데이터베이스 기본 정리 (1)

학교에서 배웠던 데이터베이스가 정말 쓸모없는 지식이라고 생각했지만, 이해에 많은 도움을 받아보니 이론이 생각보다 중요하구나 라는 생각을 하게 됐다.

 

기능을 배우는 것과 기능을 이해하는 것에 대해서는 차이점이 있구나 라는 생각을 하게 됐다.

 

아무튼 한 학기 동안 배웠던 것을 짧게 정리해 보겠다.

 

참고로 이번 글은 공부 후 정리해 놓은 내용으로 만든 파일으로 틀린 내용이 많을 수 있다. 

 

정보 전달이 목적이 아닌 일기장 정도라고 생각하고 쓰겠다.

---

데이터(data)란 무엇인가?

 

어느 과목을 배우느냐와 어디에 쓰이느냐에 따라 설명은 달라질 수 있으나

결국 데이터는 현실 세계로부터 관찰이나 측정으로 수집된 정보를 뜻한다고 책에 적혀있다.

 

그러면 잘못 수집된 데이터도 데이터인가?

틀린 정보는 데이터라고 부를 수 있는가? 라는 의문이 들지만 애초에 데이터 하나로는 그 값이 사실인지 아닌지 알 수도 없다.

 

데이터는 그 자체로서는 중요하지 않은 정보이다.

 

모든 데이터가 유용한 정보가 아닐 수 있고, 보통 정제 과정을 거쳐서 두 개 이상의 데이터의 관계를 생성했을 때 데이터가 뜻하는 바를 설명해 줄 수 있다. (아닐 수도 있다)

 

25세

홍길동

남성

 

위 3개의 데이터가 객관적으로 하나씩만 보면 어떤 의미가 있어 보이는가?

 

심지어 설문조사가 귀찮았던 홍길동이 막 썼다고 생각해 보자.

 

4. 좋아하는 취미를 적어주세요 라는 질문에 홍길동이

몰라요

 

라고 적었다면?

 

이 데이터는 데이터로서의 가치도 없고 관계를 생성시키면 그 조합된 정보를 오염시킬 뿐이다.

 

가치 있는 데이터 3개를 묶어서

홍길동

25세

남성

 

이렇게 표현하면 우리는 25세인 홍길동은 남자구나! 라는 정보를 알 수 있으며,

 

이 정보는 어떠한 의사결정에 도움을 줄 수 있게 된다.

 

데이터를 가공하여 유용한 형태로 만들었을 때 그 결과를 우리는 정보(Information)라고 한다.

---

무슨 빅데이터 공부도 아니고 서론이 너무 길었다.

 

하지만 교수님이 여기서 설명하셨던 것은 첫 장에서만 2주 내내 수업하셨다.

 

관계형, 비관계형, 왜 DB가 필요한지, 어째서 이런 식으로 발전하게 되었는지를 설명하셨는데,

 

정리하기는 애매해서 넘어가겠다.

---

메타데이터(Metadata)에 대하여 알아보자.

 

메타데이터는 데이터에 대한 데이터를 의미한다.

 

보통 그게 필요한가? 라고 생각하지만, 우리 주변에는 수많은 메타데이터가 있다.

 

폴더를 열 때 폴더 안에 폴더가 수십 개가 있다면 사람은 그것을 어떻게 구별할까?

 

당연히 폴더 이름을 보고 결정한다.

 

우리는 파일을 열기 전에 어떤 파일인지, 뭐로 실행 가능한지, 용량은 어떻게 되는지, 생성자, 관리자는 누구인지 파일 탐색기를 통해 알 수 있다.

 

그리고 파일을 실행할 때 어떻게 실행하는가? 

 

컴퓨터는 파일을 실행할 때 그 프로그램의 파일 형식에 대한 메타데이터를 통해 실행할 수 있는 프로그램을 알아낸다.

 

만약 컴퓨터를 위한 메타데이터가 없었다면, 사람이 어떤 방식으로 실행시켜야 하는지 커널에게 직접 지시해야 했을 것이다.

 

이렇게 메타데이터란 데이터의 구조나, 제약사항. 속성, 특성을 기술하는 사람과, 컴퓨터에 모두 필요한 데이터인 것이다.

 

굉장히 메타데이터에 대해서 좁은 범위로 말했지만, 가장 광범위하게 말하자면 데이터를 위한 데이터라는 표현만큼

 

메타데이터를 잘 설명하는 표현은 없다.

---

데이터베이스를 교수님께서는 이렇게 정의하셨다.

 

특정 조직 내에서 다수의 사용자가 공유할 수 있도록 통합시키고 컴퓨터 저장 장치에 저장시킨 운영 데이터의 집합.

 

MSG를 뿌리자면 데이터베이스란 다수의 사용자(process)가 사용 가능하며 한 곳에 모아져서 중복되는 데이터를 줄이고,

 

조직에 필요한 정보로 정제하여, 저장하는 데이터 정도로 생각한다.

 

이런 데이터베이스는 몇 가지 특성이 있는데

1. 실시간 접근 (Real-time accessibility)

실시간 처리로 응답이 가능해야 함

 

2. 계속적인 변화 (Continuous Evolution)

데이터의 insert, drop, update 등으로 변화하는 데이터에서 올바른 데이터를 유지해야 함

 

3. 동시 공유(Concurrent Sharing) 가능

여러 사용자가 동시에 사용해도 데이터에 접근이 가능해야 한다.

 

4. 내용에 의한 참조 (Content Refernence)

위치나 주소로 파일을 찾는 것이 아닌, 사용자가 요구하는 내용(정보)으로 값을 찾아야 한다.

---

우리는 보통 파일 탐색기로 원하는 파일을 찾는다.

 

데이터베이스와 파일 탐색기는 무엇이 다를까?

 

파일 관리 시스템이라고 불리는 파일 탐색기는 파일을 생성, 검색, 조작할 수 있는 시스템을 뜻한다.

 

파일 관리 시스템은 사용에 편리하나, 데이터의 중복, 올바르지 않은 데이터, 형식이 다른 파일의 집합 등 정제되지 않은 정보들이 있다.

 

데이터베이스는 파일 시스템의 단점을 개선한 시스템으로 데이터 중복을 최소화하고, 데이터 불일치를 피할 수 있으며, 

 

물리적으로 접근하기 힘든 서버의 특징상 보안성도 제공된다.

 

추가 비용이 드는 어쩔 수 없는 점이 있긴 하다.

---

데이터베이스는 관점에 따라 3개의 계층으로 분리가 가능하다.

 

1. 외부단계 (External level) : 외부스키마 혹은 서브 스키마라고 불린다.

2. 개념단계 (Conceptual level) : 개념스키마 혹은 스키마라고 부른다.

3. 내부단계 (Internal level) : 내부 스키마라고 부른다.

 

설명에 편하게 스키마부터 설명하겠다.

 

스키마란 데이터베이스에 저장되는 데이터의 구조 및 유형을 정의하는 것으로, 데이터베이스의 전체적인 정의를 뜻한다.

 

자세히 말하자면 스키마란 데이터베이스에 어떤 테이블, 어떤 속성, 어떤 데이터 타입으로 이루어져 있는지에 대한 정보이다. (설계도)

 

그 설계도를 따라서 값을 저장하면 그 정보의 일부를 인스턴스라고 한다.

 

스키마는 정적으로 쉽게 변하지 않지만, 인스턴스는 동적으로 데이터의 추가, 수정, 삭제에 의해서 변한다.

---

layer 구조에서 하위구조가 상위구조의 존립의 영역에 있다면 보통 상위구조가 하위구조에 서비스를 받아

각각의 layer가 다른 단계에 대해서 알지 못해도 되며 다른 계층에 영향을 미치지 않는 구조를 가진다.

 

DB의 데이터 독립성도 유사하다.

 

하위 단계의 내용을 추상화 시켜버리면 상위 단계에서는 사용에 관점에서 자세히 볼 수 있기 때문이다.

 

데이터 독립성은 물리적 데이터 독립성과 논리적 데이터 독립성이 있다.

 

물리적 데이터 독립성은 내부단계의 스키마가 변경되어도 외부단계와 개념단계의 스키마에는 영향이 미치지 않도록 지원하는 것이다.

 

내부단계를 자세하게 설명하자면 데이터가 실제로 어떤 방식으로 저장되는지를 정의하는 부분이다.

 

파일구조, 압축 방식, 물리적 저장 방식이 있고, 파일의 저장위치가 바뀐다고 해도 논리적인 구조가 바뀌는 게 아니므로 

다른 단계에는 영향이 미쳐서는 안 되는 것이다.

 

데이터베이스 상에서 자동으로 관리하는 부분이므로, 사람이 저장 방식을 바꾸거나, 위치를 바꾼다 해도, 이후 정해진 

알맞은 설정을 한다면 영향을 받지 않으며, 그로 인하여 사용자는 데이터를 논리적으로 다루는 것에 집중하면 된다.

 

그럼 논리적 데이터 독립성이란? 

 

개념단계의 스키마가 변경돼도 최상위 단계인 외부단계의 스키마에는 영향을 미치지 않도록 지원하는 것이다.

 

이 말을 이해하려면 DB 관리자와 DB이용자의 데이터를 볼 수 있는 권한이 다르다는 것을 알아야 한다.

 

DB관리자는 모든 데이터를 조회할 수 있으나, 누구나 데이터를 모두 조회할 수 있다면 그것은 심각한 보안 문제이다.

 

그러므로 이용자의 권한에 맞는 테이블을 만들어 제공하는데, 그것을 외부 스키마라고 볼 수 있다.

 

하지만 개념 스키마가 변경되었을 때 외부 스키마가 영향을 받지 않을까?

 

외부 스키마에 있는 속성을 개념 스키마에서 삭제한다면?

 

개념스키마는 따로 저장한 것이 아닌 참조의 값이다. (DB는 데이터의 중복을 최소화해야 하기 때문이다)

 

보통 그런 경우에 DBMS 시스템 선에서 막지만, 삭제 가능 옵션을 넣어놓으면 제거가 가능하다.

 

물리적 데이터 독립성은 DBMS의 내부적인 최적화에도 불구하고 개념 스키마에 영향을 주지 않기 때문에 비교적 안정적이다.

 

하지만 논리적 데이터 독립성은 개념 스키마가 변경될 때 외부 스키마가 영향을 받을 수 있기 때문에, 설계 실수로 인해 언제든지 깨질 가능성이 있다.

(라고 하셨다)

---

데이터베이스를 다시 말해보자면

 

특정 조직 내에서 다수의 사용자들이 공유할 수 있도록 통합시키고 컴퓨터 저장 장치에 저장시킨 운영 데이터의 집합이다.

 

데이터베이스 관리 시스템(DBMS) 데이터베이스를 통하여 데이터를 저장하고 관리하기 위한 목적으로 사용되는 시스템

(Database Management System)

 

DBMS가 관리하는 데이터의 집합을 데이터베이스라고 한다.

 

데이터베이스에 데이터를 저장하고, 저장된 데이터를 관리하여 조직에 필요한 정보를 생성해 주는 시스템을  합하여DBS(Datebase System) 라고 한다.

 

---

데이터베이스의 사용자를 구분해 보자

 

1. DBA(Database Administrator) : 직역하면 데이터베이스 관리자로 데이터베이스 시스템을 운영, 관리하는 관리자이다.

사용의 목적보다는 조직에 사용자를 위해 데이터베이스를 설계, 구축하는 인원으로 DDL과 DCL을 사용하여 데이터베이스를 관리한다. (바로 다음에 설명하니, 굳이 찾아보지 말자)

 

하는 업무는 스키마 정의, 저장구조, 접근, 보안 정책 결정을 주로 한다.

 

(데이터베이스 설계자)

 

2. 응용 프로그래머

3. 최종 사용자

.

.

..등 사용의 입장에서 본다면 무수히 많은 사용자가 나올 수 있다.

 

이 인원들은 보통 DML을 사용하여 정해진 스키마에 데이터를 삽입하거나 삭제, 조회, 업데이트 등 필요한 작업을 한다.

---

데이터베이스 언어에 대해서 알아보자

 

1. 데이터 정의어 (DDL : Data Definition Language)

2. 데이터 조작어 (DML : Data Manapulation Language)

3. 데이터 제어어 (DDL : Data Control Language)

로 나눌 수 있다.

 

우선 DDL은 데이터베이스의 스키마 정의, 혹은 수정할 목적으로 사용한다.

 

DBA나 DB 설계자가 주로 사용하며 테이블 생성, 삭제, 수정 등이 가능하며, 인덱스 생성, View 생성 등이 기능에 있다.

 

다음으로 DML은 학원에서 사실상 배우는 목적이기도 한데 

말 그대로 데이터를 조작하기 위해 사용된다. 

 

DDL으로 생성된 스키마에 DML을 사용해 데이터를 사용하여 삽입, 삭제, 수정 하는 것이다.

 

절차적과 비절차적은 다음에 짧게 기술하겠다.

 

마지막 DCL은 데이터 제어어로 사용자 권한을 부여, 회수할 수 있고 트랜잭션을 잡아둘 수 있다.

 

트랜잭션은 학원 교재에서 너무 난해하게 나와서 이게 뭔가 했더니, 그냥 리눅스에서 배웠던 & 을 조금만 바꾸면 된다.

 

리눅스에서 여러 개의 명령(쿼리문)을 한 줄[(한 트랜잭션)에 실행하고 모두 성공해야

실제 작업이 반영되고 만약 하나라도 실행에 실패했다면 그러면 전체를 취소할 수 있어야 한다는 개념이다.

 

트랜잭션의 작업은 전부 성공 OR 취소여야 하고

이 트랜잭션의 작업을 수행해도 데이터베이스가 기본기, 외래키, Null 등의 제약이 변하지 않고 데이터의 연산 결과가 논리적으로 달라지지 않았어야 한다. (계좌이체 했으면 은행과 내 돈의 변화의 합은 0원이여야 한다)

 

여러 트랜잭션이 함께 실행돼도 서로 영향을 주지 않도록 설계돼야 하고 트랜잭션이 완료되면 결과가 데이터베이스에 

영구히 저장돼야 한다.

 

이걸 ACID 원칙이라고 한다. 

 

데이터의 거래를 의미한다는 뜻을 상상하면 편하다.

나 홀로 집에 영화에서 피자를 시키는 트랜잭션을 생각해 보자

1. 피자를 시켰다.

2. 피자가게에서 피자를 만든다.

3. 배달부가 집 앞까지 온다.

3. 피자를 받는다.

4. 배달부에게 돈과 팁을 준다(?)

 

이 거래에서 만약 피자가 오지 않았는데 돈을 줄 수는 없으니 주문 자체를 처음으로 되돌려야 한다. 

피자 배달부에게 제공한 돈과 피자의 가치는 같을 것이다.

피자 가게에서 전화가 많이 온다 해도 피자를 만드는 데는 실수하면 안 된다.

주문이 완료됐을 땐 피자 가계의 계산서나 리스트에는 기록이 남을 것이다.

---

오늘은 테이블까지만 하고 다음 주 주말에 이어서 포스팅하겠다.

아주 끔찍하지만 일단 보자.

 

id, name, age, address들을 필드명, 혹은 속성이라고 부른다.

 

그리고 한 사람의 속성값들을(한 행) 레코드, 튜플, row, 행으로 부른다.

 

그 한 사람의 데이터는 동적으로 변할 수 있는 인스턴스라고 부른다.

 

이 레코드의 합을 카디널리티라고 부르는데 본 사진에서는 10에 해당한다.

 

행의 합을 합친 개념이 있다면 필드명의 이름을 합친 개념도 당연히 있다.

 

그 값을 릴레이션 차수라고 부른다.

 

도메인이란 특정 필드가 가질 수 있는 값들의 집합을 뜻한다.

 

보통 정수, 문자, 날짜 정도가 있지만 엄격한 도메인 설정으로 하면 학과명에 원하는 학과만 들어가게 설정하여 

다른 값들을 넣지 못하게 하는 경우가 그렇다.

 

이 테이블 자체를 테이블이라고 부르기도 하지만 릴레이션이라고 부르기도 한다.

 

DB기술은 특히 불리는 이름이 제멋대로인 것 같다.

 

메타데이터를 데이터 딕셔너리라고 부르지 않나 시스템 카탈로그라고 부르지 않나 너무 다양하다.

 

다음 주에는 릴레이션 구성, 특성, 속성(단순, 복합, NULL, 유도)과 도메인, Key의 종류, 질의어, 관계대수 연산자. 

실제 DDL, DML, DCL의 사용 방법을 알아볼 텐데 또 하루 안에 할 수 있을지는 모르겠다. 

 

3주에 걸쳐서 하면 학원 진도에 늦춰질 텐데 만약 다음 주 안에 데이터베이스가 끝난다면, 다음 주는 토, 일 전부 할 수도 있을 것 같다.