Module 5 oodb systems semantic db systems

Semantic DB SystemsDOEACC B-Level OODBMS 2011

Taher S.

5. Object Oriented Database Systems

Topics already covered in classGoogle books link for CSR Prabhu :

http://books.google.com/books/about/Object_Oriented_Database_Systems_Approac.html?id=Yo6jGojiW4cC

Semantic expressiveness of a database model- This also included discussions about the drawbacks of conventional DB models like relational, heirarchial and network and the motivation for including more semantic information in a DB.

Categories of semantic DB Models- A heirarchy shown in the next slide and discussion of each type of semantic DB.

E-R ModelConstructsOperationsApplications

Topics already covered in classRelational Model- Tasmania (RM/T)

RM/T ConstructsEntities…SurrogatesE-Domain, E-attributes, E-relationsEntity integrity rulesP-relationsProperty integrity rulesEntity references

RM/T OperationsRM/T Operators: DENOTE, COMPRESS,

PARTITION(R,A), APPLY(Property,TEMP)RM/T catalog

3: Semantic DB Model - SDMDeveloped by DB Research group at Univ of

S Cali, LA as Ph.D thesis work of Hammer and McLeod in 1981.

A copy of the original paper submitted by them at ACM Transactions on DB Systems in Sep 1981 will be given to you durin the course of the lecture. You are advised to go through it to get an idea of the SDM DDL Schema and an accompanying case study for further strengthening of concepts discussed in this lecture.

SDM Specification & ConstructsSpecification:

(1) A database is to be viewed as a collection of

entities that correspond to the actual objects in the application environment.

(2) The entities in a database are organized into classes that are meaningful collections of entities.

(3) The classes of a database are not in general independent, but rather are logically related by

means of interclass connections.(4) Database entities and classes have attributes

that describe their characteristics and relate them to other database entities.

SDM Specification & Constructs

Classes: An SDM database is a collection of entities that are organized into classes. The structure and organization of an SDM database is specified by an SDM schema, which identifies the classes in the database.

Each class in an SDM schema has the following features:(1) A class name identifies the class. (e.g., OIL - TANKERS),(2) The class has a collection of members: the entities that

constitute it.(3) An (optional) textual class description describes the meaning

and contents of the class. For example, in Appendix A, class SHIPS has a description indicating that the class contains ships with potentially hazardous cargoes that may enter U.S. coastal waters.

(4) The class has a collection of attributes that describe the members of that class or the class as a whole.

(5) The class is either a base class or a nonbase class. Base classes are mutually disjoint in that every entity is a member of exactly one base class. A nonbase class is one that does not have independent existence; rather, it is defined in terms of one or more other classes.

SDM- Subclass ConnectionsA subclass S of a class C (called the parent

class) is a class that contains some, but not necessarily all, of the members of C.

The very same entity can thus be a member of many classes.

For example, a given entity may simultaneously be a member of the classes SHIPS, OIL-TANKERS, and MERCHANT-SHIPS. (However, only one of these may be a base class.)

This is the concept of “subtype”.

SDM- Interclass ConnectionsThere are two main types of interclass connections in

SDM:The Grouping Connection:

Allows for the definition of a nonbase class, called a grouping class (G), whose members are of a higher-order entity type than those in the underlying class (U). A grouping class is second order, in the sense that its members can themselves be viewed as classes; in particular, they are classes whose members are taken from U.

A grouping expression specifies how the members of U are to be placed into these groups.

For example, class SHIP-TYPES in Appendix A is defined as a grouping class of SHIPS with the grouping expression “on common value of Type”.

Multiple interclass connection:Each nonbase class in an SDM schema ha’s a single interclass

connection associated with it. While it is meaningful and reasonable in some cases to associate more than one interclass connection with a nonbase class, the uncontrolled use of such multiple interclass connections could introduce undesirable complexity into a schema. In consequence, only a single interclass connection (the most natural one) should be used to define a nonbase class.

SDM- Name ClassesA name class in SDM is a collection of

strings, namely, a subclass of the built-in class STRINGS (which consists of all strings over the basic set of alphanumeric characters).

SDM - AttributesEach class has an associated collection of attributes.

Each attribute has features such as name, value, applicability, description, mandatory/optional, changeable/non changeable etc.

Member attribute interrelationships eg: Inversion- attribute Ships-registered-here of COUNTRIES is the inverse of attribute Country of registry of SHIPS; this establishes the fact that both are ways of expressing in what country a ship is registered.

Member attribute matching: A matching specification indicates that the value of the attribute Captain for a member S of class SHIPS is equal to the value of attribute Officer of the member A of class ASSIGNMENTS whose Ship value is S.

SDM - AttributesMember attribute derivations: inversion and

matching are mechanisms for establishing the equivalence of different ways of viewing the same essential relationships among entities. SDM also provides the ability to define an attribute whose value is calculated from other information in the database. Such an attribute is called derived, and the specification of its computation is its associated derivation.

Mappings: A mapping is a concatenation of attribute names that allows a user to directly reference the value of an attribute of an attribute.

SDM - AttributesAttribute Inheritance :

It may often be the case that an entity in an SDM database belongs to more than one class. SDM classes can and frequently do share members, for example, a member of OIL-TANKERS is also a member of SHIPS; a member of OIL-SPILLS is also in INCIDENTS.

4. Semantic Association Model- SAM *Developed at DB Research and Dev.

Centre, Univ of Florida by Prof. W.S. Su in 1983

Serves the modelling purposes of Scientific-Statistical DBs and MIS.

Primarily deals with complex data types such as sets, vectors etc.

Essential features: Integrated ModelRelativismComprehensive coverageSystem Life cycle applicability

SAM*- Concepts and associations-constructsModels real-world environment by means of

several interrelated concepts.Concepts are atomic or non-atomic.Association- grouping of atomic or non-atomic

concepts to describe other non-atomic concepts. Seven types are defined:Membership Assoc.Aggregation assoc.Generalisation assoc. Interaction assoc. Cross Product assoc.Composition assoc.Summarization assoc.

5. DaplexIt is a DB language rather than a model. A Daplex User manual appeared in 1984 which

provides DDL and DML capabilities based on a functional data model.

The DB definitions define logical types and structures of info in DB and constraints for legal values.

The DB manipulation capabilities allow a user to create, update, delete, modify and retrieve info in DBs.

Following snapshots describe basic Daplex constructs for DB definitions and manipulations.

IFO Suggested by Abiteboul and Hull in 1987. Investigations of semantic models have given rise to IFO

model. Only structural component of the IFO model has been

defined. Hence only constructs are defined and not the operations.

Attempts to mathematically define 4 fundamental principals of Semantic data modeling:

IFOIt can serve as an analyt’s tool for not only

representing the semantics of the data but also for evaluating the features and facilities of various semantic models.

Informal description: IFO schema is a directed graph with vertices and

edges. A family of IFO instances is assoiated with each

schema.IFO consists of types that model the structure of

the objects arising in a given DB application. Fragments are built from types and represent

functional relationships in the model.

IFOObjects in IFO:

3 atomic types:

- Printable objects like strings. Basis for I/O.

- Abstract objects like person. Have attributes but no structure.

- Free objects. Obtained via ISA rel. Represented by code.

IFO2 constructs:

- Star vertex- represents groupings lie in SDM.

- Cartesian product- Equivalent to aggregation type.

IFOFragements:

Functional rel. among object types are represented as fragments.

Similar to functions in DAPLEX.In the figure:

(a) indicates a fragment to rep. a set of students with a function mapping into their grades.

(b) two functions on course- enrolments and course names.

IFOISA relationships.IFO schema.