1 / 29

Database Midterm Regulations and Practice Queries

Know the regulations for the upcoming database midterm on Feb 7th and practice advanced SQL queries. Topics include ERD, Relational Algebra, and SQL Commands. Solve exercises on warships database. Study effectively!

jfried
Download Presentation

Database Midterm Regulations and Practice Queries

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Revision Instructor: Mohamed Eltabakh meltabakh@cs.wpi.edu

  2. Midterm Regulations • Midterm is Feb. 7th (11:00am – 12:30pm) • Covers until before the Views • You answer in the same exam paper • Closed-Book, One sheet is allowed for your notes

  3. Topics Covered in Midterm • Entity-Relationship Model & ERD • Relational Model • Relational Algebra • SQL Commands • DDL: Creating tables • DML: inserts, updates, deletes, querying

  4. Relational Algebra & SQL

  5. Relational Algebra: Key Points • Understand the meaning of each operator and what it does, E.g., • Selection (σc): selects certain tuples based on a condition (all columns) • Projection (πk): selects certain columns (All tuples) • Join (⋈C): joins tuples from one relation with another relation based on a condition • Practice how to combine these operators to answer queries • Performance rules: • Apply selection earlier whenever possible • Use joins instead of Cartesian product • Avoid un-necessary joins

  6. SQL: Key Points • Understand the Select clauses and their order of execution • Practice the grouping and aggregation • Understand when to use “Where” or “Having” • Practice the nested queries optional SELECT<projection list> FROM<relation names> WHERE <conditions> GROUP BY <grouping columns> HAVING <grouping conditions> ORDER BY <order columns>;

  7. Exercise (War Ships) ShipClass(name, type, country, numGuns, designYear, weight) WarShips(shipName, className, builtYear) Missions(missionName, date) Results(shipName, missionName, status) • Ships having the same design belong to the same class. The class information is stored in “ShipClass”. The ship information is stored in “WarShips” • Each ship may participate in multiple missions. The mission information is stored in “Missions” • Each ship in a mission has a status as either ‘damaged’, ‘sunk’, or ‘ok’. This information is stored in “Results”

  8. Query 1 For classes with at least 10 guns, report the class name and country; Select name, country FromShipClass WherenumGuns >= 10; • πname,country (σnumGuns >= 10(ShipClass))

  9. Query 2 List the warShips built after 1932 • σbuiltYear > 1932(WarShips) Select * From Warships WherebuiltYear >1932;

  10. Query 3 Suppose there was an agreement prohibiting war-ships heavier than 40,000 tons. Report the ship names and built year of ships violating this agreement. • πshipName,builtYear (σweight > 40,000(ShipClass) ⋈name=className WarShips) SelectshipName, builtYear From Warships, ShipClass Where name= className And weight > 40,000;

  11. Query 4 Continue from the previous query, Find the ship(s) that violate the agreement the least (i.e., the lightest ships violating the agreement) • R1 minW<-min(weight) (σweight > 40,000(ShipClass)) • Result  πshipName, weight (R1 ⋈minW=weight ShipClass ⋈name=className WarShips) Inner select: Select min(weight) From ShipClass Where weight > 40,000

  12. Query 4 (Cont’d) Continue from the previous query, Find the ship(s) that violate the agreement the least (i.e., the lightest ships violating the agreement) • SelectshipName • From Warships, ShipClass • Where name= className • And weight = ( • Select min(weight) • FromShipClass • Where weight > 40,000);

  13. Query 5 In the mission of “Sun Rising”, find the name and weight of the ships involved • R1 πshipName(σmissionName = ‘Sun Rising’(Results)) • Result  πR1.shipName, weight (R1⋈R1.shipName=Warships.shipName WarShips • ⋈className=name ShipClass)

  14. Query 5 (Cont’d) In the mission of “Sun Rising”, find the name and weight of the ships involved Select W.shipName, S.weight From Results R, Warships W, ShipClass S Where R.shipName= W.shipName And W.className = S.name And R.missionName = ‘Sun Rising’;

  15. Query 6 Report ship name for ships that were ‘ok’ in one mission, but later ‘sunk’ in another. • Select shipName • From Results • Where status = ‘ok’ • Intersect • Select shipName • From Results • Where status = ‘sunk’; • πshipName(σstatus = ‘sunk’(Results)) ∩ • πshipName(σstatus = ‘ok’(Results))

  16. Query 7 Report the names of ships damaged in the mission of “Sun Rising”. • πshipName (σmissionName= ‘Sun Rising’ AND status=‘damaged’ (Results)) • Select shipName • From Results • Where missionName= ‘Sun Rising’ • And status = ‘damaged’;

  17. Query 8 Report each shipName and the number of missions it participated in (including 0 participation) • R1  shipName, cnt <-count(*) (Results) • R2  πshipName, cnt <- 0 (πshipName(Warships) - πshipName(R1)) • Result  R1 U R2

  18. Query 8 (Cont’d) Report each shipName and the number of missions it participated in (including 0 participation) • Select shipName, 0 as cnt • From WarShips • Where shipName not in (Select shipName from Results) • Union • SelectshipName, count(*) as cnt • From Results • Group by shipName;

  19. ER & Relational Models

  20. Key Points • Remember the notations used in ERD • Relationships cardinalities (1-1, 1-M, M-M) • Entity sets and weak entity sets • Primitive, derived, and composite attributes • Mapping rules from ERD to relational model, E.g., • M-M relationship  separate table • 1-M relationship  take the key from the one-side to the many-side • 1-1 relationship  take the key from either sides to the other side • ISA relationship  Many choices depending on its type • Remember to indicate the integrity constraints, most important are: • Primary keys, Foreign keys

  21. Airline Application • We have a set of planes, each plane can make many flights. • Each plane has properties such as: ID (unique identifier), model, capacity, year in which it is built, and weight • Each flight has a departure city, arrival city, and it can make transit in many other cities. Also each flight has the departure date, arrival date, and the transit date in each of the transit cities (assume the ‘date’ captures both the date and exact time). • Each flight has some properties such as: FlightNum (unique identifier), number of transit stops, number of passengers • For each city, we have an CityID (unique identifier), name, and country

  22. Question 1 • Design an ER diagram for the given application. The diagram must include: • The entity sets, attributes, primary keys • The relationships with the correct cardinalities • State any assumptions that you make and affect your design

  23. NumStops Num Passengers FNum model year ID capacity Flight makes Plane weight departure date departure arrival transit transit date City Arrival date CityID name country Assumption: The entire flight is done by a single plane

  24. Question 2 • Extend your ERD in the previous question to capture the following additional requirements: • Each flight has one captain, one assistant captain, and between 2 to 4 flight attendants • Each of the captain, assistant captain, and attendants have a common set of properties such as: EmployeeID (unique identifier), name, salary, and DoB • The same person can be captain on some flights and assistant captain on other flights (basically same person can have different roles (captain or assistant captain) in different flights).

  25. Question 3 • Map the ERD from the previous question (Question 2) to the corresponding relational model • Provide the CREATE TABLE commands with the field names and appropriate data types • Identify the primary keys and foreign keys in the relations

  26. Relational Model Create Table Employee ( ID: int Primary Key, name: varchar(100), DOB: int, Salary: int, JobTitle: varchar(100) check JobTitle in (‘Captain’, ‘Attendant)); Create Table Plane ( ID: intPrimary Key, Year: int, Capacity: int, Weight: int, Model: varchar(50)); Create Table City( ID: intPrimary Key, Name: varchar(100), Country: varchar(100)); Create Table Flight( FNum: varchar(8) Primary Key, NumStops: int, NumPassengers: int, PlaneID: intForeign Key References Plane(ID), ArrivalCityID: intForeign Key References City(CityID), DepartCityID: intForeign Key References City(CityID), ArrivalDate: date, DepartDate: date, CaptainID: intForeign Key References Employee (ID), AssistID: intForeign Key References Employee (ID));

  27. Relational Model (Cont’d) Create Table Transit ( FNum: intForeign Key References Flight(FNum), CityID: intForeign Key References City(CityID), TransitDate: date, Primary Key (Fnum, CityID)); Create Table Flight_Attendant( FNum: intForeign Key References Flight(FNum), AttendantID: intForeign Key References Employee(ID), Primary Key (Fnum, EmpID));

  28. Relational Model (Cont’d) • Assumptions: • The ISA relationship is modeled using one table “Employee” • Whether the employee is Captain or Attendant is modeled using a new attribute “JobTitle” • Business Constraints: • Attributes CaptainIDand AssistIDin “Flight” must correspond to employee with job title “Captain” • Attribute AttendantIDin “Flight_Attendant” must correspond to employee with job title “Attendant” • Attribute NumPassengersin “Flight” must be less than or equal to attribute Capacityin “Plane”

More Related