数据库设计精选(九篇)

前言：一篇好文章的诞生，需要你不断地搜集资料、整理思路，本站小编为你收集了丰富的数据库设计主题范文，仅供参考，欢迎阅读并收藏。

第1篇：数据库设计范文

1.1灾情信息表

对灾情数据进行信息分类是一项非常重要的过程，适当的分类可以简化系统结构，实现数据的精确分析。具体来说，灾情数据分为两部分，一部分是过程信息表，一部分是灾情信息表。其中，过程信息表用来记录灾害天气发生过程中的灾害信息，这部分记录是灾情数据库的基础；灾情信息表是受灾后的灾情详细信息记录，如灾害强度、灾害损失、灾害原因等。两部分在数据使用方面体现为一对多关系，即一次灾害过程对应着多个灾情信息记录。灾情信息表是整个数据库系统的核心，其结构是否科学合理决定了后续灾情分析的准确程度。为满足分析需求，通常灾情详细信息表的数据存储字段可分为灾情起因信息、基本信息、空间属性信息、灾害带来的损失信息、后期影响信息等几部分。

1.2灾情的协同通报信息结构

数据库的建立不仅仅用于记录，还应该具有联网通报的功能，通过该功能可以实现信息的联网分析和总结，提高灾情通报的实时性和系统使用效率，减少或者避免重复工作所带来的人力资源浪费。该部分数据库架构为，在灾情协同录入界面，辅助录入人员可以将灾情数据进行及时收集整理后进行录入，然后利用协同通报系统将信息上传到数据库端并将该部分数据标记为待审核数据。经过工作人员的审核和评定后，若该数据录入准确且具有唯一性，则取消待审核状态，转为灾情详细信息数据，为后续上报或者灾情分析评估等提供数据支持。该部分的信息需要进行单独存放，以免与灾情信息表产生混淆。

1.3灾情评估信息数据结构

灾情根据灾害特点和灾害原因可以分为多种类别，如自然灾害和人为灾害、地质灾害和天气灾害等。不同的灾害收集方式和评估方式均有所不同，因此在数据库架构中如何合理制定灾害信息采集分析表对应用灾害数据进行灾情评估具有重要作用。该部分数据库应该按照如下方式进行构建。首先建立灾情分类数据库，不同灾情与对应灾情描述之间进行特征关联，同类型灾害进行细分和归类。然后根据灾情特征建立对应的数据模型，便于数据录入和灾害评估。

1.4辅助数据表结构

为提高系统的应用性能，可以增设部分辅助数据表作为灾情数据库的补充。利用该表可以进行新灾情的自定义等，增强数据库的可扩展性。同样辅助表还具有区域记录功能，通过对受灾区域进行记录，可以提高灾情地理分布的精确度，增强局部预警能力。

2基于灾情数据库的灾害评估技术分析

在建立气象灾情信息数据库的基础上结合使用GIS技术、数据分析技术、WEB技术等，可以保证对数据库的充分利用，实现灾情的精确评估，减少灾害带来的经济损失。

2.1灾情统计分析技术

对灾情进行记录的主要目的在于利用这些数据进行统计分析，并对分析结果进行总结，生成统计报表，根据报表制定防灾决策，或者指导今后的灾情预警等。该技术生成的统计报表可以用于存储或检索。其中，检索功能可以进行要素关联检索、条件检索、影响检索等。通过进行细分检索和信息对比，可以方便的实现灾害评估。

2.2可视化分布图显示技术

在对灾害数据库进行限定检索后，可以获得相关灾情信息和气象数据。结合使用可视化技术等，可以根据数据统计量生成要素分布图。如灾情分布图、灾害损失分布图等。这些分布图可以直观、便捷的实现天气和灾情的关联，突出灾害易发点，为不同天气下的灾害预防工作提供理论依据。

2.3灾害防御对策技术

灾害防御对策技术主要是指对数据库内的灾害数据进行分析，根据各要素的影响程度调用对应的防御对策信息以供气象工作人员参考。该技术的实现需要对现有的应对策略进行收集、整理和归类，并根据灾害程度制作成相应的数据库文件，进而将该数据库与灾害信息库进行关联。

3总结

第2篇：数据库设计范文

关键词：网络安全 漏洞 数据库

1 信息安全库所面临的挑战

信息技术的发展带动了全球信息化的发展，从而使信息基础设施成为社会基础设施中必不可少的关键所在。信息网络技术的应用正日益普及和广泛，应用领域也从传统的、小型业务系统逐渐向大型、关键业务系统扩展，典型的如企事业单位信息系统、金融业务系统、企业商务系统等。伴随网络的普及，安全日益成为影响网络效能的重要问题，而Internet所具有的开放性、国际性和自由性在增加应用自由度的同时，对安全提出了更高的要求，这主要表现在：

1.1 开放性导致网络的技术是全开放的，任何一个人、团体都可能获得，因而网络所面临的破坏和攻击可能是多方面的，例如：可能来自物理传输线路的攻击，也可以对网络通信协议和实现实施攻击；可以是对软件实施攻击，也可以对硬件实施攻击。

1.2 国际性意味着网络的攻击不仅仅来自本地网络的用户，它可以来自Internet上的任何一个机器，也就是说，网络安全所面临的是一个国际化的挑战。

1.3 自由性意味着网络最初对用户的使用并没有提供任何的技术约束，用户可以自由地访问网络，自由地使用和各种类型的信息。

与此同时，层出不穷的病毒、蠕虫和黑客攻击给正常的网络通信与信息资源带来沉重的负荷和影响。

如近几年来在全球肆虐的Code Red，Slammer，W32. Blaster等蠕虫病毒，除了对受害站点进行DDos攻击外，大量非正常数据包的泛洪还严重占用网络带宽，堵塞网络，并使大量服务器工作异常，具有很强的危害性。

2 安全信息数据库的设计

该子库主要存储来自于信息侦察所收集到的并支持人工修正的目标网络的基本信息。其中，包含有配置信息表（CInfo）、服务信息表（SInfo）、漏洞信息表（VInfo）和安全依赖关系表(SDR)。

CInfo表的键是主机IP地址属性；SInfo表的键是（主机IP地址、主机端口）；VInfo表的键是(主机IP地址、主机漏洞ID)；SDR表的键是(可能源主机IP，可能目的主机IP，主机漏洞ID)。CInfo与SInfo是一对多的关系，因为每台主机可同时开放多个端口；CInfo与VInfo是一对多的关系，每个节点可能有多个漏洞；SInfo与VInfo也是一对多的关系，每个运行服务可能存在多个漏洞。CInfo与SDR，VInfo与SDR均是一对多的关系。

3 标准漏洞子库设计

该子库由漏洞信息表（VulInfo）和漏洞影响系统信息表（VulSys）组成。前者主要记录了每个漏洞的BugID、/更新时间、漏洞类别、具体描述、修复方法等等；后者记录了每条漏洞所影响的操作系统或应用软件信息。

VulInfo表和VulSys的键值均是漏洞ID属性，它们之间是一对多的关系，因为同一个漏洞可能影响多个系统。

在VulInfo表中，我们使用Bugtraq作为标识漏洞的唯一ID，是因为Bugtraq ID即将成为业界的统一标准，各个软件供应商也已开始将自己的产品漏洞公告映射为Bugtraq编号，该编号提供了一个统一、一致、可比较的漏洞管理机制。

由于这两个组织的漏洞数据库都不提供直接的访问，因此设计一个漏洞数据获取插件。

根据各个漏洞信息的URL开启多个线程，发送相应的HTTP GET请求，然后读取Web Server端的响应。由于漏洞数量相当多，如果由每个线程同时完成读取响应，分析数据并填写数据库，不但会消耗大量的系统资源，而且很可能导致大量GET请求失败。因此，我们采取了实时线程获取原始漏洞数据并以简单的格式存储，然后主线程进行离线的数据分析，并完成写入数据库的任务。另外，由于可能存在GET请求失效的情况，将导致某些漏洞的信息缺失或不完整。为了保证得到所有已有漏洞的信息，我们还采取了日志记录机制，即，主线程开启一批线程抓取信息并等待其全部结束后，根据每个线程录入的日志找出需要重新抓取的漏洞，重新开启一批线程，如此反复，直到所有漏洞数据都被成功获取。

由于目前实际情况的限制，只能在国际安全组织站点上被动的更新漏洞库。如果可以建立国内统一的紧急相应中心漏洞数据库，那么中心可以定期的向各个网络风险评估管理系统的标准漏洞子库漏洞更新数据。

可见，执行相应的风险控制措施，使风险等级降低到可接受的水平。

参考文献：

[1]Information Assurance Technical Framework. IATF Document [EB/OL].Release 3.1.

[2]National Computer Security Center，Department of Defense Trusted Computer System Evaluation Criteria，DoD 5200.28-STD，December 1985

[3]David Moore，Vern Paxson，Stefan Savage etc. The Spread of the Sapphire/Slammer Worm[EB/OL].2003.

第3篇：数据库设计范文

数据库建设项目技术设计书

**市**测绘服务有限责任公司

2011年11月10日

**县**镇地籍调查

数据库建设项目技术设计书

项目承担单位（盖章）：**市**测绘服务有限责任公司

设计人：

日期： 年 月 日

审批人：

审批单位（盖章）：**县国土资源局

日期： 年 月 日

目 录

1. 项目概况 ............................................. 1

1.1 前言 ............................................ 1

1.2 工作任务 ........................................ 1

1.3 完成期限 ........................................ 1

2. 技术依据 ............................................. 1

3 入库数据主要技术指标 .................................. 2

4 城镇地籍数据库建设 .................................... 2

4.1 数据库建立的流程 ................................ 3

4.2 数据库内容 ...................................... 3

4.3 数据库信息 ...................................... 4

4.4 数据建库的主要工作内容 .......................... 4

4.5 数据建库要求 .................................... 5

4.6 数据检查 ........................................ 6

4.7 注意事项 ........................................ 6

5. 质量监督与保密措施 ................................... 7

5.1 质量检查制度 .................................... 7

5.2 检查的内容 ...................................... 7

5.3 检查工作的实施 .................................. 8

5.4 成果保密措施 .................................... 8

6 成果提交 .............................................. 9

1. 项目概况

1.1 前言

**县国土资源局按照国务院《关于开展第二次全国土地调查的通知》（国发[2006]38号）及2010年**市政府与**县政府签订的岗位目标责任制的要求，全面开展**县建制镇的地籍调查工作，为查清**县城镇土地利用状况，掌握真实的土地基础数据，建立和完善土地调查、统计和登记制度，实现土地资源信息的社会化服务，将全野外数字化地籍成果数据进行入库，满足经济建设及国土资源管理的需要，更好的为土地宏观调控及政府科学决策提供依据。**县国土资源局委托我公司承担此次**镇（镇区及高家屯、王三家子、半拉窝铺）的地籍调查工作。

1.2 工作任务

本项目是第二次土地调查的重要内容之一，也是合理利用土地资源、充分发挥土地资产效益、保护土地权利人合法权益、实施科学化的城市管理和建设“数字国土”、“数字**”的基本条件；工作任务是在完成**镇地籍调查中的权属调查、地籍测量后，建立地籍数据库。

1.3 完成期限

计划在2011年11月10日至2012年2月10日完成整个测区的数据入库工作。

2. 技术依据

《第二次全国土地调查技术规程》（TD/T 1014-2007）；

《城镇地籍调查规程》（TD 1001-93）；

《城镇地籍测量技术规定》（暂行）（吉林省第二次土地调查标准）；

《土地利用现状分类》（GB/T 21010-2007）；

《1∶500 1∶1000 1∶2000地形图图式》（GB/T 20257.1-2007）； 《城镇地籍数据库标准》（TD/T 1015-2007）；

《第二次全国土地调查数据库建设技术规范》；

《基础地理信息要素分类与代码》（GB/T13923-2006）；

《中华人民共和国行政区划代码》（GB/T2260-2007）；

《测绘成果质量检查与验收》（GB/T24356-2009）；

《吉林省城镇土地调查检查验收规定》（暂行）；

经审核的《**县**镇地籍调查数据库建设项目技术设计书》。 3 入库数据主要技术指标

坐标系统：1980西安坐标系；

高程基准：1985国家高程基准；

成图比例尺：1:500；

平面投影：高斯－克吕格正形投影3度带,中央子午线126度 计量单位：长度单位采用米（m），取位至0.01m；面积计算单位采用平方米（m2），取位至0.01 m2；面积统计汇总单位采用平方米（m2），取位至0.01 m2 。

4 城镇地籍数据库建设

城镇地籍调查数据库是指在地籍调查过程中形成的调查成果数

据库，是数字地籍调查的最终成果，也是地籍管理信息系统的基础数据源。

4.1 数据库建立的流程

4.2 数据库内容

城镇地籍数据库包括城镇地籍数据处理、管理和分析应用的基础地理要素、权属要素、地类要素、注记要素、土地权利人要素、土地登记要素，以及房屋等附加信息。

4.3 数据库信息

4.3.1 数据上交格式

地籍测量生产和地籍数据库输出的图形文件可采用如下方式：

4.3.1.1.支持ESRI的SHP格式。每个图层对应一个SHP文件，相关属性记录在SHP文件中，扩展属性表以.DBF表示，元数据支持文本(.txt)。SHP文件命名以对应属性表命名(参见《城镇地籍数据库标准》（TD/T1015-2007）表1)，以区块文件输出。

4.3.1.2.支持国土资源部规定的VCT数据格式。

4.3.2 系统平台

外业数据采集满足《城镇地籍数据库标准》（TD/T1015-2007）要求；

内业数据建库采用城镇地籍建库管理软件（CMS）。

4.4 数据建库的主要工作内容

以1：500城镇土地调查图形成果为数据源，采用电子数据的抽取、转换、装载（ETL）工艺或辅助屏幕数字化工艺，建立满足一定拓扑规则的城镇土地调查图形数据库；以城镇土地权属调查、登记发证和建设用地审批的非图形资料为数据源，建立城镇土地调查属性数据库；为保持图形数据和属性数据的逻辑一致性，并将两者相互挂接为城镇土地调查数据库。

对地籍测量采集的空间矢量数据（包括地形、地籍数据）按照要求进行分层、编辑等处理。

4.4.1.对数据进行相对关系、拓扑关系等处理，按照规定的面层，对每一个面层按照拓扑关系进行构面处理，如区划，街道、街区、宗地（地块）、地类等层。

4.4.2.属性录入，对于外业采集软件中不能录入或不能转入的各种属性数据，按照规定进行录入及链接。

4.4.3.在系统平台上进行统计、面积汇总检核及成果输出等。

4.5 数据建库要求

4.5.1 矢量数据

对于内业构面，按照一级控制一级的原则，在街坊层，同一街道内所有的街坊构成具有严格拓扑关系的各个面，面积之和应等于此街道的面积；在宗地层，所有的宗地构成具有严格的拓扑关系，宗地面积与虚宗面积之和应等于此街坊的面积；在图斑层，同一宗地内不同地类以宗地界线构成的面具有严格的拓扑关系，且面积之和等于该宗地面积。

4.5.2 编码

全部数据按《城镇地籍数据库标准》（TD/T 1015-2007）城镇地籍要素的编码规则进行编码。

4.5.3 属性数据的录入

根据《城镇地籍数据库标准》（TD/T 1015-2007）城镇地籍要素属性表的结构对除宗地外所有要素进行属性录入。

4.5.4 面积统计和汇总

4.5.4.1.面积统计的有关规定

(1)按街坊街道逐级汇总；

(2)各类面积统计要独立量算两次，面积单位m²,计算取值到小数后一位。

土地分类均用二级类填写；

(3)所有面积以地籍信息系统汇总的面积为准。

4.5.4.2.面积汇总

在完成街坊面积量算后，按街坊对宗地进行面积汇总统计。街坊汇总统计结束后，进行以街道为单位宗地面积汇总统计。当一个街道涉及两个以上作业组时，街坊宗地汇总数据交由一个作业组完成。输出面积资料有：

(1)街坊为单位的界址点坐标册；

(2)街坊宗地面积汇总表；

(3)街道土地分类面积统计表,按《土地利用现状分类》（GB/T21010-2007）和《城镇地籍数据库标准》（TD/T1015-2007）规定的地类号填写。

4.6 数据检查

4.6.1.属性录入检查，及时发现权属调查的错误、属性录入错误。

4.6.2.地籍分幅图数据的接边检查：检查接边情况、图形数据和母线数据的一致性。

4.6.3.图形数据中界址点的数量、位置与地籍调查表的界址点的数量、位置一致性的检查。

4.7 注意事项

4.7.1.地籍调查各项成果的矢量数据质量是否满足标准要求将直接影响到项目后续的数据入库，因此在矢量数据入库前，应按照GIS前端数据采集要求开展数据生产与编辑，从图形规范、属性编码、空间拓扑等方面进行控制，做到面向对象，图属一致；对象的分层、分类、编码按照国家《城镇地籍数据库标准》的空间数据库标准执行；制定相应的地籍要素采集、编辑规则，以规范数据生产。

4.7.2.在数据库中，图形与主要属性用同一张表中的同一条记录来描述，其他相关的属性通过图属关联实现图属一体化。

5. 质量监督与保密措施

质量监督与检查制度的确立是确保项目质量的关键。

5.1 质量检查制度

按照《测绘成果质量检查与验收》（GB/T24356-2009）的规定，为确保成果质量符合设计要求，该调查区地籍调查成果，严格执行各项技术、质量管理制度，在项目实施过程中，认真按照ISO9001：2000质量保证体系的要求开展工作。

5.2 检查的内容

使用城镇地籍建库管理软件（CMS）检查功能对数据库的拓扑和属性以及地籍调查表数据有效性进行检查。

5.2.1．拓扑检查

5.2.1.1行政区：面不能重叠；面不能有空隙；面边界被线层覆盖（行政区界线）；A面层被B面层覆盖（地类图斑）。

5.2.1.2行政区界线：线不能有悬挂点；线不许相交或重叠。

5.2.1.3宗地：面不能重叠；面不能有空隙；面边界被线层覆盖（界址线）；A面完全包含于B面内（行政区）。

5.2.1.4界址线：线不能有悬挂点；线不许相交或重叠；线终点与点重合（界址点）。

5.2.1.5界址点：点与线终点重合（界址线）

5.2.1.6地类图斑：面不能重叠；面不能有空隙；面边界被线层覆盖（地类界线）。

5.2.1.7地类界线：线不能有悬挂点；线不许相交或重叠。

5.2.1.8房屋：A面完全包含于B面内（宗地）。

5.2.2．属性检查：对所有地籍要素的属性进行检查。

5.2.3．标识码唯一性检查：检查数据库内各要素标识码是否唯一。

5.2.4.调查表数据检查

5.2.4.1地籍调查表主表检查：检查地籍调查表中字段值填写的正确性。

5.2.4.2指界表检查：检查指界表中本宗指界人与邻宗指界人填写的正确性。

5.2.4.3界址标示表检查：检查界址标示表中相邻宗地的界址线位置，界址线类别，界址点类型，界标类型填写是否矛盾。

5.2.4.4调查表宗地四至检查：对调查表宗地四至与邻宗权利人一致性进行检查。

5.3 检查工作的实施

专人利用城镇地籍建库管理软件（CMS）检查功能对数据库进行复查，以及参照外野权属资料与数据库进行对照检查。

5.4 成果保密措施

5.4.1.严格执行测绘资料管理办法，做好测绘资料的保密管理，加强知识产权保护法和职业道德教育，杜绝资料泄密或遗失。

5.4.2.在整个生产过程中，有关该项目的测绘成果要做好造册登记，严格管理。

5.4.3.未经甲方单位同意，测绘单位不得擅自向第三方提供任何该项目的测绘资料。

5.4.4.在生产作业现场使用的计算机网络要与外界的计算机互联网保持物理隔绝。

5.4.5.做好计算机防病毒工作，所有生产用的计算机要安装反病毒软件。

5.4.6.做好计算机的使用维护管理工作，对各计算机建立统一的标识、统一的文件系统、统一的文件格式。不用的或废弃的文件要进行清理，在工作的文件系统内保持数据的唯一性。

5.4.7.防止电子数据成果的意外损坏和丢失，坚持在每天工作结束后对该项目的所有电子数据成果进行备份，并作好备份记录。备份数据保存在专用计算机内。

5.4.8.对生产过程中形成的中间资料（不上交）在项目完成时应统一在监督下销毁，不允许随意丢弃。

第4篇：数据库设计范文

关键词：企业信息收集工作；数据库设计；信息化

中图分类号：TP311.13 文献标识码：A 文章编号：1007-9599 (2012) 12-0000-02

一、数据库设计工作的规范化在企业信息收集工作中的意义

数据收集的高质化以及数据收集的高效化是企业信息收集工作的要求，也是数据库设计的目的。企业信息收集工作是企业跟上时代进程，保有一定市场竞争力的前提，是企业发展历程中的一个重要组成部分，是企业满足现今社会信息化要求的基础工程。数据库设计工作的是否成功，是直接影响着企业信息化建设的进程的。

在我国现代化进程不断加快的今天，我国的信息化产业也得到了空前的发展空间。尤其对于企业信息收集工作来说，企业信息收集工作的发展已经成为了企业信息化建设历程中的一个重要组成部分了，其所独具的信息化特质更直接奠定了其对企业的巨大影响。企业想要从根本上实现信息化建设的目标，就必须倚靠企业信息收集工作的发展。企业信息收集工作对于企业创造效益的效率、企业的信息化建设等等等等都有着极为深远的影响。数据库设计工作的质量更是直接引导着企业信息化建设的步伐的，只有保证了数据库设计工作的质量，才能够真正地让企业信息化建设的各项工作有其意义，才能够真正地体现出企业信息收集工作的信息化特质。

然而，近几年来，有关企业信息收集工作质量的问题频频曝光，在没有突显其应有的效益的同时更直接影响了企业的正常运作，严重地阻碍了企业信息化建设的进程。这往往都是因为数据库设计工作中设计人员的能力不足、设计人员的不重视等因素所导致的。

企业的数据库设计工作的开展原本是为了让企业信息收集工作更为及时地为企业的各项工作数据提供更为便利的搜索途径，但这却也加大了数据库设计工作开展的难度，让企业的管理人员在处理企业信息收集工作与企业信息化建设工作之间的关系的时候往往不够合理、不够正确。

如何在最短的时间内给以企业最大的方便是每一个数据库设计人员都应考虑到的问题，这归根到底，就是如何正确地协调好企业信息收集工作与企业信息化建设工作之间的关系的问题。企业信息收集工作是具有整体性的一项工作，其中每一项工作、每一项要求都是紧密相连、密不可分的。一个企业管理人员只有在真正能够正确、有效、合理地协调好企业信息收集工作与企业信息化建设工作之间的关系的时候，数据库设计工作的质量才能够真正地达到加快企业群信息化建设的目的。

而企业管理人员要想能够协调好企业信息收集工作与企业信息化建设工作这两者之间的关系，就必须通过数据库设计工作的规范化来完成。数据库设计工作是企业信息化建设中不可或缺的一个部分，对于企业信息收集工作来说，更是其突显智能化、高效化的一项重要举措，甚至可以说其是企业信息收集工作与企业信息化建设工作之间的一道桥梁。

数据库设计工作是贯通着企业信息收集工作中每一个阶段、每一项工作的一项工作，是主导着企业开展信息收集工作的方向与进度、决定着企业开展信息收集工作的性质的一个决策性工作，是企业管理人员协调好企业信息收集工作与企业信息化建设工作之间的关系的一个重要途径。只有做好了数据库设计的规范化工作，企业信息收集工作的智能化、高效化才能够得以彰显，企业信息收集工作与企业信息化建设才能够充分地满足企业的要求、市场的要求。

二、设计主要过程

（一）概念结构设计阶段

1.第零步——初始化工程

这个阶段的任务是从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果，业务流程，原有系统的输入输出，各种报表，收集原始数据，形成了基本数据资料表。

2.第一步——定义实体

实体集成员都有一个共同的特征和属性集，可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有“代码”结尾的术语，如客户代码、商代码、产品代码等将其名词部分代表的实体标识出来，从而初步找出潜在的实体，形成初步实体表。

3.第二步——定义联系

IDEF1X模型中只允许二元联系，n元联系必须定义为n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系（强制的或可选的）还是非确定关系、分类关系。

4.第三步——定义码

通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选码属性，以便唯一识别每个实体的实例，再从侯选码中确定主码。为了确定主码和关系的有效性，应通过非空规则和非多值规则来保证。

第5篇：数据库设计范文

关键字：数据泵；顺序；细节处理

中图分类号：TP311.1

近年来，由于服务器平台更新换代较快，原来在设备型号较陈旧的一些数据库平台需要移植到性能较高的其它平台，数据库移植也就有了较多需求。关于数据库移植，现已有很多方法和经验介绍，有针对全库的rman移植，也有针对个别对象的数据泵移植。笔者由于工作需要，将两个数据库以最快的方式移植到较高的Linux平台，其中数据采用可传输性表空间的方法进行移植，其它对象采用数据泵不同功能选项进行移植。

1 两个数据库平台介绍

源库：windows2003 oracle；版本：10.2.0.5.0；字节顺序：little（字节顺序一致很重要，省了转换的麻烦）。

目标库：windows2003 oracle；版本：10.2.0.5.7；字节顺序：little（Select * from V$TRANSPORTABLE_PLATFORM ORDER BY PLATFORM_ID；）。

确认字节顺序一致很重要，省了转换的麻烦，不在此赘述。

数据库移植思路：根据源和目的两个表空间的特点，采用传输性表空间移植的方式，先对表空间DB01_A和DB01_B进行移植，存储过程、函数、视图、db-link连接使用数据泵分类按序移植。

2 移植步骤

2.1 移植前的准备检查

（1）首先对源表空间的自包含集进行检查、清理。即需要移植的表空间不得包含依赖性的非本表空间的对象建立的关系。

Exec dbms_tts.transport_set_check（‘DB01_A’，TRUE，TRUE）；

Select * from TRANSPORT_SET_VIOLATIONS；

Exec dbms_tts.transport_set_check（‘DB01_B’，TRUE，TRUE）；

Select * from TRANSPORT_SET_VIOLATIONS；

对DB01_A和DB01_B不符合检查标准的索引等对象删除、清理。

（2）源、目的库的用户要创建一致。参考源数据库在目标库建立了所有的普通用户。移植后的用户属性、权限及默认表空间待移植后重新赋权。执行expdp的用户要赋予exp_full_database的角色。

（3）目的库的移植元文件使用目录确认。

元文件放到目标库DATA_PUMP_DIR参数指定的地方，具体确定方法为：

Select * from dba_directories；DATA_PUMP_DIR一般是默认的目录，路径过长。笔者新建一个目录，并指定其为导入/出目录。在系统跟即/目录下创建yizhi，在sqlplus里制定/yizhi为导入导出目录。

create or replace directory directory_name as ‘/yizhi’；

grant read，write on directory directory_name to system

如果使用其它普通用户导入，还需赋予创建对话的权限；

Grant create session to username；

2.2 正式移植

（1）源库关闭所有应用、连接、计划任务，关闭监听程序。在关闭监听的情况下，在sqlplus里修改数据库的属性，read only。必须将数据库的属性修改为read only，数据库元数据才能导出。上述举措为了保持移植数据一致性。

alter tablespace DB01_A read only；

alter tablespace DB01_B read only；

（2）导出元数据，指定可传输表空间参数TRANSPORT_TABLESPACES

expdp ‘sys/xxx@db01 as sysdba’ dumpfile= DB01_A.DMP directory=DATA_PUMP_DIR TRANSPORT_TABLESPACES=DB01_A；

expdp ‘sys/xxx@db01 as sysdba’ dumpfile= DB01_B.DMP directory=DATA_PUMP_DIR TRANSPORT_TABLESPACES=DB01_B；

经实战移植验证，550G的表空间DB01_A 导出成80M的元文件需4分钟，80G的表空间DB01_B导出 70M的元文件需3分钟。

（3）分类导出其它。

expdp system/super dumpfile=view.dmp directory=DATA_PUMP_DIR logfile=job.log full=Y include= VIEW（要注意加full=Y）

然后将参数VIEW分别改为FUCTION，DB_LINK，PROCEDURE

（4）传输元文件及物理数据文件。通过FTP或工具传输元文件及数据文件。这一步骤提前要安排好物理文件的存放及目的存放规划。

（5）按顺序导入表空间、视图、db_link、存储过程、JOB。这一步分类和顺序很重要，因为对象之间有相互的依赖关系。比如有的存储过程里用到db_link链接，db_link如果未先建好，就会导致存储过程导入的失败。

Impdp system/oracle01 dumpfile=DB01_A.DMP directory=DIRECTORY_NAME

TRANSPORT_DATAFILES= /Ora_da1/DB01_A.ORA，……. /Ora_da1/DB01_A32.ORA

impdp system/oracle dumpfile=DB01_B.DMP directory=DIRECTORY_NAME

TRANSPORT_DATAFILES= /Ora_da1/DB01_B.ORA，……/Ora_da1/DB01_B7.ORA

表空间导入完成，打开表空间的可读写属性（因为后续导入的对象要用到数据表的读写）

alter tablespace DB01_A read write；alter tablespace DB01_B read write；

修改数据文件的文件属主。chown oracle：oinstall 数据文件列表。然后检查导入表空间的物理文件及逻辑文件状态及可用性。

（6）分类按序移植具体主要为存储过程，函数、视图。此步骤并不是针对用户来移植的，而是针对全部对象进行的移植。

impdp system/super dumpfile=all.dmp directory=DIRECTORY_NAME include= VIEW

然后同上，将db_link， Function，PROCEDURE，JOB等指定为include参数值进行导入。至此，数据库所有应用对象移植完毕，可以在新创建的数据库环境空间里继续分享源数据库空间的数据及用户方案。

3 采用传输性表空间的方法移植数据库的特点及总结

通常采用传输性表空间的数据方法移植数据表空间的。本次采用expdp分别将数据库各数据对象移至目标平台。关键点在参数、顺序、细节的处理。数据库同步的几个关键点：

（1）修改用户权限。在表空间移植前，将原数据库所有用户在新目标库创建。待表空间、VIEW、function等移植后，就参照原数据库用户创建脚本将新库数据库用户权限全部更新一遍。笔者采用利用源DDL脚本的方法赋权。（2）分类按序。当导入发现有错误提示时，不要担心，看一下提示便可了解逻辑关系，调整一下导入顺序，问题便迎刃而解。（3）移植点和时间的把握。最初采用此方法，是因源库没有基于rman的数据库备份。待笔者执行起来发现，对象及表空间的导出时间是非常短的，当了解了整个操作步骤及过程后，整个数据库移植占时最长的就是物理数据文件传输过程，我们可以通过多种方式提高网络传输速度以缩短数据库移植用时。特别是针对只有数据表空间变化较多的数据库而言，在进行过一次测试移植后，完全可以快速顺利进行数据移植和同步。

上述实现过程相对于基于rman备份的数据库移植，移植的步骤并不是简洁的，但经实际操作发现，确实比较灵活、方便和快捷的。

参考文献：

[1] 吴秀君.浅谈Oracle数据库SQL性能优化[J].数字技术与应用.2013（09）.

[2]Oracle数据库移植方案[J].中南民族大学学报（自然科学版），2005（03）.

第6篇：数据库设计范文

关键词：工作过程；数据库；应用技术

在网络环境越来越广阔的背景下，数据库系统已经在各个领域均有所涉及，并且成为了信息系统的基石与核心，促使诸多计算机科学与工程技术人员必须要掌握专业的数据库技术、技能。我国高校计算机相关专业学生亦需要学习数据库应用技术，以培养并且提高自身的数据库技术基础知识与管理应用水平。但是，鉴于数据库应用技术课程体系比较复杂，发展迅速，应用技术自身有较强的灵活性和多样性，采用传统教学方法并不能够取得良好教学效果。为此，有必要从工作过程视域下对数据库应用技术课程设计作出研究。

一、工作过程视域下的数据库应用技术课程开发

1、确定工作岗位数据库应用技术课程应该属于高校，尤其高职院校软件技术专业十分重要的核心课程内容，为了培养更多高素质、高能力的软件开发人才，必须要对高职院校软件技术专业学生的岗位定位进行恰当分析[1]。通过表1的相关信息可以发现，高职院校软件技术专业学生的首岗需求均需要其掌握数据库技术，需要具备桌面开发、WEB开发、数据库管理的能力。另外，学习数据库技术课程能够保证Oracle课程的有序开展，为广大软件技术专业学生进一步掌握数据库系统技术奠定坚实知识基础。2、提炼工作任务对于高职院校软件技术专业学生岗位工作任务进行提炼时，必须要对专业的工作岗位具有比较清晰的认知。根据表1的相关信息，基本上可以将软件技术专业岗位工作任务归纳为如表2所示的内容。3、确定领域知识工作过程视域下的数据库应用技术课程，且本质在于参照实际的工作过程，将工作领域的知识与工作过程进行结合，通过设计相应的教学活动培养学生具备专业工作能力[2]。从该点可以发现，高职院校软件技术专业不仅仅需要对工作岗位和工作任务具有清晰的了解，更要明确各个工作领域的知识点，以便更加科学的编写教材，选择恰当的教学模式。具体工作领域知识点如表3所示。4、设计学习情境工作过程视域下的数据库应用技术课程设计实施需要一定的学习情境予以支撑，帮助学生真正的、直接的参与到课程设计教学中[3]。设计学习情境时，必须要保证专业知识、工作能力、职业素养以及教学场景之间的有效融合，对于课程内容应该重构，保证各个课程之间紧密相连，形成系统化的教学。一般情况下，高职院校软件技术专业在工作过程视域下进行数据库应用技术课程学习情境设计时，可以采用图1所示的学习情境，在遵循学生认知学习与职业成长规律的情况下，提升教学质量。

二、工作过程视域下的数据库应用技术课程设计实施方法

实施工作过程视域下的数据库应用技术课程设计，必须要坚持“以学生为主体”，采取多种有效的实施方法，达到提升教学效果的目的。具体的实施方法包括：项目驱动教学法，即通过对教学内容进行分析，将其组织成为不同的项目案例，学生根据不同案例进行学习，掌握不同的知识、技能，提高自身职业素养；启发式教学法，即从学生的角度出发启发学生的思维，调动学生积极性与主动性，使其有效的参与到教学活动中；角色扮演教学法，即设置学习情境，令学生分组对实际工作当中的角色进行扮演，促使学生掌握工作技能并培养前期具有良好合作能力；教、学、做一体化教学方法，即将理论联系实际，打破传统的理论、实验、实训课程教学借鉴，为学生建设实训室，师生良好互动下边学、边做，培养学生的思维能力和动手能力，激发学生学习兴趣。

三、结论

综上所述，工作过程视域下的数据库应用技术课程设计，必须要将实际的工作项目作为载体，能够根据高职院校以及软件技术专业学生的特点，对典型的工作岗位、工作任务进行透彻分析。在此基础上，必须要能够明确岗位所需要的知识点，为学生的学习创建良好学习情境。另外，教师自身必须要具有较高的专业能力，能够采用多样化的实施方法，充分调动学生的学习积极性与主动性，使其参与到工作过程视域下的数据库应用技术课程设计教学当中，不断提高学生的职业能力，满足岗位需求。

参考文献

[1]吴冬晨.基于工作过程导向的《计算机应用基础》课程的设计与实践[J].现代计算机(专业版)，2013，06（05）:19-24.

[2]潘祯，孙玉宝，王艳华.基于工作过程的“S…Q…L…Server数据库应用”课程设计与实施[J].中国电力教育，2012，01（11）:45-46.

第7篇：数据库设计范文

关键词 城建档案数据库设计

中图分类号：G275.3文献标识码： A 文章编号：

一 数据库设计概述

城建档案管理信息系统数据库设计是系统设计的核心，是系统实现的前提，是系统成败的关键，也是衡量系统好坏的一个重要的因素。基于数据库系统对城建档案进行数字化组织和管理不但可以提供更准确和快捷的信息检索服务，还能极大地提高工作效率和安全性。系统库设计过程中除考虑到原有文字、图纸资料的保存外，还要考虑到文件和资料的数字化转化及入库和管理。

城建档案数据库包括城建档案业务管理数据库、档案信息数据库、元数据库等。按照城建档案信息的类型，可以将信息资源划分为空间数据库、非空间数据库和多媒体文档三个逻辑组成部分。

图1城建档案综合管理系统数据库逻辑分类图

(1)空间数据库由空间数据库引擎管理，保存空间数据信息，包括城建档案所在的地形图、用地规划图、道路红线图、管线图及竣工测量图等;

(2)非空间数据库是与地理位置无关的信息数据，包括关系数据库、工作流相关数据、城建档案办公和业务管理的信息、部门信息、人员信息等;

(3)多媒体文档保存各种非结构化的信息，包括城建档案扫描影像、图像照片、影音和网页文档等，并建立必要的全文检索引擎，它在实现上可以基于关系数据库或文件系统，本文采用了文件系统管理。

本文主要介绍的是非空间数据库中的基于SQL Server 2000构建的关系数据库。主要提取出纸质档案数据库和声像档案数据库进行介绍。

二 数据库设计原则

本文数据库设计采用SQL Server2000大型关系型数据库，Microsoft SQLServer 2000数据库是Microsoft公司的大型数据库系统，应用方便，适合中小型数据库应用。SQL Server 2000是一个具备完全Web支持的数据库产品，它提供一系列方法将数据填充到Web服务器，同时提供对数据的快捷访问，提供对可扩展标记语言(XML)的核心支持以及在Internet上和防火墙外进行查询的能力，是一个可伸缩、高性能的数据库管理系统。

本文设计数据库系统时严格遵循第三范式。设计系统时遵循的原则有:

(1)层次分明，高度结构化，保证数据的结构化、标准化和规范化。

(2)正确性与完整性。所涉及的数据库内容应该尽可能全面，字段的类型、长度都应该准确地反映业务处理的需要，所采用的字段类型、长度能够满足当前和未来的业务需要。对所有数据进行严格约束性检查，增加了数据的正确性与完整性，对系统快速稳定运行打好基础。

(3)关系一致。应准确表述不同数据表的相互关系，如一对一、一对多、多对多等，应符合业务数据实际情况。

(4)子系统之间松散祸合。各个子系统之间应遵循松散祸合的原则，即在各个子系统之间不设置强制性的约束关系。一方面避免级联、嵌套的层次太多;另一方面避免不同子系统的同步问题。

(5)设定相应的安全机制，由于数据库的信息对特定的考生有特定的保密要求，SQL Server 2000提供了良好的数据访问控制和数据恢复等安全机制。

三 纸质档案数据库设计

1概念结构设计

以竣工档案为例，分析几个主要实体特点如下:

(1)移交合同书:合同的主要信息包括:合同号、合同名称、移交单位、计划开工日期、计划竣工日期等。其中合同号是唯一的。

(2)工程。一个合同包括一个或多个工程。工程的详细信息包括项目顺序号、工程序号、工程名称、工程地点、工程建设单位、工程施工单位等信息。其中，对于每一个工程，工程的项目顺序号是唯一的。

(3)工程状态。工程的状态包括未审批、未整理、未编号等。这里也是用工程的项目顺序号来标识每个工程。

竣工档案的数据需求中还有实体，这里不再一一赘述。在需求调研阶段，要充分了解各种档案的属性信息，还有各种档案在馆内各个科室之间的流转过程，以确保所建立的数据库要支持用户业务需求。如维护事务、查询事务等。下图是纸质档案实体E-R模型初稿:

图2 纸质档案数据库实现E-R模型

2逻辑结构设计

逻辑结构涉及的主要任务就是把概念结构设计阶段设计好的基本的E-R模型转换成与选用DBMS产品所支持的数据模型相符合的逻辑结构。我们将前面标识好的E-R图转换成关系数据模型，并对它进行优化。

第一步:标识实体

首先标识在数据库中必须描述的实体(以几个表为例):

Contract Info(移交合同书)

Project Info(工程信息)

Archive Status(档案状态)

将实体存档，即形成数据字典。下面是在数据字典中记录的移交合同书表的

详细信息。

表1合同信息(Contract Info)表

第二步:标识实体之间的关系，并检查实体之间是否有通路，将E-R模型映射为表的集合。对每个表的结构都使用规范化来检查。

图3纸质档案数据库映射过程图

用规划化方法检查表结构:

(1)表至少符合第三范式(3NF)，是否消除了传递函数依赖，部分函数依赖。

(2)表是否满足用户需求，即是否支持用户事务。根据用户需求和系统要求，检查数据库表中是否包含所有必须的属性，由实体到表的映射是否正确。

(3)根据所建立的主外键关系，看数据库设计是否满足完整性约束，包括实体完整性，参照完整性，列的值域约束等。在标识候选键时，可以看到合同号、项目顺序号可以唯一标识一个实体，这里我们就把他们确定为主键。

(4)检查模型的数据冗余。

对于某些复杂查询或者经常使用的查询我们可以定义为视图，比如，系统中打印模块设计打印“城市档案交接目录”，该目录信息涉及5个表的内容，对于这种复杂的查询我们定义为视图，用户每次对视图进行查询，大大简化了用户的使用。

3物理结构设计

第8篇：数据库设计范文

关键字：在线考试系统；数据库；设计；实现

中图分类号：TP311文献标识码：A文章编号：1009-3044(2012)03-0508-04

The Design and Implementation of Database for Online Examination System

Liu Hong-jiang

(Aba Teachers’College, Aba 623002, China)

Abstract: With the continuous development of computer and network technology as well as test technologies and methods, online exami? nation can meet the requirements of paperless examination and become one of the most important means of examination. In this trend, da? tabase will been designed for the establishment of online examination system, all these works is to expand the areas of students’ knowledge and to ensure fairness of the examination to a certain extent and also to improve the modernization level of test administration. Online ex? amination system is a typical management information system (MIS), which runs on windows 2003 sever, using a powerful and easily to op? erate environment named Microsoft SQL server 2005 as its database development platform.

Key words: online examination system; database; design; implementation

21世纪是一个“知识爆炸”的时代，信息更新的速度达到空前。计算机技术与网络技术越来越广地应用于社会的各个领域，它们在现代高等教育中的应用,是现代高等教育发展的需要,也是改革教育模式,提高学校教学效果和教学效率、提高科研和管理水平的必要手段。基于网络的在线考试和无纸化办公一样必然成为社会发展的趋势，在线考试是采用大规模试题库的计算机网络考试模式使得它颠覆了传统的考试方式，使得考试出卷、答题方式以及成绩管理发生着巨大的变革，考试过程变得方便、高效、快捷、公正。有趋势表明，标准化的在线考试方式已当今考试的发展方向，当前国际上许多考试认证如GRE,其出题、答卷以及评分都是在计算机上完成的。和传统的考试方式相比，无纸化的在线考试有着其科学、及时、准确、公平等优点，这是传统考试形式无法替代和比拟的优势。

1需求分析

需求分析是数据库设计的重要步骤之一，这一阶段的主要工作是确定使用这一数据库系统的用户，以及他们的业务活动。管理员主要负责录入开课信息，教师和学生名单以及查询学生试卷等工作。

教师主要负责录入试题，修改试题，生成试卷和阅卷等工作。

学生主要完成在规定时间内的答题任务。

2数据库设计

数据库设计对于在线考试系统的开发来说是一个十分重要的环节，数据库设计质量的优劣直接影响到数据库中数据的冗余度，一致性等问题。下面就对数据库的规范化设计进行说明。2.1关系数据理论及规范化

针对一个具体的数据库应用应该构造几个关系模式？每个关系由哪些属性组成？即如何构造适合于它的数据模式，这是关系数据库逻辑设计的问题。为了解决上述问题并使数据库设计走向规范，1971年E.F.Cldd提出了规范化理论。关系数据理论就指导产生了一个具体确定的、好的数据库模式的理论体系及范式理论。范式理论的具体内容如下：

第一范式：如果关系模式R的每一个属性都是不可分解的则R为第一范式的模式记为R∈1NF。

第二范式：如果关系模式R是第一范式，且每个非主属性都完全函数依赖于关键字，则称R为满足第二范式的模式，记为R∈2NF。

第三范式：如果关系模式R是第二范式，且没有一个非关键字属性石传递函数依赖于候选关键字属性，则称R满足第三范式的模式，记为R∈3NF。

扩充第三范式：如果关系模式R是第三范式，且每一个决定因素都包含有关键字，则称R为满足扩充第三范式的模式，记为

R∈BCNF。

第四范式：如果关系模式R是第三范式，且每个非平凡多值依赖XY（Y不是X的子集），X都含有关键字，则称R为满足第四范式的模式，记为R∈4NF

2.2数据库设计

在线考试系统的各个功能模块是否能够紧密地结合在一起以及如何结合，，关键在于数据库。因此对在线考试系统的数据库进行合理的逻辑设计和有效的物理设计是关键。

2.2.1概念设计

这一部分的工作，主要是将需求分析阶段得到的用户需求抽象为信息世界的概念模型，采用自底向上的方法，进行系统的概念设计，得到以下实体及属性的E-R图。

教师实体包括教师编号、教师姓名用户名和密码四个属性，其E-R图如图1所示。

图1教师实体及属性局部E-R图

学生实体包括学号、姓名、性别和密码四个属性，其E-R图如2图所示。

图2学生实体及属性局部E-R图

试题库实体包括课程名称、题目内容、参考答案、题目类型、难易度、备选答案A、备选答案B、备选答案C、备选答案D、备选答案E、备选答案F等属性，其E-R图如3图所示。

图3试题库实体及属性局部E-R图

试卷组成实体包括试卷代码、课程名称、试卷编号、考试日期等属性，其E-R图如4图所示。

图4试卷组成实体及属性局部E-R图

试卷实体包括试卷编号、课程名称、状态、得分、大题号、小题号、试题库中序号、学生学好、学生答案等属性，其E-R图如5图所示。

图5试卷实体及属性局部E-R图

根据需求分析，教师、题库、学生和试卷四个实体之间的关系如图6所示。

图6考试局部E-R图2.2.2逻辑设计

由于现在设计数据库系统都普遍采用关系模型的关系数据库管理系统，因此逻辑设计的主要工作是将概念设计得出的实体关系模型（E-R图）转化成关系模式。

具体如下：

教师（教师编号，教师姓名，用户名，密码）

学生（学号，姓名，性别，密码）

试题库（课程代码，课程名称，题目类型，题目内容，被选答案A，被选答案B，被选答案C，被选答案D，参考答案，难易度）

试卷组成（试卷代码，课程名称，题号(大题)1，试题类型1，小题数1，难题数1，中题数1，简单题数1，每小题分数1，题号(大题)2，试题类型2，小题数2，难题数2，中题数2，简单题数2，每小题分数2，题号(大题)3，试题类型3，小题数3，难题数3，中题数3，简单题数3，每小题分数3，题号(大题)4，试题类型4，小题数4，难题数4，中题数4，简单题数4，每小题分数4，题号(大题)5，试题类型5，小题数5，难题数5，中题数5，简单题数5，每小题分数5，题号(大题)6，试题类型6，小题数6，难题数6，中题数6，简单题数6，每小题分数6，题号(大题)7，试题类型7，小题数7，难题数7，中题数7，简单题数7，每小题分数）

试卷（试卷编号，试卷名称，大试题号，小试题号，试题库中序号，学号，学生答案，得分）

成绩（学号，试卷编号，课程名称，成绩）

3数据库表结构的建立

数据库表结构的建立在逻辑设计阶段得出的关系模型的基础上，并对其进行适当的优化，各关系转化后的表结构具体如下：

Teacher表（教师信息表）：主要字段有教师编号，用户名，密码及权限，其中教师编号为主键，由于教师对系统掌握的程度不同，故增加一个权限字段，管理员的权限为H，理工科教师为权限为M，文科艺体教师的权限为L。

Student(学生信息表)：主要字段有学号、姓名、性别和密码，其中学号为主键。

Paper_lib(试题库表)：主要字段有标识、题目类型、题目内容、备选答案A、备选答案B、备选答案C、备选答案D、参考答案和难易度。其中增加一个标识来作为主键，用于确定记录的唯一性。在该表中，增加一个标识来作为主键，确定记录的唯一性。

Paper_comp (试卷组成表)：主要字段有标识、试卷名称、课程名称、试卷代码、题号（大题）1、试题类型1、小题数1、难题数1、中等题数1、简单题数1、……、题号（大题）7、试题类型7、小题数7、难题数7、中等题数7、简单题数7、考试时间、考试状态、考试学期，教学班号，教师编号等。其中，教师编号为外键，与教师表建立关系。在该表中，增加一个标识作为主键，确定记录的唯一性。

Paper(试卷表)：主要字段有标识、试卷代码、试卷编号、试题（大题）号、小题号、学生答案、试题库中序号、学号、得分。其中学生学号为外键，与学生表建立关系；试卷代码为外键，与试卷组成表建立关系。在该表中，增加一个标识作为主键，确定记录的唯一性

4数据库的连接

4.1数据库平台选择

只有选择合适的数据库系统，然后根据数据库设计阶段得出的表结构，用具体的数据库语言来实现之后，才能实现数据库的连接。目前流行的数据库系统有很多，例如SQL Server，MySQL，Sybase，Oracle等，这里我们选择Microsoft的SQLserver 2005作为在线考试系统的数据库开发平台。

4.2系统开发平台选择

在线考试系统可以选择的开发平台也很多，例如jsp，PHP，.Net或者是asp等。这里我们选择一种轻量级而且开源的开发平台PHP，PHP(Hypertext Preprocessor，超文本预处理器)是一种HTML内嵌式的语言，混合了C、Java、Perl等多种语言的特点，被广泛应用的开源式的多用途脚本语言。PHP最重要的特征是它的数据库集成层，完全支持SQL标准，可以支持大多数数据库系统，并且具有数据库访问速度快、运行效率高、性能稳定、操作简单等优势。PHP提供了标准的数据库接口，数据库连接方便，兼容性强；扩展性强；即可以用来开发WEB应用程序，也可用来开发普通的应用程序，应用范围非常广.

4.3数据库连接

PHP与SQL Server数据库的连接有两种方式，一种是PHP通过ODBC访问SQL Server 2005。ODBC(Open DataBase Connectivity)即开放式接口，是由微软主导的数据库连接标准，目前所有的关系数据库都提供了ODBC驱动程序，所以ODBC已经成为数据库访问的业界标准，并得到了广泛应用。另外一种是PHP直接访问SQL Server 2005时，利用PHP提供的Mssql函数库来创建连接。分为一般和永久两种连接方式：

一般连接使用的函数是mssql_connect。

永久连接使用的函数是mssql_pconnect。

其语法如下：

int mssql_connect(string [servername],string [username], string [password]);

int mssql_pconnect(string [servername],string [username], string [password]);

在系统中,采用的是第一种方式使用mssql_connect函数进行数据库的连接，创建一个php与数据库之间的连接文件，命名为conn_db.php来实现的。conn_db.php的代码如下：

$dbconnected=@mssql_connect("数据库服务器名称或IP","用户名","密码")

or die("连接数据库服务器失败！");

mssql_select_db("database",$dbconnected);//选择要操作的数据库

?>

为了系统的安全，用@符号来屏蔽系统在客户端浏览器显示错误提示，同时用die()函数来显示连接数据库服务器失败的错误提示并直接退出程序。

用mssql_close函数关闭连接，创建一个php与数据库之间的断开文件，命名为close.php

@mssql_close($dbconnected);

?>

5结论

本文从需求分析、概要设计、逻辑设计及数据库的实现及连接等方面进行简单地阐述。对于在线考试系统的数据库设计有一定的参考价值。

参考文献：

[1]申时凯,李海雁.数据库应用技术[M].2版.北京:中国铁道出版社,2005.

[2]陈恭和.数据库基础与SQL应用教程[M].北京:高等教育出版社,2003.

[3]石志国.JSP网络开发详解[M].北京:电子工业出版社,2007.

第9篇：数据库设计范文

关键词：门诊管理；数据库设计；概念；逻辑

中图分类号：TP311.52 文献标识码：A文章编号：1007-9599 (2011) 14-0000-02

Outpatient Management System Database Design

Liu Ying

(Xinjiang Uygur Autonomous Region Communist Youth League,Urumqi830002,China)

Abstract:The hospital outpatient information system is realized based on the information management in hospital,outpatient management system,the database design is especially important,a good database design will directly influence the performance of the whole system,this paper describes in detail the outpatient management system database design.

Keywords:Outpatient management;Database design;Concept;Logic

数据库设计是建立数据库及其应用系统的技术，是信息系统开发和建议中的核心技术。由于数据库应用系统的复杂性，为了支持相关程序运行，数据库设计就变得异常复杂，因此最佳设计不可能一蹴而就，而只能是一种“反复探寻，逐步求精”的过程，也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。数据库技术充分体现系统的需求，数据库是为应用服务的，好的数据库设计应该首先能满足应用系统的业务需求，准确的表达数据间关系。

在医院门诊管理系统中，借助数据库技术，可以科学地保存和管理医院大量复杂的数据信息，数据库设计已经成为医院信息系统的核心和基础，数据库设计的优劣将直接影响整个系统的性能。

一、数据库设计原则

（一）一致性原则。对信息进行统一的系统的分析与设计，协调好各数据源，做到“数出一门”、“算法统一”、“度量一致”，保证系统数据的一致性和有效性。

（二）完整性原则。数据库的完整性是指数据的正确性和相容性。要防止合法用户使用数据库时向数据库加入不合语义的数据。对输入到数据库中的数据要有审核和约束机制。

（三）安全性原则。数据库的安全性是指保护数据，防止非法用户使用数据库或合法用户非法使用数据库造成数据泄露、更改或破坏。要有认证和授权机制。

（四）可伸缩性原则。数据库结构的设计应充分考虑发展的需要、移植的需要，具有良好的扩展性、伸缩性和适度冗余阵。

（五）规范化。数据库的设计应遵循规范化理论，规范化程度过低的关系，可能会存在插入、删除异常、修改复杂、数据冗余等问题，解决的方法就是对关系模式进行分解或合并规范化，转换成高级范式

二、需求分析

通过对医院门诊管理的现状进行了解，得到如下需求：

（一）门诊病人需要到门诊挂号处挂号，在此过程中，病人可对所要就诊的相应科室进行查询，对当值医生进行查询，然后再去挂号，在挂号处登记，基本信息，如姓名，年龄，性别，住址，联系方式等，再由挂号处制成IC卡发给病人。

（二）病人到门诊收费处缴挂号费，并到相应科室就诊，经医生诊疗后，开处方，检查或检验申请单，病人持收费单到门诊收费处划价缴费，然后持收费证明到检查科室或检验科室进行检查。

（三）门诊药房接到取药处方后，进行配药和发药，检查科室或检验科室接到病人申请后，对病人进行检查或检验，并将结果填入结果报告单。

三、概念结构设计

概念结构的设计，它是整个数据库设计的关键，独立于数据库逻辑结构、物理结构和DBMS。概念模型是对信息世界建模，所以概念模型能够方便、准确地表示出信息世界中的用概念模型。结合以上的需求分析结果，采用ER模型进行数据库的概念设计，说明如下：

（一）主要实体及属性。

门诊患者（患者编号、登记时用户名、密码、姓名、性别、出生日期、年龄、婚姻状况、职业、籍贯、民族、身份证号码、工作单位、联系电话、家庭住址等）

门诊医生（医生编号、登录时密码、姓名、性别、年龄、职称、所属科室、专家门诊科目、联系电话、电子邮件）

医务人员（医务人员编号、登录时密码、姓名、性别、年龄、类别、联系电话、电子邮件）

挂号单（挂号单编号、患者编号、挂号科室、主治医生编号、挂号时间）

门诊病历（门诊病历记录编号、患者编号、主治医生编号、患者症状、诊断结果、处理方案、就诊开始时间、就诊结束时间、诊断是否结束）

处方单（处方记录编号、门诊病历记录编号、处方内容）

检查项目（检查记录编号、门诊病历记录编号、检查内容）

检验项目（检验记录编号、门诊病历记录编号、检验内容）

划价单（划价记录编号、处方记录编号、检查记录编号、检验记录编号、处方划价、检查划价、检验划价）

收费单（收费记录编号、划价记录编号、患者编号、收费员编号、总收费数目、患者是否缴费、门诊收费时间）

发药单（发药单编号、收费记录编号、患者是否缴费、患者编号、处方记录编号、处方内容、患者是否取到药品、发药时间、发药员编号）

药品（药品编号、名称、生产批号、生产日期、有效日期、价格、数量）

（二）联系说明及其相应属性。

支付（支付金额、支付时间、支付项目）

生成（门诊处方------药品提领单）

发生（门诊医生-------处理方案）

对应（门诊病人-------门诊病历）

（三）主要的E-R图。

门诊挂号E―R图

四、逻辑数据库设计

概念结构是现实世界的数据模型，必须将其转换为逻辑结构后才能进行数据库应用的设计。根据关系数据库规范化理论，关系数据库中的关系必须要满足一一定的范式，包括第一范式，第二范式，第三范式，第四范式，第五范式，规范化的目的是为了消除插入、删除异常，降低数据的冗余度，但是，数据的冗余度越低，查询越困难，因此，合理的数据冗余是必要的。对一般的信息系统，能达到第三范式已能满足要求。在确定联系实体的主键时，对1：1关系，任选相关两实体的主键之一作为联系实体的主键；对1：M关系，选“M”的主键作为联系实体的主键；根据以上原则，门诊管理数据库部分关系表的设计如下：

（一）挂号单（挂号号、挂号类别、挂号日期、科室、病人号、医师号）。说明：由实体型生成的关系模式，由于门诊医师和挂号单的联系是1：1，因而将其加入门诊医师的主码加入到挂号单所形成的关系模式中。

（二）门诊病历（病历号、病人号、病历内容、诊断时间、医师号、处方号）。说明：由门诊病历形成的关系模式，而门诊病历与门诊处方的联系为1：1，故将门诊处方的主码处方号加入到门诊病历关系模式中。

（三）门诊收费项目（门诊收费项目号、挂号号、支付时间、项目类型、收费金额、收费人中、病人号）。说明：由门诊收费项目形成的关系模式，门诊收费项目与挂号单为1：1，故将挂号号加入到其中。

（四）门诊医师（医师号、科室、当值日期）。说明：门诊医师中的属性：姓名、专业技术职称，性别，出生日期，出生地，民族，身份证号等。

（五）挂号收费（挂号号、门诊收费项目号、收费金额）。说明：由挂号单与门诊收费项目之间形成的一种联系，收费金额是挂号收费的属性。

（六）缴费（病人号、门诊收费项目号、缴纳金额）。说明：由门诊病人和门诊收费项目之间形成的一种联系，缴纳金额是缴纳的属性。逻辑设计如图所示：

数据库逻辑设计图

五、数据表设计

医院门诊系统数据库中每个表格表示数据库中的一个表。主要表格的设计结果如下所示：

字段名 数据类型 可否为空 说明

yhm varchar（4） Not Null 员工号（主键）

dlkl varchar（8） Null 登录口令

dlql varchar（2） Null 登陆权利

登录信息表

字段名 数据类型 可否为空 说明

mzh varchar（14） Not Null 门诊号（主键）

brxm varchar（8） Null 病人姓名

brxb varchar（2） Null 病人性别

brnl varchar（4） Null 病人年龄

brlx varchar（2） Null 病人类型

ghksh varchar（4） Null 挂号科室

ghlb varchar（2） Null 挂号类别

ghysh varchar（7） Null 挂号医生

zhjzhj numeric（5.2） Null 专家诊金

zhjghf numeric（5.2） Null 专家挂号费

ghfhj numeric（5.2） Null 挂号费合计

ghy varchar（4） Null 挂号员

ghshj varchar（20） Null 挂号时间

挂号信息表

字段名 数据类型 可否为空 说明

mzhblbh varchar（8） Not Null 门诊病历编号（主键）

hzhbh varchar（8） Null 患者编号

zhzhiyshbh varchar（8） Null 主治医生编号

yj varchar（8） Null 诊治意见

门诊病历信息表

数据库是信息系统的核心和基础，它将大量的数据按一定的模型组织起来，提供存储、维护、检索数据的功能，只有对数据库进行合理的逻辑设计和有效的物理设计，才能开发出完善而高效的信息系统，用户才能方便、及时和准确地从数据库中获取所需的信息。

参考文献：

[1]张瑞丽.门诊信息系统在医院管理中的作用[J].医学信息,2005,18:8

[2]张京.基于Web Service的医院信息系统的设计与实现[J].成都:电子科技大学,2006

[3]祝福锋.医院管理信息系统分析与设计[D].武汉:华中科技大学,2004

[4]陈卓.基于Windows DNA的门诊挂号系统的研究与应用[D].长春:吉林大学,2004