데이터 구조 계층·데이터 참조 모델·사용자 뷰

핵심 요약

데이터 구조는 한 장의 ERD로 끝나지 않는다. 개념 모델은 업무의 큰 대상과 관계, 논리 모델은 속성·식별자·관계·정규화된 구조, 물리 모델은 DBMS 구현 구조, 데이터베이스는 실제 저장·제약·접근 구조, 사용자 뷰는 특정 사용자·업무가 보는 외부 표현을 담당한다. 데이터 참조 모델은 반복되는 업무 영역에 재사용할 수 있는 기준 구조와 패턴을 제공한다.

업무 전략·범위
   → 개념 데이터 모델
   → 논리 데이터 모델
   → 물리 데이터 모델
   → 데이터베이스 구현
   → 사용자 뷰·API·보고서

데이터 참조 모델: 여러 단계에서 재사용할 공통 구조·분류·관계의 기준

학습 목표

• 개념·논리·물리 모델, 데이터베이스, 사용자 뷰의 추상화 수준과 산출물을 구분합니다.
• 데이터 참조 모델과 참조 데이터·표준 데이터의 차이를 설명합니다.
• 계층 간 매핑과 추적성 결함을 판별합니다.
• 사용자 뷰의 보안·호환성·활용 역할과 한계를 사례에 적용합니다.

1. 개념 설명

1.1 개념 데이터 모델

개념 모델은 조직이 관리해야 할 핵심 업무 대상과 큰 관계, 주제영역을 이해관계자와 공유하는 고수준 모델이다. 세부 자료형·인덱스·파티션보다 업무 범위, 핵심 엔터티, 주요 관계와 통합 관점에 초점을 둔다.

• 질문: 무엇을 관리하고 서로 어떤 관계가 있는가?
• 예: 고객, 계약, 청구, 지급과 주요 관계
• 품질 결함: 핵심 대상 누락, 범위 중복, 잘못된 업무 관계

1.2 데이터 참조 모델

데이터 참조 모델은 산업·조직·업무 영역에서 반복적으로 사용할 수 있는 데이터 분류, 공통 구조, 엔터티·관계 패턴의 기준이다. 신규 모델의 출발점과 비교 기준을 제공하지만 그대로 복사하는 정답 모델은 아니다.

구분: 데이터 참조 모델은 구조의 기준 모델이고, 참조 데이터는 국가코드·상태코드처럼 여러 시스템이 공통으로 참조하는 값 집합이다.

참조 모델을 적용할 때는 업무 적합성, 조직 용어, 규제, 데이터 생명주기와 실제 요구를 검토하고 채택·변형·제외 근거를 기록한다.

1.3 논리 데이터 모델

논리 모델은 특정 DBMS와 독립적으로 업무 데이터를 상세화한다.

• 엔터티·속성·식별자·관계
• 선택성·카디널리티·서브타입·이력
• 정규화와 업무 규칙
• 표준 용어·도메인 적용

품질 관점에서는 업무 규칙의 정확성·완전성, 중복 통제, 키 안정성, 관계와 속성 정의를 검토한다.

1.4 물리 데이터 모델

물리 모델은 논리 구조를 선택한 DBMS와 운영 환경에 맞게 구현 구조로 변환한다.

• 테이블·컬럼·자료형·길이·NULL·기본값
• PK·UK·FK·CHECK 등 제약
• 인덱스·파티션·테이블스페이스/저장 구조
• 반정규화와 성능·운영 속성
• 명명 규칙과 배포 대상

논리 모델의 업무 의미를 보존하면서 제품 제약과 성능·가용성·보안 요구를 반영해야 한다.

1.5 데이터베이스

데이터베이스는 물리 모델이 실제 DDL, 데이터, 제약, 인덱스, 권한, 통계와 운영 상태로 구현된 것이다. 승인 모델과의 일치뿐 아니라 운영 중 긴급 변경, 미사용 객체, 실제 데이터 무결성, 백업·보안 상태까지 관리 대상이 된다.

1.6 사용자 뷰

사용자 뷰는 특정 사용자·업무·애플리케이션이 필요로 하는 데이터의 외부 표현이다. DB 뷰, API 응답, 데이터 마트·보고서 모델 등으로 구현될 수 있다.

• 필요한 행·열·계산·용어로 단순화
• 원본 구조 변경의 영향을 완화하는 호환 계층
• 민감 열이나 불필요한 행 노출 제한
• 여러 원천의 통합 표현

그러나 뷰 자체가 원본 권한을 항상 대체하거나 성능을 자동 향상시키는 것은 아니다. 중첩 뷰, 복잡한 계산, 잘못된 조인은 오히려 추적성과 성능을 떨어뜨릴 수 있다.

2. 계층별 비교

3. 계층 간 판단 흐름

1. 개념 모델에서 업무 범위·핵심 대상을 확인한다.
2. 데이터 참조 모델을 비교해 공통 구조·누락 후보를 찾되 업무에 맞게 조정한다.
3. 논리 모델에서 속성·식별자·관계·이력·표준을 상세화한다.
4. 물리 모델에서 제품·성능·보안·운영 요소로 변환하고 변환 근거를 남긴다.
5. 실제 DB와 모델의 객체·제약·데이터 상태를 비교한다.
6. 사용자 뷰가 원천·변환·기준일·권한과 연결되는지 확인한다.
7. 어느 계층의 변경이 다른 계층과 사용자에게 미치는지 영향분석한다.

4. 사례·텍스트 다이어그램

사례: ‘고객’의 계층별 표현

개념: 고객 ─ 계약
논리: 고객(고객번호, 고객명, 고객유형, 유효기간)
물리: TB_CUST(CUST_ID NUMBER, CUST_NM VARCHAR2..., ...)
DB: 실제 컬럼·PK·인덱스·권한·데이터
사용자 뷰: VW_ACTIVE_CUSTOMER(활성 고객의 고객번호·표시명만 제공)

사용자 뷰의 표시명이 개인 고객은 성명, 법인 고객은 상호를 선택하는 계산이라면 그 규칙과 원천 열이 계보에 기록되어야 한다. 물리 컬럼명이 바뀌어도 뷰 계약을 유지할 수 있지만, 뷰 정의와 실제 DB가 동기화되지 않으면 오류가 생긴다.

데이터 참조 모델 적용 판단

금융권 참조 모델에 ‘계약-청구-지급’ 구조가 있다고 해서 모든 조직에 그대로 적용하지 않는다. 조직이 선불 업무만 수행해 청구가 없으면 제외 근거를 남기고, 조직 고유의 규제 엔터티가 있으면 확장한다. 참조 모델 준수율보다 업무 적합성과 추적 가능한 차이 관리가 중요하다.

5. 비교와 구분

시험 판단 포인트

• 공식 데이터 구조 이해 범위는 개념 모델, 데이터 참조 모델, 논리 모델, 물리 모델, 데이터베이스, 사용자 뷰를 구분한다.
• 데이터 참조 모델은 참조 데이터와 다른 개념이다.
• 논리→물리 변환에서 이름·자료형뿐 아니라 키·관계·무결성·반정규화 근거를 추적한다.
• 사용자 뷰는 외부 표현과 활용·보안·호환성을 지원하지만 원본 구조와 품질 문제를 자동 해결하지 않는다.
• 계층 간 불일치는 어느 한 계층을 무조건 정답으로 삼지 않고 승인 요구·변경 이력을 확인한다.

자주 틀리는 부분

• 개념 모델에 물리 자료형·인덱스를 상세하게 넣어 추상화 수준을 혼합한다.
• 참조 모델을 업무 검토 없이 그대로 복사해 조직 고유 요구를 누락한다.
• 일반 DB 뷰가 별도 저장공간을 항상 가진다고 생각한다.
• 사용자 뷰가 데이터를 가리므로 원본 객체 권한과 감사가 필요 없다고 본다.
• 물리 모델과 DB 이름만 같으면 모든 계층의 추적성이 확보됐다고 판단한다.