[DB]/02. DB모델링

01. 모델링(UML)의 개요 및 DB모델링 개념

76beny 2022. 5. 9. 21:37

1. 모델링(Modeling)

■ 현실세계를 단순화 시켜 표현하는 기법

(현실세계를 모델링통해 모델로 표현하는 기법)

 

1) 모델링 중요한점

추상화(모형화) : 현실 세계의 다양한 현상을 일정한 형식(필요한 것만)의 표기법으로 표현함
■ 단순화 : 복잡한 현실세계를 규약, 규칙에 의해 제한된 표현으로 쉽게 이해할 수 있도록 함
 명확화 : 누구나 쉽게 이해할 수 있게 애매모호함을 제거하고 정확하게 기술함

 

2) 모델링의 필요성

- 건축 또는 비행기 등 사이즈가 큰 것들은 바로 작업을 진행하지 않고,

  거기에 맞는 모델을 만든 후 잘 되는지 시험 뒤 작업 착수
- 프로그래밍 같은 경우 건물, 비행기, 다리 등과 같이 사이즈(규모)가 크진 않지만
  여러 명이 함께 하는 공동 작업이기 때문에 모델링 작업 필요,

 

 

2.  데이터 모델링(DB 모델링)

- 사용자 및 업무에 의해 발생하는 다양한 데이터를 체계적으로 관리하는 것
- 현재 데이터 모델링은 다양한 분야에서 쓰며 **데이터의 정합성을 위해 반드시 필요한 요소로 인식하고 있음

 

** Q. 데이터 정합성? (( https://dbaguru.tistory.com/432 ))
어떤 데이터들이 값이 서로 일치하는 것, 데이터가 서로 모순 없이 일관되게 일치해야 하는 것
중복 데이터를 많이 사용하면 데이터끼리 정합성을 맞추기 어려움

 

1) DB모델링의 필요성

① 데이터 증가
- 데이터 증가 → 데이터 중복 발생 → 데이터 정합성에 문제 발생
 => 데이터 정합성 문제는 애플리케이션에서 해결 가능
- 데이터 증가 → SQL 응답 속도 저하 → 성능 저하
  => 성능저하는 SQL의 튜닝으로 해결 가능
하지만 이와 같은 방법이 근본적인 문제를 해결할 수 있는 것은 아니며
이 두 문제는 최적화된 데이터 모델링을 통해 해결 가능, 근본적인 문제 해결법


② 인식의 변화에 따라
- 고객의 변화 : 고객의 데이터 중요성 인식으로 데이터 모델링, SQL튜닝에 많은 관심을 가짐
- PM, PL의 변화 : 프로젝트 리더들이 데이터 모델링, SQL튜닝에 대한 기술력을 확보하고자 함
➔ 업무에 대해 서로 공유할 수 있는 표준화된 형식을 제공하고 개발 및 Data 관리에 사용

 

 

 

3. 소프트웨어(프로그램) 개발 프로세스

(색으로 표시된 부분이 데이터베이스 관련 영역 = DB 모델링, 아래 부분은 프로세스 관련 영역)

1)  정보전략계획수립(Information Strategic Planning) → 경영∙기업에 대한 파악

- 기업의 경영전략 및 장단점 분석
- 현행업무 절차 평가 → 개선 사항 도출
- 정보시스템 구축 계획 수립

 

2) 업무 분석 → 어떤 업무 진행 순서로 진행하는지

- 누가 어떤 행위를 하는가 → 유스케이스 다이어그램
- 업무가 어떻게 이뤄지고 있는지(어떤 정보가 발생해 오고 가는지) → 클래스 다이어그램
- 이후 데이터 관점과 프로세스 관점에서의 개발 진행

 

* 데이터와 프로세스 관점에서 데이터 모델링은 프로젝트를 수행할 때 의사소통의 도구가 됨(ERD)
Data : 업무와 관계 있는 Data를 중심으로 모든 업무를 구현할 수 있는 Data 관리
→ 업무에 어떤 데이터가 필요한가


- Process : Data가 수행하는 실제 업무에 대해 관리
(업무가 어떻게 구성되고, 업무의 처리 절차, 방법이 어떻게 되는지 모델로 표현하는 관계)
→ 업무 로직


Data + Process : 업무와 Data의 상관관계 (영향도)

 

3) 논리적 DB설계(= 데이터 모델링)

데이터베이스 설계에서 핵심적인 단계

- 현실 세계를 데이터의 관점에서 파악하여 개념적인 모델로 표현하는 단계
- 업무가 어떤 데이터와 관련 있는지, 또는 데이터 간의 관계는 무엇인지에 대한 모델링
- 데이터 모델링의 최종 산출물은 ERD

 

4) 물리적 DB설계

■ 실제 데이터베이스 구축을 위한 테이블, 뷰, 인덱스, 용량 등을 설계하는 단계

- 특정 DBMS 제품을 염두에 두고 작업 진행
- 물리 DB설계 단계의 산출물은 테이블 기술서와 같음

 

5) DB 구축 

■ 물리적 DB설계 내용을 바탕으로 테이블, 뷰, 인덱스 등 생성

 

6) DB 튜닝 

■ 데이터베이스가 일정한 성능을 유지할 수 있도록 비효율적인 요소를 제거하고
 성능 개선을 위해 SQL문장을 포함, 데이터베이스의 여러 요소를 조정하는 작업

 

 

4. DB모델링의 주요 개념

 

1) 엔티티(Entity) = 개체

■ 업무의 관심 대상이 되는 정보를 갖고 있거나 그에 대한 정보를 관리할 필요가 있는 유형/무형의 사물(개체)

 

A. 유형 엔티티 : 물리적인 형태가 있는 엔티티 (ex. 고객, 사원, 상품, 거래처, 학생, 교수 등)

(ex. 입고이력, 출고이력 등)
E. 코드 엔티티 : 무형 엔티티의 일종으로 각종 코드를 관리하기 위한 엔티티
(ex. 국가코드, 색상코드, 직급분류코드, 상태코드 등)

 

* 엔티티의 성질(조건)
업무의 관심 대상이 되는 사물이어야 한다
→ 업무 절차 상 사용되지 않는 것 제외
 두 개 이상의 인스턴스를 소유해야 한다
→ 인스턴스가 하나면 안됨
    학원에 과목이라는 엔티티가 있으면 국, 영, 수 같은 여러 인스턴스 가질 수 있음
 마땅한 속성을 소유해야 한다
→ 속성을 찾을 수 없다면 속성으로 분류해야 할 것을 엔티티로 분류한 것

 

2) 속성(Attribute)

■ 엔티티에서 관리해야 할 최소 단위 정보 항목(관심이 있는 항목)

■ 엔티티는 하나 이상의 속성 포함 (기본, 유도, 설계)

■  모델링 과정에서 현실 세계 엔티티가 포함하고 있는 모든 정보 항목을 속성으로 표현하지 않음

속성 종류

A. 기본 속성(명시적) : 업무 분석 과정에서 업무의 관심 대상으로 분류된 정보 항목들로

                             전체 속성들 중에서 가장 많은 비중 차지
B. 유도 속성 : 다른 속성의 값들로부터 유도될 수 있는 속성 (ex. 포인트)


C. 설계 속성 : 현실 세계에는 존재하지 않지만 설계를 보다 효과적으로 할 수 있기 위해,
                  혹은 나중에 정보 시스템이 운영될 때의 필요성 때문에 강제적으로 만들어주는 속성
                  인위적 주 식별자나 그 외 필요한 속성 (ex. 코드 속성, 외래키)

 

 

■ 속성 명명규칙 ***

- 속성의 의미가 분명히 드러나게 속성 명 작성(명확)
- 해당 업무에서 사용하는 이름 부여
- 서술식 속성명 X(수식어, 소유격 자제)
- 약어 사용 X
- 엔티티에서 유일하게 식별 가능하도록 지정(중복X)
- 용어 상의 혼란을 피하기 위해 사전에 Data Dictionary를 정의해 쓰는 경우도 많음


* 엔티티 + 속성 ➔ 자바에서의 클래스

 

3) 인스턴스(Instance) 

■ 엔티티의 속성으로 실제로 구현된 하나의 값(테이블의 행 또는 튜플과 대응됨)

 

4) 관계(Relationship)

■ 엔티티 간의 관련성을 나타냄
두 엔티티가 관계 있다는 것은 실무적인 관점에서 상호 공유하는 속성이 있다는 의미

(ex. ‘학생’ 엔티티의 학번 속성과 ‘수강 과목’의 학번 속성)

 

5) 카디널리티(Cardinality)

■ 각 엔티티에 속해 있는 인스턴스들 간에 수적으로 어떠한 관계에 있는지를 나타냄
 종류로는 1:1, 1:N, M:N의 관계가 있음

 

 

6) 식별자(Identifier)

■ 하나의 엔티티에는 반드시 하나의 유일한 식별자 존재
 모델링에서는 키라는 용어 대신 식별자라는 용어 사용

 

주 식별자(Primary Identifier) 엔티티 내에 있는 각각의 인스턴스들을 구별하는 기준
                                                      (테이블에서 주 식별자가 튜플과 튜플을 구분하는 기준 역할)
                                                      관계형 모델에서 기본 키(Primary Key)와 대응

 

② 외래 식별자(Foreign Identifier) : 관계가 있는 엔티티 간을 연결해주는 고리 역할
                                                        관계형 모델에서 외래키(Foreign Key)와 대응

→ 자식 엔티티의 외래 식별자는 부모 엔티티의 주 식별자에 연결

 

 

7) 각 단계별 설계

■ 개념적 설계 : 요구분석 단계에서 정의된 핵심 개체와 그들 간의 관계를 바탕으로
                    ERD(E-R Diagram)을 생성하는 단계
■ 논리적 설계 : 개념 설계에서 추상화된 데이터를 구체화하여 정규화를 거쳐
                    개체, 속성을 테이블화하고 상세화하는 과정
■ 물리적 설계 : 논리 설계에서 표현된 데이터를 실제 컴퓨터 저장장치에 어떻게 표현할 지 하는 과정
                    (**관계형 데이터베이스로 전환)
                     * 보통 논리적 설계 단계에서 개념적 모델을 같이 진행

 

** Q. 관계형 데이터베이스(RDBMS)
- 키와 값의 관계를 나타내는 테이블로 이루어져 있음
 (2차원 구조의 테이블 형태로 표현하고 가장 많이 사용되는 모델)
- 데이터의 종속성을 관계로 표현하는 것이 특징
- 1:1, 1:N, M:N 표현이 모두 가능하고 구조가 단순, 편리

** Q. 네트워크 데이터 모델 : 망 데이터 모델로, 레코드 타입 간 관계를 도형으로 표현하여 개체를 중심으로 관계 표현
** Q. 계층 데이터 모델 : 트리 데이터 모델로, 부모-자식 관계, 1:N 관계 표현

 

 

 

5. DB 모델링 툴 활용

1) https://www.erdcloud.com/ 접속
2) 회원 가입 후 로그인
3) 프로필 선택 후 나의 ERD 클릭
4) + 버튼 클릭 후 ERD 작업
- 팀 공유 기능을 지원하기 때문에 프로젝트 시 유용
- 왼쪽 상단의 라이브러리 선택 후 다른 사람이 작업한 ERD 참고 가능

 


"본 인터넷 사이트 내의 모든 이미지, 문구, 콘텐츠, 내용 등에 대한 저작권은 76beny에게 있습니다.

이를 무단으로 도용, 복사, 전재, 재배포, 2차 변형 등을 할 경우

민, 형사상 법적 조치 등 저작권법에 의거하여 처벌 받을 수 있습니다."