정보 모델링

Preface

정보의 양이 경쟁력이던 시대는 이미 지났다.
지금은 올바른 정보를 추출하여 사용하는 능력, 즉 정보 변별력을 중요시하는 세상이다.

 

내가 1학년 때 호기심으로 들었던 한 공대 교양 수업의 교수님께서 하신 말씀이다.

 

당시에는 별 생각 없이 넘어갔었지만, 소프트웨어 공학을 배우며, 올바른 정보를 선택하여 사용하는 것이 특정 프로젝트에 얼마나 큰 영향을 미치는지 고민해 볼 수 있었다.

 

또한, 얼마 전 Q＆A란에 엔티티에 관한 질문을 올렸었는데, 이번 장을 통해 엔티티의 정의와 대략적인 사용 방향을 알게 되었다.

---

- 정보 모델 : 정보 데이터를 중심으로 시스템의 정적인 정보 구조를 나타냄

 

- 정보 모델링 : 엔티티(개체)들을 정의하고, 이들 사이의 연관성을 규명하는 것

 

- 정보(information) 모델링 = 객체(object) 모델링 = 개념적 데이터(conceptual data) 모델링

---

1. 정보 모델링 개요

 

- 정보 모델링은 데이터베이스의 구조를 알아내 데이터를 개념적(conceptual) 차원에서 기술한다.

→ 물리적(physical) 면을 고려하지 않지만, 물리적 데이터베이스 설계에 기본 골격을 제공

→ ERM(Entity-Relationship Model) 을 주로 사용

→ 시스템 통합(SI : System Integration) 과정에서 필히 요구되는 도구

---

2. 엔티티, 속성, 엔티티 타입

 

- ER 모델 : 엔티티(entity) + 관계(relationship)

① 사각형 : 엔티티 타입

② 타원형 : 속성

③ 마름모 : 관계 타입

 

- 엔티티 : 독립적으로 존재하는 실세계의 사물 혹은 객체

 

- 각 객체는 특정 속성(attribute)의 모임에 의해 기술된다.

 

- 엔티티 타입 : 같은 속성을 지니는 엔티티들의 집합

 

- 분류화(classification) : 비슷한 엔티티를 묶는 작업 → 편리성 제공

 

- 실례화(instantiation) : 엔티티 타입에 속한 엔티티를 구별하는 것 → 분류화의 역작용

 

[엔티티 타입과 속성]

---

3. 관계, 관계 타입, 제약 조건

 

- 관계 : 여러 엔티티 사이에 존재하는 연관성(association)

 

- 관계 타입 : 같은 형태를 갖는 관계들의 집합

 

[관계 타입]

 

- 매핑 제약 조건 (mapping constraints) : 엔티티 타입에 속한 엔티티들 간에 맺어질 수 있는 매핑 수(mapping cardinality)를 제약하는 것

---

① 일대일

[일대일 관계]

② 일대다

[일대다 관계]

③ 다대다

[다대다 관계]

---

- 참여 제약 조건 (participation constraints) : 한 엔티티가 관계에 참여하는 것이 필수(mandatory)인지 선택(optional)인지를 지정해주는 것

 

- 관계 타입 차수(degree) : 참여하는 엔티티 타입의 수

② 2차(binary) : 근무, 결혼 등

③ 3차(ternary)

→ 대부분 관계는 2차 관계 타입

→ 3차 관계 타입은 2차 관계 타입으로 대치될 수 없음

 

[3차 관계 타입]

---

4. 일반화(generalization)

 

- 엔티티 타입 간 유사성이 존재할 때 이것을 모아 하나의 새로운 엔티티 타입을 정의내리는 것

 

- 일반화의 관계 = is_a 관계 = kind_of 관계

 

- 상위 클래스 쪽에 '-'을 표시하여 하위 클래스와 구별한다.

 

[일반화]

---

5. 정보 모델링의 예 : 대학교 데이터베이스

 

- 엔티티 타입은 요구사항에서 '명사'로 표시된다.

→ 엔티티를 찾는 가이드라인

① 문제 기술에 명사가 있으면 엔티티로 고려

② 명사가 값을 가질 수 있으면 엔티티가 아니라 속성

③ 분석가가 정보를 추적하고 싶으면 엔티티로 고려

④ 엔티티와 속성의 구별이 모호하면 엔티티로 추정

⑤ 데이터 이름이 _id, _number, _code, _type 등으로 끝나면 엔티티 타입의 키일 가능성 ↑

⑥ 데이터와 관한 정의가 있는 경우 그 데이터를 포함한 엔티티의 이름 찾기가 수월

 

- 관계 타입은 요구사항에서 '동사'로 표시된다.

→ 관계를 찾는 가이드라인

① 문제 기술에 동사가 있으면 관계로 고려

② 불명확한 엔티티가 있으면 관계로 고려

③ 데이터가 독립적인 두 엔티티를 기술하면 관계로 고려

④ 한 레코드가 둘 이상의 고유 번호(unique id)를 가지고 있으면 관계로 고려

 

[대학교 ER 모델]

 

 

 

 

 

참고 문헌 : 윤청, 『소프트웨어 공학 에센셜』(생능출판), 2019, p.206~224.