BAB 2 LANDASAN TEORI
2.1
Teori- Teori Sistem Basis Data
2.1.1
Pengertian Sistem Menurut Mcleod (2001, p9), sistem adalah elemen-elemen yang terintegrasi dengan maksud yang sama untuk mencapai tujuan organisasi atau perusahaan yang terdiri dari sejumlah sumber daya dan sumber daya tersebut bekerja menuju tercapainya suatu tujuan tertentu yang ditentukan oleh pemilik atau manajemen perusahaan tersebut. Menurut Hall (2001, p5), sistem adalah sekelompok atau lebih dari komponen-komponen yang saling berkaitan atau subsistem-subsistem yang bersatu untuk mencapai tujuan yang sama. Menurut Turban, Rainer, dan Potter (2003, p8), sistem adalah suatu komponen kelompok yang saling berhubungan dan bekerja sama untuk mencapai tujuan umum dengan menerima input dan menghasilkan output dalam proses transformasi yang terorganisasi.
2.1.2
Pengertian Basis Data Menurut Connolly dan Begg (2005, p15), sebuah basis data adalah sebuah kumpulan data yang saling berhubungan secara logis, dan sebuah penjelasan dari data tersebut, yang didesain untuk menemukan data yang
9
10 dibutuhkan oleh sebuah organisasi. Di dalam basis data, semua data diintegrasikan dengan menghindari duplikasi data. Basis data dapat digunakan oleh banyak departemen dan pemakai. Basis data tidak hanya memegang data operasional organisasi, tetapi juga penjelasan mengenai data tersebut. Menurut Elmasri dan Navathe (2000, p4), sebuah basis data adalah kumpulan dari relasi-relasi data. Dengan data, kita dapat mengetahui fakta yang dapat direcord dan memiliki arti lengkap. Menurut Hoffer, Prescott, dan McFadden (2005, p4), sebuah basis data merupakan kumpulan data yang terorganisir yang saling berhubungan secara logis. Menurut Post, Gerald V. (2005, p2), sistem basis data merupakan kumpulan data yang disimpan dalam format yang standar dan dirancang untuk dibagikan oleh berbagai pemakai.
2.2
Database System Development Lifecyle Menurut Connolly dan Begg (2005, p283), sistem basis data merupakan komponen dasar dari organisasi yang besar dengan sistem informasi yang luas. Hal penting yang perlu diperhatikan dalam database application lifecycle adalah bahwa tingkatannya tidak sepenuhnya berurutan (sequential). Di mana ada beberapa tingkatan yang berulang dengan alur-balik (feedback loop), misalnya , masalahnya
ditemukan
pada
tingkatan
perancangan
basis
data
yang
membutuhkan tambahan kumpulan kebutuhan dan analisis. Untuk aplikasi basis data yang kecil dengan pemakai yang sedikit maka lifecycle-nya tidak terlalu kompleks. Sebaliknya, ketika merancang basis data yang sedang sampai ke basis
11 data yang besar dengan puluhan ribu pemakai, menggunakan ratusan query dan program aplikasi maka lifecycle akan menjadi sangat kompleks. Database Planning
System Definition Requirement collection and analysis
Database Design
Conceptual design DBMS Selection
Application Design
Logical design
Physical design
Prototyping
Implementation
Data Loading and conversion
Testing
Operational maintenance
Gambar 2.1 Database System Development Lifecycle Sumber: Connolly dan Begg, 2005, p284
12 2.2.1
Database Planning (Perencanaan Basis Data) Menurut Connolly dan Begg (2005, p285), perencanaan basis data adalah merencanakan bagaimana tahapan dari lifecycle bisa dicapai dengan lebih efisien dan efektif. Perencanaan basis data harus diintegrasikan dengan keseluruhan strategi sistem informasi dari organisasi. Ada tiga isu pokok yang berkaitan dengan perumusan strategi sistem informasi, antara lain: •
Mengenali rencana dan tujuan perusahaan, kemudian menentukan kebutuhan sistem informasi.
•
Mengevaluasi sistem informasi yang sedang berjalan untuk menentukan kekuatan dan kelemahannya.
•
Penilaian dari kesempatan teknologi informasi yang menghasilkan kekuatan kompetitif. Langkah penting pertama dalam perencanaan basis data adalah
menegaskan pernyataan tugas proyek basis data dengan jelas. Ini memandu proyek basis data dalam organisasi, biasanya Direktur atau pemilik perusahaan yang menegaskan pernyataan tugas. Pernyataan tugas membantu untuk menjelaskan tujuan dari proyek basis data dan menetapkan garis yang jelas terhadap penciptaan basis data yang dibutuhkan agar efektif dan efisien. Aktivitas selanjutnya adalah menetapkan sasaran tugas. Setiap sasaran tugas harus menetapkan tugas-tugas khusus yang harus didukung basis data asumsinya jika basis data mendukung sasaran tugas maka pernyataan tugas akan didapatkan. Pernyataan tugas dan sasaran tugas mungkin disertai dengan beberapa informasi tambahan yang khusus, dalam istilah umumnya, untuk
13 menyelesaikan pekerjaan, sumber daya untuk menyelesaikannya, dan biaya untuk membayar semuanya. Jelasnya pernyataan tugas dapat diperoleh dengan melakukan wawancara dengan Direktur atau pegawai lainnya yang berkaitan dengan hal seperti; apa tujuan dari perusahaan, kenapa perusahaan membutuhkan basis data, kenapa basis data bisa menyelesaikan masalahnya, dan hal lain apa yang serupa. Begitu juga dengan sasaran tugas dapat diperoleh dengan memberikan pertanyaan seperti; apa pekerjaannya, tugas apa yang diselesaikan tiap harinya, bekerja dalam data apa, jenis laporan apa yang digunakan, pelayanan apa yang diberikan perusahaan terhadap pelanggan, dan lain-lain.
2.2.2
System Definiton (Definisi Sistem) Menurut
Connolly
dan
Begg
(2005,
p286),
sistem
adalah
menggambarkan lingkup dan batasan dari aplikasi basis data dan pandangan pemakai yang utama. Pandangan pemakai menegaskan aplikasi basis data apa yang dibutuhkan untuk tugas tertentu seperti; untuk manajer atau supervisor atau bidang aplikasi perusahaan seperti, pemasaran, personalia atau pengendalian persediaan. Sebelum mencoba merancang suatu aplikasi basis data, diperlukan untuk mengenali batasan sistem dan bagaimana antarmuka dengan bagian sistem informasi lainnya dalam organisasi. Hal penting yang harus diperhatikan bahwa ini tidak hanya pada batasan sistem pemakai sekarang dan batasan bidang aplikasi sekarang, tetapi juga pemakai dan aplikasi mendatang. Sebuah aplikasi basis data mungkin memiliki satu atau lebih pandangan pemakai, karena itu
14 mengidentifikasi pandangan pemakai sangatlah penting dalam mengembangkan aplikasi basis data agar dapat memastikan tidak ada pemakai utama yang terlupakan ketika mengembangkan keperluan untuk aplikasi baru.
2.2.3 Requirement Collection and Analysis (Analisis dan Pengumpulan Kebutuhan) Menurut Connolly dan Begg (2005, p288), analisis dan pengumpulan kebutuhan adalah proses dari analisis dan pengumpulan informasi tentang bagian organisasi yang akan dibuat aplikasi basis data dan menggunakan informasi ini untuk mengenali kebutuhan pemakai dari sistem baru. Informasi ini kemudian dianalisa untuk mengidentifikasi kebutuhan untuk dimasukan ke dalam aplikasi basis data baru. Kebutuhan-kebutuhan ini digambarkan dalam sebuah dokumen secara bersamaan yang diarahkan sebagai spesifikasi kebutuhan untuk aplikasi basis data baru. Dalam hal ini ada beberapa teknik atau cara untuk mendapatkan informasi yang disebut dengan teknik fact-finding. Yang dimaksud dengan teknik fact-finding adalah teknik yang digunakan untuk mengidentifikasi kebutuhan, seperti mempelajari dokumen, wawancara, pengamatan operasi perusahaan, penelitian dan menggunakan kuisioner.
2.2.4
Database Design (Perancangan Basis Data) Menurut Connolly dan Begg (2005, p291), perancangan basis data adalah proses pembuatan sebuah rancangan untuk sebuah basis data yang mendukung operasi dan tujuan dari perusahaan.
15 Ada 2 pendekatan untuk mendesain sebuah basis data, yaitu: 1. Pendekatan bottom-up Yang dimulai pada tingkat awal dari atribut (yaitu, properti dari entity 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 Digunakan pada basis data yang lebih kompleks, yang dimulai dengan pengembangan dari model data yang mengandung beberapa entitas dan hubungan tingkat tinggi dan kemudian memakai perbaikan top-down berturut-turut untuk mengidentifikasi entitas, hubungan dan atribut berkaitan tingkat rendah. Pendekatan ini biasanya digambarkan melalui ER (Entity Relationship). 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
16 Kriteria untuk model data, yaitu: 1. Structural validity Konsistensi dengan cara yang didefinisikan perusahaan dan menyusun informasi. 2. Simplicity Kemudahan untuk pemahaman baik bagi yang profesional di bidang sistem informasi maupun pemakai yang nonteknis. 3. Expressibility Kemampuan untuk membedakan antara data yang berbeda, dan hubungan antar data. 4. Nonredundancy Pembuangan
informasi
yang
tak
ada
hubungannya;
khususnya
representasi dari tiap potongan informasi tepatnya hanya sekali. 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 terhadap cara yang digunakan perusahaan dan mengatur informasi.
17 8. Diagramatic representation Kemampuan untuk merepresentasikan sebuah model menggunakan notasi diagram yang dapat dipahami dengan mudah.
Dalam
metodologi
perancangan
basis
data
(database),
proses
perancangan dibagi menjadi 3 bagian, yaitu Perancangan Basis Data Konseptual, Perancangan Basis Data Logikal, dan Perancangan Basis Data Fisikal.
2.2.4.1 Conceptual Database Design (Perancangan Basis Data Konseptual) Menurut Connolly dan Begg (2005, p439), Perancangan Basis data Konseptual merupakan suatu proses pembuatan model dari data yang digunakan dalam sebuah perusahaan, bebas dari semua pertimbangan fisik. Tahapan dalam Perancangan Basis Data Konseptual dimulai dengan pembuatan sebuah konseptual data model dari perusahaan, yang mana secara keseluruhan terbebas dari detil penerapannya, seperti target DBMS software, program aplikasi, bahasa pemrograman, hardware platform atau pertimbangan fisik lainnya. Langkah-langkah Perancangan Basis Data Konseptual: Langkah 1: Membangun Model Data Konseptual Tujuan dari langkah ini adalah untuk membangun model data konseptual dari keperluan data dari perusahaan. Untuk menghasilkan model data konseptual, kita perlu sublangkah dari langkah 1 yang terdiri dari:
18 1. Identifikasi tipe entitas Untuk mengidentifikasi tipe-tipe entitas yang dibutuhkan, dengan kata lain membuat kelas-kelas dari objek-objek yang ada berikut penjelasannya . Misalkan: Staff,
yang
menggambarkan
seluruh
tingkatan
staff
yang
ada.
PropertyForRent, menggambarkan semua properti yang disewakan . 2. Identifikasi tipe relasi Untuk mengidentifikasi hubungan-hubungan penting yang ada antara tipetipe entitas. Misalkan: •
Staff Manages PropertyForRent, yaitu staf mengatur entitas properti.
•
PrivateOwner Owns PropertyForRent, yaitu entitas PropertyOwner memiliki yang ada pada entitas PropertyForRent.
•
PropertyForRent AssociatedWith Lease, yaitu entitas PropertyForRent saling bekerja sama dengan entitas Lease.
Langkah-langkah dasar dalam mengidentifikasi tipe relasi: o Gunakan Entity-Relationship (ER) Diagram o Tentukan pembatas multiplicity dari tipe relasi o Memeriksa fan dan chasm traps 3. Menghubungkan atribut dengan entitas yang sesuai Untuk menghubungkan atribut-atribut dengan entitas yang sesuai atau dengan tipe relasi yang sesuai.
19 Misalkan untuk entitas staff ditentukan atribut seperti staffNo (yang mengandung nomor-nomor kode setiap staf), name, position, sex. Begitu pun untuk setiap entitas lainnya. Langkah selanjutnya adalah mengidentifikasi tipe-tipe dari fakta-fakta tentang entitas dan relasi yang telah dipilih untuk direpresentasikan dalam basis data. Atribut dapat diidentifikasikan dengan melihat kata benda atau frase kata benda dari user requirement dimana kata benda tersebut adalah sifat, mutu, identifier, atau karakteristik dari salah satu entitas-entitas atau relasi-relasi. Hal-hal yang harus diperhatikan dalam mengidentifikasi atribut: 1. Apakah atribut merupakan simple atau composite attributes 2. Apakah atribut tersebut single atau multi-value attributes 3. Apakah atribut tersebut merupakan derived-attributes 4. Masalah-masalah yang potensial Ketika kita mengidentifikasi entitas, relasi, dan atribut untuk view, ini tidaklah aneh bila satu atau lebih entitas, relasi, atau atribut dihilangkan dari bagian aslinya. Pada kasus ini, kembali ke langkah sebelumnya, dokumentasikan entitas, relasi, atau atribut baru dan menguji kembali semua relasi-relasi yang berhubungan. 4. Menentukan Domain untuk Atribut Untuk menentukan domain untuk atribut-atribut di dalam model data konseptual lokal. Suatu domain adalah suatu kelompok nilai yang mana satu atau lebih atribut-atributnya menggambarkan nilai mereka.
20 Misalkan: •
Domain atribut untuk nilai staffNo yang valid misalnya panjang maksimalnya 5 karakter dengan 2 karakter pertama harus huruf dan yang 3 berikutnya berupa angka yang berkisar antara 1 – 999.
•
Nilai yang mungkin untuk atribut sex dari entiti staff misalnya huruf M atau F saja.
5. Mengidentifikasi atribut candidate, primary, dan alternate key Untuk mengidentifikasikan candidate keys untuk setiap tipe entitas dan jika ada lebih dari satu candidate key, pilih satu untuk menjadi primary key dan yang lainnya sebagai alternate keys. Primary key merupakan satu atribut yang dipakai sebagai ciri khas dari suatu entitas. Misalkan pada entitas staff primary key-nya adalah staffNo yang mewakili atribut lainnya, sehingga pada saat kita mengakses suatu basis data hanya dengan memasukkan nilai staffNo kita dapat mengetahui nilai-nilai atribut lainnya yang ada dalam entitas staff. 6. Pertimbangan menggunakan enchanced modeling concepts (optional) Untuk mempertimbangkan penggunaan dari konsep of enchanced modeling, seperti spesialisasi / generalisasi, aggregrasi, dan composition. Tahap ini tidak perlu pembahasan lebih lanjut dikarenakan hanya merupakan langkah tambahan saja, boleh dilakukan boleh juga tidak. 7. Memeriksa perulangan dalam model Untuk memeriksa keberadaan dari setiap redudansi di dalam model dan menghilangkan redudansi jika ada.
21 Tiga kegiatan utama dalam tahap ini:
Pertama yang dilakukan adalah memeriksa kembali hubungan one to one. Dalam
pengidentifikasiaan
entitas,
kita
mungkin
telah
mengidentifikasikan dua entitas yang merepresentasikan objek yang sama dalam perusahaan. Contoh, kita mungkin telah mengidentifikasikan dua entitas Client dan Renter yang sebenarnya adalah sama; dengan kata lain, Client merupakan sinonim dari Renter. Dalam kasus ini, kedua entitas itu harus digabungkan. Jika primary keys nya berbeda, pilih satu saja untuk dijadikan primary key dan sisanya sebagai alternate key.
Menghilangkan relasi yang redundan. Sebuah relasi adalah redundan jika informasi yang sama dapat diperoleh melalui relasi yang lain.
Consider time dimension Dimensi waktu dari relasi adalah penting ketika mengakses redudancy.
8. Validasi Model Konseptual Lokal dengan Transaksi Pengguna Untuk memastikan bahwa model konseptual tersebut mendukung proses transaksi yang dibutuhkan. Misalkan menggambarkan transaksi dengan memeriksa semua informasi yang
ada.
Comtohnya
dengan
adanya
hubungan
staff
manages
PropertyForRent kita dapat mengetahui detil dari properti dan staf yang menangani properti tersebut.
22 Dua pendekatan untuk memastikan bahwa model data konseptual mendukung transaksi yang dibutuhkan:
Menggambarkan transaksi Memeriksa semua informasi (entitas, relasi, dan atribut) yang dibutuhkan setiap
transaksi
yang
disediakan
oleh
model,
kemudian
mendokumentasikannya.
Menggunakan jalur transaksi Memvalidasi model data terhadap transaksi yang dibutuhkan mencakup diagram yang menggambarkan jalur yang diambil setiap transaksi secara langsung dari ER-diagram.
9. Me-review model data konseptual dengan pengguna Untuk mengkaji ulang model data konseptual dengan user untuk memastikan bahwa model adalah representasi yang benar dari keperluan data pada perusahaan. Model data konseptual terdiri dari ER-diagram dan dokumentasi pendukung yang menjelaskan data model.
2.2.4.2 Logical Database Design (Perancangan Basis Data Logikal) Menurut Connolly dan Begg (2005, p439), Perancangan Basis Data Logikal merupakan suatu proses pembuatan model dengan menggunakan data yang diperoleh dari perusahaan serta berdasarkan pada model data spesifik, tetapi bebas dari particular DBMS dan pertimbangan fisik lainnya. Tahapan perancangan logikal basis data memetakan model data konseptual ke sebuah model logikal, yang dipengaruhi oleh model data untuk target basis data (contoh,
23 model relational). Model data logikal merupakan sumber informasi untuk fase selanjutnya, yang dinamakan Perancangan Basis Data Fisikal Langkah-langkah perancangan basis data logikal: Langkah 2: Membangun dan memvalidasi model data logikal Tujuan dari langkah ini adalah mengubah model data konseptual ke dalam model data logikal dan kemudian untuk memvalidasikan model ini untuk mengecek bahwa model tersebut secara struktur benar dan mampu mendukung transaksi yang dibutuhkan. Untuk menghasilkan model data logikal, kita perlu sublangkah dari langkah 2 yang terdiri dari: 1. Relasi turunan untuk model data logikal Membuat relasi bagi model data logikal untuk merepresentasikan entitas, relasi, dan atribut yang telah diidentifikasi. Dalam langkah ini, kita memperoleh hubungan untuk model data logikal untuk merepresentasikan entitas, relasi, dan atribut. Kita menjelaskan komposisi dari setiap relasi menggunakan DBDL (Database Definition Language) untuk basis data relasional. Kita menjelaskan bagaimana relasi diperoleh dari struktur-struktur berikut yang mungkin terjadi dalam model data konseptual: 1) Tipe entitas kuat 2) Tipe entitas lemah 3) Tipe hubungan binary one-to-many (1:*) 4) Tipe hubungan binary one-to-one (1:1) 5) Tipe hubungan recursive one-to-one (1:1)
24 6) Tipe hubungan superclass / subclass 7) Tipe hubungan binary man- to-many (*:*) 8) Tipe hubungan komplek 9) Multi-value attributes 2. Validasi relasi dengan menggunakan normalisasi Untuk memvalidasikan relasi dalam model data logikal menggunakan normalisasi. Tujuan dari normalisasi adalah sebagai berikut:
Menghilangkan kumpulan relasi dari ketergantungan yang tidak diharapkan atas kegiatan penambahan, perubahan, dan penghapusan data.
Mengurangi kebutuhan restrukturisasi kumpulan relasi dan meningkatkan file spam program aplikasi.
Membuat model relasional lebih informatif.
3. Validasi relasi dengan menggunakan transaksi pengguna Untuk memastikan bahwa relasi dalam model data logikal mendukung transaksi yang dibutuhkan. Jika kita dapat menjalankan semua transaksi dengan cara manual, kita telah memvalidasi model data logikal dengan transaksi. Tetapi, jika tidak dapat menjalankan transaksi secara manual, maka terdapat masalah dengan model data. 4. Mengecek integrity constraints Untuk mengecek integrity constraints direpresentasikan dalam model data logikal.
25 Setelah mengidentifikasi integrity constraints, akan didapatkan model data logikal yang lengkap dan gambaran akurat dari view. Ada enam tipe dari integrity constraints: 1) Required data 2) Attribute domain constraints 3) Multiplicity 4) Entity integrity 5) Referential integrity 6) General constraints 5. Me-review model data logikal dengan pengguna Untuk meninjau model data logikal dengan user untuk memastikan bahwa mereka menganggap model tersebut menjadi representasi yang benar dari keperluan data perusahaan. Semua atribut seharusnya berada didalam suatu tipe entitas jika memang ditangani didalam perusahaan dan kemungkinan akan dilihat mengalir di sekitar perusahaan sebagai aliran data. Aturan yang mengontrol antara dua teknik tersebut, antara lain:
Setiap penyimpanan seharusnya merepresentasikan suatu tipe entitas.
Atribut dalam aliran data seharusnya merupakan bagian dari tipe entitas.
6. Menggabungkan model data logikal menjadi model data global (optional) Untuk menggabungkan model data logikal lokal menjadi sebuah model data logikal global single yang merepresentasikan semua pandangan user tentang sebuah basis data.
26 6.1
Menggabungkan model data logical menjadi model data global Untuk menggabungkan model data logikal lokal menjadi sebuah model
data logikal global single. Sampai tahap ini, untuk setiap model data logikal lokal telah dihasilkan sebuah ER-diagram, sebuah skema relasional, sebuah kamus data, dan dokumentasi pendukung yang menggambarkan constraints pada data. Beberapa tugas khusus pada pendekatan ini adalah: 1. Mereview nama dan isi dari entitas/relasi dan kandidat kuncinya 2.
Mereview nama dan isi dari relasi/foreign keys
3. Menggabungkan entitas/relasi dari model data lokal 4. Memasukkan (tanpa menggabungkan) entitas/relasi yang unik untuk setiap model data lokal 5. Menggabungkan relasi/foreign keys dari model data lokal 6. Memasukkan (tanpa menggabungkan) relasi/ foreign keys yang unik untuk setiap model data lokal 7. Memeriksa entitas/relasi dan relationship/foreign keys yang hilang 8. Memeriksa foreign keys 9. Memeriksa integrity constraints 10. Menggambarkan ER-diagram global 11. Mengupdate dokumentasi 6.2
Validasi model data logikal global Untuk memvalidasi relasi yang dibuat dari model data logikal global
menggunakan teknik normalisasi untuk memastikan mereka mendukung transaksi yang dibutuhkan, jika diperlukan.
27 6.3
Me-review model data logical global dengan pengguna Untuk mereview model data logikal global dengan users untuk memastikan bahwa mereka menganggap model tersebut menjadi representasi yang benar dari keperluan data perusahaan.
7. Mengecek pertumbuhan mendatang Untuk menentukan apakah terdapat perubahan penting yang kemungkinan besar dapat diduga untuk masa yang akan datang dan untuk memperkirakan apakah model data logikal dapat menyesuaikan dengan perubahan.
Hasil akhir dari Perancangan Logikal Basis Data adalah merancang suatu model informasi berdasarkan model spesifik yang ada (seperti model relasional), tetapi tidak tergantng terhadap suatu DBMS dan perangkat keras lainnaya. Logikal basis data merancang suatu map untuk setiap model data konseptual. Jika terdapat lebih dari satu pandangan user, maka model data logikal lokal akan dikombinasikan menjadi suatu model data logikal global yang merepresentasikan semua pandangan user dari suatu perusahaan.
2.2.4.3 Physical Database Design (Perancangan Basis Data Fisikal) Menurut Connolly dan Begg (2005, p439), Perancangan Basis Data Fisikal merupakan proses pembuatan deskripsi dari suatu implementasi basis data pada secondary storage; hal ini mendeskripsikan base relation, file organizations, dan indeks yang digunakan untuk mencapai efisiensi akses ke dalam data, dan associated integrity constraints yang lainnya dan security measures.
28 Tahapan perancangan basis data fisikal mememperbolehkan perancang untuk memutuskan tentang bagaimana basis data diimplementasikan. Ada timbal balik antara perancangan fisikal dan logikal, karena keputusan yang diambil selama perancangan fisikal untuk meningkatkan performa dapat mempengaruhi model data logikal. Langkah-langkah perancangan basis data logikal: Langkah 3: Merubah model data logikal untuk target DBMS Tujuan dari langkah ini adalah untuk menghasilkan sebuah skema relasional basis data dari model data logikal yang dapat diimplementasikan pada target DBMS. Untuk menghasilkan model data konseptual, kita perlu sublangkah dari langkah 3 yang terdiri dari: 1. Merancang relasi dasar Untuk memutuskan bagaimana merepresentasikan relasi dasar yang diidentifikasikan dalam model data logikal pada target DBMS. Untuk setiap relasi yang diidentifikasikan dalam model data logikal, kita mempunyai definisi yang terdiri dari: a. Nama dari relasional b. Daftar simple attributes c. Primary key, alternate keys (AK), dan foreign keys (FK) yang sesuai d. Referensial batasan integritas untuk setiap foreign keys yang telah diidentifikasi
29 Dari kamus data, setiap atributnya dapat diketahui: a. Domainnya, terdiri dari tipe data, panjang, dan semua constraints pada domain. b. Sebuah nilai default optional untuk atribut c. Apakah atribut dapat diisi nilai null d. Apakah atribut diturunkan, jika ya, bagaimana ini harus di hitung 2. Merepresentasikan data turunan Untuk memutuskan bagaimana merepresentasikan data turunan yang ada pada model data logikal dalam target DBMS. Atribut-atribut yang nilainya dapat ditemukan dengan menguji nilai dari atribut-atribut yang lain dikenal sebagai derived atau calculated derived. Contoh, dibawah ini adalah atribut-atribut turunan:
Jumlah staf yang bekerja pada suatu kantor
Total gaji bulanan seluruh staff
Jumlah properties yang satu anggota staf tangani
3. Merancang general constraints Untuk merancang general constraints untuk target DBMS. Pembaharuan terhadap relasi yang mungkin dibatasi oleh aturan perusahaan yang sesuai dengan transaksi sebenarnya. Rancangan akan batasan seperti ini tergantung pada pemilihan DBMS. Langkah 4: Merancang file organisasi dan indek Untuk menentukan file organisasi yang optimal untuk menyimpan relasional dasar dan indek yang diperlukan untuk mencapai performa yang dapat diterima, itu cara dimana relasi dan tuple akan disimpan pada secondary storage.
30 Untuk menghasilkan model data fisikal, kita perlu sublangkah dari langkah 4 yang terdiri dari: 1. Menganalisa Transaksi Untuk memahami fungsi dari tansaksi-transaksi yang akan dijalankan pada basis data dan untuk menganalisa transaksi-transaksi yang penting. Melaksanakan perancangan fisikal basis data secara efektif, diperlukan pengetahuan akan transaksi atau query yang akan menjalankan basis data. Hal ini mencakup baik informasi kualitatif maupun kuantitatif. Dalam menganalisa transaksi diidentifikasikan kriteria kinerja sebagai berikut:
Transaksi yang sering digunakan dan akan memiliki dampak yang penting dalam kinerja keseluruhan.
Transaksi yang merupakan transaksi bisnis yang kritis.
Durasi waktu harian atau mingguan yang akan mendapatkan banyak permintaan pada basis data. Kita menggunakan informasi ini untuk mengidentifikasi bagian dari basis
data yang dapat mengakibatkan masalah kinerja. Dalam waktu yang sama, kita perlu untuk mengidentifikasi kegunaan tingkat tinggi dari transaksi dan memilih file organisasi dan indek yang tepat. 2. Memilih file organisasi Untuk menentukan sebuah file organisasi yang efisien untuk setiap relasi dasar. Salah satu tujuan dari sublangkah ini adalah memilih file organisasi yang optimal untuk setiap relasi, jika target DBMS mengizinkan.
31 File organisasi berdasarkan tipe file, yaitu:
Heap
Hash
Indexed Sequential Office Access Method (ISAM)
B+-tree
Clusters
3. Memilih indek Untuk menentukan apakah penambahan indek akan meningkatkan performa dari sistem. Salah satu pendekatan untuk memilih file organisasi yang sesuai untuk relasi adalah menjaga tuple tidak berurutan dan membuat indeks sekunder sebanyak yang diperlukan. Pendekatan lainnya adalah mengurutkan tuple di dalam relasi dengan menetapkan sebuah indek utama atau cluster. Memilih atribut untuk pengurutan atau pengelompokkan tuple seperti:
Atribut yang paling sering digunakan untuk join operations, yang akan membuat join operations tersebut lebih efektif, atau
Atribut yang paling sering digunakan untuk mengakses tuple dalam sebuah relasi.
4. Memperkirakan kapasitas disk Untuk memperkirakan jumlah kapasitas disk yang dibutuhkan oleh basis data. Tujuan dari sublangkah ini adalah memperkirakan jumlah kapasitas disk yang dibutuhkan untuk mendukung implementasi basis data pada penyimpanan sekunder. Memperkirakan penggunaan disk sangat tergantung
32 pada target DBMS dan hardware yang digunakan untuk mendukung basis data. Cara perhitungan kapasitas yang dibutuhkan untuk tabel-tabel yang digunakan dalam perancangan basis data adalah sebagai berikut: a. Menghitung ukuran tabel Num_Rows = jumlah baris dalam tabel atau pertambahan record per tahun Num_Cols = jumlah kolom dalam tabel Fixed_Data_Size = jumlah total byte dari kolom yang panjangnya tetap Num_Variable_Cols = jumlah kolom yang panjangnya variable/tidak tetap Max_Var_Sized = jumlah total byte kolom yang panjangnya variable/tidak tetap Null_Bitmap = 2 + ((Num_Cols+7)/8) Variable_Data_Size = 2+(Num_Variable_Cols X 2) + Max_Var_Sized Row_Size = Fixed_Data_Size + Variable_Data_Size + Null_Bitmap + 4 Rows_Per_Page = (8096)/(Row_Size+2) FreeRows_Per_Page = 8096 X ((100-FillFactor)/100)/(Row_Size+2) Num_Pages = Num_Rows/(Rows_Per_Page-FreeRows_Per_Page) Table_Size(bytes) = 8192 X Num_Pages b. Menghitung Clustered Index Num_Ckey_Cols = jumlah kolom di key index Fixed_Ckey_Size = jumlah total byte dari kolom yang panjangnya tetap Num_Variable_Ckey_Cols = jumlah kolom indeks yang panjangnya variable/tidak tetap Cindex_Null_Bitmap = 2 + ((Num_CKey_Cols+7)/8)
33 Variable_Ckey_Size = 2 + (Num_variable_Ckey_Colsx2) + Max_Var_Ckey_Size Cindex_Row_Size = Fixed_Ckey_Size + VariableCkey_Size + Cindex_Null_Bitmap + 1 + 8 Cindex_Rows_Per_Page = (8096)/(Cindex_Row_Size+2) Num_Pages_Clevel_0 = (Table_Size(bytes)/8192)/Cindex_Rows_Per_Page Clustered_Index_Size(byte) = 8192 X Num_Pages_Clevel_0 c. Menghitung Non Clustered Index Num_Key_Cols = jumlah kolom di key index Fixed_Key_Size = jumlah total byte dari kolom yang panjangnya tetap Num_Variable_Key_Cols = jumlah kolom indeks yang panjangnya variable/tidak tetap Max_Var_Key_Size = ukuran maksimum dari semua kolom yang panjangnya variable/tidak tetap Index_Null_Bitmap = 2 + (( Num_Key_Cols + 7) / 8 ) Variable_Key_Size = 2 + ( Num_Variable_Key_Cols x 2) + Max_Var_Key_Size NL_Index_Row_Size = Fixed_Key_Size + Variable_Key_Size + Index_Null_Bitmap + 1 + 8 NL_Index_Row_Size_Per_Page = ( 8096 ) / (NL_Index_Row_Size + 2) Index_Row_Size = CIndex_Row_Size + Fixed_Key_Size + Variable_Key_Size + Index_Null_Bitmap + 1 Index_Rows_Per_Page = ( 8096 ) / (Index_Row_Size + 2)
34 Free_Index_Rows_Per_Page = 8096 x (( 100 – FillFactor) /100) / Index_Rows_Size; Fill_Factor =100 Num_Page_Level_0 = Num_Rows / (Index_Rows_Per_PageFree_Index_Rows_Per_Page) Nonclustered_Index_Size = 8192 X Num_Index_Pages d.
Total
perkiraan
Kapasitas
penyimpanan
per
tahun
=
Table_Size(bytes) + Clustered_Index_Size + Nonclustered_Index_Size
5. Merancang tampilan pengguna Untuk merancang tampilan user yang diidentifikasi selama pengumpulan kebutuhan dan tahap analisis dari siklus pengembangan sistem basis data. Dalam multi-user DBMS, user view memainkan peranan penting dalam mendefinisikan struktur dari basis data dan menjalankan keamanan. 6. Merancang mekanisme keamanan Untuk merancang mekanisme keamanan bagi basis data seperti yang telah dispesifikasikan oleh user selama tahap pengumpulan dan kebutuhan dari siklus pengembangan sistem basis data. Secara umum, relasional DBMS memberikan dua tipe keamanan basis data, yaitu:
System security Keamanan sistem meliputi akses dan penggunaan basis data pada level sistem seperti username dan password.
35
Data security Keamanan data meliputi akses dan penggunaan dari objek basis data (seperti relation dan view) dan tindakan yang user dapat lakukan pada objek.
7. Mempertimbangkan pengenalan redudansi Untuk menentukan apakah dengan mengenalkan redudansi dalam sebuah cara pengendalian dapat mengendurkan aturan normalisasi dan meningkatkan performa sistem. Normalisasi merupakan suatu prosedur untuk menentukan atribut mana yang mestinya bersama dalam sebuah relasi, oleh karena itu normalisasi tidak boleh ditiadakan karena normalisasi merupakan faktor yang terpenting dalam menentukan suksesnya sistem secara keseluruhan. Hasil dari normalisasi adalah rancangan logikal basis data yang secara struktural konsisten dan redundansi yang minimal. Sebagai tambahan, fakor berikut harus dipertimbangkan:
Denormalisasi membuat implementasi menjadi semakin rumit
Denormalisasi biasanya mengorbankan fleksibilitas
Denormalisasi mungkin mempercepat pemanggilan tetapi memperlambat update
Secara umum, istilah denormalisasi mengarah pada perbaikan terhadap skema relasional seperti serajat dari normalisasi untuk relasi yang diubah lebih sedikit dari derajat setidaknya satu dari relasi asli. Tidak terdapat suatu aturan pasti yang menentukan kapan relasi di denormalisasi. Tetapi secara
36 khusus, denormalisasi dipertimbangkan dalam keadaan terutama untuk mempercepat transaksi yang sering dilakukan dan bersifat penting. 8. Memonitor sistem operasional Untuk memantau sistem operasional dan meningkatkan performa dari sistem untuk
memperbaiki
keputusan
rancangan
yang
tidak
sesuai
atau
menggambarkan kebutuhan akan perubahan. Permulaaan dari rancangan fisikal basis data tidak boleh dianggap statik tapi harus dipertimbangkan sebagai sebuah perkiraan dari kinerja operasional. Sekali permulaan rancangan telah diimplementasi, sangatlah diperlukan untuk memantau sistem dan memperbaiki sebagai hasil dari pemantauan kinerja dan syarat perubahan. Beberapa keuntungan dari perbaikan basis data, yaitu:
Dapat menghindari kebutuhan perangkat keras tambahan
Kemungkinan menurunkan konfigurasi perangkat keras
Sistem yang diperbaiki dengan baik menghasilkan response time yang lebih cepat dan throughput yang lebih baik, dimana sebagai hasilnya membuat user dan organisasi lebih produktif
Meningkatkan response time dapat menambah semangat staf
Meningkatkan response time dapat meningkatkan kepuasan pelanggan
Perbaikan merupakan hal yang tidak pernah selesai. Selama hidup dari sistem, perlu untuk memantau kinerja terutama untuk mempertanggungjawabkan perubahan terhadap lingkungan dan kebutuhan user. Membuat perubahan dalam sebuah area dari sistem operasional untuk meningkatkan
37 kinerja dapat merugikan area lain. Oleh karena itu, jika dimungkinkan menguji perubahan di saat sistem tidak digunakan.
2.2.5
DBMS Selection (Pemilihan DBMS) Menurut Connolly dan
Begg (2005, p295), DBMS selection adalah
memilih DBMS yang sesuai untuk mendukung aplikasi basis data. Pemilihan DBMS dilakukan antara tahapan logical database design dan conceptual database design. Tujuan dari pemilihan DBMS adalah untuk kecukupan sekarang dan kebutuhan masa mendatang pada perusahaan, membuat keseimbangan biaya termasuk pembelian produk DBMS, piranti lunak / perangkat keras lainnya untuk mendukung aplikasi basis data, biaya yang berhubungan dengan perubahan dan pelatihan pegawai. Pendekatan sederhana dalam pemilihan DBMS adalah memeriksa keistimewaan DBMS dalam memenuhi kebutuhan. Dalam memilih sebuah produk DBMS baru, ini adalah kesempatan untuk memastikan bahwa proses pemilihan sudah direncanakan dan hasil yang diberikan sistem benar-benar bermanfaat bagi perusahaan. DBMS digunakan oleh perusahaan untuk mendukung proses bisnisnya. Untuk itu dibutuhkan pertimbangan yang sesuai dalam memilih DBMS. Pertimbangan dalam pemilihan DBMS dipengaruhi oleh beberapa faktor-faktor sebagai berikut: - Kemudahan dalam penggunaan (Ease of use) DBMS sebaiknya mudah dipergunakan oleh penggunanya - Kehandalan (Reliability)
38 DBMS sebaiknya mampu mengamankan data apabila terjadi kegagalan piranti lunak atau piranti keras, serta memiliki kinerja yang baik dalam penanganan transaksi penyimpanan data - Biaya (Cost) Biaya dari DBMS yang diperkirakan harus tepat dan akurat - Keamanan (Security) DBMS sebaiknya selalu dijaga kerahasiaanya, sehingga keamanan yang ada dapat terjamin dan dalam pengaksesnya haruslah sesuai dengan prosedur. - Kompatibel (Compatibility) DBMS sebaiknya dapat bekerja dengan baik dan sesuai dengan komponen piranti keras dan piranti lunak - Stabilitas Vendor (Vendor Stability) Sebaiknya memilih vendor yang memang mempunyai kredibilitas bagus di bidang DBMS dan vendor tersebut memberikan dukungan yang baik terhadap pemakai produknya - Kemudahan dalam pengembangan (Development) DBMS
sebaiknya
mudah
disesuaikan
untuk
pengembangan-
pengembangan yang lebih lanjut, misalnya : pengembangan sistem yang berbasiskan objek (Object Oriented). - Kebutuhan Sistem (System Requirement) DBMS yang akan dipilih harus sesuai dengan system requirement yang telah ditetapkan oleh user.
39 Sebelum dilakukan pemilihan DBMS, perlu dilakukan evaluasi terhadap beberapa produk DBMS.
2.2.6
Application Design (Perancangan Aplikasi) Menurut Connolly dan Beg (2005, p299), perancangan aplikasi adalah merancang antarmuka pemakai (user interface) dan program aplikasi, yang akan memproses basis data. Perancangan basis data dan perancangan aplikasi adalah aktivitas yang dilakukan secara bersamaan pada database application lifecycle. Dalam kasus sebenarnya, tidak mungkin dapat menyelesaikan perancangan aplikasi sebelum perancangan basis data selesai. Dalam perancangan aplikasi harus memastikan semua pernyataan fungsional dari spesifikasi kebutuhan pemakai (user requirement 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 kegiatan keduanya). Artinya bagaimana fungsi yang dibutuhkan bisa terpenuhi dan merancang antarmuka pemakai yang tepat. Antarmuka yang dirancang harus memberikan informasi yang dibutuhkan dengan cara menciptakan ’user-friendly’.
2.2.7
Prototyping (Prototipe) Menurut Connolly dan Begg (2005, p303), prototyping adalah membuat model kerja dari aplikasi basis data, yang memungkinkan perancang atau pemakai untuk mengevaluasi hasil akhir sistem, baik dari segi tampilan maupun fungsi yang dimiliki sistem. Tujuan dari pengembangan prototype aplikasi basis
40 data adalah untuk memungkinkan pemakai menggunakan prototype untuk mengidentifikasi kelebihan atau kekurangan sistem, dan memungkinkan perancang untuk memperbaiki atau melengkapi kelebihan dari aplikasi basis data baru. Ada dua strategi prototyping yang umum digunakan, yaitu requirement prototyping dan evolutionary prototyping. Requirement prototyping yaitu menggunakan prototype untuk menetapkan kebutuhan dari tujuan aplikasi basis data dan ketika kebutuhan sudah terpenuhi, prototype tidak digunakan lagi atau dibuang. Sedangkan evolutionary prototype menggunakan tujuan yang sama, tetapi perbedaannya adalah prototype tetap digunakan.
2.2.8
Implementation (Implementasi) Menurut Connolly dan Begg (2005, p304), implementasi adalah mendefinisikan
basis
data
secara
eksternal,
konseptual,
dan
internal.
Implementasi basis data dicapai menggunakan Data Definition Language (DDL) dari DBMS yang dipilih atau graphical user interface (GUI). Pernyataan DDL digunakan untuk membuat struktur basis data dan file basis data kosong. Pandangan pemakai (user view) lainnya juga diimplementasikan dalam tahapan ini. Bagian dari aplikasi program adalah transaksi basis data yang diimplementasikan dengan menggunakan Data Manipulation Language (DML) dari sasaran DBMS, mungkin termasuk host programming language seperti; Visual Basic, Delphi, C, C++, Java, COBOL, atau Pascal.
41 2.2.9
Data Conversion and Loading (Konversi Data dan Loading) Menurut Connolly dan Begg (2005, p305), konversi data dan loading adalah mengambil data dari sistem yang lama untuk dipindahkan kedalam sistem yang baru. Tahapan ini dibutuhkan ketika sistem basis data baru menggantikan sistem yang lama. Pada masa sekarang, umumnya DBMS memiliki kegunaan untuk memasukkan file ke dalam basis data baru. Biasanya membutuhkan spesifikasi dari sumber file dan sasaran basis datanya. Kegunaan ini memungkinkan pengembang untuk mengkonversi dan menggunakan aplikasi program lama untuk digunakan oleh sistem baru. Ketika conversion and loading dibutuhkan, prosesnya harus direncanakan untuk memastikan kelancaran transaksi dari keseluruhan operasi.
2.2.10 Testing (Pengujian) Menurut
Connolly dan Begg (2005, p305), testing adalah proses
menjalankan program aplikasi untuk menemukan kesalahan-kesalahan. Sebelum digunakan, aplikasi basis data yang baru dikembangkan harus diuji secara menyeluruh.
Untuk
mencapainya
harus
hati-hati
dalam
menggunakan
perencanaan strategi uji dan menggunakan data asli untuk semua proses pengujian. Di dalam definisi testing ini tidak menggunakan pandangan yang biasa, testing adalah proses demontrasi tanpa kesalahan. Dalam kenyataannya testing tidak luput dari kesalahan. Jika testing menunjukkan keberhasilan, maka pengujian akan menemukan kesalahan pada program aplikasi dan mungkin struktur basis datanya.
42 Di dalam merancang basis data, pemakai yang menggunakan sistem baru seharusnya terlibat di dalam proses testing. Situasi yang ideal untuk melakukan uji sistem adalah menguji basis data pada perangkat keras yang berbeda, tetapi hal ini sering tidak dilakukan. Jika data yang asli digunakan, perlu backup untuk mengantisipasi kesalahan. Setelah testing selesai, sistem aplikasi siap digunakan dan diserahkan kepada pemakai.
2.2.11 Operational Maintenance (Pemeliharaan Operasional) Menurut Connolly dan Begg (2005, p306), pemeliharaan operasional adalah proses memantau dan memelihara sistem setelah diinstall. Pada tahapan sebelumya, basis data benar-benar diuji dan diimplementasikan. Sekarang sistem beralih pada tahapan pemeliharaan. Yang termasuk aktivitas dari tahapan pemeliharaan adalah sebagai berikut: 1. Memantau kinerja dari sistem, Jika kinerjanya menurun di bawah level yang dapat diterima, mungkin basis data perlu diperbaiki. 2. Memelihara dan upgrade aplikasi basis datanya (jika diperlukan). Ketika basis data sepenuhnya bekerja, harus dipastikan kinerjanya dapat berada dalam tingkat yang dapat diterima. Sebuah DBMS biasanya menyediakan berbagai kegunaan untuk membantu administrasi basis data termasuk kegunaan untuk mengisi data ke dalam basis data dan untuk memantau sistem. Kegunaan ini memungkinkan sistem pemantauan memberikan informasi tentang pemakaian basis data dan strategi eksekusi query. Basis data administrator dapat
43 menggunakan informasi ini untuk memperbaiki sistem agar dapat memberikan kinerja yang lebih baik
2.3
Entity Relationship Modeling Menurut Connolly dan Begg (2005, p342), salah satu aspek yang sulit dalam perancangan basis data adalah kenyataan bahwa perancang, programmer, dan pemakai akhir cenderung melihat data dengan cara yang berbeda. Untuk memastikan pemahaman secara alamiah dari data dan bagaimana data digunakan oleh perusahaan dibutuhkan sebuah bentuk komunikasi yang non-teknis dan bebas dari kebingungan.
2.3.1 Tipe entitas Tipe entitas adalah kumpulan objek-objek dengan properti yang sama, yang didefinisikan oleh perusahaan yang keberadaannya tidak tergantung. Konsep dasar dari bentuk Entity Relationship adalah tipe entity. Sebuah tipe entity memiliki keberadaan yang bebas dan bisa menjadi objek dengan keberadaan fisik atau menjadi objek dengan keberadaan konseptual. Ini berarti perancang yang berbeda mungkin mengidentifikasi entity yang berbeda. Entity
Occurrence
diidentifikasikan secara unik.
adalah
objek
dan
tipe
entitas
yang
dapat
44
Nama Entity
Staff
Branch
Gambar 2.2 Contoh Tipe Entitas Sumber: Connolly dan Begg,2005, p345
2.3.2
Tipe Relationship Tipe Relationship adalah sebuah gabungan yang mempunyai arti di antara tipe-tipe entitas. Setiap tipe relationship diberi nama sesuai dengan fungsinya. Relationship Occurrence adalah suatu gabungan yang dapat diidentifikasikan secara unik, yang meliputi suatu kejadian dari setiap tipe entitas yang berpartisipasi. Derajat dari relationship adalah jumlah dari partisipasi tipe entitas dalam sebuah tipe relationship tertentu. Entitas yang berkaitan dalam sebuah tipe relationship dikenal sebagai participant dalam relationship dan jumlah participant dalam relationship disebut sebagai derajat dari relationship. Oleh karena itu, derajat dari sebuah relationship menunjukkan jumlah dari entitas yang terkait dalam relationship. Sebuah relationship berderajat dua disebut binary, sedangkan relationship berderajat tiga disebut sebagai ternary, dan relationship berderajat empat disebut sebagai quartenary.
45
Gambar 2.3 Contoh Binary Relationship Sumber: Connolly dan Begg, 2005, p347
Gambar 2.4 Contoh Ternary Relationship Sumber: Connolly dan Begg, 2005, p348
Gambar 2.5 Contoh Quaternary Relationship Sumber: Connolly dan Begg, 2005, p349
46 2.3.3
Attribute Atribut adalah sifat dari sebuah entitas atau sebuah tipe relationship. Atribut menyimpan nilai dari setiap entity occurrence dan mewakili bagian utama dari data yang disimpan dalam basis data.
Attribute
domain
adalah
satuan nilai-nilai untuk satu atau beberapa atribut. Setiap atribut yang dihubungkan dengan sejumlah nilai disebut domain. Domain mendefinisikan nilai-nilai yang dimiliki sebuah atribut dan sama dengan konsep domain pada model relasional. Simple attribute adalah atribut yang terdiri dari satu komponen tunggal dengan keberadaan yang bebas. Simple attribute tidak bisa dibagi lagi ke dalam komponen yang lebih kecil, misalnya posisi dan gaji dari entitas pegawai. Simple attribute disebut juga atomic attribute. Composite attribute adalah atribut yang terdiri dari banyak komponen dengan sebuah keberadaan yang bebas. Dalam hal ini beberapa atribut dapat dipisahkan menjadi komponen yang lebih kecil lagi dengan keberadaan yang bebas. Contohnya atribut alamat dari entitas kantor cabang yang mengandung nilai (jalan, kota, kode pos) bisa dipecahkan menjadi atribut sederhana jalan, kota dan kode pos). Single value attribute adalah atribut yang memiliki nilai tunggal untuk masing-masing kejadian dari entitas. Multi value attribute adalah atribut yang memiliki banyak nilai untuk masing-masing kejadian dari entitas. Derived attribute adalah atribut yang menggantikan sebuah nilai yang diturunkan dari nilai sebuah atribut yang berhubungan, tidak perlu pada jenis entitas yang sama.
47 2.3.4
Keys Candidate key adalah kunci yang secara unik mengenali setiap kejadian di dalam tipe entitas. Sebuah candidate key tidak boleh NULL. Sebuah entitas mungkin punya lebih dari satu candidate key. Primary key adalah candidate key yang dipilih sebagai kunci primer untuk mengenali secara unik setiap occurrence dari sebuah tipe entitas. Pemilihan primary key untuk sebuah entitas adalah berdasarkan pada pertimbangan panjang atribut, jumlah minimal dari kebutuhan atribut, dan memenuhi syarat unik. Candidate key yang tidak dipilih menjadi primary key disebut sebagai alternative key. Composite key adalah candidate key yang terdiri dari dua atribut atau lebih. Foreign key adalah atribut pada satu relasi yang cocok pada candidate key dari beberapa relasi.
Gambar 2.6 Contoh Representasi Atribut Sumber: Connolly dan Begg, 2005, p354
48 2.3.5
Strong and Weak Entity Type Tipe entitas yang kuat adalah tipe entitas yang keberadaannya tidak bergantung pada tipe entitas yang lain. Karakteristiknya adalah setiap kejadian entitasnya secara unik mampu diidentifikasikan menggunakan atribut primary key pada entitasnya. Tipe entitas yang lemah adalah tipe entitas yang bergantung pada keberadaan entitas lainnya. Karakteristiknya adalah setiap kejadian entitas tidak bisa diidentifikasikan secara unik hanya dengan menggunakan atribut yang bergantung pada entitasnya.
2.3.6
Structural Constraints Tipe utama dari batasan hubungan di dalam relationship disebut multiplicity adalah jumlah kemungkinan kejadian dari sebuah entitas yang mungkin berhubungan ke sebuah kejadian tunggal dari sebuah entitas yang tergabung melalui sebuah hubungan khusus. Hubungan binary secara umum dibedakan menjadi: 1. Derajat hubungan one to one (1 : 1) Derajat hubungan antar entity 1 : 1 terjadi bila tiap angggota entity Staff hanya boleh berpasangan dengan satu anggota dari entitas Branch. Sebaliknya, tiap anggota dari entitas Branch hanya boleh berpasangan dengan satu anggota dari entitas Staff. 2. Derajat hubungan one to many ( 1 : *) Derajat hubungan ini terjadi bila tiap anggota entity Staff boleh berpasangan dengan lebih dari satu anggota entity PropertyForRent. Sebaliknya, tiap
49 anggota entity PropertyForRent hanya boleh berpasangan dengan satu anggota entity Staff. 3. Derajat hubungan many to many (* : *) Derajat hubungan antar entitas ini terjadi bila tiap anggota entitas newspaper boleh berpasangan dengan lebih dari satu anggota entitas PropertyForRent. Sebaliknya, tiap anggota entitas PropertyForRent juga boleh berpasangan dengan lebih dari satu anggota entitas newspaper. Multiplicity adalah angka kemungkinan kejadian suatu entitas dalam hubungan n-ary ketika nilai yang lain ( n – 1 ) ditetapkan. Pada umumnya multiplicity untuk hubungan n-ary mewakili angka potensial dari entitas kejadian dalam suatu hubungan ketika nilai ( n – 1 ) telah ditetapkan untuk tipe-tipe entitas yang berpartisipasi.
Gambar 2.7 Contoh One-to-One (1:1) Relationship Sumber: Connolly dan Begg, 2005, p358
Gambar 2.8 Contoh One-to-Many (1:*) Relationship Sumber: Connolly dan Begg, 2005, p359
50
Gambar 2.9 Contoh Many-to-Many (*:*) Relationship Sumber: Connolly dan Begg, 2005, p360
Tabel 2.1 Ringkasan cara alternatif menggambarkan multiplicity constraint Sumber: Connolly dan Begg, 2005, p362 Cara alternatif untuk menunjukkan Keterangan
Multiplicity constraint
0..1
Nol atau satu kejadian entity
1..1 (atau 1)
Tepatnya hanya satu kejadian entity
0..* (atau *)
Nol atau banyak kejadian entity
1..*
Satu atau banyak kejadian entity
5..10
Antara lima sampai sepuluh kejadian entity
0, 3, 6-8
Nol atau tiga atau enam, tujuh, delapan kejadian entiti
51 2.3.7
Integrity Constraints Integrity constraints merupakan batasan yang kita inginkan untuk mencegah basis data menjadi tidak konsisten. Integrity constraints dibagi menjadi 4 bentuk dasar, yaitu: •
Required data, beberapa atribut harus selalu mengandung nilai yang valid, dengan kata lain tidak boleh mengandung nilai null.
•
Attribut domain constraint, setiap atribut mempunyai domain sendiri, yaitu sekumpulan nilai yang sah untuk suatu atribut. Contohnya pada nilai atribut JenisKelamin hanya terdiri dari ’P’ atau ’L’.
•
Entity integrity, primary key dari sebuah entity tidak boleh mengandung nilai null. Setiap tuple harus mempunyai sebuah primary key.
•
Referential integrity, sebuah foreign key menghubungkan setiap tuple didalam relasi anak kepada tuple dalam relasi induk yang mengandung nilai candidate key yang cocok. Secara umum ada dua kondisi pada hubungan child pada relationship: -
Mandatory, null tidak diijinkan
-
Optional, null diijinkan Contoh pada hubungan 1 : * jika tuple parent dihapus maka ada beberapa strategi yang mempengaruhi nilai child, yaitu: o NO ACTION, jika tuple parent dihapus maka nilai child-nya tidak terjadi apa-apa atau tidak mengalami perubahan. o CASCADE, jika tuple parent dihapus maka nilai child-nya juga ikut terhapus.
52 o SET NULL, jika tuple parent dihapus maka nilai child-nya diset null. o SET DEFAULT, jika tuple parent dihapus maka nilai child-nya ikut berubah sesuai dengan nilai default yang sudah diatur,. o NO CHECK, jika tuple parent dihapus maka tidak dilakukan pengecekan pada nilai child-nya.
2.4
Entity Relationship Diagram Menurut Kadir (2000, p51), entity yang ada pada suatu sitem umumnya banyak. Diantara masing-masing entity tersebut terdapat suatu hubungan. Hubungan antar entity tersebut biasanya dinyatakan dengan ER (Entity Relationship) atau diagram hubungan entitas. Berdasarkan pendapat dari Mannino(2003, p212), ERD memiliki tiga unsur pokok: tipe entity, relation, dan atribut. 1. Tipe entity dapat merepresentasikan benda-benda fisik seperti buku, orang-orang, dan tempat, begitu juga kegiatan-kegiatan. 2. Atribut adalah keterangan dari sebuah tipe entity atau relation. 3. Relation adalah penamaan hubungan antara tipe-tipe entity.
2.5
Activity Diagram Activity Diagram merupakan penggambaran proses bisnis seperti bagan alur (flowcharts). Activity Diagram menunjukkan langkah- langkah seperti direkrut, bekerja, dan berhenti bekerja dengan sangat jelas dari satu kondisi ke kondisi berikutnya.
53 Activity Diagram sangat bermanfaat dalam menunjukkan apa yang terjadi di dalam suatu proses bisnis atau suatu kegiatan. Activity Diagram dirancang sesederhana mungkin terhadap apa yang terjadi selama suatu proses atau kegiatan berjalan. Jadi, dari activity diagram dapat dianalisis aktivitas apa saja yagn terdapat pada suatu proses atau kegiatan pada suatu sistem, serta penggunaan panah dari satu status (state) ke status (state) berikutnya akan memperlihatkan keadaan dari suatu objek dan memperlihatkan aktivitas berikutnya yang harus dilaksanakan setelah status (state) sebelumnya telah selesai dikerjakan.
2.6
Teori-teori Khusus
2.6.1
Penjualan Menurut Mulyadi (2001, p202), kegiatan penjualan terdiri dari penjualan barang dan 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. Dalam sistem penjualan secara tunai, barang atau jasa baru diserahkan oleh perusahaan kepada pembeli jika perusahaan telah menerima kas dari pembeli.
2.6.2. Penyewaan Menurut Anonymous (www.rapidshare.com, p.1),
penyewaan adalah
kegiatan sewa menyewa mengenai tanah, gedung, atau peralatan modal selama jangka waktu tertentu dengan pembayaran sewa berkala, termasuk kewajiban pemilik seperti pajak, pengusutan dan asuransi (lease).
54 2.6.3
Pemasaran Menurut Kotler dan Armstrong (2001, p7), pemasaran adalah suatu proses sosial dan manajerial yang membuat individu dan kelompok memperoleh apa yang mereka butuhkan dan inginkan melalui penciptaan dan pertukaran timbal balik produk dan nilai dengan orang lain. Menurut Mohammed, et. al (2003, p3), pemasaran adalah proses perencanaan dan penentuan gambaran, harga, promosi, dan distribusi dari pemikiran, barang-barang, dan jasa untuk menciptakan pertukaran yang dapat memenuhi tujuan individual maupun organisasional.
2.6.4
Analisis Strengths, Weaknesses, Opportunities, dan Threats (SWOT)
2.6.4.1 Pengertian SWOT Menurut Rangkuti (2004, p18), analisis SWOT adalah identifikasi dari berbagai faktor secara sistematis untuk merumuskan strategi perusahaan. Analisis ini didasarkan pada data yang didapat untuk memaksimalkan kekuatan (strengths) dan peluang (opportunities), namun secara bersamaan dapat meminimalkan kelemahan (weaknesses) dan ancaman (threats). Proses pengambilan keputusan yang strategis selalu berkaitan dengan pengembangan keputusan strategis, pengembangan misi, tujuan, strategis, dan kebijakan perusahaan.Dengan demikian maka untuk membuat suatu perencanaan yang strategis (strategis planner) perusahaan harus dapat menganalisis data-data (kekuatan, kelemahan, peluang, dan ancaman) yang berkaitan dengan perusahaan.
SWOT
merupakan
model
yang
penganalisaan untuk menentukan strategi perusahaan.
paling
popular
didalam
55 Pada dasarnya analisis SWOT terbagi atas dua bagian besar. Yaitu analisis lingkungan eksternal dan internal. Dimana lingkungan internal adalah kekuatan (strengths) dan kelemahan (weaknesses) serta lingkungan eksternal yang terdiri dari peluang (opportunities) dan ancaman (threats). Menurut Pearce (2000,p202), SWOT adalah singkatan dari kekuatan internal dan kelemahan serta kesempatan didalam lingkungan serta ancaman yang dihadapi suatu perusahaan pada lingkungan eksternalnya. 1. Kekuatan (strengths) Merupakan
kekuatan
utama
perusahaan
jika
dibandingkan
dengan
kompetitornya. Misalnya sumber daya, modal, keterampilan, pengalaman, keunggulan persaingan dan penguasaan pasar. 2. Kelemahan (weaknesses) Merupakan kelemahan dari perusahaan. Seperti, keterbatasan sumber daya, modal, pengalaman, dan kapabilitas yang menghambat kinerja perusahaan. 3. Peluang (opportunities) Kesempatan atau situasi yang penting yang dapat menguntungkan perusahaan didalam proses bisnisnya. 4. Ancaman (threats) Merupakan situasi yang tidak menguntungkan bagi perusahaan dan dapat membawa dampak yang merugikan bagi perusahaan.
56 2.6.4.2 Diagram Posisi SWOT Setelah melakukan analisa terhadap lingkungan internal serta eksternal perusahaan, maka akan ditemukan posisi perusahaan sesuai dengan nilai yang didapatkan dari hasil analisa tersebut.
BERBAGAI PELUANG 4.
1.
Mendukung
Mendukung
Strategi
Strategi
Turnaround
Agresif
KELEMAHAN INTERNAL
KEKUATAN INTERNAL
3.
2.
Mendukung
Mendukung
Strategi
Strategi
Defensif
Diversifikasi BERBAGAI ANCAMAN
Gambar 2.10 Diagram Posisi SWOT Sumber : Rangkuti, 2004,p19
57 Hasil yang didapatkan dari analisis akan dimasukkan kedalam diagram yang ada. Kemudian akan dilihat, kemanakah letak posisi perusahaan. Dari diagram tersebut, terdapat 4 (empat) kuadran posisi, dimana perusahaan bisa berada. Ke 4 (empat), kuadran tersebut menjelaskan posisi dan situasi perusahaan pada saat ini. Adapun penjelasan ke 4 (empat), kuadran tersebut adalah. Kuadran 1 :
Ini merupakan situasi yang sangat menguntungkan. Perusahaan tersebut memiliki peluang dan kekuatan sehingga dapat memanfaatkan peluang yang ada. Strategi yang harus diterapkan dalam kondisi ini adalah mendukung kebijakan pertumbuhan yang agresif (Growth Oriented Strategy).
Kuadran 2 :
Meskipun menghadapi berbagai ancaman, perusahaan ini masih memiliki kekuatan dari segi internal. Strategi yang harus diterapkan adalah menggunakan kekuatan untuk memanfaatkan peluang jangka panjang dengan cara strategi diversifikasi (produk / pasar).
Kuadran 3 :
Perusahaan menghadapi peluang pasar yang sangat besar, di lain pihak ia menghadapi beberapa kendala / kelemahan internal. Fokus strategi ini adalah meminimalkan masalah-masalah internal perusahaan sehingga dapat merebut peluang pasar yang lebih baik.
Kuadran 4 :
Ini merupakan situasi yang sangat tidak menguntungkan, perusahaan
tersebut
kelemahan internal.
menghadapi
berbagai
ancaman
dan
58 2.6.4.3 Cara Penentuan Faktor – faktor SWOT Penentuan faktor strategis ekternal (EFAS) : (Rangkuti,2004,p23). Sebelum membuat matrik faktor strategi eksternal, kita perlu mengetahui terlebih dahulu faktor strategi eksternal. Berikut adalah cara-cara penentuan Faktor Strategi Eksternal (EFAS) : a. Susunlah dalam kolom 1 (5 sampai dengan 10 peluang dan ancaman) b. Beri bobot masing-masing faktor dalam kolom 2, mulai dari 1,0 (sangat penting) sampai dengan 0,0 (tidak penting). Faktor-faktor tersebut kemungkinan dapat memberikan dampak terhadap faktor strategis. c. Hitung rating (dalam kolom 3) untuk masing-masing faktor dengan memberikan skala mulai dari 4 (outstanding) sampai dengan 1(poor) berdasarkan pengaruh faktor tersebut terhadap kondisi perusahaan yang bersangkutan. Pemberian nilai rating untuk faktor peluang bersifat positif (peluang yang semakin besar diberi rating +4, tetapi juka peluangnya kecil, yaitu bersifat negative. Misalnya, jika nilai ancamannya sangat besar, ratingnya adalah -4. Sebaliknya, jika nilai ancamannya sedikit ratingnya -1. d. Kalikan bobot pada kolom 2 dengan rating pada kolom 3, untuk memperoleh faktor pembobotan dalam kolom 4. Hasilnya berupa skor pembobotan untuk masing-masing faktor yang nilainya bervariasi mulai dari 4,0 (outstanding) sampai dengan 1,0 (poor). e. Jumlahkan skor pembobotan (pada kolom 4), untuk memperoleh total skor pembobotan bagi perusahaan yang bersangkutan. Nilai total ini menunjukkan bagaimana perusahaan tertentu bereaksi terhadap faktor-faktor strategis eksternalnya. Total skor ini dapat dipergunakan untuk membandingkan
59 perusahaan ini dengan perusahaan lainnya dalam kelompok industri yang sama. Penentuan faktor strategis Internal (IFAS) : (Rangkuti,2004,p25). Setelah faktor-faktor strategis internal suatu perusahaan diidentifikasi, suatu table IFAS (Internal Strategic Faktors Analysis Summary) disusun untuk merumuskan faktor-faktor strategis internal tersebut dalam kerangka strengths and weakness perusahaan. Tahapnya adalah : a. Tentukan faktor-faktor yang menjadi kekuatan serta kelemahan perusahaan dalam kolom 1. b. Beri bobot masing-masing faktor tersebut dengan skala mulai dari 1,0 (paling penting) sampai 0,0 (tidak penting), berdasarkan pengaruh faktor-faktor tersebut terhadap posisi strategis perusahaan (semua bobot tersebut jumlahnya tidak boleh melebihi skor total 1,00). c. Hitung rating (dalam kolom 3) untuk masing-masing faktor dengan memberikan skala mulai dari 4 (outstanding) sampai dengan 1 (poor), berdasarkan pengaruh faktor tersebut terhadap kondisi perusahaan yang bersangkutan. Variabel yang bersifat positif (semua variabel yang masuk kategori kekuatan) diberi nilai mulai dari +1 sampai dengan +4 (sangat baik) dengan membandingkannya dengan rata-rata industri atau dengan pesaing utama. Sedangkan variabel yang bersifat negative, kebalikannya. Contohnya, jika kelemahan perusahaan besar sekali dibandingkan dengan rata-rata industri, nilainya adalah -4, sedangkan jika kelemahan perusahaan di bawah rata-rata industri, nilainya adalah -1.
60 d. Kalikan bobot pada kolom 2 dengan rating pada kolom 3, untuk memperoleh faktor pembobotan dalam kolom 4. Hasilnya berupa skor pembobotan untuk masing-masing faktor yang nilainya bervariasi mulai dari 4,0 (outstanding) sampai dengan 1,0 (poor). e. Gunakan kolom 5 untuk memberikan komentar atau catatan mengapa faktor-faktor tertentu dipilih, dan bagaimana skor pembobotannya dihitung. f. Jumlahkan skor pembobotan (pada kolom 4), untuk memperoleh total skor pembobotan bagi perusahaan yang bersangkutan. Nilai total ini menunjukkan bagaimana perusahaan tertentu bereaksi terhadap faktor-faktor strategis internalnya. Skor total ini dapat digunakan untuk membandingkan perusahaan ini dengan perusahaan lainnya dalam kelompok industri yang sama.
2.6.4.4 Matriks SWOT Menurut Rangkuti (2004,p31) alat yang dipakai untuk menyusun faktorfaktor
strategis
perusahaan
adalah
matrik
SWOT.
Matrik
ini
dapat
menggambarkan secara jelas bagaimana peluang dan ancaman eksternal yang dihadapi perusahaan dapat disesuaikan dengan kekuatan dan kelemahan yang dimilikinya. Matrik ini dapat menghasilkan empat set kemungkinan alternatif strategis. Untuk lebih jelasnya, lihat tabel 2.2 berikut.
61 Tabel 2.2 Matriks SWOT Sumber : Rangkuti, Analisis SWOT Teknik Membedah Kasus Bisnis, 2004, p31
Strengths (S)
Weaknesses (W)
IFAS Tentukan 5-10 faktor-
Tentukan 5-10 faktor-
EFAS
faktor kekuatan internal
faktor kelemahan internal
Opportunities (O)
Strategi SO
Strategi WO
Tentukan 5-10 faktor
Ciptakan
peluang eksternal
menggunakan untuk
Treaths (T)
yang Ciptakan
strategi
memanfaatkan untuk
memanfaatkan
peluang
Strategi ST
Strategi WT
strategi
menggunakan
yang
kekuatan meminimalkan kelemahan
peluang
Tentukan 5-10 faktor Ciptakan ancaman eksternal
strategi
yang Ciptakan
strategi
yang
kekuatan meminimalkan kelemahan
untuk mengatasi ancaman
dan menghindari ancaman
a. Strategi SO Strategi ini dibuat berdasarkan jalan pikiran perusahaan, yang dengan memanfaatkan seluruh kekuatan untuk merebut dan memanfaatkan peluang sebesar-besarnya. b. Strategi ST Ini adalah strategi dalam menggunakan kekuatan yang dimiliki perusahaan untuk mengatasi ancaman.
62 c. Strategi WO Strategi ini diterapkan berdasarkan pemanfaatan peluang yang ada dengan cara meminimalkan kelemahan yang ada. d. Strategi WT Strategi ini didasarkan pada kegiatan yang bersifat defensive dan berusaha meminimalkan kelemahan yang ada serta menghindari ancaman.
