bab 2 landasan teori 2.1 teori umum 2.1.1 sistemthesis.binus.ac.id/doc/bab2/2008-1-00288-si bab...
TRANSCRIPT
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.