Part 5-2-13. SQL 입문 : 정규화

 

 

💅 SQL 입문

 

 지난 시간에는 새로운 데이터베이스를 직접 만들어보고, 열도 생성하며 데이터를 삽입하고, 수정하고, 삭제하는 것과 제약(CONSTRAINT)에 대해서 알아보았다. 이번 시간에는 정규화라는 개념을 통해 데이터베이스 내 중복된 데이터를 분리하며 설계하는 방법에 대해서 알아보는 시간을 가진다.

 

---

 

➗ 정규화

 

 정규화는 테이블을 올바르게 올바르게 변경하고 분할하기 위해서 존재한 개념이다. 사실 SQL 챕터는 정보처리기사 자격증을 준비하면서 학습했던 내용이라 강의를 듣는데 큰 어려움이 없다. 자격증 내에서 정규화는 크게 1~6 정규화까지 존재하는데 강의에서는 모든 정규화 유형에 대해서 굳이 외울 필요는 없고, 나중에 데이터베이스 설계시 저절로 알게 된다고 말씀해주셨다.

 

---

 

 

예를 들어 임의의 데이터베이스가 위와 같이 설계되어 있다고 가정해보자. 데이터베이스를 살펴보면 다 좋은데, inventory에 다량의 아이템이 string 형태로 들어간 걸 볼 수가 있다. 이 상태에서 루키스라는 유저가 초록 물약을 하나 쓴다면 해당 인벤토리를 일일이 뒤져가면서 사용한 갯수만큼 감소해야 하니 비효율적이다. 따라서 아래와 같이 이를 변경할 수 있다.

 

 

 위와같이 인벤토리 내 아이템을 새로운 행으로 분할하여 만들었다. 이제 더 이상 모든 문자열을 순회하며 힘들게 접근할 필요가 없다!

 그러나 사실 여기에서도 여전히 문제가 있는데, ID부터 Level까지, 너무나도 많은 열이 중복된 모습을 볼 수 있다. 딱봐도 매우 비효율적이고, 만약에 rookiss 이름을 변경한다면 저 많은 행들을 전부 바꿔줘야 하는 것이다. 이러한 이유에서 데이터베이스에선 중복은 끔찍한 재앙으로 여겨야 한다. 🙅‍♂️

 

그렇다면 이는 어떻게 해결해야 할까?

 

 

 위와같이 ID를 Primary Key로 한다면, 아이템코드, 아이템이름, 아이템수를 기존 테이블에서 독립시키고, 이 테이블에다가 ID의 Foreign Key인 PlayerID를 추가하자. 이전 테이블보다 확실히 깔끔해진 모습을 볼 수 있다! Foreign Key를 통해 Item 테이블에 접근할 수 있게 되니, 문제가 될 것도 없다.

하지만 끝난 것 같은 문제가 여전히 남아있다. 바로 itemCode를 나타내는 부분과 itemName을 나타내는 부분에서 중첩되는 것을 볼 수 있다.

 

 

 이전 단계에 했던 것처럼, itemName을 독립시키고, ItemCode의 Foreign Key를 itemInfo에 추가해주면 해결된다. 더 이상 데이터가 중복된 행이 보이지 않고, 각 테이블 별로(플레이어, 인벤토리, 아이템 정보) 자신만의 역할을 수행하게 되니 정규화가 끝나게 된다.

 결론은 데이터베이스에선 중복을 없애고 테이블을 나누는 것이 가장 중요하다라는 것이다. 비록 테이블이 나누어졌더라도 PK, FK를 통해 조회하여 문제없이 데이터베이스에 접근할 수 있으므로 걱정하지 말자. 😎