BASIS DATA RELATIONAL

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:

22 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 Mpt-03 Merpati Air Bus 350

23 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 H003 H004 H005 No_seat SE-01 SE-02 EC-10

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.

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.

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

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.

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 00310004 Sistem Basisdata Butet B 00310001 Komunikasi Data Tony 00310002 Komunikasi Data Jack 00310004 Komunikasi Data Butet 00310001 Sistem Operasi Tony B 00310002 Visual Basic Jack C 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.

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 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 003102 butet juni mi0107

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 Tabel kelas Nim kelas kelas 003101 mi0101 mi0101 003101 mi0102 mi0102 003102 mi0101 mi0104 003102 mi0104 mi0107 003102 mi0107 mi0108

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 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 A02 AC1PK 10 2000000 20000000

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.

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

34 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. Dari permasalahan diatas maka table nota harus di normalkan kembali.

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 Table Nota Tabel Barang Kode barang Nama barang No factur Tanggal factur Tgl jatu tempo Total Kode supplier Table Detail Transaksi No factur Kode Table barang 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.

36 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 : supplier Barang Nota Transaksi