BAB 2 LANDASAN TEORI

Transkripsi

1 8 BAB 2 LANDASAN TEORI 2.1 Pengertian Database Menurut Connolly (2010, p65), database adalah kumpulan data dan deskripsi data yang terhubung secara logika serta dirancang untuk memenuhi kebutuhan informasi untuk suatu organisasi. 2.2 Perancangan Database Menurut Connolly (2010, p466), perancangan database adalah proses untuk menciptakan desain database yang akan mendukung kebutuhan dan tujuan suatu perusahaan. Perancangan database dibagi dalam tiga jenis fase, yaitu : 1. Conceptual Database Design. 2. Logical Database Design. 3. Physical Database Design. Menurut Elmasri dan Navathe (2004, p366), perancangan database adalah merancang struktur logis dan fisik dari satu atau lebih database untuk mengakomodasi kebutuhan informasi pengguna dalam sebuah organisasi untuk satu aplikasi. 2.3 Functional Dependencies Menurut Elmasrie dan Navathe (2004, p304), functional dependencies ialah pembatas antara dua set atribut dari database,

2 9 functional dependencies dibagi menjadi 3, yaitu full functional dependency, partial dependency dan transitive dependency. a. Full Functional Dependency Atribut yang bergantung seluruhnya kepada atribut yang merupakan primary key. b. Partial Dependency Atribut yang bergantung sebagian kepada atribut yang merupakan primary key. c. Transitive Dependency Atribut yang bergantung kepada atribut yang bukan merupakan primary key. 2.4 Normalisasi Menurut Connolly (2010, p428), normalisasi merupakan suatu teknik untuk menghasilkan sekumpulan hubungan dengan properti yang diinginkan, yang memberikan kebutuhan data terhadap suatu perusahaan. Tujuan dari normalisasi adalah sebagai berikut : a. Meminimalkan jumlah atribut yang diperlukan untuk mendukung kebutuhan data dari suatu perusahaan. b. Untuk memperoleh atribut yang bersifat functional dependencies. c. Untuk menghilangkan data yang bersifat redundancy pada tiap atribut.

3 Unnormalized Normal Form (UNF) Menurut Connolly (2010, p430), unnormalized form (UNF) merupakan sebuah tabel yang mengandung satu atau lebih repeating group. Tabel 2. 1 Contoh Normalisasi UNF TPS KELURAHAN KECAMATAN KOTA NO NIK NAMA STATUS JENIS TANGGAL KAWIN KELAMIN LAHIR L Kebon Jeruk Kebon Jeruk Jakarta Mul B L 1990 Barat Adi S L 1992 L Joglo Kembangan Jakarta Barat L Pulo Gadung Pulo Gadung Jakarta Timur Vieta S P Sanjaya S L First Normal Form (1NF) Menurut Connolly (2010, p430), First Normal Form (1NF) merupakan sebuah relasi dimana setiap potongan baris dan kolom mengandung satu dan mungkin hanya satu nilai, dan proses untuk mengubah tabel UNF ke dalam First Normal Form (1NF) adalah dengan cara harus diidentifikasi dan menghilangkan bagian yang mengandung repeating group pada tabel. Tabel 2. 2 Contoh Normalisasi 1NF TPS KELURAHAN KECAMATAN KOTA NO NIK NAMA L Kebon Jeruk Kebon Jeruk Jakarta Barat L Kebon Jeruk Kebon Jeruk Jakarta Barat L Joglo Kembangan Jakarta Barat L Pulo Gadung Pulo Gadung Jakarta Timur STATUS KAWIN JENIS KELAMIN TANGGAL LAHIR Mul B L Adi S L Vieta S P Sanjaya S L 1991

4 Second Normal Form (2NF) Menurut Connolly (2010, p430), Second Normal Form (2NF) dapat dihasilkan dengan cara melihat apakah ada atribut yang bukan merupakan primary key dapat merupakan fungsi dari sebagian primary key (partial dependence). Dalam bentuk normal kedua setiap atribut yang yang bergantung secara parsial harus dipisahkan. Bentuk normal akan diperoleh bila setiap atribut yang bukan merupakan primary key dari suatu tabel secara penuh yang merupakan functional dependence dari primary key itu. Tabel 2. 3 Contoh Normalisasi 2NF TPS KELURAHAN KECAMATAN KOTA NIK NAMA STATUS KAWIN JENIS KELAMIN TANGGAL LAHIR L Kebon Jeruk Kebon Jeruk Jakarta Barat L Kebon Jeruk Kebon Jeruk Jakarta Barat L Joglo Kembangan Jakarta Barat L Pulo Gadung Pulo Gadung Jakarta Timur Mul B L Adi S L Vieta S P Sanjaya S L Third Normal Form (3NF) Menurut Connolly (2010, p430) didalam Third Normal Form (3NF) akan secara langsung dilakukan pengujian dengan cara melihat apakah terdapat atribut bukan key yang bergantung fungsional terhadap atribut yang bukan key yang lain atau disebut (transitive dependence). Dengan cara yang sama, maka setiap transitive dependence harus dipisahkan. Third Normal Form (3NF) dapat dikatakan sudah normal apabila anomali yang ada didalamnya sudah tidak ada, pada kasus tertentu normalisasi dilakukan sampai BCNF.

5 12 Tabel 2. 4 Contoh Normalisasi 3NF TPS NIK L L L L TPS KELURAHAN KECAMATAN KOTA L Kebon Jeruk Kebon Jeruk Jakarta Barat L Kebon Jeruk Kebon Jeruk Jakarta Barat L Joglo Kembangan Jakarta Barat L Pulo Gadung Pulo Gadung Jakarta Timur NIK NAMA STATUS KAWIN JENIS KELAMIN TANGGAL LAHIR Mul B L Adi S L Vieta S P Sanjaya S L 1991 KODE STATUS KAWIN STATUS KAWIN KODE JENIS KELAMIN JENIS KELAMIN B Belum L Laki-laki S Sudah P Perempuan P Pernah Entity relationship Menurut Connolly (2010, p372), entity relationships model ialah pendekatan topdown untuk merancang database yang diawali dengan melakukan identifikasi data penting yang disebut entitas dan relasi antar data yang harus diwakili dalam model itu. Menurut Whitten (2004, p295), entity relationships adalah model data yang menggunakan beberapa notasi untuk menggambarkan data dalam hubugan antara hal

6 13 perusahaan, peserta dan hubungan antara entity dan relationship yang menggambarkan data Pengertian Entity Menurut Connolly (2010, p372), entity types adalah sekelompok obyek dengan sifat yang sama, yang diidentifikasi oleh perusahaan memiliki keberadaan yang bebas. Menurut Whitten (2004, p295), entity adalah kelompok orang, tempat, benda, peristiwa, atau konsep tentang apa yang kita butuhkan untuk menangkap dan menyimpan data. Gambar 2. 1 Contoh Entitas Pengertian Relationships Menurut Connolly (2010, p374), relationship type adalah sekelompok hubungan yang memiliki satu atau lebih entity. Menurut Whitten (2004, p295), relationship adalah asosiasi bisnis alami yang ada antara satu atau lebih entitas.

7 14 Gambar 2. 2 Contoh Relationship Pengertian Attribute Menurut Connolly (2010, p379), attribute adalah properti dari sebuah entity atau sebuah relationship. Atribut dapat diklasifikasikan menjadi beberapa jenis, yaitu : Simple and Composite Attributes Menurut Connolly (2010, p379), sebuah atribut yang terdiri dari komponen tunggal dengan keberadaan yang independen Single-Valued and Multi-Valued Attributes Menurut Connolly (2010, p380), sebuah atribut yang memegang nilai tunggal untuk setiap kemunculan suatu entitas Pengertian Key Menurut Connolly (2010, p381), key terdiri dari beberapa jenis, yaitu: Candidate key Set minimal atribut yang secara unik mengidentifikasi setiap terjadinya suatu tipe entitas, dan dapat mengenali setiap kejadian didalam tipe entity. Candidate key tidak boleh NULL dan setiap entity mungkin punya lebih dari satu candidate key.

8 Primary key Candidate key yang dipilih untuk mengidentifikasi secara unik setiap kejadian atau sebuah tipe entitas Composite key Candidate key yang terdiri dari dua atribut atau lebih. key Alternate key Candidate key yang tidak terpilih menjadi primary key, sama dengan secondary Strong and Weak Entity Menurut Connolly (2010, p383), entitas dapat dibedakan berdasarkan jenisnya, yaitu entitas dengan tipe kuat dan entitas dengan tipe yang lemah. 1. Strong Entity Type, adalah sebuah tipe entitas yang tidak tergantung pada keberadaan beberapa jenis entitas lain. 2. Weak Entity Type, adalah sebuah tipe entitas yang bergantung pada keberadaan beberapa jenis entitas lain Structural Constraints Menurut Connolly (2010, p385), tipe utama dari constraint pada relasi disebut multiplicity. Multiplicity adalah jumlah atau batas dari kejadian yang mungkin dari suatu entitas yang berelasi dengan suatu kejadian tunggal sebuah entitas dan terkait suatu relasi tertentu. Derajat binary merupakan derajat yang paling sering digunakan dalam menentukan relasi. Relasi biner secara umum merujuk pada one-to-one (1:1), one-tomany (1:*), atau many-to-many (*:*).

9 16 Gambar 2. 3 Contoh ERD 2.6 Conceptual Database Design Menurut Connolly (2010, p467) conceptual database design adalah proses membangun model data yang digunakan di dalam suatu perusahaan, bersifat independent dari semua pertimbangan fisikal. Tahap desain konseptual database yang dimulai dengan membuat model data konseptual dari perusahaan dengan rincian implementasi seperti target DBMS, program aplikasi, bahasa pemrograman, hardware platform, performance dan segala pertimbangan fisikal lain nya. Tahapan-tahapan conceptual database design adalah : 1. Mengidentifikasi tipe entitas. 2. Mengidentifikasi tipe relationship. 3. Mengasosiasikan atribut-atribut dengan tipe relationship. 4. Menentukan atribut domain nya.

10 17 5. Menentukan candidate key, primary key, dan alternate key. 6. Sebaiknya menggunakan konsep model yang ditingkatkan. 7. Memeriksa model untuk redundancy. 8. Memvalidasikan konseptual data model terhadap transaksi pengguna. 9. Melakukan review konseptual data model dengan pengguna. Gambar 2. 4 Contoh Konseptual Database Design 2.7 Logical Database Design Menurut Connolly (2010, p467), perancangan basis data logikal adalah proses membangun model data yang digunakan di dalam suatu perusahaan, bersifat independent terhadap DBMS tertentu dan segala pertimbangan fisik lainnya. Tahap desain logikal database yang dimulai dengan membuat maps konseptual database design pada model data logikal, model data logikal merupakan sumber informasi untuk tahapan desain fisikal. Tahapan-tahapan logical database design adalah : 1. Menghilangkan fitur-fitur yang tidak kompatibel dengan model data relasional. 2. Melakukan relasi untuk model data logikal.

11 18 3. Melakukan validasi relasi dengan menggunakan normalisasi. 4. Melakukan validasi terhadap transaksi user. 5. Memeriksa kendala integritas. 6. Melakukan review logikal data model dengan user. Gambar 2. 5 Contoh Logikal Database Design 2.8 Physical Database Design Menurut Connolly (2010, p467) perancangan basis data fisikal adalah proses untuk menghasilkan deskripsi implementasi database pada penyimpanan sekunder (secondary storage) menggambarkan hubungan dasar, organisasi file, dan indeks yang digunakan untuk mendapatkan akses yang cepat terhadap data dan setiap integrity constraints terkait dan langkah-langkah keamanan yang ada. Tahapan-tahapan physical database design adalah : 1. Menerjemahkan model data logikal global sesuai dengan DBMS yang digunakan.

12 19 2. Mendesain repsresentasi atau gambaran dari penurunan data. Contoh query physical database design : CREATE TABLE Pemilih( ID_KTP CHAR(19) PRIMARY KEY NOT NULL, Nama VARCHAR(50) NOT NULL, Tempat_lahir VARCHAR(20), Tanggal_lahir DATE, Jenis_Kelamin VARCHAR(6) NOT NULL, RT INT NOT NULL, RW INT NOT NULL, Kelurahan VARCHAR(20) NOT NULL, Kecamatan VARCHAR(20) NOT NULL, CONSTRAINT cs1 CHECK (LEN(ID_KTP)=19), CONSTRAINT cs2 CHECK (ID_KTP like '[0-9][0-9].[0-9][0-9][0-9][0-9]. [0-9][0-9][0-9][0-9][0-9][0-9]. [0-9][0-9][0-9][0-9]'), ) CREATE TABLE Pemilihan( ID_Pemilihan CHAR(3) PRIMARY KEY NOT NULL, ID_KTP CHAR(19) NOT NULL, ID_calon_kepala_daerah CHAR(3) NOT NULL, Tanggal_voting DATE, Waktu_Voting TIME, FOREIGN KEY ID_KTP REFERENCES Masyarakat ON UPDATE CASCADE ON DELETE CASCADE, FOREIGN KEY ID_calon_kepala_daerah REFERENCES calon_kepala_daerah ON UPDATE CASCADE ON DELETE CASCADE, CONSTRAINT cs7 CHECK (LEN(ID_Voting)=3), CONSTRAINT cs8 CHECK (ID_Voting like 'V.[0-9][0-9].[0-9][0-9].[0-9][0-9][0-9][0-9]'), ) CREATE TABLE calon_kepala_daerah_dan_calon_wakil_ Kepala_daerah( ID_calon_kepala_daerah CHAR(3) PRIMARY KEY NOT NULL, Nama_calon_kepala_daerah VARCHAR(50) NOT NULL, Nama_calon_wakil_kepala_daerah VARCHAR(50) NOT NULL, Tingkat_Pendidikan VARCHAR(10) NOT NULL, Visi VARCHAR(100) NOT NULL, Misi VARCHAR(100) NOT NULL, Foto IMAGE NOT NULL, CONSTRAINT cs3 CHECK (LEN(ID_Calon_Gubernur)=3), CONSTRAINT cs4 CHECK (ID_calon_kepala_daerah like 'G[0-9][0-9]'), ) Aplikasi web harus dibangun dalam arsiektur client-server, ada dua macam jenis arsitektur client-server, yaitu :

13 20 1. Two Tier Client Server Architecture Dalam model client/server, pemrosesan pada sebuah aplikasi terjadi pada client dan server. Client atau server adalah sebuah aplikasi two-tier dengan banyak client dan sebuah server yang dihubungkan melalui sebuah jaringan. Gambar 2. 6 Contoh Two Tier Client Server 2. Three Tier Client Server Architecture Model three-tier dikembangkan untuk menjawab keterbatasan pada arsitektur client/server. Dalam model ini, pemrosesan disebarkan di dalam tiga lapisan. Keuntungan dari Three Tier Architecture ialah : Pemeliharaan aplikasinya terpusat.

14 21 Mudah untuk diganti atau dimodifikasi salah satu tier nya tanpa mempengaruhi yang lainnya. Memisahkan logika bisnis dengan fungsi dari database. Gambar 2. 7 Contoh Three Tier Client Server 2.9 Perancangan Web Database Menurut Eaglestone (2001, p262) pada bagian ini kita menggambarkaan sebuah metode untuk merancang sistem web database. Sistem web database adalah sistem dimana dipadukannya teknologi web dan tekonologi database.

15 22 Pertama yang harus kita lakukan adalah menggambarkan tahap desain database konvensional, namun terdapat dua hal yang harus ditambahkan, yaitu : 1. Web Page Design, hal ini meliputi : a. Menampilkan web data (Web data representation) yaitu mengambil data dari database atau data yang di input user. b. Kumpulan web data (Web data association) yaitu rancangan yang dibuat sedemikian rupa untuk digunakan sebagai petunjuk didalam maupun antara halaman web. c. Desain web antarmuka (Web interface design) yaitu fitur-fitur yang ada dihalam web, termasuk didalamnya penggunaan grafik dan animasi. 2. Perancangan hubungan antara Web Pages dan database a. Web database logical mapping Definisi antara mapping dengan data yang ditampilkan dalam halaman web dan data yang disimpan di dalam basis data. b. Web database physical mapping. Merupakan implementasi dari mekanisme dimana data melewati halaman web dan database. Web database design method merupakan serangkaian model yang menampilkan data yang disimpan kedalam halaman web dengan menambahkan data ke dalam database dengan tujuan untuk menyediakan cara yang sistematis untuk merancang data. Berikut ini merupakan gambar dari web database design method.

16 23 Gambar 2. 8 Contoh Web Database Design (Eaglestone and Ridley, 2001, p264) Tahapan-tahapan dalam web database design yaitu : 1. Requirement Analysis Merupakan proses mengumpulkan dan menganalisis informasi mengenai bagian dari organisasi yang didukung oleh database yang terintegrasi dengan baik dan informasi ini digunakan untuk mengidentifikasi syarat-syarat untuk sistem baru.

17 24 2. Data Analysis Merupakan proses yang menggambarkan kegiatan organisasi yang dalam kaitannya dengan kejadian yang dapat di representasikan dan yang harus disimpan dalam database. 3. Web Data Analysis Merupakan proses mendefinisikan model konseptual dari informasi yang digambarkan didalam halaman web yang berasal dari database, Tujuan dari web data analysis adalah sebagai berikut : Untuk mapping antara informasi yang digambarkan di halaman web dan disimpan ke dalam database. Untuk memeriksa valid atau tidaknya database. Untuk memverifikasi kedetailan suatu design dan implementasi. Untuk menghindari kompleksitas suatu data. Gambar 2. 9 Contoh Konseptual Web Database Design 4. Logical database design Merupakan proses untuk mentranslasikan atau mendefinisikan model data logikal dan mengimplementasikannya ke dalam model konseptual database.

18 25 5. Logical Web Database Design Merupakan proses untuk mendefinisikan struktur data dari halaman web yang aktual, termasuk link didalam suatu halaman web ke halaman yang lain. 6. Physical Database Design. Merupakan fase yang ada didalam proses design, dimana desainer dapat memutuskan bagaimana database dapat disimpan kedalam database management system (DBMS). 7. Physical Web Database design. Merupakan proses pengimplementasian halaman web dan menghubungkannya ke dalam database.

19 26 Gambar Contoh Daftar Pilihan Kandidat 2.10 Prototyping Menurut Connolly (2010, p333) prototyping adalah membangun sebuah model kerja dari aplikasi database, adapun tujuan utama dari prototipe ini adalah untuk mengidentifikasi fitur-fitur yang ada pada sistem agar dapat bekerja dengan baik, atau kekurangan yang ada pada sistem serta memberikan saran untuk peningkatan kerja sistem. Ada dua macam strategi yang ada saat ini, yaitu : 1. Requirements prototyping

20 27 Menggunakan sebuah prototype untuk menentukan kebutuhan-kebutuhan dari aplikasi database yang diusulkan dan ketika persyaratan tersebut dapat dipenuhi, prototype tersebut tidak digunakan lagi. 2. Evolutionary prototype Digunakan untuk tujuan yang sama, namun perbedaan yang signifikan ialah prototipe dapat dikembangkan menjadi suatu aplikasi database.