Differences

This shows you the differences between two versions of the page.

--- magik-demo:school-usecase [2012/06/25 01:30]
cikm2012 [Example 1: TC-QC plain]
+++ magik-demo:school-usecase [2013/05/13 17:36]
admin removed
@@ Line 12: / Line 12: @@
 (meta-statements that states which parts of tables are certainly complete)
  that hold over an instance
-D of our school database, we can ask whether they entail that for
+D, we can ask whether they entail that for
 a certain query Q the set of answers Q(D) is complete, that is,
 whether Q(D) contains all answer records that one would expect if
@@ Line 29: / Line 29: @@
 <code sql>
 Q1=    SELECT p.name
-       FROM   pupila AS p
+       FROM   pupil AS p
        WHERE  p.level='1'
 </code>
@@ Line 70: / Line 70: @@
 TC3=   TABLE: pupil(P_Name,1,P_Code)  WHERE:
 </code>
-This is expected considering that we do not have other information about the possible class codes.
+This is expected considering that we do not have other information about possible ''class'' codes.
-After adding TC3 and running Q1 again,
+After adding TC3 and {{:magik-demo:go.jpg?nolink&10| }} running Q1 again,
  MAGIK informs us that
 {{:magik-demo:ok.jpg?nolink&10| }}**<fc green>query is complete</fc>**.
 ===== Example 2: TC-QC under Finite Domain Constraints =====
 In this section we illustrate how finite domain constraints can be used to infer query completeness.
-Let us again consider query Q1
+Let us consider again query Q1
 <code sql>
 Q1=    SELECT p.name
-       FROM   pupila AS p
+       FROM   pupil AS p
        WHERE  p.level='1'
 </code>
-and TC-statement
+and TC-statement TC2
 <code sql>
 TC2=   TABLE:pupil(Name,1,a)  WHERE:
 </code>
-In addition to the previous example, we have an information that ''code'' in the relation ''pupil'' can be either
+In addition to the previous example, we have an information that ''code'' attribute in the relation ''pupil'' can be either
-''a'' or ''b''. We express this with a following constraint:
+''a'' or ''b''. We express this with the following finide domain constraint:
 <code sql>
 FD1=   pupil(code)  IN {a,b}
 </code>
-We can see that considering together TC2 and FD1, to answer Q1 completely, we might be only missing pupils from ''1b''.
+We see that considering together TC2 and FD1, to answer Q1 completely, we might be only missing pupils from ''1b''.
-We run the MAGIK reasoner under this settings and not suprisingly it informes us that query is not complete.
+We {{:magik-demo:go.jpg?nolink&10| }} run the query Q1 under this setting and not surprisingly MAGIK informes us that {{:magik-demo:no.jpg?nolink&10| }}<fc red> query is not complete</fc>.
 However, if look at the MAGIK suggestions regarding the missing TC-statements, we can see that MAGIK proposes us to collect the pupil data
 about the class ''1b'', and to confirm it by adding the following TC-statement:
 <code sql>
-TC4=   TABLE:pupil(Name,1,b)  WHERE:
+TC4=   TABLE:pupil(P_Name,1,b)  WHERE:
 </code>
-We follow the MAGIK instructions and we call {{:magik-demo:go.jpg?nolink&10| }}run query, under the configuration of TC2,TC4 and FD.
+We follow those instructions and we call {{:magik-demo:go.jpg?nolink&10| }}run query Q1, under the configuration of TC2,TC4 and FD1.
 MAGIK reasoner inform us the now the {{:magik-demo:ok.jpg?nolink&10| }}<fc green> query is complete</fc>.
 ===== Example 3: TC-QC under Foreign Keys =====
 In this section we illustrate how foreign keys impact the query completeness.
@@ Line 119: / Line 117: @@
 === Enforced semantics ===
+Let us assume that foreign keys obey so ''enforced'' semantics. That is when the foreign keys hold both
-For the foreign keys we assume, so called ''enforced'' semantics, that is when the foreign keys hold
+ over the available database instance and over the ideal (complete) version of it.
- over the available database instance and over the ideal (complete) version of it.
+Note, that we do not have ideal version at the disposal, but only available (incomplete) version of a database.
 In general, one can assume that foreign keys hold only over the
 ideal version, while the available instance can violate foreign keys.
 This situation is plausible in information
-integration scenario.
+integration scenario. Nevertheless, we for now we assume ''enforced'' semantics.
-Now, we ask for the all pupils in the ''science'' department that attents French language:
+Now, we ask for the all pupils in the ''science'' branch that learn French language:
 <code sql>
 Q2=    SELECT p.name
-       FROM   pupila AS p,class AS,learns as l
+       FROM   pupila AS p, class AS c, learns AS l
-       WHERE  p.name=l.name     AND l.lang='french'
+       WHERE  p.name=l.name      AND l.lang='french'
-       AND    p.level=c.level   AND p.code=c.code
+       AND    p.level=c.level    AND p.code=c.code
-       AND    p.branch='science'.
+       AND    c.branch='science'
 </code>
@@ Line 142: / Line 140: @@
 </code>
-Under this setting, we run the query. MAGIK is reasoning in the following way. If for some student exists a French class attendance then it must exists
+Under this setting, we can reason in the following way. If for a some student exists a French class attendance in the ideal database then
-also in the available databas instance. Then considering that available database instance obey foreign key constraint FK1, then for that student there  exists a corresponding record in the ''pupil'' table. Further, considering this and FK2 there must exists a corresponding record
+according TC5 it must exists
+also in the available databas instance. Considering that available database instance obeys the foreign key constraint FK1, then for that student there  exists a corresponding record in the ''pupil'' table. Further, considering this and FK2 there must exists a corresponding record
 in the ''class'' table as well. In other words, if this student is a
 ''science'' student in ideal database instance then that student is ''science'' in the available instance as well.
-Taking all this into consideration, we {{:magik-demo:go.jpg?nolink&10| }}run the query and MAGIK returns that {{:magik-demo:ok.jpg?nolink&10| }} <fc green> query is complete</fc>.
+If we {{:magik-demo:go.jpg?nolink&10| }}run the query Q2, MAGIK
+takes all this into consideration,
+ and it  returns that {{:magik-demo:ok.jpg?nolink&10| }} <fc green> query is complete</fc>.
 === Non-Enforced semantics ===
-Now we relax assumptions from the setttings above, by assuming that foreign keys are not enforced
+Now we relax the assumptions from the setttings above, by assuming that foreign keys are not enforced
 over the available database instance.
-If we {{:magik-demo:go.jpg?nolink&10| }} run query Q2 for the FK1,FK2 and TC4, MAGIK inform us that
+If we {{:magik-demo:go.jpg?nolink&10| }} run query Q2 for the FK1, FK2 and TC4, MAGIK inform us that
 {{:magik-demo:no.jpg?nolink&10| }} <fc red> query is not complete</fc>.
-If we look at the suggestions, MAGIK proposes us to add following TC-statements:
+If we look at the suggestions, MAGIK proposes us to add the following TC-statements:
 <code sql>
 TC6=   TABLE: class(C_level,C_code,science)	WHERE: learns(P_name,french), pupil(P_name,P_level,C_code)
@@ Line 160: / Line 162: @@
 After adding those statements and {{:magik-demo:go.jpg?nolink&10| }} running Q1 again, MAGIK  concludes that
 {{:magik-demo:ok.jpg?nolink&10| }} <fc green> query is complete</fc>.
 ===== Example 4: TC-QC under Foreign Keys and Finite Domain Constraints =====
 In this section we illustrate how interplay between foreign keys and finite domains impact the query completeness.
-We assume that foreign key
+We illustrate this in the following scenario.
+We assume that there exists a foreign key (no metter if it is enforced or not)
 <code sql>
 FK1=  FOREIGN KEY pupil(level,code) REFERENCES class(level,code),
 </code>
-is enforced.
 Then we know that ''branch'' in the ''class'' relation can be either ''science'' or ''humanities''.
 <code sql>
@@ Line 174: / Line 175: @@
 </code>
-Also we assume that we are complete for all pupils from the humanities branch and for all pupils from science branch expressed with the following TC-statement:
+Lastly, we assume that we are complete for all pupils from the humanities branch and for all pupils from science branch expressed with the following TC-statement:
 <code sql>
 TC8=  TABLE: pupil(Name,Class,Level)  WHERE: class(Level,Code,humanities),
@@ Line 186: / Line 187: @@
 </code>
-We reason on the following way. If there is a record of a pupil in the idel database instance, then following the foreign FK1, there exists a
+We reason in the following way. If there is a record of a pupil in the idel database instance, then following the foreign FK1, there exists a
 corresponding records in the ''class'' relation. Due to the FD1 this record has either ''humanities'' or ''science'' on the branch position.
 If the first is the case, then following TC8 the pupil record will exists in the available database.
-If the second is the case, then following TC89 then again the pupil record will exists in the available database.
+If the second is the case, then following TC9 the pupil record will exists in the available database again.
-We {{:magik-demo:go.jpg?nolink&10| }} run query Q3 for the FK1, FD and TC4, and MAGIK inform us that
+We {{:magik-demo:go.jpg?nolink&10| }} run query Q3 for FK1, FD2, TC8 and TC9, and MAGIK inform us that
 {{:magik-demo:ok.jpg?nolink&10| }} <fc green> query is  complete</fc>.
@@ Line 227: / Line 228: @@
 In addition to the standard SQL ''select-project-join'' queries, MAGIK allows use of ''count(*)'' and ''GROUP BY''.
-For example, a more elegant way of writing query Q5 can be:
+For example, we can write a query, that prints the similar result as query Q5, but in a more elegant way:
 <code sql>
 Q6=   SELECT   l1.name, count(*) AS number
@@ Line 236: / Line 237: @@
 </code>
-If we look at MAGIK suggestion for the query Q5 (the same for query Q6), MAGIK proposes to
+Now, if we look at MAGIK suggestions for the query Q5 (the same will be for query Q6), MAGIK proposes to
 to complete the learns tuples for the names of those pupils
 who learn French:

ognjen.savkovic@wikispace

User Tools

Site Tools

Differences

Page Tools