Powerful PowerDesigner

정규화(Normalization)

정규화는 논리적 데이터 모델을 일관성이 있고 중복을 제거하여 보다 안정성을 갖는 바람직한 자 료구조로 만들기 위해 여러 단계를 거친다. 그 단계는 제 1차 정규형에서부터 제 5차 정규형과 BCNF(Boyce-Codd Normal Form)까지로 구성되어 있다. 대체로 적절하고 일관성을 유지하면서 중복이 없는 논리적 데이터 모델을 구축하는 데에는 흔히 3차 정규형이 사용된다.

정규화의 의미

잘 만들어진 데이터 모델이라고 해도 엔터티에 데이터를 삽입, 수정, 삭제할 때 오류가 발생할 개연성을 가지고 있다. 이러한 것들을 통칭해서 변경 이상(Modification Anomaly)이라고 한다. 여기에는 구체적으로 삽입 이상(Insertion Anomaly), 수정 이상(Update Anomaly), 삭제 이상 (Deletion Anomaly) 등이 있다.

변경 이상이 발생하는 엔터티를 그대로 운용하게 되면 데이터가 신뢰할 수 없는 값들로 채워질 가 능성이 있다. 즉, 데이터의 일관성, 무결성을 해칠 가능성이 있는 것이다.

정규화 과정을 통해서 변경 이상의 엔터티를 정규화된 엔터티로 변환하게 된다.

1) 입력 이상

별도의 사실이 발생하기 전까지 원하는 데이터를 삽입할 수 없음. 어떤 데이터를 삽입하려고 할 때 불필요하게 원하지 않는 데이터도 함께 삽입되게 된다.

2) 삭제 이상

일부 정보를 삭제함으로써 유지되어야 할 정보까지도 삭제되는 연대 삭제가 발생한다. 제3장 논리 데이터 모델링

3)갱신 이상

일부 속성 값을 갱신 함으로써 원하지 않는 정보의 이상 현상(무결성 파괴, 정보의 모순성)이 발생 한다.

정규화의 장점

1) 중복값이 줄어든다

궁극적으로 칼럼 간, 레코드 간, 테이블 간에 중복되는 데이터들을 최소화할 수 있다. 이것이 정규 화의 최대 성과라고 할 수 있다. 사실은 모든 장점이 이것에서 시작된다.

2) NULL 값이 줄어든다

전체적으로 NULL 값의 사용이 줄어들게 된다.

3) 복잡한 코드로 데이터 모델을 보완할 필요가 없다

데이터에 중복된 값이 적고, 그 부모가 누구인지가 항상 명시되어 있는 상황에서 데이터의 무결성을 지키기 위한 복잡한 코드를 사용할 필요가 없어진다. 데이터베이스 코드를 작성하는데 복잡한 변환 과정과 조인 질의, NULL 값 처리들이 필요하다는 것은 그 데이터베이스 설계가 문제가 있다는 말이 기도 하다.

4) 새로운 요구 사항의 발견 과정을 돕는다

실제 정규화 과정에서 많은 엔터티 혹은 속성들이 태어나게 된다. 또한 많은 결정 과정에서 업무 담 당자와의 협의를 통해서 현재뿐만 아니라 미래까지도 고려한 요구 사항의 발견 과정이기도 하다.

5) 업무 규칙의 정밀한 포착을 보증한다

정규화 과정을 통하여 많은 복잡한 업무 규칙들이 체계화되고, 규칙의 Value화에도 도움을 주게 된다.

6) 데이터 구조의 안정성을 최대화한다

중복된 값이 최소화되고 모든 정보들이 자기가 있어야 할 자리에 존재하게 되기 때문에 향후 발생 하게 될 모델 변화에도 유연하게 대처할 수 있다.

정규화 단계

1) 1차 정규형 (1NF, First Normal Form)

가) 정의

·         모든 속성은 반드시 하나의 값을 가져야 한다. 즉, 반복 형태가 있?일한 이름을 가져야 한다.

·         레코드들은 서로 간에 식별 가능해야 한다.

나) 정규화 작업

[그림 1] 에서와 같이 고객 엔터티의 계약일 속성의 값이 여러 건이 된다면 1차 정규형을 위배하는 것이 된다.

·         어떤 속성이 다수의 값을 가지고 있다면 M:1 관계의 새로 엔터티를 추가한다.

·         관계형 모델에서는 관계(Relation) 정의상 한 속성이 하나의 값만을 가져야 한다. 그러므로 비정규형 관계는 엄밀히 말하면 관계로 간주할 수 없다.

·         비정규형 관계가 관계로서의 모습을 갖추기 위해선 여러 개의 복합적인 의미를 가지고 있는 속 성이 분해되어 하나의 의미만을 표현하는 속성들로 분해되어야 한다. 즉 속성수가 늘어나야 한 다.

·         비정규형 관계가 관계로서의 모습을 갖추기 위해선 하나의 속성이 하나의 값을 가질수 있어야 하며, 이 조건을 만족시키기 위해선 튜플이 늘어나야 한다. 또는 다른 관계로 분리되어야 한다.

·         분석 또는 모델링 진행 과정에서 발생하며, 최종적인 모델링 완성 단계에서는 나올 수 없다. 그 러나 분석(모델링) 초기 단계에는 상세히 분해된 속성보다는 위와 같은 레벨의 속성 추출이 복잡 도를 줄일 수 있으므로 실전에서는 효율적이고 유리하게 이용될 수도 있다.

2) 2차 정규형 (2NF, Second Normal Form)

가) 정의

·         식별자가 아닌 모든 속성들은 식별자 전체 속성에 완전 종속되어야 한다.

·         이것을 물리 데이터 모델의 테이블로 말하면 기본키가 아닌 모든 칼럼들이 기본키에 종속적이어 야 2차 정규형을 만족할 수 있다는 것이다.

나) 정규화 작업

·         [그림 2]에서와 같이 식별자가 학번 + 코스코드로 이루어진 학과등록 엔터티에서 학번속 성에 평가코드, 평가내역 속성들이 종속적이다. 그렇기 때문에 이것은 2차 정규형을 위반하고 있는 것이다.

·         [그림 2]에서와 같이 식별자가 학번 + 코스코드로 이루어진 학과등록 엔터티에서 코스코 드 속성에 코스명, 기간 속성들이 종속적이다. 그렇기 때문에 이 또한 2차 정규형을 위반하고 있 는 것이다.

·         의미상의 주어 즉, 본질식별자를 알아야 식별자 부분 종속인지를 구분할 수 있다. 제3장 논리 데이터 모델링

·         속성의 의미가 명확해야 종속성을 비교할 수 있다.

·         어떤 속성 식별자 전체에 종속되어 있지 않으면 잘못된 위치이며 새로운 엔터티 즉, 상위 부모 엔터티를 생성하고 UID BAR를 상속받게 된다.

3) 3차 정규형(3NF, Third Normal Form)

가) 정의

2차 정규형을 만족하고 식별자를 제외한 나머지 속성들 간의 종속이 존재하면 안된다. 이것이 3차 정규형을 만족하는 것이다.

나) 정규화 작업

·         [그림 3]에서 학과등록 엔터티에서 평가코드, 평가내역 속성들이 서로 간에 종속적이다. 즉, 평가내역 속성은 평가코드 속성에 종속적이다. 그렇기 때문에 이것은 3차 정규형을 위반하 고 있는 것이다.

·         3차 정규형을 위반하고 있을 시에는 [그림 5-3-11]에서의 평가항목 엔터티처럼 부모 엔터티가 생성되고 그 부모 엔터티로부터 UID Bar가 없는 관계를 상속받게 된다.

4) BCNF 정규형

가) 정의

·         모든 결정자가 키인 릴레이션이 BCNF이다. 반대로 어떠한 결정자 하나라도 키가 아닌 릴레이 션이라면 BCNF가 될 수 없다.

·         기존의 2차 정규형과 3차 정규형을 보완하려는 목적으로 만들어졌다. 즉 부분 종속이나 이행 종 속이 없는 3차 정규형도 변경 이상 현상이 나타날 수 있기 때문이고, 이것은 어떤 Non-Key 속 성이 결정자로 동작하기 때문에 발생한다.

나) 3차 정규형의 문제점

·         한 릴레이션에 여러 개의 후보키(Candidate Key)가 있으며,

·         모든 후보키들이 적어도 둘 이상의 속성으로 이루어지는 복합(Composite) 키이며,

·         모든 후보키들이 적어도 하나 이상의 공통 속성이 포함되는 경우이다.

다) 3차 정규형을 만족하고 BCNF가 아닌 경우

·         각 속성이 단 하나의 값으로 구성된 경우(1차 정규형)

·         Non-Key 속성인 D는 후보키(Candidate Key)인 A+B 또는 B + C 에 완전 함수 종속이므로 2차 정규형에 속한다.

·         또한 Non-Key 속성이 D 하나 뿐이므로 Non-Key 속성 간의 종속 관계가 존재하지 않으므로 제 3차 정규형을 만족한다.

식별자(UID, Unique Identifier) 확정

엔터티 내의 모든 인스턴스는 유일하게 구분되어야 한다. 이러한 유일성을 보장하기 위해서 필요한 것이 식별자이다. 식별자에는 크게 본질 식별자(Primary UID 또는 Intrinsic UID), 주(실질) 식별자(Actual UID), 대체(보조) 식별자(Secondary UID)로 구분할 수 있다. 대체 식별자는 방법론에 따라서 AK 혹은 Alternate Key로 부르기도 하지만 현재 단계에서는 Key 보다 식별자가 더 적절한 표현이다.

본질 식별자

엔터티에는 인조 식별자(Artificial Unique Identifier)가 있고, 진주어(眞主語)에 해당하는 관계나 속성이 어딘가에 있다. 개념 데이터 모델링 과정에서 키 엔터티와 일부 핵심 엔터티에 대해서 본질 식별자를 정의하였다. 여기에서는 엔터티 상세화 단계에서 정의되어질 핵심,액션(행위) 엔터티에 대한 본질 식별자를 정의한다.

본질 식별자를 정의하는 방법은 키 엔터티와 행위 엔터티가 서로 다르다. 행위 엔터티를 정의하는 방법에는 상황에 따라 하향식과 상향식으로 접근하는 방식을 적용할 수 있다. 키 엔터티는 부모가 없이 창조된 집합이므로 식별자 또한 창조시켜 주어야 한다. 그러나 행위 엔터티는 항상 부모가 누구인지를 확인하는 방식으로 진행된다.

1) 키 엔터티의 본질 식별자

키 엔터티는 우리가 잘 알고 있듯이 사원, 고객, 상품과 같이 부모 엔터티 없이도 혼자서 정의될 수 있는 엔터티이다. 예를 들면 사원 엔터티에는 이미 이전부터 정의해서 사용하고 있던 사원번호가 있 다는 것은 굳이 언급할 필요도 없다. 그러나 좀더 깊이 생각해 본다면 사원 집합의 개체는 사람이므 로 사실 본질 식별자는 주민등록번호라고 볼 수 있다. 물론 외국인 사원이 있다면 여권번호, 외국인 등록번호 등이나 임시로 부여한 임의의 값을 광의의 주민등록번호로 정의한다면 이것을 개념적으로 는 원래의 본질 식별자로 볼 수 있다. 뒤에서 확정 식별자를 설명할 때 전략적인 부여 방법에 대해 자 세하게 언급하겠지만 이 주민등록번호는 몇 가지 전략적인 이유 때문에 사원번호라는 인조 식별자에게 대표 권한을 물려준 것이다.

2) 절대 종속 / 상대 종속 의미

절대 종속과 상대 종속은 나를 태어나게 하는데 절대적인 영향을 주었는지, 그렇지 않는지를 따지 는 것이다. 다시 말해서 내가 태어나기 위해서 절대적으로 존재했어야 하는지, 아니면 그것이 없어도 내가 태어날 수가 있는지를 확인하는 것이다. 절대 종속을 확인하는 방법은 매우 간단하다. 영화 백 투더 퓨쳐(Back To the Future)처럼 과거로 돌아가서 누구를 없앴더니 내가 태어나지 않게 된다면 그는 나를 태어나게 하기 위해 절대적으로 필요한 존재이다. 반면에 누군가가 우리 집안과 분명히 어 떤 관계를 맺고 살았지만 설혹 그가 없다고 하더라도 내 탄생에는 아무런 영향을 미치지 않는다면 그는 나의 탄생에 대해서는 상대 종속이 된다.

3) 직접 종속 / 간접 종속 의미

‘1촌이냐? 1촌 이상이냐?’를 구분한다. 즉, 부모 엔터티와의 관계가 1촌이면 직접 종속이고 1촌 이상이면 간접 종속이라고 볼 수 있다.

4) 행위 엔터티의 본질 식별자

행위 엔터티의 본질 식별자란 이와 같이 절대종속이면서도 직접종속인 것을 찾고자 하는 것이며, 결국은 자신을 태어나게 한 근본을 찾는 것이다.

본질 식별자를 찾는 가장 확실한 방법은 사건의 전모를 가장 체계적으로 표현할 수 있다는 기사 작 성의 여섯 가지 원칙인 육하원칙(六何原則)을 이용하는 것이다. ‘누가, 무엇을, 언제, 어디서, 어떻 게, 왜’라는 이 여섯 가지의 질문을 통해 발생된 행위를 구체적으로 규명하면 상황에 대한 정확한 사 실을 규명할 수 있다.

후보 식별자 도출

이전 단계에서 정의된 본질 식별자를 기본으로 식별자의 기본 목적인 자기를 식별할 수 있어야 한 다는 유일성 유지의 목적과 다른 엔터티에서 정보로 참조해야 하는 목적을 적절히 판단하여 최종 식 별자를 확정해야 한다. 하나의 엔터티 내에는 식별자로 사용할 수 있는 하나 이상의 식별자가 있다. 이 중에서 하나가 식별자로 선택되게 된다. 나머지 식별자들을 후보 식별자(Candidate UID, 방법 론에 따라서는 CK 혹은 Candidate Key라고도 하지만 현재 단계에서 Key 라는 표현보다는 식별자 라는 표현이 더 적절하다)라고 한다. 이러한 후보 식별자들은 다음과 같은 조건을 만족해야 한다.

1) 각 인스턴스를 유일하게 식별할 수 있어야 한다

가장 기본적인 전제 조건이며, 후보 키들은 유일한 값을 가지고 이를 통해 나머지 인스턴스와 자신 을 식별하는 능력을 가져야 한다. 후보 식별자는 단일 속성뿐만 아니라 하나 이상의 속성이 모인 집 합으로서도 후보 식별자가 될 수 있다. 그러므로 속성 혹은 여러 속성들이 조합된 속성 집합은 전체 인스터스에서 유일 값을 가져야 한다. 그래야만 특정한 인스턴스를 선택하기 위해서 전체 인스턴스에서 유일한 값을 가지는 후보 식별자를 선택할 수 있다.

2) 나머지 속성들을 직접 식별할 수 있어야 한다

인스턴스 간에서 뿐만이 아니라 후보 식별자는 나머지 속성을 식별할 수 있는 능력을 가지고 있어 야만 한다. 이는 후보 식별자가 유일 값을 가지고 있는 상황에서 특정 인스턴스를 추출하기 위해서 유일 값을 가진 후보 식별자를 찾아내면, 후보 식별자에 관련된 나머지 속성을 다시 찾아낼 수 있다 는 의미이다.

3) NULL이 될 수 없다

후보 식별자들은 NULL이 될 수 없다. NULL이란 해당 속성에 값이 지정되지 않았다는 적극적인 표시라고 볼 수 있다. 따라서 NULL이 허용되는 속성이 있다면 값을 넣지 않은 경우에는 NULL이 할당된다. NULL이 할당되었다는 것은 값이 없다는 것이므로 NULL이 있는 속성은 식별할 수가 없다.

4) 후보 식별자로 속성 집합을 선택하는 경우에는 개념적으로 유일해야 한다

집합으로 후보 식별자를 선택하는 경우에는 개념적으로도 유일할 것이라는 판단을 하고서 후보 식 별자로 선정해야만 한다. 만일, 회원 테이블에 대한 견본 데이터를 보고서 부서+성명 집합이 유일한 값을 가진다고 판단했다고 하더라도 개념적으로 부서에 동일한 이름을 가지는 사원이 없다고 확신할 수 있겠는가? 하지만 만일에 부서를 관리하는 엔터티에서 부서명+팀명을 후보 식별자로 선택하는 것은 개념적으로 유일할 수 있다. 한 부서에 동일한 이름을 가지는 팀은 없기 때문이다.

5) 후보 식별자의 데이터는 자주 변경되지 않는 것이어야 한다

데이터가 자주 변경된다고 해서 후보 식별자가 될 수 없는 것은 아니지만 일반적으로 후보 식별자 의 값은 자주 변경되지 않는다. 데이터? 인덱스를 통 해서 구현되게 된다. 인덱스는 포인터들을 관리하게 된다. 어떤 노드의 데이터가 변경되면 트리 구조를 재수정하는 데에 너무나 많은 시간이 필요하게 되 어 데이터베이스의 성능을 떨어뜨리게 되므로, 인덱스에 선택되는 칼럼의 데이터가 자주 변경되는 것은 좋지 않다.

대체(보조) 식별자

보조 식별자란 원래의 식별자를 대신할 수 있는 또 다른 속성들이나 릴레이션십을 말한다. 가령 사 원 엔터티에 공식적으로 부여된 식별자는 사원번호이지만, 만약 주민등록번호 속성이 유일한 값을 가지면서 필수적(Mandatory)으로 정의되었다면 비록 공식적인 식별자는 아니지만 식별자로서의 역할을 할 자격은 충분히 갖추고 있다. 특히 보조 식별자는 여러 참조 엔터티 중에서 원래의 식별자 보다 보조 식별자로 연결을 맺는 것이 자신에게는 훨씬 유리한 경우에 의미가 있게 된다.

인조 식별자 지정

인조 식별자란 식별자 확정시 기존의 본질 식별자를 그대로 실질 식별자로 인정할 수 없는 여러 가 지 상황이 발생했을 때, 전부 혹은 일부를 임의의 값을 가진 속성들로 대체하여 새롭게 구성한 식별 자를 말한다. 가령, 사원 엔터티에 이미 존재하고 있는 속성 중에서 원래의 본질 식별자를 찾으라고 한다면 주민등록번호가 될 것이다. 그러나 이 속성은 너무 길고 관리상 여러 가지 문제점이 발생하기때문에 새롭게 사원번호라는 임의의 값을 가진 인조 속성을 영입하여 공식적인 식별자 자리까지 부 여받은 것이다. 인조 식별자는 다음과 같은 기준을 가지고 지정하는 것이 바람직하다.

1) 최대한 범용적인 값을 사용한다

인조 식별자의 속성은 남들이 알지 못하는 임의의 값일 수 있기 때문에 특별한 결격 사유가 없다면 가능한 한 기존에 범용적으로 사용하던 것을 그대로 사용하는 것이 좋다. 예를 들어, 이미 회사 내에 공인되어 사용하고 있는 사원번호, 상품코드, 국가나 공공 기관에서 부여한 은행코드, 국제적으로 사 용하고 있는 무역상품 분류체계인 HS코드, 범용적으로 사용하고 있는 국가나 통화(通貨)코드 등은 가능하다면 그대로 사용하는 것이 여러 가지로 유리한 점이 많다.

2)유일한 값을 만들기 위한 인조 식별자를 사용한다

지금까지 정의해 왔던 본질 식별자를 그대로 사용하면 심각한 문제가 발생하는 경우가 몇 가지 있 다. 여기에서는 그 중에서 한 가지인 유일값에 대한 확신이 없을 때 이를 해결하기 위해 인조 속성을 영입하는 경우에 대해 설명하고자 한다. 어떤 경우에는 본질 식별자는 논리적으로야 문제가 없지만 실제적으로는 유일성에 대한 현실적인 문제가 발생하므로 인조 속성의 도입을 검토해야만 한다. 물 론 그 인조 속성을 아예 전체 본질 식별자를 대체하도록 하든, 그 중의 일부를 대체하게 하든 종합적 인 판단에 따라 달라지겠지만 인조 속성이 필요하다는 것은 분명하다. 사실 실전에서 인조 속성을 도 입하는 상당 부분은 바로 이런 경우라고 할 수 있다.

3)하나의 인조 식별자 속성으로 대체할 수 없는 형태를 주의한다

인조 속성을 만들 때 이 속성이 구체적으로 본질 식별자의 어느 부분을 대체하고 있는지를 분명하 게 정의해야 한다. 그러나 하나의 인조 식별자 속성에 같이 대체될 수 있는 것과 절대로 그렇게 해서 는 안 되는 경우가 있다는 것에 유의해야 한다. 만약 이런 원칙을 어긴다면 나중에 집합 내의 개체의 정의가 모호해져 엔터티 전체를 애매한 집합으로 변질시키게 되므로 주의해야 한다.

4)편의성 ·단순성 확보를 위한 인조 식별자를 사용할 수 있다

속성의 길이가 너무 길거나 기억하기가 어려워서 좀더 쉽고 간편한 이름으로 변경할 목적으로도 인조 속성을 추가시킬 수도 있다. 마치 사람의 이름을 간편하고 부르기 쉽도록 애칭이나 별명을 만드 는 것과 유사한 목적이라 할 수 있다. 성을 포함해서 대부분 세 글자에 지나지 않는 우리나라 사람들 에게는 그리 흔치 않는 일이지만 훨씬 긴 이름을 가진 외국 사람들에게 흔하게 사용된다. 이처럼 본 질 식별자를 그대로 사용해도 불편이 없다면 굳이 인조 속성을 만들 필요가 없겠지만 그렇지 않다면 고려해 볼 만한 충분한 가치가 있다.

5)의미의 체계화를 위한 인조 식별자를 사용할 수 있다

의미를 체계화한다는 말을 다른 말로 쉽게 표현하면 코드화를 한다는 것과 유사하다. 과거에는 전산 은 곧 코드라는 말이 있을 정도로 모든 것을 코드화하려고 애를 썼다. 코드화한다는 말에는 곧 속성 의 자릿수마다 나름의 의미를 부여하겠다는 의미를 포함한다. 논리적으로 임의의 값이란 말에는 이미 정해진 값의 형태가 포함되어 있다. 인조 속성이란 임의의 값을 정의하는 것이라고 했다. 그렇다고 해서 그야말로 아무 값이나 괜찮다는 것은 아니다. 특별한 의미를 부여할 필요가 없다면 순차적인 번호, 곧 일련번호를 정의하는 것으로도 충분하겠지만 특정한 의미를 부여함으로써 변별력이 향상된 다거나 처리의 규칙이 생겨난다면 너무 지나치지 않는 한 그것을 무조건 나쁘다고만 할 수는 없다.

6)내부적으로만 사용하는 인조 식별자

인조 식별자를 생성하는 또 한 가지의 경우는 현업 사용자들에게는 전혀 알려주지 않으면서 시스템 내부적으로만 사용하는 형태이다. 물론 데이터 모델링 입장에서 본다면 현업 사용자뿐만 아니라 시 스템 개발이나 관리를 하는 사용자 또한 엄연한 사용자임에 틀림이 없다. 여기서 설명하고자 하는 것 은 새롭게 정의한 인조 식별자가 비록 업무적으로는 아무런 의미도 없지만 시스템적인 필요성에 의 해서 도입하는 경우를 소개하려는 것이다.

식별자 확정

식별자는 자기 엔터티를 위해 생성하는 것처럼 보인다. 하지만 보다 중요한 결정 요소는 나를 참조 할 다른 엔터티가 원하는 형태로 결정되어야 하는 것이기 때문에 주변 엔터티의 상황을 종합적으로 살피고, 주변 엔터티의 상황도 최대한 수렴할 수 있도록 하는 것이 매우 중요하다. 그래서 식별자를 확정할 때는 자기 자신에 대한 존재 가치뿐만 아니라 남들에 대한 배려를 어떻게 조화시키느냐가 중 요한 관건이다.

1) UID BAR의 두 가지 의미

UID BAR가 가지고 있는 본질을 자세히 살펴보면 크게 두 가지의 의미를 가지고 있다.

가) 식별자로서의 역할

엔터티 자신의 입장에서 보았을 때 자신의 개체들을 다른 것들과 구별될 수 있도록 유일한 값을 만드는데 일조를 한다는 의미이다.

나) 정보로서의 역할

참조하는 엔터티의 입장에서 보았을 때 상대방의 식별자를 상속 받았기 때문에 자신이 보유한 정보가 증가했다는 의미도 가지고 있다.

조상의 식별자를 내가 상속 받고, 다시 그것을 내 자손들에게 물려준다면 자손들은 굳이 나를 경유 하지 않고서도 조상이 누구인지 알 수 있는 것과 유사하다. 인조 식별자를 설명하면서 언급했듯이 단 지 유일한 값을 만들기 위한 목적 뿐이었다면 굳이 부모에게 받은 식별자를 자신의 식별자에 넣지 않 고서도 얼마든지 유일한 값을 만드는 것이 가능하다. 이 말에는 부모의 식별자를 내 이름에 넣는 것 에 상관없이 내가 태어난 이상 부모는 존재한다는 의미가 내포되어 있다. 비록 부모가 분명하더라도 부모의 식별자가 나의 식별자를 만들기 위해서 반드시 필요한 것은 아니라는 것이다. 그러나 내 식별 자에 부모의 식별자를 포함시키지 않자?이란 단지 자기 식별자의 형태를 결정한다는 단순한 의미로만 생각해서는 안 된없이 복잡해지더라도 식별자 상속이 전략적으로 이루어진 다면 나중에 데이터를 처리할 때의 실제 액세스 단계에서는 훨씬 간편하게 만들 수 있다. 즉, UID의 적절한 상속과 단절 전략은 실질적인 처리의 단순화를 가져다 줄 수 있으므로 그 전략적 가치를 가지 고 있다.

[그림 2]에서 보면 A_엔터티와 B_엔터티 사이의 릴레이션에 UID BAR가 있다는 것은 C_ 엔터티와 B_엔터티 사이의 릴레이션에 UID BAR의 존재 여부와 상관 없이 무조건 조부모인 A_ 엔터티의 식별자 A를 상속 받게 된다는 것을 의미한다. 이는 곧 C_엔터티에는 A가 있으므로 이 미 아버지인 B_엔터티를 경유하지 않고서도 직접 A_엔터티와 연결될 수 있음을 의미한다. 이 릴 레이션십에 의해 부모나 그 이상의 조상에게 있던 식별자 속성이 설계 단계에서 나에게 상속된 다는 의미일 뿐이지 참조하는 경로가 그렇게 되어야 함을 뜻하는 것은 결코 아니다. 이렇게 평범 하고 당연해 보이는 사실이 갖는 진정한 가치는 우리가 상속 여부를 결정할 때 매우 중요한 판단 의 기준이 된다.

3)식별자 확정 절차

하향식(Top-down) 방식, 즉 상위 엔터티부터 시작해서 하위 엔터티로 순차적으로 결정해 가는 것이 좋다. 식별자 상속이란 상위에서 하위로 이루어지기 때문이다.

가) 키 엔터티 식별자 확정

부모를 가지지 않는 최상위 엔터티이므로 서로 독립적으로 식별자를 확정할 수 있다. 사실 엄밀 히 말하면 최상위 엔터티인 키 엔터티는 본질 식별자와 굳이 다르게 할 필요가 없으므로 본질 식별 자를 결정하는 단계에서 미리 식별자를 확정하는 것이 좀더 현실적이다. 물론 식별자 확정 단계에 서 주변의 상황과 여건을 감안하여 일부를 조정하여 최종적으로 확정한다.

나) 메인 엔터티 식별자 확정

메인 엔터티는 해당 업무의 근본이 되는 엔터티라고 할 수 있으므로 자신이 하위에 거느리고 있 는 수많은 엔터티의 상황을 종합적으로 감안한 전략적인 결정을 해야 할 것이다. 이러한 엔터티는자신의 하위 엔터티에게는 최상위 조상이기도 하므로 될 수 있는 대로 식별자 속성의 개수를 적게 하는 것도 중요하다. 이런 이유 때문에 경우에 따라서는 전체를 대신하는 인조 식별자를 생성하기 도 한다.

다) 하위 엔터티 식별자 확정

이런 부류의 엔터티는 가능하다면 인조 속성을 많이 사용하지 않는 것이 바람직하다. 그 이유는 인조 속성이란 임의의 값을 의미하므로 유일성에는 도움을 줄지 모르지만 정보로서의 가치는 현저 하게 감소하기 때문이다.

속성 정의시 유의사항

데이터 모델링의 과정에서의 속성의 정의는 필요할지도 모른다고 생각되는 속성들을 필요할 때마 다 이것 저것 나열해 두는 방법으로 속성을 정의하고 있다. 이런 방식의 속성 정의에는 진정한 엔터 티 자신의 속성 이외의 다른 엔터티에서 빌려 온 것들이거나 여기저기에 있는 정보를 이용하여 가공 을 해놓은 속성들이 많이 존재한다. 하지만 이러한 속성들은 항상 데이터의 정합성을 해칠 수 있는 개연성을 가지고 있기 마련이다. 데이터 모델링에서 데이터가 들어가 살게 될 방이라 할 수 있는 속 성을 명확하게 정의하는 일은 중요하다. 속성을 정의할 때에는 다음과 같은 유의사항을 지켜야 한다.

의미가 명확한 속성 명칭을 부여한다.

속성의 명칭을 명확히 하는 것은 매우 중요하다. 이 말의 진정한 의미는 그 속성의 개념을 정확히 부여한다는 것을 뜻한다.

1) 직업이라는 속성 정의

직업의 사전적인 의미는 생계를 위하여 일상적으로 하는 일이라는 뜻이다. 하지만 이것이‘회사 원, 전문직, 자영업, 공무원 …’처럼 수십 가지 정도로 분류한 것을 말하는 것인지, 아니면 이 보다 훨씬 상세하게‘전산설계, 프로그래머 …‘ 등과 같이 수백 가지로 분류한 것을 말하는지, 아니면 수 천 가지 이상으로 상세하게 분류한 것을 말하는지를 분명하게 정의해야 한다.

2) 학점이라는 속성

학생이 수강한 강좌에서 취득한‘A학점, B학점 …’을 말하는 것인지, 그 강좌를 이수했을 때 받는 ‘2학점, 3학점 …’을 말하는지 분명히 해야 한다는 것이다. 이런 상황에서는 설사 최초 설계 단계에 서는 매우 명확한 정의가 되었더라도 의미의 와전이나 단절은 필연적으로 발생한다.

유일한 복합명사 사용

속성의 개념을 구체적이고 명확하게 정의했다면 그 명칭을 제대로 부여하는 것도 매우 중요한 일 이다. 남들에게 구구절절 보충설명을 하지 않더라도 거의 유사한 생각을 가질 수 있도록 보편적이고 함축성 있는 단어를 찾아내어야 한다. 속성이란 자신만이 가지는 분명한 독립적인 의미를 가지고 있 기 때문에 명칭 또한 단순히 일반 용어만으로 부여해서는 결코 구체적인 의미를 나타낼 수 없다. 결론적으로 말하면, 보편적인 용어를 적절히 결합한 복합명사를 만듦으로써 구체적인 표현을 할수 있다는 것이다. [그림 5-3-5]와 같은 논리 데이터 모델을 예로 보면 모호하게 이름지어진 속성이 많이 존재한다.

1) 순번

많은 데이터 모델에서 순번 혹은 일련번호라는 명칭의 속성을 자주 접하고 있다. 이 속성은 인조식 별자를 생성하기 위해서 사용한 것이 분명하며, 누구나 그렇게 받아들이고 있기도 하다. 그러나 분명 히 이 속성의 명칭에는 문제가 있다. 여기서 만약 정확하게 표현하고자 한다면, 보험계약순번 혹은 계약순번으로 지정하는 것이 옳다. 만약 순번이라고만 표현한다면 나중에 테이블로 설계가 되었을 때 이 테이블을 참조하는 하위 테이블에서 보면 어디서 온 칼럼인지 분명치 않게 된다. 만약 또 다른 엔터티에서도 순번이라는 속성을 가지고 있고 그것도 참조한다면 실제로는 서로 다른 속성이었지만 참조하는 쪽에서 보면 동일한 이름으로 나타난다는 문제가 있다.

2) 상태

이 명칭만으로는 속성의 의미가 참으로 애매모호하기 짝이 없다. 물론 심증적으로는 보험계약상태 를 말하는 것으로 보이지만 확실하지 않다. 실전에서는 이처럼 오해의 여지가 남아있는 애매한 명칭 들이 많이 나타난다. 이 상태가 자기 엔터티에서 지정되는 값을 관리하고자 하는 것인지, 하위 엔터 티의 최종 상태를 가져다 둔 것인지, 그것도 아니면 하위 엔터티의 상태를 종합해서 새로 의미를 부 여한 상태를 의미하는지 구분할 수 없다. 어떤 상태를 의미하는지 누가 보아도 알 수 있도록 명칭을 분명하게 지정해야 한다.

3) 보험기간

보험계약이 적용되는 기간이리 것으로 예상되기는 하지만 가령 12개월, 20개월로 표현되는 것인지 1년, 2년 으로 표현되는 것인지를 알수가 없다.

4) 최초납입영수일자

간결한 명사를 최초 + 납입 + 영수 + 일자로 잘 결합하여 복합명사를 만듦으로서 누가 보더라도 오해가 없을 만큼 상세하게 표현되어 있다.

5) 초회납방

최초로 납입한 회차의 납입 방법을 말하는 것인데 설사 그 업무에 관련 있는 대부분의 사람들이 이 해한다고 하더라도 최초납입회차 납입방법으로 표현하는 것이 바람직하다.

이렇듯 우리가 데이터 모델링에서 사용하는 속성명을 분명하게 표현하기 위해서 가능한 한 복합명 사를 사용해야 한다.

단수형으로 속성명을 사용한다

속성은 단일 값만을 저장하기 대문에 단수형으로 적는 것이 바람직하다. 예를 들어 고객 엔터티의 전자메일 속성 이름을 [전자메일들]과 같이 지었다면, 이 속성은 여러 개의 값들을 저장하는 것인가? 그렇다면 속성이 될 수 없으므로 여러 속성으로 분리하든지 아니면 별도의 고객 전자메일 엔터티로 분리해야 한다.

표준 단어 제정

표준 용어 사전을 데이터 모델링을 하기 이전에 생성하여 두면 데이터 모델의 각 객체들(엔터티, 속성, 테이블, 칼럼 등)이 최대한 그 기준을 준수하도록 유도하기가?준화 준수 여부를 관리하거나, 표준으로 변경할 대상을??데도 굉장한 힘을 발휘한다. 뿐만 아니라 속성을 구??이스 설계 단계에서 속성을 칼럼(Column)으로 전환시킬 때 사용할 영문 약어를 같이 제정해 두는 것도 바람직하다. 최근에는 모델링 도구뿐만 아니라 데이터 표준화를 전문적으로 수행하는 툴도 등장하고 있는 추세이다.

작의적인 전용 금지

전용(轉用)이란 말을 사전에서 찾아보면 예정되어 있는 곳에 쓰지 않고, 다른 데로 돌려서 쓰는 것 이라고 되어 있다. 이 말과 통합이란 말에는 미묘한 관련이 있다. 가령 A를 위해 만든 것을 B로도 사 용하면 전용이고, 아예 만들 때부터 A와 B를 위해서 만들었다면 통합이다. 그러나 결과만 놓고 본다 면 어쨌거나 A와 B를 위해 사용되었다는 것은 동일하다.

전용이 발생하는 경우는 크게 세 가지로 나눌 수 있다.

·         모델러가 속성의 의미를 매우 추상적이고, 모호하게 정의했기 때문에 그것을 적용하는 개발자들이 각기 다르게 이해함으로써 나타나는 경우이다.

·         개발이 막바지에 도달했거나 이미 운용 중인 시스템에서 새로운 사용자 요구 사항으로 인해 새로 운 속성의 추가가 필요할 때 나타나는 경우이다.

·         ERP 패키지에서 자주 나타나는 형태로써 미리 전용의 용도로 속성을 정의해 두는 경우를 말한다.

출처 : DB 포탈 사이트 DBguide.net

속성 검증 및 확정

다양한 경로를 통해 수집된 속성 후보를 엔터티에 배정시킨 후 이제 우리가 해야 할 일은 이들을 검증하여 제자리를 찾게 해 주는 일이다. 속성을 검증하는 작업은 총 4단계로 나누어 실시한다.

최소 단위(Atomic Value)까지 분할하라

1) 검증 방법

·         집합 개념의 속성은 단순 개념으로 분할한다.

·         가능한 최소 단위까지 분할한 후 관리 필요에 따라 통합한다.

·         일자, 시간, 성명, 주민등록번호, 우편번호 등은 일반적으로 분할하지 않는 것이 좋다.

·         분할 및 통합의 기준은 업무의 요구 사항에 따른다.

2) 분할 속성의 대표적 유형

가) 일자(日字) 형태의 속성 : 매출일자

분리된 것들이 속성의 자격을 가지고 있는지를 검토하기 위해서는 이들이 자기 혼자서도 독립적 인 의미를 가지고 있는지 확인해 보아야 한다. 매출월(mm)이 매출년도(yyyy)나 매출일(dd)을 무 시하고 혼자서도 어떠한 의미를 가지고 있겠는가? 아마 대부분의 경우는 이들을 하나로 결합했을 때만 매출이 발생한 일자라는 의미를 가질 수 있을 것이므로 이런 경우라면 통합된 것이 속성이라 고 보아야 한다.

나) 외부에서 공인된 속성 : 우편번호 유형

국가나 공공기관에 의해서 이미 공인되어 있는 각종 번호들(예; 우편번호, 주민등록번호, 사업자 등록번호, 법인번호, 여권번호 등)에 대한 속성 관리 형태는 매우 유사하다. 이들은 단지 길이에서 차이가 있지만 대부분 OOO-OOO 형식으로 나타난다. 우편번호의 앞의 세 자리는 마치 성명의 성과 같이 나름대로 확실한 의미가 있다. 이 세 자리 숫자는 반드시 단 하나의 시군구만 지칭하므 로 분명한 의미가 있다는 것이다. 그러나 뒤의 세 자리는 앞의 시군구가 없으면 독자적으로 의미를 갖지는 못한다.

다) 전화번호 유형 : 전화, 팩스번호

전화번호는 지역번호(DDD)+국번+개별번호로 나누어진다. 일반적인 의미로 본다면 이들 각각 에는 분명히 독립적인 의미가 있다. 그러나 지금 우리가 검토하고자 하는 엔터티 내에서 과연 독립 적인 의미를 가지느냐는 또 다른 문제일 수 있다. 예를 들어, 고객 엔터티에 있는 고객의 연락전화 번호를 검토한다고 가정해보자. 국번만 독립적인 의미로 부여할 경우가 있는가? 뒷자리 4자리의 개별번호만 액세스하여 어떤 처리나 참조를 할 가치가 있는가? 지역번호만 독립적인 의미로 인정 하여 처리할 경우가 있겠는가? 물론 이러한 질문에 대한 대답은 그 엔터티의 내용이나 앞으로의 관리 수준에 많은 영향을 받는다.

라) 주소 유형 : 고객 주소

주소 형태로 관리되어야 하는 일단의 속성들은 어떤 시스템에서도 자주 등장하는 매우 중요한 속성의 한 유형이다. 주소를 세부적으로 나누는 방법은 여러 가지를 생각해 볼 수가 있다. 가령 도 (광역시) + 시군구 + 읍면동 + 단지(아파트,건물) + 동호수(번지)로 아주 세분화를 시킬 수도 있 다. 크게 나누어 우편번호와 연결되어 사전에 이미 생성되어 있는 주소 부분(여기서는 지역주소라 고 표현함)과 나머지 부분(상세주소로 표현)으로 분리하는 방법이다.

하나의 값(Single Value)만을 가지는지 검증한다

속성에서 관리되어야 할 값이 반드시 단 하나만 존재해야 한다는 것이다. 그러나 이 말의 진정한 의미는 그 속성에 들어 올 수 있는 값의 종류가 반드시 하나만 존재하고 있다는 의미는 절대 아니다. 쉽게 설명한다면 그 엔터티에 들어가는 개체마다 반드시 하나의 값만 보유하고 있어야 한다는 것 이다.

1) 검증 방법

·         여러 값을 가지거나 반복되는 속성은 잘못된 속성이다.

·         반복되는 속성은 새로운 엔터티로 분할해야 할 1차 정규화의 대상이 된다.

2) 대표적 유형

가) 계약일

계약일은 고객 엔터티의 속성이 아니라 가입계약의 속성이다. 즉, 고객은 여러 개의 계약일을 가 질 수 있기 때문에 고객의 속성이 될 수 없다. 상황에 따라서 아직 가입계약 엔터티가 도출되지 않 았을 수도 있고, 이미 도출되어 있을 수도 있다. 만약 아직 도출이 되지 않은 상태라면 이 속성에 대한 유일 값 검증에 의해서 가입계약 엔터티는 자연스럽게 도출될 것이며, 이미 존재한다면 이 속 성을 거기에 적절히 반영하면 된다.

나) 차량번호

어떤 고객은 하나 이상의 차량을 가질 수도 있다. 물론 지금까지 보유한 차량의 이력을 관리하고 자 한다면 당연히 유일하지 않을 것이고, 현재 입장에서만 보더라도 하나 이상의 차량을 보유한 사 람들은 얼마든지 존재한다. 그러나 이처럼 실제로는 하나 이상이 존재하지만 업무적으로 판단했을 때 굳이 하나 이상의 차량을 관리할 필요성이 없다거나 과거의 이력을 관리할 의사가 없다면 모델 링 입장에서는 유일 값이 되므로 이들은 이 엔터티의 속성이다.

다) 취미

취미는 사람에 따라 당연히 여러 가지를 가질 수 있다. 취미와 같은 고객의 성향 정보는 마케팅 의 중요한 자료가 된다. 엄청나게 많은 고객 모두를 대상으로 마케팅을 한다는 것은 너무 많은 비 용이 들어가기 때문에 가능성이 높은 고객들을 대상으로 표적 마케팅을 하지 않을 수 없다. 이때 고객의 각종 성향 정보는 매우 중요한 가치를 가진 정보이므로 이를 최대한 확보하려는 노력은 반 드시 필요하다.

추출 속성(Derived Attribute)인지 검증한다

속성 검증의 제3단계는 그 속성이 원천적인 값인지, 다른 속성에 의해 가공되어서 만들어진 값인 지를 검증하자는 것이다. 원천적인 값이란 말 그대로 다른 것에 의해 만들어진 것이 아닌 태초부터 창조된 것을 말하며, 추출 값이란 이들을 가지고 언제라도 쉽게 재현할 수 있는 속성을 말한다. 어 쩌면 이것은 매우 분명하고 단순한 개념이지만 실전적인 시각에서 바라보면 그리 간단하지만은 않 다.

1) 대표적 유형

가) 현재 정보만 관리하는 형태 : 현주소, 고객 등급 등

자식 엔터티에 있는 맨 마지막 정보를 현재의 정보라는 의미로 중복화하는 경우라고 할 수 있다. 엄밀하게 말하면 이력(선분) 개념이 들어가 있는 자식 정보 중에서 현재 시점을 통과하고 있는 선 분에 해당하는 데이터를 미리 가져다 두는 형태이다.

나) 최초 정보를 보관하는 형태 : 최초 가입일, 모집 사원 등

자식 엔터티의 여러 정보 중에서 하나만 선택하는 또 하나의 방법은 바로 최초로 발생한 정보만 가져다 두는 것이다. 실전에서 발생하는 대부분의 경우는 현재 정보나 집계 형태로 나타나지만, 가끔은 최초의 정보를 보관하고자 하는 경우도 나타난다.

다) 집계 정보를 관리하는 형태 : 인원 수, 가족 수, 총직원 수 등

추출 값을 관리하는 속성 중에서 아마 가장 많이 나타나는 형태는 수행 속도를 위해 하위 엔터티 의 정보를 집계해 가져다 둔 경우일 것이다. 물론 집계의 형태에는 금액 관련 속성들에서 많이 발 생하는 합계(sum)와 발생회수(count)를 관리하기 위해 사용하는 건수, 회수, 차수 등의 단어가 들 어가는 속성들이 대부분이다.

라) 추출 릴레이션만 관리하는 형태 : 가입 계약번호, 관리 사원 등

추출 속성 중에는 자식 엔터티의 식별자를 전부 또는 일부만 옮겨둔 것을 자주 발견할 수 있다. 논리적으로는 M쪽의 식별자가 1쪽으로 올 수는 없지만 대부분의 경우 마지막 건의 식별자를 가져 다 두는 경우가 많다.

마) 대표 정보만 관리하는 형태 : 대표 전자메일 ID, 취미, 법인의 대표자 정보

자식 엔터티에 있는 여러 개의 정보를 하나로 만들어 올리는 방법 중에는 가장 대표적인 것 하나 만을 선정하는 경우도 있다. 예를 들어, 한 사람이 여러 개의 전자메일 ID을 가질 수 있다. 심지어 사람에 따라서는 십여 개를 가지고 있기도 한다.

바) 다른 속성의 일부 정보만 분리한 형태 : 성별, 결혼 여부 등

추출 속성 중에는 특별한 목적을 위해서 다른 속성의 일부를 떼어서 새로운 속성을 만드는 형태 도 자주 등장하고 있다. 사실 우리가 확실한 속성이라고 할 수 있는 성별도 이러한 형태에 속한다. 만약, 개인 서브타입에 속하는 모든 고객들이 주민등록번호를 반드시 가져야 하고, 그 값이 확실하 다고 가정한다면 일곱째 자리가 1이냐 2냐에 따라 남·여를 구별할 수 있다.

사) 일부분만 추출 값인 형태 : 인원 수, 법인의 대표자 정보 등

일부분이란 이 속성에 값이 들어가는 수많은 개체들 중에서 일부는 다른 엔터티에서 가공하여 만들 수 있지만 다른 일부는 원시 값인 경우를 말하는 것이다.

보다 상세하게 관리할 것이냐?

‘보다 근원적인 정보를 관리해야 하지 않겠느냐?’고 질문하는 것이다. 다시 말해 현재까지는 이대 로도 충분했지만 수 많은 변화가 예상되는 미래를 대비하기 위해 좀더 근원적인 정보를 관리할 필요 성에 대해 검토해 보자는 것이다. 이 단계가 바로 데이터 모델링이 현재뿐만 아니라 미래의 시스템 구조를 찾아 나가는 과정이라는 것을 의미한다

가공 속성 규칙

도출 및 계산된 속성들은 도출 또는 계산에 사용된 기준 속성(Base Attribute)에 대한 종속성과 함께 데이터 모형에 표현되지 않으면 안 된다.

·         초기 데이터 모델링 이론을 보면 도출된 속성이나 가공된 속성은 중복으로 인식하고 이를 데이터 모델에 표현하지 말 것을 권고했다. 그러나 현재는 이러한 속성들이야 말로 기업의 관리자들이 관 심을 가지고 보는 속성으로 데이터 모델 내 반드시 기술할 것을 권장하고 있다.

·         도출(Derived) 속성이란 하나 이상의 다른 데이터 속성의 여러 사례들의 값을 누적함으로써, 선택 적으로 주제 도출 속성에 대하여 값을 창출키 위해 값에 어떤 추가 계산 작업을 수행함으로써 창출 되는 속성이다.

·         계산(Calculated) 속성은 엔터티의 단일 사례에 대한 어떤 특성을 기술하며, 일반적으로 관련 속 성의 또다른 단일 사례로부터 계산된다.

·         도출 속성은 경영층이 진실로 원하고 필요로 하는 정보를 대표한다.

·         도출 속성은 사용자들의 데이터 요구 사항을 나타낸다.

·         데이터 모형에 도출 속성을 포함시키는 것은 그 기본키(Primary Key)로서의 역할을 맡아서는 안 된다.

속성 후보 도출

속성을 결정할 때에도 다양한 후보를 준비하고 이들 중에서 속성의 검증 규칙에 부합하는 것을 속 성으로 최종 결정하게 된다. 특히 이러한 후보 도출 작업은 기존의 현장조사에 국한하지 않고 좀더 적극적이고 개선적인 사고를 가지고 사용자에게 많은 질문을 하고 확인해 속성 후보를 도출한다.

속성 후보 수집처

속성은 결국 속성 후보 중에서 선택되기 때문에 우리는 일단 다양한 경로를 통해서 좋은 후보를 가 능하다면 최대한 많이 확보해야 한다.

1) 구 시스템의 문서자료

가동 중인 기존 시스템의 데이터 구조 및 프로세스 명세들이 나타나 있는 설계 자료에서부터 사용 자를 위한 지침서에 이르기까지 다양한 도큐먼트가 있을 것이다. 이 자료는 엔터티 후보 및 속성 후 보를 도출하는데 가장 유용하게 사용할 수 있다.

2) 현업 장표/보고서

현업에서 사용하고 있는 각종 장표나 보고 자료들을 수집해서 조사해 보는 것이다. 현업 업무 중에 는 업무를 효과적으로 처리하기 위하여 많은 장표와 각종 보고 자료를 만들고 있다. 물론 이들을 그대로 속성 후보로 선정할 수 있는 것은 결코 아니다. 그 중의 상당 부분은 다른 속성에 의해 만들어질 수 있는 가공된 결과(추출 속성, Derived Value)인 경우가 많기 때문이다. 더구나 이것들은 대부분 정규화가 되어 있지 않기 때문에 정확히 파악해야만 진정한 의미의 속성 후보를 찾아낼 수 있다.

3) 사용자와 협의

데이터 모델링 과정에서부터 시종일관 현업 담당자들과 같이 진행하는 것이 데이터를 모델링하는 최상의 방법이다.

4) DFD의 DD(Data Dictionary)

업무 파악 및 시스템 분석을 위한 기능 설계로 자료 흐름도가 존재한다면 여기에 있는 데이터 저장 소(Data Store)와 데이터 사전(Data Dictionary)에 있는 정보를 이용하여 속성의 후보를 도출할 수 있다. 자료 흐름도를 작성할 때 생성되는 자료 저장소는 비록 테이블처럼 표현되지만 사실은 이러 한 내용의 데이터가 저장되어야 한다는 데이터의 추상화된 집합이라 할 수 있으며, 그 속에 들어가야 할 구체적인 속성이 데이터 사전에 기술된다.

5) 전문 서적 및 자료

동일한 업무에 대한 전문 서적 또는 자료를 통해서도 속성의 후보를 도출할 수 있다.

6) 다른 시스템 자료

우리가 개발할 시스템의 주변을 살펴보면 사내외에 이와 관련된 시스템이나 유사한 시스템을 찾을 수 있을 것이다. 만약 여러분이 그들이 가지고 있던 속성 또한 후보로서 참조하는 것도 속성 후보를 찾는데 좋은 방법이다.

속성 후보 선정 원칙

속성의 후보를 선택할 때는 최대한 충분히 수집해야 한다. 그것은 검토한 결과 자신의 속성이 아닌 것으로 판명될지라도 검토할 기회를 제공해 주는 단서라는 중요한 역할을 하기 때문이다.

1) 원시(Source) 속성으로 보이는 후보는 버리지 않는다

다른 속성에 의해 다시 재현할 수 있는 가공(추출, Derived) 속성이 아닌, 다시 말해서 만약 이 속 성이 없다면 다시는 재현할 수가 없을 때 이 속성을 원시 속성이라고 부른다. 재현이 불가능하다면 이것을 버리는 순간, 이미 정보는 소실되어 버리므로 절대 버려서는 안 된다.

2) 소그룹별로 후보군(Pool)을 만들고 가장 근접한 엔터티에 할당한다

모든 엔터티가 정의되어 있는 상태가 아니라 단지 핵심 엔터티들을 대상으로 모델링을 실시해왔을 뿐이므로 아직은 모든 엔터티가 드러나 있지는 않다. 그렇기 때문에 각 속성 후보들을 적절한 데이터 그룹으로 생성하여 두는 것이 필요하다.

속성의 기본 구성요소

1) 속성명

속성의 내용이나 목적이 무엇인지 알려주는 명사 또는 명사구이다. 기업에서 널리 사용하는 용어 를 쓴다.

·         속성의 의미를 명확히 표현하는 함축성 있는 명사 혹은 명사구를 사용한다.

·         해당 업무에서 일반적으로 사용하는 용어를 사용한다.

·         실체명은 속성명으로 사용하지 말아야 한다.

·         필요시 표준 약어를 제정하여 속성명을 생성하고 그 속성명을 단 하나의 실체에만 속하도록 하는 것이 바람직하다.

2) 도메인

속성이 지닐 수 있는 값에 대한 업무적인 제약 조건으로 파악된 일련의 특성이다. 모든 영역에서 같은 도메인을 사용하는 것이 좋다. 속성이 기존 도메인 집합에 속해 있지 않는 경우에는 새로운 도 메인을 추가한다. 도메인은 다음과 같은 속성들을 가진다.

·         데이터 타입

·         길이

·         허용 값(Permitted Value): 속성에 지정할 수 있는 모든 값들의 집합

·         디폴트 값 및 디폴트 알고리즘

3) 선택성

모든 건의 해당 속성이 반드시 값을 가져야 하는지 여부를 나타낸다.

·         선택성 조건 =} 선택성이 다른 속성 값에 의해 영향을 받는 경우

·         필요조건 / 금지조건 / 무관계조건

속성 개념

속성 정의

속성은 엔터티에서 관리되는 구체적인 정보 항목으로 더 이상 분리될 수 없는 최소의 데이터 보관 단위이다. 예를 들어, 엔터티 사원에 속하는 모든 엔터티는 이름을 갖고 있다. 또한 모든 사원에는 입사일자, 사원번호, 생년월일 등의 특성을 가지고 있다. 엔터티 사원에 속하는 모든 인스턴스들이 공통으로 가지는 이러한 특성을 속성(Attribute)이라고 한다. 각 엔터티들은 일련의 속성들에 의해 상세화될 수 있다.

속성 특징

1) 속성의 어원적 의미

속성이라는 의미에는 가공되지 않은 것이라는 의미도 포함되어 있다. 이 말은 곧 원천적인 것을 의 미한다. 또한 고유한 성질이란 의미도 가지고 있는데 이 말은 남의 도움을 받지 않더라도 자기만이 가지고 있는 독자적인 성질이 반드시 있어야 함을 뜻한다. 혼자서도 독자적인 성질을 가지고 있느냐 에 대한 문제는 절대적이 아니라 상대적이라는 것 때문에 판단이 쉽지 않다. 즉 어떤 시스템의, 어떤 엔터티에서, 어떤 목적으로 사용하려고 하느냐에 따라서 달라지기 때문에 사람의 종합적인 판단이 필요하다는 것이다. 이러한 속성의 어원적인 특징들은 속성 검증의 원칙으로도 사용된다.

2) 속성도 일종의 집합이다.

물리 데이터 모델링 단계에서 엔터티는 테이블이 되고, 속성은 칼럼이 된다. 결국 속성에는 데이터 값이 들어가게 되며, 그 값들은 여러 종류를 가지게 된다. 가령, 사원 정보 엔터티의 직책 속성에는 사원, 대리, 과장, 부장 … 등 여러 종류의 값들이 존재한다. 만약 이 값들의 종류 하나 하나를 개체 라고 한다면, 직책이란 속성은 결국 이들을 구성요소로 하는 집합이란 뜻이 된다.

3) 릴레이션십도 속성이다.

물리 데이터 모델링 단계에 가서 보면 릴레이션십 또한 결국은 일종의 속성이 될 수 밖에 없다.

[그림 1]에서 매출 부서는 엄격히 말해서 매출 엔터티의 속성이 아니라 부서 엔터티와의 릴 레이션십이라고 하는 것이 정확한 표현이다. 사실 이론적으로 따진다면 속성은 전체 엔터티를 통 틀어 반드시 유일하게 존재해야만 한다. 나 자신(속성)은 우리집(엔터티)에 속하고, 거기서 유일하지만 다른 모든 것(엔터티)들에 대해서도 반드시 유일한 존재이다.

매출 엔터티에 있는 매출 부서 속성에는 나중에 분명히 부서 코드가 들어온다. 부서 코드 속성이 오직 한 곳에만 위치해야 한다면 반드시 부서 엔터티에 있어야만 한다. 이 말은 다른 엔터티에 있 는 모든 부서 코드는 사실 모두가 릴레이션십이라는 것을 의미한다. 이 릴레이션십은 나중에 데이 터베이스 설계 단계에서 관계형 데이터베이스로 설계하고자 한다면 매출 테이블에 매출 부서라는 외래키 칼럼으로 존재하게 된다.

나) 매출 상품 릴레이션십

[그림 1]의 좌측에 있는 매출 상품 릴레이션십은 속성이 아닌 릴레이션십으로 제대로 표현 되어 있다. 설계 단계에서 결과적으로 동일해지는데 굳이 이것을 릴레이션십으로 표현하여 그림을 복잡하게 할 필요가 있겠는가?

물론, 원론적으로 본다면 이를 무조건 릴레이션십으로 표현하는 것이 옳다는 것에는 이견이 있 을 수 없다. 왜냐 하면 우리가 작성하는 논리적 데이터 모델이란 업무를 체계적으로 형상화하는 것 이지 데이터베이스의 구조를 정의하는 것이 아니기 때문이다. 엄격히 말한다면 논리적 데이터 모 델에는 데이터베이스나 컴퓨터와 같은 물리적 요소들은 전혀 감안하지 않은 상태에서 정의되어야 한다.

4) 속성들 간은 서로 독립적이다

속성들은 반드시 식별자에 직접 종속되어야 한다. 이 말은 정규화의 제2정규형에 해당하는 말이 다. 만약 속성들 간에 종속성이 존재한다면 이들은 별도의 엔터티로 분리되어야 한다. 이것이 바로 제3정규형이다.

출처 : DB 포탈 사이트 DBguide.net

논리 데이터 모델링 정의

논리적 데이터 모델링이란 데이터베이스 설계 프로세스의 Input으로써 비즈니스 정보의 구조와 규칙을 명확하게 표현하는 기법이다. 논리적 모델은 데이터 모델링이 최종적으로 완료된 상태를 말한다. 즉, 물리적인 스키마 설계를 하기 전단계의 데이터 모델 상태를 일컫는 말이다.

논리적 데이터 모델링의 핵심은 어떻게 데이터에 액세스하며, 누가 데이터에 액세스하며, 그러한 액세스의 전산화와는 독립적으로 비즈니스 데이터에 존재하는 사실을 인식·기록하는 기법일 뿐만 아니라 철학이다.

특히 데이터 모델링 과정에서 가장 핵심이 되는 부분이 논리 데이터 모델링이라고 할 수 있다. 데이터 모델링이란 모델링 과정이 아닌 별도의 과정을 통해서 조사하고 결정한 사실을 단지 개체-관계 다이어그램(ERD, Entity Relationship Diagram)이라는 그림으로 그려내는 과정을 말하는 것이 아니다. 시스템 구축을 위해서 가장 먼저 시작할 기초적인 업무조사를 하는 초기 단계부터 인간이 결정해야 할 대부분의 사항을 모두 정의하는 시스템 설계의 전 과정을 지원하는 과정의 도구라고 해야 할 것이다.

논리 데이터 목적 및 효과

해당 비즈니스에 대한 데이터 관점에서의 명확한 이해

데이터 모델링을 한마디로 하면 업무의 데이터 관점에서의 표현 또는 설계라고 할 수 있다.

전사적인 통합 데이터 체계 확립

논리 데이터 모델링을 통하여 전사의 데이터에 대한 구조를 체계화하고 이를 통한 통합 데이터 체계를 확립한다.

데이터의 일관성 및 정확성 유지를 위한 규칙 도출

기업이 관리하는 데이터의 일관성, 정확성을 유지하기 위해서는 데이터에 대한 정확한 업무 규칙과 데이터 처리 규칙들을 생성 관리해야 한다. 이것을 표현하고 관리하는 것은 논리 데이터 모델을 통해서 하게 된다.

안정적인 데이터베이스 설계의 토대 마련

논리 데이터 모델을 통하여 물리 데이터 모델이 생성된다. 특히 데이터 모델의 구체적인 실체(객체)인 데이터베이스를 안정적이고 체계적으로 생성하는 기초가 된다.

사용자와의 명확한 의사소통을 위한 수단으로 활용

시스템 설계자와 업무 담당자 간의 의사소통의 수단으로 논리 데이터 모델이 사용된다. 반면 설계자와 개발자 간의 의사 소통의 수단은 물리 데이터 모델이라고 볼 수 있다. 하지만 이 과정에서 개발자라고 하더라도 논리 데이터 모델에 표현되어 있는 비즈니스 규칙에 대한 이해가 선행되어야 한다.

논리 데이터 모델링 필수 성공요소

업무에 능통한 현업 사용자와 함께 데이터 모델링을 진행하라

데이터 모델링 작업은 결국 업무를 데이터 관점에서 체계화하는 작업이다. 즉, 비즈니스에서 사용되는 데이터를 집합(엔터티)으로 생성하고 이들 간의 관계(Relationship)를 지정하는 작업이다. 이러한 작업을 하는 과정에서 업무를 알고 있는 현업 사용자의 참여는 필수적이다.

절차(Procedure)보다는 데이터에 초점을 두고 모델링을 진행하라

데이터 모델에는 순서와 시간, 흐름의 개념이 들어가지 않는다. 이러한 개념을 넣어서 마치 데이터 흐름도(DFD, Data Flow Diagram)처럼 업무의 흐름에 따라 엔터티가 발생하는 경우를 실전에서는 많이 보게 된다. 이런 식의 데이터 모델에서는 많은 데이터의 중복과 데이터 정합성을 훼손할 개연성을 내포한 모델이 만들어지게 마련이다. 그렇기 때문에 가능한 절차를 배제한 채로 데이터 모델을 생성해야 한다.

·         데이터의 구조(Structure)와 무결성(Integrity)을 함께 고려하라

·         개념화(Conceptualization)와 정규화(Normalization) 기법을 적용하라

·         가능하면 다이어그램(Diagram)을 이용하여 업무를 표현하라

·         데이터 모델링을 지원하는 데이터 사전을 구축하라

출처 : DB 포탈 사이트 DBguide.net

개념

엔터티란?

• 엔터티란 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서 그 대상에 대한 데이터를 저장할 수 있고 대상들 간의 동질성을 지닌 개체 또는 행위의 집합
• 엔터티를 정의할 때는 어떤 대상이 그 엔터티에 속하는지 혹은 속하지 않는지를 명확하게 정의할 수 있어야 한다.
• 예를 들어 영화배우라는 엔터티를 영화에서 극중 배역으로 분하여 연기하는 사람(?)으로 정의한 경우에 파트라슈는 주연이지만 배우인지 아닌지를 명확히 정의할 수 있어야 한다.

엔터티 정의의 요건

• 우리가 관리하고자 하는 것인지를 확인한다.
• 가로와 세로를 가진 면적(집합)인지를 확인한다.
• 대상 개체들 간의 동질성이 있는지를 확인한다.
• 다른 개체와 확연히 구분되는 독립성을 가지는지를 확인한다.
• 순수한 개체이거나 개체가 행위를 한 행위 집합인지를 확인한다.

의미상 주어 정의

엔터티에는 인조 식별자(Artificial Unique Identifier)가 있고, 진주어(眞主語)에 해당하는 관계 나 속성이 어딘가에 있을 수 있다. 예를 들어 신용카드의 가주어는 임의의 번호를 부여해서 만든 카드번호를 말하며, 진주어는 카드를 발급 받은 사람(고객 번호)과 발급 받은 상품(상품 코드), 그리고 발급일자가 될 것이다. 의미상의 주어를 모델링 입장에서 본다면, 원래의 본질적인 식별자에 해당한다. 여기에서는 이것을 본질 식별자라고 칭한다.

본질 식별자 정의의 의의

모델링 진행 과정에서 본질 식별자를 특별히 중시하는 이유는 집합의 의미가 모호한 상태에서는 더 이상 객관적인 판단을 진행해 가는 것이 불가능하기 때문이다. 집합의 인스턴스가 생성되는 정확 한 단위를 모르고서는 집합이 명확해질 수 없다. 다시 말해서 집합의 의미가 명확하게 정의되지 않은 모호한 집합에 인조적인 유일한 이름만 가져다 붙인다고 해서 갑자기 집합의 정의가 명확해지지는 않는다.

본질 식별자 정의 예

신용카드 엔터티의 본질 식별자인 고객 번호와 상품 코드는 부모에게서 상속받은 릴레이션십이며, 이 부모들은 바로 키 엔터티이다. 다시 말해서 본질 식별자로 상속 관계를 규명해 올라갔을 때 최상위에 존재하는 것이 바로 키 엔터티라는 것이다. 여기서 주의할 것은 임의의 엔터티가 다른 엔터티와 1:M 이나 1:1 관계일 때 1쪽의 엔터티가 항상 본질 식별자가 되는 것은 아니다. 예를 들어, 사원 엔터티와 부서 엔터티는 M:1의 관계를 가지지만 사원 엔터티의 부모가 부서 엔터티는 아니다. 다시 말해서, 1쪽의 엔터티라고 해서 항상 본질 식별자가 되는 것은 아니다. 본질 식별자란 만약 그가 없다 면 자신이 절대로 태어날 수 없을 때만 해당된다.

출처 : DB 포탈 사이트 DBguide.net

주제 영역 개념

주제 영역(Subject Area)은 기업이 사용하는 데이터의 최상위 집합이다. 예를 들어, 제조 업체의 경우 인사, 생산, 자재, 판매 등의 주제 영역이 있을 수 있다. 하나의 주제 영역으로 정의되는 데이터간의 관계는 밀접하고, 다른 주제 영역에 포함되는 데이터간의 상호작용은 최소화할 수 있도록 정의한다. 데이터는 기본적으로 관계 구조로 표현된다. 관계 구조는 데이터간의 관계가 복수개로 표현되면서 서로 연결되어 있기 때문에 하향식(Top-down) 분석이 용이하지 않다. 계획 수립 단계는 하향식 분석을 원칙으로 하고, 검증을 위해서 부분적으로 상향식 분석을 사용한다. 데이터를 하향식으로 분석하기 위한 개념으로 유용한 것이 주제 영역이다. 주제 영역은 계층적으로 표현될 수 있다. 주제 영역을 분해하면 하위 수준의 주제 영역이나 엔터티가 나타난다.

주제 영역 명명

 1. 보편적 업무 용어 사용

  실제 업무에서 보편적으로 사용하는 업무 용어를 부여하는 것이 바람직하다 예) 인사, 생산, 판매, 구매, 재무 등

 2. 단수형 명사 사용

  유일한 단수형 명사를 사용한다

 3. 데이터 그룹을 의미하는 용어 사용

데이터의 그룹을 의미하는 이름을 부여한다 업무 활동(Activity)을 의미하는 이름을 배제하고 데이터 그룹을 의미하는 이름을 사용하도록 한다.

주제 영역 활용

 1. 목적

• 데이터의 계층적 구조 파악하는데 도움이 된다.
• 업무 기능(Function)과 병행하여 분석하는 경우에 분석의 최상위 단위 역할을 하여 품질 확보에기여한다.
• 주제 영역 계층과 업무 기능 계층 간의 대응 관계를 확인한다.

 2. 장점

• 데이터 및 업무 활동 모델의 품질보증(Quality Assurance)
• 프로젝트 관리(Project Management) 용이
• 모델 개발 조정(Development Coordination) 용이
• 리포지터리(Repository) 관리 용이
• 상세 사항의 전개 혹은 축약 가능

주제 영역 도출

 1. 업무에서 사용하는 데이터의 명사형 도출

      정보 수집 소스로부터 명사형 찾기

 2. 업무 기능의 이름으로부터 도출

     데이터와 업무 활동의 상호 보완 관계

 3. 하향식(Top-down) 접근 방법

    주제 영역에서 출발하여 엔터티 타입으로 전개

 4. 상향식(Bottom-up) 접근 방법

    엔터티 타입을 그룹핑하여 주제 영역 도출

 5. 분석 단계에서의 도출

   아키텍처 모델(Architecture Model)을 정련하는 과정에서 도출

   데이터 모델을 상세화하는 과정에서 도출

주제 영역 정의 내용

 주제 영역 목록

 레벨 : 주제 영역의 계층 수준 (1차, 2차, ... 단위)

 주제 영역명

 설명 (단위 주제 영역의 경우)

 대표 엔터티 : 해당 주제 영역 내에서 대표적인 엔터티를 기술한다.

출처 : DB 포탈 사이트 DBguide.net