bab 2 landasan teori - library.binus.ac.idlibrary.binus.ac.id/ecolls/ethesisdoc/bab2/2009-1-00068-if...
TRANSCRIPT
8
BAB 2
LANDASAN TEORI
2.1 Teori Umum
2.1.1 Pengertian Sistem
Menurut Jogiyanto (1989, p2), sistem adalah kumpulan dari elemen-
elemen yang berinteraksi untuk mencapai suatu tujuan tertentu.
2.1.2 Pengertian Data
Menurut Kadir (1998, p7), data adalah fakta mengenai suatu objek atau
orang. Data dinyatakan dengan nilai (angka, deretan karakter, atau simbol).
Hirarki Data
Menurut Kadir (2000,p8), suatu data dapat diorganisasikan ke dalam
suatu hirarki yang terdiri atas elemen data, record, dan file.
a. Elemen Data
Elemen data merupakan satuan data terkecil yang tidak dapat dipecah lagi
menjadi unit lain yang bermakna. Istilah lain untuk elemen data adalah
field, kolom, item, dan atribut.
b. Record
Record merupakan gabungan sekumpulan elemen data yang saling terkait
satu sama lain. Record biasa disebut dengan istilah tuple atau baris dalam
sistem basis data relasional.
9
c. File
File merupakan himpunan record-record yang bertipe sama. File dapat
pula dikatakan sebagai kumpulan record yang berkaitan dengan suatu
subjek. Dalam sistem basis data relasional, file mewakili komponen yang
disebut tabel atau relasi.
2.1.3 Pengertian Informasi
Menurut Kadir (2000, p7), informasi adalah hasil analisis dan sintesis
terhadap data. Dengan kata lain, informasi dapat dikatakan sebagai data yang
telah diorganisir ke dalam bentuk yang sesuai dengan kebutuhan seseorang,
baik di tingkat staf biasa, manajer, atau siapa saja yang berada dalam suatu
organisasi atau perusahaan.
2.1.4 Pengertian Basis Data
Menurut Connolly & Begg (2002, p14), basis data merupakan suatu
kumpulan data yang secara logika saling berhubungan dan deskripsi dari data
tersebut dirancang untuk memenuhi informasi yang dibutuhkan oleh suatu
organisasi.
Menurut Ramakrishnan (2003, p4) basis data adalah koleksi data yang
secara khusus mendeskripsikan aktivitas 1 atau lebih organisasi yang
berhubungan.
Menurut Kristanto (1993,p1) basis data adalah kumpulan file yang
saling berelasi, relasi tersebut biasa ditunjukkan dengan kunci dari tiap file
10
yang ada. Basis data menunjukkan suatu kumpulan data yang dipakai dalam 1
lingkup perusahaan.
Menurut Kusumo (2003,p2) basis data adalah kumpulan informasi yang
ditulis dalam 1 atau lebih tabel.
Basis Data merupakan suatu kumpulan data yang berhubungan secara
logis, dan deskripsi dari data tersebut, dirancang untuk memenuhi informasi
yang dibutuhkan oleh sebuah organisasi. Artinya Database merupakan tempat
penyimpanan data yang besar, dimana dapat digunakan secara simultan oleh
banyak pengguna. Selain itu Database merupakan suatu objek yang digunakan
untuk menyimpan informasi terstruktur, yang diorganisir dan disimpan dengan
aturan-aturan tertentu sehingga pemakai dapat mengambil informasi tersebut
dengan cepat dan efisien.
Database tidak hanya mengandung data operasional saja, tetapi juga
deskripsi dari data tersebut. Oleh karena itu, sebuah database juga
didefinisikan sebagai self – describing of integrated record. Deskripsi dari data
yang disimpan oleh database dikenal sebagai sistem katalog (data dictionary
atau meta-data). Deskripsi ini menciptakan kebebasan dari program aplikasi
(program - data independence). Pendekatan dengan sistem database, dimana
definisi dari data adalah dipisahkan dari program aplikasi.
2.1.5 Pengertian Sistem Basis Data
Menurut date(2000, p5) sistem basis data pada dasarnya adalah sistem
penyimpanan record yang terkomputerisasi dimana tujuan sebenarnya adalah
penyimpanan informasi dan membuat informasi tersebut selalu tersedia saat
11
dibutuhkan. Keseluruhan sistem terkomputerisasi tersebut memperbolehkan
user atau pengguna untuk menelusuri kembali, dan mengubah informasi
tersebut sesuai kebutuhan.
Sistem basis data memiliki 4 komponen utama, yaitu: data, hardware
(perangkat keras), software (perangkat lunak), dan user. Hardware pada sistem
basis data terdiri dari secondary storage devices (perangkat penyimpanan
sekunder), I/O devices (perangkat input-output), device controllers (pengontrol
peralatan), I/O channel (saluran input-output), database machines (mesin basis
data). Software secara umum berfungsi membantu pengguna basis data untuk
melakukan operasi terhadap data.
2.1.6 Pengertian Basis Data Terdistribusi
Suatu sistem basis data terdistribusi adalah suatu sistem basis data yang
terdistribusi atau direplikasi dalam berbagai bentuk konfigurasi perangkat keras
dan lunak. Pada umumnya, perangkat tersebut ditempatkan di lokasi geografis
yang berbeda di dalam suatu organisasi. Distribusi secara normal dibahas
semata-mata yang berkaitan dengan fragmentasi dan replikasi data. Suatu
fragmen data menghasilkan beberapa subset basis data yang asli. Suatu
replikasi data membuat beberapa salinan dari keseluruhan atau sebagian dari
basis data yang asli.
2.1.6.1 Fragmentasi dan Transparansi
Fragmentasi dan transparansi terkadang berguna untuk
membedakan antara fragmen vertikal dan horizontal di dalam terminologi
12
relasional, sejumlah fragmen berbentuk horizontal dalam suatu subset baris
dari tabel. Skenario di atas bisa diperlakukan sebagai serangkaian tiga
fragmen horizontal dari informasi sumber daya manusia. Sebaliknya, suatu
fragmen vertikal adalah suatu subset kolom tabel. Suatu fragmen vertikal
mungkin berisi data personil, seperti tanggal lahir dan gaji dari setiap
karyawan.
Distribusi data tidak harus terlihat nyata oleh pengguna. Dengan
kata lain, sistem basis data terdistribusi mana pun secara ideal
menampilkan tiga jenis transparansi :
Location transparency. Pengguna tidak perlu be aware terhadap data
lokasi. Independensi lokasi diinginkan karena berguna untuk
menyederhanakan program pengguna dan aktivitas antarmuka. Data
bisa berpindah tempat dari lokasi ke lokasi tanpa validasi program atau
aktivitas apapun. Data bisa berpindah tempat di sekitar jaringan sebagai
jawaban atas perubahan pemakaian atau kebutuhan kinerja.
Fragmentation transparency. Pengguna tidak perlu be aware terhadap
cara pendistribusian data
Replication transparency. Pengguna semestinya tidak perlu be aware
terhadap bagaimana data direplikasi. Replikasi diinginkan karena
kinerja menjadi lebih baik jika aplikasi bisa beroperasi pada salinan
lokal dan ketersediaan menjadi lebih baik, asal sedikitnya satu salinan
yang tinggal tersedia untuk tujuan perolehan kembali (retrieval).
13
2.1.6.2 Aturan Dasar
Tiga jenis transparansi dirancang untuk memenuhi keseluruhan
sasaran dari sistem basis data terdistribusi untuk melihat sebuah sistem
basis data yang tersentralisasi bagi pengguna (Date, 1987). Aturan itu
dikenal sebagai “foundation rule” untuk sistem basis data terdistribusi.
Sejumlah karakteristik dari sistem basis data yang terdistribusi dibangun
berdasarkan kebutuhan untuk memenuhi tiga jenis transparansi.
Local autonomy. Lokasi di dalam sistem basis data yang terdistribusi
adalah otonomi hingga semaksimal mungkin.
No reliance on a central site. Tidak ada kepercayaan atas lokasi
pusat merupakan akibat wajar dari aturan dasar. Demikian juga, hal
itu diinginkan karena kepercayaan pada lokasi pusat bisa
membuktikan suatu capaian kemacetan dan keseluruhan sistem peka
terhadap kegagalan di lokasi pusat.
2.1.6.3 Sistem Basis Data Relasional dan Distribusi
Dorongan ke arah distribusi di dalam arena basis data tidak akan
mungkin ada jika bukan untuk menaikkan pendekatan basis data relasional.
Relasi atau tabel terutama sekali mudah untuk fragmen-bagi dan replikasi.
Proses dari relasi fragmentasi dan replikasi hanya melibatkan penggunaan
operator aljabar relasional atau kalkulus relasional. Fragmentasi vertikal
dilakukan dengan memproyeksikan kolom dari sebuah tabel dengan kunci
utama. Penyusunan ulang fragmen vertikal melibatkan dilakukannya join
menggunakan kunci asli. Fragmentasi horizontal dilakukan dengan
14
pembatasan. Penyusunan ulang fragmen horizontal melibatkan
dilakukannya union. Dalam praktiknya, beberapa kombinasi dari fragmen
vertikal dan horizontal akan dilakukan menggunakan SQL perintah
SELECT. (Lihat Gambar 2.1)
Gambar 2.1 Fragmentasi
Sistem basis data terdistribusi jauh lebih kompleks dibandingkan
sistem tersentralisasi karena faktor saluran komunikasi yang ditambahkan.
Secara garis besar, aktivitas pengolah pusat lebih cepat daripada aktivitas
input/output (I/O) serta aktivitas I/O yang pada gilirannya lebih cepat dari
aktivitas komunikasi. Mengatur lalu lintas selama berkomunikasi secara
efektif memungkinkan suatu sasaran utama dari DBMS bisa terdistribusi.
Oleh karena tindakan tersebut menambahkan kesulitan,
pendistribusian data menjadi tidak mudah. Mengapa organisasi kemudian
melakukan pertimbangan konstruksi dari sistem basis data terdistribusi?
Berikut pertimbangan yang diberikan.
15
Emulating organizational structure. Ini mungkin saja penting untuk
melebihi distribusi geografis dari suatu organisasi dalam kaitannya
dengan sistem data. Jika organisasi bersifat nasional atau multinasional,
sistem komputasi harus menandingi distribusi dari departemen-
departemen, cabang-cabang, dan lain-lain.
Greater control. Kendali yang lebih besar atas data boleh terjadi jika
data dipindahkan ke tempat di mana data tersebut diperlukan.
Greater reliability. Pemelihataraan replikasi data bisa meningkatkan
keandalan sistem. Menempatkan data di mana data tersebut diperlukan
untuk meningkatkan ketersediaan sistem.
Better performance. Tampilan bisa benar-benar meningkat jika
distribusi diterapkan secara bijaksana. Jika kebanyakan query
dikerjakan untuk lokal basis data yang kecil dibandingkan satu pusat
yang besar, maka akses update dan retrieval tampaknya akan
ditingkatakan
Easier growth. Suatu lingkungan yang terdistribusi bisa meningkatkan
kemampuan organisasi untuk memperluas infrastruktur datanya.
2.1.6.4 Jenis-jenis Sistem Basis Data Terdistribusi
Sistem basis data terdistribusi dapat dibedakan menjadi tiga jenis
(Ceri dan Peligatti, 1984) :
Sistem basis data terdistribusi homogen
Suatu sistem basis data terdistribusi homogeny adalah sistem di mana
data terdistribusi antara dua sistem atau lebih. Masing-masing sistem
16
menjalankan DBMS yang sama (contoh : ORACLE). Biasanya, jenis
sistem basis data terdistribusi itu akan berjalan pada jenis perangkat
keras yang sama di bawah sistem operasi yang sama dengan DBMS
yang sama pula.
Sistem basis data heterogen
Suatu sistem basis data terdistribusi heterogen adalah sistem di mana
konfigurasi perangkat keras dan lunaknya berbeda. Suatu lokasi bisa
menjalankan ORACLE di bawah Windows NT, lokasi Informix di
bawah UNIX, dan Ingres di bawah Windows NT. Kini, cara yang
utama di mana heterogen dicapai adalah melalui konsep suatu gateway.
Suatu gateway adalah suatu antarmuka dari satu DBMS ke DBMS
lainnya, yang pada umumnya disediakan oleh penjual DBMS tertentu.
Sistem basis data federasi (multi-database)
Gagasan dari federasi mengenai sistem basis data terdistribusi,
terkadang dikenal sebagai multi-basis data, adalah serupa untuk model
politis dari suatu federasi. Suatu Negara seperti Switzerland terdiri atas
sejumlah unit politik otonomi. Adakalanya seperti unit yang akan
datang bersama-sama untuk membuat keputusan di tingkat nasional.
2.1.7 Persediaan
Fungsi dan Manfaat Persediaan :
Mengatasi risiko keterlambatan pengiriman
Mengatasi risiko kesalahan pengiriman
Mengatasi risiko kenaikan harga
17
Mengatasi ketergantungan pada musim
Mendapatkan keuntungan dari pembelian
Untuk melayani konsumen dengan lebih baik
Kelangsungan operasional perusahaan
Pengelompokkan Persediaan :
Fluktuation Stock
Anticipation Stock
Lot-Size Inventory
A. Metode Lot for Lot (LFL)
B. Metode Part Period Balancing (PPB)
C. Metode Periode Order Quantity (POQ)
Pipeline Inventory
Persediaan ABC
Secara umum dapat dikatakan bahwa pengelompokkan persediaan ABC
didasar pada pemahaman bahwa, dalam perusahaan ada item persediaan
yang meskipun jumlahnya tidak panyak, namun nilainya tinggi (A), dan
sebaliknya ada item persediaan yang jumlahnya sangat banyak namun tidak
besar (C), dan diantara itu dikelompokkan dalam kelompok B
Pengendalian Persediaan :
Metode Lot Sizing
a. Waktu Tenggang (Lead Time)
18
Perbedaan / selisih waktu antara saat pesan dengan kedatangan barang
yang dipesan. Waktu tunggu ini biasanya dipengaruhi oleh :
1. Ketersediaan Barang di pemasok
2. Jarak pengiriman
3. Transportasi, jenis dan kondisi yang ada
Persediaan Pengamanan / Safety Stock / Buffer Stock / Iron Stock
Persediaan cadangan selama Lead Time / Waktu Tenggang
Titik Pemesanan Kebali (Re-Order Point) / ROP
Saat dimana pemesanan harus dilakukan kembali sedemikian rupa
sehingga kedatangan barang tepat waktu
Penentuan Nilai Safety Stock (Persediaan Minimum)
Model Expected Value
Inti dari model ini adalah dengan mencari expected value dari biaya
kekurangan persediaan dan biaya simpan (biasanya kedua biaya ini sudah
diketahui sebelumnya) terendah dari berbagai tingkat safety stock.
Expected Value biaya kekurangan persediaan
Inti dari model ini adalah dengan melihat biaya kekurangan persediaan,
nilai safety stock, dan biaya simpan untuk safety stock.
Perhitungan biaya kekurangan dan biaya simpan
Inti darii model ini adalah perusahaan menetapkan jumlah safety stock
19
Penentuan Nilai Safety Stock (Persediaan Minimum) dengan Nilai
distribusi Normal
Inti dari model ini adalah dengan mensyaratkan biaya kekurangan dan
simpan
2.2 Teori Khusus
2.2.1 Model data relational
Model data relational dibangun berdasarkan konsep matematika dari
relation yang direpresentasikan secara fisik sebagai tabel.
2.2.1.1 Struktur data relational
a. Relation adalah tabel yang memiliki baris dan kolom.
b. Attribute adalah kolom dari suatu relation yang memiliki nama.
c. Domain adalah kumpulan dari nilai-nilai yang diperbolehkan bagi suatu
attribute pada relation.
d. Tuple adalah suatu baris yang ada pada relation.
e. Degree dari suatu relation adalah banyaknya attribute yang ada pada
relation tersebut.
f. Cardinality adalah banyaknya tuple yang ada pada suatu relation.
g. Relational database adalah kumpulan relation yang telah dinormalisasi
serta memiliki nama yang berbeda-beda.
20
2.2.1.2 Kunci Relational
a. Simple key adalah atribut yang tidak dapat dipecah lagi menjadi
attribute yang lebih sederhana.
b. Composite key adalah attribute yang bisa terdiri dari beberapa attribute.
c. Super key adalah sebuah attribute atau kumpulan attribute yang
mengidentifikasikan suatu tuple secara unik pada suatu relation .
d. Candidate key adalah super key yang tidak memiliki bagian yang juga
dapat menjadi super key pada suatu relation.
e. Primary key adalah candidate key yang dipilih untuk
mengidentifikasikan sebuah tuple secara unik dalam suatu relation.
f. Foreign key adalah atribut atau kumpulan atribut didalam suatu relation
yang cocok dengan candidate key dari beberapa relation yang lain.
2.2.1.3 Relational Integrity
a Null
Merepresentasikan nilai suatu atribut yang pada saat ini tidak diketahui,
atau tidak tersedia untuk tuple yang bersangkutan .
b Entity Integrity
Pada sebuah relation, tidak boleh ada atribut yang merupakan primary
key bernilai null.
c Referential Integrity
Jika terdapat foreign key pada sebuah relation maka foreign key
tersebut harus memiliki nilai yang cocok dengan nilai candidate key
pada relation asalnya atau foreign key tersebut harus bernilai null.
21
2.2.2 Database Management System (DBMS)
Menurut Connolly dan Begg (2002, p16), DBMS adalah suatu sistem
piranti lunak yang memungkinkan user untuk mendefinisikan, membuat,
memelihara, dan mengontrol akses ke database. Menurut Silberschatz (2002,
p21), DBMS terdiri dari sebuah koleksi data dan program-program yang
mengakses data tersebut. Menurut Post (2002, p2), DBMS adalah piranti lunak
yang mendefinisikan basis data, menyimpan data, mendukung query,
menghasilkan laporan, dan membuat layer entry data.
Pada umumnya DBMS menyediakan fasilitas-fasilitas berikut :
1. Fasilitas bagi user untuk mendefinisikan database, umumnya melalui data
definition language (DDL). DDL memperbolehkan user untuk
menspesifikasikan tipe data, struktur, serta constraints dari data yang akan
disimpan di database.
2. Fasiltas bagi user untuk melakukan insert, update, delete serta retrieve
terhadap data yang ada di database, umumnya melalui data manipulation
language (DML)
3. Menyediakan akses yang terkontrol ke database, misalnya DBMS
menyediakan :
a. Security System : berfungsi mencegah user yang tidak memiliki ijin
mengakses database.
b. Integrity System : berfungsi mempertahankan konsistensi dari data
yang tersimpan.
c. Conccurrency Control System : berfungsi menyediakan akses yang
tersebar.
22
d. Recovery Control System : berfungsi untuk me-restore database ke
keadaan konsisten sebelumnya, setelah terjadinya kesalahan atau error.
e. User Accessible Catalog : menyimpan deskripsi dari data yang ada di
database.
2.2.3 Database Application Lifecycle
Database Application life cycle merupakan komponen yang penting
dalam sistem basis data karena aplikasi dari database life cycle berkaitan
dengan sistem informasi yang ada. Langkah – langkah dari database life cycle
dapat dilihat pada gambar 2.2 berikut :
23
Gambar 2.2 Diagram Database Application Lifecycle
Sumber : Database System, Connolly, Figure 9.1 Page 272
Berdasarkan (Connolly, 2002, p272). Database Application Lifecycle
terdiri dari langkah-langkah berikut :
24
2.2.3.1 Database Planning
Aktivitas-aktivitas manajemen yang memungkinkan tahap-tahap
pengembangan aplikasi database untuk diwujudkan secara efektif dan
efisien. Perencanaan database (database planning) harus terintegrasi
dengan keseluruhan strategi sistem informasi dari organisasi atau
perusahaan yang bersangkutan perencanaan database (database planning)
perlu juga meliputi pengembangan standard yang mengurus/memerintah
bagaimana data akan dikumpulkan, bagaimana format harus ditetapkan,
dokumentasi apa saja yang akan diperlukan, dan bagaimana rancangan
dan implementasi dapat diproses. Dalam merancang suatu standard yang
baik harus menyediakan suatu basis untuk staff pelatihan dan mengukur
pengendalian mutu (quality), dan dapat memastikan bahwa pekerjaan yang
ada menyesuaikan diri kepada suatu pola teladan, tanpa tergantung dengan
keterampilan dan pengalaman staff.
2.2.3.2 System Definition
Menurut Connolly (2002, p274), system definition adalah
menentukan ruang lingkup dari aplikasi basis data (database) yang akan
dibuat termasuk user dan tempat dimana aplikasi basis data tersebut
diterapkan. Sebelum mencoba untuk merancang suatu aplikasi basis data,
adalah penting bahwa kita pertama mengidentifikasi batasan-batasan sistem
yang ada dan bagaimana sistem tersebut dapat menghubungkan dengan
bagian lain yang terdapat dalam sistem informasi organisasi / perusahaan.
25
2.2.3.3 Requirement Collection and Analysis
Proses mengumpulkan dan menganalisis informasi tentang bagian
dari organisasi yang di-support oleh aplikasi database dan menggunakan
informasi ini untuk mengidentifikasi kebutuhan user terhadap sistem
yang baru. Tahapan ini meliputi pengumpulan dan analisa informasi
tentang bagian dari perusahaan yang dilayani oleh database. Ada banyak
cara untuk memperoleh informasi ini yang disebut dengan teknik fact
finding (Connolly, 2002, p276):
Examining documentation
Dokumentasi membantu menyediakan informasi pada bagian dari
perusahaan berkaitan dengan masalah yang dihadapi.
Interviewing
Dengan wawancara dapat diperoleh informasi dari individu-individu
secara langsung face to face. Ada beberapa tujuan dalam menggunakan
interview seperti menemukan fakta, verifikasi, klarifikasi, menampilkan
antusiasme, melibatkan end-user, identifikasi kebutuhan dan memperoleh
ide dan opini atau pendapat.
Questionnaires
Kuisioner adalah dokumen dengan tujuan khusus untuk mengumpulkan
fakta-fakta dari sejumlah orang. Manakala kita ingin mengumpulkan
informasi dari orang banyak teknik yang paling efisien adalah kuisioner.
26
Research
Salah satu teknik fact-finding yang berguna adalah melakukan riset
terhadap aplikasi dan masalahnya. Majalah-majalah, komputer, buku-
buku petunjuk dan internet merupakan sumber-sumber informasi yang
bagus. Mereka dapat menyediakan informasi, tentang bagaimana orang
lain memecahkan masalah yang serupa.
Observing The Enterprise In Operation
Pengamatan merupakan salah satu teknik fact-finding yang paling efektif
untuk memahami sebuah sistem. Teknik ini memungkinkan untuk
berpartisipasi atau mengawasi seseorang dalam beraktivitas untuk
mempelajari tentang sistem.
2.2.3.4 Database design
Perancangan basis data dimulai ketika analisis terhadap kebutuhan
perusahaan telah dilakukan. Di dalam perancangan basis data terdapat suatu
metodologi yang membantu dalam membuat suatu basis data. Yang
dimaksud dengan metodologi perancangan basis data adalah sebuah
pendekatan struktur yang mencakup prosedur, teknik, alat bantu dan tujuan
dokumentasi untuk mendukung dan memberi sarana dalam proses
perancangan itu sendiri. Metodologi perancangan basis data terdiri dari
tahap-tahap yang membantu para perancang dengan teknik yang tepat
dalam setiap merancang basis data. Metodologi perancangan basis data
juga membantu perancang untuk merencanakan, mengatur dan
27
mengevaluasi pengembangan dari proyek pembuatan basis data (database)
tersebut (Connolly, 2002, p419).
Perancangan database terdiri dari 3 tahap :
1. Perancangan database tahap konseptual
2. Perancangan database tahap logical
3. Perancangan database tahap physical
2.2.3.5 DBMS Selection
Pemilihan DBMS (Database Management System) dilakukan untuk
memilih DBMS yang cocok atau sesuai dengan aplikasi basis data yang
dibuat. Bagaimanapun pemilihan DBMS bisa dilakukan pada setiap waktu
sebelum melakukan logical design yang menyajikan informasi cukup
mengenai kebutuhan sistem seperti performance, security, integrity
constraints. Walaupun pemilihan DBMS mungkin jarang, tetapi ketika
kebutuhan perusahaan sedang diperluas atau sistem yang berjalan
digantikan, mungkin menjadi perlu kadang-kadang untuk mengevaluasi
produk DBMS yang baru. Suatu pendekatan sederhana dalam melakukan
pemilihan DBMS adalah dengan mencocokkan DBMS dengan kebutuhan.
2.2.3.6 Application Design
Perancangan user menghubungkan program aplikasi yang
menggunakan dan memproses basis data tersebut (Connolly, 2002, p287).
Mengamati desain aplikasi dan basis data itu adalah aktivitas parallel pada
aplikasi basis data life cycle. Sebagai tambahan terhadap perancangan
28
bagaimana kemampuan yang diperlukan (diharapkan) untuk dicapai, kita
harus mendesain seorang pemakai yang sesuai untuk menghubungkan ke
aplikasi basis data tersebut. Alat penghubung ini menyajikan informasi
yang diperlukan sehingga mudah dioperasikan.
2.2.3.7 Prototyping
Suatu prototype adalah suatu model aplikasi basis data yang
mempunyai semua corak yang diperlukan dan menyediakan semua
kemampuan sistem. Tujuan utama mengembangkan suatu aplikasi basis
data prototype adalah mengizinkan para pemakai untuk menggunakan
prototype itu untuk mengidentifikasi corak sistem yang bekerja dengan
baik dan jika mungkin untuk meningkatkan corak baru kepada aplikasi
basis data. Dengan cara ini, kita dapat memperjelas kebutuhan pemakai dan
pengembang sistem dan mengevaluasi kelayakan desain sistem tertentu.
2.2.3.8 Implementation
Menurut Connolly (2002, p292), implementasi merupakan
perwujudan fisik dari basis data dan desain aplikasi. Implementasi basis
data dicapai dengan menggunakan Data Definition Language (DDL) atau
dengan menggunakan Graphical User Interface (GUI), yang menyediakan
fungsional yang sama dengan pernyataan (statement) DDL yang low-level.
Program aplikasi diterapkan dengan menggunakan bahasa generasi
keempat atau ketiga yang lebih disukai ( 3GL atau 4GL). Bagian dari
program aplikasi ini adalah transaksi basis data, yang diterapkan dengan
29
menggunakan Data Manipulation Language (DML). Transaksi basis data
juga dapat dibuat dalam bahasa pemrograman, seperti Visual Basic, C,
C++, Java, COBOL, Fortran, Ada, atau Pascal.
2.2.3.9 Data Conversion And Loading
Menurut Connolly (2002, p293), pemindahan data yang ada ke
dalam basis data yang baru dan mengubah aplikasi yang sedang berjalan
agar dapat digunakan dalam basis data yang baru. Kegunaan yang pada
umumnya memerlukan spesifikasi sumber file dan target basis data dan
kemudian secara otomatis mengkonversi data itu kepada format yang
diperlukan basis data yang baru.
2.2.3.10 Testing
Menurut Connolly (2002, p293), testing adalah suatu proses
melaksanakan program aplikasi dengan tujuan menemukan kesalahan.
Sebelum diterapkan dalam suatu sistem , basis data harus dilakukan
pengujian (testing) terlebih dahulu.
2.2.3.11 Operational Maintenance
Dalam langkah-langkah yang sebelumnya, aplikasi basis data
telah secara penuh diterapkan dan di uji. Sistem sekarang pindah ke suatu
langkah pemeliharaan sistem seperti melakukan backup data untuk
mencegah kehilangan data.
30
2.2.4 Metodologi Perancangan Database
Merupakan suatu pendekatan yang bersifat terstruktur yang mencakup
prosedur, teknik, alat bantu dan tujuan dokumentasi untuk mendukung dan
memberi sarana dalam proses itu sendiri. Perancangan basis data dibagi atas
tiga bagian, yaitu :
2.2.4.1 Conceptual database design
Langkah awal dalam conceptual database design adalah dengan
membuat model data secara konseptual dari perusahaan yang bersangkutan.
Langkah-langkah di atas melibatkan komponen-komponen
sebagaimana diperlihatkan pada gambar berikut ini:
Gambar 2.3 Komponen-komponen pada perancangan basis data konseptual
31
Langkah 1 Membuat model data konseptual untuk setiap View.
Model data konseptual didukung oleh dokumentasi, meliputi kamus data
yang dihasilkan selama pengembangan model. Langkah -langkah panduan
dalam perancangan basis data konseptual sebagai berikut (Connolly, 2002,
p422) :
Langkah 1.1 Mengidentifikasi tipe Entity.
Mengidentifikasikan tipe Entity utama yang diperlukan oleh view. Salah
satu metode untuk mengidentifikasi Entity adalah dengan menguji
spesifikasi kebutuhan user.
Langkah 1.2 Mengidentifikasi tipe relasi.
Setelah mengidentifikasikan Entity, selanjutnya adalah mengidentifikasi
semua relasi yang ada antar Entity. Salah satu metode yang digunakan
ketika mengidentifikasi Entity, adalah dengan menggunakan struktur
kalimat pada spesifikasi kebutuhan user. Biasanya relasi ditandai
dengan kata kerja.
Langkah 1.3 Mengidentifikasi dan mengasosiasikan atribut dengan
Entity atau relationship types.
Dengan cara yang sama dalam mengidentifikasi Entity, dilakukan
pencarian kata benda dalam spesifikasi kebutuhan user. Atribut bisa
diidentifikasi dimana kata benda tersebut memiliki nilai, kualitas,
identifier, atau karakteristik dari satu Entity atau hubungan. Dalam
menentukan atribut harus mampu mengidentifikasi atribut sederhana
32
atau komposit, single-valued atau multi-valued dan turunan. Setelah
atribut diidentifikasi, diperlukan dokumentasi setiap atribut yang terdiri
atas :
Langkah 1.4 Menentukan atribut domain
Tujuan dari langkah ini adalah menentukan domain dari semua atribut
dalam model. Sebuah domain adalah satuan data yang dapat dipakai
oleh satu atau lebih atribut.
Langkah 1.5 Menentukan atribut candidate key dan primary key
Langkah ini dilakukan untuk mengidentifikasi candidate key untuk
sebuah Entity dan kemudian memilih salah satu sebagai primary key
(Connolly, 2002, p431). Ketika memilih primary key dari sejumlah
candidate key dapat menggunakan pedoman - pedoman untuk
membantu membuat pilihan :
a Candidate key dengan jumlah atribut yang minimal
b Candidate key yang perubahan nilainya sedikit
c Candidate key dengan karakter paling sedikit (untuk kunci
candidate dengan atribut tekstual)
d Candidate key dengan nilai maksimum terkecil (untuk kunci
candidate dengan atribut numerik);
e Candidate key yang paling mudah digunakan dari sudut pandang
user.
33
Langkah 1.6 Mempertimbangkan kegunaan dari konsep model
lanjutan (optional step)
Pada langkah ini, terdapat pilihan untuk melanjutkan pengembangan
model ER menggunakan konsep pemodelan lanjut yang dinamakan
spesialisasi / generalisasi, aggregasi, dan komposisi.
Generalisasi / spesialisasi
Konsep dari generalisasi dan spesialisasi dihubungkan dengan tipe-
tipe Entity khusus, yaitu superclass dan subclass, dan proses
pewarisan atribut turunan (Connolly,2002,p360). Dimana superclass
merupakan induk dari beberapa kelompok-kelompok berbeda
keberadaannya pada suatu tipe Entity sedangkan subclass merupakan
kelompok bagian yang distinct dari suatu tipe Entity.
Spesialisasi merupakan proses memaksimalkan perbedaan-perbedaan
yang ada diantara anggota dari sebuah Entity dengan mengidentifikasi
perbedaan-perbedaan karakteristik yang ada. Spesialisasi merupakan
pendekatan top-down untuk mendefinisikan sebuah kumpulan dari
superclass dan hubungannya dengan subclass-subclassnya, dimana
kumpulan subclass dibasiskan pada beberapa perbedaan karakteristik.
Sebagai contoh setiap pekerjaan biasanya mempunyai jabatan atau
job roles tertentu seperti manajer, sekretaris, maupun sales. Jadi dapat
dianggap manajer, sekretaris dan sales merupakan spesialisasi dari
pegawai.
34
Generalisasi merupakan proses memimalisasi perbedaan-perbedaan
antar Entity yang ada dengan mengidentifikasi persamaan-persamaan
karakteristiknya. Generalisasi merupakan pendekatan bottom-up.
Terdapat dua constraints yang mungkin digunakan dalam generalisasi
/ spesialisasi yaitu (Connolly,2002,p366) :
Participation constraint, constraint ini menentukan apakah setiap
anggota dari superclass harus berpartisipasi sebagai anggota dari
sebuah subclass. Terdapat dua kemungkinan yaitu:
- Mandatory, dimana setiap anggota superclass harus menjadi
anggota dari subclass.
- Optional, dimana tidak setiap anggota superclass harus
menjadi anggota subclass.
Disjoint Constraint, constraint yang menjelaskan hubungan antar
anggota dari subclass dan mengindikasikan apakah
memungkinkan untuk seorang anggota dari superclass menjadi
anggota dari satu atau lebih dari satu subclass. Terdapat dua
kemungkinan yaitu:
- Or, dimana setiap anggota superclass hanya boleh menjadi
salah satu anggota subclass.
- And, dimana setiap anggota superclass boleh menjadi anggota
lebih dari satu subclass.
35
Agregasi
Agregasi merupakan representasi dari sebuah relasi mempunyai
sebuah (‘has-a relationship’) atau merupakan bagian dari (‘is-part-of
relationship’) diantara tipe-tipe Entity, dimana salah satu
direpresentasikan sebagai keseluruhan (‘Whole’) dan yang lainnya
menjadi bagian (‘Part’). Dalam agegrasi ‘whole’ merupakan
representasi dari Entity yang lebih besar yang mengandung Entity
yang lebih kecil ‘Part’.
Komposisi
Komposisi merupakan bentuk spesifik dari agegrasi yang
merepresentasikan sebuah hubungan antar Entity, dimana terdapat
kepemilikan yang kuat selamanya diantara ‘whole’ dan ‘part’. Pada
compotition, ‘whole’ bertanggung jawab atas penempatan dari ‘part’,
yang berarti bahwa compotiton harus mengatur penciptaan dan
penghilangan dari ‘part’nya. Dengan kata lain, sebuah objek hanya
boleh menjadi bagian dari sebuah compotition pada suatu waktu.
Langkah 1.7 Memeriksa redundansi pada model
Pada tahap ini, dijelaskan model data konseptual lokal dengan
menspesifikasi objektivitas dari pengidentifikasian, bila terdapat
redundansi yaitu duplikasi data atau data yang berulang dapat dibuang.
36
Langkah 1.8 Validasi model konseptual lokal terhadap transaksi
user.
Tujuan dari langkah ini adalah untuk mengecek model, agar
meyakinkan bahwa model yang mendukung transaksi diperlukan oleh
view.
Langkah 1.9 Mengkaji ulang model data konseptual lokal dengan
user.
Dilakukan pengkajian ulang model data konsep lokal dengan user
untuk memastikan bahwa model data yang dihasilkan, merupakan
representasi yang benar dari view.
2.2.4.2 Logical database design
Dalam logical database design, model data yang telah diperoleh
dalam conceptual database design diubah dalam bentuk logical model,
dimana data yang ada dipengaruhi oleh model data yang menjadi tujuan
basis data. Hal ini dilakukan untuk menerjemahkan representasi konseptual
ke dalam bentuk struktur logic dalam basis data. Logical data model
merupakan sumber informasi dalam merancang physical database. Logical
database design memberikan sarana yang membantu para perancang dalam
merancang physical database.
37
Langkah 2 Membangun dan validasi model data logikal lokal untuk
setiap view
Untuk membangun model data logikal lokal dari model data konseptual
lokal, merepresentasikan view tertentu dari organisasi dan kemudian
memvalidasi model ini untuk meyakinkan strukturnya benar menggunakan
teknik normalisasi serta untuk meyakinkan model akan mendukung
transaksi yang diperlukan.
Langkah 2.1 Menghilangkan fitur-fitur yang tidak sesuai dengan
model relasional (optional step)
Keobjektivitasan dari langkah ini adalah untuk :
- Menghilangkan many – to – many (*:*) Binary Relationship Types
Jika relasi banyak-ke-banyak (*:*) terdapat pada model data
konseptual, dapat dilakukan dekomposisi relasi ini untuk
mengidentifikasi Entity lanjutan. Relasi (*:*) diganti dengan dua
relasi satu-ke-banyak (1:*) untuk Entity yang baru diidentifikasi
tersebut.
- Menghilangkan tipe relasi many – to – many (*:*) rekursif
Jika relasi rekursif (*:*) terdapat pada model data konseptual, dapat
dilakukan dekomposisi relasi ini untuk mengidentifikasi Entity
lanjutan.
- Menghilangkan tipe relasi kompleks
Relasi kompleks merupakan relasi antara tiga atau lebih tipe relasi.
Jika relasi kompleks direpresentasikan dalam model data konseptual,
38
dapat dilakukan dekomposisi relasi untuk mengidentifikasi Entity
lanjutan. Relasi kompleks diganti dengan sejumlah relasi satu-ke-
banyak (1:*) untuk Entity yang baru diidentifikasi tersebut.
- Menghilangkan atribut multi-valued
Jika terdapat atribut multi-valued pada model data konseptual, dapat
dilakukan dekomposisi atribut untuk mengidentifikasi sebuah Entity.
Langkah 2.2 Menurunkan relasi untuk model data logikal lokal
Pada langkah ini, dilakukan penurunan relasi untuk model data logikal
lokal untuk merepresentasikan Entity, relasi, dan atribut yang
didefinisikan pada view.
- Tipe Strong Entity
Untuk setiap Entity strong dalam model data dibentuk relasi yang
meliputi semua atribut tunggalnya.
- Tipe Weak Entity
Primary key dari Entity weak diturunkan secara parsial atau penuh
dari setiap Entity induk. Jadi identifikasi primary key dari Entity weak
tidak dapat dilakukan sampai semua relasi dengan Entity induk telah
dipetakan.
- Tipe relasi binary One – to - Many (1:*)
Untuk setiap relasi binary (1:*), Entity pada ‘sisi satu’ dari relasi
dirancang sebagai Entity induk dan Entity pada ‘sisi banyak’
dirancang sebagai Entity anak. Untuk merepresentasikan relasi ini,
39
dilakukan penyalinan atribut primary key dari Entity induk ke relasi
yang merepresentasikan relasi anak sebagai foreign key.
- Tipe relasi binary one - to - one (1:1)
Membuat relasi untuk merepresentasikan relasi 1:1 lebih kompleks
karena cardinality tidak dapat digunakan untuk membantu
mengidentifikasi Entity induk dan anak dalam relasi. Berikut batasan
partisipasi dan cara membentuk relasinya:
- Partisipasi mandatory pada kedua sisi relasi 1:1
Dilakukan penggabungan Entity yang dilibatkan kedalam sebuah
relasi dan memilih satu primary key dari Entity asalnya untuk menjadi
primary key relasi yang baru, sedangkan yang lainnya sebagai
alternate key.
- Partisipasi mandatory pada satu sisi relasi 1:1
Dalam kasus ini, dapat dilakukan identifikasi Entity induk dan anak
untuk relasi 1:1 menggunakan batasan partisipasi. Entity yang
mempunyai partisipasi optional dalam relasi dirancang sebagai Entity
induk, dan Entity yang mempunyai partisipasi mandatory dalam relasi
dirancang sebagai Entity anak. Sehingga salinan primary key dari
Entity induk diletakkan pada relasi yang merepresentasikan Entity
anak.
- Partisipasi opsional pada kedua sisi relasi 1:1
Dalam kasus ini, perancangan Entity induk dan anak tak tentu kecuali
kalau ditemukan informasi yang lebih tentang relasi yang dapat
membantu keputusan yang dibuat.
40
- Tipe relasi superclass / subclass
Untuk setiap relasi superclass/subclass pada model data konseptual,
diidentifikasi Entity superclass sebagai Entity induk dan Entity
subclass sebagai Entity anak (Connolly, 2002, p451). Ada beberapa
macam pilihan bagaimana merepresentasikan relasi sebagai satu atau
banyak relasi tergantung faktor batasan disjoint dan partisipasi.
Langkah 2.3 Validasi relasi menggunakan normalisasi
Untuk memvalidasi relasi dalam model data logikal lokal digunakan
teknik normalisasi. Proses normalisasi meliputi langkah-langkah utama
yaitu : bentuk normal pertama (1NF), normal kedua (2NF), normal ketiga
(3NF) dan bentuk normal Boyce-Codd (BCNF).
Langkah 2.4 Validasi relasi terhadap transaksi user
Tujuan langkah ini untuk menyakinkan bahwa model data logikal lokal
mendukung transaksi yang diperlukan oleh view.
Langkah 2.5 Mendefinisikan referential integrity constraints
Batasan integriti merupakan batasan yang digunakan untuk melindungi
basis data dari keadaan tidak konsisten. Menurut Connolly (2002, p457)
ada lima jenis batasan integriti yaitu :
a. Required data, Beberapa atribut harus selalu berisi data yang sah
sehingga atribut tersebut tidak diperbolehkan menerima null.
41
b. Attribute domain constraints, Setiap atribut mempunyai domain yang
merupakan sekumpulan nilai yang sah.
c. Entity integrity, Primary key dari sebuah Entity tidak dapat menerima
null.
d. Referential integrity, Jika foreign key berisi nilai, nilai tersebut harus
menunjuk pada tuple yang ada pada relasi induk.
Untuk menyakinkan referential integrity perlu dispesifikasikan
existence constraints yang mendefinisikan kondisi dimana candidate key
atau foreign key ditambahkan, diubah atau dihapus.
Jika sebuah tuple dari relasi induk dihapus, referential integrity
hilang jika ada tuple anak menunjuk ke tuple induk yang dihapus. Ada
beberapa strategi yang dapat digunakan :
NO ACTION, Mencegah penghapusan dari relasi induk jika terdapat
referensi ke tuple anak.
CASCADE, Jika tuple induk dihapus maka secara otomatis tupel anak
akan dihapus.
SET NULL, Jika tuple induk dihapus, maka foreign key dari tuple anak
akan menjadi null.
SET DEFAULT, Jika tuple induk dihapus, maka foreign key pada semua
tuple anak akan diberikan nilai default.
NO CHECK, Jika tuple induk dihapus, maka tidak dilakukan apapun
untuk menyakinkan bahwa referential integrity terjaga.
42
Langkah 2.6 Mengkaji ulang model data logikal lokal dengan user
Tujuan langkah ini untuk menyakinkan bahwa model data logikal lokal
dan dokumentasi pendukung yang menggambarkan model merupakan
representasi yang benar dari view.
Langkah 3 Membangun dan validasi model data logikal global
Langkah ini bertujuan untuk menggabungkan model data logikal lokal
individual kedalam satu model data logikal global yang merepresentasikan
organisasi.
2.2.4.3 Physical database design
Physical database design dilakukan untuk memutuskan struktur
logis secara fisik di implementasikan ke dalam tujuan (DBMS), para
perancang juga harus membuat keputusan mengenai bagaimana basis data
tersebut dapat diimplementasikan / diterapkan dalam perusahaan.
Langkah 4 Menerjemahkan model data logikal kedalam target DBMS
Langkah 4.1 Merancang relasi dasar
Dengan menggunakan DBMS dapat dibentuk tabel secara nyata dengan
mendeklarasikan juga primary key dan foreign key, sehingga terbentuk
hubungan antar tabel seperti yang telah dirancang dalam model global
data logikal
43
Langkah 4.2 Merancang representasi dari data turunan
Pada tahap ini, dipastikan bagaimana memperoleh data dalam model
global data logikal ke DBMS.
Langkah 4.3 Merancang aturan-aturan yang dikehendaki
perusahaan
Pada tahap ini, dibuat aturan-aturan seperti yang diinginkan perusahaan
dalam menampilkan, menambah, ataupun untuk meng-update data dalam
basis data.
Langkah 5 Merancang representasi physical
Langkah 5.1 Analisis transaksi
Pada tahap ini, dipelajari segala kegiatan transaksi yang terjadi dalam
suatu perusahaan yang akan dijalankan pada basis data dan menganalisa
transaksi-transaksi yang penting.
Langkah 5.2 Memilih organisasi file
Tujuan utamanya adalah untuk memilih organisasi file yang optimal
karena akan sangat mempengaruhi efisiensi dari basis data.
Langkah 5.3 Memilih indeks
Pemilihan indeks sangat penting dalam meningkatkan kinerja dari sebuah
sistem, terutama kecepatan akses terhadap basis data.
44
Langkah 5.4 Memperkirakan kapasitas disk yang dibutuhkan untuk
menyimpan basis data.
Dalam penentuan kapasitas penyimpanan perlu memperhatikan
pertumbuhan data dikemudian hari. Langkah ini bertujuan untuk
memperkirakan jumlah kapasitas disk yang diperlukan untuk mendukung
implementasi basis data.
Tahap yang dapat digunakan untuk memperkirakan jumlah ruang yang
dibutuhkan untuk menyimpan data dan banyak tambahan nonclustered
indexes pada tabel yang memiliki clustered index.
- Menghitung tempat penyimpanan yang digunakan untuk menyimpan
data.
- Menghitung tempat penyimpanan yang digunakan untuk menyimpan
clustered index.
- Menghitung tempat penyimpanan untuk menyimpan setiap tambahan
nonclustered index.
- Menjumlahkan nilai yang dihitung.
Langkah 6 Merancang tampilan user
Rancangan tampilan sangat berpengaruh terhadap efektifitas penggunaan
oleh user. Dengan rancangan layar yang baik maka user dapat dengan
mudah menggunakan aplikasi tersebut.
45
Langkah 7 Merancang mekanisasi keamanan
Perancangan keamanan sangat diperlukan karena dapat mencegah sistem
dan data dari kerusakan. Keamanan untuk sistem dapat menggunakan
password dan keamanan untuk data bisa menggunakan cara diberikan hak
untuk akses
Langkah 8 Denormalization
Pada langkah pysical database design ini mempertimbangkan
denormalisasi skema relasional untuk meningkatkan performa. Hasil dari
normalisasi adalah merancang basis data logikal secara struktural konsisten
dan menekan jumlah redudansi. Faktor yang perlu di pertimbangkan
adalah:
• Denormalisasi membuat implementasi lebih kompleks
• Denormalisasi selalu mengorbankan fleksibilitas
• Denormalisasi akan membuat cepat dalam retrieve data tetapi lambat
dalam proses update data.
Ukuran performa dari suatu perancangan basis data dapat dilihat dari sudut
pandang tertentu yaitu melalui pendekatan efisiensi data (Normalisasi) atau
pendekatan efisiensi proses (Denormalisasi). Efisiensi data dimaksudkan
untuk meminimalkan kapasitas disk, dan efisiensi proses dimaksud untuk
mempercepat proses saat retrieve data dari basis data.
46
2.2.5 Normalisasi
2.2.5.1 Pengertian Normalisasi
Normalisasi memberikan panduan yang sangat membantu bagi
pengembang untuk mengembangkan struktur tabel yang kurang efisien
menjadi efisien dan kompatibel bagi program DBMS. Struktur tabel yang
kurang efisien tersebut biasanya disebabkan karena adanya anomali pada
tabel tersebut Suatu desain database harus memenuhi kondisi untuk tidak
mengandung anomali, yaitu suatu kejanggalan dari suatu penempatan
atribut tertentu dari suatu obyek data. Menurut Willis (2000, p69)
normalisasi adalah proses menggunakan metode-metode formal untuk
mengeliminasi data-data berulang, dan untuk memisahkan data menjadi
tabel-tabel yang saling berhubungan.
2.2.5.2 Anomali
Anomali adalah proses pada basis data yang memberikan efek
samping yang tidak diharapkan (misalnya menyebabkan ketidak
konsistenan data). Anomali terdiri dari 3 macam :
- Anomali Update
Anomali ini terjadi ketika pengubahan pada sejumlah data yang
mubazir, tapi tidak semuanya diubah.
- Anomali Insert
Anomali insert terjadi pada saat penambahan hendak dilakukan ternyata
ada data yang masih kosong, padahal data tersebut adalah primary key.
- Anomali Delete
47
Anomali yang terjadi ketika dilakukan delete terhadap suatu data dan
sebagai akibatnya data lain ikut terhapus juga, padahal data tersebut
masih dibutuhkan.
2.2.5.3 Dependensi
Dependensi adalah konsep yang mendasari normalisasi. Dependensi
menyatakan hubungan antar atribut dan secara khusus menjelaskan nilai
suatu atribut yang menentukan nilai atribut lainnya
Ada 4 macam dependensi :
- Dependensi fungsional
- Dependensi fungsional sepenuhnya
- Dependensi total
- Dependensi transitif
1. Dependensi Fungsional
Suatu atribut Y mempunyai dependensi fungsional terhadap
atribut X jika dan hanya jika setiap nilai X berhubungan dengan tiap
nilai Y.
Definisi diatas biasanya dituangkan dalam bentuk notasi sebagai
berikut:
X Y
48
2. Dependensi fungsional sepenuhnya
Suatu atribut Y mempunyai dependensi fungsional terhadap
atribut X jika :
- Y mempunyai dependensi fungsional terhadap X
- Y tidak memiliki dependensi terhadap bagian dari X
3. Dependensi total
Suatu atribut Y mempunyai dependensi fungsional terhadap
atribut X jika :
- Y mempunyai dependensi fungsional terhadap X
- X memiliki dependensi fungsional terhadap X
Definisi diatas biasanya dituangkan dalm bentuk notasi sebagai berikut:
X Y
4. Dependensi transitif
Suatu atribut Z mempunyai dependensi fungsional terhadap
atribut X jika :
- Y mempunyai dependensi fungsional terhadap X
- Z memiliki dependensi fungsional terhadap Y
2.2.5.4 Bentuk Normal
1. Bentuk Normal Pertama (1st NF)
Suatu bentuk dimana sudah tidak ada kelompok repeating group dan
sudah memiliki primary key. Suatu data dikatakan un-normalized, jika
49
didalamnya mengandung kelompok berulang (repeating group),
sehingga untuk membentuk normalisasi pertama (1st NF) repeating
group harus dihilangkan. Suatu relation dikatakan dalam bentuk normal
pertama jika dan hanya jika setiap atribut bernilai tunggal bagi setiap
record.
2. Bentuk Normal Kedua (2nd NF)
Semua atribut yang ada bergantung penuh terhadap primary key. Dapat
dihasilkan dengan melihat apakah ada atribut bukan primary key yang
merupakan fungsi dari sebagian primary key (partial dependence).
Dalam normalisasi kedua (2nd NF) setiap atribut yang tergantung parsial
ini harus dipisahkan dengan mengikutsertakan determinannya. Suatu
relasi dikatakan berada pada bentuk normal kedua jika dan hanya jika :
- Berada pada bentuk normal pertama
- Semua atribut non key memiliki ketergantungan sepenuhnya pada
primary key
3. Bentuk Normal Ketiga (3rd NF)
Tidak ada atribut lain selain primary key bergantung transitif terhadap
primary key. Pengujian terhadap 3rd NF dilakukan dengan cara melihat
apakah terdapat atribut non key yang tergantung fungsional terhadap
atribut non key yang lain (disebut ketergantungan transitif atau
transitive dependence). Dengan cara yang sama, maka setiap
50
ketergantungan transitif dipisahkan. Suatu relasi dikatakan berada pada
bentuk normal ketiga jika dan hanya jika :
- Sudah berada pada bentuk normal kedua
- Setiap atribut non key tidak memiliki ketergantungan transitif pada
primary key
3rd NF sudah cukup bagus dalam arti bahwa anomali yang
dikandungnya sudah sedemikian minimum (hampir tidak ada).
2.2.6 Entity relationship diagram
2.2.6.1 Pengertian Entity types & Entity occurrences
Entity adalah sesuatu yang dapat diidentifikasikan di lingkungan
kerja user, sesuatu yang ingin dilacak kembali oleh user.
Entity type adalah sekelompok objek dengan property yang sama,
serta diidentifikasi oleh perusahaan sebagai objek yang tidak memiliki
ketergantungan.
Entity occurrences adalah sebuah objek yang dapat
diidentifikasikan secara unik pada suatu entity types.
2.2.6.2 Relationship types & relationship occurences
Relationship types adalah Sekelompok hubungan yang bermakna
diantara entity type.
Relationship occurrences adalah adalah sebuah asosasi/ hubungan
yang termasuk didalamnya satu occurrences dari setiap entity type yang
ikut berpartisipasi.
51
Degree of Relationship types
Degree of Relationship types adalah jumlah dari entity type yang
berpartisipasi pada sebuah relationship type.
Contoh relationship bisa dilihat pada Gambar 2.4 dibawah :
Gambar 2.4 Contoh relationship
2. 2. 7 Data Flow Diagram (DFD)
DFD adalah suatu tool yang menggambarkan aliran data yang melalui
suatus sistem serta proses yang dilakukan sistem tersebut.
DFD adalah tool yang digunakan untuk merepresentasikan suatu sistem
yang otomatis atau manual dengan menggunakan gambar yang berbentuk
jaringan grafik.
Simbol-simbol yang digunakan pada DFD dapat dilihat pada Gambar
2.5 dibawah:
52
Gambar 2.5 S imbol-simbol DFD
External Entity :
- Entitas yang berada di luar sistem yang memberikan data ke sistem atau
menerima data dari sistem.
- Tidak termasuk bagian dari sistem.
Process
- Menggambarkan apa yang dilakukan oleh sistem.
- Berfungsi mentransformasikan 1 atau beberapa data masukan menjadi 1 atau
beberapa data keluaran.
- Setiap proses memiliki 1 atau beberapa data masukan serta menghasilkan 1
atau beberapa data keluaran.
External entity atau terminal
Process
Data flow
Data store
53
Data flow
- Menggambarkan aliran data dari 1 Entity ke Entity lainnya.
- Arah panah menggambarkan arah aliran data.
Data store
- Menurut Hawryskiewycz (1998, P142) data store adalah tempat menyimpan
data yang terdapat didalam system.
- Process dapat mengambil data dari data store atau memberikan data ke data
store.
2.2.8 State Transition Diagram (STD)
STD adalah tool yang digunakan untuk memodelkan suatu sistem yang
menggambarkan sifat ketergantungan terhadap waktu dari suatu system.
Notasi yang digunakan pada STD bisa dilihat pada Gambar 2.6 dibawah :
Gambar 2.6 S imbol STD
Untuk melengkapi STD diperlukan 2 hal lagi yaitu :
- Condition
adalah suatu kejadian pada lingkungan external yang dapat dideteksi oleh
sistem
Perubahan state
State
54
- Action
adalah tindakan / perubahan state yang dilakukan oleh sistem sebagai
akibat terjadinya condition. Action akan menghasilkan output, message
display pada screen, atau melakukan kalkulasi
2.2.9 Perhitungan disk space
Menurut Elmasri dan Navathe (2000,p131) rumus perhitungan disk
space adalah sebagai berikut :
Bfr = B / R b = r / Bfr
Dimana :
B = Block (antara 512 byte – 64 kilobyte)
r = record number
R = Record Length
Bfr = Banyak record per block
b = banyak block per table
2.2.10 Cryptography
Menurut Agus Kurniawan (2008,p6), Cryptography adalah ilmu yang
mempelajari bagaimana melakukan enkripsi dan dekripsi, dengan
memanfaatkan model matematika tertentu, yang bertujuan untuk :
1. Secrecy
Secrecy bertujuan untuk menjamin amannya data disimpan.
2. Integrity
55
Integrity bertujuan untuk memastikan bahwa data yang disimpan atau yang
diterima tidak rusak, ataupun di ubah oleh yang tidak berhak
3. Authentication
Authentication adalah suatu mekanisme untuk melakukan verifikasi,
apakah mempunyai hak akses atau tidak.
4. Non-Repudiation
Memastikan apakah data yang diterima benar-benar berasal dari apa yang
kita harapkan, atau sebaliknya.
2.2.10.1 Encryption
Menurut Agus Kurniawan (2008,p2), semua informasi yang dapat
di baca, secara umum dikatakan sebagai plaintext atau cleartext. Apabila
suatu informasi diubah sehingga orang lain tidak membaca informasi
tersebut, maka dapat dikatakan bahwa informasi tersebut telah dilakukan
proses enkripsi dan hasil dari proses enkripsi disebut dengan ciphertext.
Sebagai contoh kita mengubah beberapa kata seperti pada tabel
dibawah ini :
Tabel 2.1 Contoh Encryption
Huruf asal Huruf diganti
A C
U W
I K
E G
O Q
56
Dari tabel di atas, misalkan kita mempunyai kata
“CRYTOGRAPHY”, maka akan menjadi “ETWVQITCRJW”.
2.2.10.2 Decryption
Untuk mengembalikan hasil dari proses enkripsi, maka kita harus
melakukan proses yang disebut dengan dekripsi, yaitu mengembalikan text
enkripsi menjadi plaintext atau cleartext. Sebagai contoh, kata
“ETWVQITCRJW” dengan menggunakan algoritma dekripsi tertentu, akan
menjadi “CRYTOGRAPHY”.