Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
An overview of object-oriented database management systems (odbms), focusing on the odmg standard, object description language (odl), and object query language (oql). It covers class declarations, element declarations, relationships, and their inverse pairs, as well as the use of interfaces, structured and enumerated types, and keys.
Typology: Study notes
1 / 19
This page cannot be seen from the preview
Don't miss anything!
Ob ject-Oriented DBMS's
ODMG = Ob ject Data Management Group: an OO standard for databases.
ODL = Ob ject Description Language: design in the OO style.
OQL = Ob ject Query Language: queries an OO database with an ODL schema, in a manner similar to SQL.
ODL Overview
Class declarations (interfaces).
Interface includes:
ODL Relationships
Only binary relations supp orted.
F Multiway relationships require a \connecting" class, as discussed for E/R mo del.
Relationshi ps come in inverse pairs.
F Example: \Sells" b etween b eers and bars is represented by a relationship in bars, giving the b eers sold, and a relationship in b eers giving the bars that sell it.
Many-many relationships have a set typ e (called a col lection type) in each direction.
Many-one relationships have a set typ e for the one, and a simple class name for the many.
One-one relations have classes for b oth.
Beers-Bars-Drinkers Example
interface Beers { attribute string name; attribute string manf; relationship Set
An element from another class is indicated by
Form a set typ e with Set
interface Drinkers { attribute string name; attribute Struct Bars::Addr address; relationship Set
Note reuse of Addr typ e.
ODL Typ e System
Basic typ es: int, real/ oat, string, enumerated typ es, and classes.
Typ e constructors: Struct for structures and four col lection types : Set, Bag, List, and Array.
Limitation on Nesting
class collecti on
Relationship
Attribute
basic, no class
struct collecti on
Example: Multiway Relationship
Consider a 3-way relationship bars-b eers-prices. We have to create a connecting class BBP.
interface Prices { attribute real price; relationship Set
Inverses for theBar, theBeer must b e added to Bars, Beers.
Better in this sp ecial case: make no Prices class; make price an attribute of BBP.
Notice that keys are optional.
F BBP has no key, yet is not \weak." Ob ject identity suces to distinguish di erent BBP ob jects.
Roles in ODL
Names of relationships handle \roles."
Example: Sp ouses and Drinking Buddies
interface Drinkers { attribute string name; attribute Struct Bars::Addr address; relationship Set
Notice that Drinkers:: is optional when the inverse is a relationship of the same class.
Keys in ODL
Indicate with key(s) following the class name, and a list of attributes forming the key.
Several lists may b e used to indicate several alternative keys.
Parentheses group memb ers of a key, and also group key to the declared keys.
Thus, (key(a 1 ; a 2 ; : : : ; an )) = \one key consisting of all n attributes." (key a 1 ; a 2 ; : : : ; an ) = \each ai is a key by itself."
Example
interface Beers (key name) { attribute string name ...
Remember : Keys are optional in ODL. The \ob ject ID" suces to distinguish ob jects that have the same values in their elements.
Example: A Multiattribute Key
interface Courses (key (dept, number), (room, hours)) { ...
ODL Class Without Relationships
Problem: ODL allows attribute typ es built from structures and collecti on typ es.
Structure: Make one attribute for each eld.
Set: make one tuple for each memb er of the set. F More than one set attribute? Make tuples for all combinations.
Problem: ODL class may have no key, but we should have one in the relation to represent \OID."
Example
interface Drinkers (key name) { attribute string name; attribute Struct Addr {string street, string city, int zip} address; attribute Set
name street city zip phone
n 1 s 1 c 1 z 1 p 1 n 1 s 1 c 1 z 1 p 2
Surprise: the key for the class (name) is not the key for the relation (name, phone). F name in the class determines a unique ob ject, including a set of phones.
F name in the relation do es not determine a unique tuple.
F Since tuples are not identical to ob jects, there is no inconsistency!
BCNF violati on: separate out name-phone.
Example
interface Drinkers (key name) { attribute string name; attribute string addr; relationship Set
Drinkers(name, addr, b eerName, favBeer, wife, buddy)
Not in BCNF; decomp ose to:
Drinkers(name , addr, favBeer, wife) DrBeer(name , beer ) DrBuddy(name , buddy)
