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,
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.
10
2.4.1
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
Mul
STATUS KAWIN B
JENIS KELAMIN L
TANGGAL LAHIR 1990
1301020343
Adi
S
L
1992
3
1301065414
Vieta
S
P
1990
4
1301065976
Sanjaya
S
L
1991
TPS
KELURAHAN
KECAMATAN
KOTA
NO
NIK
NAMA
L0033001
Kebon Jeruk
Kebon Jeruk
Jakarta Barat
1
1301020353
2 L0055001
Joglo
Kembangan
L0172002
Pulo Gadung
Pulo Gadung
2.4.2
Jakarta Barat Jakarta Timur
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
Mul
STATUS KAWIN B
JENIS KELAMIN L
TANGGAL LAHIR 1990
1301020343
Adi
S
L
1992
3
1301065414
Vieta
S
P
1990
4
1301065976
Sanjaya
S
L
1991
TPS
KELURAHAN
KECAMATAN
KOTA
NO
NIK
NAMA
L0033001
Kebon Jeruk
Kebon Jeruk
1
1301020353
L0033001
Kebon Jeruk
Kebon Jeruk
2
L0055001
Joglo
Kembangan
L0172002
Pulo Gadung
Pulo Gadung
Jakarta Barat Jakarta Barat Jakarta Barat Jakarta Timur
11
2.4.3
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
L0033001
Kebon Jeruk
Kebon Jeruk
1301020353
Mul
B
L
1990
L0033001
Kebon Jeruk
Kebon Jeruk
1301020343
Adi
S
L
1992
L0055001
Joglo
Kembangan
Jakarta Barat Jakarta Barat Jakarta Barat
1301065414
Vieta
S
P
1990
L0172002
Pulo Gadung
Pulo Gadung
Jakarta Timur
1301065976
Sanjaya
S
L
1991
2.4.4
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.
12 Tabel 2. 4 Contoh Normalisasi 3NF
TPS
NIK
L0033001 L0033001 L0055001 L0172002
1301020353 1301020343 1301025414 1301065976
TPS
KELURAHAN
KECAMATAN
KOTA
L0033001 L0033001 L0055001 L0172002
Kebon Jeruk Kebon Jeruk Joglo Pulo Gadung
Kebon Jeruk Kebon Jeruk Kembangan Pulo Gadung
Jakarta Barat Jakarta Barat Jakarta Barat Jakarta Timur
NIK
NAMA
STATUS KAWIN
JENIS KELAMIN
TANGGAL LAHIR
1301020353 1301020343 1301065414 1301065976
Mul Adi Vieta Sanjaya
B S S S
L L P L
1990 1992 1990 1991
KODE STATUS KAWIN
STATUS KAWIN
KODE JENIS KELAMIN
JENIS KELAMIN
B S P
Belum Sudah Pernah
L P -
Laki-laki Perempuan -
2.5 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
13
perusahaan, peserta dan hubungan antara entity dan relationship yang menggambarkan data. 2.5.1
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
2.5.2
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.
14
Gambar 2. 2 Contoh Relationship
2.5.3
Pengertian Attribute
Menurut Connolly (2010, p379), attribute adalah properti dari sebuah entity atau sebuah relationship. Atribut dapat diklasifikasikan menjadi beberapa jenis, yaitu : 2.5.3.1
Simple and Composite Attributes
Menurut Connolly (2010, p379), sebuah atribut yang terdiri dari komponen tunggal dengan keberadaan yang independen. 2.5.3.2
Single-Valued and Multi-Valued Attributes
Menurut Connolly (2010, p380), sebuah atribut yang memegang nilai tunggal untuk setiap kemunculan suatu entitas. 2.5.4
Pengertian Key
Menurut Connolly (2010, p381), key terdiri dari beberapa jenis, yaitu: 2.5.4.1 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.
15
2.5.4.2 Primary key Candidate key yang dipilih untuk mengidentifikasi secara unik setiap kejadian atau sebuah tipe entitas. 2.5.4.3 Composite key Candidate key yang terdiri dari dua atribut atau lebih. 2.5.4.4 Alternate key Candidate key yang tidak terpilih menjadi primary key, sama dengan secondary key. 2.5.4.5 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. 2.5.4.8 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 (*:*).
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
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.
dan
segala
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.
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.
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].[09][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[09][0-9]'), )
Aplikasi web harus dibangun dalam arsiektur client-server, ada dua macam jenis arsitektur client-server, yaitu :
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.
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.
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.
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.
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.
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
menghubungkannya ke dalam database.
halaman
web
dan
26
Gambar 2. 10 Contoh Daftar Pilihan Kandidat
Prototyping
2.10
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
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.
