BAB 2 LANDASAN TEORI

advertisement
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.
Download