1. Fundamental Relational Database Design
5/10/2018
Fundamental Relational Database Design By
Bob Blair &
Mary Sweeney
Robert L. Blair Instructor, Bellevue Community College

2. The Day What is Database Design Tables Table Relationships
Data Normalization
Data Integrity Levels

3. Database Design
5/10/2018
Database Design
The efficient organization of real world data into a properly functioning model of a business/organization based on relational database principles and conventions representing current business rules and practices.
We will cover the basic relational database design principles and conventions today.
Robert L. Blair Instructor, Bellevue Community College

4. Objectives of Good Design
Supports Required and ad hoc information retrieval and deletion.
Contains efficiently constructed table structures.
Since the database follows a well-formulated model, it behaves predictably following all current business rules and practices
Imposes data integrity at the field, table, and relationship levels.
The database is somewhat self documenting.
Changes to the database schema are easy to make Lends itself to future growth.

5. Advantages of Good Design
Easy to modify and maintain structure.
Easy to modify data.
Easy to retrieve data.
Easy to develop and build user applications.

6. Types of Databases Operational
Operational databases are used to collect the day-to-day operational data of a business, institution or organization. Data needs to be collected, maintained, and modified. These databases collect dynamic data that changes from day to day.

7. Types of Databases Analytical
Analytical databases are used to track historical and time-dependent data. Data is used to track trends, view statistical data over long periods of time, or make long-term projections. Data is static, it never or rarely ever needs to be modified. Use static data stored in a data warehouse.

8. Data Base Design Methods
Requirements Analysis Phase
Data Modeling Phase
Normalization Phase

9. Good Design
Good database design is like the architect putting their design down on a blue print for the builder to read. It is a well thought out plan that prescribes to good design elements and existing codes.

10. Northwind Relationship Window (Blue Prints)
Database Design
5/10/2018
Northwind Relationship Window (Blue Prints)
This is your blue print of a well constructed database. Without this the application portion of the database would not function properly.
Robert L. Blair Instructor, Bellevue Community College

11. Database Design and Tables
The example for the Northwind Database relationship window on the previous screen, you will notice is made up of tables and the relationships between those tables.
If the design is like the architects plan then the foundation of that design are the tables that will be used to create those relationships

12. Database Tables

13. Tables or Entities (or relations)
Tables are also called entities or relations and are often referred to as such in database design literature.

14. Tables/Entities
Tables are containers that store data about objects or events.
Objects would include: Autos, people, products etc. Any entity that can be described.
Events would include: Doctors Appointments, a sale of a house, the transfer of goods from one warehouse to another, a scientific experiment, the production of a chemical product etc.

15. Tables/Entities Tables are made up of columns and rows
Columns are called fields/attributes
Rows are called records/tuples

16. Rows and Columns
Columns
Called fields
Rows
Called records

17. Tables Columns
Columns are called fields or attributes and contain the smallest values in a database.
Each field value must be atomic, that is broken into its smallest unit i.e. the field Name consisting of both First and Last Names must be broken into two fields FirstName and LastName to be atomic.

18. Atomic Values Field New Field Name First Name Last Name Frank Jones
Not Atomic Value
Atomic Value
Mary Smith
Mary
Smith
Ed Francis Ed
Francis

19. Tables - Rows
Rows are called records (or sometimes tuples) and describe a single object or event.
Each row must have a field or combination of fields (columns) that will uniquely identify each record.
This uniquely identifying field or combination of fields is called a Primary Key.
Primary key fields are used to establish relationships between tables AND to establish table level integrity

20. Primary Key Fields EmployeeID FirstName LastName 12345 Joan Smith
12346
Kim
Allen
Primary Key or PK uniquely identifies a record

21. A Table

22. Table Relationships

23. Relationships There are three kinds One-to-One One-to-Many
Many-to-Many

24. Primary and Foreign Keys
Primary Key – Uniquely identifies a single record in a table. Primary keys can be one or a combination of fields. A multiple field primary key is called a composite key.
Foreign Key - is a primary key field from table A inserted in table B to create the relationship between the two tables.

25. One - to - One
Each record in table A relates to one and only one record in table B and each record in table B relates to one and only one record in table A.
Examples:
Hospital bed to patient
Athlete to locker

26. One-to-One

27. One-to-Many
For each record In table A there are none, one or many records that relate in table B
For each record in table B there is one and only one record that relates in table A

28. One - to - Many
Primary
Key
Foreign
Key

29. Many-to-Many Many students have many courses and
Many courses have many students

30. Many - to - Many
Is a No No
Will not work

31. Many-to-Many
A join between two tables each containing 1000 records will result 1,000,000 combinations form this join. For you mathematicians the result is a Cartesian product.
This is the result of every record in table A relates to every record in table B and every record in table B relates to every record in table A

32. Many-to-many Solution
The solution is to create two one to many relationships with a Junction, Intersection, Association Table. This table would contain the primary key from each of the two tables in the many-to-many relation.

33. Intersection or Junction Table

34. Database Design
5/10/2018
Normalizing Data “The Key, the whole key, and nothing but the key so help me Codd “
Robert L. Blair Instructor, Bellevue Community College

35. Database Design
5/10/2018
Normalization
Is the process of simplifying the design of a database so that it achieves optimum structure.
Robert L. Blair Instructor, Bellevue Community College

36. Normalization Ensures correctness of the design
Database Design
5/10/2018
Normalization
Ensures correctness of the design
Answers the following questions
Is the correct number of tables specified; are there any hidden tables ?
Are columns set up properly on the proper tables ?
Are the correct table relationships represented ?
Robert L. Blair Instructor, Bellevue Community College

37. Database Design
5/10/2018
Normal Forms
Normalization theory gives us the concept of normal forms to assist in achieving the optimum structure. The normal forms are a linear progression of rules that you apply to your database, with each higher normal form achieving a better, more efficient design.
Robert L. Blair Instructor, Bellevue Community College

38. Normal Forms First Normal Form Second Normal Form Third Normal Form
Database Design
5/10/2018
Normal Forms
First Normal Form
Second Normal Form
Third Normal Form
Boyce Codd Normal Form
Fourth Normal Form
Fifth Normal Form
Robert L. Blair Instructor, Bellevue Community College

39. Database Design
5/10/2018
First Normal Form (1NF)
A table is in first normal form (1FN) if there are no repeating groups
Robert L. Blair Instructor, Bellevue Community College

40. Database Design
5/10/2018
1NF
Robert L. Blair Instructor, Bellevue Community College

41. 1NF Normalized Database Design 5/10/2018
Robert L. Blair Instructor, Bellevue Community College

42. 1NF Normalized Practical Example
Database Design
5/10/2018
1NF Normalized Practical Example
Robert L. Blair Instructor, Bellevue Community College

43. 1NF Not Normalized Database Design 5/10/2018
Robert L. Blair Instructor, Bellevue Community College

44. 1NF Normalized Database Design 5/10/2018
The table Order is broken into two tables.
tblOrder the table on top which contains the information necessary to create the order.
tblOrderLineItem on the bottom was created from all the repeating fields in the original Orders table. It contains all the items purchased on each order.
Draw out example for the class to see. This is an important concept for the class to understand.
Robert L. Blair Instructor, Bellevue Community College

45. 1NF Practical Use Database Design 5/10/2018
Robert L. Blair Instructor, Bellevue Community College

46. Second Normal Form (2NF)
Database Design
5/10/2018
Second Normal Form (2NF)
Second Normal Form requires that a table be in first normal form AND every non-key column be fully dependent on the entire primary key.
Hint: This normal form only applies to those tables with a composite primary key! You can ignore those that don’t have composite keys for this step.
Robert L. Blair Instructor, Bellevue Community College

47. 2NF Is this in 2NF ? Composite PK OrderID and OrderItem#
Database Design
5/10/2018
2NF
Is this in 2NF ?
Composite PK OrderID and OrderItem#
Hint: Hold the OrderID constant and you will see that the CustomerID and OrderDate don’t change.
The OrderDate and the CustomerID columns reflect only the OrderID and not the Combination of Order ID and OrderItem#
Robert L. Blair Instructor, Bellevue Community College

48. 2NF Normalized Database Design 5/10/2018
Robert L. Blair Instructor, Bellevue Community College

49. Database Design
5/10/2018
Third Normal Form (3NF)
Third Normal Form requires that every table be in second normal form AND that all non-key columns be mutually independent.
Think of this as: No tables within tables
Robert L. Blair Instructor, Bellevue Community College

50. 3 Normal Form (3NF) Is this table in 3NF ? Database Design 5/10/2018
No the DroductDescription field is not mutually independent. It is dependent on the ProductID for its value. This also creates updating problems. The solution to the problem is the creation of a lookup table called tblproducts.
Robert L. Blair Instructor, Bellevue Community College

51. Database Design
5/10/2018
3 Normal Form (3NF)
The ProductDescription field is not mutually independent.
It is dependent on the ProductID field for its value.
Robert L. Blair Instructor, Bellevue Community College

52. 3NF Normalized Database Design 5/10/2018
Robert L. Blair Instructor, Bellevue Community College

53. 3NF Is this table in 3NF? Database Design 5/10/2018
Robert L. Blair Instructor, Bellevue Community College

54. Database Design
5/10/2018
3NF Normalized
The fields Gross and Net Pay are not mutually independent. They are calculated fields that are dependent on the fields Hours and Rates for data. Therefore they should not be included in the table. (they are NOT mutually independent.
Robert L. Blair Instructor, Bellevue Community College

55. 3NF and Calculated Fields
Database Design
5/10/2018
3NF and Calculated Fields
Rule of thumb – you do not store any data that can be calculated. This saves space in the database.
Robert L. Blair Instructor, Bellevue Community College

56. Normalization and the Real World
Database Design
5/10/2018
Normalization and the Real World
There are some times that you will want to break the rules governing normalization of tables, or denormalize tables. This is OK if and only if it will improve the efficiency of you database or application. Example: Splitting tables or combining tables to improve performance
Document why you did what you did.
Robert L. Blair Instructor, Bellevue Community College

57. Database Design
5/10/2018
Calculated Fields
Real world – store calculated field data only if it increases the efficiency of your database.
Robert L. Blair Instructor, Bellevue Community College

58. It is possible to stop here
Database Design
5/10/2018
It is possible to stop here
For most business purposes, you can stop right here. If your tables are truly in 3NF and you have implemented your table relationships correctly your database should function properly. The Boyce Codd and 4 and 5NF’s deal special cases rather than something that would cause incorrect or inconsistent data.
Robert L. Blair Instructor, Bellevue Community College

59. Data Integrity Field level Table Level
Database Design
5/10/2018
Data Integrity
Field level
Choose correct datatypes
Add constraints for:
Default value
Ranges (ie., Price >= 0 and <= )
Table Level
Primary Key constraint
Relationship Level (between tables)
Foreign key constraint
Robert L. Blair Instructor, Bellevue Community College

60. Querying Select * from Products;
Database Design
5/10/2018
Querying
Select * from Products;
Select Employeeid, SalesID, Firstname,
Salesdate from
Employees join Sales
On Employees.Employeeid = Sales.Employeeid
Robert L. Blair Instructor, Bellevue Community College

61. The End Database Design 5/10/2018
Robert L. Blair Instructor, Bellevue Community College