- DB, DBMS, DMS의 차이
- 스키마와 테이블의 차이
- 3단계 데이터베이스 구조
- 3단계 데이터베이스로 구조를 나누는 이유
- 데이터 사전과 데이터 디렉토리는 사용자가 접근 가능한가?
- 데이터 언어의 종류와 예시 SQL 명령어
데이터베이스 시스템의 정의
데이터베이스(DB), 데이터베이스 관리 시스템(DBMS), 데이터베이스 시스템(DBS)의 차이를 알고 있는가?
- 데이터베이스(DB): 데이터를 저장하는 공간
- 데이터베이스 관리 시스템(DBMS): 데이터베이스를 관리하는 소프트웨어
- 데이터베이스 시스템(DBS): DB와 DBMS를 포함하는 상위 개념
데이터베이스의 구조
DB를 공부하다보면 스키마란 용어를 굉장히 많이 보게 된다. DB 입문자들은 '스키마'가 테이블(table)와 비슷하단 말을 자주 듣는다. 정말 똑같은 용어일까?
결론부터 말하자면, 스키마와 테이블은 데이터베이스 구조를 구성하는 주요 요소이며, 서로 밀접한 관계를 가지만 엄연히 다른 개념이다. (물론 DBMS 마다 정의가 조금씩 다르다)
스키마란?
데이터베이스에 저장되는 데이터 구조와 제약조건을 정의한 것
스키마는 데이터베이스의 전체 구조를 정의하는 개념이다.
데이터베이스 내에 있는 테이블, 뷰(View), 인덱스(index) 등의 데이터 구조 요소들을 정의하고 구성하는데 사용되며, 데이터베이스에 저장되는 데이터의 형식, 구조, 관계 등을 결정한다. 또한 데이터베이스에서 데이터 무결성, 보안 등을 관리하는 데에도 사용된다.
위 예시에서 보면 고객과 관련된 데이터인 고객번호, 이름, 나이, 주소를 저장한다고 할 때, 고객번호는 정수로, 이름은 최대 10자의 문자열로, 나이는 정수로, 주소는 최대 20자의 문자열로 허용하기로 한다. 이 정해진 모든 내용을 스키마라고 부른다. 그리고 정의된 스키마에 따라 데이터베이스에 실제 저장된 값을 인스턴스(instance)라고 한다.
스키마와 테이블의 차이
스키마는 데이터베이스의 전체 구조와 제약조건을 정의하는 개념이고,
테이블은 데이터를 저장하는 가장 기본적인 데이터 구조를 의미한다.
각 테이블은 여러 개의 열(Column)과 행(Row)으로 구성되며, 각 열은 해당 데이터의 속성을 나타내고, 각 행은 테이블에 저장된 실제 데이터를 나타낸다. 즉 테이블은 스키마 내에서 실제 데이터를 저장하는 기본적인 구조이다.
- 스키마는 테이블을 포함 : 각각의 테이블은 스키마 내에서 정의되며, 스키마 내에서 존재함
- 스키마는 각 테이블의 구조 정의 : 테이블의 열 이름, 데이터 타입, 제약 조건 등을 스키마에서 정의한 대로 결정됨
- 스키마는 데이터의 무결성과 보안을 관리 : 스키마에서 정의된 제약 조건에 따라 테이블의 데이터 무결성이 보장됨
- 스키마 변경 시 스키마 내의 모든 테이블이 변경됨 : 각 테이블의 구조에 영향을 미치기 때문
3단계 데이터베이스 구조
하나의 데이터베이스를 세 단계로 나누어 이해하는 모델이다.
- 외부 단계(external level): 개별 사용자 관점
- 개념 단계(conceptual level): 조직 전체의 관점에서 바라보는 단계
- 내부 단계(internal level): 물리적인 저장 장치의 관점에서 바라보는 단계
외부 단계 (외부 스키마)
개별 사용자 관점에서 데이터베이스를 이해하고 표현한다.
하나의 데이터베이스에는 정말 많은 데이터가 저장되고 관리된다. 하지만 데이터베이스 사용자가 모든 데이터를 사용하는 건 아니다. 회사에서 각 부서마다, 관리자마다 관심이 있는 데이터가 따로 있다. 고객센터에선 고객의 이름, 연락처 등이 필요할 것이고, 제품 생산 부서에선 제품과 관련된 데이터가 필요할 것이다. 영업부에서 인사팀이 취급하는 데이터는 필요하지 않을뿐더러 오히려 분쟁이 발생할 수 있다.
즉 개별 사용자마다 데이터베이스를 바라보는 관점과 구조가 다를 수밖에 없다. 그래서 각 사용자에게 필요한 데이터베이스를 정의한 것을 외부 스키마(external schema)라고 한다. 외부 스키마는 각 사용자가 생각하는 데이터베이스의 모습을 표현한 논리적인 구조로, 사용자마다 다르다.
하나의 데이터베이스에는 외부 스키마가 여러 개 존재할 수 있고, 외부 스키마 하나를 사용 목적이 같은 사용자들이 공유할 수도 있다.
예를 들어 고객 관리 시스템에서는 고객 정보, 주문 정보, 결제 정보 등이 각각의 외부 스키마로 정의될 수 있다.
개념 단계 (개념 스키마)
조직 전체의 관점에서 데이터베이스의 논리적 구조를 이해하고 표현한다.
데이터베이스를 이용하는 사용자들의 관점을 통합하여, 데이터베이스를 조직 전체의 관점에서 정의한다. DBMS나 DBA(Database Administrator)는 데이터베이스의 일부분이 아닌 전체에 관심을 둔다. 개념 단계에서는 이러한 관점에서 모든 사용자에게 필요한 데이터를 통합하여 전체 데이터베이스의 논리적 구조를 정의한다. 이를 개념 스키마(conceptual shcema)라고 한다.
개념 스키마는 모든 개별 사용자가 생각하는 데이터베이스의 모습을 하나로 합친 형태다. 따라서 전체 데이터베이스에 어떤 데이터가 저장되는지, 데이터들 간에 어떤 관계가 존재하고 있는지, 어떤 제약조건이 있는지에 대한 정의뿐만 아니라, 데이터에 대한 보안 정책, 접근 권한에 대한 정의도 포함한다.
하나의 데이터베이스에는 하나의 개념 스키마가 존재한다. 그리고 각 사용자는 개념 스키마의 일부분을 사용한다. 즉, 외부 스키마는 개념 스키마를 기초로 사용자의 이용 목적에 맞게 만들어지는 것이다.
일반적으로 스키마라고 하면 개념 스키마를 지칭한다.
내부 단계 (내부 스키마)
데이터베이스를 디스크나 테이프 같은 저장 장치의 관점에서 이해하고 표현한다.
전체 데이터베이스가 저장 장치에 실제로 저장되는 방법을 정의한다. 데이터베이스는 파일 형태로 저장되는데, 내부 스키마는 파일에 데이터를 저장하는 레코드의 구조, 레코드를 구성하는 필드 크기, 인덱스를 이용한 레코드 접근 경로 등을 정의한다. 이를 내부 스키마(internal schema)라고 한다.
3단계로 데이터베이스를 나누는 이유?
각 단계별로 다른 추상화를 제공하면 데이터베이스를 효과적으로 관리할 수 있기 때문이다.
내부 단계에서 외부 단계로 갈수록 추상화 레벨이 높아지는데,
이를 통해서 모든 데이터의 저장 및 유지와 관련된 복잡한 내용을 숨기고,
필요한 데이터만 단순화한 외부 단계의 관점을 일반 사용자들에게 제공할 수 있다.
쉽게 이야기해서 당사자의 관심 밖의 것에는 신경쓰지 않고 데이터 관리를 용이하기 만들 수 있기 때문이다.
아파트를 예시로 들어보자.
개별 세입자는 본인의 집에만 관심을 두면 된다. 반면 관리인의 관점에선 개별 세대뿐만 아니라 건물 전체의 컨디션에 신경을 써야 한다. 건설 업체는 건물의 골격, 하수관 등 내부적인 하자 여부에 집중해야 한다.
만약 계층을 나누지 않는다면 301호에 사는 명석이네가 아파트 시멘트 양과 철골의 원산지까지 모두 신경을 써야하는 불상사가 일어난다. 또는 아파트 시공 업체가 102호 유선이네 강아지가 병원에 입원했던 것까지 관심을 가져야 한다면 얼마나 비효율적이겠는가.
아파트를 바라 볼 때도 모두 관심사가 다르듯, 데이터베이스 설계에도 각 계층마다 목적과 역할이 다르기 때문에 3단계로 나누면 데이터의 구성과 관리에 용이해진다.
또 다른 이유도 있다. 그건 계층간의 데이터 독립성을 지키기 위해서이다.
데이터 독립성
하나의 데이터베이스에는 세 가지 유형의 스키마가 존재하지만, 각각의 스키마는 데이터베이스를 바라보는 관점이 다를 뿐, 결국 모두 같은 데이터베이스를 표현한다. 그래서 사용자가 자신의 외부 스키마를 통해 원하는 데이터를 얻으려면 내부 스키마에 따라 저장된 데이터베이스에 접근해야 한다. 그러므로 세 가지 스키마 사이에는 유기적인 대응 관계가 성립해야 한다.
예를 들어 상품 배송팀의 외부 스키마에서 고객번호 데이터는 개념 스키마에 있는 번호 데이터에 대응하고, 개념 스키마의 번호 데이터는 내부 스키마에 있는 번호 필드와 대응한다. 이런 연결 관계는 미리 정의되어 있어야 사용자가 물리적 저장 장치에 저장된 고객번호 데이터에 접근할 수 있다.
스키마 사이의 대응 관계를 사상 또는 매핑(mapping)이라고 한다.
- 외부/개념 사상 : 외부 스키마와 개념 스키마의 대응 관계
- 개념/내부 사상 : 개념 스키마와 내부 스키마의 대응 관계
DBMS는 미리 정의된 외부/개념 사상과 개념/내부 사상 정보를 이용하여 사용자가 원하는 데이터에 접근할 수 있다.
이렇게 대응 관계를 정의한 궁극적인 목표는 결국 데이터 독립성을 실현하기 위해서이다. 데이터 독립성이란 하위 스키마를 변경하더라도 상위 스키마가 영향을 받지 않는 특성을 말한다. 그래서 3단계 데이터베이스 구조에는 논리적 데이터 독립성과 물리적 데이터 독립성이 존재한다.
논리적 데이터 독립성
개념 스키마가 변경되더라도 외부 스키마가 영향을 받지 않는다.
그래서 전체 데이터베이스의 논리적인 구조가 변경되어도 관련된 외부/개념 사상만 수정해주면 직접 관련이 없는 사용자를 위한 외부 스키마는 변경할 필요가 없다.
예를 들어 개념 스키마의 연락처 데이터의 이름을 전화번호로 바뀐다고 해서 외부 스키마에 있는 연락처 데이터의 이름을 수정할 필요가 없다. 왜냐하면 외부/개념 사상 정보만 수정해주면 서로 연결되어 있음을 알 수 있기 때문이다. 따라서 개념 스키마에 새로운 내용이 추가되거나 기존 내용이 삭제되는 경우에도 외부 스키마는 영향을 받지 않는다.
물리적 데이터 독립성
내부 스키마가 변경되더라도 개념 스키마가 영향을 받지 않는다. 결과적으로 외부 스키마도 영향을 받지 않는다.
개념/내부 사상 정보만 적절히 수정해주면 직접적으로 관련이 없는 데이터베이스의 논리적 구조는 영향을 받지 않는다. 따라서 내부 스키마에 새로운 인덱스가 추가되거나 기존 인덱스가 삭제되는 경우에도 개념 스키마는 영향을 받지 않는다.
데이터 사전
데이터 독립성을 실현하면서 다양한 관점으로 정의되는 세 가지 스키마 정보와, 스키마 간의 사상 정보는 도대체 어디에 저장되는 것일까?
데이터베이스에 저장되는 데이터에 관한 정보를 저장하는 곳을 데이터 사전(data dictionary) 또는 시스템 카탈로그(system catalog)라고 한다. 데이터 사전은 데이터베이스가 저장되어 있는 데이터를 정확하고 효율적으로 이용하기 위해 참고해야 하는 스키마, 사상 정보, 다양한 제약조건 등을 저장한다.
데이터 사전은 데이터베이스 관리 시스템이 스스로 생성하고 유지한다. 그래서 데이터베이스 관리 시스템이 주로 접근하지만 일반 사용자도 접근할 수 있다. 물론 사용자는 저장 내용을 검색만 할 수 있다.
데이터 사전에 있는 데이터에 실제로 접근하는데 필요한 위치 정보는 데이터 디렉토리(data directory)라는 곳에서 관리한다. 여기엔 사용자가 접근할 수 없고 오로지 시스템만 들어갈 수 있다.
데이터 언어
데이터 관리 시스템과 의사소통 하는 언어는 총 3가지가 있다.
하지만 사용 목적에 따라 내부적으로 구분하는 것일 뿐 독립적으로 존재하는 언어들이 아니다.
데이터 정의어 (DDL : Data Definition Language)
데이터베이스 구조와 스키마를 정의 또는 수정하는데 사용한다.
새로 만들려는 데이터베이스의 스키마를 설명하거나 이미 정의된 스키마의 구조, 제약조건 등을 변경 또는 삭제하고 싶어 데이터베이스 관리 시스템에 알릴 때 사용한다.
데이터 정의어로 정의된 스키마나 수정 내용은 데이터 사전에 저장 및 반영된다. 그래야 사용자나 데이터베이스 관리 시스템이 필요할 때 데이터 사전에 저장된 스키마 정보를 참고할 수 있기 때문이다.
- CREATE : 새로운 데이터베이스 객체(테이블, 뷰, 인덱스 등)를 생성
- ALTER : 이미 존재하는 데이터베이스 객체를 수정
- DROP : 데이터베이스 객체를 삭제
데이터 조작어 (DML : Data Manipulation Language)
데이터베이스에 저장된 데이터를 조회, 삽입, 수정, 삭제하는 데 사용한다.
사용자가 실제 데이터 값을 활용하기 위해 사용하는 명령어로 설명 방식에 따라 두 종류로 나뉜다.
- 절차적 데이터 조작어
: 사용자가 어떤(what) 데이터를 원하고 해당 데이터를 얻으려면 어떻게(how) 처리해야 하는지까지 구체적으로 설명한다.
- 비절차적 데이터 조작어 (= 선언적 언어)
: 사용자가 어떤(what) 데이터를 원하는지만 설명한다. 해당 데이터를 얻으려면 어떻게 처리해야 하는지는 관심이 없다. 비절차적 데이터 조작어는 사용자가 어떤 데이터를 원하는지만 데이터베이스 관리 시스템에게 선언하는 방식이기 때문에 선언적 언어(declarative language)라고도 한다.
- SELECT : 데이터를 조회
- INSERT : 데이터를 삽입
- UPDATE : 저장된 데이터를 수정
- DELETE : 저장된 데이터를 삭제
데이터 제어어 (DCL : Data Control Language)
데이터베이스 사용자와 권한을 관리하는데 사용한다.
사용자가 데이터베이스를 올바르게 관리하기 위해 필요한 규칙과 기법을 DCL을 이용해 데이터베이스 관리 시스템에 설명하면, 시스템은 이 규칙과 기법에 따라 데이터베이스를 제어하고 보호한다.
사용자는 데이터 제어어를 통해 다음과 같은 특성을 보장받을 수 있다.
- 무결성 : 데이터베이스에 정확하고 유효한 데이터만 유지
- 보안 : 허가받지 않는 사용자가 데이터에 접근하는 것을 차단
- 회복 : 장애가 발생해도 데이터의 일관성 유지
- 동시성 : 여러 사용자가 같은 데이터에 동시 접근 가능하도록 처리
- GRANT : 데이터베이스 객체에 대한 권한 부여
- REVOKE : 데이터베이스 객체에 대한 권한 회수
데이터베이스 관리 시스템의 구성
데이터베이스 관리 시스템에 대한 이야기가 앞서 계속 언급됐다. 데이터베이스 관리 시스템은 사용자와 데이터베이스 사이에 위치하며, 기능에 따라 질의 처리기와 저장 데이터 관리자로 구분할 수 있다.
질의 처리기 (query processor)
사용자의 데이터 처리 요구를 해석하여 처리하는 역할을 담당한다.
- DDL 컴파일러 : 데이터 정의어로 작성된 스키마의 정의를 해석하고, 저장 데이터 관리자의 도움을 받아 새로운 데이터베이스를 구축한다. 스키마 정의는 데이터 사전에 저장한다.
- DML 컴파일러 : 데이터 조작어로 작성된 데이터의 처리(삽입, 삭제, 수정, 조회) 요구를 분석하여 런타임 데이터베이스 처리기가 이해할 수 있도록 해석한다.
- DML 프리 컴파일러 : 응용 프로그램에 삽입된 데이터 조작어를 추출하여 DML 컴파일러에 전달한다.
- 런타임 데이터베이스 처리기 : 저장 데이터 관리자를 통해 데이터베이스에 접근하여, DML 컴파일러로부터 전달받은 데이터 처리 요구를 데이터베이스에서 실제로 실행한다.
- 트랜잭션 관리자 : 데이터베이스에 접근하는 과정에서 사용자의 접근 권한이 유효한지 검사하고, 데이터베이스 무결성을 유지하기 위한 제약조건 위반 여부를 확인한다.
저장 데이터 관리자 (stored data manager)
디스크에 저장된 데이터베이스와 데이터 사전을 관리하고, 실제 접근하는 역할을 담당한다. 그런데 디스크에 저장된 데이터에 접근하는 것은 운영체제의 기본 기능이므로 저장 데이터 관리자는 운영체제의 도움을 받아 데이터베이스에 대한 접근을 수행한다.
'데이터 베이스' 카테고리의 다른 글
| Ch.5 관계 데이터 모델 [데이터베이스 개론] (0) | 2023.04.25 |
|---|---|
| Ch.4 데이터 모델링 [데이터베이스 개론 도서] (1) | 2023.04.21 |
| [MySQL] 데이터베이스, 테이블, 열 정보를 찾는 쿼리문 (0) | 2022.10.29 |
| [MySQL] '조인 연산자'와 '집합 연산자'의 차이 (0) | 2022.10.03 |
| [MySQL] 두 날짜의 차이를 구하라 (feat. DATEDIFF, TIMESTAMPDIFF) (0) | 2022.09.27 |
