Schema Design

---

Recall from Chapter 3 our discussion of the concept of a "directory schema" in the information model. The directory schema is a set of rules describing what can be stored in a directory and how information should be treated. This is achieved by the definition of attribute types and object classes. The attribute-type definitions explain how the data values are represented and how comparisons are made. The object classes are a set of attributes that frequently correspond to real-life objects. The object class further describes what attribute types are required and what attribute types are optional. It also gives a tool for retrieving a subset of an object class.

Schema design has two goals: The first is the mapping of the data defined in the previous step (data design) into attributes. The second is to put the attributes together into object classes.

One possibility is to use an existing schema. If there is no existing schema to fit your requirements, you can try to extend an existing schema. The last possibility is to create a new schema for the application at hand. If you write a new schema or extend an existing schema, you should document what you have done and eventually think about publishing the extensions you made.

You can get existing schemas from a number of sources. First of all, you will examine existing standards. You can get a standard schema from the site of IETF in the form of RFC 2256, "A Summary of the X.500(96) User Schema for Use with LDAPv3." Vendor-supplied schemas are another possible resource. Nearly every LDAP implementation is shipped with a number of standard schemas. For example, OpenLDAP gives you a number of schemas that you will find in a configuration directory called "schema." You should check to see if you can use one of these existing schemas. Your directory application also may be delivered with a schema of its own. Whatever the source, try to use a standard schema.

If your needs do not fit into an existing schema, you should consider modifying and extending one that comes close to meeting your needs. It is not recommended to modify existing object classes, because this could cause inconsistencies with your directory application and directory clients. You should instead subclass an existing class. For details about the process of subclassing, see Chapter 3, where the information model is explained.

The last possibility is to create your own schema. While the best approach is to use a standard schema or to extend an existing schema, there are situations where you really do need your own schema. However, be aware that you risk losing compatibility between your LDAP application and every other LDAP server. Your LDAP clients must also know about your proprietary schema.

Here are some considerations that you should take into account if you want to define new attribute types or new object classes:

• Use a consistent naming schema for all extensions. This helps future application programmers who may want to use your schema.

• Prefix your new object classes or attribute-type names with your project name or organization name. Because the LDAP namespace is flat, this avoids name collisions.

• Try to use meaningful names without making them too long. This avoids a lot of unnecessary typing and, even more importantly, typos.

• Get official object identifiers for your new objects. You can learn more about this at http://www.alvestrand.no.

---