dc：一条记录所属区域
ou：一条记录所属组织
cn/uid：一条记录的名字/ID
实际上更多时候我只把它看成数据库。我把它和我非常熟悉的MYSQL数据库做比较，通常会得到更好的理解：
MYSQL用“表”储存数据，LDAP用“树”
MYSQL指定一条记录要3个条件：DB、TABLE、ROW。
LDAP却更自由，为什么呢？因为LDAP数据是“树”状的，而且这棵树是可以无限延伸的，假设你要树上的一个苹果（一条记录），你怎么告诉园丁它的位置呢？当然首先要说明是哪一棵树（dc，相当于MYSQL的DB），然后是从树根到那个苹果所经过的所有“分叉”（ou，呵呵MYSQL里面好象没有这 DD），最后就是这个苹果的名字（uid，记得我们设计MYSQL或其它数据库表时，通常为了方便管理而加上一个‘id’字段吗？）。好了！这时我们可以清晰的指明这个苹果的位置了，就是那棵“歪脖树”的东边那个分叉上的靠西边那个分叉的再靠北边的分叉上的半红半绿的……，晕了！你直接爬上去吧！我还是说说LDAP里要怎么定义一个字段的位置吧，树（dc=waibo,dc=com)，分叉（ou=bei,ou=xi,ou=dong），苹果（cn=honglv），好了！位置出来了：
dn:cn=honglv,ou=bei,ou=xi,ou=dong,dc=waibo,dc=com
一个有名的画家说过：“世上没有相同的2个鸡蛋”。当然也没有相同的2个苹果……，同样，在LDAP里也不可能存在2个相同的dn。
LDAP数据填充原理
一棵树的生长，要循序渐进，如果还没有长出某个分叉，就不可能在那个分叉里长出苹果（问：FT！苹果是长在分叉上的吗？答：为了便于理解，你就当它是吧），同样，LDAP数据库也要一步步的充实，举一个学校数据库的例子，我们将要把一个庞大的学生档案放到LDAP里，大致需要这么做：
---------------------------------------------
1、建立“树根”，这是通过修改“slapd.conf”来实现的，由于现在的目的是理解，所以具体步骤就不说了，反正就是在这一步建立了一个 “dc=ourschool,dc=org”这样一个“树根”。注意：我把它理解成“目录”，或者“容器”，甚至它本身也是文件（苹果）的特殊形式，熟悉 LINUX文件系统的朋友会更容易理解。
2、建立18个系，分别是“dn:ou=computer,dc=ourschool,dc=org”、“dn:ou=film,dc=ourschool,dc=org”……
3、当然是在每个系里面建立专业，比如“dn:ou=linux,ou=computer,dc=ourschool,dc=org”……
4、（开始长苹果吧！）加学生喽——“dn:cn=stan,ou=linux,ou=computer,dc=ourschool,dc=org”……
5、已经完成了吗？对了！学生的详细信息还没有呐！不过先这样吧，反正记录是可以编辑的。
LDAP记录的详细信息
dn:cn=stan,ou=linux,ou=computer,dc=ourschool,dc=org
objectClass：organizationalPerson
cn:stan
cn:小刀
sn:小刀
description:agoodboy
（以上是一条记录的信息，如果把他保存成LDIF文件，可以导入到LDAP数据库中）
上面不是说没有学生详细信息吗？怕你着急，就马上写出来了，只是还没有导入到LDAP里，那是以后的事。这里我先就你可能会产生的疑问做回答。
---------------------------------------------
Q1：“cn”不是在“dn”里定义了吗，怎么又在后面重新定义了？答：你要把“cn=stan,ou=linux,ou=computer,dc=ourschool,dc=org”看成是一个整体，它只是属性dn的值。
Q2：怎么后面有2个“cn”，我以哪个为准？答：区别于普通数据库，LDAP每个属性一般可以具有多个值，这样不好吗？你在学校数据库里找我的时候，只要记得我的一个cn就可以了，用“cn=stan”或“cn=小刀”都可以找到我！
Q3：就这些属性了吗？我都不知道你是男是女。答：先声明，偶是男地。LDAP对记录的属性做了严格的限制（这一点我不太喜欢），也就是说，你可以用哪些属性，哪些属性不能为空，哪些属性最多只能有一个值等，他们都给你规定好了。幸好你有选择的权利，比如这次我们是储存学生信息，那么我们就定义一个 “objectClass：organizationalPerson”，这样“organizationalPerson”这个类所规定的所有属性我们都可以用了，而且确实很适合我们。虽然这个类中没有“sex”这个属性，不过你完全可以用一个“空闲”的属性来顶替。