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 Object-Oriented Databases Databases Design and Implementation: Implementation: OMS Avon
OMS Avon
OMS Avon adalah sebuah implementasi sistem manajemen data OMS berdasarkan db4objects objek berorientasi-database. 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/pro http://maven.globis.ethz.ch/projects/avon jects/avon/) /) Java implementasi dari OM data model dan OML OMS Avon Architecture
Storage layer
Mengelola penyimpanan tingkat rendah
package ch.ethz.globis.avon.storage ch.ethz.globis.avon.storage
Model layer
mengimplementasikan mengimplementasikan fungsi yang terkait dengan OM data model
package ch.ethz.globis.avon.om ch.ethz.globis.avon.om
package ch.ethz.globis.avon.oml ch.ethz.globis.avon.oml
Interface layer
menyediakan interface pemrograman pemrograman aplikasi tingkat tinggi
package ch.ethz.globis.avon.omsjp ch.ethz.globis.avon.omsjp
OMS Avon Project Modules
OMS Avon Storage Layer Penyimpanan interface berdasarkan jenis dan informasi unit
jenis unit yang menyediakan menyediakan metadata 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 fungsionalitas dan konsep tingkat tinggi
Internal •
Fungsi internal
•
Fungsionalitas 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 •
Kelas utilitas untuk mengakses dan menafsirkan objek generik •
create, retrieve, update and delete operations
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 aku s dipetakan ke OMSSet
•
Daftar dipetakan ke OMSSequence
•
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 r elasional 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 (F CO)
-
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 K edua (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 bendabenda 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
First class object (FCO) collections -
VVector, VHashtable
Second class object (SCO) collections -
Array, Vector, Hashtable, LinkedList
DVector
Scalable large collections -
LargeVector
ODMG collections
SCALABLE LARGE COLLECTIONS
Classes DVector, VVector dan VHashtable serta koleksi ODMG diimplementasikan di frontend
-
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 * 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:
