gnue/geas/doc odmg.txt

[Daniel E. Baumann]

CVSROOT:        /cvsroot/gnue
Module name:    gnue
Changes by:     Daniel E. Baumann <address@hidden>      02/02/26 00:24:49

Modified files:
        geas/doc       : odmg.txt 

Log message:
        Add attributes and relationship definitions/notes.

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

Patches:
Index: gnue/geas/doc/odmg.txt
diff -c gnue/geas/doc/odmg.txt:1.8 gnue/geas/doc/odmg.txt:1.9
*** gnue/geas/doc/odmg.txt:1.8  Mon Feb 25 01:41:54 2002
--- gnue/geas/doc/odmg.txt      Tue Feb 26 00:24:49 2002
***************
*** 805,811 ****
  
        Time
        ====
!       - Times denote specific world tiems which are interbally stored
        as GMT, timezones specified as number of hours to subtract form
        local time to get GMT.
  
--- 805,811 ----
  
        Time
        ====
!       - Times denote specific world items which are internally stored
        as GMT, timezones specified as number of hours to subtract form
        local time to get GMT.
  
***************
*** 1014,1027 ****
         * array<t>
         * dictionary<t,v>
  
!     - these type generators are analagous of their collection objects
      except they do not have OIDs
      - their elements can be of literal or object type
     
      Structured Literals
      ===================
!     - structred literal or structure has fixed numeber of elements,
!     each of which ahs a variable name and can contain either literal
      or an object.
      - Structure types supported by ODMG Object Model include:
  
--- 1014,1027 ----
         * array<t>
         * dictionary<t,v>
  
!     - these type generators are analogous of their collection objects
      except they do not have OIDs
      - their elements can be of literal or object type
     
      Structured Literals
      ===================
!     - structured literal or structure has fixed number of elements,
!     each of which has a variable name and can contain either literal
      or an object.
      - Structure types supported by ODMG Object Model include:
  
***************
*** 1054,1060 ****
      literals do have copy semantics
      - when iterating through a collection of literals, copies of the
      elements are returned
!     - when trturning a literal-valued attribute of an object, a copy
      of the literal value is returned
  
      Comparing Literals
--- 1054,1060 ----
      literals do have copy semantics
      - when iterating through a collection of literals, copies of the
      elements are returned
!     - when returning a literal-valued attribute of an object, a copy
      of the literal value is returned
  
      Comparing Literals
***************
*** 1062,1068 ****
      - since literals do not have OIDs (not objects) they cannot be
      compared by identity (same_as operation)
      - they are compared using the 'equals' equivalence operation
!     - this becomes inportant for collection management, e.g., when
      inserting, removing, or testing for membership in a collection of
      literals the 'equals' operations is used rather than the identity
      operation 'same_as'
--- 1062,1068 ----
      - since literals do not have OIDs (not objects) they cannot be
      compared by identity (same_as operation)
      - they are compared using the 'equals' equivalence operation
!     - this becomes important for collection management, e.g., when
      inserting, removing, or testing for membership in a collection of
      literals the 'equals' operations is used rather than the identity
      operation 'same_as'
***************
*** 1093,1099 ****
            once in 'x', there is an equivalent literal occurring the same
            number of times in 'y'
  
!         * if 't' is an Object type, then both 'x' and 'y' contian the
            same set of oids, In addition, for each oid appearing more
            than once in 'x', there is an identical oid appearing the same
            number of times in 'y'
--- 1093,1099 ----
            once in 'x', there is an equivalent literal occurring the same
            number of times in 'y'
  
!         * if 't' is an Object type, then both 'x' and 'y' contain the
            same set of oids, In addition, for each oid appearing more
            than once in 'x', there is an identical oid appearing the same
            number of times in 'y'
***************
*** 1125,1131 ****
    - 2 objects or literals are the same type if they have been declared
    to be instances of the same named type
    - Type compatibility follows the subtyping relationships defined by
!   the type heirarchy (i.e, a derived type can be assigned to a variable
    of the parent type, but no the reverse)
    - No implicit conversions between types are provided by the Object
    Model
--- 1125,1131 ----
    - 2 objects or literals are the same type if they have been declared
    to be instances of the same named type
    - Type compatibility follows the subtyping relationships defined by
!   the type hierarchy (i.e, a derived type can be assigned to a variable
    of the parent type, but no the reverse)
    - No implicit conversions between types are provided by the Object
    Model
***************
*** 1170,1173 ****
        Date
        Time
        Timestamp
!       Interval
\ No newline at end of file
--- 1170,1331 ----
        Date
        Time
        Timestamp
!       Interval
! 
!   Modeling State--Properties
!   ==========================
!   - class defines set of attributes through which users can access,
!   and in some cases directly manipulate, the state of the instances of
!   the class
!   - 2 kinds of properties are defined in ODMG Object Model: attribute
!   and relationship, attribute is of one type, whereas a relationship
!   is defined between 2 types, each of which must have instances which
!   are referenceable by oids
! 
!     Attributes
!     ==========
!     - attribute declarations in a class define the abstract state of
!     its instances
!     - e.g., a Person might contain the following attributes:
! 
!       class Person
!       {
!         attribute short age;
!         attribute string name;
!         attribute enum gender {male, female};
!         attribute Address home_address;
!         attribute set<Phone_no> phones;
!         attribute Department dept;
!       };
! 
!     - a particular instance of a Person could have a specific value
!       for each of the defined attributes
!     - the value of dept above is the oid of an instance of
!       Department, attribute's value is always a literal or an object
!     - attributes are 'abstract' in a sense and can be implemented
!       as data structures or even methods, especially if they can be
!       calculated from other attributes
! 
!     Relationships
!     =============
!     - ODMG Object Model supports only binary relationships, i.e.,
!     relationship between 2 types
!     - binary relationship may be one-to-one, one-to-many,
!     many-to-many, depending upon how many instances of each type
!     participate in the relationship
!     - relationships in the Object Model are similar
!     entity-relationship data modeling
!     - relationship defined explicitly by declaration of 'traversal
!     paths' that enable applications to use the logical connections
!     between the objects participating in the relationship
!     - traversal paths are declared in pairs, one for each direction of
!     the traversal of the relationship
!     - e.g., a professor teaches a course and a course is taught by a
!     professor:
! 
!       class Professor
!       {
!         relationship set<Course> teaches 
!              inverse Course::is_taught_by;
!       ...
!       };
! 
!     and
!       class Course
!       {
!         relationship Professor is_taught_by 
!              inverse Professor::teaches;
!       ...
!       };
!         
!      - the fact that these traversal paths both apply to the same
!        relationship is indicated by the 'inverse' clause in both
!        declarations
!      - relationship defined by the 'teaches' and 'is_taught_by'
!        traversal paths is a one-to-many relationship between Professor
!        and Course objects, this cardinality is show in the traversal
!        path declarations
!      - Professor in stance is associated with a set of Course
!        instances via the teaches traversal path, Course instance is
!        associated with a single professor instance via the
!        'is_taught_by' traversal path
!      - ODMS is responsible for maintaining referential integrity of
!        relationships, this means that if an object that participates
!        in a relationship is deleted then any traversal path to that
!        object must also be deleted
!      - attributes may be object based and may be used to implement
!        so-called unidirectional relationships, such constructions are
!        not considered to be true relationships in this standard,
!        relationships always guarantee referential integrity
!      - implementation of relationships is encapsulated by public
!        operations that 'form' and 'drop' members from the
!        relationship, plus public operations on the relationship target
!        classes to provide access to manage the required referential
!        integrity constraints
!      - when traversal path has cardinality "one", operations are
!        defined to form  a relationship, to drop a relationship, and to
!        traverse the relationship
!      - when traversal path has cardinality "many", the object will
!        supports methods to add and remove elements form its traversal
!        path collection 
!      - in order to facilitate use of ODL objects models in situations
!        where such models may criss distribution boundaries, we define
!        the relationship interface in purely procedural terms by
!        introducing a mapping rule form ODL relationships to equivalent
!        IDL constructions, each language binding will determine exact
!        manner in which these constructions are to be accessed
!      -   declarations that occur within classes define abstract state
!        for accessing the relationship
!      - declarations that occur within interfaces define only the
!        operations of the relationship, not the state
!      
!        Cardinality "One" Relationships
!        ===============================
!        - for relationships of cardinality one such as:
! 
!          relationship X Y inverse Z;
! 
!          we expand the relationship to an equivalent IDL attribute and
!          operation:
!          
!            attribute Professor is_taught_by;
!            void form_X(in X target) raises(IntegrityError);
!            void drop_Y(in X target) raises(IntegrityError);
! 
!          e.g., using the relationship in the Course interface from
!          before
! 
!            attribute Professor is_taught_by;
!            void form_is_taught_by(in Professor aProfessor)
!                                   raises(IntegrityError);
!            void drop_is_taught_by(in Professor aProfessor)
!                                   raises(IntegrityError);
! 
!        Cardinality "Many" Relationships
!        ================================
!        - for ODL relationships the cardinality "many" such as
! 
!          relationship set<X> Y inverse Z;
! 
!        - to convert these definitions into pure IDL, the ODL
!          collection need only be replaced by the keyword 'sequence'
!          Note the add_Y operation may raise an 'IntegrityError'
!          exception in the event the that the traversal is a set that
!          already contains a reference to the given target X, this
!          exception, if it occurs, will also be raised by the form_Y
!          operation that invoked the add_Y, e.g.
! 
!          readonly attribute set<X> Y;
!          void form_Y(in X target) raises(IntegrityError);
!          void drop_Y(in X target) raises(IntegrityError);
!          void add_Y(in X target) raises(IntegrityError);
!          void remove_Y(in X target) raises(IntegrityError);
! 
!          the relationship in the Professor interface from before would
!          result in:
! 
!          readonly attribute set<Course> teaches;
!          void form_teaches(in Course aCourse) raises(IntegrityError);
!          void drop_teaches(in Course a Course) raises(IntegrityError);
!          void add_teaches(in Course aCourse) raises(IntegrityError);
!          void remove_teaches(in Course aCourse) raises(IntegrityError);