모델링은 현실 세계의 사물, 개념, 과정 등을 단순화하여 표현한 추상적 구조를 만드는 행위이다.
복잡한 시스템을 이해·분석·설계하기 위해 필요한 핵심 요소와 관계를 시각적으로 표현하는 과정이다.
현실 세계에 활용되는 데이터를 컴퓨터 공간에서 활용하기 위해 목적에 필요한 데이터를 찾아 논리적인 데이터의 구조로 설계하는 기법 (현실을 데이터로 추상화 하는 기법)
데이터의 개체(Entity), 속성(Attribute), 관계(Relationship)를 정의하고, 이를 통해 논리적·물리적 데이터베이스 스키마로 변환하는 활동이다.
데이터베이스 설계는 데이터의 중복과 불일치 방지, 정합성과 일관성 보장을 통해 신뢰성 있는 시스템을 구축하기 위해 중요하다. 또한 체계적인 구조를 마련하여 효율적인 데이터 접근과 관리를 가능하게 함으로써 운영 및 확장성을 높인다.
| 구분 | 설명 |
|---|---|
| 데이터 중복과 불일치 방지 | 동일 데이터가 여러 곳에 중복 저장되는 것을 방지하여 저장 공간 낭비와 값 불일치 문제를 최소화함 |
| 데이터 정합성과 일관성 보장 | 데이터가 정의된 규칙과 제약조건(참조 무결성, 도메인 제약 등)을 만족하여 신뢰성 있는 값을 유지하도록 함 |
| 효율적인 데이터 접근과 관리 | 체계적인 스키마와 인덱스, 정규화 설계를 통해 빠른 검색·갱신이 가능하며, 관리 및 확장이 용이한 구조 제공 |

사용자 요구사항 및 업무 규칙을 수집·분석하여 데이터 요구 사항을 정의
요구분석 단계에서 정의된 핵심 개체와 그들 간의 관계를 바탕으로 ERD를 생성하는 단계
개념 설계에서 추상화된 데이터를 구체화하여 개체, 속성을 테이블화하고 상세화 하는 과정
논리적 설계 단계에서 표현된 데이터(ERD)를 실제 컴퓨터의 저장장치에 어떻게 표현할 것인가 (관계형 데이터베이스로 전환)
| 단계 | 주요 산출물 | 개념 |
|---|---|---|
| 요구사항 분석 | 요구사항 정의서 (Requirement Specification) | 사용자 및 시스템 요구사항을 정리한 문서로, 데이터 및 기능적 요구를 상세히 기술 |
| 개념적 모델링 | ERD (Entity-Relationship Diagram) | 개체(Entity), 속성(Attribute), 관계(Relationship)를 도식화하여 데이터 구조를 시각적으로 표현 |
| 논리적 모델링 | 논리 데이터 모델 (Logical Data Model) | 정규화된 스키마, 키 정의, 제약조건 등 DBMS에 독립적인 논리적 구조를 설계 |
| 물리적 모델링 | 물리 데이터 모델 & DDL (Physical Data Model & DDL) | 선택된 DBMS(PostgreSQL 등)에 맞게 테이블, 인덱스, 파티션 등을 정의하고 이를 SQL DDL로 구현 |
업무의 관심 대상이 되는 정보를 갖고 있거나 그에 대한 정보를 관리할 필요가 있는 유형, 무형의 사물(개체) (유형, 무형, 문서, 이력, 코드)
엔티티에서 관리해야 할 최소 단위 정보 항목(관심이 있는 항목)을 말하며 엔티티는 하나 이상의 속성을 포함 (기본, 유도, 설계)
엔티티의 속성으로 실제로 구현된 하나의 값
두 개 이상의 개체(Entity) 간의 연관성을 정의
엔티티 내 각 인스턴스를 구별하는 기준이 되는 속성
관계가 있는 엔티티 간의 연결고리 역할을 하는 속성
요구사항 명세는 사용자가 원하는 기능과 제약조건을 체계적으로 문서화한 결과물이다. 시스템이 수행해야 할 기능적 요구와 성능, 보안, 제약조건과 같은 비기능적 요구를 모두 포함한다.
데이터베이스 설계의 입력 자료로 활용되어 이후 개념적·논리적 모델링의 기준이 된다.
비즈니스 요구사항 분석은 사용자가 필요로 하는 기능, 데이터, 제약조건을 체계적으로 도출하여 시스템 개발의 기준을 마련하는 과정이다. 업무 절차와 규칙을 정리하여 이후 데이터베이스 설계와 시스템 구현의 입력 자료로 활용된다.
| 구분 | 개념 |
|---|---|
| 기능적 요구사항 식별 | 비즈니스가 달성해야 할 구체적인 서비스와 기능을 정의하는 단계로, 사용자가 기대하는 주요 업무 절차를 도출함. 예: 회원가입, 주문 처리, 결제 승인, 보고서 출력 |
| 데이터 관련 요구사항 도출 | 비즈니스 활동을 지원하기 위해 필요한 데이터의 종류, 속성, 형식, 발생 주기 및 보관 정책을 식별함. 예: 고객 정보, 주문 내역, 제품 재고, 로그 데이터 |
| 제약조건 파악 | 시스템 설계 및 운영 과정에서 반드시 준수해야 하는 한계와 조건을 명확히 정의함. 예: 성능(응답시간 2초 이내), 보안(암호화, 접근 제어), 법규(개인정보보호법 준수), 예산·기간 제한 |
데이터 사전(Data Dictionary)은 데이터베이스에 저장될 데이터의 이름, 유형, 길이, 의미, 제약조건 등 을 체계적으로 정리한 메타데이터 집합이다.
시스템 전반에서 사용하는 데이터의 표준화와 일관성을 보장하기 위해 작성된다.
| 필요성 | 설명 |
|---|---|
| 용어 정의와 표준화 | 데이터 항목의 명칭과 의미를 일관성 있게 정의하여 혼용과 혼란을 방지 |
| 데이터 항목 식별 | 시스템에서 사용되는 모든 데이터 요소를 목록화하고 속성을 식별 |
| 데이터 형식과 규칙 정의 | 데이터의 유형, 길이, 기본값, 제약조건 등 형식과 관리 규칙을 명확히 규정 |
업무 분석 단계 이후, 분석 자료(업무 기술서, 인터뷰 자료, 장부와 전표 등)로부터 엔티티 도출
정해진 공식은 없으나 경험이 없으면 다음의 과정들을 거쳐서 엔티티 기술서 작성
요구분석사항에서 얻은 엔티티와 속성들을 실제 테이블과 테이블 간의 관계를 설계하기 위해 정해진 작도법을 통해 시각화 하여 표현하는 모델링 기법
ERD의 표기법은 전통적(학문적)으로 피터첸 표기법을 사용하였으나 이는 다수의 테이블과 컬럼 값을 설계하기 어려웠고, 현대(현업)에서는 Crow-feet 표기법을 통해 주로 ERD을 설계하고 있다.

X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속하는 한 개체도 X에 속하는 한 개체에만 연결될 때
X에 속하는 한 개체는 Y에 속하는 여러 개체에만 연결되며, Y에 속하는 한 개체는 X에 속하는 한 개체와 연결될 때
논리적 모델링(Logical Modeling)은 개념적 데이터 모델을 기반으로 특정 DBMS에 독립적인 논리적 구조를 설계하는 과정이다. 정규화, 키 정의, 제약조건 등을 통해 데이터 간 관계와 구조를 체계화한다.이 단계에서 생성된 논리 데이터 모델은 이후 물리적 모델링으로 전환되어 실제 DB 구현을 수행한다.
속성 정의와 설계는 데이터베이스 내 각 데이터 요소의 의미, 형식, 제약조건을 명확히 규정하는 과정이다.
이를 통해 데이터의 정합성과 일관성을 확보하고 효율적인 관리가 가능해진다.
| 구분 | 개념 |
|---|---|
| 속성의 기본 특성 | 속성명, 데이터 타입, 길이, 기본값 등 기본적인 정의 요소 |
| 속성의 도메인 정의 | 속성이 가질 수 있는 값의 범위와 규칙을 지정 (예: 성별=‘M’, ‘F’) |
| 속성의 널 허용 여부 | 해당 속성 값이 반드시 존재해야 하는지 여부를 지정 (NOT NULL 제약 등) |
식별자 설계는 엔터티를 고유하게 구분할 수 있도록 키(Key)를 정의하고, 데이터의 정합성과 무결성을 유지하기 위해 설계하는 과정이다. 즉, 데이터베이스에서 각 레코드를 유일하게 식별하기 위한 기준을 마련하는 단계이다.
| 키의 종류 | 설명 |
|---|---|
| 슈퍼키 (Super key) | 한 엔터티에서 각 튜플을 유일하게 식별할 수 있는 속성들의 집합 |
| 후보키 (Candidate key) | 슈퍼키 중에서 불필요한 속성을 제외한 최소한의 속성 집합 |
| 기본키 (Primary key) | 후보키 중에서 대표로 선택된 키, NULL 불가 및 중복 불가 |
| 대체키 (Alternate key) | 기본키로 선택되지 않은 나머지 후보키, 필요 시 보조 식별자로 사용 |
DB에서 데이터의 중복을 제거하고,데이터 간의 종속성을 명확히 하여 구조를 체계적으로 분해하는 과정
| 단계 | 이름 | 개념 | 목적/효과 |
|---|---|---|---|
| 1NF | 제1정규형 (First Normal Form) | 모든 속성이 원자값(Atomic Value) 으로만 구성되도록 테이블을 설계 | 반복/중첩 컬럼 제거, 다중값 → 별도 행으로 분리 |
| 2NF | 제2정규형 (Second Normal Form) | 1NF 만족 + 부분 함수 종속 제거 (복합키의 일부에만 종속된 속성을 분리) | 기본키 전체에 종속되도록 하여 중복 제거 |
| 3NF | 제3정규형 (Third Normal Form) | 2NF 만족 + 이행 함수 종속 제거 (A→B, B→C일 때 A→C 종속 제거) | 비키 속성 간 종속 제거 → 데이터 일관성 강화 |
| BCNF | 보이스-코드 정규형 (Boyce–Codd Normal Form) | 3NF 만족 + 모든 결정자가 후보키가 되도록 분해 | 이상현상(Anomaly) 추가 제거, 더 엄격한 무결성 |
| 4NF | 제4정규형 (Fourth Normal Form) | BCNF 만족 + 다치 종속(Multi-valued Dependency) 제거 | 하나의 키에 대해 여러 독립적인 다치 속성을 분리 |
| 5NF | 제5정규형 (Fifth Normal Form, PJ/NF) | 4NF 만족 + 조인 종속(Join Dependency) 제거 | 불필요한 조인으로 인한 데이터 중복 제거 |
정규화 되지 않은 테이블에서 데이터를 삽입, 갱신, 삭제를 수행하다 발생하는 논리적 오류
이에 따라 무결성 원칙 위배, 일관성을 지켜지지 않고 데이터의 중복이 발생한다.
불필요한 정보를 함께 저장하지 않고는 어떤 정보를 저장하는 것이 불가능
반복된 데이터 중에 일부만 수정하면 중복된 다른 데이터의 불일치가 발생
필수적인 정보를 함께 삭제하지 않고는 어떤 정보를 삭제하는 것이 불가능
논리적 설계의 산출물인 ERD를 기반으로 DBMS의 구조와 성능을 고려해 실제 저장 구조로 구현하는 설계 단계
| 논리적 DB 설계 (데이터 모델링) | 물리적 DB 설계 |
|---|---|
| DBMS의 종류/제품에 상관 없이 진행 (ERD는 어떤 데이터베이스를 사용해도 적용가능) | 특정 DBMS를 전제로 진행 (적용 DBMS의 특성을 고려) |
테이블 설계는 현실 세계의 개체와 속성을 데이터베이스 구조로 변환하여 테이블과 컬럼으로 정의하는 과정이다. 각 컬럼의 데이터 타입, 제약조건, 키를 명확히 설정하여 데이터 무결성과 효율적인 관리가 가능하도록 한다. 이를 통해 데이터 간 관계를 반영하고 향후 확장성과 성능까지 고려한 최적의 스키마를 구축한다.
컬럼 데이터 타입 선정은 각 컬럼이 저장할 데이터의 성격과 범위에 맞는 적절한 타입을 지정하는 과정이다. 이를 통해 저장 공간을 효율적으로 사용하고, 데이터 무결성과 처리 성능을 보장한다.
| 분류 | 데이터 타입 | 설명 |
|---|---|---|
| 정수형 (Integer Types) | SMALLINT (2바이트)INTEGER (4바이트)BIGINT (8바이트) | 정수 값 저장 |
| 숫자형 (Numeric Types) | NUMERIC(p,s), DECIMAL(p,s) | 고정 소수점, 정확한 계산 가능 (금융 계산 등에 적합) |
REAL, DOUBLE PRECISION | 부동 소수점, 근사치 계산 (과학/통계 연산 등에 적합) | |
| 문자형 (Character Types) | CHAR(n) | 고정 길이 문자 |
VARCHAR(n) | 가변 길이 문자 (길이 제한 있음) | |
TEXT | 가변 길이 문자 (제한 없음) | |
| 날짜/시간형 (Date/Time Types) | DATE | 날짜 (YYYY-MM-DD) |
TIME | 시간 (HH\:MI\:SS) | |
TIMESTAMP | 날짜 + 시간 | |
INTERVAL | 기간, 시간 간격 | |
| 불리언 (Boolean) | BOOLEAN | TRUE, FALSE, NULL |
| 자동 증가 타입 (Serial Types) | SERIAL, BIGSERIAL | 자동 증가 정수 (주로 PK에 사용) |
| 고유/확장 타입 (PostgreSQL 전용) | JSON, JSONB | JSON 데이터 저장 및 처리 |
ARRAY | 배열 형태 데이터 저장 | |
UUID | 범용 고유 식별자 (Primary Key에 자주 사용) |
컬럼 제약 조건(Column Constraints)은 데이터 무결성과 일관성을 보장하기 위해 각 컬럼에 대해 값의 범위, 유일성, 참조 관계 등을 정의하는 규칙이다.
이를 통해 데이터 입력 시 오류를 예방하고 데이터베이스의 신뢰성을 확보한다.
| 구분 | 설명 | 쿼리 명령 |
|---|---|---|
| 기본값과 제약조건 설정 | 컬럼 값이 입력되지 않을 경우 기본값 지정 및 NULL 허용 여부 설정 | DEFAULT, NOT NULL |
| 기본키 (Primary Key) 구현 전략 | 테이블 내 레코드를 고유하게 식별하는 키, NULL 및 중복 불가 | PRIMARY KEY |
| 외래키 제약조건 (Foreign Key) | 다른 테이블의 기본키를 참조하여 데이터 참조 무결성 보장 | FOREIGN KEY |
| 고유키 제약조건 (Unique Key) | 특정 컬럼 값의 중복을 허용하지 않도록 정의 (단, NULL은 허용 가능) | UNIQUE |
참조 무결성 규칙은 외래키 제약조건에서 부모 테이블의 데이터 변경이나 삭제가 발생했을 때, 자식 테이블의 데이터를 어떻게 처리할지 정의하는 규칙이다.
| 옵션 | 개념 | 실제 제약 문장 예시 |
|---|---|---|
| CASCADE | 부모 데이터가 변경·삭제되면 자식 데이터도 함께 변경·삭제됨 | FOREIGN KEY (dept_id) REFERENCES department(dept_id) ON DELETE CASCADE |
| SET NULL | 부모 데이터가 삭제되면 자식의 외래키 값을 NULL로 설정 | FOREIGN KEY (dept_id) REFERENCES department(dept_id) ON DELETE SET NULL |
| RESTRICT | 자식 데이터가 존재할 경우 부모 데이터의 변경·삭제를 제한 | FOREIGN KEY (dept_id) REFERENCES department(dept_id) ON DELETE RESTRICT |
인덱스(Index)는 데이터 검색 성능을 향상시키기 위해 특정 컬럼의 값을 기준으로 정렬된 별도의 자료구조(B-Tree, Hash 등)를 생성하는 객체이다.
종류로는 B-Tree 인덱스, Hash 인덱스, GiST/GIN 인덱스, 비트맵 인덱스 등이 있다.
| 원칙 | 설명 |
|---|---|
| 선택도가 높은 컬럼 우선 | 중복이 적고 카디널리티가 높은 컬럼에 인덱스를 적용 |
| 조회/조인/정렬 기준 활용 | WHERE, JOIN, ORDER BY, GROUP BY에서 자주 쓰이는 컬럼 중심으로 설계 |
| 과도한 인덱스 지양 | 불필요한 다중 인덱스는 갱신 부하와 저장 공간 낭비를 초래하므로 최소화 |
| 기준 | 설명 |
|---|---|
| WHERE 절 조건 컬럼 | 자주 필터링되는 컬럼에 인덱스 적용 |
| JOIN 키 컬럼 | 테이블 결합에 사용되는 컬럼에 인덱스 부여 |
| ORDER BY / GROUP BY | 대상 정렬·집계 대상 컬럼에 인덱스를 적용하여 처리 효율 향상 |
데이터 모델 검증은 설계된 데이터 모델이 요구사항을 정확히 반영하고, 무결성과 일관성을 유지할 수 있는지 확인하는 과정이다. 엔터티, 속성, 관계, 제약조건이 적절히 정의되었는지를 점검하며, 이 상현상 발생 가능성을 사전에 제거한다.
이를 통해 데이터베이스 구현 시 오류를 최소화하고 성능과 확장성을 보장한다.
| 사례 | 개념 | 설명 |
|---|---|---|
| 부적절한 기본키 선정 | 가변적 값 사용 | 주민번호, 전화번호 등 변경 가능성이 있는 속성을 기본키로 사용하면 무결성과 안정성이 깨짐 |
| 잘못된 일대다 관계 설정 | 관계 오류 | 부모-자식 관계를 잘못 정의하면 데이터 중복, 삭제/갱신 이상(Anomaly) 발생 |
| 순환 참조 구조 | 상호 참조 문제 | 테이블 간 외래키가 서로를 참조하는 순환 구조가 생기면 데이터 입력·삭제 제약과 복잡성이 증가 |
성능 관련 검증은 데이터베이스 설계와 구현이 실제 운영 환경에서 요구되는 성능 목표를 충족하는지 점검하는 과정이다. 인덱스, 조인, 쿼리 실행 계획 등을 검토하여 응답 시간과 처리 효율성을 확인한다.
이를 통해 병목 지점을 사전에 발견하고 최적화 방안을 마련할 수 있다.
| 사례 | 설명 |
|---|---|
| 과도한 인덱스 생성 | 불필요한 인덱스가 많으면 쓰기(INSERT/UPDATE/DELETE) 시 성능 저하와 저장 공간 낭비 발생 |
| 비효율적인 조인 구조 | 잘못된 조인 순서·조건으로 인해 불필요한 연산이 늘어나 쿼리 성능 저하 초래 |
| 부적절한 데이터 타입 선택 | 데이터 크기·형식에 맞지 않는 타입 사용으로 저장 공간 낭비 및 연산 성능 저하 발생 |