
SQL Server本身就是一个完善的数据库,提供可视化编程,后台完成所有拖放处理 *** 作,不管有没有数据都可以使用,不需要编译。
一个比较合理的数据库设计应该考虑数据的交互性和挖掘能力、处理效率以及日志记录。
建立数据表,注意以下几点:
表建立的时候要有主键和索引,表与表之间要能使用主键相联系,举例说在A表里我做完一次记录要生成一个单号,B表里面是依据单号来做下一个流程,而不是依据记录的每一条数据
取名尽量使用英文+下划线,SQL Server里对汉字需要转码,影响工作效率,按照他的默认编码方式 *** 作有助于提高数据处理速度
建立数据表的列数不要太多,用编码规则来建立逻辑
注意字段存储空间,限制字段长度,少用注释和image
存储过程尽量简洁实用
建立视图,为了别的客户端使用,尽量建立视图,做好完整的数据分析,别的接口程序或者客户端直接就可以拿去使用。做视图注意几点:
多个表 *** 作写在一个视图里,不要嵌套太多视图
连接查询要适当的筛选
跨服务器 *** 作视图,要建立服务器链接表,尽量使用内网链接,把服务器链接表做成查询视图,放在本地服务器数据库里,这样就等同本地 *** 作
视图之间保留连接字段作为主要索引
建立计划作业,有计划地进行数据同步更新和备份标识工作,注意事项:
备份数据尽量放数据库里同步复制
计划任务避开工作高峰期
建立存储过程,记录 *** 作日志,把日志以数据表的形式存储,注意事项:
存储过程对本表 *** 作,不要交互太多表
精简参数数量,注意参数存储空间
对记录修改删除、更新标记的时候尽量使用时间来索引
建立关系图,给表与表之间建立直接关系,整理整体挖掘数据性能。
建立计划更新任务,优化数据库整体性能。
构建相山地区地学空间数据库是在对各类原始数据或图件资料进行整理、编辑、处理的基础上,将各类数据或图形进行按空间位置整合的过程。其工作流程见图 2.1。
图2.1 相山地区多源地学空间数据库构建流程
2.2.1 资料收集
相山地区有 40 多年的铀矿勘查和研究历史,积累了大量地质生产或科学研究资料。笔者收集的面上的资料包括原始的离散数据如航空放射性伽玛能谱数据、航磁数据、山地重力测量数据、ETM 数据,而地面高精度磁测资料仅收集到文字报告和图件。上述各类数据均可达到制作 1∶50000 图件的要求。地质图采用 1995 年核工业 270 研究所等单位共同实施完成的 “相山火山岩型富大铀矿找矿模式及攻深方法技术研究”项目的 1∶50000附图采用的 1∶50000 地形图的情况见表 2.1。
2.2.2 图层划分
GIS 数据库既要存储和管理属性数据和空间数据,又要存储和管理空间拓扑关系数据。数据层原理: 大多数 GIS 都是将数据按照逻辑类型分成不同的数据层进行组织,即按空间数据逻辑或专业属性分为各种逻辑数据类型或专业数据层。相山地区数字化地质图包括地理要素和地质要素两大部分,共设置 9 个图层,每一图层 (包括点、线或多边形) 自动创建与之相对应的属性表。
表2.1 采用的地形图情况一览表
注: 坐标系均为 1954 年北京坐标系,1956 年黄海高程系,等高距为 10 m。
(1) 水系图层 (L6XS01) : 包括双线河流、单线河流、水库或水塘。
(2) 交通及居民地图层 (L6XS02) : 包括公路和主要自然村及名称。
(3) 地形等高线图层 (L6XS03) : 包括地形等高线及高程和山峰高程点。
(4) 盖层图层 (D6XS04) : 包括第四系 (Q) 和上白垩统南雄组 (K2n) 及其厚度和主要岩性。
(5) 火山岩系图层 (L6XS05) : 包括下白垩统打鼓顶组 (K1d) 、鹅湖岭组 (K1e) 及各种浅成- 超浅成侵入体 (次火山岩体) 的分布和主要岩性特征。
(6) 基底图层 (L6XS06) : 含下三叠统安源组 (T3a) 、震旦系 (Z) 、燕山早期花岗岩 (γ5) 、加里东期花岗岩 (γ3) 。
(7) 构造图层 (L6XS07) : 相山地区褶皱构造不发育,构造图层主要包括实测的和遥感影像解译的线性断裂或环形构造。
(8) 矿产图层 (L6XS08) : 包括大、中、小型铀矿床和矿点。
(9) 图框及图幅基本信息图层 (L6XS09) : 数字化地质图的总体描述,内容包括图框、角点坐标、涉及的 1∶500000 标准图幅编号、调查单位及出版年代等。
图层名编码结构如下:
相山铀矿田多源地学信息示范应用
2.2.3 图形输入
图形输入或称图形数字化,是将图形信息数据化,转变成按一定数据结构及类型组成的数字化图形。MapGIS 提供智能扫描矢量化和数字化两种输入方式。本次采用扫描矢量化输入,按点、线参数表事先设定缺省参数,分别将地形底图和地质底图扫描成栅格图像的 TIF 文件,按照图层划分原则,在计算机内分层进行矢量化。线型、花纹、色标、符号等均按 《数字化地质图图层及属性文件格式》行业标准执行。
对于已建立的图层,按点、线、多边形分别编辑修改,结合地质图、地形图及相关地质报告,采集添加有关属性数据,用以表示各图层点、线、多边形的特征。拓扑处理前先将多边形的地质界线校正到标准图框内进行修改,去掉与当前图层区域边界无关的线或点。对于图幅边部不封闭的区域,采用图框线作为多边形的边界线,使图幅内的多边形均成为封闭的多边形。拓扑处理后进行图形数据与属性数据挂接。
在 MapGIS 实用服务子系统误差校正模块中,将数字化地图校正到统一的大地坐标系统中。图形数据库采用高斯-克吕格 (6 度带) 投影系统,椭球参数: 北京54/克拉索夫斯基。
MapGIS 数据文件交换功能使系统内部的矢量图层很容易实现 Shape 和 Coverage 等文件格式的转换。在图形处理模块将上述各图层转成 Shape 文件格式。
2.2.4 离散数据网格化
在收集的原始资料中,除 1∶50000 地形图和地质图之外,航空放射性伽玛能谱数据(包括原始的和去条带处理后的数据) 、航磁数据、山地重力测量数据都是离散的二维表格数据。用 GeoExpl 网格化。GeoExpl 数据处理与分析系统提供了多种网格化计算的数学方法,本次选用克立格插值方法,网格间距 15 m。重力和航磁数据网格化后,进行不同方向或不同深度的延拓处理。所有网格化数据均采用了与上述图形数据相同的地图投影和坐标系统。
2.2.5 网格化数据影像化
MapGIS 网格化文件格式为 grd,可直接被 Erdas Imagine 读取,GeoExpl 网格化文件包括重磁处理反演后的网格化文件可转换成 Surfer.grd 后,被 Erdas Imagine 读取。然后将上述网格化数据一一转成 img 影像数据格式。
2.2.6 DEM 生成
地形等高线 (L6XS03) 文件在 MapGIS 空间分析子系统 DEM 分析模块中,生成 DEM栅格化文件: L6XS03.grd,再转成 img 格式,文件名改为: XSDEM。
经过上述程序形成的各类矢量或栅格数据,在 ArcView 平台建立 “相山数据库”工程文件,将上述各 Shape 图形和 img 影像文件一一添加到该工程文件中。该工程文件即为相山地区矢量、栅格一体化地学空间数据库。该数据库,一可以对这类地学空间信息实现由 GIS 支持的图层管理,二可以视需要不断进行数字—图形—图像的转换,三可以将多源地学信息进行叠合和融合,以实现多源地学信息的深化应用和分析,为实现相山地区铀资源数字勘查奠定基础。
简述数据库设计过程—希望可以帮你数据库设计(Database Design)是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)。
在数据库领域内,常常把使用数据库的各类系统统称为数据库应用系统。
一、数据库和信息系统
(1)数据库是信息系统的核心和基础,把信息系统中大量的数据按一定的模型组织起来,提供存储、维护、检索数据的
功能,使信息系统可以方便、及时、准确地从数据库中获得所需的信息。
(2)数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在。
(3)数据库设计是信息系统开发和建设的重要组成部分。
(4)数据库设计人员应该具备的技术和知识:
数据库的基本知识和数据库设计技术
计算机科学的基础知识和程序设计的方法和技巧
软件工程的原理和方法
应用领域的知识
二、数据库设计的特点
数据库建设是硬件、软件和干件的结合
三分技术,七分管理,十二分基础数据
技术与管理的界面称之为逗干件地
数据库设计应该与应用系统设计相结合
结构(数据)设计:设计数据库框架或数据库结构
行为(处理)设计:设计应用程序、事务处理等
结构和行为分离的设计
传统的软件工程忽视对应用中数据语义的分析和抽象,只要有可能就尽量推迟数据结构设计的决策早期的数据库设计致力于数据模型和建模方法研究,忽视了对行为的设计
如图:
三、数据库设计方法简述
手工试凑法
设计质量与设计人员的经验和水平有直接关系
缺乏科学理论和工程方法的支持,工程的质量难以保证
数据库运行一段时间后常常又不同程度地发现各种问题,增加了维护代价
规范设计法
手工设计方
基本思想
过程迭代和逐步求精
规范设计法(续)
典型方法:
(1)新奥尔良(New Orleans)方法:将数据库设计分为四个阶段
S.B.Yao方法:将数据库设计分为五个步骤
I.R.Palmer方法:把数据库设计当成一步接一步的过程
(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) 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说,针对每一种最终表达数据的原型应用,保证你检查了数据模型并且查看如何取出数据。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)