강의 링크 : https://www.youtube.com/watch?v=TThEOiEbok0&list=PLg_wJlcMiuKtGdlIaAZ0rOPPQuTDENnEQ&index=5
1. 데이터 모델링 개요
모델링이란?
- 복잡한 현실세계를 추상화, 단순화하여 일정한 표기법에 의해 명확하게 표현하는 것
- 모델(Model) : 현실 세계의 추상화된 반영
모델링의 관점
- 데이터 관점(What)
- 데이터에만 초점
- 데이터와 데이터 간 관계, 업무와 데이터 간 관계를 모델링(=프로세스에서 사용하는 데이터를 모델링)
- 데이터에 접근하는 방법(How), 사람(Who)과는 무관
- 프로세스 관점(How)
- 절차와 순서에 초점
- 업무가 실제로 하고 있는 일 또는 해야할 일을 모델링
- 데이터와 프로세스의 상관 관점(Interaction)
- 업무 처리 방법에 따라 데이터가 받는 영향을 모델링
2. 데이터 모델링의 3단계
2-1. 개념적, 논리적, 물리적 모델링
데이터 모델링의 단계 (학계와 산업계의 이해)
- 학계에서의 개념적 모델링은 엔터티와 관계가 명확하게 나타있고 논리적 모델링은 그걸 테이블화한 것
- 산업계에서는 개념적 모델링과 논리적 모델링을 명확히 구분짓지 않지만, 엄밀히 따지자면 개념적 모델링은 추상화 수준을 높인 것이고 논리적 모델링은 구체적으로 나타낸 것임
## 3. 데이터 독립성
- 데이터베이스 시스템의 핵심 : 프로그램과 데이터 간 독립성을 보장해 중복 문제를 일으키지 않게 하려는 것
독립성을 위해 필요한 3가지 구조
- 외부 스키마
- 프로그램 관점 및 요구사항 관점의 질문을 해결하기 위해 필요한 데이터(응용 프로그램 관점에서의 요구사항)
- 각 사용자 또는 응용프로그램이 바라보는 스키마
- 개념 스키마
- 전체 필요한 데이터 모음(외부 스키마가 필요로 하는 데이터의 모음, 이들을 어떻게 잘 정리해야 요구사항에 잘 맞을까를 설계함 - 데이터베이스의 핵심)
- 모든 사용자의 관점을 통합한 스키마
- DB에 저장되는 데이터와 그들 간의 관계를 표현
- 내부 스키마
- 개념 스키마를 실제로 잘 정리해놓은 구조
- DB가 물리적으로 저장된 형식
- 데이터 모델링은 통합 관점의 개념 스키마를 만들어 가는 과정
데이터의 독립성과 종속성
-
데이터 종속성
- 응용 프로그램에 대한 데이터의 종속성
- 예, 파일 시스템
- 응용 프로그램과 데이터가 상호 의존적
- 데이터를 저장한 파일 구조가 변경되면 이에 대응되는 응용 프로그램도 변경되어야 함
-
데이터 독립성
- 데이터 구조가 변경되어도 응용 프로그램이 변경될 필요가 없음
- 논리적 독립성 + 물리적 독립성으로 실현됨
- 논리적 독립성 : 외부-개념 스키마 사이의 독립성
- 물리적 독립성 : 개념-내부 스키마 사이의 독립성
-
데이터 독립성이 유지되지 않으면?
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) 예시__
__좋은 데이터 모델__