식별자(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가 가지고 있는 본질을 자세히 살펴보면 크게 두 가지의 의미를 가지고 있다.

가) 식별자로서의 역할

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

나) 정보로서의 역할

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

조상의 식별자를 내가 상속 받고, 다시 그것을 내 자손들에게 물려준다면 자손들은 굳이 나를 경유하지 않고서도 조상이 누구인지 알 수 있는 것과 유사하다. 인조 식별자를 설명하면서 언급했듯이 단지 유일한 값을 만들기 위한 목적 뿐이었다면 굳이 부모에게 받은 식별자를 자??을 만드는 것이 가능하다. 이 말에는 부모의 식별자를 내 이름에 넣는 것에 상관없이 내가 태어난 이상 부모는 존재한다는 의미가 내포되어 있다. 비록 부모가 분명하더라도 부모의 식별자가 나의 식별자를 만들기 위해서 반드시 필요한 것은 아니라는 것이다. 그러나 내 식별자에 부모의 식별자를 포함시키지 않는 순간에 내 자손들에게는 더 이상 조상의 식별자를 상속시키지 못한다.

2) UID 상속과 단절의 원리

식별자 확정이란 단지 자기 식별자의 형태를 결정한다는 단순한 의미로만 생각해서는 안된다. 데이터 모델이 복잡한 업무로 인해 어쩔 수 없이 복잡해지더라도 식별자 상속이 전략적으로 이루어진다면 나중에 데이터를 처리할 때의 실제 액세스 단계에서는 훨씬 간편하게 만들 수 있다. 즉, UID의 적절한 상속과 단절 전략은 실질적인 처리의 단순화를 가져다 줄 수 있으므로 그 전략적 가치를 가지고 있다.

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

3)식별자 확정 절차

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

가) 키 엔터티 식별자 확정

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

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

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

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

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

정규화(Normalization)

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

정규화의 의미

• 잘 만들어진 데이터 모델이라고 해도 엔터티에 데이터를 삽입, 수정, 삭제할 때 오류가 발생할 개연성을 가지고 있다. 이러한 것들을 통칭해서 변경 이상(Modification Anomaly)이라고 한다. 여기에는 구체적으로 삽입 이상(Insertion Anomaly), 수정 이상(Update Anomaly), 삭제 이상 (Deletion Anomaly) 등이 있다.
• 변경 이상이 발생하는 엔터티를 그대로 운용하게 되면 데이터가 신뢰할 수 없는 값들로 채워질 가 능성이 있다. 즉, 데이터의 일관성, 무결성을 해칠 가능성이 있는 것이다.
• 정규화 과정을 통해서 변경 이상의 엔터티를 정규화된 엔터티로 변환하게 된다.

1) 입력 이상

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

2) 삭제 이상

일부 정보를 삭제함으로써 유지되어야 할 정보까지도 삭제되는 연대 삭제가 발생한다.

3)갱신 이상

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

정규화의 장점

1) 중복값이 줄어든다

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

2) NULL 값이 줄어든다

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

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

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

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

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

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

정체계화되고, 규칙의 Value화에도 도움을 주게 된다.

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

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

정규화 단계

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

가) 정의

• 모든 속성은 반드시 하나의 값을 가져야 한다. 즉, 반복 형태가 있어서는 안된다.
• 각 속성의 모든 값은 동일한 형식이어야 한다.
• 각 속성들은 유일한 이름을 가져야 한다.
• 레코드들은 서로 간에 식별 가능해야 한다.

나) 정규화 작업

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

• 어떤 속성이 다수의 값을 가지고 있다면 M:1 관계의 새로 엔터티를 추가한다.
• 관계형 모델에서는 관계(Relation) 정의상 한 속성이 하나의 값만을 가져야 한다. 그러므로 비정규형 관계는 엄밀히 말하면 관계로 간주할 수 없다.
• 비정규형 관계가 관계로서의 모습을 갖추기 위해선 여러 개의 복합적인 의미를 가지고 있는 속 성이 분해되어 하나의 의미만을 표현하는 속성들로 분해되어야 한다. 즉 속성수가 늘어나야 한 다.
• 비정규형 관계가 관계로서의 모습을 갖추기 위해선 하나의 속성이 하나의 값을 가질 수 있어야 하며, 이 조건을 만족시키기 위해선 로우(Row)가 늘어나야 한다. 또는 다른 관계로 분리되어야 한다.
• 분석 또는 모델링 진행 과정에서 발생하며, 최종적인 모델링 완성 단계에서는 나올 수 없다. 그러나 분석(모델링) 초기 단계에는 상세히 분해된 속성보다는 위와 같은 레벨의 속성 추출이 복잡도를 줄일 수 있으므로 실전에서는 효율적이고 유리하게 이용될 수도 있다.

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

가) 정의

• 식별자가 아닌 모든 속성들은 식별자 전체 속성에 완전 종속되어야 한다.
• 이것을 물리 데이터 모델의 테이블로 말하면 기본키가 아닌 모든 칼럼들이 기본키에 종속적이어 야 2차 정규형을 만족할 수 있다는 것이다.

나) 정규화 작업

• [그림 4-3-10]에서와 같이 식별자가 학번 + 코스코드로 이루어진 학과등록 엔터티에서 학번 속성에 평가코드, 평가내역 속성들이 종속적이다. 그렇기 때문에 이것은 2차 정규형을 위반하고 있는 것이다.
• [그림 4-3-10]에서와 같이 식별자가 학번 + 코스코드로 이루어진 학과등록 엔터티에서 코스코드 속성에 코스명, 기간 속성들이 종속적이다. 그렇기 때문에 이 또한 2차 정규형을 위반하고 있는 것이다.
• 의미상의 주어 즉, 본질식별자를 알아야 식별자 부분 종속인지를 구분할 수 있다.

• 속성의 의미가 명확해야 종속성을 비교할 수 있다.
• 어떤 속성 식별자 전체에 종속되어 있지 않으면 잘못된 위치이며 새로운 엔터티 즉, 상위 부모 엔터티를 생성하고 UID BAR를 상속받게 된다.

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

가) 정의

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

나) 정규화 작업

• [그림 4-3-11]에서 학과등록 엔터티에서 평가코드, 평가내역 속성들이 서로 간에 종속적이다. 즉, 평가내역 속성은 평가코드 속성에 종속적이다. 그렇기 때문에 이것은 3차 정규형을 위반하 고 있는 것이다.
• 3차 정규형을 위반하고 있을 시에는 [그림 4-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차 정규형을 만족한다.

３. M:M 관계 해소

M:M 관계의 의미

M:M 관계는 논리 데이터 모델링 과정에서 많이 나타난다. 이러한 관계는 데이터 모델이 아직 덜 완성된 모습이라고 할 수 있다. 그래서 M:M 관계는 최종적으로 완성된 데이터 모델에는 존재할 수 없는 형태라고 할 수 있다.

• 실제 업무 중 대부분은 M:M 관계이다. 즉, 기업이 관리하고 있는 많은 데이터 중에서 기업의 업무 내용에 해당하는 데이터가 이러한 M:M 관계로 표현되고 향후에 모델링이 더 진행됨에 따라 이것 이 해소된다.
• 키 엔터티와 키 엔터티 간에는 대부분 M:M 관계이다. 그래서 데이터 모델 상세화 단계에서 이러한 M:M 관계가 해소되면서 액션 엔터티가 새롭게 도출되기도 한다.
• 지속적으로 발생되는 대다수의 엔터티는 M:M 관계이다. 즉, 기업의 업무 내용을 관리하는 데이터는 대부분 이러한 관계에 의해서 생겨난 엔터티라고 볼 수 있다.

M:M 관계 해소의 의의

M:M 관계는 불특정 관계로도 알려져 있으며, 데이터 구조에 있어서 어떠한 실제적 방법으로도 구 현이 불가능하다. 이것이 이 관계를 해결하는데 충분한 이유이지만, 데이터 모델 구축 작업 초기에 그렇게 하는 데에는 또 다른 동기가 있다.

• M:M 릴레이션십은 새로운 릴레이션 엔터티를 추가하여 M:1 관계로 변경한다.
• 연관 실체(associative, relational) 엔터티는 M:M 관계 미결 시 간과해 버렸을 추가 업무 규칙 또는 업무 논리를 내포할 수 있다. 특히 업무 규칙이 정밀하게 정의됨에 따라 하위 유형(subtype)계층 구조가 연관 실체로부터 나타나기 쉽다는 점, 분석 초기에 M:M 관계가 해결되지 않은 모델에서 이들이 간과된다는 점이다.
• M:M 관계는 데이터 종속성에 대한 결정을 어렵게 하여, 모델의 논리적 완성과 부분집합 식별 능력을 제한한다.
• M:M 관계 해결시까지 모델은 불안정 상태에 머물 것이다. 모델은 정규화되지 못하고, 모델에 대한 문서화 작업도 완비되지 못할 것이다.
• [그림 4-3-13]에서와 같이 제품 엔터티와 공급자 엔터티 간에는 M:M 관계가 존재한다. 이 관계는 제품 공급이라는 업무 내용에 의해서 두 엔터티 간에 생겨난 M:M 관계이다.
• 이 관계가 해소된 결과로 공급제품목록이라는 새로운 엔터티가 만들어지고 또한 각각의 두 엔터티 즉 제품, 공급자와 1:M 의 관계를 부모로서 가지게 된다.

참조무결성 규칙 정의

• 관계 테이블의 모든 외부 식별자 값은 관련 있는 관계 테이블의 모든 주 식별자 값이 존재해야 한다.
• 실체의 주 식별자(PK)와 마찬가지로 외부 식별자(FK)도 데이터 무결성에 관한 업무 규칙을 내포하고 있다.
• 데이터베이스 설계 관점에서 선택하지 말고, 사용자의 업무 규칙에 따라 적절한 규칙을 선택한다.

입력 규칙

자식 실체의 인스턴스(Instance)를 입력할 때 참조무결성 규칙의 종류는 다음과 같다.

1) Dependent

대응되는 부모 실체에 인스턴스가 있는 경우에만 자식 실체에 입력을 허용한다.

2) Automatic

자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 이를 자동 생성한다.

3) Nullify

자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 자식 실체의 참조키 (FK)를 Null 값으로 처리한다.

4) Default

자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 참조키(FK)를 지정된 기본 값으로 처리한다.

5) Customized

특정한 검증 조건이 만족되는 경우에만 자식 실체 인스턴스의 입력을 허용한다.

6) No Effect

자식 실체 인스턴스의 입력을 조건 없이 허용한다.

삭제 규칙

부모 실체의 인스턴스를 삭제할 때(또는 그것의 주 식별자를 수정할 때) 사용되는 무결성 규칙은 다음과 같다.

1) Restrict

대응되는 자식 실체의 인스턴스가 없는 경우에만 부모 실체 인스턴스 삭제를 허용한다.

2) Cascade

부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스를 자동 삭제한다.

3) Nullify

부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스가 존재하면, 그것의 참 조키(FK)를 Null 값으로 수정한다.

4) Default

부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스가 존재하면, 그것의 참 조키(FK)를 기본 값으로 수정한다.

5) Customized

특정한 검증 조건이 만족되는 경우에만 부모 실체 인스턴스의 삭제를 허용한다.

6) No Effect

부모 실체 인스턴스 삭제를 조건 없이 허용한다.