BAB 2 LANDASAN TEORI 2.1 Teori Umum Pada teori umum ini kami akan menjelaskan teori yang akan sering digunakan sebagai penunjang dan pedoman untuk membuat rancangan basis data dan prototype pada skripsi kami 2.1.1 Pengertian Data Menurut (Hoffer, Presscot, & McFadden, 2005, p.5), data yaitu sebuah representasi penyimpanan dari obyek – obyek dan kejadian – kejadian yang beramakna dan penting di lingkungan pemakai. Sedangkan menurut (Laudon & Laudon, 2010, p.6), mengatakan bahwa “data adalah aliran fakta mentah yang merupakan kejadian yang terjadi dalam organisasi atau lingkungan fisik sebelum mereka terorganisir dan disusun menjadi bentuk yang orang – orang dapat memahami dan digunakan” 2.1.2 Pengertian Informasi (Menurut Brian K & Stacey, 2007, p.25), mendefinisikan informasi adalah data yang sudah diolah atau dimanipulasi untuk digunakan dalam pengambilan keputusan.
Menurut (O'Brian & Marakas, 2011, p.34) informasi adalah data yang telah diubah menjadi isi yang mempunyai arti dan kegunaan untuk pengguna akhir tertentu.
Dalam jurnal (Fattahi & Afshar,2006) disimpulkan bahwa informasi akan sangat berguna tergantung dari pemberian nilai informasi tersebut. Nilai informasi dapat dilihat dari sudut pandang yang berbeda oleh pihak manajemen atas untuk membuat keputusan manajemen operasional. Nilai informasi berguna sebagai nilai tambah dalam menghemat waktu proses
7
8
bisnis, produktivitas serta meningkatkan pengembangan kualitas kerja dengan membagi informasi tersebut ke dalam internal perusahaan.
2.1.3 Basis Data Menurut (Connolly & Begg, 2010, p.15), basis data adalah kumpulan data yang saling berhubungan secara logis, dan sebuah penjelasan dari data tersebut, yang didesain untuk menemukan data yang diperlukan organisasi. Di dalam basis data, semua data diintegrasikan dengan menghindari duplikasi data. Basis data banyak digunakan oleh banyak departemen dan user. Basis data tidak hanya menangani data operasional
organisasi, tetapi juga
mengenai data tersebut. Menurut(Turban et al 2005, p.16), database merupakan kumpulan file, tabel,dan relasi yan menyimpan data beserta hubungan diantara data tersebut. Menurut (Lonely & Bryla, 2005, p.4), basis data merupakan kumpulan data pada disk dalarn satu atau lebih file pada server basis data yang dikumpulkan dan dikelola berdasarkan informasi terkait. Didalam jurnal juga dikatakan : Menurut (Honni, 2011) Perusahaan membutuhkan sebuah sistem yang terintegrasi baik dalam pengolahan data dan penyimpanan data maupun pengolahan terhadap arus transaksi yang berdasarkan pada sistem basis data sehingga dalam melakukan proses bisnisnya dapat cepat, akurat dan dapat diandalkan sehingga dapat meningkatkan efisiensi dan kualitas kerja perusahaan. Menurut (Ayuliana, 2012) dengan dibuatnya sistem basis data dan program aplikasi ini dengan baik dapat membantu kinerja karyawan dalam menangani transaksi persediaan, penjualan, karena memiliki fitur-fitur yang memudahkan user untuk mengaksesnya sesuai dengan kebutuhan. Menurut (Christensen, Brandt, & McCracken, 2011) menyatakan bahwa data – data yang nantinya akan menghasilkan informasi, disimpan ke dalam suatu tabel dimana tabel tersebut berhubungan satu sama lainnya.
9
Setiap tabel yang mengandung satu atau lebih atribut digunakan untuk menghasilkan kualifikasi, identifikasi, pengelompokan, kuantitas, atau mendeskripsikan susunan informasi tabel tersebut 2.1.4 Database Management System Menurut (Connolly & Begg, 2010, p.66).Database management system (DBMS) adalah sistem perangkat lunak yang memungkinkan pengguna sistem untuk mendefinisikan, membuat, memelihara, dan mengendalikan akses ke dalam basis data
Gambar 2.1 Database Management System Sumber : (Connolly & Begg, 2010, p.67)
Pada gambar 2.1 dijelaskan tentang bagian sales dan contracts menyatakan bahwa ada dua pengguna sistem yang memasukan data yaitu bagian sales dan bagian contracts. Dua pengguna sistem dengan komputer client yang berbeda mengakses satu basis data yang sama tentu dengan pemasukan data yang berbeda, seperti pada gambar yang tertera bahwa bagian penjualan memasukan data dan laporan dengan mengakses aplikasi “sales application program” dan bagian contracts memasukan data dan laporan dengan mengakses aplikasi yang berbeda dari bagian sales, yaitu “contracts application program”, hal seperti ini membutuhkan suatu manajemen atau pengendalian ke dalam basis data dengan adanya DBMS. Fungsi DBMS itu sendiri adalah memberikan hak akses kepada dua pengguna bagian sales dan bagian contracts, data – data apa saja yang mereka masukan, modifikasi serta menghapus tergantung dari hak akses mereka, sehingga kontrol terhadap data – data yang berbeda jenis dapat teratasi
10
2.1.4.1 Fasilitas DBMS Biasanya DBMS memiliki fasilitas-fasilitas sebagai berikut: 1. Data
Definition
Language
(DDL)
adalah
fasilitas
mendefinisikan basis data. DDL mengizinkan pengguna untuk memspesifikasikan tipe, struktur, dan batasan aturan mengenai data yang bisa disimpan ke dalam basis data.hal yang bisa dilakukan DDL adalah : •
Create Table Untuk membuat tabel dengan mengidentifikasikan tipe data untuk tiap kolom.
•
Alter Table Untuk menambah atau membuang kolom dan constrain.
•
Drop Table Untuk membuang atau menghapus tabel beserta semua data yang terkait di dalamnya.
•
Create Index Untuk membuat index pada suatu tabel.
•
Drop Index Untuk membuang atau menghapus index yang telah dibuat sebelumnya.
2. Data
Manipulation
Language
(DML)
adalah
fasilitas
pengguna untuk menambah, menghapus mengedit dan mendapatkan kembali data dari basis data,. Ada juga suatu fasilitas yang melayani pengaksesan data yang disebut query language. Bahasa yang diakui adalah Structured Query Language (SQL), yang merupakan standard dari DBMS.
3. Data Control Language (DCL) Fasilitas yang digunakan mengontrol ke basis data . Contoh : •
Sistem keamanan yang mencegah user yang tidak punya autoritas untuk akses data.
11
•
Suatu sistem terintegasi yang memelihara konsistensi penyimpanan data.
•
Suatu Sistem kontrol pengembalian data yang mana dapat mengembalikan data ke keadaan sebenarnya apabila terjadi kegagalan perangkat keras atau perangkat lunak.
•
Terdapat suatu katalog yang dapat di akses oleh pengguna, yang menjelaskan data didalam basis data tersebut.
2.1.4.2 Komponen DBMS Menurut (Connoly & Begg, 2010, p.18), Komponen DBMS terbagi menjadi lima yaitu : 1.
Hardware (perangkat keras) DBMS dan program aplikasi membutuhkan perangkat
keras untuk bisa menjalankan fungsi – fungsinya. dapat berkisar dari komputer tunggal, mainframe tunggal, hingga jaringan komputer. perangkat keras yang dipakai tergantung pada kebutuhan organisasi dan Database Management System (DBMS) yang digunakan. Sebuah DBMS memerlukan jumlah minimum memori dan hardisk untuk bekerja, tetapi konfigurasi yang minimum tidak memberikan performa yang handal.
2.
Software (perangkat lunak) Komponen perangkat lunak terdiri dari perankat lunak
DBMS dan program aplikasi beserta sistem operasi (OS), termasuk jaringan perangkat lunak jika DBMS digunakan melalui jaringan.
3.
Data Data merupakan data terpenting dalam DBMS
khususnya sudut pandang dari end user mengenai data, dimana data berfungsi sebagai jembatan antara komponen mesin dengan komponen manusia.
4.
Procedures
12
Prosedur merupakan panduan dan aturan dalam membuat dan menggunakan basis data. Prosedur didalam basis data berupa : login ke dalam basis data, penggunaan fasilitas DBMS atau aplikasi program,
cara menjalankan dan
menghentikan DBMS, membuat backup database, menangani kerusakan hardware atau software, mengubah struktur table, mengumpulkan basis data dari beberapa disk, meningkatkan kinerja atau membuat arsip data pada secondary storage.
5.
People (manusia)
Komponen terakhir yaitu manusia yang terlibat dengan sistem tersebut.
Gambar 2.2 The DBMS Environtment Sumber : (Connolly & Begg, 2010, p.68)
2.1.4.3 Keuntungan dan kerugian DBMS
Keuntungan dari DBMS -
Berbagi data
-
Standarisasi
-
Konsistensi Data
-
Meningkatkan konkurensi
-
Meningkatkan produktifitas
-
Meningkatkan keamanan data
-
Mengendalikan redudansi data
-
Mengimprovisasi integritas data
-
Menyediakan backup data dan recovery
-
Menyeimbangkan kebutuhan yang bertentangan
13
-
Informasi yang lebih dari jumlah data yang sama
-
Meningkatkan aksebilitas data dan responsiveness
-
Meningkatkan pemeliharaan melalui data independen
Kerugian dari DBMS -
Mahal
-
Compexity atau rumit
-
Memperlambat kinerja beberapa aplikasi lain
-
Membutuhkan tempat atau penyimpanan besar
2.1.5 Database System Development Lifecycle Menurut(Connolly & Begg 2010, p.283), sistem basis data adalah komponen yang fundamental didalam organisasi yang besar dengan sistem informasi yang luas. Hal penting yang harus diperhatikan dalam Database System Development Lifecycle adalah bahwa tingkatannya tidak sepenuhnya berurutan (sequential). Dimana ada beberapa tingkatan yang berulang dengan alur balik (feedback loop), contohnya masalah ditemukan pada tingkat perancangan basis data yang membutuhkan tambahan kumpulan kebutuhan dan analisis. Untuk aplikasi basis data yang kecil dengan pengguna yang sedikit maka lifecycle-nya tidak terlalu kompleks. Sebaliknya ketika merancang basis data yang sedang sampai ke basis data yang banyak dengan ribuan bahkan puluhan ribu pengguna, mengunakan ratusan query dan program aplikasi maka lifecycle akan menjadi sangat kompleks.
14
Gambar 2.3 Tingkatan dari Database System Development Lifecycle Sumber : (Connolly & Begg, 2010, p.284) 2.1.5.1 Database Planning aktifitas manajemen yang memungkinkan setiap tahapan dalam Database System Development Lifecycle untuk direalisasikan menjadi paling efisien dan paling efektif. Database Planning seharusnya
diintegrasikan dengan keseluruhan strategi sistem
15
informasi dari organisasi. Ada 3 persoalan utama dalam menyusun strategi sistem informasi, antara lain : 1. identifikasi dari rencana dan tujuan perusahaan dengan determinasi secara subsequent dari kebutuhan sistem informasi. 2. mengevaluasi
sistem
informasi
yang
ada
untuk
mendefinisikan keunggulan dan kelemahan. 3. penafsiran dari IT opportunity untuk mendapatkan keuntungan bersaing. 2.1.5.2 System definition Sistem definisi mendeskripsikan cakupan dan batasan dari aplikasi basis data dan user view utama. User view mendeskripsikan apa yang dibutuhkan dari sebuah basis data dari sudut pandang peran pekerja (seperti manager atau supervisor) atau area aplikasi perusahaan (seperti marketing, personel, atau control stock). 2.1.5.3 Requirements Collection and Analysis Adalah Suatu proses yang mengumpulkan dan menganalisis informasi mengenai bagian mana saja dari organisasi yang didukung oleh aplikasi basis data dan penggunaan informasi ini untuk mengidentifikasi kebutuhan pengguna dari sistem yang baru. Untuk mengumpulkan dan menganalisis informasi digunakan teknik yang dinamakan teknik fact-finding. Menurut (Connolly & Begg, 2010, p.317), terdapat lima teknik fact finding yang umum digunakan.
•
Interview.
•
Mengevaluasi dokumentasi.
•
Observasi.
•
Questioner.
16
•
Research.
2.1.5.4 Database Design Menurut (Connolly & Begg, 2010, p291 ), Database design adalah suatu proses yang membuat suatu perancangan untuk basis data yang akan mendukung kegiatan operasional dan tujuan dari perusahaan. Pada bagian ini dibagi menjadi tiga tahap, yaitu conceptual, logical, dan physical : 1.
Conceptual database design Pada tahap konseptual ini bertujuan untuk membuat
representasi konseptual dari basis data, termasuk identifikasi entitas, relationship, dan atribut. Pada tahap ini dibagi menjadi beberapa langkah, yaitu: Langkah 1. Membangun conceptual data model Langkah 1.1 Identifikasi Tipe Entitas Langkah 1.2 Identifikasi Tipe Relationship Langkah 1.3 Identifikasi dan Asosiasi Atribut dengan Tipe Entitas dan Tipe Relationship Langkah 1.4 Menentukan Domain Atribut Langkah 1.5 Menentukan Atribut Candidate key, Primary Key, dan Alternate Key Langkah 1.6 Mempertimbangkan
penggunaan
enhanced modeling concept (optional) Langkah 1.7 Memeriksa model dari redundancy Langkah 1.8 Validasi Model Konseptual dengan user transaction
17
Langkah 1.9 Meninjau local conceptual data model dengan pengguna 2. Logical database design Pada tahap ini merubah model konseptual ke model logikal yang dipengaruhi oleh model data yang menjadi tujuan dari basis data. Didalam perancangan model logikal, model data yang telah didapat dalam basis data konseptual diubah kedalam bentuk dimana data yang ada dipengaruhi oleh model data yang menjadi tujuan basis data (contoh : relational model). Hal ini dilakukan untuk menjelaskan representasi konseptual kedalam bentuk struktur logikal dalam basis data. Data model logikal adalah sebagai sumber informasi dalam merancang basis data fisikal. Perancangan basis data logikal memberikan sarana yang membantu para perancang dalam merancang basis data fisikal. Pada tahap ini dibagi menjadi beberapa langkah, yaitu : Langkah 2. Membangun dan memvalidasi logical data model Langkah 2.1 Menentukan Relasi – Relasi untuk Model Data Logikal Langkah 2.2 Validasi Model dengan Normalisasi Langkah 2.3 Memvalidasi
Relasi
dengan
User
Transaction Langkah 2.4 Mendefinisikan Kendala Integrity Langkah 2.5 review logical data model dengan User Langkah 2.6 Menggabungkan Logical Data Model ke dalam Global Model (optional) Langkah 2.7 Memeriksa untuk perkembangan lebih lanjut
18
3. Physical database design Pada
tahap
memungkinkan keputusan
perancangan
perancang
tentang
basis
basis data
bagaimana
data
untuk
basis
fisikal membuat
data
akan
diimplementasikan. Oleh karena itu, perancangan basis data fisikal harus disesuaikan dengan DBMS yang spesifik. Pada tahap ini dibagi menjadi beberapa langkah, yaitu : Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih Langkah 3.1 Merancang relasi – relasi dasar Langkah 3.2 Merancang
representasi
untuk
data
turunan Langkah 3.3 Merancang general constraint Langkah 4. Merancang file organization dan indexes Langkah 4.1 Menganalisa transaksi Langkah 4.2 Memilih organisasi file Langkah 4.3 Memillih index – index Langkah 4.4 Memperkirakan kebutuhan disk space Langkah 5. Merancang user view Langkah 6. Merancang mekanisme keamanan Langkah 7. Mempertimbangkan pengenalan redudancy yang dipilih Langkah 8. Mengawasi dan mengendalikan sistem operasional
19
2.1.5.5 DBMS selection Seleksi /pemilihan DBMS dilakukan untuk memilih DBMS yang sesuai dengan aplikasi basis data. Menurut ( Connolly & Begg, 2010, p.295 ), berikut ini adalah langkah –langkah dalam memilih DBMS : 1. Mebdeskirpsikan cakupan tugas berdasarkan kebutuhan perusahaan 2. Membuat perbandingan mengenai 2 atau lebih produk DBMS 3. Mengevaluasi produk-produk DBMS tersebut 4. Merekomendasikan pemilihan DBMS dan membuat laporan hasil dari evaluasi produk DBMS tersebut.
Secara khusus DBMS menyediakan fasilitas-fasilitas sebagai berikut : 1. Memperkenankan pengguna untuk menentukan basis data, biasanya melalui Data Definition Language (DDL). DDL memperkenankan pengguna untuk menspesifikasikan tipe data, struktur data dan batasan-batasan data yang bisa disimpan di basis data. 2. Memperkenankan pengguna untuk insert, update, delete atau retrive data dari basis data,
biasanya
melalui Data
Manipulation Language (DML). 3. DBMS menyediakan akses kontrol ke basis data. Sebagai contohnya DBMS menyediakan : a. Security
system,
dimana
menghalangi
autorisasi
pengguna untuk mengakses basis data. b. Integrity
system,
dimana
menangani
konsistensi
penyimpanan data. c. Concurrency control system, dimana memperkenankan basis data untuk diakses secara share. d. Recovery control system, dimana basis data bias direstore pada saat terjadi kesalahan pada hardware maupun software.
20
e. User-accesable catalog, berisi deskripsi data dalam basis data.
2.1.5.6 Application Design Menurut (Connolly & Begg, 2010, p.299), rancangan aplikasi adalah perancangan dari user interface dan program aplikasi yang digunakan dan memproses basis data. Dari gambar 2.1, dapat dilihat bahwa database design dan application design adalah aktifitas yang paralel dalam database lifecycle.Didalam kebanyakan kasus tidak mungkin
dapat
menyelesaikan
application
design
sebelum
menyelesaikan database design itu sendiri. Dengan kata lain database yang ada mendukung aplikasi sehingga ada banyak aliran informasi antara application design dan database design. 2.1.5.7 Prototyping (optional) Pada kondisi tertentu kita dapat memilih apakah akan membuat prototipe atau langsung mengimplementasikan basis data. Suatu prototipe adalah suatu model aplikasi basis data yang mempunyai semua rupa yang diperlukan dan menyediakan semua kemampuan sistem. Tujuan utama prototipe adalah untuk menguji apakah fitur-fitur yang ada pada sistem telah bekerja sesuai dengan karakteristik pengguna. Dengan cara ini, kita dapat memperjelas kebutuhan pengguna dan pengembangan sistem dan mengevaluasi kelayakan desain sistem tersebut. Menurut (Connolly & Begg, 2010, p.303), ada dua cara strategi membuat prototipe yaitu requirements prototyping dan evolutioner prototyping. Untuk requirements prototyping digunakan prototipe untuk menentukan kebutuhan suatu aplikasi basis data yang diusulkan dan ketika kebutuhan dirasakan sudah lengkap maka prototipe tersebut tidak lagi digunakan. Prototype evolutioner digunakan untuk tujuan yang sama, perbedaannya ialah bahwa prototipe tidaklah dibuang tapi dikembangkan lebih lanjut sehingga menjadi aplikasi basis data tersebut.
21
2.1.5.8 Data Convertion dan Loading Menurut (Connolly & Begg, 2010, p.305), pemindahan data yang sudah ada ke basis data yang baru dan mengubah aplikasi yang sedang berjalan agar dapat digunakan dalam basis data yang baru. 2.1.5.9 Operational Maintenance Menurut (Connolly & Begg, 2010, p.306), setelah melalui tahapan-tahapan sebelumnya, maka sistem sekarang telah pada tahap pemeiharaan yang melibatkan aktivitas berikut : 1. Monitoring performance dari sistem. Jika performance berada disuatu tingkatan yang bisa diterima, setting atau menyusun kembali basis data mungkin diperlukan. 2. Memelihara dan meningkatkan mutu aplikasi basis data. Kebutuhan baru disatukan kedalam aplikasi basis data dengan mengikuti langkah – langkah sebelumnya yang terdapat dalam database lifecycle.
Ketika aplikasi bisnis data sedang beroperasi, perlu dilakukan monitoring secara dekat untuk memastikan bahwa performansi dalam tingkatan yang dapat diterima. Proses monitoring akan terus berlanjut sepanjang hidup suatu aplikasi basis data tersebut dan pada waktu tertentu boleh melakukan menyusun kembali basis data untuk mencukupi kebutuhan dari sistem. Perubahan ini meyediakan informasi pada evolusi sistem dan sumber daya pada masa yang akan datang mungkin diperlukan. Hal ini memungkinkan DBA untuk terlibat dalam perencanaan kapasitas dan untuk memberitahu staf senior siaga untuk melakukan penyesuaian rencana jika DBMS kekurangan kegunaan tertentu, DBA dapat mengembangkan kegunaan yang diperlukan atau memberi tools tambahan jika tersedia.
22
2.16
Tahap – Tahap Perancangan Basis data Dalam merancang suatu basis data melalui beberapa tahapan, sebagai berikut : •
Perancanagan Basis data Konseptual
•
Perancanagan Basis data Logikal
•
Perancanagan Basis data Fisikal
2.1.6.1 Perancangan Basis data Konseptual Menurut (Connolly & Begg 2010, p.439), perancangan konseptual basis data adalah proses pembangunan model data yang digunakan di perusahaan, yang tidak bergantung pada semua pertimbangan fisikal. Tujuannya untuk membangun representasi konseptual basis data, yang meliputi identifikasi dari entitas - entitas, atribut - atribut, dan relationship – relationship yang penting. Langkah 1. Membangun conceptual data model Tujuannya adalah menurut (Connolly & Begg, 2010, p.442), untuk membangun local conceptual data model dari perusahaan untuk tiap view yang spesifik. Tiap local conceptual data model terdiri dari entity type, relation type, atribut - atribut, domain – domain atribut, primary key, alternate key, dan integrity constraint. Langkah langkah yang harus dilakukan pada langkah 1 : Langkah 1.1 Identifikasikan Tipe Entitas Tujuannya adalah menurut (Connolly & Begg, 2010, p.443), mengidentifikasikan tipe – tipe entitas utama yang dibutuhkan oleh view. Langkah 1.2 Identifikasikan Tipe Relationship Tujuannya adalah menurut (Connolly & Begg, 2010, p.445),
mengidentifikasikan
relationship
–
relationship
penting yang ada diantara tipe – tipe entitas yang telah diidentifikasi.
23
Langkah 1.3 Identifikasikan dan Asiosiasikan Atribut dengan Tipe Entitas dan Tipe Relationship Tujuannya adalah menurut (Connolly & Begg, 2010 , p.447), untuk menghubungkan atribut – atribut dengan entitas atau relationship type yang sesuai. Langkah 1.4 Menentukan Domain Atribut Tujuannya adalah menurut (Connolly & Begg 2010, p.450), untuk menentukan domain – domain untuk atribut – atribut dalam local conceptual data model. Domain atribut adalah kumpulan nilai yang diperbolehkan untuk satu atau lebih atribut. Domain adalah fitur yang sangat kuat dalam model relational. Setiap atribut di dalam relasi ditetapkan dalam domain. Domain mungkin berbeda untuk tiap atribut, atau dua atau lebih atribut mungkin ditetapkan dalam domain yang sama. Langkah 1.5 Penentuan Atribut Candidate Key, Primary Key, dan Alternate Key Tujuannya adalah menurut (Connolly & Begg, 2010, p.451), untuk mengidentifikasikan candidate – candidate key untuk tiap tipe entitas dan, jika terdapat lebih dari satu candidate key, maka pilih salah satu untuk dijadikan primary key. Menurut (Connolly & Begg, 2010, p.451), ketika memilih primary key diantara candidate key, kita dapat menggunakan panduan berikut untuk membantu pemilihan primary key, yaitu : -
Candidate key dengan kumpulan atribut yang minimal
-
Candidate key yang nilainya jarang berubah
-
Candidate key dengan karakter – karakter yang paling sedikit (untuk yang memiliki textual attributes)
24
-
Candidate key dengan nilai maksimum paling rendah (untuk yang memiliki numerical attributes)
-
Candidate key yang paling mudah digunakan dari sudut pandang user
Langkah 1.6 Mempertimbangkan penggunaan enhanced modeling concept (optional) Tujuannya adalah menurut (Connolly & Begg, 2010 , p.453), untuk mempertimbangkan penggunaan enhanced modeling concepts, seperti specialization / generalization, aggregation, dan composition. Langkah 1.7 Memeriksa model dari redundancy Tujuannya adalah menurut (Connolly & Begg, 2010, p.453), untuk memeriksa apakah terdapat redundancy dalam model. Dua kegiatan dalam langkah ini adalah : memeriksa kembali
one-to-one
relationship
dan
menghilangkan
redundant relationships. Langkah 1.8 Validasi Model Konseptual dengan User Transaction Tujuannya adalah menurut (Connolly & Begg, 2010, p.456), untuk menjamin bahwa model konseptual mendukung transaksi – transaksi yang dibutuhkan oleh view. Langkah 1.9 Meninjau
local
conceptual
data
model
dengan pengguna Tujuannya adalah menurut (Connolly & Begg, 2010, p.458), untuk meninjau local conceptual data model dengan user untuk menjamin bahwa model tersebut adalah representasi yang sebenarnya dari data yang dibutuhkan oleh perusahaan
2.1.6.2 Perancangan Basis data Logikal
25
Menurut (Connolly & Begg, 2010, p.439), perancangan logikal basis data adalah suatu proses pembangunan model data yang digunakan dalam perusahaan berdasar atas model data yang spesifik, tetapi tidak bergantung pada particular DBMS dan pertimbangan fisikal lainnya. Tujuannya untuk menerjemahkan representasi konseptual ke struktur logikal dari basis data yang meliputi perancangan relasi – relasi. Langkah 2. Membangun dan memvalidasi logical data model Menurut (Connolly & Begg, 2010, p.462), tujuannya adalah menerjemahkan logical data model dan kemudian untuk mevalidasi model tersebut untuk memeriksa model tersebut dengan benar secara struktural dan memiliki kemampuan untuk mendukung transaksi transaksi yang dibutuhkan. Tujuan ini akan tercapai dengan mengikuti langkah – langkah berikut : Langkah 2.1 Menentukan Relasi - Relasi untuk Model Data Logikal tujuannya adalah menurut (Connolly dan Begg, 2010, p.463), menciptakan relasi – relasi untuk model data logikal untuk
merepresentasikan
entitas-entitas,
relationship
-
relationship, dan atribut - atribut yang telah diidentifikasikan. Relationship yang dapat muncul pada model data konseptual : ● Strong Entity Type dan Weak Entity Type Menurut (Connolly & Begg, 2010 , p.354), strong entity type adalah tipe entitas yang keberadaannya tidak bergantung (independent) pada beberapa tipe entitas lainnya. Karakteristik dari strong entity type adalah tiap entity occurrence dapat diidentifikasi secara unik menggunakan atribut primary key dari tipe entitas. Strong entity type sering juga disebut parent atau owner atau dominant entities.
26
Menurut (Connolly & Begg, 2010, p.355), weak entity type adalah tipe entitas yang keberadaannya bergantung (dependent) pada beberapa tipe entitas lainnya. Weak entity type juga disebut child, dependent, atau subordinate entities. ● One-to-many (1:*) binary relationship types Menurut (Connolly & Begg 2010, p.465), untuk tiap 1:* binary relationship, entitas pada ‘one side’ dari relationship dianggap sebagai entitas parent dan entitas pada ‘many
side’
dianggap
sebagai
entitas
child.
Untuk
merepresentasikan relationship ini, pasangkan salinan primary key
dari
entitas
parent
ke
dalam
relation
yang
merepresentasikan entitas child, untuk berlaku sebagai foreign key. ● One-to-one (1:1) binary relationsip types Menurut (Connolly & Begg, 2010, p.465), penciptaan relasi - relasi untuk merepresentasikan 1:1 relationship sedikit lebih kompleks karena cardinality tidak dapat digunakan untuk membantu mengidentifikasikan entitas - entitas parent dan child dalam relationship. Sebagai gantinya participation constraint digunakan untuk membantu memutuskan apakah baik
untuk
merepresentasikan
relationship
dengan
menggabungkan entitas - entitas yang terlibat kedalam satu relasi atau dengan menciptakan dua relasi dengan menyalin salinan dari primary key dari satu relasi ke relasi lainnya. Kita mempertimbangkan bagaimana menciptakan relasi – relasi untuk merepresentasikan participation constraint berikut : -
Mandatory participation pada 2 sisi dari 1:1 relationship
-
Mandatory participation pada 1 sisi dari 1:1 relationship
-
Optional participation pada 2 sisi dari 1:1 relationship
● Mandatory participation pada 2 sisi dari 1:1 relationship
27
Menurut (Connolly & Begg, 2010, p.466), dalam kasus ini, kita harus menggabungkan entitas – entitas yang terlibat kedalam satu relasi dan memilih salah satu dari primary key dari entitas – entitas aslinya untuk menjadi primary key dari relasi yang baru, sedangkan yang lainnya dijadikan alternate key. ● Mandatory participation pada 1 sisi dari 1:1 relationship Menurut (Connolly & Begg, 2010, p.466), dalam kasus ini, kita dapat mengidentifikasikan entitas - entitas parent dan child untuk 1:1 relationship memakai participation constraint. Entitas
yang
memiliki
optional
participation
dalam
relationship dianggap sebagai entitas parent, dan entitas yang mempunyai mandatory participation dalam relationship dianggap sebagai entitas child. Seperti yang diuraikan diatas, salinan primary key dari entitas parent ditempatkan dalam relasi yang merepresentasikan entitas child. Jika relationship mempunyai satu atau lebih atribut, atribut ini harus menyertakan penyalinan primary key ke relasi child. ● Optional participation pada 2 sisi dari 1:1 relationship Menurut (Connolly & Begg, 2010, p.467), kita dapat memilih primary key mana yang dipilih tergantung dari kasus yang ada. ● One-to-one (1:1) recursive relationship Menurut (Connolly & Begg, 2010, p.467), untuk 1:1 recursive
relationship,
kita
mengikuti
aturan
untuk
participation seperti yang diuraikan untuk 1:1 relationship. Untuk
1:1
recursive
relationship
dengan
mandatory
participation pada dua sisi, direpresentasikan recursive relationship sebagai relasi tunggal dengan dua salinan primary key. Sedangkan salah satu salinan dari primary key
28
merepresentasikan foreign key dan harus diganti namanya untuk menandakan relationship yang direpresentasikan. Untuk 1:1 recursive relationship dengan mandatory participation pada satu sisi, kita mempunyai pilihan untuk menciptakan relasi tunggal dengan dua salinan primary key atau untuk menciptakan relasi baru untuk merepresentasikan relationship. Relasi baru hanya akan mempunyai 2 atribut, keduanya merupakan salinan primary key. Untuk 1:1 recursive relationship dengan optional participation pada dua sisi, kita menciptakan relasi baru seperti yang telah diuraikan diatas. ● Superclass/subclass relationship types Menurut (Connolly & Begg, 2010, p.467),untuk tiap superclass / subclass relationship dalam data konseptual,
kita
mengidentifikasikan
entitas
model
superclass
sebagai entitas parent dan entitas subclass sebagai entitas child. Terdapat banyak pilihan dalam merepresentasikan relationship sebagai salah satu atau lebih relasi – relasi. Pilihan yang paling sesuai tergantung dari beberapa faktor seperti
disjointnese
dan
participation
constraint
pada
superclass / subclass relationship apakah subclass – subclass terlibat dalam distinct relationship dan jumlah participant – participant dalam superclass / subclass relationship. ● Many-to-many (*:*) binary relationship types Menurut (Connolly & Begg, 2010, p.469), untuk setiap *:*
binary
relationship
menghasilkan
relasi
untuk
merepresentasikan relationship dan meliputi atribut – atribut yang menjadi bagian dari relationship. Kita menyalin salinan primary key dari entitas yang berhubungan dalam relationship kedalam relasi baru. Untuk valid sebagai foreign key.
29
● Complex relationship types Menurut (Connolly & Begg, 2010, p.470), untuk setiap complex relationship menciptakan sebuah relasi untuk merepresentasikan relationship dan termasuk semua atribut yang merupakan bagian dari relationship tersebut. Kita menyalin salinan primary key dari entitas yang berhubungan dalam complex relationship kedalam relasi baru, untuk berlaku sebagai foreign key. ● Multi-valued attributes Menurut
(Connolly
&
Begg,
2010,
p.471),
menciptakan relasi yang merepresentasikan atribut – atribut multi-valued dan menyalin salinan primary key dari entitas owner kedalam relasi baru untuk menjadi foreign key. Langkah 2.2 Validasi Model dengan Normalisasi tujuannya adalah menurut (Connolly & Begg, 2010, p.473), untuk memvalidasi relasi – relasi dalam model data konseptual memakai teknik normalisasi. Menurut (Connolly & Begg, 2010, p.388), normalisasi adalah teknik untuk menghasilkan sekumpulan relasi – relasi dengan properti – properti yang diinginkan, sesuai dengan kebutuhan data – data yang diberikan oleh perusahaan. Tujuan dari normalisasi ini adalah untuk meminimalkan redudansi data (perulangan data) dan update anomalies, menciptakan representasi data, hubungan antar data dan contraint yang akurat, serta meningkatkan stabilitas. Untuk mencapai tujuan tersebut maka harus dilakukan identifikasi dengan benar atas relasi – relasi yang ada. Pada dasarnya, proses normalisasi ini dilakukan karena terjadinya redundansi data atau kejanggalan pengubahan (update anomaly).
30
Menurut (Connolly & Begg, 2010, p.391), update anomaly ada tiga jenis yaitu insert anomaly, delete anomaly, dan modification/update anomaly. Insert anomaly adalah kejanggalan yang terjadi terhadap sebuah table pada saat dilakukan penambahan suatu record, yaitu berupa pelanggaran terhadap
integrity
constraint.
Delete
anomaly
adalah
kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan penghapusan suatu record, penghapusan bermaksud untuk menghapus suatu data tertentu tetapi menyebabkan kehilangan
informasi
lain
dari
tabel
tersebut.
Modification/update anomaly adalah kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan pengubahan suatu record, pengubahan terhadap suatu nilai tertentu harus dilakukan lebih dari sekali. Hal ini amat memungkinkan terjadinya inkonsistensi data. Menurut (Connolly & Begg, 2010, p.401), proses normalisasi meliputi langkah – langkah utama berikut : -
First Normal Form ( 1NF ), yang menghilangkan repeating groups
-
Second Normal Form ( 2NF ), yang menghilangkan partial dependency dalam primary key
-
Third Normal Form ( 3NF ), yang menghilangkan transitive dependencies dalam primary key
-
Boyce-Codd Normal Form ( BCNF ), yang menghilangkan anomaly
–
anomaly
yang
tersisa
dari
functional
dependencies Langkah 2.3 Mevalidasi Relasi dengan User Transaction tujuannya adalah menurut (Connolly & Begg, 2010, p.474), untuk menjamin bahwa relasi – relasi dalam model data logikal mendukung transaksi – transaksi yang dibutuhkan oleh view.
31
Langkah 2.4 Mendefinisikan Kendala Integrity tujuannya adalah menurut (Connolly & Begg, 2010, p.474),untuk
memeriksa
direpresentasikan
dalam
integrity model
data
constraint logical.
yang Integrity
constraint terdiri dari 5 jenis, yaitu : data yang dibutuhkan, attribute domain constraint, entity integrity, referential integrity, dan general constraint. ● Data yang dibutuhkan Menurut (Connolly & Begg, 2010, p.475), beberapa atribut harus selalu memiliki nilai yang valid. Dengan kata lain, atribut tersebut tidak boleh bernilai null. ● Attribute domain constraint Menurut (Connolly & Begg, 2010, p.475), tiap atribut mempunyai domain, yaitu kumpulan nilai – nilai yang legal. Misalnya, ada 2 jenis kelamin yaitu ‘M’ atau ‘F’, jadi domain untuk atribut jenis kelamin adalah karakter string tunggal yang terdiri dari ‘M; atau ‘F’. Batasan ini harus diidentifikasikan ketika kita memilih domain atribut untuk model data. ● Multiplicity Menurut(Connolly & Begg, 2010, p.475), multiplicity merepresentasikan batasan yang diletakkan pada relationship antara data di dalam basis data. ● Entity integrity Menurut (Connolly & Begg, 2010, p.475), primary key dari entitas tidak boleh bernilai null. Batasan ini harus benar – benar dipertimbangkan
32
ketika kita mengidentifikasikan primary key untuk tiap tipe entitas. ● Referential integrity Menurut
(Connolly & Begg, 2010, p.475),
foreign key menghubungkan tiap tuple dalam relasi child ke tuple dalam relasi parent yang meliputi nilai candidate key yang sesuai. Referential integrity berarti bahwa jika foreign key memiliki nilai, maka nilai tersebut harus menunjuk pada tuple yang ada pada relasi parent. Menurut ( Connolly & Begg, 2010, p476 ), terdapat 5 strategi untuk mempertahankan referential integrity pada saat penghapusan tuple pada relasi parent, yaitu : -
NO ACTION Mencegah penghapusan dari relasi parent jika terdapat tuple – tuple child yang ditunjuk.
-
CASCADE Ketika tuple parent dihapus, secara otomatis juga dihapus tuple – tuple child yang ditunjuk
-
SET NULL Ketika tuple parent dihapus, nilai foreign key dalam semua tuple – tuple child yang berhubungan secara otomastis diubah menjadi null.
-
SET DEFAULT Ketika tuple parent dihapus, nilai foreign key dalam semua tuple – tuple child yang
33
berhubungan secara otomatis diubah menjadi nilai default-nya. -
NO CHECK Ketika tuple parent dihapus, tidak melakukan apa – apa untuk menjamin referential integrity tetap terjaga.
● General constraints Pengubahan – pengubahan pada entitas – entitas mungkin diatur oleh batasan – batasan yang memerintah
transaksi
’real
world’
yang
direpresentasikan oleh pengubahan tersebut Langkah 2.5 Me-review Logical Data Model dengan User tujuannya adalah menurut (Connolly & Begg, 2010, p.478),untuk menjamin bahwa pengguna mempertimbangkan model data logikal menjadi representasi yang sebenarnya dari kebutuhan data perusahaan. Langkah 2.6 Menggabungkan Logical Data Model ke dalam Global Model (optional) tujuannya adalah menurut (Connolly & Begg, 2010, p.479), untuk merepresentasikan semua user views dari basis data. Langkah 2.7 Memeriksa
untuk
perkembangan
lebih
lanjut tujuannya adalah menurut (Connolly & Begg, 2010, p.490),untuk menentukan apakah terdapat perubahan yang signifikan pada masa depan yang dapat diramalkan dan untuk menilai apakah model data logikal dapat mengakomodasi perubahan tersebut.
34
2.1.6.3 Perancangan Basis data Fisikal Menurut (Connolly & Begg , 2010, p.439), perancangan fisik basis data adalah proses membuat deskripsi dari implementasi basis data pada secondary storage, mendeskripsikan relasi dasar, file organization, dan index yang digunakan untuk mendapatkan akses efisien pada data dan semua integrity constraint yang berhubungan dan security measures. Tujuannya adalah untuk menentukan bagaimana struktur logikal diimplementasikan (sebagai relasi dasar) secara fisik dalam DBMS yang dipilih. Menurut (Connolly & Begg, 2010, p.496), langkah – langkah perancangan fisik basis data meliputi : Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih tujuannya adalah menurut (Connolly & Begg, 2010, p.497), untuk menghasilkan relational database schema dari data model logikal yang dapat diimplementasikan dalam DBMS yang dipilih. 3 aktifitas pada Step 3 : Langkah 3.1 Merancang relasi – relasi dasar tujuannya adalah menurut (Connolly & Begg,2010, p.498), untuk memutuskan bagaimana merepresentasikan relasi – relasi dasar yang diidentifikasikan dalam model data logikal dalam DBMS yang dipilih. Untuk tiap relasi yang diidentifikasi dalam model data logikal, kita mempunyai definisi yang terdiri dari : -
Nama relasi
-
Daftar atribut – atribut sederhana dalam golongan – golongan
-
Primary key dan alternate key dan foreign key jika ada
-
Referential integrity contraints untuk semua foreign keys yang diidentifikasikan
35
Menurut (Connolly & Begg, 2010, p.498), sedangkan dari data dictionary, dari tiap – tiap atribut kita juga mempunyai : -
Domain-nya, yang terdiri dari tipe data, panjang, dan semua batasan dalam domain
-
Nilai default optional untuk atribut
-
Apakah atribut dapat mempunyai nilai nulls
-
Apakah atribut tersebut derived, maka harus dikomputasi
Langkah 3.2 Merancang
Representasi
untuk
Data
Turunan tujuannya adalah menurut (Connolly & Begg, 2010, p.499), untuk menentukan bagaimana merepresentasikan semua data derived yang ada dalam model data logikal dalam DBMS yang dipilih. Atribut yang nilainya dapat dicari dengan memeriksa nilai – nilai dari atribut – atribut lainnya disebut derived atau calculated attribute. Langkah 3.3 Merancang General Constraint Menurut (Connolly & Begg, 2010, p.501), tujuannya adalah untuk merancang general constraint untuk DBMS yang dipilih. Langkah 4. Merancang file organization dan indexes Menurut (Connolly & Begg, 2010, p.501), tujuannya adalah untuk menentukan file organisasi yang optimal untuk menyimpan relasi – relasi dasar dan indeks – indeks yang dibutuhkan untuk mencapai performansi yang dapat diterima, dengan begitu, relasi dan tuple akan disimpan pada secondary storage. Terdapat beberapa factor yang dapat digunakan untuk mengukur efisiensi, yaitu :
36
-
Transaction throughput adalah jumlah transaksi yang dapat diproses dalam jangka waktu tertentu. Diukur pada kondisi peak.
-
Response time adalah waktu yang diperlukan untuk menyelesaikan satu transaksi. Dari pandangan pengguna, kita sedapat mungkin ingin meminimalkan response time. Response time ini biasanya dipengaruhi waktu untuk mengakses data yang diperlukan, system load, OS scheduling, communication delay.
-
Disk storage adalah jumlah disk space yang dibutuhkan untuk menyimpan file – file basis data. Para perancang sistem biasanya ingin meminimalkan disk storage yang digunakan.
Langkah 4.1 Menganalisa Transaksi tujuannya adalah menurut (Connolly & Begg 2010, p.502), untuk mengetahui fungsi dari transaksi yang akan diterapkan pada basis data dan untuk menganalisa transaksi – transaksi yang penting. Langkah 4.2 Memilih Organisasi file tujuannya adalah menurut (Connolly & Begg, 2010, p.506), untuk menentukan organisasi file yang paling efisien untuk tiap relasi dasar. Langkah 4.3 Memillih index – index tujuannya adalah menurut (Connolly & Begg, 2010, p.508),
untuk
mempertimbangkan
apakah
dengan
menambahkan index akan meningkatkan performansi dari sistem. Langkah 4.4 Memperkirakan kebutuhan disk space Menurut (Connolly & Begg, 2010, p.514), untuk memperkirakan jumlah disk space yang dibutuhkan oleh basis
37
data. Untuk menyimpan data dan semua index – index nonclustered dasar dalam tabel yang tidak mempunyai clustered index oleh karena itu kita dapat menggunakan beberapa langkah berikut : 1. Menghitung space yang digunakan untuk menyimpan data 2. Menghitung space yang digunakan untuk menyimpan tiap index – index nonclustered dasar. 3. Menjumlahkan nilai – nilai yang dikalkulasikan.
Langkah 5. Merancang user view tujuannya adalah menurut (Connolly & Begg 2010, p.515), untuk
merancang
user
view
yang
diidentifikasikan
selama
pengumpulan kebutuhan – kebutuhan dan tahap analisis dari system development lifecycle. Langkah 6. Merancang mekanisme keamanan tujuannya adalah menurut (Connolly & Begg, 2010, p.516), untuk merancang mekanisme keamanan untuk basis data seperti yang ditentukan oleh user pada waktu tahap pengumpulan kebutuhan – kebutuhan dari system development lifecycle. Mekanisme kemanan yang dirancang dalam basis data yaitu mekanisme keamanan sistem dan mekanisme keamanan data. Langkah 7. Mempertimbangkan pengenalan redudancy control tujuannya adalah menurut (Connolly & Begg, 2010, p.519), untuk menentukan apakah pengenalan redundancy yang dikontrol dengan aturan – aturan normalisasi akan meningkatkan performansi sistem. Langkah 8. Mengawasi dan mengendalikan sistem operasional tujuannya adalah menurut (Connolly & Begg, 2010, p.532), untuk mengawasi sistem operasional dan meningkatkan performansi
38
dari sistem untuk memperbaiki keputusan perancangan yang tidak sesuai atau merefleksikan perubahan kebutuhan. 2.1.7 ER Modeling 2.1.7.1 Entity Type Pada kutipan jurnal (Bahl, Sharma & Rajpal, 2011, p.2), entity relationships (ER) model digunakan untuk menunjukkan hubungan antar entitas dan sebagai tool dasar dalam merancang basis data Menurut (Connolly & Begg, 2010, p.343), entity type adalah kelompok objek dengan properties yang sama, yang didefinisikan untuk perusahaan selama mempunyai keadaan yang independent. Entity type mempunyai keadaan yang independent dan dapat berupa objek – objek dengan keberadaan fisik atau objek – objek dengan keberadaan konseptual 2.1.7.2 Entity Occurrence Menurut (Connolly & Begg, 2010, p.345), entity occurrence adalah objek dari entity type yang dapat diidentifikasi secara unik. 2.1.7.3 Relationship Type Menurut (Connolly & Begg, 2010, p.346), relationship type adalah sekelompok penyatuan yang memiliki arti antar entity types atau sekelompok penyatuan antara satu atau lebih participating entity type. 2.1.7.4 Relationship Occurrence Menurut (Connolly & Begg, 2010, p.346), relationship occurrence adalah penyatuan yang dapat diidentifikasikan secara unik, yang terdiri dari 1 occurrence dari tiap participating entity type. 2.1.7.5 Derajat tipe relasi (Degree of relationship type) Menurut (Connolly & Begg, 2010, p.376), derajat tipe relasi merupakan jumlah tipe entitas yang berpartisipasi dalam relasi.Entitas yang berkaitan dalam tipe relasi dikenal sebagai participant dalam relasi. Jumlah participant dalam tipe relasi dikenal sebagai degree dari relasi. Relasi dengan
39
degree dua disebut binary, sedangkan relasi dengan degree tiga disebut ternary, dan relasi dengan degree empat disebut quaternary.
2.1.7.6 Relasi Rekursif (Recursive relationship) Menurut Connolly dan Begg (2010, p376), relasi rekursif merupakan sebuah tipe relasi dimana tipe entity yang sama berpartisipasi lebih dari satu kali dalam peran yang berbeda.
2.1.7.7 Atribut Menurut (Connolly & Begg, 2010, p350), atribut adalah property dari entitas atau relationship type. Atribut domain adalah sekumpulan nilai – nilai yang
diperbolehkan
untuk
satu
atau
lebih
atribut.
Atribut
dapat
diklasifikasikan menjadi simple atau composite ; single-valued atau multivalued; atau derived. Simple attribute adalah atribut yang terdiri dari komponen tunggal dengan keadaan independent. Sedangkan composite attribute adalah atribut yang terdiri dari beberapa komponen, dimana setiap komponen dengan keadaan independent contoh nama bisa dipecah lagi menjadi nama depan dan nama belakang. Single-valued attribute adalah atribut yang memiliki nilai tunggal untuk setiap kejadian contohnya entitas staff memiliki IDstaff. Sedangkan multi-valued attribute adalah atribut yang memiliki beberapa nilai untuk kejadian contoh no telepon pasti setiap orang mempunyai beberapa telepon . Derived attribute adalah atribut yang merepresentasikan nilai yang diperoleh (derived) dari satu atau lebih atribut yang berhubungan contoh lama pinjam dihasilkan dari awal tanggal pinjam dikurangi tanggal pengembalian. 2.1.7.8 Key Menurut (Connolly & Begg, 2010, p.352), candidate key adalah sekelompok atribut yang minimal dan secara unik mengidentifikasikan tiap occurrence dari entity type.
40
Menurut (Connolly & Begg, 2010, p.353), primary key adalah key yang dipilih untuk mengidentifikasikan secara unik tiap occurrence dari entity type. Menurut (Connolly & Begg 2010, p.353), composite key adalah candidate key yang terdiri dari dua atau lebih atribut. 2.1.7.9 Structural constraint Tipe utama dari constraint dari relationship disebut multiplicity. Multiplicity adalah jumlah dari kejadian – kejadian yang mungkin dari sebuah tipe entitas yang terhubung pada kejadian tunggal dari tipe entitas yang berhubungan melalui relationship khusus. Tiga jenis relationship yang digunakan mengikuti enterprise constraint : •
Hubungan one-to-one (1:1)
Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satu-satu dan dapat pula member entitas yang satu ada yang tidak berhubungan dengan member dari entitas yang berelasi dengannya dan entitas tersebut juga berelasi maksimal 1. Contoh : satu ruang kelas hanya memiliki satu computer dan. Diasumsikan didalam ruangan tersebut 1..1
memiliki
1..1
Ruang kelas
komputer
Gambar 2.4 Hubungan one-to-one (1:1) •
Hubungan one-to-many (1:*)
Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satu-banyak. Dimana sebuah member dari entitas dapat berhubungan dengan satu atau banyak member dari entitas yang lain dan member dari entitas yang lainnya berhubungan (bisa dari 0) sampai maksimal 1. Contoh : seorang manager dapat memiliki 1 hingga banyak karyawan, tetapi seorang guru hanya memiliki satu dan hanya satu manager.
41
memiliki
1..1
1..*
manager
karyawan
Gambar 2.5 Hubungan one-to-many (1:*) •
Hubungan many-to-many (*:*)
Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah banyak-banyak. Member dari sebuah entitas dapat berelasi dengan entitas yang lain dengan maksimal multiplicity banyak (*) dan sebaliknya dengan relasi entitas yang berhubungan tersebut. Contoh : Pembelian dapat memilih 0 hingga banyak produk yang ingin dibeli, tetapi produk dapat dipilih untuk dibeli oleh 0 hingga banyak pembeli pada satu jenis produk.
0..*
Order >
0..*
Pembelian
barang
Gambar 2.6 Hubungan many-to-many (*:*) 2.1.8 Spesialisasi/ Generalisasi (Specialization/Generalization ) Menurut Thomas (Connolly & Begg, 2010, p.400-403),konsep dari spesialisasi dan generalisasi adalah asosiasi tipe entitas dengan tipe entitas khusus yang dikenal sebagai superclass dan subclass, dan proses dari atribut turunan (inheritance).Superclass adalah suatu tipe entitas yang mengandung satu atau lebih subgroup terpisah dari suatu occurance, yang dibutuhkan untuk direpresentasikan pada suatu data model. Subclass adalah suatu subgroup terpisah dari occurance suatu tipe entitas, yang dibutuhkan untuk direpresentasikan pada suatu data model.
2.1.9 Normalisasi 2.1.9.1 Pengertian Normalisasi
42
Menurut (Connolly & Begg, 2010, p.401), normalisasi adalah teknik formal untuk mnganalisa relasi berdasarkan pada primary key (atau candidate key) dan functional dependencies. 2.1.9.2 Tahapan - tahapan Normalisasi 2.1.9.2.1 UNF (Un-Normal Form) Menurut (Connolly & Begg, 2010, p.402), proses normalisasi dimulai dari bentuk UNF (Un-Normal Form), yaitu table yang masih mengandung repeating group. Tabel UNF ini dibuat dengan mentransformasi data dari sumber informasi ( seperti formulir ) ke dalam tabel berbentuk baris dan kolom. 2.1.9.2.2 1NF (First Normal Form) Menurut (Connolly & Begg, 2010, p403), pada bentuk normal pertama ( First Normal Form – 1NF ), sebuah relasi dimana pada setiap sel ( perpotongan baris dan kolom ) jika dan hanya jika mengandung satu nilai, setiap sel mengandung nilai atomik ( single value ). Untuk menjadikan bentuk tidak normal menjadi normal pertama dengan mengidentifikasikan dan menghilangkan repeating groups yang ada di dalam tabel. Repeating group adalah sebuah atau sekumpulan atribut dalam tabel yang memiliki multiple values untuk single occurrence dari atribut key yang terpilih untuk tabel tersebut. 2.1.9.2.3 2NF (Second Normal Form) Menurut (Connolly & Begg 2010, p.407), sebuah tabel disebut berada pada bentuk normal kedua ( 2NF ) jika dan hanya jika setiap atribut bukan primary key ( PK ) tergantung sepenuhnya pada PK. Untuk mengetahui apakah 1NF telah berada pada 2NF maka tentukan PK dan funtional dependency. 2.1.9.2.4 3NF (Third Normal Form) Menurut (Connolly & Begg, 2010, p.408), sebuah tabel disebut berada pada bentuk normal ketiga jika dan hanya jika tidak
43
ada atribut bukan primary key yang bergantung kepada atribut bukan primary key lainnya. Sebuah tabel yang mengandung atribut bukan PK yang tergantung pada atribut PK lainnya disebut transitive dependency. Dengan kata lain sebuah tabel disebut berada pada 3NF jika dan hanya jika tidak mengandung transitive dependency. 2.1.9.2.5 BCNF (Boyce-Codd Normal Form) Menurut (Connolly & Begg, 2010, p.419), suatu relasi dianggap sebagai bentuk normal BCNF jika dan hanya jika setiap determinant adalah candidate key. Untuk mengetahui apakah suatu tabel sudah berada pada bentuk normal BCNF maka harus dilakukan analisa atas functional dependency dari sebuah tabel. 2.1.10 Teori Activity Diagram Definisi activity diagram menurut (Satzinger, Jackson, & Burd, 2009, p.141), adalah diagram alur kerja yang menggambarkan berbagai kegiatan pengguna atau sistem, orang yang melakukan setiap kegiatan, dan aliran sekuensial dari kegiatan ini.
Gambar 2.7 Notasi Activity Diagram (Satzinger, 2009)
Notasi – notasi dalam activity diagram antara lain: 1. Oval mewakili kegiatan individu dalam sebuah alur kerja. 2. Connecting Arrow mewakili urutan antara kegiatan.
44
3. Black Circles digunakan untuk menunjukkan awal dan akhir dari alur kerja. 4. Diamond merupakan titik keputusan dimana aliran proses tersebut akan mengikuti satu jalur atau jalur lain. 5. Synchronization Bar merupakan garis padat yang membagi satu jalur ke beberapa jalur atau menggabungkan jalur secara bersamaan. 6. Swimline membagi kegiatan – kegiatan pada alur kerja menjadi kelompok – kelompok yang menunjukkan agen – agen yang melakukan aktivitas – aktivitas.
2.1.11 Use Case Diagram Menurut (Satzinger, Jackson, & Burd, 2009, p.141), use case diagram adalah “sebuah diagram yang menunjukkan berbagai peran user dan bagaimana peran tersebut menggunakan sistem”.. Notasi-notasi yang digunakan dalam use case diagram terdiri dari: 1. Use case: suatu kegiatan yang dilakukan oleh sistem, biasanya dalam menanggapi permintaan oleh pengguna sistem. 2. Actor: orang yang menggunakan sistem pada setiap use case. 3. Connecting Line: berada di antara aktor dan use case yang mengindikasikan aktor mana yang menjalankan use case. 4. Automation Boundary: menunjukkan batas antara lingkungan dimana aktor berada dengan komponen internal dari sistem komputer.
(Satzinger, Jackson, & Burd, 2009, p.242) Gambar 2.8 Notasi untuk Use Case Diagram 2.1.12 State transition diagram (STD) State Transition Diagram adalah suatu tools modelling yang menggambarkan sifat dependent pada waktu dari suatu sistem.
45
Menurut (Harel & Moore, 2011) State Transition Diagram digunakan untuk membuat modelling berorientasi objek. Hal yang mendasarinya adalah untuk mengartikan suatu sistem yang memiliki sejumlah states. Suatu sistem menerima kejadian dari interaksi yang ada di luar, dan masing - masing kejadian tersebut menyebabkan perpindahan dari satu state ke state lainnya. STD juga memiliki arah yang mengelilingi dalam pemodelan berorientasi objek. Hal tersebut menjelaskan behavior suatu sistem. Ini berarti mengharuskan analis untuk mendefinisikan semua state yang mungkin terjadi dan ada pada suatu sistem. Baik pada sistem yang kecil, maupun sistem yang besar.
Ada 2 (dua) jenis STD, yaitu : model Harel dan model Moore. Sebagai gambaran,dapat dilihat pada gambar di bawah ini : a. State Transition Diagram model Harel
Gambar 2.9 Contoh STD model Harel (Harel & Moore, 2011)
46
sumber :http://www.cs.unc.edu/~stotts/145/CRC/state.html
Gambar 2.10 Contoh State Transistion Diagram model Moore (Harel & Moore, 2011) Sumber : http://www.cs.unc.edu/~stotts/145/CRC/state.html
2.2 Teori Khusus Teori khusus merupakan teori pendukung yang dibuat untuk memenuhi kriteria dari batasan masalah analisa dan perancangan yang dihadapi 2.2.1 Pembelian Menurut (Hall, 2008, p.235), prosedur pembelian terdiri dari tugas – tugas yang meliputi identifikasi kebutuhan persediaan, penempatan order, penerimaan persediaan. Secara umum definisi pembelian adalah usaha pengadaan barang atau jasa dengan tujuan yang akan digunakan sendiri, untuk kepentingan proses produksi yang selanjutnya barang atau jasa tersebut akan di jual kembali, baik dengan atau tanpa proses, dalam proses pembelian
47
yang ada, agar kegiatan pembelian dapat dilakukan dengan benar. Fungsi pembelian betanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang, dan mengeluarkan pesanan pembelian kepada pemasok yang dipilih. Dokumen – dokumen yang terkait atau termasuk dalam prosedur sistem pembelian adalah sebagai berikut :
1.
Purchase order Dokumen purchase order disiapkan ketika adanya kebutuhan barang atau jasa yang dibutuhkan . Dokumen purchase order disiapkan untuk melakukan pembelian kepada supplier, tentu kepada supplier yang sudah termasuk di dalam daftar list. Duplikat dari purchase order diberikan kepada supplier, bagian keuangan untuk membuat account payabl), dan terakhir diberikan kepada bagian gudang (persediaan).
2.
Retur Pembelian Retur pembelian merupakan dokumen yang dibuat apabila barang yang kita beli rusak atau tidak sesuai dengan apa yang kita inginkan, dokumen yang diberikan dari bagian pembelian
kepada supplier untuk ditanggung jawabkan
barang atau jasa tersebut.
Proses pembelian adalah sebuah struktur interaksi antar orang-orang, peralatan, metode-metode, dan pengendalian yang dirancang untuk mencapai fungsi-fungsi utama berikut (Indrajani, 2011,p71) : 1. Menangani rutinitas pekerjaan yang berulang-ulang dari bagian pembelian dan bagian gudang(persediaan). 2. Mendukung kebutuhan pengambilan keputusan dari orang-orang yang mengatur bagian pembelian dan persediaan. 3. Membantu Penyiapan laporan internal dan eksternal Aktivitas Siklus Pembelian
48
Aktivitas-aktivitas yang ada dalam sebuah sistem pemrosesan pembelian (purchases processing system) (Indrajani, 2011 , p71-72): 1. Fungsi pembelian berawal dari kebutuhan untuk menyediakan stok kembali setelah melalui pengamatan atas catatan persediaan. Tingkat persediaan menurun karena penjualan langsung kepada pelanggan atau karena pengeluaran ke proses produksi. Informasi atas kebutuhan persediaan dikirimkan ke bagian proses pembelian dan utang usaha (account payable). 2. Proses pembelian menentukan kuantitas yang akan dipesan, memilih pemasok, dan menyimpan purchase order. Informasi ini dikirimkan ke pemasok dan bagian proses utang usaha. 3. Setelah suatu periode tertentu, perusahaan menerima persediaan dari pemasok. Barang yang diterima akan diperiksa terlebih dahulu untuk menjamin kuantitas dan kualitas kemudian dikirimkan ke toko atau gudang. 4. Informasi
mengenai
penerimaan
persediaan
digunakan
untuk
memperbarui catatan persediaan. 5. Bagian proses utang usaha (account payable) menerima faktur (invoice) dari pemasok. Bagian ini kemudian akan merekonsiliasi informasi dalam faktur ini dengan informasi lainnya yang telah dikumpulkan sehubungan dengan transaksi ini, kemudian mencatat kewajiban (obligation) untuk pembayaran di waktu mendatang, tergantung jangka waktu pembayaran dengan pemasok. Biasanya, pembayaran akan dilakukan pada hari terakhir jangka waktu pembayaran untuk mengambil manfaat atas bunga dan diskon yang ada. 6. Buku besar (general ledger) akan menerima informasi dari bagian utang usaha (account payable) berupa total peningkatan dari utang (liabilities) dan dari bagian pengendalian persediaan berupa total peningkatan persediaan. Informasi ini direkonsiliasi untuk menjamin keakuratan dan diposting ke akun utang usaha dan persediaan (account payable and inventory). 2.2.2 Persediaan
49
Asset yang tersedia untuk dijual dalam proses bisnis biasa atau asset yang ada dalam proses produksi untuk dijual kembali, atau asset dalam bentuk material atau bahan baku untuk digunakan dalam proses produksi. Asset di sini dapat berbentuk barang atau jasa (Indrajani, 2011 , p70-71). Dalam perusahaan dagang, persediaan hanya terdiri atas satu golongan, yaitu persediaan barang dagangan, yang merupakan barang yang dibeli untuk tujuan dijual kembali. Transaksi yang mengubah persediaan produk jadi, persediaan bahan baku, persediaan bahan penolong, persediaan bahan habis pakai pabrik, persediaan suku cadang, bersangkutan dengan transaksi internal perusahaan dan transaksi yang menyangkut pihak luar perusahaan (penjualan dan pembelian). Suatu perusahaan memiliki inventory (persediaan) dengan tujuan untuk menjaga kelancaran usahanya. Bagi perusahaan, persediaan barang dagangan memungkinkan untuk memenuhi permintaan pembeli atau pasar. Di satu sisi persediaan yang tinggi memungkinkan perusahaan untuk memenuhi permintaan yang mendadak, akan tetapi di sisi lain persediaan yang tinggi menyebabkan perusahaan memerlukan modal kerja yang makin besar pula. Untuk itu dibutuhkan pengelolaan terhadap persediaan.Tujuan pengelolaan inventory adalah turnover (perputaran) dari inventory, yaitu turnover secepat mungkin tanpa kehilangan sales sebagai akibat kehabisan inventory.
Pemeliharaan atau pengawasan persediaan adalah sesuatu hal biasa dalam semua organisasi di setiap faktor ekonomi. (Yamit, 2005, p.3) mengatakan bahwa masalah persediaan tidak hanya terbatas pada perusahaan pencari keuntungan saja tetapi juga dialami oleh organisasi sosial maupun perusahaan non profit oriented, seperti persediaan dalam pabrik, agrobisnis, pedagang besar, pengecer, rumah sakit, sekolah, hotel dan mesjid, rumah tangga, restoran, pemerintah dan lain sebagainya. Istilah (terminologi) persediaan bisa digunakan dalam perbedaan seperti : 1.
Persediaan bahan baku di tangan (stock on hand)
2.
Daftar persediaan secara fisik
50
3.
Jumlah item di tangan
4.
Nilai persediaan barang
Fungsi persediaan Menurut (Yamit, 2005, p.5), persediaan muncul disebabkan oleh tidak sesuainya permintaan dengan penyediaan dan waktu yang digunakan untuk memproses material / bahah baku. untuk menjaga keseimbangan permintaan dengan penyediaan material dan waktu proses diperlukan persediaan. Oleh karena itu, terdapat empat faktor yang dijadikan sebagai fungsi perlunya persediaan, yaitu 1.
Faktor waktu Faktor waktu menyangkut lamanya proses produksi dan distribusi sebelum barang jadi sampai kepada konsumen seperti outlet/distro. Waktu diperlukan untuk membuat jadwal produksi, sablon/bordir bahan baku, pengiriman bahan baku, pengawasan bahan baku, produksi dan pengiriman barang jadi ke outlet dan distro. Persediaan dilakukan untuk memenuhi kebutuhan selama waktu tunggu (lead time).
2.
Faktor ketidakpastian waktu datang Faktor
ketidakpastian
waktu
datang
dari
supplier
menyebabkan perusahaan memerlukan persediaan, agar tidak menghambat proses produksi maupun keterlambatan pengiriman kepada outlet/distro. Persediaan bahan baku terikat pada supplier, persediaan barang dalam proses terikat pada departemen produksi dan persediaan barang jadi terikat pada konsumen seperti outlet/distro. Ketidak pastian waktu datang mengharuskan perusahaan membuat jadwal operasi lebih detail pada setiap tingkatan.
3.
Faktor ketidakpastian penggunaan dalam pabrik Faktor ketidakpastian penggunaan dari dalam perusahaan disebabkan oleh kesalahan dalam peramalan permintaan, kerusakan
51
mesin, keterlambatan operasi, bahan cacat, dan berbagai kondisi lainnya. Persediaan dilakukan untuk mengantisipasi ketidaktepatan peramalan maupun akibat lainnya tersebut.
4.
Faktor ekonomis Faktor ekonomis adalah adanya keinginan perusahaan untuk mendapatkan alternatif biaya rendah dalam memproduksi atau membeli item dengan menentukan jumlah yang paling ekonomis. Pembelian
dalam
jumlah
besar
memungkinkan
perusahaan
mendapatkan potongan harga yang dapat menurunkan biaya. Selain itu pemesanan dalam jumlah besar dapat pula menurunkan biaya karena biaya transportasi per unit menjadi lebih rendah. Persediaan diperlukan untuk menjaga stabilitas produksi dan fluktuasi bisnis.
Fungsi Inventory Inventory memiliki fungsi tersendiri, sebagaimana tujuan dari diadakannya persediaan, berikut ini fungsi-fungsi utamanya (Indrajani, 2011, p71) yaitu : 1.
Menghilangkan/mengurangi resiko keterlambatan pengiriman bahan.
2.
Menyesuaikan dengan jadwal produksi.
3.
Menghilangkan/mengurangi resiko kenaikan harga.
4.
Menjaga persediaan bahan yang dihasilkan secara musiman.
5.
Mengantisipasi permintaan yang diramalkan.
6.
Mendapatkan keuntungan dari quantity discount.
7.
Komitmen terhadap pelanggan
2.2.3 Pengertian Penjualan Penjualan merupakan kegiatan yang dilakukan oleh penjual dalam menjual barang atau jasa dengan harapan akan memproleh laba dari adanya transaksi -
52
transaksi tersebut dan penjualan dapat diartikan sebagai pengalihan atau pemindahan hak kepemilikan atas barang atau jasa dari pihak penjual ke pembeli. Pengertian penjualan ada bermacam- macam. Namun, menurut (Mulyadi, 2001, 202) adalah sebagai berikut : Dalam trasaksi penjualan credit, jika order dari pelanggan telah terpenuhi dengan pengiriman barang atau penyerahan jasa, untuk jangka waktu tertentu perusahaan memiliki pituang kepada pelanggannya. Kegiatan penjualan secara kredit ini ditangani oleh perusahaan melalui sistem penjualan kredit. Jadi, secara umum penjualan pada sadarnya terdiri dari dua jenis yaitu penjualan tunai dan kredit. Penjualan tunai terjadi apabila penyerahan barang atau jasa secara diikuti dengan pembayaran dari pembelian, sedangkan penjualan kredit ada tenggang waktu antara saat penyerahan barang dan atau jasa dalam penerimaan pembelian. Dalam penjualan kredit, pada saat penyerahan barang dan atau jasa, penjual menerima tanda bukti penerimaan barang. Keuntungan dari penjualan tunai adalah hasil dari penjualan tersebut langsung
terealisir
mempertahankan
dalam
bentuk
likuiditasnya, tetapi
kas
yang
saat
ini
dibutuhkan
perusaan
untuk
umumnya
pembelian
lebih
cenderung dilakukan secara kredit. Oleh karena itu, dalarn rangka usaha untuk memperbesar volume penjualaunya, umumnya perusahaan menjual produknya secara kredit. Penjualan kredit tidak segera menghasilkan pendapatan kas, tetapi kemudian menumbulkan
pituang.
Kerugaian
dari
pei\iualan kredit
adalah timbulnya
biaya administrasi piutang dan kerugian akibat piutang tak tertagih. Penjualan Tunai Secara umum, terdapat dua jenis penjualan, yaitu penjualan tunai dan penjualan kredit. Menurut (Narko, 2008, p.71) pengertian penjualan tunai adalah sebagi berikut: "sistem penjualan dikatakan penjualan tunai apabila pembeli sudah memilih barang yang adakn di beli, pembeli diharuskan membayar ke bagian kassa". Jadi penjualan tunai adalah penjualan yang trasaksi pembayaran dan pemindahan hak atas barangnya langsung. Sehingga tidak perlu ada prosedur piutang pada perusahaan penjual.
53
Penjualan Kredit Selain penjualan tunai, jenis penjualan lainnya adalah penjualan kredit. Penjualan
credit menurut (Mulyadi, 2001, p.202)
adalah
sebagai berikut:
"penjualan kredit dilaksanakan oleh perusahaan dengan cara mengirimkan barang sesuai dengan order yang diterima dari pembeli dan untuk jangka waktu tertentu perusahaan mempunyai tagihan kepada pembeli tersebut." 2.2.4 Kebutuhan Untuk Implementasi 2.2.4.1 PHP PHP Hypertext Preprocessor merupakan HTML-embedded scripting language, maksudnya adalah bahasa pemrograman yang bisa dimasukan kedalam penggunaan HTML. PHP mengkombinasikan fitur-fitur terbaik dari bahasa pemrograman modern untuk menciptaan pendekatan yang unik untuk membuat aplikasi web. Walaupun banyak bahasa pemrograman namun PHP didesain dari dasar hingga keatas dengan menggunakan pemikiran webdevelopment (Allen & Hornberger, 2002, p xix )
2.2.4.2 MySQL Menurut (Allen & Hornberger, 2002, p.220) MySQL merupakan bahasa pemrograman open source yang paling popular dan banyak digunakan di lingkungan Linux. Kepopuleran ini karena ditunjang oleh performansi query dari databasenya yang jarang bermasalah. (Nugroho, 2004, p.29) mengemukakan, MySQL (My Structure Query Language) adalah sebuah program pembuat database yang bersifat open source, artinya siapa saja dapat menggunakannya secara bebas.
Karena
sifatnya open source, MySQL dapat berjalan pada semua platform baik Windows maupun Linux.
Selain itu, MYSQL juga merupakan program
pengakses database yang bersifat jaringan sehingga dapat digunakan untuk aplikasi multiuser (banyak pengguna). Saat ini database MYSQL telah digunakan oleh hampir semua pemrograman database , terlebih dalam pemrograman web
54
KERANGKA BERPIKIR
Melakukan survey dan wawancara ke perusahaan
Mengididentifikasi masalah dengan menanyakan proses bisnis yang sedang berjalan di perusahaan
Membuat perancangan basis data sesuai ketentuan Database System
Development Lifecycle
Melakukan protyping ke perusahaan
