Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Relational Database: Union Compatibility Question


Hi,

According to one reference, the union compatibility is defined as
such:
(1)the two relations have the same degree n (number of attributes) ,
and (2) domain (Ai)= domain (Bi) for 1=data type.

In other reference, it is stated that two relations are union
compatibles if they have the same degree and the *same attribute
names* and domains. The *order of attributes is immaterial*.

which one is the fully correct?


I don't believe that the two relations should have the same attribute
names as stated in the 2nd definition , but i understand that each
pair of the two relations attributes should be of the same domain.
what about the order of attributes? Has it to be the same?

I understabd from the first definition that the attributes domains
order should be the same unlike in the second definition. which one is
correct?

The relational database is based on the concept of sets where the
order of rows and columns is not important. This tends to support
definition 2. However, if we assume that each relation has two
attributes of the same domain (eg 10 char), how the Union operator can
choose between them when mapping the attributes of relation A and B,
having different relative attributes orders


for instance Relation A schema is Fname,LName, City , Age;
the second Relation B schema is City1,FName1,Age1,LName1

where Fname,Fname1,LName,LName1 is restricted to be of 10 chars

A Union B=?


Another question, can the foreign key be NULL? are all the DBMS case
(un)sensistive?



<:> thank you <:>

Comments

  • infidelinfidel Member Posts: 2,900
    : According to one reference, the union compatibility is defined as
    : such:
    : (1)the two relations have the same degree n (number of attributes) ,
    : and (2) domain (Ai)= domain (Bi) for 1=: data type.
    :
    : In other reference, it is stated that two relations are union
    : compatibles if they have the same degree and the *same attribute
    : names* and domains. The *order of attributes is immaterial*.
    :
    : which one is the fully correct?

    I don't know. I would think the types are more important than the names.

    : I don't believe that the two relations should have the same attribute
    : names as stated in the 2nd definition , but i understand that each
    : pair of the two relations attributes should be of the same domain.
    : what about the order of attributes? Has it to be the same?
    :
    : I understabd from the first definition that the attributes domains
    : order should be the same unlike in the second definition. which one is
    : correct?

    Again, I would lean towards the data types being consistent. I don't think UNION has much to do with relations as with selected values. I see it as merging together two otherwise unrelated queries. If you don't have the same number of values, or if the types of values in corresponding positions are inconsistent, the DBMS can't know how to merge the two sets into one set.

    : The relational database is based on the concept of sets where the
    : order of rows and columns is not important. This tends to support
    : definition 2. However, if we assume that each relation has two
    : attributes of the same domain (eg 10 char), how the Union operator can
    : choose between them when mapping the attributes of relation A and B,
    : having different relative attributes orders

    Again, I do not believe you are unioning relations, but are instead unioning query results from those relations. Query results are not ordered row-wise, but they are ordered column-wise.

    : Another question, can the foreign key be NULL? are all the DBMS case
    : (un)sensistive?

    I believe a foreign key can be NULL (meaning the record is an orphan).

    I believe SQL is defined as case-insensitive.


    [size=5][italic][blue][RED]i[/RED]nfidel[/blue][/italic][/size]

    [code]
    $ select * from users where clue > 0
    no rows returned
    [/code]

Sign In or Register to comment.