Chapter 2 Relational Database Design and Normalization August 2016 1

1

Chapter 2Relational Database Design and Normalization

August 2016

2

Conventional Files Versus the Database

• 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.

3

• Databases– Database Architecture:

• 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.

4

Database Management System (DBMS)

Data Definition Language

DDL

Data Manipulation

Language DML

Proprietary Data Manipulation

Language and/or Report Writers

Host-based Transaction Processing

Monitor (optional)

Internal TP Monitor

(opt)

Stored Data Metadata

Programmers

End Users

Systems Analysts and/or

Database Designers

5

Database Concepts


• 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.

6

Database Concepts


• 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.

7

Database Concepts

• 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.

8

sells sold onOrdered Product

Customer Order Productplaces

9

Customers TableCustomer Number Customer Name Customer

Balance…

10112 Luck Star 1455.7710113 Pemrose 12.1410114 Hartman 0.0010117 K-Jack Industries - 20.00

OrdersTableOrderNumber

Customer Number(foreign key)

…

A633 10112A634 10114A635 10112

Ordered Products TableOrderNumber(foreignkey)

Product Number(foreign key)

QuantityOrdered

…

A633 77F02 1A633 77B12 500A634 77B13 100A634 77F01 5A635 77B12 300A635 77B15 15

Products TableProduct Number Product Description Quantity

in Stock…

77B12 Widget 800077B13 Widget 077B15 Widget 5277F01 Gadget 2077F02 Gadget 2

10

Database Concepts for the Systems Analyst


• 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).

11

Database Concepts for the Systems Analyst


• 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.

12

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.

13


• 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.

14


• 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.

15


• Normalization Example– First Normal Form:

• The first step in data analysis is to place each entity into 1NF.

16

MEMBER ORDER ------------------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) Promotion-Number (FK2) 0 { Ordered-Product-Description } n 0 { Ordered-Product-Title } n 1 { Quantity-Ordered } n 1 { Purchased-Unit-Price } n 1 { Extended-Price } n Order-Sub-Total-Cost Order-Sales-Tax Ship-Via-Method Shipping-Charge Order-Status Prepaid-Amount Method-of-Payment

PRODUCT ------------Key Data---------------- Product-Number (PK1) Universal-Product-Code (PK2) --------Non-Key Data------------- Quantity-in-Stock Product-Type Suggested-Retail-Price Club-Default-Unit-Price Current-Special-Unit-Price Current-Month-Units-Sold Current-Year-Units-Sold Total-Lifetime-Units-Sold

sold

MERCHANDISE -------------Key Data--------------- Product-Number (PK1) Universal-Product-Code (PK1) ---------Non-Key Data------------ Merchandise-Name Merchandise-Description Merchandise-Size Merchasnise-Color Unit-of-Measure

TITLE --------------Key Data-------------- Product-Number (PK1) Universal-Product-Code (PK2) ----------Non-Key Data----------- Title-of-Work Title-Cover Catalog-Description Copyright-Date Entertainment-Category Credit-Value

AUDIO TITLE -------------Key Data--------------- Product-Number (PK1) Universal-Product-Code (PK1) ---------Non-Key Data------------ Artist Audio-Category Audio-Sub-Category Number-of-Units-in-Package Audio-Media-Code Content-Advisory-Code

VIDEO TITLE -------------Key Data--------------- Product-Number (PK1) Universal-Product-Code (PK1) ---------Non-Key Data------------ Producer Director Video-Category Video-Sub-Category Closed-Captioned Language Running-Time Video-media-Type Video-Encoding Screen-Aspect MPA-Rating-Code

GAME TITLE -------------Key Data--------------- Product-Number (PK1) Universal-Product-Code (PK1) ---------Non-Key Data------------ Manufacturer Game-Category Game-Sub-Category Game-Platform Game-Media-Type Number-of-Players Parent-Advisory-Code

is a

is a

MEMBER ---------------------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 1 { Club-Name } n 1 { Agreement-Number } n 1 { Taste Code } n 1 { Media Preference } n 1 { Date-Enrolled } n 1 { Expiration-Date } n 1 { Number-of-Credits-Required } n 1 { Number of Credits-Earned } n

placed

CLUB ------------------Key Data---------------------- Club-Name (PK) --------------Non-Key Data-------------------- Club-Description Club-Charter-Date 1 { Agreement-Number } n 1 { Agreement-Active-Date } n 1 { Agreement-Expiration-Date } n 1 { Obligation-Period } n 1 { Required-Number-of-Credits } n 1 { Bonus-Credits-After-Obligation } n

PROMOTION ---------Key Data------------- Club-Name (PK1) Promotion-Number (PK1) -------Non-Key Data-------- Product-Number (FK1) Promotion-Release-Date Promotion-Status Promotion-Type Automatic-Fill-Delay

enrolls in

sponsors

generates

features

17

MEMBER ORDER (unnormalized) ------------------KeyData--------------------- 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) Promotion-Number (FK2) 0 { Ordered-Product-Description } n 0 { Ordered-Product-Title } n 1 { Quantity-Ordered } n 1 { Purchased-Unit-Price } n 1 { Extended-Price } n Order-Sub-Total-Cost Order-Sales-Tax Ship-Via-Method Shipping-Charge Order-Status Prepaid-Amount Method-of-Payment

PRODUCT (1NF) ------------Key Data---------------- Product-Number (PK1) Universal-Product-Code (PK2) --------Non-Key Data------------- Quantity-in-Stock Product-Type Suggested-Retail-Price Club-Default-Unit-Price Current-Special-Unit-Price Current-Month-Units-Sold Current-Year-Units-Sold Total-Lifetime-Units-Sold

MEMBER ORDERED PRODUCT (1NF) ---------------Key Data------------------ Member-Number (PK1) (FK) Product-Number (PK1) (FK) -------------Non-Key Data------------- Ordered-Product-Description Ordered-Product-Title Quantity-Ordered Purchased-Unit-Price Extended-Price

CORRECTION

sold as

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

sells

18

CLUB (unnormalized) ------------------Key Data---------------------- Club-Name (PK) --------------Non-Key Data-------------------- Club-Description Club-Charter-Date 1 { Agreement-Number } n 1 { Agreement-Active-Date } n 1 { Agreement-Expiration-Date } n 1 { Obligation-Period } n 1 { Required-Number-of-Credits } n 1 { Bonus-Credits-After-Obligation } n

CLUB (1NF) ------------------Key Data---------------------- Club-Name (PK) --------------Non-Key Data-------------------- Club-Description Club-Charter-Date

CORRECTION

AGREEMENT (1NF) ----------Key Data----------------- Club-Name (PK1) (FK) Agreement-Number (PK1) --------Non-Key Data------------- Agreement-Active-Date Agreement-Expiration-Date Obligation-Period Required-Number-of-Credits Bonus-Credits-After-Obligation

establishes

19

MEMBER (unnormalized) ---------------------Key Data---------------------- Member-Number (PK1) ------------------Non-Key Data------------------- Member-Name Member-Status Member-Address Member-Daytime-Phone-Number Date-of-Last-Order Member-Balance-Due Member-Bonus-Balance-Available Member-Credit-Card-Information 1 { Club-Name } n 1 { Agreement-Number } n 1 { Taste Code } n 1 { Media Preference } n 1 { Date-Enrolled } n 1 { Expiration-Date } n 1 { Number-of-Credits-Required } n 1 { Number of Credits-Earned } n

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

CLUB MEMBERSHIP (1NF) -------------Key Data-------------- Member-Number (PK1) (FK) Club-Name (PK1) (FK) Agreement-Number (PK1) (FK) ---------Non-Key Data----------- Taste Code Media Preference Date-Enrolled Expiration-Date Number-of-Credits-Required Number of Credits-Earned

CLUB (1NF) ------------------Key Data---------------------- Club-Name (PK) --------------Non-Key Data-------------------- Club-Description Club-Charter-Date

AGREEMENT (1NF) ----------Key Data----------------- Club-Name (PK1) (FK) Agreement-Number (PK1) --------Non-Key Data------------- Agreement-Active-Date Agreement-Expiration-Date Obligation-Period Required-Number-of-Credits Bonus-Credits-After-Obligation

enrolls in

binds

establishes

sponsors

CORRECTION

20


• Normalization Example– 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.

21

PRODUCT (2NF) ------------Key Data---------------- Product-Number (PK1) Universal-Product-Code (PK2) --------Non-Key Data------------- Quantity-in-Stock Product-Type Suggested-Retail-Price Club-Default-Unit-Price Current-Special-Unit-Price Current-Month-Units-Sold Current-Year-Units-Sold Total-Lifetime-Units-Sold

MEMBER ORDERED PRODUCT (1NF) ---------------Key Data------------------ Member-Number (PK1) (FK) Product-Number (PK1) (FK) -------------Non-Key Data------------- Ordered-Product-Description Ordered-Product-Title Quantity-Ordered Purchased-Unit-Price Extended-Price

MEMBER ORDERED PRODUCT (2NF) ---------------Key Data------------------ Member-Number (PK1) (FK) Product-Number (PK1) (FK) -------------Non-Key Data------------- Quantity-Ordered Purchased-Unit-Price Extended-Price

MERCHANDISE (2NF) -------------Key Data--------------- Product-Number (PK1) Universal-Product-Code (PK1) ---------Non-Key Data------------ Merchandise-Name Merchandise-Description Merchandise-Size Merchasnise-Color Unit-of-Measure

TITLE (2NF) --------------Key Data-------------- Product-Number (PK1) Universal-Product-Code (PK2) ----------Non-Key Data----------- Title-of-Work Title-Cover Catalog-Description Copyright-Date Entertainment-Category Credit-Value

is a

sold as

CORRECTION

22


• Normalization Example– 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.

23


• Normalization Example– 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.”

24



CORRECTION

25

MEMBER (3NF) ---------------------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



CORRECTION

placed

26


• 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.

27


– 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.

28

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.

29

Database Design

• The Database Schema– 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.

30

Database Design


relational 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.

31

Database Design


relational 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.

32

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.

33

Database Design

• Data and Referential Integrity– 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.

34

Database Design

• Data and Referential Integrity– Referential Integrity:

• 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.

35

Database Design

• Data and Referential Integrity– Referential Integrity:

• 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.

36

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.

Documents

Chapter 2 Relational Database Design and Normalization August 2016 1