文档库 最新最全的文档下载
当前位置:文档库 › 1.数据库设计和编码规范

1.数据库设计和编码规范

1.数据库设计和编码规范
1.数据库设计和编码规范

设计规范文档

数据库设计和编码规范

Version 1.0

目录

1简介 (4)

1.1读者对象 (4)

1.2目的 (4)

2数据库命名规范 (4)

2.1规范总体要求 (4)

2.2数据库对象命名规范 (5)

2.3变量命名规范 (6)

3数据库设计规范 (6)

3.1选择有效的设计工具 (7)

3.2表的设计 (7)

3.2.1遵守范式要求 (7)

3.2.2字段设计 (8)

3.2.3适当的合理的冗余 (9)

3.2.4注意大类型的字段设计 (10)

3.3表关系和约束设计 (10)

3.3.1主键设计 (11)

3.3.2 外键设计 (12)

3.3.3 检查约束 (12)

3.4索引的设计 (13)

3.4.1聚集索引和非聚集索引 (13)

3.4.2索引的初始创建原则 (15)

3.4.3索引的注意事项 (15)

3.4.4索引的后期维护工作 (16)

3.5物理存储设计 (17)

3.5.1日志文件另外存放 (17)

3.5.2存储空间的设计 (17)

4T-SQL编码规范 (18)

4.1书写基本规范 (19)

4.2使用可搜索参数(WHERE使用原则) (20)

4.3少用触发器和禁用游标 (21)

4.4联合查询尽可能使用UNION ALL (22)

4.5尽可能避免的地方 (22)

4.6避免返回和使用多余的数据 (23)

4.7操作符优化 (23)

4.8数据库事务处理原则 (24)

4.9最少次数的访问表 (25)

4.10避免隐含的数据类型转换 (25)

4.11表变量、临时表和公用表达式的用法 (27)

4.12正确地判断记录是否存在 (29)

4.13注意自定义标量函数的影响 (29)

4.14避免编写复杂的TSQL语句 (30)

4.15应用程序层防止执行大块的TSQL语句 (30)

4.16对数据库大表的处理方案 (31)

4.17SP_EXECUTESQL代替EXEC (32)

4.18存储过程的一些建议 (33)

5如何进行质量控制 (33)

5.1规范的制定、认可和实施 (33)

5.2讨论和检查工作 (33)

5.3对制定的规范不断完善 (34)

5.4讨论和制定公共模板 (34)

5.4.1SELECT语句 (35)

5.4.2JOIN语句 (35)

5.4.3子查询 (36)

5.4.4INSERT语句 (36)

5.4.5UPDA TE语句 (36)

5.4.6DELETE语句 (36)

5.4.7CASE语句 (37)

5.4.8IF语句 (37)

5.4.9WHILE语句 (37)

5.4.10EXISTS语句 (37)

5.4.11变量声明 (38)

5.4.12变量赋值 (38)

5.4.13创建表及约束索引 (38)

5.4.14存储过程 (39)

5.4.15带输出参数的存储过程 (40)

5.4.16视图 (41)

5.4.17物化视图 (41)

5.4.18自定义标量函数 (42)

5.4.19自定义表值函数(多语句) (42)

5.4.20自定义表值函数(内联) (43)

5.4.21索引整理 (44)

5.4.22数据库事务格式 (44)

1简介

1.1 读者对象

此文档说明书供开发部全体成员阅读。

1.2 目的

一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错,保持团队支持顺畅,系统长久使用后不至于紊乱,让管理者易于在众多对象中,获取所需或理清问题。

同时,定义标准程序也需要团队合作,讨论出大家愿意遵循的规范。随着时间演进,还需要逐步校订与修改规范,让团队运行更为顺畅。

2数据库命名规范

团队开发与管理信息系统讲究默契,而制定服务器、数据库对象、变量等命名规则是建立默契的基本。

命名规则是让所有的数据库用户,如数据库管理员、程序设计人员和程序开发人员,可以直观地辨识对象用途。而命名规则大都约定俗成,可以依照公司文化、团队习惯修改并落实。

2.1 规范总体要求

1.避免使用系统产品本身的惯例,让用户混淆自定义对象和系统对象或关键词。例如,

存储过程不要以sp_或xp_开头,因为SQL SERVER的系统存储过程以sp_开头,扩展存储过程以xp_开头。

2.不要使用空白符号、运算符号、中文字、关键词来命名对象。

3.名称不宜过于简略,要让对象的用途直观易懂,但也不宜过长,造成使用不方便。

4.不用为数据表内字段名称加上数据类型的缩写。

5.名称中最好不要包括中划线。

6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。

2.2 数据库对象命名规范

我们约定,数据库对象包括表、视图(查询)、存储过程(参数查询)、函数、约束。对象名字由前缀和实际名字组成,长度不超过30。避免中文和保留关键字,做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串,而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范,通过后严格按照要求实施。例如:

2.3 变量命名规范

1.数据列参数

命名格式为@+[列名称]。

示例:@EmployeeID @employee_id

2.非数据列参数

在参数无法跟列名称进行关联时,使用能够反映该参数功能的英文单词或单词组合,采用Pascal样式命名。

示例:@WorkType @work_type

3数据库设计规范

好的数据库架构设计对系统运行的性能起着很大的作用,所以要在开始时就要引起重视。为了保证数据库设计的高效必须安排时间对设计结果进行评审,这一环节必不可少。

3.1 选择有效的设计工具

数据库设计工具:Power Designer、ER Studio、Rose、Microsoft Visio。

项目开始前要确定使用哪种设计工具。(另有开发插件:RedGate系列(SQL Prompt)) 选择的工具要便于讨论便入生成脚本导入数据库。

设计通过后要形成文档,并且这个结构设计文档要存档,签入VSS基线库中。

在进行数据库设计时,应随时进行数据字典的维护。(字段要求写说明)

3.2 表的设计

表设计在数据库设计中占据有十分重要的地位。表是实际存储数据的对象。除了要注重表结构设计,字段的设计之外还要注意表之间关系的设计。

3.2.1遵守范式要求

通常,合理的规范化会最小化数据异常和减少数据的冗余。为了更新数据的正确与快速,在设计的初始阶段多采用三范式设计数据库表。

第一范式强调的是列的原子性,即列不能够再分成其他几列。

第二范式包含两层意思,一是表必须有一个主键;二是非主键列必须完全依赖于主键,且不能只依赖于主键的一部分。(尽量少使用复合主键)

第三范式需要确保数据表中的所有非主键列直接与主键列相关,而不能直接依赖于非主键列。

3.2.2字段设计

1.尽量避免可为空的列。

虽然在个别情况下,允许空值可能是有用的,但是应尽量少用。这是因为需要对它们进行特殊处理,从而会增加数据操作的复杂性和增加CPU额外的逻辑判断。很多情况下可以考虑用默认值0或空字符串('')来代替NULL值。所以字段应该有NOT NULL的限制。

2.Unicode的选择。

nvarchar和nchar相应比varchar和char要占用更多的存储空间。设计的原则是:如果确保存储的内容只是纯英文和数字,用char/varchar。如果含有中文字符或其它多国语言,用nchar/nvarchar。

3.字段长度要精确,遵守“必须、够用”的原则。

精确的长度设计既能完整的描述数据,又可以节省存储空间。积小成大,当数据表中的数据有很多记录的时候,这种存储空间的优势就能体现得十分明显。存储空间越紧凑,分配的页面就越少,在同样大小的内存空间中就可以存储更多的页面,这样操作数据的效率就会提高。例如能用char(10)的就不要用char(20),提高存储的利用率和系统性能,但同时也要兼顾扩展性和可移植性。

3.2.3适当的合理的冗余

降低范式标准的一个重要原因是为了在检索数据时少连接表从而提供一个性能优势。或是预先汇总计算结果并存放起来,或是将相同字段内容一式多份地放在多个表中,这样数据的冗余会增加开发人员的工作量和业务判断。(最好是对有冗余的字段要另外用文档统一说明)

完全按照规范化设计的系统几乎是不可能的,除非系统特别的小,在规范化设计后,有计划地加入冗余是必要的。冗余可以是冗余数据库、冗余表或者冗余字段,不同粒度的冗余可以起到不同的作用。冗余可以是为了编程方便而增加,也可以是为了性能的提高而增加。从性能角度来说,冗余数据库可以分散数据库压力,冗余表可以分散数据量大的表的并发压力,也可以加快特殊查询的速度,冗余字段可以有效减少数据库表的连接,提高效率。

数据库设计阶段,对必要的冗余处理可以事先安排设计,如果在代码实现阶段发现一些

必要的冗余字段可以及早提出来考虑。

3.2.4注意大类型的字段设计

如果设计过程中发现表中存在大类型(可存储2G)的字段时,要慎重考虑,因为这样的字段会造成单一数据页存放不了几条记录。而过多的页面也会在查询扫描时带来性能影响。

一般的做法是将XML、IMAGE、VARCHAR(MAX)、NVARCHAR(MAX)或TEXT类型的字段切割到另外的数据表,而后与主数据表一对一连接。因为这些大型数据访问缓慢,修改时可能造成记录锁定较久。且在大多数的使用状态下,查询一般字段内容时可能根本用不到这些字段。这些列的存在会增加表的页面数,不分割出去容易会影响其它字段的修改和查询。

VARCHAR(MAX)、NVARCHAR(MAX)字段如果实际长度在8000以下,这个值将被作为常规的变长数据类型来对待,如果超过8000个字节,SQL Server将该值作为TEXT 来存储处理。如果该表数据量比较大时,一定要考虑大字段分离设计原则。

少用TEXT和IMAGE,二进制字段的读写是比较慢的。

3.3 表关系和约束设计

正确处理表间关系。一对多、一对一、多对多等关系。主外键关系是保证数据完整性的一个重要机制。维护数据的正确性。尽量采用提供的约束,如主外键、检查、默认值、不可NULL等。尽可能不要通过程序或存储过程、触发器等机制来运行,毕竟SQL SERVER约束是在内部以优化过的二进制程序代码来实现的,而其它方式效率当然不如直接设置的约束高。还有,能够确定具有唯一值的字段上尽量加上唯一性约束。

一些约束在客户端判断的确是可以减少服务器的资源,但是不能完全保证数据的错误产

生。而且用数据库使用域和参照完整性有时候还能帮助优化器减少查询执行时间。域和参照完整性帮助优化器分析有效的数据值而不需要物理访问数据,这减少了查询时间。

3.3.1主键设计

所有的表必须设置主键。主键跟聚焦索引没有什么关系,但主键必须要有索引。主键的选择原则:

1.字段值唯一。

2.不可NULL。

3.字段大小尽量最小。

4.字段值不常变更。

5.不建议用复合主键。

主健值过大会影响外健数据表的大小。如果主键是聚集索引,由于所有非聚集索引都会存储聚集索引的键值,所以主键值过大,还将导致其他索引结构的效率不佳(页面数)。

主键关乎着数据的正确性与完整性。而聚焦索引是从数据的运行效率出发。虽然主键跟聚集索引是两回事,但基于主键的上述特性,所以主键往往适合作为表的聚集索引,这也是微软的默认做法。但一些没有意义的ID做聚集索引的意义不大,这时候需要在创建表的时候给主键指定为唯一的非聚集索引。

-- 主键约束(非聚集索引):

ALTER TABLE[dbo].[TCustomer]ADD CONSTRAINT PK_TCustomer PRIMARY KEY NONCLUSTERED (ID);

选择GUID做为主键时在系统对接、移值和代码编写下都提供了很大的方便,但它是建立在牺牲性能的基础上。

在实际运用中,如果对于用36字符的GUID当作主键时,应当注意的问题如下:

1.GUID是无序的,所以不适合用来做聚集索引。否则会引起频繁的页面移动而产生

大量的碎片。

2.GUID类型的存储可以由char(36)改为uniqueidentifier类型(16个字节),以节

省存储空间。

3.对于有关联的表之间,考虑程序方便可用使用GUID做为主键,但对于独立的表,

还是以INT类型的字段做为主键来设计。所以设计阶段要分清哪些必须用GUID来做主键。

3.3.2 外键设计

外键的存在会在处理数据时带来麻烦,但实际上这点恰恰是它的好处。外键的存在就最高效的一致性维护方法。所以在表设计时要考虑主外键的设计。如果决定使用外键约束,那么所有人必须遵守严格执行。外键是最高效的一致性维护方法,数据库的一致性要求,依次可以用外键、CHECK约束、规则约束、触发器、客户端程序,一般认为,离数据越近的方法效率越高。

3.3.3 检查约束

约束除了主外键约束、唯一性约束和默认值约束外,还有一类叫检查约束。

检查约束是一个识别SQLServer表中每行可接受的列值的规则,检查约束帮助实施域的完整性,域完整性定义了数据库表中列的有效值,检查约束可以验证单列的域完整性,也可以验证多列的域完整性,在单个列上可以有多个检查约束,如果插入或更新的数据违反了检查约束,数据库引擎将暂时停止INSERT和UPDATE操作。

CREATE TABLE dbo.TEmployee(

ID INT,

Code VARCHAR(20),

Sex CHAR(1)CONSTRAINT Text_Sex_CK CHECK (Sex ='F'OR Sex ='M'),

-- Sex列创建相应的约束,其值只能是'F'或'M'值。

Experience INT CONSTRAINT Text_Experience_CK CHECK (Experience >= 0)

-- Experience列创建相应的约束,其值必须>=0

);

3.4 索引的设计

索引是一把双刃剑,它通常可以加快数据检索数据的同时,往往又会带来额外的资源开销(在insert、update和delete使用时)。有时候这个开销代价甚至超过了查询优化带来的好处。所以,索引的创建是门艺术,要在工作中不断的积累经验和不断的总结。一般来说,建立索引要看数据使用的方式,也就是说那些访问数据的SQL语句经常使用,针对这些经常使用的SQL语句创建有效的索引还是值得的,但过多的索引又是对于OLTP(在线事务)数据库是不利的。

3.4.1聚集索引和非聚集索引

每个表只能有一个聚集索引,因为目录只能按照一种方法进行排序。

聚集索引和数据是混为一体的,而非聚集索引是与数据独立分开的。

其实,我们的汉语字典的正文本身就是一个聚集索引。比如,我们要查“安”字,就会很自然地翻开字典的前几页,因为“安”的拼音是“an”,而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的,那么“安”字就自然地排在字典的前部。同样的,如果查“张”字,那您也会将您的字典翻到最后部分,因为“张”的拼音是“zhang”。也就是说,字典的正文部分本身就是一个目录,您不需要再去查其他目录来找到您需要找的内容。

我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。

如果您认识某个字,您可以快速地从自典中查到这个字。但您也可能会遇到您不认识的字,不知道它的发音,这时候,您就不能按照刚才的方法找到您要查的字,而需要去根据“偏旁部首”查到您要找的字(非聚集索引查找),然后根据这个字后的页码直接翻到某页来找到您要找的字(书签查找)。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法,比如您查“张”字,我们可以看到在查部首之后的检字表中“张”

的页码是672页,检字表中“张”的上面是“驰”字,但页码却是63页,“张”的下面是“弩”字,页面是390页。很显然,这些字并不是真正的分别位于“张”字的上下方,现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序,是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字,但它需要两个过程,先找到目录中的结果,然后再翻到您所需要的页码。

通过以上例子,我们可以理解到什么是“聚集索引”和“非聚集索引”。

-- 聚集索引查找,没有书签查找开销

SELECT*FROM [dbo].[TOrder]

WHERE OrderID = 1

ORDER BY OrderID;

-- 非聚集索引查找

SELECT UserID,OrderID FROM [dbo].[TOrder]

WHERE UserID = 1

ORDER BY UserID;

-- 非聚集索引查找+书签查找

SELECT UserID,OrderID,OrderPrice FROM [dbo].[TOrder]

WHERE UserID = 1

ORDER BY UserID;

3.4.2索引的初始创建原则

如果处在数据库项目的开始,而且不确定如何对索引建模,可以使用不加思考或默认索引模式作为开始。一旦能够根据实际事务信息重新评估数据库后,再调整索引。所以在系统的初始上线阶段一般只考虑创建最少的、最必要的索引。

1. 所有表要有聚集索引,如果没有合适的字段,那么暂时在主键上创建聚集索引。

2. 所有外键上创建索引。

3. 可预知的用来频繁查找的字段上创建索引。

4. 小表可以不需要特意去创建索引。有主键就好。

3.4.3索引的注意事项

1.一个经常插入更新的表不要加太多索引,因为索引影响插入和更新的速度。

2.所有非聚集索引包含聚集索引键值,创建非聚集索引时不要再包含进来。

3.如果知道索引键的所有值都是唯一的,那么确保把索引定义成唯一索引。唯一索引除了

可以保证数据的正确性外还可能帮助优化器生成更高效的执行计划。因为在唯一索引中每行都是唯一的,一旦找到一行,SQL Server不必进一步查找其他匹配的行。

4.索引不只是带来查询优化,对于更新操作,索引有时候优化查询带来的好处会超过索引

维护的开销。所以索引有某些情况下会缩短整个数据更新的时间。因为有时候,表扫描带来的开销会远大于更新操作本身的开销。(先查找后更新)

5.尽可能地选择那些小数据类型的列来创建索引,大的索引键值增加了索引页面的数量,

从而增加了索引所需要的内存和磁盘活动数量。

6.经常有范围查询(between,> , <,> =, <=)或用来作条件返回很多列和order by、

group by发生的列,可考虑建立聚集索引;(分区字段是时间类型的话,适合聚集索引)

7.非聚集索引在需要从一个大表上读取少量的行时最有用。当匹配返回的记录数过多时,

需要用到的书签查找(键查找)的开销将会变得很大。所以像性别这样的字段不要创建非聚集索引。低选择性的列只能配合其它字段创建复合非聚集索引。

8.多个字段创建组合索引时要尽量使关键查询形成索引覆盖,其第一个列一定是使用最频

繁的列;但包含的列不能太多,不能有大类型的字段。

9.缺乏合适的索引也是造成阻塞、死锁的原因。

10.频繁更新的列不适合创建聚集索引。

11.主键就是聚集索引,极端错误的,是对聚集索引的一种浪费。虽然SQL SERVER默认是

在主键上建立聚集索引的。显而易见,聚集索引的优势是很明显的,而每个表中只能有一个聚集索引的规则,这使得聚集索引变得更加珍贵。使用聚集索引的最大好处就是能够根据查询要求,迅速缩小查询范围,避免全表扫描。(尤其是分区表,适合时间做聚集索引)

3.4.4索引的后期维护工作

索引创建后不就是完事了的,一定要定期观察索引在实际工作环境中的使用情况。及时阻止索引对系统带来的负面影响。总的来说应该考虑如下几点:

1.去掉使用率低的索引。

2.合理的改善索引,使索引更有效的被利用到。

3.创建缺失的必要的索引。

4.考虑索引碎片的问题。索引碎片率过大时,查询得不到优化。

由于表上有过度地插入、修改和删除操作,索引页被分成多块就形成了索引碎片,如果索引碎片严重,那么扫描索引的时间就会变长,甚至导致索引不可用,因此数据检

索操作就慢下来了。如果碎片小于10%~20%,碎片不太可能会成为问题,如果索引碎片在20%~40%,碎片可能成为问题,但是可以通过索引重组来消除索引解决,大规模的碎片(当碎片大于40%),可能要求索引重建。

-- 查看某个表的碎片情况(整理数据的碎片,是整理聚集索引的碎片)

-- 结果看LogicalFramentation字段

DBCC SHOWCONTIG('[dbo].[TLog]')WITH FAST,TABLERESULTS,ALL_INDEXES,NO_INFOMSGS;

总之,索引的后期跟踪是不断持续的过程。为了搭建高性能的系统环境,就必须定期有效的跟踪索引。

GaeaRec索引.xlsx

3.5 物理存储设计

除了重视逻辑对象的设计,还需要考虑数据库的物理设计。在并发要求很高、并发用户数很多的情况下,这一设计对数据库的性能起到十分关键的作用。

数据库物理文件一般不要存放在C盘,因为系统重装对C盘破坏最大。

3.5.1日志文件另外存放

查询数据库的页,可以看到,由于页的ID不连续,所以数据文件内部的读写是随机的。而日志文件的读写是顺序的,所以两者放在同一个硬盘上,会造成硬盘驱动器一会随机,一会顺序,效率会比较低。将数据文件和日志分离存储在不同的物理硬盘上。这样的好处是确保数据的安全,避免单点失效。二是确保数据库的性能。同样备份文件也在不同的磁盘上。

3.5.2存储空间的设计

正确评估和测算数据库的物理空间需求。因为数据库采用预先分配存储空间的方法。存储空间的分配操作是一个非常消耗资源的操作。所以设计人员需要评估数据空间的可能增长

率,将数据库的空间增长方式设置为恰当好处,这样就可以在空间和效率之间取得均衡。

设计要考虑的内容有:

1.数据库文件和日志文件初始值的设计。

2.数据库文件和日志文件以多大的比例增长。(不要用默认的1M或10%)要设置成

按固定大小增长,这样就能避免一次增长太多或者太少所带来的不必要的影响。建

议对比较小的数据库,设置一次增长50 MB到100 MB。对大的数据库,设置一

次增长200 MB到800 MB。

3.对于生产数据库,推荐的设置是开启数据库自动增长和不限制大小,以防数据库空

间用尽导致应用程序失败。

4.在系统一段时间稳定后,可以采取日志备份的机制使得数据库日志文件大小固定下

来,不再持续增长。事务日志备份可以截断日志,在检查点发生时会清空日志,这样会在已有的空间内重新记录日志,而不用分配新的空间。

5.分配空间和压缩空间都很带来很大的资源开销,所以尽量避免数据库进行这两个操

作。比如对日志文件截断后不要使用收缩空间的操作,如果一定要收缩那么收缩到

一个合适的值,这样避免日志文件重新分配空间。(不要收缩到最小空间,比如1M)

6.不要开启数据库的自动关闭和自动收缩选项。

4T-SQL编码规范

在设计确定的情况下,编码的质量几乎决定了整个系统的质量。编码阶段首先是需要所

有程序员有性能意识,也就是在实现功能同时有考虑性能的思想。

编写规范的SQL语句不但利于阅读,而且被数据库重复使用的几率也较大,执行效率相对较高,编写的好的SQL与编写的差的SQL在执行性能上可能会差几倍甚至几千几万倍,因此养成好的SQL编写规范对于提高项目质量及提高开发人员自身素质有着潜在的极大的影响。

4.1 书写基本规范

1.大小写规则。

为了最大限度实现SQL的共享,要求书写SQL语句时大小写要一致,(比如保留关键字、谓词和系统函数一律大写)这样做的好处有两点:一是为了阅读方便。二是不统一的语句由于写法不完全相同,数据库会理解为4条不同的语句从而导致重复编译,降低了性能。系统对象(系统存储过程、视图、表,系统字段),按照系统定义的大小写执行(数据库里怎么定义就怎么引用);数据库对象名称,按照实际定义的大小写执行(数据库里怎么定义就怎么引用)

2.养成注释的好习惯。

存储过程、函数、视图、触发器等对象不仅要求创建时加上必要的注释,而且在以后修改的过程中也应该有注释。注释最好以英文为主,尽可能做到简洁而描述清晰。另外表也可以加上注释说明。

3.有结束符。

每一个完整的T-SQL语句都要以分号结束。据说在以后的数据库版本里面会强制要求。现在的版本,在公用表达式的编写中,就有这个限制。

4.所有的赋值语句要求变量与运算符之间要有空格。如:v_count = v_count + 1;,

并保持适当的对齐。

5.引用对象时带上架构名。这也是比较推荐的写法。默认的架构名为dbo。在创建物

化视图是就深有体会。

6.以内缩来标示IF、WHILE、BEGINEND、TRY CACHE等程序代码区域。

7.在SQL代码快中尽量使用BEGIN…END 语句块,提高代码可阅读性。

8.在多表连接时,尽量用表别名+字段的格式来返回列。

9.换行规则。BEGIN/END独占一行;FROM子句独占一行;WHERE子句独占一行;

GROUP BY 子句独占一行;ORDER BY 子句独占一行;单独的LEFT JOIN 和

INNER JOIN 独占一行;如果一行写不完换行时,需要确保每行逻辑完整性。4.2 使用可搜索参数(where使用原则)

建立索引后,并不是每个查询都会使用索引,在使用索引的情况下,索引的使用效率也会有很大的差别。只要我们在查询语句中没有强制指定索引,索引的选择和使用方法是SQLSERVER的优化器自动作的选择,而它选择的根据是查询语句的条件以及相关表的统计信息,这就要求我们在写SQL语句的时候尽量使得优化器可以使用索引。

为了使得优化器能高效使用索引,写语句的时候应该注意下面四点:

1.不要对索引字段进行运算,而要想办法做变换。

2.不要对索引字段进行格式转换。

3.不要对索引字段使用函数。

4.不要对索引字段进行多字段连接。

所以在where条件语句中有时候一些不规范的写法会造成索引失效。右边的写法要优

数据仓库模型的设计

2.5数据仓库模型的设计 数据仓库模型的设计大体上可以分为以下三个层面的设计151: .概念模型设计; .逻辑模型设计; .物理模型设计; 下面就从这三个层面分别介绍数据仓库模型的设计。 2.5.1概念模型设计 进行概念模型设计所要完成的工作是: <1>界定系统边界 <2>确定主要的主题域及其内容 概念模型设计的成果是,在原有的数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合,所以数据仓库的概念模型设计,首先要对原有数据库系统加以分析理解,看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等,然后再来考虑应当如何建立数据仓库系统的概念模型。一方面,通过原有的数据库的设计文档以及在数据字典中的数据库关系模式,可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面,数据仓库的概念模型是面向企业全局建立的,它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。 概念模型的设计是在较高的抽象层次上的设计,因此建立概念模型时不用考虑具体技术条件的限制。 1.界定系统的边界 数据仓库是面向决策分析的数据库,我们无法在数据仓库设计的最初就得到详细而明确的需求,但是一些基本的方向性的需求还是摆在了设计人员的面前: . 要做的决策类型有哪些? . 决策者感兴趣的是什么问题? . 这些问题需要什么样的信息? . 要得到这些信息需要包含原有数据库系统的哪些部分的数据? 这样,我们可以划定一个当前的大致的系统边界,集中精力进行最需要的部分的开发。因而,从某种意义上讲,界定系统边界的工作也可以看作是数据仓库系统设计的需求分析,因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。 2,确定主要的主题域 在这一步中,要确定系统所包含的主题域,然后对每个主题域的内

数据库设计规范范本

数据库设计规范

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),提高存储的利用率和系统性能,但同时也要兼顾扩展性和可移植性。 易用性:数据库设计清晰易用,用户和开发人员均能容易地理解。

软件工程-数据库设计规范与命名规则

数据库设计规范、技巧与命名规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指:对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据, 满足用户信息要求和处理要求。 数据库设计的各阶段: 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模型的步骤如下所示:

标准规范体系建设方案设计

标准规范体系建设方案设计 1.1需求分析 1.1.1采购范围与基本要求 收集智慧园区建设涉及的国家标准、行业标准、管理规范、技术标准和信息标准,编写XX高新区开发区智慧园区的接口规范、信息交换标准、元数据标准等。1.1.2建设内容要求 (1)编写 《XX高新区开发区智慧园区元数据信息标准》 《XX高新区开发区智慧园区数据代码规范目录》 《XX高新区开发区智慧园区数据交换方式》 《XX高新区开发区智慧园区数据交换内容标准》 《XX高新区开发区智慧园区数据接口标准》 《XX高新区开发区智慧园区数据采集规范》 《XX高新区开发区智慧园区数据处理规范》 《XX高新区开发区智慧园区数据质量规范》 《XX高新区开发区智慧园区数据管理制度》 《XX高新区开发区智慧园区系统运维管理规范》 《XX高新区开发区智慧园区文档管理制度》 《XX高新区开发区智慧园区运营管理标准》 (2)收集 (住建部智慧城市文件(2013年4月) 《智慧城市公共信息平台建设指南(试行)》 《智慧城市评价模型及基础评价指标体系》(全国通信标准化技术委员会) 《基于云计算的电子政务公共平台顶层设计指南》(工信部,2013年4月) 《政务信息资源目录体系》(GB/T21063-2007) 《政务信息资源交换体系》(GB/T21062-2007) 《信息技术大数据术语》(20141191-T-469) 《信息技术大数据参考架构》(20141191-T-469)

《关系数据管理系统技术要求》(GB/T28821-1012) 《城市基础地理信息系统技术规范》 《关于促进智慧城市健康发展的指导意见》 《关于积极推进“互联网+”行动的指导意见》 《促进大数据发展行动纲要》 《国家信息化发展战略纲要》 《国家电子政务工程建设项目管理暂行办法》 《国家信息化领导小组关于我国电子政务建设指导意见》 《国家电子政务总体框架》 《城市地下管线工程档案管理办法》(住建部2005年) 《城市地下空间开法利用管理规定》(建设部59号、第108号) 《电信建设管理办法》(国发委第20号) 《2006—2020年国家信息化发展战略》 1.2设计方案 XX高新区智慧园区是一个大规模的建设工程。该工程以业务系统的相关数据为业务处理核心,以其它相关部门为信息交换对象,实现跨机构的大型综合与分布式的信息化系统。 面对这样一个大型的信息系统,XX高新区智慧园区建设首先必须建立完善的标准体系和相关制度。保障XX高新区智慧园区生态XX高新区智慧园区建设标准的可持续发展能力,实现真正意义上的互联互通。 1.2.1标准在系统建设中的作用 XX高新区智慧园区建设与标准规范建设是相辅相成的。一方面,生态XX高新区智慧园区各项内容的建设必须遵循标准和规范,其设计、开发和实施等需要标准和规范进行指导;另一方面,标准和规范的制订和维护离不开生态XX高新区智慧园区的建设实践,标准和规范必需符合实际需求,随着生态XX高新区智慧园区建设的不断建设和推广,标准和规范也要根据生态XX高新区智慧园区建设的进展不断完善。 没有规矩不成方圆,生态XX高新区智慧园区及其配套体系的建设需要相应的标准和规范进行指导。标准和规范具有以下指导作用:

数据库表及字段命名、设计规范

数据库表及字段命名、设计规范1、命名规范 1.1数据表的命名规范: 1)表的前缀应该用系统或模块的英文名的缩写(全部大写或首字母大写)。如果系统功能简单,没有划分为模块,则可以以系统英文名称的缩写作为前缀,否则以各模块的英文名称缩写作为前缀。例如:如果有一个模块叫做BBS(缩写为BBS),那么你的数据库中的所有对象的名称都要加上这个前缀:BBS_ + 数据库对象名称,BBS_CustomerInfo标示论坛模块中的客户信息表。 2)表的名称必须易于理解,使用能表达表功能的英文单词或缩写英文单词,无论是完整英文单词还是缩写英文单词,单词首字母必须大写。如果当前表可用一个英文单词表示的,请用完整的英文单词来表示;例如:系统资料中的客户表的表名可命名为:SYS_Customer。如果当前表需用两个或两个以上的单词来表示时,尽量以完整形式书写,如太长可采用两个英文单词的缩写形式;例如:系统资料中的客户物料表可命名为:SYS_CustItem。 3)表的名称一般使用名词或者动宾短语 4)表名称不应该取得太长(一般不超过三个英文单词)。 5)在命名表时,用单数形式表示名称。例如,使用Employee,而不是Employees。 6)对于有主明细的表来说。明细表的名称为:主表的名称+ 字符Dts。例如:采购定单的名称为:PO_Order,则采购定单的明细表为:PO_OrderDts 对于有主明细的表来说,明细表必须包含两个字段:主表关键字、SN,SN字段的类型为int 型,目的为与主表关键字联合组成明细表的关键字,以及标示明细记录的先后顺序,如1,2,3……。 7)表必须填写描述信息

数据库表字段命名规范

数据库表字段命名规范 摘要:当前研发工作中经常出现因数据库表、数据库表字段格式不规则而影响开发进度的问题,在后续开发使用原来数据库表时,也会因为数据库表的可读性不够高,表字段规则不统一,造成数据查询,数据使用效率低的问题,所以有必要整理出一套合适的数据库表字段命名规范来解决优化这些问题。 本文是一篇包含了数据库命名、数据库表命名、数据库表字段命名及SQL语言编码的规范文档,针对研发中易产生的问题和常见错误做了一个整理和修改,为日后涉及到数据库相关的研发工作做好准备。 一、数据库命名规范 采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成,命名简洁明确,多个单词用下划线'_'分隔,一个项目一个数据库,多个项目慎用同一个数据库 二、数据库表命名规范 2.1数据表命名规范 (1)采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成,命名简洁明确,多个单词用下划线'_'分隔 (2)全部小写命名,禁止出现大写 (3)禁止使用数据库关键字,如:name,time ,datetime,password等(4)表名称不应该取得太长(一般不超过三个英文单词)

(5)表的名称一般使用名词或者动宾短语 (6)用单数形式表示名称,例如,使用employee,而不是employees 明细表的名称为:主表的名称+字符dtl(detail缩写) 例如:采购定单的名称为:po_order,则采购定单的明细表为:po_orderdtl (7)表必须填写描述信息(使用SQL语句建表时) 2.2命名规范 ①模块_+功能点示例:alllive_log alllive_category ②功能点示例:live message ③通用表示例:all_user 2.3待优化命名示例 ①冗余: 错误示例:yy_alllive_video_recomment yy_alllive_open_close_log 说明:去除项目名,简化表名长度,去”yy_” ②相同类别表命名存在差异,管理性差 错误示例:yy_all_live_category yy_alllive_comment_user 说明:去除项目名,统一命名规则,均为”yy_alllive_”开头即可 ③命名格式存在差异 错误示例:yy_showfriend yy_user_getpoints yy_live_program_get

数据仓库设计指南

数据仓库设计指南 在一般的数据仓库应用系统中,根据系统体系结构的不同,数据仓库设计的内容和范围不尽相同,并且设计方法也不尽相同,下面的两幅图示分别表示带有ODS的数据仓库应用系统体系结构和不带ODS的数据仓库应用系统体系结构。本文将说明两个体系结构上的差异以及这种差异造成的设计方法的不同,并且重点介绍带有ODS的体系结构中数据仓库的设计方法。GV1 =p}` 在数据仓库的设计指导思想中,数据仓库的概念定义是非常重要的,数据仓库概念规定了数据仓库所具有的几个基本特性,这些特性也正是对数据仓库设计结果进行检验的重要依据。M)_m= }d 根据Bill.Inmon的定义,“数据仓库是面向主题的、集成的、稳定的、随时间变化的,主要用于决策支持的数据库系统”。_R)tJ Ro ODS(Operational Data Store)是数据仓库体系结构中的一个可选部分,ODS具备数据仓库的部分特征和OLTP系统的部分特征,它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。4\&P~kI 一般在带有ODS的系统体系结构中,ODS都设计为如下几个作用:#:1< R\H6m 1)在业务系统和数据仓库之间形成一个隔离层。[t"C/;S! 一般的数据仓库应用系统都具有非常复杂的数据来源,这些数据存放在不同的地理位置、不同的数据库、不同的应用之中,从这些业务系统对数据进行抽取并不是一件容易的事。因此,ODS用于存放从业务系统直接抽取出来的数据,这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致,因此在抽取过程中极大降低了数据转化的复杂性,而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。,8mPV{U KU 2)转移一部分业务系统细节查询的功能 Cr

数据库设计和编码规范

数据库设计和编码规范 Version

目录

简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错,保持团队支持顺畅,系统长久使用后不至于紊乱,让管理者易于在众多对象中,获取所需或理清问题。 同时,定义标准程序也需要团队合作,讨论出大家愿意遵循的规范。随着时间演进,还需要逐步校订与修改规范,让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契,而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户,如数据库管理员、程序设计人员和程序开发人员,可以直观地辨识对象用途。而命名规则大都约定俗成,可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例,让用户混淆自定义对象和系统对象或关键词。 例如,存储过程不要以sp_或xp_开头,因为SQL SERVER的系统存储过程以 sp_开头,扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略,要让对象的用途直观易懂,但也不宜过长,造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。

6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定,数据库对象包括表、视图(查询)、存储过程(参数查询)、函数、约束。对象名字由前缀和实际名字组成,长度不超过30。避免中文和保留关键字,做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串,而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范,通过后严格按照要求实施。例如:

数据仓库编程规范

未经允许,不可全部或部分发表、复制、使用于任何目的

文档修订摘要

1引言 编写目的 编写《数据仓库开发规范(dbsql系统)(1.0)》的目的是: dbsql封装了访问db2,oracle,greenplum,Sybase 和Teradata数据库的方法,形成了一套访问db2,oracle,greenplum,sybase和Teradata数据库的统一接口。dbsql不仅提供了对db2,oracle,greenplum,sybase和Teradata访问方法的统一,而且提供了一些方法屏蔽5个数据库之间sql语言的差别。这样对于应用程序,只需要编写一套代码,就可以操纵db2,oraclee,greenplum,sybase和Teradata数据库,对开发工程师而言,只用熟悉sql92的标准sql和此文档sql函数就 本文档供以下相关人员阅览: ◆参于数据仓库设计评审的专家人员; ◆参与数据仓库软件开发的软件部人员; ◆参与数据分析系统测试人员。 1.1 背景介绍 ◆开发的软件系统的名称:数据仓库编程规范 ◆开发单位:数据分析部 ◆系统使用单位: ◆该软件系统是数据仓库底层开发跨平台异构数据仓库的基础平台 1.2 术语定义 1.3 参考资料 参考资料共包括: ◆《Tcl/Tk 编程权威指南》 ◆《Expert One on One: Oracle》

◆《Oracle 数据库DBA专题技术精粹》 2DBsql环境配置 2.1 目录设置 2.2 环境变量 主要环境变量设置包括: $DBSQL:程序安装点,开发时设置为个人目录。 $AGENTLOGDIR:Scehdule Server日志采集目录,通常设置为$DBSQL/log $AGENTTRACEDIR:日志及TRACE文件目录。(Schedule Server不采集,可用于存放调试信息) $TOOLS:存放tcl运行环境包及异构数据库编译的动态包安装目录。 用户可以在用户目录下创建.profile文件,例如:

数据库设计规范

数据库设计规范 V 1.0 2007-8-28

目录 1) 目的 (3) 2) 范围 (3) 3) 术语 (3) 4) 设计概要 (3) 5) 命名规范(逻辑对象) (4) 6) 数据库对象命名 (6) 7) 脚本注释 (8) 8) 数据库操作原则 (9) 9) 常用字段命名(参考) (9)

1) 目的 为了统一公司软件开发的设计过程中关于数据库设计时的命名规范和具体工作时的编程规范,便于交流和维护,特制定此规范。 2) 范围 本规范适用于开发组全体人员,作用于软件项目开发的数据库设计、维护阶段。 3) 术语 数据库对象:在数据库软件开发中,数据库服务器端涉及的对象包括物理结构和逻辑结构的对象。 物理结构对象:是指设备管理元素,包括数据文件和事务日志文件的名称、大小、目录规划、所在的服务器计算极名称、镜像等,应该有具体的配置规划。一般对数据库服务器物理设备的管理规程,在整个项目/产品的概要设计阶段予以规划。 逻辑结构对象:是指数据库对象的管理元素,包括数据库名称、表空间、表、字段/域、视图、索引、触发器、存储过程、函数、数据类型、数据库安全性相关的设计、数据库配置有关的设计以及数据库中其他特性处理相关的设计等。 4) 设计概要 ?设计环境 数据库:ORACLE 9i 、MS SQL SERVER 2000 等 操作系统:LINUX 7.1以上版本,显示图形操作界面; RedHat 9 以上版本 WINDOWS 2000 SERVER 以上 ?设计使用工具 使用PowerDesigner 做为数据库的设计工具,要求为主要字段做详尽说 明。对于SQL Server 尽量使用企业管理器对数据库进行设计,并且要求 对表,字段编写详细的说明(这些将作为扩展属性存入SQL Server中) 通过PowerDesigner 定制word格式报表,并导出word文档,作为数据 字典保存。(PowerDesigner v10 才具有定制导出word格式报表的功能)。

数据库命名规范(表、字段名)

数据库命名规范(表、字段名) 一. 实体和属性的命名 1常用单词已经进行了缩写,在命名过程当中,根据语义拼凑缩写即可。注意,由于ORCAL 数据库会将字段名称统一成大写或者小写中的一种,所以要求加上下划线 举例: 定义的缩写Sales: Sal 销售; Order: Ord 订单; Detail: Dtl 明细; 则销售订单名细表命名为:Sal_Ord_Dtl; 2.如果表或者是字段的名称仅有一个单词,那么建议不使用缩写,而是用完整的单词。举例: 定义的缩写Material Ma 物品; 物品表名为:Material, 而不是Ma. 但是字段物品编码则是:Ma_ID;而不是Material」。 3.所有的存储值列表的表前面加上前缀Z 目的是将这些值列表类排序在数据库最后。 4.所有的冗余类的命名(主要是累计表)前面加上前缀X 冗余类是为了提高数据库效率,非规范化数据库的时候加入的字段。或者表 5.关联类通过用下划线连接两个基本类之后,再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。 关联表用于保存多对多关系。 如果被关联的表名大于10个字母,必须将原来的表名的进行缩写。如果没有其他原因,建 议都使用缩写。 举例:表Object与自身存在多对多的关系,则保存多对多关系的表命名为:R_Object ; 表Depart和Employee;存在多对多的关系;则关联表命名为R_Dept_Emp 6.每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义,如果是数据库自动生成的编码,统一命名为:ID;如果是自定义的逻辑上的编码则用缩写加“ID” 的方法命名。 举例:销售订单的编号字段命名:Sal_Ord」D ;如果还存在一个数据库生成的自动编号,则 命名为:ID。

数据仓库的数据标准化思路.docx

数据仓库的数据标准化思路 数据标准化 对于大型公司而言,各个下层子公司都使用自己本地的业务系统,当这些子公司数据往上汇总到总公司时,常常出现代码不一致,数据歧义等等各种各样的问题,在这种情况下,数据标准化就变得不得不行了。 典型的例子,比如医院,大型医院往往包含多个分院,而分院都是用自己的业务系统。业务数据采集汇总后,发现数据结构及数据本身出现歧义,无法直接使用。因此,就不得不对本院及分院的业务数据进行标准化处理,避免歧义,使数据更真实可用,简单易理解。 数据标准化处理应当注意两个关键点: 1.一号对应一对象。 以病人为例,病人可能在各分院及本院都注册建档,因此同一病人可能在各分院都有不同的ID号,但数据采集到本院,与本院数据合并后,进行标准化处理,应保证此病人具有新的唯一ID号。同时需保留病人曾经的各分院及本院ID号,便于其他分院数据的关联(如分院的病人缴费数据需要关联原始分院号码,之后以标准化后唯一ID号,进入本院系统)。 2.事实数据标明数据来源。 如病人缴费信息,因为缴费事实产生的位置不同,需要进行来源标注,分清本院及各分院,便于数据理解及之后的查询和统计。 在构建DW时的数据标准化处理流程上,可以考虑通过以下方式来完成。 标准化准备 在标准化处理之前,需要对DW表格结构进行一些处理,使得标准化过程易于实施,也保证标准化的结果更易于理解。 对于不同的表格上,所需新增的字段也不尽相同。下面分类进行说明: 维表 比如病人信息,科室信息,员工信息,设备信息等,新加字段如下:

事实表 如病人缴费,医生处方,手术记录等,新加字段如下: 数据标准化处理 在数据标准化的处理过程中,也应分为两步进行处理,先进行维表的代码(如ID号)标准化,然后将事实表中的记录以标准化后的代码配合原来的事实信息(如缴费)及数据来源标记(哪个分院)采集到DW 标准事实表中。 维表标准化 1.维表标准化以病人维表为例进行说明 2.将本院及各分院的维表数据采集到DW标准库的缓冲区(可将本院及各分院数据放置于缓冲区的不同用户 下)

数据库设计规范

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),提高存储的利用率和系统性能,但同时也要兼顾扩展性和可移植性。 易用性:数据库设计清晰易用,用户和开发人员均能容

数据库命名规范(表、字段名)

数据库命名规范(表、字段名) 一.实体和属性的命名 1.常用单词已经进行了缩写,在命名过程当中,根据语义拼凑缩写即可。注意,由于ORCAL 数据库会将字段名称统一成大写或者小写中的一种,所以要求加上下划线 举例: 定义的缩写 Sales: Sal 销售; Order: Ord 订单; Detail: Dtl 明细; 则销售订单名细表命名为:Sal_Ord_Dtl; 2.如果表或者是字段的名称仅有一个单词,那么建议不使用缩写,而是用完整的单词。 一、【操作规范】 1. 如无备注,则表中的第一个id字段一定是主键且为自动增长; 2. 如无备注,则数值类型的字段请使用UNSIGNED属性; 3. 如无备注,排序字段order_id在程序中默认使用降序排列; 4. 如无备注,所有字段都设置NOT NULL,并设置默认值; 5. 如无备注,所有的布尔值字段,如is_hot、is_deleted,都必须设置一个默认值,并设为0; 6. 所有的数字类型字段,都必须设置一个默认值,并设为0; 7. 针对varchar类型字段的程序处理,请验证用户输入,不要超出其预设的长度; 8. 建表时将数据字典中的字段中文名和属性备注写入数据表的备注中(“PK、自动增长”不用写); 9. 如无说明,建表时一律采用innodb引擎; 二、【常用表名约定】 0. 说明:表前缀用项目名称首字母缩写;所以表名都小写,单词之间用下划线分开,单

词都用单数形式 1. user –用户 2. category –分类 3. goods –商品、产品等一切可交易网站的物品都用此命名 4. good_gallery –物品的相册 5. good_cate –物品的分类,除了单独作为表名,其他地方分类单词一律用缩写cate 4. attr –属性 5. article –文章、新闻、帮助中心等以文章形式出现的,一般都用此命名 6. cart –购物车 7. feedback –用户反馈 8. order –订单 9. site_nav –包括页头和页尾导航 10. site_config –系统配置表 11. admin –后台用户【RBAC标准表】 12. role –后台用户角色【RBAC标准表】 13. access –后台操作权限,相当于action【RBAC标准表】 14. role_admin –后台用户对应的角色【RBAC标准表】 15. access_role –后台角色对应的权限【RBAC标准表】 16. 待续 三、【常用列名约定】 1. 表名_id –通常用作外键命名 2. cid –特殊的编号,带有元数据,方便关联查询,你可以把它理解成类别(层次)编号。举个例子,产品在分类时,往往需要将其归类到子分类下,相应的字段中也一般只记录子分类的id,这时若需要知道该产品属于哪个主分类,就需要通过子分类信息再查询到主分类信息,这是比较麻烦的,cid字段就是要解决这个问题。一般的站点几十个分类肯

大数据仓库建设方案设计

第1章数据仓库建设 1.1数据仓库总体架构 专家系统接收增购项目车辆TCMS或其他子系统通过车地通信传输的实时或离线数据,经过一系列综合诊断分析,以各种报表图形或信息推送的形式向用户展示分析结果。针对诊断出的车辆故障将给出专家建议处理措施,为车辆的故障根因修复提供必要的支持。 根据专家系统数据仓库建设目标,结合系统数据业务规范,包括数据采集频率、数据采集量等相关因素,设计专家系统数据仓库架构如下: 数据仓库架构从层次结构上分为数据采集、数据存、数据分析、数据服务等几个方面的内容: 数据采集:负责从各业务自系统中汇集信息数据,系统支撑Kafka、Storm、Flume

及传统的ETL采集工具。 数据存储:本系统提供Hdfs、Hbase及RDBMS相结合的存储模式,支持海量数据的分布式存储。 数据分析:数据仓库体系支持传统的OLAP分析及基于Spark常规机器学习算法。 数据服务总线:数据系统提供数据服务总线服务,实现对数据资源的统一管理和调度,并对外提供数据服务。 1.2数据采集 专家系统数据仓库数据采集包括两个部分内容:外部数据汇集、内部各层数据的提取与加载。外部数据汇集是指从TCMS、车载子系统等外部信息系统汇集数据到专家数据仓库的操作型存储层(ODS);内部各层数据的提取与加载是指数据仓库各存储层间的数据提取、转换与加载。 1.2.1外部数据汇集 专家数据仓库数据源包括列车监控与检测系统(TCMS)、车载子系统等相关子系统,数据采集的内容分为实时数据采集和定时数据采集两大类,实时数据采集主要对于各项检测指标数据;非实时采集包括日检修数据等。 根据项目信息汇集要求,列车指标信息采集具有采集数据量大,采集频率高的特点,考虑到系统后期的扩展,因此在数据数据采集方面,要求采集体系支持高吞吐量、高频率、海量数据采集,同时系统应该灵活可配置,可根据业务的需要进行灵活配置横向扩展。 本方案在数据采集架构采用Flume+Kafka+Storm的组合架构,采用Flume和ETL 工具作为Kafka的Producer,采用Storm作为Kafka的Consumer,Storm可实现对海量数据的实时处理,及时对问题指标进行预警。具体采集系统技术结构图如下:

Greenplum数据库设计开发规范

G r e e n p l u m数据库设 计开发规范 集团企业公司编码:(LL3698-KKI1269-TM2483-LUI12689-ITT289-

目录

第一章前言 1.1文档目的 随着Greenplum数据库的正式上线使用。为了保证Greenplum 数据仓库系统平台的平稳运行,保证系统的可靠性、稳定性、可维护性和高性能。特制定本开发规范,以规范基于Greenplum数据库平台的相关应用开发,提高开发质量。 1.2预期读者 Greenplum数据仓库平台应用的设计与开发人员; Greenplum 数据仓库平台的系统管理人员和数据库管理员; Greenplum 数据仓库平台的运行维护人员; 1.3参考资料 参考Greenplum4.3.x版本官方指引: 《GPDB43AdminGuide.pdf》 《GPDB43RefGuide.pdf》 《GPDB43UtilityGuide.pdf》

第二章设计规范 2.1数据库对象数量 数据库对象类型包括数据表、视图、函数、序列、索引等等,在Greenplum数据库中,系统元数据同时保存在Master 服务器和Segment 服务器上,过多的数据库对象会造成系统元数据的膨胀,而过多的系统元数据造成系统运行逐步变慢;同时,类似数据库的备份、恢复、扩容等较大型的操作都导致效率变慢。因此,依据GreenplumDB产品的最佳时间,单个数据库的对象数量,应控制在10万以内。 GP数据库的对象包括:表、视图、索引、分区子表、外部表等。 如果数据表的数量太多,建议按应用域进行分库,尽量将单个数据库的表数量控制在10万以内,可以在一个集群中创建多个数据库。 【备注】:在Greenplum数据库中,一张分区表,在数据库中存储为一张父表、每张分区子表都是一张独立的库表;例如:一张按月进行分区的存储一年数据的表,如果含默认分区,共14张表。 2.2表创建规范 为了避免数据库表数量太多,避免单个数据表的数据量过大,给系统的运行和使用带来困难,在Greenplum数据库中需遵循如下的表创建规范: 1、GP系统表中保存的表名称都是以小写保存。通常SQL语句中表名对大小写不敏感。但不允许在建表语句中使用双引号(“”)包括表

数据库命名设计规范

数据库命名、设计规范 一、数据库表及字段 1.数据库表的命名规范: 表的前缀应该用系统或模块的英文名的缩写(全部大写)。如果系统功能简单,没有划分为模块,则可以以系统英文名称的缩写作为前缀,否则以各模块的英文名称缩写作为前缀。例如:如果有一个模块叫做BBS(缩写为BBS),那么你的数据库中的所有对象的名称都要加上这个前缀:BBS_ + 数据库对象名称,BBS_CustomerInfo标示论坛模块中的客户信息表。 表的名称必须是易于理解,能表达表的功能的英文单词或缩写英文单词,无论是完整英文单词还是缩写英文单词,单词首字母必须大写。如果当前表可用一个英文单词表示的,请用完整的英文单词来表示;例如:系统资料中的客户表的表名可命名为:SYS_Customer。如果当前表需用两个或两个以上的单词来表示时,尽量以完整形式书写,如太长可采用两个英文单词的缩写形式;例如:系统资料中的客户物料表可命名为:SYS_CustItem。 表名称不应该取得太长(一般不超过三个英文单词)。表名长度不能超过30个字符,表名中含有单词全部采用单数形式,单词首字母必须大写。在命名表时,用单数形式表示名称。例如,使用 Employee,而不是 Employees。对于有主明细的表来说。明细表的名称为:主表的名称 + 字符Dts。例如:采购定单的名称为:PO_Order,则采购定单的明细表为:PO_OrderDts;对于有主明细的表来说,明细表必须包含两个字段:主表关键字、SN,SN字段的类型为int型,目的为与主表关键字联合组成明细表的关键字,以及标示明细记录的先后顺序,如1,2,3……。表必须填写描述信息,后台表名尽量与前台表名相同,后台独有的表应以_b作为后缀。如r_gggd_b。 数据库表的命名采用如下规则: 1)表名用模块名_开头,表名长度不能超过30个字符,表名中含有单词全部采用单数形式,单词首字母必须大写。 2)多个单词间用下划线(_)进行连接。若库中有多个系统,表名采用系统名称+单词或多个单词,系统名是开发系统的缩写,如VNET。

ETL技术设计规范方案(通用)

ETL技术规 第1章.ETL设计规 ETL设计规主要应用于ETL编码的前期工作。由于ETL全过程是面向数据的, 主要工作为数据的抽取(Extract )、转换(Transform )、装载(Loading),正确界定所涉及到的数据围和应当应用的转换逻辑对于后续的编码工作非常重要,这些数据关系的确定,我们称之为Mapping (数据映射)。 正确定义数据映射关系是ETL成功实施的前提,一个完善的Mapping应该包含以下几个部分: 1.1源数据集属性 此部分应该详细描述数据源的相关属性,包括: 实体名称一一含数据来源名称(DSN、所有者等信息; 字段名称--- 英文名称; 字段简述--- 中文名称,如为参数信息应该有相关取值解释,如性别字段(1: 男;2:女;0:不详) 类型一一字段类型,含长度和精度信息; 非空属性一一字段是否可以为空;

1.2目标数据集属性 此部分应该详细描述目标数据集的相关属性,包括: 实体名称一一含数据来源名称(DSN、所有者等信息; 字段名称英文名称,建议根据字段含义来命名,而不是简单用拼音来定义字段(此部分由负责设计数据集的人员控制); 字段简述中文名称,对于保留字段应该给出默认值; 类型一一字段类型,含长度和精度信息; 非空属性一一字段是否可以为空;

1.3 ETL规则 主要描述ETL各个环节的转换规则,包括: 数据源过滤规则——描述从源数据集获取数据过程中过滤掉记录的规则; 关联规则——当源数据集为多个时,描述相互之间的关联关系; 列转换规则一一描述源数据集到目标数据集的字段间的转换规则;此规则非 常重要,要清晰描述字段间的逻辑关系,包括业务逻辑; 目标数据集更新规则一一描述目标数据集的更新策略,包括更新机制和更新频度,如“每日全量更新”、“每周增量更新”等; ETL作业列表一一由于ETL所开发的作业之间包含一定的业务逻辑和编码逻辑,所以调度过程中应遵循一定的逻辑顺序,此部分主要用来明确调度的顺序,包括:作业名称实现Mapping的作业名称,包括该作业功能描述; 调度顺序一一用序号或者是流程图模式描述作业的调度顺序,需要综合考虑业务逻辑、编码逻辑以及系统资源等多方面情况,在保证业务逻辑和编码逻辑的基础上,通过控制调度,最大限度地合理利用系统资源;

数据库设计规范

- 茶马古道电子商务有限公司 数据库设计规范 V 1.0 版权所有

文档信息 作者: 创建日期(yyyy-mm-dd): 审核者: 审核日期(yyyy-mm-dd): 最后修订者: 最后修订日期(yyyy-mm-dd): 文档类型: 文档修订历史 版本号修订日期修订者修订内容1.0.0 2011.9.20 金洋初始化

数据库约定 对应于XXXX MYSQL数据库环境的数据库类型定义如下表:1 Development Database 开发环境使用 开发环境数据库 2 Quality Assurance Database 质保环境使用 质保环境数据库 3 Production Database 生产环境使用 生产环境数据库 4 Training Database 培训环境使用 培训环境数据库 5 SIT Database 集成测试环境使用集成测试环境数据库 数据库字符集选择UTF8字符集 (建库时确定) 1. 数据库元素命名规范 长度约定:字段名,表名,视图名称等长度不能超过25个字符1.1. 表命名规范 数据类型数据类型(英文)前缀 主数据Master Data Table TM 业务事务处理数据Transaction Data Table TT 关系表Relationship Table TR 代码列表Code List Table TC 接口表Interface Table TI 系统管理表System administration Table TS 日志表Log Table TL 历史表History Table TH 中间临时表Temparory table TE 汇总表Aggregation Table TA 归档表Archivie Table TZ

数据库表及字段命名、设计规范

数据库表及字段命名、设计规范 1、命名规范 1.1数据表的命名规范: 1)表的前缀应该用系统或模块的英文名的缩写(全部大写或首字母大写)。如果系统功能简单,没有划分为模块,则可以以系统英文名称的缩写作为前缀,否则以各模块的英文名称缩写作为前缀。例如:如果有一个模块叫做BBS(缩写为BBS),那么你的数据库中的所有对象的名称都要加上这个前缀:BBS_ + 数据库对象名称,BBS_CustomerInfo标示论坛模块中的客户信息表。 2)表的名称必须易于理解,使用能表达表功能的英文单词或缩写英文单词,无论是完整英文单词还是缩写英文单词,单词首字母必须大写。如果当前表可用一个英文单词表示的,请用完整的英文单词来表示;例如:系统资料中的客户表的表名可命名为:SYS_Customer。如果当前表需用两个或两个以上的单词来表示时,尽量以完整形式书写,如太长可采用两个英文单词的缩写形式;例如:系统资料中的客户物料表可命名为:SYS_CustItem。 3)表的名称一般使用名词或者动宾短语 4)表名称不应该取得太长(一般不超过三个英文单词)。 5)在命名表时,用单数形式表示名称。例如,使用 Employee,而不是 Employees。 6)对于有主明细的表来说。明细表的名称为:主表的名称 + 字符Dts。例如:采购定单的名称为:PO_Order,则采购定单的明细表为:PO_OrderDts 对于有主明细的表来说,明细表必须包含两个字段:主表关键字、SN,SN字段的类型为int 型,目的为与主表关键字联合组成明细表的关键字,以及标示明细记录的先后顺序,如1,2,3……。

7)表必须填写描述信息 7)后台表名尽量与前台表名相同,后台独有的表应以_b作为后缀。如r_gggd_b 1.2表字段命名规范 数据库字段的命名必须遵循以下规范: 1)字段名称一般采用名词或动宾短语,且字段名为小写。 2)采用有意义的字段名。字段的名称必须是易于理解,能表达字段功能的英文单词或缩写英文单词,单词首字母必须大写,一般不超过三个英文单词。例如:人员信息表中的电话号码可命名为:Telephone或Tel。产品明细表中的产品名称可用ProductName表示。(推荐一般用完整的英文单词)。 3)系统中所有属于内码字段(仅用于标示唯一性和程序内部用到的标示性字段),名称取为:“ID”,采用整型或长整型数,具体根据可能的数据量确定,增加记录时取最大值加1,该字段通常为主关键字。 4)系统中属于是业务范围内的编号的字段,其代表一定的业务信息,比如资料信息和单据的编号,这样的字段建议命名为:“Code”,其数据类型为varchar,该字段需加唯一索引。 5)在命名表的列时,不要重复表的名称;例如,在名为 Employee 的表中避免使用名为EmployeeLastName 的字段。 5)不要在列的名称中包含数据类型。

相关文档