Conceptual model, Fragmentation and localization, Logical model - Databases

Conceptual model

The goal of the next stage is to build - based on TK - the main provisions of the created database without binding to a specific database.

Foreign designers prefer [2, 3, 5] to use for these purposes ER-diagrams, undoubted advantage of which is the possibility of automation of DB design.

However, when using ER-diagrams, serious difficulties arise:

• A high-level professional can work with ER-diagrams, apparently, due to lack of visibility of diagrams in the presence of a significant number of informal factors;

• In the apparatus of ER diagrams, diagrams of entities and attributes are actually constructed separately, which makes it difficult to specify the fields (attributes) of the connection of entities;

• there is no clear binding of entities to the inputs and outputs of the system, of which the projected database is an integral part

• This binding is not very clearly seen in the DF-diagrams accompanying ER-diagrams.

Fuzzy identification of entities can cause serious errors [6] at the initial stages of design. Such errors are very difficult to correct later.

At the same time, the system analysis clearly identifies the inputs, outputs, information flows, their forms and characteristics.

In this regard, when you first get acquainted with the database, it is more useful, according to the authors, to use more graphic communication schemes. After acquiring a certain experience, it is possible to gradually switch to the use of ER-diagrams.

On the basis of TK, a mode (single or multi user) and a variant (centralized or distributed) of the database are selected.

At the end of this stage, it is carried out - again based on TK - the selection of the DBMS, which, as shown in Ch. 9, involves the choice of both the data model and DBMS within the selected model.

At this stage, the normalization procedure is also possible.

The simplest normalization technology (TH1) is as follows:

1. Write a line (linearly) a list of all the fields received in the requirements analysis phase.

2. Identify relationships between fields.

3. Conduct normalization procedures with the construction of 1NF-5NF.

However, with a large number of fields this procedure is laborious, therefore it is advisable to use the TH2 technology.

1. Divide the fields into blocks (by subject sign).

2. Establish links between blocks.

3. Normalize at the level of the selected blocks.

If necessary, perform normalization within the blocks at a later stage.

In single-user mode, the list of fields is determined by the schema (data). In multi-user mode, you can use one of two options for forming a scheme.

1. From the scheme - to the subcircuits. Based on the workflow and the application algorithm (transformation algorithm), a schema is created that is further "scattered" between users.

2. From subcircuits to a schema. For each user, a subcircuit is identified, from which a general scheme is drawn up [1-3, 39].

Currently, the data is extracted at the requirements analysis stage, and therefore the first option is often used.

The described variants can be used in the stages of fragmentation and localization in the construction of distributed databases.

Fragmentation and localization

Horizontal fragmentation is initially carried out, which does not involve duplication of data. Nodes are identified in which the corresponding tasks of the transformation algorithm (application algorithm) are solved. A high degree of localization of data in nodes is desirable. Duplication takes place most often in order to improve reliability, less often - to improve performance. It is preferable to use client-server mode when creating a peer-to-peer network only between servers.

Logical model

Here the final normalization of the data is carried out. At this stage, the characteristics of the selected DBMS are taken into account, in particular the system of data types, methods for ensuring data integrity, ways of protecting and restoring data.

The physical model is used when selecting a hierarchical DBMS. When working with a relational DBMS, physical modeling reduces to selecting the page sizes (Delphi), data areas (Oracle) and is used, as a rule, when building super-large (by volume) databases. In all other cases, use the physical parameters by default.

thematic pictures

Also We Can Offer!

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