CHAPTER 11 Slides

Database Design
Introduction
 The chapter will address the following questions:

 What are the similarities and differences between conventional
files and modern, relational databases?
 What are of fields, records, files, and databases? What are some
examples of each?
 What is a modern data architecture that includes files, operational
databases, data warehouses, personal databases, and work group
databases?
 What are the similarities and differences between the roles of
systems analyst, data administrator, and database administrators as
they relate to databases?
 What is the architecture of a database management system?
Prepared by Kevin C. Dittman for

Systems Analysis & Design Methods
4ed
Copyright Irwin/McGraw-Hill 1998
by J. L. Whitten & L. D. Bentley 1
Database Design
Introduction
 The chapter will address the following questions:

 How does a relational database implement entities, attributes, and
relationships from a logical data model?
 How do you normalize a logical data model to remove impurities
that can make a database unstable, inflexible, and non-scaleable?
 How do you transform a logical data model into a physical,
relational database schema?
 How do you generate SQL code to create the database structures
in a schema?

4ed
Database Design
Conventional Files Versus the Database
 Introduction
 All information systems create, read, update and delete data. This
data is stored in files and databases.
 Files are collections of similar records.
 Databases are collections of interrelated files.
• The key word is interrelated.

• The records in each file must allow for relationships (think of
them as ‘pointers’) to the records in other files.
 In the file environment, data storage is built around the
applications that will use the files.
 In the database environment, applications will be built around the
integrated database.

4ed
Database Design
Information
System
File
Information Information Database Information

File File (consolidated &
System System System
integrated data
from files)
File
Information
System

4ed
Database Design
 The Pros and Cons of Conventional Files

 Pros:
 Conventional files are relatively easy to design and implement
because they are normally based on a single application or

information system.
 Historically, another advantage of conventional files has been
processing speed.
 Cons:
 Duplication of data items in multiple files is normally cited as
the principal disadvantage of file-based systems.

 A significant disadvantage of files is their inflexibility and non-
scaleability.
4ed
Database Design
 The Pros and Cons of Conventional Files

 As legacy file-based systems and applications become candidates
for reengineering, the trend is overwhelmingly in favor of
replacing file-based systems and applications with database
systems and applications.

4ed
Database Design
 The Pros and Cons of Database

 Pros:
 The principal advantage of a database is the ability to share the
same data across multiple applications and systems.

 Database technology offers the advantage of storing data in
flexible formats.
 Databases allow the use of the data in ways not originally
specified by the end-users - data independence.

 The database scope can even be extended without impacting
existing programs that use it.

• New fields and record types can be added to the database without
affecting current programs.

4ed
Database Design
 The Pros and Cons of Database

 Cons:
 Database technology is more complex than file technology.
• Special software, called a database management system (DBMS), is

required.
 A DBMS is still somewhat slower than file technology.
 Database technology requires a significant investment.
• The cost of developing databases is higher because analysts and

programmers must learn how to use the DBMS.
 In order to achieve the benefits of database technology, analysts
and database specialists must adhere to rigorous design principles.
 Another potential problem with the database approach is the
increased vulnerability inherent in the use of shared data.

4ed
Database Design
 Database Design in Perspective

 To fully exploit the advantages of database technology, a database
must be carefully designed.
 The end product is called a database schema, a technical blueprint
of the database.
 Database design translates the data models that were developed for
the system users during the definition phase, into data structures
supported by the chosen database technology.
 Subsequent to database design, system builders will construct
those data structures using the language and tools of the chosen
database technology.

4ed
Database Design
INFORMATION SYSTEMS FRAMEWORK
FOCUS ON FOCUS ON FOCUS ON FOCUS ON FAST

SYSTEM SYSTEM SYSTEM SYSTEM
DATA PROCESSES INTERFACES GEOGRAPHY Methodology
Business Subjects Survey Phase

Customers order zero,
(establish scope and
SYSTEM one, or more products. project plan)
OWNERS Products may be ordered
by zero, one, or more
customers.
(scope)
Study Phase
(establish
Data Requirements
system
PRODUCT
improvement
CUSTOMER
objectives)
product -no
customer-no product -name
customer-name unit-of-measure
SYSTEM customer-rat ing unit-price
S balance-due quantity-available
USERS
Y
S
(requirements) ORDER
T order-no
order-dat e
E
Definition Phase
products-ordered
quantit ies-ordered
M
(establish and
A data models prioritize
N
A Database Schema business system
L
Y PR OD U C T
requirements)
C U STO MER
S product _no [ A lpha( 10)] IN D EX
cus tome r_ no [ A lpha (1 0) ] IND product
EX _name [A lpha (3 2) ]
T SYSTEM cus tome r_ na me [ A lpha( 32 )] unit_ of _mea sure [A lpha (2 )]
cus tome r_ ra ting [ A lpha( 1) ] IN unit_
D EX price [ R eal( 3,2 )]
S DESIGNERS ba la nce_due [ R ea l( 5,2 )] quantit y_ available [ Int e ge r( 4) ]
(specification) OR D ER O R D ER _ PR O D UC T
or de r_ no [ Alpha(12 )] IN D EX O R D ER .order_ no
or de r_ dat e [ D at e(mmddyyyyPR ) O D U C T.produc t_ no
C U STO MER.customer_no quantit y_order ed [Inte ger( 2)
Design Phase
(translate business
requirements into a
Database Programs
technical design)
CREATE TABLE CUSTOMER
SYSTEM (customer_no CHAR(10) NOT NULL
customer_name CHAR(32) NOT NULL
BUILDERS customer _rating CHAR(1) NOT NULL
balance_due DECIMAL(5,2)
CREATE INDEX cust_no_idx on CUSTOMER
(components)
CREATE INDEX cust_rt_idx on CUSTOMER
Implementation
Phase
(translate technical
Existing
design into code)
Existing Interfaces Existing
Existing Applications and Networks
Databases and Technology and
and Technology Technology
Technology

4ed
Database Design
Database Concepts for the Systems Analyst
 Fields
 Fields are common to both files and databases.
 A field is the implementation of a data attribute.
• Fields are the smallest unit of meaningful data to be stored in a file

or database.
 There are four types of fields that can be stored: primary keys,
secondary keys, foreign keys, and descriptive fields.
 Primary keys are fields whose values identify one and only
one record in a file.

 Secondary keys are alternate identifiers for an database.
• A single file in a database may only have one primary key, but it
may have several secondary keys.

4ed
Database Design
 Fields
 There are four types of fields that can be stored: primary keys,
secondary keys, foreign keys, and descriptive fields. (continued)
 Foreign keys are pointers to the records of a different file in a
database.
• Foreign keys are how the database ‘links’ the records of one type
to those of another type.
 Descriptive fields are any other fields that store business data.

4ed
Database Design
 Records
 Fields are organized into records.
 Like fields, records are common to both files and databases.
 A record is a collection of fields arranged in a predefined format.
 During systems design, records will be classified as either fixed-

length or variable-length records.
 Most database systems impose a fixed-length record structure,
meaning that each record instance has the same fields, same
number of fields, and same logical size.
 Variable-length record structures allow different records in the
same file to have different lengths.

• Database systems typically disallow (or, at least, discourage) variable
length records.
4ed
Database Design
 Records
 When a computer program ‘reads’ a record from a database, it
actually retrieves a group or block of records at a time.
 This approach minimizes the number of actual disk accesses.
 A blocking factor is the number of logical records included in
a single read or write operation (from the computer’s

perspective). A block is sometimes called a physical record.
 Today, the blocking factor is usually determined and optimized
by the chosen database technology, but a qualified database

expert may be allowed to fine tune that blocking factor for
performance.

4ed
Database Design
 Files and Tables

 Similar records are organized into groups called files.
 A file is the set of all occurrences of a given record structure.
 In database systems, a file corresponds to a set of similar records;

usually called a table.
 A table is the relational database equivalent of a file.
 Some of the types of files and tables include:

 Master files or tables contain records that are relatively
permanent.
• Once a record has been added to a master file, it remains in the
system indefinitely.
• The values of fields for the record will change over its lifetime, but
the individual records are retained indefinitely.
4ed
Database Design

 Some of the types of files and tables include: (continued)
 Transaction files or tables contain records that describe
business events.
• The data describing these events normally has a limited useful
lifetime.
• In information systems, transaction records are frequently retained
on-line for some period of time.
• Subsequent to their useful lifetime, they are archived off-line.
 Document files and tables contain stored copies of historical
data for easy retrieval and review without the overhead of re-
generating the document.

4ed
Database Design

 Archival files and tables contain master and transaction file
records that have been deleted from on-line storage.

• Records are rarely deleted; they are merely moved from on-line
storage to off-line storage.
• Archival requirements are dictated by government regulation and
the need for subsequent audit or analysis.
 Table look-up files contain relatively static data that can be
shared by applications to maintain consistency and improve
performance.

4ed
Database Design

 Audit files are special records of updates to other files,
especially master and transaction files.

• They are used in conjunction with archive files to recover ``lost’’
data.
• Audit trails are typically built into better database technologies.

4ed
Database Design
 Databases
 Databases provide for the technical implementation of entities and
relationships.
 The history of information systems has led to one inescapable
conclusion:
 Data is a resource that must be controlled and managed!
 Out of necessity, database technology was created so an

organization could maintain and use its data as an integrated whole
instead of as separate data files.

4ed
Database Design
 Databases
 Data Architecture:
 A business’ data architecture is comprised of the files and
databases that store all of the organization’s data, the file and
database technology used to store the data, and the organization
structure set up to manage the data resource.
 Operational databases have been developed to support day-
to-day operations and business transaction processing for major

information systems.

4ed
Database Design
 Databases
 Many information systems shops hesitate to give end-users
access to operational databases, because the volume of

unscheduled reports and queries could overload the computers
and hamper business operations.
• To remedy that problem, data warehouses were developed.
computers.
– Data warehouses store data that is extracted from the
production databases and conventional files.
– Fourth-generation programming languages, query tools, and
decision support tools are then used to generate reports and
analyses off these data warehouses.

4ed
Database Design
 Databases
 Personal computer and local network database technology has
rapidly matured to allow end-users to develop personal and

departmental databases.
• These databases may contain unique data, or they may import data
from conventional files, operational databases, and/or data
warehouses.

4ed
Database Design
 Databases
 To manage the enterprise-wide data resource, a staff of
database specialists may be organized around the following

administrators:
• A data administrator is responsible for the data planning,
definition, architecture, and management.
– One or more database administrators are responsible for the
database technology, database design and construction,
security, backup and recovery, and performance tuning.

4ed
Database Design
Users and
Programmers
Information System
File (built in-house)
A legacy
file-based Information Information
information File
System System
system Operational
(built Database (built
(built in-house) in-house)
Users and
in-house)
Programmers
File
End-User
File Tools
Data
Warehouse
End-User Users
Applications
File Personal
DB
A legacy
file-based
information
system File
Users and (purchased)

Programmers Information
System
Operational Work-Group
Database Database
File (purchased)
End-User
Work Group
Users and
Programmers

4ed
Database Design
 Databases
 Database Architecture:
 Database architecture refers to the database technology
including the database engine, database management utilities,

database CASE tools for analysis and design, and database
application development tools.
 The control center of a database architecture is its database
management system.
• A database management system (DBMS) is specialized computer
software available from computer vendors that is used to create,
access, control, and manage the database. The core of the DBMS is
often called its database engine. The engine responds to specific
commands to create database structures, and then to create, read,
update, and delete records in the database.
4ed
Database Design
 Databases
 A systems analyst, or database analyst, designs the structure of
the data in terms of record types, fields contained in those

record types, and relationships that exist between record types.
 These structures are defined to the database management
system using its data definition language.

• Data definition language (or DDL) is used by the DBMS to
physically establish those record types, fields, and structural
relationships. Additionally, the DDL defines views of the
database. Views restrict the portion of a database that may be used
or accessed by different users and programs. DDLs record the
definitions in a permanent data repository.

4ed
Database Design
Programmers
Systems Analysts
and/or
Database Designers End Users
Host-based
Transaction
Processing
Monitor
(optional)
Data Internal
Manipulation TP Monitor
Language (opt)
DML
Data Proprietary Data

Definition Manipulation
Language Language and/or
DDL Report Writers
Database Management System (DBMS)
Stored Data Metadata

4ed
Database Design
 Databases
 Some data dictionaries include formal, elaborate software that
helps database specialists track metadata – the data about the

data –such as record and field definitions, synonyms, data
relationships, validation rules, help messages, and so forth.
 The database management system also provides a data
manipulation language to access and use the database in

applications.
• A data manipulation language (or DML) is used to create, read,
update, and delete records in the database, and to navigate between
different records and types of records. The DBMS and DML hide the
details concerning how records are organized and allocated to the
disk.
4ed
Database Design
 Databases
 Many DBMSs don’t require the use of a DDL to construct the
database, or a DML to access the database.

• They provide their own tools and commands to perform those
tasks. This is especially true of PC-based DBMSs.
 Many DBMSs also include proprietary report writing and
inquiry tools to allow users to access and format data without
directly using the DML.
 Some DBMSs include a transaction processing monitor (or
TP monitor) that manages on-line accesses to the database, and

ensures that transactions that impact multiple tables are fully
processed as a single unit.
4ed
Database Design
 Databases
 Relational Database Management Systems:
 There are several types of database management systems and they
can be classified according to the way they structure records.

 Early database management systems organized records in
hierarchies or networks implemented with indexes and linked lists.

 Relational databases implement data in a series of tables that are
‘related’ to one another via foreign keys.

• Files are seen as simple two-dimensional tables, also known as
relations.
• The rows are records.
• The columns correspond to fields.

4ed
Database Design
Ordered
Customer places Order sells sold on Product
Product

4ed
Database Design
Customers Table
Customer Number Customer Name Customer …
Balance
10112 Luck Star 1455.77
10113 Pemrose 12.14
10114 Hartman 0.00
10117 K-Jack Industries - 20.00
Orders
Table
Order Customer Number …
Number (foreign key)
A633 10112
A634 10114
A635 10112
Ordered Products Table

Order Product Number Quantity …
Number (foreign key) Ordered
(foreign
key)
A633 77F02 1
A633 77B12 500
A634 77B13 100
A634 77F01 5
A635 77B12 300
A635 77B15 15
Products Table
Product Number Product Description Quantity …
in Stock
77B12 Widget 8000
77B13 Widget 0
77B15 Widget 52
77F01 Gadget 20
77F02 Gadget 2
4ed
Database Design
 Databases
 Both the DDL and DML of most relational databases is called
SQL (which stands for Structured Query Language).

• SQL supports not only queries, but complete database creation and
maintenance.
• A fundamental characteristic of relational SQL is that commands
return ‘a set’ of records, not necessarily just a single record (as in
non-relational database and file technology).

4ed
Database Design
 Databases
 High-end relational databases also extend the SQL language to
support triggers and stored procedures.

• Triggers are programs embedded within a table that are
automatically invoked by a updates to another table.
• Stored procedures are programs embedded within a table that can
be called from an application program.
 Both triggers and stored procedures are reusable because they
are stored with the tables themselves.
• This eliminates the need for application programmers to create the
equivalent logic within each application that use the tables.

4ed
Database Design
Data Analysis for Database Design
 What is a Good Data Model?

 A good data model is simple.
 As a general rule, the data attributes that describe an entity
should describe only that entity.

 A good data model is essentially non-redundant.
 This means that each data attribute, other than foreign keys,
describes at most one entity.

 A good data model should be flexible and adaptable to future
needs.
 We should make the data models as application-independent as
possible to encourage database structures that can be extended

or modified without impact to current programs.
4ed
Database Design
 Data Analysis
 The technique used to improve a data model in preparation for
database design is called data analysis.
 Data analysis is a process that prepares a data model for
implementation as a simple, non-redundant, flexible, and

adaptable database. The specific technique is called
normalization.
• Normalization is a technique that organizes data attributes such
that they are grouped together to form stable, flexible, and
adaptive entities.

4ed
Database Design
 Data Analysis
 Normalization is a three-step technique that places the data model
into first normal form, second normal form, and third normal
form.
 An entity is in first normal form (1NF) if there are no
attributes that can have more than one value for a single
instance of the entity.
 An entity is in second normal form (2NF) if it is already in
1NF, and if the values of all non-primary key attributes are

dependent on the full primary key – not just part of it.
 An entity is in third normal form (3NF) if it is already in
2NF, and if the values of its non-primary key attributes are not
dependent on any other non-primary key attributes.
4ed
Database Design
 Normalization Example
 First Normal Form:
 The first step in data analysis is to place each entity into 1NF.

4ed
Database Design
MEMBER ORDER
------------------Key Data---------------------
Order-Number (PK) MEMBER
----------------Non-Key Data----------------- ---------------------Key Data----------------------
Order-Creation-Date Member-Number (PK1)
sold Order-Automatic-Fill-Date ------------------Non-Key Data-------------------
Member Number (FK1) Member-Name CLUB
Member-Name Member-Status ------------------Key Data----------------------
Member-Address Member-Street-Address Club-Name (PK)
Shipping-Address Member-Daytime-Phone-Number --------------Non-Key Data--------------------
Shipping Instructions Date-of-Last-Order Club-Description
Club-Name (FK2) Member-Balance-Due Club-Charter-Date
Promotion-Number (FK2) Member-Bonus-Balance-Available 1 { Agreement-Number } n
placed enrolls in
0 { Ordered-Product-Description } n Member-Credit-Card-Information 1 { Agreement-Active-Date } n
0 { Ordered-Product-Title } n 1 { Club-Name } n 1 { Agreement-Expiration-Date } n
PRODUCT
1 { Quantity-Ordered } n 1 { Agreement-Number } n
------------Key Data---------------- 1 { Obligation-Period } n
1 { Purchased-Unit-Price } n 1 { Taste Code } n 1 { Required-Number-of-Credits } n
Product-Number (PK1)
1 { Extended-Price } n 1 { Media Preference } n
Universal-Product-Code (PK2) 1 { Bonus-Credits-After-Obligation } n
Order-Sub-Total-Cost 1 { Date-Enrolled } n
--------Non-Key Data-------------
Order-Sales-Tax 1 { Expiration-Date } n
Quantity-in-Stock
Ship-Via-Method 1 { Number-of-Credits-Required } n
Product-Type
Shipping-Charge 1 { Number of Credits-Earned } n
Suggested-Retail-Price
Order-Status
Club-Default-Unit-Price
Prepaid-Amount
Current-Special-Unit-Price
Method-of-Payment
Current-Month-Units-Sold
Current-Year-Units-Sold
Total-Lifetime-Units-Sold sponsors
is a
generates
PROMOTION
MERCHANDISE TITLE ---------Key Data-------------
-------------Key Data--------------- --------------Key Data-------------- Club-Name (PK1)
Product-Number (PK1) Product-Number (PK1) Promotion-Number (PK1)
Universal-Product-Code (PK1) Universal-Product-Code (PK2) -------Non-Key Data--------
---------Non-Key Data------------ ----------Non-Key Data----------- Product-Number (FK1)
Merchandise-Name Title-of-Work features Promotion-Release-Date
Merchandise-Description Title-Cover Promotion-Status
Merchandise-Size Catalog-Description Promotion-Type
Merchasnise-Color Copyright-Date Automatic-Fill-Delay
Unit-of-Measure Entertainment-Category
Credit-Value
is a
AUDIO TITLE VIDEO TITLE GAME TITLE

-------------Key Data--------------- -------------Key Data--------------- -------------Key Data---------------
Product-Number (PK1) Product-Number (PK1) Product-Number (PK1)
Universal-Product-Code (PK1) Universal-Product-Code (PK1) Universal-Product-Code (PK1)
---------Non-Key Data------------ ---------Non-Key Data------------ ---------Non-Key Data------------
Artist Producer Manufacturer
Audio-Category Director Game-Category
Audio-Sub-Category Video-Category Game-Sub-Category
Number-of-Units-in-Package Video-Sub-Category Game-Platform
Audio-Media-Code Closed-Captioned Game-Media-Type
Content-Advisory-Code Language Number-of-Players
Running-Time Parent-Advisory-Code
Video-media-Type
Video-Encoding
Screen-Aspect
MPA-Rating-Code
4ed
Database Design
MEMBER ORDER (1NF)
------------------Key Data---------------------
Order-Number (PK)
----------------Non-Key Data-----------------
Order-Creation-Date
Order-Automatic-Fill-Date
Member Number (FK1)
Member-Name
Member-Address
Shipping-Address
Shipping Instructions
Club-Name (FK2)
Order-Sub-Total-Cost
Order-Sales-Tax
Ship-Via-Method
Shipping-Charge
Order-Status
Prepaid-Amount
MEMBER ORDER (unnormalized)

------------------KeyData---------------------
Order-Number (PK) sells
---------------Non-Key Data-----------------
Order-Creation-Date
Member Number (FK1)
Member-Name
Member-Address
MEMBER ORDERED PRODUCT (1NF)
Shipping-Address
---------------Key Data------------------
Member-Number (PK1) (FK)
Club-Name (FK2)
Product-Number (PK1) (FK)
Promotion-Number (FK2)
-------------Non-Key Data-------------
0 { Ordered-Product-Description } n
Ordered-Product-Description
0 { Ordered-Product-Title } n
CORRECTION Ordered-Product-Title
1 { Quantity-Ordered } n
Quantity-Ordered
1 { Purchased-Unit-Price } n
Purchased-Unit-Price
1 { Extended-Price } n
Extended-Price
Order-Sales-Tax
Ship-Via-Method
Shipping-Charge
Order-Status
Prepaid-Amount
Method-of-Payment sold as
PRODUCT (1NF)
------------Key Data----------------
Universal-Product-Code (PK2)
--------Non-Key Data-------------
Quantity-in-Stock
Product-Type
Total-Lifetime-Units-Sold
4ed
Database Design
CLUB (1NF)
------------------Key Data----------------------
Club-Name (PK)
--------------Non-Key Data--------------------
Club-Description
Club-Charter-Date
establishes
CLUB (unnormalized)
------------------Key Data----------------------
Club-Name (PK) AGREEMENT (1NF)
--------------Non-Key Data-------------------- ----------Key Data-----------------
Club-Description Club-Name (PK1) (FK)
Club-Charter-Date Agreement-Number (PK1)
1 { Agreement-Number } n --------Non-Key Data-------------
1 { Agreement-Active-Date } n CORRECTION Agreement-Active-Date
1 { Agreement-Expiration-Date } n Agreement-Expiration-Date
1 { Obligation-Period } n Obligation-Period
1 { Required-Number-of-Credits } n Required-Number-of-Credits
1 { Bonus-Credits-After-Obligation } n Bonus-Credits-After-Obligation

4ed
Database Design
MEMBER (1NF)
---------------------Key Data----------------------
Member-Number (PK1)
------------------Non-Key Data-------------------
Member-Name
Member-Status
Member-Street-Address
Member-Daytime-Phone-Number
Date-of-Last-Order
Member-Balance-Due
Member-Bonus-Balance-Available
Member-Credit-Card-Information
MEMBER (unnormalized)
---------------------Key Data---------------------- enrolls in
Member-Number (PK1)
------------------Non-Key Data-------------------
Member-Name
Member-Status
Member-Address
Date-of-Last-Order
Member-Balance-Due CLUB MEMBERSHIP (1NF)
Member-Bonus-Balance-Available -------------Key Data--------------
Member-Credit-Card-Information Member-Number (PK1) (FK)
1 { Club-Name } n Club-Name (PK1) (FK)
1 { Agreement-Number } n Agreement-Number (PK1) (FK)
1 { Taste Code } n ---------Non-Key Data-----------
1 { Media Preference } n Taste Code
1 { Date-Enrolled } n Media Preference
1 { Expiration-Date } n Date-Enrolled
CORRECTION Expiration-Date
1 { Number-of-Credits-Required } n
1 { Number of Credits-Earned } n Number-of-Credits-Required
Number of Credits-Earned
binds
AGREEMENT (1NF)
----------Key Data-----------------
Club-Name (PK1) (FK)
Agreement-Number (PK1) sponsors
--------Non-Key Data-------------
Agreement-Active-Date
Agreement-Expiration-Date
Obligation-Period
Required-Number-of-Credits
Bonus-Credits-After-Obligation
establishes
CLUB (1NF)
------------------Key Data----------------------
Club-Name (PK)
--------------Non-Key Data--------------------
Prepared by Kevin C. Dittman for Club-Description
Systems Analysis & Design Methods Club-Charter-Date
4ed
Database Design
 Second Normal Form:
 The next step of data analysis is to place the entities into 2NF.
• It is assumed that you have already placed all entities into 1NF.
• 2NF looks for an anomaly called a partial dependency, meaning
an attribute(s) whose value is determined by only part of the
primary key.
• Entities that have a single attribute primary key are already in
2NF.
• Only those entities that have a concatenated key need to be
checked.

4ed
Database Design
MEMBER ORDERED PRODUCT (1NF)
---------------Key Data------------------ MEMBER ORDERED PRODUCT (2NF)
Member-Number (PK1) (FK) ---------------Key Data------------------
Product-Number (PK1) (FK) Member-Number (PK1) (FK)
-------------Non-Key Data------------- Product-Number (PK1) (FK)
Ordered-Product-Description CORRECTION -------------Non-Key Data-------------
Ordered-Product-Title Quantity-Ordered
Quantity-Ordered Purchased-Unit-Price
Purchased-Unit-Price Extended-Price
Extended-Price
sold as
PRODUCT (2NF)
------------Key Data----------------
Universal-Product-Code (PK2)
--------Non-Key Data-------------
Quantity-in-Stock
Product-Type
Total-Lifetime-Units-Sold
is a
MERCHANDISE (2NF) TITLE (2NF)

-------------Key Data--------------- --------------Key Data--------------
Product-Number (PK1) Product-Number (PK1)
Universal-Product-Code (PK1) Universal-Product-Code (PK2)
---------Non-Key Data------------ ----------Non-Key Data-----------
Merchandise-Name Title-of-Work
Merchandise-Description Title-Cover
Merchandise-Size Catalog-Description
Merchasnise-Color Copyright-Date
Unit-of-Measure Entertainment-Category
Credit-Value

4ed
Database Design
 Third Normal Form:
 Entities are assumed to be in 2NF before beginning 3NF analysis.
 Third normal form analysis looks for two types of problems,
derived data and transitive dependencies.

• In both cases, the fundamental error is that non key attributes are
dependent on other non key attributes.
• Derived attributes are those whose values can either be calculated
from other attributes, or derived through logic from the values of other
attributes.
• A transitive dependency exists when a non-key attribute is dependent
on another non-key attribute (other than by derivation).
• Transitive analysis is only performed on those entities that do not have
a concatenated key.
4ed
Database Design
 Third Normal Form:
 Third normal form analysis looks for two types of problems,
derived data and transitive dependencies. (continued)

• A transitive dependency exists when a non-key attribute is
dependent on another non-key attribute (other than by derivation).
– This error usually indicates that an undiscovered entity is still
embedded within the problem entity.
• Transitive analysis is only performed on those entities that do not
have a concatenated key.
 “An entity is said to be in third normal form if every non-
primary key attribute is dependent on the primary key, the
whole primary key, and nothing but the primary key.”
4ed
Database Design
MEMBER ORDERED PRODUCT (2NF) MEMBER ORDERED PRODUCT (3NF)

---------------Key Data------------------ ---------------Key Data------------------
Member-Number (PK1) (FK) Member-Number (PK1) (FK)
Product-Number (PK1) (FK) CORRECTION Product-Number (PK1) (FK)
-------------Non-Key Data------------- -------------Non-Key Data-------------
Quantity-Ordered Quantity-Ordered
Purchased-Unit-Price Purchased-Unit-Price
Extended-Price Extended-Price

4ed
Database Design
MEMBER (3NF)
---------------------Key Data----------------------
Member-Number (PK1)
------------------Non-Key Data-------------------
Member-Name
Member-Status
Member-Street-Address
Date-of-Last-Order
Member-Balance-Due
Member-Bonus-Balance-Available
Member-Credit-Card-Information
placed
MEMBER ORDER (3NF)

MEMBER ORDER (2NF)
------------------Key Data---------------------
------------------Key Data---------------------
Order-Number (PK)
Order-Number (PK)
----------------Non-Key Data-----------------
----------------Non-Key Data-----------------
Order-Creation-Date
Order-Creation-Date
Member Number (FK1)
Member Number (FK1)
Member-Name
Member-Name
CORRECTION Member-Address
Member-Address
Shipping-Address
Shipping-Address
Club-Name (FK2)
Club-Name (FK2)
Order-Sales-Tax
Order-Sales-Tax
Ship-Via-Method
Ship-Via-Method
Shipping-Charge
Shipping-Charge
Order-Status
Order-Status
Prepaid-Amount
Prepaid-Amount

4ed
Database Design
 Simplification by Inspection:
 When several analysts work on a common application, it is not
unusual to create problems that won’t be taken care of by

normalization.
• These problems are best solved through simplification by
inspection, a process wherein a data entity in 3NF is further
simplified by such efforts as addressing subtle data redundancy.

4ed
Database Design
 CASE Support for Normalization:
 Most CASE tools can only normalize to first normal form.
• They accomplish this in one of two ways.

– They look for many-to-many relationships and resolve those
relationships into associative entities.
– They look for attributes specifically described as having
multiple values for a single entity instance.
 It is exceedingly difficult for a CASE tool to identify second
and third normal form errors.
• That would require the CASE tool to have the intelligence to
recognize partial and transitive dependencies.

4ed
Database Design
File Design
 Introduction.
 Most fundamental entities from the data model would be designed as
master or transaction records.
 The master files a typically fixed length records.
 Associative entities from the data model are typically joined into the
transaction records to form variable length records (based on the one-to-
many relationships).
 Other types of files (not represented in the data model) are added as
necessary.
 Two important considerations of file design are file access and
organization.
 The systems analyst usually studies how each program will access the
records in the file (‘sequentially’ or ‘randomly’), and then select an

appropriate file organization.
4ed
Database Design
Database Design
 Introduction
 The design of any database will usually involve the DBA and
database staff.
 They will handle the technical details and cross-application
issues.
 It is useful for the systems analyst to understand the basic design
principles for relational databases.

4ed
Database Design
Database Design
 Goals and Prerequisites to Database Design

 The goals of database design are as follows:
 A database should provide for the efficient storage, update, and
retrieval of data.
 A database should be reliable – the stored data should have
high integrity to promote user trust in that data.

 A database should be adaptable and scaleable to new and
unforeseen requirements and applications.

4ed
Database Design
Database Design
 Goals and Prerequisites to Database Design

 The data model may have to be divided into multiple data models
to reflect database distribution and database replication decisions.
 Data distribution refers to the distribution of either specific
tables, records, and/or fields to different physical databases.

 Data replication refers to the duplication of specific tables,
records, and/or fields to multiple physical databases.

 Each sub-model or view should reflect the data to be stored on a
single server.

4ed
Database Design
Database Design
 The Database Schema

 The design of a database is depicted as a special model called a
database schema.
 A database schema is the physical model or blueprint for a
database. It represents the technical implementation of the

logical data model.
 A relational database schema defines the database structure in
terms of tables, keys, indexes, and integrity rules.

 A database schema specifies details based on the capabilities,
terminology, and constraints of the chosen database

management system.

4ed
Database Design
Database Design

 Transforming the logical data model into a physical relational
database schema rules and guidelines:
1 Each fundamental, associative, and weak entity is implemented
as a separate table.
• The primary key is identified as such and implemented as an index
into the table.
• Each secondary key is implemented as its own index into the table.
• Each foreign key will be implemented as such.
• Attributes will be implemented with fields.
– These fields correspond to columns in the table.

4ed
Database Design
Database Design

database schema rules and guidelines: (continued)
• The following technical details must usually be specified for each
attribute.
– Data type. Each DBMS supports different data types, and terms for
those data types.
– Size of the Field. Different DBMSs express precision of real numbers
differently.
– NULL or NOT NULL. Must the field have a value before the record can
be committed to storage?
– Domains. Many DBMSs can automatically edit data to ensure that
fields contain legal data.
– Default. Many DBMSs allow a default value to be automatically set in
the event that a user or programmer submits a record without a value.
4ed
Database Design
Database Design

database schema rules and guidelines: (continued)
2 Supertype/subtype entities present additional options as
follows:
• Most CASE tools do not currently support object-like constructs
such as supertypes and subtypes.
• Most CASE tools default to creating a separate table for each
entity supertype and subtype.
• If the subtypes are of similar size and data content, a database
administrator may elect to collapse the subtypes into the supertype
to create a single table.
3 Evaluate and specify referential integrity constraints.
4ed
Database Design
Database Design
 Data and Referential Integrity

 There are at least three types of data integrity that must be
designed into any database - key integrity, domain integrity and
referential integrity.
 Key Integrity:
 Every table should have a primary key (which may be
concatenated).
• The primary key must be controlled such that no two records in
the table have the same primary key value.
• The primary key for a record must never be allowed to have a
NULL value.

4ed
Database Design
Database Design

 Domain Integrity:
 Appropriate controls must be designed to ensure that no field
takes on a value that is outside of the range of legal values.

 Referential Integrity:
 A referential integrity error exists when a foreign key value in
one table has no matching primary key value in the related

table.

4ed
Database Design
Database Design

 Referential integrity is specified in the form of deletion rules as
follows:
• No restriction.
– Any record in the table may be deleted without regard to any
records in any other tables.
• Delete:Cascade.
– A deletion of a record in the table must be automatically
followed by the deletion of matching records in a related table.
• Delete:Restrict.
– A deletion of a record in the table must be disallowed until any
matching records are deleted from a related table.
4ed
Database Design
Database Design

 Referential integrity is specified in the form of deletion rules as
follows: (continued)
• Delete:Set Null.
– A deletion of a record in the table must be automatically
followed by setting any matching keys in a related table to the
value NULL.

4ed
Database Design
Database Design
 Roles
 Some database shops insist that no two fields have exactly the
same name.
 This presents an obvious problem with foreign keys
 A role name is an alternate name for a foreign key that clearly

distinguishes the purpose that the foreign key serves in the table.
 The decision to require role names or not is usually established by
the data or database administrator.

4ed
Database Design
Database Design
 Database Prototypes
 Prototyping is not an alternative to carefully thought out database
schemas.
 On the other hand, once the schema is completed, a prototype
database can usually be generated very quickly.
 Most modern DBMSs include powerful, menu-driven database
generators that automatically create a DDL and generate a
prototype database from that DDL.
 A database can then be loaded with test data that will prove
useful for prototyping and testing outputs, inputs, screens, and

other systems components.

4ed
Database Design
Database Design
 Database Capacity Planning

 A database is stored on disk.
 The database administrator will want an estimate of disk
capacity for the new database to ensure that sufficient disk

space is available.
 Database capacity planning can be calculated with simple
arithmetic as follows.
1 For each table, sum the field sizes.
• This is the record size for the table.

2 For each table, multiply the record size times the number of
entity instances to be included in the table.
• This is the table size.

4ed
Database Design
Database Design
 Database Capacity Planning

 Database capacity planning can be calculated with simple
arithmetic as follows. (continued)
3 Sum the table sizes.
• This is the database size.

4 Optionally, add a slack capacity buffer (e.g., 10%) to account
for unanticipated factors or inaccurate estimates above.
• This is the anticipated database capacity.

4ed
Database Design
Database Design
 Database Structure Generation

 CASE tools are frequently capable of generating SQL code for the
database directly from a CASE-based database schema.
 This code can be exported to the DBMS for compilation.
 Even a small database model can require 50 pages or more of
SQL data definition language code to create the tables, indexes,

keys, fields, and triggers.
 Clearly, a CASE tool’s ability to automatically generate
syntactically correct code is an enormous productivity

advantage.
 Furthermore, it almost always proves easier to modify the
database schema and re-generate the code, than to maintain the

code directly.
4ed
Database Design
The Next Generation of Database Design
 Introduction
 Relational database technology is widely deployed and used in
contemporary information system shops.
 One new technology is slowly emerging that could ultimately
change the landscape dramatically – object database management
systems.
 The heir apparent to relational DBMSs, object database
management systems store true objects, that is, encapsulated

data and all of the processes that can act on that data.
 Because relational database management systems are so widely
used, we don’t expect this change to happen quickly.

• It is expected that these vendors will either build object technology
into their existing relational DBMSs, or they will create new,
object DBMSs and provide for the transition between relational
4ed and object models. Copyright Irwin/McGraw-Hill 1998
Database Design
Summary
 Introduction
 Conventional Files Versus the Database
 Database Concepts for the Systems Analyst
 Data Analysis for Database Design
 File Design
 Database Design
 The Next Generation of Database Design

4ed

CHAPTER 11 Slides

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CHAPTER 11 Slides

Uploaded by

Copyright:

Available Formats

Database Design

 The chapter will address the following questions:

Prepared by Kevin C. Dittman for

 The chapter will address the following questions:

Prepared by Kevin C. Dittman for

Conventional Files Versus the Database

 Databases are collections of interrelated files.

• The key word is interrelated.

Prepared by Kevin C. Dittman for

Information Information Database Information

Prepared by Kevin C. Dittman for

Conventional Files Versus the Database

 The Pros and Cons of Conventional Files

because they are normally based on a single application or

the principal disadvantage of file-based systems.

Conventional Files Versus the Database

 The Pros and Cons of Conventional Files

Prepared by Kevin C. Dittman for

Conventional Files Versus the Database

 The Pros and Cons of Database

same data across multiple applications and systems.

specified by the end-users - data independence.

existing programs that use it.

Prepared by Kevin C. Dittman for

Conventional Files Versus the Database

 The Pros and Cons of Database

• Special software, called a database management system (DBMS), is

• The cost of developing databases is higher because analysts and

increased vulnerability inherent in the use of shared data.

Conventional Files Versus the Database

 Database Design in Perspective

Prepared by Kevin C. Dittman for

FOCUS ON FOCUS ON FOCUS ON FOCUS ON FAST

Business Subjects Survey Phase

S DESIGNERS ba la nce_due [ R ea l( 5,2 )] quantit y_ available [ Int e ge r( 4) ]

Prepared by Kevin C. Dittman for

Database Concepts for the Systems Analyst

• Fields are the smallest unit of meaningful data to be stored in a file

one record in a file.

Prepared by Kevin C. Dittman for

Database Concepts for the Systems Analyst

Prepared by Kevin C. Dittman for

Database Concepts for the Systems Analyst

 During systems design, records will be classified as either fixed-

same file to have different lengths.

Database Concepts for the Systems Analyst

 A blocking factor is the number of logical records included in

a single read or write operation (from the computer’s

by the chosen database technology, but a qualified database

Prepared by Kevin C. Dittman for

Database Concepts for the Systems Analyst

 Files and Tables

 In database systems, a file corresponds to a set of similar records;

 Some of the types of files and tables include:

Database Concepts for the Systems Analyst

 Files and Tables

Prepared by Kevin C. Dittman for

Database Concepts for the Systems Analyst

 Files and Tables

records that have been deleted from on-line storage.

Prepared by Kevin C. Dittman for

Database Concepts for the Systems Analyst

 Files and Tables

especially master and transaction files.