管理信息系统的数据库设计包括哪些步骤

管理信息系统的数据库设计包括哪些步骤,第1张

按照规范的设计方法,一个完整的数据设计一般分为以下六个阶段:

⑴ 需求分析:分析用户的需求,包括数据、功能和性能需求;

⑵ 概念结构设计:主要采用E-R模型进行设计,包括画E-R图;

⑶ 逻辑结构设计:通过将E-R图转换成表,实现从E-R模型到关系模型的转换;

⑷ 数据库物理设计:主要是为所设计的数据库选择合适的存储结构和存取路径;

⑸ 数据库的实施:包括编程、测试和试运行;

⑹ 数据库运行与维护:系统的运行与数据库的日常维护。

(一)系统数据库类型

数据库是整个农用地分等信息系统的基础,是系统开发设计要考虑的重中之重。在数据形式上,系统数据库包括两大块:一是空间数据库,二是属性数据库。目前的空间数据技术已从以MapInfo为代表的混合型数据库(空间数据库+关系型数据库)发展到以ArcInfo的Coverage为代表的拓展型数据库。鉴于农用地分等属性数据量庞大,为减少数据冗余,提高数据检索的速度,本研究采用空间数据和属性数据分开管理的模式,依据关键字段进行绑定,进行科学索引,从而实现空间数据和属性动态链接和高效整合。

1空间数据库

江苏省农用地分等信息系统空间数据库内容包括以下方面:

(1)土地利用现状图层:全省13个省辖市以1996年土地利用现状图为基础,经变更调绘形成以2000年为基准年的土地利用现状图,以现行的土地分类标准按八大类分类进行信息提取并分层存储,系统分别存储为耕地、林地、水域、未利用地、建设用地等图层。

(2)全省土壤类型图层:以土属为分类单位,比例尺为1:20万。

(3)1996年和2000年全省行政区划图层:在行政区划中精确到乡镇级别,分别提取存储了市名图层、县(区)名图层、乡(镇)名图层、全省行政界线图层、市级行政界线图层、县(区)级行政界线图层、乡(镇)级行政界线图层。

(4)评价单元图层:通过GIS空间叠加功能,利用土地利用现状图、行政区划图和土壤类型图叠加产生的评价单元图层,建立分等评价单元数据库。

2属性数据库

江苏省农用地分等信息系统属性数据库内容包括以下方面:

(1)土壤属性数据:以全国第二次土壤普查为基础,结合全省土壤监测样点数据,建立土壤质量状况数据库,最小单位为土种,包括pH值、有机质含量、表层土壤质地、耕层厚度、障碍层深度、水土侵蚀程度、盐渍化程度数据。

(2)农田水利环境数据:建立了1996~2000年间各乡镇农田水利环境基础数据库,包括灌溉保证率、排水条件数据。

(3)土地利用现状数据:建立了全省13个省辖市的以1996年土地利用现状图为基础,经变更调绘形成的以2000年为基准年的土地利用现状数据库,区分耕地中的详细用地类型差异,标示水田、旱地、荒草地等纳入本次评价范围的用地内容。

(4)全省地形地貌数据库。

(5)农业区划数据:输入了江苏省农业区划数据,把江苏全省划分为6大区划,以乡镇为最小级别,建立全省乡镇的区划归属数据库。

(6)农业耕作制度数据:建立了全省各市、县、乡镇的农业耕作制度数据库,包括指定作物水稻和小麦的播种空间分布状况数据库。

(7)光温生产潜力数据:建立了全省各市、县指定作物水稻和小麦的光温生产潜力和气候生产潜力数据库。

(8)农业投入-产出数据:全省13个省辖市以乡镇为单位,建立了1996~2000年农业生产投入-产出数据库。

(9)作物产量数据:全省13个省辖市以乡镇为单位,建立了1996~2000年的指定作物水稻和小麦的产量数据库。

(10)土地利用详查分类面积数据:全省13个省辖市以乡镇为单位,建立了2000年土地利用详查分类面积数据库。

从数据格式上分,数据库又可分为:①图件数据库:指空间数据以及绑定在空间数据上的相关属性数据,本次江苏省农用地分等建立了以分等单元为记录的属性数据库,并通过关键字段与空间数据关联;②分类统计数据库:包括全省13个省辖市以乡镇为单位的1996~2000年指定作物产量统计数据和全省13个省辖市以乡镇为单位的2000年土地利用详查分类面积统计数据。

(二)系统数据库管理模式

为减少数据存储冗余,同时提高索引速度,江苏省农用地分等信息系统数据文件采用普遍的目录树形式进行管理,按省-市-县行政体系分别存储相关数据。全省建立13个省辖市分目录,分目录下按照各自所含的县(区)建立子目录。根据目前行政管理体系现状,基础资料大多来源于县级行政单位,因此采用县(区)为基本行政单位较为合理,在保证资料来源的同时,也利于资料的分类归档存储。其相对应的空间图件数据也按精度要求分割到县级行政单位,既能减少系统调用数据的吞吐量,同时也满足了系统的精度需求。空间数据、属性数据、文本数据按照各自所属的行政级别归类存储,同时设立数据文件管理器进行目录文件的索引管理,见图3-86。

图3-86 江苏省农用地分等信息系统数据文件管理模式图

(三)系统数据库结构

数据库的结构设计决定了数据之间的调用及接口关系,清晰的逻辑调用关系和统一的数据接口格式有利于数据的组织、管理、调用。

1空间数据库

江苏省农用地分等信息系统空间数据库以矢量图件的形式存在,以分图层的方式管理,包括了全省行政界线、土壤类型、按八大类分别提取的土地利用现状、分等单元等图层。其中,分等单元图层作为农用地分等的基础,考虑到图层本身信息量大,可能影响到系统运行效率,因此所在图层的属性表中只保留了ID字段,通过ID字段与外部属性库绑定,实现分等单元与外部属性库一一对应关系。ID字段是本图层的特征代码,表征了单元的唯一性,能体现出单元的图上位置和行政归属。《农用地分等定级规程》(国土资源大调查专用)和《中华人民共和国行政区划代码》(GB/T 2260-1999)为本研究分等单元代码的编码依据;本研究有1996年和2000年两套行政区划工作底图,为此分等单元特征代码共设14位,依次为江苏省代码(2位)-市代码(2位)-2000年县或区代码(2位)-2000年乡镇代码(2位)-1996年县或区代码(2位)-1996年乡镇代码(2位)-分等单元号(2位)。其中,省、市、县(区)的行政代码按国家统一代码,乡镇级代码在县(区)范围内根据划分分等单元的需要依次编码;分等单元编号的原则是不破乡镇界,即单元号是在同一乡镇内部自行编码。示例:32011501210101,指1996年江苏(32)南京(01)市江宁县(21)由于2000年行政调整变更为南京(01)的江宁区(15)。按行政体系分级编码的优点是有利于空间查询和国土资源管理部门根据工作需求按行政级别分类汇总统计数据。

2属性数据库

江苏省农用地分等信息系统采用关系型数据库来存储数据,优点是结构清晰明了,数据的更新维护方便,通过索引能优化数据库,建立快速的查询浏览(表3-26~表3-30)。

表3-26 行政代码数据结构表

表3-27 土壤属性数据结构表

表3-28 农田水利设施数据结构表

表329 指定农作物投入-产出数据结构表

表3-30 农业耕作制度及农业区划表

(四)系统模型库

系统以《农用地分等定级规程》(国土资源大调查专用)中的相关技术方法和计算模型为基础,在模型库中预先内置了分等计算模型。模型库是动态,它允许专家根据情况动态调整计算模型形式及其参数。系统主要模型的数学计算公式如下:

(1)农用地自然质量分值(Clij)计算公式见式(3-11)。

(2)样点土地利用系数计算公式:

中国耕地质量等级调查与评定(江苏卷)

式中:

Klj´——样点的第j种指定作物土地利用系数;

Yj——样点的第j种指定作物实际单产;

Yj,max——第j种指定作物最大标准粮单产。

(3)等值区土地利用系数计算公式:

中国耕地质量等级调查与评定(江苏卷)

式中:

Klj——等值区内第j种指定作物土地利用系数;

Klj´——参与计算的同一等值区内合格样点第j种指定作物土地利用系数;

n——排除异常数据后参与计算的样点的个数。

(4)样点土地经济系数计算公式:

中国耕地质量等级调查与评定(江苏卷)

式中:

Kcj′——样点的第j种指定作物土地经济系数;

Yj——样点第j种指定作物实际单产;

Cj——样点第j种指定作物实际成本;

Aj——第j种指定作物最高“产量-成本”指数。

(5)等值区土地经济系数计算公式:

中国耕地质量等级调查与评定(江苏卷)

式中:

Kcj——等值区内土地经济系数;

Kcj´——参与计算的同一等值区内合格样点第j种指定作物土地经济系数;

n——排除异常数据后参与计算的样点的个数。

(6)农用地自然质量等指数(Ri)计算公式见式(3-12)和式(3-13)。

(7)农用地利用等指数(Yi)计算公式见式(3-14)和式(3-15)。

(8)农用地经济等指数(Gi)计算公式见式(3-16)和式(3-17)。

数据库设计的基本步骤如下:

1、安装并打开MySQL WorkBench软件以后,在软件的左侧边栏有三个选项,分别是对应“连接数据库”、“设计数据库”、“迁移数据库”的功能。这类选择第二项,设计数据库,点击右边的“+”号,创建models。

2、进入MySQL Model界面后,点击“Add Diagram"。

3、然后就进入了EER Diagram的设计页面。可以从左侧的图标中选择要创建的资源。鼠标停留在图标上3秒后,会提示资源的类型。选择资源后,可以在设计页面上方选择属性。

4、这里添加了一张数据库表,添加后,双击,在页面的底部会出现数据库表的编辑框。

5、这里创建一张user表,设置了id、name、age三列。

6、还可以创建外键,左侧提供了四种外键类型。点击后,只需要用鼠标分别选中要关联的两个表即可。Workbench会自动生成对应的外键。

7、在文件、导出中,可以选择导出为sql脚本。

8、下图是导出过程sql脚本的过程。

数据库设计的基本步骤

按照规范设计的方法,考虑数据库及其应用系统开发全过程,将数据库设计分为以下6个阶段

1需求分析

2概念结构设计

3逻辑结构设计

4物理结构设计

5数据库实施

6数据库的运行和维护

数据库设计通常分为6个阶段1分析用户的需求,包括数据、功能和性能需求;2概念结构设计:主要采用E-R模型进行设计,包括画E-R图;3逻辑结构设计:通过将转换成表,实现从E-R模型到关系模型的转换;4:主要是为所设计的数据库选择合适的和存取路径;5数据库的实施:包括编程、测试和试运行;6数据库运行与维护:系统的运行与数据库的日常维护。),主要讨论其中的第3个阶段,即逻辑设计。

在数据库设计过程中,需求分析和概念设计可以独立于任何数据库管理系统进行,逻辑设计和物理设计与选用的DAMS密切相关。

1需求分析阶段(常用自顶向下)

进行数据库设计首先必须准确了解和分析用户需求(包括数据与处理)。需求分析是整个设计过程的基础,也是最困难,最耗时的一步。需求分析是否做得充分和准确,决定了在其上构建数据库大厦的速度与质量。需求分析做的不好,会导致整个数据库设计返工重做。

需求分析的任务,是通过详细调查现实世界要处理的对象,充分了解原系统工作概况,明确用户的各种需求,然后在此基础上确定新的系统功能,新系统还得充分考虑今后可能的扩充与改变,不仅仅能够按当前应用需求来设计。

调查的重点是,数据与处理。达到信息要求,处理要求,安全性和完整性要求。

分析方法常用SA(Structured Analysis) 结构化分析方法,SA方法从最上层的系统组织结构入手,采用自顶向下,逐层分解的方式分析系统。

数据流图表达了数据和处理过程的关系,在SA方法中,处理过程的处理逻辑常常借助判定表或判定树来描述。在处理功能逐步分解的同事,系统中的数据也逐级分解,形成若干层次的数据流图。系统中的数据则借助数据字典(data dictionary,DD)来描述。数据字典是系统中各类数据描述的集合,数据字典通常包括数据项,数据结构,数据流,数据存储,和处理过程5个阶段。

早期的数据库系统,经常采用某种编号,比如身份z号码,公司编号等等作为数据库表的 primary key。然而,很快,大家就发现其中的不利之处。比如早期的医院管理系统,用身份z号码作为病人表的 primary key。然而,第一,不是每个人都有身份z;第二,对于国外来的病人,不同国家的病人的证件号码并不见得没有重复。因此,用身份z号码作为病人表的 primary key是一个非常糟糕的设计。考虑到没有医生或者护士会刻意去记这些号码,使用自增长 primary key是更好的设计。公司编号采用某种特定的编码方法,这也是早期的数据库系统常见的做法。它的缺点也显而易见:很容易出现像千年虫的软件问题,因为当初设计数据库表的时候设计的位数太短,导致系统使用几年后不能满足要求,只有修改程序才能继续使用。问题在于,任何人设计系统的时候,在预计某某编号多少位可以够用的时候,都存在预计不准的风险。而采用自增长 primary key 则不存在这种问题。同样的道理,没有人可以去记这些号码。使用自增长 primary key另外一个原因是性能问题。略有编程常识的人都知道,数字大小比较比字符串大小比较要快得多。使用自增长 primary key可以大大地提高数据查找速度。2 避免用复合主键 (compound primary key)这主要还是因为性能问题。数据检索是要用到大量的 primary key 值比较,只比较一个字段比比较多个字段快很多。使用单个 primary key 从编程的角度也很有好处, sql 语句中 where 条件可以写更少的代码,这意味着出错的机会大大减少。3 双主键双主键是指数据库表有两个字段,这两个字段独立成为主键,但又同时存在。 数据库系统的双主键最早用在用户管理模块。最早的来源可能是参照 *** 作系统的用户管理模块。  *** 作系统的用户管理有两个独立的主键: *** 作系统自己自动生成的随机 ID (Linux, windows 的 SID), login id。这两个 ID 都必须是唯一的,不同的是,删除用户 test 然后增加一个用户 test, SID 不同,login id 相同。采用双主键主要目的是为了防止删除后增加同样的 login id 造成的混乱。比如销售经理 hellen 本机共享文件给总经理 peter, 一年后总经理离开公司,进来一个普通员工 peter ,两个peter 用同样的 login id, 如果只用 login id 作 *** 作系统的用户管理主键,则存在漏洞:普通员工 peter 可以访问原来只有总经理才能看的文件。 *** 作系统自己自动生成的随机 ID 一般情况下面用户是看不到的。双主键现在已经广泛用在各种数据库系统中,不限于用户管理系统。4 以固定的数据库、表应付变化的客户需求这主要基于以下几个因素的考虑:41 大型 EPR 系统的正常使用、维护需要软件厂商及其众多的合作伙伴共同给客户提供技术服务,包括大量的二次开发。如果用户在软件正常使用过程中需要增加新的表或者数据库,将给软件厂商及其众多的合作伙伴带来难题。42 软件升级的需要。没有一个软件能够让客户使用几十上百年不用升级的。软件升级往往涉及数据库表结构的改变。软件厂商会做额外的程序将早期版本软件的数据库数据升级到新的版本,但是对于用户使用过程中生成的表进行处理就比较为难。43 软件开发的需要。使用固定的数据库库表从开发、二次开发来说,更加容易。对于用户使用过程中生成的表,每次查找数据时都要先查表名,再找数据,比较麻烦。举例来说,早期的用友财务软件用 Access 作数据库,每年建立一个新的数据库。很快,用户和用友公司都发现,跨年度数据分析很难做。因此这是一个不好的设计。在 ERP 中,很少有不同的年度数据单独分开。一般来说,所有年份的数据都在同一个表中。对于跨国公司甚至整个集团公司都用同一个 ERP 系统的时候,所有公司的数据都在一起。这样的好处是数据分析比较容易做。现在大多数数据库系统都能做到在常数时间内返回一定量的数据。比如,Oracle 数据库中,根据 primary key 在 100万条数据中取 10 条数据,与在1 亿条数据中取 10 条数据,时间相差并不多。 5 避免一次取数据库大量数据,取大量数据一定要用分页。这基本上是现在很多数据库系统设计的基本守则。ERP 系统中超过 100万条数据的表很多,对于很多表中的任何一个,一次取所有的会导致数据库服务器长时间处于停滞状态,并且影响其它在线用户的系统响应速度。一般来说,日常 *** 作,在分页显示的情况下面,每次取得数据在 1-100 之间,系统响应速度足够快,客户端基本没有特别长的停顿。这是比较理想的设计。这也是大型数据库系统往往用 ODBC, ADO 等等通用的数据库联接组件而不用特定的速度较快的专用数据库联接组件的原因。因为系统瓶颈在于数据库( Database) 方面(数据量大),而不在于客户端(客户端每次只取少量数据)。在 B/S 数据库系统中,分页非常普遍。早期的数据库系统经常有客户端程序中一次性取大量数据做缓冲。现在已经不是特别需要了,主要原因有:51 数据库本身的缓冲技术大大提高。大部分数据库都会自动将常用的数据自动放在内存中缓冲,以提高性能。52 数据库联接组件的缓冲技术也在提高。包括 ADO 在内的一些数据库联接组件都会自动对数据结果集(result set)进行缓冲,并且效果不错。比较新颖的数据库联接组件,比如 Hibernate 也加入了一些数据结果集缓冲功能。当然,也有一些数据库联接组件没有对数据结果集进行缓冲,比如 JDBC Driver,不过几年之内情况应该有所改观。也有些不太成功的数据缓冲,比如 EJB 中的实体Bean,性能就不尽如人意,实体Bean数据也是放在内存中,可能是因为占用内存过多的缘故。相对来说,今天的程序员写客户端数据缓冲,能够超过以上两个缓冲效果的,已经比较难了。

数据库设计阶段包括五个阶段,分别是:需求分析阶段、概念结构设计阶段、逻辑结构设计阶段、物理设计阶段、数据库实施阶段、数据库运行和维护阶段。

独立于数据库管理系统的是:需求分析阶段,概念设计阶段,逻辑设计阶段,物理设计阶段。

依赖于数据库管理系统的是:实施阶段,运行和维护阶段。

数据库设计是建立数据库及其应用系统的技术,是信息系统开发和建设中的核心技术。由于数据库应用系统的复杂性,为了支持相关程序运行,数据库设计就变得异常复杂。

因此最佳设计不可能一蹴而就,而只能是一种“反复探寻,逐步求精”的过程,也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。

扩展资料:

形成过程

1、需求分析阶段:综合各个用户的应用需求(数据流程图(DFD)。

2、概念设计阶段:形成独立于机器特点,独立于各个DBMS产品的概念模式(E-R图)。

3、逻辑设计阶段:首先将E-R图转换成具体的数据库产品支持的数据模型,如关系模型,形成数据库逻辑模式;然后根据用户处理的要求、安全性的考虑,在基本表的基础上再建立必要的视图(View),形成数据的外模式。

4、物理设计阶段:根据DBMS特点和处理的需要,进行物理存储安排,建立索引,形成数据库内模式。

参考资料来源:百度百科--数据库设计

数据库设计主要包括需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库的实施和数据库的运行和维护,具体内容如下:

1、需求分析

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

2、概念设计

内容:对用户要求描述的现实世界,通过对其中诸处的分类、聚集和概括,建立抽象的概念数据模型。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。

3、逻辑设计

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

4、物理设计

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

5、验证设计

内容:收集数据并具体建立一个数据库,运行一些典型的应用任务来验证数据库设计的正确性和合理性。一般,一个大型数据库的设计过程往往需要经过多次循环反复。当设计的某步发现问题时,可能就需要返回到前面去进行修改。

6、运行与维护设计

内容:在数据库系统正式投入运行的过程中,必须不断地对其进行调整与修改。除了关系型数据库已有一套较完整的数据范式理论可用来部分地指导数据库设计之外,尚缺乏一套完善的数据库设计理论、方法和工具,以实现数据库设计的自动化或交互式的半自动化设计。

扩展资料:

重要性

1、有利于资源节约

对计算机软件数据库设计加以重视不仅可减少软件后期的维修,达到节约人力与物力的目的,同时还有利于软件功能的高效发挥。

2、有利于软件运行速度的提高

高水平的数据库设计可满足不同计算机软件系统对于运行速度的需求,而且还可充分发挥并实现系统功能。计算机软件性能提高后,系统发出的运行指令在为用户提供信息时也将更加快速有效,软件运行速度自然得以提高。

3、有利于软件故障的减少

加强数据库设计可有效减少软件故障的发生几率,推动计算机软件功能的实现。

参考资料来源:百度百科-数据库设计

数据库设计(Database Design)是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)。

在数据库领域内,常常把使用数据库的各类系统统称为数据库应用系统。

一、数据库和信息系统

(1)数据库是信息系统的核心和基础,把信息系统中大量的数据按一定的模型组织起来,提供存储、维护、检索数据的

功能,使信息系统可以方便、及时、准确地从数据库中获得所需的信息。

(2)数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在。

(3)数据库设计是信息系统开发和建设的重要组成部分。

(4)数据库设计人员应该具备的技术和知识:

数据库的基本知识和数据库设计技术

计算机科学的基础知识和程序设计的方法和技巧

软件工程的原理和方法

应用领域的知识

二、数据库设计的特点

数据库建设是硬件、软件和干件的结合

三分技术,七分管理,十二分基础数据

技术与管理的界面称之为“干件”

数据库设计应该与应用系统设计相结合

结构(数据)设计:设计数据库框架或数据库结构

行为(处理)设计:设计应用程序、事务处理等

结构和行为分离的设计

传统的软件工程忽视对应用中数据语义的分析和抽象,只要有可能就尽量推迟数据结构设计的决策早期的数据库设计致力于数据模型和建模方法研究,忽视了对行为的设计

如图:

三、数据库设计方法简述

手工试凑法

设计质量与设计人员的经验和水平有直接关系

缺乏科学理论和工程方法的支持,工程的质量难以保证

数据库运行一段时间后常常又不同程度地发现各种问题,增加了维护代价

规范设计法

手工设计方

基本思想

过程迭代和逐步求精

规范设计法(续)

典型方法:

(1)新奥尔良(New Orleans)方法:将数据库设计分为四个阶段

SBYao方法:将数据库设计分为五个步骤

IRPalmer方法:把数据库设计当成一步接一步的过程

(2)计算机辅助设计

ORACLE Designer 2000

SYBASE PowerDesigner

四、数据库设计的基本步骤

数据库设计的过程(六个阶段)

1需求分析阶段

准确了解与分析用户需求(包括数据与处理)

是整个设计过程的基础,是最困难、最耗费时间的一步

2概念结构设计阶段

是整个数据库设计的关键

通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型

3逻辑结构设计阶段

将概念结构转换为某个DBMS所支持的数据模型

对其进行优化

4数据库物理设计阶段

为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)

5数据库实施阶段

运用DBMS提供的数据语言、工具及宿主语言,根据逻辑设计和物理设计的结果

建立数据库,编制与调试应用程序,组织数据入库,并进行试运行

6数据库运行和维护阶段

数据库应用系统经过试运行后即可投入正式运行。

在数据库系统运行过程中必须不断地对其进行评价、调整与修改

设计特点:

在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行,相互参照,相互补充,以完善两方面的设计

设计过程各个阶段的设计描述:

如图:

五、数据库各级模式的形成过程

1需求分析阶段:综合各个用户的应用需求

2概念设计阶段:形成独立于机器特点,独立于各个DBMS产品的概念模式(E-R图)

3逻辑设计阶段:首先将E-R图转换成具体的数据库产品支持的数据模型,如关系模型,形成数据库逻辑模式;然后根据用户处理的要求、安全性的考虑,在基本表的基础上再建立必要的视图(View),形成数据的外模式

4物理设计阶段:根据DBMS特点和处理的需要,进行物理存储安排,建立索引,形成数据库内模式

六、数据库设计技巧

1 设计数据库之前(需求分析阶段)

1) 理解客户需求,询问用户如何看待未来需求变化。让客户解释其需求,而且随着开发的继续,还要经常询问客户保证其需求仍然在开发的目的之中。

2) 了解企业业务可以在以后的开发阶段节约大量的时间。

3) 重视输入输出。

在定义数据库表和字段需求(输入)时,首先应检查现有的或者已经设计出的报表、查询和视图(输出)以决定为了支持这些输出哪些是必要的表和字段。

举例:假如客户需要一个报表按照邮政编码排序、分段和求和,你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。

4) 创建数据字典和ER 图表

ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用,而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。

5) 定义标准的对象命名规范

数据库各种对象的命名必须规范。

2 表和字段的设计(数据库逻辑设计)

表设计原则

1) 标准化和规范化

数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式,但Third Normal Form(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说,遵守3NF 标准的数据库的表设计原则是:“One Fact in One Place”即某个表只包括其本身基本的属性,当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点:有一组表专门存放通过键连接起来的关联数据。

举例:某个存放客户及其有关定单的3NF 数据库就可能有两个表:Customer 和Order。Order 表不包含定单关联客户的任何信息,但表内会存放一个键值,该键指向Customer 表里包含该客户信息的那一行。

事实上,为了效率的缘故,对表不进行标准化有时也是必要的。

2) 数据驱动

采用数据驱动而非硬编码的方式,许多策略变更和维护都会方便得多,大大增强系统的灵活性和扩展性。

举例,假如用户界面要访问外部数据源(文件、XML 文档、其他数据库等),不妨把相应的连接和路径信息存储在用户界面支持表里。还有,如果用户界面执行工作流之类的任务(发送邮件、打印信笺、修改记录状态等),那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上,如果过程是数据驱动的,你就可以把相当大的责任推给用户,由用户来维护自己的工作流过程。

3) 考虑各种变化

在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。

举例,姓氏就是如此(注意是西方人的姓氏,比如女性结婚后从夫姓等)。所以,在建立系统存储客户信息时,在单独的一个数据表里存储姓氏字段,而且还附加起始日和终止日等字段,这样就可以跟踪这一数据条目的变化。

字段设计原则

4) 每个表中都应该添加的3 个有用的字段

dRecordCreationDate,在VB 下默认是Now(),而在SQL Server • 下默认为GETDATE()

sRecordCreator,在SQL Server 下默认为NOT NULL DEFAULT • USER

nRecordVersion,记录的版本标记;有助于准确说明记录中出现null 数据或者丢失数据的原因 •

5) 对地址和电话采用多个字段

描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有,电话号码和邮件地址最好拥有自己的数据表,其间具有自身的类型和标记类别。

6) 使用角色实体定义属于某类别的列

在需要对属于特定类别或者具有特定角色的事物做定义时,可以用角色实体来创建特定的时间关联关系,从而可以实现自我文档化。

举例:用PERSON 实体和PERSON_TYPE 实体来描述人员。比方说,当John Smith, Engineer 提升为John Smith, Director 乃至最后爬到John Smith, CIO 的高位,而所有你要做的不过是改变两个表PERSON 和PERSON_TYPE 之间关系的键值,同时增加一个日期/时间字段来知道变化是何时发生的。这样,你的PERSON_TYPE 表就包含了所有PERSON 的可能类型,比如Associate、Engineer、Director、CIO 或者CEO 等。还有个替代办法就是改变PERSON 记录来反映新头衔的变化,不过这样一来在时间上无法跟踪个人所处位置的具体时间。

7) 选择数字类型和文本类型尽量充足

在SQL 中使用smallint 和tinyint 类型要特别小心。比如,假如想看看月销售总额,总额字段类型是smallint,那么,如果总额超过了$32,767 就不能进行计算 *** 作了。

而ID 类型的文本字段,比如客户ID 或定单号等等都应该设置得比一般想象更大。假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。

8) 增加删除标记字段

在表中包含一个“删除标记”字段,这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。

3 选择键和索引(数据库逻辑设计)

键选择原则:

1) 键设计4 原则

为关联字段创建外键。 •

所有的键都必须唯一。 •

避免使用复合键。 •

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

2) 使用系统生成的主键

设计数据库的时候采用系统生成的键作为主键,那么实际控制了数据库的索引完整性。这样,数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点:当拥有一致的键结构时,找到逻辑缺陷很容易。

3) 不要用用户的键(不让主键具有可更新性)

在确定采用什么字段作为表的键的时候,可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。

4) 可选键有时可做主键

把可选键进一步用做主键,可以拥有建立强大索引的能力。

索引使用原则:

索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。

1) 逻辑主键使用唯一的成组索引,对系统键(作为存储过程)采用唯一的非成组索引,对任何外键列采用非成组索引。考虑数据库的空间有多大,表如何进行访问,还有这些访问是否主要用作读写。

2) 大多数数据库都索引自动创建的主键字段,但是可别忘了索引外键,它们也是经常使用的键,比如运行查询显示主表和所有关联表的某条记录就用得上。

3) 不要索引memo/note 字段,不要索引大型字段(有很多字符),这样作会让索引占用太多的存储空间。

4) 不要索引常用的小型表

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

4 数据完整性设计(数据库逻辑设计)

1) 完整性实现机制:

实体完整性:主键

参照完整性:

父表中删除数据:级联删除;受限删除;置空值

父表中插入数据:受限插入;递归插入

父表中更新数据:级联更新;受限更新;置空值

DBMS对参照完整性可以有两种方法实现:外键实现机制(约束规则)和触发器实现机制

用户定义完整性:

NOT NULL;CHECK;触发器

2) 用约束而非商务规则强制数据完整性

采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性;它不能保证表之间(外键)的完整性所以不能强加于其他完整性规则之上。

3) 强制指示完整性

在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。

4) 使用查找控制数据完整性

控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找:国家代码、状态代码等。

5) 采用视图

为了在数据库和应用程序代码之间提供另一层抽象,可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。

5 其他设计技巧

1) 避免使用触发器

触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器,你最好集中对它文档化。

2) 使用常用英语(或者其他任何语言)而不要使用编码

在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码,可以在编码旁附上用户知道的英语。

3) 保存常用信息

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

4) 包含版本机制

在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长,用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。

5) 编制文档

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

采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。

对数据库文档化,或者在数据库自身的内部或者单独建立文档。这样,当过了一年多时间后再回过头来做第2 个版本,犯错的机会将大大减少。

6) 测试、测试、反复测试

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

7) 检查设计

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

以上就是关于管理信息系统的数据库设计包括哪些步骤全部的内容,包括:管理信息系统的数据库设计包括哪些步骤、系统数据库和模型库设计、数据库设计的基本步骤等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/10127181.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-05
下一篇 2023-05-05

发表评论

登录后才能评论

评论列表(0条)

保存