SELECT p.name, a.date, a.time p.groupNo, c.address FROM Appointments a NATURAL JOIN Patient p NATURAL JOIN Clinic c WHERE a.day BETWEEN '2021-03-01' AND '2021-03-10';
SELECT p.name, m.date, v.dosage
FROM Patient p NATURAL JOIN MedicalRecord m NATURAL JOIN Vaccine v
WHERE (v.name = "Moderna") AND (m.date BETWEEN '2021-01-16' AND '2021-02-16);
SELECT s.Name FROM Staff s NATURAL JOIN Staffing st NATURAL JOIN Clinic c WHERE c.Name = 'EZ Clinic' AND st.Date IN ('2021-03-10', '2021=04-05', '2021-05-04');
Select clinicNo, count(*) as staffCount FROM Staffing WHERE Date = '2021-03-05' GROUP BY clinicNo HAVING staffCount > 10;
SELECT clinicNo, COUNT(*) as staffCount FROM Staffing WHERE day = '2021-03-05' GROUP BY ClinicNo HAVING staffCount > 10;
SELECT groupNo, count(*) as groupCount FROM Patient WHERE DateOfBirth < '2000-01-01' GROUP BY groupNo HAVING groupCount > 20;
{ P.name, P.address, P.groupNo, G.description, G.startDate | Patient(P) ∧ Group(G) ∧ P.groupNo = G.groupNo ∧ P.name = 'Brad Vander Zanden'}
{ M.staffNo, M.vaccineNo | MedicalRecord(M) ∧ (∃P)(Patient(P) ∧ (P.patientNo = M.patientNo) ∧ (P.name = 'Brad Vander Zanden')}
{ ST.date | Staffing(ST) ∧ ST.clinicNo = 3 ∧ (∃S)(Staff(S) ∧ (S.staffNo = ST.staffNo) ∧ S.name = 'Jerry Mouse')}
{ P.name, M.date, V.name | Patient(P) ∧ MedicalRecord(M) ∧ Vaccine(V) ∧ P.patientNo = M.PatientNo ∧ M.vaccineNo = V.vaccineNo ∧ ∃(S)(Staff(S) ∧ M.administerer = S.staffNo and S.name = 'Wily Coyote') }
{ P.name, M.date, V.dosage | Patient(P) ∧ MedicalRecord(M) ∧ Vaccine(V) ∧ P.patientNo = M.patientNo ∧ M.vaccineNo = V.vaccineNo ∧ V.name = 'Moderna' ∧ M.date ≥ 2021-01-16 ∧ M.date ≤ 2021-02-16 }
{ C.name, ST.date | Clinic(C) ∧ Staffing(ST) ∧ C.clinicNo = ST.clinicNo ∧ (∃S)(Staff(S) ∧ S.staffNo = ST.staffNo ∧ S.name = 'Bugs Bunny')}
take teach Students------------>Courses<-------------Instructors (a) (b) (c) (d)You may assume that:
For each of the above letters a-d, enter the multiplicity for that entity in the relationship (e.g., (a) represents the multiplicity of students that may occur in the Students take Courses relationship).
Order(customerNo, customerName, city, street, zipcode, dateOrdered, timeOrdered, [productNo, productName, description, pricePerItem, quantity, dateDelivered, warehouseNo, warehouseName, warehouseAddress, quantityAvailable]*, serviceRepNo, serviceRepName, totalOrderCost)
Functional dependenciescustomerNo --> customerName, city, street, zipcode productNo --> productName, description, pricePerItem warehouseNo --> warehouseName, warehouseAddress warehouseNo, productNo --> quantityAvailable serviceRepNo --> serviceRepName customerNo, dateOrdered --> serviceRepNo customerNo, dateOrdered, timeOrdered --> totalOrderCost, [productNo, quantity, dateDelivered, warehouseNo]*The primary key is (customerNo, dateOrdered, timeOrdered)
Answer the following questions.
a b c customerNo --> customerName, city, street, zipcode a b c productNo --> productName, description, pricePerItem a b c warehouseNo --> warehouseName, warehouseAddress a b c warehouseNo, productNo --> quantityAvailable a b c serviceRepNo --> serviceRepName a b c customerNo, dateOrdered --> serviceRepNo a b c customerNo, dateOrdered, timeOrdered --> totalOrderCost, [productNo, quantity, dateDelivered, warehouseNo]*
Note that TransactionDetails is a relation created to handle a multi-valued attribute and would be created when you convert the Order relation from unnormalized form to 1st normal form. I added orderNo to the Order relation to simplify the foreign key for the TransactionDetails relation as repeating the primary key for Order in TransactionDetails would be storage consuming.
Customer(customerNo, customerName, city, street, zipcode)
Product(productNo, productName, description, pricePerItem)
Warehouse(warehouseNo, warehouseName, warehouseAddress)
Inventory(warehouseNo, productNo, quantityAvailable)
ServiceRep(serviceRepNo, serviceRepName)
Orders(orderNo, customerNo, dateOrdered, timeOrdered, totalOrderCost)
TransactionDetails(orderNo, productNo, quantity, dateDelivered, warehouseNo)
OrderHandling(customerNo, dateOrdered, serviceRepNo)
Patient, Clinic, Staff, Vaccine--If you listed Group as an entity I am okay with that. I view Group as a composite attribute, much like a date or an address, which you in this case factor out into a separate relation to avoid redundancy.
Patient(PatientNo, Name, Address, DateOfBirth, GroupNo) Clinic(ClinicNo, Name, Address) Staff(StaffNo, Name) Staffing(ClinicNo, StaffNo, Date) Appointment(PatientNo, ClinicNo, Date, Time) Vaccine(VaccineNo, Name, Dosage, AgeFrom, AgeTo) MedicalRecord(PatientNo, VaccineNo, Date, Administerer (StaffNo)) Group(GroupNo, Description, StartDate)
works at Staff -------------------> Clinic (from Staffing relation) contains Group -------------------> Patient (only if you have Group as an entity) services Clinic ------------------> Patient (from Appointment) Staff | Patient---Administers---Vaccine (from Medical Record)
{ "_id" : 100, "make" : "Ford", "model" : "Fusion", "year" : 2014, "options" : [ "engine start", "moon roof" ], "price" : 135, "location" : { "street" : "1414 Cherry Lane", "zipcode" : 37996 } }
{ "_id" : 200, "make" : "Honda", "model" : "Accord", "year" : 2014, "options" : [ "spoiler", "alloy wheels", "sunroof" ], "price" : 169, "location" : { "street" : "518 Magnolia Ave", "zipcode": 37916 } }
{ "_id" : 300, "make" : "Honda", "model" : "Civic", "year" : 2013, "options" : [ "spoiler", "engine start", "sunroof" ], "price" : 85, "location" : { "street" : "518 Magnolia Ave", "zipcode": 37916 } }
{ "_id" : 400, "make" : "Ford", "model" : "Mustang", "year" : 2021, "options" : [ "turbocharger" ], "price" : 215, "location" : { "street" : "1414 Cherry Lane", "zipcode": 37996 } }
{ "_id" : 500, "make" : "Ford", "model" : "Mustang", "year" : 2019, "options" : [ "turbocharger", "satellite radio", "moon roof" ], "price" : 155, "location" : { "street" : "110 Apple Orchard Circle", "zipcode": 37996 } }
For each of the following Mongo queries, circle the tuples that would be returned by the query (these are all or nothing questions so you must get all tuples correct in order to get full credit):
1 2 3 4 5 : db.catalog.find({ "price" : { $gte : 100, $lte: 200 } }) 1 2 3 4 5 : db.catalog.find({ "location.zipcode" : 37996, options: { $all : ["turbocharger", "moon roof"] } } ) 1 2 3 4 5 : db.catalog.find({ $or: [ { year: 2013 }, { options: { $in: ["turbocharger", "engine start"] } } ] } ) qty : { $gte : 15 } } } })
FlightNo | Date | Departure Time | Departure Airport | Departure Gate | Arrival Time | Arrival Airport | Arrival Gate | CustomerNo | Customer Name | SeatNo | Ticket Price | AircraftNo | Aircraft Model |
---|
You should make the following assumptions:
List the functional dependencies for this table. These are the
ones that I expected you to get:
customerNo, flightNo, date ⟶ seatNo
customerNo ⟶ customerName
flightNo ⟶ departureAirport, arrivalAirport
flightNo, Date ⟶ departureTime, departureGate, arrivalTime, arrivalGate, aircraftNo
flightNo, Date, seatNo ⟶ ticketPrice, customerNo
aircraftNo ⟶ aircraftModel
These are two other ones that I saw that I was fine with
flightNo, Date, seatNo ⟶ ticketPrice (omits customerNo but customerNo might be NULL)
customerNo, flightNo, Date ⟶ seatNo, ticketPrice (but if customerNo is NULL you have a problem)
The original scientific literature on functional dependencies did not consider the possibility of NULL values. I am more comfortable with the first dependency because if a seat is unoccupied, then (flightNo, Date, seatNo) will evaluate to a NULL value for customerNo and that is fine--it indicates an empty seat. The problem with the second dependency is that if the seat is unoccupied, then the flightNo does not have a customerNo for that seat and you have (NULL, flightNo, date) and that will not have a unique right hand side if there are multiple unoccupied seats on the plane. It's really the (flightNo, date, seatNo) that determines the ticket price, not the customerNo. On the other hand, the customer books only one seat so the customerNo does determine the seat where the customer sits. That's why I'm ok with the customerNo determining the seat but not so much with the customerNo determining the ticket price of the seat.
Here are two more that are valid and got you extra credit:
Date, DepartureTime, DepartureAirport, DepartureGate ⟶ FlightNo, ArrivalTime, ArrivalAirport, ArrivalGate Date, ArrivalTime, ArrivalAirport, ArrivalGate ⟶ FlightNo, DepartureTime, DepartureAirport, DepartureGate
When you add 150 to the leaf (100, 200, 300), the leaf cannot accommodate the extra key and hence must be split into two leavings containing (100, 150) and (200, 300) respectively. 200 gets copied up to the parent to represent the new child, giving the parent the keys (70, 100, 200, 400) but the parent now has 5 children, which is 1 too many, and hence the parent must be split into two nodes. The left node gets the additional child and hence points to the leaves (10, 30), (70, 80), and (100, 150) while the right node points to the leaves (200, 300) and (400, 500). When the parent splits, the keys (70, 100) go to the left node and the key 400 goes to the right node. 200 gets promoted to the parent, thus giving the final result shown in the above diagram.