2011-01-07 3 views
8

필자의 데이터베이스 기술은 평범하지 않으며 측량 데이터 용 데이터 모델을 설계해야합니다. 나는 이것에 대해 약간의 생각을 보냈으며 지금은 EAV model과 수백 개의 테이블과 수백 개의 열 (그리고 수천 개의 레코드)을 포함하는 디자인 사이에 갇혀 있다고 느낍니다. 이 작업을 수행하는 더 좋은 방법이 있어야하며이 포럼의 현명한 사람들이 나를 도울 수 있기를 바랍니다.조사 데이터 모델 - EAV 및 과도한 비정규 화를 피하는 방법은 무엇입니까?

제 질문은 : RDBMS에서 설문 조사 질문에 대한 답변을 어떻게 모델링해야합니까? SQL Server를 사용하는 것은 필수입니다. 따라서 대체 데이터 저장 시스템은이 논의에서 제외되어야합니다. (물론, 일부는 평가되어야하지만 여기서는 만족하지 않아야합니다.) 전체 데이터 모델에 대한 솔루션이 필요하지 않습니다. 지금은 Answers 부분에만 관심이 있습니다.

나는 다양한 포럼을 이미 검색했지만 해결책을 찾지 못했습니다. 다른 곳에서 이미 제공 되었다면, 실례지만 제게 읽어 줄 수 있도록 링크를 제공하십시오. 각 설문 조사가 n 개의 설문

  • 각 설문은 2,000 질문 정말 같은 소리 것을 무시하세요 (100-2,000 질문으로 구성되어 1로 구성

    1. : 데이터에 대한

      일부 가정은 내가 처리해야 응답 할 lot ...)

    2. 객관식, 자유 텍스트, 숫자 (연령, 소득, 비율 등)
    3. 각 설문 조사에는 10 ~ 200 개국이 포함됩니다. 응답자가 아닙니다. 실제로 응답자는 국가 별)
    4. 설문지 유형에 따라 각 설문지는 국가별로 100-20,000 명의 응답자가 응답합니다.
    5. 한 국가에서 설문지에 대한 설문지를 적용 할 수 있습니다. 즉, 질문 추가, 제거 또는 수정
    6. 한 국가의 데이터는 해당 국가의 별도 데이터베이스에 수집됩니다. 처음부터 온라인 통합의 가능성은 없습니다.
    7. 모든 국가의 데이터는 나중에 통합해야합니다. 예를 들어 한 국가에서 질문을 삭제 한 경우 모든 국가에서 일관된 디자인을 달성하기 위해 보낸 데이터에서 어떻게 든 파생되어야합니다.
    8. 통합 및 정리 소프트웨어를 작성해야합니다. 모든 국가의 데이터로 작업 할 수 있습니다.
      1. 결국 데이터는 플랫 파일, 국가 및 설문지 당 하나의 직사각형 그리드로 내보내 져야합니다.

    는 이미 다양한 배경을 가진 사람들로이 주제를 논의하고 아직 좋은 해결책에 와서하지 않았습니다. 나는 주로 두 가지 종류의 의견을 가지고 있습니다. 내가 한 테이블에 국가 및 설문 당 (전술 한 바와 같이 테이블과 컬럼의 부하와 함께 비정규 구조 데이터 처리 및 분석 투표 플랫 파일 (스프레드 시트 스타일) 작업에 사용되는

    1. 도메인 전문가,). 이것은 넓은 테이블을 피할 것을 배웠기 때문에 나에게 끔찍한 일 이겠지요. 작업 할 때 어떤 열이 실제로 테이블에 있는지를 알아내는 것은 짜증나게됩니다. 데이터베이스가 수백 개의 테이블로 어수선하게 될 것입니다. 비슷하지만 조금 다른 디자인을 가진 여러 데이터베이스를 설정하십시오.)
    2. O-O- 프로그래머는 강력하게 "표준화 된"디자인에 투표합니다. 그러면 모든 질문에 대한 모든 응답자의 모든 대답을 포함하는 중앙 테이블로 효과적으로 이어집니다. 이 테이블에는 유형이 sql_variant 유형의 열 또는 여러 유형의 응답 (객관식, 자유 텍스트, ..)을 저장하기 위해 유형이 다른 여러 응답 열이 있어야합니다. 전자는 본질적으로 EAV 모델입니다. 나는 여기 조 셀코를 따르는 경향이있다. 조 셀코는 그 사용법을 강력히 낙담시킨다 (그는 그것을 OTLT 또는 "하나의 진실한 조회 테이블"이라고 부른다). 후자는 각 행이 디자인에 따라 적용 할 수없는 유형의 널 셀을 포함한다는 것을 의미합니다.

    내가 생각할 수있는 또 다른 방법은 그것으로 이어질 것입니다, 그건 너무 일반적인 아니다 .. 대답 유형 당 하나 개의 테이블, 즉 등 객관식 문제, 무료 문자 질문 하나, 하나를 만들 것 많은 조합이 합류한다고 생각합니다. 새로운 대답 유형이 발명되면 표를 추가해야 할 것입니다.

    이 텍스트를 모두 지루해해서 죄송합니다. 입력 해 주셔서 감사합니다.

    건배, 알렉스

    PS : 어떻게 나사를 고정하기 위해 망치를 사용하는 방법 : 당신은 일반적인 문제와 씨름하고있는 것처럼 http://www.eggheadcafe.com/community/aspnet/13/10242616/survey-data-model--how-to-avoid-eav-and-excessive-denormalization.aspx

  • +1

    [EAV] (http://en.wikipedia.org/wiki/Entity-attribute-value_model) 솔루션에 대한 좋은 후보라고 생각됩니다. 그 길로가는 것에 대한 당신의 반대 의견은 무엇입니까? –

    +0

    문서 또는 NoSQL 데이터베이스 사용은 어떻게됩니까? 어쩌면 여기서 문제는 도메인 모델을 관계형 인프라에 적용하는 것입니다. 그렇다면 왜 그냥 피하지 않을까요? http://en.wikipedia.org/wiki/NoSQL을 참조하십시오. – rsenna

    +0

    EAV 모델은 무결성 제약 조건을 훨씬 더 복잡하게 만드는 것처럼 보입니다. 기본적으로 여러 데이터 유형의 값을 하나의 열에 집어 넣어야합니다. http://www.eggheadcafe.com/software/aspnet/32645959/generic-datatype-table.aspx – AlexDPC

    답변

    1

    이 소리 : 여기 같은 질문을했다.

    나열된 두 가지 대안이 각각 다른 이유로 불량입니다. 그러나 이는 관계형 데이터베이스 시스템에 특정 데이터 모델을 채우려고하기 때문입니다. 좋은 접근법은 관계형 데이터베이스 인 some other database/storage systems을 살펴보고, 몇 가지 시도해보고 프로젝트에 가장 적합한 것을 찾아내는 것입니다.


    은 내가 EAV 모델을 시도하고이 너무 복잡하기 때문에 포기, 나는 관계형 데이터베이스 시스템과 다중 테이블 모델을 시도 두려워했다. 관계형 데이터베이스에서 찾은 가장 쉬운 솔루션은 각 완료 응답을 단일 CLOB로 저장하고 responses 테이블의 JSON 또는 YAML (또는 다른 경량 유형)로 직렬화하는 것입니다.

    create table responses (
        id uuid primary key, 
        questionnaire_id uuid references questionnaires.id, 
        data text 
    ) 
    
    +0

    왜 그렇게 확신합니까? 관계형 시스템은 나와 내 동료가 여기에서 가장 잘 이해하고 인프라를 보유하고있는 것입니다. 또한 유사한 관계형 디자인이 개발되어 사용되고 있습니다. 예를 들어 http://www.databaseanswers.org/data_models/의 4 가지 "설문지"디자인을보십시오. 제발 나를 잘못하지 마세요. 저는 항상 새로운 기술을 배우고 사용하기를 열망하지만, 특히이 경우에는 갚아야합니다. 심지어 많은 사람들이 여기에 디렉토리 시스템에서 혼란스럽고 평범한 파일 시스템에서 벗어나는 것이 합리적이라고 확신 할 필요가 있습니다. – AlexDPC

    +0

    그는 망치가있어 나사로 작업하고 펜치를 추천합니까? – Mark

    +0

    내 권장 사항은 다음과 같습니다. 전체 범위의 데이터 저장소가 있습니다. SQL뿐 아닙니다. 문제 해결에 대한 해머 서랍을 들여다 보지 마십시오. 에이스 하드웨어 매장에 가서 나사에 맞는 드라이버를 찾으십시오. – yfeldblum

    -1

    바퀴를 다시 발명하지 않았습니까? 이미 구축 된 오픈 소스 조사 응용 프로그램이 있습니다. 요구 사항을 충족시키지 못하더라도 몇 가지를 다운로드하고 데이터 모델을 확인하십시오. 나는 SQL Server를 사용하는 경우

    +0

    http://www.limesurvey.org/에서 자세히 살펴 보았습니다. 그들은 분명히 각 조사에 대해 편평한 테이블을 만듭니다. 만들고 유지해야하는 테이블의 양을 감안할 때, 나는 그것을 피하고 싶습니다. 위에서 쓴 것처럼 EAV 형식 모델도 사용할 수 있습니다. 디자인에 대한 아이디어가 전혀없는 것은 아닙니다. 결정을 내리는 데 어려움을 겪고 있으며 여기에 약간의 의견을 묻습니다. – AlexDPC

    1

    것은, 고속 확인 될 것입니다, 나는이 작업을 수행 할 것입니다 :

    • 테이블 유형에 대한 질문에, 플래그 의 목록 (비트)로, 경우에 필요한 플래그 (비트), 경우가 존재 정답,
    • 테이블 국가의 연결 및 질문 국가의 목록 등
    • 표 (일부 국가는 몇 가지 질문을 답변 재치에 대한
    • 표를 얻지 못할 수도 에 대한 시간 열 질문 (들) 당신은 모든 옵션 질문 스파 스 열을 사용하여 XML을 파쇄에 정통한하지 않는 경우

    을 추가하는 것을 포함 옵션 질문 위한 XML 열입니다. 나는 테이블의 스파 스 열 수에 대한 제한을 정확하게 회상하지는 않지만 30,000을 초과한다고 생각합니다.SQL Server는 내부적으로 XML로 스파 스 열을 저장하고 열을 선택하면 인덱싱 할 수 있도록 파쇄합니다.

    아래 다이어그램은 SQL Server로 만든 다이어그램입니다. AL_A4 컬럼은 QL_Id = 4에 대한 응답을 보유 할 것이고 sparse 유형입니다. AnswerList 테이블의 QL_Id에는 AnswerList의 열을 희박하게 만들 필요가 있음을 알리는 표시가되어 있지 않습니다.

    국가마다 질문이 추가되므로 QuestionListCustom, QuestiontoCountryCustom 및 AnswerListCustom 테이블을 만들고 사용자 지정 질문의 정보를 추가하십시오.

    다른 방법으로 저장 장치를 설계하는 것이 확실합니다. 숙제가 아니라면 반드시 숙제를 돌려야합니다. 숙제가 아니라면 반드시 UN을 위해 일하십시오.

    alt text

    +0

    이것은 질문이 조사로 그룹화되어 있다는 사실을 완전히 무시합니다. –

    +0

    @ 스 태피 당신이 맞습니다. 설문 파트를 완전히 떠났습니다. 새 테이블이 추가되었습니다. –

    +0

    제안 해 주셔서 감사합니다. AnswerList 뒤에있는 아이디어를 이해할 수 있을지 잘 모르겠습니다. (필수) 질문 당 하나의 열이 포함될 것이라고 생각합니까? 그렇다면 다중 조사가 시작될 때 이것이 잘 작동하는지 의심 스럽습니다. 나는 열 이름이 일반적이라는 것을 이해하므로 조사 A의 질문 1은 조사 B의 질문 1과 완전히 다를 수 있습니다. 그러나 동일한 데이터 유형을 가져야 할 수도 있고 그렇지 않을 수도 있습니다.아니면 완전히 잘못 이해합니까? – AlexDPC

    4

    alt text 음 imgur 그래서 나중에 그림을 게시합니다 다운.

    이것은 관계형 모델 내에서 완전히 실현 가능하다고 생각합니다. 나는 이것을 어떻게 할 것인지 보여주기 위해 CDM을 만들었습니다.

    아웃 바운드

    그것은 나라의 설문 조사를 정의하는 4 개 요소를합니다. 일부 학부모 설문 조사, 국가 및 질문 목록 귀하의 질문에는 내부 관계가 있으므로 한 국가에서 질문을 "편집"하면 해당 국가에서 요청한 질문과 그 질문이 모두 출제됩니다. 당신이 필요로하는 다른 것은 가능한 답 엔티티/테이블입니다. 각 질문에는 가능한 대답의 관련 목록이있을 수 있습니다 (객관식 또는 범위 등). 그것들은이 "OUTBOUND"측면을 완전히 정의해야합니다.

    인바운드

    은 "인바운드"쪽은 2 개의 새로운 기관, 신청인과 답변입니다. 응답자는 간단하며 그 사람의 인구 통계 만 알고 있으면 여기에 국가와의 관계를 포함시킬 수 있습니다. 각 응답자는 특정 국가에서 설문 조사에 응답했습니다. (여행자 또는 이중 국적자의 경우 1 : n의 응답자가 될 수 있음)

    답변은 기본적입니다. 가능한 답변 목록에 나열된 선택 사항 중 하나이거나 제공됩니다. 대답이 숫자, 날짜 등일 수 있다는 사실에 모두 몰두하지 마십시오. FK 또는 일련의 문자입니다.

    보고서를보고

    ... 당신은, 국가 및 설문 조사를 선택 질문과 답변의 목록을 얻을거야이 모든 이상 참여합니다.

    대답 복잡성

    당신이 당신의 계산을 수행 할 위치에 따라 달라집니다. 사용자가 제공 한 응답에 Varchar2 (4000) 열을 사용한 경우 대답에 대한 데이터 유형을 설명하기 위해 질문 할 속성을 추가 할 수 있습니다. Q : 나이? DT : 정수 사이 (0과 130). 그런 다음 통합 레이어는 데이터베이스를 적용하는 대신 유효성 검사를 수행 할 수 있습니다. 또는 숫자, 날짜, 문자 및 CLOB에 대해 4 개의 열을 가질 수 있습니다. 그리고 통합 레이어가 사용할 열을 결정합니다. 이러한 대답을보고하면 Coalesce()를 사용하여 4 개의 열을 모두 선택하면됩니다."대답"

    없음의 데이터 유형에 약간의 모호함이 있기 때문에

    이 EAV인가, 그렇지 않아.

    EAV 모델은 엔티티를 속성 목록으로 분류합니다. 과 같이 :

    Entity  Attribute  Value 
        1   Fname   Stephanie 
        1   Lname   Page 
        1   Age   30 
    

    당신이 설문 조사 스키마의 대답 열 값 열 같은 단어와 숫자를 모두 들고 볼 여기 않기 때문에 당신이이 EAV를 정의라고 생각한다. 그렇지 않습니다. 이 모델에 3 개의 데이터 유형 열을 추가 한 것처럼 EAV에서 변경되지는 않습니다. 내가 했어

    사람들이 내가 튜닝 해요 쿼리는 "가능한 한 빨리"가야 말해 때

    나는 soooo를 싫어. 좋아요, 그래서 10 억 달러와 30 년을주세요. "잠깐, 뭐야?" "만큼", "최대한 빨리"는 요구 사항이 아닙니다. 당신은 데이터베이스에서 원하는 것을 검증 할 수 있습니다 ... Before 트리거의 분만을 빌드하십시오. 유효성 검사가 많이 있습니다.

    연령 열의 데이터 유형은 무엇입니까? 또는 생년월일 열? 데이터 소스가 무엇인지에 달려 있습니다. 일부 오래된 레코드는 월 및 연도, 또는 단지 1 년 또는 '1 년'또는 '1 년'을 가질 수 있습니다. 당신은 숫자 열을 가질 수없고 가능한 한 많은 검증을 할 수 없습니다. 및 NUMBER (2)가 NUMBER보다 더 나은 유효성 검사 일 수 있습니다. 이제 NUMBER (1), NUMBER (2), NUMBER ...가 "만큼"가질 수 있습니다. 나는 당신을 생각

    는 개념 데이터 모델이 아닌 물리적 하나로이의

    생각해을 넘어 얻고있다. 해당 용어로 설문 조사은 엔티티입니다. 질문이은 설문 조사의 엔티티 또는 속성입니다. 을 만들었다면 PER 테이블 하나가 분명히 Question가 설문 조사의 속성 일 뿐이며 수직으로 저장하면 EAV가됩니다. 이 모델이 보여주는 것은 질문이 실제로 또 다른 존재라는 것입니다. 질문 사이에는 관계가 있습니다 (예 : '국가는 질문을 편집 할 수 있습니다'. 원래 질문이 있었고 편집되었습니다. 각 질문에는 가능한 답변 모음이 있습니다. 그리고 가장 중요한 것은 이것입니다. 그들은 모두입니다. EAV에서는 fname, lname, bdate, age, major, salary 등을 호출합니다. 매우 다른 모든 것들, 속성들. 이 경우 우리는 설문 조사를 시작한 에이전시의 이름과 발급일을 포함하지 않으며 날짜는 만기일과 질문 등입니다.

    다른 방법으로 말씀 드리겠습니다. 너 페덱스 야. 특정 이벤트에 대한 시간 소인을 저장하려고합니다. 패키지가 시설이나 차량에 출입 할 때마다 트럭 픽업에 걸리는 시간, 트럭에서 시간을내어 첫 번째 시설로 옮길 시간, 그 시설에서 비행기로 나가는 시간 등. 수평으로 보관합니까? 미리 홉 수를 어떻게 알 수 있습니까? 수직으로 보관하면 자동으로 EAV가됩니까? 그리고 만약 그렇다면.

    날씨가 급한 회사에서 전국 각지에서 기온이 상승하고 있습니다. 센서가 온도가 +/- 정도 변화 할 때 판독 값을 보내도록 설계되었다고 가정 해 봅시다. sensor_ID를 저장하는 경우 timestamp | temp는 EAV라는 독서 테이블입니까? 각 판독 값은 센서의 속성이 아니며 수집/시리즈에 속하는 항목입니다.

    답변의 수직 저장이 EAV와 공통점이있는 한 가지는 분석 쿼리를 수행하는 것이 어렵다는 점입니다.TRUE로 대답 한 모든 사람들의 목록을 5 번과 10 번 질문으로하고 싶었지만 6 번과 11 번 FALSE는 수직으로했을 때 매우 어려울 것입니다. 아마도 그것이 당신이 EAV를 보는 이유 일 것입니다. 그렇게하고 싶다면 다른 저장 공간이 필요합니다. 관계형 질문 및 답변 저장소는 최상의보고 데이터베이스가 아닙니다. Fedex 예제로 돌아가 보겠습니다. 행이 수직 일 때 "전송"시간보고를하는 것은 간단하지 않습니다.

    +0

    당신의 제안에 감사드립니다. 이것은 EAV 모델의 또 다른 예입니다. 나는 답을 문자열로 저장하고 싶지는 않습니다. 왜냐하면 모든 타입 캐스팅이 포함되기 때문입니다. 또한 데이터베이스에서 최대한 많은 유효성 검사를하는 것이 좋습니다. 따라서 데이터 유형 당 하나의 열을 갖는 것이 내게 좋을 것입니다. 나는 또한 nulls의 양을 줄이기 위해 데이터 타입 당 하나의 테이블을 갖는 것에 대해 생각해 보았다. 이제 나의 주요 목표는 모든 솔루션의 이점을 이해하는 것입니다. 그렇다면 다중 와이드 테이블을 사용하는 접근 방식보다 솔루션을 선호하는 이유는 무엇입니까 (제 초기 질문, 하단의 1 번 지점 참조). – AlexDPC

    관련 문제