11.23
주요뉴스
뉴스홈 > 종합/정책
데이터 아키텍처 솔루션 3회-기본 논리적 데이터 모델링①이화식 대표이사 엔코아정보컨설팅
데이터 아키텍처 솔루션 3회-기본 논리적 데이터 모델링①

데이터 아키텍처 솔루션 3회
기본 논리적 데이터 모델링 ①

이화식 대표이사 엔코아정보컨설팅


연/재/목/차
1회 데이터 아키텍처(11월호)
-전사적 아키텍처
-데이터 아키텍처의 개념
2회 실전 데이터 모델링 개론(12월호)
- 데이터 모델링의 접근
- 실전 데이터 모델링의 개요
3회 기본 논리적 데이터 모델링① (이번호)
- 엔터티(Entites)의 정의
- 릴레이션쉽(Relationship)의 정의
- 속성의 정의
4회 기본 논리적 데이터 모델링② (2004.2월호)
- 식별자 확정
- 데이터 아키텍처 솔루션 II 미리보기







이 글은 DB 바이블로 불리는 '대용량 데이터베이스 솔루션1, 2'로 널리 알려진 이화식 엔코아정보컨설팅 대표가 최근 내놓은 국내 최초의 데이터 아키텍처 전문서인 '데이터 아키텍처 솔루션1'을 요약 정리한 것이다. 전사적 기업 데이터의 혁신으로 불리며 이미 구미 각국에서 차세대 데이터 산업의 핵심축으로 자리잡고 있는 'DA'의 정확한 의미와 가치를 조명하고, 앞으로 지향해야 할 구체적인 방향 등을 적극적으로 제시하고 있다.<편집자>

건물을 세울 때 그러하듯이 먼저 골조부터 단단히 세우는 작업은 매우 중요하다. 골조는 크고 무겁지만 다행히 종류는 그리 많지 않다. 그 대신 견고하게 세워지지 않으면 매우 부실한 건물이 만들어질 것은 자명한 일이다. 기본 논리적 데이터 모델링에서는 이러한 골조를 튼튼하게 세우는 일을 한다.
골조를 구성하는 세가지 요소인 '엔터티(entity)', '릴레이션십(relationship)', '속성(attribute)'의 구체적인 정의를 통하여 업무의 베일이 조금씩 벗겨져 가면 데이터 모델은 드디어 그 웅장한 모습을 우리 앞에 드러낼 것이다.

앞서 한번 언급한 적이 있었지만 기본 논리적 데이터 모델링에는 개념적 모델을 작성하는 과정을 포함하고 있다. 주요 엔터티에 대해서만 먼저 엔터티를 정의하고 이를 릴레이션십을 이용해 연결하는 것까지를 개념적 모델링으로 본다면, 거기에 속성들을 넣고 세부적인 속성 검증단계를 거치면서 좀더 구체화 시켜 나가며, 여기에 식별자를 확정하고 사례 데이터 작성을 통해 검증하는 것까지를 기본 논리적 데이터 모델링으로 본다. 단계를 굳이 이렇게 나누는 것은 개념적 모델링까지의 결과는 너무 개략적이고 논리적 모델링이 완료되는 것까지는 너무 상세하기 때문에 그 중간단계가 필요했다고 생각하면 이해가 쉬울 것이다.
물론 개념적 모델을 좀더 깊이 들어가 속성과 식별자까지도 확정하기로 하였다면 기본 논리적 데이터 모델링과 동일하다. 개념적 모델링과 기본 논리적 모델링의 공통적인 면은 둘 다 주요 엔터티만을 대상으로 한다는 것이다.

제 1 장 엔터티(Entites)의 정의

엔터티는 데이터 모델링에서 가장 중요한 요소라고 할 수 있다. 엔터티를 우리말로는 '실체(實體)'라고 번역하고 있다. 말 그대로 '실질적으로 육체를 가지고 있는 것'을 의미한다. 만약 이 실체가 모호하다면 그 다음 과정이 아무리 완벽하다고 하더라도 모델링은 전체가 모호한 모습일 수 밖에 없다.
이 장에서는 엔터티를 보다 쉽게 도출하고 전략적인 판단을 해 가는 구체적인 단계와 객관적인 판단의 근거를 매우 상세하게 설명할 것이다. 엔터티는 매우 명확하게 정의해야 한다고 했다.

이처럼 데이터 모델링에서는 실체 집합인 '엔터티'를 정확하게 도출할 수 있는 것이 무엇보다도 중요하다. 잘못된 실체를 가지고 아무리 집을 지어본들 그것은 단지 사상누각에 불과할 것이다. 그러나 앞서 강조했듯이 어떻게 정의를 했건 틀렸다고는 말할 수 없으므로 오히려 '얼마나 합리적이고 전략적인 것을 생성하느냐에 대한 문제'는 보다 높은 차원의 문제이기 때문에 이해시키기도, 익혀서 활용하기에도 결코 쉽지 않을 것이므로 여러분은 바짝 긴장하여야 할 것이다.

이 장에서는 엔터티 후보의 수집부터 시작하여, 복잡성에 빠지지 않고 순서에 입각한 접근을 하기 위해서 엔터티를 분류하는 방법, 그리고 엔터티의 최종 확정을 위한 구체적인 절차와 객관적인 판단 기준을 제시하게 될 것이다.

1.1 엔터티 후보의 선정
엔터티를 선정하기 위해서 우리가 가장 먼저 해야 할 일은 엔터티 후보부터 수집하는 일이다. 이 과정은 우리가 업무에 무지한 상태에서 데이터 모델링의 첫 발을 내 딛는 단계이므로 깊은 업무 지식 없이도 충분히 수행할 수 있는 구체적인 방법이 제시되어야 할 것이다.
주의해야 할 것은 이 단계는 말 그대로 '후보'를 찾아 내려는 것이지 엔터티를 확정하자는 것이 아니므로 후보의 '자격 여부'만 가려 내는 선에서 멈출 수 있어야 한다는 것이다. 그렇지 못하면 앞서 강조했던 '수평적 사고'를 할 수가 없다.

1.1.1 엔터티 후보의 수집
엔터티 후보를 수집하기 위해 가장 먼저 우리가 시도해야 할 일은 어디서부터 후보를 찾기 시작할 것인가를 결정하는 일이다. 엔터티 후보를 수집할 수 있는 방법은 매우 다양하게 존재한다. 만약 기존 시스템이 있었다면 '시스템 다큐먼트(document)'가 있을 것이고, 현업에서 사용하는 각종 장표들, 현업 사용자와의 인터뷰를 통해서 후보를 찾을 수도 있겠고, 관련 서적을 통할 수도 있을 것이다.

만약, 우리가 프로세스 모델링을 먼저 수행하여 자료흐름도가 나와 있다면 그 속에 있는 자료저장소(data store)나 객체지향 모델링에서 나타난 클래스는 훌륭한 엔터티 후보가 될 수 있다. 뿐만 아니라 혹시 타사 혹은 유사 시스템의 자료를 확보하고 있다면 거기에서도 많은 후보들이 나타날 것이며, 현업 담당자들이 기안한 각종 보고자료에서도, 또는 현장에 가서 직접 업무를 조사해 보는 방법도 있을 것이다.

엔터티 후보의 식별
엔터티 후보의 식별을 위해서는 다음 세가지 단계를 검증함으로써 객관화가 가능하다. 첫 번째는 '엔터티의 개념'을 확실하게 정립하는 것이며, 두 번째는 '우리가 관리하고자 하는' 것인지를 따져 보는 것이다. 마지막 세 번째는 '가로와 세로를 가진 면적(집합)'인지를 확인하는 것이다.

엔터티 후보의 개념 정립

엔터티 후보로서 검토해 볼 대상의 최초 상태는 한낱 '단어'에 불과하다. 단어란 단지 사전적인 의미에 지나지 않으므로 우리는 이 단어가 의미하는 진정한 집합이 무엇인지 정의하여야만 한다.

관리 대상 후보의 선정
엔터티 후보로 선정하기 위해 할 첫 번째 작업은 과연 이것이 '우리가 관리하고자 하는' 대상이 맞는지를 확인하는 일이다. '우리가 관리하고자 하는'이란 의미는 앞으로 우리가 모델링을 하면서 던지는 모든 질문에 반드시 기본적으로 포함되어야 하는 '주어부(主語部)'에 해당하는 구문이다. 또한 이 말에는 "우리가 현재 관리하고 있느냐?" 뿐만 아니라, "우리가 앞으로는 관리해야 하지 않느냐?"라는 질문을 모두 포함하고 있다.
1.2 수집된 엔터티의 분류

우리는 이제까지 엔터티 후보들을 먼저 골라내고, 개념을 명확하게 한 다음 객관적인 잣대에 의한 자격 검증을 거쳐 엔터티 후보들을 선정하여 두었다. 그러나 이렇게 결정한 것들은 단지 엔터티의 후보에 불과할 뿐 아직 최종적으로 확정된 엔터티는 아니다. 이 엔터티 후보들은 앞으로 훨씬 정교하게 좀더 다듬어져야 하며, 자신의 출생의 비밀이 정확하게 밝혀져 있어야 한다.

첫 번째 단계는 우선적용 대상을 분류하는 것이고, 두 번째 단계는 첫 번째 단계에서 선별한 핵심 엔터티들을 대상으로 이를 데이터 영역별로 분류하는 것이다. 엔터티를 접근형태별로 분류하는 이유는 골조자재에 해당하는 엔터티와 기타 자재에 해당하는 엔터티로 분류하여 중요도와 접근단계에 따라 순차적으로 접근하도록 함으로써 우리가 보다 손쉽게 모델링을 할 수 있도록 하자는 것이다.

1.2.1 키이(key) 엔터티

키이 엔터티란 '태초부터 창조된 실체'를 말한다. 다시 말해서 자신의 부모를 가지지 않는 엔터티를 말한다. 여기서 부모 엔터티란 자신을 태어나게 한-만약, 이 엔터티가 없다면 논리적으로 자신이 태어날 수 없는-엔터티를 말한다. 예를 들어 사원 엔터티에 있는 '홍길동'이란 개체는 아직 부서가 정해지지 않았더라도 사원으로서 정의하는데 문제가 없다. 물론 부서 엔터티와 관계를 정의할 때 반드시 부서를 갖도록 하는 규칙을 부여할 수도 있겠지만 그렇다고 해서 부서가 직접적으로 사원을 태어나게 한 부모인 것은 결코 아니다.
키이 엔터티는 앞장에서 몇 번 언급했던 '개체형 집합'과 동일한 개념으로 키이 엔터티는 매우 명확하고 구체적인 정의가 필요하며, 이는 모델링에 있어서 지극히 중요한 일이다.

1.2.2 메인 (main) 엔터티

키이 엔터티를 제외한 다른 모든 엔터티들은 창조물(?)이 아니기 때문에 당연히 부모 엔터티를 가지고 있어야만 태어날 수가 있다. 그러나 그들 간에도 상하관계가 존재하는데 이 중에서 업무의 중심이 되고 많은 하위 엔터티를 창조하는 엔터티가 메인 엔터티이다. 메인 엔터티는 키이 엔터티에 붙어 있는 바로 아래 단계만을 의미하는 것이 아니라는 것이다. 여러 계층에 존재할 수 있으며 어느 대까지를 메인 엔터티로 볼 것인지 판단하는 것이 중요하다.

1.2.3 액션 (action) 엔터티

액션 업무가 수행되면서 발생한 액션 엔터티가 먼저 눈에 보이게 된다. 액션 엔터티는 수행된 업무를 담고 있으므로 중요도를 가지고 따진다면 물론 가장 중요하다고 할 수 있다. 그러나 이들은 반드시 부모를 가져야만 하는 스스로는 결코 태어날 수가 없는 것들로 이 중요한 것들을 제대로 정의하기 위해서는 그들을 낳을 부모들부터 먼저 정확하게 정의해야 하는 것이 일의 당연한 순서일 것이다.

1.3 엔터티의 명확화

엔터티를 명확화 한다는 것은 엔터티 집합의 내용물을 보다 구체화 한다는 것, 다시 말해서 엔터티 내에 들어 가는 개체들의 의미나 세부적인 구성집합을 매우 상세하게 정의한다는 것을 의미한다. 우리가 정확한 판단을 하기 위해서 가장 먼저 준비해야 할 것은 판단하고자 하는 대상을 분명하게 하는 것이다. 모호한 것을 평가한다면 필연적으로 모호한 결과밖에 얻을 수 없기 때문이다. 엔터티의 명확화를 진행해 가는 단계와 구체적인 접근 방법에 대해서 자세하게 알아 보기로 하자.

1) 데이터 영역별로 분류된 엔터티 후보들 중에서 대표적인 것을 먼저 선택하라.
2) 일단 선택된 엔터티에 일차적인 개념(동질성의 범위를 결정)을 정의하라.
3) 정의한 엔터티 개념을 가장 합리적으로 표현할 수 있는 명칭을 부여하라.
4) 엔터티 후보의 집합에 대한 순수성을 확인하라.
5) 같은 데이터 영역에 있는 유사 엔터티 후보들과 비교하여 개념을 확정하라.
6) 개념이 확정되었으면 엔터티 속에 들어가는 구체적인 부분집합을 명시하라.
7) 엔터티 정의서에 구체적인 내용을 기술하라.

엔터티 명확화에서는 이를 위해 가장 먼저 집합의 순수성을 확인하여 우리가 관리할 순수 집합을 도출한다. 집합의 순수성이란 엔터티는 반드시 순수한 개체집합이든지, 순수한 행위집합이어야 한다는 것을 말한다.
이러한 조건을 통과한 집합은 이제 그 집합의 동질성 정의를 분명히 함으로써 내용물의 성격을 명확히 하게 된다. 물론 동질성은 필요에 따라 의미를 포괄적으로 크게 잡을 수도 있고, 엄격하게 제한하여 작게 부여할 수도 있다. 여기서 어떤 크기가 좋으냐를 따질 필요는 없지만 크든, 작든 반드시 그 정의만큼은 분명해야 나중에 확정 단계에 가서 확신에 찬 최종 결론을 내릴 수가 있다.

1.4 엔터티의 형태 확정

지금까지 우리는 후보를 도출하고 이를 분류하여 일차 대상을 선정한 후 이들을 명확화 하기 위해 집합의 순수성을 확인하고, 동질성 확정을 통해 엔터티의 집합의 의미를 규명하여 합리적인 명칭을 부여함으로써 엔터티를 명확하게 한 후 이를 토대로 유사 엔터티와 비교를 통해 서로 간의 집합적 역학관계를 조정함은 물론 엔터티 내부의 상세한 부분 집합을 정의해 두었다. 사실 여기까지의 모든 작업을 마쳤다면 엔터티의 결정은 모두 마무리 된 것처럼 보인다. 하지만 아직도 우리가 해야 할 일이 몇 가지 더 남아 있다. 그것은 자체적으로 확정해 둔 엔터티의 위상이 주변의 다른 엔터티가 확정되어 가면서 어쩔 수 없이 영향을 받기 때문이다.

이제 주변의 유사 엔터티들을 구체적으로 확정하는 작업이 진행되면 상호 간에 어느 정도의 영향력을 미칠 수 밖에 없으며, 이것을 적절하게 감안하여 엔터티의 정의를 보완하는 작업이 있어야만 한다는 것이다. 엔터티의 보완은 크게 분리와 확장의 두 가지 유형으로 나눌 수 있다.
앞서 동질성을 설명할 때 집합이란 그 동질성을 어디까지 인정하느냐에 따라 여러 가지 형태의 집합이 만들어 질 수 있다고 했다. 이 말은 적어도 엔터티의 좋고 나쁨을 따지지 않는다고 가정한다면 집합을 어떤 형태로 잘라내었든 그 단위 집합이 명확하기만 하다면 충분히 하나의 엔터티로 볼 수 있다는 것을 의미한다. 문제는 그렇게 정의한 단위 집합(엔터티)이 얼마나 합리적이냐에 있다는 것에 있다.

이 말은 결국 우리의 판단이 그만큼 전략적이고 합리적이어야 한다는 것을 의미한다. 다시 말해서 단순한 공식이나 방법에 의해서 결정될 수 있는 성질의 것이 아니라 종합적인 사고력과 판단력의 산물일 수 밖에 없다는 점이다. 그렇기 때문에 어쩌면 이 단계가 모델링에서 가장 이해하기 어렵고 판단하기 곤란하며, 또한 모델링의 품질에 가장 큰 영향을 미치는 단계라고 할 수도 있다.

엔터티를 전략적으로 판단할 수 있는 힘을 키우기 위해서는 단지 방법과 수칙만을 암기한다고 해서 가능한 것은 결코 아니다. 앞으로 제시할 판단의 기준들을 깊이 이해하고 이를 바탕으로 많은 경험을 쌓아 복잡한 상황에 종합적으로 대처할 수 있는 판단 능력을 키워 나가는 방법밖에 없다는 것을 명심하기 바란다.

1.5 본질 식별자의 확정

엔터티 정의 단계에서 여러분들이 엔터티의 의미를 명확하게 정의했다면 최소한 그 속에 어떤 유형의 개체들이 들어가야 하는지에 대해서 만큼은 분명하게 밝혀졌을 것이다. 사실 지금까지 우리가 엔터티의 집합의 개념을 명확하게 하기 위해서 실시한 작업은 주로 그 내부의 세부적인 부분집합을 규명하는 일이었다.
다시 말해서 어떤 내용의 개체들이 존재하고 있는지를 분명히 하는 작업이었다. 이것은 물론 매우 중요하다. 그러나 사실은 이것보다 먼저 각 개체들이 어떻게 해서 태어났는지를 분명히 밝히는 것이 우선적으로 필요하다. 물론 이러한 사실은 앞에서 이미 언급했었고, 누차에 걸쳐 강조했었다.

여러분들은 앞서 '의미상의 주어'에 대한 것과 '출생의 비밀을 벗기는 일'에 대해서 언급하면서 장차 별도로 상세하게 설명하겠다는 약속을 기억하고 있을 것이다. 바로 여기에서 이들을 구체적이고 객관적인 방법을 통하여 규명하는 방법을 다루려고 한다. 단지 책의 구성상 여기서 설명하는 것일 뿐 앞장에서 설명한 엔터티 정의가 모두 완료된 후에 본질식별자를 확정하라는 것은 결코 아니므로 오해가 없기를 바란다.

한 가지 더 유의할 점은 여기서는 단지 최종적인 식별자를 확정하려는 것이 아니라 원래 의미상의 식별자인 본질 식별자를 분명하게 정의하려고 한다는 것이다. 엔터티의 최종 식별자를 확정하기 위해서는 앞으로도 더 많은 시간이 흘러야만 한다. 왜냐하면 최종 식별자는 자신을 대표(식별)한다는 사실 이외에도 남이 나를 불러(참조, 릴레이션십) 줄 때 사용해야 하는 것이기 때문이다. 즉, 비록 내 이름은 '나의 것'이 분명하지만 내가 나를 부를 때가 아니라 남이 나를 부르기 위해 사용하는 것이므로 나를 불러줄 주변 엔터티가 모두 등장한 후에 확정하는 것이 바람직하기 때문이다.

이런 이유로 인해 확정 식별자를 결정하는 단계는 대부분의 엔터티가 정의된 후에 실시한다. 나를 불러 줄 주변 엔터티가 아직 정의되지 않았는데 그들을 무시하고 나만의 입장에서 독선적으로 결정하는 것은 결코 좋은 방법이라 할 수 없다. 우리가 조직의 대표를 선출할 때에도 많은 심사숙고를 해야 하듯이 엔터티를 대표할 식별자를 결정하는 일은 매우 종합적이고 전략적이어야 한다. 설사 논리적인 형태가 복잡한 데이터 모델이라 하더라도 이 전략의 합리성에 따라 실제로 일어나는 액세스는 단순하게 만들 수도 있는 정말 중요한 단계이다 .

이런 중차대한 결정을 주변의 고려 요소가 모두 등장하지 않은 상태에서 어찌 함부로 정의할 수가 있겠는가? 그렇기 때문에 아무리 마음이 급하더라도 아직은 때가 도래하지 않았기 때문에 이제 최종 식별자에 대한 생각은 잊어 버리고 지금은 오로지 자신의 출생에 대한 비밀을 밝히는 데만 주력하기로 하자.
본질 식별자를 정의하는 방법은 키이 엔터티와 행위 엔터티가 서로 다르다. 행위 엔터티를 정의하는 방법에는 상황에 따라 '하향식'과 '상향식'으로 접근하는 방식을 적용할 수 있다. 키이 엔터티는 부모가 없이 창조된 집합이므로 식별자 또한 창조시켜 주어야 한다. 그러나 행위 엔터티는 항상 부모가 누구인지를 확인하는 방식으로 진행된다.

1.6 유형별 엔터티 표현방법

지금까지 우리가 정의해 왔던 엔터티들을 목적이나 용도, 혹은 뚜렷한 특징들을 나타내기 위해 형태별로 구분해 둘 필요가 있을 것이다. 세상(데이터 모델)에는 그 주체가 되는 인간(엔터티)이 존재한다. 인간에게 존재하는 이러한 유형들이 엔터티에서도 거의 유사하게 존재한다. 살아 있는 정상적인 사람들을 일반(normal) 엔터티, 마치 식물인간처럼 앞으로 다른 것으로 대체를 하거나 통합시키기 위해 아직은 없애지 않고 남겨 두었지만 삭제한 것이나 다름없는 의미의 제거(drop) 엔터티, 외계에서 온 우주인과 유사한 외부(external) 엔터티, 만화의 주인공과 비슷한 가상(pseudo) 엔터티, 손오공의 분신술로 만든 복제(clone) 엔터티, 역할을 대신하기 위해 존재하는 대체(代替, substitute) 엔터티, 임신 중이기는 하지만 곧 세상에 태어날 준비를 하고 있는 의미인 추가(additional) 엔터티로 분류할 수 있겠다.

이와 같은 여러 유형의 엔터티를 적절하게 분류해서 지정해 두는 것은 여러 가지의 의미를 가진다. 가령, 데이터 모델을 보다 정밀하게 표현할 수 있고, 남들이 모델을 좀더 정확하게 이해하는데 기여할 수 있으며, 모델링 진행과정에서 작업 대상을 식별하거나 진행관리를 할 수 있다는 부가적인 장점도 있으므로 많이 활용할 필요가 있다.

이와 같은 여러 유형의 엔터티를 적절하게 분류해서 지정해 두는 것은 여러 가지의 의미를 가진다. 가령, 데이터 모델을 보다 정밀하게 표현할 수 있고, 남들이 모델을 좀더 정확하게 이해하는데 기여할 수 있으며, 모델링 진행과정에서 작업 대상을 식별하거나 진행관리를 할 수 있다는 부가적인 장점도 있으므로 많이 활용할 필요가 있다.

1.6.1 제거(drop) 엔터티

제거 엔터티를 남겨두는 이유는 마치 여러분이 개인용 컴퓨터에서 파일을 삭제시키면 원래의 디렉토리에서는 삭제되지만 '휴지통'에 들어가 있음으로써 이를 복원하거나 내용을 참조해 보거나 영구히 삭제시킬 수 있는 기회를 제공해 주려고 배려를 하는 것과 같은 이유라 할 수 있다.
이미 나름대로의 확실한 역할을 하고 있던 어떤 존재가 갑자기 혼자만 함부로 사라질 수는 없기 때문에 설혹 제거를 하겠다고 하더라도 잠정적인 삭제 상태로 만들어 두고, 주변 관계를 말끔하게 정리한 후에야 원하는 대로 사라지게 하여야 할 것이다.

엔터티를 제거 상태로 표시하게 되는 또 하나의 활용 형태를 생각해 보자. 제거 엔터티란 의미는 앞으로 없애 버릴 엔터티를 표시해 두겠다는 것이다. 이 말은 곧 ERP패키지의 데이터 모델을 커스터마이징할 때나 리버스 모델링을 하여 만들어진 현행(as-is) 데이터 모델에서 새로운 목표(to-be) 데이터 모델을 결정해갈 때 앞으로는 사용하지 않고 버리겠다는 의사표시로도 활용할 수 있다는 것을 말한다.

1.6.2 외부(external) 엔터티

'외부'라는 말은 자기 집합을 제외한 나머지란 의미를 가지고 있다. 즉, 외부라는 집합을 정확히 정의하기 위해서는 먼저 내부 집합이 구체적으로 정의되어야 함을 뜻한다.

사실 일견 당연해 보이는 이 개념은 보는 사람의 시각에 따라 다를 수가 있다. 가령, 회사 전체 시스템을 내부로 보고 타사에 있는 개념적인 집합들을 외부로 볼 수 있는 방법이 있다. 회사 내에서도 OLTP, DW, 혹은 계정계, 정보계라는 이름으로도 시스템을 구분해 볼 수 있다. 아니면 H/W환경이나 DBMS에 따라 별도의 시스템으로 구분하는 방법도 있을 것이다. 또한 협의로 본다면 같은 OLTP내에서도 '인사, 회계...'와 같이 서브시스템별로 나눈 각각을 내부로 생각할 수도 있다.

그러나 외부 엔터티란 우리 중의 누구도 관리하거나 책임질 필요가 없으며, 우리가 관리하는 어떤 ERD에서도 소유주가 존재하지 않는 그야말로 우리가 아닌 제3자가 관리하는 엔터티란 의미가 숨어 있다. 이 외부 엔터티는 우리가 소유하고 있는 엔터티가 아니므로 나중에 구현 단계에 가서라도 직접 릴레이션십을 가지고 액세스 할 수 없는 엔터티라는 의미도 같이 포함되어 있다.

1.6.3 가상(pseudo) 엔터티
가상 엔터티란 말 그대로 상상 속에서 존재한다는, 다시 말해서 개념적으로만 존재하는 엔터티를 말한다. 우리가 사는 세상에도 따지고 보면 물리적으로 공간을 차지하고 있지는 않지만 개념적으로만 존재하는 것들이 생각보다 매우 많이 있다. 반드시 눈으로 보여져야, 손으로 만질 수 있어야 존재하는 것은 아니다.

1.6.4 대체(substitute) 엔터티
대체 엔터티란 야구에서 사용하는 '대타'나 '대주자', 혹은 조립공정을 가진 생산라인에서 주로 사용하는 '대체 자재'라는 개념과 매우 유사하다. 이들이 가지고 있는 공통적인 특성은 동일한 하나의 역할을 위해서 한 가지 이상의 실체가 존재할 수 있다는 것이다.

대체 엔터티 - 대안수립용
가령 A~I까지 9개의 엔터티로 구성된 데이터 모델이 있다고 가정해 보자. 그런데 A엔터티 대신에 A´로 하는 것도 생각해 볼 수 있고, B엔터티를 B´로 하는 경우에 대해서도 충분히 검토할 가치가 있다고 가정하자. 대신 생각을 단순하게 하기 위하여 나머지 7개의 엔터티는 복수안이 없다고 가정한다. 그러나 이처럼 단 2개의 엔터티가 복수안을 가지고 있다고 하더라도 우리는 총 4벌의 ERD를 추가로 그려야 각각의 경우에 대비할 수 있다.

엔터티가 단 9개뿐인 ERD 에서 2개 엔터티만 복수안을 가지고 있어도 이러할진대 수백 개의 엔터티를 가지고 있으면서 수십 개의 엔터티가 여러 개의 대안을 가지고 있다면 도대체 몇 벌의 ERD가 필요하겠는가?
이와 같은 경우 대표되는 9개의 엔터티를 선정하고, A' 및 B'는 대안으로서 관리하면 한벌의 ERD만 가지고서 각각의 경우에 대처 할 수 있을 것이다.

대체 엔터티 - 엔터티 형태 일부 조정 시
어떤 논리적 모델링을 가지고 다음 단계인 데이터베이스 설계 단계에서 분산 시스템으로 설계하여야 한다고 가정해 보자. 데이터베이스 설계 단계에서는 시스템의 물리적인 요소들을 감안해야 하고 해당 노드의 특성도 반영되어야 하므로 그림 우측처럼 각 노드별로 가져 갈 속성과 개체집합의 범위가 서로 다르게 결정되기로 했다고 가정하자.
이때 우리가 취할 수 있는 방법은 크게 두 가지가 있다.
첫 번째 방법은 데이터 모델에서는 하나의 엔터티만 정의하고 데이터베이스 설계 단계에서 노드별로 서로 다르게 테이블을 정의하는 것이다.

두 번째 방법은 지금 설명하고자 하는 대체 엔터티를 활용하는 방법이다. 데이터 모델링 단계에서 미리 각 노드별 특성을 감안하여 각 노드별로 대체 엔터티를 메달아 두는 방법이다. 이 대체 엔터티는 원래의 엔터티와 동일한 집합일 수도 있지만 자기만 필요한 속성(가로)과 개체(세로)들로 구성할 수가 있다.

마찬가지로 방법으로 우측 하단에 있는 대체 엔터티는 요즈음 고객관리를 위해 많이 활용하고 있는 콜센터나 고객지원센터 시스템에서 발생할 수 있는 예제이다. 대부분의 회사에는 이처럼 이미 특수한 목적을 위해 존재하는 시스템이 있는데 대개의 경우 기존과는 조금 다른 아키텍처로 구축되어 있는 경우가 많다. 물론 새로운 통합 데이터 모델을 사용하도록 시스템을 변경할 수도 있겠지만 만약 특별한 제한요소가 있다면 어쩔 수 없이 그들만의 고유한 엔터티를 생성할 수 밖에 없을 것이다. 이러한 경우에도 별도의 ERD 를 작성할 필요 없이 대체 엔터티를 활용함으로써 쉽게 해결할 수 있다

1.6.4.3 대체엔터티-서브타입의 상세표현

이 활용 형태는 데이터 모델을 좀더 명확하게 표현하기 위해 여러 각도에서 바라 본 모습을 각기 다른 엔터티로 그려 볼 때 활용하는 방법이다. 물론 우리는 서브타입세트를 이용하여 하나의 엔터티 내에서도 여러 차원에서 바라 본 데이터 모델을 그려낼 수가 있다. 사실 서브타입세트를 이용하여 여러 각도에서 바라 본 집합의 형태를 표현하는 경우는 다음과 같은 상황일 때 가장 적절하다. 즉, 가장 대표적인 서브타입세트로 전체를 표현했지만 그 중에서 일부분에 대해서는 좀더 상세하게 보강하여 표현하고 싶을 때 이러한 부분만 강조한 서브타입세트를 그리고자 하는 경우이다.

이와는 다르게 만약 모든 유형의 서브타입세트마다 전체 집합을 나타내려 한다면 불가능하지는 않지만 그림이 너무 복잡해지게 될 것이다. 이러한 경우 대체 엔터티를 사용하면 매우 쉽고 단순한 모양으로 표현할 수 있다. <그림: 대체 엔터티-서브타입의 상세표현>은 이런 경우에 대체 엔터티를 사용한 사례를 보여주고 있다.

그림에는 나타나 있듯이 서브타입세트에 따라 데이터 모델을 바라 본 모습이 서로 다른 것을 발견할 수 있다. 각 속성들의 위치 - 즉, 슈퍼타입이나 서브타입에 대한 소속 - 가 서로 달라질 수 있으며, 속성에 붙어 있는 선택사양은 물론 릴레이션십 또한 들어오고 나가는 위치가 서로 다르게 표현된다는 것을 알 수 있다.

1.6.5 추가(additional) 엔터티

추가 엔터티를 활용하는 경우는 크게 세 가지로 나눌 수 있다.
첫 번째는 리버스 모델링에서 현재(as-is) 시스템에는 없지만 리버스를 하는 과정에, 혹은 논리화를 하는 과정에서 앞으로 있어야 할 것으로 예상되는 엔터티가 나타났을 때 이를 일단 정의해 두고 나중에 최종적으로 확정하겠다고 할 때 적용하는 경우이다.

두 번째의 활용 형태는 이미 구축되어 운용되고 있는 시스템의 데이터 모델에 업무의 변화로 인해 데이터 모델의 변경을 시도하는 경우에 활용하는 경우이다. 운용 중인 시스템의 데이터 모델이라면 이미 거기에 있는 엔터티는 확정되어 있는 것들이다. 확정되어 있는 수 많은 엔터티들 사이에 새롭게 정의 - 즉, 추가 - 할 엔터티가 별도의 표시를 가지지 않는다면 뒤섞여 버려서 찾기가 어려워질 것이 틀립없다. 이 엔터티는 아직 완전히 확정이 되지 않았을 뿐이지 결코 가상의 집합이라고는 할 수 없으므로 가상 엔터티와는 별도로 관리해야 한다.

활용 형태의 세 번째는 ERP패키지를 도입하여 우리에게 맞도록 데이터 모델을 커스터마이징하는 경우에 적용하는 경우이다. 즉, 패키지에 원래부터 있던 데이터 모델을 기존의 것으로 보고 우리 업무에 맞도록 새롭게 추가한 엔터티들을 추가 엔터티로 표시하는 방법이다. 적용방법은 다르지 않지만 패키지를 도입할 때는 충분히 의미가 있을 것이다.

제 2 장 릴레이션십(Relationship)의 정의

릴레이션십(relationship)이란 엔터티와 엔터티 사이의 '관계(關係)'를 말한다. 엔터티 정의에서 그랬듯이 많은 판단의 기준이 필요하고, 치밀한 분석과 종합적인 사고력을 필요로 하기 때문에 결코 쉽다고는 할 수가 없다.

논리적으로 생각할 수 있는 관계는 참으로 헤아릴 수 없이 많이 존재한다. 도대체 어떤 것을 취하고, 어떤 것은 버려야 하는가? 별개의 관계로 보아야 하는가, 아니면 같이 묶어서 하나의 관계로 보아야 할 것인가? 심사숙고 끝에 내린 결정에 우리는 얼마나 확신을 가지고 있는가? 아마 여러분은 점차 가슴이 답답해져 오는 것을 느끼고 있을 것이다.

그러나 판단이 어렵고 모호할 것이라는 지레짐작 때문에 미리 겁부터 먹을 필요는 없다. 우리는 릴레이션보다 훨씬 어려운 엔터티에 대해서도 확신을 가지고 정의해 오지 않았던가? 앞으로 우리는 모호한 것들을 구체적이고, 객관적인 것으로 바꾸어 줄 수 있는 많은 판단의 기준과 실사례들을 접하게 될 것이다. 이러한 내용들을 이해하여 완전히 자기의 것으로 소화한다면 확신을 가지고 릴레이션십을 정의하게 될 수 있을 것이라 믿는다.

2.1 릴레이션십의 이해
릴레이션십을 확실하게 정복하려면 먼저 릴레이션십의 정확한 의미를 이해하는 것부터 시작해야 한다.

2.1.1 릴레이션십의 진정한 의미
자신의 의지와는 상관없이 필연적으로 다른 것들과 밀접한 관계를 맺지 않을 수 없다. 건축물에서도 어떤 자재들은 또 다른 자재들과 반드시 연결관계를 가진다. 만약 연결해야 할 나사를 연결하지 않거나, 부실하게 연결한다면 건물은 무너져 버린다. 엔터티와 엔터티 사이를 연결하는 릴레이션십도 이와 별로 다르지 않다. 우리가 정의해 놓은 엔터티들도 이와 같이 혼자서는 결코 존재할 수 없다. 엔터티를 릴레이션십으로 연결을 해 주어야 비로소 데이터 모델이 만들어 질 수 있기 때문이다.
?릴레이션십도 집합이다.
?간접 릴레이션십은 무수히 존재하지만 직접 릴레이션십은 많지 않다.
?관계에는 당사자 간의 관계와 제3자가 보는 관계가 있다.
?관계란 정의하기에 따라 다양하게 존재한다.
?엔터티 정의에 따라 관계는 달라진다.

2.1.2 릴레이션십의 표현
1) 관계형태(degree)
<그림:릴레이션십의 표현> 좌측에 있는 까마귀 발가락(->)처럼 표시된 것은 '하나 이상(多, many)'을 나타낸다. '하나 이상'이란 반드시 하나 이상이 되어야 한다는 것이 아니라, 하나 이상인 것이 적어도 한가지는 존재하고 있다는 것을 의미한다는 것에 주의하여야 한다. 이 말은 1:M의 관계에는 1:1의 관계가 이미 포함되어 있다는 것을 의미하고 있다. 나중에 우리가 관계형태를 규명할 때도 하나 이상인 경우가 한 가지라도 있는지에 대해 집중적으로 검토함으로써 이 관계의 진상(?)을 구체적으로 밝혀낼 수 있다.

그림 우측에 있는 수평선(ㅡ)은 '단 하나(only one)'임을 의미한다. 여기서 수평선이란 실선(ㅡ)이 될 수도 있고 점선(----)으로 표현될 수도 있으며, 이것은 다음에 설명할 선택사양에 따라 결정된다. 단 하나뿐임을 규명하는 것 또한 하나 이상인 경우가 하나라도 존재하는지를 검토함으로써 밝혀 낼 수 있다.

2) 선택사양(optionality)
실선은 '반드시 존재(mandatory)해야 한다(must be)'는 것을 의미하고 점선은 '존재하지 않을(optional) 수도 있다(may be)'는 것을 의미한다. 주로 참조하는 엔터티(M쪽)는 참조되는 엔터티(1쪽)가 반드시 존재해야 하는 경우가 많이 나타나고, 반대로 1쪽 엔터티는 M쪽 엔터티와 반드시 관계를 맺지 않아도 되는 경우가 가장 일반적인 형태라고 할 수 있다.

일반적이란 말은 이러한 경우가 가장 많이 나타난다는 것이지 항상 그러해야 한다는 것을 말하는 것은 아니다. 그렇지만 우리는 모델링에서 가능하다면 실선 관계를 가지도록 - 특히 자식 쪽에서 - 노력해야 한다. 부모 없이 태어난 자식들이 많이 생긴다면, 여러 가지 면에서 혼란이 발생할 수 있는 것처럼 부모 엔터티에 존재하지 않은 자식 엔터티의 개체가 많이 발생한다면 정보의 정합성에 많은 문제점이 나타날 것은 자명한 일이다.

3) 관계명칭

엔터티에는 '엔터티 명칭'이 있듯이 릴레이션십에도 '관계명칭'이 있어야 한다. 엔터티 내의 집합 내용이 구체적으로 정의되고, 그 내용을 함축적으로 표현해야 했듯이 릴레이션십 또한 집합이므로 그 구체적인 정의와 거기에 합당한 명칭이 필요한 것은 너무나 당연하다고 하겠다.
관계명을 표현하는 방법은 제3자 입장에서 표현하는 방법(그림의 관계명3)과 당사자 입장에서 표현하는 방법(그림의 관계명1, 2)이 있다. 방법론에 따라서 제3자 입장에서 표현하는 방법을 사용하거나 당사자 입장에서 표현하는 방법을 사용하고 있다.

여기서 제시하는 방법은 위의 두 가지 방법을 혼용하는 형태를 권장한다. 다시 말해서 상황에 따라서 보다 분명한 표현 방법을 사용하는 것이 가장 좋다는 것이다. 어떤 경우는 제3자 입장에서 표현해 두는 것이 보다 명확할 수도 있다. 가령 '부부' 관계라는 표현이 당사자간에 '남편'과 '아내'로 나누 어 표현하는 것보다 이해하기가 수월하다. '공사'에 관련된 부서가 '공사수행부서'와 '감독부서'가 있다면 참조하는 쪽의 입장에서 표현하는 것이 바람직할 것이다. 릴레이션십이란 사실은 당사자간의 서로 다른 입장에서 바라본 관계를 하나로 합성해 놓은 것을 의미한다. 즉, '남편' 쪽에서 바라본 관계와 '아내' 쪽에서 바라본 관계를 합성함으로써 '부부' 관계가 만들어졌다는 것이다.

그렇지만 같은 내용의 관계를 두 개의 릴레이션십으로 표현한다면 너무 복잡해지고 혼란을 초래하게 되므로 합성하여 하나의 관계로 만들었다고 이해하기 바란다. 작성된 릴레이션십을 당사자 입장에서 구체적으로 이해하고 싶다면, 자기 쪽에 붙어있는 반쪽만 보면 된다. 그림에서처럼 엔터티1의 입장에서 엔터티2를 바라본 릴레이션십은 좌측에 있는 반쪽만 바라보면 엔터티1이 M(any)이고 실선이다. 이것은 엔터티1이 자식이고 엔터티2를 필수적(실선)으로 가져야 한다는 것을 의미한다. 반대로 엔터티2에서 바라보면 자신이 부모쪽이고 엔터티1을 선택적(점선)으로 가질 수 있다는 것을 알 수 있다.

2.1.3 릴레이션십의 다양한 형태

릴레이션십의 형태는 크게 일대일(1:1), 다대일(M:1), 다대다(M:M)의 세 가지로 나눌 수 있다. 물론 선택사양까지 결합하면 훨씬 많은 형태가 나타나겠지만 형태로만 나눈다면 이렇게 세 가지로 분류할 수 있다. 각각의 형태들은 고유한 특징을 가지고 있으며, 각자 가장 흔하게 발생하는 기본형태(default style)를 가지고 있다.

① (1:m) - one to many relationship (both side mandatory)
- 현실 세계에서 그리 많은 경우는 아니지만 가끔 발생하는 형태.
- 주문과 주문 아이템의 관계에서 하나의 주문이 여러 개의 아이템을 포함하고 있는 경우. 주문 아이템이 없는 주문은 업무적으로 의미가 없고 마찬가지로 주문이 없는 주문 아이템도 의미가 없다.
② (1:m) - one to many relationship (one optional)
- 현실 세계에서 가장 흔한 형태이다.
- 부서와 사원간에 관계에서 모든 사원은 반드시 하나의 부서에 소속되어야 한다. 하지만 사원이 하나도 없는(신생) 부서는 존재할 수 있다.
③ (1:m) - one to many relationship (many optional)
- one to many 관계에서 현실적으로 드문 형태.
- 위의 예는 여러 번의 납품 건에 대해서 한번에 모아 대금청구를 하는 경우이다. 즉 선 납품 후 대금 청구하는 계약조건에서 아직 대금이 청구되지 않는 납품 건은 청구번호가 정해지지 않은 경우이다.
④ (1:m) - one to many relationship (both side optional)
- 이 또한 현실 세계에서 흔한 형태중의 하나.
- 관계의 선택성(Optional)이 증가 할수록 모델의 모호성도 증가하므로 될 수 있으면 선택성을 해소해야 함.
⑤ (1:1) - one to one relationship (both side mandatory)
- 1:1 Mandatory 관계는 실제로 하나의 엔터티가 분리되어 표현된 경우이다. 관계를 맺고 있는 상대 엔터티의 개체 하나에 대해서 항상 대응하는 하나의 개체가 존재한다는 것은 동일한 엔터티를 가독성 및 기타 다른 물리적인 요소를 감안하여 분리한 경우가 대부분이다.
⑥ (1:1) - one to one relationship (one side optional)
엔터티 내의 특정 개체 집합이 별도의 속성을 가지고 있고, 이 집합을 보다 상세히 표현 할 때 사용된다.
⑦ (1:1) - one to one relationship (both side optional)
이와 같은 관계는 두 엔터티는 서로 분명히 다른 개체 이나, 필요에 의해 하나의 개체처럼 간주 될 수 있는 관계, 또는 선택적으로 Only 한 개만 상호간 선택되어 질 수 있는 관계를 나타낸다.
⑧ (m:m) - many to many relationship (both side optional)
m:m 관계는 아직 분석이 완료되지 않은 상태이다. 개념 모델상에서는 존재하지만 상세논리모델링 완료된 이후에는 m:m 관계가 존재하면 않 된다 이러한 m:m 관계는 관계가 해소 되면서 새로운 엔터티 ( Relation Entity / Intersection Entity )를 생성시킨다. 위의 그림과 같이 이 새로 생성된 Relation Entity와 기존 엔터티 사이에는 1:m 관계로 분해된 새로운 관계가 나타난다. m:m 관계를 분해 했을 때 항상 1:m 관계로 분해되는 것은 아니다. 상품과 주문사이의 m:m관계와 같이 때때로 덜 분해된 m:m 관계가 사이에 나타날 수 도 있다. 이 경우 앞의 작업과 동일하게 분해작업을 수행하여 m:m 관계가 완전히 해소될 때 까지 관계를 분해해야 한다.
2.2 릴레이션십 정의 절차

릴레이션십을 찾아내고 정확하게 결정해 낸다는 것은 우리가 앞서 엔터티를 그렇게 했던 것만큼이나 어렵고도 복잡한 작업이다. 엔터티 간에 단 하나씩의 릴레이션십만 가질 수 있다고 가정하더라도 100개의 엔터티 간에는 이미 논리적으로는 10,000가지의 릴레이션십이 존재할 수가 있다고 했다. 실제로는 당연히 하나 이상 존재할 수가 있으므로 논리적으로 존재할 수 있는 릴레이션십은 크게 늘어날 수 밖에 없다.

요즈음 구축되는 대부분의 시스템에서는 엔터티가 아마 백 개 이상은 될 것이다. 대형 시스템이라면 수 천개에 이를 수도 있다. 그렇다면 현실적으로 이들이 만들어낼 수 있는 논리적인 릴레이션십은 도대체 얼마나 되겠는가? 그야말로 천문학적인 숫자가 나타날 것이다. 그럼에도 불구하고 이들을 일일이 검토해서 확신 있는 결정을 도출해 낸다는 것은 참으로 엄청난 작업이고, 막상 어디서부터 손을 써야 할지 막막하기 그지없다.

그러나 논리적으로 존재할 수 있는 경우의 수는 천문학적이지만 릴레이션십을 확정한 다음 살펴 보면, 실제 정의된 릴레이션십의 개수는 그 보다 너무나 적다는 것에 놀라게 된다. 결과적으로 어떻게 보면 우리는 쓸데없이 헛고생을 많이 한 셈이다. 문제 해결의 초점은 명확하다. 우리가 어떻게 접근해야 이러한 비효율적인 과정을 거치지 않을 수 있는지를 고민해야 하는 일만이 남아 있을 뿐이다. 너무 심각하게 생각할 것까지는 없다. 이러한 딜레마에 빠지지 않고 우리가 원하는 릴레이션십을 쉽게 찾을 수 있는 실전적인 방법과 절차가 있다. 먼저 간략하게 이를 위한 핵심적인 전략들을 나열해 보자.

- 릴레이션십 매트릭스(matrix)를 활용한다.
- 엔터티 수가 많다면 분할해서 정복한다.(divide & conquer)
- 제3자 입장에서 직접관계의 유무(有無)만 판단한다.
- 관계가 있다고 판단된 것들에 대해 구체적인 관계명을 정의한다.
- 작성된 매트릭스에서 활동성이 강한 엔터티를 찾아 구도를 잡는다.
- 나머지 엔터티들을 적절한 위치에 넣고 기본적인 릴레이션을 맺는다.
- 당사자 입장에서 릴레이션십을 구체적으로 검증하여 확정한다.
- 표현할 관계명을 최종적으로 확정한다.

2.3 릴레이션십의 실전연구
실전에서 모델링을 하기 위해서는 상황에 따라 미묘하게 달라지는 변화무쌍한 판단의 쟁점들을 합리적으로 정리해 갈 수 있는 힘을 가져야 한다. 이는 마치 바둑책을 열심히 읽고, 많은 정석을 이해했더라도 실전 훈련이 따르지 않으면 결코 고수가 될 수 없는 것과 다르지 않다.
물론 실전력을 향상시키기 위해서는 많은 실전 모델링 경험이 필요하겠지만 먼저 이를 위해 우리가 좀더 깊이 있게 연구해 보아야 할 것부터 알아 보기로 하자.

첫 번째 사항은 매우 치밀한 관계 검증을 할 수 있어야 한다는 것이다. 현실이란 이론적인 것보다 훨씬 복잡·미묘한 요소들을 가득 품고 있다. 대충 수박 겉핥기식으로 접근해서는 결코 파악해낼 수 없는 것들이 무수히 존재한다. 이러한 점을 간과하면 결코 실전적인 데이터 모델을 얻을 수 없기 때문에 이를 위해 우리가 반드시 지켜야 할 몇 가지 주의사항을 강조하고자 한다.

두 번째는 릴레이션십도 일 종의 집합이기 때문에 엔터티의 경우와 같이 어떤 관계를 다른 쪽으로 흡수시켜 버리거나, 별도로 떼어 분리할 수도, 중첩이 되도록 할 수도 있다는 것이다. 물론 어떤 결정을 하더라도 하나의 릴레이션십이 될 수는 있겠지만 그 결정의 적절성에 따라 품질의 차이는 매우 크게 나타날 것이다.
세 번째는 몇 개의 유사한 릴레이션십이 존재할 때 관계형태가 한 단계 위로 상승하도록 통합하는 경우(직렬식)와 이를 별개로 보아 여러 개로 나열하도록 하는 경우(병렬식)에 대한 판단의 기준에 대해 연구해보기로 하겠다.

이러한 결정들은 매우 중요하고 어려우며, 종합적이고 전략적인 판단이 요구되는 부분이다. 다시 말해서 단순히 방법적인 측면으로만 접근해서는 불가능한 부분이기 때문에 지극히 인간적이며, 오직 인간만이 할 수 있는 영역이라 할 것이다.

제 3 장 속성(attribute) 정의

엔터티에서 정의한 개체는 구체적인 집합으로 보이지만 어떻게 보면 매우 추상적이라고도 할 수 있다. 예를 들면 '사원정보' 엔터티의 임의의 개체인 사원 '홍길동'과 '박문수'는 독립적인 사람 개체이다.
이들이 실제로 존재하는 개체임에는 분명하지만 아직은 이 개체의 특성을 관리할 아무런 속성도 정의하지 않은 상태이기 때문에 객관적인 집합이라 하기에는 무엇인가 모호하다. 마치 '홍길동'이란 사람에 대한 구체적이고 객관적인 정보를 대부분의 주변 사람들이 모르고 있었다면 만약 가짜가 나타나서 자기가 '홍길동'이라고 우겨도 이를 변별할 방법이 없다. 그러므로 우리는 '홍길동'이가 도대체 누구인지, 무엇을 하는 사람인지, 무슨 특성을 가지고 있는지 관리해야만 한다.

이와 같이 우리가 관리하고자 하는 엔터티의 개체에 대한 관리항목으로서 어떤 속성들이 필요할 것인가에 대한 결정이 필요하다. 즉, 속성이란 특정한 개체의(사물) 본질을 이루는 고유한 특성이나 성질로서 우리가 정보로서 관리하고자 하는 것이다.

3.1. 속성의 개념 정립
사실 IT에 종사하고 있는 사람들이라면 최소한 속성(attribute)이나 컬럼(column), 혹은 필드(field)가 무엇인지 모른다고 하는 사람은 거의 없을 것이다. 그럼에도 불구하고 조금만 더 깊은 질문을 해 보면 확실하지 않은 답변이 나온다는 것은 참으로 놀라운 일이다.

3.2. 속성 정의 개요
엔터티와 릴레이션십을 정의할 때와 같이 속성을 정의할 때에도 먼저 그 후보들부터 선정하여 두는 것이 올바른 순서일 것이다. 이렇게 일차로 선정된 대상에 대해 누가 보더라도 합리적이라고 인정할 수 있도록 객관적인 평가의 기준을 적용하여 명백한 증거를 토대로 접근해야 확신에 찬 결론을 도출할 수 있다. 이러한 접근은 판단의 오류를 감소시킬 수 있을 뿐만 아니라 진행절차를 단순화 시키고 불필요한 시행착오를 막아 이 단계에 소요되는 시간도 많이 절약할 수 있다.

모델링은 정답을 확인할 수 있는 답안지가 없다고 했다. 결정의 옳고 그름을 알지 못한 채 자꾸만 다음으로 진행해 나간다는 것은 참으로 두려운 일이 라 하지 않을 수 없다. 만약 그 과정이 잘못되어 열심히 고생한 결과가 모두 무용지물이 되었다면 얼마나 안타깝고 속상한 일이겠는가? 사실 속성은 릴레이션십 보다 더 많이 존재한다. 그만큼 우리가 고민할 내용이 많기 때문에 우리가 확실한 판단의 잣대와 충분한 경험과 숙달된 능력을 가지고 있지 않으면 너무 많은 시간을 소비해야 할 것이다. 옛말에 '가지 많은 나무에 바람 잘 날 없다'고 했듯이 처리할 대상이 많은 만큼 오류와 비합리가 발생할 확률이 높다.

이런 문제를 해결하기 위해 앞으로 우리는 속성 정의를 위해 수행해 나갈 세부적인 접근 단계와 거기에서 나타나는 각종 중요한 결정에 대한 판단의 근거를 구체적으로 소개할 것이다. 물론 현실적인 실사례들을 많이 동원하여 여러분들이 보다 실전적인 솔루션으로 적용할 수 있도록 할 것이다.

3.3. 속성 검증 및 확정
다양한 경로를 통해 수집된 속성 후보들을 엔터티에 배정시킨 다음 이제 우리가 해야 할 일은 이들을 검증하여 제자리를 찾게 해 주는 일이다. 속성을 검증하는 작업은 총 4단계로 나누어 실시한다.
속성 검증의 첫 번째 단계는 "원자 단위냐?"라고 묻는 것이다. 이 말은 그 속성이 더 이상 분할되어서는 의미가 없어지는 '최하 단위'인지를 묻는 것이다. 두 번째 단계는 "하나만 존재하느냐?"라고 묻는 것이다. 이 말은 개체마다 이 속성에 반드시 하나의 값만 가지는 지를 묻는 것으로서 제1정규형과 동일하다.

세 번째 단계는 "가공값이냐?"라고 묻는 것이다. 이 말은 다른 값에 의해 재현될 수 있는지를 묻는 것으로서 정보의 근원이 되는 '원시(source)' 속성만을 찾기 위한 것이다. 이렇게 세 번째 단계까지를 통과하면 속성으로써 기본적인 자격은 획득된다. 그러나 보다 적극적인 자세로 네 번째 단계를 추진해야만 올바른 속성 정의가 가능하다. 네 번째 단계는 "보다 근원적인 정보를 관리해야 하지 않겠느냐?"고 질문하는 것이다.

3.3.1 다양한 속성 유형
엔터티나 릴레이션십에 다양한 타입을 부여하여 ERD를 보다 상세하게 표현한 것처럼 속성에도 다양한 타입이 존재한다. 우리가 현재 살고 있는 현실세계가 조금씩 변하는 것과 같이 정보 시스템도 조금씩 변해가는 업무에 따라 변화를 겪고 있다.
이러한 변화를 논리 및 물리적 데이터 모델에 적절히 반영해 주기 위해서는 속성에 타입을 부여하여 관리하는 것이 큰 장점이 있다.

제1자식(primary child) 속성의 표현

추출 속성은 그야말로 자신 이외의 다른 속성을 가지고 어떤 형태로든 가공하여 만들어진 속성을 의미하므로 그 대상의 범위는 매우 넓다고 할 수 있다. 그 중에서 제1자식 속성이란 하위에 있는 자식 엔터티의 속성 중에서 하나를 선택해서 올려놓은 것을 말한다. 자식 엔터티라 함은 그것이 바로 1촌 아래가 아니더라도 결국은 1:M 관계에 있다. 할아버지에게는 아들뿐만 아니라 그 아래 자손들과도 역시 1:M 관계에 있다는 것이다.

결론적으로 말한다면 제1자식 속성이란 자식 개체 중에서 하나를 택일해서 생성한 속성을 의미하는 것이다. 일반적으로 추출 속성이라고 해서 어디 하늘에서 갑자기 떨어진 속성으로 만들어지는 것이 아니라 거의 대부분은 주변 엔터티에 있는 속성들로 가공되기 마련이다. 그 주변이라는 것 또한 사실은 대부분 직접, 혹은 간접적인 릴레이션십에 의해 연결되어 있다는 것이다.

가상(pseudo) 속성의 표현
아직 속성화 되지 않은 가상적인 상태의 정보를 나타내는 것이다. 앞에서 소개한 속성 검증 4 단계처럼 속성이 되기 위해선 검증해야 할 몇 가지 단계가 있다. 하지만 모델링을 진행하는 단계에서 속성 검증에 치우치게 되면 전체 업무 규칙을 파악하지 못하는, 마치 숲을 보지 못하고, 나무만 보게 되는 것과 같은 우를 범할 수 있다.

사용자 인터뷰 또는 다른 수단 및 매체를 통하여 이러한 정보가 추출될 때 우선 가상속성으로서 수집하고, 향후 보다 상세한 검증을 통하여 확정된 속성으로 결정해 나가는 것이 모델링 수순을 지키면서 진행해 나가는 올바른 방법이며, 가상속성의 개념은 이때 유용하게 활용 가능하다.
가상속성(Pseudo Attribute)의 예로서 아래와 것들이 있다.

연락처(주소, 전화번호, 우편번호, 등 ... )
- 배송정보( 주소, 전화번호, 배송일자, 인수자, 배송 코멘트, 등... )
- 사원정보( 이름, 주민번호, 사번, 생년월일, 등... )

제거(drop) 속성의 표현
'제거(drop) 속성'은 앞서 소개했던 제거 엔터티와 유사한 개념으로 이해할 수 있다. 해당 정보(속성)는 필요 없다고 판단되었으나 향후 번복될 가능성이 있거나, 모델 전체의 이해도를 높이기 위하여 삭제되었다는 표시를 한 채로 존재하는 속성을 의미한다.

모델링의 과정을 지원하는 방법론이라고 한다면 상황에 따라서 일단 제거하겠다고 했지만 완전히 삭제하는 것만은 잠시 보류하겠다는 것을 표현할 수 있어야 할 것이다. 또한 ERP 패키지를 커스터마이징할 때 패키지의 특성상 비록 사용하지 않는 속성이라 하더라도 함부로 지워 버릴 수 가 없기 때문에 '사용하지 않기로 결정했다'는 표현을 해 둘 필요가 있을 때 유용하게 사용할 수 있는 개념이다.

추가(additional) 속성의 표현
'추가(additional) 속성'은 기존 모델을 분석하여 시스템을 개선하고자 할 때 이미 존재하고 있던 속성들과 신규 추가된 속성을 구분하여 검토하기 위해 존재하는 개념이다. 추가 속성은 개선된 모델의 시스템 영향도 또는 요구사항 반영여부를 효율적으로 검토하기 위하여 추가된 속성 타입이다. 기존에 그려진 데이터 모델에 이번에 새롭게 정의한 속성들을 특별히 구분하고자 할 때 사용하는 표현 방법이다.
뿐만 아니라 추가 속성이라는 의미에는 '미결(未決) 속성'이란 뜻이 얼마간은 포함되어 있다고 할 수 있으므로 아직은 '확정하지 않은 상태'에 있는 속성들을 표시하기 위해서도 활용할 수가 있다.

관계(relation) 속성의 표현
'관계 속성'은 원래의 모습은 속성이 아니라 릴레이션십이기 때문에 당연히 선분 형태로 표현하는 것이 옳겠지만 굳이 선분으로 표시하지 않더라도 어느 엔터티에서 온 릴레이션십이란 것이 너무나 분명하다면 그림이 너무 복잡해지지 않도록 속성으로 표시하는 방법도 생각해 볼 수 있다. 이러한 이유로 인해 속성 형태로 표현된 릴레이션십들을 '관계 속성'이라고 부른다.

우리가 표현하는 릴레이션십은 관계형 데이터베이스 설계 시에 부모의 식별자가 상속되어 나의 컬럼(외부키)이 된다는 것을 의미한다. 다시 말해서 릴레이션십은 나중에 가서는 결국 컬럼이 되지만 모델링 단계에서는 일종의 논리적 속성이기 때문에 미리 부모의 식별자를 상속해 둘 필요가 없다.

실전에서는 코드와 명칭만을 속성으로 가지는 엔터티들이 너무 많아져서 난잡하게 관리되는 것을 막기 위해 대부분의 코드들을 통합한 엔터티를 가져가는 경우가 많이 있다. 사실 어떤 엔터티를 살펴보더라도 최소한 한두 개 이상의 코드를 가지지 않는 경우는 별로 없다. 이러한 경우에 하나로 통합된 이 엔터티와 일일이 관계 선분을 그린다면 그림이 너무 복잡해지게 된다는 것은 당연하다. 이러한 경우에도 관계 속성으로 표현한다면 매우 단순해진 그림을 얻을 수 있을 것이다.


인기기사 순위
(우)08503 서울특별시 금천구 가산디지털1로 181 (가산 W CENTER) 1713~1715호
TEL : 02-2039-6160  FAX : 02-2039-6163  사업자등록번호:106-86-40304
개인정보/청소년보호책임자:김선오  등록번호:서울 아 00418  등록일자:2007.08  발행인:김용석  편집인:김선오