Modul 4 Perancangan Basis Data

Kelompok 10

BAB I PENDAHULUAN
1.1. Tujuan Praktikum Tujuan praktikum : a. Mahasiswa dapat mendesain sistem informasi yang terdiri dari perancangan aplikasi dan basis data. b. Mahasiswa dapat mendesain basis data dengan menggunakan Entity Relationship Diagram (ERD), normalisasi, dan Physical Data Model. c. Mahasiswa dapat mendesain aplikasi berupa user interface. d. Mahasiswa dapat mengimplementasikan model desain basis data dengan menggunakan Microsoft Access.

Josef Novan Lumbantobing (13405071)

Halaman 1 dari 43

Modul 4 Perancangan Basis Data 1.2. Flowchart Perancangan Basis Data

Kelompok 10

Josef Novan Lumbantobing (13405071)

Halaman 2 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

BAB II PERANCANGAN BASIS DATA

2.1. Planning 2.1.1. Functional Requirement Identifikasi functional requirement sistem informasi untuk divisi marketing PT PTI dilakukan dengan metode fact finding. Proses requirement discovery dilakukan dengan melihat proses bisnis divisi marketing pada DFD yang telah dibuat sebelumnya. Proses Bisnis Peranan Database Menyusun Strategi y Sistem basis data mampu menyimpan, menampilkan, Pemasaran dan mengolah data-data yang relevan dan diperlukan dalam penyusunan strategi pemasaran, seperti: preferensi konsumen, market share kompetitor,

alokasi anggaran, dll.

Mempromosikan Produk Sistem basis data mampu mengakomodasi proses inputing, updating, pengolahan, dan retrieval yang berguna untuk mempromosikan produk. Untuk pengadaan promosi produk, database harus dapat menyimpan data-data agen iklan dan promosi apa saja yang dilakukan. Sistem basis data harus mampu mengakomodasi proses inputing, pengolahan, dan retrieval yang berhubungan dengan transaksi ragum. Karena frekuensi transaksi PT PTI berlangsung sering maka basis data harus dapat melakukan prosesnya dengan cepat. Sistem basis data dapat menampilkan tabel (query) yang menampilkan data-data yang berhubungan. Sistem basis data mampu menyimpan data-data konsumen yang berhubungan dengan transaksi ragum. Sistem basis data mampu mengakomodasi pencatatan penanganan claim-claim dari konsumen serta mengirimkan report atas claim-claim yang disampaikan. Pencatatan ini harus dapat dilakukan dan di-retrieve sewaktu-waktu dengan tujuan: y PT PTI dapat selalu meninjau claim apa saja yang sudah atau belum ditangani untuk menjaga kepercayaan konsumen. y PT PTI dapat mencatat jenis-jenis claim apa saja yang diajukan oleh konsumen untuk kemudian dianalisis claim apa saja yang harus segera ditangani y PT PTI dapat mencatat dan menganalisis penyebab-penyebab terjadinya claim sehingga dapat ditangani secepatnya. Sistem basis data harus mampu membuat report sebagai dasar pengambilan keputusan oleh pihak manajemen. Report yang diperlukan oleh divisi

Melakukan Jual Beli

y y Melakukan Layanan Purna Jual

Membuat Laporan Kinerja Perusahaan

marketing antara lain: laporan transaksi konsumen (yang juga dapat menghitung total pemasukan), laporan penanganan claim, laporan kepemilikan dan penggunaan inventaris perusahaan, dan laporan promosi-promosi yang dilakukan oleh agen iklan yang disewa PT PTI.

Josef Novan Lumbantobing (13405071)

Halaman 3 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

2.1.2. Non-functional Requirement Berdasarkan klasifikasi PIECES, non-functional requirement dari sistem informasi PT PTI yaitu: Non-functional Needs requirement type y Response time yang cepat, mudah diakses. Performance y Reliable. y Mampu memfasilitasi beberapa pekerjaan dalam waktu yang bersamaan. y Mampu menerima input, mengolah, dan menampilkan Information output data-data divisi marketing perusahaan untuk frekuensi yang sering karena permintaan data untuk divisi ini cukup sering (misalnya: untuk penanganan claim, pelayanan transaksi, promosi, dll). y Mampu menyimpan data secara teratur dan sistemik, tidak ada redundancy dan anomaly. y Melindungi data dari kerusakan baik karena virus maupun kecelakaan fisik. y Mampu me-maintain data dengan kapasitas (memori) dan waktu yang tinggi. y Biaya instalasi dan maintenance yang terjangkau. Economy

Control (and security)

Efficiency

Service

y Kebutuhan keamanan akan sistem informasi yang diperlukan divisi marketing PT PTI tergolong tinggi, mengingat salah satu proses bisnisnya adalah menentukan strategi pemasaran yang sifatnya rahasia untuk perusahaan. y Mampu mengakomodasi orang-orang tertentu saja yang dapat mengakses data. y Mampu menghindari kesalahan karena faktor manusia maupun mesin. y User interface sistem informasi harus user-friendly untuk memudahkan user dan menghindari kerancuan sehingga waktu inputing data dan retrieval dapat direduksi. y Material serta tenaga dalam proses pengelolaan sistem informasi tidak berlebihan. y Mampu mengakomodasi tipe users yang berbeda-beda karena aliran data mengalir dari berbagi user di divisi marketing, misalnya: kasir transaksi, manajer pemasaran, dll. y Mampu memfasilitasi report. y Mudah digunakan, fleksibel terhadap perubahan, dan compatible akan sistem lain.

2.1.3. Identifikasi Entitas dan Relasi Antar Entitas Berdasarkan requirement analysis, ada 12 entitas yang dibutuhkan dalam menjalankan fungsi perusahaan pada divisi marketing. Berikut ini adalah identifikasi entitas dan alasan pengadaan entitas tersebut (detail atribut dijabarkan pada poin 2.2.1) antara lain: No. Entitas Keterangan 1. Pegawai WHY? Entitas pegawai mutlak diperlukan dalam perancangan sistem basis data divisi marketing karena pegawai

melakukan proses bisnis menyusun strategi pemasaran, mempromosikan produk, melakukan jual-beli, melakukan layanan purna jual, dan memberikan laporan kinerja perusahaan melalui kegiatan : meng-update inventori,
Josef Novan Lumbantobing (13405071) Halaman 4 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

menentukan strategi pemasaran, menggunakan inventaris, memilih agen iklan, menganalis anggaran, melayani claim, menganalisis segmen pasar, mencatat transaksi, serta menganalisis kompetitor. WHAT? Data entitas pegawai berisi data-data seluruh pegawai divisi marketing mulai dari kasir, teknisi, manajer, dll. Adanya atribut jabatan pada entitas pegawai akan membedakan jabatan setiap pegawai.
2. Segmen Pasar WHY? Entitas segmen pasar diperlukan karena untuk melakukan proses bisnis : menyusun strategi pemasaran, pegawai akan terlebih dahulu menganalisis data-data segmen pasar yang ada pada entitas segmen pasar.

WHAT?
Data entitas segmen pasar berisi data-data hasil segmenting (membagi pasar menjadi beberapa segmen berdasarkan demografi dan preferensi) WHY? Entitas konsumen diperlukan karena entitas ini terlibat dalam proses bisnis perusahaan : melakukan jual-beli dan melakukan layanan purna jual.

3.

Konsumen

WHAT?
Data entitas konsumen berisi data-data konsumen yang pernah melakukan transaksi jual-beli ragum dengan PT PTI. WHY? Entitas claim diperlukan karena salah satu proses bisnis perusahaan adalah melakukan layanan purna jual. Layanan purna jual diidentifikasi melalui claim-claim yang diajukan oleh konsumen.

4.

Claim

WHAT? Data entitas claim berisi data-data keluhan yang disampaikan oleh entitas konsumen terkait dengan transaksi ragum.
5. Transaksi WHY? Entitas transaksi diperlukan karena terkait dengan proses bisnis melakukan proses jual-beli. Data-data transaksi merupakan data yang penting untuk disimpan oleh perusahaan.

WHAT? Data entitas transaksi berisi data-data yang terkait dengan proses transaksi ragum antara konsumen dengan perusahaan (antara entitas konsumen dengan pegawai).
6. Kompetitor WHY? Entitas kompetitor diperlukan terkait dengan proses bisnis menentukan strategi pemasaran karena dalam penentuan strategi pemasaran, perusahaan (pegawai) terlebih dahulu menganalisis keadaan kompetitor (market share, data penjualan kompetitor, dll).

7.

Agen Iklan

WHAT? Data entitas kompetitor berisi data-data perusahaan pesaing yang relevan dalam penentuan strategi pemasaran. WHY?
Halaman 5 dari 43

Josef Novan Lumbantobing (13405071)

Modul 4 Perancangan Basis Data

Kelompok 10

Entitas agen iklan diperlukan karena terkait dengan proses bisnis: mempromosikan produk. Agen iklan bertugas untuk menghasilkan promosi produk. Oleh sebab itu data-data agen iklan penting disimpan untuk penentuan agen iklan mana yang cocok digunakan pada suatu strategi pemasaran.
WHAT? Data entitas agen iklan berisi data-data setiap agen iklan yang disewa oleh perusahaan untuk melakuan promosi ragum. WHY? Entitas inventaris diperlukan karena terkait dengan seluruh proses bisnis perusahaan. Dalam menjalankan proses bisnisnya, pegawai menggunakan inventaris peralatan kantor, seperti : meja, kursi, komputer, obeng, kertas, dll. Pencatatan akan aset perusahaan ini adalah hal yang penting.

8.

Inventaris

WHAT? Data entitas inventaris berupa data-data seluruh inventaris, peralatan kantor yang diperlukan oleh perusahaan dalam menjalankan proses bisnisnya.
9. Strategi Pemasaran WHY? Entitas strategi perusahaan diperlukan karena merupakan output dari proses bisnis menentukan strategi pemasaran. Data strategi pemasaran setiap periode perlu disimpan sebagai dokumentasi perusahaan.

WHAT? Data entitas strategi pemasaran berupa data-data mengenai strategi pemasaran yang akan dijalankan oleh perusahaan.
10. Promosi WHY? Entitas promosi diperlukan karena terkait dengan proses bisnis mempromosikan produk. Entitas produk dihasilkan oleh entitas agen iklan. Data entitas promosi diperlukan untuk meninjau sejauh mana keberhasilan promosi ragum yang dilakukan oleh agen iklan.

WHAT? Data entitas promosi berupa data-data hasil promosi yang dilakukan oleh agen iklan, misalnya: jenis promosi (koran, reklame, brosur, dll) serta jumlah promosinya.
11. Inventori WHY? Entitas inventori diperlukan karena terkait dengan proses bisnis melakukan jual-beli. Data ini perlu disimpan untuk melihat kondisi gudang (banyaknya persediaan ragum) sebelum dan sesudah transaksi.

WHAT? Data entitas ini berupa data-data mengenai inventori (persediaan dalam gudang), yaitu: jenis inventori, periode, dan jumlahnya.
12. Anggaran WHY? Entitas anggaran diperlukan karena terkait dengan proses bisnis menentukan strategi pemasaran. Anggaran pada suatu periode akan membatasi alternatif-alternatif strategi pemasaran yang ditempuh pada periode tersebut.

WHAT?
Josef Novan Lumbantobing (13405071) Halaman 6 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

Data entitas anggaran berupa data-data anggaran yang dialokasikan untuk divisi marketing setiap periode.
Sedangkan, identifikasi relasi antar entitas antara lain: 1. Agen Iklan - Promosi

Hubungan relasi agen iklan dengan promosi adalah one-to-many. Satu agen iklan dapat menghasilkan banyak promosi, sedangkan satu promosi hanya dihasilkan oleh satu agen iklan.
2. Pegawai Inventori

Hubungan relasi pegawai dengan inventori adalah one-to-many. Satu pegawai mengupdate (kondisi) banyak inventori, sedangkan satu inventori hanya diupdate oleh satu pegawai.
3. Pegawai Strategi Pemasaran

Hubungan relasi pegawai dengan strategi pemasaran adalah one-to-many. Satu pegawai dapat menentukan banyak strategi pemasaran, sedangkan satu strategi pemasaran hanya ditentukan oleh satu pegawai (pada PT PTI, strategi pemasaran diputuskan oleh manajer divisi marketing)
4. Pegawai Inventoris

Hubungan pegawai dengan inventaris adalah many-to-many. Seorang pegawai dapat menggunakan banyak inventaris, demikian pula sebaliknya, satu inventaris dapat digunakan oleh banyak pegawai. Berbeda dengan inventori, inventaris dapat digunakan berkali-kali. Contohnya: inventaris sebuah obeng yang dapat digunakan berkali kali oleh pegawai yang berbeda untuk perbaikan ragum yang di-claim konsumen. Untuk menghindari many-tomany relationship ini, normalisasi perlu dilakukan.
5. Pegawai Agen Iklan

Josef Novan Lumbantobing (13405071)

Halaman 7 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

Hubungan pegawai dengan agen iklan adalah one-to-many. Seorang pegawai dapat memilih banyak agen iklan, sedangkan satu agen iklan dipilih oleh satu pegawai. 6. Pegawai Anggaran

Hubungan pegawai dengan anggaran adalah one-to-many. Seorang pegawai dapat menganalisis banyak anggaran, sedangkan satu anggaran dianalisis oleh satu pegawai. Dalam proses analisis anggaran keuangan divisi marketing PT PTI, tiap analis keuangan memiliki tanggung jawab untuk menganalisis beberapa anggaran, kemudian masing-masing analis memberi summary hasil analisisnya pada manajer divisi.
7. Pegawai Claim

Hubungan pegawai dengan claim adalah many-to-many (catatan: claim di sini adalah jenis claim, bukan keluhan produk yang spesifik). Seorang pegawai melayani banyak claim dan satu claim dilayani oleh banyak pegawai karena seringkali sebuah claim memerlukan beberapa keahlian pegawai yang berbeda dalam proses penanganannya. Untuk menghindari many-to-many relationship, normalitas perlu dilakukan.
8. Pegawai Segmen Pasar

Hubungan pegawai dengan segmen pasar adalah one-to-many. Seorang pegawai dapat menganalisis banyak segmen pasar, sedangkan satu segmen pasar dianalisis oleh satu pegawai. Dalam proses analisis segmen pasar PT PTI, setiap market analyst bertugas untuk menganalisis beberapa segmen pasar. Hasil analisis segmen pasa ini yang menjadi r salah satu dasar bagi manajer divisi marketing untuk menentukan strategi pemasaran.
9. Pegawai Transaksi

Hubungan pegawai dengan transaksi adalah one-to-many. Seorang pegawai dapat mencatat banyak transaksi, sedangkan satu transaksi hanya dicatat oleh satu pegawai (dalam hal ini pegawai yang berjabatan kasir).
10. Pegawai Kompetitor

Josef Novan Lumbantobing (13405071)

Halaman 8 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

Hubungan pegawai dengan kompetitor adalah one-to-many. Seorang pegawai dapat menganalisis banyak kompetitor, sedangkan satu kompetitor hanya dianalisis oleh satu pegawai. Hal ini dikarenakan pada proses analisis kondisi pasar, PT PTI memiliki kebijakan untuk membagi-bagi pekerjaan pada setiap analyst. Seorang analyst berkewajiban untuk menganalisis beberapa kompetitor, hasil analisis setiap kompetitor ini kemudian menjadi bahan pertimbangan manajer divisi marketing untuk menentukan strategi pemasaran.
11. Konsumen Claim

Hubungan konsumen dengan claim adalah many-to-many (catatan: claim di sini adalah jenis claim, bukan keluhan produk yang spesifik). Seorang konsumen dapat mengajukan banyak claim. Begitu pula sebaliknya, satu jenis claim dapat diajukan oleh banyak konsumen karena seringkali beberapa konsumen mengeluhkan je claim yang sama, nis misalnya: produk cacat, delivery time terlambat. Untuk menghindari many-to-many relationship seperti ini, perlu dilakukan normalisasi.
12. Konsumen Transaksi

Hubungan konsumen dengan transaksi adalah one-to-many. Seorang konsumen dapat melakukan banyak transaksi, sedangkan satu transaksi hanya dilakukan oleh satu konsumen.

Josef Novan Lumbantobing (13405071)

Halaman 9 dari 43

Modul 4 Perancangan Basis Data 2.2. Analysis 2.2.1. Identifikasi Detail Entitas
No. 1 Entitas Strategi Pemasaran Atribut I Strategi Pemasaran (PK)

Kelompok 10

Tipe Autonumber Text Number Autonumber Text Number Number Number Autonumber Text Number Autonumber Number Text Text Text Autonumber Number Text Date/Time

Jenis Strategi I Pegawai (FK) 2 Inventory I Inventory (PK) Jenis Inventory Jumlah Inventory Periode I Pegawai (FK) 3 Inventaris I Inventaris (PK) Jenis Inventaris Jumlah Inventaris I Agen Iklan (PK)

Agen Iklan

I Pegawai (FK) Nama Agen Iklan Alamat Agen Iklan Jenis Agen Iklan I Promosi (PK)

Promosi

I Agen Iklan (FK) Jenis Promosi Periode Promosi

Alasan Sebagai penentu jenis strategi pemasaran yang ada ijadikan Primary Key karena satu I hanya ada satu jenis strategi Untuk mendeskripsikan semua jenis strategi PT. PTI Untuk melihat siapa yang menentukan jenis strategi Merupakan primary key yang dikirim dari tabel Pegawai Sebagai penentu tipe inventory yang ada ijadikan Primary Key karena satu I hanya ada satu tipe inventory Mendeskripsikan tipe inventori tercatat igunakan untuk melihat berapa stock suatu tipe inventory yang tersedia Untuk melihat kapan inventori terkait diproduksi Untuk melihat siapa yang bertanggung jawab mencatat inventory yang ada atau digunakan Merupakan primary key yang dikirim dari tabel Pegawai Sebagai penentu tipe inventaris perusahaan yang ada ijadikan Primary Key karena satu I hanya ada untuk satu jenis inventaris Mendeskripsikan seluruh jenis invetaris perusahaan igunakan untuk menunjukan stock inventaris yang dimiliki perusahaan saat ini Sebagai penentu jenis agen iklan yang terdata ijadikan Primary Key karena satu I hanya ada satu jenis agen iklan Untuk melihat siapa yang menentukan agen iklan Merupakan primary key yang dikirim dari tabel Pegawai Untuk mengetahui agen iklan yang dipilih dan untuk dihubungi Untuk melihat alamat agen iklan yang dipilih Mendeskripsikan seluruh jenis agen iklan yang dipilih Sebagai penentu jenis promosi yang tersedia ijadikan Primary Key karena satu I hanya ada satu jenis promosi Sebagai penentu jenis agen iklan yang terdata Merupakan primary key yang dikirim dari tabel Agen Iklan Mendeskripsikan seluruh jenis promosi yang tersedia Untuk melihat kapan promosi diberlakukan

Josef Novan Lumbantobing (13405071)

Halaman 10 dari 43

Modul 4 Perancangan Basis Data

No. Entitas Atribut ID Anggaran (PK) 6 Anggaran ID Pegawai (FK) Jumlah Anggaran Periode Anggaran ID Konsumen (PK) 7 Konsumen Nama Konsumen Telepon Konsumen Alamat Konsumen ID Transaksi (FK) ID Detail Claim (PK) ID Konsumen (FK) 8 Detail Claim ID Claim (FK) Tanggal Pengajuan Claqim Keterangan 9 Claim ID Claim (PK Jenis Claim ID Detail Pelayanan Claim (PK) Detail Pelayanan Claim ID Claim (FK) ID Pegawai (FK) Tanggal Pelayanan Claim Penyebab Kerusakan ID Transaksi (PK) 11 Transaksi Tanggal Transaksi Total Pembayaran ID Pegawai (FK) Number Date/Time Text Autonumber Text Autonumber Number Number Date/Time Text Autonumber Date/Time Number Number Tipe Autonumber Number Currency Date/Time Autonumber Text Number Text Number Autonumber Number

Kelompok 10
Alasan Sebagai penentu tipe anggaran yang ada Dijadikan Primary Key karena satu ID hanya ada satu tipe anggaran Untuk melihat siapa yang memakai anggaran dan bertanggung jawab mencatatnya Merupakan primary key yang dikirim dari tabel Pegawai Untuk melihat jumlah anggaran yang disediakan Untuk melihat kapan invetori terkait diproduksi Sebagai penentu konsumen yang terdata Dijadikan Primary Key karena satu ID hanya ada satu konsumen Untuk mengetahui nama konsumen Untuk mengetahui nomor telepon konsumen yang dapat dihubungi Untuk mengetahui alamat konsumen Untuk melihat transaksi yang dilakukan konsumen Merupakan primary key yang dikirim dari tabel transaksi Sebagai penentu detail apa saja yang ada didalam claim yang dilakukan oleh konsumen Dijadikan Primary Key karena satu ID hanya ada satu detail claim Untuk melihat data konsumen yang melakukan claim Merupakan primary key yang dikirim dari tabel konsumen Untuk melihat data claim yang diajukan oleh konsumen Merupakan primary key yang dikirim dari tabel claim Untuk mengetahui kapan konsumen mengajukan claim Untuk mengetahui penejelasan mengenai claim yang diajukan konsumen. Sebagai penentu claim yang diajukan oleh konsumen Dijadikan Primary Key karena satu ID hanya ada satu claim Untuk mengetahui jenis claim yang diajukan oleh konsumen Sebagai penentu detail pelayanan claim yang telah dilakukan oleh pegawai Dijadikan Primary Key karena satu ID hanya ada satu detail pelayanan claim Untuk melihat data claim yang diajukan oleh konsumen Merupakan primary key yang dikirim dari tabel claim Untuk melihat data pegawai yang menangani claim yang diajukan konsumen Merupakan primary key yang dikirim dari tabel Pegawai Untuk melihat kapan claim konsumen dilayani oleh pegawai Untik melihat penyebab konsumen mengajukan claim Sebagai penentu transaksi yang dilakukan oleh konsumen Dijadikan Primary Key karena satu ID hanya ada satu detail transaksi Untuk mengetahui kapan transaksi dilakukan Untuk mengetahui total pembayaran yang dilakukan oleh konsumen Untuk melihat data pegawai yang menangani transaksi dengan konsumen Merupakan primary key yang dikirim dari tabel Pegawai

10

Josef Novan Lumbantobing (13405071)

Halaman 11 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

No.

Entitas

Atribut ID Segmen Pasar (PK)

Tipe Autonumber Text Text Number Autonumber Text Number Number Number Autonumber Text Date/Time Text Text Autonumber Number Number Date/Time

12

Segmen Pasar

Preferensi Pasar Jenis Segmen Pasar ID Pegawai (FK) ID Kompetitor (PK)

13

Kompetitor

Nama Kompetitor Data Penjualan Kompetitor Market Share Kompetitor ID Pegawai (FK) ID Pegawai (PK)

14

Pegawai

Nama Pegawai Tanggal Lahir Alamat Pegawai Jabatan Pegawai ID Detail Inventaris (PK)

15

Detail Inventaris

ID Pegawai (FK) ID Inventaris (FK) Tanggal Penggunaan

Alasan Sebagai penentu segmen pasar yang menjadi target Dijadikan Primary Key karena satu ID hanya ada satu segmen pasar Untuk mengetahui variabel preferensi dari segmen pasar yang dijadikan target Untuk mengetahui jenis segmen pasar yang dijadikan target Untuk melihat data pegawai yang menganalisis segmen pasar Merupakan primary key yang dikirim dari tabel Pegawai Sebagai penentu kompetitor di daerah yang menjadi target perusahaan Dijadikan Primary Key karena satu ID hanya ada satu kompetitor Untuk mengetahui nama perusahaan kompetitor Untuk mengetahui berapa banyak produk yang dijual kompetitor kepada kkonsumen Untuk mengetahui berapa % kompetitor tersebut menguasai pasar Untuk melihat data pegawai yang menganalisis kompetitor Merupakan primary key yang dikirim dari tabel Pegawai Sebagai penentu pegawai perusahaan yang mengurus berbagai kegiatan perusahaan Dijadikan Primary Key karena satu ID hanya ada satu pegawai Untuk mengetahui nama pegawai Untuk mengetahui tanggal lahir dan umur pegawai Untuk mengetahui alamat tempat pegawai tersebut tinggal Untuk mengetahui jabatan dan jobdesc pegawai tersebut Sebagai penentu detail inventaris yang dibutuhkan pegawai Dijadikan Primary Key karena satu ID hanya ada satu detail inventaris Untuk melihat data pegawai yang memerlukan inventaris Merupakan primary key yang dikirim dari tabel Pegawai Untuk melihat inventaris apa saja yang dimiliki oleh perusahaan Merupakan primary key yang dikirim dari tabel inventaris Untuk mengetahui kapan inventaris tersebut dibutuhkan

Josef Novan Lumbantobing (13405071)

Halaman 12 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

2.2.2. Conceptual Data Model Pada tahapan ini dibuat diagram yang menghubungkan seluruh entitas di dalam sistem basis data beserta hubungan antar entitas-entitas tersebut sehingga diperoleh Conceptual Data Model sebagai berikut:

2.3. Logical Database Design 2.3.1. Logical Data Model Pada tahap ini dilakukan normalisasi, yaitu mentransformasi struktur data menjadi lebih kecil dan stabil. Setelah dinormalisasi, maka sudah tidak terdapat hubungan many to many seperti terlihat pada ERD di bawah ini.

Josef Novan Lumbantobing (13405071)

Halaman 13 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

Pada Microsoft Access, hubungan tersebut tergambar sebagai berikut:

Josef Novan Lumbantobing (13405071)

Halaman 14 dari 43

Modul 4 Perancangan Basis Data Logical Data Model yang dihasilkan adalah:

Kelompok 10

Josef Novan Lumbantobing (13405071)

Halaman 15 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

2.3.2. Analisis Normalisasi yang Dilakukan 1. Relasi antara Pegawai dan Inventaris Pada Conceptual Data Model, relasi yang terbentuk antara pegawai dan inventaris adalah many to many. Seorang pegawai dapat memakai banyak inventaris dan juga sebuah inventaris dapat dipakai oleh banyak pegawai sehingga satu ID Pegawai dapat tercatat pada lebih dari satu ID Inventaris atau sebaliknya. Relasinya tergambar sebagai berikut:

Oleh sebab itu, ditambahkan sebuah entitas baru bernama Detail Inventaris yang menghubungkan pegawai dan inventaris agar menghindari keabnormalan hubungan tersebut sehingga relasi yang baru berbentuk:

Detail Inventaris memuat atribut ID Detail Inventaris, ID Pegawai, ID Inventaris, dan Tanggal Penggunaan. Satu ID Pegawai akan terdapat dala banyak ID Detail m Inventaris sedangkan satu ID Detail Inventaris hanya akan berpasangan dengan satu ID Pegawai sehingga hubungan Pegawai ke Detail Inventaris adalah one to many. Satu ID Inventaris akan terdapat dalam banyak ID Detail Inventaris sedangkan satu ID Detail Inventaris hanya akan berpasangan dengan satu ID Inventaris sehingga hubungan Inventaris ke Detail Inventaris adalah one to many. Dengan hubungan ini sudah tidak terdapat redudansi data. 2. Relasi antara Pegawai dan Claim Pada Conceptual Data Model, relasi yang terbentuk antara pegawai dan claim adalah many to many. Sebuah claim dapat dilayani oleh lebih dari satu pegawai tergantung dari keperluannya. Seorang pegawai dapat melayani berbagai claim yang masuk ke perusahaan. Kedua entitas ini berelasi sebagai berikut:

Karena hubungan di atas akan menyebabkan redudansi, perlu ditambahkan entitas baru untuk menghubungkan pegawai dan claim sehingga dibuat entitas baru bernama Detail Pelayanan Claim yang menyebabkan relasi baru yaitu:

Pada atribut Detail Pelayanan Claim terdapat atribut ID Detail Pelayanan Claim, ID Pegawai, ID Claim, Tanggal Pelayanan Claim, dan Penyebab Kerusakan. Satu ID Pegawai akan terdapat dalam banyak ID Detail Pelayanan Claim sedangkan satu ID Detail Pelayanan Claim hanya akan berpasangan dengan satu ID Pegawai sehingga hubungan Pegawai ke Detail Pelayanan Claim adalah one to many. Satu ID Claim akan terdapat dalam banyak ID Detail Pelayanan Claim sedangkan satu ID Detail Josef Novan Lumbantobing (13405071) Halaman 16 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

Pelayanan Claim hanya akan berpasangan dengan satu ID Claim sehingga hubunga n Claim ke Detail Pelayanan Claim adalah one to many sehingga sudah tidak terdapat keabnormalan relasi. 3. Relasi antara Konsumen dan Claim Pada Conceptual Data Model, relasi yang terbentuk antara pegawai dan claim adalah many to many. Seorang konsumen yang sama dapat mengajukan banyak claim sesuai dengan jumlah dan waktu pembelian produk. Sebuah jenis claim dapat diajukan oleh banyak konsumen jika permasalahan yang terjadi adalah sama. Relasi yang terbentuk adalah:

Dibentuk entitas baru untuk menghindari hubungan di atas sehingga relasi antara konsumen dan claim sekarang terhubung lewat entitas Detail Claim seperti dalam gambar berikut:

Detail Inventaris memuat atribut ID Detail Claim, ID Konsumen, ID Claim, Tanggal Pengajuan Claim, dan Keterangan. Satu ID Konsumen akan terdapat dalam banyak ID Detail Claim sedangkan satu ID Detail Claim hanya akan berpasangan dengan satu ID Konsumen sehingga hubungan Konsumen ke Detail Claim adalah one to many. Satu ID Claim akan terdapat dalam banyak ID Detail Claim sedangkan satu ID Detail Claim hanya akan berpasangan dengan satu ID Claim sehingga hubungan Claim ke Detail Claim adalah one to many. Dengan hubungan ini sudah tidak terdapat redudansi data.

Josef Novan Lumbantobing (13405071)

Halaman 17 dari 43

Modul 4 Perancangan Basis Data 2.4. Physical Database Design 2.4.1. Physical Data Model

Kelompok 10

2.4.2. Analisis Tipe-tipe Data yang Digunakan dengan Akomodasi DBMS yang Digunakan (Ms. Access) 1. Autonumber Tipe data ini secara otomatis akan memberikan nilai yang berurutan, dimulai dari 1. Tipe data ini digunakan umumnya digunakan untuk menginput ID entitas secara otomatis. Tipe data ini nyaman untuk digunakan dalam penomoran ID, dan formatnya dapat di edit untuk menambahkan. Contoh, di formatnya ditambah 13406xxx, sehingga autonumbernya menjadi 13406001,13406002, dst. Pada DBMS ini tipe data autonumber digunakan pada field : ID Strategi Pemasaran, ID Agen Iklan, ID Inventaris, ID Promosi, ID Detail Inventaris, ID Claim, ID Detail Claim, ID Pelanggan, ID Invevntori, ID Kompetitor, ID Konsumen, ID Transaksi, ID Segmen Pasar, dan ID Anggaran. 2. Text Tipe data ini digunakan untuk menginput field yang berupa huruf , angka (yang dianggap sebagai text), atau simbol-simbol. Karena field ini dianggap sebagai text, maka tidak dapat digunakan untuk perhitungan.

Josef Novan Lumbantobing (13405071)

Halaman 18 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

Pada DBMS ini tipe data text digunakan pada field : Nama Pegawai, Nama Konsumen, Alamat Konsumen, Jenis Claim, Nama Agen Iklan, Alamat Agen Iklan, Nama Kompetitor,Penyebab Kerusakan, Jumlah Inventaris, Periode Promosi, dll 3. Number Tipe data ini digunakan untuk menginput field yang khusus berupa angka, termasuk minus ataupun desimal. Pada DMBS ini tipe data number digunakan pada field : Telepon Konsumen, Jumlah Inventori dll. Date/time Tipe data ini digunakan untuk menginput field yang berupa tanggal (hari/bulan/tahun). Tipe data ini umumnya digunakan untuk entitas tanggal-tanggal tertentu, misalnya tanggal lahir, tanggal transaksi, dll. Pada DMBS ini tipe data date/time digunakan pada field : Tanggal Transaksi, Tanggal Penggunaan, Tanggal Pengajuan Claim, dll.

4.

Josef Novan Lumbantobing (13405071)

Halaman 19 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

2.5. Implementasi 2.5.1 User Interface Berikut ini adalah tree diagram dari menu-menu yang ada pada sistem basis data divisi marketing PT PTI.

Josef Novan Lumbantobing (13405071)

Halaman 20 dari 43

Bagian I nternal

Modul 4 Perancangan Basis Data

Kelompok 10

User interface dimulai dari menu utama. Pada menu utama terdapat tiga pilihan, yaitu Bagian Internal, Claim Konsumen, dan Eksternal dan Hubungan ke Luar. Bagian Internal terdiri dari entitas-entitas yang merupakan internal dari divisi marketing, yaitu Database inventaris, database anggaran, Database inventori, Database strategi pemasaran, Database inventori, database promosi dan Database pegawai. Bagian ini mewakili bagian internal divisi dan menyediakan data mengenai pegawai , alokasi anggaran, strategi pemasaran dan promosi yang dilakukan. Claim Konsumen terdiri dari entitas-entitas yang berhubungan dengan konsumen dan claimclaim yang diajukan oleh konsumen. Bagian ini terdiri dari database claim konsumen, detail claim, dan detail pelayanan claim. Bagian ini berhubungan langsung dengan konsumen dan menyediakan data komplain yang diajukan konsumen, serta penanganannya (after sales service). External dan hubungan luar teridiri dari entitas-entitas luar perusahaan yang tidak dapat dikendalikan. Bagian ini terdiri dari database agen iklan, database kompetitor, database konsumen dan database segmen pasar. Bagian ini menyediakan data mengenai faktor-faktor lingkungan dan potensi pasar yang menjadi target. Untuk beberapa bagian yang dirasa perlu, terdapat query yang menampilkan tabel berupa field-field yang saling berelasi dan memberikan informasi. Setiap bagian memiliki menu input data dan edit data. Menu input data berguna sebagai form memasukkan atau menambah data pada database, sedangkan menu edit data digunakan untuk mengedit/mengganti data yang su dah di-input sebelumnya.
1. Menu Utama

2. Menu Database Inventaris

Josef Novan Lumbantobing (13405071)

Halaman 21 dari 43

Modul 4 Perancangan Basis Data 3. Menu Tambah Data Inventaris

Kelompok 10

4. Menu Edit Data Inventaris

5.

Database Anggaran

Josef Novan Lumbantobing (13405071)

Halaman 22 dari 43

Modul 4 Perancangan Basis Data 6. Menu Tambah Data Anggaran

Kelompok 10

7.

Menu Edit Data Anggaran

8.

Menu Database Inventori

9.

Menu Tambah Data Inventori

Josef Novan Lumbantobing (13405071)

Halaman 23 dari 43

Modul 4 Perancangan Basis Data 10. Menu Edit Data Inventori

Kelompok 10

11. Menu Database Strategi Pemasaran

12. Menu Tambah Database Strategi Pemasaran

13. Menu Edit Database Strategi Pemasaran

Josef Novan Lumbantobing (13405071)

Halaman 24 dari 43

Modul 4 Perancangan Basis Data 14. Menu Detail Inventaris

Kelompok 10

15.

Menu Tambah Detail Invetaris

16.

Menu Edit Detail Inventaris

17.

Menu Claim Konsumen

Josef Novan Lumbantobing (13405071)

Halaman 25 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

18. Claim

19. Form Claim

20. Detail Claim

21.

Form Detail Claim

Josef Novan Lumbantobing (13405071)

Halaman 26 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

22.

Detail Pelayanan Claim

23.

Form Detail Pelayanan Claim

24.

Bagian Eksternal dan Hubungan Luar

Josef Novan Lumbantobing (13405071)

Halaman 27 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

25. Agen Iklan

26. Form Agen Iklan

27. Kompetitor

28. Form Kompetitor

Josef Novan Lumbantobing (13405071)

Halaman 28 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

29.Konsumen

30. Form Konsumen

31. Segmen Pasar

Josef Novan Lumbantobing (13405071)

Halaman 29 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

32. Form Segmen Pasar

2.5.2 Query Dalam sistem database kali ini, query yang dibuat sebanyak 4 buah. Query tersebut terdiri dari: 1. Query konsumen Query ini mengumpulkan data-data pribadi konsumen. Query ini akan mengurutkan data konsumen dari ID terkecil hingga ID terbesar. Hal ini bertujuan untuk memudahkan user mengetahui urutan konsumen yang melakukan transaksi dengan bagian pemasaran. Perintah untuk mengurutkan ID konsumen terlihat pada gambar dibawah ini:

Hasil design untuk query dapat dilihat seperti berikut:

Selain itu, query ini hanya menampilkan data pribadi konsumen saja. Hal ini berguna nantinya sebagai report pada user agar user mudah melihat data konsumen secara cepat dan teliti (tidak tercampur dengan data yang lain). 2. Query Claim Query ini dibuat untuk memudahkan urutan proses pelayanan untuk masalah claim konsumen. Pada query ini terdapat tanggal pengajuan claim yang diurutk an berdasarkan waktunya. Sehingga pelayanan akan diutamakan kepada konsumen yang lebih dahulu mengajukan klaim. Selain itu, pada query ini juga mengumpulkan informasi-informasi yang terkait dengan masalah pengajuan claim. Sehingga informasi yang terkait mengambil informasi dari beberapa tabel yaitu: tabel detail claim(berupa tanggal pengajuan, ID detail claim, Keterangan), tabel

Josef Novan Lumbantobing (13405071)

Halaman 30 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

konsumen (berupa nama konsumen), tabel detail pelayanan claim (berupa tanggal pelayanan claim, penyebab kerusakan). Hal ini dibuat agar memudahkan user melihat informasi terkait pengajuan claim. Bentuk query yang dimaksud dapat terlihat pada gambar dibawah ini:

Sedangkan tampilan design-nya seperti:

3. Query Detail Inventaris Seperti halnya dengan query claim, query ini memiliki tujuan untuk mengurutkan tanggal penggunaan barang-barang inventaris.Dengan adanya pengurutan data ini maka kita dapat mengetahui penggunaan barang -barang inventaris, sehingga bila terjadi kehilangan, user dapat dengan mudah melacak kapan peristiwa kehilangan tersebut terjadi. Pada query ini informasi yang dilibatkan meliputi tabel inventaris dan tabel data inventaris.

Josef Novan Lumbantobing (13405071)

Halaman 31 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

4. Query Promosi Query ini dibuat untuk mengelompokan jenis promosi yang terka dengan kegiatan it pemasaran. Hal ini bertujuan agar user dapat dengan mudah berapa banyak agen iklan yang menyediakan suatu jenis promosi. Selain itu, penamaan jenis promosi juga diurutkan sesuai abjad. Hal ini bertujuan agar user merasa lebih nyaman dala m mebaca informasi. Tabel-tabel yang tekait dalam query ini antara lain: tabel promosi (melingkupi jenis promosi, periode promosi), dan tabel agen iklan (meliputi ID agen iklan, nama agen iklan, alamat agen iklan, jenis agen iklan).

Josef Novan Lumbantobing (13405071)

Halaman 32 dari 43

Modul 4 Perancangan Basis Data 2.5.3 Report Berikut ini report yang ada pada sistem basis data divisi marketing PT PTI

Kelompok 10

Data Claim adalah record yang berisi data-data ringkasan yang menunjukkan penjelasan mengenai claim yang diajukan oleh konsumen, termasuk penyebabnya dan tanggal pengajuan dan penangan claim yang diajukan. Data ini dapat digunakan untuk mengevaluasi after sales ervice yang s dilakukan oleh divisi marketing serta penyebab claim-claim yang dilakukan oleh konsumen agar dapat dievaluasi oleh divisi R & D.

Josef Novan Lumbantobing (13405071)

Halaman 33 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

Data Konsumen adalah record yang berisi data-data ringkasan mengenai konsumen yang menunjukkan penjelasan mengenai konsumen dan tr nsaksi yang a dilakukan konsumen. Data ini dapat digunakan untuk melihat konsumen -konsumen yang telah melakukan transaksi, termasuk jumlah pembayaran, tanggal transaksi, nomor telepon konsumen, dan alamat konsumen. ID Konsumen tidak berdasarkan kapan ia mel kukan transaksi pembayaran. a

Data Detail Inventaris berisi data mengenai inventaris yang dimiliki oleh perusahaan, termasuk jumlah dan kapan penggunaannya .Data ini dapat mengecek alur penggunaan invetaris perusahaan dan kapan penggunaannya. Jika digabung dengan data pelayanan claim, dapat mengidentifikasi invetaris yang dibutuhkan kan untuk melayani claim pelanggan ataupun inventaris yang dibutuhkan selain untuk melayaniclaim pelanggan.

Josef Novan Lumbantobing (13405071)

Halaman 34 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

Data Promosi ini berisi data mengenai promosi yang dilakukan perusahaan kepada pasar. Data ini berisi jenis promosi yang dilakukan, periode promosi (kapan promosi tersebut dijalankan), dan agen iklan yang melakukan promosi. Dengan digabungkan dengan data -data penjualan dapat mengevaluasi efektifitas promosi yang dilakukan.

Josef Novan Lumbantobing (13405071)

Halaman 35 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

BAB III ANALISIS

3.1. Analisis Perbandingan Metode-metode Normalisasi Normalisasi adalah teknik untuk memastikan sebuah database terbebas dari anomali data dan redudansi data. Terdapat berbagai metode untuk melakukan normalisasi. Metode yang akan dibandingkan kali ini adalah metode modul dan metode normal form. Metode modul adalah metode normalisasi yang terdapat pada Modul 4 Praktikum Perancangan Teknik Industri II. Metode ini merupakan penyederhanaan dari metode normal form. Pa da metode ini, langkah normalisasi yang dilakukan adalah: 1. Mencari dua entitas yang memiliki hubungan many to many, misalkan nama kedua entitas tersebut adalah A dan B. 2. Tambahkan entitas baru di antara kedua entitas tersebut, misalnya dengan nama C, yang menyebabkan hubungan baru dari A ke C dan dari B ke C adalah one to many. 3. Sesuaikan penggunaan primary key dan foreign key pada tabel masing -masing entitas. Kekurangan dan kelebihan metode ini dapat dilihat pada tabel berikut: Kelebihan Mudah dimengerti dan dilakukan oleh semua orang. Proses normalisasi cepat dilakukan. Tidak membutuhkan keahlian khusus dalam melihat detail hubungan antar entitas. Kekurangan Kurang teliti dan detail dalam menormalisasi database. Tidak terdapat langkah spesifik atau algoritma dalam melakukan normalisasi. Bersifat subjektif untuk dilakukan. Setelah dilakukan normalisasi, masih terdapat kemungkinan anomali dan redudansi data. Hasil normalisasi menjadi kurang baik jika digunakan untuk menormalisasi database yang kompleks. Metode normal form adalah metode normalisasi yang lazim digunakan oleh para system builder dengan basis functional dependency. Metode ini menyebabkan adanya 6 bentuk normal namun biasanya untuk penormalan pada database, sudah cukup sampai langkah 3 yang menyebabkan terbentuknya 3NF atau sampai Boyce Codd Normal Form karena sudah tidak terdapat anomali data pada bentuk ini. Pada metode ini, setiap langkah berikutnya harus sudah memenuhi langkah sebelumnya. Enam bentuk ya dihasilkan pada setiap langkah ng normal form: 1. First Normal Form (1NF) Langkah pertama yang dilakukan adalah mendefinisikan semua atribut kunci dan membuatnya tidak bernilai multi value. Hanya boleh terdapat satu nilai untuk sebuah atribut pada satu tipe entitas. 2. Second Normal Form (2NF) Pada langkah kedua, bentuk 1NF sudah harus terpenuhi dan langkah berikutnya adalah membuat semua atribut nonkunci bergantung fungsional secara sepenuhnya kepada atribut kunci. 3. Third Normal Form (3NF) atau Boyce Codd Form Bentuk 2NF harus sudah terpenuhi dan setiap atribut nonkunci tidak bergantung secara transitif pada primary key. Biasanya bentuk 3NF ini dilanjutkan menjadi Boyce Codd Josef Novan Lumbantobing (13405071) Halaman 36 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

Form yaitu jika bentuk 3NF telah terpenuhi dan setiap determinan adalah candidate key. Boyce Codd merupakan bentuk 3NF yang lebih baik karena pada praktiknya dapat mengatasi 2 masalah khusus yang tidak dapat diatasi oleh bentuk 3NF yaitu: y Bagian dari pengidentifikasi entitas yang berupa komposit menentukan bagian dari atributnya. y Sebuah atribut yang tidak mengidentifikasi entitas menentukan bagian dari atribut yang mengidentifikasi atribut. Biasanya, sebuah database dikatakan telah ternormalisasi bila sudah dalam bentuk 3NF atau Boyce Codd Form. 4. Fourth Normal Form (4NF) Pada langkah ke-4, bentuk 3NF dan Boyce Codd Form telah terpenuhi dan tidak boleh terdapat lebih dari satu hubungan saling ketergantungan yang multivalue. 5. Fifth Normal Form (5NF) Fifth Normal Form disebut juga Project-Join Normal Form, pada bagian ini bentuk 4NF telah terpenuhi dan sudah tidak terdapat dekomposisi lossless pada saat breakdown tabel atau dengan kata lain setiap join dependency adalah konsekuensi dari candidate key yang ada. 6. Sixth Normal Form (6NF) Pada Sixth Normal Form yang disebut juga Domain-Key Normal Form bentuk 5NF telah terpenuhi dan dilanjutkan dengan memastikan bahwa isi tabel tidak berisi non -trivial join dependency sama sekali. Dengan kata lain semua pembatas dan ketergantungan adalah konsekuensi logis akibat pendefinisian kunci dan domain. Kekurangan dan kelebihan metode ini dapat dilihat pada tabel berikut: Kelebihan Hasil normalisasi dipastikan sudah baik. Normalisasi dilakukan secara runut dan jelas sesuai dengan langkah spesifik yang telah ditentukan. Sangat detail dalam setiap langkah sehingga tingkat ketelitian tinggi. Baik dan bisa digunakan untuk menormalisasi semua jenis database, dari yang sederhana sampai yang kompleks. Kekurangan Kurang user friendly karena harus mengerti setiap istilah yang digunakan dan cara yang dilakukan pada setiap langkah. Rumit dalam melakukan normalisasi.

3.2. Analisis Perbandingan DBMS yang Digunakan dengan DBMS lain Kebutuhan akan manfaat database telah menjadi hal yang umum sekarang ini. Seiring dengan berkembangnya teknologi database, bermunculan pula DBMS-DBMS yang memiliki fitur yang berbeda di mana tujuannya adalah memudahkan user. Dari sekian banyaknya DBMS, salah satu yang biasa digunakan adalah Microsoft Access. Hal ini dikarenakan kemudahan dalam pemakaiannya serta perceived quality-nya yang tinggi (nama Microsoft sudah terkenal baik di Indonesia). Beberapa DBMS antara lain: 1. Microsoft Access Microsoft Access merupakan salah satu program keluaran dari Microsoft. Program ini dimanfaatkan untuk pembuatan database. Pemanfaatan database ini cukup mudah jika dibandingkan dengan DBMS yang lainnya. Hal ini dikarenakan interface-nya yang sudah cukup friendly. Selain itu, Microsoft Access juga memiliki kemudahan untuk mengolah data Josef Novan Lumbantobing (13405071) Halaman 37 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

Hal ini membuat cukup banyak masyarakat mudah untuk mem anfaatkan program database ini dengan waktu belajar yang relatif singkat. Kelebihan lainnya, adalah database ini mendukung program aplikasi yang lainnya seperti Visual Basic dan lainnya. Kelebihan y Multivalued lookup fields Pengguna dapat menciptakan field lookup yang dapat menyimpan lebih dari satu nilai pada setiap field. Sehingga dapat menciptakan relationship many to many pada field dan meyembunyikan implementasi detil yaitu dengan menggunakan sistem tabel y Attachment data type Fitur ini mempermudah penyimpanan dokumen dalam segala bentuk tipe format atau file binary. y Memo Field Adanya memo field untuk menyimpan informasi dalam. y Gambaran relationship Adanya gambaran relationship yang memudahkan desainer/user memahami skema dari basis data yang bersangkutan y Sederhana Penggunaan/pengolahan data yang relatif sederhana y Mendukung Pemrograman Berorientasi Objek DBMS ini mendukung teknik-teknik pemrograman yang berorientasi objek. y Pemanfaatan Graphical User Interface (GUI) Pemanfaatan GUI dalam membangun database sehingga memudahkan pengguna dalam membangun sistem database, misalnya saat pembuatan query. Kekurangan y Kurang dinamis Database yang dibuat kurang dinamis jika dibandingkan dengan DBMS lainnya, seperti MySQL.

y Kurang mendukung pembuatan database yang kompleks

2. Oracle Oracle merupakan DBMS yang terkenal dikalangan professional. DBMS ini memiliki kekuatan yang cukup tinggi jika dibandingkan dengan DBMS lainnya. Kelebihan serta kekurangan Oracle antara lain: Kelebihan y Tingkat keamanan tinggi Tingkat keamanan tinggi sehingga data yang tersimpan di basis data dapat diproteksi dari pihak-pihak yang tidak berkepentingan. y Pilihan otorisasi Terdapat pilihan jenis otorisasi yang sesuai dengan kebutuhan. y Berbasis Graphical User Interface (GUI) Aplikasi berbasis GUI sehingga memberi kemudahan bagi user dalam melakukan pembangunan serta manajemen Josef Novan Lumbantobing (13405071) Kekurangan y Rumit Penggunaan yang rumit disebabkan berbagai macam fasilitas yang disediakan. y Penggunaan resource yang besar DBMS ini memerlukan resource yang besar dalam pengolahan transaksi basis data berskala besar. y Biaya yang tinggi Penggunaan Oracle sangat memakan banyak biaya, mulai dari pembuatannya hingga aplikasinya. Halaman 38 dari 43

Modul 4 Perancangan Basis Data terhadap sistem basis data. y Sistem Penjaminan Adanya sistem penjaminan terhadap pemulihan sistem basis data setelah sistem mengalami kegagalan. y Mampu melakukan proses lacking sebagian DBMS ini mampu melakukan proses lacking pada beberapa item data yang diperlukan saja tanpa melakukan proses lacking terhadap keseluruhan isi tabel. y Pembatasan penggunaan resource Adanya fasilitas yang memberikan pembatasan penggunaan resource untuk seorang user sehingga menghindari monopoli penggunaan resource. y Database Cluster dengan teknololgi Real Application Clusters (RAC) Adanya database cluster dengan menggunakan teknologi Real Application Cluster (RAC) yang salah satu fungsinya adalah memberikan perlindungan terhadap kelangsungan data dalam perusahaan sehingga apabila terjadi crash pada salah satu server database, maka hal ini tidak akan mempengaruhi kinerja perusahaan. Hal ini disebabkan karena teknologi RAC memungkinkan untuk membuat beberapa database server, sehingga ketika ada database server yang down, kinerja database tersebut dapat ditanggulangin oleh server-server yang lain. y Adanya Row-Level Locking Fitur ini membuat user dapat melakukan akses data dalam suatu tabel secara bersamaan dengan lebih cepat dan akurat. y Adanya Data Partitioning Hal ini memungkinkan user untuk melakukan partisi ke suatu tabel maupun indkes. Hal ini mendukung user dalam melakukan manajemen data. y Adanya Oracle Data Mining dan Data Warehousing Fitur ini memberikan kemudahan bagi perusahaan yang ingin membangun aplikasi business intelligent yang bertujuan untuk membantu eksekutif perusahaan dalam menentukan strategi perusahaan berdasarkan analisis data yang di-generate oleh Oracle Data Mining. y Adanya Virtual Private Database Fitur ini memberikan dan meningkatkan fleksibilitas jaminan security sampai pada row-level security. Hal ini akan membuat aplikasi yang dibuat menjadi semakin aman sewaktu melakukan transaksi melalui internet. Josef Novan Lumbantobing (13405071)

Kelompok 10

Halaman 39 dari 43

Modul 4 Perancangan Basis Data y Terdapat Flashback Query Fitur ini memungkinkan user melihat status data beberapa waktu yang lalu sampai batas yang user tentukan, sehingga apabila terjadi kesalahan data pada waktu yang lalu, maka koreksi dapat dilakukan tanpa harus melakukan database recovery

Kelompok 10

3. MySQL MySQL merupakan salah satu DBMS yang paling banyak digunakan di Indonesia sebagai web database. Kelebihan dan kekurangan MySQL antara lain:

Kelebihan
y Kecepatan tinggi MySQL memiliki kemampuan yang lebih cepat dibandingkan dengan DBMS lain, namun masih kalah dari Oracle.

Kekurangan y Tidak ada Partisi Table MySQL tidak memiliki fasilitas untuk melakukan partisi terhadap table.
y Kurang men-support bahasa pemrograman visual MySQL kurang men-support koneksi ke bahasa pemrograman visual, seperti Visual Basic dan Foxpro. Koneksi menyebabkan field yang dibaca harus sesuai dengan koneksi dari program visual tersebut. Hal ini membuat MySQL jarang dipakai dalam program visual.

y Memiliki Backup Data Bila terjadi kesalahan dalam koneksi ke PHP, maka MySQL memiliki backup data berupa format notepad yang biasa diimpor dan ekspor ulang.

y Bersifat Opensource MySQL bersifat opensourcei sehingga banyak orang mampu mengaksesnya secara gratis.

4. PostgreSQL Seperti halnya Oracle, DBMS PostgreSQL digunakan untuk fungsi bisnis berskala besar. Kelebihan dan kekurangan DBMS ini antara lain:

Kelebihan
y Fasilitas yang disediakan cukup banyak.

Kekurangan y Belum memenuhi salah satu standar SQL yaitu referential integrity and outer joint.

y Database ini didukung oleh banyak bahasa pemrograman.

y Bersifat opensource sehingga cukup banyak orang yang dapat mengakses dan mengembangkannya.

y Memiliki arsitektur yang tergolong tangguh sehingga membuat user mudah untuk menggunakannya.
y Mampu dijalankan hamper di semua operating system, seperti: Linux, UNIX, dan Windows.

Josef Novan Lumbantobing (13405071)

Halaman 40 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

Sehingga dapat disimpulkan bahwa Microsoft Access memiliki kemudahan dalam pemanfaatannya untuk pembuatan database yang tidak tergolong kompleks. Hal ini karena fasilitas yang dimilikinya 3.3. Analisis Keterkaitan Antar Modul Modul 4 ini merupakan lanjutan rangkaian perancangan Sistem Informasi untuk PT. PTI. Pada modul kali ini dilakukan perancangan sistem basis data untuk PT. PTI dengan input yang digunakan adalah Data Flow Diagram yang sebelumnya dirancang pada modul 3 (DFD dibuat berdasarkan pemodelan proses bisnis yang telah dilakukan pada modul 2). Data storage yang ada pada model DFD menjadi rujukan sebagai perancangan sistem basis data pada modul kali ini. Data storage yang ada pada DFD dimodelkan sebagai entitas dalam model Entity Relantionship Diagram yang merupakan dasar dalam perancangan sistem informasi. Data item yang ada pada data storage DFD nantinya akan menjadi field untuk sistem basis data yang dirancang. Masalah yang timbul dalam perancangan sistem basis data ini adalah redudansi data yang ada pada model ERD. Redudansi ini kemudian dihilangkan dengan melakukan normalisasi. Setelah status ERD menjadi normal, perancangan basis data dapat dilakukan dengan menggunakan Database Management System (DBMS). Sistem basis data sangatlah berguna untuk menjaga kelancaran penyampian informasi dalam suatu perusahaan demi mendukung kelancaran seluruh proses bisnis yang dilakukan oleh perusahaan tersebut. Berikut adalah hubungan antar modul yang digambarkan dalam sebuah diagram .

Josef Novan Lumbantobing (13405071)

Halaman 41 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

BAB IV KESIMPULAN DAN SARAN

4.1. Kesimpulan Kesimpulan dari Modul 4 Analisis Perancangan Sistem Informasi 2 : Perancangan Basis Data 1. Telah didesain sistem informasi untuk PT. PTI yaitu sistem basis data dengan menggunakan Ms. Access 2007 sebagai DBMS-nya melalui 5 langkah perancangan sistem basis data, yaitu Planning, Analysis, LDD, PDD dan Implementation. 2. Sistem basis data dibuat dengan berdasarkan pada Entity Relationship Diagram (sesuai Data Flow Diagram yang telah dibuat pada modul 3). 3. ERD yang dijadikan dasar sebagai perancangan sistem basis data adalah ERD yang telah ternormalisasi. 4. Sistem basis data yang dibuat telah memiliki user interface yang dapat memudahkan user untuk mengoperasikan sistem basis data ini. 4.2. Saran Saran untuk Modul 4 Analisis Perancangan Sistem Informasi 2 : Perancangan Basis Data 1. Sebagai input modul ini sebaiknya digunakan DFD kelompok sendiri untuk memudahkan pengerjaan dan membuat sistem basis data yang dirancang menjadi lebih akurat dan realiable. 2. Sebaiknya gunakan DBMS lain selain Microsoft Access 2007, misalnya MySQL agar sistem basis data menjadi lebih flexible dan memiliki user interface lebih baik. 3. Sebaiknya gunakan metode normalisasi sesuai literatur. (1NF, 2NF, 3NF dan BCNF) 4. Modul yang diberikan kepada praktikan harap diperbaiki dan content-nya harap diperjelas.

Josef Novan Lumbantobing (13405071)

Halaman 42 dari 43

Modul 4 Perancangan Basis Data

Kelompok 10

DAFTAR PUSTAKA
Whitten, JL. Bentley L.D., Dittman K.C. 2004. System Analysis and Design Method 6th Edition. McGraw Hill, New York.

http://en.wikipedia.org/wiki/Database_normalization http://www.allbusiness.com/technology/technology-services-systems-analysis/4102914-1.html http://www.datamodel.org/NormalizationRules.html#dknf http://www.saintmarys.edu/~psmith/417act17.html http://www.tdan.com/view-articles/4583 http://www.tonymarston.co.uk/php-mysql/database-design.html#5nf

Josef Novan Lumbantobing (13405071)

Halaman 43 dari 43