BASIS DATA RELATIONAL

(1)

By : Sonny Leston Hutabarat, Ir. / Cc:.2004 / Program Hibah A1-2004

BASIS DATA RELATIONAL

Tujuan : agar mahasiswa mampu merancang sebuah model database relational dalam

merancang sebuah system informasi.

Bagaimana bentuk sebuah database yang relational ? Terdiri dari tabel-tabel yang terpisah Table dalam bentuk 2 dimensi Terdiri dari baris dan kolom

Baris menyatakan nilai dari satu record Kolom menyatakan field/atribut

Terjadinya hubungan antar file

Setiap table mempunyai key sebagai kunci relasi

Setiap key mewakili semua field yang ketergantungan kepadanya.

Contoh :

Dalam sebuah system informasi keberangkatan haji akan di informasikan kapan seorang calon haji akan berangkat dan menaiki nomor penerbangan berapa.

Informasi ini akan didapat dari relasi table haji, table pesawat dan table jadual keberangkatan. Sehingga dapat digambarkan relasi antar tabelnya sbb:

(2)

Haji Jadual Pesawat

No_haji Nm_chj Asal Alamat Tgl_lahir J-kel No_haji No_pnb Tgl_brkt Hari Jam No_pnb Nm_pswt Jns_pswt Kapasitas Table Haji

No_haji Nm_chj Asal Alamat Tgl_lahir J-kel

H001 Ali Medan Jl. Kaki 1 10-10-68 Lk H002 Siti Binjai Jl. Tulis 2 12-08-50 Pr H003 Imron Binjai Jl. Buku 07-08-65 Lk H004 Amad Medan Jl. Luku 27-01-70 Lk H005 Neni Tebing Jl. Duda 18-09-67 Pr H006 Joko Tebing Jl. Kikuk 21-09-50 Lk H007 Suminah Medan Jl. Kan 3 30-11-82 Pr

Table Pesawat

No_pnb Nm_pswt Jns_pswt Kapasitas

Grd-07 Garuda Air Bus 400

Grd-10 Garuda Boing 600

(3)

By : Sonny Leston Hutabarat, Ir. / Cc:.2004 / Program Hibah A1-2004 Table Jadual

No_pnb No_haji No_seat Tgl_brkt Hari Jam

Grd-07 H001 EC-01 10-10-2003 Jum’at 20.00 WIB Grd-07 H002 EX-05 10-10-2003 Rabu 20.00 WIB Grd-10 H003 SE-01 13-10-2003 Senin 21.15 WIB Grd-10 H004 SE-02 13-10-2003 Senin 22.15 WIB Grd-10 H005 EC-10 13-10-2003 Senin 21.15 WIB Mpt-03 H006 EX-06 19-10-2003 Minggu 20.50 WIB Mpt-03 H007 EX-07 19-10-2003 Minggu 23.50 WIB

Dari hasil relasi table diatas bisa diperoleh informasi sebagai berikut : Jadual Keberangkatan Calon Haji

Embarkasi Polonia Medan Nomor Penerbangan : Grd-10

Nama Pesawat : Garuda Tanggal Keberangkatan : 13-10-2003

Hari : Senin

Jam Berangkat : 21.15 wib

No_haji No_seat

H003 SE-01

H004 SE-02

H005 EC-10

(4)

By : Sonny Leston Hutabarat, Ir. / Cc:.2004 / Program Hibah A1-2004 Kenapa memakai basisdata relational ?

“ Basisdata relational merupakan basisdata yang paling baik dan banyak diterapkan diperusahaan-perusahaan atau instansi-instansi”

Bagaimana basisdata relational yang baik?

- mempunyai struktur basisdata yang lebih kompak (terdiri dari table-tabel yang saling berhubungan)

- mempunyai struktur dari masing-masing table yang lebih efisien dan sistematis - operasi basisdata yang lebih cepat (karena dlm perancangan basisdata ukuran

table diaharapkan semakin kecil. - Tingkat redundansi yang lebih kecil. - Dll.

(5)

Perancangan Database Model Konseptual

Tujuan : diharapkan mahasiswa dapat/mampu merancang database yang baik.

Merancang model konseptual databse

Perancangan sebuah database yang baik adalah merupakan tugas dari seorang Database Administrator. Dimana pada perancangan mengacu pada penyimpanan data dalam media penyimpan dan juga penekana pada struktur data dan relasi antar file.

Pendekatan yang dilakukan dalam perancangan model konseptual ini yaitu dengan menggunakan model data relational.

Ada 2 buah teknik yang digunakan dalam perancangan model konseptual yakni : - teknik normalisasi

- teknik entity-relationship

Teknik Normalisasi

Normalisasi merupakan proses pengelompokan data elemen menjadi table-tabel yang menunjukkan entity dan relasinya.

Normalisasi juga merupakan pemilah-milahan satu table menjadi beberapa table, dimana taabel yang dipilah tersebut saling berhubungan saatu dengan yang lainnya.

Alasan kenapa dilakukan normalisasi terhadap sebuah table : karena terjadinya kesulitan dalam uji terhadap proses penambahan/penyisipan, penghapusan dan peng-update-an data.

(6)

Jika masih terjadi kesulitan tersebut diatas maka harus dilakukan normalisasi kembali. Ada beberapa istilah yang harus dipahami terlebih dahulu sebelum membahas jauh tentang normalisasi, antara lain:

- field

- kebergantungan fungsi.

a. Field key (field kunci)

• Candidate key (kunci kandidat): adalah satu attribut atau set attribut yang mengidentifikasikan secara unik suatu kejadian spesifik dari entity.

Jika satu kunci kandidat terdapat lebih dari satu attribut, maka biasanya disebut sebagai composite key (kunci campuran).

Contoh :

File pegawai berisikan attribut : no_induk, no_ktp, nama, tpt_lahir, tgl_lahir, alamat, kota.

Candidate key disini yaitu :

- No_induk, no_ktp : karena unik dan tidak mungkin ganda.

- Nama : dapat juga dijadikan key tetapi masih ada kemungkinan namaya sama. - Nama+tgl_lahir : ada kemungkinan bisa dijadikan key

(7)

• Primary key (kunci primer) : adalah satu attribut atau satu set minimal attribut yang tidak hanya mengidentifikasi secara unik suatu kejadian spesifik, tetapi juga dapat mewakili setiap kejadian dari suatu entity.

Contoh :

No_induk dan no_ktp : dapat dijadikan sebagai primary key karena unik dan dapat mewakili satu entity pegawai.

• Alternate key (kunci alternatif) : merupakan kunci kandidat yang tidak dipakai sebagai kunci akses tetapi dipakai sebagai kunci pengurutan.

Contoh: Nama

• Foreign key (kunci tamu) : merupakan satu kunci (primary key) yang mewakili hubungan terhadap entity yang dituju.

Contoh : file gaji dengan attribut sbb: no_induk, no_bukti, tgl, gjktr, ptg, gjbrs.

No_induk : merupakan kunci tamu yang menghubungkan file pegawai dengan file gaji. No_bukti : merupakan kunci primer karena unik dan dapat mewakili entity.

No_induk+no_bukti : dapat dijadikan sebagai kunci kandidat dan kunci alternatif.

b. Kebergantungan fugsi (functional dependency)

Kebergantungan fungsi merupakan suatu hal yang harus diperhatikan dalam perancangan database yang baik. Diharapkan bahwa setiap attribut yang bukan key bergantung fugsi sepenuhnya pada attribut yang merupakan key nya.

(8)

Jika dalam proses normalisasi table masih dijumpai attribut yang bukan key bergantung fungsi kepada attribut yang bukan merupakan keynya, maka harus dilakukan normalisasi kembali.

Pada file pegawai dapat dilihat bahwa nama, tpt_lhr, tgl_lhr, alamat bergantung fungsi sepenuhnya pada no_induk. “artinya dengan mengetahui no_induk seorang pegawai sudah dapat dipastikan nama, tpt_lhr, tgl_lahir dari seorang pegwai”.

Notasi penulisan kebergantungan fungsi ditulis sbb: A Æ B

Artinya bahwa A secara fungsional menentukan B, atau B secara fungsional tergantung pada A. Record 1 Record 2 Record 3 Record 4 Record 5 Record 6 Record 7

Nim Æ nm_mhs, artinya attribut nm_mhs hanya bergantung pada nim. Hal ini bisa dilihat jika nim nya sama pasti nm_mhs nya juga sama.

Nm_mk + nim Æ nilai, artinya attribut nilai bergantung sepenuhnya terhadap nama mata kuliah dan nim atau dengan kata lain bahwa setiap mata kuliah dan nim tertentu pasti nilainya dapat ditentukan.

Nim Nm_MK Nm_Mhs Nilai

00310001 Sistem Basisdata Tony A 00310004 Sistem Basisdata Butet B 00310001 Komunikasi Data Tony

00310002 Komunikasi Data Jack 00310004 Komunikasi Data Butet

00310001 Sistem Operasi Tony B

(9)

Nim -/Æ nm_mk, artinya attribut nm_mk tidak bergantung pada nim. Hal ini dapat dibuktikan bahwa pada rec. 1 dan rec. 2 nilai dari nm_mk nya sama tapi nim nya berbeda.

Bentuk-bentuk normalisasi: - bentuk tidak normal - bentuk normal pertama - bentuk normal kedua - bentuk normal ketiga

Bentuk tidak normal, pada bentuk ini biasanya data yang direkam tidak megikuti suatu

format yang tertentu, bisa saja dat terduplikasi atau data tidak lengkap.

Bentuk Normal Pertama, pada bentuk ini data dibuat dalam table 2 dimensi dan tidak ada

attribut yang berniali ganda atau berulang ulang. Contoh:

Nim nm_siswa wali kelas1 kelas2 kelas3

003101 januar sony mi0101 mi0102

003102 butet juni mi0101 mi0104 mi0107

maka bentuk normal pertama dari table diatas adalah :

Nim nm_siswa wali kelas

003101 januar sony mi0101

003101 januar sony mi0102

003102 butet juni mi0101

003102 butet juni mi0104

(10)

Bentuk Normal Kedua, untuk membentuk normal kedua, table harus sudah dalam bentuk

normal pertama. Kemudian periksa apakah masih terjadi kesulitan dalam hal penambahan, penghapusan dan update data, dan juga

periksa apakah masih ada attribut yang bukan key masih bergantung fungsi terhadap attribut yang bukan key nya.

Jika masih terdapat kesulitan dan ada attribut yang bukan key masih bergantung fungsi terhadap key yang bukan key nya, maka harus dilakukan normalisasi data.

Untuk melakukan normalisasi kedua harus sudah ditentukan key field nya.

Dari contoh table sebelumnya bahwa nm_siswa dan wali, bergantung fungsi pada nim. Tapi kelas bukan merupakan fungsi dari table mahasiswa. Dengan demikian maka table dinormalisasi kembali. Sehingga menjadidua table sebagai berikut:

Table mahasiswa

Nim nm_mhs wali

003101 januar sony 013102 butet juni

Table transaksikelas Tabel kelas Nim kelas kelas 003101 mi0101 mi0101 003101 mi0102 mi0102 003102 mi0101 mi0104 003102 mi0104 mi0107 003102 mi0107 mi0108

(11)

Bentuk Normal Ketiga,untuk membentuk normal ketiga, maka table harus sudah dalam

bentuk normal kedua, dan semua attribut bukan key harus bergantung penuh pada attribut yang merupakan key nya.

Penerapan Bentuk Normalisasi

Perancangan database dengan model konseptual ini bisa dirancang dengan menggunakan dokumen dasar dari system yang dipakai. Sebagai contoh dari sebuah bon faktur pembelian barang berikut ini:

Faktur Pembelian Barang PT. CAKARA PERSADA

Jl. Beringin Jaya 21 Medan

Kode Supplier : G01 Tanggal : 07/02/90 Nama Supplier : Gobel Nusantara Nomor : 998

Kode Nama Barang Quantity Harga Jumlah A01 A02 AC SPLIT ½ PK AC SPLIT 1 PK 10 10 1.350.000 2.000.000 13.500.000 20.000.000 TOTAL FAKTUR 33.500.000 Jatuh Tempo Faktur :09/03/03

Bentuk Tidak Normal

No.fac kdsup nmsup kode nmbrg taglfac tgljtp qty harga jumllah total

779 S01 Hitachi R02 RCook 02/02/03 10/09/03 10 150000 1500000 1500000

998 G01 Gobel A01 AC½PK 07/02/03 10/09/03 10 1350000 13500000 33500000

(12)

Bentuk Normal Pertama

Bentuk normal pertama diperoleh dari bentuk tidak normal, yang dilakukan dengan cara melengkapi perulangan pengisian data pada table. Sehingga diperoleh sentuk table menjadi sbb:

Nofac kdsup nmsup kdbrg nmbrg tglfac tgljtp qty harga jumllah total 779 S01 Hitachi R02 RCook 02/02/03 10/09/03 10 150000 1500000 1500000 998 G01 Gobel A01 AC½PK 07/02/03 10/09/03 10 1350000 13500000 33500000 998 G01 Gobel A01 AC1PK 07/02/03 10/09/03 10 2000000 20000000 33500000

Jika table normal pertama dijadikan sebagai database maka perlu diperiksa apakah terjadi kesulitan dalam hal penyisipan, penghapusan ataupun peng update.

Disini dilihat terjadi kesulitan-kesulitan itu yaakni:

- kesulitan dalam hal penyisipan, dimana kita tidak bisa menambahkan supplier baru jika tidak dilakukan pembelian dari supplier tersebut.

- Kesulitan dalam hal penghapusan, dimana kita tidak bisa melakukan penghapusan bedasarkan salah satu field. Sebagai contoh jika dilakukan penghapusan berdasarkan no fac 779 maka akan menghapus supplier Hitachi dari database.

- Kesulitan dalam hal update, dimana jika dilakukan perubahan alamat terhadap satu supplier, harus merubah diseluruh record yang terdapat nama supplier tersebut.

(13)

Bentuk Normal Kedua

Untuk mendapatkan bentuk normal kedua, maka table harus sudah dalam bentuk normal pertama. Dan dalam hal ini harus sudah ditentukan mana saja field yang menjadi kunci (key).

Sebagai kandidat key dari table diperoleh sebanyak 3 kandidat key : - no factur

- kode supplier - kode barang

dari ketiga kunci kandidat dapaat dibentuk table yang mana field yang bukan key harus bergantung fungsi terhadap field yang merupakan key nya.

Table Supplier Table Barang

Table Nota

Keterangan:

- key field = foreign key

Gambar relasional database normal kedua

Kode supplier Nama supplier Kode barang Nama barang No factur Tanggal factur Tgl jatu tempo Quantity Harga Jumlah Total Kode supplier Kode barang

(14)

Tabel Supplier Tabel Barang

Kd_supp Nm_supp Kd_brg Nm_brg

G01 Gobel R02 RCOOK

S01 Hitachi A01 AC1/2PK

A02 AC1PK

Tabel Nota

Nofac Tglfac Tgljtp Qty Harga Jumlah Total Kdsup Kdbrg

779 02/02/03 10/09/03 10 150.000 1.500.000 1.500.000 S01 R02

998 07/02/03 10/09/03 10 1.350.000 13.500.000 33.500.000 G01 A01

998 07/02/03 10/09/03 10 2.000.000 20.000.000 33.500.000 G01 A02

Gambar table normal ke dua

Dari hasil normal kedua dapat dilihat bahwa tidak tejadi lagi kesulitan dalam hal penyisipan, penghapusan dan update. Hal ini dapat dilihat untuk menyisipkan satu supplier baru dapat dilakukan tanpa supplier tersebut harus melakukan transaksi pada table nota. Demikian juga untuk penghapusan dan penyisipan.

Tetapi dari table masih terlihat adanya permasalahan yaitu bahwa dalam table nota masih ada field yang bergantung fungsi kepada field yang bukan key nya, yaitu :

- field quantity tidak bergantung penuh pada key no factur.

- Masih terdapat redundansi data yaitu : setiap satu no factur yang tediri dari 5 jenis barang, maka 5 kali pula dituliskan no facturnya, tanggal factur, tanggal jatuh tempo dan total.

(15)

Bentuk normal ketiga.

Untuk membentuk normal ketiga, table harus sudah dalam bentuk normal kedua. Dan semua filed yang bukan keynya harus bergantung fungsi sepenuhnya pada field yang merupakan key nya.

Sehingga hasil dari normal ketiga diperoleh table berikut:

Table Supplier Tabel Barang

Table Nota

Table Detail Transaksi

Table Transaksi

Gambar relasional database normal ketiga Keterangan:

- Field garis bawah satu merupakan kunci primer - Field garis bawah dua merupakan kunci tamu

Dari hasil normal ketiga ini dapat dilihat bahwa tidak ada terjadi kesulitan peyisipan, penghapusan dan update. Dan juga terlihat bahwa setiap field yang bukan key sudah bergantung fungsi sepenuhnya terhadap field yang merupakan key nya. Dan redundansi yang terjadi pada tahap normal kedua sudah dapat di optimalkan.

Kode supplier

Nama supplier Kode barang Nama barang

No factur Tanggal factur Tgl jatu tempo Total Kode supplier No factur Kode barang Quantity Harga jumlah

(16)

Table Supplier Tabel Barang

Kd_supp Nm_supp Kd_brg Nm_brg

G01 Gobel R02 RCOOK

S01 Hitachi A01 AC1/2PK

A02 AC1PK

Table Nota

No_fac KD_supp Tgl_fac Tgl_jttempo Total

779 S01 02/02/03 10/09/03 1500000

998 G01 07/02/03 10/09/03 33500000

Table Detail transaksi

No_fac Kd_brg Qty Harga Jumlah

779 R02 10 150.000 1.500.000

998 A01 10 1.350.000 13.500.000

998 A02 10 2.000.000 20.000.000

Gambar table normal ke tiga

Dapat digambarkan bentuk relasi antar file nya sebagai berikut :