Log in / create account Page Discussion Edit History Go to the site toolbox

DBAGroupProj

From BluWiki

Welcome to the Group 1 projectspace. Feel free to add stuff to it. Latest Files Here

Contents

[edit] Company Name

In course of working on this it has been discovered that we need a name for ourselves. Two names have been suggested but more suggestions are welcome. If you would like to throw your support behind one or the other, feel free to do so. A majority will decide the name.

  • Isotech technologies
    • (Mike)
  • Initech
    • (Chris)

[edit] Task Layout

[edit] MANAGEMENT

[edit] Forms

  • Order inventory
  • Add/edit/remove employees
  • Train employee
  • Add/edit/remove members
  • Add/edit/remove courses
  • Add/edit/remove classes
  • Add/edit/remove rooms
  • Add/edit/remove equipment
  • Add/edit/remove manufacturer
  • Add/edit/remove sale
  • Add/edit/remove vendor

[edit] Reports

  • Sales
    • Total Sales (date range)
    • Last month, last year, daily
  • View current employees
  • View current members
  • View employee salaries (salary range as option)
  • View courses
  • View classes
  • View rooms
  • View equipment
  • View Suppliers


[edit] EMPLOYEE – FRONT DESK

  • Add/edit/view/remove members
  • Class signup
  • View available class schedule

[edit] EMPLOYEE – CASHIER

  • View members
  • View class schedules
  • Add sale

[edit] EMPLOYEE – INSTRUCTOR

  • View class schedule

[edit] Phase 2 Signups

Please signup for jobs below. After you finish any task please email the access file to chotchki@mail.usf.edu. I will merge the file and post it to chotchki.us

[edit] Application Prototype

  • Create Tables - Mike - Done
  • Create Relationships - Andy - Done
  • Create Task list in the form of a switchboard -
  • Create Forms -
  • Create Reports - Andy - -Chris -
  • Create Queries -

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).

[edit] Documentation (the application prototype must be finished first)

  • Administration Doc-
  • Cashier Doc-
  • Member Management Doc-
  • Etc--

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.)

[edit] Phase 1 Notes

Bring two bound copies

[edit] 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.


IN PROGRESS

NOTE: We need to mention something about how our system will help them market to customers by providing automatic notices when the member's join date anniversary is approaching so that cards or special offers can be sent out. We should assure Fit-4-Life that we understand that the health and education of the member's is the most important aspect of their business, and our system will help them achieve their goals by never running out of stock, and providing accurate scheduling of classes with fully-qualified instructors.

Also mention "included in this package are...brief description of the deliverables" and "Upon your approval, we will do ...(what)in Phase 2 of the project."

At the beginning, thank Fit-4-Life for considering our company, we are confident that our system will provide you with the perfect solution for your small business. or something...-Matt

After careful consideration of your company’s business needs, we feel that we can accommodate you. By considering several factors, we have narrowed the benefit of having a database system to one main point. Tracking is the first and main step in creating a successful solution for your business. By keeping track of every component in your business, daily operations will run more efficiently and will be more profitable.
The system would mainly keep track of customers not only for manager use, but also customer service use. If a customer needs to sign up for a membership or even change an address, an employee will be able to create, edit and delete accounts with ease. Sales made by employees can also be linked to what customer made the purchase. By keeping track of the customer, your business will be able to determine how many people have a membership, and even report age ranges with report generators at the click of a button.


By having a database system, many different types of reports can be generated besides age ranges to assist in making management decisions. Whether you require a marketing report sent to all the customers or an employee’s date of birth, you can count on our system to make it easy to find what you need. Change is not always easy, but we make the transition smooth by training your employees on how to use the system. We also have a live working manual online as well as a 24 hour/7 days a week customer service team dedicated to making your system use as easy as possible.
A very important report generated by the system would be daily sales. No longer will managers have to guess what money income has been made or look throguh piles of paper to find the sales for a particular day. With the system, managers and employees will be able to enter a date in order to examine the daily sales for the day. This report will give managers an idea of how to proceed in order to be most profitable.


Other benefits would include the use of maintenance and warranty issues on exercise equipment. Written documents may be an efficient way to note a small amount of exercise equipment, but once the quantity of equipment increases this can be more complicated. By utilizing database functions, the maintenance can be handled properly and on time to avoid any accidents or other problem situations. Each piece of equipment can also be tracked to avoid the possibility of theft.

[edit] 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.(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.

http://www.sharphosts.com Image:DBAGroupProjERD.png

[edit] 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.

[edit] 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.)

[edit] Membership Type

Field Name Description Primary Key? Foreign Key? Data Type Field Size Input Mask Value Constraint Indexed? Default Value
Membership Name The name of the membership type. Yes No VarChar 255 This should not be end-user edited. The only inputs will be "Platinum, Gold, Silver, and Bronze". No No default.
Join Fee The inital membership cost. No No Currency Auto A positive decimal value. Any value greater than 0. No No default.
Percentage Discount The discount for the member on each purchase. No No Number Auto A positive value. Any value between 0 and 100. No No default.

[edit] Member

Field Name Description Primary Key? Foreign Key? Data Type Field Size Input Mask Value Constraint Indexed? Default Value
First Name Members First Name No No VarChar This should not be end-user edited. There is no value constraint. No None
Last Name Members last name No No VarChar This should not be end-user edited. There is no value constraint. Yes None
Street Members strees address No No VarChar/Numeric Street value There is no value constraint. Yes None
City Members city address No No VarChar City value Only one city No None
State Members State No No VarChar State Value Only one State No FL
Zip Members Zip No No Numeric Zip code value no less than 5 and no more than 9 digit Yes None
Phone Members Phone Number No No Numeric Phone number value Must have 3-didget area code and 7-digit telephone Number Yes City's Area code
Join Date Member's date he/she joined No No Numeric End-user edited Format must be in xx/xx/xxxx Yes None
Date of Birth Members birthday No No Numeric Date of Birth Value Form must be in xx/xx/xxxx Yes None
Gender Male or female No No VarChar End-user edited Only Male or Female No None
Member ID Member's Identifing Number Yes Yes Numeric This should not be end-user edited Can not be outside the specified member id Yes None

[edit] Sales Order

Field Name Description Primary Key? Foreign Key? Data Type Field Size Input Mask Value Constraint Indexed? Default Value
Transaction Number Number of the sales order Yes Yes Numeric Number value for transaction Can only be within the specified transaction numbers Yes None
Transaction date Date os the sales order No No Numeric Number value for date Format must be in xx/xx/xxxx Yes Todat's date
Member ID Member's unique identification No Yes Numeric This should not be end-user edited Must be within specified member id numbers Yes None
Employee ID Employee's unique identification No Yes Numeric This should not be end-user edited Must be within specified employee numbers Yes None

[edit] Sales Line

Field Name Description Primary Key? Foreign Key? Data Type Field Size Input Mask Value Constraint Indexed? Default Value
Transaction ID Unique transaction identification Yes Yes Numeric This should not be end-user edited should be within specified transaction numbers Yes None
Item ID Unique item identification No Yes Numeric End-user may edit or may be set up not to edit No value constraint Yes None
Quantity Purchased Number of items purchased No No Numeric Positive value for quanity Value must be greater than 0 No None
Unit Price Cost of each item No No Numeric Positive monitary value Value must be greater than $0.00 No None

[edit] Item

[edit] Supply Line

Field Name Description Primary Key? Foreign Key? Data Type Field Size Input Mask Value Constraint Indexed? Default Value
Field Name Description Primary Key? Foreign Key? Data Type Field Size Input Mask Value Constraint Indexed? Default Value

[edit] Supply Order

Field Name Description Primary Key? Foreign Key? Data Type Field Size Input Mask Value Constraint Indexed? Default Value

[edit] Vendor

Field Name Description Primary Key? Foreign Key? Data Type Field Size Input Mask Value Constraint Indexed? Default Value

[edit] Employee

Field Name Description Primary Key? Foreign Key? Data Type Field Size Input Mask Value Constraint Indexed? Default Value

[edit] 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.)



FINAL Bringing Mockups to class

1. Annual Marketing Report

Purpose: To notify members of special offers as well as a thank you letter for continuing to be a member.

Recipient: The marketing department would receive the report and use the data to send out letters.

User-definable Parameters: Date

Sorting, Grouping, Totaling: Members names will be sorted by alphabetical order.

2. Equipment Maintenance Report

Purpose: To keep track of maintenance tasks associated with equipment to keep the equipment safe and in good working use.

Recipient: Managers

User-definable Parameters: Date to view current maintenance

Sorting, Grouping, Totaling: ID Numbers will be sorted numerically.

3. Daily Sales Report

Purpose: To track daily sales.

Recipient: Managers

User-definable Parameters: Date, employee

Sorting, Grouping, Totaling: All transactions will be totaled in one report.

4. Inventory Report

Purpose: To determine product in stock.

Recipient: Inventory Managers

User-definable Parameters: date

Sorting, Grouping, Totaling:sorted by item ID


5. Class Listing

Purpose: Lists current classes as well as days and times

Recipient: Customers

User-definable Parameters:date

Sorting, Grouping, Totaling:sorted by order number

Retrieved from "http://bluwiki.com/go/DBAGroupProj"

Site Toolbox:

GNU Free Documentation License 1.2
 This page was last modified on 5 March 2008, at 04:18. - This page has been accessed 22,936 times.
Disclaimers - About BluWiki