大型项目中如何开展数据库设计工作
大型项目中如何开展数据库设计工作
本文基于我在上海证券交易所第三代监察系统项目的实践描述如何
在大型项目中开展数据库设计工作，本文避免过多的描述具体实现的
技术细节，侧重于从软件工程角度描述数据库设计的整体流程以及项
目各个阶段的工作侧重点。
1. 开展数据库设计工作所需条件
对于基于数据信息处理的大型行业解决方案项目来说，数据库设计是
整个系统设计工作中最为重要、最为基础的环节之一，具备什么样的
条件才能顺利开展数据库设计工作呢？
本章主要从资源配置角度描述如何确保数据库设计工作能够顺利进
行。
1.1. 独立的数据库设计小组
对于一个软件合同额数千万，前后参与项目的人员数量数百人的大型
软件工程项目来说，项目管理的重要程度要远比几十个人月、几个人
完成的小项目要重要的多，而成功进行项目管理的基础之一便是完备
的组织机构。
对于一个基于数据处理的大型核心业务应用系统来说，数据库设计是
整个应用系统实现的基础，可以说其设计质量的好坏直接影响到整个
项目的成败，应当有专门的组织机构负责其设计。
教训：在3GSS项目中数据库规划组成立时间过晚，只是在开发工作
过半的时候才组建起来，在这之前我个人也是在需求工作、架构工作
都已基本结束的时间点进入项目组，这对于顺利的进行数据库设计造
成了很大的困难。
1.1.1职责
数据库设计小组的职责主要体现在以下方面：
●参与项目总体架构设计，对于涉及到数据库应用的架构问题主要
负责。
●保证在项目进行过程中数据库设计的稳定，为各个应用子系统的
开发提供稳定的数据平台，从而保证项目计划的正常执行。
●在数据库性能优化工作起到主导作用，并对数据库性能优化的结
果负责。
●对于数据库版本的管理和发布以及变更负责。
●做好需求与开发之间的桥梁。
1.1.2在项目组中的地位和作用
数据库设计小组在整个项目组的组织机构配置中应当与架构组、需求组、测试组等平级，直接对项目组PM、PSM负责，因为数据库设计的工作需要各个小组的积极配合才能够顺利完成，所以项目小组之间的沟通协调工作显得尤其重要，如果不能做到从组织机构上将数据库设计小组提到项目组中一个相对较高的位置上，那么在一个大型项目组中，沟通协调工作将会很难进行。
教训：3GSS项目中，数据库规划组在项目进入到编码阶段之前并没有单独独立出来，只是隶属于核心预警系统组，因此在与其他组的沟通协调方面增加了一定的困难。
1.2. 如何组建数据库设计小组
描述数据库设计小组的组建过程和资源角色配置。
1.2.1.角色配置
一个数据库设计小组主要应当包括以下角色：
1.2.2.资源使用
可以这样说，数据库设计工作没有太多的开发工作量，但是对人员素质的要求很高，因此数据库设计小组的组建要按照“外科手术”的标准进行，贵在精而不在多：
1.3. 硬件资源
数据库设计工作顺利开展的一个重要条件是拥有既定硬件方案所规定型号的主机以及配套的存储设备，并且网络通讯能力要和真实上线条件一致，总之数据库设计工作需要一整套真实上线环境下的硬件设备，这不仅仅是数据库设计的需要，同时也是整个项目开发工作的一个重要基础条件，因为没有经过真实上线环境的检验，谁也不敢说我们用PC机和低档服务器开发出来的系统能否在上线的时候稳定运行。必需要保证在编码工作开始前准备好硬件方案所规定型号的主机以及配套的存储设备。
教训：3GSS项目在7月进入开发编码阶段，而硬件环境直到9月份才到位，在这之前我们只能使用PC机来作数据库服务器，根本没有
办法模拟大数据量存储，致使数据库物理设计的优化调整只能延后，
如果我们能够在这宝贵的2个月时间内仔细验证、优化我们的数据库
物理设计方案，我们完全可以规避很多实现风险，也不会造成后来开
发阶段数据库存储性能的瓶颈问题。
1.4. 设计工具
工欲善其事，必先利其器，现在有很多数据库设计工具可供选择，
3GSS项目选择Sybase公司的PowerDesigner9.5作为设计工具，我认
为这个工具主要有以下好处：
1、可以方便地进行数据库的物理设计、逻辑设计
2、有很强的文档生成能力，可以定制生成各种数据库设计文档
3、拥有数据库反向工程能力
2. 数据库设计工作的流程与方法
首先提出一个问题：在一个项目中数据库设计工作什么时候开始启
动？什么时候结束？
我认为，从需求工作启动的那一刻起，数据库设计工作就正式开始了，
直到项目交付完毕、正式上线运行方才告一段落！其中工作重心主要
放在需求阶段、架构设计阶段、详细设计阶段。
2.1. 需求阶段
数据库的设计，特别是大型核心业务应用系统的数据库设计，远非建
几张数据库表那么简单，在数据库设计工作的初时阶段，就其本质来
讲，是对客户核心业务的一次数据建模，出色完成该阶段数据库设计
任务的关键条件是对用户核心业务的业务模式、处理流程、数据构成
充分理解，可以说在这一阶段的数据库设计工作中，并没有涉及多少
数据库技术方面的工作，更多的工作集中在对于客户核心业务的理解
和学习上，为在后续阶段对数据库进行逻辑设计打好基础。而在这一
方面，无疑需求组的同事是处于主导地位的，我们必须和需求组的同
事合作，获取它们的帮助，同时，我们的参与也会促进需求组的同事
进一步和客户沟通、明确很多业务方面的细节问题，从某种意义上讲
也是间接推动了客户需求的细化工作。
数据库设计小组需要在需求阶段投入最大的精力和资源。
这一阶段数据库设计小组（以数据建模员为主）主要从事以下方面的工作：
●对于客户需求的分析、理解、细化
有人可能会说：这是需求组来作的事，干吗让我来做？
这种观点是不正确的，因为需求人员的工作是站在偏业务的方面与客户进行沟通，而数据库设计人员是站在设计实现的角度去作，可以说数据库设计人员对于客户的数据需求比需求组的同事更加敏锐。
这段时间的工作是数据库设计工作中最困难也是最重要的工作，因为对于客户业务需求的理解是整个数据库设计工作的基础，磨刀不误砍柴工，在需求阶段将客户业务需求理解透彻将会在后续的设计工作中节省大量的时间。
●数据概念模型建模
在对客户的需求用例有了比较透彻的理解之后，就应当着手针对需求用例进行数据抽象，得出初步的数据流图、E_R模型、数据字典。
主要应当考虑以下方面的内容：
1、创建数据字典和E_R模型图表。E_R模型图表和数据字典可以
让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对后续开发SQL来说这是完全必要的。
2、确定数据依赖，识别数据实体之间的关系，对数据实体间的关系
作规范化处理。数据库实体之间关系规范化的范式有很多专门的技术文档可供参考，这里不加详细描述，但是需要指出一点，在实际项目实践过程中，并不一定完全按照范式的要求实现就是最好的设计，需要根据实际情况适当的作出一定的逆范式设计。例如，一个股票订单信息的数据实体，包括投资者帐号、投资者名称等投资人信息；订单号、交易价格、交易数量等交易信息；按照标准的范式设计应当将该数据模型划分为两个实体，既主从关系的投资人实体和交易信息实体，使用订单号关联，但是实际情况是，每日的订单信息数量达到了5000万笔，而投资人信息也将达到8000万条，如果仍然按照范式设计，那么在查询订单信息时将会人为的在两张超大表之间进行关联，那将严重影响查询速度，所以只能反规范化，将投资人信息和交易信息融合在一个数据实体中。
3、对数据概念模型进行优化调整。针对数据库概念模型中的不足和
缺陷，要及时作出修正和调整，在这期间要与需求组的同事配合，充分和客户沟通，数据库设计的调整在概念模型上进行调整代价是最小的。
4、制定数据对象命名规范。对于一个大型行业业务解决方案来说，
需要建模的数据项可能会有成千上万个，如果没有一个统一的命名规范将会给后续的设计开发工作造成不必要的麻烦。这一工作一般由数据库设计小组组长完成，完成后要经过项目组一级的评审。
经验：在概念模型的建立过程中，对于那些有着明确数据接口格式定义的外部输入数据，建模工作相对容易一些，对于用户需求用例中数据的流转过程建模，从而得出数据流图相对来说要困难一些，数据建模员切忌只看输入输出，不看数据流转、处理过程。数据的流转处理过程是建立数据库概念模型的重要依据，我们只有搞清楚了数据是如何流转的，如何被使用的才能够设计出尽可能贴近客户业务需求的数据模型。
●做好需求与开发之间的桥梁。
为什么呢？因为数据库作为整个应用系统的运行基础，可以说整个系统的设计工作都将或多或少的与数据库系统的设计工作产生交叉，而数据库设计人员出于完成数据库逻辑设计的目的，必须对整个项目的需求用例以及业务背景有着全面的了解和掌握，可以这么说，在整个项目组中，只有数据库设计人员才能站在开发设计角度掌握整个系统完整的需求细节，可以说数据库设计人员在以后的设计、开发阶段是一个宝贵的资源，数据库设计人员应当对应用系统的设计人员提供咨询上的帮助，并且对应用系统设计进行评审，确定其设计是否与数据库设计相契合。
2.2. 系统架构阶段
在系统架构阶段，数据库设计小组的主要工作是：
●确定数据库服务器所使用的硬件配置方案
这项工作需要数据库设计小组和系统集成组的同事合作完成，数据库设计小组主要从客户对于数据库的性能指标入手，得出对于数据库服务器的硬件要求，系统集成组的同事负责具体的硬件选型。
在确定硬件配置方案的时候，数据库设计小组主要从以下几个方面入手：
1、满足数据的存储容量需求。以需求阶段所得出的数据库概念模型
和数据字典为基础，按照客户给出的未来一段时间内业务数据的增长速度预估出数据存储空间，在这里应当注意：需要为索引预留出存储空间，一般经验性的做法，索引的存储空间与数据存储空间按照1：1来预估。
2、满足数据库交易处理能力的需求。我们要考虑高峰时的处理器的
能力，并适当保留一些缓冲，确保在业务增长时，系统有扩展的余地。如果要保持快速的响应能力，应当为CPU保留20%至40%的富余量。要为运行在此服务器的所有应用软件考虑内存，所需要的内存主要依赖于用户数、应用程序类型、进程的方式、和应用程序处理的数据量决定。在评估数据库服务器性能时，最困难的事情是如何把握准确度问题，到底考虑哪些因素等。理想情况下，应考虑下列要素:
交易的复杂性
交易频率
数据读/写比例
并发连接数目
并发交易数目
数据库最大表的大小
性能度量的目标
教训：在3GSS项目架构设计阶段硬件方案选型的时候，没有考虑到会在每天的交易时间内在数据库服务器上并发运行数据预处理存储过程，只为数据库服务器配置了4CPU，结果导致在项目后期出现了严重的数据库服务器处理性能不足问题。
●规划数据库的物理设计
数据库最终是要存储在物理设备上的。为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构（存储结构与存取方法）的过程，就是数据库的物理设计。
物理结构依赖于给定的DBMS和和硬件系统，因此设计人员必须充分了解所用DBMS的内部特征，特别是存储结构和存取方法；充分了解应用环境，特别是应用的处理频率和响应时间要求；并充分了解外存设备的特性。
数据库的物理设计通常分为两步：
第一步：确定数据库的物理结构
在这里数据库设计小组主要从事以下方面的工作：
1、确定数据的存储结构。确定数据库存储结构时要综合考虑存取时
间、存储空间利用率和维护代价三方面的因素。这三个方面常常是相互矛盾的，例如消除一切冗余数据虽然能够节约存储空间，但往往会导致检索代价的增加，因此必须进行权衡，选择一个折中方案。
2、设计数据的存取路径。在关系数据库中，选择存取路径主要是指
确定如何建立索引。例如，应把哪些域作为次码建立次索引，建立单码索引还是组合索引，建立多少个为合适，是否建立聚集索引等。
3、确定数据的存放位置。为了提高系统性能，数据应该根据应用情
况将易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。例如，目前许多计算机都有多个磁盘，因此进行物理设计时可以考虑将表和索引分别放在不同的磁盘上，在查询时，由于两个磁盘驱动器分别在工作，因而可以保证物理读写速度比较快。也可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效。此外还可以将日志文件与数据库对象（表、索引等）放在不同的磁盘以改进系统的性能。
4、确定系统配置。DBMS产品一般都提供了一些存储分配参数，供
设计人员和DBA对数据库进行物理优化。初始情况下，系统都为这些变量赋予了合理的缺省值。但是这些值不一定适合每一种应用环境，在进行物理设计时，需要重新对这些变量赋值以改善系统的性能。通常情况下，这些配置变量包括：同时使用数据库的用户数，同时打开的数据库对象数，使用的缓冲区长度、个数，时间片大小、数据库的大小，装填因子，锁的数目等等，这些参数值影响存取时间和存储空间的分配，在物理设计时就要根据应用环境确定这些参数值，以使系统性能最优。在物理设计时对系统配置变量的调整只是初步的，在系统运行时还要根据系统实际运行情况做进一步的调整，以期切实改进系统性能。
第二步：对数据库物理结构优化
数据库物理设计过程中需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案，数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。
评价物理数据库的方法完全依赖于所选用的DBMS，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。如果该结构不符合用户需求，则需要修改设计。
●完成数据库概念模型到逻辑模型的转换
逻辑结构设计的任务：就是把概念结构设计阶段设计好的基本E-R
图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。因此设计逻辑结构首先应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。设计逻辑结构时一般要分两步进行：
1、将概念结构转换为特定DBMS支持下的数据模型。
2、数据模型进行优化。
这些工作基本上都可以使用PowerDesigner设计工具开完成。
2.3. 详细设计阶段
有一点是要明确的，就是数据库设计要走在各个子系统应用程序设计的前面，原因是明显的，因为各个子系统需要在数据库支撑环境已经明确的情况下才可以开展设计、开发工作。
数据库设计小组这一阶段的主要工作有两点：
1、支持各个子系统应用程序的设计。特别是查询、报表模块的设计，
这是与数据库关联最为密切的模块，可以说没有数据库的良好支持，根本不可能设计出性能优良的查询、报表程序。
2、对数据库模型进行优化调整。在各个子系统设计的深入过程中我
们会不断发现原有数据库模型设计上的一些不足，主要集中在以下方面：
库表结构设计不合理。
不能够提供所需要的数据。
数据库表的主键、索引设置不合理。
数据库的物理存储空间分配不足。
2.4. 编码阶段
如果之前阶段的工作顺利完成，那么进入到编码阶段，可以说数据库
设计工作已经完成大半了，编码阶段数据库设计小组的工作重心应当
转移到性能验证、性能测试工作上。
此外，在编码阶段数据库设计小组应当对于开发人员的PL/SQL编程
提供技术支持和代码检查，以保证PL/SQL编码的质量。
2.5. 测试阶段
随着开发工作的逐步推进，测试组的同事会对各个阶段获取的系统版
本进行系统测试，数据库设计小组要做好数据库的版本控制工作，全
力配合测试组的同事进行系统测试。
另外，数据库设计小组还应当积极协助测试组的同事准备数据库性能
验证测试的测试案例、测试数据。
2.6. 系统交付阶段
如果能够顺利进行到系统最终交付阶段，也可以说我们的数据库设计
工作已经功德圆满了。
这一阶段要做好数据库设计的最终封版工作，对数据库设计的各种工
作成果物进行整理，对数据库设计个个阶段产生的设计文档进行归纳
总结。
3. 数据库设计工作中的版本控制
由于大型项目的开发周期很长，出于配置管理的需要，在大型项目的
开发阶段，需要设置若干个里程碑，在每个里程碑都需要对软件系统
进行封版，形成配置基线，这些配置基线对于开发工作的延承和最终
系统的按时交付有着重要意义，与此相对应，作为应用系统基础的数
据库也需要在相应的里程碑得到对应的设计版本，数据库设计的版本
控制与配置管理是整个项目组版本控制与配置管理的一部分，但是与
应用系统开发过程的版本控制与配置管理又有所区别，我们在3GSS
项目的实践中摸索出了一套数据库设计版本控制的工作流程与方法。
3.1. 版本控制
数据库设计的工作成果主要包括数据库建库脚本、初始化数据、
PL/SQL脚本等内容，其特点在于数据库设计的版本与应用系统的开
发版本之间存在很强的相互依赖性，一个开发版本通常情况下只能在
与该开发版本对应的数据库设计基础之上才能够正常运行，这是由于在项目开发工作的不断推进过程中，数据库设计工作也在不断的细化、完善。这种依赖性在测试组的同事针对某一开发版本进行测试的时候表现的最为明显。
教训：在3GSS开发工作的初始阶段，数据库设计的版本控制没有形成规范化，与开发版本的控制脱节，因此曾经一度造成数据库版本的混乱，测试组在进行系统测试的时候取得开发版本后不知道应该使用什么版本的数据库。
经验：在后续的开发工作中，数据库设计的版本控制严格跟随应用系统开发版本的版本控制进程进行，在应用系统发布每一个开发版本的时候，我们都会发布一个与之对应的数据库设计版本，并且在交付测试组进行系统测试前明确指出开发版本与数据库设计版本的对应关系，从而避免了开发版本与数据库设计版本的脱节问题，开发、测试工作也得以稳定、顺利的进行下去。
3.2. 配置管理
数据库设计的配置管理工作应当紧跟应用系统开发的阶段性封版工作，要与应用系统形成统一的配置基线。
数据库设计工作成果物的目录组织形式可以参照下图所示：
但是并不一定拘泥于此，只要能够清晰、简便的体现出数据库设计的各个配置基线，能够方便地获取各个时期各个时期的不同版本即可。
配置管理工具可以选用微软的SourceSafe。
经验：在开发阶段，数据库的结构细微变动较为频繁，数据库的变动通过补丁方式维护数据库，在一个开发阶段结束，数据库版本稳定后，根据数据库的变动情况形成数据库设计的配置基线。
3.3. 变更流程
在项目的编码开发阶段，随着编码工作的逐渐深入，原有系统设计中的不足和一些没有考虑到的设计细节问题开始逐渐暴露出来，随之就要进行设计的调整，数据库设计也是如此。
但是数据库设计是整个应用系统运行的基础，对于数据库系统的设计调整将有可能影响到整个系统的正常运行，因此对于数据库设计的调
整应当十分谨慎，在数据库设计的变更工作中应当注意以下方面：
●数据库设计变更的要求只能由各个子系统的开发组长提出，并
且经过项目组开发负责人同意。
这样做是为了保证数据库设计的稳定性，因为在一个大型项目中，编码人员非常多，而且编码人员看待设计问题的方法和角度往往和系统设计人员、架构师的角度不同，有可能提出一些不切合实际的变更要求，因此就需要有人对变更要求进行评审和把关。
●数据库设计小组在接到变更要求后绝对不可以随意变更数据库
设计，必须经过数据库设计小组组长评审通过后方可进行相应修改。
这样做同样是为了保证数据库设计的稳定性，避免设计工作的反复。如果数据库设计小组组长评审后认为不适宜修改应当立即和项目组开发负责人进行沟通协商，如果仍然没能达成一致就需要召开项目组级别的架构评审会议进行评审。
●数据库设计的变更需要做好修改记录。
这样做是为了清楚地记录下整个数据库设计过程中所发生的设计变动过程，有了这份记录，我们在将来就可以很容易对数据库设计的依据进行回溯，有助于我们更好的理解数据库设计的历史延承。
●数据库设计变更完毕后一定要将变更结果通知项目组中所有涉
及到该项变更的开发小组组长。
在一个大型项目组中，由于开发小组很多，再加上沟通不畅，很容易造成这样一种结果：某张表已经作出了变更，但是某些开发小组并不知道，仍然依据老的表结构进行开发，这样就人为的制造了系统BUG。因此务必要将数据库设计的变更结果传达到每一个相关的开发人员，而开发人员数量较多，因此我们只将变更结果传达到开发小组长，再由开发小组长传达到每一个开发人员。
教训：3GSS项目中在开发阶段的初期，数据库设计调整之后，数据库设计小组作了版本控制，也做了修改记录，但是没有将变更结果通知到涉及该次变更的开发人员，结果造成了数据库版本已经升级而开发人员还在使用老版本的数据库设计进行开发的情况
经验：我们采取了变更后对开发小组组长进行邮件通知的做法，一定程度上避免了该问题，但是有一些开发小组组长对于邮件通知不敏感，没有将变更通知继续向组员传达，所以数据库设计小组就在每次发送变更通知邮件后再口头通知一遍各个开发小组组长。
●每一次数据库设计变更后应当做好相应的版本控制和配置管理
工作。
●发布每一次数据库设计的变更之前都应当对所发布的内容在专
用的数据库服务器上进行发布测试，以保证所发布设计的可用
性。
●开发用数据库服务器由数据库设计小组负责管理和维护，此外
任何人不得对数据库服务器作出任何变更。
开发用数据库服务器是系统开发过程中全项目组公用的开发环境，任
何人对于数据库服务器的私自改变都将会影响到其他开发人员的正
常开发，应当予以严厉禁止。
经验：破坏性最大的是对数据库表结构的私自变更，在3GSS项目中，
我们采取了设置不同数据库用户，分别授权的方法来规避该问题。具
体做法是，设置管理员用户，赋予数据库DBA权限，可以对数据库
服务器作出任何变更，这个用户只有数据库设计小组相关成员拥有密
码；设置开发用户，只赋予数据增删改查权限以及其他必要的权限，
该用户供所有开发人员开发使用。
4. 数据库设计中的性能优化问题
说到数据库性能优化，在我接触到的同事中持以下两种观点的人居
多：
●性能优化太复杂了，根本无从下手！
●不就是优化嘛，等开发完了找个高手过来优化一下就可以了！
如果说持以上观点的只是普通开发人员还有可以挽回的余地，如果在
一个大型的项目组中，负责数据库设计工作的负责人也持有以上观
点，那么注定将会出现一个失败的数据库设计！
数据库性能优化并不是独立于数据库设计和实现之外，而是自始至终
贯彻于数据库设计的工作之中，可以说从数据库设计工作启动的哪一
刻起，我们就应当将性能优化作为我们的一个工作重点。也可以说数
据库设计的过程就是一个数据库性能优化的过程。
性能优化也不是洪水猛兽，也是有一定的工作方法可循的，只要我们
按照正确的方法来做，相信一定会顺利的完成，下面我们来着重谈一
下性能优化这个话题。
4.1. 什么是数据库性能？
这个问题如果问100个人，可能会得到101种答案，例如：SQL语句的执行时间长短、每秒钟能够插入数据库的记录条数、数据导入导出数据库的时间长短等等，这些答案都对，但是并不完全。
我认为，以技术的角度来看，数据库的性能就是以最少的时间获取所需要的数据的能力；以软件工程的角度来看，性能就是满足客户需求的能力。
许多人都喜欢说这么一句话：“没有最好，只有更好。”我很欣赏这句话，作工作需要这种积极向上的态度，但是这句话如果放在数据库性能优化这件事情上则不尽然，应当加上一个限制条件：“如果不计成本，那么数据库性能没有最好，只有更好。”
作软件，特别是象我们这种行业解决方案提供商，如何平衡质量（Quality）、成本（Cost）及交付（Delivery）的关系，从而利益最大化是每一个软件从业人员都必须考虑的事情，从客户角度来讲，客户花钱让我们来做解决方案，是为了能够在实际应用中体现出该解决方案的价值，能够满足其特定的应用需求，因此我们只要满足了客户需求即可，性能优化不需要画蛇添足！
4.2. 什么时间优化？
有很多人认为数据库性能优化在编码结束、系统稳定后再进行，理由是：应当首先保证项目的开发进度和交付能力，优化工作必须等到开发结束并且系统已经稳定之后进行，并且要保证优化后的系统依然是稳定的、可交付的系统。
可以肯定的说，这种看法是错误的，试问一个不能满足客户性能指标的稳定的系统何谈交付能力？数据库是应用系统运行的基础，数据库的性能优化、调整可以说是牵一发而动全身，是一件应当慎重对待的事情，如果等到系统开发完毕再想到进行性能优化，那么我们已经错过了性能优化的最佳时期，如果此时再去勉为其难的去作优化工作，那么数据库设计小组的成员就只能双掌合十，心中默念从释迦牟尼一直到圣母玛利亚等诸多中外神佛保佑，祈祷之后我们会发现他们都不站在我们这边。
数据库的性能优化工作在项目的需求分析阶段就已经开始了，并且一直伴随着数据库设计工作的开展而进行，可以说数据库的性能优化工作是贯穿数据库设计全过程的，数据库设计小组成员心中需要牢记一条准则：数据库性能优化无处不在，我们所作的一切都是为了性能的优化。
解决问题的最高境界是将问题消灭在萌芽阶段，同样性能优化的最佳时期是在需求分析阶段和系统架构设计阶段。
4.3. 优化些什么？
●首先需要优化需求
这里所指的优化并非是指数据库技术方面的优化，而是在项目的需求分析阶段对客户的性能需求本身进行优化，目的只有一个：得出切实可行的数据库性能指标！数据库设计所作的一切可以说都是在围绕着如何满足数据库性能指标在作。可以说在性能指标面前成王败寇，没有任何回旋的余地，性能指标对于数据库设计工作的顺利进行有着无比重要的意义，因此在项目的需求分析阶段，数据库设计小组必须和需求组的同事合作，与客户反复协商，最终确定切实可行的数据库性能指标，在这期间客户很可能会提出一些不可能实现或者实现起来很困难的性能需求，这些性能需求都将会在后续的数据库设计工作中产生极大的实现风险，数据库设计小则必须识别出这类需求并且和需求组密切配合与客户沟通协商，争取将风险降到最小，之所以强调数据库设计小组需要作这部分工作是因为数据库设计小组对于数据库的设计实现有着更丰富的经验，对于风险需求的识别相比需求组的同事更有发言权。
●优化硬件方案
如果客户要求你夺取F1大奖赛冠军，而只提供给你一辆奥拓，你觉得你能完成任务吗？我觉得恐怕赛纳在世也不可能完成。
数据库设计小组必需要在系统架构阶段和系统集成组的同事密切合作，依据数据库性能指标认真研究硬件方案的可行性。如果硬件基础和性能指标脱节，再怎么优化也是无济于事。
数据库设计小组要对整个项目的顺利进行负责，绝对不能放弃对于硬件方案的优化，其目的就在于为后续的数据库物理设计工作创造稳定、宽松的环境和条件。
●优化数据库逻辑设计
数据库逻辑设计的优化工作说到底就是随着对客户业务需求的分析不断细化，对已有的数据库逻辑模型进行调整，使之更加适应系统开发的需要。
这一阶段优化的主要工作在于对逻辑模型中的实体进行增删、修改，剔除逻辑模型中的冗余数据。
●优化数据库物理设计
数据库物理设计的优化工作主要从以下两方面入手：
1、数据存储方式的优化。通过对表空间规划的调整、分区规划的调
整、日志空间大小的调整等等技术手段力争达到使用最小的磁盘I/O代价获取所需数据。
2、提高数据读取速度。通过对索引设置的优化、数据存取路径的调
整等技术手段来提高数据读取速度。
●PL/SQL优化
根据经验，解决由于SQL语句写法不合理而造成的性能问题大约占到性能优化工作的80％以上，因此如何缩减低效SQL所带来的不必要工作量就成为数据库设计小组所必须面对的一个问题。
我觉得可以从以下方面入手：
1、在编码工作开始前组织使用数据库进行开发的编码人员进行
PL/SQL编程的培训，让开发人员学会如何正确地进行SQL语句的书写。
2、对于关键的、有可能成为数据库性能瓶颈的核心业务应用模块所
进行的PL/SQL编程，数据库设计小组应当定期作代码检查。
3、对于编码工作中开发人员所面临的PL/SQL编程所遇到的技术问
题，数据库设计小组应充分做好技术支持工作。
教训：3GSS项目在编码工作进行前没有统一对开发人员进行PL/SQL 编程的培训，因此造成了开发人员SQL语句编写的混乱，重新调整、优化这些不合格的SQL语句浪费了很多的工作量。
●数据库运行期优化
这里所作的主要是对数据库DBMS的配置优化，任何一个数据库，特别是Oracle这样的大型数据库系统，都需要根据具体应用情况进行配置后才能够达到最优的运行性能。
这项工作需要使用具有DBA资格的资源来完成，可以在编码阶段结合性能测试工作在系统真实运行环境下进行。
5. 综述
在大型项目中作数据库设计工作，一定要高瞻远瞩，未雨绸缪，将问
题消灭在萌芽阶段才是解决问题代价最低的方法。
一定要将数据库设计工作的中心放在整个项目的需求阶段、架构设计
阶段、详细设计阶段，其中又以需求阶段和架构设计阶段为重，数据
库设计工作一定要走在系统设计工作的前面。
性能优化工作自始至终贯穿于数据库设计工作的全过程，不能将性能
优化工作与数据库设计工作割裂开来。
附录I-3 数据库设计报告
基于https://www.wendangku.net/doc/334506179.html,的火车售票系统数据库设计报告
版本历史
目录 0. 文档介绍 (4) 0.1文档目的 (4) 0.2文档范围 (4) 0.3读者对象 (4) 0.4参考文献 (4) 0.5术语与缩写解释 (5) 1. 数据库环境说明 (6) 2. 数据库的命名规则 (6) 3. 逻辑设计 (6) 4. 物理设计 (7) 4.0表汇总 (8) 4.1表A (8) 4.N 表N (8) 5. 安全性设计 (10) 5.1防止用户直接操作数据库的方法 (10) 5.2用户帐号密码的加密方法 (10) 5.3角色与权限 (11) 6. 优化 (11) 7. 数据库管理与维护说明 (11)
0. 文档介绍 0.1 文档目的 需求的编写是为了研究火车售票系统软件的开发途径和应用方法。同时它也是进行项目策划、概要设计和详细设计的基础，是维护人员进行内部维护，信息更新，验收和测试的依据。本说明书的预期读者是与和售票系统软件开发有联系的决策人。支持本项目的领导和公司人员，软件验证者。 0.2 文档范围 本文档适用于项目开发的设计阶段，在项目开发阶段可按照本文档检验数据库实施情况。 0.3 读者对象 1．本系统的开发人员。 2. 本系统的测试人员。 3. 本系统的客户 0.4 参考文献 提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：[标识符] 作者，文献名称，出版单位（或归属单位），日期 例如： [AAA]作者，《立项建议书》，机构名称，日期 [SPP-PROC-SD] SEPG，系统设计规范，机构名称，日期 [1] [C#专业项目实例开发] Arora，中国水利水电出版社,2007 [2] [数据库原理及应用] 王雯，北京机械工业出版社2009.11 [3][数据库基础与实践技术] 何玉洁，,机械工业出版社.2013.3 [4] [C#数据库系统开发完全手册] 王小科，人们邮电出版社，2006.12 [5] [C#+sql Server中小型信息系统开发实例精选] 黄明，机械工业出版社.2007.4
系统分析师辅导：工作流管理系统体系结构设计
系统分析师辅导：工作流管理系统体系结构设计 摘要：工作流管理系统将最终成为覆盖于各类台式机与网络操作系统之上的业务操作系统，但工作流技术目前还不够完善。作者在深入研究了工作流管理联盟提供的工作流管理系统模型和各大主流工作流管理系统的基础上设计了一套功能全面的工作流管理系统体系结构。本文主要从该体系结构的三个层次深入介绍了该系统结构。 关键词：工作流管理系统、业务操作系统、软件体系结构、业务建模 1、引言 在一个组织内部存在着两种信息：一种是数据信息，另一种是业务信息。在组织之间也同样存在着两种信息：一种是数据信息，另一种是业务往来信息。如果这两种信息用计算机系统来管理，前一种属于组织内部的信息系统，后一种属于B2B电子商务系统。目前对数据信息的计算机管理系统（即：数据库管理系统）经过多年的发展已经成熟。对业务过程的计算机管理系统由于比较复杂，可变因素较多，难度大，因此发展还不成熟。工作流技术作为现代组织实现过程管理与过程控制的一项关键技术，为组织的业务处理过程提供了一个从模型建立、管理到运行、分析的完整框架。同时，工作流管理系统（Workflow Management System ,WFMS）通过一套集成化、可互操作的软件工具为这个框架提供了全过程的支持。Thomas Koulopoulos曾预言：工作流管理系统将最终成为覆盖于各类台式机与网络操作系统（如：Windows,Unix,Windows NT）之上的业务操作系统BOS（Business Operating System）,它将带来操作系统的一次革命。但是目前工作流技术无论从理论上还是从实践都还不够完善，要实现Thomas Koulopoulos的预言可能还需有一段路要走。本文主要介绍了由作者独立设计一套工作流管理系统体系结构，以供工作流技术爱好者参考。 2、工作流管理系统的基本概念 顾名思义，工作流就是工作任务在多个人或单位之间的流转。在计算机网络环境下，这种流转实际上表现为信息或数据在多个人之间的传送。工作流管理联盟( Workflow Management Coalition ，WfMC)对工作流的定义是：“业务过程的部分或全部在计算机应用环境下的自动化”。她所要解决的主要问题是，“使在多个参与者之间按照某种预定义规则传递的文档、信息或任务的过程自动进行，从而实现某个预期的业务目标，或者是促使此目标的实现”。 工作流管理系统就是通过管理一序列的工作活动以及相关人员、资源、信息技术资料来提供业务处理程序上的自动控制。工作流管理系统通过计算机软件来定义、管理和执行工作流程。在工作流管理系统中计算机运用程序的执行顺序是由工作流逻辑的计算机描述来驱动的。她的主要目标是对业务过程中各步骤(或称活动、环节)发生的先后次序，以及同各个步骤相关的人力、资源、信息资料的调用等进行管理，从而实现业务过程的自动化。当然这种管理可能会在不同的信息及通信环境下实现，所涉及的范围可以小至一个只有几人的工作组，也可以大到政府、企业组织各个机构之间。工作流管理系统将人员、组织结构、设备资源、信息源（如数据库、文件系统、电子邮件、计算机辅助设计工具等）整和成一个整体。这样，工作流管理系统就成为了一个理想的用来收容业务逻辑的业务知识仓库，并给予业务逻辑一个易操作易控制的界面。 工作流管理系统的最大优点就是实现具体应用逻辑和过程逻辑的分离，实现在不修改具体功能的情况下，通过修改业务流程模板来改变系统的功能，完成对组织生产经营过程的部
软件工程-数据库设计规范与命名规则
数据库设计规范、技巧与命名规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据， 满足用户信息要求和处理要求。 数据库设计的各阶段： A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。 B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。 C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。 然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。 D、在物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。 需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis， 简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary，简称DD)来描述。 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一 DBMS 支持的特定数据模型。 概念模型特点： (1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术， 用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示:
数据库课程设计大作业
《数据库原理》课程设计报告 专业：测控技术与仪器 班级：测控071班 学号：200710402112 200710402115 姓名：杜文龙王京京 题目名称：物资管理系统 完成日期：2009年12月25日 昆明理工大学信息工程与自动化学院 2009年12月
物资管理系统 一、课程设计目的： 1.加深对讲授内容的理解 《数据库原理及应用》中有关数据库技术的基本理论、基本概念、设计与实现的方法和阶段性知识，光靠课堂讲授既枯燥无味又难以记住，但它们都很重要，要想熟练掌握，必须经过大量实践环节加深对它们的理解。 2.通过课程设计，掌握数据库系统设计与开发的方法及步骤 数据库是一门应用性很强的学科，开发一个数据库系统需要集理论、系统和应用三方面为一体，以理论为基础，以系统（DBMS）作支柱，以应用为目的，将三者紧密结合起来。同时结合实际需要开发一个真实的数据库系统，对于较大型的系统可多人一起完成，但无论如何都应完成数据库的需求分析、数据的分析与建模、数据库的建立、数据库的开发与运行等全部过程。在此过程中将所学的知识贯穿起来，达到能够纵观全局，分析、设计具有一定规模的题目要求，基本掌握数据库系统设计与开发的基本思路和方法并且做到对知识的全面掌握和运用。 3.培养学生自学以及主动解决问题的能力 通过本次设计，使同学能够主动查阅与数据库相关资料，掌握一些课堂上老师未曾教授的知识，从而达到培养学生自学以及主动解决问题的能力的目的。 二、课程设计基本要求： 1.课程设计应由学生本人独立完成，严禁抄袭。 2.掌握所学的基础理论知识，数据库的基本概念、基本原理、关系数据库的设 计理论、设计方法等。熟悉数据建模工具Visio与数据库管理系统SQLServer 软件的使用。 3.按时上机调试，认真完成课程设计。 4.认真编写课程设计报告。 三、需求分析 信息管理系统是集计算机技术、网络通讯技术为一体的信息系统工程，它能够使企业运行的数据更加准确、及时、全面、详实，同时对各种信息进一步地加工，使企业领导层对生产、经营的决策依据更充分，更具有合理性和库、科学性，并创建出更多的发展机会；另外也进一步加强企业的科学化、合理化、制度化、规范化管理，为企业的管理水平跨上新台阶，为企业持久、健康、稳定的发展打下基础。 这个物资管理系统是以客户机/服务器模式的信息管理模式的信息管理系统。它的开发过程不仅仅是一个编写应用程序的过程，而是以软件工程的思想为指导，从可行性研究开始，经过系统分析、系统设计、系统实施
数据库设计报告
四六级英语考试网上报名系统数据库设计报告
版本历史
目录 0. 文档介绍 (4) 0.1文档目的 (4) 0.2文档范围 (4) 0.3读者对象 (4) 0.4参考文献 (4) 0.5术语与缩写解释 (4) 1. 数据库环境说明 (5) 2. 数据库的命名规则 (5) 3. 逻辑设计 (5) 4. 物理设计 (6) 4.0表汇总 (6) 4.1表A (6) 4.N 表N (6) 5. 安全性设计 (8) 5.1防止用户直接操作数据库的方法 (8) 5.2用户帐号密码的加密方法 (8) 5.3角色与权限 (9) 6. 优化 (9) 7. 数据库管理与维护说明 (9)
0. 文档介绍 0.1 文档目的 数据库设计文档的编写是为了研究四六级英语考试网上报名系统的开发途径和应用方法。同时它也是进行项目策划，概要设计和详细设计的基础，是维护人员进行内部维护，信息更新，验收和测试的依据。本说明书的预期读者是于该系统开发有联系的决策人。支持本项目的领导和公司员工，软件测试人员。 0.2 文档范围 本文档适用于项目开发的设计阶段，在项目开发阶段可以按照本文档检验数据库实施情况。 0.3 读者对象 开发人员，用户，测试人员，后期修改人员。 0.4 参考文献 [C#+sql Server中小型信息系统开发实例精选] 黄明，机械工业出版社.2007.4 [C#专业项目实例开发] Arora，中国水利水电出版社,2007 [数据库原理及应用] 王雯，北京机械工业出版社2009.11 [数据库基础与实践技术] 何玉洁，,机械工业出版社.2013.3 [C#数据库系统开发完全手册] 王小科，人们邮电出版社，2006.12 0.5 术语与缩写解释
OA办公系统工作流设计文档
OA办公系统 （工作流部分） 概要设计说明书 第1版 目录 1、概述 1.1 工作流设计目标 通过ＯＡ系统提供的JBＰＭ4引擎设计流程，实现流程的跳转，表单的设计以及表单和流程的关联。 1.2 文档的作用 本文档基于广州宏天软件有限公司开发的ＯＡ办公系统的工作流模块设计的.仅限于流程的简单开发，开发人员快速入门. 2、流程设计 2.１售前流程 2。2 采购流程 2.3 维保流程 2.4 故障处理流程 1.1 概述 主要是流程图,表单的设计以及流程图和表单关联的设计.以一个售前的流程例子介绍他们公用的部分的开发设计。
2.1。１售前流程图设计 由此页面进入“在线流程设计". 下面的页面就是OA系统提供编辑流程图的页面,可以把所需要的流程通过此工具画出来 在这里简单介绍下几个节点的作用 （1）开始节点开始：这是一个流程的起点，一个流程可以没有结束节点但是一定要有节点。 （2）任务节点:这是一个需要人参与的节点,需要人去提交数据。
（3）决策节点：这是一个特殊的节点，它不需要人参与,但是需要一些人定义的条件来决定其下一步条到哪一个分支。 （4）同步节点:这个节点是当２个分支需要同时执行时所用到的节点。（注：此节点通常和下面的合并节点成对使用，这样可以保证一个分支结束流程不会结束,等另外的分支都结束后流程才会结束） （5）合并节点:此节点是2个分支需要合并的时候的节点.其使用方法参照同步。 （6）此节点不是必须的,但是基本上都是需要这个节点的.他代表了一个流程的结束。 （7）流程节点的连接.当鼠标移到一个节点上时会有４个红点在四周，拖动一个红点到另一个节点的红点就可以连接2个节点。注意一个节点的到另一节点的线上的名字不能重复，因为流程引擎是通过流程线上的名字来跳转的,同样任何2个节点的名字也不能相同，否则会有冲突。流程就不能发布。 发布流程:再设计页面的右边会有一栏流程的详细信息如下图：
数据库设计和编码规范
数据库设计和编码规范 Version
目录
简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错，保持团队支持顺畅，系统长久使用后不至于紊乱，让管理者易于在众多对象中，获取所需或理清问题。 同时，定义标准程序也需要团队合作，讨论出大家愿意遵循的规范。随着时间演进，还需要逐步校订与修改规范，让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契，而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户，如数据库管理员、程序设计人员和程序开发人员，可以直观地辨识对象用途。而命名规则大都约定俗成，可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例，让用户混淆自定义对象和系统对象或关键词。 例如，存储过程不要以sp_或xp_开头，因为SQL SERVER的系统存储过程以 sp_开头，扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略，要让对象的用途直观易懂，但也不宜过长，造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。
6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定，数据库对象包括表、视图（查询）、存储过程（参数查询）、函数、约束。对象名字由前缀和实际名字组成，长度不超过30。避免中文和保留关键字，做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。例如：
信息系统开发实验报告：大学生创新创业项目管理系统地数据库设计
WORD格式 课程实验报告 专业年级 课程名称信息系统开发 指导教师 学生姓名 学号 实验日期2016年11月22日 实验地点 实验成绩 教务处制 2016年11月27日
WORD格式 实验项目大学生创新创业项目管理系统的数据库设计 名称 1、了解数据库的设计步骤； 实验 2、熟练掌握MicrosoftVisio；目 的及要求 3、熟练掌握E-R图的绘制； 4、掌握将数据库概念结构转化为逻辑结构的步骤。 1、采用MicrosoftVisio完成大学生创新创业项目管理系统的数据库的所有实 验 E-R图的绘制； 内容 2、根据E-R图，使用SQLServer2000作为DBM，S完成数据库的设计。 一．设置数据库实体及其属性 1、学生 属性：略 2、指导教师 属性：工号、姓名、学历、学位、专业、职称、职务、QQ、WX、手机号码、密码 3、工作人员 属性：工号、姓名、职务、QQ、WX、手机号码、密码 4、项目 属性：项目编号、项目名称、项目类型、申请人、申请时间、申请书、指导教师、指导 意见、审核意见、审核人、审核时间、是否立项 5、开题报告 实验步骤属性：报告编号、所属项目、摘要、报告附件、上传时间、指导教师意见、审核意见、审核人、审核时间、审核结果 6、实践学习 属性：编号、所属项目、类型、内容、附件 7、结项申请 属性：申请编号、所属项目、内容摘要、附件、指导教师意见、审核意见、审核人、审 核时间、审核结果 8、项目成果 属性：成果编号，所属项目、成果内容、附件、指导教师意见、审核意见、审核人、审 核时间、审核结果 二．绘制总体的E-R图
三．绘制各个实体的E-R图1.学生实体E-R图 2.指导教师实体E-R图
数据库课程设计完整版
HUNAN CITY UNIVERSITY 数据库系统课程设计设计题目：宿舍管理信息系统 姓名： 学号： 专业：信息与计算科学 指导教师： 20年 12月1日 目录 引言 3 一、人员分配 4 二、课程设计目的和要求 4 三、课程设计过程 1.需求分析阶段 1.1应用背景 5 1.2需求分析目标5 1.3系统设计概要 5 1.4软件处理对象 6 1.5系统可行性分析 6 1.6系统设计目标及意义7
1.7系统业务流程及具体功能 7 8 2.系统的数据字典11 3.概念结构设计阶段 13 4.逻辑结构设计阶段 15 5.物理结构设计阶段 18 6.数据库实施 18 7.数据库的运行和维护 18 7.1 解决问题方法 19 7.2 系统维护 19 7.3 数据库性能评价 19 四、课程设计心得. 20 参考文献 20 引言 学生宿舍管理系统对于一个学校来说是必不可少的组成部分。目前好多学校还停留在宿舍管理人员手工记录数据的最初阶段，手工记录对于规模小的学校来说还勉强可以接受，但对于学生信息量比较庞大，需要记录存档的数据比较多的高校来说，人工记录是相当麻烦的。而且当查找某条记录时，由于数据量庞大，还只能靠人工去一条一条的查找，这样不但麻烦还浪费了许多时间，效率也比较低。当今社会是飞速进步的世界，原始的记录方式已经被社会所淘汰了，计算机化管理正是适应时代的产物。信息世界永远不会是一个平静的世界，当一种技术不能满足需求时，就会有新的技术诞生并取代旧技术。21世纪的今天,信息社会占着主流地位，计算机在各行各业中的运用已经得到普及，自动化、信息化的管理越来越广泛应用于各个领域。我们针对如此，设计了一套学生宿舍管理系统。学生宿舍管理系统采用的是计算机化管理，系统做的尽量人性化，使用者会感到操作非常方便，管理人员需要做的就是将数据输入到系统的数据库中去。由于数据库存储容量相当大，而且比较稳定，适合较长时间的保存，也不容易丢失。这无疑是为信息存储量比较大的学校提供了
数据库设计报告
软件数据库设计报告文档模板 1. 引言 (2) 1.1编写目的 (2) 1.2项目来源 (2) 1.3文档约定 (2) 1.4预期读者和阅读建议 (2) 1.5参考资料 (2) 2. 数据库命名规则 (3) 3. 数据库设计说明 (3) 3.1数据库逻辑设计 (3) 3.2数据库物理设计 (3) 3.3数据库分布 (3) 3.4基表设计 (4) 3.5视图设计 (5) 3.6索引设计 (6) 3.7完整性约束 (7) 3.8授权设计 (7) 3.9触发器设计 (8) 3.10存储过程设计 (8) 3.11数据复制设计 (9) 4. 词汇表 (10) 5. 历史数据处理 (10)
引言 引言是对这份数据库设计说明书的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份数据库设计说明书是为哪份软件产品编写的，开发这个软件产品意义、作用以及最终要达到的意图。通过这份数据库设计说明书详尽准确地描述了该软件产品的数据库结构。如果这份数据库设计说明书只与整个系统的某一部分有关系，那么只定义数据库设计说明书中说明的那个部分或子系统。 1.2 项目来源 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者； ●软件开发者； ●产品使用者。 1.3 文档约定 描述编写文档时所采用的各种排版约定。排版约定应该包括： ●命名方法； ●提示方式； ●通配符号： ●等等。 1.4 预期读者和阅读建议 列举本数据库设计说明书所针对的各种不同的预期读者，例如，可能包括： ●开发人员； ●项目经理； ●测试人员； ●文档编写人员。 并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。 1.5 参考资料 列举编写需求规格说明书时所用到的参考文献及资料，可能包括； ●本项目的合同书； ●上级机关有关本项目的批文；
数据库设计规范
1概述 1.1目的 软件研发数据库设计规范作为数据库设计的操作规范，详细描述了数据库设计过程及结果，用于指导系统设计人员正确理解和开展数据库设计。 1.2适用范围 1.3术语定义 DBMS：数据库管理系统，常用的商业DBMS有Oracle, SQL Server, DB2等。 数据库设计：数据库设计是在给定的应用场景下，构造适用的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 概念数据模型：概念数据模型以实体-关系 (Entity-RelationShip,简称E-R)理论为基础，并对这一理论进行了扩充。它从用户的观点出发对信息进行建模，主要用于数据库概念级别的设计，独立于机器和各DBMS产品。可以用Sybase PowerDesigner工具来建立概念数据模型（CDM）。 逻辑数据模型：将概念数据模型转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。可
以用Sybase PowerDesigner工具直接建立逻辑数据模型（LDM），或者通过CDM转换得到。 物理数据模型：在逻辑数据模型基础上，根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。可以用Sybase PowerDesigner工具直接建立物理数据模型（PDM），或者通过CDM / LDM转换得到。 2数据库设计原则 按阶段实施并形成该阶段的成果物 一般符合3NF范式要求；兼顾规范与效率 使用公司规定的数据库设计软件工具 命名符合公司标准和项目标准 3数据库设计目标 规范性：一般符合3NF范式要求，减少冗余数据。 高效率：兼顾规范与效率，适当进行反范式化，满足应用系统的性能要求。 紧凑性：例如能用char(10)的就不要用char(20)，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。 易用性：数据库设计清晰易用，用户和开发人员均能容
11-个重要的数据库设计规则
11-个重要的数据库设计规则
?简介 在您开始阅读这篇文章之前，我得明确地告诉您，我并不是一个数据库设计领域的大师。以下列出的11点是我对自己在平时项目实践和阅读中学习到的经验总结出来的个人见解。我个人认为它们对我的数据库设计提供了很大的帮助。实属一家之言，欢迎拍砖: ) 我之所以写下这篇这么完整的文章是因为，很多开发者一参与到数据库设计，就会很自然地把“三范式”当作银弹一样来使用。他们往往认为遵循这个规范就是数据库设计的唯一标准。由于这种心态，他们往往尽管一路碰壁也会坚持把项目做下去。 如果你对“三范式”不清楚，请点击这里（FQ）一步一步的了解什么是“三范式”。 大家都说标准规范是重要的指导方针并且也这么做着，但是把它当作石头上的一块标记来记着（死记硬背）还是会带来麻烦的。以下11点是我在数据库设计时最优先考虑的规则。 ?规则1：弄清楚将要开发的应用程序是什么性质的（OLTP 还是OPAP）？
当你要开始设计一个数据库的时候，你应该首先要分析出你为之设计的应用程序是什么类型的，它是“事务处理型”（Transactional）的还是“分析型”（Analytical）的？你会发现许多开发人员采用标准化做法去设计数据库，而不考虑目标程序是什么类型的，这样做出来的程序很快就会陷入性能、客户定制化的问题当中。正如前面所说的，这里有两种应用程序类型，“基于事务处理”和“基于分析”，下面让我们来了解一下这两种类型究竟说的是什么意思。 事务处理型：这种类型的应用程序，你的最终用户更关注数据的增查改删（CRUD，Creating/Reading/Updating/Deleting）。这种类型更加官方的叫法是“OLTP”。 分析型：这种类型的应用程序，你的最终用户更关注数据分析、报表、趋势预测等等功能。这一类的数据库的“插入”和“更新”操作相对来说是比较少的。它们主要的目的是更加快速地查询、分析数据。这种类型更加官方的叫法是“OLAP”。 那么换句话说，如果你认为插入、更新、删除数据这些操作在你的程序中更为突出的话，那就设计一个规范化的表否则的话就去创建一个扁平的、不规范化的数据库结构。
数据库设计心得体会(精选多篇)
数据库设计心得体会(精选多篇) 跟老板做了两个算是比较大的项目，数据库主体都是我设计的。第一个感觉很失败；第二个现在正在用，虽然总结了第一个的教训，但感觉还是有些遗憾。把这过程中的一些心得记在这里，以便日后用到时来查阅。若以后还有机会再设计数据库——现在倒还有些期待，呵呵，再有新的体会，也全部补充到这里。 1.尽量使用数据冗余。 随着磁盘容量的大幅飙升，这一点已经不会产生什么问题。当然冗余归冗余，不能把数据的关联弄的乱七八糟的。 本科数据库课程中学的知识直接拿来，在实际中会出大问题。满足三级范式的数据库结构会让你面对大量的连表查询，应用程序中会用到大量的数据库访问，既繁琐（烦死你）又使程序运行速度减慢。 2.尽量不要使用varchar(max)类型 这一点主要是用动软代码生成器自动生成代码时，如果varchar 的最大长度指定为max，在自动生成代码时，它无法生成这一最大长度，需要手动补进去。 现在感觉用个varchar(1000)就够了。 3.使用预留字段。 数据库表（尤其是动态表格），在你把所有字段都设计好了之后，再添加几个备注字段和预留字段。 之前我觉得这样做没多大意义，因为预留字段的列名是没有实际意义的。这样程序中使用的时候就会让人费解。但现在觉得还是有必
要的，很有必要的，即便在用到时需要自己十分清楚之前预留的无意义字段现在表示什么意义。不过我的第二个数据库中还是没采用，这也是遗憾之处啊。 个人感觉用note1、note2、r1（r表示reserve）、r2、r3，2个备注字段和3个预留字段就足够了,再多的话就不容易记住哪个字段具体表示什么意义了，容易晕。类型就都用varchar(200)吧。 数据库设计心得体会（2）： 在我看来，数据库课程设计主要的目标是利用课程中学到的数据库知识和技术较好的开发设计出数据库应用系统，去解决各行各业化处理的要求。通过这次的课程设计，可以巩固我们对数据库基本原理和基础理论的理解，掌握数据库应用系统设计开发的基本方法，进一步提高我们综合运用所学知识的能力。 当我们这组决定做大学生就业咨询系统时，我们并没有着手写程序。而是大家一起商量这个系统概述、系统目标、系统需求、业务流程分析、数据流程分析和数据词典。当这些都准备好了之后，我们进行模块的分工。每个人都有自己的模块设计，而且写出来的代码要求可以实现相应模块的功能，得到理想的效果。当每个人都把自己的分工做好了，最后会由一个人把这些全部组合搭建在一起。我们使用的是html和php相互嵌套使用，当一个系统做好了之后，我会好好地把程序都看一遍，理会其中的奥秘。 我所负责的是数据库的备份和还原还有一些界面的实现。还记得自己刚接触html的时候，觉得很感兴趣，所以有一段时间几乎到了
数据库设计报告
《数据库系统概论》课程设计报告 课程名称：数据库系统概论 院系年级：14级电气信息工程系 专业班级：计算机科学与技术1班 学号： 姓名： 联系电话： 指导教师： 安徽马鞍山
2016年6月 第一章相关方法技术 1.1数据库应用特点 数据库技术是现代信息科学与技术的重要组成部分，是计算机数据处理与信息管理系统的核心。数据库技术研究和解决了计算机信息处理过程中大量数据有效地组织和存储的问题，在数据库系统中减少数据存储冗余、实现数据共享、保障数据安全以及高效地检索数据和处理数据。随着计算机技术与网络通信技术的发展，数据库技术已成为信息社会中对大量数据进行组织与管理的重要技术手段及软件技术，是网络信息化管理系统的基础。 1.2数据与处理 以处理为中心 根据处理功能设计数据文件，处理功能需要什么数据就创建什么数据文件。处理功能是主动的，数据结构是依赖的。势必导致数据的冗余存储，潜在数据的不一致性。只适合科学计算，不适合数据密集型的事务处理系统。 以数据为中心 只要应用领域内的业务内容不变，其信息结构是稳定，多变的是处理功能。主张设计稳定的数据结构，自动适应处理程序的多变性。凡是数据库应用系统，适合采用以数据为中心的应用模式。 1.3数据库设计方法 （1）功能驱动方法: 这个方法设计依赖处理中心强调先根据功能要求画出分层的数据流程图从数据流程图当中收集数据项及其数据存储以及数据字典依据数字字典分析提取出数据库相关的各种信息类。 （2）E-R建模方法： 采用以数据为中心的设计策略在初步了解领域当中各种业务需求和处理过程基础上 1.4数据库设计步骤 按照规范化设计方法，从数据库应用系统设计和开发的全过程来考虑，将数据库及其应用软件系统的生命周期可以细分为七 个阶段：规划、需求分析、概念结构设计、逻辑结构设计、物理结构设计、实施及运行维护。 各阶段需完成的工作分别为： 1、应用规划 规划阶段进行系统的必要性和可行性分析，确定数据库系统在整个管理系统中的地位。 规划阶段必须要完成的任务包括：确定系统的范围；确定开发工作所需的资源（人员、硬件和软件）；估算软件开发的成本；确定项目进度。
i-3 数据库设计报告
基于的火车售票系统数据库设计报告
版本历史
目录 0. 文档介绍 (4) 文档目的 (4) 文档范围 (4) 读者对象 (4) 参考文献 (4) 术语与缩写解释 (5) 1. 数据库环境说明 (6) 2. 数据库的命名规则 (6) 3. 逻辑设计 (6) 4. 物理设计 (7) 表汇总 (8) 表A (8) 表N (8)
5. 安全性设计 (10) 防止用户直接操作数据库的方法 (10) 用户帐号密码的加密方法 (10) 角色与权限 (11) 6. 优化 (11) 7. 数据库管理与维护说明 (11)
0. 文档介绍 文档目的 需求的编写是为了研究火车售票系统软件的开发途径和应用方法。同时它也是进行项目策划、概要设计和详细设计的基础，是维护人员进行内部维护，信息更新，验收和测试的依据。本说明书的预期读者是与和售票系统软件开发有联系的决策人。支持本项目的领导和公司人员，软件验证者。 文档范围 本文档适用于项目开发的设计阶段，在项目开发阶段可按照本文档检验数据库实施情况。 读者对象 1．本系统的开发人员。 2. 本系统的测试人员。 3. 本系统的客户 参考文献 提示：列出本文档的所有参考文献（可以是非正式出版物），格式
如下： [标识符] 作者，文献名称，出版单位（或归属单位），日期 例如： [AAA]作者，《立项建议书》，机构名称，日期 [SPP-PROC-SD] SEPG，系统设计规范，机构名称，日期 [1] [C#专业项目实例开发] Arora，中国水利水电出版社,2007 [2] [数据库原理及应用] 王雯，北京机械工业出版社 [3][数据库基础与实践技术] 何玉洁，,机械工业出版社. [4] [C#数据库系统开发完全手册] 王小科，人们邮电出版社， [5] [C#+sql Server中小型信息系统开发实例精选] 黄明，机械工业出版社. 术语与缩写解释
Activiti工作流数据库表结构
Activiti数据表结构 目录 1ACTIVITI数据库表结构 ----------------------------------------------------------------------------------------------- 2 1.1数据库表名说明 ------------------------------------------------------------------------------------------------ 2 1.2数据库表结构---------------------------------------------------------------------------------------------------- 3 1.2.1Activiti数据表清单: ---------------------------------------------------------------------------------------- 3 1.2.2表名:ACT_GE_BYTEARRAY （通用的流程定义和流程资源）-------------------------------- 3 1.2.3表名:ACT_GE_PROPERTY （系统相关属性） ----------------------------------------------------- 4 1.2.4表名:ACT_HI_ACTINST （历史节点表） ------------------------------------------------------------ 5 1.2.5表名:ACT_HI_ATTACHMENT （附件信息）-------------------------------------------------------- 6 1.2.6表名:ACT_HI_COMMENT （历史审批意见表）-------------------------------------------------- 6 1.2.7表名:ACT_HI_DETAIL （历史详细信息）----------------------------------------------------------- 7 1.2.8表名:ACT_HI_IDENTITYLINK （历史流程人员表） ---------------------------------------------- 8 1.2.9表名:ACT_HI_PROCINST（历史流程实例信息）核心表---------------------------------------- 8 1.2.10表名:ACT_HI_TASKINST（历史任务流程实例信息）核心表------------------------------ 9 1.2.11表名:ACT_HI_VARINST（历史变量信息） ------------------------------------------------------ 9 1.2.12表名:ACT_ID_GROUP（用户组表） ------------------------------------------------------------ 10 1.2.13表名:ACT_ID_INFO （用户扩展信息表） ---------------------------------------------------- 10 1.2.14表名:ACT_ID_MEMBERSHIP（用户用户组关联表） -------------------------------------- 11 1.2.15表名:ACT_ID_USER（用户信息表） ------------------------------------------------------------ 11 1.2.16表名:ACT_RE_DEPLOYMENT（部署信息表）------------------------------------------------ 12 1.2.17表名:ACT_RE_MODEL (流程设计模型部署表) ----------------------------------------------- 12 1.2.18表名:ACT_RE_PROCDEF （流程定义表） ---------------------------------------------------- 13 1.2.19表名:ACT_RU_EVENT_SUBSCR (运行时事件) ------------------------------------------------- 14 1.2.20表名:ACT_RU_EXECUTION （运行时流程执行实例） ----------------------------------- 15 1.2.21表名:ACT_RU_IDENTITYLINK（身份联系） --------------------------------------------------- 15 1.2.22表名:ACT_RU_JOB（运行中的任务）---------------------------------------------------------- 16 1.2.23表名:ACT_RU_TASK(运行时任务数据表) ------------------------------------------------------ 16 1.2.24表名:ACT_RU_VARIABLE(运行时流程变量数据表) ----------------------------------------- 17 2ACTIVITI中主要对象的关系 -------------------------------------------------------------------------------------- 18
数据库设计规范
数据库设计规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个dbms产品的概念模式（信息世界模型），用e-r图来描述。在逻辑设计阶段将e-r图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（view）形成数据的外模式。在物理设计阶段根据dbms特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法（structured analysis，简称sa方法）从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典（data dictionary，简称dd）来描述。 数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。 数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度， 取值范围，取值含义，与其他数据项的逻辑关系｝ 数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝ 数据流描述＝｛数据流名，说明，数据流来源，数据流去向， 组成:｛数据结构｝，平均流量，高峰期流量｝ 数据存储描述＝｛数据存储名，说明，编号，流入的数据流，流出的数据流， 组成:｛数据结构｝，数据量，存取方式｝ 处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝, 处理:｛简要说明｝｝
数据库设计报告完整
数据库课程设计 指导书 昆明理工大学自动化系 20xx年12月 数据库技术是近年来计算机科学技术中发展最快的领域之一，它已成为计算机信息系统与应用系统的核心技术和重要基础。《数据库原理及应用》课程设计
重视实践环节，对于巩固数据库知识，加强学生的实际动手能力和提高学生综合素质十分必要。课程设计的目的和要求有以下几方面： 一、课程设计目的： 1.加深对讲授内容的理解 《数据库原理及应用》中有关数据库技术的基本理论、基本概念、设计与实现的方法和阶段性知识，光靠课堂讲授既枯燥无味又难以记住，但它们都很重要，要想熟练掌握，必须经过大量实践环节加深对它们的理解。 2.通过课程设计，掌握数据库系统设计与开发的方法及步骤 数据库是一门应用性很强的学科，开发一个数据库系统需要集理论、系统和应用三方面为一体，以理论为基础，以系统（DBMS）作支柱，以应用为目的，将三者紧密结合起来。同时结合实际需要开发一个真实的数据库系统，对于较大型的系统可多人一起完成，但无论如何都应完成数据库的需求分析、数据的分析与建模、数据库的建立、数据库的开发与运行等全部过程。在此过程中将所学的知识贯穿起来，达到能够纵观全局，分析、设计具有一定规模的题目要求，基本掌握数据库系统设计与开发的基本思路和方法并且做到对知识的全面掌握和运用。 3.培养学生自学以及主动解决问题的能力 通过本次设计，使同学能够主动查阅与数据库相关资料，掌握一些课堂上老师未曾教授的知识，从而达到培养学生自学以及主动解决问题的能力的目的。 二、课程设计基本要求： 1.课程设计应由学生本人独立完成完成，严禁抄袭，如果发现最后的设计基本 相同者（系统需求分析与功能设计、数据库的概念设计、逻辑设计，数据库的实现与运行等内容基本相同），一经验收教师认定其抄袭行为，则成绩均为不及格。 2.掌握所学的基础理论知识，数据库的基本概念、基本原理、关系数据库的设 计理论、设计方法等。熟悉数据建模工具PowerDesigner与数据库管理系统SqlServer软件的使用。 3.按时上机调试，认真完成课程设计。 4.认真编写课程设计报告，课程设计报告的书写格式见附录2 数据库技术是近年来计算机科学技术中发展最快的领域之一，它已成为计算机信息系统与应用系统的核心技术和重要基础。《数据库原理及应用》课程设计重视实践环节，对于巩固数据库知识，加强学生的实际动手能力和提高学生综合素质十分必要。课程设计的目的和要求有以下几方面： 三、前言 设计物资管理数据库系统的目的是为了全面管理仓库中储存的商品和货物、维护公司资产的安全完整、缩短库存信息流转时间，使经营公司的物资管理层次分明、井然有序，为采购和销售提供依据，从而提高公司的经营效率。物资管理数据库主要通过存储供货商、购货商、产品等的信息，实现下列任务：保管好库存物资，做到数量充足和准确、质量完好、确保安全、收发迅速、服务周到、降低费用、加速资金周转。 四、需求分析