BAB 2 LANDASAN TEORI
2.1 Pendekatan Basisdata 2.1.1
Pengertian Teori - teori yang berkaitan dengan Basisdata Menurut Gerald V. Post (2005, p2) basisdata adalah koleksi penyimpanan data berdasarkan standar format yang dirancang agar bisa digunakan bersama – sama oleh user yang berbeda – beda. Menurut Ramakrishnan (2003, p4) basisdata adalah koleksi data, yang bertipikal penjelasan aktivitas dari satu atau lebih relasi organisasi. Menurut Atzeni, Paolo...[et al] (2003, p2) basisdata adalah koleksi data, yang digunakan untuk merepresentasikan informasi yang menarik ke dalam sistem informasi. Maka dari itu, kami menyimpulkan bahwa basisdata adalah koleksi data yang bertipikal penjelasan aktivitas dari satu atau lebih relasi organisasi yang dirancang agar bisa digunakan bersama – sama dan disimpan untuk kepentingan organisasi atau perusahaan.
2.1.2
DBMS DBMS (Database Management System) menurut Hoffer (2005, p7) adalah sistem yang digunakan untuk membuat, merawat, dan menyediakan kontrol akses untuk pengguna basisdata. DBMS menyediakan metode sistematik untuk pembuatan, updating, penyimpanan dan penerimaan data pada basisdata. DBMS juga menyediakan fasilitas untuk mengontrol akses
8
9 data, menguatkan integritas data, mengatur kontrol konkurensi, dan menyimpan basisdata. DBMS menurut Gerald V. Post (2005, p2) adalah yang menjelaskan basisdata, menyimpan data, mendukung bahasa query, memproduksi laporan, dan membuat layar data entry. DBMS menurut Atzeni, Paolo...[et al] (2003, p3) adalah sistem piranti lunak yang memungkinkan untuk mengatur koleksi data yang banyak, berbagi, dan persisten serta untuk memastikan reliabilitas dan privacy mereka. Seperti produk
yang lainnya, DBMS harus efisien dan efektif. Basisdata adalah
koleksi data yang diatur oleh DBMS. DBMS menurut Connolly (2005, p17) adalah suatu sistem piranti lunak yang memungkinkan user untuk mendefinisikan, membuat, merawat, dan mengontrol akses ke dalam basisdata. Menurut Connolly (2005, p18-20), DBMS memiliki lima komponen yang penting yaitu: 1. Hardware (perangkat keras) Dalam menjalankan aplikasi dan DBMS diperlukan perangkat keras. Perangkat keras dapat berupa a single personal computer, single mainframe, komputer jaringan berupa server. 2. Software (piranti lunak) Komponen piranti lunak meliputi DBMS software dan program aplikasi beserta Sistem Operasi (OS), termasuk piranti lunak tentang jaringan bila DBMS digunakan dalam jaringan seperti LAN.
10 3. Data Data mungkin merupakan komponen terpenting dari DBMS khususnya sudut pandang dari end user mengenai data. 4. Prosedur Prosedur berupa panduan dan instruksi dalam membuat desain dan menggunakan basisdata. Pengguna dari sistem dan staff dalam mengelola basisdata membutuhkan prosedur dalam menjalankan sistem dan mengelola basisdata itu sendiri. Demikian prosedur di dalam basisdata dapat berupa: login di dalam basisdata, penggunaan sebagian fasilitas DBMS, cara menjalankan dan memberhentikan DBMS, membuat salinan backup basisdata, memeriksa hardware dan software yang sedang berjalan, mengubah struktur basisdata, meningkatkan kinerja atau membuat arsip data pada secondary storage. 5. Manusia Komponen terakhir yaitu manusia sendiri yang terlibat dalam sistem tersebut. Dalam proses penggunaannya DBMS menurut Connolly (2005, p26) memiliki keuntungan dan kerugian. Keuntungan dari DBMS, antara lain: 1. Kontrol terhadap pengulangan data 2. Data yang dihasilkan konsisten 3. Pada beberapa data yang sama maka akan semakin banyak informasi yang diperoleh 4. Data dapat dipakai secara bersama - sama
11 5. Meningkatkan integritas data 6. Meningkatkan keamanan 7. Penetapan standarisasi 8. Perbandingan skala ekonomi 9. Mengatasi konflik kebutuhan 10. Memperbaiki pengaksesan data 11. Meningkatkan produktivitas 12. Memperbaiki pemeliharaan data melalui data yang tidak tergantung dengan data yang lain 13. Memperbaiki pengaksesan data secara bersama-sama 14. Memiliki backup data Kerugian dari penggunaan DBMS, antara lain: 1. Memiliki sistem yang kompleks 2. Karena sistem yang kompleks mengakibatkan DBMS memiliki ukuran yang semakin besar 3. DBMS memiliki harga yang bervariasi tergantung dari fungsi dan kebutuhan 4. Penambahan biaya untuk perangkat keras yang dibutuhkan 5. Penambahan biaya konversi 6. Karena DBMS dirancang untuk mengakses lebih dari satu aplikasi sehingga performansinya menurun 7. Kegagalan DBMS mengakibatkan operasi tidak dapat berjalan
12 2.1.3
DDL (Data Definition Language) Definisi dari Data Definition Language menurut Connolly (2005, p40) adalah suatu bahasa yang memperbolehkan Database Administrator (DBA) atau user untuk mendeskripsikan nama dari suatu entity, atribut, dan relasi data yang diminta oleh aplikasi, bersamaan dengan integritas data dan batasan keamanan datanya.
2.1.4
DML (Data Manipulation Language) DML menurut Gerald V. Post (2005, p146) adalah sebuah rangkaian dari perintah-perintah yang digunakan untuk mengakses data. Contohnya Command Insert, Delete, dan Update. DML menurut Connolly (2005, p40) adalah suatu bahasa yang memberikan fasilitas pengoperasian data yang ada di dalam basisdata. Pengoperasian data yang akan dimanipulasi biasanya meliputi: 1. Penambahan data baru ke dalam basisdata. 2. Modifikasi data yang disimpan ke dalam basisdata. 3. Pemanggilan data yang terdapat di dalam basisdata. 4. Penghapusan data dari basisdata. Sedangkan definisi Procedural DML menurut Connolly (2005, p41) adalah suatu bahasa yang memperbolehkan user untuk mendeskripsikan ke sistem data apa yang dibutuhkan dan bagaimana mendapatkan data tersebut secara persis.
2.1.5
4GLs 4GLs atau Fourth-Generation Languages menurut Connolly (2005, p42) adalah bahasa generasi tingkat empat. Tidak ada konsensus tentang apa
13 itu 4th GLs, ditujukan untuk bahasa pemrograman yang sederhana suatu operasi yang membutuhkan banyak baris dalam bahasa generasi tingkat tiga (3th GLs), seperti COBOL, biasanya membutuhkan hanya 10-20 baris dalam 4th GLs. Dibandingkan dengan 3th GLs yang membutuhkan prosedur, pada 4th GLs tidak diperlukan lagi dan pengguna bisa menentukan apa saja yang harus dilakukan. 4th GLs diharapkan dapat memudahkan penggunaannya pada tingkat komponen yang lebih tinggi seperti tools generasi ke-4. Para pengguna tidak mengharapkan
untuk
mendefinisikan
langkah
suatu
program
untuk
melaksanakan suatu tugas, tetapi lebih mendefinisikan parameter untuk tools yang mana untuk menciptakan suatu program aplikasi. 4th GLs diyakini dapat mengembangkan produktivitas dalam batasan jenis masalah yang bisa diatasi oleh 4th GLs: -
Presentasi bahasa, seperti query language and report generator
-
Bahasa khusus, seperti spreadsheets dan database language
-
Aplikasi
generator
yang
dapat
mendefinisikan,
menyisipkan,
memperbaharui, dan membuka kembali data dari suatu basisdata untuk membuat suatu aplikasi. 2.1.6
Database System Development Lifecycle Perancangan basisdata dilakukan berdasarkan bagan siklus basisdata, yang terdiri dari :
14
Database Planning
System Definition
Requirements Collection and Analysis
Database Design
DBMS Selection (Optional)
Conceptual Database Design
Application Design
Logical Database Design Physical Database Design
Prototyping (optional)
Implementation
Data Conversion and Loading Testing
Operational Maintenance Gambar 2.1 Database System Development Lifecycle Connolly (2005, p284)
15 2.1.6.1
Database Planning Menurut Connolly (2005, p285), database planning adalah aktivitas manajemen yang memungkinkan tahapan dari database system development lifecycle direalisasikan seefektif dan seefisien mungkin. Database planning harus diintegrasikan dengan strategis IS secara keseluruhan dari organisasi. Tiga pokok utama dalam memformula IS strategi meliputi:
Mengidentifikasi rencana dan tujuan perusahaan dengan program yang dibutuhkan sistem informasi.
Mengevaluasi arus sistem informasi untuk menentukan kelebihan dan kekurangannya.
Berharap dengan IT dapat mengambil keuntungan dalam persaingan dengan perusahaan lain. Metodologi yang digunakan untuk mengatasi hal tersebut diatas
adalah: •
Database planning – Mission Statement Mission statement untuk database project mendefinisikan tujuan utama dari aplikasi basisdata. Mengarahkan database project, biasanya mendefinisikan perintah tugas (Mission Statement). Mission statement biasanya membantu menjelaskan kegunaan dari database project dan menyediakan alur yang lebih jelas untuk mencapai efektivitas dan efisiensi penciptaan dari suatu basisdata yang diinginkan.
16 •
Database Planning – Mission Objective Ketika mission statement telah didefinisikan, maka mission objectives didefinisikan. Setiap objectives (tujuan) harus mengidentifikasikan tugas khusus yang harus didukung oleh basisdata. Dapat juga disertai dengan
beberapa
informasi
tambahan
yang
menspesifikasikan
pekerjaan yang harus diselesaikan, sumber daya yang digunakan, dan biaya yang untuk membayar kesemuanya itu. Database planning juga harus menyertakan pengembangan standar – standar yang menentukan:
2.1.6.2
•
Bagaimana data akan dikumpulkan,
•
Bagaimana menspesifikasikan format / bentuk data,
•
Dokumentasi penting apakah yang akan diperlukan,
•
Bagaimana desain dan implementasi harus dilakukan.
System Definition System definition mendeskripsikan jangkauan dan batas aplikasi basisdata dan gambaran user utama. Sebelum
merancang
aplikasi
basisdata,
maka
harus
mengidentifikasikan batasan dari sistem dan bagaimana sistem tersebut berinteraksi dengan bagian lain dari sistem informasi perusahaan. Batasan sistem tidak hanya mencakup pengguna dan area aplikasi saat ini, namun juga harus mencakup pengguna dan aplikasi mendatang.
17 2.1.6.3
Requirements Collection and Analysis Requirements
collection
and
analysis
merupakan
tahapan
pengumpulan dan analisis dari kebutuhan - kebutuhan user dan area aplikasi. Tahapan ini meliputi pengumpulan dan analisis informasi mengenai bagian dari perusahaan yang akan menggunakan basisdata. Informasi dikumpulkan untuk setiap user view (yaitu peran jabatan atau area aplikasi perusahaan) mencakup:
Deskripsi data yang digunakan.
Rincian mengenai bagaimana data digunakan atau dihasilkan.
Kebutuhan tambahan lainnya untuk aplikasi basisdata yang baru. Informasi
-
informasi
ini
kemudian
dianalisa
untuk
mengidentifikasikan kebutuhan atau fitur yang akan disertakan dalam aplikasi basisdata. Ada tiga pendekatan yang dapat digunakan untuk mengelola kebutuhan aplikasi basisdata dengan banyak user view yaitu : •
Centralized approach: kebutuhan dari setiap user view digabung menjadi serangkaian kebutuhan tunggal dari aplikasi basisdata.
•
View integration approach: Kebutuhan dari setiap user view digunakan untuk membuat model data terpisah untuk merepresentasikan user view tersebut. Model data - model data tersebut nantinya akan digabung pada tahapan database design.
•
Kombinasi dari dua pendekatan di atas.
18 2.1.6.4
Database Design Pendekatan dalam desain database: •
Top Down Diawali dengan pembentukan model data yang berisi beberapa entity high level dan relationship, yang kemudian menggunakan pendekatan
top
down
secara
berturut
–
turut
untuk
mengidentifikasikan entity lower level, relationship dan atribut lainnya. •
Bottom Up Dimulai dari atribut dasar (yaitu, sifat – sifat entity dan relationship), dengan analisis dari penggabungan antar atribut, yang dikelompokkan kedalam suatu relasi yang merepresentasikan tipe dari entity dan relationship antar entity.
•
Inside Out Berhubungan dengan pendekatan bottom up tetapi sedikit berbeda dengan identifikasi awal entity utama dan kemudian menyebar ke entity, relationship, dan atribut terkait lainnya yang lebih dulu diidentifikasi.
•
Mixed Menggunakan pendekatan bottom up dan top down untuk bagian yang berbeda sebelum pada akhirnya digabungkan.
19 Perancangan basisdata terdiri dari tiga fase utama yaitu perancangan basisdata konseptual, perancangan basisdata logikal, dan perancangan basisdata fisikal.
Perancangan
Basisdata
Konseptual
merupakan
proses
dalam
membangun suatu model informasi yang digunakan di dalam perusahaan, di mana proses tersebut tidak tergantung oleh semua pertimbangan fisikal.
Perancangan Basisdata Logikal merupakan proses dalam membangun suatu model informasi yang digunakan di dalam perusahaan, proses tersebut tidak tergantung oleh suatu DBMS dan pertimbangan fisikal tertentu, tetapi berdasarkan pada model data spesifik yang diperlukan.
Perancangan Basisdata Fisikal merupakan proses dalam menghasilkan suatu uraian implementasi basisdata pada penyimpanan sekunder; dimana proses tersebut menguraikan hubungan dasar, organisasi file, dan indeks - indeks yang digunakan untuk mencapai akses data secara efisien.
2.1.6.5
DBMS Selection (optional) Menentukan DBMS mana yang dapat digunakan sesuai dengan aplikasi yang ditentukan. Langkah - langkah utama untuk memilih suatu DBMS: 1. Mendefinisikan kriteria berdasarkan spesifikasi kebutuhan pemakai. 2. Menentukan beberapa produk DBMS. 3. Mengevaluasi produk - produk tersebut. 4. Merekomendasikan produk DBMS tersebut.
20 2.1.6.6
Application Design Langkah ini melakukan perancangan layar atau tampilan untuk user. Dalam merancangan user interface dan program aplikasi, langkah ini menggunakan proses basisdata yang mengaju pada petunjuk perancangan user interface seperti pemilihan judul, penulisan intruksi - intruksi menggunakan format yang standar sehingga mudah dipahami, pemakaian warna yang konsisten dan sebagainya. Dua aspek dalam application design, yaitu : •
Transaction Design Transaksi adalah satu aksi atau serangkaian aksi yang dilakukan oleh user tunggal atau program aplikasi, yang mengakses atau merubah isi dari basisdata. Kegunaan dari desain transaksi adalah untuk menetapkan dan keterangan karakteristik high level dari suatu transaksi yang dibutuhkan pada basisdata, diantaranya:
data yang akan digunakan oleh transaksi
karakteristik fungsional dari suatu transaksi
output transaksi
keuntungan bagi user
tingkat kegunaan yang diharapkan
Terdapat tiga tipe transaksi, yaitu:
Retrieval
transaction,
(retrieve)
data
digunakan
untuk
menghasilkan suatu laporan
untuk
ditampilkan
di
pemanggilan layar
atau
21
Update transaction, digunakan untuk menambahkan record baru menghapus record lama, atau memodifikasi record yang sudah ada didalam basisdata.
Mixed transaction, meliputi pemanggilan dan perubahan data.
•
User Interface design Beberapa aturan pokok dalam pembuatan user interface:
Meaningful title, diusahakan pemberian nama suatu form cukup jelas menerangkan kegunaan dari suatu form / report.
Comprehensible instructions, penggunaan terminologi yang familiar untuk menyampaikan instruksi ke user dan jika informasi tambahan diperlukan, maka harus disediakan helpscreen.
Logical grouping and sequencing of fields, fields yang saling berhubungan ditempatkan pada form / report yang sama. Urutan field harus logis dan konsisten.
Visually appealing layout of the form / report, tampilan form / report harus menarik, dan sesuai dengan hardcopy agar konsisten.
Familiar field labels, penggunaan field yang familiar.
Consistent terminology and abberviation, terminologi dan singkatan yang digunakan harus konsisten.
Consistent use of color, penggunaan warna seharusnya bisa digunakan untuk meningkatkan kejelasan dari sebuah form /
22 report dan untuk membedakan field - field yang penting atau pesan - pesan penting.
Visible space and boundaries for data-entry fields, jumlah tempat yang disediakan untuk data entry harus diketahui oleh user.
Convenient cursor movement, user dapat dengan mudah menjalankan
operasi
yang
diinginkan
dengan
menggerakkan kursor pada form / report.
Error correction for individual characters and entire fields, user dapat dengan mudah menjalankan operasi yang diinginkan dan melakukan perubahan terhadap nilai fields.
Error messages for unacceptable values, jika user mencoba untuk memasukkan data yang salah ke dalam sebuah field, maka akan muncul pesan kesalahan (error message).
Optional fields market clearly, optional field harus jelas diidentifikasikan untuk user.
Explanatory messages for fields, ketika user meletakkan kursor pada suatu field, maka keterangan mengenai field tersebut harus dapat dilihat.
Completion signal, indikator yang menjelaskan bahwa suatu proses telah selesai dilaksanakan.
2.1.6.7
Prototyping (optional) Langkah
ini
kita
mengizinkan
perancang
dan
user
untuk
memvisualisasikan dan mengevaluasi gambaran sistem secara menyeluruh.
23 Seperti yang kita ketahui, tujuan utama dalam mengembangkan suatu aplikasi basisdata prototype adalah untuk mengizinkan para pemakai untuk menggunakan prototype, sehingga pemakai dapat mengidentifikasikan fitur sistem, apakah sistem sudah bekerja dengan baik atau belum. Jika memungkinkan, pemakai dapat memberikan saran untuk mengadakan perbaikan atau bahkan fitur baru dalam aplikasi basisdata tersebut. Keuntungan prototype adalah relatif murah dan proses pembuatannya yang cepat. Terdapat dua macam strategi prototyping yang digunakan saat ini, yaitu: •
Requirements prototyping, menggunakan prototype untuk menentukan kebutuhan dari usulan sistem basisdata yang diinginkan dan ketika kebutuhan itu terpenuhi maka prototype akan dibuang.
•
Evolutionary prototyping, digunakan untuk tujuan yang sama. Perbedaannya, prototype tidak dibuang tetapi dengan pengembangan lanjutan menjadi aplikasi basisdata yang digunakan.
2.1.6.8
Implementation Membuat eksternal, konseptual, dan definisi basisdata internal dan program aplikasinya. Implementasi basisdata dilakukan dengan menggunakan Data Definition Language (DDL) dari DBMS yang terpilih. Bagian dari program
ini
merupakan
transaksi
-
transaksi
basisdata
diimplementasikan menggunakan Data Manipulation Language (DML).
yang
24 2.1.6.9
Data Conversion and Loading Memindahkan data dari sistem yang lama ke sistem yang baru. Langkah ini dibutuhkan hanya pada waktu sistem basisdata yang lama digantikan dengan sistem basisdata yang baru. Suatu DBMS mempunyai kegunaan memasukkan file kedalam basisdata yang baru dan kemudian secara otomatis mengubah data kedalam format yang diperlukan oleh file basisdata yang baru. Jika bisa diterapkan, pengembang dapat mengubah dan menggunakan program aplikasi dari sistem yang lama untuk digunakan oleh sistem yang baru.
2.1.6.10
Testing Langkah ini adalah mengadakan testing terhadap aplikasi basisdata dengan tujuan untuk melihat apakah masih ada kesalahan dan memvalidasi sesuai dengan keinginan user. Pengujian ini dilakukan dengan pengujian yang direncanakan dengan hati - hati berdasarkan data yang realistis.
2.1.6.11
Operational Maintenance Setelah aplikasi basisdata diimplementasikan dan diuji secara penuh, maka sistem akan terus di-monitor dan dipelihara secara kontiniu. Kegiatan kegiatan pemeliharaan tersebut dilaksanakan dalam beberapa tahap berikut:
Me-monitor kemampuan dari sistem. Jika kemampuan berada dibawah tingkatan standar, perbaikan atau reorganisasi basisdata diperlukan.
Memelihara dan meningkatkan aplikasi basisdata (apabila dibutuhkan). Kebutuhan baru disatukan ke dalam aplikasi basisdata melalui tahap tahap sebelumnya dari siklus hidup.
25 2.1.7
Tahap - tahap Perancangan Basisdata Dalam perancangan basisdata ada tiga tahapan - tahapan yang diperlukan guna mendapatkan sebuah basidata yang diinginkan, yaitu: perancangan konseptual, logikal, dan fisikal basisdata. Dan menurut Connolly (2005, p440), setiap konsep tersebut memiliki beberapa langkah yang perlu ditempuh, antara lain:
2.1.7.1
Perancangan Konseptual Perancangan konseptual menurut Gerald V. Post (2005, p32) menggambarkan tentang user view pada sistem. Model implementasi menggambarkan jalannya aliran data yang akan disimpan. Tujuan dari perancangan konseptual basisdata menurut Connolly (2005, p293) adalah untuk memproses pembuatan suatu model dari informasi yang akan digunakan dalam suatu organisasi, yang tidak tergantung pada segala pertimbangan fisikal. Langkah 1: Membuat data konseptual lokal untuk setiap bagian Tujuan dari langkah ini adalah untuk membangun suatu model data konseptual dari perusahaan untuk setiap view yang spesifik. Langkah 1.1: Mengidentifikasikan tipe entity Langkah 1.2: Mengidentifikasi tipe relasi Langkah 1.3: Mengidentifikasikan dan Mengasosiasikan atribut suatu entity atau tipe relasi Langkah 1.4: Menentukan domain atribut Langkah 1.5: Menentukan candidate dan primary key Langkah 1.6: Menggunakan Enhanced Modelling Concepts (langkah optional)
26 Langkah 1.7: Memeriksa redundansi Langkah 1.8: Validasi model konseptual lokal dengan transaksi user Langkah 1.9: Me-review model data konseptual lokal dengan user Berikut ini adalah detail mengenai langkah - langkah yang telah disebutkan di atas, antara lain: Langkah 1.1: Mengidentifikasikan tipe entity Dalam membangun suatu model data konseptual lokal adalah untuk mendefinisikan objek utama di mana user memang membutuhkannya. Salah satu metode untuk mengidentifikasi tipe entity yang utama adalah dengan mengidentifikasi kata benda atau frase kata benda yang telah disebutkan oleh user. Sebagai contoh: staffNo, name, propertyNo, address, rent, rooms. Anda juga dapat melihat objek seperti orang, tempat, hobby, tidak termasuk kata benda yang mendefinisikan kualitas dari objek lain. Sebagai contoh, Anda dapat mengelompokkan staffNo dan name dengan sebuah objek atau entity yang disebut Staff dan mengelompokkan propertyNo, address, rent, dan rooms menjadi suatu entity yang disebut PropertyForRent. Tabel 2.1 Tabel Kamus Data (Connolly, 2005, p444) Nama Entity Staff
Deskripsi Menjelaskan tentang setiap karyawan yang bekerja di DreamHome
Alias / Nama Lain Karyawan
Occurence Tiap karyawan bekerja pada salah satu cabang
27 Langkah 1.2: Mengidentifikasi tipe relasi Tujuan dari langkah ini adalah untuk mengidentifikasi relasi yang penting antara berbagai tipe entity yang telah diidentifikasikan. Biasanya, relasi diidentifikasi dengan menggunakan kata kerja atau frase kata kerja. Sebagai contoh:
Staff Manages PropertyForRent
PrivateOwner Owns PropertyForRent
PropertyForRent Associated With Lease
Relasi yang paling umum adalah relasi binary. Artinya relasi antar entity yang persis antara dua entity saja. Bagaimanapun Anda harus memperhatikan relasi yang komplek yang melibatkan lebih dari dua entity dan relasi rekursif yang hanya melibatkan hanya satu entity. Adapun langkah - langkah dalam mengidentifikasi tipe relasi adalah sebagai berikut:
Gunakan Entity–Relationship (ER) Diagram Hal yang sering terjadi adalah Anda akan lebih cepat mengerti suatu perancangan basisdata yang tervisualisasikan dibandingkan dengan perancangan basisdata yang dituliskan dalam bentuk tekstual. Anda dapat menggunakan Entity-Relationship (ER) diagram untuk mempresentasikan entity dan bagaimana relasi antar entity. Anda disarankan menggunakan Entity-Relationship (ER) diagram untuk membantu Anda membuat gambaran besar dari perancangan basisdata yang sedang Anda kembangkan.
28
Tentukan pembatas multiplicity dari tipe relasi Setelah Anda mempunyai relasi antara entity maka langkah berikutnya adalah Anda dapat menentukan multiplicity setiap relasi. Jika memang ada suatu nilai yang spesifik dari suatu multiplicity maka akan lebih baik apabila didokumentasikan.
Memeriksa Fan dan Chasm Traps Setelah Anda mendefinisikan relasi yang dibutuhkan antar entity maka langkah berikutnya adalah Anda dapat memeriksa fan dan chasm traps. Definisi dari fan traps adalah suatu model yang merepresentasikan suatu relasi antara entity. Tetapi alur relasinya memperlihatkan ambiguitas. Definisi dari chasm traps adalah suatu model di mana ada hubungan antara entity yang satu dengan entity yang lain, tetapi tidak ada relasi antara kedua entity yang utama.
Memeriksa setiap entity mempunyai relasi minimal satu Pada saat Anda membuat Entity-Relationship (ER) diagram, pastikan setiap entity mempunyai minimal satu relasi dengan entity yang lain. Jika memang ada entity yang sudah mempunyai minimal satu relasi dengan entity yang lain maka langkah berikutnya adalah perhatikan kamus datanya. Apabila memang sudah mempunyai relasi semua, maka berarti Anda telah membuat setiap entity mempunyai relasi.
29 Langkah 1.3: Mengidentifikasikan dan Mengasosiasikan atribut suatu entity atau tipe relasi Tujuan dari langkah ini adalah untuk mengidentifikasikan dan mengasosiasikan atribut dari entity atau tipe relasi.
Simple / Composite Attributes Perlu diperhatikan apakah suatu atribut tersebut, itu simple atau composite. Composite Attributes adalah atribut yang membangun dari simple attributes. Sebagai contoh, atribut alamat bisa saja dibuat simple dan menyimpan beberapa detail dari alamat sebagai suatu nilai, contoh: Dumbarton Road, Glasgow, G116YG. Bagaimanapun juga, atribut alamat dapat juga merepresentasikan sebuah composite attributes, yang terdiri dari beberapa detail yang mempunyai nilai terpisah dalam atribut street (”115 Dumbarton Road”), city (”Glasgow”), dan postcode (”G116YG”). Atribut alamat dapat dijadikan simple attributes atau composite attributes tergantung dengan kebutuhan user. Jika user tidak membutuhkan detail dari atribut alamat seperti nama jalan, kota, kodepos, dan sebagainya. Maka sebaiknya atribut alamat tersebut tetap dibuat sebagai simple attributes. Sedangkan jika user membutuhkan detail dari atribut alamat seperti nama jalan, kota, kodepos, dan sebagainya. Maka sebaiknya atribut alamat tersebut dibuat sebagai composite attributes.
30
Single / Multi-valued attributes Suatu atribut juga dapat mempunyai satu atau lebih nilai. Contoh: Atribut noTelepon. Seseorang bisa saja mempunyai nomor telepon lebih dari satu, apabila memang adanya demikian maka dapat disebut Multi-Valued Attribute. Tetapi apabila atribut tersebut hanya mempunyai suatu nilai maka disebut Single Attribute.
Derived Attributes Atribut yang tergantung dengan nilai atribut yang lain, maka atribut ini disebut Derived Attribute. Sebagai contoh: •
Umur dari seorang Staff
•
Banyaknya dari properti yang dipegang oleh Staff
Langkah 1.4: Menentukan domain atribut Tujuan dari langkah ini adalah untuk menentukan domain dari atribut yang ada didalam model data konseptual lokal. Sebagai contoh antara lain:
Atribut dari staffNo terdiri dari lima karakter tipe string dimana dua karakter utama merupakan huruf, sedangkan tiga karakter sisa berupa angka.
Nilai yang mungkin untuk atribut sex adalah ’M’ atau ’F’. Ini merupakan domain dari atribut yang menggunakan karakter tunggal.
31 Langkah 1.5: Menentukan candidate dan primary key Tujuan dari langkah ini adalah untuk mengidentifikasikan candidate key dari setiap tipe entity, dan jika memang terdapat lebih dari satu candidate key, pilihlah salah satunya untuk menjadi primary key. Pada saat Anda memilih suatu primary key di antara banyak candidate key, gunakan petunjuk berikut ini untuk membantu menyeleksi:
Merupakan candidate key dengan jumlah set paling sedikit
Merupakan candidate key yang nilainya jarang sekali berubah
Merupakan candidate key dengan jumlah karakter paling sedikit
Merupakan candidate key dengan jumlah paling sedikit dari nilai maksimumnya (untuk tipe atribut dengan tipe numerik)
Merupakan candidate key yang paling mudah digunakan dari sudut pandang pengguna
Langkah 1.6: Menggunakan Enhanced Modelling Concepts (langkah optional) Tujuan dari langkah ini adalah untuk mempertimbangkan penggunaan enhanced modelling concepts, seperti specialization, generalization, menggunakan
aggregation, pendekatan
dan
composition.
specialization
maka
Jika
Anda
Anda
akan
memperhatikan perbedaan yang terlihat secara maksimal antara entity satu atau banyak subclass dari entity superclasses. Jika Anda menggunakan
pendekatan
generalization
maka
Anda
akan
mengidentifikasi persamaan antara entity yang ada untuk membentuk superclass.
32 Langkah 1.7: Memeriksa redudansi Tujuan dari langkah ini adalah untuk memeriksa apakah ada redudansi dalam model basisdata. Pada langkah ini, Anda akan menguji data model konseptual lokal dengan melihat secara spesifik, apabila ada redudansi maka dapat dihilangkan dengan dua langkah berikut: o Menguji kembali hubungan one-to-one o Menghilangkan relasi redudansi Langkah 1.8: Validasi model konseptual lokal dengan transaksi user Tujuan dari langkah ini adalah untuk memastikan bahwa model konseptual lokal mendukung permintaan transaksi oleh user. Anda dapat menguji dua kemungkinan pendekatan dengan memastikan bahwa model data konseptual lokal mendukung permintaan transaksi dengan cara berikut:
Deskripsikan transaksi
Gunakan alur transaksi
Langkah 1.9: Me-review model data konseptual lokal dengan user Tujuan dari langkah ini adalah untuk me-review model data konseptual lokal bersama user untuk memastikan bahwa model yang ada sudah sesuai dengan yang diminta. Hasil akhir dari perancangan basisdata konseptual adalah memproses pembuatan suatu model dari informasi yang akan digunakan dalam suatu organisasi, yang independensinya tidak tergantung dengan apapun.
33 Berikut ini adalah bentuk dari Conceptual Data Model untuk user views pada Staff dengan semua atribut diambil dari Connolly (2005, p464):
Gambar 2.2 Contoh Conceptual Data Model untuk user views pada Staff dengan semua atribut (Connolly, 2005, p464)
34 2.1.7.2
Perancangan Logikal Tujuan dari perancangan logikal basisdata menurut Connolly (2005, p439) adalah untuk memproses pembuatan suatu model informasi yang digunakan di dalam suatu organisasi berdasarkan model data yang spesifik, tetapi tidak bergantung pada suatu DBMS dan perangkat keras lainnya. Langkah 2: Membuat dan Memvalidasi Model Data Logikal Lokal untuk setiap Bagian Tujuan dari langkah membuat dan memvalidasi data lokal logikal untuk setiap bagian adalah untuk membangun suatu model data logikal lokal dari suatu model data konseptual lokal yang merepresentasikan perusahaan dan kemudian memvalidasi model ini untuk memastikan strukturnya benar (menggunakan teknik normalisasi) dan memastikan bahwa model tersebut mendukung transaksi yang diminta. Langkah 2.1: Menghilangkan fitur tidak kompatibel Langkah 2.2: Validasi model menggunakan normalisasi Langkah 2.3: Validasi relasi terhadap transaksi user Langkah 2.4: Mendefinisikan kendala integrity Langkah 2.5: Me-review model data logikal lokal dengan user Langkah 2.6: Menggabungkan model data logikal ke model global (langkah optional) Langkah 2.7: Memeriksa untuk pertumbuhan ke masa yang akan datang Berikut ini adalah detail mengenai langkah - langkah yang telah disebutkan di atas, antara lain: Langkah 2.1: Menghilangkan fitur tidak kompatibel Tujuan dari langkah ini adalah untuk membuat suatu relasi untuk model data logikal lokal yang merepresentasikan suatu entity, relasinya, dan juga
35 atribut yang telah diidentifikasi. Adapun pendeskripsian bagaimana relasi dapat diturunkan dari struktur model data yang ada sekarang, antara lain:
Tipe entity kuat.
Tipe entity lemah.
Tipe relasi binary one-to-many (1:*)
Tipe relasi binary one-to-one (1:1).
Tipe relasi rekursif one-to-one (1:1).
Superclass / subclass tipe relasi.
Tipe relasi binary many-to-many (*:*).
Tipe relasi kompleks.
Atribut multi-valued.
Langkah 2.2: Validasi model menggunakan normalisasi Tujuan dari langkah ini adalah untuk menvalidasi relasi dalam model data logikal lokal dengan menggunakan teknik normalisasi. Menurut Connolly (2005, p388), normalisasi adalah teknik untuk menghasilkan sejumlah tabel dengan properties yang diinginkan, sesuai dengan kebutuhan data dari perusahaan. Normalisasi sering dilakukan sebagai rangkaian dari pengujian pada suatu hubungan untuk menentukan apakah hubungan tersebut benar atau melanggar persyaratan dari bentuk normal yang ditentukan. Normalisasi merupakan sebuah teknik dalam logical design sebuah basisdata, teknik pengelompokkan atribut dari suatu relasi sehingga membentuk struktur relasi yang baik (tanpa redudansi).
36 Adapun bentuk - bentuk normal tersebut adalah: 1. First Normal Form (1NF) Sebuah relasi dimana setiap persimpangan antara baris dan kolom mengandung satu dan hanya satu nilai. Aturan:
Mendefinisikan atribut kunci
Tidak adanya group berulang
Semua atribut bukan kunci tergantung pada atribut kunci
2. Second Normal Form (2NF) Sebuah relasi yang telah memenuhi normal pertama (1NF) dan setiap atribut yang bukan primary key, fully functionally dependent terhadap primary key. Aturan:
Sudah memenuhi dalam bentuk normal pertama
Sudah tidak ada ketergantungan parsial, dimana seluruh field hanya tergantung pada sebagian field kunci
3. Third Normal Form (3NF) Sebuah relasi yang telah memenuhi normal pertama (1NF) dan normal kedua (2NF) dan tidak ada atribut yang bukan primary key, transitively dependent terhadap primary key. Aturan:
Sudah berada dalam bentuk normal kedua (2NF)
Tidak ada ketergantungan transitif (dimana field bukan kunci tergantung pada field bukan kunci lainnya)
37 Langkah 2.3: Validasi relasi terhadap transaksi user Tujuan dari langkah ini adalah untuk memastikan bahwa relasi di dalam model data logikal lokal mendukung transaksi yang diminta user. Validasi transaksi seperti ini sudah dilakukan pada langkah 1.8, namun dilakukan kembali untuk memeriksa relasi - relasi yang diciptakan pada rancangan logikal juga mendukung transaksi user. Pada langkah ini, pengecekan bahwa relasi yang dibuat di langkah sebelumnya yang mendukung transaksi ini, dan pastikan bahwa tidak ada error dalam relasi yang telah dibuat. Langkah 2.4: Mendefinisikan kendala integrity Tujuan dari langkah ini adalah untuk mendefinisikan batasan - batasan integritas yang diperlihatkan kepada user, dimana kontrol integritas mengandung batasan - batasan yang dapat diterapkan untuk mencegah basisdata menjadi tidak konsisten. Dalam hal ini ada enam tipe kendala integrity, antara lain: 1. Required data Beberapa kolom harus memiliki sebuah nilai yang valid (tidak mengandung null). Null berbeda dari kosong atau nol, dan digunakan untuk merepresentasikan data yang tidak tersedia, hilang, atau tidak dapat dipakai. 2. Attribute domain constraints Setiap kolom harus mempunyai sebuah domain, dengan kata lain, satu set nilai yang sah.
38 3. Multiplicity Multiplicity merepresentasikan batasan - batasan yang berada di dalam relationship antara data dalam basisdata. 4. Entity integrity Primary key dari sebuah tabel harus unik dan tidak mengandung nilai null untuk setiap baris. 5. Referential integrity Foreign key adalah sebuah atau beberapa kolom yang menghubungkan setiap baris pada tabel anak yang mengandung foreign key ke baris pada tabel induk yang mengandung nilai candidate key yang sama. Referential integrity berarti bahwa jika foreign key mengandung sebuah nilai maka nilai tersebut harus ada pada sebuah baris di tabel induk. 6. General / Enterprise constraints Merupakan aturan tambahan yang dibuat oleh user atau seorang Database Administrator dari basisdata tersebut. Langkah 2.5: Me-review model data logikal lokal dengan user Tujuan dari langkah ini adalah untuk memastikan bahwa model data logikal lokal dan dokumentasi yang mendeskripsikan model tersebut sebagai representasi yang sesuai dengan keadaan yang sebenarnya. Langkah 2.6: Menggabungkan model data logikal ke model global (langkah optional) Tujuan dari langkah ini adalah untuk menggabungkan model - model data logikal lokal individual menjadi sebuah model data logikal global yang merepresentasikan perusahaan.
39 Langkah 2.6.1: Menggabungkan model data logikal ke model global Langkah 2.6.2: Memvalidasi model data logikal global Langkah 2.6.3: Me-review model data logikal global dengan user Berikut ini adalah detail mengenai langkah - langkah yang telah disebutkan di atas, antara lain: Langkah 2.6.1: Menggabungkan model data logikal ke model global Tujuan dari langkah ini adalah untuk menggabungkan model data logikal yang individu menjadi sebuah model data logikal global bagi sebuah perusahaan. Beberapa tugas dari pendekatan ini adalah sebagai berikut:
Me-review nama dan isi dari suatu entity / relasi dan candidate key
Me-review nama dan isi dari relationship / foreign key
Menggabungkan entity / relasi dari model data lokal
Memasukkan (tanpa menggabungkan) entity / relasi unik pada setiap model data lokal
Menggabungkan relationship / foreign key dari model data lokal
Memasukkan (tanpa menggabungkan) relationship / foreign key unik pada setiap model data
Memeriksa untuk entity, relasi, foreign key yang hilang
Memeriksa foreign key
Mendefinisikan kendala integrity
Membuat global ER / relasi diagram
Meng-update dokumentasi
40 Langkah 2.6.2: Memvalidasi model data logikal global Tujuan dari langkah ini adalah untuk memvalidasi relasi yang dibuat dari model data logikal global dengan menggunakan teknik dari normalisasi dan dengan memastikan bahwa relasi yang dibuat mendukung transaksi. Langkah 2.6.3: Me-review model data logikal global dengan user Tujuan dari langkah ini adalah untuk memastikan bahwa model data logikal global itu memang merepresentasikan yang sesuai dengan keadaan yang sebenarnya pada perusahaan. Langkah 2.7: Memeriksa untuk pertumbuhan ke masa yang akan datang Tujuan dari langkah ini adalah untuk menentukan apakah ada perubahan yang penting di masa yang akan datang dan untuk menilai apakah model data logikal global dapat mengakomodasi perubahan tersebut. Perancangan model data logikal global harus dapat diperluas sehingga dapat berevolusi untuk mendukung kebutuhan - kebutuhan baru di masa mendatang dengan efek yang minimal terhadap user yang telah ada.
41 Berikut adalah contoh perancangan logikal untuk kasus DreamHome
Gambar 2.3 Contoh ERD Logikal pada Global relation diagram pada kasus DreamHome (Connolly, 2005, p489)
42 2.1.7.3
Perancangan Fisikal Tujuan dari perancangan fisikal basisdata menurut Connolly (2005, p439) adalah untuk mendeskripsikan dari pengimplementasian dari suatu basisdata pada media penyimpanan secondary; itu juga akan mendeskripsikan dasar dari suatu relasi, organisasi file, dan juga index yang digunakan untuk mencapai suatu keefisienan data, integritas, serta ukuran keamanan. Langkah 3 : Menerjemahkan model data logikal ke DBMS pilihan Tujuan dari langkah ini adalah untuk menghasilkan skema basisdata relasional dari model data logikal yang dapat diimplementasikan pada DBMS pilihan. Bagian pertama dari proses ini memerlukan perbandingan informasi yang
dikumpulkan
selama
perancangan
basisdata
logikal
dan
didokumentasikan dalam kamus data. Bagian kedua dari proses ini menggunakan informasi tersebut untuk menghasilkan desain relasi dasar. Proses
ini
membutuhkan
pengetahuan
yang
mendalam
mengenai
fungsionalitas yang ditawarkan oleh DBMS pilihan. Langkah 3.1 : Merancang relasi dasar Langkah 3.2 : Merancang representasi dari data turunan (derived data) Langkah 3.3 : Merancang batasan umum (general constraints) Berikut ini adalah detail mengenai langkah - langkah yang telah disebutkan di atas, antara lain:
43 Langkah 3.1: Merancang relasi dasar Tujuan dari langkah ini adalah untuk memutuskan bagaimana merepresentasikan relasi dasar yang telah diidentifikasikan dalam model data logikal pada DBMS pilihan. Untuk memulai proses perancangan basisdata fisik, pertama-tama Anda dapat mengumpulkan dan mengasimilasikan suatu informasi tentang relasional yang dirancang selama perancangan basisdata logikal. Informasi yang diperlukan bisa berasal dari kamus data dan definisi dari relasional yang didefinisikan menggunakan Database Design Language (DBDL). Untuk setiap relasional yang diidentifikasi pada model data logikal, dapat didefinisikan sebagai berikut:
Nama dari relasi yang ada;
Suatu list untuk atribut yang simple;
Primary key, alternative key, dan foreign key;
Batasan integrasi untuk setiap foregin key yang diidentifikasi.
Dari kamus data, dari setiap atributnya dapat diketahui:
Domain atribut tersebut yang terdiri dari tipe data, panjang, dan berbagai keterangan atribut tersebut;
Suatu optional nilai default untuk atribut;
Apakah atribut dapat diisi nilai NULL;
Apakah atribut dapat diturunkan (derived).
44 Langkah 3.2: Merancang representasi dari data turunan (derived data) Tujuan dari langkah ini adalah untuk memutuskan bagaimana merepresentasikan semua data turunan pada model data logikal pada DBMS pilihan. Atribut yang nilainya didapatkan dengan mengevaluasi atribut lain dikenal sebagai atribut turunan / kalkulasi. Sebagai contoh:
Jumlah banyaknya staff yang bekerja pada suatu kantor
Total gaji yang dibayarkan pada seluruh staff
Total dari property yang ditangani oleh seorang staff
Langkah 3.3: Merancang batasan umum (general constraints) Tujuan dari langkah ini adalah merancang batasan umum pada DBMS pilihan. Meng-update suatu relasi yang mungkin dibatasi oleh aturan perusahaan sesuai dengan transaksi yang sebenarnya bisa di update. Perancangan batasan tersebut sekali lagi tergantung pada DBMS yang lain. Pada awalnya, jika sistem tersebut mempunyai aturan sesuai aturan standar SQL, beberapa batasan dapat diterapkan. Langkah 4: Merancang organisasi file dan indeks Tujuan dari langkah ini adalah untuk menentukan pengorganisasian file yang optimal untuk menyimpan relasi - relasi dasar dan indeks - indeks yang diperlukan untuk mencapai performansi yang diinginkan, yaitu cara penyimpanan relasi - relasi dan tuples pada media penyimpanan sekunder. Langkah 4.1: Menganalisis transaksi Langkah 4.2: Memilih organisasi file
45 Langkah 4.3: Memilih indeks Langkah 4.4: Memperkirakan Kapasitas Penyimpanan yang dibutuhkan Berikut ini adalah detail mengenai langkah - langkah yang telah disebutkan di atas, antara lain: Langkah 4.1: Menganalisis transaksi Tujuan dari langkah ini adalah untuk mengerti fungsi dari suatu transaksi yang mana akan dijalankan pada basisdata dan untuk menganalisa transaksi yang penting. Untuk membuat perancangan basisdata fisik efektif maka perlu untuk mempunyai pengetahuan mengenai transaksi / query yang akan dijalankan dalam basisdata. Ini termasuk kuantitatif atau kuantitatif informasi. Dalam menganalisis transaksi, dapat diidentifikasikan kriteria informasi sebagai berikut:
Transaksi yang sering digunakan, dan akan berdampak besar terhadap performansi keseluruhan.
Transaksi yang merupakan transaksi bisnis yang kritis
Durasi
waktu
dalam
harian
atau
mingguan
yang
akan
mendapatkan banyak permintaan pada basisdata Langkah 4.2: Memilih organisasi file Tujuan dari langkah ini adalah untuk menentukan organisasi file yang efektif untuk setiap relasional data. Dalam kasus yang ada, suatu relasional DBMS akan memberikan sedikit bahan tanpa pilihan dalam memilih organisasi file, walaupun beberapa
46 akan mempunyai indeks yang spesifik. Bagaimanapun juga, berikut ini beberapa organisasi file yang ada:
Heap
Hash
Indexed Sequential Access Method (ISAM)
B*-tree
Cluster
Langkah 4.3: Memilih indeks Tujuan dari langkah ini adalah untuk menentukan penambahan indeks yang akan meningkatkan performansi dari suatu sistem. Biasanya pemilihan atribut untuk indeks adalah sebagai berikut:
Suatu atribut yang digunakan paling sering untuk operasi penggabungan, yang akan membuat penggabungan tersebut lebih efektif.
Suatu atribut yang digunakan paling banyak untuk mengakses suatu record di dalam relasi yang ada.
Langkah 4.4: Memperkirakan Kapasitas Penyimpanan yang dibutuhkan Tujuan dari langkah ini adalah untuk mengestimasi ukuran kapasitas disk yang diperlukan untuk basisdata. Langkah 5: Merancang user view Tujuan dari langkah ini adalah untuk merancang user view yang diidentifikasi selama pengumpulan informasi dan analisis dari siklus hidup aplikasi basisdata.
47 Langkah 6: Merancang Mekanisme Keamanan Tujuan dari langkah ini adalah untuk merancang ukuran keamanan untuk basisdata yang telah dispesifikasikan user. Definisi dari keamanan basisdata adalah suatu mekanisme yang memproteksi basisdata dari suatu kejadian yang disengaja maupun tidak disengaja. Suatu basisdata merupakan sumber dari perusahaan yang essensial yang perlu dilindungi dengan menggunakan suatu kontrol yang memadai. Beberapa isu keamanan basisdata yang perlu diperhatikan antara lain: 1. Pencurian data (Theft and Fraud) 2. Kehilangan kerahasiaan suatu data (Loss of Confindentially) 3. Kehilangan hak pribadi (Loss of Privacy) 4. Kehilangan Integritas (Loss Integrity) 5. Kehilangan ketersediaan data (Loss of Avaliability) Hasil akhir dari perancangan fisik basisdata ini adalah suatu proses yang mendeskripsikan suatu implementasi dari suatu basisdata pada media penyimpanan. Ini mendeskripsikan suatu relasional dan struktur penyimpanan dan metodologi pengaksesan data oleh user yang efisien, selama batasan integritas dan pengukuran keamanan. 2.1.8
Entity Relationship (ER) Modelling Model Entity Relationship merupakan salah satu model yang dapat memastikan
pemahaman
yang
tepat
terhadap
data
dan
bagaimana
penggunaannya di dalam suatu organisasi (Connolly, 2005, p342). Model ini dimulai dengan identifikasi entity dan relationship antar data yang harus
48 direpresentasikan di dalam model, dan kemudian ditambahkan atribut dan setiap constraint pada entity, relationship, dan atributnya. 2.1.8.1
Entity Type Entity type adalah sekumpulan obyek yang memiliki properti yang sama, yang diidentifikasikan di dalam organisasi karena keberadaannya yang bebas (independent existence) (Connolly, 2005, p343). Sedangkan entity occurrence adalah sebuah obyek dari satu tipe entity yang dapat diidentifikasi secara unik (Connolly, 2005, p344). Keberadaan obyek-obyeknya secara fisik/nyata (physical existence), seperti entity Pegawai, Rumah, dan Pelanggan, atau secara konseptual/abstrak (conceptual existence), seperti entity Inspeksi, Penjualan, dan Peninjauan. Setiap tipe entity dilambangkan dengan sebuah persegi panjang yang diberi nama dari entity tersebut. Nama tipe entity biasanya adalah kata benda tunggal. Huruf pertama dari setiap kata pada nama tipe entity ditulis dengan huruf besar. Representasi diagram tipe entity terlihat pada gambar 2.4. NamaEntity
Pegawai
Cabang
Gambar 2.4 Representasi Diagramatik dari tipe Entity Pegawai dan Cabang (Connolly, 2005, p345) Tipe entity dapat diklasifikasikan menjadi: 1. Tipe entity kuat, yaitu tipe entity yang keberadaannya tidak bergantung pada tipe entity lainnya (Connolly, 2005, p355) 2. Tipe entity lemah, yaitu tipe entity yang keberadaannya bergantung pada tipe entity lainnya (Connolly, 2005, p355)
49 Entity Kuat
Client
Entity Lemah
States ►
clientNo {PK} name fname lname telpNo
Preference prefType maxRent
Gambar 2.5 representasi diagram tipe entity kuat dan tipe entity lemah (Connolly, 2005, p355) 2.1.8.2 Relationship Types Relationship type adalah sekumpulan hubungan antartipe entity yang memiliki arti (Connolly, 2005, p346). Sedangkan relationship occurrence adalah sebuah hubungan yang dapat diidentifikasikan secara unik, yang meliputi sebuah kejadian (occurrence) dari setiap tipe entity di dalam relationship (Connolly, 2005, p346) Tipe
relationship
digambarkan
dengan
sebuah
garis
yang
menghubungkan tipe entity - tipe entity yang saling berhubungan. Garis tersebut diberi nama sesuai dengan nama hubungannya dan diberi tanda panah satu arah di samping nama hubungannya. Biasanya sebuah relationship dinamakan dengan menggunakan kata kerja, seperti Mengatur, atau dengan sebuah frase kata kerja, seperti DisewaOleh. Sedangkan tanda panah ditempatkan di samping nama relationship yang mengindikasikan arah bagi pembaca untuk mengartikan nama dari suatu relationship. Huruf pertama dari setiap kata pada nama relationship ditulis dengan huruf besar. Representasi diagram dari suatu tipe relationship terlihat pada gambar 2.6.
50 Memiliki►
Cabang
Pegawai
’Cabang memiliki pegawai’ Gambar 2.6 Representasi Diagramatik dari Relationship (Connolly, 2005, p347) Derajat dari tipe relationship adalah jumlah tipe entity yang ikut serta dalam sebuah relationship (Connolly, 2005, p347). Sebuah relationship yang memiliki berderajat dua disebut binary (Connolly, 2005, p348). Sedangkan sebuah relationship yang berderajat tiga disebut ternary (Connolly, 2005, p348), dan jika sebuah relationship yang berderajat empat disebut sebagai quartenary (Connolly, 2005, p348). Lambang belah ketupat merepresentasikan relationship yang memiliki derajat lebih dari dua. Nama dari relationship tersebut ditampilkan di dalam lambang belah ketupat. Panah yang biasanya terdapat di samping nama suatu relationship dihilangkan. Representasi diagram tiga dari suatu tipe relationship terlihat pada gambar 2.7. ’Pegawai mendaftarkan seorang klien pada sebuah cabang’ PrivateOwner
POwns ►
PropertyForRent
Gambar 2.7 Representasi diagram derajat tiga dari suatu tipe relationship (Connolly, 2005, p348) Recursive relationship adalah sebuah tipe relationship dimana tipe entity yang sama ikut serta lebih dari sekali pada peran yang berbeda (Connolly, 2005, p349).
51 Relationship dapat diberikan nama peran untuk menentukan fungsi dari setiap entity yang terlibat dalam relationship tersebut. Representasi diagram recursive relationship beserta nama perannya terlihat pada gambar 2.8. Nama peran juga dapat digunakan jika dua buah entity dihubungkan melalui lebih dari satu relationship. Representasi diagram nama peran yang digunakan pada dua buah entity terlihat pada gambar 2.9. ’Staff (Supervisor) mengawasi staff Supervisee / orang yang diawasi)’
Role name ◄Supervises Supervisor
Role name
Supervisee
Staff
Gambar 2.8 Representasi diagram recursive relationship dan nama peran (Connolly, 2005, p349) ’Manager mengatur kantor cabang’ Role name
Staff
Manager Manages ►
Branch Office Branch
◄ Has Member of Staff
Branch Office
Role name Gambar 2.9 Representasi diagram entity dengan dua relationship berbeda beserta nama peran (Connolly, 2005, p350) 2.1.8.3
Attributes Atribut adalah properti sebuah entity atau relationship (Connolly, 2005, p350). Menurut Jeffery L. Whitten (2004, p295), atribut merupakan
52 properti deskriptif atau karakteristik dari sebuah entity. Atribut menampung nilai yang menjelaskan setiap entity occurrence dan menggambarkan bagian utama dari data yang di simpan di dalam basisdata. Atribut domain adalah sekumpulan nilai yang dibolehkan bagi satu atau lebih atribut (Connolly, 2005, p350). Atribut dapat diklasifikasikan menjadi : 1.
Simple attribute adalah atribut yang terdiri dari komponen tunggal (single component) dengan keberadaan yang bebas (independent existence). Simple attribute tidak bisa dibagi lagi ke dalam komponen yang lebih kecil.
2.
Composite attribute adalah atribut yang terdiri dari beberapa komponen, dan keberadaan setiap komponen tersebut bebas.
3.
Single-valued attribute adalah atribut yang hanya memiliki sebuah nilai untuk setiap occurrence dari sebuah entity.
4.
Multi-valued attribute adalah sebuah atribut yang memiliki banyak nilai untuk setiap occurrence dari sebuah tipe entity.
5.
Derived attribute adalah atribut yang nilai - nilainya diperoleh dari pengolahan atau diturunkan dari atribut lain yang berhubungan.
2.1.8.4
Keys Candidate key adalah himpunan atribut yang minimal yang secara unik mengidentifikasikan setiap occurrence dari sebuah tipe entity (Connolly, 2005, p352). Composite key adalah sebuah candidate key yang terdiri atas dua atau lebih atribut (Connolly, 2005, p353).
53 Primary
key
adalah
candidate
key
yang
terpilih
untuk
mengidentifikasikan secara unik setiap occurrence dari sebuah tipe entity (Connolly, 2005, p353). Pada sebuah tipe entity 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 secondary key. Foreign key adalah sebuah primary key pada sebuah entity yang digunakan pada entity lainnya untuk mengidentifikasikan sebuah relationship. Fungsinya sebagai penghubung antar tabel. Primary key Staff Ruang untuk menuliskan atribut
staffNo {PK} name fname lname position
Derived attribute
Manages► ◄Has
Branch branchNo{PK} address street city postcode telpNo [1..3]
Composite attribute
Multi-valued attribute
Gambar 2.10 Representasi diagram entity Pegawai dan Cabang beserta atribut dan primary key-nya (Connolly, 2005, p354) 2.1.8.5
Structural Constraints Batasan - batasan yang menggambarkan pembatasan pada relationship seperti yang ada pada dunia nyata harus diterapkan pada tipe entity yang ikut
54 serta pada sebuah relationship. Jenis utama dari batasan pada suatu relationship dinamakan multiplicity (Connolly, 2005, p356). Multiplicity adalah jumlah occurrence yang mungkin terjadi pada sebuah entity yang berhubungan ke sebuah occurrence dari tipe entity lain pada suatu relationship (Connolly, 2005, p356). Derajat yang biasanya digunakan pada suatu relationship adalah binary relationship, yang terdiri atas : -
One-to-one (1:1) Relationship Setiap relationship menggambarkan hubungan antara sebuah entity occurrence pada entity yang satu dengan sebuah entity occurrence pada entity lainnya yang ikut serta dalam relationship tersebut. Staff tipe entity (staffNo)
Manages tipe relationship
Branch tipe entity (branchNo)
SG5 ● SG37 ● SL21 ●
r1 ◊
B003 ●
r2 ◊
B005 ●
Gambar 2.11 Semantic net menunjukkan dua occurrence dari relationship Pegawai Mengatur Cabang (Connolly, 2005, p357)
55
‘Setiap cabang diatur oleh satu staff’
Staff staffNo
‘Seorang staff dapat mengatur nol atau satu cabang’
Branch Manages ► 1..1 0..1 branchNo
Multiplicity Gambar 2.12 Multiplicity dari relationship one-to-one (1:1) (Connolly, 2005, p358) -
One-to-many (1:*) Relationship Setiap relationship menggambarkan hubungan antara sebuah entity occurrence pada entity yang satu dengan satu atau lebih entity occurrence pada entity lainnnya yang ikut serta dalam relationship tersebut.
Staff tipe entity (staffNo)
Manages tipe relationship
Branch tipe entity (branchNo)
SG5 ●
r1 ◊
SG37 ●
r2 ◊
SA9 ●
r3 ◊
PG21 ● PG36 ● PA14 ● PG4 ●
Gambar 2.13 Semantic net menunjukkan tiga occurrence dari relationship staff Melihat PropertyFor Rent (Connolly, 2005, p358)
56
‘Setiap property yang disewakan diperlihatkan oleh nol atau satu anggota staff’
Staff staffNo
‘Setiap staff memperlihatkan nol atau lebih property yang disewakan’
PropertyForRent
Oversees ► 0..1 0..* propertyNo
Gambar 2.14 Multiplicity dari relationship one-to-many (1:*) (Connolly, 2005, p359) -
Many-to-many(*:*) Relationship Setiap relationship menggambarkan hubungan antara satu atau lebih entity occurrence pada entity yang satu dengan satu atau lebih entity occurrence pada entity lainnnya yang ikut serta dalam relationship tersebut. Staff tipe entity (staffNo)
Manages tipe relationship
Branch tipe entity (branchNo)
Glasgow Daily ● The West News ●
r1 ◊
PG21 ● PG36 ●
Aberdeen Express ●
r2 ◊ r3 ◊ r4 ◊
PA14 ● PG4 ●
Gambar 2.15 Semantic net menunjukkan empat occurrence dari relationship Koran Mengiklankan PropertyForRent (Connolly, 2005, p360)
57
‘Setiap property yang disewakan diiklankan nol atau lebih pada koran’
Newspaper newspapername
‘Setiap Koran mengiklankan satu atau lebih property yang akan disewakan’
PropertyForRent
Advertises► 0..* 1..* propertyNo
Gambar 2.16 Multiplicity dari relationship many-to-many (*:*) (Connolly, 2005, p360)
2.1.9
Normalisasi Suatu desain basisdata harus memenuhi kondisi untuk tidak mengandung anomali, yaitu suatu kejanggalan dari suatu penempatan atribut tertentu dari suatu obyek data. Untuk membedakan suatu record dengan yang lainnya maka perlu dipilih atribut dan kombinasi atribut sebagai primary key.
2.1.9.1
Pengertian Normalisasi Normalisasi menurut Gerald V. Post (2005, p36) adalah Proses pendefenisian tabel – tabel dengan baik untuk menyediakan fleksibilitas, meminimalkan redudancy, dan mengamankan integrity data. Normalisasi menurut Connolly (2005, p388) adalah sebuah teknik untuk menghasilkan sebuah relasi dengan menggunakan data yang diberikan yang ada pada perusahaan. Tujuan dari Normalisasi: 1. Menghilangkan kumpulan relasi dari update anomali 2. Menghilangkan duplikasi data 3. Membuat model relasional lebih informatif
58 2.1.9.2
Tahap-tahap Normalisasi
UNF UNF atau unnormalized form merupakan tabel yang berisi satu atau lebih repeating group.
1NF Suatu relasi dalam bentuk normal pertama jika dan hanya jika semua domain mengandung hanya nilai atomik atau menghilangkan perulangan. Terdapat dua pendekatan dalam 1NF yaitu: -
Pendekatan
Pertama,
repeating
group
dihilangkan
dengan
memasukkan data yang cocok pada kolom dari baris yang mengandung data berulang. Dimana akan dihasilkan tabel yang mengandung nilai tunggal pada setiap baris dan kolom. -
Pendekatan kedua, repeating group dihilangkan dengan mengisi data berulang, bersamaan dengan sebuah salinan dari kunci atribut aslinya. Sebuah primary key diidentifikasikan pada relasi yang baru.
2NF Suatu relasi dalam bentuk normal jika dan hanya jika relasi sudah berbentuk normal pertama dan setiap atribut bukan key tergantung fungsional pada primary key atau bentuk ini mempunyai syarat yaitu data harus memenuhi kriteria 1NF dan setiap data item
59 yang bukan kunci harus dependency functional pada kunci utamanya.
3NF Relasi dalam bentuk normal ketiga jika dan hanya jika relasi sudah terbentuk normal kedua dan tidak ada atribut bukan key yang tergantung transitif pada primary key atau menghilangkan transitif dependensi.
BCNF (Boyce-Codd Normal Form) Pada tabel yang ternormalisai normal kedua dan normal ketiga dapat
menyisakan
redudansi
tambahan
disebabkan
oleh
ketergantungan yang merusak semua candidate keys, maka dari itu untuk menghilangkan depedencies ini normal ketiga diubah ke bentuk BCNF dengan memastikan bahwa semua entity adalah candidate keys. Sebuah tabel berada pada bentuk BCNF jika dan hanya jika setiap determinan adalah candidate keys. 2.2 Pengertian Pembelian, Penjualan, Retur Penjualan, dan Persediaan 2.2.1
Pembelian Menurut Mulyadi (2001, p299), pembelian digunakan dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan. Berdasarkan jenis pemasok, pembelian dapat digolongkan menjadi dua, yaitu: 1. Pembelian Lokal Pembelian Lokal adalah pembelian dari pemasok dalam negeri. 2. Pembelian Impor Pembelian Impor adalah pembelian dari pemasok luar negeri.
60 Fungsi – fungsi yang terkait dalam sistem pembelian: o Fungsi Gudang Bertanggungjawab untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan yang ada di gudang dan untuk menyimpan barang yang telah diterima oleh fungsi penerimaan. o Fungsi Pembelian Bertanggungjawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang, dan mengeluarkan order pembelian kepada pemasok yang dipilih. o Fungsi Penerimaan Bertanggungjawab untuk melakukan pemeriksaan terhadap jenis, mutu, dan kuantitas barang yang diterima dari pemasok guna menentukan dapat atau tidaknya barang tersebut diterima oleh perusahaan. o Fungsi Akuntansi Fungsi akuntansi yang terkait dalam transaksi pembelian adalah fungsi pencatat hutang dan fungsi pencatat persediaan. Fungsi pencatat hutang bertanggungjawab untuk mencatat transaksi pembelian ke dalam register bukti kas keluar dan untuk menyelenggarakan arsip dokumen sumber (bukti kas keluar) yang berfungsi sebagai catatan hutang atau menyelenggarakan kartu hutang sebagai buku pembantu hutang. Fungsi pencatat persediaan bertanggungjawab untuk mencatat harga pokok persediaan barang yang dibeli ke dalam kartu persediaan.
61 2.2.2
Penjualan Menurut Mulyadi (2001, p248), penjualan barang dan jasa perusahaan dapat dilaksanakan melalui penjualan tunai atau penjualan kredit 1.
Penjualan Kredit Penjualan kredit memungkinkan perusahaan menambah volume penjualan dengan memberi kesempatan kepada para pembeli membelanjakan sekarang penghasilan yang akan diterima mereka di masa yang akan datang. Sistem penjualan kredit didahului dengan seleksi pelanggan yang secara keuangan dapat diberi hak untuk melakukan pembelian secara kredit kepada perusahaan. Pembelian dilakukan oleh pelanggan yang terpilih selama jangka waktu tertentu (biasanya pada akhir bulan) perusahaan melakukan penagihan kepada pelanggan yang bersangkutan. Cara penjualan kartu kredit perusahaan ini memberi kemudahan bagi pelanggan untuk tidak setiap saat menyediakan uang tunai bilamana mereka perlu belanja barang atau jasa kebutuhan mereka. Disamping itu, penjualan secara kredit menanamkan kesetiaan (loyalty) pelanggan terhadap perusahaan.
2.
Penjualan Tunai Penjualan tunai dilaksanakan oleh perusahaan dengan cara mewajibkan pembeli melakukan pembayaran harga barang lebih dahulu sebelum barang diserahkan oleh perusahaan kepada pembeli. Setelah uang diterima oleh perusahaan, barang kemudian diserahkan kepada pembeli dan transaksi penjualan tunai kemudian dicatat oleh perusahaan. Sistem penerimaan kas dari penjualan tunai dibagi menjadi tiga prosedur berikut ini:
62
Penerimaan Kas dari Over–the Counter Sale Dalam penjualan tunai ini, pembeli datang ke perusahaan, melakukan pemilihan barang atau produk yang akan dibeli, melakukan pembayaran ke kasir, dan kemudian menerima barang yang dibeli. Dalam Over–the Counter Sale ini, perusahaan menerima uang tunai, cek pribadi (personal check), atau pembayaran langsung dari pembeli dengan credit card, sebelum barang diserahkan kepada pembeli.
Penerimaan Kas dari COD Sales Cash-on-delivery sales (COD Sales) adalah transaksi penjualan yang melibatkan kantor pos, perusahaan angkutan umum, atau angkutan sendiri dalam penyerahan dan penerimaan kas dari hasil penjualan. COD Sales merupakan sarana untuk memperluas daerah pemasaran dan untuk memberikan jaminan penyerahan barang bagi pembeli dan jaminan penerimaan kas bagi perusahaan penjual.
Penerimaan Kas dari Credit Card Sales Sebenarnya credit card bukan merupakan suatu tipe penjualan namun merupakan salah satu cara pembayaran bagi pembeli dan sarana penagihan bagi penjual, yang memberikan kemudahan baik bagi pembeli maupun bagi penjual
2.2.3
Retur Penjualan Menurut Mulyadi (2001, p266), transaksi retur penjualan terjadi jika perusahaan menerima pengembalian barang dari pelanggan karena barang tidak sesuai
63 dengan permintaan. Pengembalian barang oleh pelanggan harus diotorisasi oleh fungsi penjualan dan diterima oleh fungsi penerimaan. Menurut Mulyadi (2001, p226-231), fungsi – fungsi yang terkait dalam sistem retur penjualan adalah: a.
Fungsi Penjualan, bertanggung jawab atas penerimaan pemberitahuan mengenai pengembalian barang yang telah dibeli oleh pembeli.
b.
Fungsi Penerimaan, bertanggung jawab atas penerimaan barang berdasarkan otorisasi yang terdapat dalam memo kredit yang telah diterima dari fungsi penjualan.
c.
Fungsi Gudang, bertanggung jawab atas penyimpanan kembali barang yang diterima dari retur penjualan setelah barang tersebut diperiksa oleh fungsi penerimaan.
d.
Fungsi Akuntansi, bertanggung jawab atas pencatatan transaksi retur penjualan ke dalam jurnal umum dan pencatatan berkurangnya piutang dan bertambahnya persediaan akibat retur penjualan dalam kartu piutang dan kartu persediaan.
2.2.4
Persediaan Menurut Rangkuti (1995, p7), persediaan merupakan salah satu unsur yang paling aktif dalam operasi perusahaan yang secara kontiniu diperoleh, diubah dan kemudian dijual kembali. Menurut Thomas R. Dyckman (1999, p376), persediaan terdiri dari barang – barang yang dimiliki suatu bisnis dan disimpan baik untuk digunakan membuat produk atau sebagai produk yang siap untuk dijual, dan dapat diklarifikasikan sebagai berikut:
64 1. Persediaan barang dagang (merchandise inventory) Barang yang ada di gudang dibeli oleh pengecer atau perusahaan perdagangan seperti importir atau eksportir untuk dijual kembali. Biasanya, barang yang diperoleh untuk dijual kembali secara fisik tidak diubah oleh perusahaan pembeli. 2. Persediaan manufaktur (manufacturing inventory) Persediaan dari entity manufaktur, yang terdiri dari: a.
Persediaan bahan baku. Barang yang berwujud yang dibeli atau diperoleh dengan cara lain (misal dengan menambang) dan disimpan untuk penggunaan langsung dalam membuat barang untuk dijual kembali.
b.
Persediaan barang dalam proses. Barang – barang yang membutuhkan pemrosesan lebih lanjut sebelum penyelesaian dan penjualan.
c.
Persediaan barang jadi. Barang – barang manufaktur yang diselesaikan dan disimpan untuk dijual.
3.
Persediaan rupa – rupa Barang – barang seperti pelengkapan kantor, kebersihan, dan pengiriman. Persediaan jenis ini biasanya digunakan segera dan biasanya dicatat sebagai beban penjualan atau umum ketika dibeli.
