학습 계획
데이터 모델링이란 무엇이며, 중요한 이유와 과정을 학습한다.
ERD를 학습해보며 더 나아가 개체를 테이블로 만들어 본다.
데이터 모델링이란?
데이터 모델링은 데이터베이스 디자인의 핵심 개념 중 하나로, 현실 세계의 업무 프로세스와 데이터 요구 사항을 분석하여 데이터베이스 구조를 설계(DBMS에 저장)하는 과정을 말한다.
우리는 모든 데이터를 다 저장 하기는 현실적으로 불가능하다.
필요한 데이터만을 저장해야 하며, 이 저장 할 데이터를 잘 고르고 잘 다듬어야 한다. 우리는 데이터 모델링을 통해 효율적,정확한 데이터처리를 해야한다.
추상적인 개념을 구체화 하는 단계라고 보면 될것 같습니다.
데이터 모델링 과정
데이터베이스 모델링은 다음과 같이 크게 4가지 단계로 나뉘어 집니다. 각각의 단계에서 요구사항 분석서, ERD, 관계형 데이터 모델, SQL이라는 산출물이 생기게 됩니다. 이러한 과정을 통해 애플리캐이션을 개발하고, 보안 및 유지보수 단계로 넘어가게 됩니다.
요구사항 분석
- 앱의 요구사항을 데이터 관점에서 바라본다.
- 사용자/앱 데이터에베이스에게 요구하는 것은 무엇인가?
- 무엇을 어떻게 저장할 것인가?
결과적으로 요구 사항 명세서를 만듭니다.
개념적 설계 (ERD)
요구사항으로 ERD (Entity - Relationship Diagram) (e-r 다이어그램)을 그린다.
- 요구 사항 분석 결과물을 개념적 데이터 모델을 이용해 개념적 구조로 표현합니다.
- 일반적으로 E-R 모델을 많이 이용합니다.
ERD
작업 과정
1. 개체 추출, 각 개체의 주요 속성과 키 속성 선별
2. 개체 간의 관계 결정
3. E-R 다이어그램으로 표현
앞으로 위의 그림을 기준으로 개념적 설계-> 논리적 설계로 진행해봅니다.
표기법
-
주요 작업 으로 요구 사항 분석 결과를 기반으로 중요한 개체를 추출하고 개체 간의 관계를 결정하여 E-R 다이어그램으로 표현 합니다.
-
다중값 애트리뷰트 ( Multi-Valued Attribute )
보통은 Attribute의 값만 가지지만, 하나의 Attribute가 여러 개의 값을 가지는 Attribute를 가지는 경우도 있습니다. 예를 들어, 학생의 전공을 나타내는 Attribute가 있다고 있을 때, 이 학생이 복수 전공을 할 경우 Attribute 값이 2개가 되므로, 이 때 학생의 Attribute를 Multi-Valued Attribute라고 합니다. 이와 달리, 오직 하나의 값을 갖는 애트리뷰트를 단일값 애트리뷰트(Single-Valued Attribute)라고 합니다. Multi-Valued Attribute는 ER 다이어그램에서 두 개의 원으로 표현합니다.
- 유도된 애트리뷰트 ( Derived Attribute )
다른 Attribute가 갖고 있는 값으로부터 계산되어져 나온 Attribute를 의미합니다.
예를 들어, 모든 상품의 총 가격을 나타내는 total, 상품의 가격을 나타내는 price, 상품의 개수를 나타내는 count Attribute가 있다고 가정하겠습니다.
total은 price와 count의 곱으로 계산되어져 나오는 값이므로 total Attribute는 Derived Attribute입니다. Derived Attribute는 ER 다이어그램에서 원을 점선으로 표현합니다.
개체와 속성
개체(Entity)
- 실제 현실에서 독릭적으로 존재하는 것
- 직사각형으로 표현
속성(Attribute)
- 개체(엔터티)가 가지고 있는 특징이나 성질
- 타원으로 표현
- 키속성 : 개체마다 고유한 값을 가지는 속성 밑줄로 표현하며 하나 이상 존재 가능
예를들어 학생 개체가 학번,이름,전화번호 속성을 가지고 학번이라는 키속성을 가집니다.
속성은 분리되지 않는 단위라고 말합니다. 속성은 하나의 값만 가져야 하기 때문입니다. 그래야 해당 속성에 저장되는 데이터가 의미가 있습니다. 그렇기에 멀티 파트가 되는 속성들은 쪼개서 하나의 의미만 가질 수 있도록 만들어야 합니다. 그렇기 때문에 엔티티에 꼭 필요한 속성인지 신중히 생각할 필요가있습니다.
약개체와 식별관계
여기서 직원과 가족과의 관계를 식별관계 라합니다. 여기서는 부양을 말합니다.
키가 없는 개체(가족)을/를 약개체라고합니다. 약개체와 부모 개체와의 관계를 식별관계라고 합니다.
약개체는 부분 키(이름)를 1개이상 가질 수 있으면 이를 통해 의존 대상과 구분이 가능합니다.
-
식별관계는 기본키(PK)가 자식 테이블의 외래키이자 기본키로 사용되는 관계입니다.
-
자식 테이블의 행을 추가할 때 부모테이블의 참조 행이 없다면 자식테이블의 행을 추가 할 수 없습니다.
-
비식별관계는 부모 테이블을 참조한 테이블에서 참조된 외래키가 기본키가 아닌 일반속성(컬럼)으로 참조되었을 때를 말합니다.
-
자식 테이블의 행(정보)를 추가할 때 부모테이블의 참조 행(상품번호 또는 주문번호)이 없어도 자식테이블의 행을 추가 할 수가 있습니다.
현업에서는 보통 식별관계보다 비식별관계를 선호합니다. 식별관계는 자식 엔터티가 늘어날 수록 주키가 계속해서 쌓이기 때문에 구조를 쉽게 변경할 수 없습니다. 즉 변경에 불리합니다.
위의 그림처럼 pk를 하나 인조키로 지정해주는 것을 권고합니다.
논리적 설계 (관계형 데이터 모델)
ERD의 결과를 직접적으로 SQL로 바꾸기는 어렵습니다. 관계 데이터 모델로 변경합니다.
입력 : ERD , 출력 : 관계 데이터 모델(논리 스키마)
- 개체를 테이블로 만든다. 기본적으로 ERD의 앤티티는 R모델의 테이블이 됩니다.
1:1관계
- 관계를 표현하기 위해 외래키(Foreign key)를 사용합니다.
- 모든 개체가 일대인 관계에 필수적으로 참여하면 릴레이션을 하나로 합친다.
- 일대일 관계에 필수적으로 참여하는 개체의 릴레이션만 외래키를 받는다.
참조 무결성 제약조건
외래키의 값을 제한하는 제약조건 외래키는 아래와 같은 조건을 무조건 지켜야합니다.
1. 외래키는 참조하는 테이블의 기본키를 가져온다.
2. 반드시 NUll이거나 부모테이블에 존재하는 값이어야 한다.
1:N관계
다음 과 같은 관계를 가질 때 사원과 부서의 관계를 1:N 관계라 할 수 있습니다. 두 개체가 테이블이 될 때 누구의 기본키를 외래키로 가질 것이냐가 핵심이 될 것입니다.
사원 테이블이 부서 이름을 가질 수 있지만 반대는 되지 않습니다.
다시 말하면 1:N 관계에서는 N쪽이 외래키를 가지도록 합니다.
1:N입장에서 모든 사원은 어떠한 부서에 들어가 있는지 표현해야 하고 사원테이블은 이를 FK 키로 부서의 이름을 가지고 있으면 될 것입니다.
N:M관계
N:M 관계는 관계를 가진 양쪽 엔티티 모두에서 1:N 관계를 가지는 것을 말합니다.
즉, 서로가 서로를 1:N 관계로 보고 있는 것입니다.
M:N 관계를 해소하기 위해서는 새로운 테이블을 만들어야 합니다. 새로운 테이블의 기본키는 두테이블의 외래키의 복합키 입니다.
N:M 관계에서 생긴 이 테이블은 오직 사원테이블과 프로젝트 테이블의 관계를 정의하기 위해서만 존재합니다. 연결 테이블은 두 테이블의 기본키를 외래키로 둡니다.
약개체 식별관계
약개체의 태생적 문제점이 있습니다. 부양가족 테이블과 같은 약개체에는 키가 없습니다. 하지만 테이블은 반드시 기본키를 가져 합니다. 이 때 사원(부모 엔티티)의 Pk를 부양가족의 이름과 합쳐서 기본키가 됩니다. 사원과 부양가족은 식별 관계(identify relationship) 라고 합니다.
물리적 설계 (SQL)
물리적 설계 단계에서는 논리적 설계 단계에서 산출되는 ERD를 토대로 데이터베이스의 물리적인 구조와 접근 방법에 대해서 설계를 하는 단계입니다.
이 단계에서 우리는 특정 DB를 선정해서 ERD를 실제 DATA로 변경하는 과정을 거치게 됩니다.
구현
참고 자료
