Dasar basis data

Halaman Judul

HALAMAN JUDUL

BUKU AJAR

DASAR BASIS DATA

Di susun oleh :
Dwi Puspitasari, S.Kom

Dibiayai :

PROGRAM PENGUATAN BIDANG KEILMUAN DIPA 2007

PROGRAM STUDI MANAJEMEN INFORMATIKA
JURUSAN TENIK ELEKTRO
POLITEKNIK NEGERI MALANG
TAHUN 2007

Dwi Puspitasari, S.Kom, Program Studi Manajemen Informatika i

Kata Pengantar

KATA PENGANTAR

Dengan mengucap syukur Alhamdulillah, akhirnya selesai juga
pembuatan buku ajar dengan judul “Dasar Basis Data”. Buku ajar ini
diperuntukkan bagi mahasiswa jurusan Teknik Elektro program studi Manajemen
Informatika tingkat satu pada semester satu.
Dengan mempelajari buku ini, diharapkan pembaca dapat memperoleh
pengetahuan mengenai dasar-dasar basis data, mulai dari konsep sampai
pembuatan basis data dalam hal perancangan model dan basis data yang baik.
Tiada gading yang tak retak, begitu juga dengan buku ajar ini yang masih
banyak kekurangannya. Untuk itu penulis sangat mengharapkan kritik dan saran
yang membangun, sehingga bisa dilakukan perbaikan. Akhir wakalam penulis
menyampaikan terima kasih atas bantuan dari berbagai pikah, hanya Allah SWT
yang mampu membalasnya. Dan bagi yang mempelajari buku ini, selamat
belajar.

Penulis

Dwi Puspitasari, S.Kom, Program Studi Manajemen Informatika ii

Garis-Garis Besar P Perkuliahan

GARIS-GARIS BESAR PROGRAM PENGAJARAN (GBPP)

Mata Kuliah : Dasar Basis Data
Kode Mata Kuliah : RIF 100
Semester/SKS : 1 / 1 SKS
Beban Studi : 3 jam / minggu
Diskripsi Singkat : Materi kuliah ini meliputi konsep dasar basis data beserta kompponen-komponennya
serta pemodelan basis data menggunakan ER diagram dan model relasional
Kompetensi Mata : Mahasiswa memahami konsep dan kegunaan dari basis data, serta mampu merancang
Kuliah suatu basis data yang baik berdasarkan ukuran-ukuran informal pada basis data
relasional
Referensi : 1. Elmasri & Navathe, “Fundamentals of Database Systems”, Addison-Wesley, 2004
2. C. J. Date, “Pengenalan Sistem Basis Data jilid 1”, PT. Indeks Group Gramedia, 2004

Standar Kompetensi
No Pokok Bahasan Kompetensi Dasar (TIK) Sub Pokok Bahasan Waktu Referensi
(TIU)
(1) (2) (3) (4) (5) (7) (8)
1. Mengerti basis data dan Pengantar basis data a. Mengetahui apa itu basis data Definisi basis data, 3 X 45” 1,2
kegunaannya b. Mengetahui karakteristik, Karakteristik,manfaat, dan
manfaat, dan penerapan dari penerapan basis data,
basis data orang-orang yang berperan;
c. Mengetahui orang-orang yang
berperan dalam basis data
2. Mengerti konsep dan Konsep dan arsitektur a. Mengetahui konsep model Konsep model data, schema 3 X 45” 1
arsitektur dari basis data basis data data, schema dan kebebasan dan kebebasan data,model
data; basis data,bahasa basis data,
b. Mengetahui model basis dan lingkungan sistem basis
data; data

Dwi Puspitasari, S.Kom, Program Studi Manajemen Informatika iii


c. Mengetahui bahasa dan
lingkungan sistem basis data;
3. Mampu membuat model Pemodelan data a. Mengetahui model data Model data konseptual,dan 3 X 45” 1
data menggunakan ER menggunakan ER konseptual pemodelan menggunakan
diagram diagram b. Bisa membuat pemodelan ER-Diagram
data menggunakan ER-
Diagram
4. Mampu membuat ER Latihan Soal Mampu membuat ER model 3 X 45”
model berdasarkan berdasarkan spesifikasi
spesifikasi sistem sistem yang berbeda-beda
5. Mampu membuat model Model data relasional a. Mengetahui konsep model Konsep model data 3 X 45” 1,2
data relasional data relasional; relasional,constraint untuk
b. Mengetahui constraint model data
untuk model data relasional; relasional,operasi-operasi
c. Mengetahui operasi- update, mendefinisikan relasi,
operasi update; dan pemetakan ER-Diagram
d. Mampu mendefinisikan ke model relasional
relasi;
e. Mampu memetakan ER-
Diagram ke model relasional
6. Mampu memetakkan ER Latihan Soal Mampu memetakkan ER model 3 X 45”
model ke bentuk model ke bentuk model relasional
relasional
7. Mengetahui SQL sebagai Pengantar SQL a. Mengetahui bahasa SQL; Pengertian SQL, elemen 3 X 45” 2
bahasa basis data b. Mengetahui elemen dan SQL,dan kelompok
kelompok persyaratan SQL persyaratan SQL
9. Mampu menggunakan Data Definition a. Mengetahui definisi DDL Definisi DDL dan skema,tipe- 3 X 45” 1,2
bahasa pendefinisian Language dan skema tipe domain, dan perintah-
data b. Mengetahui tipe-tipe perintah DDL.
domain
c. Mengetahui perintah-
perintah DDL.
10. Mampu membuat query Data Manipulation a. Mengetahui definisi dari Definisi DML,query 3 X 45” 1,2
yang bermacam-macam Language DML data,operasi himpunan,
dengan menggunakan b. Mampu membuat query fungsi Agregasi, dan sub
bahasa DML data sederhana query
c. Mampu membuat query

Dwi Puspitasari, S.Kom, Program Studi Manajemen Informatika iv


data dengan operasi
himpunan dan fungsi
agregasi
d. Mampu membuat sub
query
11. Mampu memanipulasi Data Manipulastion a. Mampu memodifikasi basis Modifikasi penghapusan, 3 X 45” 1,2
data menggunakan Language data penyisipan, dan perubahan
bahasa DML b. Mampu basis data,
menghapus,menyisipkan, dan
merubah data pada basis
data
12. Mampu mengukur suatu Pengukuran Skema a. Mengetahui pengertian dan Pengertian dan kegunaan 3 X 45” 1
skema relasional Relasional kegunaan pengukuran skema pengukuran skema
menggunakan petunjuk- relasional; relasional, dan petunjuk-
petunjuk informal b. Mengetahui petunjuk- petunjuk informal dalam
petunjuk informal dalam desain basis data relasional
desain basis data relasional
13. Mengetahui Ketergantungan a. Mengetahui definisi Definisi ketergantungan 3 X 45” 1
ketergantungan Fungsional ketergantungan fungsional fungsional, aturan penurunan,
fungsional dalam skema b. Mengetahui aturan dan algoritma mencari X+
relasional penurunan
c. Mengetahui algoritma
mencari X+
14. Mampu menormaslisasi Normalisasi a. Mengetahui pengertian Pengertian normalisasi dan 3 X 45” 1
skema relasional ke normalisasi dan bentuk- bentuk-bentuk normal, bentuk
dalam bentuk yang bentuk normal; 1NF, 2NF, 3NF,
diinginkan b. Mampu membuat bentuk BCNF,multivalued
1NF, 2NF, 3NF, BCNF, 4NF dependencies dan 4NF, dan
dan 5NF dependensi gabungan dan
c. Mengetahui multivalued 5NF
dependencies
d. Mengetahui dependensi
gabungan

Dwi Puspitasari, S.Kom, Program Studi Manajemen Informatika v

Satuan Ajar Perkuliahan (SAP)

SATUAN AJAR PERKULIAHAN (SAP)

Mata Kuliah : Dasar Basis Data
Kode Mata Kuliah : RIF 100
Semester/SKS : 1 / 1 SKS
Beban Studi : 3 jam / minggu
Dosen : Dwi Puspitasari,S.Kom
TIU : Mahasiswa memahami konsep dan kegunaan dari basis data, serta mampu merancang
suatu basis data yang baik berdasarkan ukuran-ukuran informal pada basis data
relasional
Referensi : 1. Elmasri & Navathe, “Fundamentals of Database Systems”, Addison-Wesley, 2004
2. C. J. Date, “Pengenalan Sistem Basis Data jilid 1”, PT. Indeks Group Gramedia, 2004

Minggu TIK Topik Sub Topik Metode Alat Bantu Referensi
(1) (2) (3) (4) (5) (6) (7)
1. Mengetahui definisi basis Pengantar basis a. Definisi basis data Ceramah Komputer, 1,2
data, karakteristik,manfaat, data b. Karakteristik, manfaat, dan LCD
dan penerapan basis data, penerapan dari basis data
orang-orang yang berperan; c. Orang-orang yang berperan
dalam basis data
2. Mengetahui konsep model Konsep dan a. Konsep model data, Ceramah Komputer, 1
data, schema dan kebebasan arsitektur basis schema dan kebebasan data LCD
data,model basis data b. Model basis data;
data,bahasa basis data, dan c. Bahasa dan lingkungan
lingkungan sistem basis data sistem basis data;
3. Mengetahui model data Pemodelan data a. Model data konseptual Ceramah Komputer, 1
konseptual,dan pemodelan menggunakan b. Pemodelan data LCD
menggunakan ER-Diagram ER diagram menggunakan ER-Diagram

Dwi Puspitasari, S.Kom, Program Studi Manajemen Informatika vi


4. Mampu membuat ER model Latihan Soal Ceramah Komputer,
berdasarkan spesifikasi LCD
sistem yang berbeda-beda
5. Quiz 1
6. Mengetahui konsep model Model data a. Konsep model data Ceramah Komputer, 1,2
data relasional,constraint relasional relasional; LCD
untuk model data b. Constraint untuk model
relasional,operasi-operasi data relasional;
update, mendefinisikan relasi, c. Operasi-operasi update;
dan pemetakan ER-Diagram d. Mendefinisikan relasi;
ke model relasional e. Memetakan ER-Diagram
ke model relasional
7. Mampu memetakkan ER model Latihan Soal
ke bentuk model relasional
8. Mengetahui pengertian SQL, Pengantar SQL a. Bahasa SQL; Ceramah Komputer, 2
elemen SQL,dan kelompok b. Elemen dan kelompok LCD
persyaratan SQL persyaratan SQL
9. UTS
10. Mengetahui definisi DDL dan Data Definition a. Definisi DDL dan skema Ceramah Komputer, 1,2
skema,tipe-tipe domain, dan Language b. Tipe-tipe domain LCD
perintah-perintah DDL. c. Perintah-perintah DDL.
11. Mengetahui definisi Data a. Definisi dari DML Ceramah Komputer, 1,2
DML,query data,operasi Manipulation b. Membuat query data LCD
himpunan, fungsi Agregasi, Language sederhana
dan sub query c. Query data dengan operasi
himpunan dan fungsi
agregasi
d. Membuat sub query
12. Mampu memodifikasi, Data a. Memodifikasi basis data Ceramah Komputer, 1,2
menghapus, menyisipkan, Manipulastion b. Menghapus, menyisipkan, LCD
dan merubah basis data, Language dan merubah data pada
basis data
13. Latihan Soal
14. Quiz 2
15. Mengetahui pengertian dan Pengukuran a. Pengertian dan kegunaan Ceramah Komputer, 1
kegunaan pengukuran skema Skema pengukuran skema LCD
relasional, dan petunjuk- Relasional relasional;

Dwi Puspitasari, S.Kom, Program Studi Manajemen Informatika vii


petunjuk informal dalam b. Petunjuk-petunjuk informal
desain basis data relasional dalam desain basis data
relasional
16. Mengetahui definisi Ketergantungan a. Definisi ketergantungan Ceramah Komputer, 1
ketergantungan fungsional, Fungsional fungsional LCD
aturan penurunan, dan b. Aturan penurunan
algoritma mencari X+ c. Algoritma mencari X+
17. Mengetahui pengertian Normalisasi a. Pengertian normalisasi dan Ceramah Komputer, 1
normalisasi dan bentuk- bentuk-bentuk normal; LCD
bentuk normal, bentuk 1NF, b. Membuat bentuk 1NF,
2NF, 3NF, BCNF,multivalued 2NF, 3NF, BCNF, 4NF dan
dependencies dan 4NF, dan 5NF
dependensi gabungan dan c. Multivalued dependencies
5NF d. Dependensi gabungan
18. Latihan Soal
19. UAS

Dwi Puspitasari, S.Kom, Program Studi Manajemen Informatika viii

Daftar Isi

DAFTAR ISI

Halaman Judul ................................................................................... i
Kata Pengantar ..................................................................................ii
Garis-Garis Besar Program Pengajaran (GBPP)............................... iii
Satuan Ajar Perkuliahan (SAP) .........................................................vi
Daftar Isi............................................................................................ix
Daftar Gambar ..................................................................................xi
Daftar Tabel ..................................................................................... xii
1. Pendahuluan............................................................................... 1
1.1 Definisi Dasar Basis Data .......................................................................1
1.2 Karakteristik Basis Data..........................................................................3
1.3 Orang-orang yang Berperan pada Basis Data........................................3
1.4 Manfaat Penggunaan Basis Data ...........................................................4
1.5 Penerapan Basis Data ............................................................................7
2. Konsep Dan Arsitektur Basis Data .............................................. 9
2.1 Model Data, Schema dan Kebebasan Data............................................9
2.2 Model Basis Data..................................................................................11
2.3 Bahasa dari Basis Data ........................................................................15
2.4 Lingkungan Sistem Basis Data .............................................................16
3. Pemodelan Data Dengan Menggunakan ER-Model.................. 17
3.1 Model Data Konseptual Untuk Desain Basis Data..............................17
3.2 Notasi-Notasi Dalam ER Diagram ......................................................18
4. Model Data Relasional .............................................................. 22
4.1 Konsep-Konsep Model Relasional........................................................22
4.2 Constraints Untuk Model Data Relasional ............................................25
4.3 Operasi-Operasi UPDATE Pada Relasi................................................26
4.4 Mendefinisikan Relasi...........................................................................29
4.5 Algoritma Pemetakan Skema ER Ke Skema Relasional ......................30

Dwi Puspitasari, S.Kom, Program Studi Manajemen Informatika

Daftar Isi

5. Structured Query Language (SQL)............................................ 34
5.1 Elemen SQL .........................................................................................34
5.2 Kelompok persyaratan SQL..................................................................37
5.3 Struktur Dasar.......................................................................................39
5.4 Operasi Himpunan................................................................................42
5.5 Fungsi-Fungsi Agregasi ........................................................................43
5.6 Subqueri Tersarang (Nested Subqueries) ............................................44
5.7 Modifikasi Basis Data ...........................................................................45
5.8 Bahasa Definisi Data (Data DefinitionLanguage)..................................47
6. Pengukuran Skema Relasional ................................................. 50
6.1 Petunjuk - Petunjuk Informal Dalam Desain Skema Relasional............50
6.2 Semantik Dari Atribut............................................................................50
6.3 Informasi yang Redundan dan Update Anomalies................................51
6.4 Nilai-Nilai Null dalam Tuples .................................................................53
6.5 Tuples yang Tidak Dikehendaki (Spurious Tuples)...............................54
7. Ketergantungan Fungsional ...................................................... 55
7.1 Definisi Ketergantungan Fungsional .....................................................55
7.2 Aturan Penurunan (Inference Rules) Untuk FD ....................................56
7.3 Algoritma Mencari X+ ............................................................................57
7.4 Set Ketergantungan Fungsional Yang Ekivalen....................................58
7.5 Set Ketergantungan Fungsional Yang Minimal.....................................59
8. Normalisasi ............................................................................... 60
8.1 Bentuk Normal ......................................................................................60
8.2 First Normal Form ( 1NF ).....................................................................61
8.3 Second Normal Form ( 2NF )................................................................61
8.4 Third Normal Form ( 3NF )....................................................................63
8.5 Boyce/Codd Normal Form (BCNF) .......................................................65
8.6 Multivalued Dependencies Dan Fourth Normal Form ( 4NF ) ...............66
8.7 Dependensi Gabungan Dan Fifth Normal Form (5NF) .........................68
Daftar Pustaka ................................................................................ xiii


Daftar Gambar

DAFTAR GAMBAR

Gambar 1.1 Lingkungan sistem basis data...........................................................2
Gambar 1.2 Gambaran basis data dan lemari arsip .............................................5
Gambar 2.1 Arsitektur three-level model data ....................................................10
Gambar 2.2 Model basis data hirarki ..................................................................12
Gambar 2.3 Model basis data jaring ...................................................................13
Gambar 2.4 Model basis data relasional.............................................................14
Gambar 3.1 Fase-fase desain basis data sederhana .........................................17
Gambar 3.2 Skema ER Untuk Basis Data COMPANY .......................................20
Gambar 4.1 Pendefinisian relasi pada basis data COMPANY............................30


Daftar Tabel

DAFTAR TABEL
Tabel 3.1 Notasi untuk ER-Diagram ...................................................................18
Tabel 4.1 Korespondensi model ER dengan model relasional ...........................33
Tabel 5.1 Pernyataan dalam SQL.......................................................................34
Tabel 5.2 Tipe data standart dalam SQL ............................................................35
Tabel 5.3 Tipe data perluasan dalam SQL .........................................................36
Tabel 5.4 Simbol pada ekspresi aritmatika .........................................................37


1. Pendahuluan

1. PENDAHULUAN

Dalam suatu organisasi, data merupakan sumber informasi yang sangat
berguna. Oleh karena itu data memegang peranan penting dan menjadi asset
yang berharga bagi organisasi. Lalu, bagaimana jika data tidak dikelola dengan
baik ? Jika data tidak dikelola dengan baik maka akan mengakibatkan data rusak
atau hilang sehingga memperlambat proses kerja.
Pertanyaan selanjutnya, bagaimana mengelola data dengan baik ?
Caranya, data di tata dengan rapi, dibuat arsip catatan, dikelompokkan dan
disimpan di suatu tempat basis data (database) sehingga memudahkan dalam
pencarian. Sesuai perkembangan iptek dan teknologi, maka pada saat sekarang
ini basis data lebih banyak menggunakan sistem komputerisasi.
Pada buku ini akan dipelajari tentang konsep basis data, pemodelan data,
perancangan serta pembuatan basis data.

1.1 Definisi Dasar Basis Data

Basis Data terdiri atas 2 kata, yaitu Basis dan Data. Basis dapat diartikan
sebagai markas atau gudang, tempat bersarang/berkumpul. Sedangkan Data
adalah representasi fakta dunia nyata yang mewakili suatu objek seperti manusia
(pegawai, siswa, pembeli, pelanggan), barang, hewan, peristiwa, konsep,
keadaan, dan sebagainya, yang direkam dalam bentuk angka, huruf, simbol,
teks, gambar, bunyi, atau kombinasinya.
Basis Data sendiri dapat didefinisikan dalam sejumlah sudut pandang,
seperti :
1. Himpunan kelompok data (arsip) yang saling berhubungan yang diorganisasi
sedemikian rupa agar kelak dapat dimanfaatkan kembali dengan cepat dan
mudah.
2. Kumpulan data yang saling berhubungan yang disimpan secara bersama
sedemikian rupa dan tanpa pengulangan (redundansi) yang tidak perlu, untuk
memenuhi berbagai kebutuhan.

Dwi Puspitasari, S.Kom, Program Studi Manajemen Informatika 1

1. Pendahuluan

3. Kumpulan file/tabel/arsip yang saling berhubungan yang disimpan dalam
media penyimpanan elektronis.
Perangkat lunak (Software) yang memungkinkan pengguna basis data
untuk membuat dan memelihara suatu basis data disebut dengan Database
Management System (DBMS). DBMS menyediakan tiga fasilitas utama, yaitu :
1. Mendefinisi basis data, yaitu menspesifikasi basis data seperti menentukan
tipe data, struktur, serta constraint dari data.
2. Membangun basis data, yaitu berkaitan dengan proses penyimpanan data itu
sendiri di dalam DBMS
3. Memanipulasi basis data, yaitu berkaitan dengan proses menambah,
menghapus, merubah dan menampilkan data yang tersimpan di dalam basis
data.
Sedangkan perangkat lunak (software) yang digunakan untuk
memanipulasi data dan basis data itu sendiri disebut sebagai Sistem Basis
Data. Berarti sistem basis data = DBMS + basis data yang disimpan di
dalamnya.
User / Programmer

Database System
Application
programs / queries

DBMS
Software Software to process
Queries / programs

Software to access
stored data

Stored database Stored database
definition (metadata)

Gambar 1.1 Lingkungan sistem basis data


1. Pendahuluan

1.2 Karakteristik Basis Data

Basis data memiliki beberapa karakteristik sebagaimana berikut.
1. ‘Self-describing’
Basis data tidak hanya berisi data saja, tetapi lengkap dengan definisi dari
data itu sendiri. Definisi data disimpan dalam catalok sistem (meta-data) yang
berisi struktur setiap file, tipe dan fomat penyimpanan data, serta constraint dari
data. Software DBMS dapat mengekstraksi data dari catalog dan
menggunakannya.
2. ‘Isolation’
Program pengaksesan DBMS ditulis secara terpisah dengan file-file yang
bersifat spesifik seperti abstraksi data. Sehingga program dan data berdiri
sendiri.
3. ‘Multi-view’
Memungkinkan user yang berbeda untuk mendapatkan perspektif (view)
basis data yang berbeda.
4. Sharing data dan pemrosesan transaksi multi-user
Memungkinkan sejumlah user mengakses data secara bersamaan. Untuk
itu DBMS perlu menyediakan ‘concurrency control software’ sehingga data yang
diakses valid.

1.3 Orang-orang yang Berperan pada Basis Data

Ada empat kelompok orang yang berperan secara langsung pada basis
data, yatu :
1. Database Administrator (DBA)
Yaitu orang yang bertanggung jawab terhadap administrasi penggunaan
sumber daya basis data (DBMS dan basis data). DBA bertugas :
- Mengatur otorisasi akses terhadap basis data
- Memonitor penggunaan basis data
- Melayani permintaan software dan hardware
2. Database Designer


1. Pendahuluan

Yaitu orang yang bertanggung jawab dalam peracangan basis data (dalam
memenuhi permintaan user). Database designer bertugas :
- Mengidentifikasi data yang akan disimpan dalam basis data.
- Memilih struktur yang sesuai dalam menyajikan dan menyimpan data.
3. End User
Orang-orang yang pekerjaannya memerlukan akses terhadap basis data
untuk keperluan membaca dan merubah data, serta membaca laporan dari
data.
4. System Analysts
Yaitu orang-orang yang bertugas mendefinisikan kebutuhan-kebutuhan end
user dan mengembangkan spesifikasi untuk transaksi-transaksi yang
memenuhi keinginannya
5. Application Programmers
Yaitu orang-orang yang bertugas mengimplementasikan spesifikasi yang
dibuat oleh system analyst menjadi program.

Sedangkan orang yang berperan dibelakang layer (tidak langsung) pada
basis data ada tiga kelompok, yaitu :
1. DBMS Designers dan Implementers
Orang-orang yang merancang dan mengimplementasikan modul-modul
DBMS dan interfacenya sebagai satu paket perangkat lunak.
2. Tool Developers
Yaitu orang-orang yang mengembangkan paket-paket software yang
memberikan fasilitas dalam perancangan dan penggunaan system basis data
(missal : paket-paket untuk performance monitoring, Graphical User Interface,
prototyping, simulation, dan sebagainya)
3. Operator dan Maintenance Personnel
Yaitu orang-orang yang bertugas mengoperasikan dan merawat basis data

1.4 Manfaat Penggunaan Basis Data


1. Pendahuluan

Basis Data dan lemari arsip sesungguhnya memiliki prinsip kerja dan
tujuan yang sama. Prinsip utamanya adalah pengaturan data/arsip. Dan tujuan
utamanya adalah kemudahan dan kecepatan dalam pengambilan kembali
data/arsip. Perbedaannya hanya terletak pada media penyimpanan yang
digunakan. Jika lemari arsip menggunakan lemari dari besi atau kayu sebagai
media penyimpanan, maka basis data menggunakan media penyimpanan
elektronis seperti disk (disket atau harddisk).

Gambar 1.2 Gambaran basis data dan lemari arsip

Adapun manfaat yang diperoleh dari penggunaan basis data adalah :
1. Kecepatan dan Kemudahan (Speed)
Pemanfaatan basis data memungkinkan kita untuk dapat menyimpan data
atau melakukan perubahan/manipulasi terhadap data atau menampilkan kembali
data tersebut dengan lebih cepat dan mudah.
2. Efisiensi Ruang Penyimpanan (Space)
Dengan basis data, efisiensi/optimalisasi penggunaan ruang penyimpanan
dapat dilakukan, karena kita dapat melakukan penekanan jumlah redundansi
data, baik dengan menerapkan sejumlah pengkodean atau dengan membuat
relasi-relasi (dalam bentuk file) antar kelompok data yang saling berhubungan.


1. Pendahuluan

3. Keakuratan (Accuracy)
Pemanfaatan pengkodean atau pembentukan relasi antar data bersama
dengan penerapan aturan/batasan (constraint) tipe data, domain data, keunikan
data, dan sebagainya, yang secara ketat dapat diterapkan dalam sebuah basis
data, sangat berguna untuk menekan ketidakakuratan pemasukan/penyimpanan
data.
4. Ketersediaan (Availability)
Dengan basis data, data yang sudah jarang atau bahkan tidak pernah lagi
kita gunakan, dapat kita atur untuk dilepaskan dari sistem basis data yang
sedang aktif (menjadi off-line) baik dengan cara penghapusan atau dengan
memindahkannya ke media penyimpanan off-line (seperti removable disk atau
tape). Di sisi lain, karena kepentingan pemakaian data, sebuah basis data dapat
memiliki data yang disebar di banyak lokasi geografis. Dengan pemanfaatan
teknologi jaringan komputer, data yang berada di suatu lokasi, dapat juga
diakses (menjadi tersedia / available) bagi lokasi lain.
5. Kelengkapan (Completeness)
Untuk mengakomodasi kebutuhan kelengkapan data yang semakin
berkembang, maka pada basis data kita tidak hanya dapat menambah record-
record data, tetapi juga dapat melakukan perubahan struktur dalam basis data,
baik dalam bentuk penambahan objek baru (tabel) atau dengan penambahan
field-field baru pada suatu tabel.
6. Keamanan (Security)
Dalam sistem yang besar dan serius, aspek keamanan data dapat
diterapkan dengan ketat dengan cara menentukan siapa-siapa (pemakai) yang
boleh menggunakan basis data beserta objek-objek di dalamnya dan
menentukan jenis-jenis operasi apa saja yang boleh dilakukannya.
7. Kebersamaan Pemakaian (Sharability)
Pemakai basis data seringkali tidak terbatas pada satu pemakai saja,
atau di satu lokasi saja atau oleh satu sistem/aplikasi saja. Data pegawai dalam
basis data kepegawaian, misalnya, dapat digunakan oleh banyak pemakai, dari


1. Pendahuluan

sejumlah departemen dalam perusahaan atau oleh banyak sistem (sistem
penggajian, sistem akuntansi, sistem inventors, dan sebagainya).

1.5 Penerapan Basis Data

Secara lebih teknis/nyata, bidang-bidang fungsional yang telah umum
memanfaatkan basis data demi efisiensi, akurasi dan kecepatan operasi antara
lain adalah:
1. Kepegawaian, untuk berbagai perusahaan yang memiliki banyak pegawai.
2. Pergudangan (inventory), untuk perusahaan manufaktur (pabrikan), grosir
(reseller), apotik, dan lain-lain.
3. Akuntansi, untuk berbagai perusahaan.
4. Reservasi,untuk hotel, pesawat, kereta api, dan lain-lain.
5. Layanan Pelanggan (customer care),untuk perusahaan yang berhubungan
dengan banyak pelanggan (bank, konsultan, dan lain-lain).
6. dan lain-lain.
Sedang bentuk-bentuk organisasi/perusahaan yang memanfaatkan basis
data (sebagai komponen sistem informasi dalam organisasi/perusahaan) dapat
berupa:
1. Perbankan, dalam melakukan pengelolaan data nasabah/data tabungan/data
pinjaman, pembuatan laporan-laporan akuntansi, pelayanan informasi pada
nasabah/calon nasabah, dan lain-lain.
2. Asuransi, dalam melakukan pengelolaan data nasabah/data pembayaran
premi, pemrosesan pengajuan klaim asuransi, dan lain-lain.
3. Rumah Sakit, dalam melakukan pengelolaan histori penyakit/pengobatan
pasien, menangani pembayaran perawatan, dan lain-lain.
4. Produsen Barang, dalam melakukan pengelolaan data keluar-masuk barang
(inventors), dan lain-lain.
5. Industri Manufaktur, dalam membantu pengelolaan pesanan barang,
mengelola data karyawan, dan lain-lain.
6. Pendidikan/Sekolah, dalam melakukan pengelolaan data siswa, penjadualan
kegiatan perkuliahan, dan lain-lain.


1. Pendahuluan

7. Telekomunikasi, dalam melakukan pengelolaan data administrasi kabel/data
pelanggan, menangani gangguan, dan lain-lain.
8. dan lain-lain.


2. Konsep dan Arsitektur Basis Data

2. KONSEP DAN ARSITEKTUR BASIS DATA
Untuk membuat basis data, kita perlu mempelajari tentang konsep basis
data meliputi model-model data, schema, dan instance

2.1 Model Data, Schema dan Kebebasan Data

Dalam pembuatan basis data, agar basis data yang dibuat bisa sesuai
dengan yang diinginkan maka diperlukan proses perancangan terlebih dahulu.
Dimana dalam proses ini dilakukan pendeskripsian data dalam bentuk schema
serta pembuatan model datanya. Untuk itu kita perlu mengetahui konsep dari
schema dan model data dalam basis data.
Schema merupakan diskripsi dari basis data berupa abstraksi data yang
terdiri dari nama dan tipe dari record, item-item data, serta constraint dari basis
data.
Sedangkan model data merupakan alat utama yang digunakan untuk
menyediakan abstraksi data. Sehingga model data merupakan penggambaran
dari schema basis data.
Ada tiga kategori dalam model data, yaitu :
1. Model data tingkat tinggi
Model data ini menggunakan konsep seperti entity, attribute, dan relationship.
2. Model data representasional atau implementasi
Termasuk dalam jenis ini adalah model data relasional, jaringan, dan hirarki.
Dimana data disajikan dengan menggunakan struktur record (record-based
data model)
3. Model data fisik
Model data ini menggambarkan bagaimana data disimpan dalam komputer
yaitu dalam format-format record, urutan-urutan record, dan access path.
Model data nantinya akan menggambarkan setiap level dari basis data
yang tampak seperti pada gambar berikut ini.



End User

Eksternal View ... Eksternal View Eternal Level

External / con-
ceptual mapping
Conceptual
Schema Conceptual level

Conceptual / in-
ternal mapping

Internal Internal level
Schema

Stored Database

Gambar 2.1 Arsitektur three-level model data

- Internal level (internal schema)
Menjelaskan struktur penyimpanan fisik dari basis data menggunakan
model data fisik.
- Conceptual level (conceptual schema)
Menjelaskan struktur penyimpanan dari keseluruhan basis data untuk
dipakai oleh satu komunitas user menggunakan model data tingkat tinggi
atau model data implementasi.
- External atau view level (external schema atau user view)
Menjelaskan sebagian basis data yang menjadi perhatian dari
sekelompok user tertentu menggunakan model data tingkat tinggi atau
model impelementasi.

Arsitektur three-schema dapat digunakan untuk menjelaskan konsep
‘kebebasan data’ (data independence) yang dapat didefinisikan sebagai



kemampuan untuk merubah skema pada suatu level dari system basis data
tanpa harus menyebabkan perubahan dari skema pada tingkat yang lebih tinggi
Terdapat dua jenis kebebasan data, yaitu :
- Logical data independence
Yaitu kemampuan untuk merubah skema konseptual termasuk juga
constraint dari basis data tanpa harus merubah skema eksternal. Hanya
definisi dari view dan mapping yang perlu dirubah dalam DBMS
- Physical data independence
Yaitu kemampuan untuk merubah skema internal tanpa harus merubah
skema konseptual (eksternal) yang mungkin diperlukan karena file-file fisik
yang harus diorganisasikan kembali (misalnya membuat struktur akses
tambahan untuk meningkatkan kinerja membacaan atau perubahan data).

2.2 Model Basis Data

Model basis data menyatakan hubungan antar data yang tersimpan
dalam basis data struktur data logis. Pada saat ini terdapat tiga model data yang
sering digunakan, yaitu :
Hirarkis;
Jaringan, dan
Relasional
Model yang baru setelah relasional, beberapa nama yang sedang
dikembangkan antara lain (sebagian ada di dalam konsep MPEG7):
DBMS deduktif;
DBMS pakar;
DBMS semantik;
DBMS berorientasi objek;
DBMS relasional universal
Beberapa produk sistem berorientasi objek telah beredar dipasaran,
antara lain: OpenODB (Hewlett Packard) dan Object Source (Object Design
Corp.).



1. Model Hirarkis
Biasa disebut dengan model pohon (tree model) menggunakan pola
hubungan orangtua-anak (parent-child). Setiap simpul menyatakan sekumpulan
medan (field) ).
Suatu simpul (node) yang terhubung ke simpul level di bawahnya adalah
orangtua (parent);
Simpul yang dibawahi orangtua adalah anak (child );
Simpul yang tak memiliki anak adalah daun (leaf );
Hubungan orangtua dan anak adalah cabang (branch ).
Contoh produk DBMS yang menggunakan model hirarkis adalah IMS
(Information management System), yang dikembangkan oleh dua perusahaan
IBM dan Rockwell International Corporation.

Gambar 2.2 Model basis data hirarki

2. Model Jaringan
Distandarisasi tahun 1971 dengan sebutan model Data Base Task Group
(DBTG) atau Conference on Data System Language (CODASYL) dimana DBTG
bagian dari CODASYL.
Satu simpul anak bisa memiliki lebih dari satu simpul orangtua, orangtua
adalah pemilik (owner) dan anak adalah anggota.



Contoh : produk CA- IDBMS/DB dari Computer Associates International
Inc yang sebelumnya IDBMS (Integrated DataBase Management System).

Gambar 2.3 Model basis data jaring

3. Model Relasional
Merupakan model yang paling sederhana sehingga mudah digunakan dan
dipahami, serta paling populer saat ini dimana sekumpulan tabel berdimensi dua
(relasi atau tabel). Relasi dirancang untuk menghilangkan kemubaziran data.
DBMS yang bermodelkan relasional disebut RDBMS (Relational DBMS)
Meskipun relasi dikatakan sama dengan tabel, relasi pada sejumlah
literatur sering disebut saat membicarakan struktur logis dan table adalah nama
yang sering disebut pada basis data fisis. Selanjutnya istilah ‘tabel’ kadang
digunakan untuk menggantikan relasi atau sebaliknya.



Gambar 2.4 Model basis data relasional

Ada beberapa sifat yang melekat pada suatu relasi:
1. Tak ada tupel (baris) yang kembar yaitu menjadi primary key
2. Urutan tupel tidaklah penting (tupel - tupel dapat dipandang dalam sebarang
urutan);
2. Setiap atribut memiliki nama yang unik;
3. Letak atribut bebas (urutan atribut tidak penting);
4. Setiap atribut memiliki nilai tunggal dan jenisnya sama untuk semua tupel.
Contoh produk DBMS yang menggunakan model relasional:
1. DB2 dari IBM;
2. RDB/VMS dari Digital Equipment Corp.;
3. Oracle dari Oracle Corp.;
4. Informix dari Informix Corp.;
5. Sybase;
5. Keluarga dBase;



6. Microsoft Access
7. Microsoft SQL
8. Microsoft Visual Foxpro;

2.3 Bahasa dari Basis Data

Basis data memiliki bahasa yang digunakan untuk membuat spesifikasi
skema konseptual dan internal, serta mapping antara keduanya. Dalam setiap
DBMS minimal terdapat empat jenis bahasa yaitu :
1. DDL (Data Definition Language,)
Yaitu bahasa yang digunakan untuk menspesifikasikan kedua skema
konseptual dan internal, jika dalam DBMS tidak ada pemisahan yang ketat
antara kedua level tersebut. Jika DBMS memiliki pemisahan yang jelas, maka
DDL hanya digunakan untuk menspesifikasikan skema konseptual.
2. VDL (View Definition Language)
Yaitu bahasa yang digunakan untuk menspesifikasikan user view dan
mapping menjadi skema konseptual pada DBMS yang memiliki pemisah yang
jelas antara skema konseptual dan internal.
3. DML (Data Manipulation Language)
Yaitu bahasa yang digunakan untuk melakukan manipulasi data (setelah
dilakukan proses kompilasi skema konseptual).
4. SQL (Structured Query Language)
Yaitu bahasa yang digunakan untuk manipulasi basis data relasional yang
mengintegrasikan DDL, DML, dan VDL.
Pada DML terdapat dua jenis bahasa, yaitu :
1. High-Level (Non_procedural) DML.
- di gunakan secara interaktif (interpreter)
- dapat dijadikan satu dengan general purpose programming language
(embedded)
High-Level DML yang biasa digunakan secara interaktif disebut “ Query
Language “.
2. Low-Level (Proedural) DML.



Digunakan secara embedded dalam suatu general purpose programming
language
Bilamana kedua jenis DML diatas digunakan secara “embedded”, maka :
bahasa pemrograman yang digunakan disebut sebagai “Host Language”
DML-nya disebut “Sub Language”

2.4 Lingkungan Sistem Basis Data

Suatu Database Management System (DBMS) harus memiliki komponen-
komponen sebagai berikut :
File Manager, yang mengelola alokasi ruang, dalam disk dan struktur data
yang dipakai untuk merepresentasikan informasi yang tersimpan dalam disk.
Sebenarnya Sistem Operasi (tempat di mana DBMS diaktifkan) juga memiliki
modul File Manager. Tetapi File Manager di DBMS lebih difokuskan pada
efisiensi dan efektivitas penyimpanan.
Database Manager, yang menyediakan interface antara data low-level yang
ada di basis data dengan program aplikasi dan query yang diberikan ke
sistem.
Query Processor, yang menerjemahkan perintah-perintah dalan query
language ke perintah low-level yang dapat dimengerti oleh database
manager. Di samping itu, Query Processor mentransformasikan permintaan
user ke bentuk yang lebih efisien sehingga query menjadi lebih efektif.
DML Precompiler, yang mengkonversi perintah DML yakni ditambahkan
dalam sebuah program aplikasi ke pemanggilan prosedur normal dalam
bahasa induk. Precompiler ini akan berinteraksi dengan query processor
DDL Compiler, yang mengkonversi perintah-perintah DDL ke dalan
sekumpulan label yang mengandung metadata. Tabel-tabel in kemudian
disimpan dalam kamus data.


3. Pemodelan Data dengan Menggunakan ER-Model

3. PEMODELAN DATA DENGAN MENGGUNAKAN ER-
MODEL
ER (Entity-Relationship) Model merupakan model data tingkat tinggi yang
popular untuk model data relasional. Model ini dengan sejumlah variasinya
sering digunakan dalam desain konseptual dari aplikasi basis data.

3.1 Model Data Konseptual Untuk Desain Basis Data

Fase-fase dalam desain basis data yang disederhanakan tampak
sebagaimana gambar berikut :

Mini-World

REQUIREMENTS
COLLECTION AND ANALYSIS
Functional Requirement

Database Requirements
FUNCTIONAL ANALYSIS
CONCEPTUAL DESIGN

High-Level Transaction
Specification Conceptual Schema (In High-
Level Data Model)
DBMS-
INDEPENDENT
LOGICAL DESIGN (DATA
MODEL MAPPING)
DBMS-
SPECIFIC
Logical (Conceptual) Schema (in
APPLICATION the data model of) a specific
PROGRAM DESIGN DBMS

TRANSACTION PHYSICAL DESIGN
IMPLEMENTATION

Internal Schema
Application Programs (for the same DBMS)

Gambar 3.1 Fase-fase desain basis data sederhana



3.2 Notasi-Notasi Dalam ER Diagram

Dalam ER model , skema konseptual untuk suatu aplikasi basis data
ditunjukkan dengan menggunakan notasi-notasi grafis yang disebut “ER
Diagram”
Tabel 3.1 Notasi untuk ER-Diagram
Simbol Arti

Entity

Weak Entity

Relationship

Identifying Relationship

Attribute

Key Attribute

Multivalued Attribute

….
Composite Attribute

Derived Attribute

E1 R E2 Total Participation of E2 in R

1 N
E1 R E2 Cardinality Ratio 1 : N For E1 : E2 in R



(min,max) (min,max)
E R E Structural Constraint (min,max) On
Participation Of E in R

Contoh Studi Kasus (Sederhana) :

Untuk keperluan penjelasan konsep dan penggunaan ER model,
digunakan satu contoh basis data “COMPANY” yang di dalamnya mencatat :
- data pegawai (Employee)
- data departemen (Department)
- data proyek (Project)
Penjelasan dari sebagian data COMPANY yang diperoleh setelah fase
“Requirement Collection and Analyst” sebagaimana berikut :
1. COMPANY terdiri dari sejumlah departments. Setiap department
mempunyai satu nama yang unik, nomor yang umik, dan seorang
pegawai (Employee) yang bertindak sebagai manager dari department.
Tanggal mulai bekerja dari manager juga dicatat dalam basis data (
tanggal pengangkatan sebagai manager ). Satu department dapat
tersebar di sejumlah lokasi.
2. Suatu department dapat mengendalikan sejumlah project. Setiap project
mempunyai satu nama yang unik, nomor yang unik, dan satu lokasi
tertentu.
3. Data pegawai yang perlu dicatat berupa : nama, social security number,
address, salary, sex, dan birthdate.
4. Seorang pegawai ditempatkan di satu department, tetapi dapat bekerja di
sejumlah project yang tidak harus dikendalikan oleh department dimana
pegawai tersebut ditempatkan. Jumlah jam perminggunya dari pegawai
yang bekerja pada suatu project perlu dicatat. Juga perlu dicatat
supervisor langsung dari setiap pegawai.
5. Untuk tujuan/keperluan asuransi pegawai, maka perlu dicatat anggota
keluarga dari setiap pegawai. Data yang dicatat berupa : nama anggota
keluarga, sex birthdate dan hubungan keluarga (relationship).



Gambar berikut merupakan skema (ER diagram) dari aplikasi contoh diatas.

Gambar 3.2 Skema ER Untuk Basis Data COMPANY



Soal :

Gambarkan satu ER-Diagram dari satu set “requirements” untuk keperluan basis
data suatu universitas yang digunakan untuk menyimpan transkrip dari
mahasiswa dengan aturan sebagai berikut :
a. Universitas mencatat data setiap mahasiswa yang berupa : nama, nomor
pokok, nomor KTP, alamt tetap, alamat sementara, tgl_lahir, jenis kelmin,
nama jurusan, program pendidikan (diploma tiga, sarjana, pasca sarjana).
Sejumlah user dari aplikasi yang dibuat juga perlu untuk mengacu pada nama
kota, propinsi dank ode pos dari alamat tetap mahasiswa, dan juga nama
orang tua dari setiap mahasiswa. Nomor KTP dan no pokok unik untuk setiap
mahasiswa.
b. Setiap jurusan dijelaskan berdasarkan nama, kode jurusan, kode kantor,
nomor telepon. Kode dan nama jurusan mempunyai nilai-nilai yang unik.
c. Setiap mata kuliah mempunyai kode, nama, jumlah sks, dan jurusan
penyelenggara. Kode mata kuliah unik untuk setiap mata kuliah yang ada.
d. Setiap mata kuliah yang ditawarkan dalam setiap semester didefinisikan
sebagai “section”, yang setiap section mempunyai nomor/kode dosen,
semester, tahun, mata kuliah, dan nomor section. Nomor section
membedakan sejumlah section yang mempunyai nama mata kuliah yang
sama yang ditawarkan pada semester/tahun yang sama (nilainya adalah
1,2,3,… s/d jumlah section yang ditawarkan dalam satu semester.
e. Laporan nilai prestasi belajar (transkrip) berisikan nama mahasiswa, section,
serta nilai angka dan nilai huruf (0,1,2,3 atau 4).


4. Model Data Relasional

4. MODEL DATA RELASIONAL
Model data relasional diperkenalkan oleh “Codd” pada tahun 1970. Model
data ini didasarkan pada suatu struktur data yang sederhana, seragam, dan
sudah mempunyai dasar yang kuat, yaitu “Relasi” .

4.1 Konsep-Konsep Model Relasional

Model relasional menyajikan basis data sebagai satu kumpulan relasi
yang secara informal dapat disamakan dengan sebuah tabel.
Jika suatu relasi dipandang sebagai sebuah tabel dari sejumlah nilai,
maka :
Setiap baris dalam tabel menyajikan sekumpulan nilai-nilai data yang
berhubungan satu dengan yang lain. Nilai-nilai ini dapat diinterpretasikan
sebagai fakta-fakta yang menjelaskan “entity” atau “relationship”.
Nama tabel dan nama-nama kolom yang digunakan untuk membantu kita
dalam melakukan interprestasi arti dari nilai-nilai dalam setiap baris dari tabel.
Dalam terminology model relasional, berlaku aturan-aturan sebagaimana
berikut ini :
Sebuah baris disebut sebuah tuple
Satu header dari kolom disebut attribute
Tabel itu sendiri disebut relasi
Tipe data yang menjelaskan jenis-jenis nilai yang dapat muncul dalam setiap
kolom disebut domain

4.1.1 Domain, Tuple, Attribute dan Relasi

Suatu “domain” D merupakan satu set dari nilai-nilai yang atomic. Atomic
mempunyai pengertian bahwa setiap nilai dalam domain harus utuh. Satu cara



yang umum dalam menjelaskan suatu domain adalah dengan cara menjelaskan
tipe data dimana nilai-nilai data yang ada membentuk domain yang dimaksud.
Contoh :
Domain “Nrm_mahasiswa” : satu set dari 10 digit yang valid untuk
menyatakan Nomor Induk Mahasiswa.

Selain tipe data, suatu domain juga dijelaskan dengan memberikan :
nama dan format data; beserta informasi tambahan untuk memudahkan
menginterpretasikan nilai-nilai domain.
Suatu skema relasi R yang ditulis sebagai R ( A1, A2, …, An ) terbentuk
dari satu nama relasi R dan satu list attribute : A1, A2, … , An. Dimana :
Setiap attribute A2 merupakan nama dari peran yang dimainkan oleh
beberapa domain D dalam skema relasi R.
Domain D dari suatu attribute Ai dinotasikan sebagai dom (A1).
Derajat dari relasi sama dengan jumlah attribute dari skema relasi.

Contoh :

Skema relasi dengan derajat 4 :
MAHASISWA ( Nama, Nim, Tgl_lahir, Alamat )
Dom (Nama) = satu set nama-nama mahasiswa dengan panjang karakter
30
Dom (Nim) = satu set nim mahasiswa berupa 10 digit nomor induk
pokok mahasiswa yang valid.
Dom (Tgl_lahir) = satu set tanggal lahir mahasiswa dengan format : dd-mm-
yyyy
Dom (Alamat) = satu set alamat mahasiswa berupa string alpha-numerik
dengan panjang maksimal 40 digit

Satu nilai relasi r dari suatu skema relasi R ( A1, A2, …, An ) yang
dituliskan sebagai : r (R) adalah satu set n-tuples r = { t1, t2, …, tn) , dimana :



Setiap n-tuple t merupakan satu list terurut dari n nilai-nilai t = <V1, V2, …,
Vn>, dimana setiap nilai Vi, 1 < i < n merupakan satu elemen dari dom(Ai),
atau berupa nilai khusus null (belum diketahui atau nilainya memang tidak
ada untuk beberapa tuple).
Definisi nilai relasi diatas dapat juga dinyatakan seperti berikut :
Suatu relasi r(R) adalah subset dari ‘Cartesian Product’ dari domain yang
mendefinsikan R :
r ( R ) ⊆ ( dom(A1) x dom(A2) x … x dom(An) )
Dari semua kemungkinan kombinasi yang ada, nilai relasi untuk satu waktu
tertentu hanya mencerminkan tuples yang valid yang menyajikan suatu state
tertentu dari sunia nyata.

4.1.2 Karakteristik-Karakteristik Relasi

Karakteristik pengurutan dan nilai dari tuples dan relasi adalah :
Pengurutan Tuple dalam suatu Relasi :
o Relasi didefinisikan sebagai satu set tuple
o Secara sistematis, elemen-elemen dari suatu set tidak mempunyai
urutan
o Jadi, tuple dalam suatu relasi tidak mempunyai urutan tertentu
Pengurutan Nilai dalam suatu Tuple
o Berdasarkan definisi sebelumnya bahwa suatu n-tuple merupakan satu
list terurut (ordered-list) dari n nilai
o Urutan-urutan nilai dalam suatu tuple juga urutan attribute dalam relasi,
menjadi penting
Nilai-nilai dalam Tuple
o Setiap nilai dalam suatu tuple merupakan satu nilai yang atomic (tidak
dapat diperoleh menjadi komponen-komponen yang lebih kecil dalam
kontek model relasional).
o Sehingga composite dan multivalued attribute tidak diperbolehkan dalam
model relasional.



o Attribute-attribute multivalued harus dipisahkan menjadi relasi-relasi
yang terpisah
o Attribute-attribute composite harus disajikan oleh simple attribute yang
membentuknya.

4.1.3 Konsep Foreign Key

Foreign Key atau kunci tamu adalah suatu attribut yang bukan key dalam
suatu tabel tetapi merupakan key dari tabel lain yang berelasi dengan tabel
tersebut.
Pada dua relasi R1 dan R2, satu set attribute FK dalam skema relasi R1
disebut dengan kunci tamu daru R2, jika memenuhi dua atutan berikut :
1. Attribut-attribut dalam FK mempunyai domain yang sama dengan
attribute-attribut yang menjadi primary key dalam skema relasi R2
Attribut-attribut FK dikatakan mengacu pada relasi R2
2. Suatu nilai FK dalam suatu tuple t1 dalam R1 mungkin :
a. berupa suatu nilai PK dalam sembarang tuple t2 dalam R2, atau
b. bernilai kosong (tidak ada)
dalam kasus (a), berlaku t1[FK] = t2[PK] dan dikatakan bahwa tuple t1
mengacu ke tuple t2.

4.2 Constraints Untuk Model Data Relasional

Constraint adalah batasan-batasan yang harus dipenuhi dalam
pembuatan model data relasional, yaitu :
1. Domain Constraints
Pada constraint ini, nilai dari setiap attribute suatu relasi harus atomic dari
domain attribute tersebut.
2. Key Constraints
Suatu relasi adalah satu set tuple. Dalam constraint ini semua elemen dalam
satu set harus berbeda (tidak boleh terdapat dua tuple yang mempunyai nilai
yang sama untuk semua attributnya).



3. Entity Integrity Constraint
Pada constraint ini berlaku , dalam suatu relasi tidak boleh terdapat “primary
key” yang bernilai kosong (NULL)
4. Referential Integrity Constraint
Constraint ini berkaitan dengan konsep FOREIGN KEY (Kunci tamu) antara
dua buah relasi yang mempunyai “relationship”.

4.3 Operasi-Operasi UPDATE Pada Relasi

Operasi update adalah proses pemanipulasian tuple yang terdiri dari
penambahan, perubahan, dan penghapusan tuple dalam suatu relasi. Ada tiga
operasi dasar, yaitu :
Insert
Delete
Modify
Penggunaan dari operasi update harus tidak melanggar integrity
constraint yang telah ditentukan pada skema basis data relasional

4.3.1 Operasi Insert

Operasi insert bertujuan untuk menyisipkan satu tuple baru ke dalam
suatu relasi R. Operasi ini memungkinkan untuk melanggar empat jenis
constraint sebagaimana dijelaskan berikut ini :
a. DOMAIN Constraint dapat dilanggar jika suatu nilai attribute yang diberikan
tidak ada dalam domain yang berkorespondensi dengan attribute tadi.
b. KEY Constraint dapat dilanggar jika nilai key dalam tuple baru t sudah ada
dalam tuple lain dalam relasi r(R).
c. ENTITY INTEGRITY Constraint dapat dilanggar jika primary key dari tuple
baru t adalah NULL



d. REFERENTIAL INTEGRITY Constraint dapat dilanggar jika nilai dari suatu
foreign key dalam t mengacu ke suatu tuple yang tidak ada dalam relasi yang
diacu.
Pada basis data COMPANY, manakah dari operasi insert berikut yang
valid ?
1. Insert < ’Kolonsky’, ‘6776’, ’05-Apr-58’, ‘6357 Windy Lane Texas’, F, 28000,
null, 4 > into EMPLOYEE
2. Insert < ’Zelaya’, ‘9998’, ’05-MayApr-58’, ‘6357 Windy Lane Texas’, F, 28000,
‘9876’, 4 > into EMPLOYEE
3. Insert <’Kolonsky’, null, ’05-Apr-58’, ‘6357 Windy Lane Texas’, F, 28000, null,
4 > into EMPLOYEE
4. Insert <’Kolonsky’, ‘6776’, ’05-Apr-58’, ‘6357 Windy Lane Texas’, F, 28000,
‘9876’, 7 > into EMPLOYEE
Ada dua pilihan tindakan yang dapat dilakukan jika ada satu atau lebih
constraint yang dilanggar akibat operasi insert, yaitu :
1. Menolak (reject) operasi insertion. Biasanya DBMS memberikan penjelasan
mengapa proses insertion ditolak.
2. Berusaha memperbaiki alasan penolakan proses insertion. Dimana insertion
akan diterima jika user melakukan perubahan nilai-nilai attribute sehingga
insertion diterima.

4.3.2 Operasi Delete

Operasi delete bertujuan untuk menghapus satu atau beberapa tuple di
dalam suatu relasi R. Operasi ini hanya dapat melanggar referential integrity, jika
tuple yang dihapus diacu oleh kunci-kunci tamu dari tuple yang lain dalam basis
data.
Dalam basis data COMPANY, manakah dari contoh operasi delete berikut
yang valid dan diterima ?
a. Delete tuple dalam WORKS_ON dengan ESSN = ‘9998’ dan PNO=10
b. Delete tuple dalam EMPLOYEE dimana SSN = ‘9998’
c. Delete tuple dalam EMPLOYEE dengan SSN = ‘333’



Ada tiga pilihan tindakan yang dapat dilakukan jika suatu deletion
melanggar constraint yang telah ditentukan, yaitu :
1. Menolak (reject) proses deletion
2. Berusaha untuk melakukan “cascade deletion”, yaitu dengan menghapus
sejumlah tuple yang mengacu pada tuple yang akan dihapus
3. Melakukan modifikasi nilai attribute yang mengacu pada tuple yang
dihapus, yaitu setiap nilai diset NULL atau diganti dengan nilai dari tuple
lain yang valid sebagai acuan baru. Akan tetapi, bila attribute yang
mengacu yang menyebabkan pelanggaran adalah bagian dari primary
key, maka ia tidak dapat diset NULL (karena melanggar entity integrity).
4. Kombinasi 2 dan 3

4.3.3 Operasi Modify

Operasi update digunakan untuk merubah nilai-nilai satu atau lebih
attribute dalam satu atau lebih tuple dalam sejumlah relasi R.
Operai modify bisa dilakukan pada tiga jenis attibut, dengan
permasalahan yang berbeda sebagaimana berikut ini :
1. Modifikasi nilai suatu foreign key, maka DBMS harus melakukan
pengecekan bahwa nilai-nilai baru yang diberikan mengacu pada tuple
yang ada dalam relasi-relasi yang dijadikan acuan.
2. modifikasi nilai suatu primary key serupa dengan proses deletion satu
tuple dan inserting yang lain pada tempat yang sama. Akibatnya, pilihan-
pilihan seperti yang dilakukan pada operasi INSERT dan DELETE dapat
dipakai agar modifikasi tidak melanggar constraint.
3. modifikasi suatu attribute yang bukan primary key atau bukan foreign key
biasanya tidak akan menimbulkan masalah. DBMS hanya perlu untuk
mengecek apakah nilai-nilai baru yang diberikan mempunyai tipe data dan
domain yang valid.



4.4 Mendefinisikan Relasi

Skema basis data harus didefiniskan pada saat diimplementasikan untuk
digunakan dalam sejumlah aplikasi, yang meliputi :
Keputusan mengenai attribut-atribut yang akan dikelompokkan dalam suatu
relasi
Menentukan nama-nama yang sesuai untuk relasi dan attribute
Menentukan domain dan tipe data untuk semua attribute yang ada
Mengidentifikasi candidate keys,dan memilih satu primary key untuk setiap
relasi serta menspesifikasikan semua foreign keys
pendefinisian ini sangat tergantung dari fasilitas-fasilitas yang dimiliki oleh
DBMS yang digunakan.
Contoh beberapa definisi relasi dari basisi data COMPANY :



CREATE TABLE EMPLOYEE
( FNAME VARCHAR(15) NOT NULL,
MINIT CHAR,
LNAME VARCHAR(15) NOT NULL,
SSN CHAR(4) NOT NULL,
BDATE DATE,
ADDRESS VARCHAR(30),
SEX CHAR,
SALARY DECIMAL(10,2).
SUPERSSN CHAR(9),
DNO INT NOT NULL DEFAULT 1,

CONSTRAINT EMPPK PRIMARY KEY(SSN),
CONSTRAINT EMPSUPERFK
FOREIGN KEY(SUPERSSN) REFERENCES EMPLOYEE(SSN)
CONSTRAINT EMPDEPFK
FOREIGN KEY(dno) REFERENCES DEPARTMENT(DNUMBER)
ON DELETE SET DEFAULT
ON UPDATE CASCADE
)

Gambar 4.1 Pendefinisian relasi pada basis data COMPANY

4.5 Algoritma Pemetakan Skema ER Ke Skema Relasional

Beberapa algoritma untuk memetakkan skema ER ke bentuk skema
relasional, yaitu :
Untuk entity regular (non-weak)
1. Untuk setiap entity regular dengan tipe E dalam skema ER, buat satu
relasi R yang attributnya meliputi semua simple attribute dari E. Untuk
suatu composite attribute, hanya komponen simple attributnya yang
dipetakkan.



2. Kemudian, pilih satu key attribute dari E sebagai primary key dari R. Jika
key terpilih adalah composite, maka primary key dari R dibentuk dari satu
set simple attribute dari composite
Pada step pertama ini, keterlibatan kunci tamu dan relationship attribute
jangan dipikirkan dulu.
Untuk weak entity
1. Untuk weak entity dengan tipe W dalam skema ER dengan owner entity
tipe E, buat satu relasi R yang attributnya meliputi semua simple attribute
atau simple component dari composite attribute.
2. Masukkan sebagai foreign key dalam R, primary key attribute dari relasi-
relasi yang merupakan owner (pemilik) dari W.
3. Primary key dari R dibentuk dari kombinasi antara primary key dari relasi-
relasi pemilik dan partial key dari weak entity tipe W.
Untuk relationship binary 1 : 1
1. Untuk setiap binary 1 : 1 relationship dengan tipe R dalam skema ER,
perhatikan relasi-relasi S dan T yang berkorespondensi dengan entity tipe
yang berpartisipasi dalam R.
2. Kemudian, ambil salah satu relasi (misalkan S) dan cantumkan primary
key dari T sebagai foreign key dalam S.
3. Untuk kasus ini, S sebaiknya dipilih dari entity tipe yang berpartisipasi total
dalam R (untuk mengurangi NULL values dari foreign key yang diambil dai
T).
Catatan, sebagai alternative untuk pemetakan dari 1 : 1 relationship tipe ini
adalah dengan menggabungkan kedua entity menjadi satu relasi tunggal.
Cara ini terutama sangat sesuai bilamana kedua entity berpartisipasi total dan
tidak berpartisipasi dalam relationship yang lain.
Untuk regular binary 1 : N relationship
1. Untuk setiap regular binary 1 : N relationship dengan tipe R, perhatikan
relasi S yang mewakili entity yang berpartisipasi pada sisi-N dari tipe
relationship.



2. Cantumkan primary key dari relasi yang berperan pada sisi-1 sebagai
forein key dalam S, karena setiap entity instance pada sisi-N terkait
dengan paling banyak satu entity instance pada sisi-1 dari tipe
relationship.
3. Kemudian cantumkan semua simple attribute atau simple component dari
composite attribute dari 1 : N relationship sebagai attribute dalam S.
Untuk binary M : N relationship
1. Untuk setiap binary M : N relationship dengan tipe R, buat satu relasi baru
S untuk mewakili R.
2. Kemudian cantumkan sebagai foreign key dalam S, primary key dari
relasi-relasi yang mewakili entity yang berpartisipasi dalam R; dimana
kombinasi dari primary keys ini akan membentuk primary key dari S
3. Cantumkan juga semua simple attribute atau semua simple component
dari composite attribute dari M : N relationship sebagai attribute dari S.
Catatan : Binary relationship 1 : 1 atau 1 : N selalu dapat dipetakkan seperti
pada M : N relationship. Alternatif ini terutama sangat berguna bilamana
relationship instances yang sangat sedikit (menghindari null values dalam
foreign key). Untuk kasus ini, primary key dari relasi “relationship” hanya akan
menjadi foreign key dari satu “entity” relasi yang berpartisipasi. Jadi, untuk 1
: N relationship, hanya pada sisi-N, sedang untuk 1 : 1 adalah entity relasi
yang berpartisipasi total (jika ada) yang dipilih.
Untuk multivalued attribute
1. Untuk setiap multivalued attribute A, buat satu relasi baru R yang
mencantumkan satu attribute yang mewakili A ditambah dengan primary
key K (sebagai foreign key dalam R) dari relasi yang mewakili tipe entity
atau tipe relationship yang mempunyai A sebagai attributnya.
2. Primary key dari R adalah kombinasi dari A dan K.
3. Jika multivalued adalah composite, maka hanya seimple component-nya
yang dicantumkan.
Untuk n-ary tipe relationship R (n > 2)



1. Untuk setiap n-ary tipe relationship R (n > 2), buat satu relasi baru S yang
mewakili R. Cantumkan sebagai foreign key attribute dalam S, primary
key dari relasi-relasi yang mewakili tipe entity yang berpartisipasi
2. Cantumkan juga sebagai attribute dalam S, semua simple attribute (atau
simple component dari composite attribute) dalam n-ary tipe relationship
3. Primary key dari S biasanya berupa kombinasi dari semua foreign key
yang mengacu pada relasi-relasi yang mewakili tipe entity yang
berpartisipasi. Namun, jika “participation constraint” (min,max) dari satu
tipe entity E yang berpartisipasi dalam R mempunyai max=1, maka
primary key dari S berupa satu foreign key attribute yang mengacu pada
relasi E. Ini dilakukan karena setiap entity instance e dalam E hanya akan
berpartisipasi dalam paling banyak satu relationship instance dalam R,
sehingga ia dapat secara unik mengidentifikasi relationship instance dari
R.

Korespondensi antara model ER dengan model relasional tampak
sebagaimana tabel berikut :
Tabel 4.1 Korespondensi model ER dengan model relasional
ER Model Relational Model
entity type “entity” relaton
1 : 1 or 1 : N relationship type foreignkey or “relationship” relation
M : N relationship type “relationship” relation and two foreign
keys
n-ary relationship “relationship” relation and n foreign
keys
simple attribute attribute
composite attribute set of simple component attributes
multivalued attribute relation and foreign key
value set domain
key attribute primary or secondary key


5. Structured Query Language (SQL)

5. STRUCTURED QUERY LANGUAGE (SQL)

Sistem basis data komersial menghendaki adanya sebuah bahasa
query yang lebih user-friendly. Oleh karena itu dikenal SQL sebagai bahasa
query yang marketable. SQL menggunakan kombinasi aljabar relasional &
kalkulus relasional.
SQL merupakan bahasa basis data relasional standard. Terdapat
macam-macam versi SQL. Versi aslinya pertama kali dikembangkan oleh
IBM San Jose Research Laboratory.
Meskipun SQL adalah bahasa query, namun SQL mempunyai banyak
kemampuan lain disamping melakukan query terhadap basis data. SQL
mempunyai kemampuan untuk mendefinisikan struktur data, modifikasi data
dalam basis data dan menentukan konstrain sekuriti.

5.1 Elemen SQL

Elemen dasar SQL mencakup pernyataan, nama, type data,
konstanta, ekspresi, dan bawaan.
Pernyataan
Peryataan adalah perintah SQL yang meminta sesuatu tindakan
kepada DBMS. SQL memiliki kira-kira 30 pernyataan. Beberapa pernyataan
dasar SQL dapat dilihat pada tabel dibawah ini:

Tabel 5.1 Pernyataan dalam SQL
Pernyataan Keterangan
ALTER Mengubah Struktur Tabel
COMMIT Mengakhiri sebuah eksekusi transakasi
CREATE Menciptakan tabel, indeks, dan pandangan
DELETE Menghapus baris pada tabel



DROP Menghapus tabel, indeks, atau pandangan
GRANT Menugaskan hak terhadap basis data pada pengguna
atau grup pengguna.
INSERT Menambah sebuah baris pada tabel
REVOKE Membatalkan hak terhadap basis data
ROLLBACK Mengembalikan ke keadaan semula sekiranya suatu
transaksi gagal dilaksanakan
SELECT Memilih baris dan kolom pada tabel
UPDATE Mengubah nilai pada sebuah baris

Nama
Nama digunakan sebagai identitas bagi obyek-obyek pada DBMS.
Contoh obyek pada DBMS adalah tabel, kolom, dan pengguna.

Tipe Data
Setiap data memiliki type data. Beberapa tipe data standar dapat
dilihat pada table dibawah ini.

Tabel 5.2 Tipe data standart dalam SQL
Tipe Data Keterangan
Untuk menyatakan deretan karakter (string). Misalnya, untuk
CHAR
menyatakan nama orang, nama jalan, atau nama kota.
INTEGER Untuk menyatakan bilangan bulat.
NUMERIC Untuk menyatakan bilangan real.

Beberapa tipe data perluasan (spesifik terhadap DBMS tertentu) dapat dilihat
pada table dibawah ini :



Tabel 5.3 Tipe data perluasan dalam SQL
Tipe Data Keterangan
VARCHAR untuk menyatakan string yang panjangnya bervariasi
MONEY Untuk menyatakan uang
BOOLEAN menyatakan tipe logis (True atau False)
untuk menyatakan data biner (gambar, suara,dan
BLOB
sebagainya)
SERIAL atau
untuk menyatakan nilai urut
AUTOINCREMENT

Konstanta
Konstanta menyatakan nilai yang tetap (kabalikan dari konstanta
adalah variable). Beberapa contoh konstanta:
Konstanta numeric : 123, -245, 5.45
Konstanta : ‘Jl. Sukapura 23’
Konstanta simbolik (konstanta yang tersedia pada SQL dan mempunyai
makna tersendiri): SYSDATE (tanggal system), USER (nama pengguna
yang menjalankan SQL). Konstanta simbolik seringkali disebut variable
system.

Ekspresi
Ekspresi adalah segala sesuatu yang menghasilkan nilai. Ekspresi
digunakan untuk menghitung nilai. Sebagai contoh :
(LABA / MODAL) * 100
merupakan ekspresi untuk membagi isi variable LABA dengan
MODAL, dan kemudian dikalikan dengan 100.
Simbol-simbol yang dapat digunakan pada ekspresi aritmatika dapat
dilihat pada table dibawah ini:



Tabel 5.4 Simbol pada ekspresi aritmatika
Simbol Keterangan
* Perkalian
/ Pembagian
+ Penjumlahan
- Pengurangan

Fungsi Bawaan
Fungsi adalah sebuah subprogram yang menghasilkan suatu nilai jika
dipanggil. SQL memiliki sejumlah fungsi bawaan (fungsi yang disediakan oleh
SQL). Sebagai contoh, terdapat fungsi bernama MIN yang berguna untuk
memperoleh nilai terkecil atau AVG untuk memperoleh nilai rata-rata.

5.2 Kelompok persyaratan SQL

Pernyataan SQL dapat dikelompokkan menjadi 5 kelompok, DDL,
DML, DCL, pengendalian transaksi, dan pengendalian progmatik.

5.2.1 DDL (Data Definition Language)
DDL merupakan kelompok perintah yang berfungsi untuk
mendefinisiksn atribut-atribut basis data, table, atribut (kolom), batasan-
batasan terhadap suatu atribut, serta hubungan antar table. Yang termasuk
dalam kelompok DDL ini adalah CREATE, ALTER, dan DROP.

5.2.2 DML (Data Manipulation Language)
DML adalah kelompok perintah berfungsi untuk memanipulasi data
dalam basis data, misalnya untuk pengambilan, penyisipan, pengubahan,
dan penghapusan data. Perintah yang masuk kategori DML adalah:



SELECT Memilih data
INSERT Menambah data
DELETE menghapus data
UPDATE Mengubah data

5.2.3 DCL (Data Control Language)
DCL berisi perintah-perintah untuk mengendalikan pengaksesan data.
Pengendalian dapat dilakukan berdasar per pengguna, per table, per kolom
maupun per operasi yang boleh dilakukan. Perintah-perintah yang termasuk
dalam DCL adalah :
GRANT Memberikan kendali pengaksesan data
REVOKE Mencabut kemampuan pengaksesan data
LOCK TABLE Mengunci table

5.2.4 Pengendali Transaksi
Pengendali transaksi adalah perintah-perintah yang berfungsi untuk
mengendalikan pengeksekusian transaksi. Perintah yang termasuk dalam
kategori ini :
COMMIT Menyetujui rangkaian perintah yang berhubungan erat (disebut
transaksi) yang telah berhasil dilakukan.
ROLLBACK Membatalkan transaksi yang dilakukan karena adanya
kesalahan atau kegagalan pada salah satu rangkaian perintah.

5.2.5 Pengendalian programatik
Pengendalian programatik mencakup pernyataan-pernyataan yang
berhubungan dengan pemanfaatan SQL dalam bahasa lain (SQL yang
dilekatkan). Pernyataan-pernyataan ini bias dipakai pada bahasa
konvensional (3-GL), seperti COBOL. Yang termasuk dalam pengendalian
programatik: DECLARE, OPEN, FETCH, dan CLOSE.



CLOSE Menutup kursor (pointer yang menunjuk ke table)
DECLARE Mendeklarasikan kursor
FETCH Mengambil nilai baris berikutnya
OPEN Untuk membuka kursor

5.3 Struktur Dasar

Struktur dasar dari ekspresi SQL terdiri dari tiga klausa yaitu : select,
from dan
where.
Klausa Select berhubungan dengan operasi proyeksi dari aljabar
relasional. Operasi ini digunakan untuk mendaftar semua atribut yang
diinginkan sebagai hasil suatu query.
Klausa From berhubungan dengan operasi Cartesian-product dari aljabar
relasional. Operasi ini mencatat semua relasi yang di”scan” dalam
evaluasi suatu query.
Klausa Where berhubungan dengan operasi predikat seleksi dari aljabar
relasional. Operasi ini terdiri dari sebuah predikat yang menyangkut
atributatribut dari relasi yang muncul dalam klausa from.
Sebuah query SQL biasanya mempunyai bentuk :
Select A1,A2,…..An
From r1,r2,….rn
Where P

5.3.1 Klausa Select

Contoh : “ Tentukan nama-nama dari semua cabang bank dalam relasi loan “
Query-nya :
select branch-name
from loan



Hasil dari query tersebut adalah sebuah relasi yang berisi sebuah
atribut tunggal dengan nama branch-name.
Bahasa query formal bersifat matematis dimana relasi adalah sebuah
himpunan sehingga tuple-tuple yang telah muncul tidak akan muncul lagi
(tidak akan terjadi duplikasi tuple).
Tapi dalam prakteknya untuk menghilangkan duplikasi tuple sangat
memakan waktu. Oleh karenanya SQL memungkinkan terjadinya duplikasi
tersebut. Dari contoh di atas, maka query-nya akan mencatat setiap branch-
name setiap kali branch-name tersebut ditemukan dalam relasi loan.
Untuk kasus di atas jika diinginkan untuk menghilangkan duplikasi
maka dapat disisipkan distinct setelah select. Query di atas ditulis ulang
sebagai berikut :
Select distinct branch-name
from loan
Jika tuple yang terduplikasi diinginkan hilang.
Klausa selest dapat juga mengandung operasi aritmatika yaitu
operator : +, -, *, / dan operasi terhadap konstanta atau atribut dari tuple.
Contoh query berikut :
Select branch-name, loan-number, amount * 100
From loan
Akan menghasilkan sebuah relasi yang sama dengan relasi loan,
kecuali bahwa atribut amount dikalikan dengan 100. SQL-92 juga
menyediakan tipe data spesial seperti tipe date, dan memungkinkan
beberapa fungsi aritmatika untuk beroperasi pada tipe-tipe ini.

5.3.2 Klausa Where

Contoh query : “Temukan semua loan number untuk pinjaman-
pinjaman yang dibuat pada cabang Perryridge dengan jumlah lebih besar dari
$1200”.
Query-nya ditulis sebagai berikut :



Select loan-number
From loan
Where branch-name = “Perryridge” and amount >1200
SQL menggunakan konektivitas lojik and, or dan not dalam klausa
where. SQL juga memasukkan perintah between untuk menentukan apakah
suatu nilai lebih kecil daripada atau sama dengan suatu nilai lain dan lebih
besar daripada atau sama dengan suatu nilai lain.
Contoh : jika diinginkan menemukan loan-number yang jumlah
pinjamannya antara $90000 dan $100000, ditulis sebagai berikut :
Select loan-number
From loan
Where amount between 90000 and 100000

5.3.3 Klausa From

Contoh query : “Untuk semua customer yang mempunyai sebuah
pinjaman dari bank, temukan nama dan loan number mereka”.
Dalam SQL ditulis :
Select distinct customer-name, borrower.loan-number
From borrower, loan
Where borrower.loan-number = loan.loan.number

5.3.4 Operasi Rename

SQL menyediakan mekanisme operasi rename untuk relasi dan
atribut. Operasi rename dalam SQL menggunakan klausa as dengan bentuk :
Nama-lama as nama-baru
Contoh : Jika atribut dengan nama loan-number akan diganti dengan
nama loan-id, dapat ditulis sebagai berikut :
Select distinct customer-name, borrower.loan-number as loan-id
From borrower,loan



Where borrower.loan-number = loan.loan-number and branch-name
= “Perryridge”

5.4 Operasi Himpunan

Operasi op erasi himpunan pada SQL-92 meliputi : union, intersect,
dan except. Union identik dengan ∗, intersect identik dengan ) dan except
identik dengan – pada aljabar relasional.

5.4.1 Operasi Union

Contoh : Untuk mendapatkan semua customer yang mempunyai
pinjaman, rekening atau keduannya pada bank ditulis :
(select customer-name from depositor)union
(select customer-name from borrower)
Operasi union secara otomatis akan menghilangkan duplikasi, tidak
seperti klausa select. Sehingga pada query di atas, jika Jones (seorang
customer) mempunyai beberapa rekening atau pinjaman (atau keduannya)
pada bank, maka Jones hanya akan muncul sekali. Jika duplikasi diinginkan
ada maka harus ditulis union all.

5.4.2 Operasi Intersect

Contoh : untuk mendapatkan semua customer yang memiliki pinjaman
dan rekening pada bank, query-nya ditulis :
(select distinct customer-name from depositor) intersect
(select distinct customer-name from borrower)
Operasi intersect secara otomatis menghilangkan duplikasi. Jika
diinginkan duplikasi tetap ada ditulis intersect all.

5.4.3 Operasi Except



Contoh : untuk mendapatkan semua customer yang mempunyai
sebuah rekening tetapi tidak memiliki pinjaman pada bank, ditulis :
(select distinct customer-name from depositor)
except
(select customer-name from borrower)

Operasi except secara otomatis menghilangkan duplikasi. Jika
diinginkan ada maka ditulis : except all.

5.5 Fungsi-Fungsi Agregasi

Yang termasuk fungsi-fungsi agregasi adalah :
Average : avg
Minimum : min
Maximum : max
Total : sum
Count : count
Fungsi-fungsi di atas telah tersedia. Input untuk avg dan sum haruslah
bertipe numerik. Untuk operator lainnya dapat non-numerik.
Contoh : untuk mendapatkan rata-rata saldo rekening pada cabang
Perryridge
Query-nya dapat ditulis :
Select avg(balance)
From account
where branch-name = “Perryridge”
Jika fungsi agregasi iningn diterapkan pada kelompok himpunan tuple,
maka digunakan klausa group by. Nama atribut/kel. Atribut dalam klausa
group by digunakan untuk membentuk grup/kelompok. Artinya tuple-tuple
yang mempunyai nilai yang sama pada semua atribut dalam klausa group-by
dimasukkan dalam satu grup/kelompok.
Contoh :
Select branch-name, avg(balance)



From account
Group by branch-name

Jika suatu fungsi diterapkan pada grup/kelompok yang dibentuk oleh
group by maka digunakan klausa having setelah group by.
Contoh : ingin ditampilkan nama cabang yang mempunyai rata-rata
saldo lebih dari 1200.
Query-nya :
Select branch-name, avg(balance)
From account
Group by branch-name having avg (balance)>1200
Fungsi agregrasi count sering digunakan untuk menghitung jumlah
tuple dalam suatu relasi. Notasi fungsi ini dalam SQL adalah count (*). Jadi
untuk menentukan jumlah tuple dalam relasi customer, ditulis :
Select count(*) from customer

5.6 Subqueri Tersarang (Nested Subqueries)

Biasanya digunakan untuk melalukuan test keanggotaan himpunan,
perbandingan himpunan dan kardinalitas himpunan.

5.6.1 Keanggotaan Himpunan

Digunakan in dan not in untuk melakukan test keanggotaan
himpunan.
Contoh : untuk mendapatkan semua customer yang mempunyai pinjaman
dan rekening pada bank.
Pertama : menemukan semua pemegang reeking dengan query :
(select customer-name from depositor)
Kedua : mencari semua customer yang merupakan peminjam dan yang
muncul dalam daftar pemegang rekening. Maka dilakukan dengan



“menyarangkan” subquery di atas dalam sebuah select luar (outer select),
menjadi :
Select distinct customer-name
from borrower
Where customer-name
in (select customer-name from depositor)

5.6.2 Perbandingan Himpunan

Perhatikan query berikut : “Temukan semua nama cabang bank yang
mempunyai asset lebih besar dari bank-bank yang mempunyai minimal satu
cabang berlokasi di Brooklyn”.
Query-nya ditulis :
Select branch-name from branch where assets > all
(select assets from branch where branch-city = “Brooklyn”)

5.7 Modifikasi Basis Data

Meliputi menambah, menghapus dan mengubah informasi
menggunakan SQL.

5.7.1 Penghapusan (Deletion)

Yang dapat dihapus (delete) hanyalah tuple bukan nilai pada suatu
atribut tertentu.
Dalam SQL, deletion diekspresikan dengan
Delete from r where p
Dimana p menunjukkan predikat dan r adalah relasi.
Contoh :
Hapus semua rekening Smith, ditulis :
Delete from depositor where costomer-name = “Smith”



Hapus semua pinjaman dengan jumlah pinjaman antara $1300 dan $1500
Delete from loan where amount between 1300 and 1500
Hapus semua rekening pada setiap cabang yang berlokasi di Perryridge
Delete from account where branch-name in
(select branch-name
from branch where branch-city = “Perryridge”)

5.7.2 Penyisipan (Insertion)

Untuk menambahkan satu tuple dalam relasi digunakan statement
insert.
Contoh :
Insert into account values (“Perryridge”,”A-9732”,1200)
Query ini identik dengan
Insert into account (branch-name, account-number,balance)
Values (“Perryridge”,”A-9732”,1200)
Insert juga dapat dilakukan untuk suatu hasil dari query yang lain.
Contoh :
Insert into account select branch-name, loan-number, 200

From loan where branch-name = “Perryridge”

5.7.3 Update

Dalam situasi tertentu, diinginkan untuk mengganti nilai dalam sebuah
tuple tanpa
harus mengganti semua nilai dalam tuple tersebut. Untuk tujuan ini dapat
digunakan statement update.
Contoh :
untuk menaikkan saldo para nasabah sebesar 5% ditulis query sebagai
berikut :
Update account set balance = balance * 1.05



untuk menaikkan saldo nasabah sebesar 6% bagi nasabah yang saldonya
lebih dari $10000, ditulis query sebagai berikut :
Update account set balance = balance *1.06
Where balance >10000

5.8 Bahasa Definisi Data (Data DefinitionLanguage)

DDL SQL memungkinkan dilakukannya spesifikasi tidak hanya pada
himpunan
relasi tetapi juga informasi untuk setiap relasi, yang meliputi :
Skema setiap relasi
Domain nilai setiap atribut relasi
Konstrain integritas
Himpunan indeks untuk setiap relasi
Sekuriti dan autorisasi setiap relasi
Struktur penyimpanan secara fisik untuk setiap relasi dalam disk.

5.8.1 Tipe-tipe Domain dalam SQL

SQL-92 standar mendukung bermacam-macam tipe domain yang
built-in sebagai
berikut :
char(n) : tipe karakter dengan panjang yang tetap (n) (fixed-length
character)
varchar(n) : tipe karakter dengan panjang bervariasi. Maksimum panjang
n.
int : integer
smallint : small integer



numeric (p,d) : p menunjukkan jumlah digit bilangan dan d menunjukkan
julahdigit dibelakang titik desimal.
real, double precision : floating-point dan double-precision floating point
float (n) : floating-point number
date : tipe kalender
time : tipe hari dalam jam,menit dan detik
SQL-92 menggunakan klausa create domain untuk mendefinisikan
domain.
Contoh :
create domain person-name char(20)

5.8.2 Definisi Skema dalam SQL

Untuk mendefinisikan sebuah relasi dengan perintah create table :
Create table r(A1D1,A2D2,….AnDn,
<integrity contraint1>,
……………,
<integrity contrantk>)
Dimana r adalah nama relasi, setiap AI adalah nama atribut dalam
skema relasi, dan DI adalah tipe domain dari nilai dalam domain atribut Ai.
Integrity constraint yang diperbolehkan antara lain : primary key (Aj1,
Aj2,….Ajn) dan check (P)
Contoh :
Create table customer
( customer-name char(20) not null,
customer-street char(30),
customer-city char(30),
primary key (customer-name)
)
create table branch
( branch-name char(15) not null,
branch-city char(30),



assets integer,
primary key (branch-name), check(assets >=0)
)
create table account
( account-number char(10) not null,
branch-name char(15),
balance integer, primary key (account-number),
check (balance >=0))
create table depositor
( customer-name char(20) not null,
account-number char(10) not null,
primary key (customer-name, account-number)

)


6. Pengukuran Skema Relasional

6. PENGUKURAN SKEMA RELASIONAL
Pengukuran skema relasi memiliki tujuan untuk mengupayakan agar
memperoleh skema relasi yang “baik” yaitu untuk mengukur secara formal
mengapa satu set pengelompokan atribut menjadi sejumlah skema relasi adalah
lebih baik dari lainnya.

6.1 Petunjuk - Petunjuk Informal Dalam Desain Skema Relasional

Ada empat ‘ukuran informal’ mengenai kualitas desain skema relasi, yaitu
:
- Semantik dari attribute
- Reduksi nilai-nilai yang redundan dalam tuples
- Reduksi nilai-nilai null dalam tuples
- Tidak mempunya tuples yang aneh (spurious tuples)

6.2 Semantik Dari Atribut

Semantik (arti) menjelaskan bagaimana menginterprestasikan nilai-nilai
attribute yang disimpan dalam suatu tuple dari suatu relasi, yaitu bagaimana
nilai-nilai attribute dalam suatu tuples berkaiatan dengan yang lain.
PETUNJUK 1 :
• Desain suatu skema relasional sedemikian rupa sehingga semantic yang
dikandungnya mudah untuk dijelaskan
• Jangan mengkombinasikan attribute-attribute dari sejumlah entity dan
relationship menjadi satu relasi tunggal
• Secara logika, jika suatu skema berkorespondensi dengan satu entity atau
satu relasionship saja, maka arti yang dikandungnya cenderung menjadi lebih
jelas.
Skema-skema relasi dalam basis data COMPANY yang diberikan dalam
contoh-contoh sebelumnya merupakan skema relasi yang memenuhi petunjuk 1
diatas.



Dibawah ini diberikan contoh penurunan skema relasi yang menyalahi
petunjuk 1 diatas.
(a) EMP_DEPT (EName, SSN, BDate, DNumber, DName, DMgrSSN)
--- mengkombinasikan relasi-relasi EMPLOYEE dan DEPARTMENT
(b) EMP_PROJ (SSN, PNumber, Hours, EName, PName, PLocation)
--- mengkombinasikan relasi-relasi WORKS_ON dan PROJECT

6.3 Informasi yang Redundan dan Update Anomalies

Salah satu tujuan dari desain skema adalah untuk meminimumkan
pemakaian storage yang dipakai oleh base relations (file).
Pengelompokan sejumlah atribut menjadi skema-skema relasi yang baik
mempnyai dampak yang berarti dalam mengurangi pemakaian storage.
Contoh :
Relasi
EMP_DEPT (EName, SSN, BDate, DNumber, DName, DMgrSSN)
yang merupakan hasil NATURAL JOIN dari sebagian atribut EMPLOYEE dan
DEPARTMENT, dan relasi
EMP_PROJ (SSN, PNumber, Hours, EName, PName, PLocation)
Yang merupakan modifikasi dari relasi WORKS_ON dengan tambahan atribut
dari PROJECT dan EMPLOYEE, akan membutuhkan pemakaian storage yang
lebih besar, karena adanya pengulangan (repeating group) dari :
(DName, DNumber, DMgrSSn)
dalam relasi EMP_DEPT (untuk setiap employee dalam satu
departemen yang sama)
(PName, PLocation)
dalam relasi EMP_PROJ (untuk setiap employee yang bekerja
dalam satu project yang sama)
Persoalan lain yang lebih serius dari kedua relasi diatas bilaman dijadikan
sebagai base relations adalah timbulnya “Update Anomalies”, yang meliputi :
- Insertion anomalies
- Deletion anomalies



- Modification anomalies

Insertion Anomalies
Pada insertion anomalies terdapat dua persoalan, yaitu :
• Persoalan kecenderungan terjadinya inkonsistensi data. Sebagai contoh,
dalam relasi EMP_DEPT, setiap kali suatu tuple baru ditambahkan, maka
atribut-atribut dari department dimana seorang employee bekerja HARUS
dituliskan secara tepat. Jika tidak maka akan terjadi nilai-nilai yang
inkonsisten untuk sejumlah nomor department yang sama.
• Persoalan kesulitan penyisipan tuple baru. Sebagai contoh, masih untuk
relasi EMP_DEPT, jika suatu department telah ada (didefinisikan) tapi belum
ada employee di dalamnya, maka satu-satunya cara adalah dengan mengisi
nilai-nilai NULL pada sejumlah atribut untuk employee. Tetapi cara ini
menyalahi entity integrity constraint, dimana key dari suatu relasi tidak boleh
bernilai NULL.

Deletion Anomalies
Anomali ini berkaitan erat dengan persoalan kedua dalam insertion
anomalies, dimana untuk kasus relasi EMP_DEPT, jika suatu tuple employee
yang merupakan satu-satunya employee untuk suatu department dihapus, maka
informasi mengenai department akan terhapus dari basis data.

Modification Anomalies
Dalam relasi EMP_DEPT, jika nilai dari salah satu atribut employee untuk
suatu department tertentu diubah (misalnya nama department diubah), maka
semua tuple employee yang bekerja pada department tersebut juga harus
diubah. Jika ada tuple yang tertinggal tidak diubah, maka akan terdapat dua
nama yang berbeda untuk satu department yang sama (yang seharusnya tidak
boleh terjadi).



PETUNJUK 2 :
Desain suatu skema relasi dasar (base relation schema) sedemikian rupa
sehingga ketiga jenis anomaly (insertion, deletion, dan modification) tidak akan
terjadi.

6.4 Nilai-Nilai Null dalam Tuples

Dalam hasil desain suatu skema relasi, mungkin saja terdapat
pengelompokkan sejumlah atribut menjadi suatu relasi dengan jumlah atribut
yang besar. Jika tedapat sejumlah sub-set atribut yang tidak berlaku untuk
semua tuple dalam relasi, maka akan terdapat sejumlah nilai-nilai NULL dalam
sejumlah tuples tersebut yang akan mengakibatkan :
- Pemborosan storage
- Timbulnya persoalan simantik dari atribut
- Kesulitan dalam merealisasikan operasi JOIN
- Kesulitan dalam merealisasikan fungsi-fungsi aggregate (seperti
SUM, COUNT, dan AVERAGE)
Selain kesulitan-kesulitan diatas, nilai-nilai NULL dapat memberikan
interpretasi jarak (multiple interpretations) terhadap tuple yang didalamnya
terdapat atribut-atribut dengan nilai null :
- Atribut-atribut tersebut tidak terpakai untuk tuple
- Nilai-nilai atribut untuk tuple tidak diketahui
- Nilai-nilainya dikehendaki, tapi belum tercatat atau tersedia

PETUNJUK 3 :
Sedapat mungkin, hindari penempatan atribut-atribut dalam suatu base relation
yang memungkinkan timbulnya nilai-nilai null. Jika nilai-nilai null tidak dapat
dihindari, yakinkan bahwa hal tersebut hanya berlaku untuk kasus-kasus khusus
dan jangan diberlakukan terhadap sebagian besar dari tuple dalam suatu relasi.



Sebagai contoh, jika hanya terdapat 10% dari keseluruhan employee yang
mempunyai kantor pribadi, maka merupakan suatu cara perancangan yang
beralasan apabila satu atribut OFFICE_NUMBER dimasukkan dalam relasi
EMPOLYEE; tetapi akan lebih baik apabila dibuatkan satu relasi baru yang terdiri
dari dua atribut (ESSN, OFFICE_NUMBER) yang dipakai untuk menyimpan data
employee yang mempunyai kantor pribadi.

6.5 Tuples yang Tidak Dikehendaki (Spurious Tuples)

Untuk ini, seandainya relasi :
didekomposisi menjadi dua relasi :
EMP_LOCS (EName, PLocation)
EMP_PROJ1 (SSN, PNumber, Hours, PName, PLocation)
maka, jika kedua relasi hasil dekomposisi di atas diupayakan untuk dilakukan
NATURAL JOIN (lewat atribut “PLocation” ) maka akan muncul beberapa tuple
yang tidak valid.
Keadaan ini dapat terjadi karena terdapat sejumlah tuple hasil JOIN untuk
“PLocation” yang sama, pasangan tuple “SSN” dan “EName” yang dihasilkan
bukan merupakan pasangan yang valid.
Sejumlah tuple yang ada dalam hasil JOIN tetapi tidak ada dalam relasi
EMP_PROJ disebut spurious tuple yaitu tuple yang tidak dikehendaki dan tidak
valid.

PETUNJUK 4:
Dalam mendesain skema-skema relasi harus diupayakan sehingga skema-
skema yang dihasilkan dapat dilakukan JOIN dengan kondisi kesamaan (EQUI
JOIN atau NATURAL JOIN) pada atribut-atribut yang berupa primary key atau
foreign key, dengan cara yang menjamin bahwa spurious tuples tidak akan
dihasilkan


7. Ketergantungan Fungsional

7. KETERGANTUNGAN FUNGSIONAL

Konsep ketergantungan fungsional merupakan salah satu konsep yang
sangat penting dalam desain skema relasional, karena konsep ini dapat secara
formal mendefinisikan bentuk-bentuk relasi yang normal (normalisasi data)
Penggunaan utama dari konsep ketergantungan fungsional adalah untuk
memberikan penjelasan lebih jauh suatu skema relasi R dengan menyatakan
constraint pada sejumlah atribut yang harus berlaku pada setiap saat.

7.1 Definisi Ketergantungan Fungsional

Ketergantungan fungsional merupakan satu constraint antara dua set
atribut suatu basis data. Jika suatu skema basis data relasional dengan n buah
atribut dinyatakan dalam bentuk universal :
R = { A1, A2, …, An-1, An }
Maka ketergantungan fungsional (disingkat FD) antara dua set atribut X dan Y
(keduanya subset dari R), dinotasikan X Y, menyatakan satu constraint
pada sejumlah tuples yang memungkinkan dapat membentuk relation instance r
dari R, yaitu

Untuk sembarang pasangan tuples t1 dan t2 dalam r sedemikian rupa
sehingga jika berlaku t1[X] = t2[X], maka juga berlaku t1[Y] = t2[Y]

Dari constraint diatas, dapat dikatakan bahwa nilai-nilai komponen tuple
dari X dapat secara unik (atau secara fungsional) menentukan nilai-nilai dari
komponen Y. Sebaliknya, dapat juga dikatakan bahwa Y secara fungsional
tergantung pada X.
Jadi, X secara fungsional menentukan Y dalam suatu skema relasi R jika
dan hanya jika, bilamana dua tuples dari r(R) mempunya nilai X yang sama,
maka kedua tuples ini juga harus mempunyai nilai Y yang sama.



Sebagai contoh perhatikan skema relasi EMP_PROJ :
yang dari semantic atributnya berlaku ketergantungan fungsional berikut :
(a) SSN EName
(b) PNumber { PName, PLocation }
(c) { SSN, PNumber } Hours

Perlu diingat !
1. Jika suatu constraint pada R berlaku bahwa tidak boleh ada lebih dari
satu tuple untuk satu nilai X dalam sembarang relasi instance r(R) yang
artinya bahwa X merupakan candidate key dari R, mengisyaratkan
bahwa X Y untuk sembarang subset atribut Y dari R.
2. Jika berlaku X Y dalam R, hal ini tidak menyatakan bahwa apakah
berlaku atau tidak Y X.
3. Ketergantungan fungsional merupakan sifat dari skema (intension) relasi
R, bukan merupakan keadaan relasi tertentu (extension). Dengan
demikian, suatu FD tidak dapat diturunkan secara otomatis dari suatu
relasi, tetapi harus didefinisikan secara eksplesit oleh mereka yang
mengerti semantic atribut dari relasi R.

7.2 Aturan Penurunan (Inference Rules) Untuk FD

Suatu FD X Y diturunkan dari satu set dependencies F dalam R jika X
Y berlaku dalam setiap keadaan relasi r. Dengan kata lain, bilamana r
memenuhi semua dependencies dalam F, maka X Y juga berlaku dalam r.
Satu set dari semua functional dependencies yang dapat diturunkan dari F
disebut “ Closure F+ dari F ”.
Untuk memperoleh cara yang sistematik dalam menurunkan
dependencies, diperlukan satu set INFERENCE RULE yang dapat digunakan
untuk menurunkan dependencies yang baru dari satu set dependencies yang
diberikan.



Notasi F X Y digunakan untuk menyatakan bahwa functional
dependency X Y diturunkan dari satu set FD F

Untuk tujuan mempersingkat penulisan variable-variabel atribut, digunakan
notasi :
FD { X,Y } Z disingkat XY Z
FD { X, Y, Z } { U, V } disingkat XYZ UV
Terdapat enam aturan atau rumus untuk functional dependencies, yaitu :
1. Rumus Reflexive
Jika X ⊇ Y , maka X Y
2. Rumus Augmentation
{X Y} XZ YZ
3. Rumus Transitive
{X Y, Y Z} X Z
4. Rumus Decomposition atau Projection
{X YZ } X Y
5. Rumus Union atau Additive
{X Y, X Z} X YZ
6. Rumus Pseudotransitive
{X Y, WY Z} WX Z

Rumus 1 s/d 3 dikenal sebagai Armtrong’s Inference Rules, dimana set
dependencies F+ dapat diturunkan hanya dengan menggunakan ketiga rumus

7.3 Algoritma Mencari X+

X+ : Closure of X under F

Pada perancangan basis data biasanya mendefinisikan ketergantungan
fungsional F (FD F) yang dapat ditentukan dari sematik atribut dalam R.
Kemudian mendefinisikan ketergantungan fungsional tambahan dengan
penurunan menggunakan Armstrong’s rule pada F



Ketergantungan fungsional tambahan secara sistematik dapat diperoleh
dengan cara : pertama menentukan setiap set atribut X yang muncul di sisi
sebelah kiri dari FD dalam F. Kemudian mencari semua atribut yang tergantung
pada X dengan menggunakan Armstrong’s rule.
Algoritmanya :
X+ := X ;
REPEAT
oldX+ := X+ ;
FOR each FD Y Z dalam F DO
IF Y ⊆ X+ THEN X+ := X+ ∪ Z ;
UNTIL (oldX+ = X+);

Contohnya :
Perhatikan skema EMP_PROJ yang mempunyai satu set FD F berikut :
F = { SSN EName,
PNumber { PName, PLocation },
{ SSN, PNumber } Hours
}
Dengan menggunakan algoritma untuk mengitung X+ dengan berdasarkan pada
F, maka diperoleh :
{ SSN }+ = { SSN, EName }
{ PNumber }+ = { PNumber, PName, PLocation }
{ SSN,PNumber}+ = {SSN, PNumber, EName, PName, PLocation, Hours}

7.4 Set Ketergantungan Fungsional Yang Ekivalen

Definisi :
Satu set FD E dilingkup (covered) oleh satu set FD F (atau F melingkup
E), jika setiap FD dalam E juga ada dalam F+. Dengan kata lain E dilingkup oleh
F jika setiap dependency dalam E dapat diturunkan dari F.



Dua set functional dependencies E dan F dikatakan ekivalen ( E = F ) jika
E+ = F+. Ekivalen berarti bahwa setiap FD dalam E dapat diturunkan dari F, dan
setiap FD dalam F dapat diturunkan dari E.Jadi E ≡ F jika kedua kondisi, yaitu E
melingkupi F dan F melingkupi E terpenuhi.
Untuk menentukan apakah F melingkupi E dapat dilakukan dengan :
- Menghitung X+ dengan berdasarkan pada F untuk setiap FD X Y dalam E
- Periksa apakah atribut-atribut dalam Y ada dalam X+. Jika “Ya” untuk setiap
FD dalam E maka dikatakan F melingkup E.

7.5 Set Ketergantungan Fungsional Yang Minimal

Satu set functional dependencies F dikatakan minimal apabila memenuhi
kondisi-kondisi berikut :
a. Setiap dependency dalam F mempunyai satu atribut tunggal pada sisi
kanannya.
b. Sembarang dependency dalam F tidak dapat dihapus dan tetap
mempertahankan bahwa satu set FD yang dihasilkan adalah ekivalen dengan
F.
c. Sembarang dependency X A tidak dapat diganti dengan satu dependency
Y A, dimana Y ⊂ X, dan tetap menghasilkan FD yang ekivalen dengan F.
Set FD yang minimal diatas dapat dipandang sebagai satu set
dependensa dalam bentuk standart (canonical) tanpa redundansi. Dimana
kondisi (b) dan (c) menjamin bahwa tidak ada redundansi dalam dependensi.
Sedangkan kondisi (a) menjamin bahwa setiap dependensi ada dalam bentuk
canonical dengan satu atribut tunggal pada sisi kanannya.


8. Normalisasi

8. NORMALISASI

Normalisasi merupakan teknik analisis data yang mengorganisasikan atau
mengelompokkan atribut-atribut data sehingga terbentuk entitas yang non-
redundant, stabil, dan fleksibel.
Normalisasi dilakukan sebagai uji coba pada suatu relasi secara
berkelanjutan untuk menentukan apakah relasi itu sudah baik, yaitu dapat
dilakukan proses insert, update, delete, dan modifikasi pada satu atau beberapa
atribut tanpa mempengaruhi integritas data dalam relasi tersebut.
Dalam perancangan basis data, normalisasi berperan sebagai :
- Kerangka kerja formal untuk menganalisa skema relasi yang didasarkan pada
primary keys dan functional dependencies antara atribut-atribut.
- Satu urutan test yang dapat dilakukan pada masing-masing skema relasi,
sehingga basis data relasional dapat dinormalisasi ke suatu tinggak tertentu.
Bilamana suatu test gagal, maka relasi yang menyalahi test harus
didekomposisi menjasi sejumlah relasi yang masing-masing memenuhi
kaidah normalisasi.

8.1 Bentuk Normal

Ada enam tingkatan dalam normalisasi yang masing-masing
menghasilkan bentuk normal sebagai berikut :
- 1 NF
- 2 NF di definisikan hanya dengan memperhatikan
- 3 NF functional dependencies dan key constrains

- BCNF
- 4 NF + constraint multivalued dependency
- 5 NF + constraint join dependency
Skema relasi dikatakan menjadi sebuah bentuk normal tertentu bila ia
memenuhi beberapa kondisi tertentu. Misalnya, sebuah skema relasi dikatakan


8. Normalisasi

berada dalam bentuk normal kedua (2NF) jika dan hanya jika ia berada dalam
1NF dan juga memenuhi kondisi lain yang disyarakan untuk menjadi 2NF.

8.2 First Normal Form ( 1NF )

Secara histories, 1NF didefinisikan untuk tidak membolehkan adanya
atribut yang berulang (multivalued attribute) atau yang bernilai ganda (composite
attribute) atau kombinasi keduanya. Dalam 1NF disebutkan bahwa domains dari
attribute harus hanya terdiri dari nilai yang berdiri sendiri (atomic values), dan
nilai dari sembarang attribute dalam suatu tuple harus berupa nilai tunggal
(single values) dari domain atribut tersebut.
Syarat suatu skema relasi bisa berada dalam bentuk 1NF jika :
1. Tidak ada set atribut yang berulang atau bernilai ganda.
2. Telah ditentukannya primary key untuk tabel atau relasi.
3. Tiap atribut hanya memiliki satu pengertian.
Jika ada atribut yang memiliki banyak nilai maka harus digambarkan dalam
sebuah entitas atau relasi yang terpisah.
Contoh 1NF :
EMPPROJ ( SSN, ENama, { PROJ ( PNumber, Hours) } )
1NF
EMP_PROJ1 ( SSN, EName )
EMP_PROJ2 ( SSN, PNumber, Hours )

8.3 Second Normal Form ( 2NF )

2NF didefinisikan pada skema relasi R jika setiap non_prime atributnya
secara fungsional bergantung penuh pada key dari R.
2NF didasarkan pada konsep “full function dependency”. FD X Y
disebut full function dependency, jika penghapusan sembarang atribut A dari X
menyebabkan sifat dependency tidak berlaku lagi; yaitu untuk sembarang atribut


8. Normalisasi

A ∈ X, maka (X – {A}) Y. Sebaliknya, FD X Y disebut partial dependency
jika beberapa atribut A ∈ X dapat dihapus dari X dan tetap mempertahankan
dependency yang ada; yaitu untuk A ∈ X, ( X – {A} ) Y.
Contoh :
{ SSN, PNumber } Hours
Merupakan full dependency, karena SSN Hours
PNumber Hours
{ SSN, PNumber } EName
Merupakan partial dependency, karena SSN EName
1.. Bentuk data telah memenuhi kriteria bentuk normal ke satu.
2. Atribut bukan kunci(non-key attribute) haruslah memiliki ketergantungan
fungsional sepenuhnya pada primary key
Contoh 2NF :
EMPPROJ (SSN, PNumber, Hours, EName, PName, PLocation)
fd1
fd2
fd3
Normalisasi 2NF
EP1 (SSN, PNumber, Hours)
fd1
EP2 (SSN, EName)
fd2
EP3 (PNumber, PName, PLocation)
fd3

Kesimpulan :
Jika suatu skema relasi tidak berada dalam 2NF, ia dapat dinormalisasi lanjut
menjadi sejumlah relasi 2NF dengan cara mengasosiasikan non-key atribut
yang ada hanya dengan sebagian dari primary key dimana atribut-atribut
tersebut secara fungsional bergantung penuh.


8. Normalisasi

8.4 Third Normal Form ( 3NF )

3NF didasarkan pada konsep “transitive dependency”. Dimana suatu FD
X Y dalam suatu relasi R merupakan transitiven dependency jika terdapat satu
set atribut Z yang tidak merupakan subset dari sembarang key dari R, dan
berlaku X Z dan Z Y.
1.. Bentuk data telah memenuhi kriteria bentuk normal ke dua (2NF).
2. Atribut bukan kunci (non-key attribute) tidak boleh memiliki
ketergantungan secara transitif pada primary key.
Contoh 3NF :
EMP_DEPT ( EName, SSN, BDate, Address, DNumber, DName,
DMGRSSN )
fd1
fd2
3NF
ED1 ( EName, SSN, BDate, Address, DNumber )
fd1
ED2 ( DNumber, DName, DMGRSSN)
fd2
Operasi Natural JOIN terhadap ED1 dan ED2 akan menghasilkan relasi
EMP_DEPT semula (tanpa ada spurious tuples)
Definisi Umum 3NF :
Suatu skema relasi R ada dalam 3NF bilamana berlaku suatu FD X A
dalam R, dan memenuhi kondisi :
(a) X adalah superkey dari R, atau
(b) A adalah prime atribut dari R
Implikasinya :
- Suatu skema relasi R menyalahi definisi umum 3 NF, jika berlaku FD X A
dalam R yang menyalahi baik kondisi (a) ataupun (b).


8. Normalisasi

- Suatu skema relasi R berada dakam 3NF, jika setiap non-prime atribut dari R
:
• Secara fungsional bergantung penuh pada setiap key dari R, dan
• Secara non-transitive bergantung pada setiap key dari R.

Definisi umum dari 3NF dapat diaplikasikan secara langsung untuk memeriksa
apakah suatu skema relasi berada dalam 3NF (tanpa perlu melalui
pemeriksaan 2NF terlebih dahulu).

Contoh lain penurunan relasi-relasi 2NF dan 3NF :
Pada basis data “Parcel of lend for sale” dalam berbagai negara bagian di USA,
terdapat relasi sebagai berikut :
LOTS (Property_ID#, Country_Name, Lot#, Area, Price, Tax_Rate)
fd1
fd2
fd3
fd4
Ada dua candidate keys, yaitu :
- Propert_ID#
- { Country_Name, Lot# }
Penurunan melalui normalisasi 2NF :
Pada contoh diatas, fd3 menyalahi aturan normalisasi 2NF, sehingga menjadi :
LOTS1 (Property_ID#, Country_Name, Lot#, Area, Price)
fd1
fd2
fd4
LOTS2 (Country_Name, Tax_Rate)
Fd3
Pada contoh diatas, fd4 masih menyalahi aturan normalisasi 3NF, sehingga
menjadi :
LOTS1A (Property_ID#, Country_Name, Lot#, Area)


8. Normalisasi

fd1
fd2
LOTS1B (Area, Price)
Fd4
LOTS2 (Country_Name, Tax_Rate)
Fd3
Penurunan melalui normalisasi 2NF diatas dapat digambarkan sebagai berikut :

LOTS 1NF

LOTS 1 LOTS 2 2NF

LOTS1A LOTS1B LOTS2 3NF

Penurunan tanpa melalui normalisasi 2NF :
Dari keempat FD yang ada (fd1 s/d fd 4) dalam skema relasi LOTS, terlihat
bahwa fd3 dan fd4 menyalahi 3NF, sehingga dapat langsungdidekomposisi
menjadi LOTS1A, LOTS1B, dan LOTS2.

8.5 Boyce/Codd Normal Form (BCNF)

BCNF merupakan bentuk normal yang lebih ketat dibandingkan 3NF. Dan
ini berarti bahwa setiap relasi dalam BCNF juga berada dalam 3NF, tetapi tidak
sebaliknya.
Suatu skema relasi berada dalam BCNF bilamana berlaku suatu FD X
A dalam R, maka X merupakan superkey dari R. Jadi perbedaan antara BCNF
dan 3NF adalah kondisi (b) dari 3NF yang membolehkan A untuk prime jika X
bukan superkey TIDAK BOLEH ada dalam BCNF.
Jika dalam relasi LOTS1A berlaku FD tambahan (fd5) :
LOTS1A (Property_ID#, Country_Name, Lot#, Area)
fd1


8. Normalisasi

fd2
fd5
BCNF
LOTS1AX (Property_ID#, Area, Lot#)
LOTS1AY (Area, Country_Name)
fd2 hilang dari hasil dekomposisi BCNF
Kesimpulan Akhir :
Dalam praktik, kebanyakan skema-skema relasi yang berada dalam 3NF
juga berada dalam BCNF. Hanya jika ada dependency X A dalam skema
relasi R dengan X bukan superkey dan A adalah prime atribut, akan menjadikan
R berada dalam 3NF tetapi tidak berada dalam BCNF
Kasus umum :
R ( A, B, C ) berada dalam 3NF, tetapi tidak dalam BCNF

Jadi, dalam proses normalisasi : upayakan untuk membentuk BCNF, dan
jika tidak memungkinkan baru biarkan berada dalam 3NF.

8.6 Multivalued Dependencies Dan Fourth Normal Form ( 4NF )

Multivalued dependencies timbul sebagai konsekuensi dari bentuk normal
pertama yang tidak membolehkan sebuah atribut dalam suatu tuple untuk
memiliki satu set nilai (multivalue).
Bilamana dua atau lebih atribut-atribut multivalued yang satu sama lain
independent terdapat dalam satu skema yang sama, maka akan muncul
persoalan “repeating group” dari setiap nilai dari salah satu atribut dengan setiap
nilai atribut yang lain untuk menjaga konsistensi dari relation instances.
Constraint ini disebut multivalued dependency
Contoh :
Relasi EMP :
EName PName DName
Smith X John


8. Normalisasi

Smith Y Anna
Smith X Anna
Smith Y John

Multivalued : pasangan { EName, PName } dan { EName, DName }

Definisi Formal Multivalued Dependency
Secara formal, suatu multivalued dependency (MVD) X Y yang
berlaku dalam skema relasi R, dimana X dan Y keduanya merupakan subset dari
R, menjelaskan constraint berikut pada setiap sembarang relasi r dari R :
Jika dua tuple t1 dan t2 ada dalam r, t1[ x ] = t2[ x ], maka sembarang dua
tuple t3 dan t4 harus juga ada dalam r yang memenuhi sifat-sifat :
- t3[ x ] = t4[ x ] = t1[ x ] = t2[ x ]
- t3[ Y ] = t1[ Y ] dan t4[ Y ] = t2[ Y ]
- t3[ R – (XY) ] = t2[ R – (XY) ] dan t4[ R – (XY) ] = t1[ R – (XY) ]
Suatu MVD dalam R disebut TRIVIAL jika :
(a) Y merupakan subset dari X, atau
(b) X ∪ Y = R
MVD selain TRIVIAL disebut NON-TRIVIAL. Contoh Non-Trivial adalah
relasi EMP diatas, dimana hasil dekomposisi menjadi 2 relasi berikut disebut
sebagai MVD Trivial :
EMP_PROJ ( EName, PName )
EMP_DEP ( EName, DName )

Definisi 4NF

Suatu skema relasi R berada dalam 4NF berdasarkan pada satu set
dependency F jika, untuk setiap nontrivial multivalued dependency X Y
+
dalam F , x adalah superkey dari R.
Contoh :


8. Normalisasi

Relasi EMP (EName, PName, DName) diatas tidak berada dalam 4NF,
karena terdapat nontrivial MVD :
EName PName
EName DName
dan EName bukan superkey
Tetapi relasi hasil dekomposisi :
EMP_PROJ (EName, PName)
EMP_DEP (EName, DName)
Keduanya berada dalam 4NF karena :
EName PName dalam EMP_PROJ
EName DName dalam EMP_DEP
Keduanya merupakan trivial MVD

8.7 Dependensi Gabungan Dan Fifth Normal Form (5NF)

Bentuk normal kelima yang terkadang disebut PJ/NF (Projection
Join/Normal Form), menggunakan acuan dependensi gabungan. Suatu relasi R
(X, Y, ..., Z) memenuhi dependensi gabungan jika gabungan dari proyeksi A, B,
..., C dengan A, B, ..., C merupakan sub-himpunan dari atribut-atribut R.
Dependensi gabungan sesuai dengan definisi di atas dinyatakan dengan
notasi:
* ( A, B, …, C )
dengan A = XY, B = YZ, C = ZX
Contohnya terlihat pada relasi berikut :

Definisi 5 NF


8. Normalisasi

Suatu relasi berada dalam 5NF jika dan hanya jika setiap dependensi
gabungan dalam R tersirat oleh kunci kandidat relasi R. Secara praktis dapat
dikatakan bahwa suatu relasi R berada dalam 5NF jika data yang ada padanya
tak dapat lagi didekomposisi menjadi relasi-relasi yang lebih kecil dengan kunci
kandidat relasi-relasi yang lebih kecil ini tidak sama dengan kunci kandidat relasi.
Contoh relasi berikut berada dalam 5NF :


Daftar Pustaka

DAFTAR PUSTAKA
Elmasri & Navathe, “Fundamentals of Database Systems”, Addison-Wesley,
2004.
C. J. Date, “Pengenalan Sistem Basis Data jilid 1”, PT. Indeks Group Gramedia,
2004.

Dwi Puspitasari, S.Kom, Program Studi Manajemen Informatika xiii

Dasar basis data

More Related Content

What's hot

Viewers also liked

Similar to Dasar basis data

Dasar basis data