DBAGroupProjReq

From BluWiki

Back to main page.

ISM 4212-001 – Database Design and Administration

TEAM PROJECT – Spring 2006

INTRODUCTION

In this project your team will model an organization’s data needs and will design and develop a database applica­tion prototype using Microsoft Access 2003. (Access 2000 or 2002 may also be used, but files will be evaluated using Access 2003.) The business scenario of interest is described on attached pages. Project grading will be based on the quality of the analysis and design; the accuracy, thoroughness, and professionalism of the printed deliverables; the actual software prototype implementation of the database model; the contributions of all individuals to the team effort; and the presenta­tion of the work to the class. All deliverables must be generated with computer software.

The project will be divided into two phases and a presentation. The specific project deliverables required of your team for each phase and the presentation are described below. Read these requirements thoroughly and carefully.

PHASE I

• Executive Overview

Write a 1½-2 page description of your team’s initial analysis of the business scenario as it pertains to the design of a database application. Write this as though you are writing to the client for whom you are performing the analysis. You should communicate your team’s vision for what the system being designed is to accomplish. Thus, describe the specific functions that your system is to perform. Be detailed. This overview should communicate to the client exactly what the proposed system will be capable of doing. If you have made any significant assumptions in your analysis that affect the design of your system, include these here. Then, briefly (approximately one paragraph) list and describe the other sections in this phase’s deliverable package. Close the overview by briefly (approximately one paragraph) describing what will be done in the next phase of the project.

• Conceptual Data Model (Entity-Relationship Diagram)

Provide a conceptual data model for your proposed system using an entity-relationship diagram. You may only use the type of notation described in Chapters 3 and 4 in your textbook. (Any deviations from this notation must be pre-approved by your instructor.) Show all relevant entities and the relationships between these entities, including the cardinal­ities of the relationships and their optionalities. Attributes of the entities must be shown using the same notation as that shown in the textbook (including derived, composite, and multivalued attributes, if any exist in your diagram). The attribute(s) that serve as the identifier for each entity must be underlined. Do not include any foreign keys at this point (they will be identified in the next step). Many-to-many relationships may be converted into associative entities if desired (or required by the circumstances), but be consistent in this.

• Logical Data Model (Normalized Relational Schema)

Using the graphical notation for creating a relational schema as described in Chapter 5 of your textbook (see, for example, Figure 5-5), prepare a logical data model that reflects the data and relationships of this business as they would be implemented in a RDBMS based on the information presented in the ERD from the previous step. Your schema should reflect relations that are in third normal form (3NF). Make sure that the field(s) comprising the primary key of each relation is (are) underlined. Include referential integrity constraints using the arrow notation as seen, for example, in Figure 5-5. (Omit dashed-underlines for FKs, however). Also, include designations of functional dependency using the line and arrow notation as seen, for example, in Figure 5-23. Use different arrow styles to clearly distinguish the referential integrity arrows from the functional dependency arrows. You should minimize the crossing of lines and avoid entirely the overlapping of lines in your diagram.

• Data Dictionary

The data dictionary should define all fields used in the database. The format to be used is flexible, but should include such information as the field name, description, primary key and/or foreign key designation (if applic­able), data type, field size, input mask and/or format, any constraints on allowable values (e.g., valida­tion rules or required field settings), and any other field properties (e.g., index settings, defaults, etc.) deemed necessary. (Note: It is not acceptable to simply use the Microsoft Access automated documentation tool.)

• Report Designs

Identify and describe 5 (only) of the most important (in your opinion) printed reports the system will need to generate. Include both a textual descrip­tion and a report mockup for each report. The textual description should include the purpose of the report, the recipient(s) of the report, any user-definable parameters that can be used in generating the report (e.g., date range for data), and any sorting/grouping/totaling used in the report. The report mockup is to be a representation (e.g., created with a word processor) of what the printed report will look like. Sample data is to be used to show where actual data will be displayed on the printed page. Include an adequate amount of data to demonstrate the report features. Headers, footers, and totals are to be shown where applicable. These preliminary report designs should help you verify that the database design being proposed is adequate to provide all necessary information. (The final report designs in the Phase II prototype may differ somewhat in appearance from these designs. Also, additional reports beyond these five will be necessary in Phase II.)

PHASE II

• Application Prototype

For the software application, you are to create a working relational database prototype using Microsoft Access 2003 (or Access 2000/2002). Your prototype should demonstrate your implementation of the work you submitted in the previous phase (incorporating any changes necessary based on corrections made to the earlier work). Your application must include at least 50 sample records in the larger of your tables and an appropriate amount of test data in each of the other tables. You should demonstrate your command of Access tables, queries, forms, reports, and macros. (VBA modules may be included if desired, but are not required.) You are encouraged to make your proto­type as attractive and professional in appearance and operation as possible. Be creative and ambitious! How­ever, it is better to have a modest application that is well-designed and works reliably than a flashy one that has flaws and experi­ences errors. Your prototype file (which may be zipped, if necessary) must be turned in on a labeled 3.5” floppy disk along with the documentation package (see below).

• Documentation

Accompanying the prototype must be a detailed printed user’s manual. The user’s manual should be designed to provide a novice system user with all the information necessary to successfully use the application to perform all the functions for which it was designed. A very high level of professionalism is expected in the preparation of this document. The user’s manual should include screen shots from your application where useful. A detailed Table of Contents is expected. The manual should also include an Appendix that contains sample outputs of all system reports. (You may assume that the future users of the system are familiar with Microsoft Windows.)

PRESENTATION

Each team will present their completed prototype to the class. In addition to Microsoft Access, teams may make brief use of Microsoft PowerPoint. The presentation should be designed to run exactly 15 minutes and each member of the team must contribute fully to their group’s presentation. Thus, all students must verbally participate in their team’s presen­tation. Typically, groups simulate a presentation to the potential buyers and/or users of the application. (Note: The data projector used for the presentations will be set at a video reso­lution of 1,024 x 768. This is also the PC screen resolution that will be used by the instructor in evaluating the prototype.)

PROJECT GRADING

• Phase 1 40 points
• Phase 2 40 points
• Presentation 10 points
• Individual Assessment 10 points

DELIVERABLES

Each team is to submit TWO complete copies of its work for Phase I (one I will keep, one I will return) and ONE copy of Phase II (which I will keep). For Phase I, submit both copies in one 3-ring binder (to allow easy removal of pages for side-to-side comparisons). The second copy should be complete (including title page) and placed in the binder at the end, separate from the first copy. Phase II submissions may be in a 3-ring binder or spiral-bound. A table of contents with page numbers and/or labeled tabbed dividers for each phase’s deliverables will be expected. Do not use plastic sheet protectors for your pages. Label the Phase II disk appropriately, and provide a means (other than tape) to ** SECURELY ** contain the disk in the binder. [It is recommended that students make and keep a complete copy of their group’s work for future reference and/or inclusion in their professional portfolios.]