본문 바로가기
Programming/Database System

모델링, ER 모델

by kghworks 2022. 2. 22.

목표

  • 데이터베이스 모델링을 이해한다.
  • 사용자 요구사항 분석의 개념과 과정을 이해한다.
  • ER 모델을 이해한다.

 

목차

  • 모델링의 이해
  • 사용자 요구사항 분석
  • 데이터 모델링
  • ER 모델
  • 참고

모델링의 이해

데이터 모델

 프로그램에서 사용하는 데이터들은 데이터베이스에 체계적으로 구조화한 다음 저장, 사용해야 하기 때문에 데이터 모델이라는 것이 필요합니다. 데이터 모델은 데이터의 의미, 데이터 타입, 연산 등을 명시하기 위해 사용하는 개념적인 집합입니다. 

 

데이터 모델링

 애플리케이션이 구동되기위한 데이터들의 의미를 파악하고, 데이터를 이용하는 업무 프로세스에 대해 개념적으로 분석, 정의한 다음. 추상화된 데이터들을 DBMS가 지원하는 데이터 모델의 형태로 전환화는 과정입니다.  따라서 모델링할 때에는 대표적으로 아래 요소를 분석합니다.

 

  1. 비즈니스적 관점 - 무슨 데이터를 저장하는가
  2. 컴퓨터 프로그래머적 관점 - 어떻게 데이러를 저장하는가

 

 비즈니스적 관점에서 어떤 데이터를 저장하는지를 먼저 분석한 뒤 (DBMS 독립적) 그 데이터들을 어떻게 저장할지 분석, 결정합니다. (DBMS 의존적) 모델링 단계를 간단히 그림으로 표현해본 뒤 각 단계별로 어떻게 진행되는지 구체적으로 알아보겠습니다.

데이터베이스 모델링 단계


사용자 요구사항 분석

 설계에 앞서 데이터에 대한 충분한 분석이 필요합니다. 사용자의 요구를 명세하지 않고, 설계를 진행하면 개발의 신뢰도와 데이터베이스의 효율성이 떨어지기 때문입니다.

 

 사용자의 요구사항 분석은 시스템의 대상이 되는 업무를 분석하여 필요한 데이터를 저장, 운용할 수 있는 구조로 개발하는 것을 말합니다. 그 과정은 도출, 분석, 기록 단계로 진행됩니다.

사용자 요구사항 분석 과정

 

제안 요청서

 제안 요청서는 고객사 (발주자) 쪽에서 작성하는 문서로,  프로그램에 필요한 요구사항을 체계적으로 정리하여 명시한 문서입니다. 이 문서에는 제목, 목적 및 목표, 내용, 기대성과, 수행기간, 금액(Budget), 참가자격, 제출서류 목록, 요구사항, 제안서 목차, 평가 기준 등의 내용이 포함됩니다. (출처 : 위키백과)

 

요구사항 명세서

 제안 요청서를 검토하여 요구사항을 도출하여 작성한 문서입니다.

 

요구사항 정의서

 요구사항 명세서를 분석하여 각 요구사항을 정의하는 문서입니다. 이 때 분석이 모호하면, 다시 제안요청서로 돌아가 요구사항을 도출하는 작업을 합니다. 경우에 따라 요구사항 명세서와 정의서를 같은 문서로 통합하기도 합니다.

 


데이터 모델링

 사용자 요구사항을 분석한 다음은 데이터 모델링 단계입니다. 데이터 모델링의 단계는 간단히 아래와 같습니다.

 

  1. 개념적 데이터 모델링
  2. 논리적 데이터 모델링
  3. 물리적 데이터 모델링

 

1. 개념적 데이터 모델링

 추상화되어있는 실세계의 데이터들을 개념적으로 일반화시켜서, 데이터의 구조, 타입, 속성, 관계, 제약조건 등을 정리하는 과정입니다.

 

2. 논리적 데이터 모델링

 DBMS(오라클, MySQL 등) 에 맞춰 데이터를 표현합니다. 이때 데이터 정의 언어 (CREATE, DROP, ALTER, TRUNCATE)로 기술된 개념 스키마가 생성됩니다.

 

3. 물리적 데이터 모델링

 데이터베이스 내부의 저장구조, 파일구성, 인덱스, 접근 경로를 결정합니다.

 


ER 모델

 

 데이터 모델링하는 방법은 여러가지이나, ER모델이 최근에 표준으로 취급할 만큼 대중적으로 쓰이는 모델링입니다. 1976년 카네기 멜론 대학의 P.Chen 박사가 제안한 모델입니다. 개체(entity)와 개체 사이의 관계(relationship)를 정형화시킨 모델이며 개념적 모델링 단계에서 사용되는 모델입니다. ER 모델의 구성요소는 아래와 같습니다.

 

* ER모델을 바탕으로 데이터의 구조 및 관계를 다이어그램으로 표현한 것이 ERD(ER Diagram) 입니다. 

 

  • 개체(entity)와 개체 집합
  • 관계 집합
  • 속성 (attribute)
  • 제약조건

 

개체(entity)와 개체 집합

 개체(entity)란 실세계에 존재하는 다른 객체와 구분되는 유무형의 사물을 말합니다. 그리고 같은 속성들이 공유하는 개체들의 모임이 개체 집합 (entity set)입니다. 축구선수를 예로 들면 아래와 같이 표현이 되겠습니다.

 

개체와 개체 집합

 

관계 집합

 관계란 개체와 개체 사이의 연관성을 말하며, 개체 집합 간의 연결 관계 (연관성)를 관계집합이라고 합니다. 이는 ER 모델에서 아래와 같이 표기합니다.

 

관계집합

 마름모에는 두 개체집합간의 관계 의미가 들어갑니다.

 

속성 (attribute)

 속성이란 개체를 구체적으로 설명한 것으로 속성에 포함될 값의 특성에 따라 아래와 같이 종류가 구분됩니다.

 

  • 단순 속성과 복합 속성
  • 단일 값 속성과 다중 값 속성
  • 유도 속성과 저장 속성

 

  • 단순 속성과 복합 속성

 단순 속성은 더 작은 구성요소로 나눌 수 없는 속성을 말합니다. 축구 선수 개체 하나를 예로 들면, 나이 속성을 일의 자릿수 씩 나눈다고 의미가 없을 겁니다. (27 -> 2, 7)

 그에 반해 복합 속성 (Composite Attribute)이란 더 작은 구성요소로 나누는 것이 가능한 속성 (데이터)입니다. 선수들의 생년월일을 년, 월, 일로 나누면 그 자체로 의미 있는 데이터가 될 수 있습니다. (1987. 5. 31 -> 1987년, 5월, 31일) 복합 속성의 경우 아래 그림과 같이 들여 쓰기를 합니다.

단순속성과 복합속성의 예제

 

  • 단일 값 속성과 다중값 속성

 단일값 속성은 한 개체에 해당 속성이 단 하나만 존재할 경우입니다. 이를테면 축구선수 개체 하나에 축구선수의 생년월일은 단 하나입니다.

 반면 다중 값속성은 하나의 개체에 여러개의 값을 가질 수 있는 속성입니다. 축구선수 개체 하나가 1개 이상의 전화번호 값을 가질 수 있으므로 다중값 속성의 예가 될 수 있습니다. 다중값 속성은 ER모델에서 '{}'를 이용해 표기합니다. 

 

다중값 속성

  • 유도 속성과 저장 속성

 유도 속성이란 다른 속성의 값으로부터 값이 유추될 수 있는 속성입니다. 유도 속성을 위해 사용될 수 있는 속성이 저장 속성입니다. 나이 속성은 생년월일로부터 유도가 가능한 값을 가지므로 유도 속성에 해당합니다. 유도 속성은 '()'를 이용하여 표기합니다.

 

 

제약조건

 데이터의 무결성을 훼손하지 않기 위해서는 모델링 과정에서 제약조건을 명확하게 표기하 여아 합니다. ER모델은 데이터가 준수해야 하는 제약조건을 정의할 수 있는 표현방식을 제공합니다. 제약조건(constraints)의 종류는 아래와 같습니다.

 

  • 사상수
  • 참가 제약조건
  • 키 속성
  • 특수 속성과 특수관계

 

  • 사상수

 사상 수란 개체 집합에 대해 각각의 개체가 다른 개체 집합과 얼마만큼의 관계를 맺을 수 있는지 나타낸 수입니다. 말이 어려운데, 아래 그림들을 보면 쉽게 이해가 될 겁니다.

 

1:1 (일대일)

 "축구선수" 개체 집합과 "신체정보" 개체 집합이 있습니다. 축구 선수 하나의 개체는 하나의 신체정보 개체와 1대 1로 대응하게 될 것입니다. 이 경우에는 아래와 같이 화살표로 표기합니다.

1:1 예제

1:N (일대다)

 "축구팀"이라는 개체 집합과 "축구선수"라는 개체 집합이 있습니다. 축구팀 하나의 개체는 여러 개의 축구선수 개체들과 대응할 수 있습니다. 그러나 축구선수 하나의 개체는 축구팀 개체 집합의 하나의 개체에만 대응합니다. 이럴 때를 1:N 관계 라 하고 1에 해당하는 개체 집합에만 화살표로 표시합니다.

N:N (M:N, 다대다)

 스폰서 회사 하나는 여러 개의 축구선수들에게 스폰서를 할 수 있습니다. 마찬가지로 축구선수 한명은 여러개의 스폰서 회사와 스폰서십을 맺을 수 있죠. 이럴 때를 N:N라 하며 아래와 같이 표기합니다.

N:N 예제

 

  • 참가 제약조건

 참가 제약조건은 참가의 필수 여부에 따라 전체적 참가부분적 참가로 구분됩니다. 전체적 참가란 모든 개체가 해당 관계 집합에 참여하는 조건을 말합니다. 반대로 부분적 참가란 해당 개체집합의 모든개체가 해당 관계집합에 참여하지 않아도 되는 조건을 말합니다. 이때 전체적 참가의 경우 두줄로 관계집합과 이어서 표시합니다.

참가제약조건 예시

 축구팀은 무조건 연고지 관계집합에 참여하기 때문에 전체적참가입니다. 그러나 모든 도시가 축구팀과 연고지관계를 가지진 않기 떄문에 도시 집합은 부분적 참가입니다.

 

  • 키 속성

 키 속성이란 개체 집합 안에서 각 개체를 구별할 수 있는 유일 값을 가지는 속성이나 관계 집합의 특정 관계를 찾을 수 있게 하는 속성을 말합니다. 

 축구선수 개체 집합의 경우 "선수 코드"는 선수의 고윳값을 가진 일련번호이므로 유일 값을 가지는 키입니다. 또한 소속팀 코드는 축구팀 개체 집합과 소속팀 관계를 이을 수 있도록 하는 키입니다. 이렇게 선수 코드와 소속팀 코드는 키 속성이며 아래와 같이 밑줄을 그어 표시합니다.

키속성의 표기법

  • 특수 속성과 특수관계

 관계 집합의 속성이란 두 개체 집합의 관계를 맺을 때 생성되는 값을 저장하는 속성입니다. 이를테면 축구선수 개체집합이 축구팀 개체 집합과 연관을 맺을때 "이적일자"라는 속성이 생성될 수 있습니다. 

 하나의 개체집합 안에서 자신의 개체집합과 관계 집합을 형성하는 속성도 있습니다. (재귀적 관계)

 

 

 약한 개체 집합은 개체의 존재 유무가 관계를 맺는 상대 개체의 존재에 종속되는 개체 집합입니다. 축구선수의 "신체정보" 개체집합은 축구선수 개체가 없다면 존재하지 않는 개체입니다.  이때 "신체정보" 개체집합은 약한개체집합이고 그 상대가 되는 축구선수 개체집합은 강한 개체집합입니다. 아래와 같이 표기할 수 있다.


참고

https://ko.wikipedia.org/wiki/%EC%A0%9C%EC%95%88%EC%9A%94%EC%B2%AD%EC%84%9C

 

제안요청서 - 위키백과, 우리 모두의 백과사전

제안요청서(RFP, request for proposal)는 발주자가 특정 과제의 수행에 필요한 요구사항을 체계적으로 정리하여 제시함으로써 제안자가 제안서를 작성하는데 도움을 주기 위한 문서이다. 제안요청서

ko.wikipedia.org

 

댓글