BAB 2 LANDASAN TEORI 2.1. TEORI UMUM 2.1.1

BAB 2
LANDASAN TEORI
2.1. TEORI UMUM
2.1.1. Data
Data adalah fakta yang dapat disimpan dan memiliki arti (Navanthe, S. dan
Elmasari, R., 2004 : 4). Jadi, dapat disimpulkan bahwa data adalah sekumpulan fakta
yang telah terjadi, memiliki arti, dapat disimpan serta diatur sedemikian rupa sehingga
dapat menjadi suatu form yang dapat digunakan untuk berbagai tujuan. Contoh dari
data, seperti data pegawai, data produk, data pemasok, dll.
2.1.2. Basis Data
Basis data adalah kumpulan berbagai data logika terkait dan deskripsi,
yang dirancang untuk memenuhi kebutuhan informasi organisasi (Connolly, Thomas
and Begg, Carolyn, 2010 : 65).
Basis data mempresentasikan entitas, atribut, dan hubungan relasional antara
entiti-entiti. Entiti merupakan suatu obyek nyata (manusia, tempat, benda, konsep, atau
kejadian) dalam suatu organisasi yang dipresentasikan dalam basis data. Atribut
merupakan suatu properti yang menjelaskan aspek dari obyek yang ingin disimpan.
Hubungan (relationship) merupakan suatu gabungan entiti-entiti dalam basis data.
Basis data adalah kumpulan data yang terorganisir dan secara logika
berkaitan (Jeffrey A. Hoffer, Mary B. Prescott, Heikki Topi, 2009 : 46). Terorganisir
maksudnya adalah data distrukturkan sehingga mudah untuk disimpan, dimanipulasi,
dan diperoleh oleh pengguna.
8
9
2.1.3. Database Management System (DBMS)
Database Management System (DBMS) adalah sebuah sistem perangkat
lunak yang dapat memungkinkan pemakai untuk mendefinisikan, membuat, dan
memelihara database dan menyediakan kontrol akses untuk database tersebut
(Connolly, Thomas and Begg, Carolyn, 2010 : 66).
2.1.3.1 Fasilitas DBMS
1. Data Definition Language (DDL)
Memungkinkan pengguna untuk membuat spesifikasi tipe data, struktur
data, dan batasan pada data yang akan disimpan dalam basis data.
1. Data Manipulation Language (DML)
Memungkinkan pengguna untuk menyisipkan, meng-update, menghapus,
dan menerima data dari basis data.
3. Akses Kontrol
DBMS menyediakan akses kendali penuh ke database, seperti :
i. Sistem keamanan, mencegah pengguna lain untuk mengakses basis
data.
ii. Sistem integritas, menjaga konsistensi data yang tersimpan.
iii. Sistem kontrol konkurensi, mengijinkan akses data untuk diakses
oleh basis data.
iv. Sistem kontrol pemulihan, mengembalikan basis data ke keadaan
yang konsisten dari sebelumnya setelah mengalami kegagalan
perangkat keras atau perangkat lunak.
10
2.1.3.2 Komponen DBMS
Ada lima komponen dalam DBMS menurut Connolly, Thomas and Begg,
Carolyn (2010 : 68), yaitu:
1. Hadware (Perangkat Keras)
Untuk menjalankan DBMS dan aplikasi. Hardware yang
digunakan sesuai dengan kebutuhan dari perusahaan dan DBMS
yang
digunakan.
Untuk
menjalankan
DBMS
memerlukan
kecepatan memori dan kapasitas hardisk tertentu.
2. Software (Perangkat Lunak)
Komponen dari software terdiri dari DBMS itu sendiri, program
aplikasi, dan sistem operasi.
3. Data
Merupakan komponen terpenting dalam DBMS karena sebagai
penghubung antara komponen mesin (Hardware dan Software)
dengan komponen manusia (prosedur dan user).
4. Procedures (Prosedur)
Instruksi dan aturan yang mengatur perancangan dan penggunaan
basis data. Contoh intruksi yang biasa digunakan :
-
Log in ke DBMS.
-
Menggunakan sebagian fasilitas DBMS atau program
aplikasi.
-
Start dan stop DBMS.
-
Membuat salinan basis data.
-
Menangani kesalahan pada hardware dan software.
11
5. People (Manusia)
Ada beberapa jenis atau tipe manusia yang telibat langsung pada
sistem basis data adalah :
a. Data and Database Administrators. Data Administrators
bertanggung jawab untuk pengelolaan sumber daya
termasuk
perencanaan
DBMS,
pengembangan
dan
pemeliharaan standar, kebijakan dan prosedur, dan desain
konseptual/logikal. Database Administrators bertanggung
jawab untuk realisasi fisik dari DBMS, termasuk desain
fisik dan implementasi, keamanan dan kontrol integritas,
serta pemeliharaan sistem operasional.
b. Database Designers. Ada 2 tipe database designers, yaitu
logical
database
designers
dan
physical
database
designers. Logical database designers bersangkutan dengan
mengidentifikasi data, hubungan antar data, dan kendala
pada data. Physical database designers yang merealisasikan
bagaimana desain basis data logikal akan diwujudkan secara
fisik.
c. Application Developers bertanggung jawab atas program
aplikasi yang dibutuhkan oleh end-users.
d. End-Users yaitu klien untuk DBMS. End-users dibagi
menjadi 2 kelas, yaitu :
o
Naïve Users, yaitu pengguna yang tidak berinteraksi
langsung dengan DBMS, mengakses DBMS melalui
12
aplikasi agar bisa menggunakan secara sesederhana
mungkin.
o
Sophisticated Users, yaitu pengguna yang lebih
mengerti
struktur
memungkinkan
DBMS
untuk
dan
fasilitasnya,
menggunakan
bahasa
pemrograman yang lebih tinggi.
2.1.3.3 Keuntungan dan Kerugian DBMS
DBMS memiliki beberapa keuntungan menurut Connolly, Thomas and
Begg, Carolyn (2010 : 77), seperti:
a. Menghilangkan redundancy data
DBMS dapat mengintegrasikan file sehingga data yang sama tidak
tersimpan berulang kali.
b. Meningkatkan keamanan data
Data yang disimpan diberi hak akses bagi pengguna tertentu yang
dapat membuka atau membaca file.
c. Konsistensi data
Dengan berkurangnya redundansi, data juga dapat lebih terjaga
konsistensinya.
d. Meningkatkan integritas data
Validitas dari data yang disimpan merupakan integritas dari suatu
data.
e. Sharing of Data
Data yang disimpan dapat dimiliki oleh perusahaan dan dapat dibagi
kepada semua pengguna yang diberi hak akses.
13
f. Meningkatkan Produktivitas
Deskripsi data dan logika pengaksesan data dibuat ke dalam
beberapa program aplikasi.
g. Improved Backup and Recovery Services
Jika terjadi kesalahan backup data dapat di-restored.
Menurut Connolly, Thomas and Begg, Carolyn (2010 : 80) DBMS
juga memiliki kerugian, seperti:
a. Kompleksitas
Semakin besar dan berat data yang disimpan, file akan semakin
kompleks.
b. Ukuran
Kompleksitas
dan
kedalaman
dari
fungsionalitas
membuat
penggunaan perangkat lunak DBMS semakin besar.
c. Biaya DBMS
Biaya DBMS biasanya berbeda tergantung dari lingkungan yang
disediakan.
d. Biaya penambahan perangkat keras (hardware)
Penyimpanan disk diperlukan bagi DBMS dan basis data akan
memerlukan penambahan tempat penyimpanan.
e. Biaya konversi
Biaya ini termasuk biaya pelatihan staff untuk menggunakan sistem
yang baru.
14
2.1.4. Siklus Hidup Aplikasi Basis Data
Untuk merancang aplikasi sistem basis data diperlukan beberapa tahapan
terstruktur yang harus di ikuti dan dideskripsikan dengan siklus hidup aplikasi data
atau database system development lifecycle atau di singkat dengan SDLC.
Menurut Connolly, Thomas and Begg, Carolyn (2010 : 314), tahapan siklus
hidup aplikasi DBMS tidak selalu berurutan, tetapi melibatkan beberapa jumlah
pengulangan tahap sebelumnya melalui loop feedback. Berikut adalah tahapan dari
database system development lifecycle.
(Sumber : Connolly, Thomas and Begg, Carolyn, 2010 : 314)
Gambar 2.1. Database System Development Lifecycle
15
2.1.4.1. Perencanaan Basis Data
Perencanaan Basis Data menurut Connolly, Thomas and Begg, Carolyn,
2010 : 315) merupakan aktifitas manajemen yang memungkinkan tahap siklus
hidup sistem aplikasi basis data yang akan direalisasikan secara se-efisien dan
se-efektif mungkin. Terdapat 3 hal pokok yang berkaitan dengan strategi
sistem informasi, yaitu:
1.
Identifikasi tujuan dan rencana dari enterprise termasuk
mengenai sistem informasi yang di butuhkan.
2.
Evaluasi sistem informasi yang ada untuk menetapkan
kelebihan dan kekurangan yang dimiliki.
3.
Penilaian
kesempatan
IT
yang
mungkin
memberikan
keuntungan kompetitif.
2.1.4.2. Definisi Sistem
Definisi Sistem menurut Connolly, Thomas and Begg, Carolyn (2010 :
316) adalah menentukan ruang lingkup dan batasan dari sistem basis data,
termasuk pandangan pengguna, dan daerah aplikasi basis data. Pandangan
pengguna mendefinisikan apa yang dibutuhkan pada sebuah aplikasi basis data
dari sudut pandang sebuah jabatan tertentu atau daerah aplikasi basis data.
2.1.4.3. Pengumpulan Kebutuhan dan Analisis
Pengumpulan Kebutuhan dan Analisis menurut Connolly, Thomas and
Begg, Carolyn (2010 : 316), yaitu sebuah proses pengumpulan dan
penganalisaan informasi mengenai bagian-bagian dari sebuah organisasi yang
16
di dukung oleh sistem basis data, dan menggunakan informasi tersebut untuk
medefinisikan kebutuhan pengguna untuk sistem yang baru.
Ada 3 pendekatan untuk mengatur kebutuhan dari sebuah aplikasi basis
data dengan banyak pandangan pengguna, yaitu:
1.
The Centralized Approach (Pendekatan Terpusat)
2.
The view integration Approach (Pendekatan Integrasi
Tampilan)
3.
A Combination Of Both Approach (Kombinasi Dari Kedua
Pendekatan)
Ada beberapa teknik untuk mengumpulkan informasi ini disebut Fact
finding, (Connolly dan Begg, 2010 : 317), yaitu:
a.
Dokumentasi
b.
Wawancara
c.
Observasi
d.
Riset
e.
Kuisioner
2.1.4.4. Desain Database
Desain Database menurut Connolly, Thomas and Begg, Carolyn (2010 :
320) adalah suatu proses menciptakan desain yang akan mendukung pernyataan
misi perusahaan dan tujuan misi untuk sistem basis data yang diperlukan. Ada 3
tahap utama perancangan basis data, yaitu:
1.
Perancangan basis data konseptual
2.
Perancangan basis data logikal
3.
Perancangan basis data fisikal
17
Ada 2 pendekatan perancangan basis data, yaitu :
a.
Bottom-up
b.
Top-down
2.1.4.5. Seleksi DBMS
Pada tahap ini dilakukan pemilihan DBMS yang sesuai dan mendukung
aplikasi basis data. Tahapan dalam memilih DBMS yang tepat menurut
Connolly, Thomas and Begg, Carolyn (2010 : 325), yaitu:
1.
Menerapkan kerangka sebagai referensi.
Untuk menentukan tujuan dan ruang lingkup dari pembelajaran dan
tugas yang harus di kerjakan.
2.
Daftar singkat dari dua atau tiga produk.
Kriteria yang di perlukan untuk keberhasilan dokumentasi
menghasilkan produk DBMS seperti dana yang tersedia, tingkat
dukungan vendor, dan lainnya
3.
Mengevaluasi produk-produk
Tujuan dari evaluasi, menggabungkan beberapa
fitur menjadi
sebuah kelompok.
4.
Merekomendasikan pilihan dan membuat laporan
Mendokumentasikan proses dan menghasilkan pernyataan akan
penemuan dan rekomendasi dari produk DBMS tertentu.
2.1.4.6. Desain Aplikasi
18
Desain Aplikasi menurut Connolly, Thomas and Begg, Carolyn (2010 :
329) adalah desain user interface dan program aplikasi yang digunakan untuk
memproses basis data. Rancangan aplikasi dibagi menjadi 2 aspek yaitu;
1.
Transaction design (Rancangan transaksi)
Suatu tindakan, atau serangkaian tindakan yang dilakukan oleh
single user atau program aplikasi, yang mengakses atau mengubah
isi basis data (Connolly, Thomas and Begg, Carolyn, 2010 : 330).
Ada 3 tipe transaksi, yaitu :
2.
-
Retrieval transactions
-
Update transactions
-
Mixed transactions
User interface design guidelines
-
Meaningful tittle
-
Comprehensive instruction
-
Familiar field tables
-
Consistent use coler
-
Error message for fields
-
Completion signal
2.1.4.7. Model Kerja
Model Kerja menurut Connolly, Thomas and Begg, Carolyn (2010 :
333) adalah membangun suatu model kerja dari aplikasi basis data. Prototipe
harus mempunyai keuntungan utama menjadi murah secara relatif dan cepat
untuk dibangun. Ada 2 jenis strategi prototipe, yaitu :
19
-
Requirement prototyping, mendiktekan persyaratan dari sebuah usulan
system basis data, jika sudah selesai maka prototipe dibuang.
-
Evolutionary prototyping, metode yang sama, namun setelah selesai
prototipe tidak dibuang melainkan dikembangkan
2.1.4.8. Implementasi
Implementasi merupakan relasi fisik dari basis data dan perancangan
aplikasi Connolly, Thomas and Begg, Carolyn (2010 : 333). Implementasi
basis data dilakukan dengan menggunakan data definition language (DDL)
dari DBMS yang terpilih. Bagian dari program ini merupakan transaksitransaksi basis data yang diimplementasikan data manipulation language
(DML).
2.1.4.9. Pengubahan dan Pemuatan Data
Pengubahan dan Pemuatan Data menurut Connolly, Thomas and Begg,
Carolyn (2010 : 334) adalah mentransferkan beberapa data yang ada ke dalam
basis data yang baru dan mengkonversikannya ke beberapa aplikasi yang ada
untuk menjalankannya pada basis data baru tersebut. Langkah ini dibutuhkan
hanya pada waktu sistem basis data yang lama diganti dengan sistem basis
data yang baru. Jika bisa diterapkan, pengembang dapat mengubah dan
menggunakan program aplikasi dari sistem yang lama untuk digunakan oleh
sistem yang baru.
2.1.4.10. Uji Coba
Uji Coba menurut Connolly, Thomas and Begg, Carolyn, 2010 : 334)
adalah proses menjalankan sistem basis data dengan maksud menemukan
20
kesalahan. Pengujian juga harus mencakup kegunaan dari sistem basis data
dan evaluasi harus di lakukan terhadap spesifikasi kegunaannya. Contoh
kriteria yang digunakan untuk evaluasi meliputi:
-
Learnability
-
Performance
-
Robustness
-
Recoverability
-
Adaptibility
2.1.4.11. Perawatan Operasional
Operational maintanace menurut Connolly, Thomas and Begg,
Carolyn (2010 : 335) adalah proses pemantauan dan pemelilharaan instalasi
sistem basis data. Tahap pemeliharaan ini melibatkan 2 kegiatan yaitu :
1. Me-monitor kemampuan dari sistem. Jika kemampuan berada di
bawah tingkat standar, perbaikan basis data diperlukan.
2. Memelihara dan meningkatkan aplikasi basis data. Kebutuhan baru
disatukan kedalam aplikasi basis data melalui tahap-tahap
sebelumnya dari siklus hidup.
2.1.5. Entity Relationship Modeling (ER Model)
ER Model adalah pendekatan top-down untuk merancang basis data yang diawali
dengan mengidentifikasi data penting yang disebut entitas dan relasi antar data yang
harus diwakili dalam model tersebut, (Connolly, Thomas and Begg, Carolyn, 2010 :
371)
21
2.1.5.1. Entity Types (Jenis Entitas)
Sekelompok obyek dengan sifat yang sama, yang diidentifikasi oleh
perusahaan memiliki eksistensi yang independen (Connolly, Thomas and
Begg, Carolyn, 2010 : 372). Konsep dasar ER Model adalah tipe entitas, yang
mewakili sekelompok ‘benda’ di ‘dunia nyata’ dengan sifat yang sama.
2.1.5.2. Relationship Types (Tipe Hubungan)
Sebuah set asosiasi yang bermakna antar jenis entitas, (Connolly,
Thomas and Begg, Carolyn, 2010 : 374). Sebuah tipe relasi adalah set asosiasi
antara satu atau lebih partisipasi tipe-tipe entitas. Seperti tipe-tipe entitas dan
entitas-entitas, perlu membedakan antara istilah “relationship type” dan
“relationship occurence”.
Derajat dari tipe relasi terbagi tiga :
1. Binary, relasi berderajat dua
POwns
PrivateOwner
PropertyForRent
Gambar 2.2. Relasi Berderajat Dua
(Sumber : Connolly, Thomas and Begg, Carolyn, 2010 : 374)
22
2. Ternary, relasi berderajat tiga
Staff
Register
Branch
Client
Gambar 2.3. Relasi Berderajat Tiga
(Sumber : Connolly, Thomas and Begg, Carolyn, 2010 : 374)
3. Quartenary, relasi berderajat empat
Client
Staff
Register
Branch
Client
Gambar 2.4. Relasi Berderajat Empat
(Sumber : Connolly, Thomas and Begg, Carolyn, 2010 : 375)
2.1.5.3. Attribute (Atribut)
Attribute adalah sebuah properti dari entitas atau tipe relasi, (Connolly,
Thomas and Begg, Carolyn, 2010 : 379).
23
Menurut Connolly, Thomas and Begg, Carolyn (2010 : 380) atribut
dapat diklasifikasi menjadi:
1. Simple and Composite Attributes
Sebuah atribut yang terdiri dari komponen tunggal dengan
keberadaan independen.
2. Single-Valued and Multi-Valued Attributes
Sebuah atribut yang memegang nilai tunggal untuk setiap
kemunculan suatu entitas.
3. Derived Attributes
Sebuah atribut mewakili nilai yang diturunkan dari nilai atribut
terkait atau sekumpulan atribut, belum tentu dalam tipe entitas yang
sama.
2.1.5.4. Keys
Menurut (Connolly, Thomas and Begg, Carolyn, 2010 : 381), keys
dibagi menjadi 5 jenis, yaitu :
1. Candidate Keys
Set atribut minimal yang secara unik mengidentifikasi setiap
kemunculan dari tipe entitas.
2. Primary keys
Sebuah candidate key yang dipilih untuk mengidentifikasi secara
unik, tiap kejadian pada sebuah tipe entitas.
3. Composite keys
Sebuah candidate key yang terdiri dari dua atau lebih atribut.
4. Alternate keys
24
Candidate key yang tidak terpililh menjadi primary key, atau biasa
disebut secondary key.
5. Foreign key
Himpunan atribut dalam suatu relasi yang cocok dengan candidate
key dari beberapa relasi lainnya.
2.1.5.5. Strong and Weak Entity Types
Menurut Connolly, Thomas and Begg, Carolyn (2010 : 383), ada entiti
kuat dan lemah, yaitu :
-
Strong Entity Type, adalah entiti yang tidak bergantung pada entiti
lain.
-
Weak Entity Type, adalah entiti yang bergantung pada entiti lain.
2.1.5.6. Structural Constraints
Structural constrain adalah hambatan yang harus mencerminkan
pembatasan pada hubungan seperti yang dirasakan di ‘dunia nyata’, (Connolly,
Thomas and Begg, Carolyn, 2010 : 385) .Tipe utama dari constraints pada
relasi disebut multiplicity. Multiplicity adalah jumlah dari kejadian yang
mungkin, dari suatu entitas yang berelasi dengan suatu kejadian tunggal
sebuah entitas dan terkait suatu relasi tertentu. Multiplicity terdiri atas 3
binary, yaitu:
1. Relasi 1 : 1 (one-to-one) yaitu relasi antar dua tipe entitas dimana
satu tipe entitas berelasi satu dengan tipe entitas lainnya.
25
2. Relasi 1 : * (one-to-many) yaitu relasi antar dua tipe entitas dimana
satu tipe entitas berelasi nol, satu atau banyak dengan tipe entitas
lainnya.
3. Relasi * : * (many-to-many) yaitu relasi antar dua tipe entitas
dimana tipe entitasnya saling berelasi nol, satu atau banyak.
Gambar 2.5. Contoh Tipe Relationship pada Binary
(Sumber : Connolly, Thomas and Begg, Carolyn, 2010 : 314)
Gambar 2.5. Structural Constraint
4. Cardinality dan Participation Constraint
- Cardinality
mendeskripsikan
jumlah
maksimum
dari
kemungkinan kejadian-kejadian yang saling berhubungan untuk
sebuah partisipasi entitas dalam proses
penentuan tipe
relationship.
- Participation adalah menentukan apakah semua kejadiankejadian
entitas
akan
ikut
berpartisipasi
dalam
sebuah
relationship atau hanya beberapa saja yang ikut berpartisipasi.
26
Gambar 2.6. Cardinality dan Participation
(Sumber : Connolly, Thomas and Begg, Carolyn, 2010 : 387)
Gambar 2.6. Cardinality dan Participation Constraint
2.1.6. Metodologi Perancangan Basis Data
Perancangan basis data adalah proses membuat suatu desain yang akan
mendukung pernyataan misi perubahan dan misi obyek untuk kebutuhan sistem basis
data, (Connolly, Thomas and Begg, Carolyn, 2010 : 320) .Dalam perancangan basis
data ada 3 tahapan yang diperlukan guna mendapatkan sebuah basis data yang
diinginkan.
27
2.1.6.1. Perancangan Basis Data Konseptual
Perancangan basis data konseptual adalah untuk memproses pembuatan
suatu model dari informasi yang akan digunakan dalam suatu organisasi, yang
tidak tergantung pada segala pertimbangan fisikal (Connolly, Thomas and
Begg, Carolyn, 2010 : 467).
Langkah 1 : Membuat data konseptual lokal untuk setiap bagian.
Tujuan dari langkah ini adalah untuk membangun suatu model
data konseptual dari perusahaan untuk setiap view yang spesifik.
1.1. : Mengidentifikasi jenis entitas.
Dalam membangun suatu model data konseptual lokal adalah
untuk mendefinisikan obyek utama di mana user memang
membutuhkannya.
1.2. : Mengidentifikasi tipe relasi.
Tujuan dari langkah ini mengidentifikasi relasi yang penting
antara berbagai tipe entity yang telah diidentifikasikan.
1.3. : Mengidentifikasi dan mengasosiasikan atribut suatu entity atau
tipe relasi.
Tujuannya untuk mengidentifikasikan dan mengasosiasikan
atribut dari entity atau tipe relasi.
1.4. : Menentukan domain atribut.
Tujuannya untuk menentukan domain dari atribut yang ada
didalam model data konseptual lokal.
1.5. : Menentukan candidat key, primary key.
28
Tujuannya untuk mengidentifikasikan candidat key dari setiap
tipe entity, dan jika memang terdapat lebih dari satu candidat key,
pilihlah salah satunya untuk menjadi primary key.
1.6. : Menggunakan enhanced modelling concepts (langkah optional)
Tujuannya untuk mempertimbangkan penggunaan enhanced
modelling concepts, seperti specialization, generalization,
aggregation, dan composition.
1.7. : Memeriksa redundansi.
Tujuannya untuk memeriksa apakah ada redundansi dalam model
basis data.
1.8. : Validasi model konseptual lokal dengan transaksi user
Tujuannya
untuk
memastikan
model
konseptual
lokal
mendukung permintaan transaksi oleh user.
1.9. : Memeriksa model data konseptual lokal dengan user
Tujuannya untuk memeriksa model data konseptual lokal
bersama user untuk memastikan bahwa model yang ada sudah
sesuai dengan yang diminta.
29
Gambar 2.7. Contoh Perancangan Basis Data Konseptual
(Sumber : Connolly, Thomas and Begg, Carolyn, 2010 : 480)
2.1.6.2. Perancangan Basis Data Logikal
Perancangan basis data logikal adalah proses pembuatan suatu model
informasi yang di gunakan dalam suatu organisasi berdasarkan model data
yang spesifik tetapi tidak bergantung pada suatu DBMS, dan perangkat keras
lainnya, (Connolly, Thomas and Begg, Carolyn, 2010 : 485).
30
Langkah 2 : Membuat dan memvalidasi model data logikal lokal untuk setiap
bagian
Tujuannya adalah untuk membangun suatu model data logikal dari
suatu model data konseptual yang mempresentasikan perusahaan
dan kemudian memvalidasi model ini untuk memastikan
strukturnya benar, dan memastikan bahwa model tersebut
mendukung transaksi yang di minta.
2.1. : Menghilangkan fitur tidak kompatibel
Tujuannya untuk membangun suatu relasi model data logikal yang
mempresentasikan suatu entity, relasi, dan juga atribut yang telah
diidentifikasi.
2.2. : Validasi model menggunakan normalisasi
Tujuannya untuk memvalidasi relasi dalam model data logikal
dengan menggunakan teknik normalisasi.
2.3. : Validasi relasi terhadap transaksi user
Tujuannya untuk memastikan bahwa relasi di dalam model data
logikal mendukung transaksi yang diminta user.
2.4. : Mendefinisikan kendala Integrity
Tujuannya adalah untuk mendefinisikan batasan-batasan integritas
yang di perlihatkan kepada user, dimana kontrol integritas
mengandung batasan-batasan yang dapat di terapkan untuk
mencegah basis data menjadi tidak konsisten
2.5. : Me-review model data logikal lokal dengan user
31
Tujuannya adalah untuk memastikan
model data logikal dan
dokumentasi yang mendeskripsikan model tersebut sebagai
representasi yang sesuai dengan keadaan yang sebenarnya.
2.6. : Menggabungkan model data logikal menjadi model global
(Optional).
Tujuannya untuk menggabungkan model-model data logikal lokal
individual menjadi sebuah model data logikal global yang
merepresentasikan perusahaan.
2.7. : Memeriksa untuk pertumbuhan ke masa yang akan datang.
Tujuannya untuk menentukan apakah ada perubahan yang penting
di masa yang akan datang dan untuk menilai apakah model data
logikal global dapat mengakomodasi perubahan tersebut.
Gambar 2.8. Contoh Perancangan Basis Data Logikal
(Sumber : Connolly, Thomas and Begg, Carolyn, 2010 : 516)
32
2.1.6.3. Perancangan Basis Data Fisikal
Perancangan basis data fisikal adalah suatu proses untuk menghasilkan
gambaran dari implementasi basis data pada tempat penyimpanan,
menjelaskan dasar dari relasi, organisasi file, indeks yang di gunakan untuk
efisiensi data, dan menghubungkan beberapa integrity constraints dan tindakan
keamanan, (Connolly, Thomas and Begg, Carolyn, 2010 : 521).
Langkah 3 : Menerjemahkan model data logikal ke DBMS (Database
Management Sistem)
Tujuannya untuk menghasilkan skema basis data relational dari
model data logikal yang dapat di implementasikan pada DBMS
pilihan.
3.1. : Mendesain relasi dasar
Tujuannya untuk memutuskan bagaimana merepresentasikan
relasi dasar yang telah di identifikasikan dalam model data
logikal pada DBMS pilihan.
3.2. : Merancang representasi derived data.
Tujuannya memutuskan bagaimana merepresentasikan semua
data turunan pada model data logikal DBMS pilihan.
3.3. : Merancang general constraints
Tujuannya untuk merancang batasan umum pada DBMS pilihan.
Langkah 4 : Desain organisasi file dan index
Tujuannya menentukan pengorganisasian file yang optimal untuk
menyimpan relasi-relasi dasar dan indeks-indeks yang diperlukan
untuk mencapai performansi yang diinginkan, yaitu cara
33
penyimpanan relasi-relasi dan tuples pada media penyimpanan
sekunder.
4.1 : Menganalisis transaksi
Tujuannya untuk mengerti fungsi dari suatu transaksi yang mana
akan dijalankan pada basis data dan untuk menganalisis transaksi
yang penting.
4.2 : Memilih organisasi file
Tujuan dari langkah ini adalah untuk menentukan organisasi file
yang efektif untuk setiap relational data.
4.3 : Memilih indeks
Tujuan dari memilih indeks menentukan penambahan indeks
yang akan meningkatkan performance dari suatu sistem.
4.4 : Memperkirakan kapasitas penyimpanan yang dibutuhkan
Tujuannya untuk mengestimasi ukuran kapasitas disk yang di
perlukan untuk basis data.
Langkah 5 : Desain pandangan pengguna
Tujuan dari langkah ini adalah untuk merancang user view yang
diidentifikasi selama pengumpulan informasi dan analisis dari
siklus hidup aplikasi basis data.
Langkah 6 : Desain mekanisme keamanan
Tujuannya adalah untuk merancang ukuran keamanan untuk
basis data yang telah dispesifikasikan user.
34
2.1.7. Normalisasi
Normalisasi adalah sebuah teknik untuk memproduksi sekumpulan relasi
dengan sifat yang diinginkan yang diberikan persyaratan data dari suatu perusahaan,
(Connolly, Thomas and Begg, Carolyn, 2010 : 416)
Unnormalized Form (UNF) adalah suatu tabel yang terdiri dari satu atau
lebih kelompok yang berulang (repeating group)
(Connolly, Thomas and Begg,
Carolyn, 2010 : 430) Repeating group adalah sebuah atribut atau himpunan atribut di
dalam tabel yang memiliki lebih dari satu nilai untuk sebuah primary key pada tabel
tersebut.
Proses normalisasi terdiri dari 3 tahap yaitu:
1.
First Normal Form (1NF)
Dikatakan 1NF jika atribut setiap baris dan kolom mengandung
satu nilai. 1NF akan terjadi pada sebuah relasi repeating group-nya
yang sudah hilang.
Ada dua cara untuk menghilangkan repeating group pada tabel
yang tidak normal, yaitu :
-
Dengan memasukan data ke dalam kolom yang
kosong dari baris yang mengandung data yang berulang.
-
Dengan menempatkan data yang berulang bersama
dari atribut kunci pada relasi yang terpisah.
2.
Second Normal Form (2NF)
Dikatakan 2NF jika relasi pada 1NF dan setiap atribut yang bukan
primary key fungsional sepenuhnya tergantung pada primary key.
Normalisasi
1NF
berhubungan
penghapusan dependency parcial.
dengan
2NF
melibatkan
35
3.
Third Normal Form (3NF)
Dikatakan 3NF jika relasi berada dalam bentuk 1NF dan 2NF serta
tidak ada atribut yang bukan primary key bergantung secara
transitif terhadap primary key. Normalisasi 2NF berhubungan
dengan 3NF melibatkan penghapusan dependency transitif.
2.2.
TEORI KHUSUS
2.2.1. Flowchart
Flowchart adalah standar yang digunakan oleh analisis sistem untuk
memggambarkan suatu sistem tertentu (Mulyadi, 2001 : 60).
Simbol-simbol yang terdapat dalam flowchart adalah :
Tabel 2.1. Simbol Flowchart
Deskripsi
Input / output
Simbol
Arti
Mempresentasikan input data
yang diproses dan output
data yang telah diproses.
Proses (proccess)
Mempresentasikan operasi
Anak
Mempresentasikan alur kerja
panah
(arrow)
Keputusan
Keputusan dalam program
(decision)
Sub
program
(Predefined
Proccess)
Rincian
operasi
ditempat lain
berada
36
Persiapan
Pemberian harga awal
(Preparation)
Titik
terminal
Awal atau akhir flowchart
(Terminal point)
Dokumen
Input
dan
(Document)
format yang dicetak
Tampilan
Input
(Display)
ditampilkan dimonitor
Penghubung
Penghubung
(Connector)
flowchart dihalaman lain
Manual input
Input
atau
yang
output
output
dalam
yang
bagian-bagian
dimasukkan
secara manual dari keyboard
Operasi
manual
Operasi secara manual
(manual
operation)
Punched tape
Input
atau
menggunakan
output
yang
pita
kertas
berlubang.
2.2.2 Data Flow Diagram (DFD)
Data flow diagram adalah alat yang menggambarkan aliran data melalui sistem
dan kerja atau pengolahan yang dilakukan oleh sistem tersebut (Whitten, JL. and
Bentley, D.L. , 2007 : 317). Terdapat 3 simbol dan satu koneksi DFD yaitu:
37
Tabel 2.2. Simbol Data Flow Diagram (DFD)
GAMBAR
DESKRIPSI
KETERANGAN
Mendefinisikan
seseorang,
sebuah
organisasi,
unit
sistem lain, atau organisasi
Agen Eksternal
lain yang berada di luar
jangkauan
proyek
tetapi
berinteraksi dengan sistem
yang sedang dipelajari.
Inventaris dari data yang
disimpan untuk keperluan
Data Stores
mendatang.
Sinonimnya
adalah file dan database.
Pekerjaan yang dilakukan
pada, atau sebagai respon
Proses
kepada aliran data yang
datang
atau
kondisi.
Sinonimnya yaitu transform.
Mempresentasikan
sebuah
input data ke proses atau
output data dari proses.
Aliran Data
Sebuah aliran data juga
digunakan
mempresentasikan
untuk
38
pembuatan,
penghapusan,
atau update data pada file
atau database.
DFD dibagi menjadi tiga yaitu :
1. Diagram Konteks
Merupakan tingkatan paling pertama yang menggambarkan ruang
lingkup dari sistem yang akan dijalankan. Diagram ini hanya
memiliki
satu
proses
yang
menggambarkan
sistem
secara
keseluruhan dan hubungan antar sistem dengan unit-unit diluar
sistem tersebut.
2. Diagram Nol
Diagram yang menggambarkan proses-proses aliran data yang
terjadi di dalam suatu sistem. Proses-proses ini dapat dipecah
menjadi proses-proses dan aliran data yang lebih terperinci.
3. Diagram Rinci
Diagram yang menggambarkan rincian proses-proses yang ada pada
diagram nol dan proses-proses ini dapat dipecah lagi menjadi
proses-proses yang lebih terperinci.
2.2.3 Entity Relationship Diagram (ERD)
Menurut Connolly, Thomas and Begg, Carolyn (2010: 330) ERD digunakan
untuk menggambarkan struktur logical database dalam bentuk diagram. ERD
menyediakan cara yang sederhana dan mudah untuk memahami berbagai komponen
dalam desain database.
39
ERD mempunyai tiga komponen yaitu :
1. Entity
Entiti merupakan benda yang memiliki identifikasi yang berbeda. Entiti
dapat digambarkan sebagai persegi yang berisi nama dari entiti
tersebut. 16
2. Relationship
Relationship merupakan asosiasi antar entity. Entiti merupakan
pengikut dari relationship. Relationship dapat berupa relasi oneto-one,
one-to-many, many-to-many. Relationship dapat digambarkan dalam
bentuk belah ketupat yang berisi nama dari relasi tersebut.
3. Property
Baik entiti maupun relationship memiliki properti. Setiap nilai dari
properti diambil dari nilai dalam kelompok properti tersebut. Properti
dapat digambarkan dalam bentuk elips yang berisi nama dari properti
tersebut.
2.2.4 State Transition Diagram (STD)
State Transition Diagram (STD) adalah suatu diagram yang menggambarkan
bagaimana suatu proses dihubungkan satu sama lain dalam waktu yang bersamaan,
(Whitten, Jeffery L., Bentley, Lonnie D., and Dittman, K. C., 2004 : 364). STD
digambarkan dengan sebuah state yang merupakan komponen sistem yang
menunjukkan bagaimana kejadian-kejadian tersebut dari satu state ke state lain.
Ada dua macam simbol yang digunakan untuk menggambarkan proses dalam
STD yaitu :
40
1. Persegi panjang yang merupakan state dari sistem
Gambar 2.9. Simbol state persegi panjang dalam STD
2. Gambar panah menunjukkan transisi antar state. Setiap panah diberi
label dengan ekspresi aturan. Label yang diatas menunjukkan
kejadian yang menyebabkan transisi terjadi. Label yang dibawah
menunjukkan aksi yang terjadi akibat kejadian tadi.
Klik Logout
--------------------------------------Kembali ke halaman Login
Kondisi Aksi Reaksi
Gambar 2.10. Simbol state panah dalam STD
2.2.5 Software Tool
2.2.5.1.
SQL Server Management Studio
SQL server management studio adalah program yang dibuat oleh
mikrosoft untuk membantu pengguna maupun admin dalam melakukan tugastugas yang berhubungan dengan server basis data (Wahana Komputer, 2010 :
40). SQL server adalah sistem manajemen basis data relational (RDBMS)
yang dirancang untuk aplikasi dengan arsitektur client/server.
System client server dirancang untuk memisah layanan basis data dari
client, dengan penghubungnya menggunakan jalur komunikasi data.
41
Gambar 2.11. SQL Server Management Studio
2.2.5.2.
C# (C Sharp)
C# adalah sebuah bahasa pemrograman yang dibuat oleh Anders
Hejlsberg, Scott Wiltamuth dan Peter Golde di Microsoft sebagai bagian dari
inisiatif kerangka .NET Framework dan semua produk Microsoft lainnya
(Bishop, Judith & Horspool, Nigel, 2004 : XV).
Bahasa C# juga telah di standarisasi secara internasional oleh ECMA.
Seperti halnya bahasa pemrograman yang lain, C# bisa digunakan untuk
membangun berbagai macam jenis aplikasi, seperti aplikasi berbasis windows
(desktop) dan aplikasi berbasis web serta aplikasi berbasis web services.
Gambar 2.12. C# (C Sharp)