数据库设计

必须保证数据库设计的合理性 数据库设计关系整个系统的架构，关系到后续的开发效率和运行效率 数据库的设计主要包含了设计表结构和表之间的联系 如何是合理数据库 结构合理 冗余较小 尽量避免插入删除修改异常 如何才能保证数据库设计水平 遵循一定的规则 在关系型数据库中这种规则就称为范式 什么是范式（NF= Normal Form） 范式是符合某一种设计要求的总结。 要想设计一个结构合理的关系型数据库，必须满足一定的范式。 第一范式 要求 最基本的范式 数据库表每一列都是不可分割的基本数据项，同一列中不能有多个值 简单说就是要确保每列保持原子性 第一范式的合理遵循需要根据系统的实际需求来定 示例 用户表（用户名，家庭地址） 用户表（用户名，省，城市，详细地址） 第二范式 要求 第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。 即在一个数据库表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。 示例 学号和课程编号作为联合主键 课程名称只依赖于课程编号，而和学号没有关系 解决 提取出学生表 提取成课程表 提取选课表，存放选课记录 第三范式 要求 确保数据表中的每一列数据都和主键直接相关，而不能间接相关 属性不依赖于其他非主属性。 范式的优缺点 优点 结构合理 冗余较小 尽量避免插入删除修改异常 缺点 性能降低

什么是范式：简言之就是，数据库设计对数据的存储性能，还有开发人员对数据的操作都有莫大的关系。所以建立科学的，规范的的数据库是需要满足一些 规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式。 什么是三大范式： 第一范式： 数据库表的每一列都是不可分割的原子数据项 时，称R是满足第一范式的，简记为1NF。 第二范式： 要求实体的属性完全依赖于主关键字。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。 第三范式： 在1NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）。 注： 关系实质上是一张二维表，其中每一行是一个元组，每一列是一个属性。 理解三大范式 第一范式 1、每一列属性都是不可再分的属性值，确保每一列的原子性。 2、两列的属性相近或相似或一样，尽量合并属性一样的列，确保不产生冗余数据。 如果需求知道那个省那个市并按其分类，那么显然第一个表格是不容易满足需求的，也不符合第一范式。 显然第一个表结构不但不能满足足够多物品的要求，还会在物品少时产生冗余。也是不符合第一范式的。 第二范式 每一行的数据只能与其中一列相关，即一行数据只做一件事。只要数据列中出现数据重复，就要把表拆分开来。 一个人同时订几个房间，就会出来一个订单号多条数据，这样子联系人都是重复的，就会造成数据冗余。我们应该把他拆开来。 这样便实现啦一条数据做一件事

我要设计一个数据库要求： 用户至少要有5种，对每个设备的操作有20种，设备至少要有15个。后期还有可能添加设备或是每个设备的操作，或是用户种类 我设计如下： 用户表 User_id User_name User_(其他属性，如邮箱，地址，联系方式等等) 1 User1 张三@qq.com 2 User2 李四@qq.com ... 设备表 Equip_id Equip_name Equip_description 1 Equip1 用于监视的设备 2 Equip2 用于操作的设备 ... 权限表 Right_id Right_name Right_description 1 a 操作1 2 b 操作2 ... 用户设备权限表 ID User_name Equip_name Right 1 User1 Equip1 abc(即拥有a，b，c三种权限) 2 User1 Equip2 ab 3 User2 Equip1 a 4 User2 Equip2 b ... 感觉最后一个表会很复杂。不知道遇到这种情况的话要怎么做呢。。。期待~~ superdullwolf superdullwolf 等级： 结帖率：98.97% 3 #3 得分：0 回复于： 2009-03-05 12:28:48 顺便，每次设计数据库的时候默念3个泛式： 1NF:原子不可分性,就是每个字段不可以拆分，比如1,2

数据库设计的5种常见关系，其中本文主要讲“多态”关系结构，以手机为例。 1，配置关系 --和其他表无任何关系的表。 例如：webConfig里的东西你存储到表里。 2，一对多关系 ，一张表包含另外一个表的主键作为外键。 例如：手机.品牌id=2， 这里的2是[品牌名称表]的id字段为2的纪录，品牌名称是"Nokia"。一个手机只能有一个品牌。 3，多对多，需要3张表，有一个包含两个外键的关系表。 例如： 手机1即属于"智能" 又属于"滑盖"组的， 一个组包含多个手机，一个手机可以属于多个组。 4，树型结构，常见的两钟：父ID设计和001002编码设计。 例如：手机的经销商分为 省/市/县 5，“多态”结构和多对多略有不同，如果需求中某表字段多少类型有非常大的不确定性，可以采用3个表来完成： 一个[主表]（ID）， 一个[属性名称表]（属性ID.属性名称)， 一个[属性值表]，包括3个字段： 属性值(属性Value varchar(500)) 主表ID 属性ID 这样可以作到最小冗余度。 （和常见的多对多关系不同的是：值统一用varchar来存储，因为这类型的值一般不会用来计算）。 比如：手机型号有几千种，除了共同属性外还有不同属性有几百个，属性名和值类型都不一样，有的手机有这属性，有的没有。 对于这样的“多态”，我们就采用上面的设计结构。 其效果相当于： 某奇怪手机.属性集合[

前言：多对多关系至少需要3个表，我们把一个表叫做主表，一个叫做关系表，另外一个叫做字典表或者副表（字典表是纪录比较少，而且基本稳定的，例如：版块名称；副表是内容比较多，内容变化的，例如）。 按照数据库的增删查改操作，多对多关系的查找都可以用inner join或者select * from 主表 where id in (select 主表id from 关系表) 1，角色任命型 特点：关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键，有一个表是字典类型的表。 界面特点：显示主表，用checkbox或多选select设置多选关系。 例如：任命版主（用户表-关系表-版块名称表），角色权限控制等，用户是5个版块版主，只要关系表5行纪录就可以确立，关系表的两个外键具有联合主键性质。 增加关系：如果没有组合纪录，insert之。 删除关系：如果有组合纪录，删除之。 2，集合分组型 特点：同角色任命型类似，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。区别是主副表都不是字典表，可能都很大不固定。 界面特点：显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。 例如：歌曲专集（专集表-关系表-歌曲表）。手机分组（分组表-关系表-手机表）。用户圈子（圈子表-关系表-用户表）。文章标签（文章表-关系表-标签表） 增加关系：同版主任命型。

MyBatis 的前身就是 iBatis 。是一个数据持久层(ORM)框架。 iBATIS一词来源于“internet”和“abatis”的组合，是一个基于Java的持久层框架。iBATIS提供的持久层框架包括SQL Maps和Data Access Objects（DAO），同时还提供一个利用这个框架开发的 JPetStore 实例。 看到Mybatis的框架图，可以清晰的看到Mybatis的整体核心对象，我更喜欢用自己的图来表达Mybatis的整个的执行流程。如下图所示： 原理详解： MyBatis应用程序根据XML配置文件创建SqlSessionFactory，SqlSessionFactory在根据配置，配置来源于两个地方，一处是配置文件，一处是Java代码的注解，获取一个SqlSession。SqlSession包含了执行sql所需要的所有方法，可以通过SqlSession实例直接运行映射的sql语句，完成对数据的增删改查和事务提交等，用完之后关闭SqlSession。 MyBatis的优缺点 优点： 1、简单易学 mybatis本身就很小且简单。没有任何第三方依赖，最简单安装只要两个jar文件+配置几个sql映射文件易于学习，易于使用，通过文档和源代码，可以比较完全的掌握它的设计思路和实现。 2、灵活 mybatis不会对应用程序或者 数据库 的现有设计强加任何影响。

I、关系数据库设计范式介绍 1.1 第一范式（1NF）无重复的列 所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。 如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含 一个实例的信息。简而言之，第一范式就是无重复的列。 说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 1.2 第二范式（2NF）属性完全依赖于主键[消除部分子函数依赖] 第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库 表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。例如员工信息表中加上了员工编号 （emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。 第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的 这一部分应该分离出来形成一个新的实体

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 我是一名java开发人员，hibernate以及mybatis都有过学习，在 java面试 中也被提及问道过，在项目实践中也应用过，现在对hibernate和mybatis做一下对比，便于大家更好的理解和学习，使自己在做项目中更加得心应手。 第一方面：开发速度的对比 就开发速度而言，Hibernate的真正掌握要比Mybatis来得难些。Mybatis框架相对简单很容易上手，但也相对简陋些。个人觉得要用好Mybatis还是首先要先理解好Hibernate。 比起两者的开发速度，不仅仅要考虑到两者的特性及性能，更要根据项目需求去考虑究竟哪一个更适合项目开发，比如：一个项目中用到的复杂查询基本没有，就是简单的增删改查，这样选择hibernate效率就很快了，因为基本的sql语句已经被封装好了，根本不需要你去写sql语句，这就节省了大量的时间，但是对于一个大型项目，复杂语句较多，这样再去选择hibernate就不是一个太好的选择，选择 mybatis 就会加快许多，而且语句的管理也比较方便。 第二方面：开发工作量的对比 Hibernate和MyBatis都有相应的代码生成工具。可以生成简单基本的DAO层方法。针对高级查询，Mybatis需要手动编写SQL语句，以及ResultMap

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 我是一名java开发人员，hibernate以及mybatis都有过学习，在 java面试 中也被提及问道过，在项目实践中也应用过，现在对hibernate和mybatis做一下对比，便于大家更好的理解和学习，使自己在做项目中更加得心应手。 第一方面：开发速度的对比 就开发速度而言，Hibernate的真正掌握要比Mybatis来得难些。Mybatis框架相对简单很容易上手，但也相对简陋些。个人觉得要用好Mybatis还是首先要先理解好Hibernate。 比起两者的开发速度，不仅仅要考虑到两者的特性及性能，更要根据项目需求去考虑究竟哪一个更适合项目开发，比如：一个项目中用到的复杂查询基本没有，就是简单的增删改查，这样选择hibernate效率就很快了，因为基本的sql语句已经被封装好了，根本不需要你去写sql语句，这就节省了大量的时间，但是对于一个大型项目，复杂语句较多，这样再去选择hibernate就不是一个太好的选择，选择 mybatis 就会加快许多，而且语句的管理也比较方便。 第二方面：开发工作量的对比 Hibernate和MyBatis都有相应的代码生成工具。可以生成简单基本的DAO层方法。针对高级查询，Mybatis需要手动编写SQL语句，以及ResultMap

第一章 ORM 概述 [ 了解 ] ORM（Object-Relational Mapping） 表示对象关系映射。在面向对象的软件开发中，通过ORM，就可以把对象映射到关系型数据库中。只要有一套程序能够做到建立对象与数据库的关联，操作对象就可以直接操作数据库数据，就可以说这套程序实现了ORM对象关系映射 简单的说：ORM就是建立实体类和数据库表之间的关系，从而达到操作实体类就相当于操作数据库表的目的。 1.1 为什么使用ORM 当实现一个应用程序时（不使用O/R Mapping），我们可能会写特别多数据访问层的代码，从数据库保存数据、修改数据、删除数据，而这些代码都是重复的。而使用ORM则会大大减少重复性代码。对象关系映射（Object Relational Mapping，简称ORM），主要实现程序对象到关系数据库数据的映射。 1.2 常见ORM框架 常见的orm框架：Mybatis（ibatis）、Hibernate、Jpa 第二章 hibernate 与 JPA 的概述 [ 了解 ] 2.1 hibernate概述 Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，它将POJO与数据库表建立映射关系，是一个全自动的orm框架，hibernate可以自动生成SQL语句，自动执行