BAB 2 LANDASAN TEORI. 2.1 Teori Umum

Transkripsi

1 BAB 2 LANDASAN TEORI 2.1 Teori Umum Pada teori umum ini kami akan menjelaskan teori yang akan sering digunakan sebagai penunjang dan pedoman untuk membuat rancangan basis data dan prototype pada skripsi kami Pengertian Data Menurut (Hoffer, Presscot, & McFadden, 2005, p.5), data yaitu sebuah representasi penyimpanan dari obyek obyek dan kejadian kejadian yang beramakna dan penting di lingkungan pemakai. Sedangkan menurut (Laudon & Laudon, 2010, p.6), mengatakan bahwa data adalah aliran fakta mentah yang merupakan kejadian yang terjadi dalam organisasi atau lingkungan fisik sebelum mereka terorganisir dan disusun menjadi bentuk yang orang orang dapat memahami dan digunakan Pengertian Informasi (Menurut Brian K & Stacey, 2007, p.25), mendefinisikan informasi adalah data yang sudah diolah atau dimanipulasi untuk digunakan dalam pengambilan keputusan. Menurut (O'Brian & Marakas, 2011, p.34) informasi adalah data yang telah diubah menjadi isi yang mempunyai arti dan kegunaan untuk pengguna akhir tertentu. Dalam jurnal (Fattahi & Afshar,2006) disimpulkan bahwa informasi akan sangat berguna tergantung dari pemberian nilai informasi tersebut. Nilai informasi dapat dilihat dari sudut pandang yang berbeda oleh pihak manajemen atas untuk membuat keputusan manajemen operasional. Nilai informasi berguna sebagai nilai tambah dalam menghemat waktu proses 7

2 8 bisnis, produktivitas serta meningkatkan pengembangan kualitas kerja dengan membagi informasi tersebut ke dalam internal perusahaan Basis Data Menurut (Connolly & Begg, 2010, p.15), basis data adalah kumpulan data yang saling berhubungan secara logis, dan sebuah penjelasan dari data tersebut, yang didesain untuk menemukan data yang diperlukan organisasi. Di dalam basis data, semua data diintegrasikan dengan menghindari duplikasi data. Basis data banyak digunakan oleh banyak departemen dan user. Basis data tidak hanya menangani data operasional organisasi, tetapi juga mengenai data tersebut. Menurut(Turban et al 2005, p.16), database merupakan kumpulan file, tabel,dan relasi yan menyimpan data beserta hubungan diantara data tersebut. Menurut (Lonely & Bryla, 2005, p.4), basis data merupakan kumpulan data pada disk dalarn satu atau lebih file pada server basis data yang dikumpulkan dan dikelola berdasarkan informasi terkait. Didalam jurnal juga dikatakan : Menurut (Honni, 2011) Perusahaan membutuhkan sebuah sistem yang terintegrasi baik dalam pengolahan data dan penyimpanan data maupun pengolahan terhadap arus transaksi yang berdasarkan pada sistem basis data sehingga dalam melakukan proses bisnisnya dapat cepat, akurat dan dapat diandalkan sehingga dapat meningkatkan efisiensi dan kualitas kerja perusahaan. Menurut (Ayuliana, 2012) dengan dibuatnya sistem basis data dan program aplikasi ini dengan baik dapat membantu kinerja karyawan dalam menangani transaksi persediaan, penjualan, karena memiliki fitur-fitur yang memudahkan user untuk mengaksesnya sesuai dengan kebutuhan. Menurut (Christensen, Brandt, & McCracken, 2011) menyatakan bahwa data data yang nantinya akan menghasilkan informasi, disimpan ke dalam suatu tabel dimana tabel tersebut berhubungan satu sama lainnya.

3 9 Setiap tabel yang mengandung satu atau lebih atribut digunakan untuk menghasilkan kualifikasi, identifikasi, pengelompokan, kuantitas, atau mendeskripsikan susunan informasi tabel tersebut Database Management System Menurut (Connolly & Begg, 2010, p.66).database management system (DBMS) adalah sistem perangkat lunak yang memungkinkan pengguna sistem untuk mendefinisikan, membuat, memelihara, dan mengendalikan akses ke dalam basis data Gambar 2.1 Database Management System Sumber : (Connolly & Begg, 2010, p.67) Pada gambar 2.1 dijelaskan tentang bagian sales dan contracts menyatakan bahwa ada dua pengguna sistem yang memasukan data yaitu bagian sales dan bagian contracts. Dua pengguna sistem dengan komputer client yang berbeda mengakses satu basis data yang sama tentu dengan pemasukan data yang berbeda, seperti pada gambar yang tertera bahwa bagian penjualan memasukan data dan laporan dengan mengakses aplikasi sales application program dan bagian contracts memasukan data dan laporan dengan mengakses aplikasi yang berbeda dari bagian sales, yaitu contracts application program, hal seperti ini membutuhkan suatu manajemen atau pengendalian ke dalam basis data dengan adanya DBMS. Fungsi DBMS itu sendiri adalah memberikan hak akses kepada dua pengguna bagian sales dan bagian contracts, data data apa saja yang mereka masukan, modifikasi serta menghapus tergantung dari hak akses mereka, sehingga kontrol terhadap data data yang berbeda jenis dapat teratasi

4 Fasilitas DBMS Biasanya DBMS memiliki fasilitas-fasilitas sebagai berikut: 1. Data Definition Language (DDL) adalah fasilitas mendefinisikan basis data. DDL mengizinkan pengguna untuk memspesifikasikan tipe, struktur, dan batasan aturan mengenai data yang bisa disimpan ke dalam basis data.hal yang bisa dilakukan DDL adalah : Create Table Untuk membuat tabel dengan mengidentifikasikan tipe data untuk tiap kolom. Alter Table Untuk menambah atau membuang kolom dan constrain. Drop Table Untuk membuang atau menghapus tabel beserta semua data yang terkait di dalamnya. Create Index Untuk membuat index pada suatu tabel. Drop Index Untuk membuang atau menghapus index yang telah dibuat sebelumnya. 2. Data Manipulation Language (DML) adalah fasilitas pengguna untuk menambah, menghapus mengedit dan mendapatkan kembali data dari basis data,. Ada juga suatu fasilitas yang melayani pengaksesan data yang disebut query language. Bahasa yang diakui adalah Structured Query Language (SQL), yang merupakan standard dari DBMS. 3. Data Control Language (DCL) Fasilitas yang digunakan mengontrol ke basis data. Contoh : Sistem keamanan yang mencegah user yang tidak punya autoritas untuk akses data.

5 11 Suatu sistem terintegasi yang memelihara konsistensi penyimpanan data. Suatu Sistem kontrol pengembalian data yang mana dapat mengembalikan data ke keadaan sebenarnya apabila terjadi kegagalan perangkat keras atau perangkat lunak. Terdapat suatu katalog yang dapat di akses oleh pengguna, yang menjelaskan data didalam basis data tersebut Komponen DBMS Menurut (Connoly & Begg, 2010, p.18), Komponen DBMS terbagi menjadi lima yaitu : 1. Hardware (perangkat keras) DBMS dan program aplikasi membutuhkan perangkat keras untuk bisa menjalankan fungsi fungsinya. dapat berkisar dari komputer tunggal, mainframe tunggal, hingga jaringan komputer. perangkat keras yang dipakai tergantung pada kebutuhan organisasi dan Database Management System (DBMS) yang digunakan. Sebuah DBMS memerlukan jumlah minimum memori dan hardisk untuk bekerja, tetapi konfigurasi yang minimum tidak memberikan performa yang handal. 2. Software (perangkat lunak) Komponen perangkat lunak terdiri dari perankat lunak DBMS dan program aplikasi beserta sistem operasi (OS), termasuk jaringan perangkat lunak jika DBMS digunakan melalui jaringan. 3. Data Data merupakan data terpenting dalam DBMS khususnya sudut pandang dari end user mengenai data, dimana data berfungsi sebagai jembatan antara komponen mesin dengan komponen manusia. 4. Procedures

6 12 Prosedur merupakan panduan dan aturan dalam membuat dan menggunakan basis data. Prosedur didalam basis data berupa : login ke dalam basis data, penggunaan fasilitas DBMS atau aplikasi program, cara menjalankan dan menghentikan DBMS, membuat backup database, menangani kerusakan hardware atau software, mengubah struktur table, mengumpulkan basis data dari beberapa disk, meningkatkan kinerja atau membuat arsip data pada secondary storage. 5. People (manusia) sistem tersebut. Komponen terakhir yaitu manusia yang terlibat dengan Gambar 2.2 The DBMS Environtment Sumber : (Connolly & Begg, 2010, p.68) Keuntungan dan kerugian DBMS Keuntungan dari DBMS - Berbagi data - Standarisasi - Konsistensi Data - Meningkatkan konkurensi - Meningkatkan produktifitas - Meningkatkan keamanan data - Mengendalikan redudansi data - Mengimprovisasi integritas data - Menyediakan backup data dan recovery - Menyeimbangkan kebutuhan yang bertentangan

7 13 - Informasi yang lebih dari jumlah data yang sama - Meningkatkan aksebilitas data dan responsiveness - Meningkatkan pemeliharaan melalui data independen Kerugian dari DBMS - Mahal - Compexity atau rumit - Memperlambat kinerja beberapa aplikasi lain - Membutuhkan tempat atau penyimpanan besar Database System Development Lifecycle Menurut(Connolly & Begg 2010, p.283), sistem basis data adalah komponen yang fundamental didalam organisasi yang besar dengan sistem informasi yang luas. Hal penting yang harus diperhatikan dalam Database System Development Lifecycle adalah bahwa tingkatannya tidak sepenuhnya berurutan (sequential). Dimana ada beberapa tingkatan yang berulang dengan alur balik (feedback loop), contohnya masalah ditemukan pada tingkat perancangan basis data yang membutuhkan tambahan kumpulan kebutuhan dan analisis. Untuk aplikasi basis data yang kecil dengan pengguna yang sedikit maka lifecycle-nya tidak terlalu kompleks. Sebaliknya ketika merancang basis data yang sedang sampai ke basis data yang banyak dengan ribuan bahkan puluhan ribu pengguna, mengunakan ratusan query dan program aplikasi maka lifecycle akan menjadi sangat kompleks.

8 14 Gambar 2.3 Tingkatan dari Database System Development Lifecycle Sumber : (Connolly & Begg, 2010, p.284) Database Planning aktifitas manajemen yang memungkinkan setiap tahapan dalam Database System Development Lifecycle untuk direalisasikan menjadi paling efisien dan paling efektif. Database Planning seharusnya diintegrasikan dengan keseluruhan strategi sistem

9 15 informasi dari organisasi. Ada 3 persoalan utama dalam menyusun strategi sistem informasi, antara lain : 1. identifikasi dari rencana dan tujuan perusahaan dengan determinasi secara subsequent dari kebutuhan sistem informasi. 2. mengevaluasi sistem informasi yang ada untuk mendefinisikan keunggulan dan kelemahan. 3. penafsiran dari IT opportunity untuk mendapatkan keuntungan bersaing System definition Sistem definisi mendeskripsikan cakupan dan batasan dari aplikasi basis data dan user view utama. User view mendeskripsikan apa yang dibutuhkan dari sebuah basis data dari sudut pandang peran pekerja (seperti manager atau supervisor) atau area aplikasi perusahaan (seperti marketing, personel, atau control stock) Requirements Collection and Analysis Adalah Suatu proses yang mengumpulkan dan menganalisis informasi mengenai bagian mana saja dari organisasi yang didukung oleh aplikasi basis data dan penggunaan informasi ini untuk mengidentifikasi kebutuhan pengguna dari sistem yang baru. Untuk mengumpulkan dan menganalisis informasi digunakan teknik yang dinamakan teknik fact-finding. Menurut (Connolly & Begg, 2010, p.317), terdapat lima teknik fact - finding yang umum digunakan. Interview. Mengevaluasi dokumentasi. Observasi. Questioner.

10 16 Research Database Design Menurut (Connolly & Begg, 2010, p291 ), Database design adalah suatu proses yang membuat suatu perancangan untuk basis data yang akan mendukung kegiatan operasional dan tujuan dari perusahaan. Pada bagian ini dibagi menjadi tiga tahap, yaitu conceptual, logical, dan physical : 1. Conceptual database design Pada tahap konseptual ini bertujuan untuk membuat representasi konseptual dari basis data, termasuk identifikasi entitas, relationship, dan atribut. Pada tahap ini dibagi menjadi beberapa langkah, yaitu: Langkah 1. Membangun conceptual data model Langkah 1.1 Langkah 1.2 Langkah 1.3 Langkah 1.4 Langkah 1.5 Identifikasi Tipe Entitas Identifikasi Tipe Relationship Identifikasi dan Asosiasi Atribut dengan Tipe Entitas dan Tipe Relationship Menentukan Domain Atribut Menentukan Atribut Candidate key, Primary Key, dan Alternate Key Langkah 1.6 Mempertimbangkan penggunaan enhanced modeling concept (optional) Langkah 1.7 Langkah 1.8 Memeriksa model dari redundancy Validasi Model Konseptual dengan user transaction

11 17 Langkah 1.9 Meninjau local conceptual data model dengan pengguna 2. Logical database design Pada tahap ini merubah model konseptual ke model logikal yang dipengaruhi oleh model data yang menjadi tujuan dari basis data. Didalam perancangan model logikal, model data yang telah didapat dalam basis data konseptual diubah kedalam bentuk dimana data yang ada dipengaruhi oleh model data yang menjadi tujuan basis data (contoh : relational model). Hal ini dilakukan untuk menjelaskan representasi konseptual kedalam bentuk struktur logikal dalam basis data. Data model logikal adalah sebagai sumber informasi dalam merancang basis data fisikal. Perancangan basis data logikal memberikan sarana yang membantu para perancang dalam merancang basis data fisikal. Pada tahap ini dibagi menjadi beberapa langkah, yaitu : Langkah 2. Membangun dan memvalidasi logical data model Langkah 2.1 Menentukan Relasi Relasi untuk Model Data Logikal Langkah 2.2 Validasi Model dengan Normalisasi Langkah 2.3 Memvalidasi Relasi dengan User Transaction Langkah 2.4 Langkah 2.5 Langkah 2.6 Langkah 2.7 Mendefinisikan Kendala Integrity review logical data model dengan User Menggabungkan Logical Data Model ke dalam Global Model (optional) Memeriksa untuk perkembangan lebih lanjut

12 18 3. Physical database design Pada tahap perancangan basis data fisikal memungkinkan perancang basis data untuk membuat keputusan tentang bagaimana basis data akan diimplementasikan. Oleh karena itu, perancangan basis data fisikal harus disesuaikan dengan DBMS yang spesifik. Pada tahap ini dibagi menjadi beberapa langkah, yaitu : Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih Langkah 3.1 Merancang relasi relasi dasar Langkah 3.2 Merancang representasi untuk data turunan Langkah 3.3 Merancang general constraint Langkah 4. Merancang file organization dan indexes Langkah 4.1 Langkah 4.2 Langkah 4.3 Langkah 4.4 Menganalisa transaksi Memilih organisasi file Memillih index index Memperkirakan kebutuhan disk space Langkah 5. Merancang user view Langkah 6. Merancang mekanisme keamanan Langkah 7. Mempertimbangkan pengenalan redudancy yang dipilih Langkah 8. Mengawasi dan mengendalikan sistem operasional

13 DBMS selection Seleksi /pemilihan DBMS dilakukan untuk memilih DBMS yang sesuai dengan aplikasi basis data. Menurut ( Connolly & Begg, 2010, p.295 ), berikut ini adalah langkah langkah dalam memilih DBMS : 1. Mebdeskirpsikan cakupan tugas berdasarkan kebutuhan perusahaan 2. Membuat perbandingan mengenai 2 atau lebih produk DBMS 3. Mengevaluasi produk-produk DBMS tersebut 4. Merekomendasikan pemilihan DBMS dan membuat laporan hasil dari evaluasi produk DBMS tersebut. Secara khusus DBMS menyediakan fasilitas-fasilitas sebagai berikut : 1. Memperkenankan pengguna untuk menentukan basis data, biasanya melalui Data Definition Language (DDL). DDL memperkenankan pengguna untuk menspesifikasikan tipe data, struktur data dan batasan-batasan data yang bisa disimpan di basis data. 2. Memperkenankan pengguna untuk insert, update, delete atau retrive data dari basis data, biasanya melalui Data Manipulation Language (DML). 3. DBMS menyediakan akses kontrol ke basis data. Sebagai contohnya DBMS menyediakan : a. Security system, dimana menghalangi autorisasi pengguna untuk mengakses basis data. b. Integrity system, dimana menangani konsistensi penyimpanan data. c. Concurrency control system, dimana memperkenankan basis data untuk diakses secara share. d. Recovery control system, dimana basis data bias direstore pada saat terjadi kesalahan pada hardware maupun software.

14 20 e. User-accesable catalog, berisi deskripsi data dalam basis data Application Design Menurut (Connolly & Begg, 2010, p.299), rancangan aplikasi adalah perancangan dari user interface dan program aplikasi yang digunakan dan memproses basis data. Dari gambar 2.1, dapat dilihat bahwa database design dan application design adalah aktifitas yang paralel dalam database lifecycle.didalam kebanyakan kasus tidak mungkin dapat menyelesaikan application design sebelum menyelesaikan database design itu sendiri. Dengan kata lain database yang ada mendukung aplikasi sehingga ada banyak aliran informasi antara application design dan database design Prototyping (optional) Pada kondisi tertentu kita dapat memilih apakah akan membuat prototipe atau langsung mengimplementasikan basis data. Suatu prototipe adalah suatu model aplikasi basis data yang mempunyai semua rupa yang diperlukan dan menyediakan semua kemampuan sistem. Tujuan utama prototipe adalah untuk menguji apakah fitur-fitur yang ada pada sistem telah bekerja sesuai dengan karakteristik pengguna. Dengan cara ini, kita dapat memperjelas kebutuhan pengguna dan pengembangan sistem dan mengevaluasi kelayakan desain sistem tersebut. Menurut (Connolly & Begg, 2010, p.303), ada dua cara strategi membuat prototipe yaitu requirements prototyping dan evolutioner prototyping. Untuk requirements prototyping digunakan prototipe untuk menentukan kebutuhan suatu aplikasi basis data yang diusulkan dan ketika kebutuhan dirasakan sudah lengkap maka prototipe tersebut tidak lagi digunakan. Prototype evolutioner digunakan untuk tujuan yang sama, perbedaannya ialah bahwa prototipe tidaklah dibuang tapi dikembangkan lebih lanjut sehingga menjadi aplikasi basis data tersebut.

15 Data Convertion dan Loading Menurut (Connolly & Begg, 2010, p.305), pemindahan data yang sudah ada ke basis data yang baru dan mengubah aplikasi yang sedang berjalan agar dapat digunakan dalam basis data yang baru Operational Maintenance Menurut (Connolly & Begg, 2010, p.306), setelah melalui tahapan-tahapan sebelumnya, maka sistem sekarang telah pada tahap pemeiharaan yang melibatkan aktivitas berikut : 1. Monitoring performance dari sistem. Jika performance berada disuatu tingkatan yang bisa diterima, setting atau menyusun kembali basis data mungkin diperlukan. 2. Memelihara dan meningkatkan mutu aplikasi basis data. Kebutuhan baru disatukan kedalam aplikasi basis data dengan mengikuti langkah langkah sebelumnya yang terdapat dalam database lifecycle. Ketika aplikasi bisnis data sedang beroperasi, perlu dilakukan monitoring secara dekat untuk memastikan bahwa performansi dalam tingkatan yang dapat diterima. Proses monitoring akan terus berlanjut sepanjang hidup suatu aplikasi basis data tersebut dan pada waktu tertentu boleh melakukan menyusun kembali basis data untuk mencukupi kebutuhan dari sistem. Perubahan ini meyediakan informasi pada evolusi sistem dan sumber daya pada masa yang akan datang mungkin diperlukan. Hal ini memungkinkan DBA untuk terlibat dalam perencanaan kapasitas dan untuk memberitahu staf senior siaga untuk melakukan penyesuaian rencana jika DBMS kekurangan kegunaan tertentu, DBA dapat mengembangkan kegunaan yang diperlukan atau memberi tools tambahan jika tersedia.

16 Tahap Tahap Perancangan Basis data Dalam merancang suatu basis data melalui beberapa tahapan, sebagai berikut : Perancanagan Basis data Konseptual Perancanagan Basis data Logikal Perancanagan Basis data Fisikal Perancangan Basis data Konseptual Menurut (Connolly & Begg 2010, p.439), perancangan konseptual basis data adalah proses pembangunan model data yang digunakan di perusahaan, yang tidak bergantung pada semua pertimbangan fisikal. Tujuannya untuk membangun representasi konseptual basis data, yang meliputi identifikasi dari entitas - entitas, atribut - atribut, dan relationship relationship yang penting. Langkah 1. Membangun conceptual data model Tujuannya adalah menurut (Connolly & Begg, 2010, p.442), untuk membangun local conceptual data model dari perusahaan untuk tiap view yang spesifik. Tiap local conceptual data model terdiri dari entity type, relation type, atribut - atribut, domain domain atribut, primary key, alternate key, dan integrity constraint. Langkah - langkah yang harus dilakukan pada langkah 1 : Langkah 1.1 Identifikasikan Tipe Entitas Tujuannya adalah menurut (Connolly & Begg, 2010, p.443), mengidentifikasikan tipe tipe entitas utama yang dibutuhkan oleh view. Langkah 1.2 Identifikasikan Tipe Relationship Tujuannya adalah menurut (Connolly & Begg, 2010, p.445), mengidentifikasikan relationship relationship penting yang ada diantara tipe tipe entitas yang telah diidentifikasi.

17 23 Langkah 1.3 Identifikasikan dan Asiosiasikan Atribut dengan Tipe Entitas dan Tipe Relationship Tujuannya adalah menurut (Connolly & Begg, 2010, p.447), untuk menghubungkan atribut atribut dengan entitas atau relationship type yang sesuai. Langkah 1.4 Menentukan Domain Atribut Tujuannya adalah menurut (Connolly & Begg 2010, p.450), untuk menentukan domain domain untuk atribut atribut dalam local conceptual data model. Domain atribut adalah kumpulan nilai yang diperbolehkan untuk satu atau lebih atribut. Domain adalah fitur yang sangat kuat dalam model relational. Setiap atribut di dalam relasi ditetapkan dalam domain. Domain mungkin berbeda untuk tiap atribut, atau dua atau lebih atribut mungkin ditetapkan dalam domain yang sama. Langkah 1.5 Penentuan Atribut Candidate Key, Primary Key, dan Alternate Key Tujuannya adalah menurut (Connolly & Begg, 2010, p.451), untuk mengidentifikasikan candidate candidate key untuk tiap tipe entitas dan, jika terdapat lebih dari satu candidate key, maka pilih salah satu untuk dijadikan primary key. Menurut (Connolly & Begg, 2010, p.451), ketika memilih primary key diantara candidate key, kita dapat menggunakan panduan berikut untuk membantu pemilihan primary key, yaitu : - Candidate key dengan kumpulan atribut yang minimal - Candidate key yang nilainya jarang berubah - Candidate key dengan karakter karakter yang paling sedikit (untuk yang memiliki textual attributes)

18 24 - Candidate key dengan nilai maksimum paling rendah (untuk yang memiliki numerical attributes) - Candidate key yang paling mudah digunakan dari sudut pandang user Langkah 1.6 Mempertimbangkan penggunaan enhanced modeling concept (optional) Tujuannya adalah menurut (Connolly & Begg, 2010, p.453), untuk mempertimbangkan penggunaan enhanced modeling concepts, seperti specialization / generalization, aggregation, dan composition. Langkah 1.7 Memeriksa model dari redundancy Tujuannya adalah menurut (Connolly & Begg, 2010, p.453), untuk memeriksa apakah terdapat redundancy dalam model. Dua kegiatan dalam langkah ini adalah : memeriksa kembali one-to-one relationship dan menghilangkan redundant relationships. Langkah 1.8 Validasi Model Konseptual dengan User Transaction Tujuannya adalah menurut (Connolly & Begg, 2010, p.456), untuk menjamin bahwa model konseptual mendukung transaksi transaksi yang dibutuhkan oleh view. Langkah 1.9 Meninjau local conceptual data model dengan pengguna Tujuannya adalah menurut (Connolly & Begg, 2010, p.458), untuk meninjau local conceptual data model dengan user untuk menjamin bahwa model tersebut adalah representasi yang sebenarnya dari data yang dibutuhkan oleh perusahaan Perancangan Basis data Logikal

19 25 Menurut (Connolly & Begg, 2010, p.439), perancangan logikal basis data adalah suatu proses pembangunan model data yang digunakan dalam perusahaan berdasar atas model data yang spesifik, tetapi tidak bergantung pada particular DBMS dan pertimbangan fisikal lainnya. Tujuannya untuk menerjemahkan representasi konseptual ke struktur logikal dari basis data yang meliputi perancangan relasi relasi. Langkah 2. Membangun dan memvalidasi logical data model Menurut (Connolly & Begg, 2010, p.462), tujuannya adalah menerjemahkan logical data model dan kemudian untuk mevalidasi model tersebut untuk memeriksa model tersebut dengan benar secara struktural dan memiliki kemampuan untuk mendukung transaksi - transaksi yang dibutuhkan. Tujuan ini akan tercapai dengan mengikuti langkah langkah berikut : Langkah 2.1 Menentukan Relasi - Relasi untuk Model Data Logikal tujuannya adalah menurut (Connolly dan Begg, 2010, p.463), menciptakan relasi relasi untuk model data logikal untuk merepresentasikan entitas-entitas, relationship - relationship, dan atribut - atribut yang telah diidentifikasikan. Relationship yang dapat muncul pada model data konseptual : Strong Entity Type dan Weak Entity Type Menurut (Connolly & Begg, 2010, p.354), strong entity type adalah tipe entitas yang keberadaannya tidak bergantung (independent) pada beberapa tipe entitas lainnya. Karakteristik dari strong entity type adalah tiap entity occurrence dapat diidentifikasi secara unik menggunakan atribut primary key dari tipe entitas. Strong entity type sering juga disebut parent atau owner atau dominant entities.

20 26 Menurut (Connolly & Begg, 2010, p.355), weak entity type adalah tipe entitas yang keberadaannya bergantung (dependent) pada beberapa tipe entitas lainnya. Weak entity type juga disebut child, dependent, atau subordinate entities. One-to-many (1:*) binary relationship types Menurut (Connolly & Begg 2010, p.465), untuk tiap 1:* binary relationship, entitas pada one side dari relationship dianggap sebagai entitas parent dan entitas pada many side dianggap sebagai entitas child. Untuk merepresentasikan relationship ini, pasangkan salinan primary key dari entitas parent ke dalam relation yang merepresentasikan entitas child, untuk berlaku sebagai foreign key. One-to-one (1:1) binary relationsip types Menurut (Connolly & Begg, 2010, p.465), penciptaan relasi - relasi untuk merepresentasikan 1:1 relationship sedikit lebih kompleks karena cardinality tidak dapat digunakan untuk membantu mengidentifikasikan entitas - entitas parent dan child dalam relationship. Sebagai gantinya participation constraint digunakan untuk membantu memutuskan apakah baik untuk merepresentasikan relationship dengan menggabungkan entitas - entitas yang terlibat kedalam satu relasi atau dengan menciptakan dua relasi dengan menyalin salinan dari primary key dari satu relasi ke relasi lainnya. Kita mempertimbangkan bagaimana menciptakan relasi relasi untuk merepresentasikan participation constraint berikut : - Mandatory participation pada 2 sisi dari 1:1 relationship - Mandatory participation pada 1 sisi dari 1:1 relationship - Optional participation pada 2 sisi dari 1:1 relationship Mandatory participation pada 2 sisi dari 1:1 relationship

21 27 Menurut (Connolly & Begg, 2010, p.466), dalam kasus ini, kita harus menggabungkan entitas entitas yang terlibat kedalam satu relasi dan memilih salah satu dari primary key dari entitas entitas aslinya untuk menjadi primary key dari relasi yang baru, sedangkan yang lainnya dijadikan alternate key. Mandatory participation pada 1 sisi dari 1:1 relationship Menurut (Connolly & Begg, 2010, p.466), dalam kasus ini, kita dapat mengidentifikasikan entitas - entitas parent dan child untuk 1:1 relationship memakai participation constraint. Entitas yang memiliki optional participation dalam relationship dianggap sebagai entitas parent, dan entitas yang mempunyai mandatory participation dalam relationship dianggap sebagai entitas child. Seperti yang diuraikan diatas, salinan primary key dari entitas parent ditempatkan dalam relasi yang merepresentasikan entitas child. Jika relationship mempunyai satu atau lebih atribut, atribut ini harus menyertakan penyalinan primary key ke relasi child. Optional participation pada 2 sisi dari 1:1 relationship Menurut (Connolly & Begg, 2010, p.467), kita dapat memilih primary key mana yang dipilih tergantung dari kasus yang ada. One-to-one (1:1) recursive relationship Menurut (Connolly & Begg, 2010, p.467), untuk 1:1 recursive relationship, kita mengikuti aturan untuk participation seperti yang diuraikan untuk 1:1 relationship. Untuk 1:1 recursive relationship dengan mandatory participation pada dua sisi, direpresentasikan recursive relationship sebagai relasi tunggal dengan dua salinan primary key. Sedangkan salah satu salinan dari primary key

22 28 merepresentasikan foreign key dan harus diganti namanya untuk menandakan relationship yang direpresentasikan. Untuk 1:1 recursive relationship dengan mandatory participation pada satu sisi, kita mempunyai pilihan untuk menciptakan relasi tunggal dengan dua salinan primary key atau untuk menciptakan relasi baru untuk merepresentasikan relationship. Relasi baru hanya akan mempunyai 2 atribut, keduanya merupakan salinan primary key. Untuk 1:1 recursive relationship dengan optional participation pada dua sisi, kita menciptakan relasi baru seperti yang telah diuraikan diatas. Superclass/subclass relationship types Menurut (Connolly & Begg, 2010, p.467),untuk tiap superclass / subclass relationship dalam data model konseptual, kita mengidentifikasikan entitas superclass sebagai entitas parent dan entitas subclass sebagai entitas child. Terdapat banyak pilihan dalam merepresentasikan relationship sebagai salah satu atau lebih relasi relasi. Pilihan yang paling sesuai tergantung dari beberapa faktor seperti disjointnese dan participation constraint pada superclass / subclass relationship apakah subclass subclass terlibat dalam distinct relationship dan jumlah participant participant dalam superclass / subclass relationship. Many-to-many (*:*) binary relationship types Menurut (Connolly & Begg, 2010, p.469), untuk setiap *:* binary relationship menghasilkan relasi untuk merepresentasikan relationship dan meliputi atribut atribut yang menjadi bagian dari relationship. Kita menyalin salinan primary key dari entitas yang berhubungan dalam relationship kedalam relasi baru. Untuk valid sebagai foreign key.

23 29 Complex relationship types Menurut (Connolly & Begg, 2010, p.470), untuk setiap complex relationship menciptakan sebuah relasi untuk merepresentasikan relationship dan termasuk semua atribut yang merupakan bagian dari relationship tersebut. Kita menyalin salinan primary key dari entitas yang berhubungan dalam complex relationship kedalam relasi baru, untuk berlaku sebagai foreign key. Multi-valued attributes Menurut (Connolly & Begg, 2010, p.471), menciptakan relasi yang merepresentasikan atribut atribut multi-valued dan menyalin salinan primary key dari entitas owner kedalam relasi baru untuk menjadi foreign key. Langkah 2.2 Validasi Model dengan Normalisasi tujuannya adalah menurut (Connolly & Begg, 2010, p.473), untuk memvalidasi relasi relasi dalam model data konseptual memakai teknik normalisasi. Menurut (Connolly & Begg, 2010, p.388), normalisasi adalah teknik untuk menghasilkan sekumpulan relasi relasi dengan properti properti yang diinginkan, sesuai dengan kebutuhan data data yang diberikan oleh perusahaan. Tujuan dari normalisasi ini adalah untuk meminimalkan redudansi data (perulangan data) dan update anomalies, menciptakan representasi data, hubungan antar data dan contraint yang akurat, serta meningkatkan stabilitas. Untuk mencapai tujuan tersebut maka harus dilakukan identifikasi dengan benar atas relasi relasi yang ada. Pada dasarnya, proses normalisasi ini dilakukan karena terjadinya redundansi data atau kejanggalan pengubahan (update anomaly).

24 30 Menurut (Connolly & Begg, 2010, p.391), update anomaly ada tiga jenis yaitu insert anomaly, delete anomaly, dan modification/update anomaly. Insert anomaly adalah kejanggalan yang terjadi terhadap sebuah table pada saat dilakukan penambahan suatu record, yaitu berupa pelanggaran terhadap integrity constraint. Delete anomaly adalah kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan penghapusan suatu record, penghapusan bermaksud untuk menghapus suatu data tertentu tetapi menyebabkan kehilangan informasi lain dari tabel tersebut. Modification/update anomaly adalah kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan pengubahan suatu record, pengubahan terhadap suatu nilai tertentu harus dilakukan lebih dari sekali. Hal ini amat memungkinkan terjadinya inkonsistensi data. Menurut (Connolly & Begg, 2010, p.401), proses normalisasi meliputi langkah langkah utama berikut : - First Normal Form ( 1NF ), yang menghilangkan repeating groups - Second Normal Form ( 2NF ), yang menghilangkan partial dependency dalam primary key - Third Normal Form ( 3NF ), yang menghilangkan transitive dependencies dalam primary key - Boyce-Codd Normal Form ( BCNF ), yang menghilangkan anomaly anomaly yang tersisa dari functional dependencies Langkah 2.3 Mevalidasi Relasi dengan User Transaction tujuannya adalah menurut (Connolly & Begg, 2010, p.474), untuk menjamin bahwa relasi relasi dalam model data logikal mendukung transaksi transaksi yang dibutuhkan oleh view.

25 31 Langkah 2.4 Mendefinisikan Kendala Integrity tujuannya adalah menurut (Connolly & Begg, 2010, p.474),untuk memeriksa integrity constraint yang direpresentasikan dalam model data logical. Integrity constraint terdiri dari 5 jenis, yaitu : data yang dibutuhkan, attribute domain constraint, entity integrity, referential integrity, dan general constraint. Data yang dibutuhkan Menurut (Connolly & Begg, 2010, p.475), beberapa atribut harus selalu memiliki nilai yang valid. Dengan kata lain, atribut tersebut tidak boleh bernilai null. Attribute domain constraint Menurut (Connolly & Begg, 2010, p.475), tiap atribut mempunyai domain, yaitu kumpulan nilai nilai yang legal. Misalnya, ada 2 jenis kelamin yaitu M atau F, jadi domain untuk atribut jenis kelamin adalah karakter string tunggal yang terdiri dari M; atau F. Batasan ini harus diidentifikasikan ketika kita memilih domain atribut untuk model data. Multiplicity Menurut(Connolly & Begg, 2010, p.475), multiplicity merepresentasikan batasan yang diletakkan pada relationship antara data di dalam basis data. Entity integrity Menurut (Connolly & Begg, 2010, p.475), primary key dari entitas tidak boleh bernilai null. Batasan ini harus benar benar dipertimbangkan

26 32 ketika kita mengidentifikasikan primary key untuk tiap tipe entitas. Referential integrity Menurut (Connolly & Begg, 2010, p.475), foreign key menghubungkan tiap tuple dalam relasi child ke tuple dalam relasi parent yang meliputi nilai candidate key yang sesuai. Referential integrity berarti bahwa jika foreign key memiliki nilai, maka nilai tersebut harus menunjuk pada tuple yang ada pada relasi parent. Menurut ( Connolly & Begg, 2010, p476 ), terdapat 5 strategi untuk mempertahankan referential integrity pada saat penghapusan tuple pada relasi parent, yaitu : - NO ACTION Mencegah penghapusan dari relasi parent jika terdapat tuple tuple child yang ditunjuk. - CASCADE Ketika tuple parent dihapus, secara otomatis juga dihapus tuple tuple child yang ditunjuk - SET NULL Ketika tuple parent dihapus, nilai foreign key dalam semua tuple tuple child yang berhubungan secara otomastis diubah menjadi null. - SET DEFAULT Ketika tuple parent dihapus, nilai foreign key dalam semua tuple tuple child yang

27 33 berhubungan secara otomatis diubah menjadi nilai default-nya. - NO CHECK Ketika tuple parent dihapus, tidak melakukan apa apa untuk menjamin referential integrity tetap terjaga. General constraints Pengubahan pengubahan pada entitas entitas mungkin diatur oleh batasan batasan yang memerintah transaksi real world yang direpresentasikan oleh pengubahan tersebut Langkah 2.5 Me-review Logical Data Model dengan User tujuannya adalah menurut (Connolly & Begg, 2010, p.478),untuk menjamin bahwa pengguna mempertimbangkan model data logikal menjadi representasi yang sebenarnya dari kebutuhan data perusahaan. Langkah 2.6 Menggabungkan Logical Data Model ke dalam Global Model (optional) tujuannya adalah menurut (Connolly & Begg, 2010, p.479), untuk merepresentasikan semua user views dari basis data. Langkah 2.7 Memeriksa untuk perkembangan lebih lanjut tujuannya adalah menurut (Connolly & Begg, 2010, p.490),untuk menentukan apakah terdapat perubahan yang signifikan pada masa depan yang dapat diramalkan dan untuk menilai apakah model data logikal dapat mengakomodasi perubahan tersebut.

28 Perancangan Basis data Fisikal Menurut (Connolly & Begg, 2010, p.439), perancangan fisik basis data adalah proses membuat deskripsi dari implementasi basis data pada secondary storage, mendeskripsikan relasi dasar, file organization, dan index yang digunakan untuk mendapatkan akses efisien pada data dan semua integrity constraint yang berhubungan dan security measures. Tujuannya adalah untuk menentukan bagaimana struktur logikal diimplementasikan (sebagai relasi dasar) secara fisik dalam DBMS yang dipilih. Menurut (Connolly & Begg, 2010, p.496), langkah langkah perancangan fisik basis data meliputi : Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih tujuannya adalah menurut (Connolly & Begg, 2010, p.497), untuk menghasilkan relational database schema dari data model logikal yang dapat diimplementasikan dalam DBMS yang dipilih. 3 aktifitas pada Step 3 : Langkah 3.1 Merancang relasi relasi dasar tujuannya adalah menurut (Connolly & Begg,2010, p.498), untuk memutuskan bagaimana merepresentasikan relasi relasi dasar yang diidentifikasikan dalam model data logikal dalam DBMS yang dipilih. Untuk tiap relasi yang diidentifikasi dalam model data logikal, kita mempunyai definisi yang terdiri dari : - Nama relasi - Daftar atribut atribut sederhana dalam golongan golongan - Primary key dan alternate key dan foreign key jika ada - Referential integrity contraints untuk semua foreign keys yang diidentifikasikan

29 35 Menurut (Connolly & Begg, 2010, p.498), sedangkan dari data dictionary, dari tiap tiap atribut kita juga mempunyai : - Domain-nya, yang terdiri dari tipe data, panjang, dan semua batasan dalam domain - Nilai default optional untuk atribut - Apakah atribut dapat mempunyai nilai nulls - Apakah atribut tersebut derived, maka harus dikomputasi Langkah 3.2 Merancang Representasi untuk Data Turunan tujuannya adalah menurut (Connolly & Begg, 2010, p.499), untuk menentukan bagaimana merepresentasikan semua data derived yang ada dalam model data logikal dalam DBMS yang dipilih. Atribut yang nilainya dapat dicari dengan memeriksa nilai nilai dari atribut atribut lainnya disebut derived atau calculated attribute. Langkah 3.3 Merancang General Constraint Menurut (Connolly & Begg, 2010, p.501), tujuannya adalah untuk merancang general constraint untuk DBMS yang dipilih. Langkah 4. Merancang file organization dan indexes Menurut (Connolly & Begg, 2010, p.501), tujuannya adalah untuk menentukan file organisasi yang optimal untuk menyimpan relasi relasi dasar dan indeks indeks yang dibutuhkan untuk mencapai performansi yang dapat diterima, dengan begitu, relasi dan tuple akan disimpan pada secondary storage. Terdapat beberapa factor yang dapat digunakan untuk mengukur efisiensi, yaitu :

30 36 - Transaction throughput adalah jumlah transaksi yang dapat diproses dalam jangka waktu tertentu. Diukur pada kondisi peak. - Response time adalah waktu yang diperlukan untuk menyelesaikan satu transaksi. Dari pandangan pengguna, kita sedapat mungkin ingin meminimalkan response time. Response time ini biasanya dipengaruhi waktu untuk mengakses data yang diperlukan, system load, OS scheduling, communication delay. - Disk storage adalah jumlah disk space yang dibutuhkan untuk menyimpan file file basis data. Para perancang sistem biasanya ingin meminimalkan disk storage yang digunakan. Langkah 4.1 Menganalisa Transaksi tujuannya adalah menurut (Connolly & Begg 2010, p.502), untuk mengetahui fungsi dari transaksi yang akan diterapkan pada basis data dan untuk menganalisa transaksi transaksi yang penting. Langkah 4.2 Memilih Organisasi file tujuannya adalah menurut (Connolly & Begg, 2010, p.506), untuk menentukan organisasi file yang paling efisien untuk tiap relasi dasar. Langkah 4.3 Memillih index index tujuannya adalah menurut (Connolly & Begg, 2010, p.508), untuk mempertimbangkan apakah dengan menambahkan index akan meningkatkan performansi dari sistem. Langkah 4.4 Memperkirakan kebutuhan disk space Menurut (Connolly & Begg, 2010, p.514), untuk memperkirakan jumlah disk space yang dibutuhkan oleh basis

31 37 data. Untuk menyimpan data dan semua index index nonclustered dasar dalam tabel yang tidak mempunyai clustered index oleh karena itu kita dapat menggunakan beberapa langkah berikut : 1. Menghitung space yang digunakan untuk menyimpan data 2. Menghitung space yang digunakan untuk menyimpan tiap index index nonclustered dasar. 3. Menjumlahkan nilai nilai yang dikalkulasikan. Langkah 5. Merancang user view tujuannya adalah menurut (Connolly & Begg 2010, p.515), untuk merancang user view yang diidentifikasikan selama pengumpulan kebutuhan kebutuhan dan tahap analisis dari system development lifecycle. Langkah 6. Merancang mekanisme keamanan tujuannya adalah menurut (Connolly & Begg, 2010, p.516), untuk merancang mekanisme keamanan untuk basis data seperti yang ditentukan oleh user pada waktu tahap pengumpulan kebutuhan kebutuhan dari system development lifecycle. Mekanisme kemanan yang dirancang dalam basis data yaitu mekanisme keamanan sistem dan mekanisme keamanan data. Langkah 7. Mempertimbangkan pengenalan redudancy control tujuannya adalah menurut (Connolly & Begg, 2010, p.519), untuk menentukan apakah pengenalan redundancy yang dikontrol dengan aturan aturan normalisasi akan meningkatkan performansi sistem. Langkah 8. Mengawasi dan mengendalikan sistem operasional tujuannya adalah menurut (Connolly & Begg, 2010, p.532), untuk mengawasi sistem operasional dan meningkatkan performansi

32 38 dari sistem untuk memperbaiki keputusan perancangan yang tidak sesuai atau merefleksikan perubahan kebutuhan ER Modeling Entity Type Pada kutipan jurnal (Bahl, Sharma & Rajpal, 2011, p.2), entity relationships (ER) model digunakan untuk menunjukkan hubungan antar entitas dan sebagai tool dasar dalam merancang basis data Menurut (Connolly & Begg, 2010, p.343), entity type adalah kelompok objek dengan properties yang sama, yang didefinisikan untuk perusahaan selama mempunyai keadaan yang independent. Entity type mempunyai keadaan yang independent dan dapat berupa objek objek dengan keberadaan fisik atau objek objek dengan keberadaan konseptual Entity Occurrence Menurut (Connolly & Begg, 2010, p.345), entity occurrence adalah objek dari entity type yang dapat diidentifikasi secara unik Relationship Type Menurut (Connolly & Begg, 2010, p.346), relationship type adalah sekelompok penyatuan yang memiliki arti antar entity types atau sekelompok penyatuan antara satu atau lebih participating entity type Relationship Occurrence Menurut (Connolly & Begg, 2010, p.346), relationship occurrence adalah penyatuan yang dapat diidentifikasikan secara unik, yang terdiri dari 1 occurrence dari tiap participating entity type Derajat tipe relasi (Degree of relationship type) Menurut (Connolly & Begg, 2010, p.376), derajat tipe relasi merupakan jumlah tipe entitas yang berpartisipasi dalam relasi.entitas yang berkaitan dalam tipe relasi dikenal sebagai participant dalam relasi. Jumlah participant dalam tipe relasi dikenal sebagai degree dari relasi. Relasi dengan

33 39 degree dua disebut binary, sedangkan relasi dengan degree tiga disebut ternary, dan relasi dengan degree empat disebut quaternary Relasi Rekursif (Recursive relationship) Menurut Connolly dan Begg (2010, p376), relasi rekursif merupakan sebuah tipe relasi dimana tipe entity yang sama berpartisipasi lebih dari satu kali dalam peran yang berbeda Atribut Menurut (Connolly & Begg, 2010, p350), atribut adalah property dari entitas atau relationship type. Atribut domain adalah sekumpulan nilai nilai yang diperbolehkan untuk satu atau lebih atribut. Atribut dapat diklasifikasikan menjadi simple atau composite ; single-valued atau multivalued; atau derived. Simple attribute adalah atribut yang terdiri dari komponen tunggal dengan keadaan independent. Sedangkan composite attribute adalah atribut yang terdiri dari beberapa komponen, dimana setiap komponen dengan keadaan independent contoh nama bisa dipecah lagi menjadi nama depan dan nama belakang. Single-valued attribute adalah atribut yang memiliki nilai tunggal untuk setiap kejadian contohnya entitas staff memiliki IDstaff. Sedangkan multi-valued attribute adalah atribut yang memiliki beberapa nilai untuk kejadian contoh no telepon pasti setiap orang mempunyai beberapa telepon. Derived attribute adalah atribut yang merepresentasikan nilai yang diperoleh (derived) dari satu atau lebih atribut yang berhubungan contoh lama pinjam dihasilkan dari awal tanggal pinjam dikurangi tanggal pengembalian Key Menurut (Connolly & Begg, 2010, p.352), candidate key adalah sekelompok atribut yang minimal dan secara unik mengidentifikasikan tiap occurrence dari entity type.

34 40 Menurut (Connolly & Begg, 2010, p.353), primary key adalah key yang dipilih untuk mengidentifikasikan secara unik tiap occurrence dari entity type. Menurut (Connolly & Begg 2010, p.353), composite key adalah candidate key yang terdiri dari dua atau lebih atribut Structural constraint Tipe utama dari constraint dari relationship disebut multiplicity. Multiplicity adalah jumlah dari kejadian kejadian yang mungkin dari sebuah tipe entitas yang terhubung pada kejadian tunggal dari tipe entitas yang berhubungan melalui relationship khusus. Tiga jenis relationship yang digunakan mengikuti enterprise constraint : Hubungan one-to-one (1:1) Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satu-satu dan dapat pula member entitas yang satu ada yang tidak berhubungan dengan member dari entitas yang berelasi dengannya dan entitas tersebut juga berelasi maksimal 1. Contoh : satu ruang kelas hanya memiliki satu computer dan. Diasumsikan didalam ruangan tersebut 1..1 memiliki 1..1 Ruang kelas komputer Gambar 2.4 Hubungan one-to-one (1:1) Hubungan one-to-many (1:*) Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satu-banyak. Dimana sebuah member dari entitas dapat berhubungan dengan satu atau banyak member dari entitas yang lain dan member dari entitas yang lainnya berhubungan (bisa dari 0) sampai maksimal 1. Contoh : seorang manager dapat memiliki 1 hingga banyak karyawan, tetapi seorang guru hanya memiliki satu dan hanya satu manager.

35 memiliki 1..* manager karyawan Gambar 2.5 Hubungan one-to-many (1:*) Hubungan many-to-many (*:*) Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah banyak-banyak. Member dari sebuah entitas dapat berelasi dengan entitas yang lain dengan maksimal multiplicity banyak (*) dan sebaliknya dengan relasi entitas yang berhubungan tersebut. Contoh : Pembelian dapat memilih 0 hingga banyak produk yang ingin dibeli, tetapi produk dapat dipilih untuk dibeli oleh 0 hingga banyak pembeli pada satu jenis produk. 0..* Order > 0..* Pembelian barang Gambar 2.6 Hubungan many-to-many (*:*) Spesialisasi/ Generalisasi (Specialization/Generalization ) Menurut Thomas (Connolly & Begg, 2010, p ),konsep dari spesialisasi dan generalisasi adalah asosiasi tipe entitas dengan tipe entitas khusus yang dikenal sebagai superclass dan subclass, dan proses dari atribut turunan (inheritance).superclass adalah suatu tipe entitas yang mengandung satu atau lebih subgroup terpisah dari suatu occurance, yang dibutuhkan untuk direpresentasikan pada suatu data model. Subclass adalah suatu subgroup terpisah dari occurance suatu tipe entitas, yang dibutuhkan untuk direpresentasikan pada suatu data model Normalisasi Pengertian Normalisasi

36 42 Menurut (Connolly & Begg, 2010, p.401), normalisasi adalah teknik formal untuk mnganalisa relasi berdasarkan pada primary key (atau candidate key) dan functional dependencies Tahapan - tahapan Normalisasi UNF (Un-Normal Form) Menurut (Connolly & Begg, 2010, p.402), proses normalisasi dimulai dari bentuk UNF (Un-Normal Form), yaitu table yang masih mengandung repeating group. Tabel UNF ini dibuat dengan mentransformasi data dari sumber informasi ( seperti formulir ) ke dalam tabel berbentuk baris dan kolom NF (First Normal Form) Menurut (Connolly & Begg, 2010, p403), pada bentuk normal pertama ( First Normal Form 1NF ), sebuah relasi dimana pada setiap sel ( perpotongan baris dan kolom ) jika dan hanya jika mengandung satu nilai, setiap sel mengandung nilai atomik ( single value ). Untuk menjadikan bentuk tidak normal menjadi normal pertama dengan mengidentifikasikan dan menghilangkan repeating groups yang ada di dalam tabel. Repeating group adalah sebuah atau sekumpulan atribut dalam tabel yang memiliki multiple values untuk single occurrence dari atribut key yang terpilih untuk tabel tersebut NF (Second Normal Form) Menurut (Connolly & Begg 2010, p.407), sebuah tabel disebut berada pada bentuk normal kedua ( 2NF ) jika dan hanya jika setiap atribut bukan primary key ( PK ) tergantung sepenuhnya pada PK. Untuk mengetahui apakah 1NF telah berada pada 2NF maka tentukan PK dan funtional dependency NF (Third Normal Form) Menurut (Connolly & Begg, 2010, p.408), sebuah tabel disebut berada pada bentuk normal ketiga jika dan hanya jika tidak

37 43 ada atribut bukan primary key yang bergantung kepada atribut bukan primary key lainnya. Sebuah tabel yang mengandung atribut bukan PK yang tergantung pada atribut PK lainnya disebut transitive dependency. Dengan kata lain sebuah tabel disebut berada pada 3NF jika dan hanya jika tidak mengandung transitive dependency BCNF (Boyce-Codd Normal Form) Menurut (Connolly & Begg, 2010, p.419), suatu relasi dianggap sebagai bentuk normal BCNF jika dan hanya jika setiap determinant adalah candidate key. Untuk mengetahui apakah suatu tabel sudah berada pada bentuk normal BCNF maka harus dilakukan analisa atas functional dependency dari sebuah tabel Teori Activity Diagram Definisi activity diagram menurut (Satzinger, Jackson, & Burd, 2009, p.141), adalah diagram alur kerja yang menggambarkan berbagai kegiatan pengguna atau sistem, orang yang melakukan setiap kegiatan, dan aliran sekuensial dari kegiatan ini. Gambar 2.7 Notasi Activity Diagram (Satzinger, 2009) Notasi notasi dalam activity diagram antara lain: 1. Oval mewakili kegiatan individu dalam sebuah alur kerja. 2. Connecting Arrow mewakili urutan antara kegiatan.