9
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
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
data yang besar dengan puluhan ribu pemakai, menggunakan ratusan query dan program aplikasi maka lifecycle akan menjadi sangat kompleks.
Gambar 2.1 Database System Development Lifecycle Sumber: Connolly dan Begg, 2005, p284
Database Planning System Definition Requirement collection and analysis Conceptual design Logical design Physical design Database Design DBMS Selection Application Design Prototyping Implementation Data Loading and conversion Testing Operational maintenance
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
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
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.
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
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.
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:
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 tipe-tipe 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.
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.
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.
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.
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,
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)
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.
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.
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.
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.
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
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.
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.
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
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
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
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_Page-Free_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.
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
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 mempertanggung- jawabkan perubahan terhadap lingkungan dan kebutuhan user. Membuat perubahan dalam sebuah area dari sistem operasional untuk meningkatkan
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)
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-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.
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
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.
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.
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
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 adalah objek dan tipe entitas yang dapat diidentifikasikan secara unik.
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.
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
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.
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
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
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 Gambar 2.8
Contoh One-to-One (1:1) Relationship Contoh One-to-Many (1:*) Relationship Sumber: Connolly dan Begg, 2005, p358 Sumber: Connolly dan Begg, 2005, p359
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
Multiplicity constraint Keterangan
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
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.
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.
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).
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 paling popular didalam penganalisaan untuk menentukan strategi perusahaan.
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.
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.
4. 1. Mendukung Mendukung Strategi Strategi Turnaround Agresif 3. 2. Mendukung Mendukung Strategi Strategi Defensif Diversifikasi
Gambar 2.10 Diagram Posisi SWOT Sumber : Rangkuti, 2004,p19 BERBAGAI ANCAMAN KELEMAHAN INTERNAL KEKUATAN INTERNAL BERBAGAI PELUANG
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 menghadapi berbagai ancaman dan kelemahan internal.
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
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.
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 faktor-faktor 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.
Tabel 2.2 Matriks SWOT
Sumber : Rangkuti, Analisis SWOT Teknik Membedah Kasus Bisnis, 2004, p31
IFAS EFAS
Strengths (S)
Tentukan 5-10 faktor- faktor kekuatan internal
Weaknesses (W)
Tentukan 5-10 faktor- faktor kelemahan internal
Opportunities (O)
Tentukan 5-10 faktor peluang eksternal
Strategi SO
Ciptakan strategi yang menggunakan kekuatan untuk memanfaatkan peluang
Strategi WO
Ciptakan strategi yang meminimalkan kelemahan untuk memanfaatkan peluang Treaths (T) Tentukan 5-10 faktor ancaman eksternal Strategi ST
Ciptakan strategi yang menggunakan kekuatan untuk mengatasi ancaman
Strategi WT
Ciptakan strategi yang meminimalkan kelemahan 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.
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.
