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”.