Tugas Rangkuman Object Oriented Database

Session 10 – Session 13

Kelompok 5

Nama Anggota :

1. Amelia – 1901505535

2. Annisa Baby Utami - 1901487173

3. Cinthia Chainata – 1901481056

4. Desti Natalia – 1901523891

5. Nida Alyssa – 1901511714

6. Selviana Pratiwi – 1901501814

Kelas : LA01
 Session 10 : Object-Oriented Databases Design and
Implementation: OMS Avon

OMS Avon

OMS Avon adalah sebuah implementasi sistem manajemen data OMS berdasarkan db4objects objek
berorientasi-database. Avon terdiri dari inti database yang menerapkan semua fungsi yang
ditetapkan oleh OM data model. Selanjutnya, menyediakan akses ke data dikelola melalui bahasa
Model objek (OML), serta melalui antarmuka sesuai OMSjp. (Sumber :
http://maven.globis.ethz.ch/projects/avon/)

Java implementasi dari OM data model dan OML

OMS Avon Architecture

Storage layer

 Mengelola penyimpanan tingkat rendah

 package ch.ethz.globis.avon.storage

Model layer

 mengimplementasikan fungsi yang terkait dengan OM data model

 package ch.ethz.globis.avon.om
 package ch.ethz.globis.avon.oml
Interface layer

 menyediakan interface pemrograman aplikasi tingkat tinggi

 package ch.ethz.globis.avon.omsjp

OMS Avon Project Modules

OMS Avon Storage Layer

Penyimpanan interface berdasarkan jenis dan informasi unit

 jenis unit yang menyediakan metadata

 informasi unit menyimpan data

Interface pemrograman aplikasi untuk

 membuat, mengambil, memperbarui dan menghapus operasi

 schema evolution
 membuat dan mengelola indeks
 low-level query operators
 transactions, concurrency control and recovery

Tingkat nilai mengelola sebagian besar nilai

Various storage providers

Storage Layer Concepts

I. Storage Layer

 Terdiri dari tiga bagian utama

 Application Programming Interface

• Digunakan oleh model layer

• Merangkum fungsionalitas dan konsep tingkat tinggi

 Internal

• Fungsi internal

• Fungsionalitas umum dan terkelola

 Service Provider Interface

• interface untuk penyedia penyimpanan yang menyediakan fungsionalitas tingkat

rendah

• Db4o, Berkeley DB, di-memori

#Storage Layer Design

 OMS Avon Model Layer

 Salah satu abstraksi Java generik untuk mewakili objek OM

• Titik tunggal diperpanjang
• Fleksibilitas untuk evolusi database
• Kontrol pusat untuk transaksi dan pemulihan
 Kelas untuk mengelola objek generik
• create, retrieve, update and delete operations
 Kelas utilitas untuk mengakses dan menafsirkan objek generik
• Metadata cache dan mengakses data dari layer penyimpanan
 Seluruh metamodelis OM bootstrapped
• Metamodel dinyatakan menggunakan OM (circularity meta)
• Berbagai rasa metamodel
• Diperpanjang metamodel
 Application Programming Interface
 Database Modules
 OMS Avon mendukung modul database yang dapat memperpanjang atau
menyesuaikan sistem untuk domain aplikasi khusus
 Modul database terdiri dari
- Metamodelextension untuk mendefinisikan konsep baru
- Fungsionalitas yang mengelola konsep baru
- Ekstensi bahasa query untuk berinteraksi dengan konsep baru
 Modul database yang ada
- Sistem utama
- Sistem acara
- Berbagi data peer-to-peer
- Manajemen informasi pribadi
- Pengelolaan konten web

 OML Query Engine

 OML Query Evaluation

 Parser
- Digunakan JavaCC untuk menghasilkan parser dan lexer
- Mengembalikan abstract syntax tree (AST)
 Query Tree Converter
- Menggunakan pola desain pengunjung untuk memproses AST secara post-order
- Mengubah AST menjadi query tree (QT)
  Query tree evaluator
- Menggunakan desain pengunjung untuk memproses QT secara post-order
- Hanya mengembalikan hasil terakhir dari skrip OML
- Menyimpan hasil intermediate pada struktur simpul

 Query Tree

 QT node adalah atomic construct

 Digunakan untuk membangun operasi database yang berbeda
- Seleksi, domain, range, iterasi, akses obyek

 OMS Avon Interface Layer

 OMS Avon menyediakan interface alternatif untuk pengembangan aplikasi
 OMSjp
- Akses seragam ke database OMS yang heterogen
- Interface program berbasis Java
- Setara dengan JDBC di dunia OMS
- Memetakan jenis Java ke tipe OM
- Menyediakan abstraksi Java untuk konsep sistem OM
 Object Model Language (OML)
 Graphical User Interface
- OMSjpEclipse plug-in dengan editor skema grafis
- OMSjpBrowser
OMS Driver and OMS Database

• OMSDriver

• Menyediakan fungsionalitas manajemen database

• Abstraksi implementasi yang mendasarinya

• Satu driver per platform yang didukung

• Driver manager memuat driver berdasarkan file konfigurasi

• Driver dikonfigurasi melalui URL

• omsjp:platform://user/password@host:port/database

• OMSDatabase

• Menyediakan fungsionalitas database

• Membuat, memperbarui dan menghapus objek

• Interface query

• Schema management

Import dan export database

OMSjp Value Framework

Impedance Mismatch

• Pemetaan model objek OM ke model objek Java menciptakan ketidakcocokan impedansi

baru

• multiple instantiation

• multiple inheritance

• Objek tunggal diwakili oleh beberapa kelas

• Sebuah metamodelclass dari tipe OMSObject

• Beberapa kelas model dari tipe OMSInstance

• Kelas instansi aplikasi khusus dapat digunakan sebagai pengganti kelas instansi generik

• Jika model data tidak memiliki multiple inheritance, Java inheritance dapat
digunakan untuk mengimplementasikan kelas model aplikasi tertentu

• Jika model data menggunakan multiple inheritance, kelas model aplikasi khusus
tidak dapat menggunakan warisan Java

OMSObject and OMSInstance

OMSjp in Action

Menggunakan OML di OMSjp

Instrumentasi

Dinamis bytecode Instrumentasi

 Menghindari impedansi mismatch untuk memberikan kegigihan transparan

 Kode disuntikkan pada saat run-time

• kegigihan agen terdaftar di JVM ketika database dibuka

• agen mengubah semua kelas yang dimuat oleh JVM

• kapan database ditutup, agen sementara terdaftar

 Instrumentasi mendukung

• OMSjpfaçade pola

• mengetik generasi dan hirarki

• multi-nilai atribut

• asosiasi

Contoh Instrumentasi
Kelas Hierarchy Instrumentasi

Jenis dan Asosiasi Instrumentasi

 Mengetik penciptaan

• adanya tipe OM diperiksa menggunakan nama jenis Java yang memenuhi syarat

• Jawa refleksi kelas analysedusing

• Jawa jenis dipetakan ke jenis OM

• setiap Tipe mendapat koleksi batas

 Obyek referensi

• OM jenis diciptakan untuk properti yang referensi jenis non-koleksi non-dasar dan

• kegigihan oleh reachability

• agen dapat dikonfigurasi untuk membuat asosiasi bukannya referensi untuk

menaikkan ekspresif semantik
Collection Instrumentation
 Multi-nilai Sifat-sifat yang diwakili menggunakan luasan OM
• Set <T>aku s dipetakan ke OMSSet <T>
• Daftar <T> dipetakan ke OMSSequence<T>
• lain jenis koleksi saat ini tidak didukung oleh agen
 OM luasan memberikan dukungan untuk
• koleksi tingkah laku
• koleksi aljabar
• pengelolaan koleksi besar

Konvensi
 kelas-kelas
• harus tidak abstrak
• harus memiliki konstruktor default publik
 properti
• harus dapat diakses melalui getter dan setter accessormethods yang mengikuti Java
Beans konvensi
• publik TypegetProperty ()
• publik kekosongan setProperty (Type)
• semua nama metode lainnya tidak harus berisi mendapatkandan setprefiks
• kata kunci sementarabisa digunakan untuk properti non-persistent
• array tidak didukung sebagai kelas anggota
• Daftar dan Set didukung, semua Koleksi lainnya Java dilarang.
• langsung
 Akses tanpa batas ke OM Fungsi

OMSjp Eclipse Plug-in: Object Browser

 OMSjp Eclipse Plug-in: Ketik Editor

OMSjp Eclipse Plug-in: Klasifikasi Editor

Session 11 : Object-Oriented Management Systems For Relational
Databases (RxO DBMS)

Relational Database Management System (RDBMS) adalah sebuah program

komputer (atau secara lebih tipikal adalah seperangkat program komputer) yang dirancang untuk
mengatur/memanajemen sebuah basis data sebagai sekumpulan data yang disimpan secara
terstruktur, dan melakukan operasi-operasi atas data atas permintaan penggunanya. Contoh
penggunaan DBMS ada banyak sekali dan dalam berbagai bidang kerja,
misalnya akuntansi, manajemen sumber daya manusia, dan lain sebagainya.
RxO DBMS mengelola data relasional dengan cara berorientasi objek
Di pengguna RDBMS tradisional harus diingat bagaimana data obyek yang kompleks didistribusikan
ke meja dinormalisasi untuk mengelola data.
RxO DBMS dapat mengelola asosiasi catatan relasional struktur tabel yang berbeda, yang terlihat
untuk pengguna sebagai objek yang kompleks

RxO DBMS mengelola data relasional dengan cara berorientasi objek

KOMPLEKS heterogen DATA SKEMA (OR “TIDAK HANYA TABLES”)

Untuk pengguna RxO DB terdiri dari kedua tabel dinormalisasi tradisional T dan kelas kompleks C,
Bersatu dengan kedua kunci relasional dan referensi objek.
SEBUAH seperangkat perintah deklaratif, memperpanjang SQL, digunakan untuk membuat dan
mengubah kelas dan untuk mengelola data objek. Dengan ini, tidak ada bahasa pemrograman OO
eksternal yang diperlukan untuk membuat model domain obyek yang kompleks.

Complex objects

Di RxO negara DB objek apapun disajikan dengan seperangkat nilai-nilai asli untuk sistem relasional,
persis nilai-nilai domain dan nilai-nilai relasional.
Demikian,objek kelas didefinisikan sebagai satu set skalar (inc.referensi) dan tabel properti, yang
bersama-sama menyajikan keadaan objek, dan metode yang digunakan untuk mengubah state.
kendala opsional (keys and foreign key) dapat diatur untuk kelas.

Dari perintah tersebut kelas baru dapat ditambahkan dalam sistem kerja ketika itu perlu. Mungkin
Multiple Inheritance akan terjadi

CLASS INTERFACE IMPLEMENTATION

Kelas interface sangat dipisahkan dari implementasi. Setiap elemen didefinisikan dalam interface
harus dilaksanakan, baik sifat dan metode.
Properti (antara scalar & tabel) yang bisa di implementasikan pada penyimpanan. Sifat disimpan
menyimpan nilai-nilai mereka terus-menerus, seperti tabel.
dihitung. Sifat dihitung bertindak seperti pandangan.
Implementasi ini menggunakan SELECT atau UDF. Pelaksanaan metode ini mirip dengan UDF atau
UDP. Dengan demikian kelas bersatu kemungkinan tabel, pandangan dan disimpan fungsional
RDBMS tradisional
Maksud dari class tersebut dapat di jadikan kembali selama inheritance. Juga implementasi kelas
dapat diubah dalam kelas non-empty tanpa sistem total pembuatan kembali.

How the objects are accessed in RxO DB ?

Sebuah objek di RxODB ada sejak dibentuk sampai itu akan de hancur jelas. Semua benda dapat
diakses sebagai elemen dari kelas mereka (sehingga kelas dapat didefinisikan sebagai “satu set
bernama objek yang ada kelas”).
Karena fitur ini setiap objek dapat diakses, bahkan tidak ada referensi di atasnya, sehingga referensi
tidak wajib dalam perintah manajemen dan akses non-navigasi untuk benda-benda mudah mungkin.
Referensi hanya diperlukan untuk menghasilkan struktur obyek yang kompleks.

Representasi Relasional Data Objek

Pengguna bisa mendapatkan data objek menggunakan dalam ekspresi query jalan relasional yang
menggambarkan struktur objek bersarang kompleks.
RxO Sistem membangun representasi relasional data objek sesuai dengan dot-dipisahkan urutan
nama yang digunakan sebelum perhitungan dari query itu sendiri, dengan cara seperti tabel
JOINenmanual dengan bidang kunci dalam RDBMS tradisional. Satu-satunya persyaratan adalah
untuk tetap query urutan nama yang membentuk bersama-sama ekspresi path lengkap dari akar
struktur hirarki untuk daun skalar nya. Umumnya, hanya nama-nama penting bagi pengguna untuk
mendapatkan data.

Selama sistem perhitungan tersebut mengikat implementasi dari sifat, sehingga hasilnya dapat berisi
kedua disimpan dan dihitung nilai-nilai secara bersamaan. Jika implementasi berubah query akan
mengembalikan hasil baru. Jadi, representasi data relasional langsung tergantung pada internal
kelas. Query dapat menggabungkan data dari kedua kelas dan tabel tradisional.

ARSITEKTUR KIASAN “OO TRANSLATOR UNTUK RELASIONAL TARGET MESIN”

Itu Inti dari ОО-terjemahan target relasional mesin:

Kompleks deskripsi struktur objek yang dipetakan ke beberapa struktur deskripsi relasional (tabel
dan tampilan). Info pemetaan disimpan dalam katalog DBMS yang akan digunakan sebagai tabel
simbol selama semua operasi terjemahan,
Semua operasi pada objek dijabarkan langsung dalam operasi pada data struktur relasional,
berdasarkan info pemetaan.
GROUP OBYEK PENGOLAHAN

Ditampilkan secara resmi bahwa setiap pelaksanaan properti dihitung atau metode dapat diubah
menjadi prosedur pada struktur relasional yang mendasari dengan cara yang setiap langkah dari
setiap algoritma sumber tertentu dalam pelaksanaannya dilakukan secara bersamaan (dalam operasi
relasional tunggal) pada data kelompok obyek untuk setiap kelompok benda. Dengan cara ini setiap
pengolahan data yang diberikan dalam jangka objek diterjemahkan ke dalam pengolahan relasional.

Sebagai keuntungan, kemungkinan ini memungkinkan re-order dan meminimalkan operasi disk
selama pemrosesan kompleks set objek, sehingga pengolahan melakukan lebih cepat. Juga mungkin
tampaknya menjadi “asli” untuk penyimpanan relasional dengan organisasi data vertikal.

Kemungkinan baru: objek reklasifikasi dinamis

Dengan metafora “OO penerjemah untuk mesin target relasional” mudah mungkin untuk
memanipulasi dengan struktur data dalam memori dari “mesin relasional”, menjaga asosiasi data.
Akibatnya tingkat baru fleksibilitas objek kompleks persisten tercapai, saat obyek dapat dipindahkan
dan diubah dalam skema data yang ada sesuai dengan proses yang ada di objek dimodelkandomain.
Itu membuat model yang lebih akurat dan ekspresif dan memberikan kemungkinan-kemungkinan
baru untuk mengembangkan sistem informasi selama hidup mereka.

RDBMS EVOLUSI MENUJU SERVER OBJEK DOMAIN MODELING

RxO Pendekatan memungkinkan sebuah evolusi halus RDBMS terhadap jenis baru dari sistem yang
sepenuhnya menggabungkan sifat dari DBMS dan objek domain pemodelan alat kaya.
Untuk pengguna DBMS RxO DBMS adalah pengembangan hanya lebih lanjut dari RDBMS yang ada
(sebagai versi baru), sepenuhnya menyimpan semua fitur mereka, termasuk dialek SQL, protokol
akses, kontrol pengguna, manajemen transaksi, dll RxOversi DBMS yang ada dapat dengan mudah
digunakan sebagai pengganti yang sebelumnya di sistem pengguna yang ada dan database.
Pengguna mendapatkan suksesi penuh sistem.

RDBMS EVOLUSI MENUJU SERVER OBJEK DOMAIN MODELING (Cont ...)

Untuk DBMS vendor RxOPendekatan menyimpan dan maksimal menggunakan fungsi dari DBMS
yang ada. Realisasi fitur baru tidak memerlukan perubahan signifikan dalam core system.
Penggunaan yang ada fungsional memungkinkan menggunakan solusi terbukti dan menyimpan
keandalan dari DBMS relasional.
Di terakhir RxOPendekatan tidak mencoba untuk mengubah model data relasional, tetapi
menggunakan sebagai dasar formal dan mengimplementasikannya dengan cara yang baru. Dengan
ini, mungkin untuk memastikan hasil yang benar dari kegiatan sistem.
 Session 12 : Commercial OODBMS: Versant

Versant Object Database ( juga dikenal sebagai VOD atau hanya ” Versant ” ) adalah sebuah
OODBMS yang mendukung concurrency besar dan set data yang besar. Versant menggunakan
kinerja internal dan skalabilitas tolok ukur untuk memonitor dan mengukur perilaku dari waktu
ke waktu di rilis. Versant dapat ber-interfacing dengan Java, C++, dan dotNet. OODMS ini
mengklaim sistem databasenya tidak banyak membutuhkan administrasi. Fitur-fitur yang
menarik dari Versant Object Database adalah kemampuan scalability dengan mendukung proses
multi threaded dan multi session. VOD mendukung permintaan melalui pengindekan sisi server
dan mesin eksekusi query. Versant menyediakan kemampuan query ini di sejumlah bentuk
tergantung pada bahasa yang dipilih.

Sebagai contoh, di Java VOD menyediakan VQL (Versant Query Language), JDOQL, EJB QL
dan OQL. Dalam C + + Versant menyediakan VQL dan OQL, dengan C # dukungan untuk VQL,
OQL dan LINQ. VOD akan melakukan optimasi eksekusi query berdasarkan indeks atribut yang
tersedia. Versant juga memiliki dukungan untuk query SQL standar terhadap database Versant
menggunakan driver ODBC / JDBC.

Arsitektur distribusi data pada VOD menangani pengolahan data yang didistribusikan
menggunakan dua fase komit protokol di database. Dalam proses ini, VOD menggunakan
manajer sumber daya internal yang menangani transaksi terdistribusi. Versant juga mendukung
protokol XA yang memungkinkan transaksi eksternal monitor untuk mengontrol konteks
transaksional, jadi misalnya steker ke CORBA atau aplikasi server J2EE.

Versant dalam OODBMS memiliki tools yang cukup lengkap, dalam tool tersebut juga
menyediakan fasilitas dan kemudahan karena VOD ini mendukung aplikasi ber oriented
objek. Selain itu, model versant juga memungkinkan penanganan data yang lebih sederhana,
tersturuktur, dan lebih kompleks untuk implementasi dalam database yang berorientasi objek

.
 VERSANT OBJECT DATABASE ARCHITECTURE

 VERSANT DUAL CACHE ARCHITECTURE

 VERSANT MULTI-THREADED ARCHITECTURE

 Java Versant Interface (JVI)
 Menyediakan penyimpanan objek Java persisten yang mudah digunakan
- Sintaks dan semantik Java murni
- Contoh hampir semua kelas bisa disimpan dan diakses
- Beberapa thread dapat bekerja dalam transaksi bersama atau independen
 Arsitektur client-server
- Menyediakan akses ke database objek Versom
- Objek cache perpustakaan klien untuk akses dan navigasi yang lebih cepat
- Query database dijalankan di server
 Dukungan untuk Java Development Kit

 JVI LAYERS
 Fundamental Layer
- Database-sentris
- Paket com.versant.fund
 Transparent Layer
- Bahasa-sentris
- Paket com.versant.trans
 ODMG Layer
- Bahasa-sentris
- ODMG database dan model transaksi, koleksi ODMG
- Paket com.versant.odmgand com.versant.odmg3

 APPLICATION DEVELOPMENT WITH VERSANT

 Kembangkan kelas Java
- Membuat kode "ketekunan sadar"
- Sesi, transaksi dan concurrency
 Buat file konfigurasi untuk program penambah
 Kompilasi kelas Java untuk menghasilkan byte-code
 Jalankan enhancer untuk membuat perubahan kode byte
 Buat database
 Jalankan aplikasi
 PERSISTENCE AND NAVIGATION MODEL
 Versant memberikan ketekunan dengan jangkauan
 Database root dapat digunakan untuk mempertahankan akar grafik objek dan
menetapkannya sebagai nama untuk mengambilnya lagi nanti
- MakeRoot () menciptakan root dan menyimpan objek
- DeleteRoot () menghapus root tapi tidak menghapus objek
- FindRoot () mengambil objek root
 Navigasi transparan
- Dimulai dari identitas, root object, class extent atau query
- Navigasi digunakan untuk mengakses objek yang terkait
- Secara transparan transparan mengunci dan mengambil objek dari database

 FIRST AND SECOND CLASS OBJECTS

 Objek Kelas Pertama (FCO)
- Dapat disimpan dan diambil secara independen sebagai objek mandiri
- Memiliki Logical Object Identifiers (LOID)
- Bisa menjadi subyek pertanyaan
- Perubahan pada contoh yang ada akan disimpan secara otomatis
- Referensi untuk FCO yang ada selalu valid
- Bidang yang ditandai sebagai sementara tidak tersimpan dalam database
 Objek Kelas Kedua (SCO)
- Dapat disimpan hanya sebagai bagian dari FCO
- Tidak bisa menjadi subjek pertanyaan
- Jika SCO tidak memiliki tipe atribut Versant yang sesuai maka disimpan sebagai
stream byte Java serial
- Bidang yang ditandai dengan sementara tidak tersimpan dalam database

 PERSISTENCE CATEGORIES (FCO)

 Persistent always (p)
- Menjadi gigih pada instansiasi objek itu sendiri
- Objek secara otomatis ditandai kotor saat dimodifikasi
 Persistent capable (c)
- Contoh baru awalnya bersifat sementara, namun mungkin terus berlanjut
 - MakeRoot (), makePersistent () atau ketekunan dengan reachability
- Objek secara otomatis ditandai kotor saat dimodifikasi
 Superclass dari kelas "p" atau "c" juga harus "p" atau "c"
- Kecuali superclassis Object
- Perhatikan bahwa peraturan ini bersifat rekursif

 PERSISTENCE CATEGORIES (SCO)

 Transparent dirty owner (d)
- Perubahan objek secara otomatis menandai pemiliknya sebagai barang kotor
- Digunakan untuk koleksi serial
 Persistence aware (a)
- Dapat secara langsung dan transparan memodifikasi atribut FCO
- Jika SCO dari FCO dimodifikasi, dirtyObject () harus dipanggil untuk FCO yang berisi SCO
untuk menyimpannya.
 Not persistent (n)
- Tidak ada penambahan kode byte
- Tidak bisa langsung mengakses field dari objek yang persisten
- Akses ke bidang semacam itu akan melempar IllegalAccessError

 CONNECTING TO A DATABASE
 Aplikasi melakukan operasi database dalam sesi
- Akses ke database, metode, tipe data dan objek yang persisten
- Harus ditutup sebelum aplikasi berakhir
- Satu atau lebih sesi bisa dibuka pada waktu bersamaan
 Di setiap lapisan JVI, ada implementasi sesi
 Elemen sesi klien
- Cache objek
- Tabel deskriptor objek cache
 Elemen sesi server
- Terkait dengan setiap database yang terhubung adalah cache halaman untuk
halaman yang baru diakses
- Cache halaman server ada dalam memori bersama dari mesin yang berisi database
yang terhubung
 TRANSACTION MODEL
 Setelah memulai sesi, Versant selalu dalam transaksi
- Setelah commit () atau rollback (), sebuah transaksi baru dimulai secara otomatis
- EndSession () melakukan transaksi terakhir
 Transaksi memiliki karakteristik sebagai berikut
- Atomik, konsisten, mandiri, tahan lama
- Terkoordinasi: objek dikunci untuk koordinasi dengan pengguna lain
- Didistribusikan: dua fase komit untuk bekerja dengan banyak database
- Selalu hadir: kode aplikasi selalu dalam transaksi
 Melakukan unit kerja
- Commit () melepaskan kunci dan flushes cache
- CheckpointCommit () menyimpan kunci dan menyimpan objek dalam cache
- CommitAndRetain () melepaskan kunci dan menyimpan objek dalam cache

 OBJECT LIFECYCLE
 Penciptaan objek yang persisten
- Objek Java dibuat di memori Java
- Informasi database internal per objek dalam cache objek Versant
 Commit
- Data objek ditulis ke database
- "Berongga" proxy objek Java dipertahankan di ruang memori
 Rollback
- Objek database baru akan dijatuhkan
 Querying objects
- Query dilewatkan ke database server
- Objek proxy untuk setiap objek yang cocok di set hasil
 Mengakses objek
- Secara transparan menampilkan objek atau de-serializes objek
 Contoh

 UPDATING OBJECTS
 First Class Objects
- Perubahan pada objek kelas pertama secara otomatis diterapkan ke database saat komit
- Objek database dimodifikasi secara transparan
- Nilai tipe dasar disalin ke database
 Second Class Objects
- Transparent Dirty Owner: perubahan pada objek secara otomatis diterapkan ke
database saat komit
- Persistent Aware: modifikasi SCO membutuhkan eksplisit kotor pemilik FCO
menggunakan metode TransSession.dirtyObject ()
- Alasannya adalah bahwa SCOs serialised menjadi pemilik FCO
- Jika SCO terkandung dalam dua FCO, ini akan menyebabkan dua contoh SCO di memori
Java setelah memuat ulang FCOs
 DELETING OBJECTS
 First Class Objects
- Hapus secara eksplisit dengan TransSession.deleteObject () dan
TransSession.groupDeleteObjects ()
- Metode ini mengacu pada objek database, contoh Java adalah sampah yang
dikumpulkan oleh JVM
- Panggilan JVM selesai () saat pengumpulan sampah, bukan penghapusan
 Second Class Objects
- Dihapus secara implisit dengan menetapkan referensi ke null
- Memori akan menjadi sampah yang dikumpulkan oleh JVM
- Saat komit, FCO yang berisi tidak akan menyamarkan SCO

 JVI CLIENT CACHE LOADER

 Versant menggunakan cache objek sisi klien
- Berisi hasil query dan objek yang diakses melalui navigasi
- Trek server yang objeknya di-cache oleh klien
 Pemuatan objek otomatis melalui penutupan
- Dengan titik awal, penutupan didefinisikan sebagai identifikasi dan pengambilan benda-
benda terkait relatif terhadap titik awal
- Setiap kali sebuah objek dereferenced, pengelola objek memutuskan apakah penutupan
diperlukan dan kemudian akan menemukan dan memuat objek yang terkait
 JVI Client Cache Loader API dapat digunakan untuk mengontrol bagaimana dan kapan objek
dimuat
- Masing-masing dereference terdiri dari RPC jaringan, object lookup dan I / O
- Efisiensi dapat ditingkatkan dengan cara memuat beberapa objek sekaligus
- Namun, mengenalkan kode khusus vendor ke dalam kelas domain
 BREADTH, DEPTH AND PATH LOADING

 Kelas penolong penutupan klien menyediakan dua panggilan API sederhana

- groupReadObjects() dan getClosure() di kelas Loader
 Kebijakan beban memberikan kontrol di luar kode aplikasi
- Kebijakan untuk mengendalikan pemuatan objek yang ditentukan dalam file XML
- XML "disusun" oleh Versant PolicyMakerutility
- Load () pada class Loaderloads object berdasarkan kebijakan yang ditentukan

 VERSANT COLLECTIONS
 Penyimpanan koleksi Java didukung
- Array, Vector, Hashtable, LinkedList
 First class object (FCO) collections
- VVector, VHashtable
 Second class object (SCO) collections
- DVector
 Scalable large collections
- LargeVector
 ODMG collections

 SCALABLE LARGE COLLECTIONS

 Classes DVector, VVector dan VHashtable serta koleksi ODMG diimplementasikan di front-
end
- Dipetakan ke atribut tipe variable-length storage (vstr)
- Masalah kinerja dengan sejumlah besar objek dalam koleksi
 Kelas com.versant.util.LargeVector
- Menerapkan antarmuka standar Vector
- Dipecah menjadi beberapa node
- Hanya dibutuhkan node yang dibawa ke front-end pada akses elemen
 Mengunci masalah
- Lebih konkuren karena tidak seluruh objek perlu dikunci
- Potensi kebuntuan
- Gunakan protokol penguncian, mis. Update hanya dalam ascending order saja

 ODMG Collections
 Ikuti spesifikasi standar ODMG
- Diimplementasikan secara Versant sebagai lapisan tipis di atas ikatan transparan
- Kelas koleksi juga tersedia dari TransSession
 ODMG 2.0
- Koleksi gaya JDK 1.1
- Paket com.versant.odmg
 ODMG 3.0
- Koleksi gaya JDK 1.2
- Paket com.versant.odmg3
- Perluas java.util.Collection interface
- Sebanding merekomendasikan penggunaan gaya koleksi ini
 ODMG COLLECTION QUERY FACILITIES
 Koleksi ODMG menyediakan fasilitas permintaan tambahan
 VCollection mengimplementasikan java.util.Collection untuk menambahkan kemampuan
query pada koleksi
- BooleanexistsElement (Stringpredicate)
- DCollectionquery (String predikat)
- Iteratorelect (String predikat)
- Object selectElement (String predikat)
 Query atas koleksi ODMG
- Hanya objek dalam koleksi yang dipertimbangkan
- Predikat adalah tempat dari Query VQL
- Hanya koleksi yang gigih yang bisa ditanyakan
 Versant Query Language (VQL)
 VQL 6
- VQL 6 queries adalah subset dari OQL seperti yang ditentukan oleh ODMG 2.0
- Tidak ada pemilahan, tidak ada ekstensi untuk kemampuan baru, API terbatas
- Seperti pada Versant 7.0, query VQL 6 tidak berlaku lagi
 VQL 7
- Dukungan untuk ekspresi kompleks
- Dukungan untuk penyortiran sisi server
- Meningkatkan kemampuan pengindeksan
 Query VQL ditentukan sebagai string query yang dikompilasi, dioptimalkan dan dieksekusi
pada server basis data
- Kueri dapat dihitung parameternya
- Parameter dimulai dengan $ diikuti oleh karakter, angka atau garis bawah
- Parameter terikat pada nilai menggunakan metode bind ()

 EVENT NOTIFICATION
 Perbanyakan kejadian dari database ke klien terdaftar
- Model acara Java Beans
- Panggil balik ke objek pendengar acara
 Event types
- class events: buat, ubah atau hapus instance
- object events: memodifikasi atau menghapus objek atau kelompok objek
- transaction demarcationi: memulai atau mengakhiri transaksi
- user-defined events
 Antarmuka pemrograman aplikasi
- Paket com.versant.event
- Sub-interface VersantEventListener untuk setiap jenis acara
- Class EventClient menyediakan fungsi sisi klien
 EVENT CHANNELS
 Event komunikasi berdasarkan saluran event
- Abstraksi untuk menyiarkan pemberitahuan acara
- Pendengar acara didaftarkan melalui saluran
- Setelah pembuatan, aplikasi bisa "tune-in" ke saluran acara
 Ruang nama global untuk saluran event
- Gigih melintasi aplikasi klien
 Kategori
- Berbasis kelas: acara kelas untuk seperangkat kelas tertentu
- Berbasis objek: peristiwa objek untuk satu set objek tertentu
- Berbasis query: event kelas untuk objek yang sesuai dengan kueri tertentu
 Manajemen saluran melalui EventClient
- Buat saluran acara baru menggunakan ChannelBuilder
- Mengakses saluran acara yang ada

 PERSISTENT OBJECT HOOKS

 Izinkan intervensi pada semua tahap transisi keadaan benda yang terus-menerus
- Hitung atribut sementara
- Membangun cache sementara
- Melakukan tugas rumah tangga untuk menjaga integritas referensial
 Metode Hook
- activate() dan deactivate()
- preRead(booleanact) dan postRead(booleanact)
- preWrite(booleandeact) dan postWrite(booleandeact)
- Parameter Boolean menunjukkan apakah objek telah diaktifkan / dinonaktifkan (true)
atau tidak (false)
- VDelete () bila objek dihapus
 MAINTAINING REFERENTIAL INTEGRITY

 SCHEMA EVOLUTION
 Dukungan untuk skema evolusi berdasarkan antarmuka pemrograman aplikasi
 Fundamental binding
- inserting, appending, dropping, danrenaming attributes
- adding dan renaming classes

 Transparent binding
- Metode TransSession#setSchemaOption(int) untuk mengkonfigurasi evolusi skema
otomatis
 Session 13 : Open Sources OODBMS: EyeDB

Tinjauan EyeDB

Fitur-fitur dari EyeDB OODBMS adalah:

1. Fitur OODBMS standar:

 Manajemen data
 Client atau server model
 Layanan transaksi
 Pemulihan sistem
 Model objek ekspresif
 Pewarisan sifat
 Ntegrity constraints
 Methods
 Riggers
 query language;
 Tampilan aplikasi
2. Dukungan untuk database besar
Kapasitas database mencapai hingga Tb (tera-bytes)
3. Orientasi bahasa
 Object Definition Language (ODL)
 Object Query Language (OQL)
 Beberapa manipulasi bahasa binding seperti C ++ dan Java
4. Efisiensi
 Objek database harus langsung dipetakan dalam ruang memori virtual;
 Memori objek harus dikurangi seminimum mungkin
 Clever caching policies kebijakan harus dilaksanakan
5. Genericity dan orthogonality dari object model
 Terinspirasi oleh SmallTalk, loop, Java dan ObjVlisp objek model yaitu setiap
kelas berasal dari kelas obyek dan dapat dimanipulasi sebagai objek
  Type polymorphism
 Binary relationships
 Literal and object types
 Objek sementara
 Method and trigger overloading;
 Berbasis template koleksi seperti set, bag, dan array
 Multi-dimensi dan variabel ukuran dimensi array
6. Skalabilitas
Program harus mampu menangani ratusan jutaan objek tanpa kehilangan
performance

The Architecture

The EyeDB Architecture

The

Storage Manager Subsistem

EyeDB didasarkan pada arsitektur klien server.

Server kernel adalah subsistem manajer penyimpanan yang menyediakan layanan utama berikut:

1. Manajemen data mentah

2. Layanan transaksi
3. Sistem pemulihan
4. B-tree and hash indexes
5. Manajemen database multi volume
The Object Model

EyeDB object model ini terinspirasi oleh model SmallTalk, loop, ObjVlisp, Java dan ODMG

Partial Native Object Model

Class Structure

Kelas terdiri dari nama, kelas induk kecuali untuk objek kelas yang merupakan root kelas,
satu set atribut, satu set methods dan satu set trigger:

Atribut terdiri dari jenis, optionnal array pengubah dan literal atau objek. Misalnya, menggunakan
bahasa EyeDB ODL:

Applicative Object Model Example

Type Polymorphism

 Dua bahasa binding, C ++ dan Java, dan EyeDB OQL mendukung jenis polimorfisme: variabel
mungkin terikat dengan contoh-contoh dari berbagai jenis
 bahwa setiap EyeDB kelas mewarisi dari kelas obyek

The Collection Type

Jenis koleksi yang didukung oleh EyeDB adalah set, bag dan array:

 Set : koleksi tidak terurut dan tidak duplikat

 Bag : Koleksi tidak terurut dan duplikat
 Array : berisifat dinamis terurut dan tidak duplikat

Relationships

EyeDB object model mendukung hanya biner relationship, yaitu hubungan antara dua jenis.
Hubungan biner mungkin satu-satu, satu-ke-banyak atau banyak-ke-banyak tergantung pada
cardinality dari jenis terkait. Hubungan tidak bernama.

EyeDB mempertahankan integritas referensial hubungan. Ini berarti bahwa jika objek yang
berpartisipasi dalam hubungan yang dihapus, maka setiap path traversal ke objek juga dihapus.

EyeDB mendukung atribut objek: atribut semacam ini memungkinkan satu objek untuk
referensi lain tanpa referensial integritas. Atribut objek-dihargai mengimplementasikan hubungan
unidirectionnal: dalam kasus ini, EyeDB tidak menjamin integritas referensial. Catatan bahwa
unidirectionnal relationship tidak disebut hubungan.

Constraints

EyeDB supports all standard constraints:

 The not null constraint pada atribut dalam kelas X berarti bahwa tidak ada kasus kelas X
dapat memiliki nilai atribut ini tidak ditetapkan.
 The unique constraint pada atribut dalam kelas X berarti bahwa seseorang tidak dapat
membuat instance kelas X yang memiliki nilai atribut yang sama dari contoh yang ada di
database.
 The cardinality constraint pada contoh koleksi kelas berarti bahwa jumlah dari koleksi ini
harus mengikuti batasan cardinality
The Object Definition Language

 EyeDB objek definisi bahasa (ODL) adalah bahasa berdasarkan ODL ODMG untuk
menentukan spesifikasi dari jenis objek. ODL tidak dimaksudkan untuk menjadi sebuah
bahasa pemrograman yang penuh
 Seperti ODMG ODL, EyeDB ODL mendefinisikan kelas (warisan dan atribut), hubungan dan
metode signitures
 Tidak seperti ODMG ODL, setiap instance kelas dapat digunakan baik sebagai literal atau
sebagai objek.
 EyeDB ODL juga memungkinkan pengguna untuk menentukan apakah metode backend
(yaitu sisi server) atau frontend (yaitu sisi klien)

Here is a simple example of an EyeDB ODL construct:

enum CivilState{
Lady = 0x10,
Sir = 0x20,
Miss = 0x40
};

class Address {
attribute string street;
Attribute string <32> town;
};

class Person {
attribute string name;
attribute int age;
attribute Address addr;
attribute CivilState cstate;
attribute Person * spouse inverse Person :: spouse;
attribute ser<car *> * cars inverse Car :: owner;
attribute Person *childern [];

instmethod void change_address (in string street, in string town, out string oldstreet,
 out string oldtown);

classmethod int getPersonCount ();

index on name;
};

class Car {
attribute string brand;
attribute int num;
attribute Person *owner inverse Person :: cars;
};

class Employrr extends Person {

Attribute long salary;
Person *boss;
};

Contoh ini menggambarkan semua konsep yang telah kami jelaskan sebelumnya.

 class Person Terdiri dari sejumlah atribut yang masing-masing memiliki kekhasan yang
menarik.

 Atribut nama adalah array karakter ukuran variabel, yaitu sebuah string.

 Atribut ini bersifat literal, yang berarti tidak memiliki identifier dalam database. Indeks
petunjuk berarti atribut ini harus diindeks untuk memberikan kueri yang efisien sesuai
dengan nilai atribut.

The age attribute is a simple literal 32-bit integer.

Atribut addr adalah atribut tipe pengguna literal. Karena atribut ini bersifat literal, atribut tipe,
Address, harus sudah ditentukan sebelumnya

 Pasangan atribut berikutnya memiliki dua kekhasan yang menarik:

1. Karakter a* mengikuti tipe pengguna, yang berarti bahwa atribut ini bukan huruf melainkan
objek (yaitu dengan identifier). Karakter * berarti referensi ke objek.
 2. Petunjuk (invers Person :: spouse berikut pasangan berarti atribut ini adalah sebuah
hubungan. Karena atribut pasangan bukanlah koleksi dan atribut target pasangan bukanlah
koleksi, ini adalah hubungan satu lawan satu.

 Atribut mobil juga memiliki beberapa kekhasan yang menarik:

1. Sebagai karakter a* mengikuti tipe pengguna, ini adalah objek.

2. Atribut ini adalah himpunan yang unsur-unsurnya adalah objek tipe Car. Perhatikan bahwa
tipe pengguna Car ditentukan setelahnya.
3. Petunjuk (inverse Car :: pemilik Car berikut berarti atribut ini adalah hubungan yang
targetnya adalah atribut pemilik di kelas Car. Karena atribut sumber Car adalah koleksi dan
pemilik atribut target bukan koleksi, hubungan tersebut adalah Hubungan banyak-ke-satu.

 Seperti yang ditunjukkan oleh instink kata kunci, metode change_address adalah metode
contoh.
 Perhatikan bahwa kata kunci ini bersifat opsional karena ini adalah defaultnya. Metode
getPersonCount adalah metode kelas seperti yang ditunjukkan oleh kata kunci classmethod .
 class Employee Mewarisi dari class Person Seperti yang ditunjukkan oleh kata keyword
extends.
 Ini memperkenalkan dua atribut gaji, atribut literal integer dan atasan, atribut objek yang
merujuk sebuah instance dari class person.
 Perhatikan bahwa karena tidak ada indikasi hubungan (yaitu kata kunci terbalik),
atribut bos adalah atribut bernilai objek (yaitu hubungan tidak sadar):
 Dalam hal ini, EyeDB tidak menjamin integritas referensial.

 The Object Query Language

 EyeDB menyediakan bahasa query berdasarkan ODMG OQL. Meskipun EyeDB OQL bukan
OML (yaitu Manipulasi Bahasa Objek), sebagian besar operasi bahasa umum dapat dilakukan
(operasi aritmatika dan logika, manipulasi string, kontrol aliran, definisi fungsi) dan juga
konstruksi query.
 EyeDB OQL menambahkan beberapa fitur dari ODMG OQL seperti flow control (jika ada,
untuk, sementara), definisi fungsi, operator penempatan, dan operator ekspresi reguler.
 Misalnya contoh berikut adalah konstruksi hukum EyeDB OQL:

Perhatikan bahwa kode sebelumnya tidak melakukan query apapun.

Kode berikut melakukan kueri:

 The C++ Binding

 C + + yang mengikat memetakan model objek EyeDB ke C ++ dengan mengenalkan API

generik dan alat untuk menghasilkan API C ++ tertentu dari skema yang diberikan, yang
dibuat di atas API generik.
 Setiap kelas dalam model objek EyeDB diimplementasikan sebagai kelas C ++ di dalam API C
++: ada pemetaan satu-ke-satu antara model objek dan API C ++.

TRANSIENT DAN OBYEK-OBJEK YANG TEPAT

 Ada dua jenis objek runtime: objek runtime yang terus-menerus dan objek runtime transien.
 Objek runtime bersifat persisten jika dikaitkan dengan objek database. Jika tidak, itu
sementara.
 Secara default, EyeDB tidak menyediakan sinkronisasi otomatis antara objek runtime yang
terus-menerus dan objek database.
 Ketika menetapkan nilai pada objek runtime yang terus-menerus, kita tidak memodifikasi
objek database yang terikat. Seseorang harus memanggil metode toko pada objek runtime
yang terus-menerus untuk memperbarui objek database yang terikat.
Perhatikan bahwa setiap manipulasi objek runtime terus-menerus harus dilakukan dalam lingkup
transaksi.
 Untuk menggambarkan manipulasi objek, kami mengenalkan contoh konkret sederhana
dengan menggunakan skema C ++ API berbasis skema, berdasarkan contoh contoh ODL
sebelumnya:
Beberapa komentar dari kode sebelumnya:

1. Pernyataan Person * p = new Person (& db) menciptakan objek runtime transien. Objek
runtime ini tidak terikat dengan objek database sampai metode store dipanggil.

2. Semua metode pemilih dan pengubah seperti setName, getAddr, addToCarsColl telah
dihasilkan oleh penyusun EyeDB ODL dari konstruk ODL sebelumnya.

3. eyedb::RecMode::FullRecurs argument ke metode store memungkinkan pengguna untuk

menyimpan setiap objek yang berhubungan dengan panggilan instance : sehingga objek
runtime car1 dan car2 dalam koleksi mobil akan disimpan secara otomatis menggunakan
metode store dengan argumen ini.

4. Panggilan ke transactionCommit memastikan bahwa perubahan database akan disimpan

dalam database.

 The Java Binding

Penggunaan bahasa Java untuk pengikatan EyeDB telah dimotivasi oleh beberapa alasan:
1. Java adalah arsitektur independen,
2. Java sangat berharga untuk lingkungan jaringan terdistribusi,
3. Java memiliki perpustakaan yang sangat kaya di perpustakaan,
4. Java aman,
5. Java lebih mudah diprogram daripada C ++.
Pengikatan Java sangat dekat dengan pengikatan C ++: interfaces kelas identik, fungsinya sama;
Hanya bahasa yang sedikit berbeda.

Kode C ++ sebelumnya di sini diterjemahkan untuk EyeDB Java API:

 Seperti ditunjukkan pada contoh ini, kodenya benar-benar identik kecuali bahwa beberapa -
> di C ++ diganti dengan a. Karakter di Java

 Satu-satunya perbedaan yang tidak muncul dalam contoh kita adalah manajemen memori
objek.

 Dalam contoh C ++, seseorang harus melepaskan semua objek yang dialokasikan; Tidak perlu
di java.