[1권] 3. 데이터 입출력 구현

[데이터 모델의 개념]

현실 세계의 정보들을 컴퓨터에 표현하기위해 단순화, 추상화하여 체계적으로 표현한 개념적 모형

1. 데이터 모델의 구성요소
     개체(Entity) - 데이터베이스에 표현하려는 것
     속성(Attribute) - 데이터의 가장 작은 논리적 단위
     관계(relationship) - 논리적인 연결
2. 데이터 모델 종류
     개념적 데이터 모델 - 인간의 이해를 돕기위해 현실세계에 대한 인식을 추상적 개념으로 표현하는 과정, 현실세계를 표현, 정보모델 이라고 한다. ex) E-R모델
     논리적 데이터 모델 - 개념적 모델링 과정에서 얻은 개념적 구조를 컴퓨터가 이해하고 처리할 수 있도록 맞춰 변환하는 과정
     물리적 데이터 모델
3. 데이터 모델에 표시할 요소
     구조(structure) - 데이터 구조 및 정적 성질을 표현
     연산(Operation) - DB조작 기본 도구
     제약조건(Constraint) - 실제 데이터의 논리적인 제약조건

[이상(Anomaly)]

테이블에서 일부 속성들의 종속으로 인해 중복이 발생하고, 중복으로 인해 테이블 조작 시 분제가 발생하는 현상

• 삽입이상 : 데이터 삽입 시 의도와는 상관없이 원하지 않은 값들로 인해 삽입X
• 삭제이상 : 의도와는 상관없는 값을도 한께 삭제 되는 현상(연쇄삭제)
• 갱신이상 : 일부 튜플의 정보만 갱신되어 정보에 불일치성이 생기는 현상

함수적 종속 - 데이터의 의미를 표현하는 것, 현실세계를 표현하는 제약조건이 되는 동시에 DB에서 항상 유지되어야할 조건

정규화의 개념 - 테이블의 속성들이 상호 종속적인 관계를 갖는 특성을 이용해 테이블을 무손실 손해하는 과정
  목적 : 중복을 최대한 제거해 삽입, 삭제, 갱신 이상을 줄이는 것

정규화 과정(직접 적고 이해하기)

[논리 데이터 모델의 물리 데이터 모델로 변환]

• 테이블 : DB의 가장 기본적인 오브젝트
   로우(Row) - 튜플, 인스턴스
   컬럼(Column) - 각 속성 항목에 대한 값을 저장
   기본키(Promary Key) - 후보키 중에 선택한 주키(Main key), 한 릴레이션에서 특정 튜플을 유일하게 구별할 수 있는 속성
   외래키(Foreign Key) - 다른 릴레이션의 기본키를 참조하는 속성 또는 속성들의 집합
  [표 그리기]
  
  
  
  

• 엔티티(Entity)를 테이블로 변환
    논리 데이터 모델에서 정의된 엔티티를 물리 데이트 모델의 테이블로 변환
    엔티티를 테이블로 변환 후 테이블 목록 정의서를 작성
    엔티티 -> 테이블
    속성 -> 컬럼
    주 식별자 -> 기본키
    외부 식별자 -> 외래키
    관계 -> 관계

변환 시 고려사항
  테이블과 엔티티 명칭 동일
  테이블은 소스코드의 가독성 위해 영문사용

• 슈퍼타입/서브타입을 테이블로 변환
    슈퍼타입/서브타입은 논리데이터모델에 사용 형태이므로 물리적 설계시 테이블로 변환 해야한다.

1. 슈퍼타입 기준 테이블 변환
     서브타입을 슈퍼타입에 통합 하여 하나의 테이블로 만드는 것
     서브타입에 속성이나 관계가 적을 경우 적용, 통합테이블에는 서브타입의 모든 속성이 포함되어야 함
     장점 : 데이터 엑세스 용이, 수행속도 빠름, SQL문장 단순
     단점 : 컬럼 증가로 디스크 저장공간 증가, 인덱스의 효율 낮아짐, 서브타입에 대한 구분이 필요한 경우가 많이 발생
2. 서브타입 기준 테이블 변환
     슈퍼타입 속성들을 서브타입에 추가해 서브타입들을 개별적인 테이블로 만드는 것
     서브타입에 속성이나 관계가 많이 포함된 경우 적용
     장점 : 서브타입 속성들의 선택사양이 명확한 경우 유리, 서브타입유형 구분 X, 테이블당 크기가 감소해 전체 테이블 스캔시 유리
     단점 : 수행속도 감소, SQL통합 어렵, 부분범위 처리곤란, 뷰는 조회만 가능, UID식별자의 유지관리가 어렵
3. 개별타입 기준 테이블 변환
     슈퍼타입과 서브타입들을 각각의 개별적인 테이블로 변환, 1:1관계 형성
   
     전체 데이터에 대한 처리가 빈번한 경우
     서브타입의 처리가 대부분 독립적으로 발생하는 경우
     통합하는 테이블의 컬럼수가 많은 경우
     서브타입의 컬럼수가 많은 경우
     트랜잭션이 주로 슈퍼타입에서 발생하는 경우
     슈퍼타입의 처리범위가 넓고 빈번하게 발생하여 단일 테이블 클러스터링이 필요한 경우
   
     장점 : 저장공간이 작음, 각각의 테이블에 정보만 조회시 문장작성 용이
     단점 : 같이 처리하면 항상 조인이 발생해 성능 저하

• 속성을 컬럼으로 변환
  논리데이터 모델에서 정의한 속성을 물리데이터 모델의 컬럼으로 변환

1. 일반 속성 변환
2. primary UID를 기본키로 변환
3. primary UID(관계의 UID bar)를 기본키로 변환
4. Secondary UID를 유니크 키로 변환

• 관계를 외래키로 변환
  1:1관계 - 개체 a의 기본키를 개체b의 외래키로 추가하거나 개체b의 기본키를 개체a의 외래키로 추가하여 표현
  1:N관계 - 개체a의 기본키를 개체b의 외래키로 추가하여 표현하거나 별도의 테이블로 표현
  N:M관계 - 릴레이션a와 b의 기본키를 모두 포함한 별도의 릴레이션(교차 릴레이션, 교차 엔티티)으로 표현
  1:M 순환 관계 - 개체a에 개체a의 기본키를 참조하는 외래키 컬럼을 추가하여 표현, 데이터의 계층구조를 표현하기 위해 주로 사용

• 데이터 타입 선택
  CHAR - 고정길이 문자열 Data 최대 2,000Byte 까지 저장 가능
  VARCHAR2 - 가변길이 문자열 Data 최대 4,000Byte 까지 저장 가능
  NUMBER - 38자릿수의 숫자 저장가능
  DATE - 날짜저장

[반정규화]

시스템의 성능향상, 개발 및 운영의 편의성을 위해 정규화된 데이터 모델을 통합, 중복, 분리 하는 과정 / 의도적으로 정규화 원칙을 위배하는 행위 / 효율성 증가하지만 과도한 정규화는 성능 저하

• 테이블 통합
  두개의 테이블이 조인되는 경우가 많아 하나로 합쳐 사용하는 것이 도움이 될 경우 수행
  검색은 간편하지만, 레코드 증가로 처리량 증가
  입력, 수정, 삭제 규칙이 복잡해질 수 있음
  not null, default, check등의 제약조건을 설계하기 어려움

• 테이블 분할
  수평분할 : 레코드를 기준으로 분할
  수직분할 : 속성을 기분으로 분할, 갱신위주/ 자주조회 / 크기 큰 / 보안적용

   기본키의 유일성 관리 어려움
   사용 빈도 낮을 경우 분할필요고려
   수행속도 느려질 수 있음
   데이터 검색에 중점을 두어 테이블 분할여부를 결정

• 중복테이블 추가
  여러 테이블에서 추출해 사용하거나 다른서버에 저장된 테이블 이용시 중복테이블을 추가하여 작업의 효율성 향상

   정규화로 수행속도 느려지는 경우
   많은 범위의 데이터를 자주처리해야 하는경우
   특점범위 데이터만 자주처리하는 경우
   범위를 줄이지 않고는 속도개선이 없는 경우

• 중복 속성 추가
  조인해서 데이터를 처리할 때 데이터를 조회하는 경로를 단축하기 위해 자주 사용하는 속성을 하나 더 추가하는 것, 무결성 확보가 어렵고 디스크 공간이 추가로 필요함

   조인이 자주 발생하는 속성인 경우
   접근경로가 복잡한 속성인 경우
   액세스의 조건으로 자주 사용되는 속성인 경우
   기본키의 형태가 적절하지 않거나 여러개의 속성으로 구성된 경우

<중복 속성 추가 시 고려사항>
테이블 중복과 속성의 중복을 고려
데이터 일관성 및 무결성 유의
SQL 그룹 함수를 이용해 처리가능해야함
저장 공간의 낭비 고려

[인덱스 설계]

인덱스는 데이터 레코드를 빠르게 접근하기 위해 <키, 값, 포인터> 쌍으로 구성되는 데이터 구조

인덱스는 데이터가 저장된 물리적 구조와 밀접한 관계
레코드가 저장된 물리적 구조에 접근하는 방법을 제공
인덱스를 통해 파일의 레코드에 대한 엑세스를 빠르게 수행
삽입삭제가 수시로 일어나는 경우 인덱스 갯수를 최소화 하는 것이 효율적
인덱스가 없으면 특정한 값을 찾기위해 모든 데이터 페이지를 확인하는 TABLE SCAN 발생

클러스터드 인덱스 - 인덱스 키의 순서에 따라 정렬되어 저장, 원하는 데이터를 빠르게 찾을 수 있음
                           데이터 삽입, 삭제 시 순서 유지위해 데이터 재정렬, 한개의 릴레이션 한개의 인덱스

• 트리기반 인덱스
  인덱스를 저장하는 블록들이 트리구조를 이루고 있는 것
  B트리 인덱스 : 일반적으로 사용, 루트에서 하위로 값을 비교해 데이터 검색, 포인터들이 오름차순
  B+트리 인덱스 : B트리의 변형으로 단말노드가 아닌 노드로 구성된 세트와 단말노드로만 구성된 순차세트로 구분

• 비트맵 인덱스
  데이터를 Bit 값인 0또는 1로 변환하여 인덱스 키로 사용하는 방법
  목적 : 키 값을 포함하는 로우의 주소를 제공
  분포도가 좋은 컬럼에 적합, 논리연산 가능, 저장공간이 작음, 압축효율 좋음

• 함수기반 인덱스
  컬럼의 값 대신 컬럼에 특정 함수나 수식을 적용하여 산출된 값을 사용, B트리 비트맵 인덱스를 생성해 사용

• 비트맵 조인 인덱스
  다수의 조인된 객체로 구성, 단일 객체로 구성된 일반 인덱스와 액세스 방법이 다르다.
  비트맵 인덱스와 물리적 구조 동일

• 도메인 인덱스
  개방자가 필요한 인덱스를 직접 만들어 사용, 확장형 인덱스

• 인덱스 대상 테이블 선정 기준
  MULTI BLOCK READ 수에 따라 판단
  랜덤 액세스가 빈번한 테이블
  특정 번위나 특정 순서로 데이터 조화가 필요한 테이블
  다른 테이블과 순차적 조인이 발생되는 테이블

• 인덱스 설계시 고려사항
  새로 추가되는 인덱스는 기존 경로에 영향 가능성
  인덱스 많으면 오버헤드 발생
  넓은 범위를 인덱스로 처리 시 오버헤드 발생
  인덱스 생성시 추가적인 저장공간 필요
  인덱스와 테이블 데이터의 저장공간이 분리되도록 설계

[뷰 설계]

뷰는 사용자에게 접근이 허용된 자료만을 제한적으로 보여주기 위해 하나 이상의 기본 테이블로부터 유도된, 이름을 가지는 가상테이블

저장장치 내에 물리적으로 존재 X, 사용자에게는 있는 것처럼 간주
조인문의 사용 최소화로 사용상의 편의성을 최대화

기본 테이블로 유도된 테이블이라 기본테이블과 같은 형태, 조작도 거의 비슷
가상이라 물리적으로 구현 X
논리적 독립성
필요한 데이터만 뷰로 정의해서 처리가능하기 때문에 관리 쉽고 명령문 간단

장점 : 논리적 독립성동일 데이터에 대해 동시에 여러 사용자의 상이한 응용이나 요구 지원, 데이터 관리 간단, 자동보안
단점 : 독립적인 인덱스 X, 뷰의 정의 변경 X, 삽입 삭제 갱신연산에 제약이 따름

설계 순서 : 데이블 선정 -> 대상 컬럼 선정 -> 정의서 작성

• 설계 시 고려사항
  테이블 구조 단순화 위해 반복적으로 조인 설정해 사용, 다양한 관점 제시 필요
  보안유지 고려해 설계

[클러스터 설계]

데이터 저장 시 데이터 액세스 효율을 향상시키기 위해 동일한 성격의 데이터를 동일한 데이터 블록에 저장하는 물리적 저장 방법

데이터 조회속도 향상 but 데이터 입력, 수정, 삭제에 대한 성능은 저하
분포도가 넓을 수록 유리 -> 클러스터링하면 저장 공간 절약
클러스터링 된 테이블은 열을 공유해 저장공간이 줄어듬
대용량 처리하는 트랜잭션은 전체스캔이 잦아 클러스터링 X
처리범위가 넓음 -> 단인 테이블 클러스터링
조인이 많이 -> 다중 테이블 클러스터링
파티셔닝 된 테이블은 클러스터링 X

클러스터 대상 테이블 - 분포도 넓음, 대량범위 자주조회, 입력 수정 삭제가 자주발생X, 자주조인, ORDER BY GROUP BY UNION이 빈번한 테이블

[파티션 설계]

대용량의 테이블이나 인덱스를 작은 논리적 단위인 파티션으로 나누는 것
처리는 테이블단위, 저장은 파티션별로 수행

장점
접근 시 액세스 점위를 줄여 쿼리 성능이 향상
데이터가 분산 저장되어 디스크 성능 향상
속도가 빠름, 시스템 장애 시 손상 최소화
파티션 단위로 입 출력 분산

단점
세심한 관리 필요, 조인에 대한 비용 증가, 용량작은 테이블에 파티셔닝 시 성능 저하

• 범위 분할 - 지정한 열의 값을 기준으로 분할

• 해시 분할
  해시함수를 정룔한 결과 값에 따라 데이터 분항
  특정 파티션에 데이터 집중되는 범위분할의 단점보완, 데이터를 고르게 분산 시 유용
  특정데이터 위치 판단X, 데이터가 고른 컬럼(주민번호 등)에 효과적

• 조합 분할 - 범위분할 후 해시함수 적용 해 다시 분할, 범위분할해도 파티션이 클 때 유용

• 파티셔닝키 선정 시 고려사항
  테이블 접근 유형에 따라 파티셔닝이 이뤄지도록 선정
  관리의 용이성을 위래 이력성 데이터는 파티션 생성주기와 소멸주기를 일치시켜야 함

• 인덱스 파티션
  파티션된 테이블의 데이터를 관리하기 위해서 인덱스를 나눈 것

Local Partitioned Index : 테이블 파티션과 인덱스 파티션이 1:1 대응
Global Partitioned Index : 테이블 파티션과 인덱스 파티션이 독립적 구성
Local Partitioned Index가 Global Partitioned Index에 비해 데이터 관리 쉬움

인덱스 파티션은 인덱스 파티션키 컬럼의 위치에 따라 Prefixed Partitioned Index와 Non-Prefixed Partitioned Index로 나뉜다
Prefixed Partitioned Index : 인덱스 파티션키와 인덱스 첫 번째 컬럼이 같음
Non-Prefixed Partitioned Index : 인덱스 파티션키와 인덱스 첫 번째 컬럼이 다름

Local과 Global, Prefixed와 NonPrefixed를 조합하여 여러가지로 구성해 사용