Objektinės duomenų bazės referatas

Įvadas Įvairių objektinių duomenų formų kaupimas kompiuteriu jau tapo įprastu dalyku. Objektinių duomenų formas, tokias kaip įvairios lenteles, tvarkaraščiai, galima laikyti individualiomis, nes konkrečiu atveju skiriasi eilučių ir/ar stulpeliu kiekis. Taip pat gali skirtis ir eilučių ir/ar stulpeliu pavadinimai. Individualių grafikos formų sudarymas nėra sudėtingas procesas. Tačiau žmogui, nuolat braižančiam vis tuos pačius objektus ir atliekančiam pasikartojančius veiksmus, toks darbas tampa nuobodus ir užima daug laiko. Individualių grafikos formų parametru (stulpelių, eilučių) kiekis ir pavadinimai dažnai priklauso nuo duomenų, esančių duomenų bazėse (DB) ar tekstiniuose failuose. Todėl jų braižymas ir parametrų įvedimas užima dar daugiau laiko, nes kiekviena kartą žiūrima į DB. O dėl monotoniško braižančiojo darbo gali būti padarytos ir atsitiktinės klaidos: neteisingai suskaičiuotas stulpelių ar eilučių kiekis, neteisingai įrašytas stulpelio ar eilutės pavadinimas. Norint išvengti tokių klaidų ir paspartinti darbą, galima automatizuoti individualių grafikos formų braižymą. Šio darbo tikslas yra automatizuoti tvarkaraščio grafinės formos braižymą. Pati tvarkaraščio forma nekinta, kinta tik jos elementu (stulpelių) kiekis ir pavadinimai, kurie priklauso nuo norimo sudaryti fakulteto tvarkaraščio grupių skaičiaus ir grupių pavadinimų. Darbo informacinį modelį sudaro tekstiniai failai: fakultetai.txt ir grupiu_registras.txt. Išorinio duomenų failo „fakultetai.txt" duomenų fragmentas: Objektinių duomenų bazių teoriniai aspektai Šiuolaikinės duomenų bazių valdymo sistemos (toliau DBVS) nėra pasirengusios apdoroti pastoviai besikeičiančių duomenų, tokių, kaip judančio objekto padėtis laike (toliau JLO). Taip yra dėl to, kad DBVS'uose saugomi duomenys laikomi konstantomis, nebent yra specialiai keičiami. Todėl, norint pavaizduoti judanti objektą (pvz. mašiną) duomenų bazėje, ir atsakyti į užklausas apie objekto padėtį tam tikru laiko momentu (pvz. Kaip toli nuo ligonines (kurios koordinates žinomos) yra greitosios pagalbos mašina, kurios numeris RVJ369 ? ), mašinos pozicija reikėtų pastoviai keisti DBVS'e. Tai yra labai nepageidautina, kadangi mašinos padėtis gali kisti labai dažnai (kas savo ruožtu smarkiai apkrautu DBVS'ą) arba atsakymas į užklausą bus pateiktas jau pasenęs [2,5,10]. Užklausas DBVS'ui gali teikti tiek patys judantys objektai, tiek ir operatoriai [1,6]. Programos, naudojančios judančių objektų DBVS'us, kariniams tikslams gali būti taikomos skaitmeninių mūšio laukų sukūrimui. Civilinėje pramonėje tokios programos gali būti pritaikytos transporto valdymo sistemose [1,5,11,9]. Trumpai aptarkime keletą esminių reikalavimų, keliamų judantiems objektams DBVS'uose: 1. Lingvistiniai reikalavimai. Bendrai kalbant, užklausos JLO duomenims turi savyje tiek erdvinę dalį (pvz. taškas, linijos, regionai, poligonai - daugiakampiai) tiek ir ribojimus laike. [1,5,6,3,7]. 2. Indeksavimas. Aišku jog judančių objektų skaičius duomenų bazėje gali būti labai didelis (pvz. Didelis miestas su milijonu gyventojų). Todėl, norint paspartini JLO užklausas, mums reikėtų išvengti, kiekvieno JLO buvimo duomenų bazėje, vietos paieškos. [2,1,5,7,8]. Neaiškumas/Netikslumas JLO buvimo vieta yra paveldimai netiksli, ir nesvarbu kokiu būdu bus atnaujinama objekto buvimo vieta (JLO irašas duomenų bazėje). duomenų bazėje saugoma objekto buvimo vieta negali visuomet atatikti objekto tikros buvimo vietos. Sis paveldimas neaiškumas sukelia daugeli sunkumų duomenų bazių modelio projektavimui, užklausoms ir indeksavimui. [1,3] Todėl egzistuoja būtinas sąrašas galimybių, kurios turi būti integruotos, adaptuotos ir sukurtos ant jau esamų DBVS'u, norint palaikyti JLO objektus. Toliau pateiksime esminius reikalvimus: 1. Dinaminiai atributai Norint apeiti vietos nustatymo problemą, mums reikia sukurti toki modelį, kuris leistų DBVS'ui numatyti busimą JLO buvimo vietą. Todėl, kai JLO keičia duomenų bazę, jis turi pateikti ne tik dabartinę savo buvimo vietą, bet ir tikėtiną ateities buvimo vieta_. Kad būtu išpildytas šitas reikalavimas, buvo pasiūlytas MOST duomenų modelis (Moving Objects Spatio-Temporal model). 2. Erdvinė ir Laiko Užklausų Kalba. MOST pateikia taip pat ir užklausų kalbą, vadinamą Ateities Laiko Logika - ALL (Future Temporal Logic - FTL), kuri veiktų JLO duomenų bazėse. Kalba aiški ir intuityvi formuojant JLO užklausas, ir ji naudoja kartu erdvinius operatorius 3. Dinaminių atributų indeksavimas. Tai gana sudėtinga tema kuri turi keletą galimų sprendimų [1,2]. Kokios pradinės sąlygas pasirinksime ALL diegimui PostgreSQL DBVS'e? Keletas prielaidų, kurių buvo laikomasi, kuriant JLO duomenų modelį ir duomenų apdorojimo algoritmus: 1. Mušu judantis objektas bus taškas 2D erdvėje. Plečiant toliau šia implementacija, duomenų modelį galima butų išplėsti ir panaudoti liniją ar poligoną kaip judanti objektą. 2. Objektas judės laike tiesiogiai tolygiai. 3. Objekto judėjimo kreivę s=f(t) bus padalinta į segmentus (tiesės dalis), kuriuose f(t)=v=const., o judėjimo trajektorija aproksimuota iki tiesės. 4. Kiekvienas objekto judėjimo trajektorijos segmentas bus atvaizduotas DBVS'e kaip atskiras įrašas (kortedžas). 5. Judėjimo greitis kiekviename segmente gali būti kitoks. 6. Trajektorijos vientisumą turėtų užtikrinti vartotojas, o ne DBVS'as, tai yra duomenų modelis neneša savyje jokios eiliškumo informacijos apie tai, kur trajektorijoje yra konkretus segmentas (kuri aprašo konkretus kortedžas duomenų bazėje). 1.1.Teorinis modelis. Duomenų tipai Mūsų įgyvendinime mes naudojomės tokiais PostgreSQL savais duomenų tipais (lentelė 1) Lentelė Nr. 1 Tipas Parašas Int*, real*, bool*, timestamp* —> Baziniai Point*, line*, region* —> Erdvinis Moving Bazinis u Erdvinis -> Judantis * Postgre ŠQL standartiniai tipai Šie tipai priklauso tokiems domenams: 1. AinlEZu{l} 2. ArealERu{l} 3• A[įmeslamp = Ru { J_ } 4. AbooI = { FALŠE, TRUE } u {1} 5. Apoint = R2u{±} 6. A|į„e,region = { P c R2 Į P yra baigtinis } Judantis tipas (Moving) yra pridėtas prie PostgreSQL DBVS'o. Tai yra sudėtinis tipas: Judantis objektas { Pradinis segmento taškas (tipas POINT), Galinis segmento taškas (tipas POINT), Pradinis laiko momentas, nuo kurio segmentas juda (tipas TIMESTAMP), Galinis laiko momentas, iki kuriuo segmentas juda (tipas TIMESTAMP),. Objekto judėjimo greitis šiuo segmentu (maksimalus butu šviesos greitis 2.99792458 K)8 m/s - tipas REAL) Kaip matome, tai yra struktūra, kurioje apjungti tokie standartiniai PostgreSQL duomenų tipai kaip: taškas (POTNT), laiko atkarpa (TIMESTAMP), realus skaičius (REAL). Šitų duomenų tipu galima operuoti kaip standartiniu SQL duomenų tipu, kartu atliekant specialias SQL operacijas. Mes sukūrėme tokias operacijas: Klasė Operacija Pasiketimas greitis Aibių operacijos sankirta Sankirta su Riba (Range) jlobuvo, jloyra, jlobus 1.2.Objekto judėjimo greičio apskaičiavimo algoritmas Iš pradinių sąlygų mes žinome, jog greitis konkrečiame segmente yra konstanta. Todėl mums reikia sužinoti: a) Atstumą tarp pirminio ir galinio segmento taško. b) Laiką, per kuri objektas įveikė šį atstumą. c) Greitis V yra atstumo ir laiko santykis. Greitis mūsų atveju yra (sutartinis atstumo vienetas - metras) m/s 4.2. Kur objektas bus konkrečiu laiko momentu apskaičiavimo algoritmas Sis algoritmas apskaičiuoja kur konkrečiu laiko momentu yra JLO pateiktame segmente. Viena iš šio algoritmo atmainų atlieka ekstrapoliaciją, t.y. apskaičiuoja GALIMA objekto buvimo vietą. a) turime JLO judėjimo greitį bei laiko momentą (kuris mus domina) b) apskaičiuojame segmento kampo

Daugiau informacijos...

★ Klientai rekomenduoja

Šį rašto darbą rekomenduoja mūsų klientai. Ką tai reiškia?

Mūsų svetainėje pateikiama dešimtys tūkstančių skirtingų rašto darbų, kuriuos įkėlė daugybė moksleivių ir studentų su skirtingais gabumais. Būtent šis rašto darbas yra patikrintas specialistų ir rekomenduojamas kitų klientų, kurie po atsisiuntimo įvertino šį mokslo darbą teigiamai. Todėl galite būti tikri, kad šis pasirinkimas geriausias!