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

© 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

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

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

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

© 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

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

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

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

© 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

© 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

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

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

© 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

© 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

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

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

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

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

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

© 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

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

© 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

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

A Normalization Example © Shelly and Rosenblatt 2011

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

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

© 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

© 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

© 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

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

© 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

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

© 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

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