Introduction
#Database/Concepts
(10/10) 굉장히 공들여서 작성한 글이여서 원래 동아리 스터디 용도로 일부 공개 했었는데, 더 많은 분들이 봤으면 하는 마음에 오픈!
들어가기 앞서
이 과목을 배우기 앞서서 Database가 왜 필요한 지부터 생각해보자.
여러분이 수강신청 시스템을 만들어야 하는 개발자가 되었다고 생각해보자. 기존에 배웠던 프로그래밍 문법(Java, C)와 GUI를 이용해서 수강신청 시스템을 만들기로 했다. 어떻게 해서 수강 과목, 회원, 클래스를 만들고 프로그래밍을 완료해서 컴파일후 프로그램을 실행시킨다. 하지만 이 프로그래밍이 종료되면 메모리 상의 데이터는 모두 사라지게 된다.
따라서 여러분들은 프로그래밍입문 시간에 배운 파일 입출력을 이용해서 2차 저장소(HDD or SSD)에 데이터를 저장해두게 된다. 여러분의 컴퓨터에 있는 SSD 또는 HDD에 파일을 저장해두고, 프로그램을 띄워놓아서 사용자 요청을 받는다면 여러분의 컴퓨터는 사용자 요청 처리 이외에 아무것도 하지 못할 것이다. 따라서 사용자의 요청을 처리하고 데이터를 처리할 컴퓨터가 따로 필요하다는 것을 알게되었다. 여기서 사용자 요청을 받아 처리를 담당하는게 서버이고, 데이터를 보관하는 컴퓨터가 데이터 저장소이다. (과거 전통적인 서버와 데이터 저장소의 개념임!)
서버에는 여러분이 작성한 프로그램을 띄워놓게 될 것이다. 이 프로그램은 사용자 요청을 받아 데이터 저장소에 저장되어 있는 데이터를 수정/삭제 하거나 새로운 데이터를 생성해 저장할 것이다.
하지만 여러분이 작성한 프로그램에는 문제점이 많다. 새로운 기능을 개발할 때 마다 데이터 저장소에 접근하는 코드를 새로 짜야하고, 따라서 중복되는 코드 또한 증가할 것이다. 또한 서버에서 오류가 발생했을 때 데이터 저장소에 있는 데이터의 무결성이 깨지는 문제 또한 발생할 수 있다. 이러한 문제점을 해결하기 위해 등장한게 DBMS(Database Management System)이다. DBMS는 여러분의 프로그램(Application)과 Database 사이에 인터페이스의 역할을 하기 위해 등장했다. DBMS 덕에 효율적으로 데이터의 무결성을 보장할 수 있게 되었고 프로그램 작성도 편리해졌다.
데이터베이스를 공부하면서 위에서 개요로서 다룬 흐름을 꼭 기억하길 바란다.
이 책(강의)에서는 Database Concept을 배우지만, Database에 대한 Detail한 부분(ex. 물리적으로 데이터가 어떻게 저장되는지)은 뒤쪽에서 마이너하게 다루게 되고, DBMS를 통해 Database에 접근하는 것을 중점으로 배우게 될 것이다.
첫 번째 챕터에서는 왜 DBMS를 사용하고 DBMS가 어떤 역할을 하는지에 대해 배우게 될 것이다.
DBMS란?
- 데이터베이스와 최종 사용자 또는 응용 프로그램 간의 인터페이스 역할을 하기 때문에, 사용자는 이 DBMS를 통해서 데이터 CRUD(Create, Read, Update, Delete) 등을 하면서 데이터베이스를 관리하고, 생성할 수 있다.
DBMS는 관리하는 것
Data, DB Engine, Schema를 관리하는데, 얘내가 뭔지 대해서 아래에서 다룰거에요.
- Data
- The database engine
- It allows data to be accessed, locked, and modified
- Schema
- It defines the database’s logical structure.
DBMS가 제공하는 기능
이런 기능을 제공하는 구나 ~ 하고 넘어가면 됩니다. 필요한 부분은 나중에 따로 자세히 다룰거에요.
- performance monitoring/tuning 및 backup과 recovery
- automated rollbacks, restarts and recovery뿐만 아니라 activity를 logging 하는 것 또한 담당
DBMS가 왜 등장했냐? - 초기 DB 응용 프로그램
- 초기에 데이터베이스 응용 프로그램을 파일 시스템 위에 직접 구축해서 데이터를 관리했는데, 다음과 같은 문제들이 발생했다.
- Data redundancy and inconsistency(데이터 중복성과 불일치)
- ex) 동일한 고객 정보가 여러 파일에 저장됨
- Difficulty in accessing data(데이터 접근의 어려움)
- 새로운 작업을 수행하기 위해 새로운 프로그램을 작성해야 했다.
- ex) 고객의 총 구매 금액을 계산하는 작업이 필요하다면, 이를 수행하기 위한 별도의 프로그램을 작성해야 한다
- Data isolation(데이터 고립)
- 다른 형식과 파일에 분산되어 있어 데이터를 결합하여 사용하기가 어렵다.
- Integrity problems(무결성 문제)
- 제약 조건의 코드 내 묻힘: 예를 들어, 계좌 잔액이 0보다 커야 한다는 제약 조건은 과거 파일 시스템에서는 특정 코드 블록 내에 구현되었는데, 이는 제약 조건의 가시성을 낮추고, 이를 추가하거나 변경하기 어렵게 만들었다.
- Atomicity of updates(업데이트의 원자성)
- 원자성: 작업이 모두 수행되거나 전혀 수행되지 않아야 함을 의미
- ex) 한 계좌에서 다른 계좌로 이체하는 경우, 돈이 한쪽 계좌에서 빠져나간 상태에서 시스템 오류가 발생하면, 다른 계좌에는 돈이 입금되지 않는 불일치 상태가 발생함. 모두 성공적으로 완료되거나, 실패하여 아무 일도 일어나지 않아야 하는데, 파일 시스템에서는 이를 보장하기 어려움
- Concurrent access by multiple users(다수 사용자의 동시 접근)
- OS를 공부해보면 알겠지만 파일 시스템에서는 세마포어 등으로 동시 쓰기를 막아두고, Iterative 하게 구현을 했는데, 이 경우 Waiting이 발생하기 때문에 Performance가 떨어짐
- Security problems(보안 문제)
- ex) 직원 A는 고객 정보에 접근할 수 있지만, 직원 B는 접근하지 못하도록 제한하는 것이 파일 시스템상으로는 쉽지 않았다.
과거 파일 시스템 기반 프로그램 DBMS
당연히 위 문제들이 발생하지 않도록 만든게 DBMS다. 이를 위해서는 데이터를 연관지어 구조적으로 조직화해야 한다. 여기서 “View of Data” 라는 개념이 등장하다. 데이터베이스 시스템에서 사용자가 데이터를 어떻게 바라보고 다룰 수 있는지에 대한 개념으로 이해하면 된다. 데이터베이스는 추상화(Data abstraction)를 통해서 복잡성을 숨기고, 사용자가 쉽게 데이터에 접근할 수 있도록 해준다. 이러한 데이터 추상화와 같은 과정에서 데이터를 구조화하고 의미를 부여하며, 무결성을 유지하기 위해 사용하는 모델을 Data Model이라고 이해하면 된다.
Data abstraction
데이터베이스 시스템은 데이터를 여러 단계로 추상화하여 사용자에게 제공하는데, 이렇게 하면 데이터의 복잡성을 숨기고, 사용자가 더 직관적이고 간단하게 데이터를 다룰 수 있게 된다. 데이터 추상화는 크게 두 가지 level로 나눌 수 있다.
- Physical level : 데이터가 실제로 어떻게 저장되고 있는지
- Logical level : 데이터베이스가 어떻게 구성되고 구조화되어 있는지(ex. table, relation, 제약조건)
- ex) 아래 같은 테이블도 Logical Level에 해당함. 테이블을 통해서 특정 property에 올 수 있는 값의 범위 —> 제약 조건을 확인할 수 있다.
type instructor = record
ID : string;
name : string;
dept_name : string;
salary : integer;
end;
- View level : 필요한 데이터만 보고 접근할 수 있게 한다.
아래 그림처럼 사용자는 View level을 통해서 필요한 데이터를 보고, Logical level에서 데이터를 다루게 된다. 사용자는 Physical level을 신경쓸 필요는 없다.
Data Models (데이터 모델)
위에서 언급했듯이 데이터 추상화와 같은 과정에서 데이터를 구조화 하고 의미를 부여하며, 무결성을 유지하기 위해 사용하는 모델이다.
Data Model은 여러가지가 있는데 대표적으로 다음과 같은 Model이 있다 정도만 알고 넘어가자. 본인이 나중에 필요한 모델을 선택해서 개발을 할 것이기 때문임. 물론 이 교재에서는 Relational Model이랑 E-R Model을 주로 다루더라고요
- 관계형 모델 (Relational Model): 데이터를 표(테이블) 형식으로 모델링합니다. 각 테이블은 행과 열로 구성되어 있으며, 이 관계(테이블)들을 통해 데이터가 구조화됩니다.
(위에 있는 빨간색 필기는 신경쓰지 않아도 됩니다.)
- 엔터티-관계 데이터 모델 (Entity-Relationship Model): 주로 데이터베이스 설계를 위해 사용되는 고수준의 데이터 모델입니다. 시스템의 주요 엔터티(실체)와 이들 간의 관계를 정의하여 데이터베이스의 개념적 설계를 개발합니다.
- 객체 기반 데이터 모델 (Object-Based Data Model): 객체 지향 프로그래밍의 개념을 데이터베이스에 적용한 모델입니다. 객체와 클래스, 상속 등의 개념을 사용하여 데이터를 다룹니다.
- 반구조화된 데이터 모델 (Semi-Structured Data Model): XML과 같은 형식을 사용하여 데이터를 표현합니다. 구조화된 데이터와 비정형 데이터를 함께 다룰 수 있습니다.
- 기타 오래된 모델: 네트워크 모델과 계층형 모델이 있습니다. 이들은 데이터베이스 시스템의 초기 모델로, 관계형 모델이 등장하기 전에 많이 사용되었습니다.
여기 아래서부터 나오는 언어 관련 내용은 실무 측면?에서 중요한 내용이라고 생각합니다.
요즘은 코테에서 SQL 문제를 낼 정도로 데이터베이스 테이블을 생성하고, 데이터를 조작하는 것에 대한 역량을 많이 요구하는데, 그런 측면에서 앞으로 나오는 내용들은 평생 알아야 할 내용이니 더 주의깊게 볼 필요가 있어요!
Instances and Schemas
데이터베이스를 배우다보면 Schema와 Instance라는 용어가 등장을 한다.
Schema에는 Logical Schema와 Physical Schema 가 있는데, 보통 Logical Schema를 말한다.
- 논리적 스키마(Logical schema)
- 데이터베이스의 전체 논리적 구조(Overall logical structure of the database)
- 프로그래밍 언어에서 변수 type information과 유사하다
- 물리적 스키마(Physical schema): 데이터베이스의 전체 물리적 구조
- 인스턴스(Instance): 특정 시점에서 데이터베이스의 실제 content
- 변수의 value와 유사하다
객체 지향 언어로 따지면 스키마는 클래스(구조체)에 대응되고, 인스턴스는 말 그대로 인스턴스이다.
DBMS에서 사용하는 Language 종류
프로그래밍에서 메모리 상의 변수를 다루기 위해 프로그래밍 언어가 존재하는 것처럼 DBMS에서도 데이터를 다루기 위해서 언어가 존재합니다.
- DDL(Data Definition Language): ALTER, CREATE, DROP, RENAME, TRUNCATE
- Definition. 데이터를 정의하는 언어. 테이블을 다룬다고 기억하자.
- 객체지향 언어로 비유하자면, 인스턴스를 찍어낼 때 컴파일러에게 전달해야하는 클래스 정보를 정의하여 인스턴스를 생성하고, 또 인스턴스를 삭제하기도 하고… 요런 역할을 한다.
- 테이블을 생성하고, 삭제하고, TRUNCATE(테이블내 데이터를 모두 삭제하지만, 테이블은 빈 값으로 존재) 한다.
- Definition. 데이터를 정의하는 언어. 테이블을 다룬다고 기억하자.
- DML(Data Manipulation Language): DELETE, INSERT, UPDATE, SELECT
- 특정 데이터를 삭제하고, 삽입하고.... 조작하는 용도
- 특정 테이블 안에 존재하는 특정 데이터를 삭제, 삽입…
- 가장 많이 사용하는 Language
- 특정 데이터를 삭제하고, 삽입하고.... 조작하는 용도
- DCL(Data Control Language): GRANT(권한을 부여), REVOKE(권한을 뺐는다)
- 접근 권한을 주거나 뺏을 때 사용
- TCL(Transaction Control Language): COMMIT, ROLLBACK, SAVEPOINT
- rarely used
- 데이터 Manipulation을 하면서 데이터베이스의 상태를 변화시키는 단위
- github를 사용해본 분들이라면 커밋이라는 단어를 보면 어떤 언어인지 바로 감이 올 거에요
실제로 DB를 가지고 간단하게 프로그래밍한다면, 논리적 스키마를 DDL로 표현하여 테이블을 만들고, 이 테이블에 데이터를 삭제, 추가하는 작업을 DML을 통해서 수행하게 됩니다!
DDL(데이터 정의 언어(Data Definition Language (DDL))
- 데이터베이스 스키마 정의하기 위해서 사용하는 언어
- ex)
create table instructor (
ID char(5)
name varchar(20),
dept_name varchar(20),
salary numeric(8,2))
작동 과정 | DDL 컴파일러는 DDL을 먼저 해석하고 문제가 없는지(ex. 제약 조건 검증) 체크를 한다.(프로그래밍에서 컴파일러가 컴파일 오류가 있는지 체크하는 것과 유사) 그리고 이 정보를 바탕으로 실제 데이터베이스에 테이블을 생성하고 Data Dictionary를 갱신한다. (Data Dictionary는 메타데이터, 스키마 정보, 무결성 제약 조건 등을 저장하고 관리하는 데이터베이스라고 생각하면 된다)
Data Manipulation Language (DML)
위에서 언급한 것 처럼 데이터 모델에 의해 구성된 데이터를 삭제하고, 삽입하고.... 조작하기 위해 사용하는 언어이다. DML은 쿼리 언어(Query Language)로도 알려져 있다. DML을 포함하고 있는 대표적인 언어가 그 유명한 SQL(Structured Query Language, 구조적 질의 언어)이다.
Structured Query Language (SQL)
데이터베이스에 접근하고 조작하기 위한 표준 언어
SQL이 할 수 있는 일은 다음과 같은데, 어차피 나중에 자세히 다룰 거니까 이런걸 할 수 있다 정도로 알고 넘어가자.
- SQL은 데이터베이스에 대한 쿼리를 실행할 수 있습니다.
- SQL은 데이터베이스에서 데이터를 retrieve(검색) 할 수 있습니다.
- SQL은 데이터베이스에서 record를 insert/update/delete 할 수 있습니다.
- SQL은 새로운 데이터베이스를 생성할 수 있습니다.
- SQL은 데이터베이스에 새로운 table을 생성할 수 있습니다.
- SQL은 데이터베이스에서 view를 생성할 수 있습니다.
참고: 어떤 책에서는 DML을 DQL과 DML로 분리하여 다루기도 한다. Select를 Query로 분류하고, INSERT, UPDATE, DELETE를 Manipulation으로 보는 것. 또한 SQL은 DML 뿐만 아니라 DDL, DCL, TCL을 모두 포함하고 있다.
Database Engine
아까 맨 위에서 DBMS가 다루는 3 가지 중 하나인 DataBase Engine 이다. 위에서 다룬 DDL, DML을 DBMS에 날렸을 때 DBMS에서 Database Engine이 처리해준다고 보면 된다.
DBMS는 전체 시스템을 책임을 기준으로 모듈화하고 있다.
- 스토리지 관리자(Storage Manager)
- 쿼리 프로세서 구성 요소(Query Processor Component)
- 트랜잭션 관리 구성 요소(Transaction Management Component)
Storage Manager
- 데이터베이스에 저장된 low-level 데이터와 데이터베이스에 제출된 응용 프로그램 프로그램 및 쿼리 사이의 인터페이스를 제공하는 프로그램 모듈입니다.
- 말이 어려운데, 그냥 쿼리를 날리면 이를 저장소에서 처리해주는 프로그램 모듈이라고 생각해면 된다.
- Storage Manager는 다음 작업을 담당한다:
- OS 파일 관리자와의 상호작용
- 데이터의 효율적인 저장, 검색 및 갱신
- Storage Manager는 또 4가지로 분류할 수 있다:
- 권한 및 무결성 관리자(Authorization and Integrity Manager)
- 트랜잭션 관리자(Transaction Manager)
- 파일 관리자(File Manager)
- 버퍼 관리자(Buffer Manager)
- Storage Manager는 물리적 시스템 구현의 일부로 여러 데이터 구조를 구현합니다:
- 데이터 파일(Data Files)
- 데이터베이스 자체를 저장합니다.
- 데이터 사전(Data Dictionary)
- 데이터베이스의 구조에 대한 메타데이터를 저장하며, 특히 데이터베이스의 스키마를 저장합니다.
- 인덱스(Indices)
- 데이터 항목에 빠르게 접근할 수 있습니다.
- 데이터베이스 인덱스는 특정 값을 보유한 데이터 항목에 대한 포인터를 제공합니다.
- 데이터 파일(Data Files)
Query Processor
쿼리 프로세서가 DDL을 해석하고 컴파일하고, 명령어를 실행한다고 보면 된다. 아까 위에서 본 DDL을 실행하면 Query Processor가 처리해준다고 기억하자.
- 쿼리 프로세서에는 다음이 포함되어 있다.
- DDL interpreter
- 데이터 정의 언어(DDL)는 데이터베이스의 다른 구조를 정의하는 명령어에 대한 표준입니다. DDL 명령어는 테이블, 인덱스, 사용자와 같은 데이터베이스 객체를 생성, 수정 및 제거합니다. 일반적인 DDL 명령어에는 CREATE, ALTER, DROP이 있습니다.
- DDL interpreter는 DDL 명령어를 해석하고 data dictionary에 definition을 기록합니다.
- DML compiler
- 이는 DML 명령어를 query evaluation engine이 이해하는 low-level 명령어로 구성된 evaluation plan으로 변환합니다.
- Query Evaluation Engine
- 이는 DML 컴파일러가 생성한 low-level 명령어를 실행합니다.
- 구문 분석 및 번역(Parsing and Translation)
- 최적화(Optimization)
- 평가(Evaluation)
- DDL interpreter
⠀
Transaction Management
Transaction Management라는 게 Transaction 단위로 작업을 처리해주는 모듈이라고 보면 되는데, 트랜잭션에 대해서도 나중에 자세히 배우긴 한다. 그래도 여기서 알고 넘어가자.
- 트랜잭션(Transaction)은 데이터베이스 애플리케이션에서 단일 logical function을 수행하는 작업들의 집합입니다.
- 트랜잭션 관리 컴포넌트(Transaction-Management Component)
- 이는 시스템 오류(예: 전원 장애 및 운영 체제 충돌) 및 트랜잭션 오류에도 불구하고 데이터베이스가 일관된(올바른) 상태를 유지하도록 보장합니다.
- 동시성 제어 관리자(Concurrency-Control Manager)
- 이는 concurrent transaction 간의 상호작용을 제어하여 데이터베이스의 일관성을 보장합니다.
- 트랜잭션 관리 컴포넌트(Transaction-Management Component)
트랜잭션이 뭔지 감이 안온다면 아래 예시를 참고해보자,
트랜잭션의 실제 예: 은행 계좌 이체
상황:
사용자 A가 자신의 계좌에서 100달러를 인출하여 사용자 B의 계좌로 이체하고자 합니다. 이 경우, 트랜잭션은 다음과 같은 작업들로 구성될 수 있습니다:
1 사용자 A의 계좌에서 100달러 인출
* A의 계좌에서 현재 잔액에서 100달러를 차감합니다.
* 예: A의 잔액이 1000달러였다면, 900달러로 업데이트됩니다.
2 사용자 B의 계좌에 100달러 입금
* B의 계좌에 현재 잔액에 100달러를 더합니다.
* 예: B의 잔액이 500달러였다면, 600달러로 업데이트됩니다.
⠀이 두 작업이 하나의 트랜잭션으로 묶여야 하며, 이 트랜잭션이 전부 성공적으로 완료되거나, 전부 수행되지 않도록 해야 합니다.
트랜잭션은 원자적(atomic)이어야 하며, 즉, 트랜잭션이 완전히 완료되거나 전혀 수행되지 않은 것처럼 처리되어야 한다. 즉, 트랜잭션의 핵심은 데이터베이스의 일관성을 유지하는 것임!
트랜잭션의 상태 변화:
1 Active 상태:
* 트랜잭션이 시작되고 작업이 진행 중입니다.
* 예를 들어, A의 계좌에서 100달러를 차감하는 작업이 수행 중입니다.
2 Partially Committed 상태:
* 모든 작업이 완료되었지만, 시스템에 영구적으로 반영되기 전의 상태입니다.
* 예를 들어, A의 계좌에서 100달러가 성공적으로 차감되었고, B의 계좌에 100달러가 더해지기 전 상태입니다.
3 Failed 상태:
* 작업 중 문제가 발생한 상태입니다. 예를 들어, A의 계좌에서 돈이 차감된 후 B의 계좌에 돈을 더하려는 도중 시스템 오류가 발생했습니다.
4 Aborted 상태:
* 트랜잭션이 실패했고, 이전 상태로 롤백(rollback)되었습니다.
* 예를 들어, A의 계좌에서 100달러를 차감했지만 B의 계좌에 더하는 과정에서 실패했다면, A의 계좌에서 차감된 100달러를 다시 복원합니다. 이제 A와 B의 계좌 잔액은 트랜잭션 전과 동일한 상태로 돌아갑니다.
5 Committed 상태:
* 모든 작업이 성공적으로 완료되어 데이터베이스에 영구적으로 반영된 상태입니다.
* A의 계좌에서 100달러가 차감되고, B의 계좌에 100달러가 더해진 것이 모두 성공적으로 완료되었고, 이 결과가 데이터베이스에 확정적으로 반영되었습니다.
⠀
- 데이터베이스의 트랜잭션은 다음 상태 중 하나일 수 있습니다:
- Active - 이 상태에서 트랜잭션이 실행 중입니다. 이는 모든 트랜잭션의 초기 상태입니다.
- Partially Committed - 트랜잭션이 최종 operation을 실행할 때 Partially Committed 상태에 있습니다.
- Failed - 데이터베이스 복구 시스템이 실패를 감지한 경우 트랜잭션이 Failed 상태에 있다고 합니다. 실패한 트랜잭션은 더 이상 진행할 수 없습니다.
- Aborted - 트랜잭션이 중단된 상태입니다. 어떤 검사가 실패하고 트랜잭션이 실패 상태에 도달하면 recovery manager가 데이터베이스의 모든 쓰기 작업을 롤백하여 트랜잭션 실행 전의 원래 상태로 되돌립니다. 이 상태의 트랜잭션을 중단되었다고 합니다. 트랜잭션 중단 후 데이터베이스 recovery module 은 다음 두 가지 작업 중 하나를 선택할 수 있습니다:
- 트랜잭션 재시작
- 트랜잭션 종료
- Comitted - 트랜잭션이 모든 operation을 성공적으로 실행하면 커밋되었다고 합니다. 모든 실행 결과는 이제 데이터베이스 시스템에 영구적으로 설정됩니다.
트랜잭션에 대해서는 DB 강의 (아마 챕터 9?) 마지막 부분에서 자세히 다룰겁니다
DBMS Total - Architecture
여기까지 DBMS가 다루는 Data, Data Engine, Schema를 모두 살펴봤다.
이러한 3가지 구성 요소가 어떻게 조직화 되어있는지 DBMS 아키텍쳐를 살펴보자
Ex) MySql 아키텍쳐
Database Architecture
데이터베이스 시스템 아키텍쳐를 다음과 같이 분류할 수 있다~
- 중앙 집중식 데이터베이스 (Centralized Databases) - One to a few core, shared memory
- 클라이언트-서버 (Client-Server) - 한 서버 머신이 여러 클라이언트 머신을 대신하여 작업을 수행합니다.
- 병렬 데이터베이스 (Parallel Databases) - Many core shared memory
- 분산 데이터베이스 (Distributed Databases) - Geographical distribution, Schema/data heterogeneity
- ex) 재난이 발생했을 때를 대비해서 분산 데이터베이스를 사용한다.
Database Applications
- 데이터베이스 애플리케이션은 보통 두 개 또는 세 개의 파트로 나뉩니다:
- Two-Tier Architecture - 애플리케이션이 클라이언트 머신에 있으며 서버 머신에서 데이터베이스 시스템 function을 invoke(호출)합니다.
- 실무에서 특수한 경우를 제외하고 이런 아키텍쳐를 사용하는 경우는 정말 드물겠죠??
- Three-Tier Architecture - 클라이언트 머신은 front-end 역할을 하며 직접적인 데이터베이스 call(호출)을 포함하지 않습니다:
- Client end는 보통 foam interface를 통해 애플리케이션 서버와 통신합니다.
- 게임으로 따지면 게이머는 게임 클라이언트(foam interface에 해당)를 통해서 게임 서버와 통신한다.
- 애플리케이션 서버는 데이터베이스 시스템과 통신하여 데이터를 액세스합니다.
- 게임 서버는 DBMS와 상호작용을 한다.
- Client end는 보통 foam interface를 통해 애플리케이션 서버와 통신합니다.
- Two-Tier Architecture - 애플리케이션이 클라이언트 머신에 있으며 서버 머신에서 데이터베이스 시스템 function을 invoke(호출)합니다.
Database Users
DBMS 사용자를 분류한다면 다음과 같이 분류할 수 있다~
Naïve에서 Specialized로 갈 수록 더 백엔드쪽에 가까워져서 데이터베이스와 상호작용을 더 깊게 한다고 보면 된다.
- 데이터베이스 시스템 사용자는 네 가지 유형이 있습니다:
- Naïve(순수한) Users - 미리 작성된 애플리케이션 프로그램 중 하나를 호출하여 시스템과 상호 작용하는 단순한 사용자
- Application Programmers - 애플리케이션 프로그램을 작성하는 컴퓨터 전문가
- Sophisticated(정교한) Users - 프로그램을 작성하지 않고 시스템과 상호 작용하는 사용자:
- 데이터베이스 쿼리 언어를 사용
- 데이터 분석 소프트웨어와 같은 도구 사용
- Specialized Users - 그래픽 데이터, 오디오, 비디오 등 기존 데이터 처리 프레임워크에 맞지 않는 전문화된 데이터베이스 애플리케이션 작성
⠀Database Administrator
- 시스템에 대한 중앙 제어 권한을 가진 사람을 데이터베이스 관리자(DBA)라고 하며, 그 기능은 다음과 같습니다:
- 스키마 정의
- 저장 구조 및 액세스 방법 정의
- 스키마 및 physical-organization 수정
- 정기 유지보수
- 정기적으로 데이터베이스 백업
- 정상 운영을 위해 충분한 여유 디스크 공간을 보장하고 필요한 경우 디스크 공간 업그레이드
- 데이터베이스에서 실행 중인 작업을 모니터링하고 일부 사용자가 제출한 매우 비용이 많이 드는 작업으로 인해 성능이 저하되지 않도록 보장
정리
이번 챕터에서는 기존 과거 파일 시스템 위에 구축된 데이터베이스의 문제점을 개선하기 위해 등장한 DBMS를 중점으로 다루었다.
DBMS는 Application, User와 데이터베이스 사이에 인터페이스 역할을 하고 다음을 관리한다.
1. Data + 2. Schema
과거 시스템의 문제점을 개선하고 효율적으로 데이터를 관리하기 위해 Abstraction(추상화)를 한다. 이를 통해서 사용자가 필요한 데이터만 다룰 수 있게 되었다. 그리고 추상화를 하는데 필요한 모델을 Data Model이라고 한다. 대표적인 데이터 모델 중 하나인 RDB는 데이터를 표로 모델링한다. 데이터를 표현(저장)하는데 사용하는 구조를 Schema라고 한다. Schema는 크게 Logicla Schema와 Physical Schema로 나눌 수 있다.
사용자가 DBMS를 통해 데이터베이스에 접근하는데 사용하는 언어에는 크게 4가지가 존재했다.
- DDL : 스키마 정의
- DML : 데이터 manipulation
- DCL : 접근권한
- TCL : 트랜잭션
데이터베이스에 접근에 사용하는 표준적인 언어로 SQL을 예로 들었다.
3. Database Engine
사용자가 DDL, DML 등을 DBMS에 날리면 데이터베이스 엔진이 처리해준다.
데이터베이스 엔진은 처리하는 일을 기준으로 다음과 같이 나눈다.
- 스토리지 관리자(Storage Manager)
- 쿼리 프로세서 구성 요소(Query Processor Component)
- 트랜잭션 관리 구성 요소(Transaction Management Component)
이후에는 DBMS 아키텍쳐를 통해서 데이터, 스키마, DB 엔진이 어떻게 구조화 되어있는지 살펴보았다. 병렬, 분산 DB와 같은 아키텍쳐와, Two-tier, Three-tier 구조 또한 살펴보았다.
챕터 마지막에는 데이터베이스 사용자를 분류하고 데이터베이스 관리자(DBA)가 어떤 역할을 하는지 살펴봤다.
끝!
Ref) Database System Concepts - 7th edition (Abraham Silberschatz)
작성자 Blog) Brute force Study
'DataBase > Concepts' 카테고리의 다른 글
[DataBase] 03. SQL(Structured Query Language)(4) (0) | 2024.10.11 |
---|---|
[DataBase] 03. SQL(Structured Query Language)(3) (0) | 2024.10.11 |
[DataBase] 03. SQL(Structured Query Language)(2) (0) | 2024.10.11 |
[DataBase] 03. SQL(Structured Query Language)(1) (0) | 2024.10.10 |
[DataBase] 02. Relational Model(관계형 모델) (0) | 2024.10.10 |