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

2023. 2. 7. 15:40Data Base/SQLD

데이터 모델링 3단계

   개념적, 논리적, 물리적 모델링

 

데이터 독립성

   물리적 데이터 독립성, 논리적 데이터 독립성

 

데이터 모델의 구성요소

   엔터티, 관계/차수, 속성/식별자

 

다양한 ERD의 표기법

  Peter Chen 표기법, IE 표기법, Barker 표기법, ...

 

모델링이란

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

        º 추상화(모형화), 단순화, 명확화

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

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

 

모델링의 관점

- 데이터 관점(What)

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

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

 

- 프로세스 관점(How)

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

 

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

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

 

데이터 모델링의 3단계

데이터 중복 제거

데이터베이스 3단계 구조

   - 외부 스키마(External Schema)

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

 

   - 개념스키마(Conceptual Schema)

      º 모든 사용자의 관점을 통합한 스키마

      º DB에 저장되는 데이터와 그들 간의 관계를 표현

 

   - 내부 스키마(Physical Schema)

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

 

         → 데이터 모델링은 통합 관점의 개념 스키마를 만들어 가는 과정

 

데이터의 독립성과 종속성

   - 데이터 종속성

      º 응용 프로그램에 대한 데이터의 종속성

      º 예) 파일 시스템

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

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

 

   - 데이터 독립성

      º 데이터 구조가 변경되어도 응용 프로그램이 변경될 필요가 없음

      º 논리적 독립성 + 물리적 독립성으로 실현됨

 

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

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

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

데이터 독립성

   - 논리적 독립성

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

      º 내용

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

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

 

   - 물리적 독립성

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

      º 내용

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

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

 

데이터 모델링의 3가지 구성 요소

   - Entity(개체) : 업무와 관련된 어떤 것

   - Attribute(속성) : 어떤 것이 갖는 성격

   - Relationship(관계) : 어떤 것 간의 관계

 

데이터베이스 스키마 (Schema)

   - 데이터 모델링의 대상

   - 테이터베이스 구조, 데이터 타입, 그리고 제약조건에 대한 명세

   - 데이터베이스 설계 단계에서 명시되며, 자주 변경되지 않음

 

데이터베이스 인스턴스 (Instance)

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

 

데이터 모델 표기법

ERD 작성 순서

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

      º 가급적 선이 꼬이지 않게 배피

      º 왼쪽 → 오른쪽, 위 → 아래 순으로 읽어나가기 편하도록 배치

 

   - 엔터티간 관계 설정

      º 식별자 관계를 우선 설정함

          º 식별자 관계 : 부모로부터 상속받은 Fk가 자식의 PK의 일부가 되는 관계

      º 가급적 Cycle 관계도 발생하지 않아야 함

 

   - 관계명 기술 (양 방향)

      º 현재형 사용, 지나치게 포괄적인 단어는 지양

      º 실제 프로젝트에서는 크게 고려하지 않음

   - 관계차수와 선택성 표시

대응수 : Cardinality

차수 : degree

※ 실무에서는 차수가 → Cardinality 를 나타낸다

 

좋은 데이터 모델

엔터티의 정의

   - 변별할 수 있는 사물 - Peter Chen (1976)

   - 데이터베이스 내에서 변별 가능한 객체 - C.J Date (1986)

   - 정보를 저장할 수 있는 어떤 것 - James Martin (1989)

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

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

 

엔터티의 분류

   - 유형(Tangible) 엔터티

      º 물리적인 형태가 있고 안정적이며 지속적으로 활용됨

      º 교수, 강의실, 학생 등

 

   - 개념(Conceptual) 엔터티

      º 물리적인 형태는 존재하지 않으나 관리해야 할 개념적 정보

      º 수업, 보험상품 등

 

   - 사건(Event) 엔터티

      º 업무 수행 과정에서 발생하며 비교적 발생량이 많음 (각종 통계 자료에 이용됨)

      º 수강신청, 주문, 입금 등

 

엔터티의 특징

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

      º 관심 영역(Business Boundary)에 따라 달라짐

 

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

 

   - 반드시 속성을 가져야 함

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

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

      º 단 연관 엔터티(Associative Entity)는 주식별자 속성만 갖고 있어도 인정

 

 

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

      º 고립 엔터티(Isolated Entity) - 부적절한 엔터티 도출, 또는 관계 누락

 

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

      º 통계성 엔터티

      º 코드성 엔터티

      º 시스템 처리용 내부 엔터티 엔터티(트랜잭션 로그 테이블 등)

 

엔터티의 명명

   - 엔터이 생성 의미대로, 실제 업무에서 사용하는 용어를 사용한다.

   - 약어를 사용하지 않는다.

   - 단수 명사를 사용한다.

   - 이름이 동일한 엔터티가 중복으로 존재할 수 없다.

 

관계와 페어링(Pairing)

   - 관계

      º 엔터티간 논리적 연관성

 

   - 페어링(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인 경우, 해당 관계는 잘못 설정되었을 가능성이 큼

 

관계 읽기

속성의 정의

   - 사물(엔터티)의 특징 또는 본질적인 성질

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

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

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

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

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

      º 각 엔터티는 둘 이상의 인스턴스를 가짐

      º 각 엔터티는 둘 이상의 속성을 가짐

      º 각 속성은 하나의 속성값을 가짐

 

속성의 특징

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

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

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

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

 

속성의 명명

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

   - 약어 사용은 가급적 금지

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

   - 수식어와 소유격을 피함

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

 

속성의 표기

   - 엔터티 내에 이름을 기재

도메인(Domain)

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

      º 예) 학점: 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)가 비식별자 속성으로 포함된 경우 → 비식별자 관계

식별자 관계(Identifying Relationship)

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

식별자 관계 남용시 문제

비식별자 관계 남용시 문제

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

 

출처 : https://www.youtube.com/watch?v=TThEOiEbok0&t=4790s 

반응형

'Data Base > SQLD' 카테고리의 다른 글

[SQLD] SQL 최적화 기본  (0) 2023.03.13
[SQLD] 데이터 모델과 성능  (0) 2023.02.28
[SQLD] SQLD 문제 풀이  (0) 2023.02.01