BASIS DATA RELATIONAL

Buku Ajar Sistem Basis Data

Halaman

21

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:

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


Halaman

Haji

Jadual

Pesawat

No_haji

No_haji

No_pnb

Nm_chj

No_pnb

Nm_pswt

Asal

Tgl_brkt

Jns_pswt

Alamat

Hari

Kapasitas

Tgl_lahir

Jam

J-kel

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

Mpt-03

Merpati

Air Bus

350


22


Halaman

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


23


Halaman

24

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.



Halaman

25

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. By : Sonny Leston Hutabarat, Ir. / Cc:.2004 / Program Hibah A1-2004


Halaman

26

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

-

Nama+tpt_lahir+tgl_lahir : bias dijadikan sebagai key



•

Halaman

27

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.



Halaman

28

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. Nim

Nm_MK

Nm_Mhs

Nilai

00310001

Sistem Basisdata

Tony

A

Record 1

00310004

Sistem Basisdata

Butet

B

Record 2

00310001

Komunikasi Data

Tony

Record 3

00310002

Komunikasi Data

Jack

Record 4

00310004

Komunikasi Data

Butet

Record 5

00310001

Sistem Operasi

Tony

B

Record 6

00310002

Visual Basic

Jack

C

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.



Halaman

29

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

003101

januar

sony

mi0101

mi0102

003102

butet

juni

mi0101

mi0104

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

003102

butet

juni

mi0107


kelas3 mi0107


Halaman

30

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 Nim

Tabel kelas

kelas

kelas

003101

mi0101

mi0101

003101

mi0102

mi0102

003102

mi0101

mi0104

003102

mi0104

mi0107

003102

mi0107

mi0108



Halaman

31

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

AC SPLIT ½ PK

10

1.350.000

13.500.000

A02

AC SPLIT 1 PK

10

2.000.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

779

S01

Hitachi

R02

RCook

02/02/03

10/09/03

10

998

G01

Gobel

A01

AC½PK

07/02/03

10/09/03

10

1350000

13500000

A02

AC1PK

10

2000000

20000000


harga

150000

jumllah

1500000

total

1500000 33500000


Halaman

32

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.



Halaman

33

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

Kode supplier Nama supplier

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

Keterangan: - key field = foreign key

Gambar relasional database normal kedua



Halaman

Tabel Supplier

34

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

779

02/02/03

10/09/03

998

07/02/03

998

07/02/03

Kdsup

Kdbrg

10

150.000

1.500.000

1.500.000

S01

R02

10/09/03

10

1.350.000

13.500.000

33.500.000

G01

A01

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.

Dari permasalahan diatas maka table nota harus di normalkan kembali.



Halaman

35

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 Kode supplier Nama supplier

Tabel Barang Table Nota

Kode barang Nama barang

No factur Tanggal factur Tgl jatu tempo Total Kode supplier

Table Detail Transaksi No factur Kode barang Table Transaksi Quantity Harga jumlah

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. By : Sonny Leston Hutabarat, Ir. / Cc:.2004 / Program Hibah A1-2004


Halaman

Table Supplier Kd_supp

Tabel Barang 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

Qty

Harga

Table Detail transaksi No_fac

Kd_brg

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 :

supplier

Barang

Nota

Transaksi


36

BASIS DATA RELATIONAL

Recommend Documents