Brain데이터 독립성 (Data Independence)
핵심 인사이트 (3줄 요약)
- 본질: 데이터 독립성 (Data Independence)은 데이터베이스의 상위 스키마가 하위 스키마의 변화로부터 영향을 받지 않는 성질로, 시스템의 유지보수성과 확장성의 핵심 기반이다.
- 가치: 물리적 저장 구조 변경(인덱스 추가, 파티셔닝)이 응용 프로그램에 영향을 주지 않게 하여, 소프트웨어 개발 비용과 유지보수 부담을 크게 줄인다.
- 융합: 클라우드 데이터베이스와 자동 튜닝 기술은 데이터 독립성 원칙 위에서 물리적 구조의 동적 최적화를 실현한다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
개념 정의
데이터 독립성 (Data Independence)은 데이터베이스 스키마의某一 수준이 다른 수준에서의 변화의 영향을 받지 않는 성질을 의미한다. ANSI/SPARC 3단계 아키텍처에서 핵심적으로追求되는 설계 원칙이다.
문제의식: 왜 필요한가?
초기 데이터베이스 시스템에서는 응용 프로그램이 데이터의 물리적 저장 구조와 긴밀하게 결합되어 있었다. 이로 인해 다음과 같은 문제가 발생했다.
┌─────────────────────────────────────────────────────────────────────┐
│ 데이터 독립성 부재로 인한 문제 상황 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ [문제 상황: 전화번호부 응용 程序] │
│ │
│ 1990년: 전화번호부 프로그램 ──▶ [파일: tel.dat, 순차 파일] │
│ │
│ 2000년: 저장 장치 SSD로 변경 ──▶ 프로그램 수정 필요!! │
│ 인덱스 추가로 검색 고속화 ──▶ 프로그램 수정 필요!! │
│ 파일 형식 변경 ──▶ 프로그램 전면 수정!! │
│ │
│ 결과: 유지보수 비용 > 신규 개발 비용 → 시스템 재작성 선택 │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 핵심 문제: │ │
│ │ 응용 程序이 "데이터의 내용"이 아닌 "데이터의 保存方式"을 │ │
│ │ 알고 있었기 때문에, 저장 방식이 변하면 프로그램도 함께 변해야 │ │
│ │ 했다. 이것을 "뚱형 의존성 (Physical Dependence)"이라 한다. │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 위 상황의 근본적 문제는 응용 程序이 물리적 저장 형식에 직접 의존했기 때문이다. SSD로 변경하면 입출력 방식이 바뀌고, 인덱스를 추가하면 검색 경로가 변한다. 응용 程序이 이러한 변화를 알아야 한다면 유지보수가 불가능할 만큼 비용이 커진다. 데이터 독립성은 응용 程序이 논리적 데이터 내용에만 의존하고, 물리적 저장 방식은 DBMS가抽象化하여 응用 程序에게 숨기는 구조로解决这个问题한다.
3단계 아키텍처와 독립성
ANSI/SPARC 3단계 아키텍처는 스키마를 세 수준으로 분리하여 데이터 독립성을 실현한다.
┌─────────────────────────────────────────────────────────────────────┐
│ ANSI/SPARC 3단계 아키텍처와 데이터 독립성 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 외부 스키마 (External Schema) │ │
│ │ 사용자/응용 程序이 보는 뷰 (View) │ │
│ │ │ │
│ │ 사용자 A: 고객 이름+전화번호만 보고 싶음 │ │
│ │ 사용자 B: 고객 전체 정보 + 주문 내역을 보고 싶음 │ │
│ │ │ │
│ └──────────────────────────┬──────────────────────────────────┘ │
│ │ 외부/개념 사상 (External/Conceptual) │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 개념 스키마 (Conceptual Schema) │ │
│ │ 전체 데이터베이스의 논리적 구조 │ │
│ │ │ │
│ │ 고객 테이블 ── 주문 테이블 ── 상품 테이블 │ │
│ │ (이름, 주소, 전화번호) (주문번호, 날짜) (상품명, 가격) │ │
│ │ │ │
│ └──────────────────────────┬──────────────────────────────────┘ │
│ │ 개념/내부 사상 (Conceptual/Internal) │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 내부 스키마 (Internal Schema) │ │
│ │ 물리적 저장 구조 (디스크 상의 실제 형식) │ │
│ │ │ │
│ │ 고객 테이블: B+ Tree 인덱스 on 고객ID │ │
│ │ 磁盘 저장: RAID 5, 블록 크기 8KB │ │
│ │ 압축 방식: Dictionary Compression │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 세 단계는 서로 다른关注 수준을 가진다. 외부 스키마는 사용자별로 필요한 데이터视图을 제공하고, 개념 스키마는 전체 조직의 관점에서 데이터의 논리적 구조를 정의한다. 내부 스키마는 실제 디스크에 어떻게 저장되는지를 기술한다. 핵심은 두 개의 **사상 (Mapping)**이다. 외부/개념 사상은 외부 스키마와 개념 스키마를 연결하고, 개념/내부 사상은 개념 스키마와 내부 스키마를 연결한다. 이러한 분리 덕분에 내부 스키마가 바뀌어도 개념 스키마에는 영향이 없고, 개념 스키마가 바뀌어도 외부 스키마(응용 程序)에 영향이 없다.
비유
데이터 독립성은 음식점의 메뉴와 조리 방식의 분리에 비유할 수 있다. 손님 (응용 程序)은 메뉴 (외부 스키마)만 보고 주문하지만, 주방 (내부 스키마)에서 조리 기기나 레시피가 바뀌어도 손님 입장에서는 동일하게 주문할 수 있다.
- 📢 섹션 요약 비유:建築물에서 입주자 (사용자)가 건물의 철골 구조 (내부 스키마)를 몰라도 사무실 (외부 스키마)만租用할 수 있는 것처럼, 데이터베이스에서도 응용 程序이 물리적 저장 구조를 몰라도 데이터에 접근할 수 있어야 합니다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
데이터 독립성의 유형
데이터 독립성은 두 가지 수준으로 구분된다.
| 유형 | 정의 | 변화의 방향 | 영향 받는 수준 |
|---|---|---|---|
| 논리적 데이터 독립성 | 개념 스키마가 외부 스키마에 미치는 영향이 없는 성질 | 개념 스키마 변화 → 외부 스키마 유지 | 외부 스키마 (응용 程序) |
| 물리적 데이터 독립성 | 내부 스키마가 개념 스키마에 미치는 영향이 없는 성질 | 내부 스키마 변화 → 개념 스키마 유지 | 개념 스키마 |
논리적 데이터 독립성
논리적 데이터 독립성 (Logical Data Independence)은 개념 스키마의 구조가 바뀌어도 외부 스키마에는 영향이 없다는 성질이다. 새로운 속성 추가, 테이블 분리/병합 등이 이에 해당한다.
┌─────────────────────────────────────────────────────────────────────┐
│ 논리적 데이터 독립성 예시 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ [개념 스키마 변경 전] │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 고객 (고객ID, 이름, 주소, 전화번호) │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ [개념 스키마 변경 후: 전화번호를 분리하여 연락처 테이블 생성] │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 고객 (고객ID, 이름, 주소) │ │
│ │ 연락처 (고객ID, 전화번호, 이메일) ──▶ 고객과 1:1 관계 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ 외부 스키마 (고객 조회 뷰): │
│ "CREATE VIEW 고객정보 AS │
│ SELECT c.고객ID, c.이름, c.주소, l.전화번호 │
│ FROM 고객 c JOIN 연락처 l ON c.고객ID = l.고객ID" │
│ │
│ → 응용 程序은 뷰를 통해 동일하게 고객 정보를 조회 │
│ → 개념 스키마 변경이 외부 스키마에 영향 없음! │
│ │
└─────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 개념 스키마에서 고객 테이블을 고객+연락처로 분리하면, 기존에 "SELECT * FROM 고객"으로 조회하던 응용 程序은 결과를 다르게 받을 수 있다. 그러나 뷰 (외부 스키마)를 통해 조회하면 응용 程序은 변경 전과 동일하게 고객ID, 이름, 주소, 전화번호를 얻을 수 있다. 이렇게 외부 스키마(뷰)를 활용하면 개념 스키마의 물리적 구조 변경을 외부 스키마에 독립적으로 만들 수 있다. 다만 외부 스키마 자체를 정의하는 방식 자체가 바뀌면(뷰 구조 변경) 응용 程序 수정이 필요할 수 있다.
물리적 데이터 독립성
물리적 데이터 독립성 (Physical Data Independence)은 내부 스키마(저장 구조)가 바뀌어도 개념 스키마에는 영향이 없다는 성질이다. 인덱스 추가, 파티셔닝, RAID 구성 변경 등이 이에 해당한다.
┌─────────────────────────────────────────────────────────────────────┐
│ 물리적 데이터 독립성 예시 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ [내부 스키마 변경 전] │
│ │
│ 고객 테이블 ──▶ [클러스터드 인덱스 on 고객ID] │
│ ──▶ [순차 파일 할당] │
│ │
│ [내부 스키마 변경 후: 성능 최적화를 위한 구조 변경] │
│ │
│ 고객 테이블 ──▶ [非클러스터드 인덱스 on 이름+지역] │
│ ──▶ [디스크 배열 RAID 10 구성] │
│ ──▶ [페이지 크기 16KB로 확대] │
│ ──▶ [데이터 압축 적용] │
│ │
│ 개념 스키마: 변경 없음! │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 고객 (고객ID, 이름, 주소, 전화번호) ← 동일 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ → 응용 程序의 SQL은 동일하게 "SELECT * FROM 고객 WHERE ..." │
│ → 내부 구현이 바뀌어도 논리적 구조는 불변! │
│ │
└─────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 클러스터드 인덱스를 비클러스터드 인덱스로 바꾸면 데이터의 물리적 저장 순서가变了. RAID 구성을 RAID 5에서 RAID 10으로 변경하면 장애 복구 능력이变了. 그러나 이러한 변화는概念 스키마에는 반영되지 않으며, 응용 程序이 SELECT 문으로 데이터를 조회하는 방식도 동일하다. 이것이 물리적 데이터 독립성이다. DBMS의 옵티마이저가 내부 스키마의 변화에 따라 실행 계획을自動再作成해주기 때문에 가능하다.
사상의 역할
두 가지 독립성을 실현하는 핵심이 **사상 (Mapping)**이다. 사상은 상위 수준 스키마의 질의를 하위 수준 스키마의 operation으로 변환하는 규칙이다.
┌─────────────────────────────────────────────────────────────────────┐
│ 사상의 유형과 역할 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 외부/개념 사상 (External/Conceptual Mapping) │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 역할: 사용자 질의 → 개념 스키마 명령으로 변환 │ │
│ │ 개념 스키마 변경 시 → 외부/개념 사상만 수정 │ │
│ │ → 응용 程序是无kem! │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ 개념/내부 사상 (Conceptual/Internal Mapping) │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 역할: 개념 스키마 명령 → 물리적 저장 명령으로 변환 │ │
│ │ 내부 스키마 변경 시 → 개념/내부 사상만 수정 │ │
│ │ → 개념 스키마는 영향받지 않음! │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 참고: 사상 규칙은 DBMS 카탈로그 (System Catalog)에 저장됨 │ │
│ │ 예: SYSCATALOG 테이블에 외부 뷰 ↔ 개념 테이블 매핑 정보 유지 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 사상은 일종의번역사 역할이다. 외부 스키마의 SELECT 문을 개념 스키마의 관계 대수运算으로 변환하고, 다시 개념 스키마 연산을 내부 스키마의 물리적 파일 접근으로 변환한다. 만약 내부 저장 구조가 바뀌면, 개념/내부 사상만 업데이트하면 되고, 개념 스키마와 외부 스키마는 변경 없이 기존 operation을 계속 수행할 수 있다. 이 구조 덕분에 시스템의局部 변경이全局에 미치는 영향을 최소화할 수 있다.
- 📢 섹션 요약 비유: 국제회의에서 Simultaneous Interpreter (동시 통역사)가演的 역할과 유사합니다. 발언자의 언어 (내부 스키마)가 바뀌어도, 통역사를 통한 청중 (외부 스키마)에게는 동일한 내용으로 전달됩니다.
Ⅲ. 융합 비교 및 다각도 분석
비교 1: 논리적 vs 물리적 데이터 독립성
| 구분 | 논리적 데이터 독립성 | 물리적 데이터 독립성 |
|---|---|---|
| 보호하는 수준 | 개념 스키마 → 외부 스키마 | 내부 스키마 → 개념 스키마 |
| 변화 유형 | 테이블 추가/분리, 속성 추가/삭제 | 인덱스 변경, 파티셔닝, 스토리지 변경 |
| 달성 난이도 | 상대적으로 어려움 (논리 구조 변경) | 상대적으로 쉬움 (물리 구조 변경) |
| 영향 받는 범위 | 외부 스키마/응용 程序 | 개념 스키마 전체 |
| 요구되는 메커니즘 | 뷰 (View), 사상 규칙 | 버퍼 관리, 접근 경로 추상화 |
논리적 데이터 독립성이 물리적보다 달성하기 어려운 이유는 논리 구조가 응用 程序의 데이터 사용 방식과 밀접하게 결합되기 때문이다.
비교 2: 데이터 독립성과 다른 개념 비교
| 개념 | 핵심 내용 | 데이터 독립성과의 관계 |
|---|---|---|
| 데이터 은폐 | 불필요한 구현 세부 정보를 숨김 | 데이터 독립성의 구현 메커니즘 |
| 추상화 | 관련 없는 세부 사항 제거 | 데이터 독립성의理论基础 |
| 캡슐화 | 객체 내부 상태를 외부에서 은폐 | 소프트웨어 엔지니어링领域的抽象화 |
| 모듈성 | 시스템을 독립적 모듈로 분리 | 데이터 독립성의 설계 원칙 |
- 📢 섹션 요약 비유: 레스토랑에서 손님이 주방의 조리 도구 (물리적 구조)를 몰라도 요리를 주문 (논리적 질의)할 수 있듯이, 데이터베이스도 응用 程序이 물리적 저장 구조를 몰라도 데이터를 操作할 수 있어야 합니다.
Ⅳ. 실무 적용 및 기술사적 판단
실무 시나리오
-
시나리오 — 인덱스 추가: 기존 테이블에 검색 성능 향상을 위해 B+ Tree 인덱스를 추가한다. 이때 응용 程序의 SQL은 변경되지 않으며, DBMS 옵티마이저가 새 인덱스를 활용하여 실행 계획을 자동 조정한다. 물리적 데이터 독립성이 보장된 상태에서 성능만 개선된 케이스다.
-
시나리오 — 테이블 파티셔닝: 대용량 주문 테이블을 연도별로 파티셔닝하여 관리한다. 응용 程序의 SELECT 문은 동일하지만, DBMS가 자동으로 해당 파티션에만 접근하여 성능을 최적화한다. 논리적 구조는 동일하게 보이지만 물리적으로는 데이터가 분산 저장된 상황이다.
-
시나리오 — 마이크로서비스 전환: 모놀리식 응용 程序을 마이크로서비스로 전환할 때, 각 서비스가 자신의 외부 스키마 (뷰)를 갖고 있도록 설계하면, 향후 데이터베이스 스키마 변경 시 영향 범위가 해당 서비스로 제한된다.
┌─────────────────────────────────────────────────────────────────────┐
│ 데이터 독립성 확보를 위한 설계 가이드라인 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ✅ 해야 할 것: │
│ • 뷰 (View)를 통해 응용 程序에 데이터 노출 │
│ • 응용 程序은 테이블명이 아닌 뷰를 참조하도록 설계 │
│ • 저장 프로시저 (Stored Procedure)로 접근 패턴抽象化 │
│ • 메타데이터 (카탈로그)를 최신 상태로 유지 │
│ │
│ ❌ 하지 말아야 할 할 것: │
│ • 응용 程序에서 SELECT * 사용 (테이블 구조 변화 시 영향) │
│ • 뷰 없이 테이블 직접 참조 │
│ • DBMS 종속적 기능을 응용 程序에서 직접 사용 │
│ • 하드코딩된 테이블명/컬럼명 │
│ │
└─────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 실무에서 데이터 독립성을 보장하려면 응용 程序과 데이터베이스 사이에 항상추상화 계층을 두어야 한다. 뷰는 가장 간단한 방법이다. SELECT * 대신 뷰를 참조하면, 기반 테이블의 구조가 바뀌어도 뷰 정의만 업데이트하면 응용 程序은 변경 없이 동작한다. 그러나 뷰는 성능 오버헤드가 있으므로, 성능이 중요한 경로에서는Stored Procedure나 ORM (Object-Relational Mapping)을 통한间接 접근도 고려할 수 있다.
도입 체크리스트
- 기술적: 모든 데이터 접근이 DBMS를 통하도록 되었는가? 응용 程序에서 테이블명을 하드코딩하지 않았는가?
- 운영·보안적: 뷰를 통해 민감 정보에 대한 접근을 제한하고 있는가? 스키마 변경 시 영향 분석 절차를 갖추고 있는가?
안티패턴
-
SELECT * 남용: SELECT * FROM 테이블은 테이블 구조가 변하면 응용 程序이 오류를 발생시킨다. 필요한 컬럼만 명시적으로 선택해야 독립성이 보장된다.
-
저장 프로시저滥用: 모든 로직을 Stored Procedure에 넣으면 DBMS 종속성이 높아지고 응용 程序과 DBMS 간 결합도가 강해진다.
-
📢 섹션 요약 비유: 스마트폰 앱이 특정 기기 모델에 맞춰 하드코딩되면 새 기기에서 작동하지 않는 것처럼, 응용 程序이 특정 DBMS의 내부 구조에 맞춰 작성되면 시스템 유지보수가 매우 어려워집니다.
Ⅴ. 기대효과 및 결론
정량/정성 기대효과
| 구분 | 독립성 미달성 | 독립성 확보 | 개선 효과 |
|---|---|---|---|
| 정량 | 스키마 변경 시 응용 程序 수정 3~6개월 | 응용 程序 수정 불필요 또는 단축 | 유지보수 시간 70% 절감 |
| 정량 | 새 응용 程序 개발 1년 | 재사용 가능한 스키마로 6개월 | 개발 생산성 50% 향상 |
| 정성 | 데이터 구조 변경 시 시스템 전체 재테스트 | 局部 변경으로 测试 범위 축소 | 리스크大幅 감소 |
| 정성 | 기술 교체 시 대규모 마이그레이션 | 점진적 마이그레이션 가능 | 시스템 수名大幅 향상 |
미래 전망
- 자율적 데이터 독립성: AI가 스키마 변경의 영향을 자동 분석하여 필요한 사상 수정을 추천하거나 자동 수행
- 声明적 데이터 관리 (Declarative Data Management): 사용자가 원하는 데이터 결과만声明하면, 시스템이 내부 스키마를 동적으로再구성
┌─────────────────────────────────────────────────────────────────────┐
│ 데이터 독립성 확보 수준의 진화 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Level 1 (수동) Level 2 (半자동) Level 3 (全自动) │
│ [전통적 DBMS] [모던 DBMS] [AI-增强 DBMS] │
│ │
│ 스키마 변경 ──▶ 스키마 변경 ──▶ 스키마 변경 ──▶ │
│ 수동 사상 갱신 도구 활용 사상 생성 AI가 영향 자동 분석 │
│ (人力) (半自動) 및 사상 자동 갱신 │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 핵심 과제: 변화에 대한影響 범위를 최소화하고, 변화에 강인한 │ │
│ │ (Change-Resilient) 데이터베이스 아키텍처를 구축하는 것 │ │
│ └─────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] Level 1에서는 DBA가 수동으로 모든 사상을 업데이트했다. Level 2에서는 DBMS가 메타데이터를 자동 관리하고 뷰를 통해抽象화를 제공하지만, 스키마 변경 시 일부 수동 작업이 필요했다. Level 3에서는 AI가 스키마 변경의 영향을 분석하고, 응용 程序에 맞는外部视图를 자동 생성하거나 조정하는 것이 목표다. 현재는 Level 2에서 Level 3로 전환하는 과도기에 있으며, 이는 클라우드 네이티브 데이터베이스의 자동化管理 功能과 맞물려 진행되고 있다.
- 📢 섹션 요약 비유: 도시 계획에서 모든 건물이 도로 구조 (물리적)에 직접 연결되면 도로 변경 시 건물 전체를 헐어야 하지만, 단지 개발 시 주변과 분리된 단지 내부 도로 (독립성)를 만들면 외부의 도로 변경이 단지 내부에 영향을 주지 않는 것과 같습니다.
📌 관련 개념 맵 (Knowledge Graph)
| 개념 명칭 | 관계 및 시너지 설명 |
|---|---|
| 스키마 | 데이터베이스의 구조를 정의하는 청사진으로, 3단계 아키텍처에서 외부/개념/내부 스키마로 구분된다. |
| 사상 (Mapping) | 상위 스키마의 질의를 하위 스키마의 operation으로 변환하는 규칙으로, 데이터 독립성의 핵심이다. |
| 뷰 (View) | 하나 이상의 테이블에서 유도되는 가상 테이블로, 외부 스키마를 구현하는 데 사용된다. |
| 옵티마이저 | SQL 질의를 최적의 실행 계획으로 변환하는 DBMS 모듈로, 물리적 독립성을 보장하는 역할을 한다. |
| 카탈로그 (Catalog) | 메타데이터 (스키마, 사상 규칙, 사용자 정보 등)를 저장하는 시스템 데이터베이스이다. |
| 추상화 | 불필요한 세부 사항을 숨기고 핵심 특성만 보여주는 원리로, 데이터 독립성의理论基础이다. |
👶 어린이를 위한 3줄 비유 설명
- 데이터 독립성은 레고 블록과 같아요. 블록의 크기나 모양 (내부 구조)이 바뀌어도, 우리가 만든 레고 하우스 (외부 뷰)의 모양은 유지될 수 있어요.
- 예를 들어, 레고 블록의 재질이 플라스틱에서 금속으로 바뀌어도, 우리가 쌓아 올린 성의 모양은 그대로 유지되는 거죠.
- 컴퓨터에서도 이렇게 데이터가 어떻게 저장되든 (플라스틱→금속), 우리가 보는 화면 (외부 뷰)은 동일하게 작동해야 하니까, 데이터 독립성이 중요해요!