Wine Database Object Schema

o list: allows to define ordered groups, which are allowed to have identical elements

o table: ordered and indexed groups

A group of objects inherits the properties of a constructor if there is a preceding constructor.

For example:can easily manage the following table lists: class sentence

content: list array char; class text

Maybe you are interested!

paragraph: list of sentences

2.5. Diagram

- An object-oriented database schema describes the following components:

o Describes the classes. Each class consists of properties (organized into groups by constructors, depending on the situation) and methods.

o Describe the relationships between classes.

Figure 2.6: Object schema of the wine database

3. Object-oriented data modeling method

3.1. Conversion method

- Define the conceptual schema in a language (model) that is close to the user and independent of the final implementation. The model used in this step must be able to represent all user requirements (UML – Unified Modeling Language).

- Move directly to the final implementation in a given object-oriented database system.

- It is possible to go through an intermediate step to have a diagram described in ODL (Object Definition Language), representing the design details independent of the final product.

Figure 2.7: The process of designing an object-oriented database schema

3.2. Direct analysis and construction method

a. Conceptual design (UML)

- UML notation:

o '+' before the property name, function determines public. In Rose, it is denoted as an unlocked lock.

o '#' before the property name, the function determines whether the property is protected. In Rose, this is represented by a locked lock with a key next to it.

o '-' before the property name, the function determines private ownership. In Rose, it is symbolized as a locked lock without a key next to it.

Figure 2.8: Links between objects

Figure 2.9: Association relationship between classes

Figure 2.10: Representation of multiples

Figure 2.11: Normal aggregation relation

Figure 2.12: Shared aggregation relationship

Figure 2.13: Aggregation relation

Figure 2.14: Generalization relationship

Figure 2.15: Multiple inheritance from 2 different classes, sharing the same base class

Figure 2.16: Multiple inheritance without a common base class

b. Standard Schema Design (ODMG): Convert a conceptual diagram expressed in UML notation to an ODMG (Object Database Management Group) diagram.

The generalizations implicit in UML are discrete, incomplete generalizations and are directly supported by the ODMG data model through the EXTEND relationship.

o Each UML persistence class is translated into an ODL class.

o Each UML interface is translated into an ODL interface.

o Each attribute is translated into one property. If it is a multivalued property, it is translated into a collection type.

o Associations are defined as relationships in ODL.

 Multiplicity (including maximum and minimum multiplicity) represents how many objects of a class can be associated with a given object of the related class.

 In ODMG, the maximum multiplicity supports the definition of a relationship. If the maximum multiplicity is greater than 1, the relationship is defined by the collection type (set, list or bag).

o UML supports two ways of representing integration:

 Member-collection aggregation: represents a collection of objects, all belonging to the same class and together forming a new class. For example, a collection of trees forming a forest.

 Part-whole aggregation: represents a class that has a structure consisting of two almost different classes.

c. Design installation diagram (Poet 4.0): Translate standard design diagram into installation diagram in POET 4.0

4. Characteristic components of object-oriented data types

4.1. Object-oriented data types

- Class and interface types:

o A type defines the common properties (attributes and associations) and behavior (operations) of a set of elements. The values of an object's properties can change at any time.

o A type has an external specification and one or more implementations. ODL supports external specifications with three constructs: interfaces, classes, and literals.

 An interface definition is a specification that defines the abstract behavior of an object type.

 A class definition is a specification that defines the abstract appearance and abstract state of an object type.

 The definition of a literal only defines the abstract state of a literal.

o The implementation of an object type must be performed by a language binding

- Subtypes and inheritance

o The ODMG data model supports two types of inheritance associations:

 An is-a association (represented by :): defines inheritance of behavior between object types, either interfaces or classes.

 The EXTENDS association (represented by the word extend) only inherits state. It applies only to object types.

o Thus, only classes can inherit state, literals cannot.

- Collection type (collections)

o A collection is a type with a variable number of elements, all of the same type.

o The ODMG data model supports the following collection types (objects or literals): sets, bags, lists, dictionaries, and tables.

- Structured types

o Is a type with a fixed number of elements, which can belong to many different types.

o The ODMG model supports structured types (objects or literals): date, interval, time and timestamp.

o In addition, ODMG also allows users to define new structured types.

- The extensions of a type are the group (collection) of all objects (instances) of the type.

- Keys: is one or a set of attributes that uniquely identify each object of a type (similar to the concept of candidate key of the relational model).

4.2. Properties of objects

- Sustainability of objects:

o Objects need to reside permanently on a storage medium such as a magnetic strip, when created by a program.

o Persistent object: is an object stored in the database, with a lifetime longer than the time of the program that created the object.

o Temporary object: is an object stored in internal memory; therefore, its existence period does not exceed the duration of the program that created that object.

- Concurrency:

o Object databases allow shared transactions. Transaction locking and data locking should be limited to ensure data compatibility.

- Reliability of the object:

o Objects that can be recovered when errors occur. Transactions need to be broken down to ensure that they either commit completely or not at all.

- Convenience of searching:

o People are asked to find objects according to the value of object properties.

o Therefore, it is necessary to manage attribute values, method results, and relationships between objects.

- Other functions:

o Distribution of objects

o Models of transactions

o Generations of objects