数据库设计 – 我的数据是否已标准化？
|
>使用识别父母(和祖父母)的复合键优于使用ID的一个原因是,例如.当你只需要问题和主题中的列时,你不必从Subtopic中选择SELECT,你可以直接从Question获得TopicCode;而对于ID,你被迫从Subtopic中选择,这不是报告要求的一部分,它是由于糟糕的关系建模造成的;未能实现识别关系,意义重大.只有一个原因是数据堆只有ID作为PK(作为FK携带)比标准化关系数据库执行更多的工作. >因为有关表格简单而且很小,这可能不是证明关系密钥/ IDENTITY列限制的优越性的好例子;考虑任何大的祖父母::父::子表. >另一个原因是失去了意义.例如.用户可以简单地选择TopicCode,SubtopicCode,Question FROM Question,并理解结果集. 对评论的回应2 Progressed Data Model 101102 对评论的回应3 我不明白你如何使用相同的图像文件与不同的问题？ 简单的例如. “命名一只不会飞的鸟”和“什么是鸸”都可以使用相同的Emu照片.这是我在上面主帖中的(1)假设.该模型允许它通过在FileName上提供非唯一索引. 您是否应在问题表中包含Media.FileName外键并从Media表中删除QuestionId？ 好吧,不.我建模的方式有几个优点.如果它在问题表中,那么一些大药水的时间,它将是空的.你需要一个Filename索引来搜索它们;看它是否被使用;或不;等等.这意味着我们无法索引FileName列(或者我们可以索引它,但由于Nulls索引会很慢).现在它被建模为： >“选项”或问题的子类型(具有图像的子类型) 它可以设置为图像库(唯一索引).我们知道一个问题可以有零对一的图像.您可以告诉我们您的决定,我将更改模型： >图像是唯一的文件名;它们只能用于一个问题 那是什么样的关系？ 1 :: 1？ 是.媒体结束是“optonal”.确切地说：一个问题有零或一个媒体.因此,“可能有”是动词短语或关系的标题. 该模型以“自然”的层次结构为基础：父母高于儿童;子类型在同一水平上. 看起来不像其他n :: n或1 :: n关系. 没有n :: n关系. (在逻辑级别有一个;它在物理级别实现为关联表.) **为什么在QuizQuestion表中包含Answer字段？* 您想在哪里存储用户的答案？ 看,你需要Quiz和QuizQuestion表;他们之前是有效的实体,你当时没有看到,但你现在做的. 主题和子主题之间的关系在子主题表中定义.在问题表中,您已包含TopicCode和SubtopicCode.你说(如果我没记错的话)包括TopicCode是好的,因为我可以直接从Question表中访问Topic而不加入Subtopic表. 是.按照上面的(1.Subtopic). 但是,根据您的模型,每当我向DB输入新问题时,我都应该选择一个主题和一个子主题[对于问题,从现有列表中]. 嗯,无论如何你必须这样做;该模型只是执行它.我理解(根据数据)这就是你所需要的. One Suptopic可以属于多个主题.所以你必须给它一个Topic和一个Subtopic(特定的组合). 该数据库如何确保子主题属于Subtopic表中描述的某个主题？ 你没有看到吗？你能看到Subtopic表已经提供了特定的[无论你插入什么] Topic :: Subtopic组合……而不是其他组合？好的,所以当你添加一个新的问题,并给它一个主题和子主题(这是SubTopic的主键,以及问题中的外键)时,数据库将强制执行FK,使得只有一个主题的组合： ：可以使用SubTopic中存在的子主题. 这是对良好自然关系键的力量的一个小洞察. 这是一个良好的关系模型的美妙之处：它提供了来自单个[正确建模]结构的许多要求. 对评论的回应4 Progressed Data Model 101103 Progressed Data Model 101109 IDEF1X Notation （编辑：瑞安网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
