关系可以是
对、对多、多对多关系
在般情况下
它们是对关系:即张原始单据对应且只对应个实体在特殊情况下它们可能是对多或多对关系即张原始单证对应多个实体或多张原始单证对应个实体这里实体可以理解为基本表明确这种对应关系后对我们设计录入界面大有好处
〖例1〗:份员工履历资料在人力资源信息系统中就对应 3个基本表:员工基本情况表、社会关系表、工作简历表这就是“张原始单证对应多个实体”典型例子2. 主键和外键
般而言个实体不能既无主键又无外键在E—R 图中, 处于叶子部位实体, 可以定义主键也可以不定义主键(
它无子孙), 但必须要有外键(它有父亲)主键和外键
设计在全局数据库设计中占有重要地位当全局数据库设计完成以后有个美国数据库设计专家说:“键到处都是键除了键的外什么也没有”这就是他数据库设计经验的谈也反映了他对信息系统核心(数据模型)高度抽象思想:主键是实体高度抽象主键和外键配对表示实体的间连接3. 基本表
性质基本表和中间表、临时表区别
它具有如下 4个特性:(1) 原子性
基本表中字段是不可再分解(2) 原始性
基本表中记录是原始数据(基础数据)记录(3) 演绎性
由基本表和代码表中数据可以派生出所有输出数据(4) 稳定性
基本表结构是相对稳定表中记录是要长期保存理解基本表
性质后在设计数据库时就能将基本表和中间表、临时表区分开来4. 范式标准
基本表及其字段的间
关系, 应尽量满足第 3范式但是满足第 3范式数据库设计往往不是最好设计为了提高数据库运行效率常常需要降低范式标准:适当增加冗余达到以空间换时间目〖例2〗:有
张存放商品基本表如表1所示“金额”这个字段存在表明该表设计不满足第 3范式“金额”可以由“单价”乘以“数量”得到介绍说明“金额”是冗余字段但是增加“金额”这个冗余字段可以提高查询统计速度这就是以空间换时间作法在Rose 2002中
规定列有两种类型:数据列和计算列“金额”这样列被称为“计算列”而“单价”和“数量”这样列被称为“数据列”表1 商品表
表结构商品名称 商品型号 单价 数量 金额
电视机 29吋 2,500 40 100,000
5. 通俗地理解 3个范式
通俗地理解 3个范式
对于数据库设计大有好处在数据库设计中为了更好地应用 3个范式就必须通俗地理解 3个范式(通俗地理解是够用理解并不是最科学最准确理解):第
范式:1NF是对属性原子性约束要求属性具有原子性不可再分解；第 2范式:2NF是对记录
惟性约束要求记录有惟标识即实体惟性；第 3范式:3NF是对字段冗余性
约束即任何字段不能由其他字段派生出来它要求字段没有冗余.没有冗余
数据库设计可以做到但是没有冗余数据库未必是最好数据库有时为了提高运行效率就必须降低范式标准适当保留冗余数据具体做法是:在概念数据模型设计时遵守第 3范式降低范式标准工作放到物理数据模型设计时考虑降低范式就是增加字段允许冗余6. 要善于识别和正确处理多对多
关系若两个实体的间存在多对多
关系则应消除这种关系消除办法是在两者的间增加第 3个实体这样原来个多对多关系现在变为两个对多关系要将原来两个实体属性合理地分配到 3个实体中去这里第 3个实体实质上是个较复杂关系它对应张基本表般来讲数据库设计工具不能识别多对多关系但能处理多对多关系〖例3〗:在“图书馆信息系统”中
“图书”是个实体“读者”也是个实体这两个实体的间关系是个典型多对多关系:本图书在区别时间可以被多个读者借阅个读者又可以借多本图书为此要在 2者的间增加第 3个实体该实体取名为“借还书”它属性为:借还时间、借还标志(0表示借书1表示还书)另外它还应该有两个外键(“图书”主键“读者”主键)使它能和“图书”和“读者”连接7. 主键PK
取值思路方法PK是供
员使用表间连接工具可以是无物理意义数字串, 由自动加1来实现也可以是有物理意义字段名或字段名组合不过前者比后者好当PK是字段名组合时建议字段个数不要太多多了不但索引占用空间大而且速度也慢8. 正确认识数据冗余
主键和外键在多表中
重复出现, 不属于数据冗余这个概念必须清楚事实上有许多人还不清楚非键字段重复出现, 才是数据冗余！而且是种低级冗余即重复性冗余高级冗余不是字段重复出现而是字段派生出现〖例4〗:商品中
“单价、数量、金额” 3个字段“金额”就是由“单价”乘以“数量”派生出来它就是冗余而且是种高级冗余冗余目是为了提高处理速度只有低级冗余才会增加数据不致性同数据可能从区别时间、地点、角色上多次录入因此我们提倡高级冗余(派生性冗余)反对低级冗余(重复性冗余)9. E–R图没有标准答案
信息系统
E–R图没有标准答案它设计和画法不是惟只要它覆盖了系统需求业务范围和功能内容就是可行反的要修改E–R图尽管它没有惟标准答案并不意味着可以随意设计好E—R图标准是:结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余10. 视图技术在数据库设计中很有用
和基本表、代码表、中间表区别
视图是种虚表它依赖数据源实表而存在视图是供员使用数据库个窗口是基表数据综合种形式, 是数据处理种思路方法是用户数据保密种手段为了进行复杂处理、提高运算速度和节省存储空间, 视图定义深度般不得超过 3层 若 3层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图这样反复交迭定义, 视图深度就不受限制了对于某些和国家政治、经济、技术、军事和安全利益有关
信息系统视图作用更加重要这些系统基本表完成物理设计的后立即在基本表上建立第层视图这层视图个数和结构和基本表个数和结构是完全相同并且规定所有员律只准在视图上操作只有数据库管理员带着多个人员共同掌握“安全钥匙”才能直接在基本表上操作请读者想想:这是为什么？11. 中间表、报表和临时表
中间表是存放统计数据
表它是为数据仓库、输出报表或查询结果而设计有时它没有主键和外键(数据仓库除外)临时表是员个人设计存放临时记录为个人所用基表和中间表由DBA维护临时表由员自己用自动维护12. 完整性约束表现在 3个方面
域
完整性:用Check来实现约束在数据库设计工具中对字段取值范围进行定义时有个Check按钮通过它定义字段值城参照完整性:用PK、FK、表级触发器来实现用户定义完整性:它是些业务规则用存储过程和触发器来实现13. 防止数据库设计打补丁
思路方法是“ 3少原则”(1)
个数据库中表个数越少越好只有表个数少了才能介绍说明系统E–R图少而精去掉了重复多余实体形成了对客观世界高度抽象进行了系统数据集成防止了打补丁式设计；(2)
个表中组合主键字段个数越少越好主键作用是建主键索引 2是做为子表外键所以组合主键字段个数少了不仅节省了运行时间而且节省了索引存储空间；(3)
个表中字段个数越少越好只有字段个数少了才能介绍说明在系统中不存在数据重复且很少有数据冗余更重要是督促读者学会“列变行”这样就防止了将子表中字段拉入到主表中去在主表中留下许多空余字段所谓“列变行”就是将主表中部分内容拉出去另外单独建个子表这个思路方法很简单有人就是不习惯、不采纳、不执行数据库设计
实用原则是:在数据冗余和处理速度的间找到合适平衡点“ 3少”是个整体概念综合观点不能孤立某个原则该原则是相对不是绝对“ 3多”原则肯定是
试想:若覆盖系统同样功能百个实体(共千个属性) E–R图肯定比 2百个实体(共 2千个属性) E–R图要好得多提倡“ 3少”原则
是叫读者学会利用数据库设计技术进行系统数据集成数据集成步骤是将文件系统集成为应用数据库将应用数据库集成为主题数据库将主题数据库集成为全局综合数据库集成程度越高数据共享性就越强信息孤岛现象就越少整个企业信息系统全局E—R图中实体个数、主键个数、属性个数就会越少提倡“ 3少”原则
目是防止读者利用打补丁技术不断地对数据库进行增删改使企业数据库变成了随意设计数据库表“垃圾堆”或数据库表“大杂院”最后造成数据库中基本表、代码表、中间表、临时表杂乱无章不计其数导致企事业单位信息系统无法维护而瘫痪“ 3多”原则任何人都可以做到
该原则是“打补丁思路方法”设计数据库歪理学说“ 3少”原则是少而精原则它要求有较高数据库设计窍门技巧和艺术不是任何人都能做到该原则是杜绝用“打补丁思路方法”设计数据库理论依据14. 提高数据库运行效率
办法在给定
系统硬件和系统软件Software条件下提高数据库系统运行效率办法是:(1) 在数据库物理设计时
降低范式增加冗余, 少用触发器, 多用存储过程(2) 当计算非常复杂、而且记录条数非常巨大时(例如
千万条)复杂计算要先在数据库外面以文件系统方式用C
语言计算处理完成的后最后才入库追加到表中去这是电信计费系统设计经验(3) 发现某个表
记录太多例如超过千万条则要对该表进行水平分割水平分割做法是以该表主键PK某个值为界线将该表记录水平分割为两个表若发现某个表字段太多例如超过 8十个则垂直分割该表将原来个表分解为两个表(4) 对数据库管理系统DBMS进行系统优化
即优化各种系统参数如缓冲区个数(5) 在使用面向数据
SQL语言进行设计时尽量采取优化算法总的
要提高数据库运行效率必须从数据库系统级优化、数据库设计级优化、实现级优化这 3个层次上同时下功夫上述十 4个窍门技巧
是许多人在大量数据库分析和设计实战中逐步整理总结出来对于这些经验运用读者不能生帮硬套死记硬背而要消化理解实事求是灵活掌握并逐步做到:在应用中发展在发展中应用
最新评论