我正在用DBDesigner Fork设计一个社交网站的数据库,我需要帮助来理解关系类型......我对我应该关注哪种类型感到非常困惑在每种情况下使用。数据库设计:请帮我理解关系类型
有如下类型:1:1,1:N,1:N(非识别)中,n:M,1:(后代OBJ)1,1:1(非识别)
您能否在每种情况下给我一个简短的解释和实例?
我正在用DBDesigner Fork设计一个社交网站的数据库,我需要帮助来理解关系类型......我对我应该关注哪种类型感到非常困惑在每种情况下使用。数据库设计:请帮我理解关系类型
有如下类型:1:1,1:N,1:N(非识别)中,n:M,1:(后代OBJ)1,1:1(非识别)
您能否在每种情况下给我一个简短的解释和实例?
有三种基本类型的直接关联到数据库本身:
实际上,这些问题反过来归结为两个问题 - 子表中是否存在外键(1:*),还是需要中间表(n:m)。
一对一是直截了当的。它通常用于子打字。考虑到两个表:
person
id int NOT NULL
name varchar(255) NOT NULL
parent
id int NOT NULL
person_id int NOT NULL
spouse_id int NULL
有两种关系 - 一个1:1 识别(父母是一个人),和非识别(父可能有配偶)。现在,走了一步:
children
person_id int NOT NULL
parent_id int NOT NULL
的“孩子”表映射“父母”的方式向“人”表,孩子对父母,许多一对多的关系联系起来。
另外,在这个例子中,“父”将是后代对象'人' - 因为它扩展了人。大多数后代对象关系将是不确定的。
因此,如果我有类似“ID”的字段的“印象”表格, ImpressionID,UserID,PostID和其他表格“ImpressionsList”,“Impressions”和“ImpressionsList”之间的关系将是1:n识别? –
是的 - 但是,我想我会将ImpressionID重命名为ImpressionListID,以表明它是否为ImpressionList表的外键。另外,我会用另一种方式来表述这个语句:“ImpressionList”和“Impressions”将会是1:n,因为每个ImpressionList都有多个Impression。 –
查看here可以更好地了解关系类型的工作方式,因为这可能会给您一个相当不错的关于主题的探索以及更好地理解实体关系模型如何工作。
请参阅http://stackoverflow.com/questions/762937/whats-the-difference-between-identifying-and-non-identifying-relationships –