개념 모델링으로 업무 규칙을 데이터 구조로 옮기는 방법

업무의 언어를 데이터 구조로 번역하는 일

개념 모델링은 현실 세계에 존재하는 사물과 그 사이의 관계를 구조적으로 표현하는 과정이다. 데이터베이스 설계에서 구현보다 앞서는 청사진이며, 업무 요구사항과 데이터 구조 사이의 간극을 연결한다.

이 단계에서 만든 모델은 이해관계자와 개발자가 같은 대상을 같은 의미로 논의할 수 있게 한다. 잘못된 개념 모델링은 시스템 개발 실패의 원인이 될 수 있고, 반대로 변화에 유연하게 대응할 데이터 구조의 기반이 된다.

모델을 이루는 기본 단위

엔티티(Entity)는 업무에서 관리해야 하는 정보의 집합이다. 보통 명사형으로 표현하며 독립적으로 존재할 수 있다. 고객, 상품, 주문, 직원이 여기에 해당한다. 엔티티는 유일한 식별자를 가져야 하고, 두 개 이상의 인스턴스를 보유하며, 속성을 가진다.

속성(Attribute)은 엔티티의 특성이나 성질을 나타내는 데이터 항목이다. 고객 엔티티라면 고객ID, 이름, 주소, 전화번호가 속성이 될 수 있다. 속성은 단일값과 다중값, 단순과 복합, 유도와 저장 속성으로 나눌 수 있다.

관계(Relationship)는 엔티티 사이의 연관성을 드러낸다. 주문한다, 소속된다처럼 동사형으로 표현한다. 한 인스턴스가 다른 인스턴스 하나에만 연결되는 일대일(1:1), 여러 인스턴스에 연결되는 일대다(1:N), 양쪽이 서로 여러 인스턴스와 연결되는 다대다(M:N)가 있다.

식별자(Identifier)는 엔티티 안에서 각 인스턴스를 유일하게 구분하는 속성 또는 속성의 집합이다. 후보키, 기본키, 대체키, 외래키로 구분한다.

주제영역에서 검증까지 이어지는 모델링 흐름

⤢✕

먼저 업무 범위를 나누어 주요 정보 그룹을 찾고, 시스템의 범위와 경계를 정한다. 은행 시스템이라면 고객관리, 계좌관리, 거래관리처럼 주제영역을 나눌 수 있다.

주제영역 안에서는 비즈니스 프로세스와 요구사항을 분석해 관리 대상인 핵심 데이터 그룹을 뽑는다. 계좌관리에서는 계좌, 계좌종류, 이자율 등이 엔티티가 될 수 있다.

그다음 엔티티 사이의 연관성을 정의한다. 관계의 유형인 1:1, 1:N, M:N과 참여도인 필수·선택을 함께 결정한다. 고객과 계좌는 고객이 개설한다는 관계로 1:N 관계를 설정할 수 있다.

각 엔티티에 필요한 정보 요소를 속성으로 정리한다. 계좌에는 계좌번호, 개설일, 잔액 같은 속성이 들어간다. 이어서 인스턴스를 구별할 속성을 선정하고, 자연키와 인조키 가운데 적절한 방식을 고른다. 계좌번호를 계좌 엔티티의 기본키로 선정하는 방식이 예다.

마지막 검증에서는 모델의 완전성, 정확성, 일관성을 확인한다. 중복·누락·모순을 찾아 수정하고, 현업 담당자와 검토해 업무 적합성을 확인한다.

분석의 출발점에 따른 접근 방식

개체분석(Entity Analysis)은 큰 개념에서 세부 데이터 항목으로 내려가는 하향식(Top-down) 방식이다. 주요 개체를 식별하고, 개체 간 관계를 정의한 뒤, 세부 속성을 도출한다. 전체 구조를 파악하기 쉽지만 세부 요구사항이 누락될 수 있다.

속성합성(Attribute Synthesis)은 개별 데이터 항목을 모아 상위 개념으로 통합하는 상향식(Bottom-up) 방식이다. 데이터 항목을 수집하고 분류·그룹화한 뒤 개체와 관계를 정의한다. 세부 요구사항 누락 가능성은 낮지만 전체 구조를 보기가 어려울 수 있다.

개념확장(Inside Out)은 속성확장의 한 종류로, 가장 명확하고 안정적인 핵심 개념에서 출발해 연관 개념으로 넓혀 간다. 핵심 개념을 식별하고 연관 개념으로 확장한 후 관계와 속성을 정한다. 복잡한 도메인에서 안정적인 모델을 구축할 수 있으나, 시작점을 잘못 잡으면 전체 모델에 영향이 간다.

혼합방법은 EA와 AS의 장점을 함께 쓰는 접근이다. 분할정복(Divide and Conquer) 전략도 허용한다. 주요 개체를 식별한 뒤 세부 데이터 항목을 수집하고, 결과를 통합·조정한다. 유연성이 높고 복잡한 시스템에 적합하지만 방법론을 전환할 시점을 정하기 어려울 수 있다.

ERD와 UML로 모델을 표현하는 방식

ERD(Entity-Relationship Diagram)는 엔티티, 속성, 관계를 그래픽 요소로 나타내는 대표적인 개념 모델링 기법이다.

⤢✕

객체지향 시스템에서는 UML 클래스 다이어그램도 주로 사용한다. 클래스, 속성, 연산, 관계를 표현하며 개념 모델링뿐 아니라 논리·물리 모델링에도 활용할 수 있다.

쇼핑몰과 병원 시스템에 적용해 보기

온라인 쇼핑몰은 고객관리, 상품관리, 주문관리, 배송관리로 주제영역을 나눌 수 있다. 핵심 엔티티는 고객, 상품, 주문, 주문항목, 배송이다. 고객은 여러 주문을 할 수 있으므로 고객과 주문은 1:N 관계다. 주문은 여러 주문항목을 포함하고, 상품은 여러 주문항목에 포함될 수 있어 각각 1:N 관계가 된다. 주문과 배송은 주문이 하나의 배송정보를 갖는 1:1 관계로 표현한다.

병원 관리 시스템은 환자관리, 의사관리, 진료관리, 처방관리로 구분할 수 있다. 환자, 의사, 진료, 처방, 약품이 핵심 엔티티다. 환자는 여러 진료를 받을 수 있고 의사는 여러 진료를 수행할 수 있으므로, 환자와 진료 및 의사와 진료는 각각 1:N 관계다. 하나의 진료에서 여러 처방이 나올 수 있으며 약품은 여러 처방에 포함될 수 있어 진료와 처방, 약품과 처방도 1:N 관계가 된다.

모델을 운영 가능한 형태로 다듬을 때

업무 전문가와 협업해 요구사항을 정확히 이해하고, 애매한 용어는 정의와 용어사전으로 고정해야 한다. 엔티티는 명사, 관계는 동사 형태로 쓰는 등 명명 규칙을 일관되게 적용한다.

엔티티와 관계가 지나치게 많아져 모델이 복잡해지는 상황도 경계할 필요가 있다. M:N 관계는 이후 구현을 고려해 식별하고, 데이터 생명주기(CRUD)도 모델링에 반영한다. 확장성을 고려해 유연한 구조를 설계하되, 정기적인 검토와 피드백으로 모델을 계속 개선한다.

구현 모델로 구체화되는 과정

⤢✕

개념 모델을 논리 모델로 옮길 때는 모든 M:N 관계를 1:N 관계로 분해하고, 다중값 속성은 별도 엔티티로 분리한다. 상속 관계의 구현 방식인 슈퍼/서브타입을 결정하고, 속성의 도메인과 제약조건을 명시한다.

논리 모델을 물리 모델로 전환할 때는 DBMS 특성에 맞춰 데이터 타입을 매핑한다. 성능을 고려해 인덱스를 설계하고, 저장 공간 최적화를 위한 정규화·반정규화를 결정한다. 테이블명과 컬럼명에 네이밍 규칙도 적용한다.

개념 모델은 복잡한 현실을 단순화해 표현하지만, 필수 업무 규칙과 제약조건은 빠뜨리지 않아야 한다. 이 단계의 품질이 후속 설계 단계와 최종 시스템의 품질에 영향을 준다.