THEORY OF LOGICAL MODELING, General-theoretical questions - Databases: design

THEORY OF LOGICAL SIMULATION

Based on the results of studying the material in this chapter, the student must: know

• approaches to the development of database models;

• tools used in the analysis of the domain;

• methods of normalization and normal forms of the logical model of the database;

be able to

• highlight the main and auxiliary functions of working with data;

• Analyze structural elements and data objects;

• highlight anomalies in the relationship;

• normalize relations; own

• skills of functional analysis of the domain;

• methods of information analysis of the domain;

• methods of using tools to build models of data flows.

This chapter of the textbook examines the basic issues of logical database modeling, based on the analysis of the subject area and consideration of information structures presented in documents. To implement the analysis and modeling processes, various tools are considered: ARIS Express, IBM WebSphere Business Modeler, MS Visio.

General theoretical questions

The procedure of logical database modeling allows the developer to better understand the structures of the information processed in the future information system and, on the basis of modeling tools, to go through the steps of forming an effective data structure with subsequent output to create a physical model of the database and physical database implemented in the database management system (DBMS).

Given the importance of this process, it is necessary to conduct a preliminary functional and information analysis of the subject area, which is based on information obtained as a result of the integrated design of the information system, where developers identify the main business processes implemented in the domain and their

Detailing, highlighting key information flows and used documents.

Functional analysis allows you to define the functionalization of data structures. This consideration of the domain allows the developer to divide all processed data according to a functional feature, reducing their number for review and modeling and thereby facilitating the process of modeling the database. Since the modeling process with the use of tools makes it possible to perform the functionalization within the framework of a single project, the functionalized database models that are built will be automatically merged into a single database model for the entire domain.

By the functionalization of data structures, we mean the separation of individual entities and the relationships between them that are necessary to solve the problems of a particular function.

Sometimes, especially if the function is large enough, functionalization can be performed at the level of tasks or individual operations. The main purpose of this functionalization is to minimize the size of the database model for the purpose of its subsequent effective maintenance. A graphical representation of the functionalization of data structures is implemented in the form of a hierarchy (tree).

In the interest of building a database and this implementation, three kinds of function trees are considered:

• Detail tree of functions - this representation assumes the construction of a tree, based on the principle of detailing (allocation) of functions;

• function dependency tree - this view allows you to see the needs of top-level functions in the implementation of lower-level functions;

• a tree of function relationships - this representation demonstrates the sequence of interaction of functions to achieve the objectives of the domain.

When building a tree of functions, these kinds of trees can be combined, but it is necessary to take into account that in the tree view you need to visually separate the functions of different types of trees by means of color, appearance or in another way. It is possible to build a tree of functions for each type separately. However, the most effective representation is the construction of two trees: a tree of detail and dependencies, a tree of connections.

Given that in the final analysis, when modeling data structures, a database model must be generated, the central element of the analysis is information that must be stored and processed in the database. In this regard, in addition to modeling functions in the analysis of the subject area, developers consider data streams that are implemented in the domain, forming a tree of relationships between functions and reflecting on the relevant diagrams the information of the domain used, the documents and data structures that describe the information being considered. >

The representation of the domain in the form of business process models and data flows allows you to identify the main information elements, some of which are represented by business elements, and the rest - documents and related information objects.

A business element is a data structure that describes a domain object, information about which is stored and processed in the database and characterizes the product or service produced on the basis of the business process.

It is the business elements of the domain become the central (key) data elements in the database. The main functional solutions in the future information system will be built around the business elements, namely, in the modification of the information about them from the moment of their appearance to the formation of exhaustive information describing the produced product of the service. Such elements in the database become data centers from which you can pounce to form an effective data structure.

An information object is a data structure describing the auxiliary or documentary (reporting) information necessary for the effective functioning of the information system.

Information objects, like business elements, make up data structures represented in the database, but can be implemented as separate elements of the database structure or in the form of an aggregated representation of data collected from different elements of the database structure. For this reason, all information objects are divided into concurrent (auxiliary) objects of the domain and document objects.

Related objects of the domain are the central (key) information elements of the dependency functions (auxiliary functions) necessary to generate business element information. Within the functionalization of the domain, such data elements are often the only structural components and are represented by classifiers (directories) of the subject area. For example, such objects can be a directory of codes, a directory of countries, a directory of cities and regions, a classifier of goods, etc.

Documentary objects are elements of a data structure in a database, but are represented by physical or electronic documents that contain the necessary information about the domain and are formed on the basis of information stored in the database.

In some cases, such objects can be represented as collateral objects, which is determined by the need to store the entire structure of the corresponding document with its data in the database. However, this is a special case, which is not implemented in every information system and not for every document.

Most often such objects are implemented in the physical model of the database in the form of a static or parametric representation. Despite the consideration of representations in the physical model of the database, understanding their structures provides information on the structures that must be implemented in the database, which requires their consideration at the stage of logical modeling.

Thus, the process of logical database modeling, based on the analysis of the domain, requires the implementation of a set of tasks (Figure 2.1).

Fig. 2.1. The process of logical database modeling

The

Having carried out functional and information analysis of the domain, the developer receives comprehensive information about the data structures used and the possibility to proceed directly to modeling the database, which can be performed in two ways:

a) documentary modeling, which treats the document as the main source of information about data structures, providing information about the attributes and characteristics used in documents. This approach is classical in database modeling, assuming the need for the initial selection of the entire set of attributes of domain objects with the subsequent application of normalization rules for aligning the structure of the database;

b) Object modeling, which treats objects of the domain as the main source of information about data structures, and documents become a companion element that characterizes the attributes of objects and indicates the need to use one or another attribute of the domain object. This approach provides the developer with a convenient technical tool for constructing a logical database model, where normalization is applied only

at the last stage to resolve various contradictions (anomalies) that were not taken into account in the process of building the database model.

Both approaches assume the use of normalization operations of the existing database model, which is considered as a process of transformation, which resolves the arising contradictions in the representation and processing of information stored in the database.

Along with the database modeling process, based on documents and domain objects, it often becomes necessary to represent individual structural elements that universalize data structures and are used to solve individual problems. Such structural elements, in particular, include hierarchical structures and structures of quasi-structured data. The implementation of such structures leads to a small demoralization of the database model, but in the interests of efficiency of processing and submission of relevant data, such demoralization seems justified. Moreover, as a whole, it has no significant effect on the database, giving great advantages in working with data.

thematic pictures

Also We Can Offer!

Ошибка в функции вывода объектов.