개념 설계는 업무의 대상과 관계를 잡고 논리 설계는 이를 스키마로 옮긴다. 물리 설계에서 저장과 접근 경로를 구체화한다.
요구 분석에서는 같은 책을 재대출할 수 있는지, 반납 이력을 언제까지 남길지부터 확인한다. 개념 설계에서는 책·회원·대출의 관계를 표현한다. DB 제품을 고르기 전에 업무 의미를 맞추는 단계다.
논리 설계에서는 books와 loans의 열·키·참조를 정하고 종속을 검토한다. 물리 설계에서는 자주 쓰는 조회와 데이터 규모에 맞춰 인덱스 등 접근 방법을 정한다. 실제 과정에서는 검증 결과를 보고 이전 설계로 돌아갈 수 있다.
- 01 →
요구 분석
- 02 →
개념 설계
- 03 →
논리 설계
- 04
물리 설계·구현
같은 상황에서 비교하기
| 개념 | 기준 | 확인할 점 |
|---|---|---|
| 개념 설계 | 대상·관계·제약 | ER 모델 |
| 논리 설계 | 관계·키·종속 | 관계 스키마 |
| 물리 설계 | 저장·접근 경로 | 인덱스·파티션 등 |
도서관 예제로 따라가기
“책 한 권은 여러 대출 이력을 가진다”는 업무 관계다. “loans.book_id가 books를 참조한다”는 논리 구조다. “loans(book_id)에 인덱스를 둔다”는 물리 접근 계획이다.
공통 예제 데이터 보기
| book_id | title | shelf_code | pages |
|---|---|---|---|
| 1 | SQL 입문 | DB | 120 |
| 2 | 설계 노트 | SW | 200 |
| 3 | 관계 모델 | DB | NULL |
| 4 | 분산 읽기 | NULL | 160 |
| loan_id | book_id |
|---|---|
| 11 | 1 |
| 12 | 1 |
| 13 | 2 |
내 말로 설명해 보기
books와 loans의 외래키를 정하는 것과 인덱스를 정하는 것은 어떤 차이가 있을까?
설명 예시 확인
외래키는 유효한 관계를 정하는 논리 제약이다. 인덱스는 조회·갱신 비용과 관련된 물리 접근 구조다.