Chapter 8: Object-Relational Modeling Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer © Prentice Hall, 2004

Chapter Objectives After studying this chapter you should be able to: Understand the relational model. Normalize data to the third normal form. Understand the object-oriented extensions to the relational model. © Prentice Hall, 2004

Chapter Objectives (Continued) After studying this chapter you should be able to: Realize the role of object relations in systems analysis. Translate a conceptual data model into object relations. Integrate object relations obtained from different use cases. © Prentice Hall, 2004

© Prentice Hall, 2004

Object-relational data modeling converts a conceptual data model to a logical data model based on relational and object-oriented technology. © Prentice Hall, 2004

Translating Conceptual Data Model to Object-Relational Model Translate classes Translate relationships Normalize object relations Merge object relations © Prentice Hall, 2004

What Is a Relational Data Model? Based on the concept of relations (tables of data) Relationships established by matching primary and foreign keys Relational DBMSs (RDBMS) are the most commonly used in industry today. Many DBMS vendors have begun adding object-oriented features, creating an object-relational model. © Prentice Hall, 2004

What Is a Relation? A named, two-dimensional table with the following properties: All cells contain are atomic (single-value) data. Entries in columns are from the same set of values (domain range). Each row is unique (i.e. has a nonempty primary key). Column order does not matter. Row order does not matter. This is called First Normal Form (1NF) © Prentice Hall, 2004

Example relation: note uniqueness of rows guaranteed by Emp_ID Example relation: note uniqueness of rows guaranteed by Emp_ID. Primary keys are underlined © Prentice Hall, 2004

What Is Normalization? The process of converting complex data structures into well-structured relations Well-structured relation – a relation that contains a minimum amount of redundancies and allows rows to be inserted, modified, and deleted without introducing errors or inconsistencies © Prentice Hall, 2004

Consequences of Relations that Are Not Well Structured Insertion anomaly – adding new rows forces user to create duplicate data Update anomaly – changes in one row force changes in other rows because of duplication Deletion anomaly – deleting rows may cause a loss of data that would be needed for other future rows Data integrity requires well-structured relations. © Prentice Hall, 2004

The Normal Forms 1st NF – all relations are in 1NF 2nd NF – relations with no partial-key functional dependencies 3rd NF – relations with no transitive functional dependencies Higher normal forms: 4th, Boyce Codd, 5th – mainly theoretical, not needed for most OOSAD problems Main goal is to achieve 3NF for all relations. © Prentice Hall, 2004

What Is a Functional Dependency? The functional dependency of attribute B on attribute A is represented by an arrow A  B, and implies that every valid value of attribute A uniquely determines the value of attribute B. Determinant – the attribute on the left side of the arrow All primary keys are determinants © Prentice Hall, 2004

Second Normal Form (2NF) 1NF, plus no partial key functional dependencies If the primary key is a composite key (composed of more than one attribute) it is possible for an attribute to be functionally dependent on only part of the key Avoid partial dependencies for 2NF © Prentice Hall, 2004

This table has a composite key (Emp_ID and Course) Functional dependencies: Emp_ID  Name, Dept, Salary Emp_ID, Course  Date_Completed Name, Dept, and Salary all have partial key dependencies, causing duplication of data. © Prentice Hall, 2004

Break the relation into two separate relations. Solution: Break the relation into two separate relations. 1:N relationship linked by Emp_ID No partial key dependencies Well structured © Prentice Hall, 2004

Third Normal Form (3NF) 2NF, plus no transitive functional dependencies Given three attributes in a relation A, B, C, if A  B and B  C, this forms a transitive functional dependency Avoid transitive dependencies for 3NF © Prentice Hall, 2004

Here, Customer_ID  Salesperson, and Salesperson  Region, cause a transitive dependency © Prentice Hall, 2004

Solution: Break the relation into two separate relations. 1:N relationship linked by SalesPerson No transitive dependencies Well structured © Prentice Hall, 2004

Primary and Foreign Keys Primary key – one or more attributes that together form a unique identifier for rows in the relation Foreign key – an attribute that appears as a non-primary key attribute or as part of a primary key in one relation and as a primary key attribute in another relation Relationship – rows in one relation are matched with related rows in another relation through foreign keys © Prentice Hall, 2004

Referential Integrity A rule that states that any foreign key value (on the relation of the many side) MUST match a primary key value in the relation of the one side No foreign key can contain a value that is not present in a primary key in the other relation © Prentice Hall, 2004

Object-Oriented Extensions to Relational Modeling Generalization Multivalued attributes (OK to violate atomicity requirement of 1NF) Aggregation Object identifiers Pointers Behaviors Richer set of data types © Prentice Hall, 2004

Translating Conceptual Data Model to Object-Relational Model Translate classes Translate relationships Normalize object relations Merge object relations © Prentice Hall, 2004

Comparison of techniques for translating multivalued attributes Relational approach, forces atomic attributes Comparison of techniques for translating multivalued attributes Object-relational approach, with multivalued attribute © Prentice Hall, 2004

When constructing 1:N relationships, the foreign key is added as an attribute to the relation on the N side. © Prentice Hall, 2004

Associative class and M:N relationship © Prentice Hall, 2004

Points for Figure 8.11 Associative class is translated into a relation whose primary key is a composite of the primary keys of the other two classes. M:N relationship between Work and Skill is implemented as an extra relation UseSkills, whose primary key is composed of the primary keys of Work and Skill. © Prentice Hall, 2004

Recursive 1:N relationship is represented by a foreign key managerID, which matches with the empId primary key of the same relation. © Prentice Hall, 2004

Recursive M:N relationship is represented by a separate relation Prerequisite, whose primary key is composed of two primary key values from the Course relation. © Prentice Hall, 2004

Recap After studying this chapter we learned to: Understand relational and object-relational models. Normalize data. Understand role of object-relations. Translate conceptual data models to object relations. Integrate object relations. © Prentice Hall, 2004