1. Section 11ER Tables1 HSQ - DATABASES & SQL And Franchise Colleges 11 ER Tables By MANSHA NAWAZ

2. Section 11ER Tables2 Introduction In this lecture we will explore how the structure of relational tables can be determined from an ERD. The tables produced from an ERD are said to be well-normalised. –This assumes a reasonable correctness of model. First we will look at the detail of determining table structure for various permutations of degree of association and membership class. Then look at a simple technique for deriving a set of tables from an large ERD.

3. Section 11ER Tables3 1:1 Obligatory:Obligatory Every employee works on exactly one machine, and every machine is worked on by exactly one employee –this can be collapsed into one table Emp (emp#, emp_name,….., machine#, machine_location……..) Basically avoid this pattern - it means the two entities are really the same thing usually - very rare anyway. EmployeeMachine works on 1 1 

4. Section 11ER Tables4 1:1 Non-Obligatory:Obligatory Since there may be employees without machines then Employee table must exist independently. However, since every machine has exactly one employee, then the relationship can be represented by a Foreign Key reference to Employee table within the Machine table Emp (emp#, …….) Machine (machine#, emp#, …...) This is called POSTING the Primary Key of Employee into Machine –Thus forming the Foreign Key EmployeeMachine works on 1 1   Post

5. Section 11ER Tables5 1:1 Non-Obligatory:Non-Obligatory Since there may be employees without machines and machines without employees, then both the Employee and Machines tables must exist independently Therefore, the relationship must be represented by a new table Emp (emp#, …….) Machine (machine#, …….., ) Works_on (emp#, machine#, ……..) or Works_on (emp#, machine#, ……..) Either can be the identifier. We can’t use POSTING. Employee Machine works on 11 

6. Section 11ER Tables6 1:M - many end obligatory The ‘one’ dot is irrelevant to the tables. However, since every Machine has exactly one Employee, the relationship can be represented by a Foreign Key reference to Employee table We can use POSTING.. Emp (emp#, …….) Machine (machine#, emp#, ……..) This is the most common pattern on any ERD. EmployeeMachine works on M 1   Post

7. Section 11ER Tables7 1:M - Many end Non-Obligatory The only thing that influences the number of tables to produce is the class of the “M” end of the relationship –When obligatory, then two tables needed –If non-obligatory, then three tables are required We can’t use POSTING so we need a relationship table. Put the Primary Keys from either end in the new table. Emp (emp#, …….) Machine: (machine#, ……..) Works_on (machine#, emp#, ……..) For a 1:m relationship table the many end always provides the Primary Key. –Why?(Clue - exactly 1) Employee Machine works on M 1  

8. Section 11ER Tables8 M:M Relationships Irrespective of the membership classes, three tables are always produced in these relationships However, all m:m relationships should have been dealt with during modelling. Refer to the lecture on Complex Entities. You should already have, for each complex entity: Name Primary Key Attributes Description Employee Machine works on MM  

9. Section 11ER Tables9 A Technique for Deriving Tables from an ERD Assuming we have already determined that the primary key for the complex entity Treatment is: Treatment(treatment-type#, admission#, date-time, …. We will use this ERD as an example for the technique. You need to assume we have just modelled a matching scenario. The observes relationship records a single staff observer for a subset of the operations.

10. Section 11ER Tables10 1. How many tables? The first stage is to find out how many tables are required. –Every entity requires a table. –Some of the relationships require a table. –Relationships which do not require a table are represented by POSTING. The following diagram shows how to determine the number of tables. You should already have determined the primary keys for any M:M (complex entity) before this stage. Your diagram should not show un-decomposed m:m relationships. The only dots (membership class) shown are those which affect the structure of the tables.

11. Section 11ER Tables11 2. Showing all the postings How many tables will we need? Seven entity tables and one relationship table (8 Tables)

12. Section 11ER Tables12 3. Which tables? Now we simply lay out the tables as below : Simple Entities: Admission ( Patient ( Staff ( Operation ( Operation-type ( Treatment-type ( Complex Entities: Treatment ( Relationships: Observes ( The order, simple entities, complex entities, relationships just makes the process easier.

13. Section 11ER Tables13 4. Identifiers The identifiers for the entity tables are usually easy. –We have often assigned a suitable identifier when we designed the entity. –At this stage we can often use a single code for an identifier. – It may be that at a later stage we change the single code identifier for something more appropriate. Simple Entities: Admission (admission#, Patient (patient#, Staff (staff#, Operation (operation#, Operation-type (op-type#, Treatment-type ( treatment-type#, Complex Entities: Treatment (treatment-type#, admission#, date-time, Relationships: Observes (

14. Section 11ER Tables14 4. Identifiers continued... Relationships: Observes ( The relationship table observes requires more thought. –A relationship table is created by inserting the identifying attributes from the entities involved in the relationship, in this case staff and operation. Observes(operation#, staff#,....) So what is the primary key of this table? –For a m:1 table the primary key is always the attribute or attributes contributed by the many end. Observes(operation#, staff#,....) Why is operation# an appropriate primary key?

15. Section 11ER Tables15 5. Postings This diagram shows all the posting (eight). The best way to carry out posting is to check each entity on the diagram and see if anything should be posted into its table. Count the postings and check you have posted everything at the end. It is very easy to miss postings when you are in a hurry. If we look at the admission entity we can see three postings into its table. –What are they? Admission(admission#, patient#, admitting.staff#, discharging.staff#,...) The prefixes sometimes are useful to indicated a primary key's role..

16. Section 11ER Tables16 5. Postings continued... Anything to post into Patient? –No. Anything to post into Treatment-type? –No. Anything to post into Staff? –No. Anything to post into Operation-type? –No. Anything to post into Operation? –Yes - what?. Operation (operation#, admission#, op-type#, staff#, ….) Anything to post into Treatment? –Yes but we already did that when we created the complex entity. Treatment(treatment-type#, admission#, date-time, …. From the previous slide. Admission(admission#, patient#, admitting.staff#, discharging.staff#,...) Have we done all the postings? - Count them...

17. Section 11ER Tables17 5. Completed posting Simple Entities: Admission (admission#, patient#, admitting.staff#, discharging.staff#....) Patient (patient#, …) Staff (staff#, …) Operation (operation#, op-type#, responsible.staff#, admission#,...) Operation-type (op-type#, …) Treatment-type (treatment-type#, …) Complex Entities: Treatment (treatment-type#, admission#, date-time, …) Relationships: Observes (operation#, staff#,....) - are these really postings too? The skeleton tables are complete.

18. Section 11ER Tables18 6. Assigning further attributes The technique we have just explored creates a structure into which remaining attributes can be placed. Is it easy to see where admission-date and operation-duration go? Admission (admission#, patient#, admitting.staff#, discharging.staff#....) Operation (operation#, op-type#, responsible.staff#, admission#,...) If you cannot place one or more attributes then your ERD is probably missing entities or relationships.

19. Section 11ER Tables19 There May Be A Need For Second Level Design Flexing first level ER Model to reflect aspects of processing and storage Three Methods: –flexing by table elimination –flexing by table splitting –flexing by introducing derived attributes Second Level is, ideally, independent of any particular implementation environment (e.g., particular DBMS such as Oracle) –no need to worry about idiosyncrasies –wasted effort where cannot support, or not using all maximum facilities available Implementation Independence

20. Section 11ER Tables20 Flexing by Table Elimination First level Design - tables? Treat the ward end as obligatory 10% null values, but probably reduced storage and greater transaction speeds for certain Transactions Eg: NurseWard supervises  1 1 10% 95% Nurse# Name Number_years Wardname Capacity

21. Section 11ER Tables21 Treat both ends as obligatory Lots of null values and slower transactions in some cases, and higher storage possible, but some transactions quicker Or, something in between: –post the id of the entity and some of the attributes only –what is posted depends on the transactions required The last two flexes also apply to 1:1 non-obligatory relationships NurseWard supervises  1 1 10% 95% Nurse# Name Number_years Wardname Capacity

22. Section 11ER Tables22 1:M Relationships First level Design - tables? Treat the M end as obligatory Null values, but probably reduced storage and greater transaction speeds for certain Transactions EmployeeProject works on  M 1 Emp# Name Number_years Proj# Description Expected_duration Hours_worked

23. Section 11ER Tables23 Post other attributes –Introduces more redundancy, but possibly quicker transaction speeds Treat both ends as obligatory and like a 1:1 relationship –best when close to 1:1 relationship, otherwise lots of redundancy

24. Section 11ER Tables24 Have a repeating group structure –Quicker transaction speeds, but relational systems do not support this traditionally. EmployeeProject works on  M 1 Emp# Name Number_years Proj# Description Expected_duration Hours_worked

25. Section 11ER Tables25 Fixed Number Relationships 1:M = 1:2 or 1:3 0r 1:4 –i.e.,always or of maximum fixed number e.g., there are always two members of a team: senior and junior Thus design tables as below. Project: (Proj#, ……, Senior_emp#, ….., Junior_emp#, ……)

26. Section 11ER Tables26 M:N Relationships First level Design - Tables? Post the identifier and possibly other attributes of the few into the many end –Problems with repeating groups PatientWard is on  M N Many Few

27. Section 11ER Tables27 Put attributes associated with the entities into the relationship –Redundant data, but greater transaction speeds for certain transactions If fixed maximum number then use columns for each one.

28. Section 11ER Tables28 Flexing by Table Splitting If certain attributes are required more than others, then could put the heavily used attributes into one table and the not so heavily used ones in another table. Group attributes according to reporting requirements NOK = Next of Kin Patient: (Patient#, Patient_name, Patient_address, …….., Patient_NOKname, Patient_NOKaddress, ……..) Becomes Patient: (Patient#, Patient_name, Patient_address, ……..) And Patient_NOK: (Patient#, Patient_NOKname, Patient_NOKaddress, ……..)

29. Section 11ER Tables29 Second Level Representation Great when transactions never require both sets of attributes together, but a little extra memory required for the link PatientNOK * has 1 1 

30. Section 11ER Tables30 Flexing by Introducing Derived Attributes Derived Attribute : An attribute whose value can be derived from a combination of one or more other attributes in the database E.g., –adding a total project time for each project, which can be derived from the individual times recorded for each employee. –Total_invoice_cost = sum of cost of invoice items

31. Section 11ER Tables31 Happy Chappie Kennels - a more complex example First Level Design:

32. Section 11ER Tables32 Happy Chappie Kennels Second level Design possibilities –Kennel Size only 3 rows: small, medium & large. Static, so could be a Domain rather than a separate table. –Confirmed Booking no additional Attributes, therefore not needed. –Special Diet one long text description, as don’t want to query individual aspects for a given dog.

33. Section 11ER Tables33 ERD SAMPLES Ascent Resources Ascent S/W and ERD Solutions Installing Ascent At Home Using Ascent - ER Modeling Library of Free Data Models

34. Section 11ER Tables34 End of Lecture