Selasa, 05 Juni 2012

kontrol data semantik


Control Data Semantic
Sebuah alat yang penting bagi DBMS terpusat maupun terdistribusi, adalah kemampuan untuk mendukung kontrol dar i semantik data. (S emantik = makna dari bahasa, jika SQL maka: makna dari bahasa SQL).
Kontrol semantik data, umumnya terdiri dari (1) manajemen view, (2) control security, (3) kontrol semantik integritas .
Secara informal: Sis tem harus menjamin bahwa user yang berhak (author ized) akan melakukan operasi yang benar (correct) terhadap database, untuk menjaga integritas database.
Manajemen View
Salah satu keuntungan dari model relasional adalah: ia memberikan independensi data sepenuhnya secara logikal. Skema external akan mengijinkan user untuk memiliki view ter tentu dar i database.
Dalam sistem relasional, sebuah view adalah sebuah relasivir tual.
Definisi view: hasil (result) dari sebuah kueri terhadap relasi- relasi dasar (atau relasi real). Hasil (view) ini tidak disimpan dalam database seperti relasi dasar. Sebuah view adalah sebuah jendela dinamik, dalam artian bahwa ia mencerminkan semua update yang dilakukan terhadap database. Disamping pemakaiannya di dalam skema external, view juga berguna untuk menjamin data- security dengan cara yang sederhana. Dengan memilih subset dari database, view dapat menyembunyikan beberapa data.
Jika user mengakses database melalui view, mereka tak dapat melihat atau memanipulas i hidden-data; dengan demikian data akan menjadi secure.
Perhatikan bahwa, dalam sistem DBMS terdistribusi, sebuah view dapat diturunkan dari relasi- relasi terdistribusi. Akses ke sebuah view akan memer lukan eksekusi dari kueri terdistribusi yang berhubungan dengan definisi view ter sebut.
Isu penting dalam DBMS terdistribusi adalah untuk membuat materialisasi view dengan cara yang efisien. Kita akan melihat bagaimana konsep snapshot akan membantu dalam memecahkan masalah ini, tapi ter lebih dulu kita akan berkonsentrasi pada DBMS terpusat.
View dalam DBMS Terpusat
Dalam konteks ini, sebuah view adalah sebuah relasi yang diturunkan dari relasi relasi dasar , sebagai hasil dari sebuah kueri relasional.
View didefinis ikan dengan meng-asosiasikan nama dari view dengan query retrieval
(pengambilan data):
Contoh A :
View dari system-analyst (S YS AN) yang diturunkan dari relasi EMP(ENO, ENAME,
TITLE), dapat didefinisikan sebagai berikut dalam kueri SQL:
CREATE VIEW SYSAN(ENO, ENAME)
AS SELECT ENO, ENAME
FROM EMP
WHERE TITLE = “Syst. Anal.”
SYSAN
ENO
ENAME
E2
M.Smith
E5
B.Casey
E8
J.Jones
Tabel Relasi yang berhubungan dengan View SYSAN.
Dengan adanya view, maka yang akan disimpan adalah definisi view di dalam katalog. Dengan demikian, hasil dari kueri yang mendefinisikan view tersebut TIDAK akan diproduksi.
Meskipun demikian, view SYSAN dapat dimanipulasi sebagai sebuah relasi dasar .
Contoh B :
Kueri :
“Carilah nama-nama dari semua system-analyst dengan nomor proyek mereka serta pertanggungjawabannya.” akan melibatkan view SYSAN dan relasi ASG(ENO, PNO, RESP,DUR).
Dapat dinyatakan sebagai:
SELECT ENAME, PNO, RESP
FROM SYSAN, ASG
WHERE SYSAN.ENO = ASG.ENO
Dengan teknik ini:
Ø variabel-variabel diubah untuk dieksekusi terhadap relasi- relasi dasar ,
Ø dan kualifikasi kueri digabungkan (AND) dengan kualifikasi view.
ENO
ENAME
TITLE
E1
J. Doe
Elect.Eng.
E2
L. Chu
Elect.Eng.
Tabel. Hasil dari kueri terhadap view ENAME
Update melalui View
View dapat didefinisikan memakai kueri relas ional kompleks sembarang, yang melibatkan: selection, projection, join, aggregate- function, dan lain- lain.
Update melalui view dapat ditangani secara otomatis , hanya jika update terhadap view tersebut dapat dipindahkan menjadi update terhadap relasi dasar secara benar .
Kita dapat mengklasifikasikan view sebagai updatable dan not-updatable. Sebuah view adalah updatable, hanya jika update yang diterapkan terhadap view dapat dipindahkan menjadi update terhadap relasi dasar tanpa ambiguitas .
View SYSAN di atas adalah updatable. Sebagai contoh :
[ insertion dar i sys tem-analys t baru < 201, Smith> ]
akan dapat dipetakan menjadi
[ insertion pegawai baru < 201, Smith, S ys t. Anal.> ]
View berikut adalah not-updatable:
CREATE VIEW EG(ENAME, RESP)
AS SELECT ENAME, RESP
FROM EMP, ASG
WHERE EMP.ENO = ASG.ENO
Sebagai contoh, operasi delete dari tuple < Smith, Analys t> tidak dapat dipindahkan, karena akan menimbulkan ambiguitas .
Relasi yang berhubungan dengan view EG:
EG
ENAME
R E S P
J. Doe
Manager
M. Smith
Analys t
M. Smith
Analys t
A. Lee
Consultant
A. Lee
Engineer
J. Miller
Programmer
B. Casey
Manager
L. Chu
Manager
R. Davis
Engineer
J. Jones
Manager
Deletion terhadap M. Smith dalam relasi EMP (atribut EMP.ENAME) akan menimbulkan ambuguitas , karena ada dua tuple dalam view.
Demikian juga, deletion terhadap Analyst dalam relasi ASG (atribut ASG.RESP) akan menimbulkan ambiguitas .
Sistem yang ada sekarang, sangat restriktif dalam mendukung update melalui view.
View dapat di-update hanya jika mereka diturunkan dari sebuah relasi tunggal melalui selection atau projection.
Sistem akan menghindari view yang didefinisikan oleh join, aggregate-function, dan lainnya.
(Catatan: view yang diturunkan oleh join, dapat disebut updatable j ika mereka
mencakup key dar i relas i dasar .)
View dalam DBMS Terdistribusi
Definisi view dalam sistem terdistribusi sama dengan definisi view dalam system terpusat. Sebagai tambahan, view dalam sistem terdistribusi dapat diturunkan dari relasi-relasi terfragmentasi yang disimpan pada berbagai lokasi yang berbeda.
Ketika sebuah view didefinisikan, maka nama dan kueri retrieval akan disimpan di
dalam katalog.
Tergantung kepada derajad otonomi dari lokasi yang ditawarkan oleh sistem, maka definisi view dapat dipusatkan dalam satu lokasi, direplikasi secara parsial, atau sepenuhnya direplikasi.
Dalam setiap kasus , informasi yang menghubungkan nama dari view dengan lokasi penyimpan definisinya, harus direplikasi. Jika definisi view tidak ada pada lokasi di mana kueri diawali, maka akan diperlukan remote-access ke lokasi penyimpan definesi view.
Pemetaan dari kueri yang diekspresikan terhadap view menjadi kueri yang diekspresikan terhadap relasi dasar , (yang bisa dalam bentuk terfragmentasi), akan dapat juga dilakukan dengan cara yang sama seperti dalam sistem terpusat, yaitu melalui modifikasi kueri.
Dengan teknik ini, kualifikasi yang mendefinisikan view akan ditemukan dalam katalog database terdistribusi, dan kemudian akan digabungkan dengan kueri, untuk menghasilkan kueri terhadap relasi dasar .
Kueri ini merupakan kueri terdistribusi, yang dapat diproses oleh query-processor terdistribusi Sehingga guery-processor akan melakukan pemetaan dari kueri terdistribusi menjadi kueri terhadap fragmen-fragmen fisik.
Pada kenyataannya, definisi fragmentasi, sangat mirip dengan definisi view. Sebagai
contoh, view SYSAN (Contoh A.) dapat diimplementasikan oleh sebuah fragmen dalam lokasi tertentu. Di mana kebanyakan user mengakses view SYSAN pada lokasi tersebut.
View yang diturunkan dari relasi-relasi terdistribusi, dapat mengakibatkan biaya tinggi ketika dievaluasi. Karena dalam sebuah organisasi tertentu akan banyak user yang mengakses view yang sama, maka beberapa proposal telah dibuat untuk mengoptimisasi penurunan view.
Sebuah solusi alternatif disusun dalam [Adiba and Lindsay, 1980] untuk menghindari penurunan view dengan mempertahankan versi aktual (sebenarnya) dari view, yang
disebut snaps hot .
Sebuah snapshot menyatakan keadaan (state) tertentu dari database. Snapshot bersifat statik, artinya ia tidak merefleksikan update yang dilakukan terhadap relasi dasar .
Snapshot berguna ketika user tidak tertarik secara khusus untuk melihat versi terbaru dari database.
Snapshot diatur sebagai relasi-relasi temporer, dalam arti bahwa mereka hanya memiliki metode akses dengan cara sequential- scanning.
Dengan demikian, sebuah kueri yang diekspresikan terhadap sebuah snapshot, tidak akan memanfaatkan indeks-indeks yang tersedia untuk relasi dasar (snapshot diturunkan dari relasi dasar ini).
Akses melalui snapshot nampaknya lebih cocok untuk kueri-kueri yang memiliki seleksi yang buruk dan akan melakukan scan terhadap keseluruhan snapshot.
Dalam hal ini, sebuah snapshot akan ber tindak seperti sebuah jawaban terhadap kueri yang telah didefinisikan terlebih dulu (predefined).
Snapshot akan perlu direkalkulasi secara periodik. Hal ini dapat dilakukan ketika sistem sedang idle (berhenti sementara). Sebagai tambahan, untuk snapshot yang diturunkan dari selection dan projection, hanya difference yang perlu untuk direkalkulasi [Blakeley etal., 1986].
TRANSPARANSI PADA DDBMS
Merupakan pemisahan dari semantic level tingkat tinggi dari implementasi level rendah. Atau sistem transparansi menyembunyikan rincian implementasi dari user.
dbt1
Tidak mudah dalam menggambarkan tingkat transparansi yang jelas. Dengan adanya transparansi bahasa sebagai lapisan generik, membuat user memiliki akses terhadap data bertingkat tinggi (4th GL, GUI, akses bahasa natural, dll). Bentuk2 transparansi
Data independence Kebebasan data menjadi bentuk dasar transparansi yang terlihat di DBMS. Kebebasan data berarti kekebalan dari aplikasi user untuk mengubah definisi dan organisasi data dan sebaliknya. Definisi data dapat terjadi dalam 2 tahap. Pada satu level, struktur logika dari data dispesifikasikan (schema definition) dan pada level yang lain struktur fisik dari data didefinisikan (physical data description). Ada 2 tipe kebebasan data 1. Kebebasan data secara logic : kekebalan aplikasi user untuk mengubah struktur logika database. Secara umum, jika aplikasi user dioperasikan pada sebuah subset atribut relasi, tidak ada pengaruh yang terjadi jika atribut baru ditambahkan ke relasi yang sama. 2. Kebebasan data secara fisik : berhubungan dengan penyembunyian rincian struktur penyimpanan dari aplikasi user. Saat aplikasi user ditulis, rincian dari  organisasi data secara fisik tidak perlu diperhatikan. Organisasi data apa pun dapat dipakai.
Transparansi jaringan/ terdistribusi Dalam sistem terpusat, hanya satu sumber yang dipelihara user yaitu data (sistem penyimpanan). Dalam manajemen DB terdistribusi, ada sumber kedua yagn perlu dipelihara yaitu jaringan. User perlu dilindungi dari detail operasi jaringan. Tidak perlu ada perbedaan antara aplikasi database yang berjalan di DB terpusat dan DB terdistribusi. Akan baik jika memiliki keseragaman dalam operasi yang diakses. Jika ingin mengkopi sebuah file, perintah yang digunakan seharusnya sama untuk pengkopian dalam satu mesin atau antar mesin yang terhubung dengan jaringan. Sayangnya banyak OS untuk jaringan yang belum menyediakan transparansi ini. cp ; satu mesin rcp ; mesin berbeda Transparansi lokasi merupakan transparansi terhadap perintah yang bebas digunakan pada lokasi data maupun pada sistem dimana operasi berjalan. Transparansi penamaan (naming tranparancy) berarti nama yang unik diberikan ke setiap objek database. Caranya dengan menambahkan nama lokasi (identifier) sebagai bagian dari nama objek. Sistem yang bertanggungjawab memberikan penamaan terhadap objek agar menjadi unik.
Transparansi replikasi Data yang mudah diakses oleh user dapat ditempatkan pada mesin local user seperti mesin user lain dengan akses data yang sama. Jika satu mesin gagal, salinan data masih ada pada lokasi mesin yang lain dalam jaringan. Keputusan direplikasikan atau tidak, dan berapa banyak salinan dari objek database, bergantung pada tingkatan aplikasi user. Tetapi replikasi menyebabkan masalah dalam meng-update DB. Jika apllikasi user berorientasi pada update, sebaiknya tidak perlu ada banyak salinan data.
Transparansi fragmentasi Fragmentasi dapat mengurangi efek negatif dari repllikasi. Setiap salinan tidak merupakan salinan penuh tetapi hanya sebuah subset, jadi ruang yang dibutuhkan lebih sedikit dan item data lebih sedikit untuk dipelihara. Saat objek DB difragment, masalah menangani queri user timbul. Masalah menangani strategi memproses queri berdasarkan fragment dibandingkan relasi meskipun query dibuat kemudian. Bentuk translasi ini disebut sebagai query global ke beberapa query fragment.
Siapa yang menyediakan transparansi Penyediaan transparansi perlu melihat lapisan transparansi. Ada 3 lapisan transparansi yang berbeda yang dapat saling menguntungkan secara eksklusif dalam penyediaan service meskipun lebih sesuai untuk ditinjau sebagai tambahan. Tanggungjawab dalam menyediakan akses data yang transparan  adalah akses lapisan. Transparansi dimulai dari transparansi bahasa yang menterjemahkan service yang diminta ke operasi yang dibutuhkan. Compiler atau interpreter mengambil alih tugas dan tidak ada service transparan disediakan untuk compiler atau interpreter. Lapis kedua adalah transparansi di level sistem operasi. Penyediaan akses transparan ke sumber daya di level OS diperluas ke distribusi, dimana manajemen jaringan diambil alih oleh OS terdistribusi. Sayangnya tidak semua OS memiliki manajemen jaringan ini. Lapis ketiga ada pada DBMS. DBMS bertindak sebagai operasi yang terintegrasi dan sistem manajemen DB. Yang khas adalah pembuatan DBMS pada komputer generalpurpose yang berjalan di beberapa OS. Pada lingkungan ini, transparansi dan dukungan fungsi DB yang disediakan untuk perancang DBMS sangat minimal dan khas ke operasi dasar untuk menjalankan tugas khusus. DBMS bertanggungjawab untuk membuat semua translasi yang berarti dari OS ke interface user yang lebih tinggi.







Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 1
P ROGR AM S T UDI I LMU KOMPUT ER
FMI P A - U niver s itas Sanat a Dharma
S is tem Bas is Dat a T er dis t r ibus i
MODU L 8 Semant ic Dat a Cont r ol
Disusun oleh : S r i Har tati Wijono, S .S i. & A. Rita Widiar ti, S .S i.
S ebuah alat yang penting bagi DBMS terpusat maupun terdis tr ibus i, adalah
kemampuan untuk mendukung kontrol dar i semantik data. (S emantik = makna dar i
bahasa, j ika SQL maka: makna dar i bahas a SQL).
Kontrol semantik data, umumnya terdiri dari (1) manajemen view, (2) kontrol
secur ity, (3) kontrol semantik integr itas .
S ecara informal: S is tem harus menjamin bahwa user yang berhak (author ized) akan
melakukan operas i yang benar (cor rect) terhadap database, untuk menjaga integr itas
database.
Dalam modul ini, kita akan membahas solus i ter pusat bagi kontrol semantik data,
ser ta adanya beberapa masalah di dalam lingkungan terdis tr ibus i ser ta pemecahan
masalah ter sebut.
Dalam modul ini, kita menekankan pembahasan pada dampak dari manajemen
direktor i terhadap per formance dar i mekanisme kontrol semantik data.
8 .1 . Manajemen View
S alah satu keuntungan dar i model relas ional adalah: ia member ikan independens i
data sepenuhnya secara logikal. S kema external akan mengij inkan user untuk
memiliki view ter tentu dar i database.
Dalam s is tem relas ional, sebuah view adalah sebuah relas i vir tual.
Definis i view: has il (result) dar i sebuah kuer i terhadap relas i- relas i dasar (atau relas i
real). Has il (view) ini tidak dis impan dalam databas e seper ti relas i dasar .
S ebuah view adalah sebuah jendela dinamik, dalam ar tian bahwa ia mencerminkan
semua update yang dilakukan terhadap database.
Disamping pemakaiannya di dalam s kema external, view juga berguna untuk
menjamin data- secur ity dengan cara yang sederhana. Dengan memilih subset dar i
database, view dapat menyembunyikan beberapa data.
Jika user mengakses database melalui view, mereka tak dapat melihat atau
memanipulas i hidden-data; dengan demikian data akan menjadi secure.
Perhatikan bahwa, dalam s is tem DBMS terdistribusi, sebuah view dapat diturunkan
dar i relas i- relas i terdis tr ibus i. Akses ke sebuah view akan memer lukan eksekus i dar i
kuer i terdis tr ibus i yang berhubungan dengan definis i view ter sebut.
I su penting dalam DBMS terdistribusi adalah untuk membuat mater ialisas i view
dengan cara yang efis ien. Kita akan melihat bagaimana konsep snapshot akan
membantu dalam memecahkan masalah ini, tapi ter lebih dulu kita akan
berkonsentras i pada DBMS terpusat.
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 2
8 .1 .1 . View dalam DBMS T erpusat
Dalam konteks ini, sebuah view adalah sebuah relas i yang diturunkan dar i relas irelas
i dasar , sebagai has il dar i sebuah kuer i relas ional.
View didefinis ikan dengan meng-asos ias ikan nama dar i view dengan query retr ieval
(pengambilan data):
Contoh 8.1.
View dar i s ys tem-analys t (S YS AN) yang diturunkan dar i relas i EMP(ENO, ENAME,
T I T LE), dapat didefinis ikan sebagai ber ikut dalam kuer i SQL:
CREATE VIEW SYSAN(ENO, ENAME)
AS SELECT ENO, ENAME
FROM EMP
WHERE TITLE = "Syst. Anal."
S YSAN
ENO ENAME
E2 M.Smith
E5 B.Casey
E8 J.Jones
Gambar 8.1. Relas i yang berhubungan dengan View S YSAN.
Dengan adanya view, maka yang akan dis impan adalah definis i view di dalam
katalog. Dengan demikian, has il dar i kuer i yang mendefinis ikan view ter sebut T I DAK
akan diproduks i.
Mes kipun demikian, view S YS AN dapat dimanipulas i sebagai sebuah relas i dasar .
Contoh 8.2.
Kuer i :
"Car ilah nama-nama dar i semua sys tem-analys t dengan nomor proyek mereka
ser ta per tanggungjawabannya."
akan melibatkan view S YS AN dan relas i ASG(ENO, PNO, RES P, DUR).
Dapat dinyatakan sebagai:
SELECT ENAME, PNO, RESP
FROM SYSAN, ASG
WHERE SYSAN.ENO = ASG.ENO
Dengan teknik ini:
Ø var iabel-var iabel diubah untuk dieksekus i terhadap relas i- relas i dasar ,
Ø dan kualifikas i kuer i digabungkan (AND) dengan kualifikas i view.
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 3
Contoh 8.3.
Kuer i dalam contoh 8.2. dapat dimodifikas i menjadi:
SELECT ENAME, PNO, RESP
FROM EMP, ASG
WHERE EMP.ENO = ASG.ENO
AND TITLE = "Syst. Anal."
Has il dar i kuer i ini dilukis kan dalam Gambar 8.2.
ENAME PNO R E S P
M.Smith P1 Analys t
M.Smith P2 Analys t
B.Casey P3 Manager
J.Jones P4 Manager
Gambar 8.2. Has il dar i kuer i yang melibatkan View S YSAN
Kuer i termodifikas i pada contoh 8.3. akan diekspres ikan terhadap relas i- relas i dasar ,
sehingga dapat diproses oleh query-proces sor .
Penting untuk memperhatikan, bahwa view-proces s ing dapat dilakukan pada saat
compile- time.
Mekanisme view dapat juga dipakai untuk melakukan penghalusan (refine) terhadap
kontrol akses dengan tujuan untuk mencakup s ubset dar i object. Untuk menentukan
setiap user dengan hidden-data ter tentu, maka dipakai keyword US ER, untuk
mengacu identifier dar i user pada saat log-on.
Contoh 8.4.
View ES AME akan membatas i akses dar i setiap user hanya ke data pegawai yang
memiliki jabatan (T I T LE) yang sama.
CREATE VIEW ESAME
AS SELECT *
FROM EMP E1, EMP E2
WHERE E1.TITLE = E2.TITLE
AND E1.ENO = USER
S ebagai contoh, kuer i ber ikut ini akan dilakukan oleh user J. Doe:
SELECT *
FROM ESAME
akan menghas ilkan relas i dalam Gambar 8.3. Perhatikan bahwa, user J. Doe j uga
muncul dalam has il ter sebut. Jika user yang membuat ESAME adalah seorang
electr ical-engineer , seper ti dalam contoh ini, maka view akan menyatakan set dar i
semua electr ical-engineer .
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 4
ENO ENAME T I T L E
E1 J. Doe Elect. Eng.
E2 L. Chu Elect. Eng.
Gambar 8.3. Has il dar i kuer i terhadap view ESAME
8 .1 .2 . Update melalui View
View dapat didefinis ikan memakai kueri relas ional kompleks sembarang, yang
melibatkan: selection, projection, join, aggregate- function, dan lain- lain.
Update melalui view dapat ditangani secara otomatis , hanya j ika update terhadap
view ter sebut dapat dipindahkan menjadi update terhadap relas i dasar secar a benar .
Kita dapat mengklas ifikas ikan view sebagai updatable dan not-updatable. S ebuah
view adalah updatable, hanya j ika update yang diterapkan terhadap view dapat
dipindahkan menjadi update terhadap relas i dasar tanpa ambiguitas .
View S YS AN di atas adalah updatable. S ebagai contoh :
[ inser tion dar i sys tem-analys t baru < 201, Smith> ]
akan dapat dipetakan menjadi
[ inser tion pegawai baru < 201, Smith, S ys t. Anal.> ]
View ber ikut adalah not-updatable:
CREATE VIEW EG(ENAME, RESP)
AS SELECT ENAME, RESP
FROM EMP, ASG
WHERE EMP.ENO = ASG.ENO
S ebagai contoh, operas i delete dar i tuple < Smith, Analys t> tidak dapat dipindahkan,
karena akan menimbulkan ambiguitas .
Relas i yang berhubungan dengan view EG:
EG
ENAME R E S P
J. Doe Manager
M. Smith Analys t
M. Smith Analys t
A. Lee Consultant
A. Lee Engineer
J. Miller Programmer
B. Casey Manager
L. Chu Manager
R. Davis Engineer
J. Jones Manager
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 5
Deletion terhadap M. Smith dalam relas i EMP (atr ibut EMP.ENAME) akan menimbulkan
ambuguitas , karena ada dua tuple dalam view.
Demikian juga, deletion terhadap Analys t dalam relas i AS G (atr ibut ASG.RES P) akan
menimbulkan ambiguitas .
S is tem yang ada sekarang, sangat res tr iktif dalam mendukung update melalui view.
View dapat di-update hanya j ika mereka diturunkan dar i sebuah relas i tunggal melalui
selection atau projection.
S is tem akan menghindar i view yang didefinis ikan oleh join, aggregate- function, dan
lainnya.
(Catatan: view yang diturunkan oleh join, dapat disebut updatable j ika mereka
mencakup key dar i relas i dasar .)
8 .1 .3 . View dalam DBMS T erdist r ibus i
Definis i view dalam s is tem terdis tr ibus i sama dengan definis i view dalam s is tem
terpusat. S ebagai tambahan, view dalam s is tem terdis tr ibus i dapat diturunkan dar i
relas i- relas i ter fragmentas i yang dis impan pada berbagai lokas i yang berbeda.
Ketika sebuah view didefinis ikan, maka nama dan kuer i retr ieval akan dis impan di
dalam katalog.
T ergantung kepada derajad otonomi dar i lokas i yang ditawar kan oleh s is tem, maka
definis i view dapat dipusatkan dalam satu lokas i, direplikas i secara par s ial, atau
sepenuhnya direplikas i.
Dalam setiap kas us , informas i yang menghubungkan nama dar i view dengan lokas i
penyimpan definis inya, harus direplikas i. Jika definis i view tidak ada pada lokas i di
mana kuer i diawali, maka akan diper lukan remote-acces s ke lokas i penyimpan definis i
view.
Pemetaan dari kueri yang diekspres ikan terhadap view menjadi kueri yang
diekspres ikan terhadap relas i dasar , (yang bis a dalam bentuk ter fragmentas i), akan
dapat juga dilakukan dengan cara yang sama seper ti dalam s is tem terpusat, yaitu
melalui modifikas i kuer i.
Dengan teknik ini, kualifikas i yang mendefinis ikan view akan ditemukan dalam
katalog databas e terdis tr ibus i, dan kemudian akan digabungkan dengan kuer i, untuk
menghas ilkan kuer i terhadap relas i dasar .
Kuer i ini merupakan kuer i terdis tr ibus i, yang dapat diproses oleh query-proces sor
terdis tr ibusi S ehingga guery-proces sor akan melakukan pemetaan dari kuer i
terdis tr ibus i menjadi kuer i terhadap fragmen- fragmen fis ik.
Pada kenyataannya, definis i fragmentas i, sangat mir ip dengan definis i view. S ebagai
contoh, view S YS AN (Contoh 8.1.) dapat diimplementas ikan oleh sebuah fragmen
dalam lokas i ter tentu. Di mana kebanyakan user mengakses view S YS AN pada lokas i
ter sebut.
View yang diturunkan dar i relas i- relas i terdis tr ibus i, dapat mengakibatkan biaya tinggi
ketika dievaluas i. Karena dalam sebuah organisas i ter tentu akan banyak user yang
mengakses view yang sama, maka beberapa proposal telah dibuat untuk mengoptimisas
i penurunan view.
S ebuah solus i alternatif disusun dalam [Adiba and Lindsay, 1980] untuk menghindar i
penurunan view dengan memper tahankan ver s i aktual (sebenarnya) dar i view, yang
disebut s naps hot .
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 6
S ebuah snapshot menyatakan keadaan (s tate) ter tentu dari database. S napshot
ber s ifat s tatik, ar tinya ia tidak merefleks ikan update yang dilakukan terhadap relas i
dasar .
S napshot berguna ketika user tidak ter tar ik secara khus us untuk melihat ver s i
terbaru dar i database.
S napshot diatur sebagai relas i- relas i temporer, dalam ar ti bahwa mereka hanya
memiliki metode akses dengan car a sequential- scanning.
Dengan demikian, sebuah kuer i yang diekspres ikan terhadap sebuah snapshot, tidak
akan memanfaatkan indeks - indeks yang ter sedia untuk relasi dasar (snapshot
diturunkan dar i relas i dasar ini).
Akses melalui snapshot nampaknya lebih cocok untuk kuer i - kuer i yang memiliki
seleks i yang buruk dan akan melakukan scan terhadap keseluruhan snapshot.
Dalam hal ini, sebuah snapshot akan ber tindak seper ti sebuah jawaban terhadap
kuer i yang telah didefinis ikan ter lebih dulu (predefined).
S napshot akan per lu direkalkulas i secara per iodik. Hal ini dapat dilakukan ketika
s is tem sedang idle (berhenti sementara). S ebagai tambahan, untuk snapshot yang
diturunkan dari selection dan projection, hanya difference yang per lu untuk
direkalkulas i [Blakeley et al., 1986].
8 .2 . Data-secur it y
Data- secur ity merupakan fungs i penting dar i s is tem bas is data yang melindungi data
dari akses unauthor ized (yang tidak ter -otor isas i). Data- secur ity mencakup dua
aspek: data-protection dan author ization-control.
Data-protection diper lukan untuk mencegah unauthor ized-user mengetahui is i fis ik
dar i data. Fungs i ini umumnya disediakan oleh s is tem file dalam konteks sis tem
operas i terpusat maupun terdis tr ibus i.
Pendekatan utama data-protection adalah melakukan enkr ips i data. Enkr ips i akan
berguna, baik untuk informas i yang dis impan dalam dis k, maupun untuk per tukaran
informas i lintas jar ingan.
Data terenkr ips i (encoded, encrypted) dapat di-dekr ips i (decoded, decrypted) hanya
oleh author ized-user (yang mengetahui kode-nya).
Dua s kema utama adalah:
Ø DES (Data Encr yption S tandard).
Ø Public- key encryption.
Dalam bab ini, kita akan berkonsentras i pada aspek kedua dar i data- secur ity, yaitu
author ization-control.
Author ization-control harus menjamin: hanya author ized-user yang dapat melakukan
operas i yang diij inkan terhadap bas is data.
DBMS , baik terpusat maupun terdis tr ibus i, harus menerapkan batasan akses oleh
user terhadap database.
Dalam s is tem file, author ization-control disediakan oleh s is tem operas i terdis tr ibus i
sebagai service dari s is tem file. Dalam konteks ini, akan dilakukan oleh sebuah
kontrol terpusat. Kontroler pusat akan membuat object, dan user ter tentu akan
diij inkan melakukan operas i read, wr ite, execute terhadap object ini. Object akan
diidentifikas i dengan memakai nama external-nya.
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 7
Author ization-control dalam s is tem databas e berbeda dengan yang di dalam s is tem
file, dalam beberapa aspek. Otor isas i harus diperhalus , sehingga user yang berbeda
akan memiliki hak yang berbeda terhadap object databas e yang sama.
Kebutuhan ini akan berakibat dalam:
Ø kemampuan menentukan object secara lebih tepat, tidak hanya sekedar
melalui nama.
Ø dapat membedakan kelompok-kelompok user .
Dalam s is tem terdis tr ibus i, penting untuk melakukan desent r alisas i terhadap
author ization-control.
8 .2 .1 . Aut hor izat ion-cont r ol T er pusat
T iga aktor utama yang ter libat dalam author ization-control:
Ø User yang memicu eksekus i program aplikas i.
Ø Operas i, yang berada dalam program aplikas i.
Ø Object database, yang merupakan sasaran operas i.
Author ization-control berupa: mekanisme checking apakah tr iple (user, operas i,
object) ter tentu dapat diij inkan untuk terus . Yaitu, apakah user boleh mengeksekus i
operas i terhadap object.
S ebuah otor isas i dapat dipandang sebagai tiga hal:
Ø User .
Ø T ipe operas i.
Ø Definis i object database.
Otor isas i merupakan proses yang menetapkan: apakah user memiliki hak untuk
melakukan tipe operas i ter tentu terhadap sebuah definis i object database.
Untuk mengontrol otor isas i, DBMS akan memer lukan data berupa: user , object, dan
hak (r ight).
U ser
I dentifikas i user (orang atau grup) umumnya dilakukan oleh s is tem dalam bentuk
sepasang data (user -name dan pas sword). Pas sword akan merupakan authentication
bagi user .
Kedua data ter sebut (nama dan pas sword) harus tersedia untuk melakukan log- in ke
dalam s is tem. Hal ini akan mencegah orang yang tidak mengetahui pas sword untuk
mengakses s is tem dengan hanya memakai nama user .
Object
Object untuk dilindungi merupakan subset dar i database.
Dalam sebuah s is tem file, individu yang diproteks i adalah file. S edangkan dalam
DBMS individu yang diproteks i adalah tipe dar i object (misalnya: record, file).
Dalam s is tem relas ional, object dapat didefinis ikan oleh :
Ø T ipe object (view, relas i, tuple, atr ibut), atau
Ø I s i dar i object, yang didapat memakai selection terhadap predikat ter tentu.
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 8
Mekanisme view dar i 8.1. akan mengij inkan proteks i object secara sederhana, yaitu
dengan menyembunyikan subset dari relasi (atr ibut atau tuple) terhadap
unauthor ized-user .
Hak / R ight
S ebuah hak (hak akses ), menyatakan hubungan antara user dengan object untuk set
operas i ter tentu.
Dalam DBMS relasional yang memakai SQL, operas i ini merupakan high- levels
tatement seper ti S ELECT , I NS ERT , UPDAT E, atau DELET E. Hak akses akan
didefinis ikan (diber ikan atau dibatalkan) memakai s tatement:
GRANT <operation type(s)> ON <object> TO <user(s)>
REVOKE <operation type(s)> FROM <object> TO <user(s)>
Untuk menyatakan semua user , dapat dipakai keyword public.
Author ization-control dapat dibedakan pada s iapa (grantor ) yang member ikan sebuah
hak (grant).
Ø Dalam bentuk paling sederhana, kontrol dilakukan terpusat: yaitu oleh s ingle-user
atau user -clas s sebagai adminis trator database, yang memiliki semua pr ivilege
terhadap semua object database. I a adalah satu- satunya yang diij inkan untuk
memakai s tatement GRANT dan REVOKE.
Ø Bentuk kontrol lain yang lebih kompleks , tapi lebih fleks ibel, adalah desentralisas i
kontrol. Pembuat object akan menjadi pemiliknya, dan memiliki semua pr ivilege di
atas object ter sebut.
Dalam hal ini, akan ada tipe operas i GRANT tambahan: Member ikan pr ivilege
GRANT , berar ti bahwa semua hak dar i sang pember i (grantor ) untuk melakukan
s tatement ter tentu, akan diber ikan kepada user ter tentu.
Dengan demikian, user yang mener ima hak, dapat kemudian member ikan
pr ivilege terhadap object yang dimilikinya kepada user lain. Misalnya, A
member ikan pr ivilege ter tentu kepada B, kemudian B akan member ikan pr ivelege
yang sama kepada C.
Kesulitan utama dari pendekatan ini adalah, proses revoke, harus dilakukan
rekur s if. Misalnya, A member ikan pr ivilege kepada B terhadap object O, kemudian
B member ikan pr ivelege yang sama kepada C. Kemudian, A ingin membatalkan
(revoke) semua pr ivilege yang telah diber ikan kepada B atas O. Maka semua
pr ivilege yang diber ikan oleh B kepada C atas O, juga harus dibatalkan. Untuk
melakukan revoke, maka s is tem harus membuat sebuah hirarki dar i grant per
object. S ebagai root dar i hirarki ini adalah creator (yaitu A).
Pr ivilege dar i subject terhadap object akan dis impan dalam katalog (direktor i) sebagai
author ization- rules (aturan-aturan otor isas i). Ada beberapa cara untuk menyimpan
otor isas i.
Pendekatan paling umum adalah dengan menganggap semua pr ivilege sebagai
sebuah matr iks otor isas i. Di mana, sebuah bar is akan mendefinis ikan subject, dan
kolom akan mendefinis ikan object. Entr i matr iks yang berupa pasangan < subject,
object> , akan merupakan otor isas i terhadap operas i.
Operas i otor isas i ditentukan oleh tipe operas inya (misal, S ELECT , UPDAT E). Bis a j uga
tipe operas i memakai predikat, yang kemudian akan membatas i akses ke object.
Predikat dipakai dalam kasus , di mana object harus berupa relas i dasar , dan tidak
dapat berupa view. S ebagai contoh, operas i otor isas i untuk pasangan < Jones , relas i
EMP> dapat berupa:
S ELECT WHERE T I T LE = "S yst. Anal."
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 9
yang akan melakukan otor isas i terhadap Jones , untuk hanya boleh mengakses tuple
pegawai untuk sys tem-analys t.
Gambar 8.4. menunjukkan contoh matr iks otor isas i, di mana object dapat berupa
relas i (EMP dan ASG) atau atr ibut (ENAME).
EMP ENAME ASG
Casey UPDAT E UPDAT E UPDAT E
Jones S ELECT S ELECT S ELECT
WHERE RES P ¹ "Manager "
Smit h NONE S ELECT NONE
(Bar is = subject ; kolom = object ; entr i = < subject, object> = otorisasi operas i)
Gambar 8.4. Contoh Matr iks Otor isas i.
8 .2 .2 . Aut hor izat ion-cont r ol T er dis t r ibus i
Dalam lingkungan terdis tr ibus i, mekanisme author ization-control dapat diturunkan
dar i mekanisme dalam s is tem terpusat. S eper ti dijelas kan sebelumnya, akan ada
tambahan kompleks itas , karena object dan user /subject dapat terdis tr ibus i.
Masalah-masalah baru yang muncul: otentifikas i terhadap remote-user , manajemen
dar i aturan otor isas i terdis tr ibus i, ser ta penanganan view dan penanganan grup user .
Otent if ikas i terhadap r emote-user diper lukan, karena setiap lokas i dalam DBMS
terdis tr ibus i dapat mener ima program awal, dan kemudian di-otor isas i pada remotes
ite.
Untuk mencegah remote-acces oleh unauthor ized-user , (misal, dar i lokas i yang bukan
bagian dar i DBMS terdistribusi), user harus juga diidentifikas i dan diotentifikas i pada
lokas i yang diakses nya.
Ada dua solus i:
1. I nformas i untuk user (user -name dan pas sword) direplikas i pada semua lokas i
yang ada dalam katalog. Program lokal, tetapi yang diawali pada remote- s ite,
juga harus menunjukkan user -name dan pas sword.
2. S emua lokas i dalam DBMS terdistribusi, melakukan identifikas i dan otentifikas i
terhadap lokas i- lokas i yang ada, dengan cara yang sama seper ti user . Dengan
demikian, komunikasi antar lokasi akan diproteksi dengan pemakaian s itepas
sword.
Misal, user akan mengakses lokas i B secara remote dar i lokas i A (lokal). Lokas i B
akan memandang user sebagai remote-user . Jika lokas i yang melakukan inis ias i
(A) telah diotentifikas i oleh lokas i B (remote), maka lokas i B tidak per lu lagi
melakukan otentifikas i terhadap user .
S olusi per tama lebih mahal biayanya, karena j ika ada user baru yang per lu
didaftarkan, maka user baru harus didaftarkan secara terdis tr ibus i. T etapi, dengan
solus i ini, semua user akan dapat mengakses database terdis tr ibus i dar i lokas i
manapun.
S olus i kedua tidak memer lukan replikas i informas i user. S olus i ini akan membuat
remote-authentification lebih efis ien. Jika user -name dan pas sword tidak direplikas i,
maka mereka hanya dis impan di dalam lokas i di mana user mengakses s is tem (yaitu
home- s ite). S olus i ini memakai asums i s tatik, yaitu mengasums ikan bahwa user
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 10
selalu mengakses dar i lokas i yang sama. Dengan demikian, kelemahannya adalah
user tidak dapat mengakses dar i sembarang lokas i.
Manajemen aturan otor isas i terdis t r ibus i:
Aturan-aturan otor isas i terdis tr ibus i dinyatakan dengan cara yang sama seper ti dalam
s is tem terpusat. Misalnya, definis i view harus dis impan di dalam katalog.
Ada dua kemungkinan penyimpanan aturan-aturan otor isas i ini:
Ø Direplikasi seluruhnya dalam setiap lokas i. Keuntungannya: otor isasi dapat
diproses dengan modifikas i kuer i pada saat compile- time. Kerugian: manajemen
direktor i/katalog akan lebih mahal biayanya, karena duplikas i data.
Ø Dis impan hanya pada lokas i- lokas i yang memer lukan referens i terhadap object.
Dengan kata lain, aturan hanya akan diduplikas i pada lokas i- lokas i di mana object
ter sebut terdis tr ibus i. Keuntungannya: Solus i ini akan lebih baik, j ika lokalitas
referens i sangat tinggi. Kerugiannya: otor isas i terdis tr ibus i tidak dapat dikontrol
pada saat compile- time (harus pada saat run- time).
8 .3 . Kont r ol S emant ik I ntegr itas
S atu masalah penting dan sulit dalam s is tem databas e adalah: menjamin kons is tens i
database.
Untuk memper tahankan kons is tens i database, memer lukan bermacam mekanisme
seper ti: kontrol concur rency, reliability, proteks i, dan kontrol semantik integr itas .
Kontrol semantik integr itas akan menjamin kons is tens i databas e dengan:
Ø Menolak update program, yang akan membawa databas e ke dalam keadaan
inkons is ten. Atau,
Ø Mengaktifkan aks i ter tentu, yang akan mengkompensas i efek dar i program
update terhadap database.
Databas e yang di-update harus memenuhi integr ity-cons traints .
8 .3 .1 . Kont r ol S emant ik I ntegr itas T erpusat
S ubs is tem semantik integr itas memiliki dua komponen utama:
Ø Bahasa untuk mengekspres ikan dan memanipulasi integr ity-as ser tion
(pernyataan integr itas ).
Ø Mekanisme as ser tion yang akan melakukan aks i ter tentu untuk memaksakan
integr itas databas e pada saat dilakukan update.
Kita dapat membedakan tiga tipe batasan integr itas : predefined, precompiled, atau
general.
Contoh-contoh untuk batasan integr itas di bawah, akan diber ikan untuk databas e
dengan s kema:
EMP(ENO, ENAME, T I T LE)
PROJ(PNO, PNAME, BUDGET )
ASG(ENO, PNO, RES P, DUR)
B atasan pr edef ined didasarkan kepada keyword sederhana. Ber ikut adalah contohcontoh
beberapa batasan dar i model relas ional, dengan memakai batasan predefined.
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 11
Contoh 8.5. Nonnull Atr ibute
Nomor pegawai (ENO) dalam relas i EMP tidak boleh null.
ENO NOT NULL IN EMP
Contoh 8.6. Unique Key
Pasangan (ENO, PNO) adalah unique- key dalam relas i ASG.
(ENO, PNO) UNIQUE IN ASG
Contoh 8.7. Foreign Key
Nomor proyek PNO dalam relas i AS G adalah foreign- key yang match dengan
pr imary- key PNO dalam relas i PROJ. Dengan kata lain, sebuah proyek yang
ada dalam relas i AS G harus ada di dalam relas i PROJ.
PNO IN ASG REFERENCES PNO IN PROJ
Contoh 8.8. Functional Dependency
Nomor pegawai ENO s ecar a fungs ional menentukan nama pegawai ENAME.
ENO IN EMP DETERMINES ENAME
B atasan pr ecompiled dapat dinyatakan dengan s tatement SQL: CHECK, ditambah
spes ifikas i tipe update. Untuk tipe update ter tentu: Batasan precompiled akan
menyatakan prakondis i yang harus dipenuhi oleh semua tuple di dalam relas i.
S yntax dar i s tatement CHECK:
CHECK ON <relation name> WHEN <update type>
( < qualification over relation name> )
Contoh batasan precompiled:
Contoh 8.9. Domain Cons traint
Budget dar i sebuah proyek ter letak antar a 500K dan 1000K.
CHECK ON PROJ (BUDGET ³ 500000 AND BUDGET £ 1000000)
Contoh 8.10. Domain Cons traint on Deletion
Hanya tuple yang budget-nya 0 boleh di-delete.
CHECK ON PROJ WHEN DELETE (BUDGET = 0)
Contoh 8.11. T rans ition Cons traint
Budget dar i sebuah proyek hanya boleh dinaikkan.
CHECK ON PROJ (NEW.BUDGET > OLD.BUDGET
AND NEW.PNO = OLD.PNO)
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 12
B atasan gener al adalah rumus - rumus kalkulus relas ional tuple, di mana semua
var iable dikuantifikas i. S is tem database harus menjamin bahwa semua rumus
ter sebut selalu benar .
Batasan general lebih r ingkas dar ipada batasan precompiled, karena dapat
melibatkan lebih dar i satu relas i.
S ebagai contoh, paling sedikit akan diper lukan tiga batasan precompiled untuk
menyatakan satu batasan general atas tiga relas i.
Batasan general dapat dinyatakan dengan s yntax ber ikut:
CHECK ON list of <variable name> : <relation name> ,
(<qualification>)
Contoh-contoh:
Contoh 8.12. Functional Dependency
Batasan dar i contoh 8.8. :
Nomor pegawai ENO s ecar a fungs ional menentukan nama pegawai ENAME.
dapat dinyatakan dengan:
CHECK ON e1:EMP, e2:EMP
(e1.ENAME = e2.ENAME IF e1.ENO = e2.ENO)
Contoh 8.13. Cons traints with Aggregate Function
Duras i total dar i semua pegawai dalam proyek CAD adalah kurang dar i 100.
CHECK ON g:ASG, j:PROJ (SUM(g.DUR WHERE g.PNO=j.PNO) <
100
IF j.PNAME = "CAD/CAM")
P ENE R APAN I NT EGR I T AS ( I NT EGR I T Y E NFOR CEMENT )
Penerapan semantik integr itas berupa: menolak program-program update yang
melanggar batasan-batasan integr itas .
S ebuah batasan dilanggar, j ika keadaan database yang baru yang dihas ilkan oleh
update menjadi false.
Dua metoda dasar untuk mengij inkan penolakan update yang inkons is ten:
Ø Berdasarkan pada deteks i inkons is tens i.
o Update u dieksekus i,
o Akan menyebabkan perubahan keadaan databas e dar i D menjadi Du.
o Algor itma penerapan batasan (cons traints enforcement), akan melakukan
ver ifikas i: dengan menerapkan tes yang diturunkan dar i batasan integr itas .
o T es dilakukan untuk mendeteks i, apakah semua batasan yang relevan
tetap ada di dalam keadaan Du.
o Jika keadaan Du inkons is ten, DBMS dapat mencoba salah satu dar i:
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 13
§ Mencapai keadaan kons is ten yang lain: D'u, dengan melakukan
modifikas i Du memakai compensating-action.
§ Mengembalikan keadaan D, dengan melakukan undo terhadap u.
(kembali ke keadaan awal)
o Karena tes ini dilakukan setelah keadaan databas e berubah, maka disebut:
pos ttes t.
o Pendekatan ini dapat menjadi tidak efis ien, j ika sej umlah besar update D
harus di-undo, dalam hal adanya kegagalan integr itas .
Ø Berdasarkan pada pencegahan (prevention) inkons is tens i.
o Update hanya akan dieksekus i, j ika ia mengubah database ke keadaan
kons is ten.
o T uple yang menjadi subyek update dapat: tersedia langs ung dalam
database (dalam I NS ERT ), atau harus diambil dari database (dalam
DELET E atau MODI FY).
o Algor itma penerapan akan melakukan ver ifikas i: apakah semua batasan
yang relevan akan tetap ada setelah update terhadap tuple.
o Hal ini dilakukan dengan menerapkan tes kepada tuple. T es diturunkan
dar i batasan integr itas .
o Karena tes ini dilakukan sebelum keadaan database berubah, maka
disebut: pretes t.
o Pendekatan preventif ini lebih efis ien, karena update tidak per lu di-undo
j ika ter jadi pelanggaran integr itas .
Algor itma modif ikasi kuer i [S tonebraker, 1975], adalah sebuah contoh dar i
metoda preventif yang efis ien dalam menerapkan batasan domain.
Metoda ini akan menambahkan kualifikas i as ser tion kepada kualifikas i kuer i dengan
operator AND, sehingga kuer i termodifikas i dapat memaksakan integr itas :
Contoh 8.14.
Kuer i untuk menaikkan budget dar i proyek CAD/CAM dengan 10% , dinyatakan oleh:
UPDAT E PROJ
S ET BUDGET = BUDGET * 1.1
WHERE PNAME = "CAD/CAM"
akan ditrans formas ikan menjadi kuer i ber ikut, dengan tujuan untuk memaksakan
batasan domain yang dibahas dalam contoh 8.9.
Budget dar i sebuah proyek ter letak antar a 500K dan 1000K.
UPDAT E PROJ
S ET BUDGET = BUDGET * 1.1
WHERE PNAME = "CAD/CAM"
AND NEW.BUDGET ³ 500000
AND NEW.BUDGET £ 1000000
Algor itma modifikas i kuer i, yang dikenal karena elegan, menghas ilkan pretes t pada
saat run- time dengan melakukan operas i AND antara predikat as ser tion dengan
predikat update dar i setiap ins truks i transaks i.
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 14
Contoh 8.15:
Pernyataan foreign- key dar i contoh 8.7. dapat ditulis kan kembali sebagai:
Nomor proyek PNO dalam relas i AS G adalah foreign- key yang match dengan
pr imary- key PNO dalam relas i PROJ. Dengan kata lain, sebuah proyek yang
ada dalam relas i AS G harus ada di dalam relas i PROJ.
" g Î ASG, $ j Î PROJ : g.PNO = j .PNO
Pernyataan as ser tion ini tidak dapat diproses oleh modifikas i kuer i, karena var iabel j
tidak dikuantifikas i secar a univer sal ($ = eksistensial).
8 .3 .2 . Kont r ol S emant ik I ntegr itas T erdis t r ibus i
Dalam pasal ini kita membahas algor itma untuk menjamin integr itas semantik dar i
databas e terdis tr ibus i. Algor itma ini merupakan per luasan dar i metode yang dibahas
sebelum ini.
Asums inya : ada otonomi lokas i, yang berar ti setiap lokas i memproses kuer i lokal dan
melakukan kontrol data sebagai sebuah DBMS terpusat. Hal ini akan menyederhakan
pembahasan.
DE F I NI S I DARI I NT EGR I T Y-AS S ER T I ON T E R DI S T R I B U S I .
S ebuah as ser tion dapat dilihat sebagai sebuah kualifikas i kuer i yang dapat bernilai
true atau false untuk setiap tuple dalam produk Car tes ian antara relas i- relas i yang
ditentukan oleh var iable tuple.
Karena as ser tion dapat melibatkan data yang dis impan pada lokas i- lokas i yang
berbeda, penyimpanan mereka harus ditentukan supaya dapat meminimalkan biaya
untuk pengecekan integr itas .
Ada s trategi yang didasar kan kepada taksonomi dar i integr ity-as ser tion. S trategi ini
membedakan tiga kelas as ser tion:
1. I ndividual-as ser tion: yaitu as ser tion dengan relasi tunggal dan var iabel
tunggal. T uple- tuple yang di-update tidak tergantung kepada tuple- tuple
lainnya. Misalkan batasan domain dalam contoh 8.9. merupakan sebuah
individual-as ser tion:
Budget dar i sebuah proyek ter letak antar a 500K dan 1000K.
CHECK ON PROJ (BUDGET ³ 500000 AND BUDGET £ 1000000)
= = = >Hanya ada satu relas i (PROJ) dan satu var iabel (BUDGET ).
2. S et-or iented as ser tion. Yaitu as ser tion yang mencakup:
a. Batasan relas i tunggal dengan multi-var iabel. Misalnya: functionaldependency
dalam contoh 8.8.:
Nomor pegawai ENO s ecara fungs ional menentukan nama pegawai
ENAME.
ENO I N EMP DET ERMI NES ENAME
= = = > Satu relas i: EMP. Multi var iabel: ENO, ENAME.
b. Batasan multi- relas i dan multi-var iabel. Misalnya batasan foreign- key
dalam contoh 8.7.:
Nomor proyek PNO dalam relas i AS G adalah foreign- key yang match
dengan pr imary- key PNO dalam relas i PROJ. Dengan kata lain, sebuah
proyek yang ada dalam relas i AS G harus ada di dalam relas i PROJ.
PNO I N AS G REFERENCES PNO I N PROJ
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 15
= = = >Multi relas i: ASG, PROJ. Multi var iabel: ASG.PNO, PROJ.PNO
3. As ser tion yang melibatkan aggregate: Memer lukan pemrosesan khusus ,
karena biaya untuk mengevaluas i aggregate. Misalnya, as ser tion dar i contoh
8.13. :
Duras i total dar i semua pegawai dalam proyek CAD adalah kurang dar i 100.
CHECK ON g:ASG, j :PROJ (S UM(g.DUR WHERE g.PNO= j .PNO) < 100
I F j .PNAME = "CAD/CAM" )
= = = >Melibatkan aggregate- function yaitu S UM().
Ketika ter jadi integr ity-as ser tion yang baru, maka definis i dar i as ser tion ter sebut
dapat mulai dibuat pada salah satu lokas i yang menyimpan relas i- relas i yang ter libat
dalam as ser tion.
Fragmen yang berbeda dari relas i yang sama dapat ber lokas i pada lokas i yang
berbeda. S ehingga, membuat definis i dar i integr ity-as ser tion akan menjadi operas i
terdis tr ibus i. Operas i ini terdir i dar i dua langkah:
Ø Melakukan trans formasi high- level-as ser tion menjadi compiled-as ser tion.
(Memakai teknik yang dibahas dalam pasal 8.3.1.)
Ø Menyimpan compiled-as ser tion sesuai dengan kelasnya (1, 2 atau 3).
As ser tion dar i kelas 3 akan diper lakukan seper ti kelas 1 atau 2, tergantung
apakah mereka individual atau set-or iented.
I ndividual as ser t ion. Definis i dar i as ser tion akan dikir imkan ke semua lokas i yang
ber is i fragmen- fragmen relas i yang dilibatkan dalam as ser tion.
As ser tion harus kompatibel dengan data relas i pada setiap lokas i. Kompatibilitas
dapat dicek pada dua level: Level predikat dan level data.
Ø Kompatibilitas pada level predikat: diver ifikas i dengan cara: membandingkan
predikat as ser tion dengan predikat fragmen. S ebuah as ser tion C tidak
kompatibel dengan predikat fragmen p, j ika " C true" berakibat " p false" . Dan
akan kompatibel dalam semua keadaan lainnya.
Jika satu lokasi menemukan ada yang tidak kompatibel, maka definis i
as ser tion akan ditolak secara global (semua s is tem), karena tuple dar i
fragmen ter sebut tidak memenuhi batasan integr itas .
Ø Kompatibilitas pada level data: Jika kompatibilitas predikat telah disepakati,
maka as ser tion akan dites melawan data (ins tance) dar i fragmen. Jika tidak
kompatibel, maka as ser tion juga akan ditolak pada tingkat global.
Jika kompatibilitas telah ditemukan, maka as ser tion akan dis impan pada setiap lokas i.
Perhatikan bahwa cek terhadap kompatibilitas hanya untuk compiled-as ser tion yang
tipe update-nya adalah inser tion (yaitu tuple- tuple dalam fragmen dianggap
dis is ipkan).
Contoh 8.18.
Misalkan relas i EMP, ter fragmentas i hor isontal pada tiga lokas i memakai predikat:
p1: 0 # ENO < "E3"
p2: " E3" # ENO # " E6"
p3: ENO > "E6"
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 16
dan domain dar i as ser tion C: ENO < "E4" .
As ser tion C :
kompatibel dengan p1 (j ika C true, p1 true),
kompatibel dengan p2 (j ika C true, p2 tidak selalu false),
tidak kompatibel dengan p3 (j ika C true, p3 false).
Dengan demikian, maka as ser tion C akan ditolak secara global, karena tuple pada
lokas i 3 tidak dapat memenuhi C, dan relas i EMP tidak memenuhi C.
S et -or iented as ser t ion. As ser tion ini multi-var iabel, yaitu mereka melibatkan
predikat join. Meskipun predikat as ser tion dapat multi- relas i (atau bisa j uga relas i
tunggal), sebuah compiled-as ser tion diasos ias ikan dengan relas i tunggal.
Dengan demikian, definisi as ser tion akan dikir imkan ke semua lokasi yang
menyimpan fragmen- fragmen yang di- referens ikan oleh multi-var iable ini.
Pengecekan kompatibilitas juga akan melibatkan fragmen- fragmen dar i relas i yang
dipakai dalam predikat join.
Kompatibilitas predikat akan tidak berguna di s ini, karena tidak mungkin untuk
menar ik kes impulan bahwa predikat p adalah false, j ika as ser tion C (didasarkan pada
predikat join) adalah true.
Dengan demikian, C harus dicek pada level data. Cek kompatibilitas ini akan
memer lukan operas i join antara setiap fragmen dar i relas i R, dengan semua fragmen
dar i relas i lainnya S . Yaitu, yang ter libat dalam predikat as ser tion.
Operas i join ini dapat berbiaya mahal, dan juga akan memer lukan optimisas i oleh
query-proces sor terdis tr ibus i.
Ada tiga kas us yang mungkin ter jadi:
1. Fragmentas i dari R diturunkan dari S , berdasarkan pada semij oin. Yaitu
semijoin pada atr ibut yang dipakai dalam predikat join as ser tion.
2. S difragmentas i pada atr ibut join.
3. S tidak difragmentas i pada atr ibut join.
Ketiga kas us ini, sesuai urutannya semakin mahal biaya dalam melakukan
pengecekan kompatibilitas .
Dalam kasus per tama, pengecekan kompatibilitas cukup murah karena [tuple S yang
matching dengan tuple R] akan berada pada lokas i yang sama.
Dalam kasus kedua, setiap tuple R harus dibandingkan dengan paling banyak satu
fragmen dar i S , karena nilai atr ibut join dar i tuple R dapat dipakai untuk mencar i
lokas i S yang ber is i fragmen yang berhubungan.
Dalam kasus ketiga, setiap tuple dar i R harus dibandingkan dengan semua fragmen
dar i S .
Jika kompatibilitas ditemukan untuk semua tuple R, maka as ser tion akan dis impan
pada setiap lokas i.
E NFOR CEMENT DAR I I NT EGR I T Y-AS S ER T I ON T E R DI S T R I B U S I .
Penerapan dar i integr ity-as ser tion terdis tr ibus i akan lebih kompleks dar ipada yang di
dalam DBMS terpusat. Malasah utama adalah untuk memutuskan: di dalam lokas i
mana akan dilakukan penerapan integr ity-as ser tion.
Disusun oleh : Sri Hartati Wijono, S.Si. & A. Rita Widiarti, S.Si. Hal 17
S olus inya akan tergantung kepada :
Ø kelas dar i as ser tion,
Ø tipe dar i operas i update,
Ø query-mas ter - s ite, yaitu lokas i yang melakukan operas i update.
Kita akan membahas tipe kelas yang berbeda.
I ndividual as ser t ion.
Ada dua kas us :
Ø Jika update merupakan s tatement I NS ERT , maka semua tuple yang akan
dis is ipkan berasal dar i user . Dalam kasus ini, semua as ser tion individual dapat
dipaks a untuk diterapkan pada lokas i di mana update dilakukan.
Ø Jika update merupakan update terkualifikas i (s tatement DELET E atau MODI FY),
maka penerapan as ser tion akan dilakukan (dikir im) ke : lokas i- lokas i yang
menyimpan relas i yang akan di-update.
Query-proces sor akan melakukan eksekus i terhadap kualifikas i update untuk
setiap fragmen.
T uple- tuple yang dihas ilkan pada setiap lokas i akan dikombinas ikan menjadi :
Ø satu relas i temporer , dalam hal DELET E, atau
Ø dua relas i temporer, dalam hal MODI FY, yaitu R+ (ber is i tuple yang
dis is ipkan ke R) dan R-(ber is i tuple yang dihapus dar i R).
S etiap lokas i yang ter libat dalam update terdis tr ibus i ini, akan memaksakan
penerapan as ser tion yang relevan.
R ingkasan Kont rol I ntegr itas T erdis t r ibus i:
Masalah utama dar i kontrol integr itas terdis tr ibus i adalah, biaya pemrosesan dan
biaya komunikas i yang mahal untuk menerapkan as ser tion terdis tr ibus i.
Dua is u utama dalam merancang s ubs is tem integr itas terdis tr ibus i adalah:
Ø Membuat definis i dar i as ser tion terdis tr ibus i.
Ø Algor itma penerapan (enforcement).
Di mana keduanya harus meminimalkan biaya untuk pengecekan integr itas
terdis tr ibus i.
Kontrol integr itas terdis tr ibus i dapat dicapai secara lengkap, dengan memper luas
metoda preventive dengan berdasarkan kepada kompilas i semantik dar i integr ityas
ser tion. (compiled-as ser tion).
Metoda ini kompatibel dengan definis i fragmen, dan akan meminimalkan biaya
komunikas i antar lokas i.
Penerapan integr itas terdis tr ibus i akan memiliki per formance yang lebih baik, j ika
fragmen- fragmen didefinis ikan dengan hati-hati. Dengan demikian, spes ifikas i dar i
batasan (cons traints ) integr itas terdis tr ibus i merupakan aspek penting dalam proses
perancangan databas e terdis tr ibus i.