The member’s data will be collected by entering all the information from a membership form. The data will not be entered into the database until all the fields on the form are complete. An example of the membership form will be shown later in this section.
The supplier’s data will have to be entered from the current lists. It will be difficult to enter this data if the current list has been lost. The current procedure if this happens is to re-make a list of suppliers’ names from their current stock, and re-make the complete list by contacting the respective suppliers. By going through the stock, most of the data of the items supplied will be found. However, in some cases, contact will be necessary.
Validation of Data: Members
The data entered may be wrong when being entered. Verification and validation will help to get round this problem. Project operates a system in their skateparks, where anyone under 17 MUST wear a helmet for protection. This is down to insurance reasons. Helmets, however, are not the most fashionable piece of clothing you could ever wear, and many members try to find a way out of getting out of wearing them. Therefore, careful attention must be paid when taking down members’ details to make sure that the data is checked against any valid form of identification
I.D. number: This is automatically created by the database as a key field. This has a default value of 000, but will increase in value for each new member.
Name: This can be checked against any forms of identification, e.g. bus passes, library cards, national insurance cards (if applicable)
Date of birth: There is an obvious mistake if someone gives a birth date making them out to be 102. However, minor mistakes, such as a year or two out, can be checked against the DOB’s on bus passes, national insurance cards etc. The format will also have to be correct, as it is being entered in the format DD/MM/YY. The date field will be set to take only the U.K. format, which is the same as above, whereas the American format is MM/DD/YY.
Date of registration: the staff will fill this in as the data is entered. The same validation checks as above will be entered.
Member’s full address: The staff can check this in the same way as the name, age etc. They should ask for any forms of identification which contain all this information.
Members telephone number: Validation for this will be rather difficult, as there are very few, if any, forms of identification that give out a telephone number for legal reasons. Therefore, the number should be phoned as soon as possible to verify that the phone number is correct.
Suppliers
Suppliers are not going to give out false information to a company/shop, not if they want to stay in business. This means that Project will not have to worry about finding out if information is true, but making sure it is entered correctly.
I.D. number: This is entered in the same way as the i.d. field for the members database.
Name of supplier: As mentioned above, the only problem is making sure that this goes in properly e.g. Shorttys instead of Shortys.
Address of supplier: This is an absolute must to be entered correctly. Whereas in the name, if a mistake was made, it would still be easy to tell what the name was. However, in the address, a mistake in the number or street could go unnoticed, therefore delivering orders, mail etc to the wrong address.
Phone number of supplier: This, again, must be entered correctly for the reasons listed above. Project could find themselves desperately short of stock if they could not contact the suppliers to place orders.
Name of product supplied: Not only does Project have a large list of suppliers, each supplier also has a list of products supplied to Project. This means that there is a lot of data to do with stock needing to be entered correctly. Again, the only way to do this is visually – making sure there is no mistake when entering in the data.
Item number: Every product has a different item number. This insures the “uniqueness” of each product, so that the stock system knows exactly what product is sold.
Type of product: Project doesn’t just sell skateboards. They sell shoes, clothes, accessories, hardware, safety gear and more. Rather than have to check in the storeroom what a product is, the database can simply tell them. This must have the type entered correctly. The only chance of a typo occurring in this is if I make a mistake during the implementation. The data in this field is selected from a drop-down list.
Price of product: If the price is wrong, customers will be over/under charged. This will not be good for Project. If they undercharge, they lose money. If they overcharge, they lose customers. Therefore it is greatly important that the price is entered correctly.
