数据库设计 – 为具有多个多对多关系的视频游戏业务域设计数据库

复合键的使用是从关系范式的起源于Dr. E. F. Codd引入的,正如他在1970年的开创性论文A Relational Model for Large Shared Data Banks中所包含的例子中所证明的那样(正是,它也提供了处理概念M：N关联的最优雅的方法). .

我提出了a db<>fiddle和a SQL Fiddle,它们都在Microsoft SQL Server 2014上运行,因此可以对结构进行测试.

正常化

规范化是一个逻辑层次的过程,基本上说,

>通过第一范式消除非原子列,以便通过使用的数据子语言(例如,SQL)更容易处理数据操作和收缩;和
>通过连续的正常形式消除特定表的列之间的不良依赖关系,以避免更新异常.

当然,必须考虑所讨论的表格和列所带有的含义.

我喜欢把规范化看作是建立在科学基础上的测试,一旦设计师设计了稳定的逻辑层次安排以确定其项目是否符合所有正常形式,设计师就会将其应用于相关元素.然后,如果需要,设计者采取适当的纠正措施.

冗余

在关系模型中,虽然列中包含的值的重复不仅可以接受,而且是预期的,但禁止重复行.在这种程度上,据我所知,在之前暴露的逻辑布局中包含的所有表中都会阻止重复行和其他类型的有害冗余,或许您想澄清您在这方面的关注.

无论如何,您当然可以(a)通过正常形式评估您自己的结构,以确定它是否符合要求,以及(b)在必要时进行修改.

相关资源

>在this series of posts中,我提出了一些关于直接M：N关联的讨论,该关联可以使两种不同实体类型的实例相互关联.
>在this other one中,我提出了一种处理“物料清单”或“零件爆炸”构造的方法,其中我描述了如何连接相同类型实体的不同实例.

三元协会

您通过评论提出了另一个重要方面(发布在现已删除的答案中)：

Every time I try to make a bridge the elements in that bridge also have a Many to Many,I’m under the impression that isn’t allowed or at least discouraged.

这种情况似乎表明您的一个问题与概念三元关联有关.基本上,当存在(1)涉及(2)其他两种关系的关系时,这种关联就出现了,换句话说,“关系之间的关系” – 一种典型的情况 – .

在适当管理的情况下,这些安排也不会带来有害的冗余.并且,是的,如果存在某个用例,您确定此类关系在“真实世界”实体类型中出现,则必须(i)建模并且(ii)在逻辑级别上准确地声明它们.

> Here is a question and answer我们分析了一个关于调查的话语领域,其中包括一个三元关联的例子.
>在this very good answer中,@Ypercube提供了一个图表和相应的DDL结构,用于形成有趣的菱形关系,这与这类场景非常相似.

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!