Database Design Fdd 2009

1

Database Design FDD

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.

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

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

7

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

8

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

9

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

10

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

11

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




12

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


13

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.








14

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


15

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

16

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

17

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

18

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

19

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

20

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

21

Example of Data Redundancy (1)

22


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

23


24


Data redundancy results in: wastage of storage space by recording

duplicate information

difficulty in updating information

inaccurate, out-of-date data being maintained

25

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

26

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

27

Network Diagrams

28

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.

29

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

30

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?

31

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.

32

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

33

Summary: Questions

What is a Relational Database?

What is a relation?

What are Constraints?

What is a Schema?

What is a Network Diagram and why is it used?

34

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)

35

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.

36

Answer

Supplies

Supplier Part

Uses

Product

37

Show the foreign keys on the network diagrams

Orders

Customer

SalesRep

Part

Ordnum ordDate custNumb12489 2/9/91 124

custNumb custName Address Balance credLim Slsnumber

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

38

OrLineordNum Part date quotePrice

39

Answer

Orders

OrLine

Part

Customer

SalesRep

SlsNumber

CustNumb orLine

Part

40

Activities

What problems many arise from this table? What data redundancies are there? What changes would you make? (hint make

another table. What if I wanted to search by surname?

41

Activities

What is wrong with this table?

42

Functional Dependence FDD

43

Functional Dependency Diagrams

A FUNCTIONAL DEPENDENCY DIAGRAM is a way of

representing the structure of information needed tosupport a business or organization

It can easily be converted into a design for a relational

database to support the operations of the business.

44

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

45

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:

46

Enterprise Rules

What are Enterprise / Business 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.

47

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.

48

Functional Dependency Diagrams

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

49

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

50

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

51

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

52

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

53

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?

54

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.

55

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”

56

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

57

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

58

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

59

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

60

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

61

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?

62

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

63

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 dependencies

Using simple data and populating the table, check there is only one value of the dependent.

64

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#

65

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

66

Obtain Tutorial 1 from your tutor.

67

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.

68

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.

69

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

70

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.

71

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.

72

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

73

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

74

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

75

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.

76

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.

77



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.

78

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

79

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

80

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.

81

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.

82

ISA = Is A

MANAGER_NUM

E_NUMBER

ISA

Every MANAGER value is a E_NUMBER value.

Gives rise to a new Foreign KeyEMPLOYEE PROJECT MANAGER_NUM

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

83


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

84

ASSIGNMENT

EMPLOYEE PROJECT

UK

Personnel Database Network Diagram Generated by Synthesis

E_NUMBER + P_NUMBER

P_NUMBERE_NUMBER

DEPT

DEPARTMENT_NAME

MANAGER_NUM

85

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

86

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

87

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

88




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

89

ASSIGNMENT

EMPLOYEE PROJECT

PRIOR_JOBEXPERTISE

Final Personnel Database Network Diagram

E_NUMBER P_NUMBERE_NUMBER

E_NUMBER

DEPT

DEPARTMENT_NAME

MANAGER_NUM

90

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.

91

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

92

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

93

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

94

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

95

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.

96

Obtain Tutorial 2 from your tutor.

Database Design Fdd 2009

Business

Transcript of Database Design Fdd 2009