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