Contoh Laporan Tubes Basdat

LAPORAN
TI-3003 PRAKTIKUM PERANCANGAN SISTEM

TERINTEGRASI III
MODUL 6
Perancangan Basis Data
Kelompok 37
1. Mitha Dewi Apriliani 13414023

2. Silfia Nurul Ariyani 13414083
3. Bethari Bintang Oktavia 13414089
LABORATORIUM SISTEM INFORMASI DAN KEPUTUSAN

PROGRAM STUDI TEKNIK INDUSTRI
FAKULTAS TEKNOLOGI INDUSTRI
INSTITUT TEKNOLOGI BANDUNG
2017
Modul 6 PPST 3 : Perancangan Basis Data Hasbi Harbi Putra/13413014
2
13414023 – 13414083 – 13414089
LEMBAR PENGESAHAN
Asisten Laboratorium Sistem Informasi dan Keputusan (LSIK) yang bertandatangan di bawah ini mengesahkan
Laporan Praktikum Perancangan Sistem Terintegrasi III Modul 6: Perancangan Basis Data Kelompok 37 yang
beranggotakan:
1. Mitha Dewi Apriliani 13414023

2. Silfia Nurul Ariyani 13414082
3. Bethari Bintang Oktavia 13414089
Hari : Jumat
Tanggal : 14 April 2017
Waktu : 11.00 WIB
Bandung, 14 April 2017
Hasbi Harbi Putra.
13413014
3
13414023 – 13414083 – 13414089
4
13414023 – 13414083 – 13414089
Daftar Isi
LEMBAR PENGESAHAN ............................................................................................................................................ 3

Daftar Isi .................................................................................................................................................................. 5
Daftar Gambar ......................................................................................................................................................... 7
Daftar Tabel ............................................................................................................................................................. 8
BAB I – PENDAHULUAN ........................................................................................................................................... 9
1.1 Latar Belakang ............................................................................................................................................... 9
1.2 Tujuan Praktikum........................................................................................................................................... 9
1.2.1 Tujuan Umum ..................................................................................................................................... 9
1.2.2 Tujuan Khusus .................................................................................................................................... 9
1.3 Alur Praktikum ............................................................................................................................................. 10
BAB II – PERANCANGAN BASIS DATA .................................................................................................................... 12
2.1 Perencanaan ................................................................................................................................................ 12
2.2 Analisis ......................................................................................................................................................... 18
2.3 Desain .......................................................................................................................................................... 21
2.3.1 Logical Database Design ................................................................................................................. 21
2.3.2 Physical Database Design ............................................................................................................... 25
2.4 Implementasi ............................................................................................................................................... 28
BAB III - ANALISIS ................................................................................................................................................... 32
3.1 Analisis Pembuatan ERD .............................................................................................................................. 32
3.2 Analisis Kardinalitas pada ERD Hasil Normalisasi ........................................................................................ 32
3.3 Analisis Penentuan Atribut, Primary Key, dan Foreign Key ......................................................................... 37
3.4 Analisis Penentuan Tipe Data dan Nulitas ................................................................................................... 43
3.5 Analisis Teknik Normalisasi.......................................................................................................................... 44
3.6 Analisis Software DBMS ............................................................................................................................... 47
3.6.1 My SQL ................................................................................................................................................ 48
3.6.2 Oracle ................................................................................................................................................. 48
3.6.3 Microsoft Access ................................................................................................................................ 49
3.6.4 Firebird .............................................................................................................................................. 49
3.6.5 SQL Server .......................................................................................................................................... 49
3.6.6 IBM DB2 ............................................................................................................................................. 50
3.6.7 Visual Pro ........................................................................................................................................... 50
3.6.8 Clipper ................................................................................................................................................ 51
3.6.9 Postgre SQL ....................................................................................................................................... 51
3.7 Analisis Keterkaitan Antarmodul ................................................................................................................. 55
BAB IV - KESIMPULAN DAN SARAN ....................................................................................................................... 56
4.1 Kesimpulan .................................................................................................................................................. 56
4.2 Saran ............................................................................................................................................................ 56
5
13414023 – 13414083 – 13414089
4.2.1 Saran untuk Praktikum ............................................................................................................................. 56

4.2.2 Saran untuk Asisten .................................................................................................................................. 56
Daftar Pustaka ....................................................................................................................................................... 57
6
13414023 – 13414083 – 13414089
Daftar Gambar
Gambar 1 Alur Praktikum Modul 6 ........................................................................................................................ 11

Gambar 2 Tahap Planning ..................................................................................................................................... 12
Gambar 3 Simbol Entitas ....................................................................................................................................... 12
Gambar 4 Simbol Relasi ......................................................................................................................................... 14
Gambar 5 ERD Sebelum Normalisasi ..................................................................................................................... 17
Gambar 6 Tahap Analisis pada Perancangan Basis Data ....................................................................................... 18
Gambar 7 Tahap Desain pada Perancangan Basis Data ........................................................................................ 21
Gambar 8 Contoh ERD Sebelum Normalisasi ........................................................................................................ 22
Gambar 9 Contoh ERD Setelah Normalisasi .......................................................................................................... 22
Gambar 3 Logical data model ............................................................................................................................... 24
Gambar 11 Physical data model ............................................................................................................................ 27
Gambar 7 Tahap Implementasi ............................................................................................................................. 28
Gambar 8 Membuat database baru ...................................................................................................................... 29
Gambar 9 Membuat tabel baru ............................................................................................................................. 30
Gambar 10 Menambahkan primary key ................................................................................................................ 30
Gambar 11 Tabel Pesanan ..................................................................................................................................... 31
Gambar 12 Menambahkan foreign key ................................................................................................................. 31
Gambar 10 Hubungan Kardinalitas Produk dengan Pesanan ................................................................................ 35
Gambar 11 Kardinalitas Pesanan dengan Entitas Lain .......................................................................................... 35
Gambar 12 Kardinalitas Konsumen dengan Entitas Lain ....................................................................................... 36
Gambar 13 Hubungan Kardinalitas Strategi Penjualan dengan Entitas Lain. ........................................................ 37
Gambar 14 Proses Sebelum Normalisasi ............................................................................................................... 45
Gambar 15 Proses Setelah Normalisasi ................................................................................................................. 45
Gambar 16 Logo MySQL ........................................................................................................................................ 48
Gambar 17 Logo Oracle ......................................................................................................................................... 48
Gambar 18 Logo Microsoft Access ........................................................................................................................ 49
Gambar 19 Logo Firebird ....................................................................................................................................... 49
Gambar 20 Logo SQL Server .................................................................................................................................. 50
Gambar 21 Logo IBM DB2 ..................................................................................................................................... 50
Gambar 22 Logo Visual Pro ................................................................................................................................... 50
Gambar 23 Logo PostgreSQL ................................................................................................................................. 51
Gambar 24 Posisi Modul 6 dalam Sistem Manufaktur .......................................................................................... 55
7
13414023 – 13414083 – 13414089
Daftar Tabel
Tabel 1 Kebutuhan Fungsional .............................................................................................................................. 19

Tabel 2 Kebutuhan Non Fungsional....................................................................................................................... 20
Tabel 3 Entitas pada DFD dan ERD ........................................................................................................................ 32
Tabel 4 Analisis Penentuan Atribut, Primary Key, dan Foreign Key....................................................................... 37
Tabel 5 Hubungan Normalisasi Antarentitas ......................................................................................................... 44
Tabel 6 Tabel Konsumen Sebelum Normalisasi ..................................................................................................... 45
Tabel 7 Tabel Customer Service Sebelum Normalisasi .......................................................................................... 46
Tabel 8 Tabel Klaim Garansi Setelah Normalisasi .................................................................................................. 46
Tabel 9 Tabel Konsumen Setelah Simplifikasi ....................................................................................................... 46
Tabel 10 Tabel Customer Service Setelah Simplifikasi .......................................................................................... 46
Tabel 11 Kelebihan dan Kelemahan Tiap DBMS .................................................................................................... 51
8
13414023 – 13414083 – 13414089
BAB I – PENDAHULUAN
1.1 Latar Belakang

CV. Simba Smash Innovation adalah sebuah perusahaan di Bandung yang memproduksi tempat parkir sepeda
vertikal yang disebut rotating bike parking. Perusahaan ini adalah sebuah perusahaan start-up yang baru
berdiri dua tahun. Namun, meski begitu, perusahaan ini sudah mendapat pesanan dari beberapa pemilik usaha
mandiri yang membutuhkan parkiran sepeda dengan lahan yang sempit. Pelanggan CV. Simba SI tersebar baru
di sekitar Jakarta, Bandung, dan Semarang. Keunggulan produk CV. Simba SI mulai tersebar dari mulut ke mulut
hingga baru-baru pihak Institut Teknologi Bandung (ITB) meminta perusahaan untuk memproduksi rotating
bike parking dalam partai besar.
Dengan jenis produk yang masih tergolong baru dan inovatif ini, perusahaan mulai berani melakukan strategi
marketing hingga ke seluruh Indonesia. Oleh karena itu, dalam rangka melebarkan sayap, perusahaan saat ini
sedang merumuskan strategi pemasaran secara berkala. CV. Simba SI saat ini juga sedang gencar dalam
melakukan benchmark dan riset pasar untuk mengetahui celah pasar yang dapat disasar mengingat kini,
perusahan masih belum memiliki pelanggan loyal. Terlepas dari kelebihan inovasi yang dimiliki produk ini,
perusahaan juga harus memikirkan strategi yang tepat untuk memasarkan produk. Salah satunya, karena
adalah CV. Simba SI juga berusaha memberikan nilai tambah lain dengan mengelola customer relationship
dengan menawarkan layanan custom produk dan pelayanan aftersales berupa garansi maintenance produk
dalam periode tertentu.
Sistem informasi merupakan sistem yang menyediakan informasi untuk manajemen pengambilan keputusan
dan menjalankan operasional perusahaan, dimana sistem tersebut adalah kombinasi antara manusia, teknologi
informasi, dan prosedur-prosedur teroganisir. Sistem informasi perusahaan sangat bergantung pada proses
bisnis yang ada. Kegunaan informasi ini yaitu menyimpan aset, aliran informasi dan data dibutuhkan
perusahaan untuk menjalankan proses bisnisnya. Dengan visi CV. Simba Smash Innovation yang ingin menjadi
pionir produsen rotating bike parking di Indonesia pada tahun 2025, perusahaan harus membangun sistem
informasi dengan perancangan sistem informasi yang baik dan runtut. Sehingga, pada modul 6 Perancangan
Basis Data kali ini akan menjelaskan urutan dalam proses perancangan sistem informasi.
1.2 Tujuan Praktikum

Tujuan Praktikum Perancangan SIstem Terintegrasi III Modul 6 Perancangan Basis Data terbagi menjadi dua
jenis, yakni tujuan umum dan khusus.
1.2.1 Tujuan Umum
Tujuan umum Praktikum Perancangan SIstem Terintegrasi III Modul 6 Perancangan Basis Data yaitu :
 Memahami prinsip perancangan sistem informasi basis data
 Memahami proses desain basis data dengan menggunakan Entity Relationship Diagram (ERD), Logical
Data Model, dan Physical Data Model
 Mengimplementasikan model desain basis data dengan menggunakan SQL Server.
1.2.2 Tujuan Khusus
Tujuan khusus Praktikum Perancangan Sistem Terintegrasi III Modul 6 Perancangan Basis Data yaitu :
9
13414023 – 13414083 – 13414089
 Memahami dan mampu merancang Entity Relationship Diagram (ERD), Logical Data Model, dan
Physical Data Model
 Mampu merancang desain basis data yang dapat menyelesaikan persoalan manajerial dan
operasional.
1.3 Alur Praktikum

Praktikum Modul 6 PPST III diawali dengan responsi yang berisi tes awal dan penjelasan praktikum. Sebelum
melakukan praktikum, sebelumnya dilakukan pembuatan skenario yang nantinya akan dgunakan pada modul 6
dan modul 7. Kemudian dilanjutkan dengan praktikum dan asistensi 0 yang dilakukan pada hari yang berbeda,
kegiatan praktikum berisi penjelasan mengenai pembuatan database menggunakan software SQL serta
pembutan draft Entity Relationship Diagram (ERD). Setelah praktikum selesai, kemudian dilanjutkan dengan
pembuatan ERD pada visio, database, logical data model, serta physical data model pada SQL. Setelah itu
seluruh file dikumpulkan pada pengumpulan awal. Kemudian dilakukan asistensi 1 yang berisi pengecekan oleh
asisten dari seluruh data yang dibuat, jika masih terdapat error maka harus dilakukan pembuatan ulang, namun
jika sudah tidak terdapat error maka bisa dilanjutkna dengan pembuatan laporan. Kemudian seluruh kegiatan
praktikum diakhiri dengan pengumpulan akhir.
Berikut adalah diagram alir pelaksanaan praktikum Modul 6 Perancangan Basis Data:
10
13414023 – 13414083 – 13414089
A
Mulai
Pengumpulan awal
Responsi Modul 6
Pembuatan Asistensi 1
skenario
Apakah terdapat
Praktimum dan error ?
asistensi 0 Ya
Tidak
Pembuatan Entity
Data Flow Pembuatan laporan
Relationship
Diagram
Diagram (ERD)
Pembuatan Pengumpulan akhir

database di SQL
Selesai
Pembuatan Logical
Data Model
Pembuatan Physical
Data Model
Gambar 1 Alur Praktikum Modul 6
11
13414023 – 13414083 – 13414089
Modul 6 PPST 3 : Perancangan Basis Data Hasbi Harbi Puta/13413014
BAB II – PERANCANGAN BASIS DATA
2.1 Perencanaan
Berikut adalah tahapan di dalam perancangan sistem basis data :
Gambar 2 Tahap Planning
Dalam melakukan perancangan basis data terdapat beberapa tahapan, tahap yang pertama adalah planning.
Planning adalah tahapan yang dilakukan untuk mengidentifikasi permasalahan dalam organisasi dan
kemungkinan solusi sesuai dengan kebutuhan dan keinginan pengguna. Output dari tahap ini adalah enterprise
model. Model ini terdiri dari :
 Detail dari aktivitas organisasi

 Identifikasi entitas-entitas dan relasi di antara entitas-entitas tersebut (berupa ERD sederhana)
Terdapat beberapa aktivitas di dalam divisi pemasaran dan penjuualan CV. Simba Smash Innovation,
diantaranya merancang strategi pemasaran dan penjualan, mengelola riset pasar, mengelola cutomer
relationship, mengelola dsitribusi serta mengelola keuangan divisi tersebut. Setelah diketahui aktivitas apa saja
yang terdapat dalam divis tersebut, kemudian akan diidentifikasi entitas-entitas apa saja yang terdapat dalam
aktivitas tersebut. Entitas sendiri bisa berupa orang, objek, event atau konsep di dalam lingkungan pengguna di
dalam organisasi yang datanya akan disimpan. Entitas memiliki notasi persegi panjang seperti berikut :
Gambar 3 Simbol Entitas
Berikut adalah entitas-entitas yang ada di dalam aktivitas Divisi Pemasaran dan Penjualan CV. Simba Smash
Innovation :
12
13414023 – 13414083 – 13414089
1. Data Produk
Data produk merupakan entitas yang menyimpan data berkaitan dengan produk yang dihasilkan oleh
CV. Simba Smash Innovation yaitu produk rotating bike parking. Data yang disimpan antara lain adalah
kode produk, nama produk serta harga produk.
2. Data Tanggal Pengiriman
Data tanggal pengiriman merupakan entitas yang menyimpan data berkaitan dengan pengiriman
suatu produk yang dipesan oleh distributor. Data yang disimpan antara lain adalah ID pengiriman,
biaya kirim, alamat kirim, tanggal kirim serta estimasi tanggal sampai..
3. Data Petugas Gudang
Data petugas gudang merupakan entitas yang menyimpan data berkaitan dengan petugas gudang
yang melayani pesanan. Data yang disimpan antara lain adalah ID petugas gudang, nama petugas
gudang serta nomor telepon petugas gudang.
4. Data Distributor
Data distributor merupakan entitas yang menyimpan data berkaitan dengan data distributor yang
melakukan pemesanan. Data yang disimpan antara lain ID distributor, nama distributor, alamat
distributor serta nomor telepon distributor.
5. Data Kuesioner Preferensi
Data kuesioner preferensi merupakan entitas yang menyimpan data berkaitan dengan kuesioner yang
diisi oleh konsumen. Data yang disimpan antara lain ID kuesioner preferensi, preferensi desain serta
instansi.
6. Data Rekap Penjualan
Data rekap penjualan merupakan entitas yang menyimpan data berkaitan dengan rekapitulasi dari
transakasi pemesanan produk pada setiap wilayah dan periode. Data yang disimpan antara lain kode
rekapitulasi, periode, wilayah, jumlah penjualan, serta sumber informasi terbanyak.
7. Data Konsumen
Data konsumen merupakan entitas yang menyimpan data berkaitan dengan data konsumen. Data
yang disimpan antara lain ID konsumen, nama konsumen, alamat konsumen, email konsumen, serta
nomor telepon konsumen.
8. Data Customer Service
Data customer service merupakan entitas yang menyimpan data berkaitan dengan data customer
service yang melayani klaim garansi. Data yang disimpan antara lain ID customer service, nama
customer service, email customer service, serta nomor telepon customer service.
9. Data Petugas Bengkel
Data petugas bengkel merupakan entitas yang menyimpan data yang berkaitan dengan petugas
bengkel yang menangani kerusakan. Data yang disimpan antara lain adalah ID petugas bengkel, nama
petugas bengkel, alamat petugas bengkel, nomor telepon petugas bengkel serta email petugas
bengkel.
10. Data Wilayah Penjualan
Data petugas bengkel merupakan entitas yang menyimpan data yang berkaitan dengan wilayah
penjualan produk. Data yang disimpan antara lain adalah kode wilayah serta nama wilayah.
11. Data Strategi Penjualan dan Pemasaran
Data strategi penjualan dan pemasaran merupakan entitas yang menyimpan data yang berkaitan
dengan strategi penjualan dan pemasaran yang digunakan. Data yang disimpan antara lain adalah
kode strategi, target pasar, alokasi dana, media, serta kontrak media partner.
12. Data Salesman
13
13414023 – 13414083 – 13414089
Data salesman merupakan entitas yang menyimpan data yang berkaitan dengan salesman yang
ditugaskan pada wilayah penjualan tetentu. Data yang disimpan antara lain adalah ID salesman, nama
salesman, alamat salesman, nomor telepon salesman serta email salesman.
Relasi adalah asosiasi 2 atau lebih entitas, yang memiliki simbol seperti berikut :
Gambar 4 Simbol Relasi
Berikut adalah berbagai macam sifat pada relasi antar entitas :
 One to one
Digambarkan dalam E-R model : 1 1
 One to many
Digambarkan dalam E-R model : 1 M
 Many to many
Digambarkan dalam E-R model : 1 M
Dari seluruh entitas tersebut kemudian akan ditentukan relasi antar masing-masing entitas beserta kardinalitas
relasi tersebut.
No Entitas 1 Relasi Entitas 2 Kardinalitas Keterangan

1 Produk Dikirim pada Pengiriman One to many CV. Simba Smash Innovation
menerapkan suatu metode dimana jika
suatu pesanan memesan lebih dari satu
produk maka seluruh produk tersebut
tidak harus dikirim dalam waktu yang
sama, melainkan dapat dikirim pada
pengiriman yang berbeda.
2 Pengiriman Dikirim Petugas Many to one Setelah terdapat suatu pesanan, maka
gudang pesanan kemudian akan dikirim oleh
petugas gudang. Dimana satu petugas
gudang dapat melakukan banyak
pengiriman, sedangakan satu
pengiriman hanya dapat dilakukan oleh
seorang petugas gudang.
3 Produk Dipesan Distributor Many to many Satu jenis produk dapat dipesan oleh
banyak distributor, sebaliknya dalam
sekali pemesanan maka dsitributor
dapat memesan banyak jenis produk.
4 Produk Ditentukan Kuesioner One to many Dalam melakukan perancnagan suatu
preferensi produk, maka perussahaan harus
mencari tahu terlebih dahulu seperti
apa produk yang diinginkan oleh
14
13414023 – 13414083 – 13414089
konsumen. Oleh sebab itu terdapat

sebuah kuesioner preferensi yang berisi
preferensi desain produk dari
konsumen. Dalam pembuatan satu
produk dapat ditentukan oleh banyak
kuesioner preferensi.
5 Rekap Berisi Produk Many to many Setiap kali terdapat transaksi
penjualan pemesanan, perusahaan juga tidak lupa
melakukan rekap penjualan dari
transaksi tersebut. Sehingga dengn
rekap penjualan tersebut nantinya
dapat digunakan untuk menganalisis
penjualan produk setiap periodenya.
Dalam sebuah rekap penjualan dapat
berisi banyak jenis produk. Begitu juga
satu jenis produk dapat tercantum pada
banyak rekap penjualan.
6 Konsumen Mengisi Kuesioner One to many Konsumen sendiri dapat mengisi lebih
preferensi dari satu kuesioner preferensi.
7 Konsumen Mengajukan Customer Many to many Seorang konsumen berhak mengajukan
service sebuah klaim garansi kepada customer
service. Dimana seorang customer
service dapat melayani banyak
konsumen, dan konsumen pun dapat
dilayani oleh customer service yang
berbeda.
8 Petugas Menangani Konsumen Many to many Setelah diterima oleh customer service,
bengkel maka selanjutnya klaim garansi akan
ditangani oleh petugas bengkel, dimana
satu klaim garansi dapat berisi banyak
kerusakan dan dapat ditangani oleh
banyak petugas bengkel. Petugas
bengkel juga dapat menangani banyak
klaim garansi dari konsumen.
9 Strategi Ditentukan Kuesioner One to many Dalam merancang strategi penjualan
penjualan preferensi dan pemasaran, maka juga harus
dan berdasarkan dari suara konsumen yang
pemasaran berasal dari kuesioner preferensi.
Dimana satu strategi penjualan dan
pemasaran dapat berasal dari banyak
10 Strategi Diterapkan Wilayah Many to many Strategi penjualan dan pemasaran yang
penjualan di penjualan telah dibuat kemudian akan
dan diimplementasikan di berbagai wilayah
pemasaran penjualan. Dimana dalam satu wilayah
15
13414023 – 13414083 – 13414089
penjualan dapat menggunakan banyak

strategi.
11 Salesman Bertanggung Strategi One to many Karena setiap wilayah diterapkan
jawab penjualan strategi penjualan dan pemasaran,
dan maka harus terdapat salesman yang
pemasaran bertanggung jawab. Dimana satu
strategi penjualan dan pemasaran dapat
dipegang oleh banyak salesman.
16
13414023 – 13414083 – 13414089
Dari hasil tersebut maka dapat diperoleh Entitiy Relationship Diagram (ERD) sebagai berikut :
Pengiriman dikirim Petugas Gudang

M 1
M
1 M M M
dikirim pada Produk dipesan Distributor
menentukan Rekap Penjualan Customer Service
M
M 1 M M
Kuesioner
mengisi Konsumen ditangani oleh Petugas Bengkel
Preferensi
1 Strategi Penjualan 1 bertanggung M

menentukan Salesman
dan Pemasaran jawab
M
diterapkan di Wilayah Penjualan
Gambar 5 ERD Sebelum Normalisasi
17
13414023 – 13414083 – 13414089
2.2 Analisis
Setelah dilakukan proses planning pada perancangan sistem basis data di atas, langkah selanjutnya adalah
melakukan analisis seperti yang tercantum pada gambar di bawah ini.
Gambar 6 Tahap Analisis pada Perancangan Basis Data
Analisis merupakan tahapan yang menentukan spesifikasi dari sistem informasi yang dibutuhkan untuk
mendukung organisasi yang terdiri dari kegiatan berikut:
 Mempelajari situasi bisnis saat ini

 Menentukan kebutuhan sistem dan perbaikannya.
Terdapat dua jenis kebutuhan yang termasuk dalam kriteria pembuatan sistem basis data yaitu Functional
Requirement dan Nonfunctional Requirement.
Functional Requirement merupakan kebutuhan akan fungsi atau fitur yang harus ada dalam sistem informasi
untuk memenuhi kebutuhan bisnis dan diterima oleh user. Jenis kebutuhan functional terdiri dari:
1. User Interface Functional

2. Processing Requirements
3. Storage Requirements
4. Control Requirements
Penjelasan untuk masing-masing beserta implementasinya dalam divisi Pemasaran dan Penjualan dapat dilihat
di bawah ini.
18
13414023 – 13414083 – 13414089
Tabel 1 Kebutuhan Fungsional
Jenis
Kebutuhan Definisi Hubungan dengan divisi Penjualan dan Pemasaran
Fungsional
Divisi Penjualan dan Pemasaran membutuhkan
suatu sistem informasi yang dapat memfasilitasi
user untuk mendapatkan:
Kebutuhan pengguna
- Input berupa data produk, petugas bengkel,
sistem atau user akan
User Interface petugas gudang, konsumen, distributor, wilayah
1 input-output yang
Functional penjualan, salesman, customer service, dan
didukung sistem
informasi.
- Output berupa tanggal pengiriman, rekap
penjualan, strategi penjualan dan pemasaran, dan
alokasi zona pemasaran.
Spesifikasi kebutuhan
pemrosesan yang Pada divisi Pemasaran dan Penjualan, pemrosesan
diperlukan untuk yang dilakukan untuk mengubah input menjadi
Processing
2 melakukan semua output diantaranya adalah proses pemesanan,
Requirements
aktivitas yang terlibat perancangan strategi penjualan dan pemasaran dari
dalam transformasi input kuesioner, dan pengelolaan data klaim garansi
menjadi output
Sistem informasi divisi Penjualan dan Pemasaran
membutuhkan suatu sistem informasi yang dapat
Pengorganisasian, isi,
menyimpan data mengenai rekapan hasil penjualan
Storage dan ukuran basis data
3 dan rekapan hasil kuesioner preferensi pelanggan
Requirements dan prosedur untuk
serta berisi data yang sudah di-input oleh user
perawatannya
maupun data hasil output dan data proses untuk
digunakan dalam proses transformasi.
Sistem informasi divisi Penjualan dan Pemasaran
memiliki kebutuhan fungsional berupa akurasi,
validasi dan keamanan. Akurasi dan validasi didapat
Kebutuhan terkait
dengan memastikan input data berasal dari sumber
Control dengan akurasi, validitas,
4 yang akurat dan sesuai dengan kondisi perusahaan.
Requirements keselamatan, keamanan,
Keamanan bisa difasilitasi dengan pembatasan user
dan adaptabilitas.
yang dapat mengakses database hanya untuk staff
divisi yang memiliki wewenang mengubah isi
database.
Nonfunctional Requirement merupakan kebutuhan yang berkaitan dengan uraian fitur, karakteristik, dan
atribut sistem yang membatasi usulan solusi. Dalam menentukan kebutuhan nonfunctional digunakan tools
PIECES untuk mengelompokkan permasalahan, kesempatan, dan tujuan. Jenis kebutuhan nonfunctional terdiri
dari:
19
13414023 – 13414083 – 13414089
Tabel 2 Kebutuhan Non Fungsional
Jenis Kebutuhan
No. Definisi Hubungan dengan divisi Penjualan dan Pemasaran
Non-Fungsional
Kriteria kinerja yang Untuk mengakomodasi kondisi pasar dipengaruhi oleh

dibutuhkan sistem agar banyak faktor dan dinamis, maka sistem informasi yang
1 Performance
dapat memenuhi dibentuk harus responsif dan efisien sehingga strategi
kebutuhan user. pemasaran yang dihasilkan efektif
Kebutuhan informasi Informasi yang mengalir pada divisi ini harus bersifat
yang berhubungan akurat, real time, dan up to date. Hal ini penting karena
2 Information dengan user, seperti data tersebut akan dijadikan dasar pengambilan
konten, akurasi, keputusan strategi penjualan dan pemasaran yang tepat
timeline, dan format. sasaran.
Divisi ini membutuhkan aspek ekonomi sebagai bahan

Kebutuhan sistem untuk
pertimbangan dalam penentuan strategi penjualan dan
3 Economy mengurangi ongkos dan
pemasaran beserta langkah implementasinya agar terjadi
meningkatkan profit
peningkatan penjualan.
Aspek pengawasan dan kontrol ini penting karena banyak

Lingkungan dimana basis data yang merupakan rahasia perusahaan,
sistem akan beroperasi contohnya adalah data penjualan, data pribadi konsumen,
Control and
4 beserta tingkat dan jenis distributor, serta karyawan. Akses khusus hanya akan
Security
keamanan yang harus diberikan pada staff tertentu yang bertanggung jawab
disediakan atas pengolahan datanya sehingga dapat mengurangi
kemungkinan data bocor yang merugikan perusahaan.
Adanya sistem informasi diharapkan dapat memangkas

Kemampuan sistem waktu yang biasanya digunakan untuk transfer data
dalam menghasilkan menjadi lebih cepat. Selain itu, efisiensi dalam sistem
5 Efficiency
output dengan waste informasi digunakan dalam pemilihan alternatif strategi
minimum. dengan nilai penjualan tertingi dengan nilai investasi
minimum
Sistem informasi dari divisi ini akan digunakan oleh semua

Kebutuhan agar sistem pihak yang terkait seperti staff, manager, dan direktur
6 Service tepercaya, fleksibel, dan utama, sehingga dibutuhkan standarisasi penggunaan
expandable. sistem agar memberikan kenyamanan bagi pengguna
yang sedang mengaksesnya.
20
13414023 – 13414083 – 13414089
2.3 Desain
Setelah dilakukan proses analysis pada perancangan sistem basis data di atas, langkah selanjutnya adalah
melakukan perancangan (desain) seperti yang tercantum pada gambar di bawah ini.
Gambar 7 Tahap Desain pada Perancangan Basis Data
Tahap desain merupakan tahapan dalam mentransformasikan konseptual data model menjadi implementation
model untuk DBMS tertentu. Terdapat dua tahapan, yaitu Logical Database Design (LDD) dan Physical
Database Design (PDD).
2.3.1 Logical Database Design
Logical Database Design (LDM) merupakan proses pembuatan model informasi berdasarkan model data yang
rinci dan spesifik, sedangkan Logical Data Model (LDM) merepresentasikan DAN mendokumentasikan entitas-
entitas yang ada pada database untuk digunakan oleh system designer.
Dalam pemodelan data menggunakan ERD, masing-masing entitas yang memiliki atribut kemudian akan
didefinisikan relasinya dengan entitas-entitas lainnya. Pada tahap Logical Database Design ini kemudian
dilakukan proses normalisasi. Normalisasi merupakan proses transformasi menjadi struktur data yang lebih
kecil dan stabil. Tujuan normalisasi antara lain:
1. Menghindari terjadinya asinkronisasi (tidak sinkron) data pada saat di-update

2. Menghindari redundansi data karena update bersifat otomatis di seluruh data terkait (tidak perlu
mengubah tabel satu-satu)
3. Mengurangi risiko pemborosan memori
4. Meningkatkan efektivitas serta kecepatan akses
Normalisasi sangat krusial dalam perancangan ERD. Hal ini dapat dilihat pada contoh berikut.
Sebelum adanya normalisasi, hubungan kardinalitas yang terbentuk adalah many to many, yang artinya banyak
produk dapat dipesan oleh banyak distributor. Hal ini dapat menyebabkan adanya redudansi data, dimana satu
data yang sama disimpan dalam dua database berbeda. Penyimpanan yang redundan ini dapat menyebabkan
adanya inconsistency data atau anomali data. Inconcistency dan anomali ini dapat terjadi karena adanya
ketidaksesuaian data yang sama pada database yang berbeda.
21
13414023 – 13414083 – 13414089
No. Telepon
ID Distributor
DIstributor
Kode Produk
Nama Alamat
Nama Produk Harga Distributor Distributor
M M M
Produk dipesan Distributor
Gambar 8 Contoh ERD Sebelum Normalisasi
Setelah melalui proses normalisasi maka ERD-nya menjadi seperti ini:
No. Telepon
ID Pengiriman (FK) ID Distributor
DIstributor
Total
Kode Produk Pembayaran Kode Rekapitulasi Nama Alamat
Kode Produk Tanggal (FK) Distributor Distributor
(FK)
ID Pesanan (FK) Pemesanan
Nama Produk Harga Kode Order ID Petugas Sumber Informasi
Total Harga Gudang (FK)
Jumlah ID Distributor
(FK)
ID Pesanan
1 M Produk yang M 1 M 1
Produk Pesanan Distributor
Dipesan
Gambar 9 Contoh ERD Setelah Normalisasi
Pada kasus di atas dilakukan dua kali proses normalisasi. Entitas Produk yang Dipesan berisi distributor beserta
masing-masing pesanannya (seperti bill), sedangkan pada entitas Pesanan berisi daftar seluruh pesanan dari
seluruh distributor. Oleh karena itu, pada entitas Produk yang Dipesan terdapat atribut Kode Produk sebagai
foreign key dari primary key Kode Produk pada entitas Produk dan juga atribut ID Pesanan sebagai foreign key
dari primary key entitas Pesanan. Pada entitas Pesanan juga terdapat atribut ID Ditributor yang menjadi foreign
key dari primary key entitas Distributor.
Kardinalitas yang terhubung di antara entitas juga berubah menjadi sebagai berikut:
- Satu produk akan dapat tercatat pada banyak Produk yang Dipesan dan Produk yang Dipesan hanya
dapat mencatat satu produk sehingga kardinalitasnya bersifat one to many.
- Satu macam Produk yang Dipesan hanya tercatat pada satu data Pesanan dan pada satu data Pesanan
tercatat banyak Produk yang Dipesan sehingga kardinalitasnya menjadi many to one.
- Satu data Pesanan hanya akan tercatat pada satu Distributor dan satu Distributor dapat melakukan
banyak pesanan sehingga kardinalitasnya menjadi many to one.
Setelah melakukan normalisasi pada seluruh relasi antar entitas, kemudian perancangan LDM dapat dilakukan.
Berikut akan dijabarkan langkah dalam melakukan perancangan LDM pada SQL Server:
1) Klik kanan pada Database Diagram, kemudian pilih New Database Diagram
2) Block semua nama tabel kemudian klik Add
22
13414023 – 13414083 – 13414089
3) Semua tabel akan ditampilkan dalam bentuk logical data model. Layout LDM dapat diatur sendiri.
Berikut adalah LDM yang terbentuk dari aliran data pada divisi Penjualan dan Pemasaran.
23
13414023 – 13414083 – 13414089
Pengiriman
[ID Pengiriman]
[Alamat kirim]
[Tanggal Kirim]
[Estimasi Tanggal Sampai]
Petugas Gudang Distributor
[Biaya Pengiriman]
[ID Petugas Gudang] [ID Distributor]
[ID Petugas Gudang]
[Nama Petugas] [Nama Distributor]
[No. Telepon Petugas] [No. Telepon Distributor]
[Alamat Distributor]
Rekap Penjualan
Pesanan [Kode Rekap Penjualan]
Produk yang Dipesan [ID Pesanan]
Wilayah
Produk [Kode Order] [ID Distributor]
Periode
[Kode Produk]
[Kode Produk] [Kode Rekap Penjualan]
[Jumlah Penjualan]
[Nama Produk] [ID Pesanan] [Tanggal Pemesanan]
[Sumber Informasi Terbanyak]
[Harga Satuan] Jumlah [Total Pembayaran]
[Total Harga] [Sumber Informasi]
[ID Pengiriman]
Data Kerusakan
[Kode Kerusakan]
Customer Service Klaim Garansi [Jenis Kerusakan]
[ID CS] [ID Klaim] [Jumlah Kerusakan]
[Nama CS]
[ID Konsumen] [ID Klaim]
[Email CS]
[ID CS] [ID Petugas]
[No. Telepon CS]
Klaim
Salesman
[ID Salesman]
[Nama Salesman]
[No. Telepon Salesman]
[Alamat Salesman]
[Email Salesman]
Kuesioner Preferensi [ID Alokasi]
[ID Preferensi] Konsumen Petugas Bengkel

Domisili [ID Konsumen] [ID Petugas]
Instansi [Nama Konsumen] [Nama Petugas]
[Preferensi Desain] [No. Telepon Konsumen] [No. Telepon Petugas]
[ID Konsumen] [Email Konsumen] [Alamat Petugas]
[Kode Strategi] [Alamat Konsumen] [Email Petugas] Strategi Pemasaran dan Penjualan
[Kode Produk] [Kode Strategi]
Strategi
Media
[Kontak Media] Alokasi Zona Pemasaran Wilayah Penjualan
[Alokasi Dana] [ID Alokasi]
[Kode Wilayah]
[Kode Rekap Penjualan] [Kode Strategi]
[Nama Wilayah]
[Target Pasar] [Kode Wilayah]
Gambar 10 Logical data model

24
13414023 – 13414083 – 13414089
2.3.2 Physical Database Design
Physical database design merupakan tahap yang mentranslasikan logical model menjadi statement yang akan
dieksekusi untuk membangun database. Pada tahap ini akan ditentukan mengenai bagaimana user akan
mengakses database. Di tahap ini juga dilakukan analisis ulang megenai perlunya denormalisasi relasi untuk
meningkatkan performance. Selain itu kita juga perlu menentukan modul-modul, hardware, dan software yang
diperlukan untuk membangun database. Output dari tahap ini adalah physical data model, yang didapatkan
dari hasil pengolahan LDM. PDM menampilkan model secara lebih detail, yatu dengan menampilkan tipe data
dari semua atribut pada setiap entitas. PDM juga menampilkan primary key dan foreign key di tiap tabel. PDM
dibutuhkan oleh system builder. Karena tahap berikutnya adalah pembangunan sistem, PDM dibutuhkan untuk
memberi acuan kepada system builder mengenai database yang perlu dibangun dan apa saja kontennya.
Untuk membuat PDM diperlukan tahap-tahap berikut:
1) Block semua tabel yang ada pada diagram LDM

2) Klik kanan kemudian pilih Modify Custom.
3) Kemudian akan muncul dialog sebagai berikut.
4) Pilih informasi apa saja yang ingin ditampilkann, klik > untuk memindahkan kolom ke bagian Selected
columns. Untuk membuat physical data model, keterangan yang dibutuhkan adalah nama kolom dan
tipe data. Jadi yang harus dilakukan adalah memindahkan kedua kolom tersebut ke bagian Selected
Diagram akan menampilkan data physical data model yang mencnatumkan keterangan nama kolom
25
13414023 – 13414083 – 13414089
dan tipe datanya untuk masing-masing tabel. Berikut ini merupakan physical data model dari
pengelolaan pemasaran dan penjualan CV. SSI.
26
13414023 – 13414083 – 13414089
Gambar 11 Physical data model
27
13414023 – 13414083 – 13414089
2.4 Implementasi
Setelah physical data model dibuat, langkah selanjutnya adalah implementasi. Dalam perancangan basis data,
implementasi terletak pada posisi berikut:
Gambar 12 Tahap Implementasi
Implentasi merupakan tahap dalam perancangan basis data di mana physical data model mulai dibangun
menjadi suatu program. Pada tahap ini biasanya digunakan bantuan aplikasi DBMS seperti Microsoft SQL
Server Management, Oracle, Microsoft Access, atau MySQL. Pada praktikum ini aplikasi yang digunakan adalah
Microosoft SQL Server Management 2012. Langkah-langkah yang dilakukan untuk membangun basis data
menggunakan Microsoft SQL Server Management adalah sebagai berikut.
1) Membuat database
Database merupakan sekumpulan file yang memiliki relasi logis yang didesain untuk memenuhi
kebutuhan suatu organisasi. Software Microsoft SQL Server Management memungkinkan kita untuk
membuat beberapa database. Cara untuk membuat database baru adalah dengan klik kanan pada
Databases kemudian pilih New Database. Maka akan muncul dialog sebagai berikut:
28
13414023 – 13414083 – 13414089
Gambar 13 Membuat database baru
Pada field Database name diisi dengan nama database. Untuk praktikum ini database yang dibuat
bernama Pemasaran dan Penjualan CV. SSI.
2) Membuat tabel
Pada Microsoft SQL Server Management entitas direpresentasikan dalam tabel. Kolom-kolom pada
tabel tersebut merupakan atribut dari entitas. Unutk membuat tabel pada Microsoft SQL Server
Management langkah yang perlu dilakukan adalah klik kanan pada Table, kemudian pilih New Table.
Setelah itu kita perlu mengisi nama tabel sesuai entitas yang kita tentukan.
29
13414023 – 13414083 – 13414089
Gambar 14 Membuat tabel baru
Langkah selanjutnya adalah membuat kolom-kolom sesuai dengan atribut pada entitas tersebut.
Selain menentukan nama atribut, kita juga menentukan tipe data untuk atribut tersebut dan
bagaimana nullity-nya, apakah atribut tersebut dapat memiliki nilai null atau tidak. Untuk setiap tabel
perlu ditentukan pula primary key-nya, yang berfungsi sebagai identitas untuk masing-masing record.
Untuk menambahkan primary key, klik kanan pada nama kolom primary key kemudian pilih Set
Primary Key.
Gambar 15 Menambahkan primary key
30
13414023 – 13414083 – 13414089
Gambar 16 Tabel Pesanan
3) Menentukan foreign key

Langkah selanjutnya adalah menentukan foreign key setiap tabel (jika ada). Foreign key
menghubungkan setiap tabel sehingga terbentuk hubungan yang sesuai dengan yang ada pada
physical data model. Untuk menentukan foreign key, langkah yang harus dilakukan adalah klik kanan
pada Keys kemudian pilih Add Foreign Key. Kemudian klik bagian Tables And Columns Specification
dan akan muncul dialog sebagai berikut.
Gambar 17 Menambahkan foreign key
4) Mengisi record
Record adalah sekumpulan field yang terhubung secara logis yang mendeskripsikan seseorang, sebuah
tempat, atau suatu hal lain. Untuk mengisikan record ke dalam tabel langkah yang dilakukan adalah
klik kanan pada nama tabel kemudian pilih Edit Top 200 Rows. Lalu kita dapat menginput atau
mengedit record pada tabel.
31
13414023 – 13414083 – 13414089
BAB III - ANALISIS
3.1 Analisis Pembuatan ERD

ERD merupakan salah satu bentuk model data yang menggambarkan hubungan antar entitas. Pembuatan ERD
dalam perancangan basis data didasarkan pada DFD yang telah dibuat sebelumnya. Dari DFD didapatkan aliran
data antar entitas eksternal. Sedangkan ERD menggambarkan database apa saja yang diperlukan untuk
membuat suatu sistem informasi. Oleh karena itu perlu diketahui hubungan antar entitas yang ada pada sistem
informasi tersebut.
Pembuatan ERD dimulai dengan menentukan entitas yang terlibat dalam sistem informasi. Sebelumnya di DFD
sudah ditentukan entitas eksternal yang terkait. Entitas eksternal tersebut perlu diidentifikasi apakah perlu
untuk dibuat database atau tidak. Selain entitas eksternal dari DFD juga perlu diidentifikasi entitas apa saja
yang perlu disimpan dalam database. Berikut ini merupakan entitas yang terdapat pada DFD dan ERD.
Tabel 3 Entitas pada DFD dan ERD
DFD ERD
-Konsumen -Konsumen
-Distributor -Distributor
-Salesman -Salesman
-Petugas bengkel -Petugas bengkel
-Manager Pemasaran -Produk
-Manager Penjualan -Pengiriman
-CEO -Petugas gudang
-Manager Perancangan -Strategi penjualan dan
Produksi dan Sistem pemasaran
Produksi -Rekap penjualan
-Manager Perencanaan dan -Wilayah penjualan
Pengadaan Produksi -Kuesioner preferensi
-Manager Audit -Customer service
-Manager Planning and
budgeting
-Manager HR Management
Dari tabel di atas dapat dilihat bahwa terdapat beberapa entitas yang ada di DFD maupun ERD. Akan tetapi ada
juga entitas pada DFD yang tidak dicantumkan di ERD, misalnya Manager Pemasaran dan Manager Penjualan.
Hal tersebut karena kedua entitas tersebut hanya merupakan entitas eksternal yang memberi atau menerima,
tetapi tidak perlu dibuat database. Setelah menentukan entitas, kita perlu menentukan relasi yang
menghubungkan antar entitas. Ada kalanya suatu relasi menimbulkan hubungan many to many, sehingga akan
dibentuk entitas asosiatif. Pengiriman merupakan salah satu entitas asosiatif yang menghubungkan antara
produk dengan petugas gudang. Setelah dinormalisasi, ERD memiliki entitas sebagai berikut:
32
13414023 – 13414083 – 13414089
Tabel 4 Entitas setelah normalisasi
ERD
-Konsumen
-Distributor
-Salesman
-Petugas bengkel
-Produk
-Produk yang dipesan
-Pesanan
-Strategi penjualan dan
pemasaran
-Pengiriman
-Petugas gudang
-Rekap penjualan
-Alokasi zona pemasaran
-Wilayah penjualan
-Kuesioner preferensi
-Klaim garansi
-Data kerusakan
-Customer service
Berikut ini merupakan relasi antar entitas setelah dinormalisasi:
Tabel 5 Tabel relasi pada ERD
Entitas Keterangan
Produk dengan Produk yang Produk yang Dipesan menunjukkan jumlah produk yang dipesan dalam
Dipesan satu transaksi. Produk yang DIpesan merupakan entitas asosiatif hasil
normalisasi antara Produk dengan Pesanan.
Produk yang Dipesan dengan Dalam satu pesanan, distributor dapat memesan lebih dari satu jenis
Pesanan produk, oleh karena itu entitas Produk yang Dipesan mencantumkan
data terperinci mengenai jumlah masing-masing jenis produk yang
dipesan dalam satu pesanan. Entitas Pesanan juga merupakan hasil
normalisasi awal antara entitas Produk dengan Distributor.
Pesanan dengan Distributor Entitas Pesanan memiliki relasi ‘dipesan’oleh Distributor. Distributor
dapat melakukan banyak pesanan untuk CV. Simba SI.
Produk yang Dipesan dengan Pesanan Distributor akan dikirimkan oleh CV. SSI dan bias jadi dikirimkan
Pengiriman dalam beberapa pengiriman apabila pemesanan dalam jumlah besar.
Oleh karena itu diperlukan entitas Pengiriman yang menunjukkan data
terkait kegiatan pengiriman pesanan. Entitas Pengiriman memiliki relasi
dengan entitas Produk yang Dipesan karena di entitas itulah terdapat
keterangan mengenai jenis produk apa yang dipesan.
Pengiriman dengan Petugas Setiap kegiatan pengiriman ditangani oleh satu petugas gudang, maka
Gudang terdapat relasi antara Pengiriman dengan Petugas Gudang. Entitas
Pengiriman memiliki relasi ‘dikirim oleh’ Petugas Gudang.
Pesanan dengan Rekap Penjualan Setiap pesanan akan direkapitulasi pada periode dan wilayah tertentu.
Oleh karena itu entitas Pesanan danentitas Rekap Penjualan memiliki
33
13414023 – 13414083 – 13414089
Entitas Keterangan
relasi ‘direkapitulasi’.
Rekap Penjualan dengan Srategi Hasil rekapitulasi penjualan akan menjadi pertimbangan untuk
Penjualan dan Pemasaran merancang strategi penjualan yang akan diterapkan untuk wilayah
tertentu. Maka entitas Rekap Penjualan memiliki relasi ‘merancang’
Strategi Penjualan dan Pemasaran.
Produk dengan Kuesioner Setiap jenis produk dihasilkan dari proses RnD. Riset dilakukan dengan
Preferensi melakukan market research, yaitu membuat kuesioner untuk konsumen.
Hasil dari kuesioner tersebut akan menjadi pertimbangan untuk
merancang produk. Sehingga entitas Produk dan Kuesioner Preferensi
memiliki relasi yaitu ‘merancang’. Record pada Kuesioner Preferensi
memiliki foreign key yang menunjukkan produk manakah yang
dirancang berdasarkan preferensi dari kuesioner tersebut.
Kuesioner Preferensi dengan Selain hasil rekap penjualan, strategi penjualan dan pemasaran juga
Strategi Penjualan dan Pemasaran mendapat input yaitu kuesioner preferensi dari konsumen. Maka relasi
yang menghubungkan Kuesioner Preferensi dengan Strategi Penjualan
dan Pemasaran adalah ‘merancang’.
Strategi Penjualan dan Pemasaran Alokasi Zona Pemasaran merupakan entitas asosiatif antara Strategi
dengan Alokasi Zona Pemasaran Penjualan dan Pemasaran dan Wilayah Penjualan. Alokasi Zona
Pemasaran memberikan keterangan mengenai eksekusi dari strategi
pemasaran dan penjualan yang telah ditentukan. Maka dapat dikatakan
relasi antara entitas Strategi Penjualan dan Pemasaran dengan Alokasi
Zona Pemasaran adalah ‘dieksekusi’.
Alokasi Zona Pemasaran dengan Alokasi Zona Pemasaran menunjukkan detail mengenai bagaimana
Wilayah Penjualan strategi pemasaran dan penjualan dijalankan, termasuk juga
menunjukkan di wilayah mana strategi tersebut dieksekusi.
Alokasi Zona Pemasaran dengan CV. SSI memiliki tim salesman untuk menjalankan strategi penjualan dan
Salesman pemasaran. Masing-masing salesman bertanggung jawab untuk
melaksanakan strategi tertentu yang sudah ditentukan alokasinya.
Sehingga entitas Salesman memiliki relasi ‘bertanggung jawab’ atas
Alokasi Zona Pemasaran.
Kuesioner Preferensi dengan Sebagai bentuk market research, CV. Simba SI menyebarkan kuesioner
Konsumen preferensi untuk konsumennya. Maka dalam ERD, Konsumen memiliki
relasi ‘mengisi’ Kuesioner Preferensi.
Konsumen dengan Klaim Garansi Setiap konsumen memiliki hak untuk mengjukan klaim garansi jika
terjadi masalah terhadap produk yang dibeli. Entitas Klaim Garansi
mencatat data mengenai klaim garansi yang diajukan konsumen. Maka
dapat dikatakan keduanya dihubungkan dengan relasi ‘mengajukan’.
Klaim Garansi juga merupakan entitas asosiatif dari hasil normalisasi
entitas Konsumen, Petugas Bengkel, dan Customer Service.
Klaim Garansi dengan Data Dari klaim garansi yang diajukan konsumen, akan dilakukan
Kerusakan pemeriksaan produk untuk mengetahui kerusakan yang sebenarnya
terjadi. Detail kerusakan akan dicatat di entitas Data Kerusakan.
Data Kerusakan dengan Petugas Data Kerusakan merupakan entitas asosiatif antara Petugas Bengkel
Bengkel dengan Klaim Garansi. Setiap klaim akan ditangani oleh satu petugas
34
13414023 – 13414083 – 13414089
Entitas Keterangan
bengkel yang kemudian akan memutuskan kerusakan apa yang terjadi.
Kemudian petugas bengkel akan memasukkannya ke database Data
Kerusakan.
Klaim Garansi dengan Customer CV. Simba SI menyediakan tenaga customer service untuk menerima
Service klaim garansi dari konsumen. Setiap klaim garansi akan ditangani oleh
satu orang customer service.
3.2 Analisis Kardinalitas pada ERD Hasil Normalisasi

Berikut adalah contoh kardinalitas yang akan dianalisis.
1 M Produk yang M 1
Produk Pesanan
Dipesan
Gambar 18 Hubungan Kardinalitas Produk dengan Pesanan
Dari gambar tersebut terlihat bahwa kardinalitas antara produk dengan produk yang dipesan adalah one to
many yang berarti bahwa satu produk bisa terdapat di banyak produk yang dipesan. Begitu pula kardinalitas
antara pesanan dengan produk yang dipesan juga one to many, yang berarti bahwa satu pesanan bisa berisi
banyak produk yang dipesan, namun satu produk yang dipesan hanya ada dalam satu pesanan.
Pengiriman Petugas Gudang

M 1
M
1 Distributor
1 M
Produk yang M 1
Pesanan
Dipesan
M M
Rekap Penjualan
1
Gambar 19 Kardinalitas Pesanan dengan Entitas Lain
Dari gambar tersebut terlihat bahwa kardinalitas antara produk yang dipesan dengan pengiriman adalah one to
many yang berarti bahwa produk yang dipesan dapat dikirim pada pengiriman yang berbeda dan satu kali
pengiriman hanya akan mengirim satu produk yang dipesan. Sedangkan kardinalitas antara petugas gudang
dengan pengiriman adalah one to many, yang berarti bahwa satu petugas gudang dapat melakukan banyak
35
13414023 – 13414083 – 13414089
pengiriman, dan satu pengiriman hanya dapat dilakukan oleh satu petugas gudang. Kardinalitas antara rekap
penjualan dengan pesanan adalah one to many, yang berarti bahwa rekap penjualan dapat berasal dari banyak
pesanan. Begitu pula kardinalitas antara distributor dengan pesanan yang juga one to many, yang berarti
bahwa satu distributor dapat melakukan banyak pesanan dan satu pesanan dilakukan oleh satu distributor.
Produk
menentukan
Kuesioner M 1
mengisi Konsumen
Preferensi
M
1 M M 1 M 1
Data
Petugas Bengkel Klaim Garansi Costumer Service
Kerusakan
Gambar 20 Kardinalitas Konsumen dengan Entitas Lain
Dari gambar tersebut terlihat bahwa kardinalitas antara produk dengan kuesioner preferensi adalah one to
many yang berarti bahwa satu produk dapat dirancang dari banyak kuesioner preferensi. Sedangkan
kardinalitas antara konsumen dengan kuesioner preferensi adalah one to many, yang berarti bahwa satu
konsumen dapat mengisi banyak kuesioner preferensi. Kardinalitas antara konsumen dengan klaim garansi
adalah one to many, yang berarti bahwa satu konsumen dapat mengajukan banyak klaim garansi. Kardinalitas
antara customer service dengan klaim garansi adalah one to many, yang berarti bahwa satu customer service
dapat melayani banyak klaim garansi. Kardinalitas antara klaim garansi dengan data kerusakan adalah one to
many, yang berarti bahwa satu klaim garansi dapat dapat berisi banyak kerusakan. Begitu pula kardinalitas
antara petugas bengkel dengan data kerusakan yang juga one to many, yang berarti bahwa satu petugas
bengkel dapat menangani banyak kerusakan.
36
13414023 – 13414083 – 13414089
merancang Wilayah Penjualan
1 M M
1 M
Strategi Penjualan Alokasi Zona
Rekap Penjualan
dan Pemasaran Pemasaran
Salesman
Gambar 21 Hubungan Kardinalitas Strategi Penjualan dengan Entitas Lain.
Dari gambar tersebut terlihat bahwa kardinalitas antara rekap penjualan dengan strategi penjualan dan
pemasaran adalah one to many yang berarti bahwa satu rekap penjualan dapat digunakan untuk merancang
banyak strategi penjualan. Sedangkan kardinalitas antara stratesgi penjualan dan pemasaran dengan alokasi
zona pemasaran adalah one to many, yang berarti bahwa satu strategi penjualan dan pemasaran dapat
diterapkan pada banyak alokasi zona pemasaran. Kardinalitas antara wilayah penjualan dengan alokasi zona
pemasaran adalah one to many, yang berarti bahwa satu wilayah penjualan dapat berisi banyak alokasi zona
pemasaran. Begitu pula kardinalitas antara alokasi zona pemasaran dengan salesman yang juga one to many,
yang berarti bahwa satu alokasi zona pemasaran dapat dipegang oleh banyak salesman.
3.3 Analisis Penentuan Atribut, Primary Key, dan Foreign Key

Dalam pembuatan Entity Relationship Diagram, terdapat beberapa atribut serta primary key dan foreign key
didalamnya. Berikut ini penjelasan terkait pemilihan atribut dan juga penentuan primary key serta foreign key
pada suatu atribut :
Tabel 6 Analisis Penentuan Atribut, Primary Key, dan Foreign Key
No. Entitas Atribut Alasan Pemilihan Atribut
Kode Produk (PK) Digunakan sebagai identitas untuk setiap jenis produk
1 Produk
Nama Produk Digunakan untuk mengatahui nama setiap jenis produk
37
13414023 – 13414083 – 13414089
Harga Digunakan untuk mengetahuhi harga setiap jenis produk
Digunakan sebagai identitas untuk setiap produk yang

Kode Order (PK)
dipesan
Digunakan untuk mengetahui jenis produk apa yang

Kode Produk (FK)
dipesan
Digunakan untuk mengetahui dipesan oleh siapa produk

ID Pesanan (FK)
tersebut
Produk yang
2
Dipesan
Jumlah Digunakan untuk mengetahui jumlah produk yang dipesan
Digunakan untuk mengetahui total harga produk yang

Total Harga
dipesan
Digunakan untuk mengetahui informasi pengiriman setiap

ID Pengiriman (FK)
produk yang dipesanan
ID Pesanan (PK) Digunakan sebagai identitas untuk setiap transaksi pesanan
Digunakan untuk mengetahui identitas distributor yang

ID Distributor (FK)
melakukan transakasi pesanan
Kode Rekapitulasi Digunakan untuk mengetahui pesanan masuk ke dalam

(FK) rekap penjualan yang mana
3 Pesanan
Tanggal Pemesanan Digunakan untuk mengetahui tanggal transaksi pesanan
Digunakan untuk mengetahui total pembayaran setiap

Total Pembayaran
transaksi
Digunakan untuk mengetahui dari mana konsumen

Sumber Informasi
mengetahui produk tersebut
Petugas ID Petugas Gudang

4 Digunakan sebagai identitas untuk setiap petugas gudang
Gudang (PK)
38
13414023 – 13414083 – 13414089
Nama Petugas
Digunakan untuk mengetahui nama setiap petugas gudang
Gudang
Nomor Telepon Digunakan untuk mengetahui nomor telepon setiap

Petugas Gudang petugas gudang
ID Pengiriman (PK) Digunakan sebagai identitas untuk setiap pengiriman
Biaya Kirim Digunakan untuk mengetahui biaya kirim setiap pengiriman
Digunakan untuk mengetahui alamat kirim setiap

Alamat Kirim
pengiriman
5 Pengiriman
Digunakan untuk mengetahui tanggal kirim setiap

Tanggal Kirim
pengiriman
Estimasi Tanggal Digunakan untuk mengetahui estimasi tanggal sampai

Sampai setiap pengiriman
ID Distributor (PK) Digunakan sebagai identitas untuk setiap distributor
Nama Distributor Digunakan untuk mengetahui nama setiap distributor
6 Distributor
Alamat Distributor Digunakan untuk mengetahui alamat setiap distributor

Distributor distributor
Kode Rekapitulasi
Digunakan sebagai identitas untuk setiap rekap penjualan
(PK)
Digunakan untuk mengetahui periode setiap rekap

Periode
penjualan
Rekap
7
Penjualan Digunakan untuk mengetahui wilayah setiap rekap
Wilayah
penjualan
Digunakan untuk mengetahui jumlah penjualan setiap

Jumlah Penjualan
rekap penjualan
39
13414023 – 13414083 – 13414089
Sumber Informasi Digunakan untuk mengetahui sumber informasi terbanyak

Terbanyak setiap rekap penjualan
Digunakan sebagai identitas untuk setiap strategi penjualan

Kode Strategi (PK)
dan pemasaran
Kode Rekapitulasi Digunakan untuk mengetahui rekap penjualan mana yang

(FK) digunakan pada setiap strategi
Digunakan untuk mengetahui target pasar pada setiap

Target Pasar
strategi
Strategi
Digunakan untuk mengetahui strategi yang digunakan pada
8 Penjualan dan Strategi
setiap strategi pemasaran dan penjualan
Pemasaran
Digunakan untuk mengetahui alokasi dana yang diberikan

Alokasi Dana
pada setiap strategi
Digunakan untuk mengetahui media pemasaran yang

Media
digunakan pada setiap strategi
Kontrak Media Digunakan untuk mengetahui kontrak media partner pada

Partner setiap strategi
Digunakan sebagai identitas untuk setiap alokasi zona

ID Alokasi (PK)
penjualan
Digunakan untuk mengetahui wilayah penjualan pada

Alokasi Zona Kode Wilayah (FK)
9 setiap zona penjualan
Penjualan
Digunakan untuk mengetahui strategi yang digunakan pada

Kode Strategi (FK)
setiap zona penjualan
Wilayah
10 Kode Wilayah (PK) Digunakan sebagai identitas untuk setiap wilayah penjualan
Penjualan
40
13414023 – 13414083 – 13414089
Digunakan untuk mengetahui nama wilayah setiap wilayah

Nama Wilayah
penjualan
ID Salesman (PK) Digunakan sebagai identitas untuk setiap salesman
Digunakan untuk mengetahui zona penjualan untuk setiap

ID Alokasi (FK)
salesman
Nama Salesman Digunakan untuk mengetahui nama setiap salesman
11 Salesman
Alamat Salesman Digunakan untuk mengetahui alamat setiap salesman

Salesman salesman
Email Salesman Digunakan untuk mengetahui email setiap salesman
ID CS (PK) Digunakan sebagai identitas untuk setiap customer service
Nama CS Digunakan untuk mengetahui nama setiap customer service

Customer
12
Service
Digunakan untuk mengetahui nomor telepon setiap
Nomor Telepon CS
customer service
Email CS Digunakan untuk mengetahui email setiap customer service
ID Konsumen (PK) Digunakan sebagai identitas untuk setiap konsumen
Nama Konsumen Digunakan untuk mengetahui nama setiap konsumen
Alamat Konsumen Digunakan untuk mengetahui alamat setiap konsumen

13 Konsumen

Konsumen konsumen
Email Konsumen Digunakan untuk mengetahui email setiap konsumen
41
13414023 – 13414083 – 13414089
Digunakan sebagai identitas untuk setiap kuesioner

ID Preferensi (PK)
preferensi
Digunakan untuk mengetahui identitas konsumen yang

ID Konsumen (FK)
mengisi kuesioner
Digunakan untuk mengetahui kuesioner digunakan pada

Kode Strategi (FK)
strategi apa
Kuesioner
14
Preferensi
Digunakan untuk mengetahui kuesioner digunakan pada
Kode Produk (FK)
produk jenis apa
Preferensi Desain Digunakan untuk mengetahui preferensi desain produk
Digunakan untuk mengetahui instansi yang mengisi

Instansi
kuesioner
ID Klaim (PK) Digunakan sebagai identitas untuk setiap klaim garansi
Digunakan untuk mengetahui identitas konsumen yang

ID Konsumen (FK)
mengajukan klaim garansi
15 Klaim Garansi
Digunakan untuk mengetahui identitas customer service
ID CS (FK)
yang melayani klaim garansi
Klaim Digunakan untuk mengetahui isi dari klaim garansi
Kode Kerusakan (PK) Digunakan sebagai identitas untuk setiap kerusakan
Digunakan untuk mengetahui identitas petugas bengkel

ID Petugas (FK)
yang menangani kerusakan
Data
16
Kerusakan
Digunakan untuk mengetahui identitas klaim garansi untuk
ID Klaim (FK)
setiap kerusakan
Jenis Kerusakan Digunakan untuk mengetahui jenis kerusakan
42
13414023 – 13414083 – 13414089
Jumlah Kerusakan Digunakan untuk mengetahui jumlah kerusakan
ID Petugas (PK) Digunakan sebagai identitas untuk setiap petugas bengkel
Nama Petugas Digunakan untuk mengetahui nama setiap petugas bengkel
Petugas Digunakan untuk mengetahui alamat setiap petugas

17 Alamat Petugas
Bengkel bengkel

Petugas petugas bengkel
Email Petugas Digunakan untuk mengetahui email setiap petugas bengkel
3.4 Analisis Penentuan Tipe Data dan Nulitas
Gambar 22 Data tabel Pesanan
Tabel di atas merupakan tabel Pesanan, primary key yang digunakan adalah ID Pesanan. Terdapat beberapa
kolom dalam tabel tersebut yang memiliki tipe data dan nullity yang berbeda-beda. Beberapa tipe data yang
digunakan dalam tabel ini adalah:
 NCHAR, data berupa sekumpulan karakter unicode. Contoh penggunaan tipe data ini adalah pada
kolom ID Pesanan.
 DATE, data berupa tanggal dan waktu. Contoh penggunaan tipe data ini adalah pada kolom Tanggal
Pemesanan.
 MONEY, data berupa angka mata uang. Contoh penggunaan tipe data ini adalah pada kolom Total
Pembayaran.
 TEXT, data berupa sekumpulan karakter non-unicode dengan jumlah karakter yang umumnya besar.
Contoh penggunaan tipe data ini adalah pada kolom Sumber Informasi.
Tipe data lain yang sering digunakan adalah INT, FLOAT, VARCHAR, dan lainnya. Selain tipe data, kita juga harus
menentukan nullity dari suatu kolom atau atribut. Terdapat dua jenis nullity yaitu NULL dan NOT NULL. Suatu
atribut bersifat NOT NULL apabila setiap record harus memiliki atribut tersebut. Contoh atribut yang bersifat
43
13414023 – 13414083 – 13414089
NOT NULL adalah primary key, karena setiap record harus memiliki primary key untuk memberikan keunikan
untuk record tersebut dibanding record lainnya. Sedangkan NULL berarti suatu record bisa jadi tidak memiliki
atribut tersebut. Pada tabel Pesanan, contoh atribut yang bersifat NULL ID Pengiriman. Hal tersebut karena
pada awal memasukkan data pesanan, pesanan tersebut belum memiliki ID Pengiriman.
3.5 Analisis Teknik Normalisasi

Normalisasi merupakan teknik yang digunakan untuk menghilangkan redundansi data pada suatu database.
Normalisasi diperlukan untuk menghindari hal-hal yang tidak diinginkan dengan mengorganisasikan atribut-
atribut yang terkait. Hasil dari pengorganisasian data tersebut bertujuan untuk membentuk entitas yang
memiliki atribut non-redundant, stabil, dan juga fleksibel. Normalisasi ini dilakukan untuk memastikan entitas
yang ada sudah memiliki relasi yang baik sehingga proses insert, update, delete, ataupun modifikasi pada satu
atau beberapa atribut dapat dilakukan tanpa memengaruhi integritas data di dalam relasi tersebut.
Teknik normalisasi diaplikasikan untuk relasi yang bersifat many to many. Seperti yang telah dijelaskan pada
bab sebelumnya, hubungan many to many memiliki risiko terjadi redundansi data. Redundansi data adalah
salah satu ciri sistem informasi yang tidak baik. Oleh karena itu, hal ini harus dihindari agar tidak terjadi error.
Permasalahan yang terjadi pada redundansi data antara lain:
1. Inkonsistensi Data
Inkonsistensi data adalah ketidakkonsistensian data yang disebabkan oleh relasi many to many.
Inkonsistensi data dapat menyebabkan perbedaan update pada dua entitas yang saling berhubungan.
Misalnya pada satu tabel entitas diupdate , namun pada tabel entitas yang berhubungan tidak di-update.
2. Anomali Data
Anomali data dapat dibedakan menjadi 3 jenis, yaitu :
o Modification anomalies, anomali akibat modifikasi data
o Insertion anomalies, anomali akibat penambahan data
o Deletion anomalies, anomali akibat data yang dihapus
Normalisasi dilakukan terhadap kedua tabel entitas yang saling berhubungan M to M. Proses normalisasi tidak
hanya terjadi satu kali saja, tetapi bisa juga dilakukan lebih dari satu kali tergantung kebutuhan sistem
informasi yang dibutuhkan. Contohnya adalah untuk entitas Pesanan yang dinormalisasi menghasilkan Produk
yang Dipesan dan entitas Klaim Garansi yang dinormalisasi kembali menghasilkan Data Kerusakan. Berikut
adalah tabel yang berisi daftar hubungan antarentitas yang sudah dinormalisasi:
Tabel 7 Hubungan Normalisasi Antarentitas
No Entitas 1 Entitas 2 Entitas Hasil Normalisasi

1 Produk Distributor Pesanan
2 Pesanan Distributor Produk yang Dipesan
3 Pesanan Rekap Penjualan Produk yang Dipesan
4 Strategi Penjualan Salesman Alokasi Zona Pemasaran
5 Strategi Penjualan Wilayah Penjualan Alokasi Zona Pemasaran
6 Konsumen Customer Service Klaim Garansi
7 Konsumen Petugas Bengkel Klaim Garansi
8 Klaim Garansi Petugas Bengkel Data Kerusakan
44
13414023 – 13414083 – 13414089
Berdasarkan hubungan many to many di atas, praktikan memilih entitas Strategi Penjualan dengan Wilayah
Penjualan sebagai contoh. Proses yang terjadi sebelum normalisasi adalah banyak Strategi Penjualan dapat
dilakukan di banyak wilayah penjualan.
Kode
Rekapitulasi
Target Pasar
(FK)
Kode Wilayah Nama Wilayah
Strategi
Kode Strategi
Kontrak Media
Partner
Media
Alokasi Dana
Strategi Penjualan M M
diterapkan di Wilayah Penjualan
dan Pemasaran
Gambar 23 Proses Sebelum Normalisasi
Proses tersebut akan dinormalisasi dengan data baru yang terbentuk Alokasi Zona Pemasaran.
Kode
Rekapitulasi
Target Pasar
(FK)
Kode Wilayah Nama Wilayah
Strategi
Kode Strategi
Kontrak Media
Partner
Media
Alokasi Dana
Strategi Penjualan 1 M Alokasi Zona M 1

Wilayah Penjualan
dan Pemasaran Pemasaran
Kode Strategi
ID Alokasi
(FK)
Kode Wilayah
(FK)
Gambar 24 Proses Setelah Normalisasi
Kemudian dilakukan normalisasi dengan langkah sebagai berikut:
1. Menghilangkan duplikasi dengan mencari ketergantungan antara dua tabel entitas, misalnya satu
konsumen dapat dilayani oleh banyak petugas customer service (karena asumsi satu pelanggan dapat
meng-klaim kerusakan yang berbeda) dan satu customer service dapat melayani banyak pelanggan
sehingga akan terdapat duplikasi ID Konsumen dan ID CS-nya.
Tabel 8 Tabel Konsumen Sebelum Normalisasi
Konsumen
ID
Nomor
Konsume Nama Alamat Email ID CS
Telepon
n (PK)
K001 Cindy Sirinya Jalan Sarimanis No. 3 Bandung
081263748937 cindy@yahoo.com CS1724
K002 Ayu Gani Jalan Sukajadi No. 56 Surabaya
087836394628 ayu@live.com CS1725
K003 Yu Tsai Jalan Kintamani II Jakarta085629386473 yutsai@gmail.com CS1725
45
13414023 – 13414083 – 13414089
Tabel 9 Tabel Customer Service Sebelum Normalisasi
Customer Service
No. Telepon
ID CS (PK) Nama CS Email CS ID Konsumen
CS
CS1724 Beni beni@simba.com 089664424535 K001
CS1725 Rohman rohman@simba.com 085243282547 K002
CS1728 Rani rani@simba.com 081347677568 K001
2. Membuat suatu tabel yang berisi foreign key dari kedua entitas sehingga pada tabel kedua entitas tersebut
tidak terdapat duplikasi lagi.
Tabel 10 Tabel Klaim Garansi Setelah Normalisasi
Klaim Garansi
ID Konsumen
ID Klaim (PK) ID CS (FK) Klaim
(FK)
KL90091 K001 CS1724 Satu roda poros lepas
KL90092 K002 CS1725 Tiga roda poros lepas
KL90093 K003 CS1725 Pengunci atas mulai goyah
KL90094 K001 CS1728 Dua Pengunci bawah hampir patah
3. Menghapus kolom-kolom yang tidak diperlukan pada kedua tabel entitas awal.
Tabel 11 Tabel Konsumen Setelah Simplifikasi
Konsumen
ID
Nomor
Konsume Nama Alamat Email ID CS
Telepon
n (PK)
K002 Ayu Gani Jalan Sukajadi No. 56 Surabaya
087836394628 ayu@live.com CS1725
K003 Yu Tsai Jalan Kintamani II Jakarta085629386473 yutsai@gmail.com CS1725
Tabel 12 Tabel Customer Service Setelah Simplifikasi
Customer Service
No. Telepon
ID CS (PK) Nama CS Email CS ID Konsumen
CS
CS1724 Beni beni@simba.com 089664424535 K001
CS1728 Rani rani@simba.com 081347677568 K001
Yang perlu diperhatikan adalah setiap entitas memiliki atribut primary key-nya masing-masing. Dalam kasus ini,
entitas Konsumen memiliki primary key berupa ID Konsumen, sedangkan pada entitas petugas Customer
Service berupa ID CS. Dalam database Klaim Garansi kedua primary key tersebut “dipanggil” sehingga menjadi
foreign key.
Dalam proses bisnis yang terjadi dalam kehidupan nyata, tidak semua fitur yang terlibat sesuai dengan sistem
informasi yang ada. Oleh karena itu, dibutuhkan adanya penyesuaian dan continuous improvement berkaitan
dengan pembangunan sistem informasi tersebut. Salah satu caranya adalah dengan normalisasi yang
46
13414023 – 13414083 – 13414089
merupakan teknik khusus sehingga dapat memperkecil kemungkinan error yang terjadi dan menjaga integritas
serta akurasi data.
3.6 Analisis Software DBMS

Database Management System (DBMS) adalah sebuah perangkat lunak yang berisi kumpulan program yang
digunakan untuk membuat, mengakses, mengontrol, dan mengelola sebuah database. Sistem DBMS dibuat
untuk mengatasi kelemahan sistem pemrosesan yang berbasis data. Oleh karena itu, adanya DBMS
memungkinkan pengguna menjalankan operasi terhadap data yang yang tersedia sesuai kebutuhan. Saat ini,
DBMS telah berkembang menjadi bagian standar pada bagian pendukung sebuah perusahaan.
Pada umumnya, perancangan sistem informasi dibuat secara customized atau terspesifikasi untuk kebutuhan
individual tiap pengguna, bukan berdasarkan kebutuhan sekelompok user sekaligus. Setiap kali terdapat
kebutuhan baru dari seorang pemakai, kebutuhan segera diterjemahkan kedalam program computer. Dengan
begitu, perancangan sistem informasi ini harus bersifat dinamis, dalam arti, sistem harus dapat diperbarui
(update), ditambah, maupun dihapus setiap waktu. Hal ini yang menimbulkan tingginya urgensi untuk program
aplikasi menuliskan data tersendiri.
Beberapa DBMS ada yang hanya bisa dijalankan di komputer mainframe, beberapa hanya jalan di
minikomputer dan juga ada yang hanya dapat dijalankan di Personal Computer (PC). Saat ini, tren yang
berkembang adalah penggunaan DBMS dengan fasilitas cross-platform.
Terdapat beberapa manfaat dan kelebihan dalam penyimpanan data menggunakan DBMS dibanding
penyimpanan dalam bentuk dokumen biasa (misal: spreadsheet Excel), yaitu sebagai berikut:
1. Pengelolaan data terdistribusi secara transparan dan replicated sehingga dapat integritas daya
terjamin.
2. Struktur database dapat diubah tanpa harus mengubah aplikasi sehingga pembuatan antarmuka ke
data lebih mudah dengan penggunaan DBMS. Adanya sifat independensi tersebut mengurangi
ketergantungan data.
3. Keadaan redundansi atau kejadian data terulang yang sering terjadi pada penggunaan flat file dan
menyebabkan pemborosan memori penyimpanan dapat dihindari.
4. Data terpusat sehingga dapat mempermudah pengelolaan database. Kemudahan one-way access
dengan konsistensi data yang diakses bersama lebih terjamin daripada data disimpan dalam bentuk
file yang tersebar.
5. Performansi data dengan penyimpanan dalam bentuk DBMS cukup besar, berbeda jauh dengan
performance data yang disimpan dalam bentuk flat file sehingga meningkatkan kehandalan data dan
pengembangan sistem.
6. DBMS memiliki sistem keamanan lebih fleksibel daripada pengamanan pada file sistem operasi.
Keamanan pada DBMS akan memberikan keluwesan dalam pemberian hak akses pada pengguna.
Namun, meski begitu DBMS juga tetap memiliki beberapa kekurangan, antara lain:
1. Biaya instalasi dan operasional software DBMS yang canggih sangat mahal. Walaupun harga DBMS
berbasis computer mikro lebih murah, tetapi bagi perusahaan start up atau organisasi kecil, trade off
yang dikeluarkan tetap dianggap besar.
2. Konfigurasi apasitas perimer dan sekunder dipakai lebih tinggi dalam penyimpanan dibanding lainnya.
3. Dengan adanya teknologi baru, maka perusahaan juga harus mempertimbangkan adanya staff khusus
DBMS karena diperlukan pengetahuan khushs untuk dapat mengoperasikanya.
4. Kompleksitas tinggi karena semua jaringan data terpusat sehingga akan timbul dampak yang tinggi jika
penggunaan tidak optimal.
47
13414023 – 13414083 – 13414089
Dalam operasionalnya, DBMS mempunyai komponen fungsional, antara lain:
 File Manager
Mengelola ruang didalam disk dan juga struktur data yang digunakan untuk merepresentasikan
informasi yang tersimpan didalam suatu disk.
 Database Manager
Menyediakan interface antar data low – level yang terdapat pada basis data dengan program aplikasi
serta query yang diberikan ke suatu sistem.
 Query Processor
Menerjemahkan perintah dalam bahasa query ke inStruksi low – level yang dapat dimengerti database
manager.
 DML Precompiler
Mengkonversi pernyataan atau perintah DML, yang ditambahkan dalam suatu program aplikasi
prosedur normal dalam bahasa induk.
 DDL Compiler
Mengkonversi berbagai perintah DDL ke dalam sekumpulan tabel yang mengandung metadata.
Adapun beberapa contoh dari DBMS yang berkembang saat ini, diantaranya sebagai berikut:
3.6.1 My SQL
MySQL adalah perangkat lunak sistem manajemen basis data SQL atau DNMS yang multithread dan multiuser
dengan sekitar 6 juta instalasi di dunia. MySQL dimiliki dan disponsori oleh perusahaan komersial Swedia, yaitu
MySQL AB yang memegang penuh hak cipta hampir semua kode sumbernya serta memungkinkan instalasi
secara gratis (open source). Versi terbaru dari MySQL adalah MySQL 5.0.41.
Gambar 25 Logo MySQL
3.6.2 Oracle
Oracle merupakan Relational Database Management System (RDBMS) yang digunakan untuk mengelola
informasi secara terbuka, komprehensif, dan terintegrasi. Oracle sendiri merupakan DBMS yang rumit dan
mahal serta dirancang khusus untuk organisasi berukuran besar. Oracle tidak sesuai digunakan pada organisasi
yang kecil ataupun organisasi menengah. Software ini dikembangkan oleh developer Oracle Corporation
dengan versis terbarunya Oracle 11g.
Gambar 26 Logo Oracle
48
13414023 – 13414083 – 13414089
3.6.3 Microsoft Access
Micorsoft Access adalah DBMS paling sederhana dan mudah didapatkan karena terdapat pada satu bundel
Microsoft Office yang ditujukan untuk kalangan rumah atau perusahaan kecil hingga menengah dan dapat
diintegrasi menggunakan Microsoft Visual Basic. Banyaknya pengguna Microsoft Access ini membuat tutorial
penggunaan DBMS sangat mudah didapatkan dipasaran. Microsoft Access menggunakan mesin basis data
Microsoft Jet Database Access Engine. Microsoft mengeluarkan versi terbaru dari Microsoft Access yaitu
Microsoft Access 2016.
Gambar 27 Logo Microsoft Access
3.6.4 Firebird
Firebird merupakan salah satu aplikasi Relational Database Management System (RDBMS) dengan sifat open
source. RDMS berjalan baik pada Linux, Windows, dan sejumlah platform Unix. Firebird diarahkan dan
dimaintain oleh FirebirdSQL Foundation yang merupakan turunan dari interbase versi open source milik
Borland. Open source DBMS ini dimotori oleh beberapa developer Interbase 6.x open-source. Produk ini gratis
dan berkelas enterprise. Selain itu, Firebird digunakan para pelaku bisnis untuk mendapatkan solusi sistem
informasi berskala besar untuk menekan harga yang mahal dan biaya maintenance yang mahal.
Gambar 28 Logo Firebird
3.6.5 SQL Server
MS SQL Server merupakan salah satu produk Relational Database Management System (RDBMS) yang populer
saat ini dengan fungsi utamanya sebagai database server yang mengatur semua proses penyimpanan data dan
transaksi aplikasi. Terdapat paket bahasa yang digunakan untuk mengorganisasi basis data yang ada, yaitu Data
Definition Language (DDL) dan Data Manipulation Language (DML).
SQL (Structured Query Language) lebih dekat dengan DML dari pada DDL. Namun tidak berarti SQL tidak
menyediakan perintah DDL. SQL lebih menekankan pada aspek pencarian dari dalam tabel. Aspek pencarian ini
krusial karena seluruh data dalam basis data diatur sedemikian rupa dengan tujuan untuk memudahkan
pencarian di kemudian hari.
Sebagai sebuah bahasa, SQL telah distandarisasi dan mengalami beberapa perubahan atau penyempurnaan.
SQL muncul pertama kali pada tahun 1970 dengan nama Sequel (nama yang masih sering digunakan hingga
49
13414023 – 13414083 – 13414089
saat ini). Standar terakhir yang dibuat adalah SQL-92. Pernyataan-pernyataan SQL digunakan untuk melakukan
beberapa tugas seperti update data pada basis data atau menampilkan data dari basis data. Beberapa software
RDBMS yang dapat menggunakan SQL, seperti Oracle, Sybase, Microsoft SQL Server, MySQL, Microsoft Access,
Ingres, dsb.
Gambar 29 Logo SQL Server
3.6.6 IBM DB2
IBM DB2 merupakan sebuah DBMS. Nama lainnya, yaitu DB2 Enterprise Server Edition atau top of the line DB2
Data Warehouse Edition (DB2 DWE) berjalan pada Unix, Windows, dan Linux Server. IBM DB2 dapat
dijalankan pada bermacam-macam platform.
Gambar 30 Logo IBM DB2
3.6.7 Visual Pro
Microsoft Visual FoxPro merupakan bahasa pemrograman prosedural dan bahasa pemrograman berorientasi
objek. Visual FoxPro adalah software yang pertama kali dari FoxPro (FoxBASE). FoxPro berkembang menjadi
Visual FoxPro pada tahun 1995. Kemampuan pemrograman prosedural tetap dipertahankan dan dilengkapi
dengan pemrograman berorietasi objek. Model data yang digunakan Visual FoxPro yaitu model relasional. Yang
merupakan model yang paling sederhana sehingga mudah di pahami oleh pengguna, serta merupakan paling
popular saat ini. Model ini menggunakan sekumpulan tabel berdimensi dua (yang disebut relasi atau table),
dengan masing-masing relasi tersusun atas tupel atau baris dan atribut. Relasi dirancang sedemikian rupa
sehingga dapat menghilangkan pemborosan data dan mengunakan foreign key untuk berhubungan dengan
relasi lain.
Gambar 31 Logo Visual Pro
50
13414023 – 13414083 – 13414089
3.6.8 Clipper
Clipper adalah software khusus untuk pengolahan data. Mulai dikenal sekitar tahun 80-an sampai 90-an.
Clipper dimasukan ke dalam kelompok Xbase.
3.6.9 Postgre SQL
Postgre SQL adalah perangkat lunak yang memberikan keuntungan dibandingkan DBMS lainnya. Selama ini
banyak memberikan keuntungan yang lebih terhadap para perusahaan atau kegiatan bisnis dibanding DBMS
lainnya karena dibuat sedemikian rupa untuk mempunyai tingkat pemeliharaan dan kebutuhan yang lebih
rendah. Postgre SQL juga Menggunakan penyimpanan data dengan banyak baris (multiple rows) yang
dinamakan MVCC. Hal ini dimaksudkan agar PostgreSQL sangat responsif pada high volume environments.
Gambar 32 Logo PostgreSQL
Berikut adalah tabel kelebihan dan kelemahan masing-masing perangkat secara lebih rinci.
Tabel 13 Kelebihan dan Kelemahan Tiap DBMS
Perangkat
No Kelebihan Kekurangan
DBMS
Tidak sesuai menangani data dengan jumlah
Bebas di-download, fleksibel, stabil, dan besar dikarenakan proses data dan
tangguh penyimpanan tidak menampung banyak data
yang menyebabkan semakin lambat
Memiliki lapisan security yang baik, yaitu
subnetmask, nama host, izin akses user Kinerja server terbatas untuk perusahaan
dengan sistem perijinan mendetail serta skala kecil hingga menengah.
sandi/password terenkripsi.
1 MySQL
Management database yang mudah dan
mendukung aktivitas transaksi
Perkembangan software yang cepat
Sesuai untuk perusahaan skala kecil Kurangnya koneksi bahasa pemrograman
Mampu berjalan lebih dari satu platform Visual Basic, Delphi, dan Fox Pro.
sistem operasi, seperti LINUX,
Windowsm, MacOS, FreeBSD, Solaris,
dan sebagainya
51
13414023 – 13414083 – 13414089
Perangkat
DBMS
Fleksibilitas baik karena memiliki
multibahasa programming yang mampu Hanya dapat digunakan pada perusahaan
untuk menyesuaikan antara kondisi besar dengan database yang besar
dengan kebutuhan
Stabilitas, yaitu kemampuan pengolahan
database dalam skala besar dan terus DBMS yang paling rumit dan mahal, mulai
berkembang sehingga kapasitas besar dari pembangunan hinggan pelatihan SDM.
dan tidak mengalami kelambatan
2 Oracle Mampu menangani manajemen space
dan basis data yang besar
Bekerja di lingkungan dengan
pemrosesan tersebar
Spesifikasi hardware yang tinggi
Mendukung akses data secara simultan
Performansi pemrosesan dengan

transaksi tinggi
Ketersedian terkontrol terjamin
Tingkat keamanan rendah sehingga jarang
Kompabilitas dengan bahasa struktur SQL
digunakan perusahaan besar.
Kompabilitas dalam penggunaan Proses menjadi lambat saat database yang
software Microsoft Office, seperti Visio dimasukkan semakin banyak.
Proses desain lebih mudah, misalnya
Microsoft
3 pada pembuatan form dan query tanpa Tidak bagus saat diakses menggunakan
Access
melakukan coding terlebih dahulu jaringan yang menyebabkan aplikasi yang
Data kecil yang memudahkan digunakan cenderung menggunakan solusi
penyimpanan dan pemrosesan sistem manajemen basis data bersifat server
Digunakan sebagai basis data dalam atau klien.
aplikasi website
Marketing kurang dilaksanakan dalam
Menggunakan sintaks standar untuk
pemasaran DBMS sehingga pengguna masih
menciptakan foreign key
jarang.
Mendukung adanya row level locks, yaitu
4 Firebird Firebird menggunakan multiversion
concurrency system, artinya semua Developer firebird relatif lambat saat
session pada database akan melihat data melakukan pengembangan
yang lama hingga data baru sudah di-
commit ke dalam database.
52
13414023 – 13414083 – 13414089
Perangkat
DBMS
Mendukung aktivitas transaksi seperti
database komersial lainnya. Sebuah
transaksi dapat di-commit atau di-
rollback denan mudah. Firebird support
menggunakan savepoint pada suatu
transaksi dan dapat melakukan rollback
kembali ke savepoint yang telah
ditentukan di awal
Dapat mereplikasi sehingga solusi
replikasi dibuat oleh pihak ketiga, tetapi
teknik replikasi ini seperti konsep trigger
yang selalu memonitor adanya operasi
insert, update atau delete ke dalam
database Open source yang ada tidak terlihat siap dari
Menggunakan lebih dari satu file sebagai sisi replication engine dan masih terintegrasi
single logic database yang sangat ke dalam firebird dengan kode utama
berguna bagi para DBA (Database
Administrator) untuk mengadministrasi
database (multiple data file)
Software untuk mengadministrasi mudah
didapat karena banyak software untuk
mengadministrasi database Firebird,
seperti EMS IB Manager, IBConsole, isql,
FBManager, Marathon dan sebagainya.
Terdapat aplikasi yang komersial maupun
open source
Memiliki stored procedure dan triggers
dengan bahasa standard sehingga tidak
membingungkan new user
Sesuai untuk perusahaan skala kecil,
menengah, dan besar sehingga dapat Hanya berjaan pada satu platform system
mengolah data dengan jumlah yang operasi, yaitu Microsoft Windows
besar
Kemampuan untuk management user
Software berlisensi dan berharga mahal
dan tiap user bisa diatur hak akses pada
5 SQL Server untuk perusahaan kecil maupun menengah
database oleh database administrator
Tingkat security data yang baik Dapat diimplementasikan pada 1 unit server.
Kemampuan back-up data, rollback data, Jika terdapat tambahan server maka hanya
dan recovery data dapat berfungsi sebagai pasif/standby server
Kemampuan membuat database (tidak memiliki kemampuan Technology
mirroring dan clustering Cluster Server, seperti pada DBMS Oracle.
53
13414023 – 13414083 – 13414089
Perangkat
DBMS
Penerapan pada pembangunan program
aplikasi akan mudah dalam koneksi
dengan computer client dengan
pembangun aplikasinya menggunakan
software sama platform dengan MS-SQL,
seperti Microsoft Visual Basic
Mengurangi biaya administrasi Platform Specified
Mengurangi storage dan meningkatkan Download langsung dari IBM tidak bisa
efisiensi dilakukan
6 IBM DB 2
Migrasi dari database lain sangat mudah
Speed masih kalah terhadap MySQL dan
untuk dilakukan dan memungkinkan
Oracle
adanya multiplatform
Simpel, dinamis, sederhana, fitur lengkap Tidak dapat digunakan untum membuat OCX
Kemudahan mengakses database Menu-designer belum

internal mengimplementasikan OOP
Pembuatan report belum
Visual Memiliki database sendiri, yaitu DBF mengimplementasikan OOP (rencana akan
7
FoxPro diimplementasikan di VFP 9)
Kemudahan dalam mengakses library
Tipe data pointer tidak tersedia
eksternal
Tidak memerlukan spesifikasi hardware Pengembangan versi sekarang terhenti pada
yang tinggi versi 9.0
Mudah dicetak karena bentuk tidak grafis Struktur program kurang teratur
8 Clipper Perangkat keras yang dipakai tidak perlu
Supporting internet tidak berjalan baik
canggih
Kurang terkenal dibanding DBMS lain
Biaya staffing menjadi lebih hemat
sehingga belum teruji kredibilitasnya
9 Postgre SQL
Prosesnya terpercaya dan stabil
Ketersediaan fungsi pendukung yang kurang
Extensible
Dari analisis kelebihan dan kelemahan setiap jenis DBMS di atas, dapat disimpulkan bahwa setiap DBMS
memiliki trade off dari kriteria performansi dan biaya. Oleh karena itu, pemilihan DBMS terbaik hendaknya
disesuaikan dengan kondisi dan kebutuhan pengguna (perusahaan). Oracle cocok digunakan untuk untuk
perusahaan besar yang sudah mapan dengan kebutuhan pemrosesan data yang tinggi. Namun, dengan kondisi
pemrosesan data yang rumit, maka ongkos yang dibutuhkan besar dan pengguna dituntut untuk memiliki
ketrampilan yang tinggi. Sedangkan untuk perusahaan baru atau start-up dengan proses bisnis dan dana yang
masih terbatas seperti CV. Simba Smash Innovation, MySQL sudah cukup untuk memenuhi kebutuhan
perancangan sistem informasi karena gratis, stabil, dan memiliki fasilitas security yang baik.
54
13414023 – 13414083 – 13414089
3.7 Analisis Keterkaitan Antarmodul

Berikut adalah ilustrasi keterkaitan antarmodul dalam siklus manufaktur.
Gambar 33 Posisi Modul 6 dalam Sistem Manufaktur
Modul 6 Perancangan Basis Data pada praktikum kali ini dalam bagan keterkaitan perancangan Teknik Industri
yang integratif berada pada posisi sistem informasi. Pada modul 5 telah dihasilkan sebuah output DFD serta
context diagram dari divisi pemasaran dan penjualan CV. Simba Smash Innovation, dimana output Modul 5
tersebut digunakan sebagai input dalam Modul 6 ini. Dari DFD serta context diagram tersebut kemudian akan
dibuat Entitiy Relationship Diagram (ERD). Entitiy Relationship Diagram (ERD) sendiri merupakan pemodelan
data yang menggunakan beberapa notasi untuk menggambarkan hubungan dengan entitas dan relasi yang
dideskripsikan oleh data tersebut. Selain ERD, dalam praktikum Modul 6 ini juga akan dibuat database dari ERD
yang dibuat serta Logical Data Model dan Physical Data Model yang akan menjadi output dari Modul 6 ini.
55
13414023 – 13414083 – 13414089
BAB IV - KESIMPULAN DAN SARAN
4.1 Kesimpulan
Setelah dilakukan praktikum perancangan sistem terintegrasi III modul 6: perancangan basis data, maka
diperoleh beberapa kesimpulan sebagai berikut :
 Praktikan telah mampu merancang Entitty Relation Diagram (ERD), Logical Data Model (LDM), Physical
Data Model (PDM) melalui beberapa tahapan perancangan sistem informasi basis data sebagai
berikut :
a. Planning
Merupakan tahap dimana dilakukan identifikasi detail dari organisasi serta entitas-entitas dan
relasi yang ada. Pada modul ini, tahap planning dijelaskan pada subbab 2.1.
b. Analysis
Tahap ini merupakan tahapan untuk menentukan spesifikasi dari sistem informasi yang dibutuhkan
oleh suatu organisasi, dimana output pada tahap ini berupa Entitty Relation Diagram (ERD) yang
terdiri dari entitas serta atribut entitas. Pada modul ini, tahap analysis dijelaskan pada subbab 2.2.
c. Design
Tahap ini merupakan tahapan untuk mentransformasikan konseptual data model menjadi
implementation model untuk suatu DBMS terttentu. Pada modul ini, tahap design dilakukan
dengan normalisasi ERD serta pembuatan tabel database yang mencakup nama field, tipe data,
primary key serta foreign key.
d. Implementation
Tahap ini merupakan tahap untuk membangun aplikasi database dengan menggunakan DBMS.
Pada modul ini implementasi dilakukan dengan menggunakan software SQL Server.
 Praktikan telah mampu mengimplementasikan model desain basis data dengan menggunakan SQL
Server.
 Praktikan telah mampu merancang desain basis data yang dapat menyelesaikan persoalan manajerial
dan operasional.
4.2 Saran
4.2.1 Saran untuk Praktikum

Berikut adalah saran untuk keberjalanan praktikum ke depannya:
1. Penjelasan terkait materi praktikum sebaiknya dijelaskan sedetail mungkin.

2. Jika terdapat perubahan informasi terkait dengan praktikum sebaiknya tidak disampaikan secara
mendadak.
4.2.2 Saran untuk Asisten

Dalam menjalankan tugasnya, ada beberapa saran dari praktikan untuk asisten praktikum Modul 6 ini:
1. Keseragaman informasi antar kelompok.

2. Penyampaian informasi agar tidak mendadak dan sudah dipertimbangkan sebelumnya sehinga tidak
banyak informasi yang diubah/direvisi.
3. Asisten sebaiknya memberikan penjelasan terkait dengan materi paraktikum kepada praktikan secara
lebih rinci.
56
13414023 – 13414083 – 13414089
Daftar Pustaka
1) Laboratorium Sistem Informasi dan Komputer Teknik Industri ITB. Modul 6 Praktikum Perancangan Sistem
Terintegrasi III: Perancangan Basis Data. Bandung, 2017.
2) Laboratorium Sistem Informasi dan Komputer Teknik Industri ITB. Modul 6 Praktikum Perancangan Sistem
Terintegrasi III: Review Microsoft SQL Server. Bandung, 2017.
3) Whitten, L Jeffery and Bentley D Lonnnie, System Analist and Design Methode 7th Edition, McGraw-Hill
Education, 2007.
4) Laman http://informatika.web.id/keuntungan-dbms.htm (diakses pada 10 April 2017 pukul 01:45).
5) Laman https://mane3x.wordpress.com/2013/03/29/konsep-perancangan-terstruktur-dfd-data-flow-
diagram/ (diakses pada 5 April 2017 pukul 14:10).
6) Laman http://vebryexa.com/pengertian-dan-contoh-data-flow-diagram-dfd.html (diakses pada 22 Maret
2017 pukul 16:13).
7) Laman http://hidupberawaldari.blogspot.co.id/2013/01/contoh-diagram-arus-data-level-0-dan_21.html
(diakses 22 Maret 2017 pukul 16:45)
57
13414023 – 13414083 – 13414089

Contoh Laporan Tubes Basdat

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Contoh Laporan Tubes Basdat

Diunggah oleh

Hak Cipta:

Format Tersedia

LAPORAN

TI-3003 PRAKTIKUM PERANCANGAN SISTEM

1. Mitha Dewi Apriliani 13414023

LABORATORIUM SISTEM INFORMASI DAN KEPUTUSAN

1. Mitha Dewi Apriliani 13414023

Tanggal : 14 April 2017

Waktu : 11.00 WIB

Bandung, 14 April 2017

Hasbi Harbi Putra.

LEMBAR PENGESAHAN ............................................................................................................................................ 3

4.2.1 Saran untuk Praktikum ............................................................................................................................. 56

Gambar 1 Alur Praktikum Modul 6 ........................................................................................................................ 11

Tabel 1 Kebutuhan Fungsional .............................................................................................................................. 19

1.1 Latar Belakang

1.2 Tujuan Praktikum

1.2.1 Tujuan Umum

1.2.2 Tujuan Khusus

1.3 Alur Praktikum

Pembuatan Pengumpulan akhir

Gambar 1 Alur Praktikum Modul 6

BAB II – PERANCANGAN BASIS DATA

Gambar 2 Tahap Planning

 Detail dari aktivitas organisasi

Gambar 3 Simbol Entitas

Gambar 4 Simbol Relasi

Berikut adalah berbagai macam sifat pada relasi antar entitas :

No Entitas 1 Relasi Entitas 2 Kardinalitas Keterangan

konsumen. Oleh sebab itu terdapat

penjualan dapat menggunakan banyak

Pengiriman dikirim Petugas Gudang

menentukan Rekap Penjualan Customer Service

1 Strategi Penjualan 1 bertanggung M

Gambar 5 ERD Sebelum Normalisasi

Gambar 6 Tahap Analisis pada Perancangan Basis Data

 Mempelajari situasi bisnis saat ini

1. User Interface Functional

Tabel 1 Kebutuhan Fungsional

Tabel 2 Kebutuhan Non Fungsional

Kriteria kinerja yang Untuk mengakomodasi kondisi pasar dipengaruhi oleh

Divisi ini membutuhkan aspek ekonomi sebagai bahan

Aspek pengawasan dan kontrol ini penting karena banyak

Adanya sistem informasi diharapkan dapat memangkas

Sistem informasi dari divisi ini akan digunakan oleh semua

Gambar 7 Tahap Desain pada Perancangan Basis Data

2.3.1 Logical Database Design

1. Menghindari terjadinya asinkronisasi (tidak sinkron) data pada saat di-update

Gambar 8 Contoh ERD Sebelum Normalisasi

Setelah melalui proses normalisasi maka ERD-nya menjadi seperti ini:

Gambar 9 Contoh ERD Setelah Normalisasi

2) Block semua nama tabel kemudian klik Add

Kuesioner Preferensi [ID Alokasi]

[ID Preferensi] Konsumen Petugas Bengkel

Gambar 10 Logical data model

2.3.2 Physical Database Design

Untuk membuat PDM diperlukan tahap-tahap berikut:

1) Block semua tabel yang ada pada diagram LDM

3) Kemudian akan muncul dialog sebagai berikut.

Gambar 11 Physical data model

Gambar 12 Tahap Implementasi

Gambar 13 Membuat database baru

Gambar 14 Membuat tabel baru

Gambar 15 Menambahkan primary key

Gambar 16 Tabel Pesanan

3) Menentukan foreign key