DIT structure rules can provide a mechanism for placing constraints on the directory server hierarchy, but in order to maximize their utility, it may be necessary to use them in conjunction with support for multiple schemas. For example, consider a directory with a naming context of dc=example,dc=com, below which are two branches: ou=People,dc=example,dc=com and ou=Groups,dc=example,dc=com. If you want to allow only inetOrgPerson entries below the ou=People branch and only groupOfNames entries below the ou=Groups branch, then that can be fully accomplished only if there are different schemas that govern the ou=People and ou=Groups branches.
If there were a single schema governing the entire directory server, then you can imagine that it would have four DIT structure rules:
dITStructureRule: ( 11 NAME 'domainStructureRule' FORM domainNameForm )
dITStructureRule: ( 12 NAME 'organizationalUnitStructureRule' FORM organizationalUnitNameForm SUP 11 )
dITStructureRule: ( 13 NAME 'inetOrgPersonStructureRule' FORM inetOrgPersonNameForm SUP 12 )
dITStructureRule: ( 14 NAME 'groupOfNamesStructureRule' FORM groupOfNamesNameForm SUP 12 )
This set of DIT structure rules would allow the structure described above, but it would also allow the creation of group entries below the ou=People branch and the creation of user entries below the ou=Groups branch. The only way to prevent that using DIT structure rules would be to define separate schemas for the ou=People and ou=Groups branches and define only the inetOrgPersonStructureRule rule in the schema for the ou=People branch, and only define the groupOfNamesStructureRule rule in the schema for the ou=Groups branch.