Teks tersebut membahas sejarah dan konsep dasar model relasional dalam sistem basis data. Model ini pertama kali diusulkan oleh E.F. Codd pada tahun 1970 dan mendefinisikan konsep-konsep penting seperti relasi, atribut, domain, dan tuple. Model ini kemudian dikembangkan lebih lanjut melalui proyek-proyek penelitian seperti Sistem R di IBM dan INGRES di Universitas California, Berkeley."

1. BAB RELATIONAL
3 MODEL
R
elational Database Management System (RDBMS) telah menjadi perangkat lunak pengolahan data yang
dominan digunakan saat ini, dengan perkiraan penjualan lisensi baru antara US $ 6 miliar hingga
US $ 10 milyar per tahun (US $ 25 miliar, bila termasuk dengan penjualan perangkat lainnya). Perangkat lunak
ini merupakan generasi kedua DBMS yang dibangun oleh EF Codd (1970).
3.1 SEJARAH RINGKAS MODEL RELATIONAL
Model ini pertama kali diusulkan oleh E. F. Codd di dalam makalahnya berjudul "A relational model of data for large
shared data banks" (Codd, 1970). Makalah ini kini berlaku umum sebagai fenomena dalam sistem database,
walaupun suatu model berorientasi set yang diusulkan sebelumnya (Child, 1968). Sasaran model Relational adalah
sebagai berikut:
 Memungkikan tingkat kebebasan data yang tinggi. Program aplikasi seharusnya tidak terpengaruh karena
perubahan penyajian data internal, terutama oleh berubahnya organisasi file, urutan data atau alur akses.
 Memberi alasan mendasarl berhubungan dengan semantik data, konsistensi, dan permasalahan pemborosan.
Makalah Codd juga memperkenalkan konsep hubungan yang dinormalisasi, yaitu suatu hubungan yang tidak
terdapat pengulangan kelompok.
 Memungkinkan penggunaan bahasa manipulasi data berorientasi set yang luas.
Hal menarik akan model relational berasal dari riset penting yang saling berhubungan dalam tiga proyek walau
dengan perspektif yang berbeda. Yang pertama, Laboratorium Riset IBM San José di California, yaitu prototipe
relational DBMS Sistem R pada akhir l970 (Astrahan Vial, 1976). Proyek ini dirancang untuk membuktikan kepraktisan
model relational dengan melakukan implementasi tentang struktur data dan operasinya. Juga membuktikan untuk
menjadi suatu sumber informasi yang sempurna tentang implementasi seperti manajemen transaksi, kendali
concurrency, teknik pemulihan, optimisasi query, keamanan data dan integritas, faktor manusia, dan alat
penghubung pemakai. Pada DBMS sistem R terdapat dua pengembangan utama:
 Pengembangan suatu bahasa query yang tersusun [yang dilafalkan “S-Q-L”, atau “See-Quel”), yang sejak itu
telah menjadi Standar ISO dan secara defacto menjadi bahasa baku untuk relational DBMS;
 Pembuatan berbagai DBMS relational komersil sepanjang akhir l970 dan l980: sebagai contoh, DB2 dan SQL/DS
dari IBM dan Oracle dari Oracle Corporation.
Proyek kedua yang penting dalam pengembangan relational model adalah INGRES (Interactive Graphics Retrieval
System) dirancang di Universitas California, Berkeley. Pada waktu yang sama aktif juga meneliti rancangan sistem R.
Proyek INGRES melibatkan pengembangan suatu prototipe RDBMS, dengan riset yang berkonsentrasi pada hasil
keseluruhan sasarannya, yang hampir menyerupai rancangan Sistem R. Riset ini mendorong suatu versi akademis
INGRES, yang memberi kontribusi terhadap konsep relational dan menghasilkan produk komersil INGRES dari
Relational Inc. Teknologi ( sekarang INGRES II dari Computer Associate) dan Mesin Database Yang cerdas dari Britton
Inc.

2. Proyek yang ketiga adalah Peterlee Relational Test Vehicle di Pusat Ilmiah IBM, Peterlee, UK (Todd, 1976).
Proyek ini mempunyai suatu orientasi yang lebih teoritis dibanding Sistem R dan INGRES, secara signifikan meneliti
isu query untuk memproses dan optimisasi, dan perluasan fungsional basis data.
Komersialisasi model relational dimulai pada akhir l970 dan awal l980. Saat ini terdapat ratusan RDBMS untuk
mainframe dan PC. Contoh pada PC-based RDBMS adalah ACCESS Dan FOXPRO dari Microsoft. PARADOX dari Corel
Corp, INTERBASE Dan BDE dari Borland, dan R:Base dari R:BASE Technology.
Beberapa perluasan model relational digunakan untuk :
 Menangkap lebih baik arti dari data (Codd, 1979);
 Mendukung konsep berorientasi objek (Stonebraker dan Rowe, 1986);
 Mendukung kemampuan deduksi (Gardarin dan Valduriez, 1989).
3.2 TERMINOLOGY
Istilah Relational Model didasarkan pada konsep matematika yang secara fisik diwakili oleh suatu hubungan tabel.
Codd, seorang ahli matematik, memakai istilah pada matematika, terutama teori dasar dan logika.
3.2.1 STRUKTUR DATA RELATIONAL
Relational
A relation is a table with columns and rows.
Suatu RDBMS diperlukan hanya berdasarkan bagimana pemakai memandang sesuai persepsinya. Sebagai catatan,
bagaimanapun persepsi ini berlaku hanya untuk struktur database yang logis: hal ini disebut tingkatan konseptual
dan eksternal arsitektur ANSI-SPARC.
Attribute
An attribute is a named column of a relation.
Gambar 3.1 - Hubungan Instance Branch dan Staff

3. Pada model relational, hubungan digunakan untuk pegangan tentang object yang diwakilinya. Suatu hubungan
diwakili sebagai dua dimensi tabel, di mana baris sesuai dengan arsip individu dan kolom sesuai dengan atribut.
Atribut dapat nampak pada tiap order dan hubungan yang sama akan menyampaikan maksud yang sama. Sebagai
contoh, informasi pada kantor cabang diwakili oleh relasi Branch, dengan kolom untuk atribut brancnNo
(nomor/jumlah cabang), street, city, dan postcode. Dengan cara yang sama informasi tentang diwakili oleh
relasi staff, dengan atribut staffNo (nomor;jumlah staff) untuk kolom, fName, lName, position, sex, DOB
(tanggal lahir), salary. dan branchNo (banyaknya cabang dan jumlah staff yang bekerja).
Pada Gambar 3.1 menunjukkan relasi Branch dan staff. Kolom berisi nilai-nilai atribut tunggal; sebagai
contoh branchNo kolom hanya berisi kode kantor cabang yang ada.
Domain
A domain is the set of allowable values for one or more attributes.
Domain adalah fitur utama dari model relational. Tiap atribut didalam suatu hubungan digambarkan atas suatu
daerah (domain). Domain mungkin berbeda untuk masing-masing atribut, atau dua atau lebih atribut namun dapat
menggambarkan domain yang sama. Pada Gambar 3.2 menunujukkan domain yang terdiri dari sebagian dari atribut
relasi Branch dan staff.
Gambar 3.2 Domain untuk relasi Branch dan staff
Konsep domain sangat penting karena kita mempelajari bagaimana menggambarkan suatu maksud/arti dan
asal nilai didalam atributnya. Sebagai hasilnya, informasi dapat tersedia pada sistem selama waktu pelaksanaan
pengoperasian suatu relasi. Jika suatu operasi secara semantik salah maka otomatis akan dihindari. Sebagai contoh
tidaklah mungkin membandingkan suatu sebutan jalan dengan nomor telepon, meskipun domain keduanya sama.
Tuple
A tuple is a row of a relation.
Elemen dari sebuah relasi adalah baris (row) atau disebut tuple di dalam table. Pada relasi branch, setiap baris berisi
empat nilai, satu nilai untuk setiap atribut. Tuple dapat muncul pada setiap urutan dari suatu table relasi, yang dapat
mempunyai pengertian yang sama.
Struktur suatu relasi, bersama dengan spesifikasi domain dan berbagai pembatasan nilai lainnya, kadangkadang disebut sebagai intension, kecuali ditetapkan lain. Bila makna relasi diubah untuk menyertakan atribut
tambahan berubah dari waktu ke waktu disebut extension.

4. Degree
A tuple is a row of a relation.
Relasi Branch di gambar 3.1 mempunyai empat atribut atau berderajat tingkat empat. Artinya tiap baris tabel
adalah berisi empat nilai-nilai. Relasi dengan hanya satu atribut mempunyai derajat tingkat satu disebut hubungan
unary atau one-tuple. Suatu hubungan dengan dua atribut disebut biner, dengan tiga atribut disebut ternary, dan
setelah itu istilah n-ary. Derajat tingkat suatu hubungan adalah suatu properti intension dari relasi itu.
Cardinality
The cardinality of a relation is the number of tuples it contains.
Sebagai pembanding, banyaknya tuples disebut kardinalitas dari relasi dan perubahan ini ketika tuples ditambahkan
atau dihapus. Kardinalitas adalah suatu properti dari hubungan ekstensi dan ditentukan dari kejadian hubungan yang
telah ditentukan di setiap momen.
Relational
A collection of normalized relations with distinct relation names.
Database
Sebuah database relasional terdiri dari hubungan terstruktur secara tepat. Kita lihat kesesuaian ini sebagai
normalisasi.
ISTILAH ALTERNATIF
Istilah untuk relational model dapat membingungkan. Pada Tabel 3.1 meringkas terminologi yang berbeda
pada model relational.
3.2.2 RELASI MATEMATIKA
Untuk memahami maksud yang benar, kita harus meninjau ulang beberapa konsep dari matematika. Bila kita
mempunyai dua himpunan, D1, dan D2, di mana D1= {2, 4} dan D2= {1, 3, 5}. Cartesian Product dari kedua himpunan
ini, ditulis D1 x D2, adalah himpunan yang berisi semua pasangan yang dihasilkannya, yaitu yang unsur pertamanya
adalah anggota D1 dan unsur yang kedua adalah anggota D2. Cara lain menyatakan ini adalah dengan menemukan
semua kombinasi unsur-unsur pertama dari D1, dan yang kedua dari D2. Pada contoh ini, kita mempunyai :
D1 x D2 = { (2, 1), (2,3), (2,5), (4,1), (4,3), (4,5) }
Setiap set dari hasil Cartesian Product adalah relasi. Misalnya relasi R seperti di bawah ini :
R = { (2, 1), (4, 1) }

5. Kita dapat menetapkan pasangan pada relasi dengan memberi beberapa pilihan kondisi. Sebagai contoh, jika kita
mengamati bahwa R terdiri dari semua pasangan di mana unsur yang kedua adalah 1, kita bisa tulis R adalah :
R = { (x,y) | x ϵ D1, y ϵ D2, and y = 1 }
Menggunakan himpunan yang sama, kita dapat membentuk relasi lain S yang mana unsur pertama selalu dua kali
lebih dari yang kedua. jadi S ditulis:
S = { (x,y) | x ϵ D1, y ϵ D2, and y = 2 y } atau dalam bentuk instance : S = { (2, 1) }
Karena hanya ada satu pasangan hasil Cartesian Product yang memenuhi pada kondisi ini. Kita dapat memperluas
menjadi tiga relasi. Misalkan D1, D2, dan D3. Produk Kartesian D1 x D2 x D3, tiga set himpunan ini adalah satuan dari
hasil himpunan dari D1, D2, dan unsur dari D3. Setiap subset dari Cartesian Product ini adalah suatu relasi. Sebagai
contoh, kita mempunyai:
D1={1,3}
D2={2,4}
D3={5,6}
D1 x D2 x D3 = {(1, 2, 5), (1, 2, 6), (1, 4, 5), (1, 4, 6), (3, 2, 5), (3, 2, 6), (3, 4, 5), (3, 4, 6)}
Setiap subset dari hasil perkalian tiga set himpunan ini membentuk relasi. Selanjutnya dapat diperluas ke dalam
relasi umum yang terdiri dari n domain. Misalnya D1, D2, D3 … Dn sebanyak n set. Hasil Cartesian Product adalah :
D1 x D2 x D3...XDn = {d1, d2, d3...dn | d1 ϵ d1, d2 ϵ d2, d3 ϵ d3,… dn ϵ dn}
Secara umum ditulis sebagai berikut :
Tiap kumpulan dari n-tuples dari Cartesian Product adalah relasi didalam n himpunan. Sebagai catatan, dalam
mendefinisikan relasi, kita harus memiliki sejumlah set atau domain dari nilai yang kita pilih.
3.2.3 RELASI BASIS DATA
Dengan menerapkan konsep di atas, maka dapat disusun definisi dari relasi sebuah skema.
Relation
A named relation defined by a set of attribute and domain name pairs.
Schema
Misalnya A1, A2, . . .,An, adalah atribut dengan domain D1, D2, . . .,Dn.
Maka kumpulan dari { A1 : d1, A2 : d2, . . . An : dn } adalah skema relasi. Sebuah relasi R didefinisikan oleh skema
relasi S adalah himpunan dari pemetaan dari nama-nama atribut pada hubungan domain mereka. Jadi relasi P
adalah himpunan n-tuples :
A1 : d1, A2 : d2, . . . ,An : dn, such that d1 ϵ D1, d2 ϵ D2, . . . ,dn ϵ dn
Setiap elemen dari n-tuples terdiri dari dari atribut dan nilai atribut itu. Secara normal, ketika menuliskan suatu relasi
sebagai tabel, kita membuat daftar nama atribut dari judul kolom dan menuliskan tuples sebagai baris. Misalnya

6. pada bentuk (d1, d2, . . .,dn) dimana nilai masing-masing diambil dari domain yang sesuai. Dengan cara ini, kita
dapat menyimpulkan bahwa suatu relasi di dalam model relational adalah semua subset dari hasil Cartesian Product
dari atribut sebuah domain. Suatu tabel adalah representasi secara fisik dari relasi di atas. Pada contoh, relasi
Branch pada gambar 3.1 mempunyai atribut branchNo, street, city, dan postcode, yang masing-masing
mempunyai domain. Relasi Branch ini terdiri dari tiap subset hasil Cartesian Product dari domainnya, atau setiap
empat tuple dimana elemen pertama adalah dari domain BranchNumber, elemen kedua berasal dari domain
StreetName dan seterusnya. Salah satu dari keempat tuple itu adalah
{(B005, 22 Deer Rd. London, SW1 4EH)}
Atau lebih tepatnya :
{(branchNo: B005, street: 22 Deer Rd. cty: London. postcode: SWI 4EH)}
Kita nyatakan sebagai isi (instance) dari relasi. Tabel Branch sangat tepat bila dinyatakan dengan empat tuple dari
relasi pada setiap waktu yang ditentukan. Ini menjelaskan bagaimana sebuah baris table pada model relasi disebut
tuple. Dengan cara yang sama sebuah relasi mempunyai skema dan sudah barang tentu dengan relasi database.
Relational Database
A set of relation schemas, each with a distinct name.
Schema
Jika R terdiri dari R1, R2, . . .,Rn adalah suatu kumpulan dari skema relasi, maka dapat dituliskan skema database
relasi atau sering disingkat dengan skema relasi R adalah :
R = {R1, R2, . . .,Rn}
3.2.4 PROPERTIES DALAM RELASI
Sebuah relasi mempunyai sejumlah property sebagai berikut :
 Relasi mempunyai suatu nama yang berbeda dari semua relasi yang pada skema relasinya;
 Masing-masing sel dari relasi berisi hanya satu nilai tunggal;
 Masing-masing atribut mempunyai nama yang berbeda;
 Nilai-nilai dari suatu atribut adalah dari domain yang sama;
 Masing-masing tuple adalah beda; tidak ada salinan tuples;
 Order atribut tidak punya arti;
 Order tuples tidak punya arti. Secara teoritis. (namun, dalam praktek, order dapat mempengaruhi efisiensi
akses tuples.)
Untuk menjelaskan arti batasan (restrictions) ini, kita lihat relasi Branch pada gambar 3.1. Setiap elemen berisi
hanya satu nilai, jadi tidak sah (illegal) untuk menyimpan dua post-codes untuk satu kantor cabang tunggal di dalam
sel tunggal. Dengan kata lain, hubungan tidak diperbolehkan berisi suatu pengulangan kelompok. Suatu hubungan
harus memiliki property yang tepat atau telah dinormalisasi atau dalam bentuk format normal tingkat kesatu
(1st Normal Form/1st NF). Daftar nama kolom berada di bagian atas kolom sesuai dengan atribut relasiny. Nilai-Nilai
di dalam atribut brancbNo adalah terdiri semua domain dari BranchNumber; mestinya tidak mengijinkan nilai
postcode nampak pada kolom tersebut. Dengan kata lain tidak ada pengulangan (duplicate) tuples di dalam suatu
relasi. Sebagai contoh (B005, 22 Deer Rd. London, SWI 4EH) hanya muncul satu kali.

7. Dapat saja terjadi, nama atribut diganti dengan nilai atributnya dengan memindahkan kolomnya. Tabel akan
menggambarkan relasi yang sama jika kita menempatkan atribut city sebelum atribut postcode, walaupun
untuk keadaan ini dapat dibaca adanya unsur-unsur alamat dan lainnya dalam pesanan. Dengan cara yang sama,
tuples dapat dipertukarkan, sehingga arsip Branch B005 dan B004 dapat dipindah dan relasi masih akan sama.
Kebanyakan dari properti menetapkan untuk relasi yang diakibatkan oleh properti relasi matematis:
 Ketika kartesian produk telah dihasilkan unsur-unsur bernilai tunggal sederhana seperti bilangan bulat, masingmasing unsur pada setiap tuple adalah bernilai tunggal. Dengan cara yang sama. Masing-masing sel suatu
hubungan berisi persisnya satu nilai. Bagaimanapun, suatu relasi matematis tidak perlu dalam bentuk normal.
Codd menentukan pengulangan kelompok data seharusnya ditolak untuk menyederhanakan relational model
data.
 Di dalam suatu relasi, nilai-nilai yang mungkin untuk tiap posisi, ditentukan oleh kelompok, domain, yang
menggambarkan posisinya. Di dalam suatu tabel, nilai-nilai pada tiap kolom harus berasal dari domain atribut
yang sama.
 Di dalam kelompok, tidak ada elemen yang berulang. Dengan cara yang sama, di dalam suatu relasi, tidak ada
duplikasi dtuplesalinan tuples.
 Sejak suatu relasi di dalam satu kelompok , aturan elemen/komponen tidak berlaku. Oleh karena itu, di dalam
suatu relasi hubungan tuples adalah tidak penting
Bagaimanapun, pada relasi matematis, aturan unsur-unsur dalam satu tuple adalah penting. Sebagai contoh,
pasangan (1, 2) adalah sungguh berbeda dari pasangan yang (2, 1). Meskipun ini bukan kasus pada model relasi,
yang memerlukan atribut tidak penting. Alasannya adalah bahwa kolom yang mengatur menggambarkan pemilik
nilai itu. Ini berarti judul kolom adalah intension yang tidak penting, tetapi ketika struktur hubungan di/terpilih,
unsur-unsur di dalam tuples harus memenuhi atributnya.
3.2.5 KUNCI RELATIONAL
Seperti dijelaskan di atas, tidak ada tuple yang duplikat di dalam suatu relasi. Oleh karena itu, kita perlu untuk dapat
mengidentifikasi satu atau lebih atribut (Kunci Relational/Relational Key) yang akan mengidentifikasi secara unik
setiap tuple di dalam suatu relasi.
Superkey
An attribute, or set of attributes, that uniquely identifies a tuple within a
relation.
Suatu superkey yang mengidentifikasi secara unik setiap tuple di dalam relasi. Suatu superkey boleh berisi atribut
gabungan, tetapi umumnya hanya berisi atribut yang penting untuk mengidentifikasi secara unik.
Candidate
A superkey such that no proper subset is a superkey within the relation.
Key
Suatu Candidate key K, pada suatu relasi R mempunyai dua ciri :


Uniqueness (keunikan) - Pada setiap tuple R, nilai-nilai K dengan uniknya mengidentifikasi tuple itu;
Irreducibility (tidak dapat dijabarkan) - Tidak ada bagian dari K yang dapat menentukan keunikan.

8. Mungkin ada beberapa candidate key untuk suatu relasi. Jika kunci terdiri lebih dari satu atribut, ini disebut kuncigabungan (composite key). Kita lihat contoh relasi Branch pada Gambar 3.1. Nilai city, kita dapat menentukan
beberapa kantor cabang (misalnya : London mempunyai dua kantor cabang). Atribut ini tidak bisa dijadikan suatu
candidate key. Karena DreamHome mengalokasikan nomor unik di masing-masing kantor cabang, branchNo. kita
dapat menentukan paling banyak satu tuple, sehingga branchNo adalah candidate key. Dengan cara yang sama,
postcode juga adalah candidate key untuk hubungan ini.
Selanjutnya kita lihat relasi Viewing, yang berisi informasi yang berkenaan dengan property yang dilihat
oleh klien. Relasi berisi berisi nomor client (clientNo), nomor properti (propertyNo), tanggal lihat (viewDate)
dan, komentar (comment). Dengan memberikan nomor client, clientNo, mungkin ada beberapa tampilan yang
sesuai untuk sifat yang berbeda. Selanjutnya dengan cara yang sama, suatu nomor properti, propertyNo, mungkin
ada beberapa klien yang melihat properti ini. Oleh karena itu, clientNo atau propertyNo dengan sendirinya
tidak dapat terpilih sebagai candidate key. Bagaimanapun, kombinasi clientNo dan propertyNo
mengidentifikasi paling banyak satu tuple, maka, untuk relasi Viewing tersebut , clientNo dan propertyNo
bersama-sama (composite) membentuk candidate key. Jika kita perlu untuk memenuhi kemungkinan bahwa klien
dapat melihat properti lebih dari sekali, maka kita bisa menambahkan viewDate ke composite key. Namun, kita
anggap bahwa ini tidak diperlukan.
Suatu kejadian dalam seuatu relasi tidak bisa digunakan untuk membuktikan bahwa suatu atribut atau
kombinasi atribut adalah candidate key. Faktanya tidak ada duplikat untuk nilai-nilai yang tampil pada saat tertentu
tidaklah mungkin. Bagaimanapun, adanya suatu kejadian dapat digunakan untuk menunjukkan beberapa kombinasi
atribut bukanlah suatu calon kunci. Mengidentifikasi candidate key memerlukan kesesuaian dengan 'dunia nyata'
dari setiap maksud/arti attribute yang terlibat. Hanya dengan penggunaan informasi semantik kita yakin bahwa
suatu kombinasi atribut adalah suatu candidate key. Sebagai contoh, Pada Gambar 3.1, suatu candidate key yang
pantas untuk relasi Staff adalah lName, nama panggilan karyawan itu. Walaupun hanya ada nilai tunggal 'White'
dalam instance untuk relasi Staff, suatu waktu staff baru dengan nama 'White' mungkin bergabung dengan
perusahaan, sehingga tidak tepat memilih lName sebagai candidate key.
Primary Key
The candidate key that is selected to identify tuples uniquely within the
relation.
Pada relasi yang tidak ada duplikasi tuple, terdapat kemungkinan untuk mengidentifikasi masing-masing baris secara
unik. Hal ini berarti suatu relasi selalu mempunyai primary key. Pada kasus yang terburuk, keseluruhan satuan atribut
bisa bertindak sebagai primary key. Tetapi pada umumnya terdapat beberapa subset kecil yang dapat
mengidentifikasi sebuah tuples. Candidate key yang tidak terpilih sebagai primary key disebut kunci pengubah
(alternate key). Sebagai contoh relasi Branch, jika kita memilih branchNo sebagai primary key, maka postcode
akan menjadi alternate key. Pada relasi Viewing, hanya ada satu candidate key, berisikan clientNo dan
propertyNo, maka atribut ini akan secara otomatis membentuk primary key.
Foreign Key
An attribute, or set of attributes, within one relation that matches the
candidate key of some (possibly the same) relation.
Ketika suatu atribut muncul lebih dari satu relasi, maka tampilan akan menghadirkan suatu hubungan antara dua
tuple dari dua relasi. Sebagai contoh, inklusi dari branchNo pada kedua relasi Branch dan Staff akan

9. mempertimbangkan menghubungkan setiap cabang ke rincian staf yang bekerja di kantor cabang tersebut. Pada
relasi Branch, branchNo adalah primary key. Namun, dalam relasi Staff, atribut branchNo ada untuk
mencocokkan staf yang masuk bekerja di kantor cabang mereka. Pada relasi Staff tersebut, branchNo adalah
foreign key. Kita katakan bahwa atribut branchNo di dalam relasi Staff adalah target primary key pada
brancnNo pada Home relation. Branch. Atribut ini mempunyai peran yang sangat penting di dalam melakukan
manipulasi data, pada pengolahan basis data
3.2.6 PENGGAMBARAN SKEMA RELASI BASIS DATA
Suatu relational database terdiri sejumlah relasi yang normal. Bagan Relasi dari kasus DreamHome adalah sebagai
berikut :

10. Gambar 3.3 DreamHome Rental Database
Branch
(branchNo, street, city, postcode)
Staff
(staffNo, fName, lName, position, sex, DOB, salary, branchNo)
PropertyForRent (propertyNo, street, city, postcode, type, rooms, rent, ownerNo,
staffNo, branchNo)
Client
(clientNo, fName, lName, telNo, prefType, maxRent)
PrivateOwner (ownerNo, fName, lName, address, telNo)
Viewing
(clientNo, propertyNo, viewDate, comment)
Registration
(clientNo, branchNo, staffNo, dateJoined)
Kesepakatan umum untuk menyatakan suatu skema relasi adalah untuk memberi nama relasi yang diikuti oleh
atribut menyebut di dalam tanda kurung. Sedangkan primary key diberi garis bawah. Model konseptual, atau skema
konseptual terdiri dari sejumlah skema database seperti itu pada Gambar 3.3.
3.3 INTEGRITAS SUATU CONSTRAIN
Sebelumnya telah dibahas bagian struktur relational data model. Telah dinyatakan suatu data model mempunyai
dua bagian yang berbeda: bagian manipulasi, untuk mendefinisikan jenis operasi yang diijinkan pada data, dan satu
set aturan integritas, yang memastikan bahwa data itu akurat.
Setiap atribut mempunyai domain, juga terdapat constraint (domain constraint) format batasan atas satuan
nilai-nilai pada relasi atribut. Sebagai tambahan, ada dua aturan integritas (integrity rules) penting yaitu integritas
entitas (entity integrity) dan integritas referensial (referential integrity). Tipe lain dari integritas suatu constrain
yaitu multiplicity dan general constrains.
3.3.1 NULL
Null
Represents a value for an attribute that is currently unknown or is not
applicable for this tuple.
Null dapat diartikan sebagai tidak diketahui nilainya (unknown). Berarti bahwa suatu nilai tidaklah dapat digunakan
untuk tuple tertentu, atau berarti bahwa tidak ada nilai yang tersedia. Null adalah suatu cara untuk berhubungan
dengan data pengecualian atau tidak sempurna. Null tidaklah sama dengan nol ( 0 ) atau ruang kosong, tetapi
diartikan sesuatu yang memunculkan ketidakadaan suatu nilai. Oleh karena itu, Null harus diperlakukan dengan cara
yang berbeda dari nilai-nilai lainnya.
Sebagai contoh, pada relasi Viewing (Gambar 3.3), atribut comment boleh tidak terdefinisikan sampai
penyewa potensial telah mengunjungi properti yang akan disewanya lalu kembali dan memberikan komentarnya

11. kepada agen. Tanpa Null, akan menjadi penting untuk menghadirkan data yang salah pada kondisi tersebut untuk
menambahkan atribut tambahan (yang mungkin tidak berarti bagi pemakai lain). Dalam contoh kita boleh mencoba
untuk menghadirkan suatu komentar batal dengan nilai ( -1 ). Sebagai alternatif. kita boleh menambahkan suatu
atribut baru hasCommentBeenSüpplied pada relasi Viewing, yang berisi nilai Y ( Yes ) jika suatu komentar telah
disediakan, dan N ( No ) untuk yang lainnya, namun pendekatan ini dapat membingungkan pemakai lain.
Null menyebabkan permasalahan implementasi, model relational didasarkan pada aturan awal kalkulus,
dimana suatu two-valued atau logika Boolean hanya memperbolehkan nilai True atau False. Untuk menggunakan
Null berarti kita bekerja dengan suatu logika tingkat tinggi.
3.3.2 INTEGRITAS SUATU ENTITAS
Aturan Integritas yang pertama berlaku pada primary key. Secara konseptual sebuah relasi menggambarkan
hubungan kesatuan dengan primary key.
Entity
In a base relation, no attribute of a primary key can be null.
Integrity
Menurut definisi, suatu primary key digunakan minimal untuk mengidentifikasi tuples agar unik. Ini berarti bagian
(subset) dari primary key tidak mencukupi untuk menjadi identifikasi unik dari sebuah tuples. Jika kita mengijinkan
Null sebagai bagian dari suatu primary key, ini akan menyiratkan bahwa tidak semua atribut diperlukan untuk
membedakan antara tuples, yang berkontradiksi dengan definisi primary key. Sebagai contoh. Pada relasi
branchNo adalah primary key dari relasi Branch, kita tidak dapat menyisipkan nilai Null untuk relasi dari atribut
branchNo tersebut. Contoh kedua, mempertimbangkan composite primary key pada relasi Viewing, berisi
nomor client (clientNo) dan nomor properti (propertyNo). Kita tidak dapat menyisipkan suatu tuple ke dalam
relasi Viewing dengan nilai Null untuk atribut clientNo, atau Null pada atribut propertyNo, atau untuk
atribut kedua-duanya.
Bila kita periksa aturan ini secara detil, akan ditemukan keganjilan. Pertama, kenapa aturan ini hanya berlaku
untuk primary key dan tidak secara umum pada candidate key, yang juga mengidentifikasi tuples secara unik? Yang
kedua, mengapa aturan terbatas hanya berdasarkan relasi? Sebagai contoh, pada relasi Viewing (Gambar 3.3)
perhatikan bagian query 'list all comments from viewings’. Ini akan menghasilkan suatu hubungan unary yang terdiri
dari atribut comment. Menurut definisi, atribut ini harusnya primary key, tetapi terdapat Null. Sejak relasi ini tidak
mengacu pada dasar relasi, model memperbolehkan primary key dengan nilai Null. Dan hal tersebut saat ini masih
dalam perbaikan dari sisi aturan (Codd, 1988 ; Date, 1990).
3.3.3 INTEGRITAS REFERENSIAL
Aturan integritas kedua berkaitan dengan foreign key, sebagai berikut :
Referential
Integrity
If a foreign key exists in a relation, either the foreign key value must match a
candidate key value of some tuple in its home relation or the foreign key value
must be wholly null.

12. Sebagai contoh, branchNo pada relasi Staff adalah foroign key yang mengarahkan pada atribut branchNo
dalam relasi home, Branch. Tidaklah mustahil untuk membuat record staff dengan nomor cabang B025, kecuali
bila telah ada record nomor cabang B025 pada relasi Branch. Namun, kita harus bisa membuat record staf baru
dengan nilai Null di sejumlah cabang, untuk memenuhi situasi di mana anggota staf baru telah bergabung dengan
perusahaan tetapi belum ditugaskan di kantor cabang tertentu.
3.3.4 CONSTRAINT UMUM
General
Constraints
Additional rules specified by the users or database administrators of a
database that define or constrain some aspect of the enterprise.
Hal ini juga dimungkinkan bagi pengguna untuk menentukan batasan (constraints) tambahan agar berbagai syarat
terpenuhi. Sebagai contoh, jika batas atas 20 telah dibuat pada jumlah staf yang dapat bekerja di kantor cabang,
maka seharusnya DBMS tidak mungkin untuk menambahkan anggota baru staf di cabang. Sayangnya, tingkat
dukungan untuk kendala umum bervariasi dari sistem ke sistem.
3.4 CARA PANDANG (VIEWS)
Pada arsitektur ANSI-SPARC diuraikan suatu pandangan eksternal dari struktur basis data yang tampil bagi pemakai
tertentu. Di dalam model relasi, View (' pandangan' ) mempunyai suatu arti yang sedikit berbeda. Suatu view adalah
relasi yang diperoleh secara dinamis dari satu atau lebih hubungan dasar. Suatu model eksternal dapat terdiri dari
gabungan relasi dasar (conceptual level) dan view diperoleh dari hubungan dasar tersebut.
3.4.1 TERMINOLOGI
Hubungan yang telah dibahas sampai saat ini umumnya disebut sebagi hubungan dasa
Base
Relation
A named relation corresponding to an entity in the conceptual schema, whose
tuples are physically stored in the database.
Kita dapat menggambarkan pandangan dalam kaitan dengan hubungan dasar:
View
The dynamic result of one or more relational operations operating on the base
relations to produce another relation. A view is a virtual relation that does not
necessarily exist in the database but can be produced upon request by a
particular user, at the time of request.
Suatu pandangan adalah suatu hubungan yang nampak pada layar pengguna, dapat dimanipulasi berdasarkan
pada relasi, tetapi tidak perlu disimpan di dalam storage database. Isi tampilan di layar adalah adalah hasil dari
query pada satu atau lebih hubungan dasar. Tampilan bersifat dinamis, artinya dapat berubah sesuai kebutuhan.

13. Kapan para pemakai meminta perubahan terhadap view, perubahan ini dibuat tetapi tetap berdasar pada
hubungan yang telah terbentuk.
3.4.2 KEGUNAAN TAMPILAN
Mekanisme view adalah didasarkan untuk beberapa pertimbangan:



Untuk menyediakan suatu mekanisme keamanan yang fleksibel dan kuat dengan cara menyembunyikan
bagian-bagian basis data terhadap pemakai tertentu.
Memungkinkan pemakai untuk mengakses data sesuai kebutuhan mereka, dengan data yang sama dapat
dilihat oleh para pemakai yang berbeda dengan hasil tampilan yang berbeda pada waktu yang sama.
Menyederhanakan operasi kompleks atas hubungan relasi dasar. Sebagai contoh, jika suatu view digambarkan
sebagai suatu kombinasi (join) dari dua relasi, para pemakai dapat lebih sederhana untuk melihat tampilan
karena telah, diterjemahkan oleh DBMS ke dalam operasi gabungan relasinya.
Suatu tampilan harus dirancang untuk mendukung model yang eksternal yang familiar bagi pemakai. Sebagai
contoh:
 Seorang pemakai mungkin memerlukan tuple Branch, yang berisi nama para manajer seperti halnya atribut
lain yang ada di relasi Branch. Tampilan ini dibuat dengan menggabungkan relasi Branch dengan suatu
format yang terbatas untuk relasi Staff dimana posisi staff adalah sebagai “Manajer”.
 Beberapa staff hanya perlu tuple Staff tanpa melihat atribut salary.
 Atribut mungkin di-rename. Sebagai contoh, pemakai terbiasa memakai branchNo untuk atribut cabang,
namun pada column heading dibuat Branch Number.
 Sebagian staff hanya melihat record property yang mereka atur.
Walaupun semua contoh ini menunjukkan bahwa suatu view menyediakan data logis independen, dimana
pemakai memiliki kebebasan pemakai untuk mengatur data secara logis. Sebagai contoh, jika suatu atribut baru
ditambahkan untuk suatu relasi, pemakai yang lain tidak akan peduli jika hal itu tidak mempengaruhi kebutuhan
pada tampilan mereka walaupin suatu relasi yang ada diatur kembali atau dipisah.
3.4.3 PEMUKTAHIRAN TAMPILAN
Untuk melakukan pemutakhiran suatu hubungan dasar sebuah relasi, harus segera. Dengan cara yang sama, jika
suatu tampilan diperbaharui, maka hubungan dasar relasi tersebut harus mencerminkan perubahan tersebut.
Bagaimanapun, ada pembatasan tampilan bila ada modifikasi. Kondisi-kondisi untuk pembaharuan yang diijinkan
melalui suatu tampilan, yaitu:
 Update diijinkan melalui suatu tampilan dengan melibatkan suatu query sederhana yang berisi hubungan
dasar relasi tunggal kunci untuk primary key maupun candidate key.
 Update tidaklah diijinkan bila suatu tampilan jika melibatkan hubungan dasar relasinya.
 Update tidaklah diijinkan sampai bila suatu tampilan melibatkan aggregasi atau penggolongan operasi.
Pengelompokan tampilan dibagi menjadi :
 Theoretically not updatable,
 Theoretically updatable
 Partially updatable.
Suatu penelitian atas proses updating relasi tampilan ditemukan pada Furtado dan Casanova ( 1985)