DA가이드 4과목 데이터모델링 (1/2)

📚 시리즈: DA가이드

• ① DA가이드 1과목
• ② DA가이드 2과목
• ③ DA가이드 3과목
• ④ DA가이드 4과목-1
• ⑤ DA가이드 4과목-2
• ⑥ DA가이드 5과목
• ⑦ DA가이드 6과목

 

DA 가이드 읽으시기전에

↑ 눌러주세요

 

 

[ 4과목 ] 데이터모델링 (1/2)

 

 

(DAP 준비의 기본서는 아래 가이드와 실전문제입니다.)

 

 

( 아래 자료는 가이드의 내용을 보완하여 공부할 수 있는 자료입니다.

한국데이터산업진흥원 정보마당에서 퍼 와서 편집만 하였습니다)

 

 

4.1 데이터 모델링 이해

 

(DA가이드 4.1.1) 데이터 모델링 개요

 

데이터 모델링 정의

데이터 모델링 탄생 배경

현재의 기업 정보시스템은 데이터베이스 관리 시스템(DBMS, DataBase Management System)을 논외로 하고는 설명할 수 없을 것이다. 하지만 초창기에는 데이터의 저장 매체가 존재하지 않았으며, 기업의 정보시스템은 저장 매체가 없는 단지 배치(Batch) 프로그램 위주의 정보시스템이었다. 이후 파일이나 데이터베이스 관리 시스템과 같은 데이터 저장 매체의 발전과 더불어 온라인(Online) 데이터 처리 정보시스템이 태동하게 되었다. 현재의 관계형 데이터베이스 관리 시스템이 아닌 이러한 시기의 파일이나 데이터베이스 관리 시스템(대표적인 예로 IBM의 계층형 데이터베이스 - HDB, Hierarchical Database)의 데이터 중심 관리 기법이 아니라 배치 프로세스에서 태동한 프로세스 중심의 데이터 관리 기법(구조적 방법론)에 의하여 정보의 고립화라는 현상을 초래하게 되었으며, 많은 기업들은 정보시스템을 유지 관리하는 데 막대한 비용을 투자해야만 했던 것이다. 이에 많은 학자들은 프로세스 중심의 정보시스템 분석, 설계 기법에 문제점이 있다고 생각하게 되었고, 진정 기업 정보시스템의 핵심은 데이터(정보)를 어떻게 하면 중복없이 정확하게 유지 관리할 수 있을까에 대한 보다 근본적인 안을 제시하게 되었다. 이와 함께 기업의 경영 정보시스템에 근본적인 문제가 설계나 개발의 문제보다는 정확한 업무의 파악(데이터에 대한 정확한 분석)이 선결되어야 한다는 결론에 이르렀으며, 이러한 환경에서 보다 현실적(실세계를 좀 더 잘 표현할 수 있는)인 관계형 데이터베이스나 개체 관계 모델링 기법(ERD, Entity Relationship Diagram)을 발전시켜 왔던 것이다.

 

모델 정의

일상생활에서 많이 접할 수 있는 단어인 모델(Model)은 다양한 현장에서 사용된다. 예술 분야에서 그림, 사진 등과 같은 작품의 대상이 되는 인물이나 대상을 보통 모델이라고 한다. 또한 아파트 분양을 할때 시공 회사에서 제공하는 모델 하우스는 분양을 원하는 사람들에게 아직 아파트 자체가 현존하지는 않지만 어떤 모습과 환경으로 시공자가 아파트를 건설할 것인가에 대한 정보를 제공한다. 이와 같이 모델이란 어떤 대상을 의미하는 포괄적 의미를 가지고 있다고 할 수 있으며, 특히 데이터 모델은 현실 세계에 대해 우리가 관심있어 하는 대상을 데이터베이스화 하기 위한 개념적 도구라고 정의할 수 있다.

아래는 모델의 일반적 의미를 실례로 설명한 내용이다.

1) 물리적 모델

현실에 실재하는 것이 아닌 복잡한 자동차의 모형, 대형 선박의 스케치 또는 설계도, 자동차의 모의 실험용으로 사용되는 바람 터널에서의 자동차 축소 모형 등이 물리적 모델의 실례이다.

2) 개념적 모델

특정 시점에 맞게 기상을 예측하기 위해서 사용되는 수리적 공식이나 원형을 파괴하지 않고 조작·수정·변경시키기 위한 경제 모형 등을 들 수 있다.

 

모델링 정의

모델링이라는 단어는 실체를 나타내는 일과 모형화라는 의미로 해석된다. ‘실체를 나타낸다’의 의미는 ‘대상을 나타낸다’라는 말로 해석될 수도 있다. 모형화라는 의미는 ‘형태를 만드는 일’ 혹은 ‘대상을 만드는 일’이라고 해석할 수 있다. 따라서 데이터 모델링이란 사용자의 요구사항으로부터 데이터의 실체를 나타내는 일이라고 해석할 수 있을 것이다.

다음은 데이터 모델링의 다양한 관점에 대한 일반적 정의 사례이다.

• Webster 사전 - 가설적 또는 일정 양식에 맞춘 표현(a hypothetical or stylized representation). - 어떤 것에 대한 예비 표현으로, 그로부터 최종 대상이 구축되도록 되어있는 계획으로 기여하는 것
• 복잡한 ‘현실 세계’를 단순화시켜 표현하는 것이다.
• 모델이란 사물 또는 사건에 관한 양상(Aspect)이나 관점(Perspective)을 연관된 사람이나 그룹을 위하여 명확하게 하는 것이다.
• 모델이란 현실 세계의 추상화된 반영이다.

데이터 모델링을 다시 정의하면 기업 업무에 대한 종합적인 이해를 바탕으로 데이터에 존재하는 업무 규칙(Business Rule)에 대하여 참(True) 또는 거짓(False)을 판별할 수 있는 사실(사실명제)을 어떻게(How), 누가(Who) 접근하는지 또한 이에 대한 전산화와는 별개의 관점에서 이를 명확하게 표현하는 추상화 기법이라 할 수 있다. 즉, 현재 업무를 파악하여 문제점을 인식하고 개선 사항을 도출하며 미래에 적합한 설계를 이끌어 내기 위해 인간이 해야 할 대부분의 결정들을 내리는 단계까지를 모두 포함하는 것이 데이터 모델링이다.

 

데이터 모델이 제공하는 것

• 시스템을 현재 또는 원하는 모습으로 가시화하도록 도와준다.
• 시스템의 구조와 행동을 명세화 할 수 있게 한다.
• 시스템을 구축하는 틀을 제공한다.
• 우리가 결정한 것을 문서화한다.
• 다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점을 제공한다.
• 특정 목표에 따라 다양한 상세 수준을 제공한다.

데이터 모델링 필요성

데이터 모델링은 프로세스 모델링과 함께 시스템 개발에 있어서 중요한 두 개의 축을 이룬다. 프로세스 중심의 분석/설계 방법을 통해 설계한 데이터 모델은 업무 프로세스의 변화에 따라 영향을 많이 받기 때문에 상대적으로 업무 변화에 대한 영향을 적게 받으면서 유연한 시스템을 만들기 위해 데이터 중심의 설계에 많은 관심이 모아지고 있다. 개발 방법론에 따라 다소간 차이는 있으나 데이터 모델링과 프로세스 모델링은 상호 보완적인 관점에서 이해되어야 하며 특히 데이터 모델은 시스템의 뼈대가 되기 때문에 데이터 모델링의 결과에 따라 시스템의 안정성은 많은 영향을 받게 된다고 할 수 있다. 고품질의 데이터 모델은 시스템의 안 정성과 유연성, 성능 등에 미치는 영향이 크기 때문에 고품질의 데이터 모델을 확보하기 위한 데이터 모델링은 시스템 개발에 있어서 가장 핵심적인 과정이라 할 수 있다. 과거의 시스템 구축 방법의 주를 이루는 프로세스 중심적인 시스템 구축 방법에서는 위와 같이 데이터와 관련한 정보 공유의 문제점이 다수 발생하게 된다. 이러한 요인들은 결국 데이터의 무결성에 좋지 않은 영향을 주게 된다. 이러한 문제점들은 데이터 품질에도 악영향을 미치게 된다. 이러한 문제점들을 해소하기 위한 방안으로 기업들은 데이터 품질 툴을 고려하고 있다. 많은 기업이 데이터 품질 툴을 이미 도입하였거나 또는 도입을 검토하고 있다. 하지만 데이터 품질 툴 도입과 같은 일회성의 데이터 품질 향상 방안으로는 문제점을 근본적으로 치유하기에는 무리가 있다.

근본적인 조치로는 난로 연통형의 개별 업무 영역을 초월한 설계가 근본적인 해결 방안이다. 이러한 통합 데이터 구조의 가장 큰 특징은 데이터 의 중복이 최소화되어 있다는 점이다.

데이터 모델링이 중요하다고 한다. 시스템 구축 과정 중에는 여러 설계 과정이 존재한다. 그 중에서도 특히 데이터 설계가 중요한 이유를 다음과 같이 정리할 수 있다.

 

파급 효과(Leverage)

시스템 구축이 완성되어 가는 시점에서는 많은 애플리케이션이 테스트를 수행하고, 대규모의 데이터 이행을 성공적으로 수행하기 위한 많은 단위 테스트가 수행되고, 이러한 과정이 반복된다. 각 단위 테스트가 성공적으로 수행되고 완료되면 전체를 묶어 병행 테스트, 통합 테스트를 수행하게 된다. 만약 이러한 시점에 데이터 모델을 불가피하게 약간 변경해야 하는 상황이 발생한다고 가정해 보자. 이를 위해서 많은 영향 분석 과정이 일어나야 한다. 데이터 구조의 변경에 따른 표준 영향 분석, 응용 변경 영향 분석 등 많은 영향 분석이 일어난다. 그 이후에 해당 분야의 실제적인 변경 작업이 발생하게 된다. 변경을 해야 하는 데이터 모델의 형태에 따라 그 영향 정도는 차이가 있겠지만 이 시기의 데이터 구조의 변경으로 인한 일련의 변경 작업은 전체 시스템 구축 프로젝트에서 큰 위험 요소가 아닐 수 없다. 이러한 이유로 인해 시스템 구축 작업 중에서 다른 어떤 설계 과정보다 데이터 설계가 더 중요하다고 볼 수 있다.

 

복잡한 정보 요구 사항의 간결한 표현(Conciseness)

데이터 모델은 구축할 시스템의 정보 요구 사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구이다. 정보 요구 사항을 파악하는 가장 좋은 방법은 수많은 페이지의 기능적인 요구 사항을 파악하는 것보다 간결하게 그려져 있는 데이터 모델을 리뷰하면서 파악하는 것이 훨씬 빠른 방법이다. 데이터 모델은 건축물로 비유하면 설계 도면에 해당한다. 이것은 건축물의 설계 도면이 건축물을 짓는 많은 사람이 공유하면서 설계자의 생각대로 일사불란하게 움직여서 아름다운 건축물을 만들어 내는 것에 비유할 수 있다. 데이터 모델은 시스템을 구축하는 많은 관련자가 설계자의 생각대로 정보 요구 사항을 이해하고 이를 운용할 수 있는 애플리케이션을 개발하고 데이터 정합성을 유지할 수 있도록 하는 것이다. 이렇게 이상적으로 역할을 할 수 있는 모델이 갖추어야 할 가장 중요한 것은 정보 요구 사항이 정확하고 간결하게 표현되어야 한다는 점이다. 활용하고 있는 데이터 모델이 이와 같은 요소들을 충족한 모델인지를 확인해 볼 필요가 있다.

 

데이터 품질(Data Quality)

데이터베이스에 담겨 있는 데이터는 기업의 중요한 자산이다. 이 데이터는 기간이 오래되면 될수록 활용가치는 훨씬 높아진다. 그런데 오랫동안 저장된 데이터가 그저 그런 데이터, 정확성이 떨어지는 데이터라면 어떨까? 이것은 일부 시스템의 기능이 잘못되어 수정하는 성격의 일이 아니다. 이것은 해당 데이터로 얻을 수 있었던 소중한 비즈니스의 기회를 상실할 수도 있는 문제이다. 데이터 품질의 문제가 중요한 이유가 여기에 있다. 데이터 품질의 문제는 데이터 구조가 설계되고 초기에 데이터가 조금 쌓일 때에는 인지하지 못하는 경우가 대부분이다. 이러한 데이터의 문제는 오랜 기간의 숙성된 데이터를 전략적으로 활용하려고 하는 시점에 대두되기 때문이다. 데이터 품질의 문제를 야기시키는 중대한 이유 중 하나가 바로 데이터 구조의 문제로 인해 야기된다. 중복 데이터의 미정의, 데이터 구조의 비즈니스 정의의 불충분, 동일한 성격의 데이터를 통합하지 않고 분리함으로써 데이터 불일치 등등 데이터 구조의 문제로 인한 데이터 품질의 문제는 치유하기에 불가능한 경우가 대부분이다.

데이터 모델링의 필요성은 다음과 같은 관점에서 설명될 수 있다.

 

애플리케이션과 데이터의 통합

현재 기업에서는 진정한 정보 인프라 구축을 위해 데이터와 애플리케이션의 통합에 많은 노력을 기울이고 있다. 데이터 기반의 통합이 아닌 애플리케이션 코딩 차원의 통합 시도에는 너무나 많은 비용과 시간이 소요된다. 데이터를 기반으로 한 통합은 효과적이면서 동시에 저비용으로 통합 프로젝트를 안정적으로 수행하면서 성공적으로 완수하기 위한 필요조건이 되고 있다. 이로 인해 데이터 기반 통합의 핵심 요소인 데이터 모델링의 중요성은 날로 부각되고 있다.

 

개발자들의 시스템 이해

개발자들은 하나의 애플리케이션에서 사용되는 데이터가 어떤 것인지 파악하고 이해하는 것뿐만 아니라 전체 시스템에서 데이터가 어떻게 상호 연관성을 가지고 유기적으로 움직이고 있는가에 대해 명확하게 이해하는 데 많은 어려움을 겪고 있다. 개발자들은 그들이 개발할 시스템과 데이터를 좀 더 확실하게 이해하기 위해 데이터의 모형화를 필요로 한다.

1) 사용자 관점 데이터

프로세스 모델링과 같이 데이터 모델링은 사용자가 원하는 것의 논리적 개념과 시스템이 어떻게 그것을 제공하는 지의 물리적 개념을 명확하게 나타낸다.

2) 물리적 표현 또는 사용에 관계없는 데이터 그 자체의 본질

물리적인 것과 논리적인 것을 구별함으로써 저장 기법, 데이터와 파일 접근 방법 그리고 데이터를 사용하는 사람과 사용법에 대한 내역 등 변화되는 물리적인 것으로부터 독립되어 조직과 사용자가 필요로 하는 필수적이고 기본적인 데이터를 정의할 수 있다.

3) 애플리케이션간 데이터 사용

데이터 모델링은 데이터 정의, 생명주기 정보(CRUD) 그리고 언제 어떻게 데이터가 사용되었는지를 추적할 수 있는 방법(매트릭스 분석 기법을 이용한 상호작용 분석) 등을 제공함으로써 애플리케이션을 통해 데이터가 어떻게 사용되는지를 개발자들이 쉽게 이해할 수 있도록 한다.

 

데이터 모델링시 주의점

1) 중복(Duplication)

데이터 모델은 같은 데이터를 사용하는 사람, 시간, 그리고 장소를 파악하는데 도움을 준다. 이러한 지식 응용은 데이터베이스의 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.

2) 비유연성(Inflexibility)

데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무 변화에도 데이터 모델이 수시로 변경됨으로써 유지보수의 어려움을 가중시킬 수 있다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.

3) 비일관성(Inconsistency)

데이터의 중복이 없더라도 비일관성은 발생한다. 예를 들어 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보를 갱신하는 것이다. 개발자가 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문이다. 데이터 모델링시 데이터와 데이터간 상호연관 관계에 대한 명확한 정의는 이러한 위험을 사전에 예방할 수 있도록 해준다.

 

데이터 모델링 단계

데이터 모델링은 현실 세계의 기업 업무에서 발생하는 데이터에 대하여 물리적으로 데이터베이스화하기 위해 이루어지는 과정 중의 한 단계이다. 이 데이터 모델링은 개념 데이터 모델링, 논리 데이터 모델링, 물리 데이터 모델링 등 3단계로 나눌 수 있으며, 엄밀한 의미에서 범주로 보기도 한다.

개념 데이터 모델링 단계에서는 주제별로 분류 가능한 업무를 분석한 후 핵심 엔터티(Entity)를 추출 하고 그들 간의 관계를 정의하여 전체 데이터 모델의 골격을 생성한다. 이렇게 도출된 엔터티(업무) 간 의 관계를 표현하기 위해 개체-관계 다이어그램(ERD, Entity-Relationship Diagram)을 작성한다.

 

[Tip] ----------------------------------------------------------------------------------------

데이터 모델링 과정은 다음과 같은 문제를 해결하려고 한다.

1. 어떠한 데이터가 중요한가? 2. 어떻게 데이터가 표시될 것인가? 3. 어디에 데이터가 저장될 것인가? 우선 시스템 분석 및 설계와 데이터베이스 설계의 차이를 알아야 한다. 데이터 모델링에서는 시스템 분석보다 조직의 업무를 지원하기 위한 포괄적 데이터베이스를 개발하는 데 초점이 맞춰진다. 반대로 시스템 분석에서는 데이터베이스 요구 사항을 고려하기는 하지만 데이터의 흐름, 데이터 변환, 입력, 출력 설계, 데이터 처리를 위한 과정에 초점이 맞춰진다. 보통 데이터 모델링 과정은 개념적 데이터 모델링(개념 데이터 모델링), 논리적 데이터 모델링(논리 데이터 모델링), 물리적 데이터 모델링(물리 데이터 모델링) 과정을 포괄한다.

---------------------------------------------------------------------------------------------

 

논리 데이터 모델링 단계에서는 개념 데이터 모델링 단계에서 정의한 핵심 엔터티와 관계를 바탕으로 상세 속성을 정의하고 식별자를 확정하며 정규화와 같은 상세화 과정을 수행한다. 마지막으로 물리 데이터 모델링 단계에서는 논리 데이터 모델을 기반으로 목표하는 DBMS의 특성 및 구현 환경 등을 감안한 스키마(데이터 구조)를 일정한 기준과 규칙에 의해 도출하고 칼럼(Column)의 데이터 타입과 크기를 정의한다. 또한 데이터 사용량을 분석 예측하는 과정을 통해 효율적인 데이터베이스가 될 수 있도록 인덱스의 정의 및 역정규화 작업을 수행한다.

이러한 단계별 내용은 프로젝트 진행과도 일치한다. 물리 데이터 모델링 단계 후에 얻어진 스키마를 실제 데이터베이스로 생성하면 본격적인 애플리케이션 개발 단계로 넘어가게 된다. 각 단계에 대해 상세히 알아보면 다음과 같다.

 

개념 데이터 모델링(Conceptual Data Modeling)

개념 데이터 모델링은 조직, 사용자의 데이터 요구 사항을 찾고 분석하는 데서 시작한다. 이 과정은 어떠한 자료가 중요하며 또 어떠한 자료가 유지되어야 하는지를 결정하는 것도 포함한다. 이와 같이 데이터 요구 사항은 분석 과정의 초기에 본질적으로 기술과 무관한 사양들의 집합인 개념 데이터 모델로 형상화되고, 비즈니스 이해 관계자들과 초기 요구 사항을 논의하기 위해 사용된다. 이 단계에 있어서의 주요한 활동은 핵심 엔터티와 그들 간의 관계를 발견하고, 그것을 표현하기 위해서 개체-관계 다이어그램을 생성하는 것이다. 개체-관계 다이어그램은 조직과 다양한 데이터베이스 사용자에게 어떠한 데이터가 중요한지를 나타내기 위해서 사용된다. 데이터 모델링에서 다루는 범위와 수행 과정이 전 조직에 걸쳐 이루어진다면, 그것은 전사적 데이터 모델(Enterprise Data Model)이라고 불린다.

개념 데이터 모델을 통해 조직의 데이터 요구를 공식화하는 것은 두 가지의 중요한 기능을 지원한다. 첫째, 개념 데이터 모델은 사용자와 시스템 개발자의 데이터 요구 사항 발견을 지원한다. 개념데이터 모델은 추상적이다. 그렇기 때문에 그 모델은 상위의 문제에 대한 구조화를 쉽게 하며, 사용자와 개발자가 시스템 기능에 대해서 논의할 수 있는 기반을 형성한다. 둘째, 개념 데이터 모델은 현 시스템이 어떻게 변형되어야 하는가를 이해하는 데 유용하다. 일반적으로 매우 고립된(StandAlone) 시스템도 간단하게 추상적 모델링을 통해서 좀 더 쉽게 표현되고 설명된다.

 

논리 데이터 모델링(Logical Data Modeling)

논리 데이터 모델링은 데이터 모델링 프로세스의 Input으로써 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 기법 또는 과정이라 할 수 있다. 논리 데이터 모델링의 결과로 얻어지는 논리 데이터 모델은 데이터 모델링이 최종적으로 완료된 상태라고 정의할 수 있다. 즉, 물리적인 스키마 설계를 하기 전 단계의‘데이터 모델’상태를 일컫는 말이다. 논리 데이터 모델링의 핵심은 어떻게 데이터에 액세스하고 누가 데이터에 액세스하며, 그러한 액세스는 전산화와는 독립적으로, 다시 말해서 누가(Who), 어떻게(How), 그리고 전산화는 별개로 비즈니스 데이터에 존재하는 사실들을 인식하여 기록하는 것이며, 이것은 기법으로서의 의미를 넘어 하나의 철학이라고도 할 수 있다.

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

이 단계에서 수행하는 또 한 가지 중요한 활동은 정규화이다. 정규화는 논리 데이터 모델 상세화 과정의 대표적인 활동으로 논리 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 엔터티에 배치되도록 함으로써 좀 더 신뢰성있는 데이터 구조를 얻는 데 목적이 있다. 논리데이터 모델의 상세화는 식별자 확정, 정규화, M:M 관계 해소, 참조 무결성 규칙 정의 등을 들 수 있으며, 추가적으로 이력 관리에 대한 전략을 정의하여 이를 논리 데이터 모델에 반영함으로써 데이터 모델링을 완료하게 된다. 이에 대한 상세한 내용은 제3장 논리 데이터 모델링에서 다룬다.

 

물리 데이터 모델링(Physical Data Modeling)

데이터 모델링 과정의 세 번째 단계인 물리 데이터 모델링은 논리 데이터 모델이 데이터 저장소로서 어떻게 컴퓨터 하드웨어에 표현될 것인가를 다룬다. 데이터가 물리적으로 컴퓨터에 어떻게 저장될 것인가에 대한 정의를 물리적 스키마라고 한다. 이 단계에서 결정되는 것은 테이블, 칼럼 등으로 표현되는 물리적인 저장 구조와 사용될 저장 장치, 자료를 추출하기 위해 사용될 접근 방법 등이 있다.

계층적 데이터베이스 관리 시스템 환경에서는 데이터베이스 관리자가 물리적 스키마를 설계하고 구현하기 위해서 보다 많은 시간을 투자하여야 한다. 계층적 데이터베이스 관리 시스템 환경에서의 물리적 스키마 설계의 예는 데이터의 디스크상의 위치, 색인화할 레코드, 다양한 최적화 문제 등이다.

이에 비해, 논리 데이터 모델은 매체에 물리적으로 구현되는 것과는 독립적으로 여겨진다. 현실적으로 물리 데이터 모델을 계층적 데이터베이스 관리 시스템에 구현하는 것은 그것이 구현될 하드웨어와 밀접한 관계를 맺고 있다. 그러나 관계형 데이터베이스 관리 시스템의 출현으로 인해 그 초점이 개념 및 논리 데이터베이스 설계로 이동하고 있다. 그래서 관계형 데이터베이스 관리 시스템을 사용하는 조직에서는 데이터베이스 관리자가 잘 유지해야 하는 데이터 항목의 발견과 데이터 항목 간에 존재하는 논리 관계를 이해하는데 더 많은 시간을 할애한다. 관계형 데이터베이스 관리 시스템의 출현으로 인하여 물리적 데이터베이스 설계와 관련된 문제들은 많은 부분 관계형 데이터베이스 관리 시스템 소프트웨어에서 처리되고 있다.

 

모델링 기본원칙

일반적으로 모델링의 방법론, 기법, 도구와 같은 개발 보조 수단의 사용 없이는 시스템이 잘 설계될 수 없을 것이라 생각하게 된다. 하지만 과거의 수많은 시스템들은 이러한 개발 보조기구의 사용없이 성공적으로 개발됐다. 물론 과거의 시스템들은 단순해서 그러할 수 있었다고 주장한다면 그 말 역시 맞는 말이다. 그러나 이러한 사실들은 여기에서 말하려는 모델링의 핵심 사항은 아니다. 프로젝트의 어려움 정도 또는 도구와 기술에 상관없이 좋은 설계를 포함한 훌륭한 시스템 개발은 다음의 단순한 단계로부터 시작한다.

• 해결해야 하는 문제점들을 선별, 결정한다.
• 해결책을 위한 문제점들을 구체화한다.
• 시스템을 구축한다.
• 실제로 구현한다.

시스템 개발 실패의 주요 요인을 무엇이라 생각하는가? 그것은 처음의 요구 사항을 충족시키지 못하는 설계자의 무능력을 들 수 있다. 즉 적절한 시스템이 개발되기 위해서는 요구 사항을 완전하고 정확하게 식별해야 한다. 논리 데이터 모델링은 기능 또는 조직이 사용하는 물리적 설계 구조에 관계없이 기업의 비즈니스에 존재하는 데이터의 명확한 구조 및 정의를 제시한다. 이는 최종 사용자 관점에서 바라보는 정보구조를 개념화하고 추상화시킨 데이터의 구조이다. 다음에 설명할 세 가지 최우선 원칙들은 논리 데이터 모델링의 접근 방식을 성공적으로 이끄는 토대이다.

 

커뮤니케이션 원칙(Communication Principle)

요구 사항은 모든 사람들이 이해할 수 있도록 명확하게 공표됨은 물론 최종 사용자 지향적으로 분명하게 파악되는 수준으로 작성되어야 한다. 논리 데이터 모델링의 주목적은 최종 사용자 데이터에 대한 뷰(View)를 개념화하고 추상화하여 시스템 설계자들에게 전달하는 것이다. 물론 커뮤니케이션 원칙이 최종 사용자들에게만 적용되는 것은 아니다. 다른 배경과 기술을 가진 많은 사람들도 논리 데이터 모형의 이해를 필요로 한다.

[표 5-1-1] 데이터 모델의 이해를 필요로 하는 그룹

그룹명	필요성
최종 사용자	개념화, 추상화, 정규화 기법을 통하여 중복없고, 데이터의 정확성을 보장하는 데이터 구조의 이해 및 사용
시스템 분석가	시스템에서 사용되어질 정확한 데이터의 구조 및 데이터가 갖는 업무 규칙의 이해
데이터베이스 관리자	논리 데이터 모델의 구조와 물리 스키마(데이터의 구조)의 차이점을 이해하고 최종 사용자에게는 데이터의 제공, 시스템 분석가에게는 물리 스키마의 제공을 위한 데이터 구조의 이해
타 프로젝트에서 작업하는 분석가	관련 프로젝트가 데이터를 어떻게 정의하고 있는지를 알아냄. 인터페이스(Interface)가 개발되어지고 데이터가 애플리케이션 또는 시스템 간에 공유되기 위한 데이터 구조 및 업무 규칙의 이해

[표 5-1-1]의 그룹 구성원들과의 커뮤니케이션을 용이하게 하기 위해서는 두 가지의 논리 데이터 모델을 생각해 볼 수 있다. 그것은 비즈니스 지향적인 최종 사용자 데이터 모델과 기술적인 상세 데이터 모델이다. 논리 데이터 모델의 문서와 그림을 작성할 때 그 목적을 명확히 해야 한다. 왜냐하면 모델을 보는 사람들에게 기술적으로 알아보기 힘든 혼란을 주는 것은 곤란하기 때문이다. 이와 같은 명확한 정의를 통해 시스템 개발 관련자와 최종 사용자들간에 비즈니스 요구 사항이 정확히 전달되어야 한다.

 

모델링 상세화 원칙(Granularity Principle)

데이터의 상세화 정도를 제시하고 조직이 사용하는 정보 구조의‘최소 공통 분모’를 제시해야 한다. 또한 복잡한 구조는 요소적인 부분들로 쪼개야 하며 불필요한 구조와 중복은 제거되어야 한다. 일반적으로 논리 데이터 모델은 너무 상세화 될 필요가 없다 든지 애플리케이션에 대한 상세화는 물리 데이터 모델에서 이룰 수 있다는 생각은 위험한 태도이다. 모델링의 상세화 원칙은“데이터는 데이터의 본질과 잠재적 사용을 이해할 수 있을 만큼 상세화되어야 한다”는 것을 의미한다. 사실 좋은 설계는 분석 단계(논리 데이터 모델)를 위한 상세 수준이 다른 단계(물리 데이터 모델)에서 선택된 수준만큼 상세화되어야 한다는 것을 의미한다.

많은 모델러(Modeler)가 겪는 문제는 논리 데이터 모델에서 물리 데이터 모델로의 이동이 분해 과 정이라고 오해하는 것이다. 하지만 논리 데이터 모델에서 물리 데이터 모델로의 이동은 분해가 아니 라 보통 수준의 상세화에서 발생하는 변환(Transformation)이다. 즉, 물리 데이터 모델링은 논리 데이터 모델에 대한 변환 과정이다. [그림 4-1-3]을 참조한다.

 

논리적 표현 원칙(Logical Representation Principle)

조직의 데이터에 대한 논리적 측면을 최대한 표현해야 한다. 모델은 물리적 제약 조건 없이 비즈니스를 그대로 반영해야 한다. 즉, 논리 데이터 모델은 특정 아키텍처, 기술 또는 제 사용자들이 항상 시스템 개발자들에게 가지는 주요 불만 사항은 바로 ‘이해의 부족’이다. 사용자가 원하는 것에 근거를 두지 않은 프로젝트는 실패할 확률이 높다. 또한 기존 애플리케이션에 대한 빈약한 문서화의 주요 원인 중 하나는 성급하게 물리적 설계 단계로 들어가려 하는 분석가들의 성향 때문이다. 논리적 설계와 물리적 설계를 구별하지 못하면 프로젝트가 추 구하고자 하는 물리적 선택 사항을 제한하거나 잘못된 방향으로 진행하게 된다. 이러한 문제들을 예를 통해 이해해 보자.

1) 웬만한 분석의 결과는 잘 알고 있다(지름길을 좋아하는 것)

어떤 이들은 여러 가지 이유(예를 들어, 자명하게 보이는 분석을 수행하는 데 시간 낭비를 줄이기 위해 또는 결과가 이미 정해져 있어서)때문에 분석을 생략하는 경우가 많다. 대부분의 경우에서 모델러들은 애플리케이션 개발 과정에서 발생할 수 있는 모든 것들을 알 수 없다. 또한 모델러들은 몇 십년내에 시스템에서 발생할 수 있는 것에 대해서도 확신하지는 못한다. 결론적으로 최적의 행동은 솔루션에 독립적인 방식으로 규칙을 따르고 문제를 문서화하는 것이다.

2) 조급하게 솔루션을 구체화하는 것

문제를 조사할 때 데이터베이스가 어떻게 구현되어야 하는가에 관한 기발한 아이디어가 나오기란 어렵다. 이러한 점에서 섣불리 솔루션을 구체화하는 것은 잘못된 것이다. 그 이유는 문제의 일부분만을 파악했을 때 이를 해결할 수 있는 모든 데이터가 확보된 것은 아니며, 나중에 인식한 문제로부터 다른 솔루션을 발견할 수도 있기 때문이다. 또한 문제가 정확히 진술된 것이 아니기 때문에 작업물을 검토하는 다른 사람들은 솔루션이 문제를 해결하는 이유를 이해할 수 없을 것이다. 이것은 분석가들이 솔루션을 그들의 머리에서 없애야 한다는 것이 아니라 솔루션에 대한 좋은 생각이 표면화되었을 때 그것을 기록하여 논리적 설계 다음에 물리 데이터 모델 설계자에게 전달하여야 한다는 것을 의미한다.

논리적 설계의 컴포넌트가 부정확하거나 빼먹었을 때 물리 데이터 모델에서 논리 데이터 모델로의 회귀는 피할 수 없다. 물리 데이터 모델 제약 조건이 명시된 경우 조차도 논리 데이터 모델은 제약 조건이 없는 것처럼 진행해야 한다. 그럼에도 불구하고 이러한 경우들이 논리적 표현 원칙을 변화시키지는 않는다. 논리 데이터 모델링이 2년짜리 프로젝트의 첫 단계이든지 수많은 2주 짜리의 반복 과정이든지에 상관 없이 원칙은 솔루션을 구체화하기 전에 문제를 이해해야 한다는 것이다.

 

좋은 데이터 모델의 요소

일반적으로 시스템 구축 과정에서 생성되는 데이터 모델은 품질을 평가하는 것이 매우 어렵다. 사실은 특정 데이터 모델이 업무 환경에서 요구하는 사항을 얼마나 잘 시스템적으로 구현할 수 있는가를 객관적으로 평가할 수 있다면 가장 좋은 평가 방법일 것이다. 하지만 이것을 객관적으로 평가할 수 있는 기준이 존재하지는 않는 것이 현실이다. 다음에서는 이러한 상황에서 대체적으로 좋은 데이터 모델이라고 말할 수 있는 몇 가지의 요소를 설명한다.

 

완전성(Completeness)

업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의되어 있어야 한다. 완전성은 데이터 모델을 검증하기 위해서 가장 먼저 확인해야 할 부분이다. 이 기준이 충족되지 못하면 다른 어떤 평가 기준도 의미가 없어진다. 만약 보험사의 데이터 모델에 고객의 직업을 관리하기 위한 속성이 존재하지 않는다면 어떻겠는가? 이것은 심각한 데이터 모델의 문제점이다.

 

중복 배제(Non-Redundancy)

하나의 데이터베이스 내에 동일한 사실은 반드시 한 번만 기록하여야 한다. 예를 들면, 하나의 테이블에서‘나이’칼럼과‘생년월일’칼럼이 동시에 존재한다면 이것은 데이터 중복이라고 볼 수 있다. 이러한 형태의 데이터 중복 관리로 인해 여러 가지의 바람직하지 않는 형태의 데이터 관리 비용을 지불하고 있다. 예를 들면, 저장 공간의 낭비, 중복 관리되고 있는 데이터의 일관성을 유지하기 위한 추가적인 데이터 조작 등이 대표적으로 낭비되고 있는 비용이라고 볼 수 있다.

 

비즈니스 룰(Business Rules)

데이터 모델에서 매우 중요한 요소 중에 하나가 데이터 모델링 과정에서 도출되어 지고 규명되어지는 수많은 업무 규칙(Business Rules)을 데이터 모델에 표현하고 이를 해당 데이터 모델을 활용 하는 모든 사용자가 그 규칙을 공유할 수 있게 제공하는 것이다. 특히 데이터아키텍처에서 언급되는 논리 데이터 모델(Logical Data Model)에서 이러한 요소들이 포함되어야 함은 매우 중요한 요소라고 할 수 있다. 예를 들면, 보험사의 사원들은 매월 여러 가지 항목에 대해 급여를 지급받고, 이를 데이터로 관리하고 있다. 각 사원들은 월별로 하나 이상의 급여 항목(기본급, 상여금, 수당, 수수료, 등등)에 대해 급여를 지급받는다. 여기에 더 나아가 각 사원은 사원 구분별(내근, 설계사, 계약직, 대리점 등)로 위의 급여 항목을 차등적으로 지급받는다는 업무 규칙이 존재한다. 이러한 내용을 데이터 모델에 나타내어야 한다. 이렇게 함으로써 해당 데이터 모델을 사용하는 모든 사용자(개발자, 관리자등)가 해당 규칙에 대해 동일한 판단을 하고 데이터를 조작할 수 있게 되는 것이다.

 

데이터 재사용(Data Reusability)

데이터의 재사용성을 향상시키고자 한다면 데이터의 통합성과 독립성에 대해서 충분히 고려해야 한다. 무슨 이야기인가? 과거에 정보시스템이 생성되고 운영되던 형태를 되짚어보면 철저하게 부서 단위의 정보시스템으로 설계되고 운용되어 왔다. 현재 대부분의 회사에서 진행하고 있는 신규 정보 시스템의 구축 작업은 어떻게 이루어지고 있는가? 회사 전체 관점에서 공통 데이터를 도출하고 이를 전 영역에서 사용하기에 적절한 형태로 설계하여 시스템을 구축하게 된다. 이러한 형태의 데이터 설계에서 가장 중요하게 대두되는 것이 통합 모델이다. 통합 모델이어야만 데이터 재사용성을 향상시킬 수 있다. 또 다른 측면에서 보면 과거 정보시스템의 데이터 구조의 가장 큰 특징은 데이터 모델이 별도로 존재하지 않고 애플리케이션의 부속품 정도로 인식되어져 왔던 것이 사실이다. 이러한 환경에서의 데이터는 프로세스의 흐름에 따라 관리되게 마련이다. 이러면 데이터 중복이 많이 발생하고 데이터의 일관성 문제가 심각하게 초래된다. 데이터가 애플리케이션에 대해 독립적으로 설계되어야만 데이터 재사용성을 향상시킬 수 있다.

 

안정성 및 확장성(Stability and Flexibility)

정보 시스템은 비즈니스의 변화에 대해 최적으로 적응하도록 끊임없이 요구 받고 있다. 하지만 정보시스템의 데이터 모델은 이러한 변화에 대해 어떻게 대응할 수 있는가? 현재의 데이터 구조를 거의 변화하지 않고도 변화에 대응할 수 있는 데이터 구조도 있을 것이고, 아주 적은 확장을 통해 이러한 변화에 대응하는 것도 있을 것이다. 하지만 이러한 변화에 대응하기 위해 데이터 구조적으로 아주 많은 변화를 주어야만 한다면 변화의 대상이 되는 부분뿐만 아니라 정보시스템의 나머지 부분들도 많은 영향을 받게 될 것이다. 그래서 많은 기업이 정보시스템을 구축하는 과정에서 데이터 구조의 확장성, 유연성에 많은 노력을 기울이고 있다. 그렇다면 어떤 데이터 모델이 이러한 확장성을 가진 데이터 모델인가?

현대의 기업들이 동종의 타 기업으로부터 경쟁 우위에 자리매김하려고 한다면 구축하는 데이터 모하게 대응할 수 있어야 한다. 특히 근래의 많은 패키지 시스템이 가지고 있는 데이터 모델들은 확장성을 강조하기 위해서 많은 부분을 통합한 데이터 모델 형태를 가지고 있는 것을 볼 수 있다. 여기에서도 잘 나타나듯이 확장성을 담보하기 위해서는 데이터 관점의 통합이 불가피하다. 특히 정보시스템에서의 ‘행위의 주체’가 되는 집합의 통합,‘ 행위의 대상’이 되는 집합의 통합, ‘행위 자체’에 대한 통합 등은 전체 정보시스템의 안정성, 확장성을 좌우하는 가장 중요한 요소라 할 수 있다.

 

간결성(Elegance)

데이터 모델이 갖추어야 하는 중요한 요소 중 하나는 기업이 관리하고자 하는 데이터를 합리적으로 균형이 있으면서도 단순하게 분류하는 것이다. 아무리 효율적으로 데이터를 잘 관리할 수 있더라도 그것의 사용, 관리 측면에서 복잡하다면 잘 만들어진 데이터 모델이라고 할 수 없다. 동종의 비즈니스를 영위하는 기업이라고 하더라도 각 회사의 데이터 모델을 비교해 보면 복잡도에는 많은 차이가 있는 것을 볼 수 있다. A 보험사는 계약 업무를 수행하기 위해 10개의 테이블을 정의해 업무를 수행하는 반면에 B 회사는 100개의 테이블을 정의해 동일한 업무를 수행하고 있다. 두 회사의 데이터 모델의 차이점은 무엇인가? 10개의 테이블을 가지고 업무를 수행하고 있는 A 회사의 데이터 모델은 간결하지만 새로운 업무 환경의 변화에 대해 확장성을 가지고 있다. B 회사는 겉으로는 새로운 업무 환경의 변화(신규 상품의 출현 등)에 능동적으로 대처하고 있는 것처럼 보이지만 사실은 보유하고 있는 데이터 모델의 한계로 인해 테이블의 수가 지속적으로 증가해 왔다. 이렇게 됨으로써 데이터 모델은 간결하지 못하고 동일한 형태로 관리되어야 하는 데이터가 복잡한 형태로 관리되어지고, 그들과의 관계를 갖고 있는 다른 여러 가지의 데이터나 복잡한 형태의 관계들이 불가피해 복잡성을 증가시켜왔다. 결국 간결한 모델의 기본적인 전제는 통합이다. 합리적으로 잘 정돈된 방법으로 데이터를 통합하여 데이터의 집합을 정의하고, 이를 데이터 모델로 잘 표현하여 활용한다면 웬만한 업무 변화에도 데이터 모델이 영향을 받지 않고 운용될 수 있게 된다.

 

의사소통(Communication)

데이터 모델의 역할이 많다. 그 중에서도 중요한 것이 데이터 모델의 의사소통 역할이다. 데이터 모델은 대상으로 하는 업무를 데이터 관점에서 분석하고 이를 설계하여 나오는 최종 산출물이다. 데이터 분석 과정에서는 자연스럽게 많은 업무 규칙이 도출된다. 이 과정에서 도출되는 많은 업무 규칙은 데이터 모델에 엔터티, 서브타입, 속성, 관계 등의 형태로 최대한 자세하게 표현되어야 한다. 예를 들면,‘ 사원’테이블에는 어떠한‘사원구분’을 가지는 사원들이 존재하는가? ‘ 정규직’,‘ 임시직’ 사원들이 같이 존재하는가? 아니면 또 다른 형태의 사원들이 존재하는지를 표현해야 한다. 더 나아가서‘호봉’이라는 속성은‘정규직’일 때에만 존재하는 속성인데, 이러한 업무 규칙이 데이터 모델에 표현되어야 한다. 또한 관리하는 사원 중에서‘정규직’사원만이‘급여’테이블과 관계를 가진다. 이러한 부분은 개별 관계로 데이터 모델에 표현되어야 한다. 이렇게 표현된 많은 업무 규칙은 해당 정보시스템을 운용, 관리하는 많은 관련자들이 설계자가 정의한 업무 규칙들을 동일한 의미로 받아들이고 정보시스템을 활용할 수 있게 하는 역할을 한다. 즉, 데이터 모델이 진정한 의사소통 (Communication)의 도구로서의 역할을 하게 된다.

 

통합성(Integration)

기업들이 과거로부터 정보시스템을 구축해왔던 방법은 개별 업무별로의 단위 정보 시스템을 구축하여 현재에까지 유지 보수를 해오고 있는 것이 보통이다. 점진적인 확장과 보완의 방법으로 정보시스템을 사용해 왔기 때문에 동일한 성격의 데이터임에도 불구하고 전체 조직 관점에서 보면 여러 곳에서 동일한 데이터가 존재하기 마련이다. 특히 이러한 데이터 중에서도 고객, 상품 등과 같이 마스터 성격의 데이터들이 분할되어 관리됨으로 인해 전체 조직 관점의 데이터 품질, 관리, 활용 관점에서 많은 문제점이 나타나고 있는 것이 현실이다. 가장 바람직한 데이터 구조의 형태는 동일한 데이터는 조직의 전체에서 한 번만 정의되고 이를 여러 다른 영역에서 참조, 활용하는 것이다. 물론 이때에 성능 등의 부가적인 목적에 따라 의도적으로 데이터를 중복시키는 경우는 존재할 수 있다. 동일한 성격의 데이터를 한 번만 정의하려면 공유 데이터에 대한 구조를 여러 업무 영역에서 공동으로 사용하기 용이하게 정의할 수 있어야 한다. 이러한 이유로 데이터 아키텍처의 중요성이 한층 더 부각되고 있다.

 

 

(DA가이드 4.1.2) 데이터 모델링 기법 이해

데이터 모델 목적

데이터 모델은 데이터베이스 설계에 대한 계획 또는 청사진이다. 설계자와 개발자, 사용자 등 모든 관련자들은 데이터 모델을 통해 구축될 시스템의 데이터 구조에 대한 형상을 이해하고, 요구 사항의 구현과 변경 등에 대해 원활한 의사소통을 도모하게 된다. 예를 들어, 건물을 지을 때 건축설계 회사는 건물 공사 이전에 그 건물을 위한 계획이나 청사진을 작성하게 되는데, 만일 계획 단계에서 어떤 방이 너무 좁거나 불편한 곳이 있다면 단순히 설계 도면의 선을 다시 그림으로써 청사진이 변경될 수 있지만 건물이 완공된 후에 변경이 필요하게 되면 벽, 상하수도, 전기 등 모든 것을 다시 시공해야만 하기 때문에 비용이나 시간 측면에서 많은 손해를 보게 될 것이다. 이와 같이 완공된 건물을 변경하는 것보다는 계획 단계에서의 변경이 훨씬 쉽고 간결하며 비용 면에서도 저렴하기 때문에 설계자는 시공에 앞서 조감도, 평면도, 입체도 등 다양한 논리 도면을 통해 건물주(사용자)가 건물의 논리적인 형태를 쉽게 이해하고 의견을 제시하거나 확정을 할 수 있도록 유도한다. 이때 사용된 도면들은 설계자와 시공자, 건물주 등이 짓고자 하는 건물에 대해 동일한 논리적 모습을 공유하게 함으로써 원활한 의사소통의 수단이 되었다고 할 수 있다.

이러한 논리는 건축 공사뿐만 아니라 시스템 개발도 동일하게 적용될 수 있다. 데이터 모델링 단계에서 업무를 잘못 이해했거나 관계를 잘못 정의한 것이 발견되었다면 해당하는 다이어그램과 일부 관련된 문서만 변경하면 된다. 그러나 데이터베이스와 응용 프로그램 개발이 완료된 후 이러한 오류를 발견하여 수정하려면 이와 관련된 많은 프로그램과 SQL문이 변경되어야 할 뿐만 아니라 데이터가 새로운 구조로 옮겨져야 하는 등 이러한 변경을 반영하는 데 많은 비용과 시간이 필요하게 되기 때문에 가능하면 설계 단계에서 조기에 오류들이 발견되고 정정되도록 원활한 의사소통이 필요하게 되고, 이러한 목적을 달성하는 데 데이터 모델은 최적의 수단으로 활용될 수 있다.

 

개체-관계 모델 기법(Entity-Relationship Modeling)

개체-관계 모델은 1976년에 피터 첸(Peter Chen)에 의해서 최초로 제안되었으며 그의 논문을 통 해 이 모델의 기본적인 구성 요소가 정립되었다. 그 후 데이터 모델을 만들어 주는 많은 도구와 기법 이 소개되었는데 계층적 데이터 모델, 네트워크 데이터 모델, ANSI/SPARC 데이터 모델, 개체-관 계 데이터 모델, 의미 객체 모델 등을 예로 들 수 있다. 이 가운데에서 개체-관계 모델은 표준적인 데이터 모델로 부상했는데 이 모델이 지니고 있는 단순성 때문에 현재 개념/논리 데이터 모델링에서 가장 일반적으로 사용되고 있다. 이 모델에 서브타입이 추가되면서 확장된 개체-관계 모델 (Extended Entity-Relationship model)이 만들어졌으며 이제 일반적으로 개체-관계 모델이라고 하면 이 확장된 개체-관계 모델을 의미한다.

개체-관계 모델은 다음과 같은 목적으로 사용되고 있다.

• 데이터에 대해 관리자, 사용자, 개발자들이 서로 다르게 인식하고 있는 뷰들을 하나로 통합할 수 있는 단일화된 설계안을 만들 수 있다.
• 서로 다른 뷰를 충족시킬 수 있는 데이터 처리와 제약 조건 등의 요구 사항을 정의하기 위해서 이다. 개체-관계 모델은 개체-관계 다이어그램(ERD, Entity Relationship Diagram)으로 표현된다. 개체-관계 다이어그램은 최종 사용자의 관점에서 데이터 구조를 그림 형태로 묘사하기 위해 개체, 관계, 속성이라는 세 개의 기본 요소를 사용하며, 엔터티와 이들 간의 관계를 미리 약속된 도형을 사 용하여 알기 쉽고 일목요연하게 그림으로 표시한 것이라 정의할 수 있다.

본 절에서는 이들 각 요소들을 구체적으로 살펴본다.

 

개체-관계 모델 구성 요소

개체-관계 데이터 모델링은 일반적으로 개발 방법론에 의하여 논리 모델링(논리 데이터 모델링)과 물리 모델링(물리 데이터 모델링)으로 나눌 수 있을 것이다. 논리 데이터 모델이란 각 기업에서 업무를 수행하기 위해 필요한 개체(엔터티)가 무엇이며, 개체의 유일성을 보장해주는 식별자(Unique identifier)가 무엇이며, 각 엔터티 간에는 어떤 상관관계가 있고 필요한 속성이 무엇인지를 설명해주는 그림이다. 즉, 업무 담당자와 IT 시스템 설계자 사이의 의사소통이라 할 수 있다. 여기에서 중요한 것은 논리 데이터 모델링은 데이터베이스나 하드웨어 등과 같은 시스템과 아무런 상관없이 업무에서 필요한 데이터를 그림으로 그려놓고 이를 검증하는 방법으로, 주로 개체-관계 다이어그램을 사용한다는 것이다. 따라서 외래키(FK, Foreign Key), 기본키(PK, Primary Key), 액세스 성능, 분산 시스템 등의 물리적 시스템 환경은 고려하지 않는다. 이 때문에 논리적 모델의 특징은 초기에 엔터티와 엔터티의 관계에서 M:M 관계, 순환 관계(Recursive), 슈퍼/서브 타입(Super/Sub Type), 배타적(Arc) 관계 등을 갖고 있는 개체(엔터티)가 많이 보인다는 점이다. 잘 설계된 논리 데이터 모델은 비록 업무 방식이 바뀌어도 업무 영역이 바뀌지 않는 한 설계 변경이 거의 발생하지 않는다. 이러한 이유 때문에 많은 시스템 설계자는 프로세스 중심의 설계보다 데이터 중심 방식의 설계를 주로 사용한다. 논리 데이터 모델에서 하나의 엔터티는 반드시 물리적으로 하나의 테이블이나 세그먼트가 되지는 않으며, 하나 이상 또는 테이블 한 개의 일부가 될 수도 있다. 물리 데이터 모델링은 논리 데이터 모델링을 기초로 현재의 시스템 환경(네트워크, 하드웨어, 운영체제, 미들웨어, 데이터베이스, 디스크 용량, 분산 등)을 고려하여 최고의 성능 향상을 목적으로 한다.

논리 데이터 모델링에서 물리 데이터 모델링 단계로 넘어오면서 고려해야 하는 작업의 사례는 다음과 같다.

• Super/Sub 관계의 엔터티를 몇 개의 테이블로 만들 것인가
• 배타적(Arc) 관계 엔터티의 외부키(Foreign Key)를 몇 개로 할 것인가
• 성능 향상을 위해 테이블을 추가해야 할 것인가 혹은 통합해야 할 것인가
• 통계 작업을 위해 합계(Summary) 테이블 같은 임시성 테이블을 몇 개로 할 것이며, 유일키를 무엇으로 할 것인가
• 테이블의 칼럼을 다른 테이블에 중복할 것인가, 중복한다면 어떤 애플리케이션이 관련되어 있는 가, 인덱스의 설정, 스냅샷(Snapshot) 또는 뷰(View) 등의 객체가 필요한가
• 분산 환경에서 테이블을 중복할 것인가, 중앙에 필요한 테이블을 따로 가져갈 것인가
• 데이터가 분산 환경에서 이동 시 문제를 어떻게 해결할 것인가

물리 데이터 모델링 단계에서는 이러한 해결 과제가 산적해 있으며, 이를 종합적으로 해결할 때 전체적인 성능 향상을 기대할 수 있다. 위의 개념은 매우 중요하며 논리 데이터 모델과 물리 데이터 모델의 구분이 반드시 필요하다. 왜냐하면 물리적인 디자인은 시스템의 변경에 따라 필수적으로 변경이 되는 요소지만 논리 데이터 모델은 업무 영역이 바뀌지 않는 이상 변경이 거의 없는 특성이 있기 때문이다. 따라서 하나의 그림으로 모델을 관리하게 되어 변경이 일어날 때마다 유지 보수를 하다 보면 현재의 시스템과 상관없는 것으로 전락하게 되고, 결국은 막대한 비용을 들여 만들었던 개체-관계 다이어그램이 존재 가치를 상실하게 될 수도 있다.

 

엔터티(Entity)

엔터티는 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서, 그 대상들 간에 동질성을 지닌 것으로 볼 수 있는 개체 집합이나 그들이 행하는 행위의 집합으로 정의할 수 있다. 동질성은 집합을 어떻게 정의하느냐에 따라 달라질 수 있는데, 집합에 들어갈 개체들의 동일한 성질을 어디까지로 한정할 것인지를 결정하는 것으로 동질성 유무를 판단할 수 있다. 예를 들면, ‘고객’이라는 집합을 ‘우리 상품을 구매한 사람이나 법인’으로 정의했다면 아직 구매를 한 적이 없는 잠재 고객이나 구매 상담자, 또 법인번호가 없는 단체나 개인 사업자 등은 이들과 동질성을 갖지 못한다. 그러나 이들이 현재 어떠한 방법으로든 관리가 되고 있거나 앞으로 관심을 갖고자 하는 범주에 해당한다면 집합의 정의를 더 확장해야만 이들을 고객 집합 내에 끌어들일 수 있다. 집합에 대한 정의 문제는 엔터티의 구성 속성과 관계 정의에도 영향을 미치고, 이것은 결과적으로 데이터 모델 전체의 구성에 영향을 미치게 되므로 엔터티, 즉 집합에 대한 명확한 정의는 데이터 모델링에서 가장 핵심적인 사안이라 할 수 있다. 그러므로 엔터티를 정의할 때는 어떤 대상이 그 엔터티에 속하는지 여부를 명확하게 구분할 수 있도록 정의해야 한다.

엄밀한 의미에서 엔터티는 동질성을 갖는 개별 개체나 행위를 지칭하며, 달리 엔터티 인스턴스(Entity Instance) 라고도 한다. 그리고 이들의 집합을 엔터티 타입(Entity Type)이라고 부른다. 동질성을 갖는다는 의미는 어떤 한 개체(엔터티 인스턴스)를 설명하거나 묘사할 수 있는 특성들(예컨대, 학번, 이름, 학과 등과 같은 항목들)에 대해 다른 여러 개체들이 동일한 특성들로 설명 또는 묘사될 수 있음을 말하며, 이와 같은 개체들의 집합을 엔터티 타입이라고 한다. 예를 들면, 어떤 특정한 학번, 이름, 학과로 특징지어질 수 있는‘홍길동’학생은 엔터티 인스턴스이고, 학번, 이름, 학과 등과 같은 공통적인 특성 항목들을 공유하는 학생들의 집합인 ‘학생’은 엔터티 타입이 된다. 엔터티와 엔터티 타입은 각각‘실체’와‘실체형’으로 번역되어 사용되기도 하나, 일반적으로 엔터티와 엔터티 타입으로 사용하기로 하며, 통상적으로 많은 책들과 실무상에서 엔터티와 엔터티 타입은 엄격하게 구분하지 않고 엔터티로 줄여서 사용하고 있기 때문에, 본 과목에서는 개체나 행위의 집합을 엔터티로 통칭할 것이다.

엔터티는 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성(Attribute)을 갖는데, 예를 들어 ‘학생’이라는 개체 집합은 학번, 이름, 이수학점, 등록일자, 생일, 주소, 전화번호, 전공 등의 속성으로 특징지어질 수 있다. 이러한 속성 가운데에는 개체 집합 전체가 공유할 수 있는 공통 속성도 있고, 개체 집합 중 일부에만 해당하는 개별 속성도 있을 수 있다.

개체-관계 다이어그램을 표기하는 방법은 여러 가지가 있는데, 그것들에 대해서는 뒤에서 설명하기로 하고, 여기서는 그 중 한가지만 리차드 바커(Richard Barker)가 제안한 바커 표기법(Barker Notation)과 정보공학표기법(IE Notation)에 따른 표현을 예로 설명한다. 엔터티를 개체-관계 다이어그램으로 나타낼 때는 [그림 4-1-4]와 같은 모양으로 나타내고 이름을 부여할 수 있다. [그림4-1-4]에서 좌측은 바커 표기법을, 우측은 정보공학표기법(이후 IE 표기법이라 지칭)을 적용한 엔터티 모습의 예이다.

 

속성(Attribute)

속성은 엔터티에 저장되는 개체 집합의 특성을 설명하는 항목이라고 할 수 있다. 엔터티를 명확하고 구체적으로 정의했다 하더라도 이것만으로는 개체 집합의 특성을 설명하기에는 부족함이 있다. 예를 들면, ‘직원’엔터티의 개체인 ‘김철수’와 ‘홍길동’은 독립적인 사람 개체임에는 분명하지만 이들의 특성을 설명할 수 있는 보다 구체적인 항목(속성)이 없으면 이 집합을 명쾌하게 객관화할 수 없다. ‘직원’집합의 특성을 설명하기 위해 직원번호, 직원명, 주민등록번호, 연락전화번호, 거주지, 주소 등과 같은 속성을 정의했다면 이제 이러한 속성 구성을 통해 어떻게 ‘홍길동’이라는 개체를 특징짓고 변별할 것인지를 분명하게 이해할 수 있고, 집합의 의미 또한 좀 더 명확해진다고 할 수 있다. [그림 4-1-5]와 [그림 4-1-6]에서 엔터티의 속성을 표현하는 서로 다른 방법을 보여 주고 있다. [그림 4-1-5]는 엔터티에 연결되는 속성을 타원으로 보여 주고 있다. 이 스타일은 데이터 모델링 소프트웨어 제품이 출현하기 이전에 원래의 개체-관계 모델에서 사용되었다. [그림 4-1-6]은 현재의 데이터 모델링 소프트웨어 제품에서 보편적으로 사용되고 있는 바커 표기법과 IE 표기법의 스타일을 보여 주고 있다.

[그림 4-1-5]의 개체-관계 다이어그램에서 속성은 개체 집합을 나타내는 직사각형에 실선으로 연결된 타원형으로 표현되며, 각 타원형은 고유의 속성 이름을 갖는다. 또한 각 속성은 가질 수 있는 값의 범위가 있는데, 이를 그 속성의 도메인(Domain)이라 한다. 예를 들면 학생이라는 엔터티가 있을때 학점이라는 속성의 도메인은 0.0에서 4.0 사이의 실수 값이며, 주소라는 속성은 길이가 20자리 이내의 문자열로 정의할 수 있다. 여기서 물론 각 속성은 도메인 이외의 값을 갖지 못한다.

 

일반적으로 서로 다른 개체 집합에 정의된 속성은 같은 도메인을 공유할 수 있다. 예를 들면, 학생 개체 집합에서 주소 속성에 해당하는 도메인과 교수 개체 집합에서의 주소 속성 도메인은 같은 값들의 범위를 가질 수 있다. 개체 집합 내에서 각각의 개체를 식별할 수 있도록 하나 또는 그 이상의 속성들로 이루어진 속성 집합을 식별자(Unique Identifier)라고 하는데, 이 속성들이 개체 집합 내의 각 개체를 유일하게 지정한다. 예를 들면 학번, 성명, 주소, 생년월일, 학과 등의 속성들로 이루어진 학생 엔터티에서 학번 속성은 하나의 식별자가 될 수 있다.

[그림 4-1-7]은 자동차 개체 집합의 속성 구성을 나타낸 것이며, ‘ID_NUM’이라는 속성에 밑줄을 친 것은 식별자를 의미한다. [그림 4-1-6]과 같은 표현에서는 ‘#’표시가 붙은 속성이 식별자이다. 속성은 단순형 혹은 복합형으로 분류할 수 있다. 예를 들면, 주소 속성은 시, 구, 동, 번지 등과 같은 여러 세부 속성들로 구성될 수 있는데, 이를 복합 속성(Composite Attribute)이라 한다. 또한 나이, 성별 등의 속성은 더 이상 다른 속성들로 구성될 수 없는 단순한 속성이므로 단순 속성(Simple Attribute)이라 한다. 속성은 관리 목적이나 상세화 정도에 따라서 단일 값(Single Value) 또는 다중 값(Multi Value)을 가질 수 있다. 주민등록번호와 같은 속성은 반드시 하나의 값만 존재하므로 이 속성은 단일치 속성(Single-Valued Attribute)이라 하고, 어떤 사람 전화번호와 같이 여러 개의 값을 가질 수 있다. 자동차의 색상 속성도 차 지붕, 차체, 외부의 색이 다를 수 있다. 이런 속성을 다중치 속성(Multi-Valued Attribute)이라 한다.

[그림 4-1-7]과 같은 표현에서 다중치 속성은 두 개의 실선으로 표시한다. 개체-관계 모델에서는 복합 속성, 다중치 속성을 정의할 수 있지만, 직접 구현은 불가능할 수도 있다. 이를 위해서는 M:M 관계나 다수의 속성 또는 1:M 관계의 추가 엔터티를 사용하여 수정해 주어야 한다. 만약 다중치 속성이 존재하면 설계자는 아래의 방법 중 하나를 선택하여 해결할 수 있다.

1) 엔터티 내에서 다중치 속성을 여러 개의 새로운 속성으로 나눈다. [그림 4-1-7]에서의‘COLOR’ 속성에 대해 [그림 4-1-8]과 같은 새로운 속성을 만들어 [그림 4-1-7]에서‘CAR’개체형의 속성들로 부착시킨다.

2) 다중치 속성을 구성하는 속성들로 구성된 새로운 엔터티를 만든다. 이때 새로운 엔터티는 원래 엔터티와 M:1 관계를 맺게 한다. [그림 4-1-8]의‘COLOR’속성을 떼어내어 새로운 엔터티로 만들면 새로운 엔터티‘COLOR’는‘CAR’개체형과 M:1 관계가 될 것이다. 속성 중에는 유도 속성 (Derived Attribute)으로 분류될 수 있는 것도 있는데, 이 속성은 다른 속성의 값으로부터 어떤 계산을 통해 새로운 값을 얻게 되므로 집합의 본질이나 특성을 규명하기 위한 속성을 고려할 때 제외할 수도 있다. 예를 들면, 어떤 사람의 나이 속성은 현재 날짜로부터 생년월일 속성의 값을 뺌으로써 나이의 값을 유도할 수 있다. [그림 4-1-9]에서와 같은 표현에서 유도 속성은 점선으로 표시된다.

 

 

식별자

엔터티의 각 개체들은 인스턴스라고 하는데, 인스턴스는 그들을 지칭하거나 식별해 주는 속성인 식별자(Unique Identifier)를 가지고 있다. 예를 들어, 직원 인스턴스는 직원번호, 주민번호, 직원명으로 식별될 수 있다. 이들 중 직원명은 실세계에서는 직원 각각을 식별하는 데 이용될 수 있으나 데이터 측면에서는 동명이인의 문제 때문에 식별성이 미약한 편이다. 봉급이나 입사일 같은 속성으로는 각각의 인스턴스를 유일하게 식별할 수 없다. 이와 마찬가지로 고객은 고객번호나 고객이름으로 식별될 수 있고, SALES-ORDER은 OrderNumber(주문번호)에 의해서 구별될 수 있다.

식별자는 하나 또는 그 이상의 속성으로 구성된다. 특히 두 개나 그 이상의 속성으로 이루어진 식별자를 복합 식별자(Composite Identifier)라 부른다. 그 예로는 (Area Code, Local Number), (Project Name, Task Name), (First Name, Last Name, Date Of Hire) 등이 있다. 식별자와 키는 구별하여 사용되어야 하며, 이 둘은 서로 일치할 수도 있고 그렇지 않을 수도 있다. 즉 식별자는 논리적인 관점에서 사용되고 키(Key)는 물리적인 관점에서 사용된다. 따라서 엔터티는 식별자를 가지며, 테이블은 키를 가진다고 할 수 있다. 이러한 이유로서 식별자가 엔터티에 대해 하는 역할은 키가 테이블에 대해 하는 역할과 동일하다.

엔터티는 데이터 모델에서 3단계의 상세 수준으로 표현된다. 때로는 엔터티와 그것이 가지는 속성 모두가 표시되기도 한다. 이 경우 [그림 4-1-10]에 나와 있는 것과 같이 식별자 속성을 표현하기 위해 바커 표기법에서는 #이 식별자 속성 앞에 그려지고, IE 표기법에서는 엔터티 박스 내부의 상단에 식별자 속성을 표시한다. 데이터 모델에서는 모든 속성을 자세히 표현하면 개체-관계 다이어그램을 다루기가 힘들어진다. 이 경우에는 [그림 4-1-11]에서처럼 식별자만 보이거나 [그림 4-1-12]에서처럼 엔터티 박스 안에 엔터티 이름만 간결하게 보일 수도 있다.

 

데이터 모델링의 초기 단계에서부터 모델을 지나치게 상세히 표현하면 개체-관계 다이어그램을 이해하고 다루기가 힘들어질 수도 있기 때문에 [그림 4-1-11]에서처럼 간단하게 식별자만 보이거나 [그림 4-1-12]에서처럼 직사각형 안에 개체 이름만 간결하게 보임으로써 많은 모델들 중에서 사용자가 필요한 것들을 손쉽게 식별하게 하기도 한다. [그림 4-1-11]과 [그림 4-1-12]에서 위는 바커 표기법을 사용한 엔터티의 약식 표현이며, 아래는 IE 표기법을 사용한 엔터티의 약식 표현이다. 세가지 기법 모두가 실제로 사용되며, [그림 4-1-12]의 더 간결한 형식은 상위 수준의 개요와 전반적인 개체-관계를 보여주는 데 사용된다.

 

관계(Relationship)

관계는 엔터티와 엔터티 간 연관성을 표현하는 것으로, 엔터티의 정의에 따라 영향을 받기도 하고, 속성 정의 및 관계 정의에 따라서도 다양하게 변할 수 있다. 엔터티 간에 논리적으로 존재할 수 있는 수많은 관계 중에서 정말로 의미가 있고 관리할 가치가 있는 관계를 식별해 낸다는 것이 쉬운 일은 아니다. 최초의 개체-관계 다이어그램에서 관계는 속성을 가질 수 있었으나 현재는 그렇지 않다. 관계의 표현에는 이항 관계(Binary Relationship), 삼항 관계(Ternary Relationship), n항 관계가 존재할 수 있는데, 실제 삼항 관계 이상은 잘 사용되지 않는다. [그림 4-1-13] 참조 매핑 카디날리티(Mapping Cadinality)는 개체-관계 다이어그램에서 개체와 연결될 때 나타나는 대응(Mapping)되는 수로 대응수라고도 한다. 대응수는 최대 대응수(Maximum Cadinality)와 최소 대응수(Minimum Cadinality)로 구분된다. 매핑 카디날리티가 포함된 개체-관계 다이어그램에 대하여 예제를 통해 설명하고자 한다. [그림 4-1-13] 참조

다음과 같은 조건하에서 교수 개체와 학생 개체 간에 성립하는 지도 관계의 매핑 카디날리티를 결정하고, 개체-관계 다이어그램을 작성하면 [그림 4-1-13]과 같은 이항 관계 구조의 다이어그램을 완성할 수 있다.

■ 조건 1 : 교수는 꼭 학생에 대한 지도를 해야 한다. <min-card(교수, 지도)="1</p"></min-card(교수,>

■ 조건 2 : 교수는 여러 명의 학생을 지도할 수 있다. Max-Card(교수, 지도) = n

■ 조건 3 : 학생은 꼭 교수에게 지도를 받아야 한다. Min-bCard(교수, 지도) = 1

■ 조건 4 : 학생은 여러 명의 교수에게 지도를 받을 수 없다. Max-Card(교수, 지도) = 1

 

 

카디날리티(Cardinality)

개체-관계 다이어그램은 데이터베이스가 지켜야 할 제약 조건들을 명시할 수 있다. 중요한 제약 조건 중의 하나로 연결(Connectivity)이라는 것이 있는데, 이는 한 개체가 관계를 통하여 다른 개체 와 관련된 개체들의 수를 나타낸다. 관계의 연결은 1:1, 1:M, M:M으로 분류된다. 개체-관계 다이어그램에서는 관계의 연결을 1, M을 사용하여 표현하며 [그림 4-1-14]의 예와 같다. 표기법에 따라서 는 M:M을 M:N으로 표현하기도 하지만 여기서는 M:M으로 나타내기로 한다.

• 일대일(One To One, 1:1) : X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속하는 한 개체도 X 에 속하는 한 개체에만 연결된다.
• 일대다(One To Many, 1:M) : X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속하는 한 개체는 X에 속하는 여러 개체와 연결된다
• 다대다(Many To Many, M:M) : X에 속하는 한 개체는 Y에 속하는 여러 개체와 연결될 수 있으며, Y에 속하는 한 개체도 X에 속하는 여러 개체와 연결될 수 있다.

또한 카디날리티(Cardinality)란 관계에 참여하는 하나의 개체에 대해 다른 엔터티에서 몇 개의 개체가 참여하는지를 나타낸다. 예를 들면, 한 명의 학생이 1개 이상 6개 이하의 과목에 등록할 수 있다면 카디날리티는 (1, 6)이다. 한 명의 교수가 최대 3개의 과목을 가르칠 수 있다면 카디날리티는 (0, 3)이다. 카디날리티는 (Min, Max)의 값 한 쌍으로 표현하는데, 여기서 Min은 관계에 참여하는 개체의 최소 개수, Max는 관계에 참여하는 최대 개수를 각각 의미한다. 여기서 Max의 값이 M으로 표시되면 최대 개수에 제한이 없음을 의미한다. [그림 4-1-15]에서 PROFESSOR-COURSE의 관계를 살펴보면 다음과 같이 해석할 수 있다.

1) PROFESSOR-COURSE는 1:M 관계이다.

2) PROFESSOR의 카디날리티는 (0, 3) 이다. 즉 각 교수는 3개 이하의 과목을 가르칠 수 있다.

3) COURSE의 카디날리티는 (1, 1)이다. 즉 각 과목을 가르치는 교수는 반드시 1명이어야 한다.

 

존재 종속

만약 한 엔터티의 존재가 다른 엔터티(들)의 존재에 영향을 받는다면 이를 존재 종속(Existence-Dependent)이라 한다. 예를 들어, 어느 보험회사가 J. H. Callifante라는 사원과 그의 부양 가족들에게 보험 혜택을 준다고 할 때 EMPLOYEE, DEPENDENT라는 엔터티들을 정의한다고 하자. J. H.Callifante에게 Jill, Annelise, Jorge라는 3명의 부양 가족이 있다면 부양 가족 3명은 J. H.Callifante 없이는 보험 혜택을 받을 수 없다. 다시 말해 부양 가족 3명의 정보가 DEPENDENT라는 테이블에 존재하지만 EMPLOYEE와 연관지어 있을 때만 존재하게 된다. 이러한 것을 존재 종속이라 한다. 만약 J. H. Callifante가 직장을 그만 두어 테이블에서 없어지게 되면 부양 가족 3명도 함께 없어지게 된다. 여기서 DEPENDENT의 식별자는 EMPLOYEE의 키인 E_NUM과 DEP_NUM으로 구성된다. 두 개의 테이블들을 연결시켜 보면 J. H. Callifante는 3명의 부양 가족이 있고, W.K. Smithson은 부양 가족이 없음을 알 수 있다.

 

서브타입

확장된 개체-관계 다이어그램은 서브타입의 개념을 도입했다. 서브타입은 정확한 의미로는 서브 타입 엔터티이며 그것의 전체집합인 슈퍼타입(Supertype)의 부분집합이다. 예를 들어 학생들은 학 부학생이나 대학원생으로 분류될 수 있다. 이 경우 학생이 슈퍼타입이고 학부학생과 대학원생은 서브타입이다.

[그림 4-1-17]은 바커 표기법에 따른 서브타입 표현으로, 슈퍼타입인 사원은 서브타입인 내근사원, 설계사, 대리점을 가지고 있다. 슈퍼타입은 세 서브타입에 공통적인 모든 속성을 포함하고 있고, 서브타입은 각 서브타입에 적절한 속성만을 포함하고 있다. [그림 4-1-17]에서 속성 ‘사원구분’은 내근사원, 설계사, 대리점인지를 가리킨다. 어떤 서브타입이 적합한지를 결정해 주는 속성을 구분자(Discriminator)라고 부른다. IE 표기법을 사용하는 툴을 사용하면 [그림 4-1-18]과 같이 구분자는 서브타입 부호 바로 옆에 나타난다.

 

모든 슈퍼타입이 구분자를 가지고 있는 것은 아니다. 만일 구분자가 없다면 적합한 서브타입을 생성하기 위해 응용 코드가 작성되어야 한다. 서브타입은 배타적(Exclusive) 또는 포괄적(Inclusive)일 수 있다. 만약 배타적이라면 슈퍼타입은 많아야 1개의 서브타입과 관련될 수 있다. 만약 포괄적이라면 슈퍼타입은 1개 또는 그 이상의 서브타입과 관련될 수 있다. [그림 4-1-19]는 IE 표기법에 따라 MANAGER와 DB_ADMIN을 서브타입으로 가진 사원 슈퍼타입의 형태를 표현한 사례이다. 돔 안의 X는 서브타입이 배타적인 것을 의미한다. 따라서 사원은 MANAGER나 DB_ADMIN 중 하나가 될 수는 있으나 둘 다 될 수는 없다. 이에 대한 구분은 서브타입을 의미하는 돔 옆에 서브타입 구분자를 표시하여 이 서브타입 구분자 속성을 통해 사원이 어느 서브타입에 속하는지 알 수 있음을 표현하고 있다. [그림 4-1-20]은 이러한 동일한 서브타입을 포괄적으로 보여주고 있다. 여기서 사원 슈퍼타입은 MANAGER, DB_ADMIN, 또는 양쪽 모두 될 수도 있는 포괄적 서브타입의 형태로 표현되어 있으며, X가 없는 돔 형태를 사용하여 두 개 이상의 서브타입과 관련된 포괄적 서브타입을 표현한다. 여기서 돔 옆에 서브타입 구분자를 나타내지 않음은 특정한 서브타입 구분자 속성을 가지고 있지 않음을 의미한다. 이와 같이 배타적 서브타입이나 포괄적 서브타입을 표현할 때 서브타입 구분자를 지정하지 않고 서브타입을 표현하는 것은 가능하나, 서브타입 구분자를 사용하지 않게 되면 인스턴스가 어느 유형에 해당하는지 알기 위해 주변 속성들을 확인해 보아야 하기 때문에 불가피한 경우가 아니면 효율성 측면에서 바람직하지 않다.

 

객체지향 모델링(Object-Oriented Modeling)

과거, 소프트웨어 생산성 향상은 상당히 힘든 일로 여겨졌다. 구조적 기법, 방법론, 4세대 언어, 관계형 DBMS, CASE 도구는 시스템 개발상의 문제점을 없애고 비용을 절감하고 소프트웨어 개발의 품질을 향상시키기 위해 시도되었다. 그러나 대부분의 시도는 실패로 끝났다. 최근의 접근 방식 중의 하나가 재사용 코드(Reusable Code)의 개념에 초점을 둔 것이다. 이 개념은 한번 소프트웨어 루틴 (Routine)을 저장해 놓고 그것을 모든 프로그래머들과 공유하는 것을 말하는 것이다. 많은 노력 끝에 방법론과 CASE와 같은 많은 접근 방식들의 결합(Combination)은 재사용 코드에 대한 실제적인 성 과로 생산성의 이익을 가져왔다. 많은 개발자들은 이 새로운 접근 방식이 향후 시스템 개발에 있어 지배적인 대세가 될 수 있다고 확신하고 있다. 만약 이것이 성공한다면 객체지향 접근 방식은 애플리케이션이 어떻게 개발되어야 하는지를 과감하게 변화시킬 수 있을 것이다. 객체지향 개발은 전체 시스 템 개발 영역을 다루고 있다. 그것의 종류는 아래와 같다.

• 객체지향 방법론
• 객체지향 분석
• 객체지향 설계
• 객체지향 모델링
• 객체지향 프로그래밍
• 객체지향 DBMS

객체지향 개발이 시작된다면 그것은 시스템 개발 생명 주기의 많은 부분(논리적 데이터 모델링을 포함해서)에 영향을 미칠 것이다. 객체지향 모델링의 간단한 개요를 제시하고 그것이 어떻게 논리적 데이터 모델링의 스키마에 적합하게 되는지를 살펴보자.

 

객체지향 개념

객체지향 모델링은 객체지향 개발의 기본이다. 여기에서 객체지향에 대한 특성과 개념을 발견할 수 있을 것이다. 우선 객체지향의 용어를 검토해 보자. 조직이나 시스템은 객체(Object)라는 것에 관련되어 있고 객체에 대한 정보를 저장한다. 고객, 직원, 교실, 책, 그리고 전표 등이 객체의 예이다. 객체는 대개 객체를 기술하는 데이터와 그 기술 데이터를 운영하는 메소드(Method)로 구성된다. 속 성 유형과 메소드를 공유하는 객체가 그룹화되어서 객체 클래스(또는 클래스)로 된다. 객체 인스턴스 는 객체 클래스의 어커런스이다. 예를 들어, 직원이 객체 클래스이면‘홍길동’은 클래스 직원의 객체 인스턴스이다.

객체는 속성과 메소드로 구성된다. 속성은 객체클래스의 성질이다. 이름, 주문번호, Color, 그리 고 책제목 등은 속성의 예이다. 속성값이 바로 객체 인스턴스의 성질인 것이다. 메소드는 하나 이상 의 속성을 접근, 조작, 수정, 삭제, 생성하는 프로세스이다. 예를 들어‘신규조직을 추가하라’또는 ‘주문서를 작성하라’등이 그 예이다.

객체는 연관(Association) 또는 상속(Inheritance)을 통해서 다른 객체들에 연결된다. 연관은 객 체 간의 자연적 관계이다. 비??다. 예를 들어, 고객은 제품을 산다. 그래서 고객 객체와 제품 객체 간의 자연적 관계인‘산다’가 있다. 연관은 카디날리티 와 모달러티(선택적 그리고 의무적)를 가질 수 있고 연관은 하나, 둘, 셋 이상 객체들 간에 존재할 수 있다.(즉 일항, 이항 그리고 다항)

반적인 객체(상위클래스)를 가지고 제일 아래 (Hierarchy) 조직을 생각해 보면 하위 클래스는 상위 클래스로부터 속성과 메소드를 상속한다. 예를 들어 도매 고객 객체와 소매 고객 객체는 상위 클래스‘고객’의 하위 클래스이다. 이 하위 클래스는 고객 클래스로부터 모든 속성과 메소드를 상속한다. 게다가 하위 클래스는 하위 클래스 고유의 속성 과 메소드를 가질 수 있으며 다른 객체들에게 상위클래스로 작는 것은 그 객체 외부에서 일어나는 것과는 관계가 없다는 것과 같은 구체적 경계 (Boundary)를 가지고 있다. 이것을 일명 캡슐화(Encapsulation)라고 한다. 예를 들어 고객 객체는 ‘신규 고객을 추가하라’라는 메소드를 가지고 있다. 고객 객체는 그 메소드가 호출될(Invoke) 때 무엇을 해야 하는지를 정확히 알고 있다. 그러나 제품 객체에 적용될 때에 그 메소드는 의미가 없다.

고객 객체의 속성과 메소드는 다른 객체들로부터 감추어져 있다. 본질적으로 그 객체는 적절한 메 시지가 전달될 때 작업을 수행하는 ‘블랙박스’이다. 그 작업이 무엇이고 그 작업이 어떻게 수행되는 지는 다른 객체에게 알려지지 않는다. 객체는 메시지를 주고 받음으로써 다른 객체와 통신한다. 예를 들어 구매 객체는 고객 객체에게 고객의 신용 상태를 변화시키라는 메시지를 보낼 수 있다. 캡슐화 때문에 구매 객체는 고객 객체가 신용 상태를 어떻게 변화시키는지 알 필요가 없다. 즉, 메시지‘고 객 신용 상태를 변화시켜라’를 받은 결과로써 고객 객체가 사용하거나 수정하려는 메소드와 속성은 구매 객체에게 전달된다. 이러한 정보는 객체 모형에 표시될 수 있다. [그림 4-1-21]과 같이 객체 모형에서 객체는 굵은 선으로 된 상자(Bold-lined Box)로 표시된다. 연관과 상속의 연결은 두꺼운 선으로 나타난다. [그림 4-1-22] 참조

 

속성이 적거나 별도 문서에 있다면 속성은 [그림 4-1-23]과 같이 객체 상자 안에 기입될 수도 있다. 객체 안의 속성이 속성 자신의 구조를 가질 수 있다면 그 객체는 자기 자신의 논리적 데이터 모델을 가질 수 있다. [그림 4-1-24] 참조

대부분의 객체 메소드는 메소드를 기술하는 서술(Narrative)에 의해서 표현될 수 있다. 그러나 메소드가 복잡하다면, 데이터 흐름 다이어그램(DFD, Data Flow Diagram)과 같은 다양한 프로세스 모델링 기법 중의 하나가 사용될 수 있다. [그림 4-1-25] 참조

 

메시지는 메시지 이동의 방향을 나타내는 화살표와 점선에 의해 객체 모형에 표현된다. [그림 4-1-26] 참조

 

 

객체 모형

객체 모형을 생성시키기 위해서 아래와 같은 방법을 취한다.

1) 주제에 연관된 기본(Basic) 객체를 식별한다. 그 결과는 엔터티 목록과 같은 것이다.

2) 객체 간의 연관(Association)을 식별한다.

3) 많이 알려져 있는 객체 모델링의 규약을 이용해서 객체의 다이어그램을 그린다.

4) 객체 간의 메시지는 다이어그램에 추가될 수 있다.

 

객체 모형이 완료되었을 때, 각 객체 내부에 대해서 표시하면 된다. 즉, 객체의 속성과 메소드가 문서화될 필요가 있다.

 

객체 모형 데이터

객체 내의 데이터를 문서화하는 것은 상대적으로 간단하다. 그 이유는 객체 내에서 발견된 속성들 은 그 객체의 성질이거나 메시지 안에 전달된 다른 객체의 성질이기 때문이다. 예를 들어 [그림 5- 1-28]에서 메시지 부분으로서의 트랜잭션 객체는 트랜잭션 번호를 주식 중개인 객체에 전달한다. 두 객체의 메시지가 트랜잭션 번호를 사용한다고 할지라도 트랜잭션 번호는 트랙잭션의 성질이지 주식 중개인의 성질은 아니다. 트랜잭션 번호는 트랜잭션 객체 안에 정의되어 있다. 그래서 주식 중개인 객체 안에서 재정의될 필요는 없다. 오직 데이터만이 한번 문서화할 필요가 있다. 그래서 다른 객체 들에 속하는 데이터는 소유 객체 안에만 문서화 된다.

대부분의 경우에서 한 객체 안의 데이터는 구조를 가지지 않는다. 구조상 데이터가 개체-관계 다이어그램에 있다면, 다양한 엔터티 내에 있을 수 있다는 것을 뜻한다. 즉 데이터 구조가 없는 객체는 모든 객체의 속성들이 개체-관계 다이어그램에서 하나의 엔터티 내에 있다는 것을 의미한다. 데이터 구조가 없을 때 객체의 데이터를 문서화하는 것은 객체의 정의와 도메인을 구체화시키는 것으로 제 한된다. 그러나 객체의 데이터가 구조를 가진다면 그 구조는 개체-관계 다이어그램의 단편도 (Fragment Diagram) 안에 모형화되어야 한다.

예를 들어 계좌 객체의 데이터가 정적인(Static) 계좌 정보뿐만 아니라 다양한 활동 항목(Activity Items)을 포함하고 있다면 분석가는 개체-관계 다이어그램 단편도에 계좌와 계좌 활동 간의 일대다 관계를 표현할 것이다. [그림 5-1-28] 참조

객체 모형의 메소드

객체 메소드가 복잡하지 않다면 메소드는 간단한 설명부(Narrative) 또는 구조화된 기법으로 가장 잘 문서화된다. 복잡한 메소드는 좀 더 정교한 문서화 접근 방식이 필요하다. 이벤트 지향적인 프로세스는 상태 전이 모델링(State Transition Modeling)과 같은 동적(Dynamic) 프로세스 모델링 기법이 필요하다. 반면에 정적인 프로세스는 데이터 흐름 다이어그램이나 기능 분해(Functional Decomposition)와 같은 기법을 사용한다. 계좌 객체의 계좌 갱신 메소드는 데이터 흐름 도표에 의해서 문서화된다. [그림 4-1-29] 참조

다이어그램에서 어떻게 트랜잭션 객체가 외부 엔터티로 표현되었는지, 또한 계좌 갱신 메시지가 계좌 객체에 대한 데이터 흐름이라는 점을 유의해야 한다.

다이어그램에서 어떻게 트랜잭션 객체가 외부 엔터티로 표현되었는지, 또한 계좌 갱신 메시지가 계좌한다.

 

불명료한 객체 접근 방식

객체 접근 방식에는 두 가지 주의 사항이 있다. 첫번째는 객체지향 개발의 가장 단순화된 표현이다. 이것은 객체지향 개발을 분명하게 이해하는데 필요한 많은 객체지향 특징을 무시하는 것이다. 불행히도 그러한 특징을 탐색하는 것은 설명하기가 매우 어렵다. 두번째는 객체지향 모델링의 미성숙이다. 객체가 어떻게 표현되고 기호가 어떻게 사용되어야 하는가 등의 정의는 아직까지 초기단계이 다. 현재 접근 방식은 크게 변화하고 있고 많은 개발자들이 표준안을 원한다고 할지라도 이러한 상황은 당분간 계속될 것이다.

 

객체지향 모델링과 논리 데이터 모델링간의 관계

객체지향 모델링과 논리 데이터 모델링은 공통점이 많다. 객체지향 모델링 개념은 논리 데이터 모델 링의 개념과 매우 유사하다. 그러나 많은 유사점에도 불구하고 차이점 또한 존재한다. 객체지향 모델링 에서만 유일한 것은 데이터와 프로세스를 같은 엔터티로 결합시킨 것이다.

[표 4-1-2] 객체지향 모델링과 논리 데이터 모델링 간의 비교

객체지향 모델링	논리 데이터 모델링	차이점
객체	엔터티	객체는 프로세스를 포함한다.
속성	속성	-
연결 (Link)	관계 (Relationships)	유사하다. - 연관은 동일하다. - 상속은 데이터 모델링이 메소드를 포함하지 않는다는 것만 제외한다면 서브타입/슈퍼타입과 동일하다.
캡슐화	-	대응하는 논리적 데이터 모델링의 개념은 없다.
객체 클래스	엔터티 유형	없음
객체 인스턴스	엔터티 인스턴스	없음
메시지	-	메시지는 프로세스와 연관되어 있기 때문에 대응하는 개념은 없다.

논리적 기초가 잘 갖춰진 데이터 모델러는 일반 프로세스 모델러보다 객체지향 모델링 개념을 더 쉽게 소화한다. 많은 객체지향 접근 방식은 논리적 데이터 모델링 접근 방식과 유사하다. 그래서 객체지향 모델링을 논리적 데이터 모델링의 연장으로 간주하기도 한다. 다른 주요 유사성은 두 가지 접근 방식이 다음의 어려움을 공유한다는 것이다. 많은 분석가는 데이터가 프로세스에 종속하지 않는 방식으로 데이터와 프로세스의 개념을 결합한다. 이것은 객체지향 모델링에 기반한 애플리케이션을 개발하는 사람들이 논리적 데이터 모델링의 개념도 잘 이해하고 있기 때문이다. 또한 좋은 접근 방식들은 서로 결합하기 때문이다.

 

객체지향 모델링 장점

객체지향 모델링의 장점은 재사용 코드와 같은 개념이 실제로 가능한 환경을 제공한다는 것이다. 이것은 또 다른 문제를 해결해 준다. 데이터나 프로세스 중 어느 것도 조직의 모든 규칙을 표현할 수는 없다. 일부 규칙은 프로세스 모형에서 표현될 수 있고 일부는 데이터 모형에서 표현된다. 그러나 객체지향 모델링은 모든 비즈니스 규칙이 표현될 수 있는 유일한 환경을 제공한다. 객체지향 모델링은 또한 프로세스와 데이터 모델링을 함께 운영한다. 데이터와 프로세스가 객체의 성질인 반면 데이터와 프로세스 각각은 그들의 풍부함(Richness)을 달성하는 다른 접근 방식을 필요로 한다는 사실이 위의 사항들을 확신하게 한다.

 

 

 

(DA가이드 4.1.3) 데이터 모델링 표기법 이해

 

바커 표기법 (Baker Notation)

바커 표기법은 영국 컨설팅 회사 CACI에 의해 처음 개발되었고 리차드 바커(Richard Barker)에 의해 지속으로 업그레이드 되었다. 오라클에서 Case Method(Custom Development Method)로 채택하여 사용하고 있다.

 

엔터티(Entity)

엔터티는 기업에서 지속적으로 저장하고 관리해야 할 대상이다. 하나의 관리 대상이 엔터티가 되기 위해서는 반드시 두개 이상의 속성을 가져야 한다. 속성이 없는 실체는 존재할 수 없다. 엔터티란 실제 세상에 있는 객체(Object)이다.

• 엔터티는 네 부분의 모서리가 둥근 형태인 소프트-박스(Soft-box)로 표현한다.
• 엔터티는 하나 이상의 속성으로 구성된다.

속성(Attribute)

속성은 하나의 엔터티에 종속되는 명사적 단어들을 말한다. 일반적으로 명사적 단어들 중에 구성 요소를 포함하고 있는 명사들은 엔터티가 되고 그렇지 못한 명사들은 속성이 된다. 속성의 상태에는 2가지 종류가 있다. 해당 속성에 어떤 값을 반드시 저장해야 하는 경우에는 * (Mandatory)를 표시하며 해당 속성에 어떤 값이 존재할 수도 있고 존재하지 않을 수도 있는 경우에는 o (Optional)를 표시하게 된다.

 

관계(Relationship)

두 개의 엔터티간에 CONDITIONAL을 표기한 후 해당 엔터티의 가까운 위치에 관계 명칭을 표기하고 관계(Relationship)는 실세계의 해당 엔터티에서 발생하는 동사적 단어들을 표기한다.

 

1) 엔터티와 엔터티간의 관계

• 1:1 관계

A 엔터티에 존재하는 데이터 1개와 관계되는 B 엔터티에 존재하는 데이터의 개수도 1개인 엔터티간의 관계를 1:1 관계라고 한다.

• 1:M 관계

A 엔터티에 존재하는 데이터 1개와 관계되는 B 엔터티에 존재하는 데이터의 개수가 여러 개인 엔터티 간의 관계를 1:M의 관계라고 한다.

• M:M 관계

A 엔터티에 존재하는 데이터 1개와 관계되는 B 엔터티에 존재하는 데이터의 개수가 여러 개이며, B 엔터티에 존재한 데이터 1개와 관계되는 A 엔터티에 존재하는 데이터의 개수도 여러 개인 엔터티 간의 관계를 M:M 관계라고 말한다.

 

2) 엔터티와 엔터티간 상관 관계의 조건

• 필수 조건

필수 사항은 실선으로 표시하고 상대 엔터티에 대해 해당 엔터티에 조건을 만족하는 엔터티가 반드시 존재할 경우에 표시한다.

• 선택 조건

선택 사항은 점선으로 표시하고 상대 엔터티에 대해 해당 엔터티에 조건을 만족하는 엔터티가 존재할 수도, 존재하지 않을 수도, 있을 경우 표시한다.

 

 

식별자(Unique Identifier)

식별자란 하나의 엔터티에 구성되어 있는 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성을 의미하며 하나의 엔터티는 반드시 하나의 식별자가 존재해야 한다. 보통 식별자와 키(Key)를 동일시 생각하고 있는 경우가 있는데 식별자는 논리 데이터 모델링 단계에서 사용하고 키는 물리 데이터 모델링 단계에서 사용한다.

 

1) 식별자의 유형

• 본질 식별자

속성들 중에서 집합의 본질을 명확하게 설명할 수 있는 의미상의 주어를 본질 식별자라한다. 의미상의 주어에는 사원번호, 상품번호처럼 집합을 식별하기 위한 임의의 유일값을 사용하는 인조 식별자(Artificial Unique Identifier)도 있고, 내가 태어나기 위해서 절대적으로 존재했어야만 하는 본질 속성들에 해당하는 것으로 자신의 고유 속성과 부모로부터 물려받은 속성(릴레이션십)들로 이루어진 것도 있을 수 있다.

• 후보 식별자

각 인스턴스를 유일하게 식별할 수 있는 속성 또는 속성들의 조합이며, 후보 식별자로 속성 집합을 선택하는 경우에는 개념적으로 유일해야 한다.

• 대체(보조) 식별자

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

• 인조 식별자

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

• 실질 식별자

인스턴스를 식별하기 위해 공식적으로 부여된 식별자를 말한다. 본질 식별자나 인조 식별자 모두가 실질 식별자가 될 수 있다.

2) 작성 방법

식별자 앞에는 # 기호를 표시하고 여러 개# 기호를 반복적으로 표시한다.

 

 

서브타입(Sub-type)

바커 표기법에서는 슈퍼타입(super-type) 안에 서브타입(sub-type)을 상자로 나타낸다. 이것은 다이어그램에서 공간을 적게 사용하는 장점을 가지고 있다. 서브타입은 서브타입의 중복을 허락하지 않는 상호 배타적 관계이다.

 

관계의 표현 비교

다음은 바커 표기법과 I/E 표기법의 가장 큰 차이점인 관계의 표현 비교를 설명하겠다. [그림 4-1-36]은 사원과 부서 엔터티 간의 관계를 표현한 모습이다. 릴레이션이란 양방향 관계를 합성한 것이라 할 수 있다. 각 관계를 설명하자면 사원을 주어로 부서를 보는 관계에서 의미는“각각의 사원은 단 하나의 부서를 반드시 가져야 한다”라고 정의할 수 있다. 또한 부서를 주어로 사원을 보는 관계의 정의는 “각각의 부서는 하나 이상의 사원을 현 주소속 부서로서 배치 받을 수도 있다”라는 의미를 표현한 것이 바로 관계선이다. 이때 관계선을 살펴보면 실선과 점선으로 구분할 수 있다. 실선은 필수를 뜻하고 점선은 필수가 아님을 뜻한다. 현재 [그림 4-1-36]의 사원 엔터티가 주어일 경우 사원 엔터티 쪽에 가까이 있는 실선이 바로 사원이 주어일 때 부서를 바라보는 관계를 설명한 것이다. 때문에 까마귀 발 모양은 이미 설명한 것처럼 하나 이상의 개체를 허용한다는 뜻이다. 이런 표시를 근거로 “각각의 사원은 단 하나의 부서를 반드시 가져야 한다”와 같이 정의할 수 있다.

 

I/E 표기법 (Information Engineering Notation)

Information Engineering(I/E)은 1981년에 Clive Finkelstein과 James Martin이 공동 저술로 발표하였으며, 80년대 중반에 James Martin에 의해 그 체계가 정리되면서 본격적으로 활용이 되었고, 정보시스템을 구축하는데 있어서 데이터 분석(Data Analysis)과 데이터베이스 설계(Database Design)를 위한 매우 유용한 기법으로 자리 잡게 되었다. 이 모델은 관계의 다(Many) 쪽을 나타내기 위해 까마귀 발을 사용하기 때문에 때때로 까마귀 발모델(Crow’s Foot Model)이라 부른다.

 

엔터티(Entity)

엔터티란 사용자가 추적하고자 하는 어떤 사물이다.

속성(Attribute)

엔터티는 엔터티의 특징을 기술해 주는 여러 개의 속성을 가진다. 속성은 [그림 4-1-38]과 같이 엔터티 안에 위치한다.

 

관계(Relationship)

까마귀 발 부호는 관계의 다(Many) 쪽을 보여주는 데 사용되고, 타원(Oval), 해쉬 마크 및 까마귀발의 다양한 조합들은 [표 4-1-3]과 같이 사용된다.

 

식별자(Unique Identifier)

엔터티는 그들을 지칭하거나 식별해 주는 속성인 식별자를 가지고 있다. 속성의 식별자는 엔터티의 상단에 나타나며, [그림 4-1-39]와 같이 수평선이 식별자 밑에 그려진다.

 

서브타입(Sub-type)

서브타입은 배타적 또는 포괄적일 수 있다. 만일 배타적이라면 슈퍼타입은 많아야 1개의 서브타입과 관련될 수 있다. 만일 포괄적이라면 슈퍼타입은 1개 또는 그 이상의 서브타입과 관련될 수 있다. [그림 4-1-40]에서 A는 슈퍼타입, B와 C는 배타적 서브타입이다. 구분자는 보이지 않고 있다. 관계는 실선으로 그려져 있다. [그림 4-1-41]에서 A는 슈퍼타입, B와 C는 포괄적 서브타입이다. 관계는 실선으로 그려져 있다.

 

 

 

 

4.2 개념모델링

(DA가이드 4.2.1.) 개념 데이터 모델링 이해

 

개념 데이터 모델 정의

개념적 데이터 모델이란 건물로 말하면 철제빔으로 건물의 골격을 세워 놓은 형태와 유사하다. 건 물의 골격이 주요 골조 자재로 구성되어 있듯이 개념 데이터 모델도 주요 핵심 엔터티들로 구성된다. 핵심 엔터티란 행위의 주체나 목적물이 되는 개체 집합에 해당하는 엔터티를 의미한다. 이들은 부모가 존재하지 않는 창조된 집합이어서 다른 집합의 존재 유무에 상관없이 독립적으로 탄생할 수 있다. 핵심 엔터티는 대체적으로 여러 가지 하위의 행위 엔터티를 탄생시킨다.

개념 데이터 모델 의의

개념 데이터 모델은 단지 대상을 주요 핵심 엔터티로 한정한다는 것일 뿐이지 모델링 기법은 논리적 모델링과 특별히 다를 것이 없다. 만약 우리가 하향식으로 데이터아키텍처를 수립해 간다면 개념적 모델은 개괄적 모델을 좀더 상세화된 형태로 진화시키거나 중요 엔터티만 선정하여 모델링을 함으로써 탄생된다. 물론 이후에도 모델링의 상세화는 계속되어 갈 것이며, 필연적으로 개념적 모델도 따라서 약간씩 변화가 일어날 수 밖에 없다. 하지만, 개념 데이터 모델은 앞으로 아무리 상세한 모델링이 진행되더라도 전체적인 골격은 개념적 모델을 벗어나지 않는다는 것이다.

데이터아키텍처 프레임워크 상에서 개념 데이터 모델

전사아키텍처에서 개념 레이어는 최상위의 개괄 레이어와 하위의 논리 레이어 중간에 존재하는 레이어이다. 데이터아키텍처에서는 개괄 데이터 모델과 논리 데이터 모델 사이에 존재하는 모델이라고 할 수 있다. 여기에서 개괄 데이터 모델은 흔히 사용되어지는 주제 영역 관계도와도 대응되는 부분이라고 할 수 있다. 개념 데이터 모델은 상위의 주제 영역별로 핵심 엔터티와 핵심 속성, 또한 핵심 엔터티들 사이의 관계들로 이루어진 데이터 모델이라고 할 수 있다. 아키텍처의 개념을 종종 건축물에 비유하곤 한다. 개념 데이터 모델을 건축물에 비유해 보면 건물의 기둥들과 중요 벽체들로만 만들어진 건물 설계 도면에 비유할 수 있다. 이 단계에서 정의된 핵심 엔터티들과 관계들을 기반으로 논리 데이터 모델에서는 업무 요구 사항에 기반을 둔 상세 데이터 모델이 생성된다.

 

(DA가이드 4.2.2) 주제 영역 정의

주제 영역 개념

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

특히 현행 시스템을 개선하거나 현행 시스템에 대한 데이터 관리 체제를 생성하고 체계화하고자 할 경우에는 상향식 분석을 수행한다. 이 경우에는 현재 운용하고 있는 시스템에서 사용하고 있는 데이터에 대해 상위 수준에서 파악하기 위해 전사적인 관점에서의 데이터 분류를 수행하고, 이의 결과를 주제 영역(Subject Area)이라는 이름으로 관리하게 된다. 이렇게 분류된 결과는 보통 업무에서 관리하고자 하는 데이터 집합들의 그룹으로, 친밀도가 높아 동질성이 있는 데이터들로 이루어지는 것이 보통이다. 각 데이터 분류들은 일반적으로 관련된 업무 기능이 존재한다.

 

주제 영역 분류 원칙 및 기준

 

주제 영역 분류 원칙

 

1) 데이터 중복 최소화

동일한 기능을 하는 자원(지역 및 정보)이 중복 정의되어 낭비되지 않도록 체계적인 분류 작업이 필요하다.

 

2) 데이터 확장성 보장

가까운 미래의 추가되어지는 정보에 대해 최대한의 확장성을 고려하여 분류 체계가 설계되어야 한다.

 

3) 데이터 관련성 및 편의성 확보

• 타 자원(정보 및 지역)과의 인접성을 고려해 설계한다.
• 고객 편의(정보 요건)를 고려한 자원 내의 핵심적인 데이터 집합에 대한 것을 명시한다.
• 핵심 관계에 대한 것도 명시한다.
• 필요에 따라서는 표준화된 타 영역의 설계(참조 모델)도 참조하여 데이터 분류를 생성한다.

주제 영역 분류 기준

 

1) 데이터 관점의 분류

• 기존의 분류 방침이 데이터와 업무 영역의 개념이 혼재되어 있었으나 본 주제 영역 분류에서는 업무를 발생시키는 주체, 대상 및 행위 등 데이터 관점에서 데이터를 생성시키고 사용하는 유형에 근거하여 분류를 수행한다.
• 데이터와 시스템/애플리케이션 간의 독립성이 계속 증가되는 추세하에서는 더욱더 장기적이고 전사적인 관점에서 데이터 유사성을 고려하여야 한다.
• 시스템이나 애플리케이션이 다르더라도 동일한 유형의 데이터를 유사한 방식으로 활용한다면 이를 동일한 영역으로 분류하여 통합된 관점에서 데이터를 관리하여야 한다.

2) 업무 요건 추가에 대한 유연성 보장

• 업무 요건의 변경이나 추가 시 유연성을 보장할 수 있도록 전사 분류 체계를 설정한다.
• 업무 요건 변경에 대해서 데이터 구조의 변경을 최소화하려면 동일한 유형의 데이터를 본질이 희석되지 않는 한도 내에서 최대한 집합으로 통합해야 한다. 이렇게 함으로써 모델의 유연성과 확장성, 융통성이 보장되어 신규, 추가 요건에 대해 기존의 분류 구조에 적절하게 수용될 수 있다.
• 만일 새로운 영역이 필요한 상황이 발생한다면 전사적인 협의를 통하여 적절한 계층의 분류 구조를 조정한다.

3) 주제 영역 간 균형 유지

• 데이터 분류는 일부분에 국한된 것이 아니고 전체적인 균형을 유지하는 것이 중요하다.
• 특정 부분을 너무 상세하게 분류하거나, 분류 방식이 타 영역과 다른 방식으로 되어 있으면 전체적인 혼란을 야기할 수 있다.
• 데이터 분류에 대한 추가나 변경이 발생할 경우 해당 부문만을 고려하여 수행하기보다는 타 영역의 분류 체계와의 형평성 및 균형을 고려하여 분류 구조를 관리한다.다.

주제 영역 명명

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

2) 유일한 단수형 명사를 사용한다.

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

 

주제 영역 정의 절차

 

주제영역 분류 방법

 

1차 분류 : 주요 데이터 집합의 유형 정의

• 기존의 시스템별로 제공되는 데이터의 성격 및 특성을 고려하여 영역을 분류한다.
• 업무의 변화에 민감하지 않도록 정의한다.
• 분류 예시(아래 예시들을 복합적으로 적용하는 것도 가능)

- 데이터를 발생시키는 주체로서의 분류 → 관계자, 상품/서비스, 자산, 채널 등

- 데이터를 발생시키는 주체 간의 상호 작용으로 발생하는 대상으로서의 분류 → 계약, 리스크, 상품, 조건

- 공통 및 관리 성격의 상위 개념으로서의 분류 → 경영 관리(정보, 방침, 지원 등)

 

2차 분류 : Biz 활동에 필요한 데이터 분류

• Biz 활동에 필요한 분석 주제와 현황 등의 영역으로 분류한다.
• 기본(정보), 상세(정보), 관계(정보) 등과 같은 데이터의 기능적 구성 관점에서 접근하여 1차 분류 를 세분화한다.
• 업무 변화 수용의 융통성을 반영하여 정의한다.
• 분류 예시

- 관계자 : 관계자 기본, 관계자 상세, 관계자 관계, 관계자 분류 등

 

3차 분류 : 2차 영역의 세부 주제 영역 분류

• Biz 활동에 필요한 분석 주제와 현황 등의 영역으로 분류한다.
• 사용자에게 제공되는 실제 데이터로서의 관점에 근거하여 정의한다.
• 업무적인 관점에서 분류한다.
• 분류 예시

- 관계자(기본) : 고객, 법인, 조직, 직원 등

- 계약(기본) : 수신계약, 예금계약, 신탁계약 등

 

4) 데이터의 그룹을 의미하는 이름을 부여한다.

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

 

주제 영역 활용

목적

• 데이터의 계층적 구조를 파악하는 데 도움이 된다.
• 업무 기능(Function)과 병행하여 분석하는 경우에 분석의 최상위 단위 역할을 하여 품질 확보에 기여한다.
• 주제 영역 계층과 업무 기능 계층 간의 대응 관계를 확인한다.
• 주제 영역은 기업의 전사 업무를 위한 전체 데이터 구성에 대한 청사진을 제공한다.
• 데이터 구성 및 통합에 대한 방향 제시(선언적 성격)
• 효율적 데이터 관리를 위한 기준을 제공한다.

장점

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

주제 영역 도출

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

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

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

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

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

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

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

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

분석 단계에서의 도출

• 아키텍처 모델(Architecture Model)을 정련하는 과정에서 도출
• 데이터 모델을 상세화하는 과정에서 도출

주제 영역 정의 내용

주제 영역 목록

• 레벨 : 주제 영역의 계층 수준(1차, 2차, ... 단위)
• 주제 영역명
• 설명(단위 주제 영역의 경우)
• 대표 엔터티 : 해당 주제 영역 내에서 대표적인 엔터티를 기술한다.

주제 영역 정의서 샘플 양식

 

(DA가이드 4.2.3) 후보 엔터티 설정

개념

엔터티를 선정하기 위해서 우리가 가장 먼저 해야 할 일은 엔터티 후보를 수집하는 것이다. 이 단계는 말 그대로 후보를 찾아내는 것이지 엔터티를 확정하는 것이 아니므로 후보의 자격 여부만 가려내는 선에서 수사를 멈출 수 있어야 한다. 엔터티 후보를 수집할 때는 다양한 경로를 통해 수집하는 것이 바람직하며, 후보인지를 검증하는 객관적인 기준을 적용하여 후보라는 것을 판명하는 엔터티 후보 판정 단계를 거치게 된다. 이들은 엔터티 후보 분류 단계에서 3가지 형태로 분류된다.

 

엔터티 후보 수집

엔터티 후보를 수집할 수 있는 방법은, 기존 시스템이 있었다면 시스템 도큐먼트(Document)가 있고, 현업에서 사용하는 각종 장표들도 있다. 또한 현업 사용자와의 인터뷰를 통해 후보를 찾을 수도 있고, 관련 서적을 통해서도 가능하다. 만약 프로세스 모델링을 먼저 수행하여 자료 흐름도가 나와 있다면 그 속에 있는 데이터 스토어 또한 훌륭한 엔터티 후보가 될 수 있다. 뿐만 아니라 타사 혹은 유사 시스템의 자료를 확보하고 있다면 거기에서도 많은 후보가 나타날 것이다. 현업 담당자들이 기안한 각종 보고 자료, 또는 현장에 가서 직접 업무를 조사해 보는 방법도 있다.

 

기존 시스템 도큐먼트

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

 

현업 장표/보고서

실제 업무를 하는 조직에서는 대체적으로 정보시스템과 관련되지 않았더라도 오래 전부터 그들이 수행하는 업무의 효과적인 처리를 위하여 많은 장표를 가지고 있다. 또한 처리된 업무의 집계·분석·관리를 위해서 많은 종류의 보고서를 가지고 있다. 이러한 장표나 보고서에서 진짜 엔터티를 찾으려면 이 자료를 만들기 위해서 어떤 본질적인 집합이 필요한지를 분석해 보아야 한다. 좀 더 자세히 말하면 자료에 기술된 항목들을 속성이라 가정하고 이 속성들의 주인이 될 본질적인 집합이 무엇이 될지를 검토해 보라는 것이다. 여기서 말하는 본질 집합은 가공된 결과가 아닌 원재료(Source)가 되는 정보를 말한다.

 

현업 인터뷰(Interview)

엔터티 후보를 도출할 때부터 현업 담당자들과 같이 시작하는 것이 최상의 모델링 방법이다. 사전에 충분한 분석을 통해 짧은 시간에 많은 것을 확인할 수 있도록 질문을 준비해야 한다.

 

관련 전문 서적

현재의 업무를 있는 그대로의 모습으로 형상화하는 것이 아니라 좀 더 개선되고 발전된 모습으로 재창조하는 것이다. 이를 위해서 얻을 수 있는 정보는 현업만으로는 분명히 한계가 있다. 관련 전문 서적을 통하여 현실에 적용하기 위해 고민하고 있는 문제를 해결하는 데 필요한 아이디어나 힌트를 얻을 수만 있어도 충분히 목적을 달성한 것이다. 이러한 시각에서 전문 서적을 참고하면 생각보다 얻을 것이 많다.

 

데이터 흐름도 (DFD, Data Flow Diagram)

업무 파악 및 시스템 분석을 위해 기능 설계를 데이터 흐름도로 작성했다면, 여기에 있는 데이터 저장소(Data Store)와 데이터 사전(Data Dictionary)에 있는 정보를 이용하여 엔터티 후보를 도출할 수 있다. 데이터 흐름도를 작성할 때 생성되는 데이터 저장소는 비록 테이블처럼 표현되지만 사실은 특정 데이터를 저장해야 한다는 데이터의 추상화된 집합이지 엔터티가 되는 것은 아니다. 예를 들어, 자재 구매 기능에서 자재 정보 자료 저장소로 정보가 저장되고 여기에는 자재 코드+자재명+규격+구매 수량+... 등의 자료 사전이 생성되지만 실제 모델링을 해보면 자재, 자재 유형, 단가정보 등의 많은 엔터티가 나타나게 된다.

 

타 시스템 자료

타 시스템이 가지고 있는 엔터티를 면밀히 조사하고 이것들이 우리가 가져가야 할 집합과 어떻게 다른지를 밝히고 앞으로는 어떻게 정의해야 할 것인지를 조사한다. 엔터티 후보를 손쉽게 찾을 수 있는 또 하나의 방법은 관계사나 유사 업종의 시스템 도큐먼트를 입수해서 참조하는 것이다.

 

현장 조사

본격적인 모델링을 하기 전에 현장을 답사하는 것이 좋다. 그렇게 해야 모델러와 개발 종사자들 간에 공통적인 의사소통 수단(Communication Protocol)이 좀 더 쉽게 만들어진다. 그렇지 못하면 설계 시에는 서로를 충분히 이해한 것 같은데, 나중에 가서 보면 무엇인가 앞뒤가 맞지 않는 일이 자주 발생한다. 이것은 결국 동일한 사실에 대해서 서로가 동상이몽을 하고 있었다는 것을 의미한다.

 

엔터티 후보 식별

다양한 경로를 통해 엔터티 후보를 수집하는 과정에서 가장 중요한 것은 엔터티 후보를 어떻게 식별할 것인가에 대한 문제이다. 이러한 판단을 위해서는 무엇보다도 누구나 인정할 수 있는 구체적이고 객관적인 잣대가 있어야 한다. 엔터티 후보의 식별은 다음의 세 가지 단계에 대한 검증을 통해 객관화할 수 있다.

• 후보 엔터티의 개념 정립을 명확히 한다.
• 우리가 관리하고자 하는 것인지를 따져 본다.
• 가로와 세로를 가진 면적(집합)인지를 확인한다.

엔터티 후보의 개념 정립

엔터티 후보로 검토해 볼 대상의 최초 상태는 한낱 단어에 불과하다. 단어란 단지 사전적 의미에 지나지 않으므로 우리는 이 단어가 의미하는 진정한 집합이 무엇인지를 정의해야 한다. 예를 들어 사원이란 단어의 사전적 의미는 회사에 근무하는 사람 혹은 사단법인을 구성하는 사람이라고 되어 있다. 그러나 우리가 검토할 사원은 우리 회사에 근무하거나 촉탁(임시) 사원, 관계사, 협력사 등에서 지원받은 사원들을 포함한 집합이 될 수도 있다. 우리는 반드시 이와 같은 구체적 집합을 정의한 다음에야 비로소 다음 단계에 대한 검토를 진행할 수 있다. 그것은 애매모호한 대상을 놓고 구체적인 판단을 하고자 노력하는 것은 도로(徒勞)에 지나지 않기 때문이다.

 

관리 대상 판정

엔터티 후보로 선정하기 위해 개념을 정립해 둔 단어에 대해 우리가 검토해야 할 첫 번째 작업은 과연 이것이 우리가 관리하고자 하는 대상이 맞는지를 확인하는 일이다. 이 말은 앞으로 우리가 모델링을 하면서 던지는 모든 질문에 반드시 기본적으로 포함되어야 하는 주어부(主語部)에 해당하는 구문이다. 이 문장이 있음으로 인해서 모델링을 할 대상 업무에 따라 모델링의 결과가 달라지는 원인이 된다.

• 사람이라는 논리적인 집합은 구멍가게 업무를 모델링을 하느냐 혹은 행정 전산망에 대한 모델링을 하느냐에 따라 관리하고자 하는 집합이 달라지므로 데이터 모델의 모습도 달라질 수 있다.
• 현재 관리하고 있느냐 뿐만 아니라 앞으로는 관리해야 하지 않느냐를 모두 포함하고 있다. 사실 현재 관리되고 있다는 것을 확인하는 것도 쉽지 않겠지만, 앞으로 관리할 것인지를 결정하는 것은 매우 전략적인 판단이 필요하다.

집합 여부 확인

엔터티는 집합이어야 하지만 모든 집합이 모두 엔터티가 되는 것은 아니다. 여기서는 엔터티를 결정하는 것이 아니라 엔터티 후보를 선정하려는 것이므로 검토하고자 하는 대상이 집합이 되는지 여부만 확인한다.

 

 

집합이란 다른 측면에서는 면적이라고 할 수도 있다. 면적이 되려면 가로 선분과 세로 선분이 있어야 한다. 선분이란 서로 다른 독립적인 두개 이상의 점(點)이 있어야 한다. 여기서 점이란 속성을 의미한다. 만약 우리가 검토할 대상이 하나의 점만 있다면 선분이 되지 못하므로 비록 세로가 선분이 되더라도 수직선 밖에 될 수 없다. 마찬가지로 세로가 하나의 점이라면 최대 수평선 밖에 될 수 없기 때문에 이런 경우는 면적(집합)이 되지 못하므로 엔터티가 될 수 없다.

 

엔터티 후보 선정시 유의사항

엔터티 후보의 선택은 데이터 모델링의 시작 부분이다. 엔터티 후보를 선정하는 동안에 아래와 같은 몇 가지의 유의사항을 염두에 두어야 한다.

 

엔터티 가능성이 있다고 예상되면 일단 검토 대상에 올려라

엔터티 후보라고 해서 모두가 최종적으로 엔터티가 되는 것은 당연히 아니다. 그 대신 후보란 다른 후보들과 비교됨으로써 결정되는 것이므로 이런 후보들을 충분히 수집한 후 언젠가는 후보들을 하나씩 비교하면서 검토하게 된다. 버리게 되더라도 이 때 버리면 되므로 일단 모든 가능성 있는 대상을 최대한 수집한다는 생각을 가지고 접근하는 것이 좋다.

 

너무 깊게 들어가지 마라

후보의 자격이 있다/없다 정도만 판단한다. 물론 필요에 따라 좀더 깊은 곳에 있는 내용을 통해 현재 결정하고자 하는 것에 대한 확신이 필요하다면 얼마간은 더 깊이 들어가 볼 수는 있다. 그러나 엔터티 후보를 선정하는 단계에서 절대로 너무 깊이 들어가서는 안 된다

 

동의어처럼 보이더라도 함부로 버리지 마라

특정 단어의 경우에는 의미를 일반적인 의미와는 다르게 사용하는 경우가 많다. 마치 새로운 언어가 생겨나는 것과 유사하게 누가 사용하기 시작했는지는 모르지만 언젠가부터 그렇게 알고 사용하기 시작하면서 의미가 그대로 굳어 버린다. 예를 들어 어떤 회사에는 상품과 제품이 있는데 일반적으로는 동일한 의미로 사용하지만 이 회사는 다른 의미로 사용하고 있었다. 이와 같이 동일한 의미로 여겨지지만 실제 정의된 집합은 같지 않을 수가 있고, 비슷하기는 하지만 정확하게 일치하지 않는 경우도 종종 발견된다. 그러므로 동의어처럼 보인다고 함부로 버릴 게 아니라 일단 후보로 도출하는 것이 중요하다. 데이터 모델링의 뒷부분에서 이러한 부분들을 가지고 다른 어떤 집합과 중복된 것인지, 완전히 포함되는 부분집합을 말하는 것인지, 아니면 일부가 서로 겹쳐져 있는 형태인지를 정확하게 규명하게 된다.

 

개념이 모호한 대상은 일차로 그 개념을 상식화 하여 이해하라

어려운 전문 용어나 특화된 업무에 대해서는 일반적이고 상식적인 예를 들어서 엔터티의 개념만을 파악한다. 이 단계에서 해당 업무 또는 데이터에 대해 정확한 개념을 파악하는 것은 무리가 따르기 마련이다.

 

프로세스에 너무 연연해 하지마라

지금까지 우리는 모든 업무를 프로세스 중심으로 이해했기 때문에 프로세스 중심으로 설명을 듣지 않으면 이해하기가 매우 어렵다. 그러나 데이터 모델에는 프로세스가 없다. 흐름도 없고, 시간도 없다. 이것이 우리를 참으로 어렵게 만든다. 모델링을 하면서 자꾸 업무의 흐름에 집착하면 데이터흐름도처럼 데이터 모델이 업무를 따라 흘러가는 이상한 현상이 발생한다. 물론 데이터 모델링에서도 업무의 흐름을 완전히 배제하지는 않는다. 다만 그것은 현재 목적한 데이터 모델링의 어떤 결정을 좀더 완벽하게 하기 위해서 프로세스를 파악해 보는 것일 뿐이다.

 

예외 경우에 너무 집착하지 마라

예외 처리에 집착하지 말라는 뜻은 예외 처리가 중요하지 않다는 의미가 아니다. 지금 엔터티 후보를 수집하고 선정하는 단계에서는 가볍게 넘어가라는 것이다. 나중에 엔터티의 내부 구성 집합(Subtype)이나 릴레이션십을 정의하는 단계에서 이러한 예외 경우를 분석하여 설계에 반영하게 된다.

 

단어 하나하나에 집중해서 판단해라

누구나 알고 있는 것처럼 보이는 단어에 대해서도 좀더 깊이 구체적인 집합을 생각해야 한다. 예를들어 누구나 사원이 어떤 집합인지는 확실히 알고 있다고 생각한다. 그러나 좀더 깊이 들어가서 외부 용역사원이나 협력사 직원도 우리 사원 집합에 들어오는지를 물어보면 대답을 못한다. 왜냐하면 이렇게 구체적으로 사원이라는 집합에 대해서 정의한 적이 없기 때문이다. 매우 상식적이고 일반적인 용어로 정의된 엔터티 후보라도 사실은 매우 개략적이고 모호하게 정의되어 있는 경우가 많다.

 

수집된 엔터티 분류

개념 데이터 모델링에서는 일단 데이터 모델의 골격을 잡는 일부터 철저하게 수행해야 한다. 이렇게 하기 위해서는 엔터티 후보를 분류하는 작업부터 수행해야 한다. 분류 작업의 궁극적인 목적은 골격에 해당하는 엔터티만을 따로 분류해서 거기에 노력을 집중함으로써 나무만 보고 숲을 보지 못하는 오류를 범하지 않도록 하기 위한 것이다. 엔터티 후보를 분류하는 작업은 다음 두 단계에 걸쳐 진행된다. 첫 번째 단계는 우선적용 대상을 분류하는 것이고, 두 번째 단계는 첫 번째 단계에서 선별한 핵심 엔터티를 데이터 영역별로 분류하는 것이다.

 

우선적용 대상 분류

엔터티 후보를 우선적용 대상별로 분류하는 목적은 모델링의 골격에 해당하는 주요 엔터티를 먼저 도출하여 이를 명확히 정의함으로써 모델링의 기초를 단단하게 하는 것이다. 이를 바탕으로 흔들림없이 상세한 모델링을 진행해 갈 수 있게 된다. 모델링을 순차적으로 접근해 가야 할 형태별로 분류한다면 크게 세 가지로 나눌 수 있다.

첫 번째는 사람, 상품, 자재 등과 같이 행위를 발생시키는 주체나 목적어가 되는 엔터티(여기서는 키 엔터티라 부르기로 한다)이다. 두 번째는 키 엔터티가 행위를 함으로써 발생되는 행위의 집합 중에서 좀더 하위의 행위를 발생시키는 주체나 목적어가 될 수 있는 엔터티(여기서는 메인 엔터티라 부르기로 한다)이다. 그리고 나머지 엔터티(여기서는 액션 엔터티라 부르기로 한다)를 세 번째로 분류한다.

 

1) 키 엔터티(Key Entity)

자신의 부모를 가지지 않는 엔터티를 말한다. 여기서 부모 엔터티란 자신을 태어나게 한 - 만약 이 엔터티가 없다면 논리적으로 자신이 태어날 수 없는 - 엔터티를 말한다. 태초부터 창조된 집합이란 다른 엔터티의 도움을 받지 않더라도 얼마든지 어떤 개체를 새롭게 정의할 수 있는 집합을 말한다. 예를 들어, 사원 엔터티에 있는 홍길동이란 개체는 아직 부서가 정해지지 않았더라도 사원으로서 정의하는 데 문제가 없다. 물론 부서 엔터티와 관계를 정의할 때 반드시 부서를 갖도록 하는 규칙을 부여할 수도 있겠지만 그렇다고 해서 부서가 직접적으로 사원을 태어나게 한 부모인 것은 결코 아니다. 다시 말해 사원은 부서 없이도 태어날 수 있지만 부서가 결정되지 않으면 결코 탄생시키지 않겠다는 규칙을 부여할 수는 있다. 키 엔터티를 구별할 때 이러한 규칙과 부모의 차이를 혼동하는 경우가 자주 나타나고 있으므로 여기서 정확히 개념을 정립해야 한다. 키 엔터티의 예로는 다음과 같은 엔터티가 있을 수 있다.

• 사원
• 부서
• 고객
• 상품
• 자재

2)메인 엔터티(Main Entity)

키 엔터티를 제외한 다른 모든 엔터티는 부모 엔터티를 가지고 있어야만 태어날 수 있다. 이러한 엔터티는 업무의 크기에 따라 엔터티 간 계층의 깊이가 달라진다. 여기서 키 엔터티를 제외한 엔터티 중에서 업무의 중심에 해당하는 엔터티를 메인 엔터티라 정의하고, 나머지를 액션 엔터티로 정의한다. 이렇게 정의하는 것은 전체를 단계적으로 파악하고자 하는 의도가 있다. 메인 엔터티의 예로는 다음과 같은 엔터티가 있다.

• 보험계약, 사고, 예금원장, 청구 …
• 구매의뢰, 출하지시, 공사 …
• 주문, 예산편성, 매출 …

3)액션 엔터티(Action Entity)

매출, 출고, 입금과 같은 엔터티는 눈에 잘 보이지만 이들을 태어나게 한 고객, 공정, 창고 등은 엔터티로서는 눈에 잘 보이지 않는다. 키 엔터티에 해당하는 것들은 다만 우리 눈에는 코드 정도로 보일 뿐이고 실제 모델링에서도 이러한 부모들이 나중에 나타나는 경우가 많다. 액션 엔터티는 수행된 업무를 담고 있으므로 중요도를 가지고 따진다면 물론 가장 중요하다고 할 수 있다. 그러나 이들은 스스로는 결코 태어날 수 없는 - 반드시 부모를 가져야만 하는 - 자손들이다. 이들을 제대로 정의하기 위해서는 낳을 부모들부터 먼저 정확하게 정의하는 것이 일의 당연한 순서일 것이다.

액션 엔터티를 구별하는 방법은 매우 쉽다. 키 엔터티와 메인 엔터티가 아닌 것은 모두 액션 엔터티이기 때문이다. 앞으로 모델링이 좀더 구체적으로 진행되더라도 키 엔터티와 메인 엔터티는 집합의 본질이 크게 달라지지 않는다. 그러나 액션 엔터티는 상위 엔터티들이 어떻게 결정되느냐에 따라서 크게 영향을 받기 때문에 업무의 본질은 살아 있지만 최초에 예상했거나 과거에 정의했던 의미상의 주어가 크게 달라질 수도 있다. 액션 엔터티의 예로는 다음과 같은 엔터티가 있다

• 상태 이력, 차량 수리 내역, 상세 주문 내역,···

우선적용 대상 분류 사례

[그림 5-2-3]에서 예시된 엔터티 후보를 접근 형태별로 분류해 보기로 하자. 검토 대상은 가능한 무순으로 하고 간단한 설명만 하도록 하겠다.

 

 

위의 후보 대상 중에서 키 엔터티에 해당하는 몇 가지만 분류해 보면 다음과 같다.

 

고객

고객은 상식선에서 생각하더라도 당연히 개체 집합이므로 키 엔터티로 분류해야 한다. 문제는 어떤 구체적인 집합을 고객으로 할 것이냐를 결정하는 것이 중요하다. 가령 개인과 법인을 모두 고객이라고 할 것인지, 현재 우리와 직접 관계를 가진 것만이 고객인지, 아니면 잠재고객까지 포함한 것을 고객이라 할 것인지에 대한 결정을 하는 것이 중요하다.

 

법인

법인 또한 당연히 개체 집합이라는 것은 굳이 설명할 필요도 없다. 강의를 하다보면 가끔 법인을 메인 엔터티라고 생각하는 사람도 있다. 그 이유를 물어보면 고객의 자식이 아니냐고 반문한다. 이것은 착각이다. 법인은 고객의 부분집합이지 자식은 아니다. 부분집합과 자식은 절대로 같은 개념이 아니다. 만약 사원 엔터티를 남자, 여자로 구분했다면, ‘남자는 사원의 아들인가’ 그렇다면 ‘여 자가 사원의 자식인가’ 나중에 엔터티 확정 단계에 가면 집합의 독립성과 동질성에 대한 평가를 하게 되는데 여러 가지 결론이 나올 수 있다. 즉, 고객 집합에 법인 집합이 포함된다면 이는 독립성에 저촉을 받는 것이므로 법인은 엔터티가 아니라 고객의 서브타입에 불과하다. 만약 개체의 일부만 고객에 포함된다면 고객 집합의 동질성을 확장하여 법인 집합 모두를 포함시킬 것인지, 아니면 어떤 특별한 목적이 있다면 중복이 있더라도 별도의 개체 집합으로 할 것인지 등의 결정에 따라 판단은 달라진다.

 

금융기관

이것은 법인의 한 부분 집합일 수 있으므로 당연히 키 엔터티로 보아야 한다. 이 또한 고객과 법인과의 관계에서 고려했던 문제처럼 법인과 금융기관 관계에서도 동일한 고민이 발생한다. 즉, 금융기관을 법인의 서브타입으로 보아야 할 것인지, 독립적인 집합으로 보아야 할 것인지를 검토하면서 유사해 보이는 두 집합의 개념을 좀 더 정확하게 정의를 해야 한다는 것이다. 얼핏 생각하면 금 융기관은 당연히 법인의 일부분처럼 보인다. 그러나 집합을 좀 더 명확히 해보면 미묘한 차이가 있을 수도 있다. 가령, 법인 엔터티는 국가가 인정한 공식 법인이 있다면 그것이 하나의 단위 개체가 되는 집합이라고 정의했다고 가정하자. 그렇지만 금융기관 엔터티는 금융기관의 본·지점이 하나의 개체가 되는 집합이라고 했다면 이들은 성격이 다른 집합이 될 것이다.

수납기관

단어의 구성을 보면 금융기관과 유사해 보이지만 결론은 정반대이다. 수납기관은 엔터티가 아니다. 물론 다른 엔터티와 개체의 중복이 발생하더라도 수납을 받을 수 있는 모든 개체들을 모아두고 이를 수납기관이라고 정의한다면 안 될 것도 없지만 개체 본연의 본질이 많이 희석되는 일이 발생한다. 예를 들어 행정기관인 세무서에서 세금을 수납 받는다면 이것을 수납기관의 개체로 두어야 하겠는가? 만약 법이 바뀌어 수납을 받지 않는다면 이 집합에서 다시 빼내어야 하는가? 또 수납의 반대 개념인 지급도 발생할 것이므로 그렇다면 지급기관 엔터티도 만들어야 하고 여기에도 이 개체가 존재해야 하지 않겠는가? 수납기관이란 말에는 기관이란 개체 본질과 수납이라는 행위 본질이 같이 들어 있는-다시 말해서 두 개의 집합을 연결한-모습이므로 이것은 엔터티가 아니라 릴레이션십이 되는 것이다.

 

거래자

거래자는 엔터티가 아니다. 엔터티는 순수한 개체 본질이 되거나 행위 본질이 되어야 하는데 거래자는 거래라는 행위 본질과 자라는 개체 본질이 혼합되어 있으므로 엔터티가 아니라 관계이다. 다시 말해서 개체 집합인 자(고객)와 거래내역이라는 행위 집합의 관계 명칭이 바로 거래자인 것이다. 이러한 집합에 대해 얼핏 생각하면 엔터티 정의에서 검토했던 우리가 관리하고자 하는 집합이며, 2개 이상의 속성과 2개 이상의 개체를 가져야 한다는 조건을 모두 만족하고 있으므로 엔터티로 오해하는 경우가 많은데 절대 그렇지 않다.

 

데이터 영역별 분류

이 골격에 해당하는 엔터티들을 명확하게 정의해야 한다. 상위 엔터티가 단단하게 고정되지 않고서는 사상누각이 될 수밖에 없기 때문에 앞으로 좀 더 상세한 모델링이 진행되더라도 굳건하게 견딜 수 있도록 견고하게 정의를 해야 한다. 앞서 도출했던 골격 엔터티들의 의미를 정밀하게 비교하여 구체화시키기 위해서는 유사한 의미를 가진 엔터티를 서로 모아 함께 비교하는 것이 필요하다. 뚜렷한 차이를 가지는 것들 간이라면 대충만 비교해도 그 차이가 분명하게 나타나지만 미묘한 차이를 가지고 있는 것들은 곁에 놓고 같이 비교해 보지 않으면 쉽게 그 차이를 알아낼 수 없다. 데이터 영역을 정의하는 방법은 접근 방법별로 볼 때 크게 하향식(Top-Down)과 상향식(Bottom-Up) 접근 방법으로 나누어 볼 수 있다. 또한 그 구성에 따라 세상의 모든 집합을 크게 나누어 행위의 주체나 목적물이 되는 개체들이 모인 집합과 그들의 활동으로 얻어지는 행위??, 지역, 시설, 재료 등은 행위의 주체로서 개체 집합의 예가 될 수 있고, 계약, 주문, 청구, 매출, 수납 등은 기업의 업무를 크게 분류한 것으로서 행위 형태의 데이터 영역으로 분류될 수 있다. 실제 업무에서 자주 발생하는 엔터티의 일부를 몇 가지 데이터 영역별로 분류해보면 [표 4-2-1]과 같다.

 

[표 4-2-1] 엔터티 영역별 분류 정의서 예

 

모델	대 상 엔 터 티 후 보
사람	사원, 가입자, 회원, 고객, 학생, 교사, 환자, 협력사 직원 …
물건	부품, 원재료, 연료, 저장품, 상품, 건물, 운송센터 …
사건 관리자	계약, 수주, 주문, 발주, 재해, 고장, 사건, 신고, 입고, 출고 …
장소	창고, 생산라인, 행정구역, 하천, 선거구, 공항, 항만, 공정 …
개념	판매목표, 생산계획, 평가기준, 할인기준, 배부기준, 공법 …
금전	입급, 청구, 차입금, 예적금, 연간예산, 융자, 사내대출 …
조직	부서, 판매망, 채널, 거래처, 법인조직, 교대조, 대리점 …

 

 

 

(DA가이드 4.2.4) 핵심 엔터티 정의

개념

 

엔터티란?

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

엔터티 정의의 요건

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

의미상 주어 정의

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

 

본질 식별자 정의의 의의

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

 

본질 식별자 정의 예

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

 

코드성 키 엔터티 모델링

소위 코드성 엔터티라고 부르는 엔터티를 개념적 모델링 단계에서 도출할 것인지 아니면 나중에 상세 모델링 단계의 정규화 단계에서 처리할 것인지에 대한 판단은 모델링의 효율적인 진행에 커다란 영향을 미친다. 이런 유형의 엔터티를 현 단계에서 너무 많이 도출시킨다면 모델링은 복잡성의 함정에 빠져 버릴 것이다. 반면, 꼭 필요한 것을 누락시켰다면 태어나야 할 중요한 자식 엔터티가 나타나지 않을 수도 있다. 이러한 고민을 해결하는 방법은 다음의 네 가지 기준에 따라 판단하는 것이다.

• 이 엔터티가 자식 엔터티를 가지는가?
• 이 엔터티가 자신만의 다양한 속성을 가질 것인가?
• 이 엔터티가 여러 엔터티에 관계를 가질 것인가?
• 이 엔터티가 다양한 종류의 관계를 가질 것인가?

자식 엔터티 유무 확인

이것은 해당 엔터티가 다른 엔터티의 본질 식별자가 되고 있는지를 찾아내는 것이다. 다시 말해서, 비록 겉모양은 볼품없이 초라하지만 만약 이 엔터티가 도출되지 않았을 때 중요한 자식 엔터티도 같이 태어날 수 없다면 반드시 미리 도출해야 한다는 것이다.

[그림 4-2-5]에 있는 엔터티를 검토해 보자. 이 그림은 어떤 생산 공장에 있는 생산에 관련된 설비를 정의한 엔터티이다. 여기에 들어 있는 개체를 크게 나누어 펌프, 탱크, 배관, 발전기, 압축기 등으로 분류했다고 하자. 이러한 분류를 모델링에서는 서브타입(Sub-type)이라고 한다. 이 분류가 그림에서처럼 단지 설비를 분류하는 데에만 사용한다면-그것이 비록 나중에 코드화를 함으로써 별도의 엔터티로 생성된다고 하더라도-지금 단계에서 굳이 엔터티로 도출할 필요가 없다. 그 이유는 지금 엔터티로 도출한 것이나 나중에 정규화 단계에서 도출한 것이나 별차이도 없으면서 초기 단계의 복잡성만 가중시키기 때문이다.

 

 

 

그러나 만약 설비 타입과 생산 라인별로 우리가 관리하고자 하는 공정 제어값이 있다면 이 설비타입은 분명히 부모의 역할을 하게 되므로 지금 도출해 두지 않으면 자식 엔터티도 같이 누락된다.

 

속성 존재 여부 확인

해당 엔터티가 현재 혹은 미래에 단순한 코드명이나 코드의 의미에 대한 설명 외에 또 다른 속성을 가질 수 있는가를 확인해 보는 것이다. 엔터티가 이러한 속성을 가지고 있다는 것은 자기만의 확실한 사유재산이 있다는 것을 의미하므로 마땅히 독립적인 개체 집합으로서의 자격이 있다고 하겠다. 이러한 엔터티는 필연적으로 다른 엔터티와 다양한 관계를 가지게 될 것이며, 앞으로 자신을 참조하는-향후에 조인(join)이 발생하는-행위 엔터티가 분명히 발생하게 될 것이므로 미리 엔터티로 도출해 두는 것이 바람직하다.

 

관계 존재 여부 확인

엔터티가 향후 다른 엔터티와 많은 관계를 가질 가능성이 있는지를 검토해 보는 것이다. 엔터티가 다양한 관계를 맺고 있다는 것은 활동성이 왕성하다는 것을 의미한다. 여기서 말하는 관계는 반드시 부모(의미상의 주어)로써의 관계만 의미하는 것이 아니라 일반적인 관계까지 모두 포함한 포괄적인 관계를 말한다. 만약 이러한 엔터티를 누락시킨다면 앞으로 우리가 정의해야 할 많은 릴레이션십들 도 같이 누락될 것이다.

 

 

집합 순수성 의미

엔터티는 반드시 순수한 본질(本質) 집합이 되어야 한다는 것은 정의하고자 하는 집합이 사람, 상품 등과 같이 단위 사물을 정의한 개체(個體) 집합이 되든지, 아니면 이들이 어떤 활동을 함으로써 만들어진 입금, 계약 등과 같은 행위(行爲) 집합이 되든지 간에 반드시 둘 중의 어느 하나가 되어야 한다는 것이다. 그렇지 못하고 이들이 서로 결합된 형태라면 그것은 관계이다.

 

집합 순수성 예

납입자와 같은 단어 개체 집합이 합성되어 있음을 알 수 있다. 물론 여기서 ‘자’란 사람이나 단체와 같은 개체 집합을 의미하며, 이러한 개체가 포함될 수 있는 본질 집합은 고객과 같은 집합들이 이에 해당할 수 있다. 그렇다면 납입자란 순수 본질 집합인 고객과 납입이 결합되어 만들어진 것, 다시 말해 이것은 엔터티가 아니라 관계라는 것이다.

 

집합 순수성 적용 예외 사항

1) 관계의 엔터티화

관계가 엔터티로 변하는 경우이다. 관계가 M:M이 되면 더 이상 관계로만 존재할 수 없기 때문에 엔터티로 바뀌게 되며, 이를 릴레이션 엔터티라고 한다. 예를 들어 피보험자란 단어를 분석해 보면, [그림 4-2-6]에 있는 것처럼 보험 수혜자로 위촉되었다는 행위와 그 수혜자가 된 사람의 개체가 결합되어 있어 순수한 본질 집합이 아니기 때문에 관계가 분명하다.

 

 

 

하지만, M:M 관계는 최종적으로는 관계로써 존재할 수 없기 때문에 1:M으로 연결된 교량 역할을 해주는 엔터티로 바뀌어야 한다. 이 엔터티는 관계가 변해서 생성되었기 때문에 릴레이션 엔터티(Relation Entity)라고 부른다. 방법론에 따라서 제휴 엔터티(Association Entity)나 교차 엔터티(Intersection Entity)라고 부르기도 한다.

 

2)일부 집합 정의

전체 논리적인 집합 중에서 관리하고자 하는 일부의 집합만을 엔터티로 정의하고자 할 때, 구체적인 명칭을 부여하다 보면 이를 수식하고 있는 단어로 인해 마치 개체 집합과 행위 집합의 합성처럼 보일 수가 있다. 예를 들면 금융기관이란 엔터티 후보가 있을 때 언뜻 생각하면 금융과 기관의 합성어로 구성되어 있는 것처럼 보이므로 이것을 관계로 오해할 수도 있지만 이것은 엔터티이다.

[그림 4-2-8]에 있는 금융기관과 수납기관은 언뜻 보기에는 마치 모두 행위처럼 보이는 금융, 수 납의 수식을 하는 부분과 업체들을 말하는 개체 집합인 기관이 결합된 형태처럼 보인다. 그렇지만 이 두 가지 단어는 서로 결론이 다르다. 먼저 결론부터 말한다면 금융기관은 엔터티가 될 수 있지만 수 납기관은 엔터티가 아니라 관계일 뿐이다.

단순하게 생각하면 금융이란 말이나 수납이란 말은 모두 동일한 역할을 하는 것처럼 보인다. 그러 나 조금만 더 깊이 생각해보면 이들 간에는 아주 뚜렷한 차이가 있음을 알 수 있다. 금융은 기관이라 는 큰 집합의 특정 부분 집합을 나타내기 위해 사용된 말이다. 마치 전체 집합인 고객의 일부를 법인 고객으로 표현한 것과 같은 의미로 사용되었다. 반면, 수납기관에 사용된 수납이란 뜻은 기관의 개체 가 행하는 여러 행위 중의 하나이다. 가령 은행에서는 수납만 하는 것이 아니라 출납 행위도 한다.

 

 

 

 

DA 가이드·글이 도움이 되셨다면

 

 

 

https://bluedata2050.tistory.com/106

DA가이드 4과목 데이터모델링 (2/2)

 

 

 

https://bluedata2050.tistory.com/107

DA가이드 5과목 데이터베이스 설계와 이용

 

 

https://bluedata2050.tistory.com/109

DA가이드 3과목 데이터 표준화