Scribd
Upload
1 views4 pages

project1-SQL

The document outlines the requirements for designing a code-versioning system (CVS) database for a software development company, detailing user, project, document, and access log attributes. It specifies tasks for implementing the relational schema and populating tables with data, along with SQL queries to retrieve specific information. The design includes constraints on document ownership, project coordination, and access logging, emphasizing the need for maintaining current ownership and access details.

Uploaded by

46bdyt8wmn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
1 views4 pages

project1-SQL

The document outlines the requirements for designing a code-versioning system (CVS) database for a software development company, detailing user, project, document, and access log attributes. It specifies tasks for implementing the relational schema and populating tables with data, along with SQL queries to retrieve specific information. The design includes constraints on document ownership, project coordination, and access logging, emphasizing the need for maintaining current ownership and access details.

Uploaded by

46bdyt8wmn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

CEN224 - Database Management Systems

Term Project
Spring 2020

1 Database requirements
Tasks:

(a) Read through the database requirements listed below.


(b) Observe the corresponding ER diagram (to be covered in class) in Fig. 1,
and relational schema in Fig. 2.

Deliverables: None.

Design a code-versioning system (CVS) database for a software development company


based on the following requirements.

• Every user has a name, multiple e-mails and a unique username.


• Every software project developed by the company is referred to with a unique name and
version combination. Together with this information, the following data of a project
are stored:
(a) a textual description of the project and,
(b) the root directory (that contains documents related with the project).
• Documents are identified by their absolute path.
• Every document has exactly one owner, who is a user. Document ownership is estab-
lished upon document creation and the timestamp of this event is kept in the database
explicitly. Ownership can later be transferred but the “date created” property of a
document cannot be modified.
• The database does not keep any history of document ownership. Only the current
owner information is maintained.
• Every project contains at least one document. However some documents may not be
contained in any project, such as personal files.
• Users contribute to multiple projects. For each user working on a project, the user’s
contribution start-date and end-date are stored. Assume that once a user stops working
for a project, he/she cannot work for the same project again. Therefore, there is only
one start-date for each user working on each project.

1
• The database also keeps the duration of time each user worked on a project. Notice
that this value can be calculated easily based on the start-date and end-date fields
described above.
• Every project is coordinated by a user. A coordinator may coordinate multiple projects
concurrently.
• The most important part of the database contains access logs of users. Whenever a
user accesses a document, an access log entry is created by the system.
• Each access log entry contains the following information:
(a) type of access: either ‘R’ for read, or ‘W’ for write, ‘RW’ for read and write,
(b) event timestamp: the date and time when the user accessed the document, and,
(c) a field called “difference”.
• The field “difference” is textual (i.e., is a string) and contains all the details needed
for undoing an edit operation by a user. Think of this field as an incremental backup
of the document.
• Over time, it is natural that a user will have multiple access log entries for a document.
• However, a user cannot have two access log entries on the same document with the
same timestamp.

Notes on the design:

• Assumption: A document is contained in at most 1 project. Therefore,


the relationship Contains between Document and Project is 1:M. This
relationship is implemented with a relationship relation because of personal
files.
• There is no way to enforce the constraint “every project has a document”
unless a non-null document reference is added to Project. However, this
does not make any sense.

2
Figure 1: ER diagram

2 Implementation of the DB
Tasks:

(a) Implement the relational schema in Fig. 2 on the DBMS of your choice.
(b) Once the implementation is over, populate every table with a reasonable
number of tuples (at least 5 for tables representing entities and 10 for tables
representing relationships ).
(c) Write SQL queries retrieving the information specified below.

Deliverables: SQL statements. Specifically, submit:

• “CREATE TABLE” queries for part (a),


• “INSERT INTO” queries for part (b), and,
• “SELECT FROM” queries for part (c).

3
User Project

UName FName MInit LName Name Version Description RootPath CoordUName

Document ProjDocs UserEMail

AbsPath OwnerUName DateCreated PName PVersion AbsPath UName EMail

LogEntry WorksFor
UName AbsPath TS Type Diff UName PName PVersion StartDate EndDate

Figure 2: Relational schema

Queries (replace the variables P, D, U, etc. with a suitable value from the domain):
(1) Select the last names of users working on project P.
(2) Select the count of access log entries on document D.
(3) Select the amount of time user U spent on project P.
(4) Select the first name and last name of users that store a personal file on the system.
A file that is not part of any projects is a personal file.
(5) Select the coordinator that coordinates the highest number of projects.
(6) Select the path to the most recently updated document.
(7) Select the number of documents owned by user U.
(8) Select the users that work on all projects coordinated by user U.
(9) Select the project that has the highest number of versions.
(10) For each user-project pair, list the number of access log entries. Order the result set
by count in descending order.

You might also like