0% found this document useful (0 votes)
28 views21 pages

Topic 05

Uploaded by

甘凯恒
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views21 pages

Topic 05

Uploaded by

甘凯恒
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 21

UCCD 1203

Database Development and


Applications

Topic 5
Basic Mapping: The Transformation Process
Reminder:
Intellectual Property
◼ Copyright must be seriously protected. The University
takes a strong stand against any illegal photocopying and
distributing of all materials provided to students. Students
are forewarned of the consequences and the penalty that
may be meted out if they are “caught in the act”.
◼ All the materials provided to student SHOULD NOT be
posted/distributed at any online platform or any other
ways possible without the permission.
Objectives

◼ Describe the terminology mapping between a


conceptual model and a relational database model
◼ How to map a set of tables from an ER model.
Mapping

◼ Transform the conceptual database design into a


logical database design that can be implemented
on a chosen DBMS later
◼ Input: conceptual model (ERD)
◼ Output: relational schema, normalized relations
◼ Create tables for the ER model to represent the
entities, relationships, attributes, and constraints.
Terminology Mapping

◼ Changing from analysis (conceptual model) to


design (physical implementation) also means
changing terminology:
◼ An entity becomes a table.
◼ An instance becomes a row.
◼ An attribute becomes a column.
◼ A primary unique identifier becomes a primary key.
◼ A relationship is transformed into a foreign-key column and a
foreign key constraint.
Terminology Mapping
Map tables - Discuss using example ERD
How to represent entities
◼ For each entity in ER model, create a table that
includes all the entity’s simple attributes.
◼ For composite attributes, include only the simple
attributes.
◼ Where possible, identify the column(s) that make
up the primary key in each table.
Initial table structures for the entities
How to represent relationships

◼ In deciding where to post (or place) the foreign key


attribute(s), must first identify the ‘parent’ and
‘child’ entities involved in the relationship.
◼ The parent entity refers to the entity that posts a
copy of its primary key into the table that represents
the child entity, to act as the foreign key.

10
How to represent relationships

◼ Consider how to represent the following


relationships:
◼ 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;
◼ Also, consider multi-valued attributes.

11
1:* binary relationships
◼ Entity on ‘one side’ of relationship is designated
as the parent entity and entity on ‘many side’ is
designated as child entity.

◼ A copy of primary key of parent entity is placed


into table representing the child entity, to act as a
foreign key.

12
1:* relationship – (a) ER diagram; (b) as
tables

13
1:* recursive relationships
◼ The representation of a 1:* recursive
relationship is similar to 1:* binary
relationship.
◼ However, in this case, both the parent and
child entity is the same entity.

14
1:* recursive relationships – (a) ER diagram;
(b) as tables

15
1:1 binary relationships
◼ PK on the mandatory side becomes a FK on
the optional side.
◼ Either represent the relationship by
combining the entities involved into one
table or by creating two tables and posting a
copy of the primary key from one table to
the other.

16
*:* binary relationships
◼ Create a table to represent the relationship and
include any attributes that are part of the
relationship.
◼ Post a copy of the primary key attribute(s) of the
entities that participate 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 table, possibly in
combination with some of the attributes of the
relationship.

17
*:* binary relationships – (a) ER diagram; (b)
as tables
Multi-valued attributes
◼ A new table is created to hold the multi-valued
attribute and the parent entity posts a copy of its
primary key, to act as a foreign key.

19
Multi-valued attributes – ER diagram and
representation as tables

20
Map all tables

You might also like