Anda di halaman 1dari 24

Object and Object-Relational Databases

Disusun oleh :
David Septianto (2017103372)
Willyam Saputra (2017103158)
Predy Daniel Halomoan (2017103603)
Overview of Object Database Concepts
• Ada satu set konsep dasar tertentu, yang didukung oleh setiap sistem
database berorientasi objek. Konsep-konsep dasar ini adalah objek dan
identitas, enkapsulasi, kelas dan instantiasi, pewarisan dan kelebihan,
pengesampingan dan keterlambatan mengikat.
Objects and Identity
• Dalam database berorientasi objek, setiap entitas dunia nyata diwakili oleh
suatu objek. Objek ini memiliki status dan perilaku. Kombinasi nilai saat
ini dari atribut objek menentukan status objek. Seperangkat metode, yang
bekerja pada keadaan objek, menentukan perilaku objek.
Encapsulation
• Enkapsulasi adalah konsep dasar untuk semua teknologi berorientasi objek. Itu dibuat
untuk membuat perbedaan yang jelas antara spesifikasi dan implementasi operasi dan
dengan cara ini untuk memungkinkan modularitas. Perangkat lunak yang melebihi
ukuran tertentu membutuhkan semacam arsitektur modular untuk memungkinkan desain,
implementasi, dan pemeliharaan dijalankan oleh kelompok programmer yang lebih besar.
• Pada prinsipnya, konsep enkapsulasi dalam database berorientasi objek adalah sama.
Satu-satunya perbedaan adalah bahwa itu tidak didefinisikan dengan jelas, apakah
struktur data objek adalah bagian dari antarmuka. Dalam bahasa pemrograman, struktur
data tentu saja merupakan bagian dari implementasi.
Classes and Instantiation
• Kelas adalah seperangkat objek yang memiliki struktur internal yang
persis sama. Dengan cara itu, sebuah kelas mendefinisikan implementasi
suatu objek dan suatu tipe menggambarkan bagaimana objek tersebut
dapat digunakan.
• Istilah instantiasi bertujuan pada kenyataan bahwa definisi kelas dapat
digunakan untuk menghasilkan sekumpulan objek yang memiliki struktur
dan perilaku yang sama. Kelas menentukan struktur (satu set atribut), satu
set operasi dan satu set metode, yang mengimplementasikan operasi.
Inheritance
• Warisan memungkinkan untuk mendefinisikan kelas sebagai subkelas dari
yang sudah ada (superclass). Subkelas mewarisi semua atribut dan metode
dari superclass dan juga dapat mendefinisikan atribut dan metode sendiri.
Konsep ini merupakan mekanisme penting untuk mendukung penggunaan
kembali. Bagian identik dari struktur dua kelas yang berbeda dapat
didefinisikan hanya sekali dalam superclass umum.
Overloading, Overriding and Late Binding

• Untuk mengimplementasikan fungsi ini, Anda pertama-tama harus


mendefinisikan "tampilan" operasi dalam "media" superclass umum dari
"gambar" dan "video" kelas. Setiap subclass mendefinisikan kembali operasi
"view" untuk kebutuhan spesifiknya. Ini menghasilkan berbagai metode yang
memiliki nama operasi yang sama. Menggunakan fitur ini hadir dengan
keuntungan penting. Kode dapat lebih mudah dipelihara dan pengenalan tipe
baru tidak memerlukan modifikasi apa pun untuk bagian aplikasi yang ada.
Menyediakan fitur ini menonaktifkan sistem untuk mengikat nama operasi
dengan metode yang sesuai pada waktu kompilasi. Pengikatan nama operasi yang
tertunda dengan metode yang sesuai pada saat run-time disebut "pengikatan
lambat".
Object Database Extensions to SQL
• Analisis dan desain berorientasi objek adalah metodologi umum untuk
menganalisis dan merancang sistem perangkat lunak. Seringkali sistem ini
memasukkan komponen basis data. Ada aturan standar untuk
menerjemahkan desain berorientasi objek dari sistem database ke dalam
implementasi database relasional tetapi akan lebih baik jika perangkat
lunak database secara langsung mendukung desain berorientasi objek.
SQL adalah definisi standar database relasional dan bahasa manipulasi.
Object Database Conceptual Design
• Membahas tentang :
a. Perbedaan antara Desain Konseptual ODB dan RDB
b. Memetakan Skema EER ke Skema OBD
Perbedaan antara Desain Konseptual ODB dan RDB

• Salah satu perbedaan utama antara desain ODB dan RDB adalah bagaimana
hubungan ditangani. Dalam ODB, hubungan biasanya ditangani dengan memiliki
hubungan yang tepat atau atribut referensi yang mencakup OID (s) dari objek
terkait. Ini dapat dianggap sebagai referensi OID ke objek terkait. Referensi
tunggal dan koleksi referensi diperbolehkan. Referensi untuk hubungan biner
dapat dideklarasikan dalam satu arah, atau dalam kedua arah, tergantung pada
jenis akses yang diharapkan. Jika dideklarasikan dalam kedua arah, mereka dapat
dispesifikasikan sebagai terbalik satu sama lain, sehingga menegakkan ODB
yang setara dengan batasan integritas referensial relasional.
Perbedaan antara Desain Konseptual ODB dan RDB

• Area perbedaan utama antara desain ODB dan RDB adalah bagaimana
penanganan warisan. Dalam ODB, struktur ini dibangun ke dalam model,
sehingga pemetaan dicapai dengan menggunakan konstruksi warisan,
seperti diturunkan (:) dan diperluas. Dalam desain relasional, seperti yang
kita bahas dalam Bagian 9.2, ada beberapa opsi untuk dipilih karena tidak
ada built-in construct ada untuk pewarisan dalam model relasional dasar.
Penting untuk dicatat, bahwa, objek-relasional dan sistem extended-
relasional menambahkan fitur untuk memodelkan konstruksi ini secara
langsung serta memasukkan spesifikasi operasi dalam tipe data abstrak
Perbedaan antara Desain Konseptual ODB dan RDB

• Perbedaan utama ketiga adalah bahwa dalam desain ODB, perlu untuk
menentukan operasi sejak awal dalam desain karena mereka adalah bagian
dari spesifikasi kelas. Meskipun penting untuk menentukan operasi selama
fase desain untuk semua jenis basis data, mungkin tertunda dalam desain
RDB karena tidak diperlukan secara ketat sampai fase implementasi.
Memetakan Skema EER ke Skema OBD
• Relatif mudah untuk mendesain deklarasi tipe kelas objek untuk ODBMS
dari skema EER yang tidak mengandung kategori atau hubungan n-ary-
kapal dengan n> 2. Namun, operasi kelas tidak ditentukan dalam EER dia-
gram dan harus ditambahkan ke deklarasi kelas setelah pemetaan
struktural selesai. Garis besar pemetaan dari EER ke ODL adalah sebagai
berikut:
Memetakan Skema EER ke Skema OBD
• Langkah 1. Buat kelas ODL untuk setiap jenis entitas atau subkelas EER. Jenis
kelas ODL harus mencakup semua atribut dari kelas EER.38 Atribut multinilai
biasanya dideklarasikan dengan menggunakan set, tas, atau daftar konstruktor.
Jika nilai atribut multinilai untuk objek harus dipesan, konstruktor daftar dipilih;
jika duplikat diperbolehkan, konstruktor tas harus dipilih; jika tidak, konstruktor
set dipilih. Atribut komposit dipetakan ke konstruktor tuple (dengan
menggunakan deklarasi struct di ODL).
• Nyatakan perluasan untuk setiap kelas, dan tentukan atribut kunci apa saja
sebagai kunci dari perluasan tersebut. (Ini hanya mungkin jika fasilitas tingkat
dan deklarasi kendala utama tersedia di ODBMS.)
Memetakan Skema EER ke Skema OBD
Langkah 2. Tambahkan properti hubungan atau atribut referensi untuk setiap
pengiriman hubungan biner ke dalam kelas ODL yang berpartisipasi dalam
hubungan. Ini dapat dibuat dalam satu atau kedua arah. Jika hubungan biner
diwakili oleh referensi di kedua arah, nyatakan referensi tersebut sebagai
properti hubungan yang berbanding terbalik satu sama lain, jika ada fasilitas
seperti itu. Jika hubungan biner diwakili oleh referensi hanya dalam satu
arah, deklarasikan referensi sebagai atribut dalam kelas referensi-encing
yang tipenya adalah nama kelas yang direferensikan.
Memetakan Skema EER ke Skema OBD
Langkah 3. Masukkan operasi yang sesuai untuk setiap kelas. Ini tidak
tersedia dari skema EER dan harus ditambahkan ke desain database dengan
mengacu pada persyaratan asli. Metode konstruktor harus menyertakan kode
program yang memeriksa semua kendala yang harus dimiliki ketika objek
baru dibuat. Metode destruktor harus memeriksa semua kendala yang
mungkin dilanggar ketika suatu objek dihapus. Metode lain harus mencakup
pemeriksaan kendala lebih lanjut yang relevan.
Memetakan Skema EER ke Skema OBD
Langkah 4. Kelas ODL yang sesuai dengan subkelas dalam skema EER
mewarisi (melalui extends) jenis dan metode superclass dalam skema ODL.
Atribut (noninherited) spesifiknya, referensi hubungan, dan operasi
ditentukan, seperti yang dibahas dalam langkah 1, 2, dan 3.
Memetakan Skema EER ke Skema OBD
Langkah 5. Jenis entitas yang lemah dapat dipetakan dengan cara yang sama
seperti jenis entitas biasa. Pemetaan alternatif dimungkinkan untuk tipe
entitas lemah yang tidak berpartisipasi dalam hubungan apa pun kecuali
hubungan identifikasi mereka; ini dapat dipetakan seolah-olah mereka adalah
atribut multivalued komposit dari tipe entitas pemilik, dengan menggunakan
set <struct <... >> atau daftar <struct <... >> konstruktor. Atribut entitas yang
lemah termasuk dalam konstruk struct <...>, yang sesuai dengan konstruktor
tuple. Atribut dipetakan sebagaimana dibahas dalam langkah 1 dan 2.
Memetakan Skema EER ke Skema OBD
Langkah 6. Kategori (tipe gabungan) dalam skema EER sulit dipetakan ke
ODL. Dimungkinkan untuk membuat pemetaan yang mirip dengan
pemetaan EER-ke-relasional (lihat Bagian 9.2) dengan mendeklarasikan
kelas untuk mewakili kategori dan mendefinisikan hubungan 1: 1 antara
kategori dan masing-masing dari superclasses-nya. Pilihan lain adalah
menggunakan tipe gabungan, jika tersedia.
Memetakan Skema EER ke Skema OBD
Langkah 7. Hubungan n-ary dengan derajat n> 2 dapat dipetakan ke dalam
kelas yang terpisah, dengan referensi yang sesuai untuk setiap kelas yang
berpartisipasi. Referensi ini didasarkan pada pemetaan hubungan 1: N dari
setiap kelas yang mewakili tipe entitas yang berpartisipasi ke kelas yang
mewakili hubungan n-ary. Hubungan biner M: N, terutama jika mengandung
atribut hubungan, juga dapat menggunakan opsi pemetaan ini, jika
diinginkan.
The Object Query Language OQL
Object Query Language (OQL) adalah standar bahasa query untuk database
berorientasi objek yang dimodelkan setelah SQL. OQL dikembangkan oleh
Object Data Management Group (ODMG). Karena kompleksitas
keseluruhannya, tidak ada yang pernah sepenuhnya mengimplementasikan
OQL lengkap. OQL telah mempengaruhi desain beberapa bahasa permintaan
yang lebih baru seperti JDOQL dan EJB QL, tetapi mereka tidak dapat
dianggap sebagai rasa OQL yang berbeda.
Kesimpulan
• Model data relasional adalah model data berdasarkan teori relasional yang
menggunakan tabel dua dimensi (sering disebut relasi) untuk menggambarkan
sebuah berkas data. Setiap tabel terdiri atas beberapa lajur yang mendatar (baris)
dan beberapa lajur vertical (kolom).
• Model data relasional memiliki bentuk yang sederhana sehingga dapat
memudahkan user untuk mengoperasikan data seperti merubah struktur basis
data dan membuat query untuk retrieve data. Akan tetapi, model data relasional
memerlukan pemahaman user terhadap hubungan tabel-tabel yang digunakan dan
bahasa SQL. Selain itu, untuk memanggil kembali (retrieve) data kita harus
menghubungkan tabel yang berbeda.
Kesimpulan
• Istilah-istilah yang digunakan dalam model data relasional yaitu : entitas,
relasi atau tabel, atribut atau kolom, tuple atau baris, domain, degree, dan
cardinality yang semuanya merupakan elemen suatu tabel.
• Bahasa yang digunakan pada model data relasional adalah bahasa query
yang menekankan pada aspek pencarian data dari dalam tabel. Bahasa
query terbagi menjadi dua, yaitu bahasa query formal yang diterjemahkan
menggunakan simbol-simbol matematis dan bahasa query komersial yang
sengaja dirancang programmer menjadi suatu program aplikasi untuk
memudahkan para penggunanya.
Terima Kasih

Anda mungkin juga menyukai