데이터베이스 스키마 표준화

Question

모든 질문과 답변을 포함하여 설문 조사를 정확하게 나타내는 데이터베이스 스키마를 디자인하려고합니다. 데이터베이스에 대한 요구 사항은 다음과 같습니다.

DB 자체는 다양한 설문 조사를 수용해야합니다 (각각 고유 한 질문이 있거나 다를 수 있습니다). 각 질문에는 끝나거나 목록에서 선택한 응답이있을 수 있습니다. 목록에서 선택한 사용자는 0 개, 1 개 또는 그 이상의 응답을 가질 수 있으며 하나의 응답 만 허용 할 수 있습니다. 질문, 응답 및 질문 당 가능한 응답의 가능한 선택을 정상적으로 정상화하는 데 문제가 있습니다. 이것은 내가 지금까지 무엇을 가지고이 설계되어

방법은 설문 조사 테이블이 여러 설문 조사를 잡아 것입니다. 각 설문 조사에는 여러 가지 질문이있을 수 있습니다. 각 설문 조사는 여러 응답자 (또는 동일한 응답자)가 작성할 수도 있습니다. 일부 질문에는 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 

를 그런 다음, 답변 테이블은 다음과 같습니다

 ID   Response    QuestionID  Example Question 

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

나는 그 여부를 결정하기 위해 질문 테이블에 다시 질문을 추적 할 수 응답은 개방형 또는 폐쇄 형이어야합니다.

이 방법이 효과가 있긴하지만 제대로 정상화 된 것 같지 않습니다. 누구든지이 스키마를 가장 잘 정규화하는 방법에 대한 제안이 있습니까?

Answer 1

philipxy가 주석을 달았으므로 발생할 수있는 문제 또는 우려 사항에 대해 설명하십시오.

아직 한 줄을 그리지 않은 관계를 정의했습니다 (그렇게하십시오).

테이블의 이름은 단명이어야합니다. 단수형과 복수형을 혼합했습니다.

사실, 답을 통해 뭔가 다른 것을 할 수 있습니다. 질문에 무제한 응답이 허용되는 경우와 그렇지 않은 경우를 대표하지 않을 수 있습니다. 다시 말하면 개방형 응답 은 가능한 응답 인이므로 "Possible_Response"로 나타내야합니다. "Possible_Response"테이블에 부울 열 "open_ended_"을 갖는 (a) 또는 (b) "개방형"과 같은 특수 값이있는 해당 테이블의 행을 가질 수 있습니다. 두 경우 모두 "응답"테이블은 "Possible_Response"테이블의 하위 테이블이 될 수 있습니다. "Answer"가 "Possible_Response"의 하위 항목 인 경우 Answer.Response 열은 제한없는 것으로 표시된 "Possible_Response"에 속할 때만 사용됩니다. 따라서 Answer.Response 열의 이름은 "Response"에서 "open_ended_response_"로 바뀌어야합니다.

"Name"은 아마도 "Possible_Response"에서 해당 열의 가장 적합한 이름이 아닙니다.

단어 "대답"은 'e'로 끝나지 않습니다.

두 번째 단락의 첫째 문장은 무엇을 의미합니까? 다른 참가자에게 설문 조사의 변형을 줄 수 있다는 의미입니까? 그렇다면 "변형"표가 있어야합니다.

일반적으로 페이지에서 하위 테이블을 아래쪽으로 그려 보는 것이 좋습니다 (가능한 경우).

명명법에 대한 팁 : (a) SQL 데이터베이스 구현에서 최대의 이식성을 얻으려면 이름에서 소문자를 모두 사용하십시오 (밑줄로 분리). (b) SQL 스펙은 후행 밑줄을 사용하지 않을 것을 약속합니다. 따라서 후행 밑줄을 추가하면 키/예약어와의 이름 충돌을 방지 할 수 있습니다. 이는 "Possible_Responses"보다는 "possible_response_"를 의미합니다.

Answer 2

일부 기능 의존성을 다이어그램에서 직접 추출 할 수없는 경우가 있습니다. 더 어려운 경우에는 명시 적으로 주석을 달고 종속성을 손으로 분석하거나 새로운 도구 dbschemacmd at elstel.org을 사용하여 다시 확인하십시오. 좋은 스키마 설계는 모델링 언어를 사용하여 모든 것을 표현할 수있는 것은 아니기 때문에 종종 손으로 주석을 작성해야하는 가능한 제약 조건에 대해 생각해보아야합니다. 추가적인 단일 및 다중 값 종속성은 이러한 제약 조건의 특수한 유형입니다. 다이어그램에서 삼항 연관을 사용하지 않았으므로 여기서 다이어그램 외에도 많은 의존성이 명시되어 있습니다 : f.i. 응답자, 설문 조사 -> 응답자 설문 조사 회원, ...