1. 데이터베이스 설계 (중요도: A)
사용자 요구를 분석하여 컴퓨터에 저장할 수 있는 데이터베이스 구조로 변형 후 특정 DBMS로 구현하는 것을 데이터베이스 설계라고 한다.
1.1. 데이터베이스 설계 시 고려사항
◍ 무결성(정확성): 삽입, 삭제, 갱신 등의 연산 후에도 DB에 저장된 데이터가 정해진 제약 조건을 항상 만족해야 한다.
◍ 일관성: DB에 저장된 데이터들 사이 또는 특정 쿼리에 대한 응답이 처음부터 끝까지 변함없이 일정해야 한다.
◍ 회복: 시스템에 장애가 발생했을 때 발생 직전 상태로 복구할 수 있어야 한다.
◍ 보안: 데이터 노출, 변경, 손실로부터 보호할 수 있어야 한다.
◍ 효율성: 응답시간의 단축, 시스템의 생산성, 저장 공간의 최적화 등이 가능해야 한다.
◍데이터베이스 확장: DB 운영에 영향을 주지 않으면서 지속적으로 데이터를 추가할 수 있어야 한다.
1.2. 데이터베이스 설계 프로세스
① 요구 조건 분석
데이터베이스를 사용할 사람들로부터 필요한 용도를 파악하여 명세서 작성하는 과정이다. 데이터베이스 사용자에 따른 수행 업무와 필요한 데이터의 종류, 용도, 처리 형태, 흐름, 제약 조건 등을 수집한다. 수집된 정보를 바탕으로 요구 조건 명세서를 작성한다.
② 개념적 설계(정보 모델링, 개념화)
정보의 구조를 얻기 위하여 현실 세계의 무한성과 계속성을 이해하고, 다른 사람과 통신하기 위하여 현실 세계에 대한 인식을 추상적 개념으로 표현하는 과정이다. 개념 스키마 모델링과 트랜잭션 모델링을 병행하여 수행한다. 요구 분석 단계에서 나온 결과인 요구 조건 명세를 DBMS에 독립적인 E-R 다이어그램으로 작성하고, 개념 스키마를 설계한다.
③ 논리적 설계(데이터 모델링)
현실 세계에서 발생하는 자료는 컴퓨터가 이해하고 처리할 수 있는 물리적 저장장치에 변환하여 저장한다. 논리적 설계는 이러한 변환 과정에서 특정 DBMS가 지원하는 논리적 자료 구조로 변환시키는 과정이다.
‘개념 세계의 데이터’를 데이터 타입과 논리적 구조(타입들간의 관계 )의 데이터로 모델화한다. 개념적 설계가 개념 스키마를 설계하는 과정이라면, 논리적 설계는 개념 스키마를 평가 및 정제하고 DBMS에 따라 서로 다른 논리적 스키마를 설계하는 과정이다.
논리적 설계 단계에서는 트랜잭션의 인터페이스를 설계하고, 관계형 데이터베이스인 경우 테이블을 설계한다.
④ 물리적 설계(데이터 구조화)
물리적 설계란 논리적 설계 단계에서 논리적 구조로 표현된 데이터를 디스크 등의 물리적 저장장치에 저장할 수 있는 물리적 구조의 데이터로 변환하는 과정이다.
물리적 설계는 다양한 데이터베이스 응용에 대한 처리 성능을 확보해야 한다. 때문에 원활한 처리 성능의 확보를 위해 파일의 저장 구조 및 액세스 경로를 결정하며, 저장 레코드의 형식, 순서, 접근 경로 등의 정보를 사용하여 데이터가 컴퓨터에 저장되는 방법을 묘사한다.
⑤ 구현
논리적 설계 단계와 물리적 설계 단계에서 도출된 데이터베이스 스키마를 파일로 생성하는 과정이다. 사용하려는 DBMS의 DDL을 이용하여 데이터베이스 스키마를 기술한 후 컴파일하여 데이터베이스 파일을 생성한다.
구현 과정에서는 생성된 빈 DB 파일에 데이터를 입력하고, 응용 프로그램을 위한 트랜잭션을 작성하고, DB 접근을 위한 응용 프로그램을 작성한다.
2. 데이터 모델의 개념 (중요도: B)
2.1. 데이터 모델
데이터 모델은 현실 세계의 정보를 컴퓨터로 표현하기 위해 단순화, 추상화를 거쳐 체계적으로 표현한 개념적 모형이다. 데이터, 데이터 간 관계, 데이터의 의미 및 일관성, 제약 조건 등을 기술하기 위한 개념적 도구 모임이며, 현실 세계를 DB에 표현하는 중간 과정이다.
즉, 데이터 모델은 데이터의 구조(Schema)를 논리적으로 표현하기 위해 사용되는 지능적 도구를 말한다.
2.2. 데이터 모델의 구성 요소
◍ 개체(Entity): 데이터베이스에 표현하려는 것, 사람이 생각하는 개념이나 정보 단위 같은 현실 세계의 대상체이다.
◍ 속성(Attribute): 데이터의 가장 작은 논리적 단위, 파일 구조상의 데이터 항목 또는 데이터 필드에 해당한다.
◍ 관계(Relationship): 개체 간의 관계 또는 속성 간의 논리적인 연결을 의미한다.
2.3. 데이터 모델링의 3단계 (개념 → 논리 → 물리)
1) 개념적 데이터 모델(정보 모델)
현실 세계에 대한 이해를 돕기 위해 현실 세계 인식을 추상적 개념으로 표현하는 과정이다. 속성들로 기술된 개체 타입과 이 개체 타입들 간 관계를 이용하여 현실 세계를 표현한다. 정보 모델이라고도 부르며, 대표적으로는 E-R 모델이 있다.
2) 논리적 데이터 모델
개념적 모델링 과정에서 얻은 개념적 구조를 컴퓨터가 이해하고 처리할 수 있도록 변환하는 과정이다. 필드로 기술된 데이터 타입과 이 타입들 간의 관계를 이용하여 현실 세계를 표현한다. 현실 세계를 컴퓨터 세계로 표현하는 과정이기때문에, 단순히 데이터 모델이라고 하면 논리적 데이터 모델을 의미한다.
일반적으로 하나의 DBMS는 특정 논리적 데이터 모델을 하나만 선정하여 사용한다. 논리적 데이터 모델은 데이터 간 관계를 어떻게 표현하느냐에 따라 관계 모델, 계층 모델, 네트워크 모델로 구분한다.
3) 물리적 데이터 모델
물리 데이터 모델이란 논리 데이터 모델을 DBMS의 특성 및 성능을 고려하여 구체화시킨 모델을 말한다. 물리 데이터 모델은 DBMS 선정 이후에 해당 DBMS 상에서 최상의 성능을 보장하도록 논리 데이터 모델에서 저장하는 데이터의 물리적 특성을 최대한 반영하여 설계하고 이를 관리한다.
즉, 물리적 데이터 모델은 데이터베이스가 물리적으로 컴퓨터에 어떻게 저장될 것인가를 정의하는 물리적 스키마를 규정하는 것이다.
물리적 데이터 모델링 단계에서는 트랜잭션 세부사항을 설계하고, 테이블, 칼럼 등으로 표현되는 물리적인 저장 구조와 사용될 저장 장치, 자료를 추출하기 위해 사용될 접근 방법 등을 정한다.
2.4. 논리적 데이터 모델의 품질 검증
▶ 완성된 논리 데이터 모델이 적합한지 확인하고 품질 검증하는 단계이다. 논리 데이터 모델 품질 기준에 따라 개체, 속성, 관계, 식별자, 모델 전반 등에 대해 검토 체크리스트를 작성하고, 체크리스트의 각 항목을 확인하는 방식으로 검증한다.
항목으로는 개체 품질 검증, 속성 품질 검증, 관계 품질 검증, 식별자 품질 검증, 전반적 품질 검증으로 나뉜다.
2.5. 데이터 모델에 표시할 요소
◍ 구조(Structure): 논리적으로 표현된 개체 타입들 간의 관계로, 데이터 구조의 정의적 성질을 표현한다.
◍ 연산(Operation): DB에 저장된 실제 데이터를 처리하는 작업에 대한 명세로서 DB를 조작하는 기본적 도구이다.
◍ 제약 조건(Constraint): DB에 저장될 수 있는 실제 데이터의 논리적 제약 조건이다.
3. 데이터 모델의 구성 요소: 개체(Entity) (중요도: A)
개체란 데이터베이스에 표현하려는 것, 사람이 생각하는 개념이나 정보 단위 같은 현실 세계의 대상체를 말한다. 개체는 실세계에 독립적으로 존재하는 유/무형의 정보로서, 서로 연관된 몇 개의 속성으로 구성된다.
개체는 파일 시스템의 레코드에 대응하는 것으로, 어떤 정보를 제공하는 역할을 수행한다. 영속적으로 존재하는 개체의 집합이고, 독립적으로 존재하거나 그 자체로서도 구별이 가능하다. 또한 다른 개체와 하나 이상의 관계(Relationship)가 있다.
개체는 유일한 식별자에 의해 식별이 가능하며, 업무 프로세스에 의해 이용된다.
| 학번 | 이름 | 전공 | 동아리 |
| 100200 | 김공부 | 컴퓨터공학 | 게임 동아리 |
| 100201 | 김감귤 | 마케팅 | 디저트 만들기 동아리 |
| 100202 | 김코코 | 철학과 | 보드게임 동아리 |
◍ 속성: 개체가 가지고 있는 특성이다. (학번, 이름, 전공, 동아리 등)
◍ 타입: 개체 인스턴스를 제외한 속성의 집합이다. (학번 + 이름 + 전공 + 동아리/ 모두 합쳐 타입이라고 한다.)
◍ 개체 인스턴스: 개체를 구성하고 있는 각 속성들이 값을 가져 하나의 개체를 나타내는 것이다. 어커런스(Occurrence)라고도 한다.
3.1. 개체 선정 방법
객체 선정을 위해 업무 분석에 관한 내용을 구체적으로 설명한 업무 기술서를 이용하거나 실제 업무를 담당하고있는 담당자와 인터뷰를 진행한다. 또한, 실제 업무를 직접 견학하여 사용되고 있는 장부와 전표를 이용해 인터뷰 및 업무 기술서에 표현되지 않은 누락 정보가 있는지 확인한다.
이미 구축된 시스템이 있는 경우 해당 시스템의 산출물을 검토하며, 자료 흐름도*를 통해 업무 분석을 수행한 경우, 자료 흐름도의 자료 저장소*를 이용한다.
업무 프로세스 재설계*에 의해 업무를 재정의한 경우 관련 개체를 찾는다.
◍ 자료 흐름도 (DFD; Data Flow Diagram): 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법, 그래프 또는 버블 차트라고 부른다.
◍ 자료 저장소 (Data Store): 시스템에서의 자료 저장소이다.
◍ 업무 프로세스 재설계 (BFR; Business Process Reengineering): 기업이 경쟁우위 확보를 위해 기업의 핵심 부문 요인(비용, 품질, 서비스, 스피드 등)에 획기적인 향상을 이룰 수 있도록 비즈니스 시스템을 프로세스 기반으로 재설계하여 성과를 추구하는 것이다.
3.2. 개체명 지정 방법
◍ 해당 업무에서 사용하는 용어로 지정한다.
◍ 약어 사용은 되도록 제한한다.
◍ 가능하면 단수 명사를 사용한다.
◍ 모든 개체명은 유일해야 한다.
◍ 가능하면 개체가 생성되는 의미에 따라 이름을 부여한다.
4. 데이터 모델의 구성 요소: 속성(Attribute) (중요도: B)
속성은 DB를 구성하는 가장 작은 논리적 단위로, 파일 구조상의 데이터 항목 또는 데이터 필드에 해당한다. 개체를 구성하는 항목이고, 개체의 특성을 기술한다. 속성의 수를 차수 또는 Degree라고 한다.
4.1. 속성의 종류
1) 속성의 특성에 따른 분류
|
기본 속성 (Basic Attribute) |
◍ 업무 분석을 통해 정의한 속성으로, 가장 많고 일반적이다. ◍ 업무로부터 분석한 속성이어도 업무상 코드로 정의한 속성은 기본 속성에서 제외된다. |
|
설계 속성 (Designed Attribute) |
◍ 업무상 원래 존재하지 않고, 설계 과정에서 도출해낸 속성이다. ◍ 업무에 필요한 데이터 외에 데이터 모델링을 위해 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성이다. |
|
파생 속성 (Derived Attribute) |
◍ 다른 속성으로부터 계산이나 변형 등의 영향을 받아 발생하는 속성이다. ◍ 파생 속성은 다른 속성의 영향을 받는 만큼 프로세스 설계 시 정합성 유지를 위해 유의할 점이 많으므로 되도록 적은 수를 정의하는 것이 좋다. |
2) 개체 구성 방식에 따른 분류
|
기본키 속성 (Primary KeyAttribute) |
개체를 식별할 수 있는 속성이다. |
|
외래키 속성 (Foreign Key Attribute) |
다른 개체와의 관계에서 포함된 속성 |
|
일반 속성 |
개체에 포함되어 있고 기본키, 외래키에 포함되지 않는 속성 |
4.2. 속성 후보 선정 원칙
속성으로 지정할 후보는 최대한 많이 선택하는 것이 좋다. 주의할 것은 다른 속성을 통해 다시 재현할 수 없는 속성인 원시 속성 (Source Attribute)을 속성 후보에서 제외하지 않는 것인데, 원시 속성은 버리면 해당 속성 정보가 완전히 소실되기 때문에 주의가 필요하다.. 소 그룹별 속성 후보군을 만들고, 가장 근접한 개체에 할당한다.
4.3. 속성명 지정 원칙
◍ 속성명은 웹/클라이언트/서버 등 어떠한 환경에서든 사용자 인터페이스에 나타나기 때문에 정확하고 혼란 없도록 지정해야 한다.
◍ 해당 업무에서 사용하는 용어로 지정한다.
◍ 서술형으로 지정하지 않고, 가급적이면 약어 사용을 제한한다.
◍ 개체명을 속성명으로 사용할 수 없고, 개체에서 유일하게 식별 가능하도록 지정한다.
5. 데이터 모델의 구성 요소: 관계(Relationship) (중요도: B)
관계는 개체와 개체 사이의 논리적 연결을 의미한다. 관계에는 개체 간 관계와 속성 간 관계가 있다.
위의 예시에서 Student의 속성 중 First name과 last name이 속성간 관계이며, 다른 Student가 더 존재한다면 Student 1 과 Student2 사이는 개체간 관계이다.
5.1. 관계의 형태
◍ 일대일: 개체 집합 A의 각 원소가 개체 집합 B의 원소 한 개와 대응하는 관계
◍ 일대다: 개체 집합 A의 각 원소는 개체 집합 B의 원소 여러 개와 대응하고 있지만, 개체 집합 B의 각 원소는 개체 집합 A의 원소 한 개와 대응하는 관계
◍ 다대다: 개체 집합 A의 각 원소는 개체 집합 B의 원소 여러 개와 대응하고, 개체 집합 B의 각 원소도 개체 집합 A의 원소 여러 개와 대응하는 관계
5.2. 관계의 종류
◍ 종속 관계(Dependent Relationship): 두 개체 사이의 주종 관계를 표현한 것, 식별 관계와 비식별 관계가 있다.
▶식별 관계(Identifying Relationship): 개체 A, B 사이의 관계에서 A 개체의 기본키가 B 개체의 외래키이면서 동시에 기본키가 되는 관계, B 개체의 존재 여부가 A 개체의 존재 여부에 의존적인 경우에 발생한다. ER 도형에서 실선으로 표시한다.
▶ 비식별 관계(Non-Identifying Relationship): 개체 A, B 사이의 관계에서 A 개체의 기본키가 B 개체의 비기본키 영역에서 외래키가 되는 관계, B 개체의 존재 여부는 A 개체의 존재 여부와 관계 없이 존재한다. ER 도형에서 점선으로 표시한다.
◍ 중복 관계(Redundant Relationship): 두 개체 사이에 2번 이상의 종속 관계가 발생하는 관계이다.
◍ 재귀 관계(Recursive Relationship): 개체가 자기 자신과 관계를 갖는 것, 순환 관계라고도 한다.
◍ 배타 관계(Exclusive Relationship): 개체의 속성이나 구분자를 기준으로 개체의 특성을 분할하는 관계, 배타 AND와 배타 OR 관계로 구분, 배타 AND 관계는 하위 개체들 중 속성이나 구분자 조건에 따라 하나의 개체만 선택할 수 있고, 배타 OR 관계는 하나 이상의 개체를 선택할 수 있다.
6. 식별자(Identifier) (중요도: C)
식별자는 하나의 개체 내에서 각각의 인스턴스를 유일하게 구분할 수 있는 구분자로, 모든 개체는 한 개 이상의 식별자를 반드시 가져야 한다. 식별자는 대표성, 생성 방법, 단일 속성, 대체 여부에 따라 각각 다르게 구분할 수 있다.
6.1. 식별자의 분류
|
분류 |
식별자 |
|
대표성 여부 |
주 식별자(Primary Identifier)/ 보조 식별자(Alternate Identifier) |
|
스스로 생성 여부 |
내부 식별자(Internal Identifier)/ 외부 식별자(Foreign Identifier) |
|
단일 속성 여부 |
단일 식별자(Single Identifier)/ 복합 식별자(Composite Identifier) |
|
대체 여부 |
원조 식별자(Original Identifier)/ 대리 식별자(Surrogate Identifier) |
6.2. 대표성 여부
주 식별자(Primary Identifier)는 개체를 대표하는 유일한 식별자이다. 보조 식별자(Alternate Identifier)는 주 식별자를 대신하여 개체를 식별할 수 있는 속성이다. 두 식별자 모두 개체를 유일하게 식별할 수 있어야 한다.
하나의 개체에 주 식별자는 한 개만 존재하고, 보조 식별자는 한 개 이상 존재한다. 개체를 유일하게 식별할 수 있는 속성이 두개 이상인 경우, 업무에 가장 적합한 속성을 주 식별자로 지정, 나머지는 보조 식별자로 지정한다.
물리적 테이블에서 주 식별자는 기본키(Primary Key)로, 보조 식별자는 유니크 인덱스(Unique Index)로 지정하고 사용한다.
주 식별자의 특징은 유일성(주 식별자에 의해 개체 내에 모든 인스턴스들이 유일하게 구분 ), 최소성(주 식별자를 구성하는 속성의 수는 유일성을 만족하는 최소 수가 되어야 함 ), 불변성(주 식별자가 한 번 특정 개체에 지정되면, 그 식별자는 변하지 않음 ), 존재성(주 식별자가 지정되면 식별자 속성에 반드시 데이터 값이 존재 )이다.
6.3. 스스로 생성 여부
내부 식별자(Internal Identifier)는 개체 내에서 스스로 만들어지는 식별자이고, 외부 식별자(Foreign Identifier)는 다른 개체와의 관계에 의해 외부 개체의 식별자를 가져와 사용하는 식별자이다. 외부 식별자는 자신의 개체에서 다른 개체를 찾아가는 연결자 역할을 한다.
6.4. 단일 속성 여부
단일 식별자(Single Identifier)는 주 식별자가 한 가지 속성만으로 구성된 식별자이다. 복합 식별자(Composite Identifier)는 주 식별자가 두 개 이상의 속성으로 구성된 식별자이다.
6.5. 대체 여부
원조 식별자(Original Identifier)는 업무에 의해 만들어지는 가공되지 않은 원래의 식별자로, 본질 식별자라고도 한다. 대리 식별자(Surrogate Identifier)는 주 식별자의 속성이 두 개 이상인 경우 속성들을 하나의 속성으로 묶어 사용하는 식별자로, 인조 식별자라고도 한다.
▶ 대리 식별자 조건
◍ 최대한 범용적인 값을 사용한다.
◍ 유일한 값을 만들기 위해 대리 식별자를 사용한다.
◍ 하나의 대리 식별자 속성으로 대체할 수 없는 경우를 주의한다.
◍ 편의성, 단순성, 의미의 체계화를 위한 대리 식별자를 사용할 수 있다.
◍ 시스템적인 필요성에 의해 내부적으로만 사용하는 대리 식별자를 사용할 수 있다.
6.6. 후보 식별자
후보 식별자는 개체에서 각 인스턴스를 유일하게 식별할 수 있는 속성 또는 속성 집합을 말한다. 하나의 개체에는 한 개 이상의 후보 식별자가 있고, 이 중 개체의 대표성을 나타내는 식별자를 주 식별자로, 나머지는 보조 식별자로 지정한다.
▶ 후보 식별자 조건
◍ 각 인스턴스를 유일하게 식별할 수 있어야 한다.
◍ 속성들을 직접 식별할 수 있어야 한다.
◍ Null 값이 될 수 없다.
◍ 속성 집합은 후보 식별자로 지정한 경우 개념적으로 유일해야 한다.
◍ 후보 식별자의 데이터는 자주 변경되지 않아야 한다.
7. E-R(개체-관계) 모델 (중요도: A)
7.1. E-R(Entity-Relationship, 개체-관계) 모델
E-R 모델은 개념적 데이터 모델의 가장 대표적인 것으로 1976년 피터 첸(Peter Chen)에 의해 제안되었다.
개체(Entity Type)와 개체 간 관계(Relationship Type)를 기본 요소로 이용하여 현실 세계의 무질서한 데이터를 개념적 논리 데이터로 표현하기 위한 방법으로 많이 사용된다.
E-R 모델에서는 데이터를 개체, 관계, 속성으로 묘사하지만, 특정 DBMS를 고려한 것은 아니다. E-R 다이어그램으로 표현되며, 일대일, 일대다, 다대다 등의 관계 유형을 나타낸다.
7.2. E-R 다이어그램
E-R 모델의 기본 아이디어를 이해하기 쉽게 기호를 사용하여 시각적으로 표현한 그림이다. 실체 간의 관계는 물론, 시스템 내에서 역할을 가진 모든 실체(조직, 사용자, 프로그램, 데이터 등)들을 표현한다.
데이터에 대해 개발자, 관리자, 사용자들이 서로 다르게 인식하고 있는 View를 하나로 단일화 한다. E-R 다이어그램 표기법에는 피터 첸 표기법, 정보 공학 표기법, 바커 표기법 등이 있다.
7.3. E-R 다이어그램 표기법
1) 피터 첸 표기법(Peter Chen Notation)
개체, 속성, 기본키 속성, 관계 등을 표현한다.
◍ 개체: 고객, 주문서
◍ 고객의 속성: 고객번호, 성명, 주소
◍ 주문서의 속성: 주문번호, 품명, 수량, 금액
◍ 밑줄친 속성: 기본키
2) 정보 공학 표기법(Information Engineering Notation)
1981년에 클리프 핀겔쉬타인과 제임스 마틴이 공동 개발했다. 개체, 속성, 기본키 속성, 관계 등을 표현한다. 개체는 사각형 박스로, 개체명은 박스 바깥쪽 위에 표시한다. 속성은 기본키 속성과 일반 속성으로 분리하여 표시한다. 관계는 관계 표시 기호를 사용하여 표시한다.
◍ 관계 표시 기호 ◍
3) 바커 표기법(BARKER Notation)
개체, 속성, 기본키 속성, 관계 등을 표현한다. 개체는 모서리가 둥근 박스로 표시하고, 박스 안 가장 위에 개체명을 표시한다. 속성은 반드시 값이 저장되어야 하는 경우 *(mandatory)를 표시하고, 값이 저장될 수도 안될 수도 있는 경우 O(Optional)를 표시한다.
관계는 관계 표시 기호를 사용하여 표시 후 해당 개체의 역할을 동사 단어로 입력한다.
8. 관계형 데이터 모델 (중요도: C)
8.1. 관계형 데이터 모델(Relational Data Model)
가장 일반적인 구조의 데이터 모델로, 2차원 Table을 이용해 데이터 상호 관계를 정의하는 DB 구조를 말한다. 파일 구조처럼 구성한 테이블들을 하나의 DB로 묶어 테이블 내에 있는 속성 간의 관계를 설정하거나 테이블 간의 관계를 설정하여 이용한다.
계층 모델과 망 모델의 복잡한 구조를 단순화시킨 모델이며, 기본키와 이를 참조하는 외래키로 데이터 간 관계를 표현한다.
일대일, 일대다, 다대다 관계를 자유롭게 표현할 수 있으며, 관계형 모델의 대표적 언어는 SQL이다.
8.2. 관계형 데이터 모델의 구성
E-R 모델에서 설명한 고객과 주문서 그리고 주문 관계를 관계형 데이터 모델로 표시하면 다음과 같다.
◍ '고객'과 '주문내역'은 개체 테이블, '주문'은 관계로 만들어진 테이블
◍ 고객 테이블과 주문내역 테이블은 주문 테이블을 관계로 연결되어 있다.
◍ 고객 테이블의 고객번호는 기본키, 주문 테이블의 고객번호와 주문번호는 외래키, 주문서
◍ 테이블의 주문번호는 기본키이다.
◍ 고객과 주문의 관계는 일대다, 즉, 한명의 고객은 여러 주문을 신청할 수 있다.
◍ 주문내역과 주문의 관계는 일대일, 즉, 주문내역은 주문번호 1개에 대한 정보만 갖는다.
◍ 주문 테이블 내용으로 주문 고객의 성명을 찾으려면 주문 테이블의 고객번호와 같은 고객번호를 고객 테이블에서 찾고, 주문 내역을 알려면 주문번호와 같은 주문번호를 주문서 테이블에서 찾는다.
9. 관계형 데이터베이스의 구조 (중요도: A)
관계형 데이터베이스는 1970년 IBM에 근무하던 코드(E. F. Codd)에 의해 처음 제안되었다. 관계형 데이터베이스를 구성하는 개체나 관계를 모두 릴레이션(Relation)이라는 표(Table)로 표현한다.
릴레이션은 개체를 표현하는 개체릴레이션과 관계를 나타내는 관계릴레이션으로 구분한다. 간결하여 보기 편하고 다른 데이터베이스로의 전환이 편리하다는 장점이 있지만 성능이 다소 떨어지는 단점이 있다.
9.1. 관계형 데이터베이스의 Relation구조
릴레이션은 데이터들을 테이블의 형태로 표현한 것으로 구조를 나타내는 릴레이션 스키마와 실제 값들인 릴레이션 인스턴스로 구성된다.
① 튜플(Tuple)
◍ 릴레이션을 구성하는 각각의 행
◍ 튜플은 속성의 모임으로 구성
◍ 파일구조에서 레코드와 같은 의미
◍ 튜플의 수 = 카디널리티(Cardinality) = 기수 = 대응수
② 속성(Attribute)
◍ 데이터베이스를 구성하는 가장 작은 논리적 단위
◍ 파일구조에서 데이터 항목 또는 데이터 필드와 같은 의미
◍ 개체의 특성을 기술
◍ 속성의 수 = 디그리(Degree) = 차수
③ 도메인(Domain)
◍ 하나의 속성이 취할 수 있는 같은 타입의 원자(Atomic=속성의 인스턴스) 값들의 집합이다.
◍ 도메인은 실제 속성 값이 나타날 때 그 값의 합법 여부를 시스템이 검사하는 데에도 이용한다.
9.2. 릴레이션의 특징 (중요)
◍ 한 릴레이션에는 똑같은 튜플이 포함될 수 없으므로 릴레이션에 포함된 튜플들은 모두 다르다.
◍ 한 릴레이션에 포함된 튜플 사이에는 순서가 없다.
◍ 튜플의 삽입, 삭제 작업으로 인해 시간에 따라 바뀐다.
◍ 릴레이션 스키마를 구성하는 속성들 간의 순서는 중요하지 않다.
◍ 속성의 유일한 식별을 위해 속성의 명칭은 유일해야 하지만, 속성을 구성하는 값은 동일한 값이 있을 수 있다.
◍ 릴레이션을 구성하는 튜플을 유일하게 식별하기 위해 속성들의 부분집합을 키로 설정한다
◍ 속성의 값은 논리적으로 더 이상 쪼갤 수 없는 원자값만을 저장한다.
10. 관계형 데이터베이스의 제약조건-키(Key) (중요도: A)
제약조건은 데이터베이스에 저장되는 데이터의 정확성을 보장하기 위해 Key를 이용하여 입력되는 데이터에 제한을 주는 것이다. 키(key)는 데이터베이스에서 조건에 맞는 튜플을 찾거나 순서대로 정렬할 때 튜플들을 서로 구분할 수 있는 기준이 되는 속성(Attribute)를 말한다. 키의 종류에는 후보키, 기본키, 대체키, 슈퍼키, 외래키 등이 있다.
10.1. 후보키(Candidate Key)
후보키는 릴레이션을 구성하는 속성들 중에서 튜플을 유일하게 식별하기 위해 사용하는 속성들의 부분집합으로, 즉 기본키로 사용할 수 있는 속성들이다. 하나의 릴레이션 내에서는 중복된 튜플들이 있을 수 없기 때문에, 모든 릴레이션에는 무조건 하나 이상의 후보키가 존재한다. 후보키는 릴레이션에 있는 모든 튜플에 대해 유일성과 최소성을 만족해야 한다.
◍ 유일성(Unique): 하나의 키 값으로 하나의 튜플만을 유일하게 식별할 수 있어야 함
◍ 최소성(Minimality): 모든 레코드를 유일하게 식별하는 데 꼭 필요한 속성으로만 구성되어야 함
예) [학생] 릴레이션에서 '학번'이나 '주민번호'는 다른 레코드를 유일하게 구별할 수 있는 기본키로 사용할 수 있으며 후보키이다.
10.2. 기본키(Primary Key)
기본키는 후보키 중에서 특별하게 선택된 메인 키로, 한 릴레이션에서 특정 튜플을 유일하게 구별할 수 있는 속성이다. 때문에 중복된 값을 가질 수 없는 특징을 가진다.
기본키는 후보키의 성질을 가지는데, 이는 유일성과 최소성을 가지며 튜플을 식별하기 위해 반드시 필요한 키임을 말한다. 기본키는 NULL 값을 가질 수 없다. (데이터가 비어있으면 안된다.)
예) [학생] 릴레이션에서 '학번'이나 '주민번호'가 기본키가 될 수 있고, [수강] 릴레이션에서는 '학번'+'과목명'의 조합이 기본키이다.
10.3. 대체키(Alternate Key)
대체키는 후보키가 둘 이상일 때 기본키를 제외한 나머지 후보키를 의미한다.
예) [학생] 릴레이션에서 '학번'을 기본키로 정의하면 '주민번호'는 대체키가 된다.
10.4. 슈퍼키(Super Key)
한 릴레이션 내에 있는 속성들의 집합으로 구성된 키로, 릴레이션을 구성하는 모든 튜플 중 슈퍼키로 구성된 속성의 집합과 동일한 값은 나타나지 않는다. 슈퍼키는 릴레이션을 구성하는 모든 튜플에 대해 유일성을 만족하지만, 최소성은 만족하지 못한다.
예) [학생] 릴레이션에서 '학번', '주민번호', '학번'+'주민번호', '주민번호'+'성명', '학번'+'주민번호'+'성명' 등으로 슈퍼키를 구성할 수 있다.
10.5. 외래키(Foreign Key)
다른 릴레이션의 기본키를 참조하는 속성 또는 속성들의 집합을 의미한다. 외래키는 참조되는 릴레이션의 기본키와 대응되어 릴레이션 간의 참조 관계를 표현하는 도구이다.
한 릴레이션에 속한 속성 A와 참조 릴레이션의 기본키인 B가 동일한 도메인 상에서 정의 되었을 때의 속성 A를 외래키라고 한다. 외래키로 지정되면 참조 릴레이션의 기본키에 없는 값은 입력할 수 없다.
예) [수강] 릴레이션이 [학번] 릴레이션을 참조하고 있으므로 [학생] 릴레이션의 '학번'은 기본키이고, [수강] 릴레이션의 '학번'은 외래키이다.
11. 관계형 데이터베이스의 제약 조건-무결성(Integrity) (중요도: B)
무결성(Integrity)이란 데이터베이스에 저장된 데이터 값과 그것이 표현하는 현실 세계의 실제 값이 일치하는 정확성을 의미한다. 무결성 제약 조건은 DB에 들어 있는 데이터의 정확성을 보장하기 위해 부정확한 자료가 DB 내에 저장되는 것을 방지하는 제약조건이다.
무결성의 종류에는 개체 무결성, 도메인 무결성, 참조 무결성, 사용자 정의 무결성이 있다.
11.1. 개체 무결성(Entity Integrity) (중요)
기본 테이블의 기본키를 구성하는 어떤 속성도 Null 값이나 중복 값을 가질 수 없다.
11.2. 도메인 무결성(Domain Integrity, 영역 무결성)
주어진 속성 값이 정의된 도메인에 속한 값이어야 한다는 규정이다.
예) [수강] 릴레이션의 '과목명' 속성에는 영어, 수학, 컴퓨터, 미술, 음악 5가지만 입력되도록 유효값이 지정된 경우 반드시 해당 값만 입력해야 함
11.3. 참조 무결성(Referential Integrity) (중요)
외래키 값은 NULL이거나 참조 릴레이션의 기본키 값과 동일해야 한다. 즉 릴레이션은 참조할 수 없는 외래키 값을 가질 수 없다는 규정이다.
11.4. 사용자 정의 무결성(User-Defined Integrity)
속성 값들이 사용자가 정의한 제약 조건에 만족해야 한다는 규정이다.
11.5. 데이터 무결성 강화
데이터 무결성은 데이터 품질에 직접적인 영향을 주므로, 데이터 특성에 맞는 적절한 무결성을 정의하고 강화해야 한다. 프로그램이 완성되고 데이터가 저장된 상태에서 무결성을 정의할 경우, 많은 비용이 발생하므로 DB 구축 과정에서 정의한다.
1) 애플리케이션
◍ 데이터 생성, 수정, 삭제 시 무결성 조건 검증 코드를 데이터 조작 프로그램 내에 추가
◍ DB에서는 데이터 무결성 제약을 정의할 수 없으므로 복잡한 규칙 등은 애플리케이션 내에서 처리
◍ 장점: 사용자 정의와 같이 복잡한 무결성 조건 구현 가능
◍ 단점: 소스 코드가 분산되어 관리가 어려움, 개별적 시행으로 적정성 검토가 어려움
2) 데이터베이스 트리거
◍ 트리거* 이벤트*에 무결성 조건을 실행하는 절차형 SQL을 추가
◍ 장점: 통합 관리 가능, 복잡한 요구 조건 구현 가능
◍ 단점: 운영 중 변경이 어려움, 사용상 주의 필요
* 트리거(Trigger): DB 시스템에서 데이터의 입력, 갱신, 삭제 등의 이벤트가 발생할 때마다 자동적으로 수행되는 절차형 SQL
* 이벤트(Event): 시스템에 어떤 일이 발생하는 것, 트리거에서 이벤트는 데이터의 입력, 갱신, 삭제와 같이 데이터를 조작하는 작업이 발생했음을 의미
3) 제약조건
◍ DB에 제약조건을 설정하여 무결성을 유지
◍ 장점: 통합 관리 가능, 간단한 선언으로 구현 가능, 변경 용이, 오류 데이터 발생 방지
◍ 단점: 복잡한 제약 조건 구현과 예외 처리 불가능
12. 관계대수 및 관계해석 (중요도: A)
관계대수는 관계형 DB에서 원하는 정보와 그 정보를 검색하기 위해 어떻게 유도하는가를 기술하는 절차적 언어이다. 관계대수는 릴레이션을 처리하기 위해 연산자와 연산규칙을 제공하는 언어로, 피연산자와 결과 모두 릴레이션이다. 관계대수는 질의에 대한 해를 구하기 위해 수행해야 할 연산의 순서를 명시한다. 관계 DB에 적용하기 위해 특별히 개발한 순수 관계 연산자(Select, Project, Join, Division)와 수학적 집합 이론에서 사용하는 일반 집합 연산자(UNION, INTERSECTION, DIFFERENCE, CARTESIAN PRODUCT)가 있다.
12.1. 순수관계연산자: Select
릴레이션에 존재하는 튜플 중 선택 조건을 만족하는 튜플의 부분집합을 구해 새로운 릴레이션을 생성하는 연산이다. 릴레이션의 행에 해당하는 튜플을 구하는 것이기 때문에 수평 연산이라고도 한다.
연산자 기호는 σ(시그마)이며 σ(조건)(릴레이션명)으로 표기한다. 조건에는 등호, 부등호 등의 기호를 사용한 비교 연산이 허용되며, 논리 연산자를 사용하여 여러 개의 조건들을 하나의 조건으로 결합시킬 수도 있다
12.2. 순수관계연산자: Project
주어진 릴레이션에서 속성 리스트에 제시된 속성 값만을 추출하여 새로운 릴레이션을 만드는 연산이다. 이 과정에서 연산 결과에 중복이 발생하면 중복된 값은 제거된다. 릴레이션의 열에 해당하는 튜플을 구하는 것이므로 수직 연산이라고도 한다.
연산자 기호는 π(파이)이며, π(속성리스트)(릴레이션명)으로 표기한다.
12.3. 순수관계연산자: Join
공통 속성을 중심으로 두 개의 릴레이션을 하나로 합쳐 새로운 릴레이션을 만드는 연산이다. Join 결과로 만들어진 릴레이션의 차수는 조인된 두 릴레이션 차수를 합한 것과 같다. 또한, Join 결과는 Cartesian Product(교차곱)를 수행 한 다음 Select를 수행한 것과 같은 값은 가진다.
연산자 기호는 ⋈이며, 릴레이션R⋈(키속성r=키속성s)릴레이션S로 표기한다.
◍ Cartesian Product: 두 릴레이션의 튜플을 모두 대응시켜 새로운 릴레이션을 만드는 연산
▶ 자연 조인(Natural Join): 이중 중복된 속성을 제거해 같은 속성을 한 번만 표기하는 방법
12.4. 순수관계연산자: Division
X⊃Y인 두 개의 릴레이션 R(x)와 S(y)가 있을 때, R의 속성이 S의 속성 값을 모두 가진 튜플에서 S가 가진 속성을 제외한 속성만을 구하는 연산이다.
연산자 기호는 ÷ (시그마)이며 릴레이션R[속성r÷속성s]릴레이션S으로 표기한다.
12.5. 일반 집합 연산자
일반 집합 연산자는 수학적 집합 이론에서 사용하는 연산자로, 릴레이션 연산에도 적용된다.
|
합집합, ∪ (UNION) |
두 릴레이션에 존재하는 튜플의 합집합을 구하되, 중복 튜플은 제거 |
|
교집합, ∩ (INTERSECTION) |
두 릴레이션에 존재하는 튜플의 교집합을 구하는 연산 |
|
차집합, - (DIFFERENCE) |
두 릴레이션에 존재하는 튜플의 차집합을 구하는 연산 |
|
교차곱, x (CARTESIAN PRODUCT) |
두 릴레이션에 있는 튜플들의 순서쌍을 구하는 연산 |
12.6. 관계 해석(Relational Calculus)
관계 해석은 관계 데이터 모델의 제안자인 코드(E. F. Codd)가 수학의 Predicate Calculus(술어 해석)에 기반을 두고 관계 데이터베이스를 위해 제안한 것으로, 관계 데이터의 연산을 표현하는 방법으로, 원하는 정보를 정의할 때 계산 수식을 사용한다.
관계해석 원하는 정보가 무엇이라는 것만 정의하는 비절차적 특성을 지닌다. 기본적으로 관계해석과 관계대수는 관계 DB를 처리하는 기능과 능력면에서 동등하며, 관계대수로 표현한 식은 관계해석으로 표현할 수 있다.
관계해석은 질의어로 표현되며, 튜플 관계해석과 도메인 관계해석으로 나뉜다.
13. 정규화(Normalization) (중요도: A)
정규화는 함수적 종속성 등의 종속성 이론을 이용하여 잘못 설계된 관계형 스키마를 더 작은 속성의 세트로 쪼개어 바람직한 스키마로 만들어가는 과정이다. 다시말해, 하나의 종속성이 하나의 릴레이션에 표현될 수 있도록 분해해가는 과정이다. 정규화의 차수가 높아질수록 만족시켜야 할 제약 조건이 늘어난다.
또한 정규화는 데이터베이스의 논리적 설계 단계에서 수행되며, 논리적 처리 및 품질에 큰 영향을 준다. 정규화된 데이터 모델은 일관성, 정확성, 단순성, 비중복성, 안정성 등을 보장한다.
정규화 수준이 높을수록 유연한 데이터 구축이 가능하고, 데이터 정확성이 높아지는 반면, 물리적 접근이 복잡하고 너무 많은 조인으로 인해 조회 성능이 저하된다.
13.1. 정규화 목적
◍ 데이터 구조의 안정성 및 무결성을 유지한다.
◍ 어떠한 릴레이션이라도 DB 내에서 표현 가능하게 만든다.
◍ 효과적인 검색 알고리즘을 생성할 수 있다.
◍ 데이터 중복을 배제하여 이상 발생 방지 및 자료 저장 공간 최소화가 가능하다.
◍ 데이터 삽입 시 릴레이션을 재구성할 필요성을 줄인다.
◍ 데이터 모형의 단순화가 가능하다.
◍ 속성의 배열 상태 검증이 가능한다.
◍ 개체와 속성의 누락 여부 확인이 가능하다.
◍ 자료 검색과 추출의 효율성을 추구한다.
13.2. 이상(Anomaly)의 개념 및 종류
정규화를 거치지 않으면 DB 내에 데이터들이 불필요하게 중복되어 릴레이션 조작 시 예상치 못한 현상이 발생하는데, 이를 이상(Anomaly)라고 한다.
◍ 삽입 이상(Insertion Anomaly): 릴레이션에 데이터를 삽입할 때 의도와는 상관없이 원하지 않은 값들도 함께 삽입되는 현상
◍ 삭제 이상(Deletion Anomaly): 릴레이션에서 한 튜플을 삭제할 때 의도와는 상관없는 값들도 함께 삭제되는 현상
◍ 갱신 이상(Update Anomaly): 릴레이션에서 튜플에 있는 속성 값을 갱신할 때 일부 튜플의 정보만 갱신되어 정보에 모순이 생기는 현상
13.3. 정규화 원칙
◍ 정보의 무손실 표현: 하나의 스키마를 다른 스키마로 변환할 때 정보의 손실이 있어서는 안된다.
◍ 분리의 원칙: 하나의 독립된 관계성은 하나의 독립된 릴레이션으로 분리시켜 표현해야 한다.
◍ 데이터 중복성이 감소되어야 한다
13.4. 정규화 과정
1) 제1정규형(1NF)
제1정규형(1NF)은 릴레이션에 속한 모든 도메인이 원자값 만으로 되어 있는 정규형이다. 릴레이션의 모든 속성이 단순 영역에서 정의 된다는 특징을 가진다.
2) 제2정규형(2NF)
제2정규형(2NF)은 릴레이션 R이 1NF이고, 기본키가 아닌 모든 속성이 기본키에 대해 완전 함수적 종속(Functional Dependency: 데이터들이 어떤 기준 값에 의해 종속되는 것)을 만족하는 정규형이다.
3) 제3정규형(3NF)
제3정규형(3NF)은 릴레이션 R이 2NF이고, 기본키가 아닌 모든 속성이 기본키에 대해 이행적 종속 관계(Transitive Dependency: A→B이고, B→C일 때, A→C를 만족하지 않는 관계 )를 만족하지 않는 정규형이다.
무손실 조인 또는 종속성 보존을 저해하지 않고도 항상 3NF 설계를 얻을 수 있다.
4) BCNF(Boyce-Codd 정규형)
BCNF는 릴레이션 R에서 결정자가 모두 후보키인 정규형을 말한다. 3NF에서 후보키가 여러 개 존재하고 서로 중첩되는 경우에 적용하는, 강한 제3정규형이라고도 한다. 다만, 모든 BCNF가 종속성을 보존하는 것은 아니다.
BCNF 제약 조건은 다음과 같다.
① 키가 아닌 모든 속성은 각 키에 대하여 완전 종속해야 한다.
② 키가 아닌 모든 속성은 그 자신이 부분적으로 들어가 있지 않은 모든 키에 대하여 완전 종속해야 한다.
③ 어떤 속성도 키가 아닌 속성에 대해서는 완전 종속할 수 없다.
5) 제4정규형(4NF)
제4정규형(4NF)은 릴레이션 R에 다치 종속* A ↠ B가 성립하는 경우 R의 모든 속성이 A에 함수적 종속 관계를 만족하는 정규형이다.
* 다치 종속(Multi Valued Dependency, 다가종속: A, B, C, 3개의 속성을 가진 릴레이션 R에서 어떤 복합 속성(A, C)에 대응하는 B 값의 지합이 A값에만 종속되고 C값에는 무관하면, B는 A에 다치 종속이라고 하고, A↠B로 표기한다.
6) 제5정규형(5NF)
제5정규형(5NF)은 릴레이션 R의 모든 조인 종속이 R의 후보키를 통해서만 성립되는 정규형이다.
14. 반정규화 (역정규화; Denormalization) (중요도: B)
반정규화는 시스템의 성능 향상, 개발 및 운영의 편의성 등을 위해 정규화된 데이터 모델을 통합/중복/분리하는 과정이다. 즉, 의도적으로 정규화 원칙을 위배하는 행위이다.
반정규화를 수행하면 시스템 성능 향상과 관리 효율성은 증가하지만, 데이터 일관성 및 정합성이 저하될 수 있다. 성능 향상을 목표로 진행하지만 과도한 반정규화는 오히려 성능을 저하시킨다.
반정규화를 위해 사전에 데이터의 일관성과 무결성을 무선으로 할지, DB 성능과 단순화를 우선으로 할지 결정해야 한다. 반정규화의 방법에는 테이블 통합, 테이블 분할, 테이블 추가, 중복 속성 추가 등이 있다.
14.1. 테이블 통합
1) 개념
두 개의 테이블이 조인되는 경우가 많으면, 하나의 테이블로 합쳐 사용하는 것이 성능 향상에 도움된다. 즉, 두 테이블에서 발생하는 프로세스가 동일하게 처리되는 경우가 잦으면, 테이블 통합을 고려한다.
2) 테이블 통합 종류
1대1 관계 테이블 통합, 1대N 관계 테이블 통합, 슈퍼타입(상위개체)/서브타입(하위 개체) 테이블 통합이 있다.
3) 테이블 통합 시 고려사항
◍ 데이터 검색은 간편하지만 레코드 증가로 인해 처리량이 증가한다.
◍ 테이블 통합으로 인해 입력, 수정, 삭제 규칙이 복잡해진다.
◍ Not Null, Default, Check 등의 제약조건 설계가 어렵다.
14.2. 테이블 분할
1) 개념
테이블을 수직 또는 수평으로 분할하는 것이다.
2) 수평 분할(Horizontal Partitioning)
레코드를 기준으로 테이블을 분할하는 것이다. 레코드 별 사용 빈도 차이가 큰 경우 사용 빈도에 따라 테이블을 분할한다.
3) 수직 분할(Vertical Partitioning)
하나의 테이블에 속성이 너무 많은 경우 속성을 기준으로 테이블을 분할하는 것이다.
◍ 갱신 위주의 속성 분할: 데이터 갱신 시 레코드 잠금으로 인해 다른 작업을 수행할 수 없으므로 갱신이 자주 일어나는 속성들을 수직 분할하여 사용한다.
◍ 잦은 조회 속성 분할: 테이블에서 자주 조회되는 속성이 극히 일부일 경우 그 속성들을 수직 분할하여 사용한다.
◍ 크기가 큰 속성 분할: 이미지 또는 큰(2GB 이상) 텍스트 형식 등으로 된 속성들을 수직 분할하여 사용한다.
◍ 보안 적용 속성 분할: 테이블 내 특정 속성에 대해서만 보안을 적용할 수 없으므로, 보안이 필요한 속성들을 수직 분할하여 사용한다.
4) 테이블 분할 시 고려사항
◍ 기본키의 유일성 관리가 어려워진다.
◍ 데이터 양이 적거나 사용 빈도가 낮은 경우, 굳이 테이블 분할을 하지 않아도 되니, 분할이 꼭 필요한지 고려해야 한다.
◍ 분할된 테이블로 인해 수행 속도가 느려질 수 있다.
◍ 데이터 검색에 중점을 두고 테이블 분할 여부를 결정한다.
14.3. 중복 테이블 추가
1) 개념
여러 테이블에서 데이터를 추출하고 사용하거나 다른 서버에 저장된 테이블에 접근해야 하는 경우, 중복 테이블을 추가하여 작업 효율성을 향상시킨다.
2) 중복 테이블을 추가하는 경우
◍ 정규화로 인해 수행 속도가 느려지는 경우
◍ 많은 범위의 데이터를 자주 처리해야 하는 경우
◍ 특정 범위의 데이터를 자주 처리해야 하는 경우
◍ 처리 범위를 줄이지 않고는 수행 속도를 개선할 수 없는 경우
3) 중복 테이블 추가 방법
◍ 집계 테이블 추가: 집계 데이터를 위한 테이블 생성, 각 원본 테이블에 트리거 설정
◍ 진행 테이블 추가: 적절한 데이터 양 유지와 활용도 향상을 위해 적절한 기본키 설정
◍ 특정 부분 포함 테이블 추가: 데이터가 많은 테이블의 특정 부분만 새 테이블로 생성
14.4. 중복 속성 추가
1) 개념
중복 속성 추가는 조인해서 데이터를 처리할 때 데이터 조회 경로를 단축하기 위해 자주 사용하는 속성을 추가하는 것이다. 중복 속성을 추가하면 데이터 무결성 확보가 어렵고, 디스크 공간이 추가로 필요하다.
2) 중복 속성을 추가하는 경우
◍ 조인이 자주 발생하는 속성인 경우
◍ 접근 경로가 복잡한 속성인 경우
◍ 액세스 조건으로 자주 사용되는 속성인 경우
◍ 기본키 형태가 적절하지 않거나 여러 개의 속성으로 구성된 경우
3) 중복 속성 추가 시 고려사항
◍ 테이블 중복과 속성 중복을 고려한다.
◍ 데이터 일관성 및 무결성에 유의한다.
◍ SQL 그룹 함수를 이용하여 처리할 수 있어야 한다.
◍ 저장 공간 낭비를 고려한다.
15. 시스템 카탈로그 (중요도: A)
시스템 카탈로그(System Catalog)는 시스템 그 자체에 관련이 있는 다양한 객체에 관한 정보를 포함하는 시스템 DB이다. 시스템 카탈로그 내의 각 테이블은 사용자를 포함하여 DBMS에서 지원하는 모든 데이터 객체에 대한 정의, 명세에 관한 정보를 유지 관리하는 시스템 테이블이다.
카탈로그들이 생성되면 데이터 사전(Data Dictionary)에 저장되기 때문에 좁은 의미로는 카탈로그를 데이터 사전이라고도 한다.
15.1. 시스템 카탈로그 저장 정보
시스템 카탈로그에 저장된 정보를 메타 데이터(Meta-Data)라고 한다. 메타 데이터의 유형은 다음과 같다.
◍ 데이터 베이스 객체 정보: 테이블, 인덱스, 뷰 등
◍ 사용자 정보: 아이디, 패스워드, 접근권한 등
◍ 테이블의 무결성 제약 조건 정보: 기본키, 외래키, NULL 값 허용 여부
◍ 함수, 프로시저, 트리거 등에 대한 정보
15.2. 카탈로그의 특징
카탈로그 자체도 시스템 테이블로 구성되어 있기 때문에 일반 사용자도 SQL을 이용하여 내용을 검색해 볼 수 있다. 다만 INSERT, DELETE, UPDATE 문으로 카탈로그를 갱신하는 것은 허용되지 않는다. DB 시스템에 따라 상이한 구조를 갖고, DBMS가 스스로 카탈로그를 생성하고 유지한다.
◍ 카탈로그의 갱신: 사용자가 SQL문을 실행해 기본 테이블, 뷰, 인덱스 등에 변화를 주면 시스템이 자동적으로 갱신한다.
◍ 분산 시스템에서의 카탈로그: 보통의 릴레이션, 인덱스, 사용자 등의 정보를 포함할뿐 아니라 위치 투명성 및 중복 투명성을 제공하기 위해 필요한 모든 제어 정보를 가진다.
15.3. 카탈로그/데이터 사전을 참조하기 위한 DBMS 내의 모듈 시스템
카탈로그(또는 데이터 사전)을 참조하기 위한 DBMS 내의 모듈 시스템이다.
1) DDL Compiler(데이터 정의어 번역기)
DDL을 메타 데이터를 갖는 테이블(카탈로그)로 변환하여 데이터 사전에 저장한다.
2) DML Compiler(데이터 조작어 번역기)
응용 프로그램에 삽입된 DML문을 주 언어로 표현한 프로시저 호출로 변환하여 질의 처리기와 상호 통신한다.
3) Data Directory
데이터 사전에 수록된 데이터에 접근하는 데 필요한 정보를 관리/유지하는 시스템
시스템 카탈로그는 사용자와 시스템 모두 접근할 수 있지만, 데이터 디렉터리는 시스템만 접근할 수 있다.
4) 질의 최적화기
사용자 요구를 효율적인 형태로 변환하고 질의를 처리하기 위한 전략을 모색한다.
5) 트랜잭션 처리기
다수의 사용자 환경에서 평행으로 동시에 일어나는 트랜잭션 문제를 해결하여, 각각의 사용자가 DB 자원을 배타적으로 이용할 수 있도록 한다.
'정보처리기사 > 3과목 데이터베이스 구축' 카테고리의 다른 글
| [정보처리기사] Chapter 05. 데이터베이스 구축: 데이터전환 (0) | 2021.04.26 |
|---|---|
| [정보처리기사] Chapter 04. 데이터베이스 구축: SQL 활용 (0) | 2021.04.25 |
| [정보처리기사] Chapter 03. 데이터베이스 구축: SQL 응용 (0) | 2021.04.25 |
| [정보처리기사] Chapter 02. 데이터베이스 구축: 물리 데이터베이스 설계 (0) | 2021.04.25 |
