1，表达形式：（1，2，3，4 ） ，里面的元素不能被修改

2，查找

直接通过下标访问
count ： 返回出现的次数     new_obj . count (‘123’)
index ：按照值查找，如果不存在会报错

字典（按照键值对存储）
1，表达形式 ：newdict = { ‘name’ : ’ 小张 ’ , ’ age ’ : ’ 小王 ’ }

字典中的键名不允许重复，可以想象为关系数据库中的属性名必须不同。

不支持下标取值，必须按照键值名来取值 例：newdict[ ’ name ’ ] ,如果不存在会报错

2， get方法 newdict.get（ ’ 键名 ’ ,’ 默认值 ’ ） 如果键名不存在就返回指定的默认值

3，修改数据：

直接赋值：  newdict[ ’ 键名 ’ ]  =  20    如果键名不存在，则为当前字典增加新的键值对
setdefault   ： 如果键名存在，则返回对应的值，如果键名不存在且键值没有设置就返回None ，并且将键名：None 加入字典。如果键名不存在且设置了键值，就将此键值对加入字典。
update :   有相同的键名就覆盖，不相同的就增加进去

传统的集合运算包括并，差，交，笛卡儿积运算
1.并
关系R和关系S的所有元组合并，再删去重复的元组，组成一个新的关系，即不允许有重复的行
2.差
关系R和关系S的差是由属于R但不属于S的所有元组组成的集合，即关系R中删去与关系S中相同的元组
3.交 
关系R和关系S的交是由既属于R又属于S的元组组成的集合，即在两个关系R和S中取相同的元组，组成一个新关系
4.笛卡儿积运算
在这里指广义笛卡尔积，因为笛卡尔积的元素是元组。设m目和n目的关系R和S，他们的笛卡尔积是一个（n+m）目的元组集合。元组的前n列是关系R的一个元组，后m列是关系S的一个元组。若R有r个元组，S有s个元组，则关系R和关系S的笛卡尔积应当有r*s个元组
--------------------------------------------------------------------------------------------------------
专门的关系运算包括选择，投影，连接，除
1.选择
从一个关系中选出满足给定条件的记录的操作，是从行的角度进行的运算
2投影
从关系中挑选若干属性组成新的关系，是从列的角度进行的运算
3.连接
将两个关系的属性名拼接成一个更宽的关系，生成的新关系中包含满足连接条件的元组
4.除
R与S的除法运算得到一个新的关系P，P是R中满足下列条件的元组在X属性列上的投影，元组在X上的分量值x的象集Yx包含S在Y上的投影

1. 关系的定义
“为什么叫它关系模型，而不叫他表模型？”

“链接数据结构”指的是使用指针连接数据的链表结构，这是分层模型和网状模型数据结构流行的时期特有的
关系和表的确相似，实质却不相同

关系中不允许存在重复的元组，而表中可以存在
关系中的元组没有从上往下的顺序，而表中的行有从上往下的顺序
关系中的属性没有从左往右的顺序，额表中的列有从左往右的顺序
关系中所有的属性都是不可分割的，而表中列的值是可以分割的。换句话说，关系中的属性满足第一范式，而表中的列不满足第一范式







正式的关系模型术语
非正式的日常用语




关系（relation）
表（table）


元组（tuple）
行（row）或记录（record）


势（cardinality）
行数（number of  rows）


属性（attribute）
列（column）或字段（field）


度
列数（number of columns）


定义域（domain）
列的取值集合（pool of legal values）


2. 正确的关系定义
R ⊆  （D1 x D2 x D3 …x Dn）

这个公式读作“关系R是定义域D1，D2，…Dn的笛卡尔积的子集”
笛卡尔积是指“使用各个属性的定义域生成的组合数最多的集合”，我们可以定义R2，将R2定义成由“R1中的第一行和第二行”组成的关系，这就是我们平时说到关系模型或者关系数据库时所说的“关系”的含义
3. 定义域的忧虑
定义域其实就是（现代编程语言中的数据类型），如果将数据库比作编程语言的话，可以说现在的DBMS相当于只能使用系统定义好的类型，不能由用户自定义类型的编程语言
4. 关系值和关系变量
关系值指的是关系变量在某一时刻取得值，实际上或许我们可以说，值就是变量的时间切片

把关系这样的复合型结构看成一个值
5. 存在“关系的关系”吗
这个问题可以替换成“存在递归的关系吗”或者“定义域中可以包含关系吗”

存在的，“关系的关系”的关系模型就是“关系之中还有关系”或者“表总还有表”的状态。像这样包含关系的列（属性）叫做关系值属性

第零章 数据库概述
1 基本概念
关系：一个关系就是一张二维表，每个关系要有一个关系名，一个关系可以存储为一个文件。
元组：表中的一行称为元组。
属性：表中的一列称为属性。
域：属性的取值范围。
关键字：属性或属性组合，其值能唯一地标识一个元组。
元数：关系模式中属性的数目。
关系中不允许出现重复元组
2 范式
2.1 范式定义
INF: 若关系模式R的每个属性都是不可分解的，则R∈1NF
 
2NF: 若R∈1NF，且每个非码属性都完全函数依赖于码属性，则R ∈2NF
 
3NF: 若R ∈2NF，且每个非码属性是传递函数依赖于候选码，则R ∈3NF
 
BCNF: 若R∈3NF，且没有一个非码属性是部分函数依赖或传递函数依赖于码属性，即每个非平凡函数依赖的左边必须包含键码，则R ∈BCNF
 
4NF: 若R ∈3NF，且没有非平凡多值依赖
2.2 范式示例说明
㈠ 第一范式
例如，如下的数据库表是符合第一范式的：


字段1 


字段2 


字段3 


字段4


 


 


 


 



而这样的数据库表是不符合第一范式的：


字段1 


字段2 


字段3 


字段4


 


 


字段3.1


字段3.2 


 

 
 
 
 
 

 
㈡ 第二范式
假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：
　　(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
    这个数据库表不满足第二范式，因为存在如下决定关系(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况，下面的就是部分依赖，不满足完全依赖)：
　　(课程名称) → (学分)
　　(学号) → (姓名, 年龄)
由于不符合2NF，这个选课关系表会存在如下问题：
　　① 数据冗余：
　　同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
　　② 更新异常：
　　若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
　　③ 插入异常：
　　假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
　　④ 删除异常：
　　假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
把选课关系表SelectCourse改为如下三个表：
　　学生：Student(学号, 姓名, 年龄)；
　　课程：Course(课程名称, 学分)；
　　选课关系：SelectCourse(学号, 课程名称, 成绩)。
　　这样的数据库表是符合第二范式的，另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。
㈢ 第三范式
　　在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系：
　　关键字段 → 非关键字段x → 非关键字段y
　　假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系：
　　(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)
这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系：
　　(学号) → (所在学院) → (学院地点, 学院电话)
　　即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
把学生关系表分为如下两个表：
　　学生：(学号, 姓名, 年龄, 所在学院)；
　　学院：(学院, 地点, 电话)。
这样的数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。
㈣ 第四范式
在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第四范式。禁止主键列和非主键列一对多关系不受约束。
　　假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：
　　(仓库ID, 存储物品ID) →(管理员ID, 数量)
　　(管理员ID, 存储物品ID) → (仓库ID, 数量)
　　所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：
　　(仓库ID) → (管理员ID)
　　(管理员ID) → (仓库ID)
　　即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。它会出现如下异常情况：
　　(1) 删除异常：
　　当仓库被清空后，所有"存储物品ID"和"数量"信息被删除的同时，"仓库ID"和"管理员ID"信息也被删除了。
　　(2) 插入异常：
　　当仓库没有存储任何物品时，无法给仓库分配管理员。
　　(3) 更新异常：
　　如果仓库换了管理员，则表中所有行的管理员ID都要修改。
　　把仓库管理关系表分解为二个关系表：
　　仓库管理：StorehouseManage(仓库ID, 管理员ID)；
　　仓库：Storehouse(仓库ID, 存储物品ID, 数量)。
　　这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。
㈤ 第五范式
将表分割成尽可能小的块，为了排除在表中所有的冗余。
2.3 范式总结
在实际使用中，其实我们并不完全执行上面的规则。一般说来，第一范式大家都可以遵守，完全遵守第二第三范式的人很少了，遵守的人一定就是设计数据库的高手了，BCNF的范式出现机会较少。如下图3是Microsoft SQL Server2000的Northwind示例数据库中的Customers表。可见其中也不满足第三范式。由于CustomerID->Address->PostalCode等。显然，存在传递函数依赖。但实际使用确没有太大影响。因为常识中大家都会一起修改相关项。而一般确定后也不会改动。这样的设计才编程时经常使用。因为查询时不需要连接，可以直接在一个表中进行查询。对大数量的数据和分布式数据库更是有效。
 
图3
3 实体关系图(ER图)
  在下面的具体实例中,使用的是PetShop数据库(网络上传播的为微软的.net的测试数据库,下载地址http://www.qddown.com/down.asp?id=2475&no=1.本文使用的是Petshop(1.5.2).msi版本).ER建模工具为Erwin4.1.4.图4是其表结构在ERwin下的ER图.
 
图4
3.1 1对1关系
    图5:Account中的userid和Signon中的username和Profile中的userid具有1对1的关系. 表中存在约束关系.并且Account中的userid必须同时在Signon和Profile中出现才可以插入.而Signon和Profile则没有限制.
 
图5
3.2 1对多关系
  如图6:Profile表中的favcategory与BannerData的主键favcategory具有外键约束,并且favcategory在Profile中可以重复出现. 并只能是在BannerData中出现的才可以插入.
 
图6
下图也是一对多的关系为什么出现的一个是菱形的图标?因为可以在Profile中在favcategory项上可以为空.而不必一定要出现在BannerData中.如果没有菱形图标就不允许为空。如下图7。
 
图7
3.3 多对多关系
     一门课程同时有若干学生选修，而一个学生有同时可以选多门课程，则学生与课程之间具有多对多关系。如图8.
 
图8 
3.4 无任何约束的表
     没有限制的表，如图9。
 
图9 
 
4 小结
本章主要介绍了几个基本概念，由于这几个概念经常用到，是以后很多问题的基础，所以讨论。范式问题是数据库的难点问题，也是设计数据库的核心问题，在设计数据库应该很好的遵守这些规则，但也有时候可以不遵守的情况，本文也举例说明。在实际工作中要根据具体情况具体分析。而实体关系图也是设计数据库的关键问题，同时开发工程师也需要理解系统设计人员发布的ER图。是开发不可避免并经常用到的问题。所以加以论述。而本章使用的MSSQL由于其简单易用，是学习的好工具，所以采用。采用Erwin也是由于许多的开发商使用和简单易用的特性的原因,另外用得好的是PowerDesigner由于稍显复杂,故未采用.
为什么关系中不允许有重复元组?可是我的程序验证却可以出现呢？
如果关系中有重复元组，那么就无法用键来标识唯一的元组。因此在关系模型中对关系作了限制。可是我在使用中的上述关系都没用到键约束。所以他们可以出现相同的元组。
文中使用了两种流行的数据库验证为了不失一般性。