2021. 10. 20. 21:09ㆍCertificate`/SQLD
1. 데이터 모델의 이해
모델링
정의
- 복합한 현실세계 (사물, 사물, 개념 등)를 일정한 표기법에 따라 표현하는 일
- 복잡한 현실세계를 단순화해 표현하는 것
특징
1. 추상화 : 다양한 현상을 일정한 양식인 표기법에 따라 표현
2. 단순화 : 복잡한 현실세계를 약속된 표기법에 의해 쉽게 이해할 수 있도록 하는 개념
3. 명확화 : 누구나 이해하기 쉽게 하기 위해 애매모호함을 제거하고 정확하게 현상을 기술
관점
1. 데이터 관점 (What, Data) : 업무가 어떤 데이터와 관련이 있는지 또는 데이터 간의 관계는 무엇인지
2. 프로세스 관점 (How, Process) : 실제하고 있는 업무는 무엇인지 또는 무엇을 해야 하는지
3. 상관 관점 (D vs P) : 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지
데이터 모델링
정의
- 현실세계의 데이터(What)에 대해 약속된 표기법에 의해 표현하는 과정
- DB를 구축하기 위한 분석, 설계의 과정
요소
- Things : 업무가 관여하는 어떤 것 - 엔터티
- Attributes : 어떤 것이 가지는 성격 - 속성
- Relationships : 업무가 관여하는 어떤 것 간의 관계 - 관계
중요성
- 파급효과
- 복잡한 정보 요구사항의 간결한 표현
- 데이터 품질
유의성
- 중복 : DB가 여러 장소에 같은 정보를 저장하지 않게 함
- 비유연성 : 데이터 정의를 데이터 사용 프로세스와 분리
- 비일관성 : 데이터와 데이터 간 상호 연관 관계에 대한 명확한 정의가 필요
좋은 데이터 모델의 요소 (완 중 업 재 의 통)
- 완전성 / 중복 배제 / 업무 규칙 / 데이터 재사용 / 의사소통 / 통합성
데이터 모델링의 3단계 (ANSI/SPARC)
1. 개념적 데이터 모델링 : 추상화 수준이 높고 업무 중심적이고 포괄적인 수준의 모델링 (추상적)
2. 논리적 데이터 모델링 : 업무의 구체적인 모습과 흐름에 따른 구체화한 업무 중심의 데이터 모델 생성
3. 물리적 데이터 모델링 : 실제 DB에 이식할 수 있도록 물리적 성격을 고려 (구체적)
프로젝트 생명주기에 따른 데이터 모델링
| 데이터 모델링 | 개념단계 | 분석단계 | 설계단계 |
| 프로젝트 생명주기 | 개념적 모델링 | 논리적 모델링 | 물리적 모델링 |
| 현실 프로젝트 | 개념적 모델링 + 논리적 모델링 | 물리적 모델링 |
데이터 독립성
정의
- 하위 스키마를 변경해도 상위 스키마가 영향을 받지 않는 특성
- 개별 형식이 가지는 고유의 기능을 유지시키고 그 기능을 극대화하기 위함
목적
- 데이터 복잡도 낮추기
- 데이터 중복성 낮추기
- 유지보수 비용 절감하기
- 요구사항 대응 저하
효과
- 각 뷰의 독립성을 유지하고 계층별 뷰에 영향을 주지 않고 변경 가능
- 단계별 스키마에 따라 DDL과 DML이 다름을 제공
| 항목 | 내용 | 비고 |
| 외부 스키마 | - 여러 개의 사용자 관점으로 구성 | - 사용자 관점 - 접근하는 특성에 따른 스키마 구성 |
| 개념 스키마 | - 조직 전체의 관점에서 DB를 기술 - DB에 저장되는 데이터와 그들 간의 관계를 표현 |
- 통합(조직) 관점 |
| 내부 스키마 | - DB가 물리적으로 저장된 형식 - 물리적 장치에서 데이터가 실제적으로 저장되는 방법을 표현 |
- 물리적 저장구조 관점 |
| 독립성 | 내용 | 특징 |
| 논리적 독립성 | - 개념 스키마가 변경되어도 의부 스키마에는 영향 X - 논리적 구조가 변경되어도 응용 프로그램에 영향 X |
- 사용자 특성에 맞는 변경 가능 - 통합 구조 변경 가능 |
| 물리적 독립성 | - 내부 스키마가 변경되어도 외부/개념 스키마에는 영향 X - 물리적 구조(저장장치)가 변경되어도 응용 프로그램/개념 스키마에 영향 X |
- 물리적 구조 영향 없이 개념구조 변경 가능 - 개념구조 영향 없이 물리적 구조 변경 가능 |
사상
- 상호 독립적인 개념들을 연결시켜주는 다리
| 사상 | 내용 |
| 외부/개념적 사상(논리적 사상) | - 외부적 뷰와 개념적 뷰의 상호 관련성을 정의 |
| 개념/내부적 사상(물리적 사상) | - 개념적 뷰와 저장된 DB의 상호 관련성을 정의 |
2. 엔터티 (Entity)
개념
- 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(Things)
- 개체들의 특성을 설명할 수 있는 속성(Attribute)을 갖는다
- 앤터티 = 인스턴스의 집합 / 인스턴스 = 엔터티의 하나의 값
특징
- 반드시 필요하고 관리하고자 하는 정보
- 유일한 식별자에 의해 식별 가능
- 2개 이상의 인스턴스의 집합
- 반드시 속성이 있어야 한다
- 다른 엔터티와 최소 1개 이상의 관계가 있어야 한다
- 업무 프로세스에 의해 이용돼야 한다
분류
- By 유무형
- 유형 엔터티 - 물리적 형태가 존재 ex) 사원, 물품
- 개념 엔터티 - 물리적 존재 X / 관리해야 할 정보 ex) 조직, 장소, 보험상품
- 사건 엔터티 - 업무(행위)의 수행에 의한 ex) 주문, 창구
- By 발생 시점
- 기본 엔터티 - 독립적으로 생성 ex) 사원, 부서
- 중심 엔터티 - 기본 엔터티로부터 발생 ex) 접수, 계약
- 행위 엔터티 - 2개 이상의 부모 엔터티로부터 발생 ex) 주문내역, 계약 진행
3. 속성 (Attribute)
정의
- 업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위
- 엔터티를 설명하고 인스턴스의 구성요소가 된다
엔터티 / 인스턴스 / 속성 / 속성 값의 관계
- 1개의 엔터티는 2개 이상의 인스턴스의 집합
- 1개의 엔터티는 2개 이상의 속성을 갖는다
- 1개의 속성은 1개의 속성 값을 갖는다
- 인스턴스 = 행(가로 집합) / 속성 = 열(세로 집합)
분류
- By 속성의 특성
- 기본 속성 - 업무로부터 추출한 모든 속성 ex) 제품 이름, 제조년월, 제조원가
- 설계 속성 - 업무를 규칙화하기 위해 새로 만들거나 변형한 속성 ex) 약품 용기 코드
- 파생 속성 - 다른 속성에 영향을 받아 발생 ex) 계산 값
- By 엔터티 구성 방식
- PK속성 - 엔터티를 식별
- FK속성 - 다른 엔터티와의 관계에서 포함
- 일반 속성 - 엔터티에 포함되어 있고 PK/FK에 포함되지 않은 속성
도메인
- 각 속성이 가질 수 있는 값의 범위
- 속성에 대한 데이터 타입과 크기/제약사항을 지정
4. 관계 (Relationship)
정의
- 인스턴스 사이의 논리적인 연관성으로서 존재 or 행위로써 서로에게 연관성이 부여된 상태
패어링
- 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것
- 패어링의 집합 = 관계
구분
- ERD
- 존재적 관계, 행위적 관계 간에 구분하지 않고 표현
- 클래스 다이어그램
- 존재적 관계, 행위적 관계를 구분하여 연관관계, 의존관계로 표현
표기법
- 관계명 : 관계의 이름
- 관계 차수 (Cardinality) : 1:1 / 1:N / M:N
- 관계 선택사양 : 필수 관계 / 선택 관계
체크사항
- 2개의 엔터티 사이에 관심 있는 연관 규칙이 존재하는가?
- 2개의 엔터티 사이에 정보의 조합이 발생하는가?
- 관계 연결에 대한 규칙이 있는가?
- 관계 연결을 가능하게 하는 동사(Verb)가 있는가?
5. 식별자 (Identifier)
정의
- 엔터티 내에서 인스턴스들을 구분할 수 있는 구분자
특징 (U - M - I -E)
| 특징 | 내용 |
| 유일성 (Uniqueness) | 주식별자에 의해 엔터티 내에 모든 인스턴스들을 유일하게 구분 |
| 최소성 (Minimal) | 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함 |
| 불변성 (Immutability) | 주식별자가 한 번 특정 엔터티에 지정되면 그 식별자의 값은 불변 |
| 존재성 (Existence) | 주식별자가 지정되면 반드시 데이터 값이 존재 (Null X) |
분류
- By 대표성 여부
- 주 식별자
- 보조 식별자
- By 스스로 생성
- 내부 식별자
- 외부 식별자
- By 속성 수
- 단일 식별자
- 복합 식별자
- By 대체 여부
- 본질 식별자
- 인조 식별자 : 순서 번호(Sequence Number)를 사용해서 식별자를 만드는 것 ex) 주문번호
주식별자 도출 기준
- 업무에서 자주 이용되는 속성
- '이름'으로 기술되는 것은 피함
- 속성의 수가 많아지지 않도록 함
식별자 / 비식별자 관계
- FK를 보유 -> 자식 엔터티 / FK를 제공 -> 부모 엔터티
- 식별자 관계 : FK를 기본키로 적용
- 비식별자 관계 : FK를 일반 속성으로 적용
문제점 (Only 식별자 / Only 비식별자)
- Only 식별자 관계
- 주식별자 속성(PK)의 지속적 증가 -> 개발 복잡성 + 오류 유발
- Only 비식별자 관계
- SQL 구문에 많은 조인 (쓸데없이 부모 엔터티 조회) -> 복잡성 증가 + 성능 저하
