참고사이트

데이터 모델링의 3단계

데이터 모델링은 데이터베이스 설계의 필수적이며, 이를 통해 현실 세계의 데이터를 체계적으로 관리할 수 있다. 데이터 모델링은 개념적 데이터 모델링, 논리적 데이터 모델링, 물리적 데이터 모델링의 세가지 주요 단계로 나뉜다. 각 단계는 서로 다른 수준의 추상화를 통해 데이터를 정의하고 관리하는 방법을 제시한다.

1️⃣ 개념적 데이터 모델링(Conceptual Data Modeling)

개념적 데이터 모델링은 조직과 사용자들의 데이터 요구사항을 찾고 분석하는 단계이다. 이 단계는 추상화 수준이 높고, 주로 비즈니스와 관련된 엔터티와 그들 간의 관계를 식별하고 표현하는 데 중점을 둔다.

• 핵심 엔터티 식별
  • 조직에 중요한 데이터 엔터티를 식별한다.
  • 예를 들어, 고객, 주문, 제품 등이 엔터티가 될 수 있다.
• 관계 정의
  • 엔터티 간의 관계를 정의한다.
  • 예를 들어, 고객이 주문을 한다, 주문이 제품을 포함한다는 관계를 설정한다.
• ER 다이어그램 생성
  • 엔터티와 관계를 시각적으로 표현하기 위해 ER 다이어그램을 작성한다.

이렇게 개념적 데이터 모델링은 사용자와 시스템 개발자가 데이터 요구사항을 보고 논의할 수 있는 기반을 제공하고, 현 시스템이 어떻게 변형되어야 하는지 이해하는데 유용한 도움을 준다.

2️⃣ 논리적 데이터 모델링(Logical Data Modeling)

논리적 데이터 모델링은 데이터베이스 설계 프로세스의 일환으로, 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 단계이다. 이 단계는 데이터베이스 관리 시스템(DBMS) 독립적으로 설계된다.

• 정규화
  • 데이터 중복을 최소화하고 일관성을 확보하기 위해 데이터를 정규화한다.
• 식별자 확정
  • 각 엔터티의 기본 키와 외래 키를 확정한다.
• M:M 관계 해소
  • 다대다(Many-to-Many) 관계를 해소하여 중간 테이블을 생성한다.
• 참조 무결성 규칙 정의
  • 데이터의 무결성을 유지하기 위한 규칙을 정의한다.

논리적 데이터 모델링은 데이터베이스의 논리적 구조를 명확하게 정의하여 데이터 저장과 접근을 효율적으로 하고, 정규화 같은 활동을 통해 데이터의 일관성을 유지하고 중복을 제거한다.

3️⃣ 물리적 데이터 모델링(Phsical Data Modeling)

물리적 데이터 모델링은 논리 데이터 모델이 실제 데이터 저장소로서 어떻게 구현될지를 다루는 단계이다. 이는 컴퓨터 하드웨어에 데이터가 물리적으로 어떻게 저장될 것인지를 정의한다.

• 물리적 스키마 설계
  • 테이블, 칼럼, 인덱스 등의 물리적 저장구조를 정의한다.
• 저장 장치 선택
  • 데이터가 저장될 물리적 장치를 선택하고 구성한다.
• 데이터 접근 방법 정의
  • 데이터를 추출하고 관리하기 위한 접근 방법을 정의한다.

물리적 데이터 모델링은 데이터가 컴퓨터 하드웨어에 효율적으로 접근될 수 있도록 설계하고, 데이터 베이스의 성능을 최적화 한다.

데이터 모델링에서 데이터독립성의 이해

1️⃣ 데이터 독립성의 필요성

1. 데이터 독립성의 정의

데이터 독립성은 데이터베이스의 구조가 응용 프로그램이나 사용자 인터페이스로부터 독립적으로 설계될 수 있도록 하는 개념이다. 이는 데이터베이스가 변경되더라도 응용 프로그램이나 사용자 인터페이스가 최소한의 영향만 받도록 하는것을 목표한다.

2. 데이터 독립성의 배경

• 과거에는 데이터가 파일 시스템으로 관리되었고, 이 방식에는 데이터 구조의 변경이 응용 프로그램에 직접적인 영향을 미쳤다.
  • 이러한 데이터 종속성은 유지보수 비용을 증가시키고 데이터 관리의 복잡성을 높였다.
• 데이터 독립성의 개념은 이러한 문제를 해결하고자 등장했다. 데이터 독립성을 확보하면 데이터베이스와 응용 프로그램 간의 결합도를 낮추어 변화에 유연하게 대응할 수 있다.

3. 데이터 독립성의 효과

• 각 View의 독립성 유지
  • 계층별로 독립적으로 변경이 가능하여, 한 계층의 변경이 다른 계층에 영향을 주지 않는다.
• 단계별 Schema 제공
  • 데이터 정의어(DDL)와 데이터 조작어(DML)가 계층별로 다르게 적용된다.

2️⃣ 데이터베이스 3단계 구조(Three-Schema Architecture)

ANSI/SPARC 3단계 모델

미국 표준 협회(ANSI) 산하의 X3 위원회는 1978년에 DBMS와 그 인터페이스를 위해 3단계 아키텍처를 제안했다. 이 모델은 외부 스키마, 개념 스키마, 내부 스키마의 세 가지 계층으로 구성된다.

1. 외부 스키마 (External Schema)

외부 스키마는 개별 사용자나 응용 프로그램이 데이터베이스를 보는 관점을 정의한다. 이는 특정 사용자 그룹이 필요로 하는 데이터의 하위 집합을 제공합니다.

그 예시로, 판매 부서와 재무 부서가 각각 다른 외부 스키마를 가질 수 있다. 판매 부서는 고객과 주문 정보를 주로 사용하고, 재무 부서는 결제와 송장 정보를 주로 사용할 수 있다.

2. 개념 스키마 (Conceptual Schema)

개념 스키마는 데이터베이스의 전체 구조를 정의하며, 모든 사용자 그룹이 공유하는 데이터를 통합한 뷰를 제공한다. 이는 데이터베이스의 논리적 구조를 나타내며, 엔터티, 속성, 관계 등을 포함한다.

예시로 고객, 주문, 제품 등의 엔터티와 그들 간의 관계를 정의한 통합된 데이터베이스 스키마이다.

3. 내부 스키마 (Internal Schema)

내부 스키마는 데이터베이스의 물리적 저장 구조를 정의합니다. 이는 데이터가 컴퓨터 시스템의 저장 장치에 어떻게 저장되고 접근되는지를 다룬다.

예시로 테이블, 인덱스, 저장 프로시저, 데이터 파일 등 물리적 저장 매체에 대한 정의를 포함한다.

3️⃣ 데이터 독립성의 요소

데이터 독립성의 두가지 유형은 다음과 같다.

1. 논리적 데이터 독립성 (Logical Data Independence)
   • 외부 스키마와 개념 스키마 간의 독립성을 의미한다.
   • 개념 스키마가 변경되어도 외부 스키마가 영향을 받지 않도록 한다.
   • 예: 새로운 속성을 추가하거나 테이블을 변경해도, 기존 응용 프로그램이 영향을 받지 않도록 유지.
2. 물리적 데이터 독립성 (Physical Data Independence)
   • 개념 스키마와 내부 스키마 간의 독립성을 의미한다.
   • 내부 스키마가 변경되어도 외부/개념 스키마가 영향을 받지 않도록 한다.
   • 예: 데이터 파일의 위치나 인덱스 구조를 변경해도, 논리적 데이터 구조에는 영향을 미치지 않음.

4️⃣ 데이터 독립성의 사상 (Mapping)

사상(Mapping)은 상호 독립적인 개념을 연결시키는 다리 역할을 한다. 데이터 독립성에서는 두 가지 주요 사상이 있습니다.

1. 논리적 사상 (Logical Mapping)
   • 외부 스키마와 개념 스키마를 연결한다.
   • 각 사용자 그룹의 요구에 맞는 뷰를 제공하면서, 통합된 개념 스키마와 연계한다.
   • 예: 판매 부서의 외부 스키마가 개념 스키마의 일부 엔터티와 속성을 참조
2. 물리적 사상 (Physical Mapping)
   • 개념 스키마와 내부 스키마를 연결한다.
   • 데이터베이스의 논리적 구조가 물리적 저장 구조와 일치하도록 한다.
   • 예: 개념 스키마의 테이블이 실제 데이터 파일과 매핑.

데이터 모델링의 중요한 세가지 개념

데이터 모델링은 데이터베이스 설계의 중요한 기초이며, 이를 구성하는 세가지 핵심 개념은 데이터 모델에 대한 이해의 근간이 된다. 이 세가지 개념은 데이터 모델링을 완성해 가는 데 필수적이다.

1️⃣ 데이터 모델링의 세가지 요소

1. 업무가 관여하는 어떤 것(Things)
   • '어떤 것'은 데이터 모델링에서 엔티티(Entity)를 의미한다.
   • 이는 업무와 관련된 주요 객체나 개념을 나타내며, 데이터 베이스에서는 테이블로 표현된다.
   • 예시: 고객, 제품, 주문 등이 있다.
2. 어떤 것이 가지는 성격(Attributes)
   • '성격'은 엔티티가 가지는 특성을 의미하며, 데이터 모델링에서는 속성(Attribute)으로 표현된다. 이는 데이터베이스에서 컬럼으로 나타난다.
   • 예시: 고객의 이름, 제품의 가격, 주문의 날짜 등
3. 업무과 관여하는 어떤 것 간의 관계(Relationships)
   • '관계'는 두 엔티티 간의 연관성을 의미한다.
   • 이는 데이터베이스에서 외래 키(Foreign Key)로 구현된다.
   • 예시: 고객이 주문을 한다, 주문이 제품을 포함한다 등.

이 세가지 요소를 통해 데이터 모델링은 현실 세계의 데이터를 체계적으로 표현할 수 있다.

2️⃣ 단수와 집합(복수)의 명명

데이터 모델링에서 단수와 복수의 개념은 중요한 역할을 한다.

• 단수(Entity Instance)
  • 특정 엔티티 하나의 개별 예시를 의미한다.
  • 예를 들어, 특정 고객 한 명 김철수는 고객 엔티티의 인스턴스이다.
• 집합(Entity Set)
  • 동일한 유형의 엔터티들의 모음을 의미한다.
  • 예를 들어, 모든 고객은 고객 엔터티 집합에 속한다.

데이터 모델링의 이해관계자

1️⃣ 이해관계자의 데이터 모델링 중요성 인식

데이터 모델링은 단순히 데이터베이스를 설계하는 것이 아니라, 전체 업무 시스템을 이해하고 분석하여 표현하는 과정이다. 이 때문에 데이터 모델링은 여러 이해관계자들에게 중요한 역할을 한다.

• DBA
  • 데이터베이스 관리자는 데이터 모델링을 전적으로 담당하기도 하지만, 대형 프로젝트에서는 주로 모델링을 전문적으로 수행하는 모델러와 협력한다.
• 응용 시스템 개발자
  • 실제로 데이터 모델링을 수행하는 경우가 많다. 데이터 모델링을 통해 업무 요구사항을 분석하고, 이를 기반으로 프로그램을 설계한다.

정보시스템을 구축하는 대부분의 시스템은 데이터에 기반을 두고 있다. 따라서 데이터베이스 설계는 시스템의 성공에 매우 중요한 요소이다.

잘못된 데이터베이스 설계는 모든 프로그램과 데이터 트랜잭션에 부정적인 영향을 미칠 수 있다.

실제 업무시스템을 구축하는 실제 프로젝트에서는 데이터베이스를 전문적으로 하는 DBA가 데이터 모델링을 전적으로 하는 예는 거의 없다. 업무 시스템을 개발하는 응용시스템 개발자가 데이터 모델링도 같이 하게 되는데, 그 이유는 데이터 모델링 과정이 단지 데이터 베이스를 설계한다는 특면보다 업무를 이해하고 분석하여 표현하는 것이 중요하고, 그것을 바탕으로 관련자와 소통하기 때문이다!

2️⃣ 데이터 모델링의 이해관계자

데이터 모델링에 대한 이해와 참여가 필요한 주요 이해관계자는 다음과 같다.

1. IT 기술자
   • 시스템 엔지니어, 개발자, 데이터베이스 관리자 등 모든 IT 기술자는 데이터 모델링을 이해하고 전문적으로 수행할 수 있어야 한다.
   • 예시: 프로젝트에 참여하는 모든 IT 기술자는 데이터 모델을 정확히 해석하고, 필요시 데이터 모델링 작업을 수행할 수 있어야 한다.
2. 비 IT 종사자
   • 정보화를 추진하는 비즈니스 전문가나 관리자는 데이터 모델링의 기본 개념과 세부사항을 이해할 필요가 있다.
   • 예시: 업무 분석을 수행하는 비즈니스 담당자는 데이터 모델링에 대한 이해를 통해 프로젝트 수행 중 의사소통을 원활히 하고, 업무 요구사항을 정확히 반영할 수 있어야 한다.

데이터 모델링은 정보 시스템 구축의 핵심 요소로, 이를 잘 이해하고 수행하는 것이 성공적인 시스템 구축의 열쇠이다.

모든 이해관계자가 데이터 모델링을 이해함으로써 의사소통을 원활히 하고, 시스템 구축 과정에서 발생할 수 있는 오류와 리스크를 줄일 수 있다.

데이터 모델의 표기법인 ERD의 이해

1️⃣ 데이터 모델 표기법

• E-R모델
  • 1976년 피터 첸(Peter Chen)이 개발한 엔티티-관계 모델(Entity-Relationship Model)은 엔티티를 사각형으로 관계를 마름모로, 속성을 타원형으로 표현한다.
  • 이는 데이터 모델링 이론을 배우는 데 널리 활용된다.
• 바커 표기법(Barker Notation)
  • 이 표기법은 영국의 시스템 개발 방법론가인 Richard Barker가 만든 것으로, IE 표기법과 함께 사용된다.
• Information Engineering(IE) 표기법
  • 이 표기법은 시스템 개발과 데이터베이스 설계에 널리 사용되며, 바커 표기법과 상호 전환이 가능하다.

2️⃣ ERD(Entity Relationship Diagram)표기법을 이용하여 모델링하는 방법

1. ERD의 역할

ERD는 업무 분석에서 도출된 엔티티와 엔티티 간의 관계를 시각적으로 표현하여, 데이터의 흐름과 프로세스의 연관성을 이해하기 쉽게 만들어준다. 이는 프로젝트의 핵심 산출물로서 중요한 역할을 한다.

2. ERD 작성의 기본 원칙

ERD 작성은 일정한 규칙에 따라 그림으로 그려지며, 이는 데이터 모델을 공통된 시각으로 파악하고 원할한 의사소통을 가능하게 한다.

3. ERD 작업 순서

1. 엔티티를 그린다.
   • 먼저 모델링할 엔티티를 식별하고 그린다.
2. 엔티티를 적절하게 배치한다.
   • 엔티티를 쉽게 이해할 수 있도록 배치한다.
   • 중요한 엔티티는 왼쪽 상단에 배치하고, 나머지 엔티티는 중앙에서 전개한다.
3. 엔티티 간의 관계를 설정한다.
   • 엔티티간의 관계를 정의하고 연결한다
4. 관계명을 기술한다.
   • 각 관계에 이름을 부여한다.
5. 관계의 참여도를 기술한다.
   • 관계에 참여하는 엔티티의 수를 명시한다.
6. 관계의 필수 여부를 기술한다.
   • 관계가 필수인지 선택인지 표시한다.

4. 엔티티 배치 방법

• 사람의 눈은 일반적으로 왼쪽에서 오른쪽, 위에서 아래로 이동하기 때문에 중요한 엔티티는 왼쪽 상단에 배치하는 것이 좋다.
• 중심 엔티티는 중앙에 배치하여 다른 엔티티들과의 관계를 쉽게 연결할 수 있도록 한다.

5. ERD 관계 설정

• 관계 설정 시 중복 관계나 원형 관계(Circular Relationship)가 발생하지 않도록 주의해야 한다.
• 초기에는 모든 관계를 식별자 관계(Primary Key상속 관계)로 설정한다.

6. ERD 관계 명칭 표시

• 관계에 이름을 부여하며, 이는 현재형을 사용하고, 지나치게 포괄적인 용어는 피한다.
• 실제 프로젝트에서는 관계 명칭이 명확하게 드러나지 않더라도 대부분의 관계는 엔티티의 성질과 주식별자를 통해 유추할 수 있다.

7. ERD 관계 차수와 선택성 표시

• 관계 차수(Cardinality)를 표현하여 각 엔티티 내 인스턴스들이 관계에 얼마나 참여하는지를 나타낸다.
• 관계 차수 IE 표기법과 Barker 표기법에 따라 다르게 표기된다.
  • 하나(1)의 관계는 실선으로, 다수(Many)의 관계는 까마귀 발 모양으로 그린다.
• 관계의 필수/선택 표시는 관계선에 원을 표시하여 나타낸다.
  • 선택참여관계는 ERD에서 관계를 나타내는 선에서 선택참여하는 엔터티 쪽을 원으로 표시한다. 필수참여는 아무런 표시를 하지 않는다.

좋은 데이터 모델의 요소

데이터 모델의 품질을 평가하는 것은 매우 어렵지만, 일반적으로 좋은 데이터 모델이 갖추어야 할 몇 가지 요소를 통해 그 품질을 판단할 수 있다.

1️⃣ 완전성(Completeness)

데이터 모델에는 업무에서 필요로 하는 모든 데이터가 정의되어 있어야 한다. 데이터 모델의 완전성은 가장 기본적이면서도 중요한 요소이다. 이 기준이 충족되지 않으면 다른 평가 기준도 무의미하다.

예시로, 보험사의 데이터 모델에 고객의 작업을 관리하는 속성이 존재하지 않는다면 이는 심각한 문제이다. 모든 필수적인 데이터가 모델에 포함되어 있어야 한다.

2️⃣ 중복배제(Non-Redundancy)

하나의 데이터베이스 내에 동일한 사실은 반드시 한 번만 기록되어야 한다. 중복된 데이터는 저장 공간의 낭비, 데이터 일고나성 유지의 어려움, 추가적인 데이터 조작 비용 등을 초래한다.

예시로, 한 테이블에 '나이'컬럼과 '생년월일'컬럼이 동시에 존재하면 중복 데이터로 간주된다. 나이는 생년월일을 통해 계산할 수 있으므로 중복을 피해야 한다.

3️⃣ 업무규칙(Business Rules)

데이터 모델링 과정에서 도출된 업무 규칙을 데이터 모델에 표현하고 이를 모든 사용자가 공유할 수 있도록 해야 한다. 이는 데이터 일고나성과 무결성을 유지하는 데 중요하다

예시로, 보험사의 사원 급여 관리에서 사원 구분별로 급여 항목이 차등적으로 지급된다는 업무 규칙을 데이터에 포함시켜야 한다. 이를 통해 모든 사용자가 동일한 기준으로 데이터를 처리 할 수 있다.

4️⃣ 데이터 재사용(Data Reusability)

데이터 재사용성을 높이기 위해 데이터의 통합성과 독립성을 충분히 고려해야 한다. 데이터가 통합된 상태로 설계되어야 데이터 재사용이 용이하다.

예시로, 과거에는 부서 단위로 데이터가 분할되어 관리되었지만, 이제는 회사 전체 관점에서 공통 데이터를 도출하고 이를 모든 영역에서 사용할 수 있도록 통합 모델을 설계해야 한다.

5️⃣ 의사소통(Communication)

데이터 모델은 의사소통의 도구로서, 데이터 관점에서 업무를 분석하고 설계하는 최종 산출물이다. 데이터 모델에 업무 규칙을 최대한 자세하게 표현해야 한다.

예시로, '사원'테이블에 '정규직', '임시직' 등의 사원 구분이 포함되고, '정규직'사원만 '급여'테이블과 관계를 가진다는 규칙을 명확히 모델에 표현해야 한다. 이를 통해 관련자들이 동일한 이해를 공유할 수 있다.

6️⃣ 통합성(Intergration)

동일한 데이터는 조직 전체에서 한 번만 정의되고 여러 영역에서 참조하여 사용해야 한다. 이는 데이터 품질과 관리의 효율성을 높이는 데 중요하다.

예시로, 고객 정보와 같은 마스터 데이터를 한 곳에서 관리하고, 다른 시스템에서 참조하는 방식으로 통합 데이터를 관리해야 한다. 이를 통해 데이터 중복을 줄이고 일관성을 유지할 수 있다.