데이터베이스 설계
요구 분석
DB에 무슨 정보를 저장할 지, 어떤 application을 구축할 지 , 빈번하게 사용될 연산은 무엇인지, 요구 성능은 어느 정도인지 등을 파악하는 단계
- 즉, 사용자들이 DB한테 원하는 바를 찾아내는 단계임
개념적 설계
요구 분석 단계에서 나온 결과(=요구 조건 명세) 를 DBMS에 독립적인 ER 다이어그램으로 작성하는 단계
- 실세계의 개념을 추상화해서 표현하는 단계
- 여러 개체, 관계 중에서 어떤 정보를 DB로 구성할지를 전하는 단계
- DBMS에 독립적인 개념스키마를 설계 => 즉 DBMS 필요 ❌
✔️ Integrity constraints, business rule 등을 정하는 단계임
논리적 설계
현실 세계의 자료를 컴퓨터가 처리할 수 있는 물리적 저장장치에 저장할 수 있도록 변환하기 위해 특정 DBMS가 지원하는 논리적 자료 구조로 변환하는 단계
- 트랜잭션의 인터페이스를 설계
- 관계형 데이터베이스라면 테이블을 설계함
- 설계한 DB를 구현하기 위해 DBMS를 정하는 단계
✔️ 개념적 설계 = 개념 스키마 설계
✔️ 논리적 설계 = 개념 스키마 평가, 정제 그리고 특정 DBMS에 종속적인 논리적 스키마 설계
물리적 설계
논리적 설계 단계에서 논리적 구조로 표현된 데이터를 디스크 등의 물리적 저장장치에 저장할 수 있는 물리적 구조의 데이터베이스로 변환
- 데이터베이스 파일의 저장 구조, 레코드의 형식, 접근 경로 결정
- 몇 개의 테이블에 인덱스를 구축하고, 몇 개의 테이블을 클러스터링할 지를 선택하는 등의 결정을 함
- 트랜잭션 작성
- 물리적 설계할 때 고려해야 할 사항 :
Response Time,Space utilization,Transaction Throughput
ER 모델
요구사항으로부터 얻어낸 정보들을 개체(Entity)와 관계성(Relation)으로 기술하는 데이터 모델
Entity
Entity란 단독으로 존재하는 객체를 의미하며, 동일한 객체는 존재하지 않음
- 사람, 사물, 장소, 개념, 사건과 같이 유무형의 정보를 가지고 있는 독립적인 실체
- 데이터베이스에서의 Entity는 Attribute의 집합으로 구성된다.
✔️ Entity, Entity Type, Entity set
- Entity : 데이터를 가진 대상
- Entity Type : Attribute가 가지고 있는 공통 속성 => ㅁ로 표현
- Entity Set : Entity의 집합 ( 여러개의 Entity가 모여있는 것)
Attribute
Attribute란 개체가 가진 성질을 의미
- 기본적으로 타원으로 표현하고 개체 타입을 나타내는 직사각형과 실선으로 연결됨
- 속성이 개체를 유일하게 식별할 수 있는 키일 경우 속성 이름에 밑줄을 그음
✅ Attribute 종류
1. Attribute domain
해당 어트리뷰트가 가질 수 있는 도메인을 말함
=> 예를 들어 학년 어트리뷰트는 1, 2, 3, 4, 등 정수만을 가질 수 있기 때문에 학년 어트리뷰트의 도메인은 Integer 이다
2. Key attribute
다른 객체들과 중복되지 않고 주로 객체들을 식별할 때 사용되는 attribute임
- 밑줄을 그어서 표현
=> 예를 들어 학번 어트리뷰트는 학생 객체를 특정지을 수 있는 어트리뷰트이므로 key attribute이다.
3. Composite attribute
독립적인 어트리뷰트들이 모여서 한 어트리뷰트를 생성할 때 생성되어진 어트리뷰트를 의미
그림처럼 주소 attribute는 독립적인 시 구 동 attribute로 구성이 되어있기 때문에 composite attribute라고 함
4. Multi-valued attribute
하나의 어트리뷰트가 여러 개의 값을 가질 때
=> 예를 들어, 전공 어트리뷰트가 있는데 한 학생이 복수전공을 해서 전공 어트리뷰트의 값이 2개가 되면 전공 어트리뷰트를 multi-valued attribute라고 하는 것
- 반대로 하나의 값만 가지는 어트리뷰트는 single-valued attribute라고 함
- Multi-valued attribute는 두 개의 원으로 표현함
5. Derived attribute
다른 어트리뷰트가 갖고 있는 값으로부터 계산되어진 어트리뷰트를 의미
=> 예를 들어, 총 가격을 나타내는 total 어트리뷰트가 있고, 가격을 나타내는 price 어트리뷰트, 개수를 나타내는 count 어트리뷰트가 있을 때 total은 count * price 이므로 total attribute는 derived attribute라고 할 수 있음
- 원을 점선으로 표시
Relation
Relation이란 개체 사이의 연관성을 나타내는 개념
- 개체 타입과 개체 타입 간의 연결 가능한 관계를 정의
- 마름모로 표현
- Relation도 attribute를 가질 수 있음
위의 그림에서 instructor와 student는advisor라는 릴레이션을 갖고 있음
근데 그 릴레이션도 언제부터 student와 instructor가 만나게 됐는지date정보를 가질 수 있음
✅ Constraint
1. Cardinality ratio constraint (카디널리티 비율 제약조건)
🚀 관계 대응수(Cardinality) : 두 개체 타입의 관계에 실제로 참여하는 개별 개체수를 관계 대응수라고 정의
관계를 가지는 두 entity에 대해 한 entity가 얼마나 많은 entity와 관련될 수 있는지를 나타내는 제약 조건
✔️ 일 대 일 (1:1)
✔️ 일 대 다 (1:N) => 가장 많이 사용되는 관계
부모는 많은 자식을 가질 수 있지만 자식은 한 부모만 가질 수 있으므로 일대다의 관계임
✔️ 다 대 다 (N:M)
학사 관리 시스템의 경우에는 한 학생이 많은 과목을 수강할 수 있고 한 과목도 많은 학생이 수강하므로 다대다의 관계임
- 위와 같이 ER 다이어그램에서 N과 M으로 표현해줌
📌 여기서의 1,N,M은 최댓값을 의미함. 최솟값을 표현하고자 할 때는 (최솟값, 최댓값)으로 표기
- 학과와 학생의 관계는 1개의 학과에 여러 명의 학생이 있을 수 있기 때문에 1대 N.
- 그리고 이를 (최솟값, 최댓값)으로 표현하면 위의 그림과 같음.
- 학과에는 반대 쪽에 (1,1) 이 있는 것 그리고 학생에는 반대쪽에 (0, *)이 있는 것으로 보아 하나의 학과에는 여러명의 학생이 속할 수 있으며 최솟값이 0인 것을 보아 학과에 학생이 없는 경우도 있음을 알 수 있음
2. Participation constraint (참여 제약조건)
관계를 가지고 있는 두 entity에 대해 한 개체의 존재가 다른 개체의 존재에 의존하는지 여부를 나타내는 제약 조건
✔️ Total Participation (전체 참여)
개체 집합의 모든 개체가 참여
✔️ Partial Participation (부분 참여)
개체 집합의 일부의 개체만 참여
예를 들어 학생은 과목을 꼭 수강 할 필요가 없지만 과목은 항상 수강생이 있어야 함. 수강생이 없는 과목은 폐강되기 때문
3. Structural constraint (구조적 제약조건)
위에서 살펴본 두가지 제약조건을 말함
대신 1,N,M을 사용하지 않고 (최솟값, 최댓값)을 사용해서 표현함
학생은 최소 3개, 최대 6개의 강의를 수강할 수 있으며, 강의는 최소 10명 최대 100명의 학생들이 들을 수 있을 때, 이를 ER 다이어그램으로 표현하면 위와 같다
🚀 Weak entity type과 Identifying Relationship Type
✔️ Weak entity type(약한 개체) : 자신의 key attribute가 없는 엔티티 타입
예를 들어 학사 관리 시스템에서 학수번호 10043는 10043-01 , 10043-02와 같이 여러 개의 분반이 있을 수 있음.
이 때 분반이라는 개체는 자신의 key Attribute가 없고, 강의에 의존하기 때문에 약한 개체라 합니다.
다시 말하면 분반이 존재하기 위해서는 꼭 강의 엔티티 타입이 있어야 함
- Entity type이 약한 개체와 관계를 맺을 때는 Identifying Relationship Type으로 표현
- 약한 개체는 항상 의존적이기 때문에 참여 제약 조건은 전체 참여
참조 : https://mangkyu.tistory.com/27
https://victorydntmd.tistory.com/126
