Actors represent a group of people that have the same position or role within the organization. Identifying the various actors that will interact with the database can help you organize the tasks that they will perform, and ensure that the database meets
- [Instructor] Requirements gathering, out of necessity demands that you become an expert in the organization that you're developing the database for. In some cases, you'll already be familiar with the data storage needs to some degree. More often, however, you'll be an outsider that needs to get up to speed with all of the intimate details of the organization. After collecting documents and process details on the current system, you'll have a pretty good sense of how data should move through the organization. You'll probably have also started to implicitly identify who is responsible for the various data tasks.
Now let's turn those unconscious observations into a formalized step in the database development process. You'll do this by first identifying all the types of people that will need to interact with the new system. These user groups are traditionally called actors and they represent a group of people that all have the same position or role within the organization. At this point, we're still not looking to identify specific people, though. We'll do that soon enough. Actors in this sense are groups like account executive, salesperson, warehouse manager, warehouse assistant and so on.
Depending on the size of the organization, these user roles might actually be performed by the same individual person. In small organizations, think of actors as the different hats that a person would wear as they move throughout their day. It's also important to look outside the organization as well and include external actors like our all important customer and product vendor. If you need help making sure that you've got everyone, go back to your mission objective statements and for every objective on the list, ask yourself, who would take on this responsibility or benefit from this? You should also make sure that you don't identify any actors that don't have a corresponding mission objective.
Even though the human resources department is an important piece of the organization, if the mission objectives don't mention anything about maintaining employee records, then you'll want to leave HR out of this particular project. Once all of our actors are identified, then we'll need to start outlining the specific tasks that they will need to do to accomplish the mission objectives. The traditional development process involves drawing stick figures that represent each type of actor and then connecting them with arrows to all of the tasks that they perform which were drawn in large bubbles. This technique comes from a method of diagramming called unified modeling language or UML notation.
I personally don't find this type of diagramming all that helpful. Instead, I simply produce a series of pages in my notes, one page for each actor, and then list out the tasks that each one needs to perform below. That's what works for me, but you might find a more diagrammatic approach helpful depending on your style. However you want to record the information, it's time to start developing how each actor will accomplish their mission objectives. For instance, if the actor that we're working with is the warehouse manager, and one of the identified objectives is for the database to provide order details to the warehouse, then the specific tasks might look something like this.
One, be alerted to new transactions as they occur. Two, obtain a list of products ordered and their quantities. And three, produce a shipping label with the customer's address. We might have another mission objective that says something like, update order delivery information. Depending on the organizational structure, this might be a task for an account representative actor, or perhaps it's also the responsibility of the warehouse manager. If so, we'll add a few more tasks to their sheet in the notebook. These tasks can include input package tracking number into the database and email the customer the estimated delivery date and tracking information.
So go through your mission objectives and the notes that you develop during the review of the current database system and identify all of the actors that will have a stake in the new system. Once the actors list is compiled, you can begin assigning tasks required to meet the mission objectives. Keep in mind that some actors will share tasks. For instance, both the warehouse manager and the warehouse assistant actors might share responsibility for generating tracking information and sharing it with the customer. And that's okay. You want to make sure that each actor has a complete list of specific tasks regardless of what others are doing.
Adam Wilbert covers the basics of relational database design, regardless of whether you use Access, FileMaker, Open Office, or SQL Server. Learn how to prevent data anomalies, gather requirements to plan your design, and develop a conceptual data model—translating your ideas into components like tables, relationships, queries, and views. Plus, learn about logical design considerations that can help you construct a database that is easy to maintain.
- Identify the three rules of relations.
- Summarize the four stages of developing a relational database.
- Describe a strategy one might use to ensure a database remains flexible in terms of the questions a user can ask.
- Explain how to avoid scope creep.
- Recall the characteristics of a Lookup Table.
- Recognize situations in which denormalization would be beneficial.
- Understand the types of relationships modeled by junction tables.
- Define referential integrity.