Given that the database is usually designed before the applications are created, you should first examine it closely and attempt to identify and define primary "objects".
For example, a database being used to store corporate order details may contain the following objects:
|
Customers |
|
Orders |
|
Products |
Assign a unique 3 letter identifier (as per the guidelines previously discussed) to each identifiable object stored in the database. For example:
|
Customers |
CUS |
|
Orders |
ORD |
|
Products |
PRO |
Next, examine each object, and decide what "actions" must be performed to satisfy all business requirements. To each "action" (now called a FUNCTION) assign a unique identifier as recommended:
Customers (CUS)
|
|
|
Finally, group the functions, which work on each object type into broad logical "categories". To each "category" (now called a PROCESS) assign a unique identifier as per the standards previously discussed:
Customers (CUS)
|
Orders (ORD)
|
Products (PRO)
|
Note that the assignment of functions to categories (i.e., processes) is completely arbitrary, and may even seem inconsistent at this stage. For instance both customer and product reports have been placed into separate processes, but order reports have not.
The most common mistake made at this stage is to consider that a process is merely a menu. It may certainly be used as a menu, and in many instances works just fine as a menu, but its most important use at this stage is its ability to logically "group" or "categorize" functions together.
