1과목 데이터 모델링의 이해
- 10문제
- 외우기 보다는 반복적으로 읽어서 전반적인 내용을 이해하는 수준에서 마무리 하는것을 목표로 잡아야 겠습니다.
제 1장 데이터 모델링의 이해
1절 데이터 모델의 이해
모델링의 특징
- 추상화 : 일정한 형식에 맞추어 표현
- 단순화 : 약속된 규약에 의해 제한
- 명확화 : 애매모호함을 제거 정확하게 기술
모델링의 3가지 관점
- 데이터 관점 (what) : 업무가 어떤 데이터와 관려이 있는지, 데이터간의 관계가 무엇인지
- 프로세스 관점 (how) : 업무가 실제하고 있는 일이 무엇인지, 무엇을 해야 하는지
- 데이터와 프로세스의 상관관점 (interaction) : 업무가 처리됨에 따라 데이터는 어떻게 영향을 받고 있는지
데이터 모델링이랑...
- 정보시스템을 구축하기 위한 데이터관점의 업무 분석 기법
- 현실세계의 데이터(what)에 대해 약속된 표기법에 의해 표현하는 과정
- 데이터베이스를 구축하기 위한 분석/설계의 과정
데이터 모델의 중요성
- 파급효과(leverage) : 데이터 모델이 잘못되어서 나중에 변경될때에는 전체 시스템에 큰 변경 사항이 발생함
- 복잡한 정보 요구사항의 간결한 표현(conciseness) : 요구사항을 정확하고 간결하게 표현. 요구사항 파악시 데이터 모델을 리뷰하는 것이 더 빠름.
- 데이터 품질(data quality) : 기간이 오래되고 쌓인 데이터를 활용하려면 품질이 중요. (정확성, 중복데이터 등...). 품질이 안좋으면 활용하지 못한 쓰레기가 될수 있음
데이터 모델링의 유의점
- 중복(duplication) : 여러 곳에 같은 정보 저장하지 않도록
- 비유연성(inflexibility) : 데이터 정의와 사용 프로세스를 분리. 각각의 작은 변화가 서로에게 영향을 미치지 않도록
- 비일관성(inconsistency) : 서로 영향을 미치는 데이터간 상호 연관 관계에 대한 명확한 정의가 필요 (ex. 납부이력과 신용상태)
데이터 모델링의 3단계 진행 (추상화 수준에 따라)
- 개념적 데이터 모델(conceptual)
- 추상화 수준이 높고 업무중신적이고 포괄적인 수준의 모델링 진행. 전사적 데이터 모델링, EA수립시 많이 이용
- 엔티티 - 관계 다이어그램 생성
- 전사적 데이터 모델링 (enterprise)
- 중요한 2가지 기능
- 사용자와 시스템 개발자가 데이터 요구 사항을 발견하는 것을 지원
- 현 시스템이 어떻게 변형되어야 하는지를 이해하는데 유용
- 논리적 데이터 모델 (logical)
- 시스템으로 구축하고자 하는 업무에 대한 Key, 속성, 관계 등을 정확하게 표현, 재사용성이 높음
- 식별자 확정, 정규화, M:M 관계 해소, 참조 무결성 규칙 정의 등
- 데이터베이스 설계 프로세스의 input으로 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 기법 또는 과정
- 물리적 데이터 모델 (physical
- 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 무리적인 성격을 고려하여 설계
- 물리적 스키마 : 데이터가 물리적으로 컴퓨터에 어떻게 저장될 것인가에 대한 정의
- 테이블, 칼럼 등의 저장구조와 저장 장치, 접근 방법 등
데이터 독립성의 필요성 <-> 데이터 종속성
- 유지보수 비용증가
- 데이터 중복성 증가
- 데이터복잡도 증가
- 요구사항 대응 저하
데이터 독립성 확보시 효과
- 각 View의 독립성을 유지하고 계층별 View에 영향을 주지 않고 변경 가능
- 단계별 Schema에 따라 DDL과 DML가 다름을 제공
데이터베이스 3단계 구조
- 외부단계 (External Schema) : 사용자 관점
- DB의 개개 user나 application이 접근하는 DB 정의
- 개념적단계 (Conceptual Schema) : 통합 관점
- 사용자가 처리하는 데이터 유형의 공통적인 사항을 처리하는 통합된 뷰를 스키마 구조로 디자인한 형태
- 모든 사용자 관점을 통합한 조직 전체의 DB
- 모든 user와 application이 필요로하는 데이터를 통합한 조직 전체의 DB를 기술
- DB에 저장되는 데이터와 그들간의 관계를 표현하는 스키마
- 내부적단계 (Internal Schema) : 물리적 저장구조
논리적, 물리직 독립성
| 독립성 | 내용 | 특징 |
|---|---|---|
| 논리적 독립성 | - 개념 스키마가 변경되어도 외부 스키마에는 영향 없음 - 논리적 구조가 변경되어도 Application에는 영향 없음 | - 사용자 특성에 맞는 변경가능 - 통합 구조 변경가능 |
| 물리적 독립성 | - 내부스키마가 변경되어도 외부/새념 스키마에 영향 없음 - 저장장치의 구조변경은 Application과 개념스키마에 영향 없음 | - 물리구조, 개념구조를 서로 영향없이 변경가능 |
사상 (Mapping)
- 논리적 mapping (외부적 <-> 개념적) : 외부적 뷰와 개념적 뷰의 상호 관련성 정의
- 사용자가 접근하는 뷰의 필드는 다른 타입을 가질 수 있으나, 개념적 뷰의 필드 타입은 변화가 없음
- 물리적 mapping (개념적 <-> 내부적) : 개념적 뷰와 데이터베이스의 상호 관련성 정의
- 데이터베이수 구조가 바뀔 경우 물리적 mapping이 바뀌어야 함. 개념적 스키마는 안바뀌도록 해야 함
데이터 모델링의 3가지 개념
- 업무가 관여하는 어떤 것 : things
- 어떤 것이 가지는 성격 : attributes
- 업무가 관여하는 어떤 것 간의 관계 : relationships
좋은 데이터 모델의 요소
- 완전성 (completeness) : 업무에 필요한 모든 데이터가 데이터 모델에 정의되어 있어야 함
- 중복배제 (non-redundancy) : 동일한 사실은 반드시 한 번만 기록 (ex. 나이, 생년월일 은 중복)
- 업무규칙 (business rules) : 수많은 업무규칙을 데이터 모델에 표현
- 데이터 재사용 (data resuability) : 데이터 통합성, 독립성을 충분히 고려
- 의사소통 (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 조건을 추가해 주어야 할 경우가 발생한다.
댓글 없음:
댓글 쓰기