This document provides an overview of database design and relational database concepts. It defines key terms like data, relations, attributes, domains, tuples, functional dependencies, and network diagrams. It explains that a relational database stores data in related tables and uses primary and foreign keys to link tables based on common attributes. Functional dependency diagrams can represent relationships in a database design and be used to normalize relations into tables without redundant data.

1. Database Design FDD

12. Terminology:Key Constraint 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 Employee Job Manager Salary Jack Secretary Bozo 25,000 Kim Secretary Jill 25,000 Jill Executive Bozo 40,000 Bozo Director Bozo 50,000 Lulu Clerk Jill 30,000

13. Terminology:Key Constraint 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. Employee Job Manager Salary Jack Secretary Bozo 25,000 Kim Secretary Jill 25,000 Jill Executive Bozo 40,000 Bozo Director 50,000 Lulu Clerk Jill 30,000

15. A D atabase is more than multiple tables you must be able to “relate” them The link is through the Agent-Code Cus-code Cus-Name Area-Code Phone Agent-Code 10010 Ramus 615 844-2573 502 10011 Dunne 713 894-1238 501 10012 Smith 615 894-2205 502 10013 Olowaski 615 894-2180 502 10014 Orlando 615 222-1672 501 10015 O’Brian 713 442-3381 503 10016 Brown 615 297-1226 502 10017 Williams 615 290-2556 503 10018 Farris 713 382-7185 501 10019 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

16. Terminology: Relational Database A Relational Database is just a set of Relations. For example Which Attribute do you think relates these two tables together? JOB EMPLOYEE Job Salary Secretary 25,000 Secretary 25,000 Executive 40,000 Director 50,000 Clerk 30,000 Employee Job Manager Salary Jack Secretary Bozo 25,000 Kim Secretary Jill 25,000 Jill Executive Bozo 40,000 Bozo Director 50,000 Lulu Clerk Jill 30,000

17. Terminology:Relational Database Schema 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 Employee Job Manager Salary Job Salary

18. Terminology :Referential Integrity Constraint 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 EMPLOYEE JOB FK PK FK PK Employee Job Manager 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

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 EMPLOYEE JOB FK FK PK PK Job Salary Director 50,000 Clerk 30,000 Employee Job Manager Jack Secretary Bozo Kim Secretary Jill Bozo Director Lulu Clerk Jill

21. Example of Data Redundancy (1)

23. Example of Data Redundancy (3)

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 JOB Job 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 10000 Common stock issue 28765 Baker 3000 4000 Resolve bad debts 26713 Kanter 2000 1500 New office lease 26511 Yates 5000 5000 Revise documentation 34054 Kanter 100 3000 Entertain new client 87108 Yates 5000 2000 New 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 Management 1004 26511 1004 28765 1005 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

31. TITLE PROJECT PRIOR_JOB EMPLOYEE SKILL 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 EMPLOYEE SKILL EXPERTISE skill e_number p_number e_number e_number e_number manager ASSIGNMENT

36. Answer Supplies Supplier Part Uses Product

39. Answer Orders OrLine Part Customer SalesRep SlsNumber CustNumb orLine Part

42. Functional Dependence FDD

48. Functional Dependency Diagrams Now we have the Database Design 2NF Relation 3NF Relation Universal Relation 1NF Tables ONF Using the Method of Decomposition Method of Synthesis Sample Data Eliminate Part Key Dependencies Eliminate Non Key Dependencies Eliminate Repeating Groups Attribute & Functional Dependencies Given the Problem Functional Dependency Diagram OR, here is the same process using the FDD approach

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” Considering the rules stated above we should be able to draw a FDD for this. What are the elements of interest? Students FamilyName 1 Smith 2 Jones 3 Smith 4 Andrews

54. FDDs Answer 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. Students FamilyName 1 Smith 2 Jones 3 Smith 4 Andrews

55. FDDs Examples Employees and the departments they work for. 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” Department Name Accounting Employee Number 11 2 31 Department Name Sales Employee Number 45 27

56. FDD Answers Employees and the departments they work for. Data elements of interest are Employee# and DeptName” Employee# DeptName So we could make this following Table 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

57. FDDs Examples The quantity of parts held in a warehouse and their suppliers 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 Parts Suppliers Name QOH 1 Wang Electronics 23 2 Cumberland Enterprises 80 3 Wang Electronics 4 4 Roscoe Pty. Ltd 58

58. FDDs Examples Students 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 Examples Results 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 Examples Results obtained by each student for each subject. Try and construct an FDD for this table considering the given Business Rules and the Data Elements Student Student Name Subject Name Grade 1 Smith History A 1 Smith Geography B 1 Smith Mathematics A 2 Jones History C 2 Jones English C 3 Smith English A 3 Smith Mathematics A 4 Andrews English D 4 Andrews French C 4 Andrews Geography C

61. FDDs Examples Results 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 Answer Results 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 Examples Customer Orders Validating functional dependencies Using simple data and populating the table, check there is only one value of the dependent. 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 455 49 Emily Jones 45 Grattan St, Parkville 455 54 Emily Jones 45 Grattan St, Parkville 456 12 Mary Ho 44 Park St, Hawthorn 456 54 Mary Ho 44 Park St, Hawthorn

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 Address Part# 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

65. FDDs Examples Employees and their tax files numbers “ Each employee has a unique employee number” “ Each employee has a unique tax file number ” Employee# determines taxfile# Taxfile# determines Employee# Alternative keys Employee TaxFile# 1 1024-5321 2 3456-3294 3 8246-7106 4 8861-6750 5 1234-4765 Employee# Taxfile# Employee# Taxfile# Taxfile# Employee#

67. Functional Dependency Diagrams Database 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. 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.

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_COST EXPECTED_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_COST EXPECTED_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_COST EXPECTED_COST _________________________________________________________________________________________________________ New billing system 26 23760 Yates 1000 10000 New office lease 10 26511 Yates 5000 5000 ___________________________________________________________________________________________________________________________ Personnel Database Forms 2

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. LOCATION DEPARTMENT_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. Personnel Database FD Diagram - Synthesis CURRENT_TITLE E_NUMBER 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.

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.

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 PRIOR_JOB ( E_NUMBER, PRIOR_TITLE ) EXPERTISE ( E_NUMBER, SKILL) Personnel Database Multivalued 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. EXPECTED_COST Personnel Database FD 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 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