CHAPTER 3

Arsitektur Database danWeb

Tujuan Dalam bab ini Anda akan belajar :

• Makna client-server arsitektur dan keuntungan dari jenis arsitektur untuk DBMS.

•Perbedaan antara dua tingkat,tiga-tier dan n-tier client-server arsitektur

•Fungsi server aplikasi.

•Makna middleware dan berbagai jenis middleware yang ada.

•Fungsi dan kegunaan dari Transaction Processing(TP) Monitor.

•Tujuan dari layanan Web dan teknologi standar yang digunakan untukmengembangkan
Layanan Web.

•Makna berorientasi layanan arsitektur(SOA).

•Perbedaan antara terdistribusi,DBMS dan didistribusikan pengolahan.

•Arsitektur data warehouse.

•Tentang komputasi awan dan database awan

•Perangkat lunak DBMS.

•Tentang logis dan fisik strukturOracle.

Dalam Bab 1, kami menyediakan ringkasan dari sejarah perkembangan sistem database dari tahun 1960 dan
seterusnya. Selama periode ini, meskipun pemahaman yang lebih baik dari fungsi yang pengguna diperlukan
diperoleh dan model data yang mendasari baru diusulkan dan dilaksanakan, paradigma perangkat lunak yang
digunakan untuk mengembangkan sistem perangkat lunak yang lebih umum telah mengalami perubahan yang
signifikan. Vendor sistem database harus mengakui perubahan ini dan beradaptasi dengan mereka untuk memastikan
bahwa sistem mereka saat ini dengan pemikiran terbaru. Dalam bab ini, kita meneliti arsitektur yang berbeda yang
telah digunakan dan memeriksa perkembangan yang muncul dalam layanan Web dan layanan berorientasi arsitektur
(SOA).
106 | Arsitektur database dan Web

Struktur dari bab ini Pada Bagian 3.1 kita memeriksa multi-user arsitektur DBMS berfokus pada dua-tier arsitektur
client-server dan arsitektur threetier client-server. Kami juga meneliti konsep middleware dan membahas berbagai
jenis middleware yang ada di bidang database. Dalam Bagian 3.2 kita meneliti layanan Web yang dapat digunakan
untuk menyediakan jenis baru dari layanan bisnis untuk pengguna, dan SOA yang mempromosikan desain longgar
ditambah dan jasa otonom yang dapat dikombinasikan untuk menyediakan proses bisnis komposit lebih fleksibel
dan aplikasi. Dalam Bagian 3.3 kita jelaskan secara singkat arsitektur untuk DBMS terdistribusi yang kita bahas
secara rinci dalam Bab 24 dan 25, dan membedakannya dari pemrosesan terdistribusi. Dalam Bagian 3.4 kita
jelaskan secara singkat arsitektur untuk sebuah gudang data dan alat terkait yang kita bahas secara rinci dalam Bab
31-34. Dalam Bagian 3.5 kita membahas komputasi awan dan database awan. Dalam Bagian 3.6 kita meneliti
arsitektur internal yang abstrak untuk DBMS dan dalam Bagian 3.7 kita meneliti arsitektur logis dan fisik dari
Oracle DBMS.

3.1 Multi-user DBMS Arsitektur

Pada bagian ini kita melihat arsitektur umum yang digunakan untuk mengimplementasikan sistem manajemen
database multi-user: teleprocessing, berkas-server, dan client-server.

3.1.1 Teleprocessing

Arsitektur tradisional untuk sistem multi-user adalah teleprocessing, dimana ada satu komputer dengan satu unit
central processing (CPU) dan sejumlah terminal, seperti digambarkan pada Gambar 3.1. Semua proses dilakukan
dalam batas-batas dari komputer fisik yang sama. Terminal pengguna biasanya "bodoh" yang, tidak mampu
berfungsi pada mereka sendiri, dan kabel ke komputer pusat. Terminal mengirim pesan melalui subsistem kontrol
komunikasi dari sistem operasi untuk program aplikasi pengguna, yang pada gilirannya menggunakan jasa

Gambar 3.1Teleprocessing topologi

3.1 Multi-user DBMS Architectures | 107

DBMS. Dengan cara yang sama, pesan yang diarahkan kembali ke terminal pengguna. Sayangnya, arsitektur ini
menempatkan beban luar biasa pada komputer pusat, yang harus tidak hanya menjalankan program aplikasi dan
DBMS, tetapi juga melaksanakan sejumlah besar pekerjaan atas nama terminal (seperti data format untuk
ditampilkan di layar ). Dalam beberapa tahun terakhir, telah ada kemajuan yang signifikan dalam pengembangan
komputer pribadi kinerja tinggi dan jaringan. Sekarang ada tren diidentifikasi dalam industri menuju perampingan,
yaitu, menggantikan komputer mainframe mahal dengan jaringan lebih hemat biaya dari komputer pribadi yang
mencapai hal yang sama, atau bahkan lebih baik, hasil. Tren ini telah melahirkan dua arsitektur berikutnya: File-
server dan client-server.

3.1.2 File-Server Architecture

Sebuah komputer terpasang ke jaringan dengan tujuan utama memberikan penyimpanan bersama file komputer
seperti dokumen, spreadsheet, gambar, dan database.
File Server
Dalam lingkungan server-file, pengolahan didistribusikan tentang jaringan, biasanya jaringan area lokal (LAN).
File-server memegang file yang dibutuhkan oleh aplikasi dan DBMS. Namun, aplikasi dan DBMS dijalankan pada
masing-masing workstation, meminta file dari file-server bila diperlukan, seperti digambarkan pada Gambar 3.2.
Dengan cara ini, file-server hanya bertindak sebagai hard disk drive bersama. DBMS pada masing-masing
workstation mengirimkan permintaan ke file-server untuk semua data yang DBMS mengharuskan disimpan pada
disk. Pendekatan ini dapat menghasilkan sejumlah besar lalu lintas jaringan, yang dapat menyebabkan masalah
kinerja. Misalnya, pertimbangkan permintaan pengguna yang membutuhkan nama-nama staf yang bekerja di cabang
di 163 Main St. Kami dapat mengungkapkan permintaan ini di SQL (lihat Bab 6) sebagai:
SELECT fname, iname
DARI Cabang b, Staf s
DIMANA b. branchNo = s.branchNo DAN b.street = '163 Main St';

Gambar 3.2File-Server. Arsitektur

108 | Database Architectures and the Web

Sebagai file-server tidak memiliki pengetahuan tentang SQL, DBMS harus meminta file sesuai dengan cabang dan
hubungan staf dari file-server, bukan hanya nama-nama staf yang memenuhi permintaan. Arsitektur server-file,
karena itu, memiliki tiga kelemahan utama:
(1) Ada sejumlah besar lalu lintas jaringan.
(2) Sebuah salinan lengkap dari DBMS diperlukan pada setiap workstation.
(3) Concurrency, pemulihan, dan kontrol integritas yang lebih kompleks, karena akan ada beberapa DBMSs
mengakses file yang sama.

3.1.3 Dua-Tier Arsitektur Client-Server Tradisional

Untuk mengatasi kerugian dari dua pendekatan pertama dan mengakomodasi lingkungan bisnis yang semakin
terdesentralisasi, arsitektur client-server dikembangkan. Client-server mengacu pada cara di mana komponen
software berinteraksi untuk membentuk suatu sistem. Seperti namanya, ada proses klien, yang membutuhkan
beberapa sumber daya, dan server, yang menyediakan sumber daya. Tidak ada persyaratan bahwa klien dan server
harus berada pada mesin yang sama. Dalam prakteknya, sangat umum untuk menempatkan server di salah satu situs
di LAN dan klien di situs lain. Gambar 3.3 menggambarkan arsitektur client-server dan Gambar 3.4 menunjukkan
beberapa kemungkinan kombinasi dari topologi client-server. Aplikasi bisnis data-intensif terdiri dari empat
komponen utama: database, logika transaksi, bisnis dan data aplikasi logika, dan user interface. Tradisional dua
tingkat arsitektur client-server menyediakan pemisahan yang sangat dasar komponen ini. Klien (lapis 1) terutama
bertanggung jawab untuk penyajian data ke pengguna, dan server (tier 2) terutama bertanggung jawab untuk
memasok layanan data ke klien, seperti yang diilustrasikan pada Gambar 3.5. Layanan presentasi menangani
antarmuka tindakan pengguna dan aplikasi bisnis dan data yang logika utama. Layanan data memberikan terbatas
logika aplikasi bisnis, biasanya validasi

Gambar 3.3 Klien-server arsitektur.

3.1 Multi-user DBMS Architectures | 109

Gambar 3.4 Alternatif client-server : topologi

(a)tunggal, klien tunggal ; server

(b)beberapa klien, tunggal ; server
(c)beberapa klien, beberapa server.

Gambar 3.5 tradisional client-server arsitekturdua-tier.

110 |Database Architectures and the Web

bahwa klien tidak dapat melaksanakan karena kurangnya informasi, dan akses ke data yang diminta, independen dari
lokasi. Data dapat berasal dari DBMS relasional, DBMSs objek-relasional, DBMSs berorientasi objek, DBMSs
warisan, atau sistem akses data proprietary. Biasanya, klien akan berjalan pada desktop pengguna akhir dan
berinteraksi dengan database server terpusat melalui jaringan. Sebuah interaksi yang khas antara klien dan server
adalah sebagai berikut. Klien mengambil permintaan pengguna, memeriksa sintaks, dan menghasilkan permintaan
database SQL atau bahasa database lain sesuai dengan logika aplikasi. Ini kemudian mengirimkan pesan ke server,
menunggu respons, dan format respon untuk end-user. Server menerima dan memproses permintaan basis data,
kemudian mengirimkan kembali hasilnya ke klien. Pengolahan melibatkan memeriksa otorisasi, memastikan
integritas, menjaga sistem katalog, dan melakukan query dan pembaruan pengolahan. Selain itu, juga menyediakan
concurrency dan recovery control. Operasi klien dan server dirangkum dalam Tabel 3.1.
Ada banyak keuntungan untuk jenis arsitektur. Misalnya:
• Hal ini memungkinkan akses yang lebih luas ke database yang ada.

• Peningkatan kinerja: Jika klien dan server berada pada komputer yang berbeda, maka CPU yang berbeda dapat
memproses aplikasi secara paralel. Hal ini juga harus mudah untuk menyesuaikan mesin server jika tugasnya hanya
untuk melakukan pengolahan database.

• Biaya Hardware dapat dikurangi: Hanya server yang membutuhkan penyimpanan dan pengolahan daya yang
cukup untuk menyimpan dan mengelola database.

• Biaya Komunikasi dikurangi: Aplikasi melaksanakan bagian dari operasi pada klien dan mengirim hanya
permintaan untuk akses database di seluruh jaringan, sehingga data yang kurang sedang dikirim melalui jaringan.

• Peningkatan konsistensi: Server dapat menangani pemeriksaan integritas, sehingga kendala perlu didefinisikan dan
divalidasi hanya di satu tempat, daripada harus setiap program aplikasi melakukan pemeriksaan sendiri.

• Ini peta untuk membuka sistem arsitektur cukup alami.

Beberapa vendor database telah menggunakan arsitektur ini untuk menunjukkan kemampuan database
terdistribusi, yaitu, koleksi beberapa, database logis saling terkait d istributed melalui jaringan komputer. Namun,
meskipun arsitektur client-server dapat digunakan untuk menyediakan DBMS terdistribusi, dengan sendirinya
tidak merupakan DBMS terdistribusi. Kami membahas didistribusikan DBMS sebentar di Bagian 3.3 dan lebih
lengkap dalam Bab 24 dan 25.

Tabel 3.1 Ringkasan Fungsi client-server.

Client Server
- Mengatur user interface - Menerima dan memproses basis data
- Menerima dan memeriksa sintaks permintaan dari klien
pengguna - Cek input otorisasi
- Proses aplikasi logika - Memastikan integritas kendala tidak
- Menghasilkan database permintaan dan dilanggar
mengirimkan ke server - Melakukan permintaan /update pengolahan
- Passes respon kembali untuk pengguna dan mengirimkan respon ke klien
- Menjaga sistem katalog
- Menyediakan bersamaan database akses
- Menyediakan recovery kontrol
3.1 Multi-user DBMS Architectures | 111

3.1.4 Tiga-Tier client-Server Arsitektur

kebutuhan perusahaan skalabilitas menantang model client-server dua-tier tradisional. Pada pertengahan 1990-an,
aplikasi menjadi lebih kompleks dan berpotensi dapat digunakan untuk ratusan atau ribuan pengguna akhir, sisi
klien disajikan dua masalah yang mencegah skalabilitas benar:

• Seorang klien "gemuk", membutuhkan sumber daya yang cukup pada komputer klien untuk berjalan efektif. Ini
termasuk ruang disk, RAM, dan power CPU.
• Sebuah biaya overhead administrasi client-side signifikan.

Pada tahun 1995, variasi baru dari model client-server dua-tier tradisional muncul untuk memecahkan masalah
perusahaan skalabilitas.Arsitektur baru ini diusulkan tiga lapisan, masing-masing berpotensi berjalan pada platform
yang berbeda:

(1) Pengguna lapisan antarmuka, yang berjalan pada komputer pengguna akhir (klien).
(2) Logika bisnis dan lapisan pengolahan data. Tingkat menengah ini berjalan pada server dan sering disebut server
aplikasi.
(3) A DBMS, yang menyimpan data yang dibutuhkan oleh tingkat menengah. Lapis ini dapat dijalankan pada server
terpisah yang disebut database server.

Seperti diilustrasikan dalam Gambar 3.6, klien sekarang bertanggung jawab untuk hanya antarmuka pengguna
aplikasi dan mungkin melakukan beberapa pengolahan logika sederhana, seperti validasi input, sehingga
memberikan "tipis" klien. Logika bisnis inti dari aplikasi sekarang tinggal di lapisan sendiri, secara fisik terhubung
ke client dan server database melalui LAN atau wide area network (WAN). Salah satu aplikasi server dirancang
untuk melayani beberapa klien.

Gambar 3.6 Tiga-tier arsitektur.

112 | 3 Database Architectures and the Web

Desain three-tier memiliki banyak keuntungan lebih dari dua-tier atau single-tier desain tradisional, yang meliputi:

• ". Thin"Kebutuhan hardware lebih murah karena klien adalah

• pemeliharaan Aplikasi ini terpusat dengan transfer logika bisnis bagi banyak pengguna akhir ke server aplikasi
tunggal. Ini menghilangkan kekhawatiran distribusi software yang bermasalah dalam model client-server dua-tier
tradisional.

• modularitas menambahkan membuatnya lebih mudah untuk memodifikasi atau mengganti satu lapis
tanpa mempengaruhi tingkatan lainnya.

• Load balancing lebih mudah dengan pemisahan logika bisnis inti dari fungsi database. Keuntungan tambahan
adalah bahwa arsitektur three-tier peta secara alamiah dengan lingkungan Web, dengan browser Web yang bertindak
sebagai klien "tipis", dan server Web bertindak sebagai server aplikasi.

3.1.5 N-tier Arsitektur

Tiga-tier arsitektur dapat diperluas untuk n tingkatan, dengan tingkatan tambahan menyediakan lebih banyak
fleksibilitas dan skalabilitas. Misalnya, seperti yang diilustrasikan pada Gambar 3.7, tingkat tengah arsitektur dapat
dibagi menjadi dua, dengan satu tingkat untuk Web
Tier 1 Client
Tier 2 server Web
Tier 3 Aplikasi server
Tier 4 database server yang

Gambar 3.7 Empat-tier Arsitektur dengan menengah tingkat dibagi menjadi Web server dan
aplikasi.server
3.1 Multi-user DBMS Architectures | 113

server dan tingkat lain untuk server aplikasi. Dalam lingkungan dengan volume tinggi, server Web tunggal dapat
digantikan oleh seperangkat server Web (atau Web peternakan) untuk mencapai load balancing yang efisien.

Aplikasi server

Host sebuah antarmuka pemrograman aplikasi (API) untuk mengekspos logika bisnis dan proses bisnis untuk
digunakan oleh aplikasi lain.

Aplikasi server

Sebuah server aplikasi harus menangani sejumlah masalah yang kompleks :

• concurrency
• manajemen koneksi jaringan
• menyediakan akses ke semua server database
• koneksi database penyatuan
• dukungan database warisan
• dukungan pengelompokan
• load balancing
• failover.

Dalam Bab 29 kita akan memeriksa sejumlah server aplikasi:

• Java Platform, Enterprise Edition (JEE), sebelumnya dikenal sebagai J2EE, adalah spesifikasi untuk sebuah
platform untuk pemrograman server dalam bahasa pemrograman Java. Seperti dengan spesifikasi Java Community
Process lainnya, JEE juga dianggap informal menjadi standar, sebagai penyedia harus menyetujui persyaratan
kesesuaian tertentu untuk menyatakan produk mereka untuk menjadi "JEE-compliant." Sebuah aplikasi server JEE
dapat menangani transaksi, keamanan , skalabilitas, concurrency, dan pengelolaan komponen yang dikerahkan
untuk itu, yang berarti bahwa pengembang harus dapat lebih berkonsentrasi pada logika bisnis komponen bukan
pada tugas infrastruktur dan integrasi. Beberapa terkenal JEE server aplikasi WebLogic Server dan Oracle ikan
mas Server dari Oracle Corporation, JBoss dari Red Hat, WebSphere Application Server dari IBM, dan open
source GlassFish Application Server. Kami membahas platform JEE dan teknologi yang terkait dengan mengakses
database dalam Bagian 29.7.
• .NET Framework adalah korban Microsoft untuk mendukung pengembangan tingkat menengah. Kami membahas
Microsoft .NET dalam Bagian 29.8.
• Oracle Application Server menyediakan satu set layanan untuk perakitan infrastruktur multitier scalable untuk
mendukung e-Bisnis. Kami membahas Oracle Application Server dalam Bagian 29,9.

3.1.6 Middleware

softwareKomputer yang menghubungkan komponen perangkat lunak atau applications.Middleware

Middleware adalah istilah umum yang digunakan untuk menjelaskan perangkat lunak yang menengahi dengan
perangkat lunak lain dan memungkinkan untuk komunikasi antara aplikasi yang berbeda dalam
114 | Chapter 3 Database Architectures and the Web

Sistem heterogen. Kebutuhan middleware muncul ketika sistem terdistribusi menjadi terlalu rumit untuk mengelola
secara efisien tanpa antarmuka umum. Kebutuhan untuk membuat sistem heterogen bekerja secara efisien di dalam
jaringan dan cukup fleksibel untuk menggabungkan modifikasi yang sering menyebabkan perkembangan dari
middleware, yang menyembunyikan kompleksitas yang mendasari sistem terdistribusi. Hurwitz (1998)
mendefinisikan enam jenis utama middleware:

• Asynchronous Remote Procedure Call (RPC): Sebuah teknologi komunikasi interprocess yang
memungkinkan klien untuk meminta layanan di ruang alamat lain (biasanya di komputer lain di dalam jaringan)
tanpa menunggu jawaban . RPC dimulai oleh klien mengirimkan pesan permintaan ke server jauh yang dikenal
dalam rangka melaksanakan prosedur yang ditentukan dengan menggunakan parameter yang disediakan. Jenis
middleware cenderung sangat scalable, sebagai sangat sedikit informasi tentang koneksi dan sesi dipelihara oleh
klien atau server. Di sisi lain, jika koneksi rusak, klien harus memulai lagi dari awal, sehingga protokol memiliki
pemulihan yang rendah. RPC asynchronous yang paling tepat ketika integritas transaksi tidak diperlukan.

• Synchronous RPC: Serupa dengan RPC asynchronous, namun, sementara server sedang memproses
panggilan, klien diblokir (itu harus menunggu sampai server telah selesai diproses sebelum melanjutkan eksekusi).
Jenis middleware adalah yang paling scalable tetapi memiliki pemulihan terbaik.
Ada sejumlah protokol analog dengan RPC, seperti:
- Jawa Remote Method Invocation (Java RMI) API menyediakan fungsionalitas mirip dengan standar metode
UNIX RPC
- XML-RPC adalah sebuah protokol RPC yang menggunakan XML untuk mengkodekan panggilan dan HTTP
sebagai mekanisme transportasi. Kami akan membahas HTTP dalam Bab 29 dan XML pada Bab 30.
-Microsoft .NET Remoting menawarkan fasilitas RPC untuk sistem terdistribusi yang diimplementasikan pada
platform Windows. Kami akan membahas NET platform dalam Bagian 29.8.
-CORBA memberikan doa prosedur remote melalui lapisan menengah disebut Kami akan membahas CORBA
dalam Bagian 28.1 "Object Request Broker.".
- Protokol Thrift dan kerangka kerja untuk jaringan sosial situs Web Facebook.

• Publish / berlangganan: Sebuah protokol pesan asynchronous mana pelanggan berlangganan pesan yang
dihasilkan oleh penerbit. Pesan dapat dikategorikan ke dalam kelas dan pelanggan mengungkapkan minat
dalam satu atau lebih kelas, dan hanya menerima pesan yang menarik, tanpa pengetahuan tentang apa (jika
ada) penerbit ada. Decoupling ini penerbit dan pelanggan memungkinkan untuk skalabilitas yang lebih besar
dan topologi jaringan yang lebih dinamis. Contoh mempublikasikan / berlangganan middleware termasuk
TIBCO Rendezvous dari TIBCO Software Inc dan Es (Internet Komunikasi Engine) dari ZeroC Inc.

• middleware Pesan berorientasi (MOM): Software yang berada di kedua klien dan server dan biasanya
mendukung panggilan asynchronous antara klien dan server aplikasi. Pesan antrian menyediakan penyimpanan
sementara ketika aplikasi tujuan sibuk atau tidak terhubung. Ada banyak produk MOM di pasar, termasuk
WebSphere MQ dari IBM, MSMQ (Microsoft Message Queuing), JMS (Java Messaging Service), yang
merupakan bagian dari JEE dan pengembangan
memungkinkan portabel, aplikasi berbasis pesan di Jawa, Sun Java sistem Message Queue (SJSMQ), yang
mengimplementasikan JMS, dan MessageQ dari Oracle Corporation.
3.1 Multi-user DBMS Architectures | 115

• Object-request broker (ORB): Mengatur komunikasi dan pertukaran data antara objek. ORB mempromosikan
interoperabilitas sistem objek terdistribusi dengan memungkinkan pengembang untuk membangun sistem dengan
mengintegrasikan bersama benda-benda, mungkin dari vendor yang berbeda, yang berkomunikasi satu sama lain
melalui ORB. The Common Object Peminta Broker Architecture (CORBA) adalah standar yang ditetapkan oleh
Management Group Object (OMG) yang memungkinkan komponen perangkat lunak yang ditulis dalam berbagai
bahasa komputer dan berjalan pada beberapa komputer untuk bekerja sama. Contoh produk ORB middleware
komersial Orbix dari Progress Software.
• akses data SQL berorientasi: Menghubungkan aplikasi dengan database di seluruh jaringan dan diterjemahkan
permintaan SQL ke dalam database SQL asli atau bahasa database lainnya. Middleware SQL berorientasi
menghilangkan kebutuhan untuk kode panggilan SQL-spesifik untuk setiap database dan kode komunikasi yang
mendasari. Lebih umum, basis data berorientasi middleware menghubungkan aplikasi untuk setiap jenis database
(tidak selalu DBMS relasional melalui SQL). Contohnya termasuk ODBC (Open Database Connectivity) API
Microsoft, yang mengekspos antarmuka tunggal untuk memfasilitasi akses ke database dan kemudian
menggunakan driver untuk mengakomodasi perbedaan antara database, dan API JDBC, yang menggunakan satu
set metode Java untuk memudahkan akses ke beberapa database. Di kategori ini kami juga akan mencakup
gateway, yang bertindak sebagai mediator dalam DBMS terdistribusi untuk menerjemahkan satu bahasa database
atau dialek bahasa ke bahasa lain atau dialek (misalnya, Oracle SQL ke DB2 SQL IBM atau Microsoft SQL Server
SQL ke Object Query bahasa, atau OQL). Kami akan membahas gateway dalam Bab 24 dan ODBC dan JDBC
dalam Bab 29.

Pada bagian berikutnya, kita meneliti satu jenis tertentu middleware untuk proses transaksi.

3.1.7 Transaction Processing Monitor

Sebuah program yang mengontrol transfer data antara klien dan s ervers untuk menyediakan lingkungan yang
konsisten, terutama untuk proses transaksi online (OLTP).
TP Monitor

aplikasi Complex sering dibangun di atas beberapa manajer sumber daya (seperti DBMS, sistem operasi, antarmuka
pengguna, dan software messaging). Sebuah Transaction Processing Monitor, atau TP Monitor, merupakan
komponen middleware yang menyediakan akses ke layanan dari sejumlah manajer sumber daya dan menyediakan
antarmuka yang seragam untuk programmer yang mengembangkan software transaksional. Sebuah Monitor TP
membentuk tingkat menengah dari arsitektur tiga-tier, seperti digambarkan pada Gambar 3.8. Monitor TP
memberikan keuntungan yang signifikan, termasuk:
• Transaction routing : The TP Monitor dapat meningkatkan skalabilitas dengan mengarahkan transaksi ke DBMS
tertentu.
• Mengelola transaksi terdistribusi: The TP Monitor dapat mengelola transaksi yang membutuhkan akses ke data
dalam beberapa, mungkin heterogen, DBMSs. Misalnya, transaksi mungkin perlu memperbarui data barang yang
diadakan dalam Oracle DBMS di situs 1, sebuah Informix DBMS di situs 2, dan IMS DBMS sebagai situs 3. TP
Monitor biasanya
116 | Chapter 3 Database Architectures and the Web

Gambar 3.8 Transaksi Pengolahan Monitor sebagai client-server tingkat menengah dari arsitekturtiga-tier.

Transaksi control menggunakan X / Open Distributed Transaction Processing standar (DTP). Sebuah DBMS yang
mendukung standar ini dapat berfungsi sebagai manajer sumber daya di bawah kendali Monitor TP bertindak
sebagai manajer transaksi. Kami membahas didistribusikan transaksi dan standar DTP dalam Bab 24 dan 25.

• Load balancing: The TP Monitor dapat menyeimbangkan permintaan klien di beberapa DBMS pada satu atau
lebih komputer dengan mengarahkan panggilan layanan klien ke server paling tidak dimuat. Selain itu, secara
dinamis dapat membawa DBMS tambahan yang diperlukan untuk memberikan kinerja yang diperlukan.
• Funneling : Dalam lingkungan dengan sejumlah besar pengguna, mungkin kadang-kadang sulit bagi semua
pengguna untuk login secara bersamaan ke DBMS. Dalam banyak kasus, kita akan menemukan bahwa pengguna
umumnya tidak memerlukan akses berkelanjutan ke DBMS. Daripada setiap pengguna menghubungkan ke
DBMS, TP Monitor dapat membangun koneksi dengan DBMS jika diperlukan, dan dapat menyalurkan
permintaan pengguna melalui koneksi ini. Hal ini memungkinkan sejumlah besar pengguna untuk mengakses
DBMS tersedia dengan sejumlah berpotensi jauh lebih kecil dari koneksi, yang pada gilirannya akan berarti
penggunaan sumber daya kurang.
• increased reliability : The TP monitor bertindak sebagai manajer transaksi, lakukan tindakan yang diperlukan
untuk menjaga konsistensi database, dengan DBMS bertindak sebagai manajer sumber daya. Jika DBMS gagal,
TP Monitor mungkin dapat mengirim ulang transaksi ke DBMS lain atau dapat terus transaksi sampai DBMS
menjadi tersedia lagi.

TP Monitor biasanya digunakan dalam lingkungan dengan volume yang sangat tinggi dari transaksi, dimana TP
Monitor dapat digunakan untuk offload proses dari server DBMS. Contoh menonjol dari Monitor TP termasuk
CICS (yang digunakan terutama pada mainframe IBM bawah z / OS dan z / VSE) dan Tuxedo dari Oracle
Corporation. Selain itu, API Java Transaction (JTA), salah satu Java Enterprise Edition (JEE) API,
memungkinkan didistribusikan transaksi yang akan dilakukan di beberapa X / sumber Terbuka XA di
lingkungan Jawa. Implementasi open-source dari JTA termasuk JBossTS, sebelumnya dikenal sebagai Arjuna
Layanan Transaksi, dari Red Hat dan Bitronix Transaksi Manager dari Bitronix.
3.2 Web Services and Service-Oriented Architectures | 117

3.2.1 Web Services

Sebuah sistem software yang dirancang untuk mendukung interaksi mesin-tomachine interoperable lebih layanan
network.

Meski telah hanya sekitar 20 tahun sejak konsepsi Internet, dalam hal ini relatif singkat periode waktu yang telah
sangat berubah banyak aspek masyarakat, termasuk bisnis, pemerintah, penyiaran, belanja, rekreasi, komunikasi,
pendidikan, dan pelatihan. Meskipun Internet telah memungkinkan perusahaan untuk menyediakan berbagai layanan
kepada pengguna, kadang-kadang disebut B2C (Business to Consumer), layanan Web memungkinkan aplikasi untuk
mengintegrasikan dengan aplikasi lain di Internet dan dapat menjadi teknologi kunci yang mendukung B2B
(Business to Business ) interaksi.

Tidak seperti aplikasi berbasis web lainnya, layanan Web tidak memiliki antarmuka pengguna dan tidak
ditujukan untuk browser Web. Layanan web bukannya berbagi logika bisnis, data, dan proses melalui antarmuka
program di dalam jaringan. Dengan cara ini, itu adalah aplikasi yang antarmuka dan bukan pengguna. Pengembang
kemudian dapat menambahkan layanan Web ke halaman Web (atau program dieksekusi) untuk menawarkan fungsi
khusus untuk pengguna. Contoh layanan Web meliputi :
• Maps Bing Microsoft dan Google Maps layanan Web menyediakan akses ke layanan locationbased, seperti peta,
arah mengemudi, pencarian kedekatan, dan geocoding (yaitu, mengubah alamat ke koordinat geografis) dan
reverse geocoding.
• Amazon Simple Storage Service (Amazon S3) adalah antarmuka layanan Web sederhana yang dapat digunakan
untuk menyimpan dan mengambil sejumlah besar data, setiap saat, dari mana saja di Web. Ini memberikan setiap
akses pengembang untuk yang sangat scalable, handal, cepat, infrastruktur penyimpanan data yang murah yang
sama yang menggunakan Amazon untuk menjalankan jaringan global sendiri situs Web. Tuduhan didasarkan pada
kebijakan "pay-as-you-go", saat ini $ 0,125 per GB untuk pertama 50TB / bulan penyimpanan yang digunakan.
• GeoNames menyediakan sejumlah layanan Web terkait lokasi; misalnya, untuk kembali satu set entri Wikipedia
sebagai dokumen XML untuk nama tempat tertentu atau untuk mengembalikan zona waktu untuk diberikan
lintang / bujur.
• layanan DOTS Web dari Layanan Objects Inc, adopter awal layanan Web, menyediakan berbagai layanan seperti
informasi perusahaan, reverse lookup nomor telepon, validasi alamat email, informasi cuaca, IP address-to-
penentuan lokasi.
• Xignite adalah layanan Web B2B yang memungkinkan perusahaan untuk menggabungkan informasi keuangan ke
dalam aplikasi mereka. Layanan mencakup US informasi ekuitas, real-time quotes sekuritas, harga ekuitas AS, dan
berita keuangan.

Kunci pendekatan layanan Web adalah penggunaan teknologi diterima secara luas dan standar, seperti:

• XML (extensible Markup Language).

• SOAP (Simple Object Access Protocol) adalah protokol komunikasi untuk bertukar informasi terstruktur melalui
Internet dan menggunakan format pesan berbasis XML. Hal ini baik platform-dan bahasa-independen.
118 | Chapter 3 Database Architectures and the Web

Gambar 3.9 Hubungan ANTARA WSDL,UDDI,Dan SOAP.

• WSDL (Web Services Description Language) Protokol, Lagi berdasarkan XML, digunakan untuk menggambarkan
Dan menemukan layanan Web.
• UDDI (Universal Discovery, Deskripsi, Dan Integrasi) Protokol Adalah platformindependent, Berbasis XML
registry Bisnis PT Diri di Internet. Penyanyi dirancang diinterogasi Oleh Pesan SOAP Dan untuk memberikan
Akses Ke Dokumen WSDL menggambarkan mengikat protokol Format Dan Pesan Yang diperlukan interact
dengan layanan Web Yang tercantum direktorinya.

Gambar 3.9 menggambarkan Hubungan Antara Teknologi tersebut. Dari Perspektif Database, Layanan Web can be
digunakan Baik Dari hearts basis data (memanggil layanan web eksternal sebagai konsumen) dan layanan web itu
mengakses basis data Sendiri (sebagai penyedia program) untuk data yang dibutuhkan memberikan layanan diminta.

RESTfull Web services

Web API Adalah layanan web di mana penekanan bergerak jauh dar layanan berbasis SOAP Terhadap Negara
transfer (REST) communication. Sisa layanan tidak memerlukan XML, SOAP, WSDL, atau jelasnya UDDI. REST
adalah sebuah hd arsitektur yang menentukan kendala, seperti Antarmuka seragam, bahwa diterapkan layanan web
creates Sifat Yang diinginkan, seperti costs kos, skalabilitas, dan modifiability, yang memungkinkan layanan untuk
review bekerja terbaik di Web. Dalam hd Arsitektur REST, data dan fungsi dianggap sumber daya dan diakses
menggunakan Uniform Resource Identifier (URI), umumnya di Link Web. Sumber Daya yang ditindaklanjuti
dengn menggunakan Satu set sederhana, welldefined Operasi HTML dibuat untuk review, membaca, memperbarui,
Dan Menghapus: PUT, GET, POST, Dan DELETE. PUT creates Sumber Daya baru, Yang can be kemudian
dihapus DENGAN using DELETE. GET mengambil keadaan Saat Sumber Daya di beberapa representasi. POST
Transfer gatra baru Ke Sumber Daya. REST mengadopsi Arsitektur client-server Dan dirancang untuk review using
Protokol communication stateless, biasanya HTTP. Dalam hd Arsitektur REST, Server Klien Dan representasi
pertukaran Sumber Daya dengan menggunakan Antarmuka standar dan Protokol. Kami akan membahas layanan
web, HTML, Dan URI hearts Bagian 29.2.5 Dan SOAP, WSDL, UDDI hearts Bab 29 Dan 30.

3.2 Layanan Web dan Layanan Berorientasi Arsitektur | 119

3.2.2 Layanan Berorientasi Arsitektur (SOA)
SOA: Sebuah Arsitektur software-centric Bisnis untuk Membangun Aplikasi Yang Mengimplementasikan Proses
Bisnis sebagai mengatur Layanan Diterbitkan pada granularity Yang relevan dengan layanan konsumen . Layanan
dapat dipanggil, diterbitkan, dan menemukan, dan disarikan dari implementasi menggunakan bentuk berbasis
standar tunggal antarmuka.

Fleksibilitas diakui sebagai persyaratan utama untuk bisnis di saat IT menyediakan peluang bisnis yang tidak pernah
dibayangkan di masa lalu sementara pada saat yang sama teknologi yang mendasari yang cepat berubah. Usabilitas
sering dipandang sebagai tujuan utama dari pengembangan perangkat lunak dan mendasari paradigma berorientasi
objek: object-oriented programming (OOP) dapat dilihat sebagai koleksi benda-benda bekerja sama, sebagai lawan
dari pandangan tradisional di mana program dapat dilihat sebagai kelompok tugas untuk menghitung. Dalam OOP,
setiap objek dapat menerima pesan, memproses data, dan mengirim pesan ke objek lainnya. Dalam arsitektur TI
tradisional, kegiatan proses bisnis, aplikasi, dan data cenderung terkunci dalam independen, "silo," sering-
kompatibel di mana pengguna harus menavigasi jaringan yang terpisah, aplikasi, dan database untuk melakukan
rantai kegiatan yang menyelesaikan proses bisnis . Sayangnya, silo independen menyerap jumlah banyak sekali
anggaran TI dan waktu staf untuk mempertahankan. Arsitektur ini diilustrasikan pada Gambar 3.10 (a) di mana kami
memiliki tiga proses: Layanan Penjadwalan, Order Processing, dan Account Management, masing-masing
mengakses sejumlah database. Jelas ada yang umum "layanan" dalam kegiatan yang akan dilakukan oleh proses ini.
Jika kebutuhan bisnis mengubah atau peluang baru hadir sendiri, kurangnya independensi antara proses-proses ini
dapat menyebabkan kesulitan dalam beradaptasi dengan cepat proses ini. SOA Pendekatan berusaha untuk
mengatasi kesulitan ini dengan merancang longgar digabungkan dan otonom layanan yang dapat dikombinasikan
untuk menyediakan proses bisnis komposit fleksibel dan aplikasi. Gambar 3.10 (b) menggambarkan proses bisnis
yang sama rearchitected menggunakan pendekatan berorientasi layanan. Inti dari layanan, oleh karena itu, adalah
bahwa penyediaan layanan independen dari aplikasi yang menggunakan layanan ini. Penyedia layanan dapat
mengembangkan layanan khusus dan menawarkan ini untuk berbagai pengguna layanan dari organisasi yang
berbeda. Aplikasi dapat dibangun dengan menghubungkan layanan dari berbagai penyedia baik menggunakan
bahasa pemrograman standar atau layanan bahasa khusus orkestrasi seperti BPEL (Business Process Execution
Language). Apa yang membuat layanan Web yang dirancang untuk SOA berbeda dari layanan Web lain adalah
bahwa mereka biasanya mengikuti sejumlah konvensi yang berbeda. Berikut ini adalah serangkaian prinsip SOA
umum yang memberikan pendekatan desain yang unik untuk membangun layanan Web untuk SOA:
• Loose coupling:Jasa harus dirancang untuk berinteraksi secara longgar ditambah
• Reusability: Logika yang dapat berpotensi digunakan kembali dirancang sebagai layanan terpisah
• Contract: Jasa mematuhi kontrak komunikasi yang mendefinisikan pertukaran informasi dan informasi
deskripsi layanan tambahan, ditentukan oleh satu atau lebih layanan dokumen deskripsi
• Abstraction: Beyond apa yang dijelaskan dalam kontrak layanan, layanan menyembunyikan logika dari
dunia luar
120 | Chapter 3 Database Architectures and the Web

Gambar 3.10 (a)tradisional TI arsitektur selama tiga bisnis;proses

(b)berorientasi layanan arsitektur membagi yang proses ke sejumlah dapat digunakan layanan kembali.

• Composability:Layanan dapat menulis layanan lainnya, sehingga logika yang dapat diwakili pada tingkat yang
berbeda dari granularity sehingga meningkatkan usabilitas dan penciptaan lapisan abstraksi;
• Autonomy:Jasa memiliki kendali atas logika mereka merangkum dan tidak tergantung pada layanan lain untuk
melaksanakan pemerintahan ini;
• Stateless: Jasa seharusnya tidak diperlukan untuk mengelola informasi negara, karena hal ini dapat mempengaruhi
kemampuan mereka untuk tetap longgar digabungkan;
• Discoverability: Layanan dirancang untuk menjadi lahiriah deskriptif sehingga mereka dapat ditemukan dan
dinilai melalui mekanisme penemuan yang tersedia.

Perhatikan bahwa SOA tidak terbatas pada layanan Web dan dapat digunakan dengan teknologi lainnya.
Pembahasan lebih lanjut tentang SOA adalah di luar cakupan buku ini dan pembaca yang tertarik disebut pembacaan
tambahan yang tercantum pada akhir buku untuk bab ini.

3.3 Distributed DBMS Seperti dibahas dalam Bab 1, motivasi utama di balik pengembangan sistem database adalah
keinginan untuk mengintegrasikan data operasional dari suatu organisasi dan untuk menyediakan akses terkontrol
untuk data. Meskipun kita mungkin berpikir bahwa integrasi dan akses dikendalikan menyiratkan sentralisasi, ini
bukan niat. Bahkan, pengembangan jaringan komputer mempromosikan mode desentralisasi kerja.ini
3.3 Distributed DBMS | 121

pendekatan desentralisasi mencerminkan struktur organisasi banyak perusahaan, yang secara logis didistribusikan ke
divisi, departemen, proyek, dan sebagainya, dan secara fisik didistribusikan ke kantor-kantor, pabrik, atau pabrik-
pabrik, di mana setiap unit memelihara data operasional sendiri. Pengembangan DBMS terdistribusi yang
mencerminkan struktur organisasi ini, membuat data di semua unit diakses, dan data toko terdekat ke lokasi di mana
ia paling sering digunakan, harus meningkatkan kemampuan untuk berbagi data dan harus meningkatkan efisiensi
dengan yang kita dapat mengakses data.

Distributed
Sebuah koleksi logis saling terkait data bersama (dan deskripsi data ini), secara fisik didistribusikan melalui jaringan
komputer.

Didistribusikan DBMS
Databasesistem perangkat lunak yang memungkinkan pengelolaan database terdistribusi dan membuat distribusi
transparan kepada pengguna.

Sebuah sistem manajemen database terdistribusi (DDBMS) terdiri dari database logis tunggal yang dibagi menjadi
beberapa fragmen. Setiap fragmen disimpan pada satu atau lebih komputer (replika) di bawah kendali DBMS yang
terpisah, dengan komputer yang terhubung dengan jaringan komunikasi. Setiap situs yang mampu secara mandiri
memproses permintaan pengguna yang membutuhkan akses ke data lokal (yaitu, setiap situs memiliki beberapa
tingkat otonomi daerah) dan juga mampu mengolah data yang tersimpan di komputer lain dalam jaringan. Pengguna
mengakses database didistribusikan melalui aplikasi. Aplikasi diklasifikasikan sebagai orang-orang yang tidak
memerlukan data dari situs lain (aplikasi lokal) dan orang-orang yang memang membutuhkan data dari situs lain
(aplikasi global). Kami memerlukan DDBMS memiliki setidaknya satu aplikasi global. Oleh karena itu A DDBMS
memiliki karakteristik sebagai berikut:
• koleksi data bersama secara logis terkait
• Data dibagi menjadi beberapa fragmen
• fragmen dapat direplikasi
• fragmen / replika dialokasikan ke situs
• situs yang dihubungkan oleh jaringan komunikasi
• data pada setiap situs adalah di bawah kendali DBMS
• DBMS pada setiap situs dapat menangani aplikasi lokal, secara otonomi
• setiap DBMS berpartisipasi dalam sedikitnya satu aplikasi global.
Hal ini tidak perlu untuk setiap situs dalam sistem untuk memiliki database lokal sendiri, seperti yang digambarkan
oleh topologi dari DDBMS yang ditunjukkan pada Gambar 3.11. Dari definisi dari DDBMS, sistem ini diharapkan
untuk membuat distribusi transparan (tak terlihat) ke pengguna. Dengan demikian, fakta bahwa database
terdistribusi dibagi menjadi fragmen yang dapat disimpan pada komputer yang berbeda dan mungkin direplikasi
harus disembunyikan dari pengguna. Tujuan dari transparansi adalah membuat sistem terdistribusi muncul seperti
sistem terpusat. Hal ini kadang-kadang disebut sebagai prinsip dasar dari DBMS terdistribusi. Persyaratan ini
menyediakan fungsionalitas yang signifikan bagi pengguna akhir tetapi, sayangnya, menciptakan banyak masalah
tambahan yang harus ditangani oleh DDBMS.
122 | Chapter 3 Database Architectures and the Web

Gambar 3.11 terdistribusi manajemen sistemdatabase

Distributed processing
Hal ini penting untuk membuat perbedaan antara DBMS terdistribusi dan pemrosesan terdistribusi:

Sebuah database terpusat yang dapat diakses melalui komputer network.Distributed pengolahan

Titik kunci dengan definisi DBMS terdistribusi adalah bahwa sistem terdiri dari data yang didistribusikan secara
fisik di sejumlah situs dalam jaringan. Jika data yang terpusat, meskipun pengguna lain dapat mengakses data
melalui jaringan, kita tidak menganggap hal ini menjadi sebuah DBMS terdistribusi hanya didistribusikan
pengolahan. Kami menggambarkan topologi pengolahan terdistribusi pada Gambar 3.12. Bandingkan angka ini,
yang memiliki pusat data di situs 2, dengan Gambar 3.11, yang menunjukkan beberapa situs masing-masing dengan
database mereka sendiri. Kami akan membahas didistribusikan DBMS secara mendalam dalam Bab 24 dan 25.

Gambar 3.12terdistribusi. pengolahan

3.4 Data Warehousing | 123

Sejak tahun 1970, organisasi ini sebagian besar difokuskan investasi mereka dalam sistem komputer baru (disebut
pemrosesan transaksi online atau sistem OLTP) yang mengotomatisasi proses bisnis. Dengan cara ini, organisasi
memperoleh keunggulan kompetitif melalui sistem yang menawarkan layanan yang lebih efisien dan hemat biaya
kepada pelanggan. Sepanjang periode ini, organisasi akumulasi jumlah data yang disimpan dalam database
operasional mereka tumbuh. Namun, dalam beberapa kali, di mana sistem tersebut yang biasa, organisasi yang
berfokus pada cara untuk menggunakan data operasional untuk mendukung pengambilan keputusan sebagai sarana
mendapatkan kembali keunggulan kompetitif. Sistem operasional tidak pernah terutama dirancang untuk
mendukung pengambilan keputusan bisnis dan menggunakan sistem seperti mungkin tidak menjadi solusi yang
mudah. Warisan adalah bahwa organisasi yang khas mungkin memiliki banyak sistem operasional dengan definisi
tumpang tindih dan kadang-kadang bertentangan, seperti tipe data. Tantangan bagi suatu organisasi adalah untuk
mengubah arsipnya data menjadi sumber pengetahuan, sehingga satu terintegrasi / konsolidasi tampilan data
organisasi disajikan kepada pengguna. Konsep data warehouse dianggap solusi untuk memenuhi persyaratan sistem
yang mampu mendukung pengambilan keputusan, menerima data dari berbagai sumber data operasional.

Data warehouse : Sebuah konsolidasi / terpadu tampilan data perusahaan yang diambil dari sumber data operasional
yang berbeda dan berbagai akses alat pengguna akhir mampu mendukung sederhana untuk pertanyaan yang sangat
kompleks untuk mendukung pengambilan keputusan.

Data diadakan di sebuah gudang data digambarkan sebagai subjek berorientasi, terpadu, waktu-varian, dan
nonvolatile (Inmon, 1993).

• Subject-oriented, sebagai gudang yang diselenggarakan di sekitar mata pelajaran utama dari organisasi (seperti
pelanggan, produk, dan penjualan) daripada area aplikasi utama (seperti faktur pelanggan, kontrol stok, dan
penjualan produk). Hal ini tercermin dalam kebutuhan untuk menyimpan data pendukung keputusan bukan data
applicationoriented.

• Integrated,, karena datang bersama-sama dari sumber data dari organisasi-lebar sistem aplikasi yang berbeda.
Sumber data sering tidak konsisten, menggunakan, misalnya, jenis data yang berbeda dan / atau format. Sumber data
yang terintegrasi harus dibuat konsisten untuk menyajikan pandangan terpadu dari data ke pengguna.

• Time-variant, karena data di gudang akurat dan hanya berlaku di beberapa titik waktu atau lebih dari beberapa
interval waktu.

• Nonvolatile, karena data tidak diperbarui secara real time tetapi di-refresh dari sistem operasional secara teratur.
Data baru selalu ditambahkan sebagai suplemen untuk database, bukan pengganti. Arsitektur khas dari gudang data
ditunjukkan pada Gambar 3.13. Sumber data operasional untuk data warehouse disuplai dari mainframe, sistem file
proprietary, workstation pribadi dan server, dan sistem eksternal seperti Internet. Sebuah menyimpan data
operasional (BPO) adalah gudang data operasional saat ini dan terintegrasi yang digunakan untuk analisis. Hal ini
sering terstruktur dan disertakan dengan data dalam cara yang sama seperti data warehouse, tetapi mungkin
sebenarnya bertindak hanya sebagai area pementasan untuk data yang akan dipindahkan ke gudang. Manajer beban
melakukan semua
124 | Chapter 3 Database Architectures and the Web

Gambar 3.13 khas arsitektur sebuah data Gudang

Operasi terkait dengan ekstraksi dan pemuatan data ke dalam gudang. Manajer gudang melakukan semua operasi
yang berhubungan dengan manajemen data, seperti transformasi dan penggabungan sumber data; penciptaan indeks
dan pandangan tentang tabel dasar; generasi agregasi, dan back up dan pengarsipan data. Manajer permintaan
melakukan semua operasi yang berhubungan dengan pengelolaan permintaan pengguna. Data rinci tidak disimpan
online tapi dibuat tersedia dengan meringkas data ke tingkat berikutnya detail. Namun, secara teratur, data rinci
ditambahkan ke gudang untuk melengkapi data diringkas. Toko gudang semua ditentukan sebelumnya ringan dan
sangat Data dirangkum dihasilkan oleh manajer gudang. Tujuan dari ringkasan informasi adalah untuk mempercepat
kinerja query. Meskipun ada peningkatan biaya operasional yang terkait dengan awalnya meringkas data, biaya ini
diimbangi dengan menghapus kebutuhan untuk terus melakukan operasi Ringkasan (seperti menyortir atau
pengelompokan) dalam menjawab pertanyaan pengguna. Data Ringkasan diperbarui terus menerus sebagai data baru
dimuat ke dalam gudang. Rinci dan diringkas data disimpan offline untuk keperluan pengarsipan dan backup.
Metadata (data tentang data) definisi yang digunakan oleh semua proses di gudang, termasuk proses ekstraksi dan
pemuatan; proses manajemen gudang; dan sebagai bagian dari proses manajemen query. Tujuan utama dari data
warehouse adalah untuk memberikan informasi kepada pengguna bisnis untuk pengambilan keputusan strategis.
Para pengguna berinteraksi dengan gudang menggunakan akses alat pengguna akhir. Data warehouse harus secara
efisien mendukung ad hoc danrutin
3.5 Cloud Computing | 125

analisis serta analisis data yang lebih kompleks. Jenis akses alat pengguna akhir biasanya mencakup pelaporan dan
permintaan alat, alat pengembangan aplikasi, sistem informasi eksekutif (EIS) alat, pengolahan analisis online
(OLAP) tools, dan alat data mining. Kami akan membahas data pergudangan, OLAP, dan alat data mining secara
mendalam pada Bab 31-34. 3,5 Cloud Computing

Cloud computing

Sebuah model untuk memungkinkan di mana-mana, nyaman, on-demand akses jaringan ke kolam renang bersama
sumber daya komputasi dikonfigurasi (misalnya, jaringan, server, penyimpanan, aplikasi, dan layanan) yang dapat
dengan cepat ditetapkan dan dirilis dengan upaya manajemen yang minimal atau penyedia layanan interaksi (NIST,
2011) 1.

1 NIST, 2011. NIST Definisi Cloud Computing, NIST Publikasi Khusus 800-145, Institut Nasional Standar,
September 2011.

Cloud computing adalah istilah yang diberikan untuk penggunaan beberapa server melalui jaringan digital seolah-
olah mereka satu komputer. The 'Cloud' itu sendiri adalah virtualisasi sumber daya-jaringan, server, aplikasi,
penyimpanan data, dan layanan-yang akhir-pengguna memiliki akses on-demand untuk. Virtualisasi adalah
penciptaan versi virtual dari sesuatu, seperti server, sistem operasi, perangkat penyimpanan, atau sumber daya
jaringan. Tujuannya adalah untuk menyediakan sumber daya ini dengan manajemen yang minimal atau interaksi
penyedia layanan. Cloud computing menawarkan sumber pengguna tanpa persyaratan memiliki pengetahuan tentang
sistem atau lokasi sistem yang memberikan mereka. Selain itu, awan dapat memberikan pengguna dengan berbagai
jauh lebih besar dari aplikasi dan layanan. Oleh karena itu, tujuan dari awan adalah untuk menyediakan pengguna
dan bisnis dengan layanan scalable dan disesuaikan. NIST memandang model cloud sebagai terdiri dari lima
karakteristik penting, tiga model layanan, dan empat model penyebaran. Karakteristik penting adalah sebagai
berikut:

• On-demand self-service. Konsumen dapat memperoleh, mengkonfigurasi, dan menyebarkan layanan cloud
sendiri menggunakan katalog layanan awan, tanpa memerlukan bantuan dari siapa pun dari penyedia awan

• akses jaringan luas. Karakteristik yang paling penting dari komputasi awan, yaitu bahwa hal itu didasarkan
jaringan, dan dapat diakses dari mana saja, dari setiap platform standar (misalnya, komputer desktop, laptop,
perangkat mobile).

• Sumber Daya pooling. Sumber penyedia awan komputasi dikumpulkan untuk melayani beberapa
konsumen, dengan sumber daya yang berbeda fisik dan virtual yang ditetapkan secara dinamis dan dipindahkan
sesuai dengan permintaan konsumen. Contoh sumber daya termasuk penyimpanan, pemrosesan, memori, dan
bandwidth jaringan.

• elastisitas cepat. Sumber daya pooling menghindari belanja modal yang diperlukan untuk pembentukan jaringan
dan infrastruktur komputasi. Dengan outsourcing ke awan, konsumen dapat memenuhi lonjakan permintaan untuk
layanan mereka dengan menggunakan kapasitas komputasi penyedia awan, dan risiko pemadaman dan gangguan
layanan secara signifikan berkurang. Selain itu, kemampuan dapat elastis ditetapkan dan dirilis, dalam beberapa
kasus secara otomatis, skala cepat berdasarkan permintaan. Untuk konsumen, kemampuan tersedia untuk
penyediaan sering muncul menjadi tidak terbatas dan dapat dipanggil dalam jumlah setiap saat.

126 | Chapter 3 Database Architectures and the Web

• Measured servic.(Layanan Terukur). Sistem cloud secara otomatis mengontrol dan mengoptimalkan penggunaan
sumber daya dengan memanfaatkan kemampuan metering sesuai dengan jenis layanan (misalnya, penyimpanan,
pengolahan, bandwidth, dan account pengguna aktif). Penggunaan sumber daya dapat dipantau, dikendalikan, dan
dikenakan biaya untuk.

Tiga model layanan didefinisikan oleh NIST adalah sebagai berikut:

• Software as a Service (SaaS). Software dan data terkait terpusat host di awan. SaaS biasanya diakses dari berbagai
perangkat klien melalui antarmuka thin client, seperti browser Web. Konsumen tidak mengelola atau mengendalikan
infrastruktur awan yang mendasari dengan kemungkinan pengecualian dari pengaturan konfigurasi aplikasi yang
spesifk terbatas. SaaS dapat dianggap jenis tertua dan paling matang dari komputasi awan. Contohnya termasuk
Salesforce.com aplikasi manajemen penjualan, Netsuite software manajemen bisnis terpadu, Gmail Google, dan
Cornerstone OnDemand.

• Platform sebagai Layanan (PaaS). PaaS platform komputasi yang memungkinkan pembuatan aplikasi web dengan
cepat dan mudah dan tanpa kompleksitas membeli dan memelihara perangkat lunak dan infrastruktur di bawahnya.
Kadang-kadang, PaaS digunakan untuk memperluas kemampuan aplikasi yang dikembangkan sebagai SaaS.
Sementara pengembangan aplikasi sebelumnya diperlukan hardware, sistem operasi, database, middleware, server
Web, dan perangkat lunak lainnya, dengan model PaaS hanya pengetahuan untuk mengintegrasikan mereka
diperlukan. Sisanya ditangani oleh penyedia PaaS. Contoh PaaS termasuk Salesforce.com ini Force.com, Google
App Engine, dan Microsoft Azure. Konsumen tidak mengelola atau mengendalikan infrastruktur awan yang
mendasari termasuk jaringan, server, sistem operasi, atau penyimpanan, namun memiliki kontrol atas aplikasi
dikerahkan dan pengaturan mungkin konfigurasi untuk lingkungan hosting.

• Infrastruktur sebagai Layanan (IaaS). IaaS memberikan server, storage, jaringan dan sistem operasi-biasanya
platform virtualisasi lingkungan kepada konsumen sebagai layanan on-demand, dalam sebuah paket dan ditagih
sesuai dengan penggunaan. Sebuah penggunaan populer dari IaaS adalah di hosting situs Web, di mana infrastruktur
di rumah tidak terbebani dengan tugas ini, tapi dibiarkan bebas untuk mengelola bisnis. Amazon Elastic Compute
Cloud (EC2), Rackspace, dan GoGrid adalah contoh IaaS. Konsumen tidak mengelola atau mengendalikan
infrastruktur awan yang mendasari tetapi memiliki kontrol atas sistem operasi, penyimpanan, dan aplikasi
dikerahkan, dan kontrol mungkin terbatas pilih komponen jaringan (misalnya, firewall).
Model ini diilustrasikan pada Gambar 3.14.

Empat model penyebaran utama untuk awan adalah:

•Private cloud. Infrastruktur awan semata-mata dioperasikan untuk organisasi tunggal, apakah dikelola secara
internal oleh organisasi, pihak ketiga, atau beberapa kombinasi dari mereka, dan mungkin host internal atau
eksternal.
•Community cloud. Infrastruktur awan dibagi untuk penggunaan eksklusif oleh komunitas tertentu organisasi yang
memiliki keprihatinan umum (misalnya, persyaratan keamanan, kepatuhan, yurisdiksi). Ini mungkin dimiliki dan
dikelola oleh satu atau lebih organisasi di masyarakat, pihak ketiga, atau beberapa kombinasi dari mereka, dan
mungkin host internal atau eksternal.
•Public cloud.. Infrastruktur awan dibuat tersedia untuk masyarakat umum oleh penyedia layanan. Layanan ini
gratis atau ditawarkan pada model pay-per-digunakan. Ini mungkin dimiliki dan dikelola oleh bisnis, akademik, atau
organisasi pemerintah, atau beberapa kombinasi dari ini. Ini ada di tempat penyedia awan.
3.5 Cloud Computing | 127

Gambar 3.14 Perbedaan antara paket perangkat lunak,IaaS,PaaS,dan SaaS.

Umumnya, penyedia layanan cloud publik seperti Amazon AWS, Microsoft, dan Google memiliki dan
mengoperasikan infrastruktur dan menawarkan akses hanya melalui internet (konektivitas langsung tidak
ditawarkan).

•Hybrid cloud.. Infrastruktur awan adalah komposisi dari dua atau lebih yang berbeda infrastruktur cloud (swasta,
komunitas, atau masyarakat) yang tetap entitas unik, namun terikat bersama oleh teknologi standar atau eksklusif,
menawarkan manfaat dari beberapa model penyebaran.

3.5.1 Manfaat dan Risiko komputasi Cloud Computing Cloud menawarkan sejumlah manfaat yang berbeda untuk
perusahaan dibandingkan dengan pendekatan yang lebih tradisional: • Biaya-reduksi. Cloud computing
memungkinkan organisasi untuk menghindari belanja modal muka yang terkait dengan server mahal, lisensi
perangkat lunak, dan personil IT, menggeser tanggung jawab ini ke penyedia awan. Hal ini memungkinkan
perusahaan-perusahaan kecil untuk memiliki akses ke infrastruktur komputasi yang kuat bahwa mereka mungkin
sebaliknya tidak mampu membayar. Selain itu, organisasi hanya membayar untuk fasilitas komputasi yang mereka
gunakan daripada membayar terlepas dari apakah atau tidak fasilitas yang digunakan untuk kapasitas penuh.
128 | Chapter 3 Database Architectures and the Web

• Skalabilitas / Agility. Provisioning-on-demand memungkinkan organisasi untuk mengatur sumber daya yang
mereka butuhkan dan menghilangkan sumber yang tidak diinginkan pada dasar yang dibutuhkan. Ketika sebuah
proyek yang didanai, organisasi memulai layanan, dan ketika proyek berakhir sumber daya dapat dilepaskan. Ini
mendukung pertumbuhan bisnis tanpa memerlukan perubahan mahal untuk sistem TI yang ada organisasi. Hal ini
juga dikenal sebagai elastisitas dan balik nama Amazon Elastic Computing Cloud (EC2).

• Peningkatan keamanan. Keamanan dapat sebaik atau bahkan lebih baik daripada sistem di rumah, karena
penyedia cloud dapat mencurahkan sumber daya untuk memecahkan masalah keamanan yang banyak organisasi
tidak mampu. Desentralisasi data juga dapat memberikan peningkatan keamanan, karena tidak semua data organisasi
disimpan di satu tempat. Selain itu, banyak organisasi yang lebih kecil tidak memiliki sumber daya yang dibutuhkan
untuk mengelola audit dan sertifikasi proses untuk pusat data internal. Penyedia awan yang membahas standar
kepatuhan seperti Sarbanes-Oxley, Industri Kartu Pembayaran Standar Keamanan Data (PCI DSS), dan Asuransi
Kesehatan Portabilitas dan Akuntabilitas Act (HIPAA) dapat membantu organisasi mengatasi proses regulasi dan
kepatuhan.

• Peningkatan keandalan. Sekali lagi, dengan sumber daya dikhususkan penyedia cloud dapat fokus pada
peningkatan keandalan sistem mereka. Provider dapat memberikan 24/7 dukungan dan komputasi tingkat tinggi
untuk semua klien mereka sekaligus, daripada setiap klien yang membutuhkan dedicated staf di rumah sendiri. Hal
ini menyebabkan sistem yang lebih berlebihan dan aman.

• Akses ke teknologi baru. Komputasi awan dapat membantu memastikan bahwa organisasi memiliki akses ke
teknologi terbaru, termasuk akses ke perangkat keras, perangkat lunak, dan fungsi TI yang dinyatakan akan terlalu
mahal untuk membeli.

• pembangunan lebih cepat. Cloud platform komputasi menyediakan banyak layanan inti yang mungkin
biasanya dibangun di rumah. Layanan ini, ditambah template dan alat-alat lainnya, secara signifikan dapat
mempercepat siklus pengembangan.

• skala besar pengujian prototipe / beban. Cloud computing membuat prototipe skala besar dan pengujian
beban lebih mudah. Ini akan mungkin untuk bertelur 1.000 server di awan untuk memuat menguji aplikasi dan
kemudian membebaskan mereka segera setelah tes selesai, yang akan sangat sulit dan mahal dengan server di-
rumah.

• praktek kerja lebih fleksibel. Cloud computing memungkinkan staf untuk bekerja lebih fleksibel. Staf dapat
mengakses file menggunakan perangkat Web-enabled seperti laptop, netbook dan smartphone. Kemampuan untuk
secara bersamaan berbagi dokumen dan file lainnya melalui Internet juga dapat membantu mendukung kolaborasi
global dan berbagi pengetahuan serta pengambilan keputusan kelompok.

• Peningkatan daya saing. Mendelegasikan infrastruktur dan layanan komoditas memungkinkan organisasi
untuk fokus pada kompetensi inti mereka dan mengembangkan kemampuan yang dapat membedakan organisasi
mereka di pasar bisnis masing-masing, sehingga meningkatkan daya saing.

Serta manfaat, komputasi awan juga menyajikan beberapa risiko untuk organisasi seperti:

• Jaringan ketergantungan. Mungkin kelemahan paling jelas untuk komputasi awan adalah ketergantungan pada
jaringan. Listrik padam dan gangguan layanan akan mencegah akses ke fasilitas cloud. Selain itu, komputasi awan
juga rentan terhadap masalah bandwidth sederhana, misalnya, pada jam-jam puncak permintaan. Jika server
penyedia awan sedang tegang pada jam sibuk, baik kinerja dan ketersediaan layanan akan menderita. Sementara
banyak penyedia cloud akan memiliki redundansi untuk menangani beban puncak mereka, selalu ada risiko kejadian
tak terduga, kegagalan server atau serangan luar; apapun yang akan mengancam akses klien.
3.5 Cloud Computing | 129

• Sistem ketergantungan. sebuah organisasi serta mungkin Sangat tergantung pada ketersediaan dan keandalan
Sistem provider awan.penyedia gagal memberikan pemulihan bencana yang memadai, hasilnya bias menjadi
bencana besar bagi organisasi .

• Cloud provider ketergantungan. Idealnya, penyedia program awan tidak akan bangkrut atau diakuisisi Oleh
perusahaan yang lebih besar . jika terjadi, ada kemungkinan bahwa layanan akan tiba-tiba menghentikan dan
organisasi perlu memastikan mereka dilindungiterhadap sebuah kemungkinan.

• Kurangnya Kontrol. Mencari Google Artikel melakukan data ke sistem yang dikelola oleh provider cloud,
organisasi serta tidak mungkin lagi berada Penuh Dari data yang menyebarkan langkah-langkah teknis dan
organisasi serta yang diperlukan data yang Menjaga. Akibatnya, masalah berikut mungkin Timbul:

- Kurangnya ketersediaan. Jika provider awan bergantung pada Teknologi ekslusif, mungkin terbukti sulit
bagi suatu organisasi menggeser data dan dokumen antara Sistem Berbasis cloud yang berbeda (portabilitas
data) atau bertukar information dengan aplikasi yang menggunakan layanan awan yang dikelola oleh
provider layanan yang berbeda (interoperabilitas).

- Kurangnya integritas. Awan terdiri dari sistem dan infrastruktur bersama. Cloud penyedia proses data
pribadi yang datang dari berbagai mata pelajaran data dan organisasi dan adalah mungkin bahwa konflik
kepentingan dan / atau tujuan yang berbeda mungkin timbul.

- Kurangnya kerahasiaan. Data sedang diproses di awan dapat dikenakan permintaan dari lembaga penegak
hukum. Ada risiko bahwa data dapat diungkapkan kepada lembaga (asing) penegakan hukum tanpa dasar
hukum yang sah dan dengan demikian pelanggaran hukum bisa terjadi.

- Kurangnya intervenability. Karena kompleksitas dan dinamika rantai outsourcing, layanan cloud yang
ditawarkan oleh salah satu penyedia mungkin dihasilkan dengan menggabungkan layanan dari berbagai
provider lain, yang mungkin secara dinamis ditambahkan atau dihapus selama durasi kontrak organisasi.
Selain itu, penyedia awan mungkin tidak memberikan langkah-langkah yang diperlukan dan alat untuk
melindungi data organisasi atau data pribadi seseorang dalam hal, misalnya akses, penghapusan, atau koreksi
data.

- Kurangnya isolasi. Sebuah penyedia awan mungkin menggunakan kontrol fisik atas data dari klien yang
berbeda untuk menghubungkan data pribadi. Jika administrator difasilitasi dengan hak akses yang cukup
istimewa, mereka bisa menghubungkan informasi dari klien yang berbeda.

• Kurangnya informasi pada pengolahan (transparansi). Informasi yang cukup tentang operasi pengolahan
layanan awan menimbulkan risiko untuk pengendali data serta untuk data mata pelajaran karena mereka
mungkin tidak menyadari potensi ancaman dan risiko dan dengan demikian tidak dapat mengambil
langkah-langkah yang mereka anggap tepat. Beberapa potensi ancaman yang mungkin timbul dari
pengontrol data tidak mengetahui bahwa:

-tempat pengolahan Rantai mengambil melibatkan beberapa prosesor dan subkontraktor.

-Data pribadi diproses di lokasi geografis yang berbeda. Dampak ini langsung pada hukum yang berlaku
untuk setiap sengketa perlindungan data yang mungkin timbul antara pengguna dan penyedia.
-Data pribadi ditransfer ke negara ketiga di luar kendali organisasi. Negara-negara ketiga mungkin tidak
memberikan tingkat perlindungan yang memadai data dan transfer tidak dapat dijaga dengan langkah-
 langkah yang tepat (misalnya, klausa kontrak standar atau mengikat peraturan perusahaan) dan dengan
demikian mungkin illegal.

130 | Chapter 3 Database Architectures and the Web

3.5.2 Cloud Berbasis aaS, solusi database berbasis cloud jatuh ke dalam dua kategori dasar: Data sebagai Service
(DaaS) dan Database sebagai Service (DBaaS). Perbedaan utama antara keduanya adalah terutama bagaimana data
dikelola:

• DaaS. Daas menawarkan kemampuan untuk mendefinisikan data di awan dan kemudian query data yang on
demand. Tidak seperti solusi database tradisional, DaaS tidak mengimplementasikan interface DBMS khas seperti
SQL (lihat Bab 6). Sebaliknya, data tersebut diakses melalui seperangkat API. DaaS memungkinkan organisasi
dengan data berharga untuk membuat garis pendapatan baru berdasarkan data mereka sudah sendiri. Contoh DaaS
yang Perkotaan Pemetaan, layanan geografi data, yang menyediakan data bagi pelanggan untuk menanamkan ke
dalam situs web mereka sendiri dan aplikasi; Xignite, yang membuat data keuangan tersedia untuk pelanggan; dan
Hoovers, sebuah Dun & Bradstreet perusahaan, yang menyediakan data bisnis di berbagai organisasi.

• DBaaS. DBaaS menawarkan fungsionalitas database lengkap untuk pengembang aplikasi. Dalam DBaaS, lapisan
manajemen bertanggung jawab untuk pemantauan terus menerus dan mengkonfigurasi database untuk mencapai
skala dioptimalkan, ketersediaan tinggi, multi-tenancy (yaitu, melayani beberapa organisasi klien), dan alokasi
sumber daya yang efektif di awan, sehingga hemat pengembang dari tugas-tugas administrasi database yang sedang
berlangsung.

Database sebagai arsitektur Layanan mendukung kemampuan yang diperlukan berikut:

-penyediaan dan pengelolaan contoh database menggunakan on-demand berbasis konsumen, mekanisme self-
service
-Automated pemantauan dan kepatuhan definisi penyedia layanan yang ditetapkan, atribut dan kualitas tingkat
pelayanan
-Fine-grained metering dari penggunaan database memungkinkan acara-kembali melaporkan atau fungsi biaya-
kembali untuk setiap individu konsumen.

Ada sejumlah isu arsitektur yang terkait dengan DBaaS hubungannya dengan bagaimana data satu organisasi
diisolasi dari data organisasi lain . Kami mempertimbangkan pilihan berikut:
•server terpisah
•Shared server, proses database server terpisah
•database server bersama, database yang terpisah
•Bersama basis data, skema
•terpisah,Database Bersama bersama skema

Server Terpisah Arsitektur

Dengan arsitektur server terpisah, masing-masing tenant memiliki host mesin server yang hanya berfungsi database
mereka. Arsitektur ini mungkin tepat untuk organisasi yang membutuhkan tingkat tinggi isolasi, memiliki database
besar, sejumlah besar pengguna, atau yang memiliki persyaratan kinerja yang sangat spesifik. Pendekatan ini
cenderung mengarah ke biaya yang lebih tinggi untuk menjaga peralatan dan back up data penyewa. Arsitektur
diilustrasikan pada Gambar 3.15.

Server bersama, database server proses arsitektur

terpisah Dengan arsitektur ini, masing-masing tenant memiliki database mereka sendiri, namun, beberapa penyewa
berbagi mesin server tunggal, masing-masing dengan proses server sendiri. Arsitektur ini.
3.5 Cloud Computing | 131

Gambar 3.15 Multi-tenant cloud database yang terpisah server arsitektur.

merupakan lingkungan virtualisasi umum. Sumber daya pada mesin server yang diberikan dibagi untuk masing-
masing tenant. Setiap lingkungan virtual cadangan sumber daya memori dan disk sendiri, dan tidak dapat berbagi
sumber daya yang tidak terpakai dengan lingkungan virtual lainnya. Dengan pendekatan ini, memori dan
penyimpanan dapat menjadi masalah karena masing-masing tenant memiliki file database mereka sendiri dan proses
server. Selain itu, kinerja dapat menjadi masalah karena penyewa berbagi server yang sama meskipun penyedia
cloud dapat mengurangi risiko ini dengan mengalokasikan hanya sejumlah kecil penyewa untuk setiap server.
Keamanan tidak menjadi masalah karena penyewa benar-benar terisolasi dari satu sama lain. Arsitektur ini
diilustrasikan pada Gambar 3.16.

Server database bersama, database terpisah

Dengan arsitektur ini, masing-masing tenant memiliki database yang terpisah mereka sendiri tetapi berbagi server
database tunggal (dan proses server tunggal) dengan semua penyewa lainnya. Perbaikan atas pendekatan
sebelumnya adalah bahwa proses server database tunggal dapat berbagi sumber daya seperti cache database efektif
antara penyewa, mendukung penggunaan sumber daya mesin. Arsitektur ini diilustrasikan pada Gambar 3.17.

Server Database bersama, arsitektur skema terpisah

Dengan arsitektur ini, ada server database tunggal bersama dan masing-masing tenant memiliki data dikelompokkan
ke dalam skema yang dibuat khusus untuk penyewa. DBMS harus
132 | Chapter 3 Database Architectures and the Web

Gambar 3.16 Multi-tenant cloud bersama database-server,terpisah database server proses arsitektur

Gambar 3.17 multi-tenant cloud database-bersama DBMS server terpisah.

3.5 Cloud Computing | 133

Gambar 3.18 Multi-tenant cloud databasebersama,database skema arsitekturterpisah.

database yang memiliki struktur izin untuk memastikan bahwa pengguna hanya memiliki akses ke data yang mereka
berhak. Arsitektur ini diilustrasikan pada Gambar 3.18.

Database bersama, berbagi skema arsitektur

Dengan arsitektur ini, ada server database tunggal bersama dan masing-masing tenant memiliki data dikelompokkan
ke dalam skema bersama tunggal. Setiap tabel database harus memiliki kolom yang digunakan untuk
mengidentifikasi pemilik baris. Setiap aplikasi mengakses baris harus mengacu pada kolom ini di setiap query untuk
memastikan bahwa salah satu penyewa tidak dapat melihat data lain penyewa. Pendekatan ini memiliki biaya
hardware dan cadangan terendah, karena mendukung jumlah terbesar dari penyewa per server database. Namun,
karena beberapa penyewa berbagi tabel database yang sama, pendekatan ini mungkin menimbulkan upaya
pengembangan tambahan dalam keamanan, untuk memastikan bahwa penyewa tidak dapat mengakses data penyewa
lain. Pendekatan ini sesuai jika penting bahwa aplikasi harus melayani sejumlah besar penyewa dengan sejumlah
kecil server, dan calon pelanggan bersedia untuk menyerah isolasi data dalam pertukaran untuk biaya yang lebih
rendah bahwa pendekatan ini memungkinkan. Arsitektur ini diilustrasikan pada Gambar 3.19.
134 | Chapter 3 Database Architectures and the Web

Gambar 3.19 Multi-tenant cloud database bersama skema arsitektur.

3.6 Komponen DBMS

DBMS adalah potongan-potongan yang sangat kompleks dan canggih dari perangkat lunak yang bertujuan untuk
menyediakan layanan yang dibahas dalam Bagian 2.4. Hal ini tidak mungkin untuk menggeneralisasi struktur
komponen dari DBMS, karena sangat bervariasi dari sistem ke sistem. Namun, hal ini berguna ketika mencoba
untuk memahami sistem database untuk mencoba untuk melihat komponen dan hubungan antara mereka. Pada
bagian ini, kami menyajikan arsitektur yang mungkin untuk DBMS. Kami meneliti arsitektur DBMS Oracle pada
bagian berikutnya. Sebuah DBMS dibagi menjadi beberapa komponen software (atau modul), yang masing-masing
diberikan sebuah operasi tertentu. Seperti yang dinyatakan sebelumnya, beberapa fungsi dari DBMS yang didukung
oleh sistem operasi yang mendasarinya. Namun, sistem operasi hanya menyediakan layanan dasar dan DBMS harus
dibangun di atasnya.

Dengan demikian, desain sebuah DBMS harus memperhitungkan antarmuka antara DBMS dan sistem operasi.
Komponen software utama dalam lingkungan DBMS digambarkan pada Gambar 3.20. Diagram ini menunjukkan
bagaimana DBMS interface dengan komponen perangkat lunak lain, seperti permintaan pengguna dan metode akses
(teknik manajemen file untuk menyimpan dan mengambil catatan data). Kami akan memberikan gambaran tentang
organisasi berkas dan metode akses dalam Lampiran F. Untuk perawatan lebih komprehensif, pembaca yang tertarik
disebut Teorey dan Fry (1982), Weiderhold (1983), Smith dan Barnes (1987), dan Ullman (1988 ).
3.6 Components of a DBMS | 135

Gambar 3.20utama Komponen dari DBMS.

Gambar 3.20 menunjukkan komponen-komponen berikut:

• prosesor Query. Ini adalah komponen DBMS utama yang mengubah query ke dalam serangkaian instruksi tingkat
rendah diarahkan ke database manager. Kami membahas pemrosesan query dalam Bab 23.

•database manager (DM). DM interface dengan program aplikasi yang dikirimkan pengguna dan permintaan. DM
menerima query dan menguji skema eksternal dan konseptual untuk menentukan apa catatan konseptual yang
diperlukan untuk memenuhi permintaan tersebut. DM kemudian menempatkan panggilan ke file manager untuk
melakukan permintaan. Komponen DM ditunjukkan pada Gambar 3.21.

•Manajer file. File manager memanipulasi penyimpanan file yang mendasari dan mengelola alokasi ruang
penyimpanan pada disk. Ini membangun dan mempertahankan daftar struktur dan indeks didefinisikan dalam skema
internal. Jika file hash yang digunakan, itu panggilan pada fungsi hashing untuk menghasilkan alamat record.
Namun, file manager tidak langsung mengelola input fisik dan output data. Sebaliknya, melewati permintaan ke
metode akses yang sesuai, yang baik membaca data dari atau menulis data ke dalam sistem penyangga (atau Cache).

•DML preprocessor. Modul ini mengubah pernyataan DML tertanam dalam sebuah program aplikasi ke dalam
fungsi panggilan standar dalam bahasa tuan rumah. DML preprocessor harus berinteraksi dengan query processor
untuk menghasilkan kode yang sesuai.

•DDL compiler. DDL compiler mengkonversi pernyataan DDL ke dalam satu set tabel yang berisi metadata. Tabel
ini kemudian disimpan dalam katalog sistem sedangkan informasi kontrol disimpan dalam header
136 | Chapter 3 Database Architectures and the Web

Gambar 3.21 Komponen dari database

• Manajer Katalog. Manajer katalog mengelola akses ke dan memelihara sistem katalog. Sistem katalog diakses oleh
sebagian besar komponen DBMS.

Komponen perangkat lunak utama untuk manajer database adalah sebagai berikut:

•control Otorisasi. Modul ini menegaskan apakah pengguna memiliki izin yang diperlukan untuk melaksanakan
operasi yang dibutuhkan.

•prosesor Command. Setelah sistem telah mengkonfirmasi bahwa pengguna memiliki kewenangan untuk
melakukan operasi, kontrol akan diteruskan ke prosesor perintah.

•Integritas checker. Untuk sebuah operasi yang mengubah database, cek integritas checker apakah operasi yang
diminta memenuhi batasan integritas semua yang diperlukan (seperti kendala utama).

•Query optimizer. Modul ini menentukan strategi yang optimal untuk eksekusi query. Kami membahas optimasi
query pada Bab 23.
3.7 Oracle Architecture | 137

• Transaksi manajer. Modul ini melakukan pengolahan diperlukan operasi yang diterima dari transaksi.
• Scheduler. Modul ini bertanggung jawab untuk memastikan bahwa operasi bersamaan pada database melanjutkan
tanpa bertentangan dengan satu sama lain. Dia mengontrol urutan relatif di mana operasi transaksi dieksekusi.
• Manajer Pemulihan. Modul ini memastikan bahwa database tetap dalam keadaan konsisten di hadapan
kegagalan. Hal ini bertanggung jawab untuk transaksi komit dan batalkan.
• Manajer Buffer. Modul ini bertanggung jawab untuk transfer data antara memori utama dan penyimpanan
sekunder, seperti disk dan tape. Manajer pemulihan dan manajer penyangga kadang-kadang disebut secara
kolektif sebagai manajer data. Manajer penyangga kadang-kadang dikenal sebagai manajer cache.
Kami membahas empat modul terakhir dalam Bab 22. Selain modul disebutkan sebelumnya, beberapa struktur
data lain yang diperlukan sebagai bagian dari pelaksanaan physicallevel. Struktur ini meliputi data dan file
indeks dan katalog sistem. Sebuah usaha telah dilakukan untuk standarisasi DBMS, dan model referensi
diusulkan oleh Database Architecture Framework Task Group (DAFTG, 1986). Tujuan dari model referensi ini
adalah untuk menentukan kerangka kerja konseptual yang bertujuan untuk membagi upaya standardisasi ke
dalam bagian dan untuk menunjukkan pada tingkat yang sangat luas bagaimana potongan-potongan ini bisa
saling.

3.7. Arsitektur oracle

Oracle didasarkan pada arsitektur client-server diperiksa dalam bagian 3.1.3. Oracle Server terdiri dari database
(data mentah, termasuk log dan kontrol file) dan contoh (proses dan sistem memori pada server yang
memberikan akses ke database). Sebuah contoh dapat terhubung ke hanya satu database. Database terdiri dari
struktur logis, seperti skema database, dan struktur fisik, yang berisi file yang membentuk database Oracle. Kita
sekarang membahas struktur logis dan fisik dari database dan proses sistem secara lebih rinci.

3.7.1. Logical Struktur Database Oracle

Pada tingkat logis, Oracle memelihara tablespace, skema, dan blok data dan luasan / segmen.

Tablespace
database Sebuah Oracle dibagi menjadi unit penyimpanan logis yang disebut tablespace. Sebuah tablespace
digunakan untuk kelompok terkait struktur logis bersama-sama. Misalnya, tablespace umum kelompok semua objek
aplikasi untuk menyederhanakan beberapa operasi administrasi. Setiap database Oracle berisi tablespace bernama
SYSTEM, yang dibuat secara otomatis ketika database dibuat. SYSTEM tablespace selalu berisi tabel sistem
katalog (disebut kamus data dalam Oracle) untuk seluruh database. Sebuah database kecil mungkin hanya perlu
tablespace SYSTEM; Namun, dianjurkan bahwa setidaknya satu tablespace tambahan dibuat untuk menyimpan data
pengguna terpisah dari kamus data, sehingga mengurangi pertentangan antara objek-objek kamus dan obyek skema
untuk datafiles yang sama (lihat Gambar 19.11). Gambar 3.22
138 | Bab 3 Arsitektur Database dan Web

menggambarkan database Oracle terdiri dari tablespace SYSTEM dan tablespace USER_ DATA.
Sebuah tablespace baru dapat dibuat dengan menggunakan perintah CREATE tablespace,
misalnya:
CREATE tablespace user_data
datafile 'DATA3.ORA' UKURAN 100K
MANAJEMEN SEJAUH LOKAL
AUTOSEGMEN MANAJEMENRUANG;
Sebuah meja kemudian dapat dikaitkan dengan tablespace tertentu menggunakan CREATE
TABLE atau ALTER TABLE pernyataan, misalnya:
CREATE TABLE PropertyForRent PropertyNo VARCHAR2(5) NOT(...NULL,)
tablespace user_data;
Jika tidak ada tablespace ditentukan saat membuat tabel baru, default tablespace diasosiasikan-
diciptakan dengan pengguna ketika akun pengguna didirikan digunakan.

Pengguna, skema, dan skema objek

Pengguna (kadang-kadang disebut namapengguna) adalah nama yang ditetapkan dalam

database yang dapat terhubung ke, dan akses, benda-benda. Skema adalah kumpulan bernama
obyek skema, seperti tabel, pandangan, indeks, cluster, dan prosedur, yang terkait dengan
pengguna tertentu. Skema dan pengguna membantu DBA mengelola keamanan database.
 3.7 Oracle Arsitektur | 139

Untuk mengakses database, pengguna harus menjalankan aplikasi database (seperti Oracle
Form atau SQL * Plus) dan terhubung menggunakan username didefinisikan dalam database.
Ketika pengguna database dibuat, skema yang sesuai dengan nama yang sama diciptakan untuk
pengguna. Secara default, setelah pengguna terhubung ke database, pengguna memiliki akses ke
semua obyek yang terkandung dalam yang sesuai skema. Sebagai pengguna dikaitkan hanya
dengan skema dengan nama yang sama; istilah "user" dan "skema" sering digunakan antar-
changeably. (Perhatikan bahwa tidak ada hubungan antara tablespace dan skema: Objek dalam
skema yang sama dapat di tablespace yang berbeda, dan tablespace dapat memegang benda dari
skema yang berbeda.)

Data blok, luasan, dan segmen

blok data adalah unit terkecil penyimpanan yang Oracle dapat menggunakan atau mengalokasikan. Satu blok data
sesuai dengan jumlah tertentu byte ruang disk fisik. Ukuran blok data dapat diatur untuk setiap database Oracle
ketika dibuat. Ukuran blok data ini harus kelipatan dari ukuran blok sistem operasi (dalam batas operasi maksimum
sistem) untuk menghindari yang tidak perlu I / O. Sebuah blok data memiliki struktur sebagai berikut:

header.berisi informasi umum seperti alamat blok dan jenis segmen.

Direktorimeja.berisi informasi tentang tabel yang memiliki data dalam blok data.
Direktori baris. berisi informasi tentang baris di blok data.
Data baris. berisi baris data aktual meja. Sederet dapat span blok.
Ruang bebas. dialokasikan untuk penyisipan baris baru dan update untuk baris yang
membutuhkan ruang tambahan. Pada Oracle8i,Oracle dapat mengelola ruang bebas secara
otomatis, meskipun ada pilihan untuk mengelola secara manual.
Kami menunjukkan bagaimana memperkirakan ukuran tabel Oracle menggunakan komponen ini
dalam Lampiran J di situs Web untuk buku ini. Tingkat berikutnya ruang database logis disebut
batas.Rupa adalah jumlah tertentu blok data berdekatan allo-kasikan untuk menyimpan jenis
informasi khusus. Tingkat atas batas yang disebut segmen.Segmen adalah satu set luasan yang
dialokasikan untuk struktur logis tertentu. Sebagai contoh, data setiap meja yang disimpan dalam
segmen data sendiri, dan data masing-masing indeks disimpan dalam segmen indeks sendiri.
140 | Bab 3 Arsitektur Database dan web

blok Web,luasan, dan segmen. Oracle dinamis mengalokasikan ruang ketika luasan eksis-ing dari
segmen menjadi penuh. Karena luasan dialokasikan sesuai kebutuhan, luasan segmen mungkin
atau mungkin tidak berdekatan pada disk.

3.7.2 Fisik Struktur Database Oracle

utama fisik struktur database dalam Oracle adalah datafile, Redo log file, dan file kontrol.

Datafiles

Setiap database Oracle memiliki satu atau lebih datafiles fisik. Data struktur data-base logis
(seperti tabel dan indeks) secara fisik disimpan di datafile tersebut. Seperti ditunjukkan dalam
Gambar 3.16, satu atau lebih datafiles membentuk tablespace. Database Oracle sederhana akan
memiliki satu tablespace dan satu datafile. Sebuah database yang lebih kompleks mungkin
memiliki empat tablespace, masing-masing terdiri dari dua datafiles, memberikan total delapan
datafiles.

Redo log file

Setiap database Oracle memiliki seperangkat dua atau lebih file redo log yang merekam semua
perubahan yang dibuat untuk data untuk tujuan pemulihan. Harus gagal mencegah data yang
diubah dari yang secara permanen ditulis ke datafiles, perubahan dapat diperoleh dari redo log,
sehingga mencegah kerja dari tersesat. Kita membahas pemulihan secara rinci dalam Bagian 22.3.

Kontrol file

Setiap database Oracle memiliki file kontrol yang berisi daftar semua file lain yang membentuk
database, seperti datafiles dan Redo log file. Untuk menambahkan proteksi-tion, dianjurkan
bahwa file kontrol harus multiplexing (beberapa salinan dapat ditulis untuk beberapa perangkat).
Demikian pula, mungkin disarankan untuk multipleks file redo log juga.

Contoh Oracle

Oracle instance terdiri dari proses Oracle dan memori bersama diperlukan untuk mengakses
informasi dalam database. Contoh terdiri dari proses latar belakang Oracle, proses pengguna, dan
memori bersama yang digunakan oleh proses-proses ini, seperti digambarkan pada Gambar 3.18.
Antara lain, Oracle menggunakan memori bersama untuk caching data dan indeks serta
menyimpan kode program bersama. Memori bersama dipecah menjadi berbagai struktur memori,
yang yang dasar adalah Area Global System (SGA) dan Global Area Program (PGA).

Area global sistem. SGA adalah daerah memori bersama yang digunakan untuk menyimpan
informasi data dan kontrol untuk satu contoh Oracle. SGA dialokasikan ketika instance Oracle
dimulai dan deallocated ketika instance Oracle dimatikan. Informasi dalam SGA terdiri dari
struktur memori berikut, yang masing-masing memiliki ukuran tetap dan dibuat pada startup
contoh:
 3.7 Oracle Arsitektur | 141

- database cache buffer. Ini mengandung paling terakhir digunakan blok data dari database.
Blok ini dapat berisi data dimodifikasi yang belum ditulis ke disk (blok kotor), blok yang
belum dimodifikasi, atau blok yang telah ditulis ke disk karena modifikasi (blok bersih).
Dengan menyimpan blok yang terakhir digunakan, buffer paling aktif tinggal di memori
untuk mengurangi I / O dan meningkatkan kinerja. Kami membahas penyangga
kebijakan manajemen dalam Bagian 22.3.2.

- Redo log buffer. Ini berisi entri berkas redo log, yang digunakan untuk tujuan recov-ery
(lihat Bagian 22.3). Proses latar belakang LGWR (dijelaskan kemudian) menulis redo
log buffer ke file yang aktif redo log online pada disk.

- Kolam Bersama. Ini berisi struktur memori bersama, seperti daerah SQL dibagi dalam
cache perpustakaan dan informasi internal dalam kamus data. Daerah SQL bersama
berisi pohon-pohon parse dan rencana eksekusi untuk query SQL. Jika beberapa aplikasi
mengeluarkan pernyataan SQL yang sama, masing-masing dapat mengakses area SQL
bersama untuk mengurangi jumlah memori yang diperlukan dan untuk mengurangi
waktu pemrosesan yang digunakan untuk parsing dan eksekusi. Kami membahas
pemrosesan query dalam Bab 23.

- Kolam besar. Ini adalah area memori opsional dimaksudkan untuk besar memori alloca-
tions (misalnya. Untuk buffer untuk Recovery Manager (RMAN) I / O budak).

- Java renang. Daerah ini menyimpan semua sesi khusus kode Java dan data dalam Java
Virtual Machine (JVM).

- Streaming kolam renang. Toko daerah ini buffered pesan antrian dan menyediakan
memori untuk proses Oracle Streams. Oracle Streaming memungkinkan arus informasi
(seperti peristiwa database dan perubahan database) untuk dikelola dan berpotensi propa-
gated ke database lain.

- Tetap SGA. Ini adalah area rumah tangga internal yang berisi berbagai data seperti
informasi umum tentang keadaan database dan contoh Oracle dan informasi
dikomunikasikan antara proses Oracle, seperti informasi tentang kunci.

Program area global. PGA merupakan daerah memori bersama yang digunakan untuk
menyimpan informasi data dan kontrol untuk proses Oracle. PGA yang dibuat oleh Oracle
Database saat proses Oracle dimulai. Satu PGA ada untuk setiap server pro-cess dan proses
latar belakang. Ukuran dan isi dari PGA tergantung pada pilihan server Oracle diinstal.

Proses client. Setiap proses klien mewakili koneksi pengguna ke Oracle Server (misalnya,
melalui SQL * Plus atau Oracle Forms aplikasi). Proses pengguna memanipulasi input
pengguna, berkomunikasi dengan proses server Oracle, menampilkan informasi yang
diminta oleh pengguna dan, jika diperlukan, pro-proses-informasi ini menjadi bentuk yang
lebih berguna.

Proses Oracle. Oracle (server) proses melakukan fungsi bagi pengguna. Oracle pro-cesses
dapat dibagi menjadi dua kelompok: proses server (yang menangani permintaan dari
proses pengguna terhubung) dan proses latar belakang (yang melakukan asynchronous I /
O dan memberikan peningkatan paralelisme untuk meningkatkan kinerja dan kehandalan).
Dari Gambar 3.24, kita memiliki latar belakang proses berikut:
- database Penulis (DBWR). Proses DBWR bertanggung jawab untuk menulis blok mod-
ified (kotor) dari buffer cache di SGA untuk datafiles pada disk. Sebuah contoh Oracle
dapat memiliki hingga sepuluh proses DBWR, bernama DBW0 untuk DBW9, untuk
menangani I / O ke beberapa datafiles. Oracle menggunakan teknik yang dikenal sebagai
 write-depan log (lihat Bagian 22.3.4), yang berarti bahwa proses DBWR mempunyai
kinerja batched menulis setiap kali buffer harus dibebaskan, belum tentu pada titik
transaksi melakukan

142 | Chapter 3 Database Architectures and the Web

- Log Penulis (LGWR). Proses LGWR bertanggung jawab untuk menulis data dari log
buffer ke redo log.

- Checkpoint (CKPT). Sebuah pos pemeriksaan merupakan acara di mana semua buffer
database yang dimodifikasi ditulis dengan datafiles oleh DBWR tersebut (lihat Bagian
22.3.2). Proses CKPT bertanggung jawab untuk memberitahu proses DBWR untuk
melakukan pemeriksaan dan memperbarui semua datafiles dan file kontrol untuk
database untuk menunjukkan pos pemeriksaan terbaru. Proses CKPT adalah opsional
dan, jika dihilangkan, tanggung jawab ini diasumsikan oleh proses LGWR.

- Sistem Monitor (SMON). Proses SMON bertanggung jawab untuk pemulihan kecelakaan
 ketika misalnya yang mulai mengikuti kegagalan. Ini termasuk pulih trans-tindakan yang
telah meninggal karena sistem crash. SMON juga defragments database dengan
menggabungkan luasan bebas dalam datafiles.

3.7Oracle Arsitektur| 143

- Proses Monitor (PMON). Proses PMON bertanggung jawab untuk melacak proses
pengguna yang mengakses database dan memulihkan mereka setelah kecelakaan. Ini
termasuk membersihkan sumber daya tertinggal (seperti memori) dan melepaskan setiap
kunci yang dipegang oleh proses gagal.

- Archiver (ARCH). Proses ARCH bertanggung jawab untuk menyalin file redo log online
untuk penyimpanan arsip ketika mereka menjadi penuh. Sistem ini dapat config-ured
berlari hingga 10 proses ARCH, bernama ARC0 untuk ARC9. Proses arsip tambahan
dimulai oleh LWGR ketika beban menentukan.

- Recoverer (Reco). Proses RECO bertanggung jawab untuk membersihkan gagal atau
ditangguhkan didistribusikan transaksi (lihat Bagian 25.4).

- Flashback Penulis atau Recovery Penulis (RVWR). Ketika kilas balik diaktifkan atau
ketika ada dijamin restore point, proses RVWR menulis data kilas balik ke kilas balik
database log di daerah pemulihan flash. Alat Flashback memungkinkan admin-istrators
dan pengguna untuk melihat dan memanipulasi negara masa lalu data Oracle instance
tanpa memulihkan database ke titik tetap dalam waktu.

- Pengaturan Monitor (MMON). Proses ini melakukan banyak tugas yang berhubungan
dengan Otomatis Beban Kerja Repository(AWR).AWR adalah gudang data historis
perfor-Mance yang mencakup statistik kumulatif untuk sistem, sesi, masing-masing SQL
laporan, segmen, dan layanan. Antara lain, secara default, proses MMON
mengumpulkan statistik setiap jam dan menciptakan snapshot AWR.

- Pengaturan Memantau Lite (MMNL). Proses ini menulis statistik dari Session History
(ASH) penyangga Aktif di SGA ke disk. MMNL menulis ke disk ketika buffer ASH
penuh.

Dalam uraian sebelumnya kita telah menggunakan istilah "proses" generik. Saat ini, beberapa
sistem melaksanakan proses sebagai benang.

Contoh bagaimana proses berinteraksi

Contoh berikut menggambarkan konfigurasi Oracle dengan proses server yang berjalan pada
satu mesin dan proses pengguna menghubungkan ke server dari mesin Sepa-tingkat. Oracle
menggunakan mekanisme komunikasi yang disebut Oracle Layanan Net untuk
memungkinkan proses pada mesin fisik yang berbeda untuk berkomunikasi satu sama lain.
Oracle Layanan Net mendukung berbagai protokol jaringan, seperti TCP / IP. Layanan juga
dapat melakukan susun protokol jaringan, yang memungkinkan klien yang menggunakan satu
protokol untuk berinteraksi dengan database server menggunakan protokol lain.

Klien workstation menjalankan aplikasi dalam proses pengguna. Klien appli-kation

mencoba untuk membuat sambungan ke server menggunakan driver Oracle Net Services.
Server mendeteksi permintaan sambungan dari aplikasi dan menciptakan (dedicated)
proses server atas nama proses pengguna.
Pengguna menjalankan pernyataan SQL untuk mengubah deretan meja dan melakukan
transaksi.
Proses server menerima pernyataan dan memeriksa kolam renang bersama untuk setiap
daerah SQL bersama yang berisi pernyataan SQL yang identik. Jika area SQL bersama
ditemukan, proses server memeriksa hak akses pengguna ke data yang diminta dan
daerah SQL bersama sebelumnya yang ada digunakan untuk memproses
144 | Bab 3 database Arsitektur dan Web

jika pernyataan tidak, daerah SQL bersama baru dialokasikan untuk pernyataan sehingga bisa diurai dan
diproses.

Proses server mengambil nilai-nilai data yang diperlukan dari datafile yang sebenarnya (tabel) atau yang
disimpan di SGA.
Proses server memodifikasi data dalam SGA tersebut. Proses DBWR menulis blok modi-fied secara permanen
ke disk ketika melakukan itu adalah efisien. Karena TRANSAKSI-tion berkomitmen, proses LGWR segera
mencatat transaksi dalam file online redo log.
Proses server mengirimkan pesan keberhasilan / kegagalan seluruh jaringan ke aplikasi.
Selama ini, latar belakang lainnya proses-proses berjalan, menonton untuk kondisi yang memerlukan intervensi.
Selain itu, server Oracle mengelola transaksi pengguna lain 'dan mencegah pertentangan antara transaksi yang
meminta data yang sama.

Bab Ringkasan

 Client-server arsitekturmengacu pada cara di mana komponen software berinteraksi. Ada klien proses
yang membutuhkan beberapa sumber daya, dan server yang menyediakan sumber daya. Dalam model
two-tier, klien menangani user interface dan logika bisnis pengolahan dan server menangani fungsi
database. Dalam lingkungan Web, model two-tier tradisional telah digantikan oleh model tiga-tier, yang
terdiri dari lapisan pengguna antar-muka (klien),logika bisnis dan lapisan data processing
(serveraplikasi),dan DBMS (databaseserver),yang tersebar di mesin yang berbeda.
 Arsitektur three-tier dapat diperpanjang untuk n tingkatan, akan tingkatan tambahan yang
ditambahkan untuk memberikan lebih banyak fleksibilitas dan skalabilitas.
 Middleware adalah perangkat lunak komputer yang menghubungkan komponen perangkat lunak
atau aplikasi. jenis middleware termasuk RPC (sinkron dan asinkron), mempublikasikan /
berlangganan, pesan-berorientasi middleware (MOM), broker objek permintaan (ORB), dan database
middleware.
 layanan Web adalah sistem software yang dirancang untuk mendukung interaksi interoperable
mesin-ke-mesin melalui jaringan. Mereka didasarkan pada standar seperti XML, SOAP, WSDL, dan
UDDI.
 Service-Oriented Architecture(SOA)adalah sebuah arsitektur software-centric bisnis untuk
membangun aplikasi yang menerapkan proses bisnis sebagai set layanan diterbitkan pada granularity
yang relevan dengan konsumen layanan.
 Cloud computing adalah model untuk memungkinkan di mana-mana, nyaman, akses jaringan on-
demand untuk bersama pool sumber daya komputasi dikonfigurasi (misalnya, jaringan, server,
penyimpanan, aplikasi, dan layanan) yang dapat dengan cepat ditetapkan dan dirilis dengan upaya
manajemen yang minimal atau interaksi penyedia layanan. Tiga model layanan utama adalah: Software
as a Service (SaaS), Platform as a Service (PaaS), dan Infrastruktur sebagai Layanan (IaaS). Solusi
database berbasis cloud jatuh ke dalam dua kategori dasar: Data sebagai Service (DaaS) dan Database
sebagai Service (DBaaS).
 A Transaction Processing (TP) Monitor adalah sebuah program yang mengontrol transfer data
antara klien dan server untuk menyediakan lingkungan yang konsisten, terutama untuk proses
transaksi online (OLTP). Keuntungan meliputi routing yang transaksi, transaksi terdistribusi, load
balancing, menyalurkan, dan peningkatan kehandalan.
 CHAPTER 4

Model Relasional

Bab Tujuan
Dalam bab ini Anda akan belajar:

 Asal-usul model relasional
 Terminologi dari model relasional
  Bagaimana tabel digunakan untuk merepresentasikan data.
 Hubungan antara hubungan matematika dan hubungan dalam relasional model.
 Sifat hubungan database.
 Bagaimana mengidentifikasi kandidat, primer, alternatif, dan kunci asing.
 Yang dimaksud dengan integritas entitas dan integritas referensial.
 Tujuan dan keuntungan dari pandangan dalam sistem relasional.
Sistem Manajemen Database Relasional (RDBMS) telah menjadi perangkat lunak pengolahan data yang
dominan digunakan saat ini, dengan perkiraanpenjualan lisensil baru 

antara US $ 6 miliar dan US $ 10 miliar per tahun (US $ 25 miliardengan penjualan alat-alat termasuk).Software

ini merupakan generasi kedua dari DBMS dan didasarkan pada

model data relasionaldiusulkan olehEF Codd (1970). Dalam model relasional, semua data 

secara logis terstruktur dalam hubungan (tabel). Setiap relasi memiliki nama dan terdiri dari

atribut bernama (kolom) data. Setiap tuple (baris) berisi satu nilai peratribut. Sebuah kekuatan besar dari

model relasional adalah struktur logissederhana. Namun, di balik struktur sederhana adalah landasan
teoritis suara yang kurang di generasi pertama DBMS (jaringan dan DBMSs hirarkis).

Kita mencurahkan sejumlah besar buku ini untuk RDBMS, sebagai pengakuan atas

pentingnya sistem ini. Dalam bab ini, kita membahas konsep-konsep struktural terminologi dan dasar dari model data

relasional. Dalam bab berikut,kita meneliti bahasa relasional yang dapat digunakan untuk update danpengambilan
data

Struktur dari bab ini

Untuk menempatkan perlakukan kami RDBMS ke dalam perspektif, dalam Bagian 3.1 kita memberikan sejarah

singkat dari model relasional. PadaBagian 3.2 kita membahas konsep dasar dan terminologi dari
modelrelasional. Pada Bagian 3.3 kita membahas aturan integritas relasional,termasuk integritas entitas
dan integritas referensial. 

Pada Bagian 3.4 kitamemperkenalkan konsep pandangan, yang adalah fitur penting dari 

DBMSrelasional meskipun,tegasnya, bukankonsep darimodel relasional perse.
Ke depan, dalam Bab 5 dan 6 kita memeriksa SQL (Structured Query Language), bahasa formal dan de
facto standar untuk RDBMSs, dan dalamBab 7 kita meneliti QBE 

(Query-By-contoh), lain bahasa query yang sangatpopuler visual untuk RDBMSs . Dalam Bab 15-

18 kita menyajikan metodologilengkap untuk desain database relasional. Dalam Lampiran D,
kita memeriksadua belas Codd aturan, yang membentuk tolok ukur terhadap yang RDBMSproduk dapat
diidentifikasi. Contoh-contoh dalam bab ini diambil dari Kasus 

DreamHome studi, yang dijelaskan secara rinci dalam Bagian 10.4 danLampiran A.

4.1 Sejarah Singkat Model Relasional

Model relasional pertama kali diusulkan oleh EF Codd dalam makalah mani'Sebuah model relasional data untuk

besar bank data bersama' (Codd, 1970).Tulisan ini sekarang umumnya diterima sebagai tengara dalam sistem
database, meskipun model set-berorientasi 

telah diusulkan sebelumnya(Childs, 1968). Tujuan model relasional yang telah ditentukan 

sebagai berikut:

 Untuk memungkinkan tingkat tinggi independensi data. Program aplikasi tidak boleh terpengaruh

oleh modifikasi pada representasi data internal, terutama dengan perubahan organisasi
file, orderings catatan, atau jalur akses.
 Untuk memberikan alasan kuat untuk berurusan dengan semantik data,konsistensi, 
dan masalah redundansi. Secara khusus, kertas Codd memperkenalkan konsep

 normalisasi

 hubungan, yaitu hubungan yang tidak memiliki kelompok berulang. (Proses

 normalisasi ini dibahas dalam Bab 13 dan 14.)

 Untuk mengaktifkan perluasan set-bahasa berorientasi manipulasi data.

Meskipun bunga dalam model relasional datang dari beberapa arah, penelitian yang
paling signifikan mungkin disebabkan tiga proyek dengan perspektif yang agak berbeda. Yang
pertama, di IBM San Jose Research Laboratory diCalifornia, adalah
prototipe relasional DBMS Sistem R, yang dikembangkanpada akhir
1970an (Astrahan proyek dirancang untuk membuktikan kepraktisanmodel relasional dengan
menyediakan sebuah implementasi dari struktur datadan operasi. Hal ini juga terbukti
merupakan excellentsource informasi tentangkekhawatiran implementasi seperti manajemen transaksi,
kontrol konkurensi,teknik pemulihan, optimasi query, keamanan data dan integritas, faktor manusia,
dan antarmuka pengguna, dan menyebabkan publikasi makalah
penelitianbanyak . dan pengembangan prototipe lain Secara khusus, Sistem R proyekmenyebabkan
dua perkembangan utama:

 pengembangan bahasa query terstruktur yang disebut SQL (diucapkan 'SQ-L',atau kadang-kadang 'See-

Quel'), yang sejak itu menjadi resmi Organisasi Internasional untuk Standarisasi (ISO)
dan bahasa standar de facto untukrelasional DBMS;
 produksi berbagai produk komersial DBMS relasional pada akhir 1970an dan 1980-an: misalnya,
DB2 dan SQL / DS dari IBM dan Oracle dari OracleCorporation.
Proyek kedua telah signifikan dalam pengembangan model relasional adalah
Ingres (Interactive Graphics Retrieval System) proyek di University of California di Berkeley, yang aktif pada
waktu yang sama dengan proyek R Sistem. Proyek Ingres melibatkan pengembangan prototipe RDBMS, dengan
penelitian berkonsentrasi pada tujuan keseluruhan sama dengan proyek R Sistem. Penelitian ini dipimpin ke
versi akademik Ingres, yang memberikan kontribusi terhadap apresiasi umum konsep relasional,
dan menelurkan produk Ingres komersial dari Relasional
Technology Inc (sekarang Keuntungan Ingres Relational Database Enterprisedari Computer Associates)
dan Database Machine Cerdas dari Britton Lee Inc.
 Proyek ketiga adalah Uji Kendaraan Peterlee Relasional di Pusat Inggris IBMI lmiah di Peterlee (Todd,
1976). Proyek ini memiliki orientasi yang lebih teoritisdaripada R Sistem dan proyek Ingres dan signifikan,
terutama untuk penelitianmasalah-masalah seperti pemrosesan query dan optimasi, dan perluasan fungsional.

Sistem komersial berbasis pada model relasional mulai muncul di akhir 1970an dan awal tahun

1980. Sekarang ada beberapa ratus RDBMSs baik untuk lingkungan mainframe dan PC, meskipun banyak yang
tidak benar-benar mengikuti definisi model relasional. Contoh berbasis PC RDBMSs adalahOffice Access dan
Visual FoxPro dari Microsoft, Interbase dan JDataStore dari Borland, dan R: Base dari
R: DASAR Technologies.

Karena popularitas dari model relasional, banyak non-relasional system sekarang menyediakan antarmuka

pengguna relasional, terlepas dari model yang mendasari. IDMS Computer Associates ', jaringan utama DBMS,
telah menjadi Keuntungan CA-IDMS, mendukung pandangan relasional data. DBMSmainframe lain
yang mendukung beberapa fitur relasional adalah Computer Corporation of America Model 204 dan
Software AG Adabas.

Beberapa ekstensi untuk model relasional juga telah diusulkan, misalnya,

ekstensi untuk:

 menangkap lebih dekat makna data (misalnya, Codd, 1979);

  dukungan konsep berorientasi obyek (misalnya, Stonebraker dan Rowe, 1986);
 mendukung kemampuan deduktif (misalnya, Gardarin dan Valduriez, 1989).
Kami membahas beberapa ekstensi ini dalam Bab 25-28 pada DBMSs Objek.

4.2 Terminologi

Model relasional didasarkan pada konsep matematika hubungan, yang secara fisik direpresentasikan

sebagai sebuah tabel. Codd, seorang matematikawanterlatih, menggunakan istilah yang diambil
dari matematika, terutama teorimengatur dan logika predikat. Pada bagian ini kita menjelaskan
konsepterminologi dan struktural dari model relasional.

4.2.1 Struktur Data Relasional

Hubungan  Relasi adalah tabel dengan kolom dan baris.

RDBMS hanya memerlukan bahwa database dirasakan oleh pengguna sebagai tabel. Namun, perlu

diketahui bahwa persepsi ini hanya berlaku untuk struktur logis dari database: yaitu, tingkat eksternal
dan konseptual dari arsitekturANSI-SPARC dibahas dalam Bagian 2.1. Ini tidak berlaku untuk struktur fisikdari
database, yang dapat diimplementasikan dengan menggunakan berbagai struktur penyimpanan (lihat
Lampiran C)

Atribut  Atribut adalah kolom bernama relasi.

Dalam model relasional, relasi digunakan untuk menyimpan informasi tentang objek yang

akan diwakili dalam database. Suatu relasi direpresentasikan sebagai tabel dua dimensi di mana baris tabel
tersebut sesuai dengan catatan individu dan kolom tabel sesuai dengan atribut. Atribut dapat muncul dalam
urutan apapun dan hubungan akan tetap sama, dan menyampaikan makna yang sama.

Sebagai contoh, informasi pada kantor cabang diwakili oleh hubungan Cabang,dengan kolom

untuk Tidak ada cabang atribut (jumlah cabang), jalan, kota, dankode pos. Demikian pula, informasi
mengenai staf diwakili oleh hubungan Staf, dengan kolom atribut untuk bukan staf atribut
(jumlah staf), fname, lname, posisi, jenis kelamin, DOB (tanggal lahir), gaji, dan cabang Tidak
(jumlah cabang karya anggota staf di). Gambar 3.1 menunjukkan contoh dari hubungan Cabang
dan Staf. Seperti yang Anda lihat dari contoh ini, kolom berisi nilai-nilai atribut tunggal, misalnya,cabang Tidak
ada kolom berisi angka saja dari kantor cabang yang ada.

Domain  domain adalah himpunan nilai yang diijinkan untuk satu atau lebih atribut.

Domain adalah fitur yang sangat kuat dari model relasional. Setiap atribut dalam suatu

relasi yang didefinisikan pada domain. Domain mungkin berbeda untuk setiap atribut, dua atau lebih
atribut dapat didefinisikan pada domain yang sama. Gambar 3.2 menunjukkan domain untuk beberapa
atribut dari relasi Cabang dan Staf. Perhatikan bahwa, pada waktu tertentu, biasanya akan adanilai dalam
sebuah domain yang saat ini tidak muncul sebagai nilai-nilai dalam atribut yang sesuai.

Konsep domain adalah penting karena memungkinkan pengguna untuk menentukan di satu

tempat makna dan sumber nilai-nilai bahwa atribut dapat terus. Akibatnya, lebih banyak informasi tersedia
untuk sistem ketika melakukan eksekusi dari operasi relasional, dan operasi yang secara semantik tidak benar
dapat dihindari. Misalnya, tidak masuk akal untuk membandingkan nama jalan dengan nomor telepon,
meskipun definisi domain untuk kedua atribut ini adalah string karakter. Di sisi lain, sewa bulanan pada
properti dan jumlah bulanproperti telah disewakan memiliki domain yang berbeda (nilai pertama moneter,
nilai satu detik integer), tetapi masih operasi hukum .
 Attributes gambar 3.1

Contoh dari
Cabang dan Staf

hubungan.

No cabang Jalan kota Kode Pos

B005 22 Deer Rd London SW14EH

B007 16 Agryll St Aberdeen AB23SU
B003 163 Main St Glasgow G119QX
B004 32 Manse Rd Bristol B5991NZ
B002 56 Clover Dr London NW106EU

hjhjhjhjh
Degree

Primary key

Foreign key

staff

No Staff fnama Inama Posisi Jenis kelamin DOB Gaji No Cabang

SL21 John White Manager Laki-laki 1-okt-45 30000 B005
SG37 Ann Beech Asisten Perempuan 10-nov-60 12000 B003
SG14 David Ford Supervisor Laki-laki 24-mar-58 18000 B003
SA9 Mary Howe Asisten Perempuan 19-feb-70 9000 B007
SG5 Susan Brand Manager Perempuan 3-jun-40 24000 B003
SL41 Julie Lee Asisten Perempuan 13-jun-65 9000 B005

Atribut Nama Doamin Makna Definisi Domain

No cabang No cabang Kemungkinan himpunan semua nomor cabang  karakter: ukuran 4, rentang B001-B999
Jalan Nama Jalan Himpunan semua nama jalan di Inggris karakter: ukuran 25
Kota Nama Kota Himpunan semua nama kota di Inggris karakter: ukuran 15
Kode Pos Kode pos Himpunan semua kode pos di Inggris karakter: ukuran 8
Jenis Kelamin Jenis Kelamin Jenis kelamin seseorang karakter: ukuran1, nilai M atau F
DOB Tanggal Lahir Kemungkinan nilai tanggal lahir staf tanggal, berkisar antara 1-Jan-20,
Kemungkinan nilai gaji staf format dd-mmm-yy
Gaji Gaji Kemungkinan nilai gaji staf moneter: 7 digit, jangkauan
6000.00-40000.00

Gambar 4.2 Domain untuk beberapa atribut dari Cabang dan Staf hubungan.

mengalikan dua nilai dari domain. Seperti dua contoh ilustrasi, implementasi lengkap dari domain ini tidak

mudah dan, sebagai hasilnya, RDBMSs banyak yang tidak mendukung mereka sepenuhnya.

Tuple  Tuple adalah baris dari relasi.

Elemen-elemen dari relasi adalah baris atau tupel dalam tabel. Dalam hubunganCabang, setiap baris

berisi empat nilai, satu untuk setiap atribut. Tupel dapat muncul dalam urutan apapun dan hubungan akan
tetap relasi yang sama, dan karena itu menyampaikan makna yang sama.

Struktur relasi, bersama dengan spesifikasi dari domain dan pembatasanlainnya pada nilai yang

mungkin, kadang-kadang disebut kehebatan, yangbiasanya tetap kecuali makna relasi diubah untuk
menyertakan atribut tambahan. Tupel disebut perpanjangan (atau negara) dari suatu relasi, yang berubah dari
waktu ke waktu.

Derajat Derajat relasi adalah jumlah atribut yang dikandungnya.

Hubungan Cabang pada Gambar 4.1 memiliki empat atribut atau gelar empat.Ini berarti bahwa setiap

baris dari tabel adalah tupel empat, yang berisi empat nilai. Relasi dengan hanya satu atribut akan memiliki
satu derajat dan disebutrelasi unary atau satu-tupel. Sebuah hubungan dengan dua atribut disebut biner, satu
dengan tiga atribut disebut ternary, dan setelah itu istilah n-ary biasanya digunakan. Derajat relasi adalah
properti dari kehebatan dari relasi.

Kardinalitas Kardinalitas relasi adalah jumlah tuple yang dikandungnya

Sebaliknya, jumlah tupel disebut kardinalitas relasi dan ini perubahan sebagai tuple yang ditambahkan atau

dihapus. Kardinalitas adalah milik perluasan hubungan dan ditentukan dari contoh tertentu dari relasi pada suatu
waktu tertentu. Akhirnya, kami memiliki definisi database relasional

Relational Basis Data Kumpulan dari hubungan normalisasi dengan nama relasi yang berbeda.

Sebuah database relasional terdiri dari hubungan yang tepat terstruktur. Kami mengacu

pada kesesuaian ini sebagai normalisasi. Kami menundapembahasan normalisasi sampai Bab

13 dan 14.

Alternatif Terminology

Terminologi untuk model relasional bisa sangat membingungkan. Kami telah

Memperkenalkan dua set istilah. Bahkan, set ketiga istilah kadang-kadang digunakan: relasi
dapat disebut sebagai file, tupel sebagai catatan, dan atributsebagai bidang. Istilah ini berasal
dari kenyataan bahwa, secara fisik, RDBMSdapat menyimpan setiap relasi dalam file.
Tabel 4.1 merangkum istilah yang berbeda untuk model relasional.

Tabel 4.1 Alternatif istilah untuk istilah model relasional.

Hal Formal Alternativ1 Alternativ2
Relasi Table Berkas
Tupel Baris Catatan
Attribute Kolom Bidang

4.2.2 Relasi Matematika

Untuk memahami arti sebenarnya dari hubungan panjang, kita harus meninjau beberapa
konsep dari matematika. Misalkan kita memiliki dua set, D1 dan D2, dimana D1={2, 4} dan D2 = {1, 3, 5}.
Produk Cartesian dua set, ditulis D1x D2, adalah himpunan semua pasangan terurut seperti bahwa
elemen cemara adalah od anggota D1 dan elemen keduaadalah anggota D2. alternatif cara mengekspresikan ini
adalah untuk mencari semua kombinasi elemen dengan yang pertama dari D1 dan yang kedua dari D2. dalam
kasus yang kami miliki :
D1 x D2 = {(2, 1), (2, 3), (2, 5), (4, 1), (4, 3), (4, 5)}

Beberapa subset dari Cartesian produk ini adalah relasi.Sebagai contoh, kita bisa menghasilkan sebuah relasi R

sedemikian rupa sehingga:

R = {(2, 1), (4, 1)}

Kita mungkin menentukan memerintahkan pasang akan berada dalam relasi dengan memberikan beberapa

kondisiuntuk pemilihan mereka. Sebagai contoh, jika kita amatibahwa R mencakup semua pasangan
terurut yang elemen kedua adalah 1, maka kita bisa menulis R sebagai:

R {(x, y) x ∈D1, y ∈D2, and y 1}

Dengan menggunakan set yang sama, kita bisa membentuk hubungan lain S di mana elemen pertamaselalu dua

kali yang kedua. Jadi, kita bisa menulis S sebagai:

S {(x, y) x ∈D1, y ∈D2, and x 2y}

atau, dalam hal ini,

S ={(2, 1)}

karena hanya ada satu pasang memerintahkan dalam produk Cartesian yang memenuhi kondisi ini. Kita dapat

dengan mudah memperluas gagasan tentang hubungannya dengan tiga set. biarkan D1, D2, dan D3 menjadi tiga
set . Cartesian produk D1× D2 x D3 dari ketiga set adalahhimpunan semua tiga kali
lipat memerintahkan sedemikian rupa sehingga elemen pertama adalah dari D, elemen kedua adalah
dari D2, dan elemet ketiga adalah dari D3, setiap subset dari Cartesian produk ini adalah relasi.Misalnya, kita
memiliki:

D1 {1, 3} D2 {2, 4} D3 {5, 6}

D1 D2 D3 {(1, 2, 5), (1, 2, 6), (1, 4, 5), (1, 4, 6), (3, 2, 5), (3, 2, 6), (3, 4, 5), (3, 4, 6)}

Setiap subset dari tiga kali lipat memerintahkan adalahrelasi. Kita bisa memperpanjang tiga set dan menetapkan

umum relasi pada domain n. Misalkan D1, D2, . . . ., Dn adalah set n . Cartesian produk mereka didefinisikan
sebagai:

D1 D2 . . . Dn {(d1, d2, . . . , dn) d1 ∈D1, d2 ∈D2, . . . , dn ∈Dn}

dan biasanya ditulis sebagai:

X Di

I=1

Setiap himpunan n-tuple dari Cartesian produk adalah relasipada set n. Perhatikan bahwa dalam

mendefinisikanhubungan ini kita harus menentukan set, atau domain, dari mana kita memilih nilai.

4.2.3 Hubungan Relasi

Menerapkan konsep-konsep di atas untuk database, kita dapat mendefinisikan skema relasi.

Skema Relasi Suatu relasi bernama didefinisikan oleh satu set atribut danpasangan nama domain.

Lihat A1, A2, . . . . ., An menjadi atribut dengan domain D1, D2, . . . ., Dn . Kemudian set

{A1:D1, A2:D2, . . . An:Dn} adalah sebuah skema relasi . Sebuah relasi R didefinisikan oleh

relasi skema S adalah satu set pemetaan dari nama-nama atribut ke domain yang

berhubungan. Jadi, relasi R adalah set n-tuple:

(A1:d1,A2:d2, . . . , An:dn) demikian d1 E D1, d1 E D2 . . ., dn E Dn

Setiap elemen dalam n-tupel terdiri dari atribut dan nilaiatribut itu. Biasanya, ketika kita

menuliskan relasi sebagai tabel, kami daftar nama atribut sebagai judul

kolom danmenuliskan tupel sebagai baris memiliki bentuk (d1,d2, . . . ,dn), dimana

nilai masing-masing diambil dari domain yang sesuai. Dengan cara ini, kita bisa

memikirkan hubungandalam model relasional karena setiap subset dari Cartesian

produk dari domain dariatribut. Sebuah meja hanyalah sebuah representasi

fisikseperti relasi.

{(B005, 22 Deer Rd, London, SW1 4EH)}

Atau lebih tepatnya

{(Nolabel: B005, Jalan: 22 Deer Rd, Kota: London, kode pos: SW1 4EH)}

Kita lihat ini sebagai contoh hubungan. Tabel Cabang adalah cara yang nyaman

untuk menulis semua empat tupleyang membentuk hubungan pada saat tertentu dalam

waktu,yang menjelaskan mengapa baris tabel dalam model relasional disebut tupel. Dengan

cara yang sama bahwarelasi memiliki skema, demikian juga database relasional.

Relasi Skema BasisData satu set skema relasi, masing-masing dengan nama yang berbeda.

If R1, R2, . . ., Rn adalah seperangkat skema relasi, maka kita dapat menulisskema

database relasional, atau hanya skema relasional,R, sebagai:

R = {R1, R2, . . ., Rn}

4.2.4 Sifat Hubungan

Suatu relasi memiliki properti berikut:

 relasi memiliki nama yang berbeda dari semua namahubungan lain dalam skema relasional;

 setiap sel dari relasi berisi tepat satu atom (tunggal) nilai;

 setiap atribut memiliki nama yang berbeda;

 nilai-nilai atribut semua dari domain yang sama;

 tupel masing-masing berbeda, tidak ada duplikat tupel;

 urutan atribut tidak memiliki makna;

 urutan tuple tidak memiliki makna, secara teoritis.(Namun, dalam

prakteknya, agar dapat mempengaruhi efisiensi tupel mengakses.)

Untuk menggambarkan apa pembatasan ini berarti, pertimabangan kembali menghubungkan cabang yang

ditunjukkan pada Gambar 3.1. Karena setiap sel harus mengandunghanya satu nilai, adalah ilegal untuk
menyimpan dua kode pos bagi kantor cabang tunggal dalam satu sel. Dengan kata lain, hubungan tidak
mengandung kelompok yang berulang. Suatu relasi yang memenuhi properti inidikatakan normal atau dalam
bentuk normal pertama .. {Bentuk normal dibahas dalam Bab 13 dan 14.)

Nama kolom yang tercantum pada bagian atas kolomsesuai dengan atribut relasi. Nilai-nilai dalam

atributbranchNo semua dari domain BranchNumbers, kami tidakharus memungkinkan kode
pos nilai muncul dalam kolom ini.Tidak ada duplicatetuples dalam suatu relasi. Misalnya, baris (B005,
22 Rusa Rd, London, SW1 4EH) muncul hanya sekali.

Memberikan nama atribut akan dipindahkan bersama dengan nilai atribut, kita dapat bertukar kolom. Tabel

iniakan mewakili hubungan yang sama jika kita menuliskanatribut kota sebelum atribut kode
pos, meskipun untuk dibaca lebih masuk akal untuk menjaga elemen alamat diurutan normal. Demikian
pula, tupel dapat dipertukarkan,sehingga catatan cabang B005 dan B004 dapat diaktifkandan hubungan akan
tetap sama.

Sebagian besar sifat yang ditentukan untuk hasil hubungan dari sifat hubungan matematis:

 Ketika kita berasal produk Cartesian set dengan sederhana, nilai-tunggal elemen seperti bilangan bulat,

setiap elemen dalam tuple masing-masing bernilai tunggal.Demikian pula, setiap sel dari relasi berisi
 tepat satu nilai.Namun, hubungan matematika tidak perlu dinormalisasi.Codd memilih
untuk kelompok mengulangi melarang untuk menyederhanakan model data relasional.
 Dalam relasi, nilai yang mungkin untuk posisi tertentuditentukan oleh himpunan, atau domain, di
mana posisididefinisikan. Dalam sebuah tabel, nilai-nilai dalam setiap kolom harus datang dari
domain atribut yang sama.
  Dalam satu set, ada elemen yang berulang. Demikian pula, dalam suatu relasi, tidak
ada tupel duplikat.
 Sejak relasi adalah satu set, urutan elemen tidak memiliki makna. Oleh karena itu, dalam suatu
relasi urutan tupletidak material.
Namun, dalam relasi matematika, urutan elemen dalam sebuah tuple adalah penting. Untuk contoh,
pasanganmemerintahkan (1, 2) sangat berbeda dari pasangan memerintahkan (2,1) Hal ini tidak
kasus hubungan dalam model relasional, yang secara khusus mengharuskan urutan atribut tidak
penting.Alasannya adalah bahwa judul kolom mendefinisikan nilai atribut milik. Ini berarti bahwa urutan judul
kolom dikehebatan adalah tidak material, tetapi sekali struktur dari relasi dipilih, urutanelemen-elemen
dalam tupel dari ekstensi harus sesuai dengan urutan nama atribut.

4.2.5 Kunci Rasional

Sebagaimana dinyatakan di atas, ada tupel ada duplikatdalam relasi. Karena itu, kita harus mampu untuk

mengidentifikasi satu atau lebih atribut (disebut kuncirelasional) yang secara unik
mengidentifikasi setiap tupledalam suatu relasi. Pada bagian ini, kami akan menjelaskan terminologi yang
digunakan untuk kunci relasional.

Superkey Atribut, atau seperangkat atribut, yang secara unik mengidentifikasi sebuah tupel di

dalam relasi.

Superkey dengan unik mengenali setiap tupel dalam relasi.Namun, superkey mungkin

berisi atribut tambahan yang tidak perlu untuk identifikasi unik, dan kami tertarik dalam

mengidentifikasi superkeys yang hanya berisijumlah minimum atribut yang diperlukan untuk

identifikasiunik.

Candidate key Sebuah superkey sehingga tidak ada subset yang tepat adalah superkey dalam relasi.

Kunci kandidat, K, untuk relasi R memiliki dua sifat:

 keunikan - di setiap tuple R, nilai K secara unik mengidentifikasi tuple itu;

 irreducibility - tidak ada subset K memiliki sifat keunikan.
Mungkin ada beberapa kandidat kunci untuk relasi. Ketika kunci terdiri lebih dari satu atribut, kita
menyebutnya kunci komposit. Pertimbangkan hubungan Cabang ditunjukkan pada
Gambar 3.1. Mengingat nilai kota, kita dapat menentukan beberapa kantor cabang (misalnya, London
memiliki dua kantor cabang). Atribut ini tidak bisa menjadi kunci kandidat. Di sisi lain, karena
DreamHome mengalokasikan masing-masing kantor cabang sejumlah cabang yang unik, kemudian
diberi nilai cabang nomor, branchNo, kita dapat menentukan paling banyak satu tuple,
sehingga branchNo adalah kunci kandidat. Demikian pula, kode pos juga merupakan kunci kandidat untuk relasi
ini.
  Sekarang mempertimbangkan Melihat hubungan, yang berisi informasi yang berhubungan
dengan properti dilihat oleh klien. Relasi terdiri dari sejumlah klien (clientNo), sejumlah properti (propertyNo),
sebuah tanggal pandang (viewDate)dan, opsional, komentar (komentar). Mengingat sejumlah klien, clientNo,
mungkin ada tampilan yang sesuai beberapa sifat yang berbeda. Demikian pula,
mengingat sejumlah properti, propertyNo, mungkin ada beberapa klien yang dilihat properti ini. Oleh karena
itu, clientNo dengan sendirinya atau propertyNodengan sendirinya tidak dapat dipilih sebagai
kunci kandidat. Namun demikian, kombinasi dari clientNo dan properti No mengidentifikasi paling banyak
satu tupel, jadi, untuk relasi Viewing, klien No dan properti Tidak adabersama-sama membentuk 

kunci kandidat (komposit). Jika kita perlu untuk memenuhi kemungkinan bahwa klien dapat

melihat properti yang lebih dari sekali, maka kita bisa menambahkan viewDate ke

tombol komposit.Namun, kita mengasumsikan bahwa ini tidak diperlukan.

Perhatikan bahwa sebuah instance dari sebuah relasi tidak dapat digunakanuntuk membuktikan

bahwa atribut atau kombinasi atribut adalah kunci kandidat.Fakta bahwa tidak ada duplikat untuk nilai-nilai
yang muncul pada saat tertentutidak menjamin bahawa duplikasi tidak mungkin Namun,
kehadiran duplikatdalam sebuah contoh dapat digunakan untuk menunjukkan bahwa beberapa
kombinasi atribut bukan kunci kandidat. Mengidentifikasi candidate key mengharuskan kita tahu makna 'dunia
nyata' dari atribut (s) yang terlibat sehingga kita dapat memutuskan apakah duplikat yang mungkin. Hanya
dengan menggunakan informasi semantik kita bisa yakin bahwa kombinasiatribut adalah
kunci kandidat. Sebagai contoh, dari data yang disajikan pada Gambar 3.1, kita mungkin berpikir bahwa
kunci calon yang cocok untuk relasi Staf akan lname, nama keluargakaryawan. Namun, meskipun hanya
ada nilai tunggal dari 'White' dalam hal initentang hubungan Staf, anggota staf baru dengan nama 'Putih'
mungkinbergabung dengan perusahaan, membatalkan pilihan lname sebagai kuncikandidat.

Primary key Kunci kandidat yang dipilih untuk mengidentifikasi tupel secara unik dalam

hubungan.

Karena relasi tidak memiliki tupel duplikat, itu selalu mungkin untuk

mengidentifikasi setiap baris unik. Ini berarti bahwa hubungan selalu memiliki
kunci primer. Dalam kasus terburuk, seluruh himpunan atribut bisa berfungsi sebagai kunci
utama, tapi biasanya beberapa subset yang lebih kecil sudah cukup untuk
membedakan tupel. Kunci kandidat yang tidak terpilih menjadi primary
key disebut kunci alternatif. Untuk hubungan Cabang, jika kita memilih branchNo sebagai
primary key, kode pos kemudian akan menjadi kunci alternatif. Untuk hubungan Melihat,
hanya ada satu calon utama, yang terdiri clientNo dan propertyNo, sehingga atribut-atribut
ini secara otomatis akan membentuk primary key.

Foreign Key Atribut , atau set atribut , dalam satu hubungan yang cocok dengan kunci kandidat
dari beberapa (mungkin sama ) hubungan .

Ketika sebuah atribut muncul di lebih dari satu relasi, penampilan biasanya merupakan

hubungan antara tuple dari duarelasi. Misalnya, masuknya cabang dalam
hubungan kedua Cabang dan Staf sangat disengaja dan menghubungkan setiap cabang ke rincian staf yang
bekerja di cabang. Dalam hubungan Cabang, branchNo adalah 
primaryKey tersebut. 
Namun, dalamhubungan Staf atribut branchNo  ada untuk mencocokkan 
staf untuk kantor cabang mereka bekerja masuk Dalam hubungan Staf, branchNo adalah 
kunci asing. Kami mengatakan bahwa branchNo atribut dalam relasi Staff menargetkan 
branchNo atribut kunci primer di Cabang rumah relasi,. Atribut-atribut umum memainkan peran penting dalam
melakukan manipulasi data,seperti yang kita lihat dalam bab berikutnya.
 4.2.6 Mewakili Schemas Relational Database

Sebuah database relasional terdiri dari sejumlah hubungan normal. pararelasional

skema untuk bagian dari studi kasus DreamHome adalah:

Gambar 4.3
Instance dari DreamHome sewa database.

BRANCH

No cabang Jalan Kota Kode Pos

B005 22 Deer Rd Londn SW14EH
B007 16 Argyll St Aberdeen AB23SU
B003 163 Main St Glasgow G119QX
B004 32 Manse Rd Bristol BS99INZ
B002 56 clover Dr London NW106EU

STAFF

NoStaff fNama iNama Posisi P/L DOB GAJI Nocabang

SL21 John White Manager L 1-OKT-45 30000 B005
SG37 Ann Beech Asisten P 10-NOV-60 12000 B003
SG14 David Ford Supervisor L 24-MAR-58 18000 B003
SA9 Mary Howe Asisten P 19-FEB-70 9000 B007
SG5 Susan Brand Manager P 3-JUN-40 24000 B003
SL41 Julie Lee Asisten P 13-JUN-65 9000 B005

Property untuk di sewa

Noproper Jalan Kota kodePos Tipe uuang Sewa Nopemilik Nostaff nocabang
ti
PA14 16 Holhead Aberdeen AB75SU House 6 650 CO46 SA9 B007
PL94 6 Agryll set London NW2 Flat 4 400 CO87 SL41 B005
PG4 6 Lawrence St Glasgow G119QX Flat 3 350 CO40 B003
PG36 2 Manor Rd Glasgow G32 4QX Flat 3 375 CO93 SG37 B003
PG21 18 dale Rd Glasgow G12 House 5 600 CO87 SG37 B003
PG16 5 Novar dr Glasgow G12 9AX Flat 4 450 C093 SG14 B003

KLIEN

Noklien fName Iname noTelp tipePref sewamax

CR76 John Kay 0207-774-5632 Flat 425
CR56 Aline Stewart 0141-848-1825 Flat 350
CR74 Mike Ritchie 01475-39278 House 750
CR62 Mary Tregear 01224-196720 Flat 600
PRIVATECLIENT

NoPemilik fNama Inama Alamat NoTelp

CO46 JOE KEOGH 2Fergus Dr, Aberdeen AB2 7SX 01224-861212
CO87 CAROL FARREL 6 Achray St, Glasgow G32 9DX 0141-357-7419
CO40 TINA MURPHY 63 Well St, Glasgow G42 0141-943-1728
CO93 TONY SHAW 12 Park pl, Glasgow G4 0QR 0141-225-7025

VIEWING

noKlien NoProperty Tanggal Komen

CR56 PA14 21-may -04 Too small
CR76 PG4 20-apr-04 Too remote
CR56 PG4 26-may04
CR62 PA14 14-may-04 No dining room
CR56 PG36 28-apr-04

REGISTRASI

Noklien NoCabang NoStaff Tanggalbergabung

CR76 B005 SL41 2-jan-04
CRR56 B003 SG37 11-aprl-03
CR74 B003 SG37 16-nov-02
CR62 B007 SA9 7-mar-03

Cabang (NoCabang, jalan, kota, kode pos)

Staf (NoStaff, fnama, lnama, posisi, jenis kelamin, DOB, gaji, NoCabang)

Staf (staffNo, fnama, lNamaPropertaForRent (propertyNo, jalan, kota, kode pos, jenis,

ruang,sewa, Nopemilik, Nostaff,NoCabang), posisi, seks, DOB, gaji, Nocabang)

Klien (Noklien, fnama, lnama, telNo, prefTipe, maxsewa)

PrivateOwner (ownerNo, fname, lname, alamat, telNo)

Viewing (clientNo, propertyNo, viewDate, comment)

Registration (clientNo, branchNo, staffNo, dateJoined)

Konvensi umum untuk mewakili skema relasi adalah memberikan nama relasidiikuti dengan nama atribut dalam

tanda kurung. Biasanya, kunci utamadigarisbawahi. 

Model konseptual atau skema konseptual, adalah himpunan semua skema tersebut untuk database. Gambar 3.3

menunjukkan sebuah contoh dari ini skema relasional.

4.3 Integritas Kendala

Pada bagian sebelumnya kita membahas bagian struktural dari model datarelasional. Sebagaimana

dinyatakan dalam Bagian 2.3, model data memiliki dua bagian lain: bagian manipulatif,
menentukan jenis operasi yang diperbolehkan pada data, dan satu set batasan integritas, yang memastikan
bahwa data tersebut akurat. Pada bagian ini kita membahas kendala integritasrelasional dan pada bab
berikutnya kita membahas operasi 

manipulasirelasional.
Kita telah melihat contoh dari kendala integritas dalam Bagian 3.2.1: karenasetiap
atribut memiliki domain terkait, ada kendala (disebut kendala domain) yang terbentuk

pembatasan pada set nilai diizinkan untuk atribut relasi. Selain itu, ada dua aturan integritas 

penting, yang merupakan kendala atau batasanyang berlaku untuk semua contoh database.

Dua aturan utama untuk model relasional dikenal sebagai integritas entitas dan integritas referensial. Jenis lain

dari kendala integritas adalah multiplisitas, yang kita bahas dalam Bagian11.6, dan kendala umum, yang kami
perkenalkan di Bagian 3.3.4. Sebelum kita mendefinisikan integritas entitas dan referensial, perlu untuk
memahami konsep nulls.

4.3.1 NULLS

Null Merupakan nilai untuk atribut yang saat ini tidak diketahui atau tidak berlaku

untuk tupel ini.

Nol dapat diartikan 'tidak diketahui' nilai logis. Hal ini dapat berarti bahwa nilai isnot berlaku

untuk tupel tertentu, atau itu hanya bisa berarti bahwa nilai belum ada disediakan. Nulls adalah cara
untuk menangani data tidak lengkap atau luar biasa. Namun, null adalah tidak sama dengan nilai angka nol
atau string teksdiisi dengan spasi; nol dan ruang adalah nilai-nilai, tetapi nol mewakili ketiadaannilai. Oleh
karena itu, nulls harus diperlakukan berbeda dari nilai-nilai lain.Beberapa penulis menggunakan 'nilai null'
istilah, namun sebagai null bukan nilaitetapi merupakan ketiadaan nilai, 'nilai null' istilah sudah ditinggalkan.

Misalnya, dalam hubungan Melihat ditunjukkan pada Gambar 3.3, atributkomentar mungkin

terdefinisi sampai penyewa potensial telah mengunjungi properti dan kembalinya komentar ke
agen. Tanpa nulls, menjadi perlu untuk memperkenalkan data palsu untuk mewakili negara ini atau untuk
menambahkan atribut tambahan yang mungkin tidak berarti bagi pengguna. Di contoh kita, kita dapat
mencoba untuk mewakili komentar null dengan nilai '-1'.Atau, kita dapat menambahkan atribut
baru hasCommentBeenSupplied untukhubungan Melihat, yang
berisi Y (Ya) jika komentar telah diberikan, dan N (Tidak) sebaliknya. Kedua pendekatan dapat
membingungkan bagi pengguna.
Nulls dapat menyebabkan masalah implementasi, yang timbul dari kenyataanbahwa model relasional
didasarkan pada urutan pertama kalkulus predikat, yang merupakan logikabernilai dua atau Boolean – yang
nilai hanya diperbolehkan adalah benar atau salah. Nulls Membiarkan berarti bahwa kita harus bekerja dengan
tinggi-nilai logika, seperti tiga atau empat-nilai logika (Codd, 1986, 1987, 1990).
Penggabungan nulls dalam model relasional adalah masalah yangdiperdebatkan. Codd kemudian
nulls dianggap sebagai bagian integral dari model (Codd, 1990). Lain menganggap pendekatan ini
menjadi sesat, percaya bahwa masalah informasi yang kurang tidak sepenuhnya dipahami, bahwa tidak ada
solusi yang memuaskan telah ditemukan dan, akibatnya,bahwa penggabungan tersebut
dari nulls dalam model relasional adalah prematur (lihat, misalnya, Tanggal,1995).
Kita sekarang dalam posisi untuk menentukan dua aturan integritas relasional.

4.3.2 Badan Integritas

Aturan integritas pertama berlaku untuk kunci utama dari hubungan dasar. Untuk saat ini,

kita mendefinisikan hubungan basis sebagai hubungan yang sesuai dengan entitas dalam skema konseptual

(lihat Bagian 2.1). Kami memberikan definisi yang lebih tepat dalam Bagian 3.4.
 Badan integritas  Dalam hubungan dasar, tidak ada atribut dari primary keydapat null.

Menurut definisi, primary key adalah identifier minimal yang digunakan untuk

mengidentifikasi tupel secara unik. Ini berarti bahwa tidak ada subset dari kunci primer cukup

untuk menyediakan identifikasi unik dari tupel. Jika kita membiarkan null untuk setiap bagian dari primary key,
kita menyiratkan bahwa tidak semua atribut yang diperlukan untuk membedakan antara tupel, yang
bertentangan dengan definisi dari kunci primer.

Misalnya, sebagai branchNoadalah kunci utama dari hubungan Cabang, kita seharusnya tidak dapat

memasukkan sebuah tuple ke dalam hubungan Cabang dengan null untuk atribut branchNo. Sebagai contoh
kedua, mempertimbangkan gabungan kunci utama dari relasi Viewing, yang terdiri dari jumlah klien (clientNo)
dan jumlahproperti (propertyNo).

Kita seharusnya tidak dapat memasukkan sebuah tupleke dalam hubungan Melihat dengan baik null

untuk atribut clientNo, atau null untuk atribut propertyNo, atau nulls untuk kedua
atribut.
Jika kita menguji aturan ini secara rinci, kita akan menemukan beberapa anomali Pertama,
mengapa aturan tersebut hanya berlaku untukkunci primer dan tidak lebih umum untuk candidate key, yang
jugamengidentifikasi tupel secara unik? Kedua, mengapa aturan

 terbatas padahubungan dasar? Sebagai contoh, menggunakan data dari relasi Melihat

ditunjukkan pada Gambar 3.3, perhatikan query, 'Daftar semua komentar daritampilan. Ini akan

menghasilkan relasi unary terdiri dari komentar atribut.Menurut definisi, atribut ini harus menjadi kunci
utama, tapi mengandung nulls (sesuai dengan tampilan pada PG36 

dan PG4 oleh klien CR56). Karenahubungan ini bukan hubungan dasar, model 

memungkinkan kunci utama untuk menjadi null. Ada beberapa upaya untuk mendefinisikan kembali aturan

ini (lihat,misalnya, Codd, 1988; Tanggal, 1990).

4.3.3 Integritas referensial

Aturan integritas kedua berlaku untuk kunci asing.

Intergritas referensial Jika kunci asing ada dalam hubungan , baik nilai kunci asing harus sesuai
dengan nilai candidate key dari beberapa tuple dalam kaitannya rumah atau
nilai foreign key harus sepenuhnya nol .

Sebagai contoh, cabang dalam hubungan Staf adalah kunci asing

menargetkan atribut cabang hubungan rumah, Cabang. Seharusnya tidakmungkin untuk membuat data staf
dengan jumlah cabang B025, misalnya, kecuali sudah ada rekor untuk jumlah cabang B025 dalam
hubungan Cabang.Namun, kita harus dapat membuat data

staf baru dengan sejumlah cabang null,untuk memenuhi situasi di mana anggota baru staf  telah bergabung

dengan perusahaan tetapi belum ditugaskan ke kantor cabang tertentu.
4.3.4 Kendala umum

Kendala umum Tambahan aturan yang ditetapkan oleh pengguna

atau administrator databasendatabase yang
mendefinisikan atau membatasi beberapa aspek dari perusahaan.

Hal ini juga mungkin bagi pengguna untuk menentukan batasan tambahanbahwa data harus

memenuhi. Misalnya, jika batas atas 20 telah ditempatkanpada jumlah staf yang dapat bekerja di

kantor cabang, maka pengguna harus dapat menentukan ini kendala umum dan

mengharapkan DBMS untuk menegakkannya. Dalam hal ini, seharusnya tidak mungkin untuk menambahkan

anggota baru staf di cabang diberikan kepada hubungan Staf jika jumlah

staf saat ini ditugaskan untuk cabang yang 20. Sayangnya, tingkat dukungan untuk kendala

umum bervariasi dari sistem ke sistem. Kami membahas pelaksanaan integritas relasional dalam Bab 6 dan 17.

4.4 Tampilan

Dalam arsitektur tiga tingkat ANSI-SPARC disajikan dalam Bab 2, kita menggambarkan pandangan eksternal

sebagai struktur database seperti yang muncul untuk pengguna tertentu. Dalam
model relasional, 'view' kata memiliki makna yang sedikit berbeda. Alih-alih
menjadi model eksternal seluruh pandangpengguna, maksud adalah hubungan virtual atau yang
diturunkan: hubunganyang tidak selalu ada dalam dirinya sendiri, tetapi dapat secara dinamis berasaldari
satu atau lebih relasi dasar. Dengan demikian, model eksternal dapat terdiri dari kedua relasi dasar (konseptual-
tingkat) dan pandangan yang berasal darihubungan dasar. Pada bagian ini, kita secara singkat membahas
pandangandalam sistem relasional. Pada Bagian 6.4 kita meneliti pandangan secara lebih rinci dan menunjukkan
bagaimana mereka dapat dibuat dan digunakan dalamSQL.

4.4.1 Terminology

Hubungan kami telah berurusan dengan begitu jauh dalam bab ini dikenal sebagai hubungan dasar.

Basis Hubungan Suatu relasi bernama sesuai dengan entitas dalam skema konseptual , yang tupel secara
fisik disimpan dalam database
Kita dapat menentukan pandangan dalam hal hubungan dasar

Tinjauan Hasil dinamis dari satu atau lebih operasi relasional yang beroperasi di pangkalan

hubungan untuk menghasilkan relasi lainnya. View View adalah relasi maya yang tidak
selalu ada dalam database tetapi dapat diproduksi atas permintaanoleh tertentu pengguna, pada
 saat permintaan.

View View adalah relasi yang muncul ke pengguna untuk ada, dapat dimanipulasi seolah

olah hubungan dasar, tetapi tidak selalu ada dipenyimpanan dalam arti bahwa hubungan dasar lakukan

(meskipun definisiyang disimpan dalam katalog sistem) . Isi pandang yang dimaksudkan sebagai
permintaan pada satu atau lebih relasi dasar. Setiap operasi pada tampilan tersebut akan secara
otomatis diterjemahkan ke dalam operasi pada hubungandari mana ia berasal. Tampilan yang dinamis, yang
berarti bahwa perubahan yang dibuat pada hubungan dasar yang mempengaruhi tampilan tersebut akansegera
tercermin dalam tampilan. Ketika pengguna melakukan perubahandiizinkan untuk melihat, perubahan ini dapat
dilakukan terhadap hubungan yang mendasarinya. Pada bagian ini, kami menjelaskan tujuan
pandangan dan secara singkat memeriksa pembatasan yang berlaku untukupdate dilakukan
melalui pandangan. Namun, kami menunda pengobatanbagaimana pandangan didefinisikan dan diproses
sampai Bagian 6.4.

4.4.2 Tujuan dari tinjaun

Mekanisme tampilan yang diinginkan karena beberapa alasan:

 Menyediakan mekanisme keamanan yang kuat dan fleksibel dengan menyembunyikan bagian dari

database dari pengguna tertentu. Pengguna tidak menyadari keberadaan atribut atau tupel yang hilang
dari tampilan.
  Hal ini memungkinkan pengguna untuk mengakses data dengan cara yang disesuaikan dengan
kebutuhan mereka, sehingga data yang sama dapat dilihatoleh pengguna yang berbeda dengan cara
yang berbeda, pada saat yang sama.
  Hal ini dapat menyederhanakan operasi kompleks pada hubungan dasar.
Misalnya, jika tampilan didefinisikan sebagai kombinasi (bergabung) dari dua relasi (lihat Bagian 4.1),
pengguna sekarang dapat performmore operasi sederhana pada tampilan, yang akan diterjemahkan oleh
DBMS ke dalam operasi setara pada bergabung.

Sebuah pandangan harus dirancang untuk mendukung model eksternal yangpengguna

menemukan akrab. Sebagai contoh:

 Seorang pengguna mungkin perlu tupel Cabang yang berisi nama-namamanajer serta atribut lainnya sudah

di Cabang. Pandangan ini dibuat dengan menggabungkan hubungan Cabang

 dengan bentuk terbatas hubungan Stafdimana posisi staf adalah 'Manajer'.  Beberapa anggota staf

harus melihat tupel Staf tanpa atribut gaji.
Atribut n dapat diganti namanya, atau urutan atribut berubah. Sebagai contoh,
pengguna terbiasa memanggil atribut branchNo cabang dengan Nomor Cabangnama lengkap mungkin
melihat kolom pos tersebut.
Beberapa anggota staf harus melihat catatan properti hanya untuk properti-properti yang mereka kelola.

Meskipun semua contoh ini menunjukkan bahwa maksud memberikan kemerdekaan logis data (lihat

Bagian 2.1.5), pandangan memungkinkan tipe yang lebih

signifikan dari independensi data logis yang mendukung reorganisasiskema konseptual.

 Misalnya, jika attributeis baru ditambahkan ke relasi,pengguna yang ada bias tidak

menyadari keberadaannya jika pandangan mereka didefinisikan untuk menghilangkannya

Jika hubungan yang ada diatur kembali atau berpisah, pandangan dapat didefinisikan

sehingga pengguna dapat terus melihat pemandangan aslinya. Kita akan melihat contoh

ini dalam Bagian 6.4.7 ketika kita membahas keuntungan dan kerugian dari pandangan

lebih terinci.

4.4.3 Memperbaharui tinjauan

Semua perubahan kepada hubungan dasar harus segera tercermin dalamsemua pandangan yang referensi bahwa

hubungan dasar. Demikian pula, jika pandangan

 diperbarui, maka hubungan dasar yang mendasari harusmencerminkan perubahan. Namun, ada

pembatasan pada jenis modifikasi yang dapat dibuat melalui pandangan. Kami mengambil
kesimpulan bawah kondisi di mana kebanyakan sistem menentukan apakah pembaruan tersebut diizinkan
melalui pandangan:

 Update diperbolehkan melalui pandangan didefinisikan menggunakan querysederhana yang

melibatkan hubungan basa tunggal dan mengandung baik kunciprimer atau kunci calon dari
relasi dasar.
 Update tidak diperbolehkan melalui pandangan yang melibatkan hubungandasar ganda.
 Update tidak diperbolehkan melalui pandangan melibatkan agregasi ataupengelompokan operasi.
Kelas pandangan yang telah ditetapkan yang secara teoritis tidak dapat diupdate, secara teoritis dapat diupdate,
dan sebagian diupdate. Sebuah surveitentang cara memperbarui pandangan relasional dapat ditemukan
di Furtadodan Casanova (1985).

RINGKASAN

 Sistem Manajemen Database Relasional (RDBMS) telah menjadi perangkat lunak pengolahan data
yang dominan digunakan saat ini, dengan perkiraan penjualan lisensi baru antara US $ 6 miliar dan US
$ 10 miliar per tahun (US $ 25 miliar dengan penjualan alat-alat termasuk). Software ini merupakan
generasi kedua dari DBMS dan didasarkan pada model data relasional diusulkan oleh EF Codd.
 Suatu relasi matematika adalah subset dari Cartesian produk dari dua atau lebih set. Dalam istilah
database, relasi adalah setiap subset dari Cartesian produk dari domain dari atribut. Suatu relasi
biasanya ditulis sebagai satu set n-tupel, di mana setiap elemen dipilih dari domain yang sesuai.
Hubungan n secara fisik direpresentasikan sebagai tabel, dengan baris sesuai dengan tupel individu dan
kolom untuk atribut.
 Struktur dari relasi, dengan spesifikasi domain dan kendala lainnya, adalah bagian dari kehebatan dari
database, sementara hubungan dengan semua tupel yang ditulis merupakan turunan atau perpanjangan
database.
 Sifat hubungan database: setiap sel berisi tepat satu nilai atom, nama-nama atribut nilai atribut yang
berbeda, berasal dari domain yang sama, urutan atribut tidak penting, urutan tuple tidak material, dan
 ada
yang tidak ada duplikat tupel.
 Tingkat relasi adalah jumlah atribut, sedangkan kardinalitas adalah jumlah tuple. Suatu relasi unary
memiliki satu atribut, hubungan biner memiliki dua, hubungan terner memiliki tiga, dan relasi n-ary
memiliki atribut n.
 Sebuah superkey adalah atribut atau himpunan atribut, yang mengidentifikasi tupel dari relasi unik,
sementara candidatekey adalah superkey minimal. Kunci utama adalah kunci kandidat yang dipilih
untuk digunakan dalam identifikasi tupel. Suatu relasi selalu harus memiliki kunci primer. Kunci asing
adalah atribut atau himpunan atribut, dalam satu relasi yang merupakan kunci kandidat relasi lain.
 Sebuah nol merupakan nilai atribut yang tidak diketahui pada saat ini atau tidak berlaku untuk tupel
ini. integritas Badan n merupakan kendala yang menyatakan bahwa dalam hubungan dasar tidak ada
atribut dari primary key dapat null. Referensial integritas menyatakan bahwa nilai-nilai kunci asing
harus sesuai dengan nilai calon kunci dari beberapa tuple dalam relasi rumah atau menjadi sepenuhnya
null. Selain integritas relasional, kendala integritas meliputi, data yang dibutuhkan, domain, dan
kendala banyaknya; batasan integritas lain disebut kendala umum.
 Tampilan dalam model relasional adalah hubungan virtual atau turunan yang dibuat secara dinamis dari
hubungan dasar yang mendasari (s) bila diperlukan.Tampilan memberikan keamanan dan
memungkinkan desainer untuk menyesuaikan model pengguna. Tidak semua pandangan ini dapat
diupdate.