Concepts of Database Management Seventh Edition Chapter 8 Database Administration.
Concepts of Database Management Seventh Edition
description
Transcript of Concepts of Database Management Seventh Edition
![Page 1: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/1.jpg)
Concepts of Database ManagementSeventh Edition
Chapter 6
Database Design 2: Design Method
![Page 2: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/2.jpg)
Objectives
• Discuss the general process and goals of database design
• Define user views and explain their function
• Define Database Design Language (DBDL) and use it to document database designs
• Create an entity-relationship (E-R) diagram to visually represent a database design
• Present a method for database design at the information level and view examples illustrating this method
2
![Page 3: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/3.jpg)
Objectives (continued)
• Explain the physical-level design process
• Discuss top-down and bottom-up approaches to database design and examine the advantages and disadvantages of both methods
• Use a survey form to obtain information from users prior to beginning the database design process
• Review existing documents to obtain information prior to beginning the database design
3
![Page 4: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/4.jpg)
Objectives (continued)
• Discuss special issues related to implementing one-to-one relationships and many-to-many relationships involving more than two entities
• Discuss entity subtypes and their relationships to nulls
• Learn how to avoid potential problems when merging third normal form relations
• Examine the entity-relationship model for representing and designing databases
4
![Page 5: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/5.jpg)
Introduction
• Two-step process for database design
• Information-level design: completed independently of any particular DBMS
• Physical-level design: information-level design adapted for the specific DBMS that will be used– Must consider characteristics of the particular DBMS
5
![Page 6: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/6.jpg)
User Views
• User view: set of requirements necessary to support operations of a particular database user (e.g. cashier, sales manager, accountant etc)– Ex. Premier products database should be capable of storing
each part’s number, description, units on hand, item class, Warehouse number where the parts is located, price etc.
• Cumulative design: supports all user views encountered during design process– Each user view is generally simpler than the total collections of
requirements– Working on individual user view is more manageable
therefore.
6
![Page 7: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/7.jpg)
Information-Level Design Method
• For each user view:1. Represent the user view as a collection of tables
2. Normalize these tables
3. Identify all keys in these tables
4. Merge the result of Steps 1 through 3 into the cumulative design
Mnemonics : RaNK Me
7
![Page 8: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/8.jpg)
Represent the User View As a Collection of Tables
• Step 1: Determine the entities involved and create a separate table for each type of entity
• Step 2: Determine the primary key for each table
• Step 3: Determine the properties for each entity
• Step 4: Determine relationships between the entities– One-to-many– Many-to-many– One-to-one
8
![Page 9: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/9.jpg)
Represent the User View As a Collection of Tables (continued)
• One-to-many relationship: include primary key of the “one” table as a foreign key in the “many” table
• Many-to-many relationship: create a new table whose primary key is the combination of the primary keys of the original tables
• One-to-one relationship: simplest implementation is to treat it as a one-to-many relationship
9
![Page 10: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/10.jpg)
Example User View
• Departments and Employees
• Each department can hire many employees and each employee work only in one department.
10
![Page 11: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/11.jpg)
Represent the User View As a Collection of Tables - Step 1: Determine the entities involved
and create a separate table for each entity
11
What are the entities involved?
Department Employee
So, represent each entity as Table as shown below:
Department (
Employee (
![Page 12: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/12.jpg)
Represent the User View As a Collection of Tables - Step 2: Determine the primary key for
each table
12
What does it take identify each entity uniquely?
For Department entity probably Department Number
Department (DepartmentNum,
For Employee entity probably Employee Number
Employee (EmployeeNum,
![Page 13: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/13.jpg)
Represent the User View As a Collection of Tables - Step 3: Determine the properties for
each entity
13
For Department entity, properties/fields could be:
Department (DepartmentNum, Name, Location)
For Employee entity, properties/fields could be:
Employee (EmployeeNum, LastName, FirstName, Street, City, State, Zip, WageRate, SocSecNum)
![Page 14: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/14.jpg)
Represent the User View As a Collection of Tables - Step 4: Determine relationship
between entities:
14
Determine if it is One-to-One, One-to-Many or Many-to-Many
Based on user requirements a Department could havemany Employees but an Employee could only work in one Department.
Department Employee1 M
One-to-Many
![Page 15: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/15.jpg)
Represent the User View As a Collection of Tables - Step 4: Determine relationship
between entities:
15
Remember the many side has the Foreign key?
Which is the Primary Key of the one side.
Department EmployeeM1
Department (DepartmentNum, Name, Location)
Primary Key
Employee (EmployeeNum, LastName, FirstName, Street, City, State, Zip, WageRate, SocSecNum, DepartmentNum) Foreign Key
![Page 16: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/16.jpg)
Represent the User View As a Collection of Tables - Step 4: Determine relationship
between entities:
16
What if Many-to-many relationship?
Department EmployeeM N
Create a bridge Table between entities thus creatingtwo one-to-many relationship.
Department (DepartmentNum, Name, Location)
Employee (EmployeeNum, LastName, FirstName, Street, City, State, Zip, WageRate, SocSecNum)
WorksIn (EmployeeNum, DepartmentNum) Bridge Table
![Page 17: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/17.jpg)
Graded Seatwork
17
• See Page 224 on Textbook – Question No. 6a. Many employees can work on a given project but each employee can work only on a single
project.
b. An Employee can work on many projects but each project has a unique employee assigned to it.
c. An employee can work on many projects and a project can be worked on many employees
Note : Answer each letter above separately
![Page 18: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/18.jpg)
Normalize the Tables
• Normalize each table
• Target is third normal form– Careful planning in early phases of the process
usually rules out need to consider fourth normal form
18
![Page 19: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/19.jpg)
Identify All Keys
• For each table, identify:– Primary key– Alternate keys– Secondary keys– Foreign keys
• Alternate key: column(s) that could have been chosen as a primary key but was not (e.g. SSN could
be an alternate key if an EmployeeID is used instead of it) • Secondary keys: columns of interest strictly for
retrieval purposes (e.g. Last Name, First Name instead of ID Number)
19
![Page 20: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/20.jpg)
Identify All Keys (continued)
• Foreign key: column(s) in one table that is required to match value of the primary key for some row in another table or is required to be null– Used to create relationships between tables– Used to enforce certain types of integrity constraints
20
![Page 21: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/21.jpg)
Types of Primary Keys
• Natural key: consists of a column that uniquely identifies an entity (e.g. Social Security Number, a book’s ISBN [International Standard Book Number], a product’s UPC [Universal Product Code] or a vehicle’s VIN [Vehicle Identification Number]
– Also called a logical key or an intelligent key
• Artificial key: column created for an entity to serve solely as the primary key and that is visible to users
• Surrogate key: system-generated; usually hidden from users– Also called a synthetic key
21
![Page 22: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/22.jpg)
Database Design Language (DBDL)
• Table name followed by columns in parentheses – Primary key column(s) underlined
• AK identifies alternate keys
• SK identifies secondary keys
• FK identifies foreign keys– Foreign keys followed by an arrow pointing to the
table identified by the foreign key
22
![Page 23: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/23.jpg)
Database Design Language (DBDL) (continued)
FIGURE 6-1: DBDL for the Employee table
23
![Page 24: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/24.jpg)
Entity-Relationship (E-R) Diagrams
• Visually represents database structure or the conceptual model of the Database
24
![Page 25: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/25.jpg)
Building Blocks of ERD
25
Type English Grammar Equivalent Example
Entity Proper Noun Student, Employee, Instructor, Courses, Room
Relationship Verb has, teaches, belongs, handles
Attribute Adjective Height, Age, Gender, Nationality, First name
![Page 26: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/26.jpg)
ERD Popular Notation
• Chen Notation• Crow’s Foot Notation
26
![Page 27: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/27.jpg)
Chen Notation - Symbol
27
1 M
Rectangle represents an Entity
Diamond represents a Relationship
Lines with labels represents Cardinality
![Page 28: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/28.jpg)
Entity (Chen Notation)
• is a real-world object distinguishable or unique from other objects.
• An entity can be a concrete or physical object like employee, student, faculty, customer etc. Or it could also be conceptual or abstract like transaction, order, course, subjects etc.
• It can be thought of as a noun like student, employee etc.
• It is normally represented by a rectangle shape.
28
![Page 29: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/29.jpg)
Database Background• Remember in Chapter 1 Entity could be a :
29
Person
Place
(ex. Teacher, Student, Physician)
(ex. School, Hotel, Store )
Object(ex. Mouse, Books, Bulding )
Event (ex. Enroll, Withdraw, Order )
Idea or Concept (ex. Courses, Account, Delivery )
![Page 30: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/30.jpg)
Entity - Example
• For example in our Premiere Database the different Entities are the following:
30
Customer Sales Rep
Order
Parts
![Page 31: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/31.jpg)
Relationship
• is a way of relating one entity to another. Entities can therefore participate in a relationship.
• it is commonly thought as a verb connecting the entities or nouns.
• It is normally represented by a diamond shape.
31
![Page 32: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/32.jpg)
Relationship - Example
• For example in our Premiere Database again we have this relationships among entities:
32
represents CustomerSales Rep
Order
has
Could be read as : A Sales RepRepresents a Customer. And aCustomer has an Order.
![Page 33: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/33.jpg)
Cardinality
• Cardinality: number of items that must be included in a relationship– An entity in a relationship with minimum cardinality of
zero plays an optional role in the relationship– An entity with a minimum cardinality of one plays a
mandatory role in the relationship
33
![Page 34: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/34.jpg)
Cardinality - Symbols
34
One-is-to-many Relationship
1 M
M N
Many-to-many Relationship
![Page 35: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/35.jpg)
Cardinality Symbols - Example
35
represents CustomerSales Rep
Could be read as : A Sales Rep could represent1 or Many Customers.
1 M
![Page 36: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/36.jpg)
Cardinality Symbols – Example (Cont’d)
36
has PartsOrder
Could be read as : An Order could have many Parts (e.g. ProductsOrdered) and a Part could have many Orders.
M N
![Page 37: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/37.jpg)
Degree of Relationship
• There are three Degree of Relationships in ERD notation, namely:– Unary– Binary– Ternary
37
![Page 38: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/38.jpg)
Degree of Relationship (Cont’d)
38
Unary
Binary
Ternary
![Page 39: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/39.jpg)
Degree of Relationship (Cont’d)
39
Employee
Unary
Customer Orders Binary
Vendor Warehouse
Part
Ternary
Manages
makes
supplies
![Page 40: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/40.jpg)
Attribute
• Refers to the characteristic or basic fact or field of an Entity or Relationship.
• For example a Student entity could have the following attributes ID Number, Last Name, First Name, Address, Birth Date etc.
• A relationship could also have an attribute for example an Entity name Student enrolls (relationship) to a Course/Program. Now, when you enroll you enroll on a certain date so you will have an attribute of Enrollment Date under Enroll relationship.
• It is normally represented by an oval.
40
![Page 41: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/41.jpg)
Attribute - Example
41
RepNum
Sales Rep
LastnameFirstname
Street
City
State
Zip CommissionRate
Take note thata Primary Keyis underlined.
![Page 42: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/42.jpg)
Attribute – More Example
42
RepNum
Sales Rep
LastnameFirstname
Street
City
State
Zip CommissionRate
Customerrepresents
CustomerNum
CustomerName
CreditLimit
Balance
Street
City
State
Zip
1 M
![Page 43: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/43.jpg)
Crow’s Foot notation - Symbol
43
Entity name
Attribute 1Attribute 2Attribute 3Attribute 4
![Page 44: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/44.jpg)
Crow’s Foot notation - Example
44
Student
StudentIDFirstnameLastnameGenderProgram
Entity
Attributes
![Page 45: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/45.jpg)
Crow’s Foot notation - Keys
45
Student
StudentID (PK)Firstname (SK)Lastname (SK)GenderProgramID (FK)
PK – Primary Key
FK – Foreign Key
SK – Secondary Key
![Page 46: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/46.jpg)
Crow’s Foot Cardinality - Symbols
46
One and only one included in the relationship
Zero or many could be included in the relationship. This is optional mode.
One or many could be included in the relationship.This is mandatory mode.
![Page 47: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/47.jpg)
Crow’s Foot notation – with Cardinality
47
Rep
Repnum (PK)FirstnameLastnameCommissionRate
Customer
Customernum(PK)CustomernameStreetCityStateZipBalanceCreditLimitRepnum (FK)
![Page 48: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/48.jpg)
ERD for Department/Employee example
48
Department
DepartmentNum(PK)NameLocation
Customer
EmployeeNum(PK)Lastname (SK)Firstname (SK)StreetCityStateZipWageRateSocSecNum (AK)DepartmentNum (FK)
![Page 49: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/49.jpg)
Graded Seatwork
49
• Make an ERD using both Chen and Crow’s Foot notation for Question No. 6 letter c on Page 224 of your Textbook – c. An employee can work on many projects and a
project can be worked on many employees
![Page 50: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/50.jpg)
Merge the Result into the Design
• Combine tables that have the same primary key to form a new table
• New table:– Primary key is same as the primary key in the tables
combined– Contains all the columns from the tables combined– If duplicate columns, remove all but one copy of the
column
• Make sure new design is in third normal form
50
![Page 51: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/51.jpg)
Merge the Result into the Design (continued)
FIGURE 6-3: Information-level design method
51
![Page 52: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/52.jpg)
Database Design Examples
• Develop an information-level design
• Company stores information about sales reps, customers, parts, and orders
• User view requirements
• Constraints
FIGURE 6-4: Cumulative design after first user view
52
![Page 53: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/53.jpg)
ERD for Premier Database
53
Rep
Repnum (PK)FirstnameLastnameStreetCityStateZipCommissionRate
Customer
Customernum(PK)CustomernameStreetCityStateZipBalanceCreditLimitRepnum (FK)
Part
Partnum (PK)DescriptionOnHandClassWarehousePrice
![Page 54: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/54.jpg)
ERD for Premier Database (cont’d)
54
Rep
Repnum (PK)FirstnameLastnameStreetCityStateZipCommissionRate
Customer
Customernum(PK)CustomernameStreetCityStateZipBalanceCreditLimitRepnum (FK)
Part
Partnum (PK)DescriptionOnHandClassWarehousePrice
Orders
Ordernum (PK)OrderDateCustomerNum (FK)
OrderLine
Ordernum (PK,FK1)Partnum (PK,FK2)NumOrderedQuotedPrice
![Page 55: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/55.jpg)
Database Design Examples (continued)
• Henry Books database: information about branches, publishers, authors, and books
• User view requirements
FIGURE 6-9: DBDL for Book database after first user view
55
![Page 56: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/56.jpg)
Database Design Examples (continued)
FIGURE 6-10: DBDL for Book database after second user view
56
![Page 57: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/57.jpg)
Graded Seatwork
57
• Make an ERD for your own Database assigned to you.Set A – Alexamara
Set B – Henry Books
![Page 58: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/58.jpg)
Physical-Level Design
• Undertaken after information-level design completion
• Most DBMSs support primary, candidate, secondary, and foreign keys
• To enforce restrictions, DB programmers must include logic in their programs
58
![Page 59: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/59.jpg)
Top-Down Versus Bottom-Up
• Bottom-up design method– Design starts at low level – Specific user requirements drive design process
• Top-down design method– Begins with general database that models overall
enterprise– Refines model until design supports all necessary
applications
59
![Page 60: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/60.jpg)
Survey Form
• Used to collect information from users
• Must contain particular elements– Entity information– Attribute (column) information– Relationships– Functional dependencies– Processing information
60
![Page 61: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/61.jpg)
Obtaining Information from Existing Documents
• Existing documents can furnish information about database design
• Identify and list all columns and give them appropriate names
• Identify functional dependencies
• Determine the tables and assign columns
61
![Page 62: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/62.jpg)
Obtaining Information from Existing Documents (continued)
FIGURE 6-14: Invoice for Holt Distributors
62
![Page 63: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/63.jpg)
Obtaining Information from Existing Documents (continued)
FIGURE 6-15: List of possible attributes for the Holt Distributors invoice
63
![Page 64: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/64.jpg)
Obtaining Information from Existing Documents (continued)
FIGURE 6-17: Revised list of functional dependencies for the Holt Distributors invoice
64
![Page 65: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/65.jpg)
Obtaining Information from Existing Documents (continued)
FIGURE 6-19: Expanded list of entities
65
![Page 66: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/66.jpg)
One-to-One Relationship Considerations
• Simply include the primary key of each table as a foreign key in the other table– No guarantee that the information will match
• One solution: create a single table– Workable, but not the best solution
• Better solution– Create separate tables for customers and sales reps– Include the primary key of one of them as a foreign
key in the other
66
![Page 67: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/67.jpg)
One-to-One Relationship Considerations (continued)
FIGURE 6-23: One-to-one relationship implemented by including the primary key of one table as the foreign key (and alternate key) in the other table
67
![Page 68: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/68.jpg)
Many-to-Many Relationship Considerations
• Complex issues arise when more than two entities are related in a many-to-many relationship
• Many-to-many-to-many relationship: involves multiple entities
• Deciding between a single many-to-many-to-many relationship and two (or three) many-to-many relationships– Crucial issue: independence
68
![Page 69: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/69.jpg)
Many-to-Many Relationship Considerations (continued)
FIGURE 6-25: Result obtained by splitting the Sales table into three tables69
![Page 70: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/70.jpg)
Many-to-Many Relationship Considerations (continued)
FIGURE 6-26: Result obtained by joining three tables—the second and third rows are in error!
70
![Page 71: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/71.jpg)
Nulls and Entity Subtypes
• Null– Special value– Represents absence of a value in a field– Used when a value is unknown or inapplicable
• Splitting tables to avoid use of null values
• Entity subtype: table that is a subtype of another table
71
![Page 72: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/72.jpg)
Nulls and Entity Subtypes (continued)
FIGURE 6-27: Student table split to avoid use of null values72
![Page 73: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/73.jpg)
Nulls and Entity Subtypes (continued)
• Subtype called a category in IDEF1X terminology
• Incomplete category: records that do not fall into the subtype
• Complete categories: all records fall into the categories
73
![Page 74: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/74.jpg)
Nulls and Entity Subtypes (continued)
FIGURE 6-29: Entity subtype in an E-R diagram
74
![Page 75: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/75.jpg)
Nulls and Entity Subtypes (continued)
FIGURE 6-32: Two entity subtypes—incomplete categories
75
![Page 76: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/76.jpg)
Nulls and Entity Subtypes (continued)
FIGURE 6-33: Two entity subtypes—complete categories
76
![Page 77: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/77.jpg)
Avoiding Problems with Third Normal Form When Merging Tables
• When combining third normal form tables, the result might not be in third normal form
• Be cautious when representing user views
• Always attempt to determine whether determinants exist and include them in tables
77
![Page 78: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/78.jpg)
The Entity-Relationship Model
• An approach to representing data in a database
• Entities are drawn as rectangles
• Relationships are drawn as diamonds with lines connecting the entities involved in relationships
• Composite entity: exists to implement a many-to-many relationship
• Existence dependency: existence of one entity depends on the existence of another related entity
• Weak entity: depends on another entity for its own existence
78
![Page 79: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/79.jpg)
The Entity-Relationship Model (continued)
FIGURE 6-34: One-to-many relationship
79
![Page 80: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/80.jpg)
The Entity-Relationship Model (continued)
FIGURE 6-35: Many-to-many relationship
80
![Page 81: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/81.jpg)
The Entity-Relationship Model (continued)
FIGURE 6-36: Many-to-many-to-many relationship
81
![Page 82: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/82.jpg)
The Entity-Relationship Model (continued)
FIGURE 6-37: One-to-many relationship with attributes added
82
![Page 83: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/83.jpg)
The Entity-Relationship Model (continued)
FIGURE 6-38: Many-to-many relationship with attributes
83
![Page 84: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/84.jpg)
The Entity-Relationship Model (continued)
FIGURE 6-39: Composite entity
84
![Page 85: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/85.jpg)
The Entity-Relationship Model (continued)
FIGURE 6-40: Complete E-R diagram for the Premiere Products database
85
![Page 86: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/86.jpg)
The Entity-Relationship Model (continued)
FIGURE 6-41: E-R diagram with an existence dependency and a weak entity
86
![Page 87: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/87.jpg)
The Entity-Relationship Model (continued)
• Cardinality: number of items that must be included in a relationship– An entity in a relationship with minimum cardinality of
zero plays an optional role in the relationship– An entity with a minimum cardinality of one plays a
mandatory role in the relationship
87
![Page 88: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/88.jpg)
The Entity-Relationship Model (continued)
FIGURE 6-43: E-R diagram that represents cardinality
88
![Page 89: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/89.jpg)
Summary
• Database design is a two-part process: information-level design (not dependent on a particular DBMS) and physical-level design (appropriate for the particular DBMS being used)
• User view: set of necessary requirements to support a particular user’s operations
• Information-level design steps for each user view: represent the user view as a collection of tables, normalize these tables, represent all keys (primary, alternate, secondary, and foreign), and merge the results into the cumulative design
89
![Page 90: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/90.jpg)
Summary (continued)
• Database design is represented in Database Design Language (DBDL)
• Designs can be represented visually using entity-relationship (E-R) diagrams
• Physical-level design process consists of creating a table for each entity in the DBDL design
• Design method presented in this chapter is bottom-up
• Survey form is useful for documenting the information gathered for database design process
90
![Page 91: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/91.jpg)
Summary (continued)
• To obtain information from existing documents, list all attributes present in the documents, identify potential functional dependencies, make a tentative list of tables, and use the functional dependencies to refine the list
• To implement a one-to-one relationship, include primary key of one table in the other table as a foreign key and indicate the foreign key as an alternate key
91
![Page 92: Concepts of Database Management Seventh Edition](https://reader036.fdocuments.us/reader036/viewer/2022062409/56814f08550346895dbc9acf/html5/thumbnails/92.jpg)
Summary (continued)
• If a table’s primary key consists of three (or more) columns, determine whether there are independent relationships between pairs of these columns
• If a table contains columns that can be null and the nulls mean that the column is inapplicable for some rows, you can split the table, placing the null column(s) in separate tables
• The result of merging third normal form tables may not be in third normal form
• Entity-relationship (E-R) model represents the structure of a database using an E-R diagram
92