본문 바로가기
SQLD 자격증

SQLD 개발자 자격증 요약 1. 데이터 모델링의 이해

by atheglance 2022. 9. 5.

SQLD 개발자 자격증 요약 정리

 

 

SQLD 개발자 자격증 시험 전 본인이 보기 위해

중요하다고 생각한 부분만 정리한 요약본으로,

누락 내용이 있을 수 있다.

 

 

 

모델링의 특징
① 추상화: 현실 세계를 일정한 형식으로 표현
② 단순화: 정해진 표기법으로 단순하고 쉽게 표현
③ 명확화: 불분명 제거, 명확하게 해석할 수 있도록 기술

모델링의 세 가지 관점
① 데이터 관점(What, Data)

어떤 데이터들이 업무와 얽혀 있고,

어떤 관계가 있는지


② 프로세스 관점(How, Process)

실제 처리하고 있는 일은 무엇이고,

앞으로 처리해야 하는 일은 무엇인지


③ 데이터와 프로세스의 상관 관점(Interaction)

프로세스에 따라 데이터는 어떤 영향?

모델링의 세 가지 단계
① 개념적 데이터 모델링

업무 중심적, 포괄적인 수준


② 논리적 데이터 모델링

재사용성이 가장 높은 모델링,

key, 속성, 관계 등을 모두 표현하는 단계


③ 물리적 데이터 모델링

실제 데이터베이스로 구현할 수 있도록

성능, 가용성 등 물리적 성격 고려

3단계 스키마 구조
① 외부 스키마

사용자의 관점,

View 단계로 여러 개의 사용자 관점으로 구성


② 개념 스키마

통합된 관점,

모든 사용자 관점을 통합한

조직 전체 관점의 통합적인 표현


③ 내부 스키마

물리적인 관점, 물리적인 저장 구조,

실질적 데이터의 저장 구조나 칼럼 정의, 인덱스 등

3단계 스키마 구조가 보장하는 독립성
① 논리적 독립성

개념적 스키마가 변경되어도

외부 스키마는 영향받지 않는다.


② 물리적 독립성

내부 스키마가 변경되어도

외부/개념 스키마는 영향받지 않는다.

ERD(Entity Relationship Diagram)
시스템에 어떤 엔터티들이 존재하며

그들 간에 어떤 관계가 있는지를

나타내는 다이어그램
ID: 점선 실선
IE/Crow’s Foot: 까마귀발

ERD 작성 순서
① 엔터티를 도출하고 그린다
② 엔터티를 배치한다
③ 엔터티 간의 관계를 설정한다
④ 관계명을 기재한다
⑤ 관계의 참여도를 기재한다
⑥ 관계의 필수/선택 여부를 기재한다

엔터티

식별이 가능한 객체

업무에서 쓰이는 데이터를 용도별로 분류한 그룹


엔터티 table / 인스턴스 Row / 속성 Column


엔터티의 특징
① 업무에서 쓰이는 정보여야 함
② 유니크함을 보장할 수 있는 식별자가 있어야 함
③ 2개 이상의 인스턴스를 가지고 있어야 함
④ 반드시 속성을 가지고 있어야 함
⑤ 다른 엔터티와 1개 이상의 관계를 가지고 있어야 함

엔터티 이름을 정할 때 주의할 점
① 업무에서 실제 쓰이는 용어 사용
② 한글은 약어 사용 X, 영문은 대문자로 표기
③ 단수 명사로 표현, 띄어쓰기 X
④ 다른 엔터티와 의미상으로 중복될 수 있음

(주문, 결제 엔터티는 중복될 수 있음)
⑤ 해당 엔터티가 가진 데이터가 무엇인지 명확하게 표현

엔터티의 분류
① 유형 vs 무형
- 유형 엔터티

물리적인 형태 존재, 안정적, 지속적 (상품, 회원)


- 개념 엔터티

물리적인 형태 없음. 개념적 (부서, 학과)


- 사건 엔터티

행위를 함으로써 발생, 빈번함,

통계 자료로 이용 가능 (주문, 이벤트 응모)

② 발생 시점
- 기본 엔터티

독립적으로 생성,

자식 엔터티를 가질 수 있음 (상품, 회원)


- 중심 엔터티

기본 엔터티로부터 파생,

행위 엔터티 생성 (주문)


- 행위 엔터티

2개 이상의 엔터티로부터 파생

(주문명세, 이벤트 응모 이력)

속성

더 이상 쪼개지지 않는 레벨,

프로세스에 필요한 항목


속성값

각각의 속성은 속성값을 가짐,

엔터티에 속한 하나의 인스턴스를

구체적으로 나타내주는 데이터
하나의 속성은 한 개의 속성값만 가질 수 있다.
만약 하나의 속성이

여러 개의 속성값을 갖는 경우

별도의 엔터티로 분리하는 것이 바람직하다.

속성 분류
① 특성에 따른 분류
- 기본속성

바로 정의가 가능한 속성


- 설계속성

업무에 존재하지는 않지만,

설계하다 보니 필요하다고 판단되어 도출한 속성


- 파생 속성

다른 속성의 속성값을 계산하거나,

특정한 규칙으로 변형해 생성한 속성

② 구성 방식에 따른 분류
- PK 속성

엔터티의 인스턴스들을 식별할 수 있는 속성


- F K 속성

다른 엔터티의 속성에서 가져온 속성


- 일반속성

PK, FK를 제외한 나머지 속성

도메인: 속성이 가질 수 있는 속성값의 범위

관계
① 존재 관계: 엄마와 아기처럼 존재 자체로 연관성이 있는 관계 (직원과 부서, 학생과 학과)
② 행위 관계: 특정한 행위를 함으로써 연관성이 생기는 관계 (회원과 주문, 학생과 출석부)

관계 표기법
① 관계명
② 관계차 수: 1:1, 1:M, N:M
③ 관계 선택사양: 필수적 관계, 선택적 관계

식별자

모든 엔터티는 인스턴스를 가지고 있고,

인스턴스는 속성으로 자신의 특성을 나타낸다
식별자는 이런 속성 중 각각의 인스턴스를

구분할 수 있게 만들어주는

대표 격인 속성을 의미한다

주 식별자(기존키, PK)
① 유일성: 각 인스턴스에 유니크함을 부여해 식별이 가능
② 최소성: 유일성을 보장하는 최소 개수의 속성
③ 불변성: 속성값이 되도록 변하지 않아야 함
④ 존재성: 속성값이 NULL일 수 없음

식별자 분류 방식
① 대표성 여부

주 식별자, 보조 식별자


② 스스로 생성되었는지 여부

내부식별자, 외부 식별자


③ 단일 속성의 여부

단일식별자, 복합식별자


④ 대체 여부

원조 식별자,

대리 식별자(주 식별자 속성이 두 개 이상인 경우,

그 속성들을 하나로 묶어서 사용

식별자 관계

부모 엔터티의 식별자가

자식 엔터티의 주 식별자가 되는 관계.
주 식별자는 반드시 존재해야 하므로(존재성)

부모 엔터티가 있어야 생성할 수 있으며,

1:1이거나 1:M

비 식별자 관계

부모 엔터티의 식별자가

자식 엔터티의 일반 속성이 되는 관계
일반 속성의 속성값은 NULL이 될 수 있으므로

부모 엔터티가 없는 자식 엔터티 생성이 가능하고,
마찬가지의 이유로

자식 엔터티가 존재하는 상태에서

부모 엔터티가 삭제될 수도 있다.

댓글