안녕하세요. CS지식 정리도 할 겸, 학교에서 배운 데이터베이스 개념 + "데이터베이스 개론-IT COOKBOOK" 의 내용을 정리할 것입니다. 지난 포스트 "Database의 View에 관한 개념"에 이어 이번에는 데이터베이스의 설계( 요구사항 분석 -> 개념적 -> 논리적 -> 물리적 설계에 관한 개념을 정리하려고 합니다.
데이터베이스 설계
Db에서 원하는 데이터를 얻기 위해서는 특정 테이블이 필요합니다. 테이블의 열은 PK, FK, 후보키 등 다양한 속성으로 정의되어 있습니다. FK를 통해 다른 테이블의 PK와 연결됩니다. 이런 테이블의 속성들은 relational schema를 기반으로 만들어집니다. relational schema는 Entity-Relationship model로부터 정의됩니다.
즉 데이터베이스를 구성하기 위해선 요구사항을 분석한 후에 명세서를 기반으로 개념적 설계 -> 논리적 설계 .. 의 과정을 거쳐야 합니다.
- 요구 사항 분석
- 개념적 설계
- 논리적 설계
- 물리적 설계
- 구현
1단계. 요구 사항 분석
서비스에 핵심적인 데이터 이외의 데이터가 추가되는 것은 저장공간 낭비, 성능저하, 유지보수 어려움 등 비 효율적입니다. 그래서 사용자가 실제로 사용하는, 서비스에서 사용되는 데이터가 무엇인지 요구 사항을 분석하고 명세서를 만들어야 합니다. ( 데이터 모델링 때 요구사항 분석 관련 개념을 봤는데 정말 해야할게 많던데,,)
그 예로 인터넷으로 회원들에게 상품 판매하는 한빛마트를 위한 db를 만든다고 가정한다면
(사진: 데이터베이스 개론 2판 | 김연희 지은이)
위와 같은 요구사항을 도출할 수 있습니다.
이전 포스트 데이터 모델링 개념정리를 하면서 개념적 설계, 논리적 설계에 필요한 개념들을 다뤘었습니다.
2단계. 개념적 설계(개념적 모델링)
저장할 가치 있는 주요 데이터를 개체로 분류하거나 서비스와 관련 있는 핵심 명사 찾기.. 명사들 중에서 개체와 속성을 분류합니다.
사용자 요구사항에 대한 분석 결과를 바탕으로 Entity(개체)와 Entity간 Relationship(관계)를 결정해야 합니다. Entity는 하나의 Attribute(속성)을 가질 수 있고 이런 속성들로 Entity가 표현됩니다.
사용자의 요구 사항을 개념적 데이터 모델로 변환하는 작업은 개념적 데이터 모델링입니다. 개념적 데이터 모델은 E-R model이 대표적으로 있습니다. 이를 기반으로 E-R Diagram을 그려 한 눈에 파악할 수 있습니다.
위 사진1의 명세서를 통해
Entity와 attributes, relationship 파악
1.2.3에서 회원 entity와 속성들(attributes)을 파악할 수 있습니다.
4,5에서 상품 entity와 attributes를 파악할 수 있습니다.
6에서 회원 entity와 상품 entity의 relationship를 파악할 수 있습니다.
7에서 파악한 relationship으로부터 추가적인 attributes를 파악할 수 있습니다.
8,9에서 상품 entity와 제조업체 entity간 relationship과 relationship에서 발생된 attributes 파악할 수 있습니다.
10, 11에서 제조업체 entity와 attributes를 파악할 수 있습니다.
12에서 회원 entity와 게시글 entity간 relationship를 파악할 수 있습니다.
13, 14에서 게시글 entity와 attributes를 파악할 수 있습니다.
총 정리하면 아래와 같은 Entity와 Attributes가 나옵니다.
| Entity(개체) | Entity's attributes(개체의 속성) |
| 회원 | 회원아이디, 비밀번호, 이름, 나이, 직업, 등급, 적립금 |
| 상품 | 상품번호, 상품명, 재고량, 단가 |
| 제조업체 | 제조업체명, 전화번호, 위치, 담당자 |
| 게시글 | 글번호, 글제목, 글내용, 작성일자 |
하지만 여기서 제일 중요한 Relationship(관계)이 빠졌습니다.
관계를 표현하기 위해서는 E-R D(Entity-Relationship Diagram)을 통해 표현할 수 있습니다. 4장 데이터 모델링 개념 정리 포스트에서 정리했지만, 다시 복습하자면. 관계의 핵심은 매핑 카디날리티를 파악하는 것 입니다.
Entity와 entity간 relationship 파악
위 사진 1에서 6, 7, 8, 9, 12를 다시 자세히 보겠습니다.
6. 한 회원은 여러 상품을 주문할 수 있다.(1:n) 하나의 상품은 여러 회원이 주문할 수 있다(1:n). 즉 회원 entity와 상품 entity는 주문이라는 관계가 있고 n: m 의 매핑 카디날리티를 갖습니다.
7. 회원이 상품을 주문할 때 주문번호, 주문 수량, 배송지, 주문일자 등 attributes value를 유지해야 한다.
8. 각 상품은 한 제조업체가 공급합니다(필수적 참여). 제조업체 하나는 여러 상품을 공급합니다.(1: n)
9. 제조업체 entity는 상품 entity를 공급합니다. 공급(relationship) 한다면 공급일자, 공급량 정보 attributes value를 추가적으로 유지해야 합니다.
12. 회원 entity는 게시글을 여러 개 작성(relationship)할 수 있습니다. 이때 게시글 하나는 한 명의 회원만 작성할 수 있습니다.(필수적 참여)
총 정리하자면 아래와 같은 Entity와 mapping cardinality, relationship, relationship attriburtes가 나옵니다.
| 관계 | 관계에 포함될 수 있는 속성 | 관계에 참여하는 개체 | 매핑 카디날리티 |
| 주문 | 회원(선택), 상품(선택) | 주문번호, 주문수량, 배송지, 주문일자 | n:m(다대다) |
| 공급 | 상품(필수), 제조업체(선택) | 공급일자, 공급량 | 1:n(일대다) |
| 작성 | 회원(선택), 게시글(필수) | 1:n |
그리고 위에서 얻은 Entity와 attributes + Relationship과 relationship's attributes를 포함해 ER-D를 그리면
이런 관계의 다이어그램이 형성됩니다. 하지만 이 다이어그램은 데이터베이스에 저장을 여전히 할 수 없습니다. 관계에서 정의된 매핑 카디날리티를 표현해야 할 방법을 찾아야 합니다..
2단계 요약. 개념적 설계는 요구사항 명세서로부터 개념적 스키마로 ER-D를 도출합니다.
3 단계. 논리적 설계(논리적 모델링)
3단계는 2단계 개념적 설계로부터 얻어낸 ER-D를 기반으로 실제 table의 속성과 유사한 relation schema를 설계하는 것이 목표입니다. 릴레이션 스키마는 데이터 타입, 길이, null값 여부, 기본값, constraint + 정규화 과정을 거쳐야 합니다.
- 개체이름 -> 릴레이션 이름
- 개체 속성 -> 릴레이션 속성
- 개체 키 -> 릴레이션 PK
- 정규화
위 사진은 게시글 ER-D의 게시글 엔터티를 게시글 릴레이션으로 변환한 예입니다.
복합속성의 경우 원자성을 위반하지 않도록 atomic 속성으로 분할해서 속성으로 표현해야 합니다.
다중 값 속성은 새로 릴레이션을 만들어야 합니다. 이때 원래 포함됬던 개체의 릴레이션 PK를 새로운 릴레이션의 FK로 가져와 FK 후보키를 조합해서 새로운 릴레이션의 PK를 지정합니다.
논리적 설계의 역할 중 하나는 ER-D에서 알 수 있는 매핑 카디날리티를 릴레이션으로 변환해야 할 임무가 있습니다.
관계 카디날리티 -> 릴레이션 스키마 변환 규칙
다대다(n:m)
카디날리티에서 관계와 관계의 속성들은 릴레이션으로 변환. 관계에 참여하는 두 릴레이션의 PK를 관계 릴레이션의 FK로 부여한 후 FK를 조합하여 PK를 구성하거나 관계 릴레이션을 식별할 수 있는 PK 정의.
일다대(1:n or n:1)
case 1. 카디날리티에서 1측 개체의 PK를 n측 외래키로 표현함 + 관계의 속성들을 n측 개체에 정의 (일반적인 경우)
case2. 관계가 약한 개체인 경우 n측 개체 릴레이션은 1측 개체의 PK를 외래키를 포함해 n측 개체의 기본키를 지정합니다.
일대일 (1:1)
case 1. 카디날리티에서 양측 릴레이션의 PK를 외래키로 표현 + 관계의 속성들 정의 ( 일반적인 경우 )
case 2. 한쪽은 필수, 한쪽은 선택적 참여인 경우 필수적 참여하는 릴레이션만 선택적 참여 측 릴레이션의 PK를 FK로 받습니다.
case 3. 두 릴레이션 다 필수적 참여인 경우 릴레이션을 하나로 합치고 관계 이름을 일레이션으로 사용합니다.
참고로 모든 관계는 독립적인 릴레이션으로 변환할 수도 있습니다. 그럼에도 위와 같은 표현방법을 일반적으로 선택하는 이유는 관계의 의미와 특성이 보다 명확하게 표현되기 위해서 그렇습니다.
논리적 설계 기타 고려사항
자기자신과 관계를 맺는 경우도 있다니,,, 순환 관계 또한 기본 규칙을 그대로 적용하지만 속성의 이름이 같을 경우 네이밍을 다르게 해서 1측 개체의 PK를 FK로 선언하면 됩니다.
ER-Diagram을 릴레이션으로 변환 후 속성의 데이터 타입, 길이, 널값 여부, PK, Constraint(사원 이름은 최소 몇 글자에서 최대 몇 글자...) 등을 세부적으로 지정합니다.
그리고 정규화 과정을 거치는데 정규화는 다음 포스트에서 다루려고 합니다.
4단계. 물리적 설계
db의 논리적 설계를 구체화 해서 인덱스 설계(테이블 검색 성능 향상), 파일 구성 설계(논리적 -> 물리적파일로 매핑), storage structure 설계 등을 수행합니다. DBMS는 이런 물리적 설계 작업의 일부를 자동으로 처리할 수 있습니다 :)
5단계. 구현
SQL을 통해 실제로 DBMS에서 실행해서 데이터베이스를 생성하고 데이터를 추가, 유지보수합니다.
틀린 부분 발견 시 댓글로 남겨주시면 정말 감사합니다.
