[DB/SQL] 데이터 모델링의 이해

Joo·2024년 2월 19일

RDB & SQL

목록 보기
3/24

강의 링크 : https://www.youtube.com/watch?v=TThEOiEbok0&list=PLg_wJlcMiuKtGdlIaAZ0rOPPQuTDENnEQ&index=5


1. 데이터 모델링 개요

모델링이란?

  • 복잡한 현실세계를 추상화, 단순화하여 일정한 표기법에 의해 명확하게 표현하는 것
    • 추상화(모형화), 단순화, 명확화
      • 구체화, 복잡화, 일반화 등이 아님
  • 모델(Model) : 현실 세계의 추상화된 반영

모델링의 관점

  • 데이터 관점(What)
    • 데이터에만 초점
    • 데이터와 데이터 간 관계, 업무와 데이터 간 관계를 모델링(=프로세스에서 사용하는 데이터를 모델링)
    • 데이터에 접근하는 방법(How), 사람(Who)과는 무관
      • 예, ID, 패스워드
  • 프로세스 관점(How)
    • 절차와 순서에 초점
    • 업무가 실제로 하고 있는 일 또는 해야할 일을 모델링
      • 로그인을 하려면 ID와 패스워드가 필요함
  • 데이터와 프로세스의 상관 관점(Interaction)
    • 업무 처리 방법에 따라 데이터가 받는 영향을 모델링



2. 데이터 모델링의 3단계

2-1. 개념적, 논리적, 물리적 모델링

데이터 모델링의 단계 (학계와 산업계의 이해)

- 학계에서의 개념적 모델링은 엔터티와 관계가 명확하게 나타있고 논리적 모델링은 그걸 테이블화한 것 - 산업계에서는 개념적 모델링과 논리적 모델링을 명확히 구분짓지 않지만, 엄밀히 따지자면 개념적 모델링은 추상화 수준을 높인 것이고 논리적 모델링은 구체적으로 나타낸 것임 ## 3. 데이터 독립성

  • 데이터베이스 시스템의 핵심 : 프로그램과 데이터 간 독립성을 보장해 중복 문제를 일으키지 않게 하려는 것

독립성을 위해 필요한 3가지 구조

  • 외부 스키마
    • 프로그램 관점 및 요구사항 관점의 질문을 해결하기 위해 필요한 데이터(응용 프로그램 관점에서의 요구사항)
    • 각 사용자 또는 응용프로그램이 바라보는 스키마
  • 개념 스키마
    • 전체 필요한 데이터 모음(외부 스키마가 필요로 하는 데이터의 모음, 이들을 어떻게 잘 정리해야 요구사항에 잘 맞을까를 설계함 - 데이터베이스의 핵심)
    • 모든 사용자의 관점을 통합한 스키마
    • DB에 저장되는 데이터와 그들 간의 관계를 표현
  • 내부 스키마
    • 개념 스키마를 실제로 잘 정리해놓은 구조
    • DB가 물리적으로 저장된 형식
  • 데이터 모델링은 통합 관점의 개념 스키마를 만들어 가는 과정

데이터의 독립성과 종속성

  • 데이터 종속성

    • 응용 프로그램에 대한 데이터의 종속성
    • 예, 파일 시스템
      • 응용 프로그램과 데이터가 상호 의존적
      • 데이터를 저장한 파일 구조가 변경되면 이에 대응되는 응용 프로그램도 변경되어야 함
  • 데이터 독립성

    • 데이터 구조가 변경되어도 응용 프로그램이 변경될 필요가 없음
    • 논리적 독립성 + 물리적 독립성으로 실현됨
      • 논리적 독립성 : 외부-개념 스키마 사이의 독립성
      • 물리적 독립성 : 개념-내부 스키마 사이의 독립성
  • 데이터 독립성이 유지되지 않으면?

    • 데이터의 중복성 및 복잡도 증가

    • 요구사항 대응 난이도 증가 → 데이터 유지보수 비용 증가

      3-1. 물리적 데이터 독립성, 논리적 데이터 독립성

    • 논리적 독립성

      • 논리적 사상(외부적/개념적 사상)을 통ㅎ애 논리적 독립성이 보장됨
      • 내용
        • 개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않음
        • 논리적 구조가 변경되어도 응용 프로그램에는 영향이 없음
    • 물리적 독립성

      • 물리적 사상(개념적/내부적 사상)을 통해 물리적 독립성이 보장됨
      • 내용
        • 내부스키마가 변경되어도 외부/개념 스키마에는 영향을 받지 않음
        • 저장장치의 구조변경은 응용프로그램과 개념 스키마에 영향을 주지 않음

4. 데이터 모델의 구성요소

  • 데이터 모델링의 3가지 구성 요소
    • Entity(개체) : 업무와 관련된 어떤 것(Thing)
    • Attribute(속성) : 어떤 것이 갖는 성격
    • Relationship(관계) : 어떤 것들 간의 관계


데이터베이스 스키마 vs 인스턴스

  • 스키마(Schema)

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


  • 인스턴스(Instance)

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


      4-1. 엔터티, 관계/차수, 속성/식별자

      엔터티(Entity)

    • 변별할 수 있는 사물

    • DB 내에서 변별 가능한 객체

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

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

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

    • 엔터티의 분류

      • 유형(Tangible) 엔터티
        • 물리적인 형태가 있고 안정적이며 지속적으로 활용됨
        • 교수, 강의실, 학생 등
      • 개념(Conceptual) 엔터티
        • 물리적인 형태는 존재하지 않으나 관리해야 할 개념적 정보
        • 수업, 보험상품 등
      • 사건(Event) 엔터티
        • 업무 수행 과정에서 발생하여 비교적 발생량이 많음 (각종 통계 자료에 이용됨)
        • 수강신청, 주문, 입금 등
      • 엔터티와 인스턴스
        • 엔터티는 인스턴스의 집합
      • 엔터티의 특징
        • 해당 업무에서 필요하고 관리하고자 하는 정보를 포함해야 함 (관심 영역(Business Boundary)에 따라 달라짐)
        • 유일한 식별자에 의해 식별이 가능해야 함
        • 영속적으로 존재하는 둘 이상의 인스턴스 집합이어야 함
        • 업무 프로세스에 의해 이용되어야 함
          • 업무 프로세스에 의해 CRUD(Create, Read, Update, Delete)가 발생해야 함
          • CRUD가 발생하지 않는다면 → 부적절한 엔터티 도출, 또는 업무 누락
          • 예, CRUD Matrix 예시

        • 반드시 속성을 가져야 함
          • 속성 없이 엔터티의 이름만 존재할 수 엇음
        • 주식별자만 존재하고 일반속성은 없는 경우도 바람직하지 않음
          • 단, 연관 엔터티(Associatvie Entity)는 주식별자 속성만 갖고 있어도 인정
        • 다른 엔터티와 최소 한 개 이상의 관계를 가져야 함
          • 고립 엔터티(Isolated Entity) - 부적절한 엔터티 도출, 또는 관계 누락
          • 다음의 경우 고립 엔터티를 인정함
            • 통계성 엔터티
            • 코드성 엔터티
            • 시스템 처리용 내부 엔터티(트랜잭션 로그 테이블 등)
      • 엔터티의 명명
        • 엔터티 생성 의미대로, 실제 업무에서 사용하는 용어 선택
        • 약어 X
        • 단수 명사 사용 (서술형 명사 X)
        • 이름이 동일한 엔터티가 중복으로 존재할 수 없음

      관계(Relationship)

    • 관계와 페어링(Pairing)

      • 관계
        • 엔터티간 논리적 연관성
      • 페어링
        • 엔터티 내 인스턴스 간의 개별적 연관성
      • 페어링의 집합 → 관계
        • cf) 엔터티 ← 인스턴스 집합을 논리적으로 표현
      • 최초의 ERD(Chen 모델)에서 관계는 속성을 가질 수 있었으나, 최근 ERD(IE 모델)에서 관게는 속성을 갖지 않음

        세 개의 페어링이 존재함

    • 관계의 분류

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

        사건 엔터티는 행위에 의한 관계로부터 생성됨

    • 관계의 표기법

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

      • 관계 선택성(Optionality)

      • 관계 읽기



      속성(Attribute)

    • 속성의 정의

      • 사물의 특징 또는 본질적인 성질
        • 속성이 없다면 실체를 생각할 수 없음
      • 인스턴스에 대해 의미상 더 이상 분리되지 않는 최소의 데이터 단위
      • 엔터티에 속한 인스턴스들의 성격을 구체적으로 나타냄
        • 인스턴스 각각을 구분할 수 있는 기준 파악 → 이름 부여 → 속성화
      • 엔터티, 인스턴스, 속성, 속성값의 대응
        • 각 엔터티는 둘 이상의 인스턴스를 가짐
        • 각 엔터티는 둘 이상의 속성을 가짐
        • 각 속성은 하나의 속성값을 가짐
    • 속성의 특징

      • 해당 업무에서 필요하고 관래햐아 하는 정보
      • 모든 속성은 주식별자에 함수적으로 종속되어야 함
      • 하나의 속성은 한 개의 값만을 가져야 함
        • 속성이 다중값을 가질 경우 해당 속성을 별도의 엔텅티로 분리함
    • 속성의 명명

      • 현업에서 사용하는 이름을 부여
      • 약어 X
      • 서술식 속성명 X
      • 명사형 속성명
      • 수식어, 소유격 X
      • 속성의 이름은 가급적 전체 모델에서 유일하게 정의
    • 속성의 표기

      • 엔터티 내에 이름을 기재

    • 도메인(Domain)

      • 각 속성이 가질 수 있는 값의 범위
      • 속성에 대한 데이터 타입과 크기, 그리고 제약사항을 지정하는 개념
    • 속성의 분류


      __식별자의 분류__


      __식별자의 특징__


      __주식별자 도출 기준__


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

      FK가 위로 연결되면 실선(식별자), 아래로 연결되면 점선(비식별자)


      __식별자 관계(Identifying Relationship)__

    • 식별자에 FK가 하나라도 있으면 해당 엔티티는 weak entity가 됨

      비식별자 관계(Non-Identifying Relationship)

      __식별자 관계 남용시 문제__

      __비식별자 관계 남용시 문제__

    • JOIN : 한 테이블에서 원하는 정보를 찾지 못 해서 다른 테이블을 참조하는 것
      비식별자 관계를 고려해야 하는 경우



5. 다양한 ERD의 표기법

5-1. Peter Chen 표기법, IE 표기법, Barker 표기법, ...


- ERD 작성 순서 - 엔터티를 그린 후 적절하게 배치 - 가급적 선이 꼬이지 않게 배치 - 왼쪽 → 오른쪽, 위 → 아래 순으로 읽어나가기 편하도록 배치 - 엔터티 간 관계 설정 - 식별자 관계를 우선 설정함 - 식별자 관계 : 부모로부터 상속받은 FK가 자식의 PK의 일부가 되는 관계 - 가급적 Cycle 관계도 발생하지 않아야 함 - 관게명 기술 (양방향) - 현재형 사용, 지나치게 포괄하는 단어는 지양 - 실제 프로젝트에서는 크게 고려하지 않음 - 관계차수와 선택성 표시
__ERD (Conceptual) 예시__ - __Peter Chen 표기법__

__ERD (Conceptual/Logical) 예시__ - __Information Engineering 표기법 (=Crow's Foot Model)__


__Schema Diagram (Logial) 예시__

__좋은 데이터 모델__


profile
적당히 공부한 거 정리하는 곳

0개의 댓글