[SQLD (1-1)] 데이터 모델링의 이해

개요

이번 포스팅은 데이터 자격 검정인 SQL 개발자(SQLD) 시험을 기반으로 공부했던 자료이다.
시험을 위한 공부이긴 했지만, 정리했던 자료가 향후에 도움이 많이 될 것 같다.

1. 데이터 모델의 이해

1.1 모델링의 이해

• 모델링의 정의
  • 다양한 현상에 대해서 일정한 표기법에 의해 표현해 놓은 모형
  • 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
  • 데이터베이스를 구축하기 위한 분석/설계의 과정
• 모델링의 특징 (추단명)
  • 추상화 : 다양한 현상을 일정한 양식인 표기법에 의해 표현
  • 단순화 : 제한된 표기법이나 언어로 표현
  • 명확화 : 애매모호함을 제거하고 정확(正確)하게 현상을 기술
• 모델링의 3가지 관점
  • 데이터 관점 : 업무가 어떤 데이터와 관련이 있는지 또는 데이터간의 관계는 무엇인지 에 대해서 모델링하는 방법 (What, Data)
  • 프로세스관점 : 업무가 실제하고 있는 일은 무엇인지 또는 무엇을 해야 하는지를 모델링하는 방법 (How, Process)
  • 데이터와 프로세스의 상관관점 : 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지 모델링하는 방법 (Interaction)

1.2 데이터 모델의 기본 개념의 이해

데이터 모델링의 유의점 (다음을 하지 말아야함)

• 중복(Duplication) : 여러 장소에 같은 정보를 제공하지 않도록 해야함
• 비유연성(Inflexibility) : 데이터의 정의를 사용 프로세스와 분리함으로써 데이터 모델이 수시로 변경되지 않도록 유의
• 비일관성(Incosistency) : 다른 테이터의 모순된다는 고려없이 데이터를 수정하지 않고 모델링 시 데이터 사이 상호연관관계에 대해 명확하게 정의하여 일관성을 높임

데이터 모델링의 3단계 (추상적 → 구체적 순)

• 개념적 데이터 모델링
  • 추상화 수준이 높음
  • 전사적, 업무중심적, 포괄적
  • EA수립시 많이 활용
  • 엔터티들간의 관계 발견 및 엔터티-관계 다이어그램 생성
• 논리적 데이터 모델링
  • 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현, 재사용성이 높음
  • 정규화 수행
• 물리적 데이터 모델링
  • 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계
  • 물리적 스키마(테이블, 칼럼)

데이터 독립성

• 특정 스키마를 변경해도 상위 수준의 스키마 정의에 영향을 주지 않는 성질
• 사용자 요구사항 변경에 따른 대응력이 향상되고 데이터 중복을 제거할 수 있다
• 데이터의 복잡도를 낮추며 관리 및 유지보수 비용이 절감된다

데이터 베이스 3단계 구조

• 외부스키마 External schema
  • 여러 개의 사용자 관점으로 구성(개인적 DB 스키마)
  • 개별 사용자나 응용 프로그래머가 접근하는 DB를 정의
• 개념스키마 Conceptual schema
  • 개념단계 하나의 개념적 스키마로 구성
  • 모든 사용자 관점을 통합한 조직 전체의 DB 기술
• 내부스키마 Internal schema
  • 내부 관계, 내부 스키마로 구성
  • DB의 물리적 저장 구조
• 논리적 데이터독립성
  • 개념 스키마가 변경되어도, 외부 스키마에 영향 X
• 물리적 데이터독립성
  • 내부 스키마가 변경되어도, 외부/개념 스키마에 영향 X

사상(Mapping) : 상호 독립적인 개념을 연결시켜주는 다리

• 논리적 사상 : 외부 스키마 - 개념 스키마
• 물리적 사상 : 개념 스키마 - 내부 스키마

데이터 모델링의 3요소

• 어떤 것 (Things)
• 어떤 것이 가지는 성격(Attributes)
• 업무가 관여하는 어떤 것 간의 관계 (Relationships) ERD
• 피터첸(Peter Chen)이 Entity-relationship model(E-R Model)
• 엔터티(사각형), 관계(마름모), 속성(타원형)
• 여러가지 표기법이 있는데 여기서는 Baker, IE로 설명
• ERD 작업 순서

• (2) 엔터티 배치 : 중요도에 따라 왼쪽 → 오른쪽, 위쪽 → 아래쪽 순서로 배치

출처 : https://mjn5027.tistory.com/43

좋은 데이터 모델의 요소

• 완전성 : 업무에 필요한 모든데이터가 모델에 정의되어 있어야 함
• 중복배제 : 하나의 DB내에 동일한 사실은 한번만.
• 업무규칙 : 많은 규칙을 사용자가 공유하도록 제공
• 데이터 재사용 : 데이터를 독립적으로 설계하여 재사용성 높이자
• 의사소통 : 과정에서 도출되는 업무규칙들을 엔터티, 서브타입, 속성, 관계 등의 형태로 최대한 자세히 표현해야함
• 통합성 : 동일한 데이터는 조직의 전체에서 한번 만 정의되고 이를 여러 다른 영역에서 참조, 활용하기

2. 엔터티 (Entity)

엔터티

• 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(Thing)
• 인스턴스의 집합. ex) 과목(엔터티)은 수학, 영어, 국어라는 인스턴스들의 집합임

엔터티의 특징

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다. (예. 환자, 토익의 응시횟수, …)
• 유일한 식별자에 의해 식별이 가능해야 한다.
• 영속적으로 존재하는 인스턴스의 집합이어야 한다.(‘한 개’가 아니라 ‘두 개 이상’)
• 엔터티는 업무 프로세스에 의해 이용되어야 한다.
• 엔터티는 반드시 속성이 있어야 한다.
• 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다. (그러나 통계성, 공통코드 등의 관계는 생략할 수 있음)

엔터티의 분류

• 유무형에 따른 분류
  • 유형 엔터티 : 물리적 형태로 지속적으로 활용
    • ex) 사원, 물품, 강사
  • 개념 엔터티 : 개념적 정보
    • ex) 조직, 보험 상품
  • 사건 엔터티 : 업무 수행시 발생하여, 발생량이 많음
    • ex) 주문, 청구, 미납
• 발생시점에 따른 분류
  • 기본/키 엔터티 :그 업무에 원래 존재하던 정보, 타 엔터티의 부모역할, 고유한 식별자 가짐
    • ex) 사원, 부서, 고객, 상품
  • 중심 엔터티 : 기본 엔터티로부터 발생, 다른 엔터티와의 관계로 많은 행위 엔터티 생성
    • ex) 계약, 사고, 예금원장, 청구, 주문, 매출 등
  • 행위 엔터티 : 2개 이상의 부모 엔터티로부터 발생, 내용이 자주 바뀌고 데이터량 증가
    • ex) 주문 목록, 사원 변경 이력

엔터티의 명명

• 현업에서 사용하는 용어 사용
• 약어 사용 금지
• 단수명사 사용
• 고유한 이름 사용
• 생성의미대로 부여

3. 속성(Attribute)

속성 : 업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위

• 한 개의 엔터티는 2개 이상의 인스턴스 집합
• 한 개의 엔터티는 2개 이상의 속성을 가짐
• 한 개의 속성은 1개의 속성값을 가짐
• 엔터티에 대한 자세하고 구체적인 정보를 나타냄

속성의 특성에 따른 분류

• 기본 속성 : 업무로 부터 추출한 모든 일반적인 속성
• 설계 속성 : 원래 업무상 존재하지는 않지만 필요에 의해 설계를 하면서 도출해내는 속성
  • ex) 일련번호
• 파생 속성 : 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성, 가급적 안만드는게 좋음
  • ex) 이자

엔터티 구성 방식에 따른 분류

• PK 속성 : 엔터티를 식별할 수 있는 속성
• FK 속성 : 다른 엔터티와의 관계에서 포함된 속성
• 일반속성 : 그 밖의 속성

도메인 : 속성이 가질 수 있는 값 범위 (데이터 타입, 크기, 제약사항 지정)

속성의 명명

• 해당 업무에서 사용하는 이름 부여
• 서술식 속성명은 사용 금지
• 약어 사용 금지
• 구체적으로 명명하여 데이터 모델에서 유일성 확보

4. 관계(Relationship)

관계

• 엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태
• ex) 강사 - 가르친다(관계) - 수강생

관계의 패어링

• 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것

UML(통합 모델링 언어)에서의 관계

• 연관관계 (실선) : 항상 이용하는 관계 (존재적 관계)
  • ex) 소속된다.
• 의존관계 (점선) : 상대 행위에 의해 발생하는 관계 (행위적 관계)
  • ex) 주문한다.

ERD에서는 존재적 관계와 행위적 관계를 구분하지 않고 표현함

관계의 표기법

• 관계명(Membership) : 관계의 이름
  • 두개의 관계명이 있음 (시작점(포함한다), 끝점(소속된다))
• 관계차수(Cardinality) : 1:1, 1:M, M:N
• 관계선택사양(Optionality)
  • 필수관계 : 지하철 출발 & 지하철 문닫힘 관계 (필수임)
  • 선택관계 : 지하철 출발 & 지하철 안내방송 관계 (필수는 아님)

관계 체크사항

• 두 개의 엔터티 사이에 관심있는 연관규칙이 존재하는가?
• 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
• 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
• 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?

5. 식별자(Identifiers)

식별자

• 하나의 엔터티에 구성되어 있는 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성
• 하나의 엔터티는 반드시 하나의 유일한 식별자가 존재
• 혼동 주의 : 식별자 → 논리적 데이터 모델링 / Key → 물리적 데이터 모델링

주 식별자의 특징

식별자의 분류

• 사원테이블의 식별자인 사번은, 업무적으로 의미 있는 식별자로, 시스템적으로 부여된 인조식별자가 아니라 일반적으로 사원 인스턴시의 탄생과 함꼐 업무적으로 부여되는 본질적인 속성

주 식별자 도출 기준

• 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다.
• 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않는다.
• 복합으로 주식별자로 구성할 경우 너무 많은 속성이 포함되지 않도록 한다.

식별자 관계

• 자식엔터티의 주식별자로 부모의 주식별자가 상속이 되는 경우
• 부모로 부터 받은 식별자를 자식 엔터티의 주식별자로 이용하는 경우
• 강한 연결관계 표현, 실선 표기
• 주식별자 관계로만 설정 시 주식별자 증가로 오류 유발

비식별자 관계

• 부모 엔터티로 부터 속성을 받았지만 자식엔터티의 주식별자로 사용하지 않고 일반 속성으로만 사용하는 경우
• 자식엔터티에서 받은 속성이 반드시 필수가 아니어도 무방하기 때문에 부모 없는 자식이 생성될 수 있는 경우
• 부모와 자식 엔터티가 생명주기가 다른 경우 (별도로 소멸됨)
• 여러 개의 엔터티가 하나의 엔터티로 통합되어 표현되었는데 각각의 엔터티가 별도의 관계를 가지는 경우
• 자식엔터티에 주식별자로 사용하여도 되지만 자식엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단되는 경우
• 약한 연결관계 표현, 점선 표기
• 비식별자 관계로만 설정 시 부모 엔터티와 조인하여 성능 저하

Reference

[데이터 전문가 포럼] SQL 개발자 스터디 교재

https://yurimac.tistory.com/40