DATA AND ACCESS CONTROL

TUGAS
UNTUK MEMENUHI TUGAS MATAKULIAH
Basis Data Terdistribusi
yang dibimbing oleh Triyanna Widyaningtyas

Oleh Kelompok 2 :
Khafidurrohman Agustianto
Khoirudin Asfani
Khusnul Qotimah 100533402568
Khusnul Khotimah 100533402606
Laitya Nindita Sahenda
Lia Nur enis Wijayanti

PTI OFFERING C

UNIVERSITAS NEGERI MALANG

FAKULTAS TEKNIK
JURUSAN TEKNIK ELEKTRO
PRODI S1 PENDIDIKAN TEKNIK INFORMATIKA
April 2013
 DATA AND ACCESS CONTROL

Persyaratan penting dari centralize atau DBMS terdistribusi adalah kemampuan untuk
mendukung pengendalian semantik data, yaitu data dan akses kontrol menggunakan semantik
tingkat tinggi .Semantik data kontrol biasanya meliputi manajemen tampilan, kontrol
keamanan, dan semantik integritas kontrol. Secara informal, fungsi-fungsi ini harus
memastikan bahwa pengguna berwenang melakukan operasi yang benar pada database,
memberikan kontribusi bagi pemeliharaan Database integrity. Dalam relasional kerangka
kerja, semantik data kontrol dapat dicapai dengan cara seragam. Views, keamanan kendala,
dan kendala integritas semantik dapat didefinisikan sebagai aturan sistem yang secara
otomatis memaksa. Pelanggaran terhadap beberapa aturan oleh program pengguna
(seperangkat operasi database) pada umumnya mengandung arti penolakan terhadap efek dari
program yang (misalnya, melepas update-nya) atau menyebarkan beberapa efek (misalnya,
memperbarui data yang terkait) untuk menjaga integritas database.
Definisi aturan untuk mengendalikan manipulasi data merupakan bagian dari
administrasi database, fungsi umumnya dilakukan oleh administrator database (DBA).
Administrator ini juga bertugas menerapkan kebijakan organisasi. Solusi untuk semantik
data kontrol telah diusulkan untuk centralizedDBMSs. Dalam bab ini ditinjau secara singkat
solusi terpusat untuk data semantik kontrol, dan menyajikan masalah-masalah khusus yang
dihadapi dalam lingkungan yang didistribusikan dan solusi masalah ini. Biaya yang
ditetapkan data semantic control, tinggi dalam hal pemanfaatan sumber daya dalam DBMS
terpusat, bisa menjadi penghalang dalam lingkungan terdistribusi.
Karena aturan untuk kontrol data semantik harus disimpan dalam sebuah katalog,
managemen dari direktori terdistribusi (juga disebut katalog). Direktori dari DBMS
terdistribusi sendiri merupakan basis data terdistribusi. Ada beberapa cara untuk menyimpan
Data semantik kontrol definitions, sesuai dengan cara direktori dikelola. Direktori Informasi
dapat disimpan berbeda sesuai dengan jenisnya, dengan kata lain, sebagian informasi dapat
direplikasi sepenuhnya sedangkan informasi lain mungkin didistribusikan. Misalnya,
informasi yang berguna pada waktu kompilasi, seperti kontrol keamanan informasi, dapat
direplikasi. Dalam bab ini ditekankan dampak dari manajemen direktori atas kinerja
mekanisme data semantik kontrol.
6.1 VIEW MANAGEMENT

Salah satu yang paling mendasar dan penting dari relasional model adalah
menciptakan atau membuat full logical data independent. Seperti pada skema eksternal yang
memungkinkan group user memiliki view database tersendiri. Dalam sistem relasional view
merupakan relasi virtual atau dengan kata lain view adalah hasil dari query dalam relasional
database. Tapi tidak diberi material seperti halnya basis data pada umumnya yang disimpan
dalam database. View merupakan antarmuka dinamik yang merepresentasikan semua update
database. Sedangkan skema eksternal dapat disebut juga dengan view dan/atau relasional
database. Selain digunakan dalam skema eksternal, view juga sangat berguna untuk
pengamanan data secara mudah. Dengan melakukan seleksi pada subset di database, view
dapat menyembunyikan beberapa data. Sehingga apabila ada user yang mengakses database
melalui view, user tidak bisa melihat atau memodifikasi data yang disembunyikan, oleh
karena itu jelas penggunaan view dapat digunakan sebagai pengamanan database.
Ketika melakukan management view pada database terpusat maupun database
terdistribusi sangat memungkinkan terjadinya masalah dalam update view. Perlu dicatat pada
DBMS terdistribusi, view dapat diperoleh dari relasi yang terdistribusi dan untuk mengakses
kebutuhan view dalam hal eksekusi query terdistribusi dihubungkan dengan view definition.
Penting untuk diketahui dalam DBMS terdistribusi, terdapat isu tentang efisiensi material
yang digunakan. Untuk membantu mengatasi masalah ini dapat menggunakan konsep
snapshots. Oleh karena itu akan dibahas menganai DBMS terpusat.

6.1.1 View pada DBMSs Terpusat

Kebanyakan relasional DBMS menggunakan mekanisme view INGRES (Stonebraker,
1976) dan System R (Chamberlin et al. 1976). Dalam konteks ini view didapat dari database
relasional sebagai hasil database dari query relasional. Sehingga view harus menuliskan nama
table asal yang terkait dengan querynya secara spesifik.
Contoh:
View dari system analis (SYSAN) yang diperoleh dari relasional EMP
(ENO.ENAME.TITLE) sebagaimana dijelaskan dalam sintax SQL di bawah:
6.1 View Management
SYSAN

Table 6.1 Hubungan Korespondensi untuk tabel SYSAN

ENO ENAME
E2 M. Smith
E6 B. Casey
E8 J-Jones

CREATE VIEW SYSAN (ENO, ENAME)

AS SELECT ENO, ENAME
FROM EMP
WHERE TITLE = “Syst. Anal.”

Satu-satunya yang disimpan dalam memori dalam membuat view adalah nama dari
view dari itu sendiri, tanpa ada informasi lain yang perlu disimpan. Untuk itu Query yang
mendefinisikan tabel (relasi yang dimiliki oleh atribut ENO dan ENAME untuk sistem analis
ditunjukkan oleh gambar 6.1) tidak di produksi. Tetapi, tabel SYSAN dapat dimanipulasi
sebagai base relation.

Contoh 6.2 Query :

“Temukan nama dari semua sistem analis dengan masing-masing project number dan
responsibility(ies)”

Tabel SYSAN dan hubungan ASG(ENO, PNO, RESP, DUR) dapat di ekspresikan sebagai :

SELECT ENAME, PNO, RESP

FROM SYSAN, ASG
WHERE SYSAN.ENO = ASG.ENO

Pemetaan dari query yang diekspresikan dari tabel menjadi pemetaan query
diekspresikan pada gambaran ke yang dapat diekspresikan dengan query pada hubungan
dasar yg dapat dilakukan dengan memodifikasi query. Dengan teknik ini, variabel diubah
dalam range pada base relation dan query qualification di merge/di gabung dengan view
qualification.

Contoh 6.3 Query yang sebelumnya dapat dimodifikasi menjadi:

 SELECT ENAME, PNO, RESP
FROM EMP, ASG
WHERE EMP.ENO = ASG.ENO
AND TITLE = “Syst.Anal.”

Tabel 6.3 Hasil dari query diatas dapat digambarkan sebagai berikut:
ENAME PNO RESP
M.Smith P1 Analyst
M.Smith P2 Analyst
B.Casey P3 Manager
J.Jones P4 Manager

Query yang telah dimodifikasi dinyatakan pada baris relasi dan oleh karena itu dapat
diproses oleh pemroses query (query processor). Hal yang penting adalah memperhatikan
bahwa pemrosesan view (view processing) telah dapat dilaksanakan pada saat compile time
nya. Mekanisme tampilan dapat juga digunakan untuk menyaring kontrol akses yang
termasuk pada subsets object nya. Untuk menentukan spesifikasi user dari siapa yang ingin
menyembunyikan data, kata kunci USER secara umum menunjuk pada pengenal user yang
sedang log on.

Contoh 6.4 Tampilan dari ESAME yang membatasi hak akses oleh beberapa user pada
pegawai-pegawai tersebut memiliki judul yang sama:

CREATE VIEW ESAME

AS SELECT *
FROM EMP E1, EMP E2
WHERE E1.TITLE = E2.TITLE
AND E1.ENO = USER

Pada definisi tampilan di atas, tanda * yang terdiri untuk “seluruh atribut” dan 2
variabel tupel (E1 dan E2) dengan rentang lebih dari EMP diperlukan untuk menunjukkan
gabungan 1 tupel dari EMP (satu yang cocok dengan user log on) dengan seluruh tupel dari
EMP yang berpedoman pada judul atau nama yang sama. Contoh: query di bawah ini yang
dihasilkan oleh pengguna PROJ.Doe,
 SELECT *
FROM ESAME

Kembali pada relasi dari contoh (gambaran) 6.3, perhatikan user PROJ.Doe juga muuncul
pada hasilnya. Jika pengguna yang menciptakan ESAME adalah insinyur listrik seperti pada
kasus ini, tampilan menggambarkan seluruh hal yang berhubungan dengan kelistrikan.

Table 6.3 Hasil dari query ESAME

PNO ENAME RESP

E1 J. Doe Elect. Eng
E2 L. Chu Elect. Eng

Views dapat didefinisikan menggunakan query relasional kompleks berubah-ubah

yang melibatkan proyeksi seleksi, join, fungsi agregat, dan sebagainya. Semua views bisa
diselidiki sebagai base relation, tetapi tidak semua views dapat dimanipulasi seperti itu.
Update melalui view dapat ditangani secara otomatis hanya jika mereka dapat diperbanyak
dengan benar ke base relationnya. Kita dapat mengklasifikasikan views sebagai yang dapat
diupdate dan tidak dapat diupdate. Suatu view dapat diupdate hanya jika update ke view
dapat disebarkan ke base relation tanpa adanya ambiguitas. View dari SYSAN di atas
termasuk yang dapat diupdate: melalui Insertion, misalnya, seorang analis sistem baru <201.
Smith> akan dipetakan ke dalam penyisipan karyawan baru <201.Smith. Syst. Anal.>. Jika
atribut selain TITLE disembunyikan oleh View, mereka akan ditetapkan sebagai nilai null.
View berikutnya, bagaimanapun, tidak dapat diupdate:

CREATE VIEW EG (NAME, RESP)

AS SELECT ENAME, RESP
FROM EMP, ASG
WHERE EMP.ENO = ASG.ENO
Deletion, misalnya, tupel <Smith. Analyst> tidak dapat diperbanyak. Karena akan terjadi
ambigu. Penghapusan Smith di relasi EMP atau analyst dalam relasi ASG keduanya
bermakna. Namun sistem tidak tahu mana yang benar.
Sistem saat ini sangat ketat tentang mendukung pembaruan melalui Views. Views
dapat diupdate hanya jika mereka berasal dari relasi tunggal dengan seleksi dan proyeksi. Hal
ini menghalangi Views didefinisikan oleh join. Dan seterusnya. Namun, secara teori mungkin
untuk mendukung pembaruan otomatis dari kelas besar Views ([Bancilhon dan Spyratos.
1981] [Dayal dan Bernstein. 1978].. [Keller 1982.]). Sangat menarik untuk dicatat bahwa
Views yang diperoleh diperoleh dari join dapat diupdate jika memasukkan kunci-kunci base
relation.

6.1.2 Views in Distributed DBMSs

Definisi view dalam sistem DBNS 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 query 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 query diawali, maka akan diperlukan remote-access ke lokasi penyimpan
definesi view.
Pemetaan dari query yang diekspresikan terhadap view menjadi query 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
query.Dengan teknik ini, kualifikasi yang mendefinisikan view akan ditemukan dalam katalog
database terdistribusi, dan kemudian akan digabungkan dengan query, untuk menghasilkan
query terhadap relasi dasar .Query ini merupakan query terdistribusi, yang dapat diproses
oleh query-processor terdistribusi Sehingga guery-processor akan melakukan pemetaan dari
query terdistribusi menjadi query terhadap fragment-fragment fisik.
Pada kenyataannya, definisi fragmentasi, sangat mirip dengan definisi view. Sebagai
contoh, view SYSAN 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 query 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 query-query yang memiliki
seleksi yang buruk dan akan melakukan scan terhadap keseluruhan snapshot.
Dalam hal ini, sebuah snapshot akan ber tindak seperti sebuah jawaban terhadap query 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].