27 views

If $D_1 , D_2 …. D_n$ are domains in relational model then the relation is a table, which is subset of

1. $D_1 \oplus D_2\oplus...D_n$
2. $D_1\times D_2 \times...D_n$
3. $D_1\cap D_2 \cap...D_n$
4. $D_1\cup D_2 \cup...D_n$
| 27 views
0
0
Do we apply the same approach as Discrete Mathematics where relation is nothing but $D_1\times D_2.. D_n??$
0
Is it Option (b) ?
0
Yes..

+1 vote

I would say option(b).

Option(a) - XOR obviously makes no sense.

Option(c) - this implies that tuples will only be formed when domains have something in common with them

Option (d) - this implies that a tuple may not have one field from each of the domains, in the right order.
i.e. consider two domains/attributes
$A = \{a1, a2\}$, $B = \{b1, b2\}$. $A\cup B = \{a1, a2, b1, b2\}$.
If you consider a tuple to be a subset of $A\cup B$, then a possible tuple is $\{b1, b2\}$, $\{b1, a1\}$ or even $\{a1, a2, b1, b2\}$ which is clearly wrong.

Option(b) is correct, because a cartesian product of the domains means an ordered set with one entry from each domain, and all such combinations. Each such ordered set is a tuple, and a relation is obviously is a subset of all these tuples.

Pretty much the same concept from Set Theory. Although its interesting to go into analyzing each of the given options and seeing how they apply to database relations.

by (1.9k points)
selected by
0
0

Confidence with this sort of question comes with experience in reading SQL - no shortcuts.

Knowing how nested queries work helps as well. In this example - the innermost query is referring to an attribute from the outermost query. Translate it in your mind to some sort of for-loop.

foreach (tuple "employee" whose age > 30 in EMP) {
X= "find all pid's for projects named 'database' ";
Y= "find all pid's this employee works for";
if (X - Y != empty) {
//i.e. there exists some database projects that this employee doesn't work for
}
}

Obviously don't waste time converting SQL to C or anything - I just mean to illustrate how you could think about it.

i.e. the inner query(ies) is running for each tuple in the outer relation. Visualize that, or simply draw up a table with about 5 records and evaluate it. Whichever approach you take, you should be able to do it 3-4mins max.

Edit: if you were to interpret the pseudocode above - it would mean "fetch all employee id's such that there are some database projects the employee doesn't work for"

0
$WOW$

U explained it in simple terms.. $THANKS$ $A$ $LOT$
0

But what does this actually try to say, and how u converted this in that simple term of yours?

I am getting lost in here

+1
That circled area is trying to pick all project ID's of projects that a given employee works on.

This SQL query as a whole is trying to pick all the employees who aren't working on every database project. Maybe the boss wants to know which employees aren't contributing to all the database projects ? Who knows.
0
ok .. :)