Scalable Representasi Data dalam Manajemen Risiko

Sistem Informasi Menggunakan XQuery Ekstensi

-----------------analisis abstrak-Risiko telah menjadi baru-baru ini yang penting
Kegiatan di banyak domain industri: pertambangan, off-shore pengeboran,
pelayanan kesehatan dll Untuk singkat, analisis risiko mempelajari
hubungan antara penyebab kecelakaan dan tingkat keparahan nya
konsekuensi. Ia datang sebagai tidak mengherankan bahwa Manajemen Risiko
Sistem Informasi (SIMLR) untuk pelacakan dan pelaporan biaya
mencegah kecelakaan dan mengurangi konsekuensi dari
peristiwa penting telah menarik banyak penelitian dan pengembangan
upaya. Jumlah dan terutama kompleksitas data dalam
SIMLR khas membuat sistem tersebut sangat sulit untuk merancang. Didalam
kertas kami menyajikan model yang populer untuk data manajemen risiko
representasi, model bowtie, yang hampir de facto
model dalam sistem manajemen risiko. Bowtie Model kami hadir
secara inheren diarahkan grafik. Kemudian kami menunjukkan bagaimana kita
mendefinisikan dan
menggunakan ekstensi dari bahasa XQuery, disebut TreXQuery, untuk
melakukan pencarian yang rumit dari model grafik dalam manajemen risiko
sistem.
----------------PENGANTAR
Sebagai jumlah data yang tumbuh setiap hari dengan kecepatan yang sangat
cepat, demikian juga
kompleksitas hubungan antara entitas data dan
minat dalam mewakili dan mencari hubungan data tersebut.
model representasi data standar (database relasional,
data semi-terstruktur) sering tidak cukup untuk menangkap dan
mewakili semua kompleksitas data. Grafik tidak diragukan lagi
Pilihan yang kuat untuk representasi data karena mereka standar
representasi hubungan, pada umumnya. Sebagai hirarkis dan
semi-hirarkis model data (database relasional, data XML)
yang intensif dipelajari dalam beberapa dekade terakhir, standar
muncul untuk menyimpan, mewakili, dan mencari data tersebut. ini
kemudian alam untuk mengambil keuntungan dari standar tersebut untuk
mengembangkan
alat untuk model data grafik yang sesuai.
Dalam makalah ini kita mempelajari manajemen analisis risiko khas
sistem dimana data mungkin timbul dari sumber yang heterogen dan
disimpan dalam berbagai bentuk (database relasional, XML). Untuk
Misalnya, sebuah perusahaan pengeboran lepas pantai dapat menyimpan data
dari
Platform yang berbeda dalam database relasional (mungkin didistribusikan
selama beberapa lokasi), sedangkan pertukaran data antara yang berbeda
sumber data dan repositori sentral dapat dilakukan di
Format semi-terstruktur (XML). Gambar 1 menunjukkan umum

gambaran dari sistem tersebut, dengan beberapa sumber data dan cara-cara
yang berbeda untuk menyajikan data: relasional tradisional
laporan database, format tabel, dan, khusus untuk risiko
analisis, diagram bowtie.
Dalam karya ini kita fokus pada model representasi bowtie
(Dijelaskan dalam Bagian II) sebagai salah satu yang paling representatif di
sistem manajemen analisis risiko. Perlu dicatat bahwa
kompleksitas dari model data dalam representasi bowtie
berasal dari hubungan yang kompleks antara entitas data
bukan dari fakta bahwa data dapat memiliki data yang heterogen
sumber. Sebuah model bowtie secara inheren grafik dan visual mewakili
hubungan antara kemungkinan penyebab dari
kecelakaan (hazard), konsekuensinya, metode untuk mencegah
kecelakaan dan cara mengurangi konsekuensi dari
kecelakaan. Analisis risiko adalah proses yang kompleks yang sering bergantung
pada sebelumnya akumulasi keahlian dan data. Hal ini membutuhkan, di
umum, banyak penyesuaian dari model dan simulasi di
memesan untuk menghasilkan analisis risiko yang akurat. bowtie yang
representasi berfungsi sebagai "dashboard" dalam proses ini: itu
memberikan ringkasan visual karakteristik proses 'dan
harus memungkinkan perubahan dinamis dari model dan simulasi.
Tujuan ini akan sangat sulit dicapai tanpa
bahasa manipulasi data yang sesuai yang sesuai untuk data
Model mewakili bowtie a.
kontribusi kami adalah sebagai berikut. Pertama, kami menyediakan
deskripsi formal dari model bowtie umum perwakilan di
proses analisis risiko yang khas. Kemudian kami menunjukkan bagaimana kita
bisa
secara alami memperpanjang bahasa XQuery [1] untuk melakukan pencarian
dan / atau manipulasi data melalui model grafik data. Akhirnya, kami
menyajikan pelaksanaan ekstensi XQuery,
TreXQuery, yang menyediakan skalabilitas yang diinginkan dan fleksibilitas dari
representasi bowtie di risiko khas
sistem manajemen informasi.
Sisa kertas ini disusun sebagai berikut. Dalam Bagian II
kami menyajikan risiko bowtie representasi model analisis,
terminologi, dan struktur data yang mendasari. Selanjutnya, di
Bagian III, kami menyajikan model data rinci, kita secara singkat
memperkenalkan XQuery untuk mencari model pohon, dan kami menunjukkan
bahwa
XQuery dapat secara alami diperluas untuk mendukung pencarian lebih
diarahkan grafik. Kami menyebutnya perpanjangan XQuery untuk mencari
risiko model data yang TreXQuery (yang disajikan dalam Bagian
IV). Contoh implementasi TreXQuery disajikan dalam
Bagian V. Kami menyimpulkan dan rencana kerja di masa depan ada di
Bagian VI.

----------------------------PERSIAPAN
penilaian risiko dan analisis, awalnya proses standar
di industri pengeboran dan pertambangan, telah saat ini memperoleh
popularitas di berbagai domain: industri kesehatan [2], air
jaringan pasokan [3], penanganan bahan berbahaya [4, 5], sosial
dan kerja [6, 7] dll Singkatnya, risiko didefinisikan sebagai
hubungan (kuantitatif atau kualitatif) antara penyebab
kecelakaan mungkin (event penting) dan kemungkinan
Konsekuensi dari acara: menyebabkan - acara penting konsekuensi. Proses penilaian risiko mengidentifikasi semua
kemungkinan penyebab kecelakaan, langkah-langkah pencegahan untuk
acara tersebut, dan kemudian, dalam kasus acara ini akhirnya diproduksi,
langkah-langkah mitigasi untuk mengurangi konsekuensi
acara. Proses ini sering dimodelkan, sangat sugestif, sebagai
diagram bowtie (Gambar 2). Dalam model ini, penyebab CA adalah
ditandai dengan nilai kemungkinan dan konsekuensi CO oleh
Nilai keparahan. Tujuan dari pencegahan (PC) dan
mitigasi (MC) kontrol (ditandai dengan efektivitas
value) adalah untuk mengurangi kemungkinan penyebab sepanjang jalur
konsekuensi dan tingkat keparahan konsekuensi,
masing-masing. Terendah penyebab kemungkinan pada akhir
jalur konsekuensi dan terendah konsekuensi
keparahan, kesempatan yang lebih baik untuk menghindari peristiwa penting.
Untuk mencapai
tujuan ini, dalam proses penilaian risiko nyata model ini
terus berubah: penyebab, kontrol, dan konsekuensi dapat ditambahkan atau
dihapus; menyebabkan likelihood dan / atau kontrol
nilai-nilai efektivitas dapat disesuaikan di kali, dll Oleh karena itu
keharusan untuk memiliki bahasa manipulasi data yang sesuai
untuk melakukan perhitungan sepanjang jalur dari penyebab
konsekuensi. Kebutuhan ini dapat jelas tergambar jika kita
melihat lebih dekat di jalur rinci dari penyebab ke
konsekuensi dari bowtie (Gambar 3). Secara umum, jalur
dari penyebab (CA, numerik ditandai dengan kemungkinan L)
untuk konsekuensinya (CO, numerik ditandai dengan tingkat keparahan
S) berisi beberapa pencegahan (PC) dan mengurangi kontrol
(MC). Kontrol ini secara numerik ditandai dengan adanya
Efektivitas E. Berbagai faktor dapat mengurangi kemampuan
kontrol untuk mengurangi penyebab kemungkinan atau konsekuensi
kerasnya. Faktor-faktor ini disebut faktor eskalasi (EF) dan
mereka numerik ditandai dengan tingkat keparahan dampaknya i.
Untuk membuat masalah lebih rumit, dalam prakteknya, ini
faktor eskalasi dapat dikendalikan oleh entitas lain,
eskalasi faktor hambatan, yang dirancang untuk mengurangi
dampak dari faktor eskalasi. Dengan cara ini seluruh model bisa pergi
rekursif mendalam dari setiap kontrol, tergantung pada

granularity dari proses analisis risiko. Kami akan melewatkan rincian ini
dalam presentasi ini karena mereka tidak berdampak keluar pendekatan (oleh
Sebaliknya, mereka akan menggambarkan skalabilitas dari pendekatan kami)
dan akan membuat deskripsi keseluruhan proses yang sangat sulit untuk diikuti.
Kecuali untuk konsekuensi keparahan, semua lainnya
parameter yang biasanya dinyatakan sebagai persentase. ketika semua
faktor-faktor ini diperhitungkan, kemungkinan efektif
penyebabnya dihitung sebagai:
EL = L * E1 * (1 + i1) * E2 (1)
dan tingkat keparahan efektif penyebabnya dihitung sebagai:
ES = S * E3 * E4 (2)
Maka nilai risiko dihitung hanyalah produk dari
efektif penyebab kemungkinan dan konsekuensi keparahan:
R = EL * ES (3)
Oleh karena itu dihitung "risiko" nilai biasanya sebagian kecil dari
beratnya konsekuensi risiko (s).
Hal ini jelas bahwa rumus di atas dipengaruhi oleh
jumlah kontrol, faktor eskalasi, dan parameter mereka. Di
kasus dinamis menyesuaikan model (menambahkan / menghapus
komponen bowtie) atau simulasi (mengubah parameter
nilai-nilai) formula ini harus menghitung ulang atau bahkan disesuaikan
(Dengan menambahkan / menghapus parameter dalam formula ini). Ini
Pendekatan akan sangat merepotkan untuk dasi kupu-kupu kecil dan
benar-benar praktis untuk dasi kupu-kupu rata-rata dan besar. Sebuah grafik
bahasa traversal akan menjadi solusi yang lebih praktis.
------Meskipun model-model grafik dan database telah ada selama
beberapa waktu [8] mereka tidak menerima banyak perhatian sebagai mereka
relasional atau XML rekan-rekan. Hanya baru-baru, tumbuh dengan
bunga dalam model data yang kompleks dan representasi memicu
peningkatan cepat dari sistem database grafik murni (lihat [9] untuk
survei terbaru). Namun, untuk saat ini tidak ada standar umum
untuk bahasa manipulasi data untuk grafik. Semua grafik permintaan
bahasa diusulkan entah didedikasikan untuk masalah tertentu
(Seperti menemukan jalan terpendek [10]) atau benar-benar baru
bahasa query sangat mirip dengan SQL (misalnya Cypher di
Grafik Database Neo4j [11]).
Pendekatan kami asli [12] untuk mencari model grafik di
Gambar 2 didasarkan pada pengamatan sederhana: grafik di
Gambar 2 pada dasarnya adalah gabungan dari dua pohon (sisi kiri,
disebut "pohon kegagalan"; dan sisi kanan, disebut "peristiwa
pohon"). Pendekatan ini muncul sebagai pilihan alami, berasal
dari terminologi standar dalam proses penilaian risiko
menggunakan dasi kupu-kupu. Setiap pohon bisa dengan mudah dimodelkan
sebagai
Model Document Object (DOM [13]) dan karena itu XQuery
[1] dapat digunakan di luar kotak. Kelemahan dari

Pendekatan adalah bahwa hal itu hanya dapat digunakan untuk bowtie relatif
sederhana
model. Dalam prakteknya, struktur data (seperti yang kita jelaskan di
Bagian III) jauh lebih kompleks dan kedua kiri dan kanan
sisi diarahkan grafik sendiri. Sebaliknya, kami memutuskan untuk
memperpanjang XQuery yang sesuai untuk mencari grafik. Itu
manfaat yang jelas ada dua: bahasa deklaratif standar
untuk mencari menggunakan ekspresi jalan biasa penghubung; dan
memanfaatkan algoritma efisien untuk menghitung query path
sudah dikembangkan untuk XPath / XQuery [13, 14].
------------------------RISIKO MODEL DATA ANALISIS
Risiko analisis sistem yang khas mungkin berisi apa-apa
antara ratusan dan puluhan ribu peristiwa penting untuk menjadi
dianalisis. Kejadian-kejadian penting yang diselenggarakan di register.
Oleh karena itu, gambaran besar dari semua entitas data hirarkis,
dengan register di atas, maka peristiwa penting elemen, yang memiliki
penyebab, kontrol pencegahan dan mitigasi, dan konsekuensi
(Gambar 4). Kemudian pada setiap tingkat acara penting, menyebabkan, kontrol,
dan konsekuensi dapat saling berhubungan dalam bentuk bowtie, seperti
diilustrasikan pada Gambar 2.
Gambar 5 menunjukkan model data saat selesai dengan semua bahan dari
aplikasi enterprise nyata: departemen
mengelola acara penting dan orang-orang; orang yang bertanggung jawab
dengan
kontrol (dalam satu atau banyak register); tindakan yang diperlukan untuk
mempertahankan efisiensi kontrol pencegahan dan mitigasi (di
satu atau banyak register), dll Setiap simpul graf adalah kompleks
keberatan dengan sendirinya. Ini berisi, secara umum, informasi yang dapat
diselenggarakan sebagai satu set "atribut" (sifat), tetapi mungkin memiliki
interconnectivities internal yang membuat simpul mini-grafik dengan
diri. Kami tidak akan hadir semua rincian ini dalam makalah ini karena
kurangnya ruang.
----Pada Gambar 5, kami juga menyoroti bagian bowtie data
struktur. Bagian itu, secara umum, "dashboard" untuk
menampilkan keadaan umum sistem dan sebaliknya untuk
baik-baik saja tuning parameter dari sistem. Sebuah data yang memadai
bahasa manipulasi diperlukan untuk mencari dan
menampilkan informasi, menambahkan / menghapus node baru, memicu
perubahan sepanjang jalur dari penyebab konsekuensi ketika
parameter dari perubahan sistem.
Secara formal, model data pada Gambar 5 adalah grafik bowtie
BG (V, E) yang berikut dua fungsi didefinisikan:
Sebuah fungsi nama node
NN: V? {CA, PC, MC, CO, Event, Registrasi,
Departemen, Orang, Action}

Definisi fungsi tipe node adalah menjelaskan diri saat

menggunakan notasi pada Gambar 5.
Fungsi pelabelan tepi
EL: V x V? {Anak, keturunan, orang tua, nenek moyang,
sebelumnya-saudara, sebelumnya, followingsibling,
berikut}
Fungsi pelabelan tepi merupakan hubungan antara
pasang simpul grafik dan didefinisikan sebagai berikut. Setiap
panah (tepi) di kotak bowtie dari Gambar 5 adalah followingsibling a.
Setiap panah lainnya dalam diagram memiliki label anak.
Kemudian sebelum-saudara dan orang tua adalah kebalikan (inverse
hubungan) mengikuti-saudara dan anak panah,
masing-masing; keturunan, nenek moyang, sebelumnya, dan
Berikut ini adalah penutupan transitif anak, orang tua,
sebelumnya-saudara, dan mengikuti-saudara hubungan,
masing-masing.
Fungsi tepi label yang didefinisikan di atas untuk bowtie sebuah
Grafik menyediakan navigasi berarti mirip dengan yang untuk
navigasi struktur data pohon. Sebagai lawan pohon meskipun,
orang tua kaitannya relatif terhadap titik tertentu dapat menghasilkan nol atau
lebih simpul (paling banyak satu untuk pohon). Mirip dengan pohon, kita bisa
juga menggunakan relasi atribut (tepi) yang menghubungkan simpul di
BG dengan "satelit" node memegang data. Misalnya,
Nilai efektivitas dari vertex PC, misalnya, disimpan dalam
atribut simpul terhubung ke simpul PC masing menggunakan
atribut tepi. Informasi ini tidak diwakili dalam Gambar 5
untuk kesederhanaan. Hal ini juga layak disebutkan bahwa model
diilustrasikan pada Gambar 5 dan dijelaskan di atas mungkin tidak cukup
untuk model semua situasi praktis. Misalnya, jika beberapa penyebab
CO pada Gambar 5 harus ketat terkait dengan satu atau beberapa penyebab
CA (tetapi tidak semua), maka salah satu dapat menambahkan hubungan anak
(tepi) dari
mereka penyebab CA untuk masing-masing konsekuensi CO. Ini
akan lebih baik mewakili beberapa situasi kami menemukan dalam praktek,
tetapi tidak akan mempengaruhi dengan cara apapun pendekatan kami jelaskan
di
pekerjaan ini.
Kami jelaskan secara singkat XQuery berikut ini, maka kita akan
menggambarkan ekstensi kami XQuery di atas data grafik
struktur seperti pada Gambar 5.
-------------------------------------------MEMPERLUAS XQuery UNTUK ANALISIS RISIKO SEARCHING
PERNYATAAN MODEL
A. XQuery Query Language
XQuery [1] adalah standar bahasa query deklaratif untuk
mencari dokumen XML direpresentasikan sebagai model pohon. Kami akan
membatasi deskripsi kita ke inti dari bahasa, cukup untuk

memperkenalkan ekstensi kami dan menjelaskan beberapa contoh di depan

bagian. Pada inti dari bahasa adalah "pilih" bagian (yang
adalah sama seperti di XPath [14] bahasa query untuk XML), yang
pada dasarnya adalah sebuah ekspresi jalur reguler untuk navigasi dan
pencocokan node pohon dimulai pada "konteks" saat ini (set
node). Sebuah "jalan" ekspresi secara singkat dijelaskan oleh
berikut tata bahasa fragmen (bagian dalam kurung adalah
opsional):
path: = (/)step1/step2/..../stepn
Langkah: = axis :: simpul-nama [Filter]
Ada 12 sumbu di XQuery (hubungan antara node di
model pohon), di antaranya anak, orang tua, sebelumnya-saudara,
berikut-saudara, dan atribut melayani untuk navigasi bawah, atas,
kiri, kanan, dan ke dan atribut relatif node untuk saat ini
"Konteks" node, masing-masing. Konteks awal terdiri dari
himpunan kosong; jika ekspresi jalan dimulai dengan "/", maka
konteks terdiri dari set yang berisi satu node, akar
model dokumen. Sebuah query path dievaluasi langkah demi langkah,
dimulai dengan konteks awal (set node). Setelah setiap langkah
Hasil simpul set dihasilkan dan hasil ini menjadi konteks
untuk melakukan langkah selanjutnya. Node mengatur hasil
diproduksi setelah langkah terakhir adalah hasil yang dihasilkan oleh jalan
ekspresi.
Misalnya, untuk model pohon pada Gambar 6, query jalan seperti
/ Anak :: A / anak :: B
akan menghasilkan satu set dari dua node (simpul-simpul yang bernama "B" dari
sisi kiri pohon). Sebuah query jalan seperti
berikut-saudara :: B / atribut :: a
ketika dievaluasi w.r.t. konteks node A akan kembali satu
node, yaitu atribut simpul @a melekat pada node B pada
sisi kanan pohon. (Ada singkatan tertentu
untuk sintaks jalur yang disajikan di atas, yang kita tidak akan membahas
di sini.) algoritma yang efisien untuk evaluasi ekspresi path memiliki
telah lama dikenal [15]. Hal ini kemudian alami untuk memanfaatkan teknologi
ada dan memperpanjang, jika mungkin, untuk mencari
model grafik.
--------B. TreXQuery: perpanjangan XQuery untuk mencari grafik
Pekerjaan kami memperluas XQuery untuk mencari model grafik adalah
berdasarkan pengamatan utama sebagai berikut: setiap model data XML
di mana semua hubungan simpul (sumbu) diwakili sebenarnya adalah
diarahkan grafik. Pernyataan ini jelas benar untuk setiap XML
"Pohon" representasi dan dapat segera mengikuti dari
Gambar 6 jika kita mewakili disebutkan di atas berikut-saudara
hubungan (axis) antara node A (dari kiri) dan B (dari
kanan). Belum lagi kasus sepele yang mewakili kedua anak
dan orang tua kapak dalam representasi model dokumen. Itu

-satunya perbedaan halus adalah kenyataan bahwa penutupan transitif dari

axis (atau sumbu itu sendiri) dapat menghasilkan siklus dalam grafik, sedangkan
bahwa tidak terjadi dalam model data XQuery. Contohnya,
penutupan transitif sumbu anak (yang keturunan-atau-diri
di XQuery) dapat menghasilkan siklus dalam grafik diarahkan umum.
Sebagai soal fakta, ketika keturunan-atau-diri (misalnya) adalah
digunakan dalam ekspresi jalur itu cocok dengan semua simpul graf
dicapai dari setiap sudut di set konteks saat ini. bahkan di
kehadiran siklus reachability dapat dihitung dalam linear
saat mulai dari setiap node grafik.
Perpanjangan TreXQuery kami mengusulkan untuk mencari grafik memiliki
karakteristik utama sebagai berikut:
Sintaks XQuery praktis didukung sepenuhnya; ini
membuat TreXQuery mudah dipelajari dan digunakan.
Model data memanipulasi node grafik, yang
benda umum (yaitu, model data tidak sama dengan
XPath / XQuery model data [13, 14]).
TreXQuery mendukung semua XQuery kapak dengan mereka
semantik asli (sesuai label tepi didefinisikan pada
mulai dari bagian ini).
Untuk grafik bowtie BG = (V, E) mewakili risiko
Model seperti pada Gambar 5, model data TreXQuery adalah
grafik BG '= (V', E '), di mana:
o V '= V U {SR}, dengan SR node tambahan
(Super register)
o E '= E U {(SR, x) | x E}
Artinya, grafik model data untuk TreXQuery
memperkenalkan "bodoh" simpul SR, yang terhubung
untuk setiap simpul grafik lainnya. simpul SR ini mewakili
"akar" dari struktur dan tidak secara eksplisit digunakan
dalam query. Daripada itu, setiap ekspresi path
dimulai dengan "/" akan dihitung relatif terhadap SR
simpul.
Terakhir, namun tidak sedikit: setiap sumbu di TreXQuery mungkin
menghasilkan nol atau lebih node. Ini pada dasarnya
semantik yang berbeda dari model pohon, di mana orang tua
axis, misalnya, menghasilkan node tunggal (paling banyak).
Secara formal, diberi satu set konteks node C, jalan
Ekspresi langkah axis :: simpul-nama semantik di TreXQuery adalah
didefinisikan sebagai berikut:
axis :: simpul-name = {y BG '| x C, EL (x, y) = axis
dan NN (y) = node-nama}
mana EL () dan NN () adalah label tepi dan nama node
fungsi sebagaimana didefinisikan dalam bagian sebelumnya. Untuk tujuan dari
mengevaluasi langkah permintaan jalan di BG grafik bowtie '(V', E '), kami
mendefinisikan fungsi sumbu:
A: Range (EL) x V '? 2V '

A (a, v) = {x V '| EL (v, x) = a}

yang pada dasarnya mengambil sumbu dari Range (EL) = {anak,
keturunan, orang tua, nenek moyang, sebelumnya-saudara, sebelumnya,
berikut-saudara, menyusul} dan grafik vertex v sebagai masukan
dan menghasilkan himpunan semua simpul yang berada dalam suatu hubungan
dengan vertex v. Menggunakan fungsi sumbu kita bisa hadir sekarang sebuah
algoritma untuk mengevaluasi langkah query jalan.
Algoritma 1: Jalur langkah permintaan evaluasi
Input: langkah axis :: node-nama; konteks mengatur node C
Output: satu set node S
algoritma langkah (axis :: simpul-nama, C)
(1) S: = kosong
(2) untuk setiap v di C
(3) S ': = A (sumbu, v)
(4) untuk setiap v di S '
(5) jika NN (v) = node-nama itu
(6) S: = S U {v}
(7) kembali S
algoritma loop atas semua simpul dalam konteks simpul set
(Baris 2), kemudian mengevaluasi sumbu langkah untuk setiap titik tersebut
(garis
3). Berikutnya ia melakukan filtering (baris 4-6) sesuai dengan
Langkah ini nama node (baris 5). Hanya node yang memenuhi syarat yang
menjadi
disimpan di final set hasil (baris 6). algoritma melakukan di
O (| V '| 2) waktu karena loop bersarang (baris 2 dan 4) dan
fakta bahwa kedua konteks simpul set C dan simpul set S '
diproduksi oleh fungsi sumbu dibatasi di atas oleh | V '|. Ini
Kinerja ini jelas tidak sebagus hasil terbaik untuk
XQuery / XPath langkah evaluasi dalam [15] (waktu linier) karena
Fakta bahwa sumbu dari grafik (cara kita mendefinisikan dan menggunakan
mereka)
tidak bisa mendapatkan keuntungan dari hubungan ketertiban di antara node
grafik dan
maka tidak ada "primitif" kapak dapat dipilih untuk mendefinisikan semua
lainnya
sumbu. Dalam prakteknya, bagaimanapun, kinerja ini bukan yang paling
menyangkut masalah (ukuran dari set yang disebutkan di atas
jauh lebih kecil dari | V '|, pada umumnya). Sebuah lebih lanjut mengenai
masalah di
praktek adalah evaluasi fungsi sumbu sejalan 3. Ketika
berurusan dengan sejumlah besar data model grafik (node
informasi dan hubungan / tepi antara node) dapat disimpan dalam
cara yang berbeda dan / atau berbagai tempat (seperti digambarkan pada
Gambar 1).
Pengambilan mereka dapat secara signifikan mempengaruhi kinerja dan kami
menemukan bahwa garis 3 dapat menjadi hambatan untuk evaluasi keseluruhan.

Untuk mengatasi situasi ini kami menemukan bahwa caching data dari
Seluruh mendaftar atau, bahkan lebih baik, "terlihat" bagian dari data dapat
secara signifikan meningkatkan kinerja. Mengingat fakta bahwa dasi kupu-kupu
dirancang untuk manusia "konsumsi", jelas bahwa
tampilan tidak dapat menampung banyak node tanpa mengambil tol
pada kemampuan untuk memahami dan menggunakan dasi kupu-kupu benar.
Besar
bowtie memiliki biasanya ratusan node, yang merupakan dikelola
Ukuran ketika berhadapan dengan pertunjukan rangka kuadrat.
--------Untuk evaluasi query jalan seluruh n langkah,
Step1 / langkah2 / .... / stepn, untuk diberikan awal konteks C, kita lanjutkan
satu langkah pada satu waktu menghindari hati-hati pendekatan rekursif,
yang dapat menghasilkan pertunjukan waktu eksponensial dalam ukuran
query (seperti yang ditunjukkan di [15]).
Algoritma 2: Jalur evaluasi permintaan
Input: jalur permintaan langkah1 / langkah2 / ... / stepn;.
konteks mengatur node C
Output: satu set node S
algoritma jalur-query (langkah1 / langkah2 / .... / stepn, C)
(1) S: = kosong
(2) untuk setiap sumbu :: simpul-nama di langkah1 / langkah2 / .... / Stepn
(3) C: = langkah (axis :: simpul-nama, C)
(4) S: = C
(5) kembali S
algoritma loop atas setiap langkah dalam query (garis 24), maka untuk setiap langkah itu menghitung node mengatur hasil langkah
(Garis 3, menggunakan Algoritma 1). Hasil simpul set setelah setiap langkah
adalah baik keseluruhan set kembali (up langkah masing-masing) dan
konteks simpul ditetapkan untuk langkah selanjutnya (jika ada). Algoritma 2 jelas
berkinerja dalam waktu linier dalam ukuran permintaan dan O (n | V '| 2)
secara keseluruhan.
XQuery ada keraguan lebih dari permintaan jalur reguler
ekspresi. Namun, terlepas dari menggunakan model data yang berbeda
dan sedikit berubah semantik dan prosedur evaluasi untuk
model data kapak, seluruh tata bahasa dapat
digunakan karena untuk perpanjangan kami mengusulkan. Oleh karena itu
bahasa diperpanjang sepenuhnya mempertahankan kompatibilitas: semua
query disajikan dalam TreXQuery dapat digunakan tanpa perubahan
model data XML (dan karenanya mendapatkan keuntungan dari portabilitas saat
menggunakan berbagai sumber data).
Dengan spesifikasi tersebut dan notasi kami akan melanjutkan
di samping memberikan contoh menggunakan TreXQuery untuk mencari
grafik. Untuk model grafik diwakili dalam Gambar 5 grafik
nama node ditunjukkan dalam setiap kotak vertex (Register, CA,
Departemen, dll) dengan "Event Kritis" yang digunakan dalam
query sebagai "Event" untuk kesederhanaan. Sumbu (tepi label) adalah sebagai

dijelaskan pada bagian sebelumnya.

V. TREXQUERY query CONTOH
Tujuan utama dari bagian ini adalah untuk menggambarkan dukungan scalable
untuk
melakukan perhitungan seperti dalam formula 1-3. Dalam prakteknya,
penting untuk mencapai tujuan ini untuk jalur penyebab (s) Konsekuensi (s) karena kemungkinan perubahan (menambah / menghapus
elemen jalur, menyesuaikan parameter) dan simulasi. Kita
telah menerapkan dan bereksperimen ekspresi TreXQuery
di RiskView [16] (yang snapshot bowtie ditunjukkan pada
Gambar 7). Semua contoh berikut berlaku untuk grafik di
Gambar 5.
Contoh 1. Memilih semua peristiwa penting:
/ Anak :: Kegiatan
Ekspresi jalan di atas memilih semua node bernama "Event"
yang adalah anak-anak dari SR (model akar) node. Demikian pula,
node dari setiap nama dalam database dapat dipilih.
Contoh 2. Memilih beberapa peristiwa penting:
/ Anak :: Kegiatan [atribut :: kejadian> 5]
Ini adalah pilihan node acara seperti sebelumnya, kecuali bahwa filter adalah
digunakan: hanya mereka node dengan atribut "kejadian" yang
memegang nilai yang lebih besar dari 5 yang dipilih. (Atribut ini tidak
diwakili dalam gambar untuk menjaga sosok sederhana dan
bersih. Kami ingin membuat titik bahwa permintaan sepenuhnya
kompatibel dengan ekspresi XQuery.)
Contoh 3. Memilih semua node sepanjang jalur dari
penyebab pertama di bowtie konsekuensi:
/ Anak :: CA [posisi () = 1] / berikut :: *
Langkah pertama dari ekspresi jalan memilih penyebab pertama
(Menggunakan filter) dan kemudian semua node yang mengikuti followingsibling
a
axis (maka bersama panah menunjuk ke kanan di bowtie yang
kotak). The * dalam ekspresi adalah standar "setiap" placeholder:
setiap nama node cocok.
Contoh 4. Performing perhitungan: berapa banyak penyebab
kemungkinan berkurang sepanjang jalur dari sebab apapun
kontrol pencegahan (lihat Gambar 2 dan 3), menggunakan rekursif suatu
Fungsi [12]. Untuk tujuan query ini kita berasumsi bahwa
setiap penyebab kemungkinan disimpan dalam atribut L (yang
diakses menggunakan @L singkatan dari atribut :: L), toko PC
efektivitas mereka dalam atribut P, dan eskalasi faktor EF
menyimpan nilai dampak keparahan mereka dalam atribut i.
(1) menyatakan fungsi likelihood ($ node) {
(2) jika ($ node / sebelumnya-saudara :: PC / sebelumnya-saudara :: EF)
kemudian

(3) return $ node / sebelumnya-saudara :: PC / @ P *

($ Node / sebelumnya :: saudara :: PC / sebelumnya-saudara :: EF / @ i + 1) *
kemungkinan ($ node / sebelumnya-saudara :: PC)
(4) lain jika ($ node / sebelumnya-saudara :: PC)
(5) return $ node / sebelumnya-saudara :: PC / @ P *
kemungkinan ($ node / sebelumnya-saudara :: PC)
(6) lain jika ($ node / sebelumnya-saudara :: CA) return $ node /
precedingsibling ::
CA / @ L
(7) lain kembali 1
(8)};
(9) sebesar $ ll di / acara / PC
(10) pulang $ ll / @ P * kemungkinan ($ ll)
Bagian utama dari query adalah di garis 9 - 10: PC langsung
node anak dari acara simpul Kegiatan sentral diambil (sebagai
terlihat pada Gambar 4, masing-masing CA, PC, MC, CO adalah anak dari acara).
Untuk setiap node PC seperti, nilai penurunan (yang terkandung dalam
atribut @P) dikalikan dengan hasil rekursif
fungsi likelihood () (baris 1 - 8). Fungsi rekursif ini berjalan
mundur pada jalur penyebab CA (bersama precedingsibling
axis) dan mengalikan sepanjang jalan semua pengurangan PC
node, dan akhirnya menghitung kemungkinan efektif
diproduksi oleh penyebab di bagian bawah jalan. Untuk setiap node
di jalan ke kiri menuju penyebabnya tes dilakukan
(Garis 2 -7): jika node PC memiliki EF faktor eskalasi, maka
dampak keparahan elemen tersebut diperhitungkan saat
efektivitas simpul PC saat ini adalah computed; jika sederhana
PC node, maka efektivitas P yang digunakan; jika penyebab, maka
kemungkinan penyebabnya sedang digunakan (baris 6, yang akan menjadi
faktor terakhir dari produk dalam formula (1)). Jika tidak ada sebelumnya
saudara, maka rekursi berakhir dengan kembali 1 (yang dikalikan
dengan sisa parameter, maka produksi tidak ada perubahan). ini
jelas bahwa fungsi rekursif melakukan dengan benar terlepas
dari jumlah PC di jalur tersebut. Dalam implementasi kami,
kita benar-benar dilengkapi masing-masing PC (dan MC) node dengan seperti...