정처기3: 데이터베이스 구축

Starman·2021년 7월 29일
0

[ 데이터베이스 구축 ]

1장. 논리 데이터베이스 설계

070 데이터베이스 설계

데이터베이스 설계 시 고려사항

  • 무결성
  • 일관성
  • 회복
  • 보안
  • 효율성
  • 데이터베이스 확장

데이터베이스 설계 순서

  1. 요구조건 분석
  2. 개념적 설계
  3. 논리적 설계
  4. 물리적 설계
  5. 구현

요구 조건 분석

  • 데이터베이스를 사용할 사람들로부터 필요한 용도를 파악하는 것
  • 데이터베이스 사용자에 따른 수행 업무와 필요한 데이터의 종류, 용도, 처리 형태, 흐름, 제약 조건 등을 수집
  • 수집된 정보를 바탕으로 요구 조건 명세를 작성

개념적 설계(정보 모델링, 개념화)

  • 개념적 설계란 정보의 구조를 얻기 위하여 현실 세계의 무한성과 계속성을 이해하고, 다른 사람과 통신하기 위하여 현실 세계에 대한 인식을 추상적 개념으로 표현하는 과정
  • 개념적 설계 단계에서 개념 스키마 모델링과 트랜잭션 모델링을 병행 수행함.
  • 요구 분석 단계에서 나온 결과인 요구 조건 명세를 DBMS에 독립적인 E-R 다이어그램으로 작성
  • DBMS에 독립적인 개념 스키마를 설계

논리적 설계(데이터 모델링)

  • 논리적 설계 단계란 현실 세계에서 발생하는 자료를 컴퓨터가 이해하고 처리할 수 있는 물리적 저장장치에 저장할 수 있도록 변환하기 위해 특정 DBMS가 지원하는 논리적 자료 구조로 변환시키는 과정
  • 개념 세계의 데이터를 필드로 기술된 데이터 타입과 이 데이터 타입들 간의 관계로 표현되는 논리적 구조의 데이터로 모델화
  • 개념적 설계가 개념 스키마를 설계하는 단계라면 논리적 설계는 개념 스키마를 평가 및 정제하고 DBMS에 따라 서로 다른 논리적 스키마를 설계하는 단계
  • 트랜잭션의 인터페이스를 설계
  • 관계형 데이터베이스라면 테이블을 설계하는 단계

물리적 설계(데이터 구조화)

  • 물리적 설계란 논리적 설계 단계에서 논리적 구조로 표현된 데이터를 디스크 등의 물리적 저장장치에 저장할 수 있는 물리적 구조의 데이터로 변환하는 과정
  • 물리적 설계 단계에서는 다양한 데이터베이스 응용에 대해 처리 성능을 얻기 위해 데이터베이스 파일의 저장 구조 및 액세스 경로를 결정
  • 저장 레코드의 형식, 순서, 접근 경로와 같은 정보를 사용하여 데이터가 컴퓨터에 저장되는 방법을 묘사
  • 물리적 설계 단계에 꼭 포함시켜야 할 것은 저장 레코드의 양식 설계, 레코드 집중(Record Clustering)의 분석 및 설계, 접근 경로 설계 등
  • 물리적 데이터베이스 구조의 기본적인 데이터 단위는 저장 레코드(Stored Record)

데이터베이스 구현

071 데이터 모델의 개념

데이터 모델

  • 현실 세계의 정보들을 컴퓨터에 표현하기 위해서 단순화, 추상화하여 체계적으로 표현한 개념적 모형
  • 데이터 모델 구성 요소: 개체, 속성, 관계
  • 데이터 모델 종류: 개념적 데이터 모델, 논리적 데이터 모델, 물리적 데이터 모델
  • 데이터 모델에 표시할 요소: 구조, 연산, 제약 조건

데이터 모델의 구성 요소

  • 개체(Entity)
  • 속성(Attribute): 데이터의 가장 작은 논리적 단위로서 파일 구조상의 데이터 항목 또는 데이터 필드에 해당함.
  • 관계(Relationship): 개체 간의 관계 또는 속성 간의 논리적인 연결을 의미

개념적 데이터 모델

  • 현실 세계에 대한 인간의 이해를 돕기 위해 현실 세계에 대한 인식을 추상적 개념으로 표현하는 과정

논리적 데이터 모델

  • 개념적 모델링 과정에서 얻은 개념적 구조를 컴퓨터가 이해하고 처리할 수 있는 컴퓨터 세계의 환경에 맞도록 변환하는 과정

데이터 모델에 표시할 요소 *

  • 구조(Structure): 논리적으로 표현된 개체 타입들 간의 관계로서 데이터 구조 및 정적 성질을 표현
  • 연산(Operation): 데이터베이스에 저장된 실제 데이터를 처리하는 작업에 대한 명세로서 데이터베이스를 조작하는 기본 도구
  • 제약 조건(Constraint): 데이터베이스에 저장될 수 있는 실제 데이터의 논리적인 제약 조건

072 데이터 모델의 구성 요소 - 개체(Entity)

개체명 지정 방법

  • 일반적으로 해당 업무에서 사용하는 용어로 지정
  • 약어 사용은 되도록 제한
  • 가능하면 단수 명사를 사용
  • 모든 개체명은 유일해야 함.
  • 가능하면 개체가 생성되는 의미에 따라 이름을 부여

073 데이터 모델의 구성 요소 - 속성(Attribute)

속성 (Attribute)

  • 데이터베이스를 구성하는 가장 작은 논리적 단위
  • 파일 구조상의 데이터 항목 또는 데이터 필드에 해당함.
  • 개체를 구성하는 항목
  • 개체의 특성을 기술
  • 속성의 수를 디그리(Degree) 또는 차수라고 함.

속성의 종류

  • 속성의 특성에 따른 분류
    • 기본 속성 (Basic Attribute)
    • 설계 속성 (Designed Attribute)
    • 파생 속성 (Derived Attribute)
  • 개체 구성 방식에 따른 분류
    • 기본키 속성
    • 외래키 속성
    • 일반 속성

속성 후보 선정 원칙

  • 속성으로 지정할 후보는 최대한 많이 선택하는 것이 좋으며 선정 원칙은 다음과 같음.
    • 원시(Source) 속성으로 판단되는 속성 후보는 버리지 않음.
      • 원시 속성: 다른 속성을 통해 다시 재현할 수 없는 속성
    • 소그룹별로 속성 후보군을 만들고 가장 근접한 개체에 할당함.

속성명 지정 원칙

  • 해당 업무에서 사용하는 용어로 지정
  • 서술형으로 지정하지 않음. 명사형으로 지정
  • 가급적이면 약어의 사용은 제한
  • 개체명은 속성명으로 사용할 수 없음.
  • 개체에서 유일하게 식별 가능하도록 지정

074 데이터 모델의 구성 요소 - 관계(Relationship)

  • 관계: 개체와 개체 사이의 논리적인 연결

관계의 형태

  • 일 대 일 (1:1)
  • 일 대 다 (1:N)
  • 다 대 다 (N:M)

관계의 종류

  • 종속 관계(Dependent Relationship) : 두 개체 사이의 주·종 관계를 표현한 것으로, 식별 관계와 비식별 관계가 있음.
  • 중복 관계(Redundant Relationship) : 두 개체 사이에 2번 이상의 종속 관계가 발생하는 관계
  • 재귀 관계(Recursive Relationship) : 개체가 자기 자신과 관계를 갖는 것으로, 순환 관계라고도 함.
  • 배타 관계(Exclusive Relationship)
    • 개체의 속성이나 구분자를 기준으로 개체의 특성을 분할하는 관계로, 배타 AND 관계와 배타 OR 관계로 구분함.
    • 배타 AND 관계는 하위 객체들 중 속성이나 구분자 조건에 따라 하나의 개체만을 선택할 수 있고, 배타 OR 관계는 하나 이상의 개체를 선택할 수 있음.ㅎ
식별 관계 / 비식별 관계
  • 식별 관계(Identifying Relationship)
    • 개체 A, B 사이의 관계에서 A 개체의 기본키가 B 개체의 외래키이면서 동시에 기본키가 되는 관계
    • B 개체의 존재 여부가 A 개체의 존재 여부에 의존적인 경우 발생
  • 비식별 관계(Non-Identifying Relationship)
    • 개체 A, B 사이의 관계에서 A 개체의 기본키가 B 개체의 비기본키 영역에서 외래키가 되는 관계

075 식별자(Identifier)

  • 하나의 개체 내에서 각각의 인스턴스르 유일(Unique)하게 구분할 수 있는 구분자로, 모든 개체는 한 개 이상의 식별자를 반드시 가져야 함.
  • 분류
    • 대표성 여부에 따라 : 주 식별자(Primary Identifier), 보조 식별자(Alternate Identifier)
    • 스스로 생성 여부에 따라 : 내부 식별자(Internal Identifier), 외부 식별자(Foreign Identifier)
    • 단일 속성 여부에 따라 : 단일 식별자(Single Identifier), 복합 식별자(Composit Identifier)
    • 대체 여부에 따라 : 원조 식별자(Original Identifier), 대리 식별자(Surrogate Identifier)

주 식별자 / 보조 식별자

  • 주 식별자(Primary Identifier): 개체를 대표하는 유일한 식별자
  • 보조 식별자(Alternate Identifier): 주 식별자를 대신하여 개체를 식별할 수 있는 속성
  • 물리적 테이블에서 주 식별자는 기본키로, 보조 식별자는 유니크 인덱스로 지정되어 사용됨.
  • 주 식별자의 4가지 특성: 유일성, 최소성, 불변성, 존재성

내부 식별자 / 외부 식별자

  • 내부 식별자(Internal Identifier): 개체 내에서 스스로 만들어지는 식별자
  • 외부 식별자(Foreign Identifier): 다른 개체와의 관계에 의해 외부 개체의 식별자를 가져와 사용하는 식별자

단일 식별자 / 복합 식별자

  • 단일 식별자(Single Identifier)
  • 복합 식별자(Composit Identifier)

원조 식별자 / 대리 식별자

  • 원조 식별자(Original Identifier): 업무에 의해 만들어지는 가공되지 않은 원래의 식별자로, 본질 식별자라고도 함.
  • 대리 식별자(Surrogate Identifier): 주 식별자의 속성이 두 개 이상인 경우 속성들을 하나의 속성으로 묶어 사용하는 식별자로, 인조 식별자라고도 함.
대리 식별자의 조건
  • 최대한 범용적인 값을 사용
  • 유일한 값을 만들기 위한 대리 식별자를 사용
  • 하나의 대리 식별자 속성으로 대체할 수 없는 경우를 주의
  • 편의성과 단순성, 의미의 체계화를 위한 대리 식별자를 사용할 수 있음.
  • 시스템적인 필요성에 의해 내부적으로만 사용하는 대리 식별자를 사용할 수 있음.

후보 식별자

  • 개체에서 각 인스턴스를 유일하게 식별할 수 있는 속성 또는 속성 집합을 의미
  • 하나의 개체에는 한 개 이상의 후보 식별자가 있고, 이 중 개체의 대표성을 나타내는 식별자는 주 식별자로, 나머지는 보조 식별자로 지정

076 E-R(개체-관계) 모델

E-R(Entity-Relationship, 개체-관계) 모델의 개요

  • E-R 모델은 개념적 데이터 모델의 가장 대표적인 것.

E-R 다이어그램

  • 피터 첸 표기법, 정보 공학 표기법, 바커 표기법 등이 있음.

피터 첸 표기법

정보 공학 표기법(Information Engineering Notation)

바커 표기법(Barker Notation)

077 관계형 데이터 모델

078 관계형 데이터베이스의 구조

관계형 데이터베이스

  • 관계형 데이터베이스를 구성하는 개체(Entity)나 관계(Relationship)를 모두 릴레이션(Relation)이라는 표(Table)로 표현함.
  • 개체를 표현하는 개체 릴레이션, 관계를 나타내는 관계 릴레이션

관계형 데이터베이스의 Relation 구조

  • 튜플(Tuple)
    • 릴레이션을 구성하는 각각의 행
    • 속성의 모임으로 구성
    • 파일 구조에서 레코드와 같은 의미
    • 튜플의 수를 카디널리티(Cardinality) 또는 기수, 대응수라고 함.
  • 속성(Attribute)
    • 데이터베이스를 구성하는 가장 작은 논리적 단위
    • 파일 구조상의 데이터 항목 또는 데이터 필드에 해당
    • 개체의 특성을 기술
    • 속성의 수를 디그리(Degree) 또는 차수라고 함.
  • 도메인(Domain)
    • 하나의 Attribute가 취할 수 있는 같은 타입의 원자값들의 집합

079 관계형 데이터베이스의 제약 조건 - 키(Key)

후보키 (Candidate Key)

  • 릴레이션을 구성하는 속성들 중에서 튜플을 유일하게 식별하기 위해 사용하는 속성들의 부분집합, 즉 기본키로 사용할 수 있는 속성들. 유일성과 최소성 만족

기본키 (Primary Key)

  • 후보키 중에서 특별히 선정된 주키(Main Key)로 중복된 값을 가질 수 없음.

대체키 (Alternate Key)

  • 후보키가 둘 이상일 때 기본키를 제외한 나머지 후보키를 의미함.

슈퍼키 (Super Key)

  • 한 릴레이션 내에 있는 속성들의 집합으로 구성된 키로서 릴레이션을 구성하는 모든 튜플들 중 슈퍼키로 구성된 속성의 집합과 동일한 값은 나타나지 않음.
  • 슈퍼키는 릴레이션을 구성하는 모든 튜플에 대해 유일성은 만족시키지만, 최소성은 만족시키지 못함.

외래키 (Foreign Key)

  • 다른 릴레이션의 기본키를 참조하는 속성 또는 속성들의 집합을 의미

080 관계형 데이터베이스의 제약 조건 - 무결성

  • 무결성(Integrity): 데이터베이스에 저장된 데이터 값과 그것이 표현하는 현실 세계의 실제값이 일치하는 정확성을 의미
  • 무결성 제약 조건: 데이터베이스에 들어 있는 데이터의 정확성을 보장하기 위해 부정확한 자료가 데이터베이스 내에 저장되는 것을 방지하기 위한 제약 조건을 말함.
  • 종류: 개체 무결성, 도메인 무결성, 참조 무결성, 사용자 정의 무결성 등

개체 무결성 (Entity Integrity, 실체 무결성)

  • 기본 테이블의 기본키를 구성하는 어떤 속성도 Null 값이나 중복값을 가질 수 없다는 규정

도메인 무결성 (Domain Integrity, 영역 무결성)

  • 주어진 속성 값이 정의된 도메인에 속한 값이어야 한다는 규정

참조 무결성 (Referential Integrity)

  • 외래키 값은 Null이거나 참조 릴레이션의 기본키 값과 동일해야 함. 즉 릴레이션은 참조할 수 없는 외래키 값을 가질 수 없다는 규정
  • 참조 무결성 제약조건 관련 옵션: Restricted, Cascade, Nullify, Default

사용자 정의 무결성 (User-Defined Integrity)

  • 속성 값들이 사용자가 정의한 제약 조건에 만족해야 한다는 규정

기타

  • 고유 무결성
  • 키 무결성
  • 관계 무결성

데이터 무결성 강화

  • 데이터 무결성은 데이터 품질에 직접적인 영향을 미치므로 데이터 특성에 맞는 적절한 무결성을 정의하고 강화해야 함.
  • 데이터베이스 구축 과정에서 정의해야 함.
  • 데이터 무결성은 애플리케이션, 데이터베이스 트리거, 제약 조건을 이용하여 강화할 수 있음.
    • 애플리케이션
      • 데이터 생성, 수정, 삭제 시 무결성 조건을 검증하는 코드를 데이터를 조작하는 프로그램 내에 추가함.
    • 데이터베이스 트리거
      • 트리거 이벤트에 무결성 조건을 실행하는 절차형 SQL을 추가
    • 제약 조건
      • 데이터베이스에 제약 조건을 설정하여 무결성을 유지

081 관계대수 및 관계해석

관계대수의 개요

  • 관계대수: 관계형 데이터베이스에서 원하는 정보와 그 정보를 검색하기 위해서 어떻게 유도하는가를 기술하는 절차적인 언어
  • 관계대수는 릴레이션을 처리하기 위해 연산자와 연산규칙을 제공하는 언어로 피연산자가 릴레이션이고, 결과도 릴레이션임.
  • 질의에 대한 해를 구하기 위해 수행해야 할 연산의 순서를 명시
  • 관계대수에는 관계 데이터베이스에 적용하기 위해 특별히 개발한 순수 관계 연산자와 수학적 집합 이론에서 사용하는 일반 집합 연산자가 있음.
    • 순수 관계 연산자: Select, Project, Join, Division
    • 일반 집합 연산자: UNION(합집합), INTERSECTION(교집합), DIFFERENCE(차집합), CARTESIAN PRODUCT(교차곱)

Select

  • 릴레이션에 존재하는 튜플 중에서 선택 조건을 만족하는 튜플의 부분집합을 구하여 새로운 릴레이션을 만드는 연산
  • 릴레이션의 행(가로)에 해당하는 튜플을 구하는 것이므로 수평 연산이라고도 함.
  • 연산자의 기호는 그리스 문자 시그마 σ 를 사용함.

Project

  • 주어진 릴레이션에서 속성 리스트(Attribute List)에 제시된 속성 값만을 추출하여 새로운 릴레이션을 만드는 연산. 단 연산 결과에 중복이 발생하면 중복이 제거됨.
  • 릴레이션의 열(세로)에 해당하는 Attribute를 추출하는 것이므로 수직 연산이라고도 함.
  • 연산자의 기호는 그리스 문자 파이 π 를 사용

Join

  • 공통 속성을 중심으로 두 개의 릴레이션을 하나로 합쳐서 새로운 릴레이션을 만드는 연산
  • Join의 결과로 만들어진 릴레이션의 차수는 조인된 두 릴레이션의 차수를 합한 것과 같음.
  • Join의 결과는 Cartesian Product(교차곱)를 수행한 다음 Select를 수행한 것과 같음
    • Cartesian Product(교차곱): 차수는 두 릴레이션의 차수를 합한 것과 같고 튜플은 두 릴레이션의 튜플 수를 곱한 것과 같음.
  • 연산자의 기호 ⋈

Division

  • X ⊃ Y 인 두 개의 릴레이션 R(X)와 S(Y)가 있을 때, R의 속성이 S의 속성값을 모두 가진 튜플에서 S가 가진 속성을 제외한 속성만을 구하는 연산
  • 연산자 기호 ÷

일반 집합 연산자

  • 수학적 집합 이론에서 사용하는 연산자로서 릴레이션 연산에도 그대로 적용 가능
  • 일반 집합 연산자 중 합집합, 교집합, 차집합을 처리하기 위해서는 합병 조건을 만족해야 함.
    • 합병 조건: 합병하려는 두 릴레이션 간에 속성의 수가 같고, 대응되는 속성별로 도메인이 같아야 함.
  • 합집합 UNION
  • 교집합 INTERSECTION
  • 차집합 DIFFERENCE
  • 교차곱 CARTESIAN PRODUCT

관계해석 (Relational Calculus)

  • 수학의 Predicate Calculus(술어 해석)에 기반
  • 관계 데이터의 연산을 표현하는 방법으로, 원하는 정보를 정의할 때는 계산 수식을 사용함.
  • 원하는 정보가 무엇이라는 것만 정의하는 비절차적 특성을 지님.
  • 튜플 관계해석과 도메인 관계해석이 있음.
  • 기본적으로 관계해석과 관계대수는 관계 데이터베이스를 처리하는 기능과 능력면에서 동등하며, 관계대수로 표현한 식은 관계해석으로 표현 가능
  • 질의어로 표현

082 정규화(Normalization)

정규화의 개요

  • 정규화: 종속성 이론을 이용하여 잘못 설계된 관계형 스키마를 더 작은 속성의 세트로 쪼개어 바람직한 스키마로 만들어 가는 과정
  • 제1정규형, 제2정규형, 제3정규형, BCNF형, 제4정규형, 제5정규형 → 차수가 높아질수록 만족해야할 제약 조건 증가
  • 데이터베이스의 논리적 설계 단계에서 수행
  • 논리적 처리 및 품질에 영향
  • 정규화된 데이터 모델은 일관성, 정확성, 단순성, 비중복성, 안전성 등을 보장함.
  • 정규화 수준이 높을수록 유연한 데이터 구축이 가능하고 데이터의 정확성이 높아지는 반면 물리적 접근이 복잡하고 너무 많은 조인으로 인해 조회 성능이 저하됨.

정규화의 목적

  • 데이터 구조의 안정성 및 무결성 유지
  • 어떤 릴레이션이든지 데이터베이스 내에서 표현 가능하게
  • 효과적인 검색 알고리즘 생성
  • 데이터 중복을 배제하여 이상(Anomaly)의 발생 방지 및 자료 저장 공간의 최소화가 가능
  • 데이터 삽입 시 릴레이션 재구성 필요성 감소

Anomaly(이상)의 개념 및 종류

  • 이상(Anomaly): 정규화(Normalization)를 거치지 않으면 데이터베이스 내에 데이터들이 불필요하게 중복되어 릴레이션 조작 시 예기치 못한 곤란한 현상 발생
  • 삽입 이상(Insertion Anomaly): 릴레이션에 데이터 삽입 시 의도와 상관없이 원하지 않은 값들도 함께 삽입되는 현상
  • 삭제 이상(Deletion Anomaly): 릴레이션에서 한 튜플 삭제 시 의도와 상관 없는 값들도 함께 삭제(연쇄 삭제 현상)되는 현상
  • 갱신 이상(Update Anomaly): 릴레이션에서 튜플에 있는 속성값 갱신 시 일부 튜플의 정보만 갱신되어 정보에 모순이 생기는 현상
  • 이상(Anomaly)현상 근본 원인 : 여러 종류의 사실들이 하나의 릴레이션에 모두 표현되어 있기 때문

정규화의 원칙

  • 정보의 무손실 표현, 즉 하나의 스키마를 다른 스키마로 변환할 때 정보의 손실이 있어서는 안됨.
  • 분리의 원칙, 즉 하나의 독립된 관계성은 하나의 독립된 릴레이션으로 분리시켜 표현해야 함.
  • 데이터의 중복성이 감소되어야 함.

정규화 과정

  • 1NF(제1정규형): 릴레이션에 속한 모든 도메인이 원자값(Atomic Value)만으로 되어 있는 릴레이션, 릴레이션의 모든 속성이 단순 영역에서 정의

  • 2NF(제2정규형): 릴레이션 R이 1NF이고, 기본키가 아닌 모든 속성이 기본키에 대하여 완전 함수적 종속관계 만족

    • 함수적 종속(Functional Dependency): 데이터들이 어떤 기준값에 의해 종속되는 것
    • 속성 A가 다른 속성 집합 B 전체에 대해서 함수적 종속이지만 집합 B의 진부분집합 C에 대해서 종속이 아니면 속성 A는 집합 B의 속성들에 대해 완전 함수적 종속 관계에 있다고 함. A가 C에도 함수적 종속일 때, 속성 A는 속성 집합 B에 부분 함수적 종속이라고 함.
    • 부분 함수 종속을 제거해서 완전 함수 종속만 있도록 만들어 주는 것.
    • 복합키 쓰는거 아니면 그냥 통과..

  • 3NF(제3정규형): 릴레이션 R이 2NF이고, 기본키가 아닌 모든 속성이 기본키에 대해 이행적 종속 관계를 이루지 않도록 제한한 관계형

    • 무손실 조인 또는 종속성 보존을 저해하지 않고도 항상 3NF 설계를 얻을 수 있음
    • 이행적 종속 관계 : A → B 이고 B → C 일 때 A → C 를 만족하는 관계

  • BCNF(Boyce-Codd 정규형): 릴레이션 R에서 결정자가 모두 후보키인 관계형(모든 결정자는 후보키이어야 한다)

    • 결정자(Determinant): A에 따라 B가 결정되는 A → B일때 A는 결정자, B는 종속자
    • 3NF에서 후보키가 많고 서로 중첩되는 경우에 적용하는 강한 제3정규형이라고도 함.
    • 모든 BCNF(Boyce-Codd Normal Form)가 종속성을 보존하는 것은 아님.
    • BCNF 제약조건
      • 키가 아닌 모든 속성은 각 키에 대하여 완전 종속
      • 키가 아닌 모든 속성은 그 자신이 부분적으로 들어가 있지 않은 모든 키에 대해 완전 종속
      • 어떤 속성도 키가 아닌 속성에 대해서는 완전 종속 불가능

  • 4NF(제4정규형): 릴레이션 R에 다치 종속 A → B가 성립하는 경우 R의 모든 속성이 A에 함수적 종속

    • 다치 종속(MVD, Multi Valued Dependency): A, B, C 세 개의 속성을 가진 릴레이션 R에서 어떤 복합 속성(A, C)에 대응하는 B의 값의 집합이 A 값에만 종속되고 C 값에는 무관하면, B는 A에 다치 종속

  • 5NF(제5정규형, PJ/NF): 릴레이션 R의 모든 조인 종속이 R의 후보키를 통해서만 성립

    • 조인 종속(Join Dependency): 어떤 릴레이션 R이 자신의 Projection(X, Y, … , Z)에 대한 조인의 결과가 자신과 같을 때 R은 조인 종속(X, Y, … , Z)을 만족

  • 과정 정리
    비 정규 릴레이션 → (도메인이 원자 값) → 1NF → (부분적 함수 종속 제거) → 2NF → (이행적 함수 송속 제거) → 3NF → (결정자 이면서 후보키가 아닌 것 제거) → BCNF → (다치 종속 제거) → 4NF → (조인 종속성 이용) → 5NF

함수적 종속성

  • 완전 함수적 종속 / 부분 함수적 종속

    • 제2정규형은 부분 함수적 종속을 제거하고 완전 함수적 종속으로 만드는 것.
    • 부분 함수적 종속은 PK가 복합키일때만 따진다.
    • 복합키로 구성된 속성들이 전부 결정자가 되서 종속자를 결정한다면 '완전 함수적 종속'이지만, 복합키 속성들 중 일부만 가지고 종속자를 결정한다면 '부분 함수적 종속'이다.
    • 완전 함수적 종속으로만 이루어졌을 때 제2정규형을 만족하는 테이블이라고 함.

  • 이행 함수적 종속

  • 다치 종속

    • 결정자로 여러 값들의 그룹을 이루는 종속자가 2개 이상(?)일 때.
    • 하나의 속성값에 대응되는 (다른 속성의)결과값이 여러개 나오는게, 한 테이블에서 두 개이상 발생할 때.

  • 조인 종속
    - 테이블을 쪼개고, 그것들을 다시 합치면, 다른 튜플들이 나올 수 있다. 이럴때는 테이블을 덜 쪼개서 문제가 된거. 더 잘라야 한다. 이게 5정규형
    - 조인 종속이 있는 테이블이, 후보키가 아닌 속성들로 구성돼 있을 때 5정규형을 적용해서 테이블들을 여러개로 잘라야 한다는 거
    https://youtu.be/-bLCtP2HNHo
    https://youtu.be/RXQ1kZ_JHqg
    https://dodo000.tistory.com/20

  • 4, 5정규형은 실무에서 거의 안 쓰임. 3정규형 정도까지만 실무에서 쓰이고, BCNF정규형 정도는 일반적으로 알아둬야.

083 반정규화(Denormalization)

  • 시스템의 성능 향상, 개발 및 운영의 편의성 등을 위해 정규화된 데이터 모델을 통합, 중복, 분리하는 과정
  • 의도적으로 정규화 원칙을 위배하는 행위
  • 반정규화를 하면 시스템의 성능이 향상되고 관리 효율성은 증가하지만 데이터의 일관성 및 정합성이 저하될 수 있음.
  • 반정규화를 위해서는 사전에 데이터의 일관성과 무결성을 우선으로 할지, 데이터베이스의 성능과 단순화를 우선으로 할지 결정해야
  • 방법에는 테이블 통합, 테이블 분할, 중복 테이블 추가, 중복 속성 추가 등

테이블 통합

  • 두 개의 테이블이 조인되는 경우가 많아 하나의 테이블로 합쳐 사용하는 것이 성능 향상에 도움이 될 경우 수행

테이블 분할

  • 테이블을 수직 또는 수평으로 분할하는 것
  • 수평 분할 (Horizontal Partitioning)
  • 수직 분할 (Vertical Partitioning)
    • 갱신 위주의 속성 분할
    • 자주 조회되는 속성 분할
    • 크기가 큰 속성 분할
    • 보안을 적용해야 하는 속성 분할

중복 테이블 추가

  • 여러 테이블에서 데이터를 추출해서 사용해야 하거나 다른 서버에 저장된 테이블을 이용해야 하는 경우 중복 테이블을 추가하여 작업의 효율성을 향상시킬 수 있음.
  • 방법
    • 집계 테이블 추가
    • 진행 테이블 추가
    • 특정 부분만을 포함하는 테이블 추가

중복 속성 추가

  • 조인해서 데이터를 처리할 때 데이터를 조회하는 경로를 단축하기 위해 자주 사용하는 속성을 하나 더 추가하는 것

084 시스템 카탈로그 (System Catalog)

  • 시스템 그 자체에 관련이 있는 다양한 객체에 관한 정보를 포함하는 시스템 데이터베이스
  • 시스템 카탈로그 내의 각 테이블은 사용자를 포함하여 DBMS에서 지원하는 모든 데이터 객체에 대한 정의나 명세에 관한 정보를 유지 관리하는 시스템 테이블임.
  • 좁은 의미로 데이터 사전(Data Dictionary)라고도 함.

시스템 카탈로그 저장 정보

  • 시스템 카탈로그에 저장된 정보를 메타 데이터라고 함.
  • 메타 데이터의 유형
    • 데이터베이스 객체 정보 : 테이블, 인덱스, 뷰 등의 구조 및 통계 정보
    • 사용자 정보 : 아이디, 패스워드, 접근 권한 등
    • 테이블의 무결성 제약 조건 정보 : 기본키, 외래키, NULL 값 허용 여부 등
    • 함수, 프로시저, 트리거 등에 대한 정보

카탈로그 특징

  • 시스템 카탈로그 자체도 시스템 테이블로 구성되어 있어 사용자가 SQL문을 이용하여 내용을 검색해 볼 수 있음.
  • INSERT, DELETE, UPDATE 문으로 카탈로그를 갱신하는 것은 허용안됨.
  • 데이터베이스 시스템에 따라 상이한 구조를 갖음.
  • 카탈로그는 DBMS가 스스로 생성하고 유지함.
  • 카탈로그 갱신 : 사용자가 SQL문을 실행시켜 기본 테이블, 뷰, 인덱스 등을 변경하면 시스템이 자동으로 시스템 카탈로그를 갱신
  • 분산 시스템에서의 카탈로그 : 보통의 릴레이션, 인덱스, 사용자 등의 정보를 포함할 뿐만 아니라 위치 투명성 및 중복 투명성을 제공하기 위해 필요한 모든 제어 정보도 포함
    • 위치 투명성(Location Transparency) : 접근하려는 데이터의 실제 위치를 알지 못해도 데이터베이스의 논리적인 명칭만으로 데이터베이스에 접근할 수 있는 특성
    • 중복 투명성(Replication Transparency) : 동일 데이터가 여러 곳에 중복되어 있더라도 사용자는 마치 하나의 데이터만 존재하는 것처럼 사용하고, 시스템은 자동으로 여러 데이터에 대한 작업을 수행하는 특성

카탈로그/데이터 사전을 참조하기 위한 DBMS 내의 모듈 시스템

  • 데이터 정의어 번역기(DDL Compiler)
  • 데이터 조작어 번역기(DML Compiler)
  • Data Directory
    • 데이터 사전에 수록된 데이터를 실제로 접근하는 데 필요한 정보를 관리 유지하는 시스템
    • 시스템 카탈로그는 사용자와 시스템 모두 접근할 수 있지만 데이터 디렉터리는 시스템만 접근 가능
  • 질의 최적화기
  • 트랜잭션 처리기

2장. 물리 데이터베이스 설계

085 사전 조사 분석

물리 데이터베이스 설계

  • 물리적 설계 시 고려사항
    • 인덱스 구조
    • 레코드 크기
    • 파일에 존재하는 레코드 개수
    • 파일에 대한 트랜잭션의 갱신과 참조 성향
    • 성능 향상을 위한 개념 스키마의 변경 여부 검토
    • 빈번한 질의와 트랜잭션들의 수행속도를 높이기 위한 고려
    • 시스템 운용 시 파일 크기의 변화 가능성

데이터 명명 규칙 파악

시스템 자원 파악

데이터베이스 관리 요소 파악

  • 파악한 후 이를 기반으로 데이터베이스 시스템 조사 분석서를 작성
    • 데이터베이스 구조
    • 이중화 구성
    • 분산 데이터베이스
    • 접근 제어 / 접근 통제
    • DB암호화

086 데이터베이스 저장 공간 설계

일반 테이블

클러스터드 인덱스 테이블 (Clustered Index Table)

  • 기본키나 인덱스키의 순서에 따라 데이터가 저장되는 테이블
  • 일반적인 인덱스를 사용하는 테이블에 비해 접근 경로가 단축됨.

파티셔닝 테이블 (Partitioning Table)

  • 대용량의 테이블을 작은 논리적 단위인 파티션으로 나눈 테이블
  • 파티셔닝 방식에 따라 범위 분할, 해시 분할, 조합 분할 등으로 나뉨.

외부 테이블 (External Table)

  • 데이터베이스에서 일반 테이블처럼 이용할 수 있는 외부 파일로, 데이터베이스 내에 객체로 존재
  • 외부 테이블은 데이터웨어하우스에서 ETL 등의 작업에 유용하게 사용됨.

임시 테이블 (Temporary Table)

  • 트랜잭션이나 세션별로 데이터를 저장하고 처리할 수 있는 테이블

테이블스페이스 (Tablespace)

  • 테이블이 저장되는 논리적인 영역
  • 하나의 테이블스페이스에 하나 또는 그 이상의 테이블을 저장할 수 있음.
  • 테이블을 저장하면 논리적으로는 테이블스페이스에 저장되고, 물리적으로는 해당 테이블스페이스와 연관된 데이터 파일(Data File)에 저장됨.
  • 데이터베이스를 테이블, 테이블스페이스, 데이터 파일로 나눠 관리하면 논리적 구성이 물리적 구성에 종속되지 않아 투명성이 보장됨.
  • 테이블스페이스 설계 시 고려사항
    • 테이블스페이스는 업무별로 구분하여 지정
    • 대용량 테이블은 하나의 테이블스페이스에 독립적으로 저장
    • 테이블과 인덱스는 분리하여 저장
    • LOB(Large Object) 타입의 데이터는 독립적인 공간으로 지정

087 트랜잭션 분석 / CRUD 분석

트랜잭션의 특성

  • Atomicity(원자성): All or Nothing
  • Consistency(일관성): 트랜잭션 실행의 성공여부에 상관없이 데이터의 내용은 일관성이 유지되어야 한다
  • Isolation(독립성): 연산의 중간 결과에 다른 트랜잭션이나 작업이 접근할 수 없다
  • Durability(영속성): 트랜잭션이 성공으로 끝난 경우 그 결과를 보장받는다

CRUD 분석

  • 데이터베이스 테이블에 변화를 주는 트랜잭션의 CRUD 연산에 대해 CRUD 매트릭스를 작성하여 분석하는 것
  • CRUD 분석을 통해 외부 프로세스 트랜잭션의 부하가 집중되는 데이터베이스 채널을 파악하고 분산시킴으로써 연결 지연이나 타임아웃 오류를 방지할 수 있음.

CRUD 매트릭스

트랜잭션 분석

트랜잭션 분석서

  • 단위 프로세스와 CRUD 매트릭스를 이용하여 작성함.
  • 구성 요소
    • 단위 프로세스
    • CRUD 연산
    • 테이블명, 컬럼명
    • 테이블 참조 횟수
    • 트랜잭션 수
    • 발생 주기

088 인덱스 설계

인덱스 (Index)

  • 클러스터드 인덱스 / 넌클러스터드 인덱스
    • 클러스터드 인덱스 (Clustered Index)
    • 넌클러스터드 인덱스 (Non-Clustered Index)

트리 기반 인덱스

  • B 트리 인덱스
  • B+ 트리 인덱스

비트맵 인덱스

  • 인덱스 컬럼의 데이터를 Bit 값인 0 또는 1로 변환하여 인덱스 키로 사용하는 방법
  • 비트맵 인덱스는 데이터 종류가 적고 동일한 데이터가 많은 경우, 즉 분포도가 낮은 경우 최적의 성능을 발휘함.

함수 기반 인덱스

비트맵 조인 인덱스

도메인 인덱스

인덱스 설계

  • 인덱스를 설계할 때는 분명하게 드러난 컬럼에 대해 기본적인 인덱스를 먼저 지정한 후 개발 단계에서 필요한 인덱스의 설계를 반복적으로 진행
  • 순서
    1. 인덱스의 대상 테이블이나 컬럼 등을 선정
    2. 인덱스의 효율성을 검토하여 인덱스 최적화를 수행
    3. 인덱스 정의서를 작성

인덱스 대상 테이블 선정 기준

  • MULTI BLOCK READ 수에 따라 판단
    • MULTI BLOCK READ: 테이블 액세스 시 메모리에 한 번에 읽어 들일 수 있는 블록의 수
  • 랜덤 액세스가 빈번한 테이블
  • 특정 범위나 특정 순서로 데이터 조회가 필요한 테이블
  • 다른 테이블과 순차적 조인이 발생하는 테이블

인덱스 대상 컬럼 선정 기준

  • 인덱스 컬럼의 분포도가 10~15% 이내인 컬럼
    • 분포도 = (컬럼값의 평균 Row 수 / 테이블의 총 Row 수) X 100
  • 분포도가 10~15% 이상이어도 부분 처리를 목적으로 하는 컬럼
  • 입·출력 장표 등에서 조회 및 출력 조건으로 사용되는 컬럼
  • 인덱스가 자동 생성되는 기본키와 Unique키 제약 조건을 사용한 컬럼
  • 가능한 한 수정이 빈번하지 않은 컬럼
  • ORDER BY, GROUP BY, UNION 이 빈번한 컬럼
  • 분포도가 좁은 컬럼은 단독 인덱스로 구성
  • 인덱스들이 자주 조합되어 사용되는 경우 하나의 결합 인덱스(Concatenate Index)로 생성
    • 결합 인덱스: 한 릴레이션 내에 존재하는 여러 컬럼들을 묶어 하나의 인덱스로 만드는 것. 결합 인덱스는 컬럼 순서에 따라 액세스하는 범위가 달라질 수 있음.
      • 컬럼 순서 우선순위
        1. 항상 사용되는 컬럼
        2. '=' 연산이 되는 컬럼
        3. 분포도가 좋은 컬럼
        4. 정렬이 자주 발생하는 컬럼

인덱스 설계 시 고려사항

  • 새로 추가되는 인덱스는 기존 액세스 경로에 영향을 미칠 수 있음.
  • 인덱스를 지나치게 많이 만들면 오버헤드가 발생함.
  • 넓은 범위를 인덱스로 처리하면 많은 오버헤드가 발생함.
  • 인덱스를 만들면 추가적인 저장 공간이 필요
  • 인덱스와 테이블 데이터의 저장 공간이 분리되도록 설계
    • 인덱스와 테이블을 분리하는 형태는 데이터베이스의 가장 일반적인 형태로, 데이터 저장 시 인덱스의 영향을 받지 않아 저장이 빠름.

089 뷰(View) 설계

뷰

  • 사용자에게 접근이 허용된 자료만을 제한적으로 보여주기 위해 하나 이상의 기본 테이블로부터 유도된, 이름을 가지는 가상 테이블
  • 저장장치 내에 물리적으로 존재하지 않지만, 사용자에게는 있는 것처럼 간주됨.
  • 데이터 보정 작업, 처리 과정 시험 등 임시적인 작업을 위한 용도로 활용됨.
  • 조인문의 사용 최소화로 사용상의 편의성을 최대화함.

뷰의 특징

  • 기본 테이블로부터 유도된 테이블이기 때문에 기본 테이블과 같은 형태의 구조를 사용. 조작도 거의 같음.
  • 가상 테이블이기 때문에 물리적으로 구현되어 있지 않음.
  • 데이터의 논리적 독립성을 제공
  • 관리가 용이. 명령문이 간단해짐.
  • 기본 테이블의 기본키를 포함한 속성(열) 집합으로 뷰를 구성해야만 삽입, 삭제, 갱신 연산이 가능함.
  • 일단 정의된 뷰는 다른 뷰의 정의에 기초가 될 수 있음.
  • 뷰가 정의된 기본 테이블이나 뷰를 삭제하면 그 테이블이나 뷰를 기초로 정의된 다른 뷰도 자동으로 삭제됨.

뷰의 장단점

  • 장점
    • 논리적 데이터 독립성
    • 동일 데이터에 대해 동시에 여러 사용자의 상이한 응용이나 요구를 지원
    • 사용자의 데이터 관리를 간단하게 해줌.
    • 접근 제어를 통한 자동 보안이 제공
  • 단점
    • 독립적인 인덱스를 가질 수 없음.
    • 뷰의 정의 변경 불가
    • 뷰로 구성된 내용에 대한 삽입, 삭제, 갱신 연산에 제약

뷰 설계 시 고려 사항

  • 테이블 구조가 단순화 될 수 있도록 반복적으로 조인을 설정하여 사용하거나 동일한 조건절을 사용하는 테이블을 뷰로 생성

090 클러스터 설계

클러스터(Cluster)

  • 데이터 저장 시 데이터 액세스 효율을 향상시키기 위해 동일한 성격의 데이터를 동일한 데이터 블록에 저장하는 물리적 저장 방법
  • 클러스터링키로 지정된 컬럼 값의 순서대로 저장되고, 여러 개의 테이블이 하나의 클러스터에 저장됨.
    • 클러스터링키: 클러스터링된 테이블에서 각각의 행을 접근할 때 기준이 되는 열로, 데이터를 조회하면 클러스터링키로 지정된 필드에서 시작하여 클러스터링된 테이블의 데이터를 조회함.

클러스터의 특징

  • 클러스터링 된 테이블은 데이터 조회 속도는 향상시키지만 데이터 입력, 수정, 삭제에 대한 성능은 저하시킴.
  • 클러스터는 데이터의 분포도가 넓을수록 유리함.
    • 인덱스는 분포도가 좁은 테이블이 좋지만 클러스터링은 분포도가 넓은 테이블에 유리
  • 데이터 분포도가 넓은 테이블을 클러스터링 하면 저장 공간 절약 가능
  • 클러스터링된 테이블은 클러스터링키 열을 공유하므로 저장 공간이 줄어듬.
  • 대용량을 처리하는 트랜잭션은 전체 테이블을 스캔하는 일이 자주 발생하므로 클러스터링을 하지 않는 것이 좋음.
  • 처리 범위가 넓은 경우에는 단일 테이블 클러스터링을, 조인이 많이 발생하는 경우에는 다중 테이블 클러스터링을 사용
  • 파티셔닝된 테이블에는 클러스터링을 할 수 없음.
  • 클러스터링을 하면 비슷한 데이터가 동일한 데이터 블록에 저장되기 때문에 디스크 I/O가 줄어듬.
  • 클러스터링된 테이블에 클러스터드 인덱스를 생성하면 접근 성능이 향상됨.

클러스터 대상 테이블

  • 분포도가 넓은 테이블
  • 대량의 범위를 자주 조회하는 테이블
  • 입력, 수정, 삭제가 자주 발생하지 않는 테이블
  • 자주 조인되어 사용되는 테이블
  • ORDER BY, GROUP BY, UNION 이 빈번한 테이블

091 파티션 설계

파티션(Partition)

  • 대용량의 테이블이나 인덱스를 작은 논리적 단위인 파티션으로 나누는 것
  • 대용량 DB의 경우 중요한 몇 개의 테이블에만 집중되어 데이터가 증가되므로, 이런 테이블들은 작은 단위로 나눠 분산시키면 성능 저하를 방지할 뿐만 아니라 데이터 관리도 쉬워짐.
  • 테이블이나 인덱스를 파티셔닝 하면 파티션키 또는 인덱스키에 따라 물리적으로 별도의 공간에 데이터가 저장됨.
  • 데이터 처리는 테이블 단위로 이뤄지고, 데이터 자장은 파티션별로 수행됨.

파티션의 장단점

  • 장점
    • 데이터 접근 시 액세스 범위를 줄여 쿼리 성능이 향상됨.
    • 파티션별로 데이터가 분산되어 저장되므로 디스크의 성능이 향상됨.
    • 파티션별로 백업 및 복구를 수행하므로 속도가 빠름.
    • 시스템 장애 시 데이터 손상 정도 최소화 가능
    • 데이터 가용성 향상
    • 파티션 단위로 입출력 분산 가능
  • 단점
    • 하나의 테이블을 세분화하여 관리하므로 세심한 관리가 요구됨.
    • 테이블간 조인에 대한 비용이 증가함.
    • 용량이 작은 테이블에 파티셔닝을 수행하면 오히려 성능이 떨어짐.

파티션의 종류

  • 범위 분할(Range Partitioning)
    • 지정한 열의 값을 기준으로 분할
  • 해시 분할(Hash Partitioning)
    • 해시 함수를 적용한 결과 값에 따라 데이터를 분할
    • 특정 파티션에 데이터가 집중되는 범위 분할의 단점을 보완. 데이터를 고르게 분산
    • 특정 데이터가 어디에 있는지 판단 불가
    • 고객번호, 주민번호 등과 같이 데이터가 고른 컬럼에 효과적
  • 조합 분할(Composite Partitioning)
    • 범위 분할로 분할한 다음 해시 함수를 적용하여 다시 분할하는 방식
    • 범위 분할한 파티션이 너무 커서 관리가 어려울 때 유용

파티션키 선정 시 고려사항

  • 파티션키는 테이블 접근 유형에 따라 파티셔닝이 이뤄지도록 선정
  • 데이터 관리의 용이성을 위해 이력성 데이터는 파티션 생성주기와 소멸주기를 일치시켜야 함.
  • 매일 생성되는 날짜 컬럼, 백업의 기준이 되는 날짜 컬럼, 파티션 간 이동이 없는 컬럼, I/O 병목을 줄일 수 있는 데이터 분포가 양호한 컬럼 등을 파티션키로 선정

인덱스 파티션

  • 인덱스 파티션은 파티션된 테이블의 데이터를 관리하기 위헤 인덱스를 나눈 것
  • 파티션된 테이블의 종속 여부에 따른 분류
    • Local Partitioned Index: 테이블 파티션과 인덱스 파티션이 1:1 대응되도록 파티셔닝. Global Partitioned Index에 비해 데이터 관리가 쉬움.
    • Global Partitioned Index: 테이블 파티션과 인덱스 파티션이 독립적으로 구성되도록 파티셔닝
  • 인덱스 파티션키 컬럼의 위치에 따른 분류
    • Prefixed Partitioned Index: 인덱스 파티션키와 인덱스 첫 번째 컬럼이 같음.
    • Non-Prefixed Partitioned Index: 인덱스 파티션키와 인덱스 첫 번째 컬럼이 다름.
  • Local과 Global, Prefixed와 Nonprefixed를 조합하여 Local Prefixed Partitioned Index, Local Non-Prefixed Partitioned Index, Global Prefixed Partitioned Index 등으로 구성하여 사용함.

092 데이터베이스 용량 설계

  • 데이터베이스 용량 설계는 데이터가 저장될 공간을 정의하는 것.
  • 테이블에 저장될 데이터양과 인덱스, 클러스터 등이 차지하는 공간 등을 예측하여 반영해야 함.

데이터베이스 용량 설계의 목적

  • 용량을 정확히 산정하여 디스크의 저장 공간을 효과적으로 사용하고 확장성 및 가용성을 높임
  • 디스크의 특성을 고려하여 설계함으로써 디스크의 입출력 부하를 분산시키고 채널의 병목 현상을 최소화
  • 디스크에 대한 입출력 경합이 최소화되도록 설계함으로써 데이터 접근성이 향상
  • 데이터 접근성을 향상시키는 설계 방법
    • 테이블의 테이블스페이스와 인덱스의 테이블스페이스를 분리하여 구성
    • 테이블스페이스와 임시 테이블스페이스를 분리하여 구성
    • 테이블을 마스터 테이블과 트랜잭션 테이블로 분류
  • 데이터베이스에 생성되는 오브젝트의 익스텐트 발생을 최소화하여 성능을 향상시킴
    • 익스텐트(Extent): 기본적인 용량이 모두 찼을 경우 추가적으로 할당되는 공간
  • 데이터베이스 용량을 정확히 분석하여 테이블과 인덱스에 적합한 저장 옵션을 지정

데이터베이스 용량 분석 절차

  1. 데이터 예상 건수, 로우(Row) 길이, 보존 기간, 증가율 등 기초 자료를 수집하여 용량을 분석
  2. 분석된 자료를 바탕으로 DBMS에 이용될 테이블, 인덱스 등 오브젝트별 용량을 산정
  3. 테이블과 인덱스의 테이블스페이스 용량을 산정
    • 테이블스페이스 용량은 테이블스페이스에 생성되는 테이블 용량을 모두 더한값에 약 40% 정도를 추가하여 산정
  4. 데이터베이스에 저장될 모든 데이터 용량과 데이터베이스 설치 및 관리를 위한 시스템 용량을 합해 디스크 용량을 산정

093 분산 데이터베이스 설계

  • 분산 데이터베이스: 논리적으로는 하나의 시스템에 속하지만 물리적으로는 네트워크를 통해 연결된 여러 개의 컴퓨터 사이트(Site)에 분산되어 있는 데이터베이스
    • 데이터의 처리나 이용이 많은 지역에 데이터베이스를 위치시킴으로써 데이터의 처리가 가능한 해당 지역에서 해결될 수 있도록 함.

분산 데이터베이스의 구성 요소

  • 분산 처리기: 자체적으로 처리 능력을 가지며, 지리적으로 분산되어 있는 컴퓨터 시스템
  • 분산 데이터베이스: 지리적으로 분산되어 있는 데이터베이스로서 해당 지역의 특성에 맞게 데이터베이스가 구성됨.
  • 통신 네트워크: 분산 처리기들을 통신망으로 연결하여 논리적으로 하나의 시스템처럼 작동할 수 있도록 하는 통신 네트워크

분산 데이터베이스 설계 시 고려 사항

  • 작업부하(Work Load)의 노드별 분산 정책
  • 지역의 자치성 보장 정책
  • 데이터의 일관성 정책
  • 사이트나 회선의 고장으로부터의 회복 기능
  • 통신 네트워크를 통한 원격 접근 기능

분산 데이터베이스의 목표

  • 위치 투명성(Location Transparency): 액세스하려는 데이터베이스의 실제 위치를 알 필요 없이 단지 데이터베이스의 논리적인 명칭만으로 액세스 가능
  • 중복 투명성(Replication Transparency): 동일 데이터가 여러 곳에 중복되어 있더라도 사용자는 마치 하나의 데이터만 존재하는 것처럼 사용하고, 시스템은 자동으로 여러 자료에 대한 작업을 수행
  • 병행 투명성(Concurrency Transparency): 분산 데이터베이스와 관련된 다수의 트랜잭션들이 동시에 실현되더라도 그 트랜잭션의 결과는 영향을 받지 않음.
  • 장애 투명성(Failure Transparency): 트랜잭션, DBMS, 네트워크, 컴퓨터 장애에도 불구하고 트랜잭션을 정확하게 처리

분산 데이터베이스의 장단점

  • 장점
    • 지역 자치성이 높음.
    • 자료의 공유성이 향상
    • 분산 제어가 가능
    • 시스템 성능이 향상
    • 중앙 컴퓨터의 장애가 전체 시스템에 영향을 끼치지 않음.
    • 효용성과 융통성이 높음.
    • 신뢰성 및 가용성이 높음.
    • 점진적 시스템 용량 확장이 용이
  • 단점
    • DBMS가 수행할 기능이 복잡
    • 데이터베이스 설계가 어려움.
    • 소프트웨어 개발 비용이 증가
    • 처리 비용이 증가
    • 잠재적 오류가 증가

분산 데이터베이스 설계

  • 분산 데이터베이스 설계는 애플리케이션이나 사용자가 분산되어 저장된 데이터에 접근하게 하는 것을 목적으로 함.
  • 잘못 설계된 분산 데이터베이스는 복잡성 증가, 응답 속도 저하, 비용 증가 등의 문제가 발생함.
  • 전역 관계망을 논리적 측면에서 소규모 단위로 분할한 후, 분할된 결과를 복수의 노드에 할당하는 과정으로 진행됨. 노드에 할당된 소규모 단위를 분할(Fragment)라고 부름.
  • 분산 설계 방법에는 테이블 위치 분산, 분할(Fragmentation), 할당(Allocation)이 있음.

테이블 위치 분산

  • 데이터베이스의 테이블을 각기 다른 서버에 분산시켜 배치하는 방법을 의미
  • 테이블 위치를 분산할 때는 테이블의 구조를 변경하지 않으며, 다른 데이터베이스의 테이블과 중복되지 않게 배치함.
  • 데이터베이스의 테이블을 각각 다른 위치에 배치하려면 해당 테이블들이 놓일 서버들을 미리 설정해야 함.

분할(Fragmentation)

  • 테이블의 데이터를 분할하여 분산시키는 것
  • 분할 규칙
    • 완전성(Completeness): 전체 데이터를 대상으로 분할해야 함.
    • 재구성(Reconstruction): 분할된 데이터는 관계 연산을 활용하여 본래의 데이터로 재구성할 수 있어야 함.
    • 상호 중첩 배제(Dis-jointness): 분할된 데이터는 서로 다른 분할의 항목에 속하지 않아야 함.
  • 주요 분할 방법
    • 수평 분할: 특정 속성의 값을 기준으로 행 단위로 분할
    • 수직 분할: 데이터 컬럼(속성) 단위로 분할

할당(Allocation)

  • 동일한 분할을 여러 개의 서버에 생성하는 분산 방법.
  • 분류
    • 비중복 할당 방식 --> ??
      • 최적의 노드를 선택해서 분산 데이터베이스의 단일 노드에서만 분할이 존재하도록 하는 방식
      • 일반적으로 애플리케이션에는 릴레이션을 배타적 분할로 분리하기 힘든 요구가 포함되므로 분할된 테이블 간의 의존성은 무시되고 비용 증가, 성능 저하 등의 문제가 발생할 수 있음.
    • 중복 할당 방식
      • 동일한 테이블을 다른 서버에 복제하는 방식. 일부만 복제하는 부분 복제와 전체를 복제하는 완전 복제가 있음.

094 데이터베이스 이중화/서버 클러스터링

데이터베이스 이중화(Database Replication)

  • 시스템 오류로 인한 데이터베이스 서비스 중단이나 물리적 손상 발생 시 이를 복구하기 위해 동일한 데이터베이스를 복제하여 관리하는 것
  • 하나 이상의 데이터베이스가 항상 같은 상태를 유지하므로 데이터베이스에 문제가 발생하면 복제된 데이터베이스를 이용하여 즉시 문제를 해결할 수 있음.
  • 여러 개의 데이터베이스를 동시에 관리하므로 사용자가 수행하는 작업이 데이터베이스 이중화 시스템에 연결된 다른 데이터베이스에도 동일하게 적용됨.
  • 애플리케이션을 여러 개의 데이터베이스로 분산시켜 처리하므로 데이터베이스의 부하를 줄일 수 있음.
  • 손쉽게 백업 서버를 운영

데이터베이스 이중화의 분류

  • 변경 내용의 전달 방식에 따라서 다음과 같이 분류
  • Eager 기법: 트랜잭션 수행 중 데이터 변경이 발생하면 이중화된 모든 데이터베이스에 즉시 전달하여 변경 내용이 즉시 적용되도록 하는 기법
  • Lazy 기법: 트랜잭션의 수행이 종료되면 변경 사실을 새로운 트랜잭션에 작성하여 각 데이터베이스에 전달되는 기법으로, 데이터베이스마다 새로운 트랜잭션이 수행되는 것으로 간주됨.

데이터베이스 이중화 구성 방법

  • 활동-대기(Active-Standby) 방법
    • 한 DB가 활성 상태로 서비스하고 있으면 다른 DB는 대기하고 있다가 활성 DB에 장애가 발생하면 대기 상태에 있던 DB가 자동으로 모든 서비스를 대신 수행
    • 구성 방법과 관리가 쉬워 많은 기업에서 이용
  • 활동-활동(Active-Active) 방법
    • 두 개의 DB가 서로 다른 서비스를 제공하다가 둘 중 한쪽 DB에 문제가 발생하면 나머지 다른 DB가 서비스를 제공
    • 두 DB가 모두 처리를 하기 때문에 처리율이 높지만 구성 방법 및 설정이 복잡

클러스터링(Clustering)

  • 두 대 이상의 서버를 하나의 서버처럼 운영하는 기술
  • 클러스터링은 서버 이중화 및 공유 스토리지를 사용하여 서버의 고가용성을 제공
  • 종류
    • 고가용성 클러스터링: 하나의 서버에 장애가 발생하면 다른 노드(서버)가 받아 처리하여 서비스 중단을 방지하는 방식. 일반적으로 언급되는 클러스터링.
    • 병렬 처리 클러스터링: 전체 처리율을 높이기 위해 하나의 작업을 여러 개의 서버에서 분산하여 처리하는 방식

095 데이터베이스 보안 / 암호화

데이터베이스 보안

  • 데이터베이스의 일부분 또는 전체에 대해서 권한이 없는 사용자가 액세스하는 것을 금지하기 위해 사용되는 기술
  • 보안을 위한 데이터 단위는 테이블 전체로부터 특정 테이블의 특정한 행과 열 위치에 있는 특정한 데이터 값에 이르기까지 다양함.
  • 데이터베이스 사용자들은 일반적으로 서로 다른 객체에 대하여 다른 접근 권리 또는 권한을 갖게 됨.

096 데이터베이스 보안 - 접근통제

접근통제

  • 데이터가 저장된 객체와 이를 사용하려는 주체 사이의 정보 흐름을 제한하는 것
  • 데이터에 대해 다음과 같은 통제를 함으로써 자원의 불법적인 접근 및 파괴를 예방
    • 비인가된 사용자의 접근 감시
    • 접근 요구자의 사용자 식별
    • 접근 요구의 정당성 확인 및 기록
    • 보안 정책에 근거한 접근의 승인 및 거부 등
  • 접근 통제 기술에는 임의 접근통제(DAC), 강제 접근통제(MAC)가 있음.
  • 임의 접근통제(DAC, Discretionary Access Control)
    • 데이터에 접근하는 사용자의 신원에 따라 접근 권한을 부여하는 방식
    • 통제 권한이 주체에 있어 주체가 접근통제 권한을 지정하고 제어할 수 있음.
    • 일반적으로 특정 객체에 대한 조작 권한은 데이터베이스 관리 시스템으로부터 부여받지만 임의 접근통제에서는 객체를 생성한 사용자가 생성된 객체에 대한 모든 권한을 부여받고, 부여된 권한을 다른 사용자에게 허가할 수도 있음.
    • 임의 접근통제에 사용되는 SQL 명령어에는 GRANT와 REVOKE가 있음.
  • 강제 접근통제(MAC, Mandatory Access Control)
    • 주체와 객체의 등급을 비교하여 접근 권한을 부여하는 방식
    • 제3자가 접근통제 권한을 지정
    • 데이터베이스 객체별로 보안 등급을 부여할 수 있고, 사용자별로 인가 등급을 부여할 수 있음.
    • 주체는 자신보다 보안 등급이 높은 객체에 대해 읽기, 수정, 등록이 모두 불가능하고, 보안 등급이 같은 객체에 대해서는 읽기, 수정, 등록이 가능하고, 보안 등급이 낮은 객체는 읽기가 가능함.
  • 접근통제의 3요소는 접근통제 정책, 접근통제 매커니즘, 접근통제 보안모델

접근통제 정책

  • 어떤 주체(Who)가 언제(When), 어디서(Where), 어떤 객체(What)에게, 어떤 행위(How)에 대한 허용 여부를 정의하는 것
  • 신분 기반 정책
    • 주체나 그룹의 신분에 근거하여 객체의 접근을 제한하는 방법으로, IBP와 GBP가 있음.
    • IBP(Individual-Based Policy): 최소 권한 정책으로, 단일 주체에게 하나의 객체에 대한 허가를 부여함.
    • GBP(Group-Based Policy): 복수 주체에 하나의 객체에 대한 허가를 부여
  • 규칙 기반 정책
    • 주체가 갖는 권한에 근거하여 객체의 접근을 제한하는 방법으로, MLP와 CBP가 있음.
    • MLP(Multi-Level Policy): 사용자 및 객체별로 지정된 기밀 분류에 따른 정책
    • CBP(Compartment-Based Policy): 집단별로 지정된 기밀 허가에 따른 정책
  • 역할 기반 정책
    • GBP의 변형된 정책으로, 주체의 신분이 아니라 주체가 맡은 역할에 근거하여 객체의 접근을 제한하는 방법

접근통제 매커니즘

  • 정의된 접근통제 정책을 구현하는 기술적인 방법
  • 접근통제 목록(Access Control List): 객체를 기준으로 특정 객체에 대해 어떤 주체가 어떤 행위를 할 수 있는지를 기록한 목록
  • 능력 리스트(Capability List): 주체를 기준으로 주체에게 허가된 자원 및 권한을 기록한 목록
  • 보안 등급(Security Label): 주체나 객체 등에 부여된 보안 속성의 집합으로, 이 등급을 기반으로 접근 승인 여부가 결정됨.
  • 패스워드
  • 암호화

접근통제 보안 모델

  • 보안 정책을 구현하기 위한 정형화된 모델
  • 기밀성 모델
    • 군사적인 목적으로 개발된 최초의 수학적 모델로, 기밀성 보장이 최우선인 모델
    • 군대 시스템 등 특수 환경에서 주료 사용됨.
    • 제약 조건
      • 단순 보안 규칙: 주체는 자신보다 높은 등급의 객체를 읽을 수 없음.
      • ★(스타)-보안 규칙: 주체는 자신보다 낮은 등급의 객체에 정보를 쓸 수 없음.
      • 강한 ★(스타) 보안 규칙: 주체는 자신과 등급이 다른 객체를 읽거나 쓸 수 없음.
  • 무결성 모델
    • 기밀성 모델에서 발생하는 불법적인 정보 변경을 방지하기 위해 무결성을 기반으로 개발된 모델
    • 데이터의 일관성 유지에 중점을 두어 개발됨.
    • 기밀성 모델과 동일하게 주체 및 객체의 보안 등급을 기반으로 함.
    • 제약 조건
      • 단순 무결성 규칙: 주체는 자신보다 낮은 등급의 객체를 읽을 수 없음.
      • ★(스타)-무결성 규칙: 주체는 자신보다 높은 등급의 객체에 정보를 쓸 수 없음.
  • 접근통제 모델
    • 접근통제 매커니즘을 보안 모델로 발전시킨 것으로, 대표적으로 접근통제 행렬이 있음.
    • 접근통제 행렬(Access Control Matrix)
      • 임의적인 접근통제를 관리하기 위한 보안 모델
      • 행은 주체, 열은 객체 즉, 행과 열로 주체와 객체의 권한 유형을 나타냄.

접근통제 조건

  • 접근통제 매커니즘의 취약점을 보완하기 위해 접근통제 정책에 부가하여 적용할 수 있는 조건
  • 값 종속 통제(Value-Dependent Control): 일반적으로 객체에 저장된 값에 상관없이 접근통제를 동일하게 허용하지만 객체에 저장된 값에 따라 다르게 접근통제를 허용해야 하는 경우에 사용
  • 다중 사용자 통제(Multi-User Control): 지정된 객체에 다수의 사용자가 동시에 접근을 요구하는 경우에 사용
  • 컨텍스트 기반 통제(Context-Based Control): 특정 시간, 네트워크 주소, 접근 경로, 인증 수준 등에 근거하여 접근을 제어하는 방법으로, 다른 보안 정책과 결합하여 보안 시스템의 취약점을 보완할 때 사용

감사 추적

  • 사용자나 애플리케이션이 데이터베이스에 접근하여 수행한 모든 활동을 기록하는 기능

097 데이터베이스 백업

데이터베이스 장애 유형

로그 파일

  • 데이터베이스의 복구를 위해 필요한 가장 기본적인 자료
  • 로그 파일 내용: 트랜잭션이 작업한 모든 내용, 트랜잭션 식별, 트랜잭션 레코드, 데이터 식별자, 갱신 이전 값(Before Image), 갱신 이후 값(After Image) 등

데이터베이스 복구 알고리즘

  • 동기적/비동기적 갱신에 따라 분류
  • NO-UNDO/REDO
    • 데이터베이스 버퍼의 내용을 비동기적으로 갱신한 경우의 복구 알고리즘
    • NO-UNDO: 트랜잭션 완료 전에는 변경 내용이 데이터베이스에 기록되지 않으므로 취소할 필요가 없음.
    • REDO: 트랜잭션 완료 후 데이터베이스 버퍼에는 기록되어 있고, 저장매체에는 기록되지 않았으므로 트랜잭션 내용을 다시 실행해야 함.
  • UNDO/NO-REDO
    • 데이터베이스 버퍼의 내용을 동기적으로 갱신한 경우의 복구 알고리즘
    • UNDO: 트랜잭션 완료 전에 시스템이 파손되었다면 변경된 내용을 취소
    • NO-REDO: 트랜잭션 완료 전에 데이터베이스 버퍼 내용을 이미 저장 매체에 기록했으므로 트랜잭션 내용을 다시 실행할 필요가 없음.
  • UNDO/REDO
    • 데이터베이스 버퍼의 내용을 동기/비동기적으로 갱신한 경우의 복구 알고리즘
    • 데이터베이스 기록 전에 트랜잭션이 완료될 수 있으므로 완료된 트랜잭션이 데이터베이스에 기록되지 못했다면 다시 실행해야 함.
  • NO-UNDO/NO-REDO
    • 데이터베이스 버퍼의 내용을 동기적으로 저장 매체에 기록하지만 데이터베이스와는 다른 영역에 기록한 경우의 복구 알고리즘
    • NO-UNDO: 변경 내용은 데이터베이스와 다른 영역에 기록되어 있으므로 취소할 필요가 없음.
    • NO-REDO: 다른 영역에 이미 기록되어 있으므로 트랜잭션을 다시 실행할 필요가 없음.

백업 종류

  • 복구 수준에 따라서 운영체제를 이용하는 물리 백업과 DBMS 유틸리티를 이용하는 논리 백업으로 나뉨.
  • 물리 백업: 데이터베잇 파일을 백업하는 방법으로, 백업 속도가 빠르고 작업이 단순하지만 문제 발생 시 원인 파악 및 문제 해결이 어려움.
  • 논리 백업: DB 내의 논리적 객체들을 백업하는 방법으로, 복원 시 데이터 손상을 막고 문제 발생 시 원인 파악 및 해결이 수월하지만 백업/복원 시 시간이 많이 소요됨.

098 스토리지 (Storage)

  • 단일 디스크로 처리할 수 없는 대용량의 데이터를 저장하기 위해 서버와 저장장치를 연결하는 기술
  • 종류에는 DAS, NAS, SAN

DAS (Direct Attached Storage)

  • 서버와 저장장치를 전용 케이블로 직접 연결하는 방식 (일반 가정에서 컴퓨터에 외장하드를 연결하는 것 같은)
    • 서버에서 저장장치를 관리
    • 속도가 빠르고 설치 및 운영이 쉬움.
    • 초기 구축 비용 및 유지보수 비용이 저렴
    • 다른 서버에서 접근 불가. 공유 불가.
    • 확장성 및 유연성이 떨어짐.
    • 저장 데이터가 적고 공유가 필요없는 환경에 적합

NAS (Network Attached Storage)

  • 서버와 저장장치를 네트워크를 통해 연결하는 방식
    • 별도의 파일 관리 기능이 있는 NAS Storage가 내장된 저장장치를 직접 관리
    • Ethernet 스위치를 통해 다른 서버에서도 스토리지에 접근 가능해서 공유 가능. 장소에 구애받지 않고 저장장치에 쉽게 접근 가능
    • DAS에 비해 확장성 및 유연성이 우수
    • 접속 증가 시 성능 저하 가능

SAN (Storage Area Network)

  • DAS의 빠른 처리와 NAS의 파일 공유 장점을 혼합한 방식. 서버와 저장장치를 연결하는 전용 네트워크를 별도로 구성하는 방식.
    • 파이버 채널(FC) 스위치를 이용하여 네트워크를 구성
      • 파이버 채널(Fiber Channel, FC): 컴퓨터 장치 간 데이터의 전송 속도를 기가바이트로 높이기 위한 네트워크 기술
    • 파이버 채널 스위치는 서버나 저장장치를 광케이블로 연결하므로 처리 속도가 빠름
    • 저장장치 및 파일 공유 가능
    • 확장성, 유연성, 가용성이 뛰어남.
    • 높은 트랜잭션 처리에 효과적이나 기존 시스템의 경우 장비의 업그레이드가 필요하고, 초기 설치 시에는 별도의 네트워크를 구축해야 하므로 비용이 많이 듬.

099 논리 데이터 모델의 물리 데이터 모델 변환

엔티티(Entity)를 테이블로 전환

  • 논리 데이터 모델에서 정의된 엔티티를 물리 데이터 모델의 테이블로 변환하는 것
  • 엔티티를 테이블로 변환한 후 테이블 목록 정의서를 작성
    • 테이블 목록 정의서: 전체 테이블을 목록으로 요약 관리하는 문서로, 테이블 목록이라고도 함.
  • 변환 규칙
    엔티티 -> 테이블
    속성 -> 컬럼
    주 식별자 -> 기본키
    외부 식별자 -> 외래키
    관계 -> 관계
  • 변환 시 고려사항
    • 일반적으로 테이블과 엔티티 명칭은 동일하게 하는 것을 권고
    • 엔티티는 주로 한글명을 사용하지만 테이블은 소스 코드의 가독성을 위해 영문명을 사용
    • 메타 데이터 관리 시스템에 표준화된 용어가 있을 때는 메타에 등록된 단어를 사용하여 명명
      • 메타 데이터 관리 시스템: 메타 데이터를 수집하거나 여러 사람이 메타 데이터를 편리하게 사용할 수 있도록 제공하는 시스템

슈퍼타입/서브타입을 테이블로 변환

  • 슈퍼타입/서브타입은 논리 데이터 모델에서 이용되는 형태이므로 물리 데이터 모델을 설계할 때는 슈퍼타입/서브타입을 테이블로 변환해야 함.
  • 방법에는 아래와 같은 것들이 있음.
  • 슈퍼타입 기준 테이블 변환: 서브타입을 슈퍼타입에 통합하여 하나의 테이블로 만드는 것
    • 서브타입에 속성이나 관계가 적을 경우 적용. 하나로 통합된 테이블에는 서브타입의 모든 속성이 포함돼야 함.
    • 장점
      • 데이터의 액세스가 상대적으로 용이
      • 뷰를 이용하여 각각의 서브타입만을 액세스하거나 수정 가능
      • 서브타입 구분이 없는 임의 집합에 대한 처리가 용이
      • 조인하지 않아도 되므로 수행 속도가 빨라짐
      • SLQ 문장 구성이 단순해짐
    • 단점
      • 테이블의 컬럼이 증가하므로 디스크 저장 공간이 증가함.
      • 처리마다 서브타입에 대한 구분(TYPE)이 필요한 경우가 많이 발생함.
      • 인덱스 크기의 증가로 인덱스의 효율이 떨어짐
  • 서브타입 기준 테이블 변환: 슈퍼타입 속성들을 각각의 서브타입에 추가하여 서브타입들을 개별적인 테이블로 만드는 것
    • 서브타입에 속성이나 관계가 많은 경우 적용
    • 장점
      • 각 서브타입 속성들의 선택 사양이 명확한 경우에 유리
      • 처리할 때마다 서브타입 유형을 구분할 필요가 없음.
      • 여러 개의 테이블로 통합하므로 테이블당 크기가 감소하여 전체 테이블 스캔시 유리
    • 단점
      • 수행 속도가 감소할 수 있음.
      • 복잡한 처리를 하는 SQL의 통합이 어려움.
      • 부분 범위에 대한 처리가 곤란
      • 여러 테이블을 통합한 뷰는 조회만 가능
      • UID(식별자)의 유지 관리가 어려움.
  • 개별타입 기준 테이블 변환: 슈퍼타입과 서브타입들을 각각의 개별적인 테이블로 변환하는 것
    • 슈퍼타입과 서브타입 테이블들 사이에는 각각 1:1 관계가 형성됨.
    • 적용하는 경우
      • 전체 데이터에 대한 처리가 빈번한 경우
      • 서브타입의 처리가 대부분 독립적으로 발생하는 경우
      • 통합하는 테이블의 컬럼 수가 많은 경우
      • 서브타입의 컬럼 수가 많은 경우
      • 트랜잭션이 주로 슈퍼타입에서 발생하는 경우
      • 슈퍼타입의 처리 범위가 넓고 빈번하게 발생하여 단일 테이블 클러스터링이 필요한 경우
    • 장점
      • 저장 공간이 상대적으로 적음.
      • 슈퍼타입 또는 서브타입 각각의 테이블에 속한 정보만 조회하는 경우 문장 작성이 용이
    • 단점
      • 슈퍼타입 또는 서브타입의 정보를 같이 처리하면 항상 조인이 발생하여 성능이 저하됨.

속성을 컬럼으로 변환

  • 논리 데이터 모델에서 정의한 속성을 물리 데이터 모델의 컬럼으로 변환
  • 일반 속성 변환
    • 속성과 컬럼의 명칭을 반드시 일치시킬 필요는 없지만, 가능한 한 표준화된 약어를 사용하여 일치시키는 게 좋음.
    • SQL의 예약어 사용 금지
    • SQL의 가독성을 위해 가능한 한 짧게 지정
    • 복합 단어를 컬럼명으로 사용할 때는 미리 정의된 표준을 따름.
    • 테이블의 컬럼을 정의한 후에는 한 로우(Row)에 해당하는 샘플 데이터를 작성하여 컬럼의 정합성을 검증
  • Primary UID를 기본키로 변환
    • 논리 데이터 모델에서의 Primary UID는 물리 데이터 모델의 기본키로 만듬.
  • Primary UID(관계의 UID Bar)를 기본키로 변환
    • 다른 엔티티와의 관계로 인해 생성된 Primary UID는 물리 데이터 모델의 기본키로 만듬.
  • Secondary(Alternate) UID를 유니크키로 변환
    • 논리 모델링에서 정의된 Secondary UID 및 Alternate Key는 물리 모델에서 유니크키로 만듬.

관계를 외래키로 변환

  • 논리 데이터 모델에서 정의된 관계는 기본키와 이를 참조하는 외래키로 변환
  • 1:1 관계
  • 1:M 관계
  • N:M 관계
    • 릴레이션 A와 B의 기본키를 모두 포함한 별도의 릴레이션으로 표현.
    • 이 때 생성된 별도의 릴레이션을 교차 릴레이션(Intersection Relation) 또는 교차 엔티티(Intersection Entity)라고 함.
  • 1:M 순환 관계
    • 개체 A에 개체 A의 기본키를 참조하는 외래키 컬럼을 추가하여 표현. 데이터의 계층 구조를 표현하기 위해 주로 사용돔.

관리 목적의 테이블/컬럼 추가

  • 논리 데이터 모델에는 존재하지 않는 테이블이나 컬럼을 데이터베이스의 관리 혹은 데이터베이스를 이용하는 프로그래밍의 수행 속도를 향상시키기 위해 물리 데이터 모델에 추가할 수 있음.
  • ex) 시스템 등록 일자, 시스템 번호 등

데이터 타입 선택

  • 논리 데이터 모델에서 정의된 논리적인 데이터 타입을 물리적인 DBMS의 물리적 특성과 성능을 고려하여 최적의 데이터 타입과 데이터의 최대 길이를 선택

100 물리 데이터 모델 품질 검토

  • 물리 데이터 모델 품질 검토: 물리 데이터 모델을 설계하고 데이터베이스 객체를 생성한 후 개발 단계로 넘어가기 전에 모델러와 이해관계자들이 모여 수행함.
    • 물리 데이터 모델은 시스템 성능에 직접적인 영향을 미치므로 향후 발생할 문제에 대해 면밀히 검토해야 함.
    • 목적은 테이터베이스의 성능 향상과 오류 예방
    • 모든 이해관계자가 동의하는 검토 기준이 필요

물리 데이터 모델 품질 기준

  • 정확성
  • 안전성
  • 준거성
  • 최신성
  • 일관성
  • 활용성

물리 데이터 모델 품질 검토 항목

물리 데이터 모델의 품질 검토 순서

  1. 데이터 품질 정책 및 기준을 확인
  2. 물리 데이터 품질의 특성에 따라 품질 기준을 작성
  3. 데이터 품질 기준에 따라 체크리스트를 작성
  4. 논리 데이터 모델과 물리 데이터 모델을 비교
  5. 각 모델링 단계의 모델러와 이해관계자가 품질 검토를 수행
  6. 모델러와 이해관계자가 작성한 체크리스트 내용을 종합하여 물리 데이터베이스 모델의 품질 검토 보고서를 작성

3장. SQL 응용

101 SQL의 개념

102 DDL (Data Define Language, 데이터 정의어)

  • SCHEMA, DOMAIN, TABLE, VIEW, INDEX를 정의하거나 변경 또는 삭제하는 언어

CREATE SCHEMA

CREATE SCHEMA 스키마명 AUTHORIZATION 사용자_id;

CREATE DOMAIN

CREATE DOMAIN 도메인명 [AD] 데이터_타입
      [DEFAULT 기본값]
      [CONSTRAINT 제약조건명 CHECK (범위값)];

CREATE TABLE

  • 일반적으로 테이블 생성 명령어에 스키마를 생성하지 않으면 현재 명령어가 실행되는 환경에 있는 스키마에 명령이 적용됨.
  • CREATE DOMAIN으로 사용자가 정의한 데이터 타입을 사용할 수 있음.

CREATE VIEW

CREATE VIEW 뷰명[(속성명[, 속성명, ...])]
AS SELECT문;

CREATE INDEX

CREATE [UNIQUE] INDEX 인덱스명
ON 테이블명(속성명 [ASC|DESC] [, 속성명 [ASC|DESC]])
[CLUSTER];
  • CLUSTER: 사용하면 인덱스가 클러스터드 인덱스로 설정됨.
    • 동일 인덱스 값을 갖는 튜플들을 그룹으로 묶을 때 사용

ALTER TABLE

DROP

DROP SCHEMA 스키마명 [CASCADE | RESTRICTED];
DROP DOMAIN 도메인명 [CASCADE | RESTRICTED];
DROP TABLE 테이블명 [CASCADE | RESTRICTED];
DROP VIEW 뷰명 [CASCADE | RESTRICTED];
DROP INDEX 인덱스명 [CASCADE | RESTRICTED];
DROP CONSTRAINT 제약조건명;
  • CASCADE: 제거할 요소를 참조하는 다른 모든 개체를 함께 제거함. 즉 주 테이블의 데이터 제거 시 각 외래키와 관계를 맺고 있는 모든 데이터를 제거하는 참조 무결성 제약 조건을 설정하기 위해 사용됨.
  • RESTRICTED: 다른 개체가 제거할 요소를 참조중일 때는 제거를 취소함.

103 DCL (Data Control Language, 데이터 제어어)

  • 데이터의 보안, 무결성, 회복, 병행 수행 제어 등을 정의하는 언어

  • GRANT / REVOKE

    • 사용자등급 지정 및 해제
      • GRANT 사용자등급 TO 사용자_ID_리스트 [IDENTIFIED BY 암호];
      • REVOKE 사용자등급 FROM 사용자_ID_리스트;
      • 사용자 등급: DBA, RESOURCE(데이터베이스 및 테이블 생성 가능자), CONNECT(단순 사용자)
    • 테이블 및 속성에 대한 권한 부여 및 취소
      • GRANT 권한_리스트 ON 개체 TO 사용자 [WITH GRANT OPTION];
      • REVOKE [GRANT OPTION FOR] 권한_리스트 ON 개체 FROM 사용자 [CASCADE/RESTRICT];
      • 권한 종류: ALL, SELECT, INSERT, DELETE, UPDATE, ALTER 등
      • WITH GRANT OPTION : 부여받은 권한을 다른 사용자에게 다시 부여할 수 있는 권한을 부여함.
      • GRANT OPTION FOR : 다른 사용자에게 권한을 부여할 수 있는 권한을 취소함
      • CASCADE : 권한 취소 시 권한을 부여받았던 사용자가 다른 사용자에게 부여한 권한도 연쇄적으로 취소함.

  • COMMIT

  • ROLLBACK

  • SAVEPOINT

// sandman - REVOKE 명령어가 묘하게 다른데??

104 DML (Data Manipulation Language, 데이터 조작어)

  • INSERT
INSERT INTO 테이블명([속성명1, 속성명2, ...])
VALUES (데이터1, 데이터2, ...);
  • DELETE
DELETE FROM 테이블명 [WHERE 조건];
  • UPDATE
UPDATE 테이블명 SET 속성명 = 데이터[, 속성명 = 데이터, ...]
[WHERE 조건];
  • SELECT

105 DML-SELECT-1

106 DML-SELECT-2

  • 그룹함수

    • COUNT(속성명)
    • SUM(속성명)
    • AVG(속성명)
    • MAX(속성명)
    • MIN(속성명)
    • STDDEV(속성명)
    • VARIANCE(속성명)
    • ROLLUP(속성명, 속성명, ..)
    • CUBE(속성명, 속성명, ..)

  • WINDOW 함수

    • ROW_NUMBER()
    • RANK()
    • DENSE_RANK()

  • 집합 연산자의 종류(통합 질의의 종류)

    • UNION
    • UNION ALL
    • INTERSECT
    • EXCEPT

107 DML-JOIN

INNER JOIN

  • EQUI JOIN
    • WHERE절을 이용한 표기
    • NATURAL JOIN절을 이용한 표기
    • JOIN ~ USING절을 이용한 표기
  • NON-EQUI JOIN

OUTER JOIN

  • LEFT OUTER JOIN
  • RIGHT OUTER JOIN
  • FULL OUTER JOIN

SELF JOIN

  • 같은 테이블에서 2개의 속성을 연결하여 EQUI JOIN을 하는 JOIN 방법

CROSS JOIN (교차 조인)

4장. SQL 활용

108 프로시저(Procedure)

  • 절차형 SQL을 활용하여 특정 기능을 수행하는 일종의 트랜잭션 언어. 호출을 통해 실행되어 미리 저장해 놓은 SQL 작업을 수행
  • 프로시저를 만들어 데이터베이스에 저장하면 여러 프로그램에서 호출하여 사용할 수 있음.
  • 데이터베이스에 저장되어 수행되기 때문에 스토어드(Stored) 프로시저라고도 불림.
  • 시스템의 일일 마감 작업, 일괄(Batch) 작업 등에 주로 사용됨.

프로시저 생성

  • CREATE PROCEDURE 명령어를 사용

프로시저 실행

  • EXECUTE 명령어(EXEC 명령어) 또는 CALL 명령어를 사용

프로시저 제거

  • DROP PROCEDURE 명령어

109 트리거(Trigger)

  • 데이터베이스 시스템에서 데이터의 삽입, 갱신, 삭제 등의 이벤트가 발생할 때마다 관련 작업이 자동으로 수행되는 절차형 sql
  • 데이터베이스에 저장되며, 데이터 변경 및 무결성 유지, 로그 메시지 출력 등의 목적으로 사용됨.
  • 트리거 구문에는 DCL(데이터 제어어)을 사용할 수 없으며, DCL이 포함된 프로시저나 함수를 호출하는 경우에도 오류가 발생함.

110 사용자 정의 함수

  • 프로시저와 유사하게 SQL을 사용하여 일련의 작업을 연속적으로 처리하며, 종료시 처리 결과를 단일값으로 반환하는 절차형 SQL
  • 데이터베이스에 저장되어 SELECT, INSERT, DELETE, UPDATE 등 DML문의 호출에 의해 실행됨.
  • 예약어 RETURN을 통해 값을 반환하기 때문에 출력 파라미터가 없음.
  • INSERT, DELETE, UPDATE를 통한 테이블 조작은 할 수 없고 SELECT를 통한 조회만 할 수 있음.
  • 사용자 정의 함수는 프로시저를 호출하여 사용할 수 없음.
  • SUM(), AVG() 등의 내장 함수처럼 DML문에서 반환값을 활용하기 위한 용도로 사용됨.

사용자 정의 함수의 구성

사용자 정의 함수 생성

  • CREATE FUNCTION 명령어

사용자 정의 함수 실행

SELECT 사용자 정의 함수명 FROM 테이블명;
INSERT INTO 테이블명(속성명) VALUES (사용자 정의 함수명);
DELETE FROM 테이블명 WHERE 속성명 = 사용자 정의 함수명;
UPDATE 테이블명 SET 속성명 = 사용자 정의 함수명;

사용자 정의 함수 제거

DROP FUNCTION 사용자 정의 함수명;

111 DBMS 접속 기술

  • DBMS 접속: 사용자가 데이터를 사용하기 위해 응용 시스템을 이용하여 DBMS에 접근하는 것을 의미

DBMS 접속 기술

  • DBMS에 접근하기 위해 사용하는 API 또는 API의 사용을 편리하게 도와주는 프레임워크 등을 의미
  • JDBC(Java Database Connectivity)
    • 접속하려는 DBMS에 대한 드라이버가 필요함.
  • ODBC(Open Database Connectivity)
    • 데이터베이스에 접근하기 위한 표준 개방형 API로, 개발 언어에 관계없이 사용할 수 있음.
    • 마이크로소프트에서 출시
    • 프로그램 내 ODBC 문장을 사용하여 MS-Access, DBase, DB2, Excel, Text 등 다양한 데이터베이스에 접근할 수 있음.
    • ODBC도 접속하려는 DBMS에 맞는 드라이버가 필요하지만, 접속하려는 DBMS의 인터페이스를 알지 못하더라도 ODBC 문장을 사용하여 SQL을 작성하면 ODBC에 포함된 드라이버 관리자가 해당 DBMS의 인터페이스에 맞게 연결해 주므로 DBMS의 종류를 몰라도 됨.
  • MyBatis
    • JDBC 코드를 단순화하여 사용할 수 있는 SQL Mapping 기반 오픈소스 접속 프레임워크

동적 SQL(Dynamic SQL)

  • 쉽게 말해 사용자가 입력란에 SQL을 직접 입력하는 것 (전부 or 일부)
  • 응용 프로그램 수행 시 SQL이 변형될 수 있으므로 프리컴파일할 때 구문 분석, 접근 권한 확인 등을 할 수 없음.
  • 실행 속도가 느리지만, 유연함.

112 SQL 테스트

  • SQL이 작성 의도에 맞게 원하는 기능을 수행하는지 검증하는 과정

단문 SQL 테스트

  • DDL, DML, DCL이 포함되어 있는 SQL과 TCL을 테스트하는 것. 직접 실행하여 결과물을 확인
  • DESCRIBE 명령어를 이용하면 DDL로 작성된 테이블이나 뷰의 속성, 자료형, 옵션들을 바로 확인할 수 있음.
    • DESC 개체명
  • DCL로 설정된 사용자 권한 확인
    • Oracle: SELECT * FROM DBA_ROLE_PRIVES WHERE GRANTEE = 사용자;
    • MySQL: SHOW GRANTS FOR 사용자@호스트;

절차형 SQL 테스트

  • 프로시저, 사용자 정의 함수, 트리거 등의 절차형 SQL은 디버깅을 통해 기능의 적합성 여부를 검증하고, 실행을 통해 결과를 확인하는 테스트를 수행

  • 많은 코드로 구성된 절차형 SQL의 특성상 오류 및 경고 메시지가 상세히 출력되지 않으므로 SHOW 명령어를 통해 오류 내용을 확인하고 문제를 수정함.

    • SHOW ERRORS;

  • 데이터베이스에 변화를 줄 수 있는 SQL문은 주석으로 처리하고, 출력문을 이용하여 화면에 출력하여 확인

  • 디버깅이 완료되면 출력문을 삭제하고, 주석 기호를 삭제한 후 절차형 SQL을 실행하여 결과를 검토

  • Oracle 출력 형식

DBMS_OUTPUT.ENABLE;
DMMS_OUTPUT.PUT_LINE(데이터);
  • MySQL 출력 형식
SELECT 데이터;

113 ORM (Object-Relational Mapping)

  • 객체지향 프로그래밍의 객체와 관계형 데이터베이스의 데이터를 연결(Mapping)하는 기술

ORM 프레임워크

  • JAVA: JPA, Hibernate, EclipseLink, DataNucleus, Ebean 등
  • C++: ODB, QxOrm 등
  • Python: Django, SQLAlchemy, Storm 등
  • iOS: DatabaseObjects, Core Data 등
  • .Net: NHibernate, DatabaseObjects, Dapper 등
  • PHP: Doctrine, Propel, RedBean 등

ORM의 한계

  • 의도대로 SQL이 작성되었는지 확인할 필요가 있음.
  • 객체지향적인 사용을 고려하고 설계된 데이터베이스가 아닌 경우 프로젝트가 크고 복잡해질수록 ORM 기술을 적용하기 어려워짐.
  • 기존의 기업들은 ORM을 고려하지 않은 데이터베이스를 사용하고 있기 때문에 ORM에 적합하게 변환하려면 많은 시간과 노력이 필요함.

114 쿼리 성능 최적화

  • 데이터 입·출력 애플리케이션의 성능 향상을 위해 SQL 코드를 최적화하는 것
  • 쿼리 성능을 최적화하기 전에 성능 측정 도구인 APM(Application Performance Management/Monitoring)을 사용하여 최적화할 쿼리를 선정해야 함.
  • 최적화 할 쿼리에 대해 옵티마이저가 수립한 실행 계획을 검토하고 SQL 코드와 인덱스를 재구성함.
옵티마이저 (Optimizer)
  • 작성된 SQL이 가장 효율적으로 수행되도록 최적의 경로를 찾아 주는 모듈로, RBO(Rule Based Optimizer; 규칙 기반 옵티마이저)와 CBO(Cost Based Optimizer; 비용 기반 옵티마이저) 두 종류가 있음. 실무에서는 주로 CBO가 사용됨.
  • CBO 옵티마이저는 입·출력 속도, CPU 사용량, 쿼리의 블록 개수, 쿼리에 사용되는 개체의 속성, 튜플의 개수 등을 종합하여 각 DBMS마다 고유의 알고리즘에 따라 산출되는 '비용'을 계산함. 개체나 DBMS의 버전이 변경되어 알고리즘에 변화가 생기면 실행 계획을 다시 확인해야 함.

실행 계획 (Execution Plan)

  • DBMS의 옵티마이저가 수립한 SQL 코드의 실행 절차와 방법을 의미

  • EXPLAIN 명령어를 통해 확인 가능.

  • 실행 계획에는 요구사항들을 처리하기 위한 연산 순서가 적혀있으며, 연산에는 조인, 테이블 검색, 필터, 정렬 등이 있음.

  • A테이블과 B테이블을 조인했을 때, A테이블의 튜플만큼 B테이블의 튜플을 반복하여 조회해 나가는 방식을 NL(Nested Loop)이라고 하고, 두 테이블 모두 인덱스가 없는 경우 조회 성능 개선을 위해 한 테이블의 일정 양의 튜플을 버퍼 메모리에 저장한 후 NL방식으로 조회하는 것을 BNL(Block Nested Loop)이라고 함.

  • filesort: filesort는 분류(sort) 작업을 수행하려는 테이블에 인덱스가 없는 경우 메모리 공간 절약을 위해 디스크에 파일 형식으로 테이블을 저장한 후 분류하는 방식을 의미

쿼리 성능 최적화

  • 실행 계획에 표시된 연산 순서, 조인 방식, 테이블 조회 방법 등을 참고하여 SQL문이 더 빠르고 효율적으로 작동하도록 SQL 코드와 인덱스를 재구성하는 것을 의미

  • SQL 코드 재구성

    • WHERE 절을 추가하여 일부 레코드만 조회하게 함으로써 조회에 들어가는 비용을 줄임.
    • WHERE 절에 연산자가 포함되면 INDEX를 활용하지 못하므로 가능한 한 연산자 사용을 자제
    • 서브 쿼리에 특정 데이터가 존재하는지 확인할 때는 IN 보다 EXISTS를 활용
      • EXISTS는 서브 쿼리의 모든 데이터를 확인하는 IN과 달리 데이터의 존재여부가 확인되면 검색이 종료되므로 IN보다 처리 속도가 빠름.
    • 옵티마이저의 실행 계획이 잘못되었다고 판단되는 경우 힌트를 활용하여 실행 계획의 액세스 경로 및 조인 순서를 변경

  • 인덱스 재구성

    • SQL 코드에서 조회되는 속성과 조건들을 고려하여 인덱스를 구성
    • 실행 계획을 참고하여 인덱스를 추가하거나 기존 인덱스의 열 순서를 변경
    • 인덱스의 추가 및 변경은 해당 테이블을 참조하는 다른 SQL문에도 영향을 줄 수 있으므로 신중히 결정
    • 단일 인덱스로 쓰기나 수정 없이 읽기로만 사용되는 테이블의 경우 IOT(Index-Organized Table)로 구성하는 것을 고려
      • IOT(Index-Organized Table): IOT는 인덱스 안에 테이블 데이터를 직접 삽입하여 저장함으로써 주소를 얻는 과정이 생략되어 더욱 빠르게 조회가 가능함.
    • 불필요한 인덱스를 제거

5장. 데이터 전환

115 데이터 전환

  • 데이터 전환: 운영 중인 기존 정보 시스템에 축적되어 있는 데이터를 추출(Extraction)하여 새로 개발할 정보 시스템에서 운영 가능하도록 변환(Transformation)한 후, 적재(Loading)하는 일련의 과정
  • 데이터 전환을 ETL(Extraction, Transformation, Loading), 즉 추출, 변환, 적재 과정이라고 함.
  • 데이터 이행(Data Migration) 또는 데이터 이관이라고도 함.

데이터 전환 계획서

  • 데이터 전환이 필요한 대상을 분석하여 데이터 전환 작업에 필요한 모든 계획을 기록하는 문서
  • 주요 항목
    • 데이터 전환 개요
    • 데이터 전환 대상 및 범위
    • 데이터 전환 환경 구성
    • 데이터 전환 조직 및 역할
    • 데이터 전환 일정
    • 데이터 전환 방안
    • 데이터 정비 방안
    • 비상 계획
    • 데이터 복구 대책

116 데이터 전환 계획서 작성

데이터 전환 개요

  • 데이터 전환 개요 항목에는 데이터 전환의 목표, 성공적인 데이터 전환을 위한 주요요인, 데이터 전환 작업을 위한 전제 조건 및 제약 사항을 기술
    • 데이터 전환 목표는 간단하고 명료하게 기술

데이터 전환 대상 및 범위

  • 단위 업무별로 데이터 전환 대상 정보, 해당 업무에 사용되는 Table의 수, 데이터 크기를 기술

데이터 전환 환경 구성

  • 원천 시스템과 목적 시스템의 구성도, 전환 단계별 DISK 사용량을 기술

데이터 전환 조직 및 역할 작성

  • 데이터 전환을 수행하고 결과를 검증할 작업자와 작업자별 역할을 최대한 상세히 기술

데이터 전환 일정 작성

  • 데이터 전환 및 검증 작업별로 상세하게 일정을 수립하여 작성

117 데이터 전환 방안

  • 데이터 전환 방안 항목에는 데이터 전환 규칙, 데이터 전환 절차, 데이터 전환 방법, 데이터 전환 설계, 전환 프로그램 개발 및 테스트 계획, 데이터 전환 계획, 데이터 검증 방안이 있음.

데이터 전환 규칙

  • 데이터 전환 과정에서 공통적으로 적용해야 할 규칙들을 기술

데이터 전환 절차

  • 전환 준비, 전환 설계/개발, 전환 테스트, 실데이터 전환, 최종 전환 및 검증의 데이터 전환 절차를 체계적이고 상세하게 기술
  • 데이터 전환 절차 수립 시 작업의 이해를 위해 데이터 흐름도를 작성

데이터 전환 방법

  • 단위 업무별로 데이터 전환 방법을 기술하되, 데이터 전환 시 업무별로 요구되는 전제 조건도 함께 기술

데이터 전환 설계

  • 업무별로 전환 대상과 전환 제외 대상을 기술하고 원천 시스템 테이블과 목적 시스템 테이블의 매핑 정의서를 작성

전환 프로그램 개발 및 테스트 계획

  • 전환 프로그램 개발 계획과 전환 프로그램 테스트 계획을 수립한 후 관련 내용을 기술

데이터 전환 계획

  • 데이터 전환 시간을 단축하기 위해 선 전환, 본 전환, 후 전환으로 분리하여 계획을 수립한 후 관련 내용을 기술

데이터 검증 방안

  • 데이터 전환 이후 전환 데이터의 정합성을 검증하고 전환 과정에서 발생할 수 있는 문제에 대응할 수 있도록 단계별 데이터 전환 검증 방안을 수립한 후 관련 내용을 기술

118 데이터 검증

  • 원천 시스템의 데이터를 목적 시스템의 데이터로 전환하는 과정이 정상적으로 수행되었는지 여부를 확인하는 과정

검증 방법에 따른 분류

  • 로그 검증
  • 기본 항목 검증
  • 응용 프로그램 검증
  • 응용 데이터 검증
  • 값 검증

검증 단계에 따른 분류

  • 추출 | 로그 검증
  • 전환 | 로그 검증
  • DB 적재 | 로그 검증
  • DB 적재 후 | 기본 항목 검증
  • 전환 완료 후 | 응용 프로그램 검증, 응용 데이터 검증

119 오류 데이터 측정 및 정제

  • 오류 데이터 측정 및 정제는 고품질의 데이터를 운영 및 관리하기 위해 수행함.
  • 데이터 품질 분석 -> 오류 데이터 측정 -> 오류 데이터 정제 순으로 진행

데이터 품질 분석

  • 데이터 품질 분석: 오류 데이터를 찾기 위해 원천 및 목적 시스템 데이터의 정합성 여부를 확인하는 작업

오류 데이터 측정

  • 오류 데이터 측정: 데이터 품질 분석을 기반으로 정상 데이터와 오류 데이터의 수를 측정하여 오류 관리 목록을 작성하는 것

오류 데이터 정제

  • 오류 데이터 정제: 오류 관리 목록의 각 항목을 분석하여 원천 데이터를 정제하거나 전환 프로그램을 수정하는 것
  • 오류 데이터 분석
    • 오류 관리 목록의 오류 데이터를 분석하여 오류 상태, 심각도, 해결 방안을 확인 및 기재
    • 상태
      • Open
      • Assigned
      • Fixed
      • Closed
      • Deferred
      • Classified
    • 심각도: 상 / 중 / 하
  • 오류 데이터 정제
    • 확인된 오류 데이터 분석을 통해 원천 데이터를 정제하거나 전환 프로그램을 수정

120 데이터 정제요청서 및 정제보고서

  • 데이터 정제요청서: 원천 데이터의 정제와 전환 프로그램의 수정을 위해 요청사항 및 조치사항 등 데이터 정제와 관련된 전반적인 내용을 문서로 작성한 것
  • 오류 관리 목록을 기반으로 데이터 정제 요건 목록을 작성하고 이 목록의 항목별로 데이터 정제요청서를 작성

데이터 정제 요건 목록 작성

  • 데이터 정제 요건 목록은 오류 관리 목록의 각 항목에 대해 정제 유형을 분류하고 현재의 정제 상태를 정의한 것
    • 정제 유형
      • 완전성
      • 유효성
      • 일치성
      • 유일성
      • 기타
    • 정제 방법
      • 원천: 원천 데이터의 정제가 필요한 경우
      • 전환: 전환 프로그램의 수정이 필요한 경우
      • 모두: 원천 데이터의 정제와 전환 프로그램의 수정이 모두 필요한 경우
    • 상태: 요건 제기, 1~3차 검토/조치/확인 등 진행 상태를 기재

데이터 정제요청서 작성

  • 데이터 정제요청서에는 데이터 전환 시 발생한 오류의 수정을 위해 정제 요청의 전반적인 내용들을 작성하며, 데이터 정제 검토 시 신속한 의사 결정을 위해 오류사항의 해결 방안도 포함시킴.

데이터 정제보고서의 개요 및 작성

  • 데이터 정제보고서: 데이터 정제요청서를 통해 정제된 원천 데이터가 정상적으로 정제되었는지 확인한 결과를 문서로 작성한 것
profile
Starman
이전 포스트

정처기2: 소프트웨어 개발

다음 포스트

정처기3: 데이터베이스 구축

0개의 댓글