[정보처리기사 필기] 3과목 데이터베이스 구축

◆3과목 데이터베이스 구축

 

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

 

•데이터베이스 설계

 : 사용자의 요구를 분석하여 그것들을 컴퓨터에 저장할 수 있는 데이터베이스의 구조에 맞게 변형한 후 특정 DBMS로

   데이터베이스를 구현하여 일반 사용자들이 사용하게 하는 것이다

 

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

  - 무결성 : 삽입, 삭제, 갱신 등의 연산 후에도 데이터베이스에 저장된 데이터가 정해진 제약 조건을 항상 만족해야 한다

  - 일관성 : 데이트베이스에 저장된 데이터들 사이나, 특정 질의에 대한 응답이 처음부터 끝까지 변함없이 일정해야

    한다

  - 회복 : 시스템에 장애가 발생했을 때 장애 발생 직전의 상태로 복구할 수 있어야 한다

  - 보안 : 불법적인 데이터의 노출 또는 변경이나 손실로부터 보호할 수 있어야 한다

  - 효율성 : 응답시간의 단축, 시스템의 생산성, 저장 공간의 최적화 등이 가능해야 한다

  - 데이터베이스 확장 : 데이터베이스 운영에 영향을 주지 않으면서 지속적으로 데이터를 추가할 수 있어야 한다

 

2. 데이터베이스 설계 순서

 

 3. 요구 조건 분석

  : 데이터베이스를 사용할 사람들로부터 필요한 용도를 파악하는 것이다

  - 데이터베이스 사용자에 따른 수행 업무와 필요한 데이터의 종류, 용도, 처리 형태, 흐름, 제약 조건 등을 수집한다

  - 수집된 정보를 바탕으로 요구 조건 명세를 작성한다

 

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

  : 정보의 구조를 얻기 위해서 현실 세계의 무한성과 계속성을 이해하고, 다른 사람들과 통신하기 위하여 현실 세계에

    대한 인식을 추상적 개념으로 표현하는 과정이다

  - 개념 스키마 모델링과 트랜잭션 모델링을 병행 수행한다

  - 요구 분석 단계에서 나온 결과인 요구 조건 명세를 DBMS에 독립적인 E-R 다이어그램으로 작성한다

  - DBMS에 독립적인 개념 스키마를 설계한다

 

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

  : 현실 세계에서 발생하는 자료를 컴퓨터가 이해하고 처리할 수 있는 물리적 저장장치에 저장할 수 있도록 변환하기

    위해 특정 DBMS가 지원하는 논리적 자료 구조로 변환(mapping)시키는 과정이다

  - 개념 세계의 데이터를 필드로 기술된 데이터 타입과 이 데이터 타입들 간의 관계로 표현되는 논리적 구조의 데이터로

    모델화한다

  - 개념적 설계가 개념 스키마를 설계하는 단계라면 논리적 설계에서는 개념 스키마를 평가 및 정제하고 DBMS에 따라

    서로 다른 논리적 스키마를 설계하는 단계이다

  - 트랜잭션의 인터페이스를 설계한다

  - 관계형 데이터베이스라면 테이블을 설계하는 단계이다

 

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

  : 논리적 설계 단계에서 논리적 구조로 표현된 데이터를 디스크 등의 물리적 저장장치에 저장할 수 있는 물리적 구조의

    데이터로 변환하는 과정이다

  - 물리적 설계의 목적은 효율적인 방법으로 데이터를 저장하는 것이다

  - 다양한 데이터베이스 응용에 대해 처리 성능을 얻기 위해 데이터베이스 파일의 저장 구조 및 액세스 경로를 결정한다

  - 저장 레코드의 형식(양식 설계), 순서, 접근 경로, 조회가 집중되는 레코드(레코드 집중의 분석 및 설계)와 같은

    정보를 사용하여 데이터가 컴퓨터에 저장되는 방법을 묘사한다

  - 물리적 설계 시 고려할 사항 : 트랜잭션 처리량, 응답 시간, 디스크 용량 등

 

 7. 데이터베이스 구현

  : 논리적 설계 단계와 물리적 설계 단계에서 도출된 데이터베이스 스키마를 파일로 생성하는 과정이다

  - 사용하려는 특정 DBMS의 DDL(데이터 정의어)을 이용하여 데이터베이스 스키마를 기술한 후 컴파일하여 빈

    데이터베이스 파일을 생성한다

  - 생성된 빈 데이터베이스 파일에 데이터를 입력한다

  - 응용 프로그램을 위한 트랜잭션을 작성한다

  - 데이터베이스 접근을 위한 응용 프로그램을 작성한다

 

•데이터 모델의 개념

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

 - 데이터, 데이터의 관계, 데이터의 의미 및 일관성, 제약 조건 등을 기술하기 위한 개념적 도구들의 모임이다

 - 현실 세계를 데이터베이스에 표현하는 중간 과정, 즉 데이터베이스 설계 과정에서 데이터의 구조(Schema)를

    논리적으로 표현하기 위해 사용되는 지능적 도구이다

 - 데이터 모델 구성 요소 : 개체, 속성, 관계

 - 데이터 모델 종류 : 개념적 데이터 모델, 논리적 데이터 모델, 물리적 데이터 모델

 - 데이터 모델에 표시할 요소 : 구조, 연산, 제약 조건

 

 1. 데이터 모델의 구성 요소

  - 개체(Entity) : 데이터베이스에 표현하려는 것으로, 사람이 생각하는 개념이나 정보 단위 같은 현실 세계의 대상체이다

  - 속성(Attribute) : 데이터의 가장 작은 논리적 단위로서 파일 구조상의 데이터 항목 또는 데이터 필드에 해당한다

  - 관계(Relationship) : 개체 간의 관계 또는 속성 간의 논리적인 연결을 의미한다

 

 2. 개념적 데이터 모델

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

  - 속성들로 기술된 개체 타입과 이 개체 타입들 간의 관계를 이용하여 현실 세계를 표현한다

  - 현실 세계에 존재하는 개체를 인간이 이해할 수 있는 정보 구조로 표현하기 때문에 정보 모델이라고도 한다

  - 대표적인 개념적 모델로는 E-R 모델이 있다

 

 3. 논리적 데이터 모델

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

    변환하는 과정

  - 필드로 기술된 데이터 타입과 이 데이터 타입들 간의 관계를 이용하여 현실 세계를 표현한다

  - 단순한 데이터 모델이라고 하면 논리적 데이터 모델을 의미한다

  - 특정 DBMS는 특정 논리적 데이터 모델 하나만 선정하여 사용한다

  - 데이터 간의 관계를 어떻게 표현하느냐에 따라 관계 모델, 계층 모델, 네트워크 모델로 구분한다

 

 4. 논리적 데이터 모델의 품질 검증

  : 완성된 논리 데이터 모델이 기업에 적합한지를 확인하기 위해 품질을 검증하는 것이다

  - 논리 데이터 모델의 품질은 논리 데이터 모델 품질 기준에 따라 개체, 속성, 관계, 식별자, 모델 전반 등에 대하여 검토

    체크리스트를 작성하고 체크리스트의 각 항목을 확인하는 방식으로 검증한다

  - 개체 품질 검증 항목 : 단수 명사 여부, 개체의 주 식별자, 개체 간 상호 배타성, 개체의 정규화 여부, 개체 상세 정의,

    개체 관리 업무 기능, 개체에 2개 이상의 속성 존재 여부, 개체의 총 길이, 개체 동의어 여부, 개체 분산 요구 등

  - 속성 품질 검증 항목 : 단수 명사 여부, 속성의 값 존재 여부 및 개수, 도메인 정의, 반복되는 속성, 그룹화 가능 속성,

    주 식별자 및 비 식별자에 의존하는 속성, 다치 종속 속성 등

  - 관계 품질 검증 항목 : 관계의 명칭, 2개 이상의 노드와 관계 존재 여부, 노드의 기수성과 선택성, 필수적 관계,

    유효한 관계, 중복된 관계, 외부식별자 존재 여부, 참조 무결성 여부 등

  - 식별자 품질 검증 항목 : 식별자의 명칭, 정의, 구성, 정합성, 크기, 순서 등

  - 전반적인 품질 검증 항목 : 주제 영역 구성의 적절성, 데이터 모델 상에 정규화 여부, 다대다 관계 해소 여부,

    이력 관리 대상 선정 확인, 이력 관리 방법의 적절성 확인

 

 5. 데이터 모델에 표시할 요소

  - 구조(Structure) : 논리적으로 표현된 개체 타입들 간의 관계로서 데이터 구조 및 정적 성질을 표현한다

  - 연산(Operation) : 데이터베이스에 저장된 실제 데이터를 처리하는 작업에 대한 명세로서 데이터베이스를 조작하는

    기본 도구이다

  - 제약 조건(Constraint) : 데이터베이스에 저장될 수 있는 실제 데이터의 논리적인 제약 조건이다

 

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

 : 개념적 데이터 모델의 가장 대표적인 것으로, 1976년 피터 첸(Peter Chen)에 의해 제안되고 기본적인 구성 요소가

   정립되었다

 - 개체와 개체 간의 관계를 기본 요소로 이용하여 현실 세계의 무질서한 데이터를 개념적인 논리 데이터로 표현하기

   위한 방법으로 많이 사용되고 있다

 - 개체 타입(Entity Type)과 이들 간의 관계 타입(Relationship Type)을 이용해 현실 세계를 개념적으로 표현한다

 - 데이터를 개체(Entity), 관계(Relationship), 속성(Attribute)으로 묘사한다

 - 특정 DBMS를 고려한 것은 아니다

 - E-R 다이어그램으로 표현하며, 1:1, 1:N, N:N 등의 관계 유형을 제한 없이 나타낼 수 있다

 - 최초에는 개체, 관계, 속성과 같은 개념들로 구성되었으나 나중에는 일반화 계층 같은 복잡한 개념들이 첨가되어

   확장된 모델로 발전했다

 

 1. E-R 다이어그램

  : E-R 모델의 기본 아이디어를 시각적으로 표현하기 위한 그림으로, 실체 간의 관계는 물론 조직, 사용자, 프로그램,

    데이터 등 시스템 내에서 역할을 가진 모든 실체들을 표현한다

 

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

 - 1970년 IBM에 근무하던 코드(E. F. Codd)에 의해 처음 제안되었다

 - 관계형 데이터베이스를 구성하는 개체(Entity)나 관계(Relationship)를 모두 릴레이션(Relation)이라는 표(Table)로

    표현한다

 - 릴레이션은 개체를 표현하는 개체 릴레이션, 관계를 나타내는 관계 릴레이션으로 구분할 수 있다

 - 장점 : 간결하고 보기 편리하며, 다른 데이터베이스로의 변환이 용이하다

 - 단점 : 성능이 다소 떨어진다

 

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

  : 릴레이션은 데이터들을 표(Table)의 형태로 표현한 것으로 구조를 나타내는 릴레이션 스키마와 실제 값들인 릴레이션

    인스턴스로 구성된다

 - 튜플(Tuple)

   ㄱ. 릴레이션을 구성하는 각각의 행을 말한다

   ㄴ. 속성의 모임으로 구성된다

   ㄷ. 파일 구조에서 레코드와 같은 의미이다

   ㄹ. 튜플의 수를 카디널리티(Cardinality) 또는 기수, 대응수라고 한다

  - 속성(Attribute)

   ㄱ. 데이터베이스를 구성하는 가장 작은 논리적 단위이다

   ㄴ. 파일 구조상의 데이터 항목 또는 데이터 필드에 해당된다

   ㄷ. 개체의 특성을 기술한다

   ㄹ. 속성의 수를 디그리(Degree) 또는 차수라고 한다

  - 도메인(Domain)

   ㄱ. 하나의 애트리뷰트가 취할 수 있는 같은 타입의 원자(Atomic)값들의 집합이다

   ㄴ. 실제 애트리뷰트 값이 나타날 때 그 값의 합법 여부를 시스템이 검사하는데에도 이용된다

 

 2. 릴레이션의 특징

  - 한 릴레이션에는 똑같은 튜플이 포함될 수 없으므로 릴레이션에 포함된 튜플들은 모두 상이하다

  - 한 릴레이션에 포함된 튜플 사이에는 순서가 없다

  - 튜플들의 삽입, 삭제 등의 작업으로 인해 릴레이션은 시간에 따라 변한다

  - 릴레이션 스키마를 구성하는 속성들 간의 순서는 중요하지 않다

  - 속성의 유일한 식별을 위해 속성의 명칭은 유일해야 하지만, 속성을 구하는 값은 동일한 값이 있을 수 있다

  - 릴레이션을 구성하는 튜플을 유일하게 식별하기 위해 속성들의 부분집합을 키(Key)로 설정한다

  - 속성의 값은 논리적으로 더 이상 쪼갤 수 없는 원자값만 저장한다

 

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

 1. 제약 조건

  : 데이터베이스에 저장되는 데이터의 정확성을 보장하기 위하여 키(Key)를 이용하여 입력되는 데이터에 제한을

    주는 것으로 개체 무결성 제약, 참조 무결성 제약 등이 해당된다

 

 2. 키(Key)

  : 데이터베이스에서 조건에 만족하는 튜플을 찾거나 순서대로 정렬할 때 튜플들을 서로 구분할 수 있는 기준이 되는

    애트리뷰트를 말한다

 

 3. 후보키(Candidate Key)

  : 릴레이션을 구성하는 속성들 중에서 튜플을 유일하게 식별하기 위해 사용하는 속성들의 부분집합, 즉 기본키로

    사용할 수 있는 속성들을 말한다

  - 하나의 릴레이션 내에서는 중복된 튜플들이 있을 수 없으므로 모든 릴레이션에는 반드시 하나 이상의 후보키가

    존재한다

  - 릴레이션에 있는 모든 튜플에 대해서 유일성과 최소성을 만족시켜야 한다

   ㄱ. 유일성(Unique) : 하나의 키 값으로 하나의 튜플만을 유일하게 식별할 수 있어야 한다

   ㄴ. 최소성(Minimality) : 모든 레코드들을 유일하게 식별하는데 꼭 필요한 속성으로만 구성되어야 한다

 

 4. 기본키(Primary Key)

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

  - 한 릴레이션에서 특정 튜플을 유일하게 구별할 수 있는 속성이다

  - 후보키의 성질을 갖는다 즉, 유일성과 최소성을 가지며 튜플을 식별하기 위해 반드시 필요한 키이다

  - NULL 값을 가질 수 없다 즉, 튜플에서 기본키로 설정된 속성에는 NULL 값이 있어서는 안 된다

 

 5. 대체키(Alternate Key)

  : 후보키가 둘 이상일 때 기본키를 제외한 나머지 후보키를 의미한다 (보조키라고도 한다)

 

 6. 슈퍼키(Super Key)

  : 한 릴레이션 내에 있는 속성들의 집합으로 구성된 키로서 릴레이션을 구성하는 모든 튜플들 중 슈퍼키로 구성된

    속성의 집합과 동일한 값은 나타나지 않는다

  - 릴레이션을 구성하는 모든 튜플에 대해 유일성은 만족시키지만, 최소성은 만족시키지 못한다

 

 7. 외래키(Foreign Key)

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

  - 참조되는 릴레이션의 기본키와 대응되어 릴레이션 간에 참조 관계를 표현하는데 중요한 도구이다

  - 한 릴레이션에 속한 속성 A와 참조 릴레이션의 기본키인 B가 동일한 도메인 상에서 정의되었을 때의 속성 A를

    외래키라고 한다

  - 외래키로 지정되면 참조 릴레이션의 기본키에 없는 값은 입력할 수 없다

 

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

 : 데이터베이스에 저장된 데이터 값과 그것이 표현하는 현실 세계의 실제 값이 일치하는 정확성을 의미한다

 - 무결성 제약 조건은 데이터베이스에 들어 있는 데이터의 정확성을 보장하기 위해 부정확한 자료가 데이터베이스 내에

    저장되는 것을 방지하기 위한 제약 조건을 말한다

 - 무결성 규정에는 데이터가 만족해야 될 제약 조건, 규정을 참조할 때 사용하는 식별자 등의 요소가 포함될 수 있다

 - 무결성의 종류에는 개체 무결성, 도메인 무결성, 참조 무결성, 사용자 정의 무결성 등이 있다

 - 무결성 규정의 대상에는 도메인, 키, 종속성 등이 있다

 

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

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

 

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

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

 

 3. 참조 무결성(Referential Integrity)

  : 외래키 값은 Null이거나 참조 릴레이션의 기본키 값과 동일해야 한다 즉, 릴레이션은 참조할 수 없는 외래키 값을

    가질 수 없다는 규정이다

  - 외래키와 참조하려는 테이블의 기본키는 도메인과 속성 개수가 같아야 한다

 

 4. 사용자 정의 무결성(User-Difined Integrity)

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

 

 5. 데이터 무결성 강화

  : 데이터 품질에 직접적인 영향을 미치므로 데이터 특성에 맞는 적절한 무결성을 정의하고 강화해야 한다

  - 프로그램이 완성되고 데이터가 저장된 상태에서 무결성을 정의할 경우 많은 비용이 발생하므로 데이터베이스

    구축 과정에서 정의한다

  - 데이터 무결성은 애플리케이션, 데이터베이스 트리거, 제약 조건을 이용하여 강화할 수 있다

   ㄱ. 애플리케이션

    - 데이터 생성, 수정, 삭제 시 무결성 조건을 검증하는 코드를 데이터를 조작하는 프로그램 내에 추가한다

    - 코드를 이용한 복잡한 규칙 등을 검토하는 무결성 검사는 데이터베이스에서 수행하기 어려우므로 애플리케이션

      내에서 처리한다

    - 장점 : 사용자 정의 같은 복잡한 무결성 조건의 구현이 가능하다

    - 단점 : 소스 코드에 분산되어 있어 관리가 힘들고, 개별적인 시행으로 인해 적정성 검토가 어렵다

   ㄴ. 데이터베이스 트리거

    - 트리거 이벤트에 무결성 조건을 실행하는 절차형 SQL을 추가한다

    - 장점 : 통합 관리가 가능하고, 복잡한 요구 조건의 구현이 가능하다

    - 단점 : 운영 중 변경이 어렵고, 사용상 주의가 필요하다

   ㄷ. 제약 조건

    - 데이터베이스에 제약 조건을 설정하여 무결성을 유지한다

    - 장점 : 통합 관리 가능, 간단한 선언으로 구현 가능, 변경 용이, 오류 데이터 발생 방지 등이 있다

    - 단점 : 복잡한 제약 조건의 구현과 예외적인 처리가 불가능하다

 

∙관계대수 및 관계해석

 : 관계대수는 관계형 데이터베이스에서 원하는 정보와 그 정보를 검색하기 위해서 어떻게 유도하는가를 기술하는

   절차적인 언어이다

 - 릴레이션을 처리하기 위해 연산자와 연산규칙을 제공하는 언어로 피연산자가 릴레이션이고, 결과도 릴레이션이다

 - 질의에 대한 해를 구하기 위해 수행해야 할 연산의 순서를 명시한다

 - 주어진 릴레이션 조작을 위한 연산의 집합이다

 - 관계대수에는 관계 데이터베이스에 적용하기 위해 특별히 개발한 순수 관계 연산자와 수학적 집합 이론에서

   사용하는 일반 집합 연산자가 있다

 - 순수 관계 연산자 : Select, Project, Join, Division

 - 일반 집합 연산자 : UNION(합집합), INTERSECTION(교집합), DIFFERENCE(차집합), CARTESIAN PRODUCT(교차곱)

 

 1. Select

  : 릴레이션에 존재하는 튜플 중에서 선택 조건을 만족하는 튜플의 수평적 부분집합을 구하여 새로운 릴레이션을

    만드는 연산이다

  - 릴레이션의 행(가로)에 해당하는 튜플을 구하는 것이므로 수평 연산이라고도 한다

  - 연산자의 기호는 그리스 문자 시그마를 사용한다

   ㄴ. 조건에서는 =, ≠, <, ≤, >, ≥ 등의 기호를 사용한 비교 연산이 허용되며, AND(∧), OR(∨), NOT(┐) 등의

       논리 연산자를 사용하여 여러 개의 조건들을 하나의 조건으로 결합시킬 수도 있다

 

 2. Project

  : 주어진 릴레이션에서 속성 리스트(Attribute List)에 제시된 속성 값만을 추출하여 새로운 릴레이션을 만드는

    연산이다 (단, 연산 결과에 중복이 발생하면 중복이 제거된다)

  - 릴레이션의 열(세로)에 해당하는 Attribute를 추출하는 것이므로 수직 연산자라고도 한다

  - 연산자의 기호는 그리스 문자 파이를 사용한다

 

 3. Join

  : 공통 속성을 중심으로 두 개의 릴레이션을 하나로 합쳐서 새로운 릴레이션을 만드는 연산이다

  - Join의 결과로 만들어진 릴레이션의 차수는 조인된 두 릴레이션의 차수를 합한 것과 같다

  - Join의 결과는 Cartesian Product(교차곱)를 수행한 다음 Select를 수행한 것과 같다

  - 연산자의 기호는 ▷◁를 사용한다

 

  + 자연 조인(Natural Join)

   - 조인 조건이 ‘=’일 때 동일한 속성이 두 번 나타나게 되는데, 이중 중복된 속성을 제거하여 같은 속성을 한 번만

     표기하는 방법을 자연(Natural) 조인이라고 합니다

   - 자연 조건이 성립되려면 두 릴레이션의 속성명과 도메인이 같아야 합니다

 

  + 교차곱(Cartesian Product, 카디션 프로덕트)

   - 두 릴레이션에 존재하는 모든 튜플들을 대응시켜 새로운 릴레이션을 만드는 연산

   - 연산의 결과 차수는 두 릴레이션의 차수를 합한 것과 같고 튜플은 두 릴레이션의 튜플 수를 곱한 것과 같습니다

   - Cartesian Product의 결과는 두 릴레이션을 연결하여 나타낼 수 있는 모든 튜플들을 표현할 수 있으므로 여기에서

     필요한 튜플만 선별하는 Select 연산을 수행하면 Join 연산의 결과와 같아지는 것입니다

 

 4. Division

  : X⊃Y인 두 개의 릴레이션 R(X)와 S(Y)가 있을 때, R의 속성이 S의 속성값을 모두 가진 튜플에서 S가 가진

   속성을 제외한 속성만을 구하는 연산이다

  - 연산자의 기호는 ÷를 사용한다

  - 표기 형식 : R[속성r ÷ 속성s]S (속성r은 릴레이션 R의 속성, 속성s는 릴레이션 S의 속성)

   ㄱ. 속성r과 속성s는 동일 속성값을 가지는 속성이어야 한다

 

 5. 일반 집합 연산자

  : 수학적 집합 이론에서 사용하는 연산자로서 릴레이션 연산에도 그대로 적용할 수 있다

  - 일반 집합 연산자 중 합집합(UNION), 교집합(INTERSECTION), 차집합(DIFFERENCE)을 처리하기 위해서는

    합병 조건을 만족해야 한다

  - 합병 가능한 두 릴레이션 R과 S가 있을 때 각 연산의 특징을 요약하면 다음과 같다

연산자	기능 및 수학적 표현	카디널리티
합집합 UNION ∪	- 두 릴레이션에 존재하는 튜플의 합집합을 구하되, 결과로 생성된 릴레이션에서 중복되는 튜플은 제거되는 연산이다 - R ∪ S = { t | t ∈ R ∨ t ∈ S }   ※t는 릴레이션 R 또는 S에 존재하는 튜플이다	- |R∪S| ≤ |R| + |S| - 합집합의 카디널리티는 두 릴레이션 카디널리티의 합보다 크지 않다
교집합 INTERSECTION ∩	- 두 릴레이션에 존재하는 튜플의 교집합을 구하는 연산이다 - R ∩ S = { t | t ∈ R ∧ t ∈ S }   ※t는 릴레이션 R 그리고 S에 동시에 존재하는 튜플이다	- |R∩S| ≤ MIN{|R|, |S|} - 교집합의 카디널리티는 두 릴레이션 중 카디널리티가 적은 릴레이션의 카디널리티보다 크지 않다
차집합 DIFFERENCE -	- 두 릴레이션에 존재하는 튜플의 차집합을 구하는 연산이다 - R – S = { t | t ∈ R ∧ t ∉ S }   ※t는 릴레이션 R에는 존재하고 S에 없는 튜플이다	- |R - S| ≤ |R| - 차집합의 카디널리티는 릴레이션 R의 카디널리티보다 크지 않다
교차곱 CARTESIAN PRODUCT ×	- 두 릴레이션에 있는 튜플들의 순서쌍을 구하는 연산이다 - R × S = { r · s | r ∈ R ∧ s ∈ S }   ※r은 R에 존재하는 튜플이고, s는 S에 존재하는 튜플이다	- |R × S| = |R| × |S| - 교차곱의 디그리는 두 릴레이션의 디그리를 더한 것과 같고, 카디널리티는 두 릴레이션의 카디널리티를 곱한 것과 같다

 

 6. 관계해석(Relational Calculus)

  : 관계 데이터 모델의 제안자인 코드(E. F. Codd)가 수학의 Predicate Calculus(술어 해석)에 기반을 두고 관계

    데이터베이스를 위해 제안했다

  - 관계 데이터의 연산을 표현하는 방법으로, 원하는 정보를 정의할 때는 계산 수식을 사용한다

  - 원하는 정보가 무엇이라는 것만 정의하는 비절차적 특성을 지닌다

  - 튜플 관계해석과 도메인 관계해석이 있다

  - 기본적으로 관계해석과 관계대수는 관계 데이터베이스를 처리하는 기능과 능력면에서 동등하며, 관계대수로

    표현한 식은 관계해석으로 표현할 수 있다

  - 질의어로 표현한다

연산자	OR 연산	∨	원자식 간 “또는”이라는 관계로 연결
	AND 연산	∧	원자식 간 “그리고”라는 관계로 연결
	NOT 연산	┐	원자식에 대해 부정
정량자	전칭 정량자 (Universal Quantifier)	∀	모든 가능한 튜플(“for all”로 읽음)
	존재 정량자 (Existential Quantifier)	∃	어떤 튜플 하나라도 존재(“there exists”로 읽음)

 

 + 조건 연산자 / 연산자 우선순위

  - 조건 연산자

   ㄱ. 비교 연산자

=	<>	>	<	>=	<=
같다	같지 않다	크다	작다	크거나 같다	작거나 같다

   ㄴ. 논리 연산자 : NOT, AND, OR

   ㄷ. LIKE 연산자 : 대표 문자를 이용해 지정된 속성의 값이 문자 패턴과 일치하는 튜플을 검색하기 위해 사용

%	_	#
모든 문자를 대표함	문자 하나를 대표함	숫자 하나를 대표함

  - 연산자 우선순위

산술 연산자	X , / , + , -	왼쪽에서 오른쪽으로 갈수록 낮아짐
관계 연산자	= , <> , > , >= , < , <=	모두 같음
논리 연산자	NOT, AND, OR	왼쪽에서 오른쪽으로 갈수록 낮아짐

   ※ 산술, 관계, 논리 연산자가 함께 사용되었을 때는 산술 > 관계 > 논리 연산자 순서로 우선순위가 정해진다

 

∙정규화(Normalization)

 : 함수적 종속성 등의 종속성 이론을 이용하여 잘못 설계된 관계형 스키마를 더 작은 속성의 세트로 쪼개어 바람직한

   스키마로 만들어 가는 과정이다

 - 하나의 종속성이 하나의 릴레이션에 표현될 수 있도록 분해해가는 과정이라 할 수 있다

 - 정규형에는 제1정규형, 제2정규형, 제3정규형, BCNF형, 제4정규형, 제5정규형이 있으며, 차수가 높아질수록

   만족시켜야 할 제약 조건이 늘어난다

 - 데이터베이스의 논리적 설계 단계에서 수행한다

 - 논리적 처리 및 품질에 큰 영향을 미친다

 - 정규화된 데이터 모델은 일관성, 정확성, 단순성, 비중복성, 안정성 등을 보장한다

 - 정규화 수준이 높을수록 유연한 데이터 구축이 가능하고 데이터의 정확성이 높아지는 반면 물리적 접근이 복잡하고

   너무 많은 조인으로 인해 조회 성능이 저하된다

 

 1. 정규화의 목적

  - 데이터 구조의 안정성 및 무결성을 유지한다

  - 어떠한 릴레이션이라도 데이터베이스 내에서 표현 가능하게 만든다

  - 효과적인 검색 알고리즘을 생성할 수 있다

  - 데이터 중복을 배제하여 이상(Anomaly)의 발생 방지 및 자료 저장 공간의 최소화가 가능하다

  - 데이터 삽입 시 릴레이션을 재구성할 필요성을 줄인다

  - 데이터 모형의 단순화가 가능하다

  - 속성의 배열 상태 검증이 가능하다

  - 개체와 속성의 누락 여부 확인이 가능하다

  - 자료 검색과 추출의 효율성을 추구한다

 

 2. 이상(Anormaly)의 개념 및 종류

  : 정규화를 거치지 않으면 데이터베이스 내에 데이터들이 불필요하게 중복되어 릴레이션 조작 시 예기치 못한

    곤란한 현상이 발생하는데, 이를 이상(Anormaly)이라 하며 삽입 이상, 삭제 이상, 갱신 이상이 있다

  - 삽입 이상(Insertion Anormaly) : 릴레이션에 데이터를 삽입할 때 의도와는 상관없이 원하지 않은 값들도 함께

    삽입되는 현상이다

  - 삭제 이상(Deletion Anormaly) : 릴레이션에서 한 튜플을 삭제할 때 의도와는 상관없는 값들도 함께 삭제되는

    연쇄가 일어나는 현상이다

  - 갱신 이상(Update Anormaly) : 릴레이션에서 튜플에 있는 속성값을 갱신할 때 일부 튜플의 정보만 갱신되어

    정보에 모순이 생기는 현상이다

 

 3. 정규화의 원칙

  - 정보의 무손실 표현, 즉 하나의 스키마를 다른 스키마로 변환할 때 정보의 손실이 있어서는 안 된다

  - 분리의 원칙, 즉 하나의 독립된 관계성은 하나의 독립된 릴레이션으로 분리시켜 표현해야 한다

  - 데이터의 중복성이 감소되어야 한다

 

 4. 정규화 과정

  - 1NF(제1정규형)

   : 릴레이션에 속한 모든 도메인(Domain)이 원자값(Atomic Value)만으로 되어 있는 정규형이다. 즉, 릴레이션의

     모든 속성 값이 원자 값으로만 되어 있는 정규형이다

   ㄱ. 릴레이션의 모든 속성이 단순 영역에서 정의된다

  - 2NF(제2정규형)

   : 릴레이션 R이 1NF이고, 기본키가 아닌 모든 속성이 기본키에 대하여 부분 함수 종속 제거(완전 함수적 종속)을

     만족하는 정규형이다

  - 3NF(제3정규형)

   : 릴레이션 R이 2NF이고, 기본키가 아닌 모든 속성이 기본키에 대해 이행적 종속(Transitive Dependency)을

     만족하지 않는 정규형이다

   ㄱ. 무손실 조인 또는 종속성 보존을 저해하지 않고도 항상 3NF 설계를 얻을 수 있다

  - BCNF(Boyce-codd 정규형)

   : 릴레이션 R에서 결정자가 모두 후보키(Candidate Key)인 정규형이다

   ㄱ. 3NF에서 후보키가 여러 개 존재하고 서로 중첩되는 경우에 적용되는, 강한 제3정규형이라고도 한다

   ㄴ. 모든 BCNF(Boyce-codd Normal Form)가 종속성을 보존하는 것은 아니다

   ㄷ. BCNF의 제약 조건

    - 키가 아닌 모든 속성은 각 키에 대하여 완전 종속해야 한다

    - 키가 아닌 모든 속성은 그 자신이 부분적으로 들어가 있지 않은 모든 키에 대하여 완전 종속해야 한다

    - 어떤 속성도 키가 아닌 속성에 대해서는 완전 종속할 수 없다

  - 4NF(제4정규형)

   : 릴레이션 R에 다치 종속(Multi Valued Dependency, 다가 종속) A ↠ B가 성립하는 경우 R의 모든 속성이

     A에 함수적 종속 관계를 만족하는 정규형이다

  - 5NF(제5정규형)

   : 릴레이션 R의 모든 조인 종속(Join Dependency)이 R의 후보키를 통해서만 성립되고 이전 단계의 정규형을

     만족하면서 후보키를 통하지 않는 조인 종속 제거해야 만족하는 정규형이다

 

  + 함수적 종속 / 완전/부분 함수적 종속 및 이해

   - 함수적 종속(Functional Dependency)

    : 데이터들이 어떤 기준값에 의해 종속되는 것을 의미합니다

    ex) 예를 들어 <수강> 릴레이션이 (학번, 이름, 과목명)으로 되어 있을 때, ‘학번’이 결정되면 ‘과목명’에 상관없이

        ‘학번’에는 항상 같은 ‘이름’이 대응됩니다 ‘학번’에 따라 ‘이름’이 결정될 때 ‘이름’을 ‘학번’에 함수

        종속적이라고 하며 ‘학번→이름’과 같이 씁니다

 

   - 완전 함수적 종속

    : 어떤 테이블 R에서 속성 A가 다른 속성 집합 B 전체에 대해 함수적 종속이지만 속성 집합 B의 어떠한 진부분

      집합 C(즉, C⊂B)에는 함수적 종속이 아닐 때 속성 A는 속성 집합 B에 완전 함수적 종속이라고 합니다

 

   - 부분 함수적 종속

    : 어떤 테이블 R에서 속성 A가 다른 속성 B 전체에 대해 함수적 종속이면서 속성 집합 B의 어떠한 진부분

      집합에도 함수적 종속일 때, 속성 A는 속성 집합 B에 부분 함수적 종속이라고 합니다

 

   - 완전/부분 함수적 종속의 이해

    : 완전 함수적 종속은 어떤 속성이 기본키에 대해 완전히 종속적일 때를 말합니다

    ex) 예를 들어 <수강> 릴레이션이 (학번, 과목명, 성적, 학년)으로 되어 있고 (학번, 과목명)이 기본키일 때,

        ‘성적’은 ‘학번’과 ‘과목명’이 같을 경우에는 항상 같은 ‘성적’이 옵니다 즉 ‘성적’은 ‘학번’과 ‘과목명’에

        의해서만 결정되므로 ‘성적’은 기본키(학번, 과목명)에 완전 함수적 종속이 되는 것입니다

    ex) 반면에 ‘학년’은 ‘과목명’에 관계없이 ‘학번’이 같으면 항상 같은 ‘학년’이 옵니다 즉 기본키의 일부인 ‘학번’에

        의해서 ‘학년’이 결정되므로 ‘학년’은 부분 함수적 종속이라고 합니다

 

  - 정규화 과정 정리

 

∙반정규화(Denormalization)

  : 시스템의 성능 향상, 개발 및 운영의 편의성 등을 위해 정규화된 데이터 모델을 통합, 중복, 분리하는 과정으로,

    의도적으로 정규화 원칙을 위배하는 행위이다

  - 반정규화를 수행하면 시스템의 성능이 향상되고 관리 효율성은 증가하지만 데이터의 일관성 및 정합성이 저하될

    수 있다

  - 과도한 반정규화는 오히려 성능을 저하시킬 수 있다

  - 반정규화를 위해서는 사전에 데이터의 일관성을 무결성으로 우선으로 할지, 데이터 베이스의 성능과 단순화를

    우선으로 할지를 결정해야 한다

  - 반정규화 방법에는 테이블 통합, 테이블 분할, 중복 테이블 추가, 중복 속성 추가 등이 있다

 

 1. 테이블 통합

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

    수행한다

  - 두 개의 테이블에서 발생하는 프로세스가 동일하게 자주 처리되는 경우, 두 개의 테이블을 이용하여 항상 조회를

    수행하는 경우 테이블 통합을 고려한다

  - 테이블 통합의 종류에는 1:1 관계 테이블 통합, 1:N 관계 테이블 통합, 슈퍼타입/서브타입 테이블 통합이 있다

  - 테이블 통합 시 고려 사항

   ㄱ. 데이터 검색은 간편하지만 레코드 증가로 인해 처리량이 증가한다

   ㄴ. 테이블 통합으로 인해 입력, 수정, 삭제 규칙이 복잡해질 수 있다

   ㄷ. Not Null, Default, Check 등의 제약조건(Constraint)을 설계하기 어렵다

 

 2. 테이블 분할

  : 테이블을 수직 또는 수평으로 분할하는 것이다

  - 수평 분할(Horizontal Partitioning)

   ㄱ. 레코드(Record)를 기준으로 테이블을 분할하는 것이다

   ㄴ. 레코드별로 사용 빈도의 차이가 큰 경우 사용 빈도에 따라 테이블을 분할한다

  - 수직 분할(Vertical Partitioning)

   ㄱ. 하나의 테이블에 속성이 너무 많을 경우 속성을 기준으로 테이블을 분할하는 것이다

   ㄴ. 갱신 위주의 속성 분할 : 데이터 갱신 시 레코드 잠금으로 인해 다른 작업을 수행할 수 없으므로 갱신이 자주

       일어나는 속성들을 수직 분할하여 사용한다

   ㄷ. 자주 조회되는 속성 분할 : 테이블에서 자주 조회되는 속성이 극히 일부일 경우 자주 사용되는 속성들을 수직

       분할하여 사용한다

   ㄹ. 크기가 큰 속성 분할 : 이미지나 2GB 이상 저장될 수 있는 텍스트 형식 등으로 된 속성들을 수직 분할하여

       사용한다

   ㅁ. 보안을 적용해야 하는 속성 분할 : 테이블 내의 특정 속성에 대해 보안을 적용할 수 없으므로 보안을 적용해야

       하는 속성들을 수직 분할하여 사용한다

  - 테이블 분할 시 고려 사항

   ㄱ. 기본키의 유일성 관리가 어려워진다

   ㄴ. 데이터 양이 적거나 사용 빈도가 낮은 경우 테이블 분할이 필요한지를 고려해야한다

   ㄷ. 분할된 테이블로 인해 수행 속도가 느려질 수 있다

   ㄹ. 데이터 검색에 중점을 두어 테이블 분할 여부를 결정해야 한다

 

 3. 중복 테이블 추가

  : 여러 테이블에서 데이터를 추출해서 사용해야 하거나 다른 서버에 저장된 테이블을 이용해야 하는 경우 중복

    테이블을 추가하여 작업의 효율성을 향상시킬 수 있다

  - 중복 테이블을 추가하는 경우

   ㄱ. 정규화로 인해 수행 속도가 느려지는 경우

   ㄴ. 많은 범위의 데이터를 자주 처리해야 하는 경우

   ㄷ. 특정 범위의 데이터만 자주 처리해야 하는 경우

   ㄹ. 처리 범위를 줄이지 않고는 수행 속도를 개선할 수 없는 경우

  - 중복 테이블을 추가하는 방법은 다음과 같다

   ㄱ. 집계 테이블의 추가 : 집계 데이터를 위한 테이블을 생성하고, 각 원본 테이블에 트리거(Trigger)를 설정하여

       사용하는 것으로, 트리거의 오버헤드(Overhead)에 유의해야 한다

   ㄴ. 진행 테이블의 추가 : 이력 관리 등의 목적으로 추가하는 테이블로, 적절한 데이터 양의 유지와 활용도를

       높이기 위해 기본키를 적절히 설정한다

   ㄷ. 특정 부분만을 포함하는 테이블의 추가 : 데이터가 많은 테이블의 특정 부분만을 사용하는 경우 해당

       부분만으로 새로운 테이블을 생성한다

 

 4. 중복 속성 추가

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

    것이다

  - 중복 속성을 추가하면 데이터의 무결성 확보가 어렵고, 디스크 공간이 추가로 필요하다

  - 중복 속성을 추가하는 경우

   ㄱ. 조인이 자주 발생하는 속성인 경우

   ㄴ. 접근 경로가 복잡한 속성인 경우

   ㄷ. 액세스의 조건으로 자주 사용되는 속성인 경우

   ㄹ. 기본키의 형태가 적절하지 않거나 여러 개의 속성으로 구성된 경우

  - 중복 속성 추가 시 고려 사항

   ㄱ. 테이블 중복과 속성의 중복을 고려한다

   ㄴ. 데이터 일관성 및 무결성에 유의해야 한다

   ㄷ. SQL 그룹 함수를 이용하여 처리할 수 있어야 한다

   ㄹ. 저장 공간의 지나친 낭비를 고려한다

 

•시스템 카탈로그

 : 시스템 그 자체에 관련이 있는 시스템 자신이 필요로 하는 스키마 및 다양한 객체에 대한 정의나 명세에 대한 정보를

   포함하는 시스템 데이터베이스이다

 - 시스템 카탈로그 내의 각 테이블은 사용자를 포함하여 DBMS에서 지원하는 모든 데이터 객체에 대한 정의나 명세에

   관한 정보를 유지 관리하는 시스템 테이블이다

 - 카탈로그들이 생성되면 데이터 사전(Data Dictionary)에 저장되기 때문에 좁은 의미로는 카탈로그를 데이터

   사전이라고도 한다

 

 1. 시스템 카탈로그 저장 정보

  : 시스템 카탈로그에 저장된 정보를 메타 데이터(Meta-Data)라고 한다

  - 메타 데이터의 유형

   ㄱ. 데이터베이스 객체 정보 : 테이블(Table), 인덱스(Index), 뷰(View) 등의 구조 및 통계 정보

   ㄴ. 사용자 정보 : 아이디, 패스워드, 접근 권한 등

   ㄷ. 테이블의 무결성 제약 조건 정보 : 기본키, 외래키, NULL값 허용 여부 등

   ㄹ. 함수, 프로시저, 트리거 등에 대한 정보

 

 2. 카탈로그의 특징

  - 카탈로그 자체도 시스템 테이블로 구성되어 있어 일반 이용자도 SQL을 이용하여 내용을 검색해 볼 수 있다

  - INSERT, DELETE, UPDATE문으로 카탈로그를 갱신하는 것은 허용되지 않는다

  - 데이터베이스 시스템에 따라 상이한 구조를 갖는다

  - 카탈로그는 DBMS가 스스로 생성하고 유지하는 데이터베이스 내의 특별한 테이블의 집합체이다

  - 카탈로그의 갱신 : 사용자가 SQL문을 실행시켜 기본 테이블, 뷰, 인덱스 등에 변화를 주면 시스템이 자동으로

    갱신한다

  - 분산 시스템에서의 카탈로그 : 보통의 릴레이션, 인덱스, 사용자 등의 정보를 포함할뿐 아니라 위치 투명성 및 중복

    투명성을 제공하기 위해 필요한 모든 제어 정보를 가져야 한다

 

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

  - 데이터 정의어 번역기(DDL Complier) : DDL을 메타 데이터를 갖는 테이블(카탈로그)로 변환하여 데이터 사전에

    저장시킨다

  - 데이터 조작어 번역기(DML Complier) : 응용 프로그램에 삽입된 DML문을 주 언어로 표현한 프로시저 호출로

    변환하여 질의 처리기와 상호 통신한다

  - Data Directory

   ㄱ. 데이터 사전에 수록된 데이터를 실제로 접근하는데 필요한 정보를 관리 유지하는 시스템이다

   ㄴ. 시스템 카탈로그는 사용자와 시스템 모두 접근할 수 있지만 데이터 디렉터리는 시스템만 접근할 수 있다

  - 질의 최적화기 : 사용자의 요구를 효율적인 형태로 변환하고 질의를 처리하는 좋은 전략을 모색한다

  - 트랜잭션 처리기 : 복수 사용자 환경에서 평행으로 동시에 일어나는 트랜잭션 문제를 해결하여, 각각의 사용자가

    데이터베이스 자원을 베타적으로 이용할 수 있도록 한다

---

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

 

∙사전 조사 분석

 1. 물리 데이터베이스 설계

  : 논리적 구조로 표현된 논리적 데이터베이스를 디스크 등의 물리적 저장장치에 저장할 수 있는 물리적 구조의

    데이터로 변환하는 과정이다

  - 물리적 데이터베이스 구조의 기본적인 데이터 단위는 저장 레코드(Stored Record)이다

  - 물리적 설계 단계에 꼭 포함되어야 할 것은 저장 레코드의 양식 설계, 레코드 집중(Record Clustering)의

    분석 및 설계, 접근 경로 설계 등이다

  - 물리적 데이터베이스 구조는 여러 가지 타입의 저장 레코드 집합이라는 면에서 단순한 파일과 다르다

  - 물리적 데이터베이스 구조는 데이터베이스 시스템의 성능에 중대한 영향을 미친다

  - 물리적 설계 시 고려 사항

   ㄱ. 인덱스 구조

   ㄴ. 레코드 크기

   ㄷ. 파일에 존재하는 레코드 개수

   ㄹ. 파일에 대한 트랜잭션의 갱신과 참조 성향

   ㅁ. 성능 향상을 위한 개념 스키마의 변경 여부 검토

   ㅂ. 빈번한 질의와 트랜잭션들의 수행속도를 높이기 위한 고려

   ㅅ. 시스템 운용 시 파일 크기의 변화 가능성

  - 물리적 설계 전에 기존 시스템을 분석하여 데이터 명명 규칙, 시스템 자원, 데이터베이스 관리 요소 등을 파악

 

 + 물리적 설계 옵션 (물리적 설계 시 고려 사항)

  : 특정 DBMS에서 제공되는 것으로, 데이터베이스 파일에 대한 저장 구조와 접근 경로에 대한 다양한 옵션을 말한다

  - 반응시간(Response Time) : 트랜잭션 수행을 요구한 시점부터 처리 결과를 얻을때까지의 경과 시간

  - 공간 활용도(Space Utilization) : 데이터베이스 파일과 액세스 경로 구조에 의해 사용되는 저장 공간의 양

  - 트랜잭션 처리량(Transaction Throughput) : 단위시간 동안 데이터베이스 시스템에 의해 처리될 수 있는

    트랜잭션의 평균 개수

 

•트랜잭션 분석 / CRUD 분석

 1. 트랜잭션(Transaction) 정의

  : 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 모두

    수행되어야 할 일련의 연산들을 의미한다

  - 데이터베이스 시스템에서 병행 제어 및 회복 작업 시 처리되는 작업의 논리적 단위로 사용된다

  - 사용자가 시스템에 대한 서비스 요구 시 시스템이 응답하기 위한 상태 변환 과정의 작업 단위로 사용된다

 

 2. 트랜잭션의 특성

  - 다음은 데이터의 무결성(Integrity)을 보장하기 위하여 DBMS의 트랜잭션이 가져야 할 특성이다

원자성(Atomicity)	- 트랜잭션의 연산은 데이터베이스에 모두 반영되도록 완료(Commit)되든지 아니면 전혀 반영되지   않도록 복구(Rollback)되어야 한다 - 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 모두가 완벽히 수행되지 않고 어느   하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다
일관성(Consistency)	- 트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 변환한다 - 시스템이 가지고 있는 고정 요소는 트랜잭션 수행 전과 트랜잭션 수행 완료 후의 상태가   같아야 한다
독립성, 격리성, 순차성 (Isolation)	- 둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션 실행 중에 다른   트랜잭션의 연산이 끼어들 수 없다 - 수행중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없다
영속성, 지속성 (Durability)	성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영되어야 한다

 

 3. CRUD 분석

  : '생성(Create), 읽기(Read), 갱신(Update), 삭제(Delete)'의 앞 글자만 모아서 만든 용어이며, CRUD 분석은

    데이터베이스 테이블에 변화를 주는 트랜잭션의 CRUD 연산에 대해 CRUD 매트릭스를 작성하여 분석하는 것이다

  - CRUD 분석으로 테이블에 발생되는 트랜잭션의 주기별 발생 횟수를 파악하고 연관된 테이블들을 분석하면 테이블에

    저장되는 데이터의 양을 유추할 수 있다

  - CRUD 분석을 통해 많은 트랜잭션이 몰리는 테이블을 파악할 수 있으므로 디스크 구성 시 유용한 자료로 활용할 수

    있다

  - CRUD 분석을 통해 외부 프로세스 트랜잭션의 부하가 집중되는 데이터베이스 채널을 파악하고 분산시킴으로써

    연결 지연이나 타임아웃 오류를 방지할 수 있다

 

 4. CRUD 매트릭스

  : 2차원 형태의 표로서, 행(Row)에는 프로세스를, 열(Column)에는 테이블을, 행과 열이 만나는 위치에는 프로세스가

    테이블에 발생시키는 변화를 표시하는 업무 프로세스와 데이터 간 상관 분석표이다

  - CRUD 매트릭스를 통해 프로세스의 트랜잭션이 테이블에 수행하는 작업을 검증한다

  - CRUD 매트릭스의 각 셀에는 Create, Read, Update, Delete의 앞 글자가 들어가며, 복수의 변화를 줄 때는 기본적으로

    'C > D > U > R'의 우선순위를 적용하여 한가지만 적지만, 활용 목적에 따라 모두 기록할 수 있다

  - CRUD 매트릭스가 완성되었다면 C, R, U, D 중 어느 것도 적히지 않은 행이나 열, C나 R이 없는 열을 확인하여

    불필요하거나 누락된 테이블 또는 프로세스를 찾는다

 

 5. 트랜잭션 분석

  : 트랜잭션 분석의 목적은 CRUD 매트릭스를 기반으로 테이블에 발생하는 트랜잭션 양을 분석하여 테이블에 저장되는

    데이터의 양을 유추하고 이를 근거로 DB 용량을 산정하고 DB 구조를 최적화하는 것이다

  - 트랜잭션 분석은 업무 개발 담당자가 수행한다

  - 트랜잭션 분석을 통해 프로세스가 과도하게 접근하는 테이블을 확인하여 여러 디스크에 배치함으로써 디스크

    입·출력 분산을 통한 성능 향상을 가져올 수 있다

 

 6. 트랜잭션 분석서

  : 단위 프로세스와 CRUD 매트릭스를 이용하여 작성하며, 구성 요소에는 단위 프로세스, CRUD 연산, 테이블명, 컬럼명,

    테이블 참조 횟수, 트랜잭션 수, 발생 주기 등이 있다

  - 단위 프로세스 : 업무를 발생시키는 가장 작은 단위의 프로세스

  - CRUD 연산 : 프로세스의 트랜잭션이 데이터베이스 테이블에 영향을 주는 C, R, U, D의 4가지 연산

  - 테이블명, 컬럼명 : 프로세스가 접근하는 데이터베이스의 테이블명을 기록한다 필요한 경우 테이블의 컬럼명을

    적는다 (컬럼명을 적을 때는 마침표로 연결하여 '테이블.컬럼명'과 같이 적는다)

  - 테이블 참조 횟수 : 프로세스가 테이블을 참조하는 횟수

  - 트랜잭션 수 : 주기별로 수행되는 트랜잭션 횟수

  - 발생 주기 : 연, 분기, 월, 일, 시간 등 트랜잭션 횟수를 측정하기 위한 발생 주기

 

•인덱스 설계

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

 - 데이터가 저장된 물리적 구조와 밀접한 관계가 있다

 - 레코드가 저장된 물리적 구조에 접근하는 방법을 제공한다

 - 인덱스를 통해서 파일의 레코드에 대한 액세스를 빠르게 수행할 수 있다

 - 레코드의 삽입과 삭제가 수시로 일어나는 경우에는 인덱스의 개수를 최소로 하는 것이 효율적이다

 - 데이터 정의어(DDL)를 이용하여 사용자가 생성, 변경, 제거할 수 있다

 - 인덱스가 없으면 특정한 값을 찾기 위해 모든 데이터 페이지를 확인하는 TABLE SCAN이 발생한다

 - 기본키를 위한 인덱스를 기본 인덱스라 하고, 기본 인덱스가 아닌 인덱스들을 보조 인덱스라고 한다 대부분의 관계형

   데이터베이스 관리 시스템에서는 모든 기본키에 대해서 자동적으로 기본 인덱스를 생성한다

 - 레코드의 물리적 순서가 인덱스의 엔트리 순서와 일치하게 유지되도록 구성되는 인덱스를 클러스터드(Clustered)

   인덱스라 한다

 - 인덱스를 구성하는 구조나 특징에 따라 트리 기반 인덱스, 비트맵 인덱스, 함수 기반 인덱스, 비트맵 조인 인덱스,

   도메인 인덱스 등으로 분류된다

 

 + 클러스터드 인덱스 / 넌클러스터드 인덱스

  - 클러스터드 인덱스(Clustered Index)

   ㄱ. 인덱스 키의 순서에 따라 데이터가 정렬되어 저장되는 방식입니다

   ㄴ. 실제 데이터가 순서대로 저장되어 있어 인덱스를 검색하지 않아도 원하는 데이터를 빠르게 찾을 수 있습니다

   ㄷ. 데이터 삽입, 삭제 발생 시 순서를 유지하기 위해 데이터를 재정렬해야 합니다

   ㄹ. 한 개의 릴레이션에 하나의 인덱스만 생성할 수 있습니다

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

   ㄱ. 인덱스의 키 값만 정렬되어 있을 뿐 실제 데이터는 정렬되지 않는 방식입니다

   ㄴ. 데이터를 검색하기 위해서는 먼저 인덱스를 검색하여 실제 데이터의 위치를 확인해야 하므로 클러스터드

        인덱스에 비해 검색 속도가 떨어집니다

   ㄷ. 한 개의 릴레이션에 여러 개의 인덱스를 만들 수 있습니다

 

 1. 트리 기반 인덱스

  : 인덱스를 저장하는 블록들이 트리 구조를 이루고 있는 것으로, 상용 DBMS에서는 트리 구조 기반의 B+ 트리

    인덱스를 주로 활용한다

  - B- 트리 인덱스

   ㄱ. 일반적으로 사용되는 인덱스 방식으로, 루트 노드에서 하위 노드로 키 값의 크기를 비교해 나가면서 단말

        노드에서 찾고자 하는 데이터를 검색한다

   ㄴ. 키 값과 레코드를 가리키는 포인터들이 트리 노드에 오름차순으로 저장된다

   ㄷ. 모든 리프 노드는 같은 레벨에 있다

   ㄹ. 브랜치 블록(Branch Block)과 리프 블록(Leaf Block)으로 구성된다

    - 브랜치 블록 : 분기를 위한 목적으로 사용되고, 다음 단계를 가리키는 포인터를 가지고 있음

    - 리프 블록 : 인덱스를 구성하는 컬럼 데이터와 해당 데이터의 행 위치를 가리키는 레코드 식별자로 구성됨

  - B+ 트리 인덱스

   ㄱ. B- 트리의 변형으로 단말 노드가 아닌 노드로 구성된 인덱스 세트(Index Set)와 단말 노드로만 구성된 순차 세트

      (Sequence Set)로 구분된다

   ㄴ. 인덱스 세트에 있는 노드들은 단말 노드에 있는 키 값을 찾아갈 수 있는 경로로만 제공되며, 순차 세트에 있는

        단말 노드가 해당 데이터 레코드의 주소를 가리킨다

   ㄷ. 인덱스 세트에 모든 키 값이 단말 노드에 다시 나타나므로 단말 노드만을 이용한 순차 처리가 가능하다

 

 2. 비트맵 인덱스

  : 인덱스 컬럼의 데이터를 Bit 값인 0 또는 1로 변환하여 인덱스 키로 사용하는 방법이다

  - 목적은 키 값을 포함하는 로우(Row)의 주소를 제공하는 것이다

  - 분포도가 좋은 컬럼에 적합하며, 성능 향상 효과를 얻을 수 있다

  - 데이터가 Bit로 구성되어 있기 때문에 효율적인 논리 연산이 가능하고 저장 공간이 작다

  - 다중 조건을 만족하는 튜플의 개수 계산에 적합하다

  - 동일한 값이 반복되는 경우가 많아 압축 효율이 좋다

 

 3. 함수 기반 인덱스

  : 컬럼의 값 대신 컬럼에 특정 함수(Function)나 수식(Expression)을 적용하여 산출된 값을 사용하는 것으로, B+ 트리

    인덱스 또는 비트맵 인덱스를 생성하여 사용한다

  - 데이터를 입력하거나 수정할 때 함수를 적용해야 하므로 부하가 발생할 수 있다

  - 사용된 함수가 사용자 정의 함수일 경우 시스템 함수보다 부하가 더 크다

  - 대소문자, 띄어쓰기 등에 상관없이 조회할 때 유용하게 사용된다

  - 적용 가능한 함수의 종류 : 산술식(Arithmetic Expression), 사용자 정의 함수, PL/SQL Function, SQL Function,

    Package, C callout 등

 

 4. 비트맵 조인 인덱스

  : 다수의 조인된 객체로 구성된 인덱스로, 단일 객체로 구성된 일반적인 인덱스와 액세스 방법이 다르다

  - 비트맵 인덱스와 물리적 구조가 동일하다

 

 5. 도메인 인덱스

  : 개발자가 필요한 인덱스를 직접 만들어 사용하는 것으로, 확장형 인덱스(Extensible Index)라고도 한다

  - 개발자가 필요에 의해 만들었지만 프로그램에서 제공하는 인덱스처럼 사용할 수도 있다

 

 6. 인덱스 설계

  : 인덱스를 설계할 때는 분명하게 드러난 컬럼에 대해 기본적인 인덱스를 먼저 지정한 후 개발 단계에서 필요한

    인덱스의 설계를 반복적으로 진행한다

  - 인덱스 설계 순서

   ㄱ. 인덱스의 대상 테이블이나 컬럼 등을 선정한다

   ㄴ. 인덱스의 효율성을 검토하여 인덱스 최적화를 수행한다

   ㄷ. 인덱스 정의서를 작성한다

 

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

  - MULTI BLOCK READ 수에 따라 판단

  - 랜덤 액세스가 빈번한 테이블

  - 특정 범위나 특정 순서로 데이터 조회가 필요한 테이블

  - 다른 테이블과 순차적 조인이 발생되는 테이블

 

 8. 인덱스 대상 컬럼 선정 기준

  - 인덱스 컬럼의 분포도가 10~15% 이내인 컬럼 (분포도 = (컬럼값의 평균 Row 수 / 테이블의 총 Row 수) X 100)

  - 분포도가 10~15% 이상이어도 부분 처리를 목적으로 하는 컬럼

  - 입·출력 장표 등에서 조회 및 출력 조건으로 사용되는 컬럼

  - 인덱스가 자동 생성되는 기본키와 Unique키 제약 조건을 사용한 컬럼

  - 가능한 한 수정이 빈번하지 않은 컬럼

  - ORDER BY, GROUP BY, UNION이 빈번한 컬럼

  - 분포도가 좁은 컬럼은 단독 인덱스로 생성

  - 인덱스들이 자주 조합되어 사용되는 경우 하나의 결합 인덱스(Concatenate Index)로 생성

 

 9. 인덱스 설계 시 고려사항

  - 새로 추가되는 인덱스는 기존 액세스 경로에 영향을 미칠 수 있다

  - 인덱스를 지나치게 많이 만들면 오버헤드가 발생한다

  - 넓은 범위를 인덱스로 처리하면 많은 오버헤드가 발생한다

  - 인덱스를 만들면 추가적인 저장 공간이 필요하다

  - 인덱스와 테이블 데이터의 저장 공간이 분리되도록 설계한다

 

∙뷰(View) 설계

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

   가지는 가상 테이블이다

 - 저장장치 내에 물리적으로 존재하지 않지만, 사용자에게는 있는 것처럼 간주된다

 - 사용자가 필요한 정보를 요구에 맞게 가공하여 뷰로 만들거나 데이터 보정 작업, 처리 과정 시험 등 임시적인

   작업을 위한 용도로 활용된다

 - 조인문의 사용 최소화로 사용상의 편의성을 최대화한다

 - 뷰를 생성하면 뷰 정의가 시스템 내에 저장되었다가 생성된 뷰 이름을 질의어(에를 들면 SQL)에서 사용할 경우

   질의어가 실행될 때 뷰에 정의된 기본 테이블로 대체되어 기본 테이블에 대해 실행된다

 

 1. 뷰(View)의 특징

  - 기본 테이블로부터 유도된 테이블이기 때문에 기본 테이블과 같은 형태의 구조를 사용하며, 조작도 기본 테이블과

    거의 같다

  - 가상 테이블이기 때문에 물리적으로 구현되어 있지 않다

  - 데이터의 논리적 독립성을 제공할 수 있다

  - 필요한 데이터만 뷰로 정의해서 처리할 수 있기 때문에 관리가 용이하고 명령문이 간단해진다

  - 뷰를 통해서만 데이터에 접근하게 하면 뷰에 나타나지 않는 데이터를 안전하게 보호하는 효율적인 기법으로

    사용할 수 있다

  - DBA는 보안 측면에서 뷰를 활용할 수 있다

  - 기본 테이블의 기본키를 포함한 속성(열) 집합으로 뷰를 구성해야만 삽입, 삭제, 갱신 연산이 가능하다

  - 일단 정의된 뷰는 다른 뷰의 정의에 기초가 될 수 있다

  - 뷰가 정의된 기본 테이블이나 뷰를 삭제하면 그 테이블이나 뷰를 기초로 정의된 다른 뷰도 자동으로 삭제된다

  - 뷰를 정의할 때는 CREATE문, 제거할 때는 DROP문을 사용한다

 

 2. 뷰(View)의 장·단점

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

 

 3. 뷰 설계 순서

  - 대상 테이블을 선정한다

   ㄱ. 외부 시스템과 인터페이스에 관여하는 테이블

   ㄴ. CRUD 매트릭스를 통해 여러 테이블이 동시에 자주 조인되어 접근되는 테이블

   ㄷ. SQL문 작성 시 거의 모든 문장에서 인라인 뷰 방식으로 접근되는 테이블

  - 대상 컬럼을 선정한다

   ㄱ. 보안을 유지해야 하는 컬럼은 주의하여 선별한다

  - 정의서를 작성한다

 

 4. 뷰 설계 시 고려 사항

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

    뷰로 생성한다

  - 동일한 테이블이라도 업무에 따라 테이블을 이용하는 부분이 달라질 수 있으므로 사용할 데이터를 다양한

    관점에서 제시해야 한다

  - 데이터의 보안 유지를 고려하여 설계한다

 

∙파티션 설계

 : 데이터베이스에서 파티션은 대용량의 테이블이나 인덱스를 작은 논리적 단위인 파티션으로 나누는 것을 의미한다

 - 대용량 DB의 경우 중요한 몇 개의 테이블에만 집중되어 데이터가 증가되므로, 이런 테이블들을 작은 단위로 나눠

   분산시키면 성능 저하를 방지할 뿐만 아니라 데이터 관리도 쉬워진다

 - 테이블이나 인덱스를 파티셔닝 하면 파티션키 또는 인덱스키에 따라 물리적으로 별도의 공간에 데이터가 저장된다

 - 데이터 처리는 테이블 단위로 이뤄지고, 데이터 저장은 파티션별로 수행된다

 

 1. 파티션의 장·단점

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

 

 2. 파티션의 종류

범위 분할 (Range Partitioning)	지정한 열의 값을 기준으로 범위를 지정하여 분할한다
해시 분할 (Hash Partitioning)	- 해시 함수를 적용한 결과 값에 따라 데이터를 분할한다 - 특정 파티션에 데이터가 집중되는 범위 분할의 단점을 보완한 것으로, 데이터를 고르게 분산할 때 유용하다 - 특정 데이터가 어디에 있는지 판단할 수 없다 - 고객번호, 주민번호 등과 같이 데이터가 고른 컬럼에 효과적이다
조합 분할 (Composite Partitioning)	- 범위 분할로 분할한 다음 해시 함수를 적용하여 다시 분할하는 방식이다 - 범위 분할한 파티션이 너무 커서 관리가 어려울 때 유용하다
목록 분할 (List Partitioning)	지정한 열 값에 대한 목록을 만들어 이를 기준으로 분할한다
라운드 로빈 분할 (Round Robin Partitioning)	- 레코드를 균일하게 분배하는 방식이다 - 각 레코드가 순차적으로 분배되며, 기본키가 필요없다

 

 3. 파티션키 선정 시 고려 사항

  - 파티션키는 테이블 접근 유형에 따라 파티셔닝이 이뤄지도록 선정한다

  - 데이터 관리의 용이성을 위해 이력성 데이터는 파티션 생성주기와 소멸주기를 일치시켜야 한다

  - 매일 생성되는 날짜 컬럼, 백업의 기준이 되는 날짜 컬럼, 파티션 간 이동이 없는 컬럼, I/O 병목을 줄일 수 있는

    데이터 분포가 양호한 컬럼 등을 파티션키로 선정한다

 

 4. 인덱스 파티션

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

  - 파티션된 테이블의 종속 여부에 따라 Local Partitioned Index와 Global Partitioned Index로 나뉜다

   ㄱ. 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를 조합하여 Local Prefixed, Local Non-Prefixed , Global Prefixed

    등으로 구성하여 사용한다

 

∙분산 데이터베이스 설계

 : 논리적으로는 하나의 시스템에 속하지만 물리적으로는 네트워크를 통해 연결된 여러 개의 컴퓨터 사이트(Site)에

   분산되어 있는 데이터베이스를 말한다

 - 데이터의 처리나 이용이 많은 지역에 데이터베이스를 위치시킴으로써 데이터의 처리가 가능한 해당 지역에서 해결

   될 수 있도록 한다

 

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

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

 

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

  - 작업부하(Work Load)의 노드별 분산 정책

  - 지역의 자치성 보장 정책

  - 데이터의 일관성 정책

  - 사이트나 회선의 고장으로부터의 회복 기능

  - 통신 네트워크를 통한 원격 접근 기능

 

 3. 분산 데이터베이스의 목표

  - 위치 투명성(Location Trasparency) : 액세스하려는 데이터베이스의 실제 위치를 알 필요 없이 단지

    데이터베이스의 논리적인 명칭만으로 액세스할 수 있다

  - 중복 투명성(Replication Transparency) : 동일 데이터가 여러 곳에 중복되어 있더라도 사용자는 마치 하나의

    데이터만 존재하는 것처럼 사용하고, 시스템은 자동으로 여러 자료에 대한 작업을 수행한다

  - 병행 투명성(Concurrency Trasparency) : 분산 데이터베이스와 관련된 다수의 트랜잭션들이 동시에

    실현되더라도 그 트랜잭션의 결과는 영향을 받지 않는다

  - 장애 투명성(Failure Transparency) : 트랜잭션, DBMS, 네트워크, 컴퓨터 장애에도 불구하고 트랜잭션을

    정확하게 처리한다

 

 4. 분산 데이터베이스의 장·단점

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

 

 5. 분산 데이터베이스 설계

  : 애플리케이션이나 사용자가 분산되어 저장된 데이터에 접근하게 하는 것을 목적으로 한다

  - 잘못 설계된 분산 데이터베이스는 복잡성 증가, 응답 속도 저하, 비용 증가 등의 문제가 발생한다

  - 분산 데이터베이스의 설계는 전역 관계망을 논리적 측면에서 소규모 단위로 분할한 후, 분할된 결과를 복수의

    노드에 할당하는 과정으로 진행된다 노드에 할당된 소규모 단위를 분할(Fragment)이라 부른다

  - 분산 설계 방법에는 테이블 위치 분산, 분할(Fragmentation), 할당(Allocation)이 있다

 

 6. 테이블 위치 분산

  : 데이터베이스의 테이블을 각기 다른 서버에 분산시켜 배치하는 방법을 의미한다

  - 테이블 위치를 분산할 때는 테이블의 구조를 변경하지 않으며, 다른 데이터베이스의 테이블과 중복되지 않게 배치

  - 데이터베이스의 테이블을 각각 다른 위치에 배치하려면 해당 테이블들이 놓일 서버들을 미리 설정해야 한다

 

 7. 분할

  : 테이블의 데이터를 분할하여 분산시키는 것이다

  - 분할 규칙

   ㄱ. 완전성(Completeness) : 전체 데이터를 대상으로 분할해야 한다

   ㄴ. 재구성(Reconstruction) : 분할된 데이터는 관계 연산을 활용하여 본래의 데이터로 재구성할 수 있어야 한다

   ㄷ. 상호 중첩 배제(Dis-jointness) : 분할된 데이터는 서로 다른 분할의 항목에 속하지 않아야 한다

  - 주요 분할 방법

   ㄱ. 수평 분할 : 특정 속성의 값을 기준으로 행(Row) 단위로 분할

   ㄴ. 수직 분할 : 데이터 컬럼(속성) 단위로 분할

 

 8. 할당(Allocation)

  : 동일한 분할을 여러 개의 서버에 생성하는 분산 방법으로, 중복이 없는 할당(Allocation)과 중복이 있는 할당

    (Allocation)으로 나뉜다

  - 비중복 할당 방식

   ㄱ. 최적의 노드를 선택해서 분산 데이터베이스의 단일 노드에서만 분할이 존재하도록 하는 방식이다

   ㄴ. 일반적으로 애플리케이션에는 릴레이션을 배타적 분할로 분리하기 힘든 요구가 포함되므로 분할된 테이블 간의

       의존성은 무시되고 비용 증가, 성능 저하 등의 문제가 발생할 수 있다

  - 중복 할당 방식

   ㄱ. 동일한 테이블을 다른 서버에 복제하는 방식으로, 일부만 복제하는 부분 복제와 전체를 복제하는 완전 복제가

       있다

 

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

 1. 데이터베이스 이중화(DataBase Replication)

  : 시스템 오류로 인한 데이터베이스 서비스 중단이나 물리적 손상 발생 시 이를 복구하기 위해 동일한

    데이터베이스를 복제하여 관리하는 것이다

  - 데이터베이스 이중화를 수행하면 하나 이상의 데이터베이스가 항상 같은 상태를 유지하므로 데이터베이스에

    문제가 발생하면 복제된 데이터베이스를 이용하여 즉시 문제를 해결할 수 있다

  - 여러 개의 데이터베이스를 동시에 관리하므로 사용자가 수행하는 작업이 데이터베이스 이중화 시스템에 연결된

    다른 데이터베이스에도 동일하게 적용된다

  - 애플리케이션을 여러 개의 데이터베이스로 분산시켜 처리하므로 데이트베이스의 부하를 줄일 수 있다

  - 데이터베이스 이중화를 이용하면 손쉽게 백업 서버를 운영할 수 있다

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

  : 변경 내용의 전달 방식에 따라 Eager 기법과 Lazy 기법으로 나뉜다

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

 

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

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

 

 4. 클러스터링(Clustering)

  : 두 대 이상의 서버를 하나의 서버처럼 운영하는 기술이다

  - 클러스터링은 서버 이중화 및 공유 스토리지를 사용하여 서버의 고가용성을 제공한다

  - 클러스터링에는 고가용성 클러스터링과 병렬 처리 클러스터링이 있다

   ㄱ. 고가용성 클러스터링 : 하나의 서버에 장애가 발생하면 다른 노드(서버)가 받아 처리하여 서비스 중단을

       방지하는 방식으로, 일반적으로 언급되는 클러스터링이 고가용성 클러스터링이다

   ㄴ. 병렬 처리 클러스터링 : 전체 처리율을 높이기 위해 하나의 작업을 여러 개의 서버에서 분산하여 처리하는

        방식이다

 + 고가용성 솔루션(HACMP; High Availability Cluster Multi Processing)

  - AIX를 기반으로 한 IBM의 High Availability Solution

  - Resource의 중복 또는 공유를 통해 Application의 보호를 가능하게 해줌

  - 같은 Data를 공유하거나 동시에 Access하는 Node들에서 여러 개의 Application을 실행하게 해줌

  - 두 대 이상의 시스템 간에 공유 디스크를 중심으로 하나의 Cluster로 묶어 Cluster내의 한 시스템에서 장애가

    발생할 경우 다른 시스템이 장애가 발생한 시스템의 자원을 인수할 수 있도록 하여 서비스의 중단을 최소화 할 수

    있도록 도와주는 솔루션

  - 조직, 기업의 기간 업무 서버 등의 안정성을 높이기 위해 사용될 수 있다

  - 여러 가지 방식으로 구현되며 2개의 서버를 연결하는 것으로 2개의 시스템이 각각 업무를 수행하도록 구현하는

    방식이 널리 사용된다

 

∙데이터베이스 보안 – 접근통제

 : 데이터가 저장된 객체와 이를 사용하려는 주체 사이의 정보 흐름을 제한하는 것이다

 - 데이터에 대해 다음과 같은 통제를 함으로써 자원의 불법적인 접근 및 파괴를 예방한다

  ㄱ. 비인가된 사용자의 접근 감시

  ㄴ. 접근 요구자의 사용자 식별

  ㄷ. 접근 요구의 정당성 확인 및 기록

  ㄹ. 보안 정책에 근거한 접근의 승인 및 거부 등

 - 접근통제 기술

임의 접근통제 (DAC, Discretionary Access Control)	- 임의 접근통제는 데이터에 접근하는 사용자의 신원에 따라 접근 권한을 부여하는 방식이다 - 데이터 소유자가 접근통제 권한을 지정하고 제어한다 - 객체를 생성한 사용자가 생성된 객체에 대한 모든 권한을 부여받고, 부여된 권한을 다른 사용자에게 허가할 수도 있다 - 임의 접근통제에 사용되는 SQL 명령어에는 GRANT와 REVOKE가 있다
강제 접근통제 (MAC, Mandatory Access Control)	- 강제 접근통제는 주체와 객체의 등급을 비교하여 접근 권한을 부여하는 방식이다 - 시스템이 접근통제 권한을 지정한다 - 데이트베이스 객체별로 보안 등급을 부여할 수 있고, 사용자별로 인가 등급을 부여할 수 있다 - 주체는 자신보다 보안 등급이 높은 객체에 대해 읽기, 수정, 등록이 모두 불가능하고, 보안 등급이 같은 객체에 대해서는 읽기, 수정, 등록이 가능하고, 보안 등급이 낮은 객체는 읽기가 가능하다
역할기반 접근통제 (RBAC, Role Based Access Control)	- 역할기반 접근통제는 사용자의 역할에 따라 접근 권한을 부여하는 방식이다 - 중앙관리자가 접근 통제 권한을 지정한다 - 임의 접근통제와 강제 접근통제의 단점을 보완하였으며, 다중 프로그래밍 환경에 최적화된 방식이다 - 중앙관리자가 역할마다 권한을 부여하면, 책임과 자질에 따라 역할을 할당받은 사용자들은 역할에 해당하는 권한을 사용할 수 있다

 

 + 강제 접근통제(MAX)의 보안 모델

벨 라파듈라 모델 (Bell-LaPadula Model)	- 군대의 보안 레벨처럼 정보의 기밀성에 따라 상하 관계가 구분된 정보를 보호하기 위해 사용한다 - 보안 취급자의 등급을 기준으로 읽기 권한과 쓰기 권한이 제한된다 - 자신의 보안 레벨 이상의 문서를 작성할 수 없고, 자신의 보안 레벨 이하의 문서를 읽을 수 있다
비바 무결성 모델 (Biba Integrity Model)	- 벨 라파듈라 모델을 보완한 수학적 모델로, 무결성을 보장하는 최초의 모델이다 - 비인가자에 의한 데이터 변형을 방지한다
클락-윌슨 무결성 모델 (Clark-Wilson Integrity Model)	무결성 중심의 상업용 모델로, 사용자가 직접 객체에 접근할 수 없고 프로그램에 의해 접근이 가능한 보안 모델이다
만리장성 모델 (Chiness Wall Model)	서로 이해 충돌 관계에 있는 객체 간의 정보 접근을 통제하는 모델이다

  - 접근통제의 3요소는 접근통제 정책, 접근통제 메커니즘, 접근통제 보안모델이다

 

 1. 접근통제 정책

  : 어떤 주체(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의 변형된 정책으로, 주체의 신분이 아니라 주체가 맡은 역할에 근거하여 객체의 접근을 제한하는 방법이다

 

 2. 접근통제 메커니즘

  : 정의된 접근통제 정책을 구현하는 기술적인 방법으로, 접근통제 목록, 능력 리스트, 보안 등급, 패스워드, 암호화

    등이 있다

  - 접근통제 목록(Access Control List) : 객체를 기준으로 특정 객체에 대해 어떤 주체가 어떤 행위를 할 수

    있는지를 기록한 목록이다

  - 능력 리스트(Capability List) : 주체를 기준으로 주체에게 허가된 자원 및 권한을 기록한 목록이다

  - 보안 등급(Security Level) : 주체나 객체 등에 부여된 보안 속성의 집합으로, 이 등급을 기반으로 접근 승인

    여부가 결정된다

  - 패스워드 : 주체가 자신임을 증명할 때 사용하는 인증 방법이다

  - 암호화 : 데이터를 보낼 때 지정된 수신자 이외에는 내용을 알 수 없도록 평문을 암호문으로 변환하는 것으로,

    무단 도용을 방지하기 위해 주로 사용된다

 

 3. 접근통제 보안 모델

  : 보안 정책을 구현하기 위한 정형화된 모델로, 기밀성 모델, 무결성 모델, 접근통제 모델이 있다

  - 기밀성 모델

   : 군사적인 목적으로 개발된 최초의 수학적 모델로, 기밀성 보장이 최우선인 모델이다

   ㄱ. 군대 시스템 등 특수 환경에서 주로 사용된다

   ㄴ. 제약 조건

    - 단순 보안 규칙 : 주체는 자신보다 높은 등급의 객체를 읽을 수 없다

    - 스타-보안 규칙 : 주체는 자신보다 낮은 등급의 객체에 정보를 쓸 수 없다

    - 강한 스타-보안 규칙 : 주체는 자신과 등급이 다른 객체를 읽거나 쓸 수 없다

Level	단순 보안 규칙	스타-보안 규칙	강한 스타-보안 규칙
	읽기 권한	쓰기 권한	읽기/쓰기 권한
높은 등급	통제	가능	통제
같은 등급	가능	가능	가능
낮은 등급	가능	통제	통제

  - 무결성 모델

   : 기밀성 모델에서 발생하는 불법적인 정보 변경을 방지하기 위해 무결성을 기반으로 개발된 모델이다

   ㄱ. 데이터의 일관성 유지에 중점을 두어 개발되었다

   ㄴ. 기밀성 모델과 동일하게 주체 및 객체의 보안 등급을 기반으로 한다

   ㄷ. 제약 조건

    - 단순 무결성 규칙 : 주체는 자신보다 낮은 등급의 객체를 읽을 수 없다

    - 스타-무결성 규칙 : 주체는 자신보다 높은 등급의 객체에 정보를 쓸 수 없다

Level	단순 무결성 규칙	스타-무결성 규칙
	읽기 권한	쓰기 권한
높은 등급	가능	통제
같은 등급	가능	가능
낮은 등급	통제	가능

  - 접근통제 모델

   : 접근통제 메커니즘을 보안 모델로 발전시킨 것으로, 대표적으로 접근통제 행렬(Access Control Matrix)이 있다

   ㄱ. 접근통제 행렬(Access Control Matrix)

    : 임의적인 접근통제를 관리하기 위한 보안 모델로, 행은 주체, 열은 객체 즉, 행과 열로 주체와 객체의 권한

      유형을 나타낸다

    - 행 : 주체로서 객체에 접근을 시도하는 사용자이다

    - 열 : 객체로서 접근통제가 이뤄지는 테이블, 컬럼, 뷰 등과 같은 데이터베이스의 개체이다

    - 규칙 : 주체가 객체에 대하여 수행하는 입력, 수정, 삭제 등의 데이터베이스에 대한 조작이다

 

 4. 접근통제 조건

  : 접근통제 메커니즘의 취약점을 보완하기 위해 접근통제 정책에 부가하여 적용할 수 있는 조건이다

  - 값 종속 통제(Value-Dependent Control) : 일반적으로는 객체에 저장된 값에 상관없이 접근통제를 동일하게

    허용하지만 객체에 저장된 값에 따라 다르게 접근통제를 허용해야 하는 경우에 사용한다

  - 다중 사용자 통제(Multi-User Control) : 지정된 객체에 다수의 사용자가 동시에 접근을 요구하는 경우에

    사용된다

  - 컨텍스트 기반 통제(Context-Based Control) : 특정 시간, 네트워크 주소, 접근 경로, 인증 수준 등에 근거하여

    접근을 제어하는 방법으로, 다른 보안 정책과 결합하여 보안 시스템의 취약점을 보완할 때 사용된다

 

 5. 감사 추적

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

  - 오류가 발생한 데이터베이스를 복구하거나 부적절한 데이터 조작을 파악하기 위해 사용된다

  - 감사 추적 시 실행한 프로그램, 사용자, 날짜 및 시간, 접근한 데이터의 이전 값 및 이후 값 등이 저장된다

 

∙스토리지

 : 단일 디스크로 처리할 수 없는 대용량의 데이터를 저장하기 위해 서버와 저장장치를 연결하는 기술이다

 

 1. DAS(Direct Attached Storage)

  : 서버와 저장장치를 전용 케이블로 직접 연결하는 방식으로, 일반 가정에서 컴퓨터에 외장하드를 연결하는 것이

    여기에 해당된다

  - 서버에서 저장장치를 관리한다

  - 저장장치를 직접 연결하므로 속도가 빠르고 설치 및 운영이 쉽다

  - 초기 구축 비용 및 유지보수 비용이 저렴하다

  - 직접 연결 방식이므로 다른 서버에서 접근할 수 없고 파일을 공유할 수 없다

  - 확장성 및 유연성이 상대적으로 떨어진다

  - 저장 데이터가 적고 공유가 필요 없는 환경에 적합하다

 2. NAS(Network Attached Storage)

  : 서버와 저장장치를 네트워크를 통해 연결하는 방식이다

  - 별도의 파일 관리 기능이 있는 NAS Storage가 내장된 저장장치를 직접 관리한다

  - Ethernet 스위치를 통해 다른 서버에서도 스토리지에 접근할 수 있어 파일 공유가 가능하고, 장소에 구애받지

    않고 저장장치에 쉽게 접근할 수 있다

  - DAS에 비해 확장성 및 유연성이 우수하다

  - 접속 증가 시 성능이 저하될 수 있다

 3. SAN(Storage Area Network)

  : DAS의 빠른 처리와 NAS의 파일 공유 장점을 혼합한 방식으로, 서버와 저장 장치를 연결하는 전용 네트워크를

    별도로 구성하는 방식이다

  - 광 채널(FC) 스위치를 이용하여 네트워크를 구성한다

  - 광 채널 스위치는 서버나 저장장치를 광케이블로 연결하므로 처리 속도가 빠르다

  - 저장장치를 공유함으로써 여러 개의 저장장치나 백업 장비를 단일화 시킬 수 있다

  - 확장성, 유연성, 가용성이 뛰어나다

  - 높은 트랜잭션 처리에 효과적이나 기존 시스템의 경우 장비의 업그레이드가 필요하고, 초기 설치 시에는 별도의

    네트워크를 구축해야 하므로 비용이 많이 든다 1. 데이터베이스 이중화(DataBase Replication)

---

∎3장 SQL 응용

 

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

 : DB 구조, 데이터 형식, 접근 방식 등 DB를 구축하거나 수정할 목적으로 사용하는 언어이다

 - 번역한 결과가 데이터 사전(Data Dictionary)이라는 특별한 파일에 여러 개의 테이블로서 저장된다

 

 1. CREATE SCHEMA : 스키마를 정의하는 명령문이다

CREATE SCHEMA 스키마명 AUTHORIZATION 사용자_id;   ex) 소유권자의 사용자 ID가 ‘홍길동’인 스키마 ‘대학교’를 정의하는 SQL문 CREATE SCHEMA 대학교 AUTHORIZATION 홍길동;

  - 스키마의 식별을 위해 스키마 이름과 소유권자나 허가권자를 정의한다

 

 2. CREATE DOMAIN : 도메인을 정의하는 명령문이다

CREATE DOMAIN 도메인명 [AS] 데이터_타입          [DEFAULT 기본값]          [CONSTRAINT 제약조건명 CHECK (범위값)];   ex) ‘성별’을 ‘남’ 또는 ‘여’와 같이 정해진 1개의 문자로 표현되는 도메인 SEX를 정의하는 SQL문 CREATE DOMAIN SEX CHAR(1) //정의된 도메인은 이름이 ‘SEX’이며, 문자형이고 크기는 1자이다          DEFAULT ‘남’ //도메인 SEX를 지정한 속성의 기본값은 ‘남’이다          CONSTRAINT VALID-SEX CHECK(VALUE IN (‘남’, ‘여’)); //SEX를 지정한 속성에는 ‘남’, ‘여’ 중 하나의 값만 저장할 수 있다

  - 임의의 속성에서 취할 수 있는 값의 범위가 SQL에서 지원하는 전체 데이터 타입의 값이 아니고 일부분일 때,

    사용자는 그 값의 범위를 도메인으로 정의할 수 있다

  - 정의된 도메인명은 일반적인 데이터 타입처럼 사용한다

 

  + SQL에서 지원하는 기본 데이터 타입

   - 정수(Integer) : INTEGER(4Byte 정수), SMALLINT(2Byte 정수)

   - 실수(Float) : FLOAT, REAL, DOUBLE PRECISION

   - 형식화된 숫자 : DEC(i, j), 단 i : 전체 자리수, j : 소수부 자리수

   - 고정길이 문자 : CHAR(n), CHARACTER VARYING(n), 단 n : 문자수

   - 가변길이 문자 : VARCHAR(n), CHARACTER VARYING(n), 단 n : 최대 문자수

   - 고정길이 비트열(Bit String) : BIT(n)

   - 가변길이 비트열 : VARBIT(n)

   - 날짜 : DATE

   - 시간 : TIME

 

 3. CREATE TABLE : 테이블을 정의하는 명령문이다

CREATE TABLE 테이블명          (속성명 데이터_타입 [DEFAULT 기본값] [NOT NULL], ...          [, PRIMARY KEY(기본키_속성명, ...)]          [, UNIQUE(대체키_속성명, ...)]          [, FOREIGN KEY(외래키_속성명, ...)]                  [REFERENCES 참조테이블(기본키_속성명, ...)]                  [ON DELETE 옵션]                  [ON UPDATE 옵션]          [, CONSTRAINT 제약조건명] [CHECK (조건식)];   ex) ‘이름’, ‘학번’, ‘전공’, ‘성별’, ‘생년월일’로 구성된 <학생> 테이블을 정의하는 SQL문  - ‘이름’은 NULL이 올 수 없고, ‘학번’은 기본키이다  - ‘전공’은 <학과> 테이블의 ‘학과코드’를 참조하는 외래키로 사용된다  - <학과> 테이블에서 삭제가 일어나면 관련된 튜플들의 전공 값을 NULL로 만든다  - <학과> 테이블에서 ‘학과코드’가 변경되면 전공 값도 같은 값으로 변경한다  - ‘생년월일’은 1980-01-01 이후의 데이터만 저장할 수 있다  - 제약 조건의 이름은 ‘생년월일제약’으로 한다  - 각 속성의 데이터 타입은 적당하게 지정한다 단, ‘성별’은 도메인 ‘SEX’를 사용한다   CREATE TABLE 학생          (이름 VARCHAR(15) NOT NULL,          학번 CHAR(8),          전공 CHAR(5),          성별 SEX,          생년월일 DATE,          PRIMARY KEY(학번),          FOREIGN KEY(전공) REFERENCES 학과(학과코드)                ON DELETE SET NULL                ON UPDATE CASCADE,          CONSTRAINT 생년월일제약                CHECK(생년월일>=‘1980-01-01’));

  - 기본 테이블에 포함될 모든 속성에 대하여 속성명과 그 속성의 데이터 타입, 기본값, NOT NULL 여부를 지정

  - PRIMARY KEY : 기본키로 사용할 속성 또는 속성의 집합을 지정한다

  - UNIQUE : 대체키로 사용할 속성 또는 속성의 집합을 지정하는 것으로 UNIQUE로 지정한 속성은 중복된 값을

    가질 수 없다

  - FOREIGN KEY ~ REFERENCES ~

   ㄱ. 참조할 다른 테이블과 그 테이블을 참조할 때 사용할 외래키 속성을 지정한다

   ㄴ. 외래키가 지정되면 참조 무결성의 CASCADE 법칙이 적용된다

   ㄷ. ON DELETE 옵션 : 참조 테이블의 튜플이 삭제되었을 때 기본 테이블에 취해야 할 사항을 지정한다

                          옵션에는 NO ACTION, CASCADE, SET NULL, SET DEFAULT가 있다

   ㄹ. ON UPDATE 옵션 : 참조 테이블의 참조 속성 값이 변경되었을 때 기본 테이블에 취해야 할 사항을 지정한다

                          옵션에는 NO ACTION, CASCADE, SET NULL, SET DEFAULT가 있다

    - NO ACTION : 참조 테이블에 변화가 있어도 기본 테이블에는 아무런 조치를 위하지 않는다

    - CASCADE : 참조 테이블의 튜플이 삭제되면 기본 테이블의 관련 튜플도 모두 삭제되고, 속성이 변경되면 관련

                  튜플의 속성 값도 모두 변경된다

    - SET NULL : 참조 테이블에 변화가 있으면 기본 테이블의 관련 튜플의 속성 값을 NULL로 변경한다

    - SET DEFAULT : 참조 테이블에 변화가 있으면 기본 테이블의 관련 튜플의 속성값을 기본값으로 변경한다

  - CONSTRAINT : 제약 조건의 이름을 지정한다 이름을 지정할 필요가 없으면 CHECK절만 사용하여 속성 값에

                    대한 제약 조건을 명시한다

 - CHECK : 속성 값에 대한 제약 조건을 정의한다

 

 + 다른 테이블을 이용한 테이블 정의

CREATE TABLE 신규테이블명 AS SELECT 속성명[, 속성명, ...] FROM 기존테이블명;

  - 기존 테이블에서 추출되는 속성의 데이터 타입과 길이는 신규 테이블에 그대로 적용됩니다

  - 기존 테이블의 NOT NULL의 정의는 신규 테이블에 그대로 적용됩니다

  - 기존 테이블의 제약 조건은 신규 테이블에 적용되지 않으므로 신규 테이블을 정의한 후 ALTER TABLE 명령을

    이용해 제약 조건을 추가해야 합니다

  - 기존 테이블의 일부 속성만 신규 테이블로 생성할 수 있으며, 기존 테이블의 모든 속성을 신규 테이블로 생성할

    때는 속성명 부분에 ‘*’를 입력합니다

 

 4. CREATE VIEW : 뷰를 정의하는 명령문이다

CREATE VIEW 뷰명[(속성명[, 속성명, ...])] AS SELECTION문;   ex) <고객> 테이블에서 ‘주소’가 ‘안산시’인 고객들의 ‘성명’과 ‘전화번호’를 ‘안산고객’이라는 뷰로 정의 CREATE VIEW 안산고객(성명, 전화번호) AS SELECTION 성명, 전화번호 FROM 고객 WHERE 주소 = ‘안산시’;

  - SELECT문을 서브 쿼리로 사용하여 SELECT문의 결과로서 뷰를 생성한다

  - 서브 쿼리인 SELECT문에는 UNION이나 ORDER BY절을 사용할 수 없다

  - 속성명을 기술하지 않으면 SELECT문의 속성명이 자동으로 사용된다

 

 5. CREATE INDEX : 인덱스를 정의하는 명령문이다

CREATE [UNIQUE] INDEX 인덱스명 ON 테이블명(속성명 [ASC | DESC] [, 속성명 [ASC | DESC]]) [CLUSTER];   ex) <고객> 테이블에서 UNIQUE한 특성을 갖는 ‘고객번호’ 속성에 대해 내림차순으로 정렬하여 ‘고객번호_idx’     라는 이름으로 인덱스를 정의 CREATE UNIQUE INDEX 고객번호_idx ON 고객(고객번호 DESC);

  - UNIQUE : 사용(중복 값이 없는 속성으로 인덱스를 생성), 생략(중복 값을 허용하는 속성으로 인덱스를 생성)

  - 정렬 여부 지정 : ASC(오름차순), DESC(내림차순), 생략(오름차순)

  - CLUSTER : 사용하면 인덱스가 클러스터드 인덱스로 설정됨

 

6. ALTER TABLE : 테이블에 대한 정의를 변경하는 명령문이다

ALTER TABLE 테이블명 ADD 속성명 데이터_타입 [DEFAULT ‘기본값’]; ALTER TABLE 테이블명 ALTER 속성명 [SET DEFAULT ‘기본값’]; ALTER TABLE 테이블명 DROP COLUMN 속성명 [CASCADE];   ex) <학생> 테이블의 ‘학번’ 필드의 데이터 타입과 크기를 VARCHAR(10)로 하고 NULL이 입력되지 않도록 변경 ALTER TABLE 학생 ALTER 학번 VARCHAR(10) NOT NULL;

  - ADD : 새로운 속성(열)을 추가할 때 사용한다

  - ALTER : 특정 속성의 Default 값을 변경할 때 사용한다

  - DROP COLUMN : 특정 속성을 삭제할 때 사용한다

 

 7. DROP : 스키마, 도메인, 기본 테이블, 뷰 테이블, 인덱스, 제약 조건 등을 제거하는 명령문이다

DROP SCHEMA 스키마명 [CASCADE | RESTRICT]; DROP DOMAIN 도메인명 [CASCADE | RESTRICT]; DROP TABLE 테이블명 [CASCADE | RESTRICT]; DROP VIEW 뷰명 [CASCADE | RESTRICT]; DROP INDEX 인덱스명 [CASCADE | RESTRICT]; DROP CONSTRAINT 제약조건명 [CASCADE | RESTRICT];   ex) <학생> 테이블을 제거하되, <학생> 테이블을 참조하는 모든 데이터를 함께 제거 DROP TABLE 학생 CASCADE;

  - CASCADE : 제거할 요소를 참조하는 다른 모든 개체를 함께 제거한다 즉, 주 테이블의 데이터 제거 시 각

    외래키와 관계를 맺고 있는 모든 데이터를 제거하는 참조 무결성 제약 조건을 설정하기 위해 사용된다

  - RESTRICT : 다른 개체가 제거할 요소를 참조중일 때는 제거를 취소한다

 

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

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

 - 데이터베이스 관리자(DBA)가 데이터 관리를 목적으로 사용한다

 - 논리적, 물리적 데이터 구조 정의

 

 1. GRANT / REVOKE

  : 데이터베이스 관리자가 데이터베이스 사용자에게 권한을 부여하거나 취소하기 위한 명령어

  - GRANT : 권한 부여를 위한 명령어

  - REVOKE : 권한 취소를 위한 명령어

 

  - 사용자등급 지정 및 해제

GRANT 사용자등급 TO 사용자_ID_리스트 [IDENTIFIED BY 암호]; REVOKE 사용자등급 FROM 사용자_ID_리스트;   ex) 사용자 ID가 ”NABI“인 사람에게 데이터베이스 및 테이블을 생성할 수 있는 권한을 부여하는 SQL문 GRANT RESOURCE TO NABI;

  ㄱ. 사용자등급 : DAB(데이터베이스 관리자), RESOURCE(데이터베이스 및 테이블 생성 가능자), CONNECT(사용자)

  - 테이블 및 속성에 대한 권한 부여 및 취소

GRANT 권한_리스트 ON 개체 TO 사용자 [WITH GRANT OPTION]; REVOKE [GRANT OPTION FOR] 권한_리스트 ON 개체 FROM 사용자 [CASCADE];   ex) 사용자 ID가 “NABI”인 사람에게 <고객> 테이블에 대한 모든 권한과 다른 사람에게 권한을 부여할 수     있는 권한까지 부여하는 SQL문 GRANT ALL ON 고객 TO NABI WITH GRANT OPION;

   ㄱ. 권한 종류 : ALL, SELECT, INSERT, DELETE, UPDATE(갱신), ALTER 등

   ㄴ. WITH GRANT OPTION : 부여받은 권한을 다른 사용자에게 다시 부여할 수 있는 권한을 부여함

   ㄷ. GRANT OPTION FOR : 다른 사용자에게 권한을 부여할 수 있는 권한을 취소함

   ㄹ. CASCADE : 권한 취소 시 권한을 부여받았던 사용자가 다른 사용자에게 부여한 권한도 연쇄적으로 취소함

 

 2. COMMIT

  : 트랜잭션이 성공적으로 끝나면 데이터베이스가 새로운 일관성(Consistency) 상태를 가지기 위해 변경된 모든

    내용을 데이터베이스에 반영하여야 하는데, 이때 사용하는 명령이 COMMIT이다

ex) <사원> 테이블에서 ‘사원번호’가 40인 사원의 정보를 삭제한 후 COMMIT을 수행 DELETE FROM 사원 WHERE 사원번호 = 40; COMMIT;

  - COMMIT 명령을 실행하지 않아도 DML문이 성공적으로 완료되면 자동으로 COMMIT되고, DML이 실패하면

    자동으로 ROLLBACK이 되도록 Auto Commit 기능을 설정할 수 있다

    이 때, 트랜잭션의 수행이 실패하여 ROLLBACK이 실행된 상태를 철회(Aborted)라고 한다

 

 3. SAVEPOINT

  : 트랜잭션 내에 ROLLBACK 할 위치인 저장점을 지정하는 명령어

ex) SAVEPOINT ‘S1’을 설정하고 ‘사원번호’가 20인 사원의 정보를 삭제 SAVEPOINT S1; DELETE FROM 사원 WHERE 사원번호 = 20;

  - 저장점을 지정할 때는 이름을 부여하며, ROLLBACK 시 지정된 저장점까지의 트랜잭션 처리 내용이 취소된다

 

 4. ROLLBACK

  : 아직 COMMIT되지 않은 변경된 모든 내용들을 취소하고 데이터베이스를 이전 상태로 되돌리는 명령어

ex) SAVEPOINT ‘S1’까지 ROLLBACK을 수행 ROLLBACK TO S1;

  - 트랜잭션 전체가 성공적으로 끝나지 못하면 일부 변경된 내용만 데이터베이스에 반영되는 비일관성

    (Inconsistency)인 상태를 가질 수 있기 때문에 일부분만 완료된 트랜잭션은 롤백(Rollback)되어야 한다

 

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

 : 데이터베이스 사용자가 응용 프로그램이나 질의어를 통해 저장된 데이터를 실질적으로 관리하는데 사용되는 언어

 - 데이터베이스 사용자와 데이터베이스 관리 시스템 간의 인터페이스를 제공한다

 

 1. 삽입문(INSERT INTO~ VALUES~) : 기본 테이블에 새로운 튜플을 삽입할 때 사용한다

INSERT INTO 테이블명([속성명1, 속성명2, ...]) VALUES (데이터1, 데이터2, ...);   ex) <사원> 테이블에 (이름 – 홍승현, 부서 – 인터넷)을 삽입하시오 INSERT INTO 사원(이름, 부서) VALUES (‘홍승현’, ‘인터넷’);   ex) <사원> 테이블에 있는 편집부의 모든 튜플을 편집부원(이름, 생일, 주소, 기본급) 테이블에 삽입하시오 INSERT INTO 편집부원(이름, 생일, 주소, 기본급) SELECT 이름, 생일, 주소, 기본급 FROM 사원 WHERE 부서 = ‘편집’;

  - 대응하는 속성과 데이터는 개수와 데이터 유형이 일치해야 한다

  - 기본 테이블의 모든 속성을 사용할 때는 속성명을 생략할 수 있다

  - SELECT문을 사용하여 다른 테이블의 검색 결과를 삽입할 수 있다

 

 2. 삭제문(DELETE~ FROM~ WHERE~) : 기본 테이블에 있는 튜플들 중에서 특정 튜플(행)을 삭제할 때 사용한다  

DELETE FROM 테이블명 [WHERE 조건];   ex) <사원> 테이블에서 “임꺽정”에 대한 튜플을 삭제하시오 DELETE FROM 사원 WHERE 이름 = ‘임꺽정’;   ex) <사원> 테이블의 모든 레코드를 삭제하시오 DELETE FROM 사원;

  - 모든 레코드를 삭제할 때는 WHERE절을 생략한다

  - 모든 레코드를 삭제하더라도 테이블 구조는 남아 있기 때문에 디스크에서 테이플을 완전히 제거하는 DROP과는

    다르다

 

 3. 갱신문(UPDATE~ SET~ WHERE~) : 기본 테이블에 있는 튜플들 중에서 특정 튜플의 내용을 변경할 때 사용한다

UPDATE 테이블명 SET 속성명 = 데이터[, 속성명=데이터, ...] [WHERE 조건];   ex) <사원> 테이블에서 “홍길동”의 “주소”를 “수색동”으로 수정하시오 UPDATE 사원 SET 주소 = ‘수색동’ WHERE 이름 = ‘홍길동’;   ex) <사원> 테이블에서 “황진이”의 “부서”를 “기획부”로 변경하고 “기본급”을 5만원 인상시키시오 UPDATE 사원 SET 부서 = ‘기획’, 기본급 = 기본급 + 5 WHERE 이름 = ‘황진이’;

 

∙DML – SELECT

 1. 일반 형식  

SELECT [PREDICATE] [테이블명.]속성명 [AS 별칭][, [테이블명.]속성명, ...] [, 그룹함수(속성명) [AS 별칭]] [, Window함수 OVER (PARTITION BY 속성명1, 속성명2, ...                ORDER BY 속성명3, 속성명4, ...)] FROM 테이블명[, 테이블명, ...] [WHERE 조건] [GROUP BY 속성명, 속성명, ...] [HAVING 조건] [ORDER BY 속성명 [ASC | DESC]];   UNION | UNION ALL | INTERSECT | EXCEPT

  - SELECT절

   ㄱ. PREDICATE : 불러올 튜플 수를 제한할 명령어를 기술한다

     - ALL : 모든 튜플을 검색할 때 지정하는 것으로, 주로 생략한다

     - DISTINCT : 중복된 튜플이 있으면 그 중 첫 번째 한 개만 검색한다

     - DISTINCTROW : 중복된 튜플을 제거하고 한 개만 검색하지만 선택된 속성의 값이 아닌, 튜플 전체를

                        대상으로 한다

   ㄴ. 속성명 : 검색하여 불러올 속성(열) 또는 속성을 이용한 수식을 지정한다

    - 기본 테이블을 구성하는 모든 속성을 지정할 때는 ‘*’를 기술한다

    - 두 개 이상의 테이블을 대상으로 검색할 때는 ‘테이블명.속성명’으로 표현한다

   ㄷ. AS : 속성 및 연산의 이름을 다른 제목으로 표시하기 위해 사용된다

   ㄹ. 그룹함수 : GROUP BY절에 지정된 그룹별로 속성의 값을 집계할 함수를 기술한다

   ㅁ. WINDOW 함수 : GROUP BY절을 이용하지 않고 속성의 값을 집계할 함수를 기술한다

    - PARTITION BY : WINDOW 함수가 적용될 범위로 사용할 속성을 지정한다

    - ORDER BY : PARTITION 안에서 정렬 기준으로 사용할 속성을 지정한다

  - FROM절 : 질의에 의해 검색될 데이터들을 포함하는 테이블명을 기술한다

  - WHERE절 : 검색할 조건을 기술한다

  - GROUP BY절 : 특정 속성을 기준으로 그룹화하여 검색할 때 사용한다 일반적으로 GROUP BY절은 그룹 함수와

                   함께 사용한다

  - HAVING절 : GROUP BY와 함께 사용되며, 그룹에 대한 조건을 지정한다

  - ORDER BY절 : 특정 속성을 기준으로 정렬하여 검색할 때 사용한다

   ㄱ. 속성명 : 정렬의 기준이 되는 속성명을 기술한다

   ㄴ. [ASC | DESC] : 정렬 방식

  - 집합 연산자 : 2개 이상의 테이블의 데이터를 하나로 통합한다

   ㄱ. 두 개의 SELECT문에 기술한 속성들은 개수와 데이터 유형이 서로 동일해야 한다   

UNION (합집합)	- 두 SELECT문의 조회 결과를 통합하여 모두 출력한다 - 중복된 행은 한 번만 출력한다
UNION ALL (합집합)	- 두 SELECT문의 조회 결과를 통합하여 모두 출력한다 - 중복된 행도 그대로 출력한다
INTERSECT (교집합)	두 SELECT문의 조회 결과 중 공통된 행만 출력한다
EXCEPT (차집합)	첫 번째 SELECT문의 조회 결과에서 두 번째 SELECT문의 조회 결과를 제외한 행을 출력한다

 

 + 그룹 함수 / WINDOW 함수

  - 그룹 함수

   : GROUP BY절에 지정된 그룹별로 속성의 값을 집계할 때 사용됩니다

   ㄱ. COUNT(속성명) : 그룹별 튜플 수를 구하는 함수

   ㄴ. SUM(속성명) : 그룹별 합계를 구하는 함수

   ㄷ. AVG(속성명) : 그룹별 평균을 구하는 함수

   ㄹ. MAX(속성명) : 그룹별 최대값을 구하는 함수

   ㅁ. MIN(속성명) : 그룹별 최소값을 구하는 함수

   ㅂ. STDDEV(속성명) : 그룹별 표준편차를 구하는 함수

   ㅅ. VARIANCE(속성명) : 그룹별 분산을 구하는 함수

   ㅇ. ROLLUP(속성명, 속성명, ...)

    - 인수로 주어진 속성을 대상으로 그룹별 소계를 구하는 함수

    - 속성의 개수가 n개이면, n+1 레벨까지, 하위 레벨에서 상위 레벨 순으로 데이터가 집계됩니다

   ㅈ. CUBE(속성명, 속성명, ...)

    - ROLLUP과 유사한 형태이나 CUBE는 인수로 주어진 속성을 대상으로 모든 조합의 그룹별 소계를 구한다

    - 속성의 개수가 n개이면, 2 레벨까지, 상위 레벨에서 하위 레벨 순으로 데이터가 집계됩니다

  - WINDOW 함수

   ㄱ. GROUP BY절을 이용하지 않고 함수의 인수로 지정한 속성을 범위로 하여 속성의 값을 집계한다

   ㄴ. 함수의 인수로 지정한 속성이 대상 레코드의 범위가 되는데, 이를 윈도우(WINDOW)라고 부른다

   ㄷ. ROW_NUMBER() : 윈도우별로 각 레코드에 대한 일련 번호를 반환한다

   ㄹ. RANK() : 윈도우별로 순위를 반환하며, 공동 순위를 반영한다

   ㅁ. DENSE_RANK() : 윈도우별로 순위를 반환하며, 공동 순위를 무시하고 순위를 부여한다

 

 2. 기본 검색 : SELECT 절에 원하는 속성을 지정하여 검색한다

 3. 조건 지정 검색 : WHERE 절에 조건을 지정하여 조건에 만족하는 튜플만 검색한다

 4. 정렬 검색 : ORDER BY 절에 특정 속성을 지정하여 지정된 속성으로 자료를 정렬하여 검색한다

 5. 하위 질의 : 조건절에 주어진 질의를 먼저 수행하여 그 검색 결과를 조건절의 피연산자로 사용한다

 6. 복수 테이블 검색 : 여러 테이블을 대상으로 검색을 수행한다

 7. WINDOW 함수 이용 검색 : GROUP BY절을 이용하지 않고 함수의 인수로 지정한 속성을 범위로 하여 속성의

                              값을 집계한다

 8. 그룹 지정 검색 : GROUP BY절에 지정한 속성을 기준으로 자료를 그룹화하여 검색한다

 9. 집합 연산자를 이용한 통합 질의 : 집합 연산자를 사용하여 2개 이상의 테이블의 데이터를 하나로 통합한다

 

∙DML – JOIN

 : 2개의 테이블에 대해 연관된 튜플들을 결합하여, 하나의 새로운 릴레이션을 반환한다

 - 크게 INNER JOIN과 OUTER JOIN으로 구분된다

 - 일반적으로 FROM절에 기술하지만, 릴레이션이 사용되는 어느 곳에서나 사용할 수 있다

 

 1. INNER JOIN

  - 조건이 없는 INNER JOIN을 수행하면 CROSS JOIN과 동일한 결과를 얻을 수 있다

  - EQUI JOIN

   ㄱ. JOIN 대상 테이블에서 공통 속성을 기준으로 ‘=’(equal) 비교에 의해 같은 값을 가지는 행을 연결하여 결과를

       생성하는 JOIN 방법이다

   ㄴ. JOIN 조건이 ‘=’일 때 동일한 속성이 두 번 나타나게 되는데, 이 중 중복된 속성을 제거하여 같은 속성을 한 번

       만 표기하는 방법을 NATURAL JOIN이라고 한다

   ㄷ. 연결 고리가 되는 공통 속성을 JOIN 속성이라고 한다

   ㄹ. WHERE절을 이용한 EQUI JOIN의 표기 형식

SELECT [테이블명1.]속성명, [테이블명2.]속성명, ... FROM 테이블명1, 테이블명2, ... WHERE 테이블명1.속성명 = 테이블명2.속성명;

   ㅁ. NATURAL JOIN절을 이용한 EQUI JOIN의 표기 형식

SELECT [테이블명1.]속성명, [테이블명2.]속성명, ... FROM 테이블명1 NATURAL JOIN 테이블명2;

   ㅂ. JOIN ~ USING절을 이용한 EQUI JOIN의 표기 형식

SELECT [테이블명1.]속성명, [테이블명2.]속성명, ... FROM 테이블명1 JOIN 테이블명2 USING(속성명);

  - NON-EQUI JOIN

   ㄱ. NON-EQUI JOIN은 JOIN 조건에 ‘=’ 조건이 아닌 나머지 비교 연산자, 즉 >, <, <>, >=, <= 연산자를 사용하는

       JOIN 방법이다

   ㄴ. 표기 형식

SELECT [테이블명1.]속성명, [테이블명2.]속성명, ... FROM 테이블명1, 테이블명2, ... WHERE (NON-EQUI JOIN 조건);

 

 2. OUTER JOIN

  : 릴레이션에서 JOIN 조건에 만족하지 않는 튜플도 결과로 출력하기 위한 JOIN 방법

  - LEFT OUTER JOIN

   ㄱ. INNER JOIN의 결과를 구한 후, 우측 항 릴레이션의 어떤 튜플과도 맞지 않는 좌측 항의 릴레이션에 있는

       튜플들에 NULL 값을 붙여서 INNER JOIN의 결과에 추가한다

   ㄴ. 표기 형식

SELECT [테이블명1.]속성명, [테이블명2.]속성명, ... FROM 테이블명1 LEFT OUTER JOIN 테이블명2 ON 테이블명1.속성명 = 테이블명2.속성명;   SELECT [테이블명1.]속성명, [테이블명2.]속성명, ... FROM 테이블명1, 테이블명2 WHERE 테이블명1.속성명 = 테이블명2.속성명(+);

  - RIGHT OUTER JOIN

   ㄱ. INNER JOIN의 결과를 구한 후, 좌측 항 릴레이션의 어떤 튜플과도 맞지 않는 우측 항의 릴레이션에 있는

       튜플들에 NULL 값을 붙여서 INNER JOIN의 결과에 추가한다

   ㄴ. 표기 형식

SELECT [테이블명1.]속성명, [테이블명2.]속성명, ... FROM 테이블명1 RIGHT OUTER JOIN 테이블명2 ON 테이블명1.속성명 = 테이블명2.속성명;   SELECT [테이블명1.]속성명, [테이블명2.]속성명, ... FROM 테이블명1, 테이블명2 WHERE 테이블명1.속성명(+) = 테이블명2.속성명;

  - FULL OUTER JOIN

   ㄱ. LEFT OUTER JOIN과 RIGHT OUTER JOIN을 합쳐 놓은 것이다

   ㄴ. INNER JOIN의 결과를 구한 후, 좌측 항의 릴레이션의 튜플들에 대해 우측 항의 릴레이션의 어떤 튜플과도

      맞지 않는 튜플들에 NULL 값을 붙여서 INNER JOIN의 결과에 추가한다 그리고 유사하게 우측 항의 릴레이션의

      튜플들에 대해 좌측 항의 릴레이션의 어떤 튜플과도 맞지 않는 튜플들에 NULL 값을 붙여서 INNER JOIN의

      결과에 추가한다

   ㄷ. 표기 형식

SELECT [테이블명1.]속성명, [테이블명2.]속성명, ... FROM 테이블명1 FULL OUTER JOIN 테이블명2 ON 테이블명1.속성명 = 테이블명2.속성명;

 

 3. SELF JOIN

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

  - 표기 형식

SELECT [별칭1.]속성명, [별칭1.]속성명, ... FROM 테이블명1 [AS] 별칭1 JOIN 테이블명1 [AS] 별칭2 ON 별칭1.속성명 = 별칭2.속성명;   SELECT [별칭1.]속성명, [별칭1.]속성명, ... FROM 테이블명1 [AS] 별칭1, 테이블명1 [AS] 별칭2 WHERE 별칭1.속성명 = 별칭2.속성명;