The PinK’erZ

HaYooo….bwt nak2 yang mao gaBunK  sama2 kita2 hub 085222340351………

bukan genk moTor….sekedar untuk menyalurkan hobi jalan2…..

othe ditunggu…..

kasuss dan normalisasi

data pada suatu rumah sakit bedah yang telah tersusun dalam bentuk laporan.

Tabel -2

Tabel 2 adalah suatu relasi yang tak normal. Perpotongan antara baris dan kolom ada yang memiliki lebih dari satu nilai. Identifikasi unik (primary key) dari table 2 adalah NO PASIEN. Berdasankan nilai key ini kita tidak bisa memperoleh nilai atribut yang unik, karena terjadi group pengulangan pada kolom-kolom

NO DOKTER
NAMA DOKTER
TGL OPERASI
JENIS OPERASI
Disain dengan group pengulangan seperti ini akan banyak menimbulkan masalah dalam melakukan pemrosesan, yaitu diperlukan program aplikasi yang sedikit kompleks, karena untuk kolom di mana terjadi group pengulangan diperlukan penanganan khusus.

1NF

Untuk mengatasi hal ini, kita transformasikan tabel pada table 2 menajdi tabel dengan relasi bentuk normal pertama table 3. Identifikasi unik pada tabel ini adalah NO PASIEN, NO DOKTER, TGL OPERASI. Dengan kata lain, jika kita mengetahui NO PASIEN, NO DOKTER dan TGL OPERASI maka kita bisa memperoleh nilai unik dan atribut-atnibut yang lainnya. Dalam hal ini dikatakan, semua atribut yang bukan sebagai key secara bersama-sama bergantung penuh kepada identifikasi unik. Identifikasi unik ini disebut sebagai primary key dari tabel 1NF.

Penyimpangan yang terjadi pada relasi bentuk normal ke pertama ini adalah sbb enyimpangan penyisipanJika ada pasien baru yang akan dioperasi, tapi kita belum tahu siapa dokternya dan kapan operasi dilakukan, maka kita tidak bisa menyisipkan data tentang pasien tersebut berdasarkan primary key yang ada. Untuk menyisipkan NAMA PASIEN dan ALAMAT PASIEN, kita hanya membutuhkan NO PASIEN sebagal key. Jadi kita tidak bisa menyisipkan data sebelum diketahui dokter siapa dan kapan operasi akan dilakukan. Jika kita plsahkan atribut NAMA PASIEN, ALAMAT PASIEN bersama-sama dengan NO PASIEN, maka penyisipan data pasien baru bisa dilakukan.
Hal yang sama juga terjadi jika kita ingin menyisipkan dokter yang baru mulal bekerja pada rumah sakit tersebut. Selama dokter baru tersebut belum pemah melakukan operasi, maka kita tidak bisa menyisipkan data tentang dokter tersebut ke dalam entiti. Hal ini bisa diatasi dengan memisahkan atribut NAMA DOKTER bersama-sama dengan atribut NO DOKTER menjadi satu entiti baru.Penyimpangan perubahanPasien yang merupakan langganan rumah sakit tersebut yang beberapa kali dioperasi, seperti mlsalnya pasien dengan nama JOHN, setiap kali dilakukan operasi, data-data tentang JOHN, yaitu NAMA dan ALAMAT akan tercatat dalam satu rekord. Dalam contoh ini JOHN dioperasi sebanyak empat kali, maka JOHN memiliki empat rekord. Jika suatu saat, misahiya JOHN dioperasi untuk yang ke lima kalinya, sedangkan pada seat itu JOHN sudah pindah alamat. Jadi alamat-alamat yang tercatat sebelumnya tidak berlaku lagi dan perlu diperbaharui. karena alamat JOHN tercatat dibeberapa tempat, maka pembaharuan juga harus dilakukan dibeberapa tempat. ini adalah contoh penyimpangan perubaban yang muncul pada table dengan relasi bentuk pertama.Penyimpangan perubahan ini bisa diatasi, jika atribut-atribut NAMA
PASIEN dan ALAMAT PASIEN tercatat hanya sekali untuk setiap pasien.
Hal ini bias dilakukan dengan menempatkan atribut NAMA PASIEN dan
AIAMAT PASIEN bersama-sarna dengan NO PASIEN dalam satu entiti
terpisah.Penyimpangan-penghapusan yang teijadi pada relasi bentuk
pertama ini adalah sebagai berikut: Penyimpangan penghapusanMisalnya ada pasien yang dirawat meninggal dunia, misalnya pasien dengan nama BUD!. Ketika data-data tentang BUDI dihapus, secara tidak sengaja kita juga kehilangan data-data tentang dokter yang melakukan operasi terhadap BUDI, yaltu DR. A. Kebetulan. DR. A melakukan operasi baru sekali, sehingga data-data tentang DR. A tidak ada ditempat lain. Tentunya hal. ini tidak diinginkan karena data-data tentang DR. A masih dlbutuhkan di rumahsakit tersebut.Penyimpangan penghapusan seperti pada contoh ini, bisa diatasi dengan memisahkan data-data tentang dokter menjadi satu entili terpisah, dengan demikian setiap ada pasien yang meninggal dunia dan rekordnya Ingin dihapus, kita tidak akan kehilangan data-data tentang dokter yang merawatnya.
Di samping penyimpangan di atas, pada relasi dengan bentuk normal pertama juga terjadi penyimpangan-penyimpangan tempat penyunpanan (storage Anomaly), yaftu pada kolom kolom NO PASIEN, NAMA PASIEN, ALAMAT PASIEN terdapat nilai yang ditulis berulang-ulang, ini disebabkan karena pasien dengan NAMA dan ALAMAT tersebut menjalani beberapa kali operasi. Hal yang sama juga terjadi pada kolom NO DOKTER dan NAMA DOKTER yaitu untuk dokter-dokter yang telah melakukan beberapa kali operasi. Penyimpangan ini muncul karena ada atribut-atribut yang bergantung secara penuh kepada bagian dari key. Seperti mlsa]nya NAMA PASIEN dan M4MAT PASIEN bergantung secara penuh pada NO PASIEN, dan NO PASIEN adalah bagian dari key. Demikian juga untuk atribut NAMA DOKTER yang bergantung secara penuh pad NO DOKTER yang merupakan bagian dari key.
Untuk mengatasi penyimpangan.penyimpangan yang terjadi pada bentuk normal pertama adalah pisahkan kolorn-kolom ditempat mana duplikasi data terjadi atau bangun enilti baru yang terdiri dari atribut atribut yang bergantung secara penuh pada bagian dari key, dengan keteutuan sebag benikut:
I. Key dari tabel baru adalah key dari group dupilkasi.2. Key dari tabel asal adalah sebagai atribut pada tabel baru.3 Mungkin perlu menyertakan key atau bagian dar key pada tabel asal
sebagai key pada tabel baru Group duplikasi pada pembahasan kita adalah NO PASIEN, NAMA PASIEN ALAMAT PASIEN dan key dari group ini adalah No PASIEN

Tabel-4

Sedangkan group duplikasi yang lain, yaitu NO DOKTER dan NAMA DOK. TER dipisahkan menjadi tabel DOKTER, dengan key NO DOKTER. Tabel. nya terlihat pada table-5

Tabel-5

Sedangkan entiti asal akan menjadi seperti benikut, kita sebut saja sebagal tabel MASTER. Group duplikasi pada tabel yang klta bicanakan adalah NO PASIEN, NAMA PASIEN, ALAMAT PASIEN. Bentuk tabel barn dengan nama PASIEN

Tabel-6

Hasil proses normalisasi dan relasi normal bentuk pertama, yaltu pada table-4, table-5,Tabel-6 adálah relasi beniUk iormal kedua (2NF).

Untuk melakukan pengecekan, apakah relasi dalam suatu tabel bukan merupakan bentuk normal ke dua adalah jika primary key merupakan gabungan dan beberapa atnibut dan ada atribut lain yang bergantung secara penuh pada salah satu atau bagian dan primary key.
Setiap relasi bentuk normal ice dna makaju merupakan relasi bentuk normal pertama. Sebaliknya, jika rebel bentuk normal pertama maka belum teutu merupakan relasi bentuk normal ice dua. Tabel yang ditunjukkan pada Gambar XWJ adalah relasi bentuk normal pertama, tapi bukan bentuk normal ke dna, sedangkan pada Gambar XWA, Gambar XW.5 dan Gambar XIV4 adeh relasi bentuk normal pertama dan juga relasi bentuk normal kedua.Penyunpangan-penyimpangan yang teqadi pada relasi bentuk normal pertama dapat diatasl dengan membanin entfti-entiti barn, yaltu entiti MASTER, entiti PASIEN dan entiti DOKTER. Proses nornalisasi di aim menghasm relasi bentuk normal kedua,. Relasi antara ketiga entiti dapat digambarkan sebagai benlkut PASIEN > MASTER < DOKTER
yaita antara PASIEN dan MASTER satu-ke-banyak dan antara DOKTER dan MASTER satu-ke-banyak.Jika kita ingin menyisipkan data-data tentang pasien baru, pada relasi bentuk normal kedua kita melakukannya dengan menyisipkan data teisebut ke entiti PASIEN. Demikian juga, jika data-data tentang dokter yang ingin dimasukkannya, kita bisa menyisipkarmya pada entiti DOKTER. Untuk melakukan perubahan.pembakan alamat pasien, kita tidak penlu lagi melakukan perubahan dibeberapa tempat, tapi cukup mengadakan perubahan satu rekord pada entiti PASIEN. Apabila ada rekord yang harus dihapus pada entiti MASTER, kita tidak akan kehilangan data-data tentang dokter yang dihapus pada entiti MASTER, karena semua data-data tentang dokter berada dalam entiti DOKTER.
Penyirnpangan..penyimpangan yang tenjadi pada relasi bentuk normal pertama telah dapat diatasi dengan mentransformasikan menjadi relasi bentuk normal kedua. Walaupun demikian, bukan berarti pada relasl bentuk normal kedua sudah tidak ada lagi penyimpangan-penyimpangan tersebut. Berikut ini kita lihat penyimpangan..penyimpg yang teijadi pada relasi bentuk normal kedua, perhatjkan Garnbar XW.6. Penyimpangan penyisipan Kita tidak bisa menyisipkan data-data tentang obat dan efek sarnpi. ngannya, kecuali jika obat tersebut diberikan kepada pasien. Dengan kata lain, jika kita ingin menyisipican data-data tentang obat, maka kita tenlebih dahulu hams membangun suatu relasi dengan primary key pada entiti MASTER. Penyimpangan penghapusan Penyimpangan penghapusan teijadi jika ada atribut bukan key yang bergantung penuh pada atnibut yang juga bukan key. Path gambar XIV.6, atnibut EFEK SAMPINGAN di samping bergantung path primary key, juga bergantung path atnbut OBAT YANG DJBERJK yang bukan sebagai k. Jika misainya ada pasien yang dlbCdkan PENICILLIN tapi efek sampin ya bukan DEMAM, maka EFEK SAMPINGAN liii harus dthapus atan diperbahanihi. Jika PENICILLIN dengan EFEK SAMPINGAN DEMAM mlsalnya tercatat hanya sekali, maka penghapusan ml akan mengiilangkan informasi teñtang PENICILLIN dengan EFEK SAMI’INGAN DEMAM. Hal ini mungkin tidak diinginkan.Penyimpangan perubahan Jika EFEK SAMPINGAN yang dibicarakan dalam kasus penyimpangan penhapusan muncul dibeberapa tempat, maka perubahan harus dilakukan dibeberapa tempat. Hal ini tentunya akan membutuhkan lebih banyak waktu dibandingkan dengan melakukan perubahan hanya pada satu tempat saja.Penyimpangan-penyimpangan yang terjadi pada relasi bentuk normal kedua sebagai akibat dari kebergantungan atribut bukan key (EFEK SAMPINGAN) pada atribut lain yang juga bukan sebagai key (OBAT YANG DIBERIKAN). Ketergantungan semacam ini disebut ketergantungan transitif (transitive Dependency).Untuk mengatasi ketergantungan transitif ini, pisahkan atribut-atribut bukan key yang bergantung pada atribut lain yang juga bukan key. Dalam catoh ini, kita bangun entiti baru, yaitu entiti OBAT dengan atribut-atribut OBAT YANG DIBERIKAN dan EFEK SAMPINGAN. Entiti MASTER sekarang tampak pada table 7 dan entiti OBAT pada table 8

Tabel-7

Proses normalisasi yang dilakukan pada relasi bentuk normal kedua menghasilkan relasi dengan bentuk normal ketiga.

Setiap relasi bentuk normal ketiga maka juga merupakan relasi bentuk normal kedua. Sebaliknya, jika relasi bentuk normal kedua maka belum tentu merupakan relasi bentuk normal ketiga. Tabel yang ditunjukkan pada table 7 adalah relasi bentuk normal ketiga dan juga relasi bentuk normal kedua.Penyimpangan-penyimpangan yang terjadi pada relasi bentuk normal kedua, dapat diatasi dengan membangun entiti baru yang terdiri dari atribut-atribut yang bergantung transitif, dan proses normalisasinya menghasil relasi bentuk normal ketiga. Transforrnasi dan relasi bentuk normal kedua ke relasi bentuk normal ketiga hampir sama dengan transformasi dan bentuk normal pertama kebentuk normal kedua. Perbedaan keduanya adaIah, tranformasi dari 1NF ke 2NF, berdasarkan relasi antara atribut bukan key dengan atribut yang sebagai key sedangbn transformasi dari 2NF ke 3NF, berdasarkan relasi antara atribut bukan key dengan atribut lain yang juga bukan key.

model database dan studi kasus

 

Karakteristik Pendekatan Database

·Independensi Data. Data terpisah dari aplikasi yang mengakses dan memproses data.

·Konsistensi Data. Setiap elemen data dalam database memiliki definisi standard. Oleh karena itu, elemen data tersebut akan konsisten dalam setiap aplikasi yang menggunakan elemen data tersebut.

·Satu kali input data. Data cukup diinputkan satu kali, kemudian disimpan dan dapat diakses oleh berbagai aplikasi oleh beragam pengguna.

·Integrasi data.

·Share data ownership.

·Centralized data management. DBMS mengelola dan mengendalikan akses terhadap semua data dalam sistem.

·Pengelolaan dan Akses Data menjadi lebih simpel.

Pengembangan Database
Hal-hal yang penting dalam merancang dan mengkonstruksi database:

·Apa tujuan sistem yang dibuat?

· Siapa yang akan menggunakan data tersebut?

·Berapa kali dalam sehari data tersebut akan diakses (dibaca dan diupdate)?

·Berapa besar data yang perlu disimpan?

·Sistem apa yang akan mengakses data tersebut?

Tahapan dalam Pengembangan Database

·Perencanaan.

·Analisis. Contoh model konseptual yang dapat digunakan adalah Entity Relationship Diagram. Dalam tahap analisis, perancang juga membuat data dictionary.

·Desain secara detail.

·Implementasi.

·Testing.

·Maintenance.

Membuat Model Data ~ Diagram ER

·Membuat Entitas dan menentukan relationship

·Menentukan kardinalitas setiap relationship

·Ada tiga jenis kardinalitas: One to One, One to Many dan Many to Many

·Menentukan atribut data

KASUS

Park Plaza adalah apartemen yang berlokasi di Paingan Maguwoharjo. Park Plaza memiliki dua gedung apartemen. Gedung pertama memiliki 20 apartemen dan gedung kedua memiliki 30 apartemen. Dari kelima puluh apartemen tersebut, ada apartemen dengan satu kamar, dengan dua kamar dan dengan tiga kamar. Apartemen disewakan dengan sistem pembayaran bulanan. Uang sewa dibayarkan di awal masa sewa. Setiap penyewa wajib membayar uang jaminan sewa (sebesar harga sewa apartemen). Uang jaminan sewa ini akan dikembalikan, jika penyewa berhenti menyewa dan jika pemilik apartemen tidak menemukan kerusakan yang berarti. Setiap tujuh hari sebelum tanggal jatuh tempo pembayaran sewa, pemilik sewa memberi surat tagihan kepada penyewa apartemen, untuk mengingatkan penyewa.

Rancanglah Diagram ER untuk apartemen tersebut. (CATATAN: Anda boleh menggunakan buku apapun sebagai acuan untuk merancang ER tersebut, bawa saja buku yang pernah anda pelajari atau pernah digunakan di mata kuliah lain, saat mempelajari database).
Lengkapi diagram ER tersebut, dengan informasi mengenai field (elemen data) dalam setiap tabel, primary key setiap tabel, foreign key setiap tabel, dan tipe data setiap field.

Sumber : blogakuntansi.blogspot.com/2008/02/membuat-model-database.html

 

Studi kasus basis data

MEMAHAMI TEORI NORMALISASI DATA MELALUI STUDI KASUS

STUDI KASUS TOKO ABC

No. Faktur :
Tanggal : Kepada :

No.	Nama	Jumlah	Harga	Total
			Total Bayar
			Diskon
			Jumlah Bayar

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

 

TAHAP-TAHAP NORMALISASI DATA

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)

Semoga ilustrasi di atas dapat memudahkan dalam memahami proses normalisasi data.

 

SBD..

Perancangan Database

Posted on April 11, 2008 by krida

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)

);

 

tugasSBD

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.

 

Hello world!

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