4
2.1 Teori umum
2.1.1 Sistem
Menurut O’Brien (2003,p8), sistem adalah sekumpulan dari komponen yang saling berhubungan dan bekerja sama untuk mencapai tujuan bersama dengan menerima input dan menghasilkan output dalam suatu organisasi.
2.1.2 Informasi
Menurut Mcleod dan Schell (2004,p15) informasi adalah data yang telah diproses atau data yang memiliki arti.
Menurut O’Brien (2003,p13), informasi adalah sekumpulan data yang telah diubah dalam konteks yang lebih bermakna dan berguna bagi pengguna akhir tertentu.
Berdasarkan definisi di atas maka dapat disimpulkan bahwa informasi adalah sebuah atau sekumpulan data yang telah diproses sehingga memiliki arti dan beguna bagi pengguna akhir tertentu.
2.1.3 Sistem Informasi
Menurut Laudon Keneth dan Laudon Jane (2002,p7) sistem informasi adalah kumpulan komponen - komponen yang saling berhubungan yang bekerjasama untuk mengumpulkan, memproses,menyimpan, dan menyebarkan informasi untuk mendukung pengambilan keputusan, koordinasi, dan kendali dalam organisasi.
Menurut O’Brien (2003,p7), sistem informasi adalah kombinasi dari orang, perangkat keras, perangkat lunak, jaringan komunikasi, dan sumber data yang dikumpulkan, diubah bentuknya, dan penyebaran informasi pada sebuah perusahaan.
Berdasarkan definisi di atas maka dapat disimpulkan bahwa sistem informasi adalah sekumpulan dari komponen komponen berupa orang, perangkat keras, perangkat lunak,
jaringan komunikasi, dan sumber data yang saling berhubungan dan bekerja sama untuk mengumpulkan, memproses, menyimpan dan menyebarkan informasi pada perusahaan untuk mendukung pengambilan keputusan, koordinasi, dan kendali dalam perusahaan tersebut.
Menurut Laudon Keneth dan Laudon Jane (2002,p39) ,ada 4 tingkat sistem informasi yaitu :
a. Sistem informasi tingkat operasional
Sistem informasi yang memonitor aktivitas dan kegiatan informasi pada tingkat dasar. Misalnya pengeluaran uang kas, daftar pemesanan dari salesman dan sebagainya.
b. Sistem informasi tingkat pengetahuan
Sistem informasi yang mendukung dan menyediakan pengetahuan dan data pekerjaan di dalam sebuah perusahaan.
c. Sistem informasi tingkat strategi
Sistem informasi yang mendukung aktivitas perencanaan jangka panjang disusun oleh manajemen senior.
d. Sistem informasi tingkat manajemen
Sistem informasi yang mendukung pengawasan, pengontrolan, pengambilan keputusan, aktivitas administrasi dari manajer menengah.
2.1.4 Data
Menurut O’Brien (2003,p13), data adalah fakta mentah atau observasi,umumnya tentang fenomena fisik atau transaksi bisnis. Sebagai contoh, sebuah peluncuran pesawat luar angkasa atau penjualan suatu mobil akan menciptakan banyak data yang menggambarkan kejadian tersebut. Secara lebih spesifik, data adalah ukuran objektif dari atribut (karakteristik) dari entitas (seperti orang, tempat,dan benda).
Berdasarkan definisi di atas maka dapat disimpulkan bahwa data adalah sebuah fakta atau pernyataan yang bersifat mentah, diterima apa adanya yang umumnya berisi tentang
fenomena fisik atau transaksi bisnis dan fakta tersebut dapat berupa angka, kata-kata, atau gambar.
2.2 Teori khusus
2.2.1 Database
Menurut Connolly dan Begg (2002,p14), Database merupakan suatu kumpulan data, yang terbagi atas data yang berhubungan secara logis dan deskripsi,dari data tersebut dirancang untuk memenuhi kebutuhan informasi suatu organisasi.
Database merupakan sebuah tempat penyimpanan tunggal yang besar bagi data yang dapat digunakan secara serentak oleh banyak departemen dan pengguna.
Database merupakan sebuah komponen yang tidak dimiliki sendiri tetapi merupakan sebuah sumber daya yang terbagi dalam perusahaan. Database tidak hanya berisi data operasional organisasi tetapi juga deskripsi data tersebut yang disebut meta data/data tentang data. Dalam database definisi dari data terpisah dari program aplikasi. Keuntungan dari pendekatan tersebut disebut abstraksi data, dimana kita dapat mengubah definisi internal dalam objek tanpa mempengaruhi pengguna objek tersebut, dan menyediakan definisi eksternal yang sama.
2.2.2 Komponen Database
Menurut Connolly dan Begg (2002,p18), komponen database terbagi menjadi lima komponen yaitu :
a. Hardware
Hardware dapat berkisar dari komputer tunggal, mainframe tunggal, hingga komputer jaringan. Hardware tertentu tergantung pada kebutuhan organisasi dan DBMS yang digunakan. Sebuah DBMS memerlukan jumlah minimum memori dan hardisk untuk bekerja, tetapi konfigurasi yang minimum tidak memberikan performa yang handal. b. Software
software jaringan, jika DBMS digunakan melalui jaringan. Program aplikasi seperti C++, Java dan Visual Basic.
c. Data
Merupakan komponen yang terpenting dalam DBMS. Data berfungsi sebagai jembatan antara komponen mesin dan komponen manusia. Database berisi data operasional dan meta data. Struktur database disebut skema, skema terdiri dari banyak tabel, di dalam tabel terdapat lebih dari satu atribut.
d. Prosedur
Mengacu pada instruksi dan aturan yang memerintahkan perancangan dan penggunaan database. Pengguna sistem dan petugas yang mengatur database memerlukan dokumentasi prosedur bagaimana untuk menggunakan dan menjalankan sistem.
Instruksi tersebut seperti :
1. Bagaimana cara masuk ke dalam DBMS
2. Bagaimana menggunakan fasilitas DBMS tertentu 3. Memulai dan menghentikan DBMS
4. Bagaimana menangani kesalahan hardware dan software tertentu. e. Manusia
Komponen manusia terdiri dari :
1. Pemrogram Aplikasi : Yang bertanggungjawab untuk membuat aplikasi database dengan menggunakan bahasa pemrograman yang ada.
2. End User : Siapapun yang berinteraksi dengan sistem secara online atau tidak melalui komputer atau jaringan.
3. Data Adiministrator : Seseorang yang berwenang membuat keputusan dan kebijakan strategis mengenai data yang ada.
4. Database Administrator : Menyediakan dukungan teknis untuk implementasi keputusan tersebut, dan bertanggung jawab atas keseluruhan kendali sistem pada tingkat
teknis.
2.2.3 Keuntungan dan Kerugian DBMS
Menurut Connolly dan Begg (2002,p25), DBMS memiliki keuntungan dan kerugian sebagai berikut :
2.2.3.1 Keuntungan DBMS
a. Kontrol terhadap pengulangan data (data redudancy).
Database berusaha untuk menghilangkan pengulangan dengan mengintegrasikan file sehingga berbagai copy dari data yang sama tidak tersimpan. Bagaimanapun juga pendekatan ini tidak menghilangkan pengulangan secara menyeluruh, tetapi mengendalikan jumlah pengulangan dalam database.
b. Data yang konsisten.
Dengan menghilangkan atau mengendalikan pengulangan, kita telah mengurangi resiko ketidakkonsistenan yang terjadi. Jika item data disimpan hanya sekali di dalam database, maka berbagai update bagi nilai data tersebut harus dibuat hanya sekali dan nilai baru tersebut harus tersedia dengan segera kepada semua pengguna. Jika item data disimpan lebih dari sekali, sistem dapat memastikan bahwa semua copy dari item tersebut tetap konsisten.
c. Semakin banyak informasi yang didapat dari data yang sama.
Dengan data operasional yang terintegrasi, hal ini memungkinkan bagi organisasi untuk mendapatkan informasi tambahan dari data yang sama.
d. Pembagian Data (sharing of data).
Database termasuk bagian dari keseluruhan organisasi dan dapat dibagikan oleh semua pengguna yang berotoritas. Dalam hal ini, banyak pengguna membagikan lebih banyak data.
e. Meningkatkan integritas data.
Integritasdatabase mengacu pada validitas dan konsistensi data yang disimpan. Integritas biasanya diekspresikan dalam istilah batasan, yang berupa aturan konsisten yang tidak boleh dilanggar oleh database. Integrasi memungkinkan DBA untuk menjelaskan, dan memungkinkan DBMS untuk membuat batasan integritas
f. Meningkatkan keamanan data.
Keamanandatabase yaitu melindungi database dari pengguna yang tak berotoritas. Hal ini dapat dilakukan dengan menggunakan sistem username dan password untuk mengidentifikasi orang yang berotoritas untuk menggunakan database. Akses pengguna yang berotoritas pada database mungkin dibatasi oleh jenis operasi seperti pengambilan, insert,update,dan delete data.
g. Penetapan Standarisasi.
Integrasi memungkinkan DBA untuk mendefinisikan dan membuat standard yang diperlukan. Standard ini termasuk standard departemen, organisasi, nasional, atau internasional dalam hal format data, untuk memfasilitasi pertukaran data antara sistem, ketetapan penamaan,standard dokumentasi, prosedur update, dan aturan akses.
h. Pengurangan Biaya.
Dengan menyatukan semua data operasional organisasi ke dalam satu database dan pembuatan sekelompok aplikasi yang bekerja pada satu sumber data dapat menghasilkan pengurangan biaya. Penyatuan biaya pengembangan dan pemeliharaan sistem pada setiap departemen akan menghasilkan total biaya yang lebih rendah. Sehingga biaya lainnya dapat digunakan untuk membeli konfigurasi sistem yang sesuai bagi kebutuhan organisasi.
i. Menyeimbangkan konflik kebutuhan.
Setiap pengguna mempunyai kebutuhan yang mungkin bertentangan dengan kebutuhan pengguna lain. Sejak database dikendalikan oleh DBA, DBA dapat membuat keputusan berkaitan dengan perancangan dan penggunaan operasional database yang menyediakan penggunaan terbaik dari sumberdaya bagi keseluruhan organisasi.
j. Meningkatkan kemampuan akses dan respon pada data
Dengan pengintegrasian data yang melintasi batasan departemen dapat secara langsung diakses pada pengguna akhir. Hal ini dapat menyediakan sebuah sistem dengan lebih banyak fungsi seperti fungsi untuk menyediakan layanan yang lebih baik pada pengguna akhir atau klien organisasi. Banyak DBMS menyediakan query language yang memungkinkan pengguna untuk menanyakan pertanyaan ad hoc dan memperoleh
informasi yang diperlukan dengan segera pada terminal mereka, tanpa memerlukan programmer menulis beberapa software untuk mengubah informasi ini dari database.
2.2.3.2 Kerugian DBMS a. Kompleksitas
Ketentuan dari fungsi yang kita harapkan dari DBMS yang baik membuat DBMS menjadi sebuah software yang sangat kompleks. Perancang dan pengembang database, DA dan DBA, serta pengguna akhir harus memahami fungsi tersebut untuk mendapatkan banyak keuntungan dari DBMS ini.
b. Ukuran
Fungsi yang kompleks dan luas membuat DBMS menjadi software yang sangat besar, memerlukan banyak ruang hardisk dan jumlah memory yang besar untuk berjalan dengan efisien.
c. Biaya dari sebuah DBMS
Biaya DBMS bervariasi, tergantung pada lingkungan dan fungsi yang disediakan. Di situ juga terdapat biaya pemeliharaan tahunan yang juga dimasukkan dalam daftar harga DBMS.
d. Biaya penambahan perangkat keras
Kebutuhan tempat penyimpanan bagi DBMS dan database amat memerlukan pembelian tempat penyimpanan tambahan. Lebih lanjut, untuk mencapai performa yang diperlukan, mungkin diperlukan untuk membeli mesin yang lebih besar dsb. Hal ini tentu memerlukan tambahan biaya yang tidak sedikit. Tergantung pada spesifikasi perangkat keras yang diperlukan.
2.2.4 Database Languages
Menurut Connoly dan Begg (2002,p40) sebuah data sublanguage terdiri dari dua bagian yaitu Data Definition Language (DDL) dan Data Manipulation Language (DML). DDL digunakan untuk menentukan skema database dan DML digunakan baik untuk membaca dan meng-update database. Keduanya disebut data sublanguage karena mereka tidak membangun semua kebutuhan pemograman komputer seperti pernyataan
kondisi dan iterative yang digunakan oleh beberapa bahasa pemrograman tingkat tinggi lainnya.
2.2.4.1 Data Definition Language
Data Definition Language menurut Connolly dan Begg (2002,p40) adalah suatu bahasa yang memperoleh DBA atau pengguna untuk mendeskripsikan dan memberi nama entitas, atribut, dan relationship yang diperlukan untuk aplikasi. DDL berfungsi untuk mengubah suatu data menjadi data yang berguna bagi pengguna.
Beberapa statement DDL menurut Connolly dan Begg(2002,p167) : 1. Create Table
Untuk membuat tabel dengan mengidentifisikan tipe data untuk tiap kolom. 2. Alter Table
Untuk menambah atau membuang kolom dan konstrain. 3. Drop Table
Untuk membuang atau menghapus tabel besarta semua data yang terkait didalamnya. 4. Create Index
Untuk membuat index pada suatu tabel. 5. Drop Index
Untuk membuang atau menghapus index atau menghapus index yang sudah dibuat sebelumnya
2.2.4.2 Data Manipulation Language
Menurut Connolly dan Begg (2002,p41) DML adalah suatu bahasa yang menyediakan sekumpulan operasi yang diinginkan untuk mendukung operasi manipulasi data utama pada data yang diperoleh dalam database. DML menyediakan operasi dasar manipulasi data pada data yang ada dalam database, yaitu :
a. Penyisipan data baru ke dalam database (insertion)
b. Mengubah atau memodifikasi data yang disimpan dalam database (modify) c. Pemanggilan data yang ada dalam database (retrieve)
Menurut Connolly dan Begg kita dapat membedakan DML menjadi 2 tipe yang berbeda, yaitu:
a. Prosedural DML
Prosedural DML adalah suatu bahasa yang memungkinkan pengguna (umumnya programmer) untuk memberi instruksi ke sistem mengenai data apa yang dibutuhkan dan bagaimana cara pemanggilannya (retrieve). Artinya pengguna harus menjelaskan operasi pengaksesan data yang akan digunakan dengan menggunakan prosedur yang ada untuk mendapatkan informasi yang dibutuhkan.
b. Non prosedural DML
Non prosedural DML adalah suatu bahasa yang memungkinkan pengguna untuk menentukan data apa yang dibutuhkan dengan menyebutkan spesifikasinya tanpa menspesifikasikan bagaimana cara mendapatkannya.
2.2.5 Fungsi DBMS
Menurut Connolly dan Begg (2002,p48), fungsi DBMS adalah sebagai berikut : a. Penyimpanan, Pengambilan, dan Peng-update-an data
Sebuah DBMS harus menyediakan bagi pengguna dengan sebuah kemampuan untuk menyimpan, mengambil, dan meng-update data dalam DBMS. Ini merupakan fungsi yang mendasar dari DBMS. Dalam menyediakan fungsi iniDBMS harus menyembunyikan detail implementasi fisikal internal seperti organisasi file dan struktur penyimpanan dari pengguna
b. Katalog User-Accesible
Sebuah DBMS harus menyediakan sebuah katalog yang menyimpan deskripsi tentang item data dan mudah diakses pada pengguna.
c. Mendukung Transaksi
Sebuah DBMS harus menyediakan mekanisme yang akan memastikan bahwa semua kegiatan update yang dilakukan sesuai dengan transaksi yang diberikan atau tidak ada kegiatan update yang dibuat bagi transaksi tersebut.Transaksi merupakan sederetan
tindakan, yang dilakukan oleh pengguna tunggal atau program aplikasi yang mengakses atau mengubah isi database.
d. Layanan Kendali Konkurensi
Sebuah DBMS harus menyediakan sebuah mekanisme untuk memastikan bahwa database di-update dengan benar ketika banyak pengguna meng-update database secara bersama-sama. Akses bersama relatif mudah jika semua pengguna hanya membaca data, di mana tidak ada cara bahwa mereka dapat mengganggu satu dan yang lain. Namun ketika dua atau lebih pengguna mengakses database secara serentak dan paling sedikit satu dari mereka meng-update data, di sana dapat terjadi gangguan yang menghasilkan ketidakkonsistenan.
e. Layanan Perbaikan
Sebuah DBMS harus menyediakan sebuah mekanisme untuk memperbaiki database disaat database mengalami kerusakkan dalam berbagai cara. Kerusakkan database dapat diakibatkan karena kerusakan sistem, kesalahan media, dan kesalahan software atau hardware. Atau disebabkan karena adanya kesalahan selama proses transaksi dan penyelesaian transaksi yang tidak lengkap.
f. Layanan Authorisasi
Sebuah DBMS harus menyediakan sebuah mekanisme untuk memastikan bahwa hanya pengguna yang berotoritas dapat mengakses database. Hal ini untuk mencegah data yang tersimpan tak terlihat oleh semua pengguna dan melindungi database dari akses yang tak berotoritas.
g. Mendukung Bagi Komunikasi Data
Sebuah DBMS harus mampu mengintegrasikan dengan software komunikasi. Kebanyakan pengguna mengakses database dari workstation. Kadang workstation tersebut terhubung secara langsung ke komputer DBMS. Dalam kasus yang lain, workstation berada pada lokasi yang jauh dan berkomunikasi dengan komputer DBMS melalui jaringan. Dalam hal ini DBMS menerima permintaan sebagai pesan komunikasi
dan menanggapi dengan cara yang sama. Semua pengiriman ini ditangani oleh Data Communication Manager.
f. Layanan Integritas
Sebuah DBMS harus menyediakan sebuah arti untuk memastikan bahwa data di dalam database dan perubahan pada data mengikuti aturan tertentu. Integritas database dapat mengacu pada kebenaran dan konsistensi data yang disimpan. Integritas berhubungan dengan kualitas data yang disimpan. Integritas biasanya diekspresikan dengan istilah batasan, yaitu berupa aturan konsisten yang tidak boleh dilanggar oleh database.
g. Layanan Peningkatan Keterbebasan Data
Sebuah DBMS harus memasukkan sebuah fasilitas untuk mendukung keterbebasan program dari struktur database yang sebenarnya. Data independence biasanya dicapai melalui sebuah view atau mekanisme subskema. Physical data independence lebih mudah untuk dicapai karena terdapat beberapa jenis perubahan yang dapat dibuat untuk karakteristik fisikal dari database tanpa mempengaruhi view. Bagaimanapun data independence logikal yang lengkap lebih susah untuk dicapai.
h. Layanan Utilitas
Sebuah DBMS harus menyediakan seperangkat layanan utilitas. Program utilitas membantu DBA mengelola database secara efektif. Beberapa utilitas bekerja pada tingkat eksternal, dan konsekuensinya dapat dibuat oleh DBA, yang lainnya bekerja pada tingkat internal dan dapat disediakan hanya dengan vendor
DBMS. Contoh dari utilitas tersebut antara lain :
a. Fasilitas import, untuk meng-load database dari flat file, dan fasilitas eksport, untuk meng-unload database pada flat file
b. Fasilitas pemantauan, untuk memantau penggunaan dan operasi database c. Program analisa statistik, untuk memeriksa performa dan penggunaan statistik
d.Fasilitas penyusunan index, untuk menyusun kembali index dan overflow mereka e. Penempatan dan pengumpulan sampah, untuk menghilangkan record yang dihapus secara fisik dari alat penyimpanan, untuk menggabungkan ruang yang terlepas, dan untuk menempatkan kembali record tersebut di mana ia dibutuhkan.
2.2.6 Komponen DBMS
1. Querry Processor : Merupakan komponen DBMS yang utama yang mengubah query ke dalam seperangkat instruksi tingkat rendah langsung ke database manager
2. Database Manager : DM mengantarmukakan dengan program aplikasi usersubmitted dan query. DM menerima query dan memeriksa skema eksternal dan konseptual untuk menentukan record konseptual apa yang diperlukan untuk memuaskan permintaan. 3. File Manager : File manager memanipulasi penyimpanan file dan mengatur penempatan ruang penyimpanan dalam disk. Komponen ini mendirikan dan memelihara daftar struktur dan index yang didefinisikan dalam skema internal
4. DML Processor : Modul ini mengubah pernyataan DML yang tertanam dalam program aplikasi ke dalam panggilan fungsi standard dalam host language. Komponen ini harus berinteraksi dengan query processor untuk membuat kode yang sesuai.
5. DDL Compiler : Modul ini mengubah pernyataan DDL ke dalam seperangkat tabel berisi meta data. Tabel ini kemudian disimpan dalam katalog sistem sementara itu informasi kendali disimpan dalam header file data.
6. Catalog Manager : Catalog Manager mengatur akses ke dan memelihara katalog sistem. Katalog sistem diakses oleh sebagian besar komponen DBMS.
2.2.7 Katalog Sistem
Menurut Connolly dan Begg (2002,p61), katalog sistem merupakan
tempat penyimpanan informasi yang menjelaskan data dalam database, yaitu meta data atau data tentang data. Katalog sistem menyimpan informasi seperti berikut : a. Nama, jenis, dan ukuran data
b. Nama relationship
c. Batasan integritas pada data
d. Nama pengguna yang berotoritas yang mempunyai akses pada data. e. Skema eksternal, konseptual, dan internal dan pemetaan antara skema
f. Penggunaan statistik, seperti frekuensi transaksi dan perhitungan sejumlah akses yang dibuat pada objek dalam database. Sedangkan katalog sistem mempunyai beberapa keuntungan yaitu :
g. Informasi tentang data dapat dikumpulkan dan disimpan secara terpusat. Hal ini membantu memelihara kendali data sebagai sebuah sumber
h. Arti data dapat didefinisikan, yang akan membantu pengguna lain memahami tujuan data
i. Dapat mengidentifikasi pengulangan dan inkonsistensi lebih mudah sejak data terpusat j. Perubahan pada database dapat direkam
k. Dapat membuat sistem pengamanan l. Dapat memastikan integritas
Gambar 2.1 : Komponen DBMS
2.2.8 Struktur Data Relasional
Menurut Connolly dan Begg (2002,p72), struktur data relasional terbagi menjadi beberapa bagian yaitu :
1. Relasi : Merupakan sebuah tabel dengan baris dan kolom. Digunakan untuk menyimpan informasi tentang objek yang digambarkan dalam database
2. Atribut : Merupakan nama kolom dari relasi. Atribut dapat ditampilkan dalam berbagai perintah dan dalam relasi yang sama sehingga menyampaikan arti yang sama. 3. Domain : Merupakan sekelompok nilai yang diijinkan bagi satu atau lebih atribut. Setiap atribut dalam relasi didefinisikan pada sebuah domain. Domain dapat berbeda bagi setiap atribut, atau dua/lebih atribut dapat didefinisikan pada domain yang sama. Konsep domain sangat penting karena memungkinkan pengguna menjelaskan arti dan sumber nilai yang ada pada atribut.
4. Tuple : Merupakan baris dari sebuah relasi. Tuple dapat disebut intention jika struktur relasi, domain serta batasan-batasan yang lainnya pada nilai yang mungkin bersifat tetap, namun sebaliknya jika relasi berubah setiap waktu ini disebut extension.
5. Degree : Merupakan jumlah atribut yang terdapat dalam relasi. Jika relasi mempunyai satu atribut akan mempunyai derajat satu yang disebut relasi unary/satu tuple. Jika relasi mempunyai dua atribut akan mempunyai derajat dua yang disebut binary. Dan begitu seterusnya dengan menggunakan istilah nary.
6. Cardinality : Merupakan jumlah tuple yang terdapat dalam relasi. Merupakan properti dari extension relasi dan ditentukan dari instance tertentu.
7. Database Relasional : Merupakan kumpulan dari relasi yang ternormalisasi dengan nama relasi yang berbeda.
2.2.9 Sifat-Sifat Relasi
Menurut Connolly dan Begg (2002,p77), relasi mempunyai sifat-sifat sebagai berikut :
a. Nama relasi berbeda satu sama lain dalam skema relasional b. Setiap sel dari relasi berisi satu nilai atomik
c. Setiap atribut memiliki nama yang berbeda d. Nilai satu atribut berasal dari domain yang sama e. Setiap tuple berbeda, dan tidak ada duplikasi tuple
2.2.10 Relational Keys
Menurut Connolly dan Begg (2002,p78), relasional key dibagi menjadi beberapa jenis yaitu :
1. Superkey : Merupakan sebuah atribut atau sekelompok atribut yang mengidentifikasi secara unik tuple dalam relasi. Superkey yang mudah diidentifikasi adalah yang hanya berisi jumlah minimum atribut yang diperlukan
2. Candidate Key : Merupakan superkey dalam relasi. Candidate key (K), bagi sebuah relasi (R) mempunyai dua sifat yaitu :
a. Keunikan : Dalam setiap tuple dari R, nilai dari K secara unik mengidentifikasi tuple tersebut
b. Irreducibility : Tidak ada subset yang sesuai dari K yang mempunyai keunikan sifat Ketika sebuah key terdiri dari lebih dari satu atribut kita sebut ini sebagai composite key. 3. Primary Key : Merupakan candidate key yang terpilih untuk identifikasi tuple secara unik dalam satu relasi. Sementara candidate key yang tak terpilih sebagai primary key disebut alternate key
4. Foreign Key : Merupakan sebuah atribut atau sekelompok atribut dalam relasi yang dibandingkan dengan candidate key pada beberapa relasi.
2.2.11 Relasional Integritas
Menurut Connolly dan Begg (2002,p81), relasional integritas terbagi menjadi beberapa jenis yaitu :
a. Null
Merupakan gambaran sebuah nilai bagi sebuah atribut yang tidak diketahui atau tidak digunakan bagi tuple tersebut. Null tidak sama dengan nilai numerik nol atau spasi, tetapi null menggambarkan ketidakadaan nilai.
b. Integritas Entitas
Pada relasi dasar, tidak ada atribut primary key yang bernilai null. Berdasarkan definisi di atas, primary key minimal berperan sebagai identifier yang digunakan untuk mengidentifikasi tuple secara unik. Ini berarti tidak ada subset dari primary key yang cukup untuk menyediakan pengidentifikasian tuple yang unik.
c. Integritas Referential
Jika terdapat foreign key dalam relasi, maka nilai foreign key tersebut akan dibandingkan dengan nilai candidate key dari beberapa tuple pada relasi itu sendiri atau nilai foreign key harus null semuanya.
2.2.12 Entity Relationship Model 2.2.12.1 Entitas
Menurut Connolly dan Begg (2002,p331), entitas adalah sekumpulan objek yang diindentifikasi oleh sebuah perusahaan atau perorangan yang mempunyai sifat – sifat yang sama dan mempunyai keberadaan yang independen. Sebuah entitas memiliki keberadaannya yang bebas dan bisa menjadi objek dengan fisik (atau ‘real’) atau menjadi objek dengan keberadaan konseptual ( atau ‘abstrak’). Artinya perancang yang berbeda mungkin mengidentifikasikan entitas yang berbeda pula. Sebuah database biasanya berisi banyak tipe entitas yang berbeda pula. Dalam UML, huruf pertama dari entitas diawali dengan huruf Kapital.
Sedangkan menurut Connolly dan Begg (2002), entity occurrence adalah sebuah objek unik yang dapat di indentifikasikan dari sebuah tipe entitas. Berikut adalah contoh entitas : staf, cabang, property, pemilik.
Gambar 2.2 : Contoh Entitas
2.2.12.2 Relationship
Menurut Connolly dan Begg (2002,p334) relationship adalah sekumpulan hubungan yang berarti antara satu atau lebih entitas, dimana setiap tipe relationship diberi nama yang menggambarkan fungsinya.
Menurut Connolly dan Begg (2002,p334), relationship occurrence adalah hubungan yang dapat diidentifikasi secara unik, yang termasuk satu kejadian dari setiap entitas yang berpartisipasi.
Relationship Recursive
Menurut Connolly dan Begg (2002,p337), recursive relationship adalah jenis relationship di mana entitas yang sama berpartisipasi lebih dari satu di dalam peran yang berbeda. Sebagai
contoh, entitas staf berpartisipasi dua kali di dalam relationship supervises. Partisipasi pertama sebagai supervisor dan partisipasi ke dua sebagai anggota dari staf yang diawasi. Relationship mungkin diberikan nama peran untuk mengindikasikan tujuan yang setiap entitas yang berpartisipasi mainkan. Di sini penting untuk menentukan fungsi setiap partisipan.
2.2.12.3 Atribut
Menurut Connolly dan Begg (2002,p338), atribut adalah sebuah properti atau sifat dari entitas atau relationship. Sebagai contoh, entitas staf mungkin dapat menjelaskan atribut sebagai berikut: nostaf, nama, posisi, dan gaji. Setiap atribut menyimpan nilai yang menjelaskan setiap entity occurrence dan menggambarkan bagian utama dari data yang disimpan di dalam database.
Sedangkan menurut Connolly dan Begg (2002,p338), domain atribut adalah sekelompok nilai yang diperbolehkan bagi satu atau lebih atribut. Domain mendefinisikan nilai potensi yang atribut miliki. Sebagai contoh ruangan berhubungan dengan properti antara 1-15 untuk setiap entity occurrence. Kita oleh karena itu mendefinsikan sekelompok nilai bagi nomor ruangan/atribut rooms dari entitas properti sebagai sekelompok nilai integer antara 1-15.
2.2.12.4 Entitas Kuat Dan Lemah
Menurut Connolly dan Begg (2002,p342), entitas kuat adalah entitas yang keberadaannya tidak bergantung pada beberapa entitas yang lain.
Karakter dari entitas ini adalah bahwa setiap kejadian entitas teridentifikasi secara unik menggunakan atribut primary key. Sebagai contoh, kita dapat mengidentifikasi secara unik setiap anggota staf dengan menggunakan atribut staffno.
Sedangkan menurut Connolly dan Begg (2002,p343), entitas lemah adalah entitas yang keberadaannya tergantung pada beberapa entitas yang lain. Karakteristik dari entitas ini bahwa setiap kejadian entitas tidak dapat teridentifikasi secara unik hanya dengan menggunakan atribut yang berhubungan dengan entitas tersebut. Sebagai contoh, kita tidak dapat mengidentifikasi setiap kejadian dari entitas kesukaan hanya dengan menggunakan atribut entitas tersebut. Kita hanya dapat mengidentifikasi secara unik entitas kesukaan melalui relationship yang entitas kesukaan miliki dengan entitas klien yang secara unik teridentifikasi menggunakan primary key bagi entitas klien.
2.2.12.5 Struktural Constraint
Menurut Connolly dan Begg (2002,p344), multiplicity adalah jumlah kejadian yang mungkin dari entitas yang berhubungan pada kejadian tunggal dari sebuah hubungan entitas melalui relationship tertentu. Ini merupakan gambaran dari kebijakan/aturan bisnis yang dibuat oleh perusahaan. Memastikan bahwa semua batasan perusahaan yang sesuai teridentifikasi dan tergambarkan merupakan bagian penting dari pemodelan perusahaan. Terdapat tiga jenis relationship sesuai dengan batasan perusahaan yaitu : a. Relationship One To One (1:1)
b. Relationship One To Many (1:*)
Gambar 2.7 : Contoh One to Many Relationship
c. Relationship Many To Many (*:*)
Gambar 2.8 : Contoh Many to Many Relationship
2.2.12.6 Cardinality
Menurut Connolly dan Begg (2002,p351), cardinality yaitu menjelaskan jumlah maksimum yang mungkin kejadian relationship bagi entitas yang berpartisipasi di dalam relationship yang diberilkan. Cardinality terdiri dari : one-to-one(1:1), one-to-many(1:*), dan many-to-many(*:*).
2.2.12.7 Compotition
Menurut Connolly dan Begg (2002,p372), composition merupakan sebuah bentuk tertentu dari agregasi yang menggambarkan hubungan antara entitas, dimana disana terdapat kepemilikan yang kuat antara ‘keseluruhan dan ‘bagian’. Disini objek hanya menjadi bagian satu composite pada waktu itu.
Gambar 2.9 : Contoh Compotition 2.2.13 Normalisasi
Menurut Connoly & Begg (2002,p376) pengertian normalisasi adalah suatu teknik untuk memproduksi satu set hubungan dengan kebutuhan yang diinginkan, memberi kebutuhan data dari suatu perusahaan. Tujuan lain dari normalisasi adalah mencegah adanya redudansi atau pengulangan data yang nantinya akan menghemat tempat pada penyimpanan (connoly & begg, 2002,p377).
Proses dalam normalisasi menurut Connoly dan Begg terbagi menjadi beberapa tahap, yaitu :
Unnormalized Form (UNF)
Suatu tabel dikatakan sebagai bentuk yang unnormalized bila didalamnya terdapat kelompok berulang atau yang biasa dikenal repeating group. Untuk lebih jelasnya lihat tabel berikut :
Tabel 2.1 : Tabel Nilai mahasiswa UNF
Kelompok Berulang
Nim Nama Alamat Kecamatan Kdpos
Kode
MK Mata Kuliah SKS Nilai 866220 Nicholas Tj.Duren Grogol 11470 TI345 Kalkulus 1 4/0 89
TI453 Aljabar 4/0 98
CB845 Character Building 2/0 89
SI343 Perancangan Sistem 4/0 78
846544 Ronny Tj.Priuk Priuk 11488 TI345 Kalkulus 1 4/0 89
CB845 Character Building 2/0 87
SI343 Perancangan Sistem 4/0 87
465497 Agus
Tj.
Karang Cikarang 15874 TI332 Struktur Data 4/2 78
TI345 Kalkulus 1 4/0 86
Normalisasi Data Pertama (First Normal Form/1NF)
Untuk mengubah bentuk Unnormalized Form menjadi 1NF, yang harus dilakukan adalah mengidentifikasi dan menghilangkan kelompok berulang, agar setiap pertemuan antara baris dan kolom berisi satu dan hanya satu nilai. Dilihat dari contoh bentuk Unnormalized sebelumnya, dapat diidentifikasi kelompok berulang sebagai berikut : Hari, waktu, KdMtk, MataKuliah, SKS, Ruang dan Kelas.
Langkah – langkah membuat normal pertama dari bentuk unnormal :
1. Menentukan 1 atau lebih atribut sebagai atribut kunci dari tabel unnormal.
2. Mengidentifikasi repeating group dari suatu tabel unnormal yang mengulang atribut kunci di atas.
3. Menghilangkan repeating group, dapat dilakukan dengan 2 cara.
4. Mengisi kolom dari baris yang kosong dengan data – data yang sesuai atau
5. Menempatkan data yang berulang beserta key-nya ke dalam tabel baru. Hasil dari bentuk 1NF dapat dilihat pada tabel berikut :
Tabel 2.2 : Tabel mahasiswa 1NF
Kelompok Berulang
Nim Nama Alamat Kecamatan Kdpos
Kode
MK Mata Kuliah SKS Nilai 866220 Nicholas Tj.Duren Grogol 11470 TI345 Kalkulus 1 4/0 89 866220 Nicholas Tj.Duren Grogol 11470 TI453 Aljabar 4/0 98 866220 Nicholas Tj.Duren Grogol 11470 CB845 Character Building 2/0 89 866220 Nicholas Tj.Duren Grogol 11470 SI343 Perancangan Sistem 4/0 78 846544 Ronny Tj.Priuk Priuk 11488 TI345 Kalkulus 1 4/0 89 846544 Ronny Tj.Priuk Priuk 11488 CB845 Character Building 2/0 87 846544 Ronny Tj.Priuk Priuk 11488 SI343 Perancangan Sistem 4/0 87
465497 Agus
Tj.
Karang Cikarang 15874 TI332 Struktur Data 4/2 78
465497 Agus
Tj.
Karang Cikarang 15874 TI345 Kalkulus 1 4/0 86
Normalisasi Data kedua (Second Normal Form/2NF)
Pada tahap normalisasi 2NF dihilangkan setiap Partial dependence yang ada pada bentuk 1NF. Yang dimaksud dengan partial dependence adalah atribut non primary key yang merupakan sebagian fungsi dari primary key, atau dapat dijelaskan demikian apabila terdapat atribut – atribut dalam suatu relasi yang memiliki ketergantungan fungsional misalnya atribut A (Kd_dosen, Nama) dan atribut B (KdMtk), dikatakan partial dependence apabila ada sebagian atribut dari A dihilangkan namun ketergantungan masih ada. Langkah membuat 2NF dari 1NF :
1. Mengidentifikasi primary key dari bentuk 1NF.
2. Mengidentifikasi functional dependency pada bentuk 1NF.
3. Bila terdapat partial dependency dalam primary key maka tempatkan primary key tersebut dalam suatu tabel baru beserta field – field yang berkaitan dengannya
Tabel 2.3 Tabel Ketergantungan Fungsional
Tabel 2.4 Tabel Mahasiswa (2NF)
Nim Nama Alamat Kecamatan Kdpos 866220 Nicholas Tj.Duren Grogol 11470 846544 Ronny Tj.Priuk Priuk 11488 465497 Agus Tj. Karang Cikarang 15874
Tabel 2.5 Tabel Mata Kuliah (2NF) Mata Kuliah SKS Kalkulus 1 4/0 Aljabar 4/0 Character Building 2/0 Perancangan Sistem 4/0 Struktur Data 4/2
Tabel 2.6 : Tabel Daftar Nilai (2NF) Nim Kode MK Nilai 866220 TI345 89 866220 TI453 98 866220 CB845 89 866220 SI343 78 846544 TI345 89 846544 CB845 87 846544 SI343 87 465497 TI332 78 465497 TI345 86
Tabel dalam bentuk 2ND-NF: ketergantungan Parsial dipisahkan Normalisasi Data Ketiga (Third Normal Form/3NF)
Pengujian terhadap bentuk normal ketiga dilakukan dengan cara melihat apakah terdapat atribut bukan key tergantung fungsional terhadap atribut bukan key yang lain (disebut ketergantungan transitive) Pada tahap normalisasi 3NF dihilangkan setiap Transitive dependence yang terdapat pada bentuk 2NF. Kondisi transitive dependence dapat diterangkan sebagai berikut : misalkan terdapat atribut A,B dan C yang mempunyai relasi A→B dan B→C, C adalah transitive
dependence terhadap A melalui B.
Ketergantungan transitif (transitive dependency) terjadi ketika ada atribut yang bukan merupakan primary key, yang memiliki ketergantungan pada atribut lain yang juga bukan merupakan primary key
Langkah – langkah membuat 3NF dari 2NF : 1. Mengidentifikasi primary key pada bentuk 2NF.
2. Mengidentifikasi functional dependency dalam tabel tersebut.
3. Bila terdapat transitive dependency pada primary key maka tempatkan primary key beserta field –field yang berkaitan pada tabel baru.
Proses Normalisasi secara umum dilakukan sampai ke tahap 3NF karena
sudah tidak terdapat data pengulangan, dan anomali yang ada sudah sangat sedikit
Tabel 2.7 Tabel Mahasiswa (3NF) Nim Nama Alamat Kdpos 866220 Nicholas Tj.Duren 11470 846544 Ronny Tj.Priuk 11488 465497 Agus Tj. Karang 15874
Tabel 2.8 Tabel Mata Kuliah (3NF) Kode MK Mata Kuliah SKS TI345 Kalkulus 1 4/0 TI453 Aljabar 4/0 CB845 Character Building 2/0 SI343 Perancangan Sistem 4/0 TI332 Struktur Data 4/2
Tabel 2.9 : Tabel Nilai (3NF)
Nim Kode MK Nilai 866220 TI345 89 866220 TI453 98 866220 CB845 89 866220 SI343 78 846544 TI345 89 846544 CB845 87 846544 SI343 87 465497 TI332 78 465497 TI345 86
Tabel 2.10 : Tabel Wilayah (3NF) Kecamatan Kdpos
Grogol 11470 Priuk 11488 Priuk 11488
Tabel dalam bentuk 3rd-NF : Ketergantungan Transitif dipisahkan
Jika hasil Normalisasi Ketiga diatas digambarkan dengan diagram E-R,maka akan diperoleh gambaran skema database sebagai berikut :
Gambar 2.10 : Entity Hasil Normalisasi
2.2.14 Siklus Hidup Aplikasi Database
Menurut Connolly dan Begg (2002,p273), siklus hidup aplikasi database terdiri dari sepuluh tahapan yaitu :
2.2.14.1 Perencanaan Database
Menurut Connolly dan Begg (2002,p273), perencanaan database adalah sebuah aktifitas pengaturan yang memungkinkan langkah-langkah dari aplikasi database direalisasikan seefektif dan efisien mungkin
Hal pertama yang dilakukan adalah mendefinisikan pernyataan sistem bagi proyek database. Pernyataan misi mendefinisikan tujuan utama dari aplikasi database. Pernyataan misi membantu mengklarifikasi tujuan dari proyek database dan menyediakan jalur yang lebih jelas terhadap pembuatan aplikasi database yang efisien dan efektif. Aktifitas selanjutnya mendefinisikan tujuan misi. Setiap tujuan misi harus mengidentifikasikan tugas tertentu yang harus didukung oleh aplikasi database Jika database mendukung tujuan misi, pernyataan misi harus disesuaikan. Pernyataan dan tujuan misi harus diselesaikan dengan informasi tambahan yang ditentukan seperti : kegiatan yang harus dilakukan, sumber daya apa yang digunakan, dan biaya yang harus dibayarkan
2.2.14.2 Definisi Sistem
Menurut Connolly dan Begg (2002,p274), definisi sistem adalah suatu kegiatan yang menjelaskan bidang dan batasan dari aplikasi database dan user view utama. Batasan dan bidang sistem yang kita buat harus ditentukan tidak hanya untuk pengguna dan area aplikasi saat ini, namun juga untuk pengguna dan area aplikasi di masa depan.
2.2.14.3 Pengumpulan dan Analisa Kebutuhan
Menurut Connolly dan Begg (2002,p276), pengumpulan dan analisa kebutuhan merupakan sebuah proses pengumpulan dan penganalisaan informasi tentang bagian organisasi yang harus didukung oleh aplikasi database, dan menggunakan informasi ini untuk mengidentifikasi kebutuhan pengguna bagi sistem yang baru. Informasi yang didapatkan dari setiap user view utama (peran kerja atau area aplikasi perusahaan) adalah
a. Deskripsi data yang digunakan atau dibuat
c. Berbagai kebutuhan tambahan bagi aplikasi dastabase yang baru
Dalam tahapan ini, jumlah data yang diperoleh tergantung masalah dan kebijakan perusahaan. Informasi yang terkumpul pada tahapan ini mungkin tidak terstruktur dan melibatkan beberapa permintaan informal yang harus diubah ke dalam kebutuhan yang lebih terstruktur. Terdapat dua pendekatan dalam tahapan ini yaitu pendekatan terpusat dan pendekatan view integration
2.2.14.4 Perancangan Database
Menurut Connolly dan Begg (2002,p279), perancangan database merupakan sebuah proses pembuatan sebuah rancangan bagi database yang akan mendukung operasi dan tujuan perusahaan.
Tahap-Tahap Perancangan Database
Menurut Connolly dan Begg (2002,p417), tahap-tahap perancangan database dibagi menjadi tiga bagian, yang mana masingmasing bagian terdapat beberapa tahap yaitu : 1. Perancangan Database Konseptual
Menurut Connolly dan Begg (2002,p419), perancangan database konseptual adalah sebuah proses pembuatan model dari informasi yang digunakan dalam perusahaan, yang terbebas dari semua pertimbangan fisikal seperti DBMS target, program aplikasi, bahasa pemrograman, hardware dan sebagainya.
Perancangan database konseptual terbagi menjadi beberapa tahap yaitu : Langkah 1 : Membangun model data konseptual lokal bagi setiap view
Bertujuan untuk membangun model data konseptual lokal dari sebuah perusahaan bagi setiap view tertentu. Selama analisa, sejumlah user view telah diidentifikasi dan tergantung pada jumlah overlap antara view tersebut. Beberapa user view mungkin telah dikombinasikan bersama untuk membentuk view bersama yang diberi nama yang sesuai. Setiap model data konseptual lokal terdiri dari :
a. Entitas. b. Relationship.
d. Primary key dan alternate key. e. Batasan integritas.
Di dalam langkah satu ini melibatkan beberapa aktifitas yaitu : a. Mengidentifikasi Entitas
Bertujuan untuk mengidentifikasi entitas utama yang dibutuhkan oleh view. Sebuah metode untuk mengidentifikasi entitas adalah dengan memeriksa spesifikasi kebutuhan pengguna. Dari spesifikasi ini, kita mengidentifikasi kata benda atau frase benda (ex : nomor staf, nama staf, nomor properti, alamat properti dsb). Kita juga mencari objek utama (ex : manusia, tempat, kejadian, dan konsep)
b. Mengidentifikasi Relationship
Bertujuan untuk mengidentifikasi relationship penting yang terdapat antara entitas yang telah diidentifikasi. Dalam mengidentifikasi relationship kita dapat menggunakan grammar dari spesifikasi kebutuhan pengguna. Secara khusus, relationship ditandai dengan kata kerja atau ekspresi verbal (ex : Staf mengatur Properti, Pemilik mempunyai Properti, Properti berhubungan dengan Pelepasan)
c. Mengidentifikasi Dan Menghubungkan Atribut Dengan Entitas atau Relationship Bertujuan untuk menghubungkan atribut dengan entitas atau relationship yang sesuai. Di sini kita mencari kata benda atau frase benda dalam spesifikasi kebutuhan pengguna. Atribut dapat diidentifikasi di mana kata benda atau frase benda merupakan sebuah sifat, kualitas, identifier, atau karakteristik dari entitas atau relationship
d. Menentukan Domain Atribut
Bertujuan untuk menentukan domain bagi atribut di dalam model data konseptual lokal. Domain merupakan sebuah kolam nilai dari satu atau lebih atribut yang menggambarkan nilai mereka.
Pengembangan model data yang utuh menentukan domain bagi setiap atribut termasuk : 1. Sekelompok nilai yang diperbolehkan bagi atribut.
2. Ukuran dan format atribut.
e. Menentukan Atribut Primary Key dan Candidate Key
Bertujuan untuk mengidentifikasi candidate key bagi setiap entitas dan jika terdapat lebih dari satu candidate key, pilihlah satu untuk dijadikan primary key.
Ketika memilih sebuah primary key diantara candidate key, gunakanlah panduan berikut untuk membantu membuat pilihan :
1. Sebuah Candidate Key dengan sekelompok atribut yang minim.
2. Sebuah Candidate Key yang paling sedikit mempunyai perubahan nilai. 3. Sebuah Candidate Key dengan karakter paling sedikit (bagi atribut tekstual). 4.Sebuah Candidate Key dengan nilai maksimum terkecil (bagioatribut numerik). 5. Sebuah Candidate Key yang paling mudah digunakan dari sudutpandang pengguna.
f. Mempertimbangkan Penggunaan Konsep Pemodelan Lebih Lanjut
Bertujuan untuk mempertimbangkan penggunaan konsep pemodelan lebih lanjut, seperti spesialisasi/generalisasi, aggregasi, dan composition. Jika kita memilih pendekatan spesialisasi, kita berusaha untuk memperhatikan perbedaan antara entitas dengan mendefinisikan satu atau lebih entitas subclass dari entitas superclass. Jika kita menggunakan pendekatan generalisasi, kita berusaha mengidentifikasi fitur umum antara entitas untuk mendefinisikan pengeneralisasian entitas superclass. Kita menggunakan aggregasi untuk menggambarkan relationship ’mempunyai’ atau ’bagian dari’ antara entitas di mana yang satu menggambarkan ’keseluruhan’ dan yang lainnya menggambarkan ’bagian’. Kita menggunakan composition untuk menggambarkan hubungan antara entitas di mana terdapat hubungan yang sangat erat antara ’keseluruhan’ dan ’bagian’
g. Memeriksa Model untuk Pengulangan
Bertujuan untuk memeriksa keberadaan berbagai pengulangan di dalam model. Terdapat dua aktifitas di dalam tahap ini yaitu :
1.Memeriksa kembali relationship one-to-one (1:1). 2. Menghilangkan relationship yang berulang.
h. Memvalidasi Model Konseptual Lokal Terhadap Transaksi User
Bertujuan untuk memastikan bahwa model konseptual lokal mendukung transaksi yang diperlukan oleh view. Dengan menggunakan model tersebut, kita berusaha untuk membentuk operasi secara manual. Jika kita dapat memecahkan semua transaksi dalam
cara ini, kita telah memastikan bahwa model data konseptual mendukung transaksi yang diperlukan. Ada dua pendekatan untuk memastikan bahwa model data konseptual lokal mendukung transaksi yang diperlukan yaitu :
1.Menjelaskan transaksi.
2. Menggunakan transaction pathway.
i. Mereview Model Data Konseptual Lokal Dengan User
Bertujuan untuk mereview model data konseptual lokal dengan pengguna untuk memastikan bahwa model tersebut merupakan gambaran yang sebenarnya dari view. Model data konseptual termasuk ER diagram dan dokumen pendukung lainnya yang menjelaskan model data. Jika terdapat kesalahan di dalam model data, kita harus membuat perubahan yang sesuai, yang mungkin memerlukan kembali ke tahap sebelumnya.
2. Perancangan Database Logikal
Menurut Connolly dan Begg (2002,p441), perancangan database logikal merupakan sebuah proses pembuatan model dari informasi yang digunakan dalam sebuah perusahaan berdasarkan pada model data tertentu, tetapi terbebas dari DBMS tertentu dan pertimbangan fisikal yang lainnya. Dalam bagian ini terdapat beberapa tahap yaitu : Langkah 2 : Membangun dan memvalidasi model data logikal lokal bagi setiap view Bertujuan untuk membangun model data logikal lokal dari model data konseptual lokal yang menggambarkan view tertentu dari sebuah perusahaan dan kemudian memvalidasi model tersebut untuk memastikan bahwa model terstruktur dengan baik dan mendukung transaksi yang diperlukan.
Untuk menyederhanakan proses ini kita memasukkan langkah
opsional yaitu menghilangkan fitur yang tidak dapat digambarkan secara
langsung di dalam model relasional. Kita juga memvalidasi skema relasional menggunakan aturan normalisasi untuk memastikan skema tersebut terstruktur dengan baik.
Kita memvalidasi model logikal untuk memastikan bahwa model tersebut mendukung transaksi yang diberikan dalam spesifikasi kebutuhan pengguna. Model data logikal lokal yang tervalidasi digunakan sebagai dasar untuk prototyping, dan kemudian kita tambahkan batasan integritas ke dalam model. Di dalam langkah ini melibatkan beberapa aktifitas yaitu :
a. Menghilangkan Fitur yang Tidak Sesuai dengan Model Relasional
Bertujuan untuk memperbaiki model data konseptual lokal untuk menghilangkan fitur yang tidak sesuai dengan model relasional. Dalam tahap ini kita mengubah struktur yang rumit ke dalam bentuk yang lebih mudah ditangani oleh sistem.
Tujuan dari tahap ini adalah untuk :
1. Menghilangkan relationship binary many-to-many (*:*) 2. Menghilangkan relationship recursive many-to-many (*:*) 3.Menghilangkan relationship yang kompleks
4. Menghilangkan atribut multi-value
b. Mendapatkan Relasi Bagi Model Data Logikal Lokal
Bertujuan untuk membuat relasi bagi model data logikal lokal untuk menggambarkan entitas, relationship, dan atribut yang telah teridentifikasi. Kita menjelaskan composition menggunakan DDL bagi database relasional.
Kita pertama kali menentukan nama relasi diikuti oleh daftar atribut sederhana relasi di dalam tanda kurung. Kita kemudian mengidentifikasi primary key dan berbagai alternate dan atau foreign key dari relasi. Berdasarkan identifikasi foreign key, relasi yang berisi primary key referensi diberikan. Berbagai derived atribut juga didaftarkan bersama bersama bgaimana setiap atribut tersebut dihitung
c. Memvalidasi Relasi Menggunakan Normalisasi
Bertujuan untuk memvalidasi relasi di dalam model data logical lokal menggunakan teknik normalisasi. Normalisasi digunakan untuk meningkatkan model sehingga model tersebut memenuhi berbagai batasan yang menghindari duplikasi data yang tak perlu. Normalisasi memastikan bahwa hasil model mendekati model perusahaan yang digambarkan, konsisten, dan mempunyai pengulangan yang minim serta mempunyai kestabilan yang maksimal.
d. Memvalidasi Relasi Terhadap Transaksi User
Bertujuan untuk memastikan bahwa relasi di dalam model data logikal lokal mendukung transaksi yang diperlukan oleh view. Dalam tahap ini, kita memeriksa bahwa relasi yang dibuat pada tahap sebelumnya juga mendukung transaksi tersebut, dan dengan demikian dipastikan tidak ada kesalahan yang terjadi selama pembuatan relasi
e. Mendefinisikan Batasan Integritas
Bertujuan untuk menjelaskan batasan integritas yang diberikan dalam view. Batasan integritas merupakan batasan yang kita tentukan untuk melindungi database untuk menjadi tidak konsisten. Pada tahap ini kita hanya memfokuskan pada rancangan tingkat tinggi yaitu menentukan batasan integritas apa yang diperlukan, bukan bagaimana hal ini dicapai. Setelah mengidentifikasi batasan integritas, kita akan mempunyai model data logikal lokal yaitu gambaran yang lengkap dan akurat dari view. Terdapat 5 Jenis batasan integritas yaitu :
1.Data yang diperlukan 2. Batasan domain atribut 3. Batasan entitas
4. Batasan referensial 5. Batasan perusahaan
f. Mereview Model Data Logikal Lokal Dengan User
Bertujuan untuk memastikan bahwa model data logikal lokal dan dokumen pendukung lainnya yang menjelaskan model tersebut adalah gambaran sebenarnya dari view.
Langkah 3 : Membangun dan memvalidasi model data logikal global
Bertujuan untuk mengkombinasikan model data logikal lokal individu ke dalam model data logikal global tunggal yang menggambarkan perusahaan. Kemudian memvalidasi model global, pertama terhadap aturan normalisasi, dan yang ke dua terhadap transaksi yang dijelaskan dalam semua view.
Kita melakukan normalisasi hanya pada relasi yang berubah selama proses penggabungan dan memvalidasi model tersebut bagi transaksi yang memerlukan akses ke area model yang mengalami perubahan.
Di dalam langkah ini melibatkan beberapa tindakan yaitu :
a. Menggabungkan Model Data Logikal Lokal ke Dalam Model Global
Bertujuan untuk menggabungkan model data logikal lokal individu ke dalam model data logikal global tunggal dari perusahaan. Kita menggunakan model data logikal lokal untuk mengidentifikasi persamaan dan perbedaan antara model tersebut dan dengan demikian membantu menggabungkan model bersama-sama. Cara ini relatif mudah bagi aplikasi database yang sederhana. Namun dibutuhkan beberapa tugas untuk melakukan teknik ini bagi aplikasi database yang kompleks yaitu :
1. Mereview nama dan isi entitas/relasi dan candidate key mereka 2. Mereview nama dan isi relationship/foreign key
3. Menggabungkan entitas/relasi dari model data lokal
4. Memasukkan (tanpa menggabungkan) entitas/relasi unik ke setiap model data lokal 5. Menggabungkan relationship/foreign key dari model data lokal
6. Memasukkan (tanpa menggabungkan) relationship/foreign key unik ke setiap model data lokal
7. Memeriksa entitas/relasi dan relationship/foreign key yang terabaikan 8. Memeriksa foreign key
9. Memeriksa batasan integritas
10. Menggambarkan ER global/diagram relasi 11. Meng-update dokumentasi
b. Memvalidasi Model Data Logikal Global
Bertujuan untuk memvalidasi relasi yang dibuat dari model data logikal global menggunakan teknik normalisasi dan untuk memastikan mereka mendukung transaksi yang diperlukan. Tahap ini hanya diperlukan untuk memeriksa area dari model yang dihasilkan dalam berbagai perubahan selama proses penggabungan.
c. Memeriksa Perkembangan Di Masa Depan
Bertujuan untuk menentukan apakah terdapat banyak perubahan yang signifikan yang mungkin dapat diketahui di masa depan dan untuk menilai apakah model data logikal
global dapat menangani perubahan ini. Merupakan hal yang penting model data logikal global
dapat dikembangkan dengan mudah. Jika model hanya dapat mendukung kebutuhan saat ini, maka keberadaan model tersebut akan relatif singkat. Sehinnga model tersebut perlu dikembangkan agar mampu mendukung kebutuhan yang baru dengan pengaruh yang minimpada pengguna.
d. Mereview Model Data Logikal Global Dengan User
Bertujuan untuk memastikan bahwa model data logikal global adalah gambaran yang sebenarnya dari perusahaan
3. Perancangan Database Fisikal
Menurut Connolly dan Begg (2002,p478), perancangan database fisikal adalah sebuah proses pembuatan deskripsi implementasi database pada tempat penyimpanan kedua. Perancangan ini menjelaskan relasi dasar, organisasi file, dan index yang digunakan untuk mencapai akses yang efisien ke data dan berbagai batasan integritas yang berhubungan serta penilaian keamanan. Di dalam perancangan ini terdapat beberapa tahap yaitu :
Langkah 4 : Menterjemahkan model data logikal global bagi DBMS target
Bertujuan untuk menghasilkan skema database relasional dari model data logikal global yang dapat diimplementasikan dalam DBMS target. Bagian pertama dari proses ini adalah mengumpulkan informasi yang diperoleh selama perancangan database logikal dan terdokumentasi dalam kamus data. Bagian kedua adalah menggunakan informasi ini untuk membuat rancangan relasi dasar. Proses ini memerlukan pengetahuan yang mendalam dari fungsi yang ditawarkan oleh DBMS target. Di dalam langkah ini melibatkan beberapa aktifitas yaitu :
a. Merancang Relasi Dasar
Bertujuan untuk memutuskan bagaimana menggambarkan relasi dasar yang telah teridentifikasi di dalam model data logikal global dalam DBMS target. Dalam tahap ini, kita pertama kali menyusun dan memahami informasi tentang relasi yang dibuat selama
perancangan database logikal. Informasi yang diperlukan dapat diperoleh dari kamus data dan definisi relasi yang dijelaskan menggunakan DDL. Definisi relasi terdiri dari : 1. Nama Relasi
2. Daftar atribut sederhana di dalam tanda kurung 3. Primary key, alternate key, dan foreign key
4. Daftar berbagai derive atribut dan bagaimana mereka seharusnya dihitung
5. Batasan integritas referensial bagi berbagai foreign key yang teridentifikasi Dari kamus data, kita juga mempunyai definisi bagi setiap attribute yaitu :
6. Domain-nya, terdiri dari jenis data, panjang, dan berbagai batasan pada domain 7. Nilai default opsional bagi atribut
8. Apakah atribut dapat menyimpan nilai null
b. Merancang Gambaran Data yang Diperoleh
Bertujuan untuk memutuskan bagaimana menggambarkan berbagai derived data yang terdapat di dalam model data logikal global di dalam DBMS target. Seringkali derived atribut tidak ditampilkan dalam model data logikal tetapi didokumentasikan dalam kamus data. Jika derived atribut ditampilkan dalam model, sebuah tanda ’/ digunakan untuk menandai bahwa atribut tersebut adalah atribut derived.
c. Merancang Batasan Perusahaan
Bertujuan untuk merancang batasan perusahaan bagi DBMS target. Perancangan batasan yang demikian tergantung pada pilihan DBMS, di mana setiap dari DBMS menyediakan fasilitas dan standard yang berbeda-beda.
Langkah 5 : Merancang gambaran fisikal
Bertujuan untuk menentukan organisasi file yang optimal untuk menyimpan relasi dasar dan index yang diperlukan untuk mencapai performa yang diinginkan, yaitu sebuah cara di mana relasi dan tuple akan disimpan pada tempat penyimpanan kedua. Tujuan utama dari perancangan database fisikal adalah untuk menyimpan data dalam cara yang efisien. Ada beberapa faktor yang digunakan untuk menilai efisiensi yaitu :
1. Transaction throughput : Hal ini berkaitan dengan jumlah transaksi yang dapat diproses dalam selang waktu yang diberikan. Di dalam beberapa sistem, transaction throughput yang tinggi merupakan hal yang penting untuk keberhasilan menyeluruh dari sistem,
2. Waktu tanggap : Dari sudut pandang pengguna mereka menginginkan waktu tanggap yang sesedikit mungkin pada aplikasi database yang dibuat.
3. Penyimpanan hardisk : Merupakan jumlah ruang yang diperlukan untuk menyimpan file database. Kita menginginkan jumlah yang minimum dari ruang hardisk yang digunakan untuk menyimpan. Ketiga faktor tersebut harus dilaksanakan secara seimbang antara satu dan yang lainnya. Selain itu kita juga harus memahami sumberdaya sistem yang digunakan Terdapat lima aktifitas dalam tahap ini yaitu :
a. Menganalisa Transaksi
Bertujuan untuk memahami fungsi dari transaksi yang akan berjalan pada database dan untuk menganalisa transaksi yang penting. Oleh karena itu, kita perlu mempunyai pengetahuan tentang transaksi yang akan berjalan pada database, baik kuantitatif maupun kualitatif.
Terdapat beberapa kriteria performa dari transaksi yang berusaha diidentifikasi yaitu : 1.Transaksi yang berjalan secara berkala dan akan mempunyai pengaruh yang signifikan pada performa.
2. Transaksi yang penting untuk operasi bisnis
3. Waktu selama sehari/seminggu ketika di sana akan banyak permintaan yang dibuat pada database
Kita menggunakan informasi tersebut untuk mengidentifikasi bagian dari database yang dapat menyebabkan masalah performa. Kita juga perlu mengidentifikasi fungsi tingkat tinggi dari transaksi seperti atribut yang di-update dalam transaksi update atau sebuah kriteria yang digunakan untuk membatasi tuple yang diperoleh dari query. Kita menggunakan informasi ini untuk memilih organisasi file dan index yang sesuai.
Ada beberapa tindakan yang dilakukan dalam menganalisa transaksi yaitu : 1. Memetakan semua jalur transaksi pada relasi
3. Menganalisa penggunaan data dari transaksi yang terpilih yang melibatkan relasi transaksi tersebut
b. Memilih Organisasi File
Bertujuan untuk menentukan organisasi file yang efisien bagi setiap relasi dasar. Dalam beberapa kasus, DBMS relasional hanya memberikan sedikit atau tidak ada pilihan untuk memilih organisasi file, walaupun ada beberapa yang dibuat sebagai index yang ditentukan.
Terdapat beberapa jenis organisasi file : 1. Heap
2. Hash 3. B*Tree
4. Index Sequenial Access Method (ISAM) 5. Cluster
c. Memilih Index
Bertujuan untuk menentukan apakah dengan penambahan index akan meningkatkan performa sistem. Sebuah pendekatan yang dapat digunakan untuk memilih index yaitu dengan menentukan index primary atau clustering. Jika atribut yang dipilih merupakan key dari relasi index akan menjadi primary index. Jika atribut bukan merupakan sebuah key, index akan menjadi clustering index
d. Memperkirakan Kebutuhan Ruang Hardisk
Bertujuan untuk memperkirakan jumlah ruang hardisk yang diperlukan oleh DBMS. Hal ini tergantung pada DBMS target dan hardware yang digunakan untuk mendukung database Pengukuran didasarkan pada ukuran tiap tuple dan jumlah tuple dalam relasi Langkah 6 : Merancang user view
Bertujuan untuk merancang user view yang telah teridentifikasi selama tahap pengumpulan dan penganalisaan kebutuhan dari siklus hidup aplikasi database relasional.
Langkah 7 : Merancang Penilaian Keamanan
Bertujuan untuk merancang penilaian keamanan bagi database yang ditentukan oleh pengguna. Database menggambarkan sumberdaya perusahaan yang penting sehingga keamanan dari sumberdaya tersebut sangatlah penting. Selama tahap pengumpulan dan analisa kebutuhan, kebutuhan keamanan tertentu harus sudah didokumentasikan di dalam spesifikasi kebutuhan sistem. Tujuan dari tahap ini adalah merealisasikan kebutuhan keamanan yang telah ditentukan.
2.2.14.5 Pemilihan DBMS
Menurut Connolly dan Begg (2002,p284), pemilihan DBMS merupakan pemilihan sebuah DBMS yang sesuai untuk mendukung aplikasi database. Pemilihan DBMS amatlah diperlukan ketika sebuah perusahaan ingin mengembangkan atau mengganti sistem yang sudah ada, proses ini digunakan untuk mengevaluasi produk DBMS. Tujuan dari pemilihan DBMS adalah untuk memilih sebuah sistem yang sesuai dengan kebutuhan saat ini dan yang akan datang pada perusahaan, menyeimbangkan biaya pembelian produk DBMS, berbagai software/hardware tambahan yang diperlukan untuk mendukung sistem database, dan biaya yang berhubungan dengan perubahan dan pelatihan staf.
Berikut adalah langkah-langkah untuk memilih DBMS yang baik : 1. Menjelaskan istilah referensi pembelajaran
2. Mendaftarkan dua atau tiga produk 3. Mengevaluasi produk
4. Merekomendasikan pilihan dan membuat laporan
2.2.14.6 Perancangan Aplikasi
Menurut Connolly dan Begg (2002,p287), rancangan aplikasi yaitu perancangan antarmuka pengguna dan program aplikasi yang digunakan dan memproses database. Aktivitas antara database design dengan application design terjadi secara paralel. Dalam banyak hal, tidak mungkin untuk menyelesaikan perancangan aplikasi sampai
perancangan dari database itu sendiri. Dalam hal ini, database hadir untuk mendukung aplikasi dan harus ada aliran informasi antara application design dan database design. Seluruh fungsi – fungsi yang tercantum dalam spesifikasi kebutuhan pengguna harus ada dalam perancangan aplikasi, untuk aplikasi database yang meliputi perancangan program aplikasi yang mengakses basis data dan melakukan transaksi. Perancangan user interface yang tepat ke dalam aplikasi database menjadi kebutuhan tambahan agar fungsi yang dibutuhkan tercapai. Perancangan user interface kadang – kadang tidak diperhatikan atau ditinggalkan selama tahapan perancangan. Program aplikasi yang mudah dipelajari, sederhana dalam penggunaan, maka pengguna cenderung untuk dapat memanfaatkan dengan baik. Hal ini menunjukkan bahwa user interface merupakan salah satu komponen penting dari sistem.
Terdapat dua aspek penting dalam perancangan aplikasi yaitu: 2.2.14.6.1 Perancangan Transaksi
Menurut Connolly dan Begg (2002,p288), transaksi merupakan sederetan tindakan yang dilakukan oleh pengguna tunggal atau program aplikasi yang mengakses atau mengubah isi
database. Transaksi menggambarkan kejadian dunia nyata seperti pendaftaran, penambahan anggota baru, penambahan pelanggan baru dsb. Transaksi digunakan untuk database untuk memastikan bahwa data yang terdapat dalam database sesuai dengan situasi dunia nyata dan mendukung kebutuhan informasi pengguna.
Tujuan dari perancangan transaksi untuk mendefinisikan dan mendokumentasikan karakteristik transaksi tingkat tinggi yang diperlukan pada database yaitu :
1. Data yang digunakan oleh transaksi 2. Karakteristik fungsional dari transaksi 3. Hasil transaksi
4. Kepentingan terhadap pengguna 5. Nilai harapan penggunaan
Terdapat tiga jenis utama transaksi yaitu :
- Retrieval transaction : Digunakan untuk mengambil data untuk ditampilkan pada layar atau di dalam hasil laporan
- Update transaction : Digunakan untuk memasukkan record baru, menghapus record lama, atau memodifikasi record yang ada di dalam database
- Mixed transaction : Melibatkan pengambilan dan peng-updatean data
2.2.14.6.2 Perancangan User Interface
Menurut Connolly dan Begg (2002,p289), terdapat beberapa langkah dalam membuat rancangan antarmuka yang baik bagi aplikasi database yaitu :
1. Judul yang berarti
2. Instruksi yang komprehensif
3. Rancangan permintaan secara visual dari laporan 4. Label field yang dikenal
5. Singkatan dan istilah yang konsisten 6. Penggunaan warna yang konsisten
7. Batasan dan ruang yang terlihat bagi field data-entry 8. Pergerakkan kursor yang baik
9. Perbaikkan kesalahan bagi karakter individu dan keseluruhan field 10. Pesan kesalahan bagi nilai yang tak sesuai
11. Penandaan field opsional yang jelas 12. Pesan penjelasan bagi field
13. Sinyal penyelesaian
2.2.14.7 Implementasi
Menurut Connolly dan Begg (2002,p292), implementasi adalah realisasi fisik dari rancangan aplikasi dan database. Implementasi database dicapai dengan menggunakan DDL dari DBMS yang dipilih atau GUI yang menyediakan fungsi yang sama selama penyembunyian statement DDL tingkat rendah. DDL digunakan untuk membuat struktur database dan file database kosong.
Program aplikasi diterapkan menggunakan bahasa tingkat tiga atau empat. Bagian dari program aplikasi ini adalah transaksi database, yang diterapkan menggunakan DML yang dapat dijalankan pada sekumpulan bahasa pemrograman, seperti Visual Basic, Delphi, C, C++, Java, COBOL, Fortran, Ada atau Pascal. Digunakan juga komponen lain dari perancangan aplikasi seperti menu layar, form masukkan data dan laporan – laporan. Keamanan dan integritas dalam aplikasi juga diterapkan.
2.2.14.8 Pengubahan dan Peng-load-an Data
Menurut Connolly dan Begg (2002), pengubahan dan pengloadan data adalah pentransferan berbagai data yang ada ke dalam database yang baru dan pengubahan berbagai aplikasi yang ada untuk berjalan pada database yang baru. Tahapan ini dibutuhkan hanya ketika sistem database yang baru menggantikan sistem yang lama. Sekarang ini, sudah menjadi hal yang biasa bagi sebuah DBMS untuk mempunyai utilitas yang dapat memuat keseluruhan file yang ada ke dalam database yang baru. Utilitas biasanya membutuhkan spesifikasi dari sumber dan tujuannya, sehingga mengubah data sesuai dengan format basis data yang baru.
2.2.14.9 Pengujian
Menurut Connolly dan Begg (2002,p292), pengujian adalah sebuah proses pengeksekusian program aplikasi dengan maksud menemukan kesalahan. Hal ini dicapai dengan strategi pengujian terencana yang hati-hati dan data yang nyata sehingga proses pengujian seluruhnya ditangani dengan metodologis dan benar. Jika proses pengujian berjalan dengan baik, hal ini akan menemukan banyak kesalahan dalam program aplikasi dan struktur database. Pengujian juga menunjukkan agar aplikasi database bekerja sesuai dengan spesifikasi dan kebutuhan performa yang diinginkan. Hasil dari pengujian dapat memberikan penilaian terhadap kehandalan dan kualitas software.
2.2.14.10 Pemeliharaan Operasional
Menurut Connolly dan Begg (2002,p293), pemeliharaan operasioanal adalah sebuah proses pemantauan dan pemeliharaan sistem berikut instalasi.
Dalam tahap ini melibatkan dua aktifitas yaitu :
1. Pemantauan performa sistem. Jika performa berada jauh dibawah level yang diharapkan, diperlukan perbaikkan atau penyusunan kembali database
2. Pemeliharaan dan peng-upgrade-an aplikasi database. Kebutuhan baru dimasukkan ke dalam aplikasi database melalui tahap-tahap siklus hidup aplikasi database yang sebelumnya.
2.2.15 Website
Untuk membangun sebuah web page atau membuat website dibutuhkan sebuah bahasa pemrograman yang dikenal dengan sebutan web scripting. Dikatakan script karena perintah kode program tersebut di-interpreter dan tidak ada kompilasi untuk menjadikan file exe (executable).
2.2.15.1 Web Scripting
Berdasarkan letak prosesinterpreter maka web scripting dibagi menjadi dua kategori yaitu :
1. Client Side
2. Server Side
Client Side dilakukan oleh web browser seperti Internet
Explorer, Netscape,Opera, Firefox, Safari dan browser-brewser lainnya. Untuk contoh bahasa client side adalah HTML, CSS, javascript, VBscript, dan xml.
Sedangkan untuk Server Side dilakukan oleh web server seperti PWS(Personal Web Server untuk Sistem Operasi 98), IIS, Apache, Tomcat, Xitamidan JOPE. Untuk Contoh bahasa server side adalah ASP(.Net), PHP, JSP, CFMdan CGI/PL
2.2.15.2 Perancangan Website
Mengingat satu-satunya cara pengguna dapat berkomunikasi dengan aplikasi web Anda melalui antarmuka, desain antarmuka kemudian harus menjadi salah satu bagian terpenting dari aplikasi manapun. Antarmuka yang baik akan meningkatkan pengalaman, kegunaan, efektivitas atau bahkan keberhasilan sistem anda. Dari buku Merancang Antarmuka Pengguna ada 8 aturan untuk membimbing kita untuk desain interaksi yang baik.
1. Berusaha untuk konsistensi.
Konsisten urutan tindakan harus diminta dalam situasi yang mirip; identik terminologi yang harus digunakan untuk prompt, menu, dan membantu layar; dan perintah konsisten harus diterapkan di seluruh.
2. Aktifkan pengguna yang sering menggunakan cara pintas.
Sebagai frekuensi penggunaan meningkat, begitu juga keinginan pengguna untuk mengurangi jumlah interaksi dan untuk meningkatkan kecepatan interaksi. Singkatan, tombol fungsi, perintah tersembunyi, dan fasilitas makro sangat membantu untuk pengguna ahli.
3. Penawaran informatif umpan balik.
Untuk setiap tindakan operator, harus ada sistem umpan balik. Untuk sering dan tindakan kecil, dapat respons sederhana, sedangkan untuk jarang dan tindakan-tindakan besar, respons harus lebih besar.
4. Desain dialog untuk menghasilkan penutupan.
Urutan tindakan harus diatur dalam kelompok-kelompok yang memiliki awal, tengah, dan akhir.Umpan balik yang informatif pada penyelesaian tindakan sekelompok operator memberikan kepuasan prestasi, rasa lega, sinyal untuk menurunkan rencana kontingensi dan pilihan dari pikiran mereka, dan suatu indikasi bahwa cara yang jelas untuk mempersiapkan kelompok berikutnya tindakan.
5. Tawarkan penanganan kesalahan yang sederhana.
Sebanyak mungkin, desain sistem sehingga pengguna tidak dapat membuat kesalahan yang serius. Jika melakukan kesalahan, sistem harus mampu
