23
Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21 1

Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

Embed Size (px)

Citation preview

Page 1: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

1

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

model

Information Structures and Implications 2015Bettina Berendt

Last updated: 2015-10-21

Page 2: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

2

About• These slides show what we did on the board on 13-10-2015:

– Transform the EU Parliament debates diagram into a relational model• 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.

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

Page 3: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

3

Syntax for relations

Relationname (key_attribute, attribute, ...)• Rules for naming and ordering:

– Use the entity or relationship type name as the Relationname.– Use the attribute names from the ER model – unless it‘s

clearer to disambiguate them (e.g. Turning Acronym into CountryAcronym in Represents below).

– 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.

Page 4: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

4

The diagram

Page 5: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

5

Step 1: Mapping of Regular Entity Types

Add all the following:

Session (Month, Year)

Session_Day (Day, Month, Year)

Agenda_Item (Agenda_item_ID, Title)

Speech (Speech_ID, Spoken_text, Language, Video_URI)

Parliament_Member (MEP_ID, Date_of_birth, Given_name, Family_name)

Country (Acronym, Name, EU_member_since)

Role (Name)

Political_Institution (Acronym, Institution_label)

[ignore the subclasses of Political_Institution in this step]

Page 6: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

6

Step 2: Mapping of Weak Entity Types

Not applicable, since our diagram does not contain weak entity types

Page 7: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

7

Step 3: Mapping of Binary 1:1 Relationship Types

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

Page 8: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

8

Step 4: 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):

Session (Month, Year)

IN_SESSION Session_Day (Day, Month, Year, Month, Year) Session_Day (Day, Month, Year)

Remark: If this modification leads to information being duplicated, it‘s better to delete it. Note however that this simplification rests on the real-world knowledge that the month and year of a session day will be the same as the month and year of the session that the session day is part of.

IN_SESSION_DAY Agenda_Item (Agenda_item_ID, Title, Day, Month, Year, Number)

IN_AGENDA Speech (Speech_ID, Spoken_text, Language, Video_URI, Agenda_item_ID, Number)

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

Parliament_Member (MEP_ID, Date_of_birth, Given_name, Family_name)

Country (Acronym, Name, EU_member_since)

Role (Name)

Political_Institution (Acronym, Institution_label)

Page 9: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

9

Step 5: 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):

Session (Month, Year)

IN_SESSION Session_Day (Day, Month, Year, Month, Year) Session_Day (Day, Month, Year)

Remark: If this modification leads to information being duplicated, it‘s better to delete it. Note however that this simplification rests on the real-world knowledge that the month and year of a session day will be the same as the month and year of the session that the session day is part of.

IN_SESSION_DAY Agenda_Item (Agenda_item_ID, Title, Day, Month, Year, Number)

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

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

Parliament_Member (MEP_ID, Date_of_birth, Given_name, Family_name)

Country (Acronym, Name, EU_member_since)

Role (Name)

Political_Institution (Acronym, Institution_label)

REPRESENTS Represents (MEP_ID, CountryAcronym)

Page 10: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

10

Step 6: Mapping of Multivalued Attributes

Not applicable, since our diagram does not contain multivalued attributes

Page 11: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

11

Step 7: 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):

Session (Month, Year)

IN_SESSION Session_Day (Day, Month, Year, Month, Year) Session_Day (Day, Month, Year)

Remark: If this modification leads to information being duplicated, it‘s better to delete it. Note however that this simplification rests on the real-world knowledge that the month and year of a session day will be the same as the month and year of the session that the session day is part of.

IN_SESSION_DAY Agenda_Item (Agenda_item_ID, Title, Day, Month, Year, Number)

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

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

Parliament_Member (MEP_ID, Date_of_birth, Given_name, Family_name)

Country (Acronym, Name, EU_member_since)

Role (Name)

Political_Institution (Acronym, Institution_label)

REPRESENTS Represents (MEP_ID, CountryAcronym)

IN_POLITICAL FUNCTION In_Political_Function (MEP_ID, RoleName, Inst_Acronym, Start_date,End_date)

Page 12: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

12

Step 8: 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:Political_Institution (Acronym, Institution_label)EU_Party (Inst_Acronym)National_Party (Inst_Acronym)EU_Committee (Inst_Acronym)

Normally, these subclasses would have attributes of their own, specific to the subclass and in addition to the attributes of the superclass, giving rise to relations such asEU_Party (Inst_Acronym, Number_of_member_parties)National_Party (Inst_Acronym, Number_of_members, Country_Acronym)...

Page 13: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

13

Summary model(Foreign-key arrows missing! Exercise: fill them in and check on the previous pages for correctness and completeness. Also ask yourself why each primary-key attribute is needed in all the relations.)

Session (Month, Year)

Session_Day (Day, Month, Year)

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

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

Parliament_Member (MEP_ID, Date_of_birth, Given_name, Family_name)

Country (Acronym, Name, EU_member_since)

Role (Name)

Political_Institution (Acronym, Institution_label)

Represents (MEP_ID, CountryAcronym)

In_Political_Function (MEP_ID, RoleName, Inst_Acronym, Start_date, End_date)

EU_Party (Inst_Acronym)

National_Party (Inst_Acronym)

EU_Committee (Inst_Acronym)

Page 14: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

14

How to note the foreign-key constraints

• Textbooks contain nicely formatted arrows.• We have not found a good editor for drawing nice arrows yet ...

• So we propose a textual notation, explained with an example:Speech (Speech_ID, Spoken_text, Language, Video_URI, Agenda_item_ID, Number, MEP_ID)

with Agenda_item_ID a foreign key referring to the primary key of Agenda_item,and MEP_ID a foreign key referring to the primary key of Parliament_member

• State this also when the foreign key is (part of) the current relation‘s primary key, e.g.

Represents (MEP_ID, CountryAcronym)with MEP_ID a foreign key referring to the primary key of Parliament_member,and CountryAcronym a foreign key referring to the primary key of Country

Page 15: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

15

Modifications I: A weak entity• In the ER diagram:

– Model AGENDA_ITEM as a weak entity, defined by the relationship IN_SESSION_DAY and thereby dependent on the defining entity SESSION_DAY

– Give AGENDA_ITEM the partial key Number, and remove this attribute from IN_SESSION_DAY

– Remove the artificial Agenda_Item_ID attribute / key.– Notation: double lines around AGENDA_ITEM, IN_SESSION_DAY, and a

double line between them; Number is underline with a dashed line• Transform into the relation

Agenda_Item (Day, Month, Year, Number, Title)– In general: the key of the relation is the key of the defining entity relation

(here: Day, Month and Year of Session_Day) plus the partial key of the weak entity (here: Number).

Page 16: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

16

Modifications II: 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 GOODII. 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.

Page 17: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

17

Modifications III: a multivalued attribute

• Assume that PARLIAMENT_MEMBER has an attribute Telephone

• One MEP can have multiple telephone numbers• (and a telephone number may be shared by several

MEPs)• Notation in ER diagram: double oval around the attribute• Transform by adding the relation

Has_Telephone (MEP_ID, Telephone)with the primary-key attribute MEP_ID at the same time a foreign key (from Parliament_Member) and Telephone the telephone number.

Page 18: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

18

These new notation elementsIn the summary sheetFrom the last-but-one lecture

Page 19: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

19

Modifications IV: subclass-specific attributes

• In our superclass-subclass part of the diagram, we modelled attributes for the superclass only.

• Often, subclasses have extra attributes.• For example, all political institutions have an

acronym and a label. • Assume that EU parties have, in addition to an

acronym and a label, a number of members; national parties have a language, and committees have a topic.

Page 20: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

20

How is that modelled in the EER diagram?

num_members

language

topic

Page 21: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

21

How is that modelled in the relational model?

• Just add the subclass-specific attributes to the relation of this entity type, as non-keys.

EU_Party (Inst_Acronym, num_members)

National_Party (Inst_Acronym, language)

EU_Committee (Inst_Acronym, topic)

Page 22: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

Did you notice? Something‘s not modelled yet.How would you model it?

The European Parliament organises its debates by sessions. Sessions are organised by year and month. Sessions are made up of session days. On each session day, one or more agenda items are debated. Agenda items are numbered, and they have a title and a date. Speeches are made by a member of the European Parliament as contributions to an agenda item. Speeches are numbered, and they are spoken in a language, which is recorded as the spoken text. The texts are also translated into the other EU languages. (It is ok to only model the English version.) In addition, the URI of a video of the speech is recorded. Members of Parliament have an MEP_ID, a given name and a family name, and a date of birth. They represent a country of the EU. They hold political functions (e.g. President or Vice President) in political institutions, which are identified uniquely by an acronym and also carry a label. Members of parliament hold a political function for a certain period, identified by its begin and end date. Political institutions include EU committees, EU parties and national parties. Countries are described by an acronym and a label. Different countries have different years in which they became members of the EU.

22

Page 23: Phase 2 of database design: Mapping an (E)ER diagram to a relational model Information Structures and Implications 2015 Bettina Berendt Last updated: 2015-10-21

23

Next week

• Tables!• With actual data!• i.e. SQL and querying real databases