用云计算数据库进行的数据库设计论文（小编整理）

第一篇：用云计算数据库进行的数据库设计论文

摘要：云计算数据库涉及机房、服务器、工程师、工作人员等多个因素，需要实现垮地区、跨部门之间的高效,协同工作；云计算数据库作为建立在互联网之上的新一代基础设施，近年来在国内外引起了注意。通过云计算数据库技术整合数据库信息的各种资源，研究云计算数据库系统联网的实现。

关键词：云计算数据库；云计算数据库系统；云计算数据库数据

编制概要设计说明书。系统要求：云计算数据库概要设计就是要确定云计算数据库软件系统所要完成任务的详细计划。确定完成计划，就耍落实主要技术指标。

（1）系统日标

主要是确定云计算数据库系统要达到的目的。系统软件要解决什么问题。确定目标，对于软件系统的开发是十分关键的。这是关系到软件系统质量高低，开发成功与否的重要问题。

（2）设计供选择的方案

把数据流图中的处理逻辑地进行组合，不同的组合可能就是不同的实现方案。分析各种方案，首先抛弃行不通的方案，然后提供各个合理方案的资料。通过云计算数据库设计来进行的数据库设计就是云计算数据库设计这些方案是：①数据流程图。

②数据词典。

③实现该系统的进度计划。

④通用性与适应性。

⑤保密性。

（3）推荐最佳实现方案

系统分析员应对比各个合理方案的利弊，选择一个最佳方案向用户推荐，并为所推荐方案制定详细的实现计划。用户和有关专家应认真审查分析员所提供的几种方案，如果确认某一个方案为最住方案，应提醒用户进步审核，从而选择和确认这最佳方案。

（4）软件结构设计

为了实现目标系统，要设计出这个系统的所有程序和数据文件。

有关系统设计的具体方法，有两种不同的论点，分别称为自顶向下的设计方法和白底向上的设计方法。

为进行结构设计，首先把复杂的功能进一步分解，分解为一系列比较简单的功能，此数据流图也要进一步细化。通常一个模块完成一个适当的子功能。分析员应把模块组织成层次结构，顶层模块调用它的卜一层模块，下一层模块再调用其下层模块，如此依次向下，最下层模块能完成某具体的功能。软件的结构可用层次图来描绘。层次图适合于描绘软件的层次结构，特别适合于自项向下设计时使用。

设计云计算数据库模块结构。设计模块结构是概要设计阶段中最主要和最重要的工作任务。其标志是绘制出具有良好结构的模块图。

顺序内聚。如果模块内某个成分的输出是另一成分的输入，则两个模块必须依次执行，称为顺序内聚，功能内聚：一个模块内所有的元素都是完成某一功能所必需的处理。由这些兀紊组成一个整体，从而完成一个特定的功能，则称为功能内聚，功能内聚是最高程度的内聚。

通过云计算数据库设计来进行的数据库设计就是云计算数据库设计（1）云计算数据库设计思想云计算数据库的设计遵循由人来完成的。是根据系统分析数据流图，导出系统的模块图。层层分解的基本思想。

云计算数据库通常要设计侧重于定义软件系统的宏观结构，即进行模块的划分，定义每个模块的功能、性能以及模块之间的接口关系。

（2）云计算数据库设计，标出它们的控制层。

云计算数据库云计算数据库设计的方法：先将系统划分为几个大模块，再对大模块进行分析，直至最终获得的每一个模块都是功能单一的模块为止。

通过云计算数据库设计来进行的数据库设计就是云计算数据库设计。

①首先划分最初的两层模块——第一次分解。云计算数据库，先导出顶层和二层模块。项层模块主要起系统主控作用．为主控模块。这是一个控制性的功能选择菜单。根据菜单选择，可随时调用第二层各个子模块。第二层各子模块执行完功能后，都将执行权返交给主控模块。第二层各个子模块，分别完成原始数据输入、处理、输出等工作。

②系统第二次模块分解。

在首次分解获得的模块图中，模块分解工作终止的标志是模块图中每一个模块均是聚合度高、功能单一的独立的模块。所以，耍对第二次模块分解的某些底层模块进一步分解，分解成便于计算机处理的模块。这里对M11模块的进一步分解，此时M1l相应变成了控制模块。

③系统模块的进一步分解。

这里对M21模块的进一步分解，此时M2l相应变成了控制模块。

（3）模块图的补充和完善。

通过逐层分解，获得了系统的云计算数据库，形成了系统的总体结构。由于计算机的特殊性，这个结构还可能不够完善，有必要从以下方面加以补充，做好系统的维护工作。

①系统首先启用前的初始化工作。主要指新系统启用前对旧的数据进行必要的处理，从而为新的系统启动做好准备。

②代码的维护工作。系统在执行过程之中要涉及到某些编码，需要一个编码处理模块。此模块要完成代码的增加、删除、修改、查询、输入等功能。

③屏幕查询工作。查询是计算，迅速进行信息检索的功能。系统设置查询功能，对本系统和各种信息进行查询。

参考文献：

[1]李隽云计算与数据存储结合的难点分析南京：中国云计算论坛，2010．12

[2]冯圣中智能数据中心的机遇与挑战南京：中国云计算论坛，2010．12作者简介：郝琪（1980——），男，辽宁沈阳人，助理讲师，本科。研究方向：宽带网络、软件技术、云计算。

第二篇：数据库课程论文

数据库课程小论文

10级 电技九班 丁鹏 2010212024

内容摘要：

数据库是按照数据结构来组织、存储和管理数据的仓库，它产生于距今五十年前，随着信息技术和市场的发展，特别是二十世纪九十年代以后，数据管理不再仅仅是存储和管理数据，而转变成用户所需要的各种数据管理的方式。数据库有很多种类型，从最简单的存储有各种数据的表格到能够进行海量数据存储的大型数据库系统都在各个方面得到了广泛的应用。

本课程主要讲解了数据库基础、数据模型和数据概念、数据库系统的设计方法、SQL Server关系数据库管理系统、数据库保护技术；介绍了数据库系统的开发、数据库设计以及数据库技术的最新研究领域和应用领域及其发展。

关键字：

数据库系统、数据库管理系统、SQL server数据库、数据库设计

二．课程主要内容和基本原理：

（一）.数据库系统：

数据库系统，是由数据库及其管理软件组成的系统。它是为适应数据处理的需要而发展起来的一种较为理想的数据处理的核心机构。它是一个实际可运行的存储、维护和应用系统提供数据的软件系统，是存储介质、处理对象和管理系统的集合体。

数据库系统通常由软件、数据库和数据管理员组成。其软件主要包括操作系统、各种宿主语言、实用程序以及数据库管理系统。数据库由数据库管理系统统一管理，数据的插入、修改和检索均要通过数据库管理系统进行。数据管理员负责创建、监控和维护整个数据库，使数据能被任何有权使用的人有效使用。数据库管理员一般是由业务水平较高、资历较深的人员担任。

数据的结构化，数据的共享性好，数据的独立性好，数据存储粒度小，数据管理系统，为用户提供了友好的接口。数据库系统的核心和基础，是数据模型,现有的数据库系统均是基于某种数据模型的。数据库系统的核心是数据库管理系统。

数据库系统一般由数据库、数据库管理系统（DBMS）、应用系统、数据库管理员和用户构成。DBMS是数据库系统的基础和核心。

（二）.数据库管理系统：

数据库管理系统是一种操纵和管理数据库的大型软件，用于建立、使用和维护数据库，简称dbms。它对数据库进行统一的管理和控制，以保证数据库的安全性和完整性。用户通过dbms访问数据库中的数据，数据库管理员也通过dbms进行数据库的维护工作。它可使多个应用程序和用户用不同的方法在同时或不同时刻去建立，修改和询问数据库。DBMS提供数据定义语言DDL与数据操作语言，供用户定义数据库的模式结构与权限约束，实现对数据的追加、删除等操作。

1.数据定义：DBMS提供数据定义语言DDL，供用户定义数据库的三级模式结构、两级映像以及完整性约束和保密限制等约束。DDL主要用于建立、修改数据库的库结构。DDL所描述的库结构仅仅给出了数据库的框架，数据库的框架信息被存放在数据字典（Data Dictionary）中。

2.数据操作：DBMS提供数据操作语言DML，供用户实现对数据的追加、删除、更新、查询等操作。

3.数据库的运行管理：数据库的运行管理功能是DBMS的运行控制、管理功能，包括多用户环境下的并发控制、安全性检查和存取限制控制、完整性检查和执行、运行日志的组织管理、事务的管理和自动恢复，即保证事务的原子性。这些功能保证了数据库系统的正常运行。

4.数据组织、存储与管理：DBMS要分类组织、存储和管理各种数据，包括数据字典、用户数据、存取路径等，需确定以何种文件结构和存取方式在存储级上组织这些数据，如何实现数据之间的联系。数据组织和存储的基本目标是提高存储空间利用率，选择合适的存取方法提高存取效率。

5.数据库的保护：数据库中的数据是信息社会的战略资源，随数据的保护至关重要。DBMS对数据库的保护通过4个方面来实现：数据库的恢复、数据库的并发控制、数据库的完整性控制、数据库安全性控制。DBMS的其他保护功能还有系统缓冲区的管理以及数据存储的某些自适应调节机制等。

6.数据库的维护：这一部分包括数据库的数据载入、转换、转储、数据库的重组合重构以及性能监控等功能，这些功能分别由各个使用程序来完成。

7.通信：DBMS具有与操作系统的联机处理、分时系统及远程作业输入的相关接口，负责处理数据的传送。对网络环境下的数据库系统，还应该包括DBMS与网络中其他软件系统的通信功能以及数据库之间的互操作功能。

（三）.SQL Server数据库:

Microsoft SQL Server是一个高性能的、多用户的关系型数据库管理系统；它是专为客户/服务器计算环境设计的，是当前最流行的数据库服务器系统之一；它提供的内置数据复制功能、强盗的管理工具和开放式的系统体系结构为基于事务的企业级信息管理方案提供了一个卓越平台。

在 SQL Server数据库中、数据被组织为用户可以看得见的逻辑部件，这些逻辑组件主要包括基本表、视图、存储过程、触发器和用户等。

SQL Server 将用户可以看得到的这些逻辑组件物理地存储在磁盘上的操作系统文件中。作为普通用户只需要关心逻辑组件的存在，二它们的物理实现在很大程度上是透明的，一般只有数据库管理员需要了解和处理数据库的物理实现。

每个SQL Server 实例包括四个系统数据库（master、model、tempdb和msdb）以及一个或多个用户数据库。根据定义的安全权限，每个SQL Server 实例都可以使所有连接到实例的用户使用该实例上的所有数据库。

数据库是建立在操作系统文件上的，SQL Server在发出CREATE DATABASE 命令建立数据库时，会同时发出建立操作系统文件、申请物理存储空间的请求；当CREATE DATABASE 命令成功以后，在物理上和逻辑上都建立了一个新的数据库；然后就可以在数据库中建立各种用户所需要的逻辑组件，如基本表、视图等。

（四）.数据库设计：

数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）。在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。

1.需求分析：

调查和分析用户的业务活动和数据的使用情况，弄清所用数据的种类、范围、数量以及它们在业务活动中交流的情况，确定用户对数据库系统的使用要求和各种约束条件等，形成用户需求规约。

2.概念设计：

对用户要求描述的现实世界(可能是一个工厂、一个商场或者一个学校等)，通过对其中住处的分类、聚集和概括，建立抽象的概念数据模型。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。所建立的模型应避开数据库在计算机上的具体实现细节，用一种抽象的形式表示出来。以扩充的实体—（E-R模型）联系模型方法为例，第一步先明确现实世界各部门所含的各种实体及其属性、实体间的联系以及对信息的制约条件等，从而给出各部门内所用信息的局部描述(在数据库中称为用户的局部视图)。第二步再将前面得到的多个用户的局部视图集成为一个全局视图，即用户要描述的现实世界的概念数据模型。

3.逻辑设计

主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。

4.物理设计：

根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。这一步设计的结果就是所谓“物理数据库”。

5.验证设计：

在上述设计的基础上，收集数据并具体建立一个数据库，运行一些典型的应用任务来验证数据库设计的正确性和合理性。一般，一个大型数据库的设计过程往往需要经过多次循环反复。当设计的某步发现问题时，可能就需要返回到前面去进行修改。因此，在做上述数据库设计时就应考虑到今后修改设计的可能性和方便性。

6.运行与维护设计：

在数据库系统正式投入运行的过程中，必须不断地对其进行调整与修改。

（五）、应用领域及其发展

应用领域

1．多媒体数据库

这类数据库主要存储与多媒体相关的数据，如声音、图像和视频等数据。多媒体数据最大的特点是数据连续，而且数据量比较大，存储需要的空间较大。

2．移动数据库

该类数据库是在移动计算机系统上发展起来的，如笔记本电脑、掌上计算机等。该数据库最大的特点是通过无线数字通信网络传输的。移动数据库可以随时随地地获取和访问数据，为一些商务应用和一些紧急情况带来了很大的便利。

3．空间数据库

这类数据库目前发展比较迅速。它主要包括地理信息数据库（又称为地理信息系统，即GIS）和计算机辅助设计（CAD）数据库。其中地理信息数据库一般存储与地图相关的信息数据；计算机辅助设计数据库一般存储设计信息的空间数据库，如机械、集成电路以及电子设备设计图等。

4．信息检索系统

信息检索就是根据用户输入的信息，从数据库中查找相关的文档或信息，并把查找的信息反馈给用户。信息检索领域和数据库是同步发展的，它是一种典型的联机文档管理系统或者联机图书目录。

5．分布式信息检索

这类数据库是随着Internet的发展而产生的数据库。它一般用于因特网及远距离计算机网络系统中。特别是随着电子商务的发展，这类数据库发展更加迅猛。许多网络用户（如个人、公司或企业等）在自己的计算机中存储信息，同时希望通过网络使用发送电子邮件、文件传输、远程登录方式和别人共享这些信息。分布式信息检索满足了这一要求。

6．专家决策系统

专家决策系统也是数据库应用的一部分。由于越来越多的数据可以联机获取，特别是企业通过这些数据可以对企业的发展作出更好的决策，以使企业更好地运行。由于人工智能的发展，使得专家决策系统的应用更加广泛。

发展趋势

随着信息管理内容的不断扩展，出现了丰富多样的数据模型（层次模型，网状模型，关系模型，面向对象模型，半结构化模型等），新技术也层出不穷（数据流，Web数据管理，数据挖掘等）。目前每隔几年，国际上一些资深的数据库专家就会聚集一堂，探讨数据库研究现状，存在的问题和未来需要关注的新技术焦点。过去已有的几个类似报告包括：1989 年Future Directions inDBMS Research-The Laguna BeachParticipants，1990 年DatabaseSystems : Achievements and Opportunities，1995 年的Database 1991：W.H.Inmon 发表了《构建数据仓库》

三．心得体会：

在做完这次课程论文后，让我再次加深了对数据库的组成原理的理解，对数据库的构建也有更深层次的体会。数据库的每一次发展，都凝聚着人类的智慧和辛勤劳动，每一次创新都给人类带来了巨大的进步。数据库从早期的简单功能，到现在的复杂操作，都是一点一滴发展起来的。这种层次化的让我体会到了，凡事要从小做起，无数的‘小’便成就了‘大’。

四．参考文献：

<<数据库系统及应用>> 崔巍

<<数据库系统概论 >>

王珊

第三篇：数据库设计流程

数据库设计流程

目前数据库设计一般分为6个阶段，即需求分析阶段，概念结构设计阶段，逻辑结构设计阶段，物理结构设计阶段，实施阶段，运行与维护阶段。

(1)需求分析阶段

需求分析阶段的主要任务是指通过充分调查现实世界要处理的对象, 详细了解计算机系统的工作情况, 明确用户的各种需求, 然后确定系统的各项功能。数据库系统不仅要按照当前的应用要求来设计, 而且必须充分考虑今后可能的扩充和改变。

(2)概念结构设计阶段

概念结构设计阶段的主要任务是将需求分析阶段所得到的用户需求抽象为概念模型, 而描述概念模型的具体工具主要是E-R 模型。

(3)逻辑结构设计阶段

逻辑结构设计阶段的主要任务是把概念结构设计阶段设计的基本E-R 模型转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。具体来说, 就是首先将概念结构转换为一般的关系、网状、层次模型, 然后将转换来的模型向特定DBMS 支持下的数据模型转换, 最后对数据模型进行优化。

(4)物理结构设计阶段

物理结构设计阶段的主要任务是为一个指定的逻辑数据模型选取一个符合应用要求的物理结构。具体来说, 就是首先确定数据库的物理结构, 即数据库的存取方法和存储结构;然后对数据库的物理结构进行评估, 评估的重点是存取时间的长短和存储空间的大小。

(5)实施阶段

实施阶段的主要任务是用RDBMS 提供的数据定义语言和其他实用程序将逻辑结构设计和物理结构设计的结果详细描述出来, 成为DBMS 可以接受的源代码;再经过系统调试产生目标模式, 最后完成数据的载入工作。

(6)运行与维护阶段

运行与维护阶段的主要任务包括数据库的转储和恢复, 数据库完整性和安全性控制, 数据库性能改造、分析和监督, 数据库的重构造和重组织。

第四篇：数据库设计心得

数据库设计经验谈

数据库设计经验谈

一个成功的管理系统，是由：[50% 的业务 + 50% 的软件] 所组成，而 50% 的成功软件又有 [25% 的数据库 + 25% 的程序] 所组成，数据库设计的好坏是一个关键。如果把企业的数据比做生命所必需的血液，那么数据库的设计就是应用中最重要的一部分。有关数据库设计的材料汗牛充栋，大学学位课程里也有专门的讲述。不过，就如我们反复强调的那样，再好的老师也比不过经验的教诲。所以我归纳历年来所走的弯路及体会，并在网上找了些对数据库设计颇有造诣的专业人士给大家传授一些设计数据库的技巧和经验。精选了其中的 60 个最佳技巧，并把这些技巧编写成了本文，为了方便索引其内容划分为 5 个部分：

第 1 部分设计数据库表

总共 24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等。

第 3 部分保证数据完整性

讨论如何保持数据库的清晰和健壮，如何把有害数据降低到最小程度。

第 5 部分设计数据库之前 考察现有环境

在设计一个新数据库时，你不但应该仔细研究业务需求而且还要考察现有的系统。大多数数据库项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求的现有系统（可能没有实现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题。一般来说，考察现有系统对你绝对有好处。

定义标准的对象命名规范

一定要定义数据库对象的命名规范。对数据库表来说，从项目一开始就要确定表名是采用复数还是单数形式。此外还要给表的别名定义简单规则（比方说，如果表名是一个单词，别名就取单词的前 4 个字母；如果表名是两个单词，就各取两个单词的前两个字母组成 4 个字母长的别名；如果表的名字由 3 个单词组成，你不妨从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成 4 字母长的别名，其余依次类推）对工作用表来说，表名可以加上前缀 WORK_ 后面附上采用该表的应用程序的名字。表内的列[字段]要针对键采用一整套设计规则。比如，如果键是数字类型，你可以用 _N 作为后缀；如果是字符类型则可以采用 _C 后缀。对列[字段]名应该采用标准的前缀和后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个 _M 后缀。还有，日期列[字段]最好以 D_ 作为名字打头。

检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。假如你坚持统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。

如果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象（比如 tbl_Employees）。我在和 SQL Server 打交道的时候还用过 tbl 来索引表，但我用 sp_company（现在用 sp_feft_）标识存储过程，因为在有的时候如果我发现了更好的处理办法往往会保存好几个拷贝。我在实现 SQL Server 2000 时用 udf_（或者类似的标记）标识我编写的函数。

工欲善其事, 必先利其器

采用理想的数据库设计工具，比如：SyBase 公司的 PowerDesign，她支持 PB、VB、Delphe 等语言，通过 ODBC 可以连接市面上流行的 30 多个数据库，包括 dBase、FoxPro、VFP、SQL Server 等，今后有机会我将着重介绍 PowerDesign 的使用。

获取数据模式资源手册

正在寻求示例模式的人可以阅读《数据模式资源手册》一书，该书由 Len Silverston、W.H.Inmon 和 Kent Graziano 编写，是一本值得拥有的最佳数据建模图书。该书包括的章节涵盖多种数据领域，比如人员、机构和工作效能等。其他的你还可以参考：[1]萨师煊 王珊著 数据库系统概论(第二版)高等教育出版社 1991、[2][美] Steven M.Bobrowski 著 Oracle 7 与客户／服务器计算技术从入门到精通 刘建元等译 电子工业出版社，1996、[3]周中元 信息系统建模方法(下)电子与信息化 1999年第3期，1999 畅想未来，但不可忘了过去的教训

我发现询问用户如何看待未来需求变化非常有用。这样做可以达到两个目的：首先，你可以清楚地了解应用设计在哪个地方应该更具灵活性以及如何避免性能瓶颈；其次，你知道发生事先没有确定的需求变更时用户将和你一样感到吃惊。

一定要记住过去的经验教训！我们开发人员还应该通过分享自己的体会和经验互相帮助。即使用户认为他们再也不需要什么支持了，我们也应该对他们进行这方面的教育，我们都曾经面临过这样的时刻“当初要是这么做了该多好..”。

在物理实践之前进行逻辑设计

在深入物理设计之前要先进行逻辑设计。随着大量的 CASE 工具不断涌现出来，你的设计也可以达到相当高的逻辑水准，你通常可以从整体上更好地了解数据库设计所需要的方方面面。

了解你的业务

在你百分百地确定系统从客户角度满足其需求之前不要在你的 ER（实体关系）模式中加入哪怕一个数据表（怎么，你还没有模式？那请你参看技巧 9）。了解你的企业业务可以在以后的开发阶段节约大量的时间。一旦你明确了业务需求，你就可以自己做出许多决策了。

一旦你认为你已经明确了业务内容，你最好同客户进行一次系统的交流。采用客户的术语并且向他们解释你所想到的和你所听到的。同时还应该用可能、将会和必须等词汇表达出系统的关系基数。这样你就可以让你的客户纠正你自己的理解然后做好下一步的 ER 设计。

创建数据字典和 ER 图表

一定要花点时间创建 ER 图表和数据字典。其中至少应该包含每个字段的数据类型和在每个表内的主外键。创建 ER 图表和数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的。越早创建越能有助于避免今后面临的可能混乱，从而可以让任何了解数据库的人都明确如何从数据库中获得数据。

有一份诸如 ER 图表等最新文档其重要性如何强调都不过分，这对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对 SQL 表达式的文档化来说这是完全必要的。

创建模式

一张图表胜过千言万语：开发人员不仅要阅读和实现它，而且还要用它来帮助自己和用户对话。模式有助于提高协作效能，这样在先期的数据库设计中几乎不可能出现大的问题。模式不必弄的很复杂；甚至可以简单到手写在一张纸上就可以了。只是要保证其上的逻辑关系今后能产生效益。

从输入输出下手

在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。举个简单的例子：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。

报表技巧

要了解用户通常是如何报告数据的：批处理还是在线提交报表？时间间隔是每天、每周、每月、每个季度还是每年？如果需要的话还可以考虑创建总结表。系统生成的主键在报表中很难管理。用户在具有系统生成主键的表内用副键进行检索往往会返回许多重复数据。这样的检索性能比较低而且容易引起混乱。

理解客户需求

看起来这应该是显而易见的事，但需求就是来自客户（这里要从内部和外部客户的角度考虑）。不要依赖用户写下来的需求，真正的需求在客户的脑袋里。你要让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。一个不变的真理是：“只有我看见了我才知道我想要的是什么”必然会导致大量的返工，因为数据库没有达到客户从来没有写下来的需求标准。而更糟的是你对他们需求的解释只属于你自己，而且可能是完全错误的。

第 2 部分选择键和索引 数据采掘要预先计划

我所在的某一客户部门一度要处理 8 万多份联系方式，同时填写每个客户的必要数据（这绝对不是小活）。我从中还要确定出一组客户作为市场目标。当我从最开始设计表和字段的时候，我试图不在主索引里增加太多的字段以便加快数据库的运行速度。然后我意识到特定的组查询和信息采掘既不准确速度也不快。结果只好在主索引中重建而且合并了数据字段。我发现有一个指示计划相当关键——当我想创建系统类型查找时为什么要采用号码作为主索引字段呢？我可以用传真号码进行检索，但是它几乎就象系统类型一样对我来说并不重要。采用后者作为主字段，数据库更新后重新索引和检索就快多了。

可操作数据仓库（ODS）和数据仓库（DW）这两种环境下的数据索引是有差别的。在 DW 环境下，你要考虑销售部门是如何组织销售活动的。他们并不是数据库管理员，但是他们确定表内的键信息。这里设计人员或者数据库工作人员应该分析数据库结构从而确定出性能和正确输出之间的最佳条件。

使用系统生成的主键

这类同技巧 1，但我觉得有必要在这里重复提醒大家。假如你总是在设计数据库的时候采用系统生成的键作为主键，那么你实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。

采用系统生成键作为主键还有一个优点：当你拥有一致的键结构时，找到逻辑缺陷很容易。

分解字段用于索引

为了分离命名字段和包含字段以支持用户定义的报表，请考虑分解其他字段（甚至主键）为其组成要素以便用户可以对其进行索引。索引将加快 SQL 和报表生成器脚本的执行速度。比方说，我通常在必须使用 SQL LIKE 表达式的情况下创建报表，因为 case number 字段无法分解为 year、serial number、case type 和 defendant code 等要素。性能也会变坏。假如和类型字段可以分解为索引字段那么这些报表运行起来就会快多了。

键设计 4 原则

* 为关联字段创建外键。* 所有的键都必须唯一。* 避免使用复合键。

* 外键总是关联唯一的键字段。

别忘了索引

索引是从数据库中获取数据的最高效方式之一。95% 的数据库性能问题都可以采用索引技术得到解决。作为一条规则，我通常对逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列[字段]采用非成组索引。不过，索引就象是盐，太多了菜就咸了。你得考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。

大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。还有，不要索引 memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。

不要索引常用的小型表

不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。

不要把社会保障号码（SSN）或身份证号码（ID）选作键

永远都不要使用 SSN 或 ID 作为数据库的键。除了隐私原因以外，须知政府越来越趋向于不准许把 SSN 或 ID 用作除收入相关以外的其他目的，SSN 或 ID 需要手工输入。永远不要使用手工输入的键作为主键，因为一旦你输入错误，你唯一能做的就是删除整个记录然后从头开始。

我在破解他人的程序时候，我看到很多人把 SSN 或 ID 还曾被用做系列号，当然尽管这么做是非法的。而且人们也都知道这是非法的，但他们已经习惯了。后来，随着盗取身份犯罪案件的增加，我现在的同行正痛苦地从一大摊子数据中把 SSN 或 ID 删除。

不要用用户的键

在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。这样做会迫使你采取以下两个措施：

* 在创建记录之后对用户编辑字段的行为施加限制。假如你这么做了，你可能会发现你的应用程序在商务需求突然发生变化，而用户需要编辑那些不可编辑的字段时缺乏足够的灵活性。当用户在输入数据之后直到保存记录才发现系统出了问题他们该怎么想？删除重建？假如记录不可重建是否让用户走开？

* 提出一些检测和纠正键冲突的方法。通常，费点精力也就搞定了，但是从性能上来看这样做的代价就比较大了。还有，键的纠正可能会迫使你突破你的数据和商业/用户界面层之间的隔离。

所以还是重提一句老话：你的设计要适应用户而不是让用户来适应你的设计。

不让主键具有可更新性的原因是在关系模式下，主键实现了不同表之间的关联。比如，Customer 表有一个主键 CustomerID，而客户的定单则存放在另一个表里。Order 表的主键可能是 OrderNo 或者 OrderNo、CustomerID 和日期的组合。不管你选择哪种键设置，你都需要在 Order 表中存放 CustomerID 来保证你可以给下定单的用户找到其定单记录。

假如你在 Customer 表里修改了 CustomerID，那么你必须找出 Order 表中的所有相关记录对其进行修改。否则，有些定单就会不属于任何客户——数据库的完整性就算完蛋了。如果索引完整性规则施加到表一级，那么在不编写大量代码和附加删除记录的情况下几乎不可能改变某一条记录的键和数据库内所有关联的记录。而这一过程往往错误丛生所以应该尽量避免。

可选键(候选键)有时可做主键

记住，查询数据的不是机器而是人。假如你有可选键，你可能进一步把它用做主键。那样的话，你就拥有了建立强大索引的能力。这样可以阻止使用数据库的人不得不连接数据库从而恰当的过滤数据。在严格控制域表的数据库上，这种负载是比较醒目的。如果可选键真正有用，那就是达到了主键的水准。

我的看法是，假如你有可选键，比如国家表内的 state_code，你不要在现有不能变动的唯一键上创建后续的键。你要做的无非是创建毫无价值的数据。如你因为过度使用表的后续键[别名]建立这种表的关联，操作负载真得需要考虑一下了。

别忘了外键

大多数数据库索引自动创建的主键字段。但别忘了索引外键字段，它们在你想查询主表中的记录及其关联记录时每次都会用到。还有，不要索引 memo/notes 字段而且不要索引大型文本字段（许多字符），这样做会让你的索引占据大量的数据库空间。

第 4 部分各种小技巧 文档、文档、文档

对所有的快捷方式、命名规范、限制和函数都要编制文档。

采用给表、列[字段]、触发器等加注释的数据库工具。是的，这有点费事，但从长远来看，这样做对开发、支持和跟踪修改非常有用。

取决于你使用的数据库系统，可能有一些软件会给你一些供你很快上手的文档。你可能希望先开始在说，然后获得越来越多的细节。或者你可能希望周期性的预排，在输入新数据同时随着你的进展对每一部分细节化。不管你选择哪种方式，总要对你的数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当你过了一年多时间后再回过头来做第 2 个版本，你犯错的机会将大大减少。

使用常用英语（或者其他任何语言）而不要使用编码

为什么我们经常采用编码（比如 9935A 可能是„青岛啤酒‟的供应代码，4XF788-Q 可能是帐目编码）？理由很多。但是用户通常都用英语进行思考而不是编码。工作 5 年的会计或许知道 4XF788-Q 是什么东西，但新来的可就不一定了。在创建下拉菜单、列表、报表时最好按照英语名排序。假如你需要编码，那你可以在编码旁附上用户知道的英语。

保存常用信息

让一个表专门存放一般数据库信息非常有用。我常在这个表里存放数据库当前版本、最近检查/修复（对 FoxPro）、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。

测试、测试、反复测试

建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证你选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。

检查设计

在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。

Microsoft Visual FoxPro 设计技巧

对复杂的 Microsoft Visual FoxPro 数据库应用程序而言，可以把所有的主表放在一个数据库容器文件里，然后增加其他数据库表文件和装载同原有数据库有关的特殊文件。根据需要用这些文件连接到主文件中的主表。比如数据输入、数据索引、统计分析、向管理层或者政府部门提供报表以及各类只读查询等。这一措施简化了用户和组权限的分配，而且有利于应用程序函数（存储过程）的分组和划分，从而在程序必须修改的时候易于管理。

第五篇：数据库设计原则

4.3.1数据库设计原则

数据库设计的基本原则是在系统总体信息方案的指导下，各个库应当为它所支持的管理目标服务，在设计数据库系统时，应当重点考虑以下几个因素:

1、数据库必须层次分明，布局合理。

2、数据库必须高度结构化，保证数据的结构化，规范化和标准化，这是建立数据库和进行信息交换的基础。数据结构的设计应该遵循国家标准和行业标准，尤其要重视编码的应用。

3、在设计数据库的时候，一方而要尽可能地减小冗余度，减小存储空间的占用，降低数据一致性问题发生的可能性，另一方面，还要考虑适当的冗余，以提高运行速度和降低开发难度。

4、必须维护数据的正确性和一致性。在系统中，多个用户共享数据库，由于并发操作，可能影响数据的一致性。因此必须用“锁”等办法保证数据的一致性。

5、设定相应的安全机制，由于数据库的信息、对特定的用户有特定的保密要求，安全机制必不可少。