1. SYSTEMS ANALYSIS & DESIGN
PHASE 3
SYSTEMS DESIGN
File and Database Design

2. Chapter 8
File and Database Design

3. Objectives
Define the terms entity, file, record, and attribute and discuss the various types of keys
Draw an entity-relationship diagram, and explain the types of entity relationships
Define cardinality, cardinality notation, and crow’s foot notation
Explain normalization, including examples of first, second, and third normal form

4. Objectives
Compare and contrast database management and file processing environments
Explain various types of database organization, including hierarchical, network, and relational design
Describe various types of files, including master, transaction, table, work, history, and security

5. Objectives
Evaluate methods of file organization, including sequential, direct, and indexed
Calculate file sizes and storage requirements
Discuss file and database control measures

6. Introduction Data terminology and concepts
Relationships among data objects
Entity-relationship diagrams (ERDs)
Normalization
File organization and access methods
File types
File media, sizing, and controls

7. Data Terminology and Concepts
Data design includes
Entities
Fields
Records
Files
Keys

8. Data Terminology and Concepts
Definitions
Entity: a person, place, thing, or event for which data is collected and maintained
Field (attribute): a single characteristic or fact about an entity
Record: a collection of fields that describes one instance of an entity
File: a set of records that contains data about a specific entity
Click to see Figure 8-1

9. Data Terminology and Concepts
Definitions
Key field: a field used to locate, retrieve, or identify a specific record
Primary key: a key that uniquely identifies each record

10. Data Terminology and Concepts
Key fields
Primary keys
A field or combination of fields that uniquely and minimally identifies each member of an entity
A primary key composed of more than one field is called a multivalued key
Click to see Figure 8-2

11. Data Terminology and Concepts
Key fields
Candidate keys
Any field that could serve as primary key
Any field that is not a primary key or candidate key is called a nonkey field
Click to see Figure 8-2

12. Data Terminology and Concepts
Key fields
Foreign keys
A field in one file that matches a primary key value in another file
Example: the advisor number is a foreign key in the STUDENT file that matches a primary key value in the ADVISOR file
A foreign key need not be unique
A combination of two or more foreign keys can form a unique primary key value
Referential integrity ensures that a foreign key value cannot be entered unless it matches a primary key value in another file
Click to see Figure 8-2

13. Data Terminology and Concepts
Key fields
Secondary keys
A field or combination of fields that can be used to access or retrieve records
Secondary keys do not need to be unique
Click to see Figure 8-2

14. Data Relationships and Entity-Relationship Diagrams
Entity-relationship diagrams (ERDs)
An ERD is a graphical model that shows relationships among system entities
Click to see Figure 8-3

15. Data Relationships and Entity-Relationship Diagrams
Entity-relationship diagrams (ERDs)
An ERD is a graphical model that shows relationships among system entities
Each entity is a rectangle, labeled with a noun
Each relationship is a diamond, labeled with a verb
Types of relationships
One-to-one (1:1)
One-to-many (1:M)
Many-to-many (M:N)
A full ERD shows all system relationships
Click to see Figure 8-4

16. Data Relationships and Entity-Relationship Diagrams
One-to-one (1:1) relationship
Exists when exactly one of the second entity occurs for each instance of the first entity
Examples
One office manager heads one office
One vehicle ID number is assigned to one vehicle
One driver drives one delivery truck
One faculty member is chairperson of one department
Click to see Figure 8-5

17. Data Relationships and Entity-Relationship Diagrams
One-to-many (1:M) relationship
Exists when one occurrence of the first entity can be related to many occurrences of the second entity, but each occurrence of the second entity can be associated with only one occurrence of the first entity
Examples
One individual owns many automobiles
One customer places many orders
One department employs many employees
One faculty advisor advises many students
Click to see Figure 8-6

18. Data Relationships and Entity-Relationship Diagrams
Many-to-many (M:N) relationship
Exists when one instance of the first entity can be related to many instances of the second entity, and one instance of the second entity can be related to many instances of the first
Examples
A student enrolls in one or more classes, and each class has one or more students registered
A passenger buys tickets for one or more flights, and each flight has one or more passengers
An order lists one or more products, and each product is listed on one or more orders
Click to see Figure 8-7

19. Data Relationships and Entity-Relationship Diagrams
A full ERD shows all system relationships
Examples
A sales rep serves one or more customers, but each customer has only one sales rep
A customer places one or more orders, but each order has only one customer
An order lists one or more products, and each product can be listed in one or more orders
A warehouse stores one or more products, and each product can be stored in one or more warehouses
Click to see Figure 8-8

20. Data Relationships and Entity-Relationship Diagrams
Cardinality
Describes how instances of one entity relate to another
Mandatory vs. optional relationships
Crow’s foot notation is one method of showing cardinality
Click to see Figure 8-9

21. Data Relationships and Entity-Relationship Diagrams
Cardinality
Describes how instances of one entity relate to another
Mandatory vs. optional relationships
Crow’s foot notation is one method of showing cardinality
Most CASE products support the drawing of ERDs
Click to see Figure 8-10

22. Data Relationships and Entity-Relationship Diagrams
Creating an ERD
1. Identify the entities
2. Determine all significant events or activities for two or more entities
3. Analyze the nature of the interaction
4. Draw the ERD
Click to see Figure 8-11

23. Normalization
Record design process that identifies and avoids data problems and redundancy
Specifies the fields and the primary key
Normalization analyzes record structure through four stages
Unnormalized records
First normal form (1NF) records
Second normal form (2NF) records
Third normal form (3NF) records

24. Normalization First normal form
Unnormalized records contain a repeating group
A repeating group refers to a single record that has multiple values in a particular field
Example: multiple product numbers in a single order record
A 1NF record cannot have a repeating group
Click to see Figure 8-12

25. Normalization First normal form
To convert an unnormalized record to 1NF, the repeating group must be removed
Expand the primary key to include the primary key of the repeating group
The new primary key is a combination of the original primary key and the key of the repeating group
Instead of a single record with a repeating group, the result is many records, one for each instance of the repeating group
Click to see Figure 8-13

26. Normalization Second normal form (2NF)
To be in second normal form, a record must be in 1 NF, and all nonkey fields must be functionally dependent on the entire primary key - not just part of it
Functional dependency means that a value in one field determines a value in another field
If the primary key is a single field, then any record in 1 NF is automatically in 2 NF
In 2NF, all nonkey fields are functionally dependent on the entire primary key

27. Normalization Second normal form (2NF) To convert a 1NF record to 2NF
Create a new record design for each field (or combination of fields) in the primary key
Place remaining fields with the appropriate record
The result will be several records, each with a primary key field (or combination of fields) that determines the values of the other fields in that record
Click to see Figure 8-14

28. Normalization Third normal form (3NF)
To be in 3NF, a record must be in 2NF and no nonkey field is functionally dependent on another nonkey field
In 3NF, all nonkey fields are functionally dependent on the primary key, the entire key, and nothing but the key

29. Normalization Third normal form (3NF) To convert a 2NF record to 3NF
Remove all nonkey fields that depend on another nonkey field and place them in a new record that has the determining field as a primary key
Click to see Figure 8-15a
Click to see Figure 8-15b

30. Normalization A normalization example Identify the entities ADVISOR
STUDENT
COURSE
Identify the relationships
One advisor advises many students (1:M)
Students take one or more courses, and courses have one or more students (M:N)
Click to see Figure 8-16
Click to see Figure 8-17

31. Normalization A normalization example Identify the entities ADVISOR
STUDENT
COURSE
Identify the relationships
One advisor advises many students (1:M)
Students take one or more courses, and courses have one or more students (M:N)
Document the unnormalized record
Note the repeating group of courses
Click to see Figure 8-18

32. Normalization A normalization example
Convert the unnormalized record to 1 NF
Remove the repeating group
Create a primary key composed of the original primary key (student number) and the primary key of the repeating group (course number)
The result is one record for each instance of the combination primary key
Click to see Figure 8-19

33. Normalization A normalization example Convert the 1 NF record to 2NF
Create a separate record design for each field and combination of fields in the primary key
Place functionally dependent fields with an appropriate primary key
The result is three records instead of one, each with a unique primary key
Now all nonkey fields are dependent on the entire primary key, not just a portion of it
Click to see Figure 8-20

34. Normalization A normalization example Convert the 2NF record to 3NF
The STUDENT record contains a nonkey field (advisor name) that is dependent on another nonkey field (advisor number)
Create a new record with advisor number as the primary key
Remove the dependent nonkey field (advisor name) and include it in the new record
Click to see Figure 8-21

35. Normalization A normalization example Convert the 2NF record to 3NF
The STUDENT record contains a nonkey field (advisor name) that is dependent on another nonkey field (advisor number)
Create a new record with advisor number as the primary key
Remove the dependent nonkey field (advisor name) and include it in the new record
Now all nonkey fields are dependent on the entire primary key, and nothing but the key
Click to see Figure 8-22

36. Steps in Database Design
Four steps in database design
1. Create the initial ERD
2. Assign all data elements to entities
3. Create 3NF designs for all records, taking care to identify all primary, secondary, and foreign keys
4. Verify all data dictionary entries
Click to see Figure 8-23
Click to see Figure 8-24
Click to see Figure 8-25

37. Database Management
Potential problems in a file processing environment
Data redundancy
Inconsistent data
Inefficiency
Click to see Figure 8-26

38. Database Management Database management design
A database is a structure that can store data about many entities and the relationships among them
Click to see Figure 8-27

39. Database Management Elements of database management systems
A database management system (DBMS) is used to create, access, and control a database
Data definition language (DDL)
Data manipulation language (DML)
Query language
Data dictionary
Utility programs

40. Database Management Characteristics of database management
1. Scalability
2. Better support for client/server systems
3. Economy of scale
4. Sharing of data
5. Balancing conflicting requirements
6. Enforcement of standards
7. Controlled redundancy
8. Security
9. Increased programmer productivity
10. Data independence

41. Database Management Characteristics of database management
A DBMS is more powerful, complex, and expensive than a file processing system
Effective security, backup, and recovery procedures are essential
Data is a company-wide resource
Data mining enables users to extract information from anywhere in the organization

42. Database Models Hierarchical databases
Data is organized like a family tree or organization chart
The parent record at the top of the hierarchy is the root record
Pointers are used to navigate and access records
Click to see Figure 8-28

43. Database Models Network databases
The network database model is shown as a set of records arranged in one-to-many relationships
A relationship between two records is called a set, which includes owner and member records
A record can be a member of multiple sets
Click to see Figure 8-29
Click to see Figure 8-30

44. Database Models Relational databases
Data is organized into two-dimensional tables, or relations
Each row is a tuple (record) and each column is an attribute (field)
A common field appears in more than one table and is used to establish relationships
Because of its power and flexibility, the relational database model is the predominant design approach
Click to see Figure 8-31

45. Database Models Object-oriented databases
The object-oriented approach focuses on data rather than processes
An object-oriented definition includes objects, methods, messages, and inheritance
An object is a unit of data, along with the actions that can affect that data
Methods are actions defined for an object
A message is a request to execute a method
Inheritance allows a subclass to take on the characteristics of an object
Click to see Figure 8-32

46. File Access and Organization
Logical and physical records
Bit
Byte (character)
Field (data element, or data item)
Logical record
Contains field values that describe a single person, place, thing, or event
Physical record (block)
Smallest unit of data that can be accessed
Contains one or more logical records, based on a blocking factor

47. File Access and Organization
Types of files
A file is a set of logical records that contains data about an entity
Master files
Table files
Transaction files
Work files
Security files
History files
Click to see Figure 8-33

48. File Access and Organization
Data storage formats
EBCDIC
ASCII
Packed decimal
Binary format
Halfword
Fullword
Floating point

49. TRADEOFF What is the best way to store date fields? Issues to consider
Year 2000 problem
ISO format options
Julian date format
Extended Julian date format
Absolute date format

50. A KEY QUESTION
The problem: different date formats exist in various countries where SoccerMom operates
The question: should SoccerMom adapt to the standard of each country, or should it use a single international format? What are the arguments both ways?

51. File Access
The file access method determines how programs read and write records
Two main methods are used
Sequential access method
Program reads all records in order until the end of the file is reached
Random access method
Program can read any logical record without having to access all preceding records

52. File Organization
The file organization approach determines the way logical records are physically stored in a file
Alternatives
Sequential organization
Direct organization
Indexed organization

53. File Organization Sequential organization
Two methods of sequential organization
Records are stored in physical sequence as they occur
Click to see Figure 8-34

54. File Organization Sequential organization
Two methods of sequential organization
Records are stored in physical sequence as they occur
Records are stored in primary key order
Click to see Figure 8-35

55. File Organization Direct organization
With direct organization, a record is stored based on a formula that uses the record’s primary key, which must be numeric
Two methods of direct organization
Key-addressing techniques
Hashing (randomizing) techniques
Click to see Figure 8-36

56. File Organization Indexed organization
With indexed organization, a separate index file contains the key value and data file location for each logical record
Several types of indexed organization exist
Indexed random organization
Click to see Figure 8-37

57. File Organization Indexed organization
With indexed organization, a separate index file contains the key value and data file location for each logical record
Several types of indexed organization exist
Indexed random organization
Indexed sequential organization
ISAM
VSAM
Click to see Figure 8-38

58. File Organization File organization advantages and disadvantages
Direct file organization
Indexed organization

59. File Media Types
Technology has enabled many alternatives, each with advantages and disadvantages
Magnetic tape
Floppy disk
Hard disk (fixed disk, direct access storage device or DASD)
RAID (Redundant Array of Inexpensive Disks)
Removable disk cartridge
Bernoulli disk cartridge
Optical disc (CD-ROM)
Small computer system interface (SCSI)
WORM
Mass storage system

60. Calculating File Sizes and Volumes
Sizing tape files
Recording density is measured in bits per inch (bpi)
An interblock gap allows space for starting and stopping the tape between blocks
A tape sizing calculation involves tape characteristics, file characteristics, and the blocking factor used
Click to see Figure 8-39

61. Calculating File Sizes and Volumes
Sizing disk files
Disk storage capacity depends on the method of physical organization
Many manufacturers supply charts or programs for determining optimum file blocking factors
A disk sizing calculation involves type of file, whether it is indexed, the file characteristics, and the blocking factor used
Click to see Figure 8-40

62. Calculating File Sizes and Volumes
Data compression
Data compression techniques reduce the storage needed by using code to represent repeating data patterns
Many vendors offer data compression utilities

63. File and Database Control
Control must include measures to ensure that data is correct, complete, and secure
Passwords
Encryption
Backup and recovery procedures
Audit trail files
Audit fields
Click to see Figure 8-41

64. SOFTWEAR, LIMITED
Michael Jeremy has asked the IS department to develop an overall strategy for information management as part of SWL’s strategic plan
Work continues on the ESIP system, which will serve as a prototype for future SWL systems development
Tom Adams and Becky Evans will work on developing an ERD and normalized record designs for the ESIP system
Click to see Figure 8-42

65. SOFTWEAR, LIMITED ERD and normalization tasks
A CASE tool was used to draw the ERD
The ERD showed the entities and the nature of the relationships among them
The record designs progressed from 1NF to 2NF to 3NF
Click to see Figure 8-43
Click to see Figure 8-44