BAB 2 LANDAS AN TEORI
2.1
Teori Dasar 2.1.1
Data dan Basis Data Data adalah fakta – fakta atau observasi yang mentah, biasanya mengenai kejadian atau transaksi bisnis (James A. O’Brien, 2003, p13), sedangkan menurut Hoffer (2005), data adalah representasi objek yang disimpan dan kejadian-kejadian yang memiliki arti dan penting bagi user. M enurut Connolly (2005, p15), basis data adalah kumpulan data yang terhubung satu sama lain secara logikal, dan deskripsi data itu dirancang untuk memenuhi kebutuhan informasi dalam suatu organisasi, dan menurut Date (2000, p10) basis data adalah kumpulan data-data yang digunakan oleh sistem aplikasi dari perusahaan.
2.1.2
Database Management System Database Management System (DBM S) adalah sebuah sistem software yang memperbolehkan user untuk menggambarkan, membuat, menjaga, dan mengontrol akses ke basis data (Connolly, 2005, p16). Database Management System (DBM S) adalah suatu kumpulan data yang interelasi dan seperangkat program untuk mengakses data-data tersebut (Silberschatz, 2002, p1).
7
8 Fasilitas yang disediakan DBM S antara lain (Connolly, 2005, p16) : a. M emperbolehkan
user
untuk
mendefinisikan
data,
membuat
spesifikasi tipe data dan constraint pada data yang akan disimpan dalam basis data. Biasanya menggunakan Data Definition Language (DDL). Constraint adalah peraturan konsistensi nilai pada basis data yang tidak dapat dilanggar. b. M emperbolehkan user untuk menambah data, mengubah data, menghapus data, dan mengambil data dari basis data. Biasanya menggunakan suatu Data Manipulation Language (DM L). Bahasa yang umum digunakan adalah Structured Query Language (SQL). c. M enyediakan fungsi-fungsi untuk mengontrol akses ke basis data : i. Sistem keamanan (Security system), mencegah user yang tidak berwenang agar tidak mengakses ke basis data. ii. Sistem integritas (Integrity system), menjaga konsistensi data yang disimpan. iii. Sistem kontrol (Concurency control), mengijinkan agar data dapat dipakai bersama-sama oleh user lainnya. iv. Sistem kontrol perbaikan (Recovery control system), memperbaiki atau mengembalikan basis data ke kondisi sebelumnya jika terjadi kerusakan pada perangkat keras dan perangkat lunak. v. Katalog yang dapat diakses user (User-accessible catalog), catatan yang berisi deskripsi data pada basis data.
9 Database Application Program adalah suatu program komputer yang berinteraksi dengan basis data sesuai dengan permintaan DBM S (Connolly, 2005, p17).
Komponen lingkungan DBM S antara lain (Connolly, 2005, p18) : 1. Perangkat keras (hardware) Perangkat keras dapat berupa komputer tunggal personal, mainframe tunggal, hingga jaringan komputer. Perangkat keras dapat tergantung pada kebutuhan perusahaan dan DBM S yang digunakan. 2. Perangkat lunak (software) Program aplikasi yang digunakan biasanya adalah 3rd GL (third generation language), seperti C, C++, Java, Visual Basic, COBOL, Fortran, Ada, Pascal, atau bahkan 4th GL (fourth generation language) seperti SQL yang digabungkan pada 3rd GL. 3. Data (data) Data merupakan komponen yang paling penting dari lingkungan DBM S. Data berperan sebagai penghubung antara komponen mesin dengan komponen manusia. 4. Prosedur (procedure) Prosedur mengandung instruksi dan peraturan yang mengatur rancangan dan kegunaan basis data, seperti bagaimana masuk ke dalam DBM S,
menjalankan
dan
menghentikan
bagaimana membuat cadangan data dari basis data.
DBM S,
dan
10 5. M anusia (people) M anusia merupakan komponen terakhir yang terlibat langsung dengan sistem, termasuk di dalamnya adalah Database Administrator (DBA), perancang basis data pengembang aplikasi, dan pemakai akhir.
2.1.3
Data Definition Language Data Definition Language (DDL) adalah suatu bahasa yang memungkinkan DBA (Database Administrator) atau user untuk mendeskripsikan dan memberi nama entiti, atribut, dan relasi yang diperlukan untuk aplikasi, bersama dengan segala integritas dan batasan keamanan. Database Administrator adalah seseorang yang bertanggung jawab terhadap realisasi fisikal basis data, termasuk rancangan fisik basis data dan implementasi, keamanan dan kontrol integritas, maintenance sistem operasional, dan memastikan kepuasan performance aplikasi kepada user (Connolly, 2005, p40). Data Definition Language (DDL) adalah perintah-perintah yang digunakan untuk mendefinisikan sebuah basis data, termasuk membuat, mengubah, dan menghapus tabel dan memberikan batasan-batasannya (Hoffer, 2005, p291).
11 2.1.4
Data Manipulation Language Data Manipulation Language (DM L) adalah sebuah bahasa yang menyediakan sekumpulan operasi untuk mendukung operasi manipulasi data utama pada data di dalam basis data (Connolly, 2005, p40). Data Manipulation Language (DM L) adalah suatu bahasa yang memungkinkan user untuk mengakses dan memanipulasi data yang telah diorganisasikan oleh model data yang tepat (Silberschatz, 2002, p12). Data Manipulation Language (DM L) adalah suatu bahasa DBM S yang digunakan untuk membuat, membaca, mengubah, dan menghapus records (Whitten, 2004, p555).
Operasi manipulasi data antara lain (Connolly, 2005, p41) : a. M emasukkan data baru ke dalam basis data b. M odifikasi data yang disimpan dalam basis data c. M enampilkan kembali data di dalam basis data d. M enghapus data dari basis data
Terdapat dua tipe DM L (Connolly, 2005, p41), yaitu : 1. Procedural DM L, yaitu sebuah bahasa yang memberikan fasilitas kepada user untuk memberitahukan kepada sistem, data apa yang diperlukan dan bagaimana seharusnya data tersebut diambil. 2. Non-procedural DM L, yaitu sebuah bahasa yang memberikan fasilitas kepada user untuk menyatakan data apa yang diperlukan daripada tentang bagaimana data tersebut diambil.
12 2.1.5
Normalisasi Normalisasi adalah
sebuah
teknik
untuk
menghasilkan
sekumpulan relasi dengan properti yang diinginkan, yang akan memberikan kebutuhan data bagi perusahaan. Relasi adalah sebuah tabel dengan kolom dan baris (Connolly, 2005, p388). Normalisasi adalah proses standard untuk menentukan atribut mana yang akan dikelompokan bersama dalam sebuah relasi (Hoffer, 2005, p211).
Proses Normalisasi (Connolly, 2005, p401) : 1. First Normal Form (1NF) Sebelum memasuki tahap 1NF, status sebelum 1NF disebut dengan Unormalized Form (UNF), yaitu sebuah tabel yang mengandung satu atau lebih kelompok yang berulang. First Normal Form adalah sebuah relasi dimana persimpangan dari setiap baris dan kolom yang mengandung satu dan hanya satu nilai saja. 2. Second Normal Form (2NF) Sebuah relasi dimana 1NF dan setiap atribut non-primary-key harus bergantung secara fungsional pada primary key. Primary key adalah kandidat key yang dipilih untuk mengindentifikasi tuple secara unik pada sebuah relasi. Sedangkan tuple adalah baris pada sebuah relasi.
13 Proses normalisasi 1NF ke 2NF melibatkan penghilangan partial dependencies. Jika terdapat partial dependencies, maka atribut functionally
dependent
dari
relasi
akan
dihilangkan
dengan
menempatkannya pada sebuah relasi baru bersama dengan copy determinant mereka. Full functional dependency adalah suatu keadaan dimana jika A dan B adalah atribut, B full functionally dependent pada A jika B secara fungsional bergantung pada A, tetapi bukan subset dari A. 3. Third Normal Form (3NF) Sebuah relasi dimana bentuk 1NF dan 2NF, dimana tidak ada atribut yang bukan primary key secara transitif bergantung pada primary key. Transitive dependency adalah sebuah kondisi dimana A, B dan C adalah atribut dari relasi dimana A ke B dan B ke C, maka C adalah transitive dependency pada A melalui B. 4. Boyce-Codd Normal Form (BCNF) Sebuah relasi di dalam BCNF, jika dan hanya jika, setiap determinan adalah candidate key. Candidate key adalah superkey yang bukan merupakan subset dalam relasi. Superkey adalah sebuah atribut atau sekumpulan atribut yang secara unik mengindentifikasi sebuah tuple dalam sebuah relasi.
2.1.6
4th GL (Generation Language) 4GL adalah bahasa pemrograman yang tidak memiliki prosedur standard dimana user mendefinisikan apa yang harus diselesaikan, bukan
14 cara yang digunakan. User tidak mendefinisikan langkah-langkah yang dibutuhkan
program
untuk
mengerjakan
sebuah
tugas,
tetapi
mendefinisikan parameter bagi tools yang akan digunakan untuk menghasilkan sebuah program aplikasi (Connolly, 2005, p42).
4GL meliputi (Connolly, 2005, p42) : a. Presentation
languages, seperti query languages dan report
generators. b. Speciality languages, seperti spreadsheets dan sistem basis data languages. c. Application
generators
yang
mendefinisikan,
meng-insert,
mengupdate, dan me-retrieve data dari sistem basis data untuk membangun aplikasi. d. Bahasa-bahasa tingkat tinggi yang digunakan untuk menghasilkan kode aplikasi.
Salah satu contoh 4th GL adalah SQl (Structured Query Language) (Connolly, 2005, p42). SQL adalah sebuah bahasa yang dirancang menggunakan relasi untuk mengubah input ke dalam output yang diinginkan. SQL memiliki dua komponen utama yaitu : Data Definition
Language (DDL)
(Connolly, 2005, p113).
dan
Data
Manipulation
Language
15 Alasan SQL mudah dipelajari (Connolly, 2005, p114) : a. Bukan merupakan bahasa prosedural. b. SQL merupakan suatu bahasa berformat bebas dimana bagian dari perintahnya tidak harus diketikkan pada lokasi tertentu di layar. c. Struktur perintahnya terdiri atas standar kata-kata dalam bahasa Inggris seperti CREATE TABLE, INSERT, SELECT, dll. d. SQL dapat digunakan oleh user dalam berbagai tingkat, termasuk Database Administrator (DBA), management personnel, application developers, dan pengguna akhir lainnya.
Beberapa perintah SQL DM L adalah (Connolly, 2005, p117) : a. SELECT – untuk query data pada basis data. b. INSERT – untuk memasukkan data ke dalam tabel. c. UPDATE – untuk update data dalam tabel. d. DELETE – untuk menghapus data dalam tabel.
2.1.7
Siklus Hidup Basis Data Basis data merupakan komponen fundamental dalam suatu sistem informasi, penggunaan dan pengembangannya harus dilihat dari perspektif yang lebih luas berdasarkan kebutuhan perusahaan. M aka dari itu siklus hidup sistem informasi dari suatu perusahaan berhubungan erat dengan siklus hidup sistem basis data yang mendukung. Berikut ini adalah gambaran siklus hidup basis data :
16
Database Planning
System Definition
Requirement Collection and Analysis
Databas e Conceptual Database Design
Application Design
DBMS Selection Logical Databas e Design
Physical Database Design
Prototyping
Implementation
Data Conversion and Loading
T esting
Operational
Gambar 2.1 Gambar S iklus Hidup Basis Data
17 Berikut ini uraian dari masing-masing aktivitas pada siklus hidup basis data : a. Perencanaan Basis Data (Database Planning) M enurut Connolly & Begg (2005, p285-p286), perencanaan basis data (database planning) merupakan aktivitas manajemen yang mengijinkan tingkatan dari aplikasi basis data untuk direalisasikan seefisien
dan
seefektif
mungkin.
Database
planning
harus
diintegrasikan dengan keseluruhan strategi sistem informasi dari perusahaan. Tiga hal penting dalam merumuskan strategi informasi : 1. M engidentifikasi rencana dan tujuan dari perusahaan berikut menentukan sistem informasi yang diperlukan. 2. Evaluasi kelebihan dan kekurangan sistem informasi yang ada. 3. Penilaian
peluang penggunaan
teknologi
informasi
yang
menguntungkan. Langkah penting dari tahap ini adalah mendefinisikan secara jelas tentang pernyataan misi untuk proyek basis data. Pernyataan tersebut mendefinisikan tujuan utama dari aplikasi basis data. Bila pernyataan tersebut selesai maka langkah selanjutnya adalah mendefinisikan sasarannya. Pernyataan dan sasaran ini perlu didukung oleh informasi-informasi tambahan yang menentukan pekerjaan apa saja yang harus diselesaikan, sumber-sumber yang mendukung dan biaya yang harus dikeluarkan.
18 b. Definisi Sistem (System Definition) M enurut Connolly & Begg (2005, p286), definisi sistem (System Definition) adalah proses yang memaparkan jangkauan dan batasan dari aplikasi basis data dan pandangan-pandangan utama para pemakai. Sebelum mendesain suatu aplikasi basis data penting untuk terlebih dahulu mengidentifikasikan batasan-batasan dari sistem yang sedang diteliti dan bagaimana kaitannya dengan bagian lain sistem informasi perusahaan. Perlu dipikirkan untuk kebutuhan yang akan datang selain
dari keadaan
saat ini.
Dan tak
lupa untuk
mengidentifikasi pandangan pemakai yang merupakan aspek penting dari pengembangan aplikasi basis data karena membantu untuk memastikan bahwa tidak ada pemakai utama basis data yang terlupa ketika pengembangan aplikasi tersebut.
c. Analisa dan Pengumpulan Kebutuhan (Requirement Collection and Analysis) M enurut Connolly & Begg (2005, p288-p291), analisis dan pengumpulan kebutuhan (requirement collection and analysis) adalah sebuah proses pengumpulan dan analisis informasi tentang bagian dari perusahaan yang akan didukung oleh aplikasi basis data, dan menggunakan informasi ini untuk mengidentifikasi kebutuhan pemakai terhadap sistem baru.
19 Informasi yang dikumpulkan termasuk : 1. Penjabaran dari data yang digunakan, 2. Detail mengenai bagaimana data digunakan, 3. Kebutuhan tambahan apapun untuk aplikasi basis data yang baru. Informasi ini kemudian
dianalisis
untuk
mengidentifikasi
kebutuhan yang dimasukkan untuk aplikasi basis data yang baru tersebut.
Ada tiga macam pendekatan untuk mengatur kebutuhan dari sebuah aplikasi basis data dengan berbagai pemakai, yaitu : 1. Pendekatan Centralized Kebutuhan untuk tiap pandangan pemakai disatukan menjadi satu set kebutuhan untuk aplikasi basis data. Umumnya pendekatan ini dipakai jika basis datanya tidak terlalu kompleks. 2. Pendekatan View Integration Kebutuhan untuk tiap pandangan pemakai digunakan untuk membangun
sebuah
model
yang
terpisah
yang
menginterpretasikan tiap pandangan pemakai tersebut. Hasil datadata model tersebut kemudian disatukan di bagian desain basis data. 3. Kombinasi keduanya
20 d. Desain Basis Data (Database Design) M enurut Connolly & Begg (2005, p291), perancangan basis data (database design) merupakan proses pembuatan suatu desain untuk sebuah basis data yang akan mendukung operasional dan sasaran suatu perusahaan.
Ada dua pendekatan untuk merancang sebuah basis data, yaitu : 1. Pendekatan bottom-up Yang dimulai pada tingkat awal dari atribut (yaitu, property dari entitas dan relationship), yang mana melalui analisis dari asosiasi antar atribut, dikelompokkan menjadi hubungan yang merepresentasikan jenis-jenis entitas dan hubungan antar entitas. Pendekatan ini cocok untuk mendesain basis data yang simpel dengan jumlah atribut yang tidak banyak. 2. Pendekatan top-down M etode perancangan top-down adalah metode perancangan basis data dimana perancangan dimulai dari pengembangan model data yang awalnya mengandung beberapa entitas tingkat atau beserta relasi-relasi antara entitas tersebut. Kemudian dilakukan penyesuaian bertahap untuk mengidentifikasi entitas dengan tingkat lebih rendah, hubungan antar mereka, dan atribut-atribut yang dimilikinya. Pendekatan ini biasanya digambarkan melalui ER (Entity Relationship).
21 Pada tahap ini ada bagian yang disebut data modelling yang digunakan untuk membantu pemahaman dari data dan untuk memudahkan komunikasi tentang kebutuhan informasi. Dengan dibuatnya model data dapat membantu memahami : 1. Pandangan tiap pemakai mengenai data 2. Kealamian data itu sendiri, kebebasan representasi fisiknya 3. Kegunaan dari data berdasarkan pandangan pemakai
Kriteria untuk model data, yaitu : 1. Structural Validity Konsistensi dengan data yang didefinisikan perusahaan dan menyusun informasi. 2. Simplicity Kemudahan untuk pemahaman baik bagi yang profesional di bidang sistem informasi maupun pemakai yang non-teknis. 3. Expressibility Kemampuan untuk membedakan antara data yang berbeda dan hubungan antar data. 4. Nonredudancy Pembuangan informasi yang tidak ada hubungannya; khususnya representasi dari tiap potongan informasi tepatnya hanya sekali.
22 5. Shareability Tidak spesifik untuk aplikasi dan teknologi khusus apapun dan dengan demikian dapat digunakan oleh banyak orang. 6. Extensibility Kemampuan
mengembangkan
untuk
mendukung
kebutuhan baru dengan efek yang minimal bagi pemakai yang ada. 7. Integrity Konsistensi tehadap cara yang digunakan perusahaan dan mengatur informasi. 8. Diagramic Representation Kemampuan untuk merepresentasikan sebuah model menggunakan notasi diagram yang dapat dipahami dengan mudah. M enurut Connolly & Begg (2005, p435-p516), Database Design dibagi dalam tiga tahapan yaitu conceptual database design, logical database design, physical database design.
e. Pemilihan DBM S (DBMS Selection) M enurut Connolly & Begg (2005, p295-p296), pemilihan DBM S yang sesuai untuk mendukung aplikasi basis data yang mencakup : 1. M endefinisikan syarat-syarat referensi studi M enentukan sasaran, batasan masalah, dan tugas yang harus dilakukan.
23 2. M endaftar 2 atau 3 jenis barang M embuat daftar barang-barang, misalkan darimana barang ini didapat,
berapa
biayanya
serta
bagaimana
bila
ingin
mendapatkannya. 3. M engevaluasi barang Barang-barang yang ada dalam daftar diteliti lebih lanjut untuk mengetahui kelebihan dan kekurangan barang tersebut. 4. M erekomendasikan pilihan dan membuat laporan M erupakan langkah terkahir dari seleksi DBM S yaitu mendokumentasikan proses dan untuk menyediakan pernyataan mengenai kesimpulan dan rekomendasi terhadap salah satu produk DBM S.
f. Desain Aplikasi (Application Design) M enurut Connolly & Begg (2005, p299-p231), perancangan aplikasi (application design) adalah merancang antarmuka pemakai (user interface) dan program aplikasi yang akan memproses basis data. Ditinjau dari gambar 2.1 bahwa, perancangan basis data dan perancangan aplikasi adalah aktivitas bersamaan pada database application lifestyle. Dalam kasus sebenarnya, adalah tidak mungkin untuk menyelesaikan perancangan aplikasi sebelum perancangan basis data selesai. Dalam perancangan aplikasi harus memastikan semua pertanyaan fungsional dari spesifikasi kebutuhan pemakai (user requirement
24 spesification) yang menyangkut perancangan aplikasi program yang mengakses basis data dan merancang transaksi yaitu cara akses ke basis data dan perubahan terhadap isi basis data (retrieve, update, dan keduanya). Artinya bagaimana fungsi yang dibutuhkan bisa terpenuhi dan merancang antarmuka pemakai (user interface) yang tepat. Antarmuka yang dirancang harus memberikan informasi yang dibutuhkan dengan cara menciptakan ‘user friendly’. Kebanyakan antarmuka pemakai yang diabaikan akan niscaya membuat masalah. Bagaimanapun, antarmuka pemakai harus diakui sebagai komponen dari sistem yang penting, dimana agar mudah dipelajari dan mudah digunakan, sehingga pemakai akan cenderung memberdayagunakan informasi yang disajikan.
g. Prototyping M enurut Connolly & Begg (2005, p303-p304), prototyping adalah membuat model kerja dari aplikasi basis data, yang membolehkan perancangan atau user untuk mengevaluasi hasil akhir sistem, baik dari segi tampilan maupun fungsi yang dimiliki sistem. Tujuan dari pengembangan memungkinkan
prototype pemakai
aplikasi
basis
menggunakan
data
adalah
prototype
untuk untuk
mengidentifikasi keistimewaan sistem atau kekurangannya, dan memungkinkan perancangan untuk memperbaiki atau melengkapai keistimewaan (feature) dari aplikasi basis data baru.
25 Ada dua strategi prototyping yang umum digunakan sekarang, yaitu requirement prototyping
dan
evolutionary
prototyping.
Requirement prototyping adalah menggunakan prototype untuk menetapkan kebutuhan dari tujuan aplikasi basis data dan ketika kebutuhan sudah terpenuhi, prototype tidak digunakan lagi atau dibuang (discard). Sedangkan evolutionary prototyping menggunakan tujuan yang sama, tetapi perbedaan pentingnya adalah prototype tetap digunakan untuk selanjutnya dikembangkan menjadi aplikasi basis data yang bekerja.
h. Implementasi (Implementation) Implementation adalah realisasi fisikal dari desain basis data dan desain aplikasi (Connolly & Begg, 2005, p304). Dalam tahap ini juga akan diimplementasikan komponen lain dari aplikasi basis data seperti menu layar, pemasukan data, security dan kontrol integritas. Implementasi basis data dilakukan dengan menggunakan Data Definition Language (DDL) dari DBM S 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 (DM L), yang biasanya sudah terdapat dalam bahasa pemrograman.
26 i. Konversi dan Loading Data (Data Convertion and Loading) Data conversion and loading adalah suatu proses mentransfer data yang ada ke dalam basis data baru (Connolly & Begg, 2005, p305). Tahap ini hanya dibutuhkan ketika sistem basis data baru menggantikan sistem yang lama.
j. Pengujian (Testing) Testing adalah suatu proses mengeksekusi program aplikasi dengan tujuan untuk menemukan kesalahan (Connolly & Brgg, 2005, p305-p306). Jika pengujian berhasil, maka dapat menampilkan error dari program aplikasi dan struktur basis data. Testing memperlihatkan bahwa basis data dan program aplikasi bekerja sesuai dengan spesifikasinya dan menampilkan kebutuhan-kebutuhan untuk kerja yang memuaskan.
k. Operational Maintenance Operational maintenance adalah suatu proses memonitor dan memelihara sistem berdasarkan instalasi (Connolly & Begg, 2005, p306-p307). Tahapan ini terdiri dari dari aktivitas-aktivitas berikut : i. M emonitor untuk kerja sistem ii. M emelihara dan diperlukan)
memperbaharui aplikasi basis data (jika
27 2.1.8
Desain Konseptual, Logikal, dan Fisikal Basis Data M etodologi desain adalah sebuah pendekatan terstruktur yang menggunakan
prosedur,
teknik,
tool,
dan
dokumentasi
yang
mendukung dan memfasilitasi proses desain (Connolly, 2005, p438).
Dalam metodologi desain, proses desain dibagi ke dalam tiga tahapan utama, yaitu (Connolly, 2005, p439) : 1. Conceptual Database Design Adalah proses membangun model informasi yang digunakan perusahaan, yang tidak bergantung pada semua aspek fisikal. 2. Logical Database Design Adalah proses pembuatan sebuah model dari suatu informasi yang digunakan dalam sebuah perusahaan yang berdasarkan model data spesifik, tetapi bebas dari DBM S tertentu dan pertimbangan fisik lainnya. 3. Physical Database Design Adalah proses menghasilkan gambaran implementasi sistem basis data pada secondary storage. M enjelaskan relasi dasar (base relation), organisasi file, dan indeks yang digunakan untuk mengakses ke data yang efisien, dan integrity constraints yang berhubungan serta pengukuran keamanan.
28 2.1.8.1 Conceptual Database Design Langkah 1 : M embangun model data konseptual lokal untuk setiap view (Connolly, 2005,p422). Tujuannya untuk membangun sebuah model data konseptual dari perusahaan untuk setiap view yang spesifik.
Langkah 1.1 : Indentifikasi tipe entiti. Tujuannya adalah untuk mengidentifikasi entiti utama yang dibutuhkan oleh user. Langkah pertama dalam membangun suatu lokal konseptual
data
model
adalah
dengan
mendefinisikan objek utama atau entiti yang dibutuhkan oleh user. Salah satu metode untuk mengidentifikasi
tipe
entiti
adalah
dengan
mengidentifikasi kata benda yang dibutuhkan oleh user. Hasilnya adalah dokumentasi tipe entiti.
Langkah 1.2 : Identifikasi tipe relasi / relationship. Tujuannya adalah mengidentifikasi relasi yang penting diantara entity type.
29 Hasilnya adalah dokumentasi tipe relationship.
Langkah 1.3 : Identifikasi dan asosiasi atribut suatu entiti. Tujuannya adalah menghubungkan atribut dengan entiti atau tipe relationship yang sesuai.
Langkah 1.4 : Tentukan domain atribut. Tujuannya adalah menentukan domain untuk atribut pada model data konseptual. Attribute domain adalah sejumlah nilai yang diperkenankan untuk satu atau lebih atribut. Hasilnya adalah dokumentasi atribut domain.
Langkah 1.5 : Tentukan candidate key dan atribut primary key. Tujuannya adalah
mengidentifikasi
candidate
key(s) pada tiap-tiap entiti, jika candidate key lebih dari satu, maka dipilih satu primary key dan candidate keys yang lain menjadi alternate keys. Candidate key adalah super key dalam relasi. Super key adalah atribut atau himpunan atribut yang mengidentifikasi seara unik tuple-tuple yang ada
30 dalam relasi. Primary key adalah candidate key yang dipilih untuk mengidentifikasikan tuple secara unik dalam suatu relasi. Alternate key adalah candidate key yang tidak terpilih sebagai primary key.
Langkah 1.6 : M empertimbangkan penggunaan konsep enhanced modelling (langkah optional). Tujuannya adalah mempertimbangkan penggunaan konsep enhanced modelling seperti : specialization /
generalization,
aggregation,
ataupun
composition. Specialization adalah proses untuk memaksimalkan perbedaan antara anggota pada sebuah
entitas
dengan
mengidentifikasikan
perbedaan karakteristik mereka. Generalization adalah proses meminimalisasi perbedaan antara anggota
pada
sebuah
entitas
dengan
mengidentifikasi perbedaan karakteristik mereka. Aggregation adalah merepresentasi “has a” atau “is part of” relasi antara entitas dimana relasi “has a” merepresentasikan keseluruhan sedangkan relasi “is part of” merepresentasikan bagian dari. Composition
adalah
bentuk
spesifik
dari
31 aggregation
yang
merepresentasikan
sebuah
hubungan antar entitas.
Langkah 1.7 : M emeriksa model untuk redundansi. Tujuannya
adalah
mengecek
apakah
terjadi
redundansi data. Redundansi data adalah data yang berulang.
Langkah 1.8 : Validasi model konseptual lokal dengan transaksi user. Tujuannya adalah
memastikan bahwa model
konseptual mendukung transaksi-transaksi yang dibutuhkan.
Langkah 1.9 : Review model data konseptual dengan user. M eninjau kembali model data konseptual yang telah dibangun untuk memastikan bahwa model tersebut
sesuai
dengan
representasi
yang
sebenarnya dari persyaratan data yang dibutuhkan oleh perusahaan.
32 2.1.8.2 Logical Database Design Langkah 2 : M embuat dan memvalidasi model data logikal lokal untuk setiap view (Connolly, 2005, p462). Tujuannya adalah untuk membangun suatu model data logikal lokal yang merepresentasikan pandangan tertentu dari perusahaan dan kemudian memvalidasi model ini untuk memastikan strukturnya sudah benar (menggunakan teknik normalisasi) dan untuk memastikan bahwa model tersebut mendukung transaksi yang diminta.
Langkah 2.1 : M endapatkan relasi untuk model data logikal. Tujuannya adalah membuat relasi untuk model data
logikal
lokal
untuk
mewakili
entiti,
relationship, dan atribut yang telah diidentifikasi. Relasi-relasi yang didapat dari model data logikal yang ada pada model data konseptual : a. Strong
entity types
adalah
entitas
yang
keberadaannya tidak tergantung dengan entitas lain,
misalnya
entitas
staff,
cabang.
Karakteristik dari strong entity adalah setiap entitas dapat diidentifikasikan dengan primary key dari tipe entitas itu.
33 b. Weak
entity
types
adalah
entitas
yang
keberadaannya tergantung dari entitas lain. Karakteristik dari weak entity adalah atribut yang terdapat pada entitas tersebut tidak dapat mengidentifikasikan tipe entitas itu secara unik. c. One-to-many (1:*) binary relationship types adalah relasi dimana setiap entitas yang ada dapat mempunyai satu relasi atau lebih dar satu relasi dengan entitas yang lain. d. One-to-one (1:1) binary relationship types adalah relasi dimana setiap entitas yang ada hanya dapat mempunyai maksimal 1 relasi dengan entitas yang lain. e. One-to-one (1:1) recursive relationship types adalah relasi dimana setiap entitas yang ada sama pada kedua sisi. f. Superclass / subclass relationship types adalah relasi dimana superclass entity merupakan parent dari subclass entity sebagai child. g. Many-to-many (*:*) binary relationship type adalah relasi dimana setiap entitas dapat mempunyai lebih dari satu relasi dengan entitas lainnya.
34 h. Complex relationship types adalah sebuah relasi yang menghasilkan sebuah relasi untuk merepresentasikan relasi yang ada dan meliputi atribut-atribut yang menjadi bagian dari relasi tersebut. i. Multi-valued
attributes
adalah
merupakan
atribut yang mempunyai banyak nilai untuk setiap tipe entitas.
Langkah 2.2 : Validasi relasi menggunakan normalisasi. Tujuannya adalah untuk memvalidasi relasi pada model
data
logikal
lokal
menggunakan
normalisasi.
Langkah 2.3 : M elakukan validasi relasi terhadap transaksi yang dilakukan user. Tujuannya adalah untuk memastikan bahwa relasi pada model data logikal mendukung transaksitransaksi yang dibutuhkan oleh view.
35 Langkah 2.4 : M enentukan integrity constraint. Tujuannya adalah memeriksa integrity constraints yang direpresentasikan pada model data logikal. Integrity constraints adalah batasan-batasan yang digunakan agar kelengkapan, keakuratan, dan kekonsistensian sistem basis data terjaga dengan baik.
Tipe integrity constraints : 1. Required data Harus mengandung nilai valid (tidak boleh null). 2. Attribute domain constraint Setiap
atribut
harus
mempunyai
sebuah
domain, satu set nilai yang sah. 3. Entity integrity Primary key dari sebuah tabel harus unik dan tidak mengandung nilai null untuk setiap baris. 4. Referential integrity Sebuah foreign key menghubungkan tiap tuple pada relasi child ke tuple pada relasi parent yang mengandung nilai candidate key yang sama.
36 Referential integrity terdiri atas : a) NO ACTION M encegah parent dihapus b) CASCADE Jika parent dihapus maka child juga akan dihapus secara otomatis. c) SET NULL Jika parent dihapus, foreign key pada semua child akan di-set null. d) SET DEFAULT Jika parent dihapus, foreign key pada semua child akan di-set default. e) NO CHECK Jika parent dihapus, maka tidak akan melakukan
apa-apa untuk
memastikan
referential integrity dijaga. 5. General constraints Perubahan pada tabel mungkin dibatasi oleh aturan yang mengatur transaksi pada dunia nyata yang direpresentasikan oleh perubahan tersebut.
37 Langkah 2.5 : Review model data logikal lokal dengan user. Tujuannya adalah meninjau kembali model data logikal yang telah dibangun untuk memastikan bahwa model tersebut sesuai dengan representasi yang sebenarnya dari persyaratan data yang dibutuhkan oleh perusahaan.
Langkah 2.6 : M enggabungkan model-model data logikal yang ada menjadi model global (langkah optional). Tujuannya adalah menggabungkan model-model data logikal lokal menjadi sebuah model data logikal
global yang merepresentasikan views
sistem basis data bagi semua user.
Langkah 2.7 : Cek perkembangan di masa yang akan datang. Tujuannya adalah memperkirakan apakah akan terjadi perubahan yang signifikan di masa yang akan datang dan untuk menilai apakah model data logikal yang ada sekarang dapat mengikuti perubahan tersebut.
38 2.1.8.3 Physical Database Design Langkah 3 : M enerjemahkan model data logikal global terhadap DBM S yang telah ditentukan. Tujuannya adalah untuk menghasilkan skema relasional sistem basis
data
dari
model
data
logikal
sehingga
bisa
diimplementasikan pada DBM S yang dituju.
Langkah 3.1 : M erancang base relation. Tujuannya adalah untuk menentukan bagaimana merepresentasikan
base
relation
yang
telah
teridentifikasi pada model data logikal di DBM S yang dituju.
Langkah 3.2 : M erancang representasi dari data yang diturunkan. Tujuannya
adalah
menentukan
bagaimana
merepresentasikan derrived data yang terdapat pada model data logikal global ke dalam DBM S yang dituju.
39 Langkah 3.3 : M erancang general constraint. Tujuannya adalah merancang general constraint untuk DBM S yang dituju.
Langkah 4 : M erancang file organizations dan indexes (Connolly,2005,p501). Tujuannya adalah untuk menentukan file organizations yang optimal untuk menyimpan relasi dasar dan indexes yang dibutuhkan untuk mencapai performa yang dapat diterima, yaitu cara dimana relasi dan tuple disimpan dalam secondary storage.
Langkah 4.1 : M enganalisis transaksi. Tujuannya adalah untuk mengetahui fungsi-fungsi transaksi yang berjalan pada sistem basis data dan untuk
menganalisis
transaksi-transaksi
yang
penting.
Langkah 4.2 : M emilih file organizations. Tujuannya
adalah
untuk
mengetahui
organizations yang efisien untuk base relation.
file
40 Langkah 4.3 : M emilih indexes. Tujuannya adalah untuk menentukan apakah penambahan indexes akan meningkatkan performa sistem.
Langkah 4.4 : M emperkirakan besarnya tempat penyimpanan yang dibutuhkan. Tujuannya adalah untuk memperkirakan besarnya tempat penyimpanan yang dibutuhkan oleh sistem basis data.
Langkah 5 : M erancang user views (Connolly, 2005, p515). Tujuannya adalah untuk merancang user views yang telah teridentifikasi selama tahap requirements collection and analysis dari siklus pengembangan sistem basis data.
Langkah 6 : M erancang mekanisme keamanan (Connolly, 2005, p516). Tujuannya adalah untuk merancang mekanisme keamanan sistem basis data seperti yang dispesifikasikan oleh user selama tahap
41 requirements collection dari siklus pengembangan sistem basis data.
Langkah 7 : M empertimbangkan
penggunaan dari redundansi terkontrol
(Connolly,2005,p519). Tujuannya adalah
untuk
menentukan
apakah
penggunaan
redundansi terkontrol yang telah ternormalisasi akan dapat meningkatkan performa sistem.
Langkah 8 : M elakukan pengawasan dan pemeliharaan terhadap sistem operasi (Connoly,2005,p519). Tujuannya adalah meningkatkan
untuk
performa
mengawasi sistem operasi dan dari
sistem
untuk
memperbaiki
rancangan-rancangan yang kurang sesuai atau sebagai refleksi adanya perubahan kebutuhan. Ukuran efisiensi merancang database fisikal dalam penyimpanan data antara lain: i. Transaction throughput Jumlah transaksi yang dapat diproses dalam jangka waktu tertentu. ii. Waktu respon Waktu yang melengkapi transaksi tunggal.
42 iii. Tempat penyimpanan Jumlah
tempat
penyimpanan
yang
dibutuhkan
untuk
menyimpan file database.
2.1.9
Bagan Aliran Dokumen (Document Flowchart) M enurut M ulyadi (2001, p60) bagan alir dokumen (dokumen flowchart) digunakan untuk menggambarkan aliran dokumen dalam sistem tertentu.
Adapun simbol yang digunakan dalam bagan alir dokumen yaitu:
Tabel 2.1 Tabel Simbol Bagan Alir Dokumen Simbol
Nama
Keterangan
Dokumen
M enggambarkan semua jenis dokumen,
formulir
yang
digunakan untuk merekam data terjadinya suatu transaksi. Dokumen
dan M enggambarkan dokumen asli
2 1 Faktur
tembusannya
dan
tembusannya.
Nomor
lembar dokumen dicantumkan di sudut kanan atas.
43 Berbagai dokumen
M enggambarkan berbagai jenis
Surat jalan
dokumen yang digabungkan
SOP
bersama dalam satu paket. Faktur penjualan
Catatan
M engambarkan akuntansi untuk
catatan
yang
digunakan
mencatat
data yang
direkam sebelumnya di dalam dokumen Catatan
atau yang
formulir. digambarkan
dengan simbol ini adalah : jurnal, buku pembantu, dan buku besar. Penghubung
pada Karena
halaman yang sama halaman (on-page connector)
keterbatasan
ruang
kertas
untuk
menggambar, maka diperlukan simbol
penghubung
memungkinkan
untuk aliran
dokumen berhenti di suatu lokasi pada halaman tertentu dan kembali berjalan di lokasi lain pada halaman yang sama.
44 Penghubung
pada Jika
halaman
yang bagan
berbeda
untuk
menggambarkan
alir
suatu
sistem
(off-page akuntansi diperlukan lebih dari
connector)
satu halaman, simbol ini harus digunakan untuk menunjukkan kemana dan bagaimana bagan alir terkait satu dengan yang lainnya.
Kegiatan M anual
M enggambarkan
kegiatan
manual seperti : menerima order
pembeli,
mengisi
formulir Keterangan,
Untuk
menambahkan
komentar
keterangan guna memperjelas pesan yang disampaikan bagan alir.
Arsip sementara
M enunjukkan
tempat
penyimpanan dokumen, seperti almari arsip dan kotak arsip. Terdapat
dua
tipe
arsip
dokumen : arsip sementara dan arsip
permanen.
Arsip
45 sementara
adalah
tempat
penyimpanan dokumen yang dokumennya
akan
diambil
kembali dari arsip tersebut di masa yang akan datang untuk keperluan lanjut
pengolahan
terhadap
tersebut.
lebih
dokumen
Untuk pengurutan
pengarsipan
dokumen
digunakan simbol berikut ini : A = menurut abjad. N = menurut nomor urut. T
=
kronologis,
menurut
tanggal Arsip permanen
M enggambarkan permanen
yang
arsip merupakan
tempat penyimpanan dokumen yang tidak akan diproses lagi dalam sistem akuntansi yang bersangkutan. On-line process
computer
M enggambarkan
pengolahan
data dengan komputer secara online.
46 Keying
(typing, M enggambarkan
verifying)
data
ke
dalam
pemasukan komputer
melalui on-line terminal. Pita
magnetik M enggambarkan
(magnetic tape)
arsip
komputer yang berbentuk pita magnetik.
Online storage
M enggambarkan
arsip
komputer yang berbentuk online
(di
dalam
memory
komputer) Keputusan
M enggambarkan
keputusan
ya
yang harus dibuat dalam proses tidak
pengolahan data. Garis alir (flowline)
M enggambarkan arah proses pengolahan data. Anak panah tidak
digambarkan
jika
dokumen mengalir ke bawah dan ke kanan. M ulai / Berakhir
M enggambarkan
awal
dan
akhir suatu sistem akuntansi
47 2.1.10 State Transition Diagram (S TD) State Transition Diagram (STD) merupakan suatu alat bantu perancangan yang menggambarkan sifat ketergantungan waktu dari sistem (Yourdon, 1989, p259). Komponen utama yang digunakan dalam STD adalah : a. Keadaan sistem (System state) State merupakan suatu kumpulan keadaan atau atribut yang mencirikan suatu benda pada waktu atau kondisi tertentu. State disimbolkan dengan gambar kotak persegi panjang.
STATE
Gambar 2.2 S imbol State dalam S TD
b. Perubahan keadaan (Change of state) Perubahan
keadaan
digambarkan
dengan
menghubungkan dua keadaan yang berkaitan. Notasinya adalah : STATE
STATE
STATE
Gambar 2.3 Perubahan State
garis
panah
yang
48 Untuk melengkapi STD diperlukan dua komponen tambahan yaitu : 1. Kondisi (Condition), adalah sebuah sinyal yang menyebabkan perubahan keadaan dari state satu ke state berikutnya. 2. Aksi (Action), adalah yang dilakukan sistem bila terjadi perubahan keadaan.
Notasinya adalah :
STATE Kondisi Aksi STATE
Gambar 2.4 Notasi Kondisi dan Aksi
2.2
Teori Pendukung 2.2.1
Penjualan M enurut M ulyadi (2001, p202), kegiatan penjualan terdiri dari transaksi penjualan barang atau jasa, baik secara kredit maupun secara tunai. Dalam transaksi penjualan kredit, jika order dari pelanggan telah dipenuhi dengan pengiriman barang atau penyerahan jasa, untuk jangka waktu tertentu perusahaan memiliki
piutang kepada pelanggannya.
Kegiatan penjualan secara kredit ini ditangani oleh perusahaan melaui sistem penjualan kredit.
49 Dalam transaksi penjualan tunai, barang atau jasa baru diserahkan oleh perusahaan kepada pembeli jika perusahaan telah menerima kas dari pembeli. Kegiatan penjualan secara tunai ini ditangani oleh perusahaan melalui sistem penjualan tunai.
2.2.1.1 Fungsi yang Terkait dalam Penjualan Fungsi yang terkait dalam sistem penjualan kredit adalah (M ulyadi, 2001, p211) : 1. Fungsi Penjualan Fungsi ini bertanggung jawab untuk menerima surat order dari pembeli,
meng-edit order
dari pelanggan
untuk
menambahkan informasi yang belum ada pada surat order tersebut, meminta otorisasi kredit, menentukan tanggal pengiriman dan dari gudang mana barang akan dikirim, serta mengisi surat order pengiriman. Fungsi ini juga bertanggung jawab untuk membuat back order pada saat diketahui tidak tersedianya persediaan untuk memenuhi order dari pelanggan. 2. Fungsi Gudang Fungsi ini bertanggung jawab untuk menyimpan barang dan menyiapkan barang yang dipesan dari pelanggan, serta menyerahkan barang ke fungsi pengiriman. 3. Fungsi Pengiriman Fungsi ini bertanggung jawab untuk menyerahkan barang atas dasar surat order pengiriman yang diterimanya dari
50 fungsi penjualan dan juga menjamin bahwa tidak ada barang yang keluar dari perusahaan tanpa ada otorisasi dari yang berwenang. 4. Fungsi Penagihan Fungsi ini bertanggung jawab untuk membuat dan mengirimkan faktur penjualan kepada pelanggan, serta menyediakan copy faktur penjualan kepada pelangga, serta menyediakan copy faktur bagi kepentingan pencatatan transaksi penjualan oleh fungsi akuntansi. 5. Fungsi Akuntansi Fungsi ini bertanggung jawab untuk mencatat piutang yang timbul dari transaksi penjualan kredit dan membuat serta mengirimkan pernyataan piutang kepada para debitur, serta membuat laporan penjualan. Di samping itu, fungsi ini juga bertanggung jawab untuk mencatat harga pokok persediaan yang dijual ke dalam kartu persediaan.
2.2.2
Pembelian M enurut Render (2001,p414), pembelian adalah perolehan barang dan jasa. Secara umum, definisi pembelian adalah suatu usaha pengadaan barang dan jasa dengan tujuan yang akan digunakan sendiri, untuk kepentingan proses produksi maupun untuk dijual kembali.
51 2.2.2.1 Tujuan Pembelian Tujuan pembelian menurut Render (2001,p414), tujuan dari kegiatan pembelian adalah: a. M embantu identifikasi produk dan jasa yang dapat diperoleh secara eksternal. b. M engembangkan, mengevaluasi dan menentukan pemasok, harga dan pengiriman yang terbaik bagi barang dan jasa tersebut.
2.2.2.2 Jenis Transaksi Pembelian Jenis transaksi dalam pembelian dibedakan menjadi dua, yaitu: a. Pembelian tunai adalah proses pembayaran yang dilakukan secara langsung pada saat barang diterima b. Pembelian kredit adalah proses pembayaran yang tidak dilakukan
langsung pada saat barang diterima, tetapi
pembayaran dilakukan selang beberapa waktu setelah barang diterima sesuai dengan perjanjian kedua belah pihak.
2.2.2.3 Hal-hal yang Harus Diperhatikan dalam Proses Pembelian Hal-hal yang harus diperhatikan dalam proses pembelian adalah: a. Kualitas b. Harga
52 c. Waktu proses Pengawasan perlu dilakukan terhadap pelaksanaan proses pembelian ini, karena pembelian menyangkut investasi dana dalam persediaan dan kelancaran arus barang ke dalam perusahaan.
2.2.2.4 Fungsi yang Terkait dalam Sistem Pembelian M enurut M ulyadi(2001,p299) fungsi yang terkait dalam sistem pembelian adalah sebagai berikut: a. Fungsi gudang Bertanggung
jawab
untuk
memperoleh
informasi
mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang dan mengeluarkan order pembelian kepada pemasok yang dipilih. b. Fungsi pembelian Bertanggung
jawab
untuk
memperoleh
informasi
mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang, dan mengeluarkan order pembelian kepada pemasok yang dipilih. c. Fungsi penerimaan Bertanggung
jawab
untuk
melakukan
pemeriksaan
terhadap jenis, mutu, dan kuantitas bahan yang diterima dari pemasok guna menentukan dapat atau tidaknya barang tersebut diterima oleh perusahaan.
53 d. Fungsi akuntansi Bertanggung jawab dalam pencatatan transaksi pembelian yang menjadi hutang sebagai dokumen bukti kas keluar.
2.2.2.5 Prosedur Sistem Pembelian M enurut M ulyadi(2001,p301),
jaringan prosedur uang
membentuk sistem pembelian adalah sebagai berikut: 1. Prosedur Permintaan Pembelian Dalam prosedur ini fungsi gudang mengajukan permintaan pembelian dalam prosedur surat permintaan pembelian kepada fungsi pembelian. 2. Prosedur Permintaan Penawaran Harga dan Pemilihan Pemasok Fungsi penawaran
pembelian
mengirimkan
surat
permintaan
harga kepada pemasok
untuk
memperoleh
informasi mengenai harga barang dan berbagai syarat pembelian
yang lain
untuk
memungkinkan
pemilihan
pemasok yang akan ditunjuk sebagai pemasok barang yang diperlukan oleh perusahaan. 3. Prosedur Order Pembelian Fungsi pembelian mengirim surat order pembelian kepada pemasok yang dipilih dan memberitahukan kepada unit-unit lain dalam perusahaan mengenai order pembelian yang sudah dikeluarkan oleh perusahaan.
54 4. Prosedur Penerimaan barang Dalam prosedur ini fungsi penerimaan barang melakukan pemeriksaan mengenai jenis, kuantitas dan mutu bahan yang diterima
dari
pemasok,
kemudian
membuat
laporan
penerimaan barang untuk menyatakan penerimaan barang dari pemasok tersebut. 5. Prosedur Pencatatan Hutang Dalam prosedur ini akuntansi memeriksa dokumendokumen yang berhubungan dengan pembelian (surat order pembelian, laporan penerimaan barang, faktur dari pemasok) dan menyelenggarakan pencatatan hutang atau pengarsipan dokumen sumber sebagai catatan hutang. 6. Prosedur Distribusi Pembelian Prosedur ini meliputi distribusi rekening yang didebet dari transaksi pembelian untuk kepentingan pembuatan laporan manajemen.
