데이터베이스 개론 - 8장 데이터베이스 설계

8장 데이터베이스 설계

8-1 데이터베이스 설계 단계

8-2 요구 사항 분석

8-3 개념적 설계

8-4 논리적 설계

8-5 물리적 설계와 구현

• 데이터베이스를 설계하기 위한 레시피를 정확히 파악하자
• 데이터베이스 설계라는 요리의 레시피 중 하나인 E-R 모델과 릴레이션 변환 규칙을 이용해 데이터베이스를 설계하는 과정을 소개한다.

8-1 데이터베이스 설계 단계

*요구 사항 *

• 사용자들의 요구 사항을 잘 분석하고, 분석한 결과를 바탕으로 데이터베이스의 논리적, 물리적 구조를 제대로 설계해야 한다.
• 데이터베이스 설계는 사용자들의 요구 사항을 고려하여 데이터 베이스를 생성하는 과정이다.
• 데이터베이스를 실제로 사용하는 구성원들의 요구 사항을 만족하는 지가 대표적인 기준이 된다.

데이터베이스를 설계할 때는

1. 첫째는 E-R 모델과 릴레이션 변환 규칙을 이용한 데이터베이스 설계이고
2. 9장에서 알아볼 정규화를 이용한 데이터베이스 설계이다.

E-R 모델과 릴레이션 변환 규칙 5단계

E-R 모델과 릴레이션 변환 규칙을 이용한 5단계 설계 규칙
1단계 : 요구 사항 분석	데이터 베이스 설계는 요구 사항 분석 단계에 시작이다.
	데이터베이스를 사용해 실제 업무를 처리하는 사용자에게서 필요한 데이터의 종류와 처리 방법 같은 다양한요구 사항을 수집한다.
	요구 사항 명세서로 작성하는 것이 요구 사항 분석 단계에서 수행하는 주요 작업이다.
2단계 : 개념적 설계	개념적 설계 단계는 요구 사항 분석 단계의 결과물인 명세서를 바탕으로 시작한다.
	사용자의 요구 사항을 개념적 데이터 모델을 이용해 표현한다.
	개념적 데이터 모델은 개발에 사용할 DBMS의 종류에 독립적이면서, 중요한 데이터 요소와 데이터 요소 간의 관계를 표현할때 사용한다.
	E-R 모델을 많이 사용하는데, E-R 모델은 중요한 데이터 요소와 데이터 요소간의 관계를 E-R 다이어그램으로 표현한다.
	사용자의 요구 사항을 분석한 결과를 E-R 다이어그램으로 표현하는 것이 개념적 설계 단계에서 수행하는 주요 작업이다.
개념적 모델링	요구 사항분석 단계의 결과물인 요구 사항 명세서를 개념적 데이터 모델로 변환하는 일을 개념적 모델링이라 한다.
개념적 구조, 개념적 스키마	그리고 E-R 다이어그램과 같이 개념적 데이터 모델로 표현한 결과물을 개념적 구조 또는 개념적 스키마라고 한다.
3단계 : 논리적 설계	개념적 설계 단계에서 생성한 개념적 구조를 기반으로논리적 구조를 설계한다.
	DBMS의 종류에 따라 네트워크 데이터 모델, 계층 데이터 모델, 관계 데이터 모델, 객체지향 데이터 모델 등의 논리적 데이터 모델로 사용할 수 있는데
관계 데이터 모델	관계 데이터 모델을 많이 사용한다.
	관계 데이터 모델을 사용한다면
	개념적 설계 단계에서 생성한 E-R 다이어그램을 릴레이션(테이블) 스키마로 변환하여
	DBMS가 처리할 수 있도록 하는 깃이 논리적 설계단계에서 수행하는 주요 작업이다.
논리적 모델링 또는 데이터 모델링	E-R 다이어그램을 릴레이션 스키마로 변환하는 작업을 논리적 모델링 또는 단순히 데이터 모델링이라 한다.
논리적 구조 또는 논리적 스키마	릴레이션 스키마와 같이 논리적 데이터 모델로 표현된 결과물을 논리적 구조 또는 논리적 스키마라고 한다.
4단계 : 물리적 설계	데이터베이스의 물리적 구조는 데이터베이스를 저장 장치에 실제로 저장하기 위한 내부 저장 구조와 접근 경로 등을 의미한다.
	데이터 베이스를 실제로 구축할 컴퓨터 시스템의 저장 장치와 운영체제의 특성을 고려하여
	효율적인 성능을 지원하면서도 사용할 DBMS로 구현이 가능한 물리적인 구조를 설계하는 것이 물리적 설계 단계에서 수행하는 주요 작업이다.
내부 스키마 또는 물리적 스키마	물리적 설계의 결과물인 물리적 구조를 내부 스키마 또는 물리적 스키마라고 한다.
5단계 : 구현	데이터 정의어 (DDL)
	사용되는 SQL 문은 테이블이나 인덱스 등을 생성할 때 사용되는 데이터 정의어 (DDL) 이다.

핵심 단계 : 요구 사항 분석, 개념적 설계, 논리적 설계 단계

8-2 요구 사항 분석

*요구 사항 분석 단계 *

• 데이터베이스에 대한 사용자들의 요구 사항을 수집하고 분석하여
• 개발할 데이터베이스의 용도를 명확히 파악하는 게 이 단계의 목적이다.

*요구 사항 분석 단계 *

1. 사용자의 범위 : 데이터 베이스를 사용할 주요 사용자의 범위부터 결정해야 한다.
2. 업무를 분석 : 조직에서 수행하는 업무를 분석한다.그데이터에 어떤 처리가 필요한지 등에 초점을 맞춰 요구 사항들을 수집하고 분석해야 한다.요구 사항 명세서로 문서화 하는데 : 요구 사항 명세서의 양식은 조직마다 다르므로 이를 먼저 확인한 후 작성해야한다.
3. 요구 사항을 수집하기 위해 사용자들과의 면담, 설문지 배포, 업무 관련 문서의 분석 등과 같은 방법이 주로 사용된다.
4. 사용자의 업무와 관련해 필요한 데이터가 무석이고

8-3 개념적 설계

개념적 설계: 개념적 데이터 모델, 개념적 모델링, 개념적 구조 == 개념적 스키마

• 요구사항 분석 => 결과물 => 개념적 데이터 모델
• 데이터베이스에 저장해둘 필요가 있다고 판단되는 데이터 요소를 추출하고 데이터 요소간의 관계를 파악하여 이를 표현
• 개념적 데이터 모델은 E-R 모델을 많이 이용한다.

• 개념적 데이터 모델로 변환하는 작업을 개념적 모델링이라 한다.
• 개념적 구조 또는 개념적 스키마라고 한다.
  • 개념적 data model로 표현된 개념적 결과물

*개체 *

• 요구 사항의 분석 결과를 E-R 모델을 이용해 개념적 모델링을 하려면
• E-R 모델의 핵심요소인 개체를 추출해야 한다.
• 개체의 주요 속성 과 키 속성을 선별하고 개체 간의 관계를 결정해야 한다.
• 개체, 속성, 관계를 선별하는 작업이 모두 완료되면 그 결과를 E-R 다이어그램으로 표현한다.

8-3-1 개체와 속성 추출

*개체 *

• 기본 작업은 요구 사항 분석 단계의 결과물에서 개체를 추출하는 일이다.
• 개체부터 결정해야 속성과 관계도 결정할 수 있다.
• 개체는 현실 세계에서 어떤 조직을 운영하는 데 꼭 필요한 사람
• 개체는 저장할 만한 가치가 있는 중요 데이터를 지닌 사람이나 사물 등이며
• 개념적 모델링을 하는 데 가장 중요한 요소다.
• 개체 => 저장할 만한 중요 데이터를 지닌 사람

*개체를 추출 방법 *

• 환자, 의사, 간호사 들과 같이 개체를 직관적으로 추출할 수 있다.
• 요구 사항 명세서에서 개체를 추출하는 방법으로 표준화 된 것이 없어서 초보자는 개체 추출 작업을 더 어렵게 생각하고있다.
• 요구 사항의 문장들에서 명사부터 찾아야 한다.
  • 조직의 업무 처리와 관련이 적은 일반적이고 광범위한 의미의 명사는 제외한다.
  • 모든 명사가 개체는 아니다.따라서 찾아낸 명사를 개체와 속성으로 정확히 분류하는 작업이 필요하다.

---

1. 회원 아이디, 비밀번호, 이름, 나이, 직업은 주요한 데이터를 가지고 있는 독립적인 대상이 아니라회원만 개체로 분류하고 회원아이디, 비밀번호, 이름, 나이, 직업은 회원 개체가 가지고 있는 속성으로 분류한다.
2. 회원이 가지고 있는 중요한 데이터 자체로 볼 수 있다.
3. 등급과 적립금도 회원 개체가 가지고 있는 속성으로 분류한다.
4. 회원아이디는 회원을 식별하는 역할을 한다고 했다
5. 따라서 회원아이디를 키 속성으로 지정한다.

---

7. 회원과 상품은 개체로 분류한다.하지만 주문을 해야 생기는 정보이므로 회원이나 상품 개체에 항상 속해 있는 속성으로 보기는 어렵다. (필수는 아니다.)
8. 주문번호, 주문수량, 배송지, 주문일자는 회원이 상품을 주문하면 생기는 중요한 정보이기 때문에 속성으로 분류

• 조직의 엄무 처리와 관련이 깊은 개체와 속성부터 반드시 추출해야 함을 잊지 말아야 한다.

최종 E-R (회원, 상픔, 제조업체, 게시글)

회원

*상품 *

*제조업체 *

*게시글 *

8-3-2 관계 추출 : 개체간의 의미 있는 연관성 (동사 표현)

관계

• 개체와 속성을 추출하고 나면 개체 간의 관계를 결정할 수 있다.
• 관계는 개체 간의 의미 있는 연관성이다.
• 관계는 요구 사항을 표현한 문장에서 동사로 표현 된다.
• 의미가 같은 동사가 여러 개이면 동사 하나만 선택한다.

매핑 카디널리티 와 참여 특성을 결정한다. : 일대일, 일대다, 다대다. 와 선택, 필수

*매핑 카디널리티 *

• 관계를 맺고 있는 두 개체에서, 각 개체 인스턴스가 관계를 맺고 있는 상대 개체의 개체 인스턴스 개수를 의미한다.
• 매핑 카디널리티를 기준으로 추출한 관계를 일대일 1:1, 일대다 1:n, 다대다 n:m 중 하나로 분류한다.

*참여 특성 *

• 개체가 관계에 필수적으로 참여하고 있는지 선택적으로 참여하고 있는지를 의미하는
• 참여특성을 결정한다.

---

1. "입력해야 한다." : 회원 개체의 속성인 회원아이디-비밀번호-이름-나이-직업 에 대해 설명하는 것이다.
2. 따라서 개체와 개체의 관계를 표현하는 동사로 볼 수 없다.
3. "부여된다." : 회원 개체의 속성인 등급-적립금에 대해 설명하는 것이므로 같은 이유로 제외한다.
4. "식별한다." : 회원 개체를 설명하는 것이므로 제외한다.

---

6. "주문할 수 있다" : 회원 개체와 상품 개체가 맺는 관계를 설명하므로 이를 통해 회원 개체와 상품 개체가 맺고 있는 주문 관계를 추출할 수 있다.하나의 상품을 여러 회원이 주문할 수있다.회원이 상품을 반드시 주문해야 하는 것은 아니므로 회원 개체는 주문 관계에 선택적으로 참여한다고 볼 수 있다.상품 (선택) <==> 회원 (선택)
7. 회원이 주문을 하지 않은 상품이 존재할 수 있으므로 상품 개체도 주문 관계에 선택적으로 참여한다고 본다.
8. 주문 관계는 다대다 n:m 관계가 된다.
9. 회원 한명이 여러 상품을 주문할 수 있고
10. "유지해야 한다" : 회원 개체와 상품 개체가 준문 관계를 맺으면 생기는 주문 번호-주문수량-배송지-주문일자 속성을 설명하므로 관계를 표현하는 동사로 볼 수 없다.

---

8. "공급할 수 있다" : 상품 개체와 제조업체 개체가 맺는 관계를 설명하므로 이를 통해 상품 개체와 제조업체 개체가 맺고 있는 공급 관계를 추출할 수 있다.제조업체 개체와 상품 개체가 맺는 공급 관계는 일대다 1:n이다.선택적 : 상품을 공급하지 않는 제조업체도 존재할 수 있으므로 제조업체 개체는 공급 관계에 선택적으로 참여한다.
9. *_필수적 : *_상품은 제조업체가 반드시 공급해야하므로 상품 개체는 공급관계에 필수적으로 참여한다고 볼 수 있다.
10. 제조업체 하나가 공급하고, 제조업체 하나는 여러 상품을 공급할 수 있다고 했으므로
11. "유지해야 한다" : 상품 개체와 제조업체 개체가 공급 관계를 맺으면 생기는 공급일자-공급량 속성을 설명하므로, 동사로 볼 수 없다.
12. 공급 관계의 속성으로 분류한다.

ㅋ

12. "작성할 수 있다" : 회원 개체와 게시글 개체가 맺는 관계를 설명하므로 이를 통해 회원 개체와 게시글 개체가 맺고 있는 작성 관계를 추출 할 수 있다.선택적 : 회원이 게시글을 반드시 작성해야 하는 것이 아니므로 회원 개체는 작성 관계에 선택적으로 참여한다고 볼 수 있다.
13. 필수적 : 게시글은 반드시 회원이 작성해야 하므로 게시글 개체는 작성 관계에 필수적으로 참여한다고 볼 수 있다.
14. 게시글 개체가 맺는 작성 관계는 일대다 1:n 가 된다.

• E-R 다이어그램에서 관계는 마음로로 표현하고, 사각형으로 표현된 개체와 선으로 연결한다.
• 일대일 1:1, 일대다 1:n, 다대다 n:m 관계는 선 위에 레이블로 표시한다.
• 필수적으로 참여하는 개체는 개체와 관계를 이중선으로 연결한다.

---

1. 주문 관계는 회원 개체와 상품 개체의 연관성을 표현하고
2. 주문번호-주문수량-배송지-주문일자를 속성으로 가진다.
3. 주문 관계는 다대다 n:m 관계로 분류되고
4. 선택적 : 회원 개체와 상품 개체는 모두 주문 관계에 선택적으로 참여한다.

---

1. 공급관계는 상품 개체와 제조업체 개체의 연관성을 표현하고
2. 공급일자-공급량을 속성으로 가진다.
3. 공급 관계는 일대다 1:n 관계로 분류되고
4. 필수적 : 상품 개체는 주문 관계에 필수적으로 참여하며
5. 선택적 :제조업체 개체는 주문 관계에 선택적으로 참여한다.

---

1. 요구 사항 명세서에서 추출한 작성 관계를 E-R 다이어그램으로 표현한 결과
2. 작성 관계는 회원 개체와 게시글 개체의 연관성을 표현한다.
3. 작성 관계는 일대다 1:n 관계로 분류되고
4. 선택적 : 회원 개체는 작성 관계에 선택적으로 참여하며
5. 필수적 : 게시글개체는 작성 관계에 필수적으로 참여한다.

---

즉 개념적 설계 단계의 결과물인 개념적 스키마다.

8-4 논리적 설계

논리적 설계 단계

dbms에 적합한 논리적 스키마 설계

• 개념적 스키마 이용 (E-R) -> 논리적 스키마 설계
• DBMS에 적합한 논리적 데이터 모델을 이용해서, 개념적 설계 단계에서 생성한 개념적 스키마를 기반으로 논리적 스키마를 설계한다.
• DBMS에 독립적인 개념적 스키마를 기반으로 하여 개발에 사용할 DBMS가 처리할 수 있는
• 데이터베이스의 논리적 구조를 설계하는 것이 논리적 설계 단계의 목표다.
• 논리적 설계 단계에서는 관계 데이터 모델을 이용하여 개념적 설계 단계의 결과물인 E-R 다이어그램을 관계 데이터 모델의 릴레이션 스키마
• 테이블 스키마로 변환 하는 작업을 한다.

• 모델링 : 논리적 데이터 모델로 변환하는 작업을 논리적 모델링 또는 단순히 데이터 모델링이라 한다.
• 논리적 구조 또는 논리적 스키마 : 릴레이션 스키마와 같이 논리적 데이터모델로 표현된 논리적 설계의 결과물을 논리적 구조 또는 논리적 스키마
• E-R 다이어 그램을 릴레이션 스키마로 변환하는 일은 쉽지 않다.
• E-R 모델에서는 개체와 관계를 구분하지만
• 관계 데이터모델에서는 개체와 관계를 구분하지 않고 모두 릴레이션으로 표현한다.
• 그리고 E-R 모델에서는 다중 값 속성이나 복합 속성의 표현을 허용하지만
• 관계 데이터 모델에서는 다중 값 속성과 복합 속성의 표현을 허용하지 않는다.

8-4-1 릴레이션 스키마 변환 규칙

릴레이션 스키마로 변환하는 규칙 다섯 가지를 간단한 예와 함께 보자.

8-4-1-1 규칙 1 : 모든 개체는 릴레이션으로 변환한다.

• E-R 다이어그램의 각 개체를 하나의 릴레이션으로 변환한다.
• 개체의 이름을 릴레이션의 이름으로 하고
• 개체가 가진 속성도 릴레이션의 속성으로 그대로 변환한다.
• 개체가 가지고 있는 속성이 복합 속성인 경우에는
• 복합 속성을 구성하고 있는 단순 속성만 릴레이션의 속성으로 변환한다.
• 개체가 가지고 있는 키 속성은 릴레이션의 기본키로 변환한다.

1. 개체의 이름을 그대로 릴레이션의 이름으로
2. 상품번호-상품명-재고량-단간 속성도 그대로 상품 릴레이션이 되고
3. 상품번호-상품명-재고량-단가 속성도 그대로 상품 릴레이션의 속성으로 변환한다.
4. 상품 개체의 키 속성인 상품번호를 상품 릴레이션의 기본키로 지정한다.
5. 실제 데이터는 DBMS가 릴레이션을 구현한 후에야 삽입되므로 논리적 설계 단계에서는 릴레이션의 스키마만 설계하면 된다.

상품 ( 상품번호, 상품명, 재고량, 단가)

---

1. 고객 개체를 고객 릴레이션으로 변환한다.
2. 단속 속성인 고객 번호-이름-등급은 그대로 고객 릴레이션의 속성으로 변환한다.
3. 고객 개체의 키 속성인 고객 번호를 고객 릴레이션의 기본키로 지정한다.
4. 고객 개체가 복합 속성인 주소 속성을 가지고 있는 경우에는 복합 속성을 구성하고 있는 단순 속성들만 릴레이션의 속성으로 변환 해햐 하므로
5. 복합 성성인 주소 속성을 제외한 우편번호-기본주소-상세주소 속성만 고객 릴레이션에 포함된다.

8-4-1-2 다대다 n:m 관계는 릴레이션으로 변환한다.

1. E-R 다이어그램에 있는 다대다 n:m 관계를 하나의 릴레이션으로 변환한다.
2. 관계의 이름을 릴레이션의 이름으로 하고
3. 관계의 속성도 릴레이션의 속성으로 그대로 변환한다.
4. 관계를 맺고 있는 개체가 무엇인지 중요하므로, 관계를 맺고 있는 개체들을 규칙 1에 따라 변환한후
5. 이 릴레이션들의 기본키를 관계 릴레이션에 포함시키고 외래키로 지정한다.
6. 이 외래키들을 조합하여 관계릴레이션의 기본키로 지정한다.
7. 개체를 변환한 릴레이션의 기본키를 외래키로 지정할 때는 가져온 기본키들의 이름이 같을 경우 하나는 이름을 변경해야 한다.

1. 고객 릴레이션의 기본키인 고객번호 속성과
2. 상품 릴레이션의 기본키인 상품번호 속성을 가져와 주문 릴레이션에 포함시키고 외래키로 지정한다.
3. 외래키를 조합하여 주문 릴레이션의 기본키로 지정한다.

8-4-1-3 일대다 1:n 관계는 외래키로 표현한다.

• E-R 다이어그램에 있는 일대다 1:n 관계는 릴레이션으로 변환하지 않고 외래키로만 표현한다.
• 1:n , 약한 개체 : 약한 개체가 참여하는 일대다1:n 관계는 일반 개체가 참여하는 경우와 다르게 처리해야 하므로

8-4-1-3-1 일반적인 일대다 관계는 외래키로 표현한다.

• 일반 개체들이 참여하는 일대다1:n 관계는 릴레이션으로 변환하지 않고 외래키로만 표현한다.
• 일대다 1:n 관계의 1측 개체 릴레이션의 기본키를 가져와 n측 개체 릴레이션에 포함시키고 외래키로 지정한다.
• 그러므로 반드시 1측 개체 릴레이션의 기본키를 n측 개체 릴레이션의 외래키로 지정해야 한다.

1. 개체를 먼저 규칙 1에 따라 제조업체 릴레이션과 상품 릴레이션으로 변환한다.
2. E-R다이어그램에서 제조업체 개체와 상품 개체가 맺고 있던 공급 관계는 일대다1:n 관계이므로 규칙 3-1에 따라 외래키로만 표현한다.
3. 공급 관계의 1측 개체에 해당하는 제조업체 릴레이션의 기본키인 제조업체명 속성을 n측 개체에 해당하는 상품 릴레이션에 포함시키고
4. 외래키로 지정한다.
5. 공급 관계의 공급 수량 속성도 상품 릴레이션에 포함시킨다.
6. 공급수량 속성은 기본키 속성이 아니므로 상품 릴레이션에서 외래키가 될 수 없다는 사실을 기억하자.

8-4-1-3-2 약한 개체가 참여하는 일대다 관계는 외래키를 포함해서 기본키로 지정한다.

1. 이때 일대다 1:n 관계의 1측 개체 릴레이션의 기본키를 가져와 n측 개체릴레이션에 포함시키고 외래키로 지정한다.
2. 관계의 속성들도 n측 개체 릴레이션에 포함시킨다.
3. 즉, n측 개체 릴레이션이 가지고 있던 키 속성과 외래키 속성을 조합하여 기본키로 지정한다.
4. 그러므로 강한 개체인 1측 개체 릴레이션의 기본키를 포함해서 약한 개체의 기본키를 지정한다.
5. 강한 개체에 해당하는 비행기 릴레이션의 기본키를 포함해서 약한 개체에 해당하는 좌석 릴레이션의 기본키를 지정하는 것이 타당하다.

8-4-1-4 : 일대일 1:1 관계를 외래키로 표현한다.

E-R 다이어그램에 있는 일대일 1:1 관계도 일대다 1:n 관계처럼 릴레이션으로 변환하지 않고 외래키로만 표현한다.

8-4-1-4-1 : 일반적인 일대일 관계는 외래키를 서로 주고 받는다.

• 외래키 서로 주고 받기
• 규칙 1에 따라 변환한 릴레이션들이 서로의 기본키를 주고받아 이를 외래키로 지정한다.

• 남자 개체와 여자 개체를 먼저 규칙 1에 따라 남자 릴레이션과 여자 릴레이션으로 변환한다.
• 즉, 남자 릴레이션의 기본키인 남자번호 속설을 여자 릴레이션의 외래키로 지정하고,
• 여자 릴레이션의 기본키인 여자번호 속성을 남자 릴레이션의 외래키로 지정한다.
• 혼인 관계가 가지고 있던 결혼날짜 속성은 남자 릴레이션과 여자 릴레이션에 모두 포함시킨다.
• 일대다 1:n 관계의 표현처럼 한쪽 릴레이션만 외래키를 가져도 관계를 표현하는데 충분하다.

8-4-1-4-2 : 일대일 관계에 필수적으로 참여하는 개체의 릴레이션만 외래키를 받는다.

• 일대일 1:1 관계를 맺고 있는 두 개체 중 관계에 필수적으로 참여하는 개체에 대응하는 릴레이션에만 외래키를 포함시킨다.
• 필수 개체의 외래키만 외래키 참조하는 이유 -> 선택인 null 있을수 있다.
• 관계에 반드시 참여하는 개체에 대응하는 릴레이션이 외래키를 가지도록 하는 것이 좋다.
• 이런 경우에는 남자 릴레이션이 여자 릴레이션의 기본키인 여자번호를 외래키로 받는다.
• 그리고 혼인 관계가 가지고 있는 결혼날짜 속성을 남자 릴레이션에 포함시킨다.
• 일대일 1:1 관계를 맺는 두 개체가 모두 선택적으로 참여하는 경우에는 외래킬ㄹ 포함시킬 릴레이션을 자유롭게 선택하면 된다.
• 필수적으로 참여하는 개체가 있다면 그 개체에 해당하는 리레이션에 외래키를 포함시키면 된다.

8-4-1-4-3 : 모든 개체가 일대일 관계에 필수적으로 참여하면 릴레이션 하나로 합친다.

*일대일 1:1 관계를 맺고 *

• 일대일 관계를 맺고 있는 두 개체가 모두 관계에 필수적으로 참여한다면
• 그러므로 두 개체에 해당하는 두 릴레이션을 하나로 합쳐 표현한다.
• 관계의 이름을 릴레이션의 이름으로 사용하고
• 관계에 참여하는 두 개체의 속성들도 관계 릴레이션에 모두 포함시킨다.
• 두 개체 릴레이션의 키 속성을 조합하여 관계 릴레이션의 기본키로 지정한다.

1. 규칙 1에 따라 남자 릴레이션과 여자 릴레이션으로 변환한다.
2. 남자 개체와 여자 개체가 일대일1:1인 혼인 관계에 모두 필수적으로 참여하므로
3. 규칙 4-3에 따라 릴레이션과 여자 릴레이션을 하나의 릴레이션으로 합친다.
4. 혼인 관계를 표현하는 릴레이션이므로 합친 릴레이션은 이름을 혼인 릴레이션으로 한다.
5. 남자 릴레이션의 남자번호-이름-나이 속성과 여자 릴레이션의 여자번호-이름-나이 속성, 혼인 관계의 결혼날짜 속성을 혼인 릴레이션에 모두 포함시킨다.
6. 단, 남자 릴레이션의 이름-나이 속성이 여자 릴레이션의 속성과 이름이 같으므로 혼인 릴레이션에서 속성의 이름을 변경한다.
7. 마지막으로, 남자 릴레이션의 기본키인 남자번호와 여자 릴레이션의 기본키인 여자번호를 조합하여 혼인 릴레이션의 기본키로 지정한다.

8-4-1-5 규칙 5 : 다중 값 속성은 릴레이션으로 변환한다.

• 관계 데이터 모델의 릴레이션에서는 다중 값을 가지는 속성을 허용하지 않는다.
• E-R 다이어그램에 있는 다중 값 속성은 그 속성을 가지고 있는 개체에 해당하는 릴레이션이 아닌 별도의 릴레이션을 만들어 포함시킨다.
• 새로 만들어진 릴레이션에는 E-R 다이어 그램에서 다중 값 속성으로 표현된 속성뿐 아니라
• 그 속성을 가지고 있는 개체에 해당하는 릴레이션의 기본키를 가져와
• 포함시키고 이를 외래키로 지정한다.
• 기본키는 다중 값 속성과 외래키를 조합하여 지정한다.

1. E-R 다이어그램에 있는 사원 개체를 먼저 규칙 1에 따라 사원 릴레이션으로 변환한다.
2. 사원 개체가 가지고 잇는부하직원 속성은 다중 값을 가지는 속성이므로
3. 사원 릴레이션에 포함시킬 수 없어 별도의 릴레이션을 만든다.
4. 새로 만든 릴레이션의 이름은 사원-부하직원 릴레이션으로 지정한다.
5. 사원-부하직원 릴레이션에 다중 값 속성으로 분류한 부하직원 속성과 사원 릴레이션의 기본키인 사원 번호를 가져와 포함시키고 이를 외래키로 지정한다.
6. 다중 값 속성으로 분류한 부하직원 속성과 외래키인 사원번호를 조학하여 사원-부하직원 릴레이션의 기본키로 지정한다.
7. 이 릴레이션이 구축된 후 실제 데이터가 저장된 모습을 통해 규칙 5을 이해해보자.

• 다중 값 속성을 릴레이션에 포함시키려면 규칙 5를 적용해서 릴레이션을 분해할 필요가 있다.

8-4-1-6 : 기타 고려 사항

• 기본 변환 규칙에서는 다대다 n:m 관계만 릴레이션으로 변환하였지만
• 일대일 1:1, 일대다 1:n 관계도 릴레이션으로 변환할 수 있다.

1. E-R 다이어그램에 있는 남자 개체와 여자 개체를 규칙 1에 따라 먼저 남자 릴레이션과 여자 릴레이션으로 변환한다.
2. E-R 다이어그램에서 남자 개체와 여자 개체가 맺고 있는 관계는 일대일 1:1 관계이지만
3. 다대다 n:m 관계처럼 릴레이션으로 변환한다.
4. 관계의 이름을 릴레이션의 이름으로 그대로 사용하고
5. 혼인 관계의 결혼날짜 속성을 혼인 릴레이션의 속성으로 변환한다.
6. 그리고 혼인 관계를 맺고 있는 두 개체에 해당하는 릴레이션들의 기본키를 가져와 포함시키고 이를 외래키로 지정한다.
7. 즉 남자 릴레이션의 기본키인 남자번호 속성과 여자 릴레이션의 기본키인 여자번호 속성을 가져와 혼인 릴레이션에 포함시키고 이를 외래키로 지정한다.
8. 두 외래키를 조합하여 기본키로 지정한다.
9. 외래키만으로도 표현이 가능한 일대일 1:1 이나 일대다 1:n 관계는 릴레이션으로 변환하지 않는 것이 좋다.

8-4-1-7 순환 관계도 기본 규칙을 그대로 적용하면 된다.

순환 관계가 다대다 n:m 관계일 경우에는 릴레이션으로 변환하고

일대일 1:1 이나 일대다 1:n 관계일 경우에는 외래키로만 표현한다.

1. 사원 개체가 자기자신과 관리 관계를 맺고 있다.
2. 서로 다른 역할로 관계를 맺고 있지만 관리 관계에 참여하는 실제 개체는 사원 개체 하나뿐이다.
3. 하나의 개체만 관계에 참여하는 특수한 형태이지만 순환 관계도 기본 규칙을 그대로 적용한다.
4. E-R 다이어그램에서 관리 관계는 일대다1:n 이므로 릴레이션을 생성하지 않고 외래키로만 표현한다.
5. 사원 릴레이션의 기본키인 사원번호를 사원 릴레이션의 외래키로 지정해야 하는데
6. 사원 릴레이션의 기본키 속성 이름과 외래키 속성 이름이 같으면 안 되므로 관리 관계를 표현하기 위해 상사번호라는 이름으로 변경한다.
7. 관리 관계에서 1측에 해당하는 상사 역할의 사원 개체 릴레이션의 기본키를 n측에 해당하는 부하직원 역할의 사원 개체 릴레이션의 외래키로 지정헌다는 의미
8. 외래키 속성의 이름을 상사번호로 변경한 것이다.
9. pk와 이름 혼합하지 않기 위해, 상사번호로 외래키 변경

8-4-2 릴레이션 스키마 변환 규칙을 이용한 논리적 설계

8-4-2-1 규칙 1에 따라 4개의 개체를 개별 릴레이션으로 변환

8-4-2-2 규칙 2를 적용한 결과 : 다대다 n:m 관계 설정

1. 회원 개체와 상품 개체가 참여하는 주문 관계를 릴레이션으로 변환해야 한다.
2. 주문 관계의 주문번호-주문수량-배송지-주문일자 속성을 그대로 포함한다.
3. 회원 개체에 해당하는 회원 릴레이션의 기본키인 회원 아이디 속성과
4. 상품 개체에 해당하는 상품 릴레이션의 기본키인 상품번호 속성을 주문 릴레이션에 포함시키고 이를 외래키로 지정한다.

8-4-2-3 규칙 3를 적용한 결과 : 일대다 1:n 관계를 외래키로 표현하는 것이다.

8-5 물리적 설계와 구현

1. 논리적 설계 단계에서 릴레이션 스키마의 설계를 완료하면,
2. 물리적 설계 단계에서는 하드웨어나 운영체제의 특성을 고려하여 필요한 인덱스의 구조나 내부 저장 구조, 접근 경로 등에 대한 물리적인 구조를 설계한다.

요약

1. 데이터베이스 설계의 과정

• 사용자의 다양한 요구 사항을 고려하여 데이터베이스를 생성하는 과정이다.
• E-R 모델과 변환 규칙을 이용한 설계와 정규화를 이용한 설계가 있다.
• E-R 모델과 릴레이션 변환 규칙을 이용한 설계 : 다음 5단계로 진행된다.

• 정규화를 이용한 설계 : 이상 현상을 제거하면서 올바르게 설계해나가는 방법으로, 9장에서 자세히 다룬다.

2. 요구 사항 분석

• 데이터베이스에 대한 사용자의 다양한 요구 사항을 수집하고 분석하여, 개발할 데이터베이스의 용도를 파악해 요구 사항 명세서를 작성한다.

3. 개념적 설계

• 요구 사항 명세서를 개념적 데이터 모델(개념적 스키마)로 표현한다.

4. 논리적 설계와 릴레이션 스키마 변환 규칙

• 다음 다섯 가지 릴레이션 변환 규칙에 따라 개념적 설계를 릴레이션 스키마(논리적 스키마)로 변환한다.

규칙	설명
규칙 1	모든 개체는 릴레이션으로 변환한다.
규칙 2	다대다 n:m 관계는 릴레이션으로 변환한다.
규칙 3	일대다 1:n 관계는 외래키로 표현한다.
규칙 4	일대일 1:1 관계는 외래키로 표현한다.
규칙 5	다중 값 속성은 독립 릴레이션으로 변환한다.

5. 물리적 설계와 구현

• 물리적 설계 : 필요한 인덱스 구조나 내부 저장 구조 등 물리적 구조를 설계한다.
• 구현 : SQL로 작성한 명령문을 DBMS에서 실행하여 데이터베이스를 생성한다.