数据库设计不外乎三种关系
1。一对一
2。一对多
3。多对多
首先，为每个表创建对应的实体类
1。一对一
人员表A，人员信息表B，
那么对象设计在为类A、A业务类，类B，B业务类
A类里有个B类的对象
取B信息的方法写在B业务类中
3。一对多
人员表A，人员信息表B，人员有多个信息
那么对象设计在为类A、A业务类，类B，B业务类
A类里有个B类的对象集合
取B信息的方法写在B业务类中
3。多对多
人员表A，组织机构表B，人员表和组织机构对应关系表C
那么对象设计在为类A、A业务类，类B，B业务类，类C，C业务类
A类里有个B类的对象集合
取B信息的方法写在B业务类中
取A,B关系方法写在C业务类中
同理
B类里有个A类的对象集合
如果多对多的关系表存储的不光是关系，还有其他内容，那么A类或者B类中就是关系对象了，而关系对象存储的是A类和B类对象的集合。一对多同理
方法的定义原则是，取什么对象，就到对应的业务类中取。
按上诉设计，每个业务类只有两基本方法就够了，然后根据两个基本接口查询出的基本对象，可以组合出所有数据库中的数据信息
1。获取所有信息
2。根据主键获取单个信息(多对多关系，需要根据外键获取数据集合,几个外键，几个方法)
例如，要取出一个部门的和人员信息
（1）根据部门ID在B业务类中取得部门信息
（2）根据部门ID在C业务类中取得人员ID
（3）根据人员ID在A业务类中取得人员信息
这样就根据三个业务类的简单接口取出了详细信息（取全部其实和单个是一样的，只不过没有部门ID的条件了）
这是理想中的ORM定义，可以使程序员完全的不用关注结构型数据、只关注对象数据就可以了，这么做有个局限性是(一般是取出的数据量过大，链接数据库次数过多)，如果这么简单的设计，那么一个部门有200人，那么取这个部门和部门人员的信息需要调200次获取人员的方法根据主键，那么就相当于连接了200次数据库，显然这是不行的，上面所说的只是理想的设计，现实情况还要按理论变化(比如查部门不能关用ID就可以了，还有其他条件等等)。
ORM也为程序员由先设计数据库走向只关注设计对象提供了道路。
在这里提一下.net中的linq技术，他的对象查询功能为ORM提供了新的生命力。
