[Database]데이터 모델링

rara_kim·2022년 6월 6일
0

Database

목록 보기
2/9
post-thumbnail

데이터 모델링 이란?

데이터 모델링이란 정보시스템 구축의 대상이 되는 업무 내용을 분석하여 이해하고 약속된 표기법에 의해 표현하는걸 의미한다.
그리고 이렇게 분석된 모델을 가지고 실제 데이터베이스를 생성하여 개발 및 데이터 관리에 사용되는, 데이터베이스 설계의 핵심 과정이기도 하다.

데이터 모델은 데이터베이스의 골격을 이해하고 그 이해를 바탕으로 SQL문장을 기능과 성능적인 측면에서 효율적으로 작성하기 위해 꼭 알아야 한다.

💡데이터 모델링
정보시스템을 구축하기 위해 해당 업무에 어떤 데이터가 존재하는지, 업무가 필요로 하는 정보는 무엇인지를 분석하는 방법

데이터 모델링 3단계

  1. 개념적 데이터 모델링: 추상화 수준이 높고, 업무 중심적이고 포괄적인 수준의 모델링.
  2. 논리적 데이터 모델링: 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현.
  3. 물리적 데이터 모델링: 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계.

개념적 데이터 모델링

개념적 데이터 모델링은 업무와 데이터 간의 관계를 구상하는 단계이다.
개념적 데이터 모델은 추상화 수준이 높고, 업무중심적이며 포관적인 수준의 모델일을 수행한다.
핵심 엔터티와 엔터티 간의 관계를 발견하고 그것을 표현하기 위해 ER다이어그램(엔터티-관계 다이어그램)을 생성한다.

ER다이어그램 테이블 표를 작성하기 전에 간단한 도형으로 표현하는 단계이다.
도형이 의미하는 바를 알고 화살표를 통해 관계를 표현하면 된다.

◼︎Entity -> MEMBER
●Attribute -> USER_ID
▲ Relation -> PK, FK

논리적 데이터 모델링

상위 수준의 엔터티 중심의 모델이 완성되면, 구체화된 업무중심의 데이터 모델을 만드는데 이것을 논리적인 데이터 모델링이라고 한다.

이 단계에서는 업무에 대한 Key,속성,관계 등을 표시하며 정규화 활동을 수행한다.
정규화는 데이터 모델의 일관선을 확보하고 중복을 제거하여 신뢰성있는 데이터 구조를 얻는데 목적이 있다.

위에서 구현한 개념적 ER다이어그램을 테이블 형태로 재구성 한다.
이때 단순히 추상적인 데이터가 아니라 보다 구체화하여 데이터를 작성한다.

물리적 데이터 모델링

물리적 데이터 모델링은 최종적으로 데이터를 관리할 데이터 베이스를 선택하고, 선택한 데이터 베이스에 실제 테이블을 만드는 작업을 말한다.
시각적인 구조를 만들었으면 그것을 SQL문을 통해 완성하는 단계이다.

-- 회원정보
CREATE TABLE `MEMBER` (
	`USER_ID`  VARCHAR(50)  NOT NULL COMMENT '아이디', -- 아이디
	`NAME`     VARCHAR(20)  NULL     COMMENT '이름', -- 이름
	`PHONE`    VARCHAR(12)  NULL     COMMENT '연락처', -- 연락처
	`PASSWORD` VARCHAR(255) NULL     COMMENT '비밀번호', -- 비밀번호
	`EMAIL`    VARCHAR(50)  NULL     COMMENT '이메일', -- 이메일
	`REG_DT`   DATE         NULL     COMMENT '가입일시' -- 가입일시
)
COMMENT '회원';

-- 회원정보(PK지정)
ALTER TABLE `MEMBER`
	ADD CONSTRAINT `PK_MEMBER` -- 회원 기본키
		PRIMARY KEY (
			`USER_ID` -- 아이디
		);

-- 주문정보
CREATE TABLE `ITEM_ORDER` (
	`ORDER_ID` INT         NOT NULL COMMENT '주문키', -- 주문키
	`USER_ID`  VARCHAR(50) NULL     COMMENT '아이디', -- 아이디
	`ITEM_ID`  INT         NULL     COMMENT '상품키', -- 상품키
	`AMOUNT`   INT         NULL     COMMENT '주문수량', -- 주문수량
	`ORDER_DT` DATE        NULL     COMMENT '주문일시', -- 주문일시
	`PAY`      INT         NULL     COMMENT '결제금액' -- 결제금액
)
COMMENT '주문';

-- 주문정보(PK지정)
ALTER TABLE `ITEM_ORDER`
	ADD CONSTRAINT `PK_ITEM_ORDER` -- 주문 기본키
		PRIMARY KEY (
			`ORDER_ID` -- 주문키
		);

ALTER TABLE `ITEM_ORDER`
	MODIFY COLUMN `ORDER_ID` INT NOT NULL AUTO_INCREMENT COMMENT '주문키';
    
-- 회원정보(관계 설정)
ALTER TABLE `ITEM_ORDER`
	ADD CONSTRAINT `FK_MEMBER_TO_ITEM_ORDER` -- 회원 -> 주문
		FOREIGN KEY (
			`USER_ID` -- 아이디
		)
		REFERENCES `MEMBER` ( -- 회원
			`USER_ID` -- 아이디
		);

💡데이터 모델링 순서 정리
1. 어떠한 것들이 필요한지 먼저 업무 내용을 파악
2. 필요한 데이터들을 파악해서 관계를 설정(개념적 데이터 모델링)
3. 개념적 데이터 모델링 한 것을 표로 작성(논리적 데이터 모델링)
4. 이러한 과정들을 수행한 것을 실제 데이터 베이스에 작업(물리적 데이터 모델링)



ERD(Entity Relationship Diagram)

ERD(Entity Relationship Diagram)는 데이터 베이스 구조를 한 눈에 알아보기 위해 그려놓는 다이어그램이다.
ERD는 단어에서 의미하는 그대로 'Entity(개체)' 와 'Relationship(관계)'를 중점적으로 표시하는 다이어그램이다.

ERD 구성요소 표기법 - 엔티티

Entity

  • Entity는 정의 가능한 사물 또는 개념을 의미한다.
  • 사람, 장소, 물건, 사건, 개념 등의 명사에 해당한다.
  • 데이터 베이스를 설계할 때, 테이블 이 Entity로 정의될 수 있다.

    💡Entity 특징

    • 엔티티는 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
    • 유일한 식별자에 의해 식별이 가능해야 한다.
    • 두개 이상의 영속적으로 존재하는 인스턴스의 집합이어야 한다.
    • 업무 프로세스에 의해 이용되어야 한다.
    • 엔티티는 반드시 속성이 있어야 한다.
    • 엔티티는 다른 엔티티와 한 개 이상의 관계가 있어야 한다.(반드시 만족시킬 필요는 없다)

Entity Attribute

  • 각각의 Entity에는 속성을 포함하고 있다.
  • Attribute는 개체가 갖고있는 속성이다.
  • 속성은 업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더이상 분리되지 않는 최소의 데이터 단위이다.
  • 속성은 업무에서 필요로 하는 데이터이며, 의미상 더 이상 분리되지 않고 엔티티를 설명하는 인스턴스의 구성요소가 된다.
  • 예를 들어, 학생이라는 엔티티는 학번, 이름, 학점 등의 속성으로 특징 지을 수 있다.

여기서 하나 더 필요한 건 데이터의 타입이다.
데이터 타입을 같이 명시해줘야 하며 이때, RDBMS가 지원하는 타입에 맞춰줘야 한다.

💡도메인 : 각 속성이 가질 수 있는 값의 범위
예를 들어, 달력의 달을 의미하는 값을 저장하는 속성이 있다고 하자.
이 속성은 1부터 12까지의 값만 가지는데, 이때 도메인의 범위를 1부터 12까지라고 한다.

Entity 분류

구분분류
유형 엔티티물리적인 형태가 있다.
ex)고객, 상품,학생, 교수 등
무형 엔티티물리적인 형태가 없고 개념적으로만 존재하는 엔티티이다.
ex)쇼핑몰 장바구니, 부서 조직 등
문서 엔티티업무 절차상 사용되는 문서나 장부,전표에 대한 엔티티이다.
ex)거래명세서, 주문서 등
이력 엔티티업무상 반복적으로 이루어지는 행위나 사건의 내용을 일자별, 시간별로 저장하기 위한 엔티티이다.
ex)입고 이력, 출고 이력, 구매 이력 등
코드 엔티티무형 엔티티의 일종으로 각종 코드를 관리하기 위한 엔티티이다.
ex)국가코드, 각종 분류 코드

ERD 구성 요소 표기법 - 키와 제약조건

제약조건(Constraint)은 데이터 베이스의 데이터의 정확성을 유지하기 위한 목적으로 사용하며 테이블에 저장할 데이터를 제약하는 특수한 규칙을 의미한다.

테이블 제약조건

  • 테이블에 부적절한 자료가 입력되는 것을 방지하기 위해서 여러가지 규칙을 적용해 놓는 것.
  • 간단하게 말하면 테이블 안에서 데이터의 성격을 정의하는 것.

    💡NOT NULL 조건, UNIQUE 조건, CHECK 조건, DEFAULT(컬럼 기본값) 지정, PRIMARY KEY지정, FOREIGN KEY(외래키)지정

PK(Primary Key)

  • USER_ID를 기본키로 지정하여 표현

NOT NULL

  • Null을 허용하지 않으면 N을 적고, 허용하지 않으면 적지 않는다.

FK(Foreign Key)

  • Foreign Key를 표시할 때 에는 을 사용하는데, 개체와 관계를 따져 표시한다.

ERD 구성요소 표기법 - 관계 선 긋기

두 개체의 관계 - 점선/실선

  • 두 관계 중 부모의 키를 PK로 받는지 안받는지 에 따라서 점선, 실선 표기가 다르다.
  • 부모와 자식이 아래 사진과 같을때
    🙍🏻‍♀️부모: address
    👶🏻자식: store
  • 실선: 식별 관계
    - 부모 자식 관계에서 자식이 부모의 키를 외래키로 참조해서 자신의 키로 설정
  • 점선: 비식별 관계
    - 부모 자식 관계에서 자식이 부모의 키를 일반 속성으로 참조

두 개체의 관계 - 선의 끝 모양

관계가 존재하는 두 Entity사이에 한 Entity에서 다른 Entity 몇개의 개체와 대응되는지 제약조건을 표기하기 위해 선을 그어 표현한다.
선으로 표현할 때에는 가독성을 위해 ERD에서는 선의 끝 모양을 다르게 표시한다.

✔️One To One: 1대 1 대응

✔️One To Many: 1대 다 대응

✔️Many To Many: 다 대 다 대응

두 개체의 관계 - 필수/선택 기호

  • I표시가 있는 곳은 반드시 있어야 하는 개체: 필수
  • O표시가 있는 곳은 없어도 되는 개체: 선택

📚참고
https://inpa.tistory.com
https://www.lucidchart.com/pages/er-diagrams
https://gngsn.tistory.com/48

profile
느리더라도 꾸준하게

0개의 댓글