관계형 데이터베이스 모델링, 정규화

(주)엔코아컨설팅 의 2007년도 교육교재, "관계형 데이터베이스 모델링I(개론)" 교제 참조

- 자료의 홍수에 대응

1. 정보의 선택

    정보로써 가치 있는 데이터만 선택하여 관리

2. 효율적인 관리와 사용

    데이터를 신속하고 편리하게 참조,관리 할 수 있는 시스템 이용

3. 무결성 유지

    데이터 무결성 유지할 수 있는 설계와 이를 보장하는 시스템 이용

- 관계형 데이터 베이스

1. 데이터를 2차원 테이블에 저장, 사용

2. 컬럼의 순서와 로우의 순서에 무관

3. 구조와 뷰를 독립

4. 관계 유지를 위한 정보만을 중복 생성(필요한 중복)

5. 다른 테이블에 있는 같은 데이터들 사이 관계 유지

- 무결성

1. 실체 무결성

    고유한 개체를 식별할 수 있는 속성(하나 혹은 조합)이 하나의 ROW 에 반드시 하나 이상 존재 해야 한다

2. 참조 무결성

    자식은 반드시 부모의 고유한 식별값을 가져야 하고

    부모의 식별값이 없는 자식은 존재해서는 안된다

    가. 입력규칙

        a. Dependent

            부모 instance 가 있어야만 자식 입력 허용

        b. Automatic

            자식 instance 입력 항상 허용, 부모 instance 없을 때 부모를 자동 생성

        c. Nullify

            자식 instance 입력 항상 허용, 부모 instance 없을 때 FK 를 NULL 로 입력

        d. Default

            자식 instance 입력 항상 허용, 부모 instance 없을 때 지정된 기본 값으로 처리

        e. Customized

            특정 검증 조건 만족한 경우에만 자식 instance 입력 허용

        f. No Effect

            자식 instance 입력 무조건 허용

    나. 삭제규칙

        a. Restrict

            대응되는 자식 실체의 instance 가 없어야만 부모 instance 삭제 허용

        b. Cascade

            부모 instance 삭제 항상 허용, 자식 instance 는 자동 삭제

        c. Nullify

            부모 instance 삭제 항상 허용, 자식 instance 존재하면 그 FK 를 NULL 로 입력

        d. Default

            부모 instance 삭제 항상 허용, 자식 instance 존재하면 그 FK 를 지정된 기본 값으로 처리

        e. Customized

            특정 검증 조건 만족한 경우에만 부모 instance 삭제 허용

        f. No Effect

            부모 instance 삭제 무조건 허용

3. 영역 무결성

    논리적 오류 검증

        a. 데이터 타입

            부모, 자식, 참조 시 데이터 속성 일치(불일치 할 경우 index 사용 등에 차질)

        b. 길이

            해당 데이터에 해당하는 적절한 길이 설정

        c. 허용 값

            요일만 입력, 양수만 혹은 음수만 입력 등

        d. 범위 체크

            급여 값 등 입력할 때 최대~최소 값 사이의 값 입력해야 한다 등

        e. 기본 값

            데이터 미 입력 시 기본 값, SYSDATE 등

        f. NULL 여부

            NULL 을 허용할 지, 허용하지 않을 지 결정

- 모델이란

    1. 현실세계 추상화 반영 및 표현

- 데이터 모델(1987, Zechman)

    1. 정보 시스템 구축

    2. 업무 정책 설계

    3. 기업 전략 변경

    4. 청사진, 계획

- 데이터 모델이 제공하는 것

    1. 시스템을 가시화(현재 또는 원하는 모습)

    2. 시스템 구조(Data) 와 업무 프로세스(Process) 명세화

    3. 시스템 구축 기본 틀 제공

    4. 결정사항 문서화

    5. 영역별 집중 및 다른 세부사항 숨김 등 다양한 관점 뷰 제공

    6. 목표에 따른 다양한 상세수준 제공

- 모델링 표현 방법

    Chen, IE(Information Engineering), Barker, IDEF1X(Intergration DEFinition for Information Modeling), UML(Unified Modeling Language)

    Barker 형식 많이 사용

- 관계형 데이터베이스 모델링 3요소

    1. 엔티티(Entity)

        대부분이 테이블

        Peter Chen: 유일하게 식별할 수 있는 사물(1976)

        C.J. Date: 데이터베이스 내에 나타내는 구별할 수 있는 객체(1986)

        Thomas Bruce: 정보로 관리되어야하는 식별 가능한 사람, 장소, 사물, 사건, 개념(1992)

    2. 관계(Relation)

        대부분이 업무로 연결 됨

        2개 이상 개체 연결한 집단화(aggregation)로 구성

        상황에 따라(M:M 관계 시) 관계도 엔티티가 될 수 있다

    3. 속성(Attribute)

        개체 또는 관계의 기초적인 성질

        정의하고 관리하고자 하는 업무에 따라 취급할 관계, 속성 달라짐

- 모델링 기본 프로세스

    A-1. 데이터 요구사항 취합

    A-2. 업무 요구분석

    A-3. 개념적 설계(결과물: 개념적 스키마)

    A-4. 논리적 설계(결과물: 논리적 스키마)

    A-5. 스키마 정제(optional)

    B-1. 물리적 설계(결과물: 물리적 스키마, 논리적 설계(A-4) 로 다시 올라가 물리적 설계까지 필요에 따라 반복)

    B-2. 응용 및 보안설계

    (A 프로세스: 특정 DBMS 고려 불필요, B 프로세스: 특정 DBMS 고려 필요)

- 모델링 상세 프로세스

    1. 재료 수집

    2. 엔티티 검증 및 확정

    3. 릴레이션 조사

    4. 릴레이션 정의

    5. 개념적 모델 완성

    6. 속성 수집 및 확정

    7. 기본 논리적 모델

    8. 데이터 모델 상세

    9. 계층구조 통합

    10. 엔티티 통합

    11. 관계 통합

    12. 이력관리 확정

    (운용 이후, 관계 변화 등)

- 관계

    1. A 는 B 의 C 로서(써) 등으로 흔히 정의 됨(A,B: 엔티티, C: 관계)

    2. 관계의 형태, (M:1, M:M, 1:1), 대부분이 M:1

    3. 관계는 필수 or 선택 으로 엔티티 양측이 각각 필수-필수, 필수-선택, 선택-선택 등으로 관계를 맺음

- 1:1 관계

    1. 드물게 발생되는 형태

    2. 인위적으로 나누는 경우가 많음

    3. 1:1 관계는 업무를 위해 나눈 것이 아니라면 동일한 엔티티로 구성해도 무방 함

    (사원 - 사물함 예)

- M:1 관계

    1. (One or more) - (One and only one) 의 관계 일반적

    2. 1:1 관계는 업무 고유 특성상 인위적으로 나뉘는 경우가 많고, M:M 관계도 결국

        M:1 - 1:M 의 관계로 해소해야 하기 때문에 M:1 관계에 집중해야한다

    3. DA#4 에서의 M:1 도식화

        가. 사원(B) - 사원 전화번호(A)

            (한 사원이 업무 관련 회사에서 지급한 여러개의 휴대전화를 사용할 수 있고,

            해당 휴대전화 번호는 한 사원에 오롯이 포함된다,

            사원 전화번호(들을)를 해당 사원의 고유한 특성으로 볼 수 있다)

        나. 사원아파트(B) - 사원(A)

            (사원아파트 중 사원에 할당 된 아파트도 있고, 사원에 할당되지 않은 아파트도 있다,

            사원 중에는 사원아파트에 입주한 사람도 있고, 입주하지 않은 사람도 있다,

            특성 상 한 사원아파트에 여러 사원이 입주한 경우도 있지만,

            한 사원이 여러 아파트에 입주한 경우는 없다,

            사원을 사원아파트의 고유한 특성으로 볼 수 없다)

        다. 부서(B) - 사원(A)

            (부서에는 반드시 한 명 이상의 소속된 사원이 있고,

            사원은 반드시 하나의 부서에만 포함되어 있다,

            하지만 부서에 포함된 사원(들)을 부서의 고유한 특성으로 볼 수 없다)

        위의 가, 나, 다 의 M:1 에 대한 관계를 아래의 그림으로 표기할 수 있다

[그림 1-1, M:1 관계 종류, DA# 작업]

[그림 1-2, M:1 관계 종류, ERwin 작업, 좌측: One or more, 우측: Zero, One or more)

- 속성

    1. 독립적인 존재가치(원자 단위 인지, 유일하게 존재하는지, 가공한 값이 아닐 것)

    2. 해당 값들에 대한 집합

    3. 관계도 일종의 속성

    4. 속성은 발견과 창조로 도출 해 내는 것

    5. 속성들 간은 서로 독립적

- 속성 후보 선정 원칙

    1. 속성 추출 시 원시(source) 속성으로 보이는 후보는 절대 버리지 말 것(재현할 수 있는가 없는가)

    2. 모든 후보에 대해 각 소속그룹 별로 후보군을 작성하고 가장 근접한 엔티티에 소속 시킴

- 속성 검증 및 확정

    1. 최소 단위로 분할 했는지(원자 단위, 업무에 유의미하게 나누어 사용할 의미가 있다면 나눌 수 있는 데 까지 나눠야 함)

    ex) 이름, 성 으로 분리(Name, Family name)

        우편번호, 시군구, 읍면동

        전화번호, 지역번호, 국번, 개별번호

        주소, 지역주소, 상세주소 등

    2. 유일값 존재 검증(Single value 인지, 제 1 정규화)

        여러 값을 가지거나 반복되는 속성은 잘못 된 것, 새로운 엔티티로 분할 해야 함

    3. 가공값 여부 판정(추출값이냐 아니냐)

        배추, 무, 고추, 마늘, 소금 등으로 만든 김치와 그 김치로 만든 김치찌개에서 김치를 원재료로 볼 지,

        가공식품(추출값) 으로 볼 지를 결정

        소스와 가공물에 대한 판단은 상대적

        논리 데이터 모델링 에서는 재현 비용이 지나치게 많이 소요될 것이 명백한 경우에 한해서 "원천(원시)값" 으로 취급

        차이가 미묘할 때는 실용적/물리적 설계에서 trade off

        이력관리 기준에 따라 판단 달리 할 수 있음

        추출값은 일종의 낭비(redundancy)

        추출값을 취급하게 될 경우 원천값과의 관계를 분명히 정립해야 함

    4. 관리 수준 상세화 검토

        속성이 스스로 자기 소유의 하위 속성들을 가지면 엔티티로 분리 해야 함

        미래의 관리 수준을 감안한 모델링

        최대한 적극적으로 판단해야 함

- 식별자

    1. UID: Unique IDentifier

    2. 하나 혹은 하나 이상의 속성(Attribute) 으로 구성

    3. 모든 엔티티는 반드시 UID 를 가져야 한다

    4. UID 를 가지지 못하면 엔티티가 아니다

    5. UID 를 구성하는 속성은 NULL 일 수 없다

    6. 엔티티는 보조(secondary) 식별자를 가질 수 있고, 단 하나만 두는 것을 원칙으로 한다.

        ex) 사원, 사원번호(UID), 주민등록번호(보조식별자)

    7. 보조식별자는 Unique 한 Index 로 볼 수 없다

    8. 관계 시 하위 엔티티가 자신이 선호하는 식별자를 선택적으로 받아 참조할 수 있도록 해야 한다, 물리적 모델 매핑 단계에서 결정

    9. 인조식별자 지정 원칙(SEQUENCE 값 등)

        최대한 범용적인 값 사용

        유일한 값을 만들기 위해 사용

        하나의 인조 속성, 대체할 수 없는 형태

        내부적으로만 사용, END-USER 는 알 지 못함

        고유한 UID 로 활용할 값을 확보하지 못할 수도 있을 때 사용(주민번호 수집 못할 수 있음)

- 식별자 확정 시 고려사항

    1. 상속과 단절, 부모-자식-손자 관계 A-B-C 엔티티가 있을 때, A 의 UID 를 C 까지 상속해주면

        모델링 상에서 C 는 아버지(B)를 경유하지만 실제로는 단 번에 할아버지(A) 까지 조회 가능 trade off

    

- 무결성 제약 조건

    1. 데이터의 정확성, 유효성, 일관성, 신뢰성을 위해 무효갱신 으로부터 데이터를 보호 함

    2. 데이터 무결성 제약조건 유형

        가. 개체 무결성 제약 - 엔티티의 기본키 속성은 절대 NULL 값을 가질 수 없다

        나. 참조 무결성 제약

            FK 값은 부모 엔티티의 기본키 값이거나 NULL 값이어야 한다

            관계에서 FK 속성은 부모로부터 참조할 수 없는 값을 가질 수 없다

        다. 도메인 무결성 제약

            각 속성의 값들은 해당 속성의 영역범위 내에 같은 type 의 모든 원자값들의 집합이다

        라. 사용자 정의 무결성

            DB 내에 저장된 모든 데이터는 업무 규칙(Business rule) 을 준수해야 한다

- 이상현상

    1. 개념

        데이터 중복으로 인해 관계 기준 조작할 때 발생하는 예기치 못한 비합리적 현상

        비정규화로 인한 하나의 엔티티에 여러 실체 속성들이 혼합 발생한 경우 발생

    2. 삽입이상

        특정 튜플 삽입 시 원치 않거나 확정되지 않은 불필요한 데이터도 함께 삽입해야 하는 현상, 설계 오류 가능성 큼

        (튜플: 물리적 테이블의 레코드, ROW 와 같은 의미)

    3. 삭제 이상

        특정 튜플 삭제할 경우 유지되어야 할 정보까지 삭제되는 연쇄 삭제 현상

    4. 갱신 이상

        특정 속성 값 갱신 시 중복 저장 된 속성값 중 하나만 갱신하고 나머지는 갱신하지 않아 발생하는 데이터 불일치 현상

- 정규화 정의

    이상 현상을 야기하는 속성간의 종속관계 엔티티를 작은 엔티티로 무손실 분해하는 과정

- 함수적 종속성

    속성(attribute) 간의 제약 조건으로 속성 A 가 속성 B 의 결정자이면 B 는 A 에 함수적으로 종속된다 할 수 있다

    1. 결정자 - PK 혹은 FK 등

    2. 완전 함수적 종속성 - 하나 혹은 둘 이상의 결정자에 모두 종속되는 경우

    3. 부분 함수적 종속성 - 둘 이상의 결정자가 존재할 때 그 중 하나에만 종속되는 경우

    4. 이행 함수적 종속성 - 결정자에 의해 함수적으로 종속되고, 결정자에 함수적으로 종속된 다른 속성에도 함수적으로 종속 될 경우

- 정규화 단계 및 종류

    1. 제1정규형(1NF) - 릴레이션 R 에 속한 모든 도메인이 원자값(atomic value) 만으로 되어 있는 경우

    2. 제2정규형(2NF) - 릴레이션 R 이 1NF 이고, 릴레이션의 기본키가 아닌 속성들이, 기본키에 완전히 함수적 종속할 경우

    3. 제3정규형(3NF) - 릴레이션 R 이 2NF 이고, 기본키가 아닌 모든 속성들이 기본키에 대해

                                       이행적 함수 종속성의 관계를 가지지 않는 경우, 즉, 기본키 외의 속성들간에 서로 함수적 속성을 가지지 않는 경우

    ======================= 통상의 실무적 바운더리 =======================

    4. BCNF(Boyce/Codd NF) - 릴레이션 R 의 모든 결정자가 후보키일 경우

    5. 제4정규형(4NF) - BCNF 만족시키면서 다중값 종속을 포함하지 않는 경우

    6. 제5정규형(5NF) - 제4정규형을 만족시키면서 후보키를 통해서만 조인속성이 성립되는 경우

- 제1정규화 예시

[그림 2-1, 제1정규화, 정규화 이전, 동일 값 반복, 다중값]

[그림 2-2, 제1정규화, 정규화 이후 엔티티 1]

[그림 2-3, 제1정규화, 정규화 이후 엔티티 2]

-제2정규화 예시

[그림 3-1, 제2정규화, 정규화 이전, 부분함수 종속 제거]

[그림 3-2, 제2정규화, 정규화 이후 엔티티1]

[그림 3-3, 제2정규화, 정규화 이후 엔티티2]

-제3정규화 예시

[그림 4-1, 제3정규화, 정규화 이전, 이행함수 종속 제거]

[그림 4-2, 제3정규화, 정규화 이후 엔티티1]

[그림 4-3, 제3정규화, 정규화 이후 엔티티2]

- M:M 관계 해소

    1. 실세계 업무 중 대부분은 M:M 관계

    2. 지속적으로 발생하는 엔티티는(히스토리) 대다수가 M:M 관계

    3. 새로운 릴레이션 엔티티를 추가하여 M:1 - 1:M 관계로 변경

    4. 릴레이션 인티티 특성(Intersection entity, M:M 관계 해소 결과물)

        가. Intersection Entity 는 "Entity 는 반드시 Attribute 를 가져야 한다" 는 원칙을 지키지 않을 수 있다

        나. Attribute 가 없는 Intersection Entity 는 상호 참조사항만을 가진다

        다. UID BAR 에 의해 UID 가 결정된다

        라. 선택적으로 Attribute 를 가질 수 있다. 정규화에 위배되지 않는다면 최대만 많은 속성을 가지는 것이 좋다.

[그림 5-1, M:M 관계해소, 단계적]

[그림 5-2, M:M 관계해소, 추가 모델링, 통합 필요]

모델링 작업 으로 각각 상세히 나눠진 엔티티를 필요에 따라 통합해야

실무적으로 의미 있는 모델링 결과물을 도출할 수 있다

- 순환구조(recursive), 자기참조 모델링

    1. 계층형 데이터 모델 모델링 시 이를 통합하면 순환구조(recursive) 관계 데이터 모델이 된다

    2. 순환구조는 새로운 형태의 관계가 아니다

    3. 하나의 순환 Entity 는 각 Entity 의 모든 Attribute 를 포함해야 한다

    4. 각 계층에 있는 Attribute 는 동일하게 모델링 하는 것이 가장 좋다

    5. 순환 모델은 mandatory 관계로 취급할 수 없다(무한 loop 발생), 반드시 optional 한 관계로 취급

    6. 순환모델은 조직의 변경(추가, 삭제) 에 쉽게 대응할 수 있다

    7. 복잡한 관계를 가진 엔티티가 자식을 가질 때 자식들은 더 복잡한 관계에 빠진다(통합의 필요성)

    8. 복잡한 관계의 엔티티들이 유사항 형태로 구성되어 있다면 통합해야 하고 그것을 순환구조로 모델링 할 수 있다

    9. ERD 에 자기참조가 표현되지 않을 수도 있지만 속성명이 prefix 로 "상위", "이전" 등과 함께 그 값이

        해당 엔티티 내에서 참조를 하고 있다면 해당 엔티티는 순환관계이다

    10. 최상위는 "상위","이전" 값으로 스스로의 값을 가지는 것 보다, NULL 값을 가지는 것이 옳다

- 이력관리(히스토리)

    1. 특정 값이 관통하는 해당 시점이 있다

    2. 특정 값이 기록 된 일시가 아니라 추가로 값이 변화된(기록이 있다면) 시점 까지를 이력으로 여긴다

    3. 이력관리 모델

        가. 점 이력 모델

            a. 이력이 발생할 때만 변경여부를(변경 날짜, UPDATE_DT) 기록 해 특정 시점을 기준으로 이력을 조회할 수 있다

            b. 각 시점의 값만 알 수 있을 뿐, 해당 이력을 관리한다고 보기 어렵다

        나. 선분 이력 모델1(한편 넣기)

            a. 이력 발생 시, 해당 이력 시작일 과 해당 이력 종료일 을 기록한다

            b. 최후 이력의 이력 종료일은 시스템이 정한 특정 값으로 처리한다

            c. 일자로 이력관리가 이뤄지는 엔티티에서 동일 일자에 이벤트가 최대한 한 번 만 발생하는 경우에만 사용한다

            d. 시간 까지 관리하는 이력관리에 적용한다

            e. 특정 시점을 기준으로 between 등으로 조회가 가능하다

        다. 선분 이력 모델2(양편 넣기)

            a. 이력 발생 시, 해당 이력 시작일 과 해당 이력 종료일(여기까지는 한편 넣기), 여기에 추가로 발생 순번을 기록한다

            b. 이력에 이벤트 까지 관리할 필요가 있을 경우 사용한다

            c. 동일한 날짜라도 이벤트 발생 횟수 제한 없이 이력을 기록할 수 있다

    4. 이력관리 유형

        가. ROW LEVEL HISTORY MANAGEMENT

            a. 정의: 해당 ROW 의 어떤 값이라도 변경 될 경우 전체 ROW 를 새로 생성시킴

            b. 장점

                ㄱ. 한 번의 조회로 snapshot 조회 가능

                ㄴ. 로그 저장 시 적당 함

                ㄷ. 저장이 쉽다

            c. 단점

                ㄱ. 하나 이상 칼럼 변경 되었을 때 탐지가 모호함

                ㄴ. 이벤트 찾기 위해 과거 데이터와 merge 해야 함

                ㄷ. 이벤트가 자식 정보를 가질 경우 치명적

                ㄹ. 특정 순간만 조회하는 것이 아니라면 처리가 복잡

                ㅁ. 저장 공간 낭비 발생

                ㅂ. 변화가 빈번하지 않아야 용이함

        나. COLUMN LEVEL HISTORY MANAGEMENT

            a. 정의: 이력을 관리하고자 하는 특정 COLUMN 만 변경 될 경우 이력 생성

            b. 장점

                ㄱ. 이벤트가 비교적 분명하게 관리 됨

                ㄴ. 다른 엔티티와 통합 이력 관리 가능

                ㄷ. 변경된 것만 처리 가능(독립적 처리)

                ㄹ. 변화 발생 가능성이 많으면서도 이력을 관리해야 하는 대상 칼럼은 절대적으로 유리함

                ㅁ. 특정 컬럼들에 변화가 집중되는 경우 유리

            c. 단점

                ㄱ. 여러 컬럼에 대한 이력을 관리할 때 많은 merge 발생

                ㄴ. 조건 검색이 어려움

                ㄷ. 변화가 너무 많은 경우 적용 곤란함

        다. SUBJECT LEVEL HISTORY MANAGEMENT

            a. 정의: 내용이 유사하거나 연동될 확률이 높은 것 순으로 ROW LEVEL 로 이력을 발생시킴

            b. 장점

                ㄱ. ROW LEVEL 과 COLUMN 레벨의 장점을 모두 수용

                ㄴ. 목적이 분명한 엔티티를 생성함으로써 확장성 확보

                ㄷ. 변경 부분만 처리 가능(독립적 처리)

                ㄹ. 다른 엔티티와 통합이력 관리 가능

                ㅁ. COLUMN 레벨의 단점을 해소

                ㅂ. 부분에 따라 변경정도의 차이가 심한 경우 유리

            c. 단점

                ㄱ. 전체를 참조할 때 ROW 레벨에 비해 merge 발생 부담

추가로 알아야 할 것,

통합 및 물리적 전환 시 발생하는 것 들

- 서브타입(SUB-TYPE)

    1. 한 엔티티에서 구분자로 서브타입 구분하고 이 때 구분자는 '유형' 을 구분해야 하며 '상태' 를 구분해서는 안된다

    2. 실제로 이것을 구분해 표현할 수 있는 디자인 툴은 드물다(DA# 은 가능), 물리적 모델에서는 구분해 낼 수 없기 때문에

    3. 레벨이 너무 깊은 것은 배제, 다른 엔티티와 관계로 분리

    4. 프로세스를 서브타입으로 만드는 것도 배제, 일종의 상태로 해석이 가능 함

    5. 물리적 모델 전환 시에는 결국 하나의 엔티티 혹은 관계를 가진 다른 엔티티로 분리 해야만 한다

- 물리적 모델 전환 단계

    1. ENTITY 별 테이블 단위 결정

    2. UID 를 기본키(Primary Key)로 전환

    3. 일반 속성(Attribute)들을 컬럼으로 전환

    4. 일반 관계의 컬럼 전환

    5. 배타적 관계 전환형태 결정

    6. 각종 제약조건, 파라미터 결정

- 배타적 관계 혹은 아크(arc) 관계

    1. 둘 이상의 엔티티로 FK 를 받을 때 각각의 엔티티로부터 다른 종류, 다른 값의 FK 를 받을 때

        어떤 엔티티에서 관계를 맺으면 다른 엔티티와 관계가 절단되는 경우가 발생

    2. 관계를 받는 엔티티에서 통합한 하나의 속성으로 관계를 맺을 수 있도록

        다른 데이터 타입의 값이나 둘 이상으로 구성된 키로 관계를 맺게 될 경우에는,

        통합을 위해 임의의 인조 키를 생성해 FK 를 넘겨받는 편이 좋고 그 FK 역시 다른 엔티티에서 넘겨받는 FK 와 호환되는

        데이터 타입이어야 한다

- 인덱스(Index)

    1. 주로 식별자를 인덱싱해서 트리로 정리해 둔 특정 파일에 기록하고 검색 시 파일을 참조해 그 속도를 높인다

    2. SELECT WHERE 문이나 JOIN 문 사용시 유리한 경우가 많고 INSERT, DELETE, UPDATE 시에는 되려 악영향을 끼칠 수도 있다

    3. PK 나 Unique Key 를 정의하면 자동으로 Unique Index 가 생성된다

    4. 인덱스를 추가 할 때는 최대한 기존의 성능에 영향이 덜 미치게 하도록 해야한다