数据库设计中的选择：实体成为属性还是表；⼆元关系还是多
元关系；
博主认为，设计的依据在于三种因素：
1、正确
1、表达清晰
2、效率
针对数据库的设计，经常考虑两个因素：
1、实体成为属性还是表
2、⼆元关系还是多元关系
第⼀条不⽤多说，如果设计出来的模型不能正确反映想要表达的实体和各种约束，这⾃然是失败的设计。⾄于第⼆条，如果不注重表达的情绪，⼀上来就想去考虑有关效率的细节，这样做很容易陷⼊迷惑，表达清晰的设计容易理解和维护。容易维护的设计不⼀定能针对实际需求达到⾼效率，所以需要优
化，⽐如修改关系模式避免连接操作，以及在物理上建⽴索引。
⾸先按照最清晰的⽅式来进⾏设计：每个实体集都单独对应⼀张表，并且采⽤多元关系。然后再来考虑效率问题。
如果每个实体集都对应⼀张表，但如果发现⼀个实体本⾝⼏乎不包含信息，并且与这个实体相联系的实体⽐较少，⽐如搜索引擎中的⼀个term或者url字符串，我们实在是没有必要再为这个实体创建⼀张表，只需要作为其他实体的某个字段就可以了。不需要每个实体都创建⼀个 ID 字段，因为实际的查询⽤不到这个id字段。如果视图⽤ id 作为⼀个term的标识，与其他实体相联系，就带来了连接的代价。总之，应该将字段很少并且和其他实体联系少的实体删除，这样的实体本⾝只在概念上存在，只出其他实体的字段中；应该将经常需要连接的联系表删除，直接在⼀个实体上添加外键字段。
⼀般来说只要三元关系不过分太长，不到把多元关系拆分成为多个⼆元关系的理由，⽆论是从清晰的⾓度还是从效率的⾓度，多元关系往往更加清晰的表达现实世界的概念，同时⼜避免了连接操作。多个⼆元关系意味着连接操作，连接操作⼀般⽐简单的过滤查询费时太多了，建⽴索引可以缓解查询问题，它的执⾏时间不能和连接操作相提并论，⽐如说考虑⽤户-商品-评论关系，某个⽤户对某个商品不太可能发表太多的评论，所以三元关系表也不会太长。当然要得到准确的答案还是得根据实际场景进⾏测试，定性的分析终究不能作为最终判据，⼀般还是先按照最清晰的⽅式设计。
两个⼆元关系不能表达三元关系！连接操作实际上是连通路径的过程，三元联系关系表的每条记录代表了⼀条长度为2的路径。这些路径不可能⽤两个⼆元关系表达，因为⼆元关系的连接操作可能会多出来很多本不存在的三元联系。必须要引⼊引⽤了每条路径的中间实体，表的长度不会有任何减少。
实体成为属性还是表？⼆元关系还是多元关系？相信已经有了更清晰的认识。在概念设计阶段我们要让设计清晰的表达概念，但是在实际逻辑设计阶段我们要避免执⾏可以省去的连接操作。
ps: ⼀个⼆元关系对应⼀个拓扑结构：⼆分图的实例。如果⼆分图的任意⼀个连通分⽀都是⼀颗根树，那么这个关系就是⼀对多、多对⼀、⼀对⼀关系，可以只有⼀个字段是主键；否则是多对多关系，两个字段都必须是主键。
树和⼆分图都是拓扑结构。
数据库属性的概念

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。