과목Ⅰ. 데이터모델링의 이해
1장 데이터모델링
1절 데이터모델링의 이해
1. 데이터 모델링
① 데이터 모델링: 현실세계를 데이터베이스로 표현하기 위해 추상화하는 것
② 데이터모델링의 특징
1) 추상화 : 공통적 특징을 간략히 표현
2) 단순화 : 누구나 이해할 수 있게
3) 명확화 : 의미가 모호하지 않고 명확
③ 모델링 단계(C-L-P)
1) 개념적 모델링(Conceptual Data Modeling)
: 업무중심적, 포괄적, 추상화 수준이 가장 높음(추상적)
전사적 관점
엔터티-속성 도출, 엔터티-관계 다이어그램 작성
2) 논리적 모델링(Logical Data Modeling)
: 식별자, 관계, 속성 등을 정확히 표현
정규화 수행
각 단계 중 재사용성이 가장 높음
3) 물리적 모델링(Physical Modeling)
: 성능, 보안, 가용성 등을 고려해 DB 구축
(논리적 모델링에서 구현된 외래키가 물리적 모델링에서도 반드시 구현되는 것은 아니다.)
④ 데이터모델링 관점 (보기 예시 내용 자주 출제됨)
관점 | 보기 예시 |
데이터 관점 | - 업무가 어떤 데이터와 관련이 있는가? - 데이터 간의 관계는 무엇인가? |
프로세스 관점 | - 업무에서 실제로 하는 일이 무엇인가? |
데이터와 프로세스 상관관점 | - 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받는가? |
⑤ 데이터모델링의 세가지 중요개념: TAR(Things, Attributes, Relationships)
Things = 엔터티
Attributes = 속성
Relationships = 관계
⑥ 데이터모델링을 위한 ERD(엔터티-관계-다이어그램)
: 엔터티와 엔터티 간의 관계를 정의하는 모델링 방법
- ERD에서 표시되는 것: 관계명, 관계차수, 관계선택사양(필수 or 선택)
- ERD 표기법 두가지 : IE 표기법, Barker 표기법
- 우리가 사용하는 ERD 표기법: IE 표기법
- Barker 표기법 :
- ERD 작성 절차 (시험에 몇 번 나옴)
1) 엔터티 도출
2) 엔터티 배치
3) 엔터티 간 관계 설정
4) 관계명 서술
5) 관계참여도 표현
6) 관계 필수 여부 표현
<ERD 작성 절차>
※ Row Chaining과 Row Migration
구분 | Row Chaining | Row Migration |
정의 | 하나의 Row를 하나의 블록에 저장할 수 없어서 여러 블록에 걸쳐 저장하는 현상 | Update로 인해 늘어나는 공간을 저장할 공간이 없어서 다른 블록으로 Row를 옮기는 현상 |
특성 | 행 조각과 Row Pointer로 블록 내 저장 | 기존 블록에는 Migration되는 데이터의 row headers와 블록 주소값을 갖게 되고, 새로운 블록에는 Migration되는 데이터가 저장됨 |
문제점 | Row의 정보를 검색하기 위해 하나 이상의 데이터 블록을 스캔해야돼서 (= 읽는 I/O량이 많아져서) 성능 저하 |
Migration된 Row를 읽기 전에 기존 블록에서 헤더를 통해 Migration된 row를 읽기 때문에 성능 저하 |
해결책 | - 블록의 크기를 크게 만듦 - 자주 쓰는 칼럼과 그렇지 않은 칼럼을 나누기 |
- 객체를 Migration하고 Truncate - PCTFREE를 크게 설정 - 객체를 Export하고 삭제 후 Import |
2. 데이터 모델링 유의점/고려사항
① 유의점
1) 중복
2) 비유연성: 데이터 정의와 데이터 사용 프로세스가 분리되지 않는 것
3) 비일관성: 데이터 간 상호연관관계에 대한 명확히 정의되지 않는 것
② 고려사항
1) 데이터모델링의 독립성
: 독립성 확보를 위해 '중복'된 데이터 제거 -> using "정규화"
2) 고객 요구사항의 표현
: 고객 요구사항 간결하고 명확히 표현
3) 데이터 품질 확보
: 데이터 표준을 정의하고 준수율 관리
└> ∵ 데이터 표준을 확보해야 데이터 품질 향상 가능
2절 3층 스키마
1. 3층 스키마
: 사용자, 설계자, 개발자가 DB를 보는 관점에 따라 DB를 기술하고 이들 간의 관계를 정의한 ANSI 표준
-> DB의 독립성 확보
데이터의 독립성 확보시 얻는 장점 : 데이터 복잡도 증가, 데이터 중복 제거, 사용자 요구사항 변경 등에 따른
대응력 향상, 관리 및 유지보수 비용 절감
2. 3층 스키마 구조 (E-C-I)
3절 엔터티(Entity)
1. 엔터티
: 업무에서 관리해야 하는 데이터 집합 = 저장이 되기 위한 어떤 것(Thing)
개념, 사건, 장소 등의 명사
(비즈니스 프로세스에서 관리되어야 하는 정보를 말한다.)
ex. 고객, 계좌 등을 엔터티라고 할 수 있다.
2. 엔터티의 특징
1) 업무에서 관리되어야 하는 집합 -- ex) 고객, 계좌
2) '유일한 식별자'가 있어야 함
3) 2개 이상의 인스턴스 => 즉, 고객정보는 2명 이상 있어야 함
4) 반드시 속성을 가짐(두 개 이상) -- ex) 고객 엔터티는 ID, PW, 이름 등의 속성을 가짐
5) 다른 엔터티와 한 개 이상의 관계를 가짐
※ 다른 엔터티와 관계가 적다고 좋은 엔터티는 아님 & DB 내에서 변별 가능한 객체라는 정의 역시 잘못된 정의
3. 엔터티의 종류
1) 유형/무형에 따라
종류 | 설명/예시 |
유형 엔터티 | ex) 사원, 고객, 강사 등 |
개념 엔터티 | - 물리적 형태 X ex) 조직, 보험상품, 거래소 종목 등 |
사건 엔터티 | - 비즈니스 프로세스를 실행하면서 생성되는 엔터티 ex) 주문, 체결, 청구, 미납 등 |
2) 발생시점에 따라
종류 | 설명/예시 |
기본 엔터티 (키 엔터티) | - 독립적으로 생성 - 다른 엔터티로부터 주식별자 상속 X ex) 사원, 부서, 고객, 상품 |
중심 엔터티 (메인 엔터티) | - 기본 엔터티로부터 발생, 행위 엔터티를 생성 ex) 계좌, 주문, 취소 등 |
행위 엔터티 | - 두 개 이상의 부모 엔터티로부터 발생 - 지속적으로 정보가 추가되고 변경되는 엔터티 ex) 주문이력, 사원변경이력 등 |
4절 속성(Attribute)
1. 속성
: 엔터티가 가지는 항목(엔터티를 설명)
인스턴스의 구성 요소
2. 특징
1) 업무에서 관리되는 정보
2) 주식별자에 함수적 종속 → ∴기본키 변경시 속성값도 변경됨
※ 주의점
서술식 속성명은 사용불가
한 개의 속성은 하나의 속성값을 가짐
3. 종류
1) 구성방식에 따라
종류 | 설명 |
단일 속성 | 하나의 의미로 구성 ex) ID, 이름 등 |
복합 속성 | 여러 세부속성들로 구성 ex) 주소 = 시+구+동+번지 |
다중값 속성 | 속성에 여러 개의 값을 가질 수 있는 것(안 중요) 다중값 속성은 엔터티로 분해됨 ex) 상품 리스트 |
2) 특성에 따라
종류 | 설명 |
기본 속성 | 업무로부터 추출한 모든 속성 ex) Id, 이름, 번호 등 |
설계 속성 | 기본 속성 이외에 데이터모델링을 위해 만든 속성 유일한 값을 부여 ex) 상품코드, 지점코드, 일련번호 등 |
파생 속성 | 다른 속성으로부터 파생 ex) 합계, 평균 등 |
※ 도메인
: 속성이 가질 수 있는 값의 범위
ex) 성별 속성의 도메인 = 남자, 여자
도메인의 특징
1) 각 속성이 가질 수 있도록 허용된 값의 집합
2) 속성명과 도메인명이 반드시 동일하지는 않음
3) 릴레이션에서 모든 속성들의 도메인은 원자적 (원자적 도메인: 도메인의 원소가 나누어질 수 없는 단일체)
4) 데이터 타입, 크기 / NOT NULL / CHECK (뭔 말인지는 모르겠는데 도메인의 특징 답이 이거였음)
5절 관계(Relationship)
1. 관계
: 엔터티 간의 관련성
2. 관계의 종류
1) 존재관계: 엔터티 간의 상태를 의미 -- ex) 고객이 은행에 회원가입시 고객 엔터티 할당
2) 행위관계: 엔터티 간에 어떤 행위가 있는 것 ex) 계좌 개설, 주문 발주
3. 관계차수(Cardinality, 카디널리티)
: 두 개의 엔터티 간 관계에 참여하는 수
- 관계차수의 종류
※ 필수적인 것은 수직선 하나, 선택적인 것은 원형으로 표시
※ 관계형 DB에서 M:N 관계의 조인은 카테시안 곱이 발생함 -> ∴ M:N을 1:N 혹은 N:1로 해소해야함
4. 식별관계, 비식별관계
1) 식별관계 (실선)
부모 엔터티의 주식별자를 자식 엔터티의 주식별자가 상속
=
강한 개체는 다른 엔터티에 의존하지 않고, 독립적으로 존재
| ex) 고객, 계좌 엔터티 중 고객은 강한 개체(Strong entity)
└> 강한 개체가 다른 엔터티와 관계를 가질 때, 다른 엔터티에게 기본키를 공유 = 식별관계
ex) 고객 엔터티의 기본키인 '회원ID'를 계좌 엔터티의 기본키로 공유
└> 강한 개체 └> 약한 개체
2) 비식별관계 (점선)
부모 엔터티의 주식별자가 자식 엔터티의 일반 속성으로 상속
=
강한 개체의 기본키를 다른 엔터티의 기본키가 아닌 '일부 칼럼'으로 관계를 가짐
※ 식별관계로만 선정할 경우 문제
: (SQL구문, 조인) 복잡성 높아짐 -> 비식별관계 고려
※ 비식별관계로만 선정할 경우 문제
: 오히려 다른 조인이 걸리게 되어 그에 따라 복잡성 증가, 성능은 저하 발생 가능
∴ 정확하게 식별관계와 비식별관계를 이해하고 업무적 특징, 조인, 기본키 구성 등을 고려해서 식별/비식별 관계를
설정해야함
6절 식별자(Entity Identifier)
1. 식별자 : 엔터티를 대표하는 유일성을 만족하는 속성
2. 주식별자의 특징
- 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함
- 대표성 : 엔터티를 대표함
- 유일성 : 주식별자에 의해 엔터티 내의 모든 인스턴스들이 유일하게 구분됨
- 불변성 : 주식별자의 값은 한 번 지정되면 불변
- 존재성 : Null일 수 없음 (Not Null)
※ 주식별자가 지정되면 반드시 값이 들어와야함
3. 키의 종류
키 | 설명 |
기본키 (Primary Key) | 후보키 중 엔터티를 대표하는 키 (대표성 만족) |
후보키 (Candidate Key) | 유일성과 최소성을 만족하는 키 |
슈퍼키 (Super Key) | 유일성만 만족하는 키 |
대체키 (Alternate Key) | 기본키로 선정되지 않은 후보키 |
외래키 (Foreign Key) | - 참조무결성을 확인하기 위해 사용되는 키 - 하나 혹은 다수의 다른 테이블의 기본키 필드를 가리키는 것 |
4. 식별자의 종류
1) 대표성 여부에 따라
식별자 | 설명 |
주식별자 | - 유일성, 최소성, 대표성을 만족하는 키 - 다른 엔터티와 참조관계로 연결 가능 |
보조식별자 | - 유일성, 최소성 O, 대표성 X - 대표성이 없어 참조관계로 연결 불가 |
2) 생성 여부에 따라
식별자 | 설명 |
내부 식별자 | 엔터티 내부에서 스스로 생성되는 식별자 ex) 부서코드, 주문번호 등 |
외부 식별자 | 다른 엔터티와의 관계로 만들어지는 식별자 ex) 계좌 엔터티의 회원ID |
3) 속성의 수에 따라
식별자 | 설명 |
단일 식별자 | 하나의 속성으로 구성 |
복합 식별자 | 두 개 이상의 속성으로 구성 |
4) 대체 여부에 따라
식별자 | 설명 |
본질식별자 | 업무로부터 만들어짐 |
인조식별자 | - 인위적으로 만들어짐 - 후보키 중 주식별자로 선정할 것이 없거나 주식별자가 너무 많은 칼럼으로 되어있을 경우 사용 (순서번호를 사용해서 식별자 만드는 것) |
'언어 > SQL' 카테고리의 다른 글
[기본] SQLD 2과목 1장 공부 정리 3 (테이블명 변경, 칼럼 추가/삭제/변경, 테이블 삭제, 뷰 생성/조회/삭제) (0) | 2020.09.02 |
---|---|
[기본] SQLD 2과목 1장 공부 정리 2 (DDL문에서 create table, constraint 설정, on delete cascade 옵션) (0) | 2020.09.01 |
[기초] 사용자 추가, MySQL DB 생성, 사용자 권한 부여 (0) | 2020.09.01 |
[기본] SQLD 2과목 1장 공부 정리 1 (관계형 DB의 정의, SQL문의 종류, 트랜잭션의 특성) (0) | 2020.09.01 |
[기본] SQLD 1과목 2장 공부 정리 (정규화, 반정규화, 분산 DB) (0) | 2020.09.01 |