计之以听，乃之以势，以佐其外
指定计划：
计算机程序不是单单从数据库中取出数据简单，而是要为特定的目标处理数据
数据的关系视图
关系模型：关系数据库之所以叫关系数据库，不是表之间存在联系，而是表之间的数据存在联系
为现实建模的范围：由业务需求决定，我们定义的关系（即是表）代表我们接受的事实，而视图与查询就是新的事实。
不同的使用者，看待数据的角度也不同，没有设计放之四海，但是高质量的设计便于编写查询，
范式化的重要性
范式化的原理：按照严格的逻辑要求，将不同的数据结合在一起，使他们能够成为结构化信息，严格性是通过不同的范式级别定义的
范式化的意义：混沌归于有序，为清晰化思考提供清单指南
松散信息-数据模型的原则
第一范式
原子性
1，要处理的数据的特征或者属性具有原子性，但是原子性具有相对性。
question:如果出现不具有原子性的属性出现的问题？sony(phone,game,song)
1高效率的搜索能力,对phone的搜索会导致检索所有sony字段，常规索引应该具有原子性，
2数据正确性，sony属性的检测函数，多个字段的关系处理。
2,主键的使用
尽量使用实例意义的主键，而不是晦涩的整数，主键应该能画出数据的特色
经典的comany问题，增加一序列号company_id说明company
3，满足属性原子性，并且设置了主键，就产生了第一范式。
第二范式
检测对于键的完全依赖，
1，数据冗余
2，查询性能
必须包含主键，没有包含在主键的列必须完全依赖于主键，而不是主键的部分，
第三范式
数据集中的每个属性已经完全依赖唯一键，除了唯一键之外，不能根据其他任何属性确定一个属性的值，
数据集中的主键不存在依赖传递，eg:非主键a依赖于非主键b,b再依赖于主键。
一些有意思的东西
空值的出现
关系数据库的完备性是以二值逻辑为基础的，记录要么存在，要么不存在
包含null值得模型的出现导致 三值逻辑，真，假，不确定。
eg:color(a,b,c)
select * from table where color not in (a,d,null) :不会返回任何结果，因为不确定null到底是什么
select * from table where color in (a,d,null):只会返回a,sql引擎认为null可能既不是b,也不是c.
遗留信息的处理与建模
以客户地址为例子
1，通常情况下，客户地址应该在发货单上面 order(custemr_address)，地址是订单一部分，
2，客户地址与送货地址不同,客户地址在在客户上， custemr(custmr_address,send-address)，地址是用户的一部分。
3,同一个客户有不同的送货地址，custemr(custmr_address,send_address1,send_address2)
4,是不是很奇怪，一个custmr有着不同的地址，通常情况下，一个客户只需要一个地址，custmr_address
5,对于send_address1,send_address2的处理
·2个为null,有点不符合逻辑，pass
·复制custmr_address，在为null的时候通过触发器复制一份custmr_address,开销很大,pass
·正真的解决方式，将地址从custmer表中分离出来，adress(custmr_address,send_address1,send_address2),
address形成一个单独的地址表
6，考虑这个问题，同一个custmr_address，不同的send-address1，同一个send-address2，
这时候order(address)，承认地址是订单的一部分，，adress(custmr_address,send_address1,send_address2),
7，总之，表的设计是对于业务的客观逻辑表示。
对于boolean类型的字段的使用
1.sql中不存在boolean,可以使用标志位来表示boolean的真假。
eg order_completed(yes/no),来表示订单是否完成
从数据密度来思考，虽然order_completed(yes/no)能表示，但是订单完成以及由谁完成
eg oreder_completed_date,oreder_completed_by,代替order_completed(yes/no)
2.boolean类型的数据组合
eg：四个属性的真假可以用0-15表示，注意这里可能违背原子性
子类
表太宽带来的影响，不同类型的员工有着相同的属性，也有不同的属性
解决方式：
1,创建3个表：e(雇员)p(固定员工)，c(合同员工)
2,e,p,c都是按照员工号为主键，pc之间没有交集。
３，ps:子类形的主键完全独立与主表的主键是不友好的，并且子类形不是从属关系
４，将所有的数据放入一个表，不使用子类型会导致一个小的查询也将导致巨大的消耗
约束
１，数据语义属于dbms，不要放在程序中处理
２，字段类型的申明，
３，外键关联主键，实现数据一致性。
约束的作用：
１，有利于保证数据的完整性。
２，dbms的核心——优化器。在未来的版本中，优化器可能会将约束用于更加复杂的处理上。
处理流程
处理流程在这里主要是指操作模式，
同步模式处理（典型的交易系统）
异步处理模式（批处理系统）
处理数据的方式，会影响我们看待系统的方式。
数据模式的设计必须考虑数据流
设计与性能
什么是调优？
目前情况下将性能优化至最佳，调优几乎不影响程序结构
调优的分类：
１，调节系统的整体性能，cpu,可用内存，io子系统，dbms
２，具体查询的调优，这种方式收到不同的dbms的限制
数据库性能不仅仅是调优，谋划整个战争才是重中之重。
数据集中化
数据的分布，如网络，集群大大增加了系统的复杂性
不论那种结构，结构越复杂，健壮性越低
原因：
１，跨越软件层或者网络层的代价
２，不同数据源的数据结合十分困难
处理方式
访问集与数据源的折中，地理位置或者网络位置
系统的复杂性
组织角色的复杂性带来的矛盾
需要用户，管理者，开发人员协作。
历史数据的处理
总结:成功的数据库建模应该严格遵循基本的设计原则
ps:25路关联
123范式
备用键（alternate key）
