较复杂的数据库设计是否有用ER图的必要。

[lishu1980]

不知道为什么？我们公司的人设计数据库都喜欢直接写数据字典，小弟认为在概要设计阶段用ER图设计数据库的概念模型有以下几点好处：
1、可以完整的设计整个系统的数据模型，而不用考虑细节。
2、能让项目组中的其它人员很直观的了解整个系统的数据关系。
3、ER模型的设计方法，逻辑性比较严密，不容易出差错。

[格兰特杨]

数据字典和ER模型一个也少不了。

没有数据字典，当不同的开发人员设计涉及到相同内容的表时，一定会有问题。
字符长度差了都Join不上！

[SE1]

非也，非也。
1、ER图设计概念模型，一样需要考虑细节：在SA中，数据流图的设计是从上向下，逐步细化的，而概念模型（ER图）的设计则是从底向上，逐步合并的。
2、ER图当然能让项目组中的其它人员很直观的了解整个系统的数据关系；但实际上它真正的目的是帮助设计人员和用户进行交流，正确理解数据结构及相互关系。
3、实际上，和关系数据模型相比，“ER模型的设计方法，逻辑性比较严密，不容易出差错。”是说不上的了：实际上，ER图更灵活，规定更少，更容易理解，容易使用用户的术语来表达数据：便于与用户交流。

个人认为，ER图是一个工具，帮助分析和设计的。应该在需求分析阶段与数据流图、数据字典一起完成，在概要设计阶段予以完善。
顺便说一下，“我们公司的人设计数据库都喜欢直接写数据字典”，不是数据字典，而是表结构吧。

[lishu1980]

不允许回复为空！！不允许有 gz、up！！！！来点创意吧！！！

[SE1]

数据字典是在分析阶段产生的，用于描述用户的业务中的各种数据结构，包括名称、组成、来源、流向等，是对数据流图中出现的数据进行定义，只要能准确描述业务中的数据流就行，什么范式等都不用管。而表结构如你所说，实际上完全依赖数据库（在这儿是关系数据库），应遵循数据库的一些标准和要求。以发票为例：
数据字典：
发票：
组成：发票头、发票细节、发票尾....
发票头：用户名称...
发票细节：名称、数量.....
发票尾：填写时间....
产生：
.......
表结构：
发票（发票号，用户名称，填写时间....），发票细节（行编号，名称、数量.....）

[lishu1980]

to SE1()，再问你一个问题，从概念模型（ER图）转换成物理模型（表结构）能够平滑的转换吗？不会出什么问题吗？

[SE1]

能够。
实际上，这种转换（ER->逻辑模型->物理模型）已经成为一种模式化的做法了，对于ER图中的各种标示的转换都有一定的说法：当然，运用之妙在于心

[lishu1980]

to SE1，你说的太好了，我们的确是直接写表结构。是用WORD画一表格，有字段名、类型、长度、约束、用途几个内容。我们开发的系统全部都是依赖数据库的，不知道你所说的数据字典和表结构有什么区别？