数据库设计例子

数据库设计范式实例:假设某建筑公司要设计一个数据库。公司的业务规则概括说明如下:

公司承担多个工程项目,每一项工程有:工程号、工程名称、施工人员等;

公司有多名职工,每一名职工有:职工号、姓名、性别、职务(工程师、技术员)等;

公司按照工时和小时工资率支付工资,小时工资率由职工的职务决定(例如,技术员的小时工资率与工程师不同)。

公司定期制定一个工资报表,如图-1所示。

显然上表并不是一个数据库中的表,只是一个书面的表格。现对其设计成为数据库中间的表。如下图在数据库中有一个这样的表。

但是该表也存在如下问题:

表中包含大量的冗余,可能会导致数据异常:

a.更新异常 例如,修改职工号=1001的职务,则必须修改所有职工号=1001的行。

b.添加异常 若要增加一个新的职工时,首先必须给这名职工分配一个工程。或者为了添加一名新职工的数据,先给这名职工分配一个虚拟的工程。(因为主关键字不能为空)

c.删除异常 例如,1001号职工要辞职,则必须删除所有职工号=1001的数据行。这样的删除操作,很可能丢失了其它有用的数据。

现可以对以上表进行重新设计:

用函数依赖图表示所有属性之间存在的函数依赖关系,如图3所示。

1. 图上方的箭头表示关键属性决定非关键属性。

2. 图下方的箭头表示属性之间的函数依赖性。

职工信息表:

职工号


姓名


职务


1001


齐光明


Q01


1002


李思岐


Q02


1003


鞠明亮


Q03


1004


葛宇洪


Q04

职务工资表

职务编号


职务名称


小时工资率


Q01


工程师


65


Q02


技术员


60


Q03


工人


55

工程项目表:

工程号


工程名


A1


花园大厦


A2


立交桥


A3


临江饭店

职工参与工程项目表

编号


工程号


职工号


工时


1


A1


1001


13


2


A1


1002


16


3


A1


1004


19


4


A2


1001


15


5


A2


1003


17


6


A3


1002


18


7


A3


1004


14

另外,

数据库的物理设计要从优化操作系统、磁盘布局优化和配置、数据库初始化参数的选择、设置和管理内存、设置和管理CPU、设置和管理表空间、设置和管理回滚段、设置和管理联机重做日志、设置和管理归档重做日志、设置和管理控制文件等几个方面来考虑。

时间: 2024-10-13 21:18:28

数据库设计例子的相关文章

一个简单数据库设计例子

一个曾经做过的简单的管理系统中数据库设计的例子,包括设计表.ER图.建模.脚本. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 项目信息 Project Name:   Book Manager System DB:                MySQL5.5 DB Name:         db_library Tables: 1). tb_book

从零开始编写自己的C#框架(9)——数据库设计与创建

对于千万级与百万级数据库设计是有所区别的,由于本项目是基于中小型软件开发框架来设计,记录量相对会比较少,所以数据库设计时考虑的角度是:与开发相结合:空间换性能:空间换开发效率:减少null异常......当然不同的公司与项目要求不同,初学者要学会适应不同的项目开发要求,使用本框架开发时,必须严格按照本章节的要求来设计数据库,不然可能会产生不可控的异常. 从零开始编写自己的C#框架 数据库设计规范   文件状态: [√] 草稿 [  ] 正式发布 [  ] 正在修改 文件标识: C#框架 当前版本

Oracle数据库设计第三范式

一.数据库设计范式及其意义和不足 数据库的设计范式是数据库设计所需要满足的规范,数据库的规范化是优化表的结构和优化把数据组织到表中的方式,这样使数据更明确,更简洁.实践中,通常把一个数据库分成两个或多个表并定义表之间的关系以做到数据隔离,添加.删除和修改某个字段只需要在一个表中进行,接着可以通过定义的关系传递到数据库中剩余的表中(和分层思想的意义所在很相似).这样我们可以消除很多错误或垃圾数据出现的机会并减轻更新信息所必要的工作量. 目前,主要有六种范式:第一范式.第二范式.第三范式.BC范式.

机房收费系统合作——再看数据库设计

机房合作我负责了最简单的D层,接口层,工厂层.反正D层是我来写,于是数据库索性也就顺便设计了.已经是第三次敲机房收费系统了,每次都是相隔半年左右吧.需求搞得透透的了,数据库也就好设计了.基本跟第二次没什么大的区别,就是把Student表和Card表分开了. 重构的时候,我的数据库几乎什么都用到了:事务,存储过程,触发器,视图,联合查询等等.所以,这次设计数据库还是SO Easy的..并且,为了让婵婵和牛迁迁师哥写的方便,我把组合查询都写成了存储过程!!!!费了一番功夫,但是D层简单了不少.还记得

数据库设计中的Soft Delete模式

最近几天有点忙,所以我们今天来一篇短的,简单地介绍一下数据库设计中的一种模式——Soft Delete. 可以说,该模式毁誉参半,甚至有非常多的人认为该模式是一个Anti-Pattern.因此在本篇文章中,我们不仅仅会对该模式进行介绍,同时也会列出该模式可能导致的一系列问题,以帮助大家正确地决定是否使用该模式. Soft Delete简介 首先先来想一个需求,那就是对用户操作的回滚支持.例如我现在正在用Word编写这篇文章.当我执行了一个错误操作的时候,我仅仅需要键入Ctrl + Z就可以进行回

数据库设计二《函数依赖和三范式》

函数依赖: 定义:R(U)是在属性集U上的关系模式,X,Y是U的子集.若对于R(U)的任意一个可能关系r,r中的不可能存在两个元组在X上的属性值相等,而在Y上的属性值不等,则称X函数确定Y,或者Y函数依赖X,记作X--->Y. 单纯的概念有点难以理解,通过例子1:属性集U,关系模式R(U),子集X,Y,可能关系r1. 可以理解为X能唯一确定Y,则X--->Y.常用为主键------>其他属性 函数依赖和三范式 函数依赖的分类:完全依赖,部分依赖,传递依赖. 完全依赖和一范式 完全依赖:X

数据库设计 Step by Step (1)——扬帆启航

引言:一直在从事数据库开发和设计工作,也看了一些书籍,算是略有心得.很久之前就想针 对关系数据库设计进行整理.总结,但因为种种原因迟迟没有动手,主要还是惰性使然.今天也算是痛下决心开始这项卓绝又令我兴奋的工作.这将是一个系列的文 章,我将以讲座式的口吻展开讨论(个人偷懒,这里的总结直接拿去公司培训新人用). 系列的第一讲我们先来回答下面几个问题 数据库是大楼的根基 大多数程序员都很急切,在了解基本需求之后希望很快的进入到编码阶段(可能只有产出代码才能反映工作量),对于数据库设计思考得比较少. 这

MVC排球计分(二)——需求分析与数据库设计

需求分析和数据库的设计是很重要的一个环节,这个环节会直接影响项目的开发过程和质量. 这里做的排球计分程序是一个例子,而且其业务极为简单,因此,这里并不是真正的需求分 析和数据库设计,而是将排球计分的需求和数据库罗列至此. 需求分析: 这个项目是排球计分程序,其业务极为简单,现将其描述如下. 1.观众只能查看比赛中的数据. 2.记分员可以对比赛的每一球进行计分(哪个队员得分). 3.记分员可以对比赛的每一局进行计分(例如:第一局:25:20.第二局:25:1). 4.记分员可以对两队的总比分进行记

数据库设计中主键问题

转自: http://www.jb51.net/article/40933.htm 数据库主键在数据库中占有重要地位.主键的选取策略决定了系统是否可靠.易用.高效.本文探讨了数据库设计过程当中常见的主键选取策略,并剖析了其做主键的优缺点,提出了相应的解决问题的方法 在基于关系型数据库设计时候,通常要为每张表指定一个主键,所谓主键就是能够唯一标识表中某一行记录的属性或属性组,一个表只能有一个主键,但可以有多个候选索引.因为主键可以唯一标识某一行记录,所以可以确保执行数据更新.删除.修改时不出现错误