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,
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.
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
2.4.2 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 STATUS KAWIN
JENIS KELAMIN
TANGGAL LAHIR L0033001 Kebon Jeruk Kebon Jeruk Jakarta
Barat
1 1301020353 Mul B L 1990
2 1301020343 Adi S L 1992
L0055001 Joglo Kembangan Jakarta Barat
3 1301065414 Vieta S P 1990
L0172002 Pulo Gadung Pulo Gadung Jakarta Timur
4 1301065976 Sanjaya S L 1991
TPS KELURAHAN KECAMATAN KOTA NO NIK NAMA STATUS KAWIN
JENIS KELAMIN
TANGGAL LAHIR L0033001 Kebon Jeruk Kebon Jeruk Jakarta
Barat
1 1301020353 Mul B L 1990
L0033001 Kebon Jeruk Kebon Jeruk Jakarta Barat
2 1301020343 Adi S L 1992
L0055001 Joglo Kembangan Jakarta Barat
3 1301065414 Vieta S P 1990
L0172002 Pulo Gadung Pulo Gadung Jakarta Timur
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
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.
TPS KELURAHAN KECAMATAN KOTA NIK NAMA STATUS
KAWIN
JENIS KELAMIN
TANGGAL LAHIR
L0033001 Kebon Jeruk Kebon Jeruk Jakarta
Barat
1301020353 Mul B L 1990
L0033001 Kebon Jeruk Kebon Jeruk Jakarta
Barat
1301020343 Adi S L 1992
L0055001 Joglo Kembangan Jakarta
Barat
1301065414 Vieta S P 1990
L0172002 Pulo Gadung Pulo Gadung Jakarta
Timur
Tabel 2. 4 Contoh Normalisasi 3NF TPS NIK L0033001 1301020353 L0033001 1301020343 L0055001 1301025414 L0172002 1301065976
TPS KELURAHAN KECAMATAN KOTA
L0033001 Kebon Jeruk Kebon Jeruk Jakarta Barat L0033001 Kebon Jeruk Kebon Jeruk Jakarta Barat
L0055001 Joglo Kembangan Jakarta Barat
L0172002 Pulo Gadung Pulo Gadung Jakarta Timur
NIK NAMA STATUS
KAWIN
JENIS
KELAMIN TANGGAL LAHIR
1301020353 Mul B L 1990 1301020343 Adi S L 1992 1301065414 Vieta S P 1990 1301065976 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 - -
2.5Entity relationship
Menurut Connolly (2010, p372), entity relationships model ialah pendekatan top-down 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
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.
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.
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 (1:1), one-to-many (1:*), atau one-to-many-to-one-to-many (*:*).
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.
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.
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.
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 :
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.
• 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.
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.
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.
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.
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.
Gambar 2. 10 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
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.
