Each row-and-column stores a single value
- Chris Date -
1. 정규화를 하는 이유
각 정규화에서 이걸 통해 어떤 문제를 막고자 하는 지를 알아야 한다.
무엇이 문제이고 어떻게 문제를 해결할 수 있는지에 대해 집중하며 정규화 방법에 대해 알아보자.
중복 데이터가 있는 경우 미스매치나 실수가 있을 수 있기 때문에
정규화를 하면 이것을 줄이고 데이터의 퀄리티를 향상할 수 있다.
2. 문제 상황 1
| 팀 | 팀원명 |
| 1 | Alice, Bob, Chris |
| 2 | David, David, David |
| 3 | Bob, Chris, Alice |
[조회]
여러 명의 정보를 가지고 있는 팀 테이블이 있다고 할 때 Alice의 정보를 알고 싶다고 해보자.
그렇다면 like '% Alice%'와 같이 팀원 컬럼에서 찾아야 한다.
[갱신]
그리고 Bob이라는 팀원이 팀을 나갔을 때는 어떻게 정보를 갱신해야 할 지에 대해 고민해 보자.
[중복]
2팀을 보면 중복에 대한 문제를 볼 수 있다. 3명의 사람이 같은 이름이라면 문제가 생길 것이다.
[순서]
1팀과 3팀은 팀원의 이름이 모두 같지만 순서가 다른데 이 경우 같은 팀으로 보는 것이 맞을까?
3. 문제 사항 2
| 팀원명 | phone1 | phone2 |
| Alice | 077 777 888 | <null> |
| Bob | 077 888 999 | 077 666 777 |
이제 하나의 컬럼에 컴마로 구분된 데이터가 들어가 있지는 않다.
Alice의 Phone2에 null이 들어가 있다.
만약 이 상황에서 Bob의 phone1을 삭제한다고 하면 Bob의 phone2는 무엇을 의미하게 될까?
이런 문제 때문에 null을 가능하면 넣으면 안 된다.
컬럼에는 left-to-right ordering이 없어야 한다.
4. 문제상황 3
그렇다고 phone1을 home phone, phone2를 work phone으로 꾼다고 문제가 해결될까?
| 팀원명 | phone type | phone number |
| Alice | HOME | 077 777 888 |
| Bob | WORK | 077 888 999 |
| Bob | HOME | 077 666 777 |
위와 같이 바꿨을 때는 어떤 문제가 남아있을까.
| 팀원명 | phone type | phone number |
| Alice | HOME | 077 777 888 |
| Bob | WORK | 077 888 999 |
| Bob | HOME | 077 666 777 |
| Bob | HOME | 077 666 777 |
Bob이 같은 번호를 입력했을 수도 있다.
그렇기 때문에 중복된 row도 피해야 한다.
이를 위해서 primary key와 unique constraints를 사용할 수 있다.
그리고 후보키로 팀원명과 phone number를 묶어서 사용할 수 있다.
5. 1NF 방법
[예제 1]
| Home Team | Home Players |
| DOAG V | Alice, Bob, Chris, Emily, Fedora |
| UKOUG V | David, David, David, David, David |
플레이어 순서별로 팀에서 포지션이 있다고 했을 때 아래와 같은 구조로 변경이 가능할 것이다.
-- 방법 1
team_name ...unique,
goalkeeper ...,
defender ...,
left_winger ...,
right_winger ...,
striker ...
-- 방법 2
team_name ...,
position ...,
player ...,
unique(
team_name, position
)
방법 1, 2 모두 1 정규화에 해당한다.
그런데 이제 요구사항에 따라 둘의 장단점과 데이터를 얻어내는 상황에 대해 고려해봐야 한다.
방법 1) 1 row, 5 columns
- 모든 팀이 5명의 플레이어를 가진다고 확신할 수 있음
- 한 row에만 접근해도 다섯 명을 모두 조회할 수 있음
방법 2) Position column, 5 rows
- 각각 플레이어 정보와 join이 쉬움
- 한 명씩 유니크하게 관리하기 쉬움
- 포지션이 늘어나도 스키마 변경이 없음
[예제 2]
| Stadium | Home team | Away team | Match Date |
| Stadion Berlin | DOAG V | UKOUG V | 17 Aug 2021 |
| Stadium | Home Away? | Team | Match Date |
| Stadion Berlin | HOME | DOAG V | 17 Aug 2021 |
| Stadion Berlin | AWAY | UKOUG V | 17 Aug 2021 |
대부분의 팀 스포츠는 대부분 2팀으로 경기가 진행된다.
그렇기 때문에 확장성에 대해 고민하기보다는 비즈니스 요구사항과
데이터로 무엇을 할 것인가에 대해 고려하는 것이 낫다.
그렇기 때문에 1번의 테이블 구조가 적절할 수도 있다.
학습 출처(~31:50)
oracle normalize 강의