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

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

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

4. The diagram 4

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] 5

6. Step 2: Mapping of Weak Entity Types Not applicable, since our diagram does not contain weak entity types 6

7. Step 3: Mapping of Binary 1:1 Relationship Types Not applicable, since our diagram does not contain binary 1:1 relationship types 7

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) 8

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) 9

10. Step 6: Mapping of Multivalued Attributes Not applicable, since our diagram does not contain multivalued attributes 10

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) 11

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 as EU_Party (Inst_Acronym, Number_of_member_parties) National_Party (Inst_Acronym, Number_of_members, Country_Acronym)... 12

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) 13

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 14

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). 15

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

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

18. These new notation elements In the summary sheet From the last-but-one lecture 18

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

20. How is that modelled in the EER diagram? 20 num_members language topic

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) 21

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

23. Next week Tables! With actual data! i.e. SQL and querying real databases 23