数据库设计

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

以下内容来自美团技术博客： 聊聊MyBatis缓存机制 前言 MyBatis是常见的Java数据库访问层框架。在日常工作中，开发人员多数情况下是使用MyBatis的默认缓存配置，但是MyBatis缓存机制有一些不足之处，在使用中容易引起脏数据，形成一些潜在的隐患。个人在业务开发中也处理过一些由于MyBatis缓存引发的开发问题，带着个人的兴趣，希望从应用及源码的角度为读者梳理MyBatis缓存机制。 本次分析中涉及到的代码和数据库表均放在GitHub上，地址： mybatis-cache-demo 。 目录 本文按照以下顺序展开。 一级缓存介绍及相关配置。 一级缓存工作流程及源码分析。 一级缓存总结。 二级缓存介绍及相关配置。 二级缓存源码分析。 二级缓存总结。 全文总结。 一级缓存 一级缓存介绍 在应用运行过程中，我们有可能在一次数据库会话中，执行多次查询条件完全相同的SQL，MyBatis提供了一级缓存的方案优化这部分场景，如果是相同的SQL语句，会优先命中一级缓存，避免直接对数据库进行查询，提高性能。具体执行过程如下图所示。 每个SqlSession中持有了Executor，每个Executor中有一个LocalCache。当用户发起查询时，MyBatis根据当前执行的语句生成MappedStatement，在Local Cache进行查询，如果缓存命中的话

一级缓存 　　Mybatis对缓存提供支持，但是在没有配置的默认情况下，它只开启一级缓存，一级缓存只是相对于同一个SqlSession而言。所以在参数和SQL完全一样的情况下，我们使用同一个SqlSession对象调用一个Mapper方法，往往只执行一次SQL，因为使用SelSession第一次查询后，MyBatis会将其放在缓存中，以后再查询的时候，如果没有声明需要刷新，并且缓存没有超时的情况下，SqlSession都会取出当前缓存的数据，而不会再次发送SQL到数据库。 　　　　　　　　　　　　　　 　　为什么要使用一级缓存，不用多说也知道个大概。但是还有几个问题我们要注意一下。 　　 1、一级缓存的生命周期有多长？ 　　 a、MyBatis在开启一个数据库会话时，会 创建一个新的 SqlSession 对象， SqlSession 对象中会有一个新的 Executor 对象。 Executor 对象中持有一个新的 PerpetualCache 对象；当会话结束时， SqlSession 对象及其内部的 Executor 对象还有 PerpetualCache 对象也一并释放掉。 　　b、如果 SqlSession 调用了 close() 方法，会释放掉一级缓存 PerpetualCache 对象，一级缓存将不可用。 　　c、如果 SqlSession 调用了

1. 原始单据与实体之间的关系 　　可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。 在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。 这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。 　　〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。 　　　　　　 这就是“一张原始单证对应多个实体”的典型例子。 2. 主键与外键 　　一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键 　　(因为它无子孙), 但必须要有外键(因为它有父亲)。 　　主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专 　　家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核 　　心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。 3. 基本表的性质 　　基本表与中间表、临时表不同，因为它具有如下四个特性： 　　 (1) 原子性。基本表中的字段是不可再分解的。 　　 (2) 原始性。基本表中的记录是原始数据（基础数据

一、树型关系的数据表 不少程序员在进行数据库设计的时候都遇到过树型关系的数据，例如常见的类别表，即一个大类，下面有若干个子类，某些子类又有子类这样的情况。当类别不确定，用户希望可以在任意类别下添加新的子类，或者删除某个类别和其下的所有子类，而且预计以后其数量会逐步增长，此时我们就会考虑用一个数据表来保存这些数据。 设计结构： 名称 类型 约束条件 说明 type_id int 无重复 类别标识，主键 type_name char(50) 不允许为空 类型名称，不允许重复 type_father int 不允许为空 该类别的父类别标识，如果是顶节点的话设定为某个唯一值 type_layer char(6) 限定3层,初始值为000000 类别的先序遍历，主要为减少检索数据库的次数 这样设计的好处就是遍历方便，只需要一个检索即可，通过设置type_layer即可设定遍历顺序，000000为3层，若要求多则可增加，每一层允许最多99个子类。010101表示为第三层。 检索过程：SELECT * FROM Type_table_2 ORDER BY type_layer 列出记录集如下： type_id 　　type_name 　　type_father 　　type_layer 1 　　　　　　总类别 　　　　　 0 　　　000000 2 　　　　　　类别1 　　　　　　1　　　

数据库设计经验谈 一个成功的管理系统，是由： [50% 的业务 + 50% 的软件 ] 所组成，而 50% 的成功软件又有 [25% 的数据库 + 25% 的程序 ] 所组成，数据库设计的好坏是一个关键。如果把企业的数据比做生命所必需的血液，那么数据库的设计就是应用中最重要的一部分。有关数据库设计的材料汗牛充栋，大学学位课程里也有专门的讲述。不过，就如我们反复强调的那样，再好的老师也比不过经验的教诲。所以我归纳历年来所走的弯路及体会，并在网上找了些对数据库设计颇有造诣的专业人士给大家传授一些设计数据库的技巧和经验。精选了其中的 60 个最佳技巧，并把这些技巧编写成了本文，为了方便索引其内容划分为 5 个部分： 第 1 部分 - 设计数据库之前 这一部分罗列了 12 个基本技巧，包括命名规范和明确业务需求等。 第 2 部分 - 设计数据库表 总共 24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等。 第 3 部分 - 选择键 怎么选择键呢？这里有 10 个技巧专门涉及系统生成的主键的正确用法，还有何 时以及如何索引字段以获得最佳性能等。 第 4 部分 - 保证数据完整性 讨论如何保持数据库的清晰和健壮，如何把有害数据降低到最小程度。 第 5 部分 - 各种小技巧 不包括在以上 4 个部分中的其他技巧，五花八门，有了它们希望你的数据库开发工作会更轻松一些。 第 1 部分 -

本文档不讲述如何使用 PowerDesigner ，而是讲述如何将 PowerDesigner 的特点结合数据库设计的方法更好的设计一个数据库系统。 采用 PowerDesigner 设计数据库 PowerDesigner 作为数据库建模和设计的 CASE 工具之一，在数据库系统开发中发挥着重要作用。 运用 PowerDesigner 进行数据库设计，不但给人直观地理解模型，而且充分运用数据库的技术，优化数据库的设计。 PowerDesigner 支持 Sybase 、 Oracle 、 Informix 、 SQL Server 等多种数据库系统，在应用系统做数据库迁移时不必维护多个数据库脚本。 对于采用结构化分析（ SA ）， E-R 图、数据流图直至最后的数据库物理图都是系统设计时不可缺少的一个部分，当数据库物理图完成后，应该产生系统的数据字典。运用 PowerDesigner 完全能够完成这一设计流程。 对于采用面向对象的分析（ OOA ），由于数据库采用的是 RDBMS ，因此存在对象和关系数据库之间的映射，也需要进行数据库设计。 两种数据库模型 PowerDesigner 可以设计两种数据库模型图：数据库逻辑图（即 E-R 图或概念模型）和数据库物理图（物理模型），并且这两种数据库图是互逆的。 数据库逻辑图是对现实世界的一种抽象，体现实体之间的关系，可以有 1 对 1

2010年5月10日开篇 前言： 为 了身体力行“一段时间内集中精力做一件事”，今天起将原来的学习安排进行调整，晚上的时间集中的学习Hibernate的设计思路和应用方法。将每天的学习成果整理以后发布到网上，作为备忘，同时也可以接受网友们的监督，以防自己错误的理解了相关知识而不自知。 学习的教材方面，我选的《Manning.Java.Persistence.with.Hibernate.Nov.2006》，这本书的作者中有一个是Hibernate的设计者 ，由他讲解的一些Hibernate的设计思路应该是更有说服力。在此之前，我已经看过前三章了，因此以下的系列随笔就从第四章开始。 学习的节奏呢，尝试使用Pomodoro技术。 学习的原则，就是2/8法则，以点带面。 本章的重点内容有两个： 一是讲解基本的OR映射选项，这些选项如何影响Hibernate加载和保存数据的行为，并讲解这些选项在JPA Annotation、JPA XML Descriptors、Hibernate Native XML Format三种格式下的表示方式； 二是在细粒度的对象模型中，对象的属性和内部子对象如何映射到关系数据模型上。 好了，下面开始本章的学习整理。 一、 首先，先来澄清两个概念，实体Entity Type和值类型Value Type。 在我感觉，作者在这张开篇就引入这两个概念的区分

数据库设计难题的求教 最近在设计一个数据库，但是碰到这样一个难题，一直找不到合适的解决方案，希望有过类似经验的高手能够帮忙分析下，看有没有好的处理策略。 举个管道建设中的例子吧，同样有三个对象： 管道：起点连接对象，结束点连接对象，管道的其他属性信息 管件：管件名称、管件类型 设备：设备名称、设备编号、设备所属单位 关系是：管道的起点和终点连接管件或者设备，而设备和管件没有多少属性是相同的，所以不能合并，这时候表的关系应该如何建？ 目前的一种考虑是使用软关联，就是在管道的表里用4个字段，分别是起点对象类型和起点对象ID，终点连接类型和终点连接ID，但是数据库建模时这种关系无法用实体关系图合理的展示，也无法在数据库中用外键关系来描述，无法保证数据的完整性，所以感觉不是很好的解决方案，想知道大家有没有更好的思路。:) 提问者： Enjoy Everyday - 初学一级 最佳答案 其实不必追求实体关系图的合理，也未必非要用外键，虽然可以没有约束，但是依然可以由程序来很好的管理这些 不过非要追求这个的话，我以前倒是做过一个，效果也还可以，可以参考一下： 管道表里包括：起点连接管件ID、起点连接设备ID、终点连接管理ID、终点连接设备ID、其他属性信息 前面四个ID都是外键，管件ID和设备ID分别关联到各自的表，四个都设置为可空，这样在程序中或者select时判断一下到底取哪个

大家好，今天我们来设计一下购物商城的商品表。 我们的目标是表结构能够满足下面这张图的搜索： 在设计表之前，我们先来了解下商品中的两个概念：SPU和SKU SPU SPU(Standard Product Unit)：标准化产品单元。是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。通俗点讲，属性值、特性相同的商品就可以称为一个SPU。 SKU SKU=Stock Keeping Unit（库存量单位）。即库存进出计量的基本单元，可以是以件，盒，托盘等为单位。 举个例子：iPhone6是一个SPU，iPhone6 32G 白色是一个SKU，iPhone6 128G 白色是另一个SKU。 因此，不难发现，这里需要一张SPU表。 SPU表有了，这里还是以iPhone6为例，iPhone6有内存16G的，有32G的，有黑色，有白色等信息，这些信息我们称之为规格，比如内存是一种规格，颜色是一种规格。这些规格放在那里呢，放在SPU表里面自然是不合适的，因为每个SPU的规格都不一样。因此这里需要一张规格表，用来存放内存，颜色（不是存放32G，黑色，就存放“内存”，“颜色”这个值，表示这个SPU具有内存，颜色规格），然后用一张中间表，把SPU表和规格表关联起来，如图： 接下来需要解决的是，如何存放“32G”，“黑色”这些值呢？这些时具体规格的值