7
TINJAUAN PUSTAKA
2.1 Teori Umum
2.1.1 Data
Data adalah fakta atau observasi mentah yang biasanya mengenai femonena fisik atau transaksi bisnis. Lebih khusus lagi, data dapat dikatakan dengan suatu ukuran objektif dari atribut (karakteristik) dari entitas seperti tempat, benda atau kejadian (Indrajani, 2009:2).
Data merupakan komponen terpenting dari DBMS. Data berfungsi sebagai jembatan yang menghubungkan komponen mesin dengan komponen orang (Connolly dan Begg, 2010:70).
2.1.2 Basis Data
Connolly dan Begg (2010:65) menyatakan bahwa basis data adalah suatu kumpulan data logikal yang saling berhubungan dan mendeskripsikan data tersebut serta dirancang untuk menemukan informasi yang dibutuhkan oleh organisasi.
Basis data juga dapat diartikan sebagai sebuah tempat penyimpanan yang dapat menampung data dalam jumlah banyak yang dapat digunakan secara bersamaan oleh berbagai departemen dan pengguna.
Dalam basis data, terdapat tiga istilah penting, yaitu entitas, atribut dan relationship. Entitas adalah sebuah objek (bisa seseorang, tempat, sesuatu, konsep, atau kejadian) dalam suatu organisasi yang harus direpresentasikan dalam basis data. Atribut adalah suatu properti yang menjelaskan beberapa aspek dari suatu objek yang ingin direkam. Relationship adalah hubungan antara beberapa entitas (Connolly dan Begg, 2010:65).
2.1.3 Database Management System (DBMS)
Connolly dan Begg (2010:67) menyatakan bahwa Database Management Systems adalah suatu sistem perangkat lunak yang memungkinkan pengguna dalam mendefinisikan, membuat, mengelola dan mengatur akses terhadap basis data.
2.1.3.1 Komponen Lingkungan DBMS
Connolly dan Begg (2010:68) menyatakan bahwa terdapat 5 komponen utama dalam DBMS Environtment yang dapat diidentifikasi, yaitu hardware, software, data, procedures dan people.
Gambar 2.1
Komponen DBMS Environtment (Connolly dan Begg, 2010:68)
1. Hardware
DBMS dan aplikasi lainnya membutuhkan perangkat keras agar bisa berjalan. Perangkat keras bisa berupa single personal computer, single mainframe, atau network of computers. Tidak semua DBMS dapat berjalan pada berbagai macam perangkat keras atau sistem operasi (Connolly dan Begg, 2010:69).
2. Software
Komponen dari perangkat lunak terdiri atas perangkat lunak DBMS itu sendiri dan program aplikasi lainnya, bersamaan dengan sistem operasi, termasuk jaringan
komputer jika DBMS dioperasikan melalui jaringan (Connolly dan Begg, 2010:70).
3. Data
Data sebagai komponen penting dari DBMS Environtment berdasarkan sudut pandang pengguna adalah sebagai penghubung anatara komponen mesin dengan komponen manusia (Connolly dan Begg, 2010:70).
4. Procedures
Prosedur berisi instruksi - instruksi dan aturan - aturan yang mengatur suatu rancangan dan penggunaan dari basis data (Connolly dan Begg, 2010:70). Instruksi yang ada di dalamnya yaitu:
a. Login ke dalam DBMS
b. Menggunakan fasilitas DBMS tertentu atau program aplikasi.
c. Memulai dan mengakhiri DBMS d. Membuat backup basis data
e. Menangani kegagalan perangkat lunak dan perangkat keras.
f. Mengubah struktur tabel, mengatur ulang basis data melalui multiple disks, meningkatkan kinerja atau data arsip pada secondary storage.
5. People
Komponen terakhir yaitu manusia yang juga terlibat langsung dengan sistem basis data itu sendiri, dapat diidentifikasikan sebagai data administrators, database administrators, database designer, application developers dan end-users (Connolly dan Begg, 2010:71).
2.1.3.2 Keuntungan DBMS
Connolly dan Begg (2010:77) menyatakan bahwa terdapat 14 keuntungan dengan menggunakan DBMS, yaitu:
1. Control of data redundancy
Pendekatan basis data yang digunakan untuk mengeliminasi redundansi dengan cara mengintegrasikan file - file sehingga banyaknya file dari data - data yang sama tidak akan disimpan. Namun, dengan melakukan hal ini, tidak akan menghilangkan redundansi secara keseluruhan, melainkan untuk mengatur jumlah redundansi yang terdapat dalam suatu basis data (Connolly dan Begg, 2010:77).
2. Data consistency
Dengan menghilangkan atau mengatur redundansi, akan meminimalisasi terjadinya data yang tidak konsisten untuk muncul. Jika ada data yang disimpan hanya sekali dalam basis data, jika terdapat pembaruan yang diberlakukan, maka perubahannya akan tersedia untuk semua penguna sesegera mungkin. Tetapi jika data yang disimpan lebih dari sekali, dan sistem menyadarinya, maka sistem dapat memastikan bahwa semua copies dari data akan tetap konsisten (Connolly dan Begg, 2010:77).
3. More information from the same amount of data
Dengan terintegrasinya operasional data, maka memungkinkan organisasi dalam memperoleh tambahan informasi yang berasal dari data yang sama (Connolly dan Begg, 2010:77).
4. Sharing of data
Basis data dari suatu perusahaan dapat digunakan oleh semua pengguna yang memiliki otorisasi. Sejauh ini, aplikasi baru dapat dibangun pada data yang sudah ada dalam suatu basis data dan
menambahkan data yang hanya belum tersimpan. Aplikasi baru juga dapat menggunakan fungsi yang sudah disediakan oleh DBMS seperti, mendefinisikan data dan manipulasi data (Connolly dan Begg, 2010:78).
5. Improved data integrity
Integrasi basis data menunjukkan validasi dan konsistensi dari data yang tersimpan. Integrasi dari data ini biasa digunakan dalam bentuk constraint (Connolly dan Begg, 2010:78).
6. Improved security
Kemanan basis data merupakan perlindungan terhadap basis data dari pengguna yang tidak memiliki wewenang. Akses yang diperbolehkan untuk pengguna yang memiliki wewenang tertentu berdasarkan operasi tertentu (retrieval, insert, update, delete) (Connolly dan Begg, 2010:78).
7. Enforcement of standard
Integrasi memperbolehkan Database Administrators (DBA) untuk menegakkan suatu standar yang diperlukan, meliputi departemen, organisasi, nasional, maupun internasional (Connolly dan Begg, 2010:78).
8. Economy of scale
Dengan menggabungkan seluruh data operasional organisasi dan membuat suatu set aplikasi akan berdampak terhadap penghematan biaya (Connolly dan Begg, 2010:78).
9. Balance of conflicting requirements
Setiap pengguna atau departemen mempunyai kebutuhan yang memungkinkan terjadinya konflik terhadap kebutuhan dari pengguna lain. Karena basis data yang diatur oleh DBA, sehingga DBA bisa dapat mengambil keputusan tentang rancangan dan
penggunaan operasional data. Keputusan ini akan menunjukkan kinerja yang optimal (Connolly dan Begg, 2010:79).
10. Improved data accessibility and responsiveness
Sebagai dampak dari integrasi, maka data dapat diakses secara langsung oleh end user melalui batasan departemen. Kondisi ini menyebabkan sistem dengan fungsionalitas yang lebih berpotensi (Connolly dan Begg, 2010:79).
11. Increased productivity
DBMS menyediakan standar fungsi yang biasanya akan ditulis pada file-based application oleh programmer. Terdapat fungsi lain yang memperbolehkan programmer untuk berkonsentrasi pada fungsionalitas spesifik yang dibutuh oleh user tanpa harus mengkhawatirkan tentang rincian dari low-level. Sehingga dampak yang dihasilkan akan meningkatkan produktivitas programmer dan mengurangin waktu dari pengembangan (termasuk penghematan biaya) (Connolly dan Begg, 2010:79).
12. Improved maintenance through data independence
Deskripsi dari data dan logika untuk mengakses data antara setiap program aplikasi, menyebabkan program bergantung dengan data. DBMS memisahkan deskripsi data dari aplikasi, sehingga menyebabkan aplikasi kebal terhadap perubahan pada deskripsi data (Connolly dan Begg, 2010:79).
13. Increased concurrency
Dalam file-based systems, jika dua atau lebih pengguna diperbolehkan untuk mengakses file yang sama secara bersamaan, maka dapat mengakibatkan hilangnya informasi bahkan hilangnya integritas. DBMS mengatur konkurensi basis data dan memastikan bahwa masalah tersebut tidak akan terjadi lagi (Connolly dan Begg, 2010:79).
14. Improved backup and recovery services
Umumnya file-based systems menempatkan tanggung jawab kepada pengguna untuk mempersiapkan backup dan recovery data untuk melindungi data dari kegagalan sistem komputer maupun pogram aplikasi (Connolly dan Begg, 2010:80).
2.1.3.3 Kerugian DBMS
Connolly dan Begg (2010:80) menyatakan bahwa terdapat 7 kerugian dari penggunaan DBMS, antara lain:
1. Complexity
Ketentuan dari fungsionalitas dari DBMS yang baik, membuat DBMS mempunyai tingkat kompleksitas yang tinggi. Kegagalan dalam memahami sistem maka akan mengakibatkan kepada buruknya pengambilan keputusan terhadap rancangan yang ingin dibuat, yang akan mengakibatkan permasalahan yang besar dalam suatu organisasi (Connolly dan Begg, 2010:80).
2. Size
Tingkat kompleksitas yang tinggi dan luasnya fungsionalitas, DBMS membutuhkan tempat penyimpanan yang besar (Connolly dan Begg, 2010:80).
3. Cost of DBMS
Perbedaan biaya yang sangat besar untuk DBMS, tergantung pada lingkungan dan fungsionalitas yang disediakan (Connolly dan Begg, 2010:80).
4. Additional hardware costs
Kapasitas penyimpanan yang dibutuhkan DBMS dan basis data yang memungkinkan untuk tempat penyimpanan tambahan (Connolly dan Begg, 2010:80).
5. Cost of conversion
Biaya dari DBMS dan perangkat keras tambahan relativ lebih kecil bila dibandingkan dengan biaya konversi dari aplikasi yang telah ada untuk menjalankan DBMS dan perangkat keras yang baru (Connolly dan Begg, 2010:81).
6. Performance
DBMS digunakan secara kebih umum, untuk melayani lebih dari 1 aplikasi. Sehingga dapat mengakibatkan beberapa aplikasi tidak berjalan dengan cepat seperti biasanya (Connolly dan Begg, 2010:81).
7. Greater impact of a failure
Sentralisasi dari sumber daya meningkatkan kerentanan terhadap sistem. Karena semua pengguna dan aplikasi bergantung kepada DBMS (Connolly dan Begg, 2010:81).
2.1.3.4 Fungsi DBMS
Connolly dan Begg (2010:99), menyatakan bahwa terdapat 10 kegunaan yang harus dimiliki oleh DBMS berskala penuh, yaitu:
1. Data Storage, retrieval, and update
Sebuah DBMS harus memberikan user kemampuan untuk menyimpan, menerima, dan memperbaru data yang ada dalam suatu basis data (Connolly dan Begg, 2010:100).
2. A user-accessible catalog
Sebuah DBMS harus menyediakan catalog untuk mendeskripsikan data items yang tersimpan yang dapat
diakses oleh user (Connolly dan Begg, 2010:100). Biasanya, sistem katalog memuat:
a. Nama, tipe, dan ukuran dari data items. b. Nama dari sebuah hubungan.
c. Integritas constraint pada data.
d. Nama dari user yang memiliki otorisasi untuk mengakses data.
e. Data items yang bisa diakses setiap user dan tipe akses yang diperbolehkan (insert, update, delete). f. Skema eksternal, conceptual, dan internal serta
pemetaan antarskema.
g. Penggunaan statistik, seperti frekuensi seringnya melakukan transaksi dan jumlah dari akses yang pernah dilakukan pada objek yang ada dalam basis data.
Sistem katalog DBMS merupakan komponen dasar dari sebuah sistem. Kebanyakan komponen perangkat lunak sangat bergantung pada sistem katalog untuk mencari informasi. Berikut merupakan beberapa kelebihan dari sistem katalog, antara lain:
a. Informasi dari data dapat dikumpulkan dan dapat disimpan secara terpusat. Hal ini dapat membantu untuk mengontrol data sebagai sumber.
b. Data tersebut dapat didefinisikan, sehingga akan membantu user lain dalam memahami tujuan dari data tersebut.
c. Komunikasi dimudahkan, karena informasi yang telah disimpan. Sistem katalog juga dapat mengidentifikasi user yang memiliki data atau sedang mengakses data.
d. Redundansi dan data yang tidak konsisten akan lebih mudah diidentifikasi, karena data disimpan secara terpusat.
e. Perubahan yang terjadi dalam basis data dapat direkam.
f. Dampak dari perubahan bisa ditentukan sebelum dimplementasikan, karena sistem katalog menyimpan setiap data item, semua hubungan, dan semua user.
g. Keamanan dapat ditingkatkan. h. Integritas dapat dipastikan. i. Informasi audit dapat disediakan.
3. Transaction support
Sebuah DBMS harus menyediakan mekanisme yang dapat memastikan semua pembaruan berjalan berdasarkan transaksi yang ada (Connolly dan Begg, 2010:101).
4. Concurrency control services
Sebuah DBMS harus menyediakan mekanisme untuk memastikan bahwa basis data telah diperbarui dengan benar ketika berbagai user sedang memperbarui basis data secara bersamaan (Connolly dan Begg, 2010:101).
5. Recovery services
Sebuah DBMS harus menyediakan mekanisme untuk pemulihan basis data dimana terdapat kejadian yang membuat basis data rusak (Connolly dan Begg, 2010:102).
6. Authorization services
Sebuah DBMS harus menyediakan mekanisme untuk memastikan bahwa hanya user yang memiliki otorisasi yang dapat mengakses basis data (Connolly dan Begg, 2010:102).
Sebuah DBMS harus dapat saling berintegrasi dengan perangkat lunak komunikasi (Connolly dan Begg, 2010:103).
8. Integrity services
Sebuah DBMS harus menyediakan sarana agar semua data dan perubahan yang terjadi dalam basis data mengikuti aturan tertentu (Connolly dan Begg, 2010:103).
9. Services to promote data independence
Sebuah DBMS harus mencakup fasilitas yang mendukung independence programs dari struktur basis data aktual (Connolly dan Begg, 2010:103).
10. Utility services
Connolly dan Begg (2010:100) menyatakan bahwa sebuah DBMS harus menyediakan sekumpulan utility services, yaitu:
a. Fasilitas impor, untuk memuat basis data dari flat files, dan fasilitas expor, untuk membongkar data pada flat files.
b. Fasilitas memonitori, untuk memonitori penggunaan dan pengoperasian basis data. c. Program analisis statistik, untuk memeriksa kinerja
atau statistik penggunaan.
d. Fasilitas index reorganization, untuk merombak index dan overflows.
e. Garbage collection dan reallocation, digunakan untuk menghapus record fisik dari tempat penyimpanan, mengkonsolidasikan space released, dan untuk alokasi kembali ketika dibutuhkan.
2.1.4 Database Language
Connolly dan Begg (2010:91) menyatakan bahwa database language memiliki dua bahasa didalamnya yaitu: bahasa definisi (Data Definition Language) dan bahasa manipulasi (Data Manipulation Language). Dua bahasa ini disebut sebagai bagian dari database language dikarenakan, mereka tidak mengikutsertakan suatu konstruktor untuk segala kebutuhan, seperti suatu kondisi atau kalimat berulang, yang biasa disediakan oleh programing tingkat tinggi (High Level Programming).
Banyak DBMS (Database Manipulation System) yang memfasilitasi dua bahasa ini dengan bahasa tingkat tinggi seperti C , C++ ,C#, Java, atau Visual Basic, dalam hal ini bahasa tingkat tinggi dapat dianggap sebagai inti bahasa (Host Language Program). Untuk membuat suatu file yang spesifik, perintah dari bagian bahasa ini dihapus dari bahasa inti yang kemudian diubah manjadi suatu fungsi panggil (Connolly dan Begg, 2010:91).
Proses sebelumnya kemudian di jalankan, disimpan di object module, disambungkan ke DBMS library yang mengandung fungsi panggil, dan menjalankan sesuai perintah. Banyak dari bagian bahasa database ini yang menyediakan input data yang tidak spesifik (nonembedded) dan perintah secara langsung dari terminal (Connolly dan Begg, 2010:91).
2.1.4.1 Database Definition Language (DDL)
Connoly dan Begg (2010:92) menyatakan bahwa data definition language adalah suatu bahasa yang memperbolehkan user untuk mendeskripsikan dan menamai suatu entitas, tabel, atribut , dan relationship yang dibutuhkan aplikasi. Contoh perintah dalam DDL antara lain:
1. Create table
Create table berfungsi untuk membuat tabel di dalam basis data.
Drop table berfungsi untuk menghapus tabel di dalam basis data.
3. Alter table
Alter table berfungsi untuk mengubah tabel, entitas dan, atribut yang sudah terbentuk.
2.1.4.2 Database Manipulation Language (DML)
Connoly dan Begg (2010:92) menyatakan bahwa data manipulation language adalah bahasa yang menyediakan operasi yang akan membantu dalam memanipulasi data di dalam basis data. Contoh perintah dalam DML antara lain:
1. Select
Select berfungsi untuk mengambil data yang di inginkan sesuai dengan syarat yang di inginkan.
2. Insert
Insert berfungsi untuk memasukkan data ke dalam tabel di basis data.
3. Update
Update berfungsi untuk mengubah data dalam table yang telah terlanjur di isi di dalam basis data.
4. Delete
Delete berfungsi untuk menghapus satu kolom atau lebih data pada tabel.
2.1.5 Database System Development Lifecycle (DSDLC)
Sebagai sebuah sistem, basis data merupakan komponen mendasar untuk organisasi - organisasi besar berbasis sistem informasi, DSDLC menjelaskan asosiasi dengan lifecycle dari sistem informasi tersebut (Connolly dan Begg, 2010:313). Berikut tahap - tahap dalam database system development lifecycle:
Gambar 2.2
Tahap Database System Development Lifecycle (Connolly dan Begg, 2010:313)
1. Database Planning
Aktivitas manajemen yang memungkinkan tahap dari DSDLC menjadi lebih efektif dan efisien. Database planning harus terintegrasi dengan sistem informasi yang umum pada suatu organisasi (Connolly dan Begg, 2010:313).
2. System Definition
Menjelaskan ruang lingkup dan batasan dari sistem basis data, dan menggambarkan kebutuhkan user secara umum (Connolly dan Begg, 2010:316).
3. Requirement Collection and Analysis
Proses mengumpulkan dan menganalisa informasi tentang bagian dari organisasi yang akan didukung oleh sistem basis data, dan menggunakan informasi ini untuk mengidentifikasi kebutuhan untuk sistem yang baru (Connolly dan Begg, 2010:316). Berikut 3 pendekatan untuk mencari kebutuhan dari sistem basis data dengan berbagai user:
a) The centralized approach
Kebutuhan dari setiap user digabungkan menjadi sebuah satu kesatuan untuk sistem basis data yang baru. Kemudian model data representasi dari semua user akan dibuat selama tahap perancangan basis data (Connolly dan Begg, 2010:318).
4. Database design
Proses pembuatan rancangan yang akan mendukung tujuan dari perusahaan dan tujuan dari pembuatan sistem basis data (Connolly dan Begg, 2010:320). Terdapat berbagai pendekatan yang dapat digunakan dalam perancangan basis data, yaitu:
a) Bottom-up
Pendekatan ini diawali dengan atribut - atribut dasar, yaitu sifat dan hubungan dari entitas tersebut. Kemudian dilanjutkan dengan analisis antara grup - grup atribut menjadi suatu hubungan yang menggambarkan tipe dari entitas dan hubungan antarentitas (Connolly dan Begg, 2010:321).
Terdapat 3 tahap utama dalam perancangan basis data, yaitu:
1) Perancangan basis data konseptual
Suatu proses pembuatan model data yang digunakan dalam perusahaan yang independen dari keseluruhan aspek fisik (Connolly dan Begg, 2010:467). Berikut langkah - langkah dari metodologi perancangan basis data konseptual, antara lain:
1. Identifikasi tipe entitas
Langkah pertama untuk membuat sebuah model data konseptual yaitu dengan menentukan dan mendefinisikan objek utama dimana user terlibat di dalamnya. Objek - objek ini adalah model dari tipe entitas (Connolly dan Begg, 2010:471).
Tipe entitas adalah suatu grup objek dengan properti yang sama, yang diidentifikasi oleh perusahaan karena keberadaannya yang independen (Connolly dan Begg, 2010:372). Tipe entitas dapat dibagi menjadi dua, yaitu:
a) Strong entity type
Tipe entitas yang keberadaannya tidak bergantung pada entitas lainnya (Connolly dan Begg, 2010:383).
b) Weak entity type
Tipe entitas yang keberadaannya bergantung pada entitas lainnya (Connolly dan Begg, 2010:383).
Gambar 2.3 Strong Entity dan Weak Entity (Connolly dan Begg, 2010:384)
2. Identifkasi tipe relationship
Tujuan dari langkah ini adalah untuk mengidentifikasi hubungan penting yang ada antara tiap entitas yang sudah diidentifikasi (Connolly dan Begg, 2010:472). Tipe relationship adalah suatu asosiasi antara satu atau lebih entitas yang berpatisipasi (Connolly dan Begg, 2010:374). Tipe relationship :
a) Binary relationship
Hubungan antar dua tipe entitas.
Gambar 2.4 Binary Relationship (Connolly dan Begg, 2010:376)
Multiplicity adalah suatu batasan antara tipe entitas yang saling berhubungan (Connolly dan Begg, 2010:385). Multiplicity dapat dibagi menjadi dua constraint, yaitu:
a) Cardinality
Mendeskripsikan maksimum jumlah batasan dari sebuah entitas yang berpatisipasi dalam relasi (Connolly dan Begg, 2010:390).
b) Participation
Menentukan apakah semua atau hanya beberapa entitas yang ikut berpatisipasi dalam relasi (Connoly and Begg, 2010:391).
Gambar 2.7 Cardinality and Participation (Connolly dan Begg, 2010:391)
3. Identifikasi dan asosiasi atribut dengan tipe entitas atau relationship.
Tujuan dari langkah ini adalah untuk mengasosiasikan atribut dengan tipe entitas dan relationship yang sesuai (Connolly dan Begg, 2010:474).
Atribut adalah suatu properti dari tipe entitas atau relationship (Connolly dan Begg, 2010:379). Berikut adalah macam – macam atribut, antara lain:
a) Attribute domain
Sekumpulan nilai yang diperbolehkan dalam satu atribut atau lebih (Connolly dan Begg, 2010:379).
b) Simple attribute
Atribut yang yang tersusun dari komponen - komponen tunggal yang keberadaannya independen (Connolly dan Begg, 2010:379).
c) Composite attribute
Atribut yang tersusun dari komponen - komponen ganda yang masing – masingnya memiliki keberadaan yang independen (Connolly dan Begg, 2010:380).
d) Single-valued attribute
Atribut yang mempunyai nilai tunggal untuk setiap kejadian pada sebuah tipe entitas (Connolly dan Begg, 2010:380).
e) Multi-valued attribute
Atribut yang mempunyai nilai ganda untuk setiap kejadian pada sebuah tipe entitas (Connolly dan Begg, 2010:380).
f) Derived attribute
Atribut yang mewakili nilai yang dapat diturunkan dari nilai pada atribut yang berhubungan atau suatu kumpulan atribut, tetapi tidak harus berasal dari tipe entitas yang sama (Connolly dan Begg, 2010:380).
4. Menentukan domain atribut
Langkah ini bertujuan untuk menentukan domain untuk atribut yang berada pada model data konseptual lokal (Connolly dan Begg, 2010:478).
5. Menentukan candidate dan primary key
Langkah ini bertujuan untuk menentukan candidate key untuk setiap tipe entitas, dan jika terdapat lebih dari satu candidate key, maka akan dipilih salah satu untuk menjadi primary key (Connolly dan Begg, 2010:479). Ada beberapa macam keys, antara lain:
a) Candidate key
Sejumlah kecil atribut yang secara unik mengidentifikasi setiap kejadian dari tipe entitas (Connolly dan Begg, 2010:381).
b) Primary key
Candidate key yang dipilih untu
mendefinisikan secara unik setiap kejadian pada tipe entitas (Connolly dan Begg, 2010:381).
c) Composite key
Candidate key yang terdiri dari dua atribut atau lebih (Connolly dan Begg, 2010:382).
d) Foreign key
Himpunan atribut dalam suatu relationship yang cocok dengan candidate key dari beberapa relationship lainya (Indrajani, 2011:42). e) Alternate key
Candidate key yang tidak terpilih menjadi primary key, atau bisa disebut juga secondary key (Indrajani, 2011:42).
6. Mempertimbangkan pengunaan enhanced modelling concepts (optional step)
Langkah ini bertujuan untuk mempertimbangkan penggunaan enhanced modeling concepts, seperti specialization, generalization, aggregation, and composition (Connolly dan Begg, 2010:480).
7. Periksa model untuk redundansi
Langkah ini bertujuan untuk melakukan pemeriksaan terhadap adanya redundansi pada model. Pada langkah ini, dilakukan proses identifikasi pada model data konseptual dengan objektif yang spesifik apakah terdapat redundansi atau tidak (Connolly dan Begg, 2010:482).
8. Memvalidasi model data konseptual terhadap transaksi user
Langkah ini bertujuan untuk memastikan bahwa model konseptual lokal tersebut mendukung transaksi yang dibutuhkan berdasarkan kemauan operasional perusahaan (Connolly dan Begg, 2010:483). Berikut adalah dua kemungkinan pendekatan untuk memastikan bahwa model data konseptual lokal mendukung transaksi yang dibutuhkan, antara lain:
a) Mendeskripsikan transaksi
Dengan menggunakan pendekatan pertama, maka akan dilakukan pemeriksaan terhadap semua informasi (entitas, relationship, atribut) yang dibutuhkan oleh setiap transaksi yang
disediakan oleh model, dengan mendokumentasikan deskripsi dari setiap transaksi yang dibutuhkan (Connolly dan Begg, 2010:484).
b) Menggunakan jalur transaksi
Pendekatan kedua digunakan untuk memvalidasi model data terhadap transaksi yang dibutuhkan termasuk diagram yang mewakili jalur yang diambil oleh setiap transaksi dalam diagram ER (Connolly dan Begg, 2010:484).
9. Mengevaluasi model data konseptual local dengan user Langkah ini bertujuan untuk mengevaluasi kembali model data konsepual local dengan user untuk memastikan bahwa model merupakan representasi dari kemauan perusahaan yang sebenarnya (Connolly dan Begg, 2010:485).
Gambar 2.8 Model Data Konseptual (Connolly dan Begg, 2010:491)
2) Perancangan basis data logikal
Perancangan basis data logikal merupakan proses pembuatan model data yang digunakan dalam perusahaan berdasarkan model data spesifik, tetapi tidak bergantung pada DBMS dan pertimbangan fisik lainnya (Connolly dan Begg, 2010:467). Berikut tahap - tahap dalam perancangan basis data logikal, antara lain:
1. Menurunkan relasi untuk model data logikal
Tujuan dari langkah ini adalah untuk membuat relasi pada model data logika yang akan mewakili entitas, relationship¸ dan atribut yang telah diidentifikasi (Connolly dan Begg, 2010:492).
Cara untuk menurunkan relasi pada model data logikal, yaitu: strong entity type, weak entity type, one-to-many
(1:*) binary relationship types, one-to-one (1:1) binary relationship types, one-to-one (1:1) recursive relationship types, superclass / subclass relationship types, many-to-many (*:*) relationship types, complex relationship types, dan multi-valued attributes.
2. Memvalidasi relasi dengan menggunakan normalisasi Tujuan dari langkah ini adalah untuk memvalidasi relasi dalam model data logikal dengan menggunakan normalisasi melalui tahap UNF, 1NF, 2NF, dan 3NF. Normalisasi juga digunakan untuk memastikan relasi dan atribut yang mendukung kebutuhan perusahaan (Connolly dan Begg, 2010:501).
Normalisasi adalah sebuah teknik dalam pembuatan desain basis data yang dimulai dengan pengecekan hubungan (functional dependencies) antaratribut. Atribut - atribut itu sendiri mendeskripsikan sifat - sifat dari data itu sendiri atau hubungan antardata. Normalisasi menggunakan serangkaian tes yang biasanya disebut normal forms untuk membantu mengidentifikasi pengelompokan yang optimal untuk atribut-atribut tersebut yang pada akhirnya bertujuan mengidentifikasi sebuah set relasi yang tepat untuk mendukung kebutuhan data di perusahaan (Connolly dan Begg, 2010:415). Tujuan dari normalisasi yaitu:
a. Mengidentifikasi hubungan antaratribut. b. Mengkombinasikan atribut untuk membentuk
relasi.
c. mengkombinasikan relasi untuk membentuk basis data.
Berikut adalah tahap - tahap dari normalisasi, antara lain:
1. First normal form (1NF)
Unnormalized form (UNF) merupakan bentuk awal data yang belum ternormalisasi. Tabel - tabel yang masih memiliki satu atau lebih pengulangan (Connolly dan Begg, 2010:430).
First normal form merupakan suatu hubungan dimana persimpangan dari setiap baris dan kolom mengandung satu dan hanya satu nilai (Connolly dan Begg, 2010:430).
2. Second normal form (2NF)
Suatu hubungan dalam first normal form yang setiap non-primary-key atributnya bergantung pada primary key yang dependen (Connolly dan Begg, 2010:434).
3. Third normal form (3NF)
Suatu hubungan dalam first normal form dan second normal form dimana tidak ada non-primary-key atribut yang bergantung secara transitif dengan primary key (Connolly dan Begg, 2010:436).
3. Memvalidasi relasi terhadap transaksi user
Tujuan dari langkah ini adalah untuk memastikan bahwa relasi dalam model data logikal mendukung transaksi yang dibutuhkan. Tahap pemeriksaan ini sudah dilakukan pada tahap perancangan basis data konseptual, tetapi dilakukan kembali untuk
memastikan bahwa tidak terdapat error dalam pembuatan relasi (Connolly dan Begg, 2010:502).
4. Memeriksa integritas constraint
Tujuan dari langkah ini adalah untuk memeriksa integritas dari constraints yang direpresentasikan dalam model data logikal. Integritas constraint adalah batasan yang digunakan untuk melindungi basis data agar sempurna, akurat, dan konsisten (Connolly dan Begg, 2010: 502). Tipe integritas constraint, antara lain:
a) Required data
Data harus berisi nilai - nilai yang valid. Tidak boleh ada data yang kosong (Connolly dan Begg, 2010:502).
b) Attribute domain constraints
Setiap atribut sudah memiliki domainnya masing - masing, yaitu berupa suatu nilai yang legal. Contohnya untuk jenis kelamin dari setiap karyawan di tandai dengan "M" atau "F" sebagai domain dari atribut jenis kelaminnya (Connolly dan Begg, 2010:503).
c) Multiplicity
Multiplicity mewakili constraint yang ditempatkan antara data yang ada dalam basis data untuk memastikan bahwa semua integritas constraints telah diidentifikasi dan mewakili bagian penting dari model data suatu perusahaan (Connolly dan Begg, 2010:503).
d) Entity integrity
Primary key tidak boleh berisikan null. Constraint ini harus dipertimbangkan saat mengidentifikasi primary key untuk setiap tipe entitas pada perancangan basis data konseptual (Connolly dan Begg, 2010:503).
e) Refential integrity
Setiap foreign key yang memiliki nilai pada atributnya, harus menunjuk pada nilai relasi induknya (Connolly dan Begg, 2010:503).
f) General constraints
Aturan constraint secara umum. Contohnya batasan untuk mencegah setiap karyawan untuk memanage 100 properti dalam waktu yang sama (Connolly dan Begg, 2010:505).
5. Mengevaluasi kembali model data logikal dengan user Langkah ini bertujuan untuk memastikan bahwa model data logikal yang terbentuk merupakan representasi dari perusahaan (Connolly dan Begg, 2010:506).
6. Menggabungkan model data logikal ke dalam model global (optional step)
Tujuan dari langkah ini adalah untuk menggabungkan model data logikal menjadi sebuah data global logikal yang merepresentasikan semua kebutuhan user dalam basis data (Connolly dan Begg, 2010:506). Aktivitas dalam langkah ini, antara lain:
a. Menggabungkan model data logikal ke dalam model data global logikal.
c. Mengevaluasi kembali model data global logikal dengan user.
7. Memeriksa perkembangan di masa depan
Langkah ini bertujuan untuk menentukan apakah terdapat perubahan yang signifikan di masa depan dan apakah model data logikal tersebut dapat mengakomodasi perubahan itu (Connolly dan Begg, 2010:517).
Gambar 2.9 Global Relation Diagram (Connolly dan Begg, 2010:516)
3) Perancangan basis data fisikal
Perancangan basis data fisikal adalah suatu proses pembuatan deskripsi dari implementasi basis data pada secondary storage, yang mendeskripsikan relasi dasar, organisasi file, dan indeks yang digunakan untuk mencapai akses data yang efisien, integritas constraints yang saling terkait, dan keamanan (Connolly dan Begg, 2010:467).
1. Menerjemahkan model data logikal untuk DBMS yang dipilih
Tujuan dari langkah ini adalah untuk membuat skema relasi pada basis data dari model data logikal yang dapat diimplementasikan dalam DBMS yang dipilih. Bagian pertama dari proses ini adalah menyatukan informasi yang telah dikumpulkan saat perancangan basis data logikal dan didokumentasikan dalam kamus data, bersamaan dengan informasi yang dikumpulkan selama proses pengumpulan dan analisis kebutuhan yang didokumentasikan dalam spesifikasi sistem. Bagian kedua dari proses ini adalah menggunakan informasi ini untuk membuat rancangan dari relasi dasar. Proses ini memerlukan pengetahuan lebih dalam tentang fungsionalitas yang ditawarkan oleh DBMS yang telah dipilih (Connolly dan Begg, 2010:524). Berikut tiga aktivitas dalam tahap ini, antara lain:
a) Merancang relasi dasar
Bertujuan untuk menentukan bagaimana cara untuk merepresentasikan relasi yang telah diidentifikasi dalam model data logikal menggunakan DBMS yang telah dipilih (Conolly and Begg, 2010:525).
b) Merancang representasi dari derived data Bertujuan untuk menentukan bagaimana cara untuk merepresentasikan derived data yang terdapat pada model data logikal menggunakan DBMS yang telah dipilih (Connolly dan Begg, 2010:526).
c) Merancang general constraints
Bertujuan untuk merancang general constraints pada DBMS yang telah dipilih agar perubahan yang terjadi dalam data dapat dibatasi dalam dunia nyata. Penentuan constraint ini tergantung akan DBMS yang dipilih, beberapa sistem menyediakan fasilitas untuk mendefinisikan constraint, tetapi ada juga yang tidak ada, sehingga proses perancangan constraint harus dilakukan dalam program aplikasi (Connolly dan Begg, 2010:528).
2. Merancang organisasi file dan indeks
Langkah ini bertujuan untuk menentukan organisasi file yang optimal untuk menyimpan relasi dasar dan indeks yang dibutuhkan untuk mencapai kinerja yang baik, yaitu dengan cara relasi dan atribut disimpan di secondary storage (Connolly dan Begg, 2010:528). Berikut empat tahap dalam aktivitas ini, antara lain:
a. Menganalisa transaksi
Bertujuan untuk mengetahui fungsionalitas dari transaksi yang berjalan pada basis data dan untuk menganalisa transaksi yang penting (Connolly dan Begg, 2010:529).
b. Memilih organisasi file
Bertujuan untuk menentukan organisasi file yang efisien untuk setiap relasi dasar. Berikut lima tipe organisasi file, yaitu heap, hash, index sequential access method (ISAM), b-tree, clusters (Connolly dan Begg, 2010:534).
c. Memilih indeks
Bertujuan untuk menentukan apakah dengan melakukan penambahan indeks akan meningkatkan kinerja dari sistem (Connolly dan Begg, 2010:535).
d. Memperkirakan tempat penyimpanan yang dibutuhkan
Bertujuan untuk memperkirakan tempat penyimpanan yang akan dibutuhkan untuk mendukung implementasi basis data pada secondary storage (Connoly and Begg, 2010:542).
3. Merancang tampilan user
Bertujuan untuk merancang tampilan untuk user yang telah diidentifikasi selama proses pengumpulan dan analisis kebutuhan pada tahap database system development lifecycle (Connolly dan Begg, 2010:542).
4. Merancang mekanisme keamanan
Bertujuan untuk merancang mekanisme keamanan untuk basis data berdasarkan spesifikasi dari user saat proses pengumpulan dan analisis kebutuhan pada tahap database system development lifecycle (Connolly dan Begg, 2010:542).
Gambar 2.10 Model Data Fisikal (Connolly dan Begg, 2010:526)
2.1.6 Data Flow Diagram (DFD)
Suatu proses model yang menggambarkan alur data melalui sistem dan kerja atau pemrosesan yang dilakukan oleh sistem (Whitten dan Bentley, 2007:317).
Gambar 2.11 Simple Data Flow Diagram (Whitten dan Bentley, 2007:318).
Terdapat tiga simbol dalam DFD, antara lain:
a. Bentuk kotak yang mewakili bentuk external agents merupakan batasan ruang lingkup dari sebuah sistem, bisa berupa orang luar, unit, sistem atau organisasi yang berinteraksi dengan sebuah sistem yang bisa disebut external entity.
b. Bentuk kotak open-ended yang mewakili bentuk data stores, yang terkadang disebut juga file atau databases. Data Store digunakan untuk menyimpan data yang akan digunakan nantinya.
c. Bentuk kotak bertepi bulat yang mewakili suatu proses atau pekerjaan yang harus dilakukan. Proses adalah suatu kegiatan yang dilakukan oleh sistem dalam merespon alur data yang datang atau suatu kondisi.
Context data flow diagram adalah sebuah model proses yang digunakan untuk mendokumentasikan lingkup dari sistem yang biasanya disebut environtment system (Whitten dan Bentley, 2007:339).
Gambar 2.12 Context Data Flow Diagram (Whitten dan Bentley, 2007:340).
System diagram adalah diagram yang menunjukkan semua kejadian pada sistem yang terdapat pada single diagram. Single diagram merupakan pecahan dari single process yang terdapat pada context diagram (Whitten dan Bentley, 2007:348).
Gambar 2.13 System Diagram (Whitten dan Bentley, 2007:350-351).
2.1.7 Visual Basic
Merupakan bahasa pemograman lanjutan dari BASIC, dikembangkan pada 1960 di Dartmouth College untuk memperkenalkan pemula kepada dasar teknik pemograman (Deitel Brothers, 2014:45-46).
Event Driven Programming adalah suatu basis pemograman yang memberi tanggapan setiap kejadian yang dilakukan user, seperti mouse click atau keystrokes serta gesture (Deitel Brothers, 2014:46).
2.1.8 8 Golden Rules
Dalam perancangan user interface harus memperhatikan 8 aturan yang dirangkum dalam 8 Golden Rules (Shneiderman & Plaisant, 2010:88), yaitu:
1) Berusaha untuk konsisten
Konsistensi dari urutan perintah, tindakan, dan istilah yang digunakan pada prompt, menu, serta layar bantuan harus diperhatikan agar user tidak kesulitan dalam mencari sebuah informasi.
2) Memungkinkan pembalikan aksi yang mudah
User dapat kembali ke halaman atau langkah sebelumnya jika terdapat kesalahan, sehingga user tidak merasa takut jika berada dalam halaman yang salah.
3) Memberikan umpan balik yang informatif
Memberikan informasi terhadap aksi yang dilakukan oleh user agar user dapat terarah dan tidak tersesat dalam mencari informasi.
4) Merancang dialog yang memberikan penutupan.
Urutan aksi yang harus terorganisasi dan memiliki bagian awal, tengah, dan akhir. User harus tahu kapan aksi tersebut akan berakhir. Umpan balik yang informatif setelah sekumpulan aksi dilakukan akan memberikan kepuasan kepada user dan juga sebagai tanda bahwa user dapat melakukan aksi selanjutnya.
5) Menyediakan penanganan eror yang mudah
Sebuah sistem harus dapat membuat user untuk terhindar dari kesalahan sistem atau tidak membuat error yang serius, dan jika terjadi error, maka sistem harus dapat mendeteksi error tersebut dan memberikan mekanisme yang sederhana dan mudah dipahami kepada user untuk menangani eror tersebut.
6) Mendukung pusat kendali internal
Membuat sistem sehingga user bisa mengendalikannya, bukan hanya komputer tapi lebih ke arah user dalam mengendalikan sistem tersebut. Kepuasan user akan lebih tinggi jika user merasa bahwa user telah memegang kendali, sedangkan kepuasan user akan rendah jika komputer yang lebih memegang kendali.
7) Universal Usability
Maksud dari hal ini adalah agar pembuat suatu aplikasi dapat mengenali kebutuhan user yang beraneka ragam, sehingga dapat ditambahkan fitur untuk pemula dan penjelasan dari fungsi yang ada
pada aplikasi tersebut, serta fitur untuk para ahli seperti shortcut dan aksi timbal balik yang cepat dan informatif, sehingga dapat memperkaya desain dari user interface dan meningkatkan kuatlitas dari aplikasi tersebut.
8) Mengurangi beban ingatan jangka pendek
Membuat user interface sesederhana mungkin, sehingga user dapat dengan mudah dan paham dengan alur dari aplikasi tersebut serta tidak banyak mengingat berbagai perintah yang dapat membingungkan user.
2.1.9 5 Faktor Manusia Terukur
Shneiderman & Plaisant (2010:32-33) menyatakan, bahwa terdapat lima faktor manusia terukur untuk menguji suatu aplikasi, yaitu:
1. Waktu Untuk Belajar
Ukuran berapa lama seorang user untuk mempelajari fungsi - fungsi di dalam sebuah aplikasi hingga akhirnya user dapat menggunakannya dengan baik.
2. Kecepatan Performa
Ukuran berapa lama suatu fungsi yang terdapat di dalam aplikasi tersebut selesai dilakukan.
3. Tingkat Kesalahan yang Dilakukan Pengguna
Ukuran untuk berapa banyak user melakukan kesalahan saat menjalankan aplikasi tersebut.
4. Daya Ingat Pengguna
Ukuran berapa lama user dapat mengingat serangkaian proses yang terdapat aplikasi tersebut setelah beberapa jam, hari atau minggu.
5. Kepuasan Subjektif
Ukuran seberapa lama puas user atas berbagai aspek dari suatu aplikasi.
2.2 Teori Khusus
2.2.1 Teori Penjualan
Mulyadi (2007:128) menyatakan bahwa penjualan adalah suatu kegiatan yang terdiri dari transaksi penjualan barang atau jasa, secara kredit maupun tunai.
Dari pengertian di atas dapat disimpulkan bahwa penjualan adalah suatu kegiatan yang dilakukan dalam memperoleh pendapatan baik untuk perusahaan besar maupun kecil. Pada tahap ini terjadi penetapan harga melalui perundingan antara kedua belah pihak sehingga tercipta suatu kepuasan antara kedua belah pihak.
2.2.2 Teori Pembelian
Render (2011:414) menyatakan bahwa, pembelian adalah perolehan barang dan jasa. Secara umum definisi pembelian adalah suatu usaha pengadaan barang atau jasa dengan tujuan yang akan digunakan sendiri, untuk kepentingan proses produksi maupun untuk dijual kembali.
2.3 Hasil Penelitian atau Projek Sebelumnya
Penjelasan mengenai beberapa penelitian terdahulu mengenai aplikasi sejenis yang terdapat dalam bab satu akan dijelaskan sebagai berikut:
1. Melisa, Feliks Prawira Lesmana, Eric (2014)
Penelitian ini berjudul “DATABASE PENJUALAN, PEMBELIAN DAN PENAGIHAN BERBASIS WEB DI PT. SAKURA SYSTEM SOLUTIONS”. Peneliti menggunakan metodologi perancangan basis data yang terdiri dari proses konseptual, logikal, dan fisikal. Tools
yang digunakan untuk perancangan aplikasi web yaitu PHP, javascript, Adobe Dreamweaver CS3 untuk merancang aplikasi serta MySQL untuk perancangan basis data. Dengan diterapkannya sistem ini, peneliti mengharapkan perancangan sistem penjualan dan pembelian yang dapat mendukung kebutuhan informasi yang diperoleh pada saat menganalisa kebutuhan.
2. Rachma Yunita, Mario Aditya Purwasunu, Marchoyono (2014) Penelitian ini berjudul “ DATABASE DESIGN PENJUALAN, PEMBELIAN DAN PERSEDIAAN PT. LUCKY ABADI”. Peneliti menggunakan metodologi perancangan basis data yang terdiri dari proses konseptual, logikal, dan fisikal. Tools yang digunakan untuk perancangan aplikasi web yaitu PHP, javascript, Adobe Dreamweaver CS3 untuk merancang aplikasi serta MySQL untuk perancangan basis data. Diharapkan aplikasi dapat menjalankan operasional perusahaan dalam penjualan dan persediaan barang serta membantu menyelesaikan permasalahan yang ada.
3. Lutfhi Muhammad Heykel, Boris Utomo, Aulia Rahman (2013) Penelitian ini berjudul “ANALISIS DAN PERANCANGAN APLIKASI DATABASE PENJUALAN BERBASIS WEB PADA PT. SARINAH”. Peneliti menggunakan metode database application lifecycle yang berorientasi pada aturan linear sequential (waterfall). Tools yang digunakan yaitu MySQL, Adobe Dreamweaver CS3, Adobe Photoshop CS3. Dengan diterapkannya sistem ini, peneliti mengharapkan perancangan web-aplikasi ini dapat mempermudah proses kerja dan mengurangi munculnya kesalahan sehingga dapat meningkatkan proses kerja.
4. Hari Krishna Mahat (2013)
Penelitian ini berjudul “DESIGNING A LOGICAL DATA MODEL FOR SALES AND INVENTORY MANAGEMENT SYSTEM”. Bertujuan untuk mendesain logical data model untuk sistem penjualan dan inventaris. Diharapkan perancangan ini dapat memenuhi
keinginan perusahaan untuk efisiensi dalam penggunaan teknologi serta mampu menjaga dan menghasilkan data yang digunakan dari staff bagian gudang dan penjualan.
