CHAPTER 3 - Relational Database Modeling

DATABASE SYSTEMS Introduction to Databases and Data Warehouses, Edition 2.0

▪ Once a conceptual ER diagram is constructed, a logical ER diagram is created, and then it is subsequently mapped into a relational schema (collection of relations)

Conceptual Model

Logical Model

Schema

▪ Relational database model - logical database model that represents a database as a collection of related tables ▪ Relational schema - visual depiction of the relational database model – also called a logical model ▪ Most contemporary commercial DBMS software packages, are relational DBMS (RDBMS) software packages

Terminology

▪ Relation - table in a relational database • A table containing rows and columns • The main construct in the relational database model • Every relation is a table, not every table is a relation

▪ Relation - table in a relational database • In order for a table to be a relation the following conditions must hold:

o Within one table, each column must have a unique name.

o Within one table, each row must be unique.

o All values in each column must be from the same (predefined) domain.

o Within each row, each value in each column must be single valued (one value from a predefined domain, within each row in each column).

▪ Relation - table in a relational database • Two additional properties of each table:

o Order of columns is irrelevant.

o Order of rows is irrelevant.

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 8 INTRODUCTION Example of a relation with rows and columns appearing in a different order

▪ Relational database - collection of related relations within which each relation has a unique name ▪ Primary key - column (or a set of columns) whose value is unique for each row • Each relation must have a primary key • The name of the primary key column is underlined in order to distinguish it from the other columns in the relation ▪ Foreign key - column in a relation that refers to a primary key column in another (referred) relation • A mechanism that is used to depict relationships in the relational database model • For every occurrence of a foreign key, the relational schema contains a line pointing from the foreign key to the corresponding primary key

Relation with the primary key underlined

▪ Entity integrity constraint - in a relational table, no primary key column can have null (empty) values • A rule stating that no primary key column can be optional • Every RBMS enforces this rule

Entity integrity constraint — compliance and violation example

▪ Based on the Conceptual ERD, the Logical ERD becomes a more specific blueprint for the database schema ▪ The process is: 1. Mapping entities into relations • Each regular entity becomes a relation • Each regular attribute of a regular entity becomes a column of the newly created relation • If an entity has a single unique attribute, then that attribute becomes the primary key in the resulting mapped relation

Jukić, Vrbsky, Nestorov, Sharma, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 1 – Slide 14 THE LOGICAL ER MODEL ▪ The process (cont.): 2. Represent composite keys as only their atomic attributes. The composite attribute itself is removed in the logical model. 3. Determine one primary key from the candidate keys (and underline the attribute(s)) 4. For each 1:M relationship, place the primary key from the “1” side into the entity on the “M” side. It becomes a foreign key in this entity.

o For every occurrence of a foreign key, the logical model contains a line pointing from the foreign key to the corresponding primary key

Jukić, Vrbsky, Nestorov, Sharma, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 1 – Slide 15 THE LOGICAL ER MODEL ▪ The process (cont.): 5. For each M:N relationship, create a new “associative” relation

o This new relation has two foreign keys, corresponding to the primary keys of the two relations representing the two entities involved in the M:N relationship

o The two foreign keys form the composite primary key of the new relation.

Entity with a composite attribute mapped into a relation

Sample data records for the mapped relation

▪ Composite primary key - a primary key that is composed of multiple columns • Column names of a composite primary key are underlined, because combined together they form the primary key

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 18 MAPPING ENTITIES WITH UNIQUE COMPOSITE ATTRIBUTES Entity with a unique composite attribute mapped into a relation

Sample data records for the mapped relation

Entity integrity constraint — another compliance and violation example

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 20 MAPPING ENTITIES WITH OPTIONAL ATTRIBUTES Entity with an optional attribute mapped into a relation

Sample data records for the mapped relation

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 21 MAPPING ENTITIES WITH CANDIDATE KEYS (MULTIPLE UNIQUE ATTRIBUTES) INTO RELATIONS Entity with candidate keys mapped into a relation

Sample data records for the mapped relation

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 22 MAPPING CANDIDATE KEYS Entity with regular and composite candidate keys mapped into a relation

Sample data records for the mapped relation

▪ Foreign key - column in a relation that refers to a primary key column in another (referred) relation • A mechanism that is used to depict relationships in the relational database model • For every occurrence of a foreign key, the relational schema contains a line pointing from the foreign key to the corresponding primary key

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 24 MAPPING RELATIONSHIPS Example - Mapping a 1:M relationship Mandatory participation on both sides

Sample data records for the mapped ER diagram

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 25 MAPPING RELATIONSHIPS Example - Mapping a 1:M relationship Optional participation on the 1 side

Sample data records for the mapped ER diagram

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 26 MAPPING RELATIONSHIPS Example - Mapping a 1:M relationship Optional participation on the M side

Sample data records for the mapped ER diagram

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 27 MAPPING RELATIONSHIPS Example - Mapping a 1:M relationship Renaming a foreign key

Sample data records for the mapped ER diagram

▪ Mapping M:N relationships • In addition to the two relations representing the two entities involved in the M:N relationship, another relation is created to represent the M:N relationship itself • This new relation has two foreign keys, corresponding to the primary keys of the two relations representing the two entities involved in the M:N relationship • The two foreign keys form the composite primary key of the new relation

Sample data records for the mapped ER diagram

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 30 MAPPING RELATIONSHIPS Example - Mapping an M:N relationship Optional participation on both sides

Sample data records for the mapped ER diagram

▪ Mapping 1:1 relationships • 1:1 relationships are mapped in the same way as 1:M relationships • One of the resulting relations will have a foreign key pointing to the primary key of another resulting relation • One of the mapped relations is chosen to have a foreign key referring to the primary key of the other mapped relation

o In cases when there is no particular advantage in choosing which resulting relation will include a foreign key, the choice can be arbitrary

o In other cases one choice can be more efficient than the other

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 33 MAPPING RELATIONSHIPS INTO RELATIONAL DATABASE CONSTRUCTS Example - Mapping a 1:1 relationship

Sample data records for the mapped ER diagram

▪ Referential integrity constraint - In each row of a relation containing a foreign key, the value of the foreign key EITHER matches one of the values in the primary key column of the referred relation OR the value of the foreign key is null (empty). • A rule that defines values that are valid for use in foreign keys • In a relational schema lines pointing from the foreign key to the corresponding primary key are referred to as referential integrity constraint lines

Referential integrity constraint — compliance example

Referential integrity constraint — violation example

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 39 Example mapped relational schema: ZAGI Retail Company Sales Department Database

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 40 Example: Sample data records for the ZAGI Retail Company Sales Department Database

▪ Mapping entities with candidate keys (multiple unique attributes) into relations • One of the candidate keys is chosen by the database designer as the primary key during the mapping process • Other candidate keys are mapped as non-primary, unique key columns

▪ Mapping entities with multivalued attributes into relational database constructs • An entity containing the multivalued attribute is mapped without the multi-valued attribute • The multi-valued attribute is mapped as a separate relation that has a column representing the multivalued attribute and a foreign key column referring to the primary key of the relation resulting from the entity itself

o Both of these columns form a composite primary key for the separate relation

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 43 MAPPING MULTIVALUED ATTRIBUTES Entity with multivalued attributes mapped into relations

Sample data records for the mapped relations

▪ Derived attributes are not mapped as a part of the relational schema ▪ They are implemented as a part of the database front-end application

Sample data The relation records for shown as the presented to mapped a user in a relation front-end application Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 45 Example : Entity with various types of attributes mapped into a relation

Unary relationships in ER diagrams are mapped in the same way as binary The relation mapped relationships from an entity involved in a 1:M unary relationship contains a foreign Sample data key that corresponds records for the to its own primary mapped relation key

▪ Mapping M:N unary relationships • In addition to the relation representing the entity involved in a unary M:N relationship, another relation is created to represent the M:N relationship itself • This new relation has two foreign keys, both of them corresponding to the primary key of the relation representing the entity involved in the unary M:N relationship • Each of the foreign keys is used as a part of the composite primary key of the new relation

Mapping a M:N unary relationship

Sample data records for the mapped relations

Mapping a 1:1 unary relationship: Mapped in the same way as 1:M unary relationships

Sample data records for the mapped relation

Mapping multiple relationships between the same entities: Each relationship is mapped

Sample data records for the mapped relations

▪ Mapping weak entities • Weak entities are mapped in a same way as regular entities with one addition:

o The resulting relation has a composite primary key that is composed of the partial identifier and the foreign key corresponding to the primary key of the owner entity

Mapping a weak entity

Sample data records for the mapped relations

Mapping a weak entity with two owners

Mapping a weak entity with no partial identifier

Sample data records for the mapped relations

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 57 Example mapped relational schema: HAFH Realty Company Property Management Database

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 58 Example: Sample data records for the HAFH Realty Company Property Management Database (part 1)

▪ Relational database constraints - rules that a relational database has to satisfy in order to be valid • Implicit constraints

o The implicit relational database model rules that a relational database must satisfy in order to be valid • User-defined constraints

o Database constraints that are added by the database designer

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 60 RELATIONAL DATABASE CONSTRAINTS ▪ Implicit constraints • Each relation in a relational schema must have a different name • Each relation must satisfy the following conditions: o Each column must have a different name o Each row must be unique o Domain constraint - all values in each column must be from the same predefined domain o In each row, each value in each column must be single valued o The order of columns is irrelevant o The order of rows is irrelevant • Primary key constraint - each relation must have a primary key, which is a column (or a set of columns) whose value is unique for each row • Entity integrity constraint • Referential integrity constraint

Specific minimum and maximum cardinalities

Sample data records for the mapped relations

▪ Business rules • User defined constraints that specify restrictions on databases that are not a part of the standard notation for creating ER diagrams

Sample data records for the mapped relation

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 64 RELATIONAL DATABASE CONSTRAINTS Business rule for the dates of enrollment and graduation

Sample data records for the mapped relation

Business rule for gender of students in an organization

Sample data records for the mapped relation

▪ Autonumber data type option - enables automatic generation of consecutive numeric data values in a column ▪ Designer-created primary key - primary key column, not called for by the original requirements, added to a table by the database designer • Often used in conjunction with the autonumber data type option ▪ Often called a surrogate key : it has no meaning in relation to the data.

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 3 – Slide 67 DESIGNER-CREATED PRIMARY KEYS AND THE AUTONUMBER OPTION Entity and the resulting relation with a Entity and the resulting relation designer-created primary key column

Sample data records for the relation with a designer-created primary key

▪ The process of requirements collection should be accompanied by ER modeling and then followed by mapping the ER model into a subsequent relational schema

▪ Creating relational schemas straight from the requirements is not advisable for following reasons • ER modeling is more suited for visualization of the requirements • Certain concepts can be visualized graphically only in ER diagrams • Every attribute is mentioned only once in the ER diagram • An ER model is a better communication and documentation device

▪ Create a relation for each entity with stored attributes only ▪ Create a relation for each M:N relationship with a composite PK ▪ Create foreign keys for each 1:M relationship by putting the PK from the "1" side as a FK in the "M" side ▪ Create a relation for each multivalued attribute.

Conceptual Model (ERD) Logical Model (Schema) ▪ Separate, distinct entities, ▪ Shows only stored attributes each with a primary key ▪ Uses foreign keys to ▪ Shows ALL attributes represent 1:M and 1:1 relationships ▪ Each attribute appears only once (no foreign keys) ▪ Uses a separate relation for each multivalued attribute ▪ Uses relationships between ▪ Uses a junction table with entities composite, primary, foreign ▪ Relationships show keys to represent M:N cardinality and participation relationships on both sides

Jukić, Vrbsky, Nestorov, Sharma, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 1 – Slide 71 PRACTICE! A database will used to keep track of drug dispensations at a hospital. They will keep track of the following: ▪For each patient we keep track of a unique patient identifier, patient birthdate, gender, patient name and the patient age. ▪For each nurse we will keep track of a unique nurse ID and the nurse's name. ▪For each drug we will keep track of a unique drug ID, the drug name and the drug coating(s). ▪For each ingredient contained in a drug, we will keep track of the unique ingredient identifier and the ingredient name. ▪Each ingredient must be contained in at least one drug, but it may be contained in many drugs. Every drug can contain many ingredients, but they must contain at least one. For every instance of an ingredient contained in a drug we will keep track of the dosage of the ingredient in the drug. ▪For each drug dispensation, we will keep track of the drug dispensation number for each patient (1, 2, 3 etc.), the date and the time.

Continued on next slide.

▪A drug may contradict several other drugs if they are taken at the same time, but a drug does not have to contradict any other drugs. A drug may be contradicted by many other drugs, but it does not have to be contradicted by any. ▪Each drug must be included in at least one drug dispensation, but it may be included in many. Each drug dispensation must include at least one drug, but it may include many. ▪For each instance of a drug included in a drug dispensation we will keep track of the quantity. ▪Each nurse can administer several drug dispensations, but it does not have to administer any. Each drug dispensation is administered by one nurse. ▪Each drug dispensation is related to one patient. A patient can have many drug dispensations, but they may not have any.

Conceptual Diagram on next slide.