중복 데이터 문제
별개의 관심사가 한 테이블에 있게 되면
Insertion anomalies어노멀리스(삽입 작업이 데이터 무결성을 깨트리는 것)이 발생함.
1. JINHO의 부서 데이터가 MESSI의 부서 데이터와 중복됨
2. JENNY는 부서 배치를 아직 받지 않아 부서 데이터가 없어서 null로 처리 됐는데 null이 많아질 수록 좋은 테이블이 아님.
3. 품질관리팀(QA)이 새로 생겨 직원은 없는 상태라 null이 남발됨
4. QA팀에 직원이 생겼을 때 3번의 튜플을 삭제해줘야하는데, 번거로움.
새 직원이 입사했을 경우, null이 남발되는 상황도 없고 부서 테이블에 수정을 하지 않아도 되므로 더 효율적임.
새로운 부서를 추가할 때도 직원 테이블은 영향을 받지 않고 부서 테이블에서만 새로 추가해주면 됨.
Deletion anomalies(삭제 작업이 데이터 무결성을 깨트리는 것)이 발생함.
YUJIN 정보를 삭제하면 QA부서 정보 자체가 사라지므로 직원테이블과 부서테이블을 따로 관리하는 것이 좋음.
Update anomalies(수정 작업이 데이터 무결성을 깨트리는 것)이 발생함.
개발팀의 부서이름이 DEV -> DEV1으로 변경됐는데 JINHO만 업데이트가 됐을 때 부서 이름의 불일치가 발생하므로 직원테이블과 부서테이블을 따로 관리하는 것이 좋음.
Spurious(가짜의) Tuples
가짜 튜플이 생길 수 있는 오류
프로젝트의 로케이션 이름이 같은 것이 2개로 중복이므로 natural join을 했을 때 각각의 튜플이 생성되어
이렇게 가짜 튜플이 생성되어 버림.
각각 따로 분리하여 각 관심사에 맞는 테이블을 관리하여야 함.
null값이 많아짐으로 인한 문제점들
- null값이 있는 column으로 join하는 경우 상황에 따라 예상과 다른 결과 발생
- null 값이 있는 column에 aggregate function을 사용했을 때 주의 필요
- 불필요한 storage 낭비
바른 DB schema 설계
- 의미적으로 관련있는 속성들끼리 테이블 구성
- 중복 데이터를 최소한으로 하도록 설계
- join 수행 시 가짜 데이터가 생기지 않도록 설계
- 되도록 null값을 줄일 수 있는 방향으로 설계
* 성능 향상을 위해 일부러 테이블을 나누지 않는 경우도 존재.
ex) 여러 테이블을 join하면 성능에 문제가 생길 수도 있음.
출처: https://www.youtube.com/watch?v=JwfQ8ouhAzA&list=PLcXyemr8ZeoREWGhhZi5FZs6cvymjIBVe&index=21
