CHAPTER 4

“DATABASE SYSTEM”

LUKMANUL HAKIM (1401204114)

LUTHFI MACHDAR RIANDA (1401201584)
FAZRI EVRIZAL MUHARAM (1401204267)
WIDYA SAFIRA (1401184444)
MB 44 10

MANAJEMEN BISNIS TELEKOMUNIKASI INFORMATIKA

FAKULTAS EKONOMI DAN BISNIS
TELKOM UNIVERSITY
2021
 CHAPTER 4 : MODEL RELASIONAL

4.1 Sejarah Singkat Model Relasional

Model relasional pertama kali diusulkan oleh EF Codd dalam makalahnya yang berjudul “A
relational model of data for large shared data bank” (Codd, 1970). Makalah ini sekarang diterima
secara umum sebagai tengara dalam sistem database, meskipun model berorientasi-set telah di-
usulkan sebelumnya (Childs, 1968). Tujuan model relasional ditentukan sebagai berikut:
• Untuk memungkinkan tingkat independensi data yang tinggi. Program aplikasi tidak boleh
terpengaruh oleh modifikasi representasi data internal, terutama oleh perubahan organisasi
file, urutan rekaman, atau jalur akses.
• Untuk memberikan dasar yang substansial untuk menangani masalah semantik data, kon-
sistensi, dan redundansi. Secara khusus, makalah Codd memperkenalkan konsep dinor-
malisasi relasi, yaitu relasi yang tidak memiliki grup berulang. (Proses normalisasi dibahas
dalam 14 dan 15.)
• Untuk mengaktifkan perluasan bahasa manipulasi data berorientasi kumpulan.
Meskipun minat pada model relasional datang dari beberapa arah, penelitian yang paling sig-
nifikan dapat dikaitkan dengan tiga proyek dengan perspektif yang agak berbeda. Yang pertama,
di IBM San José Research Laboratory di California, adalah prototipe relasional DBMS System R,
yang dikembangkan selama akhir 1970-an (Astrahandkk., 1976). Proyek ini dirancang untuk mem-
buktikan kepraktisan model relasional dengan menyediakan implementasi struktur datanya dan
operasi. Ini juga terbukti menjadi sumber informasi yang sangat baik tentang masalah implemen-
tasi seperti manajemen transaksi, kontrol konkurensi, teknik pemulihan, optimasi kueri, keamanan
dan integritas data, faktor manusia, dan antarmuka pengguna, dan menyebabkan publikasi banyak
makalah penelitian dan untuk pengembangan prototipe lainnya. Secara khusus, proyek System R
menghasilkan dua perkembangan besar:
• Pengembangan bahasa query terstruktur yang disebut SQL, yang sejak itu menjadi Inter-
national Organization for Standardization (ISO) formal dan bahasa standar de facto untuk
DBMS relasional;
• Produksi berbagai produk DBMS relasional komersial selama akhir 1970-an dan 1980-an:
misalnya, DB2 dan SQL/DS dari IBM dan Oracle dari Oracle Corporation.
 Proyek kedua yang signifikan dalam pengembangan model relasional adalah proyek INGRES
(Interactive Graphics Retrieval System) di University of California di Berkeley, yang aktif pada
waktu yang hampir bersamaan dengan proyek System R. Proyek INGRES melibatkan pengem-
bangan prototipe RDBMS, dengan penelitian yang berkonsentrasi pada tujuan keseluruhan yang
sama dengan proyek Sistem R. Penelitian ini menghasilkan versi akademik INGRES, yang ber-
kontribusi pada apresiasi umum terhadap konsep relasional, dan melahirkan produk komersial IN-
GRES dari Relational Technology Inc. (sekarang Actian Corporation) dan Intelligent Database
Machine dari Britton Lee Inc
Proyek ketiga adalah Kendaraan Uji Relasional Peterlee di IBM UK Scientific Center di Pe-
terlee (Todd, 1976). Proyek ini memiliki orientasi yang lebih teoretis daripada proyek Sistem R
dan INGRES dan signifikan, terutama untuk penelitian tentang masalah seperti pemrosesan kueri
dan pengoptimalan serta ekstensi fungsional.
Sistem komersial berdasarkan model relasional mulai muncul pada akhir 1970- an dan awal
1980-an. Sekarang ada beberapa ratus RDBMS untuk lingkungan mainframe dan PC, meskipun
banyak yang tidak secara ketat mematuhi definisi model relasional. Contoh RDBMS berbasis PC
adalah Office Access dan Visual FoxPro dari Microsoft, InterBase dari Embarcadero Technolo-
gies, dan R:Base dari R:Base Technologies
Karena popularitas model relasional, banyak sistem nonrelasional sekarang menyediakan
antarmuka pengguna relasional, terlepas dari model yang mendasarinya. IDMS, DBMS jaringan
utama, telah menjadi CA-IDMS dari CA Inc. (sebelumnya Computer Associates), mendukung
tampilan data relasional. DBMS mainframe lain yang mendukung beberapa fitur relasional adalah
Model 204 dari Computer Corporation of America (anak perusahaan Rocket Software Inc) dan
ADABAS dari Software AG.
Beberapa perluasan model relasional juga telah diusulkan; misalnya, ekstensi ke:
• Menangkap lebih dekat makna data (misalnya, Codd, 1979);
• Mendukung konsep berorientasi objek (misalnya, Stonebraker dan Rowe, 1986);
• Mendukung kemampuan deduktif (misalnya, Gardarin dan Valduriez, 1989).
Kami membahas beberapa ekstensi ini di Bab 27-28, saat kami membahas DBMS Objek.4.2 Ter-
minologi
 Model relasional didasarkan pada konsep matematika sebuah hubungan, yang secara fisik
direpresentasikan sebagai sebuah tabel. Codd, seorang matematikawan terlatih, menggunakan ter-
minologi yang diambil dari matematika, terutama teori himpunan dan logika predikat. Pada bagian
ini kami menjelaskan terminologi dan konsep struktural dari model relasional.

4.2.1 Struktur Data Relasional

Hubungan Relasi adalah tabel yang memiliki kolom dan baris.
Sebuah RDBMS hanya membutuhkan database yang dirasakan oleh pengguna sebagai tabel.
Perhatikan, bagaimanapun, bahwa persepsi ini hanya berlaku untuk struktur logis database: yaitu,
tingkat eksternal dan konseptual dari arsitektur ANSI-SPARC yang dibahas dalam Bagian 2.1. Ini
tidak berlaku untuk struktur fisik database, yang dapat diimplementasikan menggunakan berbagai
struktur penyimpanan (lihat Lampiran F).

Atribut Atribut adalah kolom bernama dari suatu relasi.

Dalam model relasional, hubungan digunakan untuk menyimpan informasi tentang objek yang
akan direpresentasikan dalam database. Relasi direpresentasikan sebagai tabel dua dimensi di
mana baris tabel sesuai dengan catatan individu dan kolom tabel sesuai dengan atribut. Atribut
dapat muncul dalam urutan apa pun dan relasinya akan tetap menjadi relasi yang sama, dan karena
itu akan menyampaikan makna yang sama.
Misalnya, informasi tentang kantor cabang diwakili oleh Cabang relasi, dengan kolom untuk
atribut cabangNo (nomor cabang), jalan, kota, dan Kode Pos. Demikian pula, informasi tentang
staf diwakili oleh Staf relasi, dengan kolom untuk atribut stafNo (nomor staf), fNama, Inama, po-
sisi, seks, DOB (tanggal lahir), gaji, dan cabangNo (jumlah cabang tempat anggota staf bekerja).
Gambar 4.1 menunjukkan contoh dari Cabang dan Staf hubungan. Seperti yang Anda lihat dari
contoh ini, kolom berisi nilai dari satu atribut; misalnya, cabangNo kolom hanya berisi nomor
kantor cabang yang ada.

Domain -- Domain adalah kumpulan nilai yang diizinkan untuk satu atau lebih atribut.
Domain adalah fitur yang sangat kuat dari model relasional. Setiap atribut dalam suatu
relasi didefinisikan pada domain. Domain mungkin berbeda untuk setiap atribut, atau dua atau
lebih atribut dapat didefinisikan pada domain yang sama. Gambar 4.2 menunjukkan domain untuk
beberapa atribut dariCabang dan Staf hubungan. Perhatikan bahwa pada waktu tertentu, biasanya
akan ada nilai dalam domain yang saat ini tidak muncul sebagai nilai dalam atribut yang sesuai.
Konsep domain penting, karena memungkinkan pengguna untuk mendefinisikan di tempat
sentral makna dan sumber nilai yang dapat dipegang oleh atribut. Akibatnya, lebih banyak

Atribut Nama Domain Arti Definisi Domain

Cabang No Nomor Jalan Kemungkinan seluruh Karakter; ukuran 4; kis-
nomor jalan aran B001-B999
Jalan Nama Jalan Seluruh nama jalan di Karakter; ukuran 24
Britain
Kota Nama Kota Seluruh nama kota di Karakter; ukuran 15
Britan
 Kode Pos Kode Pos Seluruh kode pos di Karakter; ukuran 8
Britain
Jenis Kelamin Jenis Kelamin Jenis kelamin Karakter; isi berupa P
seseorang atau L
TTL Tempat Tanggal Lahir Kemungkinan tanggal Tanggal; berkisar dari 1-
lahir staf Jan-20, format dd-mm-yy
Gaji Gaji Kemungkinan nilai Moneter; 7 digit; range
gaji staff 6000.00-400000.00
Gambar 4.1 Contoh dari Cabang dan Staf hubungan

Gambar 4.2 Domain untuk beberapa atribut hubungan cabang dan staf.

informasi tersedia untuk sistem ketika melakukan eksekusi operasi relasional, dan operasi yang
secara semantik salah dapat dihindari. Misalnya, tidak masuk akal untuk membandingkan nama
jalan dengan nomor telepon, meskipun definisi domain untuk kedua atribut ini adalah string karak-
ter. Di sisi lain, sewa bulanan pada properti dan jumlah bulan properti telah disewa memiliki do-
main yang berbeda (yang pertama nilai moneter, yang kedua nilai integer), tetapi masih merupakan
operasi hukum untuk mengalikan dua nilai dari domain-domain ini. Seperti yang diilustrasikan
oleh dua contoh ini, implementasi domain yang lengkap tidak mudah, dan akibatnya, banyak
RDBMS tidak mendukungnya sepenuhnya.

Tupel -- Tuple adalah baris dari sebuah relasi.

Elemen dari suatu relasi adalah baris atau tupel di tabel. Dalam Cabang relasi, setiap baris
berisi empat nilai, satu untuk setiap atribut. Tuple dapat muncul di setiap urutan dan hubungan
akan tetap menjadi hubungan yang sama, dan karena itu menyampaikan arti yang sama.
Struktur relasi, bersama dengan spesifikasi domain dan batasan lain pada nilai yang mungkin,
kadang-kadang disebut kehebatan, yang biasanya tetap, kecuali jika arti dari suatu relasi diubah
untuk menyertakan atribut tambahan. Tupel disebut perpanjangan (atau negara) dari suatu relasi,
yang berubah dari waktu ke waktu.
Derajat -- Derajat suatu relasi adalah jumlah atribut yang dikandungnya.
NS Cabang relasi pada Gambar 4.1 memiliki empat atribut atau derajat empat. Ini berarti
bahwa setiap baris tabel adalah empat-tupel, berisi empat nilai. Relasi dengan hanya satu atribut
akan memiliki derajat satu dan disebut aunary relasi atau satu tupel. Relasi dengan dua atribut
disebut biner, satu dengan tiga atribut disebut ternary, dan setelah itu istilah n-ary biasanya
digunakan. Derajat suatu relasi adalah sifat darikehebatan dari hubungan tersebut.

Kardinalitas -- Kardinalitas suatu relasi adalah jumlah tupel yang dikandungnya.

Sebaliknya, jumlah tupel disebut kardinalitas dari relasi dan ini berubah saat tupel dit-
ambahkan atau dihapus. Kardinalitas adalah sifat dariperpanjangan dari hubungan dan ditentukan
dari contoh tertentu dari hubungan pada saat tertentu. Akhirnya, kami mendefinisikan database
relasional.

Basis data relasional -- Kumpulan relasi yang dinormalisasi dengan nama relasi yang berbeda.
Sebuah database relasional terdiri dari relasi-relasi yang terstruktur dengan tepat. Kami
menyebut kesesuaian ini sebagainormalisasi. Kami menunda pembahasan normalisasi sampai Bab
14 dan 15.

Terminologi alternatif
Terminologi untuk model relasional bisa sangat membingungkan. Kami telah memperkenal-
kan dua set istilah. Faktanya, kumpulan istilah ketiga kadang-kadang digunakan: suatu relasi dapat
disebut sebagai amengajukan, tupel sebagai catatan, dan atribut sebagai bidang. Terminologi ini
berasal dari fakta bahwa, secara fisik, RDBMS dapat menyimpan setiap relasi dalam sebuah file.
Tabel 4.1 merangkum istilah yang berbeda untuk model relasional.
Syarat Formal Alternatif 1 Alternatif 2
Hubungan Tabel File
Tupel Baris Rekaman
Atribut Kolom Field
4.2.2 Hubungan Matematika
Untuk memahami arti sebenarnya dari istilah hubungan, kita harus meninjau beberapa konkon-
sep dari matematika. Misalkan kita memiliki dua himpunan, D1 dan D2, di mana D1 = {2, 4} dan
D2 = {1, 3, 5}. Produk kartesius dari dua set ini, ditulis D1 X D2, adalah himpunan semua pasangan
terurut sedemikian rupa sehingga elemen pertama adalah anggota dari D1 dan elemen kedua adalah
anggota dari D2. Cara alternatif untuk mengungkapkan ini adalah dengan menemukan semua kom-
binasi elemen dengan yang pertama dari D1 dan yang kedua dari D2. Dalam kasus kami, kami
memiliki:
D1 X D2 = {(2, 1), (2, 3), (2, 5), (4, 1), (4, 3), (4, 5)}
Setiap bagian dari produk Cartesian ini adalah relasi. Misalnya, kita bisa menghasilkan relasi R
seperti yang:
R = {(2, 1), (4, 1)}
Kita dapat menentukan pasangan terurut mana yang akan berada dalam relasi dengan memberikan
beberapa kondisi untuk pemilihannya. Misalnya, jika kita amati bahwaR mencakup semua pasan-
gan terurut di mana elemen kedua adalah 1, maka kita dapat menulis R sebagai:
R = {(x, y) | x ∈ D1, y ∈ D2, dan y = 1}
Dengan menggunakan himpunan yang sama ini, kita dapat membentuk relasi lain S di mana ele-
men pertama selalu dua kali elemen kedua. Dengan demikian, kita dapat menulis S sebagai:
S = {(x, y) | x ∈ D1, y ∈ D2, dan x = 2y}
atau, dalam hal ini,
S = {(2, 1)}
karena hanya ada satu pasangan terurut dalam produk Cartesian yang memenuhi kondisi ini. Kita
dapat dengan mudah memperluas gagasan tentang relasi ke tiga himpunan. Membiarkan D1, D2,
dan D3 menjadi tiga set. Produk Cartesian D1 X D2 X D3 dari tiga himpunan ini adalah himpunan
semua rangkap tiga sehingga elemen pertama berasal dari D1, elemen kedua berasal dari D2, dan
elemen ketiga adalah dari D3. Setiap bagian dari produk Cartesian ini adalah relasi. Sebagai contoh,
misalkan kita memiliki:
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 himpunan bagian dari rangkap tiga terurut ini adalah suatu relasi. Kita dapat mem-
perpanjang tiga set dan mendefinisikan hubungan umum pada n domain. Membiarkan D1, D2, . . .
,Dn menjadi n set. Produk Cartesian mereka didefinisikan sebagai:
D1 X D2 X . . . X Dn = {(D1, D2, . . . ,Dn)|D1 ∈ D1, D2 ∈ D2, . . . ,Dn ∈ Dn} dan biasanya
ditulis sebagai:
∏𝑛𝑖=𝐼 𝐷1
Setiap set n-tupel dari produk Cartesian ini adalah relasi pada n set. Perhatikan bahwa dalam
mendefinisikan hubungan ini kita harus menentukan himpunan, atau domain, dari mana kita mem-
ilih nilai.
4.2.3 Hubungan Basis Data
Menerapkan konsep yang telah dibahas sebelumnya ke database, kita dapat mendefinisikan
sebuah relasi skema
Hubungan skema -- Relasi bernama didefinisikan oleh satu set atribut dan pasangan nama do-
main.
Membiarkan A1, A2, . . . ,An menjadi atribut dengan domain D1, D2, . . . ,Dn. Maka himpunan
{A1:D1, A2:D2, . . . ,An:Dn} adalah skema relasi. Sebuah hubungan R didefinisikan oleh skema
relasi S adalah satu set pemetaan dari nama atribut ke domain yang sesuai. Jadi, relasi R adalah
sekumpulan n-tupel:
(A1:D1, A2:D2, . . . ,An:Dn) seperti yang D1 ∈ D1, D2 ∈ D2, . . . ,Dn ∈ Dn
Setiap elemen dalam n-tuple terdiri dari atribut dan nilai untuk atribut itu. Biasanya, ketika kita
menulis relasi sebagai tabel, kita mencantumkan nama atribut sebagai kolom judul dan tuliskan
tupel sebagai baris yang memiliki bentuk (D1, D2, . . . ,Dn), di mana setiap nilai diambil dari domain
yang sesuai. Dengan cara ini, kita dapat memikirkan suatu relasi dalam model relasional sebagai
bagian dari produk Cartesian dari domain atribut. Sebuah tabel hanyalah representasi fisik dari
relasi semacam itu.
Dalam contoh kita, Cabang relasi yang ditunjukkan pada Gambar 4.1 memiliki atribut
cabangNo, jalan, kota, dan Kode Pos, masing-masing dengan domain yang sesuai. Cabang relasi
adalah setiap subset dari produk Cartesian dari domain, atau setiap set empat-tupel di mana elemen
pertama berasal dari domain Nomor Cabang, yang kedua dari domain Nama Jalan, dan seterusnya.
Salah satu dari empat tupel adalah:
{(B005, 22 Deer Rd, London, SW1 4EH)}
atau lebih tepatnya:
{(cabangNo: B005, jalan: 22 Rusa Rd, kota: London, Kode Pos: SW1 4EH)}
Kami menyebutnya sebagai contoh relasi. Cabang tabel adalah cara mudah untuk menuliskan
semua empat tupel yang membentuk relasi pada waktu tertentu, yang menjelaskan mengapa baris
tabel dalam model relasional disebut "tupel". Dengan cara yang sama bahwa suatu relasi memiliki
skema, demikian pula database relasional.
Basis data relasional skema -- Satu set skema relasi, masing-masing dengan nama yang berbeda.
Jika R1, R2, . . . ,Rn adalah satu set skema relasi, maka kita dapat menulis skema basis data rela-
sional, atau hanya skema relasional, R, sebagai:
R = {R1, R2, . . . ,Rn}

4.2.4 Properties of Relations

Untuk mengilustrasikan apa arti pembatasan ini, pertimbangkan lagi hubungan Cabang yang
ditunjukkan pada Gambar 4.1. Karena setiap sel harus berisi hanya satu nilai, adalah ilegal untuk
menyimpan dua kode pos untuk satu kantor cabang dalam satu sel. Dengan kata lain, hubungan
tidak mengandung kelompok berulang. Hubungan yang memenuhi properti ini dikatakan dinor-
malisasi atau dalam bentuk normal pertama. (Formulir normal dibahas dalam Bab 14 dan 15.)
Nama kolom yang tercantum di bagian atas kolom sesuai dengan atribut hubungan. Nilai dalam
atribut branchNo semuanya berasal dari domain BranchNumbers; kita seharusnya tidak mengiz-
inkan nilai kode pos muncul di kolom ini. Tidak ada tuples duplikat dalam suatu hubungan. Misal-
nya, baris (B005, 22 Deer Rd, London, SW1 4EH) hanya muncul sekali.
Asalkan nama atribut dipindahkan bersama dengan nilai atribut, kita dapat bertukar kolom.
Tabel akan mewakili hubungan yang sama jika kita menempatkan atribut kota sebelum atribut
kode pos, meskipun untuk keterbacaan lebih masuk akal untuk menjaga elemen alamat dalam
urutan normal. Demikian pula, tuples dapat dipertukarkan, sehingga catatan cabang B005 dan
B004 dapat dialihkan dan hubungannya masih akan sama.
Sebagian besar properti yang ditentukan untuk hasil hubungan dari sifat-sifat hubungan ma-
tematika:
• Ketika kita memperoleh produk set Cartesian dengan elemen sederhana bernilai tunggal
seperti bilangan bulat, setiap elemen di setiap tuple bernilai tunggal. Demikian pula, setiap
sel dari suatu hubungan mengandung tepat satu nilai. Namun, hubungan matematis tidak
perlu dinormalisasi. Codd memilih untuk melarang kelompok berulang untuk menyeder-
hanakan model data relasional.
• Dalam suatu hubungan, nilai yang mungkin untuk posisi tertentu ditentukan oleh him-
punan, atau domain, di mana posisi didefinisikan. Dalam tabel, nilai di setiap kolom harus
berasal dari domain atribut yang sama.
 • Dalam satu set, tidak ada elemen yang diulang. Demikian pula, dalam suatu hubungan,
tidak ada tuples duplikat.
• Karena suatu hubungan adalah satu set, urutan elemen tidak memiliki arti penting. Oleh
karena itu, dalam suatu hubungan, urutan tuples tidak material.
Namun, dalam hubungan matematika, urutan elemen dalam tuple adalah penting. Misalnya,
pasangan yang dipesan (1, 2) sangat berbeda dari pasangan yang dipesan (2, 1). Ini tidak terjadi
pada hubungan dalam model relasional, yang secara khusus mensyaratkan bahwa urutan atribut
tidak material. Alasannya adalah bahwa judul kolom menentukan atribut mana yang menjadi milik
nilai tersebut. Ini berarti bahwa urutan judul kolom dalam intension tidak material, tetapi setelah
struktur hubungan dipilih, urutan elemen dalam tahap ekstensi harus sesuai dengan urutan nama
atribut.

4.2.5 Relational Keys

Seperti yang dinyatakan sebelumnya, tidak ada tanda duplikat dalam suatu hubungan. Oleh
karena itu, kita harus dapat mengidentifikasi satu atau lebih atribut (disebut kunci relasional) yang
secara unik mengidentifikasi setiap tuple dalam suatu hubungan. Pada bagian ini, kami menjelas-
kan terminologi yang digunakan untuk kunci relasional.
Superkey Atribut, atau serangkaian atribut, yang secara unik mengidentifikasi tuple dalam suatu
hubungan.
Superkey secara unik mengidentifikasi setiap tuple dalam suatu hubungan. Namun, superkey
mungkin berisi atribut tambahan yang tidak diperlukan untuk identifikasi unik, dan kami tertarik
untuk mengidentifikasi superkey yang hanya berisi jumlah minimum atribut yang diperlukan un-
tuk identifikasi unik.
Candidate key merupakan suatu atribut ataupun super key yang mengidentifikasi secara unik
untuk kejadian spesifik dari entitas
Candidate key K untuk hubungan R memiliki dua properti:
1. Keunikan. Dalam setiap tuple R, nilai-nilai K secara unik mengidentifikasi tuple itu.
2. Irreducibility. Tidak ada subset K yang tepat yang memiliki keunikan properti.
Mungkin ada beberapa kunci kandidat untuk suatu hubungan. Ketika kunci terdiri dari lebih
dari satu atribut, kita menyebutnya kunci komposit. Pertimbangkan hubungan Cabang yang
ditunjukkan pada Gambar 4.1. Mengingat nilai kota, kita dapat menentukan beberapa kantor
cabang (misalnya, London memiliki dua kantor cabang). Atribut ini tidak bisa menjadi kunci kan-
didat. Di sisi lain, karena DreamHome mengalokasikan setiap kantor cabang nomor cabang yang
unik, diberi nilai nomor cabang, cabangNo, kita dapat menentukan paling banyak satu tuple, se-
hingga cabangNo adalah kunci kandidat. Demikian pula, kode pos juga merupakan kunci kandidat
untuk hubungan ini.
Sekarang pertimbangkan hubungan Melihat, yang berisi informasi yang berkaitan dengan
properti yang dilihat oleh klien. Hubungan ini terdiri dari nomor klien (clientNo), nomor properti
(propertiNo), tanggal penayangan (viewDate) dan, secara opsional, komentar (komentar). Meng-
ingat nomor klien, klienTidak, mungkin ada beberapa tampilan yang sesuai untuk properti yang
berbeda. Demikian pula, mengingat nomor properti, properti Tidak, mungkin ada beberapa klien
yang melihat properti ini. Oleh karena itu, klienNo dengan sendirinya atau properti Tidak dengan
sendirinya tidak dapat dipilih sebagai kunci kandidat. Namun, kombinasi clientNo dan propertiNo
mengidentifikasi paling banyak satu tuple, jadi untuk hubungan Tampilan, klienNo dan properti
Tidak bersama-sama membentuk kunci kandidat (komposit). Jika kita perlu mempertimbangkan
kemungkinan bahwa klien dapat melihat properti lebih dari sekali, maka kita dapat menambahkan
viewDate ke kunci komposit. Namun, kami berasumsi bahwa ini tidak perlu.
Perhatikan bahwa contoh hubungan tidak dapat digunakan untuk membuktikan bahwa atribut
atau kombinasi atribut adalah kunci kandidat. Fakta bahwa tidak ada duplikat untuk nilai-nilai
yang muncul pada saat tertentu dalam waktu tidak menjamin bahwa duplikat tidak mungkin. Na-
mun, kehadiran duplikat dalam suatu contoh dapat digunakan untuk menunjukkan bahwa beberapa
kombinasi atribut bukanlah kunci kandidat. Mengidentifikasi kunci kandidat mengharuskan kita
mengetahui arti "dunia nyata" dari atribut yang terlibat sehingga kita dapat memutuskan apakah
duplikat itu mungkin. Hanya dengan menggunakan informasi semantik ini kita dapat yakin bahwa
kombinasi atribut adalah kunci kandidat. Misalnya, dari data yang disajikan dalam Gambar 4.1,
kita mungkin berpikir bahwa kunci kandidat yang cocok untuk hubungan Staf adalah IName, nama
keluarga karyawan. Namun, meskipun hanya ada satu nilai "Putih" dalam hal ini hubungan Staf,
anggota staf baru dengan nama keluarga "Putih" dapat bergabung dengan perusahaan, membatal-
kan pilihan IName sebagai kunci kandidat.
Primary Key Kunci kandidat yang dipilih untuk mengidentifikasi tuples secara unik dalam hub-
ungan
Karena suatu hubungan tidak memiliki tanda ganda duplikat, selalu mungkin untuk mengiden-
tifikasi setiap baris secara unik. Ini berarti bahwa suatu hubungan selalu memiliki kunci utama.
Dalam kasus terburuk, seluruh rangkaian atribut dapat berfungsi sebagai kunci utama, tetapi bi-
asanya beberapa subset yang lebih kecil cukup untuk membedakan tuples. Kunci kandidat yang
tidak dipilih untuk menjadi kunci utama disebut kunci alternatif. Untuk hubungan Cabang, jika
kita memilih cabangTidak sebagai kunci utama, kode pos kemudian akan menjadi kunci alternatif.
Untuk hubungan Tampilan, hanya ada satu kunci kandidat, yang terdiri dari clientNo dan proper-
tiNo, sehingga atribut ini akan secara otomatis membentuk kunci utama.

Foreign Key Atribut, atau serangkaian atribut, dalam satu hubungan yang sesuai dengan kunci
kandidat dari beberapa (mungkin sama) hubungan.
Ketika atribut muncul di lebih dari satu hubungan, penampilannya biasanya merupakan hub-
ungan antara tahap dari dua hubungan. Misalnya, masuknya cabangTidak baik dalam hubungan
Cabang dan Staf cukup disengaja dan menghubungkan setiap cabang dengan rincian staf yang
bekerja di cabang itu. Dalam hubungan Cabang, branchNo adalah kunci utama. Namun, dalam
hubungan Staf, atribut branchNo ada untuk mencocokkan staf dengan kantor cabang tempat
mereka bekerja. Dalam hubungan Staf, branchNo adalah kunci asing. Kami mengatakan bahwa
cabang atribut Tidak ada dalam hubungan Staf menargetkan cabang atribut kunci utama Tidak ada
dalam hubungan rumah, Cabang. Atribut umum ini memainkan peran penting dalam melakukan
manipulasi data, seperti yang kita lihat di bab berikutnya.
4.2.6 Mewakili Skema Basis Data Relasional
Sebuah database relasional terdiri dari sejumlah relasi yang dinormalisasi. Skema relasional
untuk bagian dariRumah impian studi kasus adalah:
Cabang (cabangNo, jalan, kota, kode pos)
Staf (Nostaf, fName, IName, posisi, jenis kelamin, DOB, gaji, branchNo)
Properti Disewakan (Noproperti, jalan, kota, kode pos, tipe, kamar, sewa, pemilikNo, staffNo,
branchNo)
Pemilik Pribadi (clientNo, fName, IName, telNo, prefType, maxRent, eMail)
Melihat (ownerNo, fName, IName, alamat, telNo, eMail, kata sandi)
Registrasi (clientNo, propertyNo, viewDate, komentar) (clientNo, branchNo, staffNo,
dateJoined)
Konvensi umum untuk merepresentasikan skema relasi adalah memberi nama relasi diikuti
dengan nama atribut dalam tanda kurung. Biasanya, kunci utama digarisbawahi.
NS model konseptual, atau skema konseptual, adalah himpunan semua skema tersebut untuk da-
tabase. Gambar 4.3 menunjukkan contoh skema relasional ini.

4.3 Kendala Integritas

Pada bagian sebelumnya, kita telah membahas bagian struktural dari model data relasional.
Sebagaimana dinyatakan dalam Bagian 2.3, model data memiliki dua bagian lain: bagian manipu-
latif, mendefinisikan jenis operasi yang diizinkan pada data, dan serangkaian batasan integritas,
yang memastikan bahwa data akurat. Pada bagian ini, kita membahas kendala integritas relasional,
dan dalam bab berikutnya, kita membahas operasi manipulasi relasional.
Kita telah melihat contoh batasan integritas di Bagian 4.2.1: karena setiap atribut memiliki
domain terkait, ada batasan (disebut batasan domain) yang membentuk batasan pada himpunan
nilai yang diizinkan untuk atribut relasi. Selain itu, ada dua hal pentingaturan integritas, yang
merupakan batasan atau batasan yang berlaku untuk semua instance database. Dua aturan utama
untuk model relasional dikenal sebagai integritas entitas danintegritas referensial. Jenis batasan
integritas lainnya adalahberagam, yang kita bahas di Bagian 12.6, dan kendala umum, yang kami
perkenalkan di Bagian 4.3.4. Sebelum kita mendefinisikan entitas dan integritas referensial, kita
perlu memahami konsep nulls.
4.3.1 NULLS
Null dapat diartikan sebagai nilai logika "tidak diketahui". Ini bisa berarti bahwa suatu nilai
tidak berlaku untuk tupel tertentu, atau itu bisa berarti bahwa belum ada nilai yang diberikan. Nulls
adalah cara untuk menangani data yang tidak lengkap atau luar biasa. Namun, null tidak sama
dengan nilai numerik nol atau string teks yang diisi dengan spasi; nol dan spasi adalah nilai, tetapi
nol mewakili ketiadaan nilai. Oleh karena itu, null harus diperlakukan berbeda dari nilai lainnya.
Beberapa penulis menggunakan istilah "nilai nol"; namun, karena null bukanlah nilai tetapi me-
wakili ketiadaan nilai, istilah "nilai nol" tidak digunakan lagi
Penggabungan null dalam model relasional adalah masalah yang diperdebatkan. Codd
kemudian menganggap null sebagai bagian integral dari model (Codd, 1990). Yang lain mengang-
gap pendekatan ini sesat, percaya bahwa masalah informasi yang hilang tidak sepenuhnya dipa-
hami, bahwa tidak ada solusi yang sepenuhnya memuaskan telah ditemukan dan, akibatnya, bahwa
penggabungan nol dalam model relasional adalah prematur (lihat, misalnya, Tanggal, 1995).

4.3.2 Intergritas Entitas

Menurut definisi, kunci utama adalah pengidentifikasi minimal yang digunakan untuk men-
gidentifikasi tupel secara unik. Ini berarti bahwa tidak ada subset dari kunci utama yang cukup
untuk memberikan identifikasi unik dari tupel. Jika kita mengizinkan null untuk setiap bagian dari
kunci utama, kita menyiratkan bahwa tidak semua atribut diperlukan untuk membedakan antara
tupel, yang bertentangan dengan definisi kunci utama. Misalnya, sebagai cabangNo adalah kunci
utama dari Cabang relasi, kita seharusnya tidak dapat menyisipkan tupel ke dalam relasi Cabang
dengan null untuk cabangNo atribut. Sebagai contoh kedua, pertimbangkan kunci primer komposit
dariMelihat relasi, yang terdiri dari nomor klien (klienTidak) dan nomor properti (propertiNo).
Kita seharusnya tidak dapat menyisipkan tupel ke dalamMelihat hubungan dengan nol untuk klien-
Tidak atribut, atau nol untuk propertiNo atribut, atau nol untuk kedua atribut.
Jika kita memeriksa aturan ini secara rinci, kita akan menemukan beberapa anomali. Pertama,
mengapa aturan hanya berlaku untuk kunci primer dan tidak lebih umum untuk kunci kandidat,
yang juga mengidentifikasi tupel secara unik? Kedua, mengapa aturan dibatasi pada relasi dasar?
Misalnya, dengan menggunakan dataMelihat hubungan yang ditunjukkan pada Gambar 4.3, per-
timbangkan kueri "Daftar semua komentar dari tampilan." Query ini akan menghasilkan relasi
unary yang terdiri dari atributkomentar. Menurut definisi, atribut ini harus menjadi kunci utama,
tetapi berisi nol (sesuai dengan tampilan pada PG36 dan PG4 oleh klien CR56). Karena relasi ini
bukan relasi dasar, model mengizinkan kunci utama menjadi nol. Ada beberapa upaya untuk
mendefinisikan kembali aturan ini (lihat, misalnya, Codd, 1988, dan Date, 1990).

4.3.3 Integritas Referensial

Aturan integritas kedua berlaku untuk kunci asing. Jika kunci asing ada dalam suatu relasi,
nilai kunci asing harus cocok dengan nilai kunci kandidat dari beberapa tupel dalam relasi asalnya
atau nilai kunci asing harus sepenuhnya nol. Referensi integritas Sebagai contoh, cabangNo dalam
Staf relasi adalah kunci asing yang menargetkan cabangNo atribut dalam relasi rumah, Cabang.
Seharusnya tidak mungkin membuat staf 4.4 Tampilan | 163 catatan dengan nomor cabang B025,
misalnya, kecuali jika sudah ada catatan untuk nomor cabang B025 di Cabang hubungan. Namun,
kita harus dapat membuat catatan staf baru dengan nomor cabang nol untuk memungkinkan situasi
di mana anggota staf baru telah bergabung dengan perusahaan tetapi belum ditugaskan ke kantor
cabang tertentu.

4.3.4 Kendala Umum

Dimungkinkan juga bagi pengguna untuk menentukan batasan tambahan yang harus dipenuhi
oleh data. Misalnya, jika batas atas 20 telah ditempatkan pada jumlah staf yang dapat bekerja di
kantor cabang, maka pengguna harus dapat menentukan batasan umum ini dan mengharapkan
DBMS untuk menerapkannya. Dalam hal ini, seharusnya tidak mungkin untuk menambahkan ang-
gota staf baru di cabang tertentu keStaf hubungan jika jumlah staf saat ini ditugaskan ke cabang
itu adalah 20. Sayangnya, tingkat dukungan untuk kendala umum bervariasi dari sistem ke sistem.
Kami membahas implementasi integritas relasional dalam 7 dan 18.

4.4 Tampilan
Dalam arsitektur ANSI-SPARC tiga tingkat yang disajikan dalam Bab 2, kami menggam-
barkan tampilan eksternal sebagai struktur database seperti yang terlihat oleh pengguna tertentu.
Dalam model relasional, kata "pandangan" memiliki arti yang sedikit berbeda. Alih-alih menjadi
keseluruhan model eksternal dari tampilan pengguna, tampilan adalahMaya atau relasi turunan:
suatu relasi yang tidak selalu ada dengan sendirinya, tetapi dapat diturunkan secara dinamis dari
satu atau lebih relasi dasar. Dengan demikian, model eksternal dapat terdiri dari hubungan dasar
(tingkat konseptual) dan pandangan yang diturunkan dari hubungan dasar. Pada bagian ini, kita
membahas secara singkat pandangan dalam sistem relasional. Di bagian 7.4 kami memeriksa
tampilan secara lebih rinci dan menunjukkan bagaimana mereka dapat dibuat dan digunakan dalam
SQL

4.4.1 Terminologi
Hubungan yang telah kita bahas sejauh ini dalam bab ini dikenal sebagai hubungan dasar. Basis
hubungan Relasi bernama yang sesuai dengan entitas dalam skema konseptual, yang tupelnya
disimpan secara fisik dalam database. Kita dapat mendefinisikan pandangan dalam hal hubungan
dasar. Hasil dinamis dari satu atau lebih operasi relasional yang beroperasi pada relasi dasar untuk
menghasilkan relasi lain. Pemandangan adalahhubungan maya yang tidak selalu ada dalam data-
base tetapi dapat diproduksi atas permintaan oleh pengguna tertentu, pada saat permintaan.
Tampilan adalah relasi yang tampak bagi pengguna, dapat dimanipulasi seolah-olah itu adalah
relasi dasar, tetapi tidak harus ada dalam penyimpanan dalam arti bahwa relasi dasar memang ada
(walaupun definisinya disimpan dalam katalog sistem) . Konten tampilan didefinisikan sebagai
kueri pada satu atau beberapa relasi dasar. Setiap operasi pada tampilan secara otomatis diter-
jemahkan ke dalam operasi pada hubungan dari mana ia berasal. Tampilan adalahdinamis, artinya
perubahan yang dilakukan pada hubungan dasar yang memengaruhi tampilan langsung tercermin
dalam tampilan. Saat pengguna membuat perubahan yang diizinkan pada tampilan, perubahan ini
dilakukan pada relasi yang mendasarinya. Di bagian ini, kami menjelaskan tujuan penayangan dan
memeriksa secara singkat batasan yang berlaku untuk pembaruan yang dilakukan melalui pe-
nayangan. Namun, kami menunda perlakuan tentang bagaimana tampilan didefinisikan dan di-
proses hingga Bagian 7.4.
4.4.2 Tujuan Tampilan
• Ini menyediakan mekanisme keamanan yang kuat dan fleksibel dengan menyembunyikan ba-
gian dari database dari pengguna tertentu. Pengguna tidak menyadari adanya atribut atau tupel
yang hilang dari tampilan.
• Ini memungkinkan pengguna untuk mengakses data dengan cara yang disesuaikan dengan
kebutuhan mereka, sehingga data yang sama dapat dilihat oleh pengguna yang berbeda dengan
cara yang berbeda, pada waktu yang sama
• Hal ini dapat menyederhanakan operasi kompleks pada hubungan dasar. Misalnya, jika view
didefinisikan sebagai kombinasi (join) dari dua relasi (lihat Bagian 5.1), pengguna sekarang
dapat melakukan operasi yang lebih sederhana pada view, yang akan diterjemahkan oleh
DBMS ke dalam operasi yang setara pada join.

Tampilan harus dirancang untuk mendukung model eksternal yang dianggap familier oleh
pengguna. Sebagai contoh:
• Seorang pengguna mungkin memerlukan tupel Cabang yang berisi nama manajer serta atribut
lain yang sudah ada di Cabang. Tampilan ini dibuat dengan menggabungkan relasi Cabang
dengan bentuk terbatas dariStaf hubungan di mana posisi staf adalah "Manajer."
• Beberapa anggota staf harus melihat Staf tupel tanpa gaji atribut
• Atribut dapat diganti namanya atau urutan atribut diubah. Misalnya, pengguna terbiasa me-
manggilcabangNo atribut cabang dengan nama lengkap Nomor cabang mungkin melihat judul
kolom itu
• Beberapa anggota staf harus melihat catatan properti hanya untuk properti yang mereka Kelola

Meskipun semua contoh ini menunjukkan bahwa pandangan memberikan independensi data
logis (lihat Bagian 2.1.5), tampilan memungkinkan jenis independensi data logis yang lebih sig-
nifikan yang mendukung reorganisasi skema konseptual. Misalnya, jika atribut baru ditambahkan
ke relasi, pengguna yang ada bisa tidak menyadari keberadaannya jika pandangan mereka didefin-
isikan untuk mengecualikannya. Jika relasi yang ada disusun ulang atau dipisahkan, tampilan dapat
ditentukan sehingga pengguna dapat terus melihat tampilan aslinya. Kita akan melihat contohnya
di Bagian 7.4.7 ketika kita membahas kelebihan dan kekurangan pandangan secara lebih rinci.
4.4.3 Memperbarui Tampilan
Semua pembaruan pada relasi dasar harus segera direfleksikan dalam semua tampilan yang
mereferensikan relasi basis tersebut.
• Pembaruan tidak diperbolehkan melalui tampilan yang melibatkan banyak relasi dasar.
• Pembaruan tidak diperbolehkan melalui tampilan yang melibatkan operasi agregasi atau penge-
lompokan.
Kelas tampilan telah ditentukan yang secara teoritis tidak dapat diperbarui, dapat diperbarui
secara teoritis, dan dapat diperbarui sebagian.

Ringkasan Bab
• Relational Database Management System (RDBMS) telah menjadi perangkat lunak pem-
rosesan data yang dominan digunakan saat ini, dengan perkiraan penjualan lisensi baru antara
US$6 miliar dan US$10 miliar per tahun (US$25 miliar termasuk penjualan alat). Perangkat lunak
ini mewakili DBMS generasi kedua dan didasarkan pada model data relasional yang diusulkan
oleh E. F. Codd.
• Relasi matematis adalah subset dari produk Cartesian dari dua atau lebih set. Dalam istilah
database, relasi adalah setiap subset dari produk Cartesian dari domain atribut. Suatu relasi bi-
asanya ditulis sebagai himpunan n-tupel, di mana setiap elemen dipilih dari domain yang sesuai.
• Relasi secara fisik direpresentasikan sebagai tabel, dengan baris yang sesuai dengan tupel
individu dan kolom untuk atribut.
• Struktur relasi, dengan spesifikasi domain dan batasan lainnya, merupakan bagian dari tujuan
database; relasi dengan semua tupelnya yang ditulis mewakili sebuah instance atau ekstensi dari
database.
• Properti relasi database adalah: setiap sel berisi tepat satu nilai atom, nama atribut berbeda,
nilai atribut berasal dari domain yang sama, urutan atribut tidak penting, urutan tupel tidak penting,
dan tidak ada tupel duplikat.
• Derajat suatu relasi adalah jumlah atribut, dan kardinalitas adalah jumlah tupel. Relasi unary
memiliki satu atribut, relasi biner memiliki dua, relasi terner memiliki tiga, dan relasi n-ary mem-
iliki n atribut.
 • Superkey adalah atribut, atau kumpulan atribut, yang mengidentifikasi tupel dari relasi
secara unik, dan kunci kandidat adalah superkey minimal. Kunci utama adalah kunci kandidat
yang dipilih untuk digunakan dalam identifikasi tupel. Suatu relasi harus selalu memiliki primary
key. Kunci asing adalah atribut, atau kumpulan atribut, dalam satu relasi yang merupakan kunci
kandidat dari relasi lain.
• Sebuah null mewakili nilai untuk atribut yang tidak diketahui pada saat ini atau tidak berlaku
untuk tupel ini.
• integritas entitas adalah batasan yang menyatakan bahwa dalam relasi dasar tidak ada atribut
dari kunci utama yang dapat bernilai nol. Integritas referensial menyatakan bahwa nilai kunci asing
harus cocok dengan nilai kunci kandidat dari beberapa tupel dalam relasi asal atau sepenuhnya
nol. Terlepas dari integritas relasional, batasan integritas termasuk data yang diperlukan, domain,
dan batasan multiplisitas; batasan integritas lainnya disebut batasan umum.
• Tampilan dalam model relasional adalah relasi virtual atau turunan yang dibuat secara dina-
mis dari relasi dasar yang mendasarinya bila diperlukan. Tampilan memberikan keamanan dan
memungkinkan perancang untuk menyesuaikan model pengguna. Tidak semua tampilan dapat di-
perbarui.