Phase 2 of database design: Mapping an (E)ER diagram to a

relational model Information Structures and Implications 2019

Bettina Berendt

Last updated: 2019-10-06

1

About

• These slides show how to – transform the EU Parliament debates diagram created in class into a relational model – We first restrict our attention to a subset of the EER diagram, in order to show 1 example of

each mapping step only (in one case, there are 2 examples). – Please complete the mapping analogously for the remaining elements. – At the end of the slide set, the complete mapping of a slightly different EER model is shown.

• Relational model means: – think of the database in terms of a collection of tables

• The model builds on the mathematical notion of relations (hence the name), but you don‘t need to know about that

– Model the tables‘ names and column titles – Basic idea: Entities and relationships become relation / table names, attributes become

column titles (still called attributes) – The actual tables with actual data in them follow in the next step.

• This slide set follows Elmasri & Navathe‘s 8-step model (see the Chapter 9 on Toledo), but uses a slightly simplified syntax and does step 8 (mapping subclasses) earlier. In effect, steps 8 and 3 are interchanged.

• Sometimes, only selected/preferred modelling options are shown, see the chapter for full details.

2

Most important rules for relations (1) • Rules for naming and ordering:

– Use the entity or relationship type name as the name of the relation (~ table).

– Use the attribute names from the ER model – unless it‘s clearer to disambiguate them (e.g. turning acronym into country_acronym in REPRESENTS).

– The order of the attributes doesn‘t matter (mathematically), but it‘s recommended to order them in a “nicely readable“ order.

– The keys could also be anyhwere in the list of attributes, but it‘s recommended to list them at the beginning.

3

Most important rules for relations (2) • Visual rules:

– Underline the primary keys of each relation

– Show the foreign-key constraints as arrows between two attributes

• Foreign-key constraints result from mapping relationships (steps 4,5, 6, 8) or multi-valued attributes (step 7) or weak entities (step 2).

• The arrow points to the relation R2 that holds all the possible values of the attribute

• The arrow comes from the relation R1 that references the attribute in R2

• Example: REPRESENTS may only use MEP_Ids that exist in the MEP relation The arrow comes from REPRESENTS and points to MEP

4

Most important rules for relations (3) • Important: A foreign key in R1 may itself be part of the primary key of R1 (example:

REPRESENTS.MEP_ID), or it may just be “a normal attribute“ that gives extra information about the entity (example: SPEECH.MEP_ID).

When to choose which:

– A foreign key in R1 is not part of the primary key of R1 if it results from mapping a binary 1:1 or 1:n relationship.

– In all other cases, a foreign key in R1 is part of the primary key of R1.

– There can be exceptions for non-binary relationships, but we will look at these later. You may ignore them for now.

5

On these slides …

• … we will start from the EER diagram we created in class, using version V3 of the TRANSLATED_SPEECHes (as a weak entity)

6

From E(E)R to relational model (steps in grey are not applicable in our model)

1. Map regular entity types

2. Map weak entity types

3. Map subclasses

4. Map binary 1:1 relationship types

5. Map binary 1:n relationship types

6. Map binary n:m relationship types

7. Map multivalued attributes

8. Map higher-order relationship types

Starting point: Our final EER diagram (2 versions of “dependent entities”: TRANSLATED_SPEECH as weak entity vs. SESSION_DAY as

regular entity that repeats the identifying information of year and month, i.e. with redundancy)

Step 1: Mapping of Regular Entity Types

Add a relation for each regular entity type (in hierarchies: only the top one), with all its attributes and the primary key attribute(s) remaining in this role 9

Step 2: Mapping of Weak Entity Types

Add a relation, just like those mapping regular entities, but with the primary key composed of the defining entity‘s / entities‘ primary keys PLUS the partial key of the weak entity. This is the first example of foreign-key constraints.

10

Step 3: Mapping Specialization or Generalization (= subclass/superclass hierarchy)

We show only the option from Elmasri/Navathe that is always applicable (8A in their numbering): Add the following relations and foreign-key constraints based on the information in the specialization hierarchy.

11

Step 4: Mapping of Binary 1:1 Relationship Types

Not applicable, since our diagram does not contain binary 1:1 relationship types

- See the writers‘ database exercise in the exercise session for an example.

- Or the variation of the EP model below.

12

Step 5: Mapping of Binary 1:N Relationship Types

Modify the following relations and include foreign-key constraints based on information in the following relationships (the others remain unchanged): Note that this new attribute, which is a foreign key, does NOT become part of the primary key.

13

Step 6: Mapping of Binary M:N Relationship Types

14

Add the following relations and foreign-key constraints based on information in the following relationships (the others remain unchanged in this step):

Step 7: Mapping of Multivalued Attributes

15

Not applicable, since our diagram does not contain multivalued attributes

- See the variation of the EP model below.

Step 8: Mapping of N-ary Relationship Types

Add the following relations and foreign-key constraints based on information in the following relationships (the others remain unchanged in this step):

16

Summary model

17

On the remaining slides …

• … we will start from a different model, created in past exercise sessions

• … and then discuss the changes that would result from the two further variants

• This will show all the modelling elements.

18

The diagram 19

The diagram with added information

to show more mapping steps 20

charter

isFrom (0,n)

(1,1)

telNum

Step 1: Mapping of Regular Entity Types

Add all the following:

[ignore the subclasses of INSTITUTION in this step]

21

Step 2: Mapping of Weak Entity Types

22

Step 3: Mapping Specialization or Generalization

We show only option 8A (the one that is always applicable): Add the following relations and foreign-key constraints based on the information in the specialization hierarchy. 23

Step 4: Mapping of Binary 1:1 Relationship Types

Not applicable, since our diagram does not contain binary 1:1 relationship types

- See the writers‘ database exercise in the exercise session for an example.

- Or the variation of the EP model on slide 17.

24

Step 5: Mapping of Binary 1:N Relationship Types

Modify the following relations and include foreign-key constraints based on information in the following relationships (the others remain unchanged):

25

Step 6: Mapping of Binary M:N Relationship Types

Add the following relations and foreign-key constraints based on information in the following relationships (the others remain unchanged in this step):

26

Step 7: Mapping of Multivalued Attributes

27

Add a relation with the key of the base relation as a foreign key, and the single-valued version of the attribute. The primary key of this new relation consists of the primary key of the base relation plus the attribute, i.e. All the attributes of this new relation form its key.

Step 8: Mapping of N-ary Relationship Types

Add the following relations and foreign-key constraints based on information in the following relationships (the others remain unchanged in this step):

28

Summary model

29

Modifications (1): the other versions of the EER model

• Now look at version 1 and version 3 of the exercise session 1 solutions.

• What would change in the relational model here? – When you model session day as a regular entity

(version 1)? • Hint 1: This only affects steps 1 and 2 of the mapping. • Hint 2: When mapping a composite attribute (here: date),

ignore the composite-attribute name and model only its components as normal attributes.

– When you model the translations of speeches (version 2)? • Hint: This only affects step 2 of the mapping.

30

Modifications (2): a binary 1:1 relationship

• Assume (contrary to common sense) that there is always exactly one speech per agenda item. – The cardinalities become (1,1) on both sides of IN_AGENDA. – You can model this by adding the primary key of one as a foreign key

into the other: I. Modifying Speech to (as before)

Speech (Speech_ID, Spoken_text, Language, Video_URI, Agenda_item_ID, MEP_ID)

OR – BOTH OPTIONS ARE EQUALLY GOOD II. Modifying Agenda_Item to

Agenda_Item (Agenda_item_ID, Title, Date, Day, Month, Year, Number, Speech_ID)

• Now assume that every speech has to belong to one agenda item, but there can be agenda items without speeches (i.e. (1,1) on the speech side and (0,1) on the agenda-item side of the relationship). – Then option I. makes more sense than II., because you avoid a table

with lots of NULL values for the agenda items without speeches.

31

Next weeks

1. Exercises to practice modelling

2. Your first homework

3. Then: Tables!

– With actual data!

– i.e. SQL and querying real databases

32