프로그래민 ‍

[Kafka] 카프카 커넥트의 개념 및 특징

프로그래민 — Mon, 23 May 2022 00:16:05 +0900

카프카 커넥트(Kafka Connect)란

카프카(Kafka)는 프로듀서(Producer)와 컨슈머(Consumer)를 통해 다양한 외부 시스템 데이터를 주고 받으며 메세지 파이프라인 아키텍쳐를 구성한다. 하지만 이러한 파이프라인을 매번 구성하며 프로듀서와 컨슈머를 개발하는 것은 쉽지 않다. 따라서 카프카 메세지로 파이프라인 아키텍쳐를 보다 적은 비용으로 보다 쉽게 구현하게 도와주는 것이 카프카 커넥트(Kafka Connect)이다.

카프카 커넥트(Kafka Connect)

카프카 커넥트는 아파치 카프카의 오픈소스 프로젝트 중 하나로, 카프카와 외부 시스템(DB 등) 간의 파이프라인 구성을 쉽게 해주는 프레임워크이다. 카프카 커넥트는 카프카 클러스트를 기준으로 커넥터를 양방향으로 배치하여 구성할 수 있다. 즉, 외부시스템 → 소스 커넥터 → 카프카 클러스트 → 싱크 커넥터 → 외부시스템과 같은 형태로 아키텍쳐를 구성하며 카프카와 외부시스템을 이어준다.

카프카 커넥트의 특징

카프카 커넥트는 대표적으로 다음과 같은 5가지 특징을 가지고 있다.

데이터 중심 파이프라인 : 카프카 커넥트를 이용해 카프카로 데이터를 보내거나, 카프카로 데이터를 가져옴
유연성 : 커넥트는 테스트를 위한 단독 모드(standalone mode)와 대규모 운영 환경을 위한 분산 모드(distributed mode)를 제공
재사용성과 확장성 : 커넥트는 기존 커넥터를 활용할 수도 있고 운영 환경에서의 요구사항에 맞춰 확장이 가능
편리한 운영과 관리 : 카프카 커넥트가 제공하는 REST API로 빠르고 간단하게 커넥트 운영 가능
장애 및 복구 : 카프카 커넥트를 분산 모드로 실행하면 워커 노드의 장애 상황에도 메타데이터를 백업함으로써 대응 가능하며 고가용성 보장

카프카 커넥트의 커넥터

카프카 커넥트(connect)는 커넥터로 구성되어있는 프레임워크이며 커넥터를 동작시키는 역할을 한다.

커넥터(connector)는 커넥트 내부의 실제 메시지 파이프라인이며 데이터를 실질적으로 처리한다. 이러한 커넥터는 카프카 클러스터를 기준으로 양쪽에 위치하고 있다. 커넥터에는 일종의 프로듀서의 역할을 하는 소스 커넥터, 컨슈머 역할을 하는 싱크 커넥터가 있다. 이러한 커넥터들은 카프카 커넥트가 제공하는 REST API로 구성할수있다.

소스 커넥터 : 외부 시스템에 담긴 데이터를 카프카 클러스터로 담아주는 프로듀서의 역할을 하는 커넥터
싱크 커넥터 : 카프카 클러스터에 있는 데이터를 외부 시스템으로 보내는 컨슈머의 역할을 하는 커넥터

카프카 커넥트의 커넥터

다시말해 커넥터들은 각자의 위치에서 데이터를 어디에서 어디로 복사해야 하는지의 작업을 정의하고 관리하는 역할을 한다. 예를들어 RDBMS의 데이터를 카프카로 이동하고 싶으면 JDBC 소스 커넥터가 필요하고, 카프카에 적재되어 있는 데이터를 HDFS로 적재하고 싶으면 HDFS 싱크 커넥터가 필요하다. 운영 환경에서 이용하는 커넥터의 대표적인 예로써는 미러 메이커 2.0, 데비지움(Debezium)등이 있다.

데비지움(Debezium)

카프카 커넥트의 내부 동작 원리

카프카 커넥트는 내부적으로 워커 단위로 이루어져있다. 워커는 카프카 커넥트 프로세스가 실행되는 서버 또는 인스턴스를 의미한다. 이러한 워커 내부는 커넥터와 테스크로 이루어져있다.

커넥터 : 데이터를 어디에서 어디로 복사하는지를 담당
테스크 : 커넥터가 정의한 작업을 직접 수행

카프카 커넥트는 다수의 커넥터와 다수의 테스크를 지닐 수 있는 워커를 한 개 또는 여러 개를 가지며 아키텍쳐를 형성하고 데이터를 처리한다.

커넥터와 테스크로 이루어진 워커

데이터 처리가 호출되면 워커 내부의 커넥터들에 의해 테스크들이 생성되고, 파이프라인이 구동된다. 그 후 테스크 내부에서는 외부 시스템의 메시지를 변화시키는 컨버터 처리가 발생한후 전송이 일어나는 원리이다.

카프카 커넥트의 데이터 처리 과정

카프카 커넥트의 모드

카프카 커넥트는 앞서 보았던 워커의 갯수에 따라 모드가 정해다.

만일 카프카 커넥트가 단일 워커로 이루어져있다면 단일 모드(standalone mode)라고 할 수 있다. 단일 모드의 경우 테스트 및 일회성 환경에 적합하다.

반대로 카프카 커넥트가 다수의 워커로 이루어져있다면 분산 모드(distributed mode)라고 할 수 있다. 분산 모드의 경우 실제 운영 환경으로 사용되며 REST API를 사용할 수 있다. 커넥트의 메타 데이터 정보를 저장함에 있어 카프카 클러스트를 이용할 수 있기에 장애에 유연하게 대처가 가능한 장점이 있다.

카프카 커넥트가 제공하는 REST API

카프카 커넥트를 보다 쉽게 사용하기 위해 REST API를 사용할 수 있다. 카프카 커넥트가 제공해주는 REST API로 관리자는 카프카 커넥트를 운영 관리할 수 있다.

✔︎참고. REST API 요청시 Content-Type, Accept 요청 헤더에 application/json 명시 필요

API 옵션	설명
GET /	커넥트 버전과 클러스터 ID 확인
GET /connectors	커넥터 리스트 확인
GET /connectors/커넥터 이름	커넥터 상세 내용 확인
GET /connectors/커넥터 이름/config	커넥터 config 정보 확인
GET /connectors/커넥터 이름/status	커넥터 상태 확인
PUT /connectors/커넥터 이름/config	커넥터 config 설정
PUT /connectors/커넥터 이름/pause	커넥터 일시 중지
PUT /connectors/커넥터 이름/resume	커넥터 다시 시작
DELETE /connectors/커넥터 이름	커넥터 삭제
GET /connectors/커넥터 이름/tasks	커넥터의 태스크 정보 확인
GET /connectors/커넥터 이름/tasks/태스크 ID/status	커넥터의 특정 태스크 상태 확인
POST /connectors/커넥터 이름/tasks/태스크 ID/restart	커넥터의 특정 태스크 재시작

[DB] Database의 샤딩(Sharding)

프로그래민 — Tue, 8 Feb 2022 20:41:24 +0900

샤딩이란

샤딩(Sharding)을 알기전 우선 샤드의 사전적 의미를 보면 조각 또는 파편을 의미한다. 즉, 데이터베이스에서의 샤딩(Sharding)은 한 테이블의 row들을 여러 개의 서로 다른 테이블, 즉 파티션으로 물리적으로 분리하는 것이다. row들을 여러 개의 서로 다른 테이블로 분해하는 것이기 때문에 한 테이블을 Horizontal Partitioning 했다고 볼 수 있다.

Vertical Partitions and Horizontal Partitions

샤딩은 보통 전체 데이터베이스 하나의 테이블에 전부 들어가기 힘든 데이터가 등장하고 DBMS가 테이블을 관리하기 힘들어짐에 따라 적용하게 된다. 데이터베이스를 샤딩하게 되면 기존에 하나로 구성될 스키마를 다수의 복제본으로 구성하고 각각의 샤드에 어떤 데이터가 저장될지를 샤드키를 기준으로 분리하게 된다.

주로 applicaton level에서 실행되며 어떤 샤드로 읽기와 쓰기를 전송할지를 정의하는 코드를 가지게 된다. 다만 어떤 데이터베이스에서는 내장된 샤딩 기능이 있어서 database level에서 실행될 때도 있다.

샤딩의 장단점

장점

Scale-Out이 가능
스캔 범위를 줄여서 쿼리 반응 속도를 빠르게 함
장애가 샤드 단위로 발생함

단점

프로그래밍 복잡도가 증가
데이터가 한 쪽 샤드로 몰릴 경우(Hotspot), 샤딩이 무의미 해짐
잘 못 사용할 경우 risk가 큼
한번 샤딩 사용시 샤딩 이전의 구조로 돌아가기 힘듬

샤딩은 위와 같이 프로그래밍, 운영적 복잡도가 높아지는 단점이 있습니다. 따라서 가능하다면 샤딩을 피하는 방법을 사용하는 것이 좋습니다. 대표적인 방법으로는 데이터베이스 서버의 Scale-Up, Read의 부하가 클 경우 Cache 사용 및 Database Replication, 테이블의 일부 컬럼만 주로 사용할 경우 Vertical Partitioning 등의 방법이 있습니다.

여러가지 샤딩 방식

데이터를 어떻게 나뉘어진 데이터베이스에 분산시키고, 이렇게 분산된 데이터를 어떻게 읽어올 것 인지는 샤드키(shard key)를 어떻게 정하는지에 따라 달라진다. 최대한 샤드들에게 균일하게 분산하는 것이 좋은데 그러기 위해선 다음과 같은 방법들이 있다.

Hash Sharding

Algorithm Sharding

데이터베이스의 id를 hashing 샤딩하는 방식이다. 즉 간단히 하면 샤드키를 id%num을 하여 정하는 방식이다. 다만 한번 나눌 갯수를 정해놓으면 수정하지 못한다는 단점이 있고, 단순한 hashing 방식이기에 데이터가 저장되는 공간적 효율에 대한 고려는 따로 할 수가 없게 된다.

Dynaminc Sharding

이름대로 Dynamic하게 샤딩하는 방식이다. 즉, 일종의 Locator Service를 통하여 샤드 키를 정하는 방식이다. Locator Service를 한번 거쳐서 샤드키를 얻기 때문에 확장에 유연한 방식이다. 하지만 데이터의 재배치등에 있어서 Locator Service도 변환해야하기 때문에 Locator에 의존적인 단점이 있다.

Entity Group

위의 key-value 방식인 Hash Sharding과 Dynaminc Sharding과는 다르게 동일한 파티션에 관련 엔티티를 저장하여 단일 파티션 안에서 추가 기능을 제공하는 방식이다. 즉, 관련된 데이터에 대해 하나의 샤드를 이용하는 방식이다. 하나의 물리적인 샤드를 사용하기에 쿼리진행시 효과적이며 응집도가 높아진다는 장점이 있다. 하지만 다른 샤드와 관련된 쿼리를 사용하게 된다면 샤드를 사용 안했을 때 보다 성능이 더 떨어질 수 도 있다는 단점이 있다.

출처

[데이터베이스 개론] 11장. 보안과 권한 관리

프로그래민 — Mon, 7 Feb 2022 00:54:33 +0900

보안

데이터베이스에 저장된 데이터는 조직을 운영하는 데 꼭 필요한 것으로, 조직 내 사용자들이 공유하여 사용한다. 만약 사용이 허락되지 않은 외부인이 데이터베이스에 칩입하여 데이터를 유출하거나 손상한다면 조직에 치명적인 손실이 발생할 것이다. 따라서 조직에서 허가한 사용자만 데이터베이스에 접근할 수 있도록 통제하여 유지하는 일이 중요하다. 데이터베이스의 보안은 크게 3가지로 나뉠 수 있다.

물리적 환경에 대한 보안 : 자연 재해 등으로부터 보호
권한 관리를 통한 보안 : 권한이 없는 사용자로부터 보호
운영 관리를 통한 보안 : 권한이 있는 사용자로부터 보호, 허가된 사용자의 실수로 부터 데이터 무결성 유지 및 제약조건 정의

권한 관리

권한 관리의 개념

데이터베이스 관리 시스템은 데이터베이스의 보안을 유지하기 위해 사용자가 로그인에 성공했을 때만 접근 가능하도록 접근 제어 기능을 제공한다. 새로운 사용자의 계정과 암호를 생성하고, 기존 사용자의 계정을 변경 및 제거하는 사용자 계정 관리는 데이터베이스 관리자가 담당하며 데이어베이스 관리자는 데이터베이스 전체의 보안을 관리하기 위해 필요한 모든 권한을 가지고 있다. 로그인을 통해 데이터베이스에 접근할 수 있더라도 데이터베이스 안에 있는 모든 데이터를 사용할 수 있는 것은 아니며 보안을 위한 데이터 단위는 데이터베이스 전체부터 특정 테이블의 특정 행과 열 위치에 있는 특정 데이터 값에 이르기까지 다양하다.

권한 관리를 통한 보안

데이터베이스 객체의 소유자는 필요에 따라 자신이 소유한 데이터베이스 객체에 대한 사용 권한을 다른 사용자에게 SQL 문을 이용하여 부여할 수 있다.

권한의 부여

GRANT 권한 ON 객체 TO 사용자 [WITH GRANT OPTION];

객체의 소유자가 다른 사용자에게 객체에 대한 사용 권한을 부여하기 위해 필요한 SQL 명령어는 GRANT이다. 데이터베이스에 존재하는 모든 유형의 객체에 사용 권한을 부여할 수 있지만 대부분 테이블에 권한 부여하는 경우가 많다. GRANT 명령어로 부여받은 권한은 기본적으로 다른 사용자에게 부여할 수 없지만 WITH GRANT OPTION을 포함하면 권한을 부여받은 사용자가 자신이 부여받은 권한을 다른 사용자에게도 부여할 수 있다.

객체에 대한 권한은 해당 객체의 소유자가 부여하지만 시스템 권한은 데이터베이스 관리자가 부여할 수 있다. 시스템 권한은 특정 객체에 대한 작업이 아닌, 데이터베이스 관리와 관련된 작업에 대한 권한이다. DDL과 같은 데이터 정의어와 관련된 작업에 대한 권한들이 시스템 권한에 속한다. 데이터베이스 권한을 부여할 때도 GRANT 명령어를 이용한다. 단, 특정 객체에 대한 권한을 부여하는 것이 아니므로 시스템 권한을 부여할 때는 객체를 지정할 필요가 없다.

권한의 취소

REVOKE 권한 ON 객체 FROM 사용자 CASCADE|RESTRICT;

다른 사용자에게 부여한 객체의 권한을 취소하기 위해 필요한 SQL 명령어는 REVOKE이다. 앞선 WITH GRANT OPTION을 포함하여 GRANT 문을 수행하고 권한을 부여받은 사용자가 자신이 부여받은 권한을 다른 사용자에게도 부여할 수 가 있다. 이를 위해 맨뒤에 옵션이 사용되는데, CASCADE 옵션을 포함하여 권한을 취소하면 연관된 다른 사용자들의 권한도 함께 취소가 되고, RESTRICT 옵션을 포함하여 권한을 취소하면 만일 다른 사용자에게 취소의 영향이 가면 REVOKE 명령이 실패하게 된다.

데이터베이스 관리자가 다른 사용자에게 부여한 시스템을 취소할 때도 REVOKE 문을 이용한다. 단 특정 객체에 대한 권한을 취소하는 것이 아니므로 시스템 권한을 취소하고자 할 때는 REVOKE 문에서 객체를 지정할 필요가 없다.

역할의 부여와 취소

여러 사용자에게 동일한 권한들을 부여하고 취소하는 번거로운 작업울 편리하게 수행할 수 있도록 도움을 주는 것이 역할이다.

CREATE ROLE 롤이름;

새로운 역할을 생성하는 기능은 데이터베이스 관리자가 담당하며, 역할을 생성하는데 필요한 SQL 명령어는 CREATE ROLE이다.

GRANT 권한 ON 객체 TO 롤이름;

그 후 역할에 필요한 권한을 넣을 때는 GRANT 명령어를 이용한다.

GRANT 롤이름 TO 사용자;

필요한 권한이 들어가 있는 역할을 사용자에게 부여하는 것은 데이터베이스 관리자가 담당하며 GRANT 문을 이용한다. 새로운 권한의 추가, 기존 권한의 취소 등 역할에 변화가 생기면 해당 역할을 부여받은 모든 사용자에게 변화가 그대로 전달되어 관리에 있어 용이하다.

REVOKE 롤이름 FROM 사용자;

사용자에게 부여한 역할을 취소하는 작업은 데이터베이스 관리자가 담당하며, 권한 취소처럼 REVOKE 문을 이용한다.

DROP ROLE 롤이름;

마지막으로 역할제거 또한 데이터베이스 관리자가 담당하며 DROP ROLE 문을 이용한다.

데이터베이스 개론 - 교보문고

[요약]①데이터베이스 기초 이론 : 1장에서 데이터베이스를, 2장에서 DBMS를 소개합니다. 3장에서는 이들을 조합한 데이터베이스 시스템을 소개합니다.②데이터 모델과 연산 : 4장에서 데이터 모

www.kyobobook.co.kr

[데이터베이스 개론] 10장. 트랜잭션

프로그래민 — Mon, 7 Feb 2022 00:08:52 +0900

트랜잭션

트랜잭션의 개념

데이터베이스 관리 시스템은 데이터베이스가 항상 정확하고 일관된 상태를 유지할 수 있도록 트랜잭션이란 기능을 제공한다. 트랜잭션을 관리함으로써 데이터베이스의 회복과 병행 제어가 가능해져, 결과적으로 데이터베이스가 일관된 상태를 유지할 수 있게 된다. 즉, 트랜잭션(transcation)은 하나의 작업을 수행하는 데 필요한 데이터베이스의 연산들을 모아놓은 것으로, 데이터베이스에서 논리적인 작업의 단위가 된다. 또한 데이터베이스가 장애가 발생했을 때 데이터를 복구하는 단위도 된다. 일반적으로 SQL문들의 모임으로 이루어져있다. 트랜잭션의 모든 명령문이 완벽하게 처리되거나 하나도 처리되지 않아야 데이터베이스가 모순이 없는 일관된 상태를 유지할 수 있다. 즉, 데이터베이스의 무결성과 일관성을 트랜잭션을 이용하여 보자알 수 있다.

트랜잭션의 특성

트랜잭션의 특성과 DBMS의 기능

트랜잭션이 성공적으로 처리되어 데이터베이스의 무결성과 일관성이 보장되려면 ACID라는 네가지 특성이 중요하다. 또한 이러한 네가지 특성을 보장하기 위해 DBMS는 위와 같은 기능들을 제공한다.

원자성(Atomicity)

트랜잭션의 원자성은 트랜잭션을 구성하는 연산들이 모두 정상적으로 실행되거나 하나도 실행되지 않아야 한다는 all-or-nothing 방식을 의미한다. 즉 트랜잭션이 원자성을 보장하면 트랜잭션을 구성하는 연산 중 일부만 처리가 되는 일이 발생하지 않아야 하고, 원래의 데이터베이스의 상태로 복구하는 기능을 수행하게 된다.

일관성(Consistency)

트랜잭션의 일관성은 트랜잭션이 성공적으로 수행된 후에도 데이터베이스가 일관된 상태를 유지해야 함을 의미한다. 즉, 트랜잭션이 수행되기 전에 데이터베이스가 일관된 상태였다면 트랜잭션의 수행이 완료된 후 결과를 반영한 데이터베이스도 또 다른 일관된 상태가 되어야 한다는 의미이다.

격리성(Isolation)

트랜잭션의 격리성은 고립성이라고도 하는데, 현재 수행 중인 트랜잭션이 완료될 때까지 트랜잭션이 생성한 중간 연산 결과에 다른 트랜잭션들이 접근할 수 없음을 의미한다. 일반적으로 데이터베이스 시스템에서는 여러 트랜잭션이 동시에 수행되지만 각 트랜잭션이 독립적으로 수행될 수 있도록 다른 트랜잭션의 중간 연산 결과에 서로 접근하지 못하게 하며 트랜잭션의 격리성을 보장한다.

지속성(Durability)

트랜잭션의 지속성은 영속성이라고도 하는데 트랜잭션이 성공적으로 완료된 후 데이터베이스에 반영한 수행 결과는 어떠한 경우에도 손실되지 않고 영구적이어야 함을 의미한다.즉 시스템에 장애가 발생하더라도 트랜잭션 작업 결과는 없어지지 않고 데이터베이스에 그대로 남아 있어야 하며, 나아가 복구하는 회복 기능까지 데이터베이스가 제공한다.

트랜잭션의 연산

트랜잭션의 수행과 관련하여 주로 사용되는 연산에는 트랜잭션이 성공적으로 수행되었음을 선언(작업 완료)해주는 commit 연산과 트랜잭션을 수행하는데 실패했음을 선언(작업 취소)해주는 rollback 연산이 있다.

commit 연산이 실행된 후에야 트랜잭션의 수행 결과가 데이터베이스에 반영되어 데이터베이스가 일관된 상태를 지속적으로 유지하게 된다. 즉, commit 연산을 통해 트랜잭션의 수행이 성공적으로 완료되었음을 선언하고 트랜잭션이 수행한 최종결과를 데이터 베이스에 반영한다.

rollback 연산이 실행되면 트랜잭션이 지금까지 실행한 연산의 결과가 취소되고 트랜잭션이 수행되기 전의 상태로 돌아간다. 즉, rollback 연산을 통해 트랜잭션의 수행이 실패했음을 선언하고 데이터베이스를 트랜잭션 수행 전의 일관돈 싱태로 되돌려 모순이 발생하지 않게 한다.

트랜잭션의 상태

트랜잭션의 다섯 가지 상태

트랜잭션은 다섯 가지 상태 중 하나에 속하게 된다. 트랜잭션이 수행되기 시작하면 활동 상태가 되고, 활동 상태의 트랜잭션이 마지막 연산을 처리하고 나면 부분 완료 상태가 되며, 부분 완료 상태의 트랜잭션이 commit 연산을 실행하면 완료상태가 된다. 활동 상태나 부분 완료 상태에서 여러 원인으로 인해 더는 정상적인 수행이 불가능하게 되면 트랜잭션은 실패 상태가 된다. 실패 상태의 트랜잭션은 rollback 연산의 실행으로 철회 상태가 된다. 트랜잭션이 완료 상태이거나 철회 상태가 되면 트랜잭션이 종료된 것으로 판단한다.

활동 상태

트랜잭션이 수행되기 시작하여 수행중인 상태를 활동상태라고 한다. 활동 상태인 트랜잭션은 상황에 따라 부분 완료 상태 또는 실패 상태가 된다.

부분 완료 상태

트랜잭션의 마지막 연산이 실행된 직후의 상태를 부분 완료 상태라 하며 트랜잭션의 모든 연산을 처리한 상태다. 모든 연산을 수행하였지만 데이터베이스에 반영되지 않은 상태로써, 상황에 따라 완료 상태나 실패 상태가 될 수 있다.

완료 상태

트랜잭션이 성공적으로 완료되어 commit 연산을 실행한 상태를 완료 상태라고 한다. 트랜잭션이 수행한 결과를 데이터베이스에 반영한 상태이다.

실패 상태

하드웨어나 소프트웨어의 문제, 트랜잭션 내부의 오류 등 여러 이유로 인해 장애가 발생하여 트랜잭션의 수행이 중단된 상태를 실패상태라고 한다.

철회 상태

트랜잭션을 수행하는데 실패하여 rollback 연산을 실행한 상태를 철회 상태라고 한다. 트랜잭션이 철회 상태가 되면 지금까지 실행한 트랜잭션의 연산을 모두 취소하고 트랜잭션이 수행되기 전의 데이터베이스 상태로 되돌리면서 트랜잭션이 종료된다.

장애와 회복

트랜잭션의 특성을 보장하고, 데이터베이스를 모순이 없는 일관된 상태로 유지하기 위해 데이터베이스 관리 시스템은 회복 기능을 제공한다. 회복은 장애가 발생했을 때 데이터베이스를 장애가 발생하기 전의 일관된 상태로 복구시키는 것이다.

장애의 유형

시스템이 제대로 동작하지 않는 상태를 장애라고 한다. 장애가 발생하는 유형에 따라 위와 같이 3가지로 나눌 수 있다.

데이터베이스의 저장 연산

저장 장치의 종류

데이터베이스는 기본적으로 저장 장치에 저장된다. 그리고 저장 장치는 장애가 발생했을 때 대응하는 방법에 따라 위와 같이 3종류로 나눌 수 있다.

응용 프로그램이 실행한 트랜잭션의 수행을 위해 필요한 데이터 이동 연산

일반적으로 데이터베이스는 비휘발성 저장 장치인 디스크에 상주한다. 하지만 트랜잭션이 데이터베이스의 데이터를 처리하려면 디스크에서 메인 메모리로 가져와 이를 응용 프로그램의 요구에 맞게 처리한 후 그 결과를 디스크로 다시 보내는 작업을 한다. 디스크와 메인 메모리 간의 데이터 이동은 블록 단위로 수해된다. 디스케이 있는 블록을 디스크 볼록이라 하고 메인 메모리에 있는 블록은 버퍼 블록이라 한다. 그리고 input, output 연산을 통해 데이터를 주고 받는다. 그리고 응용 프로그램의 명령을 read, write 연산을 통해 수행하며 메인 메모리의 버퍼 블록과 데이터를 주고 받는다.

회복 기법

회복은 데이터베이스에 장애가 발생했을 때 장애가 발생하기 전의 모순이 없고 일관된 상태로 복구시키는 것으로, 데이터베이스 관리 시스템에 있는 회복 관리자가 담당한다. 회복 관리자는 장애 발생을 탐지하고, 장애가 탐지되면 데이터베이스 복구 기능을 제공한다.

회복을 위한 연산

데이터베이스 회복의 핵심 원리는 데이터 중복이다. 데이터를 별도의 장소에 미리 복사해두고, 장애로 문제가 발생했을 때 복사본을 이용해 원래의 상태로 복원하는 것이다. 데이터베이스 전체를 다른 저장 장치에 주기적으로 복사하는 방법인 덤프나 데이터베이스에서 변경 연산이 실행될 때마다 데이터를 변경하기 이전 값과 변경한 이후의 값을 별도의 파일에 기록하는 방법인 로그를 이용하여 데이터를 복사했다가 회복한다.

덤프나 로그로 저장한 중복 데이터를 이용하여 장애상황시 복구를 할 때 redo나 undo 연산을 실행한다. redo 연산은 로그에 기록된 변경 연산 후의 값을 이용하여 변경 연산을 재실행하는 방법으로 데이터베이스를 복구한다. undo 연산은 로그에 기록된 변경 연산 이전의 값을 이용하여 변경 연산을 취소하는 방법으로 데이터베이스를 복구한다.

데이터베이스 회복 기법의 분류

장애가 발생하는 시점과 유형이 다양하고, 데이터베이스를 빠른 시간 내에 복구해야 하므로 실제로 데이터베이스 관리 시스템은 위와 같이 좀 더 복잡하고 효율적인 회복 기법들을 사용한다.

로그 회복 기법

로그를 이용한 회복 기법은 데이터를 변경한 연산 결과를 데이터베이스에 반영하시는 시점에 따라 즉시 갱신 회복 기법과 지연 갱신 회복 기법을 나눈다.

즉시 갱신 회복 기법은 트랜잭션 수행 중에 데이터를 변경한 연산의 결과를 데이터베이스에 즉시 반영한다. 그리고 장애 발생에 대비하기 위해 데이터 변경에 대한 내용을 로그 파일에 기록한다. 즉시 갱신 회복 기법은 장애가 발생하면 로그 파일에 기록된 내용을 참조하여, 장애 발생 시점에 따라 redo나 undo 연산을 실행하여 데이터베이스를 복구한다.

지연 갱신 회복 기법은 트랜잭션이 수행되는 동안에는 데이터 변경 연산의 결과를 데이터베이스에 즉시 반영하지 않고 로그 파일에만 기록해두었다가, 트랜잭션이 부분 완료된 후에 로그에 기록된 내용을 이용해 데이터베이스에 한 번에 반영한다. 트랜잭션이 수행되는 동안 장애가 발생할 경우 로그에 기록된 내용을 버리기만 하면 데이터베이스가 원래 상태를 그대로 유지하게 된다. 따라서 지연 갱신 회복 기법에는 undo 연산은 따로 없고 redo 연산만 필요하다.

검사 시점 회복 기법

검사 시점 회복 기법은 로그 회복 기법과 같은 방법으로 로그 기록을 이용하되, 일정 시간 간격으로 검사 시점을 만들어둔다. 그리고 장애가 발생하면 가장 최근 검사 시점 이전의 트랜잭션에는 회복 작업을 수행하지 않고, 이후의 트랜잭션에만 회복 작업을 수행한다. 검사 시점 회복 기법을 이용하면 회복 작업의 범위가 검사 시점으로 정해지므로 불필요한 회복작업을 수행하지 않아 데이터베이스 회복 시간이 단축된다는 장점이 있다.

미디어 회복 기법

디스크에 발생할 수 있는 장애에 대비한 회복 기법은 미디어 회복기법이다. 미디어 회복 기법은 전체 데이터베이스의 내용을 일정 주기마다 다른 안전한 저장 장치에 복사해두는 덤프를 이용한다. 디스크 장애가 발생하면 가장 최근에 복사해둔 덤프를 이용해 장애 발생 이전의 일관된 데이터 베이스 상태로 복구한다.

병행 제어

병행 수행과 병행 제어

데이터베이스 관리 시스템은 여러 사용자가 데이터베이스를 동시에 공유할 수 있도록 여러 개의 트랜잭션이 동시에 수행되는 병행 수행을 지원한다. 병행 수행은 여러 트랜잭션이 차례로 번갈아 수행되는 인터리빙 방식으로 진행된다. 또한, 여러 개의 트랜잭션이 병행 수행되면서 같은 데이터에 접근하여 연산을 실행하더라도, 문제가 발생하지 않고 정확한 수행 결과를 얻을 수 있도록 트랜잭션의 수행을 제어하는 병행 제어, 동시성 제어를 제공한다.

병행 수행의 문제

병행 수행을 특별한 제어 없이 진행하면 여러 문제가 발생할 수 있고, 대표적으로 갱신 분실, 모순성, 연쇄 복귀가 있다.

갱신 분실

갱신 분실은 하나의 트랜잭션이 수행한 데이터 변경 연산의 결과를 다른 트랜잭션이 덮어써 변경 연산이 무효화되는 것이다. 즉, 하나의 데이터에 대한 두개 이상의 트랜잭션 연산이 순차적으로 안 이루어지는 상황이다. 따라서 순차적으로 수행한 것과 같은 결과값을 얻어야 정확한 병행 수행이라고 할 수 있다.

모순성

모순성은 하나의 트랜잭션이 여러 개의 데이터 변경 연산을 실행할 때 일관 없는 상태의 데이터베이스에서 데이터를 가져와 연산을 실행함으로써 모순된 결과가 발생하는 것이다. 예를 들면 어떤 연산은 현재의 트랜잭션이 실행되기 전 상태의 데이터베이스에서 데이터를 가져와 실행하고, 또 다른 연산은 다른 트랜잭션이 변경한 데이터베이스에서 데이터를 가져와 실해하면 모순성은 문제가 발생한다.

연쇄 복귀

연쇄 복귀는 트랜잭션이 완료되기 전에 장애가 발생하여 rollback 연산을 수행하면, 이 트랜잭션이 장애 발생 전에 변경한 데이터를 가져가 변경 연산을 실행한 또 다른 트랜잭션에도 rollback 연산을 연쇄적으로 실행해야 한다는 것이다. 그런데 장애가 발생한 장애가 발생한 트랜잭션이 rollback 연산을 실행하기 전에 변경한 데이터를 가져가 사용한 다른 트랜잭션이 수행을 완료해버리면 rollback 연산을 실행할 수 없어 문제가 된다.

트랜잭션 스케줄

병행 수행에서는 트랜잭션들이 차례로 번갈아 가면서 수행되는 인터리빙 방식으로 진행이 된다. 다만 트랜잭션에 있는 연산을 실행하는 순서에 따라 트랜잭션들의 수행 결과가 달라지기도 하고, 병행 수행에 따른 문제가 발생하기도 한다. 그러므로 여러 트랜잭션을 병행 수행할 때는 트랜잭션들의 연산을 실행하는 순서인 트랜잭션 스케쥴이 중요하다. 크게 3가지 유형의 트랜잭션 스케줄이 있다.

직렬 스케줄

직렬 스케줄은 인터리빙 방식을 이용하지 않고 각 트랜잭션별로 연산들을 순차적으로 실행시키는 것이다. 트랜잭션이 직렬 스케줄에 따라 수행되면, 모든 트랜잭션이 완료될때까지 다른 트랜잭션의 방해를 받지 않고 독립적으로 수행된다. 그래서 직렬 스케줄은 항상 정확한 결과를 얻는다. 다만 인터리빙 방식을 사용하지 않고 각 트랜잭션을 독립적으로 수행하기 때문에 트랜잭션들이 동시에 수행되는 병행 수행이라고 할 수 없다.

비직렬 스케줄

비직렬 스케줄은 인터리빙 방식을 이용하여 트랜잭션을 병행해서 수행시키는 것이다. 비직렬 스케줄은 트랜잭션이 돌아가면서 연산들을 실행하기 때문에 하나의 트랜잭션이 완료되기 전에 다른 트랜잭션의 연산이 실행될 수 있다. 따라서 여러 튼랜잭션을 병행 수행하면 갱신 분실, 모순성, 연쇄 복귀 등의 문제가 발생할 수 있어 최종 수행 결과의 정확성을 보장할 수 없다.

직렬 가능 스케줄

직렬 가능 스케줄은 직렬 스케줄을 따라 수행한 것과 같이 정확한 결과를 생성하는 비직렬 스케줄이다. 모든 비직렬 스케줄이 직렬 가능한 것은 아니다. 직렬 가능 스케줄은 인터리빙 방식을 이용하여 여러 트랜잭션을 병행 수행하면서도 정확한 결과를 얻을 수 있다. 다만 직렬 가능 스케줄인지 여부를 판단 하는 일은 쉽지 않기에 대부분의 데이터 관리 시스템에서는 직렬 가능 스케줄인지를 검사하기 보다는 직렬 가능성을 보장하는 병행 제어 기법을 사용한다.

병행 제어 기법

병행 제어 기법은 여러 트랜잭션을 병행 수행하면서도 정확한 결과를 얻을 수 있는 직렬 가능성을 보장받기 위해 사용한다. 병행 제어 기법의 기본 원리는 직렬 가능성이 보장되는 나름의 규약을 정의하고, 모든 트랜잭션들이 이 규약을 따르도록 하는 것이다. 따라서 트랜잭션 스케줄이 직렬 가능 스케줄인지를 미리 검사할 필요가 없다. 가장 많이 사용되는 병행 제어 기법으로는 로킹 기법이 있다.

로킹 기법의 개념

로킹 기법은 병행 수행되는 트랜잭션들이 동일한 데이터에 동시에 접근하지 못하도록 lock과 unlock이라는 2개의 연산을 이용해 제어한다. 로킹 기법의 기본 원리는 한 트랜잭션이 먼저 접근한 데이터에 대한 연산을 모두 마칠 때 까지, 해당 데이터에 다른 트랜잭션이 접근하지 못하도록 상호 배제하여 직렬 가능성을 보장하는 것이다. 로킹 기법에서 lock 연산은 트랜잭션이 사용할 데이터에 대한 독점권을 가지기 위해 사용하고, unlock 연산은 트랜잭션이 데이터에 대한 독점권을 반납하기 위해 사용한다.

기본 로킹 규약에서는 트랜잭션이 데이터베이스에 있는 데이터에 접근하는 연산을 실행하려면 먼저 해당 데이터에 lock 연산을 실행하여 독점권을 획득한다. 이때, 다른 트랜잭션이 이미 lock 연산을 실행한 데이터에는 다시 lock 연산이 실행될 수 없다. 트랜잭션이 lock 연산을 통해 독점권을 획득한 데이터에 대한 모든 연산을 수행하고 나면 unlock 연산을 실행할 수 있다.

lock 연산을 실행하는 대상 데이터의 크기인 로킹 단위는 크게는 데이터베이스부터 작게는 데이터베이스를 구성하는 속성에 이르기까지 다양한 크기의 데이터를 대상으로 실행할 수 있다. 다만 로킹단위가 커질수록 병행성은 낮아지지만 제어가 쉽고, 로킹 단위가 작아질수록 제어가 어렵지만 병행성은 높아진다.

lock 연산

또한 위와 같이 write 연산과 다르게 read 연산에 대해서는 트랜잭션들이 하나의 데이터에 read 연산을 동시에 실행할 수 있도록 해서 처리 필요성을 높일 필요가 있다. 다만 일관성 없는 데이터에 대한 접근을 할 수 있기에 기본 로킹만으로는 완벽한 트랜잭션 스케줄의 직렬 가능성을 보장할 수가 없다. 따라서 lock과 unlock 연산을 실행하는 시점에 대한 새로운 규약이 추가된 2단계 로킹 규약이 필요하다.

2단계 로킹 규약

기본 로킹 규약의 문제를 해결하고 트랜잭션의 직렬 가능성을 보장하기 위해 lock과 unlock 연산의 수행 시점에 대한 새로운 규약을 추가하여 직렬 가능성을 보장시킨 것이 2단계 로킹 규약이다. 2단계 로킹 규약에서는 모든 트랜잭션이 lock과 unlock 연산을 확장 단계, 축소 단계를 포함한 2단계로 나누어 실행한다. 확장 단계는 트랜잭션이 lock 연산만 실행할 수 있고, unlock 연산은 실행할 수 없는 단계이고, 축소 단계는 트랜잭션이 unlock 연산만 실행할 수 있고, lock 연산은 실행할 수 없는 단계이다.

트랜잭션이 처음에 수행되면 확장 단계로 들어가 lock 연산만 실행할 수 있다. 그러다가 unlock 연산을 실행하면 축소 단계로 들어가 그때부터는 unlock 연산만 실행할 수 있게 된다. 2단계 로킹 규약을 준수하는 트랜잭션은 첫 번째 unlock 연산을 실행하기 전에 필요한 모든 lock 연산을 실행해야 한다. 다만 트랜잭션들이 상대가 독점하고 있는 데이터에 unlock 연산이 실행되기를 서로 기다리면서 수행을 중단하고 있는 교착 상태가 발생할 수 있기에 조치가 필요할 수 도 있다.

데이터베이스 개론 - 교보문고

www.kyobobook.co.kr

[데이터베이스 개론] 09장. 정규화

프로그래민 — Sat, 5 Feb 2022 22:47:08 +0900

정규화의 개념과 이상 현상

정규화의 개념

데이터베이스를 잘못 설계하면 불필요한 데이터 중복이 발생하여 릴레이션에 대한 데이터의 삽입∙수정∙삭제 연산을 수행할 때 부작용이 발 생할 수 있다. 이러한 부작용을 이상현상이라 하며 이를 제거하는 하며 설계하는 과정을 정규화라고 한다.

이상 현상의 종류

삽입 이상 : 새 데이터를 삽입하기 위해 불필요한 데이터도 함께 삽입해야 하는 문제
갱신 이상 : 중복 투플 중 일부만 변경하여 데이터가 불일치하게 되는 모순의 문제
삭제 이상 : 투플을 삭제하면 꼭 필요한 데이터까지 함께 삭제되는 데이터 손실의 문제

정규화의 필요성

이상 현상은 관련이 없는 데이터, 관련 없는 속성들을 하나의 릴레이션에 가지고 있기에 생기게 된다. 이상 현상이 발생하지 않도록 하려면, 관련 있는 속성들로만 릴레이션을 구성해야하고 이를 정규화를 통해 할 수 있다. 즉, 정규화는 이상 현산이 발생하지 않도록, 릴레이션을 관련이 있는 속성들로만 구성하기 위해 릴레이션을 분해하는 과정이다.

함수 종속

하나의 릴레이션을 구성하는 속성들의 부분 집합을 X와 Y라 할 때, 어느 시점에서든 릴레이션 내의 모든 투플에서 하나의 X값에 대한 Y 값이 항상 하나면 X가 Y를 함수적으로 결정하고, Y가 X에 함수적으로 종속되어 있다고 말할 수 있다. 즉, 함수 종속 관계는 X→Y로 표현하고 X를 결정자, Y를 종속자라고 한다. 예를 들면 고객 릴레이션에서 고객아이디→고객이름과 같은 속성이 있을 수 있다. 다만 함수 종속 관계를 판단할 때 유의할 점은 현재 시점에 릴레이션에 포함된 속성 값만으로 판단하면 안된다는 것이다. 릴레이션에서 속성 값은 계속 변할 수 있기 때문에 속성 자체가 가지고 있는 특성과 의미를 기반으로 판단해야 한다.

완전 함수 종속은 릴레이션에서 속성 집합 Y가 속성 집합 X에 함수적으로 종속되어 있지만, 속성 집합 X 전체에 종속된 것인지 일부분에 종속된 것이 아님을 의미한다. 부분 함수 종속은 속성 집합 Y가 속성 집합 X의 전체가 아닌 일부분에도 함수적으로 종속됨을 의미하며, 부분 함수 종속 관계가 성립하려면 결정자가 여러 개의 속성들로 구성되어 있어야 한다.

기본 정규화와 정규화 과정

정규화의 개념과 정규형의 종류

함수 종속성을 이용하여 릴레이션을 연관성이 있는 속성들로만 구성되도록 분해해서, 이상 현상이 발생하지 않는 올바른 릴레이션으로 만들어가는 과정을 정규화라고 한다. 정규화의 기본 목표는 관련이 없는 함수 종속성은 별개의 릴레이션으로 표현하는 것이다. 릴레이션이 정규화된 정도는 정규형으로 표현하며 크게 기본 정규형과 고급 정규형이 있다. 기본 정규형에는 제1정규형, 제2정규형, 제3정규형, 보이스/코드 정규형이 있고, 고급 정규형에는 제4정규형, 제5정규형이 있다.

일반적으로 차수가 높은 정규형에 속하는 릴레이션일수록 데이터 중복이 줄어 데이터 중복에 의한 이상 현상이 발행하지 않는 바람직한 릴레이션이지만 모든 릴레이션이 제5정규형에 속해야 되는 것은 아니다.

제1정규형(1NF)

릴레이션에 속한 모든 속성의 도메인이 원자 값으로만 구성되어 있으면 제1정규형에 속한다. 관계 데이터베이스의 모든 릴레이션을 모든 속성이 원자값을 가지는 특성이 있기에 최소한 제1정규형을 만족해야 관계 데이터베이스의 릴레이션이 될 수 있다. 다만 제1정규형을 만족하더라도 불필요한 데이터르 중복으로 인해 이상 현상이 발생하는 릴레이션이 생길 수 있다. 즉, 부분 함수 종속이 생길 수 있는데, 이를 위해 릴레이션을 분해하여 부분 함수 종속을 제거하면 제2정규형에 속하게 된다.

제2정규형(2NF)

릴레이션이 제1정규형에 속하고, 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속되면 제2정규형에 속한다. 즉, 제1정규형에 속하는 릴레이션이 제2정규형을 만족하게 하려면, 부분 함수 종속을 제거하고 모든 속성이 기본키에 완전 함수 종속되도록 릴레이션을 분해하는 정규화 과정이 필요하다. 다만 부분 함수 종속이 제거되도록 릴레이션을 분해하더라도 함수 종속성을 여전히 가지고 있어서 이상 현상이 발생할 수 있다. 다시 말해 함수적 종속 관계를 여러 개 포함하고 있어 결과적으로 이행적 함수 종속이 생기기 때문에 이를 위해 릴레이션을 분해하여 이행적 함수 종속을 제거하면 제3정규형에 속하게 된다.

제3정규형(3NF)

릴레이션이 제2정규형에 속하고, 기본키가 아닌 모든 속성이 기본키에 이행적 함수 종속이 되지 않으면 제3정규형에 속한다. 이행적 함수 종속이란 X→Y, Y→Z의 함수 종속 관계를 가지는 상황에서 X→Z가 성립하게 되는 상황을 의미한다. 제2정규형을 만족하더라도 하나의 릴레이션에 함수 종속 관계가 여러개 있고 그중에서도 이행적 함수 종속 관계를 가지게 되면 이상 현상이 발생할 수 있다. 따라서 이행적 함수 종속이 발생하지 않도록 릴레이션을 분해해야 한다.

보이스/코드 정규형(BCNF)

릴레이션의 함수 종속 관계에서 모든 결정자가 후보키이면 보이스/코드 정규형에 속한다. 제3정규형까지 마치고 나면 하나의 릴레이션에 여러개의 후보키가 존재할 수도 있는데, 이 경우에은 제3정규형까지 모두 만족하더라도 이상 현상이 발생할 수 있다. 따라서 후보키가 여러개 있을때 발생할 수 있는 이상 현상을 방지하기 위해 보이스/코드 정규형을 하게 된다. 따라서 제3정규형의 릴레이션에서 기본키가 유일한 후보키이며 함수 종속 관계어서도 유일한 결정자가 되도록 릴레이션을 분해한다.

제4정규형과 제5정규형

고급 정규형으로 분류되는 제4정규형은 릴레이션이 보이스/코드 정규형을 만족하면서, 함수종속이 아닌 다치 종속을 제거해야 만족할 수 있다. 그리고 제5정규형은 릴레이션이 제4정규형을 만족하면서 후보키를 통하지 않는 조인 종속을 제거해야 만족할 수 있다. 다만 오히려 제5정규형까지 만족할 때까지 분해할 경우 비효율적일 때가 많다.

정규화 과정 정리

정규화 과정

릴레이션을 분해하여 모든 속성의 도메인이 원자 값으로만 구성되도록하면 제1정규형이 된다. 제1정규형에 속하는 릴레이션에서 부분 함수 종속을 제거하여 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속되면 제2정규형이 된다. 제2 정규형 릴레이션에서 이행적 함수 종속을 제거하면 제3정규형이 된다. 제3정규형 릴레이션에서 후보키가 아닌 결정자를 제거하면 보이스/코드 정규형이 된다.

데이터베이스 개론 - 교보문고

www.kyobobook.co.kr

[데이터베이스 개론] 08장. 데이터베이스 설계

프로그래민 — Fri, 4 Feb 2022 00:52:56 +0900

데이터베이스 설계 단계

데이터베이스를 설계할때는 사용자들의 요구 사항을 잘 분석하고, 분석한 결과를 바탕으로 데이터 베이스의 논리적, 무리적 구조를 제대로 설계하는 것이 중요하다. 이러한 관계 데이터 모델을 기반으로 두고 데이터베이스를 설계할 때는 주로 두가지 방법을 사용한다. 첫째는 E-R 모델과 릴레이션 변환 규칙을 이용한 데이터베이스 설계이고, 둘째는 정규화를 이용한 데이터베이스 설계이다.

E-R 모델과 릴레이션 변환 규칙을 이용한 데이터베이스 설계는 다음 5단계로 이루어진다.

데이터베이스 설계 과정의 각 단계별 주요 작업과 결과물

1단계 : 요구 사항 분석

요구 사항 분석 단계어서는 조직의 구성원들이 데이터베이스를 사용하는 용도를 파악한다. 즉, 데이터베이스를 사용해 실제 업무를 처리하는 사용자에게서 필요한 데이터의 종류와 처리 방법 같은 다양한 요구 사항을 수집한다. 그 후 요구 사항을 기반으로 명세서를 작성한다.

2단계 : 개념적 설계

개념적 설계 단계에서는 요구 사항 분석 단계에서 파악한 사용자의 요구 사항을 개념적 데이터 모델을 이용해 표현한다. 일반적으로 E-R 다이어그램을 사용한다.

3단계 : 논리적 설계

논리적 설계 단계에서는 개발에 사용할 DBMS에 적합한 논리적 데이터 모델을 이용하여 개념적 설계 단계에서 생성한 개념적 구조를 기반으로 논리적 구조를 설계한다. E-R 다이어그램을 릴레이션(테이블) 스키마로 변환하여 DBMS가 처리할 수 있도록 한다. 논리적 데이터 모델로 표현된 결과물을 논리적 구조 또는 논리적 스키마라고 한다.

4단계 : 물리적 설계

물리적 설계 단계에서는 논리적 설계 단계어서 생성된 논리적 구조를 기반으로 물리적 구조를 설계한다. 저장 장치에 적합한 저장 레코드와 인덱스의 구조등을 설계하고, 저장된 데이터와 인덱스에 빠르게 접근할 수 있는 탐색 기법 등을 정의한다. 물리적 설계의 결과물인 물리적 구조를 내부 스키마 또는 물리적 스키마라고 한다.

5단계 : 구현

구현 단계에서는 이전 설계 결과물을 기반으로 DMBS에서 SQL로 작성한 명령문을 실행하여 데이터베이스를 실제로 생성한다. 이때 사용하는 SQL문은 테이블이나 인덱스 등을 생성할 때 사용되는 데이터 정의어(DDL)이다.

모든 과정이 중요하지만 그중에서도 요구 사항 분석, 개념적 설계, 논리적 설계 단계가 데이터베이스의 설계에 있어서 핵심 단계가 된다.

요구 사항 분석

데이터베이스 설계의 시작인 요구 사항 분석 단계에서는 사용자들의 요구 사항을 수집하고 분석하여 개발할 데이터베이스의 용도를 명확히 파악하는 단계이다. 그리고 그것을 바탕으로 명세서를 작성하여 이후 단계에서 참고를 한다. 사용자의 범위 결정, 해당 사용자의 수행 업무 분석, 업무 데이터 조사등의 작업을 기반으로 명세서를 작성한다.

개념적 설계

개념적 설계에서는 요구 사항 분석 단계의 결과물을 개념적 데이터 모델을 이용하여 표현한다. 개념적 데이터 모델은 요구 사항 분석에 대한 결과물을 바탕으로 데이터베이스에 저장해둘 필요가 있다고 판단되는 데이터 요소를 추출하여 이들관의 관계를 표현한 것이며 이를 보통 개념적 구조 또는 개념적 스키마라고 하며 대표적으로 E-R 다이어그램이 있다. 보통 개체와 속성 추출, 관계 추출, E-R 다이어 그램 작성의 순서대로 진행이 된다.

개체와 속성 추출

요구 사항 명세서에서 개체와 개체의 속성을 추출한 최종 결과 예시

개념적 설계 단계에서 가장 먼저 수행하는 작업은 요구 사항 분석 단계의 결과물인 명세서에서 개체를 추출하는 작업이다. 개체는 저장할 만한 가치가 있는 중요 데이터를 지닌 사람이나 사물이며 개념적 모델링에서 중요한 요소이며 개체 부터 결정이 되어야 속성과 관계도 결정할 수 있게 된다. 보통 명세서의 명사를 기준으로 개체와 속성으로 나눌 수 있다.

관계 추출

요구 사항 명세서에서 관계와 관계의 속성을 추출한 최종 결과 예시

개체와 속성을 추출하고 나면 개체 간의 관계를 결정할 수 있다. 관계는 개체간의 연관성으로써 보통 명세서 기준 동사로 나타내어 진다. 관계를 추출한 후에는 추출한 관계에 대해 매핑 카디널리티와 참여 특성을 결정한다. 즉, 개체 인스턴스의 개수를 기준으로 일대일, 일대다, 다대다 등을 결정하고 필수참여인지 선택탐여인지를 결정한다.

E-R 다이어그램 작성

요구 사항 명세서의 E-R 다이어그램 예시

데이터베이스에 대한 요구 사항 명세서에서 추출한 개체, 속성, 관계를 하나의 E-R 다이어그램으로 개념적 모델링하여 최종적으로 나타낼수 있다. 즉, 개념적 설계 단계의 결과물인 개념적 스키마이다.

논리적 설계

논리적 설계 단계에서는 DBMS에 적합한 논리적 데이터 모델을 이용하여, 개념적 설계 단계에서 생성한 개념적 스키마를 기반으로 논리적 스카마를 설계한다. 즉, DBMS에 독립적인 개념적 스키마를 기반으로 하여 개발에 사용할 DBMS가 처리할 수 있는 데이터베이스의 논리적 구조를 설계한다. 개념적 설계 단계에서의 결과물인 E-R 다이어그램을 관계 데이터 모델의 릴레이션 스키마, 즉 테이블 스키마로 변환하는 작업을 한다.

다만 E-R 다이어그램에 표현된 개체와 관계는 릴레이션으로 표현하는 방법이 다르다. 따라서 릴레이션 스키마로 변화하는 방법을 5가지로 규칙화하여 변환한다.

릴레이션 스키마 변환 규칙

규칙 1 : 모든 개체는 릴레이션으로 변환한다

개체를 릴레이션으로 변환하는 규칙을 적용한 예

E-R 다이어그램의 각 개체를 하나의 릴레이션으로 변환한다. 개체의 이름을 릴레이션의 이름으로 하고, 개체가 가진 속성도 릴레이션의 속성으로 그대로 변환한다. 단, 개체가 가지고 있는 속성이 복합 속성인 경우에는 복합 속성을 구성하고 있는 단순 속성만 릴레이션의 속성으로 변환한다.

규칙 2 : 다대다(N:M) 관계는 릴레이션으로 변환한다

다대다 관계를 릴레이션으로 변환하는 규칙을 적용한 예

E-R 다이어그램에 있는 다대다 관계를 하나의 릴레이션으로 변환한다. 관계의 이름을 릴레이션으로 하고, 관계의 속성도 릴레이션의 속성으로 그대로 변환한다. 단, 관계를 맺고 있는 개체가 무엇인지 중요하므로, 관계를 맺고 있는 개체들을 릴레이션으로 변환후 그 릴레이션들의 기본키를 관계 릴레이션에 포함시키고 외래키로 지정한다.

규칙 3 : 일대다(1:N) 관계는 외래키로 표현한다

일반적인 개체가 참여하는 일대다 관계를 외래키로 표현하는 규칙을 적용한 예

E-R 다이어그램에 있는 일대다 관계는 릴레이션으로 변환하지 않고 외래키로만 표현한다. 즉, 관계를 맺고 있는 개체들을 릴레이션으로 변환후 그 릴레이션의 기본키를 가져와 N측 개체 릴레이션에 포함시키고 외래키로 지정한다. 다만 위의 예시와 같은 일반적인 개체에서가 아니라 약한 개체와 강한 개체의 관계, 즉 예를 들면 비행기(강한 개체)와 좌석(약한 개체)의 경우 동일하게 약한개체의 릴레이션에서 외래키를 가지지만 기본키를 정할때 이 외래키를 포함하여 기본키를 정한다. 약한 개체는 강한 개체에 따라 존재 여부가 결정되는 만큼 강한 개체의 기본키를 이용해 식별을 하게 된다.

규칙 4 : 일대일(1:1) 관계는 외래키로 표현한다

일반적인 일대일 관계를 외래키로 표현하는 규칙을 적용한 예

일대일 관계에 모든 개체가 필수적으로 참여하여 릴레이션을 통합하는 예

E-R 다이어그램에 있는 일대일 관계도 일대다 관계처럼 릴레이션으로 변환하지 않고 외래키로만 표현한다. 관계를 맺는 개체들을 릴레이션으로 변환후 변환한 릴레이션들이 서로의 기본키를 주고받아 이를 외래키로 지정한다. 이때 관계가 가지는 속성들은 관계에 참여하는 개체를 변환한 릴레이션에 모두 포함시킨다. 다만 참여 특성을 고려한다면 한쪽 릴레이션에만 가지고 있는 경우도 있다. 또한 두 릴레이션에서 모두 필수적이면 두 개체에 해당하는 두 릴레이션을 하나로 합쳐 새로운 릴레이션에서 외래키를 가지는 형태를 만들 수 있다.

규칙 5 : 다중 값 속성은 릴레이션으로 변환한다

다중 값 속성을 릴레이션으로 변환하는 규칙을 적용한 예

관계 데이터 모델의 릴레이션에서는 다중 값을 가지는 속성을 허용하지 않는다. 그러므로 E-R 다이어그램에 있는 다중 값 속성은 그 속성을 가지고 있는 개체에 해당하는 릴레이션이 아닌 별도의 릴레이션을 만들어 포함시킨다. 새로 만들어진 릴레이션에는 E-R 다이어그램에서 다중 값 속성으로 표현된 속성분 아니라 그 속성을 가지고 있는 개체이 해당하는 릴레이션의 기본키를 가져와 포함시키고 이를 외래키로 지정한다.

기타 고려 사항

기본 변환 규칙에서는 다대다 관계만 릴레이션으로 변환하였지만 일대일, 일대다 관계도 릴레이션으로 변환할 수 있다. 특히 속성이 많은 관계는 관계 유형에 상관없이 릴레이션으로 변환하는 것을 고려할 수 있다. 그리고 추가적으로 개체가 자기 자신과 관계를 맺는 순환 관계도 기본 규칙을 그래도 적용하면 된다.

릴레이션 스키마 변환 규칙을 이용한 논리적 설계

논리적 설계를 위해 E-R 다이어그램을 릴레이션 스키마로 변환할 때는 위의 변환 규칙을 순서대로 적용하면 된다. 그 결과 위의 E-R 다이어그램을 토대로 다음과 같은 릴레이션을 얻을 수 있다.

릴레이션 스키마 변환 규칙이 적용된 예시

즉 위의 E-R 다이어그램은 논리적 모데링 과정을 통해 릴레이션 스키마로 변환이 된다. 다섯 가지의 변환 규칙을 순서대로 적용하여 최종적으로 변환된 릴레이션 스키마에 대해 속성의 데이터 타입과 길이, 널 값 허용 여부, 기본값, 제약조건 등을 결정하는 것 또한 논리적 설계 단계에서 수행하는 작업이다.

릴레이션 스키마의 테이블 명세서

따라서 릴레이션 스키마를 기준으로 위와 같은 테이블 명세서 작업이 최종적으로 필요하다.

물리적 설계와 구현

논리적 설계 단게에서 릴레이션 스키마의 설계를 완료하면, 물리적 설계 단계에서는 하드웨어나 운영체제의 특성을 고려하여 필요한 인덱스의 구조나 내부 저장 구조 등에 대한 물리적인 설계를 하고 DDL을 이용하여 SQL을 실행시켜 실세 데이터베이스 생성을 한다.

데이터베이스 개론 - 교보문고

www.kyobobook.co.kr

[데이터베이스 개론] 07장. 데이터베이스 언어 SQL

프로그래민 — Tue, 25 Jan 2022 00:35:38 +0900

SQL의 소개

SQL(Structured Query Language)은 관계 데이터베이스를 위한 표준 질의어로 사용되는 언어로써 사용자가 처리하길 원하는 데이터가 무엇인지만 제시하고 데이터를 어떻게 처리해야하지를 언급할 필요가 없는 비절차적 데이터 언어의 특징을 가진다. 즉, SQL은 데이터베이스 관리 시스템에 직접 접근하여 대화식으로 질의를 작성하거나, Java 같은 어로 작성된 응용 프로그램에도 삽입해서 사용할 수 있다. SQL은 기능에 따라 데이터 정의어(DDL), 데이터 조작어(DML), 데이터 제어어(DCL)로 나눌수 있다.

SQL의 분류

데이터 정의어는 테이블을 생성하고 변경, 제거하는 기능을 제공하고, 데이터 조작어는 테이블에 데이터를 삽입하거나, 저장된 데이터를 수정, 삭제, 검색하는 기능을 제공한다. 데이터 제어어는 보안을 위해 접근 및 사용 권한을 부여하거나 취소하는 기능을 제공한다.

SQL을 이용한 데이터 정의

SQL의 데이터 정의 기능

SQL의 데이터 정의 기능은 테이블 생성, 생성된 테이블 구조의 변경, 테이블 삭제로 분류할 수 있다.

테이블의 생성

CREATE TABLE 테이블이름 (
	속성이름 데이터타입 [NOT NULL] [DEFAULT 기본값]
	[PRIMARY KEY (속성 또는 속성리스트)]
	[UNIQUE KEY (속성 또는 속성리스트)]
	[FOREIGN KEY (속성 또는 속성리스트) REFERENCES 테이블이름(속성 또는 속성리스트)
		[ON DELETE 옵션] [ON UPDATE 옵션]]
	[CONSTRAINT 이름] [CHECK(조건)]
);

테이블을 생성하는 SQL 명령어는 CREATE TABLE이다. CREATE TABLE문은 생성할 테이블을 구성하는 속성들의 이름과 데이터 타입 및 제약 사항에 대한 정의, 기본키, 대체키, 외래키의 정의, 데이터 무결성을 위한 제약 조건의 정의 등을 포함한다. 기본 형식에서는 테이블을 구성하는 속성의 이름과 데이터 타입, 제약사항을 정의한다.

속성의 정의

속성의 데이터 타입

CREATE TABLE 문에서는 각 속성의 특성을 고려하여 적절한 데이터 타입을 정의해야 한다. 속성의 타입에는 위의 표와 같은 것들이 존재하고 추가적으로 CREATE TABLE 문에서는 기본적으로 NULL을 허용하기 때문에 NULL을 허용하지 않기위해 NOT NULL을 선언해줘야 한다.

키의 정의

CREATE TABLE 문에서는 테이블을 정의할 때 기본키, 대체키, 외래키를 지정할 수 있다. 기본키 같은 경우 PRIMARY KEY 키워드를 사용하여 지정한다. 기본키는 각 투플을 유일하게 식별하는 특성을 지니며 모든 테이블에서 기본키는 반드시 하나지정해야 하고, 하나또는 여러개의 속성으로 구성할 수 있다. 대체키의 경우 UNIQUE 키워드를 사용하여 지정한다. 대체키는 기본키와 같이 투플을 유일하게 식별하는 특성을 가지고 있지만 기본키와 달리 NULL 값을 가질 수 있다. 외래키의 경우 FOREIGN KEY 키워드를 사용하여 지정한다. 외래키를 지정할 때는 어떤 테이블의 무슨 속성을 참조하는지 REFERNCES 키워드를 이용하여 출처를 명확히 밝혀야 한다. 추가적으로 다음과 같은 키워드를 이용하여 참조되는 테이블에서 투플을 삭제하거나 변경할때 처리하는 방법을 선택할 수 있다.

ON UPDATE/DELETE NO ACTION : 투플을 변경,삭제하지 못하게 한다.
ON UPDATE/DELETE CASCADE : 관련 투플을 함께 변경,삭제 한다.
ON UPDATE/DELETE SET NULL : 관련 투플의 외래키 값을 NULL로 변경한다.
ON UPDATE/DELETE SET DEFAULT : 관련 투플의 외래키 값을 미리 지정한 기본값으로 변경한다.

데이터 무결성 제약조건의 정의

CREATE TABLE 문으로 테이블을 정의할ㄷ 때 CHECK 키워드를 사용하여 특정 속성애 데한 제약 조건을 지정할 수 있다. 또한 CHECK 키워드를 사용해 지정한 제약조건에 CONSTRANINT 키워드와 함께 고유의 이름을 부여할 수도 있다.

테이블의 변경

ALTER TABLE 테이블이름 ADD 속성이름 데이터타입 [NOT NULL] [DEFAULT 기본값];
ALTER TABLE 테이블이름 DROP COULMN 속성이름;
ALTER TABLE 테이블이름 ADD CONSTRAINT 제약조건이름 제약조건내용;
ALTER TABLE 테이블이름 DROP CONSTRAINT 제약조건이름;

테이블은 ALTER TABLE 문으로 변경할 수 있다. ALTER TABLE 문을 이용해 새로운 속성 추가, 기존 속성 삭제, 새로운 제약조건 추가, 기존 제약조건 삭제 등이 가능하다.

테이블의 삭제

DROP TABLE 테이블이름;

CREATE TABLE 문으로 생성한 테이블은 DROP TABLE 명령어로 삭제할 수 있다.

SQL을 이용한 데이터 조작

SQL의 데이터 조작 기능

SQL의 조작 기능은 SELECT를 이용한 데이터 검색, INSERT를 이용한 데이터 삽입, UPDATE를 이용한 데이터 수정, DELETE를 이용한 데이터 삭제로 분류할 수 있다.

데이터의 검색

SELECT [ALL | DISTINCT] 속성리스트
FROM 테이블리스트
[WHERE 조건]
[GROUP BY 속성리스트 [HAVING 조건]]
[ORDER BY 속성리스트 [ASC | DESC]]

테이블에서 원하는 데이터를 검색하기 위해 필요한 SQL문은 SELECT이다. 가장 기본적으로는 SELECT, FROM 두개의 키워드를 사용하여 데이터를 검색할 수 있고, 추가적으로 WHERE 키워드와 조건을 이용할 수 있다. 위와 같은 형태에서 SQL 실행 순서는 FROM-WHERE-GROUP BY-HAVING-SELECT-ORDER BY의 순서를 가진다.

조건 검색

대표적인 조건 연산자에는 다음과 같은 것이 있다.

비교 연산자와 논리 연산자

위와 같은 비교 연산자와 논리 연산자를 활용하여 WHERE 키워드에 적절한 속성 조건을 추가할 수 있다. 또한 추가적으로 문자열 검색 조건에 있어서 LIKE 키워드를 할용할 수 도 있다.

LIKE 키워드의 사용 예

그리고 NULL 값에 대한 조건에 있어서 IS NULL 또는 IS NOT NULL 등을 활용할 수 있다.

집계 함수를 이용한 검색

특정 속성 값을 통계적으로 계산한 결과를 검색하기 위해 집계함수를 이용할 수 있다. 집계함수는 개수, 합계, 평균, 최댓값, 최솟값의 계산 기능을 제공한다. 다음과 같은 키워드들이 있다.

집계 함수

집계 함수를 사용할땐 다음 두가지 사항에 주의해야한다. 첫째로 집계함수는 널인 속성 값은 제외하고 계산을 한다. 둘째로 집계 함수는 WHERE 절에서는 사용할 수 없고 SELECT 절이나 HAVING 절에서만 사용할 수 있다.

그룹별 검색

테이블에서 특정 속성의 값이 같은 투플을 모아 그룹을 만들고, 그룹별로 검색을 하기 위해 GROUP BY 키워드를 사용한다. 그룹에 대한 조건을 추가하려면 HAVING 키워드를 추가적으로 사용할 수 있다.

여러 테이블에 대한 조인 검색

여러 개의 테이블을 연결하여 데이터를 검색하는 것을 조인 검색이라고 하며 조인 검색을 하기 위해서는 테이블을 연결해주는 속성이 필요하고 이 속성을 조인 속성이라고 한다. 조인속성의 이름은 달라도 되지만 도메인은 같아야 한다. 일반적으로는 테이블의 관계를 나태나는 외래키를 조인 속성으로 이용한다.

부속 질의문을 이용한 검색

SELECT 문 안에 다른 SELECT 문을 부속 질의문 또는 서브 질의문이라고 한다. 부속 질의문은 괄호로 묶어 작성하고 ORDER BY 키워드를 사용할 수 없고, 상의 질의문보다 먼저 수행된다. 부속 질의문을 이용한 검색은 이어 달리기처럼 부속 질의문을 먼저 수행하고, 그 결과를 이용해 상위 질의문을 수행하여 최종 결과 테이블을 반환한다. 부속 질의문은 하나의 행을 결과로 반환하는 단일 행 부속 질의문과 하나 이상의 행을 결과로 반환하는 다중 행 부속 질의문으로 분류한다. 다만 이때, 단일 행 부속 질의문은 일반 비교 연산자를 사용할 수 있지만, 다중 행 부속 질의문은 일반 비교 연산자를 사용할 수 없다.

다중 행 부속 질의문에는 다음과 같은 연산자들을 활용할 수 있다.

다중 행 부속 질의문에 사용 가능한 연산자

데이터의 삽입

테이블에 새로운 투플을 삽입하기 위해 필요한 SQL문은 INSERT이다. INSERT 문을 이용하여 테이플에 투플을 직접 삽입할 수도 있고, 부속 질의문을 이용해 투플을 삽입할 수 도 있다.

데이터 직접 삽입

INSERT
INTO 테이블이름[(속성리스트)]
VALUES (속성값리스트);

테이블에 투플을 직접 삽입하는 INSERT 문의 기본 형식은 위와 같다. INTO 키워드와 함께 투플을 삽입할 테이블 이름을 제시 후 속성의 이름을 나열하여 VALUES 키워드와 순서대로 대응대도록 입력한다. 이때 INTO 절의 속성리스트와 VALUES 절의 속성값리스트는 일대일로 대응이 되어야한다. 다만 INTO 절에서 속성리스트는 생략할 수 있는데 생략하면 테이블을 정의할 때 지정한 속성의 순서대로 VALUES 절의 속성 값이 삽입된다.

부속 질의문을 이용한 데이터 삽입

INSERT
INTO 테이블이름[(속성리스트)]
SELECT 문;

부속 질의문인 SELECT 문을 이용하여 다른 테이블에서 검색한 데이터를 투플로 삽입하는 INSERT문의 기본형식의 위와 같다.

데이터의 수정

UPDATE 테이블이름
SET 속성1=속성값1, 속성2=속성값2, ...
[WHERE 조건];

테이블에 저장된 데이터를 수정하기 위해 필요한 SQL문은 UPDATE 문으로써 기본 형식은 위와 같다. UPDATE 문은 테이블에 저장된 투플에서 특정 속성의 값을 수정할 때 사용되면 WHERE 절을 이용하여 조건을 제시할 수 있다. 다만 WHERE 절이 없다면 모든 투플이 대상이 된다.

데이터의 삭제

DELETE
FROM 테이블이름
[WHERE 조건];

테이블에 저장된 데이터를 삭제하기 위해 필요한 SQL문은 DELETE 문으로써 기본 형식은 위와 같다. DELETE 문은 WHERE 절에 제시한 조건을 만족하는 투플을 삭제하는데, WHERE 절을 생략하면 모든 투플을 삭제하여 빈테이블이 된다.

뷰

뷰의 개념

뷰는 다른 테이블을 기반으로 만들어진 가상 테이블이다. 뷰가 가상 테이블인 이유는 일반 테이블과 달리 실제로 데이터를 저장하고 있지 않기 때문이다. 뷰는 CREATE TABLE 문으로 생성한 테이블 또는 다른 뷰를 기반으로 생성할 수 있다. 뷰를 통해서 기본 테이블의 내용을 쉽게 검색할 수 있지만 기본 테이블의 내용을 바꾸는 제한은 제한적으로 이루어진다.

뷰의 생성

CREATE VIEW 뷰이름[(속성리스트)]
AS SELECT 문
[WITH CHECK OPTION];

뷰를 생성하기 위해 필요한 SQL 명령어는 CREATE VIEW이고 기본 형식은 위와 같다. CREATE VIEW 명령어와 함께 새로 생성할 뷰의 이름을 제시한 후 뷰를 구성하는 속성의 이름을 괄호 안에 나열한다. 그 후 AS 키워드와 함께 기본 테이블에 대한 SELECT 문을 제시한다. WITH CHECK OPTION은 생성한 뷰에 삽입이나 수정 연산을 할 때 SELECT 문에서 제시한 뷰의 정의 조건을 위반하면 수행되지 않도록 하는 제약조건이다.

뷰의 활용

CREATE VIEW 문으로 생성된 뷰에서도 일반 테이블처럼 원하는 데이터를 검색할 수 있다. 뷰에 대한 SELECT 문이 내부적으로는 기본 테이블에 대한 SELECT 문으로 변환되어 수행이 된다. 따라서 INSERT, UPDATE, DELETE 연산또한 뷰를 대상으로 수행할 수 있고, 이 연산은 기본 테이블에도 반영이 된다. 따라서 뷰에 대한 삽십, 삭제, 수정 연산은 주의해야한다.

다만 삽입, 삭제, 수정 여산이 모든 뷰에 허용되는 것이 아니라 제한적이다. 기본 테이블에서 어떤 투플을 어떻게 변경해야 할지 명확히 제시하지 못하는 뷰는 변경이 허용되지 않는다. 즉 다음과 같은 것들이 있다.

기본 테이블의 기본키를 구서하는 속성이 포함되어 있지 않은 뷰는 변경할 수 없다.
기본 테이블에 있던 내용이 아니라 집계함수로 새로 계산된 내용을 포함하고 있는 뷰는 변경할 수 없다.
DISTINCT 키워드를 포함하여 정의한 뷰는 변경할 수 없다.
GROUP BY 절을 포함하여 정의한 뷰는 변경할 수 없다.
여러 개의 테이블을 조인하여 정의한 뷰는 변경할 수 없는 경우가 많다.

다만 이러한 제약조건에도 뷰는 다음과 같은 장점이 있다.

질의문을 좀 더 쉽게 작성할 수 있다.
데이터의 보안 유지에 도움이 된다.
데이터를 좀 더 편리하게 관리할 수 있다.

뷰의 삭제

DROP VIEW 뷰이름;

뷰를 삭제하기 위한 SQL 명령어는 DROP VIEW이고, 기본 형식은 위와 같다. 뷰를 삭제하더라도 기본 테이블은 영향을 받지 않는다. 그리고 삭제할 뷰를 참조하는 제약조건이 존재하면 삭제가 수행되지 않기에 제약조건을 우선 제거해야한다.

삽입 SQL

삽입 SQL의 개념과 특징

C, JAVA 등과 같은 프로그래밍 언어로 작성된 응용 프로그램 안에 삽입하여 사용하는 SQL 문을 삽입 SQL(Embedded SQL, ESQL)이라고 한다. 다음과 같은 특징이 있다.

삽입 SQL 문은 프로그램 안에서 일반 명령문이 위치할 수 있는 곳이면 어디든 삽입할 수 있다.
프로그램 안의 일반 명령문과 구별하기 위해 삽입 SQL 문 앞에 EXEC SQL을 붙인다.
프로그램에 선언된 일반 변수를 삽입 SQL 문에서 사용할 수 있다. 단, SQL 문에서 일반 변수를 사용할 때는 앞에 콜론(:)을 붙여 테이블 이름이나 속성의 이름과 구분한다.

수행 결과로 여러개의 행을 반환하는 SELECT 문을 삽입 SQL 문으로 사용하는 경우에서는 커서(Cursor)라는 도구가 필요하다. 커서는 수행 결과로 반환된 여러 행을 한번에 하나씩 가리키는 포인터 역할을 한다.

커서가 필요 없는 삽입 SQL

SQL 문을 실행했을 때 특별히 결과 테이블을 반환하지 않는 CREATE TABLE, INSERT, DELETE, UPDATE, 결과로 행 하나만 반환하는 SELECT 문은 커서가 필요없다. 삽입 SQL 문에서 사용할 변수는 미리 선언해야 하는데, 이는 BEGIN DECLARE SECTION 문장과 END DECLARE SECTION 문장사이에 선언하면 된다.

커서가 필요한 삽입 SQL

SELECT 문의 실행 결과로 여러 행이 검색되는 경우에는 한 번에 한행씩 차례로 접근할 수 있게 해주는 커서가 필요하다. 커서를 사용하기 전에 커서의 이름과 커서가 필요한 SELECT 문을 선언해야한다.

EXEC SQL DECLARE 커서이름 CURSOR FOR SELECT 문;

커서를 선언하는 삽입 SQL 문의 기본 형식은 위와 같다. 커서를 선언한 후에는 SELECT 문을 실행하는 명령이 필요하다.

EXEC SQL OPEN 커서이름;

커서에 연결된 SELECT 문을 실행하는 삽입 SQL의 기본 형식은 위와 같다. 그 후 검색된 행들을 차례로 처리하기 위해 커서를 이동시키는 명령어는 FETCH이다.

EXEC SQL FETCH 커서이름 INTO 변수리스트;

커서리를 이동해 처리할 다음 행을 가리키도록 하고, 커서가 가르키는 행으로부터 속성 값들을 가져와 변수에 저장하는 FETCH 문의 기본 형식은 위와 같다.

EXEC SQL CLOSE 커서이름;

커서를 종료하는 CLOSE 문의 기본 형식은 위와 같다.

데이터베이스 개론 - 교보문고

www.kyobobook.co.kr

[데이터베이스 개론] 05장. 관계 데이터 모델

프로그래민 — Sat, 22 Jan 2022 16:02:48 +0900

관계 데이터 모델의 개념

관계 데이터 모델의 기본 용어

릴레이션의 예 : 고객 릴레이션

일반적으로 관계 데이터 모델에서는 하나의 개체에 관한 데이터를 릴레이션 하나에 담아 데이터베이스에 저장한다. 릴레이션과 관련된 용어로는 다음과 같은 것들이 있다.

속성 : 릴레이션의 열을 속성 또는 애트리뷰트라고 한다. 각 속성은 다름 이름을 이용해 구별한다. 릴레이션은 파일 관리 시스템에서의 파일, 속성은 해당 파일의 필드에 대응하는 개념이다.
투플 : 릴레이션의 행을 투플이라고 한다.투플은 파일 관리 시스템 관점에서 해당 파일의 레코드에 대응하는 개념이다.
도메인 : 속성 하나가 가질 수 있는 모든 값의 집합을 해당 속성의 도메인이라 한다. 속성값은 더이상 나눌 수 없는 원자값이기에 도메인을 특정 속성이 가질 수 있는 모든 원자값의 모임이라고도 한다. 다만 나이같은 경우 도메인으로 나타낼때 모든 속성값을 나열하기 힘들기에 정수타입이라고 도메인을 정의하기도 한다.
널 값 : 릴레이션에 있는 특정 투플의 속성 값을 모르거나, 적합한 값이 없는 경우에는 널이라는 특별한 값을 사용할 수 있다.
차수 : 하나의 릴레이션에서 속성의 전체 개수를 릴레이션의 차수라고 한다.
카디널리티 : 하나의 릴레이션에서 투플의 전체 개수를 릴레이션의 카디널리티라고한다.

릴레이션과 데이터베이스의 구성

릴레이션 구성의 예 : 고객 릴레이션

관계 데이터 모델에서 릴레이션은 릴레이션 스키마와 릴레이션 인스턴스로 구성된다.

릴레이션 스키마 : 릴레이션 스키마는 릴레이션의 이름과 릴레이션에 포함된 모든 속성의 이름으로 정의하는 릴레이션의 논리적 구조이다. 릴레이션 내포라고도 한다.
릴레이션 인스턴스 : 릴레이션 인스턴스는 어느 한 시점에 릴레이션에 존재하는 투플들의 집합이다. 릴레이션 인스턴스는 간단히 릴레이션이 또는 릴레이션 외연이라고도 한다.
데이터베이스 스키마와 데이터베이스 인스턴스 : 일반적으로 데이터베이스는 여러개의 릴레이션으로 구성되어있다. 데이터베이스의 전체 구조를 의미하는 데이터베이스 스키마는 데이터베이스를 구성하는 릴레이션들의 스키마를 모아놓은 것이다. 데이터베이스 인스턴스는 어느 한 시점에서 데이터베이스에 저장된 데이터 내용의 전체 집합이다.

릴레이션의 특성

관계 데이터 모델의 릴레이션에는 네가지 특성이 존재하고, 네가지 특성을 만족해야지 테이블이 릴레이션으로 인정 받을 수 있다.

투플의 유일성 : 하나의 릴레이션에는 동일한 투플이 존재할 수 없다는 특성이다. 즉, 하나의 릴레이션에 똑같은 투플이 있으면 안되고, 모든 투플에는 다른 투플과 구별되는 유일한 특성이 있어야한다.
투플의 무순서 : 하나의 릴레이션에서 투플 사이의 순서는 무의미하다는 특성이다. 즉, 투플 순서가 바뀐다고 다른 릴레이션이 될 수 없고, 순서와 상관없이 투플 내용이 같으면 동일한 릴레이션이 된다.
속성의 무순서 : 하나의 릴레이션에서 속성 사이의 순서는 무의미하다는 특성이다. 즉, 속성의 순서가 바뀌어도 다른 릴레이션이 될 수 없고, 순서와 상관없이 같은 속성들로 구성되어야 동일한 릴레이션이 된다.
속성의 원자성 : 속성값으로 원자 값만 사용할 수 있다는 특성이다. 즉, 모든 속성 값은 더는 분해할 수 없는 하나의 값만 가지며 여러개의 값, 다중 값을 가질 수 없다.

키의 종류

릴레이션에 포함된 투플들을 유일하게 구별해주는 역할을 키로 할 수 있다. 키는 관계 데이터 모델에서 중요한 제약조건을 정의해준다. 다음과 같은 5종류의 키가 있다.

키의 관계

슈퍼키 (Super Key) : 슈퍼키는 유일성의 특성을 만족하는 속성 또는 속성들의 집합이다. 유일성은 키가 갖추어야할 기본 특성중 하나로써 하나의 릴레이션에서 키로 지정된 속성 값은 투플마다 달라야한다는 특성이다.
후보키 (Candiadte Key) : 후보키는 유일성과 최소성을 만족하는 속성 또는 속성드의 집합이다. 최소성은 꼭 필요한 최소한의 속성들로만 키를 구성하는 특성이다. 후보키는 투플을 유일하게 구별하기 위해 꼭 필요한 최소한의 속성들로만 이루어지므로 슈퍼키 중에서 최소성을 만족하는 것이 후보키가 된다.
기본키 (Primary Key) : 여러 후보키 중에서 기본적으로 사용할 키를 반드시 선택해야하는데 이를 기본키라고 한다. 기본키는 다음과 같은 기준을 가진다. 1 - 널 값을 가질 수 있는 속성이 포함된 후보키는 기본키로 부적합하다. 2- 값이 자주 변경될 수 있는 속성이 포함된 후보키는 기본키로 부적합하다. 3- 단순한 후보키를 기본키로 선택한다.
대체키 (Alternate Key) : 대체키는 기본키로 선택되지 못한 후보키들이다.
외래키 (Foreign Key) : 외래키는 어떤 릴레이션에 소속된 속성이 다른 릴레이션의 기본키가 되는 키다. 즉, 다른 릴레션의 기본키를 그대로 참조하는 속성을 외래키라고 한다. 다만 외래키가 다른 릴레이션의 기본키를 참조하지 않고 유일성과 최소성을 만족하는 대체키를 참조할 수 도 있다.

관계 데이터 모델의 제약

관계 데이터 모델의 무결성 제약조건

관계 데이터 모델에서 정의하고 있는 기본 제약 사항은 키와 관련한 무결성 제약조건이 있다. 무결성은 데이터에 결함이 없는 상태, 즉 데이터가 정확하고 유효하게 유지된 상태이다. 무결성 제약조건은 어느 시점에 데이터베이스에 저장된 데이터가 항상 지켜야하는 중요한 규칙이다. 관계 데이터 모델이 기본으로 포함하고 있느 무결성 제약조건에는 개체 무결성 제약조건과 참조 무결성 제약조건이 있다.

개체 무결성 제약조건

개체 무결성 제약조건은 기본키를 구성하는 모든 속성은 널값을 가지면 안되는 규칙이다. 기본키를 구성하는 속성 전체나 일부가 널 값이 되면 투플의 유일성을 판단할 수 없어 기본키의 원래 목적을 상실하게 된다.

참조 무결성 제약조건

참조 무결성 제약조건은 외래키는 참조할 수 없는 값을 가질 수 없는 규칙이다. 외래키가 자신이 참조하는 릴레이션의 기본키와 상관이 없는 값을 가지게 되면 두 릴레이션을 연관시킬 수 없으므로 외래키 본래의 의미가 없어진다. 그렇기에 왜리키는 자신이 참조하는 릴레이션에 기본키 값으로 존재하는 값, 즉 참조 가능한 값만 가져야 한다.

데이터베이스 개론 - 교보문고

www.kyobobook.co.kr

[데이터베이스 개론] 04장. 데이터 모델링

프로그래민 — Mon, 17 Jan 2022 02:19:26 +0900

데이터 모델링과 데이터 모델의 개념

현실 세계에 존재하는 데이터를 컴퓨터 세계의 데이터베이스로 옮기는 변환 과정을 데이터 모델링이라고 한다. 현실 세계에서 중요 데이터를 추출하여 개념 세계로 추상화하는 작업을 데이터 모델링 과정 중에서 개념적 모델링이라고 한다. 그리고 개념 세계의 데이터를 데이터베이스에 저장할 구조를 결정하고 이 구조로 표현하는 작업을 논리적 모델링이라고 한다.

데이터 모델은 데이터 모델링의 결과물을 표현하는 도구로, 개념적 데이터 모델관 논리적 데이터 모델이 있다. 개념적 데이터 모델은 사람의 머리로 이해할 수 있또록 현실 세계를 개념적 모델링하여 데이터베이스의 개념적 구조로 표현하는 도구다. 논리적 데이터 모델은 개념적 구조를 논리적 모델링하여 데이터베이스의 논리적 구조로 표현하는 도구다. 논리적 데이터 모델링과 개념적 데이터 모델링을 통틀어 데이터베이스 설계라한다.

데이터 모델은 데이터 구조, 연산, 제약조건으로 구성된다. 데이터 구조는 현실 세계를 개념 세계로 추상화했을 때 어떤 요소로 이루어져 있는지를 표현하는 개념적 구조다. 연산은 값들을 처리하는 작업이다. 제약조건은 제약사항이다.

개념적 데이터 모델 중 대표적으로 많이 사용되는 것이 개체-관계 모델(ER Model)이고, 논리적 데이터 모델로는 관계 데이터 모델이 이다.

개체-관계 모델

개체-관계 모델은 개체와 개체 간의 관계를 이용해 현실 세계를 개념적 구조로 표현하는 방법이다. E-R 다이어그램이라고 한다.

개체

개체 타입과 개체 인스턴스의 예

개체는 저장할 만한 가치가 있는 중요 데이터를 가지고 있는 사람이나 사물이다. 개체는 각 개체만의 고유한 특성이나 상태, 속성을 하나씩 가진다. 개체를 고유의 이름과 속성들로 정의한 것을 개체 타입이라 한다. 개체를 구성하고 있는 속성이 실제 값을 가짐으로써 실체화된 개체를 개체 인스턴스라고 한다.

속성

속성은 개체가 가지고 있는 고유의 특성이다. 속성은 일반적으로 의미 있는 데이터의 가장 작은 논리적 단위이다. 속성은 다양한 기준으로 분류할 수 있다.

단일 값 속성과 다중 값 속성

특정 개체를 구서하는 속성의 값이 하나면 단일 값 속성이다. 이와 달리 속성이 값을 여러 개 가질 수 있으면 다중 값 속성이다.

단순 속성과 복합 속성

단순 속성은 의미를 더는 분해할 수 없는 속성이다. 단순 속성의 값은 의미가 하나이다. 반면 복합 속성은 의미를 분해할 수 있어 값이 여러개의 의미를 포함한다. 복합 속성은 단일 속성이 여러개 모여 만들어진 속성으로 볼 수 있다.

유도 속성

값이 별도로 저장되는 것이 아니라 기존의 다른 속성 값에서 유도되어 결정되는 속성을 유도 속성이라 한다.

널 속성

아직 결정되지 않은 모르는 값인 널을 허용하는 속성을 널 속성이라고 한다.

키 속성

개체를 구성하는 속성들 중에서 특별한 역할을 키 속성이 수행한다. 모든 개체 인스턴스의 키 속성 값이 다르므르 키 속성은 개체 집합에 존재하는 각 개체 인스턴스들을 식별하는데 사용한다. 키속성의 값이 개체 인스턴스마다 달라서 이값으로 개체 인스턴스를 식별 가능하다는 점이 개체 타입을 정의할때의 중요한 제약조건이다.

관계

관계는 개체와 개체가 맺고 있는 의미 있는 연관성으로써 개체-관계 모델의 중요한 요소이다. 관계를 여러 개체 사이에서 정의되는 관계 타입과 실제 속성 값으로 구성되어 있는 특정 개체 인스턴스들 간에 맺어진 실제 관계인 관계 인스턴스로 구분하여 표현하기도 한다. 또, 관계도 개체처럼 속성을 가질 수 있다.

관계의 유형

관계의 분류 기준은 매핑 원소의 수인 매핑 카디널리티를 기준으로 일대일, 일대다, 다대다 세가지 유형으로 분ㄹ류된다.

일대일 관계는 개체A의 각 객채 인스턴스가 개체B의 인스턴스 하나와 관계를 맺고, 반대로 개체B의 인스턴스 하나와 개체A의 인스턴스 하나가 관계를 맺는 상황을 의미한다. 일대다 관계는 개체A의 각 개체 인스턴스는 개체B의 개체 인스턴스 여러 개와 관계를 맺을 수 있지만, 개체B의 각 개체 인스턴스는 개체A의 인스턴스 하나와 관계를 맺는 상황이다. 다대다 관계는 개체A의 각 개체 인스턴스가 개체B의 개체 인스턴스 여러개와 관계를 맺을 수 있고, 개체B의 각 개체 인스턴스또한 개체A의 개체 인스턴스 여러개와 관계를 맺을 수 있는 상황이다.

관계의 참여 특성

개체A와 B 사이의 관계에서 개체A의 모든 개체 인스턴스가 관계에 참여하면 필수적 참여이고, 일부만 참여하면 선택적 참여이다.

관계의 종속성

두 개체가 관계에 대해 종속정인 특성을 가지는 경우도 있다. 개체B가 독자적으로 재재할 수 없고 다른 개체A의 존재에 의존적이라면 개체B가 개체A에 종속되어 있다고 할 수 있다. 개체B가 개체A에 종속되면, 이는 개체A가 존재해야 개체B가 존재할 수 있고 개체A가 삭제되면 개체B도 함께 삭제되어야 함을 의미한다. 이러한 종속을 특별히 존재 종속이라고 한다. 이때 다른 개체의 존재 여부에 의존적인 개체B를 약한개체라 하고 다른 개체의 존재 여부를 결정하는 개체A를 강한 개체라고 한다. 두 개체가 종속적인 관계를 맺고 있어 약한 개체를 종속 개체로, 강한 개체를 오너 개체로 부른다.

E-R 다이어그램

E-R 다이어그램은 개체-관계 모델을 이용해 현실 세계를 개념적으로 모델링한 결과물을 그림으로 표현한 것이다. E-R 다이어그램은 기본적으로 개체를 표현하는 사각형, 개체 간의 관계를 표현하는 마르모, 개체나 관계의 속성을 표현하는 타원, 각 요소를 연결하는 링크로 구성되고 일대일, 일대다, 다대다 관계를 레이블로 표기한다.

논리적 데이터 모델

논리적 데이터 모델의 개념과 특성

E-R 다이어그램으로 표현된 개념적인 구조를 데이터베이스에 표현하는 형태를 결정하는 논리적 데이터 모델링에서는 데이터베이스 관리 시스템 종류가 중요하다. 논리적 데이터 모델은 논리적 데이터 모델링의 결과물이고, 사용자가 생각하는 데이터베이스의 모습 또는 구조이다. 그리고 논리적 데이터 모델로 표현된 데이터베이스의 논리적 구조가 데이터베이스의 스키마이다. 데이터베이스에 있는 데이터들의 간의 관계를 표현하는 방법에 따라 다양한 논리적 모델이 존재한다.

계층 데이터 모델

계층 데이터 모델은 데이터베이스의 논리적 구조가 트리형태다. 계층 데이터 모델은 개체 사이의 관계를 정의할 때 여러 제약이 존재하기 때문에 개념적 구조를 논리적 구조로 자연스럽게 모델링하기 어려워 구조가 복잡해 질 수 있고, 데이터의 삽입, 삭제, 수정등의 연산이나 원하는 데이터를 검색하기 쉽지 않나든 단점이 있다.

네트워크 데이터 모델

네트워크 데이터 모델은 데이터베이스의 논리적 구조가 그래프 또는 네트워크 형태이다. 네트워크 데이터 모델은 같은 개체들 사이의 관계를 두 개 이상 표현할 수 있어 계층 데이터 모델보다 개념적 구조를 논리적 구조로 좀 더 자연스럽게 모델링할 수 있다. 그러나 계층 데이터 모델보다 구조가 훨씬 복잡해질 수 있어, 데이터의 삽입, 삭제, 수정과 같은 연산과 데이터 검색이 계층 데이터 모델보다 더 어려워지는 문제가 발생한다.

데이터베이스 개론 - 교보문고

www.kyobobook.co.kr

[데이터베이스 개론] 03장. 데이터베이스 시스템

프로그래민 — Sun, 16 Jan 2022 20:00:29 +0900

데이터베이스 시스템의 정의

데이터베이스 시스템은 데이터베이스에 데이터를 저장하고, 저장된 데이터를 관리하여 조직에 필요한 정보를 생성해주는 시스템이다. 다양한 목적의 정보 처리 시스템을 구축하는 데 필요한 핵심요소이다. 데이터의 집합을 데이터베이스라고 하고, 데이터베이스에 저장된 데이터가 일관되고 무결한 상태로 유지되도록 관리하는 역학을 하는 것을 데이터베이스 관리 시스템이라고 한다. 그리고 데이터베이스와 테이터베이스 관리 시스템을 이용해 조직에 필요한 정보를 제공해주는 전체 시스템을 데이터베이스 시스템이라고 한다.

데이터베이스의 구조

스키마 (Schema)

스키마는 데이터베이스에 저장되는 데이터 구조와 제약조건을 정의한 것이다. 그리고 이 스키마에 따라 실제로 데이터베이스에 저장되는 값을 인스턴스라고 한다.

3단계 데이터베이스 구조

3단계 데이터베이스 구조의 개념

3단계 데이터 베이스느 구조는 하나의 데이터베이스를 세 단계로 나누어 이해한다. 개별 사용자 관점에서 바라보는 외부 단계, 조직 전체의 관점에서 바라보는 개념 단계, 물리적인 저장 장치의 관점에서 바라보는 내부 단계로 나눈다. 내부 단계에서 외부 단계로 갈수록 추상화 레벨이 높아진다.

외부 단계

외부 단계에서는 개별 사용자 관점에서 데이터베이스를 이해하고 표현한다. 개별 사용자가 데이터베이스를 어떻게 보는 가를 표현하므로 사용자마다 생각하는 데이터베이스 구조가 다르다. 외부 단계에서 사용자에게 필요한 데이터베이스를 정의한 것을 외부 스키마라고 한다. 외부 스키마는 각 사용자가 생각하는 데이터베이스의 모습을 표현한 논리적 구조이다. 데이터베이스 하나에는 여러 외부 스키마가 존재할 수 있고, 전체 데이터베이스 중 사용자가 관심을 가지는 일부분으로 볼 수 있기에 서브 스키마라고도 한다.

개념 단계

개념 단계 에서는 데이터베이스를 이용자들의 관점을 통합하여 데이터 베이스를 조직 전체의 관점에서 이해하고 표현한다. 개념 단계에서는 데이터베이스 관리 시스템이나 관리자의 관점에서 모든 사용자에게 필요한 데이터를 통합하여 전체 데이터베이스의 논리적 구조를 정의하며 이를 개념 스키마라고 한다. 즉, 개념 스키마는 전체의 관점에서 생각하는 데이터베이스의 모습이며 모든 개별 사용자가 생각하는 데이터베이스의 모습을 하나로 합친 형태이다. 어떤 데이터가 저장되고, 데이터들간 어떤 관계가 있고, 어떤 제약 조건이 있는지, 보안 정책이나 접근 권한은 어떻게 정의되어 있는지 등을 포함한다. 데이터베이스 하나에는 개념 스키마가 하나 있고, 일반적으로 스키마를 개념 스키마라고 한다.

내부 단계

내부 단계에서는 전체 데이터베이스가 저장 장치에 실제로 저장되는 방법을 정의하며 내부 스키마라고 한다. 데이터베이스는 저장 장치에 파일 형태로 저장되는데, 내부 스키마는 파일에 데이터를 저장하는 레코드의 구조, 필드 크기, 인덱스등을 정의한다. 내부 스키마는 데이터베이스에 하나만 존재한다.

데이터 독립성

3단계 데이터베이스 구조에서 스키마 간의 사상

하나의 데이터베이스에는 세가지 유형의 스키마가 존재하지만 각각의 스키마는 데이터베이스를 바라보는 관점만 다르지 모두 같은 데이터베이스를 표현한다. 세가지 스키마 사이에는 유기적인 대응관계가 성립한다. 이렇게 데이터베이스를 3단계 구조로 나누고, 단계별로 스키마를 유지하며 스키마 사이의 대응 관계를 정의하는 궁극적인 목적은 데이터 독립성을 실현한기 위해서이다. 데이터 독립성은 하위 스키마를 변경하더라도 상위 스키마가 영향을 받지 않는 특성이다.

논리적 데이터 독립성

논리적 데이터 독립성은 개념 스키마가 변경되더라도 외부 스키마가 영향을 받지 않는 것이다. 전체 데이터베이스의 논리적인 구조가 변경되어도 관련된 외부/개념 사상(응용 인터페이스) 정보만 적절히 수정해주면 관련이 없는 외부 스키마는 변경할 필요가 없는 성질이다.

물리적 데이터 독립성

물리적 데이터 독립성은 내부 스키마가 변경되더라도 개념 스키마가 영향을 받지 않는 것이다. 결과적으로 외부 스키마도 영향을 받지 않는다. 데이터베이스의 저장 구조가 변경되어도 관련된 개념/내부 사상(저장 인터페이스) 정보만 적절히 수정해주면 직접적으로 관련이 없는 데이터베이스의 논리적 구조는 영향을 받지 않는다.

데이터 사전

데이터베이스는 조직 운영을 위해 필요한 실제 데이터를 저장하는데 이를 관리하고 운영하기 위해 부가 정보또한 저장한다. 대표적인 부가정보로써 스키마와 사상 정보가 잇다. 데이터베이스에 저장되는 데이터에 관한 정보를 저장하는 곳을 데이터 사전 또는 시스템 카탈로그라고 한다. 데이터 사전은 데이터베이스에 저장되어 있는 데이터를 정확하고 효율적으로 이용하기 위해 참고해야 되는 스키마, 사상 정보, 다양한 제약 조건등인 메타데이터를 저장하고 있다. 데이터 사전에 있는 데이터에 실제로 접근한데 필요한 위치 정보는 데이터 디렉토리에서 관리한다.

데이터베이스 사용자

데이터베이스를 이용하는 사용자는 목적에 따라 데이터베이스 관리자, 최종 사용자, 응용 프로그래머로 나눌 수 있다.

데이터베이스 관리자 (Database Adminstrator, DBA)

데이터베이스 관리자는 데이터베이스 시스템을 운영∙관리한다. 사용자를 위해 데이터베이스를 설계 및 구축하고, 제어한다. 데이터 정의어와 데이터 제어어를 이용해 데이터베이스에 접근하기도 한다. 대표적으로 다음과 같은 업무를 한다.

데이터베이스 구성 요소 선정 : 데이터베이스를 구성할 데이터를 결정.
데이터베이스 스키마 정의 : 데이터베이스의 스키마를 설계하고, 데이터 정의어를 통해 스키마를 생성.
물리적 저장 구조와 접근 방법 결정 : 데이터베이스의 레코드 구조를 설계 및 인덱스를 구성할 필드 결정.
무결성 유지를 위한 제약조건 정의 : 데이터베이스에 저장할 수 있는 데이터의 규칙 정의 및 데이터의 정확성 및 유효성 유지.
보안 및 접근 권한 정책 결정 : 허가되지 않은 사용자의 데이터베이스 접근 방지 및 권한 부여 결정.
백업 및 회복 기법 정의 : 시스템 장애를 대비한 데이터베이스 백업 및 복구 방법 정의.
시스템 데이터베이스 관리 : 데이터 사전 관리.
시스템 성능 감시 및 성능 분석 : 병목 현상등을 확인 및 성능 감시.
데이터베이스 재구성 : 사용자의 요구에 맞추거나 성능 향상을 위해 재구성.

최종 사용자

데이터를 삽입, 삭제, 수정, 검색하기 위해 데이터베이스에 접근하는 사람들을 최종 사용자라고 한다. 주로 데이터 조작어를 사용하며 GUI 형태의 응용 프로그램으로 데이터베이스를 사용한다.

응용 프로그래머

프로그래밍 언어로 응용 프로그램을 작성할 때 데이터베이스에 접근하는 데이터 조작어를 사용하는 사용자이다.

데이터 언어

데이터 언어의 종류와 용도

데이터 언어는 사용자가 데이터베이스를 구축하고 이에 접근하기 위해 데이터베이스 간리 시스템과 통신하는 수단이다. 목적에 따라 데이터 정의어, 조작어, 제어어로 나뉜다.

데이터 정의어 (Data Definition Language, DDL)

데이터 정의어는 새로운 데이터베이스를 구축하기 위해 스키마를 정의하거나 기존 스키마의 정의를 삭제 또는 수정하기 위해 사용하는 데이터 언어이다. 즉 데이터베이스의 스키마를 생성하거나 스키마의 구조나 제약조건 변경 및 삭제를 할때 사용한다. 데이터 정의어로 정의된 스키마는 데이터 사전에 저장된다.

데이터 조작어 (Data Manipulation Language, DML)

데이터 조작어는 사용자가 데이터의 삽입, 삭제, 수정, 검색 등의 처리를 데이터 베이스 관리 시스템에 요구하기 위해 사용하는 데이터 언어이다. 즉, 실제 데이터 값을 활용하기 위해 사용하는 것이 데이터 조작어이다. 방식에 따라 절차적 데이터 조작어와 비절차적 데이터 조작어로 나뉜다.

절차적 데이터 조작어는 사용자가 어떤 데이터를 원하고 해당 데이터를 어떻게 처리해야하는지를 설명하는 것이다. 비절차적 데이터 조작어는 사용자가 어떤 데이터를 원하는지만 설명하고, 어떻게 처리해야 하는지는 데이터베이스 관리 시스템에게 맡기는 것이다. 선언적 언어라고도 한다.

데이터 제어어 (Data Control Language, DCL)

데이터 제어어는 데이터베이스에 저장된 데이터를 여러 사용자가 무결성과 일관성을 유지하며 문제없이 공유할 수 있도록, 내부적으로 필요한 규칙이나 기법을 정의하는데 사용하는 데이터 언어이다. 데이터 제어어를 통해 다음과 같은 특성을 보장한다.

무결성, Integrity : 데이터베이스에 정확하고 유효한 데이터만 유지.
보안, Security : 허가받지 않은 사용자를 차단 및 허가한 사용자를 접근 허용.
회복, Recovery : 장애가 발생하여도 데이터의 일관성 유지.
동시성, Concurrecny : 여러 사용자가 같은 데이터에 동시 접근 허용.

데이터베이스 관리 시스템의 구성

데이터베이스 관리 시스템은 사용자와 데이터베이스 사이에 위치하며 기능에 따라 크게 질의 처리기와 저장 데이터 관리자로 나뉜다.

질의 처리기

질의 처리기는 사용자의 데이터 처리 요구를 해석하여 처리하는 역할을 하며 다음과 같은 것들이 있다.

DDL 컴파일러 : 데이터 정의어로 작성된 스키마의 정의를 해석 및 저장 데이터 관리자의 도움을 받아 데이터베이스 구축. 데이터 정의어로 작성된 스키마의 삭제나 수정 처리 데이터 사전에 반영.
DML 프리 컴파일러 : 응용 프로그램에 삽입된 데이터 조작어를 추출하여 DML 컴파일러에 전달.
DML 컴파일러 : 데이터 조작어로 작성된 데이터의 삽입, 삭제, 수정, 검색을 해석.
런타임 데이터베이스 처리기 : 저장 데이터 관리자를 통해 데이터베이스에 접근하여 DML 컴파일러로부터 받은 명령을 실행.
트랜잭션 관리자 : 데이터베이스에 접근하는 과정에서 접근 권한 확인인 제약조건 위반 확인.

저장 데이터 관리자

저장 데이터 관리자는 디스크에 저장된 데이터베이스와 데이터 사전을 관리하고, 접근하는 역할을 한다.

데이터베이스 개론 - 교보문고