[SQLD] 데이터 모델링의 이해

당당·2023년 5월 1일

SQLD 관계 데이터 모델링의 이해 데이터 모델의 이해 속성 식별자 엔터티

SQLD

목록 보기

1/6

📔설명

데이터 모델링의 이해, 엔터티, 속성, 관계자, 식별자에 대해 알아보자!

🙄데이터 모델링의 이해

모델링 정의

데이터베이스 모델링 : 현실 세계를 단순화하여 표현하는 기법.
현실세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현.

모델 : 현실 세계에서 일어날 수 있는 다양한 현상에 대해 일정한(약속된) 표기법에 의해 표현해 놓은 모형.
모델링 : 이런 모델을 만들어가는 일

현실 세계를 반영
단순화하여 표현
관리하고자 하는 데이터를 모델로 설계
현실세계에서 필요한 데이터를 저장하는 DB를 구축하기 위한 분석/설계 과정
정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
현실세계를 일정한 형식에 맞추어 표현하는 추상화의 의미
모델링은 단지 시스템 구현만을 위해 수행하는 것이 아니라, 시스템 구현을 포함한 업무분석 및 업무형상화 목적 O
복잡한 현실을 제한된 언어나 표기법을 통해 이해하기 쉽게 하는 단순화 의미
애매모호함 배제하고, 누구나 이해가 가능하도록 정확하게 현상을 기술하는 명확화 의미

데이터 모델링의 필요 이유

데이터 모델링을 통하여 분석된 모델을 가지고 DB를 생성하여 개발 및 데이터 관리에 사용하기 위한 것
업무정보를 구성하는 기초가 되는 정보들에 대해 일정한 표기법에 의해 표현
데이터모델링 자체로서 업무의 흐름을 설명하고 분석하는 부분에 의미

모델링의 특징

추상화 : 현실 세계를 일정한 형식으로 표현. 즉, 간략하게 표현
단순화 : 복잡한 현실세계를 정해진 표기법으로 단순하고 쉽게 표현
명확화 : 불분명함을 제거하고 명확하게 해석할수 있도록 기술

모델링 관점

데이터 관점 : 데이터 위주 모델링. 어떤 데이터들이 업무와 얽혀있는지. 그 데이터 간에는 어떤 관계가 있는지.
프로세스 관점 : 프로세스 위주 모델링. 업무가 실제로 처리하고 있는 일은 무엇인지 또는 앞으로 처리해야 하는 일은 무엇인지.
데이터와 프로세스의 상관 관점 : 데이터와 프로세스의 관계를 위주로 한 모델링. 프로세스의 흐름에 따라 데이터가 어떤 영향을 받는지 모델링.

모델링의 세 가지 단계

개념적 데이터 모델링 : 전사적 데이터 모델링 수행 시 행함. 추상화 레벨이 가장 높은 모델링. 업무 중심적이고 포괄적인 수준의 모델링 진행.
EA 수립시 많이 이용.
논리적 데이터 모델링 : 재사용성이 가장 높은 모델링. 데이터베이스 모델에 대한 Key, 속성, 관계 등을 모두 표현하는 단계.
물리적 데이터 모델링 : 실제 데이터베이스로 구현할 수 있도록 성능이나 가용성 등의 물리적인 성격을 고려하여 모델 표현

스키마 구조

외부 스키마 : 사용자 관점. 각 사용자가 보는 데이터베이스 스키마.
View 단계. DB의 각 사용자나 응용 프로그래머가 접근하는 DB의 정의.

개념 스키마 : 통합된 관점. 모든 사용자가 보는 데이터베이스 스키마를 통합하여 전체 데이터베이스를 나타낸 것. 데이터베이스에 저장되는 데이터들을 표현하고 데이터들 간의 관계를 나타낸다.

내부 스키마 : 물리적 관점. 물리적인 저장 구조를 나타낸다. 실질적인 데이터의 저장 구조나 컬럼 정의, 인덱스 등이 포함

외부 스키마<->개념 스키마 -- 논리적 데이터 독립성
: 데이터베이스 내부 구조는 알 필요가 없고, 필요한 데이터만 볼 수 있으면 된다. 즉, 개념 스키마가 변경되어도 외부 스키마는 영향받지 않는다.

개념 스키마<->내부 스키마 -- 물리적 데이터 독립성
: 어플리케이션에 영향을 주지 않고 데이터베이스의 구조를 변경할 수 있다.
즉, 내부 스키마가 변경되어도 외부/개념 스키마는 영향받지 않는다.

ERD

Peter Chen
IDEF1X(Integration Definition for Information Modeling
IE/Crow's Foot

⬜ : 엔터티
⚪ : 0개 (선택)
| : 1개 (필수)
⪪ : 2개 이상
──── : 부모 엔터티의 식별자가 자식 엔터티의 주식별자 식별자 관계
---- : 부모 엔터티의 식별자가 자식 엔터티의 일반 속성 비식별자 관계

Min-Max/ISO
UML
Case*Method/Barker

ERD 작성 순서

엔터티 도출, 그리기
엔터티 적절하게 배치
엔터티 간의 관계 설정
관계명 기입
관계 참여도 기입
관계 필수/선택 여부 기입

시스템 분석을 위한 모델링의 기능

시스템이 향후 변화하고자 하는 모습으로 가시화
시스템을 구축하는 과정에서 결정한 것을 문서화
시스템의 구조와 행동을 명세화
시스템을 구축하는 구조화된 틀을 제공

데이터 모델링 시 지양

중복 : 같은 데이터가 여러 엔터티에 중복으로 저장되는 현상
-> 중복되어 저장되지 않도록 해야 함
비유연성 : 어플리케이션과 데이터 간의 연계성이 높아, 어플리케이션 변경 시마다 데이터 모델이 변경되어야 함
-> 데이터의 정의를 데이터의 사용 프로세스와 분리하여 해결
비일관성 : 개발자가 다른 데이터와의 연관성을 고려하지 않고 일부 데이터만 변경
-> 데이터 간의 일관성 유지를 위해 상호 연관 관계를 명확하게 정의

👩🏻엔터티(Entity)

엔터티 정의

엔터티 : 식별이 가능한 객체.
업무에서 쓰이는 데이터를 용도별로 분류한 그룹 (모호한 기준 X)

엔터티 특징

업무에서 쓰이는 정보여야 함.
실제 프로세스에 이용안되면 적절한 엔터티X
유니크함을 보장할 수 있는 식별자가 있어야 함.
엔터티에 속한 각각의 인스턴스가 중복되거나 식별이 모호하면 엔터티는 설계가 잘못된 것이다. 즉 각각의 인스턴스를 구별할 수 있는 것이 필요함.
2개 이상의 인스턴스를 가지고 있어야 함.
굳이 인스턴스가 1개만 존재하는 것을 엔터티로 만들 필요 X
다른 엔터티와 1개 이상의 관계를 가지고 있어야 함.
다른 엔터티와의 연관성을 가지고 있어야 함.
=> 단, 통계성 엔터티나 코드성 엔터티는 관계 생략O
속성을 가지고 있어야 함

엔터티 종류

독립 엔터티 : 사람, 물건, 장소 등 현실세계에 존재하는 엔터티
업무중심 엔터티 : Transaction이 실행되면서 발생하는 엔터티
종속 엔터티 : 1차 정규화로 인해 관련 중심 엔터티로부터 분리된 엔터티
교차 엔터티 : M:N관계를 해소하려는 목적으로 만들어진 엔터티

엔터티 분류

1.유형 vs 무형

유형 엔터티 : 물리적인 형태 존재. 안정적. 지속적.
ex) 상품, 회원
개념 엔터티 : 물리적인 형태 X. 개념적.
ex) 부서, 학과
사건 엔터티 : 행위를 함으로써 발생. 빈번함. 통계 자료로 이용 가능
ex) 주문, 이벤트 응모

2.발생시점

기본 엔터티 : 독립적으로 생성. 자식 엔터티 가질 수 있음. 자신만의 주식별자를 가짐.
ex) 상품, 회원
중심 엔터티 : 기본 엔터티로부터 파생. 행위 엔터티 생성. 많은 데이터를 갖게 됨.
ex) 주문
행위 엔터티 : 2개 이상의 엔터티로부터 파생. 설계 초기 단계보다는 상세 설계 단계에서 많이 도출.
ex) 주문 내역, 이벤트 응모 이력

엔터티 이름 규칙

업무에서 실제로 쓰이는 용어 사용
한글은 약어를 사용하지 않고 영문은 대문자로 표기
단수 명사로 표현, 띄어쓰기X
다른 엔터티와 의미상으로 중복될 수 없음(주문, 결제 엔터티는 가능)
해당 엔터티가 갖고 있는 데이터가 무엇인지 명확하게 표현
ex) 집계 <-무엇을 집계한지 불분명
모든 엔터티에서 유일한 이름이 부여되어야 함
엔터티가 생성되는 의미대로 자연스럽게 부여

👩🏻‍🔧속성(Attribute)

속성 정의

속성 : 엔터티의 특징을 나타내는 최소의 데이터 단위

의미상 더 이상 쪼개지지 않는 레벨
프로세스에 필요한 항목
엔터티에 대한 구체적이고 명확한 정보 나타냄
속성도 집합

속성값

속성값 : 엔터티에 속한 하나의 인스턴스를 구체적으로 나타내주는 데이터

하나의 속성은 한 개의 속성값만 가짐

엔터티, 인스턴스, 속성, 속성값 관계

한 개의 엔터티는 두 개 이상의 인스턴스를 갖는다
한 개의 인스턴스는 두 개 이상의 속성을 갖는다
한 개의 속성은 하나의 속성값을 갖는다

속성 분류

1.특성에 따른 분류

기본속성 : 업무 프로세스 분석을 통해 바로 정의가 가능한 속성
설계속성 : 업무에 존재X, 설계하다보니 필요하다고 판단되어 도출해낸 속성
ex) 학생 인스턴스에 유니크함을 보장하기 위해 학번 설계속성 도입
파생속성 : 다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성. 다른 속성으로부터 파생. 파생속성을 설계시 반드시 데이터의 정합성이 고려되어야 하므로 불가피하게 필요한 경우만 정의하는 것이 바람직
ex) 상품을 주문하고 결제하는 순간 주문 내역과 주문 상품 인스턴스가 생성, 주문 상품 인스턴스에는 주문한 상품의 개수가 속성으로 존재.

2.구성방식에 따른 분류

PK속성 : 엔터티의 인스턴스들을 식별할 수 있는 속성
FK속성 : 다른 엔터티의 속성에서 가져온 속성
일반속성 : PK, FK 제외 나머지 속성

속성 명칭 규칙

해당 업무에서 사용하는 이름
(데이터 모델링 대상에서 사용하는 용어와 외부에서 사용하는 용어도 있어 중복이 있을 때, 해당 업무에서 자주 사용하는 이름 이용)
서술식 속성명 사용X
약어사용 가급적 제한
전체 데이터모델에서 유일성 확보하는 것이 좋음

도메인(Domain)

도메인 : 속성이 가질 수 있는 속성값의 범위
ex) 학점 속성의 속성값은 0.1~4.5 사이의 실수를 가질 수 있다.

속성에 대한 데이터타입, 크기, 제약사항 지정

용어사전

용어사전 : 엔터티의 속성명을 정의할 때 명확한 의미의 이름을 부여하고 다른 엔터티와의 혼란을 예방하기 위해 이용하는 것.

설계 시 용어사전을 두고, 각 엔터티에 공통된 룰로 적용하는 것이 바람직
하나의 DB에서 같은 의미를 가진 데이터가 엔터티마다 다른 명으로 정의되면 혼란

🤝🏻관계(Relationship)

관계 정의

관계 : 엔터티와 엔터티와의 관계

1:1 관계 차수를 갖는 엔터티 : 관계에 참여하는 각각의 엔터티에 대해 단지 하나의 관계만 가짐

관계 분류

1.어떠한 연관성이 있는지 타입을 분류

존재 관계 : 존재 자체로 연관성이 있는 관계.
ex) 직원-부서(소속), 학생-학과(소속)
행위 관계 : 특정한 행위를 함으로써 연관성이 생기는 관계.
ex) 학생-출석부(출석), 회원-주문(주문), 회원-이벤트(응모)

ERD에서는 존재 관계와 행위 관계 구분 X.
클래스 다이어그램 에서는 연관 관계와 의존 관계로 표현

관계 표기법

관계명(Membership) : 관계의 이름
모든 관계는 두 개의 관계명을 가지고 있음 (각 엔터티 관점).
반드시 명확한 문장으로 표현해야 하며 현재형
관계차수(Cardinality) : 관계에 참여하는 수
1:1(회원-회원상세), 1:M(상품-상품가격이력), M:N(학생-수강) 형식
관계선택사양(Optionality) : 필수인지 선택인지 여부
필수적 관계는 참여자가 반드시 존재
(ex.주문(1)-주문상품(1...N) 주문은 반드시 하나의 이상의 주문상품 필요)
선택적 관계는 참여자가 없을 수도 있는 관계
(ex.학생(1)-출석부(0...N) 학생은 강의에 출석할지 말지 선택사항)

엔터티 간의 관계 정의 시 고려사항

두 엔터티 사이를 이어주는 동사 존재
두 엔터티 사이에 조합되는 정보가 존재 (정보의 조합)
두 엔터티 사이에 영향력 있는 관계가 존재 (관심 있는 연관규칙)
두 엔터티 사이의 관계 연결에 대한 규칙이 존재

관계 읽기

기준엔터티를 한 개 또는 각 으로 읽음
대상엔터티의 관계 참여도(하나, 하나 이상)를 읽음
관계선택사양과 관계명 읽음

🔑식별자(Identifiers)

식별자 정의

식별자 : 각각의 인스턴스를 구분 가능하게 만들어주는 대표 격인 속성

주식별자

주식별자 : 기본키,PK에 해당하는 속성.

유일성 : 각 인스턴스에 유니크함을 부여하여 식별 가능하도록 함
최소성 : 유일성을 보장하는 최소 개수의 속성
불변성 : 속성값이 되도록 변하지 않아야 한다
존재성 : 속성값이 NULL일 수 없음

해당 업무에서 자주 이용되는 속성을 주식별자로 지정

식별자 분류

1.대표성 여부

주식별자 : 유일성, 최소성, 불변성, 존재성을 가진 대표 식별자.
다른 엔터티와 참조 관계로 연결
보조식별자 : 인스턴스를 식별할 수 있지만, 대표 식별자 X
다른 엔터티와 참조 관계 연결 X

2.스스로 생성되었는지 여부

내부식별자 : 엔터티 내부에서 스스로 생성된 식별자
외부식별자 : 다른 엔터티에서 온 식별자.
다른 엔터티와의 연결고리역할 (외래키)

3.단일 속성 여부

단일식별자 : 하나의 속성으로 구성
복합식별자 : 두 개 이상의 속성으로 구성

4.대체 여부

원조식별자(본질식별자) : 업무 프로세스에 존재하는 식별자. 가공되지 않은 원래의 식별자
대리식별자(인조식별자) : 주식별자의 속성이 두 개 이상인 경우 그 속성들을 하나로 묶어서 사용하는 식별자 (인조적으로 생성).
원래 업무적으로 의미가 있던 식별자 속성을 대체하여 일련번호와 같이 새롭게 만든 식별자
ex) 인조식별자 주문번호는 주문번호+순번으로 구성.

식별자관계(─) vs 비식별자관계(---)

1.식별자 관계

부모 엔터티의 식별자가 자식 엔터티의 주식별자.
주식별자는 반드시 존재해야 하므로, 부모 엔터티가 있어야 생성 가능.
단일식별자인지, 복합식별자인지에 따라 1:1 이거나 1:M.
자식 엔터티는 단일식별자를 갖거나 복합식별자를 가질 수 있음.
자식 엔터티의 데이터가 부모 엔터티에 반드시 존재해야 함
강한 관계
반드시 부모엔터티 종속
상속받은 주식별자속성을 타 엔터티에 이전 필요

2.비식별자 관계

부모 엔터티의 식별자가 자식 엔터티의 주식별자가 아닌 일반속성.
일반 속성의 속성값은 NULL이 될 수 있으므로 부모 엔터티가 없는 자식 엔터티 생성이 가능.
자식 엔터티가 존재하는 상태에서 부모엔터티가 삭제될 수 있음
약한 관계
자식 주식별자 구성에 부모 주식별자 부분 필요
상속받은 주식별자속성을 타 엔터티에 차단 필요

식별자 관계 선택

부모엔터티의 주식별자를 자식엔터티에서 받아 손자엔터티까지 계속 흘려보내기 위해 고려
부모 엔터티의 인스턴스가 자식 엔터티와 같이 소멸되는 경우

비식별자 관계 선택

관계의 강약을 분석하여 상호간에 연관성이 약할 경우
자식테이블에서 독립적인 기본키의 구조를 가지기 원할 때
모든 관계가 식별자 관계로 연결되면 SQL Where에서 비교하는 항목이 증가되어 조인에 참여하는 테이블에 따라 SQL 문장이 길어져 SQL문의 복잡성이 증가되는 것을 방지하기 위해 비식별자 고려 (가장 마지막에 고려)
부모엔터티에 참조값이 없어도 자식엔터티의 인스턴스가 생성될 수 있는 경우
여러 개의 엔터티를 하나로 통합하면서 각각의 엔터티가 갖고 있던 여러 개의 개별 관계가 통합되는 경우
자식쪽 엔터티의 주식별자를 부모엔터티와는 별도로 생성하는 것이 더 유리하다고 판단하는 경우

당당

MySQL DBA 신입

다음 포스트