५✍/SQLD

[SQLD] 1과목 - 데이터 모델링 이해

defyuil 2023. 8. 28. 20:59

출처

https://www.youtube.com/watch?v=TThEOiEbok0&t=5727s 

 

 

모델링이란?

  • 복잡한 현실 세계를 추상화, 단순화하여 일정한 표기법에 의해 명확하게 표현하는 것

ㄴ 추상화, 단순화, 명확화

-> 구체화, 복잡화, 일반화 등이 아님

  • 모델(Model): 현실 세계의 추상화된 반영

 

 

 

모델링의 관점

- 데이터 관점(What)

데이터와 데이터간 관계, 업무와 데이터간 관계를 모델링

데이터에 접근하는 방법(How), 사람(Who)과는 무관

 

- 프로세스 관점(How)

  • 업무가 실제로 하고 있는 일 또는 해야 할 일을 모델링

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

  • 업무 처리 방법에 따라 데이터가 받는 영향을 모델링

 

 

 

 

 

 

 

 

 

 

 

 

 

데이터 모델링의 3단계

 

 

 

 

 

데이터베이스 3단계 구조

- 외부 스키마

  • 각 사용자 또는 응용프로그램이 바라보는 스키마

- 개념 스키마

  • 모든 사용자의 관점을 통합한 스키마
  • DB에 저장되는 데이터와 그들간의 관계를 표현

- 내부 스키마

  • DB가 물리적으로 저장된 형식

 

데이터의 독립성과 종속성

- 데이터 종속성

  • 응용 프로그램에 대한 데이터의 종속성 예) 파일 시스템

- 응용 프로그램과 데이터가 상호 의존적

  • 데이터를 저장한 파일 구조가 변경되면 이에 대응되는 응용 프로그램도 변경되어야 함
  •  

- 데이터 독립성

  • 데이터 구조가 변경되어도 응용프로그램이 변경될 필요가 없음
  • 논리적 독립성 + 물리적 독립성으로 실현됨

 

- 데이터 독립성이 유지되지 않으면?

  • 데이터의 중복성 및 복잡도 증가
  • 요구사항 대응 난이도 증가 -> 데이터 유지보수 비용 증가

 

논리적 독립성

논리적 사상(외부적/개념적 사상)을 통해 논리적 독립성이 보장됨

개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않음

논리적 구조가 변경되어도 응용프로그램에는 영향이 없음

 

물리적 독립성

물리적 사상(개념적/내부적 사상)을 통해 물리적 독립성이 보장됨

내부스키마가 변경되어도 외부/개념 스키마는 영향을 받지 않음

저장 장치의 구조변경은 응용 프로그램과 개념 스키마에 영향을 주지 않음

 

 

 

 

 

 

스키마란?

  • 데이터 모델링의 대상, 데이터베이스 구조, 데이터 타입, 제약조건에 대한 명세
  • 데이터베이스 설계 단계에서 명시되며 자주 변경되지 않음

 

 

인스턴스란?

  • 특정 시점에 데이터베이스에 실제로 저장되어 있는 데이터 값

 

 

데이터 모델 표기법

 

ERD 작성 순서

- 엔터티를 그린 후 적절하게 배치

  • 가급적 선이 꼬이지 않게 배치
  • 왼쪽->오른쪽, 위->아래 순으로 읽어나가기 편하도록 배치

 

- 엔터티간 관계 설정

  • 식별자 관계를 우선 설정함
  • 식별자 관계: 부모로부터 상속받은 FK가 자식의 PK의 일부가 되는 관계
  • 가급적 Cycle 관계도 발생하지 않아야 함

 

- 관계명 기술(양방향)

  • 현재형 사용, 지나치게 포괄적인 단어는 지양
  • 실제 프로젝트에서는 크게 고려하지 않음

 

- 관계차수와 선택성 표시

 

 

앤터티(Entity)

 

엔터티의 정의

- 변별할 수 있는 사물 

- 데이터베이스 내에서 변별 가능한 객체

- 정보를 저장할 수 있는 어떤 것

- 정보가 저장될 수 있는 사람, 장소, 물건, 사건, 그리고 개념 등

업무에 필요한 정보를 저장하고 관리하기 위한 집합적인 것!!

 

 

 

엔터티의 분류

- 유형 앤터티

  • 물리적인 형태가 있고 안정적이며 지속적으로 활용됨
  • 교수, 강의실, 학생 등

 

- 개념 엔터티

  • 물리적인 형태는 존재하지 않으나 관리해야 할 개념적 정보
  • 수업, 보험상품 등

 

- 사건 엔터티

  • 업무 수행 과정에서 발생하며 비교적 발생량이 많음(각종 통계 자료에 이용됨)
  • 수강신청, 주문, 입금 등

 

 

 

엔터티와 인스턴스

- 엔터티는 인스턴스의 집합

 

 

 

엔터티의 특징

- 해당 업무에서 필요하고 관리하고자 하는 정보를 포함해야 함

  • 관심 영역에 따라 달라짐

 

 

 

 

- 유일한 식별자에 의해 식별이 가능해야 함

 

 

 

 

- 영속적으로 존재하는(둘 이상) 인스턴스의 집합이어야 함

 

 

 

 

- 업무 프로세스에 의해 이용되어야 함

  • 업무 프로세스에 의해 CRUD(Create, Read, Update, Delete)가 발생해야 함
  • CRUD가 발생하지 않는다면 부적절한 엔터티 도출, 또는 업무 누락
  • ex)  CRUD Matrix 예

 

 

- 반드시 속성을 가져야 함

  • 속성 없이 엔터티의 이름만 존재할 수 없음

속성-날씨/엔터티-날씨이름      속성-태풍/엔터티-태풍이름/연관엔터티-발생지역, 풍속

 

- 주식별자만 존재하고 일반 속성은 없는 경우도 바람직하지 않음

  • 단 연관 엔터티는 주식별자 속성만 갖고 있어도 인정

 

 

엔터티의 명명

  • 엔터티 생성 의미대로, 실제 업무에서 사용하는 용어를 사용한다
  • 약어를 사용하지 않는다
  • 단수 명사를 사용한다
  • 이름이 동일한 엔터티가 중복으로 존재할 수 없다

 

- 다른 엔터티와 최소 한 개 이상의 관계를 가져야 함

  • 고립 엔터티 - 부적절한 엔터티 도출, 또는 관계 누락

 

- 다음의 경우 고립 엔터티를 인정함

  • 통계성 엔터티
  • 코드성 엔터티
  • 시스템 처리용 내부 엔터티(트랜잭션 로그 테이블 등)

 

 

관계(Relationship)

관계와 페어링

 

- 관계

  • 엔터티간 논리적 연관성

 

- 페어링(Pairing)

  • 엔터티 내 인스턴스 간의 개별적 연관성

 

- 페어링 집합 → 관계

  • cf) 엔터티 ← 인스턴스의 집합을 논리적으로 표현

 

최초의 ERD(chen 모델)에서 관계는 속성을 가질 수 있었으나 최근 ERD(IE 모델)에서 관계는 속성을 갖지 않음!!

 

 

 

관계의 분류

- 존재에 의한 관계 vs 행위에 의한 관계

 

 

 

관계의 표기법

- 관계명

  • 각 관계는 두 방향의 관계명을 가짐
  • 명명 규칙
  • 애매한 동사를 피한다(예: 관계된다, 관련있다 등을 피함)
  • 현재형으로 표현한다(예: 신청했다, 강의할 것이다 등을 피함)

 

- 관계 차수(Degree)

  • 각 관계에 참여할 수 있는 인스턴스의 수
  • 1:N, 1:1, M:N등이 존재함
  • 학계에서의 대응수(Cardinality)에 해당하는 개념
  • 학계에서 차수(Degree)는 unary, binary, ternary, N-ary를 의미함

 

 

- 관계 선택성(Optionality)

  • 필수 참여(Mandatory Membership)

 

 

 

  • 선택 참여(Optional Membership)

→ 관계의 양쪽이 Optional인 경우, 해당 관계는 잘못 설정되었을 가능성이 큼

 

 

 

 

관계 읽기

 

 

속성(Attribute)

 

속성의 정의

 

 

- 사물의 특징 또는 본질적인 성질

  • 속성이 없다면 실체를 생각할 수 없음

- 인스턴스에 대해 의미상 더 이상 분리되지 않는 최소의 데이터 단위

- 엔터티에 속한 인스턴스들의 성격을 구체적으로 나타냄

  • 인스턴스 각각을 구분할 수 있는 기준 파악 🡪 이름 부여 🡪 속성화

- 엔터티, 인스턴스, 속성, 속성값의 대응

  • 각 엔터티는 둘 이상의 인스턴스를 가짐
  • 각 엔터티는 둘 이상의 속성을 가짐
  • 각 속성은 하나의 속성값을 가짐

 

속성의 특징

- 해당 업무에서 필요하고 관리해야 하는 정보

- 모든 속성은 주식별자에 함수적으로 종속되어야 함

- 하나의 속성은 한 개의 값만을 가져야 함

  • 속성이 다중값을 가질 경우 해당 속성을 별도의 엔터티로 분리함

 

 

속성의 명명

- 현업에서 사용하는 이름을 부여

- 약어 사용은 가급적 금지

- 서술식 속성명을 피하고 명사형 속성명을 사용

- 수식어와 소유격을 피함

- 속성의 이름은 가급적 전체 모델에서 유일하게 정의

 

 

속성의 표기

- 엔터티 내에 이름을 기재

 

 

도메인

- 각 속성이 가질 수 있는 값의 범위

예) 학점: 0.0 ~ 4.5 사이의 실수

예) 주소: 길이가 20자리 이내인 문자열

- 속성에 대한 데이터 타입과 크기, 그리고 제약사항을 지정하는 개념

 

 

속성의 분류

- 속성의 특성에 따른 분류

  • 기본 속성(Basic Attribute): 가장 일반적인 속성으로 원래의 업무로부터 유래한 속성
  • 설계 속성(Designed Attribute): 구분이 애매함 데이터 모델링을 위해 새로 만든 속성(주로 코드)
  • 파생 속성(Derived Attribute): 다른 속성들로부터 유도된 속성(주로 통계 관련) 가급적 적게 정의하는 것이 좋음

 

 

 

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

  • PK(Primary Key) 속성 - 엔터티의 인스턴스를 구별할 수 있는 속성
  • FK(Foreign Key) 속성 - 타 엔터티의 PK를 참조하는 속성
  • 일반 속성 - 그 외의 속성

 

- 분리 가능성에 따른 분류

  • 복합 속성(Composite Attribute) vs 단순 속성(Simple Attribute)

 

- 속성값의 수에 따른 분류

  • 다중값 속성(Multi-Valued Attribute) vs 단일값 속성(Single-Valued Attribute)

 

 

식별자의 분류

 

 

 

식별자의 특징

 

주식별자 도출 기준

- 유일성을 갖는 속성 중 해당 업무에서 자주 이용되는 속성을 지정 

- 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않음

- 복합식별자를 구성할 경우 너무 많은 속성이 포함되지 않아야 함

 

 

 

 

 

 

 

식별자 관계와 비식별자 관계

- 부모 엔터티의 식별자 A를 자식 엔터티의 외부 식별자A(FK)로 포함할 때

  • A(FK)가 주식별자에 포함된 경우 -> 식별자 관계
  • A(FK)가 비식별자 속성으로 포함된 경우 -> 비식별자 관계

 

 

 

식별자 관계

- 부모의 주식별자가 자식엔터티의 주식별자로 상속

- 반드시 부모 엔터티가 생성되어야 자식 엔터티가 생성될 수 있음

  • 해당 속성이 Not NULL이므로 🡪 weak entity에 해당됨

- 자식 엔터티의 주식별자가 해당 속성만으로 구성되는 경우 🡪 1:1 관계

- 자식 엔터티의 주식별자가 해당 속성 + α 로 구성되는 경우 🡪 1:N 관계

 

 

 

비식별자 관계

- 부모의 주식별자가 자식엔터티의 비식별자 속성으로 상속

- 다음의 경우 비식별자 관계가 생성됨

  • 부모 엔터티와 자식 엔터티의 관계가 약한 경우
  • 부모 엔터티 없이 자식 엔터티가 생성 가능

 

  • 자식 엔터티의 주식별자로 사용해도 되지만, 일반 속성으로 두는 것이 유리할 때
  • 자식 엔터티의 독립적인 주식별자 설정이 필요한 경우 등

 

 

 

식별자 관계 남용시 문제

- 주식별자 속성이 지속성으로 증가함

 

 

- 조회시 조인 횟수 증가

예: '홍길동' 학생의 학과코드 조회

 

 

비식별자 관계를 고려해야 하는 경우

- 부모 엔터티와 자식 엔터티의 관계의 강도가 약한 경우

- 자식 엔터티의 독립적인 주식별자 설정이 필요한 경우

- PK 속성의 단순화가 필요한 경우

  • SQL 복잡도 증가로 인해 개발 생산성이 저하되는 현상 방지

 

 

ER Diagram(Conceptual)

- Peter Chen 표기법

 

- Schema Diagram(Logical)

 

 

ER Diagram(Conceptual/Logical)

- information Engineering 표기법 (=Crow's Foot Model)