Transcript Document 7269217

ITEC 3220M
Using and Designing Database Systems
Instructor: Prof Z. Yang
Course Website:
http://people.yorku.ca/~zyang/itec
3220m.htm
Office: TEL 3049
Appendix G
Object-Oriented Database
Object Orientation
• Object Orientation
– Set of design and development principles
– Based on autonomous computer structures known
as objects
• OO Contribution areas
–
–
–
–
–
Programming Languages
Graphical User Interfaces
Databases
Design
Operating Systems
3
OO Concepts: Objects
• Abstract representation of a real-world entity
– Unique identity
– Embedded properties
– Ability to interact with other objects and self
• OID
– Unique to that object
– Assigned by system at moment of object’s
creation
– Cannot be changed under any circumstances
– Can be deleted only if the object is deleted
– Can never be reused
4
Attributes (Instance Variables)
• Attributes:
– Known as instance variables in OO
environment
• Domain:
– Logically groups and describes the set of
all possible values that an attribute can
have
5
Object State
• Set of values that object’s attributes have at a
given time
• Can vary, although its OID remains the same
• To change the object’s state, change the values
of the object’s attributes
• To change the object’s attribute values, send a
message to the object
– Message will invoke a method
6
Messages and Methods
• Method:
– Code that performs a specific operation on
object’s data
– Protects data from direct and unauthorized
access by other objects
– Used to change the object’s attribute values
or to return the value of selected object
attributes
– Represent real-world actions
7
Classes
• Collection of similar objects with shared
structure (attributes) and behavior
(methods)
• Class instance or object instance
– Each object in a class
8
Object Characteristics
9
Class Hierarchy
• Superclass
• Subclass
• Class lattice
10
Inheritance
• Ability of object to inherit the data
structure and behavior of classes above it
• Single inheritance
– Class has one immediate superclass
11
Inheritance (Cont’d.)
• Multiple
– Class has more than one immediate
superclass
12
Abstract Data Types (ADT)
• Describes a set of similar objects
• Differs from conventional data types
– Operations are user-defined
– Uses encapsulation
• Definitions needed for creation
– Name
– Data representation
– Abstract data type operations and
constraints
13
Object Classification
• Simple
– Only single-valued attributes
– No attributes refer to other object
• Composite
– At least one multivalued attribute
– No attributes refer to other object
• Compound
– At least one attribute that references other object
• Hybrid
– Repeating group of attributes
– At least one refers to other object
• Associative object
14
OO vs. E-R Model Components
15
Class-Subclass Relationship
16
Interobject Relationships
• Attribute-Class Link
• Object’s attribute references another object
• Relationship Representation
– Related classes enclosed in boxes
– Double line on right side indicates mandatory
– Connectivity indicated by labeling each box
• 1:1
• 1:M
• M:N
• M:N with an Intersection Class
17
1:1 and 1:M Relationships
18
Employee-Dependent
Relationship
19
Representing the M:N
Relationship
20
Representing the M:N Relationship with
Associated Attributes
21
Representing the M:N Relationship with
Intersection Class
22
Late and Early Binding
• Late binding
– Data type of attribute not known until
runtime
– Allows different instances of same class to
contain different data types for same
attribute
• Early binding
– Allows database to check data type at
compilation or definition time
23
OODM vs. E-R Data Models
• Object, Entity, and Tuple
– OODM object has behavior, inheritance, and
encapsulation
– OO modeling more natural
• Class, Entity Set, and Table
– Class allows description of data and behavior
– Class allows abstract data types
• Encapsulation and Inheritance
– Object inherits properties of superclasses
– Encapsulation hides data representation and
method
24
OODM vs. E-R Data Models (Cont’d)
• Object ID
– Not supported in relational
models
• Relationships
– OODM
• Interclass references
• Class hierarchy
inheritance
• Access
– Relational models
•SQL
– OODM
•Navigational
•Set-oriented access
– Relational models
• Value-based approach
25
Example
• Using the following ERD to create the
equivalent OO representations.
Item_ID
User_ID
USER
Checkout
ITEM
26
More Example
Assume the following business rules:
• A course contains many sections, but each section has only one
course
• A section is taught by one professor, but each professor may
teach one or more different sections of one or more course
• A section may contain many students, and each student is
enrolled in many sections, but each section belongs to a
different course. (Students my take many courses, but they
cannot take many sections of the same course.)
• Each section is taught in one room, but each room may be used
to teach several different sections of one or more courses
• A professor advises many students, but a student has only one
advisor
27
More Example (Cont’d)
•Identify and describe the main classes of
objects
•Modify your description in part 1 to
include the use of abstract types such as
Name, DOB, and Address
•Create the conceptual OO
representations
28
More Example on OO Database
Using intersection class to represent the following relationship
STUDENT
CLASS
STU_NUM
C
COURSE:
STU_LNAME
C
COURSE
STU_FNAME
C
PROFESSOR:
STU_ADDRESS
C
PROFESSOR
STU_CITY
C
ROOM:
STU_STATE
C
STU_ZIPCODE
C
1
1
1
ROOM
GRADE
SCHEDULE:
M
PROF_NUM
C
CRS_DESCRIPTION C
PROF_NAME
C
CRS_CREDIT
PROF_DOB
D
DEPT_CODE
C
OFFERING:
C
N
M
TEACH_LOAD:
M
CLASS
1
ROOM
M
STUDENT
PROFESSOR
CRS_CODE
CLASS
ENROLL:
ADVISOR:
PROFESSOR
COURSE
N
BLDG_CODE
C
ROOM_NUM
C
ADVISEES:
STUDENT
RESERVATION:
CLASS
M
CLASS
GRADE
N
STU_CUM_GPA
N
STU_SEM_GPA
N
Note: C = Character
D = Date
N = Numeric
29
M
OO Design Example
Design OO conceptual representations for an engineering company, using the
following requirements:
•A customer has a customer identifier. Other important attributes of each
customer include name and address. They can request any number of work
orders from the company.
•The company maintains a list of materials. The data about materials include a
material identifier, a name and cost.
•A work order has a work order number, a creation date, a completion date, a
work address and a set of (one or more) tasks. In addition, each work order has
one optional supervising employee. Each employee has a number assigned by
the company. Other important attributes of each employee include name and
skill.
•Each work order also has a collection of materials. The same material can be
used by any number of work orders. Material requirement includes material
quantity.
•Each task has a task identifier, a task name, an hourly rate and estimated
hours. Tasks are standardized across work orders so that the same task may be
performed on many work orders. We have to keep record of actual hours of each
task on a work order.
30
OO Influences on Relational Model
• Extensibility of new user-defined
(abstract) data types
• Complex objects
• Inheritance
• Procedure calls (rules or triggers)
• System-generated identifiers (OID
surrogates)
31