Further Reading
| Understanding and Deploying LDAP Directory Services > 6. Data Design > Sources for Data |
Sources for DataNow you should have a list of all the data elements you want to include in your directory service. It is time now to take a slightly broader view and determine where you will obtain the values for the data elements and how you will manage the relationships with other data sources. By now you probably have a pretty good idea what data elements exist in electronic form in the other data sources within your organization. Some data elements are probably unique to a new application you plan to deploy; thus, the data values themselves may not exist anywhere yet. Figure 6.6 depicts some common data sources. Figure 6.6 Some common data sources. The following are common data sources:
You may need to obtain data from any or all of these sources. For each data element you plan to include in your directory, you should decide the following:
The information you have already gathered about each data element should help with these questions. You may not have all the answers when you initially deploy your directory service, but it is important to give some thought to these issues in advance. You do not want your directory service to hold out-of-date information, nor do you want your directory service to be accused of trying to supplant the human resources department's database (unless that is your goal). Some of the common data sources and surrounding issues are discussed in more detail in the following sections. Tip When surveying the data sources present in your organization, be sure to ask yourself whether each one will be important a year or two from now. If a system is being decommissioned in the near future, you may not want to invest much effort in studying it (unless of course your directory service is destined to replace it). Other Directory Services and Network Operating SystemsYour organization may already have a large, central directory service. If not, you probably have departmental LANs that include some kind of network operating system such as Novell NetWare (with data held in the NetWare Bindery or Novell Directory Service servers), Microsoft Windows NT Server (with data held on NT domain controllers), or Sun's Network Information Service (with data held in NIS servers). You probably also have data in domain name system (DNS) servers. Find out what data is contained in these systems and how it is being used. You should think about whether the LDAP directory service you deploy can take the place of some of these existing directories. You should also consider replicating data between the various systems; this should prevent the problem of having different values for a data element that is duplicated in several systems. DatabasesThere are probably several database systems (relational, hierarchical, or other) that hold interesting data in your organization. Examples include human resources or personnel databases, student databases, and databases used to manage network resources. If you have an in-house Private Branch eXchange (PBX) telephone system, its database probably has the most up-to-date telephone number information. In general, you will view these existing databases as gold mines when populating your directory service with an initial set of data. Do not be surprised if these systems are hard to work with though. Typically, they are expensive to run, difficult to make changes to, and hard to tie into other systems. Some databases may impose unreasonable restrictions on certain data fields, making the databases fairly useless as data sources. For example, a PBX database may be able to store only six characters for a login ID, whereas most other systems allow eight to be used. These kinds of restrictions also make it difficult to propagate information from your LDAP directory back into the database if you ever want to do so. You will need the cooperation of whoever runs these databases to get the data you are interested in. Thus, you may need to spend time lobbying to convince them that your new directory service is valuable to them and the organization as a whole. FilesIn smaller organizations or within departments, it is common for a secretary to maintain a complete phone list in a simple file or spreadsheet. If the information is maintained at the department level, it can be a good source for the most up-to-date contact information on people. Of course, the data may not be in a form that is easily pulled into a structured data system such as an LDAP-based directory service. However, you should investigate these file-based data sources anyway in case they prove useful. ApplicationsMany network or collaborative applications have a built-in database or directory that stores information about users of the application and other objects the application needs to know about. These application-specific directories tend to be proprietary, closed systems that may not even provide APIs for accessing the data. Examples include electronic mail systems that are not LDAP-aware, Web servers, and electronic calendar systems. One of the most important reasons to invest in a directory service based on LDAP is to replace many of these application-specific directories, or at least to coexist with them. You need to develop a coexistence strategy or actively manage a transition to the replacement service (this may be a lengthy strategy). The existing directories are the best source for the application-specific data elements you plan to store in your directory service, so try to work with them and not around them. AdministratorsA lot of interesting data is managed by the administrators who are charged with caring for the computer systems, networks, and telephone systems within an organization. If the data these administrators manage is not available in electronic form or another manageable format, you will still want to directly enlist the aid of these administrators in setting up and maintaining the data held in your directory service. End UsersLast, but certainly not least, end users are often the best source of data about themselves. This is especially true with personal contact information (such as home telephone numbers and addresses) and preferences. Because you probably do not have time to ask each person for information, you should provide an easy-to-use interface to your directory service so that individuals can update their own information. Some data elements come from other databases or are maintained by administrators or applications, so be prepared to explain to end users why they can't change those data elements themselves. It is a good idea to publish information about the origin and owner of each data element held in your directory service. This is usually covered in your data policy statement (as discussed earlier in this chapter).
|
Index terms contained in this sectionadministratorsdata sources 2nd applications data sources 2nd 3rd data sources 2nd 3rd 4th administrators applications 2nd databases 2nd end users 2nd files network operating systems other directory services spreadsheets databases data sources 2nd 3rd directories data sources 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th end users, see users files data sources networks operating systems data sources 2nd operating systems network data sources 2nd services directory data sources software applications data sources 2nd sources data 2nd 3rd 4th administrators applications 2nd databases 2nd end users 2nd files network operating systems other directory services spreadsheets spreadsheets data sources users data sources 2nd 3rd |
| 2002, O'Reilly & Associates, Inc. |
EAN: 2147483647
Pages: 245