I am very in tune with relational modeling but new to LDAP modeling and am looking for best practices for designing LDAP schemas. Would love to know what are the equivalents of third normal form and other practices in the world of LDAP?
Links to white papers that expand on this subject are greatly appreciated.
LDAP is inherently NOT compliant with even the first-normal form - some of its attribute can contain multiple values.
LDAP is a system designed for optimal read-/lookup performance, e.g. it's more appropriate in a scenario where you'll be reading / looking up the data way more than changing it (--> directories; your company phonebook won't be changing dozens times a day).
LDAP is not geared towards or designed for replacing or competing with standard relational database system which excel at data entry / transformation, where a large number of your operations will be inserting and/or updating data. That's what RDBMS are perfectly suited for.
So, in closing: LDAP vs. RDBMS is really a non-starter - and the two worlds are quite distinct and quite different in their style of working. I would not recommend trying to blindly apply something from one world to the other - it will be a bad match.
As for inspiration for LDAP schema design - I would definitely look at Microsoft's Active Directory, Novell's eDirectory (or whatever it's called these days), and possibly other LDAP directories, and learn from their designs.
Marc
Our experience shows the design of the schema and the DIT is very dependent on the purpose of the of the LDAP server.
For the schema, it is, generally, best to stick with the industry or LDAP server vendor's "standard".
For the structure of the DIT, unless it is for a file and print service (ie Active Directory) or OES (Netware) then generally a "flat" structure scales better.
If it is a large implementation (ie>100k) then groups should be avoided, if possible.
-jim
Based on my experience denormalize as much as possible, as the goal, as mentioned earlier, with LDAP is very fast lookup, but that means that the insertion of records may take longer, after a while. It is also important to make certain that you can keep backups of the ldap.
You may want to look at creating various classes though, such as a user, but also have a class for the authorization user, if needed.
Look at what is probably going to be needed. For example, at the university I was at we realized that some people that only tangentially have a relationship with the university will have an LDAP account.
As you scope out what types of users or resources will be in the ldap then it will help you determine how to set people up. For example, if you have one class that is only a username or identifier and a password, and perhaps a certificate, then it would be helpful for flexibility.
If you are going to allow people to log in from their unix account then there are certain classes that must be in the schema.
Pick a standard schema, such as core, cosine, inetOrgPerson, eduPerson, Java Objects, etc. appropriate for your intended purpose. Most LDAP servers come with a collection of defaults.
Prefer the existing elements, but if you need to extend the schema, prefix with comCompany (your company's domain name, or other unique identifier) to avoid conflicts from future standard elements.