데이터 자체가 많지 않던 시절에 DBMS는 중요한 것이 아니었다. 데이터를 직접 애플리케이션에서 관리할 수 있었으며, 데이터의 구성이 바뀐다고 하더라도 애플리케이션의 수정은 그다지 어려운 일이 아니었기 때문이다. 즉, 과거의 컴퓨팅은 데이터 자체가 아닌 데이터의 연산, 즉 computation이 더 중요했다. 그러나, 프로세서가 점차 강력해지고 데이터의 양이 증가하면서, 데이터의 연산보다 데이터가 의미하는 정보가 더 중요한 요소로 간주되기 시작한다.
관계(relation)란 정확하게 무엇인가? 관계 모델에서 데이터 기술하는 중요 개념은 관계이며, 이것은 레코드의 집합으로 구성된다. 어떤 데이터에 대한 정보를 저장한다고 해보자. 이 데이터를 표현하는 다른 데이터와 이 데이터와는 어떤 관계가 있을 것이고, 관계는 이것을 계산 가능한 값으로 추상화한 것이다. 그리고 스키마(schema)란, 어떤 데이터 모델에 의거한 데이터 기술 방법을 말한다. 예를 들어, 어떤 학생에 대한 정보를 저장한다고 해보자. 이 학생에 대한 정보를 데이터베이스에 저장한다고 하는 것은, 다음과 같은 스키마를 가진 관계로 저장될 수 있다 : Student(sid:string, name:string, login:string...) 이 경우, 이 스키마는 Student Relation에 있는 레코드가 몇 개의 필드로 구성되어 있다고 할 수 있다.
데이터의 무결성을 지원하기 위해서, DMBS는 트랜잭션(transaction) 단위로 데이터를 처리한다. 즉, 데이터베이스 내에서 특정 작업이 완전히 끝나기 전에 실패했다면 이 작업은 취소(rollback)되어야 하고, 데이터베이스 내의 데이터는 작업의 성공 실패 여부와 상관없이 무결성을 유지해야 한다. 트랜잭션은 원자적으로 간주될 수 있는 단위 작업이다. 트랜잭션은 실행이 완벽하게 종료되거나, 실패할 경우 작업을 시작하기 이전 상태로 되돌릴 수 있어야 한다. 그렇지만, 트랜잭션 처리는 순차적으로 발생하는 것이 아니다. 동시에 동일한 데이터에 대해 갱신 명령이 비순차적으로 발생하더라도, DMBS는 트랜잭션이 정확한 순서에 따라 처리되는 것을 보장해야 한다. 트랜잭션은 발생 순차적으로 처리되어야 하지만, 트랜잭션을 순차적으로 스케쥴링한다면, 수행 성능에 있어서 많은 손해를 보게 된다. 따라서, 트랜잭션을 적절히 스케쥴링하면서도 그 결과는 트랜잭션이 순차적으로 실행된 것과 동일한 결과를 보장해야 한다. 이것을 트랜잭션의 ACID(Atomicity, Consitency, Isolation, Durability) 특성이라고 한다.
그렇다면, 데이터의 무결성은 어떻게 보장하는가? 데이터베이스에 부정확한 데이터가 입력되는 것을 방지하기 위해서, 무결성 제약조건(integrity constraint)을 데이터베이스 스키마에 명시해야 한다. 그리고, 이 데이터 무결성 조건은 트랜잭션이 수행과 관련하여 몇 가지 다루어야 하는 문제가 있다. 즉, 어떤 명령의 실행이 무결성 제약 조건을 위배한다면 그 사실을 즉각 통보해야 하는가? 아니면 제약 조건들이 트랜잭션이 완료되기 전에 한꺼번에 검사되어야 하는가? 이것은 경우에 따라 다르다. SQL은 제약 조건 검사가 즉각 이루어질 것인지, 나중에 검사될 것인지를 선택할 수 있다.
Library/Database