Deduktīvas sistēmas izstrādes tehnoloģijas tehnoloģijas1

Ekspertu sistēmas un citas uz zināšanām balstītas sistēmas, kas lieto loģiku, lai attēlotu zināšanas faktu un likumu formā, kā loģiskās programmēšanas nozares attīstības rezultāts izraisīja virkni pētījumu loģikā un datubāzēs. Lai gan šīs sistēmas ir paredzētas zināšanu attēlošanai un apstrādei, tām parasti pietrūkst datubāzu sistēmu pamatīpašības: stabilitāte, sekundārās atmiņas vadība, paralēla datu manipulācija, vaicājumi u.c. Deduktīvu sistēmu realizēšanai galvenokārttiek lietotas loģiskās programmēšanas valodas PROLOG, DATALOG, LISP. Tās iekļauj faktus, likumus un izveduma mehānismu. Diemžēl faktu bāzes realizācija der tikai nelieliem demonstrāciju uzdevumiem. Tātad jārod iespējas to novērst.

1 http://www3.cs.stonybrook.edu/~kifer/TechReports/OpenRuleBench09.pdf

Prolog sistēmaFakti

Likumi

Izveduma mehānisms

Faktu ievade

Likumu ievade

Vaicājumu ievade Rezultāts

Lietotāja interfeiss

2

Deduktīvas datu bāzes sistēmas realizācijas arhitektūras

Līdz šim veiktie pētījumi un risinājumi, kas saistīti ar datu bāzu loģisko interpretāciju, ir labs sākumpunkts, lai integrētu šīs tehnoloģijas. Loģiskās programmēšanas valodai PROLOG ir daudz kas kopīgs ar relāciju algebru, tādējādi tā var viegli tikt izmantota kā relāciju datubāzu vaicājumu valoda. Lietojot PROLOG kā vaicājumu valodu, rindas relāciju datubāzē tiek uzskatītas par faktiem PROLOGā, kas kopā veidos deduktīvās datubāzes EDB. Tomēr, kā jau visām lietām šajā pasaulē, arī PROLOG un relāciju datubāzu sasaistīšanai ir trūkumi, kas saistīti ar dažām neatbilstībām. Fakti un likumi PROLOGā tiek organizēti diezgan stingrā kārtībā, jo tieši no šīs kārtības ir atkarīga programmas semantika. Turpretī relācijas datubāzē tiek aplūkotas kā nesakārtota rindu kopa, un vaicājuma rezultāts ir neatkarīgs no rindu fiziskās kārtības.

Pamatpieejas deduktīvās datu bāzes realizēšanai:1) homogēnā pieeja – tiek izmantota viena sistēma. Gan fakti, gan

slēdzieni tiek glabāti un apstrādāti ar loģiskās programmēšanas valodu.2) heterogēnā pieeja – datu bāze tiek izmantota paplašināmai datu bāzei,

bet loģiskās programmēšanas sistēma tiek izmantota papildinātai datu bāzei.

Heterogēnā metode atbalsta divas neatkarīgas apakšsistēmas – loģikas sistēmu un datu bāzes sistēmu. Loģikas sistēmā glabājas noteikumi un tajā tiek izdarīti slēdzieni, bet datu bāzes sistēmā glabājas fakti. Loģikas sistēma nosūta datu bāzes sistēmai slēdzienus un atpakaļ saņem faktus.

Homogēnajai pieejai ir sekojoši trūkumi:1) faktu un likumu attēlošana pēc vienādiem principiem ir maldinoša, jo

fakti un likumi atšķiras kā apjoma, tā arī to vadības principu jomā. Glabājot un apstrādājot tos atsevišķi, var iegūt labāku veiktspēju.

2) glabājot visus faktus un slēdzienus galvenajā atmiņā tiek ierobežots sistēmas zināšanu bāzes apjoms, kaut arī to daļēji risina virtuālās atmiņas tehnikas.

Loģiskās programmēšanas valodaDatu bāzes sistēma

3

Loģiskās programmēšanas valodas un DBS kopdarbība

1. Sasaiste – divu autonomu sistēmu interfeisa izveide, lai apmainītos ar datiem (datu bāze loģiskās programmēšanas valodas izpildes vides operatīvā atmiņa). Ābu autonomo sistēmu apvienojums tiek saukts par CPR sistēmām (Coupling Prolog to Relational databases).

a) vājā sasaiste (statiskā sasaiste) – datu apmaiņa notiek neatkarīgi no izveduma realizēšanas procesa, vienā datu apmaiņas procesā tiek izgūti visi nepieciešamie fakti;b) ciešā sasaiste (dinamiska sasaiste) - datu apmaiņa notiek izveduma realizēšanas procesā, kad jāiegūst kārtējie konkrētie fakti.

2. Integrācija – jaunas vienotas sistēmas izveide, loģiskās programmēšanas valodas iekļaušana datu bāzes servera programmēšanas valodu kopā.

Saistīšana ir interfeisa izstrāde starp loģiskās programmēšanas sistēmu un datubāzu vadības sistēmu. Abas sistēmas saglabā individualitāti, jo interfeiss starp tām nodrošina datu pārnešanu no ilglaicīgās glabāšanas apgabala datubāzē uz loģiskās programmēšanas sistēmas pamatatmiņu, lai varētu pārbaudīt veseluma ierobežojumus un izvest jaunu informāciju.

Loģiskās programmēšanas

valoda

Datu bāzes sistēma

4

Vājas sasaistīšanas gadījumā (attēls) lietotājam ir pieejamas abas sistēmas. Loģiskās programmēšanas valodā tiek rakstītas programmas, bet no datubāzes ar speciālu predikātu palīdzību tiek atlasīti vajadzīgie dati, t.i., rakstu kopas. Iegūtie dati tiek pievienoti loģikas programmas faktiem, tādējādi programma tiek modificēta katru reizi, kad notiek vēršanās pie datiem datubāzē. Izņemot jaunas informācijas iegūšanu, loģikas programmu var izmantot arī datubāzes modificēšanai. Šim nolūkam arī tiek izmantoti speciāli predikāti, kuriem kā argumenti tiek norādīti programmas mainīgie vai konstantes.

Ciešas sasaistīšanas gadījumā (attēls) lietotājam nav tieši pieejama DBVS. Dati no datubāzes tiek attēloti loģikas valodā, t.i., predikātu formā un tādā veidā tiek piedāvāti lietotājam. Datu pārveidošanu loģikas valodā veic likumu interpretators, kas ir realizēts kā DBVS līmenis. Pirms interpretators veic pārveidošanu, tas ar vaicājuma palīdzību atlasa no datubāzes rakstus, kas konkrētajā brīdī ir vajadzīgi programmai. Atkarībā no vaicājuma realizācijas tiek izdalīti divi ciešās sasaistīšanas veidi:

1) statiski ciešā sasaistīšana risinās izmantojot prekompilatoru. Lai realizētu šādu sasaistīšanu, prekompilators veic programmas divkāršu novērtēšanu. Pirmā novērtēšana tiek izdarīta kompilācijas laikā, pieņemot, ka visi datubāzes predikāti ir patiesi. Tas ļauj prekompilatoram ģenerēt vaicājumus, kas programmas izpildes laikā ļaus izgūt no datubāzes nepieciešamos datus. Rindas, kuru sastāvā esošās konstantes neapmierina programmu, nemaz netiek ievietotas pamatatmiņā. Otra programmas novērtēšana jau notiek programmas izpildes laikā, kad likumi tiek interpretēti, aizvietojot mainīgos ar datiem no EDB;

2) dinamiski cieša sasaistīšana tiek izpildīta atsevišķi katram konkrētam likumam. Šajā gadījumā novērtēšana tiek veikta tikai vienu reizi. Faktiski, izsaucot katru no datubāzes predikātiem, tiek iedarbināts vaicājums, kas novērtē predikātu. Tas ļauj glabāt operatīvajā atmiņā tikai tos faktus no datubāzes, kas ir vajadzīgi konkrētajam likumam.

PROLOG interpretators

DBVS

Datubāze

DBVS izsaukumi

PROLOG + DBVS izsaukumi

Deduktīvā komponente

DBVS

Datubāze

PROLOG

5

Integrēšanas gadījumā (attēls) izveduma apakšsistēma ir pilnībā integrēta DBVS un darbojas datubāzu iekšējos buferos, t.i., darbojas kā jau eksistējošo izveduma mehānismu paplašinājums. Integrējot loģiskās programmēšanas valodu ar DBVS, tiek modificēts DBVS pirmkods. Tajā tiek iekļauts likumu bāzes vadības mehānisms, deduktīvo vaicājumu interpretators (kompilators), īpašas kompilēšanas tehnikas un operatori, kas strādā ar rekursīviem likumiem. Šāda pieeja ļauj izstrādāt integrētās sistēmas, kas piedāvā lietotājam vienādu interfeisu likumu un vaicājumu veidošanai.

Paplašināta relāciju algebra

Atmiņas vadība

Datubāze

Datu manipulēšanas valoda

Valoda likumu rakstīšanai

Valodas kompilators

DBVS buferi

Valoda likumu rakstīšanai

Datu manipulēšanas valoda

6

Loģikas programmēšanas valodas un DBS kopdarbības sistēmas.

Deduktīvās datu bāzes un to čaulas. LDL++ sistēma

Deduktīvu datu bāzu sistēmas un prototipi2. Komerciālās sistēmas

DLV (Italy, University of Calabria) commercialLogicBlox (USA) commercialIntellidimensin (USA) commercialSemmle (UK) commercial

Deduktīvas datu bāzes sistēmas

Coral3 Deductive Database (University of Wisconsin)         [http://www.cs.wisc.edu/coral/]         [http://se.aminet.net/pub/databases/deductive/coral/         [http://se.aminet.net/pub/databases/object-oriented/exodus/

The Aditi4 Deductive Database         [http://www.cs.mu.oz.au/research/aditi/]

2 http://users.informatik.uni-halle.de/~brass/lp14/software.html3 https://www.cse.iitb.ac.in/~sudarsha/Pubs-dir/coralimpl.sigmod93.pdfhttp://research.cs.wisc.edu/coral/4 VLDB Jouraal, 3, 245-288 (1994). Invited contribution. Hans-J. Schek, Editor.

7

The Deductive Database System LDL++5

         [http://wis.cs.ucla.edu/ldl/]         [http://www.cs.ucla.edu/~zaniolo/papers/tplp02.pdf]         [http://www.cs.ucla.edu/ldl/] (LDL Java Interface)         [http://www.cs.uwyo.edu/~ruben/research/pdf/guide.pdf]

NAIL! (Stanford university)

The LOLA6 Project, Implementation of a Deductive Database System         [http://www.im.uni-passau.de/projekte/lola.html]

ROCK&ROLL: Deductive Object Oriented Database System         [http://www.cee.hw.ac.uk/Databases/rnr.html]

Datalog Educational System (DES)7 (Complutense university)         [http://www.softpedia.com/get/Others/Home-Education/Datalog-Educational-System.shtml]         [http://www.fdi.ucm.es/profesor/fernan/des/]

Lightwight Deductive Database System (MITRE Corporation)         [http://www.ccs.neu.edu/home/ramsdell/tools/datalog/]

bbdbddb - BDD-Based Deductive DataBase         [http://bddbddb.sourceforge.net/]

LogicBlox: Cloud-delivered platform for actionable Big Data enterprise applications         [http://www.logicblox.com/] (Homepage)         [http://www.logicblox.com/presentations/arefdatalog20.pdf]

STARBURST4QL (Warsaw University)MegaLog PRO_SQL – sistēma, kurā loģiskā programmēšanas valoda PROLOG sasaistīta ar SQL/DS sistēmu (IBM Research Center at Yorktown Heights).EDUCE - sistēma, kurā loģiskā programmēšanas valoda PROLOG sasaistīta ar DBVS INGRES (European Computer Industry Research Center).ESTEAM - firmas Philips izstrāds interfeiss sistēmai ESTEAM un DBVS INGRESS QUEL vaicājumu valodā.BERMUDA 5 http://web.cs.ucla.edu/~zaniolo/czdemo/tsur/Papers/ldlfinal.pdf6 http://dbis-informatik.uibk.ac.at/files/ext/mitarbeiter/specht/lit/91-tec-ldl-lola-vgl-scan.pdf7 https://www.fdi.ucm.es/profesor/fernan/FSP/SCG11aSlides.pdf

8

PRIMO – interfeiss starp Arity-Prolog sistēmu un DBVS Oracle, izstrāde veikta Modenas universitātē Itālijā.QUINTUS-PROLOG – firmas Quintus Computer System izstrādne, kurā izveidots interfeiss ar DBVS Unify.INDALOG a declarative deductive database language8

Answer set programming (ASP) systems

smodels         [http://www.tcs.hut.fi/Software/smodels/]Potassco (clasp, Gringo, ...)         [http://potassco.sourceforge.net/]DLV         [http://www.dlvsystem.com/]

8 http://www.ual.es/~abecerra/archivos/prole01def.pdf

9

Production and reactive rule systems

Drools, Jess, Prova

Produkciju sistēma vai produkcijas noteikumu sistēma ir datorprogramma, kas tiek izmantota, lai nodrošinātu mākslīgā intelekta formu, kas sastāv no noteikumu kopuma par uzvedību. Šie noteikumi, kas attiecas uz produkciju, ir pamatpiedāvājums, kas ir lietderīgs automatizētā plānošanā, ekspertu sistēmās un rīcības atlasē. Produkcijas sistēma nodrošina mehānismu, kas vajadzīgs, lai izpildītu produkcijas uzdevumus, lai sasniegtu konkrētu sistēmas mērķi.Produkcijas sastāv no divām daļām: 1) sensora priekšnosacījums (vai “IF” paziņojums);2) darbība (vai “THEN”). Ja produkcijas priekšnoteikums atbilst pašreizējam pasaules stāvoklim, tiek norādīts, ka produkcija tiek izraisīta. Ja tiek izpildīta produkcijas darbība, tiek apgalvots, ka tā ir trigerēta. Produkcijas sistēmā ir arī datu bāze, ko dažkārt sauc par darba atmiņu, kas uztur datus par pašreizējo stāvokli vai zināšanām, un noteikumu interpretējumu. Noteikumu interpretētājam ir jānodrošina mehānisms, kā noteikt uzdevumus, ja tiek aktivizēts vairāk nekā viens likums. Piemērs "ABC" rindai:P1: $$ -> *P2: *$ -> *P3: *x -> x*P4: * -> null & haltP5: $xy -> y$xP6: null -> $

$ABC (P6)B$AC (P5)BC$A (P5)$BC$A (P6)C$B$A (P5)$C$B$A (P6)$$C$B$A (P6)*C$B$A (P1)C*$B$A (P3)C*B$A (P2)CB*$A (P3)CB*A (P2)CBA* (P3)CBA (P4)

10

Rule engines for triples

Jena, SwiftOWLIM, BigOWLIM

Mandarax is an open source java class library for deduction rules. It provides an infrastructure for defining, managing and querying rule bases. Choose Mandarax for the following reasons: 1. Mandarax is pure OO, not a translation of a prolog interpreter from c to java. The design is flexible and open, making use of well-known design patterns such as factory, adapter, singleton , strategy and others. 2. Mandarax is based on backward reasoning. This fits perfectly in a computing landscape based on a pull model (e.g. a transaction initiated from a web site). Data (e.g., from relational databases) can be integrated on the fly at query time, no replication is necessary (see the manual for a more detailed discussion of "Mandarax vs. RETE"). 3. The easy integration of all kinds of data sources. E.g., database records can be easily integrated as sets of facts and reflection is used in order to integrate functionality available in the object model. Other data sources (like EJB, data returned by web services etc) can be integrated as well. 4. Mandarax includes a comprehensive library of pre-defined predicates and functions. 5. Mandarax contains a reference implementation of an inference engine. This engine is very flexible: unification algorithm, loop checking algorithm and selection policy can be configured. 6. Rule bases can be made persistent using the XKB module. This module stored rules and other knowledge in a format similar to RuleML. The Mandarax team itself is part of the RuleML initiative working on a XML standard for rules. Export and import of RuleML rule bases is supported. 7. Mandarax is well documented and there are various QA measures in place. Events are logged using the apache log4j framework, and there is a re-usable set of test cases for mandarax core functionalities. 8. Mandarax is free and open source. The software license used is the GNU lesser general public license, making the software suitable for both open-source and commercial projects. 9. Mandarax knowledge bases can be queried as relational databases using the mandarax jdbc driver. 10. Extensions are available including graphical user interface components (swing and servlet/jsp tag based) and other add-ons

Prova (from Prolog+Java) is a rule-based system for Java and agent scripting and information integration extending the Mandarax engine with a proper language syntax and enhanced semantics. The language breaks new ground in combining expressive and declarative programming. It combines natural syntax and typing of Java with Prolog-style rules and database wrappers. Java calls may include both constructor and method calls as wellas access to public variables in classes. Distributed and agent programming transported via JMS or JADE protocols is based on reaction rules specified in a natural syntax. The

11

language makes it easy for agents to engage in concurrent conversations without starting new threads by using reaction and novel inline reaction rules in a very natural and ecoonomic syntax, directly capturing conversations as state machines.9

12

General knowledge base systems CYC

It examines how the different systems scale for a number of common problem sets and, by interpolation, how they or their successors might perform on the Web scale.DLV is a bottom-up rule system, which is unique among the tested systems in that it is based on answer-set programming. Roughly this means that rules can have disjunction in the consequent and the semantics for negation is based on stable models. The well-founded negation is also supported, however. Unlike XSB and Yap, DLV is a pure query answering system: it does not provide operators for updating the knowledge base, and one cannot build a complete application using DLV alone. Instead, applications are to be built using a procedural language, such as Java, where DLV plays the role of a knowledge base component. DLV employs important optimizations, such as Magic Sets, which endow it with certain benefits of a top-down system. It also employs a heuristic that reorders rule premises in order to achieve better performance. DLV is implemented in C++; it is free in binary form for non-commercial use, but is not distributed with an open-source license.

13

Comparison of a Deductive Database with a Semantic Web reasoning engine. Simone A. Ludwig.9

ConceptBase is a deductive object-oriented database management program intended for conceptual modeling. It uses O-Telos which is a version of the logical knowledge representation language Telos, which includes deductive and object-oriented features. O-Telos is based on Datalog, which is a subset of Prolog. ConceptBase allows for logical, graphical and frame views of databases. The ConceptBase graph editor allows one to visualize the relationships in the database, as well as adding and modifyingthe classes, individuals, and relationships. Queries are represented as classes that have membership constraints. Within the database, all classes, instances, attributes, rules and constraints are represented as objects that may be updated at any time. However, there is not an option to cascade changes, thus it is easy to add information at any time, but it can be difficult to remove information.

The Semantic Web technology used to create an ontology to represent the application domain was Protégé a Java-based, free ontology editor developed by Stanford Medical Informatics at the Stanford University School of Medicine. It provides a knowledge base that allows the user to create formal rules for a knowledge representation system to reason through. After developing a taxonomy and creating rules, the ontology can be exported in the Web Ontology Language (OWL) format, which is similar to XML in syntax and includes the descriptions of the classes and individuals along with their explicit relationships. Protégé also provides a Java API that allows OWL files to be imported and represented as Java classes. The API has the capability to connect to a knowledge representation system, such as Racer (Renamed ABox and Concept Expression Reasoner), allowing implicit relationships to be found.

9 http://www.cs.ndsu.nodak.edu/~siludwig/Publish/images/JKBS.pdf

14

An Alternative: Recursiveness in SQL 10

Previous versions of SQL could handle recursive queries but since there was no “recursive statement” you could not retrieve more than one ancestry with a single query:

SELECT p1.parent AS grandparent FROM Parent p1, Parent p2 WHERE p1.child = p2.parent AND p2.child = ’Bart’

To find components that are one level deeper you would need another join and the best option was to join the result of query 1 with the table 2. To find all components, you would need as many joins as there are levels in the given instance. However, since SQL3 (1999) a “With” statement has been added which allows recursion. On a previous versión there was an alternative statement “connect by” however, this statement could not handle cycles. Whenever it detected a cycle, it returned an error. The general recursive statement is as follows:

WITH Ancestor(anc, desc) AS // name given to each recursion ((SELECT parent, child FROM Parent) // original table

UNION (SELECT a1.anc, a2.desc // recursive query using recursion as from tables FROM Ancestor a1, Ancestor a2 WHERE a1.desc = a2.anc))

SELECT anc /* select all ancestors from the recursive table, where start point is ’Bart’ */ FROM Ancestor WHERE desc = ’Bart’;

The query will start from an empty table and compute the query until a fixed point operator is met (in a function, a fix point is a point in which the function of x is equal to x itself. For example, the fixpoint of f(x)= x /2 is 0, since 0 is the only point where f(x) and x are equal. Similarly, in a recursive query, the query will stop when no new information is generated). In the first step, parents and children can be deduced from ancestor-descendant relationships, after the first step, in each subsequent steps we use the facts deduced in previous steps to get more ancestor-descendent relationships. The query will stop when no new facts can be proven. Additionally, some widely used database systems include ideas and algorithms developed for Datalog. For example, the SQL:1999 standard includes recursive queries, and the Magic Sets algorithm (initially developed for the faster evaluation of Datalog queries) is implemented in IBM's DB2.Moreover, Datalog engines are behind specialised database systems such as Intellidimension's database for the semantic web.

10 Deductive Databases. Jorge Galicia Auyón, Victor Flores García. 18/12/2015