9
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).
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 Nama 5184025 5183027 5184088 5184099 Adi Nugroho Ana Mariana Esti Nugraheni Eni Nugraheni Tabel Mahasiswa No_MK Nama_MK SKS 110011 130012 130013 Pascal C Basis Data 3 3 3 Tabel Mata Kuliah
NIM No_MK Nilai
5184025 5184025 5184088 110011 130013 110011 A A C Tabel Pengambilan Mata Kuliah
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 data-data dari salah satu tabel dengan data-data-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
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
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 di-integrasikan/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 hubungan-hubungan 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, kemudian dilanjutkan dengan mengidentifikasi entitas-entitas tingkat rendah, hubungan-hubungannya, serta mengasosiasikan 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).
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 multi-value 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 relasi-relasi 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
43 - Langkah 2.3 melakukan validasi relasi pada transaksi user
Langkah ini dilakukan untuk memastikan bahwa relasi didalam Local logical data model mendukung transaksi yang
dibutuhkan. (Begg, Connolly, 2005, p474). - Langkah 2.4 memeriksa batasan integrity
Bertujuan untuk memeriksa batasan integritas yang 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 kita mengidentifikasi primary key untuk tiap tipe entitas.
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).
Langkah-langkahnya 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
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 339-2178 dan
0141-339-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
1 Eksternal agents
Menjelaskan batas luar dari sebuah sistem yang berperan dalam sistem. Bentuk ini mengikuti aturan dari DeMarco/Yourdon.
2 Proses
Proses menggambarkan kegiatan yang akan diselesaikan atau melakukan proses dari kerangka informasi. Bentuk ini mengikuti
aturan dari DeMarco/Yourdon. 3 Arus data Arus data menjelaskan aliran data, dapat
53 keluaran (output), dari dan menuju proses
4 Penyimpanan data (Data Storage)
Penyimpanan data terkadang disebut dengan basis data (database), digunakan untuk menyimpan data yang akan dipakai untuk
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.
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
1
Digunakan untuk menunjukkan layar tampilan (display screen)
2
Digunakan 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.
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 rata-rata 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, kebutuhan-kebutuhan, 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
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
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).
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)
