I have a question regarding the removal of symmetrical values in
my predicates. These predicates are in my database and I used
assertz to add them there.
So I have:
foo(a,b).
foo(b,a).
foo(c,d).
foo(e,f).
foo(f,e).
I'm trying to remove
foo(b,a).
foo(f,e).
An I tried to make this rule:
remove :- foo(A,B),foo(B,A),retract(foo(B,A)).
However, this removes all the predicates in my DB and I don't know how
to prevent that.
If someone could help me I'd really appreciate it!
Thank you.
There are two distinct semantics for retract/1:
immediate update view: upon backtracking, retracted clauses can no longer be seen (they became invisible immediately).
logical update view: upon backtracking, retracted clauses can still be seen (they became invisible only on the next predicate call). This update view is the ISO standard.
In the logical update view, for example, when the predicate remove/1 is called:
First it sees foo(a,b) and foo(b,a) and hence it retracts foo(b,a).
Afterward, upon backtracking, it sees foo(b,a) and foo(a,b) and hence it also retracts foo(a,b).
To solve the problem, you can use the ISO built-in predicate once/1 (which prevents backtracking).
:- dynamic foo/2.
foo(a,b).
foo(b,a).
foo(c,d).
foo(e,f).
foo(f,e).
remove :-
once( ( foo(A, B),
foo(B, A),
retract(foo(B, A)) ) ).
To retract only one symmetrical fact, you can ask:
?- listing(foo), remove, listing(foo).
:- dynamic foo/2.
foo(a, b).
foo(b, a). % <== only this fact is retracted!
foo(c, d).
foo(e, f).
foo(f, e).
:- dynamic foo/2.
foo(a, b).
foo(c, d).
foo(e, f).
foo(f, e).
true.
To retract all symmetrical facts, you can define:
remove_all_sym :-
( remove
-> remove_all_sym
; true ).
Example:
?- listing(foo), remove_all_sym, listing(foo).
:- dynamic foo/2.
foo(a, b).
foo(b, a). % <== this fact is retracted!
foo(c, d).
foo(e, f).
foo(f, e). % <== this fact is retracted!
:- dynamic foo/2.
foo(a, b).
foo(c, d).
foo(e, f).
NOTE A better alternative would be to avoid inserting symmetrical facts into the database:
assert_foo(A, B) :-
( foo(B, A)
-> true
; assertz(foo(A, B)) ).
Related
I am currently studying Database Management and we were introduced to the idea of functional dependence:
Let A and B be attributes in a relation. B is considered functionally dependent on A if and only if for every A value you can determine a B value. i.e. A -> B
My question:
If this is the case, then given A, B, and C; if C can be evaluated arithmetically using A and B, can you consider C to be functionally dependent on A and B?
That is, (A/B) = C <=> AB -> C
As an example:
Say I have a table containing online order information. It includes the attributes: PROD_PRICE, QTY, and TOTAL_PRICE.
Seeing as the total price can be established by multiplying PROD_PRICE by the QTY is it accurate to say that PROD_PRICE QTY → TOTAL_PRICE?
If this is the case, then given A, B, and C; if C can be evaluated arithmetically using A and B, can you consider C to be functionally dependent on A and B?
Yes, by definition of functional dependency. In a functional dependency, in general, you have a set of attributes (the “determinant”) that determines another set (the “determinate”), that is each time in an instance of a relation we found the same value of the determinant the determinate must be equal, and this is true if the determinate is obtained as value of an expression over the determinate, like in your example.
Note that in general you do not know which is the function that produces the determinate from the determinant, simply you know that such a function exists. The functional dependency concept captures this fact, which is very important when representing data.
So, if for every row of a table we have c=a/b, then ab->c, but for instance, when PRODUCT_ID -> PRODUCT_NAME holds, there is no mathematical function that can derive the latter from the former.
This is an example from a textbook:
Consider the relation R (A ,B ,C ,D ,E ) with FD’s AB -> C,
C -> B, and A -> D.
We get that the key is ABE and ACE. With decompositions: ABE+=ACE+=ABCDE.
How do you check minimality? I know that AB+=ABD and the textbook says that because AB+ does not include C. Then it is minimal. C+=AB and A+=AD are also minimal. But I do not know why. How do you check minimality?
Also, do we have to find all the FD's besides the ones given to check whether to perform 3-NF or not?
We then check if AB -> C can be split into A -> C and B -> C, we notice that these do not stand on their own so AB -> C is not splittable.
We are left with the final relations: S1(ABC), S2(BC), S3(AD) and the key (since not present) S4(ABE) (or S4(ABC)). We then remove S2 because it's a subset of S1.
If it is in 3NF and there are no violations, then why do they split the original relation into: S1(A, B, C), S2(A, D), and S4(A, B, E).
Book name and page: Ullman's Database Systems page 103
How do you check minimality?
The authors don't use the word minimality here. To check for the minimal basis, follow the procedure in the first two paragraphs of example 3.27. It boils down to
". . . verify that we cannot eliminate any of the given dependencies."
". . . verify that we cannot eliminate any attributes from a left side."
Also, do we have to find all the FD's besides the ones given to check whether to perform 3-NF or not?
That question doesn't really make sense. 3NF isn't something you perform. The example in the textbook has to do with the synthesis algorithm for 3NF schemas. The synthesis algorithm decomposes a relation R into relations that are all in at least 3NF.
The synthesis algorithm operates on the FDs you've been given. In an academic setting, as you might find in a textbook, the assumption is that you've been given enough information to solve the problem. In real-world applications, you might be given a set of FDs from a business analyst. Don't assume the analyst has given you enough information; look for more FDs.
We then check if AB -> C can be split into A -> C and B -> C, we notice that these do not stand on their own so AB -> C is not splittable.
No. You verify (not notice) that you can't eliminate any attributes from a left side. Eliminating A leaves B->C; eliminating B leaves A->C. Neither of these are implied by the three original FDs. So you can't eliminate any attributes from a left side.
If [the original relation] is in 3NF and there are no violations . . .
The original relation is not in 3NF. It's not even in 2NF. (A->D)
In short: I have two arrays which may be different, and I'll like to get the difference/transformation as a series of "actions" (adds and removes). That is, in a basic example:
Current: [a, b, d]
Desired: [a, b, c, d]
Actions: Add c in position 2
Basically, the instructions are how to transform the current array so that it's got the same members and order as the desired array. For my application, each change triggers events which update UI and so on, so it would be highly preferable if the actions were not "redundant": that is, the above could have been remove d, add c # 2, add d # 3, but this would cause a lot of unwanted processing elsewhere in the system.
Perhaps as another example which might help illustrate:
Current: [a, b, d]
Desired: [b, c, d, a]
Actions: remove a, add c # 1, add a # 3
I figure this is something which has been solved before, but it's kinda difficult to search for it since "array difference" doesn't give you the right results.
If it matters, I'm implementing this in Javascript, but I guess the algorithm is language agnostic.
This does indeed exists, it's called the edit distance. The basic algorithm doesn't remember the kind of edits, but it's easily modified.
One type of edit distance is the Levenshtein distance. This wikipedia page contains some code snippets you may find useful.
Hirschberg's algorithm may also be useful.
I'm looking for an easy to understand algorithm to compute (by hand) a closure of a set of functional dependencies.
Some sources, including my instructor says I should just play with Armstrong's axioms and see what I can get at. To me, that's not a systematic way about doing it (i.e. easy to miss something).
Our course textbook (DB systems - the complete book, 2nd ed) doesn't give an algorithm for this either.
To put it in more "systematic" fashion, this could be the algorithm you are looking for. Using the first three Armstrong's Axioms:
Closure = S
Loop
For each F in S, apply reflexivity and augmentation rules
Add the new FDs to the Closure
For each pair of FDs in S, apply the transitivity rule
Add the new Fd to Closure
Until closure doesn't change any further`
Which I took from this presentation notes. However, I found the following approach way easier to implement:
/*F is a set of FDs */
F⁺ = empty set
for each attribute set X
compute the closure X⁺ of X on F
for each attribute A in X⁺
add to F⁺ the FD: X -> A
return F⁺
which is taken from here
The set of all attributes functionally determined by α under a set F of FDs.
eg. Suppose we have these starting FDs and we want to compute all the closure using the below once.
A -> BC
AC -> D
D -> B
AB -> D
More FDs calculated by above present once
A+ -> (A,B,C,D)
B+ -> (B)
Similarly we can calculate C+, D+, (AC)+, (AB)+ and so on...
There is a very easy alg. to calculate all set of FDs though
RESULT <- α
MODIFIED <- TRUE
WHILE(MODIFIED) {
MODIFIED <- FALSE
∀ FD A->B IN F DO{
IF A ⊂ RESULT {
RESULT <- (RESULT) ∪ (B)
MODIFIED <- TRUE IF RESULT CHANGES
}
}
}
If by "play" he meant an exhaustive search, then in no way this is not-systematic ;) And a simple solution could look like iterative expansion*) of the set of dependencies on the rule-by-rule basis seems to be just a queue of items to be revisited and a few (two?) loops.. Have you tried it?
Btw. googling around I immediatelly found http://www.cs.sfu.ca/CourseCentral/354/zaiane/material/notes/Chapter6/node12.html - but I cannot verify if it is reasonable because my battery in laptop is literally going down!
*) Simply: apply them iteratively as long as anything has changed in the previous iteration. When applying ALL of them does not change anything in the current state (i.e. (A -> ABCDEF) += (ADEF) ==> (A -> ABCDEF) so no new symbol was added to the set), then it means, well, that no further expansions expand it furhter, so I think that's the point to assume the no-more-growing set to be complete.
Let's consider, for instance, the following relation:
R (A,B,C,D,E,F)
where the bold denotes that it is a primary key attribute
with
F = {AB->DE, D->E}
Now, this looks to be in the first normal form. It can't be on the third normal form as I have a transitive dependency and it cannot be in the second form as not all non-key attributes depend on the whole primary key.
So my questions are:
I don't know what to make of F and C. I don't have any functional dependency info on them! F doesn't depend on anything? If that is the case, I can't think of any solution to get R into the 2nd normal form without taking it out!
What about C? C also suffers from the problem of not being referred on the functional dependencies list. What to do about it?
My attempt to get R into the 2nd normal form would be something like:
R(A,B,D)
R' (D,E)
but as stated earlier, I don't have a clue of what to do of C and F. Are they redundant so I simply take them out and the above attempt is all I have to do to get it into the 2nd form (and 3rd!)?
Thanks
Given the definition of R that { A, B, C } is the primary key, then there is inherently a functional dependency:
ABC → ABCDEF
That says that the values of A, B and C inherently determine or control the values of D, E and F as well as the trivial fact that they determine their own values.
You have a few additional dependencies, identified by the set F (which is distinct from the attribute F - the notation is not very felicitous, and could be causing confusion*):
AB → DE
D → E
As you rightly diagnose, the system is in 1NF (because 1NF really means "it is a table"). It is not in 2NF or 3NF or BCNF etc because of the transitive dependency and because some of the attributes only depend on part of the key.
You are right that you will end up with the following two relations as part of your decomposition:
R1(D, E)
R2(A, B, D)
You also need the third relation:
R3(A, B, C, F)
From these, you can recreate the original relation R using joins. The set of relations { R1, R2, R3 } is a non-loss decomposition of the original relation R.
* If the F identifying the set of subsidiary functional dependencies is intended to be the same as the attribute F, then there is something very weird about the definition of that attribute. I'd need to see sample data for the relation R to have a chance of knowing how to interpret it.
I think the primary key of R is set wrong. If F isn't functionally related to anything it has to be a part of the key
So you have R( ABCF DE) which is now in the first normal form (with F = {AB->DE, D->E}) Now you can change it to the second normal form. DE isn't dependant on the whole key (partial dependency) so you put it in another relation to get to second normal form:
R( ABCF ) F = {}
R1( #AB DE) F = {AB->DE}
Now this relation doesn't have any transitive dependencies so it is already in third normal form.
F doesn't depend on anything?
No, you just haven't been given any explicit information about it in the form
{something -> F}
And essentially the same can be said for C. You're expected to infer the other dependencies by applying Armstrong's axioms. (Probably.)
Think about how to finish this:
Given R (A,B,C,D,E,F)
{ABC -> ?}
[Later . . . I see that Jonathan Leffler has broken the suspense, so I'll just finish this.]
{ABC -> DEF} (By definition) therefore,
{ABC -> F} (By decomposition. Here's where F and C come in. And this is your third relation. ).