Section 11 ER Tables 1
HSQ - DATABASES & SQL
And Franchise Colleges
11 ER TablesBy MANSHA NAWAZ
Section 11 ER Tables 2
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.
Section 11 ER Tables 3
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.
Employee Machineworks on 11
Section 11 ER Tables 4
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
Employee Machineworks on 11
Post
Section 11 ER Tables 5
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 Machineworks on 11
Section 11 ER Tables 6
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.
Employee Machineworks on M1
Post
Section 11 ER Tables 7
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 Machineworks on M1
Section 11 ER Tables 8
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 Machineworks on MM
Section 11 ER Tables 9
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.
Section 11 ER Tables 10
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.
Section 11 ER Tables 11
2. Showing all the postings
• How many tables will we need?
• Seven entity tables and one relationship table (8 Tables)
1
1
Treatment
Admission Patient Staff has
admits
discharges
carries -out
of
Treatment Type
Operation
Operation -type
1
1
1 m m
m
1
1
m
m m
m
1
m
m
1
observes
on
on
of
Relationship table required
Complex Entity
Section 11 ER Tables 12
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.
Section 11 ER Tables 13
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 (
Section 11 ER Tables 14
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?
Section 11 ER Tables 15
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..
Section 11 ER Tables 16
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 ...
Section 11 ER Tables 17
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.
Section 11 ER Tables 18
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.
Section 11 ER Tables 19
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
Section 11 ER Tables 20
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:
Nurse Wardsupervises 1 1
10% 95%Nurse#NameNumber_years
WardnameCapacity
Section 11 ER Tables 21
• 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
Nurse Wardsupervises 1 1
10% 95%Nurse#NameNumber_years
WardnameCapacity
Section 11 ER Tables 22
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
Employee Projectworks on M 1
Emp#NameNumber_years
Proj#DescriptionExpected_duration
Hours_worked
Section 11 ER Tables 23
• 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
Section 11 ER Tables 24
• Have a repeating group structure
– Quicker transaction speeds, but relational systems do not support this traditionally.
Employee Projectworks on M 1
Emp#NameNumber_years
Proj#DescriptionExpected_duration
Hours_worked
Section 11 ER Tables 25
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#, ……)
Section 11 ER Tables 26
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
Patient Wardis on M N
Many Few
Section 11 ER Tables 27
• 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.
Section 11 ER Tables 28
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, ……..)
Section 11 ER Tables 29
Second Level Representation
• Great when transactions never require both sets of attributes together, but a little extra memory required for the link
Patient NOK*
has11
Section 11 ER Tables 30
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
Section 11 ER Tables 31
Happy Chappie Kennels - a more complex example• First Level Design:
Breed/Dog Type
*assocwith
Dog *owns Owner
*makes
*has
SpecialDiet, etc
Booking
*requires
KennelSize
*
be Kennel*
referred to by
KennelDog
Booking
*referred to
by
*involves
Become
ConfirmedBooking
CancelledBooking
Becomes
Section 11 ER Tables 32
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.
Section 11 ER Tables 33
ERD SAMPLES
Ascent Resources
Ascent S/W and ERD Solutions
Installing Ascent At Home
Using Ascent - ER Modeling
Library of Free Data Models
Section 11 ER Tables 34
End of Lecture