In a relation schema, if:
an attribute appears only on the left side then it is prime.
an attribute appears only on the right side then it is non-prime.
But what happens when there are attributes in the middle? Are they prime if they are a subset of the key?
Start from scratch with what you think a prime attribute is, because your definition is incomplete.
For an attribute to be prime, is has to be part of a candidate key. Now, in your case, it happens that A is prime and the rest are not (Since the only candidate key is A). But take this scenario: F={ {A->C}, {B->C}, {C->D}, {D->AB} }. In this case, there are two candidate keys: AB, and D.
This means that A, B, and D are all prime, since they are all parts of candidate keys, and C is not.
Could you give an example? I think I know what your confusion is, but I need more context to answer properly. I can think of 3 things you are referring to:
1) If you mean something like:
AB -> CD
and you think A is prime and D is non-prime, that's not what "left" and "right" means. Everything on the left of the arrow is prime, and everything to the right of it is non-prime.
2) Further, your point 1 is incorrect. An attribute only has to appear left once to be prime. BUT!!!!!! It also depends left or right of what. Are you talking about dependencies of candidate keys only, or all dependencies? To finish my answer I need to have a bit more context.
Related
Let's assume a FIX field is of type MULTIPLECHARVALUE or MULTIPLESTRINGVALUE, and the enumerated values defined for the field are A, B, C and D. I know that "A C D" is a legal value for this field, but is it legal for a value to be repeated in the field? For example, is "A C C D" legal? If so, what are its semantics?
I can think of three possibilities:
"A C C D" is an invalid value because C is repeated.
"A C C D" is valid and semantically the same as "A C D". In other words, set semantics are intended.
"A C C D" is valid and has multiset/bag semantics.
Unfortunately, I cannot find any clear definition of the intended semantics of MULTIPLECHARVALUE and MULTIPLESTRINGVALUE in FIX specification documents.
The FIX50SP2 spec does not answer your question, so I can only conclude that any of the three interpretations could be considered valid.
Like so may questions with FIX, the true answer is dependent upon the counterparty you are communicating with.
So my answer is:
if you are client app, ask your counterparty what they want (or check their docs).
if you are the server app, you get to decide. Your docs should tell your clients how to act.
If it helps, the QuickFIX/n engine treats MultipleCharValue/MultipleStringValue fields as strings, and leaves it to the application code to parse out the individual values. Thus, it's easy for a developer to support any of the interpretations, or even different interpretations for different fields. (I suspect the other QuickFIX language implementations are the same.)
The definition of MultipleValueString field is a string field containing one or more space delimited values. I haven't got the official spec, but there are few locations where this definition can be found:
https://www.onixs.biz/fix-dictionary/4.2/index.html#MultipleValueString (I know onixs.biz to be very faithful to the standard specification)
String field (see definition of "String" above) containing one or more space delimited values.
https://aj-sometechnicalitiesoflife.blogspot.com/2010/04/fix-protocol-interview-questions.html
12. What is MultipleValueString data type? [...]
String field containing one or more space delimited values.
This leaves it up to a specific field of this type whether multiples are allowed or not, though I suspect only a few if any would need to have multiples allowed. As far as I can tell, the FIX specification deliberately leaves this open.
E.g. for ExecInst<18> it would be silly to specify the same instruction multiple times. I would also suspect each and every implementation to behave differently (for instance one ignoring duplicates, another balking with an error/rejection).
I'm new to OCL and currently trying to figure out how to do invariants.
I attached a picture with the diagramm I'm working on.
https://imgur.com/1ucZq5w
The invariants that I'm trying to resolve are :
a) A player has 0 or 2 cards in hand.
Context Player
inv i1: self.card->size()=0 or self.card->size()=2
b) A player, who has not played any rounds, can't have more Game Capital than the maximal Buy-In of the table.
Context Player
inv i2: self.numberOfRounds=0 implies (self.gameCapital < self.Table.maxBuyIn)
c) At every table can be only players that belong to different users
Context Player
inv i3: Player.UserAccount.allInstances().userID->isUnique()
I'm not sure if 'allInstances()' is supposed to go after Player or after PlayerAccount.
And I don't know what I'm supposed to do with the 'At every table' part of the text.
There are two more points that I really don't know how to do.
d) In the deck are 52 cards, which differ from eachother through color or value
e) The inputs of all players that still have cards in the hand are equal when bidDone True.
Can you please tell me if what I've done until now is correct and maybe some advice or solution for d) and e)?
Any help is appreciated!
Seems plausible, but I would recommend sensible names, since a validation tool will tend to report that e.g Constraint Player::i2 is not satisfied for ...
b) looks to have a < / <= bug
c) allInstances takes a type source so "Player." is wrong. allInstances is generally very inefficient to execute so should only be used as a last resort. In your case it is clearly wrong since your scope is "at every Table". You should be using context Table and then reasoning about the players at the table.
d) if you rephrase "differ from" as "is unique with respect to", you can perhaps see how you could use a Tuple of color+value as the basis for uniqueness.
e) no idea what an input is, but it just seems like a cascade of implies clauses.
I have this relation:
wiki(url,title,abstract,link,category_id,category,heading,heading_pos)
And the FD's are:
F = {
url → title, abstract
category_id → category
url, heading_pos → heading
}
I need to find the keys and decompose into a set of Boyce-Codd normalized relations. I have tried to read related and similar questions but I'm unable to understand the given answers. Hope someone will help me with this assignment
Assuming 'wiki' as relation R and its attributes url,title,..heading_pos to be A,B,...H respectively.
We have,
R = {A,B,C,D,E,F,G,H}
FD's = {A->BC, E->F, AH->G}
The key here is ADEH.
We can first convert the relation R to 3NF and then to BCNF.
To convert a relation R and a set of functional dependencies(FD's) into 3NF you can use Bernstein's Synthesis. To apply Bernstein's Synthesis -
First we make sure the given set of FD's is a minimal cover
Second we take each FD and make it its own sub-schema.
Third we try to combine those sub-schemas
For example in your case:
First we check whether the FD's is a minimal cover (singleton right-hand side , no extraneous left-hand side attribute, no redundant FD)
Singleton RHS: We write the FD's with singleton RHS. So now we have FD's as {A->B, A->C, E->F, AH->G}
No extraneous LHS attribute: We remove the extraneous LHS attribute if any. There are no extraneous LHS attributes here.
No redundant FD's: We remove the redundant dependencies if any. There are no redundant dependencies here.
Second we make each FD its own sub-schema. So now we have - (the keys for each relation are in bold)
R1={A,B}
R2={A,C}
R3={E,F}
R4={A,H,G}
Third we combine all sub-schemas with the same LHS. So now we have -
S1 = {A,B,C}
S2 = {E,F}
S3 = {A,H,G}
Since none of the above decomposed relations contain contain a key of R, we need to create an additional relation schema that contains attributes that form of a key of R. This is to ensure lossless join decomposition that preserves dependencies. So we add -
S4 = {A,D,E,H}
This is in 3NF. Now to check for BCNF we check if any of these relations (S1,S2,S3,S4) violate the conditions of BCNF (i.e. for every functional dependency X->Y the left hand side (X) has to be a superkey) . In this case none of these violate BCNF and hence it is also decomposed to BCNF.
Note - The importance of some of these steps may not be clear in this example. Have a look at other examples here and here.
I found the discussion at https://groups.google.com/forum/#!topic/orient-database/Y0QJiXk7d1I to be very useful to help me set up a strict schema with edges in it. This is my code
val fileLink = schema.createClass(DefinedInS.label, g.getEdgeBaseType())
fileLink.setStrictMode(true)
fileLink.createProperty("out", OType.LINK, fqnSymbol).setNotNull(true)
fileLink.createProperty("in", OType.LINK, fileCheck).setNotNull(true)
fqnSymbol.createProperty("out_" + DefinedInS.label, OType.LINKBAG).setNotNull(true)
fileCheck.createProperty("in_" + DefinedInS.label, OType.LINKBAG).setNotNull(true)
but I am confused why I need the last two lines at all, aren't they redundant (or at least implied by the fileLink properties?). Could somebody please explain why they are needed?
In addition, for this example I want exactly one link from a fqnSymbol to a fileCheck but this seems to required that LINKBAG is used (it fails if I use LINK). Is that something I should be allowed to do?
Futhermore, is there any performance benefit to be gained from adding an index on the edge? My usecase is such that I will always have a fqnSymbol at hand when I want to lookup a fileCheck.
I raised https://github.com/orientechnologies/orientdb/issues/5494 to request better documentation in this area.
When one creates an edge (that is, an instance of E), the points of connection are stored at both endpoints (the vertices):
(vertex) -> [edge] -> (vertex)
It's my understanding that if the edge is an immediate instance of E, then those endpoints are properties named out_ and in_. (Similarly, if they are immediate instances of some subclass, say EE, of E, then they would be named out_EE and in_EE.) Often these details don't matter (e.g. outE() collects all outgoing edges), but sometimes they do (as when defining constraints on properties).
Regarding the multiplicity constraint:
I want exactly one link from a fqnSymbol to a fileCheck ...
This constraint can be enforced (at least to a degree) using MIN and MAX:
alter property fqnSymbol.out_ MIN 1;
alter property fqnSymbol.out_ MAX 1;
(Fortunately, the MIN and MAX constraints won't prevent an fqnSymbol vertex from being created in the first place :-)
Tighter enforcement may require writing hooks or triggers.
I have the following facts in dlv, knows (X,Y) means X knows Y.
knows(adam, dan).
knows(adam,alice).
knows(adam,peter).
knows(adam,eva).
knows(dan, adam).
knows(dan,alice).
knows(dan,peter).
knows(eva, alice).
knows(eva,peter).
knows(alice, peter).
knows(peter, alice).
I have defined the following predicates,
person(X) :- knows(X, _).
This will give all the persons from the facts. I am trying to find a predicate popular(X). that will give the popular person. It is defined such that if all persons knows X then X is popular. The answer for the above list of facts is alice and peter. I defined it as below,
popular(X):-person(X),knows(_,X).
X is popular if its a person and everyone knows X. But I am getting all persons as the result when I run it. Where am I making a mistake?
As per the comment string on the original post, you have defined popular to be "a person that is known by someone". Since - in your knowledge base - everyone is known by someone, everyone is popular.
Assuming "a popular person is one whom everyone knows but the popular person knows only other popular persons"; if we want to know if X is popular:
We either need to count all the people that know X and then compare that to the number of people;
Or we need to verify that it is never the case that someone doesn't know X.
I'll focus on the second way to do this, using forall. Take sometime and run some tests on your own to understand how that works. Here's an example of what you might do:
popular(X): - person(X),
forall(
( person(Y),
X \= Y
),
knows(Y,X)
).
If you run this, you get Alice and Peter as answers.
But if we include the other condition:
popular(X): - person(X),
forall(
( person(Y),
X \= Y
),
knows(Y,X)
),
forall(
knows(X,Z),
popular(Z)
).
That last line says X needs to know people that are popular exclusively... and now, if you run this, you're most likely going to get a 'out of local stack' - it's a bottomless recursive definition.
You always need to check if someone is popular to know if someone is popular to know if someone is popular... Try to think about the problem and why that is. Is there a way to check if someone is popular without needing to check if someone else is popular? What if someone 'knows' themselves? What if two people know each other? This might take a slightly more complex approach to solve.
By the way, notice that your definition of person returns multiple people - everyone is a person for every person they know. Besides making every check take a lot longer (since there are more 'people' to check), this might be a problem if you decide to go with the firs approach (the counting one).
Wouldn't it make sense to define explicitly who are the people and then define 'knowing' as a relation between people?
person('Alice').
person('Bob').
knows('Alice','Bob').
As said in lurker's comment (with slight modification and emphasis by me), the reason you get all persons as a result is
You have defined person as: X is a person if X knows someone. And you've defined popular as: X is popular if X is a person and someone knows X.
But you wanted to define: X is popular if X is a person and everyone knows X.
The following is an ASP solution for clingo 4. DLV might have slight differences in syntax.
% Project
person(P) :- knows(P, _).
% Separate helper predicate knows2/2.
% Not needed if polluting knows/2 with knows(X, X) is OK.
knows2(O, P) :- knows(O, P).
knows2(P, P) :- person(P).
% Everybody knows a popular person.
% When there is a person O that doesn't know P, #false is active.
% I.e. all rule instantiations where some O doesn't know P are discarded.
popular(P) :- person(P), #false : person(O), not knows2(O, P).
% Popular person knows only other popular persons.
% Redundant at this point, since the above rule already results
% in correct answer without further integrity constraints.
:- person(P), person(O), popular(P), not popular(O), knows(P, O).
#show popular/1.