SQLD 대비 (1) - 데이터 모델의 이해

시험이 2주일도 안남았다. 이론문제를 간단히 정리하고 노랭이 책을 풀고 오답노트를 이용해 시험을 대비해볼 생각이다.

교과목 수업으로 데이터베이스를 배운 경험이 있고 프로그래머스에서 SQL문제를 여러 개 풀어보았다. 그래도 시간이 없으니 불안하다.

일단 준비해보자.

 

아래 유튜브 영상을 참고하여 공부하였습니다. 문제 시 삭제하겠습니다.

빨간색 형광펜은 강의에서 강조한 부분, 노란색 형광펜은 추가 서치로 내용을 '직접' 보강한 부분입니다.

https://www.youtube.com/watch?v=gmMaH5mMJ9M&t=433s

1. 데이터 모델링의 정의

• 고객과 함께 고객의 업무 프로세스를 이해해야 데이터 모델링을 제대로 할 수 있다.
• 현실 세계를 데이터베이스에서 표현하기 위한 추상화 과정이다.
• 데이터 모델링 표기법을 사용해서 모델링 한다.
• 고객의 업무 프로세스내 비즈니스 규칙을 정의하여 데이터 모델로 표현 할 수 있어야 한다.
• 고객이 이해하기 쉽게 간결하게 모델링 해야한다.

*데이터 모델링을 해야하는 주요한 이유

1. 업무정보를 구성하는 기초가 되는 정보들에 대해 "일정한 표기법"에 의해 표현함으로써 정보시스템 구축의 대상이 되는 업무 내용을 정확하게 분석하는 것이 첫 번째 목적

2. 분석된 모델을 가지고 실제 데이터베이스를 생성하여 개발 및 데이터 관리에 사용하기 위한 것이 두 번째 목적.

 

*데이터 모델링을 할 때 유의할 사항

• 중복 (Duplication)
  데이터 모델은 같은 데이터를 사용하는 사람, 시간, 그리고 장소를 파악하는데 도움을 줌으로써 데이터베이스가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 해야한다.
  
  
• 비유연성(Inflexibility)
  데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무 변화에도 데이터 모델이 수시로 변경됨으로써 유지보수의 어려움을 가중시킬 수 있다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.
• 비일관성(Inconsistency)
  데이터의 중복이 없더라도 비일관성은 발생할 수 있는데, 예를 들면 신용 상태에 대한 갱신 없이 고객의 납부 이력  정보를 갱신하는 경우이다. 개발자가 서로 연관된 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문에 이와 같은 문제가 발생할 수 있다. 데이터 모델링을 할 때 데이터와 데이터 간의 상호 연관 관계에 대해 명확하게 정의한다면 이러한 위험을 사전에 예방하는데 도움을 줄 수 있다.
  사용자가 처리하는 프로세스 혹은 이와 관련된 프로그램과 테이블의 연계성을 높이는 것은 데이터 모델이 업무 변경에 대해 취약하게 만드는 단점에 해당한다.

 

2. 데이터 모델링의 특징 (추단명)

추상화(Abstract)	현실 세계를 일정한 양식(표기법)에 맞게 간략하게 표현한다. (단순화랑 헷갈리지 말것)
단순화(Simplification)	누구나 이해하기 쉽도록 약속된 규약에 의한 제한된 표기법 또는 언어를 이용하여 표현한다.
명확화(Clarity)	명확하게 의미가 한 가지로 해석되어야 함으로 애매모호함을 제거하고 정확하게 현상을 기술한다.

 

3. 데이터 모델링의 단계 (개눈물)

개념적 모델링 (고객, 가게 저장하자!) 어떻게 모델을 만들래?	논리적 모델링 Oracle로? MySQL로? 고객은 전화번호, 이메일 주소등을 받아야겠다.	물리적 모델링 : 최종 틀 완성하기, 물리적 모델링이 완성되면 바로 DB 구축 가능
추상화 수준이 가장 높음	특정 데이터베이스 모델에 종속된다.	물리적인 성능과 데이터 저장을 고려한 설계
업무 측면의 모델링	세부속성, 식별자, 관계등을 정확하게 표현	가장 구체적인 데이터 모델링
전사적이고 포괄적인 모델링	데이터 정규화 완재료	추상화 수준이 가장 낮은 단계
핵심 엔터티 도출 (손님이 핵심이냐, 가게가 핵심이냐)	재사용성이 높음	성능, 보안, 가용성을 고려한 데이터베이스 모델링 진행
ERD작성

 

4. 데이터 모델링의 3가지 관점 (설명을 보고 알 수 있음)

• 데이터 관점
  • 데이터와 업무 간의 어떤 관련이 있는지, 데이터와 데이터 사이의 관계가 무엇인지에 따라 모델링 한다.
  • 비즈니스 프로세스에서 사용되는 데이터를 의미한다.
  • 구조분석 정적 분석
• 프로세스 관점
  • 실제 하는 업무에 따라 무엇을 어떻게 하는지 모델링 한다. 비즈니스 프로세스에서 수행하는 작업을 의미한다.
  • 시나리오 분석, 도메인 분석, 동적 분석
• 데이터와 프로세스의 상관관점
  • 업무의 처리(프로세스)와 데이터 간의 서로 어떤 영향을 주고 받는지를 모델링 한다. 프로세스와 데이터 간의 관계를 의미한다.
  • CRUD (Create, Read, Update, Delete)

5. 데이터 모델링을 위한 ERD (Entity Relationship Diagram) ★★★

1976년 피터 첸(Peter Chen)이 만든 표기법으로, 데이터 모델링의 표준으로 지금까지 사용되고 있음.

• 대표적인 표기법 - Chen, IE/Crow's Foot, Barker UML
• ERD를 작성하는 순서 (추후 자세히)
  • 1. 엔터티 도출
  • 2. 엔터티 배치
  • 3. 엔터티 관계 설정
  • 4. 관계명 기술
  • 5. 관계 참여도 기술
  • 6. 관계 필수 여부 기술

6. 3단계 구조 스키마(3-Level Schema)

• 데이터베이스의 독립성을 위해 3단계 구조 스키마 존재한다.
• 사용자(외부 스키마), 설계자(내부 스키마), 개발자(개념 스키마)의 각기 관점에 따라 데이터베이스를 기술하고 이들 간의 관계를 ANSI표준으로 정했다.
• 데이터의 독립성 확보를 통해서 데이터 복잡도 감소, 데이터 중복 제거, 사용자 요구사항 변경에 따른 대응력 향상, 관리 및 유지보수 비용 절감 등의 장점이 생긴다.
• 각 계층을 뷰(View)라고 부르며 3단계 계층으로 분리되어 서로 독립성을 확보한다.

7. 데이터베이스 3단계 구조 특징 ★★★

(DB를 바라볼때의 시선 3가지)

외부 스키마 (외부 단계)	- 데이터베이스의 개별 사용자 관점의 이해와 표현
	- 응용프로그램이 접근하는 데이터베이스 (사용자가 배민에서 명령어로 가게 조회하는게 아닌것처럼!)
	- 여러 개의 외부 스키마 존재
개념 스키마 (개념 단계)	- 데이터베이스 관리자의 관점으로 규칙과 구조 표현
	- 데이터베이스의 전체적인 논리구조
	- 일반적으로 스키마는 개념 스키마를 지칭함
내부 스키마 (내부 단계)	- 데이터베이스 시스템의 설계자 관점 (개발자)으로 저장 장치 관점의 이해 및 표현
	- 데이터가 실제로 데이터베이스에 물리적으로 어떻게 저장되는지 확인

 

다음글 보기

2023.11.11 - [SQL/SQLD] - SQLD 대비 (2) - 엔터티(Entity)와 속성(Attribute), 관계(Relationship)

SQLD 대비 (2) - 엔터티(Entity)와 속성(Attribute), 관계(Relationship)