Logical Database Design and The Relational Model

Introduction to Database Systems
CSC-221
Instructor
Malik Khizar Hayat
Faculty of Engineering and Information Technology
Department of Software Engineering
Foundation University Rawalpindi Campus
4
Logical Database Design
and the Relational Model
Malik Khizar Hayat

87
Contents 3
• The Relational Data Model

• Integrity Constraints
• Transforming EER Model into Relations
• Normalization
• Merging Relations
4 – Logical Database Design and the Relational Model Malik Khizar Hayat
87
The Relational Data Model 4
• Dominant technology for database management

• Represents data in the form of tables
• Each table setup includes an identifier
• Other tables use the identifier to provide the relations
87
• Components
• Data Structure
• Data organization in the form of tables
• Data Manipulation
• Operations (using SQL) performed on the data
• Data Integrity
• Accuracy and consistency of data while manipulation
87
• Relational Data Structure

• Relation
• It is a two-dimensional table of data
• Each relation (or table) comprised of:
• A set of named columns
• Unnamed rows
• Each row (record) of a relation contains attribute values for a single entity
• Addition or deletion of rows (records) doesn’t change/affect the relation
87

• Relation Notation
• Name of the relation followed by names of attributes (in parenthesis)
87

• Relational Keys
• Rows of data are stored/retrieved based on the attribute values
• Every relation may have the following relational keys:
• Primary Key
• Composite Key
• Foreign Key
• Super Key
• Candidate Key
87

• Primary Key
• An attribute that uniquely identifies each row in a relation
• Composite Key
• An primary key that consists of more than one attribute
• Foreign Key
• An attribute in a relation that serves as primary key of another relation
• Super Key
• A set of attributes used to uniquely identify a row in a relation
• Candidate Key
• The minimal set of attributes used to uniquely identify a row in a relation
87
• Properties of Relations
1. Each relation (or table) in a database has a unique name
2. Attribute values must be atomic – not multi-valued
3. Each row in a relation is unique
4. Each attribute (column) within a table has a unique name
5. Sequence of columns (left to right) is insignificant
6. Sequence of rows (top to bottom) is insignificant
87
• Removing Multi-valued Attributes
87
• Removing Multi-valued Attributes
87
• Schema
• Description of a particular data collection using a given data model
• Database Schema
• Description of the overall logical structure of the database
87
• Schema Expressing Methods

1. Short text statements
• Each relation is named and attribute names follow in parenthesis
2. Graphical Representation
• Each relation is represented by a rectangle containing the attributes
87
• Schema – An Example
• Relations – CUSTOMER, ORDER, ORDER LINE, PRODUCT
87
Integrity Constraints 16
• Relational data model includes several constraints

• To maintain the accuracy and consistency of data in the DB
• Integrity constraint types include:
• Domain constraints
• Entity integrity
• Referential integrity
87
• Domain Constraints
• Domain is a set of values that may be assigned to an attribute
• All values that appear in a column must be from the same domain
• Following are the components of the domain definition:
• Domain name
• Meaning
• Data type
• Size or length
• Allowable values or range (if applicable)
87
• Domain Definition – An Example
87
• Entity Integrity
• It is to ensure that every relation has a primary key
• Every primary key attribute is NOT NULL
• An attribute cannot be a primary key for which – the values are
• Not applicable
• Unknown
Entity Integrity Rule Indicates
absence of a value
No primary key attribute
or component of a primary key Neither numeric 0
may be NULL nor empty string
87
• Referential Integrity
• It is to maintain the consistency among rows of two relations
• Involves primary-foreign key associations among rows in relations
Referential Integrity Rule

Either each foreign key value
must match a primary key value
in another relation OR the
foreign key value must be NULL
87
• Referential Integrity – An Example
87
• How to know – foreign key is allowed to be NULL?
• In a mandatory relationship – foreign key cannot be NULL
• In an optional relationship – foreign key can be NULL
87
• How to delete a foreign key related row in a relation?
• For instance, delete a row based on the relations – ORDER and CUSTOMER
What happens to ORDER data If a record in the parent

table is deleted, then
if we delete a CUSTOMER the matching records in
who has submitted ORDERS the child table will
automatically be
deleted
Possible Choices
1. Delete the associated orders – a cascading delete
2. Prohibit customer deletion until all associated orders all deleted
3. Place a NULL value in the foreign key
87
87
• Creating Relational Tables
87
87
87
87
• Well-structured Relations
• A relation that contains minimal redundancy
• Allow users to insert, modify, and delete rows in a table
• Without errors or inconsistencies
87
• Redundancy in a table may result in errors called anomalies
• Types of anomalies
1. Insertion anomaly
2. Deletion anomaly
3. Modification anomaly
87
1. Insertion Anomaly
• Certain attributes cannot be inserted without presence of others attributes
2. Deletion Anomaly
• Certain attributes are lost because of deletion of other attributes
3. Modification Anomaly
• One or more instances of duplicated data updated, but not all
87
Transforming EER Model into Relations 32
• Logical design helps to convert EER into relational schema

• CASE tools can aid to convert EER to relational schema
• Understanding the conversion process is important as:
1. Better understanding of the real-world business (domain)
2. CASE tools often cannot model complex relationships
3. Manual transformation is flexible for runtime solutions
4. Understanding rules help to perform a quality check on CASE output
Logical Relational
ER/EER
Design Schema
87
• Database Modeling
87
• Transformation Steps
1. Map Regular Entities
2. Map Weak Entities
3. Map Binary Relationships
4. Map Associative Entities
5. Map Unary Relationships
6. Map Ternary (and n-ary) Relationships
7. Map Supertype/Subtype Relationships
87

• Regular entities are relations with the same name as the entity type
• Simple attributes of entity type becomes attributes of the relation
• Identifier of entity type becomes the primary key of the relation
87

a) Composite Attributes
• Split each composite attribute into simple attributes
• Include each simple attributes as attributes of the relation
87

b) Multi-valued Attributes
• Two new relations are created to map multi-valued attributes
• First relation contains all attributes except the multivalued attribute
• Second relation contains two attributes – form the relation’s primary key
• First attribute is primary key from the first relation, foreign key in the second relation
• Second is the multi-valued attribute
• Multiple multivalued attributes will be converted to a separate relation each
87

b) Multi-valued Attributes
87

• For each weak entity type, create a new relation
• Include all of the simple attributes as attributes of this relation
• Include primary key of identifying relation as a foreign key in new
• Primary key of the new relation is the combination of
• Primary key of the identifying entity
• Partial identifier of the weak entity type
• Use the surrogate key
• An alternative approach to simplify primary key of the DEPENDENT relation
87
87

• Surrogate Key
• A serial number or other system-assigned primary key for a relation
• Used to simplify the key structures
• When to use Surrogate Key
1. There is a composite primary key
2. The natural primary key is inefficient (e.g., very long to be used as foreign)
3. The natural primary key is recycled (e.g., may not be unique over time)
87

• Surrogate Key
• In the presence of surrogate keys, the natural keys are kept as non-key data
• Natural keys have organizational meaning and significance
The attributes which are

not declared as any of the
key types – also called
descriptors
87

a) One-To-Many (1:M)
• Create a relation for each of the two participating entity types
• Include the primary key attribute(s) of the entity on the one-side of relation
• As the foreign key in the relation that is on the many-side of the relation
A mnemonic
The primary key migrates to the many-side
87

87

b) Many-To-Many (M:N)
• For a binary M:N relationship between two entity types, A and B
• Create a new relation C
• Include primary key attributes of A and B as foreign key in relation C
• Foreign keys in C would become composite primary key of relation C
• Non-key attributes of C are included in the relation C
87

87

c) One-To-One (1:1)
• Create a relation for each of the two entity types, A and B
• Include the primary key of A or B as the foreign key in A or B
• In 1:1 relationship, the one direction is optional and the other is mandatory
• Foreign key should be included on the optional side of the relation
• Prevents NULL values to be stored in the foreign key
87

c) One-To-One (1:1)
87

• Similar as mapping an M:N relationship
• Create three relations:
• One for each of the two participating entity types
• One for the associative entity (associative relation)
87

a) Identifier Not Assigned
• Default primary key for the associative relation is
• The primary key attributes from the other two relations
• These act as foreign keys that reference to the other two relations
87

b) Identifier Assigned
• Primary key is assigned to the associative entity on the E-R diagram
• Associative entities may assigned identifier at conceptual level because of:
1. A natural single-attribute identifier that is familiar to end-users
2. Default identifier may not uniquely identify instances of associative entity
• Primary key attributes from the participating entity types
• Included as foreign keys in the associative relation
87
Identifier
Not Assigned
87

Identifier
Assigned
87

• Create a relation to map the entity type in the unary relationship
• Add a foreign key attribute to the same relation
• That references to the primary key attribute in the same relation
Recursive Foreign Key

A foreign key in a relation
that references the primary key values
of the same relation
87

87

• Create two relations
• One to represent the entity type in the relationship
• Other for associative relation to represent the M:N relationship itself
• Primary key of the associative relation consists of two attributes
• These attributes take their values from the primary key of the other relation
• The non-key attribute(s) are included in the associative relation
87

87
6. Map Ternary (N-ary) Relationships

• An associative relation among three entity types, A, B, and C
• Create a new associative relation D
• Default primary key for D is:
• Primary key attributes for the participating entity types A, B, and C
• Act as foreign keys that reference the individual primary keys of A, B, and C
• Additional attributes may be required to form a unique primary key
• Any attributes of the associative entity type
• Become attributes of the new relation D
87
6. Map Ternary (N-ary) Relationships
87

• Create a separate relation
• For the supertype i.e., A
• For each of its subtypes i.e., B, C
• Assign common attributes of B and C to A including primary key
• Assign to each B and C, the primary key from A
• Assign unique attributes to B and C
• Assign attribute(s) of supertype to function as subtype discriminator
Relational model does not directly support the supertype/subtype relationships
87
87
87
Normalization 63
• Data manipulation may lead to

• Redundancy
• Inconsistency
87
Normalization 64
• Data manipulation may lead to

• Redundancy
• Inconsistency
Normalization
A systematic approach of
decomposing relations into smaller ones
to eliminate data redundancy, dependency,
insertion, update, and deletion anomalies
87
Normalization 65
• Goals
• Minimize data redundancy – avoid anomalies, save storage space
• Simplify the enforcement of referential integrity constraints
• Make it easier to maintain data (insert, update, and delete)
• Provide better design – improved representation of the real world
87
Normalization 66
• Functional Dependency
• A constraint between two attributes in which the value of one
attribute is determined by the value of another attribute
• Determinant
• The attribute(s) used to determine the values assigned to other
attribute(s) in the same row
87
Normalization 67
• Functional Dependency
87
Normalization 68
• Partial Functional Dependency

• A functional dependency in which one or more non-key attributes
are functionally dependent on part (but not all) of the primary key
87
Normalization 69
• Transitive Dependency
• A functional dependency between the primary key and one or
more non-key attributes that are dependent on the primary key
via another non-key attribute
87
Normalization 70
• Normal Form
• Normalization can be accomplished in stages
• Each stage corresponds to a normal form
Normal Form
A state of relation that
requires the certain rules are satisfied
regarding relationships between attributes
87
Normalization 71
• Steps
• First Normal Form (1NF)
• Relation has a primary key and does not contain repeating groups of attributes
• Second Normal Form (2NF)
• Relation is in 1NF and have no partial functional dependencies
• Third Normal Form (3-NF)
• Relation is in 2NF and have no transitive dependencies
• Boyce-Codd Normal Form (BCNF)
• Relation is in 3NF and no anomalies because of multiple candidate keys
• Fourth Normal Form (4NF)
• Relation is in BCNF and have no multi-valued dependencies
• Fifth Normal Form (5NF)
• Relation is in 4NF and have no projection join dependencies
87
Normalization 72
• Steps
87
Normalization 73
• An Example – Customer Invoice
87
Normalization 74
• An Example – Invoice Data
87
Normalization 75
• An Example – Functional Dependencies
87
Normalization 76
• Convert to 1NF
• Remove the repeating groups
• Same as ‘removing multi-valued attributes’
• Select the primary key
• Non-redundant
87
Normalization 77
• Convert to 2NF
• Removing Partial Dependencies
1. Create a new relation for each primary key attribute(s) that is
determinant in a partial dependency
2. Move the non-key attributes that are dependent on the primary key
attribute(s) from the old relation to the new relation
87
Normalization 78
• Convert to 2NF
87
Normalization 79
• 1NF 2NF
• A relation in 1NF will be 2NF, if any one of the following applies:
1. Primary key attribute consists of only one attribute – no partial dependency
2. No non-key attributes exist in the relation – no functional dependency
3. Every non-key attribute is functionally dependent on full set of primary keys
87
Normalization 80
• Convert to 3NF
• Removing Transitive Dependencies
1. Create a new relation for each non-key attribute(s) that is determinant
in a relation. That attribute(s) becomes the primary key of the new
relation
2. Move all attributes that are functionally dependent on primary key of
the new relation from the old to the new relation
3. Leave the attribute that serves as a primary key in the new relation in
the old relation to serve as a foreign key
87
Normalization 81
• Convert to 3NF
• Removing Transitive Dependencies
87
Normalization 82
• An Example – Relation Schema for Invoice Data
87
Merging Relations 83
• Organizations have independent DB development activities

• May ultimately need to create the same database
• Redundant relations may be generated from various processes
• Analyst should merge those relations to remove the redundancy
• Purpose
• When multiple teams (sub-teams) work on a single large project
• Databases with new information may require integration
• New data requirements may arise due to the life cycle
87
• View Integration Problems

• Synonyms
• Two or more attributes may have different name but the same meaning
• By using an alias – an alternative name used for an attribute
• For instance, StudentID
87

• Homonyms
• Attribute(s) that may have more than one meaning
• For instance, Account – could be a bank or mail account
87

• Transitive Dependencies
• May occur due to merging of two 3NF relations into single relation
• Can be converted into 3NF by removing transitive dependencies
87

• Supertype/Subtype Relations
• May be hidden in user views or relations

Logical Database Design and The Relational Model

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Logical Database Design and The Relational Model

Încărcat de

Drepturi de autor:

Formate disponibile

Introduction to Database Systems

Malik Khizar Hayat

• The Relational Data Model

• Dominant technology for database management

• Relational Data Structure

• Relational Data Structure

• Relational Data Structure

• Relational Data Structure

• Removing Multi-valued Attributes

• Removing Multi-valued Attributes

• Schema Expressing Methods

• Relational data model includes several constraints

• Domain Definition – An Example

Referential Integrity Rule

• Referential Integrity – An Example

What happens to ORDER data If a record in the parent

• Creating Relational Tables

• Creating Relational Tables

• Creating Relational Tables

• Creating Relational Tables

• Logical design helps to convert EER into relational schema

1. Map Regular Entities

1. Map Regular Entities

1. Map Regular Entities

1. Map Regular Entities

2. Map Weak Entities

2. Map Weak Entities

2. Map Weak Entities

2. Map Weak Entities

The attributes which are

3. Map Binary Relationships

3. Map Binary Relationships

3. Map Binary Relationships

3. Map Binary Relationships

3. Map Binary Relationships

3. Map Binary Relationships

4. Map Associative Entities

4. Map Associative Entities

4. Map Associative Entities

4. Map Associative Entities

4. Map Associative Entities

5. Map Unary Relationships

Recursive Foreign Key

5. Map Unary Relationships

5. Map Unary Relationships

5. Map Unary Relationships

6. Map Ternary (N-ary) Relationships

6. Map Ternary (N-ary) Relationships

7. Map Supertype/Subtype Relationships

Relational model does not directly support the supertype/subtype relationships

7. Map Supertype/Subtype Relationships

7. Map Supertype/Subtype Relationships

• Data manipulation may lead to

• Data manipulation may lead to

• Partial Functional Dependency

• An Example – Customer Invoice

• An Example – Invoice Data

• An Example – Functional Dependencies

• An Example – Relation Schema for Invoice Data

• Organizations have independent DB development activities

• View Integration Problems

• View Integration Problems

• View Integration Problems