Kelebihan dan Kekurangan ODBMS (Copas)

Bisa digunakan sebagai bahan pertimbangan menggunakan ODBMS :

Walaupun OODB memiliki banyak keunggulan daripada RDB, OODB belum mampu
menggoyahkan kedudukan RDB. OODB merupakan teknologi baru yang populer di kalangan
ahli sistem basis data, tetapi pembuat aplikasi masih lebih memilih RDB daripada OODB.
Hal ini mungkin disebabkan para pembuat aplikasi tersebut belum mengenal lebih jauh OODB
atau ODBMS. Untuk memilih mana yang lebih cocok OODB atau RDB untuk proyek
yang kita kerjakan, ada baiknya kita perhitungkan Iaktor resiko, kebutuhan teknis, kinerja yang
diharapkan dan keseluruhan solusi teknis. Pada keadaan tertentu OODB merupakan suatu pilihan
tepat, tapi pada keadaan yang salah pilihan ini dapat berakibat besar.
Berikut ini beberapa kelebihan dan kelemahan OODB.
KELEBIHAN OODB
A. DESAIN YANG INDAH
Pada suatu sistem yang dinamis pemrogram sering harus menghabiskan banyak waktu dan
tenaga untuk menagani masalah data. Dengan OODB, masalah ini tidak hilang, tetapi dapat
dikurangi. Karena dengan orientasi obyek maka proses penyimpanan dan pengambilan data jauh
lebih sederhana.
Dengan OOP, program dan data terintegrasi dengan baik. Dengan paradigma orientasi obyek
dapat menyederhanakan aplication modelling, kebutuhan design tool dan visualisasi sisten dan
desainnya. Dengan OODB tidak hanya kita mendapatkan persistensi data tapi keseluruhan obyek
database, bahkan termasuk implemented behaviour-nya. Juga kita dapat memanggil suatu
method dari obyek tertentu pada database di server sehingga distribusi aplikasinya lebih mudah.
Dalam RDB untuk melaksanakan hal ini kita harus memasukkan stored procedure atau suatu
komponen obyek. Sehingga arsitektur dari aplikasi jadi lebih rumit dan membutuhkan keahlian
pemrograman lebih lanjut.
B. PENYEDERHANAAN PEMBUATAN APLIKASI
Dengan OODB kita dapat menyederhanakan pembuatan aplikasi dengan meminimalisasi
penggunaan bahasa pemrograman dan implementasi teknologi yang dibutuhkan. Terkadang kita
tidak menyadari bahwa suatu proyek menjadi lebih tinggi biayanya karen banyak Iaktor teknis
seperti penggunaan beberapa tool, bahasa program dan lingkungan dari aplikasi yang berbeda-
beda. Belum lagi biaya pelatihan dan lain-lain.
Dengan OODB maka kemampuan teknis yang dibutuhkan menjadi berkurang karena pemrogram
cukup menguasai konsep orientasi obyek (object oriented) dengan sedikit tambahan mengenai
koneksi ke database. Tentunya pemrogram harus juga menguasai bahasa pemrograman
berorientasi obyek seperti C atau Java.
Selain itu pemrogram tinggal memIokuskan pada persistensi obyek. Pemrogram tidak perlu lagi
meguraikan obyek ke tabel, memikirkan relasi antar tabel, dan sebaliknya.
C. KINER1A YANG TANGGUH
Pada produk ODBMS yang tepat dan sesuai dengan aplikasi yang dibuat, OODB dapat
meningkatkan kinerja aplikasi dengan peningkatan yang tinggi.
Seperti yang beberapa kali penulis sebutkan, dengan RDB seorang pemrogram harus
menghabiskan waktu untuk memetakan data dengan obyek, menguraikan tabel-tabel ke dalam
obyek dan sebagainya. Terkadang hal ini mencapai sepertiga atau bahkan separuh dari program
itu sendiri. Hal ini menyebabkan juga kinerja program lebih lambat karena harus melaksanakan
pemetaan obyek tersebut. Belum lagi program harus melaksanakan beberapa query yang makin
memperlambat kinerja program tersebut.
Dengan OODB tentu kinerja program dapat lebih baik karena hal-hal di atas tidak lagi
diperlukan. Karena program langsung mengakses data dengan obyeknya.
Pada beberapa produk ODBMS bahkan dimungkinkan adanya client caching. Bayangkan
kecepatan yang dapat dihasilkan bila program hanya perlu mengakses chache dari database yang
sudah ada di client.
KELEMAHAN OODB
A. TIGHT COUPLING
Istilah tight coupling maksudnya antara aplikasi dengan data sedemikian rupa terikat hingga sulit
dipisahkan satu dengan lainnya. Misalnya sistem database MicrosoIt Access dengan bahasa
pemrograman MS-Visual Basic mempunyai hubungan loose couple karena kita dapat
menggunakan banyak pilihan sistem basis data untuk program dalam MS-Visual Basic dan juga
dapat menggunakan banyak pilihan bahasa pemrograman lainnya untuk mengakses data dalam
MS-Access. Sementara bahasa COBOL dengan databasenya sangat tight couple karena sulit
mengakses database COBOL dengan bahasa pemrograman lain.
Sementara tight coupling mempunyai keuntungan karena menyederhanakan program dan
desainnya, akan tetapi hal ini memiliki kekurangan karena ini menghilangkan hijab* antara
database dengan aplikasi. Juga menyebabkan suatu kendala baru bila kita ingin bermigrasi ke
produk ODBMS yang berbeda atau kembali ke RDB.
hijab* batas/pemisah.
B. KINER1A YANG MUNGKIN KURANG BAIK
Sebelumnya penulis telah memaparkan bagaimana keperkasaan kinerja OODB terutama dalam
hal mengakses data. Tetapi di sini penulis perlu juga menyampaikan bahwa bada kondisi tertentu
mungkin saja OODB menghasilkan kinerja yang buruk. Misalnya pelaksanaan ad-hoc query
yang sangat lemah dalam OODB.
Memang dalam beberapa hal produk ODBMS masih kalah dengan produk RDBMS yang telah
lebih lama beredar di pasaran. Diantaranya masalah-masalah Iungsionalisasi dan optimalisasi
query ini. Wajar saja mengingat usia OODB yang relatiI muda.
C. KURANGNYA DUKUNGAN PLATFORM
Pada dasarnya OODB dapat diterapkan pada bahasa pemrograman orientasi obyek apa saja, tapi
produk ODBMS yang ada masih kebanyakan diorientasikan untuk digunakan dalam bahasa Java
dan C. Disamping itu juga belum banyak tersedia komponen untuk pengaksesan OODB
untuuk bahasa pemrograman lainnya.
Walaupun OODB dapat diimplementasikan dalam Java yang platIorm independent, belum tentu
pada platIorm yang kita miliki mendukung implementasi Java. Selain itu Java juga memiliki
aneka nuansa dan keanehan-keanehan bila diterapkan pada lingkungan yang berbeda.
D. SULIT BERMIGRASI
Cara penyimpanan dan pengambilan data pada OODB sangat berbeda dengan RDB. Demikian
juga cara pengaksesannnya. Oleh karena itu, bila kita bermigrasi ke OODB maka kita harus
berkomitmen untuk terus menggunakan OODB. Setelah mengimplementasikan OODB, sangat
sulit untuk kembali ke RDB.
E. KEBUTUHAN KETERAMPILAN
Mencari seseorang yang memiliki kemampuan spesiIik pada salah satu ODBMS jauh lebih sulit
daripada mencari seseorang yang memiliki pemahaman RDB dan penguasaan salah satu
database seperti MS-Access, MS-SQL server, Oracle dan lain-lain. Lebih sulit lagi mencari
seorang yang benar-benar menguasai administrasi sistem OODB.
Peralihan dari paradigma RDB ke OODB juga membutuhkan pelatihan khusus karena
banyaknya perbedaan pendekatan diantaranya perIorma, locking, join dan lain lain.
F. QUERY YANG KOMPLEKS
Pada masing-masing ODBMS terkadang memiliki cara query yang berbeda. Selain itu terkadang
kita tidak mengakses data dengan cara memanggil ObjectID-nya saja, tetapi kadang berdasarkan
range, pola dan beragam kriteria lain yang mungkin kelihatannya tidak berhubungan. Ini
berakibat penggunaan OODB membutuhkan kemampuan logika yang mendalam.
OODB memang sebuah teknologi yang mengagumkan dan menyuguhkan berbagai kemampuan
yang telah lama diidam-idamkan. Tapi sayangnya masing-masing produk OODB atau ODBMS
memiliki kelebihan dan kekurangan yang berbeda-beda. Kita harus hati-hati mengevaluasi suatu
produk ODBMS untuk kebutuhan kita.
UB)ECT URIENTED DATABASE
PENGERTIAN OBJECT
Objek merupakan kesatuan entitas (baik), baik yang berwujud nyata ataupun hanya satu sistem yang
memodelkan dunia nyata. Setiap object diidentiIikasi oleh object identiIier(OID), dan juga memiliki state
dan behavior. State terdiri dari nilai object properties. Properti dari sebuah object dapat berupa atribut
atau relasi antar object. Sedangkan behavior dispesiIikasikan oleh operasi atau method yang dapat
dieksekusi oleh sebuah object melalui propertinya.


KARAKTERISTIK OBJECT
Sebuah object, mempunyai:
1. identiIier : unique id
2. name : unique name dalam DB (optional)
3. liIetime : menetapkan apakah object persistent atautransient
4. structure : pembangunan object menggunakantype constructors

STRUKTUR OBJEK
State (current value) dari object bias dibangun dari object lain (other values) dengan menggunakan type
constructors tertentu.
Constructors :
Basic types : atom, tuple dan set
Collection type : list, bag dan array

KONSEP OBJECT ORIENTED
Abstract Data Types
mendeIinisi Kelas, menyediakan ekstensi untuk jenis atribut kompleks
Encapsulation
Melaksanaan operasi dan struktur objek tersembunyi
Inheritance
Membagi data dalam lingkup hirarki, mendukung reusabilitas kode
Polymorphism
Operator overloading

PENGERTIAN OBJECT ORIENTED DATABASE
Object-oriented database adalah salah satu jenis database dimana data direpresentasikan dalam bentuk
object. Object Oriented Database merupakan sebuah sistem data base yang menggabungkan semua
konsep penting dari object oriented.
Pendekatan ini sangat dipengaruhi oleh bahasa pemrograman object-oriented dan dapat dipahami sebagai
usaha untuk menambah Iungsionalitas DBMS pada lingkup bahasa pemrograman.
Kelebihan OODB
1. Bisa menspesiIikasikan structure dari object dan behaviornya (methods).
2. Interaksi yang lebih baik dengan bahasa pemrograman berorientasi object seperti java dan C
3. DeIinisi kompleks dan user-deIined jenis
4. Enkapsulasi operasi dan user-deIined metode

OODBMS
OODBMS merupakan database management system (DBMS) yang mendukung pemodelan dan
pembuatan data sebagai objek.
OODBMS mendukung2 kriteria: DBMS dan object-oriented.
Keuntungan dan Kerugian OODBMS
Keuntungan:
1. Gabungan objek dan relationship
2. Class Hirarki
3. Menggagalkan kebutuhan Query
4. Tidak ada Primary Key
5. 1 Data model
Kerugian :
1. Perubahan schema
2. Ketergantungan Bahasa
3. Kekurangan Query Ad Hoc

Temporal Database
)une , 9
oleh Matthew 13507012
Post 1 (10 1uni 2009)
Pengenalan Database Temporal:
Database temporal merupakan database non-relational yang terintegrasi dengan aspek waktu,
misalnya model data temporal dan versi temporal dari bahasa query terstruktur.
Lebih spesiIik lagi aspek temporalnya biasa sudah termasuk waktu yang valid dan waktu
transaksi. Atribut-atribut ini muncul bersamaan pada Iorm data bitemporal.
O WakLu yang valld dlLun[ukkan dengan perlode wakLu ke[adlan yang sama dengan wakLu pada
dunla sebenarnya
O WakLu Lransaksl adalah perlode wakLu saaL menylmpan suaLu ke[adlan ke daLabase
O aLa blLemporal mengkomblnaslkan wakLu valld dan wakLu Lransaksl
Keterangan: kedua periode waktu tidak harus sama untuk suatu kejadian yang sama. Misalkan
kita menyimpan databse pada database temporal pada abad ke 18. Waktu yang valid adalah
diantara 1701 dan 1800. Sedangkan waktu transaksi dihitung pada saat kita memasukan suatu
kejadian ke dalam databse, contoh 21 Januari 1998.
Mengapa Kita Butuh Database Temporal:
Sejak dua decade terakhir, model data relational sudah menjadi sangat popular karena simpel dan
memiliki Iondasi matematis yang solid. Namun, model data relational seperti yang dikatakan
Codd|Cod70| tidak menyimpan address dari dimensi temporal suatu data. Data yang seharusnya
dibedakan dari waktunya tetap diperlakukan sama dengan data lainnya. Hal ini tidak memenuhi
aplikasi yang harus membedakan nilai data pada waktu lampau, saat ini, dan/atau data pada masa
depanpadahal dikehidupan nyata kita akan sering berurusan dengan data seperti ini.
Kenyataannya, kebanyakan aplikasi membutuhkan data temporal untuk keperluan
tertentu.
Tujuan Utama dari Database Temporal:
O ,engldenLlflkasl Llpe daLa yang cocok dengan wakLu
O ,encegah hllang/berubahnya deskrlpsl suaLu ob[ek LerLenLu
O ,enyedlakan al[abar query unLuk mengaLasl daLa Lemporal
O @eLap compaLlble dengan daLabase lama yang Lldak menggunakan daLa Lemporal
Apa yang Dapat Kita Lakukan dengan Database Temporal:
O ,udah dalam menger[akan daLa Lemporal
O ,erecord seLlap perubahan daLa dengan balk sekall
O eLlap pendeskrlpslan ob[ek dapaL dldeflnlslkan Lanpa ada perubahan yang Lldak dllnglnkan
O ,emlllkl model relaLlonal unLuk mendeskrlpslkan daLa Lemporal
O ,emlllkl al[abar query unLuk mengaLasl daLa Lemporal
O @eLap mampu mengaLasl daLa sLaLlc (Lanpa dlmensl wakLu) pada daLabase Lemporal
O l[abar daLabase yang lama LeLap dapaL ber[alan dl daLabase Lemporal
O l[abar query yang baru unLuk mengkonLrol dlmensl wakLu mlrlp dengan al[abar daLabase yang
lama
Solusi lain tentang Database Temporal:
O ,enambahkan wakLu valld
O ,enambahkan wakLu Lransaksl
O ,enambahkan kedua hal dl aLas
O 9endekaLan lalnnya
Post 2 (23 1uni 2009)
Untuk memperjelas pengertian mengenai database temporal, maka saya akan memasukan sebuah
contoh yang membandingkan penanganan suatu kasus bila dibuat database secara biasa dan
dengan database menggunakan database temporal.
Contoh kasus yang diambil berasal dari biograIi singkat tokoh buatan bernama Joel Wahyudi.
Joel Wahyudi lahir pada tanggal 3 April 1975 di rumah sakit Medicine County, sebagai anak dari
Hendro Wahyudi dan Irma Wahyudi yang bertempat tinggal di Smallville. Hendro Wahyudi
dengan bangga mendaItarkan kelahiran anak pertamanya tanggal 4 April 1975 di kota Smallville.
Joel tumbuh besar menjadi seorang pelajar cemerlang dan lulus dengan sangat baik pada tahun
1993. Setelah kelulusan, ia pergi untuk hidup sendiri di kota Bigtown. Meski Joel pindah pada
tanggal 26 Agustus 1994, ia lupa untuk mendaItarkan perubahan alamatnya secara resmi. Hingga
akhirnya pada akhir musim, ibunya mengingatkan Joel untuk mendaItarkan kepindahannya, yang
kemudian ia lakukan beberapa hari setelahnya yaitu pada 27 Desember 1994. Meskipun Joel
memiliki masa depan yang sangat menjanjikan, namun kisahnya berakhir dengan tragis. Joel
Wahyudi mengalami kecelakaan tertabrak truk pada 1 April 2001. Yang pada hari itu juga
langsung dilaporkan berita kematiannya secara resmi.

Menggunakan Database Standar:
Untuk menyimpan kehidupan Joel Wahyudi di sebuah (non-temporal) tabel database, kita
menggunakan table !erson(Name,Address). Untuk memudahkan, Name kita buat menjadi
primary key dari tabel !erson.
Ayah Joel secara resmi melaporkan kelahiran anaknya pada 4 April 1975. Hal ini berarti pada
sebuah kantor di Smallville, dimasukan data berikut ke database pada tanggal saat itu:
Person(Joel Wahyudi,Smallville). !erhatikan bahwa tanggalnya sendiri tidak dimasukan ke
database. Setelah lulus kemudian Joel pindah, namun ia lupa mendaItarkan alamat barunya. Data
milik Joel pada database tidak berubah sampai 27 Desember 1994, yaitu ketika akhirnya ia
mendaItar ke kantor di Bigtown. Kantor di Bigtown mengupdate alamatnya di database. Tabel
!erson saat ini berisi Person(Joel Wahyudi,Bigtown). !erhatikan bahwa informasi alamat Joel
di Smallville telah ditimpa. Maka tidak ada cara untuk mengakes inIormasi yang hilang tersebut
melalui database. Setiap kantor yang mengakses databse pada 28 Desember 1994 akan
mendapatkan Joel tinggal di Bigtown. Secara teknis: jika sebuah komputer melakukan query
SELECT ADDRESS FORM PERSON WHERE NAME`Joel Wahyudi` pada 26 Desember
1994, menghasilkan: Smallville. Menjalankan query yang sama pada 2 hari selanjutnya
menghasilkan Bigtown.
Sampai dengan kematian trgaisnya, database akan menyatakan Joel tinggal di Bigtown. Pada 1
April 2001 akhirnya petugas menghapus Joel Wahyudi dari databse. Maka pemanggilan query di
atas tidak akan menghasilkan hasil apapun.
1angga|
ang ter[ad| d| dun|a
nyata
erubahan d|
Database
1amp||an d|
Database
3 prll
1973
kelahlran !oel @ldak ada
@ldak ada 9erson
dengan nama !oel
Wahyudl
4 prll
1973
Pendro melaporakan
kelahlran anaknya ke
kanLor secara resml
lnserLed9erson(!oel
Wahyudl mallvllle)
!oel Wahyudl
Llnggal dl mallvllle
26
gusLus
1994
eLelah kelulusan
!oel plndah ke
8lgLown namun lupa
unLuk meregrlsLaslkan
alamaL barunya
@ldak ada
!oel Wahyudl
Llnggal dl mallvllle
26
esember
1994
@ldak ada @ldak ada
!oel Wahyudl
Llnggal dl mallvllle
27
esember
1994
!oel mendafLarkan
alamaL barunya
updaLed9erson(!oel
Wahyudl 8lgLown)
!oel Wahyudl
Llnggal dl 8lgLown
1 prll
2001
!oel menlnggal
eleLed9erson(!oel
Wahyudl)
@ldak ada 9erson
dengan nama !oel
Wahyudl
Post 3 (1 1uly 2009)
Menggunakan Database Temporal dengan Waktu yang Valid:
Waktu yang valid (valid time) yang berarti waktu sebernarnya di dunia nyata. Pad contoh di atas,
tabel Person mendapat dua Iields tambahan, yaitu Valid-From dan Valid-To, yang menjelaskan
kapan Address seseorang berlaku di dunia nyata. Pada 4 April 1975, Hendro dengan bangga
mendaItarkan kelahiran anak pertamanya. Maka petugas akan memasukkan data tersebut ke
database yang menjelaskan Joel bertempat tinggal di Smallville sejak 3 April. Perlu diketahui
meski data dimasukkan pada 4 April, namun database menjelaskan bahwa inIormasi tersebut
berlaku sejak tanggal 3. Petugas belum mengetahui apakah atau kapan Joel akan berpindah ke
tempat lain, sehingga pada Iield Valid-To di database diisi dengan infinity (). Pemasukkan data
ke basisdata berupa:
Person(Joel Wahyudi, Smallville, 3-Apr-1975, ).
Pada tanggal 27 Desember 1994, Joel melaporkan alamat barunya di Bigtown yang sudah ia
tinggali sejak 26 Agustus 1994. Petugas di kantor Bigtown tidak merubah alamat milik Joel di
database. Sang petugas menambahkan yang baru:
Person (Joel Wahyudi, Big Town, 26-Aug-1994, ).
Masukan data milik Joel sebelumnya (Joel Wahyudi, Smallville, 3-Apr-1975, ) kemudian
diupdate (tidak dihapus!). karena diketahui Joel sudah tidak tinggal di Smallville pada 26
Agustus 1994, maka kolom Valid-To dapat terisi. Database kemudian memiliki dua buah entry
milik Joel
Person(Joel Wahyudi, Smallville, 3-Apr-1975, 26-Aug-1994).
Person(Joel Wahyudi, Bigtown, 26-Aug-1994, ).
Saat Joel meninggal, database diupdate sekali lagi. Entry terbaru akan diupdate menyatakan
bahwa Joel tidak tinggal di Bigtown lagi. Tidak ada entry yang ditambahkan karena tidak pernah
dilaporkan surge sebagai alamat baru. Maka database sekarang akan seperti ini
Person(Joel Wahyudi, Smallville, 3-Apr-1975, 26-Aug-1994).
Person(Joel Wahyudi, Bigtown, 26-Aug-1994, 1-Apr-2001).

Menggunakan Database Temporal dengan Waktu Transaksi:
Waktu transaksi adalah penggunaan database temporal menggunakan waktu pada saat transaksi
dilakukan. Dengan ini kita dapat menggunakan queri-queri yang menampilkan status database
pada waktu tertentu. Maka ada dua tambahan kolom di tabel Person: Transaction-From dan
Transaction-To. Transaction-From merupakan waktu saat transaksi dilakukan, sedangkan
Transaction-To adalah waktu transaksi dibatalkan (atau menggunakan tak terhingga jikan belum
akan dibatalkan).
Apakah yang akan terjadi jika alamat seseorang yang ada di database merupakan alamat yang
salah? Anggap seorang petugas secara tidak sengaja memasukkan alamat atau tanggal yang
salah? Atau, anggap orang yang memasukkan data berbohong ketika memberi inIormasi untuk
keperluan tertentu. Setelah mengetahui data yang benar, maka petugas harus kembali
mengupdate database tersebut.
Sebagai contoh, dari 1 Juni 1995 hingga 3 September 2000 Joel Wahyudi pindah ke Beachy.
Namun untuk menghindari membayar pajak kota Beachy yang sangat mahal, Joel tidak pernah
melapor ke yang berwewenang. Akhirnya, hal tersebut terungkap pada 2 Februari 2001 saat ada
pengecekan pembayaran pajak, bahwa dia sebenarnya tinggal di Beachy selama ini, maka para
petugas mengupdate database menjadi seperti ini:
Person(Joel Wahyudi, Bigtown, 26-Aug-1994, 1-Jun-1995).
Person(Joel Wahyudi, Beachy, 1-Jun-1995, 3-Sep-2000).
Person(Joel Wahyudi, Bigtown, 3-Sep-2000, 1-Apr-2001).
Maka 2 data yang sudah ada di update, dan sebuah data baru dimasukkan menyimpan
keberadaannya di Beachy.
Bagaimanapun, hal ini tidak meninggalkan catatan di database yang menyatakan Joel tinggal di
Bigtown dari 1 Juni 1995 hingga 3 September 2000, yang mungkin sangat penting untuk alasan
mengaudit data (atau untuk menjadi bukti pada investigasi kantor pajak). Di sini kita dapat
melihat waktu transaksinya. Kita harus menyimpan setiap data ketika dimasukkan dan ketika
dibatalkan. Maka dari itu, kita memperoleh data seperti berikut:
Person(Joel Wahyudi, Smallville, 3-Apr-1975, , 4-Apr-1975, 27-Dec-1994).
Person(Joel Wahyudi, Smallville, 3-Apr-1975, 26-Aug-1994, 27-Dec-1994, ).
Person(Joel Wahyudi, Bigtown, 26-Aug-1994, , 27-Dec-1994, 2-Feb-2001 ).
Person(Joel Wahyudi, Bigtown, 26-Aug-1994, 1-Jun-1995, 2-Feb-2001, ).
Person(Joel Wahyudi, Beachy, 1-Jun-1995, 3-Sep-2000, 2-Feb-2001, ).
Person(Joel Wahyudi, Bigtown, 3-Sep-2000, , 2-Feb-2001, 1-Apr-2001 ).
Person(Joel Wahyudi, Bigtown, 3-Sep-2000, 1-Apr-2001, 1-Apr-2001, ).
Jadi, kita tidak hanya menyimpan apa yang terjadi di waktu yang berbeda, tetapi kita juga
menyimpan data yang berubah secara resmi pada waktu yang berbeda.
Permasalah utama pada database dengan waktu transaksi adalah saat mengembangkan queri-
queri temporal dibawah penggunaan skemanya. Untuk mencapai pengarsipan data yang
sempurna, sangat penting untuk menyimpan data dibawah skema awal ketika database dibuat.
Namun, sesimpel apapun queri temporal, riwayat sebuah atributnya tetap butuh ditulis manual di
setiap versi skemanya, dan mungkin ratusan kasus seperti pada kasus MediaWiki
(http://yellowstone.cs.ucla.edu/schema-evolution/index.php/SchemaEvolutionBenchmark).
Proses ini membutuhkan usaha yang sangat besar dari pengguna untuk merapihkan database
tersebut. Penyelesaian umumnya dilakukan dengan menyediakan penulis queri secara otomatis.
Post 4 (24 1uly 2009)
Sebelum melanjutkan ke topik selanjutnya, perlu diingat satu konsep penting tentang ke presisian
waktu yang di simpan di database temporal. Konsep ke presisian dari sebuah database temporal
disebut granularity of the time (serpihan waktu). Granularity merupakan unit terkecil durasi
waktu yang disimpan pada database temporal kita. Contoh serpihan waktunya yaitu satu hari,
satu jam, atau satu detik.
Konsep Utama dalam Memahami Database Temporal
Telah kita ketahui dua tipe waktu utama dalam konsep database temporal, yaitu waktu transaksi
(transaction time) dan waktu yang valid (valid time), memungkinkan 3 bentuk database temporal
: Historical, Rollback, dan Bitemporal. Sebuah database temporal historical dapatmensuport
valid time, tapi tidak dapat menggunakan transaction time. Tipe kedua yaitu rollback database,
database ini kebalikannya dari database historical, yaitu menggunakan transaction time dan tidak
dapat menggunakan valid time. Rollback database sangat berguna dalam data recovery setelah
jika terdapat kerusakan pada temporal database. Sebuah database rollback juga diperlukan jika
database tidak di proteksi untuk menjaga keamanan data. Sehingga saat ini pada pasar tingkat
dunia, minimal biasanya menyediakan beberapa Iitur rollback.
Temporal database yang sebenarnya adalah database bitemporal. Database ini mensuport
keduanya, yaitu transaction time dan valid time, sehingga menghasilkan kombinasi bentuk
database historical dan rollback. Database bitemporal mampu mengatasi permasalahan dimensi
waktu; dalam tingkat DBMS yaitu transaction time, dalam tingkat data yaitu valid time, dan
dalam tingkat user menggunakan user-deIined time.
Tujuan Utama bagi Database Temporal. Kemampuan Query
Salah satu Iaktor terpenting dalam menggunakan database yang mensuport dimensi temporal,
yaitu kemampuan untuk menjalankan data dengan query. Saat ini yang umum digunakan untuk
database conventional (relational) adalah Structured Query Language atau yang biasa kenal
dengan SQL. SQL sudah menjadi bahasa standar di industri untuk Relational Database
Management Systems (RDBMS) karena kemudahan dalam menggunakannya yang sintaksnya
mirip dengan bahasa Inggris langsung. SQL termasuk user Iriendly dan dapat digunakan untuk
berbagai keperluan. Bagaimanapun penambahan element temporal ini meningkatkan
kompleksitas query pada data temporal. Dengan penambahan elemen time, dalam
kemampuannya saat ini SQL tidak dapat memproses query query tersebut seperti biasanya pada
kondisi database klasik (relational). Bahasa query yang baru atau perluasan dari SQL sangat
diperlukan di sini. Perlu diketahui, salah satu permasalahan terbesar yang diteliti saat-saat ini
adalah di bagian temporal database. Hari-hari ini, tidak sedikit bahasa-bahasa dan perluasan
bahasa-bahasa query yang mengajukan dan membahas topik ini. Topik ini cukup memerlukan
perhatian khusus, dan salah satu contohnya akan diberikan berikut ini.
Bahasa query temporal yang baru harus dapat mensuport kemampuan SQL tanpa mengurangi
kemampuan sebelumnya. SQL sudah memberi bantuan yang sangat besar dan mendominasi
RDBMS saat ini karena, seperti yang kita ketahui sebelumnya, SQL cocok untuk banyak
keperluan bisnis dan merupakan bahasa yang user Iriendly. Salah satu bahasa query yang paling
diharapkan adalah bahasa query yang mensuport dimensi waktu dan tetap memungkinkan user
memasukan query tanpa menetapkan dimensi waktunya (hal tersebut menhindari biaya lebih).
Dan bahasa tersebut bukanlah sebuah bahasa yang baru, melainkan perluasan dari bahasa SQL.
Satu contoh yang paling menarik adalah TSQL. TSQL yang merupakan Temporal Structured
Query Language dapat berjalan tanpa harus memasukkan kriteria waktu. Karena demikian,
ketentuan-ketentuan utama dari query TSQL masih sama dengan ketentuan-ketentuan di SQL:
yaitu SELECT` dan FORM`. Jika perlu juga terdapat WHERE`, GROUP BY`, HAVING`,
dan ORDER BY`. Kriteria tambahan pada TSQL dapat berupa WHEN` atau WHILE`. Kedua
nama query tersebut bermaksud menjelaskan perbedaan kondisi waktu. Klausa WHEN`
menjelaskan perincian 'sepotong waktu untuk data yang valid atau tidak valid tergantung hasil
yang diinginkan. Saat ini, pengajuan untuk menambahkan TSQL ke ANSI dan ISO milik SQL
standar sedang dipertimbangkan oleh pihak-pihak yang mengaudit.
Post 5 (8 Agustus 2009)
Setelah membahas teori-teori mengenai database temporal, pada bagian terakhir ini saya akan
menggabungkan bagian teori dengan bagian praktiknya langsung mengenai database temporal.
Di sini,akan dijelaskan mengenai beberapa tipe bisnis yang dapat mendapat keuntungan lebih
dengan bantuan database temporal.
Data Warehouse
Data warehouse atau pergudangan data bukan merupakan bisnis per se (bukan bisnis itu sendiri,
tapi mengambil dari bisnis lain). Data warehouse ini merupakan usaha yang sangat luas, yaitu
bisnis yang diperuntukan menyimpan seluruh inIormasi dari beberapa perusahaan. Data
warehouse terbukti sangat berguna sebagai tempat penyimpanan inIormasi yang dikumpulkan
dengan tools data mining dan digunakan untuk sumber inIormasi. Seperti yang sudah kita
ketahui, elemen waktu sangat penting untuk berbagai bisnis, dan dalam sebuah data warehouse
dimensi waktu dapat disimpan dan digunakan dalam peng query an data. Sebenarnya apa yang
data warehouse lakukan dengan adanya database temporal? Menurut Ralph Kimball, setiap data
warehouse memiliki dimensi waktu yang membuat setiap data warehouse menjadi database
warehouse |Kimball 1997|,|Snodgrass 1998|.Dimensi waktu adalah unik dan merupakan
dimensi yang kuat dalam setiap kumpulan data dan usaha data warehouse|Kimball 1997|.
Laboratorium Ilmiah
Jenis bisnis yang kedua adalah lab ilmiah (scientiIic laboratory). Setiap lab tentu melakukan
banyak uji coba dan banyak versi untuk percobaan yang sama, dan setiap percobaan sering kali
melibatkan urutan waktu yang sangat teliti. Agar inIormasinya tidak ada yang hilang, tentunya
harus disimpan dalam sebuah database. Karena elemen waktu di test ini jelas tidak bisa
dihilangkan, sehingga inIormasi yang disimpan di sini harus disimpan dalam database temporal.
Satu keuntungan dalam menyimpan inIormasi ujicoba ilmiah pada temporal database yang
mendukung bahasa query temporal adalah, sebuah pola baru dan pengetahuan baru dapat digali
dari basis data |Loomis 1997|.
Sales dan Marketing
Kedua bisnis ini sangat berkantung pada temporal database, karena keberhasilan sales dan
marketing sangat bergantung pada waktu yang tepat. Waktu untuk pendekatan dengan pelanggan
dan kapan untuk mengiklankan di lokasi tertentu sangat diperlukan, dan kemampuan untuk
meramalkan inIormasi ini jauh lebih baik disediakan database temporal daripada database klasik
biasa.
Multimedia
Jenis bisnis yang terakhir adalah multimedia. Multimedia merupakan salah satu area bisnis yang
paling cepat berkembang saat ini, terutama melalui jalus internet. Seseorang saat ini dengan
mudah menonton Iilm dari internet, dimana gambar video tersebut sudah tersimpan di database
multimedia yang harus disinkronisasikan dengan data audio yang mungkin berada di database
yang sama atau berbeda. Pengsinkronisasian ini, seperti kata tersebut sendiri, jelas melibatkan
elemen waktu. 'Karen multimedia berbasis waktu, sinkronisasi sangat di butuhkan. Jika
diimplementasikan dengan baik, maka komponen-komponen media tersebut akan ditampilkan
dengan ketepatan dari sinkronisasi yang baik|David|. 'Objek-objek multimedia memiliki relasi
dan ruang temporary yang harus dijaga saat ditampilkan beberapa data memiliki batasan waktu
nyata (real time) saat menyampaian ke stasiun clien|Ozsu|. Karena itu, database untuk
multimedia, seperti data warehouse, merupakan instance dari database temporal juga.
Sebagai penutup, akan dibahas sedikit mengenai database temporal di masa mendatang. Dengan
meningkatnya persaingan di lingkungan bisnis, pengetahuan akan inIormasi antar organisasi
menjadi sumber yang berharga. Salah satu elemen kunci dari inIormasi ini adalah dimensi waktu.
Untuk mendapatkan inIormasis ini, dalam bisnis harus digunakan database temporal. Dalam
menerapkan kemampuan menyimpan variable waktu pada bisnis yang ada, akan terdapat dua hal
yang berpengaruh. Pertama, kebanyakan produsen basis data komersial akan berlomba-lomba
memasukkan kemampuan temporal data di produk basis data mereka. Kedua, extension temporal
database akan dimasukkan ke ANSI dan ISO SQL standar yang sudah ada. Hal ini akan
memungkinkan pengguna untuk mengambil keuntungan dari Iitur temporal baru pada produk
database yang biasa mereka gunakan. Pada titik ini, sebagian besar dari produsen database
komersil akan menggunakan database temporal. Hal ini memungkinkan pengetahuan akan
inIormasi yang lebih lengkap dan lebih baik dapat disimpan dan diambil dari database temporal,
yang membuat bisnis-bisnis beralih menggunakan temporal database untuk bersaing dengan
bisnis lainnya.

DAFTAR PUSTAKA
http://www.cs.aau.dk/~csj/Thesis/pdI/chapter1.pdI, waktu akses: 10 Juni 2009
http://www.csie.ntu.edu.tw/~hhlee/temporal/introduction.html, waktu akses: 10 Juni 2009
http://en.wikipedia.org/wiki/Temporaldatabase, waktu akses: 10 Juni 2009
http://www.csie.ntu.edu.tw/~tempdb2007/, waktu akses: 10 Juni 2009
http://citm.utdallas.edu/publications/whitepapers/wptemporaldb.htm, waktu akses : 24 July
2009
http://www.dbdebunk.com/page/page/2317382.htm, waktu akses: 23 Juni 2009

Temporal Database
December 28, 2010 12:36 am } Campuran, Kuliah }
Pengenalan Database Temporal:
Database temporal merupakan database non-relational yang terintegrasi dengan aspek waktu,
misalnya model data temporal dan versi temporal dari bahasa query terstruktur.
Lebih spesiIik lagi aspek temporalnya biasa sudah termasuk waktu yang valid dan waktu
transaksi. Atribut-atribut ini muncul bersamaan pada Iorm data bitemporal.
Waktu yang valid ditunjukkan dengan periode waktu kejadian yang sama dengan waktu pada
dunia sebenarnya
Waktu transaksi adalah periode waktu saat menyimpan suatu kejadian ke database
Data bitemporal mengkombinasikan waktu valid dan waktu transaksi
Keterangan. kedua periode waktu tidak harus sama untuk suatu kejadian yang sama. Misalkan
kita menyimpan databse pada database temporal pada abad ke 18. Waktu yang valid adalah
diantara 1701 dan 1800. Sedangkan waktu transaksi dihitung pada saat kita memasukan suatu
kejadian ke dalam databse, contoh 21 Januari 1998.
Mengapa Kita Butuh Database Temporal:
Sejak dua decade terakhir, model data relational sudah menjadi sangat popular karena simpel dan
memiliki Iondasi matematis yang solid. Namun, model data relational seperti yang dikatakan
Codd|Cod70| tidak menyimpan address dari dimensi temporal suatu data. Data yang seharusnya
dibedakan dari waktunya tetap diperlakukan sama dengan data lainnya. Hal ini tidak memenuhi
aplikasi yang harus membedakan nilai data pada waktu lampau, saat ini, dan/atau data pada masa
depanpadahal dikehidupan nyata kita akan sering berurusan dengan data seperti ini.
Kenyataannya, kebanyakan aplikasi membutuhkan data temporal untuk keperluan tertentu.

Tujuan Utama dari Database Temporal:
MengidentiIikasi tipe data yang cocok dengan waktu
Mencegah hilang/berubahnya deskripsi suatu objek tertentu
Menyediakan aljabar query untuk mengatasi data temporal
Tetap compatible dengan database lama yang tidak menggunakan data temporal
Apa yang Dapat Kita Lakukan dengan Database Temporal:
Mudah dalam mengerjakan data temporal
Merecord setiap perubahan data dengan baik sekali
Setiap pendeskripsian objek dapat dideIinisikan tanpa ada perubahan yang tidak diinginkan
Memiliki model relational untuk mendeskripsikan data temporal
Memiliki aljabar query untuk mengatasi data temporal
Tetap mampu mengatasi data static (tanpa dimensi waktu) pada database temporal
Aljabar database yang lama tetap dapat berjalan di database temporal
Aljabar query yang baru untuk mengkontrol dimensi waktu mirip dengan aljabar database yang
lama
Solusi lain tentang Database Temporal:
Menambahkan waktu valid
Menambahkan waktu transaksi
Menambahkan kedua hal di atas
Pendekatan lainnya
Beberapa tipe bisnis yang dapat mendapat keuntungan lebih dengan bantuan database
temporal.
ata Warehouse
Data warehouse atau pergudangan data bukan merupakan bisnis per se (bukan bisnis itu
sendiri, tapi mengambil dari bisnis lain). Data warehouse ini merupakan usaha yang sangat
luas, yaitu bisnis yang diperuntukan menyimpan seluruh informasi dari beberapa perusahaan.
Data warehouse terbukti sangat berguna sebagai tempat penyimpanan informasi yang
dikumpulkan dengan tools data mining dan digunakan untuk sumber informasi. Seperti yang
sudah kita ketahui, elemen waktu sangat penting untuk berbagai bisnis, dan dalam sebuah data
warehouse dimensi waktu dapat disimpan dan digunakan dalam peng query an data. Sebenarnya
apa yang data warehouse lakukan dengan adanya database temporal? Menurut Ralph Kimball,
setiap data warehouse memiliki dimensi waktu yang membuat setiap data warehouse menfadi
database warehouse [Kimball 1997],[Snodgrass 1998].`Dimensi waktu adalah unik dan
merupakan dimensi yang kuat dalam setiap kumpulan data dan usaha data warehouse`[Kimball
1997].
aboratorium Ilmiah
Jenis bisnis yang kedua adalah lab ilmiah (scientific laboratory). Setiap lab tentu melakukan
banyak ufi coba dan banyak versi untuk percobaan yang sama, dan setiap percobaan sering kali
melibatkan urutan waktu yang sangat teliti. Agar informasinya tidak ada yang hilang, tentunya
harus disimpan dalam sebuah database. Karena elemen waktu di test ini felas tidak bisa
dihilangkan, sehingga informasi yang disimpan di sini harus disimpan dalam database temporal.
Satu keuntungan dalam menyimpan informasi uficoba ilmiah pada temporal database yang
mendukung bahasa query temporal adalah, sebuah pola baru dan pengetahuan baru dapat
digali dari basis data [Loomis 1997].
$ales dan Marketing
Kedua bisnis ini sangat berkantung pada temporal database, karena keberhasilan sales dan
marketing sangat bergantung pada waktu yang tepat. Waktu untuk pendekatan dengan
pelanggan dan kapan untuk mengiklankan di lokasi tertentu sangat diperlukan, dan kemampuan
untuk meramalkan informasi ini fauh lebih baik disediakan database temporal daripada
database klasik biasa.
Multimedia
Jenis bisnis yang terakhir adalah multimedia. Multimedia merupakan salah satu area bisnis
yang paling cepat berkembang saat ini, terutama melalui falus internet. Seseorang saat ini
dengan mudah menonton film dari internet, dimana gambar video tersebut sudah tersimpan di
database multimedia yang harus disinkronisasikan dengan data audio yang mungkin berada di
database yang sama atau berbeda. !engsinkronisasian ini, seperti kata tersebut sendiri, felas
melibatkan elemen waktu. 'Karen multimedia berbasis waktu, sinkronisasi sangat di butuhkan.
Jika diimplementasikan dengan baik, maka komponen-komponen media tersebut akan
ditampilkan dengan ketepatan dari sinkronisasi yang baik[David]`. 'Obfek-obfek multimedia
memiliki relasi dan ruang temporary yang harus difaga saat ditampilkan beberapa data memiliki
batasan waktu nyata (real time) saat menyampaian ke stasiun clien[O:su]`. Karena itu,
database untuk multimedia, seperti data warehouse, merupakan instance dari database temporal
fuga.

Keungulan Dan Kelemahan Database Berorientasi Object
October 20th, 2010
Judul Asli : Achievements and Weaknesses oI Object-Oriented Databases
Penulis : Sikha Bagul
Institusi : Department Computer Science, University oI West Florida, USA
Tahun : 2003
Source : Journal oI Object Technology
Database berorientasi obfect Obfect Oriented Databases (OODBs) muncul dipertengahan
tahun 80-an. Database berorientasi objeck muncul karena adanya pandangan bahwa database
relational Relational Databases (RDBs) sudah tidak mampu memenuhi kebutuhan terhadap
aplikasi yang kompleks yang dikembangkan dengan metode-metode berbasis obfect. !aper ini
dimaksudkan sebagai rangkuman kekuatan dan keunggulan sistem basis data berorientasi obfect.
!aper ini juga akan membicarakan kelemahan yang harus dipecahkan.
PENGANTAR OODBS
OODBs merupakan technology generasi kelima, OODBs memandang secara mendalam konsep-
konsep tentang obfek, class, inheritace serta overriding. Setiap kenyataan dalam dunia ini akan
direpresentasikan oleh OODM (Obfect Oriented Data Model) kedalam bentuk obfect.
Beberapa konsep OODBs :
1. Kenyataan dalam dunia ini direpresentasikan sebagai obfect
2. Setiap obfect memiliki state dan behavior
3. State merupakan nilai dari properties dan atribut dari obfect
4. ehavior merupakan method yang dijalankan oleh state
5. Obfect yang memiliki kesamaan state dan behavior dikelompokkan dalam satu class
yang sama
6. Setiap obfect hanya dapat diturunkan (instace) kedalam satu class saja
7. lass-class dikeompokkan dalam sebuah hierarki. Subclass memiliki turunan (inherits)
dari superclass-nya.
8. Dimungkinkan juga terjadi overriding dimana sebuah class men-substitute domain dari
propertiesnya dengan method lain dalam implementasi yang berbeda.
KEUNGGULAN OB1ECT-ORIENTED DATABASE MODEL (OODM)
OODBs memungkinkan user pengguna database untuk meminimalkan keys, foin dan dalam
kasus-kasus tertentu meningkat kan perIorma dari Database, dimana pada RBDs terjadi log-
duration transaction pada database.
Beberapa keunggulan OODBs
1) OODBS memungkinaan user untuk mendeIinisikan abstaksi data
OODB memberikan pandangan yang berbeda tentang bagaimana sebuah data disimpan dan
dikontrol dalam abstraksi data. User dimungkinkan membuat abstak data berupa class dengan
method dan atribut dari obfect
2) OODBs memberikan kemudahan dalam perancangan relationship
OODBs memiliki Iitur untuk perancangan relationship secara otomatis yang dikelola oleh
ObjectStore
3) OODBs meminimalkan penggunaan kunci-kunci
Keberadaan OID system-defined identifier yang dibuat oleh sistem dan tidak dapat
dimodiIikasi dilevel aplikasi membuat OODBs tidak begitu tergantung kepada key
4) OODBs mengurangi kebutuhan foin
Dengan adanya kelas-kelas database kebutuhan foin direduksi karena siIat dari obfect telah ada
pada masing-masing kelas
5) Peningkatan perIorma
OODBS menawarkan perIorma yang lebih baik dibandingkan dengan RDBs, dimana OODBs
dapat melakukan penyimpanan obfect kedalam memori yang sewaktu-waktu dapat dipanggil
kembali, tidak seperti RDBs yang hanya melakukan eksekusi apabila ada query terhadap
database.
6) Mendukung long-duration transaction
OODBs mampu memenuhi kebutuhan terhadap transaksi-transaksi yang terjadi secara terus
menerus dan membutuhkan waktu yang lama, hal ini yang tidak bisa dilakukan oleh RDBs
KELEMAHAN OB1ECT OREINTED DATABASE MODEL
1) Kompatibilitas OODBs Dengan RDBs
Perbedaan arsitektur, pendekatan dan data model membuat OODBs tidak kompatibel dengan
RDBs
2) Optimasi yang minim pada Query
OODBs memiliki permasalahan ayng komplek tentang bagaimana user dapat mendeIinisikan
berbagai tipe data baru, mengubah tipe data dan membuat obfect-obfect yang kompleks
3) Kurangnya dukungan terhadap aljabar query
Pada RDBs operasi aljabar merupakan dasar dari operasi pada database pada level sistem,
sedangkan di OODBs dilakukan dilevel obfect sehingga membutuhkan cara atau metode
tersendiri
4) kurangnya dukungan terhadap Iasilitas query
Pada RDBs sub query, grup by dan sebagainya merupakan bagian dari standart ANSI, akan
tetapi pada OODBs hal tersebut tidak masuk dalam Obfect Query.
5) OODBS tidak support view
View dalam RDBs merupakan bentuk dari mekanisme database, akan tetapi bagaimana view
dapat diimplementasikan dalam sebuah obfect, dimana obfect tidak mengenal identiIikasi dalam
view.
6) Isu keamanan pada OODBs
Tidak seperti RDBs, banyak OODBs tidak mengimplentasikan proses authorisasi. Jadi tidak ada
penggunaan grant dan revoke yang membatasi ruang lingkup user seperti halnya RDBs
7) Kurangnya dukungan terhadap konsistensi konstrain pada OODBs
OODBs belum memiliki konsistensi terhadap constraint dan belum mendukung dynamic schema
dari database
8) Terbatasnya kemampuan untuk melakukan tuning terhadap OODBs
OODBs memiliki keterbatasan kemampuan dalam memberikan parameter-parameter yang
digunakan untuk melakukan perbaikan dan optimasi, tidak seperti halnya RDBs yang
memberikan banyak parameter yang dapat digunakan administrator untuk menaikkan perIorma
database sesuai dengan kebutuhan yang diinginkan oleh masing-masing user
9) Kurangnya dukungan terhadap object yang sangat kompleks
Walaupun berlabel Obfect Oriented, ternyata OODBs belum mampu meng-handle kebutuhan
terhadap obfect-obfect yang kompleksitasnya tinggi
10) Terbatasnya dukungan terhadap integrasi dengan Object Oriented Programming yang sudah
ada
Pada kenyataanya implementasi OODBs dengan OOP sulit dilakukan kerena harus ada
perbedaan manajemen obfect antara OODBs dan OOP yang persistent
11) Terbatasnya perIorma yang ditawarkan oleh OODBs
PerIorma yang ditawarkan oleh OODBs ternyata masih jauh dibawah standart yang diharapkan,
berbagai persoalan terkait dengan manajemen penggunaan memori (karena long-duration
transaction) masihbanyak terjadi. Kompleksitas Obfect database juga turut berpengaruh terhadap
proses pengaksesan data dari aplikasi
12) Tidak ada dukungan terhadap beberapa Iitur Database
Banyak Iitur-Iitur database yang tidak dapat diimlementasikan kedalam OODBs seperti trigger,
meta data dan sebagainya
KESIMPULAN
Dengan melihat banyaknya masalah yang telah dibahas diatas, OODBs belum dapat memenuhi
ekspektasi sebagai sistem basis data yang handal. Diperlukan pengembangan dan perbaikan agar
Object-Oriented Database Model berkembang menjadi mature dan dapat dijadikan sebagai
standar proses penyimpanan data.

Kita telah mengenal konsep OO (Object-Oriented) pada mata kuliah Pemrograman Berorientasi
Objek (IF2032). Oleh karena itu, tentu kita tidak akan memperoleh kesulitan dalam mempelajari
Object Oriented Database. Konsep-konsep yang penting dalam OO antara lain :
1 e|as
kelas merupakan suaLu t|pe baru yang dldeflnlslkan oleh programmer engan kaLa laln kelas
adalah ceLakan ob[ek suaLu kelas blsa memlllkl banyak ob[ek eLlap kelas memlllkl aLrlbuL dan
meLhod
2 nkapsu|as|
Lnkapsulasl adalah pemlsahan aspekaspek eksLernal ob[ek yang dapaL dlakses darl rlnclan
rlnclan lmplemenLasl lnLernal Lnkapsulasl meredam keLerganLungan yang beglLu besar dengan
ob[ek kelas lalnnya
3 ewar|san
9ewarlsan aLau lobetltooce adalah proses penclpLaan kelas baru dengan mewarlsl karakLerlsLlk
kelas yang sudah ada dlLambah karakLerlsLlk unlk kelas yang baru lLu 9ewarlsan mendukung
penggunaan kemball (teosoblllty) suaLu kode
4 o||morf|sme
ecara haraflah 9ollmorflsme berarLl banyak benLuk alam konsep CC ob[ekob[ek dlkaLakan
pollmorflk blla mempunyal anLarmuka yang ldenLlk damun mempunyal perllaku yang berbeda
ConLoh mudahnya adalah dua buah ob[ek darl kelas yang berbeda dapaL memlllkl nama meLhod
yang sama namun algorlLma meLhodnya berbeda
Object Oriented Database adalah sebuah sistem database yang menggabungkan semua konsep
penting dari object oriented tersebut dengan beberapa Iitur tambahan antara lain :
1 unlque ob[ecL ldenLlflers
2 9erslsLenL ob[ecL handllng
Teknologi ini mengintegrasikan kemampuan basis data (DBMS) dengan kemampuan
pemrograman berorientesi objek (OOP). Sebuah Object Oriented Database Management System
(ODBMS) membuat objek sebuah basis data terlihat seperti objek pemrograman pada beberapa
bahasa pemrograman OOP. Sebuah ODBMS dapat memperluas kemampuan bahasa
pemrograman dengan kemampuan basis data seperti data yang persistent secara transparan,
kontrol konkurensi, recovery data, query asosiatiI dan berbagai kemampuan basis data yang lain.
OODB atau ODBMS dirancang untuk bekerja pada bahasa pemrograman berorientasi objek
seperti Java, C dan lain-lain. Bila kita ingin menyimpan objek pada program Java atau C ke
dalam sebuah sistem basis data, kita dapat menggunakan basis data yang berorientasi kepada
objek (ODBMS).
ODBMS sangat memudahkan programmer terutama yang terbiasa dengan OOP dalam mengolah
data dan variabel dalam programnya. Kebanyakan programmer basis data menghabiskan cukup
banyak waktu untuk merepresentasikan variabel atau objek pada programnya ke dalam struktur
basis data.
Letak perbedaan utama ODBMS dengan sistem basis data konvensional adalah pada sistem basis
data konvensional data direpresentasikan ke dalam bentuk tabel-tabel dengan kolom yang
mewakili kategori dari data, dan baris yang berisi data itu sendiri. Sedangkan dalam ODBMS,
data direpresentasikan sebagai sebuah objek, baik dalam hal pengaksesannya maupun dalam hal
pemodelannya.
S^` - KelebibSn dSn KelemSbSn UUDB
23 Juni 2009
OODB memang memiliki banyak keunggulan dibandingkan dengan RDB (Relational Database).
Namun dewasa ini, OODB masih belum dapat menggantikan posisi RDB. Biarpun OODB
memang teknologi baru yang sangat terkenal di kalangan ahli sistem basis data, namun para
pembuat aplikasi yang belum begitu mengenal teknologi OODB ini masih lebih memilih
menggunakan RDB yang sudah biasa mereka gunakan.
Para pembuat aplikasi harus menentukan akan memilih OODB atau RDB dalam proyek yang
akan mereka kerjakan. Sebab setiap permasalahan memerlukan penanganan yang berbeda-beda.
Bisa saja dalam suatu kasus, menggunakan OODB adalah pilihan yang terbaik, namun bisa juga
sebaliknya.
Kelebihan OODB
1 Desa|n yang |ndah
8anyaknya wakLu dan Lenaga yang Lerbuang dalam menanganl daLa memang men[adl masalah
yang umum dalam suaLu slsLem basls daLa alam CC8 masalah LersebuL dapaL dlmlnlmlsasl
dengan konsep berorlenLasl ob[ek yang dlmlllklnya sebab dengan konsep CC proses
penylmpanan dan pengambllan daLa akan men[adl leblh sederhana elaln mendapaLkan
perslsLensl daLa dengan CC8 klLa [uga mendapaLkan perslsLensl keseluruhan obyek daLabase
bahkan Lermasuk lmplemenLed behavlournya klLa [uga dapaL dengan mudah memanggll suaLu
meLhod darl ob[ek LerLenLu pada daLabase dl server sehlngga dlsLrlbusl apllkaslnya leblh mudah
2 enyederhanaan pembuatan ap||kas|
@anpa dlsadarl Lerkadang suaLu proyek dapaL melambung blayanya karena fakLor Leknls seperLl
penggunaan beberapa Lool bahasa program dan llngkungan darl apllkasl yang berbedabeda
8elum lagl blaya pelaLlhan dan lalnlaln engan CC8 klLa dapaL menyederhanakan pembuaLan
apllkasl dengan mengurangl penggunaan bahasa pemrograman dan Leknologl yang dlgunakan
9rogrammer cukup menguasal konsep CC dan bahasa pemrograman CC dengan sedlklL
Lambahan mengenal konekLlvlLas apllkasl dengan daLabase elaln lLu programmer Llnggal
memfokuskan pada perslsLensl ob[ek
3 |ner[a yang tangguh
engan 88 seorang programmer harus menghablskan wakLu dan Lenaga unLuk memeLakan
daLa dengan ob[ek menguralkan LabelLabel ke dalam ob[ek dan sebagalnya @erkadang hal lnl
mencapal seperLlga aLau bahkan separuh darl program lLu sendlrl Pal lnl LenLunya akan
menyebabkan klner[a men[adl lambaL karena harus memeLakan ob[ek LersebuL belum lagl blla
harus melaksanakan queryquery yang kompleks ,asalah LersebuL Lldak dl[umpal dalam CC8
karena dalam CC8 program mengakses daLa dengan ob[ek nya secara langsung sehlngga
klner[a program akan leblh Llnggl Leblh darl lLu pada beberapa produk C8, bahkan
dlmungklnkan adanya cllenL cachlng 8ayangkan kecepaLan yang dapaL dlhasllkan blla program
hanya perlu mengakses cache darl daLabase yang sudah ada dl cllenL
Kelemahan OODB
1 1|ght coup||ng
Coupllng berarLl keLerkalLan anLara apllkasl dan daLabase @lghL coupllng berarLl keLerkalLan
yang kuaL anLara apllkasl dan daLabase sehlngga apllkasl dan daLabase sullL dlplsahkan
ebenarnya LlghL coupllng dapaL menyederhanakan program dan desalnnya namun hal lnl [uga
dapaL menyebabkan hllangnya baLasan anLara apllkasl dan daLabase [uga akan menlmbulkan
masalah baru blla akan mlgrasl ke CC8 lalnnya aLau kemball ke 88
2 urangnya dukungan p|atform
9ada dasarnya CC8 dlLerapkan unLuk dapaL berlnLegrasl dengan semua bahasa pemrograman
berorlenLasl ob[ek namun sampal sekarang kebanyakan CC8, hanya mendukung bahasa
pemrograman C++ dan !ava sa[a
3 u||t berm|gras|
Cara penylmpanan dan pengambllan daLa dalam CC8 sangaL berbeda dengan 88 8eglLu [uga
dengan cara pengaksesannya Cleh karena lLu dlbuLuhkan komlLmen yang kuaL dalam memlllh
8, yang akan dlgunakan sekall bermlgrasl ke CC8 akan sullL unLuk kemball ke 88
4 ebutuhan ketramp||an
karena CC8 maslh Lergolong baru dan maslh relaLlf [arang penggunaannya cukup sullL
menemukan orang yang memlllkl pemahaman CC8 blla dlbandlngkan dengan orang yang
memlllkl pemahaman 88 elaln lLu unLuk memahaml CC8 dlperlukan pelaLlhan khusus
sebab LerdapaL banyak perbedaan pendekaLan dengan 88
3 ;uery yang komp|eks
kemampuan loglka yang mendalam sangaL dlperlukan dalam CC8 ,aslngmaslng CC8
dapaL memlllkl cara pemanggllan query yang berbedabeda elaln menggunakan ob[ecL lnya
sa[a pengaksesan suaLu daLa dapaL menggunakan range pola dan berbagal krlLerla laln yang
mungkln kellhaLan Lldak berhubungan
S^` - Ub|ec`RelS`ionSl DS`SbS_e
10 Juli 2009
Setelah melihat kelebihan dan kelemahan OODBMS dibandingkan dengan RDBMS, tentu saja
kita harus memikirkan matang-matang jenis DBMS apa yang akan kita gunakan. Namun ternyata
terdapat DBMS lainnya yang merupakan gabungan atau dapat dikatakan sebagai jembatan yang
menghubungkan OODBMS dan RDBMS.
ORDBMS (Object-Relational Database Management System) merupakan DBMS yang mirip
dengan RDBMS, tapi model object-oriented seperti objek, kelas, dan pewarisan sudah didukung
langsung dalam skema basis data dan bahasa query-nya. Selain itu, dia juga mendukung adanya
tipe data buatan dan method.
Salah satu tujuan ORDBMS adalah menjembatani celah antara teknik pemodelan data
konseptual seperti Entity-relationship diagram (ERD) and object-relational mapping (ORM),
yang sering menggunakan kelas, pewarisan, dan basis data relasional, yang tidak langsung
didukungnya. Selain itu, tujuan lain ORDMBS ini adalah menjadi penghubung antara teknik
pemodelan berorientasi objek yang digunakan di bahasa pemrograman berorientasi objek seperti
Java, C, atau C#.
Bila produk RDBMS tradisional berIokus pada manajemen pengambilan data yang eIisien dari
himpunan tipe data yang terbatas, ORDBMS memungkinkan software developer untuk
mengintegrasikan tipe objek buatannya sendiri beserta method yang sesuai ke dalam DBMS.
Banyak SQL ORDBMS yang beredar di pasaran sekarang yang telah didukung dengan user
defined types (UDT) atau tipe buatan dan Iunction. Sebagian ORDBMS (misalnya MicrosoIt
SQL Server) memungkinkan Iunction untuk ditulis dalam bahasa pemrograman berorientasi
objek, tapi ini saja tidak membuatnya menjadi OODB, dalam OODB orientasi objek adalah Iitur
dari model data.
Perbandingan dengan RDBMS
RDBMS pada umumnya akan memiliki pernyataan SQL seperti ini :
CREATE TABLE Customers (
Id CHAR(12) NOT NULL PRIMARY KEY,
Surname VARCHAR(32) NOT NULL,
FirstName VARCHAR(32) NOT NULL,
DJB DATE NOT NULL
);
SELECT InitCap(Surname) || ', ' || InitCap(FirstName)
FROM Customers
WHERE Month(DJB) = Month(getdate())
AND Day(DJB) = Day(getdate())
Dapat juga dibuat menjadi Iunction seperti di bawah ini :
SELECT Formal(Id)
FROM Customers
WHERE Birthday(Id) = Today()
Dalam ORDBMS kita dapat membuat tipe bentukan dan ekspresi seperti BirthDay() :
CREATE TABLE Customers (
Id Cust_Id NOT NULL PRIMARY KEY,
Name PersonName NOT NULL,
DJB DATE NOT NULL
);
SELECT Formal(C.Id)
FROM Customers C
WHERE BirthDay (C.DJB) = TJDAY;
S^` - BSbS_S Que^ UUDB
21 Juli 2009
Bahasa query dalam OODB merupakan pengembangan dari bahasa query SQL yang sudah kita
kenal dalam RDB. Yang membedakannya adalah kita dapat membuat ADT atau tipe baru selain
tipe-tipe primitiI yang sudah ada seperti INTEGER dan VARCHAR.
Misalnya kita ingin membuat tipe baru yaitu MAHASISWA :
CREATE TYPE mahasiswa (
Nama CHAR(20),
NIM INTEGER,
Usia INTEGER,
Alamat alamat
)
Nama, NIM, dan Alamat merupakan properti atau atribut dari kelas Mahasiswa.
Dalam hal ini, alamat merupakan tipe bentukan lainnya seperti di bawah ini :
CREATE TYPE alamat (
Negara CHAR(20),
Propinsi CHAR(20),
Kota CHAR(20),
KodePos INTEGER,
Jalan CHAR(50)
)
Untuk retrieve nama dan NIM mahasiswa yang tinggal di Bandung, kita gunakan syntax seperti
ini :
SELECT Nama(m), NIM(m)
FOR EACH mahasiswa m
WHERE Kota(Alamat(m)) = 'Bandung'
NB : contoh-contoh di atas menggunakan bahasa query IRIS, salah satu OODBMS yang ada.
S^` - Ke_impulSn
5 Agustus 2009
Setelah melakukan eksplorasi selama kurang lebih 8 minggu mengenai topik Object Oriented
Database, dapat kita tarik beberapa kesimpulan akhir yaitu :
1 CC8 adalah salah saLu [enls 8, yang menggunakan konsep ob[ecL orlenLed yang LerdapaL
pada CC9
2 lbandlngkan dengan 88 CC8 leblh menyerupal kondlsl dunla nyaLa
3 alam CC8 proses pengambllan dan penylmpanan daLa akan leblh mudah karena seLlap daLa
memlllkl ob[ecLl maslngmaslng
4 CC8 maslh belum blsa mengganLlkan kedudukan 88 karena maslh Lergolong baru sehlngga
Lldak banyak yang menguasalnya
3 @erdapaL C88, yang merupakan komblnasl anLara CC8 dan 88
6 alam CC8 klLa dapaL membuaL Llpe benLukan baru yang berupa kelas dalam konsep ob[ecL
orlenLed
Dengan demikian berakhirlah tugas eksplorasi dengan topik Object Oriented Database, semoga
tugas eksplorasi ini dapat bermanIaat bagi yang membacanya. Mohon maaI apabila dalam
eksplorasi ini terdapat hal-hal yang kurang berkenan. Terima kasih kepada semua pihak yang
telah mendukung saya dan kepada semua reIerensi dalam pengerjaan tugas ini. Saya berharap
dengan berakhirnya tugas ini, saya dapat memulai tugas baru saya sebagai asisten lab. Basis
Data. Sampai Jumpa ``

PENDAHULUAN
Beberapa tahun lalu sebuah konsep sistem basis data baru muncul dan menjadi perhatian dunia
IT. Teknologi ini disebut Object-Oriented Database (OODB). Disebut sebut bahwa teknologi ini
sangat cocok dengan era internet saat ini.
Teknologi ini mengintegrasikan kemampuan basis data (DBMS) dengan kemampuan
pemrograman berorientesi kepada obyek (OOP). Sebuah Object Oriented Database Management
System (ODBMS) membuat obyek sebuah basis data terlihat seperti obyek pemrograman pada
beberapa bahasa pemrograman OOP. Sebuah ODBMS dapat memperluas kemampuan bahasa
pemrograman dengan kemampuan basis data seperti data yang persistent secara transparan,
kontrol konkurensi, recovery data, query asosiatiI dan berbagai kemampuan basis data yang lain.
OODB atau ODBMS dirancang untuk bekerja pada bahasa pemrograman OOP seperti java,
C dan lain lain. Bila kita ingin menyimpan obyek pada program Java atau C ke dalam
sebuah sistem basis data, kita dapat menggunakan basis data yang berorientasi kepada obyek
(ODBMS).
ODBMS sangat memudahkan pemrogram terutama yang terbiasa dengan OOP dalam
mengolah data dan variabel dalam programnya. Kebanyakan pemrogram basis data
menghabiskan cukup banyak waktu untuk merepresentasikan variabel atau obyek
Pada programnya ke dalam struktur basis data. Pada saat membuat penulisan ini penulis teringat
satu kasus yang penulis alami sendiri pada suatu proyek, yaitu penulis merasa seandainya hasil
query yang penulis dapatkan dapat direpresentasikan ke dalam sebuah obyek, maka
permasalahan yang penulis hadapi saat itu akan mudah teratasi. Sayangnya pada saat itu penulis
belum mengenal ODBMS ini.
Letak perbedaan utama ODBMS dengan sistem basis data konvensional adalah pada sistem
basis data konvensional data direpresentasikan ke dalam bentuk tabel-tabel dengan kolom yang
mewakili kategori dari data, dan baris yang berisi data itu sendiri. Sedangkan dalam ODBMS,
data direpresentasikan sebagai sebuah obyek, baik dalam hal pengaksesannya maupun dalam hal
pemodelannya.
PERKEMBANGAN ODBMS
Pada saat diperkenalkan beberapa tahun lalu, ODBMS diberkirakan akan segera menjadi
teknologi utama di bidang basis data menggantikan Sistem Basis Data Relasional (RDBMS).
Utamanya karena RDBMS tidak dirancang untuk menangani tipe data multimedia yang banyak
digunakan di internet.
Kenyataan pada saat ini ramalan tersebut tidak mengenai sasaran. Saat ini terbukti RDBMS
masih jauh lebih banyak dipergunakan. ODBMS hanya mendapatkan sebagain
kecil dari pasaran. Penjualan RDBMS mencapai 50 kali lipat penjualan ODBMS. Di sisi lain
pembuat RDBMS menambahkan kemampuan penggunaan obyek ke dalam sistem buatannya
menjadi oject-relational database management system (ORDBMS).
BERBAGAI PENDAPAT TENTANG ODBMS
Banyak pihak yang meragukan perkembangan ODBMS diantaranya tersurat pada pendapat yang
dikemukakan oleh Michael Stonebraker, CTO dari InIormix yang mengeluarkan produk
ORDBMS menyatakan bahwa ODBMS hanya memiliki pangsa pasar kecil yang tidak memiliki
masa depan yang luas dan ORDBMS akan menggeser posisi ODBMS dalam waktu hanya lima
tahun saja.
Akan tetapi di lain pihak optimisme akan ODBMS tetap besar, diantaranya mengutip pendapat
Rick Cattell dari Sun Mycrosystems yaitu perkembangan ODBMS masih cukup baik, walaupun
skala penjualannya tidak besar, akan tetapi ODBMS akan tetap dipergunakan terutama pada
bidang CAD (computer-aided design) dan telekomunikasi yang tidak cocok untuk menggunakan
RDBMS.
OODB sangat banyak digunakan dalam bidang CAD/CAM dan Intelegensia Buatan (AI) karena
OODB mendukung tipe data yang kompleks dan relasi yang sulit. Juga OODB secara eIisien
mendukung tipe data multimedia yang banyak digunakan dalam aplikasi CAD/CAM
Pada kesempatan lain Cattell dari Sun Microsystems menyatakan bahwa OODB juga digunakan
pada sistem pendataan pasien rumah sakit karena bagi staI rumah sakit OODB lebih mudah
dipergunakan daripada basis data relasional.
Akmal Chaudhri, seorang ahli sistem basis data dan doktor di The City University, London
menyatakan bahwa beberapa perusahaan besar di London diantaranya J.P. Morgan, Chase
Manhattan dan Citibank menggunakan teknologi ODBMS untuk pemodelan instrumen keuangan
seperti obligasi. Hal ini disebabkan teknologi ini membantu mengolah instrumen yang
dibutuhkan dalam pemodelan secara eIektiI.
Teknologi berorientasi-obyek juga mendukung mekanisme penurunan (inheritance) untuk
pemodelan instrumen berikutnya dengan cepat dan mudah.
Juga menurut Akmal Chaudhri, jika kita ingin memodelkan sebuah Boeing 747 dengan
ODBMS, maka hubungan antara komponen pesawat dikelola langsung oleh sistem basis data.
Sedangkan jika kita menggunakan RDBMS, kita harus membagi-bagi pesawat tersebut ke dalam
tabel-tabel dan menghubungkan lagi tabel-tabel tersebut bila kita ingin membangun kembali
pesawat tersebut.
KELEBIHAN DAN KEKURANGAN ODBMS
Walaupun OODB memiliki banyak keunggulan daripada RDB, OODB belum mampu
menggoyahkan kedudukan RDB. OODB merupakan teknologi baru yang populer di kalangan
ahli sistem basis data, tetapi pembuat aplikasi masih lebih memilih RDB daripada OODB.
Hal ini mungkin disebabkan para pembuat aplikasi tersebut belum mengenal lebih jauh OODB
atau ODBMS. Untuk memilih mana yang lebih cocok OODB atau RDB untuk proyek yang
kita kerjakan, ada baiknya kita perhitungkan Iaktor resiko, kebutuhan
teknis, kinerja yang diharapkan dan keseluruhan solusi teknis. Pada keadaan tertentu OODB
merupakan suatu pilihan tepat, tapi pada keadaan yang salah pilihan ini dapat
berakibat besar.
Berikut ini beberapa kelebihan dan kelemahan OODB.
1. KELEBIHAN OODB
A. DESAIN YANG INDAH
Pada suatu sistem yang dinamis pemrogram sering harus menghabiskan banyak waktu dan
tenaga untuk menagani masalah data. Dengan OODB, masalah ini tidak hilang, tetapi dapat
dikurangi. Karena dengan orientasi obyek maka proses penyimpanan dan pengambilan data jauh
lebih sederhana.
Dengan OOP, program dan data terintegrasi dengan baik. Dengan paradigma orientasi obyek
dapat menyederhanakan aplication modelling, kebutuhan design tool dan visualisasi sisten dan
desainnya. Dengan OODB tidak hanya kita mendapatkan persistensi data tapi keseluruhan obyek
database, bahkan termasuk implemented behaviour-nya. Juga kita dapat memanggil suatu
method dari obyek tertentu pada database di server sehingga distribusi aplikasinya lebih mudah.
Dalam RDB untuk melaksanakan hal ini kita harus memasukkan stored procedure atau suatu
komponen obyek. Sehingga arsitektur dari aplikasi jadi lebih rumit dan membutuhkan keahlian
pemrograman lebih lanjut.
B. PENYEDERHANAAN PEMBUATAN APLIKASI
Dengan OODB kita dapat menyederhanakan pembuatan aplikasi dengan meminimalisasi
penggunaan bahasa pemrograman dan implementasi teknologi yang dibutuhkan. Terkadang kita
tidak menyadari bahwa suatu proyek menjadi lebih tinggi biayanya karena banyak Iaktor teknis
seperti penggunaan beberapa tool, bahasa program dan lingkungan dari aplikasi yang berbeda-
beda. Belum lagi biaya pelatihan dan lain-lain.
Dengan OODB maka kemampuan teknis yang dibutuhkan menjadi berkurang karena pemrogram
cukup menguasai konsep orientasi obyek (object oriented) dengan sedikit tambahan mengenai
koneksi ke database. Tentunya pemrogram harus juga menguasai bahasa pemrograman
berorientasi obyek seperti C atau Java.
Selain itu pemrogram tinggal memIokuskan pada persistensi obyek. Pemrogram tidak perlu lagi
meguraikan obyek ke tabel, memikirkan relasi antar tabel, dan sebaliknya.
C. KINER1A YANG TANGGUH
Pada produk ODBMS yang tepat dan sesuai dengan aplikasi yang dibuat, OODB dapat
meningkatkan kinerja aplikasi dengan peningkatan yang tinggi.
Seperti yang beberapa kali penulis sebutkan, dengan RDB seorang pemrogram harus
menghabiskan waktu untuk memetakan data dengan obyek, menguraikan tabel-tabel ke dalam
obyek dan sebagainya. Terkadang hal ini mencapai sepertiga atau bahkan separuh dari program
itu sendiri. Hal ini menyebabkan juga kinerja program lebih lambat karena harus melaksanakan
pemetaan obyek tersebut. Belum lagi program harus melaksanakan beberapa query yang makin
memperlambat kinerja program tersebut.
Dengan OODB tentu kinerja program dapat lebih baik karena hal-hal di atas tidak lagi
diperlukan. Karena program langsung mengakses data dengan obyeknya.
Pada beberapa produk ODBMS bahkan dimungkinkan adanya client caching. Bayangkan
kecepatan yang dapat dihasilkan bila program hanya perlu mengakses chache dari database yang
sudah ada di client.
KELEMAHAN OODB
1. TIGHT COUPLING
Istilah tight coupling maksudnya antara aplikasi dengan data sedemikian rupa terikat hingga
sulit dipisahkan satu dengan lainnya. Misalnya sistem database MicrosoIt Access dengan bahasa
pemrograman MS-Visual Basic mempunyai hubungan loose couple karena kita dapat
menggunakan banyak pilihan sistem basis data untuk program dalam MS-Visual Basic dan juga
dapat menggunakan banyak pilihan bahasa pemrograman lainnya untuk mengakses data dalam
MS-Access. Sementara bahasa COBOL dengan databasenya sangat tight couple karena sulit
mengakses database COBOL dengan bahasa pemrograman lain.
Sementara tight coupling mempunyai keuntungan karena menyederhanakan program dan
desainnya, akan tetapi hal ini memiliki kekurangan karena ini menghilangkan hijab* antara
database dengan aplikasi. Juga menyebabkan suatu kendala baru bila kita ingin bermigrasi ke
produk ODBMS yang berbeda atau kembali ke RDB.
hijab* batas/pemisah.
2. KINER1A YANG MUNGKIN KURANG BAIK
Sebelumnya penulis telah memaparkan bagaimana keperkasaan kinerja OODB terutama dalam
hal mengakses data. Tetapi di sini penulis perlu juga menyampaikan bahwa pada kondisi tertentu
mungkin saja OODB menghasilkan kinerja yang buruk. Misalnya pelaksanaan ad-hoc query
yang sangat lemah dalam OODB. Memang dalam beberapa hal produk ODBMS masih kalah
dengan produk RDBMS yang telah lebih lama beredar di pasaran. Diantaranya masalah-masalah
Iungsionalisasi dan
optimalisasi query ini. Wajar saja mengingat usia OODB yang relatiI muda.
3. KURANGNYA DUKUNGAN PLATFORM
Pada dasarnya OODB dapat diterapkan pada bahasa pemrograman orientasi obyek apa saja, tapi
produk ODBMS yang ada masih kebanyakan diorientasikan untuk digunakan dalam bahasa Java
dan C. Disamping itu juga belum banyak tersedia komponen untuk pengaksesan OODB
untuuk bahasa pemrograman lainnya.
Walaupun OODB dapat diimplementasikan dalam Java yang platIorm independent, belum tentu
pada platIorm yang kita miliki mendukung implementasi Java. Selain itu Java juga memiliki
aneka nuansa dan keanehan-keanehan bila diterapkan pada lingkungan yang berbeda.
4. SULIT BERMIGRASI
Cara penyimpanan dan pengambilan data pada OODB sangat berbeda dengan RDB. Demikian
juga cara pengaksesannnya. Oleh karena itu, bila kita bermigrasi ke OODB maka kita harus
berkomitmen untuk terus menggunakan OODB. Setelah mengimplementasikan OODB, sangat
sulit untuk kembali ke RDB.
5. KEBUTUHAN KETERAMPILAN
Mencari seseorang yang memiliki kemampuan spesiIik pada salah satu ODBMS jauh lebih sulit
daripada mencari seseorang yang memiliki pemahaman RDB dan penguasaan salah satu
database seperti MS-Access, MS-SQL server, Oracle dan lainlain. Lebih sulit lagi mencari
seorang yang benar-benar menguasai administrasi sistem OODB.
Peralihan dari paradigma RDB ke OODB juga membutuhkan pelatihan khusus karena
banyaknya perbedaan pendekatan diantaranya perIorma, locking, join dan lain lain.
6. QUERY YANG KOMPLEKS
Pada masing-masing ODBMS terkadang memiliki cara query yang berbeda. Selain itu terkadang
kita tidak mengakses data dengan cara memanggil ObjectID-nya saja, tetapi kadang berdasarkan
range, pola dan beragam kriteria lain yang mungkin kelihatannya tidak berhubungan. Ini
berakibat penggunaan OODB membutuhkan kemampuan logika yang mendalam.
OODB memang sebuah teknologi yang mengagumkan dan menyuguhkan berbagai kemampuan
yang telah lama diidam-idamkan. Tapi sayangnya masing-masing produk OODB atau ODBMS
memiliki kelebihan dan kekurangan yang berbeda-beda. Kita harus hati-hati mengevaluasi suatu
produk ODBMS untuk kebutuhan kita.

keleblhan dan kekuranagn aLabase relaslonal
@8L 8LLlCnL

9engerLlanaLabase 8elaslonal

-8asls aLa relaslonal menggunakan Lable dua dlmensl yang Lerdlrl aLas barls dan kolom unLuk memberl
gambaran sebuah berkas daLa

keunLungan aLabase 8elaslonal

1 8enLuknya sederhana

2 ,udah melakukan berbagal

Cperasl daLa

lsLllahalamaLabase
8elaslonal

1 8elasl

2 LrlbuL

3 @upel

4 omaln

3 era[aL(degree)

6 CardlnallLy

8elaLlonal key

-uper key
-CandldaLe key
-9rlmary key
-lLernaLe key
-lorelgn key

key
dalah se[umlah aLrlbuL yang mengldenLlflkasl record/barls dalam sebuah relaLlon secara unlque
8eberapa [enls key
o uper key saLu aLrlbuL aLau kumpulan aLrlbuL yang secara unlk mengldenLlflkasl sebuah record dl
dalam relasl aLau hlmpunan darl saLu aLau leblh enLlLas yang dapaL dlgunakan unLuk mengldenLlflkasl
secara unlk sebuah enLlLas dalam enLlLas seL
o CandldaLe key aLrlbuLaLrlbuL yang men[adl deLermlnan yang dapaL dl[adlkan ldenLlLas record
pada sebuah relaLlon blas LerdapaL saLu aLau leblh candldaLe key
o 9rlmary key candldaLe key yang men[adl ldenLlLas record karena dapaL mengldenLlflkasl record
secara unlk
o lLenaLe key candldaLe key yang Lldak dl[adlkan prlmary key
o ComposlLe key key yang Lerdlrl darl 2 aLrlbuL aLau leblh
LrlbuLaLrlbuL LersebuL blla berdlrl sendlrl Lldak men[adl ldenLlLas record LeLapl blla dlrangkalkan
men[adl saLu kesaLuan akan dapaL mengldenLlflkasl secara unlk
o lorelgn key non key aLrlbuL pada sebuah relaLlon yang [uga men[adl key (prlmary) aLrlbuL dl
relaLlon lalnnya lorelgn key blasanya dlgunakan sebagal penghubung anLara recordrecord dan kedua
relaLlon LersebuL

LnLlLy/LnLlLas
dalah obyek dl dunla nyaLa yang dapaL dlbedakan darl obyek laln
LnLlLy eL/kumpulan LnLlLy adalah kumpulan darl enLlLas se[enls/dalam Llpe sama
LnLlLy seL dapaL berupa
o Cbyek flslk rumah kendaraan pegawal
o Cbyek absLrak konsep pollLlk peker[aan rencana dll
lmbol yang dlgunakan unLuk enLlLy adalah persegl pan[ang

* @lpe enLlLas
o LnLlLas kuaL yalLu enLlLas mandlrl yang keberadaannya Lldak berganLung pada keberadaan enLlLas laln
o LnLlLas Lemah/Weak LnLlLy yalLu enLlLas yang keberadaannya berganLung pada keberadaan enLlLas
laln
o LnLlLas ssoslaLlf adalah enLlLas yang LerbenLuk darl suaLu relasl blsa Ler[adl [lka
8elasl yang merekaLkan dua enLlLas berslfaL banyak ke banyak
8lasanya berasal darl suaLu relasl dlmana relasl lLu memlllkl
makna mandlrl bagl pengguna
8elaLlonshlp
* dalah hubungan anLara suaLu hlmpunan enLlLas dengan hlmpunan enLlLas lalnnya
* lmbol yang dlgunakan adalah benLuk belah keLupaL dlamod aLau recLangle
* ConLoh
* era[aL 8elaLlonshlp
o ,en[elaskan [umlah enLlLy yang LerllbaL dalam suaLu relaLlonshlp
unary egree (era[aL saLu) hanya saLu enLlLy yang LerllbaL
8lnary egree (era[aL dua) menghubungkan dua enLlLy

@ernary egree (era[aL Llga) menghubungkan Llga enLlLy
* CardlnallLy 8aLlo ConsLralnL
o ,en[elaskan baLasan [umlah relasl suaLu enLlLy dengan enLlLy lalnnya
o !enls raslo kardlnallLas
Cne Lo one (11)
Cne Lo many/many Lo one (1 , / ,1)
,any Lo many (, n)
o 8aLasan kardlnallLas
kardlnallLas ,lnlmum dalah [umlah mlnlmum lnsLanslasl relasl 8 yang berasoslasl dengan seLlap
lnsLanslasl enLlLas

kardlnallLas ,akslmum dalah [umlah makslmum lnsLanslasl relasl 8 yang berasoslasl dengan seLlap
lnsLanslasl enLlLas
* 9arLlclpaLlon ConsLralnL
o ,en[elaskan apakah keberadaan suaLu enLlLy LerganLung pada hubungannya dengan enLlLy laln
@oLal parLlclpaLlon yalLu keberadaan suaLu enLlLy LerganLung pada hubungannya dengan enLlLy laln l
dalam dlagram L8 dlgambarkan dengan dua garls penghubung anLara enLlLy dengan relaLlonshlp
9arLlal parLlclpaLlons yalLu keberadaan suaLu enLlLy Lldak LerganLung pada hubungan dengan enLlLy
laln l dalam dlagram L8 dlgambarkan dengan saLu garls penghubung anLara enLlLy dengan relaLlonshlp

LrlbuL
dalah properLy deskrlpLlf yang dlmlllkl oleh seLlap hlmpunan enLlLas
* !enls[enls aLrlbuL
o LrlbuL key dlgunakan unLuk mengldenLlflkasl suaLu enLlLy secara unlk
o LrlbuL Lunggal memlllkl nllal Lunggal
o LrlbuL mulLlvalue memlllkl sekelompok nllal unLuk seLlap lnsLanL enLlLy
o LrlbuL composlLe dapaL dldekomposlsl men[adl beberapa aLrlbuL laln
o LrlbuL derlvaLlve dlhasllkan darl aLrlbuL yang laln

Langkahlangkah membuaL L8 lagram
1) @enLukan enLlLyenLlLy yang dlperlukan
2) @enLukan relaLlonshlp anLar enLlLyenLlLy
3) @enLukan cardlnallLy raLlo dan parLlclpaLlon consLralnL
4) @enLukan aLrlbuLaLrlbuL yang dlperlukan darl Llap enLlLy
3) @enLukan key dl anLara aLrlbuLaLrlbuL
6) Plndarl penamaan enLlLy relaLlonshlp dan aLrlbuL yang sama
ConLoh L8 lagram
@ransformasl L8 lagram ke aLabase 8elaLlonal
1 LrlbuL Lunggal/ LrlbuL blasa
2 LrlbuL ComposlL Pasll 9emeLaan
3 LrlbuL ,ulLlvalue Pasll 9emeLaan
4 9emeLaan Pubungan saLu ke banyak Pasll 9emeLaan
3 9emeLaan Pubungan banyak ke banyak Pasll 9emeLaan

PEMODELAN DATA
Model data merupakan kumpulan tools yang secara konseptual untuk mendeskripsikan data,
hubungan data, semantic data, dan konsistensi konstrain atau suatu cara untuk menjelaskan
bagaimana pemakai dapat melihat data secara logik.
E Model basis data Flat-Iile
E Model basis data Hirarki
E Model basis data Jaringan
E Model basis data Relasional
E Model basis data Berorientasi Objek (Object Oriented (OO))
E Model basis data Relasional Objek (Object Relational (OR))
3.1 Model basis data Flat-Iile
Model Ilat-Iile (Iile datar), di mana semua record disimpan dalam bentuk sebuah Iile
biasa/Iormat Iile text. InIormasi pada suatu Iile-Iile disimpan sebagai Iields, dengan Iields-nya
memiliki panjang konstan atau bervariasi yang dipisahkan beberapa karakter/delimeter. Pada
model ini, tidak ada hubungan (relationship) yang bisa dideIinisikan atau dibuat diantara Iields
tersebut. Dengan tidak adanya hubungan antar Iields, maka Iields tersebut hanya bisa diakses
dengan cara berurutan (sekuansial). Sebagai contoh, jika ingin menemukan suatu Iields
pelanggan ke-50, maka akan dilakukan pencarian dari Iield pertama sampai ke Iield 49 secara
berurutan.
Untuk basis data Ilat-Iile dengan panjang Iields-nya konstan diberikan pada contoh 3.1. Pada
contoh 3.1. terdapat 3 Iields : identiIikasi angka, nama dosen, dan nama program studi. Setiap
Iields memiliki panjang konstan karena Iield identiIikasi angka selalu dimulai pada kolom #1
dan selalu berakhir pada kolom #4, Iield nama dosen selalu dimulai pada kolom #6 dan selalu
berakhir pada kolom #25, dan seterusnya.
Untuk contoh basis data Ilat-Iile dengan panjang Iields bervariasi yang dipisahkan dengan
delimeter diberikan pada contoh 3.2.
Contoh 3.1.
1234 5 67890123456789012345 6 78901234567890123
0123 Aris Puji Widodo PS. Ilmu Komputer
1234 Djalal ER Riyanto PS. Ilmu Komputer
2345 Kushartantya PS. Ilmu Komputer
3456 Suhartono PS. Ilmu Komputer
4567 Bambang Yismianto PS. Ilmu Komputer
5678 Indriyati PS. Ilmu Komputer
6789 Beta Noranita PS. Ilmu Komputer
7890 Eko Adi Sarwoko PS. Ilmu Komputer
Contoh 3.2.
0123:Aris Puji Widodo:PS.Ilmu Komputer
1234:Djalal ER Riyanto:PS.Ilmu Komputer
2345:Kushartantya:PS.Ilmu Komputer
3456:Suhartono:PS.Ilmu Komputer
4567:Bambang Yismianto:PS.Ilmu Komputer
5678:Indriyati:PS.Ilmu Komputer
6789:Beta Noranita:PS.Ilmu Komputer
7890:Eko Adi Sarwoko:PS.Ilmu Komputer
Pada contoh 3.2. terdapat 3 Iields, untuk setiap Iields dipisahkan dengan titik dua. Setiap Iields
memiliki panjang tidak konstan. Pada saat menggunakan Iields separator, seharusnya Iields
seperatornya bukan merupakan karakter yang terdapat pada data.
Kelemahan basis data Ilat-Iile:
E Flat-Iile tidak menggunakan struktur data yang dengan mudah dapat direlasikan
E Sulit untuk mengatur data secara eIisien dan menjamin akurasi
E Lokasi Iisik Iields data dengan Iile harus diketahui
E Program harus dikembangkan untuk mengatur data
E Harus sesuai dengan kondisi di mana semua Iields akan diproses secara keseluruhan.
3.2 Model basis data Hirarki
Model basis data hirarki dirancang dengan hubungan yang terstruktur sehingga memungkinkan
dan mempermudah akses terhadap suatu data, memiliki kemampuan untuk menemukan dan
memelihara relasi antar kelompok data. Hubungan yang terjadi dalam model hirarki ini adalah
parent-child dan one-to-many. Setiap tabel parent bisa mempunyai beberapa child tabel, namun
setiap child tabel hanya mempunyai satu parent tabel.
Struktur model basis data hirarki terlihat seperti kebalikan dari struktur pohon seperti yang
diberikan pada gambar 3.1.
Gambar 3.1. Model Basis Data Hirarki
Pada gambar 3.1 Publishers adalah sebagai root table. Publisher memiliki dua child table :
Author dan BookStores. Publisher mempunyai beberapa orang Author yang dikontrak, dan
mempunyai beberapa BookStores untuk mensuplai kebutuhan buku-buku. Titles adalah child
dari Author, Inventory dan Orders adalah child dari BookStrores. Salah satu masalah yang
muncul adalah terjadinya redudansi inIormasi Titles yang disimpan pada tabel Inventory, karena
tidak ada hubungan langsung antara Authors dan BookStores.
Root table dapat memiliki lebih dari satu child table dan child table hanya boleh memiliki satu
root table. Untuk mengakses child table, harus dilakukan pengaksesan root table terlebih dahulu.
Relasi-relasi tabel dengan struktur hirarki dihubungkan dengan pointer.
Kelebihan basis data hirarki dibandingkan Ilat-Iile:
E Struktur data permanen dan secara eksplisit terhubung antara satu sama lainnya
E Data dapat dengan cepat dilakukan retrieve
E Integritas data mudah dilakukan pengaturan
Kelemahan basis data hirarki dibandingkan Ilat-Iile:
E Penambahan child tabel tidak dapat dilakukan jika tidak terhubung dengan parent tabel
E Pengguna harus sangat Iamiliar dengan struktur basis data
E Terjadi redudansi data
3.3 Model basis data jaringan
Model basis data jaringan menerapkan hubungan data yang merupakan perbaikan dari model
hirarki, tabel-tabel terhubung dalam sebuah himpunan, di mana suatu tabel owner akan
dihubungkan dengan beberapa tabel member. Relasi antar tabel dalam basis data jaringan disebut
set structure. Menerapkan konsep dasar relasi parent/child, se structure dapat dipresentasikan
sebagai relasi one-0to-many antar tabel. Memiliki kemampuan root tabel untuk melakukan share
relationships dengan child table. Program aplikasi dapat mengakses basis data jaringan
menggunakan set structure sebagai navigasi ke bagian basis data yang berbeda. Sehingga jika set
structure dilakukan modiIikasi, maka program aplikasi yang mengakses basis data juga harus
dilakukan modiIikasi. Untuk set structure dapat dilihat pada gambar 3.2.
Gambar 3.2. Model Basis Data Jaringan
Pada gambar 3.2. tabel Publishers memiliki 2 tabel : Authors dan BookStores. Authors dan
BookStores adalah sebagai member dari tabel Publishers. Publishers meng-contract Authors
untuk bekerja, dan Publishers akan men-supply buku-buku yang selesai dikerjakan ke
BookStores.
Gambar 3.3. Child Table yang Dilakukan Share
Pada gambar 3.3. memberikan deskripsi child table atau members dapat dilakukan share oleh
parent table. Tabel Titles dimiliki oleh Authors dan BookStores, karena Authors dan BookStores
membutuhkan relasi dengan Titles. Walaupun 2 set structure dapat digunakan untuk mengakses
tabel Titles, inIormasi book title hanya disimpan pada satu tabel, sehingga redudansi data
direduksi.
Kelebihan basis data jaringan:
E Data lebih cepat diakses
E User dapat mengakses data dimulai dari beberapa tabel
E Mudah untuk memodelkan basis data yang komplek
E Mudah untuk membentuk query (perintah-perintah untuk mengakses data) yang komplek
dalam melakukan retrieve data.
Kelemahan basis data jaringan:
E Struktur basis datanya tidak mudah untuk dilakukan modiIikasi
E Perubahan struktur basis data yang telah dideIinisikan akan mempengaruhi program aplikasi
yang mengakses basis data
E User harus memahami struktur basis data.
3.4 Model basis data relasional
Model basis data relasional merupakan model basis data yang paling populer banyak digunakan
sekarang ini. Beberapa perbaikan ditambahkan pada model ini, yaitu sederhana dalam mengatur
data, retrieve data, dan change data. Pada model ini , data disimpan dalam sebuah relations
(relasi), biasanya disebut dengan table. Tabel tediri atas baris dan kolom. Baris
mempresentasikan record (atau tuples), dan kolom mempresentasikan Iields (atau attributes)
adalah komponen-komponen dasar yang membentuk suatu relasi database. Setiap data
individual, disimpan dalam Iield di suatu tabel dan setiap record terdiri dari beberapa Iiald yang
membentuk suatu tabel.
Model basis data relasional tidak memiliki parent/root teble, walaupun relasi antara parent table
dan child table diperbolehkan. Parent table dapat memiliki banyak child table, dan demikian juga
sebaliknya. Untuk representasi model basis data relasional diberikan pada gambar 3.4.
Gambar 3.4. Model Basis Data Relasiona
Klebihan basis data relasional:
E Akses data dapat dilakukan dengan sangat cepat dan lebih akurat
E Struktur basis data mudah dilakukan perubahan
E Data direpresentasikan secara logik, user tidak membutuhkan bagaimana data disimpan.
E Mudah untuk membentuk query yang komplek dalam melakukan retrieve data
E Mudah untuk mengimplementasikan integritas data
E Mudah untuk membangun dan memodiIikasi program aplikasi
E Telah dikembangkan Structure Query Language (SQL).
Kelemahan basis data relasional:
E Kelompok inIormasi/tables yang berbeda harus dilakukan joined untuk melakukan retrieve
data
E User harus Iamiliar dengan relasi antar tabel
E User harus belajar SQL.
3.5 Model basis data berorientasi objek
Model basis data berorientasi objek dideIinisikan dengan bahas pemrograman misalnya bahas
JAVA, disimpan dan diakses serta applikasi End User dibangun dengan pemrograman
berorientasi objek pula. Untuk membuat link antara basis data dengan applikasi digunakan
ODMS (Object Database Management System). Pada gambar 3.5. diberikan ilustrasi mengenai
contoh basis data berorientasi objek dan implementasinya.
Gambar 3.5. Basis Data Berorientasi Objek
Dua struktur dasar yang terdapat pada basis data berorientasi objek terdiri adalah dari objects dan
literals. Objects adalah suatu struktur yang memiliki identiIiers, object dapat diasosiasikan
dengan object yang lain. Literals adalah nilai-nilai yang diasosiasikan dengan object dan tidak
memiliki identiIiers. Object dan literals diorganisasikan oleh suatu tipe, dimana setiap elemen
memiliki properties yang sama, yang dapat dimodiIikasi untuk setiap object. Class adalah
ekuivalen dengan tabel pada basis data relasional. Operasi digunakan untuk mengambil nilai-
nilai dari class yang lain, menambah nilai, dan untuk menghapus nilai. Ilustrasi bagaimana relasi
data pada basis data berorientasi objek diberikan pada gambar 3.6.
Gambar 3.6. Model Data Berorientasi Objek
Kelebihan basis data berorientasi objek:
E Programmer hanya dibutuhkan memahami konsep berorientasi objek untuk
mengkombinasikan konsep berorientasi objek dengan storage basis data relasional
E Objek dapat dilakukan siIat pewarisan dari objek yang lain
E Secara teoritis mudah untuk mengatur objek
E Model data berorientasi objek lebih kompatibel dengan tools pemrograman berorientasi objek.
Kelemahan basis data berorientasi objek:
E User harus memahami konsep berorientasi objek, karena basis data berorientasi objek tidak
dapat bekerja dengan metoda pemrograman tradisional
3.6 Model basis data relasional objek
Model ini digunakan untuk mengkombinasikan antara konsep model relasional dengan
pemrograman berorientasi objek, di mana dapat dibuatnya tipe bentukkan. Pada gambar 3.7.
memberikan ilustrasi contoh basis data relasional objek. Tabel employee memiliki 2 kolom yang
memiliki tipe bentukan, yaitu empInIo yang bertipe Person dan addrInIo yang bertipe Address.
Pada empInIo memiliki tipe Person, dimana Person memiliki kategori yang lebih spesiIik: noId,
IirstName, dan lastName.
Gambar 3.7. Basis Data Relasional Objek
Kelebihan basis data relasional objek:
E Tipe bentukan dapat dibuat
Kelemahan basis data relasional objek:
E User harus memahami antara konsep berorientasi objek dengan relasional
E Beberapa vendor mengimplementasikan konsep relasional objek tidak mendukung siIat
pewarisan objek