데이터 모델의 이해
모델링의 정의
- 복잡한 현실세계를 단순화시켜 표현한 것.
- 사물과 사건에 대한 양상(Aspect)나 관점(Perspective)을 연관된 사람이나 그룹을 위해 명확하게 하는 것
- 현실세계 추상화 하여 반영 한 것.
모델링의 특징
- 추상화 : 현실세계의 일정한 형식에 맞추어 표현을 한다는 의미
- 단순화 : 복잡한 현실세계의 약속된 규약에 의해 제한된 표기법이나 언어로 표현
- 명확화 : 누구나 이해하기 쉽게 하기위해 대상을 정확하게 현상하는 기술
모델링의 세가지 관점
- 데이터 관점 : 업무가 어떤 데이터와 관련이 되어 있는지, 데이터간의 관계는 무엇인지에 대해서 모델링하는 것.
- 프로세스 관점 : 업무가 실제하고 있는 일은 무엇인지 또는 무엇을 해야 하는지를 모델링하는 것.
- 상관 관점 : 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지 모델링하는 방법.
데이터 모델링의 정의
- 정보 시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
- 현실세계의 데이터에 대해 약속된 표기법으로 표현하는 과정
- 데이터베이스를 구축하기 위한 분석/설계 과정
데이터 모델이 제공하는 기능
- 시스템을 현재 또는 원하는 모습으로 가시화
- 시스템의 구조화 행동을 명세화
- 시스템을 구축하는 구조화된 틀을 제공
- 시스템을 구축하는 과정에서 결정하는 것을 문서화
- 다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점을 제공.
- 특정 목표에 따라 구체화된 상세 수준의 표현방법을 제공.
데이터 모델링의 중요성 및 유의점
- 파급효과 : 시스템 구축 작업 중에서 다른 어떤 설계 과정보다 데이터 설계가 중요함.
- 복잡한 정보 요구사항의 간결한 표현 : 데이터 모델은 구축할 시스템의 정보 요구사항과 한계를 가장 명확하고 간결하게 표현하는 도구.
- 데이터 품질 : 데이터의 중복, 비 유연성, 비 일관성이 발생할 수 있음.
데이터 모델링의 3단계 진행
- 개념적 데이터 모델링 : 추상화 수준이 높고 업무 중심적임. 포괄적인 수준의 모델링을 진행. 전사적 데이터 모델링, EA 수립시 많이 사용.
- 논리적 데이터 모델링 : 시스템으로 구축하고자 하는 업무에 대해 key, 속성, 관계 등을 정확하게 표현, 재 사용성이 높음.
- 물리적 데이터 모델링 : 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계.
프로젝트 생명주기에서 데이터 모델링
- 프로젝트 생명 주시는 정보전략계획 -> 분석 -> 설계 -> 개발 -> 테스트 -> 전환/이행 단계 존재.
- 정보전략계획/분석 단계 : 개념적 데이터 모델링.
- 분석 단계 : 논리적 데이터 모델링.
- 설계 단계 : 물리적 데이터 모델링.
데이터 독립성의 필요성
- 지속적으로 증가하는 유지보수 비용을 절감하고 데이터 복잡도를 낮추며 중복된 데이터를 줄이기 위한 목적이 있음.
- 끊임없이 요구되는 사용자 요구사항에 대해 화면과 데이터베이스 간의 독립성을 유지하기 위한 목적으로 데이터 독립성의 개념이 출현.
데이터베이스 3단계 구조
ANSI/SPARC의 3단계 구성의 데이터독립성 모델은 외부 단계와 개념적 단계, 내부적 단계로 구성된 되고, 서로 간섭이 되지 않는 모델을 제시하고 있다.
- 외부 스키마 (External Schema) : 사용자 관점에서 보는 DB 스키마를 구성. 개별적인 스키마가 생성 되는 단계.
- 개념 스키마 (Conceptula Schema) : 통합적인 관점에서 보는 DB 스키마를 구성. 외부 스키마를 하나의 통합적인 스키마로 구성.
- 내부 스키마 (Internal Schema) : 물리적인 관점에서 보는 DB 스키마를 구성. 실제로 데이터 베이스에 저장되는 스키마를 구성.
데이터베이스 3단계 구조에서의 데이터 독립성
- 논리적 독립성 : 개념 스키마가 변경이 되어도 외부 스키마에는 영향이 미치면 안됨.
- 물리적 독립성 : 내부 스키마가 변경되어도 외부/개념 스키마는 영향을 받지 않아야 함.
데이터베이스 3단계 구조에서의 사상 매핑
- 외부적/개념적 사상(논리적 사상) : 외부적 뷰와 개념적 뷰의 상호 호환성을 정의함.
- 개념적/물리적 사상(물리적 사상) : 개념적 뷰와 저장된 데이터베이스의 상호 관련성을 형성.
데이터 모델링 용어
| 개념 | 복합/집합 개념 타입/클래스 |
개별/단수 개념 어커런스/인스턴스 |
| 어떤 것(Thing) | 엔티티 타입(Entity Type) | 엔티티(Entity) |
| 엔티티(Entity) | 인스턴스(Instance) 어커런스(Occurrence) |
|
| 관계(Relationship) | 관계(Relationship) | 페어링(Pairing) |
| 성격(Attribute) | 속성(Attribute) | 속성 값(Attribute Value) |
데이터 모델링 작업 순서
- 엔티티를 그린다.
- 엔티티를 적절하게 배치한다.
- 엔티티 간 관계를 설정한다.
- 관계명을 기술한다.
- 관계의 참여도를 기술한다.
- 관계의 필수 여부를 기술한다.
데이터 모델링의 이해관계자
- 정보시스템을 구축하는 사람은 완성된 모델을 정확하게 해석할 수 있어야 한다.
- 업무에서 정보화를 추진하는 위치에 있는 사람도 데이터 모델링에 대한 개념 및 세부사항에 대해 어느 정도 지식을 함유하고 있어야 한다.
좋은 데이터 모델의 요소
- 완전성 : 업무에 필요한 데이터가 모두 정의되어야 함.
- 중복 배제 : 동일한 사실은 한 번만 저장해야 됨.
- 업무 규칙 : 데이터 모델 분석만으로도 비즈니스 로직이 이해되어야 함.
- 데이터 재사용 : 데이터 통합성과 독립성을 고려해야 함.
- 의사소통 : 데이터 모델을 보고 이해 당사자들끼리 의사소통이 이루어져야 함.
- 통합성 : 동일한 데이터는 유일하게 정의해서 다른 영역에서 참조해야 함.
엔티티(Entity)
엔티티의 개념
- 엔티티는 사람, 장소, 사건, 개념 등의 명사에 해당한다.
- 업무상 관리가 필요한 관심사에 해당한다.
- 저장되기 위한 어떤 것(Thing)을 의미한다.
- 엔티티는 인스턴스의 집합이라고 할 수 있다.
엔티티의 특징
- 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
- 유일한 식별자에 의해 식별이 가능해야 한다.
- 영속적으로 존재하는 인스턴스의 집합 이어야 한다. (두 개 이상의 인스턴스를 가져야 함.)
- 엔티티는 업무 프로세스의 의해 이용되어야 한다.
- 엔티티는 반드시 속성이 있어야 한다.
- 엔티티는 다른 엔티티와 최소 한 개 이상의 관계가 있어야 한다. (개념상으로 존재하는 원칙, 실제로는 없이도 가능함. )
유무형에 따른 분류
- 유형 (사원, 물품, 강사) : 물리적인 형태가 있고 안정적이며 지속적으로 활용하는 엔티티.
- 개념 (조직, 보험상품) : 물리적인 형태는 없으나 개념적 정보로 구분이 되는 엔티티.
- 사건 (주문, 청구, 미납) : 업무를 수행함에 따라 발생되는 엔티티.
발생시점에 따른 분류
- 기본 (키 : 고객, 상품) : 업무에 근본이 되는 정보로서 다른 엔티티와 관계에 의해 생성되지 않고 독립적으로 생성이 가능함.
- 중심 (메인 : 주문, 배송) : 기본 엔티티로부터 생성이 되고, 그 업무에 있어서 중심적인 역할을 수행.
- 행위 (액션 : 주문변경이력) : 두 개 이상의 부모엔티티로부터 발생되고 자주 내용이 바뀌거나 데이터량이 증가.
속성(Attribute)
속성의 개념
- 업무에서 필요로 한다.
- 의미상 더 이상 분리되지 않는다.
- 엔티티를 설명하고 인스턴스의 구성요소가 된다.
엔티티, 인스턴스, 속석, 속성값의 관계
- 한 개의 엔티티는 두 개 이상의 인스턴스의 집합이어야 한다.
- 한 개의 인스턴스는 두 개 이상의 속성을 가진다.
- 한 개의 속성은 한 개의 속성값을 가진다.
속성의 특징
- 해당 업무에서 필요하고 관리하고자 하는 정보 이어야 한다.
- 정규화 이론에 근간하여 정해진 주 식별자에 함수적 종속성을 가져야 한다.
- 하나의 속성에는 한 개의 값만을 가져야 한다.
속성의 분류 - 특성에 따른 분류
- 기본속성 (Basic Attribute) : 업무 분석을 통해 바로 정의한 속성.
- 설계속성 (Designed Attribute) : 원래 업무상에 존재하지는 않으나, 설계를 하면서 도출해 내는 속성.
- 파생속성 (Derived Attribute) : 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성.
속성의 분류 - 엔티티 구성 방식에 따른 분류
- 기본키(PK) : 엔티티를 식별할 수 있는 속성.
- 외래키(FK) : 다른 엔티티와 관계에서 포함된 속성.
- 일반 속성 : 엔티티에 포함되어 있고, PK, FK 에는 포함되어져 있는 않은 속성.
도메인(Domain)
- 각 속성은 가질 수 있는 값의 범위를 정의할 수 있는데 이것을 도메인이라고 함.
- 학생이라는 엔티티 내에서 점수라는 속성은 0.00 ~ 4.5 사이의 실수 값을 가질 수 있음. 주소 속성은 길이가 20자 이내의 문자열만 가질 수 있음.
속성의 명명
- 해당 업무에서 사용하는 이름을 부여한다.
- 서술식 속성명은 사용하지 않는다.
- 약어 사용은 가급적 제한한다.
- 전체 데이터모델에서 유일성 확보하는 것이 좋다.
관계(Relationship)
관계의 정의
- 엔티티 간의 논리적인 연관성을 의미한다.
- 존재에 의한 관계와 행위에 의한 관계로 구분된다.
관계의 페어링
- 엔티티 내에 존재하는 인스턴스가 개별적으로 관계를 가지는 것을 의미한다.
- 이러한 집합을 관계로 표현한 것이다.
- 인스턴스들은 자신이 관련된 인스턴스들과 관계의 어커런스(발생, 사건)로 연관된 형태를 관계 페어링이라고 함.
관계의 분류 - 존재에 의한 관계
사원은 부서에 항상 속해 있다.
관계의 분류 - 행위에 의한 관계
주문은 고객이 주문할 때 발생 한다.
관계의 표기법
| 개념 | 설명 |
| 관계명 | 관계의 이름 |
| 관계차수 | 1:1, 1:M, M:M |
| 관계의 선택사항 | 필수관계, 선택관계 |
관계의 표기법 - 관계명
- 엔티티 간의 관계에 참여하는 형태를 지칭한다.
- 하나의 관계에서는 두 개의 관계명을 가질 수 있다. 즉 각각의 엔티티에서 바라보는 관계의 관점으로 정의가 가능하다.
- 엔티티에서 관계가 시작되는 편을 관계시작점이라고 부르고 받는 편은 관계끝점이라고 부른다.
- 관계 시작점과 끝점 모두 관계이름을 가져야 하며 참여자의 관점에 따라 관계 이름을 능동적이거나 수동적으로 명명된다.
관계의 명명 규칙
- 애매한 동사를 피한다.
- 현재형으로 표현한다.
관계의 표시법 - 관계차수
- 두 개의 엔티티 간 관계에서 참여자의 수를 표현하는 것을 관계 차수라고 한다.
- 가장 일반적인 관계 차수 표현방법은 1:1, 1:M, M:M이다.
관계의 표시법 - 관계선택사항
"반드시 지하철의 문이 닫혀야만 지하철은 출발한다"
- "지하철 출발"과 "지하철 문 닫힘"은 필수적으로 연결 관계가 있는 것이다.
- 이와 같은 것이 데이터 모델의 관계에서는 필수참여관계가 된다.
"지하철 출발 그리고 출발 시에 안내방송이 나온다"
- 지하철 출발을 알리는 안내방송은 출발에는 영향을 주지 않으므로 선택적인 관계를 가진다.
- 이와 같은 것이 데이터 모델 관계에서는 선택참여관계가 된다.
관계 읽기
- 기준 엔티티를 한 개 또는 각각으로 읽는다.
- 대상 엔티티의 관계 참여도, 즉 개수를 읽는다.
- 관계선택사항과 관계명을 읽는다.
식별자
식별자 개념
- 여러 개의 집합체를 담고 있는 하나의 엔티티에서 각각의 인스턴스들을 구분할 수 있는 논리적인 이름.
- 즉, 엔티티 내의 각 인스턴스를 개별적으로 식별하기 위해 사용된다.
식별자의 특징
- 유일성 : 주식별자에 의해 엔티티 내의 모든 인스턴스들을 구부하여야 함.
- 최소성 : 주식별자를 구분하는 속성의 수는 유일성을 만족하고 최소한의 속성 개수를 사용하여야 함.
- 불변성 : 주식별자가 한 번 특정 엔티티에 지정되면 그 식별자의 값은 변하지 않아야 함.
- 존재성 : 주식별자가 지정되면 반드시 데이터 값이 존재해야 함.
식별자의 분류
| 분류 | 식별자 | 설명 |
| 대표성 여부 | 주식별자 | 엔티티 내에서 각 인스턴스들을 구분 할 수 있는 식별자. |
| 보조식별자 | 각 행을 구분할 수 있는 구분자이긴 하나 대표성을 가지지 못한 식별자. | |
| 자동 생성 여부 | 내부식별자 | 엔티티 내부에서 자동으로 생성되는 식별자. |
| 외부식별자 | 타 엔티티와의 관계를 통해 얻어오는 식별자(외래키). | |
| 속성의 수 | 단일식별자 | 하나의 속성으로 구분 되는 식별자. |
| 복합식별자 | 여러 개의 속성으로 구분 되는 식별자. | |
| 대체여부 | 본질식별자 | 업무에 의해 만들어 지는 식별자. |
| 인조식별자 | 필요에 따라 인위적으로 만들어 지는 식별자. |
식별자 도출 기준
- 해당 업무에서 자주 이용되는 속성을 주식별자로 사용.
- 명칭, 내역 등과 같이 이름으로 기술되는 것들은 식별자로 사용하지 않는다.
- 복합으로 주식별자를 구성할 경우 너무 많은 속성이 포함되지 않도록 한다.
식별자관계와 비식별자 관계의 결정
- 외부 식별자를 받는 엔티티가 있다고 하면은 그 외부 식별자를 주식별자로 사용할 것인지 아니면 부모 엔티티와 연결관계를 유지하는 속성으로 사용할지 결정해야 함.
식별자 관계
- 자식 엔티티의 주식별자로 부모 엔티티의 주식별자를 상속받는 경우를 말함.
비식별자 관계
- 부모 엔티티로부터 속성을 부여받았지만은 자식 엔티티에서 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우를 말함.
식별자 관계로만 설정할 경우의 문제점
- 지속적으로 식별자 관계를 연결한 경우, 데이터 모델의 흐름이 길어질수록 다음 자식 엔티티가 가지는 식별자의 수는 늘어남.
- 개발의 복잡성과 오류가능성을 유발할 수 있는 요인이 될 수 있다는 문제점을 가짐.
'Backend > DataBase' 카테고리의 다른 글
| SQLD 최적화 (0) | 2023.11.08 |
|---|---|
| SQL 활용 (0) | 2023.11.07 |
| SQL 기본 (1) | 2023.11.07 |
| SQL vs NoSQL (1) | 2023.11.03 |
| 데이터 모델링과 성능 (1) | 2023.11.02 |