[Data Base] 1-1 Data Base에 관하여...

제가 이번에 데이터 베이스에 대해 공부하게 되었습니다.

그래서 데이터 베이스에 대해서 공부한 내용을 정리도 할겸 포스팅을 시작해볼 생각입니다.

데이터 베이스외에도 스프링 부트 및 웹에 관련된 내용과 네트워크에 대한 간단한 내용들

도 정리해서 포스팅 해보려고 합니다.

이해를 돕고 그것을 또 다시 정리해보려는 목적으로 정리해보려고 합니다.

글이 다소 난해할수 있는 점 양해해주시길 바라면서.. 저는 포스팅 해보겠습니다.


먼저, 데이터 베이이스와 그 시스템의 세계에 대해 보려고 합니다.

데이터베이스란, 데이터베이스는 데이터베이스 관리 시스템에 의해 관리되는 데이터의 집합을 얘기합니다.

여기서, 데이터베이스 관리 시스템(Data Base Management System)이란?

특정 목적을 위해서 존재하는 데이터베이스를 다수의 사용자가 동시에 안전하고 효율적인 사용할 수 있도록 하는 S/W들의 집단을 의미합니다.

DBMS는 영구적인 저장이 가능하여 대용량 데이터의 효율적 관리가 가능합니다.

DBMS의 프로그램 인터페이스
-> 사용자나 프로그램 개발자에게 데이터의 용이한 접근 및 수정 방법을 제공합니다.

DBMS는 트랜잭션(Transaction) 관리도 합니다,

여기서 트랜 잭션은 O/S에서 Task 같은 것으로 DBMS의 작업 단위로 생각하면 됩니다.

DBMS의 기능에 대해서 알아보면 다음과 같습니다.

데이터 정의 언어(Data definition language : DDL, ex) SQL)에 의한 스키마 정의를 하고

질의 언어(query language)나 데이터 조작 언어(data manipulation language : DML)에 의한 데이터 접근이 가능합니다.

또한, 데이터 베이스를 위한 안전하고 효율적인 저장 장소를 제공하며 병행 수행 제어가 가능합니다.

동시 데이터 접근에 의하여 우발적인 데이터 손상 방지를 병행 수행 제어가 맡습니다.

1960년대 후반에 최초의 상용 DBMS가 나왔고, 화일 시스템으로부터 발전 되었습니다.

여러종류의 데이터 모델(계층 모델, 네트워크 모델)이 있고, 당시 DBMS는 고수준 질의 언어를 지원하지 않았습니다. (SQL이 존재하지 않았음.)

DBMS는 여러 분야로 응용되어 사용됩니다.

항공 예약 시스템, 은행 시스템, 법인 레코드, 웹 쇼핑몰 등과 같은 데이터가 중요하게 쓰이는 곳에서 반드시 필요한 것입니다.

관계 데이터베이스 시스템을 살펴보면,

관계 모델(relational model)이 있습니다. 관계 모델은 1970년대에 Ted Codd에 의해 제안되었고 데이터를 테이블의 형태로 표현했습니다. 질의의 고수준 언어로 표현이 가능합니다.

accountNo | blance | type -> 애트리뷰트
   12345    |1000.00 | savings -> 튜플
   67890    |2846.92 | checking 

    Accounts 테이블

다음과 같은 형식의 표를 데이터를 관계 모델 형식으로 테이블 형태로 표현 해본 것입니다.
SQL문으로 이것을 살펴보면 다음과 같습니다.

SQL

SELECT blance // blance 항목을 찾고
FORM Accounts // Accounts 테이블로부터
WHERE accountNo = 67890; // accounNo 항목의 67890 데이터로부터

SELECT accountNo // account 항목을 찾고
FROM Accounts // Accounts 테이블로부터
WHERE Type = 'savings' and balance < 0;  // savings 타입에서 balance(금액)이 0이하인 계좌를 찾을 것.

위와 같이 표현이 가능하다고 했는데, 먼저 애트리뷰트는 테이블에서 데이터를 어떤 항목으로 나눠야하는데, 그 항목(값)을 나타내는 것 같고 튜플은 그 실제 데이터내의 값을 나타내는 것 같습니다. 뒤로 갈수록 더 자세하게 다룰 것 같네요.

정리하면, 관계 모델은 저렇게 위와 같이 나타낼 수 있습니다.

DBMS는 원래 대형 컴퓨터에서 가동되는 거대하고 값비싼 소프트웨어 시스템이었다.

오늘날, 기가바이트 단위의 데이터는 하나의 디스크에 저장될 수 있고, DBMS를 PC에서 구동하는 것도 가능하다.
- DBMS가 소형 기계에서도 사용가능하게 되었다.
* Linux, window 등에서 Oracle, DB2, MS SQL, Server 등의 DBMS 구동.

그리고 더더욱 이제는 기가바아트 단위도 대용량이 아니다.
- 테라바이트 혹은 그 이상의 정보도 요구되어지기도 한다.

대용량 데이터를 위한 요구사항이 필요하다.

3차 저장 매체(tertiary storage) : CD, DVD, BD
-> 디스크보다 큰 접근 시간, 그러나 더 많은 저장 공간

병렬 연산
-> 병렬 디스크 접근, RAID 디스크(대표적인 병렬 디스크 접근 방식)
-> 병렬 컴퓨터나 분산된 컴퓨터들에서 병렬 질의 수행.

다음으로는 클라이언트 / 서버 구조에 대해서 보자.

클라이언트 / 서버 프로세싱
-> 한 프로세스(클라이언트)가 다른 프로세스(서버)에게 작업을 요청.

서버는 성능과 구조가 좋아야한다. 많은 클라이언트를 받아들이기 위해서이다.

즉, DBMS도 이 방식을 유지하고 있다. 이 방식을 C/S 아키택쳐라고 한다.

다음으로는 데이터 웨어하우스에 대한 내용이 있습니다.

한 기관내에 여러 데이터베이스들이 있을 수 있습니다.

그럼 각 데이터베이스마다 다른 DBMS들, 정보에 대한 다른 구조들을 가질 수 있습니다.

그리하여 여러 테이터베이스들에 있는 정보는 적절하게 변역되어 중앙 데이터베이스에 복사하여 관리하게 되어지는 구조입니다.

이 중앙 DB에 있는 데이터는 기획과 분석을 위해 사용되어 질 수 있습니다.

다음 그림을 보면 이해하기 쉬울 것입니다.

그림을 보면 가 나 다 라 라는 회사들이 있고 각기 다른 DBMS를 사용하고 있습니다.

가 회사와 다 회사를 보면 같은 오라클 DBMS를 사용하지만, 상위버전과 하위버전을 사용합니다.

이 경우, 호환이 안될 수 있습니다. 그렇기에 각 회사들은 서로 DBMS가 다르기 때문에

다른 DBMS를 사용할 수 없고 호환되지 않습니다.

그렇기에 데이터웨어 하우스라는 개념이 필요한 것입니다.

각 그룹의 DBMS가 다르더라도 동일한 하나의 중앙 DB에 upload를 통해서 각 그룹의 데이

터를 효율적으로 관리할 수 있게 됩니다. 각 그룹이 호환되지 않더라도, 중앙 DB에서 통합

관리가 가능해집니다.

아 중앙 DB를 데이터 웨어하우스라고 하고, 이 중앙 DB는 읽기만 가능하고 수정이 불가능합니다.

그 이유는 중앙 DB의 내용을 수정하게 되어버리면 통합 관리하는 의미가 없어지기 때문에

수정해야 할 사항이 생기면 해당 DB에서 새롭게 업로드를 해야합니다.

그리고 이 커다란 중앙 DB에서 고급 데이터를 채굴하는 것을 데이터 마이닝이라고 합니다.

빅 데이터의 원리로 이와 비슷한 형태입니다. 데이터를 추출 또는 채굴하는 것으로 생각됩니다.

다음으로 DBMS의 구성요소의 개요를 조금 살펴볼텐데, 먼저 그림으로 보면

다음과 같습니다.

그림을 보면서 처음부터 살펴보는게 좋을 것 같습니다.

질의(query)는 데이터에 관한 질문을 나타냅니다.

데이터 변경(modification)은 데이터를 변경하기 위한 연산을 나타냅니다.

스키마(Schema) 변경은 메타 데이터를 변경하기 위한 연산을 나타냅니다.

*여기서 스키마가 무엇인지 보면, 위의 Accounts 테이블의 구조정보가 스키마라고 할 수 있을 것 같습니다.

즉, Accounts 테이블의 애트리뷰트 리스트가 스키마가 되는 것 같습니다.

Accounts 테이블의 기존 애트리뷰트의 내용을 추가하거나 삭제하는 것? 이것이 스키마 변경이 될 수 있습니다.

메타 데이터(meta data)는 데이터의 구조에 대한 정보입니다.

DB안에 들어있는 스키마의 정보들, 데이터를 위한 구조정보나 구성 정보를 통틀어서 메타 데이터라고 하는 것 같습니다.

이 부분은 맨 처음에 나오는 부분들로 전체적으로 훓고 지나가는 형식입니다.

이런게 있다는 것만 알고 넘어가도 뒤에 가면 갈수록 더 자세하게 다룰 예정이니 너무 어렵

게 생각하지 않아도 될 것 같습니다.

이제 질의 처리기에 대해서 살펴보면 질의 컴파일러(query compiler)를 보면

질의 파서(parser) : 문자열 형태의 질의를 트리 구조로 변환. 

질의 선처리기(preprocessor) : 질의에 대한 의미 조사 및 초기 질의 계획 작성.

질의 최적화(optimization) : 효과적인 질의 계획(즉, 저장 시스템에 대한 요청들)을 선택 -> I/O 횟수를 최소화시킴.

질의 처리기(즉, SQL 컴파일러가 되는 것 같다.)가 결국 SQL 문장(Syntax)가 맞는지 파싱(검사)을 하며 문자열 형태의 질의(query)를 트리 구조로 변환(Parser가 해준다.)

질의 최적화 과정을 거쳐서 효율적인 질의를 계획 해주는 역할을 한다.

질의 최적화 -> 효과적인 질의 계획, 효율적인 계획을 탐구해야함.

효율적인 계획이라면 Disk I/O 횟수를 최소화시킨다.

다음으로 저장 및 버퍼 관리기가 있는데.. 이에 대해서 조금 살펴보면 다음과 같다.

저장 및 버퍼 관리기는 파일 관리기와 버퍼 관리기로 나뉘는데, 먼저 파일 관리를 보면 

다음과 같다.

일반적인 방식으로는 SQL이 File System을 거쳐 DB의 Oracle DB를 찾아서 조회하는 방식

인데, 이 방식은 운영체제를 거쳐야 하는 방식이라 비효율적이다.

하지만 효율적인 방식으로 현재의 Disk에 파티션을 나눠서 오라클 용 DB를 구축하면 오라

클 용 File System은 이 DB에 구축하여 생성하게 된다. 이 방식을 사용하면 Windows 운영

체제를 거치지 않고, 바로 오라클 전용으로 만든 DB에 접근할 수 있다.

이 방법을 쓰는 이유는 Windows의 간섭없이 빠르게 오라클 DB를 활용과 접근 할 수 있다.

여기까지가 파일 관리기 방식의 내용이고

버퍼 관리기의 방식은 다음과 같다.

원래라면 Disk에서 RAM으로 data를 오랜 시간을 들여 가져와야 하나 시간이 많이 걸리기 

때문에 RAM에 있는 버퍼라는 공간에 자주 쓰는 데이터를 옮겨 둠으로써 disk에서 가져오

지 않고 버퍼에서 가져옴으로써 시간을 상당히 절약할 수 있다.

이것이 버퍼 관리기의 방식이다.

다음으로는 트랜잭션 처리에 대해서 알아볼 것이다.

트랜잭션 -> ACID 특성을 만족하는 연산들의 그룹이다.

ACID 성질이란?

원자성(Atomicity) : 모두 실행되거나 전혀 실행되지 않아야 함.

이 원자성을 살펴보면 트랜잭션 내의 할 일들은 일부만 실행 될 수 없다는 것을 얘기한다.

아예 실행되지 않거나 모두 실행되어야 한다. 즉, 실행되다가 완료되지 않고 종료 될 수 없다는 것을 얘기한다.

예를 들면, 내 계좌에서 -10만을 하면 출금이 10만원이 나와야 하는데, 이 출금되는 과정을 

거치다가 갑자기 정전이 되어버리면 내 돈이 나오지 않고 -10만이 되어 버리면 안된다.

즉, 중간에 중단되면 아예 실행되지 않은 상태(nothing)이 되어야한다.

일관성(Consistency) : 트랜잭션의 실행이 완료된 후에는 데이터베이스가 모두 일관성 조건

을 만족해야 함.

그러니까, T 트랜잭션을 실행하고 난 이후 D'가 되어야 하는데, C'가 되면 안된다는 것이다.

고립성(Isolation) : 트랜잭션이 병행수행되는 다른 트랜잭션으로부터 영향을 받아서는 안됨.

트랜잭션이 수행되는 동안 다른 트랜잭션이 간섭하지 않아야 한다.

지속성(Durability) : 완료된 트랜잭션의 효과가 손실되어서는 안됨.

본론적으로 완료된 트랜잭션의 효과가 지속될 수 있도록 해야한다. 어떠한 경우라도, 그것

을 보장해야한다.

ACID 특성을 위한 기법.

-로킹(locking) : 고립성과 일반성을 보장. (락을 거는 방법)

>> 한 트랜잭션이 어떤 항목에 로크를 설정하면, 다른 트랜잭션은 이 항목에 접근할 수 없음.

-로깅(logging) : 지속성과 원자성을 보장.

>> 데이터베이스의 변화와 각 트랜잭션의 상태를 지속적으로 기록

>> 비휘봘성 저장 매체에 기록

-트랜잭션 완료(commit)

>>트랜잭션이 완료되면 데이터베이스의 변화는 영구적으로 데이터베이스에 반영됨.

>>로그 우선 기록(Write ahead logging) : 변화가 DB에 반영되기 전에 로깅함.

데이터 베이스 시스템 공부의 개요에 대하여 알아보면 다음과 같습니다.

데이터 베이스 설계.

- 어떻게 하면 데이터 베이스를 만들수 있는지, 어떤 종류의 정보들이 데이터 베이스에 저장되어 있는가? 정보는 어떻게 구조화 되는가?

- 데이터 모델링, ER 모델, 정규화, 객체-관계형 모델.

데이터베이스 프로그래밍

- 데이터베이스에 대한 질의와 기타 다른 연산들은 어떻게 표현하는지 공부해야한다.

- 트랜잭션이나 트리거와 같은 DBMS의 다양한 기능들을 어떻게 사용하는지에 대해서도      알아야 한다.

- 관계대수, SQL, 트랜잭션 프로그래밍, 객체 지향 DB 프로그래밍

데이터베이스 시스템 구현

- (질의 처리, 트랜잭션 처리, 효율적인 접근을 위한 저장매체의 구성 등을 포함하여) DBM를 어떻게 만들 수 있을 것인가?

- 저장 관리, 질의 처리, 트랜잭션 관리에 대해서도 생각해봐야 한다.

그리고 색인의 구현을 참고로 간단하게 적고 마무리한다.

색인(index) -> 데이터의 일부로 데이터를 신속하게 찾을 수 있도록 도와주는 데이터 구조

ex) 계좌번호에 대한 잔액을 빠르게 탐색

B-tree

- 이진 탐색 트리의 일반화.

- 많은 fanout, 즉, 많은 자식 노드들

*B-tree의 높이는 이진 탐색 트리의 높이보다 낮음. 

 일반적으로 3 또는 4레벨.

- 2차 저장매체에서 데이터에 대한 가장 일반적인 색인 구조.

-> 해쉬(Hash) 테이블도 색인 구조로 사용되기도 함.

여기까지가 1장의 데이터 베이스에 관하여에 대한 정리한 내용이었습니다.

내용들을 참고한 서적은 '데이터베이스 시스템 개론'이라는 아주 유명한 서적입니다.

다음에는 2장인 E/R 관계성 데이터 모델에 대해서 포스팅 해보도록 하겠습니다.

내용이 다소 난해하고 이해하기 힘들고 정리되지 않은 점 이해 바랍니다.

제가 봐도 상당히 정리되지 않고 난해한 것 같네요..