section 11er tables1 hsq - databases & sql and franchise colleges 11 er tables by mansha nawaz

Section 11 ER Tables 1

HSQ - DATABASES & SQL

And Franchise Colleges

11 ER TablesBy MANSHA NAWAZ


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.


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


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


Post


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.



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


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


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


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.


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.


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


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.


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 (


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?


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


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


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.


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.


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


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


• 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


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


• 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


• 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


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#, ……)


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


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


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, ……..)


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


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


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


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.


ERD SAMPLES

Ascent Resources

Ascent S/W and ERD Solutions

Installing Ascent At Home

Using Ascent - ER Modeling

Library of Free Data Models

http://www-scm.tees.ac.uk:8002/users/u0000589/ssaweb/ERD.HTM

http://www-scm.tees.ac.uk:8002/users/u0000589/ssaweb/ERD.HTM

http://www.databaseanswers.org/data_models/index.htm


End of Lecture

section 11er tables1 hsq - databases & sql and franchise colleges 11 er tables by mansha nawaz

Documents