7

BAB 2

LANDASAN TEORI

2.1 Teori Umum

2.1.1 Sistem

Menurut O’Brien (2003,p8), sistem adalah sekumpulan dari komponen

yang saling berhubungan dan bekerja sama untuk mencapai tujuan bersama

dengan menerima input dan menghasilkan output dalam suatu organisasi.

Sedangkan menurut Mulyadi (2001, p2) sistem pada dasarnya adalah

sekelompok unsur yang erat berhubungan satu dengan lainnya, yang berfungsi

bersama – sama untuk mencapai tujuan tertentu.

Berdasarkan dari definisi di atas maka dapat disimpulkan bahwa sistem

adalah merupakan suatu kumpulan dari komponen-komponen yang saling

berhubungan serta bekerja atau berfungsi bersama sama untuk mencapai tujuan

tertentu dengan menerima input, kemudian input tersebut diproses dan

menghasilkan output dalam suatu organisasi.

2.1.2 Informasi

Menurut Mcleod dan Schell (2004, p15) informasi adalah data yang telah

diproses atau data yang memiliki arti.

Menurut O’Brien (2003, p13), informasi adalah sekumpulan data yang telah

diubah dalam konteks yang lebih bermakna dan berguna bagi pengguna akhir

tertentu

8

Berdasarkan definisi di atas maka dapat disimpulkan bahwa informasi

adalah sebuah atau sekumpulan data yang telah diproses sehingga memiliki arti dan

beguna bagi pengguna akhir tertentu.

2.1.3 Sistem Informasi

Menurut Laudon dan Laudon (2002, p7) sistem informasi adalah kumpulan

komponen-komponen yang saling berhubungan yang bekerjasama untuk

mengumpulkan, memproses, menyimpan, dan menyebarkan informasi untuk

mendukung pengambilan keputusan, koordinasi, dan kendali dalam organisasi.

Menurut O’Brien (2003,p7), sistem informasi adalah kombinasi dari

orang, perangkat keras, perangkat lunak, jaringan komunikasi, dan sumber data

yang dikumpulkan, diubah bentuknya, dan penyebaran informasi pada sebuah

perusahaan.

Berdasarkan definisi di atas maka dapat disimpulkan bahwa sistem

informasi adalah sekumpulan dari komponen komponen berupa orang, perangkat

keras, perangkat lunak, jaringan komunikasi, dan sumber data yang saling

berhubungan dan bekerja sama untuk mengumpulkan, memproses, menyimpan dan

menyebarkan informasi pada perusahaan untuk mendukung pengambilan

keputusan, koordinasi, dan kendali dalam perusahaan tersebut

Menurut Laudon dan Laudon (2002,p39) ,ada 4 tingkat sistem informasi yaitu :

Sistem informasi tingkat operasional

Sistem informasi yang memonitor aktivitas dan kegiatan informasi pada tingkat

dasar. Misalnya pengeluaran uang kas, daftar pemesanan dari salesman dan

sebagainya.

9

Sistem informasi tingkat pengetahuan

Sistem informasi yang mendukung dan menyediakan pengetahuan dan data

pekerjaan di dalam sebuah perusahaan.

Sistem informasi tingkat strategi

Sistem informasi yang mendukung aktivitas perencanaan jangka panjang

disusun oleh manajemen senior.

Sistem informasi tingkat manajemen

Sistem informasi yang mendukung pengawasan, pengontrolan, pengambilan

keputusan, aktivitas administrasi dari manajer menengah.

2.1.4 Data

Menurut O’Brien (2003,p13), data adalah fakta mentah atau observasi,

umumnya tentang fenomena fisik atau transaksi bisnis. Sebagai contoh, sebuah

peluncuran pesawat luar angkasa atau penjualan suatu mobil akan menciptakan

banyak data yang menggambarkan kejadian tersebut. Secara lebih spesifik, data

adalah ukuran objektif dari atribut (karakteristik) dari entitas (seperti orang, tempat,

dan benda).

Berdasarkan situs http://id.wikipedia.org/wiki/Data, 2006 data adalah

suatu pernyataan yang diterima secara apa adanya. Pernyataan ini merupakan hasil

pengukuran atau pengamatan terhadap sebuah variabel yang dapat berupa angka,

kata-kata- atau citra.

Berdasarkan definisi di atas maka dapat disimpulkan bahwa data adalah

sebuah fakta atau pernyataan yang bersifat mentah, diterima apa adanya yang

10

umumnya berisi tentang fenomena fisik atau transaksi bisnis dan fakta tersebut

dapat berupa angka, kata-kata, atau gambar.

2.2 Teori Khusus

2.2.1 Database

Lapran danpemasukkan

data

Lapran danpemasukkan

data

DBMS

Client

Client

Database

Gambar 2.1 : Pemrosesan Database

Menurut Connolly dan Begg (2002, p14-p15) Database merupakan suatu

kumpulan data, yang terbagi atas data yang berhubungan secara logis dan deskripsi,

dari data tersebut dirancang untuk memenuhi kebutuhan informasi suatu organisasi.

Database merupakan sebuah tempat penyimpanan tunggal yang besar bagi data

yang dapat digunakan secara serentak oleh banyak departemen dan pengguna.

Database merupakan sebuah komponen yang tidak dimiliki sendiri tetapi

merupakan sebuah sumber daya yang terbagi dalam perusahaan. Database tidak

hanya berisi data operasional organisasi tetapi juga deskripsi data tersebut yang

disebut meta data/data tentang data. Dalam database definisi dari data terpisah dari

11

program aplikasi. Keuntungan dari pendekatan tersebut disebut abstraksi data, di

mana kita dapat mengubah definisi internal dalam objek tanpa mempengaruhi

pengguna objek tersebut, dan menyediakan definisi eksternal yang sama.

2.2.2 DBMS

Menurut Connolly dan Begg (2002, p16) Database Management System

merupakan sebuah program yang memperbolehkan pengguna untuk mengontrol dan

mengatur pengorganisasian, penyimpanan dan pengambilan data dalam suatu

database. DBMS menyediakan beberapa fasilitas berikut :

a. Memungkinkan pengguna untuk mendefinisikan database, melalui Data

Definition Language (DDL). DDL memungkinkan pengguna untuk

menentukan struktur dan jenis data serta batasan pada data yang disimpan

dalam database.

b. Memungkinkan pengguna untuk melakukan manipulasi data menggunakan

Data Manipulation Language (DML). DML menyediakan fasilitas

pemeriksaan umum yang disebut query language.

c. Menyediakan akses kendali pada database seperti :

Sistem keamanan, yang mencegah pengguna tak berwewenang mengakses

database

Sistem integritas, yang memelihara konsistensi data

Sistem kendali konkurensi, yang memungkinkan pembagian akses

terhadap database

Sistem kendali recovery, yang menyimpan database kembali pada

keadaan konsisten sebelumnya

12

Katalog user-accessible, yang berisi deskripsi data dalam database.

2.2.3 Komponen Database

Menurut Connolly dan Begg (2002, p18-p20), komponen database terbagi

menjadi lima komponen yaitu :

Programaplikasi

Database Management Sistem (DBMS)

Database

Pengguna

Sistem Database

Gambar 2.2 : Komponen Database

a. Hardware

Hardware dapat berkisar dari komputer tunggal, mainframe tunggal, hingga

komputer jaringan. Hardware tertentu tergantung pada kebutuhan organisasi

dan DBMS yang digunakan. Sebuah DBMS memerlukan jumlah minimum

memori dan hardisk untuk bekerja, tetapi konfigurasi yang minimum tidak

memberikan performa yang handal.

13

b. Software

Komponen ini terdiri dari DBMS dan program aplikasi bersama sistem

operasi dan software jaringan, jika DBMS digunakan melalui jaringan.

Program aplikasi seperti C++, Java dan Visual Basic.

c. Data

Merupakan komponen yang terpenting dalam DBMS. Data berfungsi sebagai

jembatan antara komponen mesin dan komponen manusia. Database berisi

data operasional dan meta data. Struktur database disebut skema, skema

terdiri dari banyak tabel, di dalam tabel terdapat lebih dari satu atribut.

d. Prosedur

Mengacu pada instruksi dan aturan yang memerintahkan perancangan dan

penggunaan database. Pengguna sistem dan petugas yang mengatur database

memerlukan dokumentasi prosedur bagaimana untuk menggunakan dan

menjalankan sistem. Instruksi tersebut seperti :

Bagaimana cara masuk ke dalam DBMS

Bagaimana menggunakan fasilitas DBMS tertentu

Memulai dan menghentikan DBMS

Bagaimana menangani kesalahan hardware dan software tertentu

e. Manusia

Komponen manusia terdiri dari :

Pemrogram Aplikasi : Yang bertanggungjawab untuk membuat aplikasi

database dengan menggunakan bahasa pemrograman yang ada

14

End User : Siapapun yang berinteraksi dengan sistem secara online atau

tidak melalui komputer atau jaringan

Data Adiministrator : Seseorang yang berwenang membuat keputusan dan

kebijakan strategis mengenai data yang ada

Database Administrator : Menyediakan dukungan teknis untuk

implementasi keputusan tersebut, dan bertanggungjawab atas keseluruhan

kendali sistem pada tingkat teknis

2.2.4 Keuntungan dan Kerugian DBMS

Menurut Connolly dan Begg (2002, p25-p29), DBMS memiliki keuntungan

dan kerugian sebagai berikut :

2.2.4.1 Keuntungan DBMS

a. Kontrol terhadap pengulangan data (data redudancy).

Database berusaha untuk menghilangkan pengulangan dengan

mengintegrasikan file sehingga berbagai copy dari data yang sama tidak

tersimpan. Bagaimanapun juga pendekatan ini tidak menghilangkan

pengulangan secara menyeluruh, tetapi mengendalikan jumlah

pengulangan dalam database

b. Data yang konsisten.

Dengan menghilangkan atau mengendalikan pengulangan, kita telah

mengurangi resiko ketidakkonsistenan yang terjadi. Jika item data

disimpan hanya sekali di dalam database, maka berbagai update bagi nilai

data tersebut harus dibuat hanya sekali dan nilai baru tersebut harus

tersedia dengan segera kepada semua pengguna. Jika item data disimpan

15

lebih dari sekali, sistem dapat memastikan bahwa semua copy dari item

tersebut tetap konsisten.

c. Semakin banyak informasi yang didapat dari data yang sama.

Dengan data operasional yang terintegrasi, hal ini memungkinkan bagi

organisasi untuk mendapatkan informasi tambahan dari data yang sama.

d. Pembagian Data (sharing of data).

Database termasuk bagian dari keseluruhan organisasi dan dapat

dibagikan oleh semua pengguna yang berotoritas. Dalam hal ini, banyak

pengguna membagikan lebih banyak data.

e. Meningkatkan integritas data.

Integritas database mengacu pada validitas dan konsistensi data yang

disimpan. Integritas biasanya diekspresikan dalam istilah batasan, yang

berupa aturan konsisten yang tidak boleh dilanggar oleh database.

Integrasi memungkinkan DBA untuk menjelaskan, dan memungkinkan

DBMS untuk membuat batasan integritas

f. Meningkatkan keamanan data.

Keamanan database yaitu melindungi database dari pengguna yang tak

berotoritas. Hal ini dapat dilakukan dengan menggunakan sistem user

name dan password untuk mengidentifikasi orang yang berotoritas untuk

menggunakan database. Akses pengguna yang berotoritas pada database

mungkin dibatasi oleh jenis operasi seperti pengambilan, insert, update,

dan delete data

16

g. Penetapan standarisasi.

Integrasi memungkinkan DBA untuk mendefinisikan dan membuat

standard yang diperlukan. Standard ini termasuk standard departemen,

organisasi, nasional, atau internasional dalam hal format data, untuk

memfasilitasi pertukaran data antara sistem, ketetapan penamaan,

standard dokumentasi, prosedur update, dan aturan akses.

h. Pengurangan biaya.

Dengan menyatukan semua data operasional organisasi ke dalam satu

database dan pembuatan sekelompok aplikasi yang bekerja pada satu

sumber data dapat menghasilkan pengurangan biaya. Penyatuan biaya

pengembangan dan pemeliharaan sistem pada setiap departemen akan

menghasilkan total biaya yang lebih rendah. Sehingga biaya lainnya dapat

digunakan untuk membeli konfigurasi sistem yang sesuai bagi kebutuhan

organisasi.

i. Menyeimbangkan Konflik Kebutuhan

Setiap pengguna mempunyai kebutuhan yang mungkin bertentangan

dengan kebutuhan pengguna lain. Sejak database dikendalikan oleh DBA,

DBA dapat membuat keputusan berkaitan dengan perancangan dan

penggunaan operasional database yang menyediakan penggunaan terbaik

dari sumberdaya bagi keseluruhan organisasi.

j. Meningkatkan kemampuan akses dan respon pada data

Dengan pengintegrasian data yang melintasi batasan departemen dapat

secara langsung diakses pada pengguna akhir. Hal ini dapat menyediakan

17

sebuah sistem dengan lebih banyak fungsi seperti fungsi untuk

menyediakan layanan yang lebih baik pada pengguna akhir atau klien

organisasi. Banyak DBMS menyediakan query language yang

memungkinkan pengguna untuk menanyakan pertanyaan ad hoc dan

memperoleh informasi yang diperlukan dengan segera pada terminal

mereka, tanpa memerlukan programmer menulis beberapa software untuk

mengubah informasi ini dari database

2.2.4.2 Kerugian DBMS

a. Kompleksitas.

Ketentuan dari fungsi yang kita harapkan dari DBMS yang baik membuat

DBMS menjadi sebuah software yang sangat kompleks. Perancang dan

pengembang database, DA dan DBA, serta pengguna akhir harus

memahami fungsi tersebut untuk mendapatkan banyak keuntungan dari

DBMS ini

b. Ukuran

Fungsi yang kompleks dan luas membuat DBMS menjadi software yang

sangat besar, memerlukan banyak ruang hardisk dan jumlah memory yang

besar untuk berjalan dengan efisien.

c. Biaya dari suatu DBMS.

Biaya DBMS bervariasi, tergantung pada lingkungan dan fungsi yang

disediakan. Di situ juga terdapat biaya pemeliharaan tahunan yang juga

dimasukkan dalam daftar harga DBMS

18

d. Biaya penambahan perangkat keras.

Kebutuhan tempat penyimpanan bagi DBMS dan database amat

memerlukan pembelian tempat penyimpanan tambahan. Lebih lanjut,

untuk mencapai performa yang diperlukan, mungkin diperlukan untuk

membeli mesin yang lebih besar dsb. Hal ini tentu memerlukan

tambahan biaya yang tidak sedikit. Tergantung pada spesifikasi perangkat

keras yang diperlukan

2.2.5 Arsitektur ANSI-SPARC Three Level

Menurut Connolly dan Begg (2002, p35-p36), arsitektur ANSI-SPARC

three-level dibagi menjadi tiga bagian yaitu :

View 1 View 2 View n

SkemaKonseptual

SkemaInternal

Database

Pengguna 1 Pengguna 2 Pengguna 3

LevelEksternal

LevelKonseptual

LevelInternal

Organisasidata fisikal

Gambar 2.3 : ANSI-SPARC Three Level

19

Level Eksternal

External level merupakan level pengguna individu, dimana masing-

masing pengguna hanya akan berkepentingan dengan satu bagian saja. Cara

pandang dari masing-masing pengguna bersifat abstrak bila dibandingkan

dengan bagaimana sebenarnya data tersebut disimpan. Masing-masing

pandangan pengguna tersebut disebut external view, yang berisi berbagai tipe

eksternal record. Jadi level ini berkaitan erat dengan pemakai, dimana dari tiap

pemakai hanya memerlukan senagian dari data yang ada dalam database. Cara

pandang secara eksternal hanya terbatas pada entitas, atribut, dan hubungan

antar entitas yang diperlukan saja.

Level Konseptual

Conceptual view merupakan representasi informasi keseluruhan dari isi

databse, dimana semua pandangan masing-masing pengguna digabungkan.

Perwujudannya abstrak, bila dibandingkan dengan bagaimana data

sesungguhnya tersimpan secara fisik. Conceptual view berisi berbagai tipe

record konseptual yang didefinisikan oleh skema konseptual, ditulis dalam data

definition language (DDL). Pendefinisian skema konseptual dimaksudkan untuk

menyertakan fitur-fitur tambahan, seperti keamanan dan integritas. Beberapa

tujuan utama dari skema konseptual diantaranya : menggambarkan perusahaan

secara lengkap, bagaimana data tersebut digunakan, bagaimana aliran data di

dalam perusahaan, kegunaan data untuk setiap proses, proses kendali atau audit

yang diberikan pada setiap proses.

20

Level Internal

Internal view merupakan level terendah dalam merepresentasikan dari

keseluruhan database. Internal view berisikan berbagai tipe internal record

yang didefinisikan oleh skema internal. Selain itu juga menyelesaikan mengenai

penempatan ruang penyimpanan data dan index, bagaimana pewujudan field-

field yang disimpan, dekripsi record untuk penyimpanan (dengan ukuran

penyimpanan untuk elemen), dan teknik enkripsi (pengamanan data). Dengan

kata lain level ini berkaitan dengan struktur penyimpanan /database yang

tersimpan yang menerangkan tempat penyimpanan data pada internal view, dan

definisi struktur penyimpanan pada skema internal yang menerangkan

hubungannnya dengan cara pengaksesan data yang disimpan

Tujuan dari arsitektur three-level adalah untuk menyediakan data

independence yang berarti bahwa level yang lebih tinggi tidak terpengaruh oleh

perubahan pada level yang lebih rendah

2.2.6 Database Languages

Menurut Connoly dan Begg (2002, p40) sebuah data sublanguage terdiri

dari dua bagian yaitu Data Definition Language (DDL) dan Data Manipulation

Language (DML). DDL digunakan untuk menentukan skema database dan DML

digunakan baik untuk membaca dan meng-update database. Keduanya disebut data

sublanguage karena mereka tidak membangun semua kebutuhan pemograman

komputer seperti pernyataan kondisi dan iterative yang digunakan oleh beberapa

bahasa pemrograman tingkat tinggi lainnya.

21

2.2.6.1 Data Definition Language

Data Definition Language menurut Connolly dan Begg (2002, p40)

adalah suatu bahasa yang memperoleh DBA atau pengguna untuk

mendeskripsikan dan memberi nama entitas, atribut, dan relationship yang

diperlukan untuk aplikasi. DDL berfungsi untuk mengubah suatu data menjadi

data yang berguna bagi pengguna. Beberapa statement DDL menurut

Connolly dan Begg(2002, p167) :

1. Create Table

Untuk membuat tabel dengan mengidentifisikan tipe data untuk tiap

kolom.

2. Alter Table

Untuk menambah atau membuang kolom dan konstrain.

3. Drop Table

Untuk membuang atau menghapus tabel besarta semua data yang terkait

didalamnya.

4. Create Index

Untuk membuat index pada suatu tabel.

5. Drop Index

Untuk membuang atau menghapus index atau menghapus index yang

sudah dibuat sebelumnya

2.2.6.2 Data Manipulation Language

Menurut Connolly dan Begg (2002, p41) DML adalah suatu bahasa

yang menyediakan sekumpulan operasi yang diinginkan untuk mendukung

22

operasi manipulasi data utama pada data yang diperoleh dalam database.

DML menyediakan operasi dasar manipulasi data pada data yang ada dalam

database, yaitu :

- Penyisipan data baru ke dalam database (insertion)

- Mengubah atau memodifikasi data yang disimpan dalam database

(modify)

- Pemanggilan data yang ada dalam database (retrieve)

- Menghapus data dari database (delete)

Menurut Connolly dan Begg kita dapat membedakan DML menjadi 2

tipe yang berbeda, yaitu:

a. Prosedural DML

Prosedural DML adalah suatu bahasa yang memungkinkan pengguna

(umumnya programmer) untuk memberi instruksi ke sistem mengenai data

apa yang dibutuhkan dan bagaimana cara pemanggilannya (retrieve). Artinya

pengguna harus menjelaskan operasi pengaksesan data yang akan digunakan

dengan menggunakan prosedur yang ada untuk mendapatkan informasi yang

dibutuhkan.

b. Non prosedural DML

Non prosedural DML adalah suatu bahasa yang memungkinkan

pengguna untuk menentukan data apa yang dibutuhkan dengan menyebutkan

spesifikasinya tanpa menspesifikasikan bagaimana cara mendapatkannya.

23

2.2.7 Fungsi DBMS

Menurut Connolly dan Begg (2002, p48-p52), fungsi DBMS adalah sebagai

berikut :

Penyimpanan, Pengambilan, dan Peng-update-an data

Sebuah DBMS harus menyediakan bagi pengguna dengan sebuah

kemampuan untuk menyimpan, mengambil, dan meng-update data dalam DBMS.

Ini merupakan fungsi yang mendasar dari DBMS. Dalam menyediakan fungsi ini

DBMS harus menyembunyikan detail implementasi fisikal internal seperti

organisasi file dan struktur penyimpanan dari pengguna

Katalog User-Accesible

Sebuah DBMS harus menyediakan sebuah katalog yang menyimpan

deskripsi tentang item data dan mudah diakses pada pengguna.

Mendukung Transaksi

Sebuah DBMS harus menyediakan mekanisme yang akan memastikan

bahwa semua kegiatan update yang dilakukan sesuai dengan transaksi yang

diberikan atau tidak ada kegiatan update yang dibuat bagi transaksi tersebut.

Transaksi merupakan sederetan tindakan, yang dilakukan oleh pengguna tunggal

atau program aplikasi yang mengakses atau mengubah isi database.

Layanan Kendali Konkurensi

Sebuah DBMS harus menyediakan sebuah mekanisme untuk memastikan

bahwa database di-update dengan benar ketika banyak pengguna meng-update

database secara bersama-sama. Akses bersama relatif mudah jika semua pengguna

hanya membaca data, di mana tidak ada cara bahwa mereka dapat mengganggu satu

24

dan yang lain. Namun ketika dua atau lebih pengguna mengakses database secara

serentak dan paling sedikit satu dari mereka meng-update data, di sana dapat terjadi

gangguan yang menghasilkan ketidakkonsistenan.

Layanan Perbaikan

Sebuah DBMS harus menyediakan sebuah mekanisme untuk memperbaiki

database disaat database mengalami kerusakkan dalam berbagai cara. Kerusakkan

database dapat diakibatkan karena kerusakan sistem, kesalahan media, dan

kesalahan software atau hardware. Atau disebabkan karena adanya kesalahan

selama proses transaksi dan penyelesaian transaksi yang tidak lengkap.

Layanan Authorisasi

Sebuah DBMS harus menyediakan sebuah mekanisme untuk memastikan

bahwa hanya pengguna yang berotoritas dapat mengakses database. Hal ini untuk

mencegah data yang tersimpan tak terlihat oleh semua pengguna dan melindungi

database dari akses yang tak berotoritas.

Mendukung Bagi Komunikasi Data

Sebuah DBMS harus mampu mengintegrasikan dengan software

komunikasi. Kebanyakan pengguna mengakses database dari workstation. Kadang

workstation tersebut terhubung secara langsung ke komputer DBMS. Dalam kasus

yang lain, workstation berada pada lokasi yang jauh dan berkomunikasi dengan

komputer DBMS melalui jaringan. Dalam hal ini DBMS menerima permintaan

sebagai pesan komunikasi dan menanggapi dengan cara yang sama. Semua

pengiriman ini ditangani oleh Data Communication Manager.

25

Layanan Integritas

Sebuah DBMS harus menyediakan sebuah arti untuk memastikan bahwa

data di dalam database dan perubahan pada data mengikuti aturan tertentu.

Integritas database dapat mengacu pada kebenaran dan konsistensi data yang

disimpan. Integritas berhubungan dengan kualitas data yang disimpan. Integritas

biasanya diekspresikan dengan istilah batasan, yaitu berupa aturan konsisten yang

tidak boleh dilanggar oleh database.

Layanan Peningkatan Keterbebasan Data

Sebuah DBMS harus memasukkan sebuah fasilitas untuk mendukung

keterbebasan program dari struktur database yang sebenarnya. Data independence

biasanya dicapai melalui sebuah view atau mekanisme subskema. Physical data

independence lebih mudah untuk dicapai karena terdapat beberapa jenis perubahan

yang dapat dibuat untuk karakteristik fisikal dari database tanpa mempengaruhi

view. Bagaimanapun data independence logikal yang lengkap lebih susah untuk

dicapai.

Layanan Utilitas

Sebuah DBMS harus menyediakan seperangkat layanan utilitas. Program

utilitas membantu DBA mengelola database secara efektif. Beberapa utilitas

bekerja pada tingkat eksternal, dan konsekuensinya dapat dibuat oleh DBA, yang

lainnya bekerja pada tingkat internal dan dapat disediakan hanya dengan vendor

DBMS. Contoh dari utilitas tersebut antara lain :

- Fasilitas import, untuk meng-load database dari flat file, dan fasilitas eksport,

untuk meng-unload database pada flat file

26

- Fasilitas pemantauan, untuk memantau penggunaan dan operasi database

- Program analisa statistik, untuk memeriksa performa dan penggunaan statistik

- Fasilitas penyusunan index, untuk menyusun kembali index dan overflow

mereka

- Penempatan dan pengumpulan sampah, untuk menghilangkan record yang

dihapus secara fisik dari alat penyimpanan, untuk menggabungkan ruang yang

terlepas, dan untuk menempatkan kembali record tersebut di mana ia

dibutuhkan

2.2.8 Komponen DBMS

ProgramAplikasi

SistemBuffer

Kode ObjekProgram

File ManagerMetodeAkses

DictionaryManager

DDLCompiler

QueryProcessor

DMLProcessor

SkemaDatabaseQueries

DatabaseManager

Database & Sistem Katalog

DBMS

Programmer Pengguna DBA

Gambar 2.4 : Komponen DBMS

27

1. Querry Processor : Merupakan komponen DBMS yang utama yang mengubah

query ke dalam seperangkat instruksi tingkat rendah langsung ke database

manager

2. Database Manager : DM mengantarmukakan dengan program aplikasi user-

submitted dan query. DM menerima query dan memeriksa skema eksternal dan

konseptual untuk menentukan record konseptual apa yang diperlukan untuk

memuaskan permintaan.

3. File Manager : File manager memanipulasi penyimpanan file dan mengatur

penempatan ruang penyimpanan dalam disk. Komponen ini mendirikan dan

memelihara daftar struktur dan index yang didefinisikan dalam skema internal

4. DML Processor : Modul ini mengubah pernyataan DML yang tertanam dalam

program aplikasi ke dalam panggilan fungsi standard dalam host language.

Komponen ini harus berinteraksi dengan query processor untuk membuat kode

yang sesuai.

5. DDL Compiler : Modul ini mengubah pernyataan DDL ke dalam seperangkat

tabel berisi meta data. Tabel ini kemudian disimpan dalam katalog sistem

sementara itu informasi kendali disimpan dalam header file data.

6. Catalog Manager : Catalog Manager mengatur akses ke dan memelihara

katalog sistem. Katalog sistem diakses oleh sebagian besar komponen DBMS.

2.2.9 Katalog Sistem

Menurut Connolly dan Begg (2002, p61-p62), katalog sistem merupakan

tempat penyimpanan informasi yang menjelaskan data dalam database, yaitu meta

data atau data tentang data. Katalog sistem menyimpan informasi seperti berikut :

28

Nama, jenis, dan ukuran data

Nama relationship

Batasan integritas pada data

Nama pengguna yang berotoritas yang mempunyai akses pada data.

Skema eksternal, konseptual, dan internal dan pemetaan antara skema

Penggunaan statistik, seperti frekuensi transaksi dan perhitungan sejumlah akses

yang dibuat pada objek dalam database

Sedangkan katalog sistem mempunyai beberapa keuntungan yaitu :

Informasi tentang data dapat dikumpulkan dan disimpan secara terpusat. Hal ini

membantu memelihara kendali data sebagai sebuah sumber

Arti data dapat didefinisikan, yang akan membantu pengguna lain memahami

tujuan data

Dapat mengidentifikasi pengulangan dan inkonsistensi lebih mudah sejak data

terpusat

Perubahan pada database dapat direkam

Dapat membuat sistem pengamanan

Dapat memastikan integritas

Dapat menyediakan informasi audit

2.2.10 Struktur Data Relasional

Menurut Connolly dan Begg (2002, p72-p74), struktur data relasional

terbagi menjadi beberapa bagian yaitu :

1. Relasi : Merupakan sebuah tabel dengan baris dan kolom. Digunakan untuk

menyimpan informasi tentang objek yang digambarkan dalam database

29

2. Atribut : Merupakan nama kolom dari relasi. Atribut dapat ditampilkan dalam

berbagai perintah dan dalam relasi yang sama sehingga menyampaikan arti yang

sama.

3. Domain : Merupakan sekelompok nilai yang diijinkan bagi satu atau lebih

atribut. Setiap atribut dalam relasi didefinisikan pada sebuah domain. Domain

dapat berbeda bagi setiap atribut, atau dua/lebih atribut dapat didefinisikan pada

domain yang sama. Konsep domain sangat penting karena memungkinkan

pengguna menjelaskan arti dan sumber nilai yang ada pada atribut.

4. Tuple : Merupakan baris dari sebuah relasi. Tuple dapat disebut intention jika

struktur relasi, domain serta batasan-batasan yang lainnya pada nilai yang

mungkin bersifat tetap, namun sebaliknya jika relasi berubah setiap waktu ini

disebut extension.

5. Degree : Merupakan jumlah atribut yang terdapat dalam relasi. Jika relasi

mempunyai satu atribut akan mempunyai derajat satu yang disebut relasi

unary/satu tuple. Jika relasi mempunyai dua atribut akan mempunyai derajat

dua yang disebut binary. Dan begitu seterusnya dengan menggunakan istilah n-

ary.

6. Cardinality : Merupakan jumlah tuple yang terdapat dalam relasi. Merupakan

properti dari extension relasi dan ditentukan dari instance tertentu.

7. Database Relasional : Merupakan kumpulan dari relasi yang ternormalisasi

dengan nama relasi yang berbeda.

30

2.2.11 Sifat-Sifat Relasi

Menurut Connolly dan Begg (2002, p77), relasi mempunyai sifat-sifat

sebagai berikut :

Nama relasi berbeda satu sama lain dalam skema relasional

Setiap sel dari relasi berisi satu nilai atomik

Setiap atribut memiliki nama yang berbeda

Nilai satu atribut berasal dari domain yang sama

Setiap tuple berbeda, dan tidak ada duplikasi tuple

2.2.12 Relational Keys

Menurut Connolly dan Begg (2002, p78-p79), relasional key dibagi menjadi

beberapa jenis yaitu :

1. Superkey : Merupakan sebuah atribut atau sekelompok atribut yang

mengidentifikasi secara unik tuple dalam relasi. Superkey yang mudah

diidentifikasi adalah yang hanya berisi jumlah minimum atribut yang diperlukan

2. Candidate Key : Merupakan superkey dalam relasi. Candidate key (K), bagi

sebuah relasi (R) mempunyai dua sifat yaitu :

a. Keunikan : Dalam setiap tuple dari R, nilai dari K secara unik

mengidentifikasi tuple tersebut

b. Irreducibility : Tidak ada subset yang sesuai dari K yang mempunyai

keunikan sifat

Ketika sebuah key terdiri dari lebih dari satu atribut kita sebut ini sebagai

composite key.

31

3. Primary Key : Merupakan candidate key yang terpilih untuk identifikasi tuple

secara unik dalam satu relasi. Sementara candidate key yang tak terpilih sebagai

primary key disebut alternate key

4. Foreign Key : Merupakan sebuah atribut atau sekelompok atribut dalam relasi

yang dibandingkan dengan candidate key pada beberapa relasi

2.2.13 Relasional Integritas

Menurut Connolly dan Begg (2002, p81-p83), relasional integritas terbagi

menjadi beberapa jenis yaitu :

Null

Merupakan gambaran sebuah nilai bagi sebuah atribut yang tidak

diketahui atau tidak digunakan bagi tuple tersebut. Null tidak sama dengan nilai

numerik nol atau spasi, tetapi null menggambarkan ketidakadaan nilai.

Integritas Entitas

Pada relasi dasar, tidak ada atribut primary key yang bernilai null.

Berdasarkan definisi di atas, primary key minimal berperan sebagai identifier yang

digunakan untuk mengidentifikasi tuple secara unik. Ini berarti tidak ada subset dari

primary key yang cukup untuk menyediakan pengidentifikasian tuple yang unik.

Integritas Referential

Jika terdapat foreign key dalam relasi, maka nilai foreign key tersebut akan

dibandingkan dengan nilai candidate key dari beberapa tuple pada relasi itu sendiri

atau nilai foreign key harus null semuanya

32

2.2.14 Entity Relationship Model

2.2.14.1 Entitas

Menurut Connolly dan Begg (2002, p331), entitas adalah

sekumpulan objek yang diindentifikasi oleh sebuah perusahaan atau

perorangan yang mempunyai sifat – sifat yang sama dan mempunyai

keberadaan yang independen. Sebuah entitas memiliki keberadaannya yang

bebas dan bisa menjadi objek dengan fisik (atau ‘real’) atau menjadi objek

dengan keberadaan konseptual ( atau ‘abstrak’). Artinya perancang yang

berbeda mungkin mengidentifikasikan entitas yang berbeda pula. Sebuah

database biasanya berisi banyak tipe entitas yang berbeda pula. Dalam UML,

huruf pertama dari entitas diawali dengan huruf Kapital.

Sedangkan menurut Connolly dan Begg (2002, p333), entity

occurrence adalah sebuah objek unik yang dapat di indentifikasikan dari

sebuah tipe entitas. Berikut adalah contoh entitas : staf, cabang, property,

pemilik

Staf Cabang

Nama Entitas

Gambar 2.5 : Contoh Entitas

33

2.2.14.2 Relationship

Menurut Connolly dan Begg (2002, p334) relationship adalah

sekumpulan hubungan yang berarti antara satu atau lebih entitas, dimana

setiap tipe relationship diberi nama yang menggambarkan fungsinya.

Sedangkan menurut Connolly dan Begg (2002, p334), relationship

occurrence adalah hubungan yang dapat diidentifikasi secara unik, yang

termasuk satu kejadian dari setiap entitas yang berpartisipasi.

Staf Cabang

RelationshipName

Mempunyai

Cabang mempunyaistaf

Gambar 2.6 : Contoh Relationship

2.2.14.2.1 Relationship Recursive

Menurut Connolly dan Begg (2002, p337), recursive

relationship adalah jenis relationship di mana entitas yang sama

berpartisipasi lebih dari satu di dalam peran yang berbeda. Sebagai

contoh, entitas staf berpartisipasi dua kali di dalam relationship

supervises. Partisipasi pertama sebagai supervisor dan partisipasi ke dua

sebagai anggota dari staf yang diawasi. Relationship mungkin diberikan

nama peran untuk mengindikasikan tujuan yang setiap entitas yang

34

berpartisipasi mainkan. Di sini penting untuk menentukan fungsi setiap

partisipan.

Staf

Nama Peran

Nama PeranSupervisee

Supervises

Gambar 2.7 : Contoh Relationship Recursive

2.2.14.3 Atribut

Menurut Connolly dan Begg (2002, p338), atribut adalah sebuah

properti atau sifat dari entitas atau relationship. Sebagai contoh, entitas staf

mungkin dapat menjelaskan atribut sebagai berikut : nostaf, nama, posisi, dan

gaji. Setiap atribut menyimpan nilai yang menjelaskan setiap entity

occurrence dan menggambarkan bagian utama dari data yang disimpan di

dalam database.

Sedangkan menurut Connolly dan Begg (2002, p338), domain

atribut adalah sekelompok nilai yang diperbolehkan bagi satu atau lebih

atribut. Domain mendefinisikan nilai potensi yang atribut miliki. Sebagai

contoh ruangan berhubungan dengan properti antara 1-15 untuk setiap entity

occurrence. Kita oleh karena itu mendefinsikan sekelompok nilai bagi nomor

35

ruangan/atribut rooms dari entitas properti sebagai sekelompok nilai integer

antara 1-15

2.2.14.3.1 Atribut Simple dan Composite

Menurut Connolly dan Begg (2002, p339), atribut simple

adalah sebuah atribut yang terdiri dari komponen tunggal dengan

keberadaannya yang bebas. Atribut ini tidak dapat dibagi ke dalam

komponen yang lebih kecil lagi. Sebagai contoh adalah atribut posisi dan

gaji pada entitas staf.

Sedangkan menurut Connolly dan Begg (2002, p229), atribut

composite adalah sebuah atribut yang terdiri dari berbagai komponen,

dengan keberadaannya yang bebas. Atribut ini dapat dibagi ke dalam

komponen yang lebih kecil lagi. Sebagai contoh atribut alamat pada

entitas cabang dengan nilai 163 Main St, Glasgow, G119QX) yang

kemudian dibagi ke dalam komponen jalan : 163 Main St, Kota :

Glasgow, Kodepos : G119QX

2.2.14.3.2 Atribut Simple Valued dan Multi-Valued

Menurut Connolly dan Begg (2002, p339), atribut single-

value adalah atribut yang berisi nilai tunggal bagi setiap kejadian dari

setiap entitas. Sebagai contoh, setiap kejadian dari entitas cabang

mempunyai nilai tunggal bagi nomor cabang/atribut branchNo = B003.

Oleh karena itu atribut branchNo mengacu pada nilai tunggal.

Sedangkan menurut Connolly dan Begg (2002, p340), atribut

multi-valued adalah atribut yang berisi berbagai nilai bagi setiap

36

kejadian dari setiap entitas. Sebagai contoh, setiap kejadian dari entitas

cabang dapat mempunyai berbagai nilai bagi atribut telno = 65625362,

672637672. Oleh karena itu atribut telno merupakan atribut multi-value

2.2.14.3.3 Derived Atribut

Menurut Connolly dan Begg (2002, p340), atribut derived

adalah atribut yang menggambarkan sebuah nilai yang dapat diperoleh

dari nilai atribut yang berhubungan atau sekelompok atribut, tidak perlu

dalam entitas yang sama. Sebagai contoh, nilai bagi atribut durasi dari

entitas pelepasan dihitung dari atribut rentstart dan rentfinish yang juga

dari entitas pelepasan. Oleh karena itu atribut durasi dianggap sebagai

atribut derived.

Bisa juga nilai dari atribut tersebut diperoleh dari entity

occurrence di dalam entitas yang sama. Sebagai contoh jumlah total staf

(totalstaff) dari entitas staf. Dapat dihitung dengan menghitung jumlah

total dari entity occurrence staff.

Atribut derived juga melibatkan hubungan atribut dari entitas

yang berbeda. Sebagai contoh atribut deposit dari entitas pelepasan di

mana nilai atribut deposit dihitung dua kali berdasarkan sewa bulanan

bagi properti. Oleh karena itu nilai dari atribut deposit dari entitas

pelepasan diperoleh dari atribut sewa dari entitas properti

2.2.14.4 Entitas Kuat Dan Lemah

Menurut Connolly dan Begg (2002, p342), entitas kuat adalah

entitas yang keberadaannya tidak bergantung pada beberapa entitas yang lain.

37

Karakter dari entitas ini adalah bahwa setiap kejadian entitas teridentifikasi

secara unik menggunakan atribut primary key. Sebagai contoh, kita dapat

mengidentifikasi secara unik setiap anggota staf dengan menggunakan atribut

staffno.

Sedangkan menurut Connolly dan Begg (2002, p343), entitas

lemah adalah entitas yang keberadaannya tergantung pada beberapa entitas

yang lain. Karakteristik dari entitas ini bahwa setiap kejadian entitas tidak

dapat teridentifikasi secara unik hanya dengan menggunakan atribut yang

berhubungan dengan entitas tersebut. Sebagai contoh, kita tidak dapat

mengidentifikasi setiap kejadian dari entitas kesukaan hanya dengan

menggunakan atribut entitas tersebut. Kita hanya dapat mengidentifikasi

secara unik entitas kesukaan melalui relationship yang entitas kesukaan miliki

dengan entitas klien yang secara unik teridentifikasi menggunakan primary

key bagi entitas klien.

-NoKlien-Nama-Telno

Klien

-JenisKesukaan-SewaMaximum

KesukaanMenyatakan

Entitas Kuat Entitas Lemah

Gambar 2.8 : Contoh Weak Entity dan Strong Entity

38

2.2.14.5 Struktural Constraint

Menurut Connolly dan Begg (2002, p344), multiplicity adalah

jumlah kejadian yang mungkin dari entitas yang berhubungan pada kejadian

tunggal dari sebuah hubungan entitas melalui relationship tertentu. Ini

merupakan gambaran dari kebijakan/aturan bisnis yang dibuat oleh

perusahaan. Memastikan bahwa semua batasan perusahaan yang sesuai

teridentifikasi dan tergambarkan merupakan bagian penting dari pemodelan

perusahaan. Terdapat tiga jenis relationship sesuai dengan batasan perusahaan

yaitu :

a. Relationship One To One (1:1)

Staf Cabang

Setiap cabangdiatur oleh satu

anggota staff

Mengatur

1..1 0..1

Setiap anggota staf dapatmengatur nol atau satu cabang

Multiplicity

Gambar 2.9 : Contoh One To One Relationship

39

b. Relationship One To Many (1:*)

Staf Properti

Setiap Propertidiawasi olehnol atau

satu anggota staf

Mengawasi

0..1 0..*

Setiap anggota staff mengawasinol atau lebih properti

Gambar 2.10 : Contoh One To Many Relationship

c. Relationship Many To Many (*:*)

Koran Properti

Setiap propertidiiklankan dalam nol

atau lebih koran

Mengiklankan

0..* 1..*

Setiap koran mengiklankan satuatau lebih properti

Gambar 2.11 : Contoh Many To Many Relationship

2.2.14.6 Cardinality

Menurut Connolly dan Begg (2002, p351), cardinality yaitu

menjelaskan jumlah maksimum yang mungkin kejadian relationship bagi

40

entitas yang berpartisipasi di dalam relationship yang diberilkan. Cardinality

terdiri dari : one-to-one (1:1), one-to-many (1:*), dan many-to-many (*:*).

2.2.14.7 Compotition

Menurut Connolly dan Begg (2002, p372), composition merupakan

sebuah bentuk tertentu dari agregasi yang menggambarkan hubungan antara

entitas, dimana disana terdapat kepemilikanyang kuat antara ‘keseluruhan dan

‘bagian’. Disini objek hanya menjadi bagian satu composite pada waktu itu.

KoranIklan

Bagian

Mengindikasikancomposition

11..* Menampilkan

Keseluruhan

Gambar 2.12 : Contoh Compotition

2.2.15 Normalisasi

Menurut M. Subekti (1997,p85) suatu desain database harus memenuhi

kondisi tidak mengandung anomali yaitu suatu kejanggalan dari suatu penempatan

atribut tertentu dari obyek data.

Pengertian normalisasi menurut connoly & Begg (2002, p376) pengertian

normalisasi adalah suatu teknik untuk memproduksi satu set hubungan dengan

41

kebutuhan yang diinginkan, memberi kebutuhan data dari suatu perusahaan. Tujuan

lain dari normalisasi adalah mencegah adanya redudansi atau pengulangan data

yang nantinya akan menghemat tempat pada penyimpanan (connoly & begg, 2002,

p377). Proses dalam normalisasi menurut Connoly dan Begg terbagi menjadi

beberapa tahap, yaitu :

Unnormalized Form (UNF)

Suatu tabel dikatakan sebagai bentuk yang unnormalized bila didalamnya

terdapat kelompok berulang atau yang biasa dikenal repeating group. Untuk lebih

jelasnya lihat tabel berikut :

Tabel Nilai Mahasiswa

Tabel 2.1 : Tabel Nilai Mahasiswa (UNF)

- - - - - Kelompok Berulang - - - - - Nim Nama Alamat Kecamatan KdPos Kode

MK Mata Kuliah SKS Nilai

0800 Ari Haji senen

Palmerah 12450 M0456 Sistem basisdata

4/0 A

M0123 Analisa dan perancangan SI

4/2 B

M0068 Konsep SI 4/0 C 0700 Pao pao Daan

mogot Cilandak 11480 M0013 Manajemen

Proyek 4/0 A

T0203 B. Inggris II 2/0 B

T0234 Character Building

2/0 C

0900 Mathias 12540 M0054 Object Oriented Database

4/0 D

42

Normalisasi Data Pertama (First Normal Form/1NF)

Untuk mengubah bentuk Unnormalized Form menjadi 1NF, yang harus

dilakukan adalah mengidentifikasi dan menghilangkan kelompok berulang, agar

setiap pertemuan antara baris dan kolom berisi satu dan hanya satu nilai. Dilihat

dari contoh bentuk Unnormalized sebelumnya, dapat diidentifikasi kelompok

berulang sebagai berikut : Hari, waktu, KdMtk, MataKuliah, SKS, Ruang dan

Kelas.

Langkah – langkah membuat normal pertama dari bentuk unnormal :

1. Menentukan 1 atau lebih atribut sebagai atribut kunci dari tabel unnormal.

2. Mengidentifikasi repeating group dari suatu tabel unnormal yang mengulang

atribut kunci di atas.

3. Menghilangkan repeating group, dapat dilakukan dengan 2 cara.

4. Mengisi kolom dari baris yang kosong dengan data – data yang sesuai atau

5. Menempatkan data yang berulang beserta key-nya ke dalam tabel baru.

Hasil dari bentuk 1NF dapat dilihat pada tabel berikut :

43

Tabel Nilai Mahasiswa

Tabel 2.2 : Tabel Nilai Mahasiswa (1NF)

Normalisasi Data kedua (Second Normal Form/2NF)

Pada tahap normalisasi 2NF dihilangkan setiap Partial dependence yang

ada pada bentuk 1NF. Yang dimaksud dengan partial dependence adalah atribut

non primary key yang merupakan sebagian fungsi dari primary key, atau dapat

dijelaskan demikian apabila terdapat atribut – atribut dalam suatu relasi yang

memiliki ketergantungan fungsional misalnya atribut A (Kd_dosen, Nama) dan

atribut B (KdMtk), dikatakan partial dependence apabila ada sebagian atribut dari

A dihilangkan namun ketergantungan masih ada. Langkah membuat 2NF dari 1NF :

1. Mengidentifikasi primary key dari bentuk 1NF.

2. Mengidentifikasi functional dependency pada bentuk 1NF.

Nim Nama Alamat Kecamatan KdPos Kode MK

Mata Kuliah SKS Nilai

0800 Ari Haji senen

Palmerah 12450 M0456 Sistem basisdata

4/0 A

0800 Ari Haji senen

Palmerah 12450 M0123 Analisa dan perancangan SI

4/2 B

0800 Ari Haji senen

Palmerah 12450 M0068 Konsep SI 4/0 C

0700 Pao pao Daan mogot

Cilandak 11480 M0013 Manajemen Proyek

4/0 A

0700 Pao pao Daan mogot

Cilandak 11480 M0123 Analisa dan perancangan SI

4/2 B

0700 Pao pao Daan mogot

Cilandak 11480 T0234 Character Building

2/0 C

0900 Mathias Jln. U Pondok labu

12540 M0456 Analisa dan perancangan SI

4/2 A

44

3. Bila terdapat partial dependency dalam primary key maka tempatkan primary

key tersebut dalam suatu tabel baru beserta field – field yang berkaitan

dengannya

Tabel 2.3 : Ketergantungan Fungsional pada Tabel Nilai Mahasiswa

Mahasiswa Nim Nama Alamat KdPos Kecamatan 0800 Ari Haji Senen 12450 Palmerah 0700 Pao Pao Daan mogot 11480 Cilandak 0900 Mathias Jln. U 12540 Pondok Labu

Tabel 2.4 : Tabel Mahasiswa (2NF)

Mata Kuliah

Kode MK Mata Kuliah SKS M0456 Sistem basisdata 4/0 M0123 Analisa dan perancangan SI 4/2 M0068 Konsep SI 4/0 M0013 Manajemen Proyek 4/0 T0234 Character Building 2/0

Tabel 2.5 : Tabel Mata Kuliah (2NF)

Nim Nama Alamat KdPos Kecamatan Kode MK

MataKuliah SKS Nilai

PK PK PK - - - - - Partial Dependence - - - - -

- - - Partial Dependence - - - TransitiveDependence

45

Daftar Nilai

NIM Kode MK Nilai 0800 M0456 A 0800 M0123 B 0800 M0068 C 0800 M0013 A 0700 M0123 B 0700 T0234 C 0900 M0456 A

Tabel 2.6 : Tabel Daftar Nilai (2NF)

Tabel dalam bentuk 2ND-NF: ketergantungan Parsial dipisahkan

Normalisasi Data Ketiga (Third Normal Form/3NF)

Pengujian terhadap bentuk normal ketiga dilakukan dengan cara melihat

apakah terdapat atribut bukan key tergantung fungsional terhadap atribut bukan key

yang lain (disebut ketergantungan transitive) Pada tahap normalisasi 3NF

dihilangkan setiap Transitive dependence yang terdapat pada bentuk 2NF. Kondisi

transitive dependence dapat diterangkan sebagai berikut : misalkan terdapat atribut

A,B dan C yang mempunyai relasi A→B dan B→C, C adalah transitive

dependence terhadap A melalui B.

Ketergantungan transitif (transitive dependency) terjadi ketika ada atribut

yang bukan merupakan primary key, yang memiliki ketergantungan pada atribut

lain yang juga bukan merupakan primary key

Langkah – langkah membuat 3NF dari 2NF :

1. Mengidentifikasi primary key pada bentuk 2NF.

2. Mengidentifikasi functional dependency dalam tabel tersebut.

46

3. Bila terdapat transitive dependency pada primary key maka tempatkan primary

key beserta field –field yang berkaitan pada tabel baru.

Proses Normalisasi secara umum dilakukan sampai ke tahap 3NF karena

sudah tidak terdapat data pengulangan, dan anomali yang ada sudah sangat sedikit

Mahasiswa

Nim Nama Alamat Kd Pos 0800 Ari Haji Senen 12450 0700 Pao Pao Daan mogot 11480 0900 Mathias Jln. U 12540

Tabel 2.7 : Tabel Mahasiswa (3NF)

Mata Kuliah

Kode MK Mata Kuliah SKS M0456 Sistem basisdata 4/0 M0123 Analisa dan perancangan SI 4/2 M0068 Konsep SI 4/0 M0013 Manajemen Proyek 4/0 T0234 Character Building 2/0

Tabel 2.8 : Tabel Mata Kuliah (3NF)

Nilai Mahasiswa

Nim Kode MK Nilai 0800 M0456 A 0800 M0123 B 0800 M0068 C 0800 M0013 A 0700 M0123 B 0700 T0234 C 0900 M0456 A

Tabel 2.9 : Tabel Nilai Mahasiswa (3NF)

47

Wilayah

Kode Pos Kecamatan 12450 Palmerah 11480 Cilandak 12540 Pondok Labu

Tabel 2.10 : Tabel Wilayah (3NF)

Tabel dalam bentuk 3rd-NF : Ketergantungan Transitif dipisahkan

Jika hasil Normalisasi Ketiga diatas digambarkan dengan diagram E-R,

maka akan diperoleh gambaran skema database sebagai berikut :

Wilayah Mata Kuliah

Mahasiswa Nilai

Gambar 2.13 : Entity Hasil Normalisasi

2.2.16 Siklus Hidup Aplikasi Database

Menurut Connolly dan Begg (2002, p273-p293), siklus hidup aplikasi

database terdiri dari sepuluh tahapan yaitu :

48

Pengumpulan danAnalisa Kebutuhan

Perencanaan Database

Perancangan DatabaseLogikal

Perancangan DatabaseKonseptual

Definisi Sistem

Pemilihan DBMS

Prototyping

Perancangan DatabaseFisikal

Perancangan Aplikasi

PemeliharaanOperasional

Pengujian

Implementasi

Pengubahan danPeng-loadan Data

PerancanganDatabase

Gambar 2.14 : Siklus Hidup Aplikasi Database

2.2.16.1 Perencanaan Database

Menurut Connolly dan Begg (2002, p273), perencanaan database

adalah sebuah aktifitas pengaturan yang memungkinkan langkah-langkah dari

aplikasi database direalisasikan seefektif dan efisien mungkin.

49

Hal pertama yang dilakukan adalah mendefinisikan pernyataan

sistem bagi proyek database. Pernyataan misi mendefinisikan tujuan utama

dari aplikasi database. Pernyataan misi membantu mengklarifikasi tujuan dari

proyek database dan menyediakan jalur yang lebih jelas terhadap pembuatan

aplikasi database yang efisien dan efektif.

Aktifitas selanjutnya mendefinisikan tujuan misi. Setiap tujuan

misi harus mengidentifikasikan tugas tertentu yang harus didukung oleh

aplikasi database Jika database mendukung tujuan misi, pernyataan misi

harus disesuaikan. Pernyataan dan tujuan misi harus diselesaikan dengan

informasi tambahan yang ditentukan seperti : kegiatan yang harus dilakukan,

sumber daya apa yang digunakan, dan biaya yang harus dibayarkan

2.2.16.2 Definisi Sistem

Menurut Connolly dan Begg (2002, p274), definisi sistem adalah

suatu kegiatan yang menjelaskan bidang dan batasan dari aplikasi database

dan user view utama. Batasan dan bidang sistem yang kita buat harus

ditentukan tidak hanya untuk pengguna dan area aplikasi saat ini, namun juga

untuk pengguna dan area aplikasi di masa depan.

2.2.16.3 Pengumpulan dan Analisa Kebutuhan

Menurut Connolly dan Begg (2002, p276), pengumpulan dan

analisa kebutuhan merupakan sebuah proses pengumpulan dan penganalisaan

informasi tentang bagian organisasi yang harus didukung oleh aplikasi

database, dan menggunakan informasi ini untuk mengidentifikasi kebutuhan

50

pengguna bagi sistem yang baru. Informasi yang didapatkan dari setiap user

view utama (peran kerja atau area aplikasi perusahaan) adalah

Deskripsi data yang digunakan atau dibuat

Penjelasan bagaimana data digunakan atau dibuat

Berbagai kebutuhan tambahan bagi aplikasi dastabase yang baru

Dalam tahapan ini, jumlah data yang diperoleh tergantung masalah

dan kebijakan perusahaan. Informasi yang terkumpul pada tahapan ini

mungkin tidak terstruktur dan melibatkan beberapa permintaan informal yang

harus diubah ke dalam kebutuhan yang lebih terstruktur. Terdapat dua

pendekatan dalam tahapan ini yaitu pendekatan terpusat dan pendekatan view

integration

2.2.16.4 Perancangan Database

Menurut Connolly dan Begg (2002, p279), perancangan database

merupakan sebuah proses pembuatan sebuah rancangan bagi database yang

akan mendukung operasi dan tujuan perusahaan.

2.2.16.4.1 Tahap-Tahap Perancangan Database

Menurut Connolly dan Begg (2002, p 417-p502), tahap-tahap

perancangan database dibagi menjadi tiga bagian, yang mana masing-

masing bagian terdapat beberapa tahap yaitu :

1. Perancangan Database Konseptual

Menurut Connolly dan Begg (2002, p419), perancangan

database konseptual adalah sebuah proses pembuatan model dari

informasi yang digunakan dalam perusahaan, yang terbebas dari semua

51

pertimbangan fisikal seperti DBMS target, program aplikasi, bahasa

pemrograman, hardware dan sebagainya. Perancangan database

konseptual terbagi menjadi beberapa tahap yaitu :

Langkah 1 : Membangun model data konseptual lokal bagi setiap

view

Bertujuan untuk membangun model data konseptual lokal dari

sebuah perusahaan bagi setiap view tertentu. Selama analisa, sejumlah

user view telah diidentifikasi dan tergantung pada jumlah overlap antara

view tersebut. Beberapa user view mungkin telah dikombinasikan

bersama untuk membentuk view bersama yang diberi nama yang sesuai.

Setiap model data konseptual lokal terdiri dari :

Entitas

Relationship

Atribut dan domain atribut

Primary key dan alternate key

Batasan integritas

Di dalam langkah satu ini melibatkan beberapa aktifitas yaitu :

a. Mengidentifikasi Entitas

Bertujuan untuk mengidentifikasi entitas utama yang

dibutuhkan oleh view. Sebuah metode untuk mengidentifikasi entitas

adalah dengan memeriksa spesifikasi kebutuhan pengguna. Dari

spesifikasi ini, kita mengidentifikasi kata benda atau frase benda (ex :

52

nomor staf, nama staf, nomor properti, alamat properti dsb). Kita juga

mencari objek utama (ex : manusia, tempat, kejadian, dan konsep

b. Mengidentifikasi Relationship

Bertujuan untuk mengidentifikasi relationship penting yang

terdapat antara entitas yang telah diidentifikasi. Dalam mengidentifikasi

relationship kita dapat menggunakan grammar dari spesifikasi

kebutuhan pengguna. Secara khusus, relationship ditandai dengan kata

kerja atau ekspresi verbal (ex : Staf mengatur Properti, Pemilik

mempunyai Properti, Properti berhubungan dengan Pelepasan)

c. Mengidentifikasi Dan Menghubungkan Atribut Dengan Entitas atau

Relationship

Bertujuan untuk menghubungkan atribut dengan entitas atau

relationship yang sesuai. Di sini kita mencari kata benda atau frase

benda dalam spesifikasi kebutuhan pengguna. Atribut dapat

diidentifikasi di mana kata benda atau frase benda merupakan sebuah

sifat, kualitas, identifier, atau karakteristik dari entitas atau relationship

d. Menentukan Domain Atribut

Bertujuan untuk menentukan domain bagi atribut di dalam

model data konseptual lokal. Domain merupakan sebuah kolam nilai

dari satu atau lebih atribut yang menggambarkan nilai mereka.

Pengembangan model data yang utuh menentukan domain bagi setiap

atribut termasuk :

53

- Sekelompok nilai yang diperbolehkan bagi atribut

- Ukuran dan format atribut

e. Menentukan Atribut Primary Key dan Candidate Key

Bertujuan untuk mengidentifikasi candidate key bagi setiap

entitas dan jika terdapat lebih dari satu candidate key, pilihlah satu untuk

dijadikan primary key. Ketika memilih sebuah primary key diantara

candidate key, gunakanlah panduan berikut untuk membantu membuat

pilihan :

- Sebuah Candidate Key dengan sekelompok atribut yang minim

- Sebuah Candidate Key yang paling sedikit mempunyai perubahan

nilai

- Sebuah Candidate Key dengan karakter paling sedikit (bagi atribut

tekstual)

- Sebuah Candidate Key dengan nilai maksimum terkecil (bagio

atribut numerik)

- Sebuah Candidate Key yang paling mudah digunakan dari sudut

pandang pengguna

f. Mempertimbangkan Penggunaan Konsep Pemodelan Lebih Lanjut

Bertujuan untuk mempertimbangkan penggunaan konsep

pemodelan lebih lanjut, seperti spesialisasi/generalisasi, aggregasi, dan

composition. Jika kita memilih pendekatan spesialisasi, kita berusaha

untuk memperhatikan perbedaan antara entitas dengan mendefinisikan

satu atau lebih entitas subclass dari entitas superclass. Jika kita

54

menggunakan pendekatan generalisasi, kita berusaha mengidentifikasi

fitur umum antara entitas untuk mendefinisikan pen-generalisasian

entitas superclass. Kita menggunakan aggregasi untuk menggambarkan

relationship ’mempunyai’ atau ’bagian dari’ antara entitas di mana yang

satu menggambarkan ’keseluruhan’ dan yang lainnya menggambarkan

’bagian’. Kita menggunakan composition untuk menggambarkan

hubungan antara entitas di mana terdapat hubungan yang sangat erat

antara ’keseluruhan’ dan ’bagian’

g. Memeriksa Model untuk Pengulangan

Bertujuan untuk memeriksa keberadaan berbagai pengulangan

di dalam model. Terdapat dua aktifitas di dalam tahap ini yaitu :

- Memeriksa kembali relationship one-to-one (1:1)

- Menghilangkan relationship yang berulang

h. Memvalidasi Model Konseptual Lokal Terhadap Transaksi User

Bertujuan untuk memastikan bahwa model konseptual lokal

mendukung transaksi yang diperlukan oleh view. Dengan menggunakan

model tersebut, kita berusaha untuk membentuk operasi secara manual.

Jika kita dapat memecahkan semua transaksi dalam cara ini, kita telah

memastikan bahwa model data konseptual mendukung transaksi yang

diperlukan. Ada dua pendekatan untuk memastikan bahwa model data

konseptual lokal mendukung transaksi yang diperlukan yaitu :

- Menjelaskan transaksi

- Menggunakan transaction pathway

55

i. Mereview Model Data Konseptual Lokal Dengan User

Bertujuan untuk mereview model data konseptual lokal dengan

pengguna untuk memastikan bahwa model tersebut merupakan

gambaran yang sebenarnya dari view. Model data konseptual termasuk

ER diagram dan dokumen pendukung lainnya yang menjelaskan model

data. Jika terdapat kesalahan di dalam model data, kita harus membuat

perubahan yang sesuai, yang mungkin memerlukan kembali ke tahap

sebelumnya.

2. Perancangan Database Logikal

Menurut Connolly dan Begg (2002, p441), perancangan

database logikal merupakan sebuah proses pembuatan model dari

informasi yang digunakan dalam sebuah perusahaan berdasarkan pada

model data tertentu, tetapi terbebas dari DBMS tertentu dan

pertimbangan fisikal yang lainnya. Dalam bagian ini terdapat beberapa

tahap yaitu :

Langkah 2 : Membangun dan memvalidasi model data logikal lokal

bagi setiap view

Bertujuan untuk membangun model data logikal lokal dari

model data konseptual lokal yang menggambarkan view tertentu dari

sebuah perusahaan dan kemudian memvalidasi model tersebut untuk

memastikan bahwa model terstruktur dengan baik dan mendukung

transaksi yang diperlukan.

56

Untuk menyederhanakan proses ini kita memasukkan langkah

opsional yaitu menghilangkan fitur yang tidak dapat digambarkan secara

langsung di dalam model relasional. Kita juga memvalidasi skema

relasional menggunakan aturan normalisasi untuk memastikan skema

tersebut terstruktur dengan baik.

Kita memvalidasi model logikal untuk memastikan bahwa

model tersebut mendukung transaksi yang diberikan dalam spesifikasi

kebutuhan pengguna. Model data logikal lokal yang tervalidasi

digunakan sebagai dasar untuk prototyping, dan kemudian kita

tambahkan batasan integritas ke dalam model. Di dalam langkah ini

melibatkan beberapa aktifitas yaitu :

a. Menghilangkan Fitur yang Tidak Sesuai dengan Model Relasional

Bertujuan untuk memperbaiki model data konseptual lokal

untuk menghilangkan fitur yang tidak sesuai dengan model relasional.

Dalam tahap ini kita mengubah struktur yang rumit ke dalam bentuk

yang lebih mudah ditangani oleh sistem. Tujuan dari tahap ini adalah

untuk :

- Menghilangkan relationship binary many-to-many (*:*)

- Menghilangkan relationship recursive many-to-many (*:*)

- Menghilangkan relationship yang kompleks

- Menghilangkan atribut multi-value

57

b. Mendapatkan Relasi Bagi Model Data Logikal Lokal

Bertujuan untuk membuat relasi bagi model data logikal lokal

untuk menggambarkan entitas, relationship, dan atribut yang telah

teridentifikasi. Kita menjelaskan composition menggunakan DDL bagi

database relasional.

Kita pertama kali menentukan nama relasi diikuti oleh daftar

atribut sederhana relasi di dalam tanda kurung. Kita kemudian

mengidentifikasi primary key dan berbagai alternate dan atau foreign

key dari relasi. Berdasarkan identifikasi foreign key, relasi yang berisi

primary key referensi diberikan. Berbagai derived atribut juga

didaftarkan bersama bersama bgaimana setiap atribut tersebut dihitung

c. Memvalidasi Relasi Menggunakan Normalisasi

Bertujuan untuk memvalidasi relasi di dalam model data

logical lokal menggunakan teknik normalisasi. Normalisasi digunakan

untuk meningkatkan model sehingga model tersebut memenuhi berbagai

batasan yang menghindari duplikasi data yang tak perlu. Normalisasi

memastikan bahwa hasil model mendekati model perusahaan yang

digambarkan, konsisten, dan mempunyai pengulangan yang minim serta

mempunyai kestabilan yang maksimal.

d. Memvalidasi Relasi Terhadap Transaksi User

Bertujuan untuk memastikan bahwa relasi di dalam model data

logikal lokal mendukung transaksi yang diperlukan oleh view. Dalam

tahap ini, kita memeriksa bahwa relasi yang dibuat pada tahap

58

sebelumnya juga mendukung transaksi tersebut, dan dengan demikian

dipastikan tidak ada kesalahan yang terjadi selama pembuatan relasi

e. Mendefinisikan Batasan Integritas

Bertujuan untuk menjelaskan batasan integritas yang diberikan

dalam view. Batasan integritas merupakan batasan yang kita tentukan

untuk melindungi database untuk menjadi tidak konsisten. Pada tahap

ini kita hanya memfokuskan pada rancangan tingkat tinggi yaitu

menentukan batasan integritas apa yang diperlukan, bukan bagaimana

hal ini dicapai. Setelah mengidentifikasi batasan integritas, kita akan

mempunyai model data logikal lokal yaitu gambaran yang lengkap dan

akurat dari view. Terdapat 5 Jenis batasan integritas yaitu :

- Data yang diperlukan

- Batasan domain atribut

- Batasan entitas

- Batasan referensial

- Batasan perusahaan

f. Mereview Model Data Logikal Lokal Dengan User

Bertujuan untuk memastikan bahwa model data logikal lokal

dan dokumen pendukung lainnya yang menjelaskan model tersebut

adalah gambaran sebenarnya dari view.

59

Langkah 3 : Membangun dan memvalidasi model data logikal

global

Bertujuan untuk mengkombinasikan model data logikal lokal

individu ke dalam model data logikal global tunggal yang

menggambarkan perusahaan. Kemudian memvalidasi model global,

pertama terhadap aturan normalisasi, dan yang ke dua terhadap transaksi

yang dijelaskan dalam semua view.

Kita melakukan normalisasi hanya pada relasi yang berubah

selama proses penggabungan dan memvalidasi model tersebut bagi

transaksi yang memerlukan akses ke area model yang mengalami

perubahan. Di dalam langkah ini melibatkan beberapa tindakan yaitu :

a. Menggabungkan Model Data Logikal Lokal ke Dalam Model Global

Bertujuan untuk menggabungkan model data logikal lokal

individu ke dalam model data logikal global tunggal dari perusahaan.

Kita menggunakan model data logikal lokal untuk mengidentifikasi

persamaan dan perbedaan antara model tersebut dan dengan demikian

membantu menggabungkan model bersama-sama. Cara ini relatif mudah

bagi aplikasi database yang sederhana. Namun dibutuhkan beberapa

tugas untuk melakukan teknik ini bagi aplikasi database yang kompleks

yaitu :

- Mereview nama dan isi entitas/relasi dan candidate key mereka

- Mereview nama dan isi relationship/foreign key

- Menggabungkan entitas/relasi dari model data lokal

60

- Memasukkan (tanpa menggabungkan) entitas/relasi unik ke setiap

model data lokal

- Menggabungkan relationship/foreign key dari model data lokal

- Memasukkan (tanpa menggabungkan) relationship/foreign key unik

ke setiap model data lokal

- Memeriksa entitas/relasi dan relationship/foreign key yang

terabaikan

- Memeriksa foreign key

- Memeriksa batasan integritas

- Menggambarkan ER global/diagram relasi

- Meng-update dokumentasi

b. Memvalidasi Model Data Logikal Global

Bertujuan untuk memvalidasi relasi yang dibuat dari model

data logikal global menggunakan teknik normalisasi dan untuk

memastikan mereka mendukung transaksi yang diperlukan. Tahap ini

hanya diperlukan untuk memeriksa area dari model yang dihasilkan

dalam berbagai perubahan selama proses penggabungan.

c. Memeriksa Perkembangan Di Masa Depan

Bertujuan untuk menentukan apakah terdapat banyak

perubahan yang signifikan yang mungkin dapat diketahui di masa depan

dan untuk menilai apakah model data logikal global dapat menangani

perubahan ini. Merupakan hal yang penting model data logikal global

dapat dikembangkan dengan mudah. Jika model hanya dapat

61

mendukung kebutuhan saat ini, maka keberadaan model tersebut akan

relatif singkat. Sehinnga model tersebut perlu dikembangkan agar

mampu mendukung kebutuhan yang baru dengan pengaruh yang minim

pada pengguna.

d. Mereview Model Data Logikal Global Dengan User

Bertujuan untuk memastikan bahwa model data logikal global

adalah gambaran yang sebenarnya dari perusahaan

3. Perancangan Database Fisikal

Menurut Connolly dan Begg (2002, p478), perancangan

database fisikal adalah sebuah proses pembuatan deskripsi implementasi

database pada tempat penyimpanan kedua. Perancangan ini menjelaskan

relasi dasar, organisasi file, dan index yang digunakan untuk mencapai

akses yang efisien ke data dan berbagai batasan integritas yang

berhubungan serta penilaian keamanan. Di dalam perancangan ini

terdapat beberapa tahap yaitu :

Langkah 4 : Menterjemahkan model data logikal global bagi DBMS

target

Bertujuan untuk menghasilkan skema database relasional dari

model data logikal global yang dapat diimplementasikan dalam DBMS

target. Bagian pertama dari proses ini adalah mengumpulkan informasi

yang diperoleh selama perancangan database logikal dan

terdokumentasi dalam kamus data. Bagian kedua adalah menggunakan

informasi ini untuk membuat rancangan relasi dasar. Proses ini

62

memerlukan pengetahuan yang mendalam dari fungsi yang ditawarkan

oleh DBMS target. Di dalam langkah ini melibatkan beberapa aktifitas

yaitu :

a. Merancang Relasi Dasar

Bertujuan untuk memutuskan bagaimana menggambarkan

relasi dasar yang telah teridentifikasi di dalam model data logikal global

dalam DBMS target. Dalam tahap ini, kita pertama kali menyusun dan

memahami informasi tentang relasi yang dibuat selama perancangan

database logikal. Informasi yang diperlukan dapat diperoleh dari kamus

data dan definisi relasi yang dijelaskan menggunakan DDL. Definisi

relasi terdiri dari :

- Nama Relasi

- Daftar atribut sederhana di dalam tanda kurung

- Primary key, alternate key, dan foreign key

- Daftar berbagai derive atribut dan bagaimana mereka seharusnya

dihitung

- Batasan integritas referensial bagi berbagai foreign key yang

teridentifikasi

Dari kamus data, kita juga mempunyai definisi bagi setiap

attribute yaitu :

- Domain-nya, terdiri dari jenis data, panjang, dan berbagai batasan

pada domain

- Nilai default opsional bagi atribut

63

- Apakah atribut dapat menyimpan nilai null

b. Merancang Gambaran Data yang Diperoleh

Bertujuan untuk memutuskan bagaimana menggambarkan

berbagai derived data yang terdapat di dalam model data logikal global

di dalam DBMS target. Seringkali derived atribut tidak ditampilkan

dalam model data logikal tetapi didokumentasikan dalam kamus data.

Jika derived atribut ditampilkan dalam model, sebuah tanda ’/’

digunakan untuk menandai bahwa atribut tersebut adalah atribut derived.

c. Merancang Batasan Perusahaan

Bertujuan untuk merancang batasan perusahaan bagi DBMS

target. Perancangan batasan yang demikian tergantung pada pilihan

DBMS, di mana setiap dari DBMS menyediakan fasilitas dan standard

yang berbeda-beda.

Langkah 5 : Merancang gambaran fisikal

Bertujuan untuk menentukan organisasi file yang optimal untuk

menyimpan relasi dasar dan index yang diperlukan untuk mencapai

performa yang diinginkan, yaitu sebuah cara di mana relasi dan tuple

akan disimpan pada tempat penyimpanan kedua. Tujuan utama dari

perancangan database fisikal adalah untuk menyimpan data dalam cara

yang efisien. Ada beberapa faktor yang digunakan untuk menilai

efisiensi yaitu :

- Transaction throughput : Hal ini berkaitan dengan jumlah transaksi

yang dapat diproses dalam selang waktu yang diberikan. Di dalam

64

beberapa sistem, transaction throughput yang tinggi merupakan hal

yang penting untuk keberhasilan menyeluruh dari sistem,

- Waktu tanggap : Dari sudut pandang pengguna mereka

menginginkan waktu tanggap yang sesedikit mungkin pada aplikasi

database yang dibuat.

- Penyimpanan hardisk : Merupakan jumlah ruang yang diperlukan

untuk menyimpan file database. Kita menginginkan jumlah yang

minimum dari ruang hardisk yang digunakan untuk menyimpan.

Ketiga faktor tersebut harus dilaksanakan secara seimbang

antara satu dan yang lainnya. Selain itu kita juga harus memahami

sumberdaya sistem yang digunakan Terdapat lima aktifitas dalam tahap

ini yaitu :

a. Menganalisa Transaksi

Bertujuan untuk memahami fungsi dari transaksi yang akan

berjalan pada database dan untuk menganalisa transaksi yang penting.

Oleh karena itu, kita perlu mempunyai pengetahuan tentang transaksi

yang akan berjalan pada database, baik kuantitatif maupun kualitatif.

Terdapat beberapa kriteria performa dari transaksi yang berusaha

diidentifikasi yaitu :

- Transaksi yang berjalan secara berkala dan akan mempunyai

pengaruh yang signifikan pada performa.

- Transaksi yang penting untuk operasi bisnis

65

- Waktu selama sehari/seminggu ketika di sana akan banyak

permintaan yang dibuat pada database

Kita menggunakan informasi tersebut untuk mengidentifikasi

bagian dari database yang dapat menyebabkan masalah performa. Kita

juga perlu mengidentifikasi fungsi tingkat tinggi dari transaksi seperti

atribut yang di-update dalam transaksi update atau sebuah kriteria yang

digunakan untuk membatasi tuple yang diperoleh dari query. Kita

menggunakan informasi ini untuk memilih organisasi file dan index yang

sesuai. Ada beberapa tindakan yang dilakukan dalam menganalisa

transaksi yaitu :

- Memetakan semua jalur transaksi pada relasi

- Menentukan relasi yang paling sering diakses oleh transaksi

- Menganalisa penggunaan data dari transaksi yang terpilih yang

melibatkan relasi transaksi tersebut

b. Memilih Organisasi File

Bertujuan untuk menentukan organisasi file yang efisien bagi

setiap relasi dasar. Dalam beberapa kasus, DBMS relasional hanya

memberikan sedikit atau tidak ada pilihan untuk memilih organisasi file,

walaupun ada beberapa yang dibuat sebagai index yang ditentukan.

Terdapat beberapa jenis organisasi file :

- Heap

- Hash

- B*Tree

66

- Index Sequenial Access Method (ISAM)

- Cluster

c. Memilih Index

Bertujuan untuk menentukan apakah dengan penambahan

index akan meningkatkan performa sistem. Sebuah pendekatan yang

dapat digunakan untuk memilih index yaitu dengan menentukan index

primary atau clustering. Jika atribut yang dipilih merupakan key dari

relasi index akan menjadi primary index. Jika atribut bukan merupakan

sebuah key, index akan menjadi clustering index

d. Memperkirakan Kebutuhan Ruang Hardisk

Bertujuan untuk memperkirakan jumlah ruang hardisk yang

diperlukan oleh DBMS. Hal ini tergantung pada DBMS target dan

hardware yang digunakan untuk mendukung database Pengukuran

didasarkan pada ukuran tiap tuple dan jumlah tuple dalam relasi

Langkah 6 : Merancang user view

Bertujuan untuk merancang user view yang telah teridentifikasi

selama tahap pengumpulan dan penganalisaan kebutuhan dari siklus

hidup aplikasi database relasional.

Langkah 7 : Merancang Penilaian Keamanan

Bertujuan untuk merancang penilaian keamanan bagi database

yang ditentukan oleh pengguna. Database menggambarkan sumberdaya

perusahaan yang penting sehingga keamanan dari sumberdaya tersebut

sangatlah penting. Selama tahap pengumpulan dan analisa kebutuhan,

67

kebutuhan keamanan tertentu harus sudah didokumentasikan di dalam

spesifikasi kebutuhan sistem. Tujuan dari tahap ini adalah

merealisasikan kebutuhan keamanan yang telah ditentukan.

2.2.16.5 Pemilihan DBMS

Menurut Connolly dan Begg (2002, p284), pemilihan DBMS

merupakan pemilihan sebuah DBMS yang sesuai untuk mendukung aplikasi

database. Pemilihan DBMS amatlah diperlukan ketika sebuah perusahaan

ingin mengembangkan atau mengganti sistem yang sudah ada, proses ini

digunakan untuk mengevaluasi produk DBMS. Tujuan dari pemilihan DBMS

adalah untuk memilih sebuah sistem yang sesuai dengan kebutuhan saat ini

dan yang akan datang pada perusahaan, menyeimbangkan biaya pembelian

produk DBMS, berbagai software/hardware tambahan yang diperlukan untuk

mendukung sistem database, dan biaya yang berhubungan dengan perubahan

dan pelatihan staf Berikut adalah langkah-langkah untuk memilih DBMS

yang baik :

- Menjelaskan istilah referensi pembelajaran

- Mendaftarkan dua atau tiga produk

- Mengevaluasi produk

- Merekomendasikan pilihan dan membuat laporan

2.2.16.6 Perancangan Aplikasi

Menurut Connolly dan Begg (2002, p287), rancangan aplikasi

yaitu perancangan antarmuka pengguna dan program aplikasi yang digunakan

dan memproses database. Aktivitas antara database design dengan

68

application design terjadi secara paralel. Dalam banyak hal, tidak mungkin

untuk menyelesaikan perancangan aplikasi sampai perancangan dari database

itu sendiri. Dalam hal ini, database hadir untuk mendukung aplikasi dan harus

ada aliran informasi antara application design dan database design.

Seluruh fungsi – fungsi yang tercantum dalam spesifikasi

kebutuhan pengguna harus ada dalam perancangan aplikasi, untuk aplikasi

database yang meliputi perancangan program aplikasi yang mengakses basis

data dan melakukan transaksi. Perancangan user interface yang tepat ke dalam

aplikasi database menjadi kebutuhan tambahan agar fungsi yang dibutuhkan

tercapai. Perancangan user interface kadang – kadang tidak diperhatikan atau

ditinggalkan selama tahapan perancangan. Program aplikasi yang mudah

dipelajari, sederhana dalam penggunaan, maka pengguna cenderung untuk

dapat memanfaatkan dengan baik. Hal ini menunjukkan bahwa user interface

merupakan salah satu komponen penting dari sistem. Terdapat dua aspek

penting dalam perancangan aplikasi yaitu:

2.2.16.6.1 Perancangan Transaksi

Menurut Connolly dan Begg (2002, p288), transaksi

merupakan sederetan tindakan yang dilakukan oleh pengguna

tunggal atau program aplikasi yang mengakses atau mengubah isi

database. Transaksi menggambarkan kejadian dunia nyata seperti

pendaftaran, penambahan anggota baru, penambahan pelanggan baru

dsb. Transaksi digunakan untuk database untuk memastikan bahwa

data yang terdapat dalam database sesuai dengan situasi dunia nyata

69

dan mendukung kebutuhan informasi pengguna. Tujuan dari

perancangan transaksi untuk mendefinisikan dan

mendokumentasikan karakteristik transaksi tingkat tinggi yang

diperlukan pada database yaitu :

- Data yang digunakan oleh transaksi

- Karakteristik fungsional dari transaksi

- Hasil transaksi

- Kepentingan terhadap pengguna

- Nilai harapan penggunaan

Terdapat tiga jenis utama transaksi yaitu :

- Retrieval transaction : Digunakan untuk mengambil data untuk

ditampilkan pada layar atau di dalam hasil laporan

- Update transaction : Digunakan untuk memasukkan record baru,

menghapus record lama, atau memodifikasi record yang ada di

dalam database

- Mixed transaction : Melibatkan pengambilan dan peng-update-

an data

2.2.16.6.2 Perancangan User Interface

Menurut Connolly dan Begg (2002, p289), terdapat

beberapa langkah dalam membuat rancangan antarmuka yang baik

bagi aplikasi database yaitu :

- Judul yang berarti

- Instruksi yang komprehensif

70

- Rancangan permintaan secara visual dari laporan

- Label field yang dikenal

- Singkatan dan istilah yang konsisten

- Penggunaan warna yang konsisten

- Batasan dan ruang yang terlihat bagi field data-entry

- Pergerakkan kursor yang baik

- Perbaikkan kesalahan bagi karakter individu dan keseluruhan

field

- Pesan kesalahan bagi nilai yang tak sesuai

- Penandaan field opsional yang jelas

- Pesan penjelasan bagi field

- Sinyal penyelesaian

2.2.16.7 Implementasi

Menurut Connolly dan Begg (2002, p292), implementasi adalah

realisasi fisik dari rancangan aplikasi dan database. Implementasi database

dicapai dengan menggunakan DDL dari DBMS yang dipilih atau GUI yang

menyediakan fungsi yang sama selama penyembunyian statement DDL

tingkat rendah. DDL digunakan untuk membuat struktur database dan file

database kosong.

Program aplikasi diterapkan menggunakan bahasa tingkat tiga atau

empat. Bagian dari program aplikasi ini adalah transaksi database, yang

diterapkan menggunakan DML yang dapat dijalankan pada sekumpulan

bahasa pemrograman, seperti Visual Basic, Delphi, C, C++, Java, COBOL,

71

Fortran, Ada atau Pascal. Digunakan juga komponen lain dari perancangan

aplikasi seperti menu layar, form masukkan data dan laporan – laporan.

Keamanan dan integritas dalam aplikasi juga diterapkan.

2.2.16.8 Pengubahan dan Peng-load-an Data

Menurut Connolly dan Begg (2002, p 292), pengubahan dan peng-

load-an data adalah pentransferan berbagai data yang ada ke dalam database

yang baru dan pengubahan berbagai aplikasi yang ada untuk berjalan pada

database yang baru. Tahapan ini dibutuhkan hanya ketika sistem database

yang baru menggantikan sistem yang lama. Sekarang ini, sudah menjadi hal

yang biasa bagi sebuah DBMS untuk mempunyai utilitas yang dapat memuat

keseluruhan file yang ada ke dalam database yang baru. Utilitas biasanya

membutuhkan spesifikasi dari sumber dan tujuannya, sehingga mengubah data

sesuai dengan format basis data yang baru.

2.2.16.9 Pengujian

Menurut Connolly dan Begg (2002, p293), pengujian adalah

sebuah proses pengeksekusian program aplikasi dengan maksud menemukan

kesalahan. Hal ini dicapai dengan strategi pengujian terencana yang hati-hati

dan data yang nyata sehingga proses pengujian seluruhnya ditangani dengan

metodologis dan benar. Jika proses pengujian berjalan dengan baik, hal ini

akan menemukan banyak kesalahan dalam program aplikasi dan struktur

database. Pengujian juga menunjukkan agar aplikasi database bekerja sesuai

dengan spesifikasi dan kebutuhan performa yang diinginkan. Hasil dari

72

pengujian dapat memberikan penilaian terhadap kehandalan dan kualitas

software.

2.2.16.10 Pemeliharaan Operasional

Menurut Connolly dan Begg (2002, p293), pemeliharaan

operasioanal adalah sebuah proses pemantauan dan pemeliharaan sistem

berikut instalasi. Dalam tahap ini melibatkan dua aktifitas yaitu :

- Pemantauan performa sistem. Jika performa berada jauh dibawah level

yang diharapkan, diperlukan perbaikkan atau penyusunan kembali

database

- Pemeliharaan dan peng-upgrade-an aplikasi database. Kebutuhan baru

dimasukkan ke dalam aplikasi database melalui tahap-tahap siklus hidup

aplikasi database yang sebelumnya.

2.3 Teori Pendukung

2.3.1 Penjualan

Menurut Mulyadi (2001,p202) penjualan terdiri dari transaksi penjualan

barang atau jasa baik secara kredit maupun tunai. Menurut Warren, Reeve, dan Fess

(2005), jumlah yang harus dibayarkan oleh pelanggan atas barang yang dijual bisa

secara kredit maupun secara tunai.

a. Penjualan tunai

Menurut Mulyadi (2001, p202), penjualan tunai dilakukan oleh perusahaan

dengan cara mewajibkan pembeli melakukan pembayaran harga terlebih dahulu

sebelum barang diserahkan oleh perusahaan kepada pembeli. Setelah uang diterima

73

perusahaan, barang kemudian diserahkan kepada pembeli dan transaksi penjualan

tunai kemudian dicatat oleh perusahaan.

b. Penjualan kredit

Menurut Mulyadi (2001, p203), penjualan kredit adalah penjualan yang

pembayarannya dilakukan beberapa waktu kemudian setelah pembeli menerima

barang yang dipesannya. Pembayaran biasanya dilakukan dalam jangka waktu yang

telah disepakati oleh kedua belah pihak. Menurut Mulyadi, penjualan kredit

dilaksanakan oleh perusahaan dengan cara mengirimkan barang sesuai dengan

pesanan yang diterima dari pembeli dan untuk jangka waktu tertentu perusahaan

menagih kepada pembeli tersebut.

2.3.2 Pembelian

Berdasarkan situs http://www.reference.com/search?q=purchasing, 2007

pembelian adalah fungsi di dalam bisnis di mana perusahaan mendapatkan input

bagi apa yang dihasilkan, yang sama baiknya dengan barang dan layanan yang lain

yang perusahaan tersebut perlukan. Dalam bisnis yang lebih besar, fungsi tersebut

biasanya ditangani di dalam departemen pembelian, yang dikepalai oleh manajer

pembelian. Departemen pembelian bertugas mengeluarkan PO bagi barang,

termasuk material dan peralatan.

2.3.2.1 Proses Dasar Pembelian

Berdasarkan situs http://www.reference.com/search?q=purchasing,

2007, proses pembelian dimulai ketika agen pembelian menerima daftar

permintaan, yang berupa permintaan bagi item atau layanan yang harus

dihasilkan. Pembeli kemudian mengevaluasi daftar permintaan untuk

74

menentukan supplier yang menyalurkan barang paling baik. Kemudian

membuat proposal permintaan barang kepada supplier. Pembeli juga akan

menentukan periode validitas dari permintaan tawaran yang dikenal sebagai

Bid due Date yaitu tanggal ketika pendaftaran proposal berakhir.

Setelah tawaran diterima oleh supplier, pembeli akan mengevaluasi

proposal dari supplier dan mentabulasi tawaran. Biasanya pada sebuah

spreadsheet. Tawaran tabulasi merupakan sebuah spreadsheet dengan

kategori yang digunakan untuk membandingkan setiap proposal supplier

untuk menentukan proposal paling baik yang sesuai dengan kebutuhan

pembeli. Setelah tawaran ditabulasikan, pembeli akan membuat keputusan

supplier mana yang akan direkomendasikan dan akan memberikan order serta

penjual akan memulai dalam penyuplaian material sesuai dengan perjanjian.

2.3.3 Persediaan

Menurut Rangkuti (2002), persediaan itu merupakan sejumlah bahan-bahan,

bagian-bagian yang disediakan dan bahan-bahan dalam proses yang terdapat dalam

perusahaan untuk proses produksi, serta barang jadi/produk yang terdapat dalam

perusahaan untuk proses produksi, serta barang-barang jadi/produk yang disediakan

untuk memenuhi permintaan dari konsumen atau langganan setiap waktu.

2.3.3.1 Sistem Aliran Persediaan Barang

Menurut Warren et al (2005), metode sistem yang akan digunakan

dalam pencatatan persediaan barang tergantung dari metode aliran persediaan.

Metode aliran persediaan barang yang dimaksud adalah cara penambahan dan

75

pengurangan barang dari gudang. Ada 2 macam aliran persediaan barang yang

biasa digunakan, yaitu :

a. FIFO (First In, First Out)

Menurut Warren et al (2005, p.448), metode ini mengatur aliran

persediaan barang dimana barang yang lebih dahulu masuk ke dalam gudang

akan keluar terlebih dahulu dengan harga barang yang bervariatif sesuai

dengan harga pada saat barang tersebut dibeli. Pada umumnya metode ini

dipakai pada perusahaan-perusahaan yang menjual produk yang mudah rusak

serta mudah ketinggalan zaman seperti buah-buah segar, sayuran, makanan

kaleng, minuman dan pakaian.

b. LIFO (Last In, First Out)

Menurut Warren et al (2005, p.449), metode ini mengatur aliran

persediaan barang dimana barang yang paling terakhir masuk itulah yang akan

dikeluarkan terlebih dahulu, dengan harga barang yang bervariatif sesuai

dengan harga barang tersebut dibeli. Contoh perusahaan yang menerapkan

metode ini pada umumnya terdapat pada perusahaan-perusahaan yang

memiliki tingkat perputaran (turn over) penjualan yang sangat tinggi.

Sehingga barang yang dijual diambil berdasarkan barang yang paling akhir

diperoleh

2.3.4 Rich Picture

Menurut Mathiasen et al, (2000) Rich Picture merupakan gambaran

informal yang menggambarkan pemahaman penggambar terhadap situasi. Sebuah

Rich Picture memfokuskan pada aspek penting sebuah situasi yang ditentukan oleh

76

penggambar. Bagaimanapun, Rich Picture harus memberikan deskripsi yang luas

dari situasi yang memungkinkan penggunaan beberapa alternatif

2.3.4.1 Penggambaran Rich Pictures

Menurut Mathiasen et al, (2000) dalam penggambaran Rich Picture,

orang sangat sering menjadi pusat dari Rich Picture. Orang dapat berupa

pengembang sistem, para pengguna, para pelanggan, atau yang lainnya. Selain

itu juga terdapat objek fisik yang dapat berupa berbagaimacam benda. Berikut

adalah contoh-contoh objek fisik di dalam Rich Picture :

a. Di dalam pabrik objek dapat berupa mesin dan peralatan atau barang di

dalam gudang

b. Di dalam kantor administrasi objek dapat berupa dokumen-dokumen dan

formulir-formulir

c. Tempat menjelaskan lokasi dari benda atau orang-orang tersebut

d. Organisasi mungkin dapat berupa sebuah perusahaan, departemen

perusahaan, atau proyek yang melibatkan beberapa perusahaan

Pada prinsipnya, tidak ada batasan terhadap jenis-jenis bentuk simbol

yang dapat digunakan untuk menggambarkan sebuah Rich Picture

2.3.5 State Diagram

Menurut http://en.wikipedia.org/wiki/StateDiagram , 2007 State Diagram

adalah suatu diagram yang memiliki notasi-notasi yang terstandarisasi yang dapat

menjelaskan berbagai macam hal, dari program komputer hingga proses bisnis.

Berikut ini adalah elemen notasi dasar yang dapat digunakan untuk membuat state

diagram :

77

a. Fillled Circle : menandakan inisial state

b. Hollow Circle : menandakan final state

c. Rounded Rectangle : menandakan sebuah state, di mana di dalamnya berisi

nama sebuah state

d. Arrow : menandakan sebuah transisi, di mana di situ terdapat nama kejadian

yang menyebabkan transisi tersebut.