Database Design E R 2009

1

Database Design

2

What is a Database?

A collection of data that is organised in a predictable structured way

Any organised collection of data in one place can be considered a database

Examples filing cabinet library floppy disk

3

What is Data?

The heart of the DBMS. Two kinds

Collection of information that is stored in the database.

A Metadata, information about the database. Also known as a data dictionary.

An example of a Metadata in shown in Appendix A.

4

Relational Data Model

A relational database is perceived as a collection of tables.

Each table consists of a series of rows & columns.

Tables (or relations) are related to each other by sharing a common characteristic. (EG a customer or product table)

A table yields complete physical data independence.

5

Features of the relational data model

Logical and Physical separated

Simple to understand. Easy to use.

Powerful nonprocedural (what, not how) language toaccess data.

Uniform access to all data.

Rigorous database design principles.

Access paths by matching data values, not by following fixed links.

6

Terminology

Relation Null Value Tuple Attribute Domain Relation Schema Integrity Constraint Domain Constraint Key Constraint Key, Candidate Key Simple Key Composite Key Primary Key

Relational Database Relational Database Schema Referential Integrity Constraint Foreign Key Network Diagram Update Operations Join Projection Lossless join

7

Relation A 2-dimensional table of values with these properties: No duplicate rows Rows can be in any order Columns are uniquely named by Attributes Each cell contains only one value

The special value is NULL which implies that there is no corresponding value for that cell. This may mean the value does not apply or that it is unavailable. Entire rows of NULLs are not allowed.

Terminology

Employee Job Manager

Jack Secretary Jill

Jill Executive Bozo

Bozo Director

Lulu Clerk Jill

8

Tuple Commonly referred to as a row in a relation.

Eg:

Terminology

Attribute• A name given to a column in a relation. Each column must

have a unique attribute. This are often referred to as the fields.


Jack Clerk Jill

9

A pool of atomic values from which cells a given column take their values. Each attribute has a domain. Attributes may share domains

Terminology: Domain

Typist ManagerClerk........

Tom Mary Bozo Kali........

An attribute value (a value in a column labelled by the attribute)must be from the corresponding domain or may be NULL ( ).

Here again we use the same domain as above in

employee.

Attribute Domain

Employee Person Name

Job Job Name

Manager Person Name

10

A Relational Schema is a named set of attributes. This refers to the structure only of a relation. It is derived from the traditional set notation displayed below

EMPLOYEE = { Employee, Job, Manager }

This is usually written in the modified version for database purposes:

EMPLOYEE( Employee, Job, Manager ) referring to the Table

Terminology:Relation Schema

EMPLOYEEEmployee Job Manager

11

An Integrity Constraint is a condition that prescribes whatvalues are allowable in a relation. This permits the restriction of

the type of value that can be placed in a particular cell. Eg. only numbers for telephone numbers

The Domain Constraint is a condition on the allowable values for an attribute.

e.g. Salary < $60,000

Terminology:Integrity Constraint and Domain Constraint

EMPLOYEEThis restricts the

salary to be under a set value.

Employee Job Manager Salary

Jack Secretary Jill 25,000

Jill Executive Bozo 40,000

Bozo Director 50,000

Lulu Clerk Jill 30,000

12

Dealing with many keys

We will be referring to the following keys Primary key Foreign key Simple key Composite key Concatenated key Candidate key Universal key

A key is a device that helps define relationships. Its role is based on the concept of functional dependency which we deal with extensively.

13

A condition that no value of an attribute or set of attributes be repeated in a relation.

e.g. Employee(the attribute) has only unique values in EMPLOYEE (the relation).

The following relation violates this constraint:

Terminology:Key Constraint

EMPLOYEE

Jack appears twice. This means thatThis violates the Key Constraint


Jack Secretary Bozo 25,000

Jack Secretary Jill 25,000




14

An attribute (or set of attributes) to which a key constraint applies is called a key ( or candidate key). Every relation schema must have a key.

If a key constraint applies to a set of attributes, it is called a composite or Concatenated Key. Otherwise it is a simple key.

Key

Simple Key Composite Key:

EMPLOYEE Another possible key. The combination of Job and manager is also unique




Kim Secretary Jill 25,000


Bozo Director Bozo 50,000


15

A key cannot have a NULL ( ) value.

For example, If we change the table so that the Employee Bozo does not have a manager then Job+Manager cannot be a key.








16

A primary key is a special preassigned key that can always be used to uniquely identify tuples. We have to choose a Primary Key for every Relation. We must consider all of the Candidate Keys and choose between them.

Employee is a primary key for EMPLOYEE is usuallywritten as:

EMPLOYEE( Employee, Job, Manager, Salary )

Here we have chosen the Simple Key Employee

Over the concatenated option of both

Job and Manager






Bozo Director Bozo 50,000


17

A Database is more than multiple tables you must be able to “relate” them

Cus-code

Cus-Name Area-Code Phone Agent-Code

10010 Ramus 615 844-2573 50210011 Dunne 713 894-1238 50110012 Smith 615 894-2205 50210013 Olowaski 615 894-2180 50210014 Orlando 615 222-1672 50110015 O’Brian 713 442-3381 50310016 Brown 615 297-1226 50210017 Williams 615 290-2556 50310018 Farris 713 382-7185 50110019 Smith 615 297-3809 503

Agent-Code

Agent-Name Agent-AreaCode

Agent-Phone

501 Alby 713 226-1249

502 Hahn 615 882-1244

503 Okon 615 123-5589

The link is through the Agent-Code

18

A Relational Database is just a set of Relations.For example

Terminology: Relational Database

Which Attribute do you think relates these two tables together?

JOB Job Salary

Secretary 25,000

Secretary 25,000

Executive 40,000

Director 50,000

Clerk 30,000







EMPLOYEE

19

A Relational Database Schema a set of Relation Schemas, together with a set of Integrity Constraints.

For example the Relations that you have been looking at with the headings

EMPLOYEE

JOB

are usually written as EMPLOYEE(Employee, Job, Manager) JOB(Job, Salary)

Notice how the Primary Keys are underlined

Terminology:Relational Database Schema


Job Salary

20

This constraint says that –All the values in one column should also appear in another column.Look at the table below. Every entry in the Job column of the Employee table must appear in the Job column of the Job table

Terminology :Referential Integrity Constraint

EMPLOYEE JOBFK PK


Jack Secretary Bozo

Kim Secretary Jill

Jill Executive Bozo

Bozo Director

Lulu Clerk Jill

Job Salary

Secretary 25,000

Secretary 25,000

Executive 40,000

Director 50,000

Clerk 30,000

FKPK

21

Referential Integrity Constraint

Why does the following relational database violate the referential integrity constraints?

In other words, Why can’t Employee(Job) be a Foreign Key to Job(Job), or Employee(Manager) be a Foreign Key to Employee(Employee)?

Click here for the answers

Job Salary

Director 50,000

Clerk 30,000


Jack Secretary Bozo

Kim Secretary Jill

Bozo Director

Lulu Clerk Jill

EMPLOYEE JOBFK

FKPK

PK

22

Why Use Relational Databases

Their major advantage is they minimise the need to store the same data in a number of places

This is referred to as data redundancy

23

Example of Data Redundancy (1)

24


The names and addresses of all students are being maintained in three places

If Owen Money moves house, his address needs to be updated in three separate places

Consider what might happen if he forgot to let library administration know

25


26


Data redundancy results in: wastage of storage space by recording

duplicate information

difficulty in updating information

inaccurate, out-of-date data being maintained

27

Other Advantages of Relational Databases

Flexibility relationships (links) are not implicitly defined

by the data Data structures are easily modified Data can be added, deleted, modified or

queried easily

28

Summary of Some Common Relational

Terms Entity - an object (person, place or thing) that

we wish to store data about Relationship - an association between two entities Relation - a table of data Tuple - a row of data in a table Attribute - a column of data in a table Primary Key - an attribute (or group of attributes) that

uniquely identify individual records in a table

Foreign Key - an attribute appearing within a table that is a primary key in

another table

29

Network Diagrams

30

Terminology: Network Diagram

EMPLOYEE(Employee, Job, Manager) JOB(Job, Salary)

A relational database schema with referential integrity constraints can also be represented by a network diagram. A Referential Integrity Constraint is notated as an arrow labeled by the foreign key. You must always write the label of the Foreign Key on the arrow. Sometimes the same attribute has different titles in different tables.

EMPLOYEE JOBJob

Manager Network Diagram

Referential Integrity constraints can easily be represented by arrows FK PK. The arrow points from the Foreign Key to the matching Primary Key

Notice here, the label is Manager and not Employee.

31

Personnel Database: Consider the following Tables

PROJECT

NAME P_NUMBER MANAGER ACTUAL_COST EXPECTED_COST

New billing system 23760 Yates 1000 10000Common stock issue 28765 Baker 3000 4000Resolve bad debts 26713 Kanter 2000 1500New office lease 26511 Yates 5000 5000Revise documentation 34054 Kanter 100 3000Entertain new client 87108 Yates 5000 2000New TV commercial 85005 Baker 10000 8000

ASSIGNMENT SKILL

E_NUMBER P_NUMBER AREA

1001 26713 Stock Market 1002 26713 Taxation 1003 23760 Investments 1003 26511 Management1004 26511 1004 287651005 23760

EMPLOYEE TITLE

NAME E_NUMBER DEPARTMENT E_NUMBER CURRENT_TITLE

Kanter 1111 Finance 1001 Senior consultant Yates 1112 Accounting 1002 Senior consultant Adams 1001 Finance 1003 Senior consultant Baker 1002 Finance 1004 Junior consultant Clarke 1003 Accounting 1005 Junior consultant Dexter 1004 Finance Early 1005 Accounting

PRIOR_JOB EXPERTISE

E_NUMBER PRIOR_TITLE E_NUMBER SKILL

1001 Junior consultant 1001 Stock market 1001 Research analyst 1001 Investments 1002 Junior consultant 1002 Stock market 1002 Research analyst 1003 Stock market 1003 Junior consultant 1003 Investments 1004 Summer intern 1004 Taxation

1005 Management

32

ASSIGNMENT (E_NUMBER, P_NUMBER)

PRIOR_JOB (E_NUMBER, PRIOR_TITLE)

EXPERTISE (E_NUMBER, SKILL)

TITLE (E_NUMBER, CURRENT TITLE )

EMPLOYEE (NAME, E_NUMBER, DEPARTMENT)

SKILL (AREA)

PROJECT (NAME, P_NUMBER, MANAGER, ACTUAL_COST, EXPECTED_COST )

Personnel Database Schema

Not FK, we will look at this later

What are the connecting Foreign Keys to Primary Keys?

33

TITLE

PROJECT

PRIOR_JOB

EMPLOYEESKILL

EXPERTISE

Personnel Database Network Diagram

ASSIGNMENT

Once you have produced your Schema and identified the Primary and Foreign Keys you can create the Network Diagram.The Network Diagram shows each of the tables with their links. Each of the Tables (Relations) are represented in a rectangle as shown. They are then connected by arrows that show the FKs pointing to the PKs, The arrow head points towards the PK, while the FK name written is the same as the attribute of the table that has the FK in it.

34

Personnel Database Network Diagram

TITLE

PROJECT

PRIOR_JOB

EMPLOYEESKILL

EXPERTISE

skill

e_n

um

ber

p_n

um

ber

e_number

e_number

e_number

manager

ASSIGNMENT

35

Summary: Questions

What is a Relational Database?

What actually is a relation?

What are Constraints?

What is a Schema?

What is a Network Diagram and why is it used?

36

Summary: Answers

A relational database is based on the relational data model.It is one or more Relations(Tables) that are Related to each other

A relation is a table composed of rows (tuples) and columns, satisfying 5 properties• No duplicate rows• Rows can be in any order• Columns are uniquely named by Attributes• Each cell contains only one value• No null rows.

Constraints are central to the correct modeling of business information. Here we have seen them limit the set up of your tables: Referential Constraint

The Network Diagram is used to navigate complex database structures. It is a compact way to show the relationships between Relations (Tables)

37

Activities

Consider the following relational database schemas.

Suppliers(suppId, name, street, city,state)Part(partId,partName,weight,length,composition)Products(prodId, prodName,department)Supplies(partId,suppId)Uses(partId,prodId) Make reasonable assumptions about the meaning of attribute

and relations, identify the primary and foreign keys and draw a network diagram showing the relations and foreign keys.

38

Answer

Supplies

Supplier Part

Uses

Product

39

Show the foreign keys on the network diagrams

Orders

Customer

SalesRep

Part

Ordnum ordDate custNumb12489 2/9/91 124

custNumb custName Address Balance credLim sksnumb

124 Adams 48 oak st 418.68 500 3

Slsnumber Name address totCom commRate

3 Mary 12 Way 2150 .05

Part Desc onHand IT wehsNumb

unitPrice

AX12 Iron 1.4 HW 3 17.95

40

OrLineordNum Part ordNum quotePrice

41

Answer

Orders

OrLine

Part

Customer

SalesRep

SlsNumber

CustNumb orLine

Part

42

Obtain tutorial 1 from your tutor

43

Functional Dependence FDD

44

Functional Dependency Diagrams

Data AnalysisIn this Unit we look at the following:

Data Element, Attribute,Functional Dependency (FD),

Redundant FD,Pseudotransitive FD,Intersecting Attribute

45


A FUNCTIONAL DEPENDENCY DIAGRAM is a way ofrepresenting the structure of information needed tosupport a business or organization

It can easily be converted into a design for a relationaldatabase to support the operations of the business.

46

Functional Dependency DiagramsThere are a number of methods for us to develop our database design from here. We could use the method of developing a large table with all attributes and breaking it down into smaller tables using what we refer to as Normalization by Decomposition (we look at this in detail later), or we could use Functional Dependency Diagrams to create a pictorial model of our database.

47

Data Analysis and Database Design Using Functional Dependency

Diagrams1. The steps of Data Analysis in FDD are

1.1 Look for Data Elements1.2 Look for Functional Dependencies1.3 Represent Functional Dependencies in a

diagram1.4 Eliminate Redundant Functional

Dependencies2. Data Design, after we have our final version of the

FDD

2.1 Apply the Synthesis Algorithm

48

Starting points for drawing functional

dependency diagrams

We must Understand the data

We Examine forms, reports,data entry and output

screens etc…

We Examine sample data

We consider Enterprise (business) rules

We examine narrative descriptions and conduct

interviews.

We apply our Experiences/Practice and that of others

To start the process of constructing our FDD we do the following:

49

Enterprise Rules

What are Enterprise Rules?An enterprise rule (in the context of data analysis) is astatement made by the enterprise (organisation,

company,officer in charge etc.) which constrains data in some way.

Functional dependencies are the most important type ofconstraint on data and are often expressed in the form ofenterprise rules.

e.gNo two employees may have the same employee number.

An order is made by only one customerAn employee can belong to only one department at a

time.

50

Drawing FDDs - Data Elements

We often refer to Data Elements during the FDD

process

A data element is a elementary piece of recorded

information

Every data element has a unique name.

A data element is either a

Label, e.g PersonName, Address,

BulidingCode, or

Measurement, e.g. Height, Age,

Date A data element must take values that can be

written down.

51


Now we have the Database Design

2NF Relation

3NF Relation

Universal Relation

1NF

TablesONF

Using the Method ofDecomposition

Method ofSynthesis

Sample Data

Eliminate Part Key

Dependencies

Eliminate Non KeyDependencies

EliminateRepeating

Groups

Attribute& Functional

Dependencies

Given theProblem

FunctionalDependency

Diagram

OR, here is the same process using the FDD approach

52

Data Element Examples

Here are some examples PersonName has values Jeff, Jill, Gio, Enid Address has values 1 John St, 25 Rocky Road Height has values 171cm, 195cm Age has values 21,52,93,2 Date has values 20th May 1947, 2nd March 1997 JobName has values Manager, Secretary, Clerk Manager might not be a data element, but

ManagerName could be. It could be a value of another data element e.g. JobName

53

Drawing FDDs Data Elements

Start drawing the Functional Dependency Diagram by

representing the Data Elements. A Data Element isrepresented by its name placed in a box:Every data element must have a unique name in

thefunctional dependency diagram.A data element cannot be composed of other data

elements i.e.it cannot be broken down into smaller componentsA Data Element is also known as an ATTRIBUTE,

because it generally describes a property of some thing which we will later call an ENTITY

Data Element

54

A functional Dependency is a relationship between Attributes.

It is shown as an arrow e.g A B

It means that for every value of A, there is only one value for B It reads “A determines B”. A is called a determinant attribute.

B is called the dependent attribute.

Drawing FDDs –Using Elements

55

Data Element Examples

Surname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

On a form gives rise to the element

CREDIT CARD Bankcard Mastercard Visa Other

CreditCardType

Surname

Here are some examples of finding the Data Elements on a typical form

On a form gives rise to the element

56

Functional Dependency Examples

Students and their family names

“Each student (identified by student number) has only one family name”

Students FamilyName

1 Smith

2 Jones

3 Smith

4 Andrews

Considering the rules stated above we should be able to draw a FDD for this. What are the elements of interest?

57

FDDs AnswerStudents FamilyName

1 Smith

2 Jones

3 Smith

4 Andrews

Students determine FamilyName

(or FamilyName depends on Students)

Each student has exactly one family name, but the name could be the name of many students.

So FamilyName does not determine Student# e.g. “Smith is the name of students 1 and 3

Students FamilyName

Data elements of interest are Student# and FamilyName.

58

FDDs ExamplesEmployees and the

departments they work for.Department Name Accounting

Employee Number 11

2

31

Department Name

Sales

Employee Number

45

27

In this example the tables are representing some interesting data of the business. We see that Employees with the ID numbers 11,2 and 31 all work in the Accounting Dept and that Employees with the ID numbers 45 and 27 work in the Sales Dept.

Do you think that you could draw an FDD to represent this? Have a go and then check your answers

Enterprise Rule: “Each employee works on only one department”

59

FDD AnswersEmployees and the

departments they work for.Department Name Accounting

Employee Number 11

2

31

Department Name

Sales

Employee Number

45

27

Employee# DeptName

11 Acc

2 Acc

45 Sales

31 Acc

27 Acc

Data elements of interest are Employee# and DeptName”

Employee# DeptName

So we could make this following Table

60

FDDs ExamplesThe quantity of parts held in a warehouse and their suppliers

Parts Suppliers Name QOH

1 Wang Electronics 23

2 Cumberland Enterprises 80

3 Wang Electronics 4

4 Roscoe Pty. Ltd 58

Part# determines SupplierName & Part# determines QOH

“Parts are uniquely identified by part numbers”“Suppliers are uniquely identified by Supplier Names”

“A part is supplied by only one supplier”“A part is held in only one quantity”

Parts SupplierName

Parts QOH

Should QOH be a determinant? No, common sense tells us that is not a reliable choice. We could have had repeating values

61

FDDs ExamplesStudents and their subjects

enrolled.“Each student is given a unique student

number”

“A subject is uniquely identified by its name”

“A student may choose several subjects”Data element of interest are

Student# and SubjectName

Student

SubjectName

There us no functional dependency here.

Student# does not determine SubjectName,

nor does SubjectName determine Student#

Student SubjectName

1 History

1 Geography

1 Mathematics

1 History

2 English

2 English

3 Mathematics

3 English

4 French

4 Geography

62

FDDs ExamplesResults obtained by each student

for each subject.

“Each student is given a unique student number”

“A subject is uniquely identified by its name”

“A student may choose several subjects”

“A student is allocated a result for each subject”

“Each student has only one name.”

Data elements are

Student#, StudentName, SubjectName and Grade

63

FDDs ExamplesResults obtained by each student for

each subject.Student

Student Name

Subject Name Grade

1 Smith History A

1 Smith Geography B

1 SmithMathematics A

2 Jones History C

2 Jones English C

3 Smith English A

3 SmithMathematics A

4 Andrews English D

4 Andrews French C

4 Andrews Geography CTry and construct an FDD for this table considering the given Business Rules and the Data Elements

64

FDDs ExamplesResults obtained by each student for each subject.

Student # StudentName

We can see that there is only one and only one student name for each student number, even though there might be more than one student with the same name. So….

But the subject grade for any student cannot be determined by the subject name or the student# by itself. A student can have many grades depending on the subject. How can we cater for this?

65

FDDs AnswerResults obtained by each student for each subject.

Student

SubjectName Grade

StudentName

This is called the Composite Determinant

We need to combine the two Elements to say that there is one and only one grade for a student doing a particular subject. Here then is the complete diagram

66

FDDs ExamplesCustomer Orders

Order Part# CustomerName Address

454 12 David Smith 1 John St, Hawthorn

454 23 David Smith 1 John St, Hawthorn

455 32 Emily Jones 45 Grattan St, Parkville



456 12 Mary Ho 44 Park St, Hawthorn

456 54 Mary Ho 44 Park St, Hawthorn

Validating functional dependenciesUsing simple data and populating the table, check there is only one value of

the dependent.

67

FDDs Examples“Orders is uniquely identified by its names”

“Customers are uniquely identified by their names”

“A customer has only one address”

“An order belongs to only one customer”

“A part may be ordered only once one each order”

Order CustomerName

Order Parts Ordered CustomerName Address

454 23, 12 David Smith 1 John St, Hawthorn

455 54, 49, 32 Emily Jones 45 Grattan St, Parkville

456 54, 12 Mary Ho 44 Park St, Hawthorn

Address

Part#

68

FDDs ExamplesEmployees and their tax files

numbers“Each employee has a unique employee

number”

“Each employee has a unique tax file number ”

Employee

TaxFile#

1 1024-5321

2 3456-3294

3 8246-7106

4 8861-6750

5 1234-4765

Employee#

Taxfile# Employee#

Taxfile#

Taxfile# Employee#

Employee# determines taxfile#

Taxfile# determines Employee#

Alternative keys

69

Obtain Tutorial 2 from your tutor.

70

Functional Dependency

DiagramsDatabase Design

Let’s look at the process of converting the FDD into a schema. We have a 12 step process to do so, that has an iterative component to it (loop).The 12 steps are outlined in the next series of slides.

71

Functional Dependency Diagram Preparation

1. Represent each data element as a box.2. Represent each functional dependency by an arrow.3. Eliminate augmented dependencies.4. Eliminate transitive dependencies.5. Eliminate pseudo-transitive dependencies.

By this stage, intersecting attributes should have been eliminated.

72

Deriving 3NF Schema: Synthesis Algorithm

6. Pick any (unmarked) arrow in the diagram.

7.

Follow it back to its source, and write down the name of the source.

S

8.

Follow all arrows from the source data item, and write down the names of their destinations.

S, A, B, C

S is now the key of a 3NF relation (S , A, B, C).

S

S

A

B

C

73

S

A

B

C

U1 U2 U3

Synthesis Algorithm: Deriving 3NF Schema

9. Mark all the arrows just processed.

10. If there are any unmarked arrows in the diagram, go back to step 6.

11. Finally, determine the Universal Key. Any attribute which is not determined by any other attribute (ie. has no arrow going into it) is part of the Universal Key.

12. If the universal key is not already contained in any of the above relations, make it into a relation. The universal key is the key of the new relation.

74

A Fully Worked Example

We will now work from a given set of forms to produce an FDD then use the 12 steps to produce the Schema. The forms that follow show the time spent by a particular employee on a particular project. They contain details of the employee along with details of the project. In addition they also state the hours that the employee has spent on any one project to date. This is important to the FDD. Notice also that the employee can have many previous titles and have a number of skills. This also has to be dealt with in the FDD and then later after we have used the synthesis technique to create the Schema. Have a good look at the forms on the next 2 slides and try to develop the FDD yourself.

75

EMPLOYEE ______________________________________________________________________________________________________________NAME E_NUMBER DEPARTMENT LOCATION CURRENT TITLE PRIOR_TITLES SKILLS_______________________________________________________________________________________________________________Adams 1001 Finance 9th Floor Senior consultant Junior consultant Stock market

Research analyst Investments ______________________________________________________________________________________________________________PROJECTS______________________________________________________________________________________________________________NAME TIME_SPENT P_NUMBER MANAGER ACTUAL_COSTEXPECTED_COST ______________________________________________________________________________________________________________Resolve bad debts 35 26713 Kanter 2000 1500______________________________________________________________________________________________________________

We say that this table is in “zero normal form” (0NF)This is because the cells have multiple values, eg. Prior titles and Skills. The next slide shows forms that demonstrate that an employee can work on many projects.

Personnel Database Forms 1

76

EMPLOYEE __________________________________________________________________________________________________________NAME E_NUMBER DEPARTMENT LOCATION CURRENT TITLE PRIOR_TITLES SKILLS__________________________________________________________________________________________________________Baker 1002 Finance 9th Floor Senior consultant Junior consultant Stock market

Research analyst ______________________________________________________________________________________________________________________PROJECTS__________________________________________________________________________________________________________NAME TIME_SPENT P_NUMBER MANAGER_NUM ACTUAL_COSTEXPECTED_COST __________________________________________________________________________________________________________Res bad debts 18 26713 Kanter 2000 1500__________________________________________________________________________________________________________

________________________________________________________________________________________________________________

EMPLOYEE _________________________________________________________________________________________________________NAME E_NUMBER DEPARTMENT LOCATION CURRENT TITLE PRIOR_TITLES SKILLS_________________________________________________________________________________________________________Clarke 1003 Accounting 8th Floor Senior consultant Junior consultant Stock market

Investments _________________________________________________________________________________________________________

PROJECTS_________________________________________________________________________________________________________NAME TIME_SPENT P_NUMBER MANAGER_NUM ACTUAL_COSTEXPECTED_COST _________________________________________________________________________________________________________New billing system 26 23760 Yates 1000 10000New office lease 10 26511 Yates 5000 5000___________________________________________________________________________________________________________________________

Personnel Database Forms 2

77

TIME_SPENT

EXPECTED_COST

Personnel Database FD Diagram

LOCATION

ACTUAL_COST

MANAGER_NUM

PROJECT_NAME

P_NUMBER

CURRENT_TITLE E_NUMBER

EMPLOYEE_NAMEPRIOR_TITLE

SKILL

DEPARTMENT_NAME

From the forms given we can produce the following FDD

78

EXPECTED_COST

Personnel Database FD Diagram -Synthesis

ACTUAL_COST

MANAGER_NUM

PROJECT_NAME

P_NUMBER

Let us just consider the section of the FDD that looks at the project number as the determinant

By using the synthesis method we can choose an arrow, trace it back to the source, and gather together all of the attributes that the source points to. Try this and see if you can create the schema for this table.

79

LOCATIONDEPARTMENT_NAME

Personnel Database FD Diagram - Synthesis

So the table DEPT(DEPARTMENT_NAME, LOCATION) is created

Again, if we choose another arrow that has not been chosen before and follow it back to the determinant we find DEPARTMENT_NAME is a determinant. Gathering all of the attributes that it points to we only have the location attribute. Hence this is a simple table consisting of DEPARTMENT_NAME as the Primary key and LOCATION as the only other attribute.

80



EMPLOYEE_NAME

DEPARTMENT_NAME

EMPLOYEE (EMPLOYEE_NAME, E_NUMBER, DEPARTMENT, CURRENT TITLE )

Likewise for the section of the FDD based around the E_NUMBER, creating the following table for the Employees details.

81

TIME_SPENT

P_NUMBER

E_NUMBER


Try to create the Assignment table for this part of the FDD.When you think you have it have a look at ours and see if you are right.

Here we have a slightly more complicated one. The Time spent on the project is dependent on both the Project number and the Employee name, as it is the time spent by a particular employee on a particular project. This is demonstrated by the boxing of both the above attributes together pointing to the TIME_SPENT

82

TIME_SPENTP_NUMBER

E_NUMBER

Personnel DatabaseFD Diagram - Synthesis

ASSIGNMENT (E_NUMBER, P_NUMBER, TIME_SPENT)

The main difference here is that when choosing the arrow to follow back to the determinant we find that we have 2. This is OK, we just have to make sure that in the table both of them are the primary Key. We have a Composite Primary Key consisting P_NUMBER and E_NUMBER. When we then gather up all of the attributes that they point to together we get TIME_SPENT. Hence the table is written as

See the composite primary key

83

P_NUMBER

E_NUMBER

PRIOR_TITLE

SKILL

UK (E_NUMBER, P_NUMBER, PRIOR_TITLE, SKILL)

Personnel Database FD Diagram - Universal Key

Now, the last part of the synthesis is often forgotten. We must collect up all of the attributes that do not have arrows pointing into them and place them in the one table called the Universal Key. Every attribute collected then becomes part of the composite Primary Key. In this case we have the following attributes inside the box below. Notice how Skill is there, as it sits by itself. Nothing is its determinant.

84

Foreign Keys In the Synthesis Algorithm, a foreign key will arise from any

attribute that is:

A. both a determinant and part of another determinant, OR

B. both a determinant and a dependent.TIME_SPENT

LOCATION

P_NUMBER

E_NUMBER

DEPARTMENT_NAME


EMPLOYEE (E_NUMBER, DEPARTMENT_NAME)

DEPT(DEPARTMENT_NAME, LOCATION)

A.

B.

85

ISA = Is A

MANAGER_NUM

E_NUMBER

ISA

Every MANAGER value is a E_NUMBER value.

Gives rise to a new Foreign Key

EMPLOYEE PROJECT MANAGER_NUM

In the case of the manager we say that the manager number is contained within the employee number

86


EMPLOYEE (NAME, E_NUMBER, DEPARTMENT, CURRENT TITLE )

PROJECT (NAME, P_NUMBER, MANAGER_NUM, ACTUAL_COST, EXPECTED_COST )

Personnel Database SchemaGenerated by Synthesis

DEPT(DEPARTMENT, LOCATION)

UK (E_NUMBER, P_NUMBER, PRIOR_TITLE, SKILL)

This foreign key is a result of MANAGER

ISA E_NUMBER

87

ASSIGNMENT

EMPLOYEE PROJECT

UK

Personnel Database Network Diagram Generated by Synthesis

E_NUMBER + P_NUMBER

P_NUMBERE_NUMBER

DEPT

DEPARTMENT_NAME

MANAGER_NUM

88

A Fully Worked Example

We now have to take care of the multi-valued areas such as skills and prior titles. Our FDD synthesis takes care of everything up to that. It converts the FDD to what we call “Third normal Form”. We know that an individual can have many skills and many Prior Titles. They can also work on many Projects. Knowing the Employee number will not tell us one and only one value of the Skills that they have. We show this on the extended FDD with a double arrow notation.The notation for such a relationship is shown here where E_NUMBER is a determinant for many values of skill. Consequently the resulting representation shown on the next slide can be constructed, giving rise to the splitting of the UK to form three more relations

E_NUMBER

SKILL

89

E_NUMBER

PRIOR_TITLE

SKILL

MVDs



Personnel DatabaseMultivalued Dependency-Decomposition

P_NUMBER,

ASSIGN (E_NUMBER, P_NUMBER)

MultiValued Dependency

Employees are associated with Projects, Titles and

Skills independently. There is no direct relationship

between Projects, Titles and Skills.

Hence we have the three new relations ASSIGN, PRIOR_JOB and EXPERTISE

90

TIME_SPENT

EXPECTED_COST

Personnel Database FD Diagram with MVDs and Inclusion

LOCATION

ACTUAL_COSTMANAGER_NUM

PROJECT_NAME

P_NUMBER


EMPLOYEE_NAME

PRIOR_TITLE

SKILL

ISA

MVD

DEPARTMENT_NAME

MVD

91




EMPLOYEE (NAME, E_NUMBER, DEPARTMENT, CURRENT TITLE )

PROJECT (NAME, P_NUMBER, MANAGER, ACTUAL_COST, EXPECTED_COST )

Final Personnel Database Schema

DEPT(DEPARTMENT, LOCATION)

Decomposed from

UK

92

ASSIGNMENT

EMPLOYEE PROJECT

PRIOR_JOBEXPERTISE

Final Personnel Database Network Diagram

E_NUMBER P_NUMBERE_NUMBER

E_NUMBER

DEPT

DEPARTMENT_NAME

MANAGER_NUM

93

EXPECTED_COST

Personnel DatabaseFD Diagram - Synthesis

ACTUAL_COST

MANAGER

PROJECT_NAME

P_NUMBER

PROJECT (PROJECT_NAME,P_NUMBER, MANAGER, ACTUAL_COST, EXPECTED_COST )

Choosing any of the arrows and following it back leads you to the project number (P_Number). This is then the Primary Key. If you then gather all of the attributes that P_Number points to and place them in the brackets you get the table Project with P_Number as the primary Key.

94

Role Splitting In Functional Dependency Diagrams

In a Functional Dependency Diagram any group of attributes can be related in only one way. For example, a pair of attributes can be

related by an FD or not. Sometimes data can be related in more one way.

For example, a department can have an employee as its head or as a member.

The member relationship is represented in the FDD:

But the head relationship is represented in the FDD:

E_NUMBER DEPARTMENT_NAME

DEPARTMENT_NAME E_NUMBER

95

Role Splitting In Functional Dependency

Diagrams

We can choose to split the E_NUMBER attribute into E_NUMBER and HOD.

But the foreign key constraint that a Head of Department is an Employee is lost on the FDD.

E_NUMBER DEPARTMENT_NAME

HODISA

EMPLOYEE DEPT

FDD

NetworkD DEPARTMENT_NAME

HOD

Synthesis

96

Role Splitting In FDDs Alternatively, we can choose to split the

DEPARTMENT_NAME attribute into EMPLOYING_DEPT and HEADED_DEPT.

But the foreign key constraint that an Employing Department must be a Headed Department is again lost on the FDD.

E_NUMBER EMPLOYING_DEPT

HEADED_DEPT ISA

EMPLOYEE DEPT

FDD

NetworkDEMPLOYING_DEPT

E_NUMBER

Synthesis

97

Role Splitting Example

Consider this example. We have the Employee with many Skills, Prior Titles, as before but we also have equipment that belongs to a particular employee, such as a computer and a fax. An employee can have many different pieces of equipment. It is worthwhile recognizing them on the diagram and then decomposing them into smaller relations as part of the schema

98

LOCATION


EMPLOYEE_NAME

PRIOR_TITLE

SKILL

DEPARTMENT_NAME

SERIAL# DESCRIPTION

UK

• MVDs not necessarily embodied in the UK.• Better to decompose on MVDs first. • MVDs partition attributes into independent sets.

HOD

ISA

MVDs

Suppose each item of equipment (identified by SERIAL#) belongs to an

employee.

99

Obtain Tutorial 3 from your tutor.

100

ENTITY RELATIONSHIP ANALYSIS

In this area of the course we concentrate an another modelling technique called Entity Relationship Modelling (ERM or ER).

The first stage of this process will look at the following: ER Data Model and Notation Strong Entities Discovering Entities, Attributes Identifying Entities Discovering Relationships

101

Critique of FD Analysis

We originally concentrated on the modelling technique called Functional Dependency Diagrams. They have limitations as follows:

Disadvantages of FDD Does not represents real world objects, but

only data; Cannot represent MVDs or specialization; Cannot represent multiple relationships without

artificial splitting of attributes; Entities fragmented during analysis;

102

Conceptual Data Analysis

By using the ER technique we have the following advantages:

Data Analysis from the User's Point of View Models the Real World Independent of Technology Able to be validated in user terms

103

Entity Relationship Data Model Features

The real value of using this type of modelling is that it considers the design in context to the environment where it comes from. We have these Entities that have there own identifying attributes, real things and real people. They can be observed in the environment. ERM has the following features:

Populations of Real World objects represented by Entities

Objects have Natural Identity Entities have Attributes which have values Entities related by Relationships Constraints Subtypes

104

Occurrences versus Entities

56 28Jack Ackov Jill Hill

Entity OccurrencesEntity InstancesObjects

Let’s consider these two instances. Here we have both Jack and Jill, aged 56 and 23 respectively. By themselves they exist as people in their environment. In this case we consider them to be two customers. If we wish to model them and all of the possible customers that we have we need to create an Entity Class for all possibilities.

105

Occurrences versus Entities

56 28Jack Ackov Jill Hill

CUSTOMER

Customer# CustName

Customer# CustName

5628

Jack AckovJill Hill

CUSTOMER(Customer#, CustName)

Entity OccurrencesEntity InstancesObjectsThese are the Tuples of the table below

Entity ClassesEntity TypesEntity SetsThis will convert to the schema below with Customer# being the Primary Key

106

5628

Jack AckovJill Hill

BikeCup of Tea Pussy Cat23 156 234150 25

3

12

41

Here we have Jack and Jill placing orders for particular items of stock. They appear to order different amounts of each. For instance Jack orders 3 bikes. Each item being ordered also has a Stock#, Price and Description. These are individual instances of the process so we need to be able to represent any possibility of this in our model. See how we do this on the next page.

107

5628

Jack AckovJill Hill

CUSTOMER

Customer# CustName

ITEM

Stock#

ORDERS

DescPrice

Quantity

Bike Cup of Tea Pussy Cat23 156 234150 25

3

124

1

108

Customer# CustName

5628

Jack AckovJill Hill

CUSTOMER(Customer#, CustName)

Customer#

56562828

ORDERS(Customer#, Stock#, Quantity)

Stock# Desc

23156234

BikeCup of TeaPussy Cat

ITEM(Stock#, Price, Desc)Price

50125

Stock#

23156156234

Quantity

31241

Occurrences to Entities to Schemas

109

ENTITIES

Entities are classes of objects about which we wish to store information. Examples are:

People: Employees, Customers, Students,..... Places: Offices, Cities, Routes, Warehouses,... Things: Equipment, Products, Vehicles, Parts,.... Organizations: Suppliers, Teams, Agencies, Depts,... Concepts: Projects, Orders, Complaints, Accounts,...... Events: Meetings, Appointments.

STRONG

WEAK

110

STRONG ENTITIES

An entity is Existence Independent if an instance can exist in isolation. For example, CUSTOMER is existence independent of

ORDER, but ORDER is existence dependent on CUSTOMER. The ORDER is by a particular customer for a/many particular item(s)

An entity is identified if each instance can be uniquely distinguished by its attributes (or relationships). For example, CUSTOMER is identified by Customer#,

PERSON is identified by Name+Address+DoB, ORDER is identified by Customer#+Date+Time.

111

An entity is STRONG if it can be identified by its (own) immediate attributes. Otherwise it is weak. For example, CUSTOMER and PERSON are strong entities,

but ORDER is weak because it requires an attribute of another entity to identify it. ORDER would be strong if it had an Order#.

Existence independent entities are always strong.

STRONG ENTITIES

112

The Method: How to Develop the ERM

Step1: Search for Strong Entities and Attributes Step2. Attach attributes and identify strong entities. Step3. Search for relationships. Step4. Determine constraints. Step5. Attach remaining attributes to entities and relationships. Step6. Expand multivalued attributes, and relationship attributes. Represent attributed relationships and/or multivalued

attributes in a Functional Dependency Diagram.

Step7. Identify weak entities. Step8. Iterate steps 4,5,6,7,8 until no further expansion is possible. Step9. Look for generalization and specialization; Analyze Cycles;

Convert domain-sharing attributes to entities.

113

Narrative&

Forms

1Search for

strong entitiesand attributes

Entities

Attributes

3Search for

relationships

Relationships

2Identifystrongentities

Strong entities

4 & 5Determine

constraints andattach attributes

Entity-RelationshipDiagram6

Expand attributedrelationships and/or

multivalued attributes

Weak Entities

7Identify

weak entitiesIdentified

weak entities

6’Represent attributed

relationships and/or multivalued attributesas Functional Dependencies

FunctionalDependency

Diagrams

The Method

The Method

114

Step1: Search for Strong Entities and Attributes

1 Entities relevant nouns many instances have properties (attributes or

relationships) identifiable by properties

2 Strong Entities independent existence identifiable by own single-valued

attributes• 3 Attributes– printable names,

measurements– domain of values– no properties– dependent existence

115

Narrative

A worked example finding strong Entities

A customer is identified by a customer#. A customer

has a name and an address. A customer may order

quantities of many items. An item may be ordered by many customers. An item is identified by a stock#. An item has a description and a price. A stock item may have many colours. Any

item ordered by a customer on the same day is part of

the same order

Here we have a scenario. Try to firstly identify all of the strong entities followed and all of the attributes. Can you also identify a weak entity? Are there any attributes that you have missed?

116

Worked Example Continued

Let us take and place it around the nouns. These lead us to what we will consider to be the strong entities. If we then place the around items that we think would be the attributes, we can see if if any of the identified Entities are strong. You will notice that the item has a description, price, colour and stock # and a customer has a customer number, name, and address. These a Existence Independent Entities, and hence they must be strong.

Narrative

A customer is identified by a customer#. A

customer has a name and an address. A

customer may order quantities of many

items. An item may be ordered by many

customers. An item is identified by a stock#.

An item has a description and a

price. A stock item may have many

colours. Any item ordered by a customer

on the same day is part of the same order

117

Conceptual Schema

CUSTOMER ITEM

Description

Address

Price

Quantity

Customer#

Stock#

Customer Name

Date

ORDERColour

Worked Example Continued

We have our Entities and the attributes displayed before us. Customer and Item are strong entities as they are Existence Independent. What about Order?

Order cannot be identified completely by any of its own attributes. It is dependent on the attributes of the other 2 entities to be identified. An order is made up of a customer ordering an item. We need the customer# and the item# to identify the order

118

Step2. Identify Strong Entities.

Conceptual Schema

ITEMCUSTOMER

Customer#Price

AddressCustName

Stock#

Desc

Colour

DateQty

Both Customer and Item have what we call a Natural Identity

We now attach the attributes that belong to each of the Strong Entities. Notice that there are some left that belong to neither Customer or Item. We will look at this later.

119

Another Example of the Difference Between Weak and

Strong Entities

Here is another example of a common occurrence that demonstrates the difference between a strong entity and a weak entity

A strong entity is identified by its own attributes. Bidders make purchases of goods at the auction.

BIDDER and a GOOD have independent existence, hence are strong, but PURCHASE requires attributes of BIDDER and GOOD. The Purchase is the identified by the Bibbers name and the Goods description. These are 2 attributes that belong to both the Bidder and the Good respectively.

120

Additional Rules for Entities

For an Entity to exist we have the following additional rules: There must be more than one instance of an entity.

The company provides superannuation for its workers.Here there is only one instance of COMPANY so it is

not a valid entity.We do not model anything that only has one instance

Each instance of an entity must be potentially distinguishable by its properties. Members send five dollars to the association.

A dollar does not normally have distinguishing attributes.

121

Step3. Search for Relationships.

We can now identify Relationships that have the following properties: Relationships

Have associate entities Are relevant

must be worth recording Can be"structural" verbs in the narrative

persistent, rather than transient relationships Can be "abstract" nouns in the narrative

nonmaterial connections, eg. Enrolment Can be verbalizable in the narrative

eg. Student EnrolledIn Unit Have 2 (binary)or more associated entities.(3-Ternary, up to n-ary

for n associated entities)

122

Relationships:

A relationship must be relevant. It should indicate a structural, persistent (extending over time) association between entities. Students enrol in units selected from the

handbook. A relationship should not usually indicate a

procedural event (one that occurs momentarily, then is forgotten.). Students read about units selected from

the handbook.

123

Relationships and the Worked Example.

Conceptual Schema

ITEMCUSTOMER

Customer#Price

AddressCustName

Stock#

Desc

Colour

DateQty

ORDERS

We can now deal with the order. The order is a relationship between the Customer and the Item. It is for a set Quantity on a given Date.

124

Second Worked Example: The Agent

Analyze the data kept by the agent. Identify the entities, attributes and the relationships. To start with look at the nouns.Customers may order products stocked by various suppliers through the agent. The agent maintains a catalogue of what products are available from suppliers. The price of a product may depend on the supplier. Some products come in a variety of colours independently of supplier. Suppliers ship directly to customers and notify the agent only of the date and total. Customers then pay each supplier through the agent. The agent keeps records of all orders and payments, but is not interested in maintaining detailed invoice lines.

125

Second Worked Example: The Agent

The nouns are Customers may order products stocked by various suppliers through the agent. The agent maintains a catalogue of what products are available from suppliers. The price of a product may depend on the supplier. Some products come in a variety of colours independently of supplier. Suppliers ship directly to customers and notify the agent only of the date and total. Customers then pay each supplier through the agent. The agent keeps records of all orders and payments, but is not interested in maintaining detailed invoice lines.

We have Customers, Products, Suppliers and an Agent. How many Agents are there. This is the Data for the Agent. There is only one instance. Hence we do not model it.

126

The Agent:Additional Information

Customer#:Customer Name:

28 Date:Jill Hill

28 Fullview Lane, Glenvale

Oct 3, 1996

Stock# Description Qty156 Cup of Tea 4234 Pussy Cat 2

Manufacturer:Address:

Hill Creat Industries23 Highhill Blvd, Sumpend

Stock# Description Price156 Cup of Tea 1234 Pussy Cat 25

Manufacturer:Address:

Hill Creat Industries23 Highhill Blvd, Sumpend

Customer#:Customer Name:

28 Shipment Date: Oct 9,Jill Hill

1996

Total 54

These forms can tell us more information about the way the business runs.

127

The Agent:Additional Information

• Notice that the forms also tell us the following additional facts:

• A Customer has a Cust#, Name and Address. The Supplier has a Name and Address and the stock has a Stock#, Description and Price.

• An order is made on a Date and is for the one Customer for many items. It also has the number of each item ordered.

• The shipping docket has the Date of shipping, both the Customers and Suppliers details along with the total price of the goods delivered.

• Try yourself to represent this in a diagram with the strong entities and the relationships between them.

128

CUSTOMER

SUPPLIER

PRODUCT

Stock#{Colour}

Tradename

NameAddress

The Agent: Strong EntitiesThe Strong Entities

Each of the Entities below are strong. They have a Natural Identity and are Existent Independent. They are completely identifiable by their attributes

Address

Cust#

129

CUSTOMER

SUPPLIER

PRODUCT

Qty

Price

Stock#{Colour}

Tradename

NameAddress

ORDERS

AVAILABLEFROM

ERDiagram

The Agent: RelationshipsThe Customer orders a Quantity of a particular product. All products are supplied from a Supplier at a price.

Address

Cust#

130

CUSTOMER

SUPPLIER

PRODUCT

Date

Total

Paydate

Amount

Qty

Price

Barcode{Colour}

Tradename

NameAddress

ORDERS

RECEIVEDFROM

AVAILABLEFROM

PAIDERDiagram

The Agent: Final SolutionThe Product is shipped from the Supplier to the Customer on a Date with a total cost for the goods, and the Customer pays the Supplier on a Date an amount (which could be the amount for a number of shipments)

131

Entity Relationship Analysis 2

We will now concentrate on the following areas of good ERM Cardinality and Participation Constraints Expanding to Weak Entities Identifying Weak Entities Derived Attributes and Relationships Ternary Relationships

132

These are Steps 4,5 & 6 from the Original Diagram

Relationships

Strong entities

4 & 5Determine

constraints andattach attributes

Entity-RelationshipDiagram

6Expand attributed

relationships, domain sharing &

multivalued attributes

Weak Entities

7Identify

weak entities

Identifiedweak

entities

Unattched AttributesUnidentifiedweak

entities

133

Step4. Determine constraints: Cardinality(How many participate

CUSTOMER ITEMORDERS

To complete this we “fix a single instance at one end and ask how many (one or many) are involved at the other end”.Look at the relationship where the Customer Orders an Item. Consider a single Customer. Can they order many items at the one time? Yes We have seen this. So we position a crows foot (<) at the point where the line touches the Entity Item. We then ask if an Item can be ordered by many Customers? Yes So agin we place a crows foot at the Customers end.

From left to right-A Cust can order many Items

From right to left- An Item can be ordered by many Cust

134

Step4. Determine constraints: Cardinality.

CUSTOMER

Again to complete this task we “Fix a single instance at one end and ask how many (one or many) are involved at the other end”. All of the Customers live in a City. A Customer can only live in one City(unless they are politicians) In this case we must place a single straight line (|) at the intersection of the relationship line and the Entity City. However, a city can have many Customers. We show this by placing crows foot (>) at the end near the Customer

CITY

LIVES IN

135

Step4. The Resulting ER with the Cardinality Constraints in Place

CUSTOMER ITEMORDERS

Many CUSTOMERs can ORDER an

ITEM.Many

ITEMs can be

ORDERed by a

CUSTOMER.

CITY

LIVES INMany CUSTOMERs can LIVE IN a

CITY.

A CUSTOMER can LIVE IN only one

CITY.

{Colour}

An ITEM can have

many Colours.

136

Step4.Determine constraints: Participation.

CUSTOMER ITEMORDERS

Again, we “Fix a single instance at one end and ask if any must (might or must) be involved at the other end”.We ask “Does the Customer have to order an Item? Well, some would say that they do not they are not Customers! But we know that we must be able to recognise our Customers even though at present they do not have an order with us. So, in this case they do not have to place an order. This is then not mandatory, and we show it by placing the O beside the cardinality constraint. An Item does not have to be on an order as well, so it also gets the O notation.

137

Step4.Determine constraints: Participation.

CUSTOMER

CITY

LIVES IN

This is also the case for the Customer living in the City. Does the customer have to live in the City? In this case Yes, as we class all areas as being within a City. Hence we place the “|” symbol beside the cardinality constraint next to the Entity City. The next one is difficult. Does a City have to have a Customer living in it. You might think No here, but are you prepared to record all of the cities in the world just to make sure? Common sense tells us that we have to make this mandatory so we only keep a record of the cities where our Customers live.

138

Step4. The Resulting ER with the Participation Constraints in Place

CUSTOMER ITEMORDERS

An ITEM might be ordered by a CUSTOMER.

A CUSTOMER might order a

ITEM.

CITY

LIVES IN A CITY must have a CUSTOMER

LIVing IN it.

A CUSTOMER must LIVE IN a

CITY.

139

Step4. Determine constraints: Validation by Population.

CUSTOMER ITEMORDERS

CITY

LIVES IN

Cust#

Stock#

CityName

{Colour}An important method of evaluating the proposed model is to populate with instances that demonstrate that the constraints that you have identified will work.

140

Step4. Tables Created to Validate

CUSTOMER ITEMORDERS

CITY

LIVES IN

Cust# Stock#122312

13

77778899

CityName Cust#AyrAyrTully

122313

Cust#

Stock#

CityName

{Colour}

ColourStock#PinkBlue

7777

141

Step5. Attach remaining attributes to entities and

relationships.In the previous lectures we looked at a worked problem with a Customer ordering an Item. Here we were able to identify Entities from the narration. Next we also listed the attributes which helped us identify the Strong Entities. We noticed that there were some Attributes, Qty and Date, left that could not be attached to any of the strong entities. They, in fact, belong to the Relationship that was associated with the two Entities.

ITEMCUSTOMERCustomer#

Price

AddressCustName

Stock#

Desc

Colour

DateQty

ORDERS

142


relationships.

The quantity attribute cannot be attached to the Customer, as the Customer will order different quantities of various items at any time. It cannot also be attached to the Item. It must therefore be attached to the relationship between them, being the order. This is also the situation for the Date that the order was placed.

143


relationships.

Conceptual Schema

ITEMCUSTOMER

Customer#Price

AddressCustName

Stock#

Desc

{Colour}DateQty

ORDERS

144

Step6.Expand multi-valued attributes, domain sharing attributes and binary

relationship attributes.

Once we have identified the Strong Entities, Relationships and attached all Attributes to either the Strong Entities or Relationships, we are required to expand the diagram as much as possible to permit us to complete the process. This requires us to move in 2 directions. We must first look at all of the binary relationships to see what the cardinality constraints are between them. If they are “many-to-many” they must be carefully considered and expanded where appropriate.

We then must look at what we call Multi-valued Attributes and Domain Sharing Attributes. The process is shown on the following diagram.

145

Step6 Entity-RelationshipDiagram

Expand relationships

with attributes

Dependent Entities

Many-to-many Relationships with Attributes

Multi-valued AttributesDomain Sharing Attributes

ExpandMulti-valued anddomain sharing

attributes

Characteristic EntitiesAssociative Entities

146

Conceptual Schema

ITEMCUSTOMER

Customer#

Price

AddressCustName

Stock#

Desc

{Colour}DateQty

ORDERS

Step6

In the worked example we have a Many-to-Many relationship with 2 attributes . When we have a Many-to-Many relationship with attached attributes we are required to create an Associative Entity that bridges the 2 Entities.

147

ITEMCUSTOMER

Customer#

Price

AddressCustName

Stock#

Desc

Date

Qty

ORDERMAKES FOR

Associative Entity

Step6

Between Customer and Item we create the Weak (Associative) Entity called Order. We have to redo the constraints. A customer can place many orders or none. An order can come from only one customer, and must be from a customer. An order is for many items and must be for at least one item, and an item can be on many orders but does not have to appear on an order. These have all been placed in the diagram shown below in their correct position.

148

ITEMCUSTOMER

Customer#

Price

AddressCustName

Stock#

Desc

Colour

Date

Qty

ORDER

COLOUR

MAKES FOR

HAS

Associative Entity

Characteristic Entity

Step6

We have also noticed that an item can come in many colours. This is a multi-valued attribute. We can show this in our extended diagram by having a relationship between the Item and the Colour, where colour is the only attribute of the entity. In this case we are also saying that the colour of the item is optional (IE natural if requested) and that the only colours to be recorded are those that are used.

149

Step6. Expand domain sharing attributes.

Managers supervise Workers. All employees are residents of a City. Employees who live in different cities from their managers get a special allowance.

MANAGER WORKERSUPERVISES

City City

Allowance

MANAGERSUPERVISES

CityName

Allowance

CITY

OF OF

WORKER

Characteristic Entity

150

Step7. Identify weak entities. Clarify the notion of instance.

Weak entities are often ambiguous and difficult to agree on.

Attributes may be part of a key for a weak entity, but at least one (one-must) relationship for identification is required. So when we convert this into a table it will require one of the PKs from the strong entities as part of its own composite PK.

Validation, not design.The purpose of identification is not to allocate a

primary key, but to validate the concept. We have to be able to justify the concept of the relationship in the real world.

Never invent keys. I know that it is tempting but you must reflect the business as it is.

151

Step7. Identify weak entities.

Conceptual Schema

ITEMCUSTOMER

Customer#

Price

AddressCustName

Stock#

Desc

Colour

Date

Qty

ORDER

COLOUR

MAKES

FOR

HAS

An ORDER is uniquely identified by the CUSTOMER and the Date.

152

Step7. Identify weak entities.

Conceptual Schema

ITEMCUSTOMER

Customer#

Price

AddressCustName

Stock#

Desc

Colour

Date

Qty

ORDER

COLOUR

MAKES

FOR

HAS

Here we still have the relationship between Order and Item that is many to many with attributes. We must expand this.

153

Step8. Iterate until no further expansion is possible.

Conceptual Schema

ITEM

CUSTOMER

Customer#

Price

Address

CustName

Stock#

Desc

Colour

Date

Qty

ORDER

COLOUR

MADE BY

FOR

HAS

ORDERLINEHAS

An ORDERLINE is identified by an ITEM on an ORDER.

An intersection entity is one that is identified by only by its relationships.

We introduce the weak entity orderline that for one item. It is fully dependent on the attributes of Order and Item to be identified

154

Step8. Iterate until no further expansion is possible.

Ultimately every attribute must be single valued and attached to an entity.

Different development paths are possible. Your model could be different than mine depending on your research and your interpretation of the business.

Retract intersection entities. Even though we just showed you how to expand them in actual fact as they are fully dependent on the attributes of the surrounding entities you just retract them or ignore them. The conversion from ERM to the Schema will take care of everything.

155

WARNING: Forms are not Entities

Forms contain attributes from many different entities. Forms are part of an already existing Information

System and are not necessarily part of the new system that is looking at the entities.

Forms are requirements documents, so can be analysed according to the Method.

Forms are often not identifiable and contain information about many weak entities.

The problem is that when people see forms they want to produce a table. This is not always the case. Many forms that you see in the workplace are reports. They have been derived by different pieces of information. That is part of the functionality of a good database management system.

Remember that:

156

Derived Attributes

Attributes can sometimes be derived from other attributes by calculation.

Each product has a wholesale price and a retail price. There is always a 20% markup.

PRODUCT Wholesale Price

Barcode

Retail Price *

157

Derived Relationships

• Relationships can sometimes be logically derived from other relationships. Consider this situationA student is enrolled in a unit and each

unit belongs to a course

STUDENT

UNIT

COURSE

STUDIES OFFERED IN

158

Derived Relationships

• Now in addition place this in the picture.

A student enrolled in a unit must be enrolled in the course offering the unit.

• Retain derived relationships that bear constraints. This information needs to be kept and not taken out as repeating, due to its constraints

STUDENT

UNIT

COURSEENROLLED IN *

STUDIES OFFERED IN

159

TERNARY RELATIONSHIPS

In some situations the relationships that hold together entities are quite complex. In most cases they are binary and a simple bi-polar positioning will work. It is when we have to hold three or more entities together that things can get quite complicated.

Let us look at a situation that requires a Ternary relationship to be used.

An Employee may be assigned to many projects. An employee may have many skills, but an employee may use only one skill or a particular project. A project may require several skills and several employees.

160

TERNARY RELATIONSHIPS: Example

EMPLOYEE

PROJECT

SKILLQUALIFIED IN

WORKS ON

REQUIRES

Three binary relationships cannot

represent the fact that a particular employee

uses a particular skill on a particular project.

161

EMPLOYEE

PROJECT

SKILL

TERNARY RELATIONSHIPS:Cardinality Constraints

Many employees may use a skill on a project.

An employee may useonly one skill on a project.

An employee may use a skill on many projects.

162

For a ternary to be valid all associated binaries must be many-to-many.

TERNARY RELATIONSHIPS:Rule for Existence

163

The Agent RevisitedDo you remember this problem that we had

previously?

Customers may order products stocked by various suppliers through the agent. The agent maintains a catalogue of what products are available from suppliers. The price of a product may depend on the supplier. Some products come in a variety of colours independently of supplier. Suppliers ship directly to customers and notify the agent only of the date and total. Customers then pay each supplier through the agent. The agent keeps records of all orders and payments, but is not interested in maintaining detailed invoice lines.

We modelled it as demonstrated on the next slide

164

CUSTOMER

SUPPLIER

PRODUCT

Date

Total

Paydate

Amount

Qty

Price

Barcode{Colour}

Tradename

NameAddress

ORDERS

RECEIVEDFROM

AVAILABLEFROM

PAIDERDiagram

Example: The Agent, original simple solution

Now we need to expand it.

165

CUSTOMER PRODUCT

Qty

Barcode

{Colour}

NameAddress

Example: The AgentExpanded ER Diagram

ORDERMAKES FOR

Date

COLOUR

Let us first look at the relationship between the customer and the product. We see that it is a many to many relationship with attached attributes (QTY). It must then be expanded. We do this by creating the weak entity Order which is identified by the date and the customers name. We do not bother introducing the orderline weak entity as it is only identifiable by the attributes of the surrounding entities

166

SUPPLIER

Date

Total

Paydate

Amount

Tradename

Example: The Agent

SHIPMENT

PAYMENT

RECEIVES

FROM

TO

PAID

CUSTOMER

NameAddress

Consider the relationship between the customer and the supplier. Here we have 2 many to many relationships that have to be expanded. They create the weak entities payment and shipment as detailed below, with the attached attributes. Also, they have new constraints with them that show us the identifying attributes that belong to them.

167

SUPPLIER

Price

Tradename

Example: The Agent

HOLDING

HAS

IN

PRODUCT

Barcode

{Colour}

COLOUR

Finally we have to consider the relationship between the supplier and the product. Here we again have a many to many that requires expanding, creating the weak entity Holding, identified by attributes from both the product and the supplier with its own attribute price. This is because different suppliers supply the goods at different prices.

168

Example: The AgentThe final solution

In the end we have to combine all of these sections together to create the final ERM diagram for this problem

169

SUPPLIER

Date

Total

Paydate

Amount

Price

Tradename

Example: The AgentThe final solution

SHIPMENT

HOLDINGPAYMENT

RECEIVES

FROM HAS

IN

TO

PAID

CUSTOMER PRODUCT

Qty

Barcode

{Colour}

NameAddress

ORDERMAKES FOR

Date

COLOUR

171

What is Normalisation

A process that ensures that each attribute is attached to the correct entity

A process of grouping data elements into tables representing entities and their relationships

An integral part of a design method that produces flexible and reliable databases

172

Why Normalise Data?

Minimises data redundancy The only “redundancy” is the foreign key linking data This isn’t redundancy as the link has to be defined in

some fashion Most stable form to change Most robust structure Most adaptable and flexible structure

173

Normal Forms

Introduced by E.F.Codd, there were originally three normal forms (The abbreviation is NF)These are sufficient for nearly all DB’s

In addition there are Boyce-Codd, 4th, 5th and domain-key normal forms. These are rarely required and will not be covered in this course.

174

Primary Keys

An attribute (or group of attributes) that uniquely identifies a particular record in a relation

EMPLOYEE(Employee#,Name,Salary, Department#)ORDER_ITEM(Item#, Order#, Quantity)STUDENT(Stud No, Name(subcode,stitle,result))

Primary key is underlined

175

Foreign Keys An attribute in one relation (table) that

is the primary key in another relation

EMPLOYEE(Employee#, Name, Salary, Department#)

DEPARTMENT(Department#, Dname, Budget)

TOUR(Tourcode, Tname)

BOOKING(Booking#, Seats, Tourcode, Depdate)

Foreign Keys

176

First Normal Form (1)

Consider the problem posed by the entity

Entering data we might obtain

How long should the record be?

STUDENT(Stud No, Surname(Subcode, Subname, Result))

“Repeating Group”

177

First Normal Form (2)

To convert the entity to 1st normal form (1NF) remove any repeating groups of data items from the unnormalised data

EACH RECORD MUST HAVE THE SAME LENGTH

STUDENT(Stud No, Surname(Subcode, Subname, Result))

Repeats a varying number of times,depending upon how many subjectsthe student is enrolled in

178

Converting to 1NF

1.Remove the repeating group and make a new relation/entity

2.The ‘new’ relation now gets a concatenated primary key, which is made of the primary key of the original relation and the “primary” key of the repeating group

3.Give the new relationship a descriptive name

179

1. Remove the Repeating Group

To convert our relation

STUDENT(Stud No,Surname(Subcode,Subname,Result))

Remove the repeating group and state it as a separate relation

STUDENT(Stud No, Surname)(Subcode, Subname, Result)

180

2. A Concatenated Primary Key

STUDENT(Stud No, Surname)

(Subcode, Subname, Result)

Give the new (unnamed) relation a primary key consisting of the primary key of the original relation and the key of the repeating group

STUDENT(Stud No, Surname)(Stud No,Subcode, Subname, Result)

181

3. Name the New Relation

STUDENT(Stud No, Surname)(Stud No, Subcode, Subname, Result)

Give the new relation a descriptive name

STUDENT(Stud No, Surname)

SUBJECT(Stud No,Subcode, Subname, Result)

182

In First Normal Form (1)

So in first normal form (1NF) the original relation:

STUDENT(Stud No,Surname(Subcode,Subname,Result))

has become a pair of relations

STUDENT(Stud No, Surname)SUBJECT(Stud No, Subcode, Subname, Result)

183

In First Normal Form (2)

184

First Normal Forms - Examples

Change to first normal form EMPLOYEE(Employee#,

EmpName,Salary(Proj#.projname)) ORDER(Order#,Orderdate(Part#,NumberOrdered

))

Answers EMPLOYEE(Employee#, EmpName,Salary)

PROJECT(Employee#,Proj#,Projname)

ORDER(Order#,Orderdate)PART(Order#,Part#,NumberOrdered)

185

Second Normal Form

Consider the following relation and the problems presented when creating, deleting, or updating a record

186

Problems Creation

A new item “9999 - washer” cannot be added to the DB until it has been ordered

Also there could also a different description for the same item in a different row. Eg “9870 - 5cm nut”

Deletion If order 40 is the only order for nails, deleting it

will lose the item# and desc from the DB Update

If the item description for item 9870 is amended to “octagonal nut” then it must be changed in many places

187

Second Normal Form Must firstly be in 1NF A non-key attribute cannot be identified by

part of a composite key:Order-item(Order#,Item#,Desc,Qty)

The quantity ordered is functionally dependent on the whole of the primary key, the order # and the item# Order-item(Order#,Item#,Desc,Qty)

The description of the item, however, doesn’t depend on the whole key. It only depends on item#

188

Converting to 2NF

To convert a relation to second normal form

1.Write down all the possible “combinations” of the attributes forming the primary key.

2.Place each of the other attributes with the appropriate combination

3.Remove any relations that consist of a single attribute primary key alone

4.Give each remaining relation a descriptive name

189

1. Possible Primary Keys

To change our relation Order-item(Order#,Item#,Desc,Qty) into 2NF

Write down all possible “combinations” of the attributes forming the primary key:(Order#(Item#(Order#,Item#

190

2. Matching the Other Attributes

Order-item(Order#,Item#,Desc,Qty) Match each of the other attributes with the primary

key that depends upon

(Order#)(Item#, Desc)(Order#, Item#, Qty)

191

3. Remove Trivial Relations4. Name Relations

Remove any relations that consist of a single attribute primary key alone: (Order#)(Item#, Desc)(Order#, Item#, Qty)

Give the remaining relations meaningful names:ITEM(Item#,Desc)ORDER-ITEM(Order#,Item#,Qty)

192

In Second Normal Form(1)

Order-item(Order#,Item#,Desc,Qty)in second normal form has become

ITEM(Item#,Desc)ORDER-ITEM(Order#,Item#,Qty)

193

In Second Normal Form(2)

This solves the problems highlighted earlier ADD new item at any time DELETE last order for item, but item remains in

DB to UPDATE, desc only needs to be altered in one

place

194

Second Normal Form - Summary

Must first be in 1NF

Each attribute in a relation must be functionally dependent on the whole of the primary key

ie Every attribute needs the full primary key and not just parts of it

195

Second Normal Form - Examples(1)

Convert to second normal formQ1.TRAINING(Emp#,EmpName,Dept#,Course,DateComp

leted)

Q2.ORDER-ITEM(Order#,Item#,Date-ord,Qty,Unit-price)

A1. EMPLOYEE(Emp#,EmpName,Dept#)TRAINING(Emp#,Course,DateCompleted

A2. ORDER(Order#,Dat-ord)ITEM(item#,unit price)ORDER-ITEM(Order#,item#.Qty)

196

Second Normal Form - Examples(2)

Convert to 2NFEMPLOYEE(Emp#,Dept#,Ename,Salary)

Answer This is already in 2NF Any relation in 1NF that has a single attribute as

the primary key must be in 1NF as it cannot be dependent on only a portion of the key.

197

Third Normal Form

Consider the following relation ( which is in 2NF) and the problems when CREATING, DELETING or UPDATING a record:

198

ProblemsCREATION

Cannot add a new course until a student is enrolled

There is nothing in the design that stops a course having various names in different recordseg “A112 - DOT(C)”

DELETION Date for a course is lost when last student

enrolled in the course is deletedUPDATE

If the course name changes , it must be altered in many places

199

Third Normal Form Must be in 2NF A non-key attribute cannot be dependent on another

non-key attribute. (This is known as transitive dependency)

STUDENT(Student#,Sname,CourseCode,CourseName)

Sname & CourseCode are both dependent on on Student #

STUDENT(Student#,Sname,CourseCode,CourseName)

CourseName, however is dependent on CourseCode But CourseCode is a non-key attribute.

200

Converting To 3NF

1.Remove all attributes that are dependent on non-key attribute(s) into a new relation

2.Make a non-key attribute(s) that the removed attribute(s) are dependent on, the primary key of the new relation.

3.Give the new relation a descriptive name.

201

1. Remove the Attributes

To convert our relationSTUDENT(Student#,Sname,CourseCode,CourseName)

into 3NF: Remove all the attributes that are dependent upon

a non-key attribute.STUDENT(Student#,Sname,CourseCode)(CourseName)

202

2. Add the Primary key3. Name the New Relation

Make the non-key attribute that the removed attributes were dependent on, the primary key in the new relation.STUDENT(Student#,Sname,CourseCode)(CourseName)

Give the new relation a meaningful nameSTUDENT(Student#,Sname,CourseCode)COURSE(CourseCode,CourseName)

203

Third Normal Form

This solves the problems highlighted earlier ADD new course at anytime DELETE last student in course and the course

will still remain To UPDATE, course name only needs to be

altered in one place

204

Third Normal Form - Summary

Must be in 2NF (and hence in 1NF)

Each attribute in a relation must be dependent on the primary key only and not any other non-key attributes

205

Third Normal Forms - Examples

Convert to 3NFQ1.EMPLOYEE(Emp#,EmpName,Dept#,DeptName)

Q2.CUSTOMER(Customer#,Cname,Caddress,SalesRep,Sname)

AnswersQ1. EMPLOYEE(Emp#,EmpName,Dept#)

DEPARTMENT(Dept#,DeptName)

Q2. CUSTOMER(Customer#,Cname,Caddress,SalesRep)

SALESREP(SalesRep,Sname)

206

Incorrect Decompositions

Groupings of attributes that do not follow the rules of normalisation we have looked at result in: less flexible databases databases that lose data, or require major

alterations in their data, when creation, deletion or updating of records takes place

207

The Normal Forms - Summary

First Normal Form (1NF) The relation contains no repeating groups

Second Normal Form (2NF) The relation is in 1NF and each attribute in

the relation is functionally dependent on the whole key

Third Normal Form (3NF) The relation is in 2NF and each attribute in

the relation is functionally dependent on nothing but the key.

208

A Simple Test for 3NF

Each attribute should depend on

(the original ideas behind relational DB’s were proposed by Dr E.F.Codd)

The key,the whole keyand nothing but the key

(so help me Codd)

209

Data Dictionaries A data dictionary is a structured analysis

tool that records every data name and defines, precisely, what is meant by that name.

Sometimes they are referred to as a metadata(ie data about data)

All the objects (data flows, data stores, processes, data elements etc) identified during analysis should be defined in the dictionary

It may also, optionally, include physical information about the method of data storage, etc

210

Aliases Sometimes a data element in a system

may be referred (known) by more than one name the accounts department calls it

customer_payment the sales department knows it as

customer_owing

To avoid problems occurring because of multiple names for one item, a data dictionary should list any aliases (other names) by which the data is known

211

Sample Entry 1

Data Name: Student_ID

Description: Unique identifier of students

Data Type: Text(7)

Values: Text field of 7 digits with the first two digits signifying the current year.

Aliases: Student_Number, Student#

Where used: Administration, Student_Records

212

Scope of Course

The course will not be focussing on aliases or “Where used”

The following slides shows examples of listings expected in this course

213

Sample Entry 2

Data Name: Skill_Level

Description: A code representing the level of skill of an employee

Data Type: Text(2)

Values: Represents the number of years experience of employee1 = 1 year experience2 = 2 years experience, etc

214

Sample Entry 3

Data Name: Budget_Amount

Description: Amount set aside for each budget item

Data Type: Currency

Values: All amounts multiples of $100

Database Design E R 2009

Business

Transcript of Database Design E R 2009