数据库表的设计

1、若是一对多或多对一的对象存到数据库表，原则上应该先观察对象的基本属性，然后设计一个数据表保存此对象的基本数据，并在数量关系多的一方，加外键描述数据之间的关系；

2、若是多对多对象的数据库表，原则上也是观察该对象的基本属性，然后设计一个表来保存此对象的基本数据，且需要加一个中间表来描述数据的关系；

3、若是一对一的对象的数据库设计， 除了上述 *** 作，还因为一对一的对象有主从关系，因此可加入自连接表进行设计。

数据表的设计原则:

( )不应针对整个系统进行数据库设计 而应该根据系统架构中的组件划分 针对每个组件所处理的业务进行组件单元的数据库设计;不同组件间所对应的数据库表之间的关联应尽可能减少 如果不同组件间的表需要外键关联也尽量不要创建外键关联 而只是记录关联表的一个主键 确保组件对应的表之间的独立性 为系统或表结构的重构提供可能性

( )采用领域模型驱动的方式和自顶向下的思路进行数据库设计 首先分析系统业务 根据职责定义对象 对象要符合封装的特性 确保与职责相关的数据项被定义在一个对象之内 这些数据项能够完整描述该职责 不会出现职责描述缺失 并且一个对象有且只有一项职责 如果一个对象要负责两个或两个以上的职责 应进行分拆

( )根据建立的领域模型进行数据库表的映射 此时应参考数据库设计第二范式 一个表中的所有非关键字属性都依赖于整个关键字 关键字可以是一个属性 也可以是多个属性的集合 不论那种方式 都应确保关键字能够保证唯一性 在确定关键字时 应保证关键字不会参与业务且不会出现更新异常 这时 最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字

( )由于第一点所述的领域模型驱动的方式设计数据库表结构 领域模型中的每一个对象只有一项职责 所以对象中的数据项不存在传递依赖 所以 这种思路的数据库表结构设计从一开始即满足第三范式 一个表应满足第二范式 且属性间不存在传递依赖

( )同样 由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系 所以在领域模型中的对象存在主对象和从对象之分 从对象是从 N或N N的角度进一步主对象的业务逻辑 所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常

( )在映射后得出的数据库表结构中 应再根据第四范式进行进一步修改 确保不存在多值依赖 这时 应根据反向工程的思路反馈给领域模型 如果表结构中存在多值依赖 则证明领域模型中的对象具有至少两个以上的职责 应根据第一条进行设计修正 第四范式 一个表如果满足BCNF 不应存在多值依赖

( )在经过分析后确认所有的表都满足二 三 四范式的情况下 表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构 并且 我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的 只是一个存储介质 所以 表和表之间也不应用强关联来表述业务(数据间的一致性) 这一职责应由系统的逻辑层来保证 这种方式也确保了系统对于不正确数据(脏数据)的兼容性 当然 从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据 单从另一个角度来说 脏数据的产生在一定程度上也是不可避免的 我们也要保证系统对这种情况的容错性 这是一个折中的方案

( )应针对所有表的主键和外键建立索引 有针对性的(针对一些大数据量和常用检索方式)建立组合属性的索引 提高检索效率 虽然建立索引会消耗部分系统资源 但比较起在检索时搜索整张表中的数据尤其时表中的数据量较大时所带来的性能影响 以及无索引时的排序 *** 作所带来的性能影响 这种方式仍然是值得提倡的

( )尽量少采用存储过程 目前已经有很多技术可以替代存储过程的功能如 对象/关系映射 等 将数据一致性的保证放在数据库中 无论对于版本控制 开发和部署 以及数据库的迁移都会带来很大的影响 但不可否认 存储过程具有性能上的优势 所以 当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性时 可经过平衡考虑选用存储过程

( )当处理表间的关联约束所付出的代价(常常是使用性上的代价)超过了保证不会出现修改 删除 更改异常所付出的代价 并且数据冗余也不是主要的问题时 表设计可以不符合四个范式 四个范式确保了不会出现异常 但也可能由此导致过于纯洁的设计 使得表结构难于使用 所以在设计时需要进行综合判断 但首先确保符合四个范式 然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最好办法

( )设计出的表要具有较好的使用性 主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧

lishixinzhi/Article/program/SQL/201311/16156

《数据库系统导论》（第七版）CJDate著机械工业出版社，数据库领域中的权威著作，专业理论书籍出版至第七版，在业界是罕见的，可以想见该书具有多高的水平。

《数据库系统概念》（第三版）Silberschatz著机械工业出版社光看作者的名字就知道这肯定是一本好书。

《数据库系统基础教程》清华大学出版社、《数据库系统实现》机械工业出版社JDUllman著斯坦福大学五门数据库系列课程的前两门教材，《数据库系统实现》一书的层次在我国已相当于研究生课程水平。

《数据库设计》Stephens著机械工业出版社一本不太厚也不太难的入门书。

《数据挖掘--概念与技术》JiaweiHan（韩家炜）著机械工业出版社数据挖掘领域的国际知名专家韩家炜教授最新力作，系统而全面的介绍了数据挖掘技术，可读性甚佳。

《数据库处理--基础、设计与实现》（第七版）DMKroenke著电子工业出版社很少见的使用Access作为实例介绍数据库原理与设计的书，内容清晰易懂。

《数据库系统概论》（第三版）萨师煊、王珊著高教出版社国内本科及研究生专选教材，两位作者均为我国数据库界的著名专家。

《数据库原理、编程与性能》作者:（美）PatrickO'NeilElizabethO'Neil译者:周傲英俞荣华季文_钱卫宁等

本书既强调理论又强调应用，全书众多的定义、定理、详细的证明过程、丰富的应用实例使得本书翻之有望而生畏之感，读之又有畅快淋漓之觉。实在是一本不可多得的好书，值得大家认真去学。

随着计算机技术越来越广泛地应用于国民经济的各个领域 在计算机硬件不断微型化的同时 应用系统向着复杂化 大型化的方向发展 数据库是整个系统的核心 它的设计直接关系系统执行的效率和系统的稳定性 因此在软件系统开发中 数据库设计应遵循必要的数据库范式理论 以减少冗余 保证数据的完整性与正确性 只有在合适的数据库产品上设计出合理的数据库模型 才能降低整个系统的编程和维护难度 提高系统的实际运行效率 虽然对于小项目或中等规模的项目开发人员可以很容易地利用范式理论设计出一套符合要求的数据库 但对于一个包含大型数据库的软件项目 就必须有一套完整的设计原则与技巧

一 成立数据小组

大型数据库数据元素多 在设计上有必要成立专门的数据小组 由于数据库设计者不一定是使用者 对系统设计中的数据元素不可能考虑周全 数据库设计出来后 往往难以找到所需的库表 因此数据小组最好由熟悉业务的项目骨干组成

数据小组的职能并非是设计数据库 而是通过需求分析 在参考其他相似系统的基础上 提取系统的基本数据元素 担负对数据库的审核 审核内容包括审核新的数据库元素是否完全 能否实现全部业务需求 对旧数据库（如果存在旧系统）的分析及数据转换 数据库设计的审核 控制及必要调整

二 设计原则

规范命名 所有的库名 表名 域名必须遵循统一的命名规则 并进行必要说明 以方便设计 维护 查询

控制字段的引用 在设计时 可以选择适当的数据库设计管理工具 以方便开发人员的分布式设计和数据小组的集中审核管理 采用统一的命名规则 如果设计的字段已经存在 可直接引用 否则 应重新设计

库表重复控制 在设计过程中 如果发现大部分字段都已存在 开发人员应怀疑所设计的库表是否已存在 通过对字段所在库表及相应设计人员的查询 可以确认库表是否确实重复

并发控制 设计中应进行并发控制 即对于同一个库表 在同一时间只有一个人有控制权 其他人只能进行查询

必要的讨论 数据库设计完成后 数据小组应与相关人员进行讨论 通过讨论来熟悉数据库 从而对设计中存在的问题进行控制或从中获取数据库设计的必要信息

数据小组的审核 库表的定版 修改最终都要通过数据小组的审核 以保证符合必要的要求

头文件处理 每次数据修改后 数据小组要对相应的头文件进行修改（可由管理软件自动完成） 并通知相关的开发人员 以便进行相应的程序修改

三 设计技巧

分类拆分数据量大的表 对于经常使用的表（如某些参数表或代码对照表） 由于其使用频率很高 要尽量减少表中的记录数量 例如 银行的户主账表原来设计成一张表 虽然可以方便程序的设计与维护 但经过分析发现 由于数据量太大 会影响数据的迅速定位 如果将户主账表分别设计为活期户主账 定期户主账及对公户主账等 则可以大大提高查询效率

索引设计 对于大的数据库表 合理的索引能够提高整个数据库的 *** 作效率 在索引设计中 索引字段应挑选重复值较少的字段 在对建有复合索引的字段进行检索时 应注意按照复合索引字段建立的顺序进行 例如 如果对一个 万多条记录的流水表以日期和流水号为序建立复合索引 由于在该表中日期的重复值接近整个表的记录数 用流水号进行查询所用的时间接近 秒 而如果以流水号为索引字段建立索引进行相同的查询 所用时间不到 秒 因此在大型数据库设计中 只有进行合理的索引字段选择 才能有效提高整个数据库的 *** 作效率

数据 *** 作的优化 在大型数据库中 如何提高数据 *** 作效率值得关注 例如 每在数据库流水表中增加一笔业务 就必须从流水控制表中取出流水号 并将其流水号的数值加一 正常情况下 单笔 *** 作的反应速度尚属正常 但当用它进行批量业务处理时 速度会明显减慢 经过分析发现 每次对流水控制表中的流水号数值加一时都要锁定该表 而该表却是整个系统 *** 作的核心 有可能在 *** 作时被其他进程锁定 因而使整个事务 *** 作速度变慢 对这一问题的解决的办法是 根据批量业务的总笔数批量申请流水号 并对流水控制表进行一次更新 即可提高批量业务处理的速度 另一个例子是对插表的优化 对于大批量的业务处理 如果在插入数据库表时用普通的Insert语句 速度会很慢 其原因在于 每次插表都要进行一次I/O *** 作 花费较长的时间 改进后 可以用Put语句等缓冲区形式等满页后再进行I/O *** 作 从而提高效率 对大的数据库表进行删除时 一般会直接用Delete语句 这个语句虽然可以进行小表 *** 作 但对大表却会因带来大事务而导致删除速度很慢甚至失败 解决的方法是去掉事务 但更有效的办法是先进行Drop *** 作再进行重建

数据库参数的调整 数据库参数的调整是一个经验不断积累的过程 应由有经验的系统管理员完成 以Informix数据库为例 记录锁的数目太少会造成锁表的失败 逻辑日志的文件数目太少会造成插入大表失败等 这些问题都应根据实际情况进行必要的调整

必要的工具 在整个数据库的开发与设计过程中 可以先开发一些小的应用工具 如自动生成库表的头文件 插入数据的初始化 数据插入的函数封装 错误跟踪或自动显示等 以此提高数据库的设计与开发效率

避免长事务 对单个大表的删除或插入 *** 作会带来大事务 解决的办法是对参数进行调整 也可以在插入时对文件进行分割 对于一个由一系列小事务顺序 *** 作共同构成的长事务（如银行交易系统的日终交易） 可以由一系列 *** 作完成整个事务 但其缺点是有可能因整个事务太大而使不能完成 或者 由于偶然的意外而使事务重做所需的时间太长 较好的解决方法是 把整个事务分解成几个较小的事务 再由应用程序控制整个系统的流程 这样 如果其中某个事务不成功 则只需重做该事务 因而既可节约时间 又可避免长事务

适当超前 计算机技术发展日新月异 数据库的设计必须具有一定前瞻性 不但要满足当前的应用要求 还要考虑未来的业务发展 同时必须有利于扩展或增加应用系统的处理功能

lishixinzhi/Article/program/SQL/201311/16498

按照规范的设计方法，一个完整的数据库设计一般分为需求分析、概念结构设计、逻辑结构设计、数据库物理设计、数据库的实施、数据库运行与维护六个阶段：各阶段的任务如下：

1、需求分析：分析用户的需求，包括数据、功能和性能需求；

2、概念结构设计：主要采用E-R模型进行设计，包括画E-R图；

3、逻辑结构设计：通过将E-R图转换成表，实现从E-R模型到关系模型的转换；

4、数据库物理设计：主要是为所设计的数据库选择合适的存储结构和存取路径；

5、数据库的实施：包括编程、测试和试运行；

6、数据库运行与维护：系统的运行与数据库的日常维护。：数据库设计(DatabaseDesign)是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求(信息要求和处理要求)。在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。数据库设计是建立数据库及其应用系统的技术，是信息系统开发和建设中的核心技术。由于数据库应用系统的复杂性，为了支持相关程序运行，数据库设计就变得异常复杂，因此最佳设计不可能一蹴而就，而只能是一种反复探寻，逐步求精的过程，也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。

数据库的设计跟编程语言没关系，是E-R模型的设计以及e-r模型到关系模型的转化。

我觉得你的意思是编写对数据库 *** 作的程序。

建议先用VB入门。看看使用ADO的方式访问数据库。先建一个简单的ACCESS数据库。然后在vb里面依次创建CONNECTION,COMMAND,RECORDSET对象即可，只需要几句代码就能修改数据和查询数据。前提是你熟悉SQL也可以使用ActiveX控件-ADODC和datagrid，不用编程就能看到数据显示。

vc也是一样。

用E-R数据模型进行概念设计，首先必须根据需求说明，确认实体、联系和属性。

采用E-R方法进行数据库的概念设计，可以分成三步进行：首先设计局部E-R图；然后合并各局部E-R图，并解决可能存在的冲突，得到初步E-R图；最后修改和重构初步E-R图，消除其中的冗余部分，得到最终的全局E-R图，即概念模式。 扩展资料

在需求分析和逻辑设计之间增加概念设计阶段，使设计人员仅从用户角度看待数据及处理要求和约束，产生一个反映用户观点的概念模式。这样做有三个好处：

（1） 数据库设计各阶段的任务相对单一化，设计复杂程度得到降低，便于组织管理。

（2） 概念模式不受特定DBMS限制，也独立于存储安排，因而比逻辑设计得到的模式更为稳定。

（3） 概念模式不含具体的DBMS所附加的技术细节，更容易为用户所理解，因而能准确反映用户的信息需求。

在初步E—R图中，可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。冗余的数据和冗余联系容易破坏数据库的完整性，为数据库的维护增加困难，应当予以消除。消除了冗余后的初步E—R图称为基本E—R图。

但并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。因此在设计数据库概念结构时，那些冗余信息必须消除，那些冗余信息允许存在，需要根据用户的整体需求来确定。如果人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。

在JAVA开发中数据库的学习也是我们需要了解的，截下来几篇文章都是关于数据库的设计和应用，那么java课程培训机构废话不多说开始学习吧！

数据库的设计

数据库设计是基础，数据库优化是建立在设计基础之上的。好的数据库一定拥有好的设计。

数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效的运行环境。

数据库的三大范式

第一范式1NF:所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。

第二范式2Nf:第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

第三范式3Nf:所有字段必须与主键直接相关，而不是间接相关。也可以理解为字段不要和其他非主键字段相关

注意:这三个范式尽可能去遵守,不是一定要墨守成规这只是让我们设计的表的时候,越靠近这些范式,可以使字段尽量的减小冗余但是有时候也可以根据实际需要小小的违背一下但是第三范式违反一下还可以接受,但是第一范式别违反

数据库设计的步骤

需求分析阶段

准确了解与分析用户需求(包括数据与处理)。是整个设计过程的基础，是最困难、最耗费时间的一步。

概念结构设计阶段

是整个数据库设计的关键--设计数据库的E-R模型图，确认需求信息的正确和完整

Entity_Relationship---实体之间的关系

一对一

一对多

多对一

以上就是关于数据库表的设计全部的内容，包括:数据库表的设计、数据库进阶：循序渐进讲解数据表的十二个设计原则、求关于数据库方面的书籍等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！