1과목 데이터 모델링의 이해

• 10문제
• 외우기 보다는 반복적으로 읽어서 전반적인 내용을 이해하는 수준에서 마무리 하는것을 목표로 잡아야 겠습니다.

제 1장 데이터 모델링의 이해

1절 데이터 모델의 이해

모델링의 특징

• 추상화 : 일정한 형식에 맞추어 표현
• 단순화 : 약속된 규약에 의해 제한
• 명확화 : 애매모호함을 제거 정확하게 기술

모델링의 3가지 관점

• 데이터 관점 (what) : 업무가 어떤 데이터와 관려이 있는지, 데이터간의 관계가 무엇인지
• 프로세스 관점 (how) : 업무가 실제하고 있는 일이 무엇인지, 무엇을 해야 하는지
• 데이터와 프로세스의 상관관점 (interaction) : 업무가 처리됨에 따라 데이터는 어떻게 영향을 받고 있는지

데이터 모델링이란…

• 정보시스템을 구축하기 위한 데이터관점의 업무 분석 기법
• 현실세계의 데이터(what)에 대해 약속된 표기법에 의해 표현하는 과정
• 데이터베이스를 구축하기 위한 분석/설계의 과정

데이터 모델의 중요성

• 파급효과(leverage) : 데이터 모델이 잘못되어서 나중에 변경될때에는 전체 시스템에 큰 변경 사항이 발생함
• 복잡한 정보 요구사항의 간결한 표현(conciseness) : 요구사항을 정확하고 간결하게 표현. 요구사항 파악시 데이터 모델을 리뷰하는 것이 더 빠름.
• 데이터 품질(data quality) : 기간이 오래되고 쌓인 데이터를 활용하려면 품질이 중요. (정확성, 중복데이터 등…). 품질이 안좋으면 활용하지 못한 쓰레기가 될수 있음

데이터 모델링의 유의점

• 중복(duplication) : 여러 곳에 같은 정보 저장하지 않도록
• 비유연성(inflexibility) : 데이터 정의와 사용 프로세스를 분리. 각각의 작은 변화가 서로에게 영향을 미치지 않도록
• 비일관성(inconsistency) : 서로 영향을 미치는 데이터간 상호 연관 관계에 대한 명확한 정의가 필요 (ex. 납부이력과 신용상태)

데이터 모델링의 3단계 진행 (추상화 수준에 따라)

• 개념적 데이터 모델(conceptual)
  • 추상화 수준이 높고 업무중신적이고 포괄적인 수준의 모델링 진행. 전사적 데이터 모델링, EA수립시 많이 이용
  • 엔티티 - 관계 다이어그램 생성
  • 전사적 데이터 모델링 (enterprise)
  • 중요한 2가지 기능
    1. 사용자와 시스템 개발자가 데이터 요구 사항을 발견하는 것을 지원
    2. 현 시스템이 어떻게 변형되어야 하는지를 이해하는데 유용
• 논리적 데이터 모델 (logical)
  • 시스템으로 구축하고자 하는 업무에 대한 Key, 속성, 관계 등을 정확하게 표현, 재사용성이 높음
  • 식별자 확정, 정규화, M:M 관계 해소, 참조 무결성 규칙 정의 등
  • 데이터베이스 설계 프로세스의 input으로 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 기법 또는 과정
• 물리적 데이터 모델 (physical)
  • 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 무리적인 성격을 고려하여 설계
  • 물리적 스키마 : 데이터가 물리적으로 컴퓨터에 어떻게 저장될 것인가에 대한 정의
  • 테이블, 칼럼 등의 저장구조와 저장 장치, 접근 방법 등

데이터 독립성의 필요성 <-> 데이터 종속성

• 유지보수 비용증가
• 데이터 중복성 증가
• 데이터복잡도 증가
• 요구사항 대응 저하

데이터 독립성 확보시 효과

• 각 View의 독립성을 유지하고 계층별 View에 영향을 주지 않고 변경 가능
• 단계별 Schema에 따라 DDL과 DML가 다름을 제공

데이터베이스 3단계 구조

1. 외부단계 (External Schema) : 사용자 관점 - DB의 개개 user나 application이 접근하는 DB 정의
2. 개념적단계 (Conceptual Schema) : 통합 관점 - 사용자가 처리하는 데이터 유형의 공통적인 사항을 처리하는 통합된 뷰를 스키마 구조로 디자인한 형태 - 모든 사용자 관점을 통합한 조직 전체의 DB - 모든 user와 application이 필요로하는 데이터를 통합한 조직 전체의 DB를 기술 - DB에 저장되는 데이터와 그들간의 관계를 표현하는 스키마
3. 내부적단계 (Internal Schema) : 물리적 저장구조

논리적, 물리직 독립성

사상 (Mapping)

• 논리적 mapping (외부적 <-> 개념적) : 외부적 뷰와 개념적 뷰의 상호 관련성 정의
  • 사용자가 접근하는 뷰의 필드는 다른 타입을 가질 수 있으나, 개념적 뷰의 필드 타입은 변화가 없음
• 물리적 mapping (개념적 <-> 내부적) : 개념적 뷰와 데이터베이스의 상호 관련성 정의
  • 데이터베이스 구조가 바뀔 경우 물리적 mapping이 바뀌어야 함. 개념적 스키마는 안바뀌도록 해야 함

데이터 모델링의 3가지 개념

• 업무가 관여하는 어떤 것 : things (table)
• 어떤 것이 가지는 성격 : attributes (column)
• 업무가 관여하는 어떤 것 간의 관계 : relationships

좋은 데이터 모델의 요소

• 완전성 (completeness) : 업무에 필요한 모든 데이터가 데이터 모델에 정의되어 있어야 함
• 중복배제 (non-redundancy) : 동일한 사실은 반드시 한 번만 기록 (ex. 나이, 생년월일 은 중복)
• 업무규칙 (business rules) : 수많은 업무규칙을 데이터 모델에 표현
• 데이터 재사용 (data reusability) : 데이터 통합성, 독립성을 충분히 고려
• 의사소통 (communication) : 데이터 모델은 업무를 데이터 관점에서 분석하고 설계하여 나오는 최종 산출물. 모든 업무 규칙을 엔티티, 서브타입, 속성, 관계 등의 형태로 최대한 자세하게 표현. 업무관련자들은 이를 업무 규칙과 동일하게 받아들이고 정보시스템 활용
• 통합성 (integration) : 각 부서별 따로 존재했던 데이터 중 중복적인 성격들(마스터 테이블)을 통합 관리

2절 엔터티 (entity)

2.1 엔터티의 특성

• 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(thing)
• 반드시 필요한 정보
• unique하게 식별이 가능
• 반드시 속성(attribute)를 가져야 함
• 업무 프로세스에서 사용되어야 함
• 최소 한 개 이상의 다른 엔터티와의 관계 필수
• 영속적으로 존재하는 인스턴스(instance)의 집합

2.2 엔터티의 분류

• 유무형에 따른 분류
  • 유형엔터티 : 사원, 물품
  • 개념엔터티 : 부서, 보험상품
  • 사건엔터티 : 주문, 청구
• 발생시점에 따른 분류
  • 기본 엔터티 (fundamental entity, key entity) : 독립적 생성 가능, 다른 엔터티의 주어 역할 (ex. 사원 부서, 고객, 상품)
  • 중심 엔터티 (main entity) : 기본 엔터티로 부터 발생하고, 업무의 중심 역할 (ex. 계약, 주문, 매출)
  • 행위 엔터티 (active entity) : 2개 이상의 부모로 부터 발생하고 자주 바뀌거나 데이터량이 증가되는 성격을 가짐 (ex. 주문목록, 사원변경이력)

2.3 인스턴스 (instance)

• 엔터티로부터 생성된 하나의 개체
• entity가 class하면 instance 는 object

3절 속성 (attribute)

3.1 속성의 특징

• 의미상 더 이상 분리되지 않음 : 2개 이상의 값을 가질 경우 분리해야 함
• 엔터티를 설명하고 인스턴스의 구성요소
• 정규화 규칙에 의거해 주식별자에 함수적 종속성을 가져야 함
• 업무상 필요로 해야한다.

3.2 속성의 분류

• 특성에 의한 분류
  • 기본속성 (basic attribute) : 업무로부터 추출한 모든 속성
  • 설계속성 (designed attribute) : 업무를 규칙화하기 위해 새로 만들거나 변형한 속성 (ex. 일련번호)
  • 파생속성 (derived attribute) : 다른 속성에 영향을 받는 속성. 주로 계산 값들. 되도록이면 적게 정의하는게 좋음
• 구성방식에 따른 분류
  • PK (primary key), FK (foreign key), 일반속성 등…

3.3 도메인 (domain)

• 속성이 가질 수 있는 값의 범위

4절 관계 (relationship)

• 인스턴스 사이의 연관성

4.1 관계의 분류

• 존재에 의한 관계 : 부서 (1) : 사원 (M)
• 행위에 의한 관계 : 고객 (1) : 주문 (M)

4.2 관계 차수(degree, cardinality)

• 1 : 1 관계 : 사원 - 병역사항
• 1 : M 관계 : 부서 (1) : 사원 (M)
• M : M 관계 : 주문 (M) : 제품 (M)

5절 식별자 (identifiers)

• entity 내에서 instance의 구분자

5.1 식별자의 특징

• 유일성 : 주식별자에 의해 엔터티 내의 모든 인스턴스가 유일하게 부분
• 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수
• 불변성 : 자주 변하지 않는 값이어야 함
• 존재성 : 반드시 값이 있어야함 (NOT NULL)

5.2 주식별자 도출기준

• 업무에서 자주 이용되는 속성 : PK로 등록 = index 생성
• 명칭, 내역등과 같은 이름은 피해야 함 : 다른 적당한 구분자가 존재하지 않으면 일변번호 같은 것을 새로 생성
• 속성수가 많아지지 않도록 함 : WHERE 조건이 복잡해짐. 새로운 인조식별자를 생성하는게 편함

5.3 외부식별자 (foreign identifier)와의 관계

5.3.1 식별관계, 비식별관계

• 식별자관계 : 부모의 식별자를 자식의 식별자로 사용
  • FK가 NOT NULL이어야 함
  • 종속관계 : 1 : 1 또는 1 : M
  • 상속받은 주식별자속성을 타 엔터티에 이전 필요
• 비식별관계 : 부모없는 자식이 생성될 수 있음
  • 자식의 일반 속성에 생성 됨 : NULL 일 수 있음
  • 부모와 자식의 생명주기(life cycle)을 달리할 경우 유용함
  • 자식 엔터티의 주 식별자로 사용되어도 되지만, 따로 생성하는게 더 유리하다고 판단 될 경우

5.4.2 관계에 대한 주의사항

• 식별관계 / 비식별관계 결정
  • 어떻게 관계를 짓는냐에 따라 속성의 정의 및 SQL 작성시에 달라지므로 SQL 전략에 맞게 결정해야 한다.
• 식별관계로만 설정할 경우 문제점
  • PK 속성의 수가 데이터 모델 흐름에 따라 계속 증가하게 된다. : 자식의 PK 속성수는 부모의 PK 속성수 + n
  • JOIN 할때 적어줘야 할 WHERE절의 조건 수가 늘어난다.
• 비식별관계로만 설정할 경우 문제점
  • 자식 엔터티의 데이터를 조회할때 부모 엔터티에 WHERE 조건을 추가해 주어야 할 경우가 발생한다.

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)