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.
Related
I want to create a schema that ensures the consistency of the following data:
I have a COMPANY table and a PRODUCT table in a one-to-many relationship (PRODUCT has a COMPANY_ID).
Now I need to memorize the certifications that are done on the company's products. One CERTIFICATION can have multiple PRODUCT, but only one COMPANY; one COMPANY can have multiple CERTIFICATION.
I can create a many to many relationship between CERTIFICATION and PRODUCT with a PRODUCT_CERTIFICATION (C_P) table, but in this way there could be a CERTIFICATION with multiple COMPANIES and this is what I want to avoid.
My idea is to add a COMPANY_ID on the C_P table (making it COMPANY_CERTIFICATION_PRODUCT) that references the COMPANY_ID on PRODUCT (C_P has to be in a one-to-one relation with CERTIFICATION), but i dont know exactly how to do all this stuff. Also i think there is a better way to acheive what i want.
This seems to me like a common design pattern but i couldnt find it anywhere on the internet (as you can see from the title, i dont have the right keywords).
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.
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).
I have the following interesting data modeling problem. I am going to use the example of restaurants to illustrate it: Consider the following three entities: Restaurant, Location and Offer.
A restaurant can have many locations and a restaurant can have many offers.
Those relationships are easy to represent: A Restaurant table; a Location table with a FK from the Restaurant table; and a Offer table with a FK from the Restaurant table.
The interesting problem comes now:
An offer can only be valid on certain locations of a restaurant.
The modeling of that restriction seems easy at the beginning: just do an association table with two foreign keys, one from the Offer table, and another one from the Location table.
The problem with that solution is that it does not restrict me from associating offers and locations that do not belong to the same restaurant.
How could I model this in a better way that would allow me to enforce that restriction at the database level?
My assumption is that in your current model Location has 1 restaurant and Offer has 1 Restaurant.
You can solve your problem by making a compound key on Offer: (Restaurant_ID, Offer_ID) and use this key as a foreign key from Location_Offers to Offer.
You can do the same on Location: make a compound key (Restaurant_ID, Location_ID) and use this as a foreign key from Locations_Offer to Location.
This ensures that any record in Locations_Offer that links a Location and an Offer, only links those that have a relation with the same Restaurant.
I am designing a database for my cookbooks. I have created multiple tables in my design: books, authors, recipes, ingredients and for all these items I want to link media (images or video) to items in all these tables.
I was thinking of a design like:
media_id,
rid (primary key of foreign table),
rtype (1=book, 2=author, 3=recipe, 4=ingredient),
media_type(1=image,2=video),
media_url
But how will I ensure relational integrity?
Thanks
Your proposed design seems to imply that each entity (book, author, etc.) can have multiple media files, so to maintain relational integrity, I'd have separate junction tables for each relationship.
If there's only 1 media-item for each table, the media_id should be in the tables in stead of the other way around.
If several media-items are possible you shoud link them within an extra table. There should be an extra table per item (bookid_mediaid for example).
If you think it should be linkable within one table, you are actually stating that those items have at least something in common. Otherwise the rid would have different meaning throughout the records, depending on type, and that's not possible in relational theory.
Concluding :
Your design is not good. Either you should have a relationship per entity or find what's common for all entities and use that to link to your mediatypes.
Matthijs,
For a relational design, you have to look at how these objects are related to each other and then decide on the data model. Here is an initial draft and the conditions that I am assuming. You might have different rules for your case.. post them and someone should be able to post an accurate model.
Each book can be written by many authors and each author can write different books. ( M:N)
RECIPES <--> BOOKS (M:N)
RECIPES <--> INGREDIENTS (M:N)
These would be the initial set of tables.
BOOKS, AUTHORS, BOOKS_AUTHORS_ASC, RECIPES, BOOKS_RECIPES_ASC,
INGREDIENTS, RECIPES_INGREDIENTS_ASC.
If the media is related to one and only one book, you'll have a different table , say, media with the following columns. BOOK_ID is the parent column to which this media is associated.
MEDIA
-------------------------------------
MEDIA_ID NUMBER -- Primary-key
BOOK_ID NUMBER -- Foreign Key..
MEDIA_TYPE varchar2(20) -- 'IMAGE','VIDEO' etc..
other_column1 varchar2(50),
other_column2 varchar2(50)
-- so on..
And if a given image/video can be associated to multiple books and each book can have different images, then you'll have a different entity for the association.. something like..
Media
--------
Media_id number -- primary key
media_type varchar2(10),
media_name varchar2(100),
--- other columns.
MEDIA_BOOK_ASC
--------------
MEDIA_BOOK_ASC_ID NUMBER,
MEDIA_ID NUMBER, --foreign key to media table.
BOOK_ID NUMBER, --foreign key to book table
--other columns related to associations...