When Defining New Object Classes

Add new object classes when the existing object classes do not support all of the information you need to store in a directory entry.

There are two approaches to creating new object classes:

• Create many new object classes, one for each object class structure to which you want to add an attribute.

• Create a single object class that supports all of the attributes that you create for your directory. You create this kind of an object class by defining it to be an AUXILIARY object class.

  Suppose your site wants to create the attributes ExampleDepartmentNumber and ExampleEmergencyPhoneNumber. You can create several object classes that allow some subset of these attributes. You can create an object class called ExamplePerson and have it allow the ExampleDepartmentNumber and ExampleEmergencyPhoneNumber attributes. The parent of ExamplePerson would be inetOrgPerson. You can then create an object class called ExampleOrganization and have it also allow the ExampleDepartmentNumber and ExampleEmergencyPhoneNumber attributes. The parent of ExampleOrganization would be the organization object class.

  Your new object classes would appear in LDAP v3 schema format as follows:

  objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.3 NAME 'ExamplePerson'
   DESC 'Example Person Object Class' SUP inetorgPerson STRUCTURAL MAY
   (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )
  objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.4 NAME
   'ExampleOrganization' DESC 'Example Organization Object Class' SUP
   organization STRUCTURAL MAY (ExampleDepartmentNumber
   $ ExampleEmergencyPhoneNumber) )

  Alternatively, you can create a single object class that allows all of these attributes. Then you can use the object class with any entry on which you want to use the attributes. The single object class would appear as follows:

  objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.5 NAME 'ExampleEntry'
   DESC  'Example Auxiliary Object Class' SUP top  AUXILIARY MAY
   (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )

  The new ExampleEntry object class is marked AUXILIARY, meaning that it can be used with any entry regardless of its structural object class.

Consider the following when deciding how to implement new object classes.

• Multiple STRUCTURAL object classes result in more schema elements to create and maintain.

  Generally, the number of elements remains small and needs little maintenance. However, if you plan to add more than two or three object classes to your schema, you might find it easier to use a single object class.

• Multiple STRUCTURAL object classes require more careful and more rigid data design.

  Rigid data design forces you to consider the object class structure on which every piece of data is placed. You might find this restriction to be either helpful or cumbersome.

• Single AUXILIARY object classes simplify data design when you have data that you want to put on more than one type of object class structure.

  For example, suppose that you want preferredOS on both a person and a group entry. You might want to create only a single object class to allow this attribute.

• Design object classes that relate to real objects and group elements that constitute sensible groupings.

• Avoid required attributes for new object classes.

  Requiring attributes can make your schema inflexible. When you create a new object class, allow rather than require attributes.

  After defining a new object class, you need to decide which attributes the object class allows and requires, and from which object class or classes it inherits.