ERD with Multiple Paths
진단 메시지:
테이블간에 설정된 관련성에 따라, 테이블간의 연결에 있어서 다중경로(multiple paths)를 나타내는 사례임. 일반적으로 다중의 탐색경로(Navigational paths)가 나타나는 것은 중복된 데이터가 존재하고 있기 때문으로, 데이터의 무결성과 질의 성능 사이에 절충(trade off)이 필요함.
즉, 다중 경로는 각 사례별로 무결성의 위험을 감수하고 조회성능 향상을 선택할 것인지, 조회성능은 부족하더라도 무결성이 더욱 중요한 것인지 업무적인 중요성을 고려하여 중복 데이터를 그대로 둘 것인지 재검토와 경로 선택이 필요한 사례를 말함.
[Case 1] 무결성과 성능 이슈의 절충이 필요한 사례
|
|
|
ü “고객 – 주문 – 주문내역”의 구조에서 그림과 같이 설계한 경우 [OrderItem]의 Cust_id는 [Order]의 Cust_id와 중복으로 무결성 문제가 발생할 수 있음([Order]와 [OrderItem]의 ‘Cust_id’상이). 그러나 [OrderItem]에서 고객명을 참조할 때는 [Customer]만 Join 하면 됨. ü 만약, Integrity를 우선시 하여 [OrderItem]의 ‘Cust_id’를 제거하면, [OrderItem]을 기반으로 고객명을 가져올 때는 [Order]와 [Customer]를 모두 Join 해야 하기 때문에 상대적으로 조회 속도가 느려지게 됨. |
그런데, 아래 사례는 업무 규칙을 볼 때 잘못 진단된 사례로 판단됨.
[Case 2] 예외적인(잘못된 진단) 사례
|
|
|
ü 기본구조: “사용자(관리자)”- “대상자(관리대상자)”- “안전확인(관리내역)” ü [사용자]에 등록된 사람은 [대상자]에 등록된 다수의 사람을 관리함. [안전확인]은 이렇게 매핑된 사람뿐만 아니라 다른 [사용자]의 사람이 수행할 수 있음. 즉, [안전확인]의 ‘사용자ID’는 [대상자]에 등록된 ‘사용자ID’만이 아니라 [사용자]의 다른 사람에 의해 수행될 수 있음. ü 이러한 업무규칙의 경우, 성능이나 데이터 무결성의 절충 문제가 아니라 그림과 같은 다중경로의 관계설정은 필수적인 사례로 보여 잘못 진단된 사례로 판단됨. |
