Reference
- 내용전반: edwith
대규모의 정보를 사용하고 관리할 수 있도록 체계적으로 모아놓은 것. 필요에 의해 일정한 형식으로 저장해놓은 것
이러한 데이터집합과 데이터를 사용할 수 있는 프로그램으로 구성. 이런 프로그램을 통해 데이터를 추가/삭제/조회를 할 수 있음. 사용자가 편리하고 효과적으로 이를 할 수 있도록 환경을 제공. 즉, 에러핸들링, 보안 등의 기능도 포함
옛날에는 어떤 App에 데이터저장이 필요하면 파일시스템을 통해 저장하도록 개발이 필요했고 이로 인해 많은 문제가 발생했다
Data Redundancy, Inconsistency
시간이 지나며 App이 변경되거나 서로 다른 App이 같은 데이터에 접근할 경우 파일 포맷이 다르다던지 등의 이유로 불필요한 카피가 생기고 App간 데이터 불일치 문제 발생 가능
Data 요구사항 변경에 대응하기 어렵다
예로, 기존의 App 시스템이 모든 데이터를 불러오도록 구현되어 있는데 특정 데이터만 뽑는 새로운 요구사항이 들어왔을 때 매번 새로운 App을 찍어내야 한다
Data Isolation
서로 관련있는 데이터가 서로 다른 파일/포맷에 존재하는 것. 이 또한 App마다 데이터 관리 구현이 달라 발생할 수 있는데, 이 경우 데이터 관리가 매우 복잡해진다
Integrity 문제
데이터 제약조건(integrity constraint, ex. 잔고는 0원 이상이어야 한다)을 걸기 어렵다. 파일시스템에서는 자체적으로 이를 막을 방법이 없고 각 App을 만들 때 신경써야 하는데 모두가 통일된 integrity constraint를 잘 만드리란 보장이 없다. 가장 문제는 constraint를 추가/변경이 매우매우 어렵다
Atomic한 업데이트가 어렵다
데이터 업데이트는 완전히 성공하거나 아예 건드리지 않아야 일관성 문제를 피하고 대처할 수 있다(all or nothing). 파일시스템은 부분적인 업데이트를 막지 못한다. 업데이트 도중에 문제가 생기면 roll back해야 문제를 막을 수 있다
여러 사용자의 동시접속 관리 불가
파일시스템은 자체적으로 동시접속 관리 메커니즘이 없으므로 불일치 문제를 야기한다
보안 문제
파일시스템은 데이터를 일부만 허용하는게 어렵다. 유저 access control 관리가 어렵다
DBMS의 주요목적 중 하나는 사용자에게 데이터 추상화/단순화를 제공하는 것을 말하며 추상화 크게 3가지 level에서 기술됩니다
Physical level
물리적인 스토리지 단위로 추상화
Logical level
데이터 단위로 추상화. 데이터 간 관계를 기술. physical level에서 다루는 어느 스토리지에 저장되냐는 고려하지 않음. 각 App은 logical level로 추상화된 데이터를 다루게 된다
View level
가장 높은 수준의 추상화로 정보 단위의 추상화. 데이터타입을 숨기고 필요한 부분, 공개된 부분만 공개. 사용자에게 편의를 제공하는 목적
데이터베이스의 전체적인 설계 구조를 기술한 것. 추상화 level에 따라 physical/logical 스키마가 있으며 둘은 서로 독립적으로 변경될 수 있다
특정 한 시점에 데이터베이스에 저장된 정보
DB 구조를 기술하기 위해선 Data model 개념을 알아야 한다. Data model은 DB의 바탕이 되는 구조. 저장된 데이터 간 관계를 설명해주는 것. DB의 논리적인 구조가 어떻게 만들어지는지 정의. 데이터가 어떻게 연결되는지 정의. 시스템 내에서 데이터가 어떻게 저장되는지. 데이터의 구조뿐만 아니라 이런 구조에서 허용되는 연산, 제약조건 등을 포함하는 개념
초기 Data model은 모든 DB가 하나의 테이블로 표현되고 모든 데이터는 하나의 행에 저장되었다(flat DB). 이런 방식은 직관적이지만 객체들의 복잡한 관계를 표현할 수 없어 관계형 모델이 탄생한다
DB에서 사용되는 언어를 의미. 기능에 따라 Data Manipulation Language(DML)과 Data Definition Language(DDL)로 나눌 수 있다. DB를 구축하고 사용하기 위해 DBMS와 상호작용하는 수단이 된다
데이터의 삽입/삭제/조회를 DBMS로 요청하는 언어. Query 언어라고도 불린다. DML을 크게 2가지로 나눌 수 있다. SQL이 대표적인 Declarative DML에 속한다
DB 스키마를 정의하는 언어. DDL은 스키마를 정의하고 데이터의 추가적인 특성을 표현하는데 사용됨
DDL 컴파일러는 DDL로 작성된 스키마를 해석해서 새로운 DB를 구축하고, 메타데이터를 테이블형태로 Data Dictionary
에 저장합니다.
메타데이터에는 DB 스키마, 데이터 제약조건(기본키 제약조건/참조 무결성), 자원에 대한 접근권한 등이 포함됩니다
널리 사용되는 non-procedural 언어. 관계형 DB에서는 테이블을 relation
이라고 부른다
위 예제 중 2번 예제는 2개의 relation을 사용해야 하는 경우로 두 relation을 cartesian product하여 하나의 relation으로 합친다 (나중에 다룸)
relation을 막연히 합쳤을 때 발생할 수 있는 문제 예시
불필요한 데이터 중복을 막기위해 relation을 나누어 주는 것. 또한 이런 정규화를 기설계한 relation/스키마가 잘 설계가 된 것인지 평가하는데도 사용될 수 있따
DB를 설계하기 위한 기본단계. 요구사항 분석 명세서를 작성하고 이를 기반하여 필요한 데이터를 선정하게 되는데 이 때 ER 모델을 사용
Entity
DB 내에서 변별가능한 객체. 저장의 대상이 되는 어떤 것. Attribute의 집합으로 표현됨 (ex. 학생이라는 Entity는 학번,학년 등의 Attribute를 가진다)
Relationship
Entity 간 관계를 의미
위와 같은 ER 다이어그램으로 표현될 수 있다
DBMS는 여러 개의 모듈로 구성됩니다. 기능적으로 구분했을 때 크게 Storage Manager와 Query Processor로 나누어볼 수 있습니다. 추가로 Transaction Manager도 꼽을 수 있습니다
DB 상에 존재하는 low-level 데이터, Application, Query 간 인터페이스를 제공하는 모듈입니다
Storage Manger
는 file manager와 상호작용하고 데이터를 효과적으로 저장,수정,조회하는 작업을 책임집니다
Storage Manger의 주요 관심사는 storage에 어떻게 접근하고 파일들을 구조화할지입니다. 또한, DB에서 원하는 데이터를 효율적으로 접근하기 위해 Indexing/Hashing입니다
사용자 친화적인 형태의 SQL Query가 들어오면 Query Processor를 통해 아래의 과정을 거쳐 시스템이 사용하기에 적합한 형태로 변경하여 최종적으로 결과데이터(Query Output)을 도출합니다
시스템이 고장나거나 여러 사용자가 동시에 하나의 데이터를 갱신하려 하는 경우 아무것도 할 수 없는 파일시스템과 달리 DBMS는 스스로 복구를 시도합니다. 이때 중요한 개념이 Transaction
입니다
transaction은 많은 사람들이 DB를 사용하는 주요한 이유 중 하나로, 어떤 논리적 기능 1개를 하기 위해 all or nothing으로 수행되는 명령어 집합을 말합니다 (ex. 계좌이체라는 transaction 내에는 발신계좌확인/수신계좌확인/송금/송금확인 등의 명령어 집합이 포함되며 중간에 오류가 생기면 전부 취소해야 합니다)
transaction을 위해 몇가지 요소들이 있습니다
Transaction-management Component
all or nothing을 관리하여 데이터의 일관성을 지켜주는 요소입니다
Concurrency-control manager
동시에 요청되는 transaction을 관리합니다. 어떤 사용자가 먼저 사용할지 순서를 정하거나 동시작업이 가능한 사용자 간에는 이를 허락하는 등이 포함됩니다
참고로, transaction manager는 storage manager 단계에서 동작합니다
DBMS의 아키텍쳐는 DBMS가 구동되는 컴퓨터 시스템에 의해 많은 영향을 받게 됩니다
Centralized
모든 것(DBMS, Application)을 중앙에 위치한 단일 컴퓨터에 집중시킨 구조
Client-Server
클라이언트와 서버가 책임을 분담
Parallel
하나의 컴퓨터로 성능 요구사항을 충족시키기 어려워 여러 대의 프로세서를 동시에 돌리는 것
Distributed
논리적으로는 하나의 DB 시스템이나 물리적으로 데이터/기능을 분산시킨 것
데이터베이스는 여러 개의 Relation이 모여 구성된다
Relation
테이블을 의미하며 고유한 이름을 가진다. 튜플의 집합. 이름이 relation인 이유는 테이블이 독립적인 값(데이터)들 사이의 관계(relationship)를 보여주기 때문
튜플
테이블의 행(row)을 가리키는 용어로, 값들의 관계를 의미. 하나의 Relation 내 튜플의 개수를 cardinality라 한다
일반적인 테이블과 달리, Relation 내 튜플들은 집합의 개념이므로 순서가 없다. 또한, 중복이 있어서는 안된다
Attribute
테이블의 열(column)을 가리키는 용어
각 Attribute에 허락된 값의 범주를 Attribute의 도메인
이라 한다
Attribute의 값은 atomic
해야 한다. 즉, 더 나뉘어질 수 없는 하나의 값만 저장할 수 있다
아직 알지 못하거나 존재하지 않음을 나타내기 위해 NULL
을 사용할 수 있다. 하지만, NULL은 relation 연산들을 정의할 때 복잡도 증가를 야기하므로 되도록이면 사용하지 않는게 좋다
Relation 스키마
Relation 스키마는 Attribute의 리스트와 도메인으로 구성된다
R = (A1, A2, ..., An)
D1 x D2 x ... x Dn
Relation 인스턴스
현재 Relation의 값들을 의미. 테이블 형태로 보여짐
Attribute들의 값을 보고 각각의 튜플을 구별할 수 있어야 하고 Attribute 값이 모두 같은 튜플은 존재하면 안된다. Key는 튜플 구분을 위한 Attribute의 집합을 말한다
참고로, key의 Attribute가 2개 이상일 경우 composite key(복합키)라고 한다
superkey
어떤 key가 Relation 내 모든 튜플을 구별하기에 충분하면 superkey라고 한다
candidate key
superkey 중 가장 minimal한 것
primary key(기본키)
DB에서 튜플을 구별하기 위해 사용할 key를 말하며 candidate key 중 하나를 선택한 것. primary key Attribute들은 Relation의 앞부분에 적어주는 것이 일반적
primary key로 지정된 Attribute들의 값은 NULL이 되면 안된다
Foreign key(외래키)
Relation들 간 관계를 올바르게 표현하기 위해 사용되는 key. 서로 다른 Relation에 있는 튜플들을 연결시켜주기 위해 Relation들이 공통적으로 사용하는 Attribute를 외래키라 한다
사용자가 DB로부터 정보를 요청할 때 사용하는 언어. 프로그램을 작성하는데 사용되는게 아닌 이론적인 언어 (Pure 언어라고도 한다). Relational Query Language에는 procedural한 Relational Algebra
와 non-procedural한 Relational Calculus
가 있다
Relational Algebra는 절차적인 언어로, relation에서 원하는 결과를 얻기 위해 수학의 대수와 같은 연산을 이용해서 질의하는 방법을 기술하는 언어이다. relation들을 연산하는 관계 대수식으로 구성하며 연산의 결과로 새로운 relation이 만들어진다
Relational Algebra를 크게 두개로 나눌 수 있다
ex) Selection, Projection, Cartesian Product, Natural Join
Selection
조건에 맞는 튜플을 선택(Selection)하여 결과 relation을 도출
Projection
조건에 맞는 Attribute를 추출하여 결과 relation을 도출. 중복은 제거할 수도, 제거하지 않을 수도 있다
Cartesian Product
두 개의 relation을 연결하는 연산자. 곱하기 연산이라 볼 수 있다. 각 튜플을 N x M하여 결과를 도출
Natural Join
마찬가지로 두 개의 relation을 연결하는 연산자. 공통된 Attribute + Attribute 값을 가진 튜플끼리 합치는 것. 안 겹치는건 날린다. 아래 그림에선 공통된 Attribute(B/D)를 기준으로 같은 값을 가진 튜플끼리 합성하고 겹치지 않는 튜플은 날린다
Set 연산들은 대상이 되는 relation의 튜플의 구조(Attribute) 가 같아야 한다
ex) Union, Intersaction, Set Difference
반대로 Relational Calculus는 비절차적인 언어로, 원하는 결과만 기술한다. SQL은 Relational Calculus를 기반으로 하고 있지만 DBMS 내부에서는 Relational Algebra를 기반으로 둔 연산을 수행한다