I'm trying to create a small company database as a personal learning experience in PostgreSQL.
I'm trying to follow Derek Banas tutorial (which is really helpful) but there is something different how my products are processed.
So far I've made these tables as shown in the image Table list
In the components table I have a row 'where_used' where I wanted to put an reference INT to the product where it is used.
But as you can see, some components are used in multiple products. And I can only store one value?
So my question is:
Can someone point me in the right direction on how to get this working?
I tried googling for a solution,
But as I'm such a noob I do not know how to get the right keywords for the search...
In data modeling this technic of having multiple sub entities from a super entity is called Inheritage...
As an exemple, you can have a table that is called "Vehicle" and some child tables that are called "Planes", "Boats", "Car".
The main table (Vehicle) will have shared properties
The "Plane" table will have some properties specific to planes and so on...
Of course the Primary KEY of vehicle will be shared in an exclusive mode betwwen "Planes", "Boats" and "Cars"...
From a child point of view, the tables will have a PRIMARY KEY that is also a FOREIGN KEY.
So in your case you have a table 'COMPONENTS' that is linked to the table 'PRODUCTS'
You want to have a column in your table 'COMPONENTS' that you'll call 'where_used' that say if the component is used in x or y product.
There is different ways of doing it but this is what I would do :
Basically, you'll need 3 tables :
The first one is "COMPONENT" which store unique component values
The second one is "PRODUCT" which store every unique products
The third one is "COMPOSITION" (or whatever name you like) which is the associated table between "COMPONENT" and "PRODUCT" which will look like this :
COMPONENT_ID
PRODUCT_ID
1
1
1
2
2
3
2
1
Related
I am just started to learn about relational database. When I studied the database of online shopping websites, I found that many examples create a category table and added ID field to the category name. I don't know why they need to create a category table and use category ID as a foreign key to relate products table. What will happen if I remove the category table and add the category name directly to the products table?
What I think is a lot of cases that you want a website menu showing your categories. This menu allows people to view your categories (Men Clothing, Women Clothing, Kids, Accessories) and once they click it they can see the products relevant to them.
If you put the category name to the product, it is very hard for you to update your menu content as you need to loop, group the category in the product table. Also, it is harder to update the category name in product table as a category name could be in lots of product records,
Whereas if you have a category table, you just need to maintain the category table (view what you have in the category table and update DB record if you want your menu change).
In long term maintenance, category table is desired.
In a case I have come over that I would like an empty category which just to show in the website menu (a menu item which contains no product) which is not possible if I do not have a category table.
By inserting just the category name you may complete your POC but you need to understand what is Normalization and why it is needed.
First normal form (1NF) : An entity type is in 1NF when it contains no repeating groups of data.
Second normal form (2NF) : An entity type is in 2NF when it is in 1NF and when all of its non-key attributes are fully dependent on its primary key.
Third normal form (3NF) : An entity type is in 3NF when it is in 2NF and when all of its attributes are directly dependent on the primary key.
Source
What will happen if I remove the category table and add the category name directly to the products table?
Suppose you store the category with each product, and one day your boss tells you that you misspelled a category name. Which one?
"Theater" he says. Or did he say "theatre?" Which is correct? You check and find about "theater" and "theatre" are used close to evenly among the products that have either one.
So which spelling did your boss mean is the mistake, and which one is correct?
If you store the correct spelling in one place, in its own categories table, then you can be sure. You can correct it, and all the products that reference it will implicitly get the correction.
That's an argument for normalization, but keep in mind using an integer id is only a convention. It has nothing to do with normalization. You can use a string as a primary key of a table, and therefore you can use a string as a foreign key in a table that references it.
It's okay to use a non-integer for key columns. As long as there is one instance that stores the canonical value, it satisfies the goal of normalization -- that is to reduce data anomalies.
I am working on a project that has a relatively complicated data structure, and we are a bit stumped with the following situation:
The db has various tables which represent glazing unit* components (glass pane, coating, blind) and each one of these components has a spectra. (* glazing unit - think double/triple glazing glass unit)
Now we could have one spectra table per component table, and there would be a simple FK relationship, as follows:
tbl_glasspane 1 -- many tbl_glasspane_spectra
------------- -------------
+ Id + GlassPane_Id
GlassPaneName + Wavelength
TypeId etc. Value
Where GlassPaneId is a primary key in GlassPane, and GlassPaneId/Wavelength is a composite primary key in tbl_spectra.
This works fine, however we would need one tbl_xxx_spectra for each component table.
The solution to this was to have one Spectra table that each of the component tables would reference, but therein lies the problem - how do I get an arbitrary number of component tables to reference one spectra table?
My initial solution was:
tbl_spectra tbl_spectraIndex tbl_glasspane tbl_coating
--------------- --------------- ------------- -------------
+ SpectraIndex_Id + Id + Id + Id
+ Wavelength SpectraIndex_Id SpectraIndex_Id
Value
So an explanation...
tbl_spectraIndex is a table which contains one identity column. tbl_spectra has a FK relationship between Id from tbl_spectraIndex and SpectraIndex_Id, and this is one part of the composite PK for tbl_spectra. tbl_glasspane and tbl_coating have a FK relationship to tbl_spectraIndex.
Is this a sensible solution?
In this kind of cases is better to use a de-normalized schema. You could use one single spectra table with two fields: one is an int that store the kind of object (Table) the spectra belongs to. The other is an int that link to the table ID. In this cases spectra table is linked to multiple tables with the same field. I tend to do this for example with my address table. In my database I have many objects that need to have one or more address object asociated, while every address has the same fields. So i create a single address table, with two field like i mention early, one to represent the kind of object to represent, and one with the link to the actual object.
Also have you consider putting all you glazing tables into one single big table? Hope it helps you.
I have been questioning a certain scenario if it could benefit from using a one to one relationship in my ERD. I have a table called library with a FK called typeID from a table called element type. Essentially the element types have a sibling relationship with element as the parent and each item in the library is one of those types. The library is mainly used to create a hierarchy amongst the elements and other properties of how they exist in the library. If I add a column for every property of each type of element most columns would be virtually empty because not every element type has every property of the others. Also there are some other tables that are using the library items id where I want to put a constraint on what types of elements can be a foreign key for that table because not every element type can have that relationship. I was wondering if it is a good idea to use 1 to 1 where there is that same constraint on what type of element from the library can exist in the table, then add the unique properties. For example tableXYZ can only have items where typeID from library = 1 and all the 1 types are always in it. It seems like a good way to simulate object inheritance/generalization. Also all the tables connecting to library needing a specific type of element for the FK relationship could connect to the extended 1 to 1 table which already has that constraint so they don't have to. Also some of the elements are extensions of each other, could you have 1 to 1 then extend 1 to 1 again? Is this a legit idea? Will it even work? Is there anything I am not seeing here?
fyi the DB is postgreSQL
You might want to look into two techniques: class-table-inheritance and shared-primary-key
By applying these two techniques to your case, you may end up with a simpler, yet more powerful design than the one you propose. In some cases, you can dispense with the TypeID entirely, because a join between the generalized table and the appropriate specialized table will yield precisely the objects you are looking for. In addition, because the join is on two primary keys, the join will be relatively fast.
I'm developing a small application using the Clarizen API. The documentation references "pickup tables" numerous times, but the description
"Pick up tables are similar to the Regular entity types. Pick up tables usually contain limited set of fields and limited number of entities and are referenced from the other types of classes."
is meaningless to me. I've been trying to figure out what a pickup table is from context, but I'm stuck there too.
Some example fields from the documentation:
Country | Entity | Represents country. | Reference to the pickup table “Countries”.
State | Entity | Represents lifecycle State of the entity. For example, possible states of the Work Itemobjects can be Draft, Active, Cancelled, Completed, On Hold. Value is a reference to Statepickup table.
These examples make me think it's just a static list (which doesn't fit their given definition of pick up table), but if so the list/table is not provided to the user so I'm not sure how I would make use of it. If it does in fact refer to a static list, I'm going to have to try to coax them into giving me the tables.
I can't find a definition of pickup table online, so if anyone here knows it would help greatly.
My guess is that it's another name for a junction table, or association table. There are only foreign keys that refer to primary keys in other tables.
Pickup tables are picklists. The values of the picklist are stored in mini-tables (not really sure why but doesn't seem to be that important).
The work item state example is an example of a picklist.
I'd like to hear opinions on if it is better to keep forum categories and subcategories in the same table or in two separate tables...
Let's say you have a table ForumCategories. By adding a colum ParentId referencing the PK Id in the same table you could easily keep both the main categories and subcategories in the same table.
Alternatively, you could create a separate table ForumSubCategories and make the Id on that table a FK referencing PK Id column of the ForumCategories table.
Both solutions would work but what are the pros and cons of each solution?
Obviously, this is a more generic question that can apply to many other scenarios I just couldn't come up with a better phrasing in a hurry...
I can't think of any benefits of using 2 tables. Using 2 tables is going to constrain you to a 2 level tree. If you look at things as objects, then subcategories really are just category object. So put them in the same table. The 1 table structure will be simpler to design around and develop queries for.
If you know for sure that your forums will have only 2 levels of categories, then having 2 tables is reasonable.
Though storing categories in one table with foreign key to itself, basically, allows you store a tree of categories with virutally unlimited levels.
If they are the same entity (Category), you can link to itself. The parent would have a null for the parent ID or it could be linked to itself. This limits you to only one level unless you have a second table to handle the many-to-many possible relationships.
They must have the same fields or you're going to have unecessary fields for one or the other type. A separate table is why you would do this because they're not the same.
This is typical for an employee table. The supervisor is another employee record.