Chapter 9 Logical Database Design : Mapping ER Model To Tables.

Chapter 9Chapter 9

Logical Database Design :Logical Database Design :

Mapping ER Model To TablesMapping ER Model To Tables

9-2

Chapter OutlineChapter Outline

How to

Map an ER model to a set of tables.

Check that tables are capable of supporting the

transactions required by the user.

Define and document integrity constraints on tables.

9-3

Steps In Steps In Logical Database DesignLogical Database Design

Step 2 Map ER Model to Tables Step 2.1 Create tables Step 2.2 Check tables support user

transactionsStep 2.3 Check business rulesStep 2.4 Review logical database design with

users

9-4

Step 2.1 Step 2.1 Create TablesCreate Tables

Tables are created for an ER model to represent the

entities, relationships, attributes, and constraints.

The ER model information used for creating the

structure of tables includes

ER diagrams

ER data dictionary

Any other supporting documentation

9-5

Step 2.1 Step 2.1 Create Create TablesTables

Database Definition Language

To describe the composition of each table, we use a

Database Definition Language (DBDL) for relational

databases.

Example

Staff (staffNo, name, position, salary, branchNo)Staff (staffNo, name, position, salary, branchNo)

Primary Key staffNoPrimary Key staffNo

Foreign Key branchNo references Branch(branchNo)Foreign Key branchNo references Branch(branchNo)

9-6

Step 2.1 Step 2.1 Create TablesCreate Tables

Input

ER diagrams

Data dictionary

Output

Relational tables

Modified data dictionary

9-7

ER Diagram ER Diagram

Step 2.1 Create tables

9-8

ER Model - ER Model - Data DictionaryData Dictionary

Composite?Composite?Derived? How?Derived? How?Default value?Default value?

Composite?Composite?Derived? How?Derived? How?Default value?Default value?


9-9

How to Represent EntitiesHow to Represent Entities

For each entity in ER model, create a table that includes

all the entity’s simple attributes.

For each composite attribute, include only the simple

attributes of the composite attribute in the table.

E.g., for the composite attribute address, include its

simple attributes street, city, state, and zipcode.

Where possible, identify the attribute(s) that make up

the primary key in each table.


9-10

Initial Table Structures for the Entities Initial Table Structures for the Entities


ERD : 8 entities Data Dictionary for Branch

9-11

How to Represent EntitiesHow to Represent Entities

In some cases, it is not able to directly identify the full

set of attributes that make up a table. Because

The relationship between two entities may have to be

represented by using primary key and foreign key.

Might not identify the attributes that make up the

primary key for weak entities.


9-12

How to Represent RelationshipsHow to Represent Relationships

Relationship

Represented by the primary key (PK) and foreign key (FK) mechanism in Relational Model

How to represent a relationship?First identify the ‘parent’ and ‘child’ entities involved

in the relationshipPlace a copy of the PK of parent entity into the table

representing child entity, to act as a FK.

Step 2.1 Create tables: How to Represent Relationships

9-13

How to Represent RelationshipsHow to Represent Relationships

Types of relationships to consider

one-to-many (1:*) binary relationships

one-to-many (1:*) recursive relationships

one-to-one (1:1) binary relationships

one-to-one (1:1) recursive relationships

many-to-many (*:*) binary relationships

complex relationships

multi-valued attributes


9-14

1:* Binary Relationships1:* Binary Relationships

The entity on the ‘1 (one side)' of the relationship is

designated as the parent entity

The entity on the ‘* (many side)' is designated as the

child entity.

To represent this relationship, a copy of the primary key

of the parent entity is placed into the table representing

the child entity, to act as a foreign key.


Example

9-15

1:* Binary Relationships1:* Binary Relationships

Can the FK (branchNo) be null?


9-16

1:* Recursive Relationships1:* Recursive Relationships

The representation of a 1:* recursive relationship is The representation of a 1:* recursive relationship is similar to 1:* binary relationship.similar to 1:* binary relationship.

However, both the However, both the parentparent and and childchild entities are the entities are the same entitysame entity..

Parent entity:Parent entity:StaffStaff acts as Supervisor acts as Supervisor

Child entity:Child entity:StaffStaff acts as Supervisee acts as Supervisee


StaffStaff acts as both the parent acts as both the parent and child entities.and child entities.

9-17

1:* Recursive Relationships1:* Recursive Relationships

Can the FK (supervisorStaffNo) be null?


9-18

1:1 Binary Relationships1:1 Binary Relationships

In 1:1 binary relationship,

Cardinality cannot be used to identify parent and child entities in a relationship.

Use participation constraints to help decide whether it’s to represent the relationship

by combining the entities into one table, or by creating two tables and posting a copy of the primary

key from one table to the other

Three Participation Constraints: Mandatory participation on both sides Mandatory participation on one sides Optional participation on both sides


9-19

1:1 Binary Relationships:1:1 Binary Relationships: Mandatory Participation On Both SidesMandatory Participation On Both Sides

Method I : Combine into one table

Choose one of the primary keys of the two original entities to be primary key of the new relation

Other is used as an alternate key

If the relationship has one or more attributes, these attributes should also be included in the table


9-20

Can the AK (vehLicenseNo) be null?

Combine Into One TableCombine Into One Table


9-21

Method II: Creating Two Tables

Staff (staffNo, name, position, salary, branchNo, supervisorStaffNo)Primary Key staffNoForeign Key branchNo references BranchForeign Key supervisorStaffNo references Staff;

Car (vehLicenseNo, make, model, staffNo)Primary Key vehLicenseNoForeign Key staffNo references Staff(StaffNo);

Staff (staffNo, name, position, salary, branchNo, supervisorStaffNo, vehLicenseNo)Primary Key staffNoForeign Key branchNo references BranchForeign Key supervisorStaffNo references StaffForeign Key vehLicenseNo references Car (vehLicenseNo);Car (vehLicenseNo, make, model)Primary Key vehLicenseNo;

OROR

Can the FK (staffNo or vehLicenseNo) be null?


9-22

1:1 Binary Relationships:1:1 Binary Relationships:Mandatory Participation On One SideMandatory Participation On One Side

Using participation constraints to identify parent and child

entities.

Mandatory participation side ~ parent entity

Optional participation side ~ child entity

A copy of PK of parent table is placed in child table

If relationship has attributes, these attributes should

follow the posting of the primary key to the child table.


Example

9-23

1:1 Binary Relationships:1:1 Binary Relationships:Mandatory Participation On One SideMandatory Participation On One Side

The reason

The foreign key will always hold a value and hence

avoid the presence of nulls in this column of the

resulting table.

If we did not follow this rule and chose to represent

this relationship by placing the FK column in the

table representing the entity at mandatory

participation side, this FK column would contain

nulls.


9-24

1:1 Relationships:1:1 Relationships:Mandatory Mandatory Participation On Participation On One SideOne Side

Can the FK (staffNo) be null?


9-25

1:1 Binary Relationships:1:1 Binary Relationships: Optional Participation On Both Sides Optional Participation On Both Sides

In this case, the designation of the parent and child In this case, the designation of the parent and child entities is arbitrary.entities is arbitrary.

Consider Consider 1:1 Staff Uses Car relationship with optional relationship with optional participation on both sides.participation on both sides.


9-26

1:1 Recursive Relationships1:1 Recursive Relationships

The entity on both sides of the relationship is the same.

A special case of a 1:1 relationship.

Follow the rules for participation as described above for

a 1:1 relationship.


9-27

1:1 Recursive Relationships1:1 Recursive Relationships

Contains 3 casesMandatory participation on both sidesMandatory participation on one sidesOptional participation on both sides

Relationship representation :Represent the recursive relationship as a single table

with two copies of the primary key.One copy of the primary key represents a foreign

key and should be renamed to indicate the relationship it represents.


9-28

Converting *:* Binary RelationshipsConverting *:* Binary Relationships

Create a new table to represent the relationship Include any attributes that are part of the relationship

Post a copy of the primary key attribute(s) of the two entities in the relationship into the new table, to act as foreign keys.

One or both of the foreign keys will also form the primary key of the new tablePossibly in combination with some of the attributes

of the relationship.


9-29

*:* Binary Relationships*:* Binary Relationships


9-30

Converting Complex RelationshipsConverting Complex Relationships

For degree higher than 2

Create a new table to represent the relationship.

Post a copy of the primary key attribute(s) of the entities in the complex relationship into the new table, to act as foreign keys

Include any attributes that are associated with the relationship.

One or more of the foreign keys will also form the primary key of the new tablePossibly in combination with some of the attributes

of the relationship.Step 2.1 Create tables: How to Represent Relationships

ERD Example

Table design

9-31

Ternary RelationshipTernary Relationship


9-32

Ternary Relationship TransformationTernary Relationship Transformation


, staffNo

9-33

Multi-valued AttributesMulti-valued Attributes

A new table is created to hold the multi-valued attribute Follow the rule described for 1:* relationships.

The entity on the one side is designated as parent entity The multi-valued attribute is on the many side and is

designated the child entity The parent entity posts a copy of its primary key, to act as

a foreign key.

If the multi-valued attribute is an alternate key of the parent entity, the primary key of the new table is composed of the multi-valued attribute. Otherwise, the primary key of the new table is composed of the multi-valued attribute and the primary key of the parent entity.

Step 2.1 Create tables: How to Represent Multi-valued Attributes

ERD example

Table design

9-34

Multi-valued AttributesMulti-valued Attributes


9-35

Multi-valued Attributes – Multi-valued Attributes – ERD And Representation As TablesERD And Representation As Tables


9-36

Document Tables And FK AttributesDocument Tables And FK Attributes

The DBDL syntax can be extended to show integrity constraints on the foreign keys.

The data dictionary should be updated to indicate the presence of foreign keys and any new primary keys in this step.


9-37

Document New Tables and Document New Tables and Foreign Key AttributesForeign Key Attributes


Initial Result

, staffNo

9-38

Step 2.2 Step 2.2 Check Tables Support User TransactionsCheck Tables Support User Transactions

Ensures that no error has been introduced while creating

tables.Check that tables support the required transactions, which were documented in the users’ requirements specification.One approach is to examine the transaction’s data requirements to ensure that the data is present in one or more tables. Transactions may require data from more than one table

Check these tables are linked through the primary key / foreign key mechanism.

9-39Step 2.3 Check Tables Support User Transactions

Check Foreign Key Check Foreign Key LinkageLinkage

Examples of Step 2.2 Examples of Step 2.2 ((Check Tables Support User Transactions))

9-40

Step 2.3 Check Business RulesStep 2.3 Check Business Rules

Business rules (業務規則 )

Represented as Constraints

To protect the database from becoming incomplete,

inaccurate, or inconsistent.

Concerned only with high-level design

Specifying what business rules are required

Irrespective of how this might be achieved.

9-41

Types of business rules:

Required data

Domain constraints of attributes

Entity integrity

Multiplicity

Referential integrity

Other business rules

Step 2.3 Check Business RulesStep 2.3 Check Business Rules

9-42

Referential IntegrityReferential Integrity

There are two issues regarding foreign keys

1. Are nulls allowed for the foreign key?

If the participation of the child table in the

relationship is mandatory, then nulls are not allowed.

optional, then nulls are allowed.

2. How to ensure referential integrity? There are 6 cases for further discussion

Step 2.4 Check Business Rules

9-43

How to Ensure Referential Integrity? How to Ensure Referential Integrity?

Consider the 1:* relationship Consider the 1:* relationship Branch Has StaffBranch Has Staff..

The PK of the Branch table (The PK of the Branch table (branchNobranchNo) is a FK in the ) is a FK in the Staff table.Staff table.


child tableparent table

9-44

How to Ensure Referential Integrity?How to Ensure Referential Integrity?

Case 1: Insert a record into child table (Staff)

To ensure referential integrity, check that the foreign key

column (branchNo) of a new Staff record is set

to null (violates referential integrity), or

to a value of an existing Branch record.

Case 2: Delete record from child table (Staff)

If a record in the child table is deleted, referential

integrity is unaffected.


ERD

9-45


Case 3Case 3: : UpdateUpdate foreign key of a child record (Staff) foreign key of a child record (Staff)

This is similar to Case 1 (This is similar to Case 1 (update = delete + insertupdate = delete + insert). ).

To ensure referential integrity, check that the foreign key To ensure referential integrity, check that the foreign key column (column (branchNobranchNo) of the updated Staff record is set to ) of the updated Staff record is set to nullnull or to or to a value of an existinga value of an existing Branch record. Branch record.

Case 4Case 4: Insert record into parent table (Branch): Insert record into parent table (Branch)

Inserting a record into the parent table (Branch) Inserting a record into the parent table (Branch) doesdoes notnot affectaffect referential integrity referential integrity

It simply becomes a parent without any childrenIt simply becomes a parent without any children

(A branch without members of staff)(A branch without members of staff)


9-46


Case 5: Delete record from parent table (Branch)

If a record of the parent table is deleted, referential integrity is lost if there exists any child record referencing the deleted parent record.

In other words, referential integrity is lost if the deleted branch currently has one or more staff members working at it.

There are several strategies you can consider in this case


9-47

Strategies:Strategies: Delete a Parent Record with Child RecordsDelete a Parent Record with Child Records

The available strategies are :

1. NO ACTION

2. CASCADE

3. SET NULL

4. SET DEFAULT

5. NO CHECK


9-48

Strategies: Strategies: Delete a Parent Record with Child RecordDelete a Parent Record with Child Record

1. NO ACTION

Prevent the deletion from the parent table if there

are any referencing child records.

In our example, 'You cannot delete a branch if there

are currently staff members working there'.


9-49

Strategies: Strategies: Delete a Parent Record with Child RecordDelete a Parent Record with Child Record

2. CASCADE (Do the same operation to child records) When the parent record is deleted, automatically

delete any referencing child records. For example, 'Deleting a branch automatically deletes all

members of staff working there'. In this situation, this strategy would not be wise.

If any deleted child record also acts as a parent record in another relationship, then the delete operation should be applied to the records in the child table of this child table, and so on in a cascading manner.


DBDL example

9-50

Strategies:Strategies: Delete a Parent Record with Child RecordDelete a Parent Record with Child Record

3. SET NULL When a parent record is deleted, the FK values in

all related child records are automatically set to null. You can only consider this strategy if FK columns

can accept nulls.

4. SET DEFAULT When a parent record is deleted, the FK values in

all related child records are automatically set to their default values.

You can only consider this strategy if FK columns can accept default values


9-51

Strategies:Strategies: Delete a Parent Record with Child RecordDelete a Parent Record with Child Record

5. NO CHECK

When a parent record is deleted, do nothing to

ensure that referential integrity is maintained.

This strategy should only be considered in extreme

circumstances.


9-52


CASE 6: Update Primary Key of Parent Record (Branch)

lf the PK value of a parent table record is updated, referential integrity is lost if there exists any child record referencing the old PK value.

To ensure referential integrity, the strategies described in CASE 5 can be used.

In the case of CASCADE, the updates to the PK of the parent record are reflected in any referencing child records, and so on in a cascading manner.


9-53

Example of Referential Integrity ConstraintsExample of Referential Integrity Constraints

The referential integrity constraints for the tables that The referential integrity constraints for the tables that have been created for the Branch user viewshave been created for the Branch user views


9-54

Other Business RulesOther Business Rules

Finally, you consider constraints for any remaining

business rules that have not been defined so far.

Business rules should be represented as constraints on

the DB to ensure that only permitted table updates are

executed.

For example, StayHome has a business rule that

prevents a member from renting more than 10 videos at

any one time.


9-55

Document All Business RulesDocument All Business Rules

Document all business rules for consideration during

physical database design.


9-56

Step 2.4Step 2.4 Review Logical Database Design with UserReview Logical Database Design with User

To ensure that the logical database design is a true

representation of the data requirements of an

organization (or part of the organization) to be

supported by the database.

Date post:	14-Dec-2015
Category:	Documents
Upload:	imogen-hines
View:	232 times
Download:	2 times

Chapter 9 Logical Database Design : Mapping ER Model To Tables.

Documents