Reference no: EM131532244

You will join a self-formed group with maximum of four members per group for project works. A project will be of each group's own specification and design, drawn from one of these broad areas:

Experience portfolios, which can include experiential records along different thematic lines, as diverse as travel to formal coursework, informal learning accomplishments (e.g., open, online courses), volunteer/work/internship experience, resumes, and samples of notable projects;

Health records, which can range from personal health records to institutional health records, which can include health-related behavior tracking (e.g., exercise, meals), perhaps special readings (e.g., blood glucose, blood pressure), medication schedules, and physician visits;
Entertainment and Leisure, which can be in areas of music, movies, gaming, art, and athletics, with records on stated and unstated preferences (e.g., through viewing, purchasing, playing, and other analog behaviors that are appropriate to the domain);

Sustainability and Ecology, which can range from wildlife monitoring applications, backpacking, tree tours, public and private transportation (e.g., ride-sharing and routing), and recycling (but should probably avoid energy and water monitoring as we deal with this in one of our sample projects, unless you can imagine creative ways of expanding this theme, such as through social networking).

The focus of your database specifications can be on individual-level data, on institutional-level data, on regional/national/world level data, or some span of these granular levels. Importantly, however, I want each project to include some "social networking" component. Social networking can be overt social links, like "friend" or "following", and/or "hidden" links, such as those that we can imagine are used in recommender systems.

Teams must be formed by end of week 4. At the end of wee 5, your team should submit topic selection and writeup: A good and brief description of what an initial (or functional) specification can look like is given here. This will be a one paragraph description of what FUNCTIONS you want the database to support (e.g., a music library, social network, and recommender system), perhaps with a bullet list of specific tasks. You will have a chance to revise the functional specification in the coming weeks.

Each group submits ONE Project PDF document, which includes a functional specification (possibly revised); followed by one UML (probably revised); followed by CREATE TABLE, CREATE TRIGGER, CREATE VIEW, and CREATE ASSERTION definitions; followed by SQL queries.

For the functional specifications follow the guidelines promulgated earlier. An opening paragraph should be an overview of what the database is intended to support, with bullet items that follow on main categories of function. The functional specification focuses on what the DB is to support - it is NOT an English description of the DB itself - we have the UML for that.

UML diagrams cannot be hand-drawn, but should be done in Powerpoint (or similar tool that can be used to produce UML consistent with the class UML conventions).

The table and assertion definitions must be neat (no random line breaks), with comments as appropriate. The table and assertion definitions, in particular, should logically implement the UML diagram.

This deliverable will include at least one CREATE TRIGGER statements and at least two CREATE VIEW statements. The triggers can be INSTEAD OF triggers to implement operations on VIEWS, and/or BEFORE/AFTER triggers to approximate the conditions dictated by assertions. In the final deliverable, there will be additional triggers and views required.

This deliverable will include at least fifteen queries, at least two of which will include GROUP BY and HAVING clauses and at least two of which will include join clauses. This deliverable will include at least one INSERT, at least two UPDATE, and at least one DELETE.

Typically, comments on CREATE statements will be header comments, appearing before the CREATE, but in-line comments are fine too. In the header comments, identify primary authors of each CREATE statement and each query, and secondary reviewers of these CREATE and query statements. In the final deliverable, there are minimums defined on the definitions by individuals.