8
BAB 2 LANDASAN TEORI
2.1. Teori - Teori Basis data Menurut Connolly dan Begg (2002, p7) File-Based System adalah suatu kumpulan dari program aplikasi yang memberikan pelayanan kepada end-user seperti pembuatan suatu laporan. Setiap program mendefinisikan dan mengatur datanya masing-masing. Keterbatasan dari pendekatan menggunakan file ini, diantaranya adalah data yang terpisah dan terisolasi, data yang terduplikasi, ketergantungan data, format file yang tidak kompatibel, Query yang tetap atau tidak
dapat
digunakanlah
mengantisipasi pendekatan
perkembangan
dengan
program
menggunakan
aplikasi.
database
dan
Akhirnya Database
Management System (DBMS).
2.1.1
Pengertian Sistem Menurut Mcleod (2003, p9) pengertian sebuah sistem adalah Kumpulan dari elemen yang terintegrasi dengan tujuan umum untuk meraih sebuah objektif
9
2.1.2
Pengertian Basis data Menurut Connolly (2002, p14) database adalah kumpulan data yang terhubung secara logikal dan deskripsi data yang digunakan secara bersama, yang dirancang untuk memenuhi kebutuhan informasi suatu perusahaan. Sedangkan menurut Date (2000, p5) suatu sistem database adalah suatu sistem yang ada pada dasarnya menyimpan recordrecord di dalam suatu sistem yang dilakukan secara komputerisasi yang tujuannya secara keseluruhan adalah untuk memelihara informasi
dan
untuk
membuat
informasi
tersebut
tersedia
berdasarkan permintaan.
2.1.3
Database Management System (DBMS) Connolly dan Begg (2002, p16) menjelaskan bahwa DBMS merupakan sebuah sistem perangkat lunak yang memungkinkan user untuk mendefinisikan, membuat, memelihara dan mengontrol akses ke database. Suatu DBMS menyediakan fungsi sebagai berikut, yaitu : •
memperbolehkan
user
untuk
menambah,
mengedit,
menghapus data, dan mendapatkan kembali data. Biasanya dengan menggunakan suatu Data Manipulation Language (DML). Ada suatu fasilitas untuk melayani pengaksesan data
10 yang disebut sebagai Query Language. Bahasa query yang paling diakui adalah Structured Query Language (SQL), yang secara de facto merupakan standar bagi DBMS. •
Menyediakan akses kontrol ke database. Sebagai contoh, menyediakan : Sistem keamanan, dimana mencegah user yang tidak mempunyai hak akses untuk mengakses database. Sebuah
sistem
yang
tangguh,
dimana
memelihara
konsistensi dari data yang disimpan. Sebuah
sistem
kontrol
persetujuan,
dimana
memperbolehkan pembagian akses dari database. Sebuah sistem kontrol pemulihan, dimana mengembalikan database ke keadaan semula secara konsisten ketika terjadi kegagalan perangkat keras atau perangkat lunak. Sebuah daftar yang dapat diakses oleh user, dimana berisi deskripsi dari data yang terdapat di dalam database. •
Mendefinisikan
database
menggunakan
suatu
Data
Definition Language (DDL). Suatu DDL memberikan fasilitas kepada user untuk menspesifikasikan tipe data dan strukturnya dan batasan aturan mengenai data yang bisa disimpan ke dalam database tersebut.
11 Keuntungan DBMS antara lain : 1.
Kontrol terhadap redundansi data
2.
Konsistensi data
3.
Semakin banyak informasi yang didapat dari data yang sama
4.
Data yang dibagikan (shared data)
5.
Menambah integritas data
6.
Menambah keamanan data
7.
Penetapan standarisasi
8.
Menyeimbangkan konflik kebutuhan
9.
Memperbaiki pengaksesan data dan hasilnya
10.
Menambah produktivitas
11.
Memperbaiki pemeliharaan data melalui data independence
12.
Meningkatkan concurrency
Kerugian DBMS antara lain : 1.
Kompleksitas
2.
Size / ukuran
3.
Biaya dari suatu DBMS
4.
Biaya penambahan perangkat keras.
12 2.1.4
Data Definition Language ( DDL ) Menurut Connoly dan Begg (2002, p40), Data Definition Language (DDL) adalah sebuah bahasa yang memperbolehkan Database Administrator (DBA) atau user untuk mendeskripsikan dan memberi nama entiti, atribut, dan hubungan yang diperlukan untuk aplikasi, bersama dengan integritas dan batasan-batasan keamanan.
2.1.5
Data Manipulation Language ( DML ) Menurut Connoly dan Begg (2002, p41), Data Manipulation Language (DML) adalah sebuah bahasa yang menyediakan kumpulan operasi untuk mendukung operasi manipulasi data dasar pada data dalam database. Manipulasi data biasanya terdiri dari: 1. Penambahan data baru ke dalam database. 2. Modifikasi data yang tersimpan dalam database. 3. Pemanggilan data yang terdapat dalam database. 4. Penghapusan data dari database.
2.1.6
Data Flow Diagram ( DFD ) DFD adalah alat yang menggambarkan aliran data melalui sebuah sistem dan pekerjaan atau proses yang dilakukan oleh sistem. DFD sederhana tetapi memiliki teknik yang kuat dan mudah
13 dimengerti. DFD juga dapat disebut dengan
Bubble chart,
transformation graph dan, Process model. Dalam DFD terdapat tiga simbol dan satu koneksi :
• Merepresentasikan proses atau pekerjaan yang harus diselesaikan. •
Merepresentasikan agen luar – batasan (external entity) dari sistem. •
Merepresentasikan penyimpanan data, biasa disebut berkas atau basis data. Penyimpanan data dapat disamakan dengan seluruh bagian dari entiti tunggal dalam model data. • Merepresentasikan aliran data, atau input dan output, dari dan menuju proses. Keuntungan dari DFD adalah : 1.
Proses dalam DFD dapat beroperasi secara pararel. Jadi beberapa proses dapat bekerja secara bersamaan sesuai dengan cara kerja bisnis.
14 2.
DFD menunjukan aliran data yang melalui sistem. Panahnya mewakili arah ke bawah dimana data tersebut mengalir. Perulangan dan percabangan biasanya tidak diperlihatkan, selain itu flowchart menunjukan tahap-tahap dari proses atau operasi dalam algoritma atau program.
3.
DFD menunjukan proses yang memiliki perbedaan waktu yang dramatis contohnya suatu DFD tunggal mungkin akan memasukkan proses yang terjadi perjam, perhari, perminggu, pertahun, dan sesuai permintaan.
2.1.7
Entity Relationship Diagram (ERD) Menurut Connolly dan Begg (2002,p330), salah satu aspek yang sulit dalam perancangan database adalah kenyataan bahwa, perancang, programmer, dan end-user cenderung melihat dan menggunakan data dengan cara yang berbeda. Apabila kita tidak mendapatkan pemahaman umum yang mencerminkan bagaimana proses perusahaan terjadi, maka perancangan yang dihasilkan tidak akan memenuhi permintaan user. Untuk memastikan didapatnya pemahaman yang tepat secara alamiah dari data dan bagaimana data digunakan oleh perusahaan maka dibutuhkan suatu model bentuk komunikasi yang tidak teknik dan bebas dari ambigu.
15 2.1.7.1
Entity type Tipe entity (entity type) adalah sebuah kumpulan objek
yang
memiliki
diidentifikasikan
oleh
sifat
yang
suatu
sama,
dimana
perusahaan
yang
keberadaannya tidak tergantung. Konsep dasar dari bentuk ER adalah tipe entity, dimana yang
merepresentasikan
kumpulan dari objek di dalam dunia nyata dengan sifat yang sama. Sebuah tipe entity memiliki keberadaan yang bebas dan bisa menjadi objek dengan keberadaan fisik atau objek dengan keberadaan konseptual. Entity occurrence adalah sebuah objek unik yang dapat diidentifikasi dari sebuah tipe entity. Setiap objek unik yang dapat diidentifikasi dari sebuah tipe entity untuk menunjukan dengan sederhana sebagai sebuah entity occurrence. Dalam istilah umumnya ‘entity type’ dan ‘entity occurrence’ digunakan istilah entity agar artinya jelas. Nama Entity
Staff
Branch
Gambar 2.1 Contoh tipe entity Sumber : Connolly dan Begg (2002, p333)
16 2.1.7.2
Relationship Relationship adalah sejumlah hubungan yang berarti antara tipe entity. Sebuah tipe relationship adalah sejumlah hubungan antara entity satu dengan tipe entitiy lainnya, dimana setiap tipe relationship diberi nama yang menggambarkan fungsi berbeda.
Relationship name
Has
Staff
Branch
Gambar 2.2 Contoh relationship Sumber : Connolly dan Begg (2002, p335)
Derajat dari relationship adalah jumlah dari partisipasi tipe entity dalam sebuah tipe relationship tertentu. Entity yang berkaitan dalam sebuah tipe relationship dikenal sebagai participant dalam relationship dan jumlah participant dalam relationship menunjukan jumlah dari entity yang terkait dalam relationship. Sebuah relationship berderajat dua disebut binary, berderajat 3 disebut
ternary
dan
relationship
berderajat
empat
17 quartenary. Biasanya nama relationship menggunakan kata kerja. Solicitor
Arrange
Buyer
Financial Institution
Branch
Gambar 2.3 Contoh quartenary relationship Sumber : Connolly dan Begg (2002, p337)
2.1.7.3
Attribute and key Atribut adalah sifat dari sebuah entity atau tipe relationship. Sifat tertentu dari entity disebut sebagai atribut. Atribut menyimpan nilai dari setiap entity occurrence dan mewakili bagian utama dari data yang disimpan dalam basis data. Domain
atribut
adalah
sejumlah
nilai
yang
diperkenankan untuk satu atau lebih atribut. Setiap atribut yang dihubungkan dengan sejumlah nilai disebut domain. Domain menetapkan nilai potensial yang sebuah atribut
18 bisa simpan atau sama dengan konsep domain pada model relasional. Simple attribute (atribut sederhana) adalah sebuah susunan atribut dari komponen tunggal dengan keberadaan yang bebas. Simple attribute tidak bisa dibagi lagi ke dalam komponen yang lebih kecil, misalnya, posisi dan gaji dari entity pegawai. simple attribute disebut atomic attribute. Sedangkan composite attribute (atribut gabungan) adalah sebuah susunan atribut dari banyak komponen dengan sebuah keberadaan yang bebas dari masing-masingnya. Contohnya atribut alamat dari entity kantor cabang yang mengandung nilai (jalan, kota, kode pos) bisa dipecahkan menjadi simple attribute jalan, kota dan kode pos. Single value attribute adalah (atribut nilai tunggal) atribut yang hanya menyimpan nilai tunggal untuk suatu sifat dari entity. Multi-valued attribute (atribut nilai berlipat) adalah atribut yang bisa menyimpan nilai lebih dari satu untuk suatu sifat dari entity. Contohnya atribut telepon pada entity kantor cabang yang bisa memiliki lebih dari satu nomor telepon. Derived attribute (attribut turunan) adalah atribut yang menunjukan nilai yang diperoleh dari atribut yang berhubungan atau kumpulan atribut yang berhubungan,
19 tidak terlalu dibutuhkan dalam tipe entity yang sama. Derived attribute mungkin juga menyangkut hubungan dari atribut pada entity yang berbeda. Candidate key adalah kumpulan paling rendah dari atribut yang secara unik mengidentifikasi tiap kejadian dari sebuah tipe entity. Primary key adalah candidate key yang terpilih secara unik untuk mengidentifikasi tiap kejadian dari sebuah tipe entity. Sedangkan composite key adalah candidate key yang terdiri dari dua atau lebih atribut.
Primary key Manages Staff
Area to list attribute(s)
staffNoPK name position salary /totalstaff
Derived attribute
Branch Has
branchNo PK address street city postcode telNo [1..3]
Multi-valued attribute
Gambar 2.4 Contoh atribut dan key Sumber : Connolly dan Begg (2002, p342)
Composite attribute
20 2.1.8
Normalisasi Menurut Connolly dan Begg (2002, p376) normalisasi adalah sebuah teknik untuk memproduksi kumpulan dari relationship dengan sifat yang diinginkan, sesuai kebutuhan data yang diberikan oleh perusahaan. Teknik ini melibatkan serangkaian aturan yang dapat digunakan untuk menguji relationship individual sehingga basis data dapat dinormalisasikan kedalam beberapa tingkat. Mulai dari sebuah tabel dalam kategori tidak normal (unnormal form atau UNF) secara bertahap diubah kebentuk normal pertama (first normal form atau 1NF), kemudian dalam bentuk tabel 1NF diubah lagi menjadi bentuk normal kedua (second normal form atau 2NF), selanjutnya diubah kedalam bentuk normal ketiga (third normal form atau 3NF), Boyce Codd normal form (BCNF), bentuk normal keempat (fourth normal form atau 4NF) dan bentuk normal kelima (fifth normal form atau 5NF). Tingkatan dalam normalisasi : 1. Bentuk tidak normal (UNF) Unnormal form adalah tabel yang berisi satu atau lebih kelompok yang berulang. 2. Bentuk normal pertama (1NF) First normal form adalah sebuah relationship dimana pertemuan dari tiap tabel dan kolom berisi satu dan hanya satu nilai.
21 Perubahan dari tabel UNF ke 1NF dilakukan dengan cara mengidentifikasi kelompok yang berulang. 3. Bentuk normal kedua (2NF) Second normal form adalah sebuah relationship yang berada dalam 1NF dan setiap atribut yang bukan primary key secara fungsional bergantung seluruhnya kepada primary key. 4. Bentuk normal ketiga (3NF) Third normal form adalah sebuah relationship yang berada dalam 2NF dan atribut bukan kunci tidak memiliki unsur ketergantungan
transitif
terhadap
primary
key.
Suatu
ketergantungan transitif didefinisikan sebagai suatu hubungan ketergantungan fungsional tidak langsung terhadap superkey primary key. 5. Bentuk normal Boyce Codd (BCNF) Sebuah relationship adalah BCNF, jika dan hanya jika, setiap penentu (determinant) adalah candidate key. BCNF merupakan bentuk normal sebagai perbaikan terhadap 3NF karena bentuk normal
ketiga
berkemungkinan
masih
memiliki
anomali
sehingga perlu dinormalisasi lebih jauh. 6. Bentuk normal keempat (4NF) Fourth normal form adalah sebuah relationship yang berada dalam BCNF dan tidak mengandung dua atribut atau lebih yang bernilai banyak.
22 7. Bentuk normal kelima (5NF) Fifth normal form disebut juga project join normal form adalah sebuah relationship yang tidak memiliki ketergantungan gabungan. 2.1.9
4th GL (Generation Languange) Sekarang ini terdapat suatu bahasa yang disebut 4GL. Yang merupakan bahasa pemprograman yang diminimalisasi. Suatu operasi yang biasanya membutuhkan ratusan baris di bahasa pemprograman 3GL seperti COBOL, maka pada 4GL hanya membutuhkan baris pemprograman yang lebih sedikit. Klaim 4GL adalah dapat menambah produktivitas berkalikali lipat, penanganan masalah yang lebih banyak. Menurut Connolly (2002, p42), Fourth-Generation Languange mempunyai kemampuan sebagai berikut: •
Bahasa Prensentasi seperti Query Language, dan Report Generators.
•
Bahasa Spesialis seperti Spreadsheets dan Database Language.
•
Aplikasi
Generator
seperti
mendefenisikan,
menambah,
mengedit, dan mengembalikan data dari database untuk membangun aplikasi. •
Bahasa pemprograman yang dapat menggenerate application codes.
23 SQL dan QBE, seperti yang disebutkan di atas adalah contoh dari 4th GL. Beberapa contoh tipe lain dari 4th GL :
2.1.10
•
A forms generator
•
Report generator
•
Graphics generator
•
Aplikasi generator
Siklus Hidup Aplikasi Database Menurut Connolly (2002, p271) Sistem basis data merupakan suatu komponen dasar dari perusahaan dengan sistem informasi besar, siklus hidup aplikasi basis data berkaitan dengan sikuls hidup sistem informasi. Hal ini sangat penting diperhatikan karena struktur dari siklus hidup aplikasi basis data tidaklah harus benar-benar sekuensial, tetapi meliputi suatu perulangan dari bagan-bagan yang sebelumnya melalui feed back loops. Untuk aplikasi database kecil, siklus hidup tidak terlalu kompleks.
Bagaimanapun
juga,
ketika
perancangan
sedang
dilakukan pada suatu aplikasi database ukuran sedang dengan jumlah pengguna antara 10 sampai dengan ribuan user, dengan menggunakan ratusan queries dan program aplikasi, siklus hidup akan menjadi kompleks. Berikut adalah siklus hidup aplikasi database:
24
Gambar 2.5 Siklus Hidup Aplikasi Basis data Sumber : Connolly dan Begg (2002, p272)
25 Berikut ini ringkasan dari aktivitas utama yang ada di setiap langkah dari siklus hidup aplikasi sistem basis data, antara lain: •
Database Planning Merencanakan bagaimana tahapan dari siklus hidup bisa direalisasikan secara efektif dan efisien.
•
System Definition Menspesifikasikan ruang lingkup dan batasan dari aplikasi sistem basis data, penggunanya, dan juga cakupan aplikasi tersebut.
•
Requirements Collection and Analysis Mengumpulkan dan menganalisis permintaan user dan area aplikasi.
•
Database Design Meliputi rancangan konseptual, logikal, dan fisikal dari database.
•
DBMS Selection (optional) Memilih suatu DBMS yang cocok untuk aplikasi sistem basis data.
•
Application Design Merancang antarmuka pemakai dan program aplikasi yang menggunakan dan memproses sistem basis data.
•
Prototyping (optional) Membangun suatu model kerja dari aplikasi database, yang mana
mengizinkan
perancang
atau
pengguna
untuk
26 memvisualisasikan dan mengevaluasi bagaimana gambaran sistem secara keseluruhan dan fungsinya. •
Implementation Membuat definisi basis data eksternal, konseptual, dan internal dan program aplikasinya.
•
Data Conversion and Loading Memindahkan data dari sistem yang lama ke sistem yang baru.
•
Application Testing Database diuji untuk mengetahui apakah masih ada error dan memvalidasi sesuai keinginan user.
•
Operational Maintenance Aplikasi database benar-benar diimplementasikan. Sistem ini akan terus dimonitor dan dipelihara. Apabila diperlukan suatu permintaan akan dimasukkan ke dalam aplikasi basis data melalui tahapan-tahapan proses yang ada dalam siklus hidup.
2.1.11
Perancangan Basis data Konseptual, Logikal dan Fisikal Menurut Connolly (2002, p418), design methodology adalah pendekatan struktur yang menggunakan prosedur, teknik, alat, dan dokumentasi tambahan untuk mendukung dan memfasilitasi proses dari desain tersebut. Urutan metodologi yang ada menurut Connolly (2002, p421) antara lain:
27
Perancangan Basis data Konseptual Tujuan dari perancangan konseptual basis data menurut Connolly (2002, p281) adalah untuk memproses pembuatan suatu model dari informasi yang akan digunakan dalam suatu perusahaan, yang tidak tergantung pada segala pertimbangan fisikal. Langkah 1 Membangun model data lokal konseptualuntuk setiap view Langkah 1.1 Identifikasi tipe entity Tujuan dari langkah ini adalah untuk mengidentifikasi tipe entity utama yang dibutuhkan oleh view. Langkah pertama dalam membangun suatu model data lokal konseptualadalah untuk mendefinisikan objek utama di mana user memang membutuhkannya. Salah satu metode untuk mengidentifikasi tipe entity yang utama adalah dengan mengidentifikasi kata benda atau frase kata benda yang telah disebutkan oleh user. Langkah 1.2 Identifikasi tipe relationship Tujuan dari langkah ini adalah untuk mengidentifikasi relationship yang penting antara berbagai tipe entity yang telah teridentifikasi. Biasanya, relationship diidentifikasi dengan menggunakan kata kerja atau frase kata kerja.
28 Relationship yang paling umum adalah relationship binary.
Artinya
relationship
antara
dua
entity
saja.
Bagaimanapun, harus diperhatikan relationship yang kompleks yang melibatkan lebih dari dua entity dan relationship recursive yang hanya melibatkan satu entity. Adapun langkah-langkah dalam mengidentifikasi tipe relationship adalah sebagai berikut : •
Gunakan Entity-Relationship (ER) diagrams Hal yang sering terjadi adalah pengguna akan lebih cepat mengerti suatu perancangan basis data dengan cara divisualisasikan
dibandingkan
dengan
perancangan
database yang dituliskan dalam bentuk tekstual. Entity Relationship
(ER)
diagrams
digunakan
untuk
merepresentasikan entity dan bagaimana relationship antar entity. Disarankan menggunakan Entity Relationship (ER) diagrams untuk membantu dalam membuat gambaran besar dari perusahaan yang sedang dikembangkan perancangan database-nya. •
Tentukan Multiplicity constraints dari tipe relationship Setelah terdapat relationship antara entity, maka langkah berikutnya
adalah
menentukan
multiplicity
setiap
relationship. Jika memang ada suatu nilai yang spesifik dari suatu multiplicity maka akan lebih baik apabila
29 didokumentasikan.
Multiplicity
constraints
digunakan
untuk mengecek dan menjaga kualitas data. •
Mengecek Fan dan Chasm Traps Setelah didefinisikan relationship yang dibutuhkan antar entity, maka langkah berikutnya adalah mengecek fan dan chasm traps. Definisi dari fan traps adalah suatu model yang merepresentasikan suatu relationship antara entity. Tetapi alur relationshipnya memperlihatkan ambiguitas. Definisi dari chasm traps adalah suatu model di mana ada hubungan antara entity yang satu dengan yang lain, tetapi tidak ada alur relationship antara kedua entity tersebut.
•
Mengecek setiap entity mempunyai relationship minimal satu. Pada saat pembuatan Entity Relationship (ER) diagrams, pastikan setiap entity mempunyai minimal satu relationship dengan entity lain. Jika memang ada entity yang sudah mempunyai minimal satu relationship dengan entity lain, maka langkah berikutnya adalah perhatikan kamus datanya.
Langkah 1.3 Identifikasi dan mengasosiasikan atribut dengan entity atau tipe relationship Tujuan dari langkah ini adalah untuk menghubungkan atribut dengan entity atau tipe relationship yang sesuai.
30 Simple/Composite attributes Perlu diperhatikan apakah suatu atribut tersebut itu simple atau composite. Composite attribute adalah atribut yang terdiri dari beberapa simple attribute. Sebagai contoh, atribut alamat bisa saja dibuat simple dan menyimpan beberapa detail dari alamat sebagai suatu nilai. Single/Multi-valued Attributes Suatu atribut dapat mengandung single atau multi-valued. Contoh atribut yang mengandung multiple value: nomor telepon dari entity Client. Derived Attributes Atribut yang nilainya tergantung dengan nilai atribut yang lain, maka atribut ini disebut sebagai Derived Atribut. Sebagai contoh : umur dari seorang staf, jumlah property yang dikelola oleh seorang staf. Langkah 1.4 Menentukan domain atribut Tujuan dari langkah ini adalah untuk menentukan domain dari atribut yang ada di dalam lokal konseptual data model. Sebagai contoh : Atribut dari NoStaf terdiri dari lima karakter tipe string di mana dua karakter utama merupakan huruf, sedangkan tiga karakter sisa berupa angka.
31 Langkah 1.5 Menentukan atribut candidate dan primary key Tujuan dari langkah ini adalah untuk mengidentifikasi candidate key dari setiap tipe entity, dan jika memang terdapat lebih dari satu candidate key, pilihlah salah satunya untuk menjadi primary key. Pada saat pemilihan suatu primary key di antara banyak candidate key, gunakan petunjuk berikut ini untuk membantu menyeleksi : •
Merupakan candidate key dengan jumlah set paling sedikit
•
Merupakan candidate key yang nilainya jarang sekali berubah
•
Merupakan candidate key dengan jumlah karakter paling sedikit
•
Merupakan candidate key dengan jumlah paling sedikit dari nilai maksimumnya (untuk
tipe atribut dengan tipe
numerik) •
Merupakan candidate key yang paling mudah digunakan dari sudut pandang pengguna.
32 Langkah 1.6 Mempertimbangkan penggunaan enhanced modeling concepts (langkah optional) Tujuan dari langkah ini adalah untuk mempertimbangkan penggunaan konsep bahasa tingkat tinggi (enhanced modeling concepts), seperti specialization, generalization, aggregation, dan composition. Jika anda menggunakan pendekatan specialization, maka perhatikan perbedaan antara entity dengan mendefinisikan satu atau banyak subclasses dari entity superclass. Sedangkan jika menggunakan pendekatan generalization, maka anda akan mengidentifikasi fitur-fitur yang umum antara entity untuk membentuk entity superclass. Langkah 1.7 Mengecek redundansi Tujuan dari langkah ini adalah untuk mengecek keberadaan redundansi dalam model database. Pada langkah ini, dilakukan pengujian lokal konseptual data dengan penglihatan secara spesifik, apabila ada redundansi maka dapat dihilangkan redundansi tersebut dengan dua langkah berikut: 1.
Menguji kembali hubungan one-to-one
2.
Menghilangkan relationship redundansi.
33 Langkah 1.8 Validasi lokal konseptual model terhadap transaksi user Tujuan dari langkah ini adalah untuk memastikan bahwa model lokal konseptual mendukung permintaan transaksi oleh view. Pengujian
dilakukan
dengan
dua
kemungkinan
pendekatan dengan memastikan bahwa Model Data Lokal Konseptual mendukung permintaan transaksi: (1)
Deskripsikan transaksi
(2)
Gunakan alur transaksi.
Langkah 1.9 Me-review model data lokal konseptual dengan user Tujuan dari langkah ini adalah untuk mengkaji ulang model data lokal konseptual bersama user untuk memastikan bahwa model yang ada sudah sesuai dengan yang diminta. Hasil akhir dari perancangan konseptual basis data adalah memproses pembuatan suatu model dari informasi yang akan digunakan dalam suatu perusahaan, yang tidak tergantung pada segala pertimbangan fisikal.
34
Perancangan Basis data Logikal untuk Model Relasional Adapun tujuan dari perancangan basis data logikal menurut Connolly (2002, p281) adalah untuk memproses pembuatan suatu model dari informasi yang digunakan di dalam suatu perusahaan berdasarkan model data yang spesifik, tapi tidak tergantung pada suatu DBMS dan perangkat keras lainnya. Langkah 2 Membuat dan memvalidasi model data lokal logikal untuk setiap bagian Adapun tujuan dari langkah ini adalah untuk membangun suatu model data lokal logikal dari suatu model data lokal konseptual yang merepresentasikan perusahaan dan kemudian memvalidasi model ini untuk memastikan strukturnya benar, dan memastikan bahwa model tersebut mendukung transaksi yang diminta. Langkah 2.1 Menghilangkan bagian yang tidak sesuai dengan
model
relationship
(langkah
optional) Tujuan dari langkah ini adalah untuk memperbaiki model data lokal konseptual dengan menghilangkan fitur yang tidak kompatibel atau cocok dengan model relationship. Bagian yang akan dibahas pada langkah ini antara lain: (1)
Menghilangkan many-to-many (*:*) tipe relationship
binary
35 (2)
Menghilangkan many-to-many (*:*) tipe relationship
rekursif (3)
Menghilangkan tipe relationship kompleks
(4)
Menghilangkan multi-valued.
Langkah 2.2 Menurunkan relationship untuk lokal logikal data model Tujuan dari langkah ini adalah untuk membuat suatu relationship
untuk
model
data
lokal
logikal
yang
merepresentasikan suatu entity, relationshipnya, dan juga atribut yang telah diidentifikasi. Adapun pendeskripsian bagaimana relationship dapat diturunkan dari struktur data model yang ada, antara lain: (1)
Tipe entity kuat
(2)
Tipe entity lemah
(3)
One-to-many (1:*) tipe relationship binary
(4)
One-to-one (1:1) tipe relationship binary
(5)
One-to-one (1:1) relationship rekursif
(6)
Superclass / subclass tipe relationship
(7)
Many-to-many tipe relationship binary
(8)
Tipe Relationship kompleks
(9)
Atribut multi-valued.
36 Langkah 2.3 Memvalidasi relationship dengan normalisasi Tujuan dari langkah ini adalah untuk memvalidasi relationship
dalam
model
data
lokal
logikal
dengan
menggunakan teknik dari normalisasi. Tujuan dari normalisasi adalah meminimalkan redundansi data dan update anomalies. Bentuk normalisasi : 1).
Bentuk normal pertama (1NF)
Semua sel sifatnya harus atomic (hilangkan repeating group). 2).
Bentuk normal kedua (2NF)
Suatu relationship harus memenuhi 1NF dan semua nonprimary-key attribute (atribut yang bukan primary key) fully functionally dependency terhadap primary key. 3).
Bentuk normal ketiga (3NF)
Relationship harus memenuhi 1NF dan 2NF, dan semua nonprimary-key attribute tidak transitive dependent terhadap primary key. 4).
Bentuk normal Boyce & Codd (BCNF)
Sebuah relationship adalah BCNF, jika dan hanya jika, setiap penentu (determinant) adalah candidate key. Langkah 2.4 Memvalidasi relationship dengan transaksi user Tujuan dari langkah ini adalah untuk memastikan bahwa relationship di dalam model data lokal logikal mendukung
37 transaksi yang diminta oleh view. Pada langkah ini, pengecekan bahwa relationship yang dibuat di langkah sebelumnya juga mendukung transaksi ini, dan juga pastikan bahwa tidak ada error dalam relationship yang telah dibuat. Langkah 2.5 Mendefinisikan batasan-batasan integritas Tujuan dari langkah ini adalah untuk mendefinisikan batasan-batasan integritas yang ada pada view. Dalam hal ini ada 5 tipe dari batasan-batasan integritas, antara lain: •
Data yang diminta
•
Domain pembatas atribut
•
Integritas entity Yang mendefinisikan suatu entity mempunyai integritas ialah tidak adanya primary key yang kosong (null). Suatu primary key merupakan suatu atribut yang mendefinisikan bahwa setiap record / tuple itu unik satu sama lain.
•
Integritas referensi Jika terdapat suatu foreign key dalam suatu relationship, maka nilainya harus sesuai dengan nilai candidate key pada salah satu record di mana foreign key tersebut berada atau foreign key tersebut sepenuhnya kosong (null).
•
Pembatas enterprise Merupakan aturan tambahan yang dibuat oleh user atau seorang database administrator dari basis data tersebut.
38 Langkah 2.6 Me-review model data lokal logikal dengan user Tujuan dari langkah ini adalah untuk memastikan bahwa model data lokal logikal dan membuat dokumentasi yang mendeskripsikan model tersebut sebagai representasi yang sesuai dengan keadaan sebenarnya. Hubungan antara Model Data Logikal dan Data Flow Diagram Suatu Logikal Data Model merefleksikan struktur dari penyimpanan data dalam suatu enterprise. Sebuah data flow diagram (DFD) menunjukkan aliran data suatu enterprise dan disimpan di dalam penyimpanan data. Semua atribut seharusnya berada di dalam suatu tipe entity jika memang ditangani di dalam enterprise dan kemungkinan akan terlihat mengalir di sekitar enterprise sebagai aliran data. Ada aturan yang mengontrol antara dua teknik tersebut, antara lain: •
Setiap penyimpanan seharusnya merepresentasikan suatu
tipe entity •
Atribut dalam data flow seharusnya merupakan bagian dari
tipe entity.
39 Langkah 3 Membangun dan memvalidasi global logikal data model Tujuan dari langkah ini adalah untuk mengkombinasikan suatu individual model data lokal logikal ke dalam suatu global logikal data model yang menggambarkan suatu enterprise. Langkah 3.1 Menggabungkan lokal logikal data model menjadi global model Tujuan dari langkah ini adalah untuk menggabungkan suatu lokal logikal data model ke dalam suatu global logikal data model dari suatu perusahaan. Beberapa tugas dari pendekatan ini adalah sebagai berikut: (1)
Me-review nama dan isi dari suatu entity / relationship dan candidate key
(2)
Me-review nama dan isi dari relationship / foreign key
(3)
Menggabungkan entity / relationship dari lokal data model
(4)
Memasukkan (tanpa penggabungan) entity / relationship unik pada setiap lokal data model
(5)
Menggabungkan relationship / foreign key dari lokal data model
(6)
Memasukkan
(tanpa
penggabungan)
relationship
foreign key unik pada setiap lokal data model
/
40 (7)
Mengecek untuk entity, relationship, foreign key yang hilang
(8)
Mengecek foreign key
(9)
Mengecek batasan integritas
(10)
Membuat global ER / relationship diagram
(11)
Meng-update dokumentasi.
Langkah 3.2 Memvalidasi global logikal data model Tujuan dari langkah ini adalah untuk memvalidasi relationship yang dibuat dari global logikal data model dengan menggunakan teknik dari normalisasi dan juga memastikan bahwa relationship yang dibuat mendukung transaksi. Langkah 3.3 Mengecek untuk kemungkinan pengembangan di masa depan Tujuan dari langkah ini adalah untuk menentukan bagian mana yang kelihatannya akan berubah ke masa depannya dan juga memperhatikan supaya global logikal data model dapat mengakomodasi perubahan tersebut. Langkah 3.4 Me-review global logikal data model dengan user Tujuan dari langkah ini adalah untuk memastikan bahwa global logikal data model itu memang merepresentasikan perusahaan yang ada.
41 Hasil akhir dari perancangan logikal basis data adalah merancang suatu model informasi berdasarkan model data spesifik yang ada (seperti model relasional), tetapi tidak tergantung terhadap suatu DBMS dan perangkat keras lainnya. Logikal Basis data merancang suatu map untuk setiap lokal konseptual data. Jika terdapat lebih dari satu view, maka lokal logikal data model akan dikombinasikan menjadi suatu global logikal data model yang merepresentasikan semua view dari suatu perusahaan.
Perancangan Basis data Fisikal untuk Model Relasional Tujuan dari langkah ini menurut Connolly dan Begg (2002, p282) adalah untuk mendeskripsikan pengimplementasian dari suatu database pada media penyimpanan secondary, itu juga akan mendeskripsikan dasar dari suatu relationship, file perusahaan, dan juga indeks yang digunakan untuk mencapai suatu
keefisienan
pengaksesan
data
dan
batasan-batasan
integritas serta ukuran keamanan. Langkah 4 Menerjemahkan Global Logikal Data Model sesuai DBMS yang dipakai Tujuan dari langkah ini adalah untuk membuat suatu skema relasional basis data dari global logikal data model yang dapat diimplementasikan ke DBMS yang dipakai.
42 Langkah 4.1 Merancang relationship dasar Tujuan dari langkah ini adalah untuk memutuskan bagaimana
merepresentasikan
relationship
dasar
yang
diidentifikasi dalam global logikal data model pada DBMS yang dipakai. Untuk memulai proses perancangan sistem basis data fisikal,
pertama-tama
anda
dapat
mengumpulkan
dan
mengasimilasikan suatu informasi tentang relationship yang dirancang selama perancangan sistem basis data logikal. Informasi yang diperlukan bisa berasal dari kamus data dan definisi dari relationship yang didefinisikan menggunakan Database Design Language (DBDL). Untuk setiap relationship yang diidentifikasi pada global logikal data model, definisinya terdiri dari:
•
Nama relationship
•
Suatu list untuk atribut yang simple
•
Primary key, alternative key, dan foreign key
•
Suatu
daftar
dari
atribut
turunan
dan
bagaimana
pembuatannya
•
Batasan
integrasi
diidentifikasi.
untuk
setiap
foreign
key
yang
43 Dari kamus data, dari setiap atributnya dapat diketahui:
•
Domain atribut tersebut yang terdiri dari tipe data, panjang, dan berbagai batasan pada domain
•
Suatu optional nilai default untuk atribut
•
Apakah atribut boleh bernilai null
Langkah 4.2 Merancang Representasi Data Turunan Tujuan dari langkah ini adalah untuk memutuskan bagaimana merepresentasikan suatu data turunan pada global logikal data model pada DBMS yang dipakai. Langkah 4.3 Merancang Batasan Perusahaan Tujuan dari langkah ini adalah untuk merancang batasan perusahaan untuk DBMS yang dipakai. Meng-update suatu relationship yang mungkin dibatasi oleh aturan perusahaan sesuai dengan transaksi yang sebenarnya bisa di-update. Perancangan batasan tersebut sekali lagi tergantung pada DBMS yang dipilih, fasilitas yang dimiliki oleh sistem dibandingkan dengan DBMS yang lain. Pada awalnya, jika sistem tersebut mempunyai aturan sesuai aturan standar SQL maka beberapa batasan dapat dengan mudah diterapkan. Langkah 5 Merancang Representasi Fisikal Tujuan dari langkah ini adalah untuk menentukan perusahaan file yang paling optimal untuk menyimpan relationship dasar dan indeks yang diminta untuk mencapai
44 performance yang diharapkan, yaitu dengan cara menyimpan berbagai relationship dan tuple pada secondary storage. Langkah 5.1 Menganalisa Transaksi Tujuan dari langkah ini adalah untuk mengerti fungsi dari suatu transaksi yang mana akan dijalankan pada basis data dan untuk menganalisa transaksi yang penting. Untuk membuat perancangan sistem basis data fisikal efektif maka perlu dimiliki pengetahuan mengenai transaksi atau query yang akan dijalankan di dalam basis data. Hal ini termasuk kuantitatif
atau
kualitatif
informasi.
Dalam
menganalisa
transaksi, dapat diidentifikasi kriteria performansi sebagai berikut:
•
Transaksi yang sering digunakan dan akan berdampak besar terhadap performansi keseluruhan
•
Transaksi yang merupakan transaksi bisnis yang kritis
•
Durasi waktu dalam harian atau mingguan yang akan mendapatkan banyak permintaan pada database.
Langkah 5.2 Memilih Perusahaan File Tujuan dari langkah ini adalah untuk menentukan perusahaan file yang efisien untuk setiap relasional data. Dalam banyak kasus yang ada, suatu relasional DBMS akan memberikan sedikit bahkan tanpa pilihan dalam memilih perusahaan file, walaupun beberapa akan mempunyai indeks
45 yang spesifik. Bagaimanapun, berikut ini beberapa perusahaan file yang ada adalah sebagai berikut:
-
Heap
-
Hash
-
Indexed Sequential Access Method (ISAM)
-
B+-tree
-
Clusters.
Langkah 5.3 Memilih Indeks Tujuan dari langkah ini adalah untuk menentukan apakah penambahan indeks akan meningkatkan performansi dari suatu sistem. Biasanya pemilihan atribut untuk indeks adalah sebagai berikut: •
Suatu atribut yang digunakan paling sering untuk operasi penggabungan, yang akan membuat penggabungan tersebut lebih efisien.
•
Suatu atribut yang digunakan paling banyak untuk mengakses suatu record di dalam relationship yang ada.
Langkah 5.4 Mengestimasi Kapasitas Penyimpanan yang Dibutuhkan Tujuan dari langkah ini adalah untuk mengestimasi ukuran kapasitas disk yang diperlukan untuk sistem basis data.
46 Langkah 6 Merancang tampilan Layar Tujuan dari langkah ini adalah untuk merancang tampilan user yang diidentifikasi selama pengumpulan informasi dan analisis dari siklus hidup aplikasi sistem basis data. Langkah 7 Merancang Mekanisme Keamanan Tujuan dari langkah ini adalah untuk merancang ukuran keamanan untuk basis data yang telah dispesifikasi oleh user. Definisi
dari
keamanan
basis
data
adalah
suatu
mekanisme yang memproteksi basis data dari suatu kejadian yang disengaja maupun yang tidak disengaja. Suatu basis data merupakan sumber dari perusahaan yang essential yang perlu dilindungi dengan menggunakan suatu kontrol yang memadai. Beberapa kasus keamanan basis data yang perlu diperhatikan, antara lain: 1.
Pencurian data (Theft & Fraud)
2.
Kehilangan kerahasiaan suatu data (Loss of Confidentially)
3.
Kehilangan hak pribadi (Loss of Privacy)
4.
Kehilangan integritas (Loss of Integrity)
5.
Kehilangan ketersediaan data (Loss of Availability). Hasil akhir dari perancangan fisikal basis data adalah
suatu proses yang mendeskripsikan suatu implementasi dari suatu basis data pada media penyimpanan. Ini mendeskripsikan
47 suatu relationship dasar dan struktur penyimpanan dan metode akses yang digunakan untuk mengakses data secara efektif, selama batasan integritas dan ukuran keamanan.
2.2
Teori Manajemen Aset Digital Menurut Penn State (2002) Digital Asset Management ( DAM ) adalah suatu set teknologi yang terkordinasi dan prosedur yang mengizinkan penyimpanan yang efisien, pengambilan informasi, dan penggunaan ulang file digital yang sangat penting bagi perusahaan. Dengan memasukkan informasi yang lengkap dan menempel pada asetnya, DAM dapat menyediakan dan mendukung peraturan bisnis dan proses dapat melakukan penyimpanan, indeks, keamanan, pencarian, eksport dan perubahan pada informasinya. Manajemen Aset Digital kadang juga dikenal dengan nama Media Asset Management. Media Asset Management ( MAM ) didefinisikan sebagai teknologi yang digunakan untuk mencari dan mengambil isi khusus dari sebuah objek dari media analog ke digital. Biasanya, asset digital adalah file media digital apapun yang mempunyai nilai ( value ). Asset digital sering memasukkan rich media seperti video, audio, dan graphics, tetapi tidak menjadi suatu persyaratan. Images, graphics, logos, video and sound files, web pages (HTML, XML), PDF documents, Quark and Illustrator files, MS Office files, free text files, ads, marketing collateral, brochures, product packaging designs, dan lainlain, merupakan objek digital. Biasanya perusahaan dan organisasi
48 mempunyai macam-macam asset digital seperti text, photos, logos, music, dan video yang mempunyai nilai potential untuk kedepannya. Apabila mereka bisa dilokasikan dan digunakan kembali. Apabila digambarkan didalam framework dari sistem DAM, definisi dari suatu asset merupakan kepentingan yang sangat kritis. Terdapat suatu kesepakatan umum bahwa asset digital
adalah isi asset ditambah dengan
metadata (atau data yang menerangkan isi tersebut). Metadata bisa berupa informasi tentang tipe format, rights dan izin, sejarah pemakaian (usage history), dan lain-lain. Pada awalnya DAM biasanya digunakan oleh produksi video, pre-press dan bagian penerbitan. Sehingga DAM muncul menjadi komponen penting bagi infrastruktur teknologi informasi. Revolusi internet dan pemusatan pada media digital telah meningkatkan DAM dari enterprise menjadi ke setiap industri. DAM adalah software infrastruktur yang mengizinkan organisasi untuk mengatur koleksi-koleksi dari bermacam-macam isi, dan juga menyiapkan dan meningkatkan isi untuk pengiriman ke semua tingkatan distribusi. DAM ingests, indexes, categorizes, mengamankan, mencari, menyimpan, memasang isi eksport. Pada kenyataanya suatu asset yang berbentuk digital mendapatkan kesempatan yang besar untuk revenue generation dan efisiensi operasional, ini memperlihatkan bahwa platform DAM memprioritaskan functionality dan dasar apa yang membedakan DAM dengan kelas software lainnya.
49 Terdapat tiga elemen dasar yang membedakan Digital Asset Management solution dengan isi management solutions lainnya : •
Organizing Principle. Asset didefinisikan sebagai suatu kombinasi spesifik dari suatu isi dan data yang mempunya nilai financial, apakah prinsip organisasi mendasari pengamanan, transaksi, rights dan fungsi sistem lainnya.
•
Functional Characteristics. Setiap komponen fungsional dari suatu Digital Asset Management solution ( termasuk ingestion, indexing, cataloguing, navigation, transformation dan export) harus memberikan dukungan penuh untuk semua tipe media (termasuk streaming dan format tetap) dan untuk semua traditional dan elektronik channel pengiriman.
•
Architecture. Yang mendasari architecture seharusnya component-based dan enterprise-worthy, untuk menyediakan pelaksana berkala dan penyaluran akses keseluruh organisasi.
Proses Manajemen aset digital adalah : •
Creation Seorang artis, penulis, editor, atau pembuat film akan menciptakan isi baru, dengan menggunakan materi yang ada sebagai dasarnya atau dengan menciptakan sesuatu yang isinya seluruhnya baru.
50 •
Indexing Setelah isi diciptakan dan disimpan, kemudian akan di indeks menurut berbagai macam kriteria yang disimpan dalam bentuk metadata. Metadata dapat digunakan untuk membuat catalog dari isinya itu sendiri. Contoh umum penggunaan metadata di dalam implementasi digital aset manajemen adalah perancangan key frames dari video MPEG-2.
•
Storage Isi yang baru tersimpan. Isi ini biasanya akan diarahkan langsung penyimpanan dalam hard drive dalam peralatan RAID, dengan arsip di dalam kaset, atau lebih baik di dalam optical jukebox.
•
Delivery User ( internal atau eksternal ) menerima permintaan dalam bentuk faktor yang sesuai. Ini mungkin dibutuhkan untuk membuat CD, DVD, atau kaset VHS dalam kasus apapun.
•
Resale Mengikuti indeks dari isi dan user online dapat mengakses isi katalog dari pengembang untuk memilih gambar dan video yang tersedia.
•
Reuse Dengan hak struktur manajemen yang berjalan pada media digital, pengembang dapat mencari dan memilih isi dari media digital untuk digunakan kembali. Eksekutif saat ini dapat membaca katalog dari
51 perusahaan untuk video, animasi, dan naskah yang relevan, daripada membaca secara keseluruhan. •
Review Sistem DAM menyediakan kemampuan untuk melihat kembali isi yang lama dengan mudah. Materi yang sudah kadaluarsa dapat diarsip secara offline atau dihapus dari sistem.
Keuntungan dari Manajemen Aset Digital ketika diimplementasikan yaitu : •
Lebih kompetitif
•
Menghemat waktu dan uang
•
Menyediakan perlindungan legal
•
Menciptakan revenue
