I have a Product and a Product Category.
I can define a Product has Product Category relationship, or Product Category has Product.
Both make sense to me. My aim is to achieve a grouping of products to categorize them more easily. I see Product Category as a helper concept and not a concrete concept. i.e. a Product is something I could sell, something I can place into a shopping cart, etc. I cannot do that with a Product Category. But I can use it to group things, i.e. show a listing of Productthat belongs to a certain Product Category.
Many to Many relation is symmetrical, I assume, and there are two ways to create it. How can I determine which direction is correct in my case? Is there one?
Since many-to-many is bidirectional, there really is no need for consideration of a "correct direction". As for the design, I would create product_category as a static table with only primary keys; the products table with its own primary key column(s) such as Product ID; and a third association table which foreign keys the primary keys from the two tables.
PRODUCT_TAGS
PROD_ID|CAT
21|Heating
21|Security
25|Heating
37|Lighting
37|Security
I think you have a one-to-many relationship instead of a many-to-many.
Whenever I look at relationships of any type, I ask myself a question about the tables (using your table names):
Does a product have many categories, or does a category have many products?
If the first point is true, then the ID from the product table goes into the category table. Otherwise, the ID from the category table goes into the product table.
If both is true (a product has many categories and a category has many products), then you'll need a joining table.
I'm assuming that a category has many products, but a product can only have one category. If that's true, you would add a category_id to your product table.
If it's a many-to-many relationship, your table would look like this:
product_category_map (product_id, category_id)
Hope that answers your question. I recently wrote an article on normalisation that covers the concept of one-to-many and many-to-many relationships as it can be a confusing concept. (Disclosure: I own that website).
Related
Just wanted to get feedback on my ERD. A bit rusty on my PK and FK. Scenario: An ice cream shop that orders flavored ice cream and keeps track of ingredients in each flavor. Customers can have many orders. Orders can have many flavors, and any flavor can have multiple ingredients. Thanks
At the way the foreigns keys are, an order can ony have one flavor, and a flavor can only have one ingredient.
You need to create more 2 tables of n:m relationship: One table for the order flavors, and other for the flavor ingredients. Do a search about m to n relationships.
The customers and orders are correctly related with a one-to-many relation:
each order has one customer_id, and this FK allows to find back the customer through the PK.
since several orders can use the same customer_id (it's a FK), it's really a many orders possible for a single customer.
The ingredient to flavour relation is inconsistent. According to the PK/FK, we can infer that one ingredient (PK) could be used in many flavours (FK), but each flavour has only one ingredient_id, so can be associated only with one ingredient. This is not what the connection between the two is telling.
To make flavours having multiple ingredients, you could add a FK flavour_id in ingredients. Unfortunately, this would link an ingredient to a single flavour. The only way out, would be to make this relation many-to-many. This requires an associative entity flavour_ingredients with a FK flavour_id and an FK ingredient_id (you could add an id PK, or use a composite PK made of the two FKs)
The problem of the relation between orders and flavours is exactly the same. The way you have modelled it is inconsistent, and you'd need a many-to-many relationship to model the reality of ice-cream orders.
So I'm taking a look at the well-known Chinook DB. The PlaylistTrack table is obviously an association table because it just contains keys from two tables.
But what I don't quite understand is why certain other tables like Invoice are not association tables despite also containing at least two keys. Invoice, for example, contains InvoiceId and CustomerId (as well as some other fields).
I know that InvoiceId is the primary key for the invoice table and CustomerId is a foreign key pointing to another table. But isn't that the same for the PlaylistTrack table?
Conceptually speaking, what is it about the PlaylistTrack table that makes it an association table? And what is it that is different about the Invoice table that doesn't make it an association table? Or is it an association table?
It is because that it is a many-many relationship, all the other relationships are one-many.
A one-many relationship can be achieved by the child storing a unique reference/map association with it's ONE and ONLY parent (the parent potentially have 0-MANY children).
However, this embedding of the reference will not facilitate, the playlist track as a track can be in many playlists (so a track could have many parents). That is where the association tables comes in, it caters for many-many relationships (by that nature if can obviously also cater for one-one relationships).
However, I believe that the InvoiceLine table is also an associative table but with additional values (Unit price and Quantity) specific to the actual association/relationship.
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 totally confused to store category and product data stored in the same table in hierarchical relation/Parent-child relation use in a table or if we create two separate table for category and product table?
in above table, i used the same table for storing category and product with parentId and childId, If we use like this then what benefits? Or we use a separate table for category and product and why? Please anyone help me
This really depends on if the relationship between store and product categories are one to many or many to many and if a single category can only belong to one category tree.
If the relationship is one to many, and a category can only belong to one tree, then you'll be able to use a single table, with a foreign key referencing the same table.
Otherwise, you'll likely be looking 2 or 3 tables. At a minimum you'll need one table for your categories, and then another for you relationship (what's known as a composite key table).
Also, if Product categories and Store Categories are inherently different (hold different data) then you should be using separate tables for them anyway.
I have a requirement on a project and I have to make an erd diagram for a market. I have the following text:
Michael is going to the market and wants to buy some groceries: vegetables(tomatoes and cucumbers), fruits(apples and oranges), some drinks and meal.
Based on this text I have to create the ERD diagram and I am stuck, is look like I forgot anything about ERD in this moment. Can you help me please?
Well you need to identify the 'entities' like:
categories (vegetables, fruits)
products (tomatoes, cucumbers, apples, oranges) with respect to category_id as foreign key
Then define their attributes and keys
define all keys (primary key, foreign key)
all attributes of entities
Then define relations between all these entities
1 to 1 (one product belongs to one category)
1 to many (one product belongs to many categories)
many to many (many products belong to many categories)
By following these steps, I am sure you will get ERD.