Designing of databases

The purpose of the given report - to estimate today's problems and tendencies of development of technologies of designing of a DB, and also, even partly - requirements of tomorrow's day. The report can play one more role: to set a set of actual requirements which will serve as coordinates for positioning concrete private{individual} methods and tools of designing of a DB (partly also - means of their use and management of them) which are represented to two special sekcijakh to the given conference.

The integrated database - ascertaining of idea

Widely known methods of designing of databases (DB) have appeared during development of more and more complex{difficult} Information Systems (IS) which should consider{examine} needs{requirements} not one user, but the big groups and collectives. One such integrated DB was created for the decision of many problems{tasks}, each of which used only the part of the data, usually, crossed with the parts used in other problems{tasks}. Therefore the mainest methods of designing became methods of exception of redundancy in the data. These methods contacted other means of maintenance of logic integrity of the data.

The basic requirement of branch of programs from the integrated data has been formulated. This principle is directed on alienation of the data as a resource of the enterprise, is important also that, that the conservative data on character were separated from applied programs which could be exposed to changes often.

Other important problem of designing of a DB was maintenance of the necessary operational parameters, such as volume of external memory or execution time of various operations. Other requirements are known also. For example, the information should not be lost not only because of refusals of the equipment, but also owing to a mistake of the user. It differs from that position at which the one who solves a certain problem{task}, itself and is responsible for safety of the data for this problem{task}.

The understanding of the integrated DB as general{common} information resource of the enterprise was generated. The stored{kept} data became similar to the big computer which is simultaneously used by many users with the various purposes and should be efficient all time.

Behind idea - classical methodology of designing

The classical methodology of designing of a DB is a powerful and beautiful current with the philosophy, ways of perception{recognition} of a reality and ways of existence in her. In this current there was a applied mathematics, the concept of "World", "Subject domain" (About) and their models. Concerning designing a DB methods of performance of such design stages are realized and integrated into harmonous circuits:

Gathering of data about About (the analysis of needs{requirements} and the description About with use so-called "process" or up, " usage perspective " the approach and "not process" or isp, " information structure perspective " the approach);

Choice of language of performance so-called "semantic" model for fixing data about About, their subsequent analysis and synthesis of model of a DB;

The analysis of the collected data about About: classification, formalization and integration of structural elements of the description About, formalization both structural, and procedural restrictions of integrity of elements in the future model About, definition of dynamics{changes} of copies of objects About;

Synthesis of conceptual model of a DB: designing of the complete conceptual circuit of a DB in the chosen language of semantic modelling;

Choice of concrete model of the data and SUBD for realization of a DB;

Designing of the logic circuit of a DB for chosen SUBD (were called also " designing of realization ");

Development of physical structure of a DB (the "physical" or "internal" circuit, she - " the circuit of accommodation "), including accommodation of a DB on sites;

Development of technology and procedures of initial creation and filling of a DB;

Development of technology and procedures of support of a DB;

Development of universal programs of access to a DB and corresponding interfaces of users;

Supply with information of development of concrete programs of data processing: maintenance with a metainformation, the data of control examples, etc.;

Reception of feedback from developers of applied programs and users of Information System (IS) about completeness and efficiency of the organization of a DB;

Testing of a DB, its{her} development and improvement (adjustment) of its{her} structure.

There are all bases to name methodology classical: for the specified methods full, complete methodical systems are developed, for the majority of methods the formalized models, these models are offered - or, at least, their final expressive opportunities - have found real application in practice of designing. One only the list of the basic models of the data and their authors makes impressive impression, see their review, for example, in [Cikridzis85].

The discipline so-called the structural analysis was used at the design approach "from top to down". Strukturnost` contacts use of hierarchical structures for detailed elaboration of the data and functions, and "rigid" design procedures corresponding enough. The design circuit has received the name "cascade". She is well coordinated with the similar circuit of designing ON - the software.

Behind methodology - workshop of tools of designing of a DB

Designing complex on the subject orientation integrated and, usually, the big DB on the size became a challenge. Presence of complete methodology of designing has allowed to take care of "shoemaker - designer" and to start to sew to him boots as systems of automation of designing of a DB. This was promoted by presence of technological experience in the organization and computer support of systems of development of the software and, on the other hand, use of the active integrated dictionaries - directories of the data (dd/d, data dictionary/directory). So there were systems case (computer aided system engineering) - systems for structural designing a DB and connected with them IS, focused on the models of the data realized in various SUBD. The greatest popularity was received by case-systems for relational SUBD with sql-models of the data, and dd/d was renamed into a case-repository projected IS.

On this way has arisen two basic directions of development of case-systems and technologies of designing: case-systems for designing actually a DB (or t. n. upper-case) and the integrated tools allowing both to project a DB, and to develop applied programs using them. It is important to note, as upper-case generally have many means for the description of functions of processing of the information (at use of the process approach to gathering and the analysis of data about About) and storages of these descriptions in repositories. It confirms regulations about of strong communication{connection} of the project of a DB and project IS, basing on this DB. At the same time, this communication{connection} is not absolute, and the principle of branch of a DB from programs is saved.

Often integrirovannost` functions results in strong merging case-system with one SUBD on which case-means of development of applied programs are focused. Such merging has some displays, for example, the case-repository is supported by means "native", but unique SUBD, generation of applied programs is made by "native" tools of development of this SUBD, but only them. For such integrated case-systems display of conceptual model of a DB in the logic circuit often is done{made} also only for predetermined SUBD.

Last fact is connected to one more problem{task} which can be put at designing a DB: designing of a transferable{tolerable} DB which can be realized on platforms of different types of computers, operational systems, SUBD and even models of the data, and, if necessary, to be transferred from one platform on another.

In view of said, the classical Workshop of the designer of a DB includes set of classical structural methods of designing, a set of corresponding tools of modelling, realization, loading and support of a DB, and also the "cascade" organizational circuit of performance of these jobs by a principle "from top to down".

Especially - about time characteristics and transactions

Maintenance of operational characteristics of a DB - still uneasy problem{task} despite of increase of specific capacity of computers and decrease{reduction} in specific cost of memory. Thus definition of time characteristics of job from a DB and preservation of these characteristics while in service the DB concerns to trudnejshim to design problems{tasks}. At design stages definition of the rational physical circuit of a DB from ways of definition of time characteristics needs the following:

Opportunities of comparison of time parameters of variants of realization of different variants of the circuit of a DB, on some SUBD;

Opportunities of comparison of parameters of variants of realization of one circuit of a DB on different SUBD;

Opportunities of comparison of parameters of realization of one circuit of a DB on different hardware servers of a DB;

Opportunities of a prediction of time parameters of job of various applied programs and service programs - utilities.

The problem{task} of comparison of time parameters different SUBD is considered{examined} as independent. However, she often should be solved as a part of a design problem{task} of choice SUBD for a projected DB and during this designing.

The concept of transaction has been entered for definition of the finished set of actions above a DB which translates a DB from one complete status in logic sense in another. On his{its} base mechanisms of correct actualization and restoration of a DB were under construction, first of all. However, then on this basis began to be based both other mechanisms and methods.

Time ratings SUBD of the most popular tests last time are given as number of transactions of the certain standardized kind in unit of time. The distributed{allocated} processing is under construction on the basis of monitors of transactions.

It will be necessary to find out limits of opportunities of such division of jobs for fine enough portions. Here we shall note very important effect: practice of orientation on " tranzakcionnyj the approach " is closely connected to classical methodology of designing of a DB which developed, basically as methodology of designing so are named "operational" DB, that is databases which should fix separate made operations and to store{keep} model of the current actual status of object or About.

Rating of the achieved status

It is possible, that at the reader the impression was created as if we already own modern methodology or, at least, are close to this, that, unfortunately, not so, and, maybe, we never similar shall achieve anything. It is always simple to characterize methodology at a conceptual level, it is rather difficult to put her{it} into practice. A stumbling-block - complexity of penetration into an essence of a subject domain (for example, complexities of understanding of the mechanism of activity of the organization) and its{her} adaptations to new, it is possible the best, to conditions of functioning.

Similar problems are characteristic for SUBD as a whole. The system of databases should become an organic element of a control system of the organization - a pledge of its{her} successful application. However process of its{her} introduction is connected to the certain changes in the organization and in activity of its{her} employees, and we shall always collide{face} with natural inertness of people when the question is perception{recognition} of changes....

It is rather important, that means SUBD were adequate to needs{requirements} of users. As different models of the data, languages of the data and circuits can be necessary for different users, it is desirable, that SUBD supported set of means, and the user could choose from them the most suitable....

It is possible to call, certainly, into question value of such researches. Really, what bad was the programming language, it{he} eventually all the same can be taught{learnt}. Precisely as well means SUBD can be mastered for the certain period of time. But the problem will consist not in development of means, and in efficiency of their use. The machine should be the servant of the person, but not on the contrary!

Above the font selects the citation from [Cikritzis85]. Since then SUBD, methods of designing of a DB and corresponding tools have considerably added in opportunities. But other world too did not stand on a place, were essentially complicated facing to developers IS and a DB of a problem{task}. Also it is necessary to recognize: formulations Cikritzisa and Lokhovski have not become outdated.

As as from classical methods of designing it is applied in practice of present{true} time

Are put into practice:

SUBD, supporting relational model of the data of 1971 with some expansions (see, for example, [Dadli96]);

The hierarchical "cascade" circuit of structural designing of a DB at the approach "from top to down";

case-systems for structural designing databases, IS as a whole or, besides, applied programs IS. Most often are used: variants of er-model of the data; the tabulared relational model 1971 expanded with that or other additional set of means of descriptions of restrictions of integrity (reference integrity, business - rules); for the analysis of a "process" source of data models of dataflows or sadt, probably, expanded by additional communications{connections} on management (these communications{connections} cannot be mixed with the selected streams of conditions of performance of functions in the notation idef0) more often are given;

Utilities of dynamic administration of the DB, providing following functions:

Tracking of dynamics{changes} of parameters of operation of a DB: parameters are accessible at any moment on a background of job of applications, these parameters ("statistics") can be used for support of optimum dynamic construction of ways of a data access,

Creation of backup copies of a DB, as well as conducting copies of a DB of a hot reserve on a background of job of applications, restoration and recoil of fragments and a full DB,

Dynamic reorganization of a DB (pererazmehhenie a DB is possible{probable} and separate physical fragments, logic and physical re-structuring of the data), however, these opportunities are limited.

The account of the user requirements to data presentation in the greater range, than earlier. Requirements to the account of specificity of performances often began to be transformed from positions of desirability of presence of different external models of the data to position of availability of significant number of the user tools having various interfaces and, practically, various external models of the data.

That is lost

At the same time, much of a classical heritage in practice is not used or used badly. First of all, it concerns to use of the formalized methods and models if only they do not enter into used model of the data directly, and should be applied by designers to reception and high quality verification of design decisions, for example:

Full procedure of normalization of high degrees and minimization of a set of attitudes{relations} is not spent or spent seldom if examination of check on conformity even 3NF or BKNF is stipulated in case-means, this opportunity is seldom used in practice in view of its{her} bulkiness and high requirements to qualification of the designer using case;

Optimization of accommodation of a DB on devices of external memory is spent "by eye", the tests of time parameters distributed today are not adapted to the help in the decision of this problem{task} of designing;

As optimization of accommodation of a DB on sites of the distributed{allocated} DB is "by eye made.

Considerably smaller attention recently is given also to tool means of automation of physical designing of a DB, including mathematical and natural modelling of characteristics of a DB, including - in view of accommodation on sites distributed{allocated} IS. Optimization of accommodation of a DB on sites of the distributed{allocated} DB is not supported by the widespread case-means. Separate tools and jobs, including domestic researches, do not do{make} "weather" in Workshop of means of designing, and do not support alive school of this direction.

To this there are, in our opinion, some reasons:

High requirements to qualification of designers in the field of theoretical bases of classical designing a DB;

Bulkiness of the methods used in frameworks of the "cascade" circuit, in conditions of practical impossibility to provide stability of the big integrated solutions in the world with constantly varying requirements to IS;

Relative ease of performance of reorganization of logic and physical structure of a DB in relational SUBD (however, and it is concretized at the end of the report, in modern conditions such approach becomes one of traps for the designer).

Restrictions of classical methods

Classical models and methods were guided by the organization of storage and processing of in details structured data to that the concept of "attribute" as properties of the object represented by an atomic element of the data responded. In consequence{investigation} of it, for example, text-through DB at once were allocated in special type of databases. For their designing there was a separate current - the INFORMATION RETRIEVAL SYSTEM or Information retrieval systems.

After years and decades after the announcement of the classical models and concepts of classics in an obvious kind described their limitation. So, in [codd79] it has been specified, that " at discussion of modelling of semantics of the data the accent{stress} is done{made} on structural aspects to the detriment of aspects of processing. The structure without corresponding operations or meant methods is similar to anatomy in absence of physiology ".

In 14 years and co-authors in [codd93] fixed E.Kodd: "... The possession of the big corporate DB has small value if end users have no opportunities easily to synthesize the necessary information from these stocks (warehouses) of the data. Too often we have such circumstances. "

At last, has come{stepped} time, when designing of a DB (and IS as a whole) by classical rules of completeness and integrity often became practically senseless. Vesli P. Melling (garthner group) has specified in [Melling95]: " By 1990 almost all aspects of " standard procedure of job " with IT (Information Technologies - a comment. E.Z.) have been challenged, and computing architecture have escaped from under the control.... Standards of programming were washed away, and the concept of the irredundant, consistent, high-quality data suited unless for grudy stuff. "

The reasons of occurrence of new requirements

Phenomena of global computer communications and universal personal calculations (together in falling specific cost of means of computer facilities) have resulted in many new opportunities of a DB and their designing. The list of types of the stored{kept} and processable data has extended up to the possible{probable} limits determined by the most general{common} normative value of concept "given". Corporate DB include not only the unformatted elements and text-through fragments, but also a DB with the geoinformation, multimedia DB, and it not the exhaustive list.

Moreover, new opportunities IT - together with a number{line} of only economic reasons - have led to to increase in market opportunities and requirements of consumers, as consequence{investigation} - to sharp amplification{strengthening} of a competition in various industries and services. As the answer the announcement of an imperative of business - reengineering has served: from bpr M.Hammer ([hammer93]) before construction kiberkorporacij on Dzh. Martinu ([Martin95]). In these approaches realization of radical changes in the organization of primary activity of the enterprises is required. In particular:

Sharp decrease{reduction} in expenses of time, number of workers and other expenses for performance of production functions;

Globalization of business: job with clients and partners worldwide, and also job with the client in a mode 24*365;

Support on growth of mobility of the personnel, supply of the worker by all opportunities for independent reception of an end result;

Job on the future needs{requirements} of the client, accelerated promotion of new technologies.

If IT were one of pushes to such development of a situation they appeared are called and to provide success and a opportunity of planned reconstruction. There were new requirements to architecture corporate IS, as consequence{investigation} - new requirements to corporate DB.

Also, as itself IS it is impossible to consider{examine} in a separation from its{her} users, and new designing should be considered{examined} as integration of three components: requirements business of reengineering, the human factor and methods new IT. Real association of these three components, each of which has got qualitatively new filling in 90th years, has created the beginnings of that it is possible to name New System Designing - N.S.P..

That is necessary from databases for the answer to new requirements

Let's show new requirements to corporate DB by the example of two aspects of creation new corporate IS (from more than two tens kinds of the jobs making basis N.S.P. - see [Zinder96]):

Maintenance of the maximal opportunities for each worker, that is support of performance of all business - functions by that worker which receives an end result. From party{side} IS, the DB and SUBD for this purpose is required:

Maintenance of means of access to all necessary data with use of the distributed{allocated} DB, means replikacij the data, management of events in the data and processes of processing of transactions;

Use of architecture and software of storehouse of the data, means of Operative Analytical Data processing (olap), application of means of fast development of applications (rad) for creation " IS the head " (eis), means of support of decision-making (dss) on the basis of storehouse of the data, olap and rad/eis;

Application of means dss on the basis of the analysis of a DB of precedents, and also methods of a logic conclusion, neural networks and nejrokomp`juterov, etc.;

The offer of the uniform interface of the user for job with different components of the data and applications, use in this interface of the means raising simplicity of information search and the reference{manipulation} to concrete applied functions, for example, of function geoinformsistem, hypertext, a natural language, speech input.

Development of the concept and structure of a corporate database for new IS, realization of structure of the DB, supposing removal (essential reduction) restrictions on its{her} development, including, at change of functions or functional components of processing of the information:

Application of methods of componental designing of subject DB both for operational DB, and for historical DB of storehouses of the data, archives of documents, geo-information and other data;

Development of procedures of componental change of a corporate DB at change of business - procedures, kinds of the activity, used applications and geographical accommodation of the enterprise;

Constant actualization of conceptual model of activity of the enterprise for the account of the new concepts arising at change applied component on functionally similar and at change of kinds of activity of the enterprise, and construction on this basis of new interfaces between components IS;

Dynamic administration by fragments of the distributed{allocated} corporate DB at change of frequency of their use, at updating their structure and at change of their accommodation.

Some new technical requirements to databases can be received from the analysis in [Melling95].