1. PK컬럼순서 대충하지 말자

데이터베이스를 생성할때는 분석->설계->구축->테스트->이행 프로세스를 거치는데 설계 단계 이후 완성된 데이터 모델을 토대로, 물리적인 테이블을 정해진 DBMS에 맞게 생성하게 된다

이때 보통 상용화된 데이터 모델링 툴(ERWin, ERStudio, Rational Rose 등)을 이용해 모델을 만들고 DDL을 생성하기 때문에 설계 단계에서 데이터 베이스를 생성할때 PK 컬럼의 순서는 그다지 신경쓰지 않고 생성하게 되는 경우가 많이 있다

PK순서가 잘못되어 SQL의 성능이 저하되는 경우는 인덱스를 이용하지 못한 경우와 인덱스는 이용하는데 범위가 넓어져 성능이 저하 되는 경우임

테이블 생성전에 SQL Where 절을 분석하여 엔티티타입의 PK 컬럼 순서를 조정하는 작업을해야한다

테이블의 PK컬럼순서와 쿼리 순서를 맞춰야 한다

2. 식별자관계와 비식별자관계 설정 이것만은 알고 해야

식별자관계와 비식별자관계를 잘 모르고 데이터 모델링을 진행할때 발생 오류
-식별자관계만을 이용하여 데이터 모델링을 전개할 경우, PK속성의 숫자가 증가할수록 관련된 SQL구문이 복잡해져 복잡성으로 인한 개발 오류를 유발하게 된다
-비식별자관계만을 이용하여 데이터모델링을 전개할 경우 데이블간의 과다한 조인을 유발하여 조인에 의한 성능 저하를 불러오게 된다

비식별자관계를 선정하는 기준
관계분석 -> 관계의 강약분석 -> 자식테이블 독립 PK 필요 -> SQL 복잡도 증가 개발생산성 판단

관계의 약한관계시, 독립 PK 구성시, SQL  복잡도 증가 개발생산성 저하시에 PK 속성 단순화할때 비식별자관계 설정 고려함

식별자관계
목적:강한 연결관계 표현
자식PK영향:자식PK의 구성에 포함됨
표기법 :실선 표현
연결고려사항
-반드시 부모 엔티티타입 종속
-자식 PK 구성에 부모 PK 포함 필요
-상속받은 PK 속성을 타 엔티티타입에 이전 필요

비식별자관계
목적:약한연결관계 표현
자식PK영향:자식일반속성에포함됨
표기법:점선표현
연결고려사항
-약한 종속관계
-자식PK구성을 독립적으로 구성
-자식PK구성에 부모PK부분 불필요
-부모 쪽의 관계참여가 선택 관계임
-상속받은 PK속성을 타 엔티티타입에 재상속 차단 필요

3 이력유형 데이터 모델링 이렇게 하라

이력데이터모델의 특징
-시간에 따라 발생한다
-동일한 칼럼에 발생한다
-대량 데이터가 발생할 가능성이 높다
-성능에 영향을 주는 경우가 많다

내부 스냅샷 이력
특징:한개의 테이블
장점
-이력관계 설정 용이함
-데이터중복없음
고려할점
-현재 관계만 필요한 경우 불필요한 PK속성 상속
-대량의 데이터가 한군데 집중됨

1:M 스냅샷 전체 이력
특징:두개의 테이블(현재와 현재+과거 테이블)
장점
-현재/이력 관계 설정 용이함
-현재 데이터에 대한 성능 처리 용이함
고려할점
-현재 데이터 중복
-관리 항목 증가

1:M스냅샷 과거 이력
특징:두개의 테이블(현재와 과거 테이블)
장점
-현재/이력관계 설정 용이함
-현재 데이터에 대한 성능 처리 용이함
-현재 데이터 중복 없음
고려할 점
-관리 항목 증가
-현재와 과거 데이터 조회시 조인이 발생하여 성능 저하됨

1:M 스냅샷 군집 전체 이력
특징:N개의 테이블(현재와 현재+과거테이블)
장점
-칼럼이 많은 데이블 관심사 분리
-컬럼 분리로 DISK IO경감
-관심 항목 관계 설정 가능
고려할 점
-관리 항목 증가 큼
-과거 데이터 조회 시 조인 과다 발생으로 성능 저하
-현재 데이터 중복

1:M 스냅샷 군집 과거 이력
특징:N개의 테이블(현재와 과거 테이블)
장점
-컬럼이 많은 테이블 관심사 분리
-컬럼 분리로 DISK IO 경감
-관심 항목 관계 설정 가능
-현재 데이터 중복 없음
고려할 점
-관리 항목 증가 큼
-현재와 과거 데이터 조회시 조인이 과다 발생하여 성능 저하

이 중 가장 많이 사용되는 유형은 1:M 스냅샷 전체 이력형식이다


4. 엔티티통합? 분리?
적절한 기준에 따라 엔티티타입의 통합과 분리를 결정하는 것은 전문적인 모델링을 전개하는 사람에게 매우 필요한 기술이다

엔티티타입의 통합과 분리에 대한 기준을 어떻게 할것인가는 실전 프로젝트를 전개할때 중요한 고려요소가 된다

업무패턴을 먼저 이해하고 해당업무에서 날아오는 트랜잭션의 패턴을 분석한 다음 엔티티타입의 통합과 분리를 결정해야 한다

엔티티통합의 장점과 단점(6가지)
성능
효과:성능 좋아짐현상, 성능 나빠짐 현상 모두 존재
특징장점:정보가 한군데 집약되어 있으므로 조인 발생을 최소화하여 성능저하를 예상할 수 있음
특징단점:대량의 데이터가 한군데 존재할경우 트랜잭션의 집중현상과 데이터량증가로 인한 성능 저하가 나타날 수 있음
고려요소:정보의 양이 대용량이거나, 트랜잭션이 집약된 정보에 집중될 것으로 예상된다면 엔티티타입 분리가 바람직함

속성제약
효과:나빠짐
특징
-고유한 속성의 제약조건을 걸지 못하는 현상이 발생함
-Default, Check Constraint, Null등 고유한 컬럼 규칙을 지정하지 못하게 됨
고려요소:애플리케이션에서 모두 체크해야함

유연성
효과:나빠짐
특징
-분리되어 있을때 각각의 엔티티타입별로 다른 엔티티타입과 가질 수 있는 관계를 통합하면 관계가 모호해지거나 정확한 관계를 설정할 수 없게 되는 경우가 발생함
고려요소:논리적인 데이터 모델의 경우 유연성이 중요함

업무이해도
효과:나빠짐
특징
-고유한 관계의 해석이 안되므로 데이터 모델만을 보고 업무 파악에 어려움이 발생함
고려요소:논리와 물리 데이터 모델을 구분하여 생성할 수 있음

복잡도
효과:복잡도가 낮아짐
특징
-여기저기 비슷한 정보가 흩어져 있어 복잡해 보이는 데이터 모델을 단순하게 유도할 수 있음


유지보수성
효과:좋아짐
특징
-관리해야할 테이블 개수가 줄어들어 유지보수가 용이해짐





5. PK(primary key)와 UI(unique index)의 차이점

PK
목적:Constraint+Index
공통점:유일성보장
참조무결성:PK/FK에 의해 지정가능
테이블 당 개수 :1개만 가능
인덱스 생성:unique index 생성
역공학 적용시 : PK 인식 가능
NULL 허용:허용 안됨

UI
목적:INDEX
공통점:유일성 보장
참조 무결성:지정 불가능
테이블당 개수:여러개 가능
인덱스 생성:UNIQUE INDEX 생성
역공학 적용시:PK인식 불가능
NULL 허용 : 허용됨

UI만을 이용하였을때 장단점
장점
-PK/FK가 존재하지 않아 DBA가 데이터베이스를 관리하기 쉽다
-개발시점에 데이터 제약이 없으므로 개발이 용이하다
-PK/FK를 이용하지 않기 때문에 성능이 좋아질 수도 있다

단점
-데이터 무결성이 깨어질 수 있다
-데이터무결성이 깨지므로 데이터전환작업시 데이터 정리 작업이 필요하다
-데이터 모델과 테이블의 관계가 일치하지 않는다
-UI는 한 테이블에 여러개 만들수 있으므로 테이블만을 보고는 PK가 무엇인지 구분할수 없다

데이터 모델링할때 그리고 데이터베이스를 구축할때 다음의 네가지 기준에 의하 판단을 해야 한다
-데이터 무결성
-데이터베이스 서능
-데이터베이스 관리의 용이성
-개발자 편의성

6. 자기참조관계 모델링 기법


7. 엔티티 타입 도출
명사를 이용해서 엔티티 타입 도출
데이터 모델과 프로세스 모델 그리고 상관 모델링을 함께 진행하면서 검증수행함

과감하게 업무기술서를 읽어보고
정확하게 업무를 분석하고
해당 업무에서 지속적으로 사용하는 장표를 모으고
해당 업무에 대해 전문가라고 할 수 있는 고객을 만나 어떤 정보를 관리해야 하는지 인터뷰해서 알아내는 사람이 진정한 데이터 모델링의 전문가

엔티티 타입 도출방법은 세가지
-명사형 도출(초기 엔티티타입을 도출할때 가장 많이 사용하는 방법중에 하나)
-정규화 이용(1차, 2차, 3차, BCNF, 4차, 5차)
-엔티티 타입 구분에 의한 4STEP 데이터 모델링(구조 -> 업무흐름 -> 기술적 모델링 -> 모델 검토의 단계)

8. 데이터 모델링 관계의 중요성
관계를 표현하지 않으면 다음과 같은 문제가 생김
-업무의 구조와 흐름을 파악할 수 없다
-PK의 구조를 정확하게 가져갈 수 없다
-효율적인 SQL구문을 작성할 수 없다
-참조 무결성 제약 조건에 의한데이터 참조 무결성 유지가 어렵다

모든 엔티티타입은 관계를 가져야 한다
단 예외적인 케이스 3가지 경우
-코드성 엔티티타입을 표현
-통계성 엔티티타입을 표현
-다른 시스템의 엔티티타입을 참조하거나 참조되는 경우

9. 용어사전과 도메인을 정의하라
데이터 모델링을 하면서 용어사전과 도메인을 정의하지 않고 모델링을 진행할 경우 다음과 같은 문제가 나타난다
-일관성있고 품질이 좋은 데이터 모델/데이터베이스를 구축할 수 없다(데이터타입과 길이가 똑같지 않음)
-애플리케이션 로직 에러를 초래할수 있다(데이터 타입과 길이가 똑같지 않음,  INDEX를 타지 않음)
-데이터 처리에 성능 저하를 유발할 수 있다(PK의 데이터 타입과 길이가 똑같지 않음)

10. 데이터 모델을 검증하라
Validation = 고객 요구사항에 대해 구축된 소프트웨어가 조건을 만족하였는지 체크
Verification = 기본적인 시스템의 요건을 만족하였는지 확인

업무에서 최종적인 데이터베이스를 구축할때까지 데이터 모델의 관점에서는 2개의 큰 마일스톤이 있다
첫번째, 논리적 관점의 데이터 모델의 완성된 형태
두번째, 데이터베이스특성을 고려하여 성능과 용량을 고려한 물리적 관점의 데이터 모델의 형태라 할 수 있다

데이터 모델을 체크할때는 엔티티타입, 속성, 관계, PK, 용어/도메인 정의로 구분한 체크리스트를 가지고 검증하게 된다

엔티티 타입 검토 체크리스트
-선정된 PK가 업무적으로 발생하는 자료의 유일성을 보장?
-자료의 발생 유형이 유사한 엔티티는 통합되었는가?
-PK의 순서는 시스템의 성능을 고려하여 적잘한 순서로 정의되어 있는가?

속성검토 체크리스트
-동일 명칭을 가지는 속성의 타입과 크기는 동일한가?
-감사, 통계등을 고려하여 속성이 정의되어있는가?
관계검토 체크리스트
-엔티티타입 간의 관계까 M:N인 속성은 없는가?
-엔티티타입 간의 관계는 업무적 흐름과 규약이 일치하는가?

도메인/용어 체크리스트
-도메인의 변경에 따라 속성이 변경되고 있는가?
-데이터 모델의 용어가 일관성을 유지하고 있는가?

11. 논리/물리 데이터 모델을 생성하라
논리적인 데이터 모델 - 비즈니스 관점(업무중심의 모델링) - 인식부족 문제 발생가능성 있음
물리적인 데이터 모델 - 데이터베이스 오브젝트 관점(DB중심의 모델링) - knowhow 부족 문제 발생가능성 있음

논리적인 데이터 모델은 비지니스 형상화하여 노테이션을 이용한 모델로 표현하는 것이 가장 중요한 목적
물리적인 데이터 모델은 데이터베이스에 생성하기 위해 인덱스를 생성하며 성능을 향상시키기 위해 반정규화나 언티티타입의 통합과 분리 등을 하는 것이 주요한 목적

기본적으로 튜닝을 할때 index를 이용한다

index는 PK, index등이 대표적이며
index된 컬럼은 기본적으로 정렬된 데이터라고 보면 된다

그래서 제대로 된 index를 이용하기 위해서는 index를 잘 이용할 수 있어야 한다

기본적으로 index를 잘 사용했는지 안했는지 판단하는 방법을 실행계획(execution plan)을 해보면 된다
mysql에는 explain을 쓰면 나온다
여기에 type에 all이 나오면 full scan을 하는 것이다

index 사용규칙
1. where절
왼쪽 컬럼은 그대로 써야 한다
upper라던지 컬럼이름에 편집을 가하면 index가 제대로 이용되지 않는다

오른쪽 컬럼은 수정해도 된다
허나 like 검색을 할 경우 앞에 %를 쓰게 되면 index가 제대로 이용되지 않는다
뒤에 %는 유효하다

2. index를 여러컬럼을 걸수도 있는데 그때는 가장 왼쪽에 선언된 컬럼이 가장 유효하다
그리고 where절에 쓸때도 index가 걸려있는 순서대로 이용해야 한다

3. join을 하더라도 테이블 자체에 10% 내외로 데이터를 추출하지 못한다면 index가 의마가 없다 ex) del_fg 같은 경우등

4. index연산자
=, between and 를 이용해야 한다

5. where 절에 or사용시는
where절에 and는 조건의 인덱스를 사용할수 있지만 or는 인덱스를 이용할수 없다 유의 해야함

인덱스는 정렬개념
플랜은 통계개념이다