Download Report

CITS2232 Assignment 2 - Sample Solution
School of Computer Science and Software Engineering
The University of Western Australia
April 12, 2012
Question 1: SQL
Consider the following conceptual schema - the schema is described in the
format used in the recommended reading text, which should be completely
intuitive.
Suppliers (sid: integer, sname: string, address: string)
Parts (pid: integer, pname: string, colour: string)
Catalogue (sid: integer, pid: integer, price: real)
The “Suppliers” relation describes suppliers of parts which are described
in the “Parts” relation. The “Catalogue” relation lists the prices for each part
charged by the various suppliers. The keys for each relation are underlined.
Write SQL queries to perform the following tasks (you do not need to use
the aggregate functions).
1. List all suppliers of part number 12, cheapest first.
SELECT Suppliers.sname
FROM Suppliers, Catalogue
WHERE Catalogue.sid = Suppliers.sid
AND Catalogue.pid = 12
ORDER BY Catalogue.price ASC;
Note: Whilst the query might give you by default the result set ordered
in the ascending order (cheapest first). I did ask you to sort them in
the ascending order, thus I did expect to see the ASC keyword used,
especially in the exam situation.
2. List the names of all parts that come in both red and blue.
SELECT PA.pname
FROM Parts PA, Parts PB
WHERE PA.pname = PB.pname
AND PA.colour = ’red’ AND PB.colour = ’blue’;
3. List the name of every supplier that supplies a mauve-coloured part,
with no duplicates.
1
SELECT DISTINCT Suppliers.sname
FROM Suppliers, Parts, Catalogue
WHERE Catalogue.sid = Suppliers.sid
AND Catalogue.pid = Parts.pid
AND Parts.colour = ’mauve’;
4. Find the price of the most expensive orange part.
SELECT Catalogue.price
FROM Parts, Catalogue
WHERE Catalogue.pid = Parts.pid
AND Parts.colour = ’orange’
ORDER BY Catalogue.price DESC LIMIT 1;
Alternative answer accepted such as:
SELECT Max(Catalogue.price)
FROM Parts, Catalogue
WHERE Catalogue.pid = Parts.pid
AND Parts.colour = ’orange’
Question 2: ER Diagram
Draw and ER Diagram for the following scenario, a real estate firm employs personnel and lists for sale properties that have owners. The following
describes the organisation:
• The firm is made up of several sales offices in various locations. Attributes of the sales office include an office number (identifier) and a
location.
• Each sales office has one or more employees. Each employee has an employee id (identifier) and a name. Each employee can only be assigned
to one sales office.
• Each sales office has one of its assigned employees designated as the
manager of that office.
2
• The firm lists properties for sale. Each property has a property id
(identifier), and location information consisting of a street address, the
city, state, and post code.
• Each property is exclusively listed with one sales office. Each sales
office may have many properties listed, including none.
• Each property has one or more owners. The percentage of ownership
is an attribute of the relationship between an owner and the property.
Each owner has an owner id (identifier) and a name. An owner may
own one or more properties.
3
Note: For clarity of the diagram, all links of type “partial participation”
are drawn here as dotted thin lines rather than the usual solid thin lines.
Two relationships were tricky to categorise:
1. “An owner may own one or more properties”, represents a partial participation between the Owner entity and the Owns relationship, since
strictly speaking they don´t have to own any.
2. there is a partial participation between the Sales office entity and the
Works in relationship. The statement was “Each sales office has one
or more employees”, but when there is only one employee, they are
the manager by definition. Hence the total participation is enforced
through the relationship with Manages. This subtle difference will
get clarified when you consider how to implement the database in a
RDBMS, as you will see later in Question 3. If you have full participation indicated from “Sales Office” to “Works In” it will still be marked
as correct, but the above solution is preferred.
Question 3: From ERD to Database Schema
Implement your ER diagram from Question 2 as a database schema. Give
the specification of each table you will implement. You can use the format
used for describing the schema in Question 1 (you don’t have to provide the
SQL DDL descriptions).
The schema that best fits this problem domain is outlined below:
Owner (o_id: integer PRIMARY KEY,
o_name: string)
Property (p_id: integer PRIMARY KEY,
p_adress: string,
p_city: string,
p_zip: integer)
Owns (p_id: integer FOREIGN KEY REFERENCES Property(p_id),
o_id: integer NOT NULL FOREIGN KEY REFERENCES Owner(o_id),
percent: real)
4
NOT NULL for o id in Owns ensures a property in Owns has at least one
owner. However we can´t enforce that every property is within Owns using
just key constraints. That requires CHECK, ASSERTIONS or TRIGGERS
to check these things. More on this can be found in the Unit’s Lecture notes
(See “Database - constraints and Triggers”, page: 430-444).
In considering the Sales office, Lists and Property relations we note that
the property can only appear once in the relationship and it MUST appear.
This is a case where the key and participation constraints make it possible
to embed the Lists relationship in the participating entities rather than in a
separate table. The Sales office table is simple but we need to update the
Property table. Since Property can only have one Sales office, we include
the s id in the Property table (ensuring there can only be one), and make it
NOT NULL (enforcing total participation).
Sales Office (s_id: integer PRIMARY KEY,
s_location: string)
Property (p_id: integer PRIMARY KEY,
p_adress: string,
p_city: string,
p_zip: integer,
s_id: integer NOT NULL FOREIGN KEY REFERENCES Sales office(s_id))
The Sales office and Employee entities share two relationships. You could
create two tables one for each relationship. If you do this then there is
mutually exclusive e id values in the Manages and the Works in tables. That
is, an employee either employed by or is a manager of a sales office. To
work out who works in the office you would need to take the UNION of the
two tables with the e id projected out. However taking into account the
key and participation constraints means we can embed these relationships
in the participating entities. In addition, as the Employee shares the same
relationship with Sales office as did Property. There only be one Sales office
for the Employee and the employee MUST be attached to an office. Thus as
before we opt for this option.
Employee (e_id: integer PRIMARY KEY,
e_name: string,
s_id: integer NOT NULL FOREIGN KEY REFERENCES Sales office(s_id))
5
Manages is a one to one relationship. Similarly we embed the relationship
in one of the entities, but now we have a choice where to do it. The best
choice is given by the business logic. We can embed another FOREIGN
KEY Sales office(s id) in Employee which identifies which sales office they
are the manager off. Most will be NULL because most employees are NOT
managers. However if that individual leaves, you have lost the manager
connection entirely. You also can’t guarantee that two employees are BOTH
managers of the same sales office. A better solution is to have the e id as
a foreign key in the Sales office tables. There can only be one and you can
enforce the participation constraint.
Sales Office (s_id: integer PRIMARY KEY,
s_location: string,
e_id: integer NOT NULL FOREIGN KEY REFERENCES Employee(e_id))
You will need to use programmatic means (CHECK, ASSERTIONS or TRIGGERS) to ensure the (s id, e id) pairs in Sales office agree with (e id, s id)
from Employee.
6