[DB] 이상현상이란? 함수 종속성이란? 꼬리 질문하며 살펴보자.

 언쟝! 안녕하세요 어려분 오늘은 이상 현상, 함수 종속성과 정규화에 대해 알아보려고 왔습니다.

제가 세 단어를 띄어 말해서 마치 서로 관련이 없는 요소들로 보일 수 있지만 실은 아주 깊은 관계가 얽혀 있습니다. 결론부터 말하자면 DB의 릴레이션을 속성간 함수 종속성을 충분히 고려하지 않고 설계하면 이상 현상이 발생합니다! 이상 현상이 발생하지 않게 함수 종속성을 고려하며 재설계 하는 과정이 정규화입니다!

 

무슨말인지 감을 못잡겠다구요? 그럼 쭉 계속 내려가봅시다!

참고로 우린 계속 Why를 붙여가며 꼬리 질문을 할겁니다. 정확한 이해는 필수이기 때문이죠:)

 

학습 목표

1. 이상 현상이란?

2. 함수 종속성이란?

3. 정규화란?(다음 글)

 

---

1. 이상 현상이란?

정의: 릴레이션의 설계가 잘못되어, SQL 문의 결과가 틀리거나 원하는 결과가 나오지 않는 문제. 즉 테이블을 잘못 설계하여 데이터를 삽입, 삭제 및 수정할 때 생기는 논리적 오류.

 

종류

• 삽입 이상: 테이블에 투플을 삽입할 때 부득이하게 NULL 값이 입력됨.
• 삭제 이상: 삭제 시 연쇄 삭제 현상이 발생.
• 수정 이상: 수정 시 데이터의 일관성이 훼손되는 현상.

 

 이상 현상 말 그대로 풀이해봅시다! 이상 = 정상적인 상태와 다르다. 즉 정상적인 상태의 결과가 나오지 않은 거에요! 해당 결과의 원인은 잘못된 릴레이션의 설계 때문이에요. 동시성 문제 같은 원인이 아니죠. 

 

 말만 들으면 어렵죠? 간단한 예시를 들어볼께요! 아래 릴레이션은 대학교 데이터 릴레이션이에요. 릴레이션 이름이 왜이렇게 명확하지 않냐구요? 잘못 설계된 릴레이션이기 때문이죠 ㅎㅎ 아래 릴레이션 내에 존재 하는 속성들은 다른 릴레이션에 없다고 가정합시다! 학번 정보, 지도교수 정보, 학과 등등은 이 릴레이션 밖에 없어죠! 극단적으로 대학교의 서버 DB에 아래 릴레이션만 존재한다고 가정합시다! 해당 가정 하엔 '대학교 데이터'가 그렇게 이상한 릴레이션 이름이 아니게 느껴질겁니다 ㅎㅎ 그럼 아래 릴레이션의 문제를 살펴보죠!

 

그림1. 대학교 데이터 릴레이션

 

삽입 이상

자료를 삽입할 때 의도하지 않은 자료까지 삽입해야만 자료를 테이블에 추가가 가능한 현상

 자자 학생 한명이 입학했어요! 신입생을 맞이하기 위해 대학교 DB에 학생 정보를 등록해줍시다. 학생은 500 학번이고 컴퓨터 학과에요. 근데 릴레이션에 데이터를 넣으려고 하니 아직 학생이 어떤 수업을 들었는지 어떤 성적을 받았는지 정보가 없네요? 그렇다면 해당 정보들을 null로 처리해야겠군요. (500, null, 컴퓨터, null, null)을 넣읍시다! 삽입 이상이 발생했습니다! 우린 부득이하게 null을 속성 값으로 넣어버렸군요. 근데 이게 왜 이상현상이냐구요? null 값은 되도록 없어야 하기 때문입니다. 추후 null + 3과 같은 사칙 연산을 할때도 null은 문제가 돼요. 연산 정의 자체가 성립하지 않기 때문입니다!

 

삭제 이상

어떤 정보를 삭제하면, 의도하지 않은 다른 정보까지 삭제되어버리는 현상

 시간이 흘러 P2 교수님이 은퇴를 한다고 합니다. 눈물겨운 송별회를 하고 다음날 아침 P2 교수님을 DB에서 지우려고 합니다. P2 교수님을 찾으려고 데이터를 보니 (210, P2, 수학, C-60, B)가 존재합니다. 이를 지웠습니다. 어떤 일이 벌어질까요? 210학번 학생은 아무 잘못이 없지만 대학교 DB에 없어졌어요! 삭제 이상이 발생했습니다. 심지어 수학과, C-60, 210 학번 학생의 B 성적 마저 없어져 버렸군요! 데이터를 한곳에 몰아 저장해버리니 삭제 시 연쇄 삭제가 발생했습니다.

 

수정 이상

중복된 데이터 중 일부만 수정되어 데이터 모순이 일어나는 현상

 123 학생이 2학년이 되기 전 큰 맘을 먹었습니다. 2학년이 되면 학과를 바꿔야겠다고 마음 먹었어요. 2학년이 된 후 전과 신청을 해서 수학과로 갔습니다! 학교에선 대학교 데이터 릴레이션에서 학생 정보를 바꿔야겠죠. 학생 정보를 찾아보니 (123, ..., ...) 가 있군요! Update문으로 바꿨습니다. 하지만 나중에 보니 어쩔 땐 학생이 수학과로 나오지만 또 어쩔 땐 학생 소속이 여전히 컴퓨터 공학과입니다. 왜그럴까요? 서로 다른 (123, ..., ...) 정보가 2개 이상이기 때문이죠. 이때 두 정보 모두 학과를 수학과로 바꾸면 문제 없지만, 하나만 바뀌게 되면 데이터 불일치 문제 즉 데이터 일관성 훼손이 발생합니다. 한 학생이 두 학과를 가지게 되죠! 수정 이상이 발생했습니다!

 

 이상 현상은 릴레이션 설계가 잘못 되어 sql 쿼리 문의 결과가 정상적이지 않을 때 일어나는 군요! 그럼 도대체 릴레이션 설계가 어떻게 잘못됐을까요? 무슨 문제가 있기 때문일까요? 결론부터 말하자면, 이상 현상은 후보키가 아니면서 결정자인 속성(비후보키 결정자 속성)이 있을 때 발생합니다. 슈퍼키이면서 최소 속성 개수를 만족하는게 후보키인데 결정자는 뭘까요? 속성 집합 A가 속성 집합 B를 결정할 때 A가 B의 결정자라고 부르고, B는 A에 함수적으로 종속한다고 합니다. 

 

원인을 제대로 알아야 해결 방법을 잘 이해할 수 있겠죠? 이상현상의 원인인 함수 종속성에 대해 알아봅시다!

 

 

---

2. 함수 종속성

정의: 릴레이션 속성 간에 함수적으로 종속하는 성질.

'학생 번호' -> '주소'와 같이 왼쪽 속성의 모든 값에 대하여 오른쪽 속성의 값이 유일하게 결정될 때 학생 번호는 주소에 함수적으로 종속된다고 합니다. 학생 번호를 x라고 하고 y를 주소라고 합시다. 그럼 함수 종속성은 x->y로 추상화 됩니다. 이를 함수로 표현해봅시다.

 

그림2. y=x^2 그래프

 

 위 함수는 y=x^2 그래프입니다. 여기서 y는 x에 함수적으로 종속합니다. x에 따라 y가 유일하게 결정되기 때문이죠. 여기서 유일하게 결정된다는 말은 x값에 따라 두개의 y값이 나오지 않는다는 뜻입니다. y=x^2은 하나의 x는 단 하나의 y만 가집니다. 따라서 이때 x->y이며 y는 x에 함수적으로 종속합니다. 그렇다면 함수적으로 종속하지 않는 경우에 대해 또한 알아봅시다.

 

 

x=y^2 그래프

 

 위 그래프는 x=y^2입니다. x가 하나일 때 두개의 y 값을 가질 수 있습니다. x=1일 때 y=1 혹은 y=-1이죠. 이때 y는 x에 함수적으로 종속하지 않습니다. 대신 x가 y에 함수적으로 종속(y->x)하죠. y값 하나에 대해 두개의 x값을 가지지 않잖아요?

 

 

 자 이제 우리는 함수 종속성에 대해 이해했습니다! y값이 특정 x값에 대해 유일할 때 x->y, y는 x에 함수적으로 종속한다고 합니다. 이때 주의해야 하는 점은 x와 y가 단일 속성 값이 아닐 수 있습니다. 예를 들어, 복합키는 단일 키가 아니죠. 복합키->릴레이션이 될 수도 있습니다!

 

 오케이! 전부 이해했습니다! (이해가 안된다면 다시 돌아가서 살펴보시거나, 다른 블로그 혹은 위키피디아를 보고 이해 후 오시길 바랍니다) 근데 우리가 이걸로 뭘 알려고 했죠? 맞아요. 이상현상의 원인 때문이였습니다. 이상 현상은 후보키가 아니면서 결정자인 속성(비후보키 결정자 속성)이 있을 때 발생합니다. 우린 이상 현상, 후보키와 결정자를 알지만 앞의 말을 이해 못할 수 있습니다. 이럴 땐 말 하나 하나를 뜯어보고 그 관계를 살펴보는게 도움이 됩니다.

 

• 이상 현상: 테이블을 잘못 설계하여 데이터를 삽입, 삭제 및 수정할 때 생기는 논리적 오류.
• 후보키: 릴레이션의 튜플을 유일하게 식별할 수 있는 최소 개수 속성 집합.
• 결정자: '학생 번호' -> '주소'일 때 학생 번호가 결정자입니다.

 

 수학의 관점에서 릴레이션이란 튜플 집합입니다. 튜플의 유일성을 보장해주는 속성들은 후보키라고 불리죠. 모든 결정자들은 후보키여야 합니다. 왜냐하면 튜플의 유일성을 보장해주는게 후보키이기 때문이죠. 튜플안에 있는 속성이 튜플의 유일성에는 관여하지 않으면서 튜플 내 다른 속성의 결정자 역할을 한다면. 이는 릴레이션 안에 다른 릴레이션이 있다는 뜻입니다. 이때 릴레이션 안에 다른 릴레이션이 있는지도 모르고 해당 튜플의 정보를 지워버리면 숨어 있는 릴레이션 정보가 사라지게 됩니다. 마치 학생 정보를 지우려 했는데 학과 정보가 지워지는 현상과 같죠.

 

 후보키가 아니면서 결정자인 속성(비후보키 결정자 속성)이 있을 때 어떻게 해야할까요? 릴레이션을 분리해주면 됩니다! 마치 학생 정보와 학과 정보는 다른거야~ 라고 말해주는 것과 같죠. 아래는 릴레이션을 분리한 예시입니다! 주문 목록 릴레이션 내에 고객 릴레이션이 있었습니다. 주문 번호와 고객 ID 모두 결정자이기 때문이죠.

 

그림3. 주문 목록 정규화 예시

 

 이와 같은 행위를 추상화 시켜 말하면 릴레이션 세계의 규율을 정상화라고 부를 수 있습니다. 한문으로 풀면 규율(법 규 規)을 정상(바를 정 正) 화(될 화 化)입니다. 이는 정규화(正規化)라고 합니다. 정규화된 릴레이션 형태(모양 형 形)를 정규형이라고 하죠. 정규화된 형태가 여러가지기 때문에 제1 정규형, 제2 정규형 등이 존재합니다. 다음 글에서는 릴레이션 관계를 바로 잡는 방법인 정규화에 대해 알아보겠습니다. 

 

 

그럼 언쟙!