Handout 4. Logical Database Modeling, Part 1: Relational Data Model. Transforming EER model to Relational.

Transcription

1 Handout 4 CS-605 Database Management and Modeling -Spring 18 Page 1 of 9 Handout 4 Logical Database Modeling, Part 1: Relational Data Model. Transforming EER model to Relational. Logical Database Design - The process of transforming the conceptual data model into a logical data model. Using the E-R diagram to create a set of well-structured relations that can be later implemented with a relational DBMS Relational Data Model. Introduced in 1970 by Dr. Edgar F. Codd, from IBM. Relational DBMS (RDBMS) dominate the database market till the present time - strong theoretical foundation enabled development of fast and well-defined algorithms for data querying and manipulation. Early research prototypes of relational systems were developed throughout the 1970s Commercial RDBMS emerged in the 1980s; Illustration: Data about Parts, Vendors and prices on Parts from Vendors is represented in the relational model in the following way. PART PartNumber Description 1234 Logic Chip 5678 Memory Chip VENDOR VendorName Fast Chips Quality Chips Smart Chips Location Cupertino Austin Phoenix PARTVENDOR PartNumber VendorName UnitCost 1234 Fast Chips Smart Chips Fast Chips Quality Chips Smart Chips

2 Handout 4 CS-605 Database Management and Modeling -Spring 18 Page 2 of 9 Main Components of the Relational Model: Relation (a.k.a. Table). Data (entity and relationship instances) are stored in named, two-dimensional tables, called relations. Relational model vs. ER model Rows (a.k.a records, tuples) correspond to entity instances Named Columns (a.k.a fields) correspond to entity attributes Note the difference between the terms RELATION in the relational model (referring to a table) and RELATIONSHIP in the ER model (referring to an association between entities). Properties of a relation (table): 1. Every table (a.k.a. relation) has a unique name. 2. Attributes have unique names within each table. 3. Every attribute value is atomic (not multivalued, not composite) 4. Every row is unique (can t have two rows with exactly the same values for all their fields) 5. The order of the columns has no significance 6. The order of the rows has no significance 7. A field in a record may have a value or in some cases be NULL, i.e. contain no data. 8. Every relation must have a Primary Key. Attribute (or set of attributes) whose value uniquely identifies (differentiates) each row in a relation (e.g., Employee_ID), i.e. no two distinct rows in a table can have the same values of the primary key attribute. This is how we can guarantee that all rows are unique. More on Keys: Candidate key: An attribute (or a combination of attributes) that uniquely identifies each instance of an entity type Primary key: The candidate key that has been chosen to be the unique identifier of a row. All Keys can be simple or composite. Simple consisting of a single attribute Composite - a key made up of more than one attribute (e.g., F_Name + M_Name + L_Name) Natural key vs Surrogate (artificial) keys For efficiency, it is recommended that for entities with composite keys, we instead create and use a simple surrogate key (artificial id). When replacing a composite key with a surrogate, record that the composite key is another, Candidate key, to be enforced with a uniqueness constraint. Foreign Key Attribute (or set of attributes) in one relation that serves as the primary key of another (or the same) relation in the same database, thus linking the records of two tables. Note that the Foreign Key can be named differently from the Primary Key attribute that it links to

3 Handout 4 CS-605 Database Management and Modeling -Spring 18 Page 3 of 9 Example: ERD to LDM to Table data Logical data model: table schema: Or, in textual notation (suggested for homework): CUSTOMER (Customer_ID, Customer_Name, Customer_Address, Postal_Code) ORDER (Order_ID, Order_Date, Customer_ID) Customer_ID references CUSTOMER (Customer_ID) Table Data: Customer: Customer_ID Customer_Name Customer_Address Postal_code 0305 James Smith 15 Lincoln Str, Waltham, MA Janet Flanagan 465 Ocean Ave, Arlington, MA Sofia Blum 3564 Clean Road, Belmont, NH Order: Order_ID Order_Date Customer_ID /04/ /12/ /23/

4 Handout 4 CS-605 Database Management and Modeling -Spring 18 Page 4 of 9 Integrity Constraints- Built-in mechanism that enables enforcement of certain rules facilitating data accuracy and integrity (validity, consistency) Domain constraints: the values in each of the columns of a relation have to come from a certain domain (domain - set of possible values of an attribute). Entity integrity (a. k. a. primary key constraint): no two records can have the same value of the primary key attributes. Primary key value cannot be NULL. Referential integrity: a foreign key value has to be either NULL or an existing primary key value in the relation to which the foreign key refers. ALL PART OF SQL (data definition and manipulation language for relational model) We will learn about SQL s support for these commands later on. Transforming EER diagrams into Relations. Brief Summary Create a separate Table for 1. Every multivalued attribute 2. Every entity (including associative) 3. Every many-to-many relationship Every non-many-to-many relationship on the EERD adds attributes to the existing tables as foreign keys

5 Handout 4 CS-605 Database Management and Modeling -Spring 18 Page 5 of 9 Detailed Rules (see also Chapter 4) a. Transforming Entities: create relation, specify candidate keys specify a primary key. o If it is composite, create a surrogate key instead, keep a record of the composite key as a candidate key. specify foreign key(s) Create a relation. Include a field for each simple (non-composite) single-valued attribute Composite Attributes - include only the component attributes. o Multivalued Attribute create a separate table. Include all primary key attributes from the main table they become the foreign key in the new table. Candidate/primary Key of this table is a composite key that includes all fields. Example: Employee EmployeeID EmployeeName {Skill} is represented as follows: note the composite primary key in SKILL EMPLOYEE (Employee_ID, Employee_Name ) SKILL (Skill_employee_ID, Skill) o If it is a Weak Entity (i.e. only has a partial identifier, always associated with the owner-entity through an identifying relationship;) Include the primary key field of the owner-entity table it becomes a foreign key to the owner-entity s table. Candidate/primary key of the weak-entity s table = attributes of partial identifier of the weak entity + foreign key to owner-entity s table. b. Transforming Relationships: Assuming the tables for participating Entities have already been created. Only need to create fields/tables to link appropriate records from each of the two tables, i.e. add foreign keys

6 Handout 4 CS-605 Database Management and Modeling -Spring 18 Page 6 of 9 one-to-one relationship between entities A and B - include the primary key fields of A into B s table as a foreign key, or include the primary key fields of B into A s table as a foreign key include all attributes of the relationship into the same table. one-to-many relationship between entities A and B include in B s table the primary key fields of A as a foreign key many-to-many relationship between entities A and B create a new table C include into C all primary key fields of A and B as foreign keys to each table, and all attributes of the relationship. Candidate/ Primary key of C is a composite key consisting of both foreign keys to A and B. c. Transforming Associative Entities: Assume C is an associative entity between entities A and B. Create a new table for C. Include all attributes of the associative entity. Also include primary keys from A and B into the table for C. These fields become foreign keys to A and B respectively. - Associative Entity with an identifier Identifier attribute becomes the primary key. - Associative Entity without an Identifier (like many-to-many relationship) Default candidate/primary key for the associative relation (also called the intersection table) is a composite key composed of the primary keys of the two entities and the partial identifiers of the associative entity (if any). d. Transforming Subtype/Supertype Entities Create separate relations (tables) for supertype and subtype entities. In the Supertype relation, include all attributes of Supertype, including primary key. Also include the discriminator attribute, defining the subtype entity. In the Subtype relations, include all those attributes that are unique for the Subtype. Also include an attribute that is primary key of Supertype as a foreign key

7 Handout 4 CS-605 Database Management and Modeling -Spring 18 Page 7 of 9 Practice Problems: Create an LDM (relational table schema) for the following diagrams:

8 Handout 4 CS-605 Database Management and Modeling -Spring 18 Page 8 of 9 2 Source: Hoffer, Ramesh & Topi (2013) Modern Database Management. Pearson

9 Handout 4 CS-605 Database Management and Modeling -Spring 18 Page 9 of 9 3. Source: Hoffer, Ramesh & Topi (2013) Modern Database Management. Pearson