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.

Object oriented database(OODB) is a database in which data is modeled in the form of objects, their attributes, methods and classes.

Object-oriented databases are usually recommended for those cases where high-performance processing of data with a complex structure is required.

The OODB manifest proposes the required characteristics that any OODB must meet. Their choice is based on 2 criteria: the system must be object-oriented and be a database.

Mandatory characteristics

1. Support for complex objects. The system should provide for the possibility of creating compound objects by using the constructors of compound objects. Object constructors need to be orthogonal, that is, any constructor can be applied to any object.

2. Support for the individuality of objects. All objects must have a unique identifier that does not depend on the values ​​of their attributes.

3. Support for encapsulation. Correct encapsulation is achieved due to the fact that programmers have the right to access only the interface specification of methods, and the data and implementation of methods are hidden inside objects.

4. Support for types and classes. The OODB is required to support at least one concept of distinction between types and classes. (The term "type" is more in line with the concept of an abstract data type. In programming languages, a variable is declared with an indication of its type. The compiler can use this information to test operations performed on a variable for compatibility with its type, which helps to guarantee software correctness. On the other hand, a class is a kind of template for creating objects and provides methods that can be applied to those objects. Thus, the concept of "class" is more of a runtime rather than compile-time.)

5. Support for inheritance of types and classes from their ancestors. A subtype, or subclass, must inherit attributes and methods from its supertype, or superclass, respectively.

6. Overload combined with full binding. Methods should be applied to objects of different types. The implementation of a method must depend on the type of objects to which the method is applied. To provide this functionality, the binding of method names on the system should not take place until program execution time.

7. Computational completeness. The data manipulation language should be a general-purpose programming language.

8. The set of data types must be extensible. The user must have the means to create new data types based on a set of predefined system types. Moreover, there should be no distinction between how system and user-defined data types are used.

OO DBMS

Object oriented databases- databases in which information is presented in the form of objects, as in object-oriented programming languages.

To apply or not to apply object-oriented database management systems (OODBMS) in real projects today? In what cases should they be used, and in what cases not?

Here Benefits using OODBMS:

· There is no problem of mismatch between the data model in the application and the database (impedance mismatch). All data is stored in the database in the same form as in the application model.

· It is not required to separately support the data model on the DBMS side.

· All objects at the data source level are strongly typed. No more string column names! Refactoring an object-oriented database and the code that works with it is now automated, rather than a tedious and boring process.

ODMG standard

First manifest formally was just an article submitted to Conference on Object-Oriented and Deductive Databases by a group of individuals. As you can see in the previous subsection, the Manifesto's requirements were emotional rather than explicitly specified. In 1991, the ODMG consortium was formed (then this abbreviation was disclosed as Object Database Management Group, but later acquired a broader interpretation - Object Data Management Group). The ODMG consortium is closely related to the much larger OMG consortium ( Object Management Group), which was formed two years earlier. The main original goal of ODMG was to develop the industry standard for object-oriented databases (common model). The basic object model OMG COM ( Core object model). Over the course of more than a decade, ODMG has published three basic versions of the standard, the latest of which is called ODMG 3.0. sixteen

Ironically, although the ODMG is (in the author's opinion) out of the OMG, in recent years some OMG standards have relied on the ODMG object model. In particular, the OCL language specification ( Object Constraint Language), which is part of the general language specification UML 1.4 (and UML 2.0). In this article, we do not intend to conduct a detailed comparison of the OMG and ODMG approaches and refer interested readers to Encyclopedias of Kogalovsky and materials from the websites of these consortia. We will limit ourselves to a brief summary of the main ideas contained in the ODMG-3 standard.

ODMG architecture

The proposed ODMG architecture is shown in Fig. 2.1. This architecture defines a way of storing data and different types of user access to this "data store" 17. A single data store is accessible from a data definition language, a query language, and a number of data manipulation languages. 18 In fig. 2.1 ODL means Object Definition Language, OQL - Object Query Language and OML - Object Manipulation Language.

Rice. 2.1. ODMG architecture

Central to architecture is data model, representing the organizational structure in which all the data managed by the OODBMS is stored. Object definition language, query language, and manipulation languages ​​are designed in such a way that all their capabilities rely on the data model. The architecture allows for a variety of implementation structures for storing modeled data, but an important requirement is that all software libraries and all supporting tools are provided in an object-oriented framework and must be stored consistent with the data.

The main components of the architecture are as follows.

• Object data model. All data stored by an OODBMS is structured in terms of data model constructs. The data model defines the exact semantics of all concepts (see below for more details).

• Data Definition Language (ODL). Database schemas are described in terms of the ODL language, in which data model constructs are instantiated in the form of a definition language. ODL allows you to describe a schema as a set of object type interfaces, which includes the description of type properties and relationships between them, as well as the names of operations and their parameters. ODL is not a complete programming language; the types must be implemented in one of the languages ​​of the OML category. Also, ODL is virtual language in the sense that the ODMG standard does not require its implementation in OODBMS software products that are considered to be compliant with the standard. It is allowed for these products to support equivalent definition languages ​​that include all the capabilities of ODL, but adapted to the specifics of a specific system. However, the presence of the ODL language specification in the ODMG standard is important because the language specifies the properties of the data model.

• Object Query Language (ODL). The language has a syntax similar to that of SQL, but relies on the semantics of the ODMG object model. The standard allows direct use of OQL and its embedding in one of the languages ​​of the OML category.

Relational data model

Almost all modern systems are based on relational(relational) database management model. Name relational is connected with the fact that each record in such a database contains information related to only one specific object.

V relational All processed data in the DBMS are presented in the form of flat tables. Information about objects of a certain type is presented in tabular form: various attributes of objects are concentrated in the columns of the table, and rows are intended to reduce descriptions of all attributes to individual instances of objects.

The model created at the stage of infological modeling meets the principles of relativity to the greatest extent. However, to convert this model to a relational model, you need to perform a procedure called normalization.

Normalization theory operates with five normal forms... These forms are designed to reduce the redundancy of information, so each subsequent normal form must meet the requirements of the previous and some additional conditions. In practical database design, the fourth and fifth forms are generally not used. We have limited ourselves to considering the first four normal forms.

Let's introduce the concepts necessary to understand the process of reducing a model to a relational schema.

Attitude- abstraction of the described object as a set of its properties. During the infological design stage, we talked about the abstraction of objects and assigned some properties to them. Now, with conceptual design, we move to the next level of abstraction. At this stage, the objects, as such, no longer exist. We operate with a set of properties that define the object.

Relationship instance- a set of values ​​of the properties of a particular object.

Primary key- an identifying set of attributes, i.e. the value of these attributes is unique in this respect. There are no two instances of a relationship containing the same value in the primary key.

Simple attribute- an attribute whose values ​​are indivisible.

Complex attribute- an attribute whose value is a set of values ​​of several different properties of an object or several values ​​of one property.

Entity concepts ..

Domain

Domain is more specific to databases, although it has some analogies with subtypes in some programming languages. In its most general form, a domain is defined by specifying some basic data type to which the elements of the domain belong, and an arbitrary logical expression applied to the element of the data type. If this Boolean expression evaluates to true, then the data item is a domain item.

The most correct intuitive interpretation of the notion of a domain is the understanding of a domain as an admissible potential set of values ​​of a given type. For example, the Domain "Names" in our example is defined on the base type of character strings, but its values ​​can include only those strings that can represent a name (in particular, such strings cannot begin with a soft sign).

The semantic load of the domain concept should also be noted: data are considered comparable only if they belong to the same domain. In our example, the values ​​for the domains "Gap Numbers" and "Group Numbers" are of the integer type, but are not comparable. Note that most relational DBMSs do not use the domain concept, although Oracle V.7 already supports it.

Database technologies based on the above MDs are based on a static concept of information storage, focused on data modeling. However, new areas of technology application with complex, interconnected database objects, such as:

Computer-aided design;

Automated production;

Automated software development;

Office information systems;

Multimedia systems;

Geographic information systems;

Publishing systems and others - have demonstrated the limited capabilities of the static concept in terms of modeling objects in the real world.

For new types of complex specialized database applications, a dynamic concept of information storage is effective, which makes it possible to simulate data and processes acting on this data in parallel. This allows you to take into account the semantics of the domain and therefore most adequately describe these applications. This concept is based on the object-oriented approach widely used in software development. The MD, which implements this concept and is based on the object-oriented paradigm (OOP), is called the object-oriented data model (OOMD).

The construction of OOMD proceeds from the assumption that the subject area can be described by a set of objects. Each object is a uniquely identifiable entity that contains attributes that describe the state of "real world" objects and their associated actions. The current state of an object is described by one or more attributes, which can be simple or complex. A simple attribute can be of a primitive type (for example, integer, string, etc.) and take on a literal value. A composite attribute can contain collections and / or links. A reference attribute represents a relationship between objects.

The key property of an object is the uniqueness of its Identification. Therefore, every object in an object-oriented system must have its own identifier.

An Object Identifier (OID) is a database-internal way of tagging individual objects. Users who work with the dialog program for setting queries or viewing information, as a rule, do not see these identifiers. They are assigned and used by the DBMS itself. The semantics of the identifier in each DBMS is different. It can be either a random value or contain information necessary to find an object in the database file, for example, the page number in the file and the object's offset from its beginning. It is the identifier that should be used to organize references to the object.

All objects are encapsulated, that is, the representation or internal structure of the object remains hidden from the user. Instead, the user only knows that this object can perform some functions. For example, for a WAREHOUSE object, methods such as ACCEPT_PRODUCT, EXIT_TOBAP, etc. can be used. The advantage of encapsulation is that it allows you to change the internal representation of objects without reworking applications that use these objects. In other words, encapsulation implies data independence.

An object encapsulates data and functions (methods, according to OOP). Methods define the behavior of an object. They can be used to change the state of an object by changing the values ​​of its attributes, or to query the values ​​of select attributes. For example, there might be methods for adding information about a new rental property, updating an employee's salary information, or printing out information about a specific item.

Objects that have the same set of attributes and respond to the same messages can be grouped into Class(in the literature, the terms "class" and "type" are often used interchangeably). Each such class has its own representative - an object, which is a data element. Objects of a certain class are called it copies.

In some object-oriented systems, a class is also an object and has its own attributes and methods called class attributes and class methods.

Important OOP concepts are class hierarchy and container hierarchy.

Class hierarchy implies the possibility that each class, called in this case a superclass, has its own subclass. An example is the following chain: all programmers of an enterprise are its employees, therefore, every programmer who is an object of the PROGRAMMERS class within the OOMD is also an employee who, in turn, is an object of the EMPLOYEES class. Thus, PROGRAMMERS will be a subclass, EMPLOYEES will be a superclass. But programmers can also be divided into system and application. Therefore, PROGRAMMERS will be the superclass of the subclasses SIS_PROGRAMMERS and APPLICATION_PROGRAMMERS. Continuing this chain further, we get a class hierarchy in which each object of the subclass inherits the instances of variables and methods of the corresponding superclass.

There are several types of inheritance - single, multiple and selective. Single inheritance is a case where subclasses inherit from at most one superclass. Multiple inheritance - inheritance from more than one superclass. Selective inheritance allows a subclass to inherit a limited number of properties from its superclass.

Variable instance inheritance is called structural inheritance, method inheritance - behavioral inheritance, and the ability to use the same method for different classes, or rather, apply different methods with the same name for different classes is called polymorphism.

Object-oriented architecture also has another type of hierarchy - container hierarchy... It consists in the fact that some objects can conceptually be contained within others. Thus, an object of the DEPARTMENT class must contain the public variable HEAD, which is a link to the object of the EMPLOYEES class corresponding to the head of the department, and must also contain a link to a set of references to objects corresponding to the employees working in this department.

In some object-oriented systems, a class is also an object and has its own attributes and methods. The general characteristics of a class are described by its attributes. Object class methods are kind of analogous to properties of objects in the real world. Every object belonging to a particular class has these properties. Therefore, when creating an object, you must declare the class to which it belongs in order to define its inherent properties in this way.

The user and the object interact through messages. In response to each message, the system executes the appropriate method.

All links in the object model are made using reference attributes, which are usually implemented as OIDs.

Relationships in a relational database are represented by a mapping of primary and foreign keys. In the base itself, there are no structures for the formation of associations between tables, links are used as needed when joining tables. In contrast, relationships form the backbone of an object-oriented database, since each object includes the identifiers of the objects with which it is associated.

In OOMD, not only traditional links can be implemented, but also links conditioned by inheritance.

One-to-one communication (1: 1) between objects A and B is implemented by adding a reference attribute to object B to object A and (to maintain referential integrity) a reference attribute to object A to object B.

One-to-many relationship (1: M) between objects A and B is implemented by adding to object A a reference attribute to object B and an attribute containing a set of references to object A to object B (for example, a reference attribute B (OID2, OID3 ...) is added to object A, and to object instances B with OID2, OID3, ... a reference attribute A: OID1 is added.

Many-to-many relationship (M: N) between objects A and B is implemented by adding to each object an attribute containing a set of links.

In OOMD, you can use a whole-to-part relationship, which describes that an object of one class contains objects of other classes as its parts. In the case of a production database, there would be a whole-to-part relationship between the PRODUCT class and the PART and ASSEMBLY classes. This relationship is a variant of a many-to-many relationship with special semantics. A whole-to-part relationship is implemented like any other many-to-many relationship, using a set of related object identifiers. However, it, in contrast to the usual many-to-many relationship, has a different semantic meaning.

Since the object-oriented paradigm supports inheritance, in OOMD it is possible to use the relationship of the "is" type and the relationship of the "extends" type. The is relationship, which is also called the generalization-specialization relationship, generates an inheritance hierarchy in which subclasses are special cases of superclasses. This avoids describing re-inherited characteristics. When using the "extends" relationship, the subclass develops the functionality of the superclass rather than being limited to its particular case.

Consider how components such as integrity constraints and operations on data are implemented in OOMD.

The features of these components are determined by the specifics of the model. This specificity in OOMD is dictated primarily by such its internal concepts as the encapsulation of objects, that is, the secrecy of the internal structure, access to data only through predefined methods, the class hierarchy and the container hierarchy.

The specificity of the OOMD is also dictated by the specificity of the object. It manifests itself in the need to group objects into classes. Each object is included in one or another class depending on the task, and one object can belong to several classes at once (for example, the PROGRAMMERS and HIGHLY PAID families). Another specificity of an object is that it can "run over" from one class (subclass) to another. So a SYSTEM PROGRAMMER can become APPLIED over time. Thus, the class hierarchy is not analogous to the hierarchical model, as it might seem earlier, but requires the system to be able to change the location of each object within the class hierarchy, for example, move "up" or "down" within this hierarchy. But a more complex process is also possible - the system must ensure the ability of an object to be attached (detached) to an arbitrary top of the hierarchy at any time.

Integrity constraints play an important role in OOMD. For links in an object-oriented MD to work, the object identifiers on both sides of the link must match. For example, if there is a relationship between EMPLOYEES and their CHILDREN, then there must be some assurance that when an object describing a child is inserted into an object representing an employee, the identifier of the latter is added to the corresponding object. This kind of link integrity, somewhat analogous to referential integrity in a relational data model, is established using feedbacks. To ensure the integrity of the links, the designer is provided with a special syntax required to specify the location of the inverse object identifier. The responsibility to set constraints on the integrity of links (as well as referential integrity in a relational database) lies with the designer.

In OOMD, both the description of data and the manipulation of them occur using the same object-oriented procedural language.

The ODMG (Object Database Management Groop) group deals with the problems of standardization of object database technology. She developed an object model (ODMG version 2.0 was adopted in September 1997) that defines a standard model for the semantics of database objects. This model is important because it defines built-in semantics that an object-oriented DBMS (OODBMS) understands and can implement. The structure of libraries and applications using this semantics should be portable among the various OODBMSs that support a given object MD. The main components of the ODMG architecture are the Object Model (OM), Object Definition Language (ODL), Object Query Language (OQL), and the ability to link to C ++, Java, and Smalltalk.

The object data model in accordance with the ODMG 2.0 standard is characterized by the following properties:

The basic building blocks are objects and literals. Each object has a unique identifier. A literal has no identifier of its own and cannot exist separately as an object. Literals are always embedded in objects and cannot be referenced individually;

Objects and literals differ in type. Each type has its own domain, shared by all objects and literals of that type. Types can also have behaviors. If a type has some behavior, then all objects of that type have the same behavior. In practice, a type can be the class from which the object is created, an interface, or a simple data type (such as an integer). An object can be thought of as an instance of a type;

The state of an object is determined by a set of current values ​​implemented by a set of properties. These properties can be attributes of an object or a relationship between an object and one or more other objects;

The behavior of an object is determined by a set of operations that can be performed on an object or on the object itself. Operations can have a list of input and output parameters, each of which is of a strictly defined type. Each operation can also return a typed result;

A database definition is stored in a schema written in Object Definition Language (ODL). The database stores objects so that they can be shared by different users and applications.

DBMS based on OOMD are called object-oriented DBMS (OODBMS). These DBMSs are referred to as third generation DBMSs * (* The history of the development of data storage models is often divided into three stages (generations): the first generation (late 1960s - early 70s) - the hierarchical and network models; the second generation (ca. 1970-1980s) - the relational model; the third generation (1980s - early 2000s) - Object Oriented Models.).

Today, object-oriented databases are used in various organizations to solve a wide range of tasks. Analysis and generalization of the accumulated experience in the field of information technology data made it possible to identify applications in which the use of object-oriented databases is justified:

The application consists of a large number of interacting parts. Each of them has its own behavior, which depends on the behavior of others;

The system must handle large amounts of unstructured or complex data;

The application will provide predictable access to data, so the navigational nature of object-oriented databases will not be a significant disadvantage;

The need for ad hoc requests is limited;

The structure of the stored data is hierarchical or similar in nature.

At the moment, there are many object-oriented DBMS on the software market. Table 10.6 presents some of the commercial systems of this class.

Table 10.6

Modern commercial OODBMS,

their manufacturing companies and fields of application

One of the fundamental differences between object databases and relational databases is the ability to create and use new data types. An important feature of OODBMS is that the creation of a new type does not require modification of the base core and is based on the principles of object-oriented programming.

The core of the OODBMS is optimized for object manipulation. Natural operations for it are object caching, object versioning, separation of access rights to specific objects. OODBMSs are characterized by higher performance on operations requiring access and retrieval of data packed into objects, compared to relational DBMSs, for which the need to fetch connected data leads to additional internal operations.

Of great importance for OODBMS is the ability to move objects from one database to another.

When creating various applications based on OODBMS, the built-in structure of classes of a particular DBMS is important. The class library supports, as a rule, not only all standard data types, but also an extended set of multimedia and other complex data types, such as video, sound, sequence of animation frames. In some OODBMS class libraries have been created that allow storing and full-text search of documentary information (for example, Jasmine, ODB-Jupiter). An example of a basic class structure is shown in Fig. 10.17.

The main position in it is occupied by the TOdbObject class, which contains all the necessary properties and methods to control access to the database and perform indexing. All other classes override its methods by adding a validation check for the type they implement and a specific indexer.

As seen from Fig. 10.17, there are various classes in the structure focused on processing documentary information - TOdbText, TOdbDocument, TODBTextDocument, etc. Each document is represented by a separate object. Thus, the natural storage of documents is ensured. One of the most important operations is searching for documents by request. For most classes, the ability to search for objects by the value of a specific key is implemented. For the TOdbText class, the ability to form a search query for a phrase written in natural language is implemented.

The TOdbDocument class is special, capable of containing objects of different types. It consists of fields, each of which has a name and is associated with an object of a certain type. The presence of this class allows the user to expand the set of types. By modifying the container object (document), you can set a certain set of fields and thus obtain a new type of Document.

On the basis of ODB-Jupiter, OODBMS developers have created a full-featured information retrieval system ODB-Text, which has a universal structure of stored data and a powerful search engine. ODB-Text system is a tool for collective processing of documents and maintaining a corporate archive. Among the possible applications, we will name the automation of document management in a modern office, the construction of reference information systems (similar to the well-known Legal databases), maintenance of network databases, personnel records, bibliography, etc.

41. Features of the design of applied IS. Phases of IP development. (Topic 11, pp. 100-103).

11.1.3. Features of applied IC systems design

When building (choosing, adapting) an information system, you can use two main concepts, two main approaches (the third concept is a combination of them):

1. orientation to the problems that need to be solved with the help of this information system, i.e. problem-oriented approach (or inductive approach);

2. orientation towards technology that is available (updated) in a given system, environment, i.e. technology-oriented approach (or deductive approach).

The choice of the concept depends on strategic (tactical) and (or) long-term (short-term) criteria, problems, resources.

If at first the possibilities of the available technology are studied, and then actual problems that can be solved with their help are determined, then it is necessary to rely on a technology-oriented approach.

If, first, actual problems are identified, and then a technology is introduced that is sufficient to solve these problems, then it is necessary to rely on a problem-oriented approach.

At the same time, both concepts of building an information system depend on each other: the introduction of new technologies changes the problems being solved, and the change in the problems being solved leads to the need to introduce new technologies; both affect the decisions made.

System design (development) and use of any applied (corporate) information system must go through the following life cycle of the information system:

- pre-design analysis (experience in creating other similar systems, prototypes, differences and features of the system being developed, etc.), analysis of the external manifestations of the system;

- intrasystem analysis, internal analysis (analysis of system subsystems);

- systemic (morphological) description (presentation) of the system (description of the systemic goal, system relationships and connections with the environment, other systems and system resources - material, energy, information, organizational, human, spatial and temporal);

- determination of criteria for adequacy, efficiency and stability (reliability);

- functional description of the subsystems of the system (description of models, algorithms for the functioning of subsystems);

- prototyping (layout description) of the system, assessment of the interaction of subsystems of the system (development of a layout - the implementation of subsystems with simplified functional descriptions, procedures, and approbation of the interaction of these layouts in order to satisfy the system goal), while it is possible to use "layouts" of criteria for adequacy, stability, efficiency ;

- "assembly" and testing of the system - the implementation of full-fledged functional subsystems and criteria, the assessment of the model according to the formulated criteria;

- the functioning of the system;

- determination of goals for further development of the system and its applications;

- system maintenance - clarification, modification, expansion of the system's capabilities in the mode of its functioning (with the aim of its evolution).

These stages are fundamental for information systems reengineering.

The development of a corporate information system, as a rule, is carried out for a very specific enterprise. The specifics of the subject activity of the enterprise will undoubtedly influence the structure of the information system. But at the same time, the structures of different enterprises are generally similar to each other. Each organization, regardless of its type of activity, consists of a number of divisions that directly carry out one or another type of company activity. And this situation is true for almost all organizations, no matter what type of activity they are engaged in.

Thus, any organization can be considered as a set of interacting elements (divisions), each of which can have its own rather complex structure. The relationships between departments are also quite complex. In general, there are three types of links between the divisions of the enterprise:

Functional connections - each department performs certain types of work within a single business process;

Information communications - departments exchange information (documents, faxes, written and oral orders, etc.);

External relations - some units interact with external systems, and their interaction can also be both informational and functional.

The generality of the structure of different enterprises allows us to formulate some common principles of building corporate information systems.

In general, the process of developing an information system can be considered from two points of view:

By time, or by stages of the life cycle of the system being developed. In this case, the dynamic organization of the development process is considered, described in terms of cycles, stages, iterations and stages.

An enterprise information system is being developed as a kind of project. Many features of project management and project development phases (life cycle phases) are general, not depending not only on the subject area, but also on the nature of the project (it does not matter if it is an engineering project or an economic one). Therefore, it makes sense to first consider a number of general project management issues.

A project is a time-limited, purposeful change of a separate system with initially clearly defined goals, the achievement of which determines the completion of the project, as well as with established requirements for timelines, results, risk, scope of spending of funds and resources, and for organizational structure.

Usually for a complex concept (which, in particular, is the concept of a project) it is difficult to give an unambiguous formulation that fully covers all the features of the concept being introduced. Therefore, the given definition does not claim to be unique and complete.

The following main distinguishing features of the project as a management object can be distinguished:

Variability is a purposeful transfer of a system from an existing one to a certain

the desired state, described in terms of the goals of the project;

The limitation of the ultimate goal;

Limited duration;

Limited budget;

Limited resources required;

Novelty for the enterprise for which the project is being implemented;

Complexity - the presence of a large number of factors that directly or indirectly affect the progress and results of the project;

Legal and organizational support - creation of a specific organizational structure for the duration of the project.

Work efficiency is achieved by managing the project implementation process, which ensures the allocation of resources, the coordination of the work sequence and compensation of internal and external disturbing influences.

From the point of view of the theory of control systems, the project as a control object must be observable and controllable, that is, some characteristics are distinguished by which it is possible to constantly monitor the progress of the project (the property of observability). In addition, mechanisms of timely influence on the course of project implementation are required (the property of controllability).

The property of controllability is especially important in conditions of uncertainty and variability of the subject area, which often accompany projects for the development of information systems.

Each project, regardless of the complexity and amount of work required for its implementation, goes through certain states in its development: from a state when "the project is not yet" to a state when "the project is no longer there." The set of stages of development from the emergence of an idea to the complete completion of the project is usually divided into phases (stages, stages).

There are some differences in determining the number of phases and their content, since these characteristics largely depend on the conditions for the implementation of a particular project and the experience of the main participants. Nevertheless, the logic and the main content of the information system development process are in almost all cases the same.

The following phases of information system development can be distinguished:

Concept formation;

Development of technical specifications;

Design;

Manufacturing;

Putting the system into operation.

Let's consider each of them in more detail. The second and partially the third phases are usually called the phases of systems design, and the last two (sometimes this includes the design phase) - the phases of implementation.

Conceptual phase

Idea formation, goal setting;

Formation of a key project team;

Studying the motivation and requirements of the customer and other participants;

Collection of baseline data and analysis of the existing state;

Determination of basic requirements and restrictions, required material, financial and labor resources;

Comparative assessment of alternatives;

Submission of proposals, their examination and approval.

Development of a technical proposal

Development of the main content of the project, the basic structure of the project;

Development and approval of technical specifications;

Planning, decomposition of the basic structural model of the project;

Estimating and budgeting the project, determining the need for resources;

Development of schedules and enlarged work schedules;

Signing a contract with a customer;

Putting into operation the means of communication of the project participants and control over the progress of work.

Design

In this phase, subsystems, their interrelationships are determined, and the most effective ways of project execution and resource use are selected. Typical works of this phase:

Basic design work;

Development of private technical specifications;

Conceptual design;

Drawing up technical specifications and instructions;

Design submission, expertise and approval.

Development of

At this phase, coordination and operational control of project work is carried out, subsystems are manufactured, combined and tested. Main content:

Implementation of software development work;

Preparing for the implementation of the system;

Control and regulation of the main indicators of the project.

System commissioning

During this phase, tests are carried out, trial operation of the system in real conditions, negotiations are underway on the results of the project and on possible new contracts. Main types of work:

Complex tests;

42. The concept of the life cycle of IP. (Topic 11, pp. 103-105).

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 appear out of nowhere. The corresponding basis was provided both by previous works in the field of databases, and by the long-developing areas of programming languages ​​with abstract data types and object-oriented programming languages.

With regard to the relationship with previous work in the field of databases, the most powerful influence on the work in the field of OODB was the development of the DBMS and the next chronological database family, in which the management of complex objects was supported. These activities provided the structural basis for the OOBD organization. In this abstract, OOMD and OODBMS will be considered.

Object-oriented data model

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. ODM is usually used in complex subject areas that lack the functionality of the relational model for modeling (for example, for design automation systems (CAD), publishing systems, etc.).

The object-oriented data model ODMG differs from other models, first of all, 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 relations, respectively. In the object-oriented data model, a database is a collection of objects (data containers) of an arbitrary type.

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

embedding into the object-oriented language of means intended for working with a database;

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

creation of object-oriented libraries of functions for working with a database;

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

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

Among the disadvantages of OOMD, it should be noted the lack of a generally accepted model, lack of experience in the creation and operation of OODB, the complexity of use and insufficient means of data protection.

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

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.

The first formalized and generally accepted data model was Codd's relational model. In this model, as in all the following, three aspects were distinguished - structural, holistic and manipulative. Data structures in the relational model are based on flat normalized relationships, integrity constraints are expressed using first-order logic, and, finally, data manipulation is based on relational algebra or its equivalent relational calculus. As many researchers note, the relational data model owes much of its success to the fact that it relied on the rigorous mathematical apparatus of set theory, relations, and first-order logic. The designers of any particular relational system felt it their duty to show that their particular data model corresponded to the general relational model, which acted as a measure of the "relationality" of the system.

The main difficulties of object-oriented data modeling stem from the fact that there is no such developed mathematical apparatus on which a general object-oriented data model could rely. To a large extent, therefore, there is still no basic object-oriented model. On the other hand, some authors argue that the general object-oriented data model in the classical sense cannot be defined due to the inappropriateness of the classical concept of the data model to the object-oriented paradigm.

One of the most famous data model theorists, Beeri, offers an outline of a formal framework for OODB, which is far from complete and is not a data model in the traditional sense, but allows researchers and developers of OODB systems to speak at least one language (unless, of course, sentences Beeri will be developed and supported). Regardless of the further fate of these proposals, we consider it useful to summarize them briefly.

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

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

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

An important, albeit insufficiently substantiated, assumption of Beeri is that the two traditional layers - schema and data - are not enough for OODB. To accurately define an OODB, a meta-schema level is required, the content of which must determine the kinds of objects and relationships that are allowed at the database schema level. The meta-schema should play the same role for OODBs as the structural part of the relational data model plays for relational database schemas.

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

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

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

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

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

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

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

The O2 model supports multiple class inheritance based on the supertype / subtype relationship. The subclass is allowed to add and / or override attributes and methods. Ambiguities possible with multiple inheritance (in the naming of attributes and methods) are resolved either by renaming or by explicitly specifying the source of inheritance. A subclass object is an object of each superclass from which the subclass is derived.

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

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

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