Object-oriented data model example. Use of databases and information systems. Safety problems

Introduction

The emergence of the direction of object-oriented databases (OODB) was determined, first of all, by the needs of practice: the need to develop complex information application systems for which the technology of previous database systems was not entirely satisfactory. Of course, OODB did not arise out of nowhere. The corresponding basis was provided both by previous work in the field of databases and by the long-developing areas of programming languages ​​with abstract data types and object-oriented programming languages.

As for the connection with previous work in the field of databases, the strongest influence on work in the field of OODB was exerted by the development of the DBMS and the chronologically following family of databases in which management was supported complex objects. These works provided structural basis OOBD organizations. This abstract will discuss OOMD and OODBMS.

Object-oriented data model

Let's consider one of the approaches to building a database - using an object-oriented data model (OOMD). Data modeling in OOMD is based on the concept of an object. OOMD is usually used in complex subject areas for which the functionality of the relational model is not enough for modeling (for example, for design automation systems (CAD), publishing systems, etc.).

The object-oriented data model ODMG differs from other models primarily in one fundamental aspect. In the SQL data model and the true relational data model, a database is a collection of named data containers of the same generic type: tables or relationships, respectively. In an object-oriented data model, a database is a set of objects (data containers) of an arbitrary type.

When creating object-oriented DBMS (OODBMS), different methods are used, namely:

embedding tools designed for working with databases into an object-oriented language;

extension of the existing language for working with databases with object-oriented functions;

creation of object-oriented libraries of functions for working with databases;

creation of a new language and a new object-oriented data model.

The advantages of OOMD include ample opportunities domain modeling, expressive query language and high performance. Each object in the OOMD has a unique identifier (OID - object identifier). Accessing by OID is much faster than searching in a relational table.

Among the disadvantages of OODB, it should be noted the lack of a generally accepted model, lack of experience in creating and operating OODB, complexity of use and insufficient data protection tools.

Now let's look at how data model support is implemented in real systems database management.

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

Standard OOM described in the recommendations of the ODMG-93 standard (Object Database Management Group - object-oriented database management group). 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 can be graphically represented as a tree, the nodes of which are objects. The properties of objects are described by some standard type (for example, string) or a user-constructed type (defined as class).

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

Basic Concepts

Definition 1

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

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

Definition 2

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

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

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

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

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

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

Definition 3

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

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

Definition 4

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

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

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

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

Definition 5

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

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

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

Advantages and disadvantages of the object-oriented model

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

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

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

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

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

Standard OOM is described in the recommendations of the ODMG-93 standard (Object Database Management Group - object-oriented database management group). 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 can be graphically represented as a tree, the nodes of which are objects. The properties of objects are described by some standard type (for example, string) or a user-constructed type (defined as class).

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

Example logical structure The OO DB of librarianship is shown in Fig. 3.14. Here, an object of type LIBRARY is the parent of instance objects of the classes SUBSCRIBER, DIRECTORY and ISSUE. Different objects of type BOOK that have the same parent must differ in at least the accession number (unique for each instance of the book), but have the same property values isbn, udk, title And author.


Fig.3.14. Logical structure of a library science database

The logical structure of an object-oriented database is superficially similar to the structure of a hierarchical database. The main difference between them is the methods of data manipulation. To perform actions on data in an OOM database, 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 a database is accompanied by the automatic formation and subsequent adjustment of indexes (index tables) containing information for quick data retrieval.

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

Encapsulation limits the scope of a property name to the boundaries of the object in which it is defined. So, if you add a property to an object of type DIRECTORY that specifies 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. Thus, 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, title And author. If it is necessary to extend the inheritance mechanism to objects that are not immediate relatives (for example, between two children of the same parent), then an abstract property of type abs is defined in their common ancestor. Thus, the definition of abstract properties ticket And number in the LIBRARY object causes these properties to be inherited by all child objects SUBSCRIBER, BOOK and ISSUE. It is no coincidence that the property values ticket classes SUBSCRIBER and ISSUING shown in the figure will be 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 that it is permissible for objects of different types to have methods (procedures or functions) with the same names. During execution of an object program, the same methods operate on different objects depending on the type of the argument. In relation to our object-oriented database, polymorphism means that objects of the BOOK class that have 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.

Searching in an object-oriented database consists of finding out the similarities between an object specified by the user and objects stored in the database. A user-defined object, called a goal object (the object's property is of type goal), can generally be a subset of the entire hierarchy of objects stored in the database. The target object, as well as the result of the query, can be stored in the database itself. An example of a request for library card numbers and names of subscribers who received at least one book from the library is shown in Fig. 3.15.

Main dignity OOM of data in comparison with relational is the ability to display information about complex relationships between objects. OOM of data allows you to identify an individual database record and determine the functions for processing them.

Disadvantage OOM are high conceptual complexity, inconvenience of data processing and low speed fulfilling requests.


Fig.3.15. Database fragment with target object

Let us 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 the example: “ Clients», « Orders" And " Goods" Objects of the class " Clients» are specific clients; class properties - client number, client name City, Status, etc. Class methods - " Create an order», « Pay the bill" and so on. A method is some operation that can be applied to an object; a method is what an object should do. Class corresponding to table " Order Details", not required. Table data can be part of the class " Orders" Availability in class " Clients» method « Create an order" leads to interaction with class objects " Orders" And " Goods" In this case, the user does not need to know about this interaction of objects. The user only accesses the object " Orders" and uses the method " Create an order" The fact of impact on other databases may be hidden from the user. If the method " Create an order", in turn, calls the method " Check the client's creditworthiness", then this fact can also be hidden from the user. Relational databases require procedures to be written in Visual Basic for Application (VBA) to perform the same functions.

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

Object-oriented model

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

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

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

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

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

Encapsulation limits the scope of a property name to the boundaries of the object in which it is defined. So, if we add a property to an object of the Catalog type that specifies the phone number of the author of the book and is called phone, then we will get 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 contrary, extends the scope of a 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, udc, title and author. If it is necessary to extend the inheritance mechanism to objects that are not immediate relatives (for example, between two children of the same parent), then an abstract property of type abs is defined in their common ancestor. Thus, defining the abstract properties ticket and number in the Library object leads to the inheritance of these properties by all child objects Subscriber, Book and Issue. It is no coincidence that the values ​​of the ticket property of the Subscriber and Issue 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 permissible for objects of different types to have methods (procedures or functions) with the same names. During execution of an object program, the same methods operate on different objects depending on the type of the argument. In relation to the example under consideration, polymorphism means that objects of the Book class that have different parents from the Catalog class can have a different set of properties. Consequently, programs for working with objects of the Book class can contain polymorphic code.

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

Rice. 2.9 Logical structure of the library science database

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

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

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

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

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

Based on their form of ownership, BnDs are divided into state and non-state. According to the degree of accessibility, they distinguish between those that are publicly accessible and those 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 that the BnD must solve;

Scroll end users and their functions;

List of database requirements;

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 type of system software; an infological database model is built that most fully describes the subject area in user terms.

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

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

2. Main tasks solved by the data bank staff

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

We list the main functions and tasks performed by personnel during the development and operation of the database:

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

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

3) setting database integrity restrictions;

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 (separation of users, selection and verification of security measures, recording of unauthorized access attempts);

6) ensuring database recovery;

7) analysis of the effectiveness of BnD and development of the system;

8) working with users (collecting feedback, training);

9) system support software(acquisition, installation and development);

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

3. Databank users

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

Design,

Implementation,

Support,

Update and development,

Complete reorganization.

At each stage of existence, various 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 data bank being created, the range of its end users may essentially differ. These may be casual consumers accessing the database from time to time after receiving some information, and there may be ordinary users. Casual consumers can be considered as possible clients of the company, viewing a catalog of production or services with a generalized or detailed description. Employees working with programs specially designed for them, which provide automation of their actions in productivity functions, may 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 in the warehouse for new orders. Basic, specialized knowledge that should not be required of end users in the areas of language and computer technology.

Databank administrators

This is a group of users who, at the initial stage of developing a data bank, are 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 development and reorganization phase, this group is responsible for ensuring that the stack can be reorganized correctly without changing or ending its routine maintenance.

Application developers and administrators

This is a user group that functions during the design, creation and reorganization of a data bank. Application administrators coordinate the work of developers to develop a specific application or a group of applications combined in a functional subsystem. Developers of specific applications work with that part of the information from the database that is required for a specific application.

Not every databank can select every type of user. It is known that the development information systems with a tabular DBMS, the data store administrator, application administrator, and developer often existed within the same person. However, when creating today's complex enterprise databases, which are used to automate all or large parts of business processes in a large firm or corporation, there may be groups of application administrators and development departments. The most difficult operating modes are assigned to the database administrator group.

Let's look at them in more detail.

Part of the BnD administrator group should be:

System commentators;

Data structure developers and appearance regarding the information support data bank;

Developers of technological data processing processes;

System and application programmers;

Operating companies and experts in repair service.

The issue of commercial data bank plays an important role when selling experts.

Basic Functions of the Database Administrators Group

1. Research of the data area: description of the data area, laying out the text of integrity restrictions, determining the state (availability, confidentiality) of information, determining the needs of consumers, determining the correspondence of “data consumers,” determining the temporal volume characteristics of data processing.

2. Development of the database structure: definition of the composition and structure of database files and intermediate connections, selection of data optimization methods and access methods for information, description of the database in a data description language (DDL).

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

Setting declarative integrity constraints specific to the data area;

Determination of dynamic integrity constraints inherent in a data area during changes in information stored in the database;

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

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

Determination of integrity constraints for parallel operation of consumers in multi-user mode.

4. Loading initiation and database management

Developing a technique for initiating database loading, which will differ from the procedure for changing and adding data when using the database regularly;

Development of a technique for checking the entered data against the real state of the data area. Real objects of database models of a certain data area and correlations are intermediate, and at the moment of starting maintenance, this model must correspond completely to the state of the objects of the data area now by time;

According to the developed loading initiation technique, designing a data input initiation system may be necessary.

5. Data protection

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

Development of principles for protecting certain data and development objects; development of specialized methods for encoding information as it circulates in local and global information networks;

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

Security system testing;

Study of cases of violation of the security system and the development of dynamic methods for protecting information in the database.

6. Database recovery support

Development of organizational means archiving and database recovery principles;

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

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

8. Study of the effectiveness of the functioning of the BnD:

Study of BnD functioning indices

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

9. Working with end users:

Collecting information about changes in the data area;

Collection of information on the assessment of B&D work;

Consumer training, consumer consultation;

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

10. Preparation and support of system tools:

Study of software existing on the market and study of the possibility and necessity of their use within the framework of BnD;

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

Checking the functionality of the purchased software before connecting it to BnD;

Monitoring the connection of new software to BnD.

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

Selecting or creating a database development method;

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

Planning stages of development of BnD;

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

Installation external models developed applications;

Monitoring the connection of a new application to the work of BnD;

The ability to comprehensively troubleshoot a set of applications interacting from one database.