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.
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.
