시스매

개념 스키마 핸드북

13 min read

2025-08-10 10:26

Tags:

개념 스키마 핸드북

1. 만들어진 이유: 왜 개념 스키마가 필요한가?

컴퓨터가 없던 시절, 정보는 서류 캐비닛 속 문서철에 보관. 필요한 정보를 찾으려면 모든 문서를 뒤져야 하는 비효율 발생. 컴퓨터의 등장과 함께 데이터를 체계적으로 관리할 필요성 대두. 하지만 초창기 데이터베이스는 특정 프로그램에 종속되어 있어, 다른 프로그램에서 데이터를 사용하려면 구조를 전부 바꿔야 하는 문제 발생.

이는 마치 특정 회사의 열쇠로만 열 수 있는 사물함과 같음. 다른 회사 사람이 사물함을 쓰려면 자물쇠 자체를 바꿔야 하는 번거로움.

이러한 문제를 해결하기 위해 **데이터 독립성(Data Independence)**이라는 개념 등장. 데이터의 논리적 구조나 물리적 저장 방식이 변경되어도 응용 프로그램은 영향을 받지 않아야 한다는 원칙. 이 데이터 독립성을 실현하기 위한 핵심 설계도가 바로 개념 스키마.

개념 스키마는 데이터베이스의 전체적인 논리적 구조를 정의. 특정 프로그래밍 언어나 저장 장치에 얽매이지 않는, 데이터 그 자체의 본질적인 관계와 제약 조건을 표현. 덕분에 개발자, 데이터베이스 관리자(DBA), 사용자 모두가 동일한 데이터 구조를 공유하고 이해할 수 있는 공통의 소통 언어 역할 수행.

2. 구조: 개념 스키마는 무엇으로 이루어져 있는가?

개념 스키마는 데이터베이스의 전체적인 뼈대를 나타내는 설계도. 주로 다음과 같은 요소들로 구성.

  • 개체 (Entity): 저장하고자 하는 데이터의 대상. 현실 세계의 사물이나 개념. 예를 들어 ‘학생’, ‘과목’, ‘교수’ 등. 이는 설계도의 ‘주요 구성 요소’에 해당.

  • 속성 (Attribute): 개체가 갖는 특성이나 상태. ‘학생’ 개체라면 ‘학번’, ‘이름’, ‘전공’ 등이 속성. 설계도에서 각 구성 요소의 ‘세부 사양’과 같음.

  • 관계 (Relationship): 개체와 개체 사이의 연관성. ‘학생’은 여러 ‘과목’을 ‘수강’하고, ‘교수’는 특정 ‘과목’을 ‘강의’하는 관계. 설계도에서 구성 요소들이 ‘어떻게 연결되는지’를 보여주는 연결선.

  • 제약 조건 (Constraint): 데이터베이스에 저장될 데이터가 만족해야 하는 규칙. 예를 들어, ‘학번’은 절대 중복될 수 없고, ‘성적’은 0점에서 100점 사이의 값만 가져야 한다는 규칙. 설계도의 ‘시공 규칙’이나 ‘안전 규정’에 비유 가능.

1. 개체 (Entity)

  • 정의: 데이터로 저장하고 관리해야 하는 대상. 사람, 사물, 장소, 개념 등 구별 가능한 모든 것.

  • 설명: 데이터베이스 세상의 ‘주인공’ 또는 **‘명사’**에 해당. 예를 들어, 학교 데이터베이스를 만든다면 ‘학생’, ‘교수’, ‘과목’, ‘강의실’ 등이 모두 개체가 될 수 있음. ERD(개체-관계 다이어그램)에서는 보통 사각형으로 표현.

  • 예시: 학생, 도서, 주문, 회사

2. 속성 (Attribute)

  • 정의: 개체가 가지고 있는 구체적인 특성이나 상태.

  • 설명: 주인공인 개체를 설명해 주는 ‘프로필 정보’ 또는 ‘형용사’ 역할. ‘학생’이라는 개체는 ‘학번’, ‘이름’, ‘전공’, ‘연락처’와 같은 속성들로 구체화됨. 각 속성은 개체의 특징을 나타내는 최소한의 데이터 단위. ERD에서는 보통 타원형으로 표현하여 개체에 연결.

  • 예시: 학생 개체의 속성 → 학번, 이름, 전공

3. 관계 (Relationship)

  • 정의: 개체와 개체 사이에 존재하는 의미 있는 연관성.

  • 설명: 주인공들 사이에 벌어지는 ‘사건’ 또는 **‘스토리’**에 해당하며, 문장에서 ‘동사’ 역할을 함. 예를 들어, ‘학생’ 개체와 ‘과목’ 개체는 ‘수강한다’는 관계를 맺을 수 있음. 이 관계는 ‘한 명의 학생은 여러 과목을 수강할 수 있다(1:N)’ 또는 ‘하나의 과목은 여러 학생이 수강할 수 있다(M:N)‘와 같이 참여하는 개체의 수(Cardinality)로 더 구체화됨. ERD에서는 마름모로 표현.

  • 예시: 학생이 과목을 수강한다. 고객이 상품을 주문한다.

4. 제약 조건 (Constraint)

  • 정의: 데이터베이스에 저장되는 데이터가 반드시 지켜야 할 ‘규칙’ 또는 ‘법칙’.

  • 설명: 데이터의 무결성(정확성, 일관성)을 보장하기 위한 안전장치. 예를 들어, 모든 학생의 ‘학번’은 유일해야 한다는 규칙(기본 키 제약조건), 성적은 반드시 0점에서 100점 사이의 값이어야 한다는 규칙(도메인 제약조건), 존재하는 과목만 수강 신청할 수 있다는 규칙(참조 무결성 제약조건) 등이 있음.

  • 예시: 학번은 중복될 수 없음. 주민등록번호는 반드시 13자리여야 함. 성별 필드에는 ‘남’ 또는 ‘여’만 입력 가능.

이 네 가지 요소가 모여 데이터베이스의 전체적인 논리적 구조, 즉 개념 스키마라는 청사진을 완성하게 됩니다. 이러한 요소들을 시각적으로 표현하기 위해 **개체-관계 다이어그램(ERD, Entity-Relationship Diagram)**을 가장 널리 사용.

3. 사용법: 개념 스키마는 어떻게 활용되는가?

개념 스키마는 데이터베이스 구축 과정 전반에 걸쳐 다양한 용도로 활용.

  1. 설계 단계:

    • 요구사항 분석: 사용자의 요구사항을 파악하여 데이터베이스에 어떤 개체와 관계가 필요한지 정의.

    • 논리적 설계: ERD 등을 사용하여 개념 스키마를 구체적으로 작성. 데이터의 전체적인 구조와 제약 조건을 명확히 함. 이 단계의 산출물이 바로 개념 스키마.

  2. 구현 단계:

    • 물리적 설계: 개념 스키마를 바탕으로 실제 데이터베이스 관리 시스템(DBMS)에 맞는 테이블, 인덱스 등을 생성하는 **물리적 스키마(Physical Schema)**를 설계.

    • 외부 스키마(External Schema) 정의: 특정 사용자나 응용 프로그램이 보게 될 데이터베이스의 부분을 정의. 예를 들어, 학생은 자신의 성적 정보만 볼 수 있고, 교수는 담당 과목의 학생 정보만 볼 수 있도록 뷰(View)를 생성.

  3. 운영 및 유지보수 단계:

    • 데이터 사전(Data Dictionary): 개념 스키마는 데이터베이스에 대한 모든 정보를 담은 ‘데이터 사전’의 기초 자료. 데이터의 의미, 출처, 형식 등을 관리.

    • 의사소통 도구: 개발자, DBA, 현업 사용자 간의 원활한 의사소통을 돕는 공통의 문서 역할. 시스템 변경이나 확장 시 혼선을 방지.

4. 심화 내용: 3단계 스키마 구조 (3-Level Schema Architecture)

개념 스키마를 더 깊이 이해하려면 ANSI/SPARC에서 제안한 3단계 스키마 구조를 알아야 함. 이는 데이터 독립성을 확보하기 위한 표준 아키텍처.

  1. 외부 스키마 (External Schema / View Level)

    • 관점: 개별 사용자 또는 응용 프로그램의 관점.

    • 역할: 전체 데이터베이스 중 특정 사용자가 필요로 하는 부분만을 보여줌. 데이터베이스의 논리적 부분 집합.

    • 비유: 거대한 도서관(전체 데이터베이스)에서 특정 주제(예: 역사)에 관심 있는 사람이 관련 서가만 둘러보는 것.

  2. 개념 스키마 (Conceptual Schema / Logical Level)

    • 관점: 조직 전체의 통합된 관점.

    • 역할: 모든 사용자를 위한 데이터베이스의 전체적인 논리적 구조와 제약 조건을 정의. 데이터 간의 관계를 통합적으로 기술.

    • 비유: 도서관 전체의 모든 책이 어떤 분류 체계(예: 십진분류법)에 따라 정리되어 있는지 보여주는 ‘종합 도서 목록’ 또는 ‘설계도’.

  3. 내부 스키마 (Internal Schema / Physical Level)

    • 관점: 물리적 저장 장치의 관점.

    • 역할: 데이터가 디스크나 테이프 등 물리적 저장 장치에 실제로 어떻게 저장되는지를 기술. 인덱스, 데이터 압축, 파일 구조 등을 다룸.

    • 비유: 도서관의 책들이 실제로 ‘몇 번 서가의 몇 번째 칸’에 물리적으로 꽂혀 있는지에 대한 정보.

이 3단계 구조 덕분에, 내부 스키마(물리적 저장 방식)가 변경되어도 개념 스키마는 영향을 받지 않고(물리적 데이터 독립성), 개념 스키마의 일부 변경(전체 구조 변경)이 있어도 외부 스키마(사용자 뷰)는 영향을 받지 않을 수 있음(논리적 데이터 독립성).

이처럼 개념 스키마는 단순히 데이터 구조를 그리는 것을 넘어, 변화에 유연하고 안정적인 데이터베이스 시스템을 구축하는 데 있어 가장 핵심적인 역할을 담당.

혹시 개념 스키마를 설계할 때 사용하는 특정 모델링 기법(예: 정규화)이나 다른 종류의 스키마에 대해 더 궁금한 점이 있으신가요?

References

개념 스키마

그래프 뷰

백링크