By: Richard Fleischman & Sharon Young Advanced Data Models

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.

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.

ER Diagram Notation – Review  Entity Type  Weak Entity Type  Relationship Type  Identifying Relationship Type

ER Diagram Notation – Review (con’t)  Attribute w/ optional value Attribute_name or Attribute_name  Attribute w/ mandatory value  Unique Identifier  Partial Identifier (key)  Multi-valued attribute

ER Diagram Notation – Review (con’t)  m:n – 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 mn  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 A B

Cardinality  Other Cardinalities  1:n – 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.  n:1 – 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  1:1 – 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.

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.

3.1.1 – Example #1: Subclass-Superclass HourlyEmployeeSalariedEmployee Employee hourlyPayRateweeklyPayRatesickLeaveHours vacationLeaveHours ssn lastName firstName address Specialization circle Subclass connector Superclass connector Inheritance symbol Superclass Employee with its two subclasses

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

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

3.1.1 – Example #2: Specialization Hierarchies Hourly EmploymentSalaried EmploymentCashierSecretaryShipping ClerkStock Clerk Employee weeklyPayRatesickLeaveHours vacationLeaveHours account typingRate efficiency accuracy hourlyPayRate ssn lastName firstName address Superclass Employee with two specialization hierarchies

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

3.1.1 – Example #3: Multiple Inheritance Multiple Inheritance Employee StaffFacultyStudent TeachingAssistant Multiple inheritance of entity class Employee

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

3.1.2 – Example #1a: Constraints Hourly EmploymentSalaried EmploymentCashierSecretaryShipping ClerkStock Clerk Employee weeklyPayRatesickLeaveHours vacationLeaveHours account typingRate efficiency accuracy hourlyPayRate ssn lastName firstName address Constrained EER diagram for Employee d o Disjointness constraint Overlap allowed

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.

3.1.2 – Example #1b: Constraints Hourly EmploymentSalaried EmploymentCashierSecretaryShipping ClerkStock Clerk Employee weeklyPayRatesickLeaveHours vacationLeaveHours account typingRate efficiency accuracy hourlyPayRate ssn lastName firstName address Constrained EER diagram for Employee d o Disjointness constraint Completeness constraint Overlap allowed Partial specialization

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

3.1.2 – Example #1c: Constraints Hourly EmploymentSalaried EmploymentCashierSecretaryShipping ClerkStock Clerk Employee weeklyPayRatesickLeaveHours vacationLeaveHours account typingRate efficiency accuracy hourlyPayRate ssn lastName firstName address Constrained EER diagram for Employee “hourly” “salaried” wageType d o Defining Attribute Value Defining Attribute Value Defining Attribute Value Disjointness constraint Completeness constraint Partial specialization Overlap allowed

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.

3.1.3 – Example: Modeling Unions with Categories Customer Videotape CustomerTransaction TransactionItem RentalSaleInventoryItem Has transId totalSale videoId quantityprice itemId M M M u Completeness constraint Category Subclass Union Specialization Category Subclass

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

3.1.3 – Example: Modeling Unions with Categories Customer Videotape CustomerTransaction TransactionItem RentalSaleInventoryItem Has transId totalSale videoId quantityprice itemId M M M u Completeness constraint Category Subclass Union Specialization Category Subclass

 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) 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 Object-Oriented (OO) Data Modeling

 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) OO Data Modeling - Interfaces

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 Set 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 Set 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 OO Data Modeling - Interface Example

 Customer has property rents as its role in the relationship type  Property definition includes type Set, a multivalued type that specifies the rents role as one to many  Definition of rents also lists inverse role as Rental::renter  The renter property of Rental has the single-valued type Customer which specifies the renter property as to one interface Customer { relationship Set rents inverse Rental::renter; } interface Rental { relationship Customer renter inverse Customer ::rents; } *Figure 3.7 Customer and Rental classes and their relationship properties (pg. 63) OO Data Modeling - Relationship Types

 Representation of relationship types as properties is based on each object’s 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 OO Data Modeling -Relationship Types

 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 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 Set worksIn inverse Store::staff; relationship Store managerOf inverse Store::manager; } interface HourlyEmployee: Employee { attribute float hourlyPayRate; } interface SalariedEmployee: Employee { attribute float weeklyPayRate; attribute integer vacationLeaveHours; attribute integer sickLeaveHours; } *Figure 3.8 ODL Definitions for Employee, Hourly Employee, and SalariedEmployee (pg. 64)  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 OO Data Modeling -Subclasses & Inheritance (cont.)

FIGURE 3.9 ODL SPECIFICATION FOR SOME CLASSES OF BIGHIT VIDEO 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 Set otherUsers; method integer numberRentals(); relationship Set rents inverse Rental::renter; relationship Set rented inverse PreviousRental::customer; }; interface Rental { attribute Date dateDue; attribute Date dateRented; attribute integer cost; relationship Customer renter inverse Customer::rents; relationship Videotape tapeRented inverse Videotape::rentedBy; } interface Videotape { attribute integer videoId; attribute date dateAcquired; attribute string title; attribute string genre; relationship Rental rentedBy inverse Rental::tapeRented; relationship set previouslyRentedBy inverse PreviousRental::tapeRented; relationship Store location inverse Store::videotape; relationship Set orderedBy inverse PurchaseOrder::videotape; };

h DData Modeling and Database Design by Narayan S. Umanath & Richard W. Scamell (Appendix B) PPrinciples of Database Systems With Internet and Java Applications by Greg Riccardi, 2001, Addison-Wesley h h References – For More On OO Data Modeling