-
DB 잘못된 설계의 문제
1) 중복 데이터 문제
1-1) insertion anomalies
--> 직원 정보 + 부서 정보를 모두 합한 테이블 설계 시(별개의 간심사가 한 테이블에 있음)
--> 저장 공간 낭비, 실수로 인한 데이터 불일치 가능성 존재
--> ex) 부서 직원 정보 : 소속 부서 "DEV", A라는 사람과 B라는 사람 모두 DEV 일때 DEV라는 데이터 중복으로 공간 낭비 + DEV를 오타를 칠경우 데이터 불일치
--> 부서 배치를 받지 못한 직원 삽입 -> null값 입력 (가급적 안쓰는게 좋음)
--> 임직원이 한명도 없는 부서 입력 -> 직원 정보 null -> 기본키 null 불가 문제 등
--> 부서 정보와 직원 정보를 분리하여 설계1-2) Deletion anomalies
--> 부서 정보와 직원 정보를 통합하여 설계
--> 만일 QA 부서 직원 1명인데, 직원 1명 정보를 삭제하면 부서까지 삭제됨
--> 직원과 부서 정보로 테이블을 나누고 직원 정보만 삭제하면 됨1-3) Update anomalies
--> 부서 정보와 직원 정보를 통합하여 설계
--> 부서 이름 변경되고 어떤 사유로 일부 직원만 이름을 변경(데이터 불일치)
--> 테이블 분리하면, 부서명 테이블에서만 바꿔주면 됨2) Spurious Tuples : 가짜 튜플이 생길 수 있음
--> natural join : 조인 컨디션 명시하지 않아도 서로 다른 두개의 테이블에서 똑같은 애트리뷰트를 가지고 있다면 해당 애트리뷰트로 조인
--> 조인을 하며 의도와 다른 가짜튜플이 발생3) null값이 많아짐으로 인한 문제
--> null값이 있는 컬럼으로 조인하면 예상과 다른 결과 발생할 수 있음
--> null값이 있는 컬럼에 aggregate function을 사용했을 때 주의 필요 ex) COUNT - 널값은 카운트 x / COUNT(*) - 전체 튜플의 수
--> 불필요한 storage 낭비4) 바른 데이터베이스 스키마 설계
--> 의미적으로 관련있는 속성들끼리 테이블 구성
--> 중복 데이터를 최대한 허용하지 않도록
--> join 수행 시 가짜 데이터가 생기지 않도록 설계(PK, FK 잘 활용)
--> 되도록이면 null값을 줄일 수 있도록 설계5) 참고사항 : 성능 향상을 위해 일부러 테이블을 나누지 않는 경우도 있음
