데이터베이스 12주차 요약

◆트리거(trigger)

●저장된 데이터의 의미적 정확성(무결성)을 보장하기 위해서

●명시된 이벤트(데이터베이스의 갱신)가 발생할 때마다. DBMS가 자동적으로 수행하는, 사용자가 정의하는 문(프로시저)이다.

 

●트리거를 명시하려면

▷1. 트리거를 활성화시키는 사건인 이벤트

▷2. 트리거가 활성화 되었을 때 수행되는 테스트인 조건

▷3. 트리거가 활성화되고 조건이 참일 때 수행되는 문(프로시저)인 동작을 표현해야 한다.

▷트리거를 이벤트-조건-동작(ECA) 규칙이라고도 한다. (Event Condition Action)

○CREATE TRIGGER <트리거 이름>

○AFTER <트리거를 유발하는 이벤트들이 OR로 연결된리스트> ON <릴레이션> -이벤트

○[WHEN <조건>] -조건

○BEGIN <SQL문(들)> END -동작

*SELECT문은 데이터를 갱신하지 않음으로 이벤트가 될 수 없다.

●트리거를 과도하게 사용하면 복잡한 상호 의존성을 야기할 수 있다.

●한 트리거 내의 SQL문이 다른 트리거의 활성화를 유발하면 트리거들이 연쇄된다고 말한다.

 

◆내포된 SQL

◆호스트 언어에서 제공하는 데이터 구조와 DBMS가 제공하는 데이터 구조가 불일치하는

문제(impedance mismatch 문제) 등을 해결해야 한다.

*C 프로그램에 SQL문을 내포시키는 환경을 가정하고 설명을 전개한다. 이를 줄여서 Pro *C

●일반적으로 내포된 SQL문이 포함된 소스 파일의 확장자는 .pc이다.

●호스트 언어로 작성 중인 프로그램에 모든 SQL문에는 반드시 문장의 앞부분에 EXEX SQL을 붙인다.

 

◆그림1,2 내포된 SQL문의 컴파일 과정

▷호스트변수를 SQL안에서 선언해주어야 한다.

▷호스트변수 앞에 콜론을 써야 한다.

 

●불일치 문제와 커서

▷호스트 언어는 단일 변수/레코드(구조체) 위주의 처리(투플 위주의 방식)를 지원하는 반면 SQL은 데이터 레코드들의 처리(집합 위주의 방식)를 지원하기 때문에 불일치 문제가 발생한다. 따라서 커서를 사용한다.

 

1. 커서는 투플들의 집합에 속하는 각 투플을 가리키는 포인터로 생각할 수 있다.

2. 커서를 선언한 후에 OPEN문은 질의를 수행하고,

3. 질의 수행 결과의 첫 번째 투플 이전을 커서가 가리키도록 한다.

<책을 볼 것.>

◆데이터베이스 설계와 ER 모델

 

●데이터베이스의 설계

▷미리 정의된 응용들의 모임을 위해서 조직체의 사용자들의 정보 요구를 수용하여 하나 이상의 데이터베이스의 논리적인 구조와 물리적인 구조를 설계하는 것이다.

 

◆개념적 데이터베이스 설계와 물리적 데이터베이스 설계

●개념적 데이터베이스 설계

▷고수준(description)을 산출한다.

▷설계 과정에서 조직체(실세계)의 엔티티, 관계, 프로세스, 무결성 제약조건 등을 나타내는 추상화 모델을 구축한다.

▷엔티티는 서로 구분이 되면서 조직체에서 데이터베이스에 나타나려는 객체(사람, 장소, 사물 등)를 의미한다.

▷관계는 두 개 이상의 엔티티들 간의 연관을 나타낸다.

▷DBMS의 독립적인 데이터베이스 설계를 위해서 등이다.

▷인기 있는 개념적 모델은 엔티티-관계(ER: Entity-Relationship) 모델이다.

▷ER 모델과 같은 개념적 데이터 모델이 사상(mapping)될 수 있는 다수의 논리적 데이터 모델(implementation)이 존재한다.

 

◆데이터베이스 설계

▷한 조직체의 운영과 목적을 지원하기 위해 데이터베이스를 생성하는 과정이다.

▷주요 목적은 모든 주요 응용과 사용자들이 요구하는 데이터, 데이터 간의 관계를 표현하기

*관계 데이터 모델만을 사용한다.

 

●요구사항 수집과 분석

▷요구사항을 수집하고, 의견들을 평가하고 조정한다.

▷기존의 문서를 조사하고, 인터뷰나 설문 조사 등을 한다.

▷요구사항에 관한 지식을 기반으로 관련있는 엔티티들과 이들의 애트리뷰트들이 무엇인가, 엔티티들 간의 관계가 무엇인가 등을 파악한다.

 

●개념적 설계

▷모든 물리적인 사항과 독립적으로 설계한다.

▷스키마 정보만 고려하며, 인스턴스(데이터)는 고려하지 않는다.

▷완성된 개념적 스키마(ER 스키마)는 ER 다이어그램으로 표현된다.

●DBMS 선정

 

●논리적 설계

▷선택한 DBMS의 데이터 모델을 사용하여 논리적 스키마(외부 스키마도 포함)를 생성한다.

 

●정규화

▷더 정제하는 과정을 거친다.

●물리적 설계

▷처리 요구사항들을 만족시키기 위해 저장 구조와 인덱스 등을 결정한다.

 

●트렌젝션 설계

 

◆ER 모델

▷현재는 EER(Enhanced Entity Relationship) 모델이 널리 사용되고 있다.

▷물리적인 데이터베이스 설계의 효율성에 관심을 두지 않는다.

▷높은 수준으로 추상화 한다.

▷이해하기 쉽다.

▷사람들이 응용에 대해 생각하는 방식과 가깝다.

▷ER 모델은 쉽게 관계 데이터 모델로 사상된다.

▷설계자들이 최종 사용자들과 의사소통을 하는데 적합하다.

▷다수의 CASE 도구를 사용하여 만든다.

▷ER 모델링은 현재응 구형 기법이나 역사적이고 교육적인 효과가 높다.

 

●ER 다이어그램

▷엔티티 타입, 관계 타입, 이들의 애트리뷰트들을 그래픽하게 표현한 것이다.

 

◆엔티티

▷독립적으로 존재하면서 고유하게 식별이 가능한 실세계의 객체이다.

▷엔티티들은 엔티티 타입으로 분류된다.

●엔티티 타입(엔티티 집합)

▷동일한 애트리뷰트들을 가진 엔티티들의 모임(틀)이다.

▷데이터베이스는 엔티티 집합의 관계들에 관한 정보도 포함한다.

▷ER 다이어그램에서 엔티티 타입은 직사각형으로 나타낸다. (//릴레이션)

 

●애트리뷰트(=특성)

▷하나의 엔티티는 애트리뷰트들의 집합으로 설명된다.

▷각 애트리뷰트가 가질 수 있는 값들의 집합이 있다. (도메인)

▷한 엔티티 타입 내의 엔티티들은 서로 식별이 가능해야 한다. (기본 키)

▷ER 다이어그램에서 기본 키에 속하는 애트리뷰트는 기본 키에 밑줄을 긋는다.

▷인위적으로 기본 키 애트리뷰트를 엔티티 타입에 추가하기도 한다.

▷요구사항 명세에서 명사나 형용사로 표현된다.

▷엔티티는 주로 명사적인 역할을 한다.

▷관게는 주로 동사적인 역할을 한다.

▷엔티티과 애트리뷰트의 차이점은 엔티티는 독립적인 의미를 갖는데 반해서 애트리뷰트는 독립적인 의미를 갖지 않는다.

▷ER 다이어그램에서 애트리뷰트는 타원형으로 나타낸다.

▷애트리뷰트와 엔티티 타입은 실선으로 연결한다.

 

◆

●단순 애트리뷰트(simple attribute)

▷더 이상 다른 애트리뷰트로 나눌 수 없는 애트리뷰트이다.

●복합 애트리뷰트(composite attribute)

▷두 개 이상의 애트리뷰트로 이루어진 애트리뷰트이다.

 

●단일 값 애트리뷰트(single-valued attribute)

▷각 엔티티마다 정확하게 하나의 값을 가지는 애트리뷰트이다.

●다치 애트리뷰트(multi-valued attribute)

▷각 엔티티마다 여러 개의 값을 가질 수 있는 애트리뷰트이다.

▷이중 선 타원으로 표현한다.

 

●저장된 애트리뷰트(stored attribute)

▷다른 애트리뷰트와 독립적으로 존재하는 애트리뷰트이다.

●유도된 애트리뷰트(derived attribute)

▷다른 애트리뷰트의 값으로부터 얻어진 애트리뷰트이다.

▷점선 타원으로 표현한다.

 

◆관계와 관계 타입

●엔티티 간의 관계(relationship)

▷ER 다이아그램에서 다이어몬드로 표기하고, 관계 타입이 서로 연관시키는 엔티티 타입들을 관계 타입에 실선으로 연결한다.

 

●관계 집합

▷동질의 관계들의 집합이다.

 

●관계 타입

▷관계의 특징을 기술하는 애트리뷰트들을 가질 수 있다.

▷관계 타입은 키 애트리뷰트를 가지지 않는다.

▷하나의 관계 집합 내에서 특정 관계의 식별은 참여하는 엔티티들의 키들을 통해 된다.

▷동질의 관계들의 틀로서 하나의 관계와 구분해야 한다.