[CS] 데이터베이스 - 1. DBMS와 관계형 모델

J.Noma·2022년 1월 25일
0

컴퓨터 공학

목록 보기
1/18

Reference


🌀 Database Management System(DBMS)

🔸 데이터베이스란

대규모의 정보를 사용하고 관리할 수 있도록 체계적으로 모아놓은 것. 필요에 의해 일정한 형식으로 저장해놓은 것

🔸 DBMS란 무엇인가

이러한 데이터집합과 데이터를 사용할 수 있는 프로그램으로 구성. 이런 프로그램을 통해 데이터를 추가/삭제/조회를 할 수 있음. 사용자가 편리하고 효과적으로 이를 할 수 있도록 환경을 제공. 즉, 에러핸들링, 보안 등의 기능도 포함

🔸 데이터베이스 응용분야

  • 은행계좌이체
  • 공항 예약, 스케줄
  • 대학 수강신청, 학적관리

🔸 DBMS가 없던 시절엔?

옛날에는 어떤 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 스키마가 있으며 둘은 서로 독립적으로 변경될 수 있다

🔘 인스턴스

특정 한 시점에 데이터베이스에 저장된 정보


🌀 Data Models / Data Languages / Data Design Approaches

🔸 Data Models

DB 구조를 기술하기 위해선 Data model 개념을 알아야 한다. Data model은 DB의 바탕이 되는 구조. 저장된 데이터 간 관계를 설명해주는 것. DB의 논리적인 구조가 어떻게 만들어지는지 정의. 데이터가 어떻게 연결되는지 정의. 시스템 내에서 데이터가 어떻게 저장되는지. 데이터의 구조뿐만 아니라 이런 구조에서 허용되는 연산, 제약조건 등을 포함하는 개념

초기 Data model은 모든 DB가 하나의 테이블로 표현되고 모든 데이터는 하나의 행에 저장되었다(flat DB). 이런 방식은 직관적이지만 객체들의 복잡한 관계를 표현할 수 없어 관계형 모델이 탄생한다

🔘 구성요소

  • 데이터
  • 데이터 관계
  • 데이터 semantics
  • 데이터 제약조건

🔘 종류

  • 관계형 모델
    2차원 테이블. 직관적이다. SQL을 통해 접근 가능 (참고로 SQL은 관계형 모델이 업계표준이 되는데 큰 기여를 함). 모든 데이터를 테이블로 표현하므로 각 row가 같은 수의 column을 가져야 함. 데이터 관계를 직접적으로 표현하지 않고 암시적으로 표현함 (2장에서 자세히 알아볼 예정). 테이블 형태로 한정되므로 새로운 데이터 타입을 생성 및 기존 타입 확장이 불가함. 비정형 복합정보 표현이 매우 어렵다
  • Entity-Relationship(ER) 모델
    DB를 설계하는 기본단계에서 사용되는 데이터 모델. DB 요구사항 명세서를 기반하여 어떤 데이터가 필요한지 선정하게 되는데 이때 ER 모델이 사용된다. ER 모델을 관계형 모델로 맵핑할 수 있다 (7장에서 자세히 알아볼 예정)
  • 객체 기반 모델
    객체 모델을 기반으로 정보를 저장/검색하는 DB 모델. 기존 관계형 DB의 안정적인 성능에 기반하면서 동시에 객체 지향의 모델링 파워를 가미할 수 있음
  • 반정형 모델
    기존 DB 모델처럼 구조화되어있진 않지만 HTML/XML처럼 메타데이터와 스키마 정보를 포함함. 이를 표현하기 위해 태그나 마커가 수반됨. 변경에 유연하다
  • 그 외
    네트워크 모델은, 데이터를 그래픽으로 표현하며 어떤 엔티티를 여러 path로 접근가능하다. SNS App에서 각광받는 중
    계층형 모델은, 말 그대로 계층구조를 가지는 데이터 모델

🔸 Data Language

DB에서 사용되는 언어를 의미. 기능에 따라 Data Manipulation Language(DML)과 Data Definition Language(DDL)로 나눌 수 있다. DB를 구축하고 사용하기 위해 DBMS와 상호작용하는 수단이 된다

🔘 Data Manipulation Language(DML)

데이터의 삽입/삭제/조회를 DBMS로 요청하는 언어. Query 언어라고도 불린다. DML을 크게 2가지로 나눌 수 있다. SQL이 대표적인 Declarative DML에 속한다

  • Procedural
    사용자가 어떤 데이터를 원하는지, 어떻게 그 데이터를 얻을 수 있는지를 전부 명시하여 시스템에게 알려야 한다
  • Declarative (non-procedural)
    데이터를 어떻게 얻는지에 대한 자세한 명시없이 어떤 데이터가 필요한지만 명시하면 된다

🔘 Data Definition Language(DDL)

DB 스키마를 정의하는 언어. DDL은 스키마를 정의하고 데이터의 추가적인 특성을 표현하는데 사용됨

DDL 컴파일러는 DDL로 작성된 스키마를 해석해서 새로운 DB를 구축하고, 메타데이터를 테이블형태로 Data Dictionary에 저장합니다.

메타데이터에는 DB 스키마, 데이터 제약조건(기본키 제약조건/참조 무결성), 자원에 대한 접근권한 등이 포함됩니다

🔸 SQL

널리 사용되는 non-procedural 언어. 관계형 DB에서는 테이블을 relation이라고 부른다

  • select : 원하는 정보
  • from : 어떤 테이블로부터 찾을 것인지
  • where : 원하는 정보의 조건

위 예제 중 2번 예제는 2개의 relation을 사용해야 하는 경우로 두 relation을 cartesian product하여 하나의 relation으로 합친다 (나중에 다룸)

🔘 App이 DB에 접근하는 방법

  • embedded SQL 사용
  • ODBC/JDBC 등을 사용하여 프로그램을 만드는 것

🔸 Data Design Approaches

🔘 Data Design 관련 문제 예시

relation을 막연히 합쳤을 때 발생할 수 있는 문제 예시

  1. 한 교수가 여러 학부에 속하는 경우 중복이 발생할 수 있다
  2. 새로운 dept_name이 생겼을 때 교수가 한명이라도 임용되기 전까지 정보 입력이 불가하다. 기본키로 사용되는 교수 ID가 NULL일 수 없기 때문

🔘 정규화 이론

불필요한 데이터 중복을 막기위해 relation을 나누어 주는 것. 또한 이런 정규화를 기설계한 relation/스키마가 잘 설계가 된 것인지 평가하는데도 사용될 수 있따

🔘 ER 모델

DB를 설계하기 위한 기본단계. 요구사항 분석 명세서를 작성하고 이를 기반하여 필요한 데이터를 선정하게 되는데 이 때 ER 모델을 사용

  • Entity
    DB 내에서 변별가능한 객체. 저장의 대상이 되는 어떤 것. Attribute의 집합으로 표현됨 (ex. 학생이라는 Entity는 학번,학년 등의 Attribute를 가진다)

  • Relationship
    Entity 간 관계를 의미

위와 같은 ER 다이어그램으로 표현될 수 있다

  • 파란박스 : entity
  • 흰박스 : attribute
  • 밑줄 : 기본키
  • 가운데마름모 : relationship

🌀 DBMS 구성요소, 아키텍처

🔸 DBMS 구성요소

DBMS는 여러 개의 모듈로 구성됩니다. 기능적으로 구분했을 때 크게 Storage Manager와 Query Processor로 나누어볼 수 있습니다. 추가로 Transaction Manager도 꼽을 수 있습니다

🔘 Storage Manager

DB 상에 존재하는 low-level 데이터, Application, Query 간 인터페이스를 제공하는 모듈입니다

Storage Manger는 file manager와 상호작용하고 데이터를 효과적으로 저장,수정,조회하는 작업을 책임집니다

Storage Manger의 주요 관심사는 storage에 어떻게 접근하고 파일들을 구조화할지입니다. 또한, DB에서 원하는 데이터를 효율적으로 접근하기 위해 Indexing/Hashing입니다

🔘 Query Processor

사용자 친화적인 형태의 SQL Query가 들어오면 Query Processor를 통해 아래의 과정을 거쳐 시스템이 사용하기에 적합한 형태로 변경하여 최종적으로 결과데이터(Query Output)을 도출합니다

  • parser/translator : 문법 및 relation 존재여부 검사
  • relational-algebra : 트리형태의 관계대수 표현으로 변환
  • optimizer : Query 처리과정을 최적화 (통계도 활용하여)
  • execution plan : optimizer의 결정에 기반하여 non-procedural 언어인 SQL Query를 시스템이 처리할 수 있도록 procedural하게 변환
  • evaluation engine : execution plan로 획득한 data를 Query의 결과로써 반환

🔘 Transaction Manager

시스템이 고장나거나 여러 사용자가 동시에 하나의 데이터를 갱신하려 하는 경우 아무것도 할 수 없는 파일시스템과 달리 DBMS는 스스로 복구를 시도합니다. 이때 중요한 개념이 Transaction입니다

transaction은 많은 사람들이 DB를 사용하는 주요한 이유 중 하나로, 어떤 논리적 기능 1개를 하기 위해 all or nothing으로 수행되는 명령어 집합을 말합니다 (ex. 계좌이체라는 transaction 내에는 발신계좌확인/수신계좌확인/송금/송금확인 등의 명령어 집합이 포함되며 중간에 오류가 생기면 전부 취소해야 합니다)

transaction을 위해 몇가지 요소들이 있습니다

  • Transaction-management Component
    all or nothing을 관리하여 데이터의 일관성을 지켜주는 요소입니다

  • Concurrency-control manager
    동시에 요청되는 transaction을 관리합니다. 어떤 사용자가 먼저 사용할지 순서를 정하거나 동시작업이 가능한 사용자 간에는 이를 허락하는 등이 포함됩니다

🔸 DBMS 아키텍처

🔘 DBMS 전체적인 구조

참고로, transaction manager는 storage manager 단계에서 동작합니다

🔘 DBMS Architecture

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의 값들을 의미. 테이블 형태로 보여짐

🔸 Keys

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를 외래키라 한다


🌀 Relational Query Language

사용자가 DB로부터 정보를 요청할 때 사용하는 언어. 프로그램을 작성하는데 사용되는게 아닌 이론적인 언어 (Pure 언어라고도 한다). Relational Query Language에는 procedural한 Relational Algebra와 non-procedural한 Relational Calculus가 있다

🔸 Relational Algebra

Relational Algebra는 절차적인 언어로, relation에서 원하는 결과를 얻기 위해 수학의 대수와 같은 연산을 이용해서 질의하는 방법을 기술하는 언어이다. relation들을 연산하는 관계 대수식으로 구성하며 연산의 결과로 새로운 relation이 만들어진다

Relational Algebra를 크게 두개로 나눌 수 있다

🔘 Relational Operation

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 Operation

Set 연산들은 대상이 되는 relation의 튜플의 구조(Attribute) 가 같아야 한다
ex) Union, Intersaction, Set Difference

  • Union
    합집합
  • Intersaction
    교집합

🔸 Relational Calculus

반대로 Relational Calculus는 비절차적인 언어로, 원하는 결과만 기술한다. SQL은 Relational Calculus를 기반으로 하고 있지만 DBMS 내부에서는 Relational Algebra를 기반으로 둔 연산을 수행한다

profile
노션으로 이사갑니다 https://tungsten-run-778.notion.site/Study-Archive-98e51c3793684d428070695d5722d1fe

0개의 댓글