Object-oriented data model. Object-oriented database model Limited performance tuning options

The object-oriented data model is an extension of the provisions of object-oriented programming (while the relational model arose on the basis of set theory, precisely as a data model). The Object DataBase Management Group developed the ODMG-93 (Object DataBase Management Group) standard. This standard has not yet been fully implemented.

The structure of an object-oriented database is graphically represented as a tree, the nodes of which are objects. The visible structure of an object is determined by the properties of its class. Class includes objects, while the structure and behavior of objects of the same class are the same. Each object, namely an instance of a class, is considered a descendant of the object in which it is defined as a property. Object Properties- either a standard type, such as string, or a user-constructed class type. The behavior of objects is specified using methods. Method is a certain operation that can be applied to an object.

As an example, consider the “LIBRARY” database (Fig. 4.4). For each object, properties, their types and values ​​are defined. In the database:

“LIBRARY” – parent (ancestor) for “SUBSCRIPTION”, “CATALOG”, “ISSUE”;

"CATALOG" is the parent of "BOOK".

“BOOK” – different objects can have the same or different parents. If it is the same parent (same author), then the accession numbers are different, but the isbn, UDC, title and author are the same.

The logical structure of an object-oriented database is similar to a hierarchical one, the main difference is in the methods of data manipulation. You can perform actions on the database such as logical operations, enhanced by object-oriented methods of encapsulation, inheritance and polymorphism.

Encapsulation limits the scope of a property name to the boundaries of the object in which it is defined. So, if the property is added to the “CATALOG” telephone author of the book, then they are obtained similarly in “SUBSCRIPTION” and “CATALOG”. The meaning of a property will be determined by the object in which it is encapsulated.

Inheritance,conversely, it extends the scope of the property to all ,children of the object. Thus, all objects of the “BOOK” type that are descendants of “DIRECTORY” can be assigned the properties of the parent isbn, UDC, title and author.

Polyformism means the ability of the same program code to work with different types of data. In other words, it means that it is permissible for objects of different types to have methods - procedures and functions - with the same names. During execution of an object program, the same methods operate on different objects depending on the type of the argument. For the “LIBRARY” database, this means that objects of the “BOOK” class that have different parents from the “DIRECTORY” class can have a different set of properties, i.e. programs for working with an object of the BOOK class may contain polymorphic code. In a class, a method does not have a body, that is, it is not defined what specific actions it should perform. Each subclass performs the required operations. Encapsulation hides implementation details from all objects outside a given hierarchy.

The advantages of an object-oriented model in comparison with a relational one are the ability to display information about complex relationships between objects and the absence of limitations in data storage structures. An object-oriented database can store not only the structure, but also the behavioral aspects of the data. Using an object-oriented approach, databases with large volumes of semantic information can be created, such as multimedia and specialized for specific subject areas (geographical, design, etc.).

The disadvantages of this approach include high conceptual complexity, inconvenience of data processing and low speed of query execution.

In the 90s, prototypes of operational object-oriented databases were created. These are POET (POET SoftWare), JASMINE (COMPUTER ASSOCIATES), IRIS, ORION, POSTGRES.

Topic 5

Relational approach to building an information-logical model: basic concepts

Relational data model. Basic Concepts

As noted in the section of the previous lecture, the relational model is currently one of the most common models in the database market. The basis of this model is a set of interconnected tables (relationships).

The main theoretical ideas of the relational model were outlined in works on the theory of relations by the American logician Charles Souders Peirce (1839-1914) and the German logician Ernst Schroeder (1841-1902), as well as the American mathematician Edgar Codd.

In the works of Pierce and Schroeder, it was proven that the set of relations is closed under certain special operations that together form an abstract algebra. This essential property of relationships was used in the relational model to develop a data manipulation language.

In 1970, E. Codd's paper appeared on the presentation of data organized in two-dimensional tables called relationships. Codd was the first to introduce the basic concepts and limitations of the relational model as the basis for data storage, and showed the possibility of data processing using traditional operations on sets and special introduced relational operations.

The basic concepts of the relational model are given in Table. 3.1.

The objects of the relational model are mainly tables (relationships). Data integrity is ensured by foreign and primary keys (see paragraph “Relational data integrity”).

Operators in the relational model are a set of instructions that provide selection and manipulation of data.

Table 5.1. Elements of the relational model

Relational model term	Description
Database (DB)	A set of tables and other objects necessary for an abstract representation of the selected subject area
DB schema	A set of table headers interrelated with each other
Attitude	A table is a collection of real world objects that are characterized by common properties and characteristics (table fields)
Relationship header	Table title – names of fields (columns) of the table
Body relationship	The body of the table is a set of values ​​for all objects of the real world, which can be represented in the form of table records (table rows)
Relationship diagram	Table column header row (table header)
Relationship attribute	Table column name (table field)
Relationship tuple	Table row (record) – an unambiguous representation of a real-world object created using table field values
Domain	Set of valid attribute values
Attribute value	Field value in record (tuple)
Primary key	One or more (in the case of a composite key) attributes that uniquely define the value of the tuple (table row value)
External key	A table attribute whose values ​​correspond to the primary key values ​​in another related (parent, primary) table. A foreign key can consist of one or more attributes (composite foreign key). If the number of attributes of a foreign key is less than the number of attributes of the corresponding primary key, then it is called a truncated (partial) foreign key
Degree (arity) of the relationship	Number of table columns
Power ratio	Number of rows (tuples) of the table
Relationship Instance	A set of records (tuples) for a given table (relationship). The instance may change over time. Since a regular database currently works with only one version of a relation, such an instance of the relation is called current
Data type	Table element value type
Basic attitude	A relationship containing one or more columns characterizing the properties of an object, as well as a primary key
Derived relation	Is not a basic relation, i.e. does not characterize the properties of an object and is used to provide relationships between other tables; it may not contain a primary key. If a primary key is specified, it consists of the foreign keys associated with the primary keys of the underlying relation
Connection	Establishes a relationship between matching values ​​in key fields - the primary key of one table and the foreign key of another
One-to-one communication (1:1)	When using this type of relationship, a record in one table can have at most one related record in another table. In both tables, key fields must be primary. Used to separate tables with numerous fields or as required by data protection
One-to-many (1:M) communication	When using this type of relationship, each record of one table can correspond to several records of the second, but each record of the second table corresponds to only one record of the first table. The first table must have a primary key, the second must have a foreign key.
Many-to-many (N:M) relationship	With this type of relationship, one record in the first table may correspond to several records of the second table, but one record of the second table may correspond to several records of the first. Uniqueness of keys for such tables is not required. In the process of designing a database schema, such connections are transformed. To do this, it is necessary to introduce an auxiliary relation that allows you to replace the many-to-many relationship with two one-to-many relationships.

The data structure of the relational model involves representing the subject area of ​​the problem under consideration as a set of interconnected relationships.

In each connection, one relationship can act as the main one (basic, parent), and the other can act as a subordinate (derived, child). To maintain these relationships, both relations must contain a set of attributes by which they are related: in the main relation, this is the primary key of the relation (uniquely identifies the tuple of the main relation); the subordinate relation must have a set of attributes corresponding to the primary key of the main relation. Here this set of attributes is already a secondary key or foreign key, i.e. defines a set of tuples of a derived relation associated with a single tuple of the main relation.

Many interconnected tables form database schema.

So the attitude R is a two-dimensional table containing some data.

Mathematically N-ary relation R is the Cartesian product set D 1 ×D 2 ×…×D n sets (domains) D 1 , D 2 ,…,D n(n≥1), not necessarily different:

R D 1 ×D 2 ×…×D n,

Where D 1 ×D 2 ×…×D n– complete Cartesian product, i.e. a set of all possible combinations of n elements each, where each element is taken from its own domain.

Domain is a semantic concept that can be viewed as a subset of values ​​of some data type that have a specific meaning.

Domain Properties:

The domain has a unique name (within the database),

Defined on some simple data type or on another domain,

May have some logical condition that allows you to describe a subset of data valid for this domain,

Carries a certain semantic load.

The main significance of domains is that they limit comparisons: you cannot compare values ​​from different domains, even if they have the same data type.

Attribute relationship is a pair of the form

<Имя_атрибута: Имя_домена>(or<A:D>).

Attribute names are unique within a relationship. Often the attribute names are the same as the corresponding domain names.

A relation R defined on a set of domains contains two parts: a header and a body.

Relationship header– a fixed number of relation attributes, describing the Cartesian product of domains on which the relation is specified:

(<A 1: D 1>, <A 2: D 2 >, …, <A n: D n>).

The header is static: it does not change while working with the database. If attributes are changed, added, or deleted in the relation, then a different relation is obtained. Even if the name is saved.

Body relation contains a set of relation tuples.

Every motorcade represents a set of pairs of the form:

<Имя_атрибута: Значение атрибута>:

R(<A 1:Val 1>, <A 2:Val 2 >, …, <A n: Val n>).

Such that the value Vali attribute A i belongs to the domain D i.

The body of a relation is a set of tuples, i.e., a subset of the Cartesian product of domains. Thus, the body of a relation is actually a relation in the mathematical sense of the word. The body of the relation can change while working with the database, because tuples can change, be added and deleted over time.

The relationship is usually written as:

R(<A 1: D 1>, <A 2: D 2 >, …, <A n: D n>),

or abbreviated: R(A 1, A 2, …, A n) or R.

Relationship diagram is a set of relation headers included in the database, i.e., a list of attribute names of a given relation indicating the domain to which they belong:

S R =(A 1, A 2, …, A n), A i D i, i = 1,..., n.

If attributes take values ​​from the same domain, then they are called θ-comparable, where θ is the set of valid comparison operations specified for a given domain.

For example, if a domain contains numeric data, then all comparison operations are valid for it: θ == (=,<>,>=,<=,<,>). However, for domains containing character data, not only comparison operations for equality and inequality of values ​​can be specified. If a given domain has a lexicographic ordering, then it also has a full set of comparison operations.

Schemes of two relations are called equivalent, if they have the same degree, and it is possible to order the attribute names in the schemas in such a way that comparable attributes, i.e., attributes that take values ​​from the same domain, will be in the same places.

Thus, for equivalent relations the following conditions are satisfied:

Having the same number of attributes;

The presence of attributes with the same names;

The presence of identical rows in relationships, taking into account that the order of attributes may vary;

Relations of this kind are different images of the same relation.

Properties of relationships follow directly from the previously given definition of relation. These properties are the main differences between relational data model relationships and simple tables:

Uniqueness of the relation name. The name of one relationship must be different from the names of other relationships.

Uniqueness of tuples. There are no identical tuples in a relation. Indeed, the body of a relation is a set of tuples and, like any set, cannot contain indistinguishable elements. Tables, unlike relationships, can contain identical rows. Each relation cell contains only an atomic (indivisible) value.

The disorder of tuples. The tuples are not ordered (from top to bottom), because the body of the relation is a set, and the set is not ordered (for comparison, the rows in tables are ordered). The same relationship can be represented by different tables in which the rows are in different orders.

Attribute disorder. The attributes are not ordered (from left to right).

The uniqueness of the attribute name within the relationship. Each attribute has a unique name within the relationship, which means that the order of the attributes does not matter (in comparison, the columns in the table are ordered). This property somewhat distinguishes a relation from the mathematical definition of a relation. The same relationship can be represented by different tables in which the columns are in different orders.

Atomicity of attribute values. All attribute values ​​are atomic. This follows from the fact that the underlying attributes have atomic values, i.e., each attribute has a value domain (a separate elementary type) associated with it, and the attribute values ​​are taken from the same domain. The schema and tuples of a relation are sets, not lists, so the order in which they are presented does not matter. For comparison, you can place various information in table cells: arrays, structures, other tables, etc.

Comment:

From the properties of the relation it follows that not every one a table can be a relation. In order for a table to define a relationship, the table must have a simple structure (contain only rows and columns, and each row must have the same number of fields), the table must not have identical rows, any column in the table must contain only one type of data , all data types used must be simple.

It should be noted that the relational model represents a database in the form of a set of interconnected relationships, which are called relational database schema.

The first formalized and generally accepted data model was the Codd relational model. In this model, as in all the following, three aspects were distinguished - structural, holistic and manipulative. Data structures in the relational model are based on flat normalized relationships, integrity constraints are expressed using first-order logic, and finally, data manipulation is carried out on the basis of relational algebra or its equivalent, relational calculus. As many researchers note, the relational data model owes its success largely to the fact that it was based on the rigorous mathematical apparatus of set theory, relations and first-order logic. The developers of any particular relational system considered it their duty to demonstrate the conformity of their specific data model with the general relational model, which acted as a measure of the “relationality” of the system.

The main difficulties of object-oriented data modeling stem from the fact that such a developed mathematical apparatus on which a general object-oriented data model could be based does not exist. This is largely why there is still no basic object-oriented model. On the other hand, some authors argue that a general object-oriented data model in the classical sense cannot be defined because the classical concept of a data model is unsuitable for the object-oriented paradigm.

One of the most famous theorists in the field of data models, Beeri, proposes in general terms a formal framework for OODB, which is far from complete and is not a data model in the traditional sense, but allows researchers and developers of OODB systems to at least speak the same language (if, of course, the proposals Bears will be developed and supported). Regardless of the further fate of these proposals, we consider it useful to briefly recount them.

First, following the practice of many OODBs, it is proposed to distinguish two levels of object modeling: lower (structural) and upper (behavioral). At the structural level, complex objects, their identification and types of "isa" relationships are supported. A database is a collection of data elements related by the “is a member of a class” or “is an attribute” relationship. Thus, the database can be considered as a directed graph. An important point is to maintain the concept of value along with the concept of an object (later we will see how much is built on this in one of the successful object-oriented DBMSs O2).

An important aspect is the clear separation of the database schema and the database itself. The primary concepts of the OODB circuit level are types and classes. It is noted that in all systems that use only one concept (either a type or a class), this concept is inevitably overloaded: a type assumes the presence of a certain set of values, determined by the data structure of this type; a class also assumes the presence of many objects, but this set is defined by the user. Thus, types and classes play different roles, and rigor and unambiguity require simultaneous support for both concepts.

Beeri does not present a complete formal model of the structural level of OODB, but expresses confidence that the current level of understanding is sufficient to formalize such a model. As for the behavioral level, only a general approach to the logical apparatus required for this is proposed (the logic of the first level is not enough).

Beeri's important, although not well-founded, assumption is that the two traditional levels - schema and data - are not enough for OODB. To accurately define an OODB, a meta-schema level is required, the contents of which must define the types of objects and relationships allowed at the database schema level. The meta-schema should play the same role for OODB as the structural part of the relational data model plays for relational database schemas.

There are many other publications related to the topic of object-oriented data models, but they either touch on rather specific issues or use mathematical apparatus that is too serious for this review (for example, some authors define an object-oriented data model based on category theory).

To illustrate the current state of affairs, we will briefly consider the features of a specific data model used in the object-oriented O2 DBMS (this, of course, is also not a data model in the classical sense).

O2 supports objects and values. An object is a pair (identifier, value), and the objects are encapsulated, i.e. their values ​​are accessible only through methods - procedures bound to objects. Values ​​can be atomic or structural. Structural values ​​are constructed from values ​​or objects represented by their identifiers using set, tuple, and list constructors. Structural value elements are accessed using predefined operations (primitives).

There are two possible types of data organization: classes, whose instances are objects that encapsulate data and behavior, and types, whose instances are values. Each class is associated with a type that describes the structure of instances of the class. Types are defined recursively based on atomic types and previously defined types and classes using constructors. The behavioral side of a class is determined by a set of methods.

Objects and values ​​can be named. The naming of an object or value is associated with the durability of its storage (persistency): any named objects or values ​​are durable; any object or value that is part of another named object or value is durable.

Using a special instruction specified when defining a class, you can achieve long-term storage of any object of this class. In this case, the system automatically generates a set value whose name matches the name of the class. This set is guaranteed to contain all objects of a given class.

A method is a program code bound to a specific class and applicable to objects of this class. Defining a method in O2 is done in two steps. First, the method signature is declared, i.e. its name, class, argument types or classes, and result type or class. Methods can be public (accessible from objects of other classes) or private (accessible only within a given class). At the second stage, the implementation of the class is determined in one of the O2 programming languages ​​(the languages ​​are discussed in more detail in the next section of our review).

The O2 model supports multiple class inheritance based on the supertype/subtype relationship. A subclass allows adding and/or overriding attributes and methods. Possible ambiguities in multiple inheritance (in the naming of attributes and methods) are resolved either by renaming or by explicitly indicating the source of inheritance. A subclass object is an object of each superclass from which the subclass is derived.

A predefined class "Object" is supported, which is the root of the class lattice; any other class is an implicit successor of the "Object" class and inherits predefined methods ("is_same", "is_value_equal", etc.).

A specific feature of the O2 model is the ability to declare additional "exclusive" attributes and methods for named objects. This means that a particular named object representative of a class can have a type that is a subtype of the class type. Of course, standard class methods do not work with such attributes, but additional (or standard) methods for which additional attributes are already available can be defined specifically for a named object. It is emphasized that additional attributes and methods are tied not to a specific object, but to a name, which can generally be followed by different objects at different times. Implementation of exclusive attributes and methods requires the development of late binding techniques.

In the next section, we will, among other things, look at the features of the programming languages ​​and queries of the O2 system, which, of course, are closely related to the specifics of the data model.

While there are many experimental projects (and even commercial systems), there is no generally accepted object-oriented data model, not because no complete model has been developed, but because there is no general agreement on the adoption of any model. In fact, there are more specific problems associated with developing declarative query languages, executing and optimizing queries, formulating and maintaining integrity constraints, synchronizing access and managing transactions, and so on.

The object-oriented model (Fig. 3) allows you to create, store and use information in the form of objects. When any object is created, it receives a unique identifier generated by the system, which is associated with the object throughout its existence and does not change when the state of the object changes.

Fig.3. Object-oriented data model

Every object has state and behavior. The state of an object is a set of values ​​of its attributes. The behavior of an object is a set of methods (program code) that operate on the state of the object. The value of an object attribute is also an object or a set of objects. The state and behavior of an object are encapsulated in the object; The interaction of objects is carried out on the basis of message passing and the execution of corresponding methods.

A set of objects with the same set of attributes and methods forms an object class. An object must belong to only one class (ignoring the possibility of inheritance). The presence of primitive predefined classes is allowed, the instance objects of which do not have attributes: integers, strings, etc. A class whose objects can serve as values ​​for an attribute of objects of another class is called the domain of that attribute.

It is possible to generate a new class based on an existing class - inheritance. In this case, the new class, called a subclass of the existing class (superclass), inherits all the attributes and methods of the superclass. In addition, additional attributes and methods can be defined in a subclass. There are cases of simple and multiple inheritance. In the first case, a subclass can be defined on the basis of only one superclass; in the second case, there can be several superclasses. If a language or system supports single class inheritance, the set of classes forms a tree hierarchy. When supporting multiple inheritance, classes are connected in a directed, rooted graph called a class lattice. An object of a subclass is considered to belong to any superclass of that class.

Object-oriented databases are most widely used in areas such as computer-aided design/manufacturing (CAD/CAM), computer-aided software engineering (CASE), composite document management systems, i.e. in areas not traditional for databases. Examples of object-oriented DBMSs are POET, Jasmine, Versant, Iris, Orion.

2.2.4.Relational data model

In 1970, the American mathematician Codd E.F. published an article that was revolutionary in its content, proposing the use of set theory for data processing. He argued that data should be linked according to their logical relationships (e.g., union, intersection) rather than physical pointers. He proposed a simple data model in which all data is summarized in tables consisting of rows and columns with unique names. These tables are called relations (relatio - relationship), and the model is a relational data model built on the concept of mathematical relations and is sometimes also called the Codd model. Codd's proposals were so effective for database systems that he was awarded the prestigious Turing Award for Theoretical Foundations of Computing for his model.

In relational databases, all data is stored in simple tables, divided into rows (they are called records) and columns (they are called fields), at the intersection of which information about the data is located. In general, this can be presented as in Fig. 4.

Fig.4. Relational database table.

Each column has its own name. For example, in the “Items in warehouse” table (Fig. 5), the field names are as follows: Identifier, Product, Group name, Group, Unit, Purchase price, Selling price, Availability in stock.

Rice. 5. Table “Product in Warehouse” »

All values ​​in the same column are of the same type. Thus, fields are various characteristics (sometimes called attributes) of an object. Field values ​​on the same line refer to the same object, and different fields have different names.

Each record is distinguished by a unique record key, which comes in two types: primary and secondary.

Primary key– These are one or more fields that uniquely identify a record. If the primary key consists of one field, it is called a simple key; if it consists of several fields, it is called a composite key.

Secondary key is a field whose value can be repeated in several records of the file, that is, it is not unique.

External key The subtable is the secondary key of this relationship, which, at the same time, serves as the primary key in the main table. If one single instance of a record can be found by the value of the primary key, then several by the value of the foreign key (Fig. 6).

Fig.6. Example of using a foreign key

As a rule, a relational database consists of several tables, because It is not possible to combine in one table all the information necessary for employees (database users) of any organization to solve problems.

A means of effectively accessing a file record by key is indexing. Indexing creates an additional file that contains, in an ordered form, all the data file key values. For each key, the index file contains a pointer to the corresponding data file entry. Using a pointer to a record in a data file, that record is directly accessed.

Structured Query Language (SQL) is currently commonly used to work with relational databases. It is a language used to create, modify and manipulate data. SQL is not an algorithmic programming language. This is an information-logical language, it is based on relational algebra and is divided into three parts:

· data definition operators;

· data manipulation operators (Insert, Select, Update, Delete);

· data access definition operators.

In 1986, SQL was adopted as the ANSI (American National Standards Institute) standard for relational database languages. Today this base is considered as a standard for modern information systems.

Thus, the table is the main type of data structure of the relational model. The table structure is determined by a set of columns. Each row of the table contains one value in the corresponding column. There cannot be two identical rows in a table; the total number of rows is not limited. A column is an element of data, each column has a name. One or more attributes whose values ​​uniquely identify a table row are the table key.

The advantages of the relational model are:

Simplicity and ease of understanding by the end user - the only information structure is a table;

When designing a relational database, strict rules based on mathematical apparatus are applied;

Complete data independence. When changing the structure, the changes that need to be made in application programs are minimal;

To build queries and write application programs, there is no need to know the specific organization of the database in external memory.

The disadvantages of the relational model are:

Relatively low access speed and large amount of external memory;

Difficulty in understanding the data structure due to the appearance of a large number of tables as a result of logical design;

It is not always possible to present a subject area in the form of a set of tables.

Relational databases are currently the most widespread. Network and hierarchical models are considered obsolete; object-oriented models have not yet been standardized and are not widely used.

Basic Concepts

Definition 1

Object-oriented model data presentation makes it possible to identify individual database records.

Database records and their processing functions are linked by mechanisms similar to those implemented in object-oriented programming languages.

Definition 2

Graphical representation The structure of an object-oriented database is a tree whose nodes represent objects.

Standard type (for example, string - string) or user-created type ( class), describes object properties.

In Figure 1, the LIBRARY object is the parent of instance objects of the DIRECTORY, SUBSCRIBER, and ISSUE classes. Different objects of type BOOK can have the same or different parents. Objects of type BOOK that have the same parent must have at least different accession numbers (unique for each book instance) but the same property values author, Name, udk And isbn.

The logical structures of an object-oriented and hierarchical database are superficially similar. They differ mainly in the methods of data manipulation.

When performing actions on data, the object-oriented model uses logical operations that are enhanced by encapsulation, inheritance, and polymorphism. With some limitations, you can use operations that are similar to SQL commands (for example, when creating a database).

When creating and modifying a database, indexes (index tables) are automatically generated and subsequently adjusted, which contain information for quickly searching data.

Definition 3

Target encapsulation– limiting the scope of the property name to the boundaries of the object in which it is defined.

For example, if a property is added to the DIRECTORY object that specifies the author's phone number and has the name telephone, then the objects DIRECTORY and SUBSCRIBER will have the same properties. The meaning of a property is determined by the object in which it is encapsulated.

Definition 4

Inheritance, the inverse of encapsulation, is responsible for propagating the scope of a property relative to all descendants of the object.

For example, all BOOK objects that are descendants of the DIRECTORY object can be assigned the properties of the parent object: author, Name, udk And isbn.

If it is necessary to extend the inheritance mechanism to objects that are not immediate relatives (for example, to two descendants of one parent), an abstract property of the type is defined in their common ancestor abs.

So the properties number And ticket in the LIBRARY object are inherited by all child objects ISSUE, BOOK and SUBSCRIBER. That is why the values ​​of this property of the SUBSCRIBER and ISSUING classes are the same - 00015 (Figure 1).

Definition 5

Polymorphism allows the same program code to work with different types of data.

In other words, it allows objects of different types to have methods (functions or procedures) with the same names.

Search in an object-oriented database is to determine the similarity between the object that the user specifies and the objects that are stored in the database.

Advantages and disadvantages of the object-oriented model

Basics advantage An object-oriented data model, in contrast to a relational model, is the ability to display information about complex relationships between objects. The data model under consideration allows us to define a separate database record and the functions for processing it.

TO shortcomings The object-oriented model is characterized by high conceptual complexity, inconvenient data processing and low query speed.

Today, such systems are quite widespread. These include DBMS:

• Postgres,
• Orion,
• Iris,
• ODBJupiter,
• Versant,
• Objectivity/DB
• ObjectStore
• Statice,
• GemStone
• G-Base.

Post-relationalmodel

The classic relational model assumes the indivisibility of data stored in the fields of table records. The post-relational model is an extended relational model that removes the constraint of data indivisibility. The model allows multivalued fields—fields whose values ​​consist of subvalues. A set of multivalued field values ​​is considered a separate table, embedded in the main table.

In Fig. 2.6, using the example of information about invoices and goods for comparison, shows the representation of the same data using relational (a) and post-relational (b) models. The figure shows that, compared to the relational model, the post-relational model stores data more efficiently, and during processing it is not necessary to perform the operation of joining data from two tables.

Invoices Invoices-goods

N invoice	Buyer		N invoice		Quantity

Invoices

N invoice	Buyer		Quantity

Rice. 2.6. Data structures of relational and post-relational models

Since the post-relational model allows non-normalized data to be stored in tables, the problem of ensuring data integrity and consistency arises. This problem is solved by including appropriate mechanisms in the DBMS.

Dignity The post-relational model is the ability to represent a set of related relational tables by one post-relational table. This ensures high clarity of information presentation and increases the efficiency of its processing.

Disadvantage The post-relational model is the difficulty of solving the problem of ensuring the integrity and consistency of stored data.

The considered relational data model is supported by the uniVers DBMS. Other DBMSs based on a post-relational data model also include the Bubba and Dasdb systems.

Multidimensional model

The multidimensional approach to data presentation appeared almost simultaneously with the relational one, but interest in multidimensional DBMSs began to become widespread since the mid-90s. The impetus was an article by E. Codd in 1993. It formulated 12 basic requirements for OLAP (OnLine Analytical Processing) class systems, the most important of which are related to the capabilities of conceptual representation and processing of multidimensional data.

In the development of information systems concepts, the following two directions can be distinguished:

Operational (transactional) processing systems;

Analytical processing systems (decision support systems).

Relational DBMSs were intended for information systems for online information processing and are very effective in this area. In analytical processing systems, they have proven to be somewhat clumsy and insufficiently flexible. Multidimensional DBMSs are more effective here.

Multidimensional DBMSs are highly specialized DBMSs designed for interactive analytical processing of information. The main concepts used in these DBMSs are aggregability, historicity and predictability.

Aggregability data means considering information at various levels of its generalization. In information systems, the degree of detail in the presentation of information to the user depends on his level: analyst, user, manager, manager.

Historicity Data management involves ensuring a high level of staticity of the data itself and their relationships, as well as the obligatory binding of data to time.

Predictability Data processing involves specifying forecasting functions and applying them to different time intervals.

Multidimensionality of a data model does not mean multidimensional visualization of digital data, but a multidimensional logical representation of the structure of information in the description and in data manipulation operations.

Compared to the relational model, the multidimensional organization of data is more visual and informative. For illustration in Fig. Figure 2.7 shows relational (a) and multidimensional (b) representations of the same data on car sales volumes.

Basic concepts of multidimensional data models: dimension and cell.

Measurement is a set of data of the same type that forms one of the faces of a hypercube. In a multidimensional model, measurements play the role of indices that serve to identify specific values ​​in the cells of a hypercube.

Cell is a field whose value is uniquely determined by a fixed set of measurements. The field type is most often defined as digital. Depending on how the values ​​of a cell are generated, it can be a variable (the values ​​change and can be loaded from an external data source or generated programmatically) or a formula (the values, like formula cells in spreadsheets, are calculated using predefined formulas).

Rice. 2.7. Relational and multidimensional representation of data

In the example in Fig. 2.7 b each cell value Volume of sales uniquely determined by a combination of time dimensions Sales month and car models. In practice, more measurements are often required. An example of a three-dimensional data model is shown in Fig. 2.8.

Rice. 2.8. Example of a 3D model

Existing multidimensional DBMSs use two main data organization schemes: hypercubic and polycubic.

IN polycubic The scheme assumes that several hypercubes with different dimensions and with different dimensions as faces can be defined in the database. An example of a system that supports a polycubic version of a database is Oracle Express Server.

When hypercubic The design assumes that all cells are defined by the same set of measurements. This means that if there are several hypercubes in the database, they all have the same dimension and the same dimensions.

Main dignity multidimensional data model is the convenience and efficiency of analytical processing of large volumes of time-related data.

Disadvantage The disadvantage of a multidimensional data model is its cumbersomeness for the simplest tasks of ordinary operational information processing.

Examples of systems that support multidimensional data models are Essbase, Media Multi-matrix, Oracle Express Server, Cache. There are software products, for example Media / MR, that allow you to simultaneously work with multidimensional and relational databases.

Object-oriented model

In an object-oriented model, when presenting data, it is possible to identify individual database records. Relationships are established between records and their processing functions using mechanisms similar to the corresponding tools in object-oriented programming languages.

The standardized object-oriented model is described in the recommendations of the ODMG-93 (Object Database Management Group) standard.

Let's consider a simplified model of an object-oriented database. The structure of an object-oriented database is graphically represented as a tree, the nodes of which are objects. The properties of objects are described by some standard type or a user-constructed type (defined as a class). The value of a property of type class is an object that is an instance of the corresponding class. Each instance object of a class is considered a child of the object in which it is defined as a property. An instance object of a class belongs to its class and has one parent. Generic relationships in the database form a coherent hierarchy of objects. An example of the logical structure of an object-oriented library science database is shown in Fig. 2.9. Here is an object of type Library is the parent of class instance objects Subscriber, Catalog And Issue. Various type objects Books and may have the same or different parents. Objects of type Book, having the same parent, must differ in at least the accession number (unique for each copy of the book), but have the same property values isb n, udk, name e and author.

The logical structure of an object-oriented database is superficially similar to the structure of a hierarchical database. The main difference between them is the data manipulation methods.

To perform actions on data in the database model under consideration, logical operations are used, enhanced by object-oriented mechanisms of encapsulation, inheritance and polymorphism.

Encapsulation limits the scope of a property name to the boundaries of the object in which it is defined. So, if in an object of type Catalog add a property that specifies the phone number of the author of the book and has a title telephone, then we will get properties of the same name for objects Subscriber And Catalog. The meaning of such a property will be determined by the object in which it is encapsulated.

Inheritance, on the contrary, extends the scope of the property to all descendants of the object. So, all objects of type Book, which are descendants of an object of type Catalog, you can assign properties to the parent object: isbn, udk, Name And author. If it is necessary to extend the inheritance mechanism to objects that are not immediate relatives (for example, between two children of the same parent), then an abstract property of the type is defined in their common ancestor abs. Thus, the definition of abstract properties ticket And number in the object Library causes these properties to be inherited by all seven child objects Subscriber, Book And Issues A. Not by chance, so the property values ticket classes Subscriber And Issue, shown in Fig. 2.9 are the same – 00015.

Polymorphism in object-oriented programming languages ​​means the ability of the same program code to work with different types of data. In other words, it means that it is permissible for objects of different types to have methods (procedures or functions) with the same names. During execution of an object program, the same methods operate on different objects depending on the type of the argument. In relation to the example under consideration, polymorphism means that objects of the class Book having different parents from the class Catalog, may have a different set of properties. Therefore, programs for working with class objects Book may contain polymorphic code.

Searching in an object-oriented database involves finding similarities between an object specified by the user and objects stored in the database.

Rice. 2.9. Logical structure of the library science database

Main dignity An object-oriented data model compared to a relational one is the ability to display information about complex relationships between objects. An object-oriented data model allows you to identify individual database records and define functions for processing them.

Disadvantages The object-oriented model is characterized by high conceptual complexity, inconvenience of data processing and low speed of query execution.

Object-oriented DBMSs include POET, Jasmine, Versant, O 2, ODB - Jupiter, Iris, Orion, Postgres.