2012-06-20 4 views
0

나는 내 인생을 감당할 수 없다. 처음에는 너무 단순 해 보였고, 이제는 너무 오래 쳐다 보았습니다. 나무 숲이 보이지 않습니다. 본질적으로테이블 디자인 도움 : 엔티티 그룹화를 가리키는 여러 엔티티가 필요합니다.

우리가 등

ID Name Start End 
1 Name1 1300 1400 
2 Name2 13:30 19:30 
3 Name3 20:00 21:30 

... 이러한 abitrary이다, 일 부서가

우리는이 일 부문의 조합으로 요일을 구성 할 수 있도록하려면

, 그래서 우리는 WeekConfigurations 테이블을 가지고 있습니다

ID ConfigurationID DayOfWeek DayDivisionID Order 
1 1    1   1    1 
2 1    1   2    2 
3 1    2   2    1 
4 1    2   3    2 
5 2    1   1    1 
6 2    3   2    1 
7 2    3   3    1 

다른 엔티티 (Person, Office 등)가 특정 주 구성을 할당하도록합니다. 그리고 이것이 제가 풀려나는 곳입니다. 할당하려는 구성 ID는 기본 키가 아니므로 엔티티와 구성간에 참조 무결성을 적용 할 수 없습니다.

누구나 올바른 방향으로 나를 가리킬 수 있습니까? WeekConfiguration 테이블에 대해 나에게 재미있는 냄새가 있지만, 나는 그것을 볼 수 없다.

추신 : 죄송합니다, 나는 설명 할 수있는 좋은 다이어그램을했지만, 나는 안돼서과

답변

1

논리 레벨에서 해당 구성 아래에 "구성"과 "구성 항목"세트가 있습니다. 그래서 그 대신 하나의 구성 테이블의 두 가지를 사용 : 직접 외래 키의 부모 엔드 포인트로 사용할 수 있도록

enter image description here

이 디자인에서 ConfigurationId은 (Configuration 테이블의) 기본 키입니다.

ConfigurationItem PK는 구성 당 일일 기준으로 하루 단위로 사용할 수 있으며 대체 키 U1은 동일한 요일과 구성 내에서 명확한 순서가 유지되도록 보장합니다.

나는 또한 ConfigurationItem에서 surrogate PK를 피하기로 선택했다. 필요한 경우 쉽게 추가 할 수 있습니다 (기존 PK를 대체).추가 FK가있는 경우 복합 PK와는 잘 작동하지 않는 ORM을 언급하거나 사용하지 않았습니다.

+0

아, 물론 그렇습니다. 여분의 마일 가서 내게 다이어그램을 주셔서 감사합니다! – James

0

Yes (예)를 추가 할 수 없습니다. WeekConfiguration은 두 개의 테이블로 분할되어야합니다.

참조 무결성을 강화하려면 주 구성 당 정확히 하나의 레코드 (ID 하나)가있는 테이블이 필요합니다. 이 테이블에는 ConfigurationID이라는 열과 어쩌면 어떤 종류의 설명이 있어야합니다.

다른 테이블 (`WeekConfigurationDetail이라고도 함)은 세부 레코드, 주 구성이 구성하는 요일을 저장해야합니다. 열이 기존 테이블과 비슷하지만 기본 키 (ConfigurationID 다시) 자체가 기본 WeekConfiguration 테이블의 외래 키가됩니다. 같은 방식으로 다른 테이블 (엔티티)은 외부 테이블을 참조 할 수 있습니다.

WeekConfiguration 테이블에 하나의 열만있는 경우에도 의미없는 ID가 있지만 여전히 참조 무결성을 보장하려면 테이블이 필요합니다.

이 데이터베이스 디자인 패턴은 마스터 세부 사항 또는 상위 - 하위라고합니다.

+0

감사합니다 Jirka, 거기에 뭔가 잘못되었다는 것을 알았습니다. 나는 그것을 해킹 할 것이다 – James