Anda di halaman 1dari 5

Lingkungan Relasi

Pendahuluan
Bahasa SQL yang didefinisikan pada chapter sebelumnya cukup untuk aplikasi user tunggal. Ini
mengizinkan basisdata untuk diisi dengan data, data tersebut diambil sesuai dengan kebutuhan.
Lingkungan multi user membutuhkan fasilitas yang lebih. Mereka menghendaki support untuk
berbagi data antara user dan seorang user untuk merubah struktur basisdata tanpa
mempengaruhi user yang lain. Mereka seharusnya juga mengizinkan user untuk menguji
struktur data degan mengakses sistem katalog. Chapter ini mendeskripsikan bagaimana SQL
menyediakan dukungan seperti itu.

Berbagi Data (Data Sharing)


Berbagai data mempunya dua tujuan. Satu tujuan datang dari prinsip lama berbagi data. Prinsip
ini menyatakan bahwa user yang memabagi data hanya dapat mengkases bagian basisdata
yang mereka butuhkan untuk tugas khusus. Mereka seharusnya tidak mengases bagian
basisdata yang bukan menjadi perhatian mereka. Kebutuhan untuk prinsip tersebut cukup
jelas. Basisdata yang besar mungkin berisi semua data dalam suatu organisiasi secara virtual. Ini
mungkin berisi catatan pribadi, permintaan supplier, dan sebagainya. Dalam lingkungan yang
demikian orang bertanggung jawab untuk, katakanla, menyeiapkan pesanan, tidak
membutuhkan akses untuk record pribadi. Sama halnya, orang yang berkenaan dengan record
pribadi tidak membutuhkan akses kepda data permintaan. Kemampuan akses, tentu saja,
mungkin dibagi atas tingkat yang lebih baik. Sebagai contoh, misalkan sesorang seharusnya
dapat mengkeses jumlah order tapi bukan harga, atau orang lain boleh akses alamat tapi bukan
riwayat kesehatan.
Tujuan lain adalah user seharusnya dapat melihat data dalam bentuk yang lebih
menyenangkan untuk mereka dan bukan dalam bentuk yang dipaksakan oleh pengguna lain.
Contoh yang lebih jelas berkenaan dengan penyebaran data dalam sejumlah tabel. Lebih
menyenangkan untuk melihat semua ini dalam satu tabel. Data retrival jauh lebih baik, karena
user tak perlu lagi pusing dengan join dan sebagainya.
SQL mendukung berbagi data melalui view. Idea dibalik view diilustrasikan dalam
Gambar 14.1. disini basis data dibuat oleh sejumlah relasi penyimpan data. Ini adalah relasi
yang didefinisikan selama proses racangan dan dibuat dengan perintah CREATE yang tersedia
dalam SQL. Basisdata juga menyediak sejumlah view. View ini mucul sebagai tabel untuk user
tetapi mereka bukanlah tabel yang disimpan. View adalah tabel yang tidak disimpat tapi tabel
yang diturukan dari tabel yang disimpan.
User dapat mengakses data dalam penyimpanan basisdata melalui view. Mereka
mengunakan bahasa SQL yang sama untuk mengakses view sebagai bahasa yang digunakan
untuk mengakses relasi penyimpan. Akan tetapi, sebarang perintah SQL yang merucuk pada
view diterjemahkan untuk memerintahkan pada tabel penyimpanan. Untuk alasan ini view
kadang-kadang disebut dengan relasi (tabel) virtual. Mereka secara logic dapat diakses user
tetapi tidak disimpa sebagai basisdata fisik.
View dapat juga digunakan untuk mengontrol akses data. Jika seorang user diberikan
akses utnuk sebuah view, maka user tersebut hanya dapat melihat informasi yang tersedia
pada view. View tersebut dapat juga digunakan untuk mengontrol akses ke basisdata.
Administrator basisdata dapat membuat view yang hanya beriksna data yang dibutuh oleh user
untuk keperluan tugas mereka.

Gambar 14.1 Menghasilkan View

View Tabel

Menterjemahkan
tabel penyimpanan ke
tabel view

Tabel penyimpan

Pendefinisian View
View didefinisikan menggunakan pernyataan SQL. Pernyataan definisi view dibuat dengan dua
bagian berikut:

CREATE VIEW <nama view>(<nama kolom>…<nama kolom>) AS <pernyataan SQL>


Bagian pertama adalah klausa CREATE VIEW. Ini mendefinisikan nama tabel view dan
atributnya. Bagian kedua adalah pernyataan SELECT. Pernyataan SELECT yang didefinsikan pada
Chapter sebelumnya dapat digunakan untuk mendefinisikan view. Pada definisi tersebut, nama
kolom dalam klausa SELECT pernyatan SQL berkorespondensi dengan nama kolom dalam view.
Sederhananya adalah view didefinisikan sebagai subset dari sebuah relasi.

View sebagai subses dari sebuah Relasi


Disini pernyataan select memilih sebuah subset dari baris dan kolom yang muncul dalam
sebuah view. Sebagai contoh, sebuah view yang mengizinkan akses pada semua kebutuhan
dibuat oleh projek ‘pr1’ didefinisikan sebagai berikut:

CREATE VIEW PROJ1-REQUESTS(REWUST DATE-WANTED,WHERE-WANTED)


AS SELECT REQ-NO, DATE-NEEDED, WHERE-NEEDED
FROM REQUESITIONS
WHERE PROJ-NO =’pr1’

View iniditunjukan dalam gambar 14.2. ini hanya memuat baris dalam tabel REQUISTIONS
dengan PROJ-NO sama dengan ‘pr1’. Kolom projek tidak mucul dalam view tabel PROJ1-
REQUESTS dan tabel ini hanya mempunyai tiga kolom, REQ-NO, DATE-NEEDED, dan WHERE-
NEEDED, yang dinamakan ulang REQUEST, DATE-WANTED, dan WHERE-WANTED dalam view.
Kolom REQUEST dalam vies PROJ1-REQUESTS berkorespondesi dengan kolom REQ-NO dalam
relasi REQUISTIONS, dan kolom DATE-WANTED dalam view PROJ1-REQUESTS berkorespondesi
dengan kolom DATE-NEEDED dalam relasi REQUEISTIONS, dan seterusnya.
Informasi dari sebuah view dapat diambil dalam cara yang sama dalam bentuk relasi
dasar. Dengan demikian semua daftar permintaan dibuat oleh projek ‘PR1’ dapat diambil
dengan pernyataan:
SELECT * FROM PROJ1-REQUESTS
Gambar 14.2 View PROJ1-REQUEST
REQUISITIONS
REQ-NO PROJ-NO DATE-NEEDED WHERE-NEEDED
3 Pr1 870620 south
4 Pr3 870703 north
5 Pr1 870612 east
6 Pr2 870702 West

PROJ1-REQUESTS
REQUEST DATE-WANTED WHERE-WANTED
3 870620 South
5 870612 East

Selanjutnya, user yang mendapat akses pada view dapat memperoleh informasi tentang daftar
permintaan dibuat oleh project ‘pr1’ dan tidak dari projek yang lain.

View dari join relasi


View dalat memasukan informasi dari lebih satu relasi. Sebagai contoh, misalkan kita
membutuhkan sebuah view untu mengambil unfilled requisitions untuk projek terpilih. View ini
didefinisikan sebagai:
CREATE VIEW UNFILLED-PARTS (REQUEST, PROJECT, PART, QTY-TO-BE-FILLED)
AS SELECT REQUISTIONS.REQ-NO, REQUISTIONS.PROJ-NO,PART-NO, QTY-NEEDED-
QTY-FILLED
FROM REQUISITIONS.REQ-LINES
WHERE REQUESITIONS.REQ-NO=REQ-LINES.REQ.NO
AND QTY-NEEDED >QTY-FILLED;
Tabel view UNFILLED-ORDERS ditunjukan dalam tabel 14.3. ini dapat digunakan untuk
mengambil secara detail tentang part (bagian) untuk satu projek oleh satu pernyataan select
sebagai berikut:
SELECT REQUEST.PART, QTY-TO-BE-FILLED
FROM UNFILLED-PARTS
WHERE PROJECT =’pr1’

Gambar 14.3 View UNFILLED-PARTS


REQUISITIONS
REQ-NO PROJ-NO DATE-NEEDED WHERE-NEEDED
3 Pr1 870620 south
4 Pr3 870703 north
5 Pr1 870612 east
6 Pr2 870702 West

REQ-LINES
REQ-NO PART-NO QTY-NEEDED QTY-FILLED
3 Pc6 90 10
3 Jw3 30 0
4 Pc6 50 0
4 Mx7 100 20
5 Jw3 40 10
5 Bb11 70 0
6 Jw3 90 0
5 Pc6 22 15

Tabel di atas adalah tabel penyimpanan data

REQUEST PROJECT PART QTY-TO-BE-FILLED


3 Pr1 Pc6 80
3 Pr1 Jw3 30
4 Pr3 Pc6 50
4 Pr3 Mx7 80
5 Pr1 Jw3 30
5 Pr1 Bb11 70
6 Pr2 Jw3 90
5 Pr1 Pc6 7
Tabel di atas adalah view

Pernyataan SQL ini akan mengambil semua part untuk disampaikan pada projek pr1. Output
dari pernyataan SQL tersebut adalah:
REQUEST PART QTY-TO-BE-FILLED
3 pc6 80
3 jw3 30
5 jw3 30
5 bb11 70
5 pc6 7

View UNFILLED-PARTS dibuat dari sebuah join dari 2 relasi. Jua memungkinkan untuk membuat
view dari banyak relas.

TUGAS
Definisikan view untuk basisdata dalam gambar 12.2
1. Sebuah relasi (PROPERTY, SEC-NAME, SOIL) yang memperlihatkan soil pada setiap
section
2. Sebuah relasi (OWNER-NAME,OWNER-ADDRESS,PROPERTY) yang menunjukan owner,
address mereka dan property mereka bersama dengan address property.
3. Sebuah relasi (OWNERS, PRODUCT) yang menunjukan produk yang tumbuh pada setiap
pemilik property (owner’s property)
4. Sebuah relasi (PROPERTY, TOTAL-AREA) yang menunjukan tatal area dari setiap
property.

Anda mungkin juga menyukai