1. Final Project Preliminary Designs Pretty good designs. Remember that design is an iterative process. Don’t get married to your design. OK to change. You will implement this model in Access. If it doesn’t work you won’t be able to populate the database or query it. If you had red ink on your design come see me again with the final design before you implement it.

2. Common problems/issues Many-to-many relationship between presenter and proposal – not limited to just one co-presenter. Review question scores – only question number and the score for each review is recorded. Questions are not kept in this database. These are for individual and consensus reviews. Proposal and consensus review have one-to-one relationship. Be careful with primary keys. Do you have enough attributes to uniquely identify each instance? Year as discriminator for speaker and reviewer. A person can be a speaker/reviewer in multiple years. Review Captains – recursive or two relationships between group and reviewers?

3. Think about order of real world events and affects on db How should we connect consensus review, individual review, review group with proposal? The order these things happen is reviewers and review groups and proposals are first. Next is assignment of proposals to review groups. Then individual reviews happen. Then consensus reviews are conducted. And finally final status of proposal is determined. If we connect review group to consensus review then how can we assign proposals to review groups before consensus reviews occur? It may seem conceptually right to connect group to consensus review, but as long as the groupid is in proposal we can do joins to get info out?

4. SQL Functions (again) What happens with NULLS with Ave, Count, etc? NZ function allows values to be used where NULLS are NZ (expression, ValueIfNull) SELECT NZ(dateDue,"no due date") FROM Rental; Sort by aggregate function? either use function again or use ordinal position in output table

5. Views Virtual Tables – contents defined by queries Called Saved Queries in Access Used just like tables Purpose: Security – limiting access to data Query development – modularity

6. View Advantages Security – restrict user access to only subset of data. Specific to each user (group). Modularity – they allow programmers to create modular queries. Simplicity – users can create their own views to simplify complex tables Consistency – if underlying tables change, views can remain the same

7. View Disadvantages Performance – they appear to be tables but need to be created on-the-fly each time the view is referenced in a query. No indexing on views. Update Restrictions – simple views may allow updates, but complex views usually are only read-only

8. Video videoIddateAcquiredmovieIdstoreId 1011/25/19981013 1112/5/19971233 11212/31/19951235 1134/5/19981235 1144/5/19981895 1233/25/19861233 1455/12/19951455 775644/29/19911893 909873/25/19994503 9978710/10/19979875 movieIdtitlegenrelengthrating 101The Thirty-Nine Stepsmystery101R 123Annie Hallromantic comedy110R 145Lady and the Trampanimated comedy93PG 189Animal Housecomedy87PG-13 450Elizabethcostume drama123PG-13 553Stagecoachwestern130R 987Duck Soupcomedy99PG-13 Movie Rental accountIdvideoIddateRenteddateDuecost 1031011/3/20021/4/2002$1.59 1011114/24/20025/2/2002$3.99 1011124/24/20024/30/2002$1.99 1011132/22/20022/25/2002$3.00 1011142/22/20022/25/2002$3.00 10312312/1/200112/31/2001$10.99 1011452/14/20022/16/2002$1.99 101775644/24/2002 101909871/1/20021/8/2002$2.99 101997871/1/20021/4/2002$3.49

9. Create View Let’s find all rented comedy videos using a view. CREATE VIEW comedyvideos AS SELECT * FROM Movie m INNER JOIN Video v ON m.movieId=v.movieId WHERE m.genre like ‘*comedy*'; m.movieIdtitlegenrelengthratingvideoIddateAcquiredv.movieIdstoreId 123Annie Hallromantic comedy110R1112/5/19971233 Annie Hallromantic comedy110R11212/31/19951235 Annie Hallromantic comedy110R1134/5/19981235 Annie Hallromantic comedy110R1233/25/19861233 145Lady and the Trampanimated comedy93PG1455/12/19951455 189Animal Housecomedy87PG-131144/5/19981895 Animal Housecomedy87PG-13775644/29/19911893 987Duck Soupcomedy99PG-139978710/10/19979875

10. Use that in another query SELECT c.videoId FROM comedyvideos c INNER JOIN Rental r ON c.videoId=r.videoId; videoId 111 112 113 123 145 114 77564 99787

11. Inline View You can also put a “view” in the FROM part of the SQL statement. That is, a SELECT that SELECTS from a view. SELECT c.videoId FROM [SELECT * FROM Movie m INNER JOIN Video v ON m.movieId=v.movieId WHERE m.genre like '*comedy*']. AS c INNER JOIN Rental r ON c.videoId=r.videoId;