RDBMS 이해

28 May 2022 in Study on Oracle

RDBMS에 대해 이해해보자.

• 1. DBMS란?
  • 데이터베이스 개요
  • DBMS
• 2. RDBMS란?
  • RDBMS 이해
    • 데이터베이스 정의
    • 데이터베이스 특징
    • 단점
    • DBMS의 3가지 특성
    • Data 무결성(Integrity)이란?
    • DBMS 구현을 위한 추상적 설계 표준
    • DBMS 구현을 위한 추상적 설계 표준 (구체화)
  • DBMS 유형
    • 계층적 데이터 모델(Hierarchical Data Model)
    • 네트워크 데이터 모델(Network Data Model)
    • 관계형 데이터 모델(Relational Data Model)
  • 관계형 모델의 구성요소
• 3. DBMS Transaction
  • Transaction이란?
  • ACID 속성
  • Transaction 관리
    • UNDO
    • REDO

---

1. DBMS란?

DBMS란 DataBase Management System의 약자로, 우리말로 데이터베이스 관리 시스템이다.

데이터베이스 개요

• 자료(Data)
  • 현실 세계에서 관찰이나 측정을 통해 수집한 단순한 사실이나 값
• 정보(Information)
  • 의사 결정에 도움을 줄 수 있는 유용한 형태
  • 자료를 가공(처리)해서 얻을 수 있는 결과를 의미 (예: 변화율)
• 데이터베이스(Database)
  • 어느 한 조직체의 여러 응용 시스템들이 공동으로 사용할 수 있도록 통합하여 저장한 운영데이터의 집합(System)
  • 공동의 목적을 지원하기 위한 서로 관련된 자료들의 모임
  • 주제와 관련된 의미 있는 데이터들의 모음

즉 데이터베이스는 자료(Data)들의 모임이며, 이 자료들을 SQL 등을 통해 가공(조회, 분석)하여 정보(information)로 나타낼 수 있다.
변화율, 증감, 평균값 등이 이에 해당한다.
다음의 예를 보자.

위는 각 통신사별 월 가입자 수를 나타내는 테이블이다.
파란색으로 칠해진 1월, 2월, 3월 열은 자료(Data), 즉 단순한 사실이다.
주황색으로 칠해진 2월 증감, 3월 증감 열은 각 월 별 가입자 수의 자료(Data)를 가공해서 얻은 정보(Information)이다.

이러한 자료와 정보들의 모임이 데이터베이스이다.
이렇게 만들어진 데이터베이스는 DBMS에 의해 통합, 저장, 관리된다.

DBMS

• DBMS(DataBase Management System)
  • DBA / DB사용자 / 응용프로그램과 데이터베이스 사이의 중재자
  • 데이터베이스에 대한 모든 접근을 처리하는 소프트웨어적 시스템
  • DBMS는 데이터베이스 언어를 가지고 있으며 이를 통해 데이터의 SELECT / INSERT / UPDATE / DELETE 등의 Transaction을 수행

DBMS는 데이터베이스를 좀 더 효율적으로 관리할 수 있도록 만들어진 소프트웨어이다.
사용자가 웹 또는 앱을 통해 데이터를 입력하면 이는 DBMS에 의해 데이터베이스의 특정 테이블에 파일로서 저장된다.
내부적으로는 DBMS의 언어인 SQL을 통해 Transaction이 수행된다.

이러한 DBMS는 크게 두 가지 키워드로 나누어진다.
첫 번째는 RDBMS, 두 번째는 NoSQL(Not Only SQL)이다.
DBMS가 RDBMS, NoSQL 계열로 나뉘어지는 것이다.

---

2. RDBMS란?

RDBMS는 DBMS앞에 R이 붙었다. 여기서 R은 Relational, 관계형이라는 의미이다.

RDBMS 이해

데이터베이스 정의

• 통합된 데이터(integrated data)
  • 산재되어 있지 않고 한 곳에 있어야함
  • 모든 데이터가 중복을 최소화하면서 통합 -> 데이터 무결성(Data Integrity)을 보장함
• 저장 데이터(stored data)
  • 컴퓨터에서 처리가 가능하도록 전자적 형태로 저장
  • 디스크, 테이프 등 컴퓨터가 접근 가능한 저장 매체에 저장된 데이터
• 운영 데이터(operational data)
  • 조직의 업무 수행, 고유 기능을 수행하기 위해 반드시 유지되어야 할 데이터
• 공용 데이터(shared data)
  • 한 조직의 여러 응용 시스템들이 공동으로 소유, 유지, 이용하는 데이터
  • 접근(이용)에 관해서는 권한으로 접근제한이 가능함

데이터베이스 특징

• 실시간 접근 가능(real-time accessibilities) -> online processing
  • 수시적이고 비정형적인 질의(query)에 대하여 실시간 처리(real-time processing)로 응답
• 계속적인 변화(continuous evolution)
  • 새로운 데이터의 삽입(insertion)이나 삭제(deletion), 갱신(update)으로 항상 변하고, 그 속에서 현재의 정확한 데이터를 유지할 수 있음
• 동시 공유(concurrent sharing) -> 보안 설정을 통한 접근제어 가능
  • 여러 사용자(multi-user)가 동시에 자기가 원하는 데이터에 접근
• 내용에 의한 참조(concurrent reference)
  • 데이터의 레코드 위치(location)나 주소(address)가 아닌 사용자가 요구하는 데이터의 내용(contents), 즉 데이터가 가지고 있는 값에 따라 참조
  • 모든 레코드들은 물리적 위치와 상관없이 하나의 논리적 단위로 취급되고 접근

강의중엔 RDBMS 이해로서 설명된 내용이지만, 많은 곳에서 데이터베이스 정의, 데이터베이스 특징으로서 기술되어 있기에 나누었다.

데이터가 테이블에 저장되는 순간, 주소가 발생하게 된다.
그 주소를 RowID라고 한다.
실제로 SELECT문을 통해 테이블로부터 RowID를 조회하면, 다음과 같은 결과(예시)를 얻을 수 있다.

AAAFf/AAFAAAADNABK

이 18자 문자열은 Base64로 인코딩된 값이다.
이를 열어보면 실제위치(disk, file, block, row)를 알 수 있다.

단점

• 운영비 증가
  • 추가적인 하드웨어 및 DBMS 운영자 필요

• 데이터베이스 처리 및 백업과 복구의 복잡성

• 시스템 장애에 취약

DBMS의 3가지 특성

• 데이터의 논리적 독립성
  • 한 속성에 가해진 변경이 동일한 테이블에서 다른 속성에 영향을 주지 않는 것을 의미
  • 응용프로그램에 영향을 주지 않고 데이터 구조를 변경할 수 있게 하는 것
• 참조 무결성과 데이터 무결성
  • 응용프로그램 개발 시 무결성 제약 조건을 신경 쓰지 않아도 됨
  • 예를 들어 모든 부서가 보는 데이터 값은 항상 동일해야 함
• 비정규 질의
  • 사용자는 작업을 실행하는 방법을 명시하지 않고도, 데이터베이스에게 어떤 데이터를 조회할 것인지를 명령할 수 있음
  • 데이터 조회는 언제든지 수행 할 수 있어야 함

Table = 행(Data)과 열(구조)의 집합. 처음에는 제약조건을 걸지 않아도 되지만, 차후에는 데이터 보호하기 위한 수단으로서 무결성 제약조건과 같은 제약조건을 걸음.

Data 무결성(Integrity)이란?

• 데이터 무결성
  • 데이터 값이 정확한 상태임을 유지해야함(결함이 없음을 보장함)
• 데이터 정합성
  • 어떤 데이터들의 값이 지속적으로 서로 일치하는 상황을 유지할 수 있음(일관성)
• 참조 무결성
  • PK와 FK에 의해서 엮여있는 두 개의 테이블은 PK의 제약조건과 FK의 제약조건이 자동으로 그 기능을 발휘함
    • FK 칼럼에는 PK가 들어가있는 데이터만 저장이 됨
    • PK는 FK가 자기 자신의 데이터를 사용중일 경우 절대 PK에서 데이터를 삭제할 수 없음
• Entity(실체) 무결성
  • Entity는 모델링을 수행할 때 테이블이 되기 전 단계로서 고유하거나 null값을 가지면 안됨
• 도메인 무결성
  • 칼럼마다 데이터타입, 널값 허용 여부와 같은 규칙을 카테고리로서 도메인을 만듬
  • 도메인에 벗어날 경우 데이터가 들어갈 수 없음
• 업무 무결성
  • Oracle에서는 트리거(trigger)를 PrSQL이라는 언어를 통해서 개발할 수 있음
  • 업무적으로 수행되는 규칙에 트리거를 사용

DBMS 구현을 위한 추상적 설계 표준

데이터베이스를 설계하는 과정은 굉장히 복잡한 절차를 거치게 된다.
기본적으로는 외부 스키마, 개념 스키마, 내부 스키마로 나뉘는 총 3단계를 거치게 된다.

외부 스키마에서는 어떤 사람이 주로 데이터베이스를 사용할 것인지, 일반 사용자인지 관리자인지에 따라 분리한다.
어떤 인터페이스를 통할 것인지도 포함한다.

개념 스키마에서는 사용자들이 어떤 시스템을 요구하는지, 어떤 테이블을 요구하는지 등을 정의하는 과정이다.

내부 스키마에서는 이렇게 정의된 과정을 DBMS로 구현을 하고 실제로 물리 단계에 저장을 시켜서 사용자에게 언제든지 데이터를 제공할 수 있도록 한다.

• 외부 스키마(External Schema)
  • DB에 관한 개별 사용자의 관점
  • 외부 단계에서 다양한 개별 사용자나 응용 프로그램이 필요로 하는 데이터 구조를 정의한 것으로 여러 개 존재할 수 있음

외부에서 바라보는 시점에 따라서 어떻게 어떤 데이터를 처리할 수 있는지를 정의하는 과정이라고 요약할 수 있다.

• 개념 스키마(Conceptual Schema)
  • DB에 관한 사용자 공동체의 관점
  • 한 조직 전체를 위한 DB의 논리적인 구조
  • 개념 단계에서 기관의 입장에서 전체 DB를 정의한것
  • 개념 스키마는 단 하나만 존재
  • 외부/개념 사상(응용 인터페이스 : Application Interface)
    • 외부 스키마와 개념 스키마 간의 대응관계를 정의한 것이다. 개념 스키마가 변경되어도 응용 인터페이스를 수정하면 외부 스키마에 영향을 주지 않기 때문에 응용프로그램을 변경할 필요가 없다.
• 내부 스키마(Internal Schema)
  • DB에 관한 물리적 저장 장치의 관점
  • DB에 어떤 데이터가 어떻게 저장되는지를 표현하는 저장 구조
  • 실제로 저장된 내부 레코드의 형식, 인덱스 유무, 저장 데이터 항목의 표현 방법 등을 포함
  • 내부 단계에서 DB의 물리적 데이터 구조를 정의한 것으로 단 하나만 존재함
  • 개념/내부 사상(저장 인터페이스 : Storage Interface)
    • 개념 스키마와 내부 스키마의 대응 관계를 정의한 것이다. 내부 스키마가 변경되어도 저장 인터페이스를 수정하면 개념 스키마에 영향을 주지 않는다.

DBMS 구현을 위한 추상적 설계 표준 (구체화)

개념 단계에서 제공되는 논리적인 구조인 테이블을 내부 단계의 물리적 구조인 디스크, 블록, 파일이 받쳐줌.

DBMS 유형

계층적, 관게형, 네트워크 데이터베이스들은 모두 ER(Entity Relation)모델을 통해 구현 가능하다.
현재 우리가 사용하는 것은 관계형 모델이다.
ER 모델을 모든 타입이 사용할 수 있지만 가장 밀접한 형태는 관계형 데이터베이스 모델이다.
어떤 모델이든 업무를 잘 드러내는 설계가 가장 중요한 포인트이다.

계층적 데이터 모델(Hierarchical Data Model)

• 데이터를 저장하는 단위(Entity)의 구조가 상하 종속적인 관계로 구성
• 개체를 노드로 표현하고 개체 집합들 사이의 관계를 링크로 연결한 트리(Tree)형태의 자료구조 (예 : 탐색기)
• 마지막 정보의 변경 시 종속관계의 모든 정보를 수정해야 하는 종속성 문제점으로 데이터 활용의 비효율성을 가짐

네트워크 데이터 모델(Network Data Model)

• CODASYL이 제안(CODASYL DBTG 모델이라고도 함)
• 그래프를 이용해서 데이터 논리구조를 표현한 데이터 모델
• 상위와 하위 레코드 사이에서 다대다(N:M) 대응 관계를 만족하는 구조
• 비종속적 표현이 가능하지만, 복잡하여 조그만 문제에 대해서의 처리가 어려울 수도 있음

관계형 데이터 모델(Relational Data Model)

• 1970년 IBM의 연구원으로 있던 E.F.Codd가 수학적 기초에 근거를 두고 고안한 것이 관계형 데이터베이스(Relational Database)
• 기본 개념
  • 데이터베이스는 최소한의 의미를 가지는 테이블들로 구성되며 그 테이블들에 있는 필드(행에 속한 각각의 값)들로 연결한 것이다.
  • 필드 또한 가장 작은 논리적인 단위로 구분하는 것이 좋다.
• 장점
  • 업무 면화에 대한 적응 능력, 유지 보수 편리성, 높은 생산성, 응용프로그램의 개발 용이
• 단점
  • 시스템의 부하가 상대적으로 높음

• 개체 집합에 대한 속성 관계를 표현하기 위하여 개체를 테이블(table)로 사용하고 개체 집합들 사이의 관계는 공통 속성으로 연결하는 독립된 형태의 데이터 모델

하나의 부서에는 여러명의 사원이 존재할 수 있음.
즉, 일대다(1:N) 대응 관계를 가질 수 있음.

• 실체(Entity)와 관계(Relation)을 중심으로 기업의 정보 구조와 업무 프로세스를 정의함
  • 실체(Entity)란, 해당 기업에서 사용되는 Data(중요 요소)를 수집했을때, 그 중 대표할 수 있는 것으로 상위 집합 개념으로서 다른 데이터들을 하위 속성으로 가진다.

관계형 모델의 구성요소

• 관계형 데이터 모델 용어
  • Model of system in client's mind부터 Entity model of client's model까지가 모델링 단계이다
  • 관계형 데이터 모델
    • 개념 모델
    • 논리 모델
    • 물리 모델
  • 관계형 데이터베이스의 3요소
    • Entity
    • Relation = Attribute
  • 테이블(table)
    • 테이블은 행(Row)과 열(Column)로 이루어진 집합이다.
    • 행은 Data이고, 열은 구조(Structure)이다.
    • 3요소 중 Attribute로 컬럼을 만들고, 컬럼들의 datatype, size 등이 도메인이 된다.
    • 관계형 데이터베이스에 데이터를 저장할 수 있는 형식 테이블(Table=Relation), SQL에서 릴레이션보다는 테이블이란 용어를 사용한다.
    • 행과 열의 교차점은 원자 값(atomic value)이라는 오직 하나의 값으로 구성된다.
    • 테이블에서 행은 순서가 정해져 있지 않다.
    • 테이블의 내용은 실제적인 행의 집합으로 간주한다.

1번은 하나의 행(Row) Data이다.
2번은 Primary Key를 담고 있는 열로, 일반적으로 테이블의 첫 번째 컬럼으로 PK를 설정한다.
3번은 일반적인 열(Column)이다.
4번은 Foriegn Key를 담고 있는 열이다.
5번은 필드이다. 각각의 Data요소 하나를 의미한다.
6번은 Data의 중요한 요소중 하나인 Null(알 수 없는 값)이다.

위 요소들로 구성된 테이블은 엄격한 스키마 규칙으로 관리된다.
각 컬럼에는 각각의 스키마 규칙에 맞는 데이터만 들어갈 수 있다.
(ex. EMPLOYEE_ID에는 숫자만 들어갈 수 있다)

---

3. DBMS Transaction

Transaction이란?

• Transaction은 하나의 논리적 작업 단위를 구성하는 연산들의 집합
  • the unit of work
  • the unit of recovery
  • the unit of concurrency
• 특성
  • ACID
• 예
  • ATM 기기
  • 은행 거래
  • 주식 거래
  • 마일리지 적립 작업

ACID 속성

• 원자성(Atomicity)
  1. ALL OR NOTHING - 트랜잭션과 관련된 작업들이 모두 수행되었는지 아니면 모두 수행이 안되었는지를 보장
  2. 자금이체의 양쪽 계좌에 대한 이체는 수행되거나 전혀 수행되지 않음을 보장
  3. COMMIT, ROLLBACK
• 일관성(Consistency)
  1. 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성있는 데이터베이스 상태로 유지
  2. 트랜잭션 수행이 보존해야 할 일관성은 기본 키, 외래 키 제약과 같은 명시적인 무결성 제약 조건들뿐만이 아님
  3. 자금 이체에서 두 계좌 잔고의 합은 이체 전후가 같아야 함
• 고립성(Isolation)
  1. LOCK - 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장
  2. 여러 트랜잭션이 동시에 수행되더라도 각각의 트랜잭션은 다른 트랜잭션의 수행에 영향을 받지 않고 독립적으로 수행되어야 함
  3. 일관성과 고립성은 같은 맥락으로 볼 수 있음
• 지속성(Durability)
  1. 성공적으로 수행(Commit)된 트랜잭션은 영원히 반영되어야 함
  2. 지속성 저장 장치의 로그(Redo)로 기록 시스템에 이상이 발생하면 로그를 사용하여 이상 발생 이전 상태로 복구하는 것으로 지속성을 실현

Transaction 관리

• Commit
  • Transaction의 성공적인 종료 시점
  • Commit이 되면 DB에 변경사항을 저장
• Rollback
  • 가장 최근의 Checkpoint 지점으로 되돌아감(undone)
  • 이전 값을 보관하고 있음 - undo data
  • 이미 Commit된 데이터는 Rollback 할 수 없음
• Transaction이 성공적인 종료인지 system failure에 의해 비정상적으로 중단되는 경우인지를 구분하기 위해 redo, undo라는 복구 기법 사용
• 특정 시간을 checkpoint 시점으로 잡으면 그 시간에 진행중인 transaction들을 log에 쓰는 방식
• system failure가 발생하면 가장 최근의 check point 지점으로 이동

UNDO

운영 중에 수정된 페이지(버퍼)들이 버퍼 관리자의 버퍼 교체 알고리즘에 따라서 디스크에 출력될 수 있다.
버퍼 교체는 전적으로 버퍼의 상태에 따라서 결정, 일관성 고나점에서 봤을 때는 임의의 방식으로 수행.
즉 아직 완료되지 않은 트랜잭션이 수정한 페이지들도 디스크에 출력될 수 있으므로, 만약 해당 트랜잭션이 어떤 이유든 정상적으로 종료될 수 없게 되면 트랜잭션이 변경한 페이지들은 원상 복구 되어야 한다.
이러한 복구를 UNDO라고 한다.

• STEAL
  • 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책
• ¬STEAL
  • 수정된 페이지들을 최소한 트랜잭션 종료 시점(EOT, End of Transaction)까지는 버퍼에 유지하는 정책

REDO

WAL(Write Ahead Log) - Redo data를 1순위로 기록한다. 장애에 대비해서 Redo 로그를 계속해서 보관한다.

커밋한 트랜잭션의 수정은 어떠한 경우에도 유지(durability)되어야 한다.
이를 보장하는 작업이 Redo 작업이다.
이미 커밋한 트랜잭션의 수정(오류 등의 원인으로)을 재반영하는 복구 작업을 Redo 복구라고 한다.
따라서 이미 수행된 커밋은 영원히 보장될 수 있다.

• FORCE
  • 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하는 정책
• ¬FORCE
  • 수정했던 페이지를 트랜잭션 커밋 시점에 디스크에 반영하지 않는 정책