데이터베이스 시스템

Jin Hur·2022년 5월 22일
0

데이터베이스

목록 보기
3/12

reference: "데이터베이스 개론" / 김연희 / 한빛아카데미

DB 시스템 구성 요소

source: https://deftkang.tistory.com/38

DB 시스템은 DB에 데이터를 저장하고, 저장된 데이터를 관리하여 조직에 필요한 정보를 생성해주는 시스템.
즉 DB 시스템은 DB와 DBMS보다 큰 개념인데, DB와 DBMS는 DB 시스템의 핵심 구성 요소이다.

단순화된 DB 시스템 환경

source: https://velog.io/@corone_hi/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%8B%9C%EC%8A%A4%ED%85%9C



DB 구조, DB 3단계 구조에서 데이터 독립성 개념을 실현하는 방법

스키마(schema)

source: https://ykcb.tistory.com/entry/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%8A%A4%ED%82%A4%EB%A7%88%EC%9D%98-%EA%B0%9C%EB%85%90-%ED%8A%B9%EC%A7%95

스키마는 DB에 저장되는 데이터 구조제약 조건을 정의한 것이다. 아래 그림은 스키마를 그림으로 간략히 표현한 것이다.

고객과 관련된 데이터인 '고객번호', '이름', '나이', '주소'를 저장한다고 가정했을 때 고객번호는 정수로, 이름은 최대 10의 문자열로, 나이는 정수로, 주소는 최대 20자의 문자열만 허용하기로 했다면 정해진 이 모든게 스키마라 할 수 있다.

그리고 정의된 스키마에 따라 데이터베이스에 실제로 저장된 값이 인스턴스(instance)이다. 보통 스키마는 한번 정의되면 자주 변경되지 않지만, 인스턴스는 계속 변하는 특성이 있다.

3단계 DB 구조

미국의 표준화 기관인 ANSI/SPARC에서는 DB의 복잡한 내부 구조를 감추고 일반 사용자가 DB를 쉽게 이해하고 이용할 수 있도록 3단계 DB 구조를 제안하였다.

3단계 DB 구조는 하나의 DB를 세 단계로 나누어 이해한다. 즉, 개별 사용자 관점에서 바라보는 외부 단계(external level), 조직 전체의 관점에서 바라보는 개념 단계(conceptual level), 물리적인 저장 장치의 관점에서 바라보는 내부 단계(internal level)로 나눈다. 이렇게 3단계로 나눈 이유는 각 단계별로 다른 추상화를 제공하면 DB를 효과적으로 관리할 수 있기 때문이다. 3단계 DB 구조를 통해 모든 데이터가 어떻게 저장되고 유지되는지와 관련된 복잡한 내용을 숨기고 필요한 데이터만 단순화한 외부 단계의 관점을 일반 사용자들에게 제공할 수 있다.

source: https://agilestarskim.github.io/posts/what-is-database-03

외부 단계(사용자 관점)

  • 개별 사용자 관점에서 DB를 이해하고 표현
    : 하나의 DB를 조직 내의 사용자들이 함께 사용하지만 각 사용자가 DB 전체에 관심이 있는 것은 아님을 고려
  • 고객 관리를 담당하는 직원은 DB에서 고객과 관련된 데이터에만, 주문 관리를 담당하는 직원은 주문과 관련된 데이터에만 관심을 갖도록 함.
  • 외부 단계에서 사용자에게 필요한 DB를 정의한 것을 외부 스키마라 함.
    : 외부 스키마는 각 사용자가 생각하는 DB 모습인 논리적 구조로 사용자마다 다르다.
  • DB 하나에는 여러 개의 외부 스키마가 존재할 수 있고, 외부 스키마 하나를 사용 목적이 같은 사용자들이 공유할 수 있음. 외부 스키마는 전체 DB 중 사용자가 관심을 가지는 일부분으로 볼 수 있어 서브 스키마라고도 함.

개념 단계(조직 전체 관점)

  • DB를 이용하는 사용자들의 관점을 통합하여, DB를 조직 전체의 관점에서 이해하고 표현
  • DBMS나 DB 관리자는 DB의 일부분이 아닌 전체 DB에 관심을 가지는데, 개념 단계에서는 DBMS나 관리자의 관점에서 모든 사용자에게 필요한 데이터를 통합한 전체 DB의 논리적 구조를 정의, 이를 개념 스키마라 함.
    : 즉 조직 전체의 관점에서 생각하는 DB의 모습이며, 모든 사용자가 생각하는 DB의 모습을 하나로 합친 모습이다.
  • 개념 스키마는 전체 DB에 '어떤 데이터가 저장되는지', '데이터들 간에는 어떤 관계가 존재하는지', '어떤 제약조건이 존재하는지'에 대한 정의함.
  • 뿐만 아니라 데이터에 대한 '보안 정책'이나 '접근 권한'에 대한 정의도 포함한다.
  • 하지만 데이터를 물리적으로 저장하는 방법이나 데이터를 저장하는 저장 장치와는 독립적
  • DB 하나에는 개념 스키마가 하나만 존재하고, 각 사용자는 개념 스키마의 일부분으로 사용함.
    : 즉 외부 스키마는 개념 스키마를 기초로 하여 사용자의 이용 목적에 맞게 만들어짐.

일반적으로 스키마라 하면 개념 스키마를 의미함.

내부 단계(저장 장치 관점)

  • DB를 디스크와 같은 저장 장치의 관점에서 이해하고 표현
  • 내부 단계는 전체 DB가 저장 장치에 실제로 저장되는 방법을 정의하며 이를 내부 스키마라 함.
  • DB는 저장 장치에 파일 형태로 저장되는데 내부 스키마는 파일에 데이터를 저장하는 '레코드의 구조', '레코드를 구성하는 필드 크기', '인덱스를 이용한 레코드 접근 경로' 등을 정의함.
  • 내부 스키마는 DB의 개념 스키마에 대한 물리적인 저장 구조를 표현하므로 하나의 DB에 하나만 존재


내부 스키마에 정의된 고객 레코드는 필드 7개로 구성되어 있고, 레코드 총 길이는 70바이트. 이 내부 스키마는 번호와 연락처 필드에 인덱스를 정의하고 있어, 번호나 연락처 필드의 값을 이용해 해당 고객 레코드에 빠르게 접근할 수 있음.


단계간 매핑(데이터 독립성)

세 가지 스키마 사이에는 유기적인 대응 관계가 성립해야 한다. 이를 사상 또는 매핑(mapping)이라 한다.
외부 스키마는 개념 스키마와 외부/개념 사상에 의해 대응되고, 개념 스키마와 내부 스키마는 개념/내부 사상에 의해 대응된다.
DBMS는 미리 정의된 외부/개념 사상과 개념/내부 사상 정보를 이용해 사용자가 원하는 데이터에 접근할 수 있다.

이러한 대응 관계를 정의하는 궁극적인 목적은 데이터 독립성을 실현하기 위해서이다. 데이터 독립성은 DBMS의 중요한 장점이자 DBMS가 필요한 이유이기도 하다. 데이터 독립성은 하위 스키마를 변경하더라도 상위 스키마가 영향을 받지 않는 특성이다. 3단계 DB 구조에서는 2가지 독립성이 있다.
1) 논리적 데이터 독립성: 외부<->개념 사상
2) 물리적 데이터 독립성: 개념<->내부 사상

논리적 데이터 독립성(외부 스키마 <-> 개념 스키마)

  • 개념 스키마가 변경되더라도 외부 스키마가 영향을 받지 않는 것
    : 즉 전체 DB의 논리적인 구조가 변경되어도 관련된 외부/개념 사상 정보만 적절히 수정해주면 직접 관련이 없는 사용자를 위한 외부 스키마는 변경할 필요가 없다는 뜻.
  • 외부/개념 사상은 외부 스키마와 개념 스키마의 대응 관계를 정의한 것으로, 응용 인터페이스라고도 함.
  • 이 응용 인터페이스를 수정하는 방식으로, 개념 스키마에서 수정/추가/삭제가 있더라도 외부 스키마는 전혀 영향을 받지 않음.

물리적 데이터 독립성(개념 스키마 <-> 내부 스키마)

  • 내부 스키마가 변경되더라도 개념 스키마가 영향을 받지 않는 것(결과적으로 외부 스키마도 영향을 받지 않음)
    : 즉 물리적 데이터 독립성이 실현되면 DB의 저장 구조가 변경되어도 관련된 개념/내부 사상만 정보만 적절히 수정해주면 직접적으로 고나련이 없는 DB의 논리적 구조는 영향을 받지 않는다.
  • 개념/내부 사상은 개념 스키마와 내부 스키마의 대응 관계를 정의한 것으로, 저장 인터페이스라고도 함.
  • 내부 스키마에서 주소 다음에 연락처 필드가 저장되는 순서가 바뀌어도 두 필드와 관련된 개념/내부 사상 정보(저장 인터페이스)만 수정하면 됨.

메타 데이터(데이터에 대한 데이터)

DB에 저장된 데이터를 올바르게 관리하고 이용하려면 필요한 부가 정보도 저장해야 함. 대표적인 부가 정보가 스키마사상 정보, 다양한 제약조건 등이다.

데이터 독립성을 실현하면 DB를 다양한 관점에서 이해하기 위해 정의되는 3단계 스키마와 스키마 간 사상 정보도 어디엔가 저장해야 한다. 이러한 부가 정보가 저장되는 곳을 데이터 사전 또는 시스템 카탈로그라 한다. 데이터 사전도 데이터를 저장하는 DB의 일종이기에 시스템 DB라고 한다.

이 데이터 사전은 DBMS가 스스로 생성하고 유지한다.



DB 사용자별 특징

데이터베이스 시스템을 구성하는 또 하나의 중요 요소로 사용자가 있다. 사용자는 이용 목적에 따라 크게 DB 관리자, 최종 사용자, 응용 프로그래머로 나눌 수 있다.

DB 관리자

  • DB 시스템을 운영하고 관리, 데이터 정의어/제어어 사용
  • DB를 직접 사용하기보단 조직 내의 사용자를 위해 DB를 설계 및 구축하고, 제대로 서비스할 수 있도록 DB를 제어함.
  • 주요 업무
    • DB 구성 요소 선정
      : DB를 구성할 데이터 결정
    • DB 스키마 정의
      : 선정한 구성 요소를 토대로 DB 스키마 설계, '데이터 정의어'를 이용해 설계한 스키마를 DBMS에 설명
    • 물리적 저장 구조와 접근 방법 결정
      : DB를 물리적으로 저장하기 위한 레코드 구조를 설계. 레코드들 간의 저장 순서와 레코드에 빠르게 접근하기 위해 인덱스를 만들 기준 필드 등도 결정.
    • 무결성 유지를 위한 제약조건 정의
    • 보안 및 접근 권한 정책 결정
    • 백업 및 회복 기법 정의
    • 시스템 데이터베이스 관리
    • 시스템 성능 감시 및 성능 분석
    • DB 재구성

최종 사용자

  • 데이터를 조작(삽입/삭제/수정/검색)하기 위해 DB에 접근하는 일반 사용자를 의미
  • 데이터 정의어보단 주로 '데이터 조작어'를 사용
  • 데이터 조작어로 자신의 요구를 직접 표현할 수도 있지만 다른 메뉴나 GUI 형태의 응용 프로그램을 통해 DB를 사용할 수 있음.

응용 프로그래머

  • 프로그래밍 언어로 응용 프로그램을 작성할 때 DB에 접근하는 '데이터 조작어'를 삽입하는 사용자
  • 최종 사용자는 응용 프로그래머가 작성한 응용 프로그램을 이용해 DB에 접근하는 방식이 많다(ex, 도서 검색 프로그램).
  • 예를 들어 '도서관 도서 검색 프로그램'을 개발할 때 데이터 조작어를 코드에 삽입함

데이터 언어별 특징

데이터 언어는 DBMS의 정의, 조작, 제어 기능을 이용하기 위한 것이기에 사용 목적에 따라 데이터 정의어, 데이터 조작어, 데이터 제어어로 나눈다. 이는 데이터 언어를 기능에 따라 내부적으로 구분 짓는 것일 뿐 독립적으로 존재하는 언어들은 아님.

  • 데이터 정의어(DDL): 스키마 정의, 수정 또는 삭제
    • 새로운 DB를 구축하기 위해 스키마 정의, 기존 스키마의 정의를 삭제 또는 수정하기 위해 사용
      : 새로 만들려는 DB의 스키마를 설명하거나, 이미 정의된 스키마의 구조나 제약조건 등을 변경 또는 삭제하고 싶어 이를 DBMS에 알릴 때 사용
    • 데이터 정의어로 정의된 스키마는 데이터 사전(시스템 DB)에 저장되고, 삭제나 수정이 발생하면 이 내용도 데이터 사전에 반영
  • 데이터 조작어(DML): 데이터 삽입, 삭제, 수정, 검색 등의 처리를 요구
    • 스키마에 따라 저장된 실제 데이터 값(인스턴스)을 활용하기 위해 사용
    • 데이터 조작어는 DBMS에 설명하는 방식에 따라 '절차적 조작어'와 '비절차적 조작어'로 나뉨
      • 절차적(WHAT + HOW) vs 비절차적(WHAT)
  • 데이터 제어어(DCL): 내부적으로 필요한 규칙이나 기법을 정의
    • 데이터 제어어는 본래 데이터 제어어로 분류되었지만, DB 제어 기능이 중요해지고 다양한 제어 기능이 소개되면서 독립됨.
    • DB를 올바르게 관리하기 위해 필요한 규칙과 기법을 데이터 제어어를 이용하 DBMS에 설명


DBMS 구성

source: https://agilestarskim.github.io/posts/what-is-database-03

DBMS

DBMS는 DB 시스템의 주요 구성요소이고, 사용자와 DB 사이에 위치한다. 기능에 따라 크게 질의 처리기저장 데이터 관리자로 구분할 수 있다.

질의 처리기(query processor)

질의 처리기는 사용자의 데이터 처리 요구를 해석하여 처리하는 역할을 담당한다.

  • DDL 컴파일러
    • 데이터 정의어로 작성된 스키마의 정의를 해석
    • 저장 데이터 관리자의 도움을 받아 새로운 DB를 구축하고, 스키마의 정의를 데이터 사전에 저장
    • 데이터 정의어로 작성된 기존 스키마의 삭제나 수정 요청도 처리하여 변경된 내용을 데이터 사전에 적용
  • DML 컴파일러
    • 데이터 조작어로 작성된 데이터의 처리(삽입/삭제/수정/검색) 요구를 분석하여 '런타임 데이터베이스 처리기'가 이해할 수 있도록 해석
  • DML 프리 컴파일러
    • 응용 프로그램에 삽입된 데이터 조작어를 추출하여 DML 컴파일러에 전달
    • 데이터 조작어와 관련이 없는 나머지 코드들은 해당 언어 컴파일러로 전달
  • 런타임 데이터베이스 처리기
    • 저장 데이터 관리자를 통해 DB에 접근하여, DML 컴파일러로부터 전달받은 데이터 처리 요구를 DB에서 실제로 실행
  • 트랜잭션 관리자
    • DB에 접근하는 과정에서 사용자의 접근 권한이 유효한지 검사
    • DB 무결성을 유지하기 위한 제약조건 위반 여부를 확인
    • 회복이나 병행 수행과 같은 작업도 담당

저장 데이터 관리자

저장 데이터 관리자는 디스크에 저장되어 있는 사용자 DB와 데이터 사전을 관리하고, 여기에 실제로 접근하는 역할을 담당한다.
실제 디스크에 저장된 데이터에 접근하는 것은 운영체제가 제공하는 서비스이므로 저장 데이터 관리자는 운영체제의 도움을 받아(= 시스템 콜을 호출하여) DB에 대한 접근을 수행한다.

0개의 댓글