Study Kasus Perancangan Database

Perancangan Database Sistem Informasi Inventaris
Posted on May 23, 2008 by citrakurniawan

A. Permasalahan:
Suatu perusahaan software diminta membuatkan basis data yang akan menangani data-data inventaris sebuah toko kecil. Karena tokonya kecil, maka ada beberapa gudang yang khusus untuk menyimpan stock produk. Data-data yang akan ditanganinya adalah: data produk yang ditawarkan toko, data pemasok produk, data transaksi pembelian produk dari pemasok (nota pembelian), dan data gudang tempat penyimpanan produk. Satu produk yang sama bisa disimpan di beberapa gudang yang berbeda, dan tentu saja tiap gudang menyimpan berbagai macam produk. Di database harus ada data mengenai sisa stock yang ada di masing-masing gudang untuk semua produk.

B. Tahap 1: Penentuan Entities

• produk: menyimpan semua informasi mengenai semua produk yang ditawarkan
• pemasok: menyimpan semua informasi mengenai semua pemasok
• nota_pembelian: menyimpan semua informasi mengenai semua transaksi pembelian produk dari pemasok
• gudang: menyimpan semua informasi mengenai gudang untuk penyimpanan produk

C. Tahap 2: Penentuan Attributes
• produk:
• kode_produk: kode unik untuk tiap macam produk (string) PK
• nama_produk: nama lengkap untuk produk (string)
• harga_jual: harga jual produk di toko (integer)
• pemasok:
• kode_pemasok: kode unik untuk tiap pemasok (string) PK
• nama_pemasok: nama lengkap untuk pemasok (string)
• alamat_pemasok: alamat lengkap untuk pemasok (string)
• nota_pembelian:
• no_nota: kode untuk mata kuliah (integer) PK
• tanggal: tanggal transaksi dilakukan (date)
• gudang:
• kode_gudang: kode untuk ruang kelas (string) PK
• alamat_gudang: alamat lengkap untuk gudang (string)

D. Tahap 3: Penentuan Relationships

Hubungan:
• produk disimpan di gudang:
• Tabel utama: produk, gudang
• Tabel kedua: stok_produk
• Relationship: Many-to-many (m:n)
• Attribute penghubung: kode_produk, kode_gudang (FK kode_produk, kode_gudang di stok_produk)
• produk tercatat di nota_pembelian:
• Tabel utama: produk, nota_pembelian
• Tabel kedua: rincian_nota_pembelian
• Relationship: Many-to-many (m:n)
• Attribute penghubung: kode_produk, no_nota (FK kode_produk, no_nota di rincian_nota_pembelian)
• pemasok tercatat di nota_pembelian:
• Tabel utama: pemasok
• Tabel kedua: nota_pembelian
• Relationship: One-to-many (1:n)
• Attribute penghubung: kode_pemasok (FK kode_pemasok di nota_pembelian)

E. Tahap 4: Pembuatan ERD
EER (Enhanced Entity Relationship) Diagram:

F. Tahap Implementasi

CREATE TABLE produk (
kode_produk varchar(20) PRIMARY KEY,
nama_produk varchar(45) UNIQUE,
harga_jual integer
);

CREATE TABLE pemasok (
kode_pemasok varchar(20) PRIMARY KEY,
nama_pemasok varchar(20) NOT NULL,
alamat_pemasok varchar(45) NOT NULL,
CHECK(nama_pemasok!=” AND alamat_pemasok!=”)
);

CREATE TABLE gudang (
kode_gudang varchar(20) PRIMARY KEY,
alamat_gudang varchar(45)
);

CREATE TABLE nota_pembelian (
no_nota serial PRIMARY KEY,
kode_pemasok varchar(20) REFERENCES pemasok(kode_pemasok),
tanggal date DEFAULT current_date
);

CREATE TABLE rincian_nota_pembelian (
kode_produk varchar(20) REFERENCES produk(kode_produk),
no_nota integer REFERENCES nota_pembelian(no_nota),
harga_satuan integer,
jumlah integer NOT NULL,
CHECK(jumlah>=20),
PRIMARY KEY(kode_produk, no_nota)
);

CREATE TABLE stok_produk (
kode_produk varchar(20) REFERENCES produk(kode_produk),
kode_gudang varchar(20) REFERENCES gudang(kode_gudang),
jumlah_stok integer NOT NULL,
CHECK(jumlah_stok<=200),
PRIMARY KEY(kode_produk, kode_gudang)
);

Sumber : http://citrakurniawan.wordpress.com/2008/05/23/perancangan-database-sistem-informasi-inventaris/

TEKNIK NORMALISASI

Teknik normalisasi banyak digunakan terutama pemula karena mudah dipahami dan diaplikasikan. 

Dasar-dasar normalisasi

• Normal form (bentuk normal) adalah suatu klas dari skema database relasi yang didefinisikan untuk memenuhi tujuan dari tingginya integritas dan maintainability

• Kreasi dari suatu bentuk normal disebut normalisasi

• Normalisasi dicapai dengan penganalisaan ketergantungan diantara setiap individu attribut yang diassosiasikan dengan relasinya

First normal form

• Suatu relasi ada dalam kondisi First Normal Form (1NF) jika dan hanya jika semua domain yang tercakup terdiri hanya atomic value, misalnya tidak ada pengulangan group (domain-domain) dalam suatu tuple 

• Keuntungan dari 1NF dibanding Unnormalized relation (UNRs) adalah pada bentuk penyederhanaan representasi dan kemudahan dalam pengembangan menggunakan suatu query language

• Kekuranannnya adalah kebutuhan terhadap duplikasi data 

• Sebagian besar sistem relasi (tidak semua) membutuhkan suatu relasi dalam bentuk 1NF

 Second Normal Form

• Suatu superkey adalah suatu himpunan dari satu atau lebih attribute, yang mana, dimana diambil secara khusus yang memmungkinkan kita untuk mengidentifikasikan secara unik satu entitas atau relasi

• Suatu Candidate key adalah suatu subset dari attribut-attribut pada superkey yang juga merupakan superkey dan tidak reducible ke superkey yang lain 

• Suatu primary key dipilih dari himpunan candidate key untuk digunakan pada suatu index untuk relasi yang bersangkutan 

• Kepemilikan dari satu atau beberapa attribute yang dapat didefinisikan secara unik dari nilai satu atau beberapa attribute disebut functional dependency 

• Diberikan suatu relasi (R), suatu himpunan (B) adalah functionally dependent pada himpunan attribut yang lain(A) jika, pada satu waktu tertentu, setiap nilai A diassosiasikan dengan satu nilai B, bentuk ini adalah suatu FD yang dinotasikan dengan A → B

• contohR : {paper-id, inst-name, isnt-addr, editor-id, publ-id, auth-id, auth-name,auth-addr}Fds : paper-id, auth-id → auth-namepaper-id,auth-id → auth-addrpaper-id, auth-id → inst-namepaper-id, auth-id → inst-addrauth-id → auth-nameauth-id → auth-addrinst-name → inst-addrpaper-id → editor-idpaper-id → publ-idbentuk sederhanapaper-id, auth-id → auth-name, auth-addr, inst-name, inst-addrauth-id → auth-name, auth-addrinst-name → inst-addr

paper-id → pub-id, editor-id

 

• Suatu relasi adalah dalam posisi second normal form (2NF) jika dan hanya jika relasi tersebut juga dalam 1NF dan setiap nonkey attribute tergantung penuh pada primary key-nya

• 2NF membutuhkan bahwa FD apapun didalam relasi harus berisi semua komponen dari primary key sebagai determinant, baik secara langsung atau transitif 

• contoh, primary key adalah paper_id, auth_id. Bagaimanapun, terdapat Fds yang lain (auth_Id → auth-name, auth-addr, and paper-id → pub-id, editor-id) yang berisi satu komponen dari primary key, tetapi tidak keduaduanya.

• Mengapa harus 2NF, pertimbangkan keuntungan dari 1NF pada R. paper, pub-id dan editor-id dibuat duplikat. Untuk setiap author dari paper. Jika editor dari publikasi untuk suatu paper berubah, beberapa tuple harus pula di-update. Akhirnya, jika satu paper di ambil, semua tupple yang diassosiasikan harus dihapus. Bentuk ini akan memberikan efek samping pada penghapusan informasi yang mengassosiasikan suatu auth-id dengan auth-name dan auth-addr. 

• Suatu cara yang dapat dilakukan untuk hal tersebut adalah dengan mentransformasikan relasi kedalam dua atau beberapa relasi 2NF

contohR1 : paper-id, auth-id → inst-name, inst-addrR2 : auth-id → auth-name, auth-addrR3 : paper-id → pub-id, editor-id

Third Normal Form 

• Pada R1, inst_addr pasti diduplikat untuk setiap kombinasi paper_author yang mejelaskan satu inst_name. Juga, jika kita menghapus satu paper dari database, kita harus memberikan efek samping penghapusan assosiasi antara inst_name dan inst_addr.
• Suatu relasi dalam Third Normal Form (3NF) jika dan hanya jika relasi tersebut dalam 2NF dan setiap non key attribute adalah nontransitive dependent pada primary key

Contoh :R11 : paper-id, auth-id → inst-nameR12 : inst_name → inst_addrR2 : auth-id → auth-name, auth-addrR3 : paper-id → pub-id, editor-id 

Boyce-Codd Normal Form

• Suatu Trivial FD adalah suatu bentuk YZ → Z
• Suatu relasi R dalam kondisi Boyce-Codd Normal Form (BCNF) jika untuk semua nontrivial FD X → A, X adalah superkey
• BCNF adalah suatu bentuk yang lebih kuat dari normalisasi ke tiga. 3NF equivalent dengan perkataan bahwauntuk setiap nontrivial FD X → A, dimana X dan A merupakan simple atau composite attribut, satu dari duakondisi harus dipenuhi.X adalah superkey, atauA adalah prime attribute
• BCNF mengelimisasi kondisi kedua dari 3NF 

Penerapan Bentuk Normalisasi

Proses perancangan database menggunakan metode normalisasi dapat dimulai dari dokumen dasar yang pakai dalam sistem.

• Menuliskan semua data yang akan direkam, bagian yang double tidak perlu dituliskan. Terlihat record record yang tidak lengkap, sulit untuk membayangkan bagaimana bentuk record yang harus dibentuk untuk merekam data tersebut.

• Bentuklah menjadi bentuk normal kesatu dengan memisah misahkan data pada field field yang tepat dan benilai atomic, juga seluruh record harus lengkap adanya. Bentuk file adalah flat file.
  Dengan bentuk normal kesatu ini telah dapat dibuat satu file dengan 11 field yaitu nomor factur, kode supplier, nama supplier, kode barang, nama barang, tanggal, jatuh tempo, quantitas, harga, jumlah, total satu factur.