Download Mapping an ERD to a Relational Database

Mapping an ERD to a Relational Database
Designing/creating a database
At its simplest we can say that an analyst must design the database and then
implement the database
• The most common technique used to design a database is to create an ERD,
based on the business rules, that specifies the data a system must maintain. The
ERD represents these rules using 3 things: entity types, relationship types, and
attributes.
• The most common database structure is the relational model.
So, in ACS-2814 we consider
• Using and ERD to represent the data requirements
• Mapping an ERD to a relational structure (tables, PKs, FKs)
The remaining slides show how we translate an ERD to a relational database.
We show the standard approach – in practice, someone may deviate from what we
show but they must have good reasons (beyond our scope) for doing so.
ACS-2814
Ron McFadyen
1
Mapping an ERD to a Relational Database
Entity Types
Each entity type is implemented with a separate relation.
a. Strong Entities, or regular, entity types are mapped to their own relation.
The PK is chosen from the set of keys available.
b. Weak Entities
Weak entity types are mapped to their own relation, but the primary key
of the relation is formed as follows. If there are identifying relationships,
then the PK of the weak entity is the combination of the PKs of entities
related through identifying relationships and the discriminator of the
weak entity type; otherwise the PK of the relation is the PK of the weak
entity
ACS-2814
Ron McFadyen
2
Mapping an ERD to a Relational Database
Relationship Types
The implementation of relationships involves foreign keys.
One-To-One
In general, with a one-to-one relationship, a designer has a choice regarding where to
implement the relationship. One may choose to place a foreign key in one of the two
relations, or in both. Consider placing the foreign key such that nulls are minimized.
Attributes on the relationship are placed in the relation with the FK.
One-To-Many
With a one-to-many relationship the designer must place a foreign key in the relation
corresponding to the ‘many’ side of the relationship. Any other attributes defined for
the relationship are also included on the ‘many’ side.
Many-To-Many
A many-to-many relationship must be implemented with a separate relation for the
relationship. This new relation will have a composite primary key comprising the
primary keys of the participating entity types and any discriminator attribute, plus
attributes of the relationship (if any)
ACS-2814
Ron McFadyen
3
Mapping an ERD to a Relational Database
Attributes
All attributes, with the exception of derived and composite attributes, must appear in
relations.
Simple, atomic
These are included in the relation created for the pertinent entity type, many-tomany relationship, or n-ary relationship (2814 ignores n-ary relationships).
Multi-valued
Each multi-valued attribute is implemented using a new relation. This relation will
include the primary key of the related entity type. The primary key of the new
relation will be the primary key of the related entity type plus the multi-valued
attribute. Note that in this new relation, the attribute is no longer multi-valued.
Composite and Derived attributes are not included.
ACS-2814
Ron McFadyen
4
Mapping an ERD to a Relational Database
Department has two keys. One of these was chosen as PK.
Course has a composite PK. Course inherits the PK of Department to be
used as part of its PK.
ACS-2814
Ron McFadyen
5