数据库设计方案

Ⅰ 数据库怎么设计多对多的数据表

1.数据库中的多对多关联关系一般需采用中间表的方式处理，将多对多转化为两个一对多。
2.通过表的关系，来帮助我们怎样建表，建几张表。
一对一
一张表的一条记录一定只能与另外一张表的一条记录进行对应，反之亦然。

学生表：姓名，性别，年龄，身高，体重，籍贯，家庭住址，紧急联系人
其中姓名、性别、年龄、身高，体重属于常用数据，但是籍贯、住址和联系人为不常用数据
如果每次查询都是查询所有数据，不常用的数据就会影响效率，实际又不用
常用信息表：ID(P)，姓名，性别，年龄，身高，体重
不常用信息表：ID(P)，籍贯，家庭住址，紧急联系人

解决方案：将常用的和不常用的信息分享存储，分成两张表
不常用信息表和常用信息表，保证不常用信息表与常用信息表能够对应上：找一个具有唯一性的
字段来共同连接两张表。
一个常用表中的一条记录永远只能在一张不常用表中匹配一条记录，反之亦然。
一对多
一张表中有一条记录可以对应另外一张表中的多条记录；但是反过来，另外一张表的一条记录
只能对应第一张表的一条记录，这种关系就是一对多或多对一
母亲与孩子的关系：母亲，孩子两个实体
母亲表：ID(P),名字，年龄，性别
孩子表：ID(P),名字，年龄，性别
以上关系：一个妈妈可以在孩子表中找到多条记录（也可能是一条），但是一个孩子只能找到一个妈妈
是一种典型的一对多的关系。
但是以上设计：解决了实体的设计表问题，但是没有解决关系问题，孩子找不到母亲，母亲也找不到孩子

解决方案：在某一张表中增加一个字段，能够找到另外一张表中的记录:在孩子表中增加一个字段
指向母亲表，因为孩子表的记录只能匹配到一条母亲表的记录。
母亲表：ID(P),名字，年龄，性别
孩子表：ID(P),名字，年龄，性别，母亲表ID（母亲表主键）
多对多
一对表中（A）的一条记录能够对应另外一张表（B）中的多条记录；同时B表中的一条记录
也能对应A表中的多条记录

老师和学生
老师表 T_ID(P),姓名，性别
学生表 S_ID(P),姓名，性别
以上设计方案：实现了实体的设计，但是没有维护实体的关系
一个老师教过多个学生，一个学生也被多个老师教过

解决方案：增加一张中间关系表
老师与学生的关系表：ID(P),T_ID,S_ID
老师表与中间表形成一对多的关系，而中间表是多表；维护了能够唯一找到一表的关系；
同样的学生表与中间表也是一个一对多的关系;
学生找老师：找出学生ID--->中间表寻找匹配记录（多条）--->老师表匹配（一条）
老师找学生：找出老师ID--->中间表寻找匹配记录（多条）--->学生表匹配（一条）

Ⅱ 大学生信息数据库改怎么设计

第二个看上去好些。但是联合主键太多，个人不建议这样设计。
你的两种设计都有硬伤：耦合度太高。
我想多说两句的事，数据的主键、外键是很强的约束，能够解决很多问题；可是同样会带来很多问题。如果想让系统更加灵活，就不能把表结构设计得太死。依赖关系不能太强。否则，如果你的系统需要扩展，你的数据库就要修改。打个比方，地基都改了，那么上面的建筑自然也要动。不然系统就会瘫痪。

下面说说我的建议：
方案一：每张表中都增加一个字段，确保此字段全表唯一。比如可以叫做 unique_id，用来唯一定位数据，类似rowid。联合主键全都不要。我知道你会问，这样一来就没有主外键约束，就会出现重复的，或者没有依赖关系的数据。解决这个不难，程序控制。可以使用存储过程，在固化数据，修改或删除数据时加以控制。
这样做的好处是只要整个设计不改动，数据库无需调整。
当然也有缺点，投入量会大，很多控制需要编写代码。

方案二：采用你的第一种设计方式，从数据入手，将每张表中的id都采用一定的规则，比如：专业id中前几位由系id组成，确保不同系中不会出现相同的专业id。其他表以此类推。不过这个方案也依赖程序中对各种id生成时的控制。
相比方案一，程序量较小。

方案三：也就是你的第二种方案，把对数据的控制都交给主键和外键。不过不建议。

自己斟酌一下吧。

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

1． 对图书馆的信息建几个表，考虑表之间的关系。
2．系统功能的基本要求：
a) 对数据库的编辑功能：对图书馆信息记录的添加、修改、删除。
b) 对图书的统计（国内图书、国外图书、计算机图书、外语图书、中文图等各类图书的统计）。
c) 对图书的查询（按关键字查询、模糊查询等）；
d) 对报表的打印；
e) 界面友好。

1、概述
包括项目背景、编写目的、软件定义、开发环境等内容。
2、需求分析
问题陈述、需完成的功能。
用数据流图、数据字典、判断树等完成。
3、数据库概念设计
画出ER模型图
4、数据库逻辑设计
把ER模型图转换为关系表。
描述每一个基本表关系。要求所有关系达到BCNF范式。
定义视图、定义索引、主关键字、定义权限。
5 物理设计
主要用到存取方法
6、结束语
写出完成本课程设计的心得，领会数据库理论与软件开发实践的关系。有哪些收获。软件还需要哪些改进。
设计结果：设计报告，源程序代码。

Ⅳ 数据库规划一般要包含那些内容

总体数据规划主要从三个方面去规划：1、管理方面、2、技术方面 3、用户方面。
总体规划的内容包括：战略的业务规划、战略的信息技术规划、战略的数据规划。

Ⅳ 大型Oracle数据库如何设计

超大型系统的特点为： 1、处理的用户数一般都超过百万，有的还超过千万，数据库的数据量一般超过1TB; 2、系统必须提供实时响应功能，系统需不停机运行，要求系统有很高的可用性及可扩展性。 为了能达到以上要求，除了需要性能优越的计算机和海量存储设备外，还需要先进的数据库结构设计和优化的应用系统。 一般的超大型系统采用双机或多机集群系统。下面以数据库采用Oracle 8.0.6并行服务器为例来谈谈超大型数据库设计方法： 确定系统的ORACLE并行服务器应用划分策略 数据库物理结构的设计 系统硬盘的划分及分配 备份及恢复策略的考虑 二、Oracle并行服务器应用划分策略 Oracle并行服务器允许不同节点上的多个INSTANCE实例同时访问一个数据库，以提高系统的可用性、可扩展性及性能。Oracle并行服务器中的每个INSTANCE实例都可将共享数据库中的表或索引的数据块读入本地的缓冲区中，这就意味着一个数据块可存在于多个INSTANCE实例的SGA区中。那么保持这些缓冲区的数据的一致性就很重要。Oracle使用 PCM( Parallel Cache Management)锁维护缓冲区的一致性，Oracle同时通过I DLM(集成的分布式锁管理器)实现PCM 锁,并通过专门的LCK进程实现INSTANCE实例间的数据一致。 考虑这种情况：INSTANCE1对BLOCK X块修改，这时INSTANCE2对BLOCK X块也需要修改。Oracle并行服务器利用PCM锁机制，使BLOCK X从INSTANCE 1的SGA区写入数据库数据文件中，又从数据文件中把BLOCK X块读入INSTANCE2的SGA区中。发生这种情况即为一个PING。PING使原来1个MEMORY IO可以完成的工作变成2个DISK IO和1个 MEMORY IO才能够完成,如果系统中有过多的PING，将大大降低系统的性能。 Oracle并行服务器中的每个PCM锁可管理多个数据块。PCM锁管理的数据块的个数与分配给一个数据文件的PCM锁的个数及该数据文件的大小有关。当INSTANCE 1和INSTANCE 2要操作不同的BLOCK，如果这些BLOCK 是由同一个PCM锁管理的,仍然会发生PING。这些PING称为FALSE PING。当多个INSTANCE访问相同的BLOCK而产生的PING是TRUE PING。 合理的应用划分使不同的应用访问不同的数据，可避免或减少TRUE PING;通过给FALSE PING较多的数据文件分配更多的PCM锁可减少 FALSE PING的次数，增加PCM锁不能减少TRUE PING。 所以，Oracle并行服务器设计的目的是使系统交易处理合理的分布在INSTANCE实例间，以最小化PING，同时合理的分配PCM锁，减少FALSE PING。设计的关键是找出可能产生的冲突，从而决定应用划分的策略。应用划分有如下四种方法： 1、根据功能模块划分，不同的节点运行不同的应用 2、根据用户划分，不同类型的用户运行在不同的节点上 3、根据数据划分，不同的节点访问不同的数据或索引 4、根据时间划分，不同的应用在不同的时间段运行 应用划分的两个重要原则是使PING最小化及使各节点的负载大致均衡。 三、数据库物理结构的设计 数据库物理结构设计包括确定表及索引的物理存储参数，确定及分配数据库表空间，确定初始的回滚段，临时表空间，redo log files等，并确定主要的初始化参数。物理设计的目的是提高系统的性能。整个物理设计的参数可以根据实际运行情况作调整。 表及索引数据量估算及物理存储参数的设置 表及索引的存储容量估算是根据其记录长度及估算的最大记录数确定的。在容量计算中考虑了数据块的头开销及记录和字段的头开销等等。

Ⅵ 如何设计稳健的数据库之如何减少磁盘IO

1、首先你要确定的数据库的量。这点很重要，决定了你的设计方案。

2、要根据你的业务来决定你的数据类型。不要总选varchar(50)来代替Int，有些人认为varchar什么数据都支持，所以就选这个类型，其实数据库是保存在磁盘上的，如果10000000这个数字，在Int中就是4个字节，而在varhchar就是保留8个字节，因为选择这个数据类型，就需要多读一倍的磁盘数据，给磁盘IO带来负担。