시험 직전 요약장

통합된 데이터는 서로 관련된 자료를 통합하여 불필요한 중복을 줄이고 일관된 관리 대상으로 만든다는 성격이다. 저장된 데이터는 저장 매체에 기록된 자료, 운영 데이터는 조직의 업무에 필요한 자료, 공용 데이터는 여러 사용자·응용이 함께 이용하는 자료라는 관점이다. 네 용어는 동일한 분류 질문이므로 키워드만으로 서로 바꾸지 않는다.

내용에 의한 참조는 사용자가 물리 주소를 직접 지정하기보다 값·조건으로 필요한 자료를 요청한다는 특성이다. 스키마에는 구조와 제약의 정의가, 인스턴스에는 특정 시점의 실제 값이 있다. 데이터 사전에는 테이블·열·자료형·제약조건·권한처럼 데이터 자체를 설명하는 메타데이터가 있다.

계층형 모델은 트리 구조를 기본으로 하여 루트가 아닌 자식 레코드가 하나의 부모와 연결되는 구조를 나타낸다. 네트워크형 모델은 더 일반적인 연결 구조를 표현한다. 객체지향 모델은 객체의 상태뿐 아니라 그 상태를 다루는 행위와 객체 식별성도 표현한다. 관계형 모델의 구조·연산·제약은 각각 릴레이션 구성, 조작 방식, 유효한 상태의 규칙에 해당한다.

DBA는 스키마·권한·저장 공간·백업·복구·성능 등 데이터베이스의 운영과 통제를 담당한다. 업무 프로그램의 모든 기능 구현, 모든 일반 사용자의 조회 수행 자체와 동일한 역할은 아니다.

데이터베이스 관련 문제는 데이터 집합, 관리 소프트웨어, 데이터 모델, 요청 언어를 먼저 분리하면 대부분의 오답을 제거할 수 있다.

개념 모델에서는 업무 의미를 먼저 잡는다.

고객은 주문을 할 수 있다.
한 고객은 여러 주문을 할 수 있고, 각 주문은 한 고객에 속한다.
주문 금액은 0 이상이어야 한다.

논리 모델에서는 관계형 구조로 정제한다.

CUSTOMER(
  customer_id PK,
  customer_name
)

CUSTOMER_ORDER(
  order_id PK,
  customer_id FK → CUSTOMER.customer_id,
  ordered_at,
  total_amount CHECK total_amount >= 0
)

물리 모델에서는 목표 DBMS의 자료형, 길이, NULL 허용 여부, 인덱스와 저장 위치를 구체화한다. 예를 들어 주문일은 적절한 날짜·시간 자료형으로, 금액은 필요한 정밀도의 수치형으로 정하고 고객별 주문 조회에 필요한 인덱스를 검토한다. 이 단계에서 실제 CREATE TABLE 문을 만들 수 있다.

데이터베이스 설계의 전체 흐름은 요구조건 분석 → 개념 설계 → 논리 설계 → 물리 설계 → 구현으로 정리한다. 앞 단계의 업무 규칙이 뒷 단계의 테이블·제약조건으로 연결되어야 한다.