bab 2 landasan teori - bina nusantara | library...

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

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


1 1301020353 Mul B L 1990


2 1301020343 Adi S L 1992


3 1301065414 Vieta S P 1990


4 1301065976 Sanjaya S L 1991

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.


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


1301020353 Mul B L 1990


1301020343 Adi S L 1992


1301065414 Vieta S P 1990


1301065976 Sanjaya S L 1991

12


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.5 Entity 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

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-to-

many (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 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.

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]. [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 :

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 halaman web dan

menghubungkannya ke dalam database.

26

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

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.

bab 2 landasan teori - bina nusantara | library...

Documents