• 비인가자가 데이터베이스에 침입하여 데이터를 유출하거나 손상한다면 조직에 치명적인 손실이 발생함 인가자만 데이터베이스에 접근할 수 있도록 통제하여 보안을 유지하는 일이 무척 중요

보안의 유형

• 물리적 환경에 대한 보안 - 자연 재해 등으로부터 보호
• 권한 관리를 통한 보안 - 권한이 없는 사용자로부터 보호
• 운영 관리를 통한 보안 - 권한이 있는 사용자로부터 보호

권한 관리

• DBMS는 보안을 유지하기 위해, 계정이 발급된 사용자가 로그인에 성공했을 경우에만 데이터베이스에 접근이 가능하도록 하는 접근 제어(access control)기능을 기본으로 제공 계정을 생성, 변경, 제거하는 사용자 계정 관리는 DBA가 담당

• 데이터베이스에 존재하는 모든 객체는 기본적으로 해당 객체를 생성한 사용자만 사용 권한을 지님 필요에 따라 공유할 목적으로 다른 사용자에게 권한을 부여, 취소할 수 있음

권한의 부여

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

• 일반적으로 테이블에 권한을 부여하는 경우가 많음 주요 권한으로 INSERT, DELETE, UPDATE, SELECT, REFERENCES 가 존재
• REFERENCES 권한을 부여 받은 사용자는 대상 테이블의 기본키를 참조하는 외래키를 자신의 테이블에 포함할 수 있음
• UPDATE, SELECT는 일부 속성에 대한 권한 부여 가능 모든 사용자들에게 똑같이 부여하고 싶다면 PUBLIC 키워드 이용

※ WITH GRANT OPTION을 포함하여 부여 받은 사용자는 다른 사용자에게도 권한 부여 가능

보안을 강화하기 위해 뷰를 이용할 수 있음 테이블 일부분을 뷰로 생성한 후, 사용자에게 이 뷰에 대한 권한을 부여하는 것도 보안을 유지하는 데 도움이 됨

• 객체에 대한 권한과 달리 시스템 권한은 DBA가 부여 시스템 권한은 데이터베이스 관리와 관련된 작업 대한 권한, DDL과 관련된 작업에 대한 권한 (객체를 지정할 필요가 없음) - ex) GRANT CREATE TABLE TO mhgo;

권한의 취소

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

• 사용자가 WITH GRANT OPTION으로 인한 추가적인 권한 부여가 되었다면 이를 처리하는 방법이 필요 → 연쇄적으로 취소하고자 하면 CASCADE, 취소하지 않도록 하려면 RESTRICT를 사용

• DBA는 각 테이블의 소유주가 사용자들에게 어떤 권한을 부여했는지, WITH GRANT OPTION을 포함하여 권한을 부여했는지 등 권한 목록을 작성해두고 관리하는 것이 필요

• DBA가 시스템 권한을 취소할 때도 REVOKE문을 이용 ex)REVOKE CREATE TABLE FROM mhgo;

역할(role)

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

• 새로운 역할을 생성하는 기능은 DBA가 담당 / CREATE ROLE 롤이름;

• 역할에 필요한 권한들을 넣을 떄는 GRANT 이용 - 테이블 소유자가 수행

• 역할에 사용자에게 부여, 취소하는 것은 DBA가 담당 / GRANT/REVOKE 롤이름 TO/FROM 사용자;

• 역할 제거는 DBA가 담당 / DROP ROLE 롤이름;

출처 - 김연희저자의 데이터베이스 개론 2판 - 한빛 아카데미

• DBMS는 데이터베이스가 항상 정확하고 일관된 상태를 유지할 수 있도록 하는데, 그 중심에는 트랜잭션이 있음 트랜잭션을 관리함으로써 데이터베이스의 회복과 병행 제어가 가능

트랜잭션(transaction)

• 하나의 작업을 수행하는 데 필요한 데이터베이스의 연산들을 모아놓은 것 데이터베이스에서 논리적인 작업의 단위 (데이터베이스에 장애가 발생했을 때 데이터를 복구하는 작업의 단위) 트랜잭션의 모든 명령문이 완벽하게 처리되거나 하나도 처리되지 않아야 데이터베이스가 모순이 없는 일관된 상태를 유지할 수 있음
• 데이터베이스의 무결성과 일관성을 보장하려면 필요한 연산들을 하나의 트랜잭션으로 제대로 정의하고 관리해야 함
• 일반적으로 데이터베이스를 변경하는 INSERT문, DELETE문, UPDATE문의 실행을 트랜잭션으로 관리

트랜잭션의 4가지 특성

• ACID - 원자성, 일관성, 격리성, 지속성

원자성(atomicity)

• 트랜잭션을 구성하는 연산들이 모두 정상적으로 실행되거나 하나도 실행되지 않아야 함 (all or nothing) 원자성을 보장하면 트랜잭션을 구성하는 연산 중 일부만 처리한 결과를 데이터베이스에 반영하는 일이 없게 됨

일관성(consistency)

• 트랜잭션이 성공적으로 수행된 후에도 데이터베이스가 일관된 상태를 유지해야 함

격리성(isolation) / 고립성

• 수행 중인 트랜잭션이 완료될 때까지 트랜잭션이 생성한 중간 연산 결과에 다른 트랜잭션들이 접근할 수 없음을 의미함

지속성(durability) / 영속성

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

트랜잭션의 특성을 지원하는 DBMS의 기능

• 트랜잭션의 연산 commit 연산 - 트랜잭션이 성공적으로 수행되었음을 선언 (작업 완료) rollback 연산 - 트랜잭션을 수행하는 데 실패했음을 선언 (작업 취소)

트랜잭션의 상태

• 트랜잭션은 다섯 가지 상태 중 하나에 속하게 됨 활동 상태, 부분 완료 상태, 완료 상태, 실패 상태, 철회 상태

  활동 상태

• 트랜잭션이 수행되기 시작하여 현재 수행 중인 상태, 상황에 따라 부분 완료 상태나 실패 상태가 됨

  부분 완료 상태

• 트랜잭션의 마지막 연산이 실행된 직후의 상태, 이는 트랜잭션의 모든 연산을 처리한 상태이며 아직 최종 결과를 데이터베이스에 반영하지 않은 상태, 상황에 따라 완료 상태나 실패 상태가 됨

  완료 상태

• 트랜잭션이 성공적으로 완료되어 commit 연산을 실행한 상태, 트랜잭션이 수행한 최종 결과를 데이터베이스에 반영하고, 데이터베이스가 새로운 일관된 상태가 되면서 트랜잭션이 종료

  실패 상태

• 하드웨어나 소프트웨어의 문제, 트랜잭션 내부의 오류 등 여러 이유로 인해 장해가 발생하여 트랜잭션의 수행이 중단된 상태, 트랜잭션을 더는 정상적으로 수행할 수 없을때 실패 상태가 됨

  철회 상태

• 트랜잭션을 수행하는 데 실패하여 rollback 연산을 실행한 상태, 트랜잭션의 연산을 모두 취소하고 트랜잭션이 수행되기 전의 데이터베이스 상태로 되돌리면서 트랜잭션이 종료, 철회 상태로 종료된 트랜잭션은 상황에 따라 다시 수행되거나 폐기

장애와 회복

• 데이터베이스가 조직의 주요한 데이터를 저장하고 있는 만큼 데이터베이스 관리 시스템의 회복 기능은 매우 중요 회복은 장애가 발생했을 때 데이터베이스를 장애가 발생하기 전의 일관된 상태로 복구시키는 것

  장애 시스템이 제대로 동작하지 않는 상태

장애의 유형

트랜잭션 장애

의미 - 트랜잭션 수행 중 오류가 발생하여 정상적으로 수행을 계속할 수 없는 상태 원인 - 트랜잭션의 논리적 오류, 잘못된 데이터 입력,시스템 자원의 과다 사용 요구, 처리 대상 데이터의 부재 등

시스템 장애

의미 - 하드웨어 결함으로 정상적으로 수행을 계속할 수 없는 상태 원인 - 하드웨어 이상으로 메인 메모리에 저장된 정보가 손실되거나 교착 상태가 발생한 경우

미디어 장애

의미 - 디스크 장치의 결합으로 디스크에 저장된 데이터베이스의 일부 혹은 전체가 손상된 상태 원인 - 디스크 헤드의 손상이나 고장 등

데이터베이스의 저장 연산

• 데이터베이스는 기본적으로 비휘발성 저장 장치인 디스크에 상주 트랜잭션이 데이터베이스의 데이터를 처리하려면, 데이터를 디스크에서 휘발성 저장 장치인 메인 메모리로 가져와 이를 처리한 후 그 결과를 다시 디스크로 보내는 작업이 필요

• 디스크와 메인 메모리 간의 데이터 이동은 대개 블록(block) 단위로 수행 디스크 블록(디스크), 버퍼 블록(메인 메모리)

• 디스크와 메인 메모리 간의 데이터 이동은 input(X)(디스크 블록 > 버퍼 블록), output(X)(버퍼 블록 > 디스크 블록) 두 연산으로 수행

• 메인 메모리와 응용 프로그램 간의 데이터 이동은 read(X)(버퍼 블록 > 변수), write(X)(변수 > 버퍼 블록) 두 연산으로 수행

회복 기법

회복

• 데이터베이스에 장애가 발생했을 때 장애가 발생하기 전의 모순이 없고 일관된 상태로 복구시키는 것이며, DBMS의 회복관리자가 담당
• 장애가 일어난 데이터베이스를 복구하는 동안에는 데이터베이스에 접근하여 업무를 처리할 수 없으므로, 회복시키는 작업은 빠른 시간 내에 이루어져야 함

회복을 위한 연산

• 데이터베이스 회복의 핵심 원리는 데이터 중복 데이터를 별도의 장소에 미리 복사해두고, 장애로 문제가 발생했을 때 복사본을 이용해 원래의 상태로 복원하는 것 덤프나 로그 방법을 사용해 데이터를 복사해두었다가 회복시킬 때 사용

  덤프(dump) - 데이터베이스 전체를 다른 저장 장치에 주기적으로 복사하는 방법 로그(log) - 데이터베이스에서 변경 연산이 실행될 때마다 데이터를 변경하기 이전 값과 변경한 이후의 값을 별도의 파일에 기록하는 방법

• 장애가 발생했을 때, 덤프나 로그 방법으로 데이터베이스를 복구하는 가장 기본적인 방법은 redo나 undo 연산을 실행하는 것

  redo(재실행) - 가장 최근에 저장한 데이터베이스 복사본을 가져온 후 로그를 이용해 복사본이 만들어진 이후에 실행된 모든 변경 연산을 재실행 > 장애 발생 직전까지 복구, 전반적으로 손상된 경우에 주로 사용 undo(취소) - 로그를 이용해 지금까지 실행된 모든 변경 연산을 취소하여 데이터베이스 복구, 변경 중이었거나 이미 변경된 내용만 신뢰성을 잃은 경우에 주로 사용

• redo와 undo를 실행하는 데는 로그가 중요하게 사용됨 로그를 저장한 파일을 로그 파일이라 하며 로그 파일은 레코드 단위로 기록됨

  데이터베이스 회복 기법

• 로그 회복 기법, 검사 시점 회복 기법, 미디어 회복 기법이 존재

로그 회복 기법

• 데이터를 변경한 연산 결과를 데이터베이스에 반영하는 시점에 따라 즉시 갱신 회복 기법과 지연 갱신 회복 기법으로 나눔

즉시 갱신 회복 기법 (immediate update)

• 트랜잭션 수행 중에 데이터를 변경한 연산의 결과를 데이터베이스에 즉시 반영하고 데이터 변경에 대한 내용을 로그 파일에도 기록 데이터베이스 회복 시 로그를 정상적으로 사용하려면, 트랜잭션에서 데이터 변경 연산이 실행되었을 때 로그 파일에 로그 레코드를 먼저 기록한 후 데이터베이스 변경 연산을 반영 로그 파일에 기록된 내용을 참조하여, 장애 발생 시점에 따라 redo나 undo 연산을 실행하여 데이터베이스를 복구

  commit 이전 > undo연산 / commit 이후 > redo연산

• redo와 undo가 모두 필요할 때는 undo를 먼저 실행한 후 redo를 실행

지연 갱신 회복 기법 (deferred update)

• 트랜잭션이 수행되는 동안에는 데이터 변경 연산의 결과를 데이터베이스에 즉시 반영하지 않고 로그 파일에만 기록해두었다가, 트랜잭션이 부분 완료된 후에 로그에 기록된 내용을 이용해 데이터베이스에 한 번에 반영 트랜잭션이 수행되는 동안 장애가 발생할 경우 로그에 기록된 내용을 버리기만 하면 됨 undo연산은 필요 없고 redo연산만 필요하므로 로그 레코드에 변경 이전 값을 기록할 필요가 없음

• 검사 시점 회복 기법의 등장 배경 로그 회복 기법은 로그 전체를 분석하여 로그에 기록된 모든 트랜잭션을 대상으로 적용할 회복 연산을 결정 데이터베이스 회복에 많은 시간이 걸리고 redo를 수행할 필요가 없는 트랜잭션에도 redo를 실행하는 일이 발생 이런 비효율성을 해결하기 위해 제안된 방법 > 검사 시점 회복 기법

검사 시점 회복 기법

• 로그 회복 기법과 같은 방법으로 로그 기록을 이용하되, 일정 시간 간격으로 검사 시점(check point)을 제작, 장애가 발생하면 가장 최근 검사 시점 이후의 트랜잭션만 회복 작업을 수행 회복 작업의 범위가 검사 시점으로 정해지므로 데이터베이스 회복 시간이 단축된다는 장점 존재 검사 시점을 표시하는 <checkpoint L>형식의 로그 레코드를 기록하고 이를 이용해 회복 작업의 범위가 정해지면 즉시 갱신 회복 기법이나 지연 갱신 회복 기법을 이용해 회복 작업 수행

미디어 회복 기법

• 데이터베이스는 디스크에 저장되는데 디스크 헤더의 고장과 같은 원인으로 장애가 발생할 수 있음 이에 대비한 회복 기법이 미디어 회복 기법 전체 데이터베이스의 내용을 일정 주기마다 다른 안전한 저장 장치에 복사해두는 덤프를 이용, 장애가 발생하면 가장 최근에 복사해둔 덤프를 이용해 복구 전체 데이터베이스를 다른 저장 장치에 복사하는 것은 비용이 많이 들고, 복사하는 동안 트랜잭션 수행이 중단되기에 CPU가 낭비된다는 단점 존재

병행 수행(concurrency)

• 여러 개의 트랜잭션이 동시에 수행되는 것, 인터리빙(interleaving) 방식으로 진행

  인터리빙 - 트랜잭션이 번갈아가며 조금씩 처리를 수행하는 것

• 병행 수행되는 트랜잭션들이 동시에 같은 데이터에 접근하여 변경 연산을 실행하려고 하면 예상치 못한 결과가 발생 가능 병행 수행을 하더라도 각 트랜잭션이 다른 트랜잭션의 방해를 받지 않고 정확한 수행 결과를 얻을 수 있도록 제어해야 함

병행 수행의 문제

• 병행 수행을 특별한 제어 없이 진행하면 갱신 분실, 모순성, 연쇄 복귀의 문제가 발생할 수 있음

  갱신분실(lost update)

• 하나의 트랜잭션이 수행한 데이터 변경 연산의 결과를 다른 트랜잭션이 덮어써 변경 연산이 무효화되는 것

  모순성(inconsistency)

• 하나의 트랜잭션이 여러 개의 데이터 변경 연산을 수행할 때 일관성 없는 상태의 데이터베이스에서 데이터를 가져와 연산을 실행함으로써 모순된 결과가 발생하는 것

  연쇄 복귀(cascading rollback)

• 트랜잭션이 완료되기 전에 장애가 발생하여 rollback연산을 수행하면, 이 트랜잭션이 장애 발생 전에 변경한 데이터를 가져가 사용한 다른 트랜잭션에도 rollback연산을 연쇄적으로 실행해야 한다는 것

트랜잭션 스케줄

• 트랜잭션이 인터리빙 방식으로 진행되는데 이는 트랜잭션에 있는 연산을 실행하는 순서에 따라 트랜잭션들의 수행 결과가 달라지기도 하고, 병행 수행에 따른 문제가 발생하기도 하기에 트랜잭션 스케줄이 필요

  트랜잭션 스케줄 - 트랜잭션에 포함되어 있는 연산들을 수행하는 순서

트랜잭션 스케줄의 유형

• 직렬 스케줄 - 인터리빙 방식을 이용하지 않고 각 트랜잭션별로 연산을 순차적으로 실행
• 비직렬 스케줄 - 인터리빙 방식을 이용하여 트랜잭션들을 병행해서 수행
• 직렬 가능 스케줄 - 직렬 스케줄과 같이 정확한 결과를 생성하는 비직렬 스케줄

직렬 스케줄

• 직렬 스케줄의 수행 순서에 따라 최종 수행 결과가 달라질 수 있음 모든 트랜잭션이 완료될 때까지 다른 트랜잭션의 방해를 받지 않고 독립적으로 수행, 모순이 없는 정확한 결과 트랜잭션을 독립적으로 수행하기 때문에 병행 수행이라 할 수 없고 일반적으로 잘 사용하지 않음

비직렬 스케줄

• 트랜잭션이 돌아가면서 연산을 실행, 여러 트랜잭션을 병행 수행하기에 최종 수행 결과의 정확성을 보장할 수 없음 어떤 비직렬 스케줄을 선택하여 트랜잭션들을 수행하느냐가 중요

직렬 가능 스케줄

• 비직렬 스케줄 중에서 결과가 동일한 직렬 스케줄이 없는 것은 결과의 정확성을 보장할 수 없기에 직렬 가능 스케줄이 아님 직렬 가능 스케줄인지 여부를 판단하는 일은 쉽지 않기에 대부분 DBMS에서는 직렬 가능성을 보장하는 병행 제어 기법을 사용

병행 제어(concurrency control), 동시성 제어

• 여러 개의 트랜잭션이 병행 수행되더라도, 문제 없이 정확한 수행 결과를 얻을 수 있도록 트랜잭션의 수행을 제어하는 것

병행 제어 기법

• 여러 트랜잭션을 병행 수행하면서도 정확한 결과를 얻을 수 있는 직렬 가능성을 보장받기 위해 사용 모든 트랜잭션이 원리를 따르면 직렬 가능성이 보장되는 규약을 정의하고 트랜잭션들이 이 규약을 따르도록 하는 것

  병행 제어 기법 중 로킹 기법이 가장 많이 사용된다

로킹 기법(locking)

• 병행 수행되는 트랜잭션들이 동일한 데이터에 동시에 접근하지 못하도록 lock과 unlock이라는 연산을 이용해 제어 트랜잭션 간 상호 배제하여 직렬 가능성을 보장하는 것

• 사용하는 연산

  • lock - 데이터에 대한 독점권 보장
  • unlock - 데이터에 대한 독점권 포기

기본 로킹 규약

• 반드시 read 또는 write 연산을 실행하기 전에 lock 연산을 실행해야 함
• 다른 트랜잭션이 이미 lock 연산을 실행한 데이터에는 다시 lock 연산이 실행될 수 없음
• 모든 연산을 수행하고 나면 unlock 연산을 실행해서 독점권을 반납해야 함

lock 연산은 다양한 크기의 데이터를 대상으로 실행할 수 있음 전체 데이터베이스에 lock 연산을 실행하면 제어가 간단하지만 하나의 트랜잭션만 수행되므로 병행 수행이라 할 수 없음 속성에 lock 연산을 하면 많은 수의 트랜잭션이 병행 수행할 수 있지만 제어가 복잡함 즉, 시스템에 따라 적절한 로킹 단위를 선택하는 것이 중요

기본 로킹 기법

• 병행 수행을 제어, 엄격한 제약으로 어떤 순간이든 데이터 독점을 하나의 트랜잭션만 가능 write는 엄격해야 함, read는 동시에 실행해도 문제가 없음 -> 공용, 전용 lock

  • 공용 lock – read는 가능하지만 write는 불가(데이터에 대한 사용권을 여러 트랜잭션이 지님)
  • 전용 lock – read, write 가능, 다른 트랜잭션은 접근 불가

• 하지만 이러한 기본 로킹 규약만으로는 트랜잭션 스케쥴의 직렬 가능성을 완벽히 보장할 수 없음

2단계 로킹 규약(2PLP)

• 트랜잭션 스케줄의 모든 트랜잭션이 2단계 로킹 규약을 준수하면 해당 스케줄은 직렬 가능성이 보장됨 확장단계(lock만 가능), 축소단계(unlock만 가능)로 나누어 실행

• 교착 상태(deadlock)가 발생할 수 있음 교착 상태는 처음부터 발생하지 않도록 사용자가 예방하거나, 발생했을 때 빨리 탐지하여 필요한 조치를 취하는 방법으로 해결해야 함

출처 - 김연희저자의 데이터베이스 개론 2판 - 한빛 아카데미

정규화(normalization)

• 데이터베이스를 잘못 설계하면 데이터의 삽입, 수정, 삭제 연산을 수행할 때 부작용(이상현상 (anomaly))이 발생 정규화는 이상 현상이 발생하지 않도록 릴레이션을 분해(decomposition)하는 과정을 의미 데이터베이스를 설계한 후 설계 결과물을 검증하기 위해 사용하기도 함

이상 현상의 종류

• 삽입 이상(insertion anomaly) - 새 데이터를 삽입하기 위해 불필요한 데이터도 함께 삽입해야 하는 문제
• 갱신 이상(update anomaly) - 중복 투플 중 일부만 변경되어 데이터가 불일치하게 되는 모순의 문제
• 삭제 이상(deletion anomaly) - 투플을 삭제하면 필요한 다른 데이터까지 함께 삭제되는 데이터 손실의 문제

정규화의 필요성

• 관련 없는 속성들을 하나의 릴레이션에 모아두고 있으면 여러 이상 현상이 발생 정규화를 수행하기 위해선 속성들 간의 관련성인 함수적 종속성(Functional Dependency)을 판단해야 함 일반적으로 릴레이션에 함수적 종속성이 하나 존재하도록 정규화를 통해 릴레이션을 분해

함수 종속

• 하나의 릴레이션을 구성하는 속성들의 부분 집합을 X와 Y라 할 때, 어느 시점에서든 릴레이션 내의 모든 투플에서 하나의 X의 값에 대한 Y의 값이 항상 하나면

  X -> Y (X는 결정자, Y는 종속자)

  'X가 Y를 함수적으로 결정한다' 또는 'Y가 X에 함수적으로 종속되어 있다' 라고 함

• 함수 종속 관계는 현재 시점에 릴레이션에 포함된 속성 값만으로 판단하면 안 된다는 것을 유의해야 함 릴레이션에서 속성 값은 계속 변할 수 있기 때문에 속성 자체가 가지고 있는 특성과 의미를 기반으로 판단해야 함

  • 완전 함수 종속 (Full Functional Dependency) 릴레이션에서 속성 집합 Y가 속성 집합 X에 종속되어 있지만, 속성 집합 X의 일부분에 종속된 것이 아님을 의미
  • 부분 함수 종속 (Partial Functional Dependency) 속성 집합 Y가 속성 집합 X의 전체가 아닌 일부분에도 함수적으로 종속됨을 의미 일반적으로 함수 종속이라고 하면 완전 함수 종속을 의미

정규형의 종류

• 릴레이션이 정규화된 정도는 정규형(Normal Form)으로 표현 정규형은 크게 기본 정규형과 고급 정규형으로 나뉨

  • 기본 정규형 - 제1정규형, 제2정규형, 제3정규형, 보이스/코드 정규형
  • 고급 정규형 - 제4정규형, 제5정규형

• 각 정규형마다 만족시켜야 하는 제약조건이 존재 릴레이션이 특정 정규형의 제약조건을 만족하면 릴레이션이 해당 정규형에 속한다고 표현 정규형의 차수가 높아질수록 요구되는 제약조건이 많아지고 엄격해짐

• 일반적으로 차수가 높은 정규형에 속하는 릴레이션일수록 바람직한 릴레이션이나, 모든 릴레이션이 제5정규형에 속해야 되는 것은 아니기에 릴레이션의 특성을 고려해서 적합한 정규형을 선택

제1정규형(1NF)

• 릴레이션에 속한 모든 속성의 도메인이 원자 값으로만 구성되어 있어야 함 최소한 제1정규형을 만족해야 관계 데이터베이스의 릴레이션이 될 자격이 있음

• 삽입 이상, 갱신 이상, 삭제 이상 발생

• 릴레이션이 부분 함수 종속을 포함하고 있기 때문

제2정규형(2NF)

• 릴레이션이 제1정규형에 속하고, 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속되야 함

정규화 과정에서 릴레이션을 분해할 때 주의할 점 분해된 릴레이션들을 자연 조인하여 분해 전의 릴레이션으로 다시 복원할 수 있어야 한다는 것 - 무손실 분해(nonloss decomposition) 릴레이션을 분해했을 때 정보 손실이 발생하지 않아야 함

• 삽입 이상, 갱신 이상, 삭제 이상 발생
  • 릴레이션이 함수적 종속 관계를 여러 개 포함하고 있어 이행적 함수 종속이 존재하기 때문

제3정규형(3NF)

• 릴레이션이 제2정규형에 속하고, 기본키가 아닌 모든 속성이 기본키에 이행적 함수 종속이 되지 않아야 함

• 이행적 함수 종속(transitive FD) 속성집합 X, Y, Z가 존재하고 X->Y, Y->Z 일때, 논리적으로 X->Z가 성립 이때 Z가 X에 이행적으로 함수 종속 되었다고 함 함수 종속 관계가 하나의 릴레이션에 여러 개 존재하면 이행적 함수 종속이 나타남

• 후보키를 여러 개 가지고 있는 릴레이션의 경우 이상현상 발생할 수 있음 따라서 제3정규형도 이상 현상이 발생하는 경우 존재

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

• 릴레이션의 함수 종속 관계에서 모든 결정자가 후보키가 되어야 함 (강한 제3정규형) 보이스/코드 정규형에 속하는 모든 릴레이션은 제3정규형에 속하지만, 제3정규형에 속한다고 보이스/코드 정규형에 속하는 것은 아님

• 3NF → BCNF

제4정규형(4NF)

• 릴레이션이 보이스/코드 정규형을 만족하면서, 다치 종속(Multi Valued Dependency)을 제거해야 만족

제5정규형(5NF)

• 릴레이션이 제4정규형을 만족하면서 후보키를 통하지 않는 조인 종속(Join Dependency)을 제거해야 만족

실제로 설계 시 무조건 제5정규형에 속하도록 분해해야 하는 것은 아니며, 오히려 제5정규형까지 분해하면 비효율적이고 바람직하지 않은 경우가 존재 일반적으로 제3정규형이나 보이스/코드 정규형에 속하도록 릴레이션을 분해하여 데이터 중복을 줄이고 이상 현상을 해결함

출처 - 김연희저자의 데이터베이스 개론 2판 - 한빛 아카데미

데이터베이스 설계

• 사용자들의 요구 사항을 고려하여 데이터베이스를 생성하는 과정 데이터베이스는 구조를 변경하기 어렵기 때문에 설계 과정에서부터 품질 좋은 데이터베이스를 생성해야 됨

  품질 기준 사용하는 구성원들의 요구 사항을 만족하는지, 데이터의 일관성과 무결성, 사용자가 이해하기 쉽고 접근성이 좋은지 ... etc

데이터베이스 설계 방식

E-R모델과 릴레이션 변환 규칙을 이용한 데이터베이스 설계와 정규화를 이용한 데이터베이스 설계

데이터베이스 설계 과정

요구 사항 분석 > 개념적 설계 > 논리적 설계 > 물리적 설계 > 구현

요구 사항 분석

• 조직의 구성원들이 데이터베이스를 사용하는 용도를 파악
• 수집한 다양한 요구 사항을 분석하여 그 결과를 요구 사항 명세서로 작성하는 것이 주요 작업
• 먼저 데이터베이스를 사용할 주요 사용자의 범위부터 결정하여 불필요한 요구 사항을 수집하지 않도록 함
• 요구 사항 분석이 잘못되면 사용자가 원치 않는 데이터베이스가 개발되어, 고치거나 다시 개발하는 수고가 뒤따를 수 있음 (신중하고 꼼꼼하게 작업해야 함)

개념적 설계

• 요구 사항 분석 단계의 결과물인 명세서를 바탕으로 개념적 구조를 설계
• 사용자의 요구 사항을 개념적 데이터 모델을 이용해 표현 / 일반적으로 E-R모델로 설계하며 E-R 다이어그램으로 표현하는 것이 주요 작업
• 요구 사항 명세서 → 개념적 데이터 모델 = 개념적 모델링

  개체와 속성 추출 - 일반적으로 요구 사항의 문장에서 명사 관계 추출 - 일반적으로 요구 사항을 표현한 문장에서 동사

논리적 설계

• 개발에 사용할 DBMS에 적합한 논리적 데이터 모델을 이용해 개념적 구조를 기반으로 논리적 구조를 설계

• 일반적으로 관계 데이터 모델을 사용하며, E-R 다이어그램을 릴레이션 스키마로 변환하는 것이 주요 작업

• 변환 시 고려할 사항이 많음

• 개념적 데이터 모델 → 논리적 데이터 모델 = 논리적 모델링

  릴레이션 스키마 변환 규칙

  1. 모든 개체는 릴레이션으로 변환한다
  2. 다대다 관계는 릴레이션으로 변환한다
  3. 일대다 관계는 외래키로 표현한다 3-1 일반적인 일대다 관계는 외래키로 표현한다 3-2 약한 개체가 참여하는 일대다 관계는 외래키를 포함해서 기본키로 지정한다
  4. 일대일 관계는 외래키로 표현한다 4-1 일반적인 일대일 관계는 외래키를 서로 주고받는다 4-2 일대일 관계에 필수적으로 참여하는 개체의 릴레이션만 외래키를 받는다 4-3 모든 개체가 일대일 관계에 필수적으로 참여하면 릴레이션 하나로 합친다
  5. 다중 값 속성은 릴레이션으로 변환한다

  기타 고려 사항

  • 속성이 많은 관계는 관계 유형에 상관없이 릴레이션으로 변환하는 것을 고려할 수 있음 다만 릴레이션의 개수가 많으면 DBMS의 부담이 커짐, 릴레이션의 개수가 불필요하게 늘어나지 않도록 관리

물리적 설계

• 논리적 구조를 기반으로 물리적 구조를 설계
• 저장 장치에 적합한 저장 레코드와 인덱스의 구조 등을 설계하고, 저장된 데이터와 인덱스에 빠르게 접근하게 할 수 있는 탐색 기법 등을 정의
• 데이터베이스를 실제로 구축할 컴퓨터 시스템의 저장 장치와 운영체제의 특성을 고려하여 물리적인 구조를 설계하는 것이 주요 작업
• 응답 시간을 최소화하고 저장 공간을 효율적으로 활용하면서 데이터베이스 시스템의 처리 능력을 향상시킬 수 있도록 설계

구현

• 이전 설계 단계의 결과물을 기반으로 DBMS에서 SQL로 작성한 명령문을 실행하여 데이터베이스를 실제로 생성
• 데이터 정의어(DDL) 사용

※ 모든 단계가 중요하지만, 그 중에서 데이터베이스의 개념적 구조와 논리적 구조를 설계하는 요구 사항 분석, 개념적 설계, 논리적 설계 단계가 핵심

출처 - 김연희저자의 데이터베이스 개론 2판 - 한빛 아카데미

• 관계 데이터베이스를 위한 표준 질의어로 많이 사용되는 언어 사용자가 처리를 원하는 데이터가 무엇인지만 제시하고 어떻게 처리해야 하는지 절차를 언급할 필요가 없음 (비절차)
• DBMS에 직접 접근하여 대화식으로 질의를 작성, C나 Java 같은 언어로 작성한 응용 프로그램에 삽입하여 사용

SQL의 분류

• 데이터 조작어, 데이터 정의어, 데이터 제어어

모든 SQL 문은 ;으로 문장 끝을 표시, SQL 문에 사용되는 키워드는 대소문자를 구분하지 않음

SQL을 이용한 데이터 정의

• 테이블 생성, 생성된 테이블 구조의 변경, 테이블 삭제로 분류

테이블 생성 - CREATE TABLE

• 생성할 테이블을 구성하는 속성들의 이름, 데이터 타입 및 제약 사항에 대한 정의, 기본키/대체키/외래키의 정의, 데이터 무결성을 위한 제약조건의 정의 등을 포함

  1)은 테이블을 구성하는 각 속성의 이름과 데이터 타입, 기본적인 제약 사항을 정의 2)는 기본키로 테이블에 하나만 존재 3)은 대체키로 테이블에 여러 개 존재 가능 4)는 외래키로 테이블에 여러 개 존재 가능 5)는 데이터 무결성을 위한 제약조건으로 여러 개 존재 가능

CREATE TABLE 테이블_이름 (
1) 속성_이름 데이터_타입 [NOT NULL] [DEFAULT]
2) [PRIMARY KEY (속성_리스트)]
3) [UNIQUE (속성_리스트)]
4) [FOREIGN KEY (속성_리스트) REFERENCES 테이블_이름(속성_리스트)] [ON DELETE 옵션] [ON UPDATE 옵션]
5) [CONSTRAINT 이름] [CHECK (조건)]
);

속성의 정의

• CREATE TABLE 문으로 생성되는 테이블을 구성하는 속성은 기본적으로 널 값이 허용, 허용하지 않는 속성을 정의하려면 NOT NULL 명시 (기본키 - 개체 무결성 제약조건, 꼭 입력해야 된다고 판단되는 속성) DEFAULT로 기본 값을 지정 가능, 숫자는 그대로 표현, 문자열이나 날짜는 작은따옴표 내에 표기

키의 정의

• 기본키, 대체키, 외래키를 지정할 수 있음

  • PRIMARY KEY로 기본키 설정(없어도 가능하나 선택하는 것이 좋음)
  • UNIQUE로 대체키 설정(여러 개 가능)
  • FOREIGN KEY로 외래키 설정(지정할 때는 출처를 분명히 해야함 REFERENCES를 제시 - 참조 무결성 제약조건을 유지하기 위함)

• 참조되는 테이블에서 투플을 삭제하거나 변경할 때 처리하는 방식 NO ACTION - 기본 설정, 투플을 삭제/변경하지 못하게 함 CASCADE - 관련 투플을 함께 삭제/변경 SET NULL - 관련 투플의 외래키 값을 NULL로 변경 SET DEFAULT - 관련 투플의 외래키 값을 미리 지정한 기본 값으로 변경

• 데이터 무결성 제약조건의 정의 CHECK를 사용해 특정 속성에 대한 제약조건을 지정할 수 있음 (CHECK로 지정한 제약조건을 만족하는 투플만 존재) CONSTRAINT로 CHECK에 고유한 명칭 부여 가능, 이후에 제약조건을 수정하거나 제거할 때 식별하기가 쉬움

테이블 변경 - ALTER TABLE

• 새로운 속성 추가, 기존 속성 삭제, 새로운 제약조건 추가, 기존 제약조건 삭제 등이 가능

새로운 속성 추가

ALTER TABLE 테이블_이름 ADD 속성_이름 데이터_타입 [NOT NULL] [DEFAULT];

기존 속성 삭제

ALTER TABLE 테이블_이름 DROP COLUMN 속성_이름;

새로운 제약조건 추가

ALTER TABLE 테이블_이름 ADD CONSTRAINT 제약조건_이름 제약조건_내용;

기존 제약조건 삭제

ALTER TABLE 테이블_이름 DROP CONSTRAINT 제약조건_이름;

테이블 삭제 - DROP TABLE

• 삭제할 테이블을 참조하는 테이블이 있다면 삭제가 수행되지 않음, 삭제하고자 하는 테이블을 참조하는 외래키 제약조건을 먼저 삭제해야 함

SQL을 이용한 데이터 조작

• 데이터 검색, 새로운 데이터 삽입, 데이터 수정, 데이터 삭제로 분류

데이터 검색 - SELECT

• 다양한 검색 유형을 지원하며, 일반 사용자들이 가장 많이 사용

기본검색

SELECT [ALL or DISTINCT] 속성_리스트
FROM 테이블_리스트;

• 테이블과 속성 모두 여러 개를 검색하고 싶을 경우 ,로 구분하여 나열 테이블에 존재하는 모든 속성을 검색하기 위해 SELECT *를 사용할 수 있음 ALL은 기본 설정이지만 명시적 표시 가능, 중복 제거를 위해 DISTINCT 사용 AS 키워드를 통해 출력되는 결과 테이블의 이름 수정 가능

산술식을 이용한 검색

• SELECT 키워드와 함께 산술식을 제시할 수 있지만 실제로 값이 변경되는 것은 아니며 결과 테이블만 변경돼서 출력

조건검색

SELECT [ALL or DISTINCT] 속성_리스트
FROM 테이블_리스트
[WHERE 조건];

• WHERE절 안에 비교 연산자와 논리 연산자를 이용한 검색 조건 제시

LIKE를 이용한 검색

• 검색 조건을 부분적으로만 알 경우 LIKE 키워드를 이용해 검색, 단 문자열을 이용하는 조건에서만 사용
  • % - 0개 이상의 문자, _ - 1개의 문자 LIKE 'DATA%' - DATA로 시작하는 문자열 LIKE '__A%' - 세 번째 글자가 'A'인 문자열

NULL을 이용한 검색

• 검색 조건에서 특정 속성의 값이 널 값인지를 비교하려면 IS NULL 사용 반대의 경우엔 IS NOT NULL / '이름 = NULL' 형태로 표현하면 안됨

정렬 검색

SELECT [ALL or DISTINCT] 속성_리스트
FROM 테이블_리스트
[WHERE 조건]
[ORDER BY 속성_리스트 [ASC or DESC] ];

• 일반적으로 SELECT를 통한 결과 테이블은 DBMS가 정한 순서로 출력되기에 사용자가 원하는 순서로 출력하기 위해선 ORDER BY를 사용함
  • 오름차순 정렬 - ASC (기본 정렬)
  • 내림차순 정렬 - DESC

집계 함수를 이용한 검색

• 특정 속성 값을 통계적으로 계산한 결과를 검색하기 위해 이용 열 함수라고도 하며 개수, 합계, 평균, 최댓값, 최솟값 계산 기능 제공 SUM, AVG는 숫자 데이터 타입만 COUNT, MAX, MIN 모든 데이터(MAX, MIN에서 문자열은 사전의 역/정순서와 같은 방식으로 비교)

  ※주의 사항 - 널인 속성 값은 제외하고 계산, WHERE절에서는 사용할 수 없고 SELECT절이나 HAVING절에서만 사용 집계 함수를 이용해 계산된 결과 값을 출력할 때는 AS 키워드를 사용해 새 이름을 부여하는게 좋음

  COUNT 함수 - 테이블의 모든 속성에 적용하여 개수를 계산할 수 있음 개수를 정확히 계산하려면 널 값이 없는 속성에 COUNT 함수를 적용하는 것이 좋기에 기본키 속성이나 *를 이용 DISTINCT를 사용하여 특정 속성 값의 중복 제거 가능

그룹별 검색

• 테이블에서 특정 속성의 값이 같은 투플을 모아 그룹을 만들고, 그룹별로 검색을 하기 위해 GROUP BY를 사용 그룹에 대한 조건을 추가하려면 GROUP BY와 HAVING을 함께 사용 GROUP BY가 없는 SELECT문은 테이블 전체를 하나의 그룹으로 간주

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

  • 그룹을 나누는 기준이 되는 속성을 SELECT절에 작성하지 않으면 어떤 그룹에 대한 검색 결과인지 확인하기 어려움 그룹별 검색할 때 집계 함수나 GROUP BY절에 있는 속성 외의 속성은 SELECT절에 사용할 수 없음 여러 그룹으로 나눌 경우 기준이 되는 속성을 GROUP BY절에 순서대로 작성

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

• 여러 개의 테이블을 연결하여 데이터를 검색하는 것 조인 검색을 하려면 테이블을 연결해주는 속성이 필요 > 조인 속성(일반적으로 외래키를 사용) 도메인은 반드시 같아야 함 조인 검색을 위한 SQL문은 FROM절에서 검색에 필요한 모든 테이블을 나열, WHERE절에는 조인 속성의 값이 같아야 함을 의미하는 조인 조건을 제시 테이블 이름이 길면 속성 이름 앞에 소속 테이블을 표기하는 일이 번거로울 수 있음 따라서 FROM절에 테이블 이름과 별명을 함께 제시 가능 (AS생략 가능)

서브쿼리(부속 질의문)를 이용한 검색

• SELECT문 안에 또 다른 SELECT문 - 부속 질의문(sub query) 서브쿼리는 괄호로 묶어 작성하고, ORDER BY절을 사용할 수 없으며, 상위 질의문보다 먼저 수행 단일 행 서브쿼리(결과 값을 하나만 반환), 다중 행 서브쿼리(결과 값을 여러 개 반환) 존재 단일 행 서브쿼리는 일반 비교 연산자를 사용할 수 있으나 다중 행 서브쿼리는 사용할 수 없음

• 다중 행 서브쿼리와 함께 사용할 수 있는 연산자

  • IN - 서브쿼리의 결과 값 중 일치하는 것이 있으면 검색 조건이 참
  • NOT IN - 서브쿼리의 결과 값 중 일치하는 것이 없으면 검색 조건이 참
  • EXISTS - 서브쿼리의 결과 값이 하나라도 존재하면 검색 조건이 참
  • NOT EXISTS - 서브쿼리의 결과 값이 하나라도 존재하지 않으면 검색 조건이 참
  • ALL - 서브쿼리의 결과 값 모두와 비교한 결과가 참이면 검색 조건을 만족 (비교 연산자와 함께 사용)
  • ANY or SOME - 서브쿼리의 결과 값 중 하나라도 비교한 결과가 참이면 검색 조건을 만족 (비교 연산자와 함께 사용)

데이터 삽입 - INSERT

• 데이터 삽입은 직접 삽입과 서브쿼리를 이용해 삽입하는 방식으로 나뉨

데이터 직접 삽입

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

• INTO 절에서 속성 이름의 리스트는 생략 가능하지만 생략한 경우 테이블을 정의할 때 지정한 속성의 순서대로 VALUES 절의 속성 값이 삽입됨 VALUES절에 나열되는 속성 값은 문자나 날짜 타입의 데이터인 경우 작은따옴표로 묶음

서브쿼리를 이용한 데이터 삽입

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

데이터 수정 - UPDATE

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

• WHERE절을 생략하면 테이블에 존재하는 모든 투플을 대상 UPDATE문에 서브쿼리가 포함되는 경우도 존재

데이터 삭제 - DELETE

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

• WHERE절을 생략하면 테이블에 존재하는 모든 투플을 삭제하여 빈 테이블이 됨 (DROP TABLE과 다름)

뷰

• 뷰는 다른 테이블을 기반으로 만들어진 가상 테이블 일반 테이블과 달리 데이터를 실제로 저장하고 있지 않음 일반적으로 뷰는 기본 테이블을 기반으로 만들어지지만 다른 뷰를 기반으로 만들 수 있음 동일한 테이블도 어떤 뷰로 보느냐에 따라 보이는 부분이 달라짐 뷰를 통해 내용을 쉽게 검색할 수는 있지만 기본 테이블의 내용을 바꾸는 작업은 제한적

뷰 생성

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

• AS SELECT문은 생성하고자 하는 뷰의 정의를 지니며, ORDER BY를 제외한 일반 SELECT문과 동일 속성의 이름 리스트는 생략 가능하며 생략 시 기존의 이름을 그대로 사용, 하지만 AS SELECT문에서 집계함수를 이용할 경우 속성의 이름을 생략할 수 없음
• WITH CHECK OPTION은 생성한 뷰에 삽입이나 수정 연산을 할 때 SELECT문에서 제시한 뷰의 정의 조건을 위반하면 수행되지 않도록 하는 제약조건을 의미

뷰 활용

• 일반 테이블처럼 원하는 데이터를 검색할 수 있음 뷰에 대한 SELECT문이 내부적으로 기본 테이블에 대한 SELECT문으로 변환되어 수행되기 때문 뷰에 대한 삽입, 수정, 삭제 연산도 기본 테이블에 수행되기에 기본 테이블이 변함 그러나 모든 뷰에 허용되는 것은 아니며 뷰를 통한 기본 테이블의 변화는 제한적

  기본 테이블의 기본키를 지닌 뷰는 INSERT, UPDATE, DELETE가 가능하지만 기본키를 지니지 않은 뷰는 오류가 발생 why? 기본키가 없는 뷰는 어떤 투플에 대한 삽입, 수정, 삭제 연산인지 명확히 구분되지 않음 그리고 집계 함수로 계산된 값은 기본 테이블이 원래 지닌 값이 아니기에 변경을 할 수 없음

  ※ 변경이 되더라도 뷰에 대한 연산은 결과적으로 기본 테이블의 내용을 자동으로 바꾸기 때문에 주의해야 함

변경이 불가능한 뷰의 특징

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

뷰의 장점

• 질의문을 좀 더 쉽게 작성할 수 있다. (특정 조건을 만족하는 투플들로 뷰를 만들어놓으면 WHERE절 없이 쉽게 검색)
• 데이터의 보안 유지에 도움이 된다. (뷰에 포함되지 않은 데이터를 사용자로부터 보호)
• 데이터를 좀 더 편리하게 관리할 수 있다. (제공된 뷰에 포함되지 않은 기본 테이블의 다른 부분은 사용자가 신경 쓸 필요가 없음)

뷰 삭제

DROP VIEW 뷰_이름;

• 뷰를 삭제하더라도 기본 테이블은 영향을 받지 않음

삽입 SQL(임베디드 SQL)

• 프로그래밍 언어로 작성된 응용 프로그램 안에 삽입하여 사용하는 SQL문 삽입SQL문은 프로그램 안에서 일반 명령문이 위치할 수 있는 곳이면 어디든 삽입 가능 프로그램 안의 일반 명령문과 구별하기 위해 앞에 EXEC SQL을 붙임 프로그램에 선언된 일반 변수를 사용할 수 있으나 앞에 :를 붙여 테이블 이름이나 속성의 이름과 구분함

• 여러 개의 행을 반환하는 SELECT문을 사용할 경우 커서라는 도구가 필요

  커서

• 수행 결과로 반환된 여러 행을 한 번에 하나씩 가리키는 포인터 역할

  커서가 필요 없는 삽입 SQL

  CREATE문, INSERT문, DELETE문, UPDATE문, 결과로 행 하나만 반환하는 SELECT문

  커서가 필요한 삽입 SQL

  여러 행을 결과로 반환하는 SELECT문

출처 - 김연희저자의 데이터베이스 개론 2판 - 한빛 아카데미

• 관계 데이터 모델에서 연산은 원하는 데이터를 얻기 위해 릴레이션에 필요한 처리 요구를 수행하는 것 데이터 시스템의 구성 요소 중 데이터 언어의 역할

• 관계 대수 원하는 결과를 얻기 위해 데이터의 처리 과정을 순서대로 기술 / 절차 언어

• 관계 해석 원하는 결과를 얻기 위해 처리를 원하는 데이터가 무엇인지만 기술 / 비절차 언어

데이터를 처리하는 기능과 처리를 요구하는 표현력에서 관계 대수와 관계 해석은 능력이 동등 데이터에 대한 처리 요구를 일반적으로 질의(query)라고 한다.

관계 대수와 관계 해석을 공부하는 이유 새로운 데이터 언어가 제안되면 데이터 언어의 유용성 검증의 기준

관계 대수

원하는 결과를 얻기 위해 데이터의 처리 과정을 순서대로 기술 (연산자들의 집합) 피연산자가 릴레이션, 즉 관계 대수는 릴레이션을 연산함 폐쇄 특성(closure property) - 릴레이션에 연산자를 적용해 얻은 결과도 릴레이션 대표적인 연산자 8개 존재하며 일반 집합 연산자, 순수 관계 연산자로 구분

일반 집합 연산자

• 피연산자가 2개가 필요 합집합, 교집합, 차집합은 2개의 릴레이션이 합병 가능 해야 함 (카티션 프로덕트는 예외)

  릴레이션 합병 가능

  • 두 릴레이션의 차수가 같다
  • 서로 대응되는 속성의 도메인이 같다

합집합(union)

• R⋃S, 릴레이션 R에 속하거나 릴레이션 S에 속하는 모든 투플의 결과 릴레이션을 구성 교환적 특징, 결합적 특징

교집합(intersection)

• R∩S, 릴레이션 R과 S에 공통으로 속하는 투플로 결과 릴레이션을 구성 교환적 특징, 결합적 특징

차집합(difference)

• R-S, 릴레이션 R에는 존재하지만 릴레이션 S에는 존재하지 않는 투플들로 결과 릴레이션을 구성 교환적, 결합적 특징이 없음

카티션 프로덕트(cartesian product)

• R⨉S, 릴레이션 R과 릴레이션 S에 속한 각각의 투플을 모두 연결하여 결과 릴레이션을 구성 교환적 특징, 결합적 특징

순수 관계 연산자

• 릴레이션의 구조와 특성을 이용 릴레이션에 저장되어 있는 데이터를 다양하게 처리하는 데 자주 사용

셀렉트

• 릴레이션에서 주어진 조건을 만족하는 투플만 선택하여 결과 릴레이션을 구성, 수평적 연산자

  σ 조건식(릴레이션)

  하나의 릴레이션을 대상으로 수행하며, 조건식은 비교 연산자를 이용해 구성 조건식을 속성과 상수의 비교나 다른 속성들 간의 비교로 표현 가능 (데이터 타입이나 도메인이 일치해야 함), 교환적 특징

프로젝트

• 릴레이션에서 선택한 속성에 해당하는 값으로 결과 릴레이션을 구성, 수직적 연산자

  π속성리스트(릴레이션)

  프로젝트 연산을 한 결과는 릴레이션의 모든 속성 중 일부분만 선택으로 볼 수 있음

조인

• 데이터를 얻기 위해 관계가 있는 여러 릴레이션을 함께 사용해야하는 경우 이용 조인 속성(join attribute)을 이용해 두 릴레이션을 조합하여 하나의 결과 릴레이션을 구성

  조인 속성 - 두 릴레이션이 공통으로 가지고 있는 속성

  결과 릴레이션은 조인 속성의 값이 같은 투플만 연결하여 만들어짐

  릴레이션1 ⋈ 릴레이션2

  두 릴레이션을 조인하는 이유 - 조건에 맞는 투플을 찾기 위해서

  • 자연 조인(natural join) 가장 많이 사용되기 때문에 조인이라고 하면 자연 조인을 의미

• 세타 조인(theta join) 주어진 조인 조건을 만족하는 두 릴레이션의 모든 투플을 연결

  릴레이션1 ⋈AθB 릴레이션2

  AθB는 조인 조건으로, A는 릴레이션1의 속성이고 B는 릴레이션2의 속성, θ는 비교 연산자 A와 B는 같은 도메인으로 정의 θ 연산자가 '='인 세타 조인을 동일 조인(equi-join)이라고 함 자연 조인과 달리 동일 조인의 결과 릴레이션에는 속성이 중복되어 나타남 ex) 고객 ⋈고객아이디=주문고객 주문 연산 시, 결과 릴레이션에 고객아이디와 주문고객 둘 다 나타남

디비전(division)

• R÷S, 릴레이션 S의 모든 투플과 관련 있는 릴레이션 R의 투플로 결과 릴레이션을 구성 정수의 나눗셈과 유사

확장된 관계 대수 연산자

세미 조인(semi join)

• R⋉S, 릴레이션 S의 조인 속성으로만 구성한 릴레이션을 릴레이션 R에 자연 조인하는 것 R에서 자연 조인 연산에 참여할 수 있는 투플만 선택하여 결과 릴레이션을 구성 검색에 불필요한 속성을 미리 제거하여 조인 연산의 비용을 줄일 수 있다는 장점 교환 특성이 없음

외부 조인(outer-join)

• R⋈+S, 자연 조인 연산을 수행할 때 조인 속성 값이 같은 투플이 상대 릴레이션에 존재하지 않아도 포함 존재하지 않는 값은 널 값으로 처리

관계 해석

• 원하는 데이터가 무엇인지만 기술하는 비절차 언어, 관계 데이터 연산의 한 종류, 프레디킷 해석에 기반 투플 관계 해석과 도메인 관계 해석으로 분류

출처 - 김연희저자의 데이터베이스 개론 2판 - 한빛 아카데미

• 논리적 데이터 모델 중 가장 인기 있는 모델 하나의 개체에 관한 데이터를 릴레이션 하나에 담아 데이터베이스에 저장

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

속성

• 릴레이션의 열을 속성 또는 애트리뷰트(attribute)라고 부름 각 속성은 서로 다른 이름을 이용해 구별

투플

• 릴레이션의 행을 투플(tuple)이라 부름

도메인

• 속성 하나가 가질 수 있는 모든 값의 집합을 해당 속성의 도메인(domain)이라고 함 관계 데이터 모델에서는 속성 값으로 더는 분해할 수 없는 원자 값만 사용 (도메인은 특정 속성이 가질 수 있는 모든 원자 값의 모임)
• 도메인을 정의해두면 사용자가 속성 값을 입력하거나 수정할 때 데이터베이스 시스템이 적합성을 판단하여 해당 값 이외의 값은 허용하지 않음으로써 항상 올바른 값만 유지한다는 장점 존재 프로그래밍 언어에서 데이터 타입과 변수의 관계로 이해할 수 있음 ex) 데이터 타입을 도메인, 변수를 속성

널 값

• 릴레이션에 있는 특정 투플의 속성 값을 모르거나, 적합한 값이 없는 경우에는 널(null)이라는 특별한 값을 사용할 수 있음 널 값은 특정 속성에 해당되는 값이 없음을 나타냄으로 숫자 0이나 공백 문자와는 다름

차수

• 하나의 릴레이션에서 속성의 전체 개수를 릴레이션의 차수(degree)라고 함 모든 릴레이션은 최소 1 이상의 차수를 유지해야 함 릴레이션의 차수는 일반적으로 자주 변하지 않는다는 정적인 특징을 지님

카디널리티

• 하나의 릴레이션에서 투플의 전체 개수를 릴레이션의 카디널리티(cardinality)라고 함 투플이 없는 릴레이션이 존재할 수도 있고, 새로운 투플이 삽입되거나 기존의 투플이 삭제될 수 있으므로 릴레이션의 카디널리티는 일반적으로 자주 변한다는 동적인 특징을 지님

릴레이션은 파일 관리 시스템에서의 파일, 속성은 해당 파일의 필드, 투플은 개체의 인스턴스이며 레코드에 대응하는 개념이다.

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

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

릴레이션 스키마(relation schema)

• 릴레이션의 이름과 릴레이션에 포함된 모든 속성의 이름으로 정의하는 릴레이션의 논리적 구조 릴레이션 스키마는 데이터베이스 관리 시스템이 내부적으로 데이터 정의어를 이용해 정의 일반적으로 릴레이션이름(속성이름1, 속성이름2, ... , 속성이름n)'과 같은 형태로 표현 릴레이션 스키마를 보면 릴레이션의 이름이 무엇이고, 어떤 속성들로 구성되어 있는지 전체 구조를 쉽게 파악 가능

• 릴레이션 스키마는 릴레이션 내포(relation intension)이라고도 부른다

릴레이션 인스턴스(relation instance)

• 어느 한 시점에 릴레이션에 존재하는 투플들의 집합 릴레이션 인스턴스에 포함된 투플은 릴레이션 스키마에서 정의한 각 속성에 대응하는 실제 값으로 구성되어 있음 릴레이션 인스턴스를 보면 현재 릴레이션의 실제 내용을 쉽게 파악할 수 있음 데이터베이스 관리 시스템이 내부적으로는 데이터 조작어를 이용해 릴레이션 인스턴스의 투플을 검색하거나, 새로운 투플 삽입과 기존 투플 삭제 및 수정을 진행

• 릴레이션 인스턴스는 간단히 릴레이션이라 부르거나 릴레이션 외연(relation extension)이라고도 부른다

릴레이션 스키마 - 정적인 특징, 릴레이션 인스턴스 - 동적인 특징

데이터베이스 스키마

• 데이터베이스를 구성하는 릴레이션들의 스키마를 모아놓은 것 특정 데이터베이스 스키마를 설계한다는 것은 필요한 모든 릴레이션의 스키마를 모두 정의한다는 뜻

데이터베이스 인스턴스

• 어느 한 시점에서 데이터베이스에 저장된 데이터 내용의 전체 집합을 의미 데이터베이스를 구성하는 모든 릴레이션의 인스턴스를 모아놓은 것

릴레이션의 특징

1) 투플의 유일성 - 하나의 릴레이션에는 동일한 투플이 존재할 수 없다

• 모든 투플에는 다른 투플과 구별되는 유일한 특성이 있어야 함 (key를 이용하여 유일성 판단)

2) 투플의 무순서 - 하나의 릴레이션에서 투플 사이의 순서는 무의미하다

• 데이터베이스는 위치가 아닌 내용으로 검색되므로 투플의 순서는 중요하지 않음 삽입 순서에 따라 저장되지만, 효율적인 처리를 위해 투플의 순서를 임의로 변경하기도 함

3) 속성의 무순서 - 하나의 릴레이션에서 속성 사이의 순서는 무의미하다

• 속성 값은 릴레이션에서 위치가 아닌 속성의 이름으로 접근함

4) 속성의 원자성 - 속성 값으로 원자 값만 사용할 수 있다

• 하나의 속성은 여러 개의 값, 즉 다중 값을 가질 수 없음 현실에서는 존재할 수 있으나 관계 데이터 모델은 복잡한 개념을 배제하고 릴레이션을 단순한 구조로 정의하고자 하는 특징 (다중 값을 허용 안함)

키의 종류

키(key)

• 릴레이션에 포함된 투플들을 유일하게 구별해주는 역할 관계 데이터 모델에서 중요한 제약조건을 정의 및 투플을 처리하는 데 중요한 역할을 수행
• 슈퍼키(super key), 후보키(candidate key), 기본키(primary key), 대체키(alternate key), 외래키(foreign key)가 존재

슈퍼키

• 슈퍼키는 유일성(uniqueness)의 특성을 만족하는 속성 또는 속성들의 집합

  유일성은 키가 갖추어야 하는 기본 특성이며, 하나의 릴레이션에서 키로 지정된 속성 값은 투플마다 달라야 한다는 의미 > 키 값이 같은 투플은 존재할 수 없다

후보키

• 후보키는 유일성과 최소성(minimality)을 만족하는 속성 또는 속성들의 집합

  최소성은 꼭 필요한 최소한의 속성들로만 키를 구성하는 특성이며, 하나의 속성으로 구성된 키는 최소성을 만족

슈퍼키 중에서 최소성을 만족하는 것이 후보키가 됨

후보키가 되기 위해 만족해야 하는 유일성과 최소성의 특성은 새로운 투플이 삽입되거나 기존 투플의 속성 값이 바뀌어도 유지되어야 함 현재의 릴레이션 내용, 즉 릴레이션 인스턴스만 보고 유일성과 최소성을 판단해서는 안됨 데이터베이스가 사용될 현실 세계의 환경까지 염두에 두고 속성의 본래 의미를 정확히 이해한 후 슈퍼키와 후보키를 선별해야 함

기본키

• 데이터베이스 설계자나 관리자가 여러 후보키 중에서 기본적으로 사용할 키를 선택한 것 후보키가 여러 개일 경우 데이터베이스 사용 환경을 고려하여 적합한 것을 기본키로 선택

• 기본키 선택 고려 사항

  • 널 값을 가질 수 있는 속성이 포함된 후보키는 부적합
  • 값이 자주 변경될 수 있는 속성이 포함된 후보키는 부적합
  • 단순한 후보키 선택

대체키

• 기본키로 선택되지 못한 후보키

외래키

• 어떤 릴레이션에 소속된 속성 또는 속성 집합이 다른 릴레이션의 기본키가 되는 키

• 다른 릴레이션의 기본키를 그대로 참조하는 속성의 집합* 외래키는 릴레이션들 사이의 관계를 올바르게 표현하기 위해 필요

• 참조하는 릴레이션과 참조되는 릴레이션이 같을 수도 있음 (자기 참조)

  외래키는 기본키를 참조하지만 기본키가 아니기 때문에 널 값을 가질 수 있고, 서로 다른 투플이 같은 값을 가질 수 있음

  외래키가 되는 속성과 기본키가 되는 속성의 이름은 달라도 된다 하지만 외래키 속성의 도메인과 기본키 속성의 도메인은 반드시 같아야 한다 도메인이 같아야 연관성 있는 투플을 찾기 위한 비교 연산이 가능 외래키가 참조되는 릴레이션의 기본키가 아닌 다른 키를 참조할 경우 투플을 유일하게 특정짓기 어렵기 때문에 관련 있는 투플을 검색하지 못할 수도 있음

관계 데이터 모델의 제약

관계 데이터 모델에서 정의하고 있는 기본 제약 사항은 키와 관련한 무결성 제약조건(integrity constraint)

무결성

• 데이터에 결함이 없는 상태, 즉 데이터가 정확하고 유효하게 유지된 상태를 의미

  무결성 제약조건의 주요 목적

• 데이터베이스에 저장된 데이터의 무결성을 보장하고, 데이터베이스의 상태를 일관되게 유지하는 것 무결성 제약조건은 데이터베이스가 어떤 상태나 시점에서도 무조건 지켜야 하는 중요한 규칙

개체 무결성 제약조건(entity inegrity constraint)

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

  개체 무결성 제약조건을 만족시키려면 새로운 투플이 삽입되는 연산과 기존 투플의 기본키 속성 값이 변경되는 연산이 발생할 때 기본키에 널 값이 포함되는 상황에서는 연산의 수행을 거부해야 함 이것은 DBMS가 자동으로 수행하기에 사용자는 새로운 릴레이션을 생성할때 기본키를 어떤 속성들로 구성할 것인지 전달만 하면 됨

참조 무결성 제약조건(referential inegrity constraint)

• 외래키는 참조할 수 없는 값을 가질 수 없다는 규칙 외래키가 자신이 참조하는 릴레이션의 기본키와 상관이 없는 값을 가지게 되면 두 릴레이션을 연관시킬 수 없으므로 외래키 본래의 의미가 없어짐

  외래키는 참조 가능한 값만 가져야 하지만, 널 값을 가진다고 해서 참조 무결성 제약조건을 위반한 것으로 판단해서는 안됨

• 참조되는 릴레이션A 에서 투플a가 삭제될 경우 연관된 투플b가 참조하는 릴레이션 B에 남아 있으면

  • 해당 투플a를 삭제하는 연산을 수행하지 않음
  • 연관된 투플b를 함께 삭제
  • 투플b를 null 값이나 기본 값으로 지정

  셋 중 하나를 이용하여 참조 무결성 제약조건을 만족시켜야 함

  데이터베이스 상태가 빈번하게 변경되는 경우 참조 무결성 제약조건을 만족시키기 쉽지 않지만 이는 DBMS에서 자동으로 수행 사용자는 어떤 속성들이 외래키이고 어떤 릴레이션의 기본키를 참조하면 되는지 전달하고, 위반하게 되는 경우에 어떻게 처리할지 설정만 하면 됨

출처 - 김연희저자의 데이터베이스 개론 2판 - 한빛 아카데미

데이터베이스

현실 세계에 존재하는 수많은 데이터 중에서 조직을 운영하는 데 꼭 필요한 데이터만 선별하여 저장한 것

데이터 모델링(data modeling)

현실 세계의 데이터를 컴퓨터 세계의 데이터베이스로 옮기는 변환 과정 데이터베이스 설계의 핵심 과정 필요한 데이터만 선별하기 위해선 많은 고민과 결정이 필요하기에 어려운 작업

• 추상화(abstraction) - 데이터베이스에 저장하여 관리할 만한 가치가 있는 중요 데이터를 추출하는 것

• 개념적 모델링(conceptual modeling) - 현실 세계에서 중요 데이터를 추출하여 개념 세계로 옮기는 작업

• 논리적 모델링(logical modeling) - 개념 세계의 데이터를 데이터베이스에 저장할 구조를 결정하고 이 구조로 표현하는 작업

데이터 모델

데이터 모델링의 결과물을 표현하는 도구 데이터 구조(data structure), 연산(operation), 제약조건(constraint)로 구성

• 데이터 구조 - 자주 변하지 않고 정적이라는 특징 존재
• 연산 - 데이터 구조에 따라 개념 세계나 컴퓨터 세계에서 실제로 표현된 값들을 처리하는 작업, 동적이라는 특징 존재
• 제약조건 - 구조적 측면, 의미적 측면의 제약 사항이 존재

  개념적 데이터 모델에서 데이터 구조 - 현실 세계를 개념 세계로 추상화했을 때 어떤 요소로 이루어져 있는지를 표현하는 개념적 구조 논리적 데이터 모델에서 데이터 구조 - 데이터를 어떤 모습으로 저장할 것인지를 표현하는 논리적 구조

데이터베이스 설계 = 개념적 데이터 모델링 + 논리적 데이터 모델링 사용하는 데이터 모델에 따라 현실 세계를 표현하는 개념적 구조나 논리적 구조의 모습이 달라짐

대표적으로 많이 사용되는 모델 개체-관계 모델(E-R Model) 관계 데이터 모델(relational data model) 자세한 내용은 5장에서

개체-관계 모델

개체와 개체 간의 관계를 이용해 현실 세계를 개념적 구조로 표현하는 방법 머릿속에 그릴 수 있는 개념적인 구조로 모델링하는 것이기에 어떤 DBMS로 데이터베이스를 구축하는지 상관 없음

개체-관계 모델을 그림으로 표현한 것이 개체-관계 다이어그램(E-R Diagram)

개체(entity)

현실 세계에서 저장할 만한 가치가 있는 중요 데이터를 지닌 사람이나 사물 등을 의미 개념적 모델링을 하는 데 가장 중요한 요소 개념이나 사건처럼 물리적으로 존재하지 않는 것도 개체가 될 수 있음 ex) 대학교의 학과 개체는 다른 개체와 구별되는 이름을 가지고 있고, 각 개체만의 고유한 특성이나 상태, 즉 속성을 하나 이상 지님

• 개체 타입 - 개체를 고유의 이름과 속성들로 정의한 것
• 개체 인스턴스 - 개체를 구성하고 있는 속성이 실제 값을 가짐으로써 실체화된 개체
• 개체 집합 - 개체 인스턴스들의 집합 개체-관계 모델에서 개체와 속성은 파일 구조에서의 레코드와 필드에 대응됨

속성(attribute)

개체가 가지고 있는 고유의 특성 속성은 그 자체만으로는 의미가 없지만 관련 있는 속성들을 모아 개체를 구성하면 하나의 중요한 의미를 표현할 수 있음 속성은 일반적으로 의미 있는 데이터의 가장 작은 논리적 단위로 인식됨

속성 분류 기준 속성 값의 개수, 의미의 분해 가능성, 기존 속성 값에서 유도

• 속성 값의 개수 단일 값 속성- 특정 개체를 구성하는 속성의 값이 하나 ex)고객의 이름 다중 값 속성 - 특정 개체를 구성하는 속성이 값을 여러 개를 가짐 ex)고객의 연락처(집 전화번호, 휴대폰 번호)

• 의미의 분해 가능성 단순 속성 - 의미를 더는 분해할 수 없는 속성 복합 속성 - 의미를 분해할 수 있어 값이 여러 개의 의미를 포함하는 속성 (여러 개의 단순 속성이 모여 만들어진 속성) - 하나의 단순 속성으로 처리를 하는 경우도 존재 ex)생년월일

• 기존 속성 값에서 유도 유도 속성 - 값이 별도로 저장되는 것이 아니라 기존의 다른 속성 값에서 유도되어 결정되는 속성 ex)제품의 판매가격(기존 가격과 할인율을 통해 유도)

• 널 속성 - 널 값이 허용되는 속성 ex) 병역 속성

  널 값은 데이터베이스에서 여러 가지로 중요한 의미를 지님 (아직 결정되지 않았거나 모르는 값, 존재하지 않는 값) 공백이나 0과 다른 의미를 지님

• 키 속성 - 개체 집합에 존재하는 각 객체 인스턴스들을 식별하는 데 사용 ex)고객 아이디 키를 둘 이상의 속성들로 구성하는 경우도 존재 개체 타입을 정의할 때 중요한 제약조건은 키 속성의 값이 개체 인스턴스마다 달라서 이 값으로 개체 인스턴스를 식별할 수 있어야 한다는 것

관계(relationship)

개체와 개체가 맺고 있는 의미 있는 연관성 개체 집합들 사이의 대응 관계(correspondence), 즉 매핑(mapping)을 의미 업무 처리에 대한 요구 사항을 개체들을 이용해 하나의 문장으로 만들었을 때 동사에 해당하는 것 ex) 고객은 책을 구매한다. 관계를 통해서만 개체들 간의 연관성을 이용한 업무를 처리할 수 있음 여러 개체 사이에서 정의되는 관계 타입과 개체 인스턴스들 간에 맺어진 실제 관계인 관계 인스턴스로 구분하여 표현하기도 함

관계도 개체처럼 속성을 지닐 수 있음 관계를 맺음으로써 발생하는 중요한 데이터들이 관계의 속성이 됨 ex) 구매 관계 속에 포함되는 [구매일자], [결제방식]

관계의 유형

관계에 참여하는 개체 타입의 수에 의해 이항, 삼항, 순환 관계로 구분

매핑 카디널리티(mapping cardinality)

데이터베이스 설계 과정에서 중요하게 활용되는 관계의 분류 기준 (1:1관계, 1:n관계, n:m관계)

• 일대일(1:1) 관계 개체 A의 개체 인스턴스 하나가 다른 개체 B의 개체 인스턴스 하나와 관계를 맺는다면 두 개체의 관계는 일대일 관계 ex) 혼인 관계
• 일대다(1:n) 관계 개체 A의 개체 인스턴스 하나가 다른 개체 B의 여러 개체 인스턴스와 관계를 맺지만, 개체 B의 개체 인스턴스들은 개체 A의 개체 인스턴스 하나만 관계를 맺는 경우 두 개체의 관계는 일대다 관계 ex) 부서와 사원
• 다대다(n:m) 관계 개체 A의 개체 인스턴스 하나가 다른 개체 B의 여러 개체 인스턴스와 관계를 맺고, 개체 B의 인스턴스들도 마찬가지라면 두 개체의 관계는 다대다 관계 ex) 학생과 강의 관계

관계의 참여 특성

개체 A와 B 사이의 관계에서 개체 A의 모든 개체 인스턴스가 관계에 반드시 참여해야 된다면 개체 A가 관계에 '필수적 참여한다' 또는 '전체 참여한다' 라고 함 개체 A의 개체 인스턴스 중 일부만 관계에 참여해도 되면 개체 A가 관계에 '선택적 참여한다' 또는 '부분 참여한다' 라고 함

관계의 종속성

개체 A가 독자적으로 존재할 수 없고 다른 개체 B의 존재 여부에 의존적이라면 개체 A가 개체 B에 종속되어 있다고 함

• 존재 종속(existence dependence) - 개체 B가 삭제되면 개체 A도 삭제되어야 함을 의미
• 약한 개체(weak entity) or 종속 개체 - 다른 개체의 존재 여부에 의존적인 개체
• 강한 개체(strong entity) or 오너 개체 - 다른 개체의 존재 여부를 결정하는 개체

  강한 개체와 약한 개체는 일반적으로 일대다의 관계이며, 약한 개체는 강한 개체와의 관계에서 필수적으로 참여한다는 특징을 지님 약한 개체는 자신이 지닌 속성만으로는 식별이 어려워 일반적으로 강한 개체의 키를 포함하여 키를 구성 (직원 개체와 부양가족 개체) 약한 개체를 구별해주는 속성을 구별자(delimiter) 또는 부분키(partial key)라고 함

  E-R 다이어그램

  개체-관계 모델을 이용해 현실 세계를 개념적으로 모델링한 결과물을 그림으로 표현한 것 글로 작성하는 것보다 이해하기 쉽기에 많이 선호됨 개체는 사각형, 속성은 타원으로 표기하며, 속성에서 키 속성은 밑줄, 다중 값 속성은 이중 타원, 유도 속성은 점선 타원으로 표현함 관계는 마름모 약한 개체는 이중 사각형, 약한 개체가 맺는 관계는 이중 마름모로 표기하고, 선택적 참여는 실선, 필수적 참여는 이중선으로 표현 일대일, 일대다, 다대다 관계는 레이블로 표기

논리적 데이터 모델

E-R 다이어그램으로 표현된 개념적인 구조를 논리적 데이터 모델을 통해 데이터베이스에 표현하는 형태를 결정하기에 DBMS 종류가 중요 논리적 데이터 모델은 논리적 데이터 모델링의 결과물이고, 사용자가 생각하는 데이터베이스의 모습 논리적 데이터 모델로 표현된 데이터베이스의 논리적 구조가 바로 데이터베이스 스키마(schema) 논리적 구조는 사용하는 DBMS에 따라 달라짐

관계 데이터 모델(relational data model)

데이터베이스의 논리적 구조가 2차원 테이블 형태 일반적으로 많이 사용되는 모델 (자세한 내용은 5장에서 다룸)

계층 데이터 모델(hierarchical data model)

데이터베이스의 논리적 구조가 트리 형태 상위에 있는 개체를 부모 개체, 하위에 있는 개체를 자식 개체라 하고, 이들 사이의 일대다 관계를 부모 자식 관계라고 함 각 부모는 다수의 자식을 가질 수 있고, 자식은 단 하나만의 부모를 가질 수 있음 개체 사이의 관계를 정의할 때 여러 제약이 존재하기에 개념적 구조를 논리적 구조로 자연스럽게 모델링하기 어렵고 구조가 복잡해질 수 있음 데이터의 연산이나 원하는 데이터를 검색하기 쉽지 않음

네트워크 데이터 모델(newtwork data model)

데이터베이스의 논리적 구조가 그래프 또는 네트워크 형태 계층 데이터 모델과 달리 두 개체 간의 관계를 여러 개 정의할 수 있어 관계를 이름으로 구별 같은 개체들 사이의 관계를 두 개 이상 표현할 수 있어 계층 데이터 모델보다 개념적 구조를 논리적 구조로 좀 더 자연스럽게 모델링 가능 하지만 계층 데이터 모델보다 구조가 더 복잡해질 수 있으며, 데이터의 연산과 데이터 검색이 더 여러워질 수 있음

추가적으로 객체지향 데이터 모델, 객체관계 데이터 모델 존재하지만 누구나 쉽게 이해할 수 있는 구조와 데이터의 검색,삭제,수정 등의 연산을 제공하는 관계 데이터 모델이 인기가 많으며 대중적으로 사용

출처 - 김연희저자의 데이터베이스 개론 2판 - 한빛 아카데미

데이터베이스와 데이터베이스 관리 시스템을 이용해 필요한 정보를 제공해주는 전체 시스템

데이터베이스 시스템의 구성 요소

사용자, 데이터 언어, 데이터베이스, 데이터베이스 관리 시스템, 컴퓨터

스키마(schema)

• 스키마 - 데이터베이스에 저장되는 데이터 구조와 제약조건을 정의
• 인스턴스 - 정의된 스키마에 따라 데이터베이스에 실제로 저장된 값

스키마는 한번 정의되면 자주 변경되지 않으나, 인스턴스는 계속 변하는 특성 존재

3단계 데이터베이스 구조

• 개별 사용자 관점 - 외부 단계(external level)
• 조직 전체의 관점 - 개념 단계(conceptual level)
• 물리적인 저장 장치의 관점 - 내부 단계(internal level)

외부 단계

• 개별 사용자가 데이터베이스를 어떻게 보는가를 표현 -> 사용자마다 생각하는 데이터베이스의 구조가 다름
• 외부 단계에서 사용자에게 필요한 데이터베이스를 정의한 것 - 외부 스키마(서브 스키마)
• 데이터베이스 하나에 외부 스키마가 여러 개가 존재할 수 있고, 외부 스키마 하나를 목적이 같은 사용자들이 공유 가능

  개념 단계

• 사용자들의 관점을 통합하여, 데이터베이스를 조직 전체의 관점에서 이해하고 표현
• 개념 단계에서 모든 사용자에게 필요한 데이터를 통합하여 전체 데이터베이스의 논리적 구조를 정의한 것 - 개념 스키마 개념 스키마 - 조직 전체의 관점에서 생각하는 데이터베이스의 모습이며, 어떤 데이터가 저장되는지, 데이터들 간의 관계, 제약조건, 데이터에 대한 보안 정책, 접근 권한에 대한 내용들 포함하지만 데이터를 물리적으로 저장하는 방법이나 데이터 저장 장치와는 독립적

  데이터베이스 하나에 개념 스키마는 하나만 존재 일반적으로 스키마라고 언급하면 개념 스키마를 의미한다.

내부 단계

• 데이터베이스를 저장 장치의 관점에서 이해하고 표현
• 내부 단계에서 전체 데이터베이스가 저장 장치에 실제로 저장되는 방법을 정의한 것 - 내부 스키마 내부 스키마 - 데이터베이스의 개념 스키마에 대한 물리적인 저장 구조를 표현한 것이며 하나만 존재

데이터 독립성

하나의 데이터베이스에는 3가지 유형의 스키마가 존재하나 각각의 스키마는 데이터베이스를 바라보는 관점이 다를 뿐 모두 같은 데이터베이스를 표현 스키마 사이의 대응 관계 - 사상, 매핑(mapping) DBMS는 미리 정의된 매핑 정보를 이용하여 사용자가 원하는 데이터에 접근할 수 있음

3단계 데이터베이스 구조, 단계별 스키마 유지, 매핑을 정의하는 목적 ==> 데이터 독립성 실현

데이터 독립성은 DBMS의 중요한 장점이자 존재 의의이며, 하위 스키마를 변경하더라도 상위 스키마가 영향을 받지 않는 특성 논리적 데이터 독립성(외부/개념), 물리적 데이터(개념/내부) 독립성 존재

• 논리적 데이터 독립성 - 개념 스키마가 변경되더라도 외부 스키마가 영향을 받지 않는 것 논리적인 구조가 변경되어도 관련된 매핑(응용 인터페이스)만 적절히 수정하면 외부 스키마 변경할 필요 없음 => 외부 스키마의 사용자가 전체 데이터베이스의 논리적 구조가 변경되었다는 사실을 알 필요가 없음

• 물리적 데이터 독립성 - 내부 스키마가 변경되더라도 개념 스키마가 영향을 받지 않는 것 저장 구조가 변경되어도 매핑(저장 인터페이스)만 적절히 수정하면 논리적 구조는 영향을 받지 않음

데이터 사전

데이터베이스에 저장되는 데이터에 관한 정보를 저장하는 장소 (다른 용어로는 시스템 카탈로그, 메타 데이터) 스키마와 사상 정보(매핑) 그리고 제약조건을 저장 일반 사용자도 접근할 수 있으나 저장 내용에 대한 검색만 가능

데이터 디렉터리 - 데이터 사전에 있는 데이터에 실제로 접근하는 데 필요한 위치 정보 관리 (사용자 접근 불가)

데이터베이스 사용자

데이터베이스 사용자에는 데이터베이스 관리자, 최종 사용자, 응용 프로그래머가 존재

데이터베이스 관리자(DBA)

데이터베이스 시스템을 운영 및 관리하며, 조직 내의 사용자를 위해 데이터베이스를 설게 및 구축, 제대로 서비스할 수 있도록 데이터베이스를 제어, 데이터 정의어와 데이터 제어어를 이용해 데이터베이스에 접근 데이터베이스 운영,관리를 책임지므로 컴퓨터 시스템이나 데이터베이스와 관련해 많은 지식과 경험 필요

• 데이터베이스 구성 요소 선정 - 사용자의 요구 사항을 분석하여 데이터를 결정
• 데이터베이스 스키마 정의 - 구성 요소를 토대로 데이터베이스 스키마를 설계, 데이터 정의어를 이용해 설계한 스키마를 DBMS에 설명
• 물리적 저장 구조와 접근 방법 결정 - 레코드 구조를 설계, 레코드 간의 저장 순서와 빠른 접근을 위한 인덱스를 만들 기준 필드 결정
• 무결성 유지를 위한 제약조건 정의 - 결함 없는 데이터만 저장할 수 있도록 규칙을 정의, 규칙에 따라 데이터베이스를 제어하여 데이터의 정확성, 유효성 유지
• 보안 및 접근 권한 정책 결정 - 비인가 사용자의 접근 방지, 인가된 사용자에게 적절한 권한을 부여하는 보안 정책 결정
• 백업 및 회복 기법 정의 - 장애에 대비하여 데이터베이스를 백업, 손상된 데이터베이스를 일관된 상태로 복구하는 방법을 정의
• 시스템 데이터베이스 관리 - 데이터 사전 등을 관리
• 시스템 성능 감시 및 성능 분석 - 병목 현상 등이 발생하지 않는지 확인, 시스템 자원의 활용도 분석 등을 통해 시스템의 성능을 감시
• 데이터베이스 재구성 - 사용자의 요구 사항이나 사용 형태에 맞게, 시스템의 전체 성능 향상 필요성, 시스템 장비가 교체된 경우 데이터베이스를 재구성 데이터베이스 관리자는 항상 사용자의 요구 사항에 귀 기울이고 시스템 성능을 분석하여, 새로운 변화에 부응하면서 성능을 향상시키는 방향으로 데이터베이스를 재구성해야 함

최종 사용자

데이터를 조작하기 위해 데이터베이스에 접근하는 사람들, 주로 데이터 조작어를 사용

• 캐주얼 사용자 - 데이터베이스에 대한 이론적 지식, 주로 데이터 조작어를 이용해 원하는 데이터와 데이터 처리를 DBMS에 직접 설명
• 초보 사용자 - 메뉴나 GUI 형태의 응용 프로그램을 통해 데이터베이스를 사용

응용 프로그래머

프로그래밍 언어로 응용 프로그램을 작성할 때 데이터베이스에 접근하는 데이터 조작어를 삽입하는 사용자 최종 사용자는 응용 프로그래머가 작성한 응용 프로그램을 사용하여 데이터베이스에 접근 ex)도서 위치를 검색

데이터 언어

데이터 정의어(DDL)(CREATE, ALTER, DROP, TRUNCATE) 데이터 조작어(DML)(SELECT, INSERT, UPDATE, DELETE) 데이터 제어어(DCL)(GRANT,REVOKE,COMMIT,ROLLBACK)

데이터 정의어

새로운 데이터베이스를 구축하기 위해 스키마를 정의하거나 기존 스키마의 정의를 삭제 또는 수정하기 위해 사용하는 데이터 언어 새로 만들려는 데이터베이스의 스키마를 설명하거나 이미 정의된 스키마의 구조나 제약조건 등을 변경 또는 삭제할 경우 DBMS에 알릴 때 사용 데이터 정의어로 정의된 스키마는 데이터 사전에 저장되고, 삭제나 수정이 발생하면 데이터 사전에 반영

데이터 조작어

사용자가 데이터의 삽입,삭제,수정,검색 등의 처리를 DBMS에 요구하기 위해 사용하는 데이터 언어 사용자가 실제 데이터 값을 활용하기 위해 사용하는 것

• 절차적 데이터 조작어 - what과 how를 설명 / 절차(how)도 설명하는 것
• 비절차적 데이터 조작어 - what만 설명 / 선언적 언어 / how는 DBMS에 일임

데이터 제어어

데이터베이스에 동시 공유가 가능하면서도 무결성과 일관성을 유지하도록 내부적으로 필요한 규칙이나 기법을 정의하는 데 사용하는 데이터 언어 데이터 제어어를 이용해 DBMS에 설명하면 DBMS는 이 규칙과 기법에 따라 데이터베이스를 제어하고 보호함 무결성, 보안 회복, 동시성을 보장하기 위해 데이터 제어어를 이용해 규칙과 기법을 정의함

무결성 - 데이터베이스에 정확하고 유효한 데이터만 유지 보안 - 허가받지 않는 사용자가 데이터에 접근하는 것을 차단하거나, 허가된 사용자가 접근 권한이 있는 데이터에만 접근하도록 함 회복 - 장애가 발생해도 데이터의 일관성을 유지 동시성 - 여러 사용자가 같은 데이터에 동시에 접근하여 처리할 수 있게 함

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

DBMS는 사용자와 데이터베이스 사이에 위치하며, 질의 처리기와 저장 데이터 관리자로 구성

질의 처리기

사용자의 데이터 처리 요구를 해석하여 처리하는 역할

• DDL 컴파일러 - 데이터 정의어로 작성된 스키마의 정의를 해석, 저장 데이터 관리자의 도움을 받아 새로운 데이터베이스 구축, 새롭거나 변경된 스키마의 정의를 데이터 사전에 저장
• DML 프리 컴파일러 - 응용 프로그램에 삽입된 데이터 조작어를 추출하여 DML 컴파일러에 전달
• DML 컴파일러 - 데이터 조작어로 작성된 데이터의 처리(Select, Insert, Update, Delete) 요구를 분석하여 런타임 데이터베이스 처리기가 이해할 수 있도록 해석
• 런타임 데이터베이스 처리기 - 저장 데이터 관리자를 통해 데이터베이스에 접근하여, DML 컴파일러로부터 전달받은 데이터 처리 요구를 데이터베이스에서 실제로 실행
• 트랜잭션 관리자 - 데이터베이스에 접근하는 과정에서 사용자의 접근 권한과 데이터베이스 무결성을 유지하기 위한 제약조건 위반 여부 확인 회복이나 병행 수행과 관련된 작업도 담당

저장 데이터 관리자

디스크에 저장된 데이터베이스와 데이터 사전을 관리하고, 실제로 접근하는 역할을 담당 디스크에 저장된 데이터에 접근하는 것은 운영체제의 기본기능이기에 저장 데이터 관리자는 운영체제의 도움을 받아 데이터베이스에 대한 접근을 수행

출처 - 김연희저자의 데이터베이스 개론 2판 - 한빛 아카데미

DBMS 등장 이전 데이터를 관리하기 위해선 파일 시스템이라는 소프트웨어를 이용

파일 시스템

1)데이터를 파일로 관리할 수 있도록 파일을 생성,삭제,수정,검색하는 기능 제공 2)응용 프로그램별로 필요한 데이터를 관리

위와 같이 관리를 하다 보니 아래와 같은 문제점 발생

• 같은 내용의 데이터가 여러 파일에 중복 저장 데이터 중복성 발생, 이로 인한 저장 공간의 낭비와 데이터 일관성, 데이터 무결성 손실
• 응용 프로그램이 데이터 파일에 종속적 응용 프로그램이 파일에 직접 접근하여 데이터를 처리, 따라서 파일의 데이터를 구성하는 방법이나 물리적 저장 구조에 맞게 작성 -> 데이터 종속성 파일에 데이터 속성이 추가될 시 관련된 모든 응용 프로그램에서 접근 방식을 변경해야함
• 데이터 파일에 대한 동시 공유, 보안, 회복 기능 부족 동시 공유 기능 제공이 안되며, 파일 단위 접근 권한 부여로 통제 -> 구체적인 권한 부여로 보안을 유지해야될 필요성 증가, 장애가 발생 시 일관된 상태로 복구하기 어려움
• 응용 프로그램을 개발하기 어려움 파일에 접근하여 데이터를 관리하는 작업을 응용 프로그램이 담당 -> 기본적인 데이터 관리 기능을 모두 포함
• 문제점들의 근본 원인 - 데이터 종속성과 데이터 중복성

• 데이터 종속성(data dependency) - 데이터와 응용 프로그램 간의 상호 의존 관계 똑같은 내용을 표로 작성해 doc파일로 저장한 경우에는 데이터의 종속성 때문에 excel파일로는 열 수 없음
• 데이터의 중복성(data redundancy) - 동일한 내용의 파일이 여러개 생기는 것 데이터가 중복되면 저장 공간이 낭비되고 데이터가 변동되거나 갱신할 때 수정된 내용을 동시에 모두 반영해야하니 굉장히 비효율적

데이터베이스 관리 시스템(DBMS)

파일 시스템의 데이터 중복과 데이터 종속 문제를 해결하기 위해 제시된 소프트웨어 여러 응용 프로그램들이 동시에 데이터베이스에 접근할 때 발생할 수 있는 문제를 중재 데이터베이스 생성, 접근, 관리 모두 담당 사용자는 요청만 하면 되며, 데이터베이스의 물리적 저장 구조나 데이터 접근 및 처리 방법 등을 자세히 알 필요가 없음 데이터 변동 발생 시 사용자가 알거나 응용 프로그램이 변경될 필요가 없음 - 데이터 독립성 보장

DBMS의 주요 기능

• 정의 기능 - 데이터베이스 구조를 정의하거나 수정 가능
• 조작 기능 - 데이터를 삽입,삭제,수정,검색하는 연산 가능
• 제어 기능 - 데이터를 항상 정확하고 안전하게 유지 가능 (장애가 발생해도 회복 가능하도록 제어, 기밀성 보장, 동시 공유 보장)

DBMS 장점

1. 데이터 중복을 통제 - 데이터베이스에 데이터를 통합하여 관리함 -> 중복 문제 해결 효율성 때문에 중복을 허용해도 통제 가능한 선에서 최소화 -> 데이터 일관성 유지 2. 데이터 독립성 확보 - 데이터베이스 (저장)구조가 변경되어도 응용 프로그램이 영향을 받지 않음 3. 데이터 동시 공유 가능 - 이를 통해 불필요한 데이터 중복을 제한할 수 있음 4. 데이터 보안이 향상 - 중앙 집중식 관리를 통한 데이터에 대한 효율적인 접근 제어 수행 5. 데이터 무결성 유지 가능 - 연산이 수행될 때마다 유효성을 검사 6. 표준화 가능 - DBMS가 미리 정한 표준화 방식을 통해 데이터베이스에 접근 7. 장애 발생 시 회복 가능 - 데이터 일관성과 무결성을 유지하면서 이전 상태로 복구 8. 응용 프로그램 개발 비용 감소 - 개발 및 유지보수 비용이 감소

DBMS 단점

1. 고비용 - DBMS 구매 비용, 복잡한 기능을 제공하기에 컴퓨터 자원을 많이 점유 2. 복잡한 백업 및 복구 - 데이터베이스는 구조가 복잡하고 동시 공유를 지원하기에 장애의 원인과 상태를 정확히 파악하기 어려움 따라서 장애 발생 전에 데이터를 미리 백업해놓고 장애 발생 후에 데이터를 일관된 상태로 회복하는 방법 사용 -> 복잡함 3. 중앙 집중 관리로 인한 취약점 존재 - 장애 발생 시 전체 시스템의 업무 처리가 중단 데이터베이스에 대한 의존도가 높은 시스템일수록 가용성, 신뢰성에 치명적 영향을 받을 수 있음

DBMS의 발전 과정

사용하는 데이터 모델에 따라 네트워크, 계층, 관게, 객체지향. 객체관계로 구분할 수 있음

데이터 모델은 데이터를 데이터베이스에 저장하는 구조를 의미한다.

1세대 - 네트워크, 계층 DBMS

• 네트워크 DBMS - 노드와 간선을 이용한 그래프 형태 구조가 복잡하고, 변경하기 어려움 (IDS)
• 계층 DBMS - 트리 형태로 구성하는 계층 데이터 모델 네트워크보다 구조가 단순하지만 복잡한 현실 세계를 트리 형태로 표현하기 어렵고 구조 변경이 어려움 (IMS)

  2세대 - 관계 DBMS

  테이블 형태로 구성하는 관계 데이터 모델을 사용, 데이터베이스를 단순하고 이해하기 쉬운 구조로 구성

• 관계 데이터 모델을 사용하는 관계 DBMS가 많이 개발되었으며, 이론적 연구도 많이 이루어짐 데이터베이스 관리 시스템의 주류로 존재 (Oracle, MS SQL Server, Access, Informx, MySQL)

  3세대 - 객체지향,객체관계 DBMS

• 객체지향 DBMS - 객체지향 프로그래밍의 객체라는 개념을 이용하여 구성 데이터에 대한 복잡한 분석 및 처리를 지원 (O2, ONTOS, GemStone)
• 객체관계 DBMS - 관계 DBMS와 객체지향 DBMS의 개념을 통합한 것

객체지향 DBMS와 객체관계 DBMS가 등장한 뒤에도 대표적인 데이터베이스 관리 시스템은 일반적으로 관계 DBMS로 인식 하지만 대량의 비정형 데이터가 생성, 클라우딩 컴퓨팅, 빅데이터 개념이 등장하면서 새로운 DBMS에 대한 요구 발생

4세대 이후 - NoSQL, NewSQL DBMS

• NoSQL DBMS - RDBMS의 안정성, 일관성을 포기, 데이터 구조를 정해두지 않기에 비정형 데이터를 저장하고 처리하는 데 적합하며, 뛰어난 확장성을 지님 여러 대의 서버 컴퓨터에 데이터를 분산 저장 및 처리하는 환경에서 주로 사용 (MongoDB, Cassandra, Redis, Neo4j, OriedntDB)
• NewSQL DBMS - 정형 데이터는 관계 DBMS로 처리하고 비정형 데이터는 NoSQL로 처리하고자 각자 도입하기엔 부담과 불편함이 존재 -> NewSQL의 필요성 대두 안정성과 일관성을 유지하면서 확장성과 유연성 지원 -> 정형 및 비정형 데이터를 안정적이고 빠르게 처리 가능 (Spanner, VoltDB, NuoDB)

NewSQL은 시장에 진입한 지 얼마 되지 않았기에 당분간 관계 DBMS, NoSQL, NewSQL이 상호 보완하면서 공존할 것으로 예상됨 그렇기에 저장할 데이터의 형태, 비즈니스의 성격 등을 고려해서 적합한 DBMS를 선택하는 것이 중요

출처 - 김연희저자의 데이터베이스 개론 2판 - 한빛 아카데미

데이터와 정보의 차이

• 데이터는 단순히 측정하여 수집한 사실이나 값 (자료라고도 함)
• 정보는 의사 결정에 유용하게 활용할 수 있도록 데이터들을 처리해서 만든 유의미한 결과물 ex) 원유 - 데이터, 팩우유 - 정보 둘의 차이점은 가공의 유무!

정보 처리

데이터를 상황에 맞게 분석하거나 해석하여 데이터 간의 의미 관계를 파악하는 것

데이터베이스의 정의

특정 조직의 여러 사용자들이 공유하여 사용할 수 있도록 통합해서 저장한 운영데이터의 집합

• 공유데이터(shared data) 특정 조직의 여러 사용자들이 함께 소유하고 이용할 수 있어야함
• 통합데이터(integrated data) 데이터의 중복을 최소화하고 통제가 가능한 중복만 허용
• 저장데이터(stored data) 데이터 처리는 컴퓨터가 하기에 데이터를 컴퓨터가 접근 할 수 있는 매체에 저장해야함
• 운영데이터(operational data) 조직을 운영하고 주요 기능을 수행하기 위해 꼭 필요하며, 지속적으로 유지해야 하는 데이터

  데이터베이스의 특징

• 실시간 접근성(real-time accessibillity) 사용자가 요구하면 원하는 데이터를 빠른 시간(수초이내) 내에 제공
• 계속 변화(continuous evolution) 현실 세계의 상태를 정확히 반영(동적인 특징이 존재 - 삽입, 삭제, 수정하여 정확한 데이터 유지)
• 동시 공유(concurrent sharing) 여러 사용자가 서로 다른 데이터를 동시 사용 및 같은 데이터를 동시 사용하는 것을 지원
• 내용 기반 참조(content reference) 주소나 위치가 아닌 값으로 참조 가능 ex) 데이터 검색

  데이터의 분류

  일반적으로 데이터는 형태에 따라 정형, 반정형, 비정형으로 분류할 수 있다.
• 정형 데이터 - 미리 정해진 구조에 따라 저장된 데이터 ex) excel의 스프레드시트, RDBMS의 테이블
• 반정형 데이터 - 구조에 따라 저장된 데이터지만 데이터 내용 안에 구조에 대한 설명이 존재 ex) html, xml, json 문서들, 웹 로그
• 비정형 데이터 - 정해진 구조가 없이 저장된 데이터 ex) 텍스트, 영상, 이미지, pdf 최근 스마트 기기의 활성화로 실시간으로 많은 양의 비정형 데이터가 생산 중

출처 - 김연희저자의 데이터베이스 개론 2판 - 한빛 아카데미