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.

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.