Hardware and software setup

Object-oriented data models. Object-oriented model Support for versions and long-running transactions

Post-relationalmodel

The classical relational model assumes the indivisibility of the data stored in the fields of table records. The post-relational model is an extended relational model that removes the restriction of data indivisibility. The model allows multivalued fields - fields whose values ​​consist of subvalues. A set of values ​​for multivalued fields is considered to be a stand-alone table embedded in the main table.

On fig. 2.6, using the example of information on invoices and goods for comparison, the presentation of the same data using relational (a) and postrelational (b) models is shown. The figure shows that, compared with the relational model in post relational model data is stored more efficiently, and processing does not require a data join operation between two tables.

Invoices

N invoice

Buyer

N invoice

Quantity

Overhead

N invoice

Buyer

Quantity

Rice. 2.6. Data structures of relational and postrelational models

Since the post-relational model allows storage of non-normalized data in tables, the problem of ensuring the integrity and consistency of data 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 provides a high visibility of the presentation of information and an increase in the efficiency of its processing.

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

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

Multidimensional model

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

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

Operational (transactional) processing systems;

Analytical processing systems (decision support systems).

Relational DBMS were intended for information systems of operational information processing and are very effective in this area. In analytical processing systems, they have proven to be somewhat clumsy and not flexible enough. Multidimensional DBMSs are more efficient here.

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

Aggregability data means consideration of information at various levels of its generalization. IN information systems the degree of detail in the presentation of information for the user depends on its level: analyst, user, manager, manager.

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

Predictability data processing involves setting prediction functions and applying them to different time intervals.

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

Compared with the relational model, the multidimensional organization of data has a higher visibility and information content. 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 form one of the faces of the hypercube. In a multidimensional model, dimensions play the role of indices that serve to identify specific values ​​in hypercube cells.

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

Rice. 2.7. Relational and multidimensional data representation

In the example in fig. 2.7 b each cell value Volume of sales uniquely determined by the combination of the time dimension 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. 3D model example

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 can be defined in the database as faces. An example of a system that supports a polycubic variant of a database is the Oracle Express Server.

When hypercubic The scheme 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 amounts of time-related data.

disadvantage multidimensional data model is its cumbersomeness for the simplest tasks of conventional online information processing.

Examples of systems that support multi-dimensional data models are Essbase, Media Multi-matrix, Oracle Express Server, Cache. There are software products, such as 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 facilities in object-oriented programming languages.

A standardized object-oriented model is described in the recommendations of the ODMG-93 standard (Object Database Management Group - an object-oriented database management group).

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 or 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 class instance object 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 relations in the database form a connected hierarchy of objects. An example of the logical structure of an object-oriented librarianship database is shown in fig. 2.9. Here an object of type Library is the parent of class instance objects Subscriber, Catalog And extradition. Various type objects Books and may have the same or different parents. Objects of type Book, which have the same parent, must differ by at least an accession number (unique for each book instance), but have the same property values isb n udk, names e and author.

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

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

Encapsulation limits the scope of a property name to 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 phone, then we will get the 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. Thus, for all objects of type Book, which are descendants of an object of type Catalog, you can assign the properties of the parent object: isbn, udk, title And author. If it is necessary to extend the action of the inheritance mechanism to objects that are not immediate relatives (for example, between two descendants of the same parent), then an abstract property of type abs. Thus, the definition of abstract properties ticket And room in object Library causes these properties to be inherited by all child objects Subscriber, Book And Issues but. It is no coincidence that therefore the property values ticket classes Subscriber And extradition shown in fig. 2.9 are the same - 00015.

Polymorphism in object-oriented programming languages ​​means the ability of the same program code work with different types of data. In other words, it means admissibility in objects different types have methods (procedures or functions) with the same name. During the 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 a 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 consists in finding out the similarities between the object specified by the user and the objects stored in the database.

Rice. 2.9. The logical structure of the librarianship database

Main dignity object-oriented data model in comparison with the relational one is the ability to display information about the complex relationships of objects. The object-oriented data model allows you to identify a single database record and define the functions for processing them.

disadvantages object-oriented model are high conceptual complexity, inconvenience of data processing and low query execution speed.

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

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, namely 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- or standard type, such as string, or a user-constructed class type. The behavior of objects is set using methods. Method is an operation that can be applied to an object.

As an example, consider the database "LIBRARY" (Fig. 4.4). Properties, their types and values ​​are defined for each object. In DB:

"LIBRARY" - parent (ancestor) for "SUBSCRIPTION", "CATALOGUE", "RELEASE";

"CATALOGUE" is the parent for "BOOK".


"BOOK" - different objects can have the same or different parents. If the same parent (one author), then the inventory numbers are different, but 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. On the database, you can perform such actions as logical operations, enhanced by object-oriented methods of encapsulation, inheritance and polymorphism.

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

Inheritance, conversely, extends the scope of the property to all descendants of the object. So, all objects of type "BOOK", which are descendants of "CATALOG", 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 heterogeneous data. In other words, it means the admissibility in objects of different types to have methods - procedures and functions - with the same names. During the 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 "CATALOG" class can have a different set of properties, i.e. programs for working with an object of class "BOOK" may contain polymorphic code. In the class, the method does not have a body, that is, it is not defined what specific actions it should perform. Each subclass performs the necessary operations. Encapsulation hides implementation details from all objects outside the given hierarchy.

The advantages of an object-oriented model in comparison with a relational one are the ability to display information about the complex relationships of objects, 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 can also be created. semantic information, 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 execution of requests.

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

Theme 5

Relational approach in 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 interrelated tables (relations).

The main theoretical ideas of the relational model were outlined in the works on relational theory 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 proved that the set of relations is closed under some 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, an article by E. Codd appeared on the presentation of data organized in the form of two-dimensional tables, called relations. Codd first introduced 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 Section "Relational Data Integrity").

Operators in the relational model are a set of instructions that provide fetching 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 the abstract representation of the selected subject area
DB Schema A set of table headers related to each other
Attitude Table - a set of real world objects that are characterized by common properties and characteristics (table fields)
Relationship header Table header - the names of the fields (columns) of the table
Relationship body The body of the table is a set of values ​​for all objects of the real world, which is represented as table entries (table rows)
relation scheme Table column header row (table header)
relation attribute Table column name (table field)
relation tuple Table row (record) – a one-to-one representation of a real-world object created using table field values
Domain The 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 An attribute of a table whose values ​​correspond to the values ​​of a primary key in another related (parent, primary) table. A foreign key can consist of one or more attributes (composite foreign key). If the number of foreign key attributes 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
Relationship power Number of rows (tuples) of the table
Relationship instance A set of records (tuples) for a given table (relation). An instance may change over time. Since a regular database at the current time works with only one version of the relation, such an instance of the relation is called the current one.
Data type Table element value type
Base ratio Relationship containing one or more columns characterizing the properties of the object, as well as a primary key
Derived relation Is not a base relation, i.e. does not characterize the properties of the object and is used to provide links between other tables, may not contain a primary key. If a primary key is specified, then it consists of foreign keys that are related to the primary keys of the base 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, an entry in one table can have at most one associated entry in another table. In both tables, the key fields must be primary. Used to separate tables with multiple fields or for data protection requirements
One-to-Many Relationship (1:M) 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 Relationship (N:M) With this type of relationship, one record in the first table can correspond to several records of the second table, but one record of the second table can also 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 links are transformed. To do this, you need to introduce an auxiliary relationship that allows you to replace the many-to-many relationship with two one-to-many relationships

The data structure of the relational model assumes the representation of the subject area of ​​the problem under consideration as a set of interrelated relationships.

In each relationship, one relationship can act as the main (base, parent), and the other as a subordinate (derived, child). To maintain these links, 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 subrelation must have an attribute set corresponding to primary key main relationship. Here, this set of attributes is already a secondary key or foreign key, i.e. defines a set of derived relation tuples associated with a single tuple of the base relation.

A set of interconnected tables form database schema.

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

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

R D 1×D 2×…×Dn,

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

Domain is a semantic concept that can be thought of 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 boolean condition to describe the subset of data allowed for that domain,

Carries a certain semantic load.

The main value of domains is that they restrict 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 within a relation are unique. 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:

(<A1: D1>, <A2: D2 >, …, <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 relation, then another relation is obtained. Even with the saved name.

Body relation contains a set of relation tuples.

Every tuple is a set of pairs of the form:

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

R(<A1:Val1>, <A2:Val2 >, …, <A n: Val n>).

Such that the value Val i attribute Ai belongs to the domain D i.

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

The relationship is usually written as:

R(<A1: D1>, <A2: D2 >, …, <A n: D n>),

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

relation scheme 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 refer:

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

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

For example, if the domain contains numeric data, then all comparison operations are allowed 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 is given 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 arrange attribute names in 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, the following conditions are satisfied for equivalent relations:

Having the same number of attributes;

The presence of attributes with the same names;

The presence of identical strings in relations, taking into account the fact that the order of attributes may vary;

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

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

The uniqueness of the relation name. The name of one relation must be different from the names of other relations.

The uniqueness of tuples. There are no identical tuples in relation. Indeed, the relation body 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.

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

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

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

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

Comment:

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

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

With a large number of experimental projects (and even commercial systems) there is no generally accepted object-oriented data model, and not because there is not a single complete model developed, but because there is no general agreement on the adoption of any model. In fact, there are more specific issues related to designing 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. Any object upon its creation 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

Each object has a state and behavior. The state of an object is a set of values ​​for 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 attribute of an object is also some object or a set of objects. The state and behavior of an object are encapsulated in an object; the interaction of objects is based on the transmission of messages and the execution of the 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 (if you do not take into account the possibility of inheritance). It is allowed to have primitive predefined classes whose instance objects do not have attributes: integers, strings, etc. A class whose objects can serve as the values ​​of an attribute of objects of another class is called the domain of that attribute.

It is allowed to generate a new class based on an already existing class - inheritance. In this case, the new class, called a subclass of an 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 only on the basis of 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 graph with a root, called a class lattice. An object of a subclass is considered to belong to any superclass of that class.

Object-oriented databases have found the widest application in such areas as computer-aided design / manufacturing (CAD / CAM), computer-aided software development (CASE), compound document management systems, i.e. in areas not traditional for databases. Examples of object-oriented DBMS are - POET, Jasmine, Versant, Iris, Orion.

2.2.4 Relational data model

In 1970, the American mathematician Codd E.F. published a revolutionary article in its content, suggesting the use of set theory for data processing. He argued that data should be linked according to their logical relationships (eg 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 - relation), 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 for this model he was awarded the prestigious Turing Award in Computing Theory.

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 terms, this can be represented as in Fig. 4.

Fig.4. Relational database table.

Each column has its own name. For example, in the table "Goods in stock" (Fig. 5.), the field names are as follows: Identifier, Product, Group name, Group, unit of measurement, Purchase price, Selling price, Availability in stock.

Rice. 5. Table "Goods in the Warehouse »

All values ​​in one 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 are of two types: primary and secondary.

primary key is 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 subordinate table is the secondary key of this relation, which, at the same time, performs the functions of the primary key in the main table. If by the value of the primary key one single instance of the record can be found, then by the value of the foreign key there are several (Fig. 6).

Fig.6. An 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.

The means of efficient access by key to a file record is indexing. Indexing creates an additional file that contains all the key values ​​of the data file in order. For each key, the index file contains a pointer to the corresponding entry in the data file. A pointer to an entry in the data file provides direct access to that entry.

To work with relational databases, the Structured Query Language (SQL) is now commonly used. It is a language used to create, modify, and manipulate data. The SQL language 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 database is considered as a standard for modern information systems.

Thus, the table is the main type of data structure of the relational model. The structure of a table is defined by a set of columns. Each row of the table contains one value in the corresponding column. The table cannot have two identical rows, the total number of rows is not limited. A column is a data element, 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 accessibility of understanding by the end user - the only information construct is a table;

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

Complete data independence. When changing the structure, the changes that need to be made in the 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;

Not always the subject area can be represented as a set of tables.

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

Basic concepts

Definition 1

Object Oriented Model data representation makes it possible to identify individual database records.

Database records and their processing functions are connected by mechanisms similar to the corresponding tools that are 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 a user-created type ( class), describes object properties.

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

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

When performing actions on data in an object-oriented model, logical operations are used, which are enhanced by encapsulation, inheritance, and polymorphism. With some limitation, 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 formed and subsequently corrected, which contain information for fast data retrieval.

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 CATALOG object that specifies the author's phone number and has the name phone, then the properties of the same name will be obtained for the CATALOG and SUBSCRIBER objects. The meaning of a property is determined by the object in which it is encapsulated.

Definition 4

Inheritance, the reverse of encapsulation, is responsible for extending the scope of the property to all descendants of the object.

For example, all BOOK objects that are children of the CATALOG object can be assigned the properties of the parent object: author, title, udk And isbn.

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

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

Definition 5

Polymorphism allows the same program code to work with heterogeneous 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

Main advantage object-oriented data model in contrast to the relational model is the ability to display information about the complex relationships of objects. The considered data model allows defining a separate database record and its processing functions.

TO shortcomings object-oriented model include high conceptual complexity, inconvenient data processing and low query execution speed.

To date, such systems are quite widespread. These include DBMS:

  • postgres,
  • orion,
  • iris,
  • ODBJupiter,
  • Versant,
  • Objectivity/DB,
  • object store,
  • static,
  • gem stone
  • g base.

Object Oriented Model

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

A standardized object-oriented model is described in the recommendations of the ODMG-93 (Object Database Management Group) standard. It has not yet been possible to fully implement the recommendations of ODMG-93. To illustrate the key ideas, consider a somewhat simplified model of an object-oriented database.

The structure of an object-oriented database (for example, Versant Object Database, Object Store, etc.) is graphically represented as a tree, the nodes of which are objects. Object properties are described by some standard type (for example, string - string) or a user-constructed type (defined as a class).

The value of a property of type string is a character string. The value of a property of type class is an object that is an instance of the corresponding class. Each object - an instance of a class is considered a descendant of the object in which it is defined as a property. An object is an instance of a class that belongs to its class and has one parent. Generic relations in the database form a coherent hierarchy of objects.

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

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

Operations similar to SQL commands can be used to a limited extent (for example, to create a database).

The creation and modification of the database is accompanied by the automatic formation and subsequent adjustment of indexes (index tables) containing information for quick data retrieval.

Let us briefly consider the concepts of encapsulation, inheritance and polymorphism in relation to the object-oriented database model.

Encapsulation limits the scope of a property name to the object in which it is defined.

Inheritance, on the other hand, extends the scope of the property to all descendants of the object.

Polymorphism in object-oriented programming languages ​​means the ability of the same program code to work with heterogeneous data. In other words, it means that objects of different types can have methods (procedures or functions) with the same names. During the execution of an object program, the same methods operate on different objects depending on the type of the argument. Searching in an object-oriented database consists of looking for similarities between an object specified by the user and objects stored in the database. A user-defined object called a goal object (object property of type goal) can generally be a subset of the entire object hierarchy stored in the database. The target object, as well as the result of the query execution, can be stored in the database itself.

The main advantage of the object-oriented data model in comparison with the relational one is the ability to display information about the complex relationships of objects. The object-oriented data model allows you to identify a single database record and define the functions for processing them.

The disadvantages of the object-oriented model are the high conceptual complexity, the inconvenience of data processing, and the low speed of query execution.

Data types

Initially, DBMS were used primarily to solve financial and economic problems. At the same time, regardless of the presentation model, the following main data types were used in databases:

  • numeric. Example data values: 0.43; 328; 2E+5;
  • character (alphanumeric). Data value examples: "Friday", "string", "programmer";
  • dates specified using the special type "Date" or as normal character data. Data value examples: 12/1/97, 2/23/1999.

In different DBMS, these types could differ insignificantly from each other in name, range of values, and type of representation. Subsequently, specialized data processing systems began to appear in new areas of application, for example, geoinformation, video image processing, etc. In this regard, developers began to introduce new types of data into traditional DBMS. Relatively new data types include the following:

  • temporary and date-time, designed to store information about time and (or) date. Example data values: 01/31/85 (date), 9:10:03 (time), 03/6/1960 12:00 (date and time);
  • character variables of variable length, designed to store textual information of great length, such as a document;
  • binary, designed to store graphic objects, audio and video information, spatial, chronological and other special information. For example, in MS Access, this type is the "OLE Object Field" data type, which allows you to store graphic data in the database in the BMP (Bitmap) format and automatically display them when working with the database;
  • hyperlinks, designed to store links to various resources (sites, files, documents, etc.) located outside the database, for example, on the Internet, a corporate intranet, or on a computer hard drive.

In modern DBMS with various data models, all of the listed data types can be used.

Liked the article? Share with friends!
Was this article helpful?
Yes
Not
Thanks for your feedback!
Something went wrong and your vote was not counted.
Thanks. Your message has been sent
Did you find an error in the text?
Select it, click Ctrl+Enter and we'll fix it!