데이터베이스 개요.

Database [from Pixabay]

1. 정의 및 필요성.

1.1 정의.

데이터베이스는 여러 응용 시스템들의 통합된 정보들을 저장하여 운영할 수 있는 공용 데이터들을 구조화 해놓은 집합체이다. 같은 데이터가 서로 다른 목적을 가진 여러 응용에 중복되어 사용될 수 있다는 것이다.

예) 3가지의 서로 다른 업무처리 시스템.

위의 그림을 보면 3가지의 각기 다른 파일로부터 강의 시간표, 출결 현황, 장학금 현황에 대한 정보를 얻어 타겟파일들을 생성하고 있다.

이때 데이터베이스가 있다면 학생, 출결, 성적 파일을 통합해서 관리하고, 각각의 시스템이 접근하여 정보처리를 하게 해준다.

1.2 필요성.

'데이터베이스가 왜 필요한가?'라고 묻는다면 여러 이유가 있지만, 가장 큰 이유로는 상이한 시스템에서 데이터를 공용하여 사용하기 위해 필요하다고 할 수 있다.

이때  '그냥 파일로 저장해놓고 공용하면 되는거 아냐?'라는 의문이 떠오른다.

수많은 시스템이나 응용 프로그램이 사용할 수 있는 데이터를 저장하는 표준 파일 포맷을 만들어서(예. HTML, PDF) 그에 맞게 데이터를 처리하면 된다는 것이다.

이 물음에 대답하기 위해 위의 학생, 출결, 성적파일에 있을만한 데이터의 종류를 봐보자.

학생 파일	출결 파일	성적 파일
이름	이름	이름
수강 강좌	수강 강좌	수강 강좌
강좌 시간	출결 여부	성적

이름과 수강 강좌가 겹쳐있다는 것을 알 수 있다.

파일 내부에 데이터를 체계적으로 잘 입력해놨다면 상당히 편하게 정보를 추출할 수 있을테지만 여러번 겹치게 입력을 해놨다면 검색이나 저장하는데 드는 비용등이 증가할 수 밖에 없다.

데이터베이스는 이를 통합하여 관리해 정보를 구조적, 효율적으로 저장한다.

지금까지의 내용을 살펴보면 데이터베이스도 자료구조처럼 데이터의 추상화 과정에서 나온 산물중 하나라는 사실을 눈치빠른 분들은 알아차렸을 것이다.

+.

파일 같은 경우 동시에 수정을 하려고 하는 경우에도 오류가 생길 가능성이 높다.

예) 파일 공유 충돌.

파일 공유 충돌[from Microsoft]

2. 특징.

2.1 기본특성.

내가 읽었던 책에서는 데이터베이스의 정의로부터 데이터베이스가 가지고 있는 몇가지 특성을 추론 해놓았다.

책에서의 정의: 어느 한 조직의 여러 응용 시스템들이 공용할 수 있도록 통합, 저장된 운영 데이터의 집합.

+.

저작권 때문에 소제목만 똑같이 사용하였고, 내부 내용은 요약과 저의 해석을 담았습니다.

- 통합 데이터(Integrated Data).

 여러 데이터를 통합하여 저장하는데 중복이 된다는 것은 효율이 떨어지는 것이기 때문에 데이터의 중복을 제거한다.

 하지만 효율성을 위해서 일부 데이터는 중복을 허용하기도 한다. 다만 의도적인 중복의 경우는 통제가 가능해야 한다.(효율을 위해서 중복을 허용하는 것이니까.)

의도적인 중복을 허용하는 경우는 No SQL의 모델링에서 볼 수 있다.

아직 DB 모델링은 안배워서 잘 모르니.. 링크만 걸어놓음.

NoSQL 데이타 모델링 #1-데이타모델과, 모델링 절차

NoSQL 데이터 모델링 개념

 이것을 최소의 중복(Minimal Redundacy) 또는 통제된 중복(Controlled Redundancy)라고 한다.

- 저장 데이터(Stored Data).

 데이터베이스는 냉장고, 바구니등 물리적인 데이터가 아니라 HDD나 SSD처럼 컴퓨터 저장장치에 저장하는 데이터이다.

- 운영 데이터(Operational Data).

 데이터베이스는 단순한 데이터의 집합이 아니라, 조직의 존재 목적이나 기능을 수행하는데 필요한 데이터의 집합이다. 작업을 처리하기 위해 일시적으로 생성된 임시 데이터는 운영 데이터가 아니라는 뜻이기도 하다.

- 공용 데이터(Shared Data).

데이터베이스가 필요한 가장 큰 이유이기도 하다.
하나의 프로그램이나 시스템을 위한 데이터가 아니라, 여러 시스템들이 공동으로 소유하고 유지하며 이용한다는 뜻이다. 그래서 여러 사용자가 상이한 목적으로 데이터베이스를 사용하기에 일반적으로 데이터 양이 많고 구조가 복잡해지게 된다.

여러 사람들이 공유하고 사용할 목적으로 통합 관리되는 정보의 집합이다. 논리적으로 연관된 하나 이상의 자료의 모음으로 그 내용을 고도로 구조화함으로써 검색과 갱신의 효율화를 꾀한 것이다. 즉, 몇 개의 자료 파일을 조직적으로 통합하여 자료 항목의 중복을 최대한 없애고 자료를 구조화하여 기억시켜 놓은 자료의 집합체라고 할 수 있다.

2.2 특징

- 실시간 접근성(Real-Time Accessibility).

현재 사용되고 있는 시스템들에서는 일괄 처리만 하는 경우가 드물기 때문에 임의적이고 비정형적인 쿼리(Query)에 대해 실시간으로 처리가 가능해야 된다. 일반적으로 온라인에서 처리한다고 하면 실시간 처리를 의미한다.

실시간 접근성 때문에 데이터베이스는 주로 실시간 처리를 위해 활용된다.

- 지속적인 변화(Continuous Evolution).

한 시점에서 데이터베이스가 저장하고 있는 내용은 데이터베이스의 그 당시 상태를 뜻한다. 그런데 위에서 설명한 실시간 접근성의 특징에 의해 동적인 상태를 띤다.

그런데 이런 지속적인 변화가 이어지는 상황에서도 데이터베이스는 현재의 정확한 데이터를 유지해야 되기 때문에 관리하기가 어렵다

.

- 동시 공용(Concurrent Sharing).

 서로 다른 목적을 가진 시스템들이 공용할 수 있도록 구성되어 있다.
그래서 여러 사용자가 동시에 자신이 원하는 데이터에 접근하는 것이 가능해야 하기에 하나의 응용 프로그래미 접근하는 데이터와는 당연히 다르고 여러 응용 프로그램이 같은 데이터를 직렬적으로 공용하는 개념과도 전혀 다르다.
데이터베이스의 서로 다른 부분을 여러 사용자가 동시에 사용할 수 있도록 하는 것은 관리의 측면에서도 복잡하지만, 데이터베이스를 조직하는 측면에서도 복잡하다.

-  내용에 의한 참조(Contents Reference).

 데이터베이스에서 데이터의 참조는 저정되어 있는 레코드들의 주소나 위치에 의해서가 아닌, 사용자가 요구하는 데이터의 값에 따라 참조된다.
일반적인 컴퓨터 시스템에서 데이터들이 주소로 참조하는 것과 달리(C언어 포인터나 파일 디렉토리, URL주소를 생각해보자.) 사용자가 참조하기를 원하는 데이터의 특성이나 조건을 명세하면, 조건을 만족하는 레코드들이 어디에 있는지 논리적 단위로 취급하고 접근하게 된다.

  예) 데이터 값들 안에서 100 이상의 숫자들을 찾고 싶다면, 수나 위치에 관계없이 모두 접근되고 검색된다.

- 데이터 논리적 독립성(Data logical independence).

사용하는 데이터의 저장되는구조가 바뀌더라도 응용프로그램에는 영향을 미치지 않아야 한다.

데이터에 삽입, 삭제, 정렬, 검색같은 구조적 변형, 디스크 저장위치가 바뀌는 물리적 변형이 일어나더라도 응용프로그램의 소스를 바꿀 필요가 없어야 한다는 것.

3. 데이터베이스의 구성요소 및 구조.

 계속 언급해왔듯 상이한 목적을 가지고 공용하는 데이터베이스의 구성요소는 보는 관점에 따라 다르다. 그래도 크게크게 본다면 사용자 관점의 개념적(논리적) 구성요소와 시스템 관점의 물리적 구성요소로 나뉠 수 있다.

3.1 개념적 구성요소.

사용자의 측면에서 보면 개체(Entity)와 관계(Relationship)으로 나뉠 수 있다고 한다.

3.1.1 개체(Entity)

 개체(Entity)는 데이터베이스에 표현하려고 하는 유무형의 객체(Object)로 구별되는 것이라 한다.

개체(Entity)는 사람이 생각하는 개념이나 정보의 단위로의 의미를 가지고 있으며 파일의 레코드(Recode)에 해당된다고 한다. 그 자체로서 의미를 가지고 있기 때문에 단독으로 존재가 가능하고, 정보로의 역할을 수행할 수 있다.

 하나의 개체는 하나 이상의 속성(Attribute)로 구성되고 데이터의 가장 작은 논리적 단위가 된다. 속성은 자신만으로는 의미를 표현하지 못하다는 점이 객체와의 가장 큰 차이이며 파일의 필드(Field)에 해당된다. 여기의 이름, 수강강좌~성적까지 모든 Attribute의 값들은 각각 자신만으론 정보를 이루지 못하지만 합해지면 '학생'이라는 개체(Entity)가 되어 뜻을 제공해준다.

파일 구조.

데이터베이스 개체 구조.

단위 | 시스템	파일 시스템(File System)	데이터베이스(Database)
정보의 단위	레코드(Record)	개체(Entity)
논리적 단위	필드(Field)	속성(Attribute)

+.

각 속성들이 합해진 것은 개체 타입(Entity Type이라 하며 개체들이 구체적인 값을 가지는 것을 개체 인스턴스(Entity Instance)나 개체 어커런스(Entity Occurrence)라 한다. 객체지향 프로그래밍(OOP)를 해보면 알겠지만 메소드나 변수들을 범주화 시켜서 클래스를 만들고, 사용을 할때는 실체화(Instance, 인스턴스)화를 시키게 되는 것과 비슷하다고 볼 수 있다.

이 인스턴스들의 집합은 개체 집합(Entity Set)이라 한다.

++.

파일에서 필드와 레코드에 대한 조금더 자세한 설명은 여기를 참고하면 됩니다.

3.1.2 관계(Relationship)

개체의 집합끼리는 여러 유형의 관계가 존재할 수있다.(내용에 의한 참조란 특징을 생각해보면 된다.)

개체끼리 관계를 만들어 '의미를 부여'한다는 것에서 관계(Relationship)이란 것도 개체가 되며 데이터베이스에 저장된다. 단, 관계라는 특징상 값이 눈에 보이지 않고 다소 추상적이기 때문에 위의 개체와는 별개의 요소로 판단한다.

개체의 집합에서 관계를 찾아본다면 크게 속성과 개체의 관계로 나눌 수 있다.(3.1.1 참고.) 속성은 논리적 단위이므로 속성 관계(Atrribute Relationship)도 개체의 내부에서만 존재하기에 개체 내 관계(Intra-Entity Relationship)이라 불리고, 개체는 정보의 단위이므로 개체 관계(Entity Relationship)는 개체끼리의 비교를 위해 개체 외부에 존재하기 때문에 개체 간 관계(Inter-Entity Relationship)이라 한다고 한다.

데이터베이스에서는 보통 개체 관계는 명시적으로 취급하는 반면, 속성 관계는 묵시적으로 처리한다.(속성 관계의 경우 개체란 단위로 범주화되어 처리가 가능하지만 개체끼리는 따로 관계를 짓는 것이 직접적으로 필요하기 때문.)

그럼 개체 관계를 어떻게 알아내고 왜 필요한지 알아보자.

보통은 아래처럼 E-R 다이어그램(Enity-Relationship Diagram) 형태로 만든다.

학생은 학과라는 개체와 '전공'이라는 관계를 가지고 있다.

학생에서 '김XX'(이름)란 학생의 수강강좌와 강좌시간을 알려주라는 질의(Query)를 보내면, 학생 개체에서 이름과 수강강좌, 시간의 관계를 추적하여 결과를 알려줄 수 있다. 묵시적으로 처리가 된다는 것이다.

그러나 '김XX'의 자료구조란 과목의 해당 학과사무실가 무엇인지 알고 싶다면, 전공이란 관계를 통해서 학과에 접근해야 한다. 관계가 명시적으로 필요하다는 것을 알 수 있다.

이렇듯 개념적으로 볼 때 데이터베이스는 개체와 관계로 이루어졌다고 볼 수 있다.

3.2 데이터베이스 구조(Database Structure).

 데이터베이스는 앞서 이야기 한것처럼 개념적으로 볼때는 개체와 관계로 이루어져 있다. 하지만 실제로 데이터베이스는 개체와 관계의 값들(Occurrence)로 구성되어 있다.  이러한 값들은 어떻게 되었든, 물리적인 저장장치에 저장된다.(SSD나 HDD, 자기테이프..)

그런데 이 저장 구조를 장치의 입장과 사용자의 입장에서 볼 수 있으며 각각 물리적 구조와 논리적 구조로 구별 할 수 있다.

3.2.1 물리적 구조(Physical Structure).

 물리적 구조는 저장장치(SSD, HDD, 자기테이프)의 입장에서 바라본 것으로 물리적인 저장장치에 물리적으로 저장되어 있는 데이터의 실제 구조이다.  실제 구조이기 때문에 저장 데이터의 물리적 배치를 표현했다고 볼 수 있다. 데이터베이스의 물리적 구조에서 취급하는 데이터 레코드들은 저장 레코드(Stored Record)라 한다.

추후으로 HDD와 SSD의 구조와 함께 설명하도록 하겠습니다.

3.2.2 논리적 구조(Logical Structure).

논리적 구조는 사용자(일반 사용자, 응용 프로그래머)의 입장으로 바라본 것으로 데이터의 논리적 표현이다. 논리적 표현이기 때문에 데이터가 배치되어 있다고 가정하는 가상적인 구조라고 볼 수 있다. 데이터베이스의 논리적 구조에서 취급하는 데이터 레코드들은 논리적 레코드(Logical Record)라고 한다. 일반적인 응용 프로그램은 당연하지만 일부만 접근해서 사용한다.

물리적인 구조를 단순화한 것이기 때문에 논리적 구조와 물리적 구조가 매우 다를 수 있다.

이처럼 데이터베이스를 표현하는 구조(물리적, 논리적)끼리는 서로 대응관계(매칭)되어야 하며 그래야 동등성을 유지할 수 있다.

참조. 데이타베이스론(이석호, 정익사), 위키백과. DB-Engines

(데이터베이스 카테고리에서 앞으로도 별 말이 없으면 위의 출처를 따릅니다.)

끝~~~