BAB 2 LANDASAN TEORI

Transkripsi

1 BAB 2 LANDASAN TEORI 2.1 Teori Basis Data Pengertian Basis Data Basis data adalah suatu kumpulan data yang terhubung secara logikal satu satu sama lain dan deskripsi dari suatu data yang dirancang sebagai suatu informasi yang dibutuhkan oleh suatu organisasi (Connolly, 2005, p15). Menurut Mannino (2001, p4), basis data merupakan kumpulan dari data-data yang persisten yang dapat dishare dan saling berhubungan. a. Persisten berarti data tersebut tersimpan pada penyimpanan yang stabil dan tetap, seperti magnetic disk (harddisk, cd, dll). b. Shared berarti basis data memiliki banyak kegunaan dan banyak pengguna. Sistem basis data menyediakan penyimpanan secara umum untuk berbagai fungsi pada suatu organisasi. c. Saling berhubungan berarti data yang disimpan pada unit yang berbeda dapat saling dikaitkan untuk menyediakan gambaran seluruhnya. Sedangkan menurut Turban (2005, p37), basis data merupakan kumpulan file atau record yang terorganisir yang menyimpan data beserta relasi diantara data tersebut. Basis data merepresentasikan entitas, atribut dan hubungan relasional antara entitas-entitas. Dengan kata lain basis data menyimpan data yang 6

2 7 terhubung secara logikal. Sistem basis data tidak hanya menyimpan data operasional dari suatu organisasi tetapi juga penjelasan dari data-data tersebut. Basis data juga dikenal sebagai self-describing collection of integrated records, maksudnya adalah basis data tersebut menyediakan data yang independen. Penjelasan dari data tersebut biasa dikenal sebagai sistem katalog atau kamus data atau metadata. Menurut Date (2002, p11), entitas adalah suatu objek yang nyata seperti orang, tempat, benda, konsep atau kejadian pada suatu organisasi yang direpresentasikan dalam basis data. Atribut adalah sebuah properti yang menjelaskan banyak aspek dari objek yang akan disimpan. Relasi adalah asosiasi diantara entitas-entitas dalam sebuah basis data. Istilah-istilah penting yang berhubungan dengan basis data : a. Relasi : tabel dengan kolom dan baris. b. Atribut : kolom dari suatu relasi yang diberi nama. c. Domain : kumpulan dari nilai-nilai yang diperkenankan untuk satu atau lebih atribut. d. Tuple : baris dalam suatu relasi e. Cardinality : jumlah tuple pada suatu relasi f. Relational Database : kumpuan dari relasi-relasi yang sudah dinormalisasi dengan nama relasi yang berbeda. g. Candidate key : calon key dalam suatu relasi. h. Primary key : candidate key yang dipilih untuk menentukan tuple secara unik dalam suatu relasi.

3 8 i. Foreign key : atribut atau kumpulan atribut dalam suatu relasi yang sesuai dengan candidate key dari beberapa relasi. j. Composite key : candidate key yang terdiri dari dua atau lebih atribut Database Management System (DBMS) Database Management System (DBMS) adalah sebuah sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, mengatur, dan mengontrol akses ke suatu basis data (Connolly, 2005, p16). Sedangkan menurut Mannino (2001, p7), DBMS adalah kumpulan dari perangkat lunak yang mendukung pembuatan, penggunaan dan perawatan dari basis data. Komponen DBMS (Connolly, 2005, p18) : a. Hardware (perangkat keras) DBMS dan aplikasinya memerlukan hardware untuk beroperasi. Hardware tersebut dapat berupa personal komputer, mainframe, atau komputer dalam jaringan. b. Software (perangkat lunak) Terdiri dari aplikasi DBMS itu sendiri dan aplikasi lainnya, serta sistem informasi yang digunakan termasuk software jaringan jika DBMS digunakan melalui suatu jaringan. c. Data Berperan sebagai jembatan antara komponen mesin dan komponen manusia.

4 9 d. Procedures Berupa instruksi-instruksi, peraturan perancangan dan penggunaan basis data. Langkah-langkah instruksinya adalah sebagai berikut : 1. Memasuki DBMS 2. Menggunakan suatu fasilitas DBMS atau program aplikasi lainnya. 3. Menjalankan dan menghentikan DBMS 4. Membuat duplikat basis data sebagai backup 5. Menangani kesalahan hardware atau software 6. Mengubah struktur tabel e. Human Terdiri dari database administrator, database designer, application developer, dan end user. Database administrator bertanggung jawab atas realisasi fisik basis data, termasuk perancangan basis data dan implementasi, keamanan dan kontrol integritas, perawatan sistem operasional, dan meyakinkan bahwa kinerja aplikasi memuaskan pengguna. Fungsi dari DBMS (Connolly, 2005, p48) : a. Data storage, retrieval dan update Sebuah DBMS harus menyediakan fasilitas kepada pengguna untuk menyimpan, mengambil dan meng-update data di sebuah basis data. b. User-accessible catalog Sebuah DBMS harus menyediakan katalog yang berisi penjelasan dari data items yang tersimpan pada basis data.

5 10 c. Transaction support Sebuah DBMS menyediakan mekanisme yang memastikan bahwa update pada suatu transaksi terjadi seluruhnya atau tidak terjadi sama sekali. d. Concurrency control service Sebuah DBMS harus menyediakan mekanisme yang memastikan basis data diupdate secara benar ketika multiple user meng-update basis data secara bersamaan. e. Recovery service DBMS harus menyediakan mekanisme untuk mengembalikan suatu basis data pada keadaan dimana basis data belum terjadi kerusakan. f. Authorization service DBMS harus menyiapkan mekanisme dimana hanya pengguna tertentu yang dapat mengakses basis data. g. Support for data communication Sebuah DBMS harus mampu berintegrasi dengan perangkat lunak komunikasi. h. Integrity service Sebuah DBMS harus menyediakan aturan bahwa data dalam basis data dan perubahannya harus mengikuti aturan tertentu. i. Service to promote data independence DBMS harus mengikutsertakan fasilitas untuk mendukung program independen dari struktur basis data.

6 11 j. Utility Service DBMS harus menyediakan layanan utilitas lainnya, contohnya adalah fasilitas impor, fasilitas monitoring, analisis statistik, indexing, serta garbage collection dan reallocation. Keuntungan DBMS (Connolly, 2005, p26) : a. Mengontrol redundansi data. b. Konsistensi data. c. Banyak informasi diperoleh dari sumber yang sama. d. Mampu men-share data. e. Meningkatkan integritas data. f. Meningkatkan keamanan. g. Meningkatkan standar. h. Bila DBMS sudah berjalan dengan baik dapat menekan total pengeluaran organisasi. i. Dapat menyeimbangkan perbedaan kebutuhan. j. Meningkatkan kemampuan akses dan respon data. k. Meningkatkan produktivitas. l. Meningkatkan pemeliharaan dengan data independence. m. Meningkatkan concurrency data. n. Meningkatkan backup dan recovery services. Kerugian DBMS (Connolly, 2005, p29) : a. Kompleks. b. Memerlukan ukuran perangkat lunak yang besar. c. Biaya untuk menghasilkan DBMS yang baik sangat mahal.

7 12 d. Pengeluaran untuk perangkat keras tambahan. e. Biaya untuk konversi sistem dari sistem yang lama ke sistem yang baru. f. Performa sistem dapat tidak sesuai dengan keinginan. g. Menimbulkan pengaruh yang besar pada perusahaan jika terjadi kegagalan pada sistem. Pemilihan DBMS dapat dilakukan berdasarkan pada analisis kelayakan (feasibility analysis) (Whitten, 2004, p404). Analisis kelayakan ini terbagi atas empat hal, yaitu : a. Kelayakan operasional (Operational Feasibility) Merupakan ukuran sejauh mana solusi dapat berguna bagi perusahaan dan juga mengukur bagaimana penerimaan orang-orang terhadap solusi itu. Kelayakan operasional berorientasi pada orang. b. Kelayakan teknis (Technical Feasibility) Mengukur seberapa praktis solusi teknis, ketersediaan sumber daya teknis dan keahlian yang dibutuhkan serta berorientasi pada komputer. c. Kelayakan jadwal (Schedule Feasibility) Merupakan ukuran yang menyatakan seberapa masuk akal tenggat waktu proyek dan menentukan apakah waktu yang dialokasikan untuk sebuah proyek akurat. d. Kelayakan ekonomis (Economic Feasibility) Mengukur efektivitas biaya dari suatu proyek atau solusi. Kelayakan ekonomis berhubungan dengan biaya dan manfaat yang diperoleh dari sistem informasi. Garis dasar kebanyakan proyek adalah kelayakan ekonomis.

8 Data Definition Language (DDL) Data Definition Language (DDL) adalah suatu bahasa yang memungkinkan Database Administrator (DBA) atau pengguna untuk mendeskripsikan dan memberi nama entitas, atribut, dan relasi yang dibutuhkan untuk aplikasi, bersamaan dengan integritas data dan batasan keamanan datanya (Connolly, 2005, p40). DDL digunakan untuk mendefinisikan skema atau untuk memodifikasi skema yang telah ada, tetapi DDL tidak bisa digunakan untuk memanipulasi data. Hasil dari kompilasi DDL adalah kumpulan tabel yang disimpan dalam file khusus yang disebut Data Dictionary (kamus data). Kamus data merupakan suatu metadata yaitu suatu data yang mendeskripsikan atau mewakili data yang sesungguhnya Data Manipulation Language (DML) Menurut Connolly (2005, p40), Data Manipulation Language (DML) merupakan suatu bahasa yang menyediakan sebuah set operasi untuk mendukung operasi dasar memanipulasi data dalam data yang tersimpan di basis data. Operasi manipulasi data biasanya mencakup hal-hal berikut ini : a. Memasukkan data baru ke dalam basis data (Insertion). b. Modifikasi data yang tersimpan dalam basis data (Modify). c. Mengambil data yang tersimpan di dalam basis data (Retrieve). d. Menghapus data dari dalam basis data (Delete). Menurut Connolly (2005, p41), DML dapat dibedakan menjadi dua tipe, yaitu :

9 14 a. Procedural DML Merupakan suatu bahasa yang memungkinkan pengguna untuk memberi informasi kepada sistem tentang data apa yang dibutuhkan dan bagaimana menampilkan data tersebut secara benar. b. Non-procedural DML Merupakan suatu bahasa yang memungkinkan pengguna untuk menentukan data apa yang dibutuhkan daripada bagaimana data itu ditampilkan Normalisasi Normalisasi adalah suatu proses formal untuk memutuskan atributatribut yang seharusnya dikelompokkan bersama dalam sebuah relasi (Hoffer, 2002, p189), sedangkan menurut Connolly (2005, p388) normalisasi adalah sebuah teknik untuk menghasilkan sebuah set relasi dengan menggunakan data yang ada pada perusahaan. Tujuan normalisasi adalah mengidentifikasi sebuah set relasi yang benar untuk mendukung kebutuhan data dari sebuah perusahaan. Karakteristik dari set relasi yang benar mencakup: a. Jumlah minimal dari atribut yang diperlukan untuk mendukung kebutuhan data dari perusahaan b. Atribut relasi logikal yang dekat (dikenal sebagai function dependency) ditemukan dalam relasi yang sama. c. Redundansi minimal

10 15 Keuntungan menggunakan basis data yang memiliki set relasi yang benar, bahwa basis data tersebut akan lebih mudah bagi pengguna untuk mengakses dan memelihara data, serta meminimalisasi penggunaan tempat penyimpanan pada komputer. Gambar Bagaimana normalisasi dapat digunakan untuk mendukung desain basis data (Connolly, 2005, p389) Normalisasi merupakan teknik bottom-up yang mengambil informasi mengenai atribut dari contoh forms yang pertama kali ditransformasikan ke dalam bentuk tabel. Tabel yang belum dinormalisasi dinamakan Unnormalized Form (UNF). Menurut Connolly (2005, p403) UNF adalah suatu tabel yang berisi satu atau lebih grup yang berulang. Bentuk-bentuk normalisasi antara lain :

11 16 a. First Normal Form (1NF) First Normal Form merupakan suatu relasi dimana pertemuan antar setiap baris dan kolom yang mengandung satu dan hanya satu nilai (Connolly, 2005, p403). Untuk mengubah UNF menjadi 1NF yang diperlukan adalah mengidentifikasi dan menghilangkan grup yang berulang antar tabel. b. Second Normal Form (2NF) Second Normal Form adalah relasi pada 1NF dan setiap atribut non primary key tergantung secara fungsional kepada primary key (Connolly, 2005, p407). Normalisasi dari 1NF ke 2NF melibatkan penghilangan partial dependency. Apabila terdapat partial dependency, maka dilakukan penghilangan atribut yang partially dependent dari relasi dengan meletakkan relasi yang baru bersama dengan duplikat determinannya. c. Third Normal Form (3NF) Third Normal Form adalah relasi yang ada pada 1NF dan 2NF dan tidak ada atribut non primary key yang transitively dependent kepada primary key (Connolly, 2005, p409). Normalisasi dari 2NF ke 3NF melibatkan penghilangan ketergantungan transitif tersebut dari relasi dengan meletakkan atribut di suatu relasi yang baru bersama dengan duplikat determinannya.

12 17 Gambar Diagram ilustrasi dari proses normalisasi. (Connolly, 2005, p402) Fourth Generation Language (4GL) Dibandingkan dengan Third Generation Languages (3GL) yang merupakan bahasa prosedural, 4GL merupakan bahasa yang non prosedural, pengguna mendefinisikan apa yang harus dilakukan dan bukan

13 18 bagaimana melakukannya. Pengguna tidak perlu mendefinisikan langkahlangkah yang dilakukan program untuk menyelesaikan suatu tugas-tugas, tetapi hanya perlu mendefinisikan parameter untuk alat dan menggunakannya untuk menghasilkan program aplikasi. 4GL memiliki : a. Presentation Languages b. Speciality Languages c. Generator Application yang mendefinisikan, memasukkan, mengubah, dan mengambil data dari basis data ke dalam aplikasi. d. Bahasa tingkat tinggi yang digunakan untuk menghasilkan kode aplikasi Siklus Hidup Aplikasi Basis Data Sistem basis data merupakan komponen penting dari sistem informasi suatu organisasi atau perusahaan, siklus hidup aplikasi basis data (SDLC The Database System Development Lifecycle) terhubung dengan siklus hidup sistem informasi.

14 19 Gambar 2.3 Siklus hidup aplikasi basis data (Connolly, 2005, p284) Database Planning (Perancangan Basis Data) Database planning merupakan aktivitas manajemen yang memungkinkan tahapan dari Siklus Hidup Aplikasi Basis Data

15 20 dapat direalisasikan seefisien dan seefektif mungkin. Database planning harus diintegrasikan dengan strategi IS secara keseluruhan dari organisasi. Ada tiga isu-isu penting terkait dalam menyusun strategi IS, yaitu : a. Identifikasi dari rencana dan tujuan enterprise dengan determinasi subquent dari kebutuhan sistem informasi. b. Evaluasi dari sistem informasi yang ada untuk menentukan kekuatan dan kelemahan yang ada. c. Berharap dengan IT dapat mengambil keuntungan dalam persaingan dengan perusahaan lain. Langkah pertama yang paling penting pada perencanaan basis data adalah untuk menentukan mission statement untuk sistem basis data. Mission statement mendefinisikan tujuan utama dari sistem basis data. Mission statement membantu menjelaskan kegunaan dari sistem basis data dan menyediakan alur yang lebih jelas untuk mencapai efektivitas dan efisiensi penciptaan dari suatu basis data yang diinginkan System Definition (Definisi Sistem) System Definition mendeskripsikan ruang lingkup dan batasan dari aplikasi basis data dan gambaran pengguna utama. User view mendefinisikan kebutuhan sistem basis data perspektif berbagai macam job rule (seperti Manager, Supervisor) atau bagian enterprise lainnya (seperti Marketing, Personnel, atau Stock

16 21 Control). User view menjelaskan apa yang dibutuhkan dari aplikasi basis data dalam kondisi data yang akan disimpan dan transaksi yang akan dilakukan Requirement Collection and Analysis (Pengumpulan Kebutuhan dan Analisis) Requirement Collection and Analysis merupakan proses pengumpulan dan analisis informasi suatu organisasi yang dibutuhkan sistem basis data, dan menggunakan informasi tersebut untuk mengidentifikasi kebutuhan sistem yang baru. Ada banyak teknik yang dipakai untuk mendapatkan informasi, disebut Fact-finding Technique. Informasi yang diambil dari user view meliputi : a. Penjelasan dari data yang digunakan atau yang dihasilkan. b. Detail dari bagaimana data tersebut digunakan atau dihasilkan. c. Kebutuhan tambahan lainnya untuk aplikasi basis data baru. Ada tiga pendekatan untuk mengetahui kebutuhan dari aplikasi basis data dengan multiple user view (Connolly, 2005, p289) : a. Centralized approach Kebutuhan dari tiap user view digabungkan menjadi sebuah set kebutuhan tunggal untuk sistem basis data yang baru. Model data yang merepresentasikan semua user view dibuat pada tahapan merancang basis data. Pendekatan ini digunakan ketika terjadi overlap yang signifikan pada kebutuhan dari

17 masing-masing user view dan sistem basis data yang ada tidak terlalu kompleks. 22 Gambar 2.4 Centralized approach untuk menangani multiple user view (Connolly, 2005, p289) b. View integration approach Kebutuhan untuk setiap user view tetap pada daftar yang terpisah. Model-model data yang merepresentasikan setiap user view dibuat dan kemudian digabungkan pada saat tahapan merancang basis data. Secara umum, pendekatan ini digunakan pada saat terjadinya perbedaan yang signifikan antara user views dengan sistem basis data yang cukup sulit untuk dibagi-bagi kedalam beberapa bagian yang dapat diatur.

18 23 Gambar 2.5 View integration approach untuk menangani multiple user view (Connolly, 2005, p290) c. Kombinasi keduanya Untuk sistem basis data yang sangat kompleks mungkin sangat tepat untuk menggunakan kombinasi dari kedua pendekatan diatas untuk menangani multiple user views. Sebagai contoh, kebutuhan untuk dua atau lebih user views dapat digabungkan menjadi satu menggunakan centralized approach, yang nantinya akan menghasilkan model data lokal logikal. Kemudian model data ini dapat digabungkan dengan model data lokal logikal lainnya menggunakan view integration approach untuk mendapatkan model data global logikal.

19 Database Design (Perancangan Basis Data) Database Design merupakan proses pembuatan desain yang akan mendukung mission statement dan mission objecive untuk sistem basis data yang dibutuhkan. Ada dua pendekatan utama untuk proses desain basis data, yaitu bottom-up dan top-down. Pendekatan bottom-up dimulai dari level fundamental dari atribut (yaitu properti dari entitas dan relasi), yang kemudian dianalisis relasi diantara atribut-atribut tersebut, dan dikelompokan menjadi relasi yang mewakili entitas dan relasi diantara entitas tersebut. Pendekatan ini lebih cocok untuk rancangan basis data yang sederhana dengan tidak banyak relasi diantara atributnya. Sedangkan pendekatan top-down dimulai dari pengembangan data model yang berisi beberapa entitas tingkat atas dan relasinya dan kemudian mengidentifikasi entitas dibawahnya, relasi, dan asosiasi dari atribut-atributnya. Pendekatan ini diilustrasikan menggunakan konsep dari Entity Relationship (ER) model, dimulai dari mengidentifikasi entitas dan relasi diantara entitas tersebut, yang merupakan bagian dari organisasi. Selain dua pendekatan diatas, ada juga pendekatan lain yaitu inside-out approach dan mixed strategy approach. Database Design ini terdiri dari 3 fase, yaitu :

20 25 a. Conceptual Database Design Proses membangun model informasi yang digunakan suatu organisasi, terlepas dari segala pertimbangan fisiknya. Pada fase ini dibuat model data konseptual. b. Logical Database Design Proses membangun model informasi yang digunakan suatu organisasi berdasarkan model data tertentu, tetapi masih terlepas dari pertimbangan DBMS tertentu dan pertimbangan fisikal lainnya. c. Physical Database Design Proses menghasilkan deskripsi dari implementasi basis data pada secondary storage; dimana proses tersebut mendeskripsikan relasi dasar, organisasi file, dan indeks yang digunakan untuk memudahkan akses data secara efisien, dan segala integrity constraints dan keamanannya DBMS Selection (Pemilihan DBMS) Memilih DBMS yang sesuai untuk sistem basis data yang dibuat untuk mendukung aplikasi basis data. Langkah-langkah untuk memilih DBMS : a. Menjelaskan ruang lingkup tujuan yang akan dipelajari. b. Mendaftarkan dua atau tiga produk yang akan digunakan c. Mengevaluasi produk. d. Merekomendasikan pilihan dan menghasilkan laporan.

21 Application Design (Perancangan Aplikasi) Application design merupakan perancangan user interface dan program aplikasi yang memproses dan menggunakan basis data (Connolly, 2005, p299). Dapat dilihat dari Gambar 2.3 antara perancangan aplikasi dengan perancangan basis data terhubung secara paralel. Dengan kata lain basis data ada untuk mendukung aplikasi, dan aplikasi digunakan sebagai jembatan kepada pengguna. Jadi, harus ada arus informasi antara perancangan aplikasi dan perancangan basis data. Menurut Connolly (2005, p300), perancangan aplikasi meliputi 2 (dua) aspek, yaitu : a. Transaction design (desain transaksi) Tujuan dari desain transaksi adalah untuk menjelaskan dan mendokumentasikan high-level characteristic dari transaksi yang dibutuhkan dalam basis data, yang meliputi : 1. Data yang akan digunakan oleh transaksi 2. Karakteristik fungsional 3. Keluaran dan transaksi 4. Tingkat kegunaan yang diharapkan 5. Kepentingan untuk pengguna Ada 3 (tiga) jenis transaksi, yaitu : 1. Retrieval transaction Transaksi yang digunakan untuk mengambil data untuk ditampilkan di layar atau untuk laporan.

22 27 2. Update transaction Transaksi yang digunakan untuk memasukkan data baru, menghapus data lama, atau memodifikasi data yang sudah ada. 3. Mixed transaction Transaksi yang meliputi kedua transaksi diatas. b. User Interface Design (Perancangan antarmuka) Sebelum mengimplementasikan sebuah form atau report (laporan), sangat penting untuk merancang tampilan antarmuka pengguna. Menurut Connolly (2005, p301), berikut adalah panduan untuk merancang antarmuka pengguna: 1. Menentukan judul 2. Instruksi yang jelas 3. Pengelompokkan logikal dan field yang berurutan 4. Menampilkan laporan / form secara visual 5. Tabel field yang umum 6. Terminologi dan singkatan yang konsisten 7. Konsistensi penggunaan warna 8. Ruang dan batasan yang terlihat untuk inputan data 9. Pergerakan kursor yang nyaman 10. Penanganan kesalahan untuk karakter individual dan keseluruhan field 11. Pesan kesalahan untuk data yang tidak diterima 12. Pilihan opsional ditandai dengan jelas

23 Penjelasan untuk field 14. Tanda kelengkapan Prototyping (Bentuk Dasar) Membangun model kerja dari sistem basis data. Prototype merupakan suatu model kerja yang tidak memiliki fitur-fitur atau fungsional dari sistem final (Connolly, 2005, p304). Tujuan utama dari mengembangkan prototype aplikasi basis data adalah memungkinkan pengguna untuk menggunakan prototype untuk mengidentifikasikan fitur-fitur dari sistem yang bekerja dengan baik, atau belum ada, dan jika memungkinkan untuk memberi saran pengembangan atau fitur-fitur baru untuk aplikasi basis data. Ada 2 (dua) strategi prototyping yang biasa digunakan, yaitu requirement prototyping dan evolutionary prototyping. Requirement prototyping menggunakan prototype untuk menentukan kebutuhan-kebutuhan dari sistem basis data yang diajukan, dan sekali kebutuhan tersebut terpenuhi, prototype tersebut ditinggalkan. Sedangkan evolutionary prototyping digunakan untuk tujuan yang sama, yang berbeda adalah prototype tersebut tidak ditinggalkan, tetapi dengan pengembangan lebih jauh akan menjadi sistem basis data yang berjalan.

24 Implementation (Implementasi) Menurut Connolly (2005, p304), implementasi merupakan realisasi dari perancangan aplikasi dan basis data. Implementasi basis data didapatkan dengan menggunakan Data Definition Language (DDL) dari DBMS yang dipilih atau Graphical User Interface (GUI). Perintah DDL digunakan untuk membuat struktur basis data dan file basis data kosong. Semua user view yang telah dispesifikasi, keamanan, dan kontrol integritas untuk aplikasi juga diimplementasi pada tahap ini Data Convertion And Loading (Perubahan dan Pengambilan Data) Menurut Connolly (2005, p305), perubahan dan pengambilan data adalah pemindahan data yang ada ke dalam basis data yang baru dan mengkonversi aplikasi yang ada untuk menjalankan basis data yang baru. Tahap ini hanya dilakukan ketika sistem basis data yang baru menggantikan sistem yang lama Testing (Pengetesan) Menurut Connolly (2005, p305), testing adalah proses menjalankan sistem basis data yang baru dengan tujuan untuk menemukan kesalahan. Sebelum sistem diterapkan, aplikasi basis data baru yang telah dikembangkan harus diuji terlebih dahulu. Pengujian ini dilakukan melalui strategi uji yang telah direncanakan dengan sebaik-baiknya dan dengan menggunakan

25 30 data yang realistik sehingga keseluruhan proses pengujian dilaksanakan berdasarkan metode yang tepat. Pengguna dari sistem yang baru harus dilibatkan pada proses pengujian. Situasi ideal untuk menguji suatu sistem ialah dengan menguji basis data dengan sistem perangkat keras yang terpisah. Jika data yang sebenarnya akan digunakan, maka sebaiknya data tersebut di backup untuk menjaga jika ada kerusakan atau kegagalan. Setelah pengujian selesai, sistem aplikasi siap untuk diterapkan dan diberikan ke pengguna Operational Maintenance (Perawatan Operational) Operational Maintenance merupakan proses memonitor dan memelihara sistem basis data setelah instalasi (Connolly, 2005, p306). Pada tahap ini melibatkan aktifitas sebagai berikut : a. Memonitor kinerja sistem. Jika kinerja dibawah standar, pengaturan basis data mungkin diperlukan. b. Memelihara dan mengembangkan aplikasi basis data (jika dibutuhkan). Kebutuhan yang baru tidak dapat disatukan dengan aplikasi basis data tahap SDLC sebelumnya Desain Konseptual, Logikal dan Fisikal Basis Data Urutan metodologi yang ada menurut Connolly (2005, p439), yaitu :

26 31 a. Perancangan Basis Data Konseptual Perancangan basis data konseptual adalah proses membangun model informasi yang digunakan suatu organisasi, terlepas dari segala pertimbangan fisiknya. b. Perancangan Basis Data Logikal Perancangan basis data logikal adalah proses membangun model informasi yang digunakan suatu organisasi berdasarkan model data tertentu, tetapi masih terlepas dari pertimbangan DBMS tertentu dan pertimbangan fisikal lainnya. c. Perancangan Basis Data Fisikal Perancangan basis data fisikal adalah proses menghasilkan deskripsi dari implementasi basis data pada secondary storage; dimana proses tersebut mendeskripsikan relasi dasar, organisasi file, dan indeks yang digunakan untuk memudahkan akses data secara efisien, dan segala integrity constraints dan keamanannya. Berikut adalah keseluruhan langkah-langkah dalam membangun model data konseptual, logikal, dan fisikal (Connolly, 2005, p440), yaitu: Langkah 1 : Membangun model data konseptual 1. Identifikasi tipe entitas Tujuannya adalah untuk mengidentifikasi tipe-tipe entitas yang diperlukan. Satu metode untuk mengidentifikasi entitas adalah dengan memeriksa spesifikasi kebutuhan pengguna. Dari spesifikasi ini, dapat diidentifikasi kata benda atau frase kata benda, seperti staff number, staff name, property number, property address, dll. Objek-objek yang

27 32 umum juga dapat dilihat untuk menentukan entitas seperti people, places, atau concept of interest. Sebagai contoh, staff number dan staff name dapat dijadikan entitas dengan nama Staff. 2. Identifikasi tipe relasi Tujuannya adalah untuk mengidentifikasi relasi yang penting diantara berbagai tipe entitas yang ada. Metode yang digunakan untuk menentukan relasi adalah dengan melihat verbs (kata kerja) yang ada. Sebagai contoh : Staff managed propertyforrent privateowner owns propertyforrent propertyforrent assosiatedwith Lease Gambar Contoh entitas dan relasinya 3. Identifikasi dan mengasosiasikan atribut dengan entitas atau tipe relasi Tujuannya adalah untuk mengasosiakan atribut-atribut dengan entitas atau tipe relasi yang tepat. Contohnya, pada atribut address dapat menyimpan data yang simpel atau detail yang mempunyai nilai tunggal seperti '115 Dumbarton Road, Glasgow, G11 6YG'. Nilai tunggal ini juga bisa dipisah-pisah yang terdiri dari beberapa atribut street ('115 Dumbarton Road'), city ('Glasgow') dan postcode ('G11 6YG'). Biasa

28 33 disebut composite attribute. Selain itu juga terdapat derived attribute yang nilainya berdasarkan dari nilai atribut lainnya. Sebagai tambahan, atribut juga dapat bernilai tunggal ataupun ganda (multi-valued attribute). 4. Menentukan domain atribut Tujuannya adalah untuk menentukan domain dari atribut yang ada di dalam model data konseptual lokal. Domain adalah kumpulan nilai dari satu atau lebih atribut yang menggambarkan nilai mereka. Sebagai contoh, dapat digambarkan domain atribut dari staff number (staffno) yaitu 5 karakter string, dengan 2 karakter pertama huruf dan 3 karakter terakhir berupa angka yang berkisar Menentukan candidate key dan primary key setiap entitas Tujuannya adalah untuk mengidentifikasi candidate key untuk setiap tipe entitas dan apabila terdapat lebih dari satu candidate key, maka pilih satu sebagai primary key dan lainnya sebagai alternate key. 6. Mempertimbangkan kegunaan konsep enhance modelling (optional) Tujuannya adalah untuk mempertimbangkan penggunaan konsep enhanced modelling, seperti specialization atau generalization, aggregation, dan composition. Jika memilih specialization atau generalization, maka mencoba perbedaan high-light diantara entitas dengan mendefinisikan satu atau lebih entitas subclass atau entitas superclass. Aggregation digunakan untuk merepresentasikan relasi 'has-a' atau 'part-of' diantara tipe-tipe entitas. Composition digunakan untuk merepresentasikan asosiasi diantara tipe-tipe entitas dimana

29 34 terdapat kepemilikan yang kuat dan kesamaan lifetime diantara 'whole' dan 'part'. 7. Memeriksa redundansi Tujuannya adalah untuk memeriksa keberadaan redundansi pada model data. Langkah-langkahnya adalah : Menghilangkan relasi one-to-one Menghilangkan relasi redundant 8. Memvalidasi model konseptual terhadap transaksi pengguna Tujuannya adalah untuk memastikan bahwa model konseptual mendukung untuk kebutuhan transaksi. Untuk dapat memastikan hal tersebut, dapat mendeskripsikan transaksi dan menggunakan transaction pathways. 9. Me-review model data konseptual dengan pengguna Tujuannya adalah untuk me-review model data konseptual dengan pengguna untuk memastikan bahwa mereka mempertimbangkan model sebagai objek yang sesungguhnya dari kebutuhan data perusahaan. Langkah 2 : Membangun dan memvalidasi logikal data model Tujuannya adalah untuk menterjemahkan model data konseptual ke dalam model data logikal dan kemudian memvalidasi model tersebut untuk memeriksa bahwa secara struktur sudah benar dan mampu untuk mendukung transaksi-transaksi yang dibutuhkan. 1. Menurunkan relasi untuk model data logikal Tujuannya adalah untuk menciptakan relasi model data logikal untuk merepresentasikan entitas, relasi, dan atribut yang telah diidentifikasi.

30 35 Pada tahapan ini digunakan DBDL (Database Definition Language), yang kemudian dapat menentukan relasi diantara entitas, primary key, foreign key, dan atribut turunan lainnya. Selain itu juga dikenal beberapa relasi yang mungkin terjadi, diantaranya : strong entity types weak entity types one-to-many (1:*) binary relationship types one-to-one (1:1) binary relationship types one-to-one (1:1) recursive relationship types superclass or subclass relationship types many-o-many (*:*) binary relationship types complex relationship types multi-valued attributes 2. Memvalidasi relasi dengan normalisasi Tujuannya adalah untuk memvalidasi relasi dalam model data logikal menggunakan normalisasi. Tujuan dari normalisasi adalah untuk memastikan bahwa set dari relasi mempunyai minimal dan memiliki cukup atribut yang perlu untuk mendukung kebutuhan data dari enterprise. Selain itu relasi harus memiliki redundansi data yang minimal untuk menghindari masalah dari update anomalies. 3. Memvalidasi relasi terhadap transaksi pengguna

31 36 Tujuannya adalah untuk memastikan bahwa relasi dalam model data logikal mendukung transaksi yang dibutuhkan, yang telah dijabarkan pada spesifikasi kebutuhan pengguna. 4. Mendefinisikan batasan integritas Tujuannya adalah untuk mengecek batasan integritas yang direpresentasikan pada model data logikal. Batasan integritas adalah batasan-batasan yang ingin ditunjukkan untuk melindungi basis data dari ketidaklengkapan, ketidakakuratan, ataupun ketidakkonsistenan. Tipe-tipe dari integrity constrains meliputi : required data attribute domain constraint multiplicity entity integrity referential integrity general constraints 5. Mereview model data logikal dengan pengguna Tujuannya adalah untuk mereview model data logikal dengan pengguna untuk memastikan bahwa mereka melihat model sebagai representasi sebenarnya dari kebutuhan data dari perusahaan. 6. Menggabungkan model data logikal menjadi model global (optional) Tujuannya adalah untuk menggabungkan model data lokal logikal menjadi model data global logikal tunggal yang merepresentasikan semua user views dari basis data.

32 37 7. Memeriksa untuk kemungkinan pengembangan di masa depan Tujuannya adalah untuk menentukan apakah ada perubahan yang signifikan di masa mendatang dan untuk meyakinkan apakah model data logikal dapat mengakomodasi perubahan-perubahan yang ada. Langkah 3 : Memindahkan model data logikal kepada DBMS yang dituju Tujuannya adalah untuk menghasilkan skema basis data relasional dari model data logikal yang bisa diimplementasikan pada DBMS yang dituju. Pada langkah ini meliputi 3 (tiga) aktivitas, yaitu : 1. Merancang relasi dasar Tujuannya adalah untuk memutuskan bagaimana merepresentasikan relasi basis data yang diidentifikasikan pada model data logikal dalam DBMS yang dituju. Setiap relasi yang diidentifikasi dalam model data logikal memiliki definisi sebagi berikut : Nama relasi Daftar simple attributes Primary key, alternate key (AK), dan foreign key (FK) referential integrity constraints untuk setiap foreign key yang diidentifikasi Dan untuk kamus data setiap atribut juga memiliki definisi sebagai berikut : Domain, isi dari tipe data, panjang, dan setiap constraint dalam domain Default value yang optional untuk tiap atribut

33 38 Sebuah atribut bisa berisi null Sebuah atribut diturunkan dan jika demikian bagaimana cara menghitungnya 2. Merancang representasi dari data turunan Tujuannya adalah untuk memutuskan bagaimana merepresentasikan data turunan saat ini dalam model data logikal pada DBMS yang dituju. Atribut yang isinya merupakan hasil dari operasi dari atribut lain disebut atribut turunan atau atribut hitungan. Sebagai contoh yang merupakan atribut turunan adalah : Jumlah staf yang bekerja di kantor cabang Jumlah total gaji bulanan dari seluruh staf Jumlah properti yang ditangani oleh seluruh staf Sebagaimana pada contoh poin 3, bahwa jumlah properti yang ditangani oleh seluruh staf adalah atribut turunan dimana jika salah satu staf telah melepas satu properti maka pada jumlah properti tersebut akan berkurang satu juga. 3. Merancang batasan umum Tujuannya adalah untuk merancang batasan umum untuk DBMS yang dituju. Meng-update suatu relasi yang mungkin dibatasi oleh aturan perusahaan sesuai dengan transaksi yang sebenarnya bisa di update. Perancangan batasan tersebut sekali lagi tergantung pada DBMS yang lain. Pada awalnya, jika sistem tersebut mempunyai aturan sesuai aturan standar SQL, beberapa batasan dapat diterapkan.

34 39 Langkah 4 : Merancang organisasi file dan index Tujuannya adalah untuk menentukan organisasi file optimal untuk menyimpan relasi dasar dan index yang diperlukan agar mencapai performa yang dapat diterima yaitu bagaimana jalan dari relasi dan tuple disimpan dalam secondary storage. Aktivitas dalam langkah ke-4 ini mencakup : 1. Menganalisa transaksi Tujuannya adalah untuk memahami fungsionalitas dari transaksi yang akan dijalankan oleh basis data dan menganalisis kepentingan dari transaksi tersebut. 2. Memilih organisasi file Tujuannya adalah untuk menentukan organisasi file yang efisien untuk setiap relasi dasar. 3. Memilih index Tujuannya adalah untuk menentukan jika diperlukan index tambahan yang akan meningkatkan penampilan dari sistem. 4. Memperkirakan kapasitas penyimpanan yang dibutuhkan Tujuannya adalah untuk memperkirakan besar kapasitas penyimpanan yang dibutuhkan untuk basis data. Langkah 5 : Merancang user views Tujuannya adalah untuk merancang user view sesuai yang telah diidentifikasi selama fase analisis dan pengumpulan kebutuhan dari siklus hidup aplikasi sistem basis data.

35 40 Langkah 6 : Merancang mekanisme keamanan Tujuannya adalah untuk merancang mekanisme keamanan basis data sesuai dengan spesifikasi pengguna selama fase analisis dan pengumpulan kebutuhan dari siklus hidup aplikasi sistem basis data. Secara garis besar, relational DBMS menyediakan 2 tipe keamanan basis data : 1. system security Meliputi akses dan penggunaan basis data pada level system, contohnya username dan password. 2. data security Meliputi akses dan penggunaan objek basis data (contohnya, relasi dan views) dan aksi-aksi yang dapat dilakukan oleh pengguna terhadap objek tersebut. Langkah 7 : Mempertimbangkan pengenalan kontrol redundansi Tujuannya adalah untuk menentukan apakah pengenalan redundansi pada controlled manner dengan relaxing the normalization rules akan meningkatkan performa sistem. Normalisasi merupakan suatu teknik untuk menentukan atribut-atribut mana yang akan disatukan dalam sebuah relasi. Hasil dari normalisasi tersebut adalah desain basis data logikal yang konsisten secara struktur dan memiliki redundansi yang minimal. Tetapi kadangkala, desain basis data ternormalisasi tidak menghasilkan proses maksimal yang efisien. Normalisasi tidak harus dihilangkan dari desain basis data logikal. Normalisasi memaksa untuk mengerti secara lengkap setiap atribut yang direpresentasikan dalam basis data. Faktor penting

36 41 dalam kontribusi sukses dari keseluruhan sistem. Hal-hal dibawah ini perlu dipertimbangkan : 1. denormalisasi membuat implementasi lebih kompleks. 2. denormalisasi sering menghilangkan fleksibilitas. 3. denormalisasi dapat mempercepat penerimaan atau pengambilan tetapi memperlambat update. Berikut ini adalah aktifitas dari langkah 7 (tujuh) : 1. Menggabungkan relasi one-to-one (1:1) 2. Menduplikasi atribut non-key di dalam relasi one-to-many (1:*) untuk mengurangi join. 3. Menduplikasikan atribut foreign key di dalam relasi one-to-many (1:*) untuk mengurangi join. 4. Menduplikasikan atribut di dalam relasi many-to-many (*:*) untuk mengurangi join. 5. Pengenalan grup berulang (repeating groups) 6. Pembuatan tabel ekstrak 7. Relasi partitioning Langkah 8 : Memonitor dan mengatur sistem operasional Tujuannya adalah untuk memonitor sistem operasional dan meningkatkan performa dari sistem untuk mengkoreksi keputusan desain yang tidak sesuai atau reflect kebutuhan yang berubah-ubah. Salah satu tujuan utama dari rancangan fisikal sistem basis data adalah menyimpan dan mengakses data dengan cara yang efisien. Ada beberapa faktor yang dapat digunakan untuk mengukur efisiensi tersebut :

37 42 Transaction Throughput Merupakan jumlah transaksi yang dapat diproses dalam interval waktu tertentu. Response Time Merupakan waktu yang dibutuhkan untuk menyelesaikan satu transaksi. Disk Storage Merupakan kapasitas penyimpanan yang dibutuhkan untuk menyimpan file-file basis data. Awal rancangan fisikal sistem basis data harus dipertimbangkan sebagai estimasi cara bekerja dari sistem operasi. Ketika awal rancangan telah diimplementasikan, diperlukan pengawasan sistem dan pemeliharaan keuntungan dari tuning sistem basis data : 1. Menghindarkan dari procurement tambahan perangkat keras. 2. Menghasilkan response time yang lebih cepat dan throughput yang lebih baik, yang nantinya dapat membuat pengguna dan organisasi lebih produktif. 3. Peningkatan response time dapat meningkatkan moral staf dan kepuasan pelanggan. 4. Memungkinkan downsize konfigurasi perangkat keras. Hasilnya ialah pemeliharaan perangkat keras yang lebih murah.

38 Entity Relationship (ER) Modelling Menurut Connolly dan Begg (2005, p342), Entity-Relationship Modelling (ER Modelling) adalah pendekatan top-down pada perancangan basis data, yang dimulai dengan identifikasi data yang penting, disebut juga entitas, dan relasi antar entitas yang harus direpresentasikan model Entity Type Entity type adalah sekumpulan obyek yang memiliki properti yang sama, yang diidentifikasikan di dalam organisasi karena keberadaannya yang bebas (independent existence) (Connolly, 2005, p343). Sedangkan entity occurrence adalah sebuah obyek dari satu tipe entity yang dapat diidentifikasi secara unik (Connolly, 2005, p344). Keberadaan obyek-obyeknya secara fisik atau nyata (physical existence), seperti entity Pegawai, Rumah, dan Pelanggan, atau secara konseptual atau abstrak (conceptual existence), seperti entity Inspeksi, Penjualan, dan Peninjauan. Setiap tipe entity dilambangkan dengan sebuah persegi panjang yang diberi nama dari entity tersebut. Nama tipe entity biasanya adalah kata benda tunggal. Huruf pertama dari setiap kata pada nama tipe entity ditulis dengan huruf besar. Gambar Representasi Diagramatik dari tipe Entity Pegawai dan Cabang (Connolly, 2005, p345)

39 44 Tipe entity dapat diklasifikasikan menjadi : a. Tipe entity kuat (Strong entity), yaitu tipe entity yang keberadaannya tidak bergantung pada tipe entity lainnya (Connolly, 2005, p355) b. Tipe entity lemah (Weak entity), yaitu tipe entity yang keberadaannya bergantung pada tipe entity lainnya (Connolly, 2005, p355) Gambar 2.8 Representasi diagram tipe entity kuat dan tipe entity lemah (Connolly, 2005, p355) Relationship Types Relationship type adalah sekumpulan relasi antar tipe entity yang memiliki arti (Connolly, 2005, p346). Sedangkan relatonship occurrence adalah sebuah relasi yang dapat diidentifikasikan secara unik, yang meliputi sebuah kejadian (occurrence) dari setiap tipe entity di dalam relationship (Connolly, 2005, p346). Tipe relationship digambarkan dengan sebuah garis yang menghubungkan tipe-tipe entitas yang saling berhubungan. Garis

40 45 tersebut diberi nama sesuai dengan nama relasinya dan diberi tanda panah satu arah di samping nama relasinya. Biasanya sebuah relationship dinamakan dengan menggunakan kata kerja, seperti Mengatur, atau dengan sebuah frase kata kerja, seperti DisewaOleh. Sedangkan tanda panah ditempatkan di samping nama relationship yang mengindikasikan arah bagi pembaca untuk mengartikan nama dari suatu relationship. Huruf pertama dari setiap kata pada nama relationship ditulis dengan huruf besar. Gambar 2.9 Representasi diagramatik dari Relationship (Connolly, 2005, p347) Derajat dari tipe relationship adalah jumlah tipe entity yang ikut serta dalam sebuah relationship (Connolly, 2005, p347). Sebuah relationship yang memiliki derajat dua disebut binary (Connolly, 2005, p348). Sedangkan sebuah relationship yang berderajat tiga disebut ternary (Connolly, 2005, p348), dan jika sebuah relationship yang berderajat empat disebut sebagai quartenary (Connolly, 2005, p348). Lambang belah ketupat merepresentasikan relationship yang memiliki derajat lebih dari dua. Nama dari relationship tersebut ditampilkan di dalam lambang belah ketupat. Panah yang

41 biasanya terdapat di samping nama suatu relationship dihilangkan. 46 Gambar 2.10 Representasi diagram derajat tiga dari suatu tipe relationship (Connolly, 2005, p348) Recursive relationship adalah sebuah tipe relationship dimana tipe entity yang sama ikut serta lebih dari sekali pada peran yang berbeda entity (Connolly, 2005, p349). Relationship dapat diberikan nama peran untuk menentukan fungsi dari setiap entity yang terlibat dalam relationship tersebut. Gambar 2.11 Representasi diagram recursive relationship dan nama peran (Connolly, 2005, p349) Nama peran juga dapat digunakan jika dua buah entity dihubungkan melalui lebih dari satu relationship.

42 47 Gambar 2.12 Representasi diagram entity dengan dua relationship berbeda beserta nama peran (Connolly, 2005, p350) Atribut Atribut adalah properti sebuah entity atau relationship (Connolly, 2005, p350). Menurut Whitten (2004, p295), atribut merupakan properti deskriptif atau karakteristik dari sebuah entity. Atribut menampung nilai yang menjelaskan setiap entity occurrence dan menggambarkan bagian utama dari data yang disimpan di dalam basis data. Atribut domain adalah sekumpulan nilai yang dibolehkan bagi satu atau lebih atribut (Connolly,2005,p350). Atribut dapat diklasifikasikan menjadi : a. Simple attribute adalah atribut yang terdiri dari komponen tunggal (single component) dengan keberadaan yang bebas (independent existence). Simple attribute tidak bisa dibagi lagi ke dalam komponen yang lebih kecil. b. Composite attribute adalah atribut yang terdiri dari beberapa komponen, dan keberadaan setiap komponen tersebut bebas.

43 48 c. Single-valued attribute adalah atribut yang hanya memiliki sebuah nilai untuk setiap occurrence dari sebuah entity d. Multi-valued attribute adalah sebuah atribut yang memiliki banyak nilai untuk setiap occurrence dari sebuah tipe entity. e. Derived attribute adalah atribut yang nilai-nilainya diperoleh dari pengolahan atau diturunkan dari atribut lain yang berhubungan Keys Candidate key adalah himpunan atribut yang minimal yang secara unik mengidentifikasikan setiap occurrence dari sebuah tipe entity (Connolly,2005, p352). Composite key adalah sebuah candidate key yang terdiri atas dua atau lebih atribut (Connolly, 2005, p353) Primary key adalah candidate key yang terpilih untuk mengidentifikasikan secara unik setiap occurrence dari sebuah tipe entity (Connolly, 2005, p353). Pada sebuah tipe entity biasanya terdapat lebih dari satu candidate key yang salah satunya harus dipilih untuk menjadi primary key. Pemilihan primary key didasarkan pada panjang atribut jumlah minimal atribut yang diperlukan, dan keunikannya. Alternate key adalah setiap candidate key yang tidak terpilih menjadi primary key, atau biasa disebut secondary key.

44 49 Foreign key adalah sebuah primary key pada sebuah entity yang digunakan pada entity lainnya untuk mengidentifikasikan sebuah relationship. Fungsinya sebagai penghubung antar tabel. Gambar 2.13 Representasi diagram entity Pegawai dan Cabang beserta atribut dan primary key-nya (Connolly, 2005, p354) Structural Constraints Batasan-batasan yang menggambarkan pembatasan pada relationship seperti yang ada pada dunia nyata harus diterapkan pada tipe entity yang ikut serta pada sebuah relationship. Jenis utama dari batasan pada suatu relationship dinamakan multiplicity (Connolly, 2005, p356). Multiplicity adalah jumlah occurrence yang mungkin terjadi pada sebuah entity yang berhubungan ke sebuah occurrence dari tipe entity lain pada suatu relationship (Connolly, 2005, p356). Derajat yang biasanya digunakan pada suatu relationship adalah binary relationship, yang terdiri atas :

45 50 a. One-to-one (1:1) Relationship Setiap relationship menggambarkan hubungan antara sebuah entity occurrence pada entity yang satu dengan sebuah entity occurrence pada entity lainnya yang ikut serta dalam relationship tersebut. Gambar 2.14 Semantic net menunjukkan dua occurrence dari relationship Pegawai Mengatur Cabang (Connolly, 2005, p357) Gambar 2.15 Multiplicity dari relationship one-to-one (1:1) (Connolly, 2005, p358) b. One-to-many (1:*) Relationship Setiap relationship menggambarkan hubungan antara sebuah entity occurrence pada entity yang satu dengan satu atau lebih entity occurrence pada entity lainnya yang ikut serta dalam relationship tersebut.

46 51 Gambar 2.16 Semantic net menunjukkan tiga occurrence dari relationship Staff Melihat PropertyForRent (Connolly, 2005, p358) Gambar 2.17 Multiplicity dari relationship one-to-many (1:*) (Connolly, 2005, p359) c. Many-to-many (*:*) Relationship Setiap relationship menggambarkan hubungan antara satu atau lebih entity occurrence pada entity yang satu dengan satu atau lebih entity occurrence pada entity lainnya yang ikut serta dalam relationship tersebut. Gambar 2.18 Semantic net menunjukkan empat occurrence dari relationship Koran Mengiklankan PropertyForRent (Connolly, 2005, p360)

47 52 Gambar 2.19 Multiplicity dari relationship many-to-many (*:*) (Connolly, 2005, p360) Data Flow Diagram (DFD) Menurut Whitten (2004, p344), Data Flow Diagram adalah alat yang digunakan untuk menggambarkan aliran data melalui sistem dan kerja atau pengolahan yang dilakukan oleh sistem tersebut. Persamaan dari DFD adalah bubble chart, transformation graph, dan process model. Decomposition diagram, juga dikenal dengan hierarchy chart, adalah alat yang digunakan untuk menggambarkan dekomposisi sistem. Decomposition diagram pada dasarnya adalah alat perencanaan untuk model proses yang lebih detail, yang disebut diagram aliran data. Context diagram adalah model proses yang menggambarkan tampilan dari sistem ke dunia bisnis dan dunia luar, termasuk sistem informasi yang lainnya. Data Flow Diagram terdiri dari simbol-simbol sebagai berikut : a. Proses Proses adalah kerja yang dilakukan oleh sistem sebagai respon terhadap aliran data masuk atau kondisi. Proses menggambarkan bagian dari sistem yang mengolah masukan menjadi keluaran. Sinonim dari proses adalah transform. Proses digambarkan dengan sebuah persegi panjang bersudut tumpul.

48 53 Gambar 2.20 Simbol Proses b. Aliran data Aliran menggambarkan perpindahan informasi (input dan output), ke dan dari proses tersebut. Aliran digambarkan dengan sebuah tanda panah. Awal panah menggambarkan asal data sedangkan arah panah menggambarkan tujuan. Gambar 2.21 Simbol Aliran Data c. Data store (Penyimpanan data) Data store adalah penyimpanan data yang ditujukan untuk penggunaan selanjutnya. Sinonimnya adalah file dan database. Data store digambarkan dengan sebuah kotak dengan ujung terbuka. Gambar 2.22 Simbol Data Store d. Agen eksternal Agen eksternal adalah orang, unit organisasi, atau organisasi luar yang berinteraksi dengan sistem. Disebut juga entitas eksternal. Agen eksternal digambarkan dengan sebuah persegi empat. Gambar 2.23 Simbol Agen Eksternal

49 State Transition Diagram (STD) Menurut Whitten (2004, p419), State Transition Diagram digunakan untuk memodelkan behaviour objek khusus yang dinamis. Diagram ini mengilustrasikan siklus hidup objek berbagai keadaan yang dapat diasumsikan oleh objek dan event yang menyebabkan objek beralih dari suatu state ke state yang lain. Notasi yang digunakan dalam State Transition Diagram : a. State State adalah kumpulan dari keadaan atau atribut yang mencirikan seseorang atau suatu benda pada waktu tertentu, bentuk keberadaan tertentu atau kondisi tertentu. State disimbolkan dengan segi empat b. Transisi state Simbol 2.24 Simbol State dalam STD Transisi state adalah state yang disimbolkan dengan panah berarah. Simbol 2.25 Simbol Transisi State dalam STD c. Kondisi dan aksi Untuk melengkapi STD diperlukan dua hal lagi, yaitu Condition dan Action. Condition (State 1) adalah suatu event pada external environment yang dapat dideteksi oleh sistem. Action (State 2) adalah yang dilakukan oleh sistem bila terjadi perubahan state atau merupakan reaksi terhadap condition. Action akan menghasilkan output, message display pada layar, menghasilkan kalkulasi dan lain-lain.