me and my friend are arguing over what the correct answer for one of my questions, is. I have put A but he suggests that it may be B
The question
Now this is why I believe I am correct, the third relationship, clearly models a M to M relationship, thus we would need to simplify it, therefore the "teaches" would become a entity in itself thus the correct answer would be A
I do not think it can be B or None of the Above.
The semantics should be read: A course is taught by one lecturer, every lecturer is teaching one or more courses.
So, now, A) is M to M relation, so it's definitely out. To be a M to M, there should be arrows in both directions Lecturer <- Teaches -> Course
B is the answer since the class has the teacher as a foreign key
Related
I am currently working on this question to identify which normal form it is and so I have to list out the functional dependencies. I worked out the solution but still have questions about it.
In a final-year-project selection process, students are to select one
research topic for his/her project. Students are allowed to select the
same research topic. For each research topics, supervisors are
assigned to supervise it. A supervisor may be supervising up to two
different research topics and each research topic may be assigned to
different supervisors. For each of the research topic a supervisor
supervises, a consultation day is allocated for the student to meet
and discuss with the supervisor.
This information of final-year-project selection are stored in the following relational table:
FINALYEARPROJECT(supervisor, researchTopic, consultationDay,
student)
These is the functional dependencies I listed:
student → researchTopic, consultationDay, supervisor
student is the candidate key.
supervisor, researchTopic, student → consultationDay
Question 1:
From student I can find all the attributes. But then with the (supervisor, researchTopic, student), I also can find consultationDay. However those are just superkey and not candidate key. So should it be a dependency?
Question 2:
Assume my dependencies were correct, I can deduced this relational table to be in BCNF. However in my lecture notes,
The definition of Boyce-Codd Normal Form (BCNF)states that a relation
is in BCNF if and only if every determinant is a candidate key.
This is very different from what I found on the net (eg. wiki):
A relational schema R is in Boyce–Codd normal form if and only if for
every one of its dependencies X → Y, at least one of the following
conditions hold:
X → Y is a trivial functional dependency (Y ⊆ X)
X is a superkey for schema R
So now, according to my lect notes, with the dependencies found, the table will not be in BCNF as (supervisor, researchTopic, student) is not a candidate key, it is just a superkey. However if is according to wiki's, then this table will be in BCNF as all the determinants are superkey.So is this table in BCNF?
Both the definitions of BCNF that you cite do not mention which set of Functional Dependencies is used when checking for satisfaction of the normal form, but this is important.
You know that, given a set of Functional Dependencies, for instance that found by reasoning over a problem, there are many equivalent sets, or more precisely there are many sets that are a coverage of it; for instance, a minimal or canonical cover of a set of FDs is a cover with no redundant dependencies nor superfluous attributes, and with a single attribute on the right part of each dependency.
So, actually, it is easy to prove that a definition that mentions superkeys, like the wiki definition, for instance, is equivalent to a definition that mentions candidate keys, like those of your lecture notes, when the functional dependencies considered are those of a minimal cover. In fact, in a minimal cover trivial dependencies are not present, as well as no strict superkeys (i.e. a superkey formed by a candidate key plus a non-empty set of attributes) can be present as left part of any dependency, for the definition of minimal cover.
So, when checking for a normal form, it is always a good idea to first find a minimal cover of the given dependencies.
For what concerns the functional dependencies of your example, given the specification of the problem, it is not clear to me if a student selects a reasearch topic and then can go to any supervisor for that research topic to discuss it, or instead is assigned also to a specific supervisor. Of courses the dependencies are different in the two cases.
students are to select one research topic
student -> research-topic
Because each student has only one research topic, and these are the only two attributes in this relation, we know student is unique, and thus a candidate key.
Students are allowed to select the same research topic.
That tells us research topic is not unique in the same relation, and cannot be a candidate key.
For each research topics, supervisors are assigned to supervise it.
research-topic -> supervisor
A supervisor may be supervising up to two different research topics
So supervisor is not unique in this relation, and cannot be a candidate key.
each research topic may be assigned to different supervisors.
OK, revise (1st time)
research-topic, supervisor -> {}
Each researcher many have more than one topic, and each topic more than one researcher.
For each of the research topic a supervisor supervises, a consultation day is allocated for the student
2nd revision:
research-topic, supervisor, student -> consultation-day
This is a bit messy, perhaps intentionally so to create a problem to solve. Since each student has only 1 research topic, For each of the research topic is a red herring. We can equally well say:
3rd revision:
research-topic, supervisor -> {}
and
supervisor, student -> consultation-day
It's unnecessary to put topic in the key of the 3rd relation because when the student meets with the supervisor, it will be on the student's only topic. If a student could have more than one topic, we'd have to add that to the relation, to know what's on the agenda on consultation-day.
to meet and discuss with the supervisor.
Call these three relations student, supervisor, and consultation. I leave it to you to write a join to produce {student, topic, supervisor, day}, and show that the natural join of student with supervisor produces only 1 row.
All I have done is express the stated requirements as dependencies. Every dependency is minimally captured. That, in essence, is BCNF.
Your student table is not BCNF. Nowhere is it stated that students choose or are assigned a supervisor.
I'm trying to understand how to normalize a database, and one of the exercise given by our teacher was to normalize in BCNF this table:
Flight(**CityDeparture,CityArrival,Day**,NationDeparture,NationArrival)
where (CityDeparture,CityArrival,Day) is the primary key.
So I assumed that:
1)The city name is unique independently from the nation (there can not be two nation with the same city, even if that is not true in reality), otherwise the primary key would be wrong.
2)The functional depencies are
CityDeparture->NationDeparture
CityArrival->NationArrival
Meaning the table was not even in 2NF, so I decomposed it like so:
Flight(CityDeparture,CityArrival,Day)
there are no non-banal FD so it is in BNCF, right?
CityD(**CityDeparture**,NationDeparture) CityDeparture->NationDeparture
is in BNCF because CityDeparture is key
CityA(**CityArrival**,NationArrival) CityArrival->NationArrival
is in BNCF because CityArrival is key.
I also considered the fact that CityA and CityD could be identical unless every city has a different code of departure/arrival(i.e. NewYork has code 'AAA' if a flight leaves from there and code 'BBB' if a flight lands there) so one could just have a single City(Name,Nation) table and both CityDeparture,CityArrival would reference it.
The decomposition should also be lossless because City.Name is a common attribute for both tables and is key for City (I'm quite unsure about this)
When I showed this to my teacher it just scored 0 and told me to go read the book without further explanation. Now I did read the book, and the articles I found linked around here but I'm honestly clueless, so I'm asking for your advice! Any help would be appreciated
1)The city name is unique independently from the nation (there can not be two nation with the same city, even if that is not true in reality), otherwise the primary key would be wrong.
On the one hand, your reasoning here is correct. On the other hand, many (most?) textbook normalization exercises don't include keys at all. You're usually expected to derive all possible keys from the dependencies. Maybe your teacher expects you to ignore the existing key.
Another possibility is that your teacher wanted you to include the FD {CityDeparture, CityArrival, Day} -> {NationDeparture, NationArrival}.
Another possibility is that your teacher wanted you to explore the dependencies within the primary key. Are there any multi-value dependencies?
If your book includes an algorithm that you can do with pencil and paper--most of them do--try working through it that way. See what you get.
Your decomposition of
Flight(CityDeparture,CityArrival,Day,NationDeparture,NationArrival)
into
Flight(CityDeparture,CityArrival,Day)
CityD(CityDeparture,NationDeparture)
CityA(CityArrival,NationArrival)
gives you indeed BCNF.
Regarding the last step, the unification of CityD and CityA: This is not justified by your functional dependencies, and thus incorrect from a formal database perspective. It would be justified by further context knowledge. In practice, it would of course make sense in most settings.
Keep in mind that database normalization is a formal discipline, and so are its algorithms. Substitute artificial names for your relation, e.g., R(A,B,C,D,E) with the same keys and functional dependencies - the result must be same up to renaming.
EDIT
This assumes that the primary key and the two functional dependencies CityDeparture->NationDeparture and CityArrival->NationArrival were given as part of the exercise - otherwise see Mike's answer.
I am trying to show the following in the ER diagram:
There are instructors and courses, a course is taught by only one instructor
whereas an instructor can give many courses.
My question is, is there any difference between two diagrams, in other words, does it matter which line we turn into an arrow, or what only matters is only the direction of the arrow?
Also, if we think about the mapping cardinalities; is it 1 to many or many to 1? If we think in terms of courses, then it is many to one but if we think in terms of instructors, then it is one to many. How do we decide this?
Thank you.
In ER diagrams when the relationship is denoted the arrows are not used. Some instructors use this arrow when they want to decide the cardinalities but that is just to get the cardinality (1:1, 1:M and N:M)
I have attached the ER diagram for this in Chen notation and also using Crow Notation you can use either of them.
Deciding the cardinality for a relationship is a practical scenario there is no hard and pass rule to obtain it. What you need to do is start from one side of the relationship and take one tuple (instance) and see how many tuples from the other entity participate for the relationship. Then do the vise versa. Then you know the participation number of tuples) from each entity to the relationship. Think about set theory and functions in mathematics when you decide the cardinality (ie Set of instructors, Set of Courses and set of Teaches relationship type) then this is so easy but if you are not from a mathematic background just think of practical scenario.
For Example
a) For 1 instructor he or she can teach Many (M) courses
b) For 1 Course there is only 1 instructor
so in instructor side there is always 1 in a) and b) but in Courses there is M and 1 in a) and b) there for Instructor:Course cardinality is 1:M
I don't think the other answer is fully correct.
I would say that one should use arrows, and one should use a notation that gives a meaningful name to each direction of the relationship. In this case it will be "teaches" in one direction, and "is taught by" in the other. Either use arrows next to the names or put the name near to the entity to which it refers. You could use one line (with two arrow heads) or two lines (with one arrow each).
I would also suggest that cardinality is just one kind of constraint, and the notation should reflect that. For example, the two names for the relationship could be "teaches (many)" and "is taught by (exactly one)". The point is you might have "teaches (one or two)" or "is taught by (exactly two)" and so on.
It is better to be explicit and clear about exactly what your constraints really are.
Both are having exactly opposite cardinality
🔸Simple clean line means many.
🔸Arrow means one.
If we consider both with same cardinality.
then, many to many should be represented by following the second convention as (please assume diamond for relationship set and rectangle for entity set)
INSTRUCTOR <---- TEACHES -----> COURSE
which is actually of no meaning.
If we consider both with opposite cardinality.
then, many to many should be represented by following the second convention as (please assume diamond for relationship set and rectangle for entity set)
INSTRUCTOR ----- TEACHES ------ COURSE
No explicit arrow is always considered many to many. So, it is correct (only if we consider both opposite)
Consider an 'employee' entity set and 'department' entity set, having relationship set as 'manage'.
Employee-------------Manage--------------------Department
(entity set) (Relationship set) (entity set)
One to many relationship means one entity of employee set can be associated with more than one entity of Department entity set but, an entity of Department set can be associated with at most one entity of employee entity set.
That means if there is one to many relationship between employee and department entity sets, then each employee can manage more than one department and at the same time each department is managed by at most one employer.
Can anyone tell me what is chasm trap? Perhaps fan trap too as I'm not too clear. Also, please provide easy to understand examples (via Chen notations).
My understanding thus far: I understand that Fan trap is M:1:1:M, which suggests the paths between entities is ambiguous.
I understand that. For example, if M represents Student and the other M represents School then it'll be ambiguous because we don't know which student studies at which school (that's what I understood so far).
However, I cannot grasp what is chasm trap.
Also, how can I identify the traps and then fix it?
Based on Conolly&Begg:
Fan trap occur in a situation when a model represents relationship between entity types however a path between certain entity occurrences is ambiguous.
Example:
(Staff)-1:N-has-1:1-(Division)-1:1-operates-1:N-(Branch)
in this model it may be impossible to determine the branch a staff belongs to, in the situation when staff belong to division having more than 1 branches.
Restructuring the model resolves trap
(Division)-1:1-operates-1:N-(Branch)-1:1-has-1:N-(Staff)
Chasm trap occur when a model suggests relationship between entity types however a path between certain occurrences does not exist.
Example:
(Branch)-1:1-has-1:N-(Staff)-0:1-oversees-0:N-(PropertyForRent)
Because Staff relationship to PropertyForRent is with optional participation (0:1) for staff the path for Branch to PropertyForRent may not exist. Solution to this would be direct relationship between Branch and PropertyForRent with mandatory participation.
In simple word, for both the cases (FAN & CHASM) it will produce more line(result sets) than actual. How to identify
FAN -> 1-N-N means table relation from one -> many -> many
CHASM -> N-1-N means one row table to two or more table many relation
LOOP -> join all tables and when make loop like circle (In this case we will lose some rows absolutely)
Nothing to identify but when you create Universe than we have to keep our eyes open, if you see out of these situation while developing Universe than there will be a problem always. So rectify by applying aliases, context.
Once all problems solved at Universe level than we are good to go for reporting. By practice you will have excellent knowledge.
I fan trap occurs when three tables joins in a fashion where there realtion to each other is 1 to many way. means table A B and C are in join as .. table A links to table B in one to many and table B to table C relates again one to main way A-->B-->C.
I tried to consolidate everything I learned about normalization in this blog post
http://geekyisawesome.blogspot.com/2011/03/database-normalization-1-2-3-nf.html
but I need to make sure that I understood everything correctly. Could you notify me of any mistakes?
Thanks
Normalization doesn't mean "replace values with ID numbers".
Normalization also doesn't involve terms like weak entity, bridge table, or junction table.
I wouldn't say there are any mistakes. The examples are sound. I like the fact that you showed a couple of different ways of doing 1NF.
I would say that the post is a little bit confusing. Perhaps you might consider laying out a precise statement of what each NF is as you get to it and include a short description of what the attending anomalies are for 1NF and 2NF. That way, when you go through your sample relations, it will be clearer what the problems are and why the next NF is a solution rather than just another way of doing it. I found the transitions from one NF to the next weren't crystal clear. A neophyte would benefit more from clearer distinctions between each NF, since it can be hard to keep straight in your head at first, as you pointed out in your introduction.
I like how 3NF can be summed up in the old addage: "The key, the whole key, and nothing but the key, so help me Codd." This is very succinct and highlights all of the important attributes of a relation in 3NF. Each attribute must depend on the key (1NF) the whole key (2NF) and nothing but the key (3NF). This is useless for explaining normalization but it's a great way to remember it once you've learned it.