1. 모델링이란?
현실 세계를 단순화하여 표현하는 기법
현실 세계에서 필요한 데이터를 저장하는 데이터베이스를 구축하기 위한 분석/설계의 과정
현실 세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현하는 기법
2. 모델링의 특징
추상화(Abstraction)
현실 세계를 일정한 형식으로 표현, 아이디어나 개념을 간략히 표현
단순화(Simplification)
정해진 표기법으로 단순하고 쉽게 표현
명확화(Clarity)
명확하게 해석할 수 있도록 기술
3. 모델링의 세 가지 관점
데이터 관점(What, Data)
데이터 위주 모델링
프로세스 관점(How, Process)
프로세스 위주 모델링
데이터와 프로세스의 상관 관점(Data vs Process, Interaction)
데이터와 프로세스의 관계를 위주로 한 모델링, 프로세스의 흐름에 따라 데이터가 어떤 영향을 받는지를 모델링하는 방법이다.
4. 모델링의 세 가지 단계
개념적 데이터 모델링(Conceptual Data Modeling)
전사적 데이터 모델링 수행 시 행해지며 추상활 레벨이 가장 높은 모델링. 업무 중심적이고 포괄적인 수준의 모델링
논리적 데이터 모델링(Logical Data Modeling)
재사용성이 가낭 높은 모델링, Key, 속성, 관계 등을 모두 표현하는 단계
물리적 데이터 모델링(Physical Data Modeling)
실제 구현할 수 있도록 성능이나 가용성 등의 물리적인 성격을 고려하여 표현하는 단계
5. 데이터의 독립성
ANSI-SPARC 아키텍처(데이터베이스 관리 시스템(DBMS)의 추상적인 설계 표준)에서는 데이터베이스에 대한 사용자들의 관점과 데이터베이스가 실제로 표현되는 물리적인 방식을 분리하기 위해 스키마를 3단계 구조로 나눈다. 사용자 입장에서는 데이터베이스의 내부 구조에 대해 굳이 알 필요가 없고, DBA 입장에서는 어플리케이션에 영향을 주지 않고 데이터베이스의 구조를 변경할 수 있어야 독립성이 보장된다고 할 수 있다.
5-1. 3단계 스키마 구조
외부 스키마(External Schema)
사용자의 관점(Multiple User's View 단계), 각 사용자가 보는 데이터베이스의 스키마를 정의(View 단계로 여러 개의 사용자 관점으로 구성되는 것)
DB의 각 사용자나 응용 프로그래머가 접근하는 DB의 정의이다.
개념 스키마(Conceptual Schema)
통합된 관점(Community View of DB 단계), 모든 사용자가 보는 데이터베이스의 스키마를 통합하여 전체 데이터베이스를 나타내는 것이다. 데이터베이스에 저장되는 데이터들을 표현하고 데이터들 간의 관계를 나타낸다.
내부 스키마(Internal Schema)
물리적인 관점(Physical Representation 단계), 물리적인 저장 구조. 실질적인 데이터의 저장 구조나 컬럼 정의, 인덱스 등이 포함된다.
5-2. 3단계 스키마 구조가 보장하는 독립성
논리적 독립성
개념 스키마가 변경되어도 외부 스키마는 영향받지 않는다.
물리적 독립성
내부 스키마가 변경되어도 외부/개념 스키마는 영향받지 않는다.
6. ERD(Entity Relationship Diagram)
시스템에 어떤 엔티티들이 존재하며 그들 간에 어떤 관계가 있는지를 나타내는 다이어그램이다.
6-1. 표기방식
Peter Chen
IDEF1X(Integration Definition for Information Modeling)
IE/Crow's Foot
(가장 많이 사용)🔺 이미치 출처 : https://ppomelo.tistory.com/51
Min-Max/ISO
UML
CaseMethod/Barker
6-2. 작성순서
- Entity를 도출하고 그린다.
- Entity 적절하게 배치한다.
- Entity 간의 관계를 설정한다.
- 관계명을 기입한다.
- 관계의 참여도를 기입한다.
- 관계의 필수/선택 여부를 기입한다.
plus! 시스템 분석을 위한 모델링의 기능
- 시스템이 향후 변화하고자 하는 모습으로 가시화 해준다.
- 시스템을 구축하는 과정에서 결정한 것을 문서화한다.
- 시스템을 구축하는 구조화된 틀을 제공한다.
- 시스템의 구조와 행동을명세화 해준다.
2. Entity
1. Entity란?
독립체, 데이터베이스에서는 식별이 가능한 객체. 쉽게 말하면 업무에서 쓰이는 데이터를 용도별로 분류한 그룹
🔺 이미지 출처 : https://blog.naver.com/clsrnclsrn95/222069240916
2. Entity 특징
- 업무에서 쓰이는 정보여야 한다.
- 유니크함을 보장할 수 있는 식별자가 있어야 한다.
- 2개 이상의 인스턴스를 가지고 있어야 한다.
- 반드시 속성을 가지고 있어야 한다.
- 다른 엔터티와 1개 이상의 관계를 가지고 있어야 한다.
3. Entity 분류
유형vs무형에 따른 분류
종류 설명 유형 Entity 물리적인 형태 존재, 안정적, 지속적 (ex 상품, 회원 등) 개념 Entity 물리적인 형태 없음, 개념적 (ex 부서, 학과 등) 사건 Entity 행위를 함으로써 발생, 빈번함, 통계 자료로 이용 가능 (ex 주문, 이벤트 응모 등)
발생시점에 따른 분류
종류 설명 기본 Entity 독립적으로 생성됨, 자식 엔터티를 가질 수 있음 (ex 상품, 회원 등) 중심 Entity 기본 엔터티로부터 파생, 행위 엔터티 생성 (ex 주문 등) 행위 Entity 2개 이상의 엔터티로부터 파생 (ex 주문 내역, 이벤트 응모 이력 등)
발생시점에 따른 분류 예시
"Student"를 중심 엔터티로 가정하고 설명
- 기본 엔터티: "Person" (개인)
- 중심 엔터티: "Student" (학생), "Faculty" (교직원)
여기서 "Person"은 기본 엔터티이며, "Student"와 "Faculty"는 "Person"에서 파생된 엔터티이다. "Person" 엔터티는 모든 사람을 대표하며, "Student" 엔터티는 학생들을, "Faculty" 엔터티는 교직원을 나타낸다.
- 행위 엔터티: "Enrollment" (수강 신청)
"Enrollment"는 "Student"와 "Course" 간의 관계를 표현한 행위 엔터티이다. "Enrollment" 엔터티는 어떤 학생이 어떤 과목을 수강하는지를 나타내며, 이는 "Student"와 "Course" 엔터티 간의 관계에 의해 발생한다.
tip. 엔터티의 이름을 정할 때 주의
- 업무에서 실제로 쓰이는 용어
- 한글은 약어 사용 X, 영문은 대문자 표기
- 단순 명사 표기, 띄어쓰기 사용 X
- 다른 엔터티와 의미상으로 중복 될 수 없음
- 명확하게 표현해야 함
3. 속성(Attribute)
1. 속성이란?
사물이나 개념의 특징을 설명해줄 수 있는 항목들
엔터티의 특징을 나타내는 최소의 데이터 단위
더 이상 쪼개지지 않는 레벨로 프로세스에 필요한 항목
2. 속성값
하나의 속성은 한 개의 속성값만 가질 수 있다.
3. Entity, Instance, 속성, 속성값의 관계
- 한 개의 엔터티는 두 개 이상의 인스턴스를 갖는다.
- 한 개의 인스턴스는 두 개 이상의 속성을 갖는다.
- 한 개의 속성은 하나의 속성값을 갖는다.
4. 분류
- 특성에 따른 분류(속성의 성격이나 특징에 따른 분류)
- 기본속성(Basic Attribute)
- 업무 프로세스 분석을 통해 바로 정의가 가능한 속성
- 가장 많은 퍼센티지를 차지하는 속성
- 설계속성(Designed Attribute)
- 업무에 존재하지는 않지만 설계하다 보니 필요하다고 판단되어 도출해낸 속성
- 파생속성(Derived Attribute)
- 다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성
- 기본속성(Basic Attribute)
- 구성방식에 따른 분류
- PK(Primary Key)속성
- 엔터티의 인스턴스들을 식별할 수 있는 속성
- 유니크함 부여
- FK(Foreign Key)속성
- 다른 엔터티의 속성에서 가져온 속성
- 다른 엔터티와 관계를 맺게 해주는 매게체 역할
- 다른 엔터티의 PK값과 일치하거나 NULL 값을 가질 수도 있다.
- 일반속성
- PK, FK를 제외한 나머지 속성
- PK(Primary Key)속성
5. Domain
속성이 가질 수 있는 속성값의 범위, 데이터 타입과 크기로 나타낼 수 있다.
tip. 용어사전
엔터티의 속성명을 정의할 때 명확한 의미의 이름을 부여하고 다른 엔터티와의 혼란을 예방하기 위해 용어사전을 두고 공통된 룰로 적용한다.
4. 관계(Relationship)
1. 관계란?
엔터티와 엔터티와의 관계
2. 연관성에 따른 타입 분류
- 존재 관계
- 존재 자체로 연관성이 있는 관계
- 직원과 부서, 학생과 학과 등
- 행위 관계
- 특정한 행위를 함으로써 연관성이 생기는 관계
- 회원과 주문, 학생과 출석부 등
2. 표기법
- 관계명(Membership)
- 관계의 이름
- 모든 관계는 두 개의 관계명을 가지고 있는데 각 엔터티의 관점에서 관계명을 하나씩 가지기 때문이다.
- 명확하고 현재형으로 표현
- 관계차수(Cardinality)
- 관계에 참여하는 수
- 1:1, 1:M, M:N 형식으로 구분
- 관계선택사양(Optionality)
- 필수적 관계 : 참여자가 반드시 존재해야 하는 관계
- 선택적 관계 : 참여자가 없을 수도 있는 관계
5. 식별자(Identifiers)
1. 식별자란?
각각의 인스턴스를 구분 가능하게 하는 대표 격인 속성의 의미한다.
2. 주식별자
기본키, PK에 해당하는 속성, 하나의 속성이 주식별자가 될 수도 있고 여러 개의 속성이 주식별자가 될 수도 있다.
- 유일성 : 각 인스턴스에 유니크함을 부여하여 식별이 가능하도록 한다.
- 최소성 : 유일성을 보장하는 최소 개수의 속성이어야 한다.
- 불변성 : 속성값이 되도록 변하지 않아야 한다.
- 존재성 : 속성값이 NULL일 수 없다.
3. 분류
🔺 이미지 출처 : https://tyrionlife.tistory.com/38
- 대표성 여부
종류 설명 주식별자
(Primary Identifier)유일성, 최소성, 불변성, 존재성을 가진 대표 식별자
다른 엔터티와 참조 관계로 연결보조식별자
(Alternate Identifier)인스턴스를 식별할 수는 있지만 대표 식별자가 아님
다른 엔터티와 참조 관계로 연결되지 않음
- 스스로 생성되었는지 여부
종류 설명 내부식별자
(Internal Identifier)엔터티 내부에서 스스로 생성된 식별자 외부식별자
(Foreign Identifier)다른 엔터티에서 온 식별자, 다른 엔터티와의 연결고리 역할
- 단일 속성의 여부
종류 설명 단일식별자
(Single Identifier)하나의 속성으로 구성된 식별자 복합식별자
(Composite Identifier)두 개 이상의 속성으로 구성된 식별자
- 대체 여부
종류 설명 원조시별자(본질식별자)
(Original Identifier)업무 프로세스에 존재하는 식별자, 가공되지 않은 원래의 식별자 대리식별자(인조식별자)
(Surrogate Identifier)주식별자의 속성이 두 개 이상인 경우 그 속성들을 하나로 묶어서 사용하는 식별자
4. 식별자 관계 vs 비식별자 관계
🔺 이미지 출처 : https://m.blog.naver.com/amabile29/221973568796
- 식별자 관계(Identification Relationship)
- 부모 엔터티의 식별자가 자식 엔터티의 주식별자가 되는 관계.
- 부모 엔터티가 있어야 생성 가능
- 단일 속성의 여부에 따라 1:1이거나 1:M
- 실선으로 표현
- 비식별자 관계(Identification Relationship)
- 부모 엔터티의 식별자가 자식 엔터티의 주식별자가 아닌 일반 속성이 되는 관계
- 일반 속성의 속성값은 NULL이 될 수 있으므로 부모 엔터티가 없는 자식 엔터티 생성이 가능하며 자식 엔터티가 존재하는 상태에서 부모 엔터티가 삭제될 수도 있다.
- 점선으로 표현
참고
'SQLD' 카테고리의 다른 글
03. SQL 기본 (0) | 2023.08.30 |
---|---|
02. 데이터 모델과 SQL (0) | 2023.08.28 |