Data Modeling
데이터 모델링
- 정보시스템 구축을 위해, 업무에 어떤 데이터가 존재하는지 업무에 필요한 정보는 무엇인지를 분석하는 방법이다.
- 데이터베이스를 구축하기 위한 분석 및 설계 과정이다.
- 현실세계를 추상화·단순화·명확화하여 일정한 체계로 표현해내는 과정을 의미한다.
- 현실세계의 여러 Aspect(측면)를 체계화하는 작업이다.
데이터 모델링의 특징
Abstraction (추상화)
- 현실세계를 일정한 형식에 맞추어 표현한다.
- 다양한 현상을 일정한 양식의 표기법에 따라 표현한다.
Simplification (단순화)
- 복잡한 현실세계를 약속된 규약에 의해 제한된 표기법이나 언어로 표현하여 누구나 쉽게 이해할 수 있도록 한다.
Clarification (명확화)
- 누구나 이해하기 쉽게 대상에 대한 애매모호함을 제거하고 정확하게 현상을 기술한다.
데이터 모델의 지향점
- 좋은 데이터 모델이 갖춰야 할 요소들로는 아래와 같은 것들이 있다.
Completeness (완전성)
- 업무에 필요한 모든 데이터가 모델로 정의되어 있어야 한다.
Non-Redundancy (중복 배제)
- 동일한 사실은 DB에 단 한 번만 기록되어 있어야 한다.
Business Rules (업무 규칙)
- 업무 상 규칙은 데이터 모델에 반영되어야 하고, 해당 데이터 모델을 활용하는 모두에게 공유되어야 한다.
Data Reusaility (데이터 재사용)
- Data는 Application에 독립적으로 설계되어야 중복이 최소화되고, 재사용성이 향상될 수 있다.
Communication (의사소통)
- 업무 규칙이 잘 반영된 데이터 모델은 구성원 간 의사소통의 도구가 된다.
Integration (통합성)
- 적절한 전사적 통합 데이터 모델을 활용하여 데이터 재사용성을 제고한다.
- 데이터 모델의 변화·확장에 유연히 대응하기 위해 데이터 통합이 수반되어야 한다.
데이터 모델링의 3요소
- 현실세계를 모델링할 때, "어떤 것", "속성(성격)", "관계"로 분류하여 모델링한다.
Entity (Thing)
- "어떤 것"에 해당되는 개념으로, 일반적으로 "Entity"로 표현한다.
Attribute (Characteristic of a Thing)
- "어떤 것의 성격"에 해당되는 개념으로, 일반적으로 "Attributes"로 표현한다.
Relationship (Association between Things)
- "어떤 것 간의 관계"에 해당되는 개념으로, 일반적으로 "Relationships"로 표현한다.
* 용어 정의
| 개념 | 개별·단수 표현 | 집합·복수 표현 |
| Thing | - Entity - Instance - Occurrence |
- Entity - Entity Type |
| Characteristic of a Thing | - Attribute Value | - Attribute |
| Association between Things | - Pairing | - Relationship |
Entity (엔터티, 실체, 객체)
- 사람, 장소, 물건, 사건, 개념 등에 해당되며, 업무상 관리가 필요한 대상이 엔터티로 저장된다.
* 적절한 Entity의 조건
- Entity는 해당 업무에서 필요로 하는 정보들로만 구성되어야 한다.
- Entity로 파생된 각각의 Instance들은 Unique Identifier를 통해 서로 유일하게 식별될 수 있어야 한다.
- Entity는 영속적으로 존재하는 2개 이상의 Instance로 구성되는 집합이어야 한다.
- 모든 Entity는 업무 프로세스에서 CRUD 작업에 의해 사용되어져야 한다.
- Entity는 Attribute를 가져야한다.
- Entity는 다른 Entity와 하나 이상의 Relationship으로 연관되어야 한다.
(단, 통계성 Entity, 코드성 Entity, 시스템 처리를 위한 Entity의 경우, 관계를 갖지 않을 수 있다.)
* Entity의 분류
| 유무형에 따른 분류 | Tangible Entity (유형 엔터티) |
- 물리적인 형태가 존재하는 개체를 모델링한 엔터티이다. ex) 사원, 물품, 강사 |
| Conceptual Entity (개념 엔터티) |
- 물리적 형태가 존재하지 않고, 관리해야 할 개념적인 정보를 모델링한 엔터티이다. ex) 조직, 보험상품 |
|
| Event Entity (사건 엔터티) |
- 업무 수행 중 발생될 수 있는 이벤트를 모델링한 엔터티로, 각종 통계자료에 활용될 수 있다. ex) 주문, 청구, 미납 |
|
| 발생시점에 따른 분류 | Fundamental Entity Key Entity (기본·키 엔터티) |
- 기존에 업무상에서 존재하던 정보에 대한 엔터티로, 타 엔터티와의 관계로 생성되지 않고, 독립적으로 생성이 가능하다. - 기본 엔터티는 타 엔터티의 Parent의 역할을 한다. ex) 사원, 부서, 고객, 상품, 자재 |
| Main Entity (중심 엔터티) |
- 기본 엔터티로부터 발생되는 엔터티로, 업무에서 중심적 역할을 한다. - 데이터가 많이 발생되는 엔터티이고, 타 엔터티와 관계를 통해 Active Entity(행위 엔터티)를 생성한다. ex) 계약, 사고, 예금원장, 청구, 주문, 매출 |
|
| Active Entity (행위 엔터티) |
- 둘 이상의 부모 엔터티로부터 발생되는 엔터티로, 내용 수정이 빈번하고 데이터 양이 점차 증가한다. _ 상세 설계 단계나 프로세스 상관모델링 진행 도중 도출될 수 있다. ex) 주문목록, 사원변경이력 |
|
| 생성방법에 따른 분류 | Independent Entity (독립 엔터티) |
- 스스로 생성될 수 있는 엔터티이며, Parent Entity가 될 수 있다. |
| Dependent Entity (의존 엔터티) |
- Parent Entity에 의해서만 생성될 수 있는 엔터티이다. |
* Entity Naming Tips
- 현업에서 사용하는 용어를 사용한다.
- 약어를 사용하지 않는다.
- 단수 명사를 사용한다.
- 각각의 엔터티에 유일한 이름을 부여한다.
- 이름에 의미를 녹여낸다.
Attribute (속성)
- Entity를 설명하고, 인스턴스의 구성요소가 되는, 의미상으로 더 이상 분리되지 않는(Atomic) 데이터이다.
- 각각의 Entity들은 2개 이상의 Attribute들을 갖는다.
- 하나의 Attribute는 하나의 Instance에만 존재할 수 있다.
- Attribute는 Relationship으로 기술될 수 없고, Attribute가 Attribute를 가질 수 없다.
* 적절한 Attribute의 조건
- 해당 업무에 필요한 정보이어야 한다.
- Normalization Theory에 근거하여, 정해진 Identifier에 Functional Dependency(함수적 종속성)을 가져야 한다.
- 하나의 Attribute는 하나의 Attribute Value(속성값)을 가진다.
(하나의 속성에 다중값이 존재할 수 있는 경우, 별도의 엔터티로 분리한다.)
* Attribute의 분류
| 특성에 따른 분류 |
Basic Attribute (기본 속성) |
- 업무 분석 과정에서 바로 도출되는 속성이다. |
| Designed Attribute (설계 속성) |
- 업무상 존재하지는 않지만, 설계 과정에서 도출되는 속성이다. - 업무상 필요한 데이터외에, 모델링을 위한, 업무의 규칙화를 위한 속성이다. ex) 일련번호 |
|
| Derived Attribute (파생 속성) |
- 다른 속성으로부터 계산·변형·생성되는 속성이다. - 데이터 정합성 유지를 위해, 가능한 파생속성을 적게 유지하는 것이 바람직하다. |
|
| 엔터티 구성방식에 따른 분류 |
Primary Key Attribute PK Attribute (PK 속성) |
- Entity를 유일하게 식별할 수 있게 하는 속성이다. |
| Foreign Key Attribute FK Attribute (FK 속성) |
- 다른 Entity와의 관계에 포함된 속성이다. | |
| General Attribute (일반 속성) |
- Entity에 포함되어 있으나, PK/FK에는 속하지 않는 속성들을 통칭한다. |
|
| 분할 여부에 따른 분류 |
Simple Attribute (단순 속성) |
- 세부적인 의미로 분할할 수 없는, Atomic한 속성이다. ex) 나이, 성별 |
| Composite Attribute (복합 속성) |
- 세부적인 의미로 분할할 수 있는 속성이다. ex) 주소 (시, 군, 동으로 분할 가능) |
|
| 값의 개수에 따른 분류 |
Single-Valued Attribute (단일값 속성) |
- 하나의 값만을 갖는 속성이다. ex) 주민등록번호 |
| Multi-Valued Attribute (다중값 속성) |
- 여러 개의 값을 가지는 속성이다. - 다중값 속성은 하나의 Entity에 포함될 수 없으므로 1차 정규화를 거치거나, 별도의 Entity로 분리되어야 한다. ex) 전화번호(집 전화, 회사 전화, 개인 전화로 동시에 존재 가능) |
* Domain
- 속성이 가질 수 있는 값의 범위를 의미한다.
- Entity 내에서 Attribute에 대한 Data Type과 크기, 제약사항 등을 도메인으로서 지정할 수 있다.
* Attribute Naming Tips
- 현업에서 사용하는 용어를 사용한다.
- 서술식 속성명, 소유격은 사용하지 않는다.
- 약어 사용을 지양한다.
- 가급적, 전체 데이터 모델에서 유일성을 확보한다.
Relationship (관계)
- Entity의 Instance들 사이의 논리적 연관성을 표현한 것을 의미한다.
* Relationship Pairing (관계 패어링)
- 각각의 Entity의 Instance들이 관련된 Instance들과 Relationship의 Occurence로 참여하는 형태를 지칭한다.
- Entity는 Instance들의 논리적 집합이고, Relationship은 Relationship Pairing의 논리적 집합이다.
* 관계의 분류
- 존재에 의한 관계 ex) 소속
- 행위에 의한 관계 ex) 주문
* Relationship Notation (관계 표기법)
| Membership (관계명) |
- 관계의 이름을 의미한다. |
| Degree/Cardinality (관계 차수) |
- 두 Entity간 관계에서 참여자의 수를 의미한다. - 0 : 0 (양쪽 Entity 모두 선택 참여 관계로 설정된 경우) - 1 : 1 - 1 : M - M : N (M : N 관계는 추후, 관계 엔터티를 이용해 3개의 엔터티로 분리하게된다.) |
| Optionality (관계 선택사양) |
* Mandatory Membership (필수 참여 관계) - 관계에 연관된 Entity의 Instance 모두가 관계에 참여해야 한다. * Optional Membership (선택 참여 관계) - 관계에 연관된 Entity의 Instance 중 일부만 관계에 참여해도 된다. - 선택 참여 관계에 해당되는 Entity들의 FK Attribute는 Nullable해야 한다. - 0 : 0 Relationship은 양쪽 Entity가 모두 선택 참여 관계로 설정된 것을 의미하는데, 이러한 관계는 옳지 못한 관계일 가능성이 높다. |
| The Beginning (관계 시작점) |
- 해당 관계가 시작되는 Entity편을 의미한다. - 관계 참여자의 관점에 따라 관계 이름이 Active(능동적)하게 명명되거나, Passive(수동적)하게 명명된다. |
| The End (관계 끝점) |
- 해당 관계를 받는 Entity편을 의미한다. - 관계 참여자의 관점에 따라 관계 이름이 Active(능동적)하게 명명되거나, Passive(수동적)하게 명명된다. |
* Relationship Naming Tips
- 애매한 동사로 명명하지 않는다. ('관계', '이다', '한다' 등의 표현은 지양한다.)
- 현재형으로 표현한다. (미래형, 과거형은 지양한다.)
* Exclusive-OR Relationship (상호배타적 관계)
- 하나의 엔터티가 여러 엔터티와 관계를 맺고 있고,
각 인스턴스는 관계를 맺고 있는 엔터티 중 항상 택일해야 하는 상황에 놓여있을 경우에 적합한 관계 형태이다.
데이터 모델링의 관점
Data Perspective (What)
- 업무가 어떤 데이터와 관련이 있는지, 데이터 간의 관계는 어떠한지에 대해 모델링 하는 방법이다.
Process Perspective (How)
- 실제 업무는 무엇인지, 무엇을 해야 하는지에 대해 모델링 하는 방법이다.
Interaction Perspective (Data vs Process)
- 처리하는 일의 방법에 따라 데이터가 받는 영향에 대해 모델링 하는 방법이다.
데이터 모델링의 중요성
Leverage (파급효과)
- 완전한 데이터 설계가 이뤄지지 않은 채로, 시스템 구축을 진행하게 되면
추후 데이터 모델에 결함을 발견해서 수정할 경우
전체 시스템 구축을 다시 시작해야 될 수도 있을 만큼 엄청난 파급효과를 불러 일으킬 수 있다.
- 따라서, 시스템 구축에서 데이터 모델링 과정은 근본이 되는 과정인 만큼 신중히 이루어져야 한다.
Conciseness (복잡한 요구 사항에 대한 간결한 표현)
- 데이터 모델은 건축에서의 설계 도면에 해당된다.
- 잘 만들어진 데이터 모델은 복잡한 요구 사항을 간결하게 파악할 수 있게 한다.
- 데이터 모델은 시스템을 구축에 동원되는 사람들이 설계자의 방향을 이해한 후 애플리케이션을 개발하고,
데이터 정합성을 유지할 수 있게 하는 만큼, 데이터 모델은 요구 사항을 간결하게 표현하고 있어야 한다.
Data Quality (데이터 품질)
- 중복, 비유언성, 비일관성은 데이터 품질을 저해한다.
| Data Redundancy (데이터 중복) |
- 같은 정보(데이터)를 여러 공간에 동시에 저장된 상태를 의미한다. |
| Data Inflexibility (데이터 비유연성) |
- 잘못 설계된 데이터 모델로 인해 잦은 수정이 발생해 유지보수의 어려움을 가중시키는 상태를 의미한다. - 데이터 정의와 데이터 사용 프로세스를 분리함으로써 데이터 유연성을 제고할 수 있다. |
| Data Incnosistency (데이터 비일관성) |
- 데이터 간 상호 연관 관계가 명확히 정의되어 있지 않은 상태를 의미한다. - 데이터 비일관성은 논리적 모순을 야기하는 원인이 된다. |
데이터 모델링 절차
- 현실세계의 개체가 데이터 모델링되는데에는 일반적으로 세 단계의 절차를 거친다.
- EA(Enterprise Application Integration) 기반의 전사적 데이터 모델링 시에는 예외적으로
더욱 상위 레벨의 개괄적 데이터 모델링을 수행한 후 각 업무 영역에 대한 개념적 모델링을 시작하기도 한다.
| Conceptual Data Modeling (개념적 데이터 모델링) (추상적) |
- 업무 중심적·포괄적 수준의 모델링 진행한다. - 전사적 데이터 모델링, EA 수립 시 이용한다. |
| Logical Data Modeling (논리적 데이터 모델링) |
- 모델링 대상에 대한 Key, Attribute, Relationship 등을 정확히 표현하는 모델링 단계이다. - 재사용성이 높다. |
| Physical Data Modeling (물리적 데이터 모델링) (구체적) |
- 실제 DB에 이식할 수 있도록 성능 등의 물리적 성격을 고려해 설계하는 모델링 단계이다. |
Conceptual Data Modeling (개념적 데이터 모델링)
- 사용자의 데이터 요구사항을 분석하는 단계이다.
(이 과정에서 추가적인 요구사항이 발견되거나, 현 시스템의 개선 방안이 발견되기도 한다.)
- ERD(Entity-Relationship Diagram)를 생성한다.
- 경우에 따라 Enterprise Data Model(전사적 데이터 모델; 전 조직적 데이터 모델)을 고안하기도 한다.
Logical Data Modeling (논리적 데이터 모델링)
- 누가(Who), 어떻게(How, Process) 데이터에 액세스하는지를 정하는 단계이다.
- Normalization(정규화)를 수행하여 신뢰성 있는 데이터 구조를 생성한다.
- 식별자 선정, M:N 관계 해소, 참조 무결성 규칙 정의, 이력 관리 전략 수립 등을 수행한다.
- 논리적 데이터 모델링 과정에서 산출되는 논리 데이터 모델은
물리적 스키마 설계를 하기 전, 데이터 모델링이 최종적으로 완료된 상태이다.
Physical Data Modeling (물리적 데이터 모델링)
- 논리 데이터 모델을 컴퓨터 하드웨어에 표현할 방법을 정하는 단계이다.
- 데이터가 컴퓨터에 물리적으로 저장될 방법을 정의하여 물리적 스키마를 만든다.
- 물리적 저장 구조(Table, Column 등), 저장 장치, 접근 방법 등을 선정한다.
Data Independence (데이터 독립성)
- 데이터가 특정 Application에 종속되지 않고 고유한 형태로 존재함으로써
여러 장점을 취할 수 있게 하는 성질을 의미한다.
* 데이터 독립성 확보를 통해 얻을 수 있는 장점
- 각각의 View의 독립성이 확보되어 계층별 View에 영향을 주지 않고 수정이 가능하다.
- 단계별 Schema에 따라 다른 DDL과 DML을 제공할 수 있다.
- 유지보수 비용감소, 데이터 복잡도 감소, 데이터 중복성 감소, 요구사항에 유연한 대응이 가능하다.
Logical Independence (논리적 독립성)
- Conceptual Schema(개념적 스키마)가 변경되어도
External Schema(외부 스키마)에는 영향을 미치지 않도록 하는 성질을 의미한다.
- 즉, 논리적 독립성을 갖추면 논리적 구조가 변경되어도 Application에는 영향을 미치지 않는다.
- DB 사용자 특성에 맞게 수정을 하고, 통합 구조를 변경할 수 있게 한다.
* Logical Mapping (= External·Conceptual Mapping, 논리적·외부적·개념적 사상)
- External View(외부적 뷰)와 Conceptual View(개념적 뷰) 간의 상호 관련성에 대한 정의를 의미한다.
Physical Independence (물리적 독립성)
- Internal Schema(내부 스키마)가 변경되어도
External·Conceptual Schema(외부·개념 스키마)에는 영향을 미치지 않도록 하는 성질을 의미한다.
- 즉, 물리적 독립성을 갖추면 저장장치 구조의 변경이 Application과 Conceptual Schema에 영향을 미치지 않는다.
- 물리적 구조를 신경쓰지 않고 개념적 구조를 변경할 수 있게 한다.
- 또한, 개념적 구조를 신경쓰지 않고 물리적 구조를 변경할 수도 있게 한다.
* Physical Mapping (= Conceptual·Internal Mapping, 물리적·개념적·내부적 사상)
- Conceptual View(개념적 뷰)와 저장된 DB 간의 상호 관련성에 대한 정의를 의미한다.
ANSI/SPARC 3-Schema Architecture (데이터베이스 3단계 구조)
- DB Schema 구조는 3단계로 구분되고, 각각은 상호 독립적이며 고유한 기능과 의미를 갖는다.
- DBA는 데이터 독립성을 보장하기 위해 Mapping하는 Script(= DDL)를 적절히 수행해야 한다.
External Level (=View, 외부 단계)
- DB 사용자 개개인이 보는 데이터에 대한 관점을 제공하는 부분이다.
- 각각의 DB 사용자마다 처리하는 데이터 유형·관점·방법에 따라 다른 Schema 구조로 구성된다.
Conceptual Level (=Schema, 개념적 단계)
- 사용자가 처리하는 데이터 유형의 공통적인 사항을 처리하는
통합된 View에 대한 Schema 구조를 구성하는 단계이다.
- DB에 저장되는 데이터와 그들 간의 관계를 표현하는 Schema를 구성한다.
Internal Level (=Schema, 내부적 단계)
- 물리적 데이터 저장 방법에 대한 Schema 구조가 구성되는 단계이다.
Data Model Notation (데이터 모델 표기법)
ER Model (ER 모델) (URL)
- 교육용으로 많이 이용하는 표기법으로, 실무에선 많이 사용되진 않는다.
IDEF1X
- 소수의 실무 현장에서 사용되는 표기법으로, 마름모와 원을 이용하여 표기한다.
- ERWin에서 IDEF1X을 지원한다.
IE (Informatin Engineering, Crow's Foot)
- 까마귀발 모양의 표기법으로, 가장 널리 사용되는 표기법이다.
- ERWin, EWRStudio에서 IE를 지원한다.
Min-Max
- Cardinality(기수성, 관계에 참여하는 Entity의 비율)를 보다 정교히 표현할 수 있는 표기법이다.
UML
- Streotype을 이용하여 Entity를 표현하는 표기법이다.
- IBM Rational Rose에서 UML을 지원한다.
Barker
- Crow's Foot을 적용하여 관계를 표현하지만, IE와는 차이가 있는 표기법이다.
- DA#에서 Barker를 지원한다.
Identifier (식별자)
- 한 Entity내에 있는 각각의 Instance들에 고유하게 부여되는 논리적 이름이다.
- Identifier(식별자)는 논리 데이터 모델링 단계에서 사용되는 용어이고,
Key(키)는 물리 데이터 모델링 단계에서 사용되는 용어이다.
(Identifier와 Key는 Instance를 Unique하게 만들어준다는 측면에서 유사한 기능을 한다고 볼 수 있다.)
* Identifier의 분류
| 대표성 여부에 따른 분류 |
Primary Identifier (주식별자) |
- 엔터티내에서 각 Occurence들을 구분지을 수 있고, 타 엔터티와 참조관계를 연결할 수 있게 하는 식별자이다. |
| Alternate Identifier (보조식별자) |
- 엔터티 내에서 각 Occurence들을 구분지을 수 있으나, 대표성을 가지진 못해 타 엔터티와 참조관계를 연결하지는 못하는 식별자이다. |
|
| 자가 생성 가능 여부에 따른 분류 |
Internal Identifier (내부식별자) |
- 엔터티 내부에서 스스로 생성가능한 식별자이다. |
| Foreign Identifier (외부식별자) |
- 타 엔터티와의 관계를 통해 타 엔터티에서 받아와야하는 식별자이다. - 관계로 연관된 엔터티 중, Child Entity측에 생성된다. |
|
| 속성 개수에 따른 분류 |
Single Identifier (단일식별자) |
- 하나의 속성으로 구성된 식별자이다. |
| Composite Identifier (복합식별자) |
- 둘 이상의 속성으로 구성된 식별자이다. | |
| 대체 여부에 따른 분류 |
본질식별자 | - 업무에 의해 만들어지는 식별자이다. |
| Artificial Identifier (인조식별자) |
- 원래의 주식별자가 복잡하게 구성되어 있을 경우에 인위적으로 구성한 주식별자를 의미한다. - 인조식별자는 업무적으로 만들어지지 않는다. ex) 주문번호 = 사번 + 주문일자 + 순번 (여기서, 사번+주문일자+순번'은 원래의 주식별자이고, 주문번호는 새로 만들어진 인조식별자이다.) |
Primary Identifier (주식별자)
- 주식별자는 아래 4가지 특징을 만족시킨다.
| 유일성 | - 주식별자에 의해, 엔터티 내 모든 인스턴스들이 유일하게 구분된다. |
| 최소성 | - 주식별자를 구성하는 속성(들)은 유일성을 만족시키면서, 그 개수는 최소이어야 한다. (성능상의 이유) |
| 불변성 | - 주식별자로 지정된 값은 자주 변하지 않아야 한다. |
| 존재성 | - 주식별자는 Not Nullable하다. (Null값을 허용하지 않는다.) |
* 주식별자 도출 기준
- 업무에서 자주 이용되는 속성을 주식별자로 지정한다.
- 명칭·내역과 같이, 이름으로 기술되는 속성들은 주식별자로의 지정을 삼가한다.
(대신, 일련번호·코드와 같은 인조식별자를 생성하여 주식별자로 사용하고, 명칭·내역은 보조식별자로 활용한다.)
- 복합 주식별자로 구성할 경우, 속성의 개수를 최소화한다.
(해당 엔터티가 높은 레벨의 Hierarchy에 위치해있는데 주식별자의 속성 수가 많다면,
Child 엔터티들도 주식별자들을 모두 상속받아야하므로 오버헤드가 크게 증가하게 된다.)
Identifying vs Non-Identifying Relationship Modeling (식별자 관계와 비식별자 관계의 모델링)
- 기본적으로, 모든 관계를 식별자 관계 형태로 설정한 후,
필요에 따라 몇몇 관계를 비식별자 관계 형태로 설정하여 합리적 관계 형태를 유지하도록 한다.
* Identifying Relationship (식별자 관계)
- Child Entity의 주식별자를 Parent Entity의 주식별자로 "그대로" 상속받는 경우의 관계 형태를 지칭한다.
(즉, Child의 주식별자 = Parent의 주식별자 인 경우를 의미한다.)
- Strong Entity와 Weak Entity 사이의 1:1 관계에서 흔히 보이는 유형이다.
- 모든 관계를 식별자 관계로만 구성할 경우,
Descendant로 갈수록 식별자의 개수가 산술급수적으로 증가하여
개발 복잡성을 증가시키고 오류를 유발하는 요인이 된다.
(그러니, 식별자 관계와 비식별자 관계를 적절히 취사선택하여 구성해야 한다.)
* Non-Identifying Relationship (비식별자 관계)
- Child Entity에서 Parent Entity의 속성을 상속받았으나, Identifier로는 활용하지 않는 경우의 관계 형태를 지칭한다.
- 상속받은 속성이 비필수적인 경우, Parent없는 Child가 생성될 수 있다.
- Parent와 Child간 Data Life Cycle이 상이할 경우,
Parent와 Child를 Foreign Identifier로 연결짓지 않거나,
Non-Identifying Relationship으로 연결하는 방법이 있다.
- 각각 별도의 관계를 갖는 다수의 엔터티를 하나로 통합할 때, Non-Identifying Relationship 형태로 연결한다.
- 모든 관계를 비식별자 관계로만 구성할 경우,
Identifier가 Descendant들에게 상속되질 않아 Descendant에서 데이터를 처리할 때
불필요하게 Ancestors까지 찾아가야(Join하여) 하는 경우가 발생하여 성능을 저해하게 된다.
(그러니, 식별자 관계와 비식별자 관계를 적절히 취사선택하여 구성해야 한다.)
| 항 목 | Identifying Relationship (식별자 관계) |
Non-Identifying Relationship (비식별자 관계) |
| 목 적 | - Strong Relationship의 표현 | - Weak Relationship의 표현 |
| 자식 주식별자에 미치는 영향 |
- 자식 주식별자의 구성에 포함 | - 자식 일반속성에 포함 |
| 표 기 법 | - 실선 | - 점선 |
| 연결 고려사항 |
- 반드시 부모엔터티에 종속 - 자식 주식별자에 부모 주식별자를 포함 |
- 자식 주식별자를 부모 주식별자와 독립적으로 구성 혹은, 부분 독립적으로 구성 - 부모측에선 관계에 선택적으로 참여 |
* Non-Identifying Relationship Selection Process (비식별자 관계 선택 프로세스)
1) 관계의 Strong - Weak 여부를 분석하여, Weak Relationship의 경우, 비식별자 관계 설정을 고려한다.
2) Child Entity에 독립적인 PK가 필요한 경우, 독립 PK를 구성한 후 비식별자 관계 설정을 고려한다.
(일반적으로, 업무적 필요성이나 성능 향상 도모를 위해 독립적 PK를 구성한다.)
3) 완성된 모델에서 SQL 복잡도가 높고, 개발 생산성이 낮다면 PK 속성을 단순화하고 비식별자 관계 설정을 고려한다.
Reference: Database Management Systems 3E
(Raghu Ramakrishnan, Johannes Gehrke 저, McGrawHill, 2003)
Reference: The Guide for SQL Professional
(Kdata 한국데이터산업진흥원 저, Kdata 한국데이터산업진흥원, 2020)
