I ask this because I seem to lose information when I remove one the FDs and convert the relation to 3NF.
If you have a relation with two attributes R(A,B) and the two dependencies {A→B, B→A}, then the dependencies are already a minimal cover, and you cannot remove one of them.
Note that in this case the relation is already in Boyce-Codd Normal Form and in Third Normal Form, and A and B are both candidate keys.
Related
I have a confusion in UML class diagram Multiplicity.
To ask my question , first i need to give you an example of a situation; Consider this requirement:
"Sections shall have many topics."
I can make the classes for Section and Topic with their multiplicity as follows :
Example 1)
The above relation can be read as : "One or more sections has many topics".
But consider this design also :
Example 2)
The above relation can be read as "One section has many topics , and one topic is in only one section."
Question 1 is :
What is the correct design?
Because for me i think the Example 2 design is the correct one, because i am considering only ONE instance at that particular time. But in Example 1 , they considered the Section class as a very high view! (Of course i can make infinity number of instances of any class...)
Question 2 is : In Example 2, do we say that there exists only one Section in the whole system, that's why we write it as in Example 1? Also in Example 1, This relation is Many to Many, so we need to make an association class to handle it.
I hope you understood my confusion, thanks in advance :D
Q1: In fact it depends on the requirements. A Topic can appear in many Sections as being discussed under different aspects. If you require that a topic must be completely covered in one section then your 2nd approach would be right. Anyhow, I think that the first is the more common way of doing things.
Q2: No. You only say that a Topic can have only one Section. To tell that there's only one section allowed you'd probably need a constraint. (I used a <<singleton>> stereotype for such purposes which is no UML standard, though.)
BTW: you multiplicity in ex. 2 is wrong. To the left you must only have 1..* and to the right only one 1.
In example 1 there are two independent statements:
Every instance of a section can have any number of topics and
every instance of a topic must have at least one section. I don‘t know whether this is what you meant.
PS: The composition, shown by the filled diamond, implies exclusivity. Therefore, the multiplicity can at maximum be 1, not 1..*.
An Association Class is not needed. Many to many relationships are just normal Associations.
I am currently working within Access 2013. I have a simple task that has been really driving me crazy these past few days, as I thought my relationships where correct. But when adding more data into the database I saw that there was a major problem.
Within the database everything is working fine between tblPersonal Information and tblPosition Applied for. The problem that I am running into is trying to successfully create the one to many relationship between tblPosition Applied for and tblOffer
I am trying to make it so that:
one person can apply to many positions (one to many)
one position that each person applies for can have one contingent offer (one to many) "the root of the problem that I am having"
Is their a field that I need to add, or create another table holding just the Personal ID to link tblPosition Applied for and tblOffer? I am really lost on this any help would be greatly appreciated.
If a Position_applied_For can have one-to-many offers, then you need to create a related field in tbl_Offer, just as you did for the one-to-many relationship between tbl_Personal_Information and tblPosition_Applied_For. Change tbl_Offer.Personal_ID to tbl_Offer.Position_Applied_For and relate it back to tblPosition_Applied_For.ID.
Right now there are no fields that are related except Personal_ID in the offers and applied tables. Essentially, there would be no way to distinguish if Person A applied for Job 1 and Job 2, and received an offer for Job 2.
In your tbl_Offer, there should be a Position_ID that relates to the Position. Also, assuming that the offer is only valid for one person, there is no need for tbl_Offer to contain a Personal_ID field, as it would be related through the tblPosition_Applied_For.
Do generatable array fields always belong to the same CFS?
In case one of the list fields has a constraint, and another field has a different constraint and they are not connected. Will both the fields belong to the same CFS?
If the fields aren't connected than each field will be on a different CFS.
The question is not totally clear but here is an attempt to answer:
if this is a list of struct with several fields, the different fields will belong to the same CFS only if connected (e.g. l[0].x and l[0].y will belong to the same CFS only if there is a constraint connecting them).
assuming the question referred to different indices of the same list path (e.g. l[0].x and l[1].x, or m[0] and m[1]), then we need to differentiate between the static and runtime considerations:
statically, both paths are considered to belong to the same CFS. For example, ICFS analysis assume that, so "keep x < f(m[0]); keep m[1] < g(x)" will create an ICFS.
on runtime, IntelliGen tries to solve the list items one-by-one (as if they were in different CFSs), for performance reasons. However, when the list items are connected (either directly or to different variables), which in IntelliGen's terms is called 'lace', they are indeed solved as one CFS, which can be very large.
for more details, I suggest to read section 4.3 ("Avoid Dependencies Between List Elements") in the IntelliGen user guide.
I try to design database tables for the case shown below. I also have an account defined, but it's not important regarding my problem.
There is a list of operations (expenses). Each operation can take place in specified POI, places can be grouped in chains (optional). Each operation can have a recipient, specifically a shop chain.
My current design looks like below. I could even remove chain table in favor of direct reference to recipient, but it still leaves a loop between tables. Effectively, single row could contain references to place and receiving account having different recipient defined.
The only solution I can see is a table check to exclude described case, but I'm wondering: is there a better fix?
As far as I can tell there isn't anything fundamentally wrong with your design. There's no need to change it just because it contains a loop. The loop in this case doesn't even appear to be a circular dependency. If you believe your current design accurately models what it is intended to then I see no need to change it.
Following this post from Neo4j's google group I have to say that I don't see any benefits when using this multiple-label-thing but rather, on the contrary, IMHO it just adds complexity for what a uniqueness constraint is. It could also tempt the user to introduce inheritance into the data model which would cause frustration since that's not possible at all...
Labels have not the notion of just representing a type, they are rather roles which are viable in different contexts.
So in one role, certain attributes and relationships of a node might matter and in another role (label) a different set (that might intersect with the first one).
We stayed away from inheritance as it opens a new can of worms, and we favor composition. So you'd rather compose a node whole as the sum of its parts. You can also mimic an inheritance by also attaching the "super"-types as labels to the child elements in your hierarchy.
Node labels can also be used to separate subgraphs in a larger graph, e.g. label the proteins that are active in human pathways and phylo pathways with those labels. So you can quickly select a part of the graph that you're interested in.
Those separate subgraphs can also come from different domains, like geo,social,catalogue,supplier that are combined in a single graph.
And multiple labels also make sense to separate "technical" namespaces of your graph that are used to represent "in-graph-indexes" from your "domain"-labels.
Regarding uniqueness - all uniqueness constraints for the existing labels and properties on your nodes are enforced at the same time. If they cannot be resolved on insert or update the operation will fail.