规范化数据库模式

时间:2014-06-19 15:10:44

标签: database-design database-schema normalization database-normalization

我正在尝试设计一个准确代表调查的数据库架构及其所有问题和响应。以下是数据库的要求:

数据库本身需要适应各种调查(每个调查可能有独特的问题或可能是相同的)。每个问题都可以具有开放式响应或从列表中选择的响应。从列表中选择的那些可以具有0个,一个或多个响应,或者它们可以仅允许一个响应。我在解决每个问题的问题,响应和可能的回答选择方面存在的问题。这就是我到目前为止所做的:

ER Model

设计方式是调查表可以进行多次调查。每项调查都有多个问题。每个调查也可以由多个受访者(或相同)填写。一些问题可以有0,1或更多预定义的响应(例如,考虑多项选择)。这些响应也可能没有任何多项选择,但可能是开放式响应。因此,表“Possible_Responses”可能如下所示:

      Name                   QuestionID                Example Question

      Red                      1                        Favorite Color
      Blue                     1                        Favorite Color
      Green                    1                        Favorite Color
      Pizza                    2                        Favorite Food 
      Apple                    2                        Favorite Food
      Steak                    2                        Favorite Food

然后,Answers表可能如下所示:

        ID            Response                QuestionID       Example Question

        1               1                       1                Favorite Color
        2               1                       2                Favorite Food
        3               "Subjective Respones"   3                Some subjective quest.

然后,我可以将问题追溯到问题表,以确定答复是应该是开放式还是已关闭。

虽然这可能有效,但我感觉不正常。有没有人对如何最好地规范化这个架构有任何建议?

1 个答案:

答案 0 :(得分:1)

正如philipxy评论的那样,描述您可能遇到的问题或疑虑。

您定义了一个尚未绘制线条的关系(请执行此操作)。

表格应以单数形式命名。你混合了一些单数,有些复数。

事实上,你可以做一些不同的答案。如果允许某个问题有一个开放式回复,那么您可能无法表示。换句话说,开放式响应可能的响应,因此它应该表示为“Possible_Response”。您可以通过以下方式表示它:(a)在“Possible_Response”表上具有布尔列“open_ended_”,或者(b)在该表中具有特殊值的行,例如“开放式”。在任何一种情况下,“Answer”表都可以是“Possible_Response”表的子代。如果“Answer”是“Possible_Response”的子项,则Answer.Response列仅在属于标记为开放式的“Possible_Response”时使用。因此,Answer.Response列的名称应从“Response”更改为“open_ended_response _”。

“名称”可能不是“Possible_Response”中该列的最佳名称。

“答案”一词不以'e'结尾。

第2段第1句是什么意思?你的意思是调查的变化可能会给不同的参与者吗?如果是这样,应该有一个“变化”表。

通常我发现在页面下方绘制子表(如果可行的话)会很有帮助。

命名提示:(a)为了在SQL数据库实现中实现最大可移植性,请在名称中使用全部小写(以及使用下划线分隔)。 (b)SQL规范承诺永远不会使用尾随下划线。因此,添加尾随下划线将防止与键/保留字的任何命名冲突。这意味着“possible_response_”而不是“Possible_Responses”。

相关问题