ORDBMS

Sesuai dengan Perundang-undangan Privasi Kanada,
beberapa formulir pendukung mungkin telah
dihapus dari disertasi ini.
Meskipun formulir ini dapat dimasukkan dalam
jumlah halaman dokumen, penghapusannya tidak
menunjukkan hilangnya konten dari disertasi.

ORDERS: Sistem Reformulasi Query Database Relasional Objek
Oleh
Lingyan Xu
Sebuah tesis diserahkan ke
Fakultas Studi dan Penelitian Pascasarjana
dalam pemenuhan sebagian dari
persyaratan untuk derajat
Magister Sains
Ilmu Informasi dan Sistem
Institut Ilmu Komputer Ottawa-Carleton
Sekolah Ilmu Komputer
Universitas Carleton
Ottawa, Ontario
2 Juni 2003
© Hak Cipta
2003, Lingyan Xu

Perpustakaan Nasional Kanada
Bibliothèque nationale du Canada
Layanan Akuisisi dan Bibliografi
Bibliografi akuisisi dan layanan
395 Wellington Street Ottawa DI K1A ON4 Kanada
395, rue Wellington Ottawa DI K1Ã 0N4 Kanada
File Anda Referensi Votre
ISBN: 0-612-88788-X
File kami Notre référence
ISBN: 0-612-88788-X
Penulis telah memberikan lisensi non-eksklusif yang mengizinkan Perpustakaan Nasional
Kanada untuk memperbanyak, meminjamkan, mendistribusikan, atau menjual salinan tesis ini
dalam bentuk mikro, kertas, atau format elektronik.
L'auteur a accordé une license non
permetan eksklusif la Bibliothèque nationale du Canada de reproduire, prêter, distribuer ou
vendre des copy de cette thèse sous la forme de microfiche/film, de reproduksi sur papier ou
sur format électronique.
Penulis mempertahankan kepemilikan hak cipta dalam tesis ini. Baik tesis maupun ekstrak
substansial darinya tidak boleh dicetak atau direproduksi tanpa izin penulis.
L'auteur melestarikan la proprieté du droit d'auteur qui protge cette ini. Ni la thèse ni des
extraits substantiels de celle-ci ne doivent tre imrimés ou aturement reproduits sans son
otorisasi.
Kanada

Abstrak
Database relasional objek telah banyak digunakan untuk menyimpan objek kompleks. Efektif
pengambilan informasi dari database objek-relasional dengan struktur database yang kompleks
tures dikenal sebagai masalah non-sepele. Khususnya perumusan valid
query SQL objek-relasional adalah langkah penting untuk akses informasi yang efektif dalam
konteks. Pendekatan yang ada biasanya membutuhkan pengetahuan yang kurang lebih luas
tentang
sistem manajemen basis data, bahasa kueri, dan struktur basis data yang mendasarinya.
tur. Dalamtesis ini kami menyajikan ORDERS, Database Relasional Objek yang mudah digunakan
SistemReformulasi Kueri yang memungkinkan pengguna untuk mengeluarkan pertanyaan dalam
kosa kata mereka sendiri
tanpa pengetahuan luas tentang manajemen basis data, bahasa kueri, dan
struktur database yang mendasarinya, dan secara otomatis menghasilkan SQL objek-relasional
pernyataan untuk dieksekusi.
Dalamsistemini, kami menggunakan tesaurus berbasis ontologi untuk mengaitkan level aplikasi
konsep dengan objek skema database. Berdasarkan asosiasi ini, pencocokan fuzzy
mekanisme yang digunakan untuk memetakan konsep pengguna ke konsep basis data.
Karena pengguna tidak memiliki pengetahuan yang luas tentang struktur database, pengguna
kueri mungkin tidak menentukan semua objek skema yang relevan. Sistem mempertahankan
skema
grafik yang mewakili struktur database berdasarkan skema database, menggunakannya
sebagai peta jalan untuk menemukan objek skema yang tepat dan menemukan jalur kueri yang
optimal untuk final
pernyataan SQL objek-relasional, menggunakan algoritma pencarian luas-pertama.

ucapan terima kasih
Pertama-tama, saya ingin mengucapkan terima kasih kepada Profesor Mengchi Liu, supervisor
saya, atas
bimbingan yang sangat baik, dorongan, daya tanggap, dan dukungan keuangan melalui
penelitian saya. Standar akademiknya yang tinggi telah membuat proses pembelajaran menjadi
berharga
pengalaman yang akan bermanfaat bagi saya selama sisa hidup saya. Saya juga menghargai
tawaran TA dari
sekolah Ilmu Komputer.
Saya jugaingin berterima kasihkepada Tuan Wenjie Tong, Tuan Xiaofei Jiadan Tuan Tao Fu untuk
mereka
bantuan yang baik dan murah hati.
Saya berterima kasih kepada keluarga saya atas dukungan dan pengertian mereka yang
konsisten. Terima kasih
kepada orang tua saya Zhengxian Zhang dan Duanyi Xu, atas dorongan dan dukungan mereka
sepanjang hidupku. Terima kasih khusus kepada suami saya Wenlu Wang, dan putri saya
Janet, atas cinta dan dukungan mereka selama ini.

[01.27, 15/2/2022] 162057 wahyudi: Isi
Abstrak
aku aku aku
ucapan terima kasih
iv
Daftar tabel
vii
Daftar Gambar
viii
1. Perkenalan
1.1 Motivasi. .
1.2 Pernyataan Masalah
1.3 Pendekatan Kami
1.4 Garis Besar Skripsi. . .
2 Pekerjaan Terkait
2.1 Kueri Basis Data pada Tingkat Logis.
2.2 Pertanyaan Konseptual .
2.3 Teknik Akses Data di Tingkat Eksternal
3 Teknologi Obyek-relasional
3.1 Mengapa ORDBMS?
SQL: 1999 Standar dan Oracle9i
V
[01.28, 15/2/2022] 162057 wahyudi: 3.2.1
Fitur 00 baru yang didukung oleh SQL: 1999 dan Oracle9i
18
...
3.2.2 Lebih lanjut tentang Oracle9i

3.2.1
18
...
3.2.2 Lebih lanjut tentang Oracle9i
23
4 Ikhtisar PESANAN
24
4.1 Arsitektur Sistem
24
4.2
Contoh aplikasi
27
5 Skema Grafik
31
5.1
Grafik Skema. .
31
5.1.1
Konsep grafik skema
32
5.1.2 Contoh skema dan diagram grafik skema
34
5.2 Tesaurus dan Mekanisme Pencocokan Fuzzy .
40
5.3 Implementasi Grafik Skema dan Pembuatan Grafik Skema
45

5.4 Properti grafik skema
49
6 Reformulasi Permintaan ORSQL
50
6.1
Generasi pohon kueri.
50
6.1.1 Jalur kueri dan pohon kueri .
50
6.1.2 Konstruksi Pohon Kueri
53
6.1.3
Menangani Predikat Seleksi
58
6.1.4 Optimasi di pohon kueri
59
6.2 Pembuatan kueri ORSQL
61
6.3 Contoh Kueri
65
7 Kesimpulan
71
7.1 Ringkasan
71
7.2 Pekerjaan di masa depan
74
Bibliografi

Daftar tabel
6.1
ORDERS tipe data, SQL:1999, dan pemetaan tipe data Oracle9i ...
63
Vii
Daftar Gambar
3.1 Tampilan grafis atas hubungan dan struktur objek untuk
Contoh Universitas-Departemen-Profesor
21
4.1
ORDER arsitektur
25
4.2 Antarmuka Pengguna Sistem Informasi Cerdas
28
4.3 Arsitektur Sistem Informasi Cerdas
29
5.1
Skema database Kota-Universitas
35
5.2 Grafik skema database Kota-Universitas
36
5.3 Skema untuk database Universitas-Karyawan
37
5.4 Grafik skema untuk database Universitas-Karyawan
38
5.5 Jalur kueri untuk kueri "daftar nama instruktur di Carleton
Universitas"

44
...
5.6 Representasi struktur grafik skema untuk Professor.tab dan
tipenya didefinisikan pada Gambar 5.1
48
6.1 Pohon kueri untuk kueri: sebutkan semua profesor di Universitas Carleton 57
viii

Bab 1
pengantar
1.1
Motivasi
Saat daya komputasi dan kapasitas penyimpanan meningkat, akses dan pemrosesan dalam
jumlah besar
kumpulan data dengan data dan hubungan yang kompleks memainkan peran yang semakin
penting
di banyak domain penelitian ilmiah [1, 31, 43] dan aplikasi database berbasis web.
Dengan dukungan fitur berorientasi objek, seperti referensi objek dan terstruktur
tipe data, model data relasional objek telah banyak digunakan untuk meniru dunia nyata
objek dan hubungan di antara mereka. Sebuah contoh yang luar biasa muncul dalam query
informasi yang direstrukturisasi dari World Wide Web. Pemodelan dan pengorganisasian
data web semi-terstruktur menggunakan teknologi database relasional objek menyediakan
kemampuan untuk mengeluarkan kueri terstruktur terhadap database dengan cara yang tidak
ada
dari metodologi pencarian kata kunci (18, 30]. Proses mengambil informasi
dari database bagaimanapun, adalah kompleks dan menakutkan bagi pengguna database non-
ahli.
Sistem pengambilan data yang ada hampir secara non-eksklusif memerlukan penggunaan kueri
bahasa yang menuntut pengetahuan yang kurang lebih luas tentang Manajemen Basis Data
1

BAB 1 PENDAHULUAN
Sistem (DBMS), sintaks bahasa query, dan struktur database. Sebagai salah satu
bahasa kueri basis data yang paling umum digunakan, SQL memiliki bahasa Inggris yang relatif
sederhana
seperti struktur sintaksis dan semantik. Namun, wajib memiliki pemahaman yang menyeluruh
pengetahuan tentang skema database dan sintaks SQL untuk merumuskan valid
kueri basis data. Kebutuhan informasi yang rumit dan canggih yang dihadapi dalam sains
otomatisasi, bisnis, dan kantor menuntut metode kueri otomatis dan semantik
dalam aplikasi basis data.
Upaya telah dilakukan oleh pengembang aplikasi database dan vendor DBMS
untuk menyediakan metode pemilihan informasi yang disesuaikan pengguna. Solusi seperti
query-
by-form [19] dan Query by Example (QBE) [45] menyediakan antarmuka yang menampilkan
skema yang mendasari melalui formulir atau daftar template. Bahasa kueri konseptual (12] pro-
vide antarmuka untuk memandu pengguna melalui proses perumusan kueri dengan
menampilkan
struktur konseptual database. Dengan menggunakan metode ini, pengguna dapat menavigasi
struktur database dan tentukan kueri mereka dengan memilih dan mengisi kondisi
untuk atribut objek yang diinginkan, dan dibebaskan dari keharusan menghafal database
skema atau belajar tentang aturan sintaks bahasa query yang kaku. Masalah utama
pendekatan ini bagaimanapun, adalah keterbatasan skalabilitas. Ketika struktur
basis data yang mendasarinya menjadi sangat kompleks, tidak mungkin untuk menunjukkan
keseluruhannya
struktur database dalam satu tembakan, dan akibatnya menyebabkan kesulitan bagi pengguna
untuk
menelusuri layar struktur skema demi layar, dan untuk memilih secara manual
objek yang diinginkan. Selanjutnya, tanpa gambaran yang jelas tentang bagaimana benda-benda
tersebut berhubungan dengan
satu sama lain dalam database, akan sulit bagi pengguna untuk menemukan yang benar dan

jalur akses efektif dari satu relasi ke relasi lainnya melalui navigasi buta.
BAB 1 PENDAHULUAN
1.2
Pernyataan masalah
Tujuan dari tugas akhir ini adalah untuk merancang dan mengembangkan objek-relasional yang
mudah digunakan
sistem reformulasi kueri basis data yang memungkinkan pengguna untuk mengeluarkan kueri
dalam pilihan mereka sendiri
cabulary tanpa pengetahuan luas tentang manajemen basis data, bahasa kueri
dan struktur database yang mendasarinya, dan secara otomatis menghasilkan ORSQL state-
ment. Untuk mencapai hal ini, ada dua masalah utama yang harus ditangani. Yang pertama
adalah bagaimana mencocokkan istilah kunci yang diwakili dalam kueri pengguna ke dalam
konsep yang ditentukan
dalam skema database. Masalah kedua adalah bagaimana menghasilkan jalur kueri yang efisien
yang menentukan struktur skema apa yang akan dilibatkan dalam kueri dan urutan
mengaksesnya, dan untuk merumuskan kueri SQL yang valid berdasarkan jalur kueri dan
sintaks SQL.
Menanggapi permintaan untuk merepresentasikan objek dalam database, objek-relasional
sistem manajemen diperkenalkan untuk memperluas model relasional tradisional dengan
fitur 00 baru, seperti tipe data yang ditentukan pengguna, pengidentifikasi objek, dan bawaan
objek
itance, dll. [29, 42]. Dengan menggunakan teknologi objek-relasional, desainer database
mampu memodelkan objek dunia nyata dengan cara yang konkret. Namun, seringkali berbeda
Sulit untuk memetakan istilah kunci dari kueri pengguna ke dalam konsep basis data secara
langsung, karena
pengguna biasanya menggunakan kosakata yang lebih kaya dalam ekspresi mereka. Tanpa
konteks, semantik

ketidakjelasan dalam permintaan pengguna sering menyebabkan masalah dalam penentuan
akurasi
arti istilah yang digunakan dalam kueri mereka.
Selain itu, tanpa pengetahuan yang luas tentang struktur database, pengguna dapat:
tidak dapat menentukan semua objek skema yang relevan dalam kueri mereka. Untuk secara
otomatis
menghasilkan jalur kueri yang membangun bingkai kueri SQL tujuan menjadi-
datang persyaratan yang diperlukan untuk sistem kami. Namun, objek di dunia nyata
terkait secara langsung atau tidak langsung, skema database pasti mengandung struktur
BAB 1 PENDAHULUAN
referensi diri atau referensi melingkar. Untuk memilih jalur kueri yang efektif dan benar
atas database yang kompleks tersebut menjadi tugas nontrivial. Pemilihan jalur kueri
juga menentukan operasi ORSQL yang digunakan dalam kueri, yang menghasilkan per-
formance selama eksekusi query. Untuk meminimalkan biaya eksekusi,
generasi query yang optimal menjadi bagian penting dalam ORDER juga.
1.3
Pendekatan kita
Dalam tesis ini kami memperkenalkan prototipe dan implementasi eksperimental dari
Object Relational Database query Reformulation System (ORDERS), sebagai sebuah heuristik
solusi untuk secara semantik memetakan kata kunci dalam kueri pengguna ke objek skema, dan
secara otomatis menghasilkan kueri ORSQL.
Ketika kita mengeluarkan permintaan ke database, umumnya ada tiga komponen pra-
dikirim dalam pertanyaan: 1) subjek, kategori atau jenis "hal" yang diminati;
2) apa yang ingin kita ketahui tentang subjek; 3) dengan kondisi apa. Sebagai contoh,
pertimbangkan pertanyaannya: temukan nomor telepon dan alamat profesor yang namanya

adalah Smith. Dalam kueri ini, profesor adalah subjek atau kategori, nomor telepon
dan alamat adalah atribut yang ingin kita ketahui tentang profesor, dan kondisi
tion adalah nama Smith. Ide dasar dari pendekatan kami adalah mengambil tiga kueri
komponen sebagai input dan memetakannya ke dalam elemen yang sesuai yang diwakili
dalam klausa SELECT-FROM-WHERE dari pernyataan ORSQL melalui fo-
lowing mappings: atribut-atribut yang diminati dipetakan ke dalam daftar atribut di
klausa SELECT, kondisi diinterpretasikan ke dalam klausa WHERE, dan kategori
gory (subjek) dipetakan ke tabel pertama dalam klausa FROM. Selama pemetaan ini
proses, makna semantik dari permintaan pengguna yang bersangkutan.
BAB 1 PENDAHULUAN
Perumusan ulang kueri pengguna menjadi pernyataan ORSQL yang valid telah
dianggap sebagai prosedur nontrivial. Konstruksi ORSQL yang benar dan efektif
ekspresi selalu melibatkan beberapa proses yang rumit, seperti identifikasi
tabel dan atribut yang relevan, pemilihan jalur akses kueri yang tepat, dan
gen-
erasi pernyataan ORSQL berdasarkan batasan sintaksis yang ditentukan dalam ORSQL.
Langkah-langkah berurutan berikut terlibat dalam:
proses
dari
menghasilkan status ORSQL-
ment dari permintaan pengguna:
1. Ekstrak konsep semantik dari kueri pengguna dan cocokkan dengan yang relevan
tipe, tabel, atribut, dan properti data lainnya yang direpresentasikan dalam database.
2. Tentukan satu set jalur akses kueri yang menentukan objek skema yang relevan
dan urutan untuk mengaksesnya.
3. Merumuskan ulang kueri menjadi pernyataan ORSQL berdasarkan akses kueri

jalur dan sintaks ORSQL.
Pada tahap desain database, persyaratan dari database calon
pengguna biasanya dipertimbangkan dengan cermat sehingga struktur konseptual database
ringkas dapat mewakili domain data dengan penuh hormat ke tampilan pengguna [16].
Oleh karena itu, pengguna dan skema database harus selalu berbagi struktur umum
melihat domain aplikasi sistem, kecuali bahwa pengguna menggunakan lebih kaya
kosakata untuk menjelaskan konsep. Untuk menjembatani kesenjangan antara pengguna dan
database, kami telah membuat tesaurus berdasarkan ontologi yang bergantung pada domain.
Sebuah
ontologi adalah kumpulan konsep dan keterkaitannya yang secara kolektif dapat
memberikan pandangan abstrak atas domain aplikasi [13, 23]. Dalam ontologi ini berbasis
tesaurus, daftar kata-kata terkait dan analog dari konsep-konsep dari ontologi adalah
dipertahankan dan dikaitkan dengan objek skema database yang setara. kabur
mekanisme pencocokan dikembangkan untuk menentukan relevansi antara istilah-istilah kunci
BAB 1 PENDAHULUAN
dari kueri pengguna dan tabel dan/atau atribut dari skema database. SEBUAH
model grafik skema dibuat untuk mewakili struktur database dan
digunakan untuk mencari objek skema terkait secara dinamis. Pencarian luas-pertama
algoritma digunakan untuk menghasilkan jalur akses kueri dengan melintasi grafik skema.
Formulator ORSQL dikembangkan untuk menghasilkan pernyataan ORSQL berdasarkan:
jalur kueri dan sintaks ORSQL.
ORDERS adalah implementasi eksperimental dari model sistem yang dapat
dilampirkan ke databaserelasionalobjek yang kompleks dan secaradinamis merumuskan ORSQL
pernyataan berdasarkan makna semantik dari kueri pengguna. Salah satu aplikasi yang mungkin
kation dari ORDERS akan digunakan sebagai antarmuka back-end untuk informasi cerdas
sistem temu kembali yang didasarkan pada model data relasional objek, seperti

gin untuk data web, sistem informasi otomatis untuk ilmiah yang besar dan kompleks
database.
Kontribusi utama dari tesis ini adalah:
1. Sebuah prototipe heuristik untuk sistem reformulasi query semantik diusulkan dan
diimplementasikan untuk database objek-relasional.
2. Grafik skema diperkenalkan sebagai solusi untuk mewakili struktur database
sebagai peta jalan virtual yang memfasilitasi proses pencarian tabel yang relevan
dan atribut dari database. Fitur dari grafik skema meliputi:
• Grafik skema secara otomatis dibangun dari skema bukan
daripada diprogram sebelumnya. Ketika struktur database yang mendasarinya
perubahan, grafik skema dapat dibuat kembali dengan memulai ulang sistem,
sehingga tidak perlu memprogram ulang seluruh sistem.
• Grafik skema memberikan representasi konkret dari struktur database
ture dan digunakan sebagai peta jalan untuk menemukan objek skema yang relevan dan
: R 1. PENDAHULUAN
jalur untuk mengaksesnya.
• Grafik skema juga mencatat semua meta-data yang diperlukan dalam
Proses pembuatan kueri ORSQL, akibatnya menghilangkan kebutuhan
berkomunikasi dengan server database, dan karenanya mempercepat pengguna
pemrosesan kueri.
3. Mekanisme pencocokan fuzzy dengan tesaurus berbasis ontologi diusulkan
sebagai pendekatan baru untuk mengasosiasikan konsep tingkat aplikasi dengan database
objek skema, yang memungkinkan pengguna untuk mengeluarkan kueri menggunakan istilah
yang mereka kenal.
dengan.

4. Algoritma jalur terpendek digunakan untuk secara otomatis menemukan jalur kueri yang
sesuai
struct bingkai kueri ORSQL tujuan, dan untuk mencapai yang optimal
pembuatan kueri. Jadi pengguna tidak perlu menentukan jalur secara manual.
5. Desain dan implementasi dari generator query ORSQL memberikan solusi
menuju generasi otomatis kueri ORSQL.
1.4
Garis Besar Tesis
Sisa dari tesis ini disusun sebagai berikut: Bab 2 mengulas terkait
bekerja. Bab 3 memperkenalkan beberapa fitur baru ORDBMS dan Oracle9i
sistem. Bab 4 memberikan gambaran singkat tentang sistem ORDER. Dalam Bab 5,
model grafik skema dan struktur data diperkenalkan. Bab 6 menjelaskan
Proses dan algoritma reformulasi query ORSQL. Beberapa pertanyaan sampel juga
diperiksa. Akhirnya, di Bab 7 kami menyajikan kesimpulan dan rencana untuk masa depan
bekerja.
[01.37, 15/2/2022] 162057 wahyudi: Bab 2
Pekerjaan Terkait
Sejak Bachman merancang DBMS umum pertama di awal 60-an [16], database
sistem telah melalui evolusi dramatis. Upaya telah dilakukan untuk menyediakan
antarmuka yang ramah pengguna menuju proses kueri basis data yang lebih mudah. Ada empat
utama
tingkat di mana manusia dapat berinteraksi dengan sistem database [25]:
• Eksternal
• Konseptual
• Logis
• Fisik
Mulai dari bawah, tingkat fisik sangat erat dengan DBMS yang dipilih.
Semua detail tentang penyimpanan fisik dan struktur akses, seperti indeks penyimpanan

catatan, berbagai struktur penyimpanan, apakah akan menggunakan rantai penunjuk atau
hashing, dll.,
didefinisikan pada tingkat ini. Jarang bagi pengguna akhir untuk berkomunikasi dengan sistem
basis data
pada tingkat ini.
BAB 2. KARYA TERKAIT
Tingkat logis mengungkapkan skema konseptual dalam hal struktur data dan
operasi yang didukung dalam model data yang dipilih (relasional, hierarki, dll.). Ini
level selalu melibatkan komunikasi dengan database menggunakan bahasa query, seperti:
seperti SQL, OQL, dll.
Pada tingkat konseptual, informasi dinyatakan dalam bentuk konseptualnya. Menipu-
bahasa query ceptual telah diperkenalkan untuk menulis query ke database.
Pada tingkat eksternal, antarmuka aktual dan representasi input/output adalah
digunakan untuk bekerja secara langsung dengan sistem, misalnya melalui formulir layar atau
dicetak
laporan, dll.
Berdasarkan keempat tingkatan tersebut, bagian berikut memberikan ulasan terkait
bekerja untuk metode asisten kueri database yang ada saat ini. Sejak fisik
level sering berurusan dengan DBMS spesifik dan detail penyimpanan internal, dan akhirnya
pengguna jarang mengakses data secara langsung pada level ini, kami akan fokus pada tiga
lainnya yang lebih tinggi
tingkat, yaitu tingkat logis, tingkat konseptual, dan tingkat eksternal.
2.1
Kueri Basis Data di Tingkat Logis
Pada Level Logika, database direpresentasikan dan diimplementasikan berdasarkan un-
model data utama, seperti model relasional atau berorientasi objek. Informasinya adalah
diekspresikan menggunakan konstruksi logis yang diwakili dalam model data, misalnya, dengan

sarana tabel dan kunci dalam model relasional. Bahasa query logis digunakan
dalam proses pengambilan data dan manipulasi data [16, 25].
Diantara model data yang berkembang pada tahun 70-an yaitu model relasional,
model jaringan, dan model hierarkis, model relasional telah
dianggap sebagai yang paling banyak digunakan dalam DBMSS komersial. SQL, QUEL, dan
QBE adalah tiga bahasa query database relasional yang telah diimplementasikan
dan didukung oleh produk komersial.
SQL dan QUEL adalah dua bahasa query database yang diimplementasikan sebagai in-
antarmuka ke beberapa DBMSS komersial. Dibandingkan dengan operasi yang didefinisikan
dalam
aljabar relasional dan kalkulus relasional yang mendasar untuk memanipulasi
database relasional, SQL dan QUEL secara sintaksis lebih mirip dengan bahasa Inggris dan
lebih ekspresif. Namun, orang masih perlu dilatih sebelum menulis yang valid
query database dalam bahasa-bahasa ini. Selain itu, pengetahuan penuh tentang database
skema diperlukan untuk menyiapkan kueri yang efisien.
QBE (Query By Example) [45] adalah bahasa query relasional yang mudah digunakan yang
dikembangkan di lembaga penelitian IBM. Ini berbeda dari SQL dan QUEL dalam hal itu
pengguna tidak harus menentukan kueri terstruktur secara eksplisit. Sebaliknya, mereka
merumuskan
query dengan mengisi template relasi yang ditampilkan pada layar terminal.
Dengan menampilkan daftar semua nama relasi di layar, QBE pertama-tama memungkinkan
pengguna untuk
memilih tabel atau relasi yang diperlukan untuk merumuskan kueri. Setelah template untuk
hubungan yang dipilih ditampilkan, pengguna pindah ke kolom yang tepat di template
dan tentukan kueri atau tentukan kondisi menggunakan tombol fungsi khusus. Di dalam
cara, pengguna tidak harus mengikuti aturan sintaks yang kaku untuk spesifikasi kueri, tetapi

untuk membangun contoh yang terkait dengan permintaan dengan memasukkan variabel di
kolom,
dan dengan demikian dibebaskan dari keharusan menyusun seluruh skema dalam pikiran atau
bahkan untuk
mengingat nama tabel atau atribut. Namun, sering kali membosankan untuk menelusuri
template dari satu ke yang lain. Untuk query kompleks yang melibatkan beberapa relasi,
seseorang perlu memilih tabel dengan tangan dan menentukan variabel gabungan di kolom
dari template.
Dengan munculnya generasi database berorientasi objek, DBMSS telah berevolusi
untuk mendukung tipe data yang kompleks dan struktur datayang dapat didekomposisi. Integrasi
bahasa pemrograman dan sistem basis data memberi pengembang aplikasi lebih banyak
kekuatan dan kebebasan untuk memodelkan domain informasi dengan cara berorientasi objek.
Namun, SQL (SQL3) yang diperluas untuk ORDBMS dan OQL untuk berorientasi objek
DBMS sering menyebabkan kompleksitas yang lebih besar dalam perumusan query.
2.2 Pertanyaan Konseptual
Skema konseptual mengungkapkan struktur domain aplikasi dari
perspektif manusia daripada mesin. Ini memfasilitasi komunikasi antara
pemodel dan ahli materi selama proses pemodelan. Diberikan keuntungan
dari hubungan erat antara skema konseptual dan skema database,
banyak bahasa kueri konseptual telah diusulkan untuk memungkinkan pengguna merumuskan
query langsung pada skema konseptual itu sendiri [11, 12]. Namun, sebagian besar lan-
proposal ukuran adalah topik penelitian akademis, dengan dukungan alat prototipe terbaik.
Satu alat komersial, English Wizard, menyediakan beberapa kemampuan bagi pengguna untuk
memasukkan kueri

langsung dalam bahasa Inggris, tetapi alat tersebut saat ini mengalami masalah dengan
ambiguitas, seperti
serta kebenaran generasi SQL-nya [25].
Solusi khas yang diadopsi oleh sebagian besar alat bahasa kueri konseptual untuk mewakili
database ke pengguna akhir menggunakan atribut, yang dapat menyebabkan ketidakstabilan
sejak di-
upeti sering berkembang menjadi entitas atau hubungan sebagai model aplikasi berkembang.
Upaya telah dilakukan dengan memperkenalkan bahasa kueri baru berdasarkan Peran Objek
Pemodelan (ORM) atau Pemodelan Sistem Berorientasi Objek (OSM), yang menggambarkan
domain aplikasi dalamhal objek yang memainkan peran, sehingga menghindari gagasan tentang
atribut. Beberapa bahasa kueri berbasis ORM atau OSM yang paling signifikan
adalah RIDL [32], LISA-D [27}, dan OSM-QL [17]. Meskipun mereka dianggap sangat
kuat dan ekspresif, penggunaannya terbatas karena kurangnya dukungan alat
‘
atau kerumitan dalam antarmuka pengguna [25].
Bahasa query berbasis ORM yang paling baru dikembangkan adalah ConQuer [12]. ko-
dibandingkan dengan bahasa query konseptual lainnya, ConQuer diklaim lebih ekspresif,
lebih mudah bagi pengguna pemula, dan didukung oleh alat komersial yang mengubah konsep
kueri aktual menjadi kueri SQL. Antarmuka tiga panel disediakan oleh ConQuer untuk memandu
pengguna di seluruh konstruksi kueri. Objek disimpan dalam database dan mereka
peran ditampilkan di layar. Pengguna diizinkan untuk memilih objek dan peran
minat, dan klik peran untuk menjelajahi kriteria yang dapat diterapkan pada

obyek. Kueri tipikal dapat dibuat dengan mengklik objek dengan mouse dan
menambahkan kondisi. Pengguna tidak diharuskan untuk terbiasa dengan skema konseptual
atau struktur tabel dalam proses formulasi kueri. Namun, ketika database
menjadi kompleks, pengguna masih dapat dengan mudah tersesat karena harus menjelajahi
objek dan mereka
peran secara manual.
2.3
Teknik Akses Data di Tingkat Eksternal
Pada tingkat eksternal, alat kueri basis data sering terlibat dalam komunikasi
antara pengguna dan sistem informasi. Kueri berdasarkan formulir adalah solusi tradisional
yang memungkinkan pengguna untuk mengeluarkan kueri secara langsung pada formulir layar.
Bentuknya biasanya mencerminkan
skema database yang mendasari dengan bidang yang dapat diisi oleh pengguna dengan
persetujuan
nilai atau kondisi yang sesuai. Antarmuka berbasis formulir ini sangat cocok untuk kueri
sederhana
tanpa operasi kompleks yang terlibat, dan ruang lingkup kueri terlihat pada satu
layar. Namun, solusi ini tidak berfungsi dengan baik untuk mengekspresikan kueri yang rumit.
Selain itu, pengguna akan menderita rasa sakit yang sama seperti di QBE karena mereka harus
menjelajah
skema berbasis formulir secara manual dan tersesat ketika struktur datanya jauh
kompleks.
UniGuide [19, 18] adalah contoh dari database berbasis bentuk query mesin pencari de-
dikembangkan oleh Enguix et. Al. Ini menyimpan data "Universitas Australia" dalam objek-
basis data relasional. Dua set antarmuka pengguna disediakan secara terpisah untuk sederhana

kueri yang melibatkan satu entitas atau satu set, dan untuk kueri kompleks yang memiliki lebih
banyak
dari satu set atau entitas yang terlibat. Untuk pencarian yang kompleks, pengguna perlu
menentukan
pilih daftar, di mana klausa, dan operasi kueri basis data lainnya terdaftar di tingkat lanjut
formulir permintaan. Untuk pengguna akhir pemula, antarmuka itu sendiri menjadi tantangan
teknis
karena antarmuka menggunakan tombol yang disebut secara teknis seperti "Kelompokkan
menurut" atau "Pesan menurut"
untuk mewakili kata kunci kueri dalam SQL. Untuk memahami bentuk dan caranya
untuk menggunakannya, setidaknya diperlukan beberapa pengetahuan dasar tentang SQL.
Dynamic Query [2, 3, 39, 44] adalah metode akses database yang dikembangkan baru-baru ini
yang memberikan umpan balikterus menerus kepada pengguna selamaproses perumusan kueri.
Dynamic Query dirancang sebagai mekanisme untuk memvisualisasikan data multidimensi
dengan antarmuka grafis.Sistemmenyajikan semua opsi yang tersedia kepada pengguna dengan
sarana daftar, bilah geser, tombol, dan widget grafis lainnya yang memungkinkan individu
penyesuaian setiap nilai. Dengan menggunakan metode ini, pengguna dapat menentukan kueri
dengan menggunakan
widget grafis. Hasil yang ditampilkan kemudian diperbarui secara dinamis sehubungan dengan
nilai yang dipilih oleh pengguna.
Pendekatan ini mudah dan cocok selama jumlah di-
menyebutkan cukup kecil. Namun, karena setiap dimensi baru atau properti data baru
membutuhkan komponen antarmuka baru, pendekatan ini tidak berskala dengan baik. Faktanya,
jumlah dimensi yang sering tinggi dengan mudah menghasilkan kompleks dan membingungkan
antarmuka. Antarmuka seperti itu mungkin tidak memberikan masalah bagi pengguna
berpengalaman, tetapi pengguna pemula
kemungkinan besar akan menderita. Masalah lain dengan pendekatan ini adalah bahwa hal itu
tidak dapat diterapkan
ke database besar dengan kinerja yang memadai.

Dalam makalah selanjutnya [14, 34], pendekatan dua fase untuk kueri dinamis diusulkan.
bagian 3
Teknologi Obyek-relasional
Seperti yang diperkenalkan di Bab 1, kami menggunakan Oracle9i
sebuah ORDBMS untuk dijadikan sebagai
ing blok di sistemkami. Dalambab ini, pertama-tama kami memberikan beberapa latar belakang
dari
teknologi objek-relasional, dan kemudian memperkenalkan beberapa fitur baru terkait yang
disediakan
oleh SQL:1999 [15] – standarisasi baru teknologi ORDBMS
dan oleh
Oracle9i [21, 28] sistem manajemen basis data.
3.1
Mengapa ORDBMS?
Keberhasilan DBMSS Relasional dalam beberapa dekade terakhir sudah dikenal luas. Namun,
model data relasional tradisional dan versi SQL sebelumnya dianggap tidak sesuai.
sama untuk mendukung aplikasi database yang kompleks dan canggih. Generasi baru-
asi database telah diperkenalkan untuk memenuhi tuntutan untuk dukungan dari
fitur berorientasi objek di DBMSS. Objek-relasional [40] dan berorientasi objek
database [9] dianggap cocok untuk data yang kompleks karena dukungannya
untuk objek kompleks, data multimedia dan pewarisan objek, dll. [42].
15
BAB 3. TEKNOLOGI OBJEK-RELASIONAL
Keinginan untuk mewakili objek yang kompleks telah menyebabkan pengembangan Object-

berorientasi pada Sistem Manajemen Basis Data (OODBMS). Database berorientasi objek em-
menerapkan model data yang mendukung fitur berorientasi objek seperti tipe data abstrak
(ADTS), polimorfisme dan pewarisan, dll. Melalui dukungan unik
pengidentifikasi objek (OIDS), objek yang disimpan dalam database dapat dengan mudah
diidentifikasi,
dan untuk dibagikan dalam jaringan komputasi terdistribusi. Database berorientasi objek
juga memanfaatkan kekuatan bahasa pemrograman berorientasi objek untuk menyediakan
meminjamkan kemampuan pemrograman database. Kombinasi pemrograman 00 dengan
teknologi database menyediakan lingkungan pengembangan aplikasi yang terintegrasi.
Dengan menggunakan 00 bahasa pemrograman, seperti C atau Java, berorientasi objek
aplikasi database dapat mengurangi ukuran kode dengan tidak harus menerjemahkan kode
ke dalam bahasa database seperti SQL atau menggunakan ODBC [5, 35]. Akibatnya, sebuah di-
hubungan langsung dibuat antara model data aplikasi dan database
model data. Koneksi yang kuat antara aplikasi dan database menghasilkan lebih sedikit
pengkodean, struktur data yang lebih alami, dan perawatan yang lebih baik dan dapat digunakan
kembali dari
kode.
Namun, teknologi OODBMS masih muda dan kurang standar. Sampai
baru-baru ini, Grup Manajemen Data Objek (ODMG) telah didirikan untuk mengusulkan
standar untuk OODBS. Penelitian masih diperlukan untuk mengembangkan objek matematika
model yang mendukung karakteristik berorientasi objek (38). Selain itu, tidak kompatibel
Keterkaitan dengan database relasional menyulitkan sebagian besar perusahaan untuk beralih
ke
OODBMS karena investasi besar telah dilakukan di RDBMSS.
Pengembangan sistem manajemen basis data relasional objek adalah hibrid
dari RDBMSS dan OODBMSS. ORDBMSS menggunakan model data yang memasukkan
memasukkan 00 fitur ke dalamRDBMSS, dan dengan demikian memberikan cara yang alami dan
produktif

untuk mempertahankan struktur yang konsisten dalam database. Semua informasi basis data
adalah
disimpan dalam tabel, tetapi beberapa entri tabel mungkin memiliki struktur data yang lebih
kaya, seperti:
sebagai tipe data dan tipe koleksi yang ditentukan pengguna. ORDBMS mendukung
perpanjangan
bentuk SQL yang disebut SQL: 1999 (juga dikenal sebagai SQL3) yang diperkenalkan berikutnya
bagian. Dukungan dari vendor DBMS utama dan fitur OO baru membuat OR-
DBMSS pemimpin pasar. Karena kelebihan ini, database objek-relasional
diharapkan dan membuat dampak yang lebih besar di pasar daripada berorientasi objek
database [29, 42].
Sebagai salah satu vendor RDBMS dan ORDBMS utama, Oracle Corporation memperkenalkan
menghasilkan Oracle8pada tahun 1999, dan merilis Oracle9i pada tahun 2001 yang menawarkan
berbagai struktur data
tures dan kekuatan komputasi yang kuat untuk membuat sistem database yang kuat.
Berdasarkan
pengamatan di atas, kami telah memilih menggunakan database relasional Objek untuk
memodelkan
objek dunia nyata dan hubungan antar mereka, dan menggunakan Oracle9i sebagai database
server untuk sistem informasi kami.
3.2
SQL: 1999 Standar dan Oracle9i
Skema database mewakili sifat struktural dan perilaku dari real-
objek dunia dalam domain tertentu. Dalam model relasional tradisional, ketika struktur
objek dan hubungan di antara mereka menjadi sangat kompleks, objek harus

didekomposisi menjadi banyak tupel yang disimpan dalamtabel yang berbeda. Untuk mengambil
informasi
dari database seperti itu sering melibatkan sejumlah besar operasi gabungan dan
kinerjanya berkurang secara signifikan [10]. Namun, masalah ini telah
diselesaikan dalam SQL: 1999, standar SQL generasi ketiga.
Di bagian ini, pertama-tama kita melihat beberapa fitur baru yang didukung oleh SQL:1999 dan
sistem Oracle9i, seperti tipe data baru dan beberapa fitur 00 lainnya, dan kemudian kami
memperkenalkan beberapa fitur khusus yang disediakan oleh sistem database Oracle9i.
3.2.1
SQL:1999 mendukung dua tipe komposit baru: tipe ARRAY dan tipe ROW, yang
melegalkan keberadaan tabel tidak dalam bentuk normal pertama. Jenis ARRAY memungkinkan
menyimpan koleksi nilai secara langsung di kolom tabel database. Tipe BARIS
memungkinkan untuk menyimpan nilai terstruktur dalam satu kolom database.
Di Oracle9i, tipe VARRAY dan tipe NESTED TABLE didukung untuk
mewakili koleksi alih-alih tipe ARRAY di SQL:1999. Setiap elemen atau nilai
untuk koleksi memiliki tipe data yang sama. Jenis VARRAY atau NESTED TABLE
dapat digunakan sebagai kolom tabel atau sebagai atribut dari tipe objek.
SQL:1999 juga mendukung tipe data yang ditentukan pengguna yang juga disebut sebagai struc-
jenis tured. Tipe terstruktur dapat digunakan sebagai kolom atau sebagai struktur dasar.
jenis "tabel yang diketik". Definisi kolom dari tabel yang diketik diturunkan
dari atribut tipe yang mendasarinya dan karenanya tabel dan tipe data
berbagi definisi dan sifat struktur yang sama. Setiap objek (tupel) dari a
tabel yang diketik dikaitkan dengan identitas unik yang dihasilkan sistem yang berfungsi seperti

pengenal objek (OID).
SQL:1999 menyediakan tipe khusus yang disebut tipe REF yang nilainya OIDS atau ref-
erences objek disimpan dalam tabel diketik. Referensi penting untuk pemodelan
hubungan dan navigasi di antara instance objek. Penggunaan yang canggih dari
Jenis REF adalah mengikuti referensi untuk mengakses atribut objek yang direferensikan
(wasit), yang selalu berupa deretan tabel yang diketik. Akibatnya, nilai REF
type dapat dianggap sebagai penunjuk atau tautan dari satu tupel ke tupel lainnya. Ini
fitur penting yang memungkinkan kita untuk melihat struktur database sebagai di-
grafik yang diluruskan yang simpulnya menunjukkan tipe data yang ditentukan pengguna dan
atributnya, dan
referensi antara jenis bertindak sebagai tepi yang menunjukkan hubungan antara
R 3. JЕСТ-RELASIONAL TEKNOLOGI
objek. Kemampuan untuk membangun hubungan data satu-ke-banyak dan banyak-ke-banyak
tanpa kunci asing relasional mengurangi kebutuhan untuk operasi GABUNG relasional,
karena kolom tabel bisa berisi referensi ke baris di tabel lain. penggunaan
jenis koleksi dan referensi membuatnya tidak lagi menjadi persyaratan untuk relasional
perancang basis data untuk memodelkan objek kompleks dalam komponen paling atomiknya,
tetapi
memungkinkan objek dunia nyata untuk memiliki keberadaan yang konkret. Dengan melakukan
dereferensi atau mengikuti
menurunkan pointer ini, seseorang dapat mengambil baris dari tabel lain tanpa pernah
menggunakan
operator SQL JOIN yang memakan waktu [7].
Notasi penunjuk (→) digunakan dalam SQL: 1999 untuk mengakses atribut OID
nilai yang teridentifikasi dari tipe terstruktur terkait. Di Oracle9i notasi titik ('.') adalah
digunakan sebagai gantinya. Penggunaan dasar dan sintaks tipe REF ditunjukkan di

contoh berikutnya. Untuk membuat tesis ini lebih mudah dibaca, konvensi penamaan berikut:
diikuti dalam contoh:
• Nama tipe data yang ditentukan pengguna semua diakhiri dengan t' (tidak peka huruf
besar/kecil);
• Nama tabel yang diketik semuanya memiliki akhiran 'tab' (tidak peka huruf besar/kecil);
• nama tipe VARRAY diberi nama dengan akhiran v' (tidak peka huruf besar/kecil);
• Jenis tabel bersarang diberi nama dengan akhiran _nt' (tidak peka huruf besar/kecil);
Sekarang perhatikan hubungan antara universitas, departemen universitas,
dan para profesor. Untuk mewakili domain informasi ini, kami memiliki program tabel yang
diketik
tab fessor dari tipe professor.t dengan atribut yang disebut departemen yang mereferensikan
ke baris dalam tabel yang diketik department.tab dari tipe department_t. departemen.t
juga berisi kolom university of REF ke objek dengan tipe university_t di an-
tabel yang diketik lainnya university.tab. Gambar 3.1 menunjukkan tampilan grafik di atas
database
skema. Untuk kueri daftar nama profesor dan nama universitas itu
profesor bekerja, kita dapat mengakses nama atribut objek university_t
dari objek profesor di profesor_tab menggunakan pernyataan SQL:1999:
PILIH p.name AND p.department -> universitas -> nama FROM professor_tab p
atau pernyataan ORSQL dari Oracle9i:
PILIH p.name, p.department.university.name FROM tab profesor p
Perhatikan bahwa dalam klausa SELECT dari dua pernyataan SQL, terdapat akses
jalur yang mengarah ke nama atribut univerity_t dari objek profesor,
yang membawa pemetaan satu-ke-satu antara konsep skema dan akses
urutan dalam kueri basis data. Setelah jalur akses ini telah diidentifikasi, gen-

erasi pernyataan ORSQL kemudian menjadi pekerjaan yang relatif mudah dilakukan.
Hal lain yang ingin kami tekankan adalah disarankan untuk memiliki dua arah
referensi yang didefinisikan dalam skema database untuk setiap pasangan tupel objek terkait
dalam or-
der untuk memastikan aksesibilitas data. Seperti yang ditunjukkan dalam contoh di atas,
tunjukkan
pada Gambar 3.1, setiap objek universitas menyimpan satu set referensi ke semua
departemennya
instance, dan masing-masing objek departemen menyimpan pointer ke yang sesuai
tuple universitas juga.
SQL:1999 dan Oracle9i menyediakan model tipe yang selaras dengan single Java
warisan. Perancang basis data dapat menentukan jenis yang diberikan dapat digunakan atau
tidak (analog dengan tipe abstrak dalam bahasa pemrograman lain) pada saat itu
jenis dibuat. Dan tentu saja, di setiap tempat (misalnya kolom) di mana nilai beberapa
tipe terstruktur diizinkan, nilai dari setiap subtipenya dapat digunakan. Ini menyediakan
substitusi yang ditawarkan oleh teknologi pemrograman berorientasi objek
nama
departemen REF)
nama
profesor REF)
(rangkaian)
(rangkaian)
Universitas_t
Departemen_t
Profesor_t

universitas REF}
departemen REF)
Universitas_tab
Departemen_tab
Profesor_tab
tipe terstruktur
tabel yang diketik
hubungan yang ditunjukkan oleh tipe REF
Gambar 3.1: Tampilan grafis atas hubungan dan struktur objek untuk contoh Universitas-
Departemen-Profesor
Oracle juga menyediakan metode untuk mengkhususkan tipe super ke dalam subtipe ketika itu
berlaku. Fungsi TREAT dari Oracle9i didefinisikan untuk memodifikasi tipe yang dideklarasikan
dari
ekspresi ke tipe tertentu yang biasanya merupakan subtipe dari tipe yang dideklarasikan. Ini
fungsi mencoba memperlakukan instance tipe super sebagai instance subtipe, misalnya
memperlakukan seseorang sebagai mahasiswa. Apakah ini dapat dilakukan dalamkasus tertentu
tergantung pada
apakah orang tersebut benar-benar seorang siswa (atau subtipe siswa, seperti paruh waktu
murid). Jika orang tersebut adalah siswa, maka orang tersebut dikembalikan sebagai siswa,
dengan
atribut tambahan yang mungkin dimiliki siswa. Jika orang tersebut kebetulan bukan seorang
mahasiswa, TREAT mengembalikan NULL.
Misalnya, asumsikan bahwa kita memiliki database dengan Person.t sebagai tipe super
Orang t dan subtipe Student.t. Instance dari kedua jenis disimpan dalam tabel
tab orang. Contoh berikut menunjukkan bagaimana TREAT digunakan dalam kueri untuk
mengambil
semua (dan hanya) instance Student.t dari tabel objek Person.tab dari tipe Person.t.

SELECT TREAT(VALUE (p) As Student t) FROM Person_tab p;
Contoh berikut mengilustrasikan penggunaan fungsi TREAT untuk memodifikasi de-
jenis ekspresi REF yang dideklarasikan dan untuk mengakses atribut dari subtipe yang dirujuk
objek, seperti nomor ID siswa siswa.
PILIH p.name, TREAT(VALUE (p.spouse) AS REF Student_t).sid FROM Person_tab p;
Dalam contoh ini, Person.tab memiliki atribut pasangan yang didefinisikan sebagai referensi
ke objek Person.t. Permintaan di atas mengambil nama orang dan siswa
nomor pasangan orang tersebut. Jika pasangan adalah seorang pelajar, nilai pelajar
nomor dikembalikan, jika tidak, NULL dikembalikan.
teknik yang dijelaskan di atas, database fitur objek murni dibangun di ORDERS
untuk memodelkan objek dunia nyata dan hubungannya. Dalam database yang mendasari
ORDERS, semua tabel bertipe tabel. Referensi objek, yang mewakili
hubungan objek, digunakan di mana saja batasan kunci asing mungkin berlaku.
3.2.2
Lebih lanjut tentang Oracle9i
Selain fitur OO baru yang disebutkan di atas, Oracle9i juga menyediakan
lingkungan pengembangan aplikasi yang komprehensif. Dukungan asli untuk Java dari
DBMS adalah fitur penting lainnya yang menguntungkan pengembangan kueri kami
sistem reformulasi. Oracle9i telah mengembangkan Java Virtual Machine-nya sendiri yaitu
terintegrasi erat dengan mekanisme database untuk kinerja tinggi dan skalabilitas.
Dukungan JDBC dan kamus data dari sistem database Oracle adalah
juga merupakan fitur penting. Tampilan kamus data statis Oracle memungkinkan aplikasi
tion pengembang untuk mengeksplorasi skema database dari berbagai tingkatan. Misalnya, an
Tampilan ALL Xxx menampilkan semua informasi yang dapat diakses oleh pengguna saat ini,
termasuk

informasi dari skema pengguna saat ini serta informasi dari objek di
skema lain, jika pengguna saat ini memiliki akses ke objek tersebut dengan cara memberikan
hak istimewa atau peran. Melalui penggunaan JDBC dan beberapa pandangan dari data dictio-
nary, seperti USER_TYPE dan USER.TYPE-ATTRS, seseorang dapat mengambil nama
dari tipe yang ditentukan pengguna, atributnya, tipe atributnya, dan bahkan warisannya
informasi.
Bab 4Ikhtisar PESANA.
Seperti yang ditunjukkan dalamBab 1, PESANAN dirancang dan diimplementasikan sebagai kueri
sistem formulasi untuk database objek-relasional, yang menafsirkan istilah-istilah kunci
dari kueri pengguna menjadi kueri basis data. Bab ini pertama-tama menjelaskan arsitektur
sistem
tekstur ORDER. Kemudian contoh aplikasi ORDERS, yang disebut Intelligent
Sistem Informasi, diperkenalkan. Akhirnya, beberapa contoh kueri ke Intelijen
Sistem Informasi disajikan untuk mendemonstrasikan input dan output ORDERS.
4.1 Arsitektur Sistem
Dengan dukungan fitur berorientasi objek dan kompatibilitas dengan tra-
database relasional, ORDBMSS dianggap sebagai pilihan yang paling tepat
untuk aplikasi database yang kompleks [40]. Keinginan menyediakan formula ORSQL-
metode asisten untuk database objek-relasional telah menyebabkan pengembangan
PESANAN. Fitur utama ORDERSadalahmerumuskan ulang pertanyaan pengguna secarasemantik
menjadi pernyataan ORSQL. Arsitektur dasar ORDERS ditunjukkan pada Gambar 4.1
BAB 4. GAMBARAN UMUM PESANAN
dengan komponen pemrosesan kueri diwakili dalam persegi panjang tebal.
Permintaan pengguna
Pilihan dari

Jalur Kueri
Kueri SQL
komponen
Tabel Kategori
Pilihan
Generasi
Skema
Grafik
SQL
Penyataan
Inisialisasi
ORDBMS
Skema
DB
Gambar 4.1: Arsitektur ORDER
Dalam sistem ini, grafik skema didefinisikan sebagai grafik berarah yang dibangun
dari skema database untuk mewakili struktur database menggunakan node dan edge.
Ini digunakan dalam ORDER sebagai peta jalan untuk menemukan objek skema yang relevan,
seperti:
tabel, tipe atau atribut yang sesuai dengan permintaan pengguna. Sistem berjalan di atas
database objek-relasional yang skemanya mencerminkan ontologi aplikasi
domain. Setelah database dibangun, grafik skema dibuat secara otomatis oleh
membaca skema dari DBMS. Kemudian sistem siap untuk melayani sebagai ORSQL
perumus kueri seperti yang tercantum di bawah ini:
Sistem ORDER mengambil tiga komponen kueri yang didefinisikan dalam istilah

dari kosakata pengguna sebagai: 1) kategori, 2) daftar atribut minat, dan
3) kondisi. Dua komponen pertama adalah wajib, di mana tanda bintang (*) dapat
digunakan sebagai daftar atribut untuk menunjukkan pengambilan semua informasi yang
tersedia
tentang kategori. Syaratnya bisa opsional. Langkah-langkah berikut terlibat:
untuk menghasilkan kueri ORSQL:
1. Mencari node tabel dalam grafik skema untuk memutuskan salah satu yang
mewakili objek kategori;
2. Menggunakan tabel kategori sebagai titik awal, dapatkan satu set jalur yang menemukan
semua
jenis objek dan atribut yang relevan dengan melintasi grafik skema;
3. Terakhir buat kueri ORSQL sesuai dengan jalur kueri dan
sintaks ORSQL.
Tesaurus berbasis ontologi diadopsi dalam grafik skema untuk memperluas
konsep struktur basis data dengan istilah atau frasa terkait. Mekanisme pencocokan fuzzy
nism digunakan dalam proses menentukan relevansi tabel, tipe atau atribut
didefinisikan dalam database. Dalam kasus lebih dari satu set jalur kueri diidentifikasi,
satu set pernyataan ORSQL akan dihasilkan sebagai hasilnya. Itu diserahkan kepada pengguna
untuk memutuskan kueri mana yang memenuhi permintaan lebih dekat dengan menelusuri yang
diklasifikasikan dengan baik
hasil kueri. Kriteria seleksi semantik didefinisikan dan digunakan dalam proses pencocokan
cess untuk mencegah pemilihan item yang tidak terkait. Akibatnya, semakin spesifik
permintaan input, semakin akurat pernyataan ORSQL.
Dalam implementasi sistem, basis data yang mendasari dibuat menggunakan:
Oracle9i yang sedang berjalan
Mesin Sun Enterprise 250 di bawah operasi Sun Solaris

sistem 2.8. Komponen lain diimplementasikan di JAVA dan dapat dijalankan di mana saja
komputer yang mendukung JDK1.2 (atau lebih tinggi) dan JDBC dengan perpustakaan Oracle
JAVA
diinstal. Sistem terhubung ke database melalui JDBC untuk membaca dan membuat
skema grafik setelah dimulai.
4.2
Contoh aplikasi
Sistem ORDERS telah dirancang sebagai antarmuka back-end ke perangkat cerdas
sistem kueri untuk database relasional objek yang kompleks. Itu dapat dilampirkan ke depan-
prosesor Natural Language (NL) tingkat yang menganalisis dan menguraikan bahasa alami
kueri ke dalam tiga komponen kueri sebagai input ke ORDER. Ada berbagai
Teknik Artificial Intelligent (AI), seperti pengenalan pola bahasa Inggris dan
teknik analisis [22], dapat digunakan untuk mengembangkan antarmuka bahasa alami.
Saat ini kami telah mengimplementasikan contoh aplikasi ORDERS yang disebut Intelli-
Sistem Informasi Gen. Sumber informasi yang mendasarinya adalah objek-relasional
database yang mencakup informasi besar-besaran tentang negara, kota, negara bagian atau
provinsi,
dan universitas di Amerika Utara. Hubungan antara tupel diwakili kita-
ing referensi objek. Sistem Informasi Cerdas mendukung tiga permintaan pengguna
metode, yaitu pencarian kata kunci, pencarian kategori, dan pencarian semantik.
Gambar 4.2 menunjukkan antarmuka pengguna Sistem Informasi Cerdas. Ini-
pencarian mantic memberi pengguna kemampuan untuk mengeluarkan kueri menggunakan
bahasa alami. SEBUAH
penerjemah bahasa alami telah diimplementasikan untuk mengambil pertanyaan dari pengguna
akhir,
mengidentifikasi tiga komponen kueri, dan kemudian meneruskannya ke ORDER untuk
membentuk

pernyataan ORSQL yang sesuai. Setelah pernyataan ORSQL dieksekusi,
hasil kueri diklasifikasikan menurut kategori dan ditampilkan ke
pengguna. Pola kueri bahasa Inggris dikenali oleh penerjemah bahasa alami sehingga
bahwa pengguna dapat menulis kueri tidak hanya menggunakan istilah yang mereka kenal tetapi
juga untuk menyajikannya secara alami. Arsitektur Informasi Cerdas
Sistem ditunjukkan pada Gambar 4.3.
Sistem Inferensi Ingent
Mencari
menjual.
Kategori Pencarian
Scarch Busa
Regienal Asis, Canbbean, Certjal Aierca
Pendidikan Referenca, Konferensi, Pubicaton
masyarakat
Cari Kategori
Capicre Ca00E Semua Hak Raserveti
Gambar 4.2: Antarmuka Pengguna Sistem Informasi Cerdas
Contoh 1: Daftar nama dan situs web universitas di Ottawa
Masukan ke ORDER:
kategori: universitas atribut: nama, situs web
kondisi: [nama kota=0ttawa]
Pernyataan ORSQL dari ORDERS:
PILIH x.NAME,x.SITUS WEB DARI UNIVERSITY_TAB x
DI MANA (UPPER(x.CITY.name) LIKE UPPER('%0ttawa%'))

Contoh 2: Temukan profesor di Universitas Carleton yang minat penelitiannya meliputi:
Basis Data
Pengguna IIS
Pengguna
Prosesor NL
Antarmuka
pertanyaan
komponen kueri
Hasil
pernyataan SQL
Pengontrol
PESANAN
pernyataan SQL
hasil
ORDBMS
DB
Gambar 4.3: Arsitektur Sistem Informasi Cerdas
Masukan ke ORDER:
kategori: profesor
atribut: *

kondisi: [minat penelitian=Database
(DAN) Nama universitas = Universitas Carleton]
PILIH
DARI FACULTY_MEMBER_TAB x
*
WHERE (UPPER (x.RESEARCH) LIKE UPPER(ʻ%Database%')) dan (UPPER (x.
FACULTY_COLLEGE.UNIVERSITY.name) LIKE UPPER ('%carleton%'))
Contoh 3: Temukan negara yang populasinya lebih dari 10 juta
Masukan ke ORDER:
kategori: negara
atribut: *
kondisi: [populasi > 10000000]
PILIH
DARI NEGARA_TAB x
DIMANA ( x.PEOPLE.POPULATION > 10000000)
Bab 5. Grafik Skema
Seperti yang ditunjukkan dalam arsitektur ORDERS pada Gambar 4.1 di Bab 4, skema
grafik memainkan peran penting dalam prosedur pemrosesan kueri. Representasi konkretnya
representasi dari ontologi domain dan struktur database memungkinkan untuk
digunakan sebagai peta jalan untuk menemukan objek skema yang relevan, seperti tabel,

jenis atau atribut yang ditentukan. Dalam bab ini kami memperkenalkan konsep grafik skema
dan struktur data yang digunakan dalam implementasi ORDERS. Pencocokan kabur
mekanisme yang ditentukan untuk menentukan relevansi antara istilah-istilah kunci dari
kueri pengguna dan objek skema juga dibahas.
5.1
Grafik Skema
Untuk memanfaatkan sepenuhnya 00 fitur dan teknik baru yang disediakan
oleh teknologi database objek-relasional, database fitur objek murni dibangun
di ORDERS untuk memodelkan objek dunia nyata dan hubungannya. Di bawahnya
database ORDER, semua tabel bertipe tabel. Referensi objek, yang
31
BAB 5. GRAFIK SKEMA
mewakili hubungan objek, digunakan di mana saja batasan kunci asing mungkin
menerapkan. Grafik skema dirancang sebagai metode untuk secara konkret mewakili database
struktur dan pemetaan antara model database dan model konseptual,
sehingga dapat digunakan sebagai peta jalan untuk menemukan objek skema yang relevan.
Pada bagian ini pertama-tama kami memperkenalkan konsep grafik skema dan sifat-sifatnya.
ikatan. Proses pembentukan grafik skema dibahas. Beberapa contoh database
skema dan diagram grafik skema yang sesuai terdaftar untuk menunjukkan ini
model data.
5.1.1
Konsep grafik skema
Seperti yang disajikan dalam bab-bab sebelumnya, model relasional objek memberikan
cara untuk mewakili entitas atau konsep generik, dan hubungan antar mereka dalam
domain informasi dengan cara berorientasi objek. Representasi alami dari

ontologi domain menyarankan kemungkinan pemetaan istilah kunci yang disajikan dalam
pengguna
query ke dalam konsep database dari skema database. Dalam proses pemetaan ini,
kita membutuhkan struktur data yang menyediakan akses ke struktur database
dan kemampuan untuk secara dinamis mencari tabel dan atribut yang cocok dengan
pertanyaan.
Dalam ORDERS, struktur skema objek-relasional direpresentasikan menggunakan
grafik diarahkan pada tingkat konsep database. Grafik skema didefinisikan sebagai
grafik berarah yang terhubung lemah'di mana node mewakili tabel, objek
jenis dan atributnya (atribut ditampilkan sekali untuk tabel yang diketik dan
tipe terstruktur yang mendasarinya), dan tepi mewakili hubungan antara
node.
1 Graf berarah terhubung lemah jika graf tak berarah yang bersesuaian terhubung [26]. Dalam
domain aplikasi, kami berasumsi bahwa objek secara virtual terkait satu sama lain secara
langsung atau
ER 5. GRAFIK SKEMA
Dari sudut pandang implementasi, grafik skema adalah representasi struktur data.
membenci grafik berarah yang berisi informasi struktural (meta-data) tentang
skema basis data. Secara umum, dua jenis node diwakili dalam skema
grafik: node tabel yang mewakili tabel yang didefinisikan dalam skema database; dan
node Objek Database yang menyajikan tipe terstruktur dan atributnya.
Hubungan antar tipe objek direpresentasikan menggunakan node Database Object
dan tepi. Kecuali tipe terstruktur, ada 4 jenis hubungan yang tersirat oleh:
Node Objek Basis Data:
Atribut dari: menunjukkan node bertindak sebagai atribut dari struktur terkait
Tipe. Dalam tesis ini, kami menyebut salah satu dari jenis node Database Object ini sebagai
simpul atribut.

ISA: menunjukkan hubungan pewarisan antara dua tipe data terstruktur. Itu
subtipe mewarisi semua atribut tipe super, dan memiliki tambahan sendiri
atribut.
• IS OF TYPE: hubungan antara node atribut dan tipe terstruktur
simpul. Ini menunjukkan bahwa tipe host memiliki atribut yang terhubung
tipe terstruktur.
• Hubungan semantik: hubungan antara tipe terstruktur untuk mewakili informasi-
hubungan semantik domain tertentu di antara objek.
Tiga jenis relasi terakhir, yaitu ISA, IS OF TYPE, dan semantic
hubungan, bertindak sebagaimediaantara tipe data abstrak terkait dan menunjukkan hubungan-
kapal ada di dunia nyata. Kami menyebut node Database Object antara sepasang
node tipe terstruktur terkait sebagai node perantara
BAB 5. GRAFIK SKEMA
5.1.2 Contoh skema dan diagram grafik skema
Untuk memberikan tampilan grafis atas struktur data grafik skema, sekarang kita ambil
lihat beberapa contoh dan diagram grafik skema yang sesuai.
Pertimbangkan kota-Universitas yang disederhanakan don
yang melacak kota dan uni-
objek versi, properti kota dan universitas, seperti namanya," the
pendaftaran (jumlah siswa terdaftar), dan departemen universitas, the
profesor untuk setiap departemen, dll. Ada lima tipe data yang dirancang pengguna yang
ditentukan
dalam database ini: city.t, university-t, registration_t, department.t dan professor.t; dan
empat tabel yang diketik: city.tab, university.tab, department.tab, dan professor_tab. Untuk
menjaga

contoh sederhananya, kita asumsikan rektor sebuah universitas adalah profesor
Tipe. Skema database ditunjukkan pada Gambar 5.1.
Berdasarkan definisi tabel dan tipe data yang ditentukan pengguna, skema
grafik database ini ditunjukkan pada Gambar 5.2. Notasi yang digunakan dalam diagram ini
didefinisikan sebagai berikut: node dalam bentuk persegi panjang tebal mewakili tabel,
node dalam bentuk persegi panjang polos mewakili tipe terstruktur, elips di
diagram bertindak sebagai atribut dari tipe terstruktur, dan persegi panjang bersudut bulat
singkatan dari hubungan IS OF TYPE atau hubungan semantik antara terstruktur
jenis yang merupakan salah satu dari jenis REF atau kumpulan REFS. Label simpul berfungsi
sebagai tabel
nama, nama jenis atau nama atribut. Untuk node atribut, selain atribut
nama, jenisnya juga ditampilkan dalam tanda kurung. Tepi dalam grafik menghubungkan node
sesuai dengan skema database dan mendemonstrasikan properti dari tipe objek
dan hubungan antar tipe objek. Tepi panah tunggal mewakili
atribut bernilai tunggal, dan tepi panah ganda menunjukkan multi-nilai
atribut atau koleksi.
Hubungan ISA mewakili cara di mana objek dikategorikan ke dalam
BAB 5. GRAFIK SKEMA
Universitas_tab
Kota_tab
Universitas_t
kota_t
nama: universitas string:
name:string website:string president: REF professor_t pendaftaran:
Universitas REFS_t

pendaftaran_t departemen: REFS departemen_t kota:REF kota_t
Pendaftaran untuk
part_time_st: NUMBER full_time_st:
NOMOR
Departemen_t
nama : program string : universitas string: REF university_t profesor: REFS profesor_t
Profesor_t
nama:string email:string
departemen: departemen REF_t
Profesor_tab
Departemen_tab
Gambar 5.1: Skema database Kota-Universitas
ER 5. GRAFIK SKEMA
Universitas_tab
tab kota
kota
nama
(REF)
(rangkaian)
nama
(rangkaian)

situs web
universitas
(REF_NT)
kota untuk
(rangkaian)
Universitas_t|
part_time_st (angka)
pendaftaran
Pendaftaran_t
(pendaftaran_t)
full_time_st (angka)
Universitas
departemen (REF_NT)
(REF)
nama
presiden (REF)
(rangkaian)
program (string)
surel
Seorang Profesor_t
profesor (REF_NT)
(rangkaian)
Departemen_t
nama
departemen
(rangkaian)
(REF)

Departemen_tab
Profesor_tab
simpul tipe yang ditentukan pengguna
simpul atribut konkret
simpul meja
hubungan bernilai tanda
hubungan multi-nilai
simpul atribut relasional
relasi tipe tabel
Gambar 5.2: Grafik skema database Kota-Universitas
R 5. GRAFIK SKEMA
subtipe. Objek subtipe mewarisi struktur atasan umum mereka
(tipe super) dan biasanya memiliki properti tambahan yang tidak dimiliki oleh induk generik.
Berikut ini adalah contoh sederhana yang menggambarkan representasi hierarki
struktur menggunakan grafik skema. Sekarang pertimbangkan universitas-departemen-
karyawan
domain. Dalam contoh ini, tipe employee.t memiliki dua subtipe, staff_t adalah singkatan dari
staf administrasi, dan tipe professor.t mewakili profesor atau instruktur di
sebuah universitas. Gambar 5.3 menunjukkan skema untuk contoh ini.
Universitas_t

tab_karyawan
nama:departemen string: departemen REFS_t
Universitas_tab
karyawan_t
nama:telepon string:departemen string:REF department_t
Departemen_t
nama: universitas string: karyawan REF university_t: REFS emloyee_t
Departemen_tab
Profesor_t
Staf_t
kursus: string
kantor: string
Gambar 5.3: Skema untuk database Universitas-Karyawan
Catatan dalam database ini, professor.t dan staff.t didefinisikan sebagai spesialis
Employee.t dengan menambahkan atribut tambahan seperti mata kuliah yang diajarkan
profesor-
ing atau lokasi kantor staf. Hanya ada satu Employee.tab yang didefinisikan untuk disimpan
objek karyawan. Instance profesor dan staf tidak lagi disimpan secara terpisah
di professor.tab atau di staff_tab, tetapi disimpan di employee.tab dari tipe super
BAB 5. GRAFIK SKEMA
Universitas_tab
universitas_t
tab_karyawan
nama
(rangkaian)

departemen (REF_NT)
Universitas
(REF)
nama
(rangkaian)
departemen (REF)
karyawan
karyawan_t
Departemen_tab
departemen_t
(REF_NT)
telepon (tali)
nama
(rangkaian)
kursus
(rangkaian)
kantor
(rangkaian)
staff_t
profesor_t
simpul meja
hubungan pewaris

relasi tipe tabel
adalah
Gambar 5.4: Grafik skema untuk database Universitas-Karyawan
R 5. GRAFIK SKEMA
karyawan.t.
Gambar 5.4 menggambarkan grafik skema untuk database Universitas-Karyawan. Itu
subtipe professor_t dan staff_t terhubung ke Employee_t tipe super mereka melalui
hubungan ISA. Atribut tambahan dari subtipe ditampilkan di node atribut
yang terhubung dengan subtipe.
Dalam diagram grafik skema, atribut sistem DBMS didefinisikan jenis,
seperti NOMOR, CHAR atau VARCHAR2, dll., Disebut sebagai atribut konkret
node, dan ditampilkan dalam elips, seperti node nama dan node situs web
universitas t pada Gambar 5.2. Node atribut lainnya dan node relasi ISA, adalah
contoh node perantara. Node semacam ini ditampilkan di sudut bulat
persegi panjang atau segitiga dalam diagram grafik skema, seperti node presiden dan
node pendaftaran pada Gambar 5.2, dan node ISA pada Gambar 5.4.
Seperti yang ditunjukkan dalam contoh di atas, grafik skema dibangun di atas dan dengan baik
sesuai dengan skema database yang mewakili pandangan konseptual umum atas
domain informasi. Dalam sistem ORDER, grafik skema bertindak sebagai peta jalan
yang dapat digunakan untuk menemukan tabel dan atribut yang relevan. Namun, yang
diharapkan
pengguna menggambarkan konsep domain menggunakan kosakata yang lebih kaya daripada
yang digunakan dalam
skema basis data. Untuk mengidentifikasi secara semantik tabel, tipe, dan atribut yang
mencocokkan permintaan pengguna bukanlah tugas yang mudah. Dalam sistem kami, kami
membangun tesaurus yang

menggambarkan dunia target dalam istilah pengguna dan digunakan untuk memetakan kueri
pengguna ke dalam
konsep dari skema database.
BAB 5. GRAFIK SKEMA
5.2
Tesaurus dan Mekanisme Pencocokan Fuzzy
Mengizinkan pengguna untuk mendefinisikan kueri dalam istilah kosakata mereka sendiri adalah
hal yang penting
fitur ORDER. Untuk mendukung fitur ini, tesaurus yang bergantung pada ontologi adalah
didirikan untuk menjembatani kesenjangan antara kosakata yang berbeda yang digunakan oleh
pengguna dan database.
Ontologi biasanya didefinisikan sebagai spesifikasi eksplisit dari konseptualisasi (13,
23, 24]. Istilah ini dipinjam dari filsafat, kata Yunani ontos (makhluk), di mana
ontologi adalahpenjelasan sistematis tentang keberadaan atau keberadaan. Ketika pengetahuan
tentang
domain direpresentasikan dalam formalisme deklaratif, himpunan objek yang dapat
diwakili disebut alam semesta wacana. Kumpulan objek ini dan yang dapat dideskripsikan
hubungan di antara mereka tercermin dalam kosakata representasional. Bermacam-macam
tesauri dan ontologi, seperti WordNet [33] dan Sensus [41], didefinisikanuntuk mengekspresikan
berbagai hubungan antara konsep domain (misalnya sinonim, antonim, dll.),
dengan atau tanpa deskripsi eksplisit dan formal tentang makna konsep.
Dalam penelitian kami, ontologi dianggap membuat kerangka umum untuk semua atau
sebagian besar kategori yang dihadapi oleh keberadaan manusia dalam domain atau alam
semesta tertentu

dari wacana. Konstruksi ontologi biasanya dilakukan oleh pakar domain yang
memiliki penguasaan atas konten spesifik domain. Dalam implementasi kami saat ini,
ontologi demonstrasi dianggap berdasarkan pemahaman umum untuk
contoh domain.
Tesaurus biasanya disebut sebagai buku sinonim, sering kali termasuk
kata dan antonim yang terkait dan kontras. Dalam sistem Information Retrieval (IR),
tesaurus didefinisikan sebagai struktur data yang terdiri dari (1) daftar yang telah dikompilasi
sebelumnya
kata-kata penting dalam domain pengetahuan tertentu, dan (2) untuk setiap kata dalam daftar
ini, a
kumpulan sinonim dan frasa terkait. Menurut Foskett [6, 20], sebuah tesaurus dapat menjadi
CНАPТER 5. GRAFIK SKEMA
digunakan (a) untuk menyediakan kosakata standar untuk pengindeksan atau pencarian; (b)
untuk membantu pengguna
untuk menemukan istilah untuk formulasi kueri yang tepat; dan (c) untuk menyediakan hierarki
yang diklasifikasikan
yang memungkinkan perluasan atau penyempitan permintaan kueri saat ini sesuai dengan
kebutuhan pengguna. Dalam model kami, struktur tesaurus menyediakan serangkaian istilah
atau
konsep yang memperluas pemilihan struktur database yang cocok.
Definisi tesaurus dapat bersifat umum atau ditentukan untuk
domain pengetahuan tertentu. Pemilihan tesaurus harus didasarkan pada:
domain dari database yang mendasari yang dirancang untuk mencerminkan konsep ontologi
dan tujuan aplikasi. Jadi dalam sistem kami, tesaurus dibangun
sebagai struktur yang mengaitkan nama tabel unik, nama tipe data, dan

nama atribut dalam skema dengan daftar sinonim. Daftar sinonim kata a
konsep basis data berisi kosa kata yang melaluinya konsep tersebut direpresentasikan
dalam database melalui tabel, tipe, dan atribut, dapat dicocokkan dengan pengguna
permintaan. Setelah urutan mengakses objek skema yang relevan ditentukan,
Pernyataan ORSQL dihasilkan untuk mengambil nilai yang disimpan dalam database. Untuk
contoh, jika kita membangun database yang domainnya berfokus pada universitas di Utara
Amerika untuk pengguna basis data non-ahli, kami akan menggunakan tesaurus khusus domain
untuk
perluas kumpulan istilah yang didefinisikan dalam skema menggunakan istilah terkait yang
diperoleh dari
ontologi, misalnya, menggunakan profesor, anggota fakultas, guru, instruktur, dan mereka
bentuk jamak sebagai sinonim untuk tipe node Professor_t. Saat kita bertemu
pertanyaan seperti: daftar semua anggota fakultas departemen ilmu komputer, frasa
anggota fakultas akan diakui sebagai sinonim profesor dan dipetakan ke dalam
profesor.t dalam database. Dan dengan demikian akhirnya menghasilkan pernyataan ORSQL
yang mengambil informasi tentang semua karyawan yang mengajar di departemen
ilmu Komputer.
Karena pengguna tidak mengeluarkan kueri dalam konsep basis data, kami menyajikan
pencocokan fuzzy
CНАРТER 5. GRAFIK SKEMA
mekanisme untuk memetakan istilahdari permintaan pengguna ke objek skema berdasarkan on-
tologi. Metode ini terdiri dari dua bagian: satu adalah penggunaan berbasis ontologi
tesaurus yang kami jelaskan di atas untuk mengaitkan konsep ontologi dengan
ing konsep skema, yang lain adalah definisi kendala seleksi untuk menambahkan con-
strain untuk menunjukkan ambiguitas semantik dan untuk mencegah kemungkinan salah
interpretasi.

Kendala seleksi terkait dengan sinonim dari aplikasi do-
main dan dicatat di setiap node objek skema. Dalam proses penentuan
relevansi objek skema, informasi ini diperiksa.
Perhatikan bahwa dalam banyak kasus kata kunci dapat diwakili dalam beberapa daftar sinonim
dan mengacu pada beberapa konsep ontologi. Terkadang istilah-istilah ini umumnya disebut
untuk sesuatu yang sangat terkait atau objek dari kategori yang sama secara nyata
dunia, dan karenanya ambiguitas disajikan. Untuk mencegah hilangnya data dan miss-
interpretasi kueri, kami menambahkan dua jenis batasan semantik ke daftar sinonim
untuk konsep skema yang memiliki ambiguitas semantik yang disajikan. penggunaan dari
tesaurus dan batasan semantik disajikan sebagai mekanisme pencocokan fuzzy
di ORDER untuk memperluas pemilihan node yang relevan dan untuk mengesampingkan yang
tidak relevan
node dengan memeriksa kriteria semantik.
Misalnya, kata fakultas terkadang mengacu pada departemen, dan terkadang
mengacu pada anggota fakultas. Oleh karena itu dapat dianggap sebagai sinonim baik untuk
departemen dan untuk profesor. Pertimbangkan pertanyaannya: daftar fakultas yang
menawarkan database
kursus, kata "fakultas" dalam kueri ini secara semantik tidak jelas. Tanpa konteks, itu adalah
sulit untuk menentukan apakah kita harus menafsirkan kueri untuk mengambil profesor
yang mengajar kursus atau departemen yang menawarkan kursus database. Prinsip kami
untuk ini adalah untuk mengambil informasi selengkap mungkin, sehingga kedua hal di atas
query harus dipertimbangkan dan dirumuskan kembali ke dalam pernyataan ORSQL. Dalam
BAB 5. GRAFIK SKEMA
implementasi, batasan "SEE.ALSO" ditambahkan ke daftar sinonim dari pro-
fessor_t dan departemen.t untuk menunjukkan ambiguitas kata fakultas. Di
kasus khusus ini, string "faculty SEE_ALSO professor_t" disertakan dalam

sinonim daftar department.t, dan string "faculty SEE_ALS0 department.t" adalah
termasuk dalam daftar sinonim profesor.t. Pada tahap mencari yang relevan
konsep skema, setiap kali kendala "LIHAT JUGA" ditemui,
tipe objek yang diikuti dengan cermat dianggap sebagai simpul yang relevan dengan kueri.
Setelah
Pernyataan ORSQL dihasilkan dan dieksekusi, hasilnya harus ditampilkan dalam bentuk yang
berbeda
cluster, sebagai informasi untuk profesor dan informasi untuk departemen, sehingga
pengguna dapat dengan mudah menavigasi melalui hasil dengan kategori yang berbeda.
Di atas adalah batasan semantik yang didefinisikan untuk memperluas kueri pengguna
untuk mendapatkan informasi selengkap mungkin. Ada juga situasi yang
ambiguitas dapat menyebabkan kesalahan semantik dalam proses terjemahan kueri. Sebagai
contoh,
pertimbangkan kueri terhadap skema yang ditunjukkan pada Gambar 5.1 dan Gambar 5.2:
daftarkan
nama instruktur di Carleton University. Ambil universitas sebagai kategori, jika
kami mencari simpul yang daftar sinonimnya berisi kata instruktur, sinonim
dari tipe node professor.t, kita akan berakhir dengan beberapa jalur yang mengarah ke
Profesor.t as
Universitas -> Presiden → Profesor → Nama,
dan jalan
Universitas → Jurusan → Jurusan_t → Profesor → Profesor t -→ Nama,
antara mana jalur kedua adalah yang benar dan harus digunakan untuk menghasilkan
Pernyataan ORSQL (Gambar 5.5).
Untuk menghindari masalah pemilihan jalur kueri yang tidak akurat, kriteria semantik adalah:
ditambahkan ke daftar sinonim dalam struktur simpul. Definisi semantik

BAB 5. GRAFIK SKEMA
tab universitas
Kota_tab
kota
nama
(REF)
(rangkaian)
nama
(rangkaian)
universitas
situs web (string)
(REF_NT)
kota_t
Universitas_t|
part_time_st {angka)
pendaftaran
Pendaftaran_t
(pendaftaran_t]
departemen (REF_NT)
penuh waktu_st {angka)
Universitas
(REF)
nama
Presiden
(rangkaian)
(REF)
program

surel
(rangkaian)
profesor (REF_NT)
Profesor_t
{rangkaian)
Departemen_t
nama
{rangkaian)
departemen (REF)
Departemen_tab
Profesor_tab
simpul meja
relasi tipe tabel
jalur kueri yang benar
jalur kueri yang salah
---->
Gambar 5.5: Jalur kueri untuk kueri "daftar nama instruktur di Universitas Carleton"
BAB 5. GRAFIK SKEMA
kriteria mencerminkan makna semantik dari struktur yang ditentukan pengguna yang sesuai,
dan mempersempit pemilihan node yang cocok selama pencarian. Untuk di atas

Misalnya, kata presiden dan sinonimnya didefinisikan sebagai kriteria untuk
pemilihan atribut Presiden node University.t, sehingga Presiden
node atribut dapat dipilih dalam jalur kueri jika dan hanya jika kata presiden atau
istilah yang setara secara khusus ditentukan dalam permintaan pengguna.
Melalui penggunaan mekanisme pencocokan fuzzy yang didefinisikan dalam hal
tesaurus dan batasan semantik, sistem mampu menangani kueri
didefinisikan dalam terminologi yang akrab dengan pengguna, sehingga pengguna dibebaskan
dari keharusan menulis kueri dalam jargon teknis, atau harus menavigasi database
skema dan tentukan jalur kueri secara manual.
5.3
Implementasi dan Pembuatan Grafik Skema
tion Grafik Skema
Struktur adjacency [36] diadopsi untuk mengimplementasikan grafik skema di mana
semua adjacencies secara eksplisit dicatat sebagai pointer dalam wadah untuk setiap node.
Wadah dapat berupa vektor atau larik; orde relatif dari unsur-unsur dalam
wadah tidak penting.
Sesuai dengan dua jenis node yang direpresentasikan dalam grafik skema, dua
kelas node dibuat untuk mengimplementasikan model data. Salah satunya adalah kelas simpul
tabel
yang mewakili tabel yang diketik. Yang lainnya adalah kelas simpul Objek Database yang
mewakili tipe terstruktur atau atribut tipe terstruktur. Sebuah node tabel memiliki
bidang berikut: bidang NAMA untuk nama tabel, bidang ALIAS untuk
daftar sinonim, dan bidang TYPE menyimpan pointer ke tipe terstruktur yang sesuai
BAB 5. GRAFIK SKEMA
simpul dari tabel. Node Objek Database menyimpan informasi berikut: sebuah NAMA

bidang mencatat nama jenis atau atribut, bidang JENIS menyajikan jenis
node, seperti tipe yang ditentukan pengguna atau tipe REF, dan bidang ALIAS. Itu
bidang alias dalam simpul Objek Database mencantumkan sinonim dari tesaurus untuk
jenis atau atribut yang sesuaiyang direpresentasikan dalamskema. Alias dari simpul tabel adalah
terdiri dari kumpulan sinonim dari tipe terstruktur dan sinonim
dari semua subtipe di sepanjang hierarki tipe. Kedekatan antar node, mis.
hubungan antara tipe dan atributnya, direpresentasikan sebagai pointer ke yang lain
Node objek basis data. Dengan demikian, node tabel diwakili oleh catatan:
NAMA TABEL TABLE.TYPE (penunjuk ke node Objek Database) ALIAS
Dan setiap node Database Object direpresentasikan sebagai record dari form:
Nama Jenis Alias Berdekatan. Node (penunjuk)
Dalam implementasi ORDERS kami mengaitkan frasa terkait dari
tesaurus dengan skema database, misalnya, untuk mendefinisikan informasi alias
sebagai KOMENTAR untuk setiap tabel, tipe terstruktur, dan atribut. Pada tahap
membangun grafik skema, bidang alias dari setiap node secara otomatis dimuat dengan
informasi struktural database lainnya dari skema.
Dua hashtables digunakan untuk menyimpan objek node tabel dan Objek Database
untuk akses mudah. Nama-nama node berfungsi sebagai kunci. Setelah pengaturan
grafik skema, yang telah menangkap semua informasi struktural skema yang diperlukan dan
istilah terkait kueri yang diperluas, ORDER kemudian siap berfungsi sebagai ORSQL
perumus kueri untuk basis data relasional objek yang mendasarinya. Berikut ini adalah
algoritma yang digunakan untuk membuat grafik skema:
CHАРТER 5. GRAFIK SKEMA
Skema algoritmaGraph():
Masukan: nol.

Output: Grafik skema G.
1. Inisialisasi dua tabel hash kosong: satu untuk objek node tabel dan satu untuk Database
Node objek.
2. Buat koneksi ke DBMS melalui JDBC.
3. Buat node tipe terstruktur dengan menanyakan USER.TYPES dan USER.
TYPE ATTRS tabel dalam kamus data dan mengambil nama jenis, di-
nama upeti, jenis atribut. Hubungan antara node tipe terstruktur
diimplementasikan dengan menambahkan node perantara yang sesuai. Nilai dari
field type diperoleh dari kolom pertama dari tabel datatype-mapping (Ta-
ble 6.1) sesuai dengan jenis atribut yang didefinisikan dalam skema. alias
bidang setiap node objek database diisi dengan membaca yang sesuai
KOMENTAR dari kamus data.
4. Buat objek node tabel dengan mengeksekusi pernyataan SQL yang mengambil semua
pengguna
mendefinisikan tabel dari USER.ALL.TABLES dalam kamus data, dan menambahkan
pointer ke objek tipe terstruktur yang sesuai. Bidang alias berisi
alias dari tipe terstruktur dan alias dari semua penerusnya.
5. Grafik skema dibangun dan koneksi ke DBMS ditutup.
Gambar 5.6 mengilustrasikan representasi struktur grafik skema untuk
Professor.tab dan node tipenya didefinisikan pada Gambar 5.1 dengan nilai untuk field yang
ditampilkan.
Perhatikan bahwa batasan SEE_ALSO disajikan di bidang alias dari professor.t
simpul. Node yang berdekatan ditunjukkan oleh panah melengkung.
ER 5. GRAFIK SKEMA
TIPE NODE
NODE TABEL
NAMA: departemen_t

TABLE_NAME :professor_tah
JENIS: tipe_pengguna
TABLE_TYPE: profesor_t
ALIAS: profesor,
ALIAS:profesor, instruktur,
instruktur, guru, fakultas SEE_ALSO department_t, anggota fakultas
guru,
anggota dewan
ADJACENT_NODES:
nama
surel
KODE ATRIBUT
departemen
NAMA: nama
JENIS: string
KODE ATRIBUT
KODE ATRIBUT
Nama alias
NAMA: email
NAMA: departemen
ADJACENT_NODES: NULL:
JENIS: string
JENIS: REF
ALIAS: departemen, fakultas, sekolah
ALIAS: email
ADJACENT_NODES: NULL:
ADJACENT_NODES: departemen_t

Gambar 5.6: Representasi struktur grafik skema untuk tab Profesor dan tipenya yang ditentukan
pada Gambar 5.1
BAB 5. GRAFIK SKEMA
5.4 Properti grafik skema
Berikut ini adalah ringkasan singkat dari properti yang disajikan dalam grafik skema:
1. Graf skema adalah graf berarah terhubung yang merepresentasikan struktur
dari database yang mendasarinya, dan digunakan sebagai peta jalan virtual untuk pencarian
objek yang relevan dalam database.
2. Tesaurus berbasis ontologi dan batasan seleksi semantik memberikan fuzzy
mekanisme pencocokan untuk memperluas atau mempersempit pemilihan skema yang relevan
konsep.
3. Model data ini merekam semua metadata skema yang diperlukan untuk menghasilkan ORSQL
pernyataan.
4. Informasi yang direpresentasikan dalam grafik skema tersedia dari
kamus data atau telah dikaitkan sebelumnya dengan objek skema dari
DBMS, sehingga pengaturan grafik skema dapat dilakukan secara otomatis.
Selama proses perumusan ulang kueri, ORDERS terhubung ke ORDBMS
ketika itu dimulai. Setelah grafik skema dibuat, koneksi
ke server database terputus. Karena grafik skema telah mengumpulkan semua
informasi yang diperlukan untuk memformulasi ulang kueri pengguna menjadi kueri ORSQL,tidak
ada
perlu terhubung ke server database selama proses pembuatan kueri, dan dengan demikian
menghilangkan komunikasi dengan sistem manajemen basis data dan mengurangi

lalu lintas jaringan lokal antara server database dan ORDER.
Bab 6.Reformulasi Permintaan ORSQL
Penggunaan grafik skema telah menyediakan cara untuk mencocokkan istilah dari permintaan
pengguna ke dalam
objek skema yang relevan. Langkah selanjutnya adalahmelintasigrafik skema untuk menentukan
tabel, tipe data, dan atribut yang relevan, serta urutan cara
mengakses mereka. Setelah jalur akses yang akurat dan efektif ditentukan,
Generator kueri ORSQL dipanggil untuk merumuskan kueri basis data berdasarkan:
sintaks ORSQL. Bab ini menjelaskan prosedur pemilihan akses
jalur dan proses pembuatan kueri ORSQL. Bab ini diakhiri dengan beberapa
contoh yang menggambarkan proses reformulasi ORSQL dalam kasus kueri yang berbeda.
6.1
Pembuatan pohon kueri
6.1.1 Jalur kueri dan pohon kueri
Pembuatan kueri ORSQL dimulai dengan tiga parameter yang diteruskan ke OR-
DERS, yang sesuai dengan tiga komponen yang disajikan dalam kueri pengguna, yaitu:
50
BAB 6. REFORMULASI QUERY ORSQL
1. kategori subjek kalimat,

2. daftar atribut yang mungkin, atau tanda bintang (*) untuk mengambil semua yang tersedia
informasi tentang subjek yang disimpan dalam database,
3. kondisi didefinisikan dalam pasangan atribut dan nilai.
Koma (,) digunakan dalam daftar atribut untuk memisahkan atribut. Format untuk
definisi kondisi dijelaskan dalam Bagian 6.1.3. Dalam basis data target
query, nilai parameter (1) dipetakan ke nama tabel pertama di FROM
klausa, dan atribut yang mungkin disajikan dalam parameter (2) dan parameter (3)
dipetakan ke dalam atribut yang disajikan dalam klausa SELECT dan WHERE
klausa masing-masing. Ambil contoh skema yang didefinisikan pada Gambar 5.1 dan Gambar 5.2
dan pertimbangkan pertanyaannya: daftar nama profesor dan nama departemen mereka
di Universitas Carleton. Masukan untuk ORDER tercantum di bawah ini:
(1) kategori: profesor (2) daftar atribut: nama, nama departemen
(3) kondisi: [nama universitas=Carleton University]
Dengan mencari grafik skema, kategori dipetakan ke dalam professor_tab
node, atribut nama depan dipetakan ke dalam node atribut nama dari pro-
fessor t, dan atribut nama departemen dipetakan ke node nama dari
department.t, kondisi dicocokkan dengan atribut name dari university_t, dan
node ini selanjutnya dipetakan ke klausa SELECT-FROM-WHERE selama
pembuatan kueri ORSQL. Kueri ORSQL dihasilkan sebagai:
SELECT VALUE (x).name, VALUE (x).department.name FROM professor_tab x WHERE
x.department.university.name LIKE 'Carleton University'
Di klausa SELECT dan di klausa WHERE, ada jalur yang menunjukkan
urutan mengakses atribut tabel, di mana jalur dimulai dengan a
tabel alias x. Jika kita muncul di jalan yang memiliki tujuan yang sama, itu akan berakhir dengan

pohon yang berakar dari tabel kategori seperti yang ditunjukkan di bawah ini:
profesor_tab
profesor_
universitas jurusan
nama
departemen
nama
nama
Seperti yang ditunjukkan dalam contoh ini, akarnya adalah profesor.tab, dan ada dua jalur yang
menunjukkan urutan mengakses dua atribut dalam klausa SELECT dan satu
path mengarah ke atribut dalam klausa WHERE. Struktur kueri ini dikenal sebagai
Kueri oleh Pohon [37]. Dalam ORDERS, pohon SQL secara otomatis dihasilkan oleh sistem
melalui pencarian grafik skema. Perbedaan antara pohon di atas dan
pohon kueri yang dihasilkan oleh ORDER adalah tambahan ke urutan yang terkait
objek skema, yaitu nama tabel dan nama atribut, yang kemudian juga mencatat
jenis atribut dan informasi struktural skema lainnya yang diperlukan dalam
proses perumusan query ORSQL.
Jalur kueri adalah sebagai serangkaian objek simpul grafik skema yang menunjukkan akses
urutan node tujuan yang diinginkan dari node kategori. Ini dimulai dengan
node tabel kategori, diikuti oleh nol atau lebih node Database Object dan diakhiri dengan
node atribut yang relevan sebagai ekor. Diberikan grafik skema G, untuk kueri sederhana
yang hanya melibatkan satu tipe terstruktur, mis. jenis tabel kategori, kueri
jalur P berbentuk:

P =
<node kategori-tabel> -> <node tipe-kategori> -> <simpul atribut>.
Untuk kueri yang lebih kompleks yang melibatkan dua atau lebih tipe yang ditentukan pengguna,
jalur kueri
P dalam format ini:
P = <node tabel kategori> -> <node tipe kategori>
-> <simpul atribut menengah> -> <jenis simpul> -> <simpul atribut>.
Dimana pola -→ <intermediate atribut node> → <type node> dapat mengulang
beberapa kali untuk mencapai atribut yang diinginkan. Perhatikan bahwa jalur kueri selalu
berakhir
dengan node atribut dari tipe beton (tipe sistem DBMS) atau tipe terstruktur.
Node perantara hanya menunjukkan hubungan antara tipe node, seperti ISA, IS
OF TYPE, atau hubungan yang disajikan oleh objek referensi. Nilai perantara
node, seperti kode DBMS internal OID, tidak memberikan arti bagi pengguna akhir
dan tidak boleh ditampilkan sebagai hasilnya. Dalam kasus dimana node perantara
memenuhi kriteria pencarian, node tipe objek yang terhubung dimasukkan sebagai ekor
jalan.
6.1.2
Konstruksi Pohon Kueri
Dalam grafik skema, tipe objek dihubungkan melalui referensi objek dan objek
warisan. Hubungan antar objek di dunia nyata direpresentasikan secara konkrit
dalam grafik skema melalui node yang terhubung langsung. Oleh karena itu jalur terpendek
antara setiap pasangan jenis objek sesuai dengan hubungan ontologi antara objek
objek dalam domain informasi. Tugas mendapatkan pohon kueri untuk hasilnya
Permintaan ORSQL demikian dicapai dengan menemukan jalur terpendek yang memenuhi
batasan pemilihan pencocokan fuzzy yang dijelaskan dalam Bab 5.

Untuk grafik skema yang mewakili database dengan kemungkinan kasus pewarisan,
referensi diri, dan referensi melalui jalur melingkar, simpul grafik skema dapat
dipilih lebih dari sekali dalam jalur kueri. Untuk memastikan proses pencarian kejadian-
sekutu berakhir di beberapa titik, variabel sistemMAXDEPTH diatur untuk membatasi maksimum
panjang jalur kueri yang menempatkan node atribut yang relevan. Sejak terpendek
jalur antara dua node menunjukkan kedekatan hubungan antara
objek ada di domain informasi, ketika panjang jalur kueri melebihi a
ambang batas tertentu, makna semantik dari hubungan yang diwakili oleh jalur
menjadi lemah dan kabur, dan pencarian jalan menjadi tidak berarti. Itu
MAXDEPTH didefinisikan untuk memastikan kinerja dan kebenaran semantik
ness dari jalur kueri keluaran. Nilai variabel MAXDEPTH ditentukan
sesuai dengan aplikasi database dan struktur database. Untuk contohnya
skema yang disajikan dalam tesis ini, bilangan bulat 9 ditetapkan sebagai nilai MAXDEPTH.
Berikut ini menjelaskan pemilihan jalur kueri ke atribut A dari:
permintaan pengguna: Awalnya sistem mencari hashtable yang berisi node tabel
objek untuk menemukan tabel yang mewakili objek kategori. Bidang alias dari
setiap node tabel dibandingkan untuk menentukan apakah tabel yang sesuai cocok
kriteria pemilihan tabel kategori. Setelah node tabel kategori telah
diidentifikasi, tipe terstruktur dari tabel kategori ditetapkan sebagai akar kueri
pohon. Kemudian algoritma pencarian luas-pertama digunakan untuk memilih jalur kueri dari
skema grafik untuk atribut A dengan cara berikut: Untuk setiap atribut dari root,
bidang alias diperiksa untuk memutuskan apakah tipe atau atribut memenuhi pilihan
kriteria A. Pencarian berakhir jika node atribut ditemukan cocok dengan kueri, dan
jalur yang mengarah ke atribut dipertahankan sebagai bagian dari pohon. Jika tidak,

node tipe terhubung dan node atribut diproses hingga node yang cocok
ditemukan atau panjang jalur kueri melebihi MAXDEPTH.
Berikut ini adalah pseudocode dari prosedur findPath yang diturunkan dari:
algoritma pencarian luas-pertama. Untuk grafik skema yang diberikan G, setelah kategori
node tipe objek C telah ditemukan, kami mengambil node C sebagai node root, dan
menggunakan
algoritma berikut untuk menemukan simpul yang sesuai dari atribut A:
Algoritma findPath(C, A):
Input: Kategori C, atribut A. Output: Jalur terpendek ke node atribut A.
Inisialisasi antrian kosong q. Inisialisasi jalur kueri P <node tabel kategori>. Tambahkan C ke akhir
P.
Centang C terhadap kriteria pemilihan jika C cocok dengan kueri lalu kembalikan jalur kueri P.
else
q.enqueue(P). sedangkan q tidak kosong dan panjang P <= MAXDEPTH do
t = simpul ekor dari P.
untuk setiap simpul yang berdekatan n dari tdo // Periksa apakah n memenuhi kriteria pemilihan
untuk atribut A.
jika cocok maka
// tambahkan node n ke path return P - P.append(n). kalau tidak
q.enqueue(P.append(n)). P anggota depan q. q.dequeue().
Keluaran dari algoritma adalah jalur terpendek yang sesuai dengan kriteria seleksi
untuk atribut A. Untuk setiap atribut yang direpresentasikan dalam parameter input (2) atau
(3), prosedur findPath digunakan untuk menghasilkan jalur terpendek yang mengarah ke
simpul yang cocok. Jalur kueri dipertahankan untuk membentuk pohon kueri, yang digunakan
oleh perumus kueri ORSQL untuk menghasilkan kueri basis data. Pengoptimalan

pohon kueri dicapai secara alami selama proses pembuatan jalur sejak
semakin sedikit simpul yang terlibat dalam kueri menyiratkan semakin sedikit operasi kueri yang
digunakan dalam kueri
proses.
Contoh berikut menunjukkan algoritma. Pertimbangkan pertanyaannya: nama
semua profesor di Carleton University, ke database City-University yang ditunjukkan di
Gambar 5.1 dan Gambar 5.2. Masukan ke ORDERS adalah:
(1) kategori: profesor (2) daftar atribut: nama
(3) kondisi: [nama universitas=Carleton University]
Untuk menghasilkan jalur kueri, ORDERS terlebih dahulu mencari tabel di tabel
node hash-table dan mengidentifikasi profesor.tab sebagai tabel kategori. Dengan mengikuti
tautannya, tipe terstruktur professor_t berada dan ditetapkan sebagai kepala kueri
jalan. Kemudian algoritma findPath dipanggil untuk menghasilkan jalur kueri untuk masing-
masing
atribut dari input. Untuk mengidentifikasi jalur ke atribut nama, yang berdekatan
node profesor.t diproses satu per satu untuk menentukan apakah kriteria seleksi
puas. Alias dari nama simpul atribut memenuhi kriteria pemilihan dan
path professor.t → nama dikembalikan. Untuk jalur kueri ke nama universitas
dalamkondisi tersebut, algoritma findPath digunakan lagi untuk melintasi node yang berdekatan
dari profesor.t. Node nama dan node situs web tidak memenuhi kriteria pemilihan
dan dikesampingkan. Dengan mengikuti tautan professor_t → department → department.t
-→ universitas → nama dalam grafik skema, nama node yang ditemukan cocok dengan kueri.
Ini mengakhiri proses pembuatan pohon kueri. Gambar 6.1 menunjukkan query tujuan
jalur yang ditunjukkan oleh panah putus-putus.

Universitas_tab
Kota_tab
kota
nama
(REF)
(rangkaian)
nama
(rangkaian)
situs web (string)
universitas (REF_NT)
kota_t
Universitas_t
part_time_st (angka)
pendaftaran
Pendaftaran_t
(pendaftaran_t)
full_time_st (angka)
Universitas
departemen (REF_NT)
(REF)
nama
Presiden
(rangkaian)
(REF)
program
surel
(rangkaian)

profesor (REF_NT)
Profesor_t
(rangkaian)
Departemen_t
nama
departemen (REF)
(rangkaian)
Departemen_tab
Profesor_tab
simpul meja
relasi tipe tabel
jalur kueri
Gambar 6.1: Pohon kueri untuk kueri: sebutkan semua profesor di Universitas Carleton
6.1.3 Menangani Predikat Seleksi
Algoritme pembuatan jalur kueri yang dijelaskan dalam Bagian 6.1.2 digunakan untuk
menentukan
jalur yang mengarah ke atribut dalam klausa SELECT dan ke atribut
dalam kondisi WHERE. Namun, jalur hasil untuk kedua klausa ini adalah

direpresentasikan dalam format yang berbeda dan ditangani dengan cara yang berbeda. Ini
karena
kondisi kueri yang dijelaskan dalam parameter ketiga yang diteruskan ke ORDER sering
melibatkan
beberapa operator logis dan operator perbandingan ORSQL untuk menunjukkan pilihan
predikat yang mendefinisikan properti yang dapat dimiliki atribut.
Predikat seleksi didefinisikan dalam bentuk X op Y, di mana operan X adalah
nama atribut atau istilah yang setara, operan Y adalah nama atribut atau setara
istilah alent dengan kondisi, atau nilai konstan. Op adalah operator dari himpunan
{<, >, <=, >=, <>, =}. Hubungan logis antara predikat seleksi
dihubungkan oleh operasi logika, yang meliputi operator unary NOT, dan
operator biner AND dan OR. Kondisi kueri pengguna disajikan dalam
format:
((TIDAK)) X1 op Y1 (DAN|ATAU (TIDAK)) X2 op Y2 ... (DAN|ATAU (TIDAK)) X; op Yi,
di mana sepasang tanda kurung ()' melampirkan satu atau lebih item opsional, bilah vertikal '
mewakili pilihan dari dua atau lebih opsi dan salah satu opsi harus digunakan dalam
masukan ORDER.
Untuk predikat yang nilai Y-nya adalah atribut, tanda kurung siku ( ]' digunakan
mengelilingi X op Y. Mungkin ada satu atau lebih predikat dalam kondisi tersebut. Setiap
predikat dikelilingi oleh sepasang tanda kurung siku dan ditangani secara individual.
Algoritma findPath dijalankan secara terpisah untuk menentukan jalur yang mengarah ke
atribut X dan atribut Y. Pohon kueri terpisah dihasilkan untuk setiap X dan
Y. Dalam proses perumusan kueri ORSQL, pohon kueri berakar dari
kategori jenis objek dan dari jenis objek predikat digabungkan bersama untuk
membentuk pernyataan ORSQL tujuan. Akar pohon kueri untuk atribut Y
diubah menjadi nama tabel dalam klausa FROM. Dalam kueri biasa, keduanya

atribut X dan Yyang didefinisikandalampredikat seleksibiasanyamengacupada objek yang sama
Tipe. Jenis dari dua atribut di kedua sisi operator op diperiksa.
Jika tipenya tidak sebanding, misalnya, jika atribut X adalah tipe persont,
dan Y ditemukan sebagai objek universitas.t, predikat ini dianggap tidak sah dan
dijatuhkan dari jalur WHERE. Misalnya, dalam daftar kueri negara-negara yang
populasi lebih besar dari populasi Kanada, kriteria pemilihan diatur ke
membandingkan populasi negara. Masukan ke ORDERS dinyatakan sebagai:
(1) kategori: negara (2) daftar atribut: *
(3) kondisi: [populasi > populasi (DAN) nama negara=Kanada]
Kondisi mewakili predikat seleksi. Ungkapan yang termasuk dalam
kurung siku menunjukkan kondisi yang diterapkan pada pemilihan objek negara
proyek. Dalam hal ini, populasi adalah operan X, dan populasi (DAN) negara
name=Canada adalah operand Y. Dua pohon kueri terpisah dihasilkan untuk X dan
Y, dan digabungkan dalam proses perumusan kueri ORSQL. Untuk mantan yang lengkap
cukup, silakan lihat Contoh 3 di Bagian 6.3.
6.1.4
Pengoptimalan di pohon kueri
Dalam proses pembuatan jalur kueri, jalur terpendek yang memenuhi seleksi
kriteria untuk tabel atau atribut yang relevan dibangun sebagai jalur kueri, yang
mengoptimalkan kueri dengan melibatkan objek skema sesedikit mungkin dan memangkasnya
operasi kueri yang tidak perlu. Pengoptimalan pohon kueri juga muncul sebagai hasilnya
dari cara kita memilih nilai parameter input ke ORDER
Jenis koleksi seperti VARRAY dan NESTED TABLE dan fitur 00 lainnya
tures dari Oracle memberikan desainer database kemampuan untuk meniru hubungan dunia
nyata
hubungan secara alami. Namun, referensi objek yang sering didereferensi disimpan

di VARRAYS atau NESTED TABLES tidak menghasilkan manfaat yang menarik dibandingkan
tradisional
tabel bergabung dan tidak direkomendasikan oleh para ahli Oracle [8]. Masalah ini dihindari
di ORDER dengan memilih tipe data yang paling terdekomposisi dalam struktur database
sebagai akar dari pohon kueri. Dalam kueri pengguna, subjek - titik awal kueri
jalur dari ORDERS - biasanya cenderung menjadi objek yang paling bersarang dengan konseptual
objek yang lebih besar ditentukan sebagai kondisi. Misalnya, pertimbangkan kueri untuk
mendaftar
departemen Universitas Carleton. Departemen subjek dalam frasa the
departemen Universitas Carleton bertindak sebagai sub-organisasi dari Universitas Carleton
kota. Dalam database yang ditunjukkan pada Gambar 5.1 dan Gambar 5.2, departemen
dideklarasikan
sebagai atribut universitas dari tabel REFS bersarang ke objek departemen. Dua
Pernyataan ORSQL dapat dikeluarkan untuk menghasilkan hasil yang sama seperti yang
ditunjukkan pada pengguna
pertanyaan:
PILIH *
FROM department_tab x WHERE x.university.name LIKE 'Carleton University'
dan
PILIH DEREF(VALUE(xx))
FROM university_tab x, TABLE(x.departments) xx WHERE x.university.name LIKE Carleton
University'
Kueri kedua mengalami overhead dengan menghapus tabel bersarang dan menghasilkan ekstra
biaya eksekusi atas yang pertama. Namun, dengan memilih Department.tab sebagai
61
tabel kategori, pernyataan ORSQL pertama akan dihasilkan sebagai kueri hasil oleh
PESANAN.

Metode yang dijelaskandi atas mungkin tidak menghasilkan pohon kueri paling optimal di bawah
semua keadaan. Dalam kasus beberapa tabel bersarang dari pohon kueri yang berbeda
terlibat dalam satu kueri, akar pohon SQL mungkin perlu diubah
dengan memilih struktur kueri yang melibatkan lebih sedikit referensi objek dereferensi
dalam tabel bersarang mungkin. Kami menganggap pengembangan yang lebih canggih
dan metode pengoptimalan pohon kueri yang lebih komprehensif sebagai bagian penting dari
pekerjaan masa depan.
6.2
Pembuatan kueri ORSQL
Setelah ketiga komponen kueri tersebut diinterpretasikan menjadi beberapa pohon kueri yang
mewujudkan
objek skema yang relevan dan urutan akses dalam klausa SELECT dan
klausa WHERE, pekerjaan yang tersisa adalah membentuk pernyataan ORSQL berdasarkan
jalur kueri dan sintaks ORSQL. Bagian ini memperkenalkan proses ORSQL
pembuatan kueri.
Untuk menulis kueri ORSQL yang valid, kita harus mengetahui jenis atributnya
untuk menentukan operator, urutan akses dan alias tabel yang disajikan dalam
Pernyataan ORSQL selain nama tabel atau tampilan, dan atribut
nama yang disajikan dalam daftar atribut SELECT dan dalam klausa WHERE. Untuk ujian-
tolong, pertimbangkan pernyataan ORSQL berikut terhadap skema universitas yang ditunjukkan
pada:
Gambar 5.1 dan Gambar 5.2:
PILIH NILAI(xx).nama
FROM University_tab x, tabel (x.departments) xx WHERE x.name = 'Carleton University';
Dalam kueri ini kita dapat melihat bahwa untuk mengambil nama atribut departemen di
tabel bersarang, operator TABLE() digunakan untuk meratakan atribut multi-nilai

departemen University_tab. Contoh ini menunjukkan bahwa tipe atribut, dan
tipe tipe atribut, yang biasanya disebut sebagai metadata dalam database
sistem, tentukan sintaks yang digunakan dalam kueri ORSQL, seperti operasi apa yang bisa
diterapkan ke setiap atribut, dan urutan untuk mengakses tabel dan atribut.
Berdasarkan pengetahuan ini, tabel pemetaan tipe data didefinisikan untuk mengaitkan SQL
tipe data dengan operasi ORSQL yang berlaku. Aturan didefinisikan lebih lanjut dan
digunakan untuk merumuskan pernyataan ORSQL sesuai dengan jalur yang diperoleh dari
grafik skema.
Tabel 6.1 menunjukkan beberapa pemetaan tipe data yang diadopsi dalam ORDERS. Pertama
kolom memberikan tipe data yang disajikan dalam ORDER. Kolektor "SQL:1999 Datatypes"
umn mencantumkan tipe data yang didefinisikan dalam standar SQL:1999. "Tipe Data Oracle9i"
kolom daftar tipe SQL yang diklasifikasikan dalam sistem database Oracle9i. Yang terakhir
kolom daftar operasi SQL yang berlaku untuk jenis yang sesuai.
Dalam tabel pemetaan tipe data ini, nilai disajikan pada kolom 'ORDERS'
tipe data 'didefinisikan berdasarkan klasifikasi tipe data bawaan Oracle9i dan
operator SQL yang berlaku. Jenis yang berbagi operasi kueri yang sama adalah
ditugaskan ke nama metadata yang sama. Misalnya, DBMS mengetik CHAR dan
VARCHAR2 yang mewakili karakter panjang tetap atau bervariasi dan memiliki karakter yang
sama
operator perbandingan di Oracle9i, disajikan sebagai tipe 'STRING' di ORDER.
Selama pembentukan grafik skema, metadata ditentukan berdasarkan:
skema database dari kamus data Oracle dan dipetakan ke ORDERS
tipe data dan disimpan di bidang Tipe dari catatan simpul Objek Database. Dalam
Proses perumusan pernyataan ORSQL, operasi kueri SQL yang sesuai dipilih
berdasarkan pemetaan yang didefinisikan dalam tabel ini untuk menghasilkan pernyataan kueri.
Sebagai contoh,

SQL: 1999 | Tipe data Oгаcle9i tipe data Numerik
Operasi SQL >,<,=,<>
PESANAN
Keterangan
Oracle9i
tipe data NUMBER
NOMOR, | Termasuk bilangan bulat atau non-integer- ics INTEGER serta bilangan eksak atau
perkiraan
MENGAMBANG,
merics
RANGKAIAN
Karakter CHAR,
Tetap
atau memvariasikan =, %, LIKE
VAR-
karakter panjang
CHAR2
TANGGAL
Tanggal
TANGGAL
Tanggal
>,<,=,<>, to date(<string>, '<format>'), to char(<date>, '<format>') tipe REF ke pengguna | ',' (tipe
objek yang ditentukan titik), VALUE(), DEREF()
REF
Jenis referensi
REF
ota-
(DITETAPKAN PENGGUNA

MERUJUK-
ENCE) UER-
TIPE PENGGUNA
Pengguna
Data yang ditentukan pengguna | '.'(dot
tidak a-
ditentukan
tion), NILAI(), REF() atau TABEL()
DEFINISI
jenis
jenis
JЕСT
NESTED_USERT, | Array PENGGUNA VARRAY
BERSATU
bersarang
meja
VARRAY dari sys- (Oracle9i) mendefinisikan tabel tipe data
BLE,
VARRAY
waktu
TABEL DIBUTUHKAN,
NESTED_REF,
Array
bersarang
atau TABEL()
REF_VARRAY
VARRAY dari REF

ORDBMS

Recommended

Recommended

More Related Content

What's hot

What's hot (15)

Similar to ORDBMS

Similar to ORDBMS (20)

Recently uploaded

Recently uploaded (20)

ORDBMS