Pertemuan 12 Arsitektur DBMS Terdistribusi

ARSITEKTUR DBMS TERDISTRIBUSI

*STANDARISASI DBMSBerdasarkan Komponen.Komponen dari sistem didefinisikan bersama dengan keterkaitan antar komponen. Suatu DBMS terdiri dari sejumlah komponen, masing-masing menyediakan beberapa fungsi.

Berdasarkan Fungsi.Kelas-kelas yang berbeda dari pengguna diidentifikasi dan fungsi bahwa sistem akan melakukan untuk masing-masing kelas didefinisikan. Spesifikasi Sistem dalam kategori ini biasanya menentukan struktur hirarki untuk kelas pengguna.

*STANDARISASI DBMSBerdasarkan Data.Jenis data yang berbeda diidentifikasi, dan sebuah kerangka kerja arsitektur ditentukan yang mendefinisikan unit fungsional yang akan menyadari atau menggunakan data sesuai dengan pandangan yang berbeda. Pendekatan (juga disebut sebagai pendekatan datalogical) diklaim menjadi pilihan lebih baik untuk kegiatan standardisasi.

*STANDARISASI DBMSARSITEKTUR ANSI / SPARC ANSI / SPARC arsitektur diklaim didasarkan pada data organisasi. Ia mengakui tiga tampilan data: tampilan eksternal, yang adalah bahwa dari pengguna, yang mungkin programmer, pandangan internal, bahwa dari sistem atau mesin; dan pandangan konseptual, yaitu perusahaan. Untuk masing-masing pandangan, definisi skema yang tepat diperlukan.

*STANDARISASI DBMSARSITEKTUR ANSI / SPARC

*STANDARISASI DBMSARSITEKTUR ANSI / SPARC Pada tingkat terendah arsitektur adalah pandangan internal, yang berkaitan dengan definisi fisik dan organisasi data. Pada ekstrem yang lain adalah pandangan eksternal, yang berkaitan dengan bagaimana para pemakai memandang database. Antara kedua ujung adalah skema konseptual, yang merupakan definisi abstrak dari database. Ini adalah "dunia nyata" pandangan dari perusahaan yang dimodelkan dalam database.

*STANDARISASI DBMSARSITEKTUR ANSI / SPARC

*STANDARISASI DBMSARSITEKTUR ANSI / SPARC Kotak-kotak persegi merupakan fungsi pengolahan, sedangkan segi enam adalah peran administratif.Tanda panah menunjukkan data, perintah, program, dan aliran deskripsi, sedangkan "Aku" bar berbentuk pada mereka merupakan antarmuka.Komponen utama yang memungkinkan pandangan pemetaan antara data yang berbeda organisasi adalah data dictionary / directory (digambarkan sebagai segitiga), yang merupakan meta-database.Database administrator bertanggung jawab untuk menentukan definisi skema internal.Peran perusahaan administrator adalah untuk mempersiapkan definisi skema konseptual.Administrator aplikasi bertanggung jawab untuk mempersiapkan skema eksternal untuk aplikasi.

*STANDARISASI DBMSARSITEKTUR ANSI / SPARC Sistem ditandai sehubungan dengan: (1) otonomi sistem lokal, (2) distribusi, (3) heterogenitas.

*MODEL ARSITEKTUR UNTUK DISTRIBUSI DBMS Otonomi Otonomi mengacu pada distribusi kontrol, tidak ada data. Hal ini menunjukkan sejauh mana DBMSs individu dapat beroperasi secara independen. Tiga alternatif: ketat integrasi semiautonomous sistem isolasi total

*MODEL ARSITEKTUR UNTUK DISTRIBUSI DBMS Otonomi Tight integrasi. Gambar-tunggal seluruh database tersedia untuk setiap pengguna yang ingin berbagi informasi, yang dapat berada di beberapa database. Dari sudut pandang pengguna, data secara logis terpusat dalam satu database.Semiautonomous sistem. The DBMSs dapat beroperasi secara independen. Masing-masing DBMSs menentukan bagian mana dari database mereka sendiri, mereka akan membuat diakses pengguna DBMSs lain.Total isolasi. Sistem DBMSs individu yang berdiri sendiri, yang tidak mengetahui tentang keberadaan DBMSs lain atau bagaimana berkomunikasi dengan mereka.

*MODEL ARSITEKTUR UNTUK DISTRIBUSI DBMS Otonomi Distribusi mengacu pada distribusi data. Tentu saja, kita sedang mempertimbangkan distribusi fisik data melalui beberapa situs, pengguna melihat data sebagai salah satu kolam renang logis. Dua alternatif: client / server distribusi peer-to-peer distribusi (distribusi penuh)

*MODEL ARSITEKTUR UNTUK DISTRIBUSI DBMS DistribusiClient / distribusi server. Klien / server distribusi konsentrat tugas manajemen data pada server sedangkan klien fokus pada penyediaan lingkungan aplikasi termasuk user interface. Tugas komunikasi yang dibagi antara mesin klien dan server. Client / server DBMSs merupakan usaha pertama di mendistribusikan fungsionalitas.Peer-to-peer distribusi. Tidak ada perbedaan dari mesin klien versus server. Setiap mesin memiliki fungsionalitas penuh DBMS dan dapat berkomunikasi dengan mesin lainnya untuk mengeksekusi query dan transaksi.

*MODEL ARSITEKTUR UNTUK DISTRIBUSI DBMS HeterogenitasHeterogenitas dapat terjadi dalam berbagai bentuk dalam sistem terdistribusi, mulai bentuk heterogenitas perangkat keras dan perbedaan dalam jaringan protokol untuk variasi dalam manajer data. Mewakili data dengan alat pemodelan yang berbeda menciptakan heterogenitas karena kekuatan ekspresif yang melekat dan keterbatasan model data individu. Heterogenitas dalam bahasa query tidak hanya melibatkan penggunaan paradigma yang sama sekali berbeda akses data dalam model data yang berbeda, tetapi juga mencakup perbedaan dalam bahasa bahkan ketika sistem individu menggunakan model data yang sama.

*ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - ALTERNATIVESThe dimensions are identified as: A (autonomy), D (distribution) and H (heterogeneity).The alternatives along each dimension are identified by numbers as: 0, 1 or 2.

A0 - tight integrationD0 - no distribution A1 - semiautonomous systemsD1 - client / server systemsA2 - total isolationD2 - peer-to-peer systems

H0 - homogeneous systemsH1 - heterogeneous systems

*ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - ALTERNATIVES(A0, D0, H0)If there is no distribution or heterogeneity, the system is a set of multiple DBMSs that are logically integrated.(A0, D0, H1)If heterogeneity is introduced, one has multiple data managers that are heterogeneous but provide an integrated view to the user.(A0, D1, H0)The more interesting case is where the database is distributed even though an integrated view of the data is provided to users (client / server distribution).

*ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - ALTERNATIVES(A0, D2, H0)The same type of transparency is provided to the user in a fully distributed environment. There is no distinction among clients and servers, each site providing identical functionality.(A1, D0, H0)These are semiautonomous systems, which are commonly termed federated DBMS. The component systems in a federated environment have significant autonomy in their execution, but their participation in the federation indicate that they are willing to cooperate with other in executing user requests that access multiple databases.

*ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - ALTERNATIVES(A1, D0, H1)These are systems that introduce heterogeneity as well as autonomy, what we might call a heterogeneous federated DBMS.(A1, D1, H1)System of this type introduce distribution by pacing component systems on different machines. They may be referred to as distributed, heterogeneous federated DBMS.(A2, D0, H0)Now we have full autonomy. These are multidatabase systems (MDBS). The components have no concept of cooperation. Without heterogeneity and distribution, an MDBS is an interconnected collection of autonomous databases.

*ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - ALTERNATIVES(A2, D0, H1)These case is realistic, maybe even more so than (A1, D0, H1), in that we always want to built applications which access data from multiple storage systems with different characteristics.(A2, D1, H1) and (A2, D2, H1)These two cases are together, because of the similarity of the problem. They both represent the case where component databases that make up the MDBS are distributed over a number of sites - we call this the distributed MDBS.

*DISTRIBUTED DBMS ARCHITECTUREClient / server systems - (Ax, D1, Hy)

Distributed databases - (A0, D2, H0)

Multidatabase systems - (A2, Dx, Hy)

*DISTRIBUTED DBMS ARCHITECTURECLIENT / SERVER SYSTEMSThis provides two-level architecture which make it easier to manage the complexity of modern DBMSs and the complexity of distribution.

The server does most of the data management work (query processing and optimization, transaction management, storage management).

The client is the application and the user interface (management the data that is cached to the client, management the transaction locks).

*DISTRIBUTED DBMS ARCHITECTURECLIENT / SERVER SYSTEMSThis architecture is quite common in relational systems where the communication between the clients and the server(s) is at the level of SQL statements.

*DISTRIBUTED DBMS ARCHITECTURECLIENT / SERVER SYSTEMSMultiple client - single serverFrom a data management perspective, this is not much different from centralized databases since the database is stored on only one machine (the server) which also hosts the software to manage it. However, there are some differences from centralized systems in the way transactions are executed and caches are managed.

Multiple client - multiple serverIn this case, two alternative management strategies are possible: either each client manages its own connection to the appropriate server or each client knows of only its home server which then communicates with other servers as required.

*DISTRIBUTED DBMS ARCHITECTUREPEER-TO-PEER DISTRIBUTED SYSTEMSThe physical data organization on each machine may be different.Local internal scheme (LIS) - is an individual internal schema definition at each site.Global conceptual schema (GCS) - describes the enterprise view of the data.Local conceptual schema (LCS) - describes the logical organization of data at each site.External schemas (ESs) - support user applications and user access to the database.

*DISTRIBUTED DBMS ARCHITECTUREPEER-TO-PEER DISTRIBUTED SYSTEMS

*DISTRIBUTED DBMS ARCHITECTUREPEER-TO-PEER DISTRIBUTED SYSTEMSIn these case, the ANSI/SPARC model is extended by the addition of global directory / dictionary (GD/D) to permits the required global mappings. The local mappings are still performed by local directory / dictionary (LD/D). The local database management components are integrated by means of global DBMS functions. Local conceptual schemas are mappings of global schema onto each site.

*DISTRIBUTED DBMS ARCHITECTUREPEER-TO-PEER DISTRIBUTED SYSTEMSThe detailed components of a distributed DBMS.

Two major components:user processordata processor

*DISTRIBUTED DBMS ARCHITECTUREPEER-TO-PEER DISTRIBUTED SYSTEMSUser processoruser interface handler - is responsible for interpreting user commands as they come in, and formatting the result data as it is sent to the user,semantic data controller - uses the integrity constraints and authorizations that are defined as part of the global conceptual schema to check if the user query can be processed,global query optimizer and decomposer - determines an execution strategy to minimize a cost function, and translates the global queries in local ones using the global and local conceptual schemas as well as global directory,distributed execution monitor - coordinates the distributed execution of the user request.

*DISTRIBUTED DBMS ARCHITECTUREPEER-TO-PEER DISTRIBUTED SYSTEMSData processorlocal query optimizer - is responsible for choosing the best access path to access any data item,local recovery manager - is responsible for making sure that the local database remains consistent even when failures occur,run-time support processor - physically accesses the database according to the physical commands in the schedule generated by the query optimizer. This is the interface to the operating system and contains the database buffer (or cache) manager, which is responsible for maintaining the main memory buffers and managing the data accesses.

*DISTRIBUTED DBMS ARCHITECTUREMDBS ARCHITECTUREModels using a Global Conceptual Schema (GCS)The GCS is defined by integrating either the external schemas of local autonomous databases or parts of their local conceptual schemas. If the heterogeneity exists in the system, then two implementation alternatives exists unilingual and multilingual.

Models without a Global Conceptual Schema (GCS)The existence of a global conceptual schema in a multidatabase system is a controversial issue. There are researchers who even define a multidatabase management system as one that manages several databases without the global schema.

*DISTRIBUTED DBMS ARCHITECTUREMDBS ARCHITECTURE - models using a GCS

*DISTRIBUTED DBMS ARCHITECTUREMDBS ARCHITECTURE - models using a GCSA unilingual multi-DBMS requires the users to utilize possibly different data models and languages when both a local database and the global database are accessed.

Any application that accesses data from multiple databases must do so by means of an external view that is defined on the global conceptual schema.

One application may have a local external schema (LES) defined on the local conceptual schema as well as a global external schema (GES) defined on the global conceptual schema.

*DISTRIBUTED DBMS ARCHITECTUREMDBS ARCHITECTURE - models using a GCSAn alternative is multilingual architecture, where the basic philosophy is to permit each user to access the global database by means of an external schema, defined using the language of the users local DBMS.

The multilingual approach obviously makes querying the databases easier from the users perspective. However, it is more complicated because we must deal with translation of queries at run time.

*DISTRIBUTED DBMS ARCHITECTUREMDBS ARCHITECTURE - models without a GCS

*DISTRIBUTED DBMS ARCHITECTUREMDBS ARCHITECTURE - models without a GCSThe architecture identifies two layers: the local system layer and the multidatabase layer on top of it.The local system layer consists of a number of DBMSs, which present to the multidatabase layer the part of their local database they are willing to share with users of the other databases. This shared data is presented either as the actual local conceptual schema or as a local external schema definition.The multidatabase layer consist of a number of external views, which are constructed where each view may be defined on one local conceptual schema or on multiple conceptual schemas. Thus the responsibility of providing access to multiple databases is delegated to the mapping between the external schemas and the local conceptual schemas.

*DISTRIBUTED DBMS ARCHITECTUREMDBS ARCHITECTURE - models without a GCSThe MDBS provides a layer of software that runs on top of these individual DBMSs and provides users with the facilities of accessing various databases.

Fig. represents a nondistributed multi-DBMS. If the system is distributed, we would need to replicate the multidatabase layer to each site where there is a local DBMS that participates in the system.

*DISTRIBUTED DBMS ARCHITECTUREGLOBAL DIRECTORY ISSUEThe global directory includes information about the location of the fragments as well as the makeup of the fragments.The directory is itself a database that contains meta-data about the actual data stored in the database.

We have three dimensions:

1.type 2.location3.replication

*DISTRIBUTED DBMS ARCHITECTUREGLOBAL DIRECTORY ISSUETypeA directory maybe either global to the entire database or local to each site. In other words, there might be a single directory containing information about all the data in the database, or a number of directories, each containing the information stored at one site.

LocationThe directory maybe maintained centrally at one site, or in a distributed fashion by distributing it over a number of sites.

ReplicationThere maybe a single copy of the directory or multiply copies.

*DISTRIBUTED DBMS ARCHITECTUREGLOBAL DIRECTORY ISSUEThese three dimensions are orthogonal to one another. The unrealistic combination have been designed by a question mark.

DISTRIBUTED DATABASE DESIGN

*DISTRIBUTED DATABASE DESIGNThe organization of distributed systems can be investigated along three orthogonal dimensions:1. Level of sharing2. Behavior of access patterns3. Level of knowledge on access pattern behavior

*DISTRIBUTED DATABASE DESIGNLevel of sharingno sharing - each application and its data execute at one site,data sharing - all the programs are replicated at all the sites, but data files are not,data plus program sharing - both data and programs may be shared.Behavior of access patternsstatic - access patterns of user requests do not change over time,dynamic - access patterns of user requests change over time.Level of knowledge on access pattern behaviorcomplete information - the access patterns can reasonably be predicted and do not deviate significantly from the predictions,partial information - there are deviations from the predictions.

*ALTERNATIVE DESIGN STRATEGIESTwo major strategies that have been identified for designing distributed databases are:

the top-down approach

the bottom-up approach

*ALTERNATIVE DESIGN STRATEGIESTOP-DOWN DESIGN PROCESS

*ALTERNATIVE DESIGN STRATEGIESTOP-DOWN DESIGN PROCESSview design - defining the interfaces for end users,

conceptual design - is the process by which the enterprise is examined to determine entity types and relationships among these entities. One can possibly divide this process into to related activity groups:entity analysis - is concerned with determining the entities, their attributes, and the relationships among these entities,functional analysis - is concerned with determining the fundamental functions with which the modeled enterprise is involved.

*ALTERNATIVE DESIGN STRATEGIESTOP-DOWN DESIGN PROCESSdistributions design - design the local conceptual schemas by distributing the entities over the sites of the distributed system. The distribution design activity consists of two steps:fragmentationallocation

physical design - is the process, which maps the local conceptual schemas to the physical storage devices available at the corresponding sites,

observation and monitoring - the results is some form of feedback, which may result in backing up to one of the earlier steps in the design.

*ALTERNATIVE DESIGN STRATEGIESBOTTOM-UP DESIGN PROCESSTop-down design is a suitable approach when a database system is being designed from scratch.

If a number of databases already exist, and the design task involves integrating them into one database - the bottom-up approach is suitable for this type of environment. The starting point of bottom-up design is the individual local conceptual schemas. The process consists of integrating local schemas into the global conceptual schema.

*DISTRIBUTION DESIGN ISSUESREASONS FOR FRAGMENTATIONThe important issue is the appropriate unit of distribution. For a number of reasons it is only natural to consider subsets of relations as distribution units.If the applications that have views defined on a given relation reside at different sites, two alternatives can be followed, with the entire relation being the unit of distribution. The relation is not replicated and is stored at only one site, or it is replicated at all or some of the sites where the applications reside.The fragmentation of relations typically results in the parallel execution of a single query by dividing it into a set of subqueries that operate on fragments. Thus, fragmentation typically increases the level of concurrency and therefore the system throughput.

*DISTRIBUTION DESIGN ISSUESREASONS FOR FRAGMENTATIONThere are also the disadvantages of fragmentation:if the application have conflicting requirements which prevent decomposition of the relation into mutually exclusive fragments, those applications whose views are defined on more than one fragment may suffer performance degradation,the second problem is related to semantic data control, specifically to integrity checking.

*DISTRIBUTION DESIGN ISSUESFRAGMENTATION ALTERNATIVESThe are clearly two alternatives:horizontal fragmentationvertical fragmentation

The fragmentation may, of course, be nested. If the nestings are of different types, one gets hybrid fragmentation.

*DISTRIBUTION DESIGN ISSUESDEGREE OF FRAGMENTATIONThe extent to which the database should be fragmented is an important decision that affects the performance of query execution.

The degree of fragmentation goes from one extreme, that is, not to fragment at all, to the other extreme, to fragment to the level of individual tuples (in the case of horizontal fragmentation) or to the level of individual attributes (in the case of vertical fragmentation).

*DISTRIBUTION DESIGN ISSUESCORRECTNESS RULES OF FRAGMENTATIONCompletenessIf a relation instance R is decomposed into fragments R1,R2, ..., Rn, each data item that can be found in R can also be found in one or more of Ris. This property is also important in fragmentation since it ensures that the data in a global relation is mapped into fragments without any loss.ReconstructionIf a relation R is decomposed into fragments R1,R2, ..., Rn, it should be possible to define a relational operator such that:R = Ri, RiFRThe reconstructability of the relation from its fragments ensures that constraints defined on the data in the form of dependencies are preserved.

*DISTRIBUTION DESIGN ISSUESCORRECTNESS RULES OF FRAGMENTATIONDisjointnessIf a relation R is horizontally decomposed into fragments R1,R2, ..., Rn and data item di is in Rj, it is not in any other fragment Rk (k j). This criterion ensures that the horizontal fragments are disjoint. If relation R is vertically decomposed, its primary key attributes are typically repeated in all its fragments. Therefore, in case of vertical partitioning, disjointness is defined only on the nonprimary key attributes of a relation.

*DISTRIBUTION DESIGN ISSUESALLOCATION ALTERNATIVESThe reasons for replication are reliability and efficiency of read-only queries.

Read-only queries that access the same data items can be executed in parallel since copies exist on multiple sites.

The execution of update queries cause trouble since the system has to ensure that all the copies of the data are updated properly.

The decisions regarding replication is a trade-off which depends on the ratio of the read-only queries to the update queries.

*DISTRIBUTION DESIGN ISSUESALLOCATION ALTERNATIVESA nonreplicated database (commonly called a partitioned database) contains fragments that are allocated to sites, and there is only one copy of any fragment on the network.

In case of replication, either the database exists in its entirety at each site (fully replicated database), or fragments are distributed to the sites in such a way that copies of a fragment may reside in multiple sites (partially replicated database).

*DISTRIBUTION DESIGN ISSUESALLOCATION ALTERNATIVES

*DISTRIBUTION DESIGN ISSUESINFORMATION REQUIREMENTSThe information needed for distribution design can be divided into four categories:database information,application information,communication network information,computer system information.

*DISTRIBUTION DESIGN ISSUES FRAGMENTATIONHorizontal fragmentation partitions a relation along its tuples

Two versions of horizontal fragmentation

Primary horizontal fragmentation of relation is performed using predicates that are defined on that relation

Derived fragmentation is the partitioning of relation that results from predicates being defined on another relation

*DISTRIBUTION DESIGN ISSUES FRAGMENTATIONVertical fragmentation partitions a relation into a set of smaller relations so that many of users aplications will run on only one fragment

Vertical fragmentation is inherently more complicated than horizontal partitioning

*DISTRIBUTION DESIGN ISSUESALLOCATIONAllocation problemthere are set of fragments F= { F1, F2, ... , Fn } and network consisiting of sites S = { S1, S2, ... , Sm } on wich sets aplications Q= { q1, q2, ... , qq } is running

The allocation problem involves finding the optimal distribution of F to S

*DISTRIBUTION DESIGN ISSUESALLOCATIONOne of important issues that need to be discussed is the definition of optimalityThe optimality can be defined with respects of two measures [ Dowdy and Foster, 1982 ] Minimal cost. The cost consists of the cost of storing each Fi at the site Sj, the cost of quering Fi at Sj, the cost of updating Fi, at all sites it is stored, and cost of data comunication. The allocation problem,then, attempts to find an alocations scheme that minimizes cost function.

*DISTRIBUTION DESIGN ISSUESALLOCATION Perfomance. The allocation strategy is designed to maintain a performance mertic. Two well-known are to minimize the response time and to maximize the system throughput at each site