데이터베이스 개론

데이터 모델링과 ERD

NHN NEXT 정호영

나눔고딕 및 나눔고딕코딩 글꼴을 설치해 주세요.

오늘 배울것

- 데이터 모델링

- ER 다이어그램

- 관계형 데이터 모델

데이터모델링이란?

- 현실세계에서

- 응용에 필요한 데이터를 잘 고르고 다듬어서

- DBMS에 저장하는 방법

데이터모델링 과정

1. 요구사항 분석 (Requirements Analysis)

2. 개념적 설계 (Conceptual Database Design)

3. 논리적 설계 (Logical Database Design)

4. 물리적 설계 (Physical Database Design)

*데이터모델링과정

1. 요구사항 분석 (Requirements Analysis)

2. 개념적 설계 (Conceptual Database Design)

3. 논리적 설계 (Logical Database Design)

4. 스키마 정제 (Schema Refinement)

5. 물리적 설계 (Physical Database Design)

6. 응용 및 보안 설계 (Application and Security Design)

산출물로본 개발 단계

요구사항 분석 요구사항 분석서

개념적 설계 ERD

논리적 설계 관계형 데이터 모델( Relational data model)

물리적 설계 SQL

첫번째: 요구사항 분석

앱의 요구사항을데이터의관점에서바라본다.

- 사용자 / 앱이 데이터베이스에게 요구하는 것은 무엇인가?

- 무엇을 어떻게 저장할 것인가?

회사 운영 SW 요구사항분석 : (1) 회사분석

회사는 부서로 구성되어 있다.

부서는 부서이름과 부서번호, 한 명의 부장을 가진다.

부장의 업무 시작날짜를 기록한다.

부서는 하나 이상의 장소에 있을 수 있다.

회사 운영 SW 요구사항분석 : (2) 프로젝트

부서는 여러 프로젝트를 관리한다.

프로젝트는 고유번호, 고유이름, 위치 정보를 가진다.

한 프로젝트는 하나의 부서에만 속한다.

회사 운영 SW 요구사항분석 : (3) 사원

사원은 한 부서에 속한다.

사원은 하나 이상의 프로젝트에 참여한다.

사원 데이터는 사번, 이름, 주소, 성별, 주소, 연봉 정보등이다.

각 사원은 프로젝트에 참여한 시간을 관리한다.

각 사원은 1 또는 0명의 직속 상관이 있다.

회사 운영 SW 요구사항분석 : (4) – 부양 가족(Dependants)

사원들의 경조사 등을 위해 가족 정보를 유지한다.

가족 구성원에 대해 이름, 성별, 생일, 관계만 저장한다.

두번째: 개념적설계

요구사항을 조금 더 정형화하기 위해 사용

- 입력: 요구사항 분석서

-출력: ERD( Entity – Relationship Diagram )

- 수작업 또는 프로그램(ERWin 등) 사용

개체와속성 (Entity and Attribute)

개체

- 실제 현실에서 독립적으로 존재하는 어떤 것

- 직사각형으로 표현

속성

- 개체를 설명할 수 있는 특성

- 타원으로 표현

- 키 속성 : 개체마다 고유한 값을 가지는 속성

밑줄로 표현하며 하나 이상 존재 가능

부서

부서번호 부서위치

실습 : Entity 표현해보기

종이를 꺼내서 요구사항 분석을 보며 Entity를 그려 봅시다.

Relationship : 관계

개체와 개체 사이의 관계를 나타냄

관계도 애트리뷰트를 가질 수 있음

관계에는 1:1, 1:M, M:N의 세 가지가 존재

반드시 필요한 관계는 겹줄로 표현

예) 사원 - 부서, 부서 - 매니저, 사원 - 프로젝트

Department Employee

Works

1 N

약개체와식별관계

부양가족의 경우 키가 없습니다.

키가 없는 개체를 약개체(weak entity) 라고 합니다.

약개체와 부모 개체와의 관계를

식별관계(identifying relationship)라고 합니다.

가족사원

실습 : Relationship 표현해보기

Entity를 그렸던 곳에다 Relationship도 추가해 봅시다.

세번째: 논리적설계

ERD의 결과를직접 SQL로바꾸기는어렵습니다.

관계 데이터 모델로 변경합니다.

입력: ERD

출력: 관계데이터 모델 (논리 스키마)

간단한규칙 1번: 개체테이블

기본적으로

ERD의 개체는 R모델에서 테이블(릴레이션)이 됩니다.

사원 (ID, … )

부서 (ID, … )

가족 (이름, …)

프로젝트 (PID, … )

1:1 관계

관계를 맺는 개체(테이블)로 들어갑니다.

어떻게 해야 할까요?

사원 -- 1 -- 관리(시작일) == 1 == 부서

사원(ID, … )

부서(ID, … )

1:1 관계

관계를 표현하기 위해 외래키(Foreign Key)를 사용합니다.

테이블이 다른 테이블의 키 속성을 가지면 외래키입니다.

1:1 관계

(1) 관계를 맺는 테이블에 외래키를 추가합니다.

(2) 관계의 속성도 테이블의 속성으로 추가합니다.

* 사원 릴레이션에 들어가면 안 되나요?

사원 -- 1 -- 관리(시작일) ==1 == 부서

참조 무결성제약조건

외래키의 값을 제한하는 제약조건

1. 외래키는참조하는테이블의기본키를가져옴

2. 반드시 NULL이거나

3. 부모테이블에 존재하는값이어야함

위 조건을 참조 무결성제약조건 이라고 부름

시험에 100% 나옵니다.

1 : M 관계

1 : 1 관계와 비슷하게 처리 가능

관계를 맺는 릴레이션 중 한 쪽에 들어가야 함

사원 == N == 일한다(배치날짜) == 1 == 부서

사원(ID, … )

부서(ID, … ,부장ID, 부서시작일)

1 : N 관계

사원의 외래키로 부서를 추가합니다.

관계의 속성도 사원의 속성으로 추가합니다.

부서 쪽에 사원이 들어갈 수 있나요? WHY?

사원 == N == 일한다(배치날짜) == 1 == 부서

사원(ID, … ,부서ID, 배치날짜)

부서(ID, … ,부장ID, 부서시작일)

M : N 관계 는 어떻게 해야 할까요?

부서 == M == 관리한다(시작일) == N == 프로젝트

부서(ID, … ,부장ID, 부서시작일)

프로젝트(PID, …)

M : N 관계 는 어떻게 해야 할까요?

M:N 관계를 해소하기 위해서는 새로운 테이블을 만들어야 합니다.

새로운 테이블의 기본키는 두 테이블의 외래키의 복합키(?!) 입니다.

부서 == M == 관리한다(시작일) == N == 프로젝트

부서(ID, … ,부장ID, 부서시작일)

부서_프로젝트관리(DID,PID, 시작일)

프로젝트(PID, …)

약개체 는 태생적으로 문제점을 가지고 있습니다.

부양가족 개체 부양가족 테이블이

되려면 어떤 문제가 있을까요?

부양가족(이름, 성별, 생일)

약개체 는 태생적으로 문제점을 가지고 있습니다.

부양가족 테이블에는 키가 없습니다.

테이블은 반드시 기본키를 가져야 합니다.

사원 -- 1 -- 부양한다(관계) == N == 부양가족

사원(EID, …)

부양가족(이름, 성별, 생일)

약개체 는 태생적으로 문제점을 가지고 있습니다.

사원의 EID와 부양가족의 이름을 합쳐서 기본키가 됩니다.

약개체와의 관계를 식별관계라고 합니다.식별관계도 시험 단골 문제로 나옵니다.

사원 -- 1 -- 부양한다(관계) == N == 부양가족

사원(EID, …)

부양가족(EID,이름, 성별, 생일)

관계 스키마를직접완성해 봅시다.

THANK YOU!!!