好久没有碰数据库分析设计了。今天突然要做一个数据库分析,很是费解,所谓好记性不如烂笔头,个人觉得还是要记一下的。用一个例子来说:
你想要设计的一个产品表可能是这样的:
产品表:产品ID, 产品名称, 产品类型
产品ID 产品名称 产品类型
1 敌敌畏 农药
2 加多宝 饮料
3 可乐 饮料
- 1
- 2
- 3
- 4
那么,接下来我们把这个产品表拆分开来(实际开发中),因为在数据库设计中除了外键以外其他字段是不可以重复的(产生冗余),因为不可能你一个界面就设计一张表,你需要分析这样一对多的关系,便于管理维护:
产品表:产品ID,产品名称,产品类型ID
产品类型表:产品类型ID,产品类型名称
产品ID 产品名称 产品类型ID
1 敌敌畏 1
2 加多宝 2
3 可乐 2
产品类型ID 产品类型名称
1 农药
2 饮料
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
相信大家对于这样的拆分是可以理解的,因为一个产品类型对应多个产品,是一对多的关系,所以我们把这个产品类型表的主键放到产品表中做外键,形成主外键的关联,那么产品表相当于继承了产品类型表的东西,继承,那么大家可以联想到的就是儿子继承父亲的东西,所以产品表是子表,产品类型表是父表。也有一种说法是主表和从表的说法。
还有一种比较棘手的数据库设计模式就是多对多的关系:
学生表:学生ID,学生名称。。。
选课表:课程ID,课程名称。。。
学生_选课表:学生选课ID,学生ID,选课ID。。。
上面的例子中可以这么理解,一个学生对应多个课程,而一个课程也可以对应多个课程,两个一对多的关系,加外键也是搞不定了。所以这个时候我们就可以引入一个中间表(关系表),学生_选课表进行逻辑的处理,而且不破坏学生表和选课表的结构关系。这样,我们如果想要查出一个学生的所有选课,或者一个选课的所有学生,就可以通过联表查询查出想要的结果了。奥耶
比较常用的有递归表:
可能你想要的是这种效果,但是对于地区名称这个字段中还可以细分,因为广东属于中国,广州属于广东,存在这样的关系。。。。
地区表:地区ID,地区名称
1 中国
2 广东
3 广州
- 1
- 2
- 3
- 4
我们引入一个地区ID_f就是地区ID的父亲,建立递归关系。
地区表:地区ID,地区名称,地区ID_f
1 中国 0
2 广东 1
3 广州 2
4 浙江 0
- 1
- 2
- 3
- 4
- 5
- 6
个人觉得你在数据库表的设计上如果碰到类似这样的表结构,我们还可以引入属性表的概念:
颜色表:颜色ID,颜色
尺寸表:尺寸ID,尺寸
地区表:地区ID,地区名称
等等
大家看,这些表的结构是不是相识,只有一个ID外加一个字段。
那么,我们可以引入属性集合表和属性集合明细表的概念来优化
属性集合表:属性集合ID,属性集合名称
1 颜色
2 尺寸
3 地区
属性集合明细表:属性集合明细ID,属性集合ID,属性集合明细名称
1 1 红色
2 1 绿色
3 2 大
4 3 中国
5 3 美国
需要注意的是,我们需要记住属性集合的ID,这样比较方便,我们在使用前可以对属性集合ID进行一个判断,如果是1,则判断颜色。