[Tuesday, Feb 22, 10:35]

> I suspect that the answers to Excercise 4 in Summer99 Midterm is
> incorrect.
> The right key should be more restrictive than the left key.
>
> The following state would violate the right key but is okay for the left:
> Meeting 2/16/00 from 10am to 12pm
> Meeting 2/16/00 from 11am to 12pm
>
> The left model does not have the "to" time as the key, thus allowing
> meetings to be scheduled with the same "to" time.

No, my solution is correct: The key {Date, From_Time} is more restrictive
than the key {Date, From_Time, To_Time}.
But keys are difficult and very many students got this wrong in the midterm
exam of Summer 1999.

The key {Date, From_Time, To_Time} is only violated when you have two rows
which agree in all three attributes.
Your example would not violate this key because the two rows differ in the
From_Time, which is part of the key.
You would be right if the key were {Date, To_Time} or only {To_Time}.
These keys are violated in the example.
But {Date, From_Time, To_Time} contains From_Time, and your two rows differ
in From_Time, there is no problem.

In general, if the attributes in a key K1 are a subset of the attributes in
key K2, then K1 is stronger than K2, so the database states which K1 allows
are also a subset of the database states which K2 allows.

I hope this helps.

-------------------------------------------------------------------------------

[Tuesday, Feb 22, 10:55]

>     What is the answer to Exercise 8 on the Midterm Example II.  These
> were some incorrect SQL queries.  I did not see anything wrong with the
> first query.  Thanks

This was a bit tricky.
The SQL standard and Oracle require that you use single quotes '...' for
string constants.
In the example query, double quotes "..." were used.
In the standard and in Oracle, you would use double quotes only for delimited
identifiers, i.e. when you have a table name or a column name which contains
spaces or other non-alphanumerical characters or when you want to protect
lowercase letters.
But this is not very practical (you must use the "..." in every query which
access the table/column), so it happens seldom.
It is most often used when you define output column names, e.g.
        SELECT ENAME, SAL*12 "Yearly Salary"
        FROM EMP
Here "Yearly Salary" will be printed as the name of the second column in
the query result. You can do it without quotes, but then you must avoid the
space and will get only uppercase letters, e.g.
        SELECT ENAME, SAL*12 Yearly_Salary
        FROM EMP
This will print the column name YEARLY_SALARY (all SQL input except in quotes
is turned into uppercase).

By the way, SQL server accepts "..." for strings. But this is non-standard.