[데이터베이스] 1. Data Model

1. Introduction

현실 세계 → 컴퓨터 세계 

: 현실 → 이해 → 형식화(Formalism) →  설계/코딩 →  응용/운영

 

- 왜 형식화가 필요한가? : 검증 가능(verifiable), 구현 가능(machine understandable)

   ex) 수식, 다이어그램(UML), 대수(Algebra)

 

SW 생명주기 vs DB 생명주기

SW life cycle	DB life cycle
요구사항 분석	요구사항 분석
기능 명세	모델링
설계	스키마 설계
구현	DB 환경 구축
테스트	데이터 입력, 품질관리
유지보수	질의 및 관리

 

DB의 2가지 관점

- 논리적(Logical or Conceptual): 정보 구조 중심 - DB 설계, 모델

- 물리적(Physical): 파일 구조, 인덱스 등 - DBMS 관련

→ 논리/물리 독립성 중요! 논리구조 바뀌어도 물리구조 바뀌지 않도록!

 

데이터베이스 3계층 스키마 구조

[External Schema] ← 사용자 관점 (뷰)      ↑ [Conceptual Schema] ← 전체 구조      ↑ [Physical Schema] ← 실제 저장 방식

 

 

2. 데이터베이스 모델의 역사

연도	인물	모델
1970	Edgar F. Codd	Relational Model (관계형 데이터 모델)
1976	Peter Chen	Entity-Relationship (E-R 모델)
1990	James Rumbaugh 외	Object-Oriented Modeling (객체 모델링)
1999	Booch + Rumbaugh	UML Class Diagram

 

3. UML Class Diagram

Class Diagram: 시스템의 정적인 구조(클래스와 그 관계)를 그래픽으로 표현

• Class: 객체 집합 (속성+연산 포함)
• Attributes: 클래스의 속성 (데이터 필드)
• Operations: 클래스 수행 동작
• Relationships: 클래스 간 관계
  
  • Association: 클래스간 대등한 연관 관계
  • Generalization: 상속 관계 is-a
  • Aggregation / Composition: 포함 관계 has-a
• Constraints: 제약조건 (키, 참조 무결성)

Class

 

Association (연관 관계)

: 클래스 간 의미 있는 연결

• Association Name: 관계 의미 표현 (보통 동사)
• Role Name: 각 끝점에서의 역할 (보통 명사)
• Multiplicity(=Cardicality): 인스턴스 수 제한 (ex. 1, *, 0..3)

Association Class

 

Generalization (상속 관계)

: is kind of, is-a

- 상위 클래스의 속성, 동작을 하위클래스가 상속

- 하위 클래스는 상위 클래스의 구체적 사례

- {abstract} : UML에서 추상적 클래스는 기울임꼴 처리

- ex) 구기종목 - 축구, 농구, 배구

- 하위클래스는 속성 및 연산을 추가하거나 재정의(override) 가능

 

Aggregation vs Composition (포함 관계)

: is a part of

○ Aggregation	● Composition (=strong aggregation)
전체 - 부분 (느슨한 결합)	전체 - 부분 (강한 결합)
독립적	종속적
부서 - 직원	병원 - 수술팀
삭제 시 부분은 존재 가능	삭제 시 부분도 같이 삭제

 

제약조건 (Constraints)

1. Key Constraints : 클래스마다 고유하게 식별할 수 있는 속성 존재 → PK(1개)로 설정 ex. 주민번호, 이름+주소
2. Referential Integrity: 참조 일관성 - 연관된 객체 존재해야 함 → 외래키(Foreign Key)

 

약한 엔티티 (Weak Entity Set)

: 자신이 교유한 primary key를 갖지 못하고, 다른 엔티티의 key를 이용해서만 구별되는 엔티티

(독립적인 키가 없어, 다른 클래스의 PK와 조합해야 식별 가능)

ex) Player 클래스의 key가 back number만으론 부족 : 스스로 key를 가질 수 없고 다른 엔티티의 key를 빌려야만 식별 가능

      → (back number, team name) 조합 필요 

      → 이때 Player는 Weak Entity, Football Team은 Supporting Entity

Observation1: 왜 약한 엔티티가 생기게 되는가?
-> 현실 세계에선 독립적으로 식별되지 않는 개체들이 있다. ex) player를 구별하기에 등번호만으로는 부족한 것처럼

Observation2: 만약 Football team도 약한 엔티티라면?
-> 그럼 Player는 약한 엔티티의 약한 엔티티가 된다.
-> 다이어그램 구조와 설계가 더 복잡해지고, 지원 게층 구조가 필요하다.

Observation3: Referential Integrity (참조 무결성)
-> Player가 참조하는 Football team이 항상 존재해야 한다.
-> 데이터 삽입, 삭제 시 무결성 검사 필요

Q4. 다대다 관계에서도 supporting class가 될 수 있을까?
-> 다대다 관계에서도 충분히 '식별 가능한' 클래스이기 때문에 supporting class 될 수 있다!

 

4. ER Model

: UML보다 더 간단히 표현 가능

 

- generalization과 aggregation/composition 관계 구별 안한다 -> isa

- 카디널리티 표현 방식을 화살표로 한다.

- Multy-way 표현 가능 (ex. 3각 관계) : UML에선 못한다.