[Hoops PJ] 트러블 슈팅 & TIL (1)

정규화!

식별관계와 비식별관계를 정리하면서 데이터 정규화에 대해 다시 정리를 했다.
해당 부분도 정확하게 아는 것 같지가 않아서 다시 찾아보고 정리를 했다.

우선 식별관계와 비식별관계를 오류없이 하기 위해서는 데이터를 정규화해야 한다. 이런 정규화 개념이 없다면 나중에 여러가지로 문제가 생길 수 있다.

무엇보다 데이터 정규화를 왜 하는 걸까? -> 데이터를 효율적으로 사용하기 위해 데이터에 대한 평탄화 작업이 필요하며 이것이 정규화다.

이상현상 (anormaly)

• 정규화를 거치지 않은 데이터베이스에서 발생할 수 있는 현상
• 갱신,삽입,삭제 이상이 있다.

정규화 목적

• 이상 발생 방지
• 무결성 유지
• 효율적인 검색
• 결론은 휴먼에로 최소화

첫 번째 평탄화

• 1NF : 도메인이 원자 값이어야 한다. (list 이런거 쓰지 말란 얘기)
• 데이터베이스에서 도메인은 문자, 숫자 등의 자료형을 말한다, 도메인 주도설계에서 말하는 도메인은 데이터베이스의 스키마급 개념이다.

데이터베이스	객체지향프로그래밍	비고
스키마	도메인	스키마는 데이터를 위한 데이터. 메타데이터로 표현
속성(컬럼)	필드	데이터베이스에는 ‘행위’ 메서드라는 개념이 없다.
도메인	(원시) 자료형	문자, 숫자, 불린등
엔티티(테이블)	데이터객체	필드로 구성된 클래스를 말한다 (JPA의 entity)

정규화 전

정규화 후

두 번째 평탄화

• 2NF : 부분적 함수 종속성 제거
• 복함키에서 후보키에 종속되어있는 경우 별도 테이블로 분리해준다.
• 정규화 후 두 테이블은 자연스럽게 식별 관계가 된다.

정규화 전

1차 정규화

• 담당교수는 수강과목에 종속적이고 수강과목은 후보키다

2차 정규화

자연스럽게 식별관계로 연결되었고, 수강과목과 학생과의 다대다 관계가 해소되었다.

• M : M -> 1:M , M:1

세 번쨰 평탄화

• 3NF : 종속적 (이행적) 함수 종속성 제거
• a -> b , b -> c 인경우 a -> c가 성립하는 경우
• 정규화 후 두 테이블은 비식별 관계가 된다.

정규화 전

학생은 학과에 종속되고 학과는 단과대에 종속됨

분리

• 학과를 기준으로 단과대를 넣을 수 있지만 단과대를 기준으로 넣어야한다면?
• 공과대는 검색 결과가 2개임 그래서 단과대 컬럼과 학과 두개 컬럼이 다 필요함 이런 복합키는 조인할 때 귀찮다고 함 그래서 학과 코드라는 대체키 하나로 관리

• 2차 정규화는 식별 관계
• 3차 정규화는 비식별관계
• 학과코드는 학생현황에 키로 참여하고 있지 않음 -> 비식별 관계

  조금 힘든 평탄화

• BC(Boyce-Codd)NF : 결정자이면서 후보키가 아닌 것 제거
• 마스터 코드 관리 테이블 정도로 표현하게 된다.
• ERD를 그릴 때 마스터 코드는 릴레이션을 굳이 표시하지 않는다.

정규화 전

정규화 후

• 등급 기준에 따라 값이 정해진다.
• 하짐나 성적은 후보키가 아니므로 테이블을 분리하면 기준 데이터를 찾을 수 없게 된다.

• 기준 테이블을 별도로 만들고 DDL 작성시 코멘트에 적어두어야 한다.

• 밑에 분리된 등급 기준표는 왜래키도 아니고 후보키도 아닌 것에서 분리되었으므로 관계를 가지지 않는다.
• 여러기준을 만족하는 마스터 테이블을 구성하는 것은 설계자의 노하우다.

위와 같이 마스터 테이블은 ERD 관계도에 표시되지는 않지만 매우 중요한 테이블이다.

평탄화를 하지 말아야 할 때 (역정규화)

• 테이블이 너무 쪼개져서 조인하기 힘들 때
• 보통 개발 편의를 위해 하는데 위와 같이 중간고사 테이블에 이름이 꼭 들어가야할 경우 이름을 수정하게 되면 무결성의 원칙이 깨지기 때문에 해당 컬럼은 수정을 하지 못 하게 막아둠