Modul 6 ppst 3 perancangan basis data

(1)

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

(2)

(3)

13412007 – 13412037 – 13412067 - 13412094 3

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 13412009

2. Hanna Octaviani 13412037

3. Della Rieza Ramdhani 13412067 4. Nadia Shafira Novarena 13412094

Dan menyetujui untuk dikumpulkan pada:

Hari : Jumat

Tanggal : 17 April 2015

Waktu : maksimal pukul 11.00 WIB

Bandung, 17 April 2015

Ahmad Ibrahim Fahmi

(4)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

Ahmad Ibrahim Fahmi / 13411051

13412007 – 13412037 – 13412067 - 13412094 4

(5)

13412007 – 13412037 – 13412067 - 13412094 5 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.1 Planning 2.2 Analysis 2.3 Design

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

(6)

(7)

13412007 – 13412037 – 13412067 - 13412094 7

DAFTAR ISI

LEMBAR PENGESAHAN ... 3

LEMBAR ASISTENSI ... 4

DAFTAR ISI ... 7

DAFTAR GAMBAR ... 9

DAFTAR TABEL ... 11

BAB 1 _{PENDAHULUAN ... 13}

1.1 _{Latar Belakang ... 13}

1.2 _{Tujuan ... 13}

1.2.1 Tujuan Umum ... 13

1.2.2 Tujuan Khusus ... 13

1.3 _{Flowchart Perancangan Basis Data ... 13}

BAB 2 _{PERANCANGAN BASIS DATA ... 17}

2.1 _{Planning ... 17}

2.2 _{Analysis ... 20}

2.3 _{Design... 22}

2.3.1 _{Logical Database Design ... 22}

2.3.2 _{Physical Database Design ... 24}

2.4 _{Implementasi ... 28}

BAB 3 _{POIN ANALISIS ... 37}

3.1 _{Analisis Pembuatan ERD ... 37}

3.2 _{Analisis Teknik Normalisasi ... 38}

3.3 _{Analisis Software DBMS ... 43}

3.4 _{Analisis Keterkaitan Antar Modul ... 45}

BAB 4 _{KESIMPULAN DAN SARAN ... 47}

4.1 _{Kesimpulan ... 47}

4.2 Saran ... 47

4.2.1 Saran untuk Praktikum ... 47

4.2.2 Saran untuk Asisten ... 47

DAFTAR PUSTAKA ... 49

(8)

(9)

13412007 – 13412037 – 13412067 - 13412094 9

DAFTAR GAMBAR

Gambar 1 Flowchart praktikum ... 15

Gambar 2 Logical Database Model Sistem Informasi Logistik PT KKM Jaya ... 23

Gambar 3 Physical Data Model Sistem Informasi Logistik PT KKM Jaya ... 27

Gambar 4 ERD Sistem Logistik PT KKM Jaya ... 29

Gambar 5 Daftar Tabel Microsoft Access ... 30

Gambar 6 Entitas Staf dan Atributnya ... 30

Gambar 7 Field Name dan Data Type (Design View) dari Tabel_Staf di Microsoft Access ... 31

Gambar 8 Datasheet View pada Tabel_Staf ... 31

Gambar 9 Entitas Staf dan Entitas yang Berhubungan Langsung ... 31

Gambar 10 Relationship antara Tabel_Staf dengan Tabel_Barang_Pesanan dan Tabel_Gudang ... 32

Gambar 11 Design Grid pada Design View Query_Staf ... 32

Gambar 12 Datasheet View Query_Staf ... 33

Gambar 13 Tampilan Form Staf ... 33

Gambar 14 Command Button Wizard 1 ... 34

Gambar 15 Command Button Wizard 2 ... 34

Gambar 16 Report Laporan_Staf ... 35

Gambar 17 Tahapan Normalisasi ... 38

Gambar 18 Contoh Bentuk Normal Pertama ... 39

Gambar 19 Contoh Bentuk Normal Kedua ... 39

Gambar 20 Contoh Bentuk Normal Ketiga ... 40

Gambar 21 Hubungan Pelanggan dan Produk Jadi Sebelum Normalisasi ... 40

Gambar 22 Hubungan Pelanggan dan Produk Jadi Setelah Normalisasi ... 40

Gambar 23 Hubungan Staf dan Produk Jadi Sebelum Normalisasi ... 41

Gambar 24 Hubungan Staf dan Produk Jadi Setelah Normalisasi ... 41

Gambar 25 Hubungan Produk Jadi dan Bahan Baku Sebelum Normalisasi ... 41

Gambar 26 Hubungan Produk Jadi dan Bahan Baku Setelah Normalisasi ... 41

Gambar 27 Hubungan Supplier yang Bekerja Sama dan Bahan Baku Sebelum Normalisasi ... 41

Gambar 28 Hubungan Supplier yang Bekerja Sama dan Bahan Baku Setelah Normalisasi... 42

Gambar 29 Hubungan Gudang dan Bahan Baku Sebelum Normalisasi... 42

Gambar 30 Hubungan Gudang dan Bahan Baku Setelah Normalisasi ... 42

Gambar 31 Hubungan Gudang dan Produk Jadi Sebelum Normalisasi ... 42

Gambar 32 Hubungan Gudang dan Produk Jadi Setelah Normalisasi ... 42

Gambar 33 Bagan Keterkaitan Antar Modul ... 45

(10)

(11)

13412007 – 13412037 – 13412067 - 13412094 11

DAFTAR TABEL

Tabel 1 Entitas ... 18

Tabel 2 Relasi Antar Entitas ... 19

Tabel 1 Tabel Pelanggan ... 24

Tabel 2 Tabel Supplier yang Bekerjasama ... 24

Tabel 3 Tabel Pengadaan Bahan Baku ... 24

Tabel 4 Evaluasi Pengadaan ... 25

Tabel 5 Tabel Kebutuhan ... 25

Tabel 6 Tabel Bahan Baku... 25

Tabel 7 Tabel Barang Terkirim ... 25

Tabel 8 Tabel Evaluasi Distribusi ... 25

Tabel 9 Tabel Produk Jadi ... 25

Tabel 10 Tabel Barang Pesanan ... 26

Tabel 11 Tabel Staf ... 26

Tabel 12 Tabel Gudang ... 26

Tabel 13 Pengelolaan Inventory ... 26

(12)

(13)

13412007 – 13412037 – 13412067 - 13412094 13

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

(14)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 14

input awal berupa data flow diagram (DFD) dari Divisi Logistik PT Kereta Kayu Mainan (KKM) Jaya yang didapatkan dari output modul sebelumnya. Data masukan awal ini kemudian diolah menjadi entitity relationship diagram (ERD). Tahapan berikutnya adalah kegiatan Asistensi 0 yang menjelaskan apa saja yang harus dikumpulkan pada pengumpulan awal pengolahan data. Selanjutnya praktikan memindahkan ERD yang telah dibuat ke dalam Visio, membuat tabel database, query, dan report, kemudian mengumpulkannya ke asisten untuk diperiksa dan diberikan feedback pada Asistensi 1.

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.

(15)

13412007 – 13412037 – 13412067 - 13412094 15

Start

Responsi Awal Praktikum

Sudah benar? Data Flow Diagram

Pembuatan Form

Pembuatan report untuk setiap query

Pembuatan query untuk setiap tabel

Pembuatan tabel database Asistensi 0 Pelatihan Pengoperasian

Microsoft Access

A

Pengumpulan Laporan Penyusunan Laporan

Melakukan Revisi

Stop

Belum

Sudah Asistensi 1

Pembuatan Entity Relationship Diagram (ERD)

Pengumpulan 1

Pembuatan Switchboard

Pengumpulan 2

(16)

(17)

13412007 – 13412037 – 13412067 - 13412094 17

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

(18)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 18

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.

(19)

13412007 – 13412037 – 13412067 - 13412094 19 pengadaan dan status pengadaan.

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

Entitas 1 Relasi Entitas 2 Sifat Relasi Penjelasan

Pelanggan Dikirimkan Produk Jadi M to M Satu pelanggan dapat dikirimkan banyak produk jadi dan satu produk 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. Staf Memimpin Gudang 1 to M 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

bekerja sama

Memasok Bahan Baku M to M Satu supplier yang bekerja sama dapat memasok berbagai jenis bahan baku. Satu jenis bahan baku pun dapat dipasok oleh banyak supplier yang bekerja sama. dilakukan satu kali evaluasi pengadaan.

(20)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 20

beragam jenis bahan baku. Satu jenis bahan baku pun dapat disimpan di 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

(21)

13412007 – 13412037 – 13412067 - 13412094 21 operasional. User Interface harus dirancang sedemikian rupa untuk memudahkan pengguna dalam mengoperasikan sistem informasi tersebut.

 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 Requirement Type

Explanation

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

(22)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 22

mahal

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 manyto 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.

(23)

(24)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 24

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 VarChar Nama pelanggan yang melakukan transaksi Alamat Pelanggan 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

PK ID Supplier Counter Primary key unik dari tabel supplier yang bekerjasama Nama Supplier VarChar Nama supplier yang melakukan hubungan kerjasama Alamat Supplier 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

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

(25)

13412007 – 13412037 – 13412067 - 13412094 25 Tabel 6 Evaluasi Pengadaan

PK ID Evaluasi Pengadaan Counter Primary key unik dari tabel evaluasi pengadaan Tanggal Evaluasi Pengadaan Date Time Tanggal dilakukannya evaluasi pengadaan Hasil Evaluasi Pengadaan VarChar Hasil evaluasi untuk pengadaan bahan baku Rekomendasi Perbaikan

Pengadaan

VarChar Rekomendasi perbaikan yang disarankan untuk kegiatan pengadaan bahan baku

Tabel 7 Tabel Kebutuhan

PK 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 per Produk Jadi

Integer Jumlah kebutuhan bahan baku tertentu untuk produk jadi tertentu

Tabel 8 Tabel Bahan Baku

PK ID Bahan Baku Counter Primary key unik dari tabel bahan baku Nama Bahan Baku VarChar Nama dari bahan baku

Stok Bahan Baku Integer Jumlah stok bahan baku yang tersedia di gudang

Satuan VarChar Satuan ukuran dari bahan baku

Tabel 9 Tabel Barang Terkirim

PK 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

PK ID Evaluasi Distribusi Counter Primary key unik dari tabel evaluasi distribusi Tanggal Evaluasi Distribusi Date Time Tanggal dilakukannya evaluasi distribusi Hasil Evaluasi Distribusi VarChar Hasil evaluasi untuk distribusi produk jadi Rekomendasi Perbaikan

Distribusi

VarChar Rekomendasi perbaikan yang disarankan untuk kegiatan distribusi produk jadi

Tabel 11 Tabel Produk Jadi

(26)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 26

Stok Produk Jadi Integer Jumlah stok produk jadi yang tersedia di gudang Tabel 12 Tabel Barang Pesanan

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

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

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

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

PK ID Evaluasi Inventory Counter Primary key unik dari tabel evaluasi inventory Tanggal Evaluasi Inventory Date Time Tanggal dilakukannya evaluasi inventory Hasil Evaluasi Inventory VarChar Hasil evaluasi untuk inventory di gudang Rekomendasi Perbaikan

Inventory

VarChar Rekomendasi perbaikan yang disarankan untuk kegiatan inventory di gudang

(27)

(28)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 28

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

(29)

(30)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 30

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:

Staf

Jabatan Nama_petugas

ID_staf

1

Gambar 6 Entitas Staf dan Atributnya

(31)

13412007 – 13412037 – 13412067 - 13412094 31

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:

Staf Gudang

ID_barang_pesanan ID_produk_jadi

ID_staf

Jumlah_barang_dipesan

Tanggal_pemesanan Barang

Pesanan

Kapasitas_gudang ID_gudang

Lokasi_gudang PJ_gudang

Jabatan Nama_petugas

ID_staf

M

1

1 M

(32)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 32

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

(33)

13412007 – 13412037 – 13412067 - 13412094 33

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

(34)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 34

jika ingin mengganti nama, hanya dengan mengganti nama “Anung” menjadi nama yang diinginkan, kemudian tinggal menekan button “Save”. Setelah itu, seluruh data dapat dilihat kembali pada “Lihat Data”.

Gambar 14 Command Button Wizard 1

Gambar 15 Command Button Wizard 2

(35)

13412007 – 13412037 – 13412067 - 13412094 35 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:

(36)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 36

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:

(37)

13412007 – 13412037 – 13412067 - 13412094 37

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.

(38)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 38

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 permasalahan-permasalahan yang terkait dengan redundansi data yang tak terkendali. Redundansi data sangat tidak efisien dengan alasan sebagai berikut :

 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 :

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.

(39)

13412007 – 13412037 – 13412067 - 13412094 39

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.

(40)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 40

a. Bentuk data telah memenuhi kriteria bentuk normal ke dua

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

Pelanggan Dikirimkan Produk Jadi

M M

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.

Produk Jadi

Pelanggan Barang Terkirim

1 M M ₁

Gambar 24 Hubungan Pelanggan dan Produk Jadi Setelah Normalisasi

(41)

13412007 – 13412037 – 13412067 - 13412094 41 terjadi karena entitas pelanggan dan produk jadi dapat langsung mengirimkan masing-masing primary key kepada entitas barang terkirim. Dengan begitu, entitas barang terkirim dapat menjadi penghubung antara keduanya.

2. Normalisasi Entitas Staf dengan Produk Jadi

Staf Memesan Produk Jadi

M M

Gambar 25 Hubungan Staf dan Produk Jadi Sebelum Normalisasi

Untuk menghindari redundansi data, cara normalisasinya dilakukan dengan penambahan entitas baru, yakni barang pesanan.

Produk Jadi Staf

1 M M ₁

Barang Pesanan

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

Produk Jadi Membutuhkan Bahan Baku

M M

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.

Bahan Baku Produk Jadi

1 _M _M ₁

Kebutuhan

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

Supplier yang

Bekerja Sama Memasok Bahan Baku

M M

(42)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 42

Hubungan many-to-many entitas tersebut dinormalisasi menjadi seperti berikut ini.

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

Gudang Menyimpan Bahan Baku

M M

Gambar 31 Hubungan Gudang dan Bahan Baku Sebelum Normalisasi

Penambahan entitas pengelolaan inventory dapat menormalisasi entitas di atas.

Bahan Baku Gudang

1 M M ₁

Pengelolaan Inventory

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

Gudang Menyimpan Produk Jadi

M M

Gambar 33 Hubungan Gudang dan Produk Jadi Sebelum Normalisasi

Entitas tersebut dinormalisasi menjadi seperti berikut.

Produk Jadi Gudang

1 _M _M ₁

Pengelolaan Inventory

Gambar 34 Hubungan Gudang dan Produk Jadi Setelah Normalisasi

(43)

13412007 – 13412037 – 13412067 - 13412094 43

3.3 Analisis Software DBMS

DBMS (Database Management System) adalah perangkat lunak khusus yang digunakan untuk membuat, mengakses, mengkontrol, dan mengelola sebuah database. Perangkat lunak yang digunakan pada praktikum kali ini adalah Microsoft Access, namun terdapat banyak perangkat lunak DBMS lain yang dapat digunakan. Setiap perangkat lunak memiliki kelebihan dan kekurangan masing-masing yang dapat dipertimbangkan untuk memilih perangkat lunak yang akan digunakan.

No. Nama Software

Deskripsi Kelebihan Kekurangan

1 Microsoft

 Adanya fasilitas untuk security data

 Dapat menyimpan data atau file dalam jumlah yang besar

 Aplikasi ini berbayar  Tidak begitu bagus jika

diakses melalui jaringan

 Program dapat running di semua OS, PHP MySQL berjalan secara web base  Sangat cocok dan mudah diterapkan pada komputer

 Data yang ditangani belum begitu besar

 Keterbatasan kemampuan kinerja dalam server ketika data yang disimpan melebihi  Mudah hang dan crash  Tidak multi user, apabila

sedang digunakan, tidak  Dapat bekerja di lingkungan

clien/server

 Menangani manajemen space dan basis data yang besar  Mendukung akses data secara

simultan

 DBMS yang paling rumit di dunia

 DBMS yang paling mahal di dunia

(44)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

Ahmad Ibrahim Fahmi / 13411051 4 FIREBIRD Sistem manajemen

basisdata

 Query Plan yang kurang optimize

 Built in function masih sedikit user bisa diatur hak aksesnya  Memiliki tingkat

 Hanya bisa berjalan pada satu platform system

 Simple dan mudah untuk digunakan

 Fitur lengkap untuk menunjang kebutuhan user  Mempunyai database sendiri

yaitu DBF

 Akses ke database internal mudah

 OOP murni sejak versi 6.0  Akses ke library eksternal

mudah

 Tidak memerlukan spesifikasi hardware yang tinggi

 Tidak tersedia tipe data pointer

 Tidak bisa digunakan untuk membuat OCX databae lagi saat Delphi sudah ada

 Data yang dihasilkan relatif kecil

 Mudah dicopy

 Cocok digunakan bagi pemula untuk belajar

 Gratis, tidak perlu dibeli  Cocok digunakan oleh desktop

single user

(45)

13412007 – 13412037 – 13412067 - 13412094 45 user

 Jika terjadi pemutusan arus listrik mendadak, data akan mengalami kerusakan fatal Berdasarkan kelebihan dan kekurangan setiap perangkat lunak yang telah dijabarkan diatas, dapat dipilih satu perangkat lunak yang paling cocok untuk digunakan dalam praktikum ini. Belum tentu program yang terbaik yang terpakai mengingat praktikan adalah pemula dalam program ini sehingga perlu program yang mudah untuk diguanakan. Permasalahan yang dibahas pada praktikum kali ini juga tidak begitu kompleks sehingga belum perlu digunakan perangkat lunak yang sangat canggih. Kelebihan-kelebihan perangkat lunak yang canggih mengakibatkan trade-off dengan biaya yang dikeluarkan. Dengan membandingkan kecanggihan perangkat lunak dan biaya yang harus dikeluarkan, perangkat lunak Microsoft Access adalah perangkat lunak yang dipilih untuk digunakan dalam praktikum ini.

3.4 Analisis Keterkaitan Antar Modul

Berikut ini bagan keterkaitan modul 6 dengan modul lainnya :

Gambar 35 Bagan Keterkaitan Antar Modul Modul 4

(46)

MODUL 6 PPST 3 : PERANCANGAN BASIS DATA

13412007 – 13412037 – 13412067 - 13412094 46

Gambar 36 Ouput Modul 4 - 6

Modul 5 Pemodelan Proses Bisnis merupakan bagian awal dari perancangan sistem informasi manajemen sederhana dalam sebuah perusahaan, termasuk PT. KKM Jaya. Modul 5 ini menghasilkan output berupa Context Diagram, Decomposition Diagram, dan DFD level 1 dan level 2. Output DFD tersebut digunakan untuk modul 6 Perancangan Basis Date sebagai input yang dibutuhkannya. DFD digunakan sebagai dasar acuan aliran data dari suatu entitas ke entitas lainnya serta database apa yang dibutuhkan pada perusahaan tersebut. Entitas yang ada di DFD kemudian ditransformasikan menjadi entitas yang ada di Entity Relationship Diagram (ERD) yang dibuat di modul ini dengan kondisi entitas yang ada di DFD tidak semua aka nada di ERD mengingat efisiensi sistem. Lalu, output dari modul ini akan menjadi input untuk modul 7 dalam pembuatan prototype sistem pendukung keputusan.

•Context Diagram •Decomposisition

Diagram •DFD Level 1 & 2

Output

Modul 5

•Entity Relationship Diagram (ERD)

Output

Modul 6

•Prototype sistem pendukung

keputusan

(47)

13412007 – 13412037 – 13412067 - 13412094 47

BAB 4

KESIMPULAN DAN SARAN

4.1 Kesimpulan

Perancangan sistem informasi terdiri dari 4 tahap, yakni planning, analysis, design, dan implementation. Planning adalah tahapan untuk mendetailkan aktivitas organisasi dan mengidentifikas entitas serta relasi antarentitasnya. Analysis adalah kegiatan untuk mempelajari situasi bisnis serta menentukan kebutuhan sistemnya. Design adalah tahapan transformasi antara analysis dan implementasi. Sedangkan implementasi adalah tahapan untuk membangun aplikasi database dengan Oravle, My SQL, MS SQL Server, dll.

Dalam merancang suatu sistem, diperlukan pula pemodelan data untuk mengorganisasikan dan mendokumentasikan data dari suatu sistem. Beberapa jenis pemodelan data adalah entity relationship model, logical data model, dan physical data model. Entity Relationship Diagram (ERD) terdiri dari beberapa entitas yang tidak boleh memiliki hubungan many-to-many serta terdapat atribut yang mampu menjelasan entitas tersebut. Logical data model adalah bentuk lain dari ERD yang ditampilkan dalam bentuk tabel. Physical Data Model juga memiliki bentuk yang mirip dengan logical data model, namun memiliki tipe data yang menjadi pembedanya.

Sistem informasi dirancang untuk dapat digunakan dengan mudah oleh para penggunanya. Untuk itu, diperlukan suatu user interface yang salah satunya dapat dibuat menggunakan Ms. Access. Aplikasi tersebut memerlukan minimal pembuatan tabel, form, dan switchboard untuk dapat membentuk suatu database yang dapat diolah oleh user. Semakin aplikatif dan mudah digunakan, maka user interface tersebut dinilai semakin baik.

4.2 Saran

4.2.1 Saran untuk Praktikum

Praktikum modul 5 ini sudah baik karena memberikan tutorial mengenai penggunaan Ms. Access. Namun, lebih baik jika diberikan tutorial pula mengenai detail syntax yang lainnya sehingga praktikan tidak terlalu meraba – raba untuk menggunakan Ms. Access tersebut. Untuk proses pembuatan DFD, LDM, dan PDM dirasa sudah dibimbing dengan baik.

4.2.2 Saran untuk Asisten

(48)

(49)

13412007 – 13412037 – 13412067 - 13412094 49

DAFTAR PUSTAKA

Asisten Laboratorium Sistem Informasi dan Keputusan (LSIK) ITB. Modul 6 PPST III: Perancangan Basis Data. Asisten Laboratorium Sistem Informasi dan Keputusan (LSIK) ITB. Modul 6 PPST III: Pengenalan Microsoft Access.

http://hariyadi0903.blogspot.com/2013/03/test_4564.html

http://brahmaputra7.blogspot.com/2014/05/basis-data-pengenalan-entity.html

http://id.wikipedia.org/wiki/Microsoft_Access

http://onie12018077.blogspot.com/2014/03/macam-macam-dbms-beserta-kelebihan-dan.html

http://rizkysql.blogspot.com/

https://arizius.wordpress.com/2011/03/23/tiga-perbedaan-mysql-oracle-firebird/

https://fadjarsinar.wordpress.com/2011/10/19/kelebihan-dan-kekurangan-visual-foxpro-9-0/

http://togibasthian.blogspot.com/2009/02/idef0.html

(50)