데이터베이스

데이터베이스(Database)는 특정 조직의 업무를 수행하는 데 필요한 상호 관련된 데이터들의 모임을 말한다. 베이스(Base)란 기지(基地)라는 의미를 가지고 있다. 유추해서 생각해보면 데이터베이스는 데이터를 공급하는 보급기지로 풀이된다.

데이터베이스 설계

데이터베이스 설계는 컴퓨터 세계의 데이터로 변환하기 위한 데이터베이스 모델링 과정을 말한다.

데이터베이스 생명주기

데이터베이스의 생명주기는 다음과 같다.

1. 요구 조건 분석(Requirements Analysis) 2. 설계(Design) 3. 구현(Implementation) 4. 운영(Operation) 5. 감시와 개선(Moniotoring and Tuning)

데이터베이스 설계 단계

데이터베이스 생명주기 중 1~3단계 과정이다.

1. 요구 조건 분석: 요구 조건 명세서 작성 2. 개념적 설계: 개념스키마, 트랜잭션 모델링, E-R모델 3. 논리적 설계: 목표 DBMS에 맞는 스키마를 설계한다. 4. 물리적 설계: 목표 DBMS에 맞는 물리적 구조의 데이터로 변환한다. 5. 구현: 특정 DBMS의 DDL로 데이터베이스를 생성한다.

제1단계: 요구 조건 분석 단계

요구 조건 분석 단계에서는 시스템의 운영상태 등을 분석하고 사용자들의 요구사항에 대한 분석까지 포함하는 단계를 말한다. 소프트웨어 공학에서 눈덩이 효과를 보면 요구 조건 분석 단계에서 중요성을 알 수 있다. 분석 단계에서 작은 오류가 발생하면 경사면에서 굴러오는 눈덩이처럼 나중에는 커다란 시스템 완성 단계의 누적된 오류가 발생한다.

요구 조건 분석을 위한 방법으로는 인터뷰와 설문조사 등 있다.

인터뷰 진행 절차는 다음과 같은 방식으로 진행된다.

1. 계획과 준비단계: 인터뷰 일정, 인터뷰 지침, 인터뷰를 하는 요지, 인터뷰 시 기록 양식 등을 결정하는 단계이다. 2. 인터뷰 수행 단계: 핵심 사항 및 상세 면담 기록을 작성한다. 3. 인터뷰 결과 분석 단계: 인터뷰 결과를 분석한다. 4. 분석 및 피드백 단계: 인터뷰 분석 결과를 승인 요청하고 승인 완료 후에는 프로젝트를 진행한다.

제2단계: 개념적 설계(Conceptual Design) 단계

개념적 설계(Conceptual Design)는 사용자들의 요구사항을 이해하기 쉬운 형식으로 간단히 기술하는 단계이다. DBMS에 독립적이고 고차원적인 표현 기법으로 기술한다. 개념적 설계를 표현하는 방법에는 객체 데이터 모델(Conceptual Data Model), E-R 다이어그램이 있다.

ERD(E-R 다이어그램)

ERD 또는 E-R(Entity-Relationship) 다이어그램이라고도 한다. E-R 다이어그램을 표현하는 방법에는 정보공학 · IE(Information Engineering) 방식, Indeflx(Integration Definition for Inforamtion Modeling) 방식이다.

엔티티 도출

엔티티(Entity)는 업무의 관심 대상이 되는 정보를 갖고 있거나 그에 대한 정보를 관리할 필요가 있는 유형을 말한다. 쉽게 말하면 실체, 개체를 말한다.

1. 업무 기술서에서 명사를 찾아 표시 2. 중복된 명사, 불명확한 개념, 광범위한 명사는 제거, 동의어 통일, 업무 진행 과정을 나타내는 단어 제거, 속성은 따로 분리한다. 3. 또는 직관적인 방법으로 엔티티를 찾을 수 있다. (핵심 엔티티를 찾아내고 앞에서 설명한 절차대로 나머지 엔티티를 찾아가면 쉽게 엔티티를 도출 할 수 있다.)

주 식별자 정의

주 식별자 또는 기본키(Primary Idntifier, PK; Primary Key)는 엔티티에 소속된 인스턴스(같은 클래스에 속하는 개개의 객체)들을 구분하는 기준이 되는 속성이다. 만일 어떤 속성 x가 엔티티의 주 식별자라면 그 엔티티에 속한 모든 인스턴스 속성 x 값을 비교했을 때 중복된 값이 나타나지 않아야 한다. 후보 식별자 중 가장 중요한 하나를 주 식별자로 나머지를 대체키로 지정한다.

관계의 정의

관계(relation)는 두 엔티티(entity) 타입 사이의 관계를 의미한다. 업무 흐름을 제대로 파악해야만 관계를 도출 할 수 있다. 어떤 엔티티 x의 정보가 만들어지기 위해서는 다른 엔티티 y의 정보를 필요로 하는 관계에 있을 경우 엔티티 y는 엔티티 x와의 관계를 가지게 되며 엔티티 y는 엔티티 x의 부모 엔티티가 된다.

외래식별자의 정의

외래식별자 또는 외부식별자, 외부키(Foreign Identifier, FK; Foreign Key)는 엔티티 간의 관계로부터 도출한다. 관계가 있는 두 엔티티를 부모와 자식으로 구분한다. 부모 엔티티의 주 식별자 속성을 자식이 가지고 있는가 확인하고 없으면 추가해야 한다. 즉, 두 엔티티 간의 관계를 결정하여 주는 속성으로 관계에 의한 자식 엔티티에 위치하고 있으며 부모 엔티티의 주 식별자가 같은 값을 갖는다.

제3단계; 논리적 설계(logical Design) 단계

논리적 설계(logical Design) 단계는 개념적 설계 단계에서 생성한 개념적 스키마(E-R 다이어그램)을 입력하여 특정 데이터베이스가 수행할 수 있는 스키마를 정의한다. 즉, E-R 다이어그램을 특정 DBMS를 위한 논리적 구조로 변형하는 것을 말한다. 이 과정에서 결과물은 릴레이션(관계 혹은 관계 데이터베이스) 스키마이다.

논리적 데이터 모델에는 관계 데이터 모델(Relational Data Model), 네트워크 데이터 모델(Network Data Model), 계층 데이터 모델(Hierarchical Data Model)이 있다.

• 관계 데이터 모델: 릴레이션(Relation) 즉, 표 또는 테이블(table)의 집합으로 되어있다.
• 네트워크 데이터 모델: 데이터 구조도가 네트워크(Network) 즉, 그래프의 형태를 취하고 있다.
• 계층 데이터 모델: 데이터 구조도가 트리(Tree) 형태이다.

규칙1: 모든 개체는 릴레이션으로 변환한다.

E-R 다이어그램의 각 개체를 하나의 릴레이션으로 변환한다. 개체(엔티티, Entity)의 이름을 릴레이션 이름으로 하고 개체가 가진 속성도 릴레이션 속성으로 그대로 변환한다. 개체가 가지고 있는 키 속성은 그대로 릴레이션의 기본키로 변환한다.

단, 개체가 가지고 있는 속성이 복합 속성인 경우 복합 속성을 구성하고 있는 단순 속성만 릴레이션의 속성으로 변환한다.

규칙2: 다대다(n:m) 관계는 릴레이션으로 변환한다.

E-R 다이어그램에 있는 다대다(n:m) 관계를 하나의 릴레이션으로 변환한다. 관계 이름을 릴레이션의 이름으로 하고 관계의 속성도 릴레이션 속성으로 그대로 변환한다. 단, 관계를 맺고 있는 개체가 무엇인지 중요하므로, 관계를 맺고 있는 개체들을 규칙1에 따라 변환한 후 이 릴레이션들의 기본키를 관계 릴레이션에 포함시키고 외래키로 지정한다. 그리고 이 외래키들을 조합하여 관계 릴레이션의 기본키로 지정한다.

고객 릴레이션의 기본키인 고객번호 속성과 상품 릴레이션의 기본키인 상품번호 속성을 가져와 주문 릴레이션에 포함시키고 외래키로 지정한다. 그런 다음 두 외래키를 조합하여 주문 릴레이션의 기본키로 지정한다. 필요하다면 주문번호 속성과 같은 별도의 기본키를 지정할 수도 있다.

규칙3: 일대다(1:n) 관계는 외래키로 표현한다.

일반 개체들이 참여하는 일대다(1:n) 관계는 릴레이션으로 변환하지 않고 외래키로만 표현한다. 관계를 맺고 있는 개체들을 규칙1에 따라 변환한 릴레이션 중에서, 일대다(1:n) 관계의 1측 개체 릴레이션의 기본키를 가져와 n측 개체 릴레이션에 포함시키고 외래키로 지정한다. 관계의 속성들도 n측 개체 릴레이션에 포함시킨다. 단, 외래키나 관계의 속성을 포함시킬 때 해당 릴레이션의 원래 개체 속성과 이름이 같으면 이름을 변경해야 한다.

만약 n측 개체 릴레이션의 기본키를 가져와 1측 개체 릴레이션에 외래키로 포함시키면 해당 외래키가 다중 값을 가져 릴레이션의 특성을 위반하게 되므로 반드시 1측 개체 릴레이션의 기본키를 n측 개체 릴레이션의 외래키로 지정해야 한다.

예외적으로, 약한 개체가 참여하는 일대다 관계는 외래키를 포함해서 기본키로 지정한다. 규칙 3처럼, 약한 개체가 참여하는 일대다(1:n) 관계도 릴레이션으로 변환하지 않고 외래키로만 표현한다.

규칙4: 일대일(1:1) 관계는 외래키로 표현한다.

E-R 다이어그램에 있는 일대일(1:1) 관계도 일대다(1:n) 관계처럼 릴레이션으로 변환하지 않고 외래키로만 표현한다. 이때, 데이터의 중복을 피하려면 개체가 관계에 참여하는 특성에 따라 약간 다르게 처리해야 한다.

규칙4-1: 일반적인 일대일 관계는 외래키를 서로 주고 받는다.

일반적인 일대일(1:1) 관계는 릴레이션으로 변환하지 않고 외래키로만 표현한다. 관계를 맺고 있는 개체들을 규칙1에 따라 변환한 릴레이션들이 서로의 기본키를 주고 받아 이를 외래키로 지정한다. 이때, 관계가 가지고 있는 속성들은 관계에 참여하는 개체를 변환한 릴레이션에 모두 포함시킨다.

규칙4-2: 일대일 관계에 필수적으로 참여하는 개체의 릴레이션만 외래키를 받는다.

일대일(1:1) 관계를 맺고 있는 두 개체 중 관계에 필수적으로 참여하는 개체에 대응하는 릴레이션에만 외래키를 포함시킨다. 즉, 관계에 필수적으로 참여하는 개체에 해당하는 릴레이션이 선택적으로 참여하는 개체에 해당하는 릴레이션의 기본키를 받아 외래키로 지정한다. 이때, 관계가 가지고 있는 속성들도 관계에 필수적으로 참여하는 개체에 해당하는 릴레이션에 함께 포함시킨다.

규칙4-3: 모든 개체가 일대일 관계에 필수적으로 참여하면 릴레이션 하나로 합친다.

일대일(1:1) 관계를 맺고 있는 두 개체가 모두 관계에 필수적으로 참여한다면 그만큼 관련성이 있는 개체라는 의미다. 그러므로 두 개체에 해당하는 릴레이션들을 하나로 합쳐 표현한다. 관계의 이름을 릴레이션의 이름으로 사용하고, 관계에 참여하는 두 개체의 속성들도 관계 릴레이션에 모두 포함시킨다. 그리고 두 개체 릴레이션의 키 속성을 조합하여 관계 릴레이션의 기본키로 지정한다.

규칙5: 다중 값 속성은 릴레이션으로 변환한다.

관계 데이터 모델의 릴레이션에서는 다중 값을 가지는 속성을 허용하지 않는다. 그러므로 E-R 다이어그램에 있는 다중 값 속성은 그 속성을 가지고 있는 개체에 해당하는 릴레이션이 아닌 별도의 릴레이션을 만들어 포함시킨다. 새로 만들어진 릴레이션에는 E-R 다이어그램에서 다중 값 속성으로 표현된 속성뿐만 아니라 그 속성을 가지고 있는 개체에 해당하는 릴레이션의 기본키를 가져와 포함시키고 이를 외래키로 지정한다. 새로 만들어진 릴레이션의 이름은 자유롭게 정하고, 기본키는 다중 값 속성과 외래키를 조합하여 지정한다.

기타 고려 사항

규칙 4-1처럼 외래키를 서로 주고 받지 않고 릴레이션으로 변환하면 다음과 같다. 다대다(n:m) 외의 관계를 릴레이션으로 변환해도 된다. 하지만 그러면 생성되는 릴레이션의 개수가 많아져 릴레이션을 관리해야 하는 DBMS의 부담이 커지게 된다. 그러므로 릴레이션의 개수가 불필요하게 늘어나지 않도록 외래키만으로도 표현이 가능한 일대일(1:1)이나 일대다(1:n) 관계는 릴레이션으로 변환하지 않는 것이 좋다.

E-R 다이어그램에서 사원 개체가 자기 자신과 관리 관계를 맺고 있는 것도 있다. 사원 개체는 상사와 부하직원이라는 서로 다른 역할로 관계를 맺고 있지만 관리 관계에 참여하는 실제 개체는 사원 개체 하나뿐이다. 하나의 개체만 관계에 참여하는 특수한 형태이지만 순환 관계도 기본 규칙을 그대로 적용한다. 먼저 사원 개체를 규칙1에 따라 사원 릴레이션으로 변환한다.E-R 다이어그램에서 관리 관계는 일대다(1:n)이므로 릴레이션을 생성하지 않고 외래키로만 표현한다.

ISA

ISA는 두 개체(엔티티)가 다른 개체의 하위 분류일 경우가 있을 수 있다. ISA라는 말을 안에 써넣은 삼각형으로 표시하고 수퍼클래스는 위쪽에 다른 하위 분류의 서브클래스들은 아래쪽에 그린다.

수퍼클래스인 학생 릴레이션의 기본키인 학번이 서브클래스 재학생, 휴학생, 졸업생 릴레이션의 외래키로 들어간다.

용어사전(Data Dictionary) 정의

논리적 데이터베이스 설계나 물리적 데이터베이스 설계시 사용되는 용어 정의 문서를 말한다. 용어사전의 정의 방법에는 다음과 같은 방법으로 진행한다.

1. 개체(엔티티) 이름과 속성 이름들을 모아 리스트를 만든다. 2. 엔티티 이름이나 속성 이름이 여러 단어를 포함할 경우 분리한다. 3. 마지막 단어를 기준으로 정렬한다. 4. 단어에 대해 영어 단어를 붙이고 용어의 의미를 설명한다.

도메인 정의

물리적 데이터베이스에서 개체(엔티티)의 속성에 대응하는 테이블의 열(칼럼)에 대한 데이터 타입과 크기, 데이터에 대한 제약 사항등을 지정하는 것이다.

도메인을 정의하는 방법은 다음과 같다.

1. 각 개체(엔티티)에서 소겅들을 모아 리스트를 만든다. 2. 속성 이름이 여러 단어를 포함할 경우 분리한다. 3. 마지막 단어를 기준으로 정렬한다. 4. 도메인을 정한다. 5. 도메인만 모아 정리한다.

1~3은 앞서 ‘용어사전’을 통해 정리하였으므로 4.부터 작업을 진행하면 된다.

4. 도메인을 정한다.

5. 도메인만 모아 정리한다.

제4단계: 물리적 설계(physical Design) 단계

물리적 설계 단계(Physical Design)는 다음 일련의 과정을 거쳐 물리적 설계를 한다.

사용 DBMS 결정 → 데이터 타입 크기 결정 → 데이터 용량 및 설계 및 업무 프로세스 분석 → 역정규화 → 무결성 제약조건 정의 → 인덱스 정의 → 데이터베이스 생성

물리적 설계 시 고려사항은 응답시간을 최소화해야 하고 저장공간을 효율화 해야 하며, 트랜잭션 처리도(처리능력)를 고려 해야 한다.

데이터베이스 설계를 위한 인덱스 활용

자료 검색 방법에는 두가지 방법이 있다. 테이블을 처음부터 끝까지 검색하는 방법인 FTS(Full Table Scan) 방법과 인덱스를 통해 부분 검색을 하여 인덱스에 저장된 테이블의 ROW ID를 가지고 테이블을 검색한 후 정보를 가져오는 검색방법인 인덱스 스캔(Index scan) 방법이 있다.

• 논리적 구분에 따른 인덱스

• 물리적 구분에 따른 인덱스

성능 향상을 위한 인덱스 관리 방법에는 다음과 같다.

1. 인덱스 정보 확인 2. 인덱스 재구축 3. 인덱스 삭제

1. 인덱스 정보 확인

• DBA_INDEXES는 DBA 권한으로 확인할 수 있는 뷰이다.
• USER_INDEXES는 일반 사용자 권한으로 자신이 생성한 인덱스 정보를 확인할 수 있는 뷰이다.
• ALL_INDEXES는 일반 사용자 권한으로 다른 사용자가 생성한 인덱스 정보를 확인할 수 있는 뷰이다.

2. 인덱스 재구축

[인덱스 재구축 SQL] SQL>ALTER INDEX idx_ename_emp REBUILD TABLESPACE indx02;

3. 인덱스 삭제 SQL> DROP INDEX idx_ename_emp;

역정규화(Denormalization)

역정규화(Denormalization)은 시스템 성능을 고려해서 기존 설계를 재구성하는 것을 말한다. 즉, 이전에 정규화된 데이터베이스에서 성능을 개선하기 위해 사용되는 전략이다. 역정규화는 비정규화(unnormalized form)와는 구별된다. 데이터베이스와 테이블은 이들을 효율적으로 역정규화하기 위해 우선 정규화되어야 한다. 즉, 지나친 정규화는 성능 저하를 불러 일으키며, 적절한 정규화와 역정규화를 사용해야 한다.

역정규화의 유형에는 다음과 같다.

1. 칼럼 역정규화(데이터의 중복) 칼럼(열) 역정규화는 테이블 간의 조인을 줄이고자 데이터의 중복을 허용하는 방법이다.

예를 들면 ‘학번’에 따른 ‘이름’과 ‘학과명’을 알기 위해서는 두 릴레이션을 조인을 해야 한다. 이러한 불편함을 해소하기 위해 칼럼 역정규화를 하여 데이터의 중복을 허용하는 것이다.

2. 테이블 분리 테이블 분리는 단어 그대로 테이블 하나로 여러 테이블로 분리하는 방법이다.

예를 들면 사진 열(칼럼)을 포함한 학생테이블인 경우이다. 사진 파일의 경우 일반 데이터베이스의 크기보다 크기 때문에 테이블을 분리하는 것이 좋다.

3. 테이블 통합 테이블 통합은 정규화를 통해 나눈 테이블을 다시 하나의 테이블로 통합하는 작업이다. 전체 테이블을 통합하는 것에서 앞서 ‘칼럼 역정규화’와 차이가 있다.

4. 요약 테이블 생성 요약 테이블 생성은 논리적 결합 작업으로 시스템 성능이 저하되는 단점을 개선하려고 생성한다. 즉, 불필요한 정보를 제거하고 요약하는 것을 말한다.

데이터베이스 용량 설계

데이터베이스 용량 설계는 테이블에 저장해야 할 데이터량과 각종 오브젝트가 차지하는 볼륨이 얼마나 많은 디스크 공간을 차지할 것인지 예측하여 반영하는 것이다.

1. 데이터베이스 용량 분석의 목적

• 디스크 사용의 효율 최대화
• 집중화된 디스크의 입출력 부하를 분산
• 디스크 입출력 로드(load)를 최소화하여 데이터 접근 성능 향상
• 데이터벵스 오브젝트의 추가적인 스페이스 확장 작업 발생을 최소화

2. 데이터베이스 용량 분석 절차(순서)

오브젝트 용량 산정 → 테이블스페이스 용량 산정 → 디스크 용량 산정

• 1단계: 용량분석을 위한 기초 데이터를 수집한다.
• 2단계: 기초 데이터를 활용하여 DBMS에서 이용하는 오브젝트별로 용량을 산정한다.

트랜잭션

트랜잭션(transaction)은 데이터베이스 내에서 하나의 그룹으로 처리해야 하는 명령문(또는 데이터베이스 연산)들을 모아놓은 논리적인 작업 단위를 말한다. 트랜잭션은 장애가 발생했을 때 데이터를 복구하는 작업의 단위가 된다. (데이터베이스 연산은 SQL 문으로 표현되기 때문에 트랜잭션 작업 수행에 필요한 SQL 모임으로 이해해도 된다.) 트랜잭션을 관리함으로써 데이터베이스의 회복과 병행 제어가 가능해져 결과적으로 데이터베이스를 일관된 상태를 유지할 수 있다.

트랜잭션의 특징

트랜잭션의 특징은 원자성, 일관성, 격리성/고립성, 영속성/지속성이다. 각 영어 단어들의 첫 자를 따서 ACID 특성이라고도 한다.

원자성(Atomicity)

원자성(Atomicity)은 트랜잭션을 구성하는 연산들이 모두 정상적으로 실행되거나 하나도 실행되지 않아야 한다는 all-or-nothing 방식을 의미한다.

• all: 정상적으로 실행하여 종료되었다면 데이터베이스 내 연산 결과 전부 반영
• nothing: 장애가 발생하면 처음 상태로 모두 되돌리거나 전부 취소된다.

일관성(consistency)

일관성(consistency)은 트랜잭션이 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지되어야 한다. 즉, 트랜잭션이 수행되기 전에 데이터베이스가 일관된 상태였다면 트랜잭션의 수행이 완료된 후 결과를 반영한 데이터베이스도 또 다른 일관된 상태가 되어야 한다는 의미이다.

격리성/고립성(isolation)

격리성(isolation) 또는 고립성이라고도 하는데, 현재 수행 중인 트랜잭션이 완료될 때까지 트랜잭션이 생성한 중간 연산 결과에 다른 트랜잭션들이 접근할 수 없음을 의미한다. 트랜잭션은 동시수행 할 수 없고 순차실행(순서적으로 실행)해야 한다.

영속성/지속성(Durability)

영속성(Durability) 또는 지속성은 트랜잭션이 모든 작업을 성공적으로 수행 완료하여 데이터베이스 내에 반영했다면, 트랜잭션의 결과는 영구적이어야 한다. 즉, 시스템 장애가 발생하더라도 트랜잭션의 작업 결과는 없어지지 않고 데이터베이스에 그대로 남아 있어야 한다는 말이다.

트랜잭션 연산

트랜잭션의 수행과 관련하여 주로 사용하는 연산에는 작업 완료를 의미하는 commit 연산과 작업 취소를 의미하는 rollback 연산이 있다.

commit 연산(완료)

트랜잭션이 행한 연산이 완료된 것을 commit 문장을 통해 트랜잭션 관리자에게 알려주는 연산을 의미한다. 즉, 트랜잭션이 성공적으로 수행되었음을 선언하고 작업 완료하는 것이다.

rollback 연산(복귀)

해당 트랜잭션이 행한 모든 연산을 취소시키거나 트랜잭션을 재시작하도록 하는 연산을 의미한다. 즉, 트랜잭션이 수행을 실패했음을 선언하고 작업 취소하는 것이다.

트랜잭션의 상태

트랜잭션은 5가지 상태 중 하나에 속하게 된다. 트랜잭션이 수행을 시작하면 활동 사태가 되고 활동 상태의 트랜잭션이 마지막 연산을 처리하고 나면 부분 완료 상태, 부분 완료 상태의 트랜잭션이 commit 연산을 실행하면 완료 상태가 된다. 활동 상태나 부분 완료 상태에서 여러 원인들로 인해 더는 정상적인 수행이 불가능 할 경우 트랜잭션은 실패 상태가 되고, 실패 상태의 트랜잭션은 rollback 연산의 실행으로 철회 상태가 된다. 트랜잭션이 완료 상태이거나 철회 상태가 되면 트랜잭션이 종료된 것으로 판단한다.

• 활동(Active): 트랜잭션이 Begin_transaction으로부터 실행을 시작하였거나 현재 실행중인 상태를 의미한다. 즉, 트랜잭션이 수행을 시작하여 현재 수행중인 상태를 활동 사태라고 한다. 활동 상태인 트랜잭션은 상황에 따라 부분 완료 상태나 실패 상태로 전이 된다.

• 부분 완료(Partially Committed): 트랜잭션이 마지막 명령문을 실행시킨 직후의 상태를 의미한다. 이는 트랜잭션의 모든 연산을 처리가 끝난 상태이지만 트랜잭션이 수행한 최종 결과를 데이터베이스에 아직 반영하지 않은 상태이다. 즉, 아직은 트랜잭션의 수행이 성공적으로 완료됐다고 볼 수 없다. 부분 완료 상태의 트랜잭션은 상황에 따라 완료 상태나 실패 상태로 전이 된다.
• 실패(Failed): 트랜잭션 실행 중에 장애나 오류가 발생하여 정상적인 실행을 더 이상 할 수 없는 상태를 의미한다. 이는 트랜잭션이 더는 정상적으로 수행을 계속할 수 없을 때 실패 상태가 된다.

• 철회(Aborted): 트랜잭션 실행에 실패하여 rollback 연산을 수행한 상태를 의미한다. 철회상태의 트랜잭션 조치에는 다음과 같다.
  • 트랜잭션 재시작: 트랜잭션 철회 원인이 트랜잭션 자체적인 논리적 오류가 아닌 하드웨어나 스프트웨어 오류로 인해 중단된 경우에 사용한다.
  • 트랜잭션 강제 종료: 트랜잭션 철회 원인이 트랜잭션 내부적으로 논리적 오류가 발생하여 오류를 수정해야만 하는 상황이거나 얻고자 하는 데이터가 데이터베이스내에 존재하지 않는 경우에 사용한다.

• 완료(Committed): 트랜잭션 실행이 성공적으로 완료되어 commit 연산을 수행한 상태를 의미한다.