ECMA TR 58-1992 DATABASES AND NETWORKING《数据库和互联》.pdf

1、EUROPEAN COMPUTER MANUFACTURERS ASSOCIATIONDATABASES AND NETWORKINGECMA TR/58June 1992.EUROPEAN COMPUTER MANUFACTURERS ASSOCIATIONDATABASES AND NETWORKINGECMA TR/58June 1992.Brief HistoryWhen a number of computer systems are linked together to enable interworking these computers systems are said to

2、benetworked. Within a network of computers there may be many applications using databases at various locations. Ifusers on any of these network locations can access any database on the network, these databases are termed networkeddatabases, irrespective of whether these are local or remote databases

3、ECMA TC22 (Databases) considered that the structure and design of networked databases were not well known, anddecided to prepare an ECMA Technical Report providing tutorial information on this subject. This report, starting fromsome general modelling considerations and a number of practical example

4、s, arrives at a model for networked databasesand draws some conclusions on the implications for the standardisation work of the architecture of networkeddatabases.Adopted as an ECMA Technical Report by the General Assembly of June 1992.- i -Table of contentsPage1Scope 12 Structure 13 Acronyms 14 Mod

5、elling concepts 14.1 Introduction 14.2 Definitions 34.3 Components 34.4 Loosely coupled databases 54.5 Federated databases 64.6 Distributed databases 74.7 Centralised multi-processor databases 85 Outline of selected applications 85.1 Application 1 - Banking 95.2 Application 2 - Design project suppor

6、t environment 115.3 Application 3 - Travel agency 115.4 Application 4 - Intelligent network databases 125.5 Application 5 - Telephone network traffic control 155.6 Application 6 - Electronic library 166 Analysis of applications 187 Modelling considerations 208 Implications for standardisation 20- ii

7、 -.1ScopeThis ECMA Technical Report is intended to provide tutorial information on networked databases. It addressesthe area of designing, maintaining and controlling networked database systems providing database services tothe users of networked databases.A joint technical committee of the Internat

8、ional Organisation for Standardisation and International Electro-technical Commission (ISO/IEC JTC1) and other forums are currently progressing standards to makenetworking of databases a reality over the Open Systems Interconnection (OSI) reference model.These groups address the need to integrate da

9、ta held in database systems that:- are supplied by different vendors;- use different technologies;- are distributed or logically (if not physically) separated;- form part of an open systems environment.Such a database environment encompasses a range of:- network topologies,- data distribution,- coup

10、lings of application with data,- transaction management.Not all technical solutions are developed yet.The intent of this ECMA Technical Report is to inform readers who are unfamiliar with databases and net-works, and to reach conclusions that could be useful to standardisation groups.2 StructureThe

11、main clauses of this ECMA Technical Report are clause 4, containing the outline description of referencemodels for generic distributed or networked data systems; clause 5, exploring a number of possible applicationsand defining an architectural model in an uniform way; clause 6 presenting the result

12、s of the analysis of thedata collected in clause 5, and clause 7 describing the model emerging from this work. The implications for thestandardisation work are presented in clause 8.3 AcronymsACP Access control point CAD Computer-aided designCD-ROM Compact disk read-only memory DB DatabaseDBMS Datab

13、ase management system DP Data processorIND Intelligent network database IR Information retrievalOPAC Online public access catalogue OSI Open systems interconnectionPSTN Public switched telephone network SQL Sequential query languageUP User processor VLSI Very large scale integration4 Modelling conce

14、pts4.1 IntroductionBefore considering networked databases let us examine the reference model for a single databaseenvironment.- 2 -Front end Back endDatabaseSystemProgramUser DataDatabaseprocessor processorLocalterminalUser interface(Database language statements)User processor/Data processorinterfac

15、e(Database language statements)Database interfaceFigure 1 - Single database environmentNote that either a program or a human user may need to access the database. The User Processor (UP) is thefront end and the Data Processor (DP) the back end.In the OSI terminology, UP is referred to as “Client“ an

16、d DP as “Server“ .Database language commands flow across the user interface and the database interface.In a networked database, in essence each user at a location needs to be able to access any of the databases bethey local or remote. Figure 2 shows what is required.UP DP DBUP DP DBUP DP DB111222N N

17、NFigure 2 - Networked database environment- 3 -The figure can be reduced to the following diagram, which highlights the communication networks.UP DP DBUP DP DBUP DP DB111222N NNNetworkFigure 3 - Networked database environment - alternate representation4.2 DefinitionsSome of the terms used in this EC

18、MA Technical Report are explained below.4.2.1 Common query languageThe language used to define the data held in databases, such as SQL. It is often referred to as the querylanguage.4.2.2 Common schemaA schema is the design of a database and when this design is common for the whole organisation it is

19、referred to as the common schema.4.2.3 Data consistencyIntegrity of the data held in an organisations database resource.4.2.4 DirectoryThe addressing information for the databases within the system.4.2.5 Query decompositionThe order in which operations are carried out for a given transaction.4.2.6 Q

20、uery optimisationThe way a transaction is carried out, to make the whole operation as efficient as possible.4.2.7 ReplicationThe duplication of the data used for achieving better availability of data to the user at various locations.4.2.8 RoutingThe way communication paths are utilised in the course

21、 of the transaction.4.3 ComponentsFour different reference architecture are identified in a paper prepared by Mr. J.A. Larson - (Four ReferenceArchitectures for Distributed Database Management Systems, Computer Standards and Interfaces, NorthHolland Pub. Co. vol. 8, 1988/89, pp.209-221). These are d

22、iscussed in detail in 4.4 to 4.7, a summary isgiven in table 1.- 4 -Table 1 - Reference architectureTypes of databasesFeatures Loosely coupled Federated Distributed CentralisedQuery decomposition user user/dbms dbms dbmsQuery optimisation user user/dbms dbms dbmsRouting user user/dbms dbms dbmsDirec

23、tory user user/dbms dbms n.aReplication user user/dbms dbms n.aData consistency user user/dbms dbms n.aCommon schema no no yes yesCommon query language no no yes yesThis table identifies for each feature and type of database:- if the user is responsible for providing the feature (user)- if the DBMS

24、is responsible for providing the feature (DBMS)- if both are jointly responsible (user/DBMS)- if the feature is supported (YES/NO)- if it is not applicable (n.a.)The following components are used in the description of the database architectures.- Application program: it contains calls to the distrib

25、uted parts of the database.- Distributed execution monitor: routes requests to the respective distributed parts of the database(s),including choice of the distribution strategy and distributed transaction control.- User command translator: accepts user commands from a specific user interface and tra

26、nslates theminto a canonical (i.e. unique internal) representation.- Constraint enforcer: enforces integrity constraints independent of a specific database and modifies ca-nonical commands so that security and integrity constraints are enforced in all specific databases.- Distributed requests decomp

27、oser: translates a request from a client processor into a distributed execu-tion strategy consisting of several commands to be executed at one or more data processor.- Canonical command translator: converts canonical commands into commands of a specific DBMS tobe executed by a specific DBMS at run t

28、ime.- Run-time support of each specific database (component DBMS).The four architectures differ primarily in the relative placement of the distributed request decomposer and ofthe distributed execution monitor. As a reference, the structure of a single database is shown in figure 4.- 5 -Application

29、programUser commandtranslatorConstraint enforcerCanonical commandtranslatorRun-time supportDatabaseFigure 4 - Structure of a single database4.4 Loosely coupled databasesIn loosely coupled databases, all co-ordination by the distributed execution monitor is done directly beneaththe application progra

30、m level. This leads to a minimal co-operation between the involved databases and littlesystem support in executing distributed requests. In this architecture, the definition of the distributedexecution strategy is done by the application programmer.Loosely coupled databases are used in:- Inter-banki

31、ng co-operation with high local autonomy requirements (example 1, 5.1);- access to independent databases (hotels, flight booking) in travel applications (example 3, 5.3).Application programDistributed execution monitorUser commandtranslatorUser commandtranslator. . . . . .Constraint enforcer Constra

32、int enforcerCanonical commandtranslatorCanonical commandtranslatorRun-time support Run-time supportDatabase 1 Database 2Figure 5 - Structure of loosely coupled databases- 6 -4.5 Federated databasesThe basic idea of a federated database architecture is that independent databases provide support for g

33、lobal(distributed) database integration, with minimal co-operation. This means that, in general, for federateddatabases there is no global conceptual schema for the integrated distributed database, although some,partial, database integration is supported at the user interface for some classes of app

34、lications.In federated databases some global co-ordination is provided at and above the distributed execution monitorlevel. User commands are translated into an internal representation, and distributed requests are routedindependently from each other to the local database components. This still lead

35、s to a fairly high degree ofautonomy of the involved database systems, but it also supports a distributed application by some system-wide co-ordinating function.According to a federated architecture, the distributed request decomposer and the distributed executionmonitor are logically centralised an

36、d provide some distribution transparency for the application program. Ina federated database, no consistency constraints can be expressed across sites, global control does not exist.As the constraint enforcers reside at the local site, only the local sites have complete control of the access totheir

37、 local data.Application programUser command translatorDistributed request decomposerDistributed execution monitorConstraint enforcer Constraint enforcer. . . . . .Canonical commandtranslatorCanonical commandtranslatorRun-time support Run-time supportDatabase 1 Database 2Figure 6 - Structure of feder

38、ated databasesCases where hierarchically structured organisations need computer-based support for data management atdifferent levels of their organisation tend to use federated databases. For example:- within a department, the widespread use of intelligent workstations and appropriate software suppo

39、rtallows for data management for private or locally restricted use at a personal level;- for the common needs of a department, common data management functions are provided at adepartment level, and may be in several stages;- data management support for whole (sub)organisations is provided at the or

40、ganisational level.As - at least occasionally and potentially - organisational units at all levels have to network, an integrateddata management should be supported by an appropriate distributed DBMS. But for, e.g., organisational,- 7 -privacy, financial, optimisation, etc. reasons, a high degree of

41、 autonomous responsibility over their own datahas to remain with all respective local data management functions, too.A federated database environment provides an architectural compromise between, on one hand, system-wideintegration and, on the other, local site autonomy based on a distributed and on

42、ly partially integrated datamanagement system. Members of such a federation have the freedom to join or leave the integratedenvironment at any time. Taken to its logical conclusion this leads to a multi-database system.Federated databases are used in:- co-operation of different departments in the sa

43、me organisation;- co-operation of parallel workstations with common management services (example 2, 5.2);- integrated travel applications.4.6 Distributed databasesTightly coupled distributed databases integrate different databases distributed among different sites in anetwork providing the applicati

44、on program with a logical view of only one database. So, at the user interfaceof a distributed database there is only one global conceptual schema; all integrity and consistency constraintsare expressed and enforced at the global database level. As a consequence, distributed databases require adegre

45、e of close co-operation. This has an impact on local control and autonomy. The distributed databasemanagement system has to provide support for data distribution in a networking environment. Specifically,this means that a user need not know where the data resides. Such a characteristic of a distribu

46、ted databasesystems is usually called “distribution transparency“ or “location transparency“.Application programUser command translatorDistributed constraint enforcerDistributed request decomposerDistributed execution monitorCanonical commandtranslatorCanonical commandtranslator. . . . . .Run-time s

47、upport Run-time supportDatabase 1 Database 2Figure 7 - Structure of distributed databasesIn a distributed database environment, database operations are executable at a local or at a remote (i.e.global) level, as appropriate. An integrated distributed transaction management involves co-ordinatingtran

48、sactions spanning one or more locations. This can, in general, only be achieved at the expense of anadditional management overhead and of restrictions to the respective autonomy of the involved localdatabase components.- 8 -Distributed databases may be either homogeneous or heterogeneous systems. If

49、 the databases in a distributeddatabase environment are based on a single data mode (e.g. relational or hierarchical) then the distributeddatabases are said to be homogeneous, otherwise they are said to be heterogeneous.In a distributed database environment, programming language support can be generalised from what isknown from a centralised system in order to express the specific requirements of remote processing. A user-friendly way of expressing this is to hide distribution aspects at the programming language level, i.e. to makeremote data access transparent to the application