1.엔티티타입 검토

선정된 PK가 업무적으로 발생하는 자료의 유일성을 보장하는가?

• 이유 ▶ 엔티티타입 내에 저장/관리되는 자료의 유일성을 식별하기 위한 것이다.

주요 오류 유형 사례

(1) 자료의 유일성을 보장할 수 없는 항목에 의한 PK선정

• 자료의 유일성을 보장할 수 없는 경우 : 업무 분석이 구체화되면서 초기에 예측했던 주식별자가 유일성의 요건을 충족하지 못할 때 주로 발생한다.

(2) 일반적으로 필요 이상의 항목을 PK로 선정하는 경우

• 두 개 이상의 부모 엔티티타입이 하나의 자식 엔타티타입과 만나 상위 부모 엔티티타입 PK를 모두 자식 엔티티타입으로 PK에 포함시켰을 경우에 주로 발생한다.
• 예1) ARC 관계에 의한 여러 부모와 자식 엔티티간의 관계

• 오른쪽 모델에서 구성된 PK처럼 여러 부모로부터 받은 PK를 그 속성에 따라 하나로 통합될 필요.
• 계약이력 엔티티타입에는 수탁 약정 엔티티타입이든지 보험계약 엔티티타입이든지 특정 시점에는 하나의 관계만 있을 수밖에 없으므로 비식별자 관계로 연결할 수밖에 없다.
• 양쪽에 선택 관계로 해주어야 정상적으로 이 관계가유지될 수 있다.

예2) 하나의 완전 종속 부모와 기타 부분 종속 부모를 가진 자식 엔티티타입

• 확정내역은 원고나 피고 하나만 가능하다는 업무 규칙을 적용하기에 적절한 PK가 될 수 없다.
• 장해내역에 등록된 모든 데이터는 확정내역에도 등록되어야한다는 PK구조를 가지고 있음.
• 확정내역에 대한 장해내역의 관계가 PK 상속 관계가 될 수 없는 비식별자관계 표현.
• 결론 : 확정내역 엔티티타입에 따른 장해내역 엔티티타입이 원래 존재하였고, 상소내역 엔티티타입에 따른 장해내역 엔티티타입이 별도로 존재했던 것이다.

선정된 PK는 효율적인 모습인가?

*이유 ▶ SQL 등을 통해 데이터의 입력, 수정, 조회, 삭제 등을 처리할 때 SQL 전반에 걸쳐 매우 빈번히 사용되는 속성임

주요 오류 유형 사례

잘못된 ERD

• PK를 복잡하게 선정함으로써 업무 전체적으로 엔티티타입에 PK가 복잡해지는 경우

개선 ERD

• ERD의 중심 엔티티타입인 사원의 PK가 사원번호로 단순화됨으로써 자식 및 손자 엔티티타입의 PK가 단순하게 될 수 있다.
• PK가 단순해지면 복잡한 SQL문장이 훨씬 더 단순해질 수 있다.

자료의 발생 유형이 유사한 엔티티타입은 통합되었는가?

주요 오류 유형 사례

(1) 장표 단위의 엔티티타입 생성

• (문제) 시스템을 구축했을 때 매출이 발생하거나 변경되어 두 엔티티타입을 동시에 생성/변경해야 하는상황
• (해결) 매출은 특정 사원이 특정일자에 특정 제품을 판매(Who, When, Whar)하는 것으로 나타나 사원 기준으로 테이블을 수정

(2) 집약도가 큰 여러 개의 통계 엔티티타입

• (문제) 고객이 요구하는 통계 수만큼 엔티티타입을 생성
• (해결) 고객의 요구에서 공통 요소를 도출하여 활용할 수 있는 엔티티를 생성하면 엔티티타입의 수를 최소화할 수 있다.

독립된 엔티티타입이나 엔티티타입의 그룹은 없는가?

• ERD에 독립된 엔티티타입이나 엔티티타입 그룹의 존재는 업무 분석이 미흡한 것으로 의심할 수 있다.

예외

• 1. 코드 엔티티는 관계를 갖지만 코드 엔티티의 관계를 일일이 표현하면 ERD가 매우 복잡해지므로 일반적으로 표현하지 않는다.
• 2. 통계 엔티티타입은 검색 편의를 위한 단순한 조회용 엔티티로서, 업무적 흐름이 없다.
• 3. 시스템 관리 엔티티타입은 업무와 개별적으로 시스템을 통제하기 위한 엔티티타입이므로 경우에 따라서는 업무적 연계가 없을 수도 있다.

병합 또는 분리되어야 하거나 불필요한 엔티티타입은 없는가?

주요 오류 유형 사례

(1) 연속적인 업무 절차가 갖는 엔티티타입의 병합으로 인해 발생하는 문제

• (문제) 그림에 심의 및 확정이 종결된 자료를 확정이 취소되어 해당 자료를 삭제하면, 심의 정보까지 같이 삭제된다.
• (해결) 그림에 확정 취소 여부를 관리하여, 확정을 취소할 때 심의 데이터에 대한 영향 없이 데이터를 관리할 수 있다록 유도할 수 있다.

(2) 대칭적인 업무의 경우엔티티타입의 분리

• 엔티티타입을 통합하여 관리한다면, 발행인별 전표 현황, 발행 일자별 전표 현황의 보고서를 출력할 때
• 엔티티타입을 분리하여 처리하는것보다 훨씬 유리하다.

추가적으로 도출되어야 하거나 불필요한 엔티티타입은 없는가?

주요 오류 유형 사례

(1) 단위 시스템간에 중복된 엔티티타입 발생

(2) 업무적으로상호 M:N의 관계를 가지는 엔티티타입간의 관계에 의한 추가 엔티티타입필요

• (문제) 제품과 공급자 엔티티타입간의 관계가 M:N으로 연결되어 있으므로 관계 엔티티타입이 필요
• (해결) 제품과 공급자 엔티티타입의 PK를 복합 PK로 구성한 공급자제품이라는 관계 엔티티타입이 생성해준다.

(3) 1차, 2차, 3차 정규화가 미흡하여 추가적인 엔티티타입이 도출되지 않음

• 예1) 1차정규화 응용

• (문제) 왼쪽 모델의 일재로에는 3개월분에 대한 장기재고수량, 주문수량, 금액, 주문금액이 차례대로 기술되어있다.
• 이렇게 되면 장기재고 관릴가 4개월 이상 으로 늘어날 때 모델을 변경해야 하는 치명적 결함.
• (해결) 오른쪽과 같이 1차 정규화를 통해 모델을 분리함으로써 업무 변형에 따른 데이터 모델의 확장성을 확보하도록 해야 한다.
• 예2) 2차 정규화 응용
• 여러 개의 속성이 주실별자로 구성되어 있을때 일반 속성 중에서 일부 주식별자에만 종속적인 속성이 있을경우 2차 정규화를 적용하여 엔티티타입을 분리하도록한다.

• (문제) 실전 프로젝트에서는 코드 유형의 엔티티타입들이 2차 정규화가 되지 않고, 하나의 엔티티타입으로 표현되는 경우가 많다.
• (해결) 고객번호에 종속적이지 않은 속성들을 분리하여 고객점포라는 새로운 엔티티타입을 생성한다
• 예3) 3차 정규화 응용
• 결정자 역할을 하는 일반 속성이 있고, 결정자 역할 속성에 의존하는 의존자가 존재하는 엔티티타입은 3차 정규화 대상

• (문제) 등록카드번호가 결정자 역항를 하고 , 등록카드사면과 등록카드유효일자가 의존자 역할을 하는, 속성간의 종속성이 발견되었다.
• (해결) 등록카드에 대한 내용에 대해 별도의 엔티티타입을 도출한 오른쪽 모델로 만듦으로써 3차 정규화를 완성시킴.

엔티티타입이 주변 여러 엔티티타입의 공통 엔티티타입인 경우 자료 원천이 어느 엔티티타입인지 추적할 수 있는가?

주로 공통 엔티티타입과 주변 엔티티타입과의 관계가 수퍼타입/서브타입 관계일 때 주로 발생하는 3가지

• 1. 하나의 부모 엔티티타입이 여러 개의 배타적 자식 엔티티타입과 곤계를 가진경우
• 2. 하나의 자식 엔티티타입이 여러 개의 배타적 부모 엔티티타입과 관계를 가지는경우
• 3. 상호 관계가 1:1인 공통 엔티티타입과 주변 엔티티타입과의 관계를 가진경우

주요 오류 유형 사례

(1) 슈퍼타입/서브타입 모델에서 자료 원천 구분 표시가 없는경우

• (문제) 문서 공통 수퍼 엔티티타입에 서브 엔티티타입을 구분할 수 있는 구분자가 없는 것이 문제.
• (해결) 문서 공통 엔티티타입에 문서 구분을 속성으로 지정함으로써 경비요청서, 근무명령서, 입고증 서브 엔티티타입을 효과적으로 찾아갈 수 있게 된다.

PK의 순서는 시스템의 성능을 고려하여 적절한 순서로 정의되어 있는가?

PK조합 우선순위는 대체로 다음 규칙에 따라 결정

• 1. 모든 SQL에서 항상 사용되는 속성은 우선순위를 제일 높게 해야한다.
• ==> SQL의 WHERE에 첫번째 속성이 표현되어 있지 않다면 그 인덱스는 사용되지 않기 때문이다.
• 2. 분포도가 좋은 속성은 PK 선정에서 우선순위가 높다.
• 3. '='조회를 하는 컬럼은 PK 조합 시 우선순위가 높다.

주요 오류 유형 사례

(1) 잘 사용되지 않는 속성이 PK의 첫 번째 항목으로 선정되는 경우

• (문제) 검색 유형을 검토한 결과 날짜를 통한 급여 현황을 조회할 경웅는 항상 사원정보를 읽는다고 하면,
• 결국 사원번호는 항상 조회 항목으로 사용된다.
• (해결) 급여 엔티티타입의 사원번호를 PK의 첫 번째 항목으로 하는것이 유리하다.
• 검색 유형에 따라 PK 순서를 조정함으로써 실제 SQL실행 시 성능 저하를 예방할수 있다.

(2) 구분 표시와 같은 속성이 PK의 첫 번째 항목으로 선정되는 경우

• (문제) PK에따른 조회 유형에는 사원번호에의한경우, 사원번호+사원구분에 의한 경우, 사원구분에 의한 경우
• 이때 사원번호에 의한 경우에는 사원 구분이 PK의 첫 번째 속성으로 있을 때 PK 인덱스를 사용할수 없다.
• (해결) 사원번호+사원구분의 경우는 PK의 순서에 상관없이 적절하게 인덱스를 사용한다
• 사원구분은 분포도가 매우 낮은 속성이므로 플 스캔하는것이 빠르다.

(3) 날짜와 같이 주로 범위를 조회하는 속성이 PK의 첫 번째 항목으로 선정되는 경우

• (문제) 인사시스템의 발령 정보를 읽는 SQL이 있다고 가정하자. 어떤 사원이 어떤 발령내역을 가지고 있는지 조회하는 경우가 많을것이다.
• (해결) '=' 비교를 할 수 있는 어떤 사원에 해당하는 사원번호는 PK의 맨 앞에 위치해야 한다.