걸음마부터 달리기
DB-6/30 본문
데이터 처리 속도 성능 3가지 요소:
1) 데이터 모델 구조 자체의 개선
2) 데이터 자체의 대용량으로 인한 성능 하락
3) 인덱스 특성을 고려하지 않고 인덱스 생성하여 성능저하
성능 데이터 모델링: 데이터베이스 성능향상을 목적으로 설계단계의 데이터 모델링 때부터 정규화, 반정규화, 테이블통합, 테이블분할, 조인구조, P K, FK 등 여러 가지 성능과 관련된 사항이 데이터 모델링에 반영될 수 있도록 하는 것으로 정의할 수 있다. (== 모델링할때부터 성능에 신경써라)
이러한 성능 데이터 모델링은 Analysis와 Design 단계에서 수행하면 Cost가 적게 든다. 따라서 미리미리 해놓자.
1) 정규화된 모델이 데이터를 주요 관심사별로 분산시키는 효과가 있기 때문에 그 자체로 성능을 향상시키는 효과가 있다.
2) 정규화가 완성된 모델에 대해서 해당 데이터 모델의 각각의 엔터티에 어느 정도 트랜잭션이 들어오는지 살펴보고 엔터티에 대한 용량산정을 하여 설계단계에서 테이블에 대한 성능고려를 엄격하게 적용해야 하는지 고려함.
3) 트랜잭션의 유형을 파악하게 되면 SQL문장의 조인관계 테이 블에서 데이터조회의 칼럼들을 파악할 수 있게 되어 그에 따라 성능을 고려한 데이터 모델을 설계할 수 있다.
4) 용량산정과 트랜잭션의 유형데이터를 근거로 반정규화를 적용함
정규화:
데이터 모델링을 하면서 정규화를 하는 것은 기본적으로 데이터에 대한 중복성을 제거하여 주고 데이터가 관심사별로 처리되는 경우가 많기 때문에 성능이 향상되는 특징을 가지고 있다. 즉 관심사별로 중복성을 피하여 테이블을 설계한다. 하지만 관심사가 다름에도 매번 조인이 발생하는 경우도 있기에 반정규화 전략도 필요하다.
그러면 성능이 정확히 무엇인데? (==CRUD 성능)
1) 조회성능
2) 입력/수정/삭제 성능
결정자: 어떤 애트리뷰트의 값이 다른 애트리뷰트의 값을 고유하게 결정할 수 있음
결정자는 주어진 릴레이션에서 다른 애트리뷰트를 고유하게 결정하는 하나 이상의 애트리뷰트를 의미함
결정자는 키 애트리뷰트이거나 아닐수도 있고, 복합 애트리뷰트일 수 있음
함수적 종속성: 만일 애트리뷰트 A가 애트리뷰트 B의 결정자이면 B가 A에 함수적으로 종속한다고 말함. 이때 B는 의존자
이상(Abnormal) : 일부 속성들의 종속이나 데이터의 중복관계로 데이터 조작시 불일치가 발생하는것.
삭제이상, 삽입이상, 갱신이상 (https://dodo000.tistory.com/19)
함수적 종속성을 제거하는것이 이상(Abnormal)을 제거하는 것은 아님. 함수적 종속성을 관리하는것이 이상을 제거하는것임.
학생 ID는 결정자, 학생 이름은 의존자
수업이름은 결정자, 교수이름은 의존자로 존재한다.
하지만 이것들의 이상을 제거하기 위해 정규화를 시키면
이렇게 쪼갤수 있고, 이는 각 테이블에서 종속성이 남아있는 형태임. 즉 종속성을 관리하는것이 곧 정규화임.
데이터의 중복속성을 제거하고 결정자에 의해 동일한 의미의 일반속성이 하나의 테이블로 집약되므로 한 테이블의 데이터 용량이 최소화되는 효과가 있다.
즉, 정규화로 인해 관심사가 같은 애들은 같은 테이블로 몰아넣다보니 조회에서는 많은 조인문을 써야되는 확률이 높아지고 이는 조회성능에서 성능이 저하될 "가능성" 도 있다. (성능이 향상될 수도 있지만...)
하지만 입력,수정,삭제 성능에서는 Abnormal이 없어지기에 무조건 성능이 향상된다.
그렇다고 반정규화를 해야 조회성능이 올라가냐? >> 이것도 마찬가지로 보장 못한다. 그것이 아래의 사례이다.
제2정규화 :
제2 정규화란 제1 정규화를 진행한 테이블에 대해 완전 함수 종속을 만족하도록 테이블을 분해하는 것이다. 여기서 완전 함수 종속이라는 것은 기본키의 부분집합이 결정자가 되어선 안된다는 것을 의미한다.
출처: https://mangkyu.tistory.com/110 [MangKyu's Diary:티스토리]
즉 기본키가 복합키로 구성되어 있는 경우, 함수적 종속성이 있더라도 그 복합키 전체가 결정자여야 된다. 그 복합키의 부분집합이 결정자면 안된다. 이때는 테이블을 분리해야된다.
사례1)
상황: [그림 Ⅰ-2-4]의 왼쪽 그림은 2차 정규화가 안 된 반정규화된 테이블의 모습이고 오른쪽 그림은 부분키 종속을 정규화하여 두 개의 테이블로 분리해 2차 정규 화된 테이블의 모습이다. 2차 정규화가 안 된 테이블은 직급명과 함께 반정규화된 관서번호, 관서명을 조회하면 하나의 테이블에서 데이터가 조회가 된다. 2차 정규화된 테이블은 관서 번호, 관서명이 관서테이블에만 존재하기 때문에 두 개의 테이블을 조인하여 처리해야 한다
기본키 , 외래키 조건:
외래키는 부모테이블의 기본키와 매핑이 될건데, 이때 외래키는 자식테이블의 기본키가 아니여도 상관없다. 대신 외래키 속성의 값은 무조건 부모테이블의 기본키의 값이어야한다.
조인관련:
https://pearlluck.tistory.com/46
조인의 방향:
책에서 워딩이
"정부보관금관서원장에서 데이터를 조회하는 것이나, 관서와 정부보관금관서원장을 조인하여 데이터를 조회하나 처리 성능은 사용자가 느끼기에는 거의 차이가 나지 않는다. PK가 걸려있는 방향으로 조인이 걸려 Unique Index를 곧바로 찾아서 데이터를 조회하기 때문에, 하나의 테이블에서 조회하는 작업과 비교 했을 때 미미하게 성능 차이가 날 뿐 사용자에게 크게 영향을 줄 만큼 성능이 저하되는 일은 없는 것이다."
FK를 기준으로 보고, FK의 값들을 PK에 걸려있는 값들이랑 연결시키겠다는거임. 이게 조인이잖아.
기본키를 정하는 순간 Unique Index는 자동으로 생기고 이것으로 바로 찾아서 조회하기에 성능 차이가 크지 않다는거.
근데 문제는 '관서등록일자가 2010년 이후 관서를 모두 조회하라’라고 바꿔버리면 반정규화 테이블에서 기본키가 복합키이다보니까 그 두개를 조합하다보니 Unique Index의 경우의 수가 더 많아져서 Index 테이블의 릴레이션이 더 많아짐. 그래서 더 오래걸리게 된다는거.
사례2)
정규화 전 모델에서 '서울 7호’에서 매각된 총매각금액, 총유찰금액을 산출하는 조회용 SQL 문장은
SELECT B.총매각금액 , B.총유찰금액
FROM (SELECT DISTINCT 매각일자 FROM 일자별매각물건 WHERE 매각장소 = '서울 7호') A,
매각일자별매각내역 B
WHERE A.매각일자 = B.매각일자 AND A.매각장소 = B.매각장소;
이 SQL에서는 서브쿼리에 있는 일자별매각물건 100만개를 다 뒤져야돼서 성능이 떨어짐
그래서 2차 정규화시키고 5천건짜리로 쿼리를 작성하여 성능을 좋게 만든다.
SELECT B.총매각금액 , B.총유찰금액
FROM 매각기일 A, 매각일자별매각내역 B WHERE A.매각장소 = '서울 7호'
AND A.매각일자 = B.매각일자 AND A.매각장소 = B.매각장소;
사례3)
사례4)
함수적 종속성:
함수의 종속성(Functional Dependency)은 데이터들이 어떤 기준값에 의해 종속되는 현상을 지칭하는 것이다.
이 때 기준값을 결정자(Determinant)라 하고 종 속되는 값을 종속자(Dependent)라고 한다.
함수의 종속성은 데이터가 가지고 있는 근본적인 속성으로 인식되고 있다. 정규화의 궁극적인 목적은 반복적인 데이터를 분리하고 각 데이터가 종속된 테이 블에 적절하게(프로세스에 의해 데이터의 정합성이 지켜질 수 있어야 함) 배치되도록 하는 것이므로 이 함수의 종속성을 이용하여 정규화 작업이나 각 오브 젝트에 속성을 배치하는 작업에 이용이 되는 것이다.