2.속성 검토

반정규화된 속성은 식별되는가?

• 속성의 명명은 정규화 시점을 기준으로 이루어진다.
• 정규화가 완성되면 모든 속성은 전체 ERD에 걸처 하나만 존재하게 되며, 이 시점을 기준으로 속성이 명명된다.

주요 오류 유형 사례

(1) 반정규화된 속성에 실제로는 의미가 다르고, 이름만 같은 속성이 공존함

• (문제) 매출 정보의 전화번호는 반정규화된 속성인데, 고객엔티티타입과 사원 엔티티타입 중 어느 엔티티타입으로부터 반정규화된 속성인지 식별되지 않는다.
• (해결) 개선 모델 에서는 고객전화번호 속성과 사원전화번호 속성의 이름을 다르게 한후 매출정보 엔티티타입에서 고객전화번호를 반정규화했다.
• 반정규화된 속성-의미가 다른 속성이나 이름만 같은 속성 공존

2. 반정규화는 시스템 복잡도와 성능을 고려하여 적절하게 이루어졌는가?

• ERD에서 반정규화를 하는 이유는 검색 시 데이터베이스의 성능을 빠르게 하기 위함.

단점.

• 1.자료를 수정할 때 관련 엔티티타입에 존재하는 반정규화된 속성도 함계 변경해 주어야 하므로 자료 수정 시 부하가 발생한다.
• 2.반정규화된 속성을 병행 수정하는 프로세스가 빠졌다든지 운영자에 의해 자료가 직접 변경되는 경우가 생기면 자료의 무결성이 깨질 수 있다.

주요 오류 유형 사례

(1) 시스템 특성에 따르지 않은 과도한 반정규화

• (문제) 이러한 모델은 만일 사원명 또는 직위가 변경되면 문제가 생김
• (해결) 인사 엔티티ㅣ타입과 최초로 자식 관계를 가지는 급여이력 엔티티타입에만 반정규화를 실시하고, 그이하 엔티티타입에 대해서는 반정규화를 실시하지 않았다.

(2) 반정규화를 하지 않아 발생하는 시스템 성능 저하

• (문제) Index: 행정동 , 2만건이 넘는다면 이하들도 2만번씩 읽는다.
• (해결) 행정동이 반정규화 했다. 특정 계열사의 행정동별 우수 고객을 검색하려고 할 때 개선 모델에서는 계열사별 고객 엔티티타입의 행정동 인덱스를 읽은후(1차검색) 계열사별 고객 테이블의 데이터에 접근(2차 검색)하게된다.
• 그러면 만 번의 접근은 2차 검색 시에서만 이루어지며, 그 속도는 수 십초 이상 걸리지 않다.

명칭이 같은 속성의 타입과 크기는 동일한가?

동일 명칭을 가지는 속성이 다른 타입과 크기를 가질 때 다음과 같은 문제가 발생

• 1. 자료의 무결성이 깨진수 있다.
• 2. 명칭이 동일한 속성간에는 SQL조인 시 연결 고리가 될 가능성이 많은데, 타입이 달라서 컬럼 변형이 일어나 인덱스 검색을 하지 못해 성능이 저하될수있다.
• 다음표는 타입과 크기의 불일치 여부

주요 오류 유형 사례

(1) 크기의 불일치

• 인사 시스템에서 사원정보의 사원명은 10바이트이고, 급여이력의 사원명은 8바이트라고 하자.
• 이때 '김 미리네'라는 사원은 9바이트를 가진다.
• 따라서 사원정보에서 사원명을 읽어 급여이력이 복사하는 SQL(Insert, Update)을 처리할 때 정보가 손실된다.

(2) 타입의 불일치

• (문제) SQL에서 근태이력의 급여지금일에 컬럼 변형이 일어남으로써 근태이력의 '사원번호+급여지급일' 인덱스가 사용되지 못하게된다.
• (해결) ?애이력과 급여이력의 컬럼 형식과 길이는 동일하게 지정해야한다.

내부적인 속성을 갖고 있는 속성은 없는가?

내부적인 속성을 갖는 속성은 두가지로 분리

• 1. 속성 별견 초기부터 내부적인 속성을 가지는 경우로, 성명(성+이름), 주민등록번호(생년월일+일련번호), 전화번호(지역번호+국번호+일련번호)가 있다.
• 2. 해당 시스템의 필요에 따라 여러 속성을 병합하여 만들어지는 속성으로, 대표적인 예가 문서번호
• (예: 문서발생부서+문서유형+날짜+일련번호)

주요 오류 유형 사례

(1) 병합된 속성만 관리

• (문제) 전표번호(발행부서+전표유형+날짜+일련번호)를 분리하여 그 항목을 PK로 관리하게 된다면, 그 이하의 자식 및 손자 엔티티타입의 PK는 매우 길어지게 된다.
• (해결) 여러 속성이 병합된 전표번호를 PK로 사용하는 것은 유용하다

병합되어야 할 속성은 없는가?

주요 오류 유형 사례

(1) 날짜와 같이 대부분 범위 조회가 일어나는 속성

• (문제) 인덱스 컬럼의 변형이 일어나 인덱스가 적절하게 사용되지 않아서 애플리케이션의 성능을 저하시키는 요인이된다.
• (해결) 발령일자로 병합하면 SQL에 적절한 인덱스 사용이 이루어진다.

전후 레코드간 영향을 미칠 수 있는 속성은 없는가?

주요 오류 유형 사례

(1) 중간 데이터가 변경할 수 있는 이력 엔티티타입에서 현재 데이터까지의 누적 정보를 관리하는 속성

• (문제) 공사이력 엔티티타입 안에 공사비 누적계라는 속성이 있다면, 특정 공사에 대해 매번 공사 실적이 발생할 때마다 현재 레코드의 공사비 누적계 속성에 이전 레코드까지의 합이 들어갈 것이다.
• (해결) 공사마스터와 공사이력을 분리하여 공사비 누적계라는 속성을 공사마스터 엔티티타입에서 관리한다면 공사이력의 공사비가 변경 또는 추가될 때 공사비 마스터만 변경해주면 성능 저하 없이 데이터를 관리할수 있다.

감사, 통계 등을 고려하여 속성이 정의 되었는가?

주요 오류 유형 사례

(1) 코드화할 수 있으나 텍스트로 정의된 속성

• (문제) 이 표에서 보는 것처럼 동일한 자격증에 대해 자격증명이 사용자의 입력 방법에 따라 다르게 입력될수 있으며, 자격증 이름이 'ORACLE ADMIN'인 사원을 집계한다면 사원번호가 '11111'인 사원만 집계되서 그 값은 '1'로 나올 것이다.
• 실제로는 ORACLE ADMIN 자격증 소지자는 모두 4명이다.
• (해결) 특정값에 대해 정확한 통계치가 필요하다면 속성값에 대한 코드화 작업이 필요한지 검토해야한다.
• 마지막 다음표와 같이 자격증코드가 '01' 인것을 SELECT 하므로 총건수는 4건이 나올수있다.