范式

1.批量增 使用mysql向数据库中批量插图数据: conn = pymysql.connect( host='127.0.0.1', port=3306, user='root', password='*******', database='wangyi') cur = conn.cursor(pymysql.cursors.DictCursor) 这里的cur指的是游标。游标是映射在结果集中一行数据上的位置实体，有了游标，用户就可以访问结果集中的任意一行数据了， 将游标放置到某行后，即可对该行数据进行操作。然而这些都是mysql内部的事情了，我们只需要知道要写上这么两句话， 在执行sql语句前实例化一个游标对象，并在执行完sql语句提交后，关掉这个游标就好了。 try: sql = "insert into news(title, content, keyword,type) values(%s, %s, %s,%s);" # 数据库中有id字段,使用executemany 向数据库中提交! print(sql) ret = self.cur.executemany(sql,[(item['new_title'],item['new_content'],word,type)])# 执行sql 语句 　　　#有几个占位符 列表里面的元组就应该有几个元素,否则的就存不进去,　　　

数据库设计三大范式 1. 第一范式 确保每列的原子性。 如果每列（或者每个属性）都是不可再分的最小数据单元（也称为最小的原子单元），则满足第一范式。 例如： 顾客表(姓名、编号、地址、……) ，其中"地址"列还可以细分为国家、省、市、区等 2. 第二范式 在第一范式的基础上更进一层，目标是确保表中的每列都和主键相关。 如果一个关系满足第一范式，并且除了主键以外的其它列，都依赖于该主键，则满足第二范式。 例如： 订单表(订单编号、产品编号、定购日期、价格、……)， "订单编号"为主键，"产品编号"和主键列没有直接的关系，即"产品编号"列不依赖于主键列，应删除该列。 3. 第三范式 在第二范式的基础上更进一层，目标是确保每列都和主键列直接相关，而不是间接相关。 如果一个关系满足第二范式，并且除了主键以外的其它列都不依赖于主键列，则满足第三范式. 为了理解第三范式，需要根据 Armstrong 公理 之一定义传递依赖。 假设A、B和C是关系R的三个属性，如果A→B且B→C，则从这些函数依赖中，可以得出A→C。 如上所述，依赖A→C是传递依赖。 例如： 订单表(订单编号，定购日期，顾客编号，顾客姓名，……) 初看该表没有问题，满足第二范式，每列都和主键列"订单编号"相关 再细看你会发现"顾客姓名"和"顾客编号"相关，"顾客编号"和"订单编号"又相关，最后经过传递依赖，"顾客姓名"也和

网上查找了一些资料，记录如下并加入自己的理解。 设计关系 数据库 时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。但是有些时候一昧的追求范式减少冗余，反而会降低数据读写的效率，这个时候就要反范式，利用空间来换时间。 目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式(3NF）就行了。所以这里就只记录三范式相关的知识。 三范式 1NF:字段不可分; 2NF:有主键，非主键字段依赖主键; 3NF:非主键字段不能相互依赖; 解释: 1NF:原子性 字段不可再分,否则就不是关系数据库; 2NF:唯一性 一个表只说明一个事物; 3NF:每列都与主键有直接关系，不存在传递依赖; 第一范式（1NF） 即表的列的具有原子性,不可再分解，即列的信息，不能分解, 只要数据库是关系型数据库( MySQL / Oracle /db2/informix/sysbase/sql server)，就自动的满足1NF。数据库表的每一列都是不可分割的原子数据项

范式的概念 　　为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。 在实际开发中最为常见的设计范式有三个： 1 ．第一范式(确保每列保持原子性) 第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。 第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。 上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。 2 ．第二范式(确保表中的每列都和主键相关) 第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。 比如要设计一个订单信息表

视图 视图概念 视图是存储的查询语句,当调用的时候,产生结果集,视图充当的是虚拟表的角色。其实视图可以理解为一个表或多个表中导出来的表，作用和真实表一样，包含一系列带有行和列的数据 视图中，用户可以使用SELECT语句查询数据，也可以使用INSERT，UPDATE，DELETE修改记录，视图可以使用户操作方便，并保障数据库系统安全，如果原表改名或者删除则视图也失效。 视图操作 创建视图 语法结构： CREATE [ OR REPLACE ] VIEW [ view_name ] AS [ SELECT_STATEMENT ] ; 释义： CREATE VIEW ： 创建视图 OR REPLACE : 可选，如果添加原来有同名视图的情况下会覆盖掉原有视图 view_name ： 视图名称 SELECT_STATEMENT ： SELECT 语句 e . g . create view c1 as select name , age from class_1 ; 视图表的增删改查操作 视图的增删改查操作与一般表的操作相同，使用insert update delete select即可，但是原数据表的约束条件仍然对视图产生作用。 删除视图 drop view [IF EXISTS] 视图名； IF EXISTS 表示如果存在，这样即使没有指定视图也不会报错。 drop view c1 ;

DDL：Data Definition Language，数据库模式定义语言； DML：Data Manipulation Language，数据操纵语言命令使用户能够查询数据库以及操作已有数据库中的数据； 关系范式学习： 要理解范式必须先理解一下依赖关系 1.数据依赖 数据依赖指的是通过一个关系中属性间的相等与否体现出来的数据间的相互关系，其中最重要的是函数依赖和多值依赖。 2.函数依赖 设X,Y是关系R的两个属性集合，当任何时刻R中的任意两个元组中的X属性值相同时，则它们的Y属性值也相同，则称X函数决定Y，或Y函数依赖于X。 3.平凡函数依赖 当关系中属性集合Y是属性集合X的子集时(Y?X)，存在函数依赖X→Y，即一组属性函数决定它的所有子集，这种函数依赖称为平凡函数依赖。 4.非平凡函数依赖 当关系中属性集合Y不是属性集合X的子集时，存在函数依赖X→Y，则称这种函数依赖为非平凡函数依赖。 5.完全函数依赖 设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。 6.部分函数依赖 设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。 7.传递函数依赖 设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。 举例说明

　　　当前我们使用的主流数据库是关系型数据库，所以我是记录在关系型数据库中对范式的一些理解和看法．数据库库范式分为六种（其实还有有一个ＢＣＮＦ），分别为从第一范式到第六范式．高级一层是建立在所有低层的基础上的，如第２范式是建立在第一范式的基础上的，依次类推．　下面分别举例讲解各种范式： １．第一范式（1NF）： 　　第一范式的核心描述为：数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值．该范式讲的是列的原子性．有两层意思：一层是说每一列只能存一个属性值（如果把２个属性值存在１列中）．第二层说的是在一张表中属性值不能重复．　在现代关系行数据库中，都是默认满足第一范式的，所以你想要写出不满足第一范式的结构来还是不可能的事情，所以第一范式就不再多说．如果想深入，可以研究下其他非关系型的数据库的情况． ２．第二范式(2NF) 　　第二范式的核心描述为：行有唯一的主键，非主键仅对主键依赖．　有２层意思，第一层，每一行都要有主键（单独信息或组合信息），这个容易理解．　第二层意思是非主键对主键依赖，如果是复合主键的情况，非主键属性不能依赖于部分主键属性．如　【产品，仓库号，数量，仓库地址，仓库管理员】，这里（产品＋仓库号）为复合主键，而仓库地址和仓库管理员依赖于仓库号，这就是上面描述的＇主键属性不能依赖于部分主键属性＇，因此这是违背第二范式的，符合范式的设计应该为：【产品，仓库号

本文作者： 盛赫，花名白茶，就职于阿里本地生活中台研发部，多年交易系统建设开发经验，目前转入营销领域继续探索。 叮~,您有新的饿了么订单，正在阿里云上被接单。 这篇文章成型于交易系统重构一期之后，主要是反思其过程中做决策的思路，我没有使用「架构」这个词语，是因为它给人的感受充满权利和神秘感，谈论「架构」让人有一种正在进行责任重大的决策或者深度技术分析的感觉。 如 毕玄 在 系统设计的套路 这篇文章里所提： 回顾了下自己做过的几个系统的设计，发现现在自己在做系统设计的时候确实是会按照一个套路去做，这个套路就是：系统设计的目的->系统设计的目标->围绕目标的核心设计->围绕核心设计形成的设计原则->各子系统，模块的详细设计 在进行系统设计时，摸清楚目的，并形成可衡量的目标是第一步。 "Soft" ware Software 拆开来分别是 soft ware ，即灵活的产品。 -- 鲍勃大叔 重构前的交易系统第一版的代码可以追溯到 8 年前，这期间也经历过拆解重构，17 年我来到时，主要系统是这样： 这套系统驮着业务从百万级订单跑到了千万级订单，从压测表现来看，它可以再支撑业务多翻几倍的量，也就是说如果没有啥变化，它可以继续稳定运行着，但如果发生点变化呢，答案可能就不这么肯定了。 在我入职的这两年里，系统承载的业务迭增变化：从单一的餐饮外卖到与新零售及品牌餐饮三方并行

关系数据库的基本概念 　　关系：二维表 　　行：元组 　　列：属性 　　域：属性取值范围 　　关键字：唯一确定一个元组（主码） 　　　　一般显示表示形式：关系名（属性1，属性2，……属性n） 　　　　　　如：学生（学号，姓名，性别，年龄，学部号） 数据完整性 　　指数据库中数据的正确性和唯一性。 　　三类完整性规则： 　　　　1、实体完整性规则 　　　　2、参照完整性规则 　　　　3、用户定义的完整性规则 关系操作：选择，投影，连接 　　1、选择，又称为限制。i在关系中选择满足给定条件的诸元组 　　选择运算实际上就是从关系中选择逻辑表达式为真的元组 　　在关系的行的角度进行运算 　　逻辑表达式运算符可以是：>、<、>=、<=、!=、= 　　2、投影。 　　在关系上选择若干属性列组成新的关系 　　投影是在列的角度进行运算 　　投影操作后可能取消一些元组，因为一旦选取了特定列，可能就会产生重复的行，这些重复的行必须消除 　　3、连接。 　　通过一个关系中的某个属性等于另一个关系的某个属性作为连接条件的连接。 逻辑数据库设计 　　将实体和关系转化为关系模式 　　函数依赖型 　　无损分割 　　规范化准则 联系 　　事物的联系可以分为两类：一类是实体集内部的联系，表现在属性之间；另一类是实体集之间的联系，可分解为多个实体间的了联系。 　　两个实体间联系的类型： 　　1:1

数据库规范化与范式 　　冗余导致多种更新异常，也就是插入、更新和删除行的操作困难。 　　 规范化（normalization） 是通过修改表以减少冗余和矛盾的一系列步骤。 　　在每一步之后，数据库都达到一个特定的 范式（normal form） 。 　　关系模型定义了三种范式，以著名的序数命名。 　　第一范式（1NF） 　　第二范式（2NF） 　　第三范式（3NF） 　　每一种范式都比前一种更健壮。符合3NF的数据库也符合2NF和1NF。规范化水平越高，表的数量也越多。 　　 无损分解（lossless decomposition ） 能确保表的分割不会引起信息丢失。 　　 依赖- 保持分解（dependency-preserving decomposition ） 能确保联系不丢失。 　　当表被分割的时候，存在匹配的主键和外键列不应被认为是多余的数据。 　　 规范化 不是系统化，它是一个涉及重复表的分割、重新联结和精炼的迭代过程。 第一范式（1NF） 　　 满足第一范式的表： 　　 列仅包含原子值。 　　 没有重复的组。 　　 原子值 （也称为 标量值 ）是不能再细分的单一值。 　　 重复的组 是两个或多个逻辑相关联的列的集合。 第二范式（2NF） 　　当满足下列条件时，第一范式的表自动满足第二范式： 　　主键是一个列（也就是说，关键字不是组合的）。