gnue/geas/doc odmg.txt

[Daniel E. Baumann]

CVSROOT:        /cvsroot/gnue
Module name:    gnue
Changes by:     Daniel E. Baumann <address@hidden>      02/02/08 01:06:46

Modified files:
        geas/doc       : odmg.txt 

Log message:
        Update notes.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/geas/doc/odmg.txt.diff?tr1=1.1&tr2=1.2&r1=text&r2=text

Patches:
Index: gnue/geas/doc/odmg.txt
diff -c gnue/geas/doc/odmg.txt:1.1 gnue/geas/doc/odmg.txt:1.2
*** gnue/geas/doc/odmg.txt:1.1  Fri Feb  8 00:26:07 2002
--- gnue/geas/doc/odmg.txt      Fri Feb  8 01:06:46 2002
***************
*** 4,10 ****
    Object Model
    ============
    - Object Model important because it specifies kinds of semantics
!   that can be defined explicitly to an ODMS (Object Database
    Management System)
    - Object Model determines characteristics of objects, how objects
    can be related to each other, and how objects can be named and
--- 4,10 ----
    Object Model
    ============
    - Object Model important because it specifies kinds of semantics
!   that can be defined explicitly to an ODMS (Object Data
    Management System)
    - Object Model determines characteristics of objects, how objects
    can be related to each other, and how objects can be named and
***************
*** 50,58 ****
--- 50,60 ----
    definition
    - *literal* definition defines only abstract state of a literal type
    - example:
+ 
      interface Employee {...};
      class Person {...};
      struct Complex {float re; float im;};
+ 
    interface Employee only defines the abstract behavior of Employee
    objects, Class Person defines both the abstract behavior and the
    abstract state of Person objects, the struct Complex defines only
***************
*** 82,94 ****
      - supertype is the more general type, subtype is the more
      specialized type
      - e.g., 
        interface Employee {...};
        interface Professor: Employee {...};
        interface Associate_Professor: Professor {...};
      - Associate_Professor is a subtype of Professor; Professor is a
      subtype of employee
      - instance of the subtype is logically instance of the supertype
      - Associate_Professor is instance is logically Professor instance
      - Associate_Professor is special case of Professor
      - subtype's interface can also be refined to specialize state and
!     behavior 
\ No newline at end of file
--- 84,191 ----
      - supertype is the more general type, subtype is the more
      specialized type
      - e.g., 
+ 
        interface Employee {...};
        interface Professor: Employee {...};
        interface Associate_Professor: Professor {...};
+ 
      - Associate_Professor is a subtype of Professor; Professor is a
      subtype of employee
      - instance of the subtype is logically instance of the supertype
      - Associate_Professor is instance is logically Professor instance
      - Associate_Professor is special case of Professor
      - subtype's interface can also be refined to specialize state and
!     behavior 
!     - e.g, a Employee might have an operation for claculate_paycheck
!     - Salaried_Employee and Hourly_Employee might each refine that
!     behavior to relflect specific needs
!     - polymorphic nature of object programming would enable to correct
!     behavior to be invoked at runtime, dependent on the actual type of
!     the instance
!     
!       class Salaried_Employee: Employee {...};
!       class Hourly_Employee: Employee {...};
! 
!     - ODMG model supports multiple inheritance of object behavior
!     - which leaves it possible to inherit operations that have the same
!     - name, but different parameters form 2 interfaces
!     - ODMG disallows name overloading during inheritance
!     - ODL classes are directly instantiable, interface and types cannot
!     be directly instantiated
!     - subtyping refers to inheritance of behavior only; consequently
!     - interfaces may only inherit from interfaces and classes may only
!     inherit form interfaces
!     - due to ambiguities, interfaces may not inherit from classes nor
!     may classes inherit from other classes
!  
!     Inheritance of State
!     ====================
!     - ODMG Object Model defines and EXTENDS relationship for the
!     inheritance if state and behavior
!     - the EXTENDS also applies to only *object* types, only classes,
!     not literals, may inherit state
!     - EXTENDS relationship is single inheritance relationship between
!     classes whereby subordinate class inherits all properties and
!     behavior of class that it extends
!     - e.g.,
! 
!       class Person
!       { 
!         attribute string name;
!         attribute Date birthDate;
!       };
!     
!     // in the following, the colon denotes the ISA relationship
!     // the extends denotes the EXTENDS relationship
!       class EmployeePerson extends Person: Employee
!       {
!         attribute Date hireDAte;
!         attribute Currency payRate;
!         relationship Manager boss inverse manager::subordinates;
!       };
! 
!       class ManagerPerson extends EmployeePerson: Manager
!       {
!         relationship set<Employee> subordinates
!             inverse Employee::boss;
!       };
! 
!     -  EXTENDS relationship is transitive; consequently every
!     ManagerPerson would have a name, a birthDate, a payRate, and a
!     boss
!     - not that since class EmployeePerson inherits behavior from (ISA)
!     Employee, instances of EmployeePerson and ManagerPerson would
!     all support the behavior deifned within this interface
!     - only legal exception to name oveloading occurs when the same
!     property declaration in a class and one of its inherited
!     interfaces
!     - since propeties declared within an interface also have a
!     procedural interface, such redundant declarations are useful
!     in situations where it is desireable to allow relationships to
!     cross distribution boundaries, yet they also constitue part of the 
!     abstract state of the object
!     
!       Extents
!       =======
!       - *extent* of a type is set of all instances of the type within
!       a particular ODMS
!       - if object is instance of type A, then it will of necessity be
!       a member of the extent of A
!       - if type A is subtype of type B, then extent of A is a subset
!       of the extent of B
!       - relational DBMS maintains an extent for every defined table
!       - OMDS schema designer can decide whether the system should
!       automatically maintain the extent of each type
! 
!       Keys
!       ====
!       - in some cases, individual instances of a type can be uniquely
!       identified by the values they carry for some property or set of
!       properties
!       - these identifying properties are called *keys*
!       - in relational model, thse properties are called *candidiate
!       keys*
!       - a *simple key* consustes of a single property
!       - a *compound key* consist of a set of properties
!       - the scope of uniqueness is the extent of the type; type must
!       have an extent to have a key
\ No newline at end of file