데이터베이스 정규화 - 1

도메인 제약조건, 기본키 제약조건, 외래키 제약조건, 참조 무결성 제약 조건, general 제약조건 등이 데이터의 무결성을 위해서 사용되었었다.

다시말해서 정확한 데이터가 테이블에 들어가서 유지되도록 하는 제약 조건들이다.

Redundancy -> 중복성

테이블을 잘못 설계하면 데이터의 중복이 다수 발생 할 수 있다.

데이터 중복성을 없애는것이 좋은 데이터베이스 설계에 가장 중요하다고 할 수 있다.

함수 종속성이라는 또다른 무결성 제약조건을 이용해서 Redundancy를 가지고 있는 스키마를 식별해서 조치를 취할수 있다.

같은 데이터가 테이블내의 여러개 존재하면 저장공간을 낭비하게 되며, 여러가지 이상현상을 일으킬수 있다.

Schema refinement(스키마 개선)에 제일 중요한것이 데이터 중복을 없애기 위해 스키마를 작은것으로 작은 단위로 쪼개는것이다.

decomposition -> 테이블을 쪼개다.

ABCD라는 속성들을 갖는 테이블을 AB를 갖는 테이블과 BCD를 갖는 테이블로 나누는것이 예가 될수 있다.

B라는 속성이 두 테이블에 중복 되는 이유는 조인을 위해서 이다.

하나의 테이블을 다시 다른 테이블로 쪼개고 난 뒤 그 테이블들을 다시 조인했을때 원래의 테이블이 나오게끔 테이블을 잘 쪼개야 한다.

->이것을 무손실 조인이라고 한다.

테이블에 중복성이 있다고 해서 속성을 막 쪼개면 안되고 규칙을 따라야 한다.

X->Y

X와 Y는 테이블의 속성또는 속성의 집합이다.

X가 Y를 결정한다, Y는 X에 함수적(functional dependancy)으로 종속된다. 라고 해석하면 된다.

r은 튜플의 집합이다. 따라서 t1,t2는 한 테이블의 어떤 특정 튜플이다.

X -> Y의 의미는 t1,t2튜플에 대해 X속성에 대해 프로젝션 한 값이 t1,t2튜플에서 Y속성에 대해 프로젝션 한 값이 같아야 한다는 의미이다.

다시말해서 X가 Y를 결정한다는 임의의 두 튜플이 있을때 X로 프로젝션한 값이 같으면 Y로 프로젝션한 값도 서로 같아야 한다는 의미이다.

     x    y

t1 15 50

t2 15 50

t3 20 40

t4 15 50

t5 25 25 

위의 테이블에서 t1,t2에 대해서 적용해보면, t1,t2의 X에 대해 프로젝션한 값이 같을경우 ( 15) Y에 대해 프로젝션 한 값도 같음(50)

X값이 같으면 Y값도 서로 같다.

Hourly_Emps(ssn,name,lot,rating,hrly_wages,hrs_worked)

-> SNLRWH 의 속성의 앞글자만 따서 테이블을 표현할수 있음

모든 테이블은 반드시 하나 이상의 함수 종속성이 존재해야 한다(기본키가 존재하기때문에)

S라는 키가 NLRWH를 결정한다. -> 키가 같으면 두 튜플은 다른값들도 서로 같아야 한다. -> 실제 데이터베이스에 넣을수는 없음 -> 기본키 제약조건때문에 키가 같은 다른 두 튜플은 존재할수 없음 -> 이론적으로 생각하자.

테이블이 주어졌을때 함수종속성을 가지고 거꾸로 키를 찾는것을 할줄 알아야 한다.

어떤 속성의 값이 같은 두 튜플이 있을때 나머지 값들도 같다면 그것은 기본키이다.

R = Rating = 호봉

W = hrly_wages = 시급

R->W?일까?

호봉이 같으면 시급은 무조건 같을것이다. 하지만 W->R의 경우 시급이 같더라도 호봉은 다를수 있다.(7호봉과 8호봉의 시급이 같을수있다)

함수 종속성은 설계자가 찾아내야 하는것이다. -> 호봉이 시급을 결정한다 같은 정보.

맨 마지막 테이블에서 Attishoo의 W(시급)을 10에서 11로 올렸다고 해보자.

근데 이 사람의 호봉은 8이다. 다른 8호봉인 사람은 10의 시급을 받는데, 이 사람만 8호봉인데 11의 시급을 받는다.

-> 스키마 설계가 잘못 되었다. 제대로 고쳐주려면, 등급이 8호봉인 사람을 찾아서 시급을 모두 11로 고쳐야 한다.

-> anomaly(변칙,이례) 현상 이라고 한다. update 이상현상

또 다른 문제.

신입사원이 입사해서 1호봉인데, 1호봉에 얼마의 시급을 줘야 하는지 모르는 경우 일단 NULL로 설정해야 한다.

또는, 1호봉인 다른 사원의 시급을 검색해서 찾아내야 한다.

이런식으로 삽입할때 문제가 생기기도 한다. 

또 다른 문제.

5등급을 갖는 직원들의 데이터를 삭제하고 싶다.

호봉에 대한 시급에 대한 정보를 이 테이블이 유일하게 가지고 있을 경우,

5등급이 7의 시급을 받는다는 정보도 같이 날아가게 된다.

이런식으로 삭제할때 문제가 생기기도 한다.

뭐 때문에 이런 문제가 생겼을까?

호봉이 시급을 결정한다는 함수적 종속성 때문에 발생한것이다.

호봉->시급에 대한 정보를 한번만 나타내면 된다.

SNLRWH

SNLRH             RH

이런식으로 테이블을 2개로 쪼개면 문제가 사라진다. R은 조인을 위해서 서로의 테이블에 존재해야 한다.

이렇게 쪼갤 경우 아까의 문제가 해결 되는지 알아보자.

업데이트 이상 현상

8등급에 대한 시급을 10에서 11로 인상시키고 싶을 경우

RH를 가진 테이블의 한 튜플에 대한 정보만 수정하면 됨. 아까처럼 모든 8등급을 가지는 데이터를 검색한다음에 시급을 바꿔주지 않아도 됨.

삽입 이상 현상

1등급에 대한 사원의 시급정보를 모르는 경우 큰 테이블을 다 찾아서 1등급에 대한 시급을 알아내지 않고, 작게 분해된 RH속성만을 갖는

테이블만 조사 해서 삽입하면 됨.

삭제 이상 현상

8호봉에 대한 시급 정보를 삭제하고 싶을때 다른 사원의 정보는 SNLRH에 유지되면서 호봉과 시급에 대한 정보만 깔끔하게 삭제됨.

키가 아닌것들이 다른 속성을 결정하기 때문에 이런 데이터 중복성 문제가 발생하는 것이다.

-> 키가 아니라는것은 중복이 가능하다는 얘기이다. 그렇기 때문에 그 키가 아닌것들을 키로 만들어서 중복값을 갖지 못하게 해주면 된다.