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

2. Chapter Objectives Af ter 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.

3. Chapter Objectives (Continued) Af ter studying this chapter you should be able to: – Realize the role of object entities and relations in systems analysis. – Translate a conceptual/logical data model into relational entities. – Integrate classes obtained from different use cases.

5. Object-relational data modeling converts a conceptual/logical object model (i.e. a Class Diagram) into a logical data model based on relational data concepts and object-oriented extensions. Object-relationalData Modeling Object-relational Data Modeling

6. Purposes of Object-Relational Modeling Produce database structures Create entity classes Enhance and finalize the attributes in the data model

7. What Is a Relational Data Model? Based on the concept of entity relationships (tables of data, and relationships) Relationships established by matching primary keys and foreign keys, or to unique indexes Relational DBMSs (RDBMS) are the most commonly used in industry today. Many DBMS vendors have begun adding object-oriented features, thereby creating object-relational models.

8. What Is an Entity? A named, two-dimensional table with the following properties: – Represents an organized set of interrelated data – Contains both horizontal rows and vertical columns of data – Each row represents 1 instance (a record) of a given entity – Each column represents a particular characteristic for that entity – Each row/column intersection value is atomic

9. What Is Normalization? The process of converting complex data structures into well-structured entities and relationships Well-structured – – Contains a minimum amount of redundancies. – Ensures data grouping and dependencies are valid. – Allows rows to be inserted, modified, and deleted without introducing errors or inconsistencies.

10. Consequences of Relations that Are Not Well Structured Insertion anomaly – adding new rows forces user to create duplicate data Updating anomaly – changes in one row force changes in other rows because of duplication Deletion anomaly – deleting rows may cause loss of data that would be needed for other rows Data integrity requires well-structured relationships.

11. The Normal Forms 1 st NF – Minimum requirements for entities 2 nd NF – No partial dependencies on composite keys (neither primary nor other keys) 3 rd NF – No transitive dependencies. No attribute should be dependent on any other non-key attribute Higher normal forms: 4 th, Boyce Codd BCNF, 5 th mainly theoretical, not needed for most entity relationships Main goal is to achieve 3NF for all entities.

12. 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 value of attribute A uniquely determines the value of attribute B. Determinant – the attribute on the left side of the arrow. It determines the value on the right side

13. First Normal Form (1NF) Each row is unique (Must have a non empty unique primary key). Cell content must be atomic (single-value data). (Repeating cells must be placed in separate table) There are no hidden values (row ids, pointers, hidden time stamps, etc.) in the data Column order does not matter. Row order does not matter.

14. Example entity in 1NF: note uniqueness of rows guaranteed by Emp_ID. Primary key is underlined

15. Second Normal Form (2NF) 1NF, plus No partial key functional dependencies If the primary key or other candidate keys are composite keys (composed of more than one attribute) it is possible for an attribute to be functionally dependent on only part of the key. If so, entity is not in 2NF. Example: if fname & lname is composite key, home address (which is dependent on lname only) should not exist in this entity

16. This table has a composite key (Emp_ID and Course) Functional dependencies: Emp_ID  Name, Dept, Salary Emp_ID, Course  Date_Completed Name, Dept, & Salary all have partial key dependency -- They depend on Emp_ID only -- This causes duplication of data of name, dept & salary.

17. Solution: Break the entity into two separate entities. 1. Using key Emp_ID for attributes Name, Dept and Salary. 2. Using keys Emp_ID & Course for attribute Date_completed.

18. 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. If A is the key and B is an attribute, C should not depend on B. All non-key attributes must only depend on Pkey. They must not depend on any other attribute Example: if an entity includes a book ISBN, title, price, author, publisher, and publisher website, the website depends on the publisher, not on the primary key. This entity is not in 3NF.

19. Customer_ID (PK)  Salesperson and Salesperson  Region. This causes a transitive dependency

20. 1. Using key Customer_ID for attributes Customer_name, and Salesperson. 2. Using key Salesperson for attribute Region. Solution: Break the entity into two separate entities.

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

22. Referential Integrity A rule that states that any foreign key value MUST match a primary key (or a unique index/key) value in another entity No foreign key can contain a value that is not present as a primary key (or unique idx) in the other entity

23. Object-Oriented Extensions to Relational Modeling – Generalization – Multivalued attributes (OK to violate atomic data requirement of 1NF ?) – Aggregation/Composition – Object identifiers – Pointers – Behaviors – Richer set of data types (such as objects)

24. Translating Class Diagrams to Object-Relational Model Translate classes Translate relationships Normalize entity relations Merge class entities

25. Relational approach: forces atomic attributes resulting in a second entity Object-relational approach: supports multi-valued attribute Translating Multi-valued Attributes VS. [Phone_Number] being an array

26. Customer (customerId, name, address) Order (orderNo, orderDate, promisedDate, customerId) When constructing 1:N relationship, add a foreign key as an attribute to the entity on the N side. Translating 1:N Relationship

27. Translating M:N Relationship Associative class is translated into an entity whose primary key is a composite of the primary keys of the other two classes, or an independent Pkey with 2 foreign keys to the other two classes. M:N relationship between two classes is translated into a new entity whose primary key is the composite of the primary key of the other two classes, or an independent Pkey with 2 foreign keys to the other two classes. An associative class is simply an M:N relationship with additional attributes

28. Employee ( empId, name ) Project ( projId, description ) Work ( empId, projId, hoursWrk ) Associative class vs. M:N Relationship Work ( empId, projId, hoursWrk ) Skill ( skillId, skillName ) UseSkills( empId, projId, skillId ) Work is an associative class UseSkills is a M:N relationship

29. Unary 1:N relationship is translated by adding a foreign key managerId, which matches the value of empId primary key of another object of the same entity. Translating Unary 1:N Relationship

30. Unary M:N relationship is translated by a creating a new entity (here Prerequisite) whose primary key is the composite of 2 instances of the primary keys of Course entity. Translating Unary M:N Relationship Prerequisite courseId and prerequisiteId point to 2 PKs CourseId of the Course entity

31. Translating Other Relationships Aggregation and Composition – – No support for loosely or tightly coupled associations. – Use the same technique that apply to regular associations. Using 1:N or M:N relationships Generalization – – No uniform standard exists for modeling. – Can use of stereotypes to annotate generalization. – Best approach is to create 3 entities. A superclass and 2 subclasses, then create 2 views that “tie” the superclass to each of the subclasses

32. Merging Classes from Different Use Cases You might find similar or redundant class entities from different use cases. Those should be merged into one. Example: merge

33. Problems with Merging Synonyms – two entities with different attribute names referring to same meaning –Solution – decide on a single standard name Homonyms – two entities with same attribute names referring to two different meanings –Solution – create new attribute for second meaning Dependencies between non-key attributes after merge –Solution – re-normalize the merged entities

34. Recap Af ter studying this chapter we learned to: – Understand relational data concepts and object-relational models. – Data normalization rules. – Translate conceptual data models (class Diagrams) to object relational models. – Merge classes obtained from different use cases