JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Fusion Middleware Administration Guide for Oracle Unified Directory 11g Release 1 (11.1.1)
search filter icon
search icon

Document Information


1.  Starting and Stopping the Server

2.  Configuring the Server Instance

3.  Configuring the Proxy Components

4.  Configuring Security Between Clients and Servers

5.  Configuring Security Between the Proxy and the Data Source

6.  Managing Oracle Unified Directory With Oracle Directory Services Manager

7.  Managing Directory Data

8.  Replicating Directory Data

9.  Controlling Access To Data

10.  Managing Users and Groups With dsconfig

11.  Managing Password Policies

12.  Managing Directory Schema

Directory Schema Overview

Designing and Extending the Schema

Default Schema Files

Configuring Schema Checking

Working With Object Identifiers (OIDs)

Obtaining a Base OID

Extending the Schema

Managing Attribute Types

To View Attribute Types

To Create an Attribute Type

To Delete an Attribute Type

Managing Object Classes

To View Object Classes

To Create an Object Class

To Delete an Object Class

Extending the Schema With a Custom Schema File

Replicating the Schema

Managing the Schema With Oracle Directory Services Manager

Add a New Attribute Type

Add an Attribute Based on an Existing Attribute

Modify an Attribute

Delete an Attribute

View All Directory Attributes

Search for Attributes

View the Indexing Details of an Attribute

Add a New Object Class

Add an Object Class Based on an Existing Object Class

View the Properties of an Object Class

Modify an Object Class

Delete an Object Class

Search for Object Classes

Display a List of LDAP Syntaxes

Search for a Syntax

Display a List of LDAP Matching Rules

Search for a Matching Rule

Display a List of Content Rules

Search for a Content Rule

Create a New Content Rule

Create a Content Rule Based on an Existing Content Rule

Modify a Content Rule

Delete a Content Rule

13.  Monitoring Oracle Unified Directory

14.  Tuning Performance

15.  Advanced Administration

Directory Schema Overview

The directory server reads the schema once at startup and then uses the schema information to match a search filter request or assertion to an entry's attributes to determine if any add or modify operations are permitted by the client.

In most cases, the default schema should be sufficient for most applications. However, you can take advantage of the flexibility of the directory server to extend the schema to suit your applications. The general procedure is not to relinquish the standard schema to a new custom schema, but to use the standard attributes or object classes wherever possible. If you require custom attributes or object classes that are not handled with the standard schema, you can create or extend the standard schema with auxiliary attributes and object classes required for your application.

The schema is stored in the directory under the suffix (cn=schema). The directory server also has a subschema subentry that defines the schema elements plus the set of operational attributes in the directory.

You can extend the schema in one of two ways:

Designing and Extending the Schema

Before you consider extending the default schema, or designing your own schema, ensure that you have a solid understanding of schema syntax and design.

The basic steps to design or extend a schema are as follows:

  1. Map the data to the default schema. Where possible, use the existing schema elements that are defined in the directory server. Standard schema elements help to ensure compatibility with directory-enabled applications. Because the schema is based on the LDAP standard, it has been reviewed and agreed upon by a large number of directory users.

  2. Identify unmatched data. The default schema was designed to accommodate a large variety of information objects. However, if the schema does not handle your specific data type, then make note of it and any other data types needed for your directory.

  3. Extend the default schema to define new elements. For optimal performance, reuse existing schema elements wherever possible. Also, minimize the number of mandatory attributes that you define for each object class. Keep the schema as simple as possible. Do not define more than one object class or attribute for the same purpose.

  4. Use schema checking. Schema checking ensures that attributes and object classes conform to the schema rules.

  5. Select and apply a consistent data format. The LDAP schema allows you to place any data on any attribute value. However, you should store data consistently by selecting a format appropriate for your LDAP client application and directory users.

Default Schema Files

The default schema provided with the directory server is a collection of LDIF files stored under install-dir/config/schema. The directory server loads the schema files in alphanumeric order (numerals first) at directory server startup.


Caution - Never modify the standard schema definitions and internal operational attributes in these files.

The following table describes the default schema files and their contents.

Table 12-1 Default Schema Files

Schema File
Contains the schema definitions for the LDAPv3 standard user and organization.
Contains the schema definitions for password policies based on the draftldappolicy draft.
Contains the schema definitions for the attribute and object class definitions in the directory configuration file.
Contains the schema definitions for storing changes to directory data based on the draftldap-changelog.
Contains the schema definitions for representing Java objects in an LDAP directory based on RFC 2713.
Contains the schema definitions for representing CORBA object references in an LDAP directory based on RFC 2714. The Common Object Request Broker Architecture (CORBA) integrates machines in a multivendor, multiplatform environments using CORBA objects. A directory server can be a repository for CORBA object references, which allow for a centrally administered service for CORBA-compliant applications.
Contains the schema definitions for representing calendar attributes for a vCard directory based on RFC 2739. Calendar applications require a calendar user agent to locate a URI, located in a directory, for an individual's calendar. Note that the definition in RFC 2739 contains a number of errors. This schema file has been altered from the standard definition in order to fix a number of those problems.
Contains the schema definitions for mapping Service Location Protocol (SLP) advertisements based on RFC 2926. This specification allows directory servers to serve SLP directory agent back ends that create mappings between SLP templates and the LDAP directory schema.
Contains the schema definitions for the authentication password syntax based on RFC 3112.
Contains the schema definitions for storing printer information in the directory based on RFC 3712.
Contains the schema definitions for storing UDDI v3 information in the directory based on RFC 4403. Universal Description, Discovery and Integration (UDDI) is a platform-independent, XML-based registry for companies on the Internet. UDDI enables companies to publish service listings and defines which software applications interact together over the Internet.
Contains the schema definitions for storing naming service information in the directory based on draftrfc2307bis.