BAB 2 LANDASAN TEORI
2.1
Pengertian Data dan Informasi Item data merupakan penjelasan dasar mengenai segala sesuatu, peristiwa,
aktivitas, dan transaksi yang dicatat, diklasifikasikan, serta disimpan, tetapi tidak diatur untuk mengungkapkan makna tertentu. Basis data terdiri dari berbagai item data yang disimpan dan diatur untuk dapat ditarik kembali (Rainer, Turban, 2006, p52). Informasi merupakan data yeng telah diatur sehingga memiliki makna dan nilai bagi penerimanya. Penerima informasi akan mengartikan maksud dari informasi dan menarik kesimpulan serta berbagai implikasi dari data tersebut. 2.2
Pengertian Teknologi Informasi dan Sistem Informasi Sistem Informasi adalah proses menjalankan fungsi mengumpulkan, memproses,
menyimpan, menganalisis, dan menyebarkan informasi untuk tujuan tertentu; kebanyakan sistem informasi dikomputerisasi, tetapi tidak harus komputerisasi (Rainer, Turban, 2006, p48). Teknologi informasi adalah kumpulan sumber daya informasi perusahaan, para penggunanya, serta manajemen yang menjalankannya; meliputi infrastruktur teknologi informasi dan semua sistem informasi lainnya dalam perusahaan. Infrastruktur teknologi informasi meliputi proses integrasi, operasi, dokumentasi, pemeliharaan, dan manajemennya.(Rainer, Turban, 2006, p49).
9
10 2.3
Teori-Teori Basis Data 2.3.1
Definisi Basis Data Basis data adalah merupakan kumpulan data yang berhubungan secara
logikal, dan keterangan di dalamnya, yang di rancang untuk memenuhi informasi yang dibutuhkan dalam suatu organisasi (Begg, Connolly, 2005, p15). Basis data merupakan suatu kesatuan, penyimpanan data yang besar yang dapat digunakan secara bersamaan oleh banyak departemen dan pengguna. Sedangkan menurut Adi Nugroho (2008, p1), basis data merupakan kumpulan/koleksi
data-data
yang
terorganisasi
yang
disimpan
di
tempat
penyimpanan komputer (biasanya bersifat permanen) dan dirancang serta diorganisasikan sedemikian rupa sehingga mudah dicari, diakses, dan dimanipulasi (diubah, ditambahkan, serta dihapus) oleh pengguna. Data-data tersebut mungkin berupa teks, angka-angka, maupun grafik, dan dimasa kini, pengertian data(sesuai yang diakomodasi oleh Oracle Corp.) bisa diperluas menjadi selain tipe-tipe data yang telah disebutkan-suara, gambar, foto, serta video. Orang-orang yang mengatur dan mengelola Basis data disebut DBA (Database Administrator). 2.3.2
Relational Model Struktur data relasional mempunyai istilah-istilah sebagai berikut (Begg,
Connolly, 2005, p72): a.
Relation, merupakan sebuah tabel yang berisi kolom dan baris
b.
Attribute, merupakan nama kolom suatu relasi
c.
Domain, merupakan kumpulan nilai-nilai yang bernilai valid pada atribut tertentu
11 d.
Tuple, merupakan sebuah baris dari sebuah relasi
e.
Degree, merupakan jumlah atribut yang dikandung
f.
Cardinality, merupakan jumlah tuple dalam suatu relasi
g.
Relation Database, merupakan kumpulan dari tabel-tabel yang telah melewati proses normalisasi dengan relasi yang unik
2.3.3
Relational Key Tidak ada tuple yang sama dalam suatu relasi. Maka dari itu, harus mampu
mengidentifikasi satu atau lebih atribut yang secara unik mengidentifikasi setiap tuple dalam suatu relasi. Atribut-atribut tersebut disebut dengan suatu relational key (Begg, Connolly, 2005, p78). Relational key terdiri dari : a. Superkey, yang merupakan suatu atribut, atau sekumpulan atribut, yang mengidentifikasi tuple secara unik dalam suatu relasi. b. Candidate key, merupakan superkey sedemikian sehingga tidak ada bagian yang tepat dari superkey dalam relasi. c. Primary
key,
merupakan
candidate
key
yang
dipilih
untuk
mengidentifikasi tuple yang unik dari relasi. d. Foreign key, merupakan sebuah atribut, atau sekumpulan atribut, yang ada pada suatu relasi, yang sama dengan candidate key dari beberapa relasi. 2.3.4
Database Management System (DBMS) Menurut Connolly dan Begg (Begg, Connolly, 2005, p16) Database
Management System (DBMS) adalah merupakan suatu perangkat lunak yang
12 memungkinkan pengguna untuk mendefinisikan, membuat, merawat, dan melakukan kontrol akses terhadap basis data. DBMS mempunyai fasilitas sebagai berikut: •
Memungkinkan pengguna untuk mendifinisikan Basis data, biasanya melalui
sebuah
Data
Definition
Language
(DDL).
DDL
memungkinkan pengguna untuk mengelompokkan tipe data, struktur, dan batasan terhadap data yang akan disimpan dalam basis data •
Dapat memungkinkan pengguna untuk melakukan pemasukan (insert), perubahan (update), penghapusan (delete), dan pengambilan (retrieve) data dari basis data, biasanya melalui Data Manipulation Language (DML). DML memungkinkan pengguna untuk melakukan operasi query pada basis data
•
Menciptakan akses kendali ke basis data. Sebagai contoh DBMS menyediakan: -
Sebuah sistem keamanan, yang dapat mencegah pengguna yang tidak mempunyai wewenang untuk mengakses basis data.
-
Sebuah sistem integrasi, yang menjaga konsistensi data yang tersimpan
-
Sebuah sistem kendali yang memungkinkan basis data untuk diakses secara bersamaan.
-
Sebuah kendali sistem recovery, yang memungkinkan basis data untuk mengembalikan basis data ke kondisi konsisten yang
13 sebelumnya jika terjadi kesalahan, termasuk kesalahan perangkat keras dan perangkat lunak -
Sebuah katalog yang dapat diakses oleh pengguna, yang mengandung penjelasan dari data yang terdapat di dalam basis data yang ada.
2.3.4.1
Komponen Database Management System (DBMS) Menurut Conolly dan Begg (Begg, Connolly, 2005, p18), DBMS
mempunyai lima komponen utama : hardware, software, data, procedure, dan manusia (pengguna). •
Hardware (Perangkat Keras) DBMS dan aplikasi membutuhkan perangkat keras untuk menjalankan suatu proses. Hardware dapat dijangkau dari suatu komputer tunggal, ke sebuah mainframe tunggal, pada suatu jaringan komputer.
•
Software (Piranti Lunak) Komponen piranti lunak yang meliputi software DBMS itu sendiri dan program-program aplikasi beserta Operating System (OS), termasuk piranti lunak jaringan, bila DBMS digunakan pada suatu jaringan LAN.
•
Data Data adalah komponen yang paling penting dalam DBMS, khususnya dari titik sudut pandang pangguna akhir yang berhubungan dengan data.
14 •
Prosedur Prosedur dapat berupa instruksi dan aturan-aturan yang mengatur rancangan dan penggunaan basis data. Pengguna dari sistem dan pekerja yang mengatur basis data membutuhkan dokumentasi petunjuk mengenai bagaimana cara mengoperasikan sistem. Instruksi tersebut dapat berupa cara untuk melakukan: -
Log on ke dalam DBMS
-
Menggunakan fasilitas DBMS tertentu atau program aplikasi
-
Memulai (start) dan mengakhiri (stop) DBMS
-
Membuat backup duplikasi dari basis data
-
Menangani kesalahan pada perangkat keras (hardware) atau perangkat lunak (software).
-
Mengubah struktur sebuah tabel, merancang kembali basis data melintasi banyak disk, meningkatkan kemampuan, atau mendapatkan data dari penyimpanan kedua/cadangan.
•
Manusia (person) atau Sumber Daya Manusia (SDM) Manusia yang terlibat langsung dalan sistem dibagi atas 4 bagian, yaitu (Begg, Connolly, 2005, p22): -
Data dan Database Administrators Data Administrator (DA) bertanggung jawab terhadap managemen sumber data meliputi perencanaan basis data, pengembangan dan standar pemeliharaan, prosedur dan kebijakan, dan desain konseptual logikal basis data.
15 Database Administrator (DBA) bertanggung jawab terhadap pelaksanaan secara fisik dari database, seperti desain dan implementasi fisik database, kendali kemanan dan integritas, perawatan sistem operasional, dan menjamin kepuasan pengguna -
Database designer Terdiri dari dua tipe designer, yaitu logical database designer dan physical database designer . Logical database designer yaitu orang yang memperhatikan identifikasi data (entities dan attribute), hubungan diantara data, dan batasan dari data yang disimpan pada basis data. Physical database designer adalah orang yang menentukan bagaimana logical database designer dapat terlaksana secara fisik
-
Pengembang Aplikasi (Application Developer) Yaitu orang yang bekerja untuk spesifikasi yang telah dibuat oleh system analist
-
Pengguna Akhir (End-user) Merupakan siapa saja yang menggunakan aplikasi untuk memperoleh informasi dari sebuah sistem basisdata
16 2.3.4.2
Fungsi dari DBMS DBMS menciptakan beberapa tipe fungsi dan pelayanan (Begg,
Connolly, 2005, p48). Diantaranya adalah : •
Data Storage, Retrieval, and Update Sebuah
DBMS
harus
mampu
melayani
pengguna
dengan
kemampuan untuk menyimpan, menelusuri kembali, dan melakukan pengubahan data dalam basis data. •
Sebuah user-accessible catalog Sebuah
DBMS
harus
menyediakan
sebuah
catalog
yang
menjelaskan data yang disimpan dan yang dapat diakses oleh pengguna. •
Transaction support DBMS harus menyediakan sebuah mekanisme yang menjamin semua perubahan terhadap suatu transaksi atau tidak akan terjadi perubahan sama sekali.
•
Concurrency Control Services DBMS harus menyediakan sebuah mekanisme yang menjamin basis data berubah dengan benar ketika banyak pengguna melakukan perubahan pada basis data secara bersamaan.
•
Recovery services Sebuah DBMS harus menyediakan sebuah mekanisme untuk melakukan recovery terhadap basis data ketika basis data rusak dengan cara apapun.
17 •
Authorization Service Sebuah DBMS harus menyediakan mekanisme untuk memastikan bahwa hanya pengguna yang mempunyai wewenang yang dapat mengakses basis data.
•
Mendukung Komunikasi Data Sebuah DBMS harus mempunyai kemampuan untuk berintegrasi dengan perangkat lunak komunikasi
•
Integrity services DBMS harus mengidentifikasikan suatu cara untuk menjamin data yang terdapat di dalam basis data beserta perubahannya mengikuti aturan-aturan yang tepat.
•
Services to promote Data Independence DBMS harus mengandung fasilitas untuk mendukung kemandirian program dari struktur basis data aktual.
•
Utility service DBMS harus menyediakan sekumpulan Utility services agar basis data dapat berjalan secara efektif.
2.3.5
Relational Database Management System (RDBMS) Dalam penelitian, digunakan perangkat lunak Oracle Database 10g yang
merupakan Relational Database Management System (RDBMS). Penemu konsep Basis Data Relasional adalah Peter Chen, sedangkan pencipta RDBMS adalah DR.Ted Codd (Adi Nugroho, 2008, p4).
18 Basis data relasional adalah tipe basis data atau sistem manajemen basis data yang menyimpan data-data dalam bentuk tabel, terdiri dari baris-baris data dan kolom-kolom data dimana data pada kolom dan baris tertentu terkadang dapat digunakan sebagai rujukan pencarian data yang berkaitan di tabel yang lain (Adi Nugroho, 2008, p4). Perhatikan gambar tabel 2.1.3.1 dibawah NIM 5184025
Nama Adi Nugroho
5183027
Ana Mariana
5184088
Esti Nugraheni
5184099
Eni Nugraheni Tabel Mahasiswa
No_MK 110011
Nama_MK Pascal
SKS 3
130012
C
3
130013
Basis Data Tabel Mata Kuliah
3
NIM 5184025
No_MK 110011
Nilai A
5184025
130013
A
5184088
110011 Tabel Pengambilan Mata Kuliah
C
Gambar 2.1 Contoh Basis Data Relasional Tabel pertama tertunjuk pada gambar 2.1 memperlihatkan data-data tentang mahasiswa tertentu, misalkan mahasiswa dengan NIM = 5184025 dengan nama Adi Nugroho, NIM = 5183027 dengan nama ana Mariana, dan selanjutnya. Tabel kedua
19 memperlihatkan data-data tentang mata kuliah, misalkan mata kuliah dengan No_MK = 110011 bernama pascal dengan jumlah SKS sebanyak 3 dan No_MK = 110012 dengan SKS sebesar 3 adalah mata kuliah C. Kemudian ketiga tabel memperlihatkan data-data mahasiswa yang mengambil mata kuliah tertentu beserta nilainya masing-masing, misalnya Adi Nugroho (NIM = 5184025) yang mengambil mata kuliah Pascal (No_MK = 110011) dan mendapatkan indeks nilai A dan Esti Nugraheni (NIM = 5184088) mengambil mata kuliah Pascal (No_MK = 110011) sudah mendapatkan nilai C. Kemudian beberapa mahasiswa, dengan nama Ana Mariana dan Eni Nugraheni (NIM = 5184099) ternyata tidak mengambil mata kuliah apa-apa (mungkin yang bersangkutan sedang cuti). Dalam basis data relasional, data-data disimpan dalam bentuk tabel (beberapa pihak menyebutnya sebagai relasi) dimana baris-baris pada tabel menyatakan rekaman-rekaman (record) dan kolom-kolom menyatakan field-field (atribut-atribut pada rekaman). Untuk memandu pencarian, basis data relasional mencocokan datadata dari salah satu tabel dengan data-data pada tabel lain dan menghasilkan tabel ketiga yang menggabungkan data-data dari kedua tabel (Adi Nugroho, 2008, p5). Basis data adalah himpunan dari relasi-relasi. Secara formal, setiap relasi ditampilkan dalam bentuk tabel atau sering disebut sebagai tabel datar (flat files) dari rekaman-rekaman (record). Selain itu relasi sering didefinisikan sebagai himpunan rekaman-rekaman. Dalam berkas-berkas basis data, rekaman-rekaman (record) secara fisik tersimpan di media simpan tertentu sehingga ada hubungan atau relasi antara satu dengan yang lain.
20 Setiap nilai dalam atribut suatu rekaman harus bernilai atomik, yang artinya tidak dapat dibagi lagi menjadi komponen-komponen dalam kerangka model relasional sehingga atribut bernilai banyak tidak diizinkan. RDBMS memiliki 3 aspek utama, yaitu : •
Data ditampilkan sebagai tabel-tabel 2 dimensi. Tabel-tabel memiliki nomor-nomor yang spesifik bagi setiap baris dan kolom dan suatu data disimpan pada baris dan kolom tertentu. Kolom-kolom memperlihatkan atribut-atribut dan setiap baris mewakili data-data untuk suatu objek.
•
Operator untuk memanipulasi tabel-tabel. SQL (Structured Query Language) adalah bahasa basis data bertipe relasional. Dalam hampir segala hal menyangkut administrasi basis data, oracle menggunakan sintaks-sintaks SQL. Selain itu, suatu pengembangan dari bahasa pemrograman nir-prosedural SQL yang khas Oracle, yaitu : PL/SQL (Programming
Language
/
Structured
Query
Language),
juga
dikembangkan Oracle Corp. Demi peningkatan kemampuan SQL baku •
Referencial
Integrity.
Referencial
Integrity
merupakan
sarana
penghubung utama pada suatu basis data relasional sehingga basis data pada suatu tabel dapat berhubungan dengan data yang berada pada tabel lain, melalui penggunaan primary key dan foreign key
21 2.3.6
Database Language Sebuah sub bahasa data dibagi menjadi dua bagian yaitu : Data Definition
Language (DML) dan Data Definition Language (DML). DDL digunakan untuk menspesifikasikan skema basisdata dan DML digunakan untuk membaca dan mengubah basisdata (Begg, Connolly, 2005, p39). 2.3.6.1
The Data Definition Language DDL
(Data
Definition
Language)
merupakan
bahasa
yang
memungkinkan DBA (database administrator) atau user untuk menjelaskan dan memberi nama entitas, atribut, dan hubungan yang dibutuhkan untuk aplikasi, bersama dengan beberapa hubungan intergrasi dan batasan keamanan (Begg, Connolly, 2005, p40). Contoh operasi yang dapat dilakukan oleh DDL adalah sebagai berikut (Begg, Connolly, 2005, p168) : a. Create Table Digunakan untuk menciptakan tabel dengan melakukan definisi tipe data pada masing-masing kolom. b. Alter table Digunakan untuk mengubah kolom yang ada dan mengubah batasan pada suatu tabel, c. Drop table Digunakan untuk menghapus tabel yang tidak digunakan beserta semua data yang ada didalamnya. d. Create Index Digunakan untuk melakukan index dalam suatu tabel,
22 e. Drop Index Digunakan untuk menghapus index yang diciptakan sebelumnya.
f. Create View Digunakan untuk membuat sebuah virtual relation. g. Drop View Digunakan untuk menghapus view, 2.3.6.2
The Data Manipulation Language (DML) DML merupakan sebuah bahasa yang menciptakan sekumpulan operasi
untuk mendukung operasi manipulasi data dasar pada data yang ada didalam basisdata. DML (Data Manipulation Language) menyediakan operasi dasar dalam basis data, diantaranya adalah : a) Memasukkan data baru kedalam basisdata (insertion) b) Perubahan
terhadap
data
yang
disimpan
dalam
basisdata
(modification) c) Pemanggilan data yang ada dari basisdata (retrieve) d) Menghapus data yang ada didalam basisdata (delete) DML dapat dibedakan menjadi 2 tipe yang berbeda, diantaranya adalah (Begg, Connolly, 2005, p41): a. Procedural DMLs Procedural language merupakan bahasa yang memperbolehkan user untuk memberitahu sistem mengenai data apa yang dibutuhkan dan bagaimana cara pemanggilannya (retrieve). DML memanggil
23 rekaman (record), dan memprosesnya, berdasarkan hasil yang diperoleh dari proses, memanggil rekaman lain yang harus diproses secara cara yamg sama, dan lainnya. b. Non-procedural DMLs Merupakan suatu bahasa yang memperbolehkan pengguna untuk menyatakan data apa yang dibutuhkan tanpa menspesifikasikan bagaimana cara mendapatkan data tersebut. 2.3.6.3
Fourth-Generation Language Fourth-Generation Language merupakan bahasa non-procedural
dimana pengguna menentukan apa yang akan diselesaikan, bukan bagaimana cara menyelesaikannya (Begg, Connolly, 2005, p42). Contoh 4 GL adalah SQL dan QBE. Beberapa tipe 4 GL adalah sebagai berikut : a. Forms Generator Merupakan fasilitas interaktif menciptakan data masukan secara cepat dan menampilkan tampilan. Mendefinisikan desain tampilan seperti apa, informasi apa yang akan ditampilkan, definisi warna pada layar. b. Report Generator Merupakan suatu fasilitas yang digunakan untuk membuat laporan dari data yang disimpan dalam basisdata. Report generator lebih mementingkan keluaran, yaitu bagaimana suatu laporan akan disajikan.
24 c. Graphic Generator Merupakan fasilitas yang digunakan untuk mengambil data dari basisdata. Memungkinkan pengguna untuk menampilkannya dalam bentuk grafik seperti bar, chart, pie chart, line chart dan lain-lain. d. Application generator Merupakan fasilitas untuk menghasilkan sebuah program yang merupakan interface dari basisdata.
25 2.3.7
Siklus Hidup Aplikasi Basis Data (Database Application Lifecycle) Sistem basis data merupakan komponen dasar dari organisasi besar dengan
sistem informasi yang luas. Daur hidup aplikasi basis data berkembang terhubung dengan daur hidup sistem informasi (Begg, Connolly, 2005, p283). Berikut ini adalah siklus hidup aplikasi basisdata pada gambar berikut :
Gambar 2.2 Tahapan-Tahapan Siklus Hidup Aplikasi Basisdata (Begg, Connolly, 2005, p284)
26 2.3.7.1
Perencanaan Database (Database Planning) Database Planning adalah aktivitas manajemen yang memungkinkan
tahapan-tahapan dari database system development lifecycle dapat direalisasikan dengan seefektif dan seefisien mungkin. Database planning harus diintegrasikan/dihubungkan dengan seluruh strategi sistem informasi (Begg, Connolly, 2005, p285). Ada 3 hal yang terlibat dalam penyusunan strategi sistem informasi : -
Identifikasi terhadap rencana dan sasaran usaha dengan rangkaian keputusan dari kebutuhan sistem informasi
-
Evaluasi terhadap sistem informasi yang sedang berjalan untuk mengetahui kekuatan dan kelemahannya
-
Penafsiran terhadap kesempatan teknologi informasi yang dapat memberikan keuntungan yang kompetitif
2.3.7.2
System Definition Pendefinisian sistem (System Definition) menjelaskan lingkup dan
batasan aplikasi basis data dan pandangan-pandangan utama dari para user/pengguna (Begg, Connolly, 2005, p286). Sebelum memutuskan untuk mendesain sebuah sistem basisdata, penting untuk mengidentifikasi batasan dari sistem yang sedang diselidiki dan bagaimana tampilannya dengan bagian lain dari sistem informasi organisasi. Batasan sistem sebaiknya tidak hanya sesuai dengan bidang dan batasan aplikasi basisdata serta pandangan pengguna yang telah ada saja pada saat ini, namun harus sesuai juga dengan kebutuhan pada masa yang akan datang.
27 Pandangan pengguna (user views) menentukan apa yang dibutuhkan dari sebuah sistem basisdata dari perspektif/pandangan suatu jabatan tertentu (seperti manager atau supervisor) atau area aplikasi perusahaan (seperti marketing, personnel, dan stock control). 2.3.7.3
Pengumpulan Kebutuhan dan Analisis (Requirement Collection and Analysis) Proses pengumpulan kebutuhan dan analisis merupakan proses
pengumpulan dan analisis informasi tentang bagian organisasi yang harus didukung oleh sistem basisdata, dan penggunaan informasi tersebut berguna untuk mengidentifikasi persyaratan pengguna untuk sistem yang baru (Begg, Connolly, 2005, p288). Informasi yang dikumpulkan pada langkah ini termasuk: -
Deskripsi dari data yang digunakan atau data yang di-generate
-
Detail mengenai bagaimana data digunakan atau di-generated
-
Kebutuhan-kebutuhan tambahan apapun untuk sistem basis data yang baru
2.3.7.4
Perancangan Basis Data (Database Design) Perancangan basisdata merupakan proses pembuatan suatu rancangan
yang akan mendukung operasi dan tujuan perusahaan untuk kebutuhan sistem basisdata (Begg, Connolly, 2005, p291). Terdapat 2 pendekatan dalam perancangan basisdata : b. Bottom-up Pendekatan bottom-up dimulai dari tingkat paling dasar dari suatu atribut (yaitu, properti dari entitas dan relasi) dimana melalui
28 analisis dari hubungan diantara atribut, dikelompokkan kedalam relasi-relasi yang merepresentasikan tipe entity dan hubunganhubungan diantara entity. Pendekatan ini cocok untuk perancangan sebuah basisdata sederhana, dengan jumlah atribut yang relatif kecil. Namun pendekatan ini akan sulit diterapkan dalam rancangan basis data yang lebih kompleks dengan jumlah atribut yang lebih besar, karena akan sulit untuk membangun semua ketergantungan fungsional diantara atribut. c. Top-down Pendekatan ini dimulai dari pengembangan model data yang terdiri dari beberapa hubungan relasional dan entity tingkat tinggi beserta hubungan-hubungannya, mengidentifikasi hubungannya,
kemudian
entitas-entitas serta
tingkat
mengasosiasikan
dilanjutkan rendah,
dengan hubungan-
atribut-atribut
yang
berhubungan. Pendekatan ini merupakan strategi yang lebih cocok untuk membuat sebuah basisdata yang lebih kompleks. Pendekatan ini biasanya digambarkan melalui ER (Entity Relationship) Perancangan database dibagi menjadi 3 tahapan yaitu, conceptual database design, logical database design, dan physical database design (Begg, Connolly, 2005, p439). 2.3.7.5
Pemilihan DBMS Merupakan suatu proses untuk memilih DBMS yang tepat untuk
mendukung sistem dari basisdata (Begg, Connolly, 2005, p295). Tahapan utama pemilihan DBMS adalah sebagai berikut :
29 a) Menentukan syarat-syarat referensi studi Tahapan ini merupakan prasyarat dalam menentukan DBMS yang sudah dijalankan, mulai dari menentukan tujuan, batasan masalah, dan tugas-tugas yang harus dilakukan. b) Mengurutkan dua atau tiga produk Ini merupakan proses membuat daftar barang-barang seperti sumber barang, biaya yang diperlukan lalu bagaimana cara untuk mendapatkannya. c) Mengevaluasi produk Barang-barang akan melalui proses penelitian pada beberapa tahap untuk mengetahui kelebihan ataupun kekurangan dari barang tersebut. d) Membuat laporan tentang pilihan yang direkomendasikan Merupakan langkah yang berkaitan dengan proses dokumentasi dan menciptakan pernyataan mengenai penemuan dan rekomendasi terhadap suatu produk DBMS tertentu. 2.3.7.6
Perancangan Aplikasi Perancangan aplikasi merupakan suatu proses perancangan dari user
interface dan program-program aplikasi yang menggunakan dan memproses basisdata (Begg, Connolly, 2005, p299). Basis data dan perancangan aplikasi adalah aktivitas yang paralel dari daur hidup sistem basisdata. Maka dari itu, pada banyak kasus merupakan suatu yang tidak mungkin untuk melengkapi perancangan aplikasi jika perancangan basisdata belum selesai.
30 2.3.7.7
Prototyping Prototyping adalah proses membangun sebuah kerangka kerja dari
sebuah aplikasi basisdata. Suatu prototype merupakan model yang tidak normal dan tidak mempunyai semua fitur yang dibutuhkan atau menyediakan semua fungsionalitas dari sistem terakhir. Tujuan utama dari pengembangan sebuah sistem basisdata prototype adalah memungkinkan pengguna menggunakan prototype tersebut untuk mengidentifikasi fitur-fitur dari sistem yang bekerja baik, atau memadai, dan jika mungkin menganjurkan peningkatan atau bahkan fitur-fitur baru pada aplikasi basisdata (Begg, Connolly, 2005, p304). Ada 2 strategi prototyping yang umum digunakan saat ini, yaitu : a) Requirement prototyping Strategi ini menggunakan sebuah prototype untuk menentukan berbagai kebutuhan dari sistem basisdata yang diusulkan. Apabila semua kebutuhan telah selesai ditentukan maka prototype tersebut tidak akan digunakan lagi. b) Evolutionary prototyping Strategi ini digunakan untuk tujuan yang sama, perbedaan yang penting adalah bahwa prototype tidak dibuang tetapi dengan pengembangan lebih jauh menjadi sistem basisdata yang bekerja. 2.3.7.8
Implementasi (Implementation) Implementasi merupakan realisasi fisik dari perancangan basisdata dan
perancangan aplikasi (Begg, Connolly, 2005, p304). Pada penyelesaian tahap perancangan (dimana mungkin atau tidak mengandung prototyping), sekarang dalam
posisi
mengimplementasikan
basisdata
dan
program
aplikasi.
31 Implementasi basisdata dapat dicapai menggunakan Data Definition Language (DDL) dari DBMS yang dipilih atau dari graphical user interface (GUI), yang menciptakan fungsionalitas yang sama ketika menyembunyikan pernyataan DDL tingkat rendah. Pernyataan DDL tersebut digunakan untuk menciptakan struktur basisdata dan file basisdata yang kosong. Program-program aplikasi dapat diimplementasikan menggunakan bahasa generasi ketiga atau keempat (3GL atau 4GL). Transaksi basis data diimplementasikan dengan menggunakan Data Manipulation Language (DML) dan merupakan bagian dari program aplikasi. Kendali integritas dan keamanan sebagian diimplementasikan menggunakan DDL, namun terdapat beberapa yang membutuhkan perangkat diluar DDL. 2.3.7.9
Pengubahan data dan pengambilan Merupakan proses transfer data yang ada kedalam basis data baru dan
mengubah aplikasi yang ada untuk berjalan pada basis data yang baru (Begg, Connolly, 2005, p305). Langkah ini dibutuhkan hanya ketika sebuah sistem basis data baru mengganti sistem yang lama. Saat ini, merupakan suatu hal yang umum untuk DBMS yang memiliki suatu peralatan yang dapat memuat file yang ada kedalam basis data yang baru. Peralatan biasanya membutuhkan spesifikasi dari sumber file dan basis data tujuan, dan kemudian secara otomatis mengubah data kedalam bentuk format yang dibutuhkan oleh basis data yang baru. 2.3.7.10 Pengujian (Testing) Merupakan proses pelaksanaan program aplikasi dengan tujuan untuk menemukan kesalahan. Sebelum dihidupkan, sistem basis data yang baru
32 dikembangkan harus seluruhnya diuji. Proses uji coba ini dilakukan dengan keadaan yang mendekati kenyataan bersangkutan dengan data-data yang nyata. 2.3.7.11 Pemeliharaan Operasional (Operational Maintenance) Merupakan proses pengawasan dan perawatan sistem basisdata berikut instalasi. Kegiatan yang dilakukan pada tahap ini adalah sebagai berikut : -
Memantau kinerja sistem
-
Merawat dan melakukan upgrade terhadap aplikasi basisdata (ketika dibutuhkan)
2.3.8
Tahap-Tahap Perancangan Basis Data Metode perancangan database dibagi menjadi tiga bagian utama (Begg,
Connolly, 2005, p293), yaitu : •
Perancangan Basis Data Konseptual Merupakan suatu proses membangun sebuah model dari data yang digunakan didalam suatu perusahaan, yang tidak tergantung dari seluruh pertimbangan fisik.
•
Perancangan Basis Data Logikal Merupakan suatu proses membangun sebuah model dari data yang digunakan pada suatu perusahaan berdasarkan pada data model yang spesifik, tetapi tidak tergantung pada Database Management System (DBMS) tertentu dan pertimbangan fisik lainnya.
•
Perancangan Basis data fisikal Merupakan suatu proses untuk menghasilkan sebuah gambaran dari implementasi basisdata pada tempat penyimpanan kedua, menjelaskan
33 dasar dari relasi, organisasi file dan indeks yang digunakan untuk mendapatkan efisiensi akses data dan menghubungkan beberapa batasan integritas dan tindakan keamanan. 2.3.8.1
Perancangan Basis Data Konseptual Langkah-langkah
dalam
metodologi
percancangan
basis
data
konseptual adalah sebagai berikut (Begg, Connolly, 2005, p442): • Langkah 1 – Membangun Local Conceptual Data Model - Langkah 1.1 Mengidentifikasi tipe entitas Tujuan dari langkah ini adalah untuk mengidentifikasi tipe entitas yang terutama dibutuhkan oleh pengguna. Satu metode untuk mengidentifikasi entitas adalah tentukan kebutuhan pengguna terlebih dahulu. Dan pada langkah ini dilakukan identifikasi kata benda atau frase kata benda pada spesifikasi kebutuhan pengguna, objek besar seperti orang, tempat, benda, atau konsep dapat digunakan untuk mencari tipe entitas. Cara lain adalah dengan mencari objek yang bebas. (Begg, Connolly, 2005, p443) - Langkah 1.2 Identifikasi tipe relasi Tujuannya adalah untuk mengidentifikasi relasi penting yang tersedia diantara tipe-tipe entitas (Begg, Connolly, 2005, p445) - Langkah 1.3 Mengidentifikasi dan menghubungkan atribut dengan entitas atau tipe relasi Tujuannya adalah untuk menghubungkan atribut dengan entitas atau tipe relasi yang tepat. Atribut yang dimiliki oleh setiap
34 entitas dan relasi wajib memenuhi karakteristik atribut yaitu simple/composite attribute, single/multi-valued attribute, dan derived attribute. (Begg, Connolly, 2005, p447) - Langkah 1.4 menentukan domain atribut Bertujuan untuk menentukan domain atribut didalam local conceptual data model. Sebuah domain adalah kumpulan nilai dimana satu atau lebih atribut memperoleh nilai true atau benar. Setiap atribut di dalam relasi ditetapkan dalam domain. (Begg, Connolly, 2005, p450) - Langkah 1.5 Menentukan atribut Candidate Key dan Primary Key Digunakan untuk identifikasi candidate key setiap tipe entitas, dan jika ada lebih dari satu candidate key, maka akan terpilih satu untuk menjadi primary key dan yang lain akan menjadi alternate key (Begg, Connolly, 2005, p451). Untuk memilih primary key diantara candidate key, pergunakan aturan berikut untuk membantu pemilihan primary key : Candidate key dengan minimal kumpulan dari atribut Candidate key dengan nilai yang paling sedikit berubah. Candidate key dengan jumlah karakter yang paling sedikit (untuk yang memiliki textual attributes) Candidate key dengan nilai maximum yang paling kecil (untuk yang dengan numerical attributes) Candidate key yang paling mudah digunakan dari sudut pandang pengguna.
35 - Langkah 1.6 Pertimbangkan penggunaan dari enhanced modeling concepts (langkah pilihan) Tujuannya adalah untuk mempertimbangkan penggunaan dari peningkatan
model
konsep,
seperti
specialization
/
generalization, generalization, aggregation, dan composition. Specialization adalah proses memaksimalkan perbedaan antara anggota sebuah entitas dengan mengidentifikasi karakteristik yang membedakan entitas tersebut. Generalization adalah proses
meminimalkan
perbedaan
antar
entitas
dengan
mengidentifikasi sifat umum entitas. Aggregation menunjukkan ’memiliki’ atau ’bagian dari’ relationship diantara tipe entitas, dimana yang satu menunjukkan ’keseluruhan’ dan ’bagian’ (Begg, Connolly, 2005, p453). - Langkah 1.7 Model pemeriksaan untuk redudancy Digunakan untuk memeriksa conceptual model agar terhindar dari redudansi dalam model (Begg, Connolly, 2005, p453). Dua kegiatan yang dilakukan pada hal ini adalah :
Memeriksa kembali One-to-one (1:1) Relationship. Dalam
mengidentifikasi
entitas,
mungkin
dapat
menemukan dua entitas atau lebih yang menggambarkan objek yang sama dalam suatu organisasi.
Menghilangkan Relasi redundant Sebuah relasi dikatakan redundant apabila informasi yang sama dapat diperoleh pada relasi lainnya.
36 - Langkah 1.8 melakukan validasi conceptual model dengan transaksi yang dilakukan pengguna Untuk memastikan bahwa local conceptual model mendukung transaksi yang dibutuhkan (Begg, Connolly, 2005, p456). Dua pendekatan yang memungkinkan untuk memastikan local conceptual data model mendukung kebutuhan transaksi :
Menggambarkan transaksi Memeriksa semua informasi (entities, relationship, dan attributes) yang dibutuhkan oleh setiap transaksi dan dihasilkan oleh model, dengan dokumentasi sebuah penjelasan dari setiap kebutuhan transaksi.
Menggunakan transaction pathways Melakukan validasi data terhadap kebutuhan transaksi dengan penggambaran diagram yang mewakili pathway yang diambil oleh setiap transaksi secara langsung pada diagram ER.
- Langkah 1.9 Melihat kembali conceptual data model bersama pengguna Untuk memastikan bahwa data model adalah merupakan representasi yang benar dari kebutuhan dari suatu organisasi (Begg, Connolly, 2005, p458).
37 2.3.8.2
Perancangan Basis Data Logikal Perancangan basis data logika adalah suatu proses pembangunan
sebuah model dari data yang digunakan di dalam suatu perusahaan berdasarkan sebuah model data yang spesifik, tetapi tidak bergantung pada suatu DBMS tertentu dan pertimbangan fisikal lainnya. (Begg, Connolly, 2005, p439). Langkah-langkah perancangan basis data logikal adalah sebagai berikut (Begg, Connolly, 2005, p462): • Langkah 2. Membangun dan melakukan validasi logical data model Tujuannya adalah untuk menerjemahkan conceptual data model kedalam logical data model dan kemudian memvalidasi model tersebut agar benar secara struktural dan mampu mendukung transaksi-transaksi yang dibutuhkan (Begg, Connolly, 2005, p462). Aktivitas yang ada pada langkah tersebut adalah : - Langkah 2.1 Menentukan Relasi-Relasi untuk logical data model Tujuannya adalah menciptakan relasi untuk logical data model untuk
merepresentasikan
entitas-entitas,
relasi-relasi, dan
atribut-atribut yang telah diidentifikasikan (Begg, Connolly, 2005, p463). Relationship yang mungkin terjadi pada model data konseptual: • Strong Entity Type Strong Entity Type adalah tipe entitas yang keberadaannya tidak bergantung (independent) pada beberapa tipe entitas lainnya. Karakteristik dari Strong entity type adalah setiap
38 tipe entiti yang terjadi dapat diidentifikasi secara unik menggunakan atribut primary key dari tipe entitas. Strong entity type sering disebut dengan parent atau owner atau dominant entities (Begg, Connolly, 2005, p354). • Weak Entity type Weak entity type adalah tipe entitas yang keberadaannya bergantung (dependent) pada beberapa tipe entitas lainnya. Weak entity type juga disebut dengan child, dependent, atau subordinate entities (Begg, Connolly, 2005, p355). • One-to-many (1:*) binary relationship types Untuk setiap 1:* binary relationship, entitas pada ‘satu sisi’ dari relasi dianggap sebagai entitas parent dan entitas pada ‘banyak sisi’ dianggap sebagai entitas child. Untuk merepresentasikan relasi ini, tampilkan
salinan atribut
primary key dari entitas parent ke dalam relasi yang merepresentasikan entitas child, untuk berlaku sebagai foreign key (Begg, Connolly, 2005, p465). • One-to-one (1:1) binary relationship types Membuat relasi-relasi yang memperlihatkan sebuah relasi 1:1 sedikit lebih kompleks karena cardinality tidak dapat digunakan untuk membantu mengidentifikasi entitas-entitas parent dan child dalam relasi (Begg, Connolly, 2005, p465). Kita mempertimbangkan bagaimana menciptakan relasi-
39 relasi untuk merepresentasikan participation constraint berikut: -
Mandatory Participation pada 2 sisi dari 1:1 relationship Pada kasus ini, harus digabungkan entitas yang terlibat kedalam satu relasi dan memilih salah satu dari primary key dari entitas-entitas aslinya untuk menjadi primary key pada relasi yang baru, sedangkan yang lainnya dijadikan alternate key. (Begg, Connolly, 2005, p466)
-
Mandatory Participation pada 1 sisi dari relasi 1:1 Pada kasus ini dapat diidentifikasi entitas-entitas parent dan child untuk relasi 1:1 dengan menggunakan participation constraint. Entitas yang mempunyai pilihan participation dalam relationship dianggap sebagai entitas parent, dan entitas yang mempunyai mandatory participation dalam relationship dianggap sebagai child. (Begg, Connolly, 2005, p466)
-
Optional Participation pada 2 sisi dari 1:1 relationship Primary key dapat dipilih berdasatkan atas kasus yang ada (Begg, Connolly, 2005, p467)
• One-to-one (1:1) recursive relationship types Untuk sebuah 1:1 recursive relationship, ikuti aturan yang dijelaskan diatas untuk sebuah 1:1 relationship.
40 Dalam kasus tertentu relasi 1:1, entity kedua sisi dari relationship
adalah
sama.
Untuk
1:1
recursive
relationship dengan mandatory participation pada 2 sisi, representasikan recursive relationship sebagai relasi tunggal dengan salinan 2 primary key. Sedangkan salah satu salinan dari primary key merepresentasikan foreign key dan harus dubah namanya untuk menandakan relationship yang direpresentasikan. (Begg, Connolly, 2005, p467) • Superclass/subclass relationship types Untuk setiap superclass / subclass relationship dalam conceptual
data
model,
dapat
diidentifikasi
entitas
superclass sebagai entiti parent dan entiti subclass sebagai entitas child. Pilihan yang paling sesuai tergantung dari sejumlah faktor seperti disjointnese dan participation constraint pada superclass/subclass relationship apakah subclass-subclass terlibat dalam distinct relationship dan jumlah participant dalam relasi superclass / subclass (Begg, Connolly, 2005, p467). • Many-to-many (*:*) binary relationship types Untuk setiap relasi biner many-to-many (*:*), buatlah relasi yang mewakili relasi dan mencakup seluruh atribut yang menjadi bagian dari relasi. Dilakukan penyalinan
41 atribut primary key untuk entity yang berpartisipasi didalam relasi kedalam relasi yang baru sebagai foreign key (Begg, Connolly, 2005, p469) . • Complex relationship types Untuk setiap relasi kompleks, buat sebuah relasi untuk merepresentasikan relasi dan meliputi semua atribut yang merupakan bagian dari relasi tersebut. Lalu buat salinan primary key dari entitas yang berhubungan dalam relasi kompleks kedalam relasi baru, untuk berlaku sebagai foreign key. • Multi-valued attributes Untuk setiap atribut yang memiliki banyak nilai yang ada pada entity, buatlah relasi untuk mewakili atribut multivalue dan mencakup primary key dari entity pada relasi yang baru sebagai foreign key (Begg, Connolly, 2005, p471). - Langkah 2.2 Melakukan validasi relasi dengan menggunakan normalisasi Tujuannya adalah untuk melakukan validasi terhadap relasirelasi dalam logical data model dengan menggunakan teknik normalisasi. (Begg, Connolly, 2005, p473). Normalisasi merupakan teknik untuk menghasilkan sekumpulan relasi-relasi dengan properti-properti yang diinginkan, sesuai
42 dengan kebutuhan data-data yang diberikan oleh suatu perusahaan (Begg, Connolly, 2005, p388). Tujuan dari normalisasi ini adalah untuk mengurangi redudansi data (pengulangan data) dan update anomaly. Update anomaly dibedakan menjadi 3, yaitu insert anomaly, update anomaly, dan modification anomaly/update anomaly. Delete anomaly adalah kejanggalan yang terjadi terhadap suatu tabel
pada
saat
dilakukan
penghapusan
suatu
record,
penghapusan bermaksud untuk menghapus suatu data tertentu tetapi menyebabkan kehilangan informasi lain dari tabel tersebut. Insert anomaly adalah kejanggalan yang terjadi terhadap sebuah tabel pada saat dilakukan penambahan suatu record yaitu berupa pelanggaran terhadap batasan integritas. Modification/update anomaly adalah kejanggalan yang terjadi pada suatu tabel pada saat dilakukan pengubahan suatu rekaman. (Begg, Connolly, 2005, p392). Proses dari normalisasi melewati tahap seperti berikut (Begg, Connolly, 2005, p401): a. First normal form (1NF), yang bertujuan menghilangkan perulangan data b. Second normal form (2NF), yang bertujuan untuk menghilangkan ketergantungan parsial pada Primary Key. c. Third Normal Form (3NF), yang bertujuan untuk menghilangkan ketergantungan transitif pada primary key.
43 - Langkah 2.3 melakukan validasi relasi pada transaksi user Langkah ini dilakukan untuk memastikan bahwa relasi didalam Local
logical
data
mendukung
model
transaksi
yang
integritas
yang
dibutuhkan. (Begg, Connolly, 2005, p474). - Langkah 2.4 memeriksa batasan integrity Bertujuan
untuk
memeriksa
batasan
direpresentasikan dalam logical data model (Begg, Connolly, 2005, p474). Batasan integritas dibagi menjadi 5 bagian, yaitu : a. Data yang dibutuhkan (Required Data) Beberapa atribut harus selalu mengandung nilai yang bernilai valid, dengan kata lain, tidak boleh diperbolehkan mempunyai nilai null. b. Batasan domain atribut Setiap atribut mempunyai domain, yaitu sekumpulan nilai yang pasti. c. Multiplicity Multiplicity merepresentasikan batasan yang ditempatkan pada relasi diantara data dalam basisdata. d. Integritas entitas Primary key dari sebuah entitas tidak boleh bernilai null. Batasan
ini
harus
dipertimbangkan
ketika
mengidentifikasi primary key untuk tiap tipe entitas.
kita
44 e. Integritas referensial Integritas referensial berarti jika foreign key berisi sebuah nilai, maka nilai tersebut harus menunjuk tuple yang ada di dalam relasi parent. Umumnya, jika partisipasi dari relasi child dalam relationship adalah mandatory, maka nilainya tidak boleh null. Tetapi jika partisipasi dari relasi child dalam relasi dapat dipilih, maka boleh null. f. Batasan umum Pengubahan pada entitas mungkin dapat diatur oleh batasan-batasan yang mengatur transaksi ’real world’ yang direpresentasikan oleh perubahan tersebut. - Langkah 2.5 Melihat ulang model local logical data dengan pengguna Bertujuan untuk melihat kembali logical data model untuk memastikan bahwa pengguna mempertimbangkan model data logikal untuk menjadi representasi yang sebenarnya dari kebutuhan data perusahaan. (Begg, Connolly, 2005, p478). - Langkah 2.6 Menggabungkan Local logical data model kedalam global model. Langkah ini bertujuan untuk merepresentasikan semua user views dari database (Begg, Connolly, 2005, p479). Langkahlangkahnya adalah sebagai berikut : a. Melihat kembali nama dan isi datri entitas/relasi serta candidate keys.
45 Bertujuan untuk mengidentifikasi munculnya dua masalah potensial sebagai berikut : o Memiliki nama yang sama, tetapi sebenarnya tidak sama (homonim) o Adalah sebenarnya sama, tetapi memiliki nama yang berbeda (sinonim) b. Melihat kembali nama dan isi dari relationship/foreign key c. Menggabungkan entitas/relasi dari model data lokal. d. Memasukkan (tanpa menggabungkan) entitas/relasi yang unik ke dalam setiap model data e. Menggabungkan relasi/foreign key dari local data model f. Memasukkan (tanpa menggabungkan) relasi / foreign key yang unik kedalam setiap model data g. Mengecek untuk entitas/relasi dan relasi / foreign key yang tertinggal. h. Mengecek foreign key i. Mengecek integrity constraint j. Menggambarkan diagram ER / relasi global k. Melakukan update dokumentasi. 2.3.8.3
Perancangan Basis Data Fisikal Perancangan basis data fisikal adalah proses membuat sebuah deskripsi
dari implementasi basis data pada penyimpanan kedua; mendeskripsikan relasi dasar, organisasi file, dan index yang digunakan untuk mendapatkan akses
46 efisien pada data dan semua integrity constraint yang berhubungan dan security measures (Begg, Connolly, 2005, p439). Langkah-langkah perancangan fisik database adalah sebagai berikut : • Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih Tujuannya adalah untuk menghasilkan skema basis data relasional dari data model logikal yang dapat diimplementasikan dalam target DBMS (Begg, Connolly, 2005, p497). Terdapat 3 langkah dalam tahap ini, yaitu : - Langkah 3.1 Mendesain relasi dasar Tujuannya
adalah
untuk
memutuskan
bagaimana
merepresentasikan relasi dasar yang diidentifikasikan dalam model data logikal dalam DBMS yang dipilih (Begg, Connolly, 2005, p498). - Langkah 3.2 Merancang Representasi untuk Derived data Tujuannya
adalah
untuk
memutuskan
bagaimana
merepresentasikan semua data derived yang ada dalam model data logikal dalam DBMS yang dipilih. Atribut yang nilainya dapat dicari dengan memeriksa nilai-nilai dari atribut lainnya yang diketahui sebagai ”derived” atau ”calculate attribute” (Begg, Connolly, 2005,p499). - Langkah 3.3 Merancang batasan umum Tujuannya adalah untuk merancang batasan umum pada DBMS yang dipilih (Begg, Connolly, 2005,p501).
47 • Langkah 4 Merancang organisasi file dan indeks Langkah ini mempunyai tujuan untuk menentukan organisasi file yang optimal untuk menyimpan relasi dasar dan indeks-indeks yang dibutuhkan untuk tercapainya performa yang daopat diterima, dengan begitu, relasi dan tuple akan dapat disimpan pada penyimpanan kedua (Begg, Connolly, 2005, p501). - Langkah 4.1 Menganalisa transaksi Tujuan pada langkah ini adalah untuk memahami fungsi dari transaksi-transaksi yang akan berjalan pada basis data dan untuk
menganalisa
transaksi-transaksi
penting
(Begg,
Connolly, 2005, p502). - Langkah 4.2 Memilih organisasi file Tujuannya adalah untuk menentukan sebuah organisasi file yang efisien untuk relasi dasar (Begg, Connolly, 2005, p506). - Langkah 4.3 Memilih index-index Tujuan dari langkah ini adalah untuk menentukan apakah dengan menambahkan indeks-indeks akan meningkatkan kemampuan dari suatu sistem (Begg, Connolly, 2005, p508). - Langkah 4.4 Memperkirakan kebutuhan disk space Tujuannya adalah untuk memperkirakan nilai dari disk space yang dibutuhkan oleh basisdata (Begg, Connolly, 2005, p514).
48 • Langkah 5. Merancang pandangan user. Tujuannya adalah untuk merancang pandangan pengguna yang diidentifikasikan selama pengumpulan kebutuhan dan tahapan analisis dari database system development lifecycle (Begg, Connolly, 2005, p515). • Langkah 6. Merancang mekanisme keamanan Tujuannya adalah untuk merancang mekanisme keamanan untuk basis data seperti yang ditentukan oleh pengguna pada saat pengumpulan kebutuhan dari database system development lifecycle (Begg, Connolly, 2005, p516). 2.3.9
Entity-Relationship Modeling
2.3.9.1
Entity Types Entity type adalah sekumpulan objek dengan properti yang sama, yang
diidentifikasikan oleh perusahaan serta keberadaannya yang mandiri (Begg, Connolly, 2005, p343). Sedangkan entity occurance adalah setiap objek yang diidentifikasikan secara unik.
Gambar 2.3 Representasi Diagram dari tipe entity staff dan Branch
(Begg, Connolly, 2005, p345)
49 2.3.9.2
Relationship Type Relationship Type adalah sekumpulan hubungan yanng mempunyai arti
diantara tipe entiti (Begg, Connolly, 2005, p346). Setiap tipe relasi memiliki nama yang menjelaskan fungsinya. Derajat dari relationship adalah jumlah dari partisi tipe entitas dalam sebuah tipe relationship tertentu. 2.3.9.3
Atribut Atribut adalah suatu properti dari sebuah entitas atau tipe relasi (Begg,
Connolly, 2005, p350). Domain attribute adalah sekumpulan nilai yang diperbolehkan untuk satu atau banyak atribut. Atribut dapat diklasifikasikan sebagai berikut : 1. Simple dan Composite Attribute Simple attribute adalah sebuah atribut yang disusun oleh sebuah komponen tunggal dengan keberadaan yang tidak tergantung. Simple attribute tidak dapat dipecah menjadi komponen yang lebih kecil lagi (Begg, Connolly, 2005, p351). Composite attribute adalah sebuah atribut yang disusun oleh banyak komponen, setiap komponen yang ada tersebut tidak tergantung/mandiri. Atribut ini dapat dipecah menjadi atribut yang lebih kecil. 2. Single-valued dan multi-valued attribute Single-valued
attribute
adalah
sebuah
atribut
yang
memegang nilai tunggal dari setiap kejadian dalam sebuah tipe entitas (Begg, Connolly, 2005, p351). Multi-valued
50 attribute adalah sebuah atribut yang mempunyai nilai lebih dari satu untuk setiap kejadian pada sebuah tipe entiti. Contohnya
pada
setiap
atribut
entity
Branch
dapat
mempunyai telNo lebih dari satu (misalnya cabang dari BranchNo B003 mempunyai telNo 0141-339-2178 dan 0141339-4439). 3. Derived attributes Derived attribute adalah atribut yang merepresentasikan sebuah nilai yang bisa diperoleh dari suatu nilai atribut atau sekelompok atribut yang berkaitan, dan tidak harus berasal dari satu entitas(Begg, Connolly, 2005, p352). 2.3.9.4
Keys Candidate key adalah kumpulan atribut minimal yang secara unik
mengidentifikasikan setiap kejadian dari sebuah tipe entity (Begg, Connolly, 2005, p352). Primary key adalah candidate key yang dipilih untuk mengidentifikasikan secara unik setiap kejadian dari sebuah tipe entitas. Composite key adalah sebuah candidate key yang terdiri dari dua atau lebih atribut. Alternate key adalah candidate key yang tidak dipilih menjadi primary key. 2.3.10
Normalisasi Normalisasi adalah sebuah teknik untuk menghasilkan relasi dengan
properti-properti yang diinginkan, memberikan kebutuhan data dari sebuah perusahaan (Begg, Connolly, 2005, p388). Tujuan normalisasi adalah untuk
51 mengidentifikasi sekumpulan relasi yang benar dan diperlukan oleh perusahaan. Karakteristik dari sekumpulan relasi yang benar adalah sebagai berikut : 1. Jumlah atribut yang minimal yang berguna untuk mendukung kebutuhan data dari perusahaan 2. Atribut dengan relasi logikal yang dekat (dijelaskan sebagai ketergantungan fungsional) ditemukan pada relasi yang sama 3. Redudansi minimal dengan setiap atribut direpresentasikan hanya sekali dengan pengecualian atribut penting dalam bentuk semua atau bagian foreign key yang diperlukan untuk menggabungkan relasi yang terkait. Terdapat 3 tahap dalam proses normalisasi sehingga disebut dengan tabel yang normal apabila sudah melewati ketiga tahapan ini. a. First Normal Form (1NF) First Normal Form adalah relasi dimana pertemuan antar setiap baris dan kolom terdiri satu dan hanya satu nilai. Kondisi ini dapat diperoleh dengan melakukan eliminasi terjadinya data ganda (repeating group). Pada kondisi normal pertama ini kemungkinan masih terjadinya adanya rangkap (Begg, Connolly, 2005, p403). b. Second Normal Form (2NF) Aturan pada normalisasi ini adalah sebuah relasi dalam bentuk normal pertama dan setiap atribut yang bukan primary key bergantung secara fungsional penuh kepada primary key (Begg, Connolly, 2005, p407).
52 c. Third Normal Form (3NF) Third Normal Form adalah sebuah relasi yang telah berada pada bentuk normal tahap pertama dan kedua dimana semua tidak ada lagi atribut yang bukan primary key bergantung secara transitif kepada primary key (Begg, Connolly, 2005, p409). Pada tahap ini, atribut yang tidak memberikan kontribusi terhadap penjelasan karakteristik primary key, akan dipindahkan kesebuah tabel yang terpisah. Keuntungan dari tabel relasional dalam 3NF adalah menghilangkan data yang berulang-ulang dengan tujuan menghemat tempat dan mengurangi keanehan manipulasi. 2.3.11 DFD DFD adalah sebuah model proses yang digunakan untuk menggambarkan aliran data yang lewat dari sebuah sistem dan bekerja atau proses ditampilkan dari sistem tersebut (Whitten, Bentley, Dittman, 2004, p344). Komponen-komponen DFD adalah sebagai berikut: No
Nama
Simbol
Keterangan Menjelaskan batas luar dari sebuah sistem
1
Eksternal agents
yang berperan dalam sistem. Bentuk ini mengikuti aturan dari DeMarco/Yourdon. Proses menggambarkan kegiatan yang akan
2
Proses
diselesaikan atau melakukan proses dari kerangka informasi. Bentuk ini mengikuti aturan dari DeMarco/Yourdon.
3
Arus data
Arus data menjelaskan aliran data, dapat berperan sebagai masukan (input) atau
53 keluaran (output), dari dan menuju proses Penyimpanan data terkadang disebut dengan 4
basis data (database), digunakan untuk
Penyimpanan data
menyimpan data yang akan dipakai untuk
(Data Storage)
proses selanjutnya. Bentuk ini mengikuti aturan dari DeMarco/Yourdon.
Tabel 2.1 Tabel Komponen-Komponen DFD Tingkatan dalam DFD (Schell, McLeod, 2007, p200), yaitu : 1. Diagram Konteks Menempatkan sistem dalam konteks lingkungannya. Diagram terdiri dari symbol proses tunggal. Diagram terdiri dari simbol proses tunggal yang menggambarkan keseleruhan dari sistem. 2. Diagram Nol DFD
yang
levelnya
berada
dibawah
diagram
konteks
dan
merepresentasikan gambaran level tertinggi dari fungsi utama didalam sistem. 3. Diagram Gambar n Mendokumentasikan sistem yang lebih detail dibandingkan dengan diagram nol. Huruf n menunjukkan jumlah proses yang sedang didokumentasikan pada tingkat berikutnya yang lebih tinggi.
2.3.12 State Transition Diagram (STD)
54 State Transition Diagram (STD) adalah sebuah alat yang digunakan untuk menggambarkan suatu urutan dan variasi tampilan yang dapat terjadi saat pengguna menjalankan sistem (Whitten, Bentley, Dittman, 2004, p673). Simbol-simbol yang digunakan dalam STD : No
Simbol
Keterangan Digunakan
untuk
menunjukkan
layar
1 tampilan (display screen) Digunakan 2
untuk
menunjukkan
aliran
kendali dan kejadian pemicu (trigger) yang menyebabkan tampilan menjadi aktif Tabel 2.2 Tabel Simbol-Simbol STD
2.3.13 Arsitektur Basis Data Oracle Menurut Loney dan Bryla (2005,p6-8), datafiles dalam basis data Oracle dikelompokkan bersama menjadi satu atau lebih tablespace. Dalam setiap tablespace, struktur logikal basis data, seperti tabel dan indeks yang merupakan penyimpanan yang memungkinkan Oracle untuk memiliki kontrol yang lebih efisien atas penggunaan ruang disk. Tablespace Oracle tablespace terdiri dari satu atau lebih datafiles; sebuah datafiles dapat menjadi bagian dari satu dan hanya satu tablespace. Untuk instalasi Oracle 10g, minimal dibtuhkan dua tablespace dibuat: SYSTEM tablespace dan SYSAUX tablespace.
55 Oracle 10g memungkinkan anda untuk membuat tablespace jenis khusus yang disebut bigfile tablespace, yang dapat sebesar 8EB (exabyte atau juta tetrabytes). Menggunakan bigfiles membuat manajemen tablespace menjadi transparan untuk DBA; dengan kata lain, DBA dapat mengelola tabespace sebagai sebuah unit tanpa khawatir tentang ukuran dan struktur datafiles yang mendasarinya. Jika sebuah tablespace yang bersifat sementara maka tablespace itu sendiri adalah permanen; hanya segmen yang tersimpan dalam tablespace yang bersifat sementara. Sebuah temporary tablespace dapat digunakan untuk operasi penyortiran dan sebagai area kerja untuk membangun indeks. Mendedikasikan sebuah tablespace untuk operasi semacam ini membantu mengurangi I/O contention antara sementara segmen-segmen temporary dan segmen permanen tersimpan dalam tablespace lain, contohnya tabel. Tablespace dapat dikelola dengan kamus atau dikelola secara lokal. Dalam tablespace yang dikelola oleh kamus, manajemen extent tercatat dalam tabel kamus data. Oleh karena itu, bahkan jika semua tabel aplikasi ada di tablespace USERS, tablespace SYSTEM masih akan dapat diakses untuk mengelola DML pada tabel aplikasi. Karena semua pengguna dan aplikasi harus menggunakan tablespace SYSTEM untuk manajemen extent, hal ini menciptakan hambatan yang potensial untuk menulis aplikasi yang intensif. Pada tablespace yang dikelola secara lokal, Oracle memelihara suatu bitmap dalam setiap datafile dari tablespace untuk melacak ketersediaan ruang. Hanya kuota dikelola dalam kamus data, secara dramatis mengurangi contention pada kamus data tabel. Blok
56 Blok basis data adalah unit terkecil penyimpanan dalam basis data Oracle. Ukuran blok adalah jumlah byte dari penyimpanan dalam tablespace tertentu dalam basis data. Satu blok biasanya merupakan kelipatan dari sistem operasi ukuran blok untuk memfasilitasi I/O disk yang efisien. Ukuran blok default ditetapkan oleh Oracle parameter inisialisasi DB_BLOCK_SIZE. Sebanyak empat lainnya ukuran blok dapat didefinisikan untuk tablespace lainnya dalam basis data, meskipun blok di SYSTEM, SYSAUX, dan setiap tablespace temporary harus dari ukuran DB_BLOCK_SIZE. Extent Extent adalah tingkat berikutnya dari pengelompokan logika dalam basis data. Sebuah extent terdiri dari satu atau lebih blok basis data. Ketika objek basis data diperbesar, ruang akan ditambahkan ke objek tersebut yang akan dialokasikan sebagai sebuah extent. Segments Tingkat berikutnya dari pengelompokan logika dalam basis data adalah segment. Sebuah segment adalah sekelompok extents yang meliputi objek basis data yang diperlakukan sebagai satu unit, seperti tabel atau indeks. Akibatnya, hal ini biasanya merupakan unit terkecil penyimpanan yang pengguna akhir dari basis data akan menangani. Empat jenis segment yang ditemukan di basis data Oracle: data segment, indeks segment, temporary segment, dan rollback segment. Data segment
57 Setiap tabel dalam basis data berada dalam satu data segmen yang terdiri dari satu atau lebih extent; lebih dari satu segmen dialokasikan untuk tabel jika tabel tersebut merupakan tabel yang dipartisi atau tabel cluster. Index segment Setiap indeks disimpan dalam segmen indeks sendiri. Seperti pada tabel yang dipartisi, setiap partisi dari indeks yang dipartisi disimpan dalam segmen sendiri. Temporary segment Ketika pernyataan SQL seorang pengguna mebutuhkan ruang disk untuk menyelesaikan operasi, seperti operasi penyortiran yang tidak dapat dimuat dalam memori yaitu temporary segment yang dialokasikan. Temporary segment ada hanya untuk durasi pernyataan SQL. Rollback segment Sebagai Oracle 10g, rollback segment hanya ada di tablespace SYSTEM, dan biasanya DBA tidak perlu mempertahankan SISTEM rollback segment. Oracle yang rilis sebelumnya, sebuah rollback segment diciptakan untuk menyimpan nilai-nilai sebelumnya dari sebuah operasi DML basis data dalam kasus transaksi dilaukna rollback, dan untuk memelihara data image "sebelum" untuk menyediakan read-consistent views dari data tabel untuk pengguna lain mengakses tabel. Rollback segment juga digunakan selama proses pemulihan basis data untuk memutar kembali terikat transaksi yang aktif pada saat jatuh contoh basis data atau dihentikan mendadak. Di Oracle 10g, Automatic Undo Management menangani alokasi secara otomatis dan pengelolaan pengembalian segment dalam suatu undo tablespace.
58 Dalam satu undo tablespace, maka akan dibatalkan segment yang terstruktur mirip dengan pengembalian segment, kecuali bahwa secara rinci bagaimana segment ini dikelola berada di bawah kendali dari Oracle, bukan dikelola (sering tidak efisien) oleh DBA. Otomatis membatalkan segment yang tersedia menatap dengan Oracle 9i, tetapi dikelola secara manual rollback segment masih tersedia di Oracle 10g. Namun, fungsi ini is deprecated sebagai Oracle 10g dan tidak akan lagi tersedia di masa mendatang. 2.3.14 Estimating Disk Space Requirements Terdapat empat langkah untuk menghitung ruang yang dibutuhkan: 1. Menghitung total block header size Langkah pertama untuk menghitung ukurang dari block header : totalBlockHeaderSize =
fixedHeaderSize + fixedTransactionHeader
+ variableTransactionHeader + dataHeader fixedHeaderSize = KCBH + UB4 fixedTransactionHeader = KTBBH variableTransactionHeader = KTBIT*(INITTRANS – 1) dataHeader = KDBH parameter KCBH, UB4, KTBBH, KTBIT, KDBH bisa didapat dari tabel system v$type_size, dan INITTRANS untuk tabel non-clustered dalam sebuah platform NT bernilai = 1, maka kita akan mendapat : totalBlockHeaderSize = (20 + 4) + 48 + 24 * ( 1 – 1 )+ 14 = 86 2. Menghitung ruang yang tersedia untuk tiap blok data
59 Berikutnya kita akan menghitung jumlah ruang yang tersedia dalam sebuah blok data : availableDataSpace
=
ROUNDUP
((BlockSize
–
totalBlockHeaderSize) * (1 – PCTFREE/100) – KDBT PCTFREE adalah persentase dari ruang yang dipesan dalam sebuah blok untuk mengupdate. Untuk sebuah non-clustered table dalam sebuah NT platform dengan PCTFREE = 10, maka kita akan mendapatkan: availableDataSpace = (8192 – 86)*(1 – 10/100) – 4 = 7292 3. Menghitung ruang yang digunakan tiap row Untuk menghitung ruang data yang terkombinasi dan dibutuhkan ratarata untuk tiap row. Hal ini bergantung pada: •
Jumlah kolom pada definisi tabel
•
Tipe data yang digunakan tiap kolom
Total ukuran kolom, termasuk jumlah byte, dihitung dengan cara sebagai berikut : totalColumnSize = columnSize + (1, if column size < 250, else 3) Ukuran row dihitubng sebagai berikut : totalRowSize = rowHeaderSize + ∑totalColumnSize Dimana rowHeaderSize = 3 bytes tiap row pada non-clustered table (4 bytes untuk tiap row pada sebuah clustered table). Apabila nilai yang dihitung lebih kecil dari nilai dari ukuran row, maka akan digunakan nilai minimum row size.
60 4. Menghitung jumlah total row yang akan dimasukkan dalam sebuah blok data Kita dapat menghitung jumlah total row yang akan dimasukkan ke dalam blok data dengan cara sebagai berikut : noRowsPerBlock = ROUNDOWN(availableDataSpace/totalRowSize) (http://wps.pearsoned.co.uk/wps/media/objects/1538/1575733/appendix /Appendix_H.pdf)
2.4
Teori-Teori Pendekatan Analisis Sistem 2.4.1
Pendekatan Model-Driven Analysis Structured analysis, information engineering, dan object-oriented analysis
adalah contoh dari analisis model-driven. Analisis model-driven menggunakan gambar-gambar untuk mengkomunikasikan permasalahan bisnis, kebutuhankebutuhan, dan solusi-solusi. Contoh model-model yang mungkin sudah dikenal seperti flowcarts, structure atau hierarchy charts, dan organization charts. 2.4.1.1 Structure Analysis Structured analysis adalah salah satu pendekatan formal untuk menganalisa sistem atau sistem informasi. Structured analysis memusatkan pada alur dari data dalam bisnis dan proses piranti lunak. Structured analysis disebut sebagai process-centered. Structured analysis termasuk sederhana secara konsep. Structured analysis menggambarkan sebuah seri dari model proses yang disebut data flow diagram yang mengambil proses pada sistem yang ada dengan input, output dan file yang ada dalam sistem tersebut.
61 2.4.1.2 Information Engineering dan Data Modeling Banyak organisasi yang mengembangkan dari pendekatan structured analysis menjadi pendekatan information engineering. Information engineering memusatkan pada struktur dari penyimpanan data dalam sebuah sistem. Model data dalam information engineering disebut entity relationship diagrams. 2.4.1.3 Object-Oriented Analysis Object-Oriented Analysis adalah sebuah teknik model-driven yang mengintegrasikan data dan proses yang menekankan pada gagasan yang disebut objects.
Model
Object-Oriented
Analysis
adalah
gambaran
yang
mengilustrasikan sistem objek dari berbagai perspektif, seperti structure, behaviour, dan interaction antar objek. Model objek dalam Object-Oriented Analysis menggunakan Unified Modeling Language Standard.
62 2.5
Teori-Teori Pendukung 2.5.1
Teori Pengiriman Barang Terdapat beberapa istilah dalam proses pengiriman barang, diantaranya
adalah sebagai berikut : a. Airway Bill (AWB) Air Waybill (AWB) merupakan dokumen yang dibuat oleh atau atas nama pengirim (shipper) yang membuktikan kontrak antara pengirim dan pembawa (carrier) untuk pengiriman barang sesuai dengan rute pengiriman. AWB merupakan dokumen pengiriman yang paling penting dan diperkenalkan pada konfrensi WARSAWA pada tahun 1929. AWB menetapkan kewajiban hukum dari pembawa (carrier) dan pembatasan kompensasi, hak dan kewajiban dari pengirim, penerima, dan pembawa yang tidak dapat dinegosiasi. (http://cargo.garuda-indonesia.com/ff/Airwaybill%20detail%20 GARUDA.htm) b. Cargo Handling Cargo atau kargo dapat diartikan sebagai semua barang (goods) yang dikirim melalui udara (pesawat), laut (kapal), dan darat (truk) yang biasanya untuk diperdagangkan, baik antarwilayah/kota didalam negeri maupun antarnegara (internasional). Apapun jenis barangnya, semua barang kiriman-kecuali benda pos dan bagasi penumpang-baik yang diperdagangkan ataupun keperluan lainnya (non komersial) dan dilengkapi dengan dokumen pengangkutan (SMU atau Airway Bill) dikategorikan sebagai kargo. Cargo handling berkaitan dengan
63 penanganan kargo dengan urutan penyajian dimulai dari aktifitas pengiriman barang, penggolongan jenis kargo, cargo rate, serta perhitungan sewa gudang. (Warpani, Majid, 2009, p95). c. Freight forwarder/Agents Ada tiga pihak utama yang terkait dengan pengiriman kargo, yaitu pihak pengirim (shipper) dan atau pihak penerima (consignee); pihak pengangkut (carrier); dan pihak ground handling dan atau warehouse operator. Shipper bisa berupa perorangan, badan usaha, dilakukan secara langsung tanpa perantara, atau melalui jasa ekspedisi pengiriman barang yang dikenal dengan istilah freight forwarder atau ekspedisi muatan kapal laut atau ekspedisi muatan pesawat udara. Istilah agen kargo dewasa ini sudah berkembang menjadi freight forwarding atau freight forwarder, baik airfreight maupun seafreight. d. IATA IATA singkatan dari International Air Transport Association atau Asosiasi Angkutan Udara Internasional. IATA bermarkas di Montreal dan Jenewa. IATA merupakan asosiasi internasional swasta dari perusahaan penerbangan berjadwal. Walaupun swasta dari segi teknisnya, IATA juga dipengaruhi oleh kepentingan negara anggotanya karena kebanyakan dari perusahaan penerbangan yang menjadi anggotanya itu dikendalikan oleh pemerintah negaranya masing-masing (Warpani, Majid, 2009, p302). e. SLA
64 Service Level Agreement adalah perjanjian antara penyedia jasa dan pengguna jasa terdadap jasa layanan yang akan diberikan/ diterima. Dalam perjanjian tersebut, biasanya diuraikan secara rinci elemen layanan, antara lain : -
Lingkup pekerjaan/layanan
-
Masa berlaku perjanjian
-
Waktu response terhadap permintaan pelanggan
-
Tingkat kinerja
Tingkat layanan yang diberikan/ diterima merupakan kesepakan bersama kedua belah pihak, termasuk didalamnya biaya atas layanan tersebut. (http://www.solusidokumen.com/id/service_sla.htm)
