浅析关联设计
【范式】
比較理想的情况下，数据库中的不论什么一个表都会相应到现实生活中的一个对象，如球员是一个对象，球队是一个对象，赛程是一个对象，比赛结果又是一个对象等等，则就是范式。
【关联设计】
对于关联设计能够理解成表和表之间要有关联关系，在对表查询时常常使用关联查询。
补充：关系数据库的来源：对一个事务操作要从多个表中读。
如2014巴西世界杯这个表空间中要有球员表、赛程表、比赛结果表，比赛结果表要关联比赛的队伍名字、球员的名字最后关联一个比赛的结果，这就是一个简单的关联关系。至于为何要设计成范式，也非常好理解，这是为了不冗余存储数据，同一场比赛的结果就不用反复的存储了，如巴西对德国0:0和德国队巴西也为0:0（由于是相同的两支队伍，结果必定是一样的），这样就能够仅仅存在一行数据了，结果也就是保持了数据的独立性。
【不良好的范式、关联设计举例】
假设不良好的范式、关联设计会引发关联的成本的问题，举个样例，假设两张表的成本都非常大，来做等值连接和不等值连接时将会有非常大的成本问题。如从世界杯的进球球员中去关联到该名球员在俱乐部中一个赛季的表现情况时，如进球数、犯规数、抢断数等等一些列数据时，而这个数据是存在于一个较大的表中的，对于这两张表的关联成本将会非常大。由于世界杯中进球球员的一行记录有可能相应赛季表中的非常多行数据，而每个球员都是这样，第一个表中的一行数据相应于第二个表中的非常多行数据，这样的交叉的链接过程中，成本是相当高的。这也就引出了，目标比較流行的技术趋势，反范式。
【反范式】
反范式，打破旧有的良好设计，而有益使用存在冗余的数据。
举个样例，例如以下图
表1：
|
FIFA球员ID |
球员名 |
国籍 |
2014世界杯进球 |
...... |
|
10982 |
小罗 |
葡萄牙 |
6 |
...... |
|
23781 |
比利亚 |
西班牙 |
5 |
...... |
|
12312 |
穆勒 |
德国 |
4 |
...... |
|
......万条 |
||||
表2
|
FIFA球员ID |
10982 |
23781 |
12312 |
...... |
|
地区 |
欧洲 |
欧洲 |
欧洲 |
...... |
|
俱乐部 |
皇家马德里 |
马德里竞技 |
拜仁慕尼黑 |
...... |
|
2014赛季进球 |
32 |
28 |
6 |
...... |
|
......万条 |
||||
如上，表1是世界杯球员统计数据，表2为球员在俱乐部中的表现情况。为了避免球员重名情况，表2使用了ID号作为标识。如今想要查看世界杯表现优异有进球的小罗在俱乐部的表现情况，即要关联世界杯有进球的球员在俱乐部中的表现情况时，要通过第一张表进行关联，先要知道小罗的ID号，再查到相应的俱乐部表现情况。表1中的一行数据要相应到表2中的1列数据，表2中的1列数据也要相应表1中的1行数据，在以万条计的两张大表中，这个关联成本是相当高的。尽管两张表符合了良好的范式、关联性，防止了冗余、防止了冲突，但在性能上就很差了。相应的改善做法就是不写ID号，而是直接填写球员的名字，假设有重名在后台数据库做一个标识。这样想查询某球员俱乐部表现情况时，就直接到表2中去查询相应的数据信息就可以。从设计上出发，没有一个好的范式、没有一个好的关联设计。但从性能上分析，比一个良好的范式、关联设计体现了更好的性能。