Object Oriented Data Model example. Object-oriented database model. Insufficient support for complex objects

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 ODMG-93 (Object DataBase Management Group) standard has been developed by the Object-Oriented Database Management Group. This standard has not yet been fully implemented.

The structure of an object-oriented database is graphically represented in the form of 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 type class. The behavior of objects is set using methods. Method Is an 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 DB:

"LIBRARY" - parent (ancestor) for "SUBSCRIPTION", "CATALOG", "ISSUE";

"CATALOG" 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. Above the database, you can perform actions such as logical operations, enhanced by object-oriented methods of encapsulation, inheritance and polymorphism.

Encapsulation restricts the scope of the property name to the limits of the object in which it is defined. So, if the property is added to the "CATALOG" telephone the author of the book, then obtained in the same way in "SUBSCRIPTION" and "CATALOG". 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. Thus, all objects of the "BOOK" type that are descendants of the "CATALOG" can be assigned the properties of the parent isbn, UDC, name 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 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 having different parents from the "CATALOG" 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 has no 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 the given hierarchy.

The advantages of the object-oriented model in comparison with the relational model are the ability to display information about 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 the object-oriented approach, databases can also be created with large amounts of semantic information, such as multimedia and specialized for specific subject areas (geographic, design, etc.).

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

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

Topic 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. This model is based on a set of interconnected tables (relations).

The main theoretical ideas of the relational model were presented in the 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 Peirce and Schroeder, it was proved that the set of relations is closed under some special operations that together form an abstract algebra. This most important property of relations 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 two-dimensional tables, called relations. Codd was the first to introduce the basic concepts and limitations of the relational model as the basis for storing data, 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 (relations). Data integrity is ensured by external and primary keys (see p. "Relational data integrity").

Operators in the relational model are a set of instructions that fetch and manipulate data.

Table 5.1. Elements of the relational model

Relational model term	Description

Database (DB)	A set of tables and other objects needed to abstractly represent the selected subject area
DB schema	A set of table headers that are related to each other
Attitude	Table - a set of objects of the real world, which are characterized by common properties and characteristics (table fields)
Relationship header	Table header - the names of the fields (columns) of the table
Relationship body	Table body - a collection of values for all objects in the real world, which can be represented as table records (table rows)
Relationship diagram	Row of table column headings (table "header")
Relationship attribute	Table column name (table field)
Relationship tuple	Table Row (Record) - An unambiguous representation of a real world object created using the values of the table fields
Domain	Many 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 (the value of the table row)
External key	A table attribute whose values correspond to the values of the primary key in another related (parent, primary) table. A foreign key can consist of one or several 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
The degree (arity) of the relationship	Number of table columns
The power of the relationship	Number of rows (tuples) of the table
Relationship instance	The set of records (tuples) for a given table (relationship). The instance may change over time. Since an ordinary database currently works with only one version of the relationship, such an instance of the relationship is called the current one.
Data type	Value type of table elements
Base relation	Relationship containing one or more columns characterizing the properties of the object, as well as the primary key
Derived Ratio	It is not a basic relationship, i.e. does not characterize object properties 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 associated with the primary keys of the underlying relationship
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 relationship (1: 1)	When using this type of relationship, a record in one table can have at most one associated record in another table. In both tables, key fields must be primary. Used for splitting tables with multiple fields or on-demand data protection
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 primary key must be specified in the first table, and the external key in the second.
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 correspond to several records of the first. The uniqueness of the 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 relations.

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 subordinate relationship must have a set of attributes corresponding to the primary key of the main relationship. Here, this set of attributes is already a secondary key or foreign key, i.e. defines the set of tuples of the derived relation. associated with a single tuple of the base relation.

Many interconnected tables form db schema.

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

Mathematically N-ary relation R Is a set of Cartesian product 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 the 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 a subset of the data allowed for this domain,

Carries a certain semantic load.

The main meaning 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 couple 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.

An R, defined across multiple domains, has two parts: a header and a body.

Relationship header- a fixed number of relationship attributes describing the Cartesian product of domains on which the relationship 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 the relation has changed, added, or removed attributes, then a different relation is obtained. Even with the name saved.

Body relationship contains many relationship tuples.

Each cortege is a set of pairs of the form:

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

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

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

The body of a relation is a collection of tuples, that is, a subset of the Cartesian product of domains. Thus, the body of a relation is itself a relation in the mathematical sense of the word. The body of a relationship can change while working with the database, since 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 with an indication of 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 comparisons specified for this domain.

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

The schemas of the two relationships are called equivalent if they have the same degree, and the ordering of the attribute names in the schemas is possible so that comparable attributes will be in the same places, i.e., attributes that take values from the same domain.

Thus, the following conditions are fulfilled for equivalent relations:

The presence of the same number of attributes;

The presence of attributes with the same names;

The presence of the same strings in the relationship, given that the order of the attributes may differ;

Relationships of this kind are different images of the same relationship.

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

The uniqueness of the name of the relationship. 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 the same rows. Each cell of a relationship contains only an atomic (indivisible) value.

Unordered tuples. Tuples are not ordered (from top to bottom), since the relation body 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, in which the rows are in different order.

Disorder of attributes. The attributes are not ordered (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 (for comparison, the columns in the table are ordered). This property is somewhat different from the mathematical definition of the relationship. The same relationship can be represented by different tables in which the columns are in different order.

Atomicity of attribute values. All attribute values are atomic. This follows from the fact that the underlying attributes have atomic meanings, that is, each triboot is associated with a range of values (a separate elementary type), the values of the attributes are taken from the same domain. Relationship schemas and tuples 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 the table can be a relation. In order for some 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 identical 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 interconnected relationships, which are called relational database schema.

Basic concepts

Definition 1

Object Oriented Model presentation of data makes it possible to identify individual records of the database.

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

Definition 2

Graphical representation an object-oriented database structure 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 DIRECT, SUBSCRIBER, and REFERENCE instance objects. Different objects of the BOOK type can have one or different parents. Objects of type BOOK that have the same parent must have at least different inventory numbers (unique for each copy of the book), but the same property values author, title, udk and isbn.

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

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

When creating and modifying the database, the automatic formation and subsequent adjustment of indexes (index tables), which contain information for fast data retrieval, are performed.

Definition 3

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

Definition 4

Inheritance, inversely encapsulating, is responsible for spreading the scope of the 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, 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, two descendants of the same parent), an abstract type property is defined in their common ancestor abs.

So the properties room and ticket in the LIBRARY object are inherited by all child objects REFERENCE, BOOK and SUBSCRIBER. That is why the values of this property of the SUBSCRIBER and OUTPUT 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, it 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

The main advantage object-oriented data model, in contrast to the relational model, consists in the ability to display information about complex relationships of objects. The considered data model allows you to define a separate database record and the functions of its processing.

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

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

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

In the object-oriented model (OOM), 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 those in object-oriented programming languages.

Standard OOM is described in the recommendations of the ODMG-93 (Object Database Management Group) standard. The ODMG-93 recommendations have not yet been fully implemented. To illustrate the key ideas, consider a somewhat simplified model of an object-oriented database.

The structure of the OO database is graphically represented in the form of a tree, the nodes of which are objects. The properties of objects are described by some standard type (for example, a string type) 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 instance of a class is considered a descendant of the object in which it is defined as a property. An instance object of a class belongs to its class and has a single parent. Generic relationships in the database form a related hierarchy of objects.

An example of the logical structure of the OO DB of librarianship is shown in Fig. 3.14. Here, an object of type LIBRARY is the parent for instance objects of the SUBSCRIBER, DIRECTORY, and OUTPUT classes. Different objects of type BOOK having the same parent must be different at least in the inventory number (unique for each copy of the book), but have the same property values isbn, udk, name and author.

Figure 3.14. The logical structure of the library database

The logical structure of the OO database is outwardly similar to the structure of a hierarchical database. The main difference between them lies in the methods of data manipulation. To perform actions on data in an OOM database, logical operations are used, strengthened 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 fast data retrieval.

Let's briefly consider the concepts of encapsulation, inheritance and polymorphism in relation to OOM databases.

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

Inheritance, on the contrary, it extends the scope of the property to all descendants of the object. So, all objects of the BOOK type that are descendants of an object of the DIRECTORY type can be assigned the properties of the parent object: isbn, udk, name and author. If it is necessary to extend the effect 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 is defined in their common ancestor. So, the definition of abstract properties ticket and room in a LIBRARY object causes these properties to be inherited by all child SUBSCRIBER, BOOK, and REFERENCE objects. It is no coincidence that the values of the property ticket of the SUBSCRIBER and ISSUE classes shown in the figure will be the same - 00015.

Polymorphism in object-oriented programming languages, it means the ability of the same program code to work with different types of data. In other words, it means that it is possible to have methods (procedures or functions) with the same names in objects of different types. During the execution of an object program, the same methods operate on different objects depending on the type of the argument. As applied to our OO DB, polymorphism means that objects of the BOOK class, having different parents from the DIRECTORY class, can have a different set of properties. Consequently, programs for working with objects of the BOOK class can contain polymorphic code.

Search in the OO database consists in finding out the similarity between the object specified by the user and the objects stored in the database. A user-defined object, called a goal object (the object property is of type goal), in the general case, can represent a subset of the entire hierarchy of objects stored in the database. The target object, as well as the result of the query execution, can be stored in the database itself. An example of a request for numbers of library cards and the names of subscribers who have received at least one book in the library is shown in Fig. 3.15.

The main dignity OOM versus relational data is the ability to display information about complex object relationships. OOM data allows you to identify a single database record and define the functions of their processing.

Disadvantage OOM are high conceptual complexity, inconvenience in data processing and low query speed.

Figure 3.15. Fragment of the database with the target object

Let's turn again to the Orders task, presented in the form of a relational data model in Fig. 3.8 and consider it in terms of an object-oriented database. There are three classes in total: " Clients», « Orders" and " Products". Objects of the class " Clients»Are specific clients; class properties - Customer No., Customer Name City, Status, etc. Class methods - " Create order», « Pay invoice" etc. A method is some kind of operation that can be applied to an object; a method is what an object should do. The class corresponding to the table " Order details", not required. Table data can be part of the class " Orders". Presence in the class " Clients"Method" Create order"Leads to interaction with objects of the classes" Orders" and " Products". In this case, the user does not need to know about this interaction of objects. The user only refers to the object " Orders"And uses the method" Create order". The impact on other databases can be hidden from the user. If the method " Create order", In turn, refers to the method" Check the customer's creditworthiness”, This fact can also be hidden from the user. In relational databases, performing the same functionality requires writing procedures in Visual Basic for Application (VBA).

In the 90s, there were experimental prototypes of OO database management systems. Currently, such systems are widespread. In particular, these include the following DBMSs: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltek Plus Research and Production Center), and Iris , Orion and Postgres.

With a large number of experimental projects (and even commercial systems), there is no generally accepted object-oriented data model, not because there is no complete model developed, but because there is no general agreement on the adoption of any model. In fact, there are more specific problems related to the development of declarative query languages, the execution and optimization of queries, the formulation and maintenance of integrity constraints, access synchronization and transaction management, etc.

The object-oriented model (Figure 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

Every object has state and behavior. The state of an object is a set of values for its attributes. Object behavior 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 is encapsulated in an object; the interaction of objects is based on the transmission of messages and the execution of the corresponding methods.

Many objects with the same set of attributes and methods form an object class. An object should only belong to one class (if you do not consider the possibility of inheritance). The presence of primitive predefined classes is allowed, the objects-instances of which 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 create 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. The subclass can also define additional attributes and methods. The cases of simple and multiple inheritance are distinguished. 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 inheritance of classes, the set of classes forms a tree hierarchy. While maintaining multiple inheritance, classes are linked into a rooted directed 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) systems, computer-aided software development (CASE) systems, 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 E.F. published an article that was revolutionary in its content, proposing to use set theory for data processing. He argued that data should be bound according to its logical relationship (eg union, intersection), not physical pointers. He proposed a simple data model in which all data is tabulated with uniquely named rows and columns. These tables are called relations (relatio - relation), and the model is a relational data model built on the concept of mathematical relations and it is sometimes also called the Codd model. Codd's proposals were so effective for database systems that he was awarded the prestigious Turing Prize for Computer Science for this model.

In relational databases, all data is stored in simple tables, divided into rows (called records) and columns (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, Stock availability.

Rice. 5. Table "Goods in Stock »

All values in one column are of the same type. Thus, fields are various characteristics (sometimes they say - attributes) of an object. Field values on one line refer to the same object, and different fields differ in name.

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, the value of which 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 relationship, which, at the same time, serves as 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. Example using a foreign key

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

Indexing is a means of efficient access by key to a file record. Indexing creates an additional file that contains all the key values of the data file in an ordered manner. For each key, the index file contains a pointer to the corresponding data file entry. A pointer to a record in the data file directly accesses that record.

To work with relational databases, the structured query language (Structured Query Language - SQL) is currently commonly used. It is a language used to create, modify, and manipulate data. SQL is not an algorithmic programming language. It 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);

· Operators of definition of access to data.

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 the data structure of the relational model. The structure of a table is determined by a collection of columns. Each row of the table contains one value in the corresponding column. There cannot be two identical rows in the table, the total number of rows is not limited. A column is a data item, each column has a name. One or more attributes whose values uniquely identify a table row is the table key.

The advantages of the relational model are:

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

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

Complete data independence. When the structure changes, 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 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 represent 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 are not yet standardized and widespread.

Object Oriented Model

In the 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 those in object-oriented programming languages.

A 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 in the form of 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 instance of a class is considered a descendant of the object in which it is defined as a property. An instance object of a class belongs to its class and has a single parent. Generic relationships in the database form a coherent 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 for instance objects of the Subscriber, Directory, and Issuance classes. Different Book objects can have the same or different parents. Objects of type Book having the same parent must differ at least by the inventory number (unique for each copy of the book), but have the same property values isbn, udc, title and author.

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

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

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

Inheritance, on the other hand, extends the scope of the property to all descendants of the object. Thus, all objects of the Book type that are descendants of an object of the Catalog type can be assigned the properties of the parent object: isbn, udk, title and author. If it is necessary to extend the effect 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 is defined in their common ancestor. So, the definition of abstract properties ticket and number in the Library object leads to the inheritance of these properties by all child objects Subscriber, Book and Issue. Therefore, it is no coincidence that the values of the ticket property of the Subscriber and Issuance classes 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 possible to have methods (procedures or functions) with the same names in objects of different types. During the execution of an object program, the same methods operate on different objects depending on the type of the argument. For this example, polymorphism means that objects of the Book class that have different parents from the Catalog class can have a different set of properties. Therefore, programs for working with objects of the Book class can contain polymorphic code.

Searching in an object-oriented database consists in finding out the similarity between the object, specified by the user, and the objects stored in the database.

Rice. 2.9 The logical structure of the librarianship database

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

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

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

Databanks as a whole are usually classified according to economic and legal characteristics.

According to the terms of the provision of services, free and paid banks are distinguished, which, in turn, are divided into commercial and non-profit (scientific, library or socially significant).

According to the form of ownership, BND are divided into state and non-state. According to the degree of accessibility, they distinguish between public and with a limited number of users.

Other types of classification are associated with individual components of BnD.

1. Development of data banks consists of 4 stages:

Stage 1. Formation and analysis of system requirements:

A system specification is drawn up, including a list of tasks to be solved by BND;

List of end users and their functions;

List of requirements for the database;

A document flow diagram in the organization is drawn up.

Stage 2. Conceptual design: an information model of the system is created without reference to the type of computer and the type of system software; an infological database model is built, which most fully describes the subject area in terms of the user.

Stage 3. Implementation design: a computing system, system software and a DBMS are selected; the data structure is designed and a database datalogical model (database schema) is built, which is a description of the logical structure of the database in the language of a specific selected database management system.

Stage 4. Physical implementation, which includes creating and loading data into a database, developing and debugging application programs for working with a database, writing documentation. At this stage, a physical model of the database is built, which describes the storage devices used, methods of physical organization of data. The description of the physical structure of a database is called a storage scheme. Currently, there is a tendency to reduce this type of work.

2. The main tasks solved by the personnel of the data bank

The staff of BND includes various specialists: BND administrators, system analysts, system and application programmers, operators, specialists in technical means, marketing, etc.

Let's list the main functions and tasks solved by the personnel during the development and operation of the database:

1) analysis of the subject area (determining the needs of end users, building an information model of the subject area, identifying integrity constraints);

2) designing the structure of the database (determining the composition and structure of the database files, describing its schema in the data description language);

3) setting the database integrity constraints;

4) loading and maintaining the database (database maintenance includes changing, deleting and adding records); development of loading and maintenance technology; development of data entry forms; data entry and control;

5) data protection (differentiation of users, selection and verification of protection means, recording of unauthorized access attempts);

6) ensuring database recovery;

7) analysis of BnD efficiency and system development;

8) work with users (collecting responses, training);

9) maintenance of system software (acquisition, installation and development);

10) organizational and methodological work (selection of design and modernization methods, planning the development of BND, development of documentation).

3. Users of data banks

Like any software-organizational-technical complex, a data bank exists in time and space. It has specific development stages:

Design,

Implementation,

Support,

Update and development,

Complete reorganization.

At each stage of existence, different categories of consumers are connected to the data bank.

End Users

This is the main category of users whose interests are related to the data bank. Depending on the characteristics of the created data bank, it may essentially differ in the circle of its end users. These can be random consumers who address the database from time to time to the database after receiving some information, and they can be ordinary users. Casual customers can be viewed as potential customers of the firm, browsing a catalog of performances or services with a generalized or detailed description. Employees working with programs specially designed for them, who provide automation of their actions in the performance of functions, can be ordinary users. For example, an administrator planning the work of an auxiliary division of a computer company has a program that helps him plan and arrange current orders according to instructions, monitor the progress of their productivity, and organize the necessary accessories for new orders in the warehouse. The main, special knowledge that should not be required from end users in the field of language and computer technology.

Data bank administrators

This is a group of users, which at the initial stage of the development of the databank is responsible for its optimal design from the point of view of the simultaneous operation of a set of end users, in support, the stage is responsible for the correct operation of this stack of information in multi-user mode. During the design and reorganization phase, this group is responsible for the ability to correctly reorganize the stack without changing or completing its ongoing maintenance.

Application Developers and Administrators

This is a group of users that functions during the design, creation and reorganization of the data bank. Application administrators coordinate the work of developers by developing a specific application or group of applications, united in a functional subsystem. Developers for specific applications work with the piece of information from the database that is required for a specific application.

Not every databank has every type of user selected. It is known that in the development of information systems using a tabular DBMS, the databank administrator, application administrator and developer often existed in one person. However, when creating modern complex enterprise databases that are used to automate all or large parts of business processes in a large firm or corporation, there may be application administrators groups and development departments. The most difficult operating modes are assigned to the group of database administrators.

Let's consider them in more detail.

Part of the BnD administrator group should be:

System commentators;

Developers of data structures and appearance regarding the information support databank;

Developers of technological data processing processes;

System and application programmers;

Operating companies and experts in the repair service.

Commercial databank issue plays an important role when selling experts.

The main functions of the group of DB administrators

1. Research of the data area: description of the data area, packing the text of integrity constraints, determining the state (availability, confidentiality) of information, determining the needs of consumers, determining the correspondence of "data consumers", determining the temporal volume of data processing characteristics.

2. Development of the structure of the database: the definition of the composition and the structure of the database files and intermediate connections, the choice of methods for optimizing data and access methods for information, describing the database in the data description language (DLS).

3. Setting integrity constraints in the description of the database structure and database processing procedures:

Setting declarative integrity constraints inherent in the data area;

Determination of dynamic integrity constraints inherent in the data area in the course of changing the information stored in the database;

The definition of integrity constraints is called by the structure of the database;

Development of procedures for maintaining the integrity of the database when entering and correcting data;

Determination of integrity constraints by parallel operation of consumers in multiuser mode.

4. Initiate download and guide the database

Development of a technique for initiating database loading, which will differ from the procedure for changing and adding data with regular use of the database;

Development of a technique for checking the entered data, the real state of the data area. The real objects of the database models of some data area and the correlation is intermediate, and at the time of the start of the current repair, this model must fully correspond to the state of the data area objects now by time;

According to the developed technique of initiating loading of the design of the system, the initiation of data entry may be necessary.

5. Data protection

Defining a password system, principles of targeting consumers, creating consumer groups with identical data access rights;

Development of principles for the protection of certain data and development objects; development of specialized methods for coding information during its circulation in local and global information networks;

Development of means of fixing access to data and attempts to violate the security system;

Testing the protection system;

Investigation of cases of violation of the protection system and the development of dynamic methods for protecting information in the database.

6. Support for database recovery

Development of organizational means archiving and database recovery principles;

Development of additional software and technological processes for database recovery after failures.

7. Investigation of calls to database consumers: a set of statistics on the symbol of requests, the time to turn on their performance, in accordance with the required output documents

8. Investigation of the efficiency of BnD functioning:

Investigation of the indices of BnD functioning

Planning restructuring (structural change) of the database and reorganization of the BND.

9. Working with end users:

Collecting information about changing the data area;

Collection of information on the assessment of BnD work;

Consumer training, consumer consultation;

Development of the necessary systematic and educational documentation regarding the work of end users.

10. Preparation and maintenance of system tools:

Research of software existing on the market and research of the possibility and necessity of their use within the framework of BND;

Development of the required organizational and technical program of movements for the development of BND;

Checking the performance of the redeemed software before connecting it to the BND;

Control of the connection of the new software to the BND.

11. Organizational and systematic work in the development of BND:

Selection or creation of a database development method;

Determination of goals and direction of development of the system as a whole;

Planning the stages of BnD development;

Development of reference books for general dictionaries of the BND project and a conceptual model;

Installation of external models of developed applications;

Control of the connection of the new application to the work of BND;

Possibility of complex troubleshooting of a set of applications interacting from one database.