kegiatan merencanakan segala sesuatu

BAB 2 LANDASAN TEORI 2.1. Pengertian Umum 2.1.1. Analisis Menurut Kamus Besar Bahasa Indonesia (1988, p32), analisis adalah penguraian suatu pokok atas berbagai bagiannya dan penelaahan bagian itu sendiri serta hubungan antar-bagian untuk memperoleh pengertian yang tepat dan pemahaman arti keseluruhan. 2.1.2. Perancangan Menurut Kamus Besar Bahasa Indonesia (1988, p725), perancangan adalah suatu proses / kegiatan merencanakan segala sesuatu. 2.1.3. Pengelolaan Menurut Kamus Besar Bahasa Indonesia (1988, p441) pengelolaan adalah proses memberikan pengawasan pada semua hal yang terlibat dalam pelaksanaan kebijaksanaan dan pencapaian tujuan 2.1.4. Pengertian Sistem Menurut Fathansyah (2004, p2) sistem selalu berkonotasi pada tiga hal utama: 1. Komponen 2. Ketergantungan 3. Tujuan

7

8 Artinya setiap sistem akan selalu terdiri atas berbagai komponen yang saling berhubungan dan memiliki ketergantungan (dependence), dalam rangka mencapai satu tujuan tertentu. Dengan kata lain, bukanlah disebut sebuah sistem, jika hanya terdiri dari sebuah komponen yang saling bergantung atau jika tidak diniatkan untuk satu tujuan tertentu. 2.1.5. Pengertian Data Menurut Hoofer, Prescott, and McFadden (2002, p5), data adalah fakta yang telah diketahui, yang dapat dikumpulkan dan disimpan dalam media komputer. 2.2. Pendekatan Basis Data 2.2.1. Pengertian Basis data Menurut Connolly and Begg (2005, p15), basis data adalah suatu kumpulan data yang saling terhubung secara logikal dan dijelaskan, sehingga dirancang untuk menghubungkan informasi yang dibutuhkan terhadap suatu organisasi. 2.2.2. Karakteristik Basis data Menurut Atzeni, Ceri, Paraboschi, Torlone (2003, p3-4), basis data mempunyai beberapa karakteristik yaitu : a. Persistent Syarat suatu basis data harus bersifat persistent, karena data memiliki umur yang tidak terbatas setiap dijalankan oleh suatu program oleh user. Dan sebaliknya data diatur oleh suatu program dalam memory utama

9 sebagai penggerak dalam memulai dan mengakhiri suatu program yang dijalankan. b. Shared Basis data dapat digunakan secara bersama. Dalam hal ini berbagai macam aplikasi dan user dapat mengakses suatu data dalam kondisi apapun. Hal ini sangat penting karena dengan cara ini sifat redundancy data dapat dikurangi, karena pengulangan data harus dihindari. Sebagai konsekuensinya kemungkinan data dapat berkurang. c. Large Basis data dapat diperbesar, dalam hal ini suatu data dapat berisi jutaan byte dan umumnya suatu basis data selalu lebih besar dari memory yang tersedia. 2.2.3. Kelebihan dan Kekurangan Basis data Menurut Hoffer, Prescott, and McFadden (2002, p25-26), basis data mempunyai beberapa keuntungan antara lain : a. Pengontrolan Data Redundancy Kontrol data redudansi dilakukan dengan cara mengeliminasi data yang redundansi dengan mengintegrasikan file sehingga tidak disimpan datadata yang sama ke dalam memori. b. Data Konsistensi Dengan mengeliminasi dan mengontrol data yang redudansi, dapat memperkecil resiko dari konsistensi data yang terjadi. Misalnya terjadi

10 pengupdate-an data suatu sistem, maka untuk sistem yang lain akan dilakukan pengupdate-an secara otomatis pada data yang sama secara konsisten. c. Informasi Lebih dari Jumlah data yang sama Dengan pengintegrasian dari data operasional, mungkin saja ada penambahan data informasi ke data yang sama. d. Data Sharing Sebuah basis data yang didesain untuk digunakan sebagai sumber informasi perusahaan yang dapat digunakan oleh semua orang. User terotorisasi internal maupun eksternal dengan menggunakan basis data ini tetapi dengan kemampuan yang berbeda dalam menggunakan fasilitas basis data ini. e. Improve Data Integrity Integritas basis data mewakili dari validitas dan konsistensi dari penyimpanan data. Integritas biasanya diekspresikan oleh konstrain dimana aturan kekonsistensian basis data tidak boleh dilanggar. Konstrain dapat digunakan untuk item data untuk record tunggal atau konstrain dapat digunakan untuk hubungan antar record. f. Improved Security Pengamanan basis data dapat dilakukan dengan membentuk proteksi terhadap user yang tidak memiliki hak akses untuk mengakses basis data. g. Enforcement of Standards Ketika basis data diimplementasikan dengan dukungan penuh dari manajemen, maka administrator basis data seharusnya akan berfungsi

11 sebagai orang yang bertanggung jawab untuk menghasilkan suatu standarisasi data untuk organisasi. h. Skala ekonomi Penggabungan semua operasional data organisasi ke dalam suatu basis data dan pembuatan suatu aplikasi yang bekerja pada satu sumber data sehingga dapat memberikan penekanan biaya. i. Balance of Conflicting Requirement Setiap permintaan user atau departemen pasti memiliki perbedaan dengan permintaan user yang lain. Oleh karena itu, basis data dikontrol oleh DBA (Database Administrator), DBA dapat membuat keputusan dalam perancangan dan kegunaan operasional dalam basis data yang menyediakan penggunaan terbaik sumber daya untuk kegunaan organisasi. Selain itu penggunaan basis data menurut Hoffer, Prescott, and McFadden (2002, p25-26) juga mempunyai kekurangan antara lain : a.

New Specialized Personnel Sering kali, suatu organisasi yang menggunakan basis data perlu untuk mempekerjakan

atau

melatih

orang

untuk

mendesain

dan

mengimplementasikan basis data, menyediakan pelayanan basis data, dan mengatur staff yang terdiri dari orang-orang baru. b. Installation, Management Cost, and Complexity Multiuser database management system adalah software yang sangat rumit dan mempunyai harga initial yang tinggi, sehingga memerlukan staff yang

12 telah terlatih untuk meng-install, mengoperasikan serta setiap tahun memerlukan pemeliharaan dan biaya pendukung. Meng-install suatu sistem juga mungkin memerlukan hardware yang lebih baik dan sistem komunikasi dalam organisasi. c. Conversion cost Biaya juga diperlukan untuk mengkonversi sistem lama menjadi sistem yang baru dengan berbasiskan sistem basis data yang modern, yang dapat diukur dengan uang dan waktu. d. Need for Explicit Backup and Recovery Sebuah basis data yang digunakan secara bersama-sama haruslah akurat dan dapat digunakan setiap saat. Hal ini mengharuskan prosedur-prosedur seperti itu dikembangkan dan digunakan untuk menyediakan backup dari data, untuk memulihkan basis data bila terjadi kerusakan. e. Organizational Conflict Penggunaan basis data secara bersama-sama dalam satu perusahaan memerlukan kesepakatan dalam hal definisi data dan kepemilikan data, sama halnya dengan pertanggungjawaban terhadap keakuratan dalam pemeliharaan daya. Pengalaman telah membuktikan bahwa, konflik yang terjadi pada definisi data, format data, pemrograman data, dan kemampuan untuk mengupdate data yang digunakan, telah menjadi masalah yang sering dan sulit untuk diselesaikan. Untuk menangani masalah ini memerlukan komitmen organisasi dalam basis data.

13 2.2.4. Sistem Manajemen Basis data Menurut Connolly and Begg (2003, p16), sistem manajemen basis data adalah sebuah sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisi, membuat, menjaga, dan mengontrol akses ke basis data. Atau sistem manajemen basis data bisa juga diartikan sebagai sebuah perangkat lunak yang dapat berhubungan / berinteraksi dengan user, program aplikasi, dan basis data 2.2.4.1. Fasilitas Sistem Manajemen Basis data Secara khusus sistem manajemen basis data menyediakan fasilitas-fasilitas sebagai berikut (Connolly dan Begg, 2005 p16) : a. Mengijinkan pengguna untuk menentukan basis data, biasanya melalui Data Definition Language (DDL). DDL menyediakan fasilitas untuk menspesifikasi tipe data, struktur, dan batasan data yang disimpan di basis data. b. Mengijinkan pengguna untuk memasukkan, mengupdate, menghapus, dan mengambil data dari basis data yang biasanya disebut Data Manipulation Language (DML). c. Sistem manajemen data juga menyediakan akses kontrol terhadap basis data. Contoh akses kontrol yang tersedia di sistem manajemen basis data: • Sistem keamanan, yang dapat mencegah pengguna yang tidak terautorisasi mengakses basis data.

14 • Integrity System, yang menangani konsistensi penyimpanan data. • Concurrency and Control System, yang memungkinkan pembagian akses pengguna ke basis data. • Recovery Control System, yang dapat mengembalikan basis data ke keadaan konsisten awal apabila terjadi kesalahan pada perangkat lunak maupun perangkat keras. • User accessible catalog, yang berisi penjelasan dari dalam basis data. 2.2.4.2. Komponen-komponen dari sistem manajemen basis data Menurut Connolly dan Begg (2005, p19) komponen utama dalam sistem manajemen basis data adalah : 1. Hardware (Perangkat Keras) Sistem

manajemen

basis

data

membutuhkan

hardware

untuk

menjalankan aplikasi. Beberapa hardware berpengaruh pada kebutuhan organisasi dan sistem manajemen basis data yang digunakan. 2. Software (Perangkat Lunak) Komponen dari software terdiri dari software sistem manajemen basis data itu sendiri dan program aplikasi, yang saling terhubung melalui sistem operasi termasuk software jaringan jika sistem manajemen basis data tersebut berjalan diatas jaringan. 3. Data Data adalah komponen terpenting dalam sistem manajemen basis data. Data berfungsi sebagai penghubung diantara komponen mesin dan komponen manusia.

15 4. Procedure Procedure adalah instruksi dan peraturan yang menentukan perancangan dan penggunaan dari basis data. User yang berada di sistem dan staff mengatur kebutuhan basis data dalam mencatat procedure bagaimana menggunakan atau menjalankan sistem tersebut. 5. People (orang) People dapat diidentifikasi berdasarkan 4 jenis yang berhubungan dengan sistem manajemen basis data dan basis data administrator, perancang basis data, pengembang aplikasi di End user. 2.2.4.3. Karakteristik Sistem Manajemen Basis data Menurut Atzeni, Ceri, Paraboschi, Torlone (2003, p3-4) sistem manajemen basis data memiliki karakteristik : 1. Large Suatu sistem manajemen basis data harus mengatur data yang berada di secondary memory. Pada dasarnya jumlah basis data yang sedikit dapat dilakukan, tetapi sistem harus terus mampu mengatur data tanpa mengenal namanya batasan dimensi yang terpisah dari salah satu alat physical. 2. Shared Untuk menjamin suatu data dapat diakses oleh multi user, operasi yang berjalan harus bersifat terus menerus. Oleh karena itu, sistem

16 manajemen basis data menggunakan salah satu yang bersifat khusus yang disebut concurrency control. 3. Reliability Sistem manajemen basis data harus bersifat tahan uji karena, jumlah sistem yang berada dalam basis data harus bersifat tahan lama termasuk dalam masalah kerusakan yang bersifat perangkat lunak maupun perangkat keras. Untuk memenuhi syarat kebutuhan tersebut, sistem manajemen basis data menyediakan fungsi yang spesifik yaitu backup & recovery. 4. Privacy Sistem manajemen basis data harus bersifat privacy, yang mana sistem tersebut harus dapat dikenal oleh user yang penamaannya bersifat spesifik, sehingga user memiliki hak akses tersendiri untuk masuk ke dalam sistem. 5. Efisien Sistem manajemen basis data harus bersifat efisien, maksudnya adalah kemampuan

untuk

menjalankan

sekumpulan

operasi

dengan

berdasarkan sumber waktu dan ruang untuk masing-masing user. Karakteristik tersebut harus dengan berdasarkan implementasi dari DBMS. 6. Efektivitas Sistem manajemen basis data dapat meningkatkan efektivitas, maksudnya adalah kapasitas sistem basis data yang ada untuk merancang kegiatan produktif dari setiap user dalam setiap waktu.

17 2.2.4.4. Keuntungan menggunakan sistem manajemen basis data Menurut Connolly dan Begg (2005, p26), keuntungan dari sistem manajemem basis data adalah : 1. Mengatur data redundansi Pendekatan

basis

data

berusaha

menghapus

redundansi

dengan

menggabungkan file sehingga data yang sama tidak akan disimpan kembali. Dengan tujuan untuk mengatur jumlah redundansi yang terdapat pada basis data. Namun dalam beberapa kondisi, beberapa data yang duplikat diperlukan untuk meningkatkan performance. 2. Data konsistensi Dengan menghapus atau mengontrol redundansi, maka akan mengurangi resiko ketidak konsistensian yang akan muncul. Jika sebuah data disimpan hanya satu kali pada basis data, update apapun terhadap nilai data tersebut hanya dilakukan satu kali dan nilai baru tersedia untuk user. 3. Informasi yang lebih dari jumlah data yang sama Dengan integrasi dari data operasional, maka memungkinkan bagi perusahaan untuk menurunkan informasi tambahan dari data yang sama. 4. Data yang dibagi File

biasanya

dimiliki

oleh

orang

atau

departemen

yang

menggunakannya. Di sisi prolain, basis data adalah milik keseluruhan orgranisasi dan dapat dibagi-bagi kepada user dengan hak aksesnya.

18 5. Meningkatkan integritas data Integritas data mewakili validitas dan konsistensi data yang disimpan. Integritas biasanya digambarkan dalam bentuk constraint, yang merupakan peraturan yang konsisten pada basis data yang tidak diijinkan untuk dilanggar. 6. Meningkatkan keamanan Keamanan basis data adalah perlindungan basis data dari user yang tidak memiliki hak akses. User yang memiliki hak akses dibatasi oleh tipe operasi yaitu pengambilan, memasukkan, meng-update, dan menghapus data. 7. Enforcement of standard Seorang DBA (Database Administrator) untuk mendefinisikan dan menjalankan kebutuhan standarisasi. Dalam hal ini termasuk didalamnya standarisasi departemen, standarisasi organisasi, standarisasi nasional / internasional dalam hal ini sebagai format data untuk memfasilitasi pergantian data diantara sistem, standarisasi dokumen, update prosedur dan peraturan akses. 8. Skala ekonomi Gabungan semua organisasi operasional data kedalam satu basis data dan membuat sekumpulan aplikasi yang bekerja pada satu sumber data, dapat menghasilkan penekanan biaya. 9. Balance of conflicting requirements Seorang DBA dapat membuat keputusan mengenai perancangan dan operational dalam menggunakan basis data secara terbaik yang digunakan

19 dari sumber untuk keseluruhan dalam organisasi. Keputusan ini dapat meningkatkan performa untuk aplikasi penting, yang memungkinkan mengurangi biaya sebagai salah satu hal yang kritis. 10. Improve data accessibility dan responsive Sebagai hasil integrasi, data yang bersilangan dengan batasan departemen akan secara langsung diakses oleh pengguna akhir. Proses ini menyediakan sistem dengan fungsionalitas yang lebih bagus. 11. Meningkatkan produktivitas Sebagai tahap awal DBMS menyediakan semua pengaturan file tingkat rendah secara terus menerus dalam program aplikasi. Banyak sekali DBMS yang menyediakan fourth generation (4G) termasuk didalamnya alat untuk mempermudah pengembangan aplikasi basis data. 12. Improved maintenance through data independence Pada sistem berbasiskan file, deskripsi data dan logika untuk mengakses data dibangun ke dalam setiap program aplikasi, membuat program bergantung pada data. Pada DBMS, memisahkan deskripsi data dari aplikasi sehingga membuat aplikasi terpisah dari perubahan deksripsi data. Hal ini disebut dengan independensi data. 13. Meningkatkan concurrency Pada sistem berbasiskan file, jika terdapat dua atau lebih user diperbolehkan untuk mengakses file yang sama secara simultan, maka pengaksesan akan saling mengganggu satu sama lain yang menghasilkan kehilangan informasi atau bahkan kehilangan integritas. DBMS mengatur

20 akses basis data pada saat yang bersamaan dan memastikan masalah seperti di atas tidak muncul. 14. Meningkatkan backup dan recovery services Setiap file yang berada di dalam sistem bertanggung jawab terhadap user untuk mengukur seberapa besar data tersebut terlindung dari kegagalan sistem komputer atau aplikasi program. Backup adalah mengembalikan data sekaligus berfungsi untuk mengambil alih sejak data tersebut hilang. 2.2.4.5. Kerugian dari sistem manajamen basis data Kerugian dari sistem manajemen basis data adalah sebagai berikut : 1. Complexity Perancang dan pengembang basis data, data dan database administrator, serta pengguna akhir harus memahami keseluruhan fungsionalitas DBMS yang kompleks. Kegagalan untuk memahami sistem dapat menghasilkan suatu keputusan rancangan yang buruk dimana akan terdapat konsekuensi yang serius untuk perusahaan. 2. Size Kompleksitas dan kedalaman fungsionalitas membuat DBMS sebagai sebuah potongan perangkat lunak yang besar, memakan banyak megabyte dari tempat penyimpanan dan membutuhkan jumlah memory yang cukup untuk menjalankannya. 3. Cost of DBMS Biaya DBMS sangat bervariasi, tergantung pada lingkungan dan fungsionalitas yang dibutuhkan.

21 4. Additional Hardware costs Kebutuhan

tempat

penyimpanan

untuk

DBMS

dan

basis

data

membutuhkan pembelian tempat penyimpanan tambahan. Selanjutnya, untuk mendapatkan performa yang diinginkan, maka diperlukan untuk membeli mesin yang lebih besar, bahkan mesin yang diperuntukkan untuk menjalankan

DBMS.

Penambahan

perangkat

keras

baru

akan

menghasilkan pengeluaran biaya. 5. Cost of conversion Pada beberapa situasi, biaya DBMS dan perangkat keras tambahan menjadi tidak signifikan jika dibandingkan dengan biaya konversi aplikasi yang telah ada untuk dijalankan pada DBMS dan perangkat keras baru. Biaya tambahan juga termasuk biaya pelatihan staff untuk menggunakan sistem baru dan mungkin mempekerjakan staff ahli untuk membantu melakukan konversi dan menjalankan sistem. Biaya-biaya inilah yang menjadi alasan utama mengapa beberapa perusahaan merasa tidak perlu berpindah ke teknologi basis data modern dan tetap menjalankan yang sudah ada. 6. Performance Biasanya, sistem berbasis file ditulis untuk aplikasi tertentu, seperti faktur.

Sebagai

hasilnya,

performance

secara

umum

bagus.

Bagaimanapun, DBMS ditulis lebih umum. Efeknya adalah beberapa aplikasi mungkin tidak dapat berjalan dengan cepat seperti biasanya.

22 7. Higher impact of a failure Sumber yang terpusat dapat meningkatkan lemahnya dari sistem tersebut. Semua user dan aplikasi bersumber dari ketersediaan dalam DBMS, kegagalan terhadap komponen dapat menyebabkan operasi berhenti.

23 2.2.5. Siklus Hidup Aplikasi Basis data (Basis data Aplication Lifecycle) Siklus atau daur hidup sebuah aplikasi basis data menurut Connolly and Begg (2005, p284) digambarkan sebagai berikut : Perencanaan Basis data Definisi Sistem Pengumpulan dan Analisa Data Perancangan Basis data

Perancangan Basis data konseptual

Memilih DBMS

Perancangan Basis data Logikal

Perancangan Aplikasi

Perancangan Basis data Physical

Prototyping (pilihan)

Implementasi Konversi data dan Loading Testing Pemeliharaan Operasional Gambar 2.1. Siklus Aplikasi Basis data (Sumber : Connolly dan Begg, 2005, p)

24 Adapun Penjelasan dari daur hidup diatas adalah : 1.

Perencanaan Basis data Menurut Connolly dan Begg Perencanaan basis data (2005, p285) adalah aktivitas manajemen yang memungkinkan tahapan dari aplikasi basis data untuk dapat direalisasikan seefisien dan seefektif mungkin. Perencanaan basis data harus dapat diintegrasikan dengan keseluruhan strategi sistem informasi organisasi. Terdapat tiga hal penting yang terlibat dalam memformulasikan sebuah strategi sistem informasi dengan perencanaan basis data, yaitu : • Mengidentifikasi rencana dan tujuan perusahaan dengan penentuan sistem infromasi yang diperlukan • Mengevaluasi sistem informasi yang digunakan sekarang untuk menentukan kekuatan dan kelemahan • Penilaian tentang peluang teknologi informasi yang mungkin menghasilkan keuntungan yang kompetitif Perencanaan basis data juga harus meliputi pengembangan standar pengumpulan data, bagaimana penetapan format dan dokumentasi yang diperlukan, bagaimana desain dan implementasi diproses.

2.

Definisi Sistem Kegiatan utamanya adalah menspesifikasikan ruang lingkup dan batasan dari aplikasi basis data dan user views utama. Menurut Connolly and Begg (2005, p286) User Views adalah mendefinisikan apa yang dibutuhkan aplikasi basis data berdasarkan dari sudut pandang peran pekerjaan tertentu (misal manager atau

25 supervisor) atau area aplikasi enterprise (misal marketing, personil, atau control stok). Setiap perusahaan memiliki sistem dan setiap sistem memiliki sebuah aplikasi basis data yang mempunyai satu atau lebih user view yang merupakan aspek terpenting. Alasannya adalah karena setiap sistem yang dibuat harus sesuai dengan kebutuhan dari masing-masing user yang bekerja di sistem tersebut. Tujuan dari user view adalah untuk membantu dan memastikan tidak ada pengguna dari basis data yang terlupakan saat membangun dan mengembangkan kebutuhan-kebutuhan untuk aplikasi yang baru. 3.

Pengumpulan dan Analisa Data Proses mengumpulkan dan menganalisa informasi atau data mengenai bagian dari organisasi yang didukung oleh aplikasi basis data. Dengan menggunakan informasi ini bertujuan untuk mengidentifikasi kebutuhan pengguna sistem baru. Informasi tersebut diambil dengan berdasarkan dari tiap-tiap user view yang penting dimana di dalamnya termasuk : •

Deskripsi tentang bagaimana data digunakan atau dibuat

•

Penjelasan dari bagaimana data akan digunakan atau dibuat

•

Kebutuhan tambahan untuk aplikasi basis data baru

Pada bagian ini dilakukan pengumpulan dan analisa informasi tentang bagian-bagian dari organisasi yang memiliki keterkaitan dengan basis data yang akan dibuat. Untuk itu digunakan teknik Fact Finding Techniques.

26 Menurut Connolly dan Begg Terdapat lima teknik Fact Finding Techniques yang umum digunakan (2005 p315) : 1. Pengkajian Terhadap Dokumen Pengkajian terhadap dokumen seperti laporan, dokumen penting, faktur, dan berbagai data yang berkaitan dengan sistem, yang akan sangat berguna dalam menentukan kebutuhan basis data yang akan dibangun. 2. Wawancara Digunakan untuk mengumpulkan informasi secara langsung melalui tatap muka dengan individual yang berkaitan. Beberapa tujuan dari teknik ini adalah mengumpulkan fakta-fakta, memeriksa kebenaran

fakta yang ada dan

mengklarifikasinya, mengidentifikasi kebutuhan-kebutuhan dan mengumpulkan ide-ide dan pendapat. 3. Mengobservasi jalannya kegiatan kerja perusahaan Sangat berguna apabila kita menemukan kejanggalan analisis data dari metode yang telah dilakukan sebelumnya dengan berpartisipasi secara langsung untuk mendapatkan gambaran langsung dari sistem yang berjalan. 4. Penelitian Mencari referensi seperti jurnal, buku, dan melalui internet yang memiliki pemecahan atas masalah serupa dengan masalah yang sedang dihadapi. 5. Kuisioner Pengumpulan dokumen dengan tujuan khusus yang didapat dari pengumpulan fakta-fakta dari banyak orang sambil menjaga kontrol terhadap tanggapan yang diberikan

27 4.

Desain Basis Data Desain basis data adalah proses dalam menciptakan desain untuk basis data yang akan mendukung operasi dan tujuan organisasi. Desain basis data dibuat dalam tiga fase utama, yaitu : 1. Desain konseptual basis data Proses mengkonstruksikan / membangun model informasi yang digunakan dalam sebuah organisasi, yang terbebas dari semua pertimbangan fisik. 2. Desain logikal basis data Proses membangun model informasi yang digunakan dalam sebuah enterprise yang didasarkan oleh data model spesifik, dan terbebas dari sistem manajemen basis data (DBMS) tertentu dan pertimbangan fisik lainnya. 3. Desain physical basis data Proses memproduksi sebuah deskripsi dari implementasi basis data dalam secondary storage, yang menjelaskan relasi dasar, organisasi file, dan indeks yang digunakan untuk mencapai akses yang efisisen ke data dan setiap integrity constraint yang saling berhubungan dan juga pengukuran keamanan. (security)

5.

Penyeleksian Sistem Manajemen Basis data Pada tahap ini dilakukan seleksi sistem manajemen basis data yang cocok untuk mendukung aplikasi basis data. Berikut ini adalah tahapan utama untuk menseleksi basis data adalah : 1. Menggambarkan cakupan tugas berdasarkan kebutuhan perusahaan 2. Membuat perbandingan mengenai dua atau tiga produk 3. Mengevaluasi produk-produk sistem manajemen basis data yang dipilih

28 4. Merekomendasikan pemilihan sistem manajemen basis data dan membuat laporan hasil evaluasi produk-produk sistem manajemen basis data tersebut. 6.

Desain Aplikasi Desain aplikasi yaitu mendesain antarmuka pengguna dan program aplikasi yang menggunakan dan memproses basis data. Pada tahap ini harus dipastikan semua spesifikasi kebutuhan pengguna terdapat di dalam desain aplikasi untuk aplikasi basis data. Desain aplikasi dibagi menjadi dua aspek, yaitu : 1. Desain Transaksi Transaksi dapat diartikan sebagai sebuah atau serangkaian aksi, yang dilakukan oleh seorang user atau program aplikasi, yang mengakses atau mengubah isi dari basis data. Terdapat tiga utama transaksi: o Retrieval Transaction, contohnya tampilan detil data properti (data ditampilkan dalam bentuk angka) o Update Transaction, contohnya operasi untuk memasukkan detil data property baru ke dalam basis data. o Mixed Transaction, contohnya operasi untuk mencari detil data property, menampilkannya dan kemudian mengupdate nilainya. 2. Panduan Desain Antarmuka Pengguna Elemen-elemen dalam merancang suatu antarmuka pengguna (user interface) antara lain penetapan judul yang bermakna, instruksi-instruksi yang dapat dipahami, pengelompokkan logika dan pengurutan kolom, bentuk form yang menarik secara visual, judul kolom yang dikenal, penggunaan istilah dan

29 singkatan yang konsisten, penggunaan warna yang konsisten, ruang dan batasan yang terlibat untuk menginput kolom, pergerakan kursor yang mudah, perbaikan kesalahan untuk satu huruf dan semua kolom, mencegah kesalahan, menampilkan pesan kesalahan terhadap nilai yang tidak sesuai, pemberian tanda terhadap kolom yang berupa pilihan (optional field), pesan-pesan yang bersifat penjelasan untuk suatu kolom, pemberian tanda penyelesaian. 7. Prototyping Prototyping adalah proses membangun model kerja (working model) dari aplikasi basis data. Tujuan utama dari membangun prototype aplikasi basis data adalah untuk memungkinkan

pengguna

menggunakan

prototype

tersebut

untuk

mengidentifikasikan fitur dari sistem yang bekerja dengan baik, dan apabila memungkinkan untuk dapat menyarankan improvisasi atau bahkan membuat fitur baru ke aplikasi basis data. 8. Implementasi Implementasi adalah realisasi fisik dari basis data dan desain aplikasi. Implementasi basis data dilakukan dengan menggunakan Data Definition Language (DDL) dari DBMS yang dipilih atau dengan menggunakan Graphical User Interface (GUI), yang menyediakan fungsionalitas yang sama dengan saat menyembunyikan statemen low-level DDL. Program aplikasi diimplementasikan menggunakan bahasa generasi ketiga atau keempat (3GL atau 4 GL). Bagian dari program aplikasi ini adalah transaksi basis data, yang diimplementasikan dengan menggunakan Data Manipulation Language (DML), yang biasanya sudah terdapat dalam bahasa pemrograman. Selain itu pada tahap ini diimplementasikan pula keamanan dan kontrol integritas.

30 9.

Loading dan Konversi Data Pada tahap ini dilakukan transfer semua data ke dalam basis data yang baru dan mengkonversi aplikasi yang ada untuk dijalankan di basis data yang baru.

10. Testing Testing adalah proses mengeksekusi program aplikasi dengan tujuan menemukan kesalahan. Beberapa keuntungan melakukan testing : −

Menemukan error (kesalahan) program aplikasi dan mungkin juga kesalahan struktur basis data.

−

Testing mendemonstrasikan bahwa basis data dan program aplikasi dapat berjalan sesuai dengan kebutuhan performa dan spesifikasi yang diinginkan atau tidak.

11.

Perawatan Operasional Perawatan operasional adalah proses memonitor dan merawat sistem setelah dilakukan instalasi. Pada tahap ini melibatkan beberapa aktivitas : −

Memonitor performa sistem. Apabila performa berada di level bawah, maka dibutuhkan tunning atau reorganisasi basis data

−

Memelihara dan mengupgrade aplikasi basis data (apabila dibutuhkan).

2.2.6. Entity Relationship Modeling Menurut Connolly dan Begg (2005, p342), salah satu aspek terpenting dari perancangan basis data adalah suatu kenyataan bahwa seorang perancang, programmer, dan end-user cenderung dalam melihat data memilki cara yang berbeda. Oleh karena itu, untuk memastikan pemahaman yang tepat tentang

31 sifat data dan bagaimana data tersebut digunakan oleh organisasi / perusahaan, maka dibutuhkan suatu model untuk berkomunikasi yang bersifat non teknis dan bebas dari ambiguitas. Salah satu contohnya adalah : model Entity Relationship. Pemodelan Entity Relationship menggunakan pendekatan basis data secara top-down untuk merancang basis data dengan cara mengidentifikasi data penting disebut entities dan relationship antara data yang harus ditampilkan dalam model. Kemudian menambah lebih banyak detail seperti informasi mengenai entities dan relationship yang disebut attributes dan berbagai constraints dalam entities, relationship, dan attributes. 2.2.6.1. Tipe Entity (Entity Type) Tipe entity adalah sekumpulan objek dengan property yang sama yang mana diidentifikasikan oleh suatu organisasi / perusahaan yang keberadaannya bersifat independen. Konsep dasar dari model entity relationship adalah tipe entity (entity type). Suatu tipe entity memiliki keberadaannya yang bebas dan bisa menjadi objek dengan physical (nyata) keberadaannya atau objek dengan keberadaannya bersifat konseptual (abstrak). Setiap objek dari suatu tipe entity dapat diidentifikasikan secara unik. Yang disebut sebagai entity occurrence. Setiap entity digambarkan dalam bentuk segiempat yang di jelaskan melalui nama dari entity tersebut, yang

32 biasanya berupa kata benda tunggal. Dalam UML huruf pertama setiap kata dalam nama entity berupa huruf kapital.

Nama Entity

Pegawai

Cabang

Gambar 2.2. Contoh Tipe Entity (Sumber : Connolly dan Begg, 2005, p345) 2.2.6.2. Tipe Relasi (Relationship Types) Tipe relationship adalah sejumlah hubungan antara satu atau banyak tipe entity yang terlibat. Setiap tipe relasi (relationship type) memliki nama yang menggambarkan fungsinya. Suatu asosiasi yang digambarkan secara unik, yang didalamnya memiliki satu kejadian dari setiap bagian dari tipe entity. Setiap tipe relasi ditampilkan sebagai sebuah garis yang dihubungkan dengan tipe entity, ditandai dengan nama dari relasi. Dan setiap relasi hanya ditandai oleh satu garis. Secara umum sebuah relasi dinamai menggunakan kata kerja (contoh : Supervises atau Manages) atau frase pendek termasuk didalamnya kata kerja (contoh : leased by). Setiap huruf pertama dari setiap kata dalam nama relasi ditulis dengan huruf besar.

33 Jika memungkinkan, setiap nama relasi harus unik untuk setiap model ER yang diberikan.

Nama Relasi

Pegawai

Memiliki

Cabang

Gambar 2.3. Contoh Tipe Relasi (Sumber : Connolly dan Begg 2005, p347) Derajat tipe relasi adalah sekumpulan tipe entity yang terlibat dalam satu relasi. Entity yang terlibat dalam sebuah tipe relationship tertentu dikenal sebagai participant dalam relationship tersebut. Jumlah participant dalam tipe relasi disebut derajat dari suatu relasi (relationship). Oleh karena itu derajat relasi menjelaskan bahwa jumlah dari tipe entity memilki keterkaitan dalam sebuah relasi. Sebuah relasi yang memilki dua derajat disebut binary.

34 Pemilik

memiliki

Properti

Gambar 2.4. Contoh tipe relasi binary (Sumber : Connolly dan Begg 2005 p348)

Sebuah relasi (relationship) yang berderajat tiga disebut ternary

Pegawai

Cabang

Registers

Client

Gambar 2.5. Contoh tipe relasi ternary (Sumber : Connolly dan Begg 2005, p348) Sebuah relasi yang berderajat empat disebut quarternary. Pencari Langganan

Pembeli

Mengatur

Tawaran

Gambar 2.6 Contoh tipe relasi quarternary (Sumber : Connolly dan Begg, 2005, p349)

Bagian Keuangan

35 2.2.6.3. Attribut Menurut Connolly dan Begg (2005, p350) atribut adalah sebuah property dari satu entity atau tipe relasi (relationship type). Setiap atribut diasosiasikan dengan sejumlah nilai yang disebut domain. Domain tersebut memiliki nilai potensial yang atribut tersebut dapat disimpan sama halnya dengan konsep domain dalam model relational. Simple attribute adalah sebuah atribut yang dirangkai dari satu buah komponen dengan keberadannya bebas. Simple attribute tidak dapat dibagi ke dalam komponen yang lebih kecil. Misal : atribut posisi dan gaji dari entity pegawai. Simple attribute terkadang disebut atomic attribute. Composite attribute adalah sebuah atribut yang dirangkai dari beberapa komponen yang setiap atribut tersebut memiliki keberadaan yang bebas. Beberapa atribut dapat dipecah menjadi beberapa komponen dengan keberadaan yang bebas dari masing-masingnya. Contohnya atribut alamat dari entity kantor cabang yang mengandung nilai (jalan, kota, kode pos) bisa dipecahkan menjadi atribut sederhana jalan, kota dan kode pos. Single valued attribute adalah sebuah atribut yang hanya menyimpan 1 nilai dari setiap kejadian / sifat dari tipe entity.

Multi

valued

attribute adalah sebuah atribut yang memiliki banyak nilai dari setiap sifat / kejadian yang berada dari setiap tipe entity.

36 Derived attribute adalah sebuah atribut yang menunjukkan nilai yang diperoleh dari atribut yang berhubungan tidak terlalu perlu dalam tipe entity yang sama. 2.2.6.4. Keys Candidate key adalah jumlah minimal dari sekumpulan atribut yang diidentifikasikan secara unik dalam setiap kejadian / sifat dari tipe entity. Primary key adalah jumlah key yang digunakan secara unik untuk mengenali setiap occurrence (kejadian) dari suatu tipe entity. Terpilihnya primary key dari suatu entity menjadi dasar dari pertimbangan panjangnya atribut, jumlah minimal atribut yang dibutuhkan, serta keunikan-keunikan yang lain dari suatu atribut. Composite key adalah suatu candidate key yang terdiri dua atau lebih atribut.

Contohnya,

entity

Advert

memiliki

atribut

propertyNo,

newspaperName, dateAdvert dan cost. Banyak properti yang diiklankan dalam banyak koran pada waktu yang diberikan. Jadi, entity Advert mempunyai composite primary key yang berasal dari atribut propertyNo, newsapaperName dan dateAdvert. 2.2.6.5. Structural Constraints Constraint mencerminkan pembatasan (restriction) pada relationship sebagai perhatian (perceived) didalam kenyataan. Tipe utama dari constraint adalah multiplicity. Menurut Connolly dan Begg (2005, p356)

37 multiplicity adalah jumlah kemungkinan occurrence dari sebuah entity yang menghubungkan sebuah occurrence tunggal dari hubungan entity melalui relationship tertentu. Multiplicity constraint adalah jalan dimana entity dihubungkan melalui relationship tertentu. Seperti yang disebutkan sebelumnya bahwa relationship berderajat dua (binary), umumnya bisa ditunjukkan sebagai hubungan one to one (1:1), one to many (1:*) atau many to many (*:*). 2.2.6.5.1. One-to-one relationship

Gambar 2.7. Contoh one-to-one relationship (Sumber : Connolly dan Begg, 2005, p357) 2.2.6.5.2 One-to-many relationship

38 Gambar 2.8. Contoh one-to-many relationship (Sumber : Connolly dan Begg, 2005, p358) 2.2.6.5.3 Many-to-many relationship

Gambar 2.9. Many-to-many relationship (Sumber : Connolly dan Begg, 2005, p360) Multiplicity Constraint •

0..1

: Nol atau satu entity occurrence

•

1..1 (atau 1)

: Tepatnya hanya satu entity occurrence

•

0..* (atau *)

: Nol atau banyak entity occurrence

•

1..*

: Satu atau banyak entity occurrence

2.2.7. Perancangan Basis data 2.2.7.1. Desain konseptual basis data Proses mengkonstruksikan / membangun model informasi yang digunakan dalam sebuah organisasi, yang terbebas dari semua pertimbangan fisik. Pada konseptual basis data desain ini terdiri dari langkah-langkah sebagai berikut :

39 Langkah 1 : Membangun data model konseptual lokal Untuk membangun model data konseptual dari kebutuhan data berdasarkan suatu organisasi 1.1. Mengidentifikasi tipe entity Untuk mengidentifikasi kebutuhan dari tipe entity. Langkah awal untuk membangun model data konseptual adalah untuk mendefinisikan tujuan utama yaitu keinginan user. Salah satu metode dalam mengidetifikasi tipe entity adalah dengan memeriksa kebutuhan user. Dari kebutuhan user ini, dapat ditemukan kata benda atau frase yang ada (misalnya nomor pegawai, nama pegawai, alamat rumah), selain itu bisa diperoleh objek utama seperti orang, tempat. Cara lain dalam mengidentifikasi entity adalah dengan melihat objekobjek yang ada dan keberadaannya tidak tergantung pada objek lain, misalnya staff merupakan entity, karena staff tetap akan ada walaupun kita tidak mengetahui nama, posisi dan tanggal lahirnya. 1.2. Mengidentifikasi tipe relasi Untuk mengidentifiikasi relationship utama yang berada diantara tipetipe entity. Ketika mengidentifikasi entity salah satu metodenya adalah untuk mencari kata sebagai spesifikasi kebutuhan user. Misalnya : •

Staff mengatur property

•

PrivateOwner mempunyai property

40 Untuk

menampilkan

masing-masing

entity

maka

dibuatlah

entity-

relationship diagram. Tujuannya adalah agar mudah dilihat dengan entity yang saling berhubungan. 1.3. Mengidentifikasi dan menghubungkan atribut dengan entity atau tipe relationship Untuk menghubungkan attribute dengan entity atau tipe relationship yang tepat. Salah satu caranya adalah dengan mencari kata benda atau frase dalam basis data sesuai dengan spesifikasi kebutuhan user. 1.4. Menentukan domain atribut Untuk menentukan domain untuk atribut dalam model data konseptual lokal. Domain adalah sebuah penampung dari nilai yang dapat ditampung oleh attribut dari nomor staff hanya dapat menggunakan 5 karakter string dengan 2 karakter pertama adalah huruf dan 3 karakter berikutnya adalah angka. 1.5. Menentukan candidate key, primary key, dan alternate key dari attribute Candidate key adalah sekumpulan atribut minimal dari sebuah entity yang secara unik mengidentifikasi setiap kemunculan dari entity tersebut. Candidate key dapat diidentifikasikan lebih dari satu, tetapi harus dipilih satu sebagai primary key, sedangkan candidate key yang lain disebut alternate key. Berikut ini adalah acuan dalam menentukan primary key dari candidate key : • Candidate key dengan set atribut yang minimal • Candidate key dengan nilai yang berubah paling sedikit

41 • Candidate key dengan karakter paling sedikit • Candidate key dengan isi maksimum yang paling sedikit • Candidate key yang termudah digunakan dari sudut pandang user 1.6. Mempertimbangkan penggunaan konsep model yang lebih tinggi (enhanced modeling concepts) optional Untuk mempertimbangkan menggunakan konsep model yang lebih tinggi seperti specialization / generalization. 1.7. Memeriksa redudansi pada model Tahapan ini memeriksa model data konseptual lokal apakah terjadi duplikasi atau tidak, dengan melalui tiga langkah yaitu : • Memeriksa ulang relasi one-to-one • Menghilangkan relasi yang terduplikasi (redundant) • Mempertimbangkan dimensi waktu 1.8. Memvalidasi model data konseptual lokal terhadap transaksi user Untuk memastikan bahwa model konseptual mendukung kebutuhan transaksi. Pemeriksaan ini dapat menggunakan dua langkah yaitu: • Mendeskripsikan transaksi • Menggunakan jalur transaksi 1.9. Memeriksa model data konseptual lokal dengan user Untuk mengevaluasi model data konseptual dengan user untuk memastikan bahwa model yang ditampilkan adalah benar dari kebutuhan data suatu organisasi.

42 Memeriksa model data konseptual lokal termasuk ER diagram dan dokumentasi pendukung yang menjelaskan data model. Jika terjadi ketidakcocokan (abnomaly) maka harus dilakukan perubahan yang tepat dengan mengulangi langkah sebelumnya. 2.2.7.2. Desain Logikal Basis data Proses membangun model informasi yang digunakan dalam sebuah enterprise yang didasarkan oleh data model spesifik, dan terbebas dari sistem manajemen basis data (DBMS) tertentu dan pertimbangan fisik lainnya. Pada desain logikal basis data terdiri dari langkah-langkah sebagai berikut: Langkah 2 : Membangun dan memvalidasi model data logikal lokal Untuk menerjemahkan model data konseptual ke dalam model data logikal dan memvalidasi terhadap model tersebut yang bertujuan untuk memeriksa bahwasanya strukturnya tepat dan mampu untuk mendukung kebutuhan transaksi 2.1. Mendapatkan relasi untuk model data logikal Membentuk merepresentasikan

relasi

dari

relasi

model

antar

entity

data dan

logikal attribut

lokal yang

untuk telah

diidentifikasikan. Untuk mendapatkan relasi dari data model yang ada maka digunakan cara-cara berikut ini : •

Tipe entity yang kuat

43 •

Tipe entity yang lemah

•

Tipe relasi binary one-to-many (1:*)

•

Tipe relasi binary one-to-one (1:1)

•

Tipe relasi recursive one-to-one (1:*)

•

Tipe relasi superclass / subclass

•

Tipe relasi binary many-to-many (*:*)

•

Tipe relasi complex

•

Multi-valued attributes

2.2. Memvalidasi relasi menggunakan normalisasi Untuk memvalidasi relasi dalam model data logikal dengan menggunakan normalisasi. Tujuan dari normalisasi adalah untuk memastikan bahwa sekumpulan relasi mendukung kebutuhan data dari suatu organisasi. 2.3. Memvalidasi relasi sebagai transaksi user Untuk memastikan relasi yang telah ada pada model data logikal sehingga mendukung transaksi yang diperlukan oleh view. 2.4. Memeriksa integrity constraint Untuk memeriksa integrity constraint ditampilkan dalam model data logikal. Integrity constraint adalah batasan yang digunakan untuk menjaga agar basis data tidak menjadi inconsistent. Ada 5 tipe integrity constraint :

44 •

Required data (data / nilai yang valid)

•

Batasan domain constraints

•

Multiplicity

•

Entity integrity (primary key tidak boleh null)

•

Referential integrity (foreign key pada suatu entity harus sesuai dengan candidate key pada entity lain)

•

General constraint (batasan pada organisasi)

2.5. Mengevaluasi model data logikal dengan user Untuk memeriksa model data logikal dengan user dengan tujuan memastikan bahwa user mempertimbangkan model yang ditampilkan benar dari kebutuhan data suatu organisasi. Dan sekaligus hubungan antara model data logikal dengan diagram aliran data(DFD). Semua atribut harus ditampilkan dalam setiap entity dalam suatu perusahaan, dengan tujuan untuk mengetahui aliran data yang berjalan di perusahaan tersebut. 2.6. Menggabungkan model data logikal dengan model global (Optional) Untuk menggabungkan model data logikal ke dalam satu model data logikal global yang menampilkan semua user view dari suatu basis data. Pada tahapan ini hanya merancang basis data dengan multiple user view yang diatur dengan menggunakan view integration approach. Kegiatan dalam tahap ini meliputi : 1.

Menggabungkan model logikal data lokal ke dalam model global

45 Dalam model logikal data lokal menghasilkan ERD (Entity Relationship Diagram), skema relational (relational schema), kamus data

(data

dictionary)

dan

dokumentasi

pendukung

yang

menggambarkan batasan-batasan (constraints) dalam model tersebut. Beberapa

tahapan

pendekatan

yang

dilakukan

dalam

menggabungkan model logikal data lokal ke dalam model global adalah seperti berikut : 1. Mengecek nama dan isi dari entity / relasi dan candidate key 2. Mengecek nama dan isi relasi atau foreign key 3. Menggabungkan entity / relasi dari model data lokal 4. Memasukkan (tanpa menggabungkan) entity yang unik ke setiap model data lokal. 5. Menggabungkan relasi atau foreign key dari model data lokal 6. Memasukkan (tanpa menggabungkan) relasi / foreign key yang unik ke setiap model data lokal 7. Memeriksa adanya entity / relasi yang hilang dan relasi / foreign key 8. Memeriksa foreign key 9. Memeriksa integrity constraint 10. Membuat entity relasional global 11. Mengupdate dokumentasi 2.

Memvalidasi model logikal data global Untuk mencocokkan relasi yang dibuat dari model logikal data global dengan menggunakan teknik dari normalisasi dan untuk memastikan

46 bahwa model logikal data global mendukung transaksi yang dibutuhkan. 3.

Mengevaluasi model logikal data global dengan user Untuk mengevaluasi model logikal data global dengan user untuk memastikan

bahwa

user

dapat

mempertimbangkan

gambaran

sebenarnya mengenai kebutuhan data dari suatu organisasi. 2.7. Memeriksa untuk perkembangan selanjutnya Untuk menentukan apakah akan terjadi perubahan yang siginifikan untuk kedepannya dan untuk menilai apakah model logikal data global dapat menampung perubahan tersebut. 2.2.7.3. Desain fisikal basis data Proses memproduksi sebuah deskripsi dari implementasi basis data dalam secondary storage, yang menjelaskan relasi dasar, organisasi file, dan indeks yang digunakan untuk mencapai akses yang efisisen ke data dan setiap integrity constraint yang saling berhubungan dan juga pengukuran keamanan. (security) Langkah 3 : Menerjemahkan model logikal data dengan tujuan DBMS Untuk menghasilkan suatu basis data relational skema dari model logikal data yang dapat diimplementasikan sesuai dengan tujuan dari DBMS. Tahap awal dari merancang basis data physical adalah menerjemakan relasi dari model logikal data ke

47 dalam form yang dapat diimplementasikan ke dalam tujuan relational DBMS. Dalam merancang hal tersebut terdiri dari beberapa proses : 1.

Membandingkan informasi yang diperlukan selama merancang basis data logikal dan didokumentasikan dalam bentuk kamus data dengan informasi yang dikumpulkan berdasarkan tingkatan kebutuhan pengumpulan dan analisa dan didokumentasikan dalam spesifikasi sistem.

2.

Proses dari menggunakan informasi tersebut untuk menghasilkan rancangan dari relasi dasar (base relation) Proses-proses yang terjadi dalam langkah ini adalah : 1.

Merancang relasi dasar Untuk menentukan bagaimana menjabarkan suatu relasi dasar yang ditentukan dalam model logikal data global dalam target DBMS.

2.

Merancang gambaran dari pengambilan data Untuk menetukan bagaimana menampilkan / menggambarkan pengambilan setiap data dalam model logikal data dalam tujuan DBMS.

3.

Merancang batasan umum Untuk merancang batasan umum dari tujuan DBMS.

Perancangan batasan

umum seharusnya dicatat seluruhnya. Langkah 4 : Merancang organisasi file dan index Untuk menentukan organisasi file secara optimal agar disimpan ke dalam relasi dasar dan index dibutuhkan untuk memperoleh performa yang dapat diterima, ini adalah jalan agar relasi dan data akan disimpan di secondary storage. Beberapa tahapan dari merancang organisasi file dan index adalah sebagai berikut :

48 4.1. Menganalisa transaksi Untuk memahami transaksi secara fungsional yang berjalan pada basis data dan untuk menganalisa transaksi yang penting. Informasi tersebut digunakan untuk mengidentifikasi bagian dari basis data yang menyebabkan performan menjadi bermasalah. 4.2. Memilih organisasi file Untuk menentukan suatu organisasi file secara efisien untuk setiap relasi dasar jika sesuai dengan tujuan DBMS. 4.3. Memilih indeks Untuk menentukan apakah penambahan indeks dapat meningkatkan performa sistem. 4.4. Mengukur kebutuhan harddisk yang tersisa. Untuk mengukur jumlah dari harddisk yang tersisa yang dibutuhkan untuk mendukung implementasi basis data pada secondary storage. Langkah 5 : Merancang tampilan user Untuk merancang tampilan user yang diidentifikasi selama kebutuhan dari pengumpulan dan analisis tingkatan dari pengembangan siklus sistem basis data. Langkah 6 : Merancang security mechanism Untuk merancang security mechanism untuk basis data sebagai syarat oleh user selama kebutuhan dan pengumpulan dari pengembangan siklus sistem basis data.

49 Langkah 7 : Mempertimbangkan pengenalan pengaturan redundancy Untuk menentukan apakah pengenalan redundancy dapat diatur dengan mengurangi normalisasi sehingga dapat meningkatkan performa dari sistem. Terkadang suatu perancangan basis data yang sudah ternormalisasi tidak memberikan hasil yang maksimal secara efisien. Oleh sebab itu denormalisasi menjadi salah satu pertimbangan untuk mengatasi hal tersebut, lebih tepatnya untuk meningkatkan transaksi secara cepat dengan berdasarkan tahap-tahap berikut ini : 1.

Mengabungkan relationship one-to-one (1:1)

2.

Menggandakan atribut non-key dalam relationship one-to-many untuk mengurangi join.

3.

Menggandakan atribut foreign key dalam relationship one-to-many untuk mengurangi join.

4.

Menggandakan atribut many-to-many (*:*) relationship untuk mengurangi join.

5.

Pengenalan grup yang berulang

6.

Membuat table extract

7.

Partitioning Relations

Langkah 8 : Memonitor dan mengatur sistem operasional Untuk memonitor sistem operational dan meningkatkan performa sistem atau untuk

memperbaruhi

tidak

tepat

suatu

perancangan

keputusan

atau

untuk

menggambarkan berubahnya suatu kebutuhan. Banyak sekali faktor yang digunakan untuk mengukur efisiensi, diantaranya adalah sebagai berikut :

50 •

Transaction Throughput, jumlah transaksi yang dapat diproses dalam satuan interval waktu. Dalam beberapa sistem tingginya transaction throughput adalah kunci dari kesuksesan suatu sistem.

•

Response Time, waktu yang digunakan untuk menyelesaikan satu transaksi. Ada beberapa faktor yang mempengaruhi response time yang si perancang tidak dapat mengatur sepenuhnya seperti : sistem loading atau communication times. Response time dapat diperpendek seperti : o Mengurangi isi dan waktu tunggu, particularly disk I/O wait times

•

o

Mengurangi jumlah waktu dari sumber yang dibutuhkan.

o

Menggunakan komponen yang lebih cepat Disk Storage, ini adalah jumlah dari disk space yang dibutuhkan untuk

menyimpan file basis data. Perancang berharap untuk meminimalisir dari jumlah penyimpanan yang digunakan Banyak sekali keuntungan yang diperoleh dari tuning basis data diantaranya adalah sebagai berikut : 1. Tuning dapat menghindari untuk pembelian hardware 2. Hal ini dapat memungkinkan untuk melihat kembali konfigurasi hardware. 3. Sistem tuning yang baik dapat menghasilkan response time yang lebih cepat dan throughput yang lebih baik, yang mana dapat menyebabkan user dan organisasi dapat lebih produktif 4. Response time yang lebih cepat dapat meningkatkan moral pegawai 5. Response time yang lebih cepat dapat meningkatkan kepuasan pelanggan.

51 2.2.8. Normalisasi Menurut Connolly (2005, p388), normalisasi adalah sebuah teknik untuk menghasilkan sekumpulan relasi dengan properti yang diinginkan, yang akan memberikan kebutuhan data bagi perusahaan. Relasi adalah sebuah tabel dengan kolom dan baris. Basis data dianggap normal jika basis data tersebut tidak mengulangi data (data redundancy) atau tidak menimbulkan keanehan (abnomaly) pada proses update, delete, atau insert. Tujuan normalisasi adalah sebagai berikut : ●

Menghilangkan kumpulan relasi dari inserting, updating, dan delete dependency yang tidak diharapkan

●

Mengurangi kebutuhan restrukturisasi kumpulan relasi dan meningkatkan life spam program aplikasi

●

Membuat model relasional yang lebih informative

●

Membuat sekecil mungkin terjadinya data rangkap

●

Menghindarkan adanya data yang tidak konsisten terutama bila dilakukan penghapusan atau penambahan data sebagai akibat adanya data rangkap.

●

Menjamin bahwa identitas tabel secara tunggal sebagai determinan semua atribut.

Hal penting yang perlu diperhatikan dalam proses normalisasi untuk basis data relational adalah hanya bentuk normal pertama (First normal form / 1NF) yang menjadi kritis dalam membuat relasi. Semua bentuk normal berikutnya adalah optional. Tetapi untuk menghindarkan update anomalies (relasi yang

52 memiliki pengulangan atau redundansi data yang dapat menyebabkan masalah) biasanya dianjurkan sampai pada tahap ketiga (3NF). Normalisasi yang umum dipakai adalah sampai dengan bentuk normal ketiga. Berikut ini adalah proses normalisasi : 2.2.8.1. First Normal Form (1NF) Sebelum memasuki tahap 1NF, status sebelum 1NF disebut dengan Unormalized Form (UNF), yaitu sebuah tabel yang mengandung satu atau lebih kelompok yang berulang. First Normal Form (1NF) adalah sebuah relasi dimana persimpangan dari setiap baris dan kolom yang mengandung satu dan hanya satu nilai saja. Untuk mengubah tabel UNF kedalam 1NF harus mengidentifikasi dan menghilangkan repeating group pada tabel. Sebuah repeating group adalah sebuah atribut atau kumpulan atribut pada suatu tabel yang terdapat lebih dari satu nilai (multiple) untuk sebuah occurrence tunggal dari key atributnya yang ditunjuk dalam tabel. Ada dua pendekatan umum untuk menghilangkan repeating group pada tabel UNF, antara lain : ƒ Pendekatan pertama, menghilangkan repeating group dengan memasukan data yang berlebihan ke dalam kolom dan baris yang kosong. Sehingga hasil dari tabel nantinya hanya mengandung nilai atomik (tunggal). ƒ Pendekatan kedua, menghilangkan repeating group dengan menempatkan data yang berlebihan, selanjutnya dengan meng-copy atribut kuncinya yang asli dalam sebuah relasi yang dipisahkan.

53 Kedua pendekatan ini benar. Tetapi pendekatan kedua awalnya menghasilkan relasi yang paling sedikit pada 1NF dengan mengurangi redundansi. Jika menggunakan pendekatan pertama, relasi dari 1NF adalah buruk,

selanjutnya

selama

langkah

normalisasi

berikutnya

akan

menghasilkan relasi yang sama yang dihasilkan oleh pendekatan kedua. 2.2.8.2. Second Normal Form (2NF) Second Normal Form (2NF) adalah sebuah relasi dimana pada bentuk normal pertama dan setiap attribute yang bukan primary key adalah secara fungsional tergantung dengan primary key. Primary key adalah candidate key yang dipilih untuk mengidentifikasi tuple secara unik pada sebuah relasi. Sedangkan tuple adalah baris pada sebuah relasi. Proses normalisasi 1NF ke 2NF melibatkan penghilangan partial dependencies. Jika terdapat partial dependencies, maka atribut functionally dependent dari relasi akan dihilangkan dengan menempatkannya pada sebuah relasi baru bersama dengan copy determinant mereka. Full functional dependency adalah suatu keadaan dimana jika A dan B adalah atribut, B secara fungsional sangat tergantung pada A dan jika B secara fungsional bergantung pada A, tetapi bukan subset dari A. 2.2.8.3. Third Normal Form (3NF) Third Normal Form (3NF) adalah sebuah relasi dimana bentuk normal pertama dan kedua, dan dimana tidak ada attribute yang bukan primary key yang secara transitif bergantung pada primary key. Transitive dependency

54 adalah sebuah kondisi dimana A, B dan C adalah atribut dari relasi dimana A → B dan B → C, maka C adalah transitive dependency pada A melalui B. Proses normalisasi dari relasi 2NF ke 3NF melibatkan penghilangan dari ketergantungan transitif. Jika sebuah ketergantungan transitif muncul, maka dihilangkan ketergantungan transitif antara atributnya dengan menempatkan atribut tersebut kedalam relasi baru, selanjutnya dengan sebuah salinan dari determinannya. 2.2.9. Fourth Generation Language (4GL) Menurut Connolly dan Begg (2005, p42), bahasa yang lebih dekat ke bahasa manusia dibandingkan dengan high-level programming languages. Biasanya dipakai untuk mengakses basis-data. 4GL meliputi : a. Query languages. Suatu bahasa pemrograman yang digunakan untuk memanipulasi data dalam suatu basis-data. b. Form Generators. Merupakan fasilitas interaktif untuk membuat form input data dan tampilannya. Mendefinisikan desain tampilan, informasi apa yang akan disajikan, komponen warna pada layer dan karakteristik lainnya. c. port Generators. Membuat laporan (report) yang datanya diambil dari basis data. Memungkinkan user untuk mengambil data yang diperlukan untuk laporan.

55 Lebih menekankan kepada rancangan hasil atau output, yaitu bagaimana suatu laporan akan disajikan. d. Graphics Generators. Digunakan untuk mengambil data dari basis-data, dan menampilkannya dalam bentuk grafik. e. Application Generators. Fasilitas untuk menghasilkan program yang berhubungan dengan data, sekaligus untuk menentukan bagaimana menampilkan fungsi-fungsi.

2.3. Tools-tools yang digunakan 2.3.1. STD Menurut Whitten (Whitten, 2004, p673), state transition diagram merupakan suatu alat yang digunakan untuk menggambarkan urutan dan variasi screen yang dapat terjadi selama satu sesi pengguna. 1. State, disimbolkan dengan segi empat. Simbol state : 2. Transition state atau state perubahan disimbolkan dengan panah berarah. Simbol transition state : 3. State adalah kumpulan keadaan atau atribut yang mencirikan seseorang atau suatu benda pada waktu tertentu atau kondisi tertentu. Contohnya adalah menunggu user mengisi password, menunggu instruksi berikutnya, menunggu nada panggilan dan sebagainya.

56 4. Condition adalah suatu kejadian pada lingkungan eksternal yang dapat dideteksi oleh sistem. Contohnya adalah sebuah sinyal, interrupt, atau data. Hal ini akan menyebabkan perubahan terhadap state dari state menunggu X ke state menunggu Y atau memindahkan aktifitas X ke aktifitas Y. 5. Action adalah yang dilakukan sistem bila terjadi perubahan state atau merupakan reaksi terhadap kondisi. Aksi akan menghasilkan keluaran atau tampilan. 6. Display pada layar (screen) akan menghasilkan kalkulasi dan sebagainya. State 1 Condition State 2

Action

Gambar 2.10. Contoh Display Layar (Sumber : Whitten, 2004, p674)

2.3.2. Diagram Arus Data (DFD) Menurut Jogiyanto (1999, p700), Diagram yang menggunakan notasinotasi ini untuk menggambarkan arus dari data sistem sekarang dikenal dengan nama diagram arus data (data flow diagram atau DFD). DFD sering digunakan untuk menggambarkan suatu sistem yang telah ada atau sistem baru yang akan dikembangkan secara logika tanpa mempertimbangkan lingkungan fisik dimana data tersebut mengalir (misalnya lewat telepon, surat) atau lingkungan fisik dimana data tersebut akan disimpan (misalnya file kartu, microfiche, hard disk, tape, diskette). DFD merupakan alat yang digunakan pada metodologi pengembangan

57 sistem. 2.3.2.1. Simbol yang digunakan DFD Beberapa simbol yang digunakan di DFD : 1. kesatuan luar (External entity) atau boundary (batas sistem) 2. Arus data (Data flow) 3. Proses (Process) 4. Simpanan data (Data store) 2.3.2.1.1. Kesatuan Luar (External entity) Kesatuan luar (external entity) merupakan kesatuan (entity) di lingkungan luar system yang dapat berupa orang, organisasi atau system lainnya yang berada di lingkungan luarnya yang akan memberikan input atau menerima output dari sistem. Kesatuan luar ini diantaranya adalah sebagai berikut : • Suatu kantor, departemen atau divisi dalam perusahaan tetapi di luar sistem yang sedang dikembangkan. • Orang atau sekelompok orang di organisasi tetapi di luar sistem yang sedang dikembangkan. • Suatu organisasi atau orang yang berada di luar organisasi seperti misalnya langganan, pemasok. • Sistem informasi yang lain di luar sistem yang sedang dikembangkan. • Sumber asli dari suatu transaksi. • Penerima akhir dari suatu laporan yang dihasilkan oleh system. Suatu kesatuan luar dapat disimbolkan dengan suatu notasi kotak.

58

Gambar 2.11. Notasi kesatuan luar di DFD (Sumber : Jogiyanto, 1999, 701)

2.3.2.1.2. Arus data (Data Flow) Arus data (data flow) di DFD diberi simbol suatu panah. Arus data ini mengalir diantara proses (process), simpanan data (data store) dan kesatuan luar (external entity). Arus data ini menunjukkan arus dari data yang berupa masukan untuk sistem atau hasil dari proses sistem yang dapat berbentuk sebagai berikut : a) Formulir atau dokumen yang digunakan di perusahaan. b) Laporan tercetak yang dihasilkan oleh system. c) Tampilan atau output di layar komputer yang dihasilkan oleh system d) Masukan untuk komputer e) Komunikasi ucapan f) Surat-surat atau memo g) Data yang dibaca atau direkamkan ke suatu file h) Suatu isian yang dicatat pada buku agenda i) Transmisi data dari suatu komputer ke komputer yang lain. Arus data sebaiknya diberi nama yang jelas dan mempunya arti. Nama dari arus data dituliskan disamping garis panahnya.

59 1

Order langganan

Proses order langganan

Langganan

Gambar 2.12. Contoh arus data dari kesatuan luar (external entity) ke proses (Sumber : Jogiyanto, 1999, p702)

Di dalam menggambar arus data di DFD perlu diperhatikan beberapa konsep, diantaranya adalah : 1. Konsep paket dari data (packet of data) Bila dua atau lebih data mengalir dari suatu sumber yang sama ke tujuan yang sama maka harus dianggap sebagai suatu arus data yang tunggal. Mengapa ? karena dua atau lebih data tersebut mengalir bersama-sama sebagai suatu paket. Data yang mengalir bersama-sama harus ditunjukkan sebagai satu arus data walaupun misalnya terdiri dari beberapa dokumen. Berikut ini adalah contoh penggambaran arus data yang tidak benar.

Order langganan

Langganan pembayaran

1 Proses order langganan

Gambar 2.13. contoh arus data yang salah. (Sumber : Jogiyanto, 1999, p702)

Dua buah arus data ini, yaitu order langganan dan pembayaran harus ditunjukkan sebagai arus data yang tunggal, yaitu sebagai arus data order

60 langganan dan pembayaran seperti berikut ini : 1

Order langganan dan pembayaran

Proses order langganan

Langganan

Gambar 2.14. arus data yang benar (Sumber : Jogiyanto, 1999, p702)

2. Konsep arus data menyebar (diverging data flow) Arus data yang menyebar menunjukkan sejumlah tembusan dari arus data yang sama dari sumber yang sama ke tujuan yang berbeda

2 Proses order langganan

Tembusan Jurnal

1 Proses penerimaan kas

Order penjualan

Tembusan permintaan barang

Tembusan Kredit 3 Proses verifikasi kredit

Gambar 2.15. Contoh arus data yang menyebar (Sumber : Jogiyanto, 1999, p703)

Gudang

61 Konsep arus data yang menyebar ini menunjukkan bahwa arus data tembusan jurnal, tembusan permintaan barang dan tembusan kredit merupakan arus data yang mempunya struktur elemen yang sama, karena merupakan hasil dari tembusan arus data order penjualan.

3. Konsep arus data mengumpul (Converging data flow) Arus data yang mengumpul menunjukkan beberapa arus data yang berbeda dari sumber yang berbeda bergabung bersama-sama menuju ketujuan yang sama. 1 Faktur Proses pembuatan faktur pengiriman

Langganan

2 Pembuatan Slip pengepakan

Slip Pengepakan

Gambar 2.16. Contoh Arus data mengumpul yang jarang digunakan (Sumber : Jogiyanto, 1999, p704) Arus data “pengiriman” merupakan hasil dari gabungan arus data “faktur” dan “slip pengepakan”. Arus data mengumpul ini jarang dibuat di DFD dan sebagai penggantinya dapat digambarkan sebagai berikut ini :

62 1

Faktur

Proses pembuatan faktur

Langganan 2 Pembuatan Slip pengepakan

Slip Pengepakan

Gambar 2.17. Contoh arus data mengumpul yang biasa digunakan (Sumber : Jogiyanto, 1999, p704)

4. Konsep sumber dan tujuan arus data Semua arus data harus dihasilkan dari suatu proses atau menuju ke suatu proses (dapat salah satu atau ke dua-duanya , yaitu berasal dari suatu proses menuju ke bukan suatu proses atau berasal dari bukan suatu proses tetapi menuju ke suatu proses atau berasal dari suatu proses dan menuju ke suatu proses). Konsep ini penting karena arus data adalah salah satu dari hasil suatu proses atau akan digunakan untuk melakukan suatu proses. 2.3.2.1.3. Proses (process) Suatu proses adalah kegiatan atau kerja yang dilakukan oleh orang, mesin atau komputer dari hasil suatu arus data yang masuk ke dalam proses untuk dihasilkan arus data yang akan keluar dari proses. Suatu proses dapat ditunjukkan dengan simbol lingkaran atau dengan simbol empat persegi panjang tegak dengan sudut-sudutnya tumpul.

63 Identifikasi atau

Nama Proses

Gambar 2.18. Notasi proses di DFD (Sumber : Jogiyanto, 1999, p705) Setiap proses harus diberi penjelasan yang lengkap meliputi : •

Identifikasi proses Identifikasi ini umumnya berupa suatu angka yang menunjukkan nomor acuan dari proses dan ditulis pada bagian atas di simbol proses.

•

Nama proses Nama proses menunjukkan apa yang dikerjakan oleh proses tersebut. Nama dari proses harus jelas dan lengkap menggambarkan kegiatan prosessnya. Nama dari proses biasanya berbentuk suatu kalimat yang diawali dengan kata kerja.

2.3.2.1.4. Simpanan data Simpanan data (data store) merupakan simpanan dari data yang dapat berupa sebagai berikut ini : • Suatu file atau database di sistem komputer • Suatu arsip atau catatan manual. • Suatu kotak tempat data di meja seseorang • Suatu agenda atau buku Simpanan data di DFD dapat disimbolkan dengan sepasang garis

64 horizontal paralael yang tertutup di salah satu ujungnya. Media Nama data store

Gambar 2.19. Simbol dari simpanan data di DFD (Sumber : Jogiyanto, 1999, p707) Nama dari data store menunjukkan nama dari filenya, misalnya file langganan, file hutang, file arsip faktur. Di dalam penggambaran simpanan data di DFD perlu diperhatikan beberapa hal sebagai berikut ini: 1. Hanya proses saja yang berhubungan dengan simpanan data, karena yang menggunakan atau merubah data di simpanan data adalah suatu proses. 2. Arus data yang menuju ke simpanan data dari suatu proses menunjukkan proses update terhadap data yang tersimpan di simpanan data. Update dapat berupa proses : •

Menambah atau menyimpankan record baru atau dokumen baru ke dalam simpanan data.

•

Menghapus record atau mengambil dokumen dari simpanan data

•

Merubah nilai data di suatu record atau di suatu dokumen yang ada di simpanan data.

3.

Arus data yang berasal dari simpanan data ke suatu proses menunjukkan bahwa proses tersebut menggunakan data yang ada di simpanan data.

4.

Untuk suatu proses yang melakukan kedua-keduanya, yaitu menggunakan dan update simpanan data dapat dipilih salah satu penggambaran sebagai berikut ini :

65 a) Menggunakan sebuah garis dengan panah mengarah kedua arah yang berlawanan dari simpanan data sebagai berikut : 1 Memeriksa dan merubah data barang

penjualan

D1

Persediaan barang

Gambar 2.20. Contoh garis mengarah kedua arah yang berlawanan (Sumber : Jogiyanto, 1999, p709) b) Menggunakan arus data yang terpisah 1

Status barang

Memeriksa dan merubah data barang

D1

Persediaan barang

penjualan

Gambar 2.21. Contoh garis dengan arus data yang terpisah (Sumber : Jogiyanto, 1999, p709)

2.3.3.

Sistem Permodelan Tiga alasan yang menyebabkan sebaiknya dilakukan pemodelan sistem, yaitu: 1.

Dapat melakukan perhatian pada hal-hal penting dalam sistem tanpa

mesti terlibat terlalu jauh. 2.

Mendiskusikan perubahan dan koreksi terhadap kebutuhan pemakai

dengan resiko dan biaya minimal. 3.

Menguji pengertian penganalisa sistem terhadap kebutuhan pemakai dan

membantu pendesain sistem dan pemrogram membangun sistem.

66 Dua tahapan yang terjadi dalam permodelan suatu sistem diantaranya : 1.

Context Diagram

2.

Diagram 0

2.3.3.1. Diagram Konteks (Context Diagram) Diagram konteks merupakan kejadian tersendiri dari suatu diagram alir data, dimana satu lingkaran merepresentasikan seluruh sistem. Diagram konteks dapat diartikan sebagai suatu pandangan, yang mencakup masukan-masukan dasar, sistem-sistem dan keluaran. Semua entitas eksternal yang ditunjukkan pada diagram konteks berupa arus data-arus data utama menuju dan dari sistem. Diagram tersebut dari sistem diketahui penganalisis dengan cara melakukan wawancara dengan user yang digunakan sebagai hasil analisis dokumen. Context diagram menggaris bawahi sejumlah karakteristik penting dari suatu sistem : •

Kelompok pemakai, organisasi, atau sistem lain dimana sistem kita melakukan komunikasi yang disebut juga sebagai external entity.

•

Data dimana sistem kita menerima dari lingkungan dan harus diproses dengan cara tertentu.

•

Data yang dihasilkan sistem kita dan diberikan ke dunia luar.

•

Penyimpanan data yang digunakan secara bersama antara sistem kita dengan external entity. Data ini dibuat oleh sistem dan digunakan oleh lingkungan atau sebaliknya dibuat oleh lingkungan dan digunakan oleh sistem kita.

•

Batasan antara sistem kita dan lingkungan.

67 Diagram konteks dimulai dengan 1. Penggambaran external entity 2. Arus data 3. Aliran kontrol penyimpanan 4. Proses tunggal yang menunjukkan keseluruhan sistem. Bagian termudah adalah menetapkan proses (yang hanya terdiri dari satu lingkaran) dan diberi nama yang mewakili sistem. Nama dalam hal ini dapat menjelaskan proses atau pekerjaan atau dalam kasus ekstrim berupa nama perusahaan yang dalam hal ini mewakili proses yang dilakukan keseluruhan organisasi. Diagram konteks memiliki aturan sebagai berikut: a) Jika terdapat banyak eksternal entity yang mempunyai banyak masukan dan keluaran diperbolehkan untuk digambarkan lebih dari satu kali sehingga mencegah penggambaran yang terlalu rumit, dengan ditandai secara khusus untuk menjelaskan bahwa eksternal entity yang dimaksud adalah identik. Tanda tersebut dapat berupa asterik (*) atau pagar (#). b) Jika eksternal entity mewakili individu sebaiknya diwakili oleh peran yang dimainkan personil tersebut. Alasan pertama adalah personil dapat berganti sedangkan diagram konteks harus tetap akurat walaupun personil berganti. Alasan kedua adalah seorang personil dapat memainkan lebih dari satu peran. c) Karena fokus utama adalah mengembangkan model, maka penting untuk membedakan sumber (resource) dan pelaku (handler), pelaku adalah mekanisme, perangkat atau media fisik yang mentransportasikan data ke / dari sistem, karena pelaku seringkali familier dengan pemakai dalam implementasi

68 sistem berjalan, maka sering menonjol sebagai sesuatu yang harus digambarkan lebih dari sumber data itu sendiri. Sedangkan sistem baru dengan konsep pengembangan teknologinya membuat pelaku menjadi sesuatu yang tidak perlu digambarkan. Aliran dalam diagram konteks memodelkan masukan ke sistem dan keluaran dari sistem seperti halnya sinyal kontrol yang diterima atau dibuat sistem. Dengan mencegah interaksi yang tidak perlu (extraneous prompts) yang berorientasi pada implementasi masukan-keluaran dan mengkonsentrasikan pemodelan pada jaringan arus data. Dalam beberapa kondisi diperlukan dialog karena eksternal entity tidak tahu sistem memerlukan masukan atau memerlukan keluaran. Dalam hal ini interaksi menjadi diperlukan dan diasumsikan menjadi bagian esensi. Contoh : sebuah Context Diagram untuk sistem pemesanan makanan ditunjukan pada gambar di bawah ini

Customer Order

Manager Restaurant

Food Order

Receipt

Customer

Kitchen

Sistem Pemesanan Makanan

Management Report

Gambar 2.22. Contoh Context Diagram (Sumber: http://dhamidin.files.wordpress.com/2008/01/handout-6.pdf)

69 2.3.3.2. Diagram 0 (Level berikutnya) Diagram 0 adalah pengembangan dari diagram konteks dan bisa mencakup sampai sembilan proses. Setiap proses diberi nomor bilangan bulat. Penyimpanan data-penyimpanan data utama dari sistem (mewakili file-file master) dan semua entitas eksternal dimasukkan ke dalam diagram 0.

Gambar 2.23. Contoh Diagram 0

2.3.4. Bagan Alir Dokumen (Document FlowChart) Menurut Mulyadi (2001, p60) simbol-simbol standar yang digunakan dalam pembuatan bagan alir dokumen (document flow chart) adalah :

•

Dokumen. Simbol ini digunakan untuk menggambarkan

70 semua jenis dokumen, yang merupakan formulir yang digunakan untuk merekam data terjadinya suatu transaksi.

•

Dokumen dan tembusannya. Simbol ini digunakan

untuk menggambarkan dokumen asli dan tembusannya.

•

Berbagai dokumen. Simbol ini digunakan untuk

menggambarkan berbagai jenis dokumen yang digabungkan bersama di dalam satu paket. • Catatan. Simbol ini digunakan untuk menggambarkan catatan akuntansi yang digunakan untuk mencatat atau yang direkam sebelumnya di dalam dokumen atau formulir. Catatan dapat berupa : jurnal, buku pembantu, dan buku besar.

•

Penghubung pada halaman yang sama (on page connector).

Untuk menghubungkan jika terdapat aliran dokumen yang berhenti di suatu lokasi pada halaman tertentu dan kembali berjalan di lokasi lain pada halaman yang sama.

71 Akhir arus dokumen dan mengarahkan pembaca ke symbol penghubung halaman yang sama yang bernomor seperti yang tercantum di dalam symbol tersebut.

1

1 Awal arus dokumen yang berasal dari symbol penghubung halaman yang sama yang bernomor seperti yang tercantum di dalam symbol tersebut.

•

Penghubung pada halaman yang berbeda (off page

connector). Simbol ini digunakan untuk menunjukkan kemana dan bagian alir terkait satu dengan lainnya.

•

Kegiatan

manual.

Simbol

ini

digunakan

untuk

menggambarkan kegiatan manual seperti : menerima order pembeli, mengisi, membandingkan, memeriksa formulir. •

Keterangan komentar.

Simbol ini memungkinkan ahli

sistem menambahkan keterangan untuk memperjelas pesan yang disampaikan dalam bagan alir.

72

•

Arsip sementara. Simbol ini digunakan untuk menunjukkan

tempat penyimpanan / pengarsipan dokumen. Untuk menunjukkan urutan pengarsipan dokumen digunakan symbol berikut ini : a)

A = menurut abjad

b)

N = menurut nomor urut

c)

T = kronologis menurut tanggal

•

Arsip permanen. Simbol ini digunakan untuk menggambarkan

arsip permanen yang merupakan tempat penyimpanan dokumen yang tidak akan diproses lagi. Ya

•

Tidak

Keputusan. Simbol ini menggambarkan keputusan

yang harus dibuat dalam proses pengolahan data. Keputusan yang dibuat ditulisan di dalam symbol.

•

Persimpangan

garis

alir.

Jika

dua

garis

bersimpangan untuk menunjukkan arah masing-masing garis, salah satu garis dibuat sedikit melengkung tepat pada persimpangan kedua garis tersebut. •

Pertemuan garis alir. Simbol ini digunakan jika dua

garis alir bertemu dan salah satu garis mengikuti arus garis lainnya. •

Mulai

/

berakhir

(terminal).

Symbol

ini

untuk

73 menggambarkan awal dan akhir suatu sistem. Dalam bagan alir, arus dokumen digambarkan berjalan dari kiri ke kanan dan dari atas ke bawah. Perjalanan dokumen ini dapat diikuti dengan melihat nomor dalam simbol penghubung pada halaman yang sama (on-page connector) atau nomor dalam simbol penghubung pada halaman yang berbeda (off-page connector). Penggunaan bagan alir lebih bermanfaat dibandingkan dengan uraian tertulis dalam menggambarkan suatu sistem. Manfaat tersebut diantaranya adalah sebagai berikut : 1.

Gambaran sistem secara menyeluruh lebih mudah diperoleh dengan menggunakan bagan alir

2.

Perubahan sistem lebih mudah digambarkan dengan menggunakan bagan alir.

3.

Kelemahan-kelemahan dalam system dan identifikasi bidang-bidang yang memerlukan perbaikan lebih mudah ditembukan dengan bagan alir.

2.3.5. Web Menurut Shneiderman (1998, p47), mengemukakan ada delapan aturan yang dapat digunakan sebagai petunjuk dasar yang baik untuk merancang suatu user interface. Delapan aturan ini disebut dengan Eight Golden Rules of Interface Design, yaitu : 1. Konsistensi Konsistensi dilakukan pada urutan tindakan, perintah, dan istilah yang digunakan pada prompt, menu, serta layar bantuan.

74

2. Memungkinkan pengguna untuk menggunakan shortcut Ada kebutuhan dari pengguna yang sudah ahli untuk meningkatkan kecepatan interaksi, sehingga diperlukan singkatan, tombol fungsi, perintah tersembunyi, dan fasilitas makro. 3. Memberikan umpan balik yang informatif Untuk setiap tindakan operator, sebaiknya disertakan suatu sistem umpan balik. Untuk tindakan yang sering dilakukan dan tidak terlalu penting, dapat diberikan umpan balik yang sederhana. Tetapi ketika tindakan merupakan hal yang penting, maka umpan balik sebaiknya lebih substansial. Misalnya muncul suatu suara ketika salah menekan tombol pada waktu input data atau muncul pesan kesalahannya. 4. Merancang dialog untuk menghasilkan suatu penutupan Urutan tindakan sebaiknya diorganisir dalam suatu kelompok dengan bagian awal, tengah, dan akhir. Umpan balik yang informatif akan memberikan indikasi bahwa cara yang dilakukan sudah benar dan dapat mempersiapkan kelompok tindakan berikutnya. 5. Memberikan penanganan kesalahan yang sederhana Sedapat mungkin sistem dirancang sehingga pengguna tidak dapat melakukan kesalahan fatal. Jika kesalahan terjadi, sistem dapat mendeteksi kesalahan dengan cepat dan memberikan mekanisme yang sedehana dan mudah dipahami untuk penanganan kesalahan. 6. Mudah kembali ke tindakan sebelumnya Hal ini dapat mengurangi kekuatiran pengguna karena pengguna mengetahui

75 kesalahan yang dilakukan dapat dibatalkan; sehingga pengguna tidak takut untuk mengekplorasi pilihan-pilihan lain yang belum biasa digunakan. 7. Mendukung tempat pengendali internal (internal locus of control) Pengguna ingin menjadi pengontrol sistem dan sistem akan merespon tindakan yang dilakukan pengguna daripada pengguna merasa bahwa sistem mengontrol pengguna. Sebaiknya sistem dirancang sedemikan rupa sehingga pengguna menjadi inisiator daripada responden. 8. Mengurangi beban ingatan jangka pendek Keterbatasan ingatan manusia membutuhkan tampilan yang sederhana atau banyak tampilan halaman yang sebaiknya disatukan, serta diberikan cukup waktu pelatihan untuk kode, mnemonic, dan urutan tindakan.

2.4.

Manajemen Peralatan Menurut Suryadharma dan Wigroho (1998, p149), manajemen peralatan terdiri dari 3 tahapan diantaranya : 2.4.3. Biaya alat-alat berat Biaya alat-alat berat terdiri dari : 2.4.3.1. Umum Untuk operasi dengan alat-alat berat harus dipertimbangkan biayabiaya yang disediakan untuk penggunaan alat, waktu yang harus disesuaikan, keuntungan yang diperoleh dan pertimbangannya. Biaya untuk alat berat dapat dihitung dengan prakiraan-prakiraan yang dapat dipertanggungjawabkan. Biaya tersebut meliputi owning

76 cost (biaya kepemilikan) dan operating cost (biaya operasi) yang sering juga disebut O & O Cost (owning and operating cost). 2.4.3.2. Owning Cost Owning

cost

adalah

biaya

kepemilikan

alat

yang

harus

diperhitungkan selama alat yang bersangkutan dioperasikan, apabila alat tersebut milik sendiri. Biaya ini harus diperhitungkan karena alat semakin lama akan semakin berkurang hasil produksinya, bahkan pada waktu tertentu alat sudah tidak dapat diproduksi lagi, hal ini disebut sebagai depresiasi. Nilai depresiasi ditentukan oleh harga beli alat waktu didatangkan beserta perlengkapannya, prakiraan umur ekonomis alat, nilai residu alat (harga jual pada akhir umur ekonomis) dan nilai produksi alat. Untuk menentukan hasil depresiasi alat dalam satuan waktu tertentu, ada beberapa metode seperti berikut ini : a) Straight line method Straight line method adalah metode untuk menentukan nilai depresiasi alat tiap tahunnya sama besar atau sering disebut dengan metode garis lurus. Pada metode ini nilai depresiasi tiap tahun diperoleh dengan membagi nilai reproduksi dengan umur ekonomis alat. Contoh : Harga beli alat :

Rp. 100.000.000

Umur Ekonomis :

5 tahun

Nilai Residu :

Rp. 20.000.000

77 Nilai Reproduksi= Rp.100.000.000–Rp.20.000.000=Rp. 80.000.000 Depresiasi = Rp. 80.000.000 = 16.000.000. – per tahun 5 Metode seperti ini sangat sesuai digunakan apabila alat bekerja secara terus menerus setiap tahunnya. Misalnya dapat diperkirakan alat bekerja selama 2000 jam. b)

Reducing charge method Metode untuk menentukan jumlah depresiasi yang menurun atau berkurang jumlahnya untuk setiap tahunnya. Pertimbangan dari metode ini adalah, semakin tua alat, maka semakin menurun produksinya. Metode ini dibedakan dalam 2 metode. •

Declining balance method Metode untuk menentukan jumlah depresiasi dari tahun ke

tahun adalah sebesar persentase tertentu dari nilai buku alat pada tahun yang bersangkutan. Besarnya persentase dapat dihitung berdasarkan harga beli, nilai residu dan umur ekonomi alat. Nilai buku adalah harga beli alat dikurangi depresiasi yang telah diperhitungkan. Contoh : Harga beli alat = Rp.30.000.000 Depresiasi per tahun = 40% dari nilai buku Umur ekonomis alat = 5 tahun Nilai residu = Rp. 4.000.000 Harga beli alat

= Rp. 30.000.000

78 Depresiasi tahun ke 1 = 40% * Rp. 30.000.000

= Rp. 12.000.000 – Rp.18.000.000 = Rp.18.000.000

Nilai buku tahun ke 2 Depresiasi tahun ke 2 = 40% * Rp. 18.000.000 Nilai buku tahun ke 3

= Rp. 7.200.000

-

= Rp. 10.800.000

Selanjutnya dapat dilihat di tabel 2.2

Tabel 2.1. Depresiasi dengan declining balance method Tahun ke 1

% Depresiasi

Depresiasi (Rp)

Nilai Buku (Rp)

1

40

12.000.000

30.000.000

2

40

7.200.000

18.000.000

3

40

4320.000

10.800.000

4

40

2.592.000

6.480.000

51)

40

1.555.000

3.888.000

52)

-

-

4.000.000

Dari table diatas dapat dilihat nilai buku tidak lagi mengalami depresiasi setelah mencapai nilai residu yang telah diperkirakan seperti pada contoh diatas sebesar Rp. 4.000.000,-, sehingga nilai buku yang digunakan adalah nilai buku pada tahun ke 52. •

Sum Year’s digit method Metode untuk menentukan besarnya depresiasi tiap tahun berdasarkan

pada jumlah angka-angka tahun dari umur ekonomis alat yang bersangkutan sebagai koefisien pembagi, dan didasarkan pada sisa umur ekonomis dari alat.

79 Contoh : Nilai beli alat = Rp. 100.000.000 Prakiraan umur ekonomis 5 tahun Nilai Residu = Rp. 25.000.000 Berdasar umur ekonomis, jumlah angka dalam tahun = 1 + 2 + 3+ 4 + 5 = 15 Nilai Reproduksi = Rp. 100.000.000 – 25.000.000 = Rp. 75.000.000 Besar depresiasi dari tahun ke tahun dihitung seperti pada tabel 2.3 di bawah ini Tabel 2.2. Depresiasi berdasar nilai angka tahun Tahun

Rasio

Nilai Reproduksi

Depresiasi

Nilai Buku

ke

Depresiasi

(Rp)

(Rp)

(Rp)

0

0

75. 000.000

0

100.000.000

1

5/15

75. 000.000

25.000.000

75.000.000

2

4/15

75. 000.000

20.000.000

55.000.000

3

3/15

75. 000.000

15.000.000

40.000.000

4

2/15

75. 000.000

10.000.000

30.000.000

5

1/15

75. 000.000

5.000.000

25.000.000

Pada diatas dapat dilihat nilai buku pada tahun ke 5 pada akhir umur ekonomis alat besarnya Rp.25.000.000 sesuai dengan perkiraan nilai residu. Dalam menghitung owning cost, selain menentukan depresiasi harus diperhitungkan juga suku bunga pajak, asuransi, dan biaya penyimpanan. Cara menentukan besarnya suku bunga, pajak dan asuransi tiap-tiap negara berbeda-beda, tergantung di negara mana alat tersebut digunakan.

80 Nilai rerata untuk suka bunga, pajak, dan asuransi per tahun didasarkan pada nilai rerata alat selama umur ekonomis. Oleh sebab itu, dapat digunakan rumus yang didasarkan pada nilai depresiasi dengan metode garis lurus berikut ini : P = P(n + 1) + S(n-1) 2n Keterangan : P = biaya rerata yang dikeluarkan per tahun P = harga beli alat S = Salvage value (nilai residu) n = prakiraan umur ekonomis alat Contoh: Harga beli alat = Rp. 100.000.000 Nilai Residu = Rp. 25.000.000 Umur ekonomis = 5 tahun (2000 jam per tahun) Misalnya : Suku bunga

= 15 %

Pajak

= 2.5 %

Asuransi

= 2.5 %

Total annual Rates = 20% P = Rp. 100.000.000 (5+1) + Rp. 25.000.000(5-1) 2(50)

81

P = Rp. 70.000.000 per tahun Atau P = Rp. 35.000, - per jam Sehingga suku bunga, pajak dan asuransi dihitung

= Rp. 35.000 * 20%

= Rp. 7.000 per jam 2.4.3.3. Operating cost (Biaya Operasi) Operating cost atau biaya operasi alat ialah biaya-biaya yang dikeluarkan selama alat tersebut digunakan. Biaya operasi ini meliputi bahan bakar, minyak pelumas atau minyak hidrolis, penggantian ban, perbaikan atau pemeliharaan, penggantian suku cadang khusus, misalnya mata pisau pada dozer dan gaji operator (tukang). 2.4.3.3.1. Biaya ban Biaya ban tergantng dari harga ban di tempat alat yang bersangkutan dioperasikan dan prakiraan umur ban menurut pengalaman, atau menurut rekomendasi pabrik pembuatnya. Besarnya biaya penggantian ban ditentukan sebagai berikut : Harga ban (rupiah)

12,5- 17,5* harga alat Rupiah / jam atau

Prakiraan umur ban

100*2000 jam

2.4.3.3.2. Biaya perbaikan / pemeliharaan Untuk menjaga kondisi alat agar dapat bekerja normal dan baik perlu adanya pemeliharaan, penggantian suku cadang dengan yang

82 baru. Faktor yang mempengaruhi besarnya biaya perbaikan alat, kecakapan operator dan adanya perawatan yang memadai. Besarnya

factor

untuk

menentukan

biaya

perbaikan

dan

pemeliharaan biasanya sudah ada rekomendasi dari pabrik pembuat alat, yang besarnya tergantung dari kondisi dan pemakaiannya dam ditentukan sebagai berikut : Faktor perbaikan / pemeliharaan * (harga alat-harga ban) Prakiraan umur ekonomis alat (jam) Atau (6,25-8,75%) * harga alat 100*2000 jam 2.4.3.3.3. Penggantian suku cadang khusus Suku cadang khusus yang dimaksud adalah bajak, ujung mata pisau dan alat-alat khusus lainnya yang kerusakaannya lebih cepat dibanding suku cadang yang lain, waktu kerusakannya tidak tertentu, tergantung pemakaian dan medan kerja. Untuk menghitung biaya suku cadang khusius ini tidak termasuk dalam pos perbaikan dan pemeliharaan tetapi dihitung dalam pos tersendiri. 2.4.4. Penyusunan Jadwal Pada tahap ini dilakukan perhitungan produksi dan kebutuhan waktu untuk menyelesaikannya dari masing-masing alat untuk masing-masing pekerjaan. Berdasarkan perhitungan waktu penyelesaian dari masing-masing pekerjaan atau masing-masing alat dapat dibuat jadwal pengoperasiannya. Hal-hal yang dibutuhkan untuk penyusunan jadwal pekerjaan berupa hal-hal

83 sebagai berikut : a)

Waktu pelaksanaan

b)

Jenis dan volume pekerjaan

c)

Jumlah dan jenis pekerjaan

d)

Pola dasar operasi peralatan

Umumnya proyek-proyek diawali dengan perencanaan penyusunan jadwal pelaksanaan pekerjaan yang biasanya berbentuk barchart (bagan balok). Bagan balok adalah suatu bagan balok yang disusun secara grafis yang menguraikan jenis-jenis pekerjaan suatu proyek yang terdiri dari sejumlah kegiatan atau aktifitas yang telah dirumuskan dengan baik. Langkah-langkah yang dibutuhkan untuk menyusun balok adalah sebagai berikut: a) Menyusun daftar kegiatan proyek secara teratur beserta volume pekerjaannya. b) Menaksir waktu dan sumber daya yang dibutuhkan untuk masingmasing pekerjaan c) Menggambarkan setiap kegiatan tersebut menjadi sebuah bagan balok mendatar dengan skala waktu tertentu. d) Menata kegiatan tersebut diatas sebuah bagan balok dengan skala waktu yang mendatar Dengan adanya bagan balok dapat memberikan informasi, kapan suatu pekerjaan harus dimulai dan kapan harus diakhiri. Penggunaan bagan balok biasanya dikombinasikan dengan kurva “S” agar diperoleh informasi tambahan pada bagan balok dalam kegiatan pengendalian. Hal ini digunakan untuk mengontrol kegiatan pembayaran secara kumulatif untuk jangka waktu

84 tertentu atau periode waktu yang telah ditentukan. Tabel 2.3 Tabel Penyusunan Jadwal

Bagan balok diatas merupakan paduan bagi pelaksanaan pekerjaan di lapangan. Agar diperoleh manfaat yang lebih besar, maka pada bagan barchart harus selalu diupdating dengan informasi kemajuan pekerjaan (progress report). Contoh secara mingguan atau harian tergantung penjadwalan waktunya. Tujuan dari progress report ini adalah agar bisa diketahui apakah pelaksanan pekerjaan sudah sesuai dengan jadwal yang telah disusun atau telah melewati jadwal atau mengalami keterlambatan.

2.4.5. Pemeliharaan alat-alat berat Pemeliharaan mesin dan alat berat menolong agar kecelakaan terjadi seminimal mungkin. Pemeliharaan mesin dan alat-alat berat sangat dibutuhkan sehingga kemungkinan akan kerugian atas mesin dan alat-alat berat dapat dikurangi.

85

Pengaruh Kerugian

Penggoresan

Korosi

Beban Berlebihan

Usia

Pengausan

Kelelahan Bahan

Gambar 2.23. Skema Pengaruh Kerugian (Sumber : Suryadharma dan Wigroho, 2000, p164)

Pemeliharaan mesin dan alat-alat berat dapat dibagi atas beberapa hal sebagai berikut : 2.4.5.1. Pembersihan Akibat penggunaan mesin dan alat-alat berat di lokasi proyek, maka mesin dan alat berat akan menjadi kotor. Pada lokasi proyek yang teroganisir, pembersihan mesin dan alat dilakukan setiap sore selesai bekerja maka perlu dimotivasi buruh dari dan pembantunya untuk melaksanakan pekerjaan tersebut. Bahan pembersih yang murah dan efisien adalah air. Sesudah pembersihan dengan air, sebaiknya mesin dan alat berat dilumasi pada semua tempat pelumasan hingga air yang mungkin telah masuk pada bantalan-bantalan, ditekan keluar oleh gemuk baru yang diisikan.

86 2.4.5.2. Pencegah kerusakan Pencegah kerusakan adalah seluruh tindakan, pemeliharaan dan pekerjaan lain atas dasar pengawasan / kontrol mesin dan alat berat sebagai berikut :

Pencegahan Kerusakan

Pemeliharaan Dan Servis

Perbaikan

Inspeksi

Langsung Di tempat

Di bengkel reparasi

Pengawasan Kontrol

Gambar 2.25. Pengawasan / Kontrol (Sumber : Suryadharma dan Wigroho, 2000, p165) 2.4.5.3. Pekerjaan pemeliharaan Istilah-istilah

yang

digunakan

didefinisikan sebagai berikut :

pada

pekerjaan

pemeliharaan

87 1) Pemeliharaan Berupa tindakan-tindakan bagi perlindungan dan penyediaan inventaris bergerak dalam keadaan baik. Pemeliharaan ini terdiri dari : perawatan, inspeksi dan perbaikan 2) Perawatan Berupa tindakan-tindakan bagi perlindungan dalam keadaan baik. Perawatan terdiri dari : pelumasan, pembersihan, dan penyetelan yang tepat. 3) Inspeksi Berupa kontrol dan pertimbangan keadaan sebagai dasar penentuan pekerjaan, perbaikan, dan servis. 4) Perbaikan Berupa

tindakan-tindakan

bagi

penyediaan

keadaan

baik.

Perbaikan terdiri dari : perbaikan dan revisi. 5) Pemeliharaan dan pencegahan Inspeksi dan servis dilakukan secara teratur pada waktu tertentu, walaupun mesin atau alat masih dalam keadaan baik. 2.4.5.3.1. Tujuan pekerjaan pemeliharaan Tujuan pekerjaan pemeliharaan adalah berupa pencegahan kerusakan sebagai berikut : 1) Penetapan standar dan nilai inventaris, berarti agar alat dan mesin selalu dapat dipergunakan dan gangguan oleh kerusakan. 2) Meminimalisasi biaya-biaya perbaikan, gangguan dan suku cadang pengganti.

88 Untuk mewujudkan hal tersebut diatas, maka perlu dilakukan pekerjaan-pekerjaan berikut secara teratur : 1) Perawatan 2) Inspeksi 3) Pemeliharaan pencegahan 2.4.5.4.

Pengontrolan pekerjaan pemeliharaan

2.4.5.4.1. Pengontrolan alat dan suku cadang Pengontrolan sangat perlu dilakukan dengan teratur dan teliti supaya diketahui masih tidaknya stok alat dan suku cadang disimpan. Alat-alat dan bahan bakar yang masuk dan keluar harus selalu dicatat secara teliti. Pengeluaran / permintaan suku cadang disediakan formulir kartu permintaan suku cadang (spare part), kontrol penggunaan bahan bakar / pelumas dilakukan dengan bon pemakaian 2.4.5.4.2. Pengontrolan perlakuan pemeliharaan a) Kontrol harian Setiap alat harus diperiksa setiap hari dan dilakukan secara teratur, kemudian harus ada orang yang bertanggung jawab terhadap hal tersebut. b) Wajib lapor Setiap orang bertanggungjawab atas kontrol alat dan wajib melaporkan atas kerusakan, pengausan, kehilangan yang terjadi.