2주차 (3)

3층 스키마 (3-Level Schema): 데이터의 독립성 확보에 대한 방법

1. 데이터 독립성의 필요성

데이터의 일체적 구성

• 데이터 모델링 과정에서 가장 신경 써야 하는 것 중 하나
• 일관된 형태로 데이터를 수집하는 것 = 데이터의 독립적 구성
• 데이터 독립성의 반대말은 데이터 종속성
  • 종속의 주체는 보통 응용(Application)을 의미
    응용: 사용자의 요구사항을 처리하는 사용자 접점의 인터페이스
• 과거에는 파일 방식으로 데이터를 구성하는 것이 일반적이었음
  • 사용자가 접근하는 방법(트랜잭션의 유형)에 따라 파일의 정렬순서, 인덱스의 정렬순서, 파일 구성 등을 제공하기 쉽게 별도로 구성
  • 즉, 사용자가 어떤 방식으로 파일에 접근하냐에 따라서 데이터를 구성하는 방법이 영향을 받았었음
• 하지만 1990년대 이후 Client & Server 모델이 주를 이루며 파일 단위의 데이터베이스 관리가 아닌 원격 서버에 저장해두는 방식이 보편화되면서 파일 처리 방식의 변화가 생김

• 데이터 독립성 확보 시 기대 효과
  • 각 view의 독립성을 유지하고 계층별 View에 영향을 주지 않고 변경 가능
  • 단계별 Schema에 따라 데이터 정의어(DDL)와 데이터 조작어(DML)가 다르게 제공됨
    → 응용 프로그램과 물리적 데이터베이스 분리하기

2. 데이터베이스 3단계 구조 (3층 스키마)

3층 스키마

• 데이터베이스를 보는 관점에 따라 데이터베이스를 기술하고 이들간의 관계를 정의한 ANSI 표준
  • *ANSI : 미국표준협회 (American National Standards Institute)
• 3단계 계층으로 분리하여 독립성을 확보
  • 각 계층을 뷰(View)라고도 함
    → 사용자, 설계자, 개발자가 데이터베이스를 보는 관점에 따라 데이터베이스를 기술하고 이들 간의 관계를 정의한 표준
    

3층 스키마의 구조

• 외부 스키마(External Schema)
  • View 단계 여러 개의 사용자 관점으로 구성
  • 개별 사용자가 보는 DB 스키마
  • 실제로 관심 있는 데이터베이스 부분을 설명하고 나머지는 감춤
    → 사용자 관점
    → 접근하는 특성에 따른 스키마를 구성
    
• 개념 스키마(Conceptual Schema)
  • 데이터베이스의 물리적인 저장 구조에 대한 부분은 숨기고, 데이터의 전체적인 구조와 관계에 대해 집중
  • 모든 사용자 관점을 통합한 조직 전체의 DB를 기술
  • 모든 응용 시스템들이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 DB를 기술
  • DB에 저장되는 데이터와 그들간의 관계를 표현하는 스키마
    → 설계자 관점, 통합 관점
    → 통합 데이터베이스 구조
    
• 내부 스키마(Internal Schema)
  • 내부 단계, 내부 스키마로
  • DB가 물리적으로 저장된 형식
  • 물리적 장치에서 데이터가 실제적으로 저장되는 완전히 구체적인 방법을 표현하는 스키마
    → 개발자 관점
    → 물리적 저장 구조
    

• 데이터베이스를 3가지의 큰 범주로 분리해보자는 컨셉

  • 사상(mapping):1 각 각의 범주간의 요청/응답을 전송하는 것
    • 외부 스키마에서 요청이 들어오면 DBMS에 의해 개념 스키마 → 내부 스키마로 전달됨
    • 여기에서 요청과 응답을 변환하는 프로세스를 사상(mapping)이라 함
  • 내부 스키마
    • 물리적 저장 구조를 갖춘 모델
  • 개념 스키마
    • 전체 데이터베이스의 설계를 설명할 수 있는 모델 (구조, 관계 등)
    • 데이터 구조의 구현 정보와 같은 내부 상세 정보는 보지 못함
  • 데이터 독립성 (Data Independence)
    • 상위 스키마를 변경하지 않고 하나의 계층에서 스키마를 변경할 수 있는 능력
    • 데이터베이스의 여러 레벨에서 구조를 수정할 때, 하위 레벨 스키마를 변경하더라도 상위 레벨의 스키마를 건드릴 필요가 없음(영향을 미치지 않음)

• 3층 스키마의 독립성

  • 논리적 독립성

    • 개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않도록 지원

    • 논리적 구조가 변경되어도 응용 프로그램에 영향이 없음

    • 우리가 데이터 저장이 필요한 속성을 추가/변경이 필요할 때 외부 응용 프로그램을 변경하지 않아도됨

      → 사용자 특성에 맞게 변경 가능
      → 통합 구조로 변경 가능

  • 물리적 독립성

    • 내부 스키마가 변경되어도 개념 스키마는 영향을 받지 않도록 지원

    • 저장 장치의 구조 변경은 응용프로그램과 개념 스키마에 영향을 주지 않음

    • 실제로 데이터를 저장하는 위치나 파일 이름을 변경하더라도 데이터베이스 전체 관점 즉, 개념 스키마 관점에서는 아무런 영향이 없음

      → 물리적 구조의 영향 없이 개념 구조로 변경 가능
      → 개념 구조의 영향 없이 물리적인 구조로 변경 가능

예시 1) CS팀 aiden(외부 스키마 #1): 이벤트 상품 전달을 위해 고객 정보가 필요
→ 필요한 정보: 고객의 이름, 전화번호, 주소
→ 하지만 회사가 저장하고 있는 정보는 고객 비밀번호, 계좌번호, 캐시, 이메일, 닉네임 등 굉장히 많음
→ 외부 스키마는 개념 스키마를 이용하여 필요한 정보만 전달받을 수 있음

예시 2) CS팀 mae(외부 스키마 #2): 14세가 안된 고객은 우리 서비스에서 거래를 못하게 해야한다. 즉, 14세 미만인지 아닌지 여부를 새롭게 저장해야 하는 상황
→ 14세 이상인지 여부를 판단하는 데이터가 추가되었다고 해서 앞서 aiden(외부 스키마 #1)이 하던 고객 정보에 대한 접근이 안된다면 물리적 / 논리적 독립성 모두 없는 것

⇒ 검색 속도를 높이기 위해 데이터가 저장되는 파일의 구조를 바꿨다고 해서(내부 스키마), 전체적인 데이터 베이스 구조/설계가 달라지거나(개념 스키마) 응용 프로그램단(외부 스키마)이 변경되면 안됨
⇒ 데이터베이스를 바라보는 관점에 따라 세가지로 나눌 수 있으며 그 각각은 논리적/물리적으로 독립적이면 좋다는 뜻!