본문 바로가기

언어/SQL

[기본] SQLD 1과목 1장 공부 정리 (데이터모델링, 3층스키마, 엔터티, 속성, 관계, 식별자)

과목Ⅰ. 데이터모델링의 이해

 

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 표기법 :

출처: http://www.dbguide.net/db.db?cmd=view&boardUid=148189&boardConfigUid=9&categoryUid=216&boardIdx=134&boardStep=1

 

- 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) 대체 여부에 따라

식별자 설명
본질식별자 업무로부터 만들어짐
인조식별자 - 인위적으로 만들어짐
- 후보키 중 주식별자로 선정할 것이 없거나 주식별자가 너무 많은 칼럼으로 되어있을 경우 사용
(순서번호를 사용해서 식별자 만드는 것)