1 / 36

Chapter 3

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

holiday
Download Presentation

Chapter 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. Chapter 3 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

    6. ER Diagram Notation Review (cont) Attribute w/ optional value

    7. ER Diagram Notation Review (cont) 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

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

    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

    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

    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

    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

    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

    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

    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

    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

    26. Section 3.2 Object Oriented Data Modeling

    27. 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. 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. 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. 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<string> 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<string> 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. Customer has property rents as its role in the relationship type Property definition includes type Set<Rental>, 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

    32. 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 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. 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<Store> 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

    35. Section 3.3 An oo model for Bighit video

    36. 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<string> otherUsers; method integer numberRentals(); relationship Set<Rental> rents inverse Rental::renter; relationship Set<PreviousRental> 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<PreviousRental> previouslyRentedBy inverse PreviousRental::tapeRented; relationship Store location inverse Store::videotape; relationship Set<PurchaseOrder> orderedBy inverse PurchaseOrder::videotape; };

    37. http://fria.fri.uniza.sk/~kmat/dbs/oodbs/OODBS1b.htm 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/abstract/31/2/116

More Related