I have one table "Liability" which is currently providing the available coverage amounts in a dropdown box. It has the following fields:
[CoverageAmountID]
[CoverageAmount]
[Cost]
[StateID]
[ProductID]
[CompanyID]
There are many coverage amounts, companies, states & products.
A complicated query currently pulls the correct Coverage Amount options. My question is if I need to split this up and how?
I have no relationships for this now but there are State, Product & Company Tables.
Do I create junction table with the CoverageAmountID, StateID, ProductID & CompanyID as the primary key?
Is there a better way to handle this with multiple m:m junction tables?
I'm struggling with how this data should be structured. The attached picture shows what I have in the table currently.
Normalizing the liability database:
Instead of using many values in one field, use intermediary tables for many to many relationships
Better use numbers for keys, using text in relationships will be challenging.
If you have one product per coverage then you have a one to many relationship in which case you can use a direct relationship from CoverageTbl to ProductTbl
Yes, you need separate tables with own primary Keys for ProductTbl, StateTbl & CompanyTbl
Attached is a tentative design showing relationships, Note all IDs are of type number, Codes are of type text(5)
database design/relationships
Related
I'm creating a database for personnel records and trying to ease record creation for the user and avoid a kludgy solution. The tables are:
people:
people_id,
person_name,
person_category_id
person_category:
person_category_id,
person type
document_requirement:
document_requirement_id,
document_requirement_name,
person_category_id,
document_section_id
document_section:
document_section_id,
document_section
I've created an append query (inner join) that populates a table caLLed document_repository which contains all of the required documents for all of the people. (I use a primary key composed of people_ID & document_id to avoid duplicates when the append query runs.) Here is the document_repository table.
document_respository:
document_repository_id,
people_id,
person category_id,
document_id,
document_section_id,
document_attachment
I'd like to be able to allow the user to create a document requirement that is applicable to multiple person categories. I understand I should avoid multi field values, which doesn't work anyway with inner joins. For example, if people categories include doctors and nurses, I'd like to be able to create a new document requirement that applies to both people categories (e.g., doctors and nurses), without having to create two separate document requirements.
More information needed?
Suggestions on design changes and/or queries?
Thanks!
snapshot of tables and relationships
What you describe is a many to many relationship. Each document requirement can be applicable to multiple person categories and different document requirements can be applicable to the same person category.
To have a many to many relationship between two entities (tables) in your database, you need another table to relate them. This additional table contains the primary key of both tables and each record in this table represents a link between the two entities.
Your naming is different between your text and your diagram, but I'll assume you want to have document_requirement records that can link to zero or more person_category records.
You need a table which for example could be called document_requirement_person_category and contains the following fields:
document_requirement_id - foreign key referencing PK of document_requirement
person_category_id - foreign key referencing PK of person_category
You then add a record to this link table for each person category that relates to each document requirement.
Edit: BTW, (if I'm reading your schema correctly), you already have a many to many relationship in your schema: document_repository allows a relationship between multiple people and a document requirement as well as multiple document requirements and a person. That's a many to many relationship.
I used the Forward Engineer tool in the MySQL Workbench to generate a database based on the tables I entered. I was able to populate my tables, such as "Villagers," "Fish," and "Items" for the database I am building around the game Stardew Valley. However, when I linked the tables in the ER Diagram it created new tables based on relationships, such as Cooking_Has_Fish because many fish can be used in many recipes and many recipes can use many fish. But, once I populated the Cooking and Fish tables there was nothing in the generated Cooking_Has_Fish table. I am trying to understand how this table functions or how it can be used, or if it needs to be populated and I missed something.
Thanks for reading.
No table ever gets populated on its own, you need to make sure that it gets populated. The third tables created for many-to-many relationships are called associative or junction table and as a minimum contain the primary keys of the 2 tables they join.
If you have a recipe_id identifying recipies and a fish_id identifying fishes, then Cooking_Has_Fish table would have at least a recipe_id and a fish_id field.
If you want to associate fish and chips (with recipe_id 1) with cod (fish_id being 2), then you would do the following insert:
insert into Cooking_Has_Fish (`recipe_id`, `fish_id`) values (1,2)
This means the cod is required for the "fish and chips". You may add additional fields to your association table, such as how much cod you need for the fish and chips.
In summary: you have to populate your association tables based on how you would like to associate your entities (tables) that have many-to-many realationship with each other.
I'm no MySQL expert and I have to design a rather complex db for my level.
The problem I'm facing now consist in having a supplier-customer relationship within the same table (macro categories of companies):
Macro table
id name mega_id macro_customer_id
------------------------------------------
1 Furniture 2 2,4,5,35
I want to represent the fact that macro entry with id 1 has other macro companies (which are their customers) described within the same table.
Which is the best way to represent this?
Thanks!
It depends: We all used to use the normalization forms (as #1000111 indicated), however depending on the use of the data, you can choose to look different at certain parts of this normalization discussion:
The normal model for this would be:
Table userData(id,name)
- 1:N table linkTable(id,macro_customer_id)
- N:1 table metaData(macro_customer_id,value)
Or:
Table userData(id,name)
- 1:N table linkTable(macro_customer_id,id)
The big question is however in how the data is used. If data is just for this user and not queried in any other way (no where, or group by), then storing it as a serialized String is a completely valid approach.
The relationship between entities in an RDBMS should be stored in a relational way. Ask yourself if you care about this relationship in your database - will you need to write queries that will link macro.id to table/rows represented by IDs in macro.macro_customer_id? If yes, then you must store this relationship in a (one-to-many or many-to-many) separate table.
I am running an e-commerce site with multiple stores and each store having its products. I currently have a table called product-store which has a list of all product id referencing the products name and description from a different table , prices etc and their corresponding store ids. This table could have same product repeating multiple times if multiple store carry it.
I am mooting the idea of having a separate table for each store(product-store1, product-store2) rather than having all stores in one product-store table. I could be adding 100 stores and hence 100 tables like this. The structure of each table is the same but the reason why I am thinking of doing this is for better encapsulation of data from the other stores. However this would also mean identifying the corresponding table first for the store and then fetching the data.
I need help in assessing if this is a right approach and how I can measure the two approaches.
There are very few good reasons for splitting a table into multiple tables. Here are reasons not to do it:
SQL is optimized for large tables, but not for lots of small tables with the same structure. (With small tables, you end up with lots of partially filled data pages.)
Maintenance is a nightmare. Adding a column, changing a data type, and so on has to be repeated many times.
A simple query such as "How many stores sell a single product?" are problematic.
You cannot have a foreign key relationship into this table, for instance, to have a history of prices or discounts on the product in each store.
A single table is almost always the best way to go.
I guess it also depends on if the products might be shared across different stores. I would not go the way of creating x tables for x stores, but a general structure to be able to hold all the information.
If so, you could set up at least three tables:
product (holds all the generic products information, shop independent)
store (information about the stores)
store_product (links the products to the stores)
This way you can add as many products / stores to your system without having to change database structure (which is bad anyways).
To answer some of your assumptions:
Encapsulation of data from different stores is rather selecting a subset of data that choosing different tables.
whenever you need some additional information (not being thought of in the beginning) for either stores or products, its easier to add by referencing the new table to stores/products instead of having to multiply those changes by the amount of stores.
I was studying about relationships in RDBMS.I have understood the basic concept behind mapping relation ship,but I am not able to spot them.
The three possibilities :
one to many(Most common) requires a PK - FK relationsip.Two tables involved
many to many(less common) requires a junction table.Three tables Involved
one to one(very rare). One table involved.
When I begin a project,I am not able to separate the first two conditions and I am not clear in my head.
Examples when I study help for a brief moment,but not when I need to put these principles in to practice.
This is the place where most begineers falter.
How can I spot these relationships.Is there a simpler way?
Don't look at relationships from a technical perspective. Use analogies and real-life examples when trying to envision relationships in your head.
For example, let's say we have a library database.
A library must have books.
M:M
Each Book may have been written by multiple Authors and each Author may have written multiple Books. Thus it is a many-to-many relationship which will reflect into 3 tables in the database.
1:M
Each Book must also have a Publisher, but a Book may only have one Publisher and a Publisher can publish many Books. Thus it is a one-to-many relationship and it reflects with the PublisherId being referenced in the Books table.
A simple analogy like this one explains relationships to their core. When you try to look at them through a technical lens you're only making it harder on yourself. What's actually difficult is applying real world data scenarios when constructing your database.
I think the reason you are not getting the answers that you need is because of the way you are framing the question. Instead of asking “How do I spot the correct type of relationship between entities”, think about “How do my functional needs dictate what relationship to implement”. Database design doesn’t drive the function; it’s the functional needs that drive the relationships you need to implement.
When designing a database structure, you need to identify all the entities. Entities are all the facts that you want to store: lists of things like book titles, invoices, countries, dog species, etc. Then to identify your relationships, you have to consider the types of questions you will want to ask your database. It takes a bit of forward thinking sometimes… just because nobody is asking the question now doesn’t mean that it might not ever be asked. So you can’t ask the universe “what is the relationship between these lists of facts?” because there is no definitive answer. You define the universe… I only want to know answers to these types of questions; therefore I need to use this type of relationship.
Let’s examine an example relation between two common entities: a table of customers and a table of store locations. There is no “correct” way to relate these entities without first defining what you need to know about them. Let’s say you work for a retailer and you want to give a customer a default store designation so they can see products on the website that their local store has in stock. This only requires a one-to-many relationship between a store and the customer. Designing the relationship this way ensures that one store can have many customers as their default and each customer can only have one default store. To implement this relationship is as easy as adding a DefaultStore field to your Customer table as a foreign key that links to the primary key of the Store table.
The same two entities above might have alternate requirements for the relationship definition in a different context. Let’s say that I need to be able to give the customer the opportunity to select a list of favorite stores so that they can query about in stock information about all of them at once. This requires a many-to-many relationship because you want one customer to be able to relate to many stores and each store can also relate to many customers. To implement a many-to-many relationship requires a little more overhead because you will have to create a separate table to define the relationship links, but you get this additional functionality. You might call your relationship table something like CustomerStoreFavorites and would have as its primary key as the combined primary keys from each of the entities: (CustomerID, StoreID). You could also add attributes to the relationship, like possibly a LastOrderDate field to specify the last date that the customer ordered something from a particular store.
You could technically define both types of relationships for the same two entities. As an example: maybe you need to give the customer the option to select a default store, but you also need to be able to record the last date that a customer ordered something from a particular store. You could implement the DefaultStore field on the Customer table with the foreign key to the Store table and also create a relationship table to track all the stores that a customer has ordered from.
If you had some weird situation where every customer had their own store, then you wouldn’t even need to create two tables for your entities because you can fit all the attributes for both the customer and the store into one table.
In short, the way you determine which type of relationship to implement is to ask yourself what questions you will need to ask the database. The way you design it will restrict the relational data you can collect as well as the queries you can ask. If I design a one-to-many relationship from the store to the customer, I won’t be able to ask questions about all the stores that each customer has ordered from unless I can get to that information though other relationships. For example, I could create an entity called "purchases" which has a one-to-many relationship to the customer and store. If each purchase is defined to relate to one customer and one store, now I can query “what stores has this customer ordered from?” In fact with this structure I am able to capture and report on a much richer source of information about all of the customer's purchases at any store. So you also need to consider the context of all the other relationships in your database to decide which relationship to implement between two particular entities.
There is no magic formula, so it just takes practice, experience, and a little creativity. ER Diagrams are a great way to get your design out of your head and onto paper so that you can analyze your design and ensure that you can get the right types of questions answered. There are also a lot of books and resources to learn about database architecture. One good book I learned a lot from was “Database System Concepts” by Abraham Silberschatz and Henry Korth.
Say you have two tables A and B. Consider an entry from A and think of how many entries from B it could possibly be related with at most: only one, or more? Then consider an entry from B and think of how many entries in A it could be related with.
Some examples:
Table A: Mothers, Table B: Children. Each child has only one mother but a mother may have one or more children. Mothers and Children have a one-to-many relationship.
Table A: Doctors, Table B: Patients. Each patient may be visiting one or more doctors and each doctor treats one or more patients. So they have a many-to-many relationship.
An example of one to one:
LicencePlate to Vehicle. One licence plate belongs to one vehicle and one vehicle has one licence plate.