今天在J道网看到一个讨论数据库分析的帖子很受启发。写一些自己的体会。
版主牛人的回复（针对主题一个数据库表关系图）：
首先我们必须明确，为什么使用Hibernate?我看很多人没有明白，包括一些专业的论坛，Hibernate是为了让我们更方便地以对象化思维来分析系统。
这句话怎么理解？这个意思里面有个纠正错误的隐含意思，纠正什么错误，为什么要强调以对象化思维来分析系统，难道我们以前不是用或者说不方便用对象化思维来分析系统吗？
是的，以前我们以数据库关系数据来分析系统，所以本例子就是一个明显实例。
那么以对象化和以数据库两种思维方式有什么区别呢？有本质的不同，这里暂时不谈很多理论知识，就以本例为说明。
首先，数据库逻辑图是平面的，而对象化（面向模型）分析设计是立体的，那么平面和立体有什么区别？因为是平面的，也就是所有的、无论大小的关系都会展现出来，最后关系复杂，阻碍我们抓住重点，妨碍进一步详细分析。
本图中evaluate_process几乎和所有表有关系，而evaluate_process又有自己的实体Data，所以,evaluate_process是个关系+实体的东西，使用数据库逻辑图表示出来，我们看出这个系统混乱，无从下手。
要使用好Hibernate，首先需要拿出类图 class diagram， 用类图四种关系（依赖 关联 继承 实现）来表示他们之间关系。在用UML类图表示后，evaluate_process会分分解，甚至不出现在类图中，而隐含在类关系中了，重而整个类图简洁，易于执行，再使用Hiberante进行对象到数据表的转换就水到渠成。
所以使用Hiberante的次序是：用对象化思路画好UML类图--->设计数据库--->配置Hibernate映射。
而本例只给出技术终端实现，没有很好地抓住源头和本质，必然会带来系统的失败，或者是体现在中间层DTO/VO的混乱上。
看了上面的一段文字,我也对自己以前使用hibernate时的一些问题有所体会。由于先于完成数据库建模。在使用时不得不照顾到数据库或碍于数据库设计，非常麻烦。写这些并不是否定数据库e-r设计，而是在以后考虑问题时多一条思路
另一个回复也非常好，针对弱化关键表功能。增加了多表查询的复杂程度。一并贴出，慢慢体会中.....
按我的理解,从业务流程角度分析
一般数据库中大体可以分为两类表,实体表和流程表,实体表是具体业务对象的持久存储,具体实体之间的关系可以是传统的一对一,一对多,多对多等关系.流程表是描述实体之间业务流程,一般是用主键ID关联实体,然后加上具体的流程描述信息.可以称之为流程实体,所以一般而言,像这样的流程信息一般都是单拿出张表来描述.
但是按照面向对象的思维,对象之间的关系不外乎继承,依赖,关联,实现四种关系,也就是说在建模时要将这些关系分散到各个对象实体中,我觉的这样做是否有弱化关系之嫌.真正在项目实施时,比如OA,对流程信息的统一性是要求很高的,一般都要求将流程信息具体化到UI界面上,为了一个流程,要联合查n张表,效率上得不偿失.所以banq您所说的将process表弱化到各个实体关系的做法我觉得还是值得商榷的.
【原贴地址：】http://www.jdon.com/jive/article.jsp?forum=62&thread=23720
版主牛人的回复（针对主题一个数据库表关系图）：
首先我们必须明确，为什么使用Hibernate?我看很多人没有明白，包括一些专业的论坛，Hibernate是为了让我们更方便地以对象化思维来分析系统。
这句话怎么理解？这个意思里面有个纠正错误的隐含意思，纠正什么错误，为什么要强调以对象化思维来分析系统，难道我们以前不是用或者说不方便用对象化思维来分析系统吗？
是的，以前我们以数据库关系数据来分析系统，所以本例子就是一个明显实例。
那么以对象化和以数据库两种思维方式有什么区别呢？有本质的不同，这里暂时不谈很多理论知识，就以本例为说明。
首先，数据库逻辑图是平面的，而对象化（面向模型）分析设计是立体的，那么平面和立体有什么区别？因为是平面的，也就是所有的、无论大小的关系都会展现出来，最后关系复杂，阻碍我们抓住重点，妨碍进一步详细分析。
本图中evaluate_process几乎和所有表有关系，而evaluate_process又有自己的实体Data，所以,evaluate_process是个关系+实体的东西，使用数据库逻辑图表示出来，我们看出这个系统混乱，无从下手。
要使用好Hibernate，首先需要拿出类图 class diagram， 用类图四种关系（依赖 关联 继承 实现）来表示他们之间关系。在用UML类图表示后，evaluate_process会分分解，甚至不出现在类图中，而隐含在类关系中了，重而整个类图简洁，易于执行，再使用Hiberante进行对象到数据表的转换就水到渠成。
所以使用Hiberante的次序是：用对象化思路画好UML类图--->设计数据库--->配置Hibernate映射。
而本例只给出技术终端实现，没有很好地抓住源头和本质，必然会带来系统的失败，或者是体现在中间层DTO/VO的混乱上。
看了上面的一段文字,我也对自己以前使用hibernate时的一些问题有所体会。由于先于完成数据库建模。在使用时不得不照顾到数据库或碍于数据库设计，非常麻烦。写这些并不是否定数据库e-r设计，而是在以后考虑问题时多一条思路
另一个回复也非常好，针对弱化关键表功能。增加了多表查询的复杂程度。一并贴出，慢慢体会中.....
按我的理解,从业务流程角度分析
一般数据库中大体可以分为两类表,实体表和流程表,实体表是具体业务对象的持久存储,具体实体之间的关系可以是传统的一对一,一对多,多对多等关系.流程表是描述实体之间业务流程,一般是用主键ID关联实体,然后加上具体的流程描述信息.可以称之为流程实体,所以一般而言,像这样的流程信息一般都是单拿出张表来描述.
但是按照面向对象的思维,对象之间的关系不外乎继承,依赖,关联,实现四种关系,也就是说在建模时要将这些关系分散到各个对象实体中,我觉的这样做是否有弱化关系之嫌.真正在项目实施时,比如OA,对流程信息的统一性是要求很高的,一般都要求将流程信息具体化到UI界面上,为了一个流程,要联合查n张表,效率上得不偿失.所以banq您所说的将process表弱化到各个实体关系的做法我觉得还是值得商榷的.
【原贴地址：】http://www.jdon.com/jive/article.jsp?forum=62&thread=23720
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
