I have been asked by my manager to design a Personal Protective Equipment Database for the procurement dept,using SQL Server.In gathering my requirements for the database,I came up with 5 PPE categories:Hands,Eyes & Faces,Head,Body,Footwear.
Currently have one table which stores all the aforementioned categories,
PPCatTable:*
Hands,
Eyes & Faces,
Head,
Body,
Footwear
For each category,there are several has subsets i.e for
Footwear:*
Level of resistance to electric,
HasSteelToe,
Color,
Height,
Gloves:*
Hazard,
Degereeof hazard,
ProtectiveMaterial
but I'm stumped on what the structure of the children's table should be look like,how to store the different subsets for each category.Each subset has different number attributes and procurement dept insists on capturing all the different attributes.
Should I create a table for each child category?
What field should be referenced the child's primary key for the PPEEOrderDetails table?
Should I store the corresponding child attributes as an XML data type in the parent category table?
You want to use the entity supertype / subtype technique to model your items. Consider the following data model:
Your various categories each have their own table, because they have distinct attribute sets. Each sub-category has as its primary key, a column which is also a foreign key to the supertype table: PPEQUIP.
Note that PPEQUIP is not a list of categories, like your PPCatTable. PPEQUIP contains a record for every single item in each of the subtype tables. The columns in PPEQUIP will be the common identifier and a partitioning attribute which is a colum that indicates which subtype applies to the item. If there are other attributes that all types have in common, then those common attributes would also go in PPEQUIP.
Now when you have a table that needs to reference equipment in general, without specific regard to what category the equipment falls into, such as your ORDER_DETAIL then that foreign key reference goes to the supertype table (i.e. PPEQUIP). If on the other hand, you need to reference only a specific category, then you would do that at the subtype level.
Related
I am designing this database for a manufacturing company that produces boards for other factories to produce harnesses and I have created an items table, where each record is an item in the board to be produced, for example a fixture.
When a salesperson sees a client they fill up an information gathering format where each row of it represents one of the items to be produced. I've made a table for it.
This obviously is a one-to-many relationship, my question if I should create an intermediate table items_gatherings so as to keep the items table clean because it would have way too many fields, even if that generates a one-to-one relationship, especially considering that I also want to track the unique items through the supply chain. Also, should I also keep the tracking in another table?
Overall this are my questions:
Should I create a table for a one-to-many relation to keep attributes
of the gathering separate from those of the item?
Should I do the same for other major busy categories of attributes of this
table (e.g. item_production)?
Thank you for reading
Inventory Items :
Paper Size
-----
A0
A1
A2
etc
Paper Weight
------------
80gsm
150gsm etc
Paper mode
----------
Colour
Bw
Paper type
-----------
glass
silk
normal
Tabdividers and tabdivider Type
--------
Binding and Binding Types
--
Laminate and laminate Types
--
Such Inventory items and these all needs to be stored in invoice table
How do you store them in Database using proper RDBMS.
As per my opinion for each list a master table and retrieval with JOINS. However this may be a little bit complex adding too many tables into the database.
This normalisation is having bit of problem when storing all this information against a Invoice. This is causing too many columns in invoice table.
Other way putting all of them into a one table with more columns and then each row will be a combination of them.. (hacking algorithm 4 list with 4 items over 24 records which will have reference ID).
Which one do you think the best and why!!
Your initial idea is correct. And anyone claiming that four tables is "a little bit complex" and/or "too many tables" shouldn't be doing database work. This is what RDBMS's are designed (and tuned) to do.
Each of these 4 items is an individual property of something so they can't simply be put, as is, into a table that merges them. As you had thought, you start with:
PaperSize
PaperWeight
PaperMode
PaperType
These are lookup tables and hence should have non-auto-incrementing ID fields.
These will be used as Foreign Key fields for the main paper-based entities.
Or if they can only exist in certain combinations, then there would need to be a relationship table to capture/manage what those valid combinations are. But those four paper "properties" would still be separate tables that Foreign Key to the relationship table. Some people would put an separate ID field on that relationship table to uniquely identify the combination via a single value. Personally, I wouldn't do that unless there was a technical requirement such as Replication (or some other process/feature) that required that each table had a single-field key. Instead, I would just make the PK out of the four ID fields that point to those paper "property" lookup tables. Then those four fields would still go into any paper-based entities. At that point the main paper entity tables would look about the same as they would if there wasn't the relationship table, the difference being that instead of having 4 FKs of a single ID field each, one to each of the paper "property" tables, there would be a single FK of 4 ID fields pointing back to the PK of the relationship table.
Why not jam everything into a single table? Because:
It defeats the purpose of using a Relational Database Management System to flatten out the data into a non-relational structure.
It is harder to grow that structure over time
It makes finding all paper entities of a particular property clunkier
It makes finding all paper entities of a particular property slower / less efficient
maybe other reasons?
EDIT:
Regarding the new info (e.g. Invoice Table, etc) that wasn't in the question when I was writing the above, that should be abstracted via a Product/Inventory table that would capture these combinations. That is what I was referring to as the main paper entities. The Invoice table would simply refer to a ProductID/InventoryID (just as an example) and the Product/Inventory table would have these paper property IDs. I don't see why these properties would be in an Invoice table.
EDIT2:
Regarding the IDs of the "property" lookup tables, one reason that they should not be auto-incrementing is that their values should be taken from Enums in the app layer. These lookup tables are just a means of providing a "data dictionary" so that the database layer can have insight into what these values mean.
Imagine that you have to model incidents. There's four types of incidents (could be more). They all share some characteristics. So, the main shared fields would be in a supertype table called incidents and there will be one table per incident-type having incident_id as a FK. I could even have a incident type table to help me enforce that one incident id will be of one type only. This is all very text book, BUT, I'd like to know what's the best way to model the case when 3 of these incident types share a subset of fields and these fields are mandatory to them (so I can't put then in the supertype table, can I?). On top of that, some of those fields shared only by 3 of the incident types have a limited set of values (i.e. types of rock) and that's a typical look-up table.
So, should I repeat all these fields in the 3 incident tables and have a look-up table being Foreign keyed to these 3 tables? Should I have intermediary tables?
Thanks in advance,
Joe
I am designing a database and as i do not have much experience in this subject, i am faced with a problem which i do not know how to go about solving.
In my conceptual model i have an object known as "Vehicle" which the customer orders and the stock system monitors. This supertype has two subtypes "Motorcar" and "Motorcycle". The user can order one or the other or even both.
Now that i am at the logical design stage, i need to know how i can have the system allow for two different types of products. The problem i have is that if i put each of the objects separate attributes into the same relation, then i will have columns that are of no use to some objects.
For example, if i just have a generic table holding both "Motorcars" and "Motorcycles" which i call "Vehicles" and all of their attributes, the cars will not need some of the motorcycle attributes and the motorcycle will not need all of the car attributes.
Is there a way to solve this issue?
The decision will need to be guided by the amount of shared information. I would start by identifying all the attributes and the rules about them.
If the majority of information is shared, you might not split into multiple tables. On the other hand, you can always split tables and then join into a view for ease of use.
For instance, you might have a vehicle table with only share information, and then a motorcar table with a foreign key to the vehicles table and a motorcycle table with a foreign key to the vehicles table. There is a certain difficulty ensuring that you don't have a motorocar row AND a motorcycle row referring to the same vehicle, and so there are other possibilities to mitigate that - but all that is unnecessary if the majority of information is common, you just have unused columns in a single vehicles table. You can even enforce with constraints to ensure that columns are NULL for types where they should not be filled in.
Excuse the poor title, i can not think of the correct term.
I have a database structure that represents objects, objects have types and properties.
Only certain properties are available to certain types.
i.e.
Types - House, Car
Properties - Colour, Speed, Address
Objects of type car can have both colour and speed properties, but objects of type House can only have colour, address. The Value for the combination of object, type, property is stored in a values table.
All this works, relationships enforce the above nicely.
My dilemma is that I have another table i.e Addresses. This table has AddressID.
I want to somehow join my address table to my object values table.. is there a neat way to achieve this??
[UPDATE] - More detail
I already have 5 tables. i.e.
Object
Properties
ObjectTypes
ObjectPropertyValues
ObjectTypeProperties
These tables have relationships which lock which property values can be assigned to each type of object.
An object maybe have a name of 'Ferrari' and the type would be 'car' and because the type is car I can set a value for the colour property.
The value though is numeric and I want to be able to join to a colourcodes table to match the id.
First, a "relation" in Relational Databases is a table - it does not refer to the relationships between tables. A relation defines how pieces of data are related - to a key.
In relational modeling, each entity is normalized, so one model for you would be 4 tables:
Car (Colour-FK, Address-FK)
House (Colour-FK, Speed)
Colour (Colour-PK)
Address (Address-PK, Address-Data)
In relational model, cars are not houses and you typically would be extremely unlikely to model them in the same table.
One might argue, that in fact, the valid colours for houses and cars are very different (since the paints are not equivalent), and thus one would not ever combine the two tables based on colour in a real world application.
Possible other modelling considerations might be where the car is garaged - i.e. an FK to a House or an FK to an Address - interesting problem there. Then if you had keys to cars and houses, they could both be part of key rings, in which case you would probably model with link-tables representing the keys.