用户管理数据库设计
㈠ 请简要的叙述一下数据库的主要设计过程
一、数据库设计过程
数据库技术是信息资源管理最有效的手段。
数据库设计是指:对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求。
数据库设计的各阶段:
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方法,它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术,用于建立系统信息模型。
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
2.1 第零步——初始化工程
这个阶段的任务是从目的描述和范围描述开始,确定建模目标,开发建模计划,组织建模队伍,收集源材料,制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果,业务流程,原有系统的输入输出,各种报表,收集原始数据,形成了基本数据资料表。
2.2 第一步——定义实体
实体集成员都有一个共同的特征和属性集,可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有 “代码”结尾的术语,如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来,从而初步找出潜在的实体,形成初步实体表。
2.3 第二步——定义联系
IDEF1X模型中只允许二元联系,n元联系必须定义为n个二元联系。根据实际的业务需求和规则,使用实体联系矩阵来标识实体间的二元关系,然后根据实际情况确定出连接关系的势、关系名和说明,确定关系类型,是标识关系、非标识关系(强制的或可选的)还是非确定关系、分类关系。如果子实体的每个实例都需要通过和父实体的关系来标识,则为标识关系,否则为非标识关系。非标识关系中,如果每个子实体的实例都与而且只与一个父实体关联,则为强制的,否则为非强制的。如果父实体与子实体代表的是同一现实对象,那么它们为分类关系。
2.4 第三步——定义码
通过引入交叉实体除去上一阶段产生的非确定关系,然后从非交叉实体和独立实体开始标识侯选码属性,以便唯一识别每个实体的实例,再从侯选码中确定主码。为了确定主码和关系的有效性,通过非空规则和非多值规则来保证,即一个实体实例的一个属性不能是空值,也不能在同一个时刻有一个以上的值。找出误认的确定关系,将实体进一步分解,最后构造出IDEF1X模型的键基视图(KB图)。
2.5 第四步——定义属性
从源数据表中抽取说明性的名词开发出属性表,确定属性的所有者。定义非主码属性,检查属性的非空及非多值规则。此外,还要检查完全依赖函数规则和非传递依赖规则,保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。以此得到了至少符合关系理论第三范式的改进的IDEF1X模型的全属性视图。
2.6 第五步——定义其他对象和规则
定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、存储过程、视图、角色、同义词、序列等对象信息。
3. 逻辑结构设计阶段
将概念结构转换为某个DBMS所支持的数据模型(例如关系模型),并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型,然后选择最合适的DBMS。
将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则:一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的码就是关系的码。
数据模型的优化,确定数据依赖,消除冗余的联系,确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准,即:
表内的每一个值都只能被表达一次。
表内的每一行都应该被唯一的标识(有唯一键)。
表内不应该存储依赖于其他键的非键信息。
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
4. 数据库物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。
5. 数据库实施阶段
运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C),根据逻辑设计和物理设计的结果建立数据库,编制与调试应用程序,组织数据入库,并进行试运行。 数据库实施主要包括以下工作:用DDL定义数据库结构、组织数据入库 、编制与调试应用程序、数据库试运行 ,(Data Definition Language(DDL数据定义语言)用作开新数据表、设定字段、删除数据表、删除字段,管理所有有关数据库结构的东西)
●Create (新增有关数据库结构的东西,属DDL)
●Drop (删除有关数据库结构的东西,属DDL)
●Alter (更改结构,属DDL)
6. 数据库运行和维护阶段
在数据库系统运行过程中必须不断地对其进行评价、调整与修改。内容包括:数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。
7. 建模工具的使用
为加快数据库设计速度,目前有很多数据库辅助工具(CASE工具),如Rational公司的Rational Rose,CA公司的Erwin和Bpwin,Sybase公司的PowerDesigner以及Oracle公司的oracle Designer等。
ERwin主要用来建立数据库的概念模型和物理模型。它能用图形化的方式,描述出实体、联系及实体的属性。ERwin支持IDEF1X方法。通过使用 ERwin建模工具自动生成、更改和分析IDEF1X模型,不仅能得到优秀的业务功能和数据需求模型,而且可以实现从IDEF1X模型到数据库物理设计的转变。ERwin工具绘制的模型对应于逻辑模型和物理模型两种。在逻辑模型中,IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。在物理模型中,ERwin可以定义对应的表、列,并可针对各种数据库管理系统自动转换为适当的类型。
设计人员可根据需要选用相应的数据库设计建模工具。例如需求分析完成之后,设计人员可以使用Erwin画ER图,将ER图转换为关系数据模型,生成数据库结构;画数据流图,生成应用程序。
二、数据库设计技巧
1. 设计数据库之前(需求分析阶段)
1) 理解客户需求,包括用户未来需求变化。
2) 了解企业业务类型,可以在开发阶段节约大量的时间。
3) 重视输入(要记录的数据)、输出(报表、查询、视图)。
4) 创建数据字典和ER 图表
数据字典(Data Dictionary,简称DD)是各类数据描述的集合,是关于数据库中数据的描述,即元数据,不是数据本身。(至少应该包含每个字段的数据类型和在每个表内的主外键)。
数据项描述: 数据项名,数据项含义说明,别名,数据类型,长度,取值范围,取值含义,与其他数据项的逻辑关系
数据结构描述: 数据结构名,含义说明,组成:[数据项或数据结构]
数据流描述: 数据流名,说明,数据流来源,数据流去向, 组成:[数据结构],平均流量,高峰期流量
数据存储描述: 数据存储名,说明,编号,流入的数据流,流出的数据流,组成:[数据结构],数据量,存取方式
处理过程描述: 处理过程名,说明,输入:[数据流],输出:[数据流],处理:[简要说明]
ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用,而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。
5) 定义标准的对象命名规范
数据库各种对象的命名必须规范。
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
2. 表和字段的设计(数据库逻辑设计)
表设计原则
1) 标准化和规范化
数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式,但Third Normal Form(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说,遵守3NF 标准的数据库的表设计原则是:“One Fact in One Place”即某个表只包括其本身基本的属性,当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点:有一组表专门存放通过键连接起来的关联数据。
2) 数据驱动
采用数据驱动而非硬编码的方式,许多策略变更和维护都会方便得多,大大增强系统的灵活性和扩展性。
举例,假如用户界面要访问外部数据源(文件、XML 文档、其他数据库等),不妨把相应的连接和路径信息存储在用户界面支持的表里。如果用户界面执行工作流之类的任务(发送邮件、打印信笺、修改记录状态等),那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上,如果过程是数据驱动的,你就可以把相当大的责任推给用户,由用户来维护自己的工作流过程。
3) 考虑各种变化
在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。
4) 表名、报表名和查询名的命名规范
(采用前缀命名)检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。你可以统一地命名这些数据库的不同组成部分,至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。如果采用了 Microsoft Access,你可以用 qry、rpt、tbl 和 mod 等符号来标识对象(比如 tbl_Employees)。用 sp_company 标识存储过程,用 udf_ (或者类似的标记)标识自定义编写的函数。
字段设计原则:
1) 每个表中都应该添加的3 个有用的字段。
dRecordCreationDate,在SQL Server 下默认为GETDATE()
sRecordCreator,在SQL Server 下默认为NOT NULL DEFAULT USER
nRecordVersion,记录的版本标记;有助于准确说明记录中出现null 数据或者丢失数据的原因
时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。
2) 对地址和电话采用多个字段
描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有,电话号码和邮件地址最好拥有自己的数据表,其间具有自身的类型和标记类别。
3) 表内的列[字段]的命名规则(采用前缀/后缀命名)、采用有意义的字段名
对列[字段]名应该采用标准的前缀和后缀。如键是数字类型:用 _N 后缀;字符类型:_C 后缀;日期类型:_D 后缀。再如,假如你的表里有好多“money”字段,你不妨给每个列[字段]增加一个 _M 后缀。
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
假设有两个表:
Customer 和 Order。Customer 表的前缀是 cu_,所以该表内的子段名如下:cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前缀是 or_,所以子段名是:
or_order_id、or_cust_name_id、or_quantity 和 or_description 等。
这样从数据库中选出全部数据的 SQL 语句可以写成如下所示:
Select * From Customer, Order Where cu_surname = "MYNAME" ;
and cu_name_id = or_cust_name_id and or_quantity = 1
在没有这些前缀的情况下则写成这个样子(用别名来区分):
Select * From Customer, Order Where Customer.surname = "MYNAME" ;
and Customer.name_id = Order.cust_name_id and Order.quantity = 1
第 1 个 SQL 语句没少键入多少字符。但如果查询涉及到 5 个表乃至更多的列[字段]你就知道这个技巧多有用了。
5) 选择数字类型和文本类型的长度应尽量充足
假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。
6) 增加删除标记字段
在表中包含一个“删除标记”字段,这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。
7) 提防大小写混用的对象名和特殊字符
采用全部大写而且包含下划符的名字具有更好的可读性(CUSTOMER_DATA),绝对不要在对象名的字符之间留空格。
8) 小心保留词
要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突,比如,用 DESC 作为说明字段名。后果可想而知!DESC 是 DESCENDING 缩写后的保留词。表里的一个 SELECT * 语句倒是能用,但得到的却是一大堆毫无用处的信息。
9) 保持字段名和类型的一致性
在命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在表1中叫做“agreement_number”,就别在表2里把名字改成 “ref1”。假如数据类型在表1里是整数,那在表2里可就别变成字符型了。当然在表1(ABC)有处键ID,则为了可读性,在表2做关联时可以命名为 ABC_ID。
10) 避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器,你最好集中对它文档化。
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
3. 选择键和索引(数据库逻辑设计)
参考:《SQL优化-索引》一文
4. 数据完整性设计(数据库逻辑设计)
1) 完整性实现机制:
实体完整性:主键
参照完整性:
父表中删除数据:级联删除;受限删除;置空值
父表中插入数据:受限插入;递归插入
父表中更新数据:级联更新;受限更新;置空值
DBMS对参照完整性可以有两种方法实现:外键实现机制(约束规则)和触发器实现机制用户定义完整性:
NOT NULL;CHECK;触发器
2) 用约束而非商务规则强制数据完整性
采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。不要依赖于商务层保证数据完整性;它不能保证表之间(外键) 的完整性所以不能强加于其他完整性规则之上。如果你在数据层确实采用了约束,你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。
3) 强制指示完整性
在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
4) 使用查找控制数据完整性
控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找:国家代码、状态代码等。
5) 采用视图
为了在数据库和应用程序代码之间提供另一层抽象,可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。
6) 分布式数据系统
对分布式系统而言,在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该估计一下未来 5 年或者 10 年的数据量。当你把数据传送到其他站点的时候,最好在数据库字段中设置一些标记,在目的站点收到你的数据之后更新你的标记。为了进行这种数据传输,请写下你自己的批处理或者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据。本地拷贝你的维护数据,比如计算常数和利息率等,设置版本号保证数据在每个站点都完全一致。
7) 关系
如果两个实体之间存在多对一关系,而且还有可能转化为多对多关系,那么你最好一开始就设置成多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。
8) 给数据保有和恢复制定计划
考虑数据保存策略并包含在设计过程中,预先设计你的数据恢复过程。采用可以发布给用户/开发人员的数据字典实现方便的数据识别同时保证对数据源文档化。编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新。
9) 用存储过程让系统做重活
提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库不只是一个存放数据的地方,它也是简化编码之地。
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
5. 其他设计技巧
1) 避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器,你最好集中对它文档化。
2) 使用常用英语(或者其他任何语言)而不要使用编码
在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码,可以在编码旁附上用户知道的英语。
3) 保存常用信息
让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复(对Access)、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库,当客户抱怨他们的数据库没有达到希望的要求而与你联系时,这样做对非客户机/服务器环境特别有用。
4) 包含版本机制
在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长,用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。
5) 编制文档
对所有的快捷方式、命名规范、限制和函数都要编制文档。
采用给表、列、触发器等加注释的 数据库工具。对开发、支持和跟踪修改非常有用。
对数据库文档化,或者在数据库自身的内部或者单独建立文档。这样,当过了一年多时间后再回过头来做第2 个版本,犯错的机会将大大减少。
6) 测试、测试、反复测试
建立或者修订数据库之后,必须用用户新输入的数据测试数据字段。最重要的是,让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。
7) 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说,针对每一种最终表达数据的原型应用,保证你检查了数据模型并且查看如何取出数据。
三、数据库命名规范
1. 实体(表)的命名
1) 表以名词或名词短语命名,确定表名是采用复数还是单数形式,此外给表的别名定义简单规则(比方说,如果表名是一个单词,别名就取单词的前4 个字母;如果表名是两个单词,就各取两个单词的前两个字母组成4 个字母长的别名;如果表的名字由3 个单词组成,从头两个单词中各取一个然后从最后一个单词中再取出两个字母,结果还是组成4 字母长的别名,其余依次类推)
对工作用表来说,表名可以加上前缀WORK_ 后面附上采用该表的应用程序的名字。在命名过程当中,根据语义拼凑缩写即可。注意:将字段名称会统一成大写或者小写中的一种,故中间加上下划线。
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
举例:
定义的缩写 Sales: Sal 销售;
Order: Ord 订单;
Detail: Dtl 明细;
则销售订单明细表命名为:Sal_Ord_Dtl;
2) 如果表或者是字段的名称仅有一个单词,那么建议不使用缩写,而是用完整的单词。
举例:
定义的缩写 Material Ma 物品;
物品表名为:Material, 而不是 Ma.
但是字段物品编码则是:Ma_ID;而不是Material_ID
3) 所有的存储值列表的表前面加上前缀Z
目的是将这些值列表类排序在数据库最后。
4) 所有的冗余类的命名(主要是累计表)前面加上前缀X
冗余类是为了提高数据库效率,非规范化数据库的时候加入的字段或者表
5) 关联类通过用下划线连接两个基本类之后,再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。
关联表用于保存多对多关系。
如果被关联的表名大于10个字母,必须将原来的表名的进行缩写。如果没有其他原因,建议都使用缩写。
举例:表Object与自身存在多对多的关系,则保存多对多关系的表命名为:R_Object;
作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17
本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……
2. 属性(列)的命名
1) 采用有意义的列名
表内的列要针对键采用一整套设计规则。每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义;
A、如果是数据库自动生成的编码,统一命名为:ID
B、如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名,即“XXXX_ID”
C、如果键是数字类型,你可以用_NO 作为后缀;
D、如果是字符类型则可以采用_CODE 后缀
E、对列名应该采用标准的前缀和后缀。
举例:销售订单的编号字段命名:Sal_Ord_ID;如果还存在一个数据库生成的自动编号,则命名为:ID。
2) 所有的属性加上有关类型的后缀
注意,如果还需要其它的后缀,都放在类型后缀之前。
注: 数据类型是文本的字段,类型后缀TX可以不写。有些类型比较明显的字段,可以不写类型后缀。
3) 采用前缀命名
给每个表的列名都采用统一的前缀,那么在编写SQL表达式的时候会得到大大的简化。这样做也确实有缺点,比如破坏了自动表连接工具的作用,后者把公共列名同某些数据库联系起来。
3. 视图的命名
1) 视图以V作为前缀,其他命名规则和表的命名类似;
2) 命名应尽量体现各视图的功能。
4. 触发器的命名(尽量不使用)
触发器以TR作为前缀,触发器名为相应的表名加上后缀,Insert触发器加'_I',Delete触发器加'_D',Update触发器加'_U',如:TR_Customer_I,TR_Customer_D,TR_Customer_U。
5. 存储过程名
存储过程应以'UP_'开头,和系统的存储过程区分,后续部分主要以动宾形式构成,并用下划线分割各个组成部分。如增加代理商的帐户的存储过程为'UP_Ins_Agent_Account'。
6. 变量名
变量名采用小写,若属于词组形式,用下划线分隔每个单词,如@my_err_no。
7. 命名中其他注意事项
1) 以上命名都不得超过30个字符的系统限制。变量名的长度限制为29(不包括标识字符@)。
2) 数据对象、变量的命名都采用英文字符,禁止使用中文命名。绝对不要在对象名的字符之间留空格。
3) 小心保留词,要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突
4) 保持字段名和类型的一致性,在命名字段并为其指定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数,那在另一个表里可就别变成字符型了。
㈡ 2、用户权限管理,数据库表设计
网上资料说权限设计 = 功能权限 + 数据权限,我认为还是很有道理的。之前项目中只涉及到功能权限,没有数据权限,原因是最开始设计时,数据已经绑定在特定的用户下了,而且涉及到的表数量很少,不需要单独考虑数据权限的问题。
权限管理,最细致的权限管理有 用户,用户组,角色,权限,功能。根据不同的需求适当选择,如 用户量过大,每个人都授权和麻烦,就引入用户组,对用户组赋予权限。功能上也根据业务不同做适当的扩展。由于如用户权限之前存在多对多关系,需要引入中间表。
本系统设计如下:
数据量很小,功能也不复杂,所以只有用户,角色,权限(功能)及产生的中间表。
表中的数据都是提前填的,用户登陆,查ermroleuser表,获取角色,查ermrolefunction表,获取功能,再查ermfunction表,返回该用户的功能的中文,在页面上展示。
功能权限详细设计请参考,本项目也是受此启发:
http://blog.csdn.net/painsonline/article/details/7183613/
需求:给一个原来没有权限的数据配置系统加上登录,权限功能,不同角色查同一张表返回结果不同。
思路:所谓数据权限,关注点在于实体属性值、条件、允许值,用户登录后,查询该用户的查询条件,根据条件获取数据即可。详细表结构设计可以参考: https://zhuanlan.hu.com/p/31339794
具体介绍一下每个字段含义:
(1)主键 id;
(2)acl_id 映射权限点表主键,代表每行记录是针对哪个权限点的;
(3)status 代表当前这条配置是否有效,方便临时激活与禁用;
(4)param 代表需要校验的参数名,允许一个请求有多个参数参与数据校验;如果参数复杂,比如包含对象,定义的参数可能为a.b.c 这种多级的形式,建议不要太复杂
(5)operation 代表数据拦截的规则,使用数字代表是等于、大于、小于、大于等于、小于等于、包含、介于之间等,可以根据自己需要增加或减少支持的拦截规则
(6)value1 和 value2 用来和param、operation组成一个关系表达式,比如:1<=a<2
next_param_op 字段根据需要使用,如果一个权限点支持多条数据规则时,连接两个规则之间的操作,|| 还是 &&
(7)seq 字段用于某个权限点包含多条数据权限规则时的顺序
假设有这么一条数据,那么他的含义是:id为1(acl_id)的权限点,配置了一条有效(status=1)的数据规则,规则是:传入参数id(param)的值要大于(operation)10(value1)
这种设计很细致了,当然我的项目没有那么复杂,所以最终没有采用这个。
http://www.cnblogs.com/jeffwoot/archive/2008/12/23/1359591.html 讲述了数据权限设计的演化过程。
本系统跟权限相关的表结构如下:
㈢ 具体的数据库设计与实现过程
大致的讲主要是根据用户的需求,然后设计数据库的E-R模型,然后将E-R模型图转换为各种表,并对其进行数据库设计范式(范式因不同书籍有不同)的审核,然后进行数据库的实施,然后运行维护。
一句话来讲就是将用户的需求变成带有各种关系的表,以及其它的数据库结构,然后供编程使用
具体如下:
按照规范设计的方法,考虑数据库及其应用系统开发全过程,将数据库设计分为以下六个阶段
(1)需求分析。
(2)概念设计。
(3)逻辑设计。
(4)物理设计。
(5)数据库实施。
(6)数据库运行和维护。
5.1.1 需求分析阶段
进行数据库设计首先必须准确了解与分析用户需求,包括数据与处理需求。需求分析是整个设计过程的基础,是最困难、最耗时的一步。作为“地基”的需求分析是否做得充分与准确,决定了在其上构建“数据库大厦”的速度与质量。需求分析做得不好,可能会导致整个数据库重新设计,因此,务必引起高度重视。
5.1.2 概念模型设计阶段
在概念设计阶段,设计人员仅从用户角度看待数据及其处理要求和约束,产生一个反映用户观点的概念模式,也称为“组织模式”。概念模式能充分反映现实世界中实体间的联系,又是各种基本数据模型的共同基础,易于向关系模型转换。这样做有以下好处:
(1)数据库设计各阶段的任务相对单一化,设计复杂程度得到降低,便于组织管理。
(2)概念模式不受特定DBMS的限制,也独立于存储安排,因而比逻辑设计得到的模式更为稳定。
(3)概念模式不含具体的DBMS所附加的技术细节,更容易为用户所理解,因而能准确地反映用户的信息需求。
概念模型设计是整个数据库设计的关键,它通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型。如采用基于E-R模型的数据库设计方法,该阶段即将所设计的对象抽象出E-R模型;如采用用户视图法,则应设计出不同的用户视图。
5.1.3 逻辑模型设计阶段
逻辑模型设计阶段的任务是将概念模型设计阶段得到的基本E-R图,转换为与选用的DBMS产品所支持的数据模型相符合的逻辑结构。如采用基于E-R模型的数据库设计方法,该阶段就是将所设计的E-R模型转换为某个DBMS所支持的数据模型;如采用用户视图法,则应进行表的规范化,列出所有的关键字以及用数据结构图描述表集合中的约束与联系,汇总各用户视图的设计结果,将所有的用户视图合成一个复杂的数据库系统。
5.1.4 数据库物理设计阶段
数据库的物理结构主要指数据库的存储记录格式、存储记录安排和存取方法。显然,数据库的物理设计完全依赖于给定的硬件环境和数据库产品。在关系模型系统中,物理设计比较简单一些,因为文件形式是单记录类型文件,仅包含索引机制、空间大小、块的大小等内容。
物理设计可分五步完成,前三步涉及到物理结构设计,后两步涉及到约束和具体的程序设计:
(1)存储记录结构设计:包括记录的组成、数据项的类型、长度,以及逻辑记录到存储记录的映射。
(2) 确定数据存放位置:可以把经常同时被访问的数据组合在一起,“记录聚簇(cluster)”技术能满足这个要求。
(3)存取方法的设计:存取路径分为主存取路径及辅存取路径,前者用于主键检索,后者用于辅助键检索。
(4)完整性和安全性考虑:设计者应在完整性、安全性、有效性和效率方面进行分析,作出权衡。
(5)程序设计:在逻辑数据库结构确定后,应用程序设计就应当随之开始。物理数据独立性的目的是消除由于物理结构的改变而引起对应用程序的修改。当物理独立性未得到保证时,可能会引发对程序的修改。
数据库物理设计是为逻辑数据模型选取一个最适合应用环境的物理结构,包括存储结构和存取方法。
5.1.5 数据库实施阶段
根据逻辑设计和物理设计的结果,在计算机系统上建立起实际数据库结构、装入数据、测试和试运行的过程称为数据库的实施阶段。实施阶段主要有三项工作。
(1)建立实际数据库结构。对描述逻辑设计和物理设计结果的程序即“源模式”,经DBMS编译成目标模式并执行后,便建立了实际的数据库结构。
(2)装入试验数据对应用程序进行调试。试验数据可以是实际数据,也可由手工生成或用随机数发生器生成。应使测试数据尽可能覆盖现实世界的各种情况。
(3)装入实际数据,进入试运行状态。测量系统的性能指标,是否符合设计目标。如果不符,则返回到前面,修改数据库的物理模型设计甚至逻辑模型设计。
5.1.6 数据库运行和维护阶段
数据库系统正式运行,标志着数据库设计与应用开发工作的结束和维护阶段的开始。运行维护阶段的主要任务有四项:
(1)维护数据库的安全性与完整性:检查系统安全性是否受到侵犯,及时调整授权和密码,实施系统转储与备份,发生故障后及时恢复。
(2)监测并改善数据库运行性能:对数据库的存储空间状况及响应时间进行分析评价,结合用户反应确定改进措施。
(3)根据用户要求对数据库现有功能进行扩充。
(4)及时改正运行中发现的系统错误。
㈣ 高分诚心求助!数据库设计如何实现不同用户进行不同操作的权限管理!(数据库SQL2000+编程语言C#)
我做过类似有权限管理的系统,表分3个:
第一个表是 权限表(tb_pope),都有什么权限,以你的系统要求,分3个权限:管理所有学生,管理系学生,本学生。
表列名可以是: ID,popeName,里面有3条记录。
1,管理所有学生
2,管理系学生
3,本学生
第二个表是 用户表(tb_user): ID,userName,age,等等.
第三个表就是 用户权限表(tb_userpope): ID,userID,PopeID
登录时先检查是否有该用户名,然后读取其权限值,根据权限操作数据库 显示或隐藏 操作的部分。
大致就这样了。
㈤ 多级用户系统的数据库应该怎么设计
主要从几个不同方面设计ORACLE数据库优化方案: 一.数据库优化自由结构OFA(Optimal flexible Architecture) 二、充分利用系统全局区域SGA(SYSTEM GLOBAL AREA) 三、数据库设计中的优化策略 数据应当按两种类别进行组织:频繁访问的数据和频繁修改的数据。对于频繁访问但是不频繁修改的数据,内部设计应当物理不规范化。对于频繁修改但并不频繁访问的数据,内部设计应当物理规范化。 四、合理设计和管理表 1、利用表分区 分区将数据在物理上分隔开,不同分区的数据可以制定保存在处于不同磁盘上的数据文件里。 2、避免出现行连接和行迁移 3、控制碎片 4、别名的使用 别名是大型数据库的应用技巧,就是表名、列名在查询中以一个字母为别名,查询速度要比建连接表快1.5倍。 5、回滚段的交替使用 五、索引Index的优化设计 1、管理组织索引 索引可以大大加快数据库的查询速度,索引把表中的逻辑值映射到安全的RowID,因此索引能进行快速定位数据的物理地址。 六、多CPU和并行查询PQO(Parallel Query Option)方式的利用 七、实施系统资源管理分配计划 ORACLE 提供了Database Resource Manager(DRM,数据库资源管理器)来控制用户的资源分配,DBA可以用它分配用户类和作业类的系统资源百分比。在一个OLDP系统中,可给联机用户分配75%的CPU资源,剩下的25%留给批用户。另外,还可以进行CPU的多级分配。除了进行CPU资源分配外,DRM还可以对资源用户组执行并行操作的限制。 八、使用最优的数据库连接和SQL优化方案 九、充分利用数据的后台处理方案减少网络流量 1、合理创建临时表或视图 2、数据库打包技术的充分利用 利用数据库描述语言编写数据库的过程或函数,然后把过程或函数打成包在数据库后台统一运行包即可。 3、数据复制、快照、视图,远程过程调用技术的运用
㈥ 怎么设计用户权限管理系统数据库要用到哪几张表每张表有哪些字段
什么样的权限?菜单权限?
一般用户表,角色表,模块表(或者菜单啊反正是你要权限的东西),然后角色和模块的表
这是最简单的结构,用户关联角色,角色关联模块,用角色去控制权限,增删改查什么的模块表呢,就是你要控制的东西,比菜单,根据登录人的角色,看有哪些模块,然后显示这些模块其他的模块隐藏。
如果需要复杂的东西,中间可以加别的东西,具体看你需求了
至于字段,用户和角色就没什么可说的,无法就是名字啊什么的
模块表也简单,比如模块名称,ID,父子模块id(如果有父子模块的话),具体字段还是要看需求。
㈦ 怎么设计用户权限管理系统数据库
一般用户表,角色表,模块表(或者菜单啊反正是你要权限的东西),然后角色和模块的表
这是最简单的结构,用户关联角色,角色关联模块,用角色去控制权限,增删改查什么的模块表呢,就是你要控制的东西,比菜单,根据登录人的角色,看有哪些模块,然后显示这些模块其他的模块隐藏。
如果需要复杂的东西,中间可以加别的东西,具体看你需求了。
㈧ 概念数据库设计的主要任务是什么应该完成哪些工作
数据库设计可以分为概念结构设计、逻辑结构设计和物理结构设计三个阶段。
(1)概念结构设计。这是数据库设计的第一个阶段,在管理信息系统的分析阶段,已经得到了系统的数据流程图和数据字典,现在要结合数据规范化的理论,用一种数据模型将用户的数据需求明确地表示出来。
概念数据模型是面向问题的模型,反映了用户的现实工作环境,是与数据库的具体实现技术无关的。建立系统概念数据模型的过程叫做概念结构设计。
(2)逻辑结构设计。根据已经建立的概念数据模型,以及所采用的某个数据库管理系统软件的数据模型特性,按照一定的转换规则,把概念模型转换为这个数据库管理系统所能够接受的逻辑数据模型。不同的数据库管理系统提供了不同的逻辑数据模型,如层次模型、网状模型、关系模型等。
(3)物理结构设计。为一个确定的逻辑数据模型选择一个最适合应用要求的物理结构的过程,就叫做数据库的物理结构设计。数据库在物理设备上的存储结构和存取方法称为数据库的物理数据模型。
数据库(Database)是按照数据结构来组织、存储和管理数据的仓库,它产生于距今六十多年前,随着信息技术和市场的发展,特别是二十世纪九十年代以后,数据管理不再仅仅是存储和管理数据,而转变成用户所需要的各种数据管理的方式。数据库有很多种类型,从最简单的存储有各种数据的表格到能够进行海量数据存储的大型数据库系统都在各个方面得到了广泛的应用。
在信息化社会,充分有效地管理和利用各类信息资源,是进行科学研究和决策管理的前提条件。数据库技术是管理信息系统、办公自动化系统、决策支持系统等各类信息系统的核心部分,是进行科学研究和决策管理的重要技术手段。
㈨ 怎么设计用户权限管理系统数据库要用到哪几张表每张表有哪些字段
1、首先在oracle数据库创建教学管理系统需,要用到的数据表如下。