Audience: All users new to Skills Manager.

You have just installed your new Skills Manager software and you are anxious to begin entering your data into the database so you can quickly realize the power, efficiency, and organization that Skills Manager promises. I am thrilled with your enthusiasm, but before you begin hastily forging ahead, I sincerely recommend that you do some old fashioned database planning first. A good plan can save you a lot of effort and frustration. This article will provide guidance in helping you decide just how and where to begin building your database.

Skills Manager provides many data tables that can benefit your organization. These include attributes, employment, education, certification, notes, training, the course catalog, and more. You will be most successful if you implement these tables one or two at a time. Using a scatter gun approach that too quickly implements all, or many of them at once can be overwhelming and confusing. I suggest that you review all of the tables provided by Skills Manager and then choose one or two that will provide the greatest and most immediate benefit to your organization. Concentrate on implementing those you select first and then build on your successes by proceeding to implement additional tables.

For customers that are using Skills Manager to monitor employees at one or more organizations, I suggest starting with the agency table. As you begin entering employees into the database you will want to associate them with an agency and the agencies must already be defined to do this. After you have setup your agency table, I would proceed with the employee table as noted in the following paragraph.

Next I suggest focusing on the employee table. The employee master record is prerequisite to adding data into any of the other employee tables such as education, certification, training, etc. Next, I recommend the employment table as this table defines an employee's relationship to your organization, their rank/position, their status (active/inactive), and so on. Where you go from here is up to you and the needs of your organization.

Before you can begin entering data into the tables that you have selected, you must establish the code tables that will support them. Lookup tables are the foundation upon which you will build your entire database. It is essential that you have a solid understanding of the lookup tables, their function, and their relationship to the other tables in the database. It is also important to determine which lookup tables you will use and what values you will place in each table. Although there are many tables to choose from, you may find that you do not need all of them when you begin building your database.

The lookup tables are used to present users with a list of uniform choices when entering data into the main tables, as illustrated with the county table to the right. Lookup tables provide two very important benefits. They speed data input by allowing the user to quickly select a value from a list of choices rather than requiring the manual entry of lengthy descriptions. They also insure that the data entered into the database consist of uniform choices.

In contrast, some software products employ text based fields that are prone to misspellings, inconsistent abbreviations, and various case (upper/lower) representations. Consistency in a database is crucial for accurate queries and reports. The variable nature of text fields makes it virtually impossible to query (filter) a field in the database with any accuracy. Using county as an example, consider the impact if the software required users to type the county name into every employee record rather than choosing from a pre-defined list? Wouldn't this be laborious? How many variations of county name do you think you would find after several hundred records are added by a number of different users? The odds of the descriptions being entered without variation are not good.

The lookup tables are organized into groups with each group representing a relationship with one of the major data tables within the database. For example, there is a group of code tables that supports the employee table, and another group that supports the education table, and so on. Since I have already recommended that you start your database by entering employees and their employment data, the corresponding groups of lookup tables that support these two major tables would be an excellent place to start defining your codes.

Don't assume that you have to use all lookup tables in all groups. Skills Manager is designed to fill the needs of both small and large organizations. Some organizations may not have a need for all lookup tables, or they may not have the manpower to enter and maintain all of the elements provided in the database. It is true that the more details you put in to your database the more versatile and powerful it becomes, yet managing a detailed database requires additional work. Carefully evaluate the benefits of a table before you implement it. You don't want to be overwhelmed with entering and maintaining data that will never be used. It is best to start simple and then add elements as you discover their usefulness.

What values should I enter in the lookup tables?

After you have determined which lookup tables you will use, you must decide what values you will place in them. This task may seem difficult initially, but it can be simplified if you stop and think about the various elements you are already tracking on paper forms or in other databases that you maintain. Let's take employment for example. Do you think you will ever need to produce a list of employees by rank or position? If so, what are the various ranks/positions that you are already using? Make a list and enter them into your employment position/rank table. Will you need to classify employees by employment status such as full-time or part-time? If you will, enter these choices into your employment classification table. These are the kinds of things you will need to ponder when defining the entries for your lookup tables.

How descriptive should the values in the lookup tables be?

Is it better to fill your lookup tables with just a few values of a very general nature, or a greater number of values that are more explicit? This is an important decision and you will need to decide which fits your organization best. A few general values are easier to maintain but they also provide less information. Explicit values provide more power and information but they require additional input and ongoing maintenance.

Let's examine the employment action to help illustrate this concept. We have some customers that choose to use just two values in this code table, one indicating "Active" and another indicating "Inactive". They enter a maximum of two employment events per employee, an "Active" action when they are hired, and an "Inactive" action when they leave. This method requires minimal effort but it also provides minimal information. For example, you would never know the reason why an employee left your organization. Other customers choose to use more explicit values such as "Hired", "Promoted", "Demoted", "Suspended", "Reinstated", "Resigned", "Terminated", "Deceased", etc. Can you see the difference in the amount of information each method provides? Can you also see that the latter method would require additional work?

Let's look at some examples

The following tables define the values that support the agency table. The term "Agency" can be replaced by an alternate term to be determined by the customer. For example, a police department might choose the term "Division", "Unit", or "Bureau" as an alternative.

Employees