외부활동/CS 면접 끝장내기 - 데이터베이스 1기

데이터베이스 4주차 스터디 정리

소프 2023. 8. 15.

이상현상

이상현상이란 테이블내의 데이터 중복성에 의해서 발생되는 데이터 불일치 현상이다.

 

삽입 이상(Insertion Anomaly)

특정 데이터가 존재하지 않아 중요한 데이터를 DB에 삽입할 수 없을때 발생

https://developer-talk.tistory.com/256

학생이 없어 기본키가 없으므로 삽입 불가

 

 

갱신 이상(Update Anomaly)

특정 데이터를 업데이트 했는데, 일부 튜플만 갱신되어 모순 발생

https://developer-talk.tistory.com/256

경영학과의 학과장 이름을 변경시 경영학과 학생의 모든 튜플을 수정하지 않으면 데이터 모순 발생

 

 

삭제 이상(Deletion Anomaly)

특정 정보를 삭제하면, 원치 않는 정보도 삭제되는 현상

https://developer-talk.tistory.com/256

 

이 모든건 정규화를 통해 해결 가능

 

함수 종속성이란?

데이터베이스 릴레이션에서 두 개의 속성 집합 간 제약의 일종이다

 

어떤 릴레이션 R에서, X와 Y를 각각 R의 속성(attribute) 집합의 부분 집합이라 하자. 속성(attribute) X의 값 각각에 대해 시간에 관계없이 항상 속성(attribute) Y의 값이 오직 하나만 연관되어 있을 때 Y는 X에 함수 종속이라 하고, X → Y라고 표기한다.

 

💡 X를 결정자(determinant set)이라 하고, Y를 종속자(dependent attribute)라고 한다.

R 내의 속성(attribute) 의 집합 X와 역시 R 내에 있는 또 다른 속성(attribute) 의 집합 Y에 대해, 각각의 X 값에 대해 최대 한 개의 Y 값에 연관되어 있을 때, 속성(attribute) 의 집합 X를 함수 결정(to functionally determine)하다고 한다.

 

차량과 엔진 배기량을 추적 관리하는 시스템을 설계한다고 가정하자. 각 차량에는 차량별 고유한 차량 식별 번호(VIN)을 부여한다. 그러면, "VIN → 배기량" 이라고 적을 수 있다. 차량 한 대에는 배기량 하나만 있는 것이 맞는 말이기 때문이다. (이 예제에서는 차량에 엔진이 하나만 달려 있다고 가정한다.) 그러나, "배기량 → VIN"이라고 적는 것은 틀린 것이다. 같은 배기량을 가진 여러 대의 차가 있을 수 있기 때문이다.

 

함수 종속은 애트리뷰 "배기량"이 후보 키 "VIN"과 함께 하나의 릴레이션 안에 배치될 수 있다는 가능성을 말해 주고 있다. 그러나 이러한 하나의 릴레이션 안에 배치되는 것이 항상 알맞은 일은 아니다. 예를 들어 함수 종속은 이행적(transitive) 함수 종속의 결과로 나타날 수도 있다.

VIN → 차량모델, 차량모델→차량배기량

위와 같은 경우 이행적(Transitivity) 함수 종속으로[2] 보통의 정규화된 관계가 성립되지 않는다.

 

완전 함수적 종속

종속자가 기본키에만 종속되며, 기본키가 여러 속성으로 구성되어 있을 경우 기본키를 구성하는 모든 속성이 포함된 기본키의 부분집합에 종속된 경우

https://velog.io/@busybean3/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%ED%95%A8%EC%88%98-%EC%A2%85%EC%86%8D%EC%84%B1Functional-Dependency

기본키(사원번호, 부서번호)를 통해서 종속자(직책)를 종속하는 경우를 완전 함수 종속이라 한다.

 

 

부분 함수적 족송

릴레이션에서 종속자가 기본키가 아닌 다른 속성에 종속되거나, 기본키가 여러 속성으로 구성되어 있을 경우 기본키를 구성하는 속성 중 일부만 종속된 경우

https://dncjf64.tistory.com/manage/newpost/438?type=post&returnURL=https%3A%2F%2Fdncjf64.tistory.com%2F438

 

부분 함수 종속의 경우 기본키 중 사원번호를 통해서 종속자(사원이름, 주소, 전화번호)을 종속 할 수 있으며, 기본키 중 부서번호를 통해서 종속자(부서이름)을 종속 할 수 있다.

이를 우리는 부분 함수 종속이라고 한다.

 

이행적 함수적 종속

릴레이션에서 X, Y, X라는 3 개의 속성이 있을 때, X -> Y, Y -> Z 이란 종속관계가 있을 경우, X -> Z가 성립될 때 이행적 함수 종속이라고 한다. 즉 X를 알면 Y를 알고 그를 통해 Z를 알 수 있는 경우

https://velog.io/@busybean3/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%ED%95%A8%EC%88%98-%EC%A2%85%EC%86%8D%EC%84%B1Functional-Dependency

X(사원번호)를 통해서 Y(사원이름)을 종속할 수 있다. Y(사원이름)를 통해서 Z(주소, 전화번호, 직책)등을 종속 할 수 있다.

또한 X(사원번호)를 통해서 Z(주소, 전화번호, 직책)등을 종속할 수 있으므로 이는 이행 함수 종속이 되는 것이다.

 

 

정규화

 

정규화는 테이블 간에 중복된 데이터를 허용하지 않는 다는 것이다.

무결성을 유지할 수 있으며, DB의 저장 용량도 줄일 수 있다.

테이블을 어떻게 분해하는지에 따라 정규화 단계가 달라지낟.

 

제1 정규화

테이블 칼럼이 원자값(atomic value)을 갖도록 테이블을 분해하는 것이다.

원자값이란 더 이상 쪼개질 수 없는 단위를 말한다.

https://mangkyu.tistory.com/110

1 정규화를 적용하면 아래와 같다.

 

https://dncjf64.tistory.com/manage/newpost/438?type=post&returnURL=https%3A%2F%2Fdncjf64.tistory.com%2F438

 

제2 정규화

제1 정규화를 진행한 테이블에 대해 완전 함수 종속을 만족하도록 테이블을 분해하는 것

완전 함수 종속이란 기본키의 부분집합이 결정자가 되어선 안된다는 것이다.

https://mangkyu.tistory.com/110

이 테이블에서 기본키는 (학생번호, 강좌이름)으로 복합키이다. 그리고 (학생번호, 강좌이름)인 기본키는 성적을 결정하고 있다. (학생번호, 강좌이름) --> (성적)
그런데 여기서 강의실이라는 컬럼은 기본키의 부분집합인 강좌이름에 의해 결정될 수 있다. (강좌이름) --> (강의실)
즉, 기본키(학생번호, 강좌이름)의 부분키인 강좌이름이 결정자이기 때문에 위의 테이블의 경우 다음과 같이 기존의 테이블에서 강의실을 분해하여 별도의 테이블로 관리하여 제2 정규형을 만족시킬 수 있다.

 

https://mangkyu.tistory.com/110

 

제3 정규화

제2 정규화를 진행한 테이블에 대해 이행적 종속을 없애도록 테이블을 분해하는 것이다.

여기서 이행적 종속이라는 것은 A -> B, B -> C가 성립할 때 A -> C가 성립되는 것을 의미한다.

https://mangkyu.tistory.com/110

기존의 테이블에서 학생 번호는 강좌 이름을 결정하고 있고, 강좌 이름은 수강료를 결정하고 있다. 그렇기 때문에 이를 (학생 번호, 강좌 이름) 테이블과 (강좌 이름, 수강료) 테이블로 분해해야 한다. 

이행적 종속을 제거하는 이유는 비교적 간단하다. 예를 들어 501번 학생이 수강하는 강좌가 스포츠경영학으로 변경되었다고 하자. 이행적 종속이 존재한다면 501번의 학생은 스포츠경영학이라는 수업을 20000원이라는 수강료로 듣게 된다. 

물론 강좌 이름에 맞게 수강료를 다시 변경할 수 있지만, 이러한 번거로움을 해결하기 위해 제3 정규화를 하는 것이다.

즉, 학생 번호를 통해 강좌 이름을 참조하고, 강좌 이름으로 수강료를 참조하도록 테이블을 분해해야 하며 그 결과는 다음의 그림과 같다.

https://mangkyu.tistory.com/110

BCNF 정규화

제3 정규화를 진행한 테이블에 대해 모든 결정자가 후보키가 되도록 테이블을 분해하는 것이다.

예를 들어 다음과 같은 특강수강 테이블이 존재한다고 하자.

https://mangkyu.tistory.com/110

특강수강 테이블에서 기본키는 (학생번호, 특강이름)이다. 그리고 기본키 (학생번호, 특강이름)는 교수를 결정하고 있다. 또한 여기서 교수는 특강이름을 결정하고 있다.

그런데 문제는 교수가 특강이름을 결정하는 결정자이지만, 후보키가 아니라는 점이다. 그렇기 때문에 BCNF 정규화를 만족시키기 위해서 위의 테이블을 분해해야 하는데, 다음과 같이 특강신청 테이블과 특강교수 테이블로 분해할 수 있다.

그럼 모든 결정자가 후보키가 된다.

※ 교수는 후보키가 아님에도 특강이름을 결정하고 있기 때문에 교수는 결정자에 속한다.

https://mangkyu.tistory.com/110

 

반 정규화

정합성과 무결성이 보장되지 않더라도  조회시 성능을 높이기 위한 방법(쿼리시 조인 감소)

입력, 수정, 삭제의 성능은 낮아진다

 

반정규화를 수행하는 경우

  • 정규화에 충실하여 종속성, 활용성은 향상되었지만, 수행 속도가 느려진 경우
  • 다량의 범위를 자주 처리해야하는 경우
  • 특정 범위의 데이터만 자주 처리하는 경우
  • 요약/집계 정보가 자주 요구되는 경우

반 정규화 절차

https://velog.io/@yewon-july/De-Normalization

 

테이블 반정규화

https://dataonair.or.kr/db-tech-reference/d-guide/sql/?mod=document&uid=333

 

칼럼 반정규화

https://dataonair.or.kr/db-tech-reference/d-guide/sql/?mod=document&uid=333

 

 

 

참고

https://developer-talk.tistory.com/256

https://velog.io/@busybean3/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%ED%95%A8%EC%88%98-%EC%A2%85%EC%86%8D%EC%84%B1Functional-Dependency

https://mangkyu.tistory.com/110

https://rebro.kr/160

https://wookcode.tistory.com/186

 

댓글