1. MIS 322 – Enterprise Business Process Analysis
Ch. 9: Designing Databases
Dr. Terence Saldanha

2. © 2011 Pearson Education, Inc. Publishing as Prentice Hall
Introduction
FIGURE 9-1
Systems development life cycle with design phase highlighted
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

3. Relational Database Model
Relation: a named, two-dimensional table of data; each relation consists of a set of named columns and an arbitrary number of unnamed rows
Relational database model: data represented as a set of related tables or relations
Relations have several properties that distinguish them from nonrelational tables:
Entries in cells are simple.
Entries in columns are from the same set of values.
Each row is unique.
The sequence of columns can be interchanged without changing the meaning or use of the relation.
The rows may be interchanged or stored in any sequence.
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

4. Transforming E-R Diagrams into Relations
It is useful to transform the conceptual data model into a set of normalized relations.
Steps
Represent entities.
Represent relationships.
Normalize the relations.
Merge the relations.
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

5. Representing Entities
Each regular entity is transformed into a relation.
The identifier of the entity type becomes the primary key of the corresponding relation.
The primary key must satisfy the following two conditions.
The value of the key must uniquely identify every row in the relation.
The key should be nonredundant.
The entity type label is translated into a relation name.
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

6. © 2011 Pearson Education, Inc. Publishing as Prentice Hall
The procedure for representing relationships depends on both the degree of the relationship – unary, binary, ternary – and the cardinalities of the relationship.
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

7. Binary 1:N Relationships
Binary 1:N Relationship is represented by adding the primary key attribute (or attributes) of the entity on the one side of the relationship as a foreign key in the relation that is on the many side of the relationship.
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

8. Binary or Unary 1:1Relationships
Binary or Unary 1:1 Relationship is represented by any of the following choices:
Add the primary key of A as a foreign key of B.
Add the primary key of B as a foreign key of A.
Both of the above.
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

9. Binary and Higher-Degree M:N Relationships
Create another relation and include primary keys of all relations as primary key of new relation
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

10. © 2011 Pearson Education, Inc. Publishing as Prentice Hall
Unary Relationships
Unary 1:N Relationship
Is modeled as a relation
Primary key of that relation is the same as for the entity type
Foreign key is added to the relation that references the primary key values
Recursive foreign key: a foreign key in a relation that references the primary key values of that same relation
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

11. © 2011 Pearson Education, Inc. Publishing as Prentice Hall
Unary Relationships
Unary M:N Relationship
Is modeled as one relation
Create a separate relation the represent the M:N relationship
Primary key of new relation is a composite key of two attributes that both take their values from the same primary key
Any attribute associated with the relationship is included as a nonkey attribute in this new relation
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

12. Standard Table Notation
7/2/2018Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

13. Normalization and Rules of Normalization
Normalization: the process of converting complex data structures into simple, stable data structures
Unnormalized Form
Multi-valued Attributes
Normal Forms
First Normal Form (1NF)
Unique rows, no multi-valued attributes (no repeating groups)
Second Normal Form (2NF)
Each non-primary key attribute is identified by the whole key (called full functional dependency)
Third Normal Form (3NF)
Non-primary key attributes do not depend on each other (i.e. no transitive dependencies)
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

14. © Shelly and Rosenblatt 2011
Unnormalized Table
A table that contains a repeating group (multivalued attributes) is in “unnormalized” form
ORDER (ORDER-NUM, ORDER-DATE, (PRODUCT-NUM, PRODUCT-DESC, NUM-ORDERED))
© Shelly and Rosenblatt 2011

15. © Shelly and Rosenblatt 2011
First Normal Form – 1NF
A table is in first normal form(1NF ) if it does not contain a repeating group. To convert an unnormalized design to 1NF, you must expand the table's primary key to include the primary key of the repeating group.
ORDER (ORDER-NUM, ORDER-DATE, PRODUCT-NUM, PRODUCT-DESC, NUM-ORDERED)
7/2/2018Chapter 9
© Shelly and Rosenblatt 2011

16. Functional Dependency
For a given relation, attribute B is functionally dependent on attribute A if, for every valid value of A, that value of A uniquely determines the value of B.
The functional dependence of B on A is represented by A→B.
Functional dependency is not a mathematical dependency.
Knowledge of problem domain is most reliable method for identifying functional dependency.
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

17. Second Normal Form (2NF)
A relation is in second normal form (2NF) if any of the following conditions apply:
Every nonprimary key attribute is functionally dependent on the full set of primary key attributes.
The primary key consists of only one attribute.
No nonprimary key attributes exist in the relation.
ORDER (ORDER-NUM, ORDER-DATE)
PRODUCT (PRODUCT-NUM, PRODUCT-DESC)
ORDER-LINE (ORDER-NUM, PRODUCT-NUM, NUM-ORDERED)
7/2/2018Chapter 9
© Shelly and Rosenblatt 2011

18. How to convert from 1NF to 2NF – Step 1
Step 1: Create and name a separate table for each field in the existing primary key. For example, in the previous example, the ORDER table's primary key has two fields, ORDER-NUM and PRODUCT-NUM, so you must create two tables. The ellipsis (…) indicates that fields will be assigned later. The result is:
ORDER (ORDER-NUM,…)
PRODUCT (PRODUCT-NUM,…)
© Shelly and Rosenblatt 2011

19. How to convert from 1NF to 2NF – Step 2
Step 2: Create a new table for each possible combination of the original primary key fields. In the example, you would create and name a new table with a combination primary key of ORDER-NUM and PRODUCT-NUM. This table describes individual lines in an order, so it is named ORDER-LINE, as shown:
ORDER-LINE (ORDER-NUM, PRODUCT-NUM,…)
© Shelly and Rosenblatt 2011

20. How to convert from 1NF to 2NF – Step 3
Step 3: Study the three tables and place each field with its appropriate primary key, which is the minimal key on which it functionally depends. When you finish placing all the fields, remove any table that did not have any additional fields assigned to it. The remaining tables are the 2NF version of your original table. In the example, the three tables would be shown as:
ORDER (ORDER-NUM, ORDER-DATE)
PRODUCT (PRODUCT-NUM, PRODUCT-DESC)
ORDER-LINE (ORDER-NUM, PRODUCT-NUM, NUM-ORDERED)
© Shelly and Rosenblatt 2011

21. © Shelly and Rosenblatt 2011
Third Normal Form (3NF)
A relation is in third normal form (3NF) if it is in second normal form (2NF) and there are no functional (transitive) dependencies between two (or more) nonprimary key attributes.
To convert the table from 2NF to 3NF, you must remove all fields from the 2NF table that depend on another nonkey field and place them in a new table that uses the nonkey field as a primary key.
© Shelly and Rosenblatt 2011

22. Third Normal Form (3NF) – Another example
A relation is in third normal form (3NF) if it is in second normal form (2NF) and there are no functional (transitive) dependencies between two (or more) nonprimary key attributes.
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

23. © 2011 Pearson Education, Inc. Publishing as Prentice Hall
FIGURE 9-16
Class diagram corresponding to normalized relations of Hoosier Burger‘s inventory control system
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

24. Relations for Hoosier Burger
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

25. A Normalization Example
© Shelly and Rosenblatt 2011

26. Q1. Represent this table in standard Table notation.
STUDENT (STUDENT-NUMBER, STUDENT-NAME, TOTAL-CREDITS, GPA, ADVISOR-NUMBER, ADVISOR-NAME, (COURSE-NUMBER, COURSE-DESC, NUM-CREDITS, GRADE))
© Shelly and Rosenblatt 2011

27. Q2. What form is this table in? Unnormalized? 1NF? 2NF?3NF?
This table is in Unnormalized form.
Why? Because it contains a repeating group.
© Shelly and Rosenblatt 2011

28. © Shelly and Rosenblatt 2011
Q3. Convert the table to first normal form and represent it in standard table notation.
STUDENT (STUDENT-NUMBER, STUDENT-NAME, TOTAL-CREDITS, GPA, ADVISOR-NUMBER, ADVISOR-NAME, COURSE-NUMBER, COURSE-DESC, NUM-CREDITS, GRADE)
© Shelly and Rosenblatt 2011

29. © Shelly and Rosenblatt 2011
Q3. Convert the table to second normal form and represent it in standard table notation.
Step 1: Create Tables with primary keys and combinations
STUDENT (STUDENT-NUMBER, … )
COURSE(COURSE-NUMBER, …)
GRADEINFO(STUDENT-NUMBER, COURSE-NUMBER,…)
Step 2: Add the non-key attributes which are functionally dependent on minimal keys
STUDENT (STUDENT-NUMBER, STUDENT-NAME, TOTAL-CREDITS, GPA, ADVISOR-NUMBER, ADVISOR-NAME)
COURSE(COURSE-NUMBER, COURSE-DESC, NUM-CREDITS)
GRADEINFO(STUDENT-NUMBER, COURSE-NUMBER, GRADE)
Step 3: Drop any tables where there is no additional column other than the primary key.
Step 4:Remaining tables are in 2NF form. Verify that condition for 2NF is satisfied: Table is in 1NF and
Every non primary-key attribute is functionally dependent on whole primary key.
© Shelly and Rosenblatt 2011

30. © Shelly and Rosenblatt 2011
Q3. Convert the table to third normal form and represent it in standard table notation.
Table is in 3NF if it is in 2NF and there are no transitive dependencies (No non-primary key attributes are functionally dependent on each other).
Separate them into a separate table.
STUDENT (STUDENT-NUMBER, STUDENT-NAME, TOTAL-CREDITS, GPA, ADVISOR-NUMBER)
ADVISOR (ADVISOR-NUMBER, ADVISOR-NAME)
COURSE(COURSE-NUMBER, COURSE-DESC, NUM-CREDITS)
GRADEINFO(STUDENT-NUMBER, COURSE-NUMBER, GRADE)
© Shelly and Rosenblatt 2011

31. Physical File and Database Design
The following information is required:
Normalized relations, including volume estimates
Definitions of each attribute
Descriptions of where and when data are used, entered, retrieved, deleted, and updated (including frequencies)
Expectations or requirements for response time and data integrity
Descriptions of the technologies used for implementing the files and database
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

32. © 2011 Pearson Education, Inc. Publishing as Prentice Hall
Choosing Data Types
Selecting a data type balances four objectives:
Minimize storage space.
Represent all possible values of the field.
Improve data integrity of the field.
Support all data manipulations desired on the field.
Examples: CHAR, LONG, NUMBER
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

33. Controlling Data Integrity
Default Value: a value a field will assume unless an explicit value is entered for that field
Range Control: limits range of values that can be entered into field
Both numeric and alphanumeric data
Referential Integrity: an integrity constraint specifying that the value (or existence) of an attribute in one relation depends on the value (or existence) of the same attribute in another relation
Null Value: a special field value, distinct from zero, blank, or any other value, that indicates that the value for the field is missing or otherwise unknown
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

34. © 2011 Pearson Education, Inc. Publishing as Prentice Hall
Summary
Normalization, functional dependency, foreign key, referential integrity, field, data type, null value,
Explain the role of designing databases in the analysis and design of an information system.
Chapter 9
© 2011 Pearson Education, Inc. Publishing as Prentice Hall

35. Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America.
Copyright © 2011 Pearson Education, Inc.  
Publishing as Prentice Hall