[Data Modeling (데이터 모델링)]

 

데이터의 모델링

1. 요구사항 분석
2. 개념적 모델링 
3. 논리적 모델링
4. 물리적 모델링

 

개념적 (80%), 논리적(15%), 물리적(5%)

 

---

 

 

모델링

- 특정 목적에 따라 대상의 주요 대상을 도출하여을 재구성하는것 과정

데이터 모델링 (Data Modeling)

- 현실 세계에 존재하는 데이터를 컴퓨터 세계의 데이터 베이스로 옮겨 변환하는 과정

 

Digital Twin(디지털 트윈) : 현실속 사물을 컴퓨터에 대입하여 현실에서 생길 수 있는 상황을 CPU로 시뮬레이터 함으로서 결과를 예측하는 기술이다.

 

추상화 : 현실세계의 사물을 CPU에 데이터화 하기 위해 중요한 정보를 옮기는 단계다.

 

데이터 모델링의 목적

- 현실 문제를 해결하기 위해 실게계의 대상에서 중요한 것을 도출하여 이를 정보(테이블)로 재구성

Data Modeling Process

- 요구사항분석(정의서, 분석서 도출) → 개념적 모델링(ERD) → 논리적 모델링(Table) → 물리적 모델링(Schema)

 

1) 요구사항 수집 및 분석

• 사용자들의 요구사항을 듣고 분석하여 데이터베이스 구축의 범위를 정합니다.

2) 설계

• 분석된 요구사항을 기초로 주요 개념과 업무 프로세스등을 식별하고(개념적 설계), 사용하는 DMBS의 종류의 맞게 변환(논리적 설계) 한 후, 데이터베이스 스키마를 도출(물리적 설계)합니다.

3) 구현

• 설계 단계에서 생성한 스키마를 실제 DBMS에 적용하여 테이블 및 관련 객체(뷰, 인덱스 등)를 만듭니다.

4) 운영

• 구현된 데이터베이스를 기반으로 소프트웨어를 구축하여 서비스를 제공합니다.

5) 감시 및 개선

• 데이터베이스 운영에 따른 시스템의 문제를 관찰하고 데이터베이스 자체의 문제점을 파악하여 개선합니다.

 

Heuristic : 체험적인, 짬에서 나오는 Ex) 디자인 패턴, 휴리스틱 테스팅

 

엔티티 속성 릴레이션쉽 

객체 객체속성 객체의 관계

 

---

 

 

Data Modeling Process

 

개념적 구조

- 추상적 구조이며 가장 중요한 정보를 확인하는 구조.

논리 데이터 구조

- CPU 입장에서 해석이 가능한 구조.

- EX) ERD

물리 데이터 구조

- 해석을 하여 구현된 실질적으로 이용 가능한 데이터 구조.

- 일치성이 일치 하지 않으면 구조적으로 돌아가 다시 모델링을 해야한다.

 

 

 

 

---

 

 

요구사항 분석

- 고객이 무엇을 원하는지 또는 시스템이 무엇을 원하는지 도출하고 논리를 체계화 하는 과정이다.

- 가시성 → 시각화 → 규칙부여

 

요구사항 수집 방법

• 실제 문서를 수집하고 분석합니다.
• 담당자와의 인터뷰나 설문조사를 통해 요구사항을 직접 수령합니다.
• 비슷한 업무를 처리하는 기존의 데이터 베이스를 분석합니다.
• 각 업무와 연관된 모든 부분을 살펴봅니다.

 

대표적인 요구사항 분석 기법

• 관찰 : 직접적 관찰, 요구사항을 명확히 도출하기 어려울 경우, 초기 분석.
• 인터뷰 : 질문, 예상 답변, 추가질문 등을 계획하고 이해관계자(Stakeholder)와 직접적이고 단도직입적인 대화를 통해 오해의 요소가 발생하지 않도록 요구사항을 도출한다.
• 프로토타이핑(prototyping) : 요구사항의 적용 결과에 대한 시제품화한 모형(prototype)을 만들어 요구사항 가시화 하여 도출한다.
• 포커스 그룹 : 선별된 전문가 그룹과의 대화식 토론을 통해 요구를 도출한다.
• 심층 워크샵 : 핵심 이해 관계자간(태스크포스, 생산부, 마케팅 부서 등)의 요구사항 집중 토론을 통해 요구사항을 도출한다

 

 

 

---

 

 

 

요구사항 분석 시나리오

• 본 사이트는 작가의 글을 소개하는 사이트이다.
• 작가의 글을 소개하고 댓글을 달 수 있다.
• 하나의 글을 여러 작가가 쓸 수 있다.
• 글을 쓰고 싶다면 자기 소개글을 작성하여 작가로 등록하고 글을 쓸 수 있다. 

 

"품질이 좋은 SW는 Big Q와 Samll Q가 둘다 만족되어야 한다."

 

Biq Q 

- 고객의 만족

Small Q

- 결함이 없는 요구명세에 부합되는 소프트웨어

 

PROTOTYPING TOOL

https://ovenapp

OvenApp.io

 

 

+ 추가 요구사항 : 글쓰기 기능을 추가해주세요.

 

 

 

 

 

개발자는 자신의 의견을 프로토타입으로 전달할 수 있어야한다.

 

 

 

 

 

---

 

 

 

개념적 모델링

목표

• Eintity, 속성, 관계의 도출

 

정의

• 실세계에서 의미있는 개체를 도출하고 개체가 가지고 있는 속성을 파악하여 개체와 개체간의 관계를 도출해내는 모델링이다.
• 최종적 목표는 요구분석의 결과를 ERD(Entity-Relationship Diagram)으로 표현한다.

※ ERD(Entity-Relationship Diagram) : 개체와 속성의 관계도 표

 

▶ 개체(Entity)

정의

• 현실세계의 유형, 무형의 대상체를 추상화하여 표현하는 단위이다.
• 저장할 만한 가치가 있는 중요 데이터를 가지고 있는 사람이나 사물 등 가장 중요한 요소다.

특징

• 식별가능 : 유일한 식별자의 의해 식별이 가능하다. Unique 해야한다. Tracing이 가능해야한다.
• 영속성 : 업무에 필요한 정보가 영속적으로 존재한다.
• 관계성 : Entity간의 관계가 존재한다.

* Tracing : 추적하다.

* Entity occurrence/Entity instance : 실제적인 값이 들어가 있는 상태

 

 

▶ 속성

정의

• 개체가 가지고 있는 고유한 특성
• column 이자 data

유형

• 기본속성 : 개념단계에서 도출
• 설계속성 : 설계과정에서 도출
• 파생속성 : 계산결과나 파생으로부터 도출

 

▶ 관계

정의

• 개체와 개체가 맺고 있는 의미있는 연관성
• 관계는 속성을 가질 수 있다.
• table 이자 column 이자 data
• 기본적으로 업무분석을 통해 정답을 얻는다.

종류

• 1:1관계
• 1:n 관계
• n:m 관계

 

테이블 안에 있는 튜플과 튜플의 관계에 대한 이슈다.

 

 

 

 

관계의 종류

Cardinality

테이블의 관계는 업무분석 단계에서 증명된다.

테이블과 테이블의 관계에 대한 이슈는 관계성 존재의 유무 밖에 없다.

테이블 안에 있는 튜플과 튜플의 관계에 대한 이슈를 테이블과 테이블의 관계라고 한다.

table.tuple --- table.tuple 

3가지 관계 외의 다른 관계는 존재하지 않는다.

 

 

Optionality

저자와 댓글은 관계성이 존재한다.

저자 입장에서 댓글은 사용 할 수도 하지 않을 수 도 있다.

댓글입장에서 저자는 반드시 있어야 된다. (댓글이 달렸는데 저자가 NULL일 수 없다.)

left join, inner join

※ 이와 같은 상황에서는 Optional에 모든 값을 도출하려면 LEFT JOIN, Optioanl에 NULL값을 제외하려면 INNER JOIN을 사용한다.

 

 

최종 

저자와 댓글은 관계성이 존재한다.

저자 입장에서 댓글은 여러개 달린다.

댓글 입장에서 저자는 하나다.

저자 입장에서 댓글은 OPTION이다.댓글 입장에서 저자는 반드시 존재해야한다.

 

 

고객 - 구매 내역 - 제품의 ERD

 

 

 

 

 

관계는 결국 Foreign Key와 Primary Key로 제작된다.

 

 

 

 

---

 

 

 

 

 

 

 

개념적 모델링 수행

도구 - draw.io

https://app.diagrams.net/

Flowchart Maker & Online Diagram Software

 

단계

1. 엔티티 도출 : 수평적으로 엔티티를 도출한다.
2. 속성 도출 : 필요한 모든 속성을 도출한다.
3. 엔티티 조직 : 엔티티와 속성의 그룹핑
4. 관계 도출 : 엔티티와 엔티티의 관계를 도출한다.

 

 

 

 

 

---