This database was designed to provide information on journal articles and annotations for the Fall 2005 session of LSC 508 and for classes during the next five years. There are two main users of this information. This knowledge is useful for current and future students of LSC 508 and professors teaching this course. A student in LSC 508 will be able to access this information to search for journal articles of interest pertaining to the class. This can be done without repeating work done by other students by searching the same online databases. They might also use it for research on databases or information and communication theories for class projects. Theory groups can use the database as a bibliographic resource guide for assigned information theory projects. Professors can use the database to find interesting articles to share with the class and to monitor student participation. This time saving tool is valuable in a course that is labor intensive.

Microsoft Access 2000 was used to store the data for the annotations. The required APA style provided the format for the field data used. An example of the original APA form required for the course is shown below. A sample of the screen design used can be found at the end of this report.

Annotation #1
Last, F.M., & Last, F.M. (year). Article title. Journal Title, volume(issue), page-page.
Annotation...fifty words or less!!!

Data entry was easy using the Access data view input form provided. I used "record #" as the primary key, followed by these columns: "student id #", "annotation #", "author name","date of article", "article title", "journal name", "volume #", "issue #", "page #" and "annotation". Setting up "record #" as the unique primary identifier allows multiple students to enter multiple annotations over the course of a five year time span. Choosing "annotation #" as the primary key would not allow differentiation because the students would all have the same annotation numbers (1-10). Choosing the "student id" as the primary key would result in each student having only one record each. Records could still be sorted by student for grading purposes without "student id" as the primary key. Assigning "record #" as the primary key might be the best way to overcome these two issues and others.

Although the design view feature of Access provides default values for field sizes, I chose to modify some of the values to save storage space. The data type "text" was selected for some of the numeric fields ("student id" and "page #") to allow for the addition of alphabetic and Roman numerals as well as the "dash" (-) character. The default text field of 255 characters was too short for the annotations so data type "memo" was preferred to accomodate the length. A character count of the longer annotations concluded that the average memo size equaled 300 characters. In addition, the data range of the number fields was analyzed to optimize the size of each number field. An analysis of the database information is found in the following table.

Total record input requirements = 581 bytes

Size of each record: 581 bytes
Maximum number of students in five years: 750
(Estimated at 25 students per section x 2 sections per semester x 3 semesters per year x 5 years)

Maximum number of records per student: 10
(Required number of records per student to be entered on database)

Maximum size of the file in five years: 4,357,500 bytes or 4.36 MB
(Estimated at 750 students x 10 records each x 581 bytes per record)

Computer capacity of current HP home computer: 50.8 GB with 5.6 GB of free space

Any PC that has the necessary Windows and Microsoft Access software installed and the available space on the hard drive to accomodate the database could be used.

Upon further analysis, I could envision an additional table in the annotations database. I can see the need for a class roster table that would include the fields: student id #, student last name, student first name, student middle initial, term (fall, spring, summer) and the term year. The unique identifier between the two tables would be the student id. This could be used to purge the records of all students with annotation records older than five years old. One limitation is that this only allows for students taking the class once. A student who fails the class or drops out part way through might then have more than ten annotations recorded. Further analysis would need to be done to come up with an optimal solution.

This database would be located on a University of Rhode Island, Graduate School of Library and Information Science site and maintained and updated by a graduate student intern or the professor. Data entry would be performed by current LSC 508 students through supervision of the professor. Security for the database can be provided by Access through setting up either share-level security or user level security. Share-level security allows you to assign a password to the database and anyone who knows the password can open the database. Changing the share-level security password every semester would prevent unathorized users from opening the database and restrict use to current students only. User-level security requires more work by creating users and groups and granting either implicit or explicit permission. User-level security would be more appropriate if the database had more than one table and you would want to control access to certain data on an individual user level.

Database screen design view

Report produced by D. Gaye Kulvete
LSC 508- Database Assignment
Fall 2005