Rinipristiasari’s Weblog

STUDI KASUS TOKO ABC

No. Faktur :
Tanggal : Kepada :

No.	Nama	Jumlah	Harga	Total
			Total Bayar
			Diskon
			Jumlah Bayar

Petugas : …………………………..

 

Basis Data Belum Ternormaliasasi

Mendasar pada faktur yang tertera di atas, maka gambaran database yang belum ternormalisasi adalah sebagai berikut :

 

1. Tabel yang memiliki field dengan banyak data / tidak tunggal

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

No_Faktur	Tanggal	Nama_pelanggan	Daftar_Belanja
05070101	29/05/07	Pitoyo	Bedak, Beras, Minyak Tanah, Buku
05070102	29/05/07	Bowo	Baby Oil, Garam, Gula, Pensil
05070103	30/05/07	Erlina	Sikat gigi, Sabun, Odol, Sampo
06070001	01/06/07	Dayat	Beras

 

2. Tabel dengan field yang mengalami repeating groups

 

No_Faktur	Tanggal	Nama_pelanggan	Belanja1	Harga1	Belanja2	Harga2	Belanja3	Harga3	Belanja4	Harga4
05070101	29/05/07	Pitoyo	Bedak	1500	Beras	10000	Minyak Tanah	3500	Buku	2000
05070102	29/05/07	Bowo	Baby Oil	5600	Garam	2500	Gula	4000	Pensil	1500
05070103	30/05/07	Erlina	Sikat gigi	12000	Sabun	2500	Odol	13000	Sampo	16000
06070001	01/06/07	Dayat	Beras	25000

Walaupun susunan tabel data di atas belum menampilkan keseluruhan atribut dari bentuk faktur yang tertera pada soal ini, tetapi ia telah dapat menggambarkan bentuk basis data yang belum ternormalisasi, karena suatu relasi memenuhi 1-NF jika dan hanya jika setiap atribut hanya memiliki nilai tunggal dalam satu baris / record dan tidak mengalami repeating groups.

First Normal Form (1-NF)

Implementasi 1-NF dari table data yang belum ternormalisasi di atas adalah dengan cara mengeliminasi keberadaan repeating groups dan dekomposisi relasi menjadi dua atau lebih dengan syarat “tidak boleh ada informasi yang hilang karena proses dekomposisi”

Adapun caranya adalah :

1. Membuat 3 tabel yang memiliki fungsi sebagai berikut :

• TBFaktur, berfungsi untuk menyediakan atribut-atribut yang bersifat atomic dari tiap nomor faktur (ID_Faktur), seperti : Tanggal, Nama_Pelanggan, Total_Bayar, Diskon dan Nama_Petugas
• TBProduk, berfungsi untuk menyediakan atribut-atribut yang berulang atau tidak bernilai tunggal pada tiap nomor faktur (ID_Faktur), seperti : Nama_Barang dan harga
• TBTransaksiDetail, berfungsi sebagai penghubung antara nomor faktur (ID_Faktur) dengan kode barang (ID_Barang) agar proses dekomposisi tidak menyebabkan kerusakan informasi.

2. Menentukan type data dari tiap atribut dan membuat digram relasional sebagai berikut

3. Pada table TBTransaksiDetail terdapat atribut “Harga” yang berfungsi untuk menyimpan harga per transaksi, sedangkan atribut “Harga_Default” yang terdapat pada table TBProduk adalah atribut yang berfungsi untuk menyimpan harga barang terbaru dari tiap jenis barang. Hal ini berguna untuk mengantisipasi adanya perubahan harga barang dari waktu ke waktu.

4. Primary key yang digunakan pada TBTransaksiDetail adalah “ID_Transaksi”. Atribut kunci tersebut merupakan candidate key yang dibentuk dari superkey hasil penggabungan 2 atribut yaitu : ID_Faktur dan ID_Barang

 

 

Second Normal Form (2-NF)

Suatu relasi berada dalam 2^nd normal form jika dan hanya jika :

<–>Berada dalam bentuk first normal form (1-NF)

<–>Semua atribut bukan kunci memiliki dependensi sepenuhnya dengan kunci primer (Primary Key)

Jika ditelaah kembali relasi bentuk 1-NF yang telah dibuat sebelumnya, maka atribut bukan kunci pada table TBFaktur yang tidak memiliki dependensi sepenuhnya dengan primary key (ID_Faktur), yaitu : “Nama_Petugas”.

Oleh sebab itu dekomposisi relasi perlu dilakukan kembali dengan cara :

1. Mengeliminasi atribut “Nama_Petugas” dari table TBFaktur
2. Membuat tabel TBPetugas, menyediakan atribut-atribut yang terkait dengan identitas dan data pelanggan

Third Normal Form (3-NF)

Pada Second Normal Form (2-NF) atribut yang terkait dengan “Nama_Pelanggan” tidak didekomposisi dari table TBFaktur karena atribut tersebut masih memiliki dependensi fungsional dengan primary key (ID_Faktur) karena tiap nomor faktur akan berbeda untuk tiap pembeli/pelanggan.

Tetapi pada tahap 3-NF (Third Normal Form), atribut “Nama_Pelanggan” harus didekomposisi relasi karena pada tahap ini atribut bukan kunci tidak boleh ada yang berdependensi transitif dengan kunci primer.

Atribut “Nama_Pelanggan” dikatakan berdependensi transitif terhadap primary key (ID_Faktur) karena :

1. ID_Pelanggan à Nama_Pelanggan (Nama_Pelanggan berdependensi fungsional terhadap ID_Pelanggan)
2. ID_Faktur à ID_Pelanggan (ID_Pelanggan berdependensi fungsional terhadap ID_Faktur, karena tiap nomor faktur akan dikeluarkan untuk suatu ID_Pelanggan tertentu)
3. Sehingga dikatakan bahwa ID_Faktur memiliki dependensi transitif terhadap atribut Nama_Pelanggan

Berdasarkan analisa di atas maka diagram relational hasil penerapan Third Normal Form adalah sebagai berikut :

PENERAPAN BAHASA SQL PADA REPORT

SQL yang Digunakan Untuk Membuat Report “Faktur Pembelian Barang”

SELECT TBTransaksiDetail.ID_Faktur, TBFaktur.Tanggal, TBPelanggan.Nama_Pelanggan, TBProduk.Nama_Barang, TBTransaksiDetail.Jumlah, TBTransaksiDetail.Harga, ([Jumlah]*[Harga]) AS Total_perUnit, TBFaktur.Diskon, ([Diskon]*[Jumlah]*[Harga]) AS UangDisc, TBFaktur.Diskon, TBPetugas.Nama_Petugas

FROM TBProduk
INNER JOIN (TBPetugas
INNER JOIN (TBPelanggan
INNER JOIN (TBFaktur
INNER JOIN TBTransaksiDetail
ON TBFaktur.ID_Faktur = TBTransaksiDetail.ID_Faktur)
ON TBPelanggan.ID_Pelanggan = TBFaktur.ID_Pelanggan)
ON TBPetugas.ID_Petugas = TBFaktur.ID_Petugas)
ON TBProduk.ID_Barang = TBTransaksiDetail.ID_Barang;

keterangan :

Pada SQL diatas terdapat beberapa atribut baru yang dibuat yaitu :

–>Total_perUnit, digunakan untuk menghitung total dari sejumlah jenis barang yang dibeli (Rumus Total_perUnit : Jumlah * Harga)

–>UangDisc, digunakan untuk menghitung besarnya potongan harga dari tiap barang yang dibeli (Rumus UangDisc : Diskon * Jumlah * Harga)

Database
Database (Basis Data) adalah kumpulan data (elementer) yang secara logik berkaitan dalam mempresentasikan fenomena / fakta secara terstruktur dalam domain tertentu untuk mendukung aplikasi pada sistem tertentu. Basis data adalah kumpulan data yang saling berhubungan, memberikan refleksi fakta-fakta yang terdapat di organisasi. Basis data mendeskripsikan state organisasi/perusahaan/sistem. Saat satu kejadian muncul di dunia nyata mengubah state organisasi/perusahaan/sistem, maka satu perubahan pun harus dilakukan terhadap data yang disimpan di basis data. Basis data merupakan komponen utama sistem informasi karena semua informasi untuk pengambilan keputusan berasal dari data di basis data. Pengelolaan basis data yang buruk dapat mengakibatkan ketidaktersediaan data penting yang digunakan untuk menghasilkan informasi yang diperlukan dalam pengambilan keputusan.
Metodologi Perancangan Basis Data

Metodologi perancangan basis data adalah kumpulan teknik terorganisasi untuk pembuatan rancangan basis data. Teknik terorganisasi ini merupakan kumpulan tahap-tahapan yang memiliki aturan-aturan terurut. Teknik yang digunakan pada perancangan basis data dibagi menjadi dua, yaitu:

a. Perancangan basis data tingkat logik.

b. Perancangan basis data tingkat fisik.

Perancangan basis data secara logik dimulai dengan penciptaan model konseptual dari organisasi dan seluruhnya tak bergantung rincian implementasi seperti perangkat lunak DBMS, program aplikasi, bahasa pemrograman, platform perangkat keras, dan pertimbangan fisik lainnya. Model konsep ini kemudian dipetakan menjadi model data secara logik yang telah dipengaruhi model data target basis data seperti model relasional.

Dalam perancangan basis data secara logik, kita dapat melakukannya dengan cara :

a. Menerapkan Normalisasi terhadap struktur tabel yang telah diketahui.

b. Langsung membuat model Entity-Relationship (ER).
Model data secara logik merupakan sumber informasi perancangan fisik. Model ini menyediakan perancang suatu kendaraan untuk pertimbangan dalam merancang basis data yang efisien.

Perancangan basis data secara fisik adalah proses memproduksi deskripsi implementasi basis data pada penyimpanan sekunder, mendeskripsikan struktur-struktur penyimpanan dan metode-metode pengaksesan dalam meningkatkan efektifitas pengaksesan. Pada tahap ini, perancangan fisik telah ditujukan untuk system DBMS tertentu. Perancangan basis data tingkat fisik sudah dikaitkan dengan platform dan perangkat lunak system manajemen basis data dimana basis data diimplementasikan.

Langkah-langkah Metodologi Perancangan Basis Data

Berikut adalah perancangan basis data relasional :
- Dimulai dari perancangan basis data logik untuk basis data relasional pada tahap 1 sampai dengan tahap 3.
- Perancangan dan implementasi basis data fisik untuk basis data relasional pada tahap 4 sampai dengan tahap 7.

a. Tahap 1
Membangun rancangan data konseptual lokal berdasarkan pandangan pemakai. Yaitu mengidentifikasikan himpunan entitas – himpunan entitas. Mengidentifikasikan keterhubungan-keterhubungan (relationship), mengidentifikasikan dan asosiasikan atribut-atribut pada entitas atau keterhubungan, menentukan domain atribut, menentukan atribut-atribut candidate key dan primary key, melakukan spesialisasi/generalisasi, menggambarkan diagram ER, melakukan review model data konsep dengan pemakai.

b. Tahap 2
Membangun dan validasi model data logik lokal. Yaitu memetakan model data konsep ke model data logik, melakukan turunan relasi-relasi dari model data logik, validasi model menggunakan normalisasi, validasi model berdasarkan transaksi – transaksi pemakai, menggambarkan ER nya, mendefinisikan kontsrain-konstrain (batasan-batasan) integritas, melakukan review model data logik dengan pemakai.

c. Tahap 3
Membangun dan validasi model data logik global. Yaitu menggabungkan model data logik lokal menjadi model global, validasi model data logik global, periksa untuk pertumbuhan masa datang, menggambarkan diagram ER akhir, melakukan review model logik global dengan pemakai.

d. Tahap 4
Menerjemahkan model data logik global untuk DBMS target. Yaitu merancang relasi-relasi basis untuk DBMS target, merancang aturan-aturan integritas untuk DBMS target.

e. Tahap 5
Merancang dan implementasi representasi fisik. Yaitu menganalisa transaksi-transaksi, memilih organisasi file, memilih indeks-indeks sekunder, mempertimbangkan penambahan redudansi yang terkendali, estimasikan ruang disk yang diperlukan.

f. Tahap 6
Merancang dan mengimplementasikan mekanisme pengamanan. Yaitu merancang view-view pemakai, merancang aturan-aturan pengaksesan.

g. Tahap 7
Memonitor dan menyesuaikan system yang sedang operasi.

http://www.globalkomputer.com/Bahasan/Database

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!