핵심 데이터 모델링 4장. 물리 모델링

4️⃣

출처: 핵심 데이터 모델링

https://product.kyobobook.co.kr/detail/S000001975842

6/13(화)

• 일이 잘못되었을 때 내가 책임지는 게 아니기 때문에 입사해서는 고집부리지 말고 시키는대로 할 것 의견 제시정도만 조심스럽게 하기…

• 이 책의 이슈나 초록색 박스의 내용이 좋으니까 자주보기

  우리가 생각 못 할만한 것들을 잘 알려준다.

물리 모델링이란

테이블 설계

관계 설계

재귀적 관계

[ 변동 ]

[ 고정 ]

컬럼 설계

속성-컬럼 변환

[ 시스템 컬럼 ]

컬럼명 부여

데이터 타입 및 길이 지정

이슈1

🚨 이슈2

물리 모델링이란

= 논리 데이터모델을 데이터베이스 종류에 맞게 데이터를 저장할 수 있는 스키마 구조로 변환하는 과정이다.

1. 테이블 생성

   엔티티 → 테이블

   속성 → 컬럼

2. 데이터 타입, 길이, 기본값 정하기

3. 제약조건 설정 : PK, FK, Not Null, Unique, Check

4. 기초 데이터 넣기

5. 데이터베이스 성능 향상
   1. 엔티티를 반정규화(역정규화)
   2. 중복 컬럼 추가

      ex) SELECT salary, salary * 12 as 연봉

      연봉은 계산하면 나오는 컴퓨티드 컬럼이기 때문에 DB에 저장할 필요가 없다. 하지만 금액 계산을 실시간으로 해야 하는 경우에는 데이터가 많으면 계산하는데 시간이 오래걸린다. 이럴 때는 중복을 감수하고 성능을 위해 중복 컬럼을 만든다. DB에 미리 저장을 해놓으면 계산을 안 하기 때문에 성능이 좋아진다.

   3. index
   4. 파티셔닝

이론적으로는 논리와 물리를 구분하지만 실제로는 물리에서 해야 할 일을 논리에서 같이 하기도 한다. 이건 논리에서 해야 하고 이건 물리에서 해야 한다 굳이 이렇게 선 그어서 구분지을 필요 없음. 상황에 따라 유연하게 하면 된다.

테이블 설계

⇒ 넘어감

관계 설계

기본적인 관계, 상호배타적 관계

재귀적 관계

코드가 계층 구조인 경우 재귀적 관계로 표현할 수 있다.

계층 구조 유동적(변동) → 재귀

계층 구조 단계가 정해져있음 → 재귀로 할 필요 X

재귀는 어렵기 때문에 웬만하면 고정으로 하는 게 좋다.

[ 변동 ]

오라클에서는 START WITH ~ CONNECT BY ~을 통해 재귀호출을 쉽게 구현할 수 있다.

[ 고정 ]

고정으로 할 경우에 사전순으로 정렬하면 계층구조가 쫙나온다.

컬럼 설계

물리에서 속성을 컬럼으로 변환하는 과정이 복잡하진 않다.

데이터 표준화를 이미 수행했다면 논리 데이터모델의 속성에 표준용어와 표준단어, 표준도메인을 적용하는 작업이 대부분이다.

논리에서는 속성이 자명성을 위해 구체적이었는데 물리에서는 오히려 이름이 짧아져야 한다.

why? 직접 타이핑을 해야 해서 길면 안됨

속성-컬럼 변환

보통 논리에서 정의한 속성은 물리에서 거의 그대로 사용된다.

[ 시스템 컬럼 ]

최초등록일시, 최초등록자식별번호, 최종수정일시, 최종수정자식별번호와 같은 시스템 컬럼을 모든 테이블에 공통으로 추가해야 한다. (테이블 가장 마지막에 위치하도록 해야 함)

목적 : 데이터가 잘못입력되거나 잘못 업데이트 되었을 경우를 대비해서 필요

컬럼명 부여

컬럼명은 속성을 구성하는 표준단어의 영문약어 조합으로 부여한다.

표준용어에 등록되지 않았다면 속성명을 단어와 단어로 분리하고, 표준단어의 양문약어를 조합하여 컬럼명을 부여한다.

이때 가독성을 위해 영문 약어 사이를 언더바로 구분한다.

데이터 타입 및 길이 지정

p. 194 참고

이슈1

: CHAR, VARCHAR2중 어느 것을 적용할 것인가

결론 : 1글자(Y/N)는 CHAR로 하고 그 외는 다 VARCHAR로 하면 된다.

+) CHAR는 빈 칸을 공백으로 채움

🚨 이슈2

:일자(YYYYMMDD) 컬럼을 VARCHAR2(8)로 할지 DATE로 할지

두 개의 안이 있을 때 각 장단점을 적고 비교해서 선택하면 된다.

	Date	YYYYMMDD
display	X	O
정렬	O	O
날짜계산	O	X
데이터 품질	O	X

1. YYYYMMDD

   장점 : to_char 안 해도 됨

   단점 : 데이터 품질 떨어짐

2. Date

   장점 : 데이터 품질 올라감, 시간까지 알 수 있음, 날짜 계산 시 유리(but 계산할 일 별로 없음 있는 그대로 보여주는 경우가 더 많음)

   단점 : 보여줄 때마다 to_char를 써야 함

면접에서 날짜를 왜 VARCHAR2(8) YYYYMMDD로 했는지 물어봤을 때 대답할 수 있어야 한다.

→ 위 두 케이스의 차이를 알고 있는지 검증용 질문

날짜를 계산할 일이 없어서 VARCHAR2(8)로 결정했다고 대답하면됨

이런 것들이 단순하지만 깊이가 있는 내용이다.

---

+) 🚨 VARCHAR2(8)로 한다면 아래처럼 CHECK CONSTRAINT를 추가하거나 인덱스를 만들어서 오류 데이터가 입력되지 않도록 할 수 있다.

ALTER TABLE EMP ADD CONSTRAINT EMP_CK ENT DI
CHECK (ENT_DT = TO_CHAR (TO_DATE (ENT_DT, 'YYYYMMDD'), 'YYYYMMDD')) ;
'CREATE INDEX EMP_IX01 ON EMP( TO_DATE (ENT_DT, 'YYYYMMDD') );
INSERT INTO EMP VALUES('20190230');
- ORA-01839 : date not valid for month specified

인덱스

YYYYMMDD를 DATE로 변환해서 저장한다.

인덱스를 이용하면 INSERT 시 잘못된 형식의 날짜가 들어오게 될 경우 변환 시 에러가 발생한다.

→ 체크를 통해서 검증하는 건 다들 많이 아는데 인덱스를 이용하는 경우는 좋은 방법이나

---

+) 💡 은행에서는 날짜를 거의 다 VARCAHR를 사용한다.

초단위가 필요한 건 DATE 쓰는데 그 외는 다 VARCAHR다.

은행에서는 시간보다는 날짜가 더 중요하다.

서버가 엄청나게 많은데 그 4000대의 서버 시간이 다 정확하지 않다.

ex) 증여세 10년 하루차이로 10년이 걸리냐 안 걸리냐가 결정됨

그래서 11시 50분쯤에 거래를 못하게 막는다. 처리 중간에 날짜가 넘어갈 수 있기 때문이다. 그날 요청 시간한게 다음날 끝나면 안됨

---

Uploaded by N2T