Modul 6 ppst 3 perancangan basis data
LAPORAN
TI 3007 – PRAKTIKUM PERANCANGAN SISTEM TERINTEGRASI III
MODUL 6
PERANCANGAN BASIS DATA
Oleh: Kelompok 9
1. Theo Renaldo
13412009
2. Hanna Octaviani
13412037
3. Della Rieza Ramdhani
13412067
4. Nadia Shafira Novarena
13412094
LABORATORIUM SISTEM INFORMASI DAN KEPUTUSAN PROGRAM STUDI TEKNIK INDUSTRI INSTITUT TEKNOLOGI BANDUNG 2015
LEMBAR PENGESAHAN
Asisten Laboratorium Sistem Informasi dan Keputusan ITB (LSIK ITB) yang bertandatangan di bawah ini mengesahkan Laporan Praktikum Perancangan Sistem Terintegrasi (PPST) III Modul 6 Perancangan Basis Data kelompok 09, yang beranggotakan:
1. Theo Renaldo
2. Hanna Octaviani
3. Della Rieza Ramdhani
4. Nadia Shafira Novarena
Dan menyetujui untuk dikumpulkan pada:
Hari : Jumat
Tanggal : 17 April 2015 Waktu
: maksimal pukul 11.00 WIB
Bandung, 17 April 2015
Ahmad Ibrahim Fahmi
13412007 – 13412037 – 13412067 - 13412094
LEMBAR ASISTENSI
13412007 – 13412037 – 13412067 - 13412094
Asistensi : Modul 6 PPST III Asistensi ke
:1 Tanggal
: 13 April 2015 Nama Aisten
: Ahmad Ibrahim Fahmi (13411051) Anggota
1. Theo Renaldo
(13412009)
2. Hanna Octaviani
(13412037)
3. Della Rieza Ramdhani
(13412067)
4. Nadia Shafira Novarena (13412094) Catatan
BAB I. Pendahuluan
1.1 Latar Belakang
1.2 Tujuan
1.3 Flowchart Perancangan Basis Data BAB II. Perancangan Basis Data
2.3.1 Logical Database Design
2.3.2 Physical Database Design
2.4 Implementasi BAB III Poin Analisis
3.1 Analisis Pembuatan ERD
3.2 Analisis Teknik Normalisasi
3.3 Analisis Software DBMS
3.3 Analisis Keterkaitan Antar Modul BAB IV. Kesimpulan dan Saran
13412007 – 13412037 – 13412067 - 13412094
BAB 1 PENDAHULUAN
1.1 Latar Belakang
PT Kereta Kayu Mainan (KKM) Jaya merupakan salah satu perusahaan industri penghasil mainan tradisional berupa kereta kayu mainan di Indonesia yang telah mulai melebarkan sayapnya ke beberapa negara lain di ASEAN. Untuk menghadapi tingkat persaingan yang begitu tinggi dengan kompetitor-kompetitornya, PT KKM Jaya pun berencana untuk melakukan instalasi sistem SAP untuk mengintegrasikan proses bisnis antar kantor cabang dan pabrik yang dimilikinya. Selain itu, perusahaan ini juga selalu berusaha untuk dapat menembus pasar ASEAN dan menjadi market leader dari penjualan kereta kayu mainan dengan cara menjaga dan memperhatikan kesehatan perusahaannya. Kesehatan perusahaan ini salah satunya dilihat dari kestabilan sistem informasi yang dimilikinya.
Untuk meningkatkan kinerja perusahaan dan mewujudkan integrasi antardivisi dan antar kantor cabangnya, PT KKM Jaya berniat untuk membuat dan memasang suatu sistem informasi berbasis computerized yang dilakukan dengan menggunakan pendekatan pemodelan proses bisnis. Proses bisnis yang telah dibuat dalam DFD ini selanjutnya hendak ditransformasikan dan digunakan sebagai referensi untuk membuat suatu sistem basis data perusahaan. Sistem basis data ini digunakan untuk memudahkan pengarsipan dan pengolahan data secara teratur dan terintegrasi. Perancangan basis data yang dilakukan diharapkan dapat mempermudah penyimpanan data pada seluruh tingkat proses bisnis yang dilakukan.
1.2 Tujuan
1.2.1 Tujuan Umum
Memahami prinsip perancangan sistem informasi yang terdiri dari perancangan aplikasi dan basis data. Memahami proses desain basis data dengan menggunakan Entity Relationship Diagram (ERD), Logical Data Model, dan Physical Data Model. Mendesain aplikasi berupa user interface.
Mengimplementasikan model desain basis data dengan menggunakan Microsoft Access.
1.2.2 Tujuan Khusus
Memahami dan mampu merancang Entity Relationship Diagram (ERD), Logical Data Model, dan Physical Data Model.
Mampu merancang aplikasi sistem informasi sederhana yang dilengkapi user interface.
1.3 Flowchart Perancangan Basis Data
Pelaksanaan praktikum Modul 6 Praktikum Perancangan Sistem Terintegrasi (PPST) III dimulai dengan kegiatan Responsi Awal yang dilaksanakan pada hari Senin, 5 April 2015. Responsi Awal terdiri dari penjelasan materi modul, pelaksanaan tes awal praktikum, serta penjelasan singkat mengenai pelaksanaan praktikum dan pembagian asisten. Tahap selanjutnya adalah pelaksanaan praktikum. Pada praktikum ini pertama-tama praktikan diberikan penjelasan mengenai penggunaan dan pengoperasian Microsoft Access untuk membuat suatu sistem basis data. Selanjutnya, setelah penjelasan dan demo singkat tersebut, praktikan menggunakan 13412007 – 13412037 – 13412067 - 13412094
Tahap selanjutnya adalah Asistensi 1, dimana asisten memberikan feedback terkait pengumpulan 1 dan memberikan penjelasan lebih lanjut mengenai penulisan laporan. Pada tahap ini juga asisten akan memeriksa apakah pengerjaan pada pengumpulan 1 sudah sesuai atau belum, jika belum sesuai makan praktikan harus melakukan revisi terlebih dahulu. Langkah berikutnya yaitu membuat form dan switchboard dan mengumpulkan seluruh pengolahan data final pada Rabu, 15 April 2015. Kemudian, setelah semua proses perancangan selesai, tahap terakhir yang dilakukan adalah menyusun laporan dan mengumpulkannya tepat waktu.
Berikut adalah flowchart dari Modul 6 Praktikum Perancangan Sistem Terintegrasi (PPST) III mengenai Perancangan Basis Data.
13412007 – 13412037 – 13412067 - 13412094
Start
Responsi Awal Praktikum
Asistensi 1
Belum
Data Flow Diagram
Sudah benar?
Melakukan Revisi
Sudah
Pelatihan Pengoperasian
Pembuatan Form
Microsoft Access
Pembuatan Entity Relationship Diagram (ERD)
Pembuatan Switchboard
Asistensi 0
Pengumpulan 2
Pembuatan tabel database
Penyusunan Laporan
Pembuatan query untuk setiap tabel
Pengumpulan Laporan
Stop
Pembuatan report untuk setiap query
Pengumpulan 1
Gambar 1 Flowchart praktikum
15
13412007 – 13412037 – 13412067 - 13412094
BAB 2 PERANCANGAN BASIS DATA
2.1 Planning
Planning adalah tahapan yang dilakukan untuk mengidentifikasi permasalahan dalam organisasi dan kemungkinan solusi sesuai dengan kebutuhan dan keinginan pengguna. Model ini terdiri dari dua bagian, yakni mengidentifikasi detail dari aktivitas organisasi dan mengidentifikasi entitas-entitas serta relasi di antara entitas- entitas tersebut. Sesuai dengan yang telah disampaikan pada DFD dalam modul sebelumnya, aktivitas (proses bisnis) yang dilakukan oleh Divisi Logistik PT. KKM Jaya adalah sebagai berikut :
1.1 Mengelola Jalinan Kemitraan dengan Supplier Aktivitas ini terdiri dari 2 bagian, yakni
1.1.1 Mengelola Pendataan Supplier Pendataan ini dilakukan untuk mengetahui informasi serta data-data mengenai seluruh supplier yang berhubungan dengan pengadaan bahan baku
1.1.2 Mengelola Hubungan Kemitraan Hubungan kemitraan ini adalah pengelolaan untuk supplier-supplier yang telah bekerja sama dengan perusahaan
1.2 Mengelola Pengadaan Pengadaan terdiri dari dua aktivitas, yakni
1.2.1 Mengelola Rencana Pengadaan Rencana pengadaan ini perlu dikelola agar sesuai dengan kebutuhan bahan baku yang akan digunakan oleh bagian produksi.
1.2.2 Mengelola PO dan DO Mengelola purchase order dan delivery order adalah hal yang penting bagi perusahaan agar mengetahui bahan baku mana saja yang sudah dipesan kepada supplier, dan bahan baku mana saja yang sudah diantarkan oleh supplier tersebut.
1.2.3 Mengelola Evaluasi Pengadaan Keseluruhan aktivitas pengadaan perlu dievaluasi agar proses pengelolaan pengadaan dapat diperbaiki jika terdapat proses yang tidak efisien.
1.3 Mengelola Pergudangan Terdapat 3 aktivitas yang berada di bawah aktivitas pengelolaan pergudangan.
1.3.1 Mengelola Penerimaan Barang dari Supplier Aktivitas ini dilakukan agar semua penerimaan barang dari supplier dapat tercatat dengan baik dan dapat dicek kesesuaiannya dengan rencana pengadaan bahan baku.
1.3.2 Mengelola Inventory Gudang yang berada di perusahaan merupakan tempat penyimpanan bagi bahan baku maupun produk yang sudah jadi. Karena adanya keterbatasan kapasitas gudang, inventory ini perlu dikelola agar menghasilkan ongkos total yang minimum dengan menghindari adanya kekurangan bahan baku maupun produk jadi.
1.3.3 Mengelola Evaluasi Pergudangan Keseluruhan aktivitas pergudangan perlu dievaluasi agar proses pengelolaan pergudangan dapat diperbaiki jika terdapat proses yang tidak efisien.
1.4 Mengelola Pendistribusian Pengelolaan pendistribusian terbagi ke dalam 4 aktivitas, yakni
1.4.1 Mengelola Pengambilan Barang Pengelolaan pengambilan barang ini dilakukan agar terjadi pencatatan yang runtun antara bagian distribusi dan bagian pemasaran serta penjualan.
1.4.2 Mengelola Persiapan Pengiriman Persiapan pengiriman ini dilakukan untuk mempersiapkan barang-barang yang telah dipesan oleh pelanggan agar siap untuk dikirim.
1.4.3 Mengelola Pengiriman Barang Mengelola pengiriman barang ini merupakan suatu aktivitas yang mencatat dan mengeksekusi pengiriman barang kepada pelanggan.
1.4.4 Mengelola Evaluasi Distribusi Keseluruhan aktivitas pendistribusian perlu dievaluasi agar proses pengelolaan pendistribusian dapat diperbaiki jika terdapat proses yang tidak efisien.
Aktivitas – aktivitas tersebut kemudian akan diolah untuk membentuk suatu Enterprise Data Model. Adapun entitas – entitas awal (sebelum normalisasi) yang terdapat dalam pemodelan sistem basis data adalah sebagai berikut.
Tabel 1 Entitas
No Nama Entitas
Penjelasan
1 Pelanggan Entitas ini mengandung informasi id pelanggan, nama pelanggan, alamat pelanggan, dan no telepon pelanggan.
2 Produk Jadi Entitas ini mengandung informasi id produk jadi, nama produk jadi, dan stok produk jadi
3 Evaluasi Distribusi Entitas ini mengandung informasi id evaluasi distribusi, tanggal evaluasi distribusi, hasil evaluasi distribusi, dan rekomendasi perbaikan distribusi
4 Barang Terkirim Entitas ini mengandung informasi id barang terkirim, id produk jadi, id pelanggan, tanggal pengiriman, dan jumlah barang dikirim.
5 Staf Entitas ini mengandung informasi id staf, nama petugas, dan jabatan.
6 Gudang Entitas ini mengandung informasi id gudang, lokasi gudang, pj gudang, dan kapasitas gudang.
7 Bahan Baku Entitas ini mengandung informasi id bahan baku, nama bahan baku, dan stok bahan baku.
8 Supplier yang Bekerja Sama Entitas ini mengandung informasi id supplier, nama supplier, alamat supplier, dan no telepon supplier.
9 Evaluasi Pengadaan Entitas ini mengandung informasi id evaluasi pengadaan, tanggal evaluasi pengadaan, hasil evaluasi pengadaan, dan rekomendasi perbaikan pengadaan.
10 Pengadaan Bahan Baku Entitas ini mengandung informasi id pengadaan, id supplier, id evaluasi pengadaan, id bahan baku diadakan, tanggal 10 Pengadaan Bahan Baku Entitas ini mengandung informasi id pengadaan, id supplier, id evaluasi pengadaan, id bahan baku diadakan, tanggal
11 Evaluasi Inventori Entitas ini mengandung informasi id evaluasi inventori, tanggal evaluasi inventori, hasil evaluasi inventori, dan rekomendasi perbaikan inventori.
12 Pengelolaan Inventori Entitas ini mengandung informasi id pengelolaan inventori, id bahan baku, id evaluasi inventori, id produk jadi, dan id gudang.
Sedangkan relasi antarentitas tersebut dijelaskan dalam tabel berikut ini.
Tabel 2 Relasi Antar Entitas
Sifat Relasi
Produk Jadi
M to M
Satu pelanggan dapat dikirimkan banyak produk jadi dan satu produk jadi dapat dikirimkan ke banyak pelanggan.
Evaluasi
Melakukan
Barang terkirim
1 to M
Satu kali evaluasi distribusi dapat
Distribusi
evaluasi melakukan evaluasi terhadap banyak barang terkirim, tetapi satu barang terkirim hanya dilakukan satu kali evaluasi distribusi.
Staf
Memesan
Produk Jadi
M to M
Satu staf dapat memesan banyak produk jadi. Satu produk jadi juga dapat dipesan oleh banyak staf.
Satu staf dapat memimpin banyak gudang, namun satu gudang hanya dipimpin oleh satu staf.
Produk Jadi
Membutuhkan Bahan Baku
M to M
Satu produk jadi bisa membutuhkan banyak jenis bahan baku. Begitu pula satu
jenis bahan baku dapat dibutuhkan oleh banyak produk jadi.
Supplier
yang Memasok
Bahan Baku
M to M
Satu supplier yang bekerja sama
bekerja sama
dapat memasok berbagai jenis bahan baku. Satu jenis bahan baku pun dapat dipasok oleh banyak supplier yang bekerja sama.
Satu kali evaluasi pengadaan dapat
Pengadaan
evaluasi
Bahan Baku
melakukan evaluasi terhadap banyak pengadaan bahan baku, tetapi satu pengadaan
bahan baku hanya
dilakukan
satu kali evaluasi
Bahan Baku
M to M
Satu gudang dapat menyimpan Satu gudang dapat menyimpan
Gudang
Menyimpan
Produk Jadi
M to M
Satu
dapat menyipan beragam jenis bahan produk jadi. Satu
gudang
produk jadi dapat disimpan di banyak gudang.
Satu kali evaluasi inventori dapat
melakukan evaluasi terhadap banyak pengelolaan inventori, tetapi satu pengelolaan
inventori hanya dilakukan satu kali evaluasi inventori.
2.2 Analysis
Analysis adalah tahapan dalam perancangan basis data untuk menentukan spesifikasi dari sistem informasi yang dibutuhkan untuk mendukung kebutuhan pengguna sistem informasi tersebut. Tahapan ini dapat dibagi menjadi dua bagian yaitu mempelajari situasi bisnis saat ini dan menentukan kebutuhan sistem dam perbaikannya.
Mempelajari situasi bisnis saat ini Bagian mempelajari situasi bisnis sudah dilakukan pada modul sebelumnya menggunakan IDEF0
diagram. Dengan menggunakan IDEF0 diagram, tahapan atau metodologi pengembangan dari suatu sistem dapat diketahui dengan jelas. Sistem dimodelkan sebagai kumpulan fungsi-fungsi yang saling berkaitan satu dengan yang lain untuk membentuk suatu fungsi utama. Fungsi-fungsi tersebut menjelaskan apa yang dikerjakan oleh sistem tersebut. Dengan demikian, apa saja yang mengontrol, memproses, diproses, dan dihasilkan oleh sistem tersebut dapat diketahui.
Menentukan kebutuhan sistem dan perbaikannya Dalam menentukan kebutuhan sistem, kebutuhan tersebut dibagi menjadi dua jenis yaitu kebutuhan
fungsional (Functional Requirements) dan kebutuhan non functional (Nonfunctional Requirements). o Functional Requirement Functional Requirement adalah kebutuhan akan fungsi atau fitur yang harus ada dalam sistem
informasi untuk memenuhi kebutuhan bisnis dan diterima oleh pemakai (user). Kebutuhan fungsional dapat dikelompokkan menjadi empat sebagai berikut.
User Interface Requirements User Interface Requirements adalah kebutuhan pengguna sistem akan input-output
yang didukung sistem informasi. User Interface merupakan bentuk tampilan grafis yang berhubungan
yang berfungsi untuk menghubunngkan antara pengguna dengan sistem operasi, sehingga sistem informasi tersebut dapat digunakan. Tujuan adanya interaksi antara manusia dan sistem informasi adalah pengoperasian dan control yang efektif, dan umpan balik dari sistem informasi yang membantu operator untuk membuat keputusan
langsung
dengan
pengguna pengguna
Processing Requirements Processing Requirements adalah spesifikasi kebutuhan pemrosesan yang diperlukan
untuk melakukan semua aktivitas yang terlibat dalam transformasi input menjadi output. Proses yang diperlukan pada sistem informasi ini adalah mengelola pengadaan, pergudangan, dan pendistribusian. Dengan proses tersebut, sistem informasi dapat digunakan oleh user untuk mentransformasikan input menjadi output sesuai dengan kebutuhan.
Storage Requirements Pengorganisasian, isi, dan ukuran basis data dan prosedur untuk perawatannya.
Pada sistem informasi yang dirancang, dibuat tabel-tabel yang berfungsi untuk menyimpan data-data yang diinput oleh user. Tabel yang digunakan sebagai media penyimpanan data disusun sedemikian rupa sehingga terorganisasi dan terstruktur isinya untuk memudahkan user dalam membaca dan memahami data yang terdapat pada sistem informasi.
Control Requirements Kebutuhan terkait dengan akurasi, validitas, keselamatan, keamanan, dan
adaptabilitas. Pada sistem informasi yang dirancang dapat dibuat fitur-fitur yang dapat mengurangi kesalahan-kesalahan penginputan data sehingga data yang dimasukkan lebih akurat dan valid. Selain itu sebuah sistem informasi dapat diberikan fitur berupa kata sandi untuk dapat diakses sehingga keselamatan dan keamanan sistem informasi dapat terjaga.
o Nonfunctional Requirements Kebutuhan yang berkaitan dengan uraian fitur, karakteristik, dan atribut sistem yang
membatasi usulan solusi. Dalam menentukan kebutuhan nonfunctional digunakan tools PIECES untuk mengklasifikasikan permasalahan, kesempatan, dan tujuan.
Nonfunctional
Explanation
Requirement Type Performance
Sistem informasi dapat mengolah data pengadaan dengan
baik Sistem informasi dapat mengolah data pergudangan dengan
baik Sistem informasi dapat mengolah data pendistribusian
dengan baik
Information Sistem informasi dapat mengolah data sesuai dengan
kebutuhan user Sistem informasi dapat menyajikan hasil pengolahan data
tepat pada waktu dibutuhkan Sistem informasi menghasilkan output yang akurat Sistem informasi dibuat dalam bentuk atau format yang
sesuai dengan kebutuhan user
Economy Sistem informasi didesain sedemikian rupa sehingga biaya
yang dikeluarkan kecil Sistem informasi didesain sehingga hardware yang dibutuhkan untuk menjalankan sistem informasinya tidak yang dikeluarkan kecil Sistem informasi didesain sehingga hardware yang dibutuhkan untuk menjalankan sistem informasinya tidak
Control (and security) Sistem informasi harus dapat dikendalikan oleh user yang
berkepentingan Sistem informasi harus memiliki fitur keamanan yang baik
sehingga data yang tersimpan aman
Efficiency Sistem informasi tidak mengandung fungsi atau tampilan
yang redundan Pemrosesan data yang terdapat pada sistem informasi didesain seefektif mungkin sehingga dapat berjalan dengan cepat
Data yang perlu diinput atau yang akan ditampilkan hanya data yang diperlukan oleh user sehingga tidak dilakukan pengolahan data yang tidak perlu
Service Sistem informasi dibuat sesuai dengan kebutuhan user dan
menghasilkan data yang reliable Sistem informasi didesain untuk mengakomodasi perubahan- perubahan yang mungkin terjadi atau fleksible Sistem informasi didesain dengan tetap memungkinkan terjadinya pengembangan sistem informasi tersebut di masa depan
2.3 Design
2.3.1 Logical Database Design
Proses pembuatan LDM dimulai dengan melakukan tahap normalisasi untuk semua hubungan many to many yang ada pada ERD sederhana pada subbab sebelumnya. Normalisasi ini dilakukan dengan cara menjadikan hubungan relasi (bentuk belah ketupat) antara 2 entitas yang berhubungan M-M menjadi suatu entitas baru. Entitas baru ini berfungsi ganda sebagai relasi sekaligus sebagai entitas, sehingga hubungan antar entitas menjadi 1-M, tidak lagi M-M.
Pada perancangan LDM ini hanya dilakukan satu buat normalisasi, yaitu membuat relasi kebutuhan antara produk jadi dan bahan baku menjadi sebuah relasi sekaligus entitas. Hal ini dilakukan karena satu produk jadi bisa membutuhkan banyak jenis bahan baku dan satu jenis bahan baku bisa dibutuhkan untuk membuat banyak jenis produk jadi. Normalisasi lainnya tidak dibutuhkan karena semua entitas yang juga berlaku sebagai relasi (ditunjukkan dengan notasi persegi panjang dengan belah ketupat di dalamnya) sedah ada pada database DFD, sehingga hampir semua relasi (kecuali relasi kebutuhan) sedah memiliki kardinalitas 1-M.
Berikut ini adalah logical database design (LDM) yang dihasilkan dan ditransformasikan dari ERD pada subbab sebelumnya.
Gambar 2 Logical Database Model Sistem Informasi Logistik PT KKM Jaya
2.3.2 Physical Database Design
Tahap physical database design merupakan tahap dilakukannya proses pembangunan model data yang akan digunakan pada DBMS yang dipilih. Output dari tahap physical database design adalah rancangan tabel-tabel (nama field, tipe data, primary key, foreign key) dan file yang spesifik untuk suatu DBMS tertentu.
Field merupakan unit terkecil dari data yang sudah memiliki suatu makna tertentu; dimana kolom nama field disini berarti nama kelompok/grup dari unit data yang akan disimpan dalam tabel. Tipe data yang ada dalam suatu sistem basis data cukup banyak dan beragam, namun pada sistem basis data yang dikembangkan pada modul kali ini, hanya 4 tipe data yang digunakan, yaitu:
Counter : angka yang secara otomatis bertambah seiring bertambahnya data ke dalam sistem basis data, biasanya tipe data jenis ini digunakan untuk mengenerate kode unik atau ID suatu data.
VarChar : data yang berisi kumpulan dan gabungan huruf dan angka
Integer
: tipe data yang digunakan untuk menyimpan data yang berbentuk angka
Date Time : menunjukkan tanggal, bulan, dan tahun suatu waktu tertentu Dalam suatu physical data model (PDM) kita dapat melihat yang mana field yang menjadi primary key maupun
foreign key. Primary key merupakan kode unik yang menyatakan identitas pada sebuah record, sedangkan foreign key merupakan field yang menunjuk pada sekumpulan record yang terdapat pada tabel lain pada suatu sistem basis data.
Tabel 3 Tabel Pelanggan
Key Nama Field
Tipe Data
Keterangan
PK
ID Pelanggan
Counter
Primary key unik dari tabel pelanggan
Nama Pelanggan
Nama pelanggan yang melakukan transaksi Alamat Pelanggan
VarChar
VarChar
Alamat dari pelanggan
No Telp Pelanggan
VarChar
Nomor telepon pelanggan, jenis tipe varchar karena terdapat tanda “-“ yang memisahkan kode area dengan nomor telepon
Tabel 4 Tabel Supplier yang Bekerjasama
Key Nama Field
Tipe Data
Keterangan
PK
Primary key unik dari tabel supplier yang bekerjasama Nama Supplier
ID Supplier
Counter
Nama supplier yang melakukan hubungan kerjasama Alamat Supplier
VarChar
VarChar
Alamat dari supplier
No Telp Supplier
VarChar
Nomor telepon supplier, jenis tipe varchar karena terdapat tanda “-“ yang memisahkan kode area dengan nomor telepon
Tabel 5 Tabel Pengadaan Bahan Baku
Key Nama Field
Tipe Data
Keterangan
PK
ID Pengadaan
Counter
Primary key unik dari tabel pengadaan bahan baku
FK
ID Supplier
Integer
Foreign key dari tabel supplier
FK
ID Evaluasi Pengadaan
Integer
Foreign key dari tabel evaluasi pengadaan
FK
ID Bahan Baku
Integer
Foreign key dari tabel bahan baku
Jumlah Bahan Baku Diadakan
Integer
Jumlah bahan baku yang diadakan melalui kegiatan pengadaan bahan baku
Tanggal Pengadaan Date Time Tanggal dilakukannya pengadaan bahan baku
Tabel 6 Evaluasi Pengadaan
Key Nama Field
Keterangan PK
Tipe Data
ID Evaluasi Pengadaan
Primary key unik dari tabel evaluasi pengadaan Tanggal Evaluasi Pengadaan
Counter
Date Time Tanggal dilakukannya evaluasi pengadaan Hasil Evaluasi Pengadaan
Hasil evaluasi untuk pengadaan bahan baku Rekomendasi
VarChar
Rekomendasi perbaikan yang disarankan untuk kegiatan Pengadaan
Perbaikan
VarChar
pengadaan bahan baku
Tabel 7 Tabel Kebutuhan
Key Nama Field
Keterangan PK
Tipe Data
ID Kebutuhan
Counter
Primary key unik dari tabel kebutuhan
FK
ID Bahan Baku
Integer
Foreign key dari tabel bahan baku
FK
ID Produk Jadi
Integer
Foreign key dari tabel produk jadi
Kebutuhan Bahan Baku
Jumlah kebutuhan bahan baku tertentu untuk produk jadi per Produk Jadi
Integer
tertentu
Tabel 8 Tabel Bahan Baku
Key Nama Field
Keterangan PK
Tipe Data
ID Bahan Baku
Primary key unik dari tabel bahan baku Nama Bahan Baku
Counter
VarChar
Nama dari bahan baku
Stok Bahan Baku
Jumlah stok bahan baku yang tersedia di gudang Satuan
Integer
VarChar
Satuan ukuran dari bahan baku
Tabel 9 Tabel Barang Terkirim
Key Nama Field
Keterangan PK
Tipe Data
ID Barang Terkirim
Counter
Primary key unik dari tabel barang terkirim
FK
ID Produk Jadi
Integer
Foreign key dari tabel produk jadi
FK
ID Pelanggan
Integer
Foreign key dari tabel pelanggan
Tanggal Pengiriman Date Time Tanggal dilakukannya pengiriman barang Jumlah Barang Dikirim
Integer
JUmlah barang yang dikirimkan kepada pelanggan
FK
ID Evaluasi Distribusi
Integer
Foreign key dari tabel evaluasi distribusi
Tabel 10 Tabel Evaluasi Distribusi
Key Nama Field
Keterangan PK
Tipe Data
ID Evaluasi Distribusi
Primary key unik dari tabel evaluasi distribusi Tanggal Evaluasi Distribusi
Counter
Date Time Tanggal dilakukannya evaluasi distribusi Hasil Evaluasi Distribusi
Hasil evaluasi untuk distribusi produk jadi Rekomendasi
VarChar
Rekomendasi perbaikan yang disarankan untuk kegiatan Distribusi
Perbaikan
VarChar
distribusi produk jadi
Tabel 11 Tabel Produk Jadi
Key Nama Field
Keterangan PK
Tipe Data
ID Produk Jadi
Primary key unik dari tabel produk jadi Nama Produk Jadi
Counter
VarChar
Nama dari produk jadi
Stok Produk Jadi
Integer
Jumlah stok produk jadi yang tersedia di gudang
Tabel 12 Tabel Barang Pesanan
Key Nama Field
Tipe Data
Keterangan
PK
ID Barang Pesanan
Counter
Primary key unik dari tabel barang pesanan
FK
ID Produk Jadi
Integer
Foreign key dari tabel produk jadi
FK
ID Petugas
Integer
Foreign key dari tabel petugas
Tanggal Pemesanan Date Time Tanggal dilakukannya pemesanan barang Jumlah Barang Dipesan
Integer
Jumlah barang yang dipesan
Tabel 13 Tabel Staf
Key Nama Field
Tipe Data
Keterangan
PK
ID Staf
Counter
Primary key unik dari tabel staf
Nama Staf
VarChar
Nama lengkap staf
Jabatan
VarChar
Jabatan yang dipangku oleh staf terkait
Tabel 14 Tabel Gudang
Key Nama Field
Tipe Data
Keterangan
PK
ID Gudang
Counter
Primary key unik dari tabel gudang
Lokasi Gudang
VarChar
Lokasi tempat gudang berada
FK
PJ Gudang
Integer
Foreign key dari tabel staf
Kapasitas Gudang
Integer
Jumlah barang yang dapat ditampung oleh gudang
Tabel 15 Pengelolaan Inventory
Key Nama Field
Tipe Data
Keterangan
PK
ID Pengelolaan Inventory
Counter
Primary key unik dari tabel pengelolaan inventory
FK
ID Bahan Baku
Integer
Foreign key dari tabel bahan baku
FK
ID Gudang
Integer
Foreign key dari tabel gudang
FK
ID Produk Jadi
Integer
Foreign key dari tabel produk jadi
FK
ID Evaluasi Inventory
Integer
Foreign key dari tabel evaluasi inventory
Tabel 16 Tabel Evaluasi Inventory
Key Nama Field
Keterangan PK
Tipe Data
Primary key unik dari tabel evaluasi inventory Tanggal Evaluasi Inventory
ID Evaluasi Inventory
Counter
Date Time Tanggal dilakukannya evaluasi inventory Hasil Evaluasi Inventory
Hasil evaluasi untuk inventory di gudang Rekomendasi
VarChar
Rekomendasi perbaikan yang disarankan untuk kegiatan Inventory
Perbaikan
VarChar
inventory di gudang
Berikut ini merupakan hasil pembuatan physical data model (PDM) di Microsoft Visio.
Gambar 3 Physical Data Model Sistem Informasi Logistik PT KKM Jaya
2.4 Implementasi
Implementasi merupakan tahap terakhir dari perancangan sistem basis data. Tahap ini bersifat programming. Maksudnya adalah membangun aplikasi database menggunakan Database Management System (DBMS). DBMS merupakan perangkat lunak yang secara khusus digunakan untuk membuat, mengakses, mengontrol dan mengelola database. Pada kasus kali ini, digunakan perangkat lunak Microsoft Access.
Langkah-langkah yang harus dilakukan dalam membuat sebuah DBMS terutama Microsoft access adalah sebagai berikut:
1. Membuat tabel sebagai tampat penyimpanan data beserta primary key masing-masing tabel, dan relasi antar tabelnya
2. Membuat query yang digunakan untuk memanipulasi data
3. Membuat form yang digunakan untuk frontend aplikasi, secara umum untuk menampilkan data, menambah data, dll.
4. Membuat report yang digunakan untuk membuat laporan
5. Membuat macro yang digunakan untuk melakukan satu atau beberapa fungsi
6. Membuat switchboard yang digunakan untuk membangun aplikasi user interface Hal pertama yang dilakukan adalah membuat tabel. Tabel dibuat berdasarkan Entity Relationship Diagram
(ERD) yang telah dibuat sebelumnya. ERD tersebut ditunjukkan pada gambar berikut:
Gambar 4 ERD Sistem Logistik PT KKM Jaya
Setiap entitas dalam ERD kemudian digambarkan lebih lanjut dalam bentuk tabel, maka setiap entitas tersebut dipastikan merupakan sebuat tabel. Setiap entitas terdiri dari atribut yang kemudian digambarkan menjadi kolom-kolom yang ada di tabel. Pada ERD, terlihat bahwa terdapat 14 entitas, maka terdapat pula 14 tabel dibuktikan pada gambar berikut:
Gambar 5 Daftar Tabel Microsoft Access
Misalnya pada entitas Staf seperti ditunjukkan pada gambar berikut:
ID_staf 1
Staf Nama_petugas
Jabatan
Gambar 6 Entitas Staf dan Atributnya
Pada gambar di atas dapat terlihat bahwa entitas Staf terdiri dari tiga atribut, yaitu ID_Staf, Nama_petugas, dan Jabatan. Maka, tabel Staf terdiri dari kolom-kolom tersebut. Pada Microsoft Access dibuat sebuah tabel Staf, dengan terlebih dahulu menentukan jenis data dari setiap kolom tersebut. pada microsoft access field name terdiri dari ID_staf, Nama_petugasm dan Jabatan dengan jenis data masing masing atau Data Type secara berurut adalah Auto Number karena tergenerate langsung secara otomatis untuk ID_Staf, dan text untuk Nama_Staf dan Jabatan. Hal tersebut dapat dilihat pada design view Tabel_Staf seperti pada gambar berikut ini:
Gambar 7 Field Name dan Data Type (Design View) dari Tabel_Staf di Microsoft Access
Setelah setiap kolom dan jenis data ditentukan, selanjutnya adalah menentukan primary key dari tabel yang bersangkutan. Dipilih ID_Staf sebagai primary key, dari gambar sebelumnya dapat terlihat pada sebelah kiri
Field Name, yang terdapat gambar ikon kunci merupakan field name yang menjadi primary key. Kemudian dilakukan pengisian record pada tabel. Hal tersebut dapat dilakukan pada mode Datasheet View. Datasheet View pada Tabel_Staf dapat dilihat pada gambar berikut:
Gambar 8 Datasheet View pada Tabel_Staf
Setiap field name Nama_Staf dan Jabatan diisi manual sesuai database perusahaan, sedangkan field name ID_Staf akan otomatis terisi atau muncul ketika field name lain diisi. Setelah didapatkan tabel dengan record- nya, langkah selanjutnya adalah menentukan relasi dalam tabel. Relasi tabel ditentukan dengan merujuk pada ERD. Pada ERD dapat terlihat bahwa entitas Staf berhubungan langsung dengan entitas Gudang dan entitas Barang Pesanan seperti terlihat pada gambar di bawah ini:
ID_produk_jadi
ID_barang_pesanan
ID_staf
Barang
Tanggal_pemesanan
Pesanan
Jumlah_barang_dipesan
ID_gudang
PJ_gudang ID_staf
Lokasi_gudang
Kapasitas_gudang Nama_petugas
Gambar 9 Entitas Staf dan Entitas yang Berhubungan Langsung
Dari hubungan dalam ERD, diketahui bahwa hubungan kardinalitas antara entitas Staf ke entitas Gudang adalah one-to-many yang mana berarti entitas Staf memberikan Primary Key-nya sebagai Foreign Key pada entitas Gudang. Begitu juga pada hubungan kardinalitas entitas Staf ke entitas Barang Pesanan, yaitu one-to-many. Berarti entitas Staf juga memberikan Primary Key-nya sebagai Foreign Key pada entitas Barang Pesanan. Selanjutnya adalah menentukan foreign key mana pada entitas Barang Pesanan dan Gudang. Hal ini dapat dilakukan pada tahap penentuan relasi tabel. Relationship antara ketiga tabel dapat dilihat pada gambar berikut ini:
Gambar 10 Relationship antara Tabel_Staf dengan Tabel_Barang_Pesanan dan Tabel_Gudang
Gambar di atas menunjukkan relationship antara Tabel_Staf dengan Tabel_Gudang dan Tabel_Barang_Pesanan dan secara jelas atribut mana yang dijadikan Foreign Key dari Tabel_Gudang dan Tabel_Barang_Pesanan. Pada Tabel_Barang_Pesanan ID_Petugas merupakan Foreign Key yang merujuk pada Primary Key (ID_Staf) Tabel_Staf. Sedangkan pada Tabel_Gudang PJ_Gudang merupakan Foreign Key yang merujuk pada Primary Key Tabel_Staf.
Setelah didapatkan relasi seperti di atas, langkah selanjutnya adalah membuat Query. Query merupakan tampilan yang diinginkan dari sebuah database. Pada pembuatan query ini ditentukan field name apa saja yang ditunjukkan pada user interface nantinya. Selain itu ada pilihan tambahan jika ingin mengurutkan record berdasarkan salah satu field name. Pada kasus kali ini, jabatan diurutkan sesuai abjad. Aturan tersebut dapat dilihat pada Design Grid di Query.
Gambar 11 Design Grid pada Design View Query_Staf
Kemudian setelah dipilih aturan untuk mengurutkan record sesuai jabatan berdasarkan abjad, hasilnya tampak pada Datasheet View pada gambar di bawah ini:
Gambar 12 Datasheet View Query_Staf
Setelah didapatkan query dengan relasinya, kemudian langkah selanjutnya adalah membuat form yang digunakan untuk frontend aplikasi khususnya untuk menampilkan data, menambah data, dll. Pembuatan form ini dilakukan untuk dapat melakukan fungsi tambahan pada tabel dan setiap recordya. Hal ini memudahkan user untuk dapat mengolah data. Pada praktikum kali ini digunakan cara pembuatan form dengan metode blank form, sehingga praktikan dapat mendesain dan membuat sesuai kebutuhan yang dirasa user friendly. Pada kasus kali ini dibuat form untuk staf sehingga terlihat pada gambar sebagai berikut:
Gambar 13 Tampilan Form Staf
Gambar di atas adalah bentuk tampilan gambar ketika pertama kali Form Staf dibuka. Pada bagian sebelah kanan terdapat berbagai macam button yang dapat digunakan untuk mengolah data. Pada button add data, user dapat mengisi data baru apabila terdapat staf baru. Jika ingin melihat seluruh data, dapat dilihat dengan cara menekan button Lihat Data. Sedangkan jika terdapat data yang salah, dapat memilih berbagai record dengan pilihan button first record, previous record, next record, dan last record kemudian mengganti data yang ada di bagiannya masing masing sesuai fieldnya. Pada form staf di atas, dapat membuka first record, kemudian Gambar di atas adalah bentuk tampilan gambar ketika pertama kali Form Staf dibuka. Pada bagian sebelah kanan terdapat berbagai macam button yang dapat digunakan untuk mengolah data. Pada button add data, user dapat mengisi data baru apabila terdapat staf baru. Jika ingin melihat seluruh data, dapat dilihat dengan cara menekan button Lihat Data. Sedangkan jika terdapat data yang salah, dapat memilih berbagai record dengan pilihan button first record, previous record, next record, dan last record kemudian mengganti data yang ada di bagiannya masing masing sesuai fieldnya. Pada form staf di atas, dapat membuka first record, kemudian
Gambar 14 Command Button Wizard 1
Gambar 15 Command Button Wizard 2
Pembuatan button pada form dapat dilakukan dengan memilih berbagai command yang terdapat di command button wizard. Misalkan pada Button Save. Button tersebut digunakan untuk melakukan penyimpanan data atas record yang telah diedit. Jadi, dapat dipilih categories record operation, kemudian dipilih save record. Kemudian tampilan button yang muncul dapat dipilih antara berupa gambar atau berupa tulisan (text). Pada kasus kali ini dipilih berupa tulisan (text). Sedangkan untuk button lainnya mengikuti berdasarkan proses atau perintah apa yang diinginkan. Untuk empat tombol arah panah ke kanan dan ke kiri antara exit form dan lihat data, dipilih dari categories record navigation.
Setelah didapatkan form dengan berbagai proses, navigasi, dan lain lain, dibuat report. Report merupakan keluaran dari data-data yang sebelumnya telah dimasukkan pada form, serta digunakan untuk merepresentasikan hasil olahan data menjadi informasi yang siap dicetak. Pada kasus kali ini, dipilih metode pembuatan report dengan blank report. Sehingga report dari pengolahan data staf adalah sebagai berikut:
Gambar 16 Report Laporan_Staf
Bentuk laporan yang diinginkan harus terdapat cara agar langsung menuju menu utama, maka pada laporan di atas, terdapat button home. Setelah laporan staf didapatkan, kemudian dibuat switchboard. Switchboard yang dibuat memiliki tampilan seperti dua gambar di bawah ini:
Gambar 17 Tampilan Switchboard PT KKM Jaya sebagai Menu Utama
Setelah menu utama dibuat, kemudian dibuat switchboard lanjutan agar dari menu tersebut pengguna dapat menuju atau membuka laporan ataupun form yang dapat digunakan untuk mengolah data lebih lanjut, seperti menambahkan data ataupun mengedit data. Maka pada menu utama ditampilkan pilihan untuk dapat membuka form dan membuka report (laporan). Kemudian bentuk tampilan ketika yang dipilih adalah daftar form untuk dapat membuka form, sebagai berikut:
Gambar 18 tampilan switchboard 2
BAB 3 POIN ANALISIS
3.1 Analisis Pembuatan ERD
Entitiy Relationship Diagram (ERD) adalah salah satu jenis pemodelan data yang menggunakan notasi-notasi untuk menggambarkan entitas, atribut, dan relasi antar atribut yang dideskripsikan oleh data tersebut. Entitas pada ERD merupakan objek, orang, atau benda yang berada dalam lingkungan pengguna dalam organisasi yang datanya akan disimpan, dimana dalam hal ini organisasi yang dimaksud adalah PT KKM Jaya. Atribut merupakan karakteristik-karakteristik yang didefinisikan pada suatu entitas, sedangkan relasi merupakan hubungan asosiasi antara 2 entitas atau lebih.
Relasi yang terdapat pada suatu ERD terdiri dari 3 sifat, ada yang bersifat M-M (many to many), 1-M (one to many), dan 1-1 (one to one). Relasi yang bersifat many to many menggambarkan relasi antara satu entitas yang bisa berasosiasi dengan banyak entitas lainnya, dan begitu pula sebaliknya. Sedangkan relasi one to many menggambarkan relasi satu entitas yang bisa memiliki relasi dengan banyak entitas lainnya, sedangkan entitas lainnya hanya memiliki satu relasi terhadap entitas tersebut. Yang terakhir yaitu relasi one to one, dimana kedua entitas hanya memiliki masing-masing satu asosiasi dengan entitas yang berhubungan.
Proses transformasi dan pembuatan ERD dari DFD dilakukan pertama-tama dengan mengidentifikasi entitas- entitas mana saja yang akan dimasukkan pada ERD. Pada tahap pertama ini kami memasukkan seluruh database yang ada pada DFD level 1 yang telah dibuat pada modul sebelumnya. Selanjutnya kami mengidentifikasi hubungan-hubungan/relasi antar database tersebut. Pada tahap identifikasi relasi ini kami juga menentukan kardinalitas dari setiap relasi tersebut, apakah bersifat M-M, 1-M, atau 1-1. Untuk relasi yang masih bersifat M-M, relasi yang berada di antara kedua entitas tersebut kami jadikan sebagai entitas baru sehingga hubungan relasinya menjadi 1-M (ternormalisasi). Contoh normalisasi jenis ini ada pada entitas kebutuhan. Entitas kebutuhan awalnya merupakan relasi antara produk jadi dan bahan baku, namun karena satu bahan baku bisa menjadi kebutuhan bagi banyak produk jadi, dan satu produk jadi bisa membutuhkan banyak jenis bahan baku (relasi many to many), maka relasi kebutuhan dijadikan sebagai suatu entitas baru sehingga hubungan relasi yang terjadi adalah 1-M dan M-1.
Namun ada kalanya entitas sekaligus relasi (ditunjukkan dengan bentuk persegi panjang dengan belah ketupat di dalamnya) sudah menjadi database dalam DFD, sehingga pada proses pembuatan ERD kita tinggal menambahkan notasi belah ketupat yang menandakan bahwa entitas tersebut juga berfungsi sebagai relasi antara 2 entitas. Kasus seperti ini dapat dijumpai pada entitas barang terkitim, barang pesanan, pengelolaan inventory, dan pengadaan bahan baku.
Pada perancangan ERD ini juga dilakukan beberapa pengurangan entitas. Pengurangan entitas ini dilakukan pada dua database/entitas yang memiliki hubungan one to one dan memiliki atribut yang sama persis. Pengurangan entitas ini misalnya dilakukan pada penghilangan database supplier, kinerja distribusi, pemebelian, dan pesanan siap dikirim. DI samping pengurangan entitas, juga dilakukan penambahan entitas baru yang tidak ada pada DFD sebelumnya. Penambahan entitas ini dilakukan dengan tujuan untuk memperjelas hubungan relasional yang ada pada ERD. Penambahan entitas baru ini dilakukan misalnya pada entitas staf dan pelanggan. Yang terakhir, yaitu perubahan nama atau entitas. Perubahan nama ini dilakukan untuk menyesuaikan database dengan hubungannya dengan entitas lain. Contoh perubahan nama ini adalah perubahan dari kapasitas gudang menjadi gudang.
13412007 – 13412037 – 13412067 - 13412094
Langkah terakhir dari pembuatan ERD adalah menambahkan atribut-atribut yang sesuai pada setiap entitas yang ada. Pada setiap entitas juga harus ditentukan yang mana atribut yang merupakan primary key dan yang mana yang merupakan foreign key. Primary key merupakan kode unik yang menyatakan identitas pada sebuah record, sedangkan foreign key merupakan field yang menunjuk pada sekumpulan record yang terdapat pada tabel lain pada suatu sistem basis data. Berikut ini adalah hasil akhir dari ERD yang telah ternormalisasi dan telah dilengkapi dengan relasi, kardinalitas, dan atribut.
3.2 Analisis Teknik Normalisasi
Menurut (E.F. Codd, 1970) normalisasi adalah langkah-langkah sistematis untuk menjamin bahwa struktur database terbebas dari insertion, update dan deletion anomalies yang dapat menyebabkan hilangnya integritas data. Data anomalies dan data yang tidak konsisten tersebut merupakan
yang terkait dengan redundansi data yang tak terkendali. Redundansi data sangat tidak efisien dengan alasan sebagai berikut :
permasalahan-permasalahan
Terjadi pemborosan pada memori Update data pada setiap tabel sulit diakukan karena proses
pengerjaan harus dilakukan dua kali pada tabel yang berbeda Peluang kesalahan pada data semakin besar.
Jika data-data yang dirancang telah dilakukan proses normaliasi, maka akan ada beberapa keuntungan yang didapat, yakni :
1. Meminimalkan ukuran penyimpanan yang diperlukan untuk penyimpanan data.
2. Meminimalkan resiko inkonsistensi data pada basis data.
3. Meminimalkan kemungkinan anomali pembaruan.
4. Memaksimalkan stabilitas struktur data.
Secara teori, gambar di samping ini memperlihatkan tahapan – tahapan yang harus dilakukan untuk melakukan normalisasi. Penjelasan secara rincinya adalah sebagai berikut.
Bentuk Normal Pertama (1NF)
Bentuk normal pertama merupakan bentuk normal dengan lever terendah, dan diperlukan tahapan normalisasi berikutnya untuk
mencapai kelebih normalan dan keakuratan data. Syarat :
Gambar 19 Tahapan Normalisasi a. Tidak ada set atribut yang berulang atau bernilai ganda
b. Telah ditentukannya primary key untuk tabel atau relasi
c. Tiap atribut hanya memiliki satu pengertian
d. Tiap atribut yang dapat memiiki banyak nilai sebenarnya menggambarkan entitas atau relasi yang terpisah.
13412007 – 13412037 – 13412067 - 13412094
Gambar 20 Contoh Bentuk Normal Pertama
Bentuk Normal ke Dua (2NF)
Syarat :
a. Bentuk data telah memenuhi kriteria bentuk normal ke satu
b. Atribut bukan kunci(non-key attribute) haruslah memiliki ketergantungan fungsional sepenuhnya pada primary key
c. Jika ada ketergantungan parsial maka atribut tersebut harus dipisah pada tabel yang lain
d. Perlu ada tabel penghubung ataupun kehadiran foreign key bagi atribut yang telah dipisah tadi
Gambar 21 Contoh Bentuk Normal Kedua
Bentuk Normal ke Tiga (3NF)
Jika tabel telah berada dalam bentuk normal ke tiga ( Third Normal Form ) , maka tabel tersebut bisa dianggap cukup normal. Third Normal Form merupakan syarat minimum bagi sebuah desain tabel walaupun akan lebih baik jika juga memenuhi BCNF.
Syarat : 13412007 – 13412037 – 13412067 - 13412094
b. Atribut bukan kunci(non-key attribute) tidak boleh memiliki ketergantungan fungsional terhadap atribut bukan kunci lainnya. Seluruh atribut bukan kunci pada suatu relasi hanya memiliki ketergantungan fungsional terhadap primary key di relasi itu saja
Gambar 22 Contoh Bentuk Normal Ketiga
Bentuk normalisasi BCNF, 4, dan 5 tidak dibahas karena bentuk normalisasi ketiga sudah cukup memberikan desain tabel yang normal. Selain cara tersebut, terdapat satu cara lain yang lebih mudah dalam melakukan normalisasi, yakni dengan membuat entitas baru diantara dua entitas yang memiliki hubungan many-to-many. Entitas baru tersebut akan memiliki hubungan one-to-many dengan entitas-entitas yang ada di sekitarnya. Dalam modul ini, kami melakukan metode tersebut dalam melakukan proses normalisasi. Berikut ini beberapa proses normalisasi yang kami lakukan.
1. Normalisasi Entitas Pelanggan dan Produk Jadi
M Pelanggan
Dikirimkan
Produk Jadi
Gambar 23 Hubungan Pelanggan dan Produk Jadi Sebelum Normalisasi
Dalam gambar tersebut, terlihat bahwa satu pelanggan dapat dikirimkan banyak produk jadi dan satu produk jadi dapat dikirimkan ke banyak pelanggan. Untuk menghindari redundansi data, diperlukan satu entitas tambahan diantara kedua entitas tersebut, misalnya entitas Barang Terkirim, seperti digambarkan di bawah ini.
1 Pelanggan
Barang Terkirim
Produk Jadi
Gambar 24 Hubungan Pelanggan dan Produk Jadi Setelah Normalisasi
Entitas Barang Terkirim memiliki hubungan one-to-many dengan dua entitas lainnya, baik itu dengan pelanggan ataupun produk jadi. Satu pelanggan dapat dikirim banyak barang terkirim, namun satu barang terkirim hanya dapat dikirimkan kepada satu pelanggan. Begitu pula dengan satu produk jadi dapat menjadi banyak barang terkirim, tetapi satu barang terkirim hanya mengandung satu produk jadi. Penambahan entitas barang terkirim ini dapat menjadi salah satu cara normalisasi karena dapat mengurangi risiko terjadinya duplikasi data. Hal itu
13412007 – 13412037 – 13412067 - 13412094 13412007 – 13412037 – 13412067 - 13412094
2. Normalisasi Entitas Staf dengan Produk Jadi
M Staf
Memesan
Produk Jadi
Gambar 25 Hubungan Staf dan Produk Jadi Sebelum Normalisasi
Untuk menghindari redundansi data, cara normalisasinya dilakukan dengan penambahan entitas baru, yakni barang pesanan.
1 Staf
Barang Pesanan
Produk Jadi
Gambar 26 Hubungan Staf dan Produk Jadi Setelah Normalisasi
Hubungan many-to-many dapat dinormalisasi menjadi one-to-many sehingga satu staf dapat memesan banyak barang pesanan, sedangkan satu barang pesanan hanya ditujukan untuk satu staf. Satu produk jadi dapat menjadi banyak barang pesanan, namun satu barang pesanan hanya menunjukan satu produk jadi.
3. Normalisasi Produk Jadi dengan Bahan Baku
M Produk Jadi
Membutuhkan
Bahan Baku
Gambar 27 Hubungan Produk Jadi dan Bahan Baku Sebelum Normalisasi
Penambahan entitas kebutuhan adalah salah satu cara normalisasi entitas di atas, seperti gambar berikut ini.
1 Produk Jadi
Kebutuhan
Bahan Baku
Gambar 28 Hubungan Produk Jadi dan Bahan Baku Setelah Normalisasi
Dengan penambahan entitas kebutuhan, hubungan masing-masing entitasnya menjadi one-to-many. Dengan demikian, produk jadi dapat terjadi di banyak kebutuhan dan satu kebutuhan hanya mengandung satu produk jadi. Satu kebutuhan pun hanya memiliki satu jenis bahan baku dan satu bahan baku terdapat di banyak kebutuhan
4. Normalisasi Supplier yang Bekerja Sama dengan Bahan Baku
M Supplier yang Bekerja Sama
Memasok
Bahan Baku
Gambar 29 Hubungan Supplier yang Bekerja Sama dan Bahan Baku Sebelum Normalisasi
13412007 – 13412037 – 13412067 - 13412094
Hubungan many-to-many entitas tersebut dinormalisasi menjadi seperti berikut ini.
Supplier yang
1 Bekerja Sama
Pengadaan
Bahan Baku
Bahan Baku
Gambar 30 Hubungan Supplier yang Bekerja Sama dan Bahan Baku Setelah Normalisasi
Supplier yang bekerja sama terdapat di banyak pengadaan bahan baku, sedangkan satu pengadaan bahan baku hanya dipasok oleh satu supplier yang bekerja sama. Selain itu, satu pengadaan bahan baku hanya terdapat satu jenis bahan baku dan satu bahan baku terdapat di banyak pengadaan bahan baku.
5. Normalisasi Gudang dan Bahan Baku
M Gudang
Menyimpan
Bahan Baku
Gambar 31 Hubungan Gudang dan Bahan Baku Sebelum Normalisasi
Penambahan entitas pengelolaan inventory dapat menormalisasi entitas di atas.
Bahan Baku
Gambar 32 Hubungan Gudang dan Bahan Baku Setelah Normalisasi
Hubungan entitas tersebut menjadi one-to-many. Satu gudang bisa terdapat di banyak pengelolaan inventory, namun satu pengelolaan inventory hanya terdapat di satu gudang. Satu bahan baku pun bisa terdapat di banyak pengelolaan inventory, namun satu pengelolaan inventory hanya memiliki satu bahan baku.
6. Normalisasi Gudang dan Produk Jadi
M Gudang
Menyimpan
Produk Jadi
Gambar 33 Hubungan Gudang dan Produk Jadi Sebelum Normalisasi
Entitas tersebut dinormalisasi menjadi seperti berikut.
Produk Jadi
Gambar 34 Hubungan Gudang dan Produk Jadi Setelah Normalisasi