Home >Documents >Pertemuan 12 Arsitektur DBMS Terdistribusi

Pertemuan 12 Arsitektur DBMS Terdistribusi

Date post:17-Oct-2015
Category:
View:79 times
Download:21 times
Share this document with a friend
Description:
dbms
Transcript:
  • 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

Embed Size (px)
Recommended