6-1 Prentice Hall, 2007 Topic 6: Object-Relational Modeling Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich,

6-1© Prentice Hall, 2007

Topic 6:Topic 6:Object-Relational ModelingObject-Relational Modeling

Object-Oriented Systems Analysis and Design

Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer

Topic 6 6-2© Prentice Hall, 2007

Chapter ObjectivesChapter 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.


Chapter Objectives Chapter Objectives (Continued)(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.



Object-relational data modeling converts a conceptual data model to a logical data model based on relational and object-oriented technology.


Purposes of Object-Relational Purposes of Object-Relational ModelingModeling

Produce database structuresCreate entity classesEnhance and finalize the attributes

in the data model


What Is a Relational Data Model?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.


What Is a Relation?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)


Example relation: note uniqueness of rows guaranteed by Emp_ID. Primary keys are underlined


What Is Normalization?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


Consequences of Relations that Consequences of Relations that Are Not Well StructuredAre 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.


The Normal FormsThe Normal Forms1st NF – all relations are in 1NF2nd NF – relations with no partial-key

functional dependencies3rd NF – relations with no transitive

functional dependenciesHigher normal forms: 4th, Boyce Codd, 5th –

mainly theoretical, not needed for most OOSAD problems

Main goal is to achieve 3NF for all relations.


What Is a Functional What Is a Functional Dependency?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


Second Normal Form (2NF)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


This table has a composite key (Emp_ID and Course)

Functional dependencies:Emp_ID Name, Dept, SalaryEmp_ID, Course Date_Completed

Name, Dept, and Salary all have partial key dependencies, causing duplication of data.


Solution:

Break the relation into two separate relations.

1:N relationship linked by Emp_ID

No partial key dependencies

Well structured


Third Normal Form (3NF)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


Here, Customer_ID Salesperson, and Salesperson Region, cause a transitive dependency


Break the relation into two separate relations.

1:N relationship linked by SalesPerson

No transitive dependencies

Well structured

Solution:


Primary and Foreign KeysPrimary 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


Referential IntegrityReferential IntegrityA 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


Object-Oriented Extensions to Object-Oriented Extensions to Relational ModelingRelational Modeling

– Generalization– Multivalued attributes (OK to violate atomicity

requirement of 1NF)– Aggregation– Object identifiers– Pointers– Behaviors– Richer set of data types

Object-relational Data Model


Translating Conceptual Data Translating Conceptual Data Model to Object-Relational ModelModel to Object-Relational Model

Translate classesTranslate relationshipsNormalize object relationsMerge object relations


Relational approach, forces atomic attributes

Object-relational approach, with multivalued attribute

Comparison of techniques for translating multivalued attributes


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


Associative class and M:N relationship


Points for Figure 8.11Points for Figure 8.11Associative 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.


Unary 1:N relationship is represented by a foreign key managerID, which matches with the empId primary key of the same relation.


Unary M:N relationship is represented by a separate relation Prerequisite, whose primary key is composed of two primary key values from the Course relation.


Other RelationshipsOther RelationshipsAggregation and Composition – use same

rules that apply to association. Composition is 1:N, aggregation is M:N

Generalization – no uniform standard exists. Can make use of stereotypes to annotate generalizations


Merging Object RelationshipsMerging Object RelationshipsSimilar or redundant object relations can be

merged into oneExample:

merge


Problems with MergingProblems with Merging Synonyms – two relations with different attribute

names referring to same meaning– Solution – decide on a single standard name

Homonyms – two relations with same attribute names referring to different meanings– Solution – create new attribute for second meaning

Dependencies between non-key attributes after merge– Solution – normalize the merged relation


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

6-1 Prentice Hall, 2007 Topic 6: Object-Relational Modeling Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich,

Documents