3학년 2학기 데이터베이스 시스템 기말

5. DB 설계와 ER모델
데이터베이스 설계
개념적 DB설계 vs 물리적 DB설계
개념적 DB설계: 실제로 DB를 어떻게 구현할 것인가와 독립적으로 정보 사용의 모델을 개발하는 과정
물리적 DB설계: 물리적인 저장 장치와 접근 방식 다룸
개념적 DB 설계 과정에서 조직체의 엔티티, 관계, 프로세스, 무결성 제약조건 등을 나타내는 추상화 모델을 구축
엔티티는 서로 구분이 되면서 조직체에서 DB에 나타내려는 객체(사람, 장소, 사물 등)를 의미
관계: 두 개 이상의 엔티티들 간의 연관을 나타냄
프로세스: 관련된 활동
무결성 제약조건: 데이터의 정확성과 비즈니스 규칙을 의미
개념적 수준의 모델
특정 데이터 모델과 독립적으로 응용 세계를 모델링할 수 있도록 함
DB 구조나 스키마를 하향식으로 개발할 수 있기 위한 틀을 제공
인기 있는 개념적 수준 모델은 엔티티-관계 모델(ER)
ER 모델과 같은 개념적인 데이터 모델이 사상 될 수 있는 다수의 구현 데이터 모델이 존재
구현 단계에서 사용되는 세 가지 데이터 모델: 관계, 계층, 네트워크 데이터 모델
5.1 데이터베이스 설계의 개요
DB설계 개요
한 조직체의 운영과 목적을 지원하기 위해 DB를 생성하는 과정
목적: 모든 주요 응용과 사용자들이 요구하는 데이터, 데이터간의 관계를 표현하는 것
DB 개발은 일반적인 프로젝트 라이프 사이클 과정을 따름
훌륭한 DB 설계
 시간의 흐름에 따른 데이터의 모든 측면 표현
 데이터 항목 중복 최소화
 효율적인 접근 제공
 무결성 제공
 
DB설계 주요 단계
요구사항 분석, 개념적 
설계, DBMS 선정, 논리적 설계, 스키마 정제, 물리적 설계와 튜닝
일반적으로 DB 설계 완성도 위해 왔다갔다
 
요구사항 수집, 분석
기존 문서 조사, 인터뷰, 설문조사 시행
인터뷰: 요구사항 수집을 위해 가장 흔히 사용됨
설문조사: 자유롭게 의견을 적어내도록 하는 방식, 주어진 질문에 대해서만 답을 하는 방식
요구사항에 관한 지식을 기반으로 관련 있는 엔티티들과 이들의 애트리뷰트들이 무엇인가, 엔티티들 간의 관계가 무엇인가 파악
데이터 처리에 관한 요구사항에 대해 전형적인 연산들은 무엇인가, 연산들의 의미, 접근하는 데이터의 양 분석
개념적 설계
모든 물리적인 사항과 독립적으로, 한 조직체에서 사용되는 정보의 모델을 구축하는 과정
사용자들의 요구사항 명세로부터 개념적 스키마가 만들어짐
높은 추상화 수준의 데이터 모델을 기반으로 정형적인 언어로 데이터 구조 명시
개념적 설계 단계 
 엔티티 타입, 관계 타입, 애트리뷰트들 식별
 애트리뷰트들의 도메인 결정
 후보키, 기본키 애트리뷰트들 결정
완성된 개념적 스키마는 ER다이어그램으로 표현됨
DBMS 선정
여러가지 요인 검토  DBMS 선정
기술적 요인: DBMS가 제공하는 데이터 모델, 저장 구조, 인터페이스, 질의어, 도구, 제공되는 서비스
정치적 요인: 고수준의 전력적인 결정
경제적 요인: DBMS 구입, 하드웨어 구입, 유지보수, 변환 소요 비용, 인건비, 교육비
논리적 설계
DB관리 위해 선택한 DBMS의 데이터 모델을 사용하여 논리적 스키마(외부 스키마 포함) 생성
개념적 스키마에 알고리즘 적용 논리적 스키마 생성
논리적 스키마 나타내기 위해 관계 데이터 모델 사용하는 경우 ER모델로 표현된 개념적 스키마를 관계 DB스키마로 사상함
관계 DB 스키마를 더 좋은 관계 DB 스키마로 변환 위해 정규화 과정 적용
DB 설계자가 요구사항 수집과 분석 후 바로 논리적 설계 단계 ㄴㄴ
물리적 설계
처리 요구사항 만족위해 저장 구조와 접근 경로 결정
성능상 기준
 응답 시간: 질의와 갱신이 평균적 OR 피크 시간 때얼마나 오래 걸릴 것인가
 트랜잭션 처리율: 1초당 얼마나 많은 트랜잭션들이 평균적 or 피크 시간 때 처리될 수 있는가
 전체 DB에 대한 보고서 생성하는데 얼마나 오래 걸릴 것인가
트랜잭션 설계
요구사항 수집, 분석 후 DB설계 과정과 별도로 트랜잭션 설계를 진행할 수 있음
트랜잭션은 완성될 DB에서 동작할 응용 프로그램
DB 스키마는 트랜잭션에서 요구하는 모든 정보를 포함해야 함
검색, 갱신, 혼합 등 세가지 유형으로 구분해 입력과 출력, 동작 등을 식별
5.2 ER 모델
DB 설계를 용이하기위해 P.P. Chen이 1976년에 제안
현재 Enhanced Entity Relationship 모델이 DB 설계 과정에 널리 사용
개념적 설계 위한 인기 있는 모델
실세계를 엔티티, 애트리뷰트, 엔티티들 간의 관계로 표현
기본적 구문: 엔티티, 관계, 애트리뷰트
기타 구문: 카디날리티 비율, 참여 제약 조건
 
5.2.1 엔티티
엔티티: 하나의 엔티티는 사람, 장소, 사물, 사건 등과 같이 독립적으로 존재하면서 고유하게 식별이 가능한 실세계의 객체
5.2.2 엔티티 타입
엔티티들은 엔티티 타입(or 집합)들로 분류
엔티티 타입은 동일한 애트리뷰트들을 가진 엔티티의 틀
엔티티 집합은 동일한 애트리뷰트들을 가진 엔티티들의 모임
하나의 엔티티는 한 개 이상의 엔티티 집합에 속할 수 있음
엔티티 타입은 내포에 해당 엔티티 집합은 외연에 해당
강한 엔티티 타입(정규 엔티티 타입): 독자적으로 존재, 엔티티 타입 내에서 자신의 키 애트리뷰트를 사용해 고유하게 엔티티들을 식별할 수 있는 엔티티 타입
약한 엔티티 타입: 키를 형성하기에 충분한 애트리뷰트들을 갖지 못한 엔티티 타입
이 엔티티 타입이 존재하려면 소유 엔티티 타입이 있어야 함
소유 엔티티 타입의 키 애트리뷰트를 결합해야만 고유하게 약한 엔티티 탑의 엔티티들을 식별할 수 있음
5.2.3 애트리뷰트
하나의 엔티티는 연관된 애트리뷰트들의 집합으로 설명 됨
한 애트리뷰트의 도메인은 그 애트리뷰트가 가질 수 있는 모든 가능한 값들의 집합을 의미
여러 애트리뷰트가 동일한 도메인을 공유할 수 있음
키 애트리뷰트는 한 애트리뷰트 또는 애트리뷰트들의 모임으로서 한 엔티티 타입 내에서 각 엔티티를 고유하게 식별함
ER 다이어그램에서 기본 키에 속하는 애트리뷰트는 밑줄을 그어 표시함
엔티티는 독립적 의미, 애트리뷰트는 독립적 의미X
ER 다이어그램에서 타원형으로 나타냄
애트리뷰트와 엔티티 타입은 실선으로 연결
단순 애트리뷰트
더 이상 다른 애트리뷰트로 나눌 수 없는 애트리뷰트
ER 다이어그램에서 실선 타원으로 표현
ER 다이어그램에서 대부분의 애트리뷰트는 단순 애트리뷰트
 
복합 애트리뷰트
두 개 이상의 애트리뷰트로 이루어진 애트리뷰트
동일한 엔티티 타입이나 관계 타입에 속하는 애트리뷰트들 중에서 밀접하게 연관된 것을 모아놓은 것

 
단일 값 애트리뷰트
각 엔티티마다 정확하게 하나의 값을 갖는 애트리뷰트
ER다이어그램에서 단순 애트리뷰트와 동일하게 표현
Ex) 사원의 사원번호 애트리뷰트는 어떤 사원도 두 개 이상의 사원번호를 갖지 않으므로 단일 값 애트리뷰트
ER다이어그램에서 대부분의 애트리뷰트는 단일 값 애트리뷰트
다치 애트리뷰트
각 엔티티마다 여러 개의 값을 가질 수 있는 애트리뷰트
ER 다이어그램에서 이중선 타원으로 표현
 
저장된 애트리뷰트
다른 애트리뷰트와 독립적으로 존재하는 애트리뷰트
ER 다이어그램에서 단순 애트리뷰트와 동일하게 표현
ER 다이어그램에서 대부분의 애트리뷰트는 저장된 애트리뷰트
유도된 애트리뷰트
다른 애트리뷰트의 값으로부터 얻어진 애트리뷰트
관계 데이터베이스에서 릴레이션의 애트리뷰트로 포함시키지 않는 것이 좋음
ER 다이어그램에서 점선 타원으로 표현
 
 
약한 엔티티 타입
5.2.4 약한 엔티티 타입
키를 형성하기에 충분한 애트리뷰트들을 갖지 못한 엔티티 타입
소유 엔티티 타입(식별 엔티티 타입): 약한 엔티티 타입에게 키 애트리뷰트를 제공하는 엔티티 타입
ER 다이어그램에서 이중선 직사각형으로 표기
약한 엔티티 타입의 부분키는 점선 밑줄을 그어 표시
부분 키(=구분자): 부양가족의 이름처럼 한 사원에 속한 부양가족 내에서는 서로 다르지만 회사 전체 사원들의 부양가족들 전체에서는 같은 경우가 생길 수 있는 애트리뷰트
 
5.2.5 관계와 관계 타입
관계와 관계 타입
관계는 엔티티들 사이에 존재하는 연관이나 연결로서 두 개 이상의 엔티티 타입들 사이의 사상으로 생각할 수 있음
관계 집합은 동질의 관계들의 집합
관계 타입은 동질의 관계들의 틀
요구사항 명세에서 흔히 동사는 ER 다이어그램에서 관계로 표현
ER 다이어그램에서 다이아몬드로 표기
관계 타입이 서로 연관시키는 엔티티 타입들을 관계 타입에 실선으로 연결함
 
 
관계의 애트리뷰트
관계 타입은 관계의 특징을 기술하는 애트리뷰트들을 가질 수 있음
관계 타입은 키 애트리뷰트를 갖지 않음
 
차수
관계로 연결된 엔티티 타입들의 개수 의미
실세계에서 가장 흔한 관계는 두 개의 엔티티 타입을 연결하는 2진 관계
 
카디날리티
카디날리티 비율은 한 엔티티가 참여할 수 있는 관계의 수를 나타냄
관계타입에 참여하는 엔티티들의 가능한 조합 제한 함
카디날리티에 관한 정보는 간선 위에 나타냄
 
카디날리티 비율의 최소값과 최대값
ER 다이어그램에서 관계 타입과 엔티티 타입을 연결하는 실선 위에(min, max) 형태로 표기
어떤 관계 타입에 참여하는 각 엔티티 타입에 대하여 min은 이 엔티티 타입 내의 각 엔티티는 적어도 min번 관계에 참여함을 의미
max는 이 엔티티 타입 내의 각 엔티티는 최대한 max번 관계에 참여함을 의미
min=0은 어떤 엔티티가 반드시 관계에 참여해야 할 필요는 없음을 의미
max=*는 어떤 엔티티가 관계에 임의의 수만큼 참여할 수 있음을 의미
 
 
역할
관계 타입의 의미를 명확하게 하기 위해 사용됨
특히 하나의 관계 타입에 하나의 엔티티 타입이 여러 번 나타나는 경우에는 반드시 역할을 표기해야 함
관계 타입을 간선 위에 표시
 
전체 참여 & 부분 참여
전체 참여: 어떤 관계에 엔티티 타입 E1의 모든 엔티티들이 관계 타입 R에 의해서 어떤 엔티티 타입 E2의 어떤 엔티티와 연관되는 것을 의미
부분 참여: 어떤 관계에 엔티티 타입 E1의 일부 엔티티 참여하는 것을 의미
약한 엔티티 타입은 항상 관계에 전체 참여
전체 참여는 ER 다이어그램에서 이중 실선으로 표시
카디날리티 비율과 함께 참여 제약조건은 관계에 대한 중요한 제약조건
 
다중 관계
두 엔티티 타입 사이에 두 개 이상의 관계 타입이 존재할 수 있음
 
순환적 관계
하나의 엔티티 타입이 동일한 관계 타입에 두 번 이상 참여하는 것
 
5.2.6 ER 스키마를 작성하기 위한 지침
엔티티는 키 애트리뷰트 이외에 설명 정보를 추가로 가짐
다치 애트리뷰트는 엔티티로 분류해야 함
애트리뷰트들이 직접적으로 설명하는 엔티티에 애트리뷰트들을 붙임
가능한 한 복합 식별자를 피함
관계는 일반적으로 독자적으로 존재 할 수 없지만 엔티티 타입과 관계 타입을 절대적으로 구분 어려움
 
 
5.2.7 데이터베이스 설계 과정
응용의 요구사항을 수집하는 기술
응용과 연관이 있는 엔티티 타입들을 식별
응용과 연관이 있는 관계 타입들을 식별
관계 1:1, 1:N, M:N 중에서 어느 것에 해당하는지 결정
엔티티 타입과 관계 타입들에 필요한 애트리뷰트들을 식별, 각 애트리뷰트가 가질 수 있는 값들의 집합을 식별
엔티티 타입들을 위한 기본 키 식별
응용 위한 ER 스키마 다이어그램 그림
ER 스키마 다이어그램이 응용에 대한 요구사항과 부합되는지 검사
ER 스키마 다이어그램을 DBMS에서 사용되는 데이터베이스 모델로 변환
5.2.8 ER 모델의 또 다른 표기법
 
5.3 데이터베이스 설계 사례
5.4 논리적 설계: ER 스키마를 관계 모델의 리레이션들로 사상
5.4.1 ER-릴레이션 사장 알고리즘
 
 
단계 1: 정규 엔티티 타입과 단일 값 애트리뷰트
ER 스키마의 각 정규 엔티티 타입 E에 대해 하나의 릴레이션 R을 생성
E에 있던 단순 애트리뷰트들을 릴레이션 R에 모두 포함시킴
E에서 복합 애트리뷰트는 그 복합 애트리뷰트를 구성하는 단순 애트리뷰트들만 릴레이션 R에 포함시킴
E의 기본 키가 릴레이션 R의 기본키가 됨
 
단계 2: 약한 엔티티 타입과 단일 값 애트리뷰트
ER스키마에서 소유 엔티티 타입 E를 갖는 각 약한 엔티티 타입 W에 대하여 릴레이션 R을 생성함
W에 있던 모든 단순 애트리뷰트들을 릴레이션 R에 포함시킴
소유 엔티티 타입에 해당하는 릴레이션의 기본키를 약한 엔티티 타입에 해당하는 릴레이션에 외래키로 포함시킴
약한 엔티티 타입에 해당하는 릴레이션 R의 기본 키는 약한 엔티티 타입의 부분 키와 소유 엔티티 타입에 해당하는 릴레이션을 참조하는 외래 키의 조합으로 이루어짐
 
단계 3: 2진 1:1 관계 타입
ER 스키마의 각 2진 1:1 관계 타입 R에 대하여, R에 참여하는 엔티티 타입에 대응되는 릴레이션 S와 T를 찾음
S와 T중에서 한 릴레이션을 선택하여, 만일 S를 선택했다면 T의 기본키를 S에 외래키로 포함시킴
S와 T중에서 관계 타입에 완전하게 참여하는 릴레이션을 S의 역할을 하는 릴레이션으로 선택함
관계 타입 R이 가지고 있는 모든 단순 애트리뷰트(복합 애트리뷰트를 갖고 있는 경우 복합 애트리뷰트 구성하는 단순 애트리뷰트)들을 S에 대응되는 릴레이션에 포함시킴
두 엔티티 타입이 관계 타입 R에 완전하게 참여할 때는 두 엔티티 타입과 관계 타입을 하나의 릴레이션으로 합치는 방법도 가능
  
단계 4: 정규 2진 1:N 관계 타입
정규 2진 1:N 관계 타입 R에 대하여 N측의 참여 엔티티 타입에 대응되는 릴레이션 S를 찾음
관계 타입 R에 참여하는 1측의 엔티티 타입에 대응되는 릴레이션 T의 기본키를 릴레이션 S에 외래 키로 포함시킴
N측의 릴레이션 S의 기본키를 1측의 릴레이션 T에 외래키로 포함시키면 애트리뷰트에 값들의 집합이 들어가거나 정보의 중복이 많이 발생함
관계 타입 R이 가지고 있는 모든 단순 애트리뷰트(복합 애트리뷰트를 갖고 있는 경우엔 복합 애트리뷰트를 구성하는 단순 애트리뷰트)들을 S에 해당하는 릴레이션에 포함시킴
 
단계 5: 2진 M:N 관계 타입
2진 M:N 관계 타입 R에 대해서는 릴레이션 R을 생성함
참여 엔티티 타입에 해당하는 릴레이션들의 기본키를 릴레이션 R에 외래키로 포함시키고, 이들의 조합이 릴레이션 R의 기본 키가 됨
관계 타입 R이 가지고 있는 모든 단순 애트리뷰트(복합 애트리뷰트를 갖고 있는 경우에는 복합 애트리뷰트를 구성하는 단순 애트리뷰트)들을 릴레이션 R에 포함시킴
 
단계 6: 3진 이상의 관계 타입
3진 이상의 각 관계 타입 R에 대하여 릴레이션 R을 생성함
관계 타입 R에 참여하는 모든 엔티티 타입에 대응되는 릴레이션들의 기본키를 릴레이션 R에 외래 키로 포함시킴
관계 타입 R이 가지고 있는 모든 단순 애트리뷰트(복합 애트리뷰트를 갖고 있는 경우엔 복합 애트리뷰트를 구성하는 단순 애트리뷰트)들을 릴레이션 R에 포함시킴
일반적으로 외래키들의 조합이 릴레이션 R의 기본키가 됨
관계 타입 R에 참여하는 엔티티 타입들의 카디날리티가 1:N:N이면 카디날리티가 1인 릴레이션의 기본키를 참조하는 외래키를 제외한 나머지 외래키들의 조합이 릴레이션 R의 기본키가 됨
 
단계 7: 다치 애트리뷰트
각 다치 애트리뷰트에 대하여 릴레이션 R을 생성함
다치 애트리뷰트에 해당하는 애트리뷰트를 릴레이션 R에 포함시키고, 다치 애트리뷰트를 애트리뷰트로 갖는 엔티티 타입이나 관계 타입에 해당하는 릴레이션의 기본키를 릴레이션 R에 외래키로 포함시킴
릴레이션 R의 기본키는 다치 애트리뷰트와 외래키의 조합
 
5.4.2 데이터베이스 설계 사례에 알고리즘 적용
 
 
 
단계 1: 정규 엔티티 타입과 단일 값 애트리뷰트
다치 애트리뷰트인 LOCATION 신경안씀… 뺌
EMPLOYEE(Empno, Empname, Title, City, Ku, Dong,      
     Salary)
PROJECT(Projno, Projname, Budget)
DEPARTMENT(Deptno, Deptname, Floor)
SUPPLIER(Suppno, Suppname, Credit)
PART(Partno, Partname, Price)
단계 2: 약한 엔티티 타입과 단일 값 애트리뷰트
DEPENDENT(Empno, Depname, Sex)
단계 3: 2진 1:1 관계 타입
Project – s employee – t … employee릴레이션 기본키를 project릴레이션에 employee 릴레이션 참조하는 외래키(manager) 추가 
PROJECT(Projno, Projname, Budget, StartDate, Manager)
단계 4: 정규 2진 1:N 관계 타입
BELONGS, CONTAINS 가 정규 2진 1:N 타입
POLICY 2진 1:N 타입
EMPLOYEE 엔티티 타입이 N측에 참여하므로 EMPLOYEE 릴레이션을 S
BELONGS 관계 타입에 참여하는 1측의 엔티티 타입에 대응되는 릴레이션이 DEPARTMENT이므로 이를 T라 한다.
T의 기본키를 S에 외래키로 포함시킨다.
EMPLOYEE(Empno, Empname, Title, City, Ku, Dong,             Salary, Dno)
PART(Partno, Partname, Price, Subpartno)
단계 5: 2진 M:N 관계 타입
새로운 릴레이션 생성
WORKS_FOR(Empno, Projno, Duration, Responsibility)
단계 6: 3진 이상의 관계 타입
새로운 릴레이션 생성
각 연결 릴레이션의 기본키의 조합이 새로운 릴레이션의 기본키
 SUPPLY(Suppno, Projno, Partno, Quantity)
단계 7: 다치 애트리뷰트
새로운 릴레이션 생성
원래 있던 키 가져오고(외래키로) 지꺼 쓰고
PROJ_LOC(Projno, Location)
 
7. 릴레이션 정규화
릴레이션 정규화
부주의한 DB설계는 제어할 수 없는 데이터 중복을 야기하여 여러가지 수정 이상(modification anomaly)을 유발함
정규화(normalization)는 주어진 릴레이션 스키마를 함수적 종속성과 기본키를 기반으로 분석하여, 원래의 릴레이션을 분해함으로써 중복과 세 가지 수정 이상을 최소화함
7.1 정규화 개요
좋은 관계 DB 스키마 설계 목적
정보의 중복과 수정 이상 생기지X
정보 손실 막기
실세계 훌륭히 나타냄
애트리뷰트들 간 관계가 잘 표현 보장
무결성 제약조건 시행 간단히
효율성 측면 고려
수정 이상(modification anomaly)
갱신 이상(update anomaly): 반복된 데이터 중에 일부만 수정하면 데이터의 불일치가 발생
삽입 이상(insertion anomaly): 불필요한 정보를 함께 저장하지 않고는 어떤 정보를 저장하는 것이 불가능
삭제 이상(deletion anomaly): 유용한 정보를 함께 삭제하지 않고는 어떤 정보를 삭제하는 것이 불가능
 
 
 
 
문제점
정보의 중복: 각 사원이 속한 부서 수만큼 동일한 사원들의 튜플들이 존재하므로 사원이름, 사원번호, 주소, 전화번호 등이 중복되어 저장 공간이 낭비 됨
갱신 이상: 만일 어떤 부서의 이름이 바뀔 때 이 부서에 근무하는 일부 사원 튜플에서만 부서이름을 변경하면 데이터베이스가 불일치 상태에 빠짐
삽입 이상: 만일 어떤 부서를 신설했는데 아직 사원을 한 명도 배정하지 않았다면 이 부서에 관한 정보를 입력할 수 없음.
삭제 이상: 만일 어떤 부서에 속한 사원이 단 한 명이 있는데, 이 사원에 관한 튜플을 삭제하면 이 사원이 속한 부서에 관한 정보도 릴레이션에서 삭제됨
릴레이션 분해
하나의 릴레이션을 두 개 이상의 릴레이션으로 나누는 것
릴레이션의 분해는 필요한 경우에는 분해된 릴레이션들로부터 원래의 릴레이션을 다시 구할 수 있음을 보장해야 한다는 원칙
분해를 잘못하면 두 릴레이션으로부터 얻을 수 있는 정보가 원래의 릴레이션이 나타내던 정보보다 적을 수도 있고 많을 수도 있음
릴레이션의 분해는 릴레이션에 존재하는 함수적 종속성에 관한 지식을 기반으로 함
 
관계 DB 설계의 비공식적인 지침
지침 1: 이해하기 쉽고 명확한 스키마 생성
지침 2: 널값을 피하라
지침 3: 가짜 튜플이 생기지 않도록
지침 4: 스키마를 정제
7.2 함수적 종속성
함수적 종속성의 개요
정규화 이론의 핵심
릴레이션의 애트리뷰트들의 의미로부터 결정됨
릴레이션 스키마에 대한 주장O, 릴레이션의 특정 인스턴스에 대한 주장X
릴레이션의 가능한 모든 인스턴스들이 만족해야 함
실세계에 대한 지식과 응용의 의미를 기반으로 어떤 함수적 종속성들이 존재하는가를 파악해야 함
함수적 종속성은 제2정규형부터 BCNF까지 적용됨]
결정자(determinant)
어떤 애트리뷰트의 값은 다른 애트리뷰트의 값을 고유하게 결정할 수 있음
결정자는 주어진 릴레이션에서 다른 애트리뷰트(또는 애트리뷰트들의 집합)를 고유하게 결정하는 하나 이상의 애트리뷰트를 의미
 
함수적 종속성
애트리뷰트 A가 애트리뷰트 B의 결정자이면 B가 A에 함수적으로 종속한다고 말함
== 주어진 릴레이션 R에서 애트리뷰트 B가 애트리뷰트 A에 함수적으로 종속하는 필요 충분 조건은 각 A 값에 대해 반드시 한 개의 B값이 대응된다는 것
 
완전 함수적 종속성(Full Functional Dependency)
주어진 릴레이션 R에서 애트리뷰트 B가 애트리뷰트 A에 함수적으로 종속하면서 애트리뷰트 A의 어떠한 진부분 집합에도 함수적으로 종속하지 않으면 애트리뷰트 B가 애트리뷰트 A에 완전하게 함수적으로 종속한다고 말함
 
 
이행적 함수적 종속성(Transitive FD)
한 릴레이션의 애트리뷰트 A, B, C가 주어졌을 때 애트리뷰트 C가 이행적으로 A에 종속한다(AC)는 것의 필요 충분 조건은 AB ^ BC 가 성립하는 것
 
7.3 릴레이션 분해
릴레이션 분해
릴레이션을 분해하면 중복이 감소되고 갱신 이상이 줄어드는 장점이 있는 반면에, 바람직하지 않은 문제들을 포함하여 몇 가지 잠재적인 문제들을 야기할 수 있음
릴레이션이 분해되기 전에는 조인이 필요 없는 질의가 분해 후에는 조인을 필요로 하는 질의로 바뀔 수 있음
분해된 릴레이션들을 사용하여 원래 릴레이션을 재구성하지 못할 수 있음
무손실 분해(lossless decomposition)
분해된 두 릴레이션을 조인하면 원래의 릴레이션에 들어 있는 정보를 완전하게 얻을 수 있음
여기서 손실이란 정보의 손실을 뜻함
정보의 손실은 원래의 릴레이션을 분해한 후에 생성된 릴레이션들을 조인한 결과에 들어 있는 정보가 원래의 릴레이션에 들어 있는 정보보다 적거나 많은 것을 모두 포함
 
학번  이름, 이메일
이메일  학번, 이름
(학번, 과목번호)  학점
 
 
 
7.4 제 1,2,3 정규형, BCNF
7.4.1 제1정규형
한 릴레이션 R이 제1정규형을 만족할 필요 충분 조건은 릴레이션 R의 모든 애트리뷰트가 원자값만을 갖는다는 것
즉 릴레이션의모든 애트리뷰트에 반복 그룹(repeating group)이 나타나지 않으면 제1정규형을 만족함
 
제1정규형 변환법
반복 그룹 애트리뷰트에 나타나는 집합에 속한 각 값마다 하나의 튜플로 표현
 
모든 반복 그룹 애트리뷰트들을 분리해서 새로운 릴레이션에 넣음. 원래 릴레이션의 기본키를 새로운 릴레이션에 애트리뷰트로 추가함
제1정규형에 존재하는 수정 이상
 
위 릴레이션은 모든 애트리뷰트가 원자값을 가지므로 제1정규형을 만족
기본키: (학번, 과목번호)
갱신 이상
한 학과에 소속한 학생 수만큼 그 학과의 전화번호가 중복되어 저장되므로 여러 학생이 소속된 학과의 전화번호가 변경되었을 때 그 학과에 속한 모든 학생들의 튜플에서 전화번호를 갱신하지 않으면 데이터베이스의 일관성이 유지되지 않음
삽입 이상
한 명의 학생이라도 어떤 학과에 소속되지 않으면 이 학과에 관한 튜플을 삽입할 수 없음. 왜냐하면 학번이 기본 키의 구성요소인데 엔티티 무결성 제약조건에 따라 기본 키에 널값을 입력할 수 없기 때문
삭제 이상
어떤 학과에 소속된 마지막 학생 튜플을 삭제하면 이 학생이 소속된 학과에 관한 정보도 삭제됨
갱신 이상 발생 이유
기본키에 대한 부분 함수적 종속성이 학생 릴레이션에 존재함
 
7.4.2 제2정규형
한 릴레이션 R이 제2정규형을 만족할 필요 충분 조건은 릴레이션 R이 제1정규형을 만족하면서, 어떤 후보키에도 속하지 않는 모든 애트리뷰트들이 R의 기본키에 완전하게 함수적으로 종속하는 것
기본키가 두 개 이상의 애트리뷰트로 구성되었을 경우에만 제1정규형이 제2정규형을 만족하는가를 고려할 필요가 있음
제2정규형에 존재하는 수정 이상
기본키는 한 애트리뷰트인 학번이므로 제2정규형 만족
 
갱신, 삽입, 삭제 이상 제1정규형과 같음
수정 이상이 생기는 이유
학생 릴레이션에 이행적 종속성이 존재하기 때문
 
7.4.3 제3정규형
한 릴레이션 R이 제3정규형을 만족할 필요 충분 조건은 릴레이션 R이 제2정규형을 만족하면서, 키가 아닌 모든 애트리뷰트가 릴레이션 R의 기본 키에 이행적으로 종속하지 않는 것
제3정규형에 존재하는 수정 이상
 
학생 여러 과목 수강 가능O
강사는 한 과목만 가르침
릴레이션의 기본키 (학번, 과목)
키가 아닌 강사 애트리뷰트가 기본키에 완전하게 함수적으로 종속하므로 제2정규형을 만족, 키가 아닌 강사 애트리뷰트가 기본키에 직접 종속하므로 제3정규형도 만족
(학번, 과목) 강사 강사과목
 
갱신 이상
여러 학생이 수강 중인 어떤 과목의 강사가 변경되었을 때 그 과목을 수강하는 모든 학생들의 튜플에서 강사를 갱신하지 않으면 데이터베이스의 일관성이 유지되지 않음
삽입 이상
어떤 과목을 신설하여 아직 수강하는 학생이 없으면 어떤 강사가 그 과목을 가르친다는 정보를 입력할 수 없음 
왜냐하면 학번이 기본 키를 구성하는 애트리뷰트인데 엔티티 무결성 제약조건에 따라 기본 키를 구성하는 애트리뷰트에 널값을 입력할 수 없기 때문
삭제 이상
어떤 과목을 이수하는 학생이 한 명밖에 없는데 이 학생의 튜플을 삭제하면 그 과목을 가르치는 강사에 관한 정보도 함께 삭제됨
수정 이상 발생 이유
수강 릴레이션에서 키가 아닌 애트리뷰트가 다른 애트리뷰트를 결정하기 때문
위 릴레이션의 후보키는 (학번, 과목) 과 (학번, 강사)
7.4.4 BCNF
한 릴레이션 R이 BCNF를 만족할 필요 충분 조건은 릴레이션 R이 제3정규형을 만족하고, 모든 결정자가 후보키이어야 함
위의 수강 릴레이션에서 강사 애트리뷰트는 후보 키가 아님에도 불구하고 과목 애트리뷰트를 결정하기 때문에 BCNF가 아님
제3정규형을 만족하는 대부분의 릴레이션들은 BCNF도 만족함
하나의 후보키만을 가진 릴레이션이 제3정규형을 만족하면 동시에 BCNF도 만족함
제3정규형을 만족하는 릴레이션을 BCNF으로 정규화하려면 키가 아니면서 결정자 역할을 하는 애트리뷰트와 그 결정자에 함수적으로 종속하는 애트리뷰트를 하나의 테이블에 넣음. 이 릴레이션에서 결정자는 기본 키가 됨 
그 다음에는 기존 릴레이션에 결정자를 남겨서 기본 키의 구성요소가 되도록 함. 또한 이 결정자는 새로운 릴레이션에 대한 외래키 역할도 함
 
 
 
7.4.5 여러 정규형의 요약
 
7.4.6 ER 다이어그램과 정규화
7.5 역정규화
정규화 단계가 진행될수록 중복이 감소하고 갱신 이상도 감소됨
정규화가 진전될수록 무결성 제약조건을 시행하기 위해 필요한 코드의 양도 감소됨
정규화가 데이터베이스 설계의 중요한 요소이지만 성능상의 관점에서만 보면 높은 정규형을 만족하는 릴레이션 스키마가 최적인 것은 아님
한 정규형에서 다음 정규형으로 진행될 때마다 하나의 릴레이션이 최소한 두 개의 릴레이션으로 분해됨
분해되기 전의 릴레이션을 대상으로 질의를 할 때는 조인이 필요 없지만 분해된 릴레이션을 대상으로 질의를 할 때는 같은 정보를 얻기 위해서 보다 많은 릴레이션들을 접근해야 하므로 조인의 필요성이 증가함
때로 데이터베이스 설계자는 응용의 요구 사항에 따라 데이터베이스 설계의 일부분을 역정규화함으로써 데이터 중복 및 수정 이상을 대가로 치르면서 성능상의 요구를 만족시키기도 함
많은 데이터베이스 응용에서 검색 질의의 비율이 수정 질의의 비율보다 훨씬 높음. 역정규화는 주어진 응용에서 빈번하게 수행되는 검색 질의들의 수행 속도를 높이기 위해서 이미 분해된 두 개 이상의 릴레이션들을 합쳐서 하나의 릴레이션으로 만드는 작업
즉 역정규화는 보다 낮은 정규형으로 되돌아가는 것