Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Today we are going to focus on converting ER Diagrams to Tables, which is an alternative or supplementary method to Normalizing the Tables. The newly converted tables should be normalized, where every non key attribute is dependent on the KEY, the WHOLE KEY, and NOTHING BUT THE KEY. The goal is exactly same: improve maintenance by eliminating UPDATE, INSERT, and DELETE anomalies.
  • One thing that we did not talk about in the last lecture was 4NF. It will not be on the test, but here is an example. 4NF mean no multi-valued dependencies. In the example above, Employee and Degree should be separated into one table and Employees and Dependents should be separated into another table.
  • Today we are going to talk about how to conver 1-N, N-N, 1-1, 1-1 Recursive, 1-N Recursive and super-types/Sub-types. Remember that when we talk about 1-N, 1,1, etc. we are talking about Maximum cardinality. Also, note that when we don’t specify, we are talking about binay Relationships.
  • Constructing ER diagram refers to Conceptual Design (Data as seen by the end-user). Converting the ER diagrams to tables (without entering into detail of datatypes) refers to Logical Design. Note that when we are talking about local logical data model, we are assuming that our data model is for a large company with a local model for each unit/department/division.
  • For every Many to many relationship (*:*), we need to create an associative/intersection table. Likewise, multi-valued attributes also require an additional table, as we shall see.
  • Every many-to-many relationship can be converted into two one-to many relationships as can be shown in the example above. Note that some tools that construct ER diagrams don’t even allow you to have a many-to-many relationship. The new table (in this example is Viewing), can be an associative (with its own attributes) table or an intersection table (doesn’t have its own attributes). Also, note that the Associative/Intersection table will be the child table (the Many) in each of the newly created relationships.
  • Above are
  • Below is a ternary relationship being converted into three binaries. Note that whenever you convert a ternary relationship (three tables connected to one relationship). The relationship will be the associate/intersection table.
  • A multi-valued attribute keeps the table from being in First Normal form and should be removed (at least theoretically). A separate table needs to be created for the multi-valued attribute.
  • To implement a one-to-many relationship, we add a Foreign key on the child (the many) side. On extreme cases (to avoid nulls), we may want to create an associative/intersection table instead. We never place a foreign key on the parent side, because we would be creating a table with a multi-valued attribute.
  • If a 1:1 Relationship is mandatory on both side, we should combine the two entities into one table. When it is mandatory on both side, we would not have null values or multi-valued attributes by combining the two entities into one table. When it is optional on one side and mandatory on the other, we should place a Foreign key on the optional side pointing to the mandatory side (as shown in the Nurse and carecenter examble above. This way, we avoid null values. When it is optional on both sides we can add a FK on either side (not both) or an associate/intersection table. The most appropriate solution will depend on the individual scenario.
  • Converting superclass/subclass to tables is not a simple task. Superclass/subclass do not convert naturally into tables, so there is no perfect solution. The figure above just shows some guidelines. Besides basing the decision on whether the relationship is Disjoint or overlapping, Partial or total, it is also important to take into consideration the type of queries you have. Do you have queries that request data in just the supertype ? Just the subtype ? What are the more important queries ?
  • The figure below provides a summary of how to convert E-R diagrams to tables.
  • Below is an exercise with one big table and fuctional dependencies. I request the class to put it in 3NF and I go around checking. Another good exercise is to do reverse engineering. Try to convert this one big table to an ER diagram.
  • Here is another exercise. This is an example similar to the previous, but a hint here is that this solution needs four tables. You may use the functional dependencies to help design the tables, but also use the data to view it.
  • In the first example above, the table is normalized because ssn determines pet_id. There will be no multi-valued attribute. In the second example, the table is not even in 1NF because an owner can have multiple pets. Therefore, pet_id is a multi-valued attribute.
  • Here is just a review of the data models again.
  • This chart is a summary of converting ER Diagrams to table with emphasis on the default solution.
  • If you answered the best solution is c, placing a Foreign Key in application, you are correct. This solution avoids null values (minimum cardinality in the student side is 1 and avoid multi-valued attribute, because the maximum cardinality of the student is many.
  • The correct answer for this is d . Solution a contains multi-valued attribute. For solution b, why use contains_name when you can use contains_id. ? Contains_name may not be unique, will require much more space. Solution c has an extra redundant table.
  • 09-23-2008.ppt

    1. 1. 09-23-2008, Tuesday Normalization / Converting E-R to Tables <ul><li>Class </li></ul><ul><ul><ul><li>Will </li></ul></ul></ul><ul><ul><ul><ul><ul><li>Start </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Momentarily… </li></ul></ul></ul></ul></ul>CS8630 Database Administration Dr. Mario Guimaraes
    2. 2. Normalization <ul><li>Normalization may be used as an alternative or </li></ul><ul><li>as a supplement to E-R Diagrams. </li></ul><ul><li>All non-key attributes of a table must be dependent on THE KEY, THE WHOLE KEY, and NOTHING BUT THE KEY. </li></ul><ul><li>Normalization: helps maintenance (update, insert , delete). </li></ul><ul><li>Not intended to speed up queries. </li></ul>
    3. 3. 4NF <ul><li>Dependency between attributes (for example, A, B, and C) in a relation, such that for each value of A there is a set of values for B and a set of values for C. However, set of values for B and C are independent of each other. </li></ul><ul><ul><li>Example Employee ->> Degree </li></ul></ul><ul><ul><ul><ul><ul><li> Employee ->> Dependents </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Don’t combine both tables. </li></ul></ul></ul></ul></ul>
    4. 4. Convert E-R to Tables <ul><li>1-N </li></ul><ul><li>N-N </li></ul><ul><li>1-1 </li></ul><ul><li>1-1 Recursive </li></ul><ul><li>1-N Recursive </li></ul><ul><li>Super-Type & Sub-Types </li></ul>
    5. 5. Methodology – Logical DD <ul><li>Build and validate local logical data model for each view </li></ul><ul><ul><li>Remove features not compatible with the relational model (optional step) </li></ul></ul><ul><ul><li>Derive tables for local logical data model </li></ul></ul><ul><ul><li>Validate tables using normalization </li></ul></ul><ul><ul><li>Validate tables against user transactions </li></ul></ul><ul><ul><li>Define integrity constraints </li></ul></ul><ul><ul><li>Review local logical data model with user </li></ul></ul><ul><li>Build and validate global logical data model </li></ul><ul><ul><li>Merge local logical data models into global model </li></ul></ul><ul><ul><li>Validate global logical data model </li></ul></ul><ul><ul><li>Check for future growth </li></ul></ul><ul><ul><li>Review global logical data model with users </li></ul></ul>
    6. 6. Build & Validate <ul><li>Remove features not compatible with the relational model (optional step) </li></ul><ul><li>To refine the local conceptual data model to remove features that are not compatible with the relational model. This involves: </li></ul><ul><ul><li>remove *:* binary relationship types; </li></ul></ul><ul><ul><li>remove *:* recursive relationship types; </li></ul></ul><ul><ul><li>remove complex relationship types; </li></ul></ul><ul><ul><li>remove multi-valued attributes. </li></ul></ul>
    7. 7. Remove *:* Binary Relationship
    8. 8. Remove *:* Recursive
    9. 9. Remove Complex Relationships
    10. 10. Remove Multi-valued Attributes
    11. 11. 1:* binary <ul><li>(3) 1:* binary relationship types </li></ul><ul><ul><li>Entity on ‘one side’ is designated the parent entity and entity on ‘many side’ is the child entity. </li></ul></ul><ul><ul><li>Post copy of the primary key attribute(s) of parent entity into relation representing child entity, to act as a foreign key. </li></ul></ul><ul><ul><li>May create an association table (not common) to avoid nulls </li></ul></ul>1:* unary: Add a column – FK (default) or association table
    12. 12. 1:1 binary <ul><li>(4) 1:1 binary relationship types </li></ul><ul><ul><li>(a) mandatory participation on both sides of 1:1 relationship; Combine both entities into one table </li></ul></ul><ul><ul><li>(b) mandatory participation on one side of 1:1 relationship; FK on side that is optional. </li></ul></ul><ul><ul><li>Example: Nurse (1,1) is in charge of (0,1) CareCenter </li></ul></ul><ul><ul><li>FK nurseid must be added to CareCenter </li></ul></ul><ul><ul><li>(c) optional participation on both sides of 1:1 relationship. Add FK on either side or 3 rd table </li></ul></ul>
    13. 13. Superclass/Subclass <ul><li>Note: </li></ul><ul><li>Mandatory = Total or Complete. Optional: Partial or Incomplete. </li></ul><ul><li>Nondisjoint = overlapping </li></ul><ul><li>2) The solution (Relations required) is not necessarily the best. It will also depend on client’s specific performance needs and what type of queries and updates occur more. </li></ul>
    14. 14. Summary
    15. 15. Also Draw E-R (Emp-Proj-Man)
    16. 16. Stolen Car Database
    17. 17. Is the table in 3NF ?
    18. 18. DATA MODELS <ul><li>Conceptual Model – data as viewed by client </li></ul><ul><li>Relational Model – data that is associated to a Relational Database (includes FK). </li></ul><ul><li>Physical Model – data associated with a specific hardware/software configuration. Associated with a specific DBMS. </li></ul>
    19. 19. Convert E-R to Tables <ul><li>1-N - add FK on child side (default) </li></ul><ul><li>N-N - create associate table (3 rd table) </li></ul><ul><li>1-1 - 3 possibilities. Look at minimum </li></ul><ul><li>cardinality for the best solution </li></ul><ul><li>1-1 Recursive 2 possib. Look at min. card. </li></ul><ul><li>1-N Recursive 2 possib. Look at min. card. </li></ul><ul><li>N-N Recursive – create associate table (2 nd table) </li></ul><ul><li>Super-Type & Sub-Types – one table for super-type </li></ul><ul><li>and one for each sub-type is usually the default </li></ul>
    20. 20. Choose best solution
    21. 22. End of Lecture <ul><li>End </li></ul><ul><li>Of </li></ul><ul><li>Today’s </li></ul><ul><li>Lecture. </li></ul>