LECTURE NOTES

ISYS6508
Database System

Week 4

Normalization

ISYS6508 – Database System

 LEARNING OUTCOMES

LO2: Design conceptual database

OUTLINE MATERI (Sub-Topic):

1. The Purpose Normalization

2. How Normalization Support Database Design

3. Data Redudancy and Update Anomaly

4. Functional Dependencies

5. The Process of Normalization

ISYS6508 – Database System

 ISI MATERI

Introduction
Ketika kami mendesain database untuk suatu perusahaan, tujuan utamanya adalah
untuk membuat representasi akurat dari data, hubungan antara data, dan kendala pada data
yang berkaitan dengan perusahaan. Untuk membantu mencapai tujuan ini, kita dapat
menggunakan satu atau lebih teknik desain basis data. Dalam bab ini dan selanjutnya kami
menjelaskan teknik desain database lain yang disebut normalisasi.
Normalisasi adalah teknik desain database yang dimulai dengan memeriksa hubungan
(disebut fungsional dependensi) antar atribut. Atribut menggambarkan beberapa properti data
atau hubungan antar data yang penting bagi perusahaan. Normalisasi menggunakan
serangkaian tes (digambarkan sebagai bentuk normal) untuk membantu mengidentifikasi
pengelompokan yang optimal untuk setiap atribut pada akhirnya mengidentifikasi satu set
hubungan yang sesuai yang mendukung persyaratan data perusahaan.
Ciri-ciri dari relasi yang sesuai mencakup hal-hal berikut:
 jumlah minimum atribut yang diperlukan untuk mendukung persyaratan data
perusahaan.
 atribut dengan hubungan logis yang dekat (digambarkan sebagai ketergantungan
fungsional) ditemukan dalam relasi yang sama.
 redundansi minimal, dengan masing-masing atribut diwakili hanya sekali, dengan
pengecualian penting dari atribut yang membentuk semua atau sebagian dari foreign
key, yang penting untuk bergabungnya relasi terkait.
Manfaat menggunakan basis data yang memiliki himpunan relasi yang sesuai adalah
bagi pengguna memudahkan untuk mengakses dan memelihara data, serta mengambil ruang
penyimpanan minimal di komputer. Masalah yang terkait dengan penggunaan relasi yang
tidak normal dinormalisasi dijelaskan berikutnya.

How Normalization Supports Database Design

Normalisasi adalah teknik formal yang dapat digunakan pada setiap tahap desain
database. Namun, pada bagian ini kami menyoroti dua pendekatan utama untuk

ISYS6508 – Database System

menggunakan normalisasi, seperti yang diilustrasikan pada Gambar 4.1. Pendekatan 1
menunjukkan bagaimana normalisasi dapat digunakan sebagai teknik desain database yang
berdiri sendiri dari bawah ke atas, dan Pendekatan 2 menunjukkan bagaimana normalisasi
dapat digunakan sebagai teknik validasi untuk memeriksa struktur hubungan, yang mungkin
telah dibuat menggunakan pendekatan top-down seperti sebagai pemodelan ER. Tidak peduli
pendekatan apa yang digunakan, tujuannya sama; menciptakan serangkaian hubungan yang
dirancang dengan baik yang memenuhi persyaratan data perusahaan.
Gambar 4.1 menunjukkan contoh sumber data yang dapat digunakan untuk desain
database. Meskipun spesifikasi kebutuhan pengguna adalah sumber data pilihan,
dimungkinkan untuk merancang basis data berdasarkan informasi yang diambil langsung dari
sumber data lain, seperti formulir dan laporan, Gambar 4.1 juga menunjukkan bahwa sumber
data yang sama dapat digunakan untuk kedua pendekatan. Namun, meskipun ini benar pada
prinsipnya, dalam prakteknya pendekatan yang diambil cenderung ditentukan oleh ukuran,
luas, dan kompleksitas dari database yang dijelaskan oleh sumber data dan oleh preferensi
dan keahlian dari perancang database. Kesempatan untuk menggunakan normalisasi sebagai
teknik mandiri bottom-up (Pendekatan 1) sering dibatasi oleh tingkat detail yang diharapkan
dapat dikelola oleh perancang database. Namun, pembatasan ini tidak berlaku ketika
normalisasi digunakan sebagai teknik validasi (Approach 2), karena perancang basis data
berfokus hanya pada bagian dari database, seperti relasi tunggal, pada satu waktu. Oleh
karena itu, tidak peduli apa ukuran atau kompleksitas dari database, normalisasi dapat
diterapkan untuk pemanfaatan.

ISYS6508 – Database System

 Gambar 4.1 Bagaimana normalisasi dapat digunakan untuk mendukung desain database

Data Redundancy and Update Anomalies

Sebagaimana dinyatakan pada awal LN 4 ini, tujuan utama desain database relasional
adalah untuk mengelompokkan atribut ke dalam relasi untuk meminimalkan redundansi data.
Jika tujuan ini tercapai, manfaat potensial untuk database yang diimplementasikan termasuk
yang berikut ini:
 update data yang disimpan dalam database dicapai dengan jumlah operasi minimal,
sehingga mengurangi peluang untuk inkonsistensi data yang terjadi dalam database.
 pengurangan ruang penyimpanan file yang dibutuhkan oleh hubungan dasar sehingga
meminimalkan biaya.
Tentu saja, database relasional juga bergantung pada keberadaan sejumlah redundansi
data. Redundansi ini dalam bentuk salinan primary key (atau candidate key) yang bertindak
sebagai foreign key dalam relasi yang memungkinkan pemodelan relasi antar data.
Contoh ilustrasi redundancy data pada relasi Branch dan Staff pada gambar 4.2 dan
4.3 sesuai dengan ilustrasi:
Staff (staffNo, sName, position, salary, branchNo)
Branch (branchNo, bAddress)

ISYS6508 – Database System

 StaffBranch (staffNo, sName, position, salary, branchNo, bAddress)

Gambar 4.2 Tabel Staff dan Branch

Gambar 4.3 Relasi Staff dan Branch

Dalam hubungan StaffBranch ada data yang berlebihan; rincian cabang diulangi untuk
setiap anggota Staff yang ada di Branch tersebut. Sebaliknya, rincian branch hanya muncul
sekali untuk setiap branch dalam hubungan Branch, dan hanya nomor branch (branchNo)
yang diulang dalam relasi Staff untuk mewakili di mana setiap anggota staf berada.
Hubungan yang memiliki data redundan mungkin memiliki masalah yang disebut update
anomali, yang diklasifikasikan sebagai penyisipan (insertion), penghapusan (deletion), atau
modifikasi (modification).

ISYS6508 – Database System

Insertion Anomalies
Ada dua jenis utama dari anomali penyisipan, yang kami ilustrasikan menggunakan
hubungan StaffBranch yang ditunjukkan pada Gambar 4.3:
 Untuk memasukkan anggota staf baru ke dalam relasi StaffBranch, kita harus
menyertakan rincian branch tempat staf akan ditempatkan. Misalnya, untuk
memasukkan rincian staf baru yang terletak di nomor branch B007, kita harus
memasukkan rincian yang benar dari nomor cabang B007 sehingga rincian cabang
konsisten dengan nilai untuk cabang B007, di tupel lain dari hubungan StaffBranch.
Hubungan yang ditunjukkan pada Gambar 4.2 tidak mengalami inkonsistensi
potensial, karena kami hanya memasukkan nomor cabang yang sesuai untuk setiap
anggota staf dalam relasi Staff. Sebagai gantinya, rincian nomor cabang B007 dicatat
dalam basis data sebagai tupel tunggal dalam relasi Branch.
 Untuk memasukkan cabang baru yang saat ini tidak memiliki anggota staf ke dalam
relasi StaffBranch, perlu memasukkan nol ke dalam atribut untuk staf, seperti StafNo.
Namun, staffNo adalah kunci utama untuk hubungan StaffBranch, mencoba
memasukkan nol untuk staf, Tidak melanggar integritas entitas (lihat Bagian 4.3), dan
tidak diperbolehkan. Oleh karena itu kami tidak dapat memasukkan tuple untuk
cabang baru ke dalam hubungan StaffBranch dengan null untuk staffNo. Rancangan
relasi yang ditunjukkan pada Gambar 4.2 menghindari masalah ini, karena rincian
cabang dimasukkan dalam hubungan Cabang secara terpisah dari rincian staf. Rincian
staf yang pada akhirnya terletak di cabang tersebut dimasukkan di kemudian hari ke
dalam relasi Staff.

Deletion Anomalies
Jika kita menghapus tuple dari relasi StaffBranch yang mewakili anggota staf terakhir
yang terletak di cabang, detail tentang cabang tersebut juga hilang dari database. Misalnya,
jika kita menghapus tupel untuk nomor staf SA9 (Mary Howe) dari relasi StaffBranch, detail
yang berkaitan dengan nomor cabang B007 hilang dari database. Desain dari hubungan di
Gambar 4.2. untuk menghindari masalah ini, karena tupel cabang disimpan secara terpisah
dari staf tupel dan hanya atribut branchNo berkaitan dua relasi. Jika kita menghapus tupel
untuk nomor staf SA9 dari relasi Staf, rincian nomor cabang B007 tetap tidak terpengaruh
dalam relasi Branch.

ISYS6508 – Database System

Modification Anomalies
Jika kita ingin mengubah nilai salah satu atribut dari cabang tertentu dalam hubungan
StaffBranch — misalnya, alamat untuk nomor cabang B003 — kita harus memperbarui tupel
semua staf yang ada di cabang tersebut. Jika modifikasi ini tidak dilakukan pada semua tupel
yang sesuai dari relasi StaffBranch, basis data akan menjadi tidak konsisten. Dalam contoh
ini, nomor cabang B003 mungkin tampak memiliki alamat berbeda dalam tupel staf yang
berbeda.
Contoh sebelumnya menggambarkan bahwa hubungan Staff dan Branch Gambar 4.2
memiliki lebih banyak sifat yang diinginkan daripada hubungan StaffBranch dari Gambar
4.3. Ini menunjukkan bahwa meskipun hubungan StaffBranch tunduk pada pembaruan
anomali, kita dapat menghindari anomali ini dengan menguraikan relasi asli ke dalam
hubungan Staff dan Branch. Ada dua sifat penting yang terkait dengan dekomposisi
hubungan yang lebih besar menjadi hubungan yang lebih kecil:
 Properti lossless-join memastikan bahwa setiap contoh dari relasi asli dapat
diidentifikasi dari contoh yang sesuai dalam relasi yang lebih kecil.
 Properti dependency preservation memastikan bahwa kendala pada relasi asli dapat
dipertahankan hanya dengan menegakkan beberapa kendala pada masing-masing
relasi yang lebih kecil. Dengan kata lain, kita tidak perlu melakukan gabungan pada
relasi yang lebih kecil untuk memeriksa apakah kendala pada relasi asli dilanggar

Functional Dependencies
Konsep penting yang terkait dengan normalisasi adalah ketergantungan fungsional,
yang menggambarkan hubungan antar atribut (Maier, 1983). Pada bagian ini kami
mendeskripsikan ketergantungan fungsional dan kemudian fokus pada karakteristik khusus
dari dependensi fungsional yang berguna untuk normalisasi. Kami kemudian mendiskusikan
bagaimana ketergantungan fungsional dapat diidentifikasi dan digunakan untuk
mengidentifikasi kunci utama untuk suatu relasi.

Characteristics of Functional Dependencies

Functional Dependencies adalah menggambarkan hubungan antara atribut dalam
suatu relasi. Misalnya, jika a dan B adalah atribut relasi r, B secara fungsional bergantung
pada (dilambangkan a ® B), jika setiap nilai a dikaitkan dengan tepat satu nilai B. (a dan B

ISYS6508 – Database System

masing-masing terdiri dari satu atau lebih banyak atribut). Ketergantungan fungsional adalah
properti dari makna atau semantik dari atribut dalam relasi. Semantik menunjukkan
bagaimana atribut berhubungan satu sama lain, dan menentukan ketergantungan fungsional
antar atribut. Ketika ada ketergantungan fungsional, ketergantungan ditentukan sebagai
kendala antara atribut. Cara alternatif adalah untuk menggambarkan hubungan antara atribut
a dan B adalah dengan mengatakan bahwa "a secara fungsional menentukan B". Beberapa
pembaca mungkin lebih suka deskripsi ini, karena lebih alami mengikuti arah panah
ketergantungan fungsional antara atribut.
Determinant adalah mengacu pada atribut, atau kelompok atribut, di sisi kiri panah
Determinan adalah ketergantungan fungsional. Ketika ada ketergantungan fungsional, atribut
atau kelompok atribut di sisi kiri panah disebut determinan. Sebagai contoh, pada Gambar
4.4, a adalah penentu B.

Gambar 4.4 diagram ketergantungan fungsional

Gambar 4.5 (A) staffNo secara fungsional menentukan posisi (posisi staffNo ®); (B) posisi tidak
secara fungsional menentukan staffNo (position®x staffNo)

Full Functional Dependencies adalah Menunjukkan bahwa jika a dan B adalah

atribut dari suatu relasi, B bergantung secara penuh pada A, jika B bergantung secara
fungsional pada A, tetapi tidak pada subset yang benar dari a. Ketergantungan fungsional a ®
B adalah ketergantungan fungsional penuh jika penghapusan atribut apa pun dari hasil dalam

ISYS6508 – Database System

ketergantungan tidak ada lagi. Ketergantungan parsial (partial dependencies) a ® B
adalah jika ada beberapa atribut yang dapat dihapus dari namun ketergantungan masih
bertahan.
Sejauh ini kita telah membahas ketergantungan fungsional yang kita minati untuk
keperluan normalisasi. Namun, ada tambahan jenis ketergantungan fungsional yang disebut
ketergantungan transitif yang perlu kita kenali, karena keberadaannya dalam suatu relasi
dapat berpotensi menyebabkan jenis update anomali yang dibahas dalam Bagian 4.3. Di
bagian ini kami hanya menggambarkan dependensi ini sehingga kami dapat mengidentifikasi
ketergantungan transitif bila diperlukan. Ketergantungan transitif (transitive
dependencies) adalah suatu kondisi di mana a, B, dan C adalah atribut dari suatu hubungan
sedemikian rupa sehingga jika a B dan B ® C, maka C secara transitif bergantung pada via B
(dengan ketentuan bahwa tidak tergantung secara fungsional pada B atau C).
Identifying the Primary Key for a Relation Using Functional Dependencies
adalah Tujuan utama mengidentifikasi satu set dependensi fungsional untuk suatu relasi
adalah untuk menentukan rangkaian batasan integritas yang harus dipegang pada suatu relasi.
Batasan integritas penting yang perlu dipertimbangkan pertama adalah identifikasi kunci
kandidat, salah satunya dipilih untuk menjadi kunci utama untuk relasinya.

The Process of Normalization

Normalisasi adalah teknik formal untuk menganalisis hubungan berdasarkan kunci
utama (atau kunci kandidat) dan dependensi fungsional (Codd, 1972b). Teknik ini melibatkan
serangkaian aturan yang dapat digunakan untuk menguji hubungan individu sehingga
database dapat dinormalkan ke tingkat apa pun. Ketika suatu persyaratan tidak dipenuhi,
hubungan yang melanggar persyaratan harus diuraikan menjadi relasi yang secara individual
memenuhi persyaratan normalisasi.
Tiga bentuk normal awalnya diusulkan disebut First Normal Form (1NF), Second
Normal Form (2NF), dan Third Normal Form (3NF). Selanjutnya, R. Boyce dan E. F. Codd
memperkenalkan definisi yang lebih kuat dari bentuk normal ketiga yang disebut Boyce-
Codd Normal Form (BCNF) (Codd, 1974). Dengan pengecualian 1NF, semua bentuk normal
ini didasarkan pada ketergantungan fungsional di antara atribut relasi (Maier, 1983). Bentuk
normal yang lebih tinggi yang melampaui BCNF diperkenalkan kemudian seperti Keempat
Bentuk Normal (4NF) dan Formulir Normal Kelima (5NF) (Fagin, 1977, 1979). Namun,

ISYS6508 – Database System

bentuk-bentuk normal kemudian ini berhubungan dengan situasi yang sangat langka. Dalam
bab ini kami hanya mendeskripsikan tiga bentuk normal pertama dan meninggalkan diskusi
tentang BCNF, 4NF, dan 5NF ke bab berikutnya.
Normalisasi sering dilakukan sebagai serangkaian langkah. Setiap langkah sesuai
dengan bentuk normal tertentu yang memiliki sifat yang dikenal. Ketika normalisasi
berlangsung, hubungan menjadi semakin lebih terbatas (lebih kuat) dalam format dan juga
tidak rentan terhadap update anomali. Untuk model data relasional, sangat penting untuk
mengenali bahwa itu hanya Bentuk Normal Pertama (1NF) yang sangat penting dalam
menciptakan hubungan; semua bentuk normal berikutnya adalah opsional. Namun, untuk
menghindari update anomaly yang dibahas sebelumnya, umumnya disarankan agar kita
melanjutkan ke setidaknya Formulir Normal Ketiga (3NF). Gambar 4.7 menggambarkan
hubungan antara berbagai bentuk normal. Ini menunjukkan bahwa beberapa hubungan 1NF
juga ada dalam 2NF, dan beberapa hubungan 2NF juga ada di 3NF, dan seterusnya.

Gambar 4.6 Diagram ilustrasi antara relasi dengan normal form

ISYS6508 – Database System

 Gambar 4.7 Diagram Ilustrasi proses normalisasi

Dalam Bab ini, kami mendeskripsikan normalisasi sebagai teknik bottom-up yang
mengekstraksi informasi tentang atribut dari bentuk sampel yang pertama kali
ditransformasikan ke dalam format tabel, yang dideskripsikan sebagai dalam bentuk tidak
dikenal (UNF). Tabel ini kemudian mengalami progresif ke persyaratan yang berbeda yang
terkait dengan setiap bentuk normal sampai akhirnya atribut yang ditunjukkan dalam bentuk
sampel asli diwakili sebagai serangkaian hubungan 3NF. Meskipun contoh yang digunakan
dalam bab ini berasal dari bentuk normal yang diberikan ke yang di atas, ini tidak selalu
terjadi dengan contoh lain. Seperti yang ditunjukkan pada Gambar 13.8, resolusi masalah
tertentu dengan, katakanlah, hubungan 1NF dapat mengakibatkan relasi ditransformasikan ke
hubungan 2NF, atau dalam beberapa kasus secara langsung menjadi 3NF hubungan dalam
satu langkah.
Untuk menyederhanakan uraian normalisasi, kita mengasumsikan bahwa satu set
dependensi fungsional diberikan untuk setiap relasi dalam contoh yang dikerjakan dan setiap
relasi memiliki kunci primer yang ditentukan. Dengan kata lain, penting bahwa makna atribut
dan hubungan mereka dipahami dengan baik sebelum memulai proses normalisasi. Informasi
ini penting untuk normalisasi dan digunakan untuk menguji apakah suatu relasi dalam bentuk
normal tertentu. Kita mulai dengan menggambarkan Bentuk Normal Pertama (1NF).

ISYS6508 – Database System

Berikutnya kami mendeskripsikan Bentuk Normal Kedua (2NF) dan Bentuk Normal Ketiga
(3NF) berdasarkan pada kunci utama dari suatu relasi dan kemudian menyajikan definisi
yang lebih umum dari masing-masing. Definisi yang lebih umum dari 2NF dan 3NF
mempertimbangkan semua kunci kandidat dari suatu relasi, bukan hanya kunci primer.

First Normal Form (1NF)

Sebelum membahas First Normal Form (1NF), kami memberikan definisi tentang
keadaan sebelum First Normal Form (1NF). Unnormalized Form (UNF) adalah sebuah tabel
yang berisi satu atau lebih grup yang berulang. First Normal Form (1NF) adalah suatu relasi
di mana perpotongan setiap baris dan kolom berisi satu dan hanya satu nilai.

Gambar 4.8 Unnormalized Form dari ClientRental

Masih ada beberapa baris dari tabel yang kosong, pada kolom clientNo dan cName
dan masih ada beberapa baris yang berulang, seperti pada kolom oName. Tabel inilah yang
disebut sebagai Unnormalized Form (UNF). Langkah selanjutnya lakukan normalisasi ke
First Normal Form (1NF).

ISYS6508 – Database System

 Gambar 4.9 First Normal Form (1NF)

Pada tabel 1NF seluruh baris terisi semua dan perulangan masih terjadi, pada saat
1NF candidate key dan functional dependency mulai terlihat. Beberapa candidate key adalah
clientNo, propertyNo, ownerNo.

Second Normal Form (2NF)

Secon Normal Form (2NF) adalah suatu relasi yang dalam bentuk normal pertama dan
setiap atribut non-primary-key secara fungsional tergantung pada kunci primer. Bentuk
Normal Kedua (2NF) didasarkan pada konsep ketergantungan fungsional penuh, yang kami
uraikan di sebelumnya. Bentuk normal kedua berlaku untuk hubungan dengan kunci
komposit, yaitu hubungan dengan kunci primer yang terdiri dari dua atau lebih atribut.
Hubungan dengan kunci primer satu-atribut secara otomatis setidaknya 2NF. Suatu relasi
yang tidak ada dalam 2NF mungkin mengalami anomali pembaruan yang dibahas dalam
Bagian sebelumnya Sebagai contoh, misalkan kita ingin mengubah sewa nomor properti
PG4. Kami harus memperbarui dua tupel di relasi ClientRental pada Gambar 4.8. Jika hanya
satu tupel diperbarui dengan sewa baru, ini menghasilkan inkonsistensi dalam database.

ISYS6508 – Database System

 Gambar 4.10 Second Normal Form (2NF)

Third Normal Form (3NF)

Third Normal Form (3NF) adalah Suatu relasi yang dalam bentuk normal pertama dan
kedua dan di mana tidak ada atribut non-primary-key yang secara transitif bergantung pada
kunci primer. Meskipun hubungan 2NF memiliki lebih sedikit redundansi dibandingkan
dengan 1NF, mereka mungkin masih mengalami pembaruan anomali. Misalnya, jika kami
ingin memperbarui nama pemilik, seperti Tony Shaw (ownerNo CO93), kami harus
memperbarui dua tupel di relasi PropertyOwner pada Gambar 4.10. Jika kita memperbarui
hanya satu tuple dan bukan yang lain, database akan berada dalam keadaan yang tidak
konsisten. Anomali pembaruan ini disebabkan oleh ketergantungan transitif, yang kami
jelaskan di Bagian sebelumnya. Kita perlu menghapus dependensi tersebut dengan maju ke
bentuk normal ketiga.

ISYS6508 – Database System

Gambar 4.11 Third Normal Form (3NF)

ISYS6508 – Database System

 SIMPULAN

Kesimpulan dari materi ini adalah:

1. Normalisasi adalah teknik untuk menghasilkan satu set hubungan dengan sifat yang
diinginkan, mengingat persyaratan data dari suatu perusahaan. Normalisasi adalah
metode formal yang dapat digunakan untuk mengidentifikasi hubungan berdasarkan
kunci relasi dan dependensi fungsional relasi antar atribut.
2. Normalisasi dilakukan untuk menghindari update anomali, yang diklasifikasikan
sebagai penyisipan (insertion), penghapusan (deletion), atau modifikasi
(modification).
3. Proses normalisasi dengan menggambarkan Bentuk Normal Pertama (1NF).
Berikutnya kami mendeskripsikan Bentuk Normal Kedua (2NF) dan Bentuk Normal
Ketiga (3NF) berdasarkan pada kunci utama dari suatu relasi dan kemudian
menyajikan definisi yang lebih umum.
4. Unnormalized Form (UNF) adalah tabel yang berisi satu atau lebih grup yang
berulang.
5. Bentuk Normal Pertama (1NF) adalah hubungan di mana perpotongan setiap baris dan
kolom berisi satu dan hanya satu nilai.
6. Bentuk Normal Kedua (2NF) adalah relasi yang dalam bentuk normal pertama dan
setiap atribut non-kunci utama secara fungsional sepenuhnya bergantung pada kunci
primer. Definisi umum untuk Bentuk Normal Kedua (2NF) adalah relasi yang dalam
bentuk normal pertama dan setiap atribut non-kandidat-kunci sepenuhnya tergantung
pada kunci kandidat.
7. Bentuk Normal Ketiga (3NF) adalah relasi yang dalam bentuk normal pertama dan
kedua di mana tidak ada atribut non-primary key yang secara transitif bergantung
pada kunci primer. Definisi umum untuk Bentuk Normal Ketiga (3NF) adalah relasi
yang dalam bentuk normal pertama dan kedua di mana tidak ada atribut non-kandidat-
kunci yang secara transitif bergantung pada kunci kandidat.

ISYS6508 – Database System

 DAFTAR PUSTAKA

Connolly, T., & Begg, C. (2015). Database System A Practical Approach to Design,
Implemetation, and Management 6th Edition. Pearson

ISYS6508 – Database System