1. 모델링의 이해
모델링의 정의
사람, 사물, 개념 등에 의해 발생되는 다양한 현상을 표기법에 의해 규칙을 가지고 표기하는 것을 의미한다.
현실세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현하는 기법으로 정리할 수 있다.
모델링의 특징
추상화, 단순화, 명확화 3대 특징으로 요약 가능하다.
추상화
현실세계를 일정한 형식에 맞추어 표현을 한다는 의미로, 다양한 현상을 일정한 양식인 표기법에 의해 표현한다는 것이다.
단순화
복잡한 현실세계의 약속된 규약에 의해 제한된 표기법이나 언어로 표혀하여 쉽게 이해할 수 있또록 하는 개념을 의미한다.
명확화
누구나 이해하기 쉽게 하기 위해 대상에 대한 애매모호함을 제거하고 정확하게 현상을 기술하는 것을 의미한다.
2. 데이터 모델 기본 개념의 이해
데이터모델링의 정의
정보시스템을 구축하기 위한 데이터관점의 업무 분석 기법이다.
현실세계의 데이터(What)에 대해 약속된 표기법에 의해 표현하는 과정이다.
데이터베이스를 구축하기 위한 분석/설계의 과정이다.
데이터 모델이 제공하는 기능
시스템을 현재 또는 원하는 모습으로 가시화하도록 도와준다.
시스템의 구조와 행동을 명세화 할 수 있게 한다.
시스템을 구축하는 구조화된 틀을 제공한다.
시스템을 구축하는 과정에서 결정한 것을 문서화 한다.
다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점을 제공한다.
특정 목표에 따라 구체화된 상세 수준의 표현방법을 제공한다.
3. 데이터 모델링의 중요성 및 유의점
파급효과(Leverage)
시스템 구축이 완성되어 가는 시점에서 많은 애플리케이션들이 테스트를 수행하고, 대규모의 데이터 이행을 성공적으로 수행하기 위한 많은 단위 테스트들이 수행되고 이러한 과정들이 반복된다. 이런 시점에 데이터 모델의 변경이 불가피한 상황이 발생하면 변경을 해야하는 데이터 모델의 형태에 따라 영향 정도의 차이가 있겠지만, 프로젝트 단위가 크다면 큰 위험요소가 아닐 수 없다. 때문에 시스템 구축 작업 중에는 다른 어떤 설계 과정보다 데이터 설계가 가장 중요하다고 볼 수 있다.
복잡한 정보 요구사항의 간결한 표현(Conciseness)
데이터 모델은 구축할 시스템 정보 요구사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구로서, 수 많은 페이지의 기능적인 요구사항을 파악하는 것보다 간결하게 그려져 있는 데이터 모델을 리뷰하면서 파악하는 것이 훨씬 효율적이다. 데이터 모델은 건축물로 비유하자면 설계 도면이라고 할 수 있다. 정보 요구사항이 정확하고 간결하게 표현되어야 시스템을 구축하는 많은 관련자들이 설계자의 생각대로 정보요구사항을 이해하고 이를 운용할 수 있는 애플리케이션을 개발하지 않을까?
데이터 품질(Data Quality)
데이터베이스에 담겨있는 데이터는 중요한 자산이다. 데이터는 기간이 오래되면 될수록 활용 가치가 높아진다. 그런데 저장된 데이터가 그저 그런 데이터, 정확성이 떨어지는 데이터라고 한다면 데이터를 전략적으로 활용하려고 하는 시점에 문제가 대도될 것이다.
데이터 모델링을 할 때 유의점
중복(Duplication)
데이터 모델은 같은 데이터를 사용하는 사람, 시간, 그리고 장소를 파악하는데 도움을 준다. 때문에 데이터베이스가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 해야 한다.
비유연성(Inflexibility)
데이터 모델 설계에 따라 사소한 업무변화에도 데이터 모델이 수시로 변경됨으로써 유지보수의 어려움을 가중시킬 수 있다. 때문에 데이터 모델링은 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 사소한 변화에도 데이터베이스의 중대한 변화를 일으킬 수 있는 가능성을 줄일 수 있다.
비일관성(Inconsistency)
데이터 모델링을 할 때 데이터와 데이터 간 상호 연관 관계에 대한 명확한 정의를 함으로써 데이터의 중복이 없더라도 발생할 수 있는 비일관성을 예방한다.
4. 데이터 모델링의 3 단계 진행
추상화 수준에 따라 개념적 데이터 모델, 논리적 데이터 모델, 물리적 데이터 모델로 정리할 수 있다.
데잍터 모델링 | 내용 | 수준 |
개념적 데이터 모델링 | 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링 진행. 전사적 데이터 모델링. EA 수립시 많이 이용 | 추상적 |
논리적 데이터 모델링 | 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현. 재사용성이 높다. | / |
물리적 데이터 모델링 | 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계한다. | 구체적 |
개념적 데이터 모델링 (Conceptual Data Modeling)
조직, 사용자의 데이터 요구사항을 찾고 분석하는데서 시작한다. 주요 활동은 핵심 엔터티와 그들 간의 관계를 발견하여 표현하기 위해 엔터티-관계 다이어그램을 생성하는 것이다. 엔터티-관계 다이어그램은 조직과 다양한 데이터 베이스 사용자에게 어떠한 데이터가 중요한지 나타내기 위해서 사용된다.
개념 데이터 모델은 사용자와 시스템 개발자가 데이터 요구 사항을 발견하는 것을 지원한다. 개념 데이터 모델은 추상적이다. 그렇기 때문에 그 모델은 상위의 문제에 대한 구조화를 쉽게 하며, 사용자와 개발자가 시스템 기능에 대해서 논의할 수 있는 기반을 형성한다.
또한 개념 데이터 모델은 현 시스템이 어떻게 변형 되어야 하는가를 이해하는데 유용하다.
논리적 데이터 모델링 (Logical Data Modeling)
이 과정은 데이터베이스 설계의 중요한 부분으로, 비즈니스 정보의 논리적 구조와 규칙을 명확하게 정의한다. 여기서는 데이터가 어떻게 사용되고, 누가 사용하는지에 대한 방법을 정리한다. 이 모델링은 시스템 설계 전체 과정을 지원하며, 가장 중요한 활동 중 하나는 '정규화'를 꼽을 수 있다. 정규화는 데이터의 중복을 제거하고 일관성을 확보하는 과정으로, 데이터를 더 신뢰할 수 있고 효율적으로 구성하는 데 도움이 된다.
물리적 데이터 모델링 (Physical Data Modeling)
이 단계에서는 논리적 모델이 실제 컴퓨터 하드웨어에 어떻게 구현될지를 결정한다. 이 과정은 데이터가 컴퓨터에 물리적으로 어떻게 저장되는지, 테이블과 칼럼 등의 물리적 저장 구조, 데이터 추출 방법 등을 정의한다.
5. 프로젝트 생명주기(Life Cycle)에서 데이터 모델링
Waterfall 모델에서의 데이터 모델링
전통적인 워터폴(Waterfall) 방식에서는, 데이터 모델링이 분석과 설계라는 두 단계로 나뉜다. 분석 단계에서는 업무 중심의 논리적 데이터 모델링을 수행하고, 설계 단계에서는 하드웨어와 성능을 고려한 물리적 데이터 모델링을 진행한다.
나선형 모델과 RUP에서의 데이터 모델링
나선형 모델이나 RUP(Rational Unified Process) 같은 방법론에서는, 프로젝트의 규모에 따라 논리적 데이터 모델링과 물리적 데이터 모델링이 분석과 설계 단계 모두에서 진행된다. 이 경우 분석 단계에서 논리적 데이터 모델링이 더 중요한 역할을 한다.
통합된 접근 방식
객체지향 개념에서는 데이터 모델링과 프로세스 모델링을 별개로 구분하지 않는다. 대신, 데이터(속성)와 프로세스(메소드)를 포함하는 클래스를 중심으로 모델링을 진행한다. 이 접근법은 데이터와 프로세스를 함께 고려하여 통합적으로 모델링한다.
결론적으로, 다양한 프로젝트 관리 방법론에 따라 데이터 모델링의 접근 방식과 중요성이 달라진다. 워터폴 방식은 더 전통적이고 단계별로 접근하는 반면, 나선형 모델이나 RUP는 더 유연하고 반복적인 접근을 취한다. 객체지향 접근법은 데이터와 프로세스를 통합하여 보다 포괄적인 모델을 구축한다.
6. 데이터 모델링에서 데이터 독립성의 이해
데이터 독립성의 필요성
독립적 기능 유지 및 극대화
데이터 독립성은 각 데이터 컴포넌트가 독립적으로 자신의 기능을 유지하고 최대한 발휘할 수 있게 한다. 이는 서비스 중심 아키텍처(SOA)나 컴포넌트 기반의 모듈 구성에서도 볼 수 있다. 이러한 접근 방식은 각 서비스나 컴포넌트가 개별적으로도 의미가 있고, 다른 서비스와 결합될 때도 가치가 있음을 의미한다.
변경으로부터의 독립성
데이터 독립성은 데이터가 다른 기능의 변경에 의해 쉽게 영향받지 않도록 한다. 이는 데이터가 자신의 고유한 기능을 유지할 수 있게 하여 시스템의 안정성과 유연성을 높인다.
데이터 종속성과의 대비
데이터 독립성의 개념을 이해하기 위해서는 데이터 종속성의 개념을 알아야 한다. 과거 파일 기반 시스템에서 데이터는 응용 프로그램에 종속되었고, 사용자가 데이터에 접근하는 방식에 따라 데이터 구성이 영향을 받았었다.
유지보수 비용 절감 및 복잡도 감소
데이터 독립성은 유지보수 비용을 줄이고, 데이터 복잡도를 낮추며 중복 데이터를 줄이는 데 목적이 있다. 사용자 요구사항이 지속적으로 변함에 따라 화면과 데이터베이스 간의 독립성을 유지하는 것이 중요하다.
결론적으로, 데이터 독립성은 시스템의 안정성, 유연성, 유지보수 용이성을 향상시키고, 데이터 구조의 복잡도와 중복을 감소시키는 데 필수적인 개념이다.
데이터베이스 3단계 구조
외부 단계(External Level)
이 단계는 사용자에게 가장 가까운 부분으로, 사용자 개개인이 보는 데이터에 대한 관점과 연결된다. 사용자가 처리하고자 하는 데이터 유형과 관점, 방법에 따라 다양한 스키마 구조를 가질 수 있다. 이는 사용자마다 다를 수 있는 데이터의 표현 방식을 의미한다.
개념 단계(Conceptual Level)
이 단계는 사용자가 처리하는 데이터 유형의 공통적인 사항을 처리하는 통합된 뷰를 제공한다. 다양한 사용자 요구사항을 하나의 통합된 형태로 정리하여 데이터 모델의 구조를 디자인하는 단계이다. 즉, 여러 사용자 뷰를 하나로 통합한 개념적인 데이터 모델을 의미한다.
내부적 단계(Internal Level)
이 마지막 단계는 데이터가 실제로 물리적으로 어떻게 저장되는지에 대한 스키마 구조를 다룬다. 데이터의 물리적 저장 방법, 저장소의 구조와 같은 내부적인 측면을 포함한다.
이 세 단계는 서로 간섭되지 않으면서도 데이터의 논리적 구조와 물리적 저장 방식 사이의 독립성을 보장하는 구조를 제공한다. 이 모델은 데이터베이스 설계와 관리에서 중요한 역할을 하며, 각 단계가 서로 영향을 미치지 않도록 하여 데이터 구조의 유연성과 확장성을 증가시킨다.
데이터독립성 구성요소
데이터베이스 스키마 구조는 3단계로 구분되고 각각은 상호 독립적인 의미를 가지고 고유한 기능을 갖는다.
데이터 모델링은 통합관점의 뷰를 가지고 있는 개념 스키마를 만들어가는 과정으로 이해할 수 있다.
항목 | 내용 | 비고 |
외부스키마 (External Schema) |
- View 단계 여러 개의 사용자 관점으로 구성. 즉 개개인 사용자 단계로서 개개인 사용자가 보는 개인적 DB 스키마 - DB의 개개인 사용자나 응용프로그래머가 접근하는 DB 정의 |
사용자관점 접근하는 특성에 따른 스키마 구성 |
개념스키마 (Conceptual Schema) |
- 개념단계 하나의 개념적 스키마로 구성하여 모든 사용자 관점을 통합한 조직 전체의 DB를 기술하는 것 - 모든 응용시스템들이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 DB를 기술한 것으로 DB에 저장되는 데이터와 그들간의 관계를 표현하는 스키마 |
통합 관점 |
내부스키마 (Internal Schema) |
- 내부단계. 내부 스키마로 구성. DB가 물리적으로 저장된 형식 - 물리적 장치에서 데이터가 실제적으로 저장되는 방법을 표현하는 스키마 |
물리적 저장구조 |
두 영역의 데이터 독립성
위처럼 3단계로 개념이 분리되면서 각각의 영역에 대한 독립성을 지정하는 용어가 바로 논리적인 독립성과 물리적인 독립성이다.
독립성 | 내용 | 특징 |
논리적독립성 | - 개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않도록 지원하는 것. - 논리적 구조가 변경되어도 응용 프로그램에 영향 없음. |
- 사용자 특성에 맞는 변경 가능 - 통합 구조 변경 가능 |
물리적독립성 | - 내부 스키마가 변경되어도 외부/개념 스키마는 영향을 받지 않도록 지원하는 것. - 저장장치의 구조변경은 응용프로그램과 개념스키마에 영향 없음. |
- 물리적인 구조 영향 없이 개념구조 변경 가능 - 개념구조 영향 없이 물리적인 구조 변경 가능 |
즉, 논리적 데이터 독립성은 외부 변경에도 개념 스키마가 변하지 않는 특징을 잦는다.
사상 (Mapping)
상호 독립적인 개념을 연결시켜주는 다리를 뜻한다. 데이터 독립성에는 크게 2가지의 사상이 도출된다.
사상 | 내용 | 예시 |
외부적/개념적 사상 (논리적 사상) |
- 외부적 뷰와 개념적 뷰의 상호 관련성을 정의한다. | 사용자가 접근하는 형식에 따라 다른 타입의 필드를 가질 수 있다. 개념적 뷰의 필드 타입은 변화가 없다. |
개념적/내부적 사상 (물리적 사상) |
- 개념적 뷰와 저장된 데이터베이스의 상호관련성을 정의한다. | 만약 저장된 데이터베이스 구조가 바뀐다면 개념적/내부적 사상이 바뀌어야 한다. 그래야 개념적 스키마가 그대로 남아있게 된다. |
7. 데이터 모델링의 중요한 세 가지 개념
데이터 모델링의 세 가지 요소
데이터 모델링을 구성하는 중요한 개념은 총 세가지로 가 있다.
1) 업무가 관여하는 어떤 것(Things)
2) 어떤 것이 가지는 성격(Attributes)
3) 업무가 관여하는 어떤 것 간의 관계(Relationships)
모든 사람, 사물, 개념 등은 어떤 것, 어떤 것 간의 관계, 성격의 구분을 통해서 분류될 수 있다. 바로 이러한 원리. 즉 자연계에 존재하는 모든 유형의 정보들을 세 가지 관점의 접근 방법을 통해 모델링을 진행하는 것이다.
단수와 집합(복수)의 명명
개념 | 복수/집합 개념 타입/클래스 |
개별/단수개념 어커런스/인스턴스 |
어떤 것 (Things) |
엔티티 타입 (Entity Type) | 엔티티 (Entity) |
엔티티 (Entity) | 인스턴스(Instance) 어커런스(Occurrence) |
|
어떤 것 간의 연관 (Association between Things) |
관계 (Relationship) | 페어링 (Pairing) |
어떤 것의 성격 (Characteristic of a Things) |
속성 (Attribute) | 속성값 (Attribute Value) |
엔티티는 어떤 것에 대한 집합을 명명하여 지칭한다. 어떤 것에 대한 개별 지칭으로 엔티티가 단 수명사로서 단어의 의미가 있지만, 엔티티를 집합개념으로 사용하는 경우에는 개별요소에 대해서는 인스턴스/어커런스를 단수의 개념으로 사용하여 부른다.
관계(Relationship)도 이를 복수로 통칭하여 관계로 표현하고 관계에 포함된 개별 연관성을 패어링 이라고 부르기도 한다. 그러나 패어링이라는 용어는 실제 데이터 모델링을 할 때는 잘 사용하지 않 으며 그냥 일반적으로 단수든 복수든 관계라고 표현하는 경우가 많다.
어떤 것이 가지는 성격 (Attribute)에 대한 집합개념이 속성이고 그 안에 개별 값들을 속성값으로 구분하여 복수와 단수의 개념으로 구분할 수 있다.
8. 데이터 모델의 표기법인 ERD의 이해
데이터 모델 표기법
Entity-relationship model(E-R Model) : 1976년 피터첸(Peter Chen)이 발명한 표기법으로 엔티티를 사각형으로 표현하고, 관계를 마름모, 속성을 타원형으로 표현하는 이 표기법은 데이터 모델링에 대한 이론을 배울 때 많이 사용한다.
대표적으로 IE/Crow's Foot, Barker 표기법을 많이 사용한다.
ERD(Entity Relationship Diagram) 표기법을 이용하여 모델링하는 방법
ERD를 그리는 것은 어떻게 그리든 업무에 전혀 지장을 주지 않지만, 일정한 규칙을 지정하여 그림으로써 데이터 모델을 누구나 공통된 시각으로 파악할 수 있고 의사소통을 원활하게 하는 장점이 있다.
ERD 작성하는 작업 순서
1) 엔티티를 그린다.
2) 엔티티를 적절하게 배치한다.
3) 엔티티간 관계를 설정한다.
4) 관계명을 기술한다.
5) 관계의 참여도를 기술한다.
6) 관계의 필수 여부를 기술한다.
엔티티 배치
1) 가장 중요한 엔티티를 왼쪽 상단에 배치한다.
2) 이것을 중심으로 다른 엔티티를 나열하며 전개한다.
3) 해당 업무에서 가장 중요한 엔티티는 왼쪽 상단에서 조금 아래쪽 중앙에 배치하여 전체 엔티티와 어울릴 수 있도록 하면 향후 관계를 연결할 때 선이 꼬이지 않고 효과적으로 배치가 가능하다.
9. 좋은 데이터 모델의 요소
아래의 요소들은 데이터 모델의 효율성, 유연성, 그리고 확장성을 보장하는 데 중요한 내용이다. 또한, 데이터 모델이 복잡하지 않고 간결하며, 업무 환경의 변화에 쉽게 적응할 수 있도록 설계되어야 한다.
완전성(Completeness)
데이터 모델은 업무에서 필요한 모든 데이터를 포함해야 합니다. 만약 중요한 데이터 속성이 누락되면, 모델은 불완전합니다.
중복배제(Non-Redundancy)
데이터베이스 내에 동일한 정보가 중복되어 기록되어서는 안 됩니다. 예를 들어, '나이'와 '생년월일' 같은 중복된 정보는 불필요한 저장 공간과 데이터 일관성 문제를 야기할 수 있습니다.
업무규칙(Business Rules)
데이터 모델은 업무 프로세스를 반영한 업무규칙을 명확하게 표현해야 합니다. 예를 들어, 급여 관련 업무규칙이 모델에 반영되어야 합니다.
데이터 재사용(Data Reusability)
데이터 모델은 데이터의 통합성과 독립성을 고려하여 설계되어야 합니다. 이는 데이터 중복을 감소시키고, 변화에 유연하게 대응할 수 있는 구조를 만드는 데 중요합니다.
의사소통(Communication)
데이터 모델은 업무 규칙을 명확하게 표현하여, 관련자들이 동일한 이해를 가질 수 있도록 해야 합니다.
통합성(Integration)
데이터 모델은 전체 조직 관점에서 통합적으로 설계되어야 하며, 중복을 최소화하고 한 번 정의된 데이터를 여러 영역에서 활용할 수 있도록 해야 합니다.
'CapacityBuilding > SQLD 취득' 카테고리의 다른 글
[SQLD] SQL 기본 - SELECT, WHERE, GROUP BY, HAVING, ORDER BY 요약 (1) | 2024.02.06 |
---|---|
[SQLD] 데이터 모델과 SQL - 관계/조인, 트랜잭션, Null속성, 본질 vs 인조 식별자 요약 (2) | 2024.02.05 |
[SQLD] 데이터 모델과 SQL - 정규화 요약 (0) | 2024.02.02 |
[SQLD] 데이터 모델링의 이해 - 관계, 식별자 요약 (0) | 2024.02.01 |
[SQLD] 데이터 모델링의 이해 - 엔터티, 속성 요약 (0) | 2024.01.31 |