Basis Data

Perancangan Basis Data Buttom Up dengan Normalisasi

rahmadya Basis Data, Unisma

[basis.data|akuntansi|lab.software|per.15]

Dikenal dua pendekatan dalam merancang basis data yaitu top down dan buttom up. Top down biasanya dilakukan untuk sistem yang benar-benar baru, tidak pernah dilakukan transaksi sebelumnya walaupun secara manual. Atau jika ingin merombak sistem yang terdahulu yang tidak sesuai lagi dengan proses bisnis yang efisien. Sebagian besar e-commerce yang bermunculan saat ini (toko online maupun aplikasi taksi/ojek online) berbasis top down karena memang benar-benar baru.

Postingan ini khusus membahas metode buttom up yang lebih sederhana karena hanya mengkonversi transaksi manual menjadi terkomputerisasi juga online. Cara kerjanya menganalisa kebutuhan berdasarkan arsip-arsip manual yang ada misalnya nota penjualan, nota pembelian, dan laporan-laporan yang sebelumnya ada. Metode ini lebih sederhana dalam pengalihan sistem karena operator-operator tidak perlu belajar intensif karena proses yang ada tetap seperti sebelumnya, hanya mungkin perlu pelatihan penggunaan aplikasi sebagai pengganti sistem manual sebelumnya. Perhatikan sampel arsip nota penjualan di bawah ini. Bagaimana proses normalisasinya?

Ada beberapa jenis normalisasi tabel yaitu unnormalize (UNF), normal pertama (1NF), normal kedua (2NF), dan normal ketiga (3NF). Ada bentuk normal lainnya karena adanya konstrain terhadap relasi yang dimiliki misalnya Boyce-Code Normal Form (BCNF), normal keempat (4NF) dan kelima (5NF).

Unnormalize Form (UNF)

Bentuk normal ini gunanya untuk mendata calon-calon atribut suatu tabel. Adanya perulangan (redundancy) dan multivalue (satu field berisi lebih dari satu isian) diijinkan. Jadi contoh di atas bentuk UNF-nya adalah:

penjualan = no_nota + kode_kasir + nama_kasir + kode_customer + nama_customer + alamat + {kode + nama_barang + harga + jumlah} + total

Primary key diberi symbol “@”. Perhatikan adanya multivalue di atas yang diberi simbol “{ }”. Tugas berikutnya untuk normal pertama adalah membuat tabel tersebut dapat dibuat dalam satu tabel tanpa melanggar konsep basis data relational. Note: untuk basis data non-relational (berbasis objek) multivalue dapat diterapkan.

First Normal Form (1NF)

Penghilangan multivalue dapat dilakukan dengan cara membuat kunci komposit antara barang dengan penjualan. Kandidatnya adalah kode barang + no_nota sebagai primary key-nya.

Penjualan = @no_nota + @kode + kode_kasir + nama_kasir + kode_customer + nama_customer + alamat + nama_barang + harga + jumlah + total

Walaupun terdapat redundansi, misalnya no_nota yang sama tetapi karena primary key menggunakan gabungan no_nota dan kode barang maka selama gabungan keduanya unik, tidak melanggar prinsip primary key. Terkadang beberapa kunci kandidat bisa diidentifikasi untuk proses lebih lanjut, misalnya kode_customer dan kode_kasir.

Second Normal Form (2NF)

Untuk normal kedua, syarat mutlaknya selain 1NF adalah ketergantungan fungsional (functional dependency) antara satu atribut dengan atribut lainnya. Perhatikan bentuk 1NF sebelumnya, keluarkan (bentuk tabel baru) jika ada atribut yang tergantung dengan salah satu primary key (no_nota saja atau kode barang saja). Tercatat ada beberapa antara lain:

  1. nama_barang, harga dan jumlah tergantung kode
  2. kode_customer, nama_customer, alamat dan total, kode kasir dan nama kasir tergantung no_nota.

Nama, harga dan jumlah tergantung kode barang begitu juga yang terlibat transaksi penjualan (pelanggan dan kasir) tergantung nota penjualan. Karena kedua ketergantungan parsial di atas (partial dependency) hanya tergantung pada salah satu kunci komposit primary key, maka harus dihilangkan agar memenuhi syarat 2NF.

  1. barang = @kode + nama_barang + harga
  2. penjualan =@no_nota + kode_kasir + nama_kasir + kode_customer + nama_customer + alamat + total
  3. detilpenjualan = @no_nota + @kode + jumlah

Perhatikan tidak ada atribut yang tergantung secara parsial.

Third Normal Form (3NF)

Bentuk 2NF jika masih terdapat ketergantungan secara transitif antara satu atribut dengan atribut lainnya harus dinormalkan agar bisa menjadi normal ketiga. Perhatikan tabel penjualan yang memiliki beberapa atribut non-key ternyata antara satu atribut tergantung dengan atribut lainnya:

  1. nama_kasir tergantung kode_kasir
  2. nama_customer dan alamat tergantung kode_customer

Oleh karena itu perlu dibuat dua tabel baru. Tabel penjualan hanya menyertakan kunci tamu (foreign key) saja dengan simbol “#” di depannya.

  1. kasir = @kode_kasir + nama_kasir
  2. Pelanggan = @kode_customer + nama_customer + alamat
  3. barang = @kode + nama_barang + harga
  4. penjualan =@no_nota + #kode_kasir + #kode_customer + total
  5. detilpenjualan = @no_nota + @kode + jumlah

Jika tidak ada lagi ketergantungan transitif pada tiap-tiap atribut non-key maka proses normalisasi ketiga telah selesai. Biasanya sampai 3NF saja jika tidak ada konstrain/batasan-batasan ketat atribut tertentu, misalnya harga barang yang tergantung dari pelanggan tertentu, dan lain-lain. Semoga ujian akhir nanti lancar.

Iklan

Persamaan Persepsi Dosen

rahmadya Basis Data, Puisi Kehidupan

Selain mendengar dari orang lain, saya mengalami sendiri konflik yang terjadi antara satu dosen (bahkan satu grup dosen) dengan yang lain. Korbannya sudah dipastikan mahasiswa, khususnya ketika menyelesaikan tahap akhir penyelesaian skripsi/tugas akhir mereka. Biasanya terjadi karena ego antar dosen selain tentu saja beda pemahaman terhadap suatu konsep dan aturan-aturan yang memang ada hak independen dari sisi pengajar dalam berfikir ilmiah. Untuk masalah ego memang sedikit rumit, apalagi ada unsur-unsur konflik pribadi antar dosen. Postingan ini sedikit menggambarkan kondisi ini dari pengalaman pribadi.

Persamaan Persepsi

Untuk bidang tertentu yang skripsinya mirip-mirip antara satu sama lain dengan metode-metode yang sudah baku, sebuah pertemuan yang mengundang para dosen sangat penting. Manfaatnya untuk membuat standar yang baku dan adil terhadap mahasiswa. Misalnya topik-topik apa saja yang masuk wilayah domain jurusan dengan bentuk laporan skripsinya. Hal ini agar tidak membuat siswa bingung karena oleh satu dosen di suruh begitu, oleh dosen pembimbing yg lain disalahkan, kan kasihan. Juga dengan pertemuan itu, diharapkan kemampuan pembimbing bisa bertambah, minimal tidak jomplang satu dengan lainnya, apalagi jika disertakan dengan pelatihan/seminar oleh dosen yang dianggap pakar di bidangnya. Atau bisa mengundang pakar dari institusi lain.

Standar Tingkat Kesulitan

Sudah pasti tingkat kesulitan antara mahasiswa D3, S1, S2 dan Doktoral berbeda. Repotnya beberapa dosen guna mengejar publikasi menyamakan level D3, S1 dan S2 terhadap mahasiswanya. Melihat mahasiswa D3 yang diminta menganalisa antara satu metode dengan metode lainnya oleh dosen pembimbing kasihan juga. Walaupun ada baiknya tetapi tidak sesuai dengan tujuan D3 yang memang ketika bekerja hanya diminta menyelesaikan pekerjaan dengan metode tertentu yang diperintahkan oleh atasannya, harus selesai dengan baik dan cepat. Jika ngotot dan protes kalau metodenya kalah dengan yang lain bakal dipecat nanti. Jadi fokus ke skill pada level vokasi diutamakan. Level S1 pun berbeda dengan S2 yang mencoba ada aspek analisa satu metode dengan lainnya. Bukan hanya apa yang harus dilakukan tetapi juga mengapa suatu konsep diperlukan dan lebih baik dari konsep dan metode lainnya. Untuk mahasiswa doktoral terlepas dari pertanyaan apa, mengapa dan bagaimana, aspek kebaruan sangat mutlak, walau pun sederhana/kecil. Silahkan membimbing mahasiswa doktoral jika ingin publikasinya banyak dan jangan memaksa mahasiswa S1 apalagi D3 untuk bisa mempublikasi di jurnal internasional yang memang dituntut state of the art.

Standar Internasional

Terkadang walaupun sudah ada persamaan persepsi antara satu dosen dengan lainnya, ketika implementasi di lapangan, ada hal-hal tertentu berbeda pemahamannya karena memang topik yang luas yang tidak bisa selalu disamakan. Jika terjadai ada baiknya menggunakan dasar dan rujukan yang baik dan benar. Untungnya saat ini sebagian besar sudah ada standarnya, misal UML, ERD, dan lainnya. Jadi tidak elok jika memaksakan metode sendiri (tidak standar). Salah satu contoh kasus di bawah ini, tentang ERD.

ERD di atas merupakan standar dari Chen (1976) dan karena sekedar contoh, tidak semua atribut ditulis. Tetapi yang jelas ERD merupakan diagram konsep. Ada polemik mahasiswa yang menggambar diagram di atas disalahkan oleh pembimbing (biasanya praktisi/programmer) karena diagram di atas tidak bisa dijalankan di aplikasi. Tentu saja, karena itu masih konsep dan perlu konversi menjadi tabel, dan ada teorinya (weak entity, many to many, dan lainnya untuk dikonversi menjadi tabel). Silahkan menggunakan beragam standar/jenis model ERD lain (crow foot) atau dengan class diagram UML berstandar internasional. Baik perancang sistem maupun programmer harus bisa bekerja sama bukan malah mengagung2kan bidangnya apalagi menjelek-jelekan bidang lain. Mungkin itu sekadar contoh, semoga bisa menjadi bahan evaluasi bersama.

Insert Data Multitable dengan PHP

rahmadya Basis Data

[s.basis.data|akuntansi|lab.soft|per.14]

Pertemuan ini mencoba membuat aplikasi berbasis web dengan PHP untuk memasukan data baru ke basis data. Sebagai informasi, semua file-file PHP diletakan di folder ..\xampp\htdocs\ sementara basis data diletakan pada folder ..\xampp\mysql\data.

Insert Data yang Melibatkan Satu Tabel

Postingan ini menggunakan data pertemuan yang lalu. Misalnya input data barang dengan form berupa tabel yang dibuat dengan mode HTML. Struktur dari file PHP nya dapat digambarkan sebagai berikut.

  • <Judul Form>
  • <Metode Form: POST, Action: simpan.php>
  • <Interface untuk Input-input Data>
  • <Interface Untuk Tombol Submit>

Struktur php di atas (misal diberi nama formbarang.php) membutuhkan file simpan.php untuk mengeksekusi isian yang telah diisi. Struktur simpan.php adalah kira-kira sebagai berikut:

  • <Membuat koneksi>
  • <Membuat variabel $ untuk tiap input data dari formbarang.php>
  • <Membuat SQL insert data dengan VALUE dari variabel tersebut>
  • <Eksekusi SQL dan tutup koneksi>

Koneksi bisa dibuat di file simpan.php atau membuat satu file php khusus untuk koneksi. Untuk PHP 7 instruksi mysql diganti menjadi mysqli yang membutuhkan link koneksi tiap eksekusi. Silahkan browsing kode detail dari file php tersebut yang banyak tersebar di internet. Berikut contoh hasil eksekusinya.

Pastikan ketika tombol SIMPAN ditekan pada tabel barang data baru muncul. Berikutnya untuk form yang melibatkan dua tabel.

Insert Data yang Melibatkan 2 Tabel

Sebagai contoh adalah tabel pembelian yang melibatkan tabel pembelian dan tabel pemasok (suplier). Karena pelanggan harus sesuai dengan tabel. Kode suplier pada tabel pemasok merupakan kunci tamu (Foreign Key) di tabel pembelian. Struktur file pembelian.php adalah sebagai berikut:

  • <Judul Form>
  • <Membuat Koneksi>
  • <Membuat Form Methode :POST, Action: simpanbeli.php>
  • <Membuat SQL mengambil data suplier>
  • <Menyiapkan Array Javascript utk menampung hasil>
  • <Membuat pilihan dari data suplier>
  • <Menyimpan variabel $ array hasil pilihan>
  • <Interface input data>
  • <Interface submit / insert data>
  • <Fungsi Javascript mengisi input data berdasarkan $ array>

Form ini mirip sebelumnya tetapi sedikit rumit karena perlu menyiapkan data suplier sebagai pilihan dalam bentuk combo box. Ketika satu suplier dipilih, maka data lainnya seperti Nama, Alamat, dan Kontak muncul di interface input data. Untuk total diisi manual, biasanya total ini diinput otomatis dari form transaksi yang lebih detil (melibatkan data barang lebih dari satu). Karena sekedar contoh bagaimana menginput data yang melibatkan dua tabel, kiranya cukup sekedar demo. File simpanbeli.php diperlukan untuk menyimpan data pembelian. Berikut strukturnya:

  • <Membuat koneksi>
  • <Membuat variabel $ untuk tiap input data dari pembelian.php>
  • <Membuat SQL insert data dengan VALUE dari variabel tersebut>
  • <Eksekusi SQL dan tutup koneksi>

Kode untuk tombol simpan mirip simpan data barang sebelumnya. Tinggal copas dan ganti variabel dengan variabel $ baru mengikuti nama dari input data di file php sebelumnya yang memanggil (pembelian.php). Testing apakah sudah berjalan dengan baik.

Untuk detil yang melibatkan pembelian lebih dari satu barang sehingga membutuhkan isian dinamis (muncul isian baru ketika ada penambahan) perlu dicoba, juga pembuatan aplikasinya pada android. Semoga bermanfaat.

Migrasi ke PHP versi 7 itu Wajib

rahmadya Basis Data, Komputer dan Masyarakat

Semester ini teknik kompilasi, information retrieval, algoritma, pengolahan citra dan basis data menjadi santapan sehari-hari (karena mengajar). Teknik kompilasi membahas teknik-teknik parsing suatu bahasa pemrograman. Ada informasi bahwa PHP versi 5 ke bawah sangat rentan dan mudah dimanipulasi parsing-nya. Dan yang terpenting PHP 5 akan dihentikan dukungannya per 31 Desember 2018 nanti. PHP sendiri saya gunakan sebagai praktek dalam mata kuliah sistem basis data. Berikut edaran dari Badan Siber dan Sandi Negara (BSSN) mengenai hal tersebut.

Yuk, Install Versi 7.x

Silahkan unduh PHP versi terbaru di SINI. Pada postingan ini saya mencoba menggunakan versi terbaru itu. Coba pilih versi 7.3 yang terbaru ketika postingan ini ditulis.

Ukuran XAMPP untuk PHP 7.3 ini cukup kecil, hanya sekitar seratusan mega byte. Isi dari XAMPP dapat dilihat saat proses instalasi. Oiya, gunakan login Administrator agar instalasi optimal, karena ada pesan / warning ketika tidak menggunakan login itu.

Intal XAMPP ini satu paket dalam Bitnamiyang mensuport paket Drupal, Joomla, Moodle dan WordPress. Lanjutakan dengan menekan Next> hingga proses instalasi selesai.

Testing XAMPP yang Baru

Dimulai dengan pemilihan bahasa, control panel XAMPP muncul ketika aplikasi pertama kali dijalankan. Hidupkan server database dan PHP untuk memulai aplikasi (wah .. ada Tomcat .. jadi trauma waktu S2 dulu). Seperti biasa windows minta konfirmasi apakah kedua server itu dihidupkan, tekan saja OK.

Coba saya migrasi beberapa file terdahulu (php dan mysql) untuk testing. Misalnya input data barang.

Ternyata tampilan XAMPP jika dijalankan localhost langsung menuju dashboard yang menginformasikan tentang versi 7.3 dari PHP ini.

Tampak berhasil insert satu data baru. Silahkan migrasi ke PHP versi 7 agar tenang dan nyaman, khususnya bagi admin web (sementara mungkin, karena serangan terus terjadi mencari kelemahan-kelemahan yang mungkin ada). Semoga bermanfaat.

Ketika acara FGD (dua dari kanan)

Membuat Relasi Antar Tabel Pada MySQL

rahmadya Basis Data

[basis.data|akuntansi|lab.software|pert.13]

Pada pertemuan sebelumnya dibuat satu tabel (tabel barang) dengan MySQL yang dihubungkan dengan form berbasis web (php). Tentu saja setiap basis data akan memiliki lebih dari satu tabel, misalnya tabel yang lain seperti detilpenjualan, penjualan, atau juga suplier. Untuk mudahnya kita buat satu tabel baru yakni tabel detilpenjualan yang terhubung dengan tabel barang. Relasinya kira-kira sebagai berikut:

Membuat Tabel Suplier

Ada dua tabel master yaitu tabel barang dan tabel Suplier. Buat tabel suplier dengan script SQL berikut ini:

  • CREATE TABLE SUPLIER (
  • KdSuplier CHAR(10) NOT NULL,
  • NamaSuplier VARCHAR(20) NOT NULL,
  • Alamat VARCHAR(25) NOT NULL,
  • Kontak CHAR(10),
  • PRIMARY KEY (KdSuplier)
  • );

Jalankan dengan mengklik simbol SQL pada phpmyadmin (http://localhost/phpmyadmin/). Atau bisa juga dengan create lewat menu di phpmyadmin. Masukan satu buah record, misalnya:

  • INSERT INTO SUPLIER (KdSuplier, NamaSuplier, Alamat, Kontak) VALUES
  • (‘S001′,’Rahmadya’,’Bekasi’,’3332211′),
  • (‘S002′,’Ujang’,’Jakarta’,’123456′);

Pastikan kode SQL ketika dijalankan berhasil.

Membuat Tabel Penjualan

Tabel penjualan membutuhkan field-field: KdPenjualan, KdSuplier, dan Total. Sehingga memerlukan Foreign Key KdSuplier yang berasal dari tabel Suplier. Berikut kode SQL-nya:

  • CREATE TABLE PENJUALAN (
  • KdPenjualan INT AUTO_INCREMENT NOT NULL,
  • KdSuplier CHAR(10) NOT NULL,
  • total DECIMAL(8,2) NOT NULL,
  • PRIMARY KEY (KdPenjualan),
  • FOREIGN KEY (KdSuplier) REFERENCES suplier(KdSuplier)
  • ON DELETE CASCADE
  • ON UPDATE CASCADE
  • );

Perhatikan frasa on delete cascade dan on update cascade pada foreign key KdSuplier. Di sini artinya jika kode suplier dihapus atau diedit maka tabel penjualan juga berubah. Tapi jika ingin tidak berubah tidak perlu memasukan frasa tersebut.

Membuat Tabel DetilPenjualan

Tabel ini bermaksud mengakomodir relasi many to many dimana transaksi melibatkan jumlah barang yang lebih dari satu. KdPenjualan dan KdBarang menjadi primary key (komposit). Berikut kode SQL untuk tabel barang dan tabel DetilPenjualan.

  • CREATE TABLE BARANG(
  • KdBarang VARCHAR(10),
  • NamaBarang VARCHAR(25),
  • Harga decimal,
  • PRIMARY KEY (KdBarang)
  • );

Dan untuk tabel DetilPenjualan:

  • CREATE TABLE DETILPENJUALAN (
  • KdPenjualan INT AUTO_INCREMENT NOT NULL,
  • KdBarang CHAR(10) NOT NULL,
  • FOREIGN KEY (KdBarang) REFERENCES barang (KdBarang),
  • PRIMARY KEY (KdPenjualan,KdBarang)
  • );

Perhatikan kode di atas dimana PRIMARY KEY ada dua yaitu KdPenjualan dan KdBarang. Silahkan tambahkan ON DELETE CASCADE atau ON UPDATE CASCADE. Selamat mencoba.

Normalisasi File

rahmadya Basis Data

[basis.data|akuntansi|lab.software|pert.12]

Basis data secara fisik dibuat dalam bentuk tabel-tabel. Tabel tersebut berasal dari analisis baik lewat Entity Relationship Diagram (ERD) maupun Diagram Alir Data (DAD). Beberapa kampus menerapkan ERD yang merupakan perancangan basis data secara konseptual dilanjutkan dengan mengkonversi ERD menjadi struktur penyimpanan logika (logical structured record). Caranya dengan menggunakan prosedur sebagai berikut:

  • Konversi multivalued menjadi satu tabel tambahan (tabel detail) dari relasi Many-to-Many
  • Konversi entity komposit menjadi tabel lookup baru
  • Konversi entitas lemah (weak entity) menjadi satu tabel baru

Sementara itu yang menggunakan DFD harus menjabarkan tabel yang ada setelah itu dilakukan proses normalisasi untuk menghindari anomali-anomali yang terjadi (insert, update, dan delete). Tetapi ERD pun tetap sebaiknya melakukan proses normalisasi file untuk memperkokoh hasil rancangan.

Format Normalisasi

Ada beragam format penulisan normalisasi file. Salah satu format yang cukup baik adalah format yang ditawarkan oleh Elmasri dkk dengan menggunakan bagai yang berisi judul tabel dan atribut-atributnya. Untuk atribut kunci ditandai dengan menggunakan garis bawah. Simbol panah menunjukan Functional Dependency (FD).

Beberapa kampus menggunakan format tabel seperti class diagram tanpa operation/method dengan nama tabel serta atributnya menyusun ke bawah. Foreign key akan mengarah panahnya ke relasi tabel yang dimaksud. Jika primary key ditandai dengan satu *, foreign key ditandai dengan **.

Kedua cara di atas memiliki kesulitan dalam penggambarannya (dengan visio ataupun insert shape pada MS Word). Namun ada cara lain yang tanpa bagan yaitu dengan menggunakan teks langsung. Formatnya adalah:

  • <nama_tabel> = @<primary_key> + <field_1> + <field_2> + … atau:
  • <nama_tabel>(<primary_key>,<field_1>,<field_2>, …)

Dari sisi pengetikan sepertinya lebih mudah walaupun butuh penjelasan dengan kata-kata untuk foreign key-nya. Berikut adalah contohnya.

Contoh Normalisasi

Dikenal biasanya ada tiga bentuk normalisasi unnormalized, 1st Normal Form, 2nd Normal Form, dan 3rd Normal Form. Ada BCNF dan Normal kelima tetapi sangat jarang dijumpai di lapangan. Misalkan ada bentuk di bawah ini, yaitu suatu struk transaksi penjualan. Bagaimana normalisasinya?

Unnormalized Form

Unnormalized Form (UNF) paling mudah membuatnya karena hanya mendata field-field yang ada saja. Untuk yang berulang/multi-valued dengan mengisi tanda kurung kurawal saja (bagian detil). Jadi UNF transaksi di atas kira-kira sebagai berikut:

  • Penjualan = KdPenjualan + KdPelanggan + namaPelanggan + Alamat + Kontak + Total + {KdBarang + nama +harga + Jumlah}

    Atau:

  • Penjualan (KdPenjualan, KdPelanggan, namaPelanggan, Alamat, Kontak, Total, {KdBarang, nama, harga, Jumlah})

Tentu saja untuk implementasi, UNF tidak bisa dibuat tabel, kecuali DBMS khusus berbasis object (atau XML).

First Normal Form

Bentuk 1st Normal Form (1NF) memiliki ciri tidak adanya redundansi dan multi-value. Dalam 1NF tidak ada field yang merupakan hasil kalkulasi (Calculated Field) yang tidak disimpan di basis data. Selain itu Candidate Key diperkenalkan di sini. Kunci kandidat diperoleh dengan meliha ketergantungan fungsional antara satu field dengan field lainnya, misalnya namaPelanggan, Alamat, dan Kontak dengan KdPelanggan dipilih KdPelanggan sebagai kunci kandidat.

Karena fokus 1st NF adalah menghilangkan multi-valued field (juga nested relation) maka kunci komposit dibentuk gabungan KdPenjualan dan KdBarang sehingga tidak ada multi-value pada barang yang dijual. Tabel penjualan di bawah ini sudah cukup menghindari multi-value pada suatu field.

  • Penjualan (KdPenjualan, KdBarang, nama, harga, Total, KdPelanggan, namaPelanggan, Alamat, Kontak)

Di sini Jumlah dihilangkan karena merupakan hasil kalkulasi dan tidak diinput ke basis data, sementara Total walaupun hasil kalkulasi tetapi tersimpan di basis data.

“Relation should have no multivalued attributes or nested relations.”

Second Normal Form

Bentuk normal kedua (2NF) mengharuskan dalam satu tabel memiliki ketergantungan fungsional secara penuh (Fully Functional Dependency). Dengan kata lain pada bentuk 2NF tidak diperbolehkan satu field secara fungsional bergantung pada salah satu kunci komposit. Dalam contoh ini: nama dan harga barang bergantung ke KdBarang dan tidak ke KdPenjualan, Total ke KdPenjualan tapi tidak ke KdBarang. Oleh karena itu perlu dibentuk tabel baru untuk mengakomodir hal tersebut.

  • Penjualan = @KdPenjualan + KdPelanggan + namaPelanggan + Alamat + Kontak + Total
  • DetilPenjualan = @KdPenjualan + @KdBarang
  • Barang = @KdBarang + nama + harga

Perhatikan di sini tidak ada atribut (di tabel Penjualan) yang bergantung ke salah satu kunci komposit (terhadap KdPenjualan saja atau KdBarang saja).

“For relations where primary key contains multiple attributes, no nonkey attribute should be functionally dependent on a part of the primary key.”

Third Normal Form

Biasanya transaksi sampai di normal ketiga yang mensyaratkan tidak boleh ada transitive dependency dimana satu field non-key bergantung dengan yang lain. Contohnya adalah namaPelanggan (juga alamat dan kontak) yang ternyata bergantung dengan KdPelanggan. Untuk mengingatnya, istilah “transitive” berasal dari kata transfer, yakni mentransfer dari primary key (KdPenjualan) ke namaPelanggan, Alamat, dan Kontak lewat KdPelanggan.

  • Pelanggan (KdPelanggan, namaPelanggan, Alamat, Kontak)
  • Penjualan (KdPenjualan, KdPelanggan, Total)
  • DetilPenjualan (KdPenjualan, KdBarang)
  • Barang (KdBarang, nama, harga)

Tampak seluruh field/atribut bergantung ke kunci masing-masing tabel. Aturan untuk 3NF adalah:

“Relation should not have a nonkey attribute functionally determined by another nonkey attribute (or by a set of nonkey attributes). That is, there should be no transitive dependency of a non-key attribute on the primary key.”

Sekian, semoga bermanfaat.

Reference:

Elmasri, R & Navathe. “Fundamentals of Database”. USA: Pearson. 2004

Membuat Report dengan MS Access

rahmadya Basis Data

[basis.data|akuntansi|lab.software|pert.11]

Sambil membahas masalah normalisasi file, praktek basis data kali ini adalah membuat report pembelian dan penjualan. Sebagai informasi, pada pertemuan sebelumnya sudah dibahas pembuatan form pembelian yang melibatkan suplier, barang, dan detil pembelian. Atau lebih jelasnya dapat dilihat relasi antar tabel di bawah ini.

Mempersiapkan Report

Untuk membuat report baru tekan menu CREATE – Report Wizard. Di sini menggunakan wizard agar lebih cepat dan mudah. Nanti jika akan dirubah, tinggal menekan Dezign View saja. Berikutnya masukan field-field yang akan muncul di report. Sebenarnya pilih saja sebanyak mungkin yang kira-kira dibutuhkan. Toh jika tidak dibutuhkan bisa dihapus dari report nantinya.

Di sini akan coba ditambahkan field-field pada tabel pembelian. Pastikan format sesuai dengan yang diinginkan sebagai berikut.

Lanjutkan dengan menekan Next> hingga report terbentuk. Berikutnya adalah menambahkan Total Pengeluaran terhadap seluruh pembelian yang telah dilakukan.

Membuat Total Pengeluaran

Sebelumnya masuk ke menu Report Design dengan mengklik kanan Report Penjualan dan memilih Design View.

Tambahkan satu Text Box untuk menampilkan total pengeluaran. Ganti teks dengan “Total Pengeluaran” setelah melebarkan bagian footer dengan mouse. Tekan bagian paling kanan Control Source pada property Data.

Masukan fungsi yang diperlukan, di sini menggunakan Sum yang artinya menjumlahkan suatu field (dalam hal ini Field Total). Tekan Ok untuk menguji report yang baru saja dibuat. Tampak total pengeluaran yang merupakan penjumlahan dari seluruh transaksi yang ada. Semoga bermanfaat, selamat mencoba.

NOTE: Di sini harga hanya contoh, tentu saja harga jual harus dibedakan dengan harga beli agar diperoleh keuntungan.