7

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

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 data-

data 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 :

Gambar 2.1. Siklus Aplikasi Basis data

(Sumber : Connolly dan Begg, 2005, p)

Perancangan Aplikasi

Memilih

DBMS

Prototyping (pilihan)

Implementasi

Konversi data dan Loading

Pemeliharaan Operasional

Testing

Perencanaan Basis data

Definisi Sistem

Pengumpulan dan Analisa Data

Perancangan

Basis data Perancangan Basis data

konseptual

Perancangan Basis data Logikal

Perancangan Basis data Physical

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.

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.

Nama Entity

Pegawai Cabang

33

Jika memungkinkan, setiap nama relasi harus unik untuk setiap model ER

yang diberikan.

Memiliki

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.

Nama Relasi

Pegawai Cabang

34

memiliki

Gambar 2.4. Contoh tipe relasi binary

(Sumber : Connolly dan Begg 2005 p348)

Sebuah relasi (relationship) yang berderajat tiga disebut ternary

Gambar 2.5. Contoh tipe relasi ternary

(Sumber : Connolly dan Begg 2005, p348)

Sebuah relasi yang berderajat empat disebut quarternary.

Gambar 2.6 Contoh tipe relasi quarternary

(Sumber : Connolly dan Begg, 2005, p349)

Pegawai Cabang Registers

Client

Pembeli Bagian Keuangan

Tawaran

Pencari Langganan

Mengatur

Pemilik Properti

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 objek-

objek 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 tipe-

tipe 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 relasi dari model data logikal lokal untuk

merepresentasikan relasi antar entity dan attribut yang 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.

Gambar 2.10. Contoh Display Layar

(Sumber : Whitten, 2004, p674)

2.3.2. Diagram Arus Data (DFD)

Menurut Jogiyanto (1999, p700), Diagram yang menggunakan notasi-

notasi 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

Condition

Action

State 1

State 2

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

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.

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

Order langganan

Langganan

1

Proses order langganan pembayaran

Order langganan

Langganan

1

Proses order langganan

60

langganan dan pembayaran seperti berikut ini :

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

Gambar 2.15. Contoh arus data yang menyebar

(Sumber : Jogiyanto, 1999, p703)

Order langganan dan pembayaran

Langganan

1

Proses order langganan

1

Proses penerimaan kas

3

Proses verifikasi kredit

2

Proses order langganan

Gudang Order penjualan

Tembusan permintaan barang

Tembusan Kredit

Tembusan Jurnal

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.

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 :

Faktur1

Proses pembuatan

faktur

2

Pembuatan Slip

pengepakan

Langganan

Slip Pengepakan

pengiriman

62

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.

Faktur1

Proses pembuatan

faktur

2

Pembuatan Slip

pengepakan

Langganan

Slip Pengepakan

63

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

Identifikasi

Nama Proses atau

64

horizontal paralael yang tertutup di salah satu ujungnya.

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 :

Media

65

a) Menggunakan sebuah garis dengan panah mengarah kedua arah yang

berlawanan dari simpanan data sebagai berikut :

Gambar 2.20. Contoh garis mengarah kedua arah yang berlawanan

(Sumber : Jogiyanto, 1999, p709)

b) Menggunakan arus data yang terpisah

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.

1

Memeriksa dan merubah data

barang

D1 Persediaan barang penjualan

1

Memeriksa dan merubah data

barang

D1 Persediaan barang

penjualan

Status barang

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

Sistem Pemesanan

Makanan

Customer

Manager Restaurant

Kitchen

Management Report

Food Order

Customer Order

Receipt

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.

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.

1

1

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.

• 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

Tidak

Ya

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 biaya-

biaya 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 Nilai buku tahun ke 2 = Rp.18.000.000

Depresiasi tahun ke 2 = 40% * Rp. 18.000.000 = Rp. 7.200.000 -

Nilai buku tahun ke 3 = 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

ke

Rasio

Depresiasi

Nilai Reproduksi

(Rp)

Depresiasi

(Rp)

Nilai Buku

(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 masing-

masing 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

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.

Pengaruh Kerugian

Penggoresan Beban Berlebihan

Korosi Usia Pengausan Kelelahan Bahan

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 :

Gambar 2.25. Pengawasan / Kontrol

(Sumber : Suryadharma dan Wigroho, 2000, p165)

2.4.5.3. Pekerjaan pemeliharaan

Istilah-istilah yang digunakan pada pekerjaan pemeliharaan

didefinisikan sebagai berikut :

Pencegahan Kerusakan

Pemeliharaan Dan Servis Inspeksi

Perbaikan

Di bengkel reparasi

Langsung Di tempat

Pengawasan Kontrol

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.