데이터베이스 설계: 통합·공유 데이터를 운영하는 구조

여러 업무가 같은 데이터를 바라보게 하는 저장소

데이터베이스는 다수 사용자의 정보 요구를 충족하도록 만든 데이터 집합이다. 서로 연관된 데이터를 최소한의 중복으로 통합하고, 조직의 여러 응용 시스템이 공동으로 사용하는 저장소라는 점이 핵심이다. 관련 데이터는 구조화된 형태로 전자적 매체에 보관된다.

은행을 예로 들면 고객 정보, 계좌 정보, 거래 내역은 서로 연결되어 있다. 창구 업무와 인터넷 뱅킹, 모바일 뱅킹은 이 데이터를 각기 다른 채널에서 사용한다. 데이터베이스는 이처럼 여러 업무가 같은 사실을 일관되게 다룰 수 있게 한다.

통합·저장·운영·공유로 보는 데이터베이스의 성격

통합된 데이터는 조직의 여러 업무 영역에 흩어진 데이터를 하나의 관점에서 관리하는 것을 뜻한다. 중복을 줄여 일관성과 무결성을 확보하고, 부서별 데이터를 논리적으로 통합한다. 대학 정보시스템에서 학사·등록·장학·취업 부서가 각각 관리하던 학생 정보를 통합 데이터베이스로 옮기면 데이터 불일치 문제를 해소할 수 있다.

저장 데이터는 컴퓨터가 접근할 수 있는 저장 매체에 보관되는 데이터다. 휘발되지 않는 형태로 남아야 하며, 물리적 저장 장치에 체계적으로 구조화된다. 기업 고객 데이터를 SSD나 하드디스크 같은 비휘발성 저장 장치에 저장하면 시스템이 종료된 뒤에도 데이터가 유지된다.

운영 데이터는 조직의 목적을 위해 실제 업무에 쓰이는 현재의 데이터다. 일상적인 업무 처리와 의사결정에 활용된다. 제조업체의 재고 관리 시스템에서 보유 재고량, 생산 계획, 주문 정보는 모두 운영에 직접 필요한 데이터다.

공유 데이터는 여러 사용자와 애플리케이션이 동시에 접근할 수 있는 데이터다. 권한에 따라 접근을 제어하고, 동시성 제어로 다중 사용자 환경을 지원한다. 항공사 예약 시스템에서는 여러 여행사와 고객이 같은 항공편 좌석 정보를 조회하고 예약할 수 있다.

설계는 요구사항을 실행 가능한 구조로 옮기는 과정

데이터베이스 구축은 계획 수립, 요구사항 분석, 개념적 설계, 논리적 설계, 물리적 설계, 구현의 여섯 단계로 진행된다. 앞선 단계에서 정한 업무 규칙과 데이터 관계는 뒤 단계에서 모델과 스키마, 저장 구조로 구체화된다.

구축 범위와 자원을 먼저 정한다

계획 수립 단계에서는 데이터베이스 구축 목적과 범위를 정의하고, 전체 시스템 아키텍처를 설계한다. 필요한 자원과 일정을 계획하면서 기술적·관리적 이슈도 식별한다.

산출물은 프로젝트 계획서와 요구사항 명세서 초안이다.

업무 요구를 데이터와 처리 요구로 분해한다

요구사항 분석에서는 사용자와 업무의 요구를 수집·분석한다. 데이터 요구사항, 처리 요구사항, 시스템 제약사항을 확인하며 사용자 인터뷰, 문서 검토, 업무 분석을 수행한다.

이 단계에서는 요구사항 명세서와 데이터 사전 초안을 만든다.

업무 모델에서 엔티티와 관계를 잡는다

개념적 설계는 업무 중심의 추상적 데이터 모델을 만드는 단계다. 주요 엔티티와 관계를 식별하고 E-R 다이어그램을 작성한다. 특정 DBMS에 종속되지 않는 설계가 이 단계의 특징이다.

⤢✕

산출물은 개념적 데이터 모델과 E-R 다이어그램이다.

데이터 모델에 맞춰 테이블과 제약을 정의한다

논리적 설계에서는 개념적 모델을 관계형이나 객체지향형 같은 특정 데이터 모델로 변환한다. 정규화로 데이터 중복을 제거하고, 테이블·키·관계를 정의하며 무결성 제약조건을 설정한다.

관계형 데이터베이스에서는 E-R 다이어그램을 테이블 스키마로 변환한다.

⤢✕

이 단계의 결과물은 논리적 데이터 모델, 테이블 정의서, 관계 정의서다.

DBMS와 접근 방식에 맞게 저장 구조를 결정한다

물리적 설계는 논리적 모델을 특정 DBMS에 맞춰 구체화하는 단계다. 저장 구조와 파일 조직, 인덱스를 설계하고 접근 경로를 최적화한다. 성능을 고려해 물리적 구조를 결정한다.

Oracle 데이터베이스를 사용한다면 테이블스페이스 할당, 인덱스 생성, 파티셔닝 전략 수립이 이 단계에 포함된다. 물리적 데이터베이스 스키마, 인덱스 설계서, 저장 공간 예측치가 산출물이다.

스키마를 만들고 데이터와 응용 프로그램을 연결한다

구현 단계에서는 물리적 데이터베이스를 생성하고 DDL(Data Definition Language)로 스키마를 구현한다. 데이터 로딩과 변환, 응용 프로그램 개발과 테스트, 성능 튜닝과 최적화가 이어진다.

구현된 데이터베이스, SQL 스크립트, 테스트 결과가 이 단계에서 남는다.

설계 단계 사이에서 오가는 검토 항목

⤢✕

잘 설계된 데이터베이스는 데이터 중복을 줄여 저장 공간을 절약하고, 일관성과 무결성을 통해 신뢰할 수 있는 정보를 제공한다. 효율적인 접근 경로는 시스템 성능에 영향을 주며, 확장성과 유연성은 비즈니스 변화에 대응할 기반이 된다. 데이터 보호와 접근 제어를 위한 보안 설계도 함께 필요하다.

전자상거래와 의료정보 시스템에 적용하는 방식

온라인 쇼핑몰을 설계할 때는 사용자 1만 명, 상품 10만 개 규모의 중소형 쇼핑몰을 대상으로 구축 계획을 수립할 수 있다. 회원 관리, 상품 관리, 주문 처리, 결제, 배송 관리가 핵심 요구사항이 된다. 회원·상품·카테고리·주문·결제·배송 엔티티와 관계를 모델링한 뒤, 이를 회원 테이블·상품 테이블·주문 테이블 등으로 변환하고 정규화한다. 물리 설계에서는 MySQL InnoDB 엔진을 선택하고 주문번호와 상품ID에 인덱스를 생성하며 로그 데이터 파티셔닝을 설계한다. 이후 SQL DDL 스크립트 작성, 테이블 생성, 제약조건 설정, 초기 데이터 로딩으로 구현한다.

병원 정보 시스템에서는 환자 정보, 진료 기록, 처방전, 검사 결과를 관리하는 통합 의료정보 시스템을 계획한다. 의사·간호사·행정 직원처럼 사용자 그룹이 다른 만큼 요구사항 수집도 중요하다. 환자, 의사, 진료, 처방, 검사 엔티티를 식별하고 관계를 설정한 뒤, 민감한 환자 개인정보는 별도 테이블로 분리하고 엄격한 정규화를 적용한다. Oracle Database 환경에서는 진료 기록을 시간별로 파티셔닝하고, 대용량 의료 영상 데이터는 외부 참조 방식으로 설계한다. 구현 단계에서는 강력한 보안 제약조건과 감사 추적(Audit Trail) 기능을 적용한다.

빅데이터, 클라우드 컴퓨팅, IoT 환경에서는 전통적인 설계 방법론에 더해 확장성, 분산처리, 실시간 데이터 처리 요구를 함께 고려해야 한다. 변화에 대응하면서도 데이터의 일관성과 무결성을 유지하는 설계가 필요하다.