Richard Fleischman

1
Chapter 3
Advanced Data Models

• By
• Richard Fleischman Sharon Young

2
Chapter Overview - Objective

• Information systems typically include entities
  that belong in more than one entity class or that
  share properties with entities from different
  classes.
• These concepts correspond to the object-oriented
  notions of inheritance and class hierarchies.
• It is crucial for the conceptual model of the
  information content to accurately represent the
  real objects.

3
Section 3.1 -- Enhanced ER Modeling
4
ER Diagram Definitions - Review

• Entity Type A reference to an object type.
  Objects belonging to an object type are
  considered entities.
• Relationship Types A meaningful association
  among entity types.
• Attributes An entity type (object type) with a
  set of individual (not always unique) properties.
• Cardinality Constraint A constraint that
  specifies the maximum number of entities of an
  entity type to which another entity can be
  associated through a specific relationship set
  expressed as a ratio.

5
ER Diagram Notation Review

• Entity Type

• Weak Entity Type

• Relationship Type

• Identifying Relationship Type

6
ER Diagram Notation Review (cont)

• Attribute w/ optional value

Attribute_name

• Attribute w/ mandatory value

Attribute_name

• Unique Identifier

• Partial Identifier (key)

Attribute_name

• Multi-valued attribute

Attribute_name
7
ER Diagram Notation Review (cont)
m
n

• mn An entity A is associated with any number
  (zero or more) of entities in B and vice versa
• Other relationships are described on the next
  slide

A
B

• Mandatory participation Technically called
  total participation If in order to exist, every
  entity must participate in the relationship

• Partial participation Often called optional
  participation If an entity can exist, without
  participating in the relationship

8
Cardinality

• Other Cardinalities
• 1n An entity in A is associated with any
  number (zero or more) of entities in B an entity
  in B, however, is associated with no more than 1
  entity of A.
• n1 An entity in A is associated with no more
  than 1 entity of B. An entity in B, however, is
  associated with any number (zero or more) of
  entities in A. This is just a reverse of the
  above cardinality
• 11 An entity A is associated with no more than
  1 entity of B and an entity in B is associated
  with no more then 1 entity of A.

9
3.1.1 Inheritance Class Hierarchies

• In certain situations, some objects in a class
  have properties that are not shared by all
  objects in the class.
• In such a case, we might consider that groups of
  objects with shared properties form subclasses of
  the whole class
• The subclass-superclass relationship is an
  inheritance, and are often called is-a
  relationships because a member of the subclass
  is-a member of the superclass.

10
3.1.1 Example 1 Subclass-Superclass
Superclass Employee with its two subclasses
lastName
firstName
ssn
address
Employee
Specialization circle
Superclass connector
Subclass connector
Inheritance symbol
HourlyEmployee
SalariedEmployee
hourlyPayRate
weeklyPayRate
sickLeaveHours
vacationLeaveHours
11
3.1.1 Specialization Generalization

• Class hierarchies are discovered in two ways by
  recognizing that a class has subclasses, called
  specialization, and by recognizing that two or
  more classes have a common superclass, called
  generalization
• The process of figuring and specifying
  differences among objects of a single class is
  called specialization
• When discovery leads to the realization that two
  or more separate classes have common properties,
  we can generalize those class to create a
  superclass with the common properties. This is
  called generalization

12
3.1.1 Specialization Generalization

• An entity class can belong to more than one
  specialization hierarchies.
• Suppose that we want to further characterize
  employees by the jobs that they perform.
• Example Employees can work as a cashier,
  secretary, purchaser, or stock clerk.
• The specialization of employees according to
  their jobs is independent of their specialization
  by wage type

13
3.1.1 Example 2 Specialization Hierarchies
Superclass Employee with two specialization
hierarchies
lastName
firstName
ssn
address
Employee
Hourly Employment
Salaried Employment
Cashier
Secretary
Shipping Clerk
Stock Clerk
efficiency
weeklyPayRate
sickLeaveHours
typingRate
vacationLeaveHours
accuracy
hourlyPayRate
account
14
3.1.1 Multiple Inheritance

• An entity class can also belong to more than one
  generalization. That is it can have more than one
  superclass. In object-oriented designs, this
  structure is called multiple inheritance.
• Example An employee can be either a staff or a
  faculty member (shown in next slide).
• However, a student may be employed as a teaching
  assistant and be both a student and faculty - an
  example of multiple inheritance

15
3.1.1 Example 3 Multiple Inheritance
Multiple inheritance of entity class Employee
Employee
Staff
Faculty
Student
Multiple Inheritance
TeachingAssistant
16
3.1.2 - Constraints and Characterizations of
Specialization Hierarchies

• Questions to think about
• Q1. Is it possible for someone to be both an
  hourly employee and a salaried employee, or both
  a cashier and a stock clerk?
• A1. This question addresses the issue of
  disjointness, the property that an entity can
  belong to a single subclass
• Ex A manager of one store (salaried employee)
  might work overtime at another store as a clerk
  and be paid on an hourly basis. This employee has
  two roles and therefore belongs to both subclasses

17
3.1.2 Example 1a Constraints
Constrained EER diagram for Employee
lastName
firstName
ssn
address
Disjointness constraint
Employee
Overlap allowed
o
d
Hourly Employment
Salaried Employment
Cashier
Secretary
Shipping Clerk
Stock Clerk
efficiency
weeklyPayRate
sickLeaveHours
typingRate
vacationLeaveHours
accuracy
hourlyPayRate
account
18
3.1.2 Constraints and Characterizations of
Specialization Hierarchies

• Q2 Are there employees who are neither salaried
  nor hourly?
• A2 This question addresses the issue of
  completeness, the property stating that an entity
  must belong to at least one subclass.
• In this case, because we can pay employees only
  in one of these two ways, and every employee must
  be paid, it is appropriate to impose a
  completeness constraint.

19
3.1.2 Example 1b Constraints
Constrained EER diagram for Employee
lastName
firstName
ssn
Partialspecialization
address
Disjointness constraint
Employee
Overlap allowed
Completeness constraint
o
d
Hourly Employment
Salaried Employment
Cashier
Secretary
Shipping Clerk
Stock Clerk
efficiency
weeklyPayRate
sickLeaveHours
typingRate
vacationLeaveHours
accuracy
hourlyPayRate
account
20
3.1.2 Constraints and Characterizations of
Specialization Hierarchies

• Q3 Is there an attribute or expression whose
  value determines whether an employee is hourly or
  salaried?
• A3 This third question indicates whether the
  specialization is attribute defined. An attribute
  defined specialization is one in which the value
  of a particular attribute (the defining
  attribute) determines subclass membership.
• In this case, an attribute wageType could be use
  as the basis for discrimination. A value of
  hourly or salaried is appropriate

21
3.1.2 Example 1c Constraints
Constrained EER diagram for Employee
lastName
firstName
ssn
Defining Attribute Value
Partialspecialization
address
Disjointness constraint
Employee
Overlap allowed
wageType
Defining Attribute Value
Completeness constraint
o
d
Defining Attribute Value
hourly
salaried
Hourly Employment
Salaried Employment
Cashier
Secretary
Shipping Clerk
Stock Clerk
efficiency
weeklyPayRate
sickLeaveHours
typingRate
vacationLeaveHours
accuracy
hourlyPayRate
account
22
3.1.3 Modeling Unions with Categories

• A last enhancement to our data model is to allow
  an entity class to be a subset of a union of
  superclasses
• Example (shown in the next slide) We extend a
  business to include the sales of items as well as
  the rentals of them.
• In a single transaction, a customer might rent
  several videotapes and purchase other items.
• The sales receipt for this customer transaction
  includes sales details that come from either
  rentals or purchases.

23
3.1.3 Example Modeling Unions with Categories
1
CustomerTransaction
Has
transId
Completeness constraint
M
totalSale
Union Specialization
TransactionItem
Category Subclass
u
Has
1
M
Customer
M
1
Rental
Sale
InventoryItem
Has
Videotape
Has
1
1
itemId
quantity
price
Category Subclass
videoId
24
3.1.3 Modeling Unions with Categories

• The inheritance symbol (pointing down) is
  attached to a double line that connects the
  subclass TransactionItem to the specialization
  circle which has a u inside to show that it is
  a union. The double line is a completeness
  constraint
• The entity class TransactionItem is called a
  union type or category. A transaction item must
  be a member of exactly one superclass
• The category is different from an entity class,
  in particular because the entities in the
  category do not all have the same key attributes.
• A Rental entity has a key of videoId from the
  Videotape entity
• A Sale entity gets its key from the itemId of its
  InventoryItem entity

25
3.1.3 Example Modeling Unions with Categories
1
CustomerTransaction
Has
transId
Completeness constraint
M
totalSale
Union Specialization
TransactionItem
Category Subclass
u
Has
1
M
Customer
M
1
Rental
Sale
InventoryItem
Has
Videotape
Has
1
1
itemId
quantity
price
Category Subclass
videoId
26
Section 3.2 Object Oriented Data Modeling
27
Object-Oriented (OO) Data Modeling

• An object-oriented model
• is a description of the information content and
  the behavior of a system.
• Differs from ER model
• Includes definitions of the functions/methods
  that are used to manipulate objects
• Comes from the Object Definition Language (ODL)
  a standard language for defining conceptual
  schemas as collections of object classes
• Developed by Object Database Management Group
  (ODMG)
• Defines mappings from ODL to many object-oriented
  programming languages (i.e. C, Java, Smalltalk)

28
Object-Oriented (OO) Data Modeling

• Content of OO model combines a data model and a
  behavior model into a single schema
• ODL supports definition of methods on class
  objects
• An interface definition includes the attributes
  and relationship types of the ER model and adds
  definitions of methods or operations on the data
  members

29
OO Data Modeling -
Interfaces

• Each entity class of the ER model is represented
  by an interface declaration in ODL
• Interface looks like that of a C class
  definition
• Keyword interface
• The name
• Set of property specifications surrounded by
  (set braces)

30
OO Data Modeling -
Interface Example

• interface Customer
• attribute integer accountID
• attribute string lastName
• attribute string firstName
• attribute struct Addr
• string street, string city, string state,
  string zipcode address
• attribute double balance
• attribute Setltstringgt otherUsers
• method integer numberRentals()
• Figure 3.6 Prelimary ODL definition of entity
  class Customer (pg. 62)

• Each line beginning with keyword attribute
  defines a single attribute by listing its type
  and name
• Attribute address is a composite -- defined as a
  Struct called Addr with 4 fields
• Attribute otherUsers is a set -- has type
  Setltstringgt and its value is a set of string
  values
• Attribute numberRentals is derived specified as
  a method with no parameters that returns an
  integer value

31
OO Data Modeling -
Relationship Types

• Customer has property rents as its role in the
  relationship type
• Property definition includes type SetltRentalgt, a
  multivalued type that specifies the rents role as
  one to many
• Definition of rents also lists inverse role as
  Rentalrenter
• The renter property of Rental has the
  single-valued type Customer which specifies the
  renter property as to one

interface Customer relationship
SetltRentalgt rents inverse
Rentalrenter interface Rental
relationship Customer renter inverse
Customer rents Figure 3.7 Customer and
Rental classes and their relationship properties
(pg. 63)
32
OO Data Modeling -
Relationship Types

• Representation of relationship types as
  properties is based on each objects unique
  object identity (OID)
• A relationship property has as its value a unique
  OID for each related object
• No change in values of related objects (not even
  change in attributes) has any effect on relations
• Disadvantage of ODL
• Does not allow naming of relationship types

33
OO Data Modeling -
Subclasses Inheritance

• OO model supports definition of class hierarchies
• Each class has zero or more superclasses and zero
  or more subclasses
• A subclass inherits all of the properties of its
  superclass and may have additional properties
  that are not shared with the parent class

34
(cont.)
OO Data Modeling -
Subclasses Inheritance

• interface Employee
• attribute string ssn
• attribute string lastName
• attribute string firstName
• attribute struct Addr
• string street, string city, string state,
  string zipcode address
• attribute double balance
• relationship SetltStoregt worksIn
• inverse Storestaff
• relationship Store managerOf
• inverse Storemanager
• interface HourlyEmployee Employee
• attribute float hourlyPayRate
• interface SalariedEmployee Employee
• attribute float weeklyPayRate
• attribute integer vacationLeaveHours
• attribute integer sickLeaveHours

• Each entity of class HourlyEmployee and
  SalariedEmployee is also an entity of class
  Employee and has all of the properties of that
  class
• Every employee has attribute properties ssn,
  lastName, firstName, and address as well as
  relationship properties worksIn and managerOf
• Only hourly employees have hourlyPayRate

35
Section 3.3 An oo model for Bighit video
36

• Figure 3.9 ODL specification for some classes of
  bighit video

• interface Rental
• attribute Date dateDue
• attribute Date dateRented
• attribute integer cost
• relationship Customer renter
• inverse Customerrents
• relationship Videotape tapeRented
• inverse VideotaperentedBy
• interface Videotape
• attribute integer videoId
• attribute date dateAcquired
• attribute string title
• attribute string genre
• relationship Rental rentedBy
• inverse RentaltapeRented
• relationship setltPreviousRentalgt
  previouslyRentedBy
• inverse PreviousRentaltapeRented

• interface Customer
• attribute integer accountID
• attribute string lastName
• attribute string firstName
• attribute struct Addr
• string street, string city, string state,
  string zipcode address
• attribute double balance
• attribute Setltstringgt otherUsers
• method integer numberRentals()
• relationship SetltRentalgt rents
• inverse Rentalrenter
• relationship SetltPreviousRentalgt rented
• inverse PreviousRentalcustomer

37
References For More On OO Data Modeling

• http//fria.fri.uniza.sk/kmat/dbs/oodbs/OODBS1b.h
  tm
• Data Modeling and Database Design by Narayan S.
  Umanath Richard W. Scamell (Appendix B)
• Principles of Database Systems With Internet and
  Java Applications by Greg Riccardi , 2001,
  Addison-Wesley
• http//www.cs.sfu.ca/CC/354/zaiane/material/notes/
  Chapter8/node3.html
• http//comjnl.oxfordjournals.org/cgi/content/abstr
  act/31/2/116