23. Case Study: Netscape Communications Corporation

Understanding and Deploying LDAP Directory Services > 7. Schema Design > Schema Design Overview

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053055078214172164222164206223058

Schema Design Overview

Schema design is the process of selecting and defining schemas to be used in a directory service. Before tackling schema design, you should first follow the data design process described in Chapter 6; to complete your schema design you will need detailed information on what data elements you plan to store in your directory service.

Schema design involves these steps:

  1. Locate schemas provided with the applications you plan to deploy.

  2. Locate standard and directory vendor-provided schemas.

  3. Choose predefined schema elements to meet as many of your data element needs as possible.

  4. Develop schema extensions or define new schema elements to meet your remaining needs.

  5. Plan for schema maintenance and evolution.

  6. Document your schema design.

Overall, it is best to use existing schema elements whenever possible, with a preference for widely published and well-documented schemas. This strategy is the easiest way to choose schema, and it should enhance compatibility with the directory-enabled applications you will deploy in the future. One of the challenges in schema design is to locate good predefined schemas to use, so we cover that topic in some depth.

If no existing schema can be located that meets your needs, you will need to create a custom schema by subclassing an existing object class definition or by defining completely new schema elements. When defining your own schema elements, it is important to use proper techniques to avoid potential problems down the road. You will also want to document your schema design (a simple but important step that many people overlook). Finally, it is a good idea to develop a strategy for maintaining your schemas and to plan for future changes.

A Few Words About Schema Configuration

In most directory server implementations, the administrator of the server determines what schema rules are in effect on a given server. Although we assume that schema customization is possible, the ease and degree to which it can be done varies widely among implementations .

An administration interface that can be used to customize schema is included with most, but not all, directory service software. In some systems schemas can be changed only by writing code that calls vendor-specific APIs. If you have already chosen your directory server software or are considering a specific implementation, check the documentation to ensure that you can and know how to perform any necessary schema customizations.

Another way implementations differ is in whether all data stored throughout the entire directory service is subject to the same set of schema rules or whether schema configuration can vary from server to server. In some implementations, different portions of the directory namespace can have their own schema rules. This allows the administrator to arrange for different subtrees within the directory to use different schemas. The term subschema refers to the schema that is in use for a specific subtree of the directory.

If you are deploying a centrally managed directory service, in most situations you should use the same schema everywhere. On the other hand, if you are actually deploying more than one service, or if you are an ISP that is providing directory service to more than one customer, it may be appropriate to use different schemas in different parts of the service.

Finally, you should check to see if the directory server software you plan to use supports automated replication of schema information or if you will need to take your own steps to ensure that the correct schema rules are installed on all servers you deploy. Not all implementations that support replication of user directory data can replicate schema information.

The Relationship of Schema Design to Data Design

When we tackled data design in Chapter 6, our main focus was on creating a detailed list of data elements to be included in your directory service. Most of the data design work was driven by the requirements of the applications that will use the directory service. During schema design, each data element is mapped to an LDAP attribute type, and related elements are gathered into LDAP object classes.

If some of the applications you plan to deploy come with a set of recommended schema definitions, the schema design process will probably be easier. There are also a lot of standard schemas you can choose from for common objects such as people, groups, and departments. However, you may need to design your own schemas or refine the vendor-provided and standard schemas based on your requirements. Also, if two different directory-enabled applications recommend the use of radically different schemas for the same type of object, such as a person, you will need to sort that out during the schema design process as well. Harmonizing schemas is important, so look for a high degree of configurability when selecting your directory server and application software.

Let's Call the Whole Thing Off

Some of you may wonder if you really need schema rules. Sometimes it seems like the schemas just get in the way of applications and users who want freedom when using the directory service. Based on our experience, and for all the reasons mentioned earlier in this chapter, it is important to use schemas within a directory service. However, depending on how you use your directory, it may be appropriate to de- emphasize schema rules or eliminate schema checking altogether.

Some implementations, such as Netscape Directory Server, allow you to disable schema checking entirely. Also, as discussed earlier, many LDAPv3-compliant servers support a special object class called extensibleObject that, when applied to an entry, allows any attribute type to be stored in the entry. Most directory service administrators will want to keep schema checking enabled and use the extensibleObject class only in special situations (for example, for applications that need to store their own configuration information and do not need the directory server itself to enforce schema rules).

Tip

If you do decide to downplay or disable schema rules, be careful. It is nearly impossible to impose order later on a collection of data that was created free from the constraints of schema checking! We suggest that you proceed with caution and at least begin your directory service deployment with schema checking enabled, even if you believe you will turn it off eventually.





Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

applications
          standard schema support
customizing
         schemas
                    application support
                    software issues
deactivating
          schemas 2nd 3rd
design
          schemas
                    application support
                    custom subclassing
                    customizing
                    disabling 2nd 3rd
                    existing designs
                    replication support
                    subschemas
directories
         schemas
                    design 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
disabling
          schemas 2nd 3rd
existing schema designs
extensibleObject object class
object classes
          extensibleObject
replication
          schema support
schemas
          design
                    application support
                    custom subclassing
                    customizing
                    disabling 2nd 3rd
                    existing designs
                    replication support
                    subschemas
software
          customizing schemas
standard schemas
          application support
subclassing
          custom schemas
subschemas

2002, O'Reilly & Associates, Inc.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net