简单点根据借书的面意思建立连三张表就能完成借书管理。
tbl1学生表
tbl2图书表
tbl3借书表
学生和图书的关系是1:n。当然这个n是可以限制的。而这个关系则是在借书表中展示出来例如有字段
id studentId bookId
做借书系统应该主要是为了考察你们的表关联查询,以及对简单逻辑的观察
人力资源管理信息系统毕业论net方向,vs做前台,sql做后台数据库的文:
3512设计全局ER模式
所有局部ER模式都设计好了后,接下来就是把它们综合成单一的全局概念结构。全局概念结构不仅要支持所有局部ER模式,而且必须合理地表示一个完整、一致的数据库概念结构。
1) 确定公共实体类型
为了给多个局部ER模式的合并提供开始合并的基础,首先要确定各局部结构中的公共实体类型。在这一步中我们仅根据实体类型名和键来认定公共实体类型。一般把同名实体类型作为公共实体类型的一类候选,把具有相同键的实体类型作为公共实体类型的另一类候选。
2) 局部ER模式的合并
合并的原则是:首先进行两两合并;先合并那些现实世界中有联系的局部结构;合并从公共实体类型开始,最后再加入独立的局部结构。
3) 消除冲突
冲突分为三类:属性冲突、结构冲突、命名冲突。
设计全局ER模式的目的不在于把若干局部ER模式形式上合并为一个ER模式,而在于消除冲突,使之成为能够被所有用户共同理解和接受的同一的概念模型。
4) 全局ER模式的优化
在得到全局ER模式后,为了提高数据库系统的效率,还应进一步依据处理需求对ER模式进行优化。一个好的全局ER模式,除能准确、全面地反映用户功能需求外,还应满足下列条件:实体类型的个数要尽可能的少;实体类型所含属性个数尽可能少;实体类型间联系无冗余。
人力资源管理系统的全局ER模式如图所示:
参考全文 >
一:表中应该避免可为空的列;二:表不应该有重复的值或者列;三: 表中记录应该有一个唯一的标识符 在数据库表设计的时候,数据库管理员应该养成一个好习惯,用一个ID号来 唯一的标识行记录,而不要通过名字、编号等字段来对纪录进行区分。每个表都应该有一个ID列,任何两个记录都不可以共享同一个ID值。另外,这个ID值最 好有数据库来进行自动管理,而不要把这个任务给前台应用程序。否则的话,很容易产生ID值不统一的情况。另外,在数据库设计的时候,最好还能 够加入行号。如在销售订单管理中,ID号是用户不能够维护的。但是,行号用户就可以维护。如在销售订单的行中,用户可以通过调整行号的大小来对订单行进行 排序。通常情况下,ID列是以1为单位递进的。但是,行号就要以10为单位累进。如此,正常情况下,行号就以10、20、30依次扩展下去。若此时用户需 要把行号为30的纪录调到第一行显示。此时,用户在不能够更改ID列的情况下,可以更改行号来实现。如可以把行号改为1,在排序时就可以按行号来进行排 序。如此的话,原来行号为30的纪录现在行号变为了1,就可以在第一行中显示。这是在实际应用程序设计中对ID列的一个有效补充。这个内容在教科书上是没 有的。需要在实际应用程序设计中,才会掌握到这个技巧。四:数据库对象要有统一的前缀名 一个比较复杂的应用系统,其对应的数据库表往往以千计。若让数据库管理员看到对象名就了解这个数据库对象所起的作用,恐怕会比较困难。而且在数据库对象引用的时候,数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。 为此,笔者建立,在开发数据库之前,最好能够花一定的时间,去制定一个数据库对象的前缀命名规范。如笔者在数据库设计时,喜欢跟前台应用程序协商,确定 合理的命名规范。笔者最常用的是根据前台应用程序的模块来定义后台数据库对象前缀名。如跟物料管理模块相关的表可以用M为前缀;而以订单管理相关的,则可 以利用C作为前缀。具体采用什么前缀可以以用户的爱好而定义。但是,需要注意的是,这个命名规范应该在数据库管理员与前台应用程序开发者之间达成共识,并 且严格按照这个命名规范来定义对象名。其次,表、视图、函数等最好也有统一的前缀。如视图可以用V为前缀,而函数则可以利用F为前缀。如此数据库管理员无论是在日常管理还是对象引用的时候,都能够在最短的时间内找到自己所需要的对象。五:尽量只存储单一实体类型的数据 这里将的实体类型跟数据类型不是一回事,要注意区分。这里讲的实体类型 是指所需要描述对象的本身。笔者举一个例子,估计大家就可以明白其中的内容了。如现在有一个图书馆里系统,有图书基本信息、作者信息两个实体对象。若用户 要把这两个实体对象信息放在同一张表中也是可以的。如可以把表设计成图书名字、图书作者等等。可是如此设计的话,会给后续的维护带来不少的麻烦。 如当后续有图书出版时,则需要为每次出版的图书增加作者信息,这无疑会增加额外的存储空间,也会增加记录的长度。而且若作者的情况有所改变,如住址改变 了以后,则还需要去更改每本书的记录。若这个作者的图书从数据库中全部删除之后,这个作者的信息也就荡然无存了。很明显,这不符合数据库设计规范化的需 求。遇到这种情况时,笔者建议可以把上面这张表分解成三种独立的表,分别为图书基本信息表、作者基本信息表、图书与作者对应表等等。如此设计以后,以上遇到的所有问题就都引刃而解了。
数据库应用系统的开发是一项软件工程。一般可分为以下几个阶段:
1规划。
2需求分析。
3概念模型设计。
4逻辑设计。
5物理设计。
6程序编制及调试。
7运行及维护。
买家,卖家,这两个实体你没有问题了;
那再加货物,收益两个实体
货物有如下信息:货物编号,货物 名称,货物价格,货物产地。
收益有如下信息:货物编号,进货价,售货价,进货日期,售货日期
以上就是关于怎么用数据库做个简单的借书管理系统全部的内容,包括:怎么用数据库做个简单的借书管理系统、SQL数据库 做一个人力资源管理系统、开发一个完整的数据库系统具体的流程是什么等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)