这是一个基于B/S的学生在线评价教师的系统
evaluate_detalis表格是评价指标（例如：教学态度教学风格等等）
1、evaluate_process表格是学生首先从界面里面选择所在班级的任课教师和相应的课程的每一个指标对其进行评价（选择评价等级 优良中差）
2、evaluate_result表格存放的信息是 当学生评价完毕时管理员对该老师的课程进行结束评价的操作，系统自动计算出每一个评价指标的加权评价等级并将结果写到这个表格里面
大家看看是否合理，对于hibernate的映射有什么不妥吗
大家有什么需要小生再说明的请指出 万分感谢
首先我们必须明确，为什么使用Hibernate?我看很多人没有明白，包括一些专业的论坛，Hibernate是为了让我们更方便地以对象化思维来分析系统。
这句话怎么理解？这个意思里面有个纠正错误的隐含意思，纠正什么错误，为什么要强调以对象化思维来分析系统，难道我们以前不是用或者说不方便用对象化思维来分析系统吗？
是的，以前我们以数据库关系数据来分析系统，所以本例子就是一个明显实例。
那么以对象化和以数据库两种思维方式有什么区别呢？有本质的不同，这里暂时不谈很多理论知识，就以本例为说明。
首先，数据库逻辑图是平面的，而对象化（面向模型）分析设计是立体的，那么平面和立体有什么区别？因为是平面的，也就是所有的、无论大小的关系都会展现出来，最后关系复杂，阻碍我们抓住重点，妨碍进一步详细分析。
本图中evaluate_process几乎和所有表有关系，而evaluate_process又有自己的实体Data，所以,evaluate_process是个关系+实体的东西，使用数据库逻辑图表示出来，我们看出这个系统混乱，无从下手。
要使用好Hibernate，首先需要拿出类图 class diagram， 用类图四种关系（依赖 关联 继承 实现）来表示他们之间关系。在用UML类图表示后，evaluate_process会分分解，甚至不出现在类图中，而隐含在类关系中了，重而整个类图简洁，易于执行，再使用Hiberante进行对象到数据表的转换就水到渠成。
所以使用Hiberante的次序是：用对象化思路画好UML类图--->设计数据库--->配置Hibernate映射。
而本例只给出技术终端实现，没有很好地抓住源头和本质，必然会带来系统的失败，或者是体现在中间层DTO/VO的混乱上。
谢谢版主指明方向 当时还是有一些不是很明白 譬如说那个evaluate_process怎么设计好呢 小弟是刚刚学这个 还望指点一二 躬了
对不起 banq兄 那个data是笔误 应该是date 小弟初学 真的无从下手
实体关系我很清楚 就是这样的一个学生给老师的一门课来评价 涉及到三个实体的关系 而评价需要结合评价项目给每一个项目打分 这样就又涉及一个评价项目的实体 而打分的记录是需要持久化的 所以我现在要是从域模型下手的话 真的有些没有头绪 还是希望老哥能给一点启示 谢谢
我们使用域驱动方法来分析你这个案例。
首先，从用例use case分析开始，你的这个案例有三个角色：学生 老师和管理员。主要功能是：学生对老师的课程进行评价；管理员对老师的课程进行结案操作。主要是这两个功能。
现在，我们要通过域建模专家从你这个用例中提炼出域模型来，这个过程是一个经验过程，只有一些方法可借鉴，没有特定的技巧。主要一个模型是evaluate，这是用例中几个角色操作主要对象，而且evaluate
和课程class是有一定关系，因此，必须有一个模型class。
类图如下图：
这张类图就比你的数据库逻辑图清晰多了，而且抓住了我们操作的主要对象。
下面就是实现，如果使用Jdon框架实现就很简单，Jdon框架提供了域模型的增删改查CRUD操作，这个案例就是模型evalute的CRUD操作，学生给课程评价打分，实际是evalute的新增操作。你看主要一个功能我们就实现了。
当然，围绕evalute还有type类型 level等属性，这些属性是围绕evalute的关系图，通过对象的关联关系很容易实现（参考class与evalute的关联）。
我使用together绘制的上面类图，自动生成的代码如下：
不知上述过程你是否明白？有不详细的地方可进一步交流。
问一下，楼主这个图是用手画的吧？很厉害啊！:-)
不过好看但不好用哈！
可以考虑用rose或together试试，看banq的图就清晰多了。问题的关键还是对OO的理解哈！
谢谢banq哥了 仔细阅读中
不是手绘的图 是hibernate的一个工具 midgen 好像是这个名字 用来对后台数据库生成关系图 然后自动完成映射类的生成和映射文件的生成
oo,说到底就是分类，分类就依赖于分类的标准，标准取决于站的角度和人的主观经验。
> 问一下，楼主这个图是用手画的吧？很厉害啊！:-)
> 不过好看但不好用哈！
> 可以考虑用rose或together试试，看banq的图就清晰多了。问
> 獾墓丶故嵌OO的理解哈！
无语……说人家手画的。
hiahia~~~~~
其实，即便是按板桥的“域模型”法，如果具体实现起来，且分得细一些也会和你这个一样的，如果把你那个一个图中的一些类（关系）再合并一下，也会达到板桥的“域模型”法结果的。
你做的那个图是理论上的一种做法，其实现实中，“粒度”的粗细取决于某个“粒”的变化程度。粒度越细了操作越繁杂，因此，我们尽量采用就“粗”原则，某部分确实经常变化，我们才会把它单独提出来。
另外，我们学数据库时学的E-R模型分析法，我个人感觉它们之间是相通的。
不存在，谁好谁烂的问题，关键是怎么用，两者都有用烂的，更有用好的！
鲁中正气 观点很有普遍性，我这里讨论一下：
从得出的结果来看，好像两者差不多，但是我们分析设计一个新系统时，不是先有结果的，就象股票技术分析一样，很多方法只是用来证明过去结果，无法辅助决策未来。
域模型驱动（简称：DDD）方法提供了得出系统未来结果的科学方法，上述案例明显证明两者区别，我和楼主都对这个系统是未知的，楼主通过数据表逻辑图这个方法还是无法得出系统的入手点。
而我依赖DDD这样的方法，则很快抓住系统本质，找到系统的入手点。
有人说这是我们个人素质不一样，如果说有，那也只是在模型提炼上有些经验成分，所以我一直说：未来程序员只剩余两种人：建模专家；框架设计师，其余几乎是软件工人即可。
DDD为我们分析新系统提供可靠的方法途径，特别这个系统对我们来说是未知，一点无法把握，不是我们曾经碰到过的系统，那么能否很快就抓住或不是偏离很差的抓住系统本质，方法论就很重要，传统数据库的分析方式不能提供这种逼近未来未知结果的途径。
从分析设计这个角度来说，数据库也不再是我们系统的中心，彻底抛弃数据库为中心传统思维，这也是我为什么说：数据库时代的终结：
按我的理解,从业务流程角度分析
一般数据库中大体可以分为两类表,实体表和流程表,实体表是具体业务对象的持久存储,具体实体之间的关系可以是传统的一对一,一对多,多对多等关系.流程表是描述实体之间业务流程,一般是用主键ID关联实体,然后加上具体的流程描述信息.可以称之为流程实体,所以一般而言,像这样的流程信息一般都是单拿出张表来描述.
但是按照面向对象的思维,对象之间的关系不外乎继承,依赖,关联,实现四种关系,也就是说在建模时要将这些关系分散到各个对象实体中,我觉的这样做是否有弱化关系之嫌.真正在项目实施时,比如OA,对流程信息的统一性是要求很高的,一般都要求将流程信息具体化到UI界面上,为了一个流程,要联合查n张表,效率上得不偿失.所以banq您所说的将process表弱化到各个实体关系的做法我觉得还是值得商榷的.
itdong总结出两者一个区别，但是这个区别不是弱化或加强的区别，而是对象关系和数据关系的区别，这两者哪种更适合用来分析系统，很显然，以对象观念来分析设计系统已经证明是一个正确更适合的系统。
但并不是说，数据关系不重要，而是回到他适合的地方，以前他过于张扬，手伸到系统分析层面，虽然有时有效，但在更大范围内无法和对象化分析方法竞争。
数据关系也非常重要，javalobby最近的一篇文章：
Has the Objects/Relational Impedance Mismatch been Solved?
对象/关系的阻抗被解决了吗？http://www.javalobby.org/java/forums/t54475.html
该文提出一些关系数据模型的优点是客观的，但是他应该回到他的擅长的位置：持久化功能，而不是跳跃到系统分析层面。
我将JavaLobby这段文字意译在如下地址：
对象/关系阻抗已经被解决了吗？
现在国外已经在谈论关系数据库是否有存在必要，而我们大部分程序员还采取面向数据库的编程方式，而不是转变到面向对象的编程上来，注意编程和数据是两种概念，在编程上，面向对象更符合人类认识世界的方式，而数据关系则是一种数学符号。所以，我们不能至少将两种混淆替代，混淆它们的界限。