求一份图书管理系统的数据库设计方案

求一份图书管理系统的数据库设计方案,第1张

1、要了解ER图的核心要素:实体,属性,关系,实体就是一个个对象,比如猫,属性就是实体所有的某个属性,比如猫的性别,关系就是实体和实体之间或者实体内部之间的关系。

2、要了解ER图中怎么表示1中描述的三个核心要素:在ER图中矩形代表实体,椭圆代表属性,菱形代表关系,各个形状之间用线段连接。

3、以同样的方式定义课程实体后建关系表,拖进关系线段,连接两个实体,注意两头都是红色才是真正的连接起来了。会自动在关系属性里建立起连接。

扩展资料:

图书借阅管理系统注意事项:

一个实体型转换为一个关系模式。关系的属性:实体型的属性,关系的码:实体型的码。

一个1:1联系可以转换为一个独立的关系模式,也可以与任何一端对应的关系模式合并。一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。一个m:n联系转换为一个关系模式。

三个或三个以上实体间的一个多元联系可以转换为一个关系模式,具有相同码的关系模式可合并,同一实体集的实体之间的联系即自联系,也可以按1:1,1:n和m:n三种情况分别处理。

数据库是整个软件应用的根基,是软件设计的起点,它起着决定性的质变作用,因此我们必须对数据库设计高度重视起来,培养设计良好数据库的习惯,是一个优秀的软件设计师所必须具备的基本素质条件!

那么我们要做到什么程度才是对的呢?下面就说说数据库设计的原则:

1、数据库设计最起码要占用整个项目开发的40%以上的时间

数据库是需求的直观反应和表现,因此设计时必须要切实符合用户的需求,要多次与用户沟通交流来细化需求,将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确,就要分析不确定的因素,设计表时就要事先预留出可变通的字段,正所谓“有备无患”。

2、数据库设计不仅仅停留于页面demo的表面

页面内容所需要的字段,在数据库设计中只是一部分,还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段,因此数据库设计绝对不是简单的基本数据存储,还有逻辑数据存储。

3、数据库设计完成后,项目80%的设计开发在你脑海中就已经完成了

每个字段的设计都是有他必要的意义的,你在设计每一个字段的同时,就应该已经想清楚程序中如何去运用这些字段,多张表的联系在程序中是如何体现的。换句话说,你完成数据库设计后,程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度,那当进入编码阶段后,才发现要运用的技术或实现的方式数据库无法支持,这时再改动数据库就会很麻烦,会造成一系列不可预测的问题。

4、数据库设计时就要考虑到效率和优化问题

一开始就要分析哪些表会存储较多的数据量,对于数据量较大的表的设计往往是粗粒度的,也会冗余一些必要的字段,已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时,一般都会对主键建立聚集索引,含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时,还要考虑是否有必要采用存储过程。

5、添加必要的(冗余)字段

像“创建时间”、“修改时间”、“备注”、“ *** 作用户IP”和一些用于其他需求(如统计)的字段等,在每张表中必须都要有,不是说只有系统中用到的数据才会存到数据库中,一些冗余字段是为了便于日后维护、分析、拓展而添加的,这点是非常重要的,比如黑客攻击,篡改了数据,我们便就可以根据修改时间和 *** 作用户IP来查找定位。

6、设计合理的表关联

若多张表之间的关系复杂,建议采用第三张映射表来关联维护两张表之间的关系,以降低表之间的直接耦合度。若多张表涉及到大数据量的问题,表结构尽量简单,关联也要尽可能避免。

7、设计表时不加主外键等约束性关联,系统编码阶段完成后再添加约束性关联

这样做的目的是有利于团队并行开发,减少编码时所遇到的问题,表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆就不加表关联。

8、选择合适的主键生成策略

以上就是关于求一份图书管理系统的数据库设计方案全部的内容,包括:求一份图书管理系统的数据库设计方案、在系统设计中,对数据库的设计应考虑哪些设计原则、等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/sjk/10202883.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-06
下一篇 2023-05-06

发表评论

登录后才能评论

评论列表(0条)

保存