Notice
Recent Posts
Recent Comments
Link
«   2024/10   »
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31
Tags
more
Archives
Today
Total
관리 메뉴

rudu_std

데이터 모델링 개념 & ERD 다이어그램 본문

DB

데이터 모델링 개념 & ERD 다이어그램

Ru_Du 2024. 9. 24. 01:08

데이터 모델링

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


특히 데이터를 추상화한 데이터 모델은 데이터베이스의 골격을 이해하고 그 이해를 바탕으로 SQL문장을 기능과 성능적인 측면에서 효율적으로 작성할 수 있기 때문에, 데이터 모델링은 데이터베이스 설계의 핵심 과정이기도 하다. 

 

 

데이터 모델링 순서 절차

1. 업무 파악 (요구사항 수집 및 분석)

업무 파악은 어떠한 업무를 시작하기 전에 해당하는 업무에 대해서 파악하는 단계

모델링에 앞서 가장 먼저 해야 할 것은 어떠한 업무를 데이터화하여 모델링 할 것인지에 대한 요구사항 수집.

업무파악을 하기 좋은 방법으로는 UI를 의뢰인과 함께 확인해 나아가는 것.

궁극적으로 만들어야 하는 것이 무엇인지 심도있게 알아야 한다.

 

아래는 게시판의 예시이다.

 

2. 개념적 데이터 모델링

개념적 데이터 모델링은 내가 하고자 하는 일의 데이터 간의 관계를 구상하는 단계이다 .

각 개체들과 그들 간의 관계를 발견하고 표현하기 위해 ERD 다이어그램을 생성한다.

다음은 피터 첸 표기법(Peter Chen Notation)으로 ERD 다이어그램을 구성한 그림이다. 도형이 의미하는 바를 알고 화살표를 통해 관계를 표현하기만 하면 된다.

 

아래 사진은 게시판 데이터 구상을 개념적 데이터 모델링으로 구현해 본 것이다.

게시판에는 대표적으로 게시판 이용자의 회원 정보, 로그인 정보 그리고 게시판의 게시글, 댓글이 있다.

 

3. 논리적 데이터 모델링

개념적인 데이터 모델이 완성되면, 구체화된 업무 중심의 데이터 모델을 만들어 내는데, 이것을 논리적인 데이터 모델링이라고한다. 이 단계에서 업무에 대한 Key, 속성, 관계등을 표시하며, 정규화 활동을 수행한다. 

정규화는 데이터 모델의 일관성을 확보하고 중복 제거하여 신뢰성있는 데이터 구조를 얻는데 목적이 있다.

위에서 피터 첸 표기법으로 구현한 개념적 ERD 다이어그램을 정보 공학 표기법 테이블 형태로 재 구성 한다.

 

이때 단순히 추상적인 데이터에서 보다 구체화적인 데이터로 작성한다.

예를 들어 회원정보의 아이디, 비밀번호에 각 데이터 타입을 명시해 주고 각 데이터간의 관계를 정밀하게 맺어주며 테이블의 키(key)를 지정해준다.

1대 다 관계를 1:* 로 표현.

 

4. 물리적 데이터 모델링

물리적 데이터 모델링은 최종적으로 데이터를 관리할 데이터 베이스를 선택하고, 선택한 데이터 베이스에 실제 테이블을 만드는 작업 이다.

시각적인 구조를 만들었으면 그것을 실제로 SQL 코딩을 통해 완성하는 단계

/* 테이블 생성 */

-- 회원정보
create table member_tbl ( 
  member_uid bigint primary key auto_increment,
  member_name varchar(45) unique not null,
  member_pwd varchar(45) not null,
  member_status boolean not null
);

-- 로그인기록정보
create table login_info_tbl( 
  member_name varchar(45) not null,
  info_ip varchar(45) not null,
  info_date datetime not null,
  constraint fk_member_name foreign key (member_name) references member_tbl (member_name)
);

-- 게시판
create table board_tbl ( 
  board_uid bigint primary key auto_increment,
  member_name varchar(45) not null,
  board_title varchar(45) not null,
  board_date datetime not null,
  board_hit int not null,
  board_post varchar(5000) not null,
  constraint fk_member_name foreign key(member_name) references member_tbl(member_name)
);

-- 게시판 풀텍스트 인덱스 생성
create Fulltext index idx_title on board_tbl ( board_title );
create Fulltext index idx_post on board_tbl ( board_post );
-- show index from board_tbl ;

-- 댓글
create table reply_tbl ( 
  reply_uid bigint primary key auto_increment,
  board_uid bigint not null,
  member_name varchar(45) not null,
  reply_date datetime not null,
  reply_post varchar(1000) not null,
  foreign key(board_uid) references board_tbl(board_uid),
  foreign key(member_name) references member_tbl(member_name)
);

-- 댓글 풀텍스트 인덱스 생성
create Fulltext index idx_reply on reply_tbl ( reply_post );

 

데이터 모델링 절차 정리

지금까지 알아보았던 절차를 간단하게 요약 정리하자면 다음과 같다.

  1. 1. 네이버 게시판의 화면에 어떠한 것들이 필요한지에 대한 개념을 잡는게 업무파악 단계 (요구사항 수집 및 분석)
  2. 2. 네이버 게시판의 화면에 표현되는 데이터들을 파악해서 관계를 설정하는게 개념적 데이터 모델링
  3. 3. 개념적 데이터 모델링 한 것을 표로 만드는 게 논리적 데이터 모델링
  4. 4. 이 일련의 과정을 수행한 것을, 실제 데이터베이스 테이블로 만드는 게 물리적 데이터 모델링



ERD (Entity Relationship Diagram) 그리기

ERD (Entity Relationship Diagram) 단어에서 의미하는 그대로 'Entity 개체'와 'Relationship 관계'를 중점적으로 표시하는 데이터베이스 구조를 한 눈에 알아보기 위해 그려놓는 다이어그램이다. 개체 관계도라고도 불리며 요구분석사항에서 얻은 엔티티와 속성들의 관계를 그림으로 표현한 것이다.

 

ERD 엔티티 표기법

 

엔티티(Entity) 

  • 엔티티는 정의 가능한 사물 또는 개념을 의미한다.
  • 사람도 될수 있으며 프로필이나 도서정보와 같은 무형의 정보도 데이터화가 가능하다.
  • 데이터베이스의 테이블이 엔티티로 표현된다고 보면 된다.
  • 예를들어 학생 Entity는 아래의 그림과 같이 표현된다.

 

엔티티 속성(Attribute) 

  • 엔티티에는 개체가 갖고있는 속성(Attribute)을 포함한다.
  • 예를들어 학생 엔티티라면, 학번, 이름, 주소, 전공 ..등 속성들이 있다.
  • 데이터베이스의 테이블의 각 필드(컬럼)들이 엔티티 속성이라고 보면 된다.

 

엔티티 도메인(Domain) 

  • 도메인은 속성의 값, 타입, 제약사항 등에 대한 갑의 범위를 표현하는 것이다.
  • 사용자 기호에 따라 속성 타입만 그릴수도 있고, 가독성을 위해서 생략할 수도 있다.
  • 이때 데이터 타입을 명시할때, 데이터베이스가 지원하는 타입에 맞게 해야한다.

 

엔티티 분류 

  • 엔티티는 저장하는 데이터 정보 주제에 따라 종류가 다양하다.
  • 고객 정보같은 실제로 물리적인 형태로 있는 정보와 구매 이력같은 무형적이고 개념적인 정보가 있다.
  • 이 엔티티 분류 구분을 잘 해주어야 데이터베이스 설계에 있어 각 데이터 주제에 맞게 모델링을 구축할 수 있다.
구 분  내 용
유형 엔티티 물리적인 형태
(예 : 고객, 상품, 거래처, 학생, 교수 등)
무형 엔티티 물리적인 형태가 없고 개념적으로만 존재하는 엔티티
(예 : 인터넷 장바구니, 부서 조직 등)
문서 엔티티 업무 절차상에서 사용되는 문서나 장부, 전표에 대한 엔티티
(거래명세서, 주문서 등)
이력 엔티티 업무상 반복적으로 이루어지는 행위나 사건의 내용을 일자별, 시간별로 저장하기 위한 엔티티
( 예 : 입고 이력, 출고 이력, 구매 이력 등)
코드 엔티티 무형 엔티티의 일종으로 각종 코드를 관리하기 위한 엔티티
(예 : 국가코드, 각종 분류 코드)

 


ERD 엔티티 관계 표기법

 

각 엔티티 유형들을 만들었으면, 엔티티 끼리 관계가 있는 경우 선을 이어 관계를 맺어야 한다.

두 엔티티 관계에서 부모의 키를 자식에서 PK로 사용하는지 일반 속성으로 사용하지에 따라서 표기가 다르게 된다.

 

실선으로 그으면 강한 관계를 나타내는 것이며 '식별자 관계'라고 불리우며,

점선으로 그으면 약한 관계를 나타내는 것이며 '비식별자 관계'라고 불리우게 된다.

항목 식별자 관계 비식별자 관계
목적 강한 연결관계 표현 약한 연결관계 표현
자식 주식별자
영향
자식 주식별자의 구성에 포함됨 자식 일반 속성에 포함됨
표기법 실선 표현 점선 표현
연결
고려사항
- 반드시 부모엔터티 종속

- 자식 주식별자구성에 부모 주식별자포함 필요

- 상속받은 주식별자속성을 타 엔터티에 이전 필요
- 약한 종속관계

- 자식 주식별자구성을 독립적으로 구성

- 자식 주식별자구성에 부모 주식별자 부분 필요

- 상속받은 주식별자속성을 타 엔터티에 차단 필요

- 부모쪽의 관계참여가 선택관계

 

식별 관계(Identifying)

- 개체 A, B 사이의 관계에서 A 개체의 기본키가 B 개체의 외래키이면서 동시에 기본키가 되는 관계

- B 개체의 존재 여부가 A 개체의 존재 여부에 의존적인 경우에 발생, ER 도형에서 식별 관계는 실선으로 표시

 

비식별 관계(Non-identifying)

- 개체 A, B 사이의 관계에서 A 개체의 기본키가 B 개체의 비기본키 영역에서 외래키가 되는 관계

- B 개체의 존재 여부는 A 개체의 존재 여부와 관계없이 존재

- 일반적으로  개체는 비식별 관계로 존재하는 경우가 많으며, ER 도형에서 점섬으로 표기

// 식별 //
-- 부모 테이블 생성 (학생)
CREATE TABLE Student (
    student_id INT PRIMARY KEY,
    name VARCHAR(100)
);

-- 자식 테이블 생성 (학생증)
CREATE TABLE Student_ID_Card (
    student_id INT,  -- 부모 테이블의 기본 키 포함
    card_number INT,
    PRIMARY KEY (student_id, card_number),  -- 복합 기본 키 (식별 관계)
    FOREIGN KEY (student_id) REFERENCES Student(student_id)  -- 외래 키
);

/////////////////////////////////////////////////////////////////////////

// 비식별 //
-- 부모 테이블 생성 (학생)
CREATE TABLE Student (
    student_id INT PRIMARY KEY,
    name VARCHAR(100)
);

-- 자식 테이블 생성 (수강 과목)
CREATE TABLE Enrollment (
    enrollment_id INT PRIMARY KEY,  -- 자식 테이블의 독립된 기본 키
    student_id INT,  -- 부모 테이블의 기본 키를 참조
    course_name VARCHAR(100),
    FOREIGN KEY (student_id) REFERENCES Student(student_id)  -- 외래 키로만 참조
);

ERD Notation

ERD에는 여러 기호들로 관계를 표현할 수 있으나, 기호들만 숙지하여도 충분히 표현 가능하다.

 

1. One (일대일 또는 일대다 관계)

  • 하나의 데이터가 다른 하나의 데이터와 연결되거나, 여러 데이터와 연결될 수 있습니다.
  • ex) 한 명의 학생이 한 명의 지도 교수에게 배정되거나, 여러 과목을 수강할 수 있는 관계.

2. Many (다대다 관계)

  • 여러 데이터가 다른 여러 데이터와 서로 연결됩니다.
  • 중계 테이블을 통해서 여러 데이터를 함께 관리합니다.
  • ex)  학생 여러 명이 여러 과목을 수강하는 경우.

3. One (and only one) (단 하나의 일대일 관계)

  • 한 데이터가 오직 하나의 데이터와만 연결됩니다.
  • ex)  한 사람당 하나의 여권만 존재할 수 있는 관계.

4. Zero or One (일대일 또는 없음)

  • 데이터가 하나와 연결될 수도 있고, 연결되지 않을 수도 있습니다.
  • ex)  가입 시 선택 사항으로 제공되는 연락처 정보. 입력해도 되고, 입력하지 않아도 됨.

5. One or Many (일대일 또는 다대다 관계)

  • 하나의 데이터가 하나 또는 여러 데이터와 연결될 수 있지만, 몇 개의 데이터와 연결될지는 확실하지 않을 때 사용됩니다.
  • ex)  회사의 한 직원이 한 명의 팀장과 연결될 수도 있고, 여러 프로젝트에 참여할 수도 있음.

6. Zero or Many (없거나 여러 개와의 관계)

  • 데이터가 없을 수도 있고, 하나 또는 여러 개와 연결될 수도 있습니다.
  • ex)  쇼핑몰의 장바구니처럼, 상품이 없을 수도 있고, 하나일 수도 있으며, 여러 개일 수도 있음.

 

 

 

 

 

 

 

 

출처 : https://inpa.tistory.com/entry/DB-%F0%9F%93%9A-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81-1N-%EA%B4%80%EA%B3%84-%F0%9F%93%88-ERD-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8