Interrelation of data models, physical organization of databases...

Data Model Interaction, Physical Database Organization

The comparative characteristics of the merits of different data models are given, the rules for converting data from one model to another, which is very important when building a distributed database from already operating local databases with the same or different data models.

We consider the procedure for selecting a data model (in general, an ambiguous one) in the process of designing a database.

The questions of the physical construction of the database are discussed: methods for placing, updating and accessing data in the database.

Comparative characteristics of data models, transformation of data models

Described and Ch. 5-8 properties of relational, network, hierarchical, object-hierarchical and object-relational data models (we consider multidimensional models as a kind of hierarchical data models) can be systematized and compared (Table 9.1). It can be seen from the table that none of the models fully meets the requirements for modern databases.

In this connection, a number of problems arise, the main ones of which are: 1) transformation of data models; 2) the choice of data model and DBMS.

Let's discuss these issues.

In detail, the transformation (mapping) procedures are discussed later, here we consider the general statement of the problem.

Possible variants of transformations [10] of MD (into themselves and other models) are shown in Fig. 9.1.

Table 9.1

Comparative characteristics of database models

Model view

Advantages

Disadvantages

Hierarchical

Easy to understand

High performance when database structures and query match

Relations M: M can only be implemented artificially

There may be redundant data

Complicating Enable and Disable Operations

Deleting source segments deletes the generated segments

The procedural nature of building a database structure and manipulating data

Access to any child segment is possible only through the root segment

Strong dependence of logical and physical models

Limited set of query structures

Unable to implement tables with a nonlinear structure

Networking

Saving information when destroying an owner record

Richer query structure

Less dependence of logical and physical models

Ability to implement tables with a non-linear structure

Relations M: M can only be implemented artificially

The need for the programmer to know the logical structure of the database

The procedural nature of building a database structure and manipulating data

Possible loss of data independence during database reorganization

Relational

Arbitrary request structure

Easy operation and reflection of user views

Separation of physical model from logical and logical from conceptual

A good theoretical study

Relations M: M can only be realized artificially Necessity of data normalization The possibility of logical errors in normalization and implementation The impossibility of implementing tables with a nonlinear structure

Object -

Oriented

Unlimited set of data types

Ability to implement a table by a non-linear structure

Layered view of data

High speed due to missing key

Unnecessaryness of normalization

Easy extensibility of the structure and its flexibility

Reusing Data Types and Components

Implementation of the relations M: M

The complexity of mastering the model due to the complexity of the database structure Fuzzy programming language Insufficient data protection

Indistinct Simultaneous Access

Poor visibility structure

In the transformation, the transformation of the structures (schemes and constraints) defined by the IODR (position A - operations not covered), the operations corresponding to the NMD (position B) is singled out. It should be noted that with the manual conversion of MD, as done in Ch. 5-9, the one-to-one correspondence can (due to limitations) and not be, so in Fig. 9.1 introduced the concept of isomorphism - constructivity (position B).

We assume that the maps are constructive, if the implementation of the database corresponding to one source Ss schema is mapped to another implementation corresponding to another, the target St:

Transformation Types>

Fig. 9.1. Types of transformations:

A - operations are covered; The B-schemes are isomorphic; B-model odsh'akovy

In the general case this mapping is a homomorphism. Briefly describe the possible forms of transformation.

Restructuring - changing the structure within a single MD: the relationship scheme, including functional dependencies, is transformed into a schema with the same dependencies.

Translation - schema design when application requirements are expressed by means of one data model, and implementation is implemented using a different model.

Reorganization is a special case of restructuring, when the schemes Ss and St are isomorphic.

Conversion is defined as follows: for a given Ss schema corresponding to the Ms model and the associated database, get the St scheme corresponding to the Mt model and the associated database.

Detailing operational concepts.

View is a subscheme of various users in multi-user mode.

Transformation: for a given Ms Ss schema, find the St circuit corresponding to the Mt model, which can be used for database operations with the Ss schema. This can be a mapping of the view into a hierarchical and network model.

Homogeneous RDB is the construction of a global scheme from local (one-type) schemes that cover all other schemes.

A heterogeneous RDB is a general case of integration of local databases into a distributed database (RDB).

The rest of the transformations are special cases of integration. Of these, translation, transformation and conversion are of interest.

The most common are the integration transformations: homogeneous and heterogeneous, which are examined in detail later.

In the restructuring scheme St - the result of applying to the scheme Ss the operations of relational algebra and relational calculus with the mapping of structures and constraints. The solution is determined by the specific limitations of the model. In a relational model, for example, restructuring has no particular difficulty, since the specification of structures and constraints, as well as their management, is divided.

Thus, any ratio Rt of degree n in the scheme St is the result of the function f (Rs) of the same degree η of the relation Ss.

Complicated with constraints (functional dependencies). Suppose that there are relations R (A, B), S (C, D) and constraints A → B, C → D in Ss. Suppose that St: T = RA = C · S. Then St has a dependence A → BD.

The invertibility of a map does not always hold,

S: R (A, B, C), AB → C, C → BS,:

S = π A, C (R), T = πB, C (R), C → B.

The functional dependence of AB → C is not included in St, since A, B, C do not appear in the scheme of the same ratio. Due to the functional dependence of C → B, the connection S and T in C forms a connection without loss of information (S and T gives R), but the ability to maintain the constraint AB → C is lost.

Note that the set of rules for mapping structures and functional dependencies, as shown in Ch. 4, has the completeness and reliability: reliable initial data give reliable results.

Restructuring can be carried out for other MDs.

The difficulty of converting is that it does not operate with virtual objects, but with real objects. This is the case, for example, when you create one from two databases, and the operations can be performed on a physical or logical level.

The transformation of a relational MD into a hierarchical and network MD is shown in Ch. 5-7. This procedure with operations can be used to move from the conceptual model, which is closest to the relational MD, to the hierarchical and network MD.

thematic pictures

Also We Can Offer!

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