数据库设计说明书

[dztasd]

现在是开发设计一起做，刚忙完软件需求规格说明书，现在要做数据库设计，请各位大神帮帮忙，给个参考呗

[以专业开发人员为伍]

我不知道你们所谓《软件需求规格说明书》具体是如何写的。简单来说，如果你把那些“名词儿、动词儿”做个分类，你会在所有的名词儿中再反复区分“哪些是属性、哪些是重复类型、哪些是业务领域类型、哪些是计算机领域类型”，并且找出类型之间关联上的不匹配的地方。 进一步地，你可以结合自己的团队的实力来划分层次，对类型进行抽象。抽象（一般化）是一个非常关键的技术，类型分层方法它影响到随后的各种设计（用例、活动、状态、功能、驱动方式、组件，等等）的分层，可以决定将来能不能省力的、可靠、稳定地开发。 迭代的系统通常只清楚地设计最近2个月的工作。要知道文档过了3个月，大部分就成了垃圾了。而且开发人员一旦开始开发，最恶心去修改过去的文档，造成了写文档时间的浪费。一开始可能抱着比较“理想的”心态去以为瀑布式的基于文档的开发方式最好，到最后就都知道这是最自欺欺人的说法。好的项目是分阶段的、演进的、有能力重构的，其文档和代码都不是虚的、而是惜字如金一样地敏捷甚至可执行的文档，只有精确的文档才能尽量不在后期变成垃圾。

[以专业开发人员为伍]

数据库表，只是对类型关联图的一个“简单映射”。它随时都可以做。通常在你准备动手写代码之前才具体写下来，甚至你直接使用一个数据库桌面文档工具或者Model Class映射工具，直接产生数据库表。 在这之前，你应该在设计阶段的迭代过程中，将各种类型对象进行“仿真”。比如说，如果用5个人来模拟5个对象之间的通讯时序，让这些人做一个游戏，能不能非常顺利地反复10遍走通流程？有没有感觉很差劲的体验？每一个人所拿到的所谓的“类型设计”是否完备地表示了业务领域的属性？人与人之间的“关系”是否需要调整？等等。 在你动手实现设计之前，你在设计上还有很多事情要做。不要拖到编程时才将这些问题推卸给程序员去做。

[exception92]

无非就是说明 用说明数据库，表信息，表详细，以及表之间的关系。

[以专业开发人员为伍]

描述了基本的需求之后，应该把“类型关联图”画出来，这是设计的第二步。 另外，设计是迭代的。如果你学了30年前的软件工程教科书，或者20年前的“中国规范”（已经落后了国外十几年），那么你可能看到一堆垃圾规范“参考”。你可以从网上下载“国标”参考，你可以看到，国标很垃圾，根本不符合现代的、敏捷的软件工程。

[正怒月神]

根据业务需求，制定数据库的表关联

[dztasd]

引用 4 楼 以专业开发人员为伍的回复:

数据库表，只是对类型关联图的一个“简单映射”。它随时都可以做。通常在你准备动手写代码之前才具体写下来，甚至你直接使用一个数据库桌面文档工具或者Model Class映射工具，直接产生数据库表。 在这之前，你应该在设计阶段的迭代过程中，将各种类型对象进行“仿真”。比如说，如果用5个人来模拟5个对象之间的通讯时序，让这些人做一个游戏，能不能非常顺利地反复10遍走通流程？有没有感觉很差劲的体验？每一个人所拿到的所谓的“类型设计”是否完备地表示了业务领域的属性？人与人之间的“关系”是否需要调整？等等。 在你动手实现设计之前，你在设计上还有很多事情要做。不要拖到编程时才将这些问题推卸给程序员去做。

谢谢楼上！，我慢慢看看把，头一次，有点晕

[架构师聊技术]

你要的应该是数据库结构说明文档吧，这个把数据库及表、列的信息描述清楚，写成文档就行。