[CS/데이터베이스] 데이터베이스의 기초와 설계 프로세스

선우·2025년 12월 25일

CS

목록 보기

9/20

[CS/데이터베이스] 01. 데이터베이스의 기초와 설계 프로세스

⚡ 한 줄 요약: 데이터베이스는 데이터를 체계적으로 관리하여 무결성을 유지하는 시스템이며, 효율적인 구축을 위해 개념·논리·물리적 모델링의 3단계를 거칩니다.

1. 👋 들어가며: 데이터베이스는 왜 공부해야 할까요?

우리가 다루는 데이터가 어떤 규칙으로 쌓이고 연결되는지를 이해하는 것은 매우 중요합니다.
이는 더 나은 상태 관리와 효율적인 데이터 구조 설계의 밑바탕이 되기 때문입니다.

🧐 Why:
- 엑셀과 같은 파일 기반 관리의 한계를 넘어서, 대규모 데이터를 안전하고 빠르게, 그리고 여러 명이 동시에 다루기 위해서입니다.
🎯 Goal:
- 데이터베이스의 핵심 특징을 이해하고, 아이디어를 실제 DB 테이블로 구현하기 위한 3단계 모델링 과정을 마스터합니다.

📂 2. 데이터베이스 개요

📌 2-1. 데이터베이스의 정의와 활용

데이터베이스(DB)는 단순히 데이터를 모아둔 주머니가 아닙니다.

체계적으로 정리된 데이터의 집합으로,
여러 사용자가 데이터를 효율적으로 저장, 검색, 수정, 삭제할 수 있도록 관리하는 시스템입니다.

실무에서는 이를 직접 다루기보다 데이터베이스 관리 시스템(DBMS)이라는 소프트웨어를 통해 운영하며,
무결성과 일관성을 유지하는 데 사활을 겁니다.

우리가 매일 쓰는 시스템은 이미 DB와 떼려야 뗄 수 없는 사이입니다.

카페 POS 시스템: 손님별 주문 목록이 DB에 저장되어 정산에 활용됩니다.
SNS (인스타그램): 수많은 게시물과 댓글 데이터가 DB에 쌓이고 관리됩니다.
쇼핑몰: 제품 목록, 재고 정보, 고객의 복잡한 주문 내역이 DB를 통해 관리됩니다.

📌 2-2. 데이터 vs 정보: 우리가 진짜 다루어야 할 것

많은 분이 데이터와 정보를 혼용합니다.

데이터(Data):
- 가공되지 않은 원시 값 그 자체입니다.
- 단순히 문자, 날짜, 숫자(ex. 철수, 90, 1900-01-01)를 의미합니다.
정보:
- 데이터를 가공하여 의미를 부여한 결과물입니다.
흩어져 있는 데이터를 서로 연관 짓고 의미를 부여하는 순간 비로소 '정보'가 됩니다.
예를 들어 "철수의 평균 점수는 90점이다"라는 식으로 가공되어야
우리가 비즈니스에 활용할 수 있는 가치가 생기는 것입니다.

📌 2-3. 엑셀과의 결정적 차이점

"엑셀로도 데이터 관리할 수 있는데 왜 굳이 무거운 DB를 쓰나요?"라는 질문에 대한 답입니다.

저장 단위:
- 엑셀은 파일 단위지만, DB는 테이블 단위로 데이터를 쪼개어 관리합니다.
접근 방식:
- 직접 파일을 여는 대신 SQL이라는 표준 언어를 사용하여 데이터를 제어합니다.
동시성:
- DB는 여러 사용자가 동시에 접근해서 작업해도 데이터가 꼬이지 않도록 설계되어 있습니다.
확장성:
- 대규모 데이터를 처리하는 속도 면에서 파일 기반인 엑셀과는 비교가 안 됩니다.
보안성:
- 단순 파일 암호를 넘어, 사용자별로 읽기/쓰기/수정 권한을 정교하게 설정할 수 있습니다.

📌 2-4. 헷갈리기 쉬운 포인트 / 오해 정리

데이터베이스와 DBMS는 같은 것이다?
- 데이터베이스는 데이터의 집합체이고, DBMS(MySQL, Oracle)는 그 집합체를 관리하는 소프트웨어입니다.
- 도서관(DB)와 사서(DBMS)의 관계로 이해하면 쉽습니다.

📌 2-5. 한 줄 정리

데이터베이스는 단순한 데이터(원시 값)를 SQL을 통해 유의미한 정보로 변환하고,
대규모 인원이 동시에 안전하게 공유할 수 있도록 돕는 체계적인 시스템입니다.

📂 3. 데이터베이스 특징

📌 3-1. 데이터베이스의 7가지 핵심 특성

데이터베이스는 데이터의 무결성과 일관성을 유지하기 위해 다음과 같은 성질을 반드시 가집니다.

실시간 접근성(Real-time Accessibility)
- 사용자가 원할 때 언제든지 데이터를 저장하고 조회할 수 있어야 합니다.
- 예시:
  - 쇼핑몰에서 결제 직후 내 주문 내역을 바로 확인할 수 있는 것이 실시간 접근성 덕분입니다.
동시성(Concurrency)
- 여러 사용자가 동시에 같은 데이터를 읽고 쓸 수 있는 능력입니다.
- 예시:
  - 수만 명이 이용하는 은행 앱에서 여러 사람이 동시에 각자의 계좌 잔액을 조회해도 문제없이 작동해야 합니다.
일관성(Consistency)
- 데이터는 작업 전후로 항상 모순 없는 올바른 상태를 유지해야 합니다.
- 예시:
  - 계좌 이체 중 오류가 나더라도 돈이 중간에 사라지거나 중복 송금되지 않도록 보장합니다.
무결성(Integrity)
- 데이터가 정해진 규칙에 맞게 저장되도록 보장하는 것입니다.
- 예시:
  - 회원 가입 시 중복된 이메일로 가입되지 않도록 제한을 거는 것이 무결성을 지키는 과정입니다.
데이터 중복 최소화
- 데이터를 효율적으로 저장하고 중복을 방지하여 관리 효율을 높입니다.
- 예시:
  - 회원 정보(이름, 이메일)를 한 곳에만 저장하고, 주문 내역과는 ID로 연결하여 사용합니다.
보안성
- 허가된 사용자만 데이터에 접근할 수 있도록 차단합니다.
- 예시:
  - 은행 시스템에서 타인이 아닌 오직 본인 계좌만 조회 가능하도록 권한을 설정하는 것입니다.
독립성
- 데이터와 이를 사용하는 프로그램이 분리되어 있어,
  데이터 구조가 바뀌어도 프로그램 수정 없이 사용 가능합니다.
- 예시:
  - 앱을 업데이트해도 서버의 기존 데이터는 그대로 유지되는 구조입니다.

📌 3-2. 헷갈리기 쉬운 포인트 / 오해 정리

중복 제거 vs 중복 최소화:
- DB는 중복을 100% 제거하는 것이 아니라, 관리가 가능할 정도로 최소화하는 것이 목적입니다.
- 때로는 성능을 위해 의도적으로 중복을 허용하는 경우(반정규화)도 있기 때문입니다.

📌 3-3. 한 줄 정리

데이터베이스는 실시간성, 동시성, 독립성을 바탕으로 데이터의 무결성과 일관성을 유지하며 보안을 책임지는 신뢰 기반의 관리 시스템입니다.

💡 비유로 이해하기

데이터베이스의 특성은 '잘 운영되는 대형 도서관'과 같습니다.

누구나 원할 때 책을 찾을 수 있고(실시간성), 여러 사람이 동시에 공부할 수 있으며(동시성), 책 분류 규칙이 엄격하고(무결성), 도서관 건물을 리모델링해도 책 속의 지식은 변하지 않는 것(독립성)과 같습니다.

📂 4. 데이터베이스 관리 시스템

📌 4-1. DBMS(데이터베이스 관리 시스템)의 정체

많은 분이 데이터베이스와 DBMS를 혼동하곤 합니다.
하지만 이 둘은 엄연히 역할이 다릅니다.

DBMS란?:
- 데이터베이스를 효과적으로 관리하기 위해 필요한 소프트웨어입니다.
- 데이터를 저장, 수정, 검색, 삭제하는 핵심 기능을 제공하며 MySQL, Oracle 등이 대표적입니다.
데이터베이스가 단순히 데이터를 담아두는 '그릇'이라면,
그 데이터를 제대로 꺼내고, 넣고, 바꾸고, 지우기 위해 필요한 '도구'가 바로 DBMS입니다.
그릇만 있어서도 아무것도 할 수 없기 때문에, 도구를 얼마나 잘 다루느냐가 실력의 척도가 됩니다.

📌 4-2. DBMS의 5가지 핵심 기능

DBMS는 단순히 저장만 하는 게 아니라, 백그라운드에서 정말 많은 일을 해줍니다.

데이터 저장 및 관리:
- 데이터를 테이블이라는 구조화된 형태로 저장합니다.
데이터 검색 및 수정:
- SQL을 사용해 데이터를 빠르게 찾고 변경할 수 있게 합니다.
동시성 제어:
- 여러 사용자가 동시에 같은 데이터에 접근해도 문제가 없도록 제어합니다.
보안 관리:
- 사용자별로 권한을 설정해 데이터 접근을 제한합니다.
백업 및 복구:
- 장애가 발생했을 때 데이터 손실 없이 복구할 수 있는 안전장치를 제공합니다.

📌 4-3. DBMS의 언어: SQL의 4가지 분류

우리가 DBMS에게 명령을 내릴 때 사용하는 언어인 SQL은 용도에 따라 크게 4가지로 나뉩니다.

DML (데이터 조작어): 매우 자주 사용합니다.
- 명령어: SELECT, INSERT, UPDATE, DELETE
- 용도: 데이터를 검색하고 추가, 수정, 삭제할 때 사용합니다.
DDL (데이터 정의어): 필요할 때 사용합니다.
- 명령어: CREATE, ALTER, DROP
- 용도: 테이블이나 인덱스 같은 구조를 생성하거나 수정할 때 사용하며,
  주로 초기 설계나 운영중에 가끔 사용됩니다.
DCL (데이터 제어어): 일반 개발자는 거의 안 씁니다.
- 명령어: GRANT, REVOKE
- 용도: DB 관리자(DBA)가 보안을 위해 사용자 권한을 관리할 때 사용합니다.
TCL (트랜잭션 제어어): 특정 작업(금융, 결제 등)에서 필수입니다.
- 명령어: COMMIT, ROLLBACK, SAVEPOINT
- 용도: 여러 변경 작업을 하나의 단위로 묶어 확정하거나 취소할 때 사용합니다.

📌 4-4. 헷갈리기 쉬운 포인트 / 오해 정리

SQL은 다 똑같은 거 아닌가요?
- DELETE는 DML이지만, 테이블 자체를 날려버리는 DROP은 DDL입니다.

📌 4-5. 한 줄 정리

DBMS는 데이터라는 그릇을 다루기 위한 필수 도구이며, 우리는 DML(조작), DDL(정의), DCL(제어), TCL(트랜잭션)이라는 4가지 SQL 언어를 통해 이 도구를 제어합니다.

💻 참고

실무에서는 DML 실력은 기본이고, 결제 시스템처럼 중요한 로직을 다룰 때는 TCL을 얼마나 정확하게 이해하고 쓰느냐가 시니어와 주니어를 가르는 기준이 됩니다.

📂 5. 관계형 데이터베이스

📌 5-1. 관계형 데이터베이스(RDBMS)의 정의와 특징

DBMS의 여러 종류 중 실무에서 가장 많이 사용하게 되는 것이 바로
RDBMS(Relational Database Management System)입니다.

핵심 개념:
- 데이터를 테이블 형태로 저장하고, 테이블 간의 관계를 이용하여 데이터를 관리하는 시스템입니다.
도구와 방식:
- 표준 언어인 SQL을 사용해 데이터를 조회하고 수정하며, 테이블 간 연결을 통해 데이터의 중복을 최소화하는 것이 가장 큰 특징입니다.
대표 제품:
- 우리가 흔히 듣는 MySQL, PostgreSQL, Oracle, SQL Server 등이 여기에 속합니다.

📌 5-2. 테이블 간의 관계 표현

RDBMS의 정수는 '관계'에 있습니다. 데이터들이 어떻게 서로 얽혀 있는지에 따라 4가지 모델로 나뉩니다.

일대일 (1:1):
- 한 행이 다른 테이블의 딱 한 행과만 연결됩니다.
- 자주 쓰이진 않지만, 보안이 중요하거나 별도 관리가 필요한 데이터에 활용합니다.
일대다 (1:N):
- 한 개의 행이 다른 테이블의 여러 행과 연결될 수 있는 구조입니다.
- 예시:
  - 1명의 고객이 여러 번의 주문을 하는 '고객과 주문' 관계가 대표적입니다.

다대일 (N:1):
- 여러 행이 다른 테이블의 한 행과 연결되는 경우입니다.
- 예시:
  - 여러 명의 직원이 1개의 부서에 소속된 '직원과 부서' 관계입니다.
다대다 (N:M):
- 양쪽 모두 여러 개의 데이터와 연결될 수 있는 가장 복잡한 구조입니다.
- 예시:
  - 학생은 여러 강의를 듣고, 한 강의에는 여러 학생이 있는 '학생과 강의' 관계입니다.

📌 5-3. 헷갈리기 쉬운 포인트 / 오해 정리

1:N과 N:1은 다른 것인가요?
- 관계의 방향 차이일 뿐입니다.
  고객 입장에서 주문을 보면 1:N이지만, 주문 입장에서 보면 N:1입니다.
- 어느 테이블을 기준으로 설명하느냐의 차이일 뿐 본질은 같습니다.

📌 5-4. 한 줄 정리

RDBMS는 데이터를 테이블로 구조화하고 SQL과 관계(1:1, 1:N, N:M)를 활용해 데이터 중복을 방지하며 무결성을 유지하는 가장 대중적인 데이터베이스 시스템입니다.

💻 참고

프론트엔드 실무에서도 Redux나 TanStack Query 같은 상태 관리 라이브러리를 쓸 때 데이터를 '정규화'해서 저장하라는 조언을 많이 듣게 될 겁니다.

서버 DB의 RDBMS 구조를 이해하면 클라이언트 단의 복잡한 객체 데이터를 어떻게 효율적으로 쪼개고 연결할지에 대한 설계 능력이 비약적으로 상승합니다.

📂 6. 데이터베이스 모델링

📌 6-1. 데이터베이스 모델링: 설계의 3단계

데이터베이스 모델링은 실제 데이터베이스를 만들기 전에 그 구조를 설계하는 과정으로,
크게 3단계로 진행됩니다.

1단계 - 개념적 모델링:
- 무엇을 저장할지 정리하고, 데이터 구조를 간단한 개념(개체, 관계)으로 표현하는 단계입니다.
2단계 - 논리적 모델링:
- 개념적 모델링을 기반으로 릴레이션 스키마 형태로 구체화하며, 정규화를 적용합니다.
3단계 - 물리적 모델링:
- 실제 DBMS에 맞게 데이터 타입, 인덱스 등을 설정하여 적용하는 단계입니다.

📌 6-2. 개념적 모델링과 ERD(Entity-Relationship Diagram)

개념적 모델링은 우리가 만들고자 하는 서비스를 실제 구현하기 위해
어떤 데이터가 필요할지 정리하고, 그 데이터들을 담기 위한 구조를 잡아보는 단계입니다.

본격적인 모델링 시작 전, 머릿속에만 들어있는 파편화된 내용들을 도형과 선을 통해 그림으로 정리해보는 과정이라 이해하면 쉽습니다.

이때 가장 많이 사용하는 도구가 바로 ERD입니다.

ERD의 주요 구성 요소는 다음과 같습니다:

개체(Entity):
- 저장할 데이터의 유형으로, 문장에서 명사에 해당합니다. (기호: 사각형)
관계(Relationship):
- 개체 간의 연결로, 문장에서 동사에 해당합니다. (기호: 마름모)
속성(Attribute):
- 개체의 특징(이름, 나이 등)을 나타냅니다. (기호: 타원)
기본 키(Primary Key):
- 개체를 유일하게 식별하는 유일한 식별자입니다. (기호: 밑줄 표시)

📌 6-3. 식별자(ID)가 필요한 이유

우리가 개체의 특징 중 하나인 '이름'같은 속성만으로 데이터를 관리하려고 하면,
동명이인 같은 사례 때문에 특정한 개체를 유일하게 식별하기 어려워집니다.

그래서 특정한 개체를 명확히 구분하기 위한 식별자가 반드시 필요하며, 보통 ID를 사용하게 됩니다.

ERD에서는 이 식별자 아래에 밑줄을 그어 표현합니다.

📌 6-4. 실전 ERD 예시: 고객, 주문, 상품

실제 서비스에서 개체 간의 관계가 어떻게 설정되는지 살펴보겠습니다.

고객과 주문 (1:N 관계):
- 한 명의 고객은 여러 개의 주문을 할 수 있습니다.
주문과 상품 (N:M 관계):
- 한 개의 주문에는 여러 개의 상품이 들어갈 수 있고, 반대로 하나의 상품 역시 여러 개의 주문에 속할 수 있습니다.

📌 6-5. 헷갈리기 쉬운 포인트 / 오해 정리

개체(Entity) vs 속성(Attribute)
- 개체는 관리해야 할 '대상' 그 자체(예: 고객)이고, 속성은 그 대상을 설명하는 '정보'(예: 고객명, 이메일)입니다.

📌 6-6. 한 줄 정리

개념적 모델링은 ERD를 통해 머릿속의 데이터 구조를 명사(개체)와 동사(관계)로 시각화하고,
유일한 식별자(ID)를 확정하는 설계의 첫 단계입니다.

📂 7. 논리적 모델링

📌 7-1. 논리적 모델링: 구조를 구체화하는 단계

개념적 모델링에서 큰 그림을 그렸다면, 이제는 DBMS가 이해할 수 있는 구체적인 설계도로 옮겨야 합니다.
이 단계를 논리적 모델링이라고 합니다.

용어의 변화:
- 이 단계부터는 테이블을 릴레이션이라 부르고, 이 릴레이션의 속성(컬럼)들을 나열한 것을 릴레이션 스키마라고 부릅니다.

핵심 작업:
- 각 테이블의 속성을 설정하고, 행을 식별할 기본 키(PK)와 테이블 간을 잇는 외래 키(FK)를 정의하여 데이터 중복을 최소화하는 정규화를 적용합니다.

📌 7-2. 키(Key)의 정의와 식별의 원칙

키는 테이블의 각 행을 고유하게 식별하는 아주 중요한 역할을 합니다.
단순히 데이터를 찾는 도구가 아니라, 데이터의 유일성을 보장하는 안전장치입니다.

키가 되기 위해서는 두 가지 성질을 반드시 만족해야 합니다.

유일성(Uniqueness):
- 특정 키 값은 테이블 내에서 절대 중복될 수 없습니다.
최소성(Minimality):
- 식별하는 데 꼭 필요한 최소한의 속성으로만 구성되어야 합니다.
- 키는 반드시 하나의 속성으로만 표현되는 것은 아닙니다.
- ID와 이름을 묶어서 키로 설정할 수도 있지만, ID만으로도 식별이 충분한 상황이라면, 굳이 이름을 묶어 키로 설정할 필요가 없습니다.
- 이것이 바로 불필요한 속성을 걷어내는 '최소성'의 원칙입니다.

📌 7-3. 반드시 알아야 할 키의 종류

기본 키(PK, Primary Key): 행을 유일하게 식별하는 '대표'키입니다.
외래 키(FK, Foreign Key): 다른 테이블의 기본 키를 참조하는 키입니다.
- 고객과 주문 테이블 사이처럼 1:N 관계를 형성할 때는 반드시 두 테이블을 잇는 '연결고리'가 필요합니다.
- 이때 N(주문) 쪽 테이블이 1(고객) 쪽의 기본 키를 '외래키'로 갖게 됩니다.
- 이 FK가 있어야 나중에 두 테이블을 조합(Join)하여 유의미한 정보를 뽑아낼 수 있습니다.
후보 키(Candidate Key):
- 기본 키가 될 자격이 있는 후보군(유일성+최소성 만족)입니다.
대체 키(Alternate Key):
- 후보 키 중 기본 키로 선택되지 않은 나머지 키들입니다.
슈퍼 키(Super Key):
- 유일성을 가지지만 최소성은 고려하지 않은 속성들의 조합입니다.

📌 7-4. 다대다(N:M) 관계와 중간 테이블의 마법

데이터베이스의 물리적인 테이블 구조에서는 다대다 관계를 직접적으로 표현할 수 없습니다.
그래서 우리는 중간 테이블(Mapping Table)이라는 매개체를 도입하여 이 문제를 해결합니다.

구조의 변환:
- 기존의 N:M 관계를 '다대일(N:1) - 일대다(1:N)' 관계로 쪼개어 변환합니다.
매개체 역할:
- '주문-상품'과 같은 중간 테이블이 매개체가 되어,
  서로 직접 연결될 수 없는 '주문' 테이블과 '상품' 테이블을 유연하게 연결해 줍니다.

📌 7-5. 데이터를 찾는 로직: 외래 키(FK) 활용법

중간 테이블을 두면 양방향 조회가 매우 명확해집니다.

특정 주문에 포함된 모든 상품을 찾고 싶을 때:
- 중간 테이블은 주문 ID를 외래 키(FK)로 들고 있습니다.
- 따라서 주문 ID로 필터링을 하게 되면, 그 주문 한 건에 묶인 모든 상품 리스트를 단번에 뽑아낼 수 있습니다.
특정 상품이 어떤 주문들에 들어있는지 궁금할 때:
- 중간 테이블은 상품 ID 역시 외래 키(FK)로 관리합니다.
- 상품 ID로 필터링만 하면, 해당 상품이 포함된 모든 주문 내역을 추적할 수 있습니다.

📌 7-6. 헷갈리기 쉬운 포인트 / 오해 정리

외래 키는 항상 유일해야 하나요?
- 아닙니다. 1:N 관계에서 'N'쪽에 들어가는 외래 키는 중복될 수 있습니다.
  한 고객(1)이 여러 개의 주문(N)을 할 수 있기 때문에, 주문 테이블의 '고객 ID' 컬럼에는 같은 고객 번호가 여러 번 등장하는 것이 정상입니다.
중간 테이블은 데이터만 쌓이고 쓸모없는 테이블 아닌가요?
- 아닙니다. 중간 테이블은 두 실체의 '관계' 자체가 데이터가 되는 곳입니다.
  언제(주문 시각), 어떤 가격(주문 시점의 가격)으로 팔렸는지 같은 '관계 속성'을 저장하는 아주 중요한 공간입니다.

📌 7-7. 한 줄 정리

키는 데이터의 유일성을 보장하는 식별자이며, 특히 외래 키는 1:N 관계의 N쪽 테이블에서 1쪽의 PK를 참조하여 데이터 사이의 필수적인 연결고리 역할을 수행합니다.

📂 8. 물리적 모델링

📌 8-1. 물리적 모델링: 실체를 만드는 단계

물리적 모델링은 실제 데이터베이스를 만들기 위한 3단계 중 최종 단계로,
논리적 모델을 실제 데이터베이스에 적용하는 과정입니다.

주요 작업:
- 선택한 DBMS에 최적화된 데이터 타입(INT, VARCHAR 등), 인덱스, 그리고 데이터의 정합성을 지켜줄 제약 조건을 설정합니다.

💻 참고

아무리 논리적 구조가 완벽해도 물리적 모델링에서 데이터 타입을 잘못 선택하면 성능 저하나 데이터 손실이 발생할 수 있습니다. 즉, 설계라는 추상을 코드로 구현하는 '현실화' 단계라고 이해하면 됩니다.

📌 8-2. 코드로 보는 물리적 모델링 예시

사용자(users) 테이블 생성

CREATE TABLE users (
    id INT PRIMARY KEY,               -- 기본 키 (각 사용자를 유일하게 식별) 
    name VARCHAR(50),                 -- 이름 저장
    email VARCHAR(100) UNIQUE         -- 중복을 허용하지 않는 고유 값
);

주문(orders) 테이블 생성

CREATE TABLE orders (
    id INT PRIMARY KEY,               -- 기본 키 (각 주문을 유일하게 식별)
    user_id INT,                      -- 주문한 사용자 ID 
    order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, -- 주문 시각 (기본값 설정) 
    FOREIGN KEY (user_id) REFERENCES users(id)      -- 외래 키 설정
);

📌 8-3. 헷갈리기 쉬운 포인트 / 오해 정리

물리적 모델링은 단순히 SQL문을 작성하는 과정이다?
- 단순 작성이 아니라, 성능 향상을 위한 인덱스 전략과 데이터의 성격에 맞는 최적의 데이터 타입을 결정하는 고도의 엔지니어링 과정입니다.

📌 8-4. 한 줄 정리

물리적 모델링은 논리적 구조를 실제 DBMS의 환경에 맞춰 데이터 타입과 제약 조건을 정의하여 데이터베이스의 실체를 구현하는 최종 단계입니다.

🎁 9. 정리

🔑 요약

데이터베이스 VS DBMS
- DB가 데이터라는 '원석'을 모아둔 창고라면, DBMS는 그 원석을 가공해 정보로 만드는 '관리 도구'입니다.
RDBMS의 정수, '관계'
- 테이블 간의 관계(1:1, 1:N, N:M)를 설정함으로써 데이터 중복을 최소화하고 일관성을 유지합니다.
- 특히 복잡한 N:M 관계는 '중간 테이블'을 통해 해결한다는 점이 핵심입니다.
설계의 3단계
- 개념적 모델링: ERD를 통해 머릿속 아이디어를 시각화
- 논리적 모델링: PK와 FK를 정의하고 정규화를 통해 논리적 구조 확립
- 물리적 모델링: 특정 DBMS에 맞춰 데이터 타입과 제약 조건을 설정하여 실제 테이블 생성

선우

이전 포스트

[CS/네트워크] 네트워크 보안과 실무 인프라

다음 포스트