2. 설계

3-1공부/데이터베이스시스템

2. 설계

KGW2027 2022. 4. 24. 13:19

728x90

DB에서는 실 세계의 시스템을 컴퓨터 세계의 시스템으로 변환해야한다.

DB설계 단계

1. 요구 분석 ( Requirement Analysis )

2. 개념적 DB 설계

3. 논리적 DB 설계

4. 스키마 정제

5. 물리적 DB 설계

6. 응용 및 보안 설계

E-R Model ( Entity-Relation Model )

- 개념적 설계 단계에서 필요하며, 해당 조직체에서 개체와 관계성이 무엇인가와 무엇을 저장할까를 정함.

- 무결성 제약조건, 사업 규칙 등을 정합

개체(Entity)

- 실세계에서 서로 구분되는 객체 ( 학생, 학과, 학교 등.. )

- 속성들의 집합으로 표시 ( 학생 -> [학번, 이름, 학과, 나이...] )

개체 집합(Entity Set)

- 유사한 개체(Instance)들의 집합, 개체 집합의 모든 개체들은 같은 속성 집합 공유.

- 각 개체집합은 Key를 가진다.

속성(Attribute)

- 한 개체 집합의 모든 구성원에 의해 소유되는 묘사적인 성질들

속성 영역(Domain)

- 각 속성에 대해 허용된 값의 집합 ( 학번: int, 이름: varchar )

관계(Relation)

- 둘 이상의 개체간의 연관성 ( 학생 A는 학과 B에 재학중 )

관계 집합(Relation Set)

- 같은 형태의 관계

- N개의 개체 집합 사이의 관계는 N-ary 관계집합 이라고 표현.

- 삼진(Ternary) : 3개 개체의 관계, 세 개의 개체 집합을 연결해야 하는데, 이진관계 3개로 대체 불가능할 경우 사용

역할(Role)

- 한 관계 집합에 참여하는 개체 집합이 같은 경우, 개체 구분을 위해 역할을 부여할 수 있음. (일반학생, 과대, ...)

키(Key) 제약 조건

- 다대다 관계, 일대다 관계

참여(Participation) 제약 조건

- 전체 참여 : 개체 집합 내에서 최소 1개 이상의 개체가 관계에 참여 ( 선 2개로 표시 )

- 부분 참여 : 개체 집합 내에서 최소 0개 이상의 개체가 관계에 참여 ( 선 1개로 표시 )

약한 개체 ( Weak Entity Type )

- 강한 개체 타입이 없으면 식별할 수 없는 종속적인 개체 타입 ( 각 학생의 가족 관계 같은 것, 2줄 네모 )

ISA ( is a 관계 )

- 한 개체 집합을 세부분류(Subclass)로 분류. ( 학생 개체 집합을 학부생, 대학원생으로 분류, 학생 개체를 상속함. )

- 세분화 ( Specialization ) : 개체를 subclass로 변환 [ 학생 -> 학부생 | 대학원생 ]

- 일반화 ( Generalization ) : subclass를 superClass로 변환 [ 학부생 | 대학원생 -> 학생 ]

- 중첩 제약조건 ( Overlap Constraints ) : 한 개체가 동시에 여러 subclass를 가질수 있는가?

( 학부생 OVERLAPS 대학원생 )

- 포괄 제약조건 ( Covering Constraints ) : subClass의 모든 개체를 모으면 superClass와 같아지는가?

( 학부생 AND 대학원생 COVER 학생 )

집단화 ( Aggregation )

- 관계집합과 개체집합 사이의 관계를 설정

- 관계집합을 일종의 개체집합으로 취급함

대규모 조직체를 위한 개념적 설계

관점 1. 전체적인 설계 개발 조직화, 사용자 그룹 별로 스키마 작성 후 스키마 통합 ( 충돌 해결 )

관점 2. 다용한 사용자의 요구 조건을 고려한 뒤, 상충되는 조건 해소, 통합된 조건 생성

UML ( Unified Model Language )

- 업무 모델링, 시스템 모델링, 개념 모델링, 물리 모델링, 하드웨어 시스템 모델링..

UML Diagram

- Use case Diagram

- Activity Diagram

- Class Diagram

- DB Diagram

- Component Diagram

- Deployment Diagram

728x90