1. 데이터 모델의 이해
- 모델링이란?
현실 세계를 단순화하여 표현하는 기법
- 모델링이 갖춰야 할 조건
(1) 현실 세계를 반영해야 한다
(2) 단순화하여 표현해야 한다
(3) 관리하고자 하는 데이터를 모델로 설계한다
- 모델링의 특징
(1) 추상화
: 현실 세계를 일정한 형식으로 표현하는 것. 아이디어나 개념을 간략하게 표현하는 과정
(2) 단순화
: 복잡한 현실 세계를 정해진 표기법으로 단순하고 쉽게 표현한다는 의미
(3) 명확화
: 불분명함을 제거하고 명확하게 해석할 수 있도록 기술
- 모델링의 세 가지 관점
1. 데이터 관점
: 데이터 위주의 모델링. 어떤 데이터들이 업무와 얽혀있는지, 데이터 간의 어떤 관계가 있는지에 대해 모델링하는 방법
2. 프로세스 관점
: 이 업무가 실제로 처리하고 있는 일은 무엇인지 or 앞으로 처리해야 하는 일은 무엇인지 모델링하는 방법
3. 데이터와 프로세스의 상관 관점
: 프로세스의 흐름에 따라 데이터가 어떤 영향을 받는지를 모델링하는 방법
- 데이터의 품질을 보장하기 위해 유의해야 할 사항
1. 중복 : 같은 언어가 여러 엔티티에 중복으로 저장되는 현상을 지양해야 함
2. 비유연성 : 데이터 모델의 설계에 따라 애플리케이션의 사소한 변경에도 데이터 모델이 수시로 변경되어야 할 수 있음. 이러한 상황은 유지보수에 어려움을 증가시키기 때문에 데이터 모델과 프로세스를 분리하여 유연성을 높이는 것이 바람직함
3. 비일관성 : 데이터의 중복이 없는 경우에도 비일관성이 발생할 수 있다. 다른 데이터와의 연관성을 고려하지 않고 일부 데이터만 변경할 수 있기 때문. 이러한 위험을 예방하기 위해 데이터 간의 연관 관계에 대해 명확하게 정의해야 함
- 모델링의 세 가지 단계
1. 개념적 데이터 모델링
: 전사적 데이터 모델링 수행 시 행해짐. 추상화 레벨이 가장 높은모델링. 업무 중심적이고 포괄적인 수준의 모델링이 진행됨
2. 논리적 데이터 모델링
: 재사용성이 가장 높은 모델링. 모델에 대한 key, 속성, 관계 등을 모두 표현하는 단계
3. 물리적 데이터 모델링
: 실제 데이터베이스로 구현할 수 있도록 성능이나 가용성 등의 물리적인 성격을 고려하여 모델을 표현하는 단계
- 데이터의 독립성
ANSI-SPARC : DBMS의 추상적인 설계 표준. 이 아키텍쳐에서는 3단계 구조로 스키마를 나눔
1. 외부 스키마 (Externam Schema)
: Multiple users's view 단계로 사용자가 보는 데이터베이스의 스키마를 정의한다
2. 개념 스키마 (Conceptual Schema)
: Community View of DB 단계로 모든 사용자가 보는 데이터베이스의 스키마를 통합하여 전체 데이터베이스를 나타내는 것. 데이터베이스에 저장되는 데이터들을 표현하고 데이터들 간의 관계를 나타낸다
3. 내부 스키마 (Internal Schema)
: Physical Representation 단계로 물리적인 저장 구조를 나타낸다. 실질적인 데이터의 저장 구조나 컬럼 정의, 인덱스 등이 포함됨
- 3단계 스키마 구조가 보장하는 독립성
1. 논리적 독립성 : 개념 스키마가 변경되어도 외부 스키마는 영향받지 않는다
2. 물리적 독립성 : 내부 스키마가 변경되어도 외부/개념 스키마는 영향받지 않는다
- ERD
1. ERD 표기 방식
(1) Peter Chan : 주로 대학 교재에서 표기. 실무에서 사용하는 경우는 드물다
(2) IDEF1X : 실무에서 사용하는 경우도 있으며, ERWin에서 사용되는 모델
(3) IE/Crow's Foot : 까마귀발 표기법. 가장 많이 사용함.
(4) Min-Max/ISO : 각 엔터티의 참여도를 좀 더 상세하게 나타내는 표기법
(5) UML : 소프트웨어 공학에서 주로 사용되는 모델
(6) Case*Method/Barker : Oracle에서 사용되는 모델로 (3) 과 유사함
2. ERD 작성 순서
- 엔터티를 도출하고 그린다
- 엔터티를 적절하게 배치한다
- 엔터티 간의 관계를 설정한다
- 관계명을 기입한다
- 관계의 참여도를 기입한다
- 관계의 필수/선택 여부를 기입한다
2. 엔터티 (Entity)
: 식별이 가능한 객체
엔터티 = table, 인스턴스 = row, 속성 = column
- 엔티티의 특징
1. 업무에서 쓰이는 정보여야 함
2. 유니크함을 보장할 수 있는 식별자가 있어야 함
3. 2개 이상의 인스턴스를 가지고 있어야 함
4. 반드시 속성을 가지고 있어야 함
5. 다른 엔티티와 1개 이상의 관계를 가지고 있어야 함
- 엔티티의 분류
(1) 유형 vs 무형
1. 유형 엔티티 : 물리적인 형태 존재. 안정적, 기술적
2. 개념 엔티티 : 물리적인 형태 없음. 개념적
3. 사건 엔티티 : 행위를 함으로써 발생. 빈번함. 통계 자료로 이용 가능
(2) 발생 시점
1. 기본 엔티티 : 업무에 원래 존재하는 정보. 독립적으로 생성되며, 자식 엔티티를 가질 수 있음
2. 중심 엔티티 : 기본 엔티티로부터 파생되고, 행위 엔티티 생성/ 업무에 있어서 중심적인 역할을 하며 데이터의 양이 많이 발생
3. 행위 엔티티 : 2개 이상의 엔티티로부터 파생. 데이터가 자주 변경되거나 증가할 수 있음
- 엔티티 이름 정할 때 주의할 점
1. 업무에서 실제로 쓰이는 용어 사용
2. 한글은 약어를 사용하지 않고 영문은 대문자로 표기
3. 단수 명사로 표현하고 띄어쓰기는 하지 않음
4. 다른 엔티티와 의미상으로 중복될 수 없음
5. 해당 엔티티가 갖고 있는 데이터가 무엇인지 명확하게 표현
3. 속성 (Attribute)
: 사물이나 개념의 특징을 설명해줄 수 있는 항목들. 엔티티의 특징을 나타내는 최소의 데이터 단위. 더 이상 쪼개지지 않는 레벨이어야 하고 프로세스에 필요한 항목이어야 한다.
- 속성값
: 엔티티에 속한 하나의 인스턴스를 구체적으로 나타내주는 데이터
하나의 속성은 한 개의 속성값만 가질 수 있다. 하나의 속성이 여러 개의 속성값을 갖는 경우 별도의 엔티티로 분리하는 것이 바람직.
- 엔티티, 인스턴스, 속성, 속성값의 관계
엔티티 > 인스턴스 > 속성
1. 한 개의 엔티티는 두 개 이상의 인스턴스를 갖는다
2. 한 개의 인스턴스는 두 개 이상의 속성을 갖는다
3. 한 개의 속성은 하나의 속성값을 갖는다
- 분류
1. 특성에 따른 분류
(1) 기본 속성 : 업무 프로세스 분석을 통해 바로 정의가 가능한 속성
(2) 설계 속성 : 업무에 존재하지는 않지만 설계하다 보니 필요하다고 판단되어 도출해낸 속성. 인위적임!
(3) 파생 속성 : 다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성. 데이터 조회 시 빠른 성능을 보장하기 위해 본래의 속성값을 계산하여 따로 저장할 수 있도록 만든 속성
2. 구성방식에 따른 분류
(1) PK 속성 : 엔티티의 인스턴스들을 식별할 수 있는 속성. 각 인스턴스에 유니크함을 부여
(2) FK 속성 : 다른 엔티티의 속성에서 가져온 속성. 다른 엔티티와 관계를 맺게 해주는 매개채 역할을 하는 속성
(3) 일반 속성 : PK, FK를 제외한 나머지 속성
- 도메인
: 속성이 가질 수 있는 속성값의 범위
- 용어사전
: 속성의 이름을 정확하면서도 직관적으로 부여하고 용어의 혼란을 없애기 위한 것
- 시스템 카탈로그
: 사용자 테이블과는 별개로 시스템 자체에 관련이 있는 데이터를 담고 있는 데이터베이스. 시스템 테이블로 구성되어 있어 SQL을 이용하여 조회할 수 있음.
4. 관계 (Relationship)
: 엔티티와 엔티티와의 관계. 어떠한 연관성이 있는지 타입을 분류하여 존재 관계와 행위 관계로 나눌 수 있다
- 존재 관계 : 엄마와 아기처럼 존재 자체로 연관성이 있는 관계
- 행위 관계 : 특정한 행위를 함으로써 연관성이 생기는 관계
- 표기법
(1) 관계명 (Membership) : 관계의 이름. 엔티티와 엔티티가 어떠한 관계를 맺고 있는지를 나타내주는 문장. 반드시 명확한 문장으로 표현해야 하며 현재형이여야 함.
(2) 관계차수 (Cardinality) : 관계에 참여하는 수. 1:1, 1:M, M:N 형식으로 구분
- 1:1 관계 (회원 - 회원 상세)
- 1:M 관계 (상품 - 상품가격 이력)
- N:M 관계 (학생 - 수강생)
(3) 관계선택사양 (Optionality) : 필수인지 선택인지의 여부
- 필수적 관계 : 참여자가 반드시 존재해야 하는 관계
- 선택적 관계 : 참여자가 없을 수도 있는 관계
5. 식별자 (Identifiers)
: 각각의 인스턴스를 구분 가능하게 만들어주는 대표격인 속성
- 주식별자 : 기본키에 해당하는 속성. 하나의 속성이 주식별자가 될 수도 있고 여러 개의 속성이 주식별자가 될 수도 있다. 유일성을 보장하는 최소 개수의 속성이어야 함.
(1) 유일성 : 각 인스턴스에 유니크함을 부여하여 식별이 가능하도록 한다
(2) 최소성 : 유일성을 보장하는 최소 개수의 속성이어야 한다
(3) 불변성 : 속성값이 되도록 변하지 않아야 한다
(4) 존재성 : 속성값이 NULL일 수 없다
- 분류
1. 대표성 여부
(1) 주식별자 (Primary Identifier)
: 유일성, 최소성, 불변성, 존재성을 가진 대표 식별자
: 다른 엔티티와 참조 관계로 연결
(2) 보조 식별자 (Alternate Identifier)
: 인스턴스를 식별할 수는 있지만 대표 식별자가 아님
: 다른 엔티티와 참조 관계로 연결되지 않음
2. 스스로 생성되었는지 여부
(1) 내부 식별자 (Internal Identifier)
: 엔티티의 내부에서 스스로 생성된 식별자
(2) 외부 식별자 (Foreign Identifier)
: 다른 엔티티에서 온 식별자, 다른 엔티티와의 연결고리 역할
3. 단일 속성의 여부
(1) 단일 식별자 (Single Identifier) : 하나의 속성으로 구성된 식별자
(2) 복합 식별자 (Composite Identifier) : 두 개 이상의 속성으로 구성된 식별자
4. 대체 여부
(1) 원조 식별자 (Original Identifier) : 업무 프로세스에 존재하는 식별자. 가공되지 않은 원래의 식별자 (본질식별자)
(2) 대리 식별자 (Surrogate Identifier) : 주식별자의 속성이 두 개인 경우 그 속성들을 하나로 묶어서 사용하는 식별자 (인조식별자)
- 식별자 관계 : 부모 엔티티의 식별자가 자식 엔티티의 주식별자가 되는 관계. 주식별자는 반드시 존재해야 하므로 (존재성) 부모 엔티티가 있어야 생성 가능. 단일식별자인지 복합식별자인지에 따라 1:1이거나 1:M이 결정된다
- 비식별자 관계 : 부모 엔티티의 식별자가 자식 엔티티의 주식별자가 아닌 일반 속성이 되는 관계. 일반 속성의 값은 null이 될 수 있으므로 부모 엔티티가 없는 자식 엔티티 생성이 가능하고 자식 엔티티가 존재하는 상태에서 부모 엔티티가 삭제될 수도 있다.