트랜잭션이란 한 묶음으로 처리되어야 하는 SQL 명령문들의 집합입니다.

여기서 중요한 내용은 한 묶음입니다.

한 묶음으로 처리되어야 한다 이게 핵심인데 왜 한 묶음인걸 강조하는 걸까요?

예를들어 봅시다. 

영희는 꿈에 그리던 주택을 얻기 위해 2억원이라는 큰 돈을 은행을 통해 판매자에게 주기로 합니다.

만약 이러한 거래가 있으면 거래는 다음과 같은 방식으로 처리되겠죠?

1. 자신의 통장 돈 액수 2억원 감소 / UPDATE 구문

2. 판매자 통장 돈 액수 2억원 증가 / UPDATE 구문

근대 1. 만 작동하고 문제가 생겨서 2. 는 작동하지 못했습니다.

이런 상황에서 돈은 어떻게 됬냐면....날라가버렸습니다

이러한 현상을 방지하기 위해선 어떻게 해야할까요??

여러가지 방법이 있겠지만 다음과 같은 방법이 가장 간단할거같지 않나요?

1.을 실행시킨뒤 2.를 실행 둘다 정상 실행됬으면 데이터베이스에 반영 도중 실패하면 명령어 취소

그러면 1.과 2.를 한 묶음으로 처리하는 것과 동일하겠죠?

이것이 트랜잭션의 기본 개념입니다.

기본으로 트랜잭션에는 커밋과 롤백이라는 기능이 있습니다.

커밋(commit)은 트랜잭션의 실행 결과를 데이터베이스에 최종적으로 반영하는 것을 말합니다.

롤백(rollback)은 실행 결과를 반영하지 않고 취소하여 원래 상태로 되돌리는 것이죠. 이러면 커밋되기전까지 데이터베이스에 보내진 SQL명령어는 어떻게 처리되냐하면 임시 실행 결과를 만들어 놓고 커밋되면 데이터베이스에 반영되기를 기다리고 있습니다.

이러한 트랜잭션은 크게 3가지 종류를 가지고 있습니다. 이러한 종류를 구분하는 기준은 트랜잭션이 시작되는 시점과 끝나는 시점에 따라 구분이 됩니다. 이제 트랜잭션의 3가지 종류인 명시적 트랜잭션, 자동완료 트랜잭션, 수동완료 트랜잭션을 알아봅시다.

1. 명시적 트랜잭션

이 트랜잭션은 시작과 끝을 사용자가 직접 명시하는 트랜잭션입니다.

예

START TRANSACTION;
 ---
 SQL 쿼리문;
 ---
COMMIT 또는 ROLLBACK ;

2. 자동완료 트랜잭션

이 트랜잭션은 시작과 끝 모두 시스템이 자동으로 달아서 합니다.

더 정확히는 모든 SQL 쿼리문마다 트랜잭션 처리를 하여 처리를 하죠

보통 DBMS의 설정을 건드려 on-off할 수 있습니다.

3. 수동완료 트랜잭션

위에서 보았던 자동완료 트랜잭션은 모든 쿼리문 시작에 START TRANSACTION을 달고 쿼리문 끝에는 COMMIT을 답니다.

이 수동완료 트랜잭션은 시작점은 지정하지 않고 끝나는 시점만 지정합니다.

예를 들어 이렇게 말이죠

SQL 쿼리문 1
SQL 쿼리문 2
SQL 쿼리문 3
COMMIT 또는 ROLLBACK

이 수동완료 트랜잭션에서는 무조건 데이터를 반영하기 위해서 COMMIT을 입력해줘야합니다.

그대로 컴퓨터를 종료하면 앞서 입력한 SQL 쿼리문들은 날라가게됩니다.

이제 남은 문제는 2억원 날린 영희씨는 은행에 소송을 걸면되겠군요

데이터베이스에서 ER모델이란 현실 세계를 개체와 관계를 이용하여 개념 구조로 표현하는 개념적 모델링 방법입니다.

ER 다이어그램은 ER모델의 개념적 모델링을 도식화한 것이죠.

그렇다면 이런 관계를 왜 조사하는 걸까요?

그 이유는 ER 모델을 만들어 봄으로 미리 관계 없는 개체나 필요없는 관계를 쳐낼 수 있고 그림으로 표현하기 때문에 한눈에 쉽게(?) 파악할 수 있기 때문입니다.

ER모델은 현실세계의 개체와 관계를 표현하기 위해 기본 핵심 구성요소 4개가 있습니다.

이 4가지 요소를 요리조리 잘 조합하는걸 따라가며 구성요소를 알아봅시다.

1. 개체와 속성

개체는 현실 세계에서 저장할 가치가 있는 데이터와 관련된 독립적인 존재를 의미합니다.

여기서 이 존재는 속성들이 모인 덩어리... 즉, 개체는 속성 주머니라는 사실을 알아야합니다.

이러한 개체는 여러가지가 될 수 있습니다. 학생, 컴퓨터, 도서, 강의실, 주차장 심지어는 추상적인 개념도 가능합니다. 예를 들어 과목이나 기술같은 것도 말이죠.

속성은 개체 또는 관계가 갖는 고유한 특성을 의미합니다.

근대 잠깐... 관계도 속성을 가질 수 있다고 하고 있습니다. 이에 대해선 나중에 언급하죠 일단 개체와 속성에 관해 풀 썰이 남아있습니다.

그런데 위 그림 어디서 많이 본거같지 않나요?

바로 데이터베이스 릴레이션에서 보았던 것과 비슷하지 않나요?

이렇듯 개체는 릴레이션과 대응할 수 있으며 속성은 애트리뷰트 그리고 릴레이션의 튜플은 개체의 인스턴스와 대응할 수 있습니다.

릴레이션 - 개체

애트리뷰트 - 속성

릴레이션의 튜플 - 개체의 인스턴스

개체

이렇게 보니 낮설었던 새로운 개념도 익숙하게 보입니다.

다음으로 설명할것은 어떻게 다이어그램으로 표현할 것인지 개체와 속성의 ER 다이어그램 표현을 알아봅시다.

ER 다이어그램 규칙에 의해서

개체는 직사각형, 속성은 타원으로 정해져있습니다.

그리고 그 관계는 다음과 같이 표현됩니다.

두 가지 예시를 더 들어보죠

그런데 속성은 여러개의 개념이 나올 수 있는 여지가 있습니다.

예를들어 속성으로 전화번호를 적었다고 하면 그 전화번호에 휴대폰 번호도 적을 수 있고 집전화도 적을 수 있다는 것입니다. 또한 어떤 속성은 다른 속성으로 이루어진 속성일 수도 있습니다. 생년월일의 경우는 (년도)와 (월) 그리고 (일)이라는 속성이 뭉쳐져서 만들어진 것이니까요

이러한 여러가지를 속성에서 나타내기 위해 4가지 방법이 있습니다. 

A. 다중 값 속성

위에서 예로 들었던 전화번호가 그 예입니다. 바로 한 속성이 여러 속성 값을 내포할 수 있다는 것을 ER다이어그램에서는 다음과 같이 이중 실선 타원으로 표현합니다.

B. 복합속성

위에서 예로 들었던 생년월일이 그 예가 됩니다. 한 속성이 여러 속성으로 분해 될 수 있으며 다음과 같이 복합속성은 하위에 다른 속성을 둘 수 있습니다.

C. 유도속성

유도속성이란 개체의 속성으로부터 유추할 수 있는 속성을 말합니다. 예를 들어 학번으로부터 학년을 유추할 수 있을까요 없을까요? 없겠죠 휴학이나 여러 문제 때문에 학번이 같아도 학년은 다를 수 있으니까요

그러면 생년월일로부터 나이를 유추할 수 있을까요 없을까요?? 네 이거는 가능합니다.

이처럼 한 속성으로부터 다른 속성을 유추해 낼 수 있으면 그 유추해낸 속성을 유도속성이라 합니다.

D. 키속성

키속성은 데이터베이스에서 질리도록 봤던 그 고유키(Key)를 말합니다.

속성에 밑줄을 그어 표시합니다.

2. 관계와 링크

ER모델에서 관계란 개체와 개체가 맺어지는 연관성을 의미합니다.

그래서 관계는 개체가 없으면 존재하지도 않습니다.

관계에 대해 설명하면 빼놓을 수 없는 요소가 있습니다. 바로 관계 유형입니다. 사람은 살면서 많은 사람들과 다양한 이해속에 여러 종류의 관계를 가집니다. ER 모델에서는 이러한 현실의 관계를 유형으로 정해두고 세 가지 요소를 통해 구분하고 있습니다.

제 1요소 - 관계 카디널리티

관계 카디널리티는 관계를 맺는 두 개체 집합 간의 사상형태를 말합니다.

쉽게 말해 개체와 다른 개체의 관계에 대한 참여자 수를 나타내는 것과 같습니다.

예를 들어보죠 "교사"와 "학생" 이라는 개체를 <지도>라는 관계로 나타내면

"1명의 교사"는 "여러명의 학생"을 <지도> 할 수 있습니다.

다르게

"1명의 학생"은 "1명의 교수"에게 <지도>받습니다.

이렇게 관계속에 두 개체의 참여자 수를 나타낸 것이 관계 카디널리티입니다.

참여자 수는 1 혹은 여러명으로 표기되는데 여기서 여러명은 m 또는 n으로 표기됩니다.

그러면 관계 카디널리티는 두 개체간의 참여자 수를 나타낸 것과 같고 참여자 수 유형은 두 가지가 있으므로 각 개체가 가질 수 있는 관계 유형의 수 * 개체의 수 = 2*2로 총 4가지의 관계 카디널리티 종류가 있다는 것을 미리 파악할 수 있습니다.

이러한 관계 카디널리티는 두가지 종류가 있는데 분류기준은 한 속성에 참여 가능한 숫자를 기준으로 삼아 여기서 최대로 참여 가능한 수를 최대 사상수라고 부르며 최소로 참여 가능한 수를 최소 사상 수라고 합니다.

A) 최대 사상수

- 1:1 관계

이 관계는 쉽게 일부일처제에서의 결혼을 예로 들 수 있습니다.

A. 남성 한명은 여성 한명과 결혼할 수 있다. 여성 한명은 남성 한명과 결혼할 수 있다.

B. 남성 한명은 여성 여러명과 결혼할 수 있다. 여성 한명은 남성 여러명과 결혼할 수 있다.

위 A와 B 중에서 어떤게 일부일처제에 해당할까요?? 

당연히 A겠죠? 이러한 유형의 관계를 1:1 관계라고 합니다.

- 1:n 관계

위에서 예로 들었던 교수와 학생의 예를 들 수 있습니다.

그런데 한명의 학생이 여러명의 교수에게 지도받을 수 있지 않나요?라고 하면 뭐라 할 말이 없네요 

교수님들에게 사랑받으시면 대학원가시면됩니다.

- n:1 관계

위에서 했던 학생과 교수의 예제를 거꾸로 보면 이 관계입니다.

- n:m 관계

한권의 책이 여러 사람에 의해서 쓰여졌을 수도 있습니다. 이를 유식한 말로 공저(共著)라고 하죠

"한명의 저자"는 "여러권의 책"을 쓸 수 있다.

"한권의 책"은 "여러명의 저자"가 쓸 수 있다.

그런데 이런 n:m 관계는 실제 데이터베이스로 쓰면 조인이 매우 많아 성능이 나쁩니다.

따라서 저 사이에 또 다른 개체를 넣음으로 1:n 관계로 풀어주는게 좋습니다.

그러면 중앙에 <글쓴이 목록> 이라는 개체를 넣어보죠

"한명의 저자"는 "여러개의 글쓴이 목록" 지칭을 할 수 있다.

"한개의 글쓴이 목록"은 "한 명의 저자"를 지칭하고 있다.

"한권의 책"은 "여러개의 글쓴이 목록"을 지칭 할 수 있다.

"한개의 글쓴이 목록"은 "한권의 책"을 지칭하고 있다.

참고로 글쓴이 목록을 릴레이션으로 나타내면 다음과 같습니다.

여기서 앞서 이야기했던 관계도 속성을 가진다! 이 이야기를 풀어보려고 합니다.

예를 한개 들어보죠

학생과 과목은 수강이라는 관계로 연결되있다고 해봅시다.

그러면 학생 한명은 여러개의 과목을 수강할 수 있다.

          과목 한개는 여러명의 학생이 수강할 수 있다.

이렇게  M:N관계가 형성됩니다.

그런데 학생이 과목을 수강함으로 학점을 얻을 수 있습니다.

그러면 학점은 어느 개체에 넣어야할까요??

만약 학생에 넣는다면 .... 생각해봅시다. 

학번을 고유키로 구분하는데 학번 한개의 한개의 학점밖에 넣지 못합니다.

그렇다고 과목에 넣을려고 하니 과목이 한사람만 들으면 학점을 넣어도 그 사람의 학점만 매기면되는데 여러 사람이 들으면 문제가 되는군요

이러면 이 학점이라는 속성을 어디에 넣을 수 있는가??

이 때 바로 관계에 넣을 수 있습니다. 

그러면 위에서 언급했듯이 개체란 속성의 집합이라고 했습니다.

따라서 속성을 가진 관계는 개체의 성질도 일부 가지게 됩니다.

따라서 관계도 나중에 DB구축할 때 테이블(릴레이션)이 될 수 있는데 저렇게 보통 M:N관계에서 개체들이 서로 속성을 가지지 못할 때 그 속성을 받아들임으로서 됩니다.

이 때 그 학점을 고유로 식별하기 위해서 연결된 각 개체의 고유키 속성을 추가로 받습니다.

 B) 최소 사상 수

위에서 언급한 최대 사상 수는 결국 어떤 한 속성에 대해 최대 N명이 참여할 수 있는 것을 나타냈습니다.

그러나 아직 언급을 안한게 있는데 그냥 데이터만 있고 참여를 아예 안하는 경우가 있을 수도 있고 꼭 참여를 해야되는 경우가 있을 수도 있습니다. 

예를 들어  

여기서 교수 개체에서 강의를 하는 교수도 있을 수도 있고 없을 수도 있습니다.

극단적으로 모든 교수가 강의를 안한다고 하면 아예 과목은 필요없어지겠죠

과목의 경우는 강의를 하기 위해선 교슈니뮤 ㅠㅠ 가 한명 이상이라도 필요하기 때문에 저렇게 이중 실선을 그어 표시합니다.

이렇게 개체 입장에서 최소 관계를 맺는 다른 개체가 한 개이상 필요하다면 이것을 전체 참여라고 합니다.

반대로 개체 입장에서 다른 개체와 관계를 맺든 맺지 않던 노 상관이라면 부분 참여라고 합니다.  

제 2요소 - 관계 차수

쉽게 말해 관계에 몇개의 개체가 붙어있냐? 가 차수 입니다.

하나의 관계에 한개의 개체가 붙어있으면 1진 관계

두개 붙어있으면 2진 관계

세개 붙어있으면 3진 관계

n개 붙어있으면 n진 관계라 합니다.

제 3요소 - 관계의 종속성

사실 이 요소는 관계가 주된 현상이 아니라 개체간의 힘겨루기와 비슷한 요소입니다. 뭐라 한마디로 정의하기 어렵네요

관계의 종속성에는 두 가지 하위 분류가 있습니다. 

- 비식별 관계와 식별 관계

여기서 식별이라는 요소는 개체가 다른 개체에 종속적인 관계를 가지는 가를 식별한다는 것입니다.

예를 들어보죠 "대학 건물"이라는 개체와 "강의실"이라는 개체가 있습니다.

<존재>라는 관계로 해석하면 다음과 같습니다.

"대학 건물"에 "강의실"이 존재할 지도 모른다 (선택)

"강의실"은 "대학 건물"에 존재한다.(필요)

ER 다이어그램으로 표기할 때는 개체와 관계를 두번 겹쳐 표현합니다.

강의실 개체는 대학건물에 종속된 개체입니다.

즉 대학 건물에는 강의실이 있던 말던 관계가 없습니다. 대학 건물이 식당일수도 있고 도서관일지도 모르죠

그러나 강의실은 무조건 대학 건물에 있어야만합니다.

운동장에서 강의 듣고싶을까요?  

- 일반화 관계

위 이미지는 예전에 재미있게 봤었던 원피스의 한 장면입니다.

일반화 관계는 개체 사이의 상하 관계를 나타냅니다.

근대 단순한 상하관계가 아닙니다. 공통 속성을 가지는 상하관계인거죠

일반화관계는 역 삼각형으로 표기되며 is a 관계라고도 합니다.

사실 ER 모델의 표기 방법은 위에 나온것 뿐만 아니라 여러가지 표기로도 쓸 수 있습니다. 만약 ER 다이어그램을 보고 다른 모양이 나왔으면 당황하지 말고 구글링하셔서 찾아보시면 분명히 위 문서에는 있는 개념인데 모양만 다른게 대다수 일겁니다. 

지난 포스터에서 이야기했던 이상과 함수 종속성에 이어 마지막으로 정규화에 대해 이야기해보려고 합니다

이상을 치료하는 방법인 정규화는 치료 스케일에 따라 그 규약이 더욱 빡빡해 집니다

즉 정규화 숫자가 올라갈수록 더 어렵다는 이야기가 되겠습니다.

먼저 제 1 정규화(1NF)에 대해서 이야기해봅시다

제 1 정규화는 테이블에 있는 모든 속성의 레코드 값이 원자값을 가지고 있는 형태를 말합니다.

여기서 새로운 개념이 등장하네요 바로 원자값이란 개념이죠

여기서 말하는 원자값이란 쉽게 설명하자면 최소한으로 쪼갤 수 있는 데이터의 한계입니다.

예를들어 주민등록번호를 생각해보면 주민등록번호를 앞자리와 뒷자리로 나누어 저장 할 수도 있는 것입니다.

<주민등록번호> -> <주민번호 앞자리, 주민번호 뒷자리>

사실 원자값은 설계자가 원자값이 있다고 판단되면 설계자 입장에서는 원자값이 있는것입니다. 약간 애매한 해석의 여지를 담고 있는것이지요

예제 하나 더 보고 가보도록 합시다

어떤 헬스장에서 회원정보를 아래와 같은 테이블에 넣어 보관하고 있다고 해봅시다

그런데 여기서 철수 회원이 업무 때문에 전화번호가 하나 더 생겼습니다.

그러면 아래와 같은 테이블이 됩니다.

이렇게 되면 똑똑한 개발자는 전화번호라는 하나의 속성에 두개의 값을 지니고 있는 것은 원자값을 가지고 있지 않다는 것을 알아차리게 될 것입니다.

따라서 개발자는 다음과 같이 테이블을 분리했습니다.

이렇게 반복되는 속성을 기준으로 기본키 속성과 함께 새로운 테이블을 만드는 것입니다.

(참고로 🗝️는 외래키입니다.)

다음은 제 2 정규화(2NF)입니다.

제 2 정규화는 제 1 정규화를 만족하면서 완전 함수 종속인 테이블이 되었을 때 제 2 정규화라고 합니다.

여기서 이전에 포스트에서 봤던 내용인 완전 함수 종속이 나오네요

잘 상기하면서 예제를 보도록 합시다.

여기서 잘보면

생년월일은 굳이 앞자리 뒷자리 둘다 쓸 필요 없이 앞자리만으로 정보를 알아낼 수 있죠

이를 표현하면 다음과 같이 됩니다.

주민번호 앞자리*주민번호 뒷자리 -> 생년월일     ---------   완전함수종속 위반

주민번호 앞자리 -> 생년월일    

즉 주민번호 앞자리 말고 생년월일 정보를 알아낼 수 있는 다른 최소 속성 조합은 존재하지 않기 때문에 주민번호 앞자리 -> 생년월일 이라는 정보를 바탕으로 다음과 같이 테이블을 분리합니다.

제 3 정규화(3NF)는 제 2정규화를 만족하고 후보키가 아닌 속성들에서 이행 종속이 없는 테이블을 말합니다.

이번에도 이전에 포스트에서 봤던 내용인 이행 종속이 나오네요

잘 상기하면서 예제를 보도록 합시다.

여기서 학과 건물은 학과와 연관이 있습니다 그리고 학과는 학번과 연결되어 있죠

학번-> 학과

학과-> 학과건물

이러한 이행종속은 다음과 같이 풀어줍니다.

마지막 BCNF는 제3정규화를 만족하고 모든 결정자는 후보키여야 합니다.

여기서 결정자란 테이블의 나머지 속성을 모두 결정할 수 있는 속성을 말합니다.

예를들어 학번을 알고 있으면 이름과 주소 성별을 알 수 있겠네요 그러면 학번이 결정자가 됩니다.

학번 -> (이름, 주소, 학년, 성별)

예를 들어보죠

위 테이블을 분석해보면 학번과 과목으로 교수를 결정할 수 있습니다. 그러나 교수가 한학기당 한 과목을 맡게되면 교수라는 속성으로 다시 과목을 결정할 수 있게 됩니다.

함수 종속 표현으로 표현하면 다음과 같이 되는거죠

학번,과목-> 교수

교수-> 과목

이렇게 되면 교수라는 속성은 현재 후보키가 아니기 때문에 BCNF를 만족하지 않게 되는군요

따라서 교수를 후보키로 하는 새로운 테이블을 만들어 줘야합니다.

이렇듯 정규화까지 알아봤습니다. 이러한 정규화는 데이터의 중복을 낮춰주지만 반대로 조인 연산 비용이 증가하여 지나친 정규화는 시스템에 큰 부담이 됩니다. 따라서 정규화를 사용할려면 데이터 안정성과 시스템 부하에 적절한 트레이드 오프를 잘 정해야합니다.

관계형 데이터베이스를 공부하는데 맞이하는 가장 첫번째 난벽은 개인적으로 정규화라고 생각합니다

보통 정규화에 앞서 배울 내용들 즉 릴레이션이나 스키마 구조, DBMS의 역활같은 거는 그냥 외우면 되는거니까요

그런데 이 정규화라는 녀석은 성격이 약간 다릅니다. 정규화는 철저한 논리식에 기반을 두고 있기 때문에 암기보다는 이해가 중요합니다. 이러한 이해를 바탕으로 여러가지 규칙을 칼같이 지키며 릴레이션을 정규화할 수 있습니다. 

사실 정규화가 어려운 이유는 위의 것들 도 있겠지만 가장 큰 문제는 문제점이 뭔지를 찾는게 더욱 문제가 되겠네요

이건 뭐라 설명할 수 없고 그저 열심히 여러 문제나 모델링을 하면서 문제점을 보는 눈을 기르는 수밖에 없습니다.

먼저 배울건 데이터베이스를 막 설계하면 생기는 문제점과 그 문제점을 측정할 수 있는 도구를 알아봅니다

그리고 이 데이터 베이스의 수리 방법을 정규화라고 하는데 여기서는 보통 데이터베이스 정규화하면 배우는 1~3 정규화와 BCNF의 이해에 주력합니다 더욱 공부하고 싶으신 분들은 4~6정규화까지 찾아서 공부해보시면 좋을것같습니다.

먼저 정규화의 정의를 봅시다

정규화의 정의 : 관계형 데이터베이스의 설계에서 중복을 최소화하게 데이터를 구조화하는 프로세스

(위키백과 참조)

위 정의는 한눈에 봐서 이해하기에는 무리가 있군요

문장을 분해해봅시다

관계형 데이터베이스의 설계에서 중복을 최소화하게 -> 그러면 RDB에서 중복이 무엇인가라는 개념이 필요하겠죠?

데이터를 구조화하는 프로세스 -> 구조화가 무엇일까요?

저 문장을 분해해서 해석했더니 두 가지 의문이 나왔네요

"중복"의 개념과 "구조화"가 무엇인지에 대한 의문이죠

먼저 구조화를 설명하자면 여러 데이터가 모여서 테이블을 형성하고 그 테이블 들이 모여서 하나의 스키마를 구성하는게 관계형 데이터베이스에서 말하는 구조화 입니다. 

데이터 중복이 데이터베이스 설계를 막장으로 하면 생기는 문제점인데 약간 복잡하니 예를 들어보죠 

어떤 영화관에서 예약 고객을 받기 위해 데이터베이스 테이블을 아래와 같이 운영하고 있다고 합니다 

이 테이블은 SELECT 쿼리를 사용할 때는 문제가 없지만 이 테이블에 들어있는 속성이나 데이터 때문에 3가지 문제가 발생합니다 문제라기 보다는....이 문제는 마치 영어의 불규칙동사를 외우는 것과 같습니다! 쓸려면 예외를 외워야하고 실수가 빈번하게 일어나죠

먼저 3가지 이상에 대해 알아봅시다

삽입 이상- 새로운 영화 "기생충"이 4관에 상영 예약 데이터를 테이블에 추가해본다고 생각해봅시다

그러면 <NULL, 기생충, NULL, '4관'> 을 삽입해야하는데 고객번호가 기본키이기 때문에 데이터가 넣어지지 않습니다

신규 영화이름을 넣기 위해선 몰래 고객 아무나 한명을 예약에 넣어야되죠 이것을 삽입 이상이라고 합니다

갱신 이상 -  "트루먼 쇼" 상영관을  1관에서 3관으로 변경하는 경우를 생각해봅시다

영화 위에는 튜플 2개만 변경하면서 오류가 발생했습니다 007 고객이 예약한 자료는 갱신이 안되버렸습니다

나중에 007 고객이 영화관에 와서 4번 상영관으로 가면 매우 뻘쭘해지겠군요 

삭제 이상 - 고객번호가 001인 고객이 "포레스트 검프" 예약을 취소하였습니다 그런데 이를 어쩌죠 001 고객이 예약한 정보가 테이블 내에 "포레스트 검프" 정보를 가지고 있는 유일한 튜플이네요 그러면 저 튜플을 삭제하는 순간 테이블 내에선 다시 입력하기 전까지 "포레스트 검프"가 있는지도 모르겠군요

이러한 이상이 생기는 주원인은 데이터 중복 때문인데 데이터 중복을 낮추는 방법이 바로 정규화입니다

정규화에선 중복을 최소화하게 데이터를 구조화 한다고 하였습니다. 이를 위해서 테이블의 갯수나 테이블의 속성을 재설계하는 것이죠. 즉, 데이터의 중복을 낮추기 위해 테이블을 쪼개고 고치고 다시 만드는것 <구조화> 하는거죠

이제 1~3 정규화와 BCNF에 대해 본격적으로 들어가기 전에  한가지 중요한 개념이 있습니다. <함수 종속성> 이라는 개념인데 이 개념은 테이블이 주어졌을 때 어디가 이상한지 그 이상한 점을 찾는 논리적 도구입니다.

마치 의사가 내장 어떤 부분이 아픈지 판단하는 청진기로 봐도 무방합니다.

먼저 이 새로운 도구의 정의를 봅시다

 함수 종속성 : 같은 테이블 안의 속성 간에 특정 속성 값이 함수적으로 다른 속성 값을 결정하는 종속관계

이번에도 상당히 복잡한 개념입니다 한번에 이해가 잘 안되는게 당연한 현상이죠

이거는 저 말뜻을 이해하는 것보다는 예를 통해 한번 보는게 훨씬 쉽습니다

회사의 사원들의 정보를 관리하는 테이블을 다음과 같이 만들었습니다.

여기서 사원번호가 주어지면 주민등록번호를 알 수 있겠죠?

그러면 함수 종속성으로 이렇게 쓸 수 있습니다.

사원번호 ->주민등록번호

이렇게도 쓰는게 가능합니다

사원번호*거주지 ->주민등록번호*거주지

그런데 주민등록번호로 이름을 알 수 있네요 물론 사원번호로도 알 수 있죠 이것을 이렇게 적는게 가능합니다

주민등록번호->이름

사원번호->이름

이렇게 특정 속성 값으로부터 다른 속성값을 결정 하는 관계를 함수 종속성이라 합니다

논리적으로 생각해서 이 속성은 이 속성을 결정할 수 있다!!!라고 생각하면 그렇게 해석해도 됩니다. 단 자기만 옳다고 생각 되는게 아니라 사회 전반적으로 생각이 인정받아야겠지만요... 이러한 특성 때문에 함수 종속성은 여러 표현이 나올 수 있습니다. 그 표현들을 알아보죠

1. x->y and x->z then x->yz

ex) 사원번호->이름 and 사원번호->거주지 then 사원번호 -> 이름*거주지

2. x->yz then x->y and x->z

ex) 사원번호 -> 이름* 거주지 then 사원번호->이름 and 사원번호->거주지 

3. x->y and wy->z then wx->z

ex) 여기서는 조금 다른 속성을 끌어쓰겠습니다

출생일->주민번호앞자리 and 주민번호앞자리*주민번호뒷자리->이름 then 출생일*주민번호뒷자리->이름

4. x->y and z->w then xz->yw

ex) 사원번호->이름 and 주민등록번호->거주지 then 사원번호*주민등록번호->이름*거주지

여기서 완전 함수 종속성과 부분 함수 종속이라는 개념이 나오는데 각각의 개념은 다음과 같습니다.

완전함수종속

: 테이블에서 속성 x가 다른 단일 혹은 복합 속성 y에 함수적 종속이면서 다른 어떤 속성과도 함수적 종속이 아닌 것

예를 들어 x1*x2*x3.... -> y을 보면 쉽게 알 수 있습니다.

위에서 예를 들면 다음과 같은 스키마가 있다고 합시다

수강 스키마

<학번, 과목번호, 학점, 성별, 강의교수>

이때 학점은 과목번호만으로 정해지지 않고 학번만으로 정해지지 않습니다.

오직 학번과 과목번호의 속성의 조합으로만 알 수 있습니다.

학번*과목번호->학점

부분함수종속 

위쪽 테이블을 다시 가져와보죠

여기서 거주지는 주민등록번호로도 알 수 있는 속성입니다.

이때 사원번호와 거주지의 관계를 부분함수종속이라고 합니다.

이행 함수 종속

이행함수종속이란 x->y이고 y->z이면 x->z인 속성을 말합니다.

예를 들어 다음과 같이 학생 스키마가 있다고 합니다.

학생

<학번, 이름, 학과, 학과건물>

이때 좀 억지긴 하지만 학번으로는 학과건물을 알아낼 수 없다고 합시다!!

학과건물은 오직 학과에 의해서만 알아낼 수 있는거죠

그러면 학번-> 학과 이고 학과->학과건물 이면 학번->학과건물 이라는 논리를 이끌어 낼 수 있습니다.

이것을 이행종속이라고 합니다.

이렇듯 함수적 종속을 통해 현재 테이블의 속성관계를 표현할 수 있게 되었습니다.

지금까지 그냥 데이터베이스를 막 설계하면 생기는 문제점과 그 문제점을 측정할 수 있는 도구를 얻었습니다.

그러면 마지막으로 수술 방법은 알아야하는데 문서가 너무 길어져서 정규화에 대한 이야기는 다음으로 미루도록 하겠습니다.