113
Data requirements. That is what attributes the database must contain in order to store all the
information an organization needs for its activities. To record a point of sale transaction, for example, the database would need to have attributes for the sale number, the date, the customer, the items and quantities purchased and the prices of those items among others.
Report requirements. Most databases need to generate several different kinds of reports,
summary information often gathered from several different entities. The entities must contain the data needed to make these reports, as above, but also be related in a way that makes it possible to bring the various pieces of data together. This is a function of relational design which we shall look at in detail in the next chapter.
Access and Security Requirements. Often some, or all, the data in a database is confidential.
Databases typically contain core business information that could be of great value of to a competitor, or it may contain things like credit card numbers or social security numbers that could pose financial and legal risks if revealed to the wrong people. An essential requirement of most databases is to develop a security schema that determines who has access to what data.
Anyone without the proper authentication credentials should be excluded.
Chapter Two looked at most of the techniques for gathering requirements: interviews, questionnaires, review of documents, and job shadowing. From those it is necessary to distill the requirements into a usable list. One of the techniques, used in this chapter, is to look at the requirements in terms of each user who will interact with the database. What does the database need to do and contain for that user to successfully complete his or her tasks? The chapter starts with the higher level approaches, looking at the general requirements first and then getting down to the detail of what attributes and entities the database needs to contain. This approach can help organize what is admittedly a complex task.
114
Finally, it is essential to review the requirements you find with those who will be using the database.
Having a full understanding of the requirements is crucial if you are to develop a successful database.
Leaving out requirements, even small ones, may render the entire database useless to the organization.
Thinking about this, Sharon remembers that Professor Collins had told her to make sure that she looked at the requirements in terms of each of the stakeholders for the database. That gives her a place to start. First she will look at the tutors. What does the database have to do for each tutor? She writes out a list:
Allow tutors to enter their monthly schedules
Allow tutors to view the schedule to see which sessions have students signed up
Allow tutors to cancel a session
Allow tutors to fill out and submit a session report
She ponders for a moment trying to decide if there is anything else the database has to do for tutors. It has to allow their hours to be tracked for payment. But that’s requirement seems to belong more to the Tutor Administrator.
Sharon decides to list all the requirements she can for students next. For students the database must:
Allow student to register for tutoring (includes entering demographic data and current courses)
Allow the student to view session schedule
Allow the student to sign up for session
Allow student to cancel a session
Sharon isn’t sure of the last one. Are students allowed to cancel their own sessions? She will have to check with Terry when they review the requirements together.
115
Thinking of Terry, Sharon decides to list the requirements for the Tutoring Administrator next. For Terry the database must:
Allow her to view session schedules
Allow her to add and remove tutors
Allow her to add and remove courses
Allow her to view student requests
Allow her to view and summarize session reports
Sharon thinks about this for a moment. There are other reports Terry needs to view, besides just reports on the sessions. And it might be possible that she needs to be able to generate new reports. Sharon adds a few more items to Terry’s list of requirements:
View and generate reports
Summarize tutor hours for payroll
There a couple more actors who will be involved in the database. In addition to the Tutoring Administrator, there will need to be a database administrator. She or he will need to maintain the database by backing it up regularly, and will need to maintain it security, especially for student information. IT staff members will need to make the database available over the network and secure access to it. Sharon decides not to diagram these for the moment.
116
Another set of requirements involves Access and Security. Sharon knows that she will have to fully develop these in the database itself, but for now she just makes a few notes. First she looks at the Access requirements for Terry:
The database administrator should have select access to the all the data. That means he or she can view all the data in the tables.
The database administrator needs to be able to add, edit and remove records for tutors and courses
The database administrator should be able to create queries as needed
The database administrator should not be able to create or remove tables or other database objects?
The last one she will have to check with Terry, but her basic instinct is that no one except the database administrator should be able to add or remove database objects.
Things to Watch Out for
It is essential that you include security considerations in your planning from the beginning. Too often developers wait until after the database has been designed and developed to think about the security issues of a database. Adding security as an afterthought can result in an insecure database, vulnerable to data theft or to accidental violations that can result in a loss of data integrity.
Next she thinks about the tutor:
A tutor needs to be able to enter and edit their own schedules but no one else’s.
A tutor needs to be able to enter a session report
A tutor needs to be able to cancel one of their own sessions, but no one else’s.
A tutor should not be able to see student information.
117 Lastly, she looks at students:
A student must be able to view all available sessions
A student must be able to enter their own demographic information
A student must be able to enter the courses in which they are currently enrolled
A student should be able to cancel one of their own sessions, but no one else’s.