BAB 2 LANDASAN TEORI
2.1
Teori Dasar Sistem Basis Data
2.1.1
Data Menurut Everest (1986, p3), data adalah “fakta” yang dipresentasikan dengan nilai berupa angka, karakter string, atau symbol yang memiliki arti dalam beberapa konteks. Menurut Turban (2005, p38), data merupakan kumpulan fakta atau deskripsi dasar dari sesuatu, kejadian, aktifitas, dan transaksi, yang diambil, dicatat, disimpan dan dikelompokkan, tetapi tidak diatur untuk menyatakan suatu arti tertentu. Menurut Whitten (2004, p27, p553), data adalah fakta mentah mengenai orang, tempat, kejadian, dan apapun yang penting bagi perusahaan. Dimana setiap fakta sebenarnya, jika berdiri sendiri, relatif tidak memiliki arti. Data merupakan sebuah sumber daya yang harus dikendalikan dan dikelola. Jadi, dapat disimpulkan bahwa data adalah fakta yang dipresentasikan dengan nilai mengenai sesuatu, kejadian, aktifitas, dan transaksi yang perlu dikontrol dan dikelola sehingga dapat berguna bagi suatu pihak/organisasi.
7
8
2.1.2
Basis Data Menurut Turban (2005, p37), basis data merupakan kumpulan file, tabel, relations, dan lain-lain yang saling berhubungan, yang menyimpan data dan asosiasi-asosiasi diantaranya. Menurut Whitten (2004, p548), basis data adalah koleksi dari file yang saling berhubungan. Menurut Connolly dan Begg (2005, p15), basis data adalah sekumpulan data yang saling berhubungan dimana dirancang untuk mencapai informasi yang diperlukan dalam suatu organisasi. Artinya basis data adalah tempat penyimpanan data yang besar dimana bisa digunakan secara simultan atau secara bersamaan oleh banyak departemen dan pemakai lainnya (user). Di dalam basis data semua item data diintegrasikan untuk menghindarkan duplikasi data (redudancy). Basis data tidak hanya mengandung data operasional organisasi, tetapi juga deskripsi dari data tersebut (meta-data). Sehingga dapat disimpulkan bahwa basis data merupakan suatu kumpulan data yang saling berhubungan antara satu dengan yang lainnya, yang dapat digunakan secara simultan atau secara bersamaan oleh banyak user, dan item data pada basis data diintegrasikan untuk menghindarkan duplikasi data.
2.1.2.1 Karakteristik Basis Data Menurut Mannino (2004, p4), basis data memiliki beberapa karakteristik, yaitu :
9
a) Persistent, artinya data berada pada tempat penyimpanan yang stabil seperti pada magnetic disk. Variabel pada computer tidak bersifat persistent karena berada pada memori utama dan akan menghilang seiring ditutupnya program. Persistent juga bukan berarti data akan selamanya ada. Ketika data sudah tidak lagi relevan maka data tersebut akan dibuang atau diarsipkan. b) Shared, artinya basis data dapat mempunyai banyak kegunaan dan banyak user. Basis data menyediakan memori yang umum untuk beragam fungsi dalam suatu organisasi. Kecuali jika dua users mencoba untuk merubah suatu bagian yang sama pada basis data pada saat yang bersamaan, mereka dapat langsung melakukannya tanpa harus menunggu yang lain. c) Interrelated, artinya data tersimpan dalam unit yang terpisah-pisah, tapi dapat dihubungkan untuk menyediakan data yang dibutuhkan.
2.1.3
Sistem Basis Data Menurut Date (2000, p5), pada dasarnya sistem basis data adalah sistem penyimpanan yang telah terkomputerisasi yang secara keseluruhan bertujuan untuk menyimpan informasi dan memungkinkan penggunanya mengambil dan mengubah informasi tersebut pada saat yang dibutuhkan. Komponen-komponen penting dalam sistem basis data yaitu :
10
1. Data Data dalam basis data dapat merupakan data yang single user (hanya satu pengguna yang beroperasi pada basis data) atau multi user, dimana satu atau lebih user beroperasi secara bersama-sama ke dalam basis data. Sehingga data dalam basis data terutama untuk sistem yang besar, harus terintegrasi dan dapat dipakai secara bersamaan. 2. Perangkat Keras (Hardware) Untuk manajemen basis data hanya dibutuhkan mesin standard, namun yang harus diperhatikan adalah kapasitas penyimpanan karena basis data akan membutuhkan kapasitas yang besar. 3. Perangkat Lunak (Software) Piranti lunak untuk sistem basis data disebut DBMS (Database Management System). 4. Pengguna (User) Pengguna yang terlibat dalam komponen DBMS yaitu : a) Database Administrator Bertanggung jawab untuk mengatur manajemen sumber daya data yang meliputi perencanaan basis data, pengembangan dan pemeliharaan standardnya, aturan dan prosedur, dan rancangan basis data konseptual atau logikal. b) Programmer Programmer adalah seseorang atau sekelompok orang yang menjadi
tenaga
ahli
komputer
yang
berfungsi
untuk
11
mengembangkan program-program aplikasi yang diperlukan dalam DBMS. c) End-user (Pengguna Akhir) Yang termasuk dalam kategori pengguna akhir adalah pemilik sistem, para manajer, operator dan sebagainya yang terlibat langsung dalam penggunaan sistem basis data.
2.2
Database Management System (DBMS) Definisi Database Management System (DBMS) menurut Whitten (2004, p554) adalah perangkat lunak khusus yang digunakan untuk membuat, mengakses, mengendalikan, dan mengelola sebuah basis data. Menurut Connolly dan Begg (2005, p16), Database Management System (DBMS) adalah sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, me-maintain, dan mengontrol akses ke basis data. Fasilitas-fasilitas yang pada umumnya disediakan oleh DBMS adalah sebagai berikut (Connolly dan Begg, 2005, p16-17) : a) Pendefinisian basis data menggunakan Data Definition Language (DDL). b) Insert, update, delete dan mengambil data dari basis data yang biasanya menggunakan Data Manipulation Language (DML). c) Penyediaan akses yang terkontrol ke basis data seperti :
12
•
Sistem keamanan (security system), mencegah pengguna yang tidak berhak mengakses basis data.
•
Sistem integritas (integrity system), memelihara konsistensi data yang disimpan.
•
Sistem kontrol akses yang bersamaan (concurrency control system), mengijinkan akses basis data secara bersamaan.
•
Sistem kontrol perbaikan (recovery control system), mengembalikan basis data ke kondisi konsisten sebelumnya setelah terjadi kegagalan perangkat keras atau perangkat lunak.
•
Katalog pengguna (user-accessible catalog), berisi deskripsi data dalam basis data.
2.2.1
Keuntungan dari DBMS Menurut Connolly dan Begg (2005, p26), keuntungan dari DBMS meliputi : a) Mengontrol duplikasi data. b) Konsistensi data. c) Informasi lebih dari jumlah data yang sama. d) Penggunaan data secara bersamaan. e) Meningkatkan integritas data. f) Meningkatkan keamanan.
13
g) Pelaksanaan standardisasi. h) Skala ekonomi tertentu. i) Skala ekonomi. j) Keseimbangan antara persyaratan yang saling bertentangan. k) Meningkatkan aksesibilitas data dan responsibilitas data. l) Meningkatkan produktivitas. m) Meningkatkan pemeliharaan melalui data yang bebas. n) Meningkatkan konkurensi. o) Meningkatkan backup dan recovery service.
2.2.2
Kerugian dari DBMS Menurut Connolly dan Begg (2005, p29), kerugian dari DBMS meliputi : a) Kompleksitas. b) Memerlukan disk space dan memory yang tidak sedikit. c) Harga dari DBMS yang pada umumnya cukup mahal. d) Biaya hardware tambahan. e) Biaya konversi. f) Performa. g) Dampak yang lebih hebat jika terjadi kegagalan.
14
2.2.3
Structured Query Language (SQL) Menurut Connolly dan Begg (2005, p113), Structured Query Language (SQL) merupakan sebuah contoh dari transform-oriented language, atau sebuah bahasa yang didesain untuk menggunakan relasi untuk mentransformasikan inputs ke output yang dibutuhkan. Sebagai sebuah bahasa, standar ISO SQL memiliki dua komponen utama yaitu :
2.2.4
•
Data Definition Language (DDL)
•
Data Manipulation Language (DML)
Data Definition Language (DDL) Menurut Connolly dan Begg (2005, p40), Data Definition Language (DDL) adalah sebuah bahasa yang memungkinkan DBA atau user untuk mendeskripsikan dan memberi nama entitas, atribut, dan hubungan yang dibutuhkan
untuk
aplikasi,
termasuk
batasan-batasan
keamanan
dan
integritasnya. Hasil kompilasi dari Data Definition Language (DDL) adalah seperangkat tabel yang disimpan dalam file spesial yang dinamakan katalog sistem.
Katalog
sistem
ini
mengintegrasikan
meta-data,
data
yang
menggambarkan objek dalam basis data dan membuatnya menjadi lebih mudah untuk diakses. Statement standar DDL yang utama pada umumnya adalah sebagai berikut (Connolly dan Begg, 2005, p168) :
15
a) CREATE SCHEMA b) CREATE DOMAIN c) CREATE TABLE d) CREATE VIEW e) ALTER DOMAIN f) ALTER TABLE g) DROP SCHEMA h) DROP DOMAIN i) DROP TABLE j) DROP VIEW
2.2.5
Data Manipulation Language (DML) Menurut Connolly dan Begg (2005, p40), Data Manipulation Language (DML) adalah sebuah bahasa yang menyediakan seperangkat operasi untuk mendukung operasi dasar manipulasi data pada data dalam basis data. Operasi manipulasi data biasanya mencakup berikut ini : a) Memasukkan data baru ke dalam basis data (insert). b) Memodifikasi data yang ada di dalam basis data (update). c) Mengambil data yang disimpan di dalam basis data (select). d) Menghapus data yang terdapat di dalam basis data (delete). Data Manipulation Language (DML) dapat dibedakan menjadi dua tipe, yaitu :
16
a) Procedural DML Procedural DML adalah sebuah bahasa yang memungkinkan user untuk memberitahukan kepada sistem akan data yang dibutuhkan dan bagaimana tepatnya data tersebut diambil. Procedural DML tertanam dalam bahasa pemrograman tingkat tinggi dimana menyediakan fasilitas untuk iterasi dan menangani navigasi logika. b) Non-procedural DML Non-procedural
DML
adalah
sebuah
bahasa
yang
memungkinkan user untuk menyampaikan data apa yang diperlukan tanpa perlu menyampaikan bagaimana data tersebut diambil. Pada umumnya, non-procedural DML lebih mudah untuk dipelajari dan digunakan daripada procedural DML.
2.2.6
Fourth Generation Language (4th GL) Menurut Connolly dan Begg (2005, p42), dibandingkan dengan 3rd GL yang procedural, 4th GL adalah non-procedural yaitu pengguna lebih ditekankan pada pendefinisian apa yang akan dikerjakan, daripada bagaimana mengerjakannya. Contoh 4th GL meliputi : a) Forms generators Merupakan fasilitas interaktif untuk membuat form input data dan tampilannya. Mendefinisikan desain tampilan, informasi apa
17
yang akan disajikan, komponen warna pada layar dan karakteristik lainnya. b) Report generators Membuat laporan yang datanya diambil dari basis data. Memungkinkan
pengguna
untuk
mengambil
data
yang
diperlukan untuk laporan. Lebih menekankan kepada rancangan output, yaitu bagaimana suatu laporan akan disajikan. c) Graphic generators Digunakan untuk mengambil data dari basis data, dan menampilkannya dalam bentuk grafik, seperti bar chart, pie chart, dan lain-lain. d) Application generators Fasilitas untuk menghasilkan program yang berhubungan dengan data, menentukan bagaimana menampilkan fungsi-fungsi.
2.3
Database System Development Lifecycle Siklus hidup pengembangan sistem basis data atau dikenal juga dengan database system development lifecycle (DSDLC) merupakan suatu pendekatan terstruktur untuk mengembangkan sistem basis data. Karena sistem basis data merupakan komponen yang penting dalam sistem informasi suatu perusahaan besar, siklus hidup pengembangan sistem basis data berkaitan erat dengan siklus hidup sistem informasi. (Connolly dan Begg, 2005, p282-p283)
18
Adalah penting untuk mengetahui bahwa tahapan siklus hidup pengembangan sistem basis data tidaklah harus berurutan, tetapi melibatkan sejumlah pengulangan tahapan sebelumnya melalui feed-back loops. Berikut ini akan ditunjukkan tahapan database system development lifecycle (DSDLC) pada gambar di bawah ini :
Gambar 2.1 Tahap-tahap database system development lifecycle. (Connolly dan Begg, 2005, p284)
19
2.3.1
Database Planning (Perencanaan Basis Data) Database planning (perencanaan basis data) merupakan aktivitasaktivitas manajemen yang memungkinkan tahap-tahap dalam database system development lifecycle direalisasikan seefisien dan seefektif mungkin (Connolly dan Begg, 2005, p285). Perencanaan basis data harus diintegrasikan dengan keseluruhan sistem informasi suatu organisasi. Ada tiga persoalan pokok yang terlibat dalam perumusan suatu strategi sistem informasi : a) Identifikasi rencana, sasaran dan tujuan perusahaan dengan penetuan kebutuhan sistem informasi. b) Evaluasi
sistem infromasi
yang
sedang
berjalan
untuk
menentukan kelebihan dan kekurangan yang ada. c) Penilaian terhadap peluang IT (Information Technology) apakah mampu menghasilkan keuntungan yang kompetitif. Tahapan dalam perencanaan basis data juga harus menjelaskan : a) Mission statement dari proyek basis data. Mission statement ini menjelaskan tujuan utama aplikasi basis data, juga membantu menjelaskan tujuan proyek basis data, dan menyediakan maksud yang lebih jelas dalam pembuatan aplikasi basis data secara efektif dan efisien (Connolly dan Begg, 2005, p286). Dengan merumuskan apa sebenarnya yang menjadi tujuan dari proyek basis data ini maka diharapkan dapat lebih memfokuskan pekerjaan pada tahap selanjutnya.
20
b) Mission objectives. Selain merumuskan tujuan dari sebuah proyek basis data, harus diperhatikan juga mengenai tugas apa saja yang harus didukung oleh basis data tersebut. Setiap mission objective akan menjelaskan tugas tertentu yang harus didukung oleh basis data, dengan asumsi jika basis data mendukung mission objective, maka mission statement juga akan sesuai (Connolly dan Begg, 2005, p286). Di dalam perencanaan basis data juga meliputi perkembangan standar yang akan menentukan bagaimana suatu data akan dikumpulkan, bagaimana format yang harus ditetapkan, lalu dokumentasi apa saja yang akan dibutuhkan, serta bagaimana desain dan implementasi harus dikerjakan nantinya.
2.3.2
System Definition (Pendefinisian Sistem) System definition (pendefinisian sistem) menjelaskan bidang dan batasan aplikasi basis data serta pandangan pengguna (user view) secara umum (Connolly dan Begg, 2005, p286). Hal ini sangat penting dilakukan dalam suatu proses perancangan basis data agar dapat melakukan proses identifikasi mengenai batasan sistem yang akan dirancang, serta bagaimana sistem tersebut akan berhubungan dengan bagian sistem informasi pada organisasi yang lain. Selain itu batasan sistem sebaiknya tidak hanya sesuai dengan bidang dan batasan aplikasi serta pandangan pengguna yang telah ada saja pada saat ini, namun harus sesuai juga dengan kebutuhan pada masa yang akan datang.
21
Pandangan pengguna sangat diperlukan untuk mengidentifikasi informasi-informasi yang dibutuhkan oleh pengguna (user). Pandangan pengguna menggambarkan apa yang dibutuhkan oleh aplikasi basis data dari sudut pandang jabatan tertentu, seperti manajer atau pengawas, maupun dari sudut pandang area aplikasi perusahaan, seperti pemasaran, personalia, atau pengawasan persediaan, dalam hubungannya dengan data yang akan disimpan dan transaksi yang akan dijalankan terhadap data itu (Connolly dan Begg, 2005, p287).
2.3.3
Requirements Collection and Analysis (Pengumpulan Kebutuhan dan Analisis) Pada tahap ini dilakukan proses pengumpulan dan analisa informasi mengenai bagian organisasi yang harus didukung oleh aplikasi basis data, dan penggunaan informasi ini berguna untuk mengidentifikasi persyaratan pengguna terhadap sistem yang baru (Connolly dan Begg, 2005, p288). Tahap ini meliputi pengumpulan dan analisis informasi mengenai bagian perusahaan yang harus dilayani oleh basis data. Ada tiga pendekatan utama untuk pengaturan kebutuhan aplikasi basis data dengan multiple user views, yakni : a) Pendekatan centralized Kebutuhan-kebutuhan untuk setiap user view digabung dalam suatu kumpulan kebutuhan tunggal untuk aplikasi basis data baru.
22
b) Pendekatan view intergration Kebutuhan-kebutuhan untuk setiap user view digunakan untuk membangun
sebuah
model
data
yang
terpisah
untuk
merepresentasikan pengguna itu sendiri. Hasil dari model data akan digabung pada tahap perancangan basis data. c) Kombinasi antara centralized dan view integration.
Suatu proses resmi dalam menggunakan teknik-teknik seperti wawancara atau kuesioner untuk mengumpulkan fakta-fakta tentang sistem dan kebutuhan-kebutuhannya dinamakan dengan teknik fact-finding (Connolly dan Begg, 2005, p314). Ada lima kegiatan yang dapat dipakai dalam teknik ini, yaitu : 1) Memeriksa dokumentasi Pemahaman terhadap jalannya sistem akan cepat diperoleh dengan memeriksa dokumen-dokumen, formulir, laporan, dan berkas yang terkait dengan sistem yang sedang berjalan pada perusahaan.
Dengan
pemeriksaan
ini
diharapkan
dapat
mengetahui data-data apa saja yang akan disimpan di dalam basis data (Connolly dan Begg, 2005, p317). 2) Wawancara Wawancara
bertujuan
untuk
mengumpulkan
fakta-fakta,
memeriksa kebenaran fakta yang ada dan mengklarifikasinya, menimbulkan
antusiasme,
melibatkan
pengguna
akhir,
23
mengidentifikasi kebutuhan-kebutuhan, dan mengumpulkan ideide dan pendapat (Connolly dan Begg, 2005, p317). Teknik ini memerlukan
kemampuan
komunikasi
yang
baik
untuk
menghadapi pengguna yang memiliki nilai, prioritas, pendapat, motivasi, dan kepribadian yang berbeda-beda. 3) Observasi Pengamatan ini memungkinkan untuk ikut serta atau mengamati seseorang melakukan kegiatan untuk mempelajari sistem. Salah satu faktor pengamatan dapat berhasil adalah dengan mencari informasi sebanyak mungkin tentang aktivitas yang akan diamati serta orang yang melakukan aktivitas tersebut (Connolly dan Begg, 2005, p319). 4) Penelitian Selain melakukan penelitian yang berasal dari dalam organisasi itu sendiri, dapat juga dilakukan pengumpulan informasi yang berasal dari luar organisasi tersebut. Beberapa contoh sumber informasi tersebut antara lain jurnal komputer, buku-buku referensi, dan internet. Sumber informasi tersebut juga dapat digunakan untuk memecahkan masalah serupa (Connolly dan Begg, 2005, p319). 5) Kuesioner Teknik lain yang dapat digunakan untuk mengumpulkan informasi yang dibutuhkan adalah dengan menggunakan
24
kuesioner. Kuesioner adalah suatu dokumen dengan tujuan khusus yang memungkinkan fakta-fakta dikumpulkan dari banyak orang sambil menjaga kontrol terhadap tanggapan yang diberikan (Connolly dan Begg, 2005, p320).
2.3.4
Database Design (Perancangan Basis Data) Perancangan basis data merupakan proses menciptakan perancangan untuk basis data yang akan mendukung operasi dan tujuan perusahaan (Connolly dan Begg, 2005, p291). Terdapat dua pendekatan dalam perancangan basis data (Connolly dan Begg, 2005, p291), yaitu : a) Bottom-up Pendekatan ini dimulai dari tingkat paling dasar dari atribut (yakni properti dari entity dan hubungan relasional) dimana melalui analisis gabungan antara atribut-atribut, dikelompokkan ke dalam relasi-relasi yang merepresentasikan tipe-tipe entity dan hubungan antara entity. Pendekatan ini lebih cocok untuk perancangan basis data yang sederhana dengan jumlah atribut yang relatif kecil. b) Top-down Pendekatan ini dimulai dari pengembangan model data yang terdiri dari beberapa hubungan relasional dan entity tingkat tinggi.
25
Perancangan basis data terdiri dari tiga tahap utama (Connolly dan Begg, 2005, p293), yaitu : 1. Conceptual Database Desain (Perancangan Basis Data Konseptual) Perancangan basis data konseptual adalah proses membangun suatu model informasi yang digunakan oleh perusahaan atau organisasi yang tidak tergantung dari pertimbangan fisik (Connolly dan Begg, 2005, p293). 2. Logical Database Design (Perancangan Basis Data Logikal) Perancangan basis data logikal adalah proses pembuatan suatu model informasi yang digunakan pada perusahaan berdasarkan pada model data yang spesifik, tetapi tidak tergantung dari Database Management System (DBMS) yang khusus dan pertimbangan fisik lain (Connolly dan Begg, 2005, p294). 3. Physical Database Design (Perancangan Basis Data Fisikal) Perancangan basis data fisikal adalah suatu proses untuk menghasilkan gambaran dari implementasi basis data pada tempat penyimpanan, menjelaskan dasar dari relasi, organisasi file dan indeks yang digunakan untuk efisiensi data dan menghubungkan beberapa integrity constraints dan tindakan keamanan (Connolly dan Begg, 2005, p294)
26
2.3.5
DBMS Selection (Pemilihan DBMS) Tahapan ini bertujuan untuk memilih DBMS yang tepat untuk mendukung aplikasi basis data, dimana dibutuhkan tambahan beberapa software dan hardware. Berikut ini adalah tahapan utama untuk memilih basis data, yaitu : 1. Define terms of reference of study, cakupan penelitian mengenai pemilihan DBMS menyatakan tujuan dan ruang lingkup penelitian serta tugas-tugas yang harus dilakukan, meliputi deskripsi kriteria (berdasarkan spesifikasi kebutuhan pengguna) untuk mengevaluasi produk DBMS, daftar DBMS yang tersedia dan batasan-batasan serta jadwal waktu untuk penelitiannya. 2. Shortlist two or three products, kriteria-kriteria yang dianggap kritis untuk keberhasilan implementasi yang dapat digunakan untuk evaluasi daftar DBMS yang tersedia. 3. Evaluate products, ada banyak fitur yang dapat digunakan untuk mengevaluasi sebuah produk DBMS, semua bobot nilai dari fitur-fitur tersebut dijumlahkan untuk mendapatkan nilai sebuah produk DBMS tertentu yang akan dibandingkan dengan nilai produk DBMS lainnya. Produk DBMS yang dipilih adalah produk dengan nilai tertinggi. 4. Recommend selection and produce report, tahap akhir dari pemilihan DBMS adalah untuk mendokumentasikan proses dan
27
untuk menyediakan laporan dan rekomendasi mengenai produk DBMS tertentu.
2.3.6
Application Design (Perancangan Aplikasi) Merupakan perancangan user interface dan program aplikasi yang menggunakan dan memproses basis data. Ada dua aspek penting dalam perancangan aplikasi, yakni : a) Transaction Design (Perancangan Transaksi) Transaksi merupakan sebuah aksi, atau serangkaian aksi yang dilakukan oleh seorang pengguna atau program aplikasi yang mengakses atau mengubah isi dari basis data. Tujuan
dari
perancangan
dan
transaksi
adalah
untuk
menetapkan
mendokumentasikan karakteristik tingkat tinggi dari transaksi yang dibutuhkan pada basis data, yang termasuk : •
Data yang digunakan dalam transaksi.
•
Karateristik fungsional dari transaksi.
•
Output dari transaksi.
•
Kepentingan pengguna.
•
Nilai yang diharapkan dari pemakaian.
Perancangan ini harus dilakukan lebih awal dalam proses perancangan untuk memastikan bahwa basis data yang
28
diimplementasikan mampu mendukung semua transaksi yang dibutuhkan. Ada tiga jenis transaksi, yaitu : •
Retrieval transactions, digunakan untuk mendapatkan kembali data untuk ditampilkan di layar atau dalam laporan.
•
Update transactions, digunakan untuk menambah data baru, menghapus data lama, atau memodifikasi data yang ada di dalam basis data.
•
Mixed Transactions, melibatkan retrieval (pemanggilan) dan update (perubahan) data atau kombinasi antara keduanya.
b) User Interface Design (Perancangan antarmuka) Sebelum mengimplementasikan suatu form atau laporan, ada perlunya merancang tampilan terlebih dahulu.
2.3.7
Prototyping Merupakan pembuatan suatu model kerja dari aplikasi basis data (Connolly dan Begg, 2005, p304). Suatu prototype adalah model yang bekerja yang tidak mempunyai semua fitur-fitur yang diperlukan atau menyediakan semua fungsionalitas dari sistem terakhir. Tujuan utama dari pengembangan suatu aplikasi basis data prototype adalah memungkinkan pengguna menggunakan prototype tersebut untuk menentukan fitur-fitur dari sistem yang
29
bekerja dengan baik, dan jika mungkin mengusulkan peningkatan atau bahkan fitur-fitur baru pada aplikasi basis data. Ada dua strategi prototyping yang umum digunakan, yaitu : 1) Requirement prototyping, menggunakan suatu prototype untuk menentukan kebutuhan-kebutuhan dari aplikasi basis data yang diusulkan dan ketika kebutuhan tersebut telah lengkap, prototype tersebut disingkirkan. 2) Evolutionary prototyping, digunakan untuk tujuan yang sama, perbedaan yang penting adalah bahwa prototype tidak dibuang tetapi dengan perkembangan yang lebih jauh menjadi aplikasi basis data yang digunakan.
2.3.8
Implementation (Implementasi) Implementasi merupakan realisasi fisik dari rancangan basis data dan rancangan aplikasi (Connolly dan Begg, 2005, p304). Implementasi basis data dilakukan dengan menggunakan Data Definition Language (DDL) dari DBMS yang dipilih, atau dengan menggunakan Graphical User Interface (GUI), yang menyediakan fungsionalitas yang sama dengan saat menyembunyikan pernyataan low-level DDL. Kemudian bagian dari program aplikasi adalah transaksi basis data, yang diimplementasikan dengan menggunakan Data Manipulation Language (DML), yang biasanya sudah terdapat dalam bahasa pemrograman.
30
2.3.9
Data Conversion and Loading Merupakan pemindahan data yang ada ke dalam basis data baru dan mengubah aplikasi yang ada untuk beroperasi pada basis data yang baru. Langkah ini diperlukan hanya ketika suatu sistem basis data baru menimpa sistem yang lama.
2.3.10 Testing Merupakan proses pengeksekusian program aplikasi dengan maksud pencarian kesalahan-kesalahan. Sebelum ditunjukkan secara langsung, aplikasi basis data yang baru dikembangkan seharusnya diuji sepenuhnya. Beberapa keuntungan melakukan testing : •
Menemukan error pada aplikasi dan mungkin juga error pada struktur basis data.
•
Testing mendemonstrasikan apakah basis data dan aplikasi dapat berjalan sesuai dengan kebutuhan performa dan spesifikasi yang diinginkan atau tidak.
2.3.11 Operational Maintenance (Perawatan Operasional) Merupakan proses pengawasan dan pertahanan sistem berikut instalasi. Pada langkah sebelumnya, aplikasi basis data telah diimplementasikan dan diuji sepenuhnya. Sekarang sistem memasuki langkah perawatan, yang melibatkan aktivitas-aktivitas berikut :
31
a) Mengawasi kinerja sistem. b) Mempertahankan dan meng-upgrade aplikasi basis data (ketika dibutuhkan).
2.4
Entity Relationship (ER) Modelling ER
Modelling
merupakan
suatu
pendekatan
top-down
dalam
perancangan basis data yang dimulai dengan mengidentifikasi data penting yang disebut entitas (entities) dan relasi/hubungan (relationship) antara data tersebut harus direpresentasikan dalam model (Connolly dan Begg, 2005, p342).
2.4.1
Entity Type Entity type adalah sekumpulan objek yang memiliki properti yang sama, yang didefinisikan oleh perusahaan sebagai keberadaan yang independen (Connolly dan Begg, 2005, p343). Setiap object yang unik dari sebuah entity type dapat disebut sebagai sebuah entity occurrence (Connolly dan Begg, 2005, p345). Entity type dapat diklasifikasikan sebagai strong (kuat) atau weak (lemah) sebagai berikut : a) Strong
entity
type
merupakan
suatu
entity
type
yang
keberadaannya tidak tergantung kepada entity type yang lain. b) Weak
entity
type
merupakan
suatu
entity
type
keberadaannya tergantung kepada entity type yang lain.
yang
32 Nama Entity
Staff
Cabang
Gambar 2.2 Representasi diagram entity type Staff dan Cabang
2.4.2
Relationship Type Relationship type adalah sekumpulan entity yang mempunyai hubungan dan memiliki arti (Connolly dan Begg, 2005, p346).
Nama Relationship
Staff
Å Memiliki
Cabang
Gambar 2.3 Representasi diagram ‘Cabang memiliki Staff’ relationship type
33
2.4.2.1 Degree of Relationship Type Degree of relationship type merupakan jumlah entity type yang ikut serta dalam sebuah relationship (Connolly dan Begg, 2005, p347). Beberapa degree of relationship type adalah : a) Binary relationship merupakan hubungan yang terjadi di antara dua entity type. ‘PrivateOwner memiliki PropertyForRent’
PrivateOwner
POwns Æ
PropertyForRent
Gambar 2.4 Contoh binary relationship b) Ternary relationship merupakan hubungan yang terjada di antara tiga entity type. ‘Staff meregistrasi seorang client pada sebuah branch’
Staff
Register
Branch
Client
Gambar 2.5 Contoh ternary relationship c) Quaternary relationship merupakan hubungan yang terjadi antara empat entity type.
34 ‘Seorang solicitor mengurus sebuah bid mewakili seorang buyer dan didukung oleh sebuah financial instution’
Solicitor
Financial Institution
Register
Buyer
Bid
Gambar 2.6 Contoh quaternary relationship
2.4.2.2 Recursive Relationship Recursive relationship merupakan sebuah relationship type dimana entity type yang sama ikut berpartisipasi lebih dari sekali dengan peran yang berbeda (Connolly dan Begg, 2005, p349). ‘Staff [Supervisor] mengawasi (supervises) staff lainnya [Supervisee]’
Peran
Å Supervises Supervisor
Peran Supervisee
Staff
Gambar 2.7 Contoh recursive relationship
35
2.4.3
Attributes Atribut adalah sebuah properti dari suatu entity type atau relationship type (Connolly dan Begg, 2005, p350). Attribute domain adalah sekumpulan nilai yang diperbolehkan untuk satu atau lebih attributes. Atribut dapat diklasifikasikan sebagai : a) Simple and Composite Attribute Simple attribute adalah sebuah atribut yang tersusun dari sebuah komponen dengan keberadaan yang independen. Simple attribute tidak dapat dipecah lagi menjadi atribut yang lebih kecil, biasanya disebut dengan atomic attribute. Composite attribute adalah attribute yang tersusun dari banyak komponen, dimana setiap komponennya memiliki keberadaan yang independen. Composite attribute dapat dipecah lagi menjadi komponen-komponen idependen yang lebih kecil. b) Single-Valued and Multi-Valued Attributes Single-valued attribute merupakan suatu atribut yang memiliki sebuah nilai untuk setiap keberadaan sebuah entity type. Multi-valued attribute merupakan suatu atribut yang memiliki banyak nilai untuk setiap keberadaan sebuah entity type. c) Derived Attributes Derived
attribute
merupakan
suatu
atribut
yang
merepresentasikan suatu nilai yang bisa didapat dari nilai sebuah
36
atau kumpulan attribute yang berhubungan, tetapi tidak harus dalam entity type yang sama.
2.4.4
Keys
Candidate key adalah himpunan atribut yang minimal yang secara unik mengidentifikasikan setiap occurrence dari sebuah tipe entitas (Connolly dan Begg, 2005, p352). Primary key adalah candidate key yang terpilih untuk mengidentifikasikan secara unik setiap occurrence dari sebuah tipe entitas (Connolly dan Begg, 2005, p353). Composite key adalah sebuah candidate key yang terdiri atas dua atau lebih atribut (Connolly dan Begg, 2005, p353). Pada sebuah tipe entitas biasanya terdapat lebih dari satu candidate key yang salah satunya harus dipilih untuk menjadi primary key. Pemilihan primary key didasarkan pada panjang atribut, jumlah minimal atribut yang diperlukan, dan keunikannya. Alternate key adalah setiap candidate key yang tidak terpilih menjadi primary key, atau biasa disebut dengan secondary key (Whitten, 2004, p298). Foreign key adalah sebuah primary key
pada sebuah entitas yang
digunakan pada entitas lainnya untuk mengidentifikasikan sebuah relationship (Whitten, 2004, p301).
2.4.5
Structural Constraints Multiplicity merupakan jumlah kemunculan yang mungkin dari sebuah entity type yang mungkin berhubungan dengan kemunculan tunggal dari sebuah
37
entity type-entity type yang berhubungan melalui relasi tertentu (Connolly dan Begg, 2005, p356). Beberapa jenis relasi berdasarkan multiplicity yang dimiliki, yaitu : 1. Relasi 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 satu.
Gambar 2.8 Notasi relasi one-to-one 2. Relasi 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 satu.
Gambar 2.9 Notasi relasi one-to-many
38
3. Relasi 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.
Gambar 2.10 Notasi relasi many-to-many
2.4.6
Crow’s Foot Data Model Dari beberapa pilihan yang tesedia untuk menggambarkan cardinality, notasi crow’s foot merupakan yang paling diminati. Crow’s foot menunjukkan baik cardinality minimum dan maksimum dalam suatu format grafik yang jelas. Simbol multiplicity-nya intuitif dan mudah dimengerti oleh pembaca non-teknis. Notasi crow’s foot sebaiknya digunakan dalam seluruh diagram model data konseptual yang akan ditinjau oleh pengguna bisnis. Notasi ini juga cocok untuk digunakan dalam model desain basis data fisikal (Stewart, 2008). Pada pengerjaan penulisan ini akan digunakan model data Crow’s Foot pada Entity Relationship Diagram yang akan dibuat.
39
Gambar 2.11 Contoh Crow’s foot data model
Berikut merupakan representasi cardinality pada Crow’s Foot data model :
Gambar 2.12 Cardinality pada Crow’s foot data model
2.5
Perancangan Basis Data Menurut Connolly dan Begg (2005, p438), metodologi perancangan basis data merupakan pendekatan terstruktur yang menggunakan bantuan prosedur,
teknik,
alat-alat,
dan
dokumentasi
untuk
mendukung
dan
memfasilitasi proses perancangan basis data. Metodologi perancangan basis data terbagi atas tiga tahap perancangan, yaitu perancangan konseptual, perancangan logikal, dan perancangan fisikal. Meskipun langkah-langkah dalam metodologi digambarkan secara proses yang
40
berurutan, perlu ditekankan bahwa tidak berarti metodologi tersebut harus dibuat secara berurutan. Seringkali pengetahuan yang didapat pada suatu tahap mempengaruhi keputusan yang telah diambil di tahap sebelumnya.
2.5.1
Perancangan Konseptual (Conceptual Design) Conceptual database design adalah proses membangun model informasi yang digunakan organisasi, bebas dari semua pertimbangan fisik (Connolly dan Begg, 2005, p439). Pertimbangan fisik yang dimaksud meliputi DBMS yang akan digunakan, program aplikasi, bahasa pemrograman, platform perangkat keras, performa, dan pertimbangan fisik lainnya. Langkah-langkah dalam metodologi conceptual database design adalah : Langkah 1
Membangun Model Data Konseptual
Bertujuan untuk memecah rancangan menjadi tugas-tugas yang dapat diatur dengan memeriksa sudut pandang yang berbeda dari pengguna di dalam organisasi (Connolly dan Begg, 2005, p442). Hasil dari langkah ini berupa pembuatan satu atau lebih local conceptual data model yang merupakan penggambaran yang tepat dan lengkap dari suatu organisasi dilihat dari para pengguna yang berbeda. Tugas-tugas yang dilakukan pada langkah ini terdiri dari : Langkah 1.1 Mengidentifikasi entity types Entity type dapat dikenali dengan mengidentifikasikan kata benda atau frase kata benda pada spesifikasi kebutuhan pengguna, objek
41
besar seperti orang, tempat, benda atau konsep. Alternatif lain adalah dengan mencari objek yang keberadaannya bebas.
Langkah 1.2 Mengidentifikasi relationship type Bertujuan untuk mengidentifikasi relationship yang penting yang ada antara entity types yang telah diidentifikasi sebelumnya. Relationship type diidentifikasikan dengan mencari kata kerja atau suatu kata yang berhubungan dengan kata kerja.
Langkah 1.3 Mengidentifikasi
dan
menghubungkan
attributes
dengan entity atau relationship types Tujuannya adalah untuk menghubungkan atribut dengan entity dan relationship types yang tepat. Dalam tahap ini juga dilakukan identifikasi composite attributes, single-valued/multi-valued attributes, dan derived attributes.
Langkah 1.4 Menentukan attribute domains Menentukan domain atribut dalam model data konseptual. Domain adalah sekumpulan nilai-nilai dari satu atau lebih atribut yang menggambarkan nilainya. Sebagai contoh nilai yang mungkin untuk atribut jenis kelamin dari entitas karyawan adalah ‘L’ atau ‘W’.
42
Langkah 1.5 Menentukan candidate, primary, dan alternate key attribute Tujuannya untuk mengidentifikasi candidate key untuk tiap-tiap tipe entitas dan jika ada lebih dari satu candidate key maka pilih satu untuk menjadi primary key dan sisanya dapat dijadikan alternate key.
Langkah 1.6 Mempertimbangkan penggunaan enchance modelling concepts (langkah opsional) Langkah
ini
bertujuan
untuk
menentukan
penggunaan
specialization, generalization, aggregation, dan composition. Specialization
merupakan
suatu
proses
memaksimalkan
perbedaan-perbedaan antara anggota-anggota sebuah entitas dengan cara mengidentifikasi karakteristik yang membedakan entitas tersebut (Connolly dan Begg, 2005, p374). Generalization
merupakan
suatu
proses
meminimalkan
perbedaan-perbedaan antara entitas-entitas dengan cara mengidentifikasi sifat umum pada entitas-entitas tersebut (Connolly dan Begg, 2005, p374). Aggregation menggambarkan relationship ‘has-a’ atau ‘is-partof’ antara tipe entitas dimana yang satunya mewakili ‘whole’ dan yang satunya lagi mewakili ‘part’ (Connolly dan Begg, 2005, p383).
43
Composition digunakan untuk merepresentasikan penggabungan antara tipe-tipe entitas yang memiliki kepemilikan yang kuat dan hubungan yang penting antara ‘whole’ dan ’part’.
Langkah 1.7 Memeriksa model akan adanya redudansi Bertujuan memeriksa conceptual model untuk menghindari adanya redudansi atau pengulangan data dalam model. Ada dua kegiatan yang dapat dilakukan pada tahap ini : a) Memeriksa kembali one-to-one relationship (1:1) Kemungkinan ada lebih dari satu entitas yang menggambarkan objek yang sama dalam organisasi. Oleh karena itu, entitasentitas tersebut harus digabungkan. b) Menghilangkan relasi yang redundan Suatu relationship menjadi redundan jika informasi yang sama dihasilkan
melalui
relationship
yang
lainnya.
Untuk
meminimalkan data model maka relationship yang redundan harus dihilangkan. c) Mempertimbangkan dimensi waktu Dimensi waktu dalam relationships penting saat mengukur adanya redudansi. Yang dimaksud disini adalah hubungan antar entitas yang mungkin saja terjadi pada waktu yang berbeda.
44
Langkah 1.8 Memvalidasi
model
konseptual
terhadap
user
transactions Memastikan model konseptual telah mendukung transaksitransaksi yang dibutuhkan. Tahap ini dapat dilakukan dengan dua cara, yaitu : a) Mendeskripsikan transaksi Dengan pendekatan ini berarti akan diperiksa semua informasi (entitas, relationship, dan atribut) yang dibutuhkan oleh setiap transaksi apakah telah disediakan dalam model, dengan mendokumentasikan setiap kebutuhan transaksi. b) Menggunakan transaction pathways Pendekatan ini untuk validasi model data terhadap transaksi yang dibutuhkan termasuk representasi diagram jalur yang digunakan oleh setiap transaksi langsung pada ER diagram.
Langkah 1.9 Review model data konseptual dengan user Mengadakan review model data konseptual dengan pengguna sistem
untuk
memastikan
model
data
tersebut
secara
tepat
menggambarkan transaksi dan kebutuhan data secara nyata dalam perusahaan.
45
2.5.2
Perancangan Logikal (Logical Design) Desain basis data logikal adalah proses membangun model informasi yang digunakan organisasi berdasarkan model data tertentu, tetapi tidak tergantung dari Database Management System (DBMS) dan pertimbangan fisik lainnya (Connolly dan Begg, 2005, p439). Langkah-langkah dalam metodologi logical database design yaitu : Langkah 2
Membangun dan validasi logical data model
Tujuannya adalah untuk membangun sebuah logical data model dari sebuah conceptual data model yang mewakili pandangan tertentu dari organisasi dan kemudian memvalidasi model ini untuk memastikan bahwa strukturnya benar (dengan menggunakan teknik normalisasi) dan untuk memastikan dukungannya terhadap transaksi-transaksi yang dibutuhkan. Kegiatan yang dilakukan pada langkah ini meliputi : Langkah 2.1 Membentuk relasi untuk logical data model Bertujuan untuk menyaring conceptual data model sehingga fitur-fitur yang tidak sesuai dengan model relasional dihilangkan. Langkah tersebut antara lain dilakukan terhadap : 1) Strong entity types Untuk semua entitas dengan jenis kuat, buatlah sebuah relationship yang memiliki semua atribut sederhana yang dimilikinya. Untuk composite attribute, hanya sertakan atribut pokoknya saja.
46
2) Weak entity types Untuk setiap entitas dengan jenis lemah, buatlah sebuah relationship yang memiliki semua atribut sederhana yang dimilikinya. Primary key dari entitas ini belum dapat ditentukan sampai relationship-nya dengan entitas kuat ditentukan. 3) One-to-many (1:*) binary relationship types Pada relationship jenis ini, entitas pada ‘one side’ kita anggap sebagai entitas induk sedangkan entitas pada ‘many side’
dianggap
sebagai
entitas
anak.
Untuk
merepresentasikan hubungan ini, kita kirimkan primary key dari entitas induk sebagai foreign key pada entitas anak. 4) One-to-one (1:1) binary relationship types Relasi 1:1 lebih sulit ditentukan hubungannya karena cardinality
dan
participation
constraints
juga
akan
menentukan dalam mengidentifikasi entitas induk dan anak dalam relationship ini. i.
Mandatory participation pada kedua sisi Pada kasus ini, kita harus menggabungkan kedua entitas yang memiliki relationship jenis ini dan memilih salah satu dari kedua primary key sebagai primary key yang baru.
47
ii.
Mandatory participation pada satu sisi Pada kasus ini, kita bisa mengidentifikasikan entitas yang berada pada sisi optional participation sebagai entitas induk, sedangkan yang berada pada sisi mandatory participation sebagai entitas anak. Seperti pada langkah sebelumnya, kita kirimkan primary key dari entitas induk sebagai foreign key pada entitas anak.
iii.
Optional participation pada kedua sisi Pada kasus ini, pemilihan induk dan anak bisa berubah-ubah. Untuk bisa menentukan, maka kita harus mencari sisi optional participation mana yang lebih mendekati sebagai mandatory participation. Pemecahan untuk relasi ini sangat tergantung dengan kondisi data yang ada.
5) One-to-one (1:1) recursive relationship Untuk pemecahan hubungan ini, dapat digunakan cara yang sama dengan yang telah diterapkan pada 1:1 relationship. 6) Superclass/subclass relationship Untuk setiap superclass/subclass relationship dalam data model
konseptual,
kita
mengidentifikasikan
entitas
superclass sebagai entitas parent dan entitas subclass sebagai entitas child. Terdapat banyak pilihan dalam
48
merepresentasikan relationship sebagai salah satu atau lebih relationships. Pilihan yang paling sesuai tergantung dari sejumlah faktor seperti disjointness dan participation constraint pada superclass/subclass relationship apakah subclass terlihat dalam distinct relatonship dan jumlah participant dalam superclass/subclass relationship. 7) Many-to-many (*:*) binary relationship types Dengan memecah relationship yang mengandung many-tomany (*:*) untuk mengidentifikasikan sebuah entitas tengah (intermediate entity) sehingga relationship ini digantikan dengan dua buah one-to-many (1:*) relationship, dengan entitas tengah berada di antara dua buah entitas yang lama. 8) Complex relationship types Complex relationship types dihilangkan dengan memecah relationship tersebut untuk mengidentifikasikan entitas tengah (intermediate entity). Kemudian complex relationship ini akan digantikan dengan beberapa one-to-many (1:*) binary relationship. 9) Multi-valued attributes Multi-valued attributes dapat dihilangkan dengan memecah atribut tersebut untuk mengidentifikasikan sebuah entitas. Setelah itu, kirimkan primary key pada entitas induk sebagai foreign key pada entitas anak.
49
Langkah 2.2 Validasi relasi dengan meggunakan normalisasi Normalisasi merupakan suatu teknik untuk menghasilkan sekumpulan relasi dengan properti yang diinginkan, sesuai dengan kebutuhan data dari suatu perusahaan (Connolly dan Begg, 2005, p388). Tujuan dari normalisasi adalah untuk meminimalkan redudansi data dan update anomalies, menciptakan representasi data, hubungan antar data dan constraint yang akurat, serta meningkatkan stabilitas. Untuk mencapai tujuan tersebut maka harus dilakukan identifikasi dengan benar atas relasi yang ada. Pada dasarnya, proses normalisasi dilakukan untuk meminimalkan redudansi data dan update anomalies. Menurut Connolly dan Begg (2005, p391), update anomalies dapat dibagi menjadi tiga jenis yaitu : a) Insert anomaly merupakan kejanggalan yang terjadi terhadap sebuah table pada saat dilakukan penambahan suatu record, yaitu berupa pelanggaran terhadap integrity constraint. b) Delete anomaly merupakan kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan penghapusan suatu record, penghapusan bermaksud untuk menghapus suatu data tertentu tetapi menyebabkan kehilangan data lain dari tabel tersebut. c) Modification anomaly merupakan kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan pengubahan suatu record, pengubahan terhadap suatu nilai tertentu harus dilakukan lebih dari sekali.
50
Tiga tingkatan normalisasi yang dijadikan acuan penulisan skripsi ini yaitu : 1) First Normal Form (1NF) Suatu relasi dikatakan 1NF jika titik temu tiap baris dan kolom pada relasi tersebut mengandung satu dan hanya satu nilai (Connolly dan Begg, 2005, p403). 2) Second Normal Form (2NF) Relasi dikatakan 2NF jika relasi tersebut berada pada 1NF dan setiap atribut yang bukan primary key bergantung penuh (fully
functionally
dependent)
terhadap
primary
key
(Connolly dan Begg, 2005, p407). Functional dependency terjadi jika A dan B adalah atribut dari sebuah relasi , B dikatakan functionally dependent terhadap A (A Æ B), jika setiap nilai dari A diasosiasikan dengan tepat satu nilai dari B. Full functional dependency terjadi jika A dan B merupakan atribut dari suatu relasi, B dikatakan full functional dependent terhadap A jika B functionally dependent terhadap A, tetapi bukan merupakan subset dari A. 3) Third normal form (3NF) Relasi dikatakan 3NF jika relasi tersebut dalam bentuk 1NF dan 2NF, dan tidak ada atribut bukan primary key bergantung secara transitif (transitively dependent) terhadap primary key (Connolly dan Begg, 2005, p409). Transitive
51
dependency merupakan sebuah kondisi dimana A, B, dan C merupakan atribut dari relasi yang jika AÆB dan BÆC maka C disebut bergantung secara transitif terhadap A melalui B (Connolly dan Begg, 2005, p397).
Langkah 2.3 Validasi relasi terhadap user transactions Memastikan relasi dalam model data logikal telah mendukung transaksi yang diperlukan. Pada tahap ini, akan dilakukan pengecekan terhadap relasi yang sudah terbentuk sebelumnya, apakah sudah dapat memproses transaksi tersebut dan pastikan tidak ada kesalahan pada saat membuat relasi.
Langkah 2.4 Menentukan integrity constraint Integrity
constraint
adalah
batasan-batasan
yang
harus
ditentukan untuk melindungi basis data agar tetap konsisten (Connolly dan Begg, 2005, p474). Berikut merupakan tipe dari integrity constraints : a) Required data ( Data yang diperlukan ) Beberapa atribut harus selalu berisi nilai yang benar, tidak dapat bernilai null. b) Attribute domain constraint Setiap atribut memiliki domain, yaitu himpunan nilai yang dibolehkan (Connolly dan Begg, 2005, p475).
52
c) Multiplicity Multiplicity merepresentasikan batasan jumlah yang ada antara data yang ada di basis data. d) Entity integrity Primary key dari sebuah entitas tidak boleh bernilai null. e) Referential integrity Jika sebuah foreign key memiliki nilai, maka nilai tersebut harus menunjuk ke sebuah baris yang ada pada relasi ‘parent’. f) General constraint Kegiatan update entitas dibatasi oleh peraturan atau kebijakan
organisasi
yang
mengatur
transaksi
yang
diwakilkan oleh update yang dilakukan.
Langkah 2.5 Meninjau kembali local logical data model dengan user Memastikan bahwa logical data model dan dokumentasi pendukung yang menggambarkan model merupakan perwakilan yang benar dari pandangan pengguna.
53
Langkah 2.6 Menggabungkan logical data model menjadi global model (langkah opsional) Menggabungkan local logical data models menjadi satu global logical data model yang merepresentasikan seluruh user views dari basis data. Langkah ini hanya perlu dilakukan apabila saat desain dilakukan dengan user views yang terpisah berdasarkan masing-masing user.
Langkah 2.7 Memeriksa untuk perkembangan mendatang Bertujuan untuk menentukan apakah akan ada perubahan yang signifikan pada masa mendatang dan memperkirakan apakah logical data model yang sekarang dapat mengakomodasi perubahan tersebut.
2.5.3
Perancangan Fisikal (Physical Design) Perancangan basis data fisikal merupakan proses memproduksi sebuah deskripsi dari implementasi basis data dalam secondary storage, yang menjelaskan relasi dasar, organisasi file, dan indeks yang digunakan untuk mendapatkan akses data yang efisien, serta setiap integrity constraint yang saling berhubungan dan juga pengukuran keamanan (Connolly dan Begg, 2005, p294).
54
Langkah 3
Menterjemahkan Logical Data Model untuk DBMS Sasaran
Langkah ini bertujuan untuk menghasilkan skema basis data relasional bagi global logical data model yang dapat diimplementasikan pada DBMS sasaran. Langkah 3.1 Membuat base relations Memutuskan bagaimana merepresentasikan relasi-relasi yang telah diidentifikasikan pada logical data model pada DBMS yang akan dipakai.
Langkah 3.2 Merancang representasi dari data yang diperoleh Memutuskan bagaimana merepresentasikan derived data yang ada dalam logical data model pada DBMS yang akan dipakai.
Langkah 3.3 Merancang general constraints Merancang
batasan-batasan umum untuk DBMS yang akan
digunakan.
Langkah 4
Merancang file organizations dan indexes
Menentukan organisasi file optimal untuk menyimpan relasi dasar dan indeks yang diperlukan untuk mencapai performa yang dapat diterima, yaitu cara dimana relasi dan entitas akan dilaksanakan di secondary storage.
55
Langkah 4.1 Analisis transaksi Memahami fungsi-fungsi dari transaksi yang akan dijalankan pada basis data dan menganalisis transaksi yang penting. Dalam menganalisis transaksi, kita mencoba mengidentifikasikan kriteria performa, seperti : •
Transaksi yang akan berjalan secara terus-menerus dan yang akan mempengaruhi secara signifikan pada performa.
•
Transaksi yang penting bagi operasi bisnis.
•
Waktu selama sehari/seminggu ketika akan terjadi permintaan yang tinggi dibuat dalam basis data (disebut peak load).
Langkah 4.2 Memilih file organizations Tujuan langkah ini adalah menetukan organisasi file yang efisien untuk tiap-tiap relasi dasar jika diperbolehkan oleh DBMS yang akan digunakan. Beberapa tipe organisasi file adalah : •
Heap
•
Hash
•
ISAM
•
B+-Tree
•
Cluster
56
Langkah 4.3 Memilih index Memutuskan
apakah
dengan
menambahkan
index
akan
meningkatkan performa dari sistem.
Langkah 4.4 Memperkirakan disk space yang diperlukan Memperkirakan jumlah disk space yang diperlukan basis data. Estimasi pemakaian disk tergantung pada DBMS dan perangkat keras yang digunakan untuk mendukung basis data.
Langkah 5
Merancang user views
Merancang
view
pengguna
yang
telah
diidentifikasi
selama
pengumpulan persyaratan dan tahap analisis dari database system development lifecycle.
Langkah 6
Merancang mekanisme keamanan
Merancang mekanisme keamanan untuk basis data yang ditentukan user selama tahap requirements dan collections pada database systems development lifecycle.
Langkah 7
Mempertimbangkan pengenalan redudansi terkontrol
Menentukan apakah dengan adanya redudansi yang terkontrol dengan melonggarkan aturan normalisasi akan meningkatkan kinerja sistem. Misalnya,
57
mempertimbangkan duplikasi atribut atau join relasi bersama. Dokumentasi adanya redudansi.
Langkah 8
Mengawasi dan melakukan setting terhadap sistem operasi
Mengawasi sistem operasi dan meningkatkan kinerja sistem dalam membenarkan keputusan perancangan yang kurang tepat atau dalam mengatasi kemungkinan adanya perubahan.
2.6
Document Flowchart Document flowchart digunakan untuk merepresentasikan elemenelemen dari dari suatu sistem manual dalam gambar, contohnya meliputi : catatan akutansi, departemen yang terlibat dalam proses, dan aktivitas yang dilakukan pada departemen tersebut (Hall, 2008, p61). Document flowchart adalah bagan yang menggambarkan aliran dokumen dalam suatu sistem informasi. Berikut ini adalah simbol-simbol standar dengan maknanya masing-masing untuk melukiskan document flowchart suatu sistem (Mulyadi, 2001, p64) :
58
Table 2.1 Simbol document flowcchart Simbo ol
N Nama
Pen njelasan
Dookumen
Simbol ini digunakan d u untuk mengggambarkan seemua jenis dokuumen, yang merupakann formulir yang digunakan untuk mereekam data terjadinya suatu transaksi. Nama N dokum men dicantuumkan di teengah simbol
Dokkumen dan
Simbol inni digunakaan untuk menggambaarkan
tembbusannya
dokumen asli a dan tem mbusannya. Nomor lembar dokumen diicantumkan di sudut kannan atas.
Berbagai
Simbol inni digunakaan untuk menggambaarkan
dookumen
berbagai jennis dokumenn yang digabbungkan berrsama di dalam saatu paket. Nama N dokum men dituliskaan di dalam massing-masing simbol dann nomor lembar dokumen dicantumkan d di sudut kaanan atas simbol dokumen yaang bersangkutan
Pennghubung
Simbol pennghubung untuk u memuungkinkan aliran a
padaa halaman
dokumen berhenti b di suatu lokassi pada halaaman
yanng sama
tertentu dann kembali berjalan b di lokasi lain pada
(oon-page connnector)
halaman yaang sama.
59
Akhir arus
Akhir arus dokumen dan mengarahkan pembaca ke
dokumen
simbol penghubung halaman yang sama yang bernomor seperti yang tercantum di dalam simbol tersebut.
Awal arus
Awal arus dokumen yang berasal dari simbol
dokumen
penghubung halaman yang sama, yang bernomor seperti yang tercantum di dalam simbol tersebut.
Penghubung
Jika untuk menggambarkan bagan alir suatu sistem
pada halaman
diperlukan lebih dari satu halaman, simbol ini harus
yang berbeda
digunakan
(off-page connector)
untuk
menunjukkan
kemana
dan
bagaimana bagan alir terkait satu dengan lainnya. Nomor
yang
tercantum
di
dalam
simbol
penghubung menunjukkan bagaimana bagan alir yang tercantum pada halaman tertentu terkait dengan bagan alir yang tercantum pada halaman yang lain. Kegiatan
Simbol ini digunakan untuk menggambarkan
manual
kegiatan manual, seperti: menerima order dari pembeli,
mengisi
formulir,
membandingkan,
memeriksa dan berbagai jenis kegiatan klerikal yang
lain.
Uraian
singkat
dicantumkan di dalam simbol ini.
kegiatan
manual
60
Arsip
Simbol ini digunakan untuk menunjukkan tempat
sementara
penyimpanan dokumen, seperti almari arsip dan kotak arsip. Terdapat dua tipe arsip dokumen: arsip sementara dan arsip permanen. Arsip sementara adalah
tempat
penyimpanan
dokumen
yang
dokumennya akan diambil kembali dari arsip tersebut di masa yang akan datang untuk keperluan pengolahan lebih lanjut terhadap dokumen tersebut. Untuk menunjukkan urutan pengarsipan dokumen digunakan simbol berikut ini: A = menurut abjad N = menurut nomor urut T = kronologis, menurut tanggal Arsip
Simbol ini digunakan untuk menggambarkan arsip
permanen
permanen yang merupakan tempat penyimpanan dokumen yang tidak akan diproses lagi dalam sistem yang bersangkutan.
Keputusan
Simbol ini menggambarkan keputusan yang harus dibuat dalam proses pengolahan data. Keputusan yang dibuat ditulis di dalam simbol.
Garis alir
Simbol ini menggambarkan arah proses pengolahan
(flowline)
data. Anak panah tidak digambarkan jika arus dokumen mengarah ke bawah dan ke kanan. Jika
61
arus dokumen mengalir ke atas atau ke kiri, anak panah perlu dicantumkan. Mulai/berakhir Simbol ini untuk menggambarkan awal dan akhir (terminal)
2.7
suatu sistem.
Data Flow Diagram (DFD) Menurut Whitten (2004, p344), Data Flow Diagram adalah sebuah alat pemodelan yang digunakan untuk menggambarkan aliran data pada suatu sistem dan pekerjaan atau proses yang dilakukan oleh sistem. Sinonim dari data flow diagram adalah bubble chart, transformation graph, dan process model. Decomposition diagram, juga dikenal dengan hierarchy chart, adalah alat
yang
digunakan
untuk
menggambarkan
dekomposisi
sistem.
Decomposition diagram pada dasarnya adalah alat perencanaan untuk model proses yang lebih detail, yang disebut diagram aliran data. Context diagram adalah model proses yang menggambarkan hubungan dari sistem ke dunia bisnis dan dunia luar, termasuk sistem informasi yang lainnya. Notasi simbol pada data flow diagram pada umumnya terbagi menjadi dua notasi, yaitu : Yourdon/DeMarco DFD dan Gane&Sarson DFD. Berikut merupakan simbol-simbol yang terdapat pada Data Flow Diagram : a. Proses Proses adalah proses atau pekerjaan yang dilakukan oleh sistem sebagai respon terhadap aliran data masuk atau kondisi. Proses menggambarkan bagian dari sistem yang mengolah masukan
62
menjadi keluaran. Proses digambarkan dengan sebuah lingkaran pada
notasi
Yourdon/DeMarco
DFD,
sedangkan
proses
digambarkan dengan sebuah sistem persegi panjang bersudut tumpul pada notasi Gane&Sarson DFD.
Gambar 2.13 Simbol proses b. Aliran data Aliran menggambarkan perpindahan informasi (input dan output), ke dan dari proses tersebut. Aliran digambarkan dengan sebuah tanda panah. Awal panah menggambarkan asal data sedangkan arah panah menggambarkan tujuan.
Gambar 2.14 Simbol aliran data c. Penyimpanan data (Data store) Data store adalah penyimpanan data yang ditujukan untuk penggunaan selanjutnya. Sinonimnya adalah file dan database. Data store digambarkan dengan sebuah kotak dengan ujung terbuka.
Gambar 2.15 Simbol penyimpanan data
63
d. Agen eksternal Agen eksternal adalah orang, unit organisasi, atau organisasi luar yang berinteraksi dengan sistem. Disebut juga entitas eksternal. Agen eksternal digambarkan dengan sebuah persegi empat.
Gambar 2.16 Simbol agen eksternal
2.8
State Transition Diagram (STD) State transition diagram (STD) adalah suatu alat yang digunakan untuk menggambarkan urutan dan variasi dari layar yang dapat terjadi selama suatu sesi pengguna (Whitten, 2004, p673). Notasi yang digunakan dalam STD adalah : •
Kotak digunakan untuk menggambarkan layar tampilan.
•
Anak panah menggambarkan aliran dari kontrol dan kejadian yang memicu layar menjadi aktif atau menerima focus.
Suatu STD dapat menjadi cukup besar, terutama ketika semua input, output, help, dan layar-layar lainnya dimasukkan ke dalam diagram. Maka dari itu, umumnya diagram dipisah menjadi beberapa diagram yang lebih sederhana dan lebih mudah dibaca (Whitten, 2004, p674).
64
2.9
Teori Khusus
2.9.1
Defisini Penjualan Menurut Mulyadi (2001, p204), kegiatan penjualan terdiri dari penjualan barang atau jasa baik secara kredit maupun tunai. Penjualan menurut cara bayarnya dapat dibedakan sebagai berikut : 1) Penjualan tunai adalah penjualan yang dilaksanakan oleh perusahaan dengan cara mewajibkan pembeli dengan melakukan pembayaran harga barang terlebih dahulu sebelum barang diserahkan kepada pembeli. 2) Penjualan kredit adalah penjualan yang dilakukan dengan cara memenuhi pesanan dari pelanggan dengan mengirimkan barang atau menyerahkan jasa dan untuk jangka waktu tertentu perusahaan memiliki piutang kepada pelanggannya.
2.9.2
Defisini Pembelian Menurut Mulyadi (2001, p299), sistem pembelian digunakan dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan. Transaksi pembelian digolongkan menjadi dua yaitu pembelian lokal dan impor. Pembelian lokal adalah pembelian dari pemasok dalam negeri sedangkan pembelian impor adalah pembelian dari pemasok luar negeri.
65
2.9.3
Definisi Persediaan Menurut Mulyadi (2001, p553), sistem persediaan bertujuan untuk mencatat mutasi tiap jenis persediaan yang disimpan di gudang. Sistem ini berkaitan erat dengan sistem pembelian, sistem retur pembelian, dan sistem akutansi biaya produksi. Dalam perusahaan manufaktur, persediaan terdiri dari : persediaan produk jadi, persediaan produk dalam proses, persediaan barang, persediaan bahan penolong, persediaan bahan habis pakai pabrik, dan persediaan suku cadang.
