계층 적 데이터를위한 테이블 디자인

Question

섹션이 포함 된 테이블을 디자인하려고하는데 각 섹션에는 작업이 포함되어 있으며 각 작업에는 하위 작업이 포함되어 있습니다. 나는 하나의 테이블 아래에서 그것을하고 싶다. 저에게 확장 가능한 최상의 단일 테이블 접근법을 알려주십시오. 나는 데이터베이스 디자인에 새로운 경험이있다. 또한 단일 테이블이 최선의 접근 방법이 아니라면 최선의 접근 방식이 될 수 있는지 제안하십시오. 나는 DB2를 사용하고있다.

Answer 1

몇 가지 방법이 있습니다. 둘 사이에 많은 관계로 하나가 될 수 섹션과 작업

:

하나의 아이디어는 두 개의 테이블을 사용하는 것입니다. Task 테이블은 TaskId와 ParentTaksId가있는 트리로 설계 될 수 있습니다. 즉, n 레벨 (하위 작업 및 하위 작업 등의 하위 작업)으로 진행할 수 있습니다. 루트 태스크를 제외한 모든 태스크에는 상위가 있습니다.

나는 위에서 설명한 작업 표에 섹션 열을 추가하는 단일 테이블을 사용하여이 문제를 해결할 수 있다고 생각합니다.

Answer 2

장기적으로는 비효율적 일 수 있지만 모든 것을 하나의 테이블에 넣으려는 경우. 이것은 당신이 당신의 데이터베이스에 불필요한 반복 된 데이터 그룹을 저장할 것이고 이것은 프로세서와 메모리에 전혀 도움이되지 않는다는 것을 의미합니다. 사실 Normalization rules을 위반하고 더 구체적으로 1st Normal Form을 말하면 테이블에 반복 그룹이 없어야합니다. 그리고 실제로는 3rd Normal Form을 위반하게됩니다. 이는 비 기본 키가 다른 비 기본 키에 (전환되는) 종속성이 없음을 의미합니다.

일러스트레이션을 제공하기 위해 디자인을 하나의 테이블에 넣을 것입니다. 나는 가능한 영역을 추측 할 것이지만 토론을 위해서이기 때문에 그것을 감당할 것입니다. 아래의 그래픽을 봐 :

(이 오히려 작은이지만 이미지를 다운로드하고 가까이 자신을 위해 그것을 볼 수있다) 위의 그래픽을 볼 경우, SectionName, Taskname, TaskInitiato R, TaskStartDate 및 TaskEndDate은 앞에서 언급 한 것처럼 1st Normal Form의 위반을 반복 할 필요가 없습니다.

둘째 Taskname, TaskInitiator, TaskStartDate 및 TaskEndDate이 경우 기본 키이어야 대신 SectionID의 기본 키 (별도의 표에있는 경우)하지 않은 TaskID를 기능에 의존한다. 이것은 Transitional Dependence가 없거나 다른 기본 키가 이 아닌 다른 기본 키에 종속되어야한다고 말하는 제 3 표준 양식을 위반 한 것입니다.

정규화되지 않은 인스턴스가 있지만 정규화해야한다고 생각합니다. 내 견해로는 디자인에 세 개의 테이블이 있어야합니다 (예 : Sections, Tasks 및 SubTasks).

Section는, 즉, Tasks에 관련되는 부분은 Tasks 많은있을 수 있습니다. Task은 Sub-Tasks과 관련이 있습니다. 즉, Task은 많은 Sub-tasks을 가질 수 있습니다.

Answer 3

간단히 말하면, 작업에 1 개의 테이블을 사용한다고 말하고 싶습니다.

모든 다양한 속성 외에도 각 작업에는 기본 식별자가 있어야하고 선택적으로 상위 작업의 식별자가 포함되어야하는 또 다른 열이 있어야합니다.

z/OS 용 DB2를 사용하는 경우 recursive query with a common table expression을 사용합니다. 그렇지 않은 경우 hierarchical recursive query in DB2 for i 또는 in DB2 for LUW (Linux, Unix, Windows)을 사용할 수 있습니다.

하위 타스크 관계의 특정 부분을 전문으로하는 더 많은 테이블을 필요로하는 다른 디자인은 불필요하게 문제 나 제한을 도입 할 수 있습니다.

Answer 4

원래의 포스터가 정확히 이해한다면, 얼마나 많은 수준의 계층 구조가 필요할까요 (따라서 "등등"). 그의 문제는 깊이있는 구조를 유지할 수있는 디자인을 만드는 것입니다.

Imho는 하나의 대답이없는 복잡한 문제입니다. 이러한 디자인을 구현할 때 다음과 같은 요인을 계산해야합니다.

구조가 상당히 일정합니까? (얼마나 많은 글을 씁니까?) 이 구조는 얼마나 자주 읽습니까? 어떤 작업이 가능해야합니까? (모든 어린이에게 주어진 객체의 객체를 가져옵니다? 부모 오브젝트를 취득? 직접 아이를 가져?)

을 구조 당신은 이런 식으로 표에서 중첩 된 세트 모델 (http://en.wikipedia.org/wiki/Nested_set_model)

를 사용할 수있는 일정 경우 '왼쪽'과 '오른쪽'열이 있습니다. 부모 객체는 왼쪽 및 오른쪽 열에 해당 자식 객체의 값을 encompasing합니다. 이 같은 쿼리를 사용하여 개체의 모든 자식을 나열 할 수있는 방법으로

:

SELECT child.id 
FROM table AS parent 
JOIN table AS child 
    ON child.left BETWEEN parent.left AND parent.right 
    AND child.right BETWEEN parent.left AND parent.right 
WHERE 
    parent.id = @searchId 

이 디자인 읽기가 매우 빠르게 할뿐만 아니라, 극단적으로 비용이 많이 드는 때, 예를 들어 구조 변화 (어떤 객체에 자식을 추가 할 때 삽입 된 객체보다 높은 값을 가진 객체를 업데이트해야합니다.

실시간으로 구조를 변경할 수 있어야하는 경우 두 테이블 (하나는 객체를, 두 번째는 parentId, childId, differenceInHierarchyLevels와 같은 구조)를 사용하는 디자인을 사용해야합니다.