High-Level Design Languages - Database Systems - Lecture Slides, Slides of Database Management Systems (DBMS)

Download High-Level Design Languages - Database Systems - Lecture Slides and more Slides Database Management Systems (DBMS) in PDF only on Docsity!

Other High-Level Design Languages

Unified Modeling Language Object Description Language

Object-Oriented DBMS’s

• Standards group: ODMG = Object Data Management Group.
• ODL = Object Description Language, like CREATE TABLE part of SQL.
• OQL = Object Query Language, tries to imitate SQL in an OO framework.

Framework – (2)

• ODL is used to define persistent classes, whose objects are stored permanently in the database. - ODL classes look like Entity sets with binary relationships, plus methods. - ODL class definitions are part of the extended, OO host language.

ODL Overview

• A class declaration includes:
  1. A name for the class.
  2. Optional key declaration(s).
  3. Element declarations. An element is either an attribute, a relationship, or a method.

Attribute and Relationship

Declarations

• Attributes are (usually) elements with a type that does not involve classes. attribute ;
• Relationships connect an object to one or more other objects of one class. relationship inverse ;

Inverse Relationships

• Suppose class C has a relationship R to class D.
• Then class D must have some relationship S to class C.
• R and S must be true inverses.
  • If object d is related to object c by R , then c must be related to d by S.

Types of Relationships

• The type of a relationship is either
  1. A class, like Bar. If so, an object with this relationship can be connected to only one Bar object.
  2. Set: the object is connected to a set of Bar objects.
  3. Bag, List, Array: the object is connected to a bag, list, or array of Bar objects.

Multiplicity of Relationships

• All ODL relationships are binary.
• Many-many relationships have Set<…> for the type of the relationship and its inverse.
• Many-one relationships have Set<…> in the relationship of the “one” and just the class for the relationship of the “many.”
• One-one relationships have classes as the type in both directions.

Another Multiplicity Example

class Drinker {

attribute … ; relationship Drinker husband inverse wife; relationship Drinker wife inverse husband; relationship Set buddies inverse buddies;

}

13

husband and wife are one-one and inverses of each other.

buddies is many-many and its own inverse. Note no :: needed if the inverse is in the same class.

Coping With Multiway Relationships

• ODL does not support 3-way or higher relationships.
• We may simulate multiway relationships by a “connecting” class, whose objects represent tuples of objects we would like to connect by the multiway relationship.

Example: Connecting Class

• Suppose we have Bar and Beer classes, and we want to represent the price at which each Bar sells each beer. - A many-many relationship between Bar and Beer cannot have a price attribute as it did in the E/R model.
• One solution: create class Price and a connecting class BBP to represent a related bar, beer, and price.

Example -- Continued

• Since Price objects are just numbers, a better solution is to:

1. Give BBP objects an attribute price.
2. Use two many-one relationships between a BBP object and the Bar and Beer objects it represents.

Structs and Enums

• Attributes can have a structure (as in C) or be an enumeration.
• Declare with

attribute [Struct or Enum] <name of

struct or enum> {

} ;

• Details are field names and types for a Struct, a list of constants for an Enum.

Example: Struct and Enum

class Bar {

attribute string name; attribute Struct Addr {string street, string city, int zip} address; attribute Enum Lic { FULL, BEER, NONE } license; relationship …

}

20

Names for the structure and enumeration

names of the attributes