Chapter 4 Planning Directory Schema

Schema is a term used to described the type, or kind, of data that you can include in a directory. When you perform your site survey, you generate a lot of information on the data that you want to keep in your directory. Once you have an understanding of what you want to put in your directory, you must decide how to represent it there.

In this chapter you will learn how data is stored in the directory, and how you can customize your directory service to contain information that is unique to your enterprise. This chapter contains the following sections:

Directory Data Representation Overview—This section describes how data is stored in the directory through the use of attribute-data pairs.

Object Classes—This section describes the concept of and uses for object classes.

Attributes—This section describes the concept of and uses for object classes.

Schema Checking—This section describes the concept of schema checking.

Customizing the Schema—This section describes how and why you would extend your directory's schema.

cn: Babs Jensen

In fact, the entire entry is represented as a series of attribute-data pairs. Babs Jensen's entry might, for example, look something like the following:

dn: uid=bjensen, ou=people, o=airius.com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Babs Jensen
sn: Jensen
givenName: Babs
givenName: Barbara
mail: bjensen@airius.com

Notice in the previous example that multiple instances of a specific attribute are allowed. That is, givenName is used twice, each time with a unique value. This allows you to specify multiple values for a specific attribute.

The use of attribute-data pairs means that every entry in the directory is made up of multiple attributes. Further, you tell the directory what attribute values are allowed or required on the entry by defining one or more object classes for the entry (object classes are discussed in detail in the following section). By placing an object class on an entry, you are telling the Directory Server that the entry can have a certain set of attribute values, and must have another, usually smaller, set of attribute values.

Finally, before you can use an object class or an attribute in your directory, it must be identified to your directory. The total set of object classes and attributes known to your directory is referred to as your directory's schema. Your Directory Server comes with a standard schema that includes hundreds of object classes and attributes. In addition, you can extend this standard schema to represent information unique to your enterprise.

The following sections define these concepts in greater detail.

For example, if you define an entry to use the organizationalPerson object class, then the commonName (cn) and surname (sn) attributes are required for the entry (you must specify values for these attributes when you create the entry). In addition, there is a fairly long list of attributes that you can optionally use on the entry. This list includes such descriptive attributes as telephoneNumber, uid, streetAddress, and userPassword.

The use of object classes and the concept of defining the type of data that you can store on your directory entry are meaningful only if schema checking is turned on. For information on schema checking, see "Schema Checking".

Standard Object Classes

As is the case for all of the Netscape Directory Server's schema, object classes are defined and stored directly in your Directory Server. This means that you can both query and change your directory's schema by using standard LDAP operations.

Your directory recognizes a standard list of object classes by default. These are described in the Netscape Schema Reference Guide. You can find it at the following location:

http://home.netscape.com/eng/server/directory/schema/

Inheritance

Object classes are meant to use inheritance to define the total list of attributes that are either required or allowed on the entry. This inheritance is defined in the form of an object class structure. The structure begins with objectClass top and proceeds through a series of object class definitions, each of which adds to the list of required or allowed attributes. An object class that is meant to be at a lower end of the structure should not be placed on an entry until all of that object class's antecedent object classes have also been defined on the entry.

Note. While the LDAP specs call for an object class structure, the Netscape Directory Server does not currently enforce it. However, there is no guarantee that the Directory Server will not enforce these structures in the future. Therefore, you should always conform to the object class structure when designing and populating your directory.

For example, a person entry is usually defined with the following object class structure:

objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

objectClass top is what allows additional object classes to be placed on the entry. objectClass person defines two required attributes (commonName and surname), and then a few optional attributes. organizationalPerson and inetOrgPerson, in turn, add more attributes to the list of optional attributes. Further, before you can put inetOrgPerson on the entry, you must first put object classes top, person, and organizationalPerson on the entry.

Attributes generally have short, mnemonic names. For example, cn is the abbreviation for commonName.

Required Versus Optional Attributes

Object class definitions usually contain at least one required attribute, and they always contain one or more optional attributes. If an object class requires an attribute, then you cannot add an entry using that object class to the directory unless the required attribute is also defined for the entry. Doing so results in an object class violation, and the add operation for the entry fails.

Optional attributes are attributes that you are allowed, but not required, to add to the directory entry. If you attempt to add an attribute to an entry that is neither required nor allowed according to the entry's object class definition, then the Directory Server returns an object class violation.

The concept of a required or allowed attribute is meaningful only if schema checking is turned on. If schema checking is turned off, then you can add any attribute to your directory; the Directory Server will make no attempt to ensure that the data you are adding to your directory conforms to the schema.

It is strongly recommended that you run your Directory Server with schema checking turned on. For information on schema checking, see "Schema Checking".

A Note About Attribute Values

Perhaps one of the more confusing aspects about an LDAP schema is that you can generally place any data that you want on any attribute value. LDAP and the Directory Server place no restrictions on the data format, length, or type that you associate with individual attributes (other than some minimal syntax definitions that are used strictly for searching and pattern-matching purposes). For example, when you represent a telephone number in your directory tree, you can legally represent it in any of the following ways:

(408) 555-5555

408-555-5555

1-408-555-5555

1.408.555.5555

555-5555

This data model provides you with maximum flexibility when you design your data policy. However, remember that while the Directory Server and the LDAP protocol do not care about your data format, your LDAP clients probably do care about the representation of the data in your directory tree. This is especially true of graphical user interface clients that must display directory data in rigid-length fields.

The format of your directory data is also important to the user who is searching your directory tree for a particular value. For example, if the user is searching for an address such as

1206 Directory Drive

but you have stored the address in the form

1206 Directory Dr.

then the user may have difficulty locating the actual entry for which she is searching. For these two reasons, it is important that you be as consistent as possible when storing data in your directory tree. Pick a format and always follow it. When managing the data in your directory tree, remember what your LDAP clients and directory users expect to find there. Doing so will vastly improve the usability of your directory service.

In addition, the LDAP protocol may have defined certain attributes to contain data of a particular format. While the Netscape Directory Server does require you to represent this data in the proper format, your LDAP clients will likely be confused if they do not receive data in this defined format. One example of this is the postalAddress attribute, which expects an attribute value in the form of a multiline string that uses dollar signs ($) as line delimiters. For example:

postalAddress: 1206 Directory Drive$Pleasant View, MN$34209

You can turn schema checking off, but this mode of operation is not recommended. Schema checking helps ensure that you are using a consistent schema, which is important for allowing an LDAP client to successfully search your directory. At a minimum, schema checking ensures that you have not misspelled any object class or attribute names.

For information on turning schema checking on and off, see the Netscape Directory Server Administrator's Guide.

To help you extend your schema, the Netscape Directory Server includes a schema management tool. For more information, see the Netscape Directory Server Administrator's Guide.

When You Should Extend Your Schema

While the object classes and attributes supplied with the Directory Server should meet most of your needs, you will probably find that a given object class does not allow you to store specialized information about your organization. Or you may be using the Directory Server to support an LDAP-capable application, in which case you will need to extend your schema to support the object classes and attributes required by the application's information needs.

When to Add New Object Classes and Attributes

Add new attributes only when you add new object classes. If you find that you need to add an attribute to a standard LDAP object class, then you should:

1. Create a new object class. Define its parent object class to be the object class on which you wanted to add the attribute.
2. Add the new attribute on the new object class.

For example, you might want to store birth dates in your directory. No attribute for this information exists within the standard Netscape Directory Server schema, so you may choose to create a new attribute called dateOfBirth and allow this attribute to be used on entries representing people.

You should always look for an existing attribute that meets your needs before you extend your schema to include new attributes and object classes.

Object Class Strategies

There are two approaches you can take to new object class creation:

• You can create many new object classes, one for each object class structure that you want to add attributes to.
• You can create a single object class and use it to allow all of the attributes that you create for your directory. This object class can be used on any object class structure. You create this kind of an object class by defining its parent to be objectClass top.

Note. You should avoid requiring attributes on new object classes if possible. Requiring attributes tend to make your schema inflexible. It is best to allow rather than require attributes when you create new object classes.

You might also create an object class called airiusOrganization and have it allow buildingFloor and vicePresident. The parent of airiusOrganization might be the organization object class.

For example:

airiusPerson
   superior
       inetOrgPerson
   allowed
       dateOfBirth,
       preferredOS

airiusOrganization
   superior
       organization
   allowed
       buildingFloor,
       vicePresident

Alternatively you can create a single object class that allows all of these attributes and use it with any entry on which you want to use one or more of these attributes. It is best not to define any required attributes for this kind of an object class because you cannot be sure that you will want to always use a given attribute for every entry on which the object class will be included. For example:

airiusEntry
   allowed
       dateOfBirth,
       preferredOS,
       buildingFloor,
       vicePresident

Both strategies work equally well, and neither seems to offer a clear administrative advantage over the other. However, depending on your situation and your personal preferences, you will probably find one approach works a little better for you. Some things to consider are:

• Multiple object classes will result in more schema elements that you must create and maintain. However, the total number is likely to be reasonably small in even the most complex situations (one for each kind of object class structure that you might be using), and once the object classes are created there is very little administrative overhead to managing them. Still, you may find that it is easier for you to use a single object class if you find yourself considering adding more than two or three object classes to your schema.
• The multiple object class approach requires that you to be more careful and a lot more rigid in your approach to data design. This is because a structured approach forces you to consider the object class structure on which every piece of data will be placed. Depending on your personal preferences, you will find this to be either helpful or cumbersome. Pick the approach that works best for you.
• Using a single object class for everything is very useful if you find that you have data that you want to put on more than one type of object class structure. For example, suppose you want preferredOS on both a person and a group entry. Then you may want to create only a single object class to allow this attribute.
• There are no prohibitions, either technically or administratively, to mixing the strategies. If you find, for example, that it is best to create a few structural object classes, as well as another single object class to be used everywhere, then you should do that. There is nothing in the protocol or in the Netscape implementation that prevents you from doing this.

It is important that you use a consistent schema within your Directory Server because LDAP clients locate entries in your directory by searching for object classes or attributes and their associated values. If you use an inconsistent schema, then it becomes very difficult to locate information in your directory tree efficiently.

An example of an inconsistent schema is a situation where you use an attribute to store a specific kind of information, and then later use a different attribute to store the exact same kind of data. Another example of an inconsistent schema is if you use multiple formats to store the same kind of information. That is, do this:

telephoneNumber: +1 555 123-4567
telephoneNumber: +1 555 123-2468
telephoneNumber: +1 555 123-3579
telephoneNumber: +1 555 123-1470

Do not do this:

telephoneNumber: (555) 123-4567
phone: +1 555 123-2468
phoneNumber: 123-3579
telephone: 1 555 123 1470

Further, LDAP clients are designed to work with a specific, well-defined schema. For the most part, the schema that these LDAP clients are designed to work with is the standard LDAP schema which is based on the X.500 standard. For this reason, most LDAP-based directory services begin with the standard LDAP schema, but then the schema is extended as the site discovers site-specific needs that are not met by the standard schema.

The Netscape LDAP schema takes this approach as well. Most of the schema elements are based on the LDAP standard. However, Netscape has extended the schema to allow for directory activities that are commonly performed by Netscape's customers. In addition, Netscape ships LDAP clients that expect the schema to appear as defined by Netscape.

You can enforce your Directory Server's schema by turning schema checking on. When schema checking is turned on, you cannot add an object class or attribute to your Directory Server that does not conform to the schema. For more information on schema checking, see the Netscape Directory Server Administrator's Guide (http://home.netscape.com/eng/server/directory/4.1/admin/).

Schema Extension Frequently Asked Questions

These are common questions that people new to the Directory Server tend to ask when they first extend their schema:

I want to represent x in my directory. Is there a standard attribute that I can use to do this?

What you should do when you are looking for an attribute for use with your directory is to first become familiar with the more common attributes as defined in the Netscape Schema Reference Guide.

If none of those common attributes seem to be appropriate for your needs, then try browsing through the total list of attributes using the Directory Server schema management tool. To narrow your search, consider the type of entry that the data represents (a person, an organization, a device, and so forth), and then examine those object class structures that define that type of an entry.

If you still cannot find a likely candidate, then extend your directory schema to support your informational needs. After all, if a standard attribute does actually exist that could support you, then it is probably so obscure or poorly named that few people will actually expect to find it in your directory.

Should I delete unused attributes/object classes from my schema?

In short, no. Unused schema elements represent no operational or administrative overhead for your directory. You gain nothing by deleting them, and you potentially create future coexistence problems by supporting only a subset of the standard LDAP schema.

Of course, if you have defined a new schema element for your directory and you have found that you are not using it, then by all means delete it from your schema. (However, first make sure that your directory data is not using it!) No harm can come from removing unused schema elements from your directory that are specific to your enterprise.

I am building a global directory, and I have data that I use in one part of the world that is not used in another part of the world. Do I have to make sure my schema extensions are defined worldwide?

It is not strictly necessary to use the same schema enterprise-wide, but in practice it is a very good idea to do so. This is because to support a large-scale directory, you are using replication to move data between servers. This means that whenever some piece of data is replicated to a server, that server must recognize the attribute used to represent the data. If the consuming server does not recognize the attribute, then the replication operation fails and the servers in your directory become out of synch.

The most likely reason why you might be replicating data to a server that does not recognize the schema used by that data is if you defined new data in your supplier server and you forgot to update the schema in your consumer server.

Remember that your goal should be to make your directory easy to administer. It is best to ensure that your schema is defined consistently across your entire enterprise, just in case you one day want to replicate a piece of data that you had not originally intended to replicate.