Home-Good to know-Object-oriented databases: achievements and problems. Object-relational data model

Object-oriented databases: achievements and problems. Object-relational data model

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

The standardized object-oriented model 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 (OODB) is 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 coherent hierarchy of objects.

An example of the logical structure of a librarianship OOBD is shown in Fig. 2.8.

Here, an object of type LIBRARY is the parent of instance objects of the SUBSCRIBER, DIRECTORY and ISSUE classes. Various objects type BOOK can have the same or different parents. Objects of type BOOK that have the same parent must differ by at least the accession number (unique for each instance of the book), but have same values properties isbn, udk, title And author.

Rice. 2.8. Logical structure of the library science database

The logical structure of the OODB is externally similar to the structure of the IDB. The main difference between them is the methods of data manipulation.

To perform actions on data in the database model under consideration, use logical operations, enhanced by object-oriented mechanisms of encapsulation, inheritance and polymorphism. Operations similar to SQL commands (for example, to create a database) can be used to a limited extent.

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

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

Encapsulation limits the scope of a property name to the boundaries of the object in which it is defined. So, if we add a property to an object of the DIRECTORY type that specifies the phone number of the author of the book and is called 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, 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 property values ticket classes SUBSCRIBER and ISSUING shown in the figure will be the same - 00015.

Polymorphism V 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 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 OODB 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 target object (an object's property has typegoal), V general case can 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. 2.9.

Rice. 2.9. A database fragment with a target object

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

Main shortcomings OOMD are high conceptual complexity, inconvenient data processing and low speed fulfilling requests.

In the 90s, there were experimental prototypes of OODBMS. Currently, there are more than 300 such DBMSs. Some systems have become relatively widespread, for example the following DBMS: Cache (InterSystems), ROET (ROET Software), Jasmine (Computer Associates), Versant (VersantTechnologies), O2 (ArdentSoftware), ODB-Jupiter (Inteltek Plus Research and Production Center ), as well as Iris, Orion and Postgres.

The advantages of OODB in the future should lead to their very wide distribution. To do this, you first need to solve problems to eliminate the inherent shortcomings of OODB: increase the flexibility of the database structure, build a clear programming language, work out the query parsing syntax, define several data access methods, work out issues of simultaneous access, define complex data enumeration, work out data protection and recovery. The list of problems that need to be solved can be continued.

However, even after solving these problems, the transition to OODB will be gradual and not very fast, since it will be difficult to break away from the huge number of existing relational DBMSs for objective and subjective reasons. To make such a transition less painful will be the inclusion of not only an object, but also a relational component in the OODBMS. In addition, MMD should be introduced into OODBMS to form OLAP data warehouse systems, which are increasingly in demand in practice.

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 each at least different accession numbers (unique for each copy of the book), but the same property values author, Name, udk And isbn.

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

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

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

Definition 3

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

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

Definition 4

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

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

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

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

Definition 5

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

In other words, it allows in objects different types have methods (functions or procedures) with 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 determine separate entry Database and its processing functions.

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.

Object-oriented data model

Object- relational model data

Other data models

The increasing complexity of database applications and the limitations of the relational model led to the development of the Codd model, which was first called extended relational model, and later received its development in the object-relational data model. Databases based on these models are usually classified as generation III.

The object-relational data model (ORDM) is implemented using relational tables, but includes objects similar to the concept of an object in object-oriented programming. ORMD uses such object-oriented components as custom data types, encapsulation, polymorphism, inheritance, method overriding, etc.

Unfortunately, to date, developers have not reached a consensus on what the ORMD should provide. In 1999 ᴦ. The SQL-99 standard was adopted, and in 2003 ᴦ. The second release of this standard was released, called SQL-3, which defines the main characteristics of the ORMD. But so far the object-relational models supported various manufacturers DBMSs differ significantly from each other. The prospects of this area are evidenced by the fact that leading DBMS manufacturers, including Oracle, Informix, INGRES, etc., have expanded the capabilities of their products to an object-relational DBMS (ORDBMS).

In most ORMD implementations, objects are considered to be an aggregate and a table (relationship), which may be part of another table. Data processing methods are presented in the form of stored procedures and triggers, which are procedural database objects and associated with tables. At the conceptual level, all data in an object-relational database is represented as relationships, and ORDBMSs support the SQL language.

Another approach to building a database is the use of an object-oriented data model (OODM). 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.).

When creating object-oriented DBMS (OODBMS), we use different methods, namely:

  • embedding tools designed for working with databases into an object-oriented language;
  • extension existing language working with databases using 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 modeling subject area, an expressive query language and high performance. Each object in the OOMD has unique identifier(OID – object identifier). Accessing by OID is much faster than searching in a relational table.

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

In 2000 ᴦ. working group ODMG(Object Database Management Group), formed by OODBMS manufacturing companies, has released the next standard (ODMG 3.0) for OODBMS, which describes the object model, query definition language, object query language and connecting languages ​​C++, Smalltalk and Java. ODMG standards are not official. The ODMG approach to standardization is essentially that after a new version of a standard is adopted by ODMG member organizations, a book containing the text of the standard is published.

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

Object-oriented data model - concept and types. Classification and features of the category "Object-oriented data model" 2017, 2018.

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.

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 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 coherent hierarchy of objects. Example logical structure 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 objects of type Books can have the same or different parents. 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 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. Inheritance, on the contrary, extends the scope of the property to all descendants of the object.

Polymorphism in object-oriented programming languages ​​means the ability of the same program code 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. Searching in an object-oriented database involves finding similarities between an object specified by the user and objects stored in the 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, O 2, ODB - Jupiter, Iris, Orion, Postgres.

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

Computer-aided design;

Automated production;

Automated development software;

Office information systems;

Multimedia systems;

Geographic information systems;

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

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

The construction of OOMD is based on 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 the actions associated with them. The current state of an object is described by one or more attributes, which can be simple or complex. A simple attribute can have primitive type(e.g. integer, string, etc.) and take a literal value. A composite attribute can contain collections and/or references. A reference attribute represents a relationship between objects.

The key property of an object is the uniqueness of its Identification. Therefore, each 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 working with a dialog-based query or information viewer typically do not see these identifiers. They are assigned and used by the DBMS itself. The semantics of the identifier is different in each DBMS. It can be either a random value or contain information necessary to find an object in a database file, for example, the page number in the file and the offset of the object from its beginning. It is the identifier that must be used to organize references to the object.

All objects are encapsulated, meaning 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. Thus, for a WAREHOUSE object, methods such as RECEIVE_GOOD, ISSUE_TOBAP, etc. can be used. The advantage of encapsulation is that it allows you to change the internal representation of objects without reworking the applications in which these objects are used. 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 its attribute values ​​or to query the values ​​of selected attributes. For example, there might be methods to add information about a new rental property, to update an employee's salary information, or to print information about a specific product.

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 concepts of OOP are class hierarchy and container hierarchy.

Class Hierarchy implies the possibility of each class, called in this case a superclass, having its own subclass. As an example, we can give the following chain: all programmers of any enterprise are its employees, therefore, every programmer who, within the framework of OOMD, is an object of the PROGRAMMERS class, 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 systems and application programmers. Therefore, PROGRAMMERS will be a superclass to the subclasses SIS_PROGRAMMERS and APPLICATION_PROGRAMERS. Continuing this chain further, we get a class hierarchy in which each object of a subclass inherits 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.

Inheritance of variable instances is called structural inheritance, method inheritance - behavioral inheritance, and the ability to use the same method for different classes or rather, applying different methods with the same name to different classes is called polymorphism.

Object-oriented architecture also has another type of hierarchy - container hierarchy. It is that some objects can be conceptually contained within others. Thus, an object of the DEPARTMENT class must contain the public variable HEAD, which is a link to the EMPLOYEES class object corresponding to the head of the department, and must also contain a link to a set of links 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. General characteristics a class is described by its attributes. Object class methods are a kind of analogue of the properties of real world objects. Each object belonging to a particular class has these properties. Therefore, when creating an object, it is necessary to declare the class to which it belongs, in order to thereby define its inherent properties.

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

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

Relationships in a relational database are represented by a comparison of primary and foreign keys. The database itself does not have structures for forming associations between tables; connections are used as needed when connecting tables. In contrast, relationships form the basis of an object-oriented database because each object includes the identifiers of the objects with which it is associated.

In OOMD, not only traditional connections can be implemented, but also connections due to 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 (1:M) relationship 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 instances of object B with OID2, OID3,... the reference attribute A is added: OID1.

Many-to-many (M:N) relationship 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-part” relationship, which describes that an object of one class contains objects of other classes as its parts. In the case of a manufacturing database, there would be a whole-part relationship between the PRODUCT class and the PART and ASSEMBLY classes. This connection is a variant of many-to-many communication with special semantics. A whole-part relationship is implemented like any other many-to-many relationship, using a set of related object identifiers. However, unlike the usual many-to-many relationship, it has a different semantic meaning.

Since the object-oriented paradigm supports inheritance, OOMD can use relationships of the “is” type and relationships of the “extends” type. The “is” relationship, also called the generalization-specialization relationship, gives rise to an inheritance hierarchy in which subclasses are special cases of superclasses. This makes it possible not to describe re-inherited characteristics. When using the "extend" relationship, the subclass extends the functionality of the superclass rather than being limited to a special case of it.

Let's look at how components such as integrity constraints and data operations 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 internal concepts as encapsulation of objects, i.e. hidden internal structure, access to data only through predetermined methods, class hierarchy and container hierarchy.

The specifics of the OOMD are dictated by the specifics 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 specific feature of an object is that it can “move” from one class (subclass) to another. Thus, a SYSTEMS PROGRAMMER can become an APPLICATION PROGRAMMER over time. Thus, a class hierarchy is not analogous to a hierarchical model, as it might previously seem, 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 a given hierarchy. But a more complex process is also possible - the system must provide the ability for an object to be attached (detached) to an arbitrary top of the hierarchy at any time.

Important role In OOMD, restrictions on the integrity of connections play a role. For links in an object-oriented MD to work, the object identifiers on both sides of the link must match each other. For example, if there is a relationship between EMPLOYEES and their CHILDREN, then there must be some guarantee that when an object describing a child is inserted into an object representing the employee, the latter's identifier is added to the corresponding object. This type of relational integrity, somewhat analogous to referential integrity in the relational data model, is established using feedback. To ensure the integrity of the relationships, the designer is provided with a special syntactic construct necessary to specify the location of the reverse object identifier. The responsibility to set constraints on the integrity of relationships (as well as referential integrity in a relational database) lies with the designer.

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

The ODMG (Object Database Management Group) group deals with the problems of standardization of object database technology. It developed an object model (ODMG 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 that use these semantics must be portable among different OODBMSs that support this object MD. The main components of the ODMG architecture are: the object model (OM), the object definition language (ODL), the object query language (OQL), and the ability to bind to C++, Java and Smalltalk.

Object Model data 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 does not have its own identifier and cannot exist separately as an object. Literals are always embedded in objects and cannot be referenced individually;

Objects and literals are distinguished by type. Each type has own domain, shared by all objects and literals of this type. Types can also have behavior. If a type has some behavior, then all objects of this type have the same behavior. In practice, the 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 ​​realized by a set of properties. These properties may be attributes of an object or relationships between an object and one or more other objects;

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

The database definition is stored in a schema written in the definition language objects Object Definition Language (ODL). The database stores objects, allowing them to be shared among different users and applications.

DBMSs based on OODS are called object-oriented DBMSs (OODBMSs). These DBMSs are classified 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) - hierarchical and network model; second generation (approximately 1970-1980s) - relational model; third generation (1980s - early 2000s) - object-oriented models.).

Today, object-oriented databases are used in various organizations to solve a wide range of problems. Analysis and generalization of 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 large number interacting parts. Each of them has its own behavior, which depends on the behavior of others;

The system must process large volumes of unstructured or complex structure data;

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

The need for unplanned requests is limited;

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

IN present moment There are many object-oriented DBMSs on the software market. In table 10.6 shows some of the commercial systems of this class.

Table 10.6

Modern commercial OODBMS,

their manufacturers and areas of application

One of fundamental differences object databases from relational ones is the ability to create and use new data types. Important Feature OODBMS is that the creation of a new type does not require modification of the database core and is based on the principles of object-oriented programming.

The OODBMS core is optimized for operations with objects. Natural operations for it are caching objects, maintaining versions of objects, and dividing access rights to specific objects. OODBMS is characterized by higher performance in operations that require access and retrieval of data packed into objects, compared to relational DBMS, for which the need to fetch connected data leads to additional internal operations.

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

When creating various applications based on an OODBMS, the built-in class structure of a particular DBMS is important. The class library usually supports not only everything standard types data, but also an expanded set of multimedia and other complex data types, such as video, sound, sequence of animation frames. Some OODBMSs have created class libraries that make it possible to store and full-text search document information (for example, Jasmine, ODB-Jupiter). Example basic structure classes are shown in Fig. 10.17.

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

As can be seen from Fig. 10.17, in the structure there are various classes focused on processing documentary information - TOdbText, TOdbDocument, TODBTextDocument, etc. Each document is represented by a separate object. This ensures natural storage of documents. One of the most important operations is searching for documents on 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 search query according to a phrase written in natural language.

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

Based on ODB-Jupiter, OODBMS developers created a fully functional information retrieval system ODB-Text, which has a universal structure of stored data and a powerful search engine. The ODB-Text system is a tool for collective processing of documents and maintaining a corporate archive. Among possible applications let's name the automation of document flow accounting in a modern office, the construction of reference and information systems (similar to the well-known Legal databases), the maintenance of network databases, personnel records, bibliography, etc.

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

11.1.3. Features of system design of applied ICs

When constructing (selecting, adapting) information system You can use two main concepts, two main approaches (the third concept is a combination of them):

1. focus on problems that need to be solved using this information system, i.e. problem-oriented approach (or inductive approach);

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

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

If the capabilities of existing technology are first studied, and then current problems that can be solved with their help are identified, then it is necessary to rely on a technology-oriented approach.

If current problems are first identified, and then 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 changing the problems being solved leads to the need to introduce new technologies; both influence 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;

– intra-system analysis, internal analysis(analysis of system subsystems);

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

– determination of criteria for adequacy, efficiency and sustainability (reliability);

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

– prototyping (layout description) of the system, assessment of the interaction of system subsystems (development of a layout - implementation of subsystems with simplified functional descriptions, procedures, and testing the interaction of these models in order to satisfy the system goal), while it is possible to use “models” of criteria for adequacy, sustainability, and efficiency;

– “assembly” and testing of the system - implementation of full-fledged functional subsystems and criteria, evaluation of the model according to the formulated criteria;

– system operation;

– defining goals further development system and its applications;

– maintenance of the system - clarification, modification, expansion of the capabilities of the system in the mode of its operation (for the purpose of its evolution).

These stages are the main ones for information reengineering of systems.

The development of a corporate information system, as a rule, is carried out for a very specific enterprise. Features of the subject activity of the enterprise will certainly 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 engage 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, three types of connections between departments of an enterprise can be distinguished:

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 departments interact with external systems, and their interaction can also be both informational and functional.

The common structure of different enterprises allows us to formulate some common principles for 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 life cycle the system being developed. IN 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 developed as a project. Many features of project management and the project development phase (life cycle phases) are common, independent not only of the subject area, but also of the nature of the project (it does not matter whether it is an engineering or an economic project). Therefore, it makes sense to first consider the series general issues project management.

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

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

The following main distinctive features of the project as a management object can be identified:

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

the desired state, described in terms of project goals;

Limitation of the final goal;

Limited duration;

Budget limitations;

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.

Efficiency of work is achieved through management of the project implementation process, which ensures the allocation of resources, coordination of the sequence of work performed and compensation of internal and external disturbing influences.

From the point of view of the theory of control systems, a project as a control object must be observable and controllable, that is, certain characteristics are identified by which the progress of the project can be constantly monitored (observability property). In addition, mechanisms for timely influence on the progress of project implementation are needed (controllability property).

The controllability property is especially relevant 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 the state when “the project does not exist yet” to the state when “the project no longer exists.” The set of stages of development from the emergence of an idea to the complete completion of a 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 of the specific project and the experience of the main participants. However, the logic and basic content of the information system development process are common in almost all cases.

The following phases of information system development can be distinguished:

Formation of the concept;

Development of technical specifications;

Design;

Manufacturing;

Putting the system into operation.

Let's look at each of them in more detail. The second and partially third phases are usually called system design phases, and the last two (sometimes the design phase is also included here) are implementation phases.

Conceptual phase

Formation of ideas, setting goals;

Formation of a key project team;

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

Collection of initial data and analysis of the existing state;

Determination of basic requirements and limitations, 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;

Drawing up estimates and budget for the project, determining resource requirements;

Development calendar plans and enlarged work schedules;

Signing a contract with the customer;

Putting into operation means of communication between project participants and monitoring the progress of work.

Design

At this phase, subsystems and their relationships are determined, and the most suitable ones are selected. effective ways project execution and resource utilization. Characteristic works this phase:

Performing basic design work;

Development of private technical assignments;

Performing conceptual design;

Compilation technical specifications and instructions;

Presentation of design development, examination and approval.

Development

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

Carrying out software development work;

Preparation for system implementation;

Monitoring and regulation of key project indicators.

Commissioning of the system

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

Comprehensive testing;

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



Related publications: