태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

저는 속성을 아래와 같이 분류합니다.

 

- 기초(Basic) 속성

- 관계(Relationship) 속성

- 추출(Derived) 속성

- 시스템(System) 속성

 

이는 실제 엔터티에 존재하는 속성을 분류한 것입니다. 즉 순수하게 업무에서 필요한 논리적인 구분이 아니라 물리적인 구분입니다.

 

기초 속성(Basic Attribute)부터 차례로 설명하겠습니다.

 

엔터티의 본질을 설명하는 속성이 기초 속성입니다. 이 기초 속성을 보면 엔터티의 정의를 알 수 있습니다. 엔터티에 반드시 존재해야 하는 업무 식별자와 후보 식별자, 엔터티의 특성을 설명하는 속성 등이 이에 해당합니다.

 

[그림1] 주문 엔터티의 주문번호·고객번호·주문일자·배송요청일자·배송지주소 속성이 기초 속성입니다.

 

 

[그림1]

 

기초 속성은 오너십(Ownership)과 연관있습니다. 오너십 중에 엔터티가 어느 주제 영역(ERD)에 속해야 하는지에 대한 오너십이 모델 오너십(Model Ownership)인데요. 모델 오너십을 정하는 기준이 기초 속성입니다.

 

관계·추출·시스템 속성으로는 해당 엔터티의 성격을 알 수 없기 때문에 당연히 기초 속성이 기준이 돼야 합니다. 기초 속성의 값은 주로 데이터베이스를 사용하는 사용자(User)의 입력이라는 행위에 의해서 생성됩니다. 기초 속성의 값을 생성하는 영역에서 모델 오너십을 가져야 합니다.

 

바람직하지 않지만 만약 데이터 오너십(Data Ownership)을 관리한다면 마찬가지로 기초 속성의 값을 생성하는 조직(파트)에서 가져야 할 것입니다.

 

기초 속성은 주로 논리 모델링 초반에 도출됩니다. 일부 핵심적인 기초 속성은 개념 모델링 단계에서 도출되고요. 가장 먼저 도출해야 하는 속성이 기초 속성입니다.

 

속성이 도출되는 순서는 아래와 같습니다. 모델링할 때 이 순서로 속성을 추가하면 됩니다.

 

기초 속성 => 관계 속성 => 추출 속성 => 시스템 속성

 

엔터티에서 중복·추출 속성을 제외하면 가장 많은 속성이 기초 속성입니다. 또한 기초 속성을 전부 삭제하면 나머지 속성만으로는 그 엔터티가 무슨 데이터를 관리하는지 알 수 없게 됩니다. 그만큼 엔터티 본질과 연관되는 중요한 속성이 기초 속성입니다.

 

 

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

대리 식별자(Alternate Identifier)는 주 식별자(Primary Identifier)로 선택되지 않은 후보 식별자입니다. 대체 식별자라고도 하고요. Primary Identifier에 대한 의미로써 Secondary Identifier라고도 합니다.


[그림1] 릴레이션에서 후보 식별자는 사원주민번호·휴대폰번호·이메일주소·고객번호 속성입니다.


[사원]

사원주민번호

사원명

휴대폰번호

이메일주소

집주소

고객번호

현재부서

123456-7890123

홍길동

010-123-4567

a@y.z

경기도

654321

개발부

234567-8901234

이길동

010-234-5678

b@y.z

서울

987654

총무부

345678-9012345

김길동

010-345-6789

c@y.z

서울

321098

인사부

[그림1]


후보 식별자 중에서 고객번호 속성을 주 식별자로 선정했습니다. 그러면 사원주민번호·휴대폰번호·이메일주소 속성이 대리 식별자입니다.


대리 식별자는 결국 후보 식별자와 같은 역할을 합니다. 대리 식별자 속성 값은 릴레이션에서 유일해야 합니다. 따라서 물리적인 제약을 생성해 관리하기 위해 유니크 인덱스를 생성합니다. 그래야 엔터티에 데이터가 잘못 입력되는 것(중복된 값이 입력되는 것)을 원천적으로 방지할 수 있습니다.

 

만약 인조 식별자가 사용됐다면 대리 식별자는 인스턴스가 생성되는 기준이 되기 때문에 더욱 유니크 인덱스로 관리해야 합니다.

 

후보 식별자가 유니크하게 잘 관리될수록 데이터베이스가 더 온전해지며 사용하기 편하게 됩니다.


CASE 툴에서 다양한 식별자를 구분해 관리할 수 있으면 좋지만, 지원이 안 되면 속성 설명에 식별자 구분과 간략 설명을 기술하는 것이 좋습니다.

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

주 식별자(Primary Identifier)는 엔터티에 하나만 존재하는 대표 식별자입니다. 업무 식별자나 후보 식별자와 달리 물리적인 개념이 강해 PK(Primary Key)라고 생각해도 될 거 같습니다.

 

주 식별자 역할은 두 가지 관점으로 생각할 수 있습니다. 하나는 자신의 엔터티를 바라보는 관점이고요. 다른 하나는 다른 엔터티에서 바라보는 관점입니다.

 

전자는 자신의 엔터티 내에서 인스턴스를 식별하는 PK 역할이고요. 후자는 다른 엔터티에서 바라볼 때 그 엔터티와의 관계를 식별하는 FK(Foreign Key) 역할입니다.

 

주 식별자는 물리적으로 인스턴스를 대표하는 역할을 하기 때문에 인스턴스를 조회할 때 사용하고요. 또한 다른 엔터티와 조인(Join)할 때도 주 식별자를 사용합니다.

 

주 식별자를 선정하는 방법은 두 가지가 있습니다. 하나 또는 여러 개의 후보 식별자 중에서 대표로 지정할 수가 있고요. 적당한 후보가 없다면 인조 식별자를 만들어 주 식별자로 사용할 수도 있습니다. 주 식별자를 선정하는 방법은 이후에 자세히 설명하겠습니다.

 

주 식별자는 몇 가지 특성이 있습니다.

 

가장 기본적인 특성은 엔터티에 주 식별자가 반드시 존재해야 한다는 것입니다. 더 정확히 표현하면 엔터티에는 물리적인 주 키(Primary Key)가 반드시 존재해야 합니다. 간혹 PK가 없는 엔터티를 볼 수 있는데요. 이는 엔터티 무결성을 지키지 않은, 기본이 지켜지지 않은 모델입니다.

 

그리고 주 식별자는 하나만 존재해야 합니다. 이것이 또한 물리적으로 PK가 존재해야 하는 이유이기도 합니다. 하나만을 지정해야 다른 엔터티와의 조인(Join)이 가능합니다.

 

또한 주 식별자 속성은 당연히 널(Null) 값을 허용하지 않습니다.

 

주 식별자는 정규화의 기준이 되는 속성입니다. 정규화라는 행위가 먼저이고 그 결과에 따라 주 식별자가 정해지는지, 아니면 주 식별자가 정해지고 정규화가 진행되는지 애매한 점은 있지만, 최소한 정규형이 맞는지를 검증할 때는 주 식별자가 명확한 기준이 됩니다.

 

주 식별자(PK)는 외래 식별자(FK)와 함께 많이 알려진 식별자입니다. 실제로 많이 사용하는 식별자라 개념을 이해하는 것은 어렵지 않습니다. 어떤 속성을 주 식별자로 선택할지가 어려운 부분인데요. 주 식별자 선정 원칙은 별도로 설명하겠습니다.

 

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

판다곰과 원숭이와 바나나가 있습니다. 이중 두 가지를 묶는다면 어떤 것을 묶으시겠습니까?”

책을 읽다보면 모델링과 연관해서 생각할 때가 종종 있습니다. 일종의 직업병이죠. 생각하고 싶지 않은데 저절로 생각이 흐르니까 좋지 않은 병입니다.

서양과 동양의 차이를 설명한 책을 읽었는데1), 한 부분을 제가 이해한 방식으로 소개하겠습니다.

아리스토텔레스로 대표되는 서양 사람은 사물의 본질을 잘 파악한다고 합니다. 성격 그대로 생각하는 것이죠. 데이터 본질이 생각나더라고요.

반면, 공자로 대표되는 동양 사람에게는 사물의 본질과 함께 관계가 지대한 영향을 미친다고 합니다. ‘관시(관계)’라는 중국어를 강조하던 선배가 생각났고요. 모델링 관계가 생각났습니다.

서양 사람은 자기 자신을 잘 파악해서 개인주의 성향이 강합니다. 자신 외의 외부에 대해서는 별 상관하지 않습니다.

동양 사람은 타인과의 관계를 중요시합니다. 혼자서는 살아갈 수 없는 존재죠. 어릴 때는 이 말을 인정하지 않았는데, 이젠 어느정도 인정합니다. 나는 내 본질 이외의 것으로 이루어졌다는 것을요.

주제가 벗어났는데... 오늘은 범주에 대한 얘기를 하고 싶었습니다.

서양 사람이 범주라는 단어를 잘 이해합니다. 아리스토텔레스가 범주론2)을 쓴 이유이기도 하죠. 한번 읽어보세요. 모델러에게 도움이 될 것입니다.

반면 장자는 범주론을 경계했다고 합니다. 도덕경에 나온다는 아래 글이 마음에 듭니다.

섯 가지 색으로만 범주화하면, 우리 눈은 멀게 되고
다섯 가지 음으로만 범주화하면, 우리 귀도 멀게 되고
섯 가지 맛으로만 범주화하면, 우리 입맛은 짧아질 것이다

아리스토텔레스를 뛰어 넘는 경지인 것 같습니다. 범주화를 경계했다는 것은 이미 범주화를 했다는 것이니까요. 옆길로 또 샜는데요.

첫 줄의 질문은 동양과 서양 대학생들에게 한 설문 조사입니다. 여러분은 어떻게 묶으셨나요? 저는 주저 없이 원숭이와 바나나를 묶었습니다. 주변에도 물었는데 그렇게 묶었고요. 주저하지 않았습니다. 실험 결과도 대다수의 동양 학생은 그렇게 묶었습니다.

그런데 대다수 서양 학생은 판다곰과 원숭이를 묶었습니다. 판다곰과 원숭이는 동물이라는 동일한 범주에 속한다고 보고 묶은 것입니다. 예상하셨겠지만 동양 학생은 원숭이가 바나나를 먹는다는 관계에 근거해서 원숭이와 바나나를 묶었습니다.

이 질문에 판다곰과 원숭이를 묶으셨다면(아마 거의 없을 듯) 서양인의 피가 흐르거나 특이한 뇌구조를 가지고 있는 것입니다. 동양에서는 살기 힘든

만약 설문이 두 가지를 그냥 묶어라가 아니라(무의식을 살피기 위한), 범주화하라고 했다면 결과가 조금 달라졌을 것 같은데요. 어쨌든 모델링에서 시사하는 바가 있습니다.

세 사물의 특성을 보면 당연히 판다곰과 원숭이가 유사합니다. 속성이 유사하죠. 이는 데이터 통합에 그대로 적용됩니다.

엔터티를 통합하기 위해서는 엔터티의 속성(특성)을제대로 파악해야 합니다. 외부 관계에 현혹되면 안 됩니다. 다른 엔터티와의 관계나 프로세스, 화면, 조직(데이터 오너십) 등과 무관해야 합니다. 본질을 제외한 외부 환경의 작용은 없어야 합니다.

범주화에 대한 이해가 부족해 관계(행위) 엔터티를 실체 엔터티에 통합하는 예도 있습니다. 데이터 통합은 성질이 유사한 것끼리 통합하는 것입니다. 관계가 있는 엔터티끼리 통합하는 것이 아니고요.

모델링 측면에서는 판다곰과 원숭이를 묶는 것이 답입니다. 원숭이와 바나나를 묶었다면 시스템이 힘들어질 것입니다.

고대 그리스인이 사물 자체의 본질을 범주화의 기준으로 삼았듯이 엔터티를 통합할 때도 엔터티 자체의 본질이 기준이 되어야 합니다.

범주화는 논리적으로 사고하려는 사람에게 필요한 기법입니다. 모델러에게 큰 도움이되는 것은 분명합니다.

 

1) 생각의 지도/리처드 니스벳/최인철/김영사/2004
2) 범주들, 명제에 관하여/아리스토텔레스/김진성/이제이북스/2008

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 혈기린 2012.04.16 10:35  댓글주소  수정/삭제  댓글쓰기

    전 완전 동양사람이네요 관계먼저 ㅡㅡ;; 모델러 되기는 힘든건지 ㅎㅎ 울 와이프는 바로 본질적으로 동물로 묶어 버리네요 그래서 와이프 한테 기창님 책줘서 읽어보라구 햇습니다 모델러 양성 ㅎㅎ

  • 핫신 2013.02.08 10:43  댓글주소  수정/삭제  댓글쓰기

    판다곰과 원숭이를 본능적으로 묶었는데, 이거 모델러 직업병인가요? 제가 특이한 뇌구조인것 같네요.. 너무 좋은 실험이네요. 조만간 지인들에게 써먹어 보로돌 하겠습니다.

    • 블루퍼필 2013.02.11 14:41 신고  댓글주소  수정/삭제

      회사 직원들한테 간혹 문제를 내는데, 판다곰과 원숭이를 주로 묶네요.
      확실히 연관이 있는 거 같습니다.
      아니면 문제가 이미 노출됐든지... ㅎ

  • 정유성 2013.08.14 13:29  댓글주소  수정/삭제  댓글쓰기

    유형에 따라 두 종류로 묶이네요.
    아무래도 작년에 이 글을 읽은 영향 같습니다. ㅎㅎ

  • 클락 2013.08.28 12:40  댓글주소  수정/삭제  댓글쓰기

    몇명아니되지만 엔지니어인 분은 서양적으로 생각하고 영업맨은 분들은 동양적으로 생각하더군요 ㅎㅎㅎㅎ

  • 킷츄 2013.09.06 17:08 신고  댓글주소  수정/삭제  댓글쓰기

    굉장히 인상 깊게 읽었습니다. 많은 생각을 하게 하는 글이네요. ㅎㅎ

    덧붙여서, 판다곰과 원숭이를 묶었다는 사실이 기쁘기도, 복잡하기도 하고 그렇습니다 ㅎㅎ

식별자 속성이란 엔터티에 존재하는 인스턴스의 유일성을 보장해 주는 속성이나 속성 집합입니다.

엔터티의 인스턴스마다 서로 다른 값을 가지는 속성이 식별자입니다. 같은 값이 하나라도 존재하면 식별자가 아닙니다.

흔히 말하는 PK는 테이블에 지정된 물리적인 제약(Constraints)입니다. 임의의 속성을 하나 추가하거나 여러 속성을 묶어서 PK 역할을 하도록 만들 수 있기 때문에, PK가 업무 식별자나 후보 식별자와 동일한 개념은 아닙니다. 업무(후보) 식별자는 논리적으로 인스턴스를 구별하는 속성입니다.

식별자를 지칭하는 용어는 여러 가지가 있습니다. 업무 식별자, 후보 식별자, 주 식별자, 대리 식별자, 인조 식별자, 외래 식별자, 슈퍼 식별자 등이 있는데요. 자세한 설명은 곧이어 할 것입니다.

이중에 하나의 엔터티에 물리적으로 존재하는 식별자로는 주 식별자, 대리 식별자, 외래 식별자가 있습니다. 나머지 식별자는 쓰임새에 따른 구분입니다. [그림1] 사원 엔터티에서 사원번호 속성은 주 식별자이고요. 사원주민등록번호 속성은 대리 식별자입니다. 소속부서번호 속성은 외래 식별자입니다.



[그림
1]


따라서 사원번호, 사원주민등록번호, 소속부서번호 속성은 식별자(Key) 속성이고요. 사원명, 입사일자, 퇴사일자, 휴대전화번호 속성은 비식별자(Non-Key) 속성입니다.

사원명 속성과 같은 비식별자 속성의 값은 중복 존재할 수 있기 때문에, 홍길동이라는 이름의 사원은 여러 명 존재할 수 있기 때문에 사원명 속성으로는 인스턴스를 구별할 수 없습니다. 유일하게 식별할 수 없기 때문에 비식별자 속성입니다.

식별자 속성을 다르게 표현하면 결정자(Determinant) 속성입니다. 비식별자 속성은 종속자(Dependent) 속성과 같고요.

연관된 속성을 묶는 과정이 정규화(Normalization)인데요. 묶는 기준이 결정자입니다. 이렇게 묶여서 결정자 역할을 하는 속성(식별자 속성)과 종속자 역할을 하는 속성(비식별자 속성)이 모이면 엔터티가 됩니다.

식별자(결정자) 속성이 엔터티의 본질이나 태생과 관련이 있다면, 비식별자(종속자) 속성은 엔터티의 특성을 묘사하는 역할을 합니다.

그리고 하나의 속성이 식별자의 역할을 하지 못할 때는 여러 속성이 묶여 식별자(복합 식별자)가 될 수 있습니다.

엔터티의 식별자(결정자)가 정해지면 그 엔터티가 정의된 것이나 마찬가지여서 식별자는 데이터 모델링에서 중요한 역할을 합니다. 집중해야 할 부분입니다.


 

블로그 이미지

블루퍼필

댓글을 달아 주세요

모델링의 3요소는 엔터티, 속성, 관계입니다.

엔터티 정의는 중요하기 때문에 어려운 반면, 속성 정의는 많은 개수 때문에 어려움을 겪습니다. 엔터티나 관계에 비해 압도적으로 많죠
.

속성은 엔터티의 성격을 상세하게 기술하는 요소입니다. 속성을 모두 도출(정의)하면 해당 엔터티가 관리하는 데이터가 무엇인지 알기 쉽습니다.

속성은 데이터의 값을 저장하는 저장소입니다. 데이터를 저장하는 가장 작은, 독립된 저장 단위죠. 이렇게 저장된 데이터가 엔터티를 자세하게 묘사합니다.

 

속성을 모두 도출해야 엔터티가 온전해집니다. 속성이 채워지지 않는 한 모델링은 끝난 것이 아닙니다. 결국 속성을 상세하게 분석하는 시간이 많을수록 데이터 모델의 완성도는 높아집니다.

 

이를 역으로 표현하면 모델링 시간이 충분히 주어질수록 속성을 상세하게 분석할 수 있어 모델의 완성도가 높아지게 됩니다. 결국 모델링 시간이 충분하지 않으면 속성과 관련된 작업이 부실해지게 됩니다.

 

속성의 정의 자체는 어렵지 않습니다. 하지만 속성의 진정한 쓰임새를 알려면 속성의 종류를 아는 것이 좋습니다. 속성의 다양한 분류법을 통해 속성이 무엇인지 더욱 상세하게 알 수 있을 것입니다.

 

다음과 같은 다양한 방법으로 속성을 구분할 수 있습니다.

 

-식별자(Key) 속성 & 비식별자(Non-Key) 속성
-
기초(Basic) 속성 & 관계(Relationship) 속성 & 추출(Derived) 속성 & 시스템(System) 속성
-
원본(Raw) 속성 & 추출(Derived) 속성
-
단일 값(Single-Valued) 속성 & 다가(Multivalued) 속성
-
필수(Mandatory) 속성 & 선택(Optional) 속성
-
코드(Code) 속성 & 비코드(Non-Code) 속성

 

위와 같은 방법으로 어떤 속성을 명확히 분류할 수 있다면, 속성이 무엇인지 온전히 안다고 할 수 있습니다.

 

위의 분류를 앞으로 하나씩 상세하게 설명하겠습니다.



블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 금땡이 2012.02.28 14:08  댓글주소  수정/삭제  댓글쓰기

    바쁘신 와중에도 꾸준이 글을 올려 주시니 고맙습니다. 책 내용도 좋아 3번이나 읽었네요.
    프로젝이 다르다 보니 자주 뵙지도 못하고 블로그로 위안을 삼아야겠네요.^^

    • 블루퍼필 2012.02.28 19:45 신고  댓글주소  수정/삭제

      ㅎㅎ 누군가 했어요.

      긴 프로젝트 끝내서 시원섭섭하겠어요.
      재충전할 시간이 있을려나 모르겠네요.

      가끔 들러서 좋은 글 남겨주시고...
      그래도 심심하면 분당으로 놀러와요... ㅎ

지난 번에 서브타입을 구분하는 방법으로 배타(Exclusive)·중복(Inclusive) 서브타입을 설명했습니다. 이번에는 완전(Complete) 서브타입과 불완전(Incomplete) 서브타입을 설명하겠습니다.

 

완전(Complete) 서브타입은 슈퍼타입의 모든 인스턴스가 최소한 하나의 서브타입 인스턴스와 관계가 존재하는 서브타입입니다.

 

반면에 불완전(Incomplete) 서브타입은 슈퍼타입에만 인스턴스가 존재하고 서브타입에는 인스턴스가 존재하지 않는 서브타입입니다. 즉 고유 속성이 존재하지 않는 서브타입입니다.

 

이렇게 슈퍼타입 인스턴스와 서브타입 인스턴스의 관계를 인스턴스 제약(Instance Constraints)이라고 합니다. 인스턴스 제약에 따라 완전(Complete) 서브타입과 불완전(Incomplete) 서브타입으로 구분할 수 있는거죠.

 

완전 서브타입이 대부분을 차지하며 일반적이므로, 실무에서 불완전 서브타입을 주의해서 구별할 수 있어야 합니다.

 

[그림1] 모델에서 서브타입은 개인고객·사원·가망고객이 존재합니다. 이중 가망고객은 이름과 주민등록번호만 관리한다는 요구 사항 때문에 고유 속성이 없습니다.



[그림1]

 

위 모델을 물리 모델로 변환하면 [그림2]와 같이 됩니다1). 가망고객 서브타입은 속성이 없기 때문에 서브타입 엔터티로 변환되지 않습니다.



[그림2]

 

[그림3] [그림2]에 대한 릴레이션입니다. 가망고객인 김길동은 서브타입 릴레이션이 없고, 슈퍼타입인 고객 릴레이션에만 존재하므로 불완전(Incomplete) 서브타입입니다.

 

[고객]

#고객번호

고객명

주민번호

고객구분코드

12345

홍길동

123456-7890123

개인고객

67890

이길동

678901-2345678

사원

34567

김길동

345678-9012345

가망고객

 

[개인고객]

#고객번호

사업자번호

업종구분코드

12345

123-45-67890

개발

 

[사원]

#고객번호

사원번호

입사일자

67890

2345

2025-02-02

 

[그림3]

 

슈퍼타입에 인스턴스가 생성될 때 서브타입에도 인스턴스가 생성되면 완전(Complete) 서브타입이며, 그렇지 않으면 불완전(Incomplete) 서브타입입니다.

 

불완전(Incomplete) 서브타입이 드물기는 하지만 중복(Include) 서브타입보다는 자주 볼 수 있습니다. 엔터티를 과감하게 통합하면 얼마든지 나올 수 있습니다. 또한 중복 서브타입과는 달리 데이터를 관리하는 데 어려움이 없습니다.

 

완전·불완전 서브타입은 배타·중복 서브타입을 도출하는 것보다 훨씬 수월합니다.

 

1)     슈퍼타입과 서브타입을 각자 엔터티로 도출한 유형을 사용


블로그 이미지

블루퍼필

댓글을 달아 주세요

서브타입은 크게 배타 서브타입과 중복 서브타입으로 구분할 수 있습니다.

 

배타(Exclusive 또는 Disjoint) 서브타입은 서브타입 부분 집합 간에 공통 부분을 갖지 않는 서브타입입니다. [그림1]은 배타(Exclusive) 서브타입입니다.


[그림1]

 

하나의 슈퍼타입 인스턴스는 단 하나의 서브타입과 관계(일대일 관계)가 존재합니다. 따라서 고객은 개인 고객이거나 사원 둘 중 하나입니다.

 

서브타입 간에 상호 배타적이므로 일반적으로 전체 서브타입의 합은 슈퍼타입이 됩니다. 즉 개인 고객과 사원을 합치면 전체 고객이 됩니다.

 

[그림2]정보 공학(Information Engineering) 표기법의 배타 서브타입입니다. 서브타입 기호에 X 표시가 있습니다.


[그림2]

 

[그림3]중복(Inclusive 또는 Overlapping) 서브타입입니다.


[그림3]

 

중복 서브타입은 겹쳐지는 부분이 존재하는 서브타입입니다. 하나의 슈퍼타입 인스턴스가 두 개 이상의 서브타입과 관계가 존재할 수 있습니다. 따라서 고객은 개인 고객이거나 사원이거나, 또는 개인 고객과 사원 둘 다일 수 있습니다.

 

[그림4]는 중복 서브타입을 IE 표기법으로 표현한 모델입니다. 서브타입 기호에 X 표시가 없습니다.


[그림4]

 

실제로 발생하는 대부분의 서브타입은 배타(Exclusive) 서브타입입니다. 중복(Inclusive) 서브타입은 자주 발생하지 않습니다.

 

배타 서브타입의 개념은 쉬운데 혼란을 일으시킬 수 있는 부분이 있습니다. 이력과 연동된 내용인데 다음에 설명할 것이고요.

 

중복 서브타입은 데이터를 관리하는 방법이 혼란스러울 수 있습니다. 이 부분도 다시 상세하게 설명드리겠습니다.

 

해당 업무 요건이 배타 서브타입인지 중복 서브타입인지를 정확히 도출하는 것이 중요합니다. 중복 서브타입으로 도출해야 하는데 습관적으로 배타 서브타입으로 도출하면 업무를 반영하지 못하게 되므로 유의해야 합니다.




블로그 이미지

블루퍼필

댓글을 달아 주세요

블로그에 서브타입에 대한 글을 쓰고 있는데요.

변화를 위해 다양한 주제의 글을 올리겠습니다.

 

나이를 먹을수록 확실히 체력의 부담을 느낍니다.

일주일에 하나씩은 올리려는 생각이 한 달에 두 개로 줄고... 실제는 하나만 올라가기도 하고요.

 

최근에 정규화에 대해 다시 생각하고 있습니다.

 

지나치게 사적인 얘기지만 저는 모델링이 자신 있는데요. 남들이 뭐라하든... ㅎㅎ

오래 전부터 해 오던 훈련 때문입니다.

 

속성의 종속 관계를 파악해서 엔터티를 도출하는 훈련인데요. 쉽게 말해 속성이 엔터티에 속하는 게 옳은지를 판단하는 것입니다. 이 훈련의 핵심은 식별자와 종속성입니다.

 

엔터티를 대표하는 속성(업무 식별자)을 찾아야 하고요. 그 속성을 기준으로 대상 속성이 종속됐는지 여부를 판단합니다. 종속성이 없다면 다른 엔터티를 찾고요.

 

이 훈련을 거듭하면 전문 모델러가 될 수 있습니다. 정규화를 제대로 아는 전문 모델러가요.

 

정규화를 꼭 해야 하는지 묻는 사람들이 많습니다. 원론적인 얘기들은 이후에 많이 하겠지만 모델러라면 정규화를 꼭 해야 한다고 단언합니다.

 

정규화를 별로 고려치 않으면서 모델링하는 사람을 보는데요. 결과와 무관하게 전문 모델러로 여기지 않습니다.

 

사실 정규화를 모르고 화면 위주로 설계해도 대강은 맞게 돼 있습니다. 어떤 화면이라도 본질적으로 유사한 정보(종속성으로 묶인 정보)와 참고로 보여주는 정보(다른 화면에도 존재하는 중복 정보)를 한 화면에 보여주니까요.

 

하지만 이렇게 설계하면 뭔가를 변경하고 추가할 때 문제가 발생합니다. 그 문제가 그때그때 견딜만 해서 버텼던 것인데요. 이젠 전문가 집단이 생기고, 더 이상 주먹구구식으로 설계해선 안 되겠다는 인식이 생겨 마냥 버틸 수는 없게 됐습니다.

 

제대로 설계하기 위한 근본적인 해결책은 정규화입니다. 시스템에 따라 정규화가 필요 없을 수 있지만 그건 필요에 따른 선택일 뿐입니다. 이마저도 원칙에 바탕을 둔 선택입니다. ()와 객()을 혼돈하면 안 됩니다.

 

정규화는 엔터티 정의 자체이기 때문에, 즉 근본적인 것이기 때문에 아무리 강조해도 부족함이 없습니다. 선택 사항이 아니라는 사실을 염두에 둬야 합니다.

 

정규화에는 여러 종류가 있는데요. 정규화 이론에 대한 이견은 크지 않습니다. 학문으로 연구하는 사람은 약간씩 다른 주장을 하지만 모델러에게 큰 영향은 없을 거 같습니다.

 

일반적으로 정규화는 순서대로 수행하지 않습니다. 상향식이면 속성을 제거하면서 정규화가 수행되고, 하향식이면 생각하는 과정을 거쳐 이미 3~4정규화가 수행됩니다. 제가 초보일 때를 생각해봐도 순서대로 수행하지 않았던 거 같습니다.

 

물론 1정규화부터 차례대로 수행해도 됩니다. 현실적이진 않지만 더 체계적일 수는 있습니다. 2정규형이면 1정규화도 만족해야 되니까요.

 

RDB의 핵심은 조인(Join)입니다. 모든 속성은 주인이 되는 하나의 엔터티에만 속하고, PK만이 다른 엔터티에 존재할 수 있습니다. 다른 엔터티에 있는 속성이 필요하면 PK를 통해 조인을 해서 얻는 것이 RDB 개념 자체입니다.

 

속성의 주인(엔터티)을 찾는 과정이 정규화입니다.




블로그 이미지

블루퍼필

댓글을 달아 주세요

서브타입을 도출하는 방법은 크게 두 가지입니다.

 

두 개 이상의 유사한 엔터티에서 공통 속성을 분류하는 방법과, 복잡한 엔터티에서 유사한 속성끼리 분류하는 방법이 있습니다.

 

전자는 엔터티를 통합(Generalization)하는 행위이고, 후자는 엔터티를 상세화(Specialization) 또는 논리화(Logicalization)하는 행위입니다.

 

모든 엔터티가 서브타입이 존재하는 것은 아닙니다. 서브타입이 도출되는 엔터티는 소수인데요. 통합할 수 있고 상세화할 수 있는 엔터티에서는 서브타입을 반드시 도출해야 합니다. 물리 모델링 단계에서 다시 하나의 엔터티로 통합되더라도 과정 중에는 도출해야 합니다. 모델링은 과정을 의미하니까요.

 

[그림1] 모델에는 유사한 엔터티가 있습니다. 두 개 이상의 엔터티가 유사하다고 판단해서, 같은 성격의 속성을 찾으면 슈퍼타입을 도출하게 됩니다.


[그림1]

 

[그림2]가 서브타입을 도출한 모델입니다.



[그림2]

 

[그림1] 모델에서 개인고객·법인고객 엔터티가 유사한 엔터티이고 고객번호·고객명 속성이 유사한 속성이어서, 유사한 속성을 분리해 고객이라는 슈퍼타입을 생성했습니다. 그리고 개인고객·법인고객 엔터티에 고유한 속성은 남아서 서브타입이 됐습니다.

 

슈퍼타입 엔터티에는 서브타입을 구분할 수 있는 속성(고객구분코드)을 관리해야 합니다. 이를 서브타입 구분자(Subtype Discriminator)라고 하는데 슈퍼타입의 특정 인스턴스가 어떤 서브타입과 연관되는지를 구분하는, 슈퍼타입 엔터티의 고유 속성입니다.

 

위의 예제는 유사한 엔터티를 통합하는 과정에서 생기는 서브타입 예제입니다. 반면 아래 예제는 엔터티를 논리화(Logicalization)하는 과정에서 생기는 서브타입 예제입니다.

 

[그림3] 모델도 자주 보게 되는데요. [그림1] 보다는 바람직한 모델이지만 결과를 표현한 모델이 아니라면 바람직하지 않습니다.

 

서브타입을 도출할 수 있는 엔터티(복잡한 엔터티)인데 서브타입이 없어 고유 속성이 도출되지 않았고 관계가 상세하게 표현되지 않았습니다.


[그림3]

 

고객 엔터티에서 고객구분코드 속성이 눈에 띕니다. 이 속성으로 고객 구분이 개인 고객과 법인 고객이라는 것을 알게 되고요. 속성을 하나씩 분석(Logicalization)하면서 개인 고객에만 해당하는 속성, 법인 고객에만 해당하는 속성을 찾게 됩니다.

 

고객 엔터티와의 관계도 마찬가지입니다. 취미·주요제품 엔터티가 개인 고객에 해당하는 관계인지, 법인 고객에 해당하는 관계인지를 분석합니다.

 

이렇게 분석 과정을 거쳐 도출된 모델이 [그림2]입니다. 고객이 어떤 종류로 구성됐는지를 알 수 있고, 각 서브타입에 고유한 속성과 관계를 한눈에 알 수 있습니다.

 

속성과 관계가 복잡하게 얽혀 있는 엔터티는 위와 같은 상세화(Specialization) 과정을 거쳐 서브타입이 도출됩니다.

 

[그림2] 모델에서 다양한 면을 검토해서 결정한 최종 모델이 [그림3] 모델일 수 있습니다. 하지만 [그림2] 모델을 도출하지도 않고 그냥 [그림3] 모델로 남는 것은 모델링을 했다고 볼 수 없습니다. 이는 정규화를 하지 않고 그냥 비정규형 엔터티인 채로 남겨두고 모델링을 했다고 하는 것과 마찬가지입니다.

 

유사한 성격의 엔터티를 모아서 슈퍼타입을 생성하는 방법(Roll-Up Supertypes)이 일반화(Generalization)이며, 복잡한 엔터티를 분해해서 서브타입을 생성하는 방법(Break-Down Subtypes)이 상세화(Specialization)입니다.

서브타입은 위의 두 가지 방법에 의해 도출됩니다.


블로그 이미지

블루퍼필

댓글을 달아 주세요