2014-05-22 1 views
0

저는 모델 회의 그룹을 관리 할 응용 프로그램의 데이터베이스 디자인 작업을하고 있습니다. 나는 의회를 대표하는 대상에 특별한 문제가 있습니다. 현재 필드 목록은 다음과 같습니다.작은 테이블을 사용하는 경우

| Congress | 
    +------------+ 
    | congressID | 
    | adminID | 
    | speakerID | 
    | hopperID | 
    | floorID | 
    | rulesID | 
    | (etc.)  | 

이것은 각 필드의 의미입니다. 표/개체는 모두 대문자입니다.

  • congressID는 (분명히)
  • adminID 기본 키는 : 모델 대회, 즉, 교사를 실행하는 독특한 PERSON를 참조합니다.
  • speakerID : 참고 고유 REP (대표) 의회
  • hopperID 위해 스피커의 역할 : 참조 특수 COMMITTEE (청구서를 보낼 수있는 장소 인위원회)가되는 새로운 법안은 처음에 전송합니다.
  • floorID는 : 의회의 바닥을
  • rulesID을 표현하는 데 사용되는 COMMITTEE 참고 : 규칙 COMMITTEE

당신이 볼 수 있듯이,이 필드는 각 모델 의회의 맥락에서 참조 할 중요한을 참조합니다. 내가 겪고있는 문제는 외래 키를 표현하는 방법입니다. 복합 기본 키, 예를 들어, 각 필드에 대한 작은 테이블을 확인 그들이 지금으로

  1. 이 의회 테이블에 그들 모두를 포함, 또는
  2. :

    은 내가 두 가지 선택이 보인다 발표자의 RepID + 회의 ID, 호퍼의위원회 ID + 의회 ID 등

더 세분화되어 있어야합니다. 아니면 이것은 불필요하게 일을 복잡하게합니까? 나는 잠시 동안 첫 번째 레이아웃으로 디자인을 둘러 보았지만, 그 지점에서 ERD를 그리려 할 때마다 관계가 절망적으로 엉망으로 보입니다.

+0

청구서는 한 호퍼위원회에만 보낼 수 있습니까? 현실적인 것처럼 보이지 않습니다. 외래 키 테이블에는 아무 문제가 없습니다. 그러나, 당신은 의회와 연사, 호퍼위원회,지면위원회 및 규칙위원회 간의 일대일 관계를 모델링합니다. –

+0

호퍼위원회는 단순히 새로운위원회가 최초의 적절한위원회에 소개 될 때까지 개최됩니다. 이 과정에서 법안은 실제로 어떤 집회 또는 절차 적 경유지가되어야합니다. – K1nesthesia

+0

각 특별위원회와 회원 역할에 대한 테이블을 제안 하시겠습니까? – K1nesthesia

답변

0

GROUPS는 이름이나 설명 (1 등, 2 등)의 총회 수를 정의 할 수있는 테이블이어야하며 각 PERSON은 이름과 전기 필드가있는 ID가 있어야합니다. 그런 다음 M : N 테이블 (GROUPMEMBERS라고 부름)은 자체 ID, GROUPS를 참조하는 ID 및 (PERSON 또는 GROUPS - 두 개의 필드가되므로 계층의 다른 그룹에 그룹을 연결할 수 있습니다.) 그런 다음 자체 ID, 시작 날짜 (및 종료 날짜), GROUPMEMBERS에 대한 참조 및 구성원 내에서 행당 하나의 역할을 정의하는 TYPES 테이블에 대한 참조가있는 태그 테이블 (GROUPROLES)이 있습니다.

무엇이 당신을 허용합니까? 사람의 역할은 이제 역할에 첨부 된 날짜를 사용하여 중간 회의를 변경할 수 있습니다. 위원회는 의회의 일부가 될 수 있으며 (설명이나 이름에 의회 #가있는 그룹으로 지명 됨)위원회 (예 : 의장)의 역할을 지정할 수 있습니다.

단점? 보고는 약간의 체조를 포함하지만 불가능한 것은 아닙니다. 테이블 이름은 직접적으로 상관 관계가 없지만 응용 프로그램 사용자에게 노출 될 필요는 없습니다. 그룹 당 역할 당 구성원 수에 대한 제약 조건은 데이터베이스의 사용자 지정 함수로 설정되거나 응용 프로그램 제어 (권장되지 않음)되어야합니다.

이렇게하면위원회를 통해 항목의 흐름을 추적하는 종속 인프라를 설정할 수 있으며 한 사람이 항목을 통과 한 그룹에 대한 회원 자격으로 한 번 보았던 횟수를보고 할 수 있습니다. 또한 문제의 투표에 대한 집계를 실행하고 그룹을 참조함으로써 투표를 추적하고 정보를 대규모 그룹 투표로 비정규 화하는 데 사용할 수 있습니다 (투표에 따라 통과하거나 죽는 것과 같은). 이런 경우라면 아마도 역할을 역사적인 테이블의 하위 클래스로 만들고 모든 것을 중앙 역사에서 실행할 것입니다.

+0

제안 해 주셔서 감사합니다. 그러나 저는 주로 "특별"위원회의 자격 축소에 관심이 있습니다. 호퍼, 플로어 및 규칙위원회는 일반위원회와 동일한 속성을 갖지만 회의의 절차에 특히 중요합니다. 의회 테이블에있는 필드 또는 다른 방법으로이 사실을 기록할지 여부는 확실하지 않습니다. – K1nesthesia

+0

나는 제안 된 구조가 그것을지지하지 못하는 것을 보지 못한다. 의회 절차에 "특별한 중요성"이라고 할 때 왜 이것이 역할 테이블의 하위 클래스에서 처리되어 특정 역할 유형에 대한 추가 속성을 저장할 수 없습니까? –

+0

질문이 순진 해 보이면 사과드립니다. 이것은 내 첫 번째 데이터베이스입니다. _members_의 경우, "특정 역할 유형에 대해 추가 속성을 저장하는"것이 좋습니다. 나는 당신에게 그것을 준다. 그러나 특별위원회에 대한 추가 정보는 필요하지 않으며 단지 회의 내에서 독특하고 의미가있다. 그렇다면 별도의 테이블을 만드는 것이 여전히 바람직한가? – K1nesthesia