From 30896622dd2eb5d5275c45b86733683d401d5cbd Mon Sep 17 00:00:00 2001
From: youngcircle-kim <dudghks021121@gmail.com>
Date: Tue, 13 Feb 2024 22:17:25 +0900
Subject: [PATCH] =?UTF-8?q?1.Introduction=20=EC=A0=95=EB=A6=AC?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ch.1/1.Introduction.md | 411 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 ch.1/1.Introduction.md

diff --git a/ch.1/1.Introduction.md b/ch.1/1.Introduction.md
new file mode 100644
index 0000000..6582573
--- /dev/null
+++ b/ch.1/1.Introduction.md
@@ -0,0 +1,411 @@
+# 1. Introduction
+
+- DBMS(Database Management System)
+    - 상호 관련된 데이터의 집합과 해당 데이터에 액세스하는 프로그램 세트
+    - 상호 관련된 데이터의 집합은 우리가 흔히 부르는 Database.
+    - 즉, DBMS를 간단히 표현하면, Database에 접근하고 조작하는 프로그램이다.
+    
+
+DBMS의 주요 목적은 데이터베이스의 정보를 저장하고 이를 검색하기 위한 편리하고도 효율적인 환경을 제공하는 데 있다.
+
+또한 시스템 고장이나 모든 불법적인 접근 등으로부터 안전하게 보호해야 하며, 데이터가 여러 사용자 간에 공유될 경우 생길 수 있는 예기치 않은 이상 결과를 방지해야 한다.
+
+## 1.1 데이터 베이스 시스템의 응용
+
+데이터베이스 시스템은 양적으로 매우 크고, 크고 복잡하고 데이터 집합을 관리하는 대규모의 소프트웨어 시스템이다.
+
+복잡성 관리에서 중요한 것은 추상화(abstraction) 개념이다.
+
+데이터 베이스 시스템은 대규모의 복잡한 데이터에 대해서 단순하고 추상화된 관점을 제공하기에, 사용자와 응용 프로그래머들은 데이터가 실제로 어떻게 저장되고 조직화되었는지에 대한 자세한 사항을 알 필요가 없다.
+
+## 1.2 데이터베이스 시스템의 목적
+
+### 파일 처리 시스템의 단점
+
+DBMS가 등장하기 전까진 일반적으로 운영체제에서 제공해주는 파일 처리 시스템을 사용하여 데이터를 관리했다.
+
+1. 데이터의 중복과 비일관성
+    - 파일과 응용 프로그램은 장시간에 걸쳐 서로 다른 많은 프로그래머에 의해 개발됨. 
+    그래서 파일이 서로 다른 형식을 갖기 쉽고, 응용 프로그램이 서로 다른 언어로 작성될 수 있음.
+    - 동일한 정보가 여러 파일에 중복 저장될 것이다.
+    - 데이터의 비일관성을 초래함.
+        - 동일한 데이터의 여러 사본이 서로 다른 값을 보유하고 있는 상태.
+2. 데이터 접근의 어려움
+    - 필요한 데이터를 편리하고 효율적으로 검색하기 어렵다.
+3. 데이터 고립
+    - 데이터가 여러 파일에 흩어져 있고, 파일 형식이 서로 달라 원하는 데이터를 검색하는 프로그램을 새로 작성하기 어렵다.
+4. 무결성(Integrity) 문제
+    - 데이터베이스 내에 저장된 데이터 값은 어떤 형식의 일관성 제약 조건을 만족해야 한다.
+    - 새로운 제약 조건이 추가되었을 때, 기존 프로그램을 일일이 변경하여 해당 제약 조건을 새로이 만족한다는 것은 쉬운 일이 아님.
+5. 원자성 문제
+    - 시스템이 예상치 못한 이유로 잘못되었을 때, 데이터를 잘못되기 이전 사애로 유지시키는 일은 매우 중요
+    - 데이터베이스의 일관성을 지키기 위해서 데이터베이스에 대한 어떠한 행위가 원자적이어야 함.
+    - 일련의 과정 전체가 수행되든지 아니면 어느 것도 수행되지 않아야 한다.
+6. 동시 접근의 문제
+    - 시스템의 전반적인 성능을 향상하고 응답 시간을 단축하기 위해, **많은 시스템은 여러 사용자가 데이터를 동시에 갱신할 수 있도록 한다.**
+7. 보안 문제
+    - 파일 처리 시스템에서는 응용 프로그램이 그때그때 바로 추가되므로 보안에 관한 제약 조건을 지키기 어렵다.
+
+## 1.3 데이터의 관점
+
+데이터베이스 시스템은 서로 관련이 있는 파일의 모임이자 사용자로 하여금 이 파일에 접근하거나 이를 수정하도록 하는 프로그램의 집합.
+
+데이터베이스 시스템의 주요 목적은 사용자에게 데이터에 관한 추상적인 관점을 제공하는 것임.
+
+즉, 시스템은 데이터가 어떻게 저장되고 유지되는지에 관한 세부 사항은 사용자로부터 은폐한다.
+
+### 1.3.1 데이터 모델
+
+데이터 모델은 데이터, 데이터들 사이의 관계, 데이터의 의미 그리고 일관성 제약 조건 등을 기술하기 위한 개념적 표현의 집합이다.
+
+데이터 모델은 크게 4개로 분류한다.
+
+1. 관계형 모델
+    - 데이터와 이들 데이터 사이의 관계를 나타내기 위해 테이블의 모임을 사용한다.
+    - 각 테이블은 고유한 이름을 가진 여러 개의 열로 구성된다.
+    - 레코드 기반 모델의 한 예다.
+        - 데이터베이스가 몇 개의 타입(type)으로 이루어진 고정 형식의 `레코드(record 또는 행(row), 튜플(tuple))`로 구성되기 때문이다.
+        - 각 테이블은 특정한 타입의 레코드를 포함한다.
+        - 각 레코드 타입은 정해진 수의 필드(또는 속성)를 정의한다.
+    - **테이블의 각 열은 레코드 타입의 속성에 대응한다.**
+    - 가장 널리 쓰이는 데이터 모델이며, 대부분의 데이터베이스 응용의 기본이 된다.
+2. 개체-관계 모델
+    - `개체-관계 모델(E-R 모델)`은 기본적인 객체들의 집합인 `개체(entity)`와 이러한 개체들 간의 `관계(relationship)`를 사용한다.
+    - 개체-관계 모델은 데이터베이스를 설계하는 데 널리 쓰인다.
+3. 반구조형 데이터 모델
+    - 같은 형식을 갖고 있으나, **다소 다른 속성을 가진 개별적 데이터 항목을 기술하기 위한** `비정형 데이터 모델`이다.
+        - 앞에서 소개한 모델들이 특정 형식의 데이터 항목에 대해서는 동일한 속성의 집합만 갖도록 허용한다는 점에서 대조를 이룬다.
+    - **JSON**과 확장성 마크업 언어(extensible markup language)인 **XML**이 반구조형 데이터를 표현하는 데 널리 사용된다.
+4. 객체 기반 데이터 모델 
+    - 관계형 테이블에 객체를 저장하는 표준이 있다.
+    - 관계형 모델에 캡슐화, 메서드, 객체 식별화의 개념을 더해 확장한 것처럼 보일 수 있다.
+
+### 1.3.3 데이터 추상화
+
+데이터베이스는 여러 단계의 `데이터 추상화(data abstraction)`을 통해 복잡한 구조를 되도록이면 감추어 사용자의 이해와 편의를 도와야 한다.
+
+1. 물리적 단계
+    - 추상화의 최하위 단계
+    - 데이터가 실제로 **어떻게** 저장되는지 기술한다.
+    - 복잡한 하위 단계의 데이터 구조가 상세히 기술된다.
+2. 논리적 단계
+    - **어떤** 데이터가 저장되었는지, 데이터들 사이에는 어떤 관계가 있는지를 기술한다.
+    - 전체 데이터베이스를 몇 개의 비교적 간단한 데이터 구조를 이용하여 기술한다.
+    - `물리적 데이터 독립성(physical data independence)`
+        - 논리적 단계의 간단한 구조를 구현하기 위해서는 복잡한 물리적 단계의 구조를 알아야 하는 것이 사실이나,
+        - 논리적 단계의 사용자는 이러한 복잡한 구조에 대해 전혀 알 필요가 없다.
+    - 어떤 정보가 데이터베이스에 저장되어야 할지를 결정하는 `데이터베이스 관리자(database administrator, DBA)`가 이 단계에서 작업한다.
+3. 뷰 단계
+    - 추상화의 최상위 단계
+    - 전체 데이터베이스의 일부분만을 기술한다.
+    - 사용자가 시스템을 간단히 이용할 수 있도록 정의한다.
+        - 사용자는 데이터베이스에 저장된 데이터에 대해서 극히 일부분만 관심이 있다.
+    - 한 데이터베이스에 대해서 수많은 뷰가 존재할 수 있다.
+    
+
+## 1.3.4 인스턴스와 스키마
+
+### 인스턴스
+
+어느 특정한 순간에 데이터베이스에 저장되어 있는 정보의 모임을 데이터베이스의 `인스턴스(instance)`라 한다.
+
+### 스키마
+
+데이터베이스의 전체적인 설계를 이야기할 때는 데이터베이스 `스키마(shema)`라 한다.
+
+데이터베이스 시스템에서는 추상화의 단계에 따라 여러 개의 스키마가 존재한다.
+
+- `물리적 스키마(physical schema)` : 물리적 단계에서 데이터베이스 설계를 기술한다.
+- `논리적 스키마(logical schema)` : 논리적 단계에서 데이터베이스 설계를 기술한다.
+- `서브 스키마(subschema)` : 데이터베이스는 여러 가지 서로 다른 뷰를 기술하는 뷰 단계의 스키마를 여러 개 가질 수 있다.
+
+응용 프로그램에 가장 큰 영향을 미치는 것은 논리적 스키마이다.
+
+대부분의 응용 프로그램이 논리적 스키마에 기반하여 작성되기 때문이다.
+
+### 물리적 데이터 독립성(physical data independence)
+
+물리적 스키마는 논리적 스키마 아래에 감추어져 있으나, 대개 상위의 응용 프로그램에 영향을 주지 않고서도 이를 쉽게 변경할 수 있다.
+
+즉, **응용 프로그램이 물리적 스키마에 의존하지 않아서** 물리적 스키마가 변경되어도 고칠 필요가 없다.
+
+# 1.4 데이터베이스 언어
+
+데이터베이스 시스템은 데이터베이스 스키마를 기술하는 `데이터 정의 언어(data definition language, DDL)`와 데이터베이스 질의 및 갱신을 표현하는 `데이터 조작 언어(data manipulation language, DML)`를 제공한다.
+
+## 1.4.1 데이터 정의 언어
+
+`데이터 정의 언어(DDL)`**라는 특수한 언어로 표현된 정의들의 집합**을 이용해 데이터베이스 스키마를 구체화한다.
+
+DDL은 데이터의 추가적인 특성을 표현하는 데에도 사용된다.
+
+데이터베이스에 저장된 데이터는 해당 데이터베이스가 요구하는 일관성 제약 조건을 만족해야 한다.
+
+데이터베이스 시스템은 데이터베이스가 갱신될 때마다 이러한 제약 조건을 검토하는데, 이런 `술어(predicate)`를 검증하는데에는 처리 비용이 많이 든다.
+
+따라서 데이터베이스 시스템은 최소한의 비용으로 검증될 수 있는 `무결성 제약 조건`을 이행한다.
+
+### 도메인 제약 조건(Domain Constraints)
+
+- 모든 속성은 가능한 값의 도메인(e.g., 정수형, 문자형, 날짜/시간형)이 지정되어 있어야 한다.
+- 속성을 선언하는 데 각각의 도메인은 값에 대한 제약 조건으로 작용한다.
+
+### 참조 무결성(Referential Integrity)
+
+- 어떤 속성들의 집합에 대해 **릴레이션의 한 값이 다른 릴레이션의 해당 속성 집합의 값으로 반드시 나타나야 하는** 경우가 있다. (`참조 무결성`)
+    - 예를 들어, 각 수업에 **열거된** 학과가 실제로 존재해야 하는 상황이다.
+- 데이터베이스의 수정이 참조 무결성을 위반할 수 있는데, 이 경우 기본적인 절차는 **위반을 유발한 동작을 거부**하는 것이다.
+
+### 권한(Authorization)
+
+`권한(authorization)`은 데이터베이스의 다양한 데이터에 대해서 사용자마다 접근을 다르게 하고 싶을 때의 차별을 말한다.
+
+아래처럼 여러 유형의 권한들이 존재하는데,
+
+이들은 사용자에게 전부 허가하거나, 혹은 전혀 할당하지 않거나, 조합해서 일부만 할당할 수도 있다.
+
+> ✅ 읽기 권한(read authorization)
+> 
+- 데이터의 읽기를 허용한다.
+- 데이터의 수정(쓰기)를 허용하지 않는다.
+
+> ✅ 삽입 권한(insert authorization)
+> 
+- 새로운 데이터의 삽입을 허용한다.
+- 존재하는 데이터의 수정은 허용하지 않는다.
+
+> ✅ 갱신 권한(update authorization)
+> 
+- 데이터의 수정은 허용한다.
+- 데이터의 삭제는 허용하지 않는다.
+
+> ✅ 삭제 권한(delete authorization)
+> 
+- 데이터의 삭제를 허용한다.
+
+DDL은 명령문(statements)을 입력으로 받아 결과를 생성한다.
+
+DDL의 결과는 `메타데이터(metadata, 데이터에 대한 데이터)`를 수록하는 `데이터 사전(data dictionary)`에 저장된다.
+
+- 데이터 사전은 특별한 형태의 테이블로서 **오직 데이터베이스 시스템에 의해서만 접근되고 갱신될 수 있다.**
+- 데이터베이스 시스템이 실제 데이터를 읽거나 갱신할 때에는 데이터 사전을 참조하여 작업을 수행한다.
+
+## 1.4.2 SQL 데이터 정의 언어
+
+`SQL`은 데이터 타입과 무결성 제약 조건을 갖는 테이블을 정의할 수 있도록 풍부한 DDL을 제공한다.
+
+SQL DDL은 다수의 무결성 제약 조건을 제공한다. (3장, 4장에서 설명)
+
+e.g., department 테이블을 정의하는 SQL DDL 구문
+
+```
+create table department
+(
+    department char(20),
+    building   char(15),
+    budget     numeric(12, 2)
+);
+```
+
+## 1.4.3 데이터 조작 언어
+
+`데이터 조작 언어(DML)`는 사용자가 적절한 데이터 모델로 구성된 데이터에 접근하거나 이것을 조작할 수 있도록 하는 언어다.
+
+### 접근의 형태
+
+- 데이터베이스 내에 저장된 정보를 **검색(read)**
+- 데이터베이스에 새로운 정보를 **삽입(create)**
+- 데이터베이스로부터 정보를 **삭제(delete)**
+- 데이터베이스 내에 저장된 데이터를 **수정(update)**
+
+### DML의 두 가지 형태
+
+### 절차적 DML(procedural DML)
+
+어떤 데이터가 필요하며 그 데이터를 어떻게 구할지 지정할 것을 요구한다.
+
+### 선언적 DML(declartive DML 또는 비절차적 DML(nonprocedural DML))
+
+필요한 데이터를 어떻게 구할지 명시할 필요 없이, 어떠한 데이터가 필요한지 지정할 것만 사용자에게 요구한다.
+
+### 질의
+
+`질의(query)`는 **정보 검색을 요청하는 구문**이다.
+
+데이터 조작 언어에서 정보 검색을 담당하는 부분을 `질의어(query language)`라고 한다.
+
+## 1.4.4 SQL 데이터 조작 언어
+
+SQL 질의어는 `비절차적 언어`다.
+
+**입력으로 한 개 이상의 테이블을 받아 항상 한 개의 테이블을 반환한다.**
+
+e.g., 역사학과의 모든 교수의 이름을 찾는 SQL 질의어
+
+```sql
+select instructor.name
+from instructor
+where instructor.dept_name = 'History';
+```
+
+질의는 하나 이상의 테이블에 있는 정보를 포함할 수도 있다.
+
+e.g., 예산이 $95,000보다 많은 학과의 모든 교수의 ID와 학과 이름을 찾아주는 SQL 질의어
+
+```sql
+select instructor.ID, department.dept_name
+from instructor,
+     department
+where instructor.dept_name = department.dept_name
+  and department.budget > 95000;
+```
+
+# 1.5 데이터베이스 설계
+
+1. 데이터베이스 설계의 초기 단계는 장래의 데이터베이스 사용자들이 **필요로 하는 데이터를 충분히 규정하는 것**이다.
+    - 이 단계의 결과물은 사용자의 `요구 명세서(specification of user requirements)`이다.
+2. `개념적 설계(conceptual-design) 단계`
+    - 설계자는 데이터 모델을 선택한다.
+    - 선택한 데이터 모델의 개념을 적용함으로써 사용자 요구를 데이터베이스의 개념적인 스키마로 바꾼다.
+    - 설계자의 초점은 물리적으로 어떻게 저장할 것인지 자세히 규정하는 것보다는 **데이터와 그들의 관계**를 기술하는 데 맞추어져 있다.
+    - 데이터베이스에서 우리가 포착하길 원하는 **어떤 속성**과, 다양한 테이블을 구성하는 이러한 속성을 **어떻게 그룹화**할 것인가에 대한 결정과 관련된다.
+        - `개체-관계 모델`의 사용
+        - 모든 속성의 집합을 입력으로 받아 테이블의 집합을 생성하는 `정규화(normalization)`로 알려진 알고리즘의 사용
+3. 사용자는 `기능적 요구 사항 명세서(specification of functional requirement)`에 데이터에 적용될 연산(혹은 트랜잭션)의 종류를 기술한다.
+    - 연산의 예시 : 데이터의 변경 혹은 갱신, 특정 데이터의 검색 및 추출, 데이터의 삭제
+    - 개념적 설계의 이 단계에서 설계자는 스키마가 기능적인 요구 사항을 잘 만족하는지 검토할 수 있다.
+
+> 추상 데이터 모델로부터 데이터베이스 구현으로 이동하는 과정은 마지막 두 설계 단계에서 이루어진다.
+> 
+1. 논리 설계 단계(logical-design phase)
+    - 설계자는 상위의 개념적 스키마를 사용할 데이터베이스의 구현 데이터 모델에 대응시킨다.
+2. 물리 설계 단계(physical-design phase)
+    - 데이터베이스의 물리적 속성이 구체화된다.
+    - 이러한 속성은 파일 구성(file organization)의 형식과 내부적인 저장 구조를 포함한다.
+
+# 1.6 데이터베이스 엔진
+
+데이터베이스 시스템은 여러 모듈로 구성되며, 각 모듈은 데이터베이스의 여러 책무를 나누어 맡는다.
+
+1. `저장 장치 관리자(storage manager)`
+2. `질의 처리기(query processor)`
+
+## 1.6.1 저장 장치 관리자
+
+- 데이터베이스 하부에 저장된 **데이터와 응용 프로그램 및 질의 사이의 인터페이스를 제공**하는 데이터베이스 시스템 요소다.
+- 파일 관리자(file manager)와 상호작용하는 책무가 있다.
+- 저장 장치 관리자는 다양한 DML 구문을 하위 단계의 파일 시스템 명령으로 변환한다.
+    - 그러므로 이는 **데이터베이스 내의 데이터를 저장하고 검색하며, 갱신하는 책임이 있다.**
+
+### 구성요소
+
+- `권한과 무결성 관리자`
+- `트랜잭션 관리자`
+- `파일 관리자`
+- `버퍼 관리자`
+
+### 구현하는 데이터 구조
+
+- `데이터 파일` : 데이터베이스 자체를 저장한다.
+- `데이터 사전`
+    - 데이터베이스의 구조에 관한 메타데이터를 저장한다.
+    - 특히 데이터베이스의 스키마를 여기에 저장한다.
+- `인덱스` : 특정한 값을 가지고 있는 데이터 항목에 빠르게 접근하기 위한 것이다.
+
+## 1.6.2 질의 처리기
+
+### 구성요소
+
+- `DDL 인터프리터` : DDL 문을 해독하여 데이터 사전 내에 기록한다.
+- `DML 컴파일러`
+    - 질의어 내의 DML 문을 질의 평가 엔진이 이해할 수 있는 하위 단계 명령어로 구성된 `질의 평가 계획`으로 바꾼다.
+    - DML 컴파일러의 책무 중 하나는 `질의 최적화(query optimization)`이다.
+        - 여러 질의 평가 계획 중 **가장 낮은 비용의 계획을 선택**하는 것이다.
+- `질의 평가 엔진` : DML 컴파일러가 생성한 하위 단계 명령을 실행한다.
+
+## 1.6.3 트랜잭션 관리
+
+보통 데이터베이스에 대한 몇 개의 연산이 하나의 논리적 작업 단위를 이룬다.
+
+예금 이체를 생각해보자. A는 출금 계좌이고, B는 입금 계좌다.
+
+### 원자성
+
+분명히, 입금과 출금이 **모두 일어나든지, 모두 일어나지 않든지** 하는 것이 필수적이다.
+
+즉, 예금 이체는 전체가 완전히 수행되거나, 전혀 수행되지 않아야 한다.
+
+이러한 **all or none 요구 조건**을 `원자성(atomicity)`이라고 한다.
+
+### 일관성
+
+또한 예금 이체의 실행은 데이터베이스의 **일관성을 보존해야 한다.**
+
+즉, A의 잔고와 B의 잔고를 합한 값이 보존되어야 한다.
+
+이러한 정확성에 관한 요구 조건을 `일관성(consistency)`이라고 한다.
+
+### 지속성
+
+시스템 고장의 가능성에도 불구하고 마침내 예금 이체가 성공적으로 끝난 뒤 A의 잔고와 B의 잔고의 새로운 값이 유지되어야 하는데, 이러한 **영속성의 요구 조건**을 `지속성(durability)`이라고 한다.
+
+### 트랜잭션(transaction)
+
+이는 데이터베이스 응용 프로그램에서 **하나의 논리적 기능을 수행하는 연산의 모임이다.**
+
+각 트랜잭션은 원자성과 일관성을 모두 지닌 단위로 수행되어야 한다.
+
+그러므로 **트랜잭션은 어떤 데이터베이스 일관성 제약 조건도 위반해서는 안 된다.**
+
+즉, 트랜잭션이 시작될 때 데이터베이스가 일관성 있는 상태였다면, 트랜잭션이 성공적으로 종료되었을 때에도 일관성 있는 상태여야 한다.
+
+각각의 트랜잭션이 데이터베이스의 일관성을 유지하도록 여러 트랜잭션을 적절하게 정의하는것은 프로그래머의 책임이다.
+
+### 트랜잭션 관리자
+
+`트랜잭션 관리자(transaction manager)`는 복구 관리자와 동시성 제어 관리자로 구성된다.
+
+- 원자성과 지속성을 보장하는 것은 데이터베이스 시스템, 특히 `복구 관리자(recovery manager)`의 책임이다.
+    - 원자성의 특성을 보장하려면 **실패한 트랜잭션이 데이터베이스의 상태에 아무런 영향을 주지 말아야 한다.**
+    - 즉, 데이터베이스는 실패한 트랜잭션이 일어나기 전 상태로 재저장되어야 한다.
+    - 그러므로 데이터베이스는 `고장 복구(failure recovery)`를 수행해야만 한다.
+- 데이터베이스의 일관성을 보장하기 위해 동시에 실행되는 트랜잭션들 간의 상호작용을 제어하는 것은 `동시성 제어 관리자(concurrency-control manager)`의 책임이다.
+
+## **1.7 데이터베이스 및 응용 구조**
+
+## 계층 구조
+
+백엔드(back-end)로 데이터베이스를 사용하는 응용의 구조는 다음과 같이 두 부분 또는 세 부분으로 나뉜다.
+
+### 2계층 구조
+
+초기 데이터베이스 응용은 `2계층 구조(two-tier architecture)`를 이용했다.
+
+이 구조에서는 응용 프로그램이 클라이언트 상에 존재하고 특정 질의문을 보냄으로써 서버에 있는 데이터베이서 시스템의 기능을 불러온다.
+
+### 3계층 구조
+
+`3계층 구조(three-tier architecture)`에서 클라이언트는 어떤 데이터베이스 호출도 직접적으로 수행하지 않고 단지 전처리 시스템으로서의 역할만 한다.
+
+- 프런트엔드(혹은 클라이언트)는 `응용 서버(application server)`와 통신을 한다.
+- 응용 서버는 차례로 데이터에 접근하기 위해 데이터베이스 시스템과 통신한다.
+
+어떤 작업(action)이 어떠한 조건하에서 수행되는지를 의미하는 `비즈니스 로직(business logic)`은 **응용 서버 쪽에 포함되어 있다.**
+
+이는 2계층 응용보다 더 좋은 성능뿐만 아니라 더 나은 보안을 제공한다.
+
+# 1.8 데이터베이스 사용자와 관리자
+
+## 1.8.2 데이터베이스 관리자
+
+`DBMS`를 도입하는 중요한 이유 중의 하나는 **데이터와 데이터에 접근하는 프로그램 모두에 대해서 중앙 제어를 가하자**는 것이다.
+
+중앙에서 제어하는 사람을 `데이터베이스 관리자(database administrator, DBA)`라고 한다.
+
+데이터베이스 관리자는 다음과 같은 일을 한다.
+
+- 스키마 정의
+- 저장 구조와 접근 방법 정의
+- 스키마 및 물리 구조 수정
+- 데이터 접근 권한 인정
+- 일상적인 유지 보수
\ No newline at end of file