728x90
반응형
1. 데이터 모델링의 이해
01. 데이터 모델링
- 현실 세계를 가상 공간인 데이터베이스로 표현하기 위해 추상화하는 것
- 데이터 모델링을 하기 위해서는 고객과의 의사소통을 통해 고객의 업무 프로세스를 완전히 이해해야 함
- 고객의 업무 프로세스를 이해하고 난 뒤에 데이터 모델링 표기법을 사용해서 모델링함.
- 고객이 쉽게 이해할 수 있도록 복잡하지 않게 모델링 되어야 함
- 고객의 업무 프로세스를 추상화하고, 소프트웨어를 분석, 설계해 가면서 점점 더 상세해짐
- 고객의 비지니스 프로세스를 이해하고 비지니스 프로세스의 규칙을 정의한다. 정의된 비지니스 규칙을 데이터 모델로 표현함.
🔍데이터 모델링 표기법
바커 표기법 (Baker Notation) - 영국 컨설팅 회사 CACI에서 처음 개발되었고 바커에 의해 지속적으로 발전되었다. 오라클의 Case Method로 채택되어 활용되고 있다.
I/E 표기법 (Infomation Engineering Notation) - 정보 시스템을 구축하는 데 있어 데이터 분석과 DB설계를 위해 유용한 기법이다. 때로 까마귀 발 모델이라고도 부른다
02. 데이터 모델링의 특징
데이터 모델링은 다음과 같은 세 가지 특징에 중점을 두고 만들어져야 한다.
- 추상화 ( Abstraction ) - 현실 세계의 공통점을 찾아 간략하게 표현한다
- 단순화 ( Simplification ) - 누구나 쉽게 이해할 수 있도록 표현한다
- 명확성 ( Clarity ) - 의미가 명확하며 한 가지 의미를 가져야 한다
02-2. 데이터 모델링의 세 가지 중요 개념
데이터 모델링을 구성하는 중요한 세 가지 개념이 있다. 이것은 데이터 모델에 대한 이해의 근간이 된다.
- 업무가 관여하는 어떤 것 (Things)
- 어떤 것이 가지는 성격 (Attributes)
- 업무가 관여하는 어떤 것 간의 관계 (Relationships)
위 세 가지 중요 개념은 각각 엔터티, 속성, 관계로 대응된다.
03. 데이터 모델링 단계
위의 데이터 모델링의 세 가지 특징에 중점을 두고 만들되, 어떤 절차에 따라 만들어야 하는가
- 개념적 모델링 ( Conceptual Data Modeling )
- 전사적이고 포괄적인 모델링을 수행
- 추상화 수준이 가장 높음
- 어떤 모델 이론에 관계없이 업무적인 측면에서만 모델링
- 논리적 모델링 ( Logical Data Modeling )
- 특정 데이터베이스 모델에 종속 = 어떤 데이터베이스를 사용할지 결정
- 식별자( Identifier ) 를 정의하고 관계 ( Relationship ), 속성 ( Attribute ) 등을 모두 표현
- 정규화를 통해 재사용성을 높임
- 물리적 모델링 ( Physical Modeling )
- 물리적인 성능과 데이터 저장을 고려한 설계 단계
- 추상화 수준이 가장 낮은 단계
- 성능, 보안, 가용성 등을 고려해 데이터베이스를 구축
04. 데이터 모델링 관점
데이터 모델링을 수행하는 세 가지 관점이 있다.
- 데이터 관점
- 데이터를 중심으로 데이터와 업무 간의 어떤 관련이 있는지, 데이터와 데이터 사이의 관계에 대해서 데이터 모델링을 수행하는 관점. 비지니스 프로세스에서 사용되는 데이터를 의미
- ex > 구조 분석, 정적 분석
- 프로세스 관점
- 실제 비지니스 프로세스에서 수행하는 프로세스를 중심으로 수행하는 관점
- 시나리오 분석, 도메인 분석, 동적 분석
- 데이터와 프로세스의 상관 관점
- 프로세스와 데이터 간에 어떤 영향을 주고 받는지 그러한 상관 관계를 중심으로 수행하는 관점
- CRUD분석
05. ERD ( Entity Relationship Diagram )
피터첸이 만든 표기법으로 사실상 데이터 모델링의 표준으로 사용되고 있다. 엔터티와 엔터티 간의 관계를 정의하는 모델링 방법
(1) ERD 작성 절차
- 엔터티를 도출하고 그린다
- 엔터티를 배치한다
- 엔터티를 도출한 후 엔터티를 배치한다
- 중요한 엔터티는 왼쪽 상단에 배치한다
- 엔터티 간의 관계를 설정한다
- 관계명을 서술한다
- 고객은 계좌를 개설한다 등
- 관계 참여도를 표현한다
- 관계의 필수 여부를 표현한다
- 까마귀 발과 같은 표기법을 이용해 관계가 필수인지 아닌지, 참여도는 어떠한지 등을 표기한다
(2) ERD 작성 시 고려사항
- 중요한 엔터티는 가급적 왼쪽 상단으로
- ERD는 이해하기 쉬워야 하고 복잡하지 않아야 한다
2. 3층 스키마 ( 3-Level Schema )
01. 3층 스키마
- 사용자, 설계자, 개발자가 데이터를 보는 관점에 따라 데이터베이스를 기술하고 이들 간의 관계를 정의한 ANSI표준
- 데이터베이스의 독립성을 확보하기 위한 방법
- 데이터의 독립성을 확보하면 데이터 복잡도 감소, 데이터 중복 제거, 사용자 요구사항 변경에 따른 대응력 향상, 관리 및 유지보수 비용 절감 등의 장점을 가짐
- 3단계 계층으로 분리해 독립성을 확보하는 방법으로 각 계층을 뷰(View)라고도 함
🔍ANSI ( American National Stardards Institute, 미국표준협회 )
ANSI SQL 표준은 SQL문이 모든 데이터베이스관리시스템에서 호환되도록 정의한 표준이다
02. 3층 스키마 구조
- 외부 스키마 ( External Schema )
- 사용자 관점, 업무상 관련이 있는 데이터 접근
- 관련 데이터베이스의 뷰(View)를 표시
- 응용 프로그램이 접근하는 데이터베이스를 정의
- 개념 스키마 ( Conceptual Schema )
- 설계자 관점, 사용자 전체 집단의 데이터베이스 구조
- 전체 데이터베이스 내의 규칙과 구조를 표현
- 통합 데이터베이스 구조
- 내부 스키마 ( Internal Schema )
- 개발자 관점, 데이터베이스의 물리적 저장 구조
- 데이터 저장 구조, 레코드 구조, 필드 정의, 인덱스 등을 의미
🔍3층 스키마의 독립성
- 논리적 독립성 - 개념 스키마가 변경되더라도 외부 스키마가 영향을 받지 않는 것
- 물리적 독립성 - 내부 스키마가 변경되더라도 개념 스키마가 영향을 받지 않는 것
3. 엔터티 ( Entity )
01. 엔터티
- 업무에서 관리해야 하는 데이터 집합. 저장되고 관리되어야 하는 데이터. 즉, 어떤 개념, 사건, 장소 등의 한 개체를 의미한다. 인스턴스들의 집합
02. 엔터티 특징
- 식별자 ( Identifier )
- 엔터티는 유일한 식별자가 있어야 함
- 식별자는 물리적 데이터 모델링 단계에서의 키(Key)의 역할이지만 논리 데이터 모델링 단계에서 사용하는 용어
- ex > 회원ID, 계좌번호
- 인스턴스 집합
- 2개 이상의 인스턴스가 있어야 함
- 인스턴스는 스키마에 대한 실제 데이터로, 테이블의 각 행을 의미한다
- 즉, 회원ID 등의 고객 정보는 2개 이상이 있어야 함
- 속성
- 한 개의 엔터티는 반드시 두 개 이상의 속성을 가지고 있음
- ex > 고객 엔터티에 회원ID, 패스워드, 이름, 주소, 전화번호 등
- 관계
- 다른 엔터티와 최소한 한 개 이상 관계가 있어야 함
- ex > 고객은 계좌를 개설한다
- 업무
- 업무에서 관리되어야 하는 집합임
- ex > 고객, 계좌
03. 엔터티 종류
엔터티는 유형과 무형에 따른 종류, 엔터티가 발생하는 시점에 따른 종류로 나눌 수 있다.
- 유형과 무형에 따른 종류
| 종류 | 설명 |
| 유형 엔터티 | - 업무에서 도출되며 지속적으로 사용되는 엔터티 - ex > 고객, 강사, 사원 등 |
| 개념 엔터티 | - 유형 엔터티는 물리적 형태가 있지만, 개념 엔터티는 물리적 개념이 없음 - 개념적으로 사용되는 엔터티 - ex > 거래소 종목, 코스닥 종목, 생명보험 상품 |
| 사건 엔터티 | - 비즈니스 프로세스를 실행하면서 생성되는 엔터티 - ex > 주문, 체결, 취소주문, 수수료 청구 등 |
- 발생 시점에 따른 종류
| 종류 | 설명 |
| 기본 엔터티 (Basic Entity) |
- 키 엔터티 - 다른 엔터티로부터 영향을 받지 않고 독립적으로 생성되는 엔터티 - ex > 고객, 상품, 부서 등 |
| 중심 엔터티 (Main Entity) | - 기본 엔터티와 행위 엔터티 간의 중간에 있는 것 - 즉, 기본 엔터티로부터 발생되고 행위 엔터티를 생성 - ex > 계좌, 주문, 취소, 체결 등 |
| 행위 엔터티 (Active Entity) | - 2개 이상의 엔터티로부터 발생 - ex > 주문 이력, 체결 이력 등 |
4. 속성 ( Attribute )
01. 속성
- 업무에서 필요한 정보인 엔터티가 가지는 항목
- 더 이상 분리되지 않는 단위로, 업무에 필요한 데이터를 저장할 수 있음
- 인스턴스의 구성요소이며 의미적으로 더 이상 분해되지 않음
02. 속성의 특징과 종류
특징
- 업무에서 관리되는 정보
- 일반적으로 하나의 값만을 가짐
- 주식별자에게 함수적으로 종속됨. 즉, 기본키가 변경되면 속성의 값도 변경됨
종류
- 분해 여부에 따른 속성의 종류
| 종류 | 설명 |
| 단일 속성 |
- 하나의 의미로 구성된 속성 - ex > 회원ID, 이름 등 |
| 복합 속성 | - 여러 개의 의미로 구성된 속성 - ex > 주소. 주소는 시, 군, 동 등으로 분해될 수 있음 |
| 다중값 속성 | - 여러 개의 값이 들어가는 속성 - 다중값 속성이 있을 경우 새로운 엔터티를 생성해서 다중값을 없애야 함 |
- 특성에 따른 속성의 종류
| 종류 | 설명 |
| 기본 속성 | - 비즈니스 프로세스에서 도출되는 현실 세계 본래의 속성 - ex > 회원ID, 이름, 계좌번호, 주문 일자 등 |
| 설계 속성 | - 데이터 모델링 과정에서 발생되는 속성 - 유일한 값을 부여해 새로 만든다 - ex > 상품코드, 지점 코드 등 |
| 파생 속성 | - 다른 속성에 의해서 만들어지는 속성 - ex > 합계, 평균 등 |
🔍 도메인 (Domain)
- 어떤 속성이 가질 수 있는 값의 범위
- ex > 성별이라는 속성의 도메인은 남자, 여자이다.
5. 관계 ( Relationship )
01. 관계
- 엔터티 간의 관련성을 의미, 존재 관계와 행위 관계로 분류됨
02. 관계의 종류
- 존재 관계
엔터티 간의 상태를 의미한다
예를 들어 어떤 사원이 어떤 팀에 '소속된다'라는 의미는 행위(이벤트)에 의해 발생되는 것이 아니라 실제로 팀에 소속되어 있기 때문에 존재에 의해 형성된 의미이다.
- 행위 관계
엔터티 간의 어떤 행위가 있는 것
어떤 계좌를 개설하고 주문을 발주하는 등의 행위로 인해 관계가 형성된 경우이다.
03. 관계의 표기법
관계를 표기할 때는 아래와 같이 3가지 개념에 대해서 함께 표현한다
03-1. 관계명 (Membership)
- 관계명은 엔터티가 관계에 참여하는 형태를 지칭함
- 관계는 2개의 엔터티에 의해 발생하므로 하나의 관계는 2개의 관계명을 가지며, 각각의 관계명에 따라 하나의 관계가 두가지 관점으로 표현될 수 있음
- 엔터티에서 관계가 시작되는 쪽은 관계시작점이라고 부르고, 관계가 끝나는 쪽을 관계끝점이라고 함
명명규칙
- 애매한 동사를 피하기
- 현재형으로 표현하기
ex > 관련있다, 관계된다. 같은 표현은 구체적이지 않아 두 엔터티 간에 어떤 행위/상태가 존재하는지 파악하기 어렵다.
ex > 주문을 했다. 신청을 했다. 와 같은 표현은 사용되지 않고 주문한다, 신청한다와 같이 표현한다
03-2. 관계 차수 ( Ralation Cardinality )
- 두 개의 엔터티 간에 관계에 참여하는 수
03-3. 관계선택
- 엔터티가 항상 관계에 참여하는지, 혹은 선택적으로 관계에 참여할 수 있는 것인지에 대한 사항
- 항상 관계에 참여하는 것을 필수 참여(Mandatory Membership), 선택적으로 관계에 참여할 수 있는 것을 선택 참여(Optional Membership)이라고 함
03-4. 관계 체크사항
두 개의 엔터티 사이에서 관계를 정의할 때는 다음과 같은 사항들을 체크해야 함
- 두 개의 엔터티 사이에 관심있는 연관 규칙이 존재하는가?
- 두 개의 엔터티 사이에 정보의 조합이 발생하는가?
- 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
- 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?
04. 식별 관계와 비식별 관계
식별 관계 ( Identification Relationship )
- 독립적으로 존재할 수 있는 강한 개체(Strong Entity)
- 강한 개체는 다른 엔터티에 의존하지 않고 독립적으로 존재
- 강한 개체는 다른 엔터티와 관계를 가질 때 다른 엔터티에게 기본키를 공유함
- 실선으로 표현됨
비식별 관계 ( Non-Identification Relationship )
- 강한 개체의 기본키를 다른 엔터티의 기본키가 아닌 일반 칼럼으로 관계를 가지는 것
- 점선으로 표현됨
6. 엔터티 식별자 ( Entity Identifier )
식별자란 엔터티를 대표할 수 있는 유일성을 만족하는 속성. 예로 회원ID, 계좌번호, 주민등록번호, 외국인등록번호, 여권번호 등이 있음
01. 주식별자(기본키, Primary Key, PK)
- 최소성 - 최소한의 속성으로 튜플을 구분지을 수 있는 키이어야 한다 예를 들어 (주민등록번호, 이름), (주민등록번호, 이름, 주소) 들도 각 개개인을 구분지을 수 있지만, (주민등록번호)하나만으로 각 개개인을 구분지을 수 있으므로 최소성을 만족하는 주식별자는 주민등록번호
- 대표성 - 엔터티를 대표할 수 있는 속성
- 유일성 - 엔터티의 인스턴스를 유일하게 구분지어 식별할 수 있는 속성
- 불변성 - 자주 변경되지 않는 속성
키의 종류
| 데이터베이스 키 | 설명 |
| 기본키(Primary Key) | - 후보키 중에서 엔터티를 대표할 수 있는 키 |
| 후보키(Candidate Key) | - 유일성과 최소성을 만족하는 키 |
| 슈퍼키(Super Key) | - 유일성은 만족하지만 최소성을 만족하지 않는 키 |
| 대체키(Alternate Key) | - 여러 개의 후보키 중에서 기본키를 선정하고 남은 키 |
| 외래키(Foreign Key) | - 하나 혹은 하나 이상의 다른 테이블의 기본키 필드를 가리키는 것으로 참조 무결성을 확인하기 위해 사용하는 키 - 허용된 데이터 값만 데이터베이스에 저장하기 위해 사용함 |
02. 식별자의 종류
대표성, 생성 여부, 속성의 수, 대체 여부로 각각 종류를 구분지을 수 있음
대표성 여부에 따른 종류
| 종류 | 설명 |
| 주식별자 | - 유일성과 최소성을 만족하면서 엔터티를 대표하는 식별자 (+ Not Null) - 다른 엔터티와 참조 관계로 연결될 수 있음 |
| 보조 식별자 | - 유일성과 최소성은 만족하지만 대표성을 만족하지 못하는 식별자 |
생성 여부에 따른 종류
| 종류 | 설명 |
| 내부 식별자 | - 엔터티 내부에서 스스로 생성되는 식별자 - ex > 부서코드, 주문번호, 종목코드 등 |
| 외부 식별자 | - 다른 엔터티와의 관계로 인해 만들어지는 식별자 - ex > 계좌 엔터티에 회원 ID |
속성의 수에 따른 종류
| 종류 | 설명 |
| 단일 식별자 | - 하나의 속성으로 구성 - ex > 고객 엔터티에 회원ID |
| 복합 식별자 | - 두 개 이상의 속성으로 구성 |
대체 여부에 따른 종류
| 종류 | 설명 |
| 본질 식별자 | - 비즈니스 프로세스에서 만들어지는 식별자 |
| 인조 식별자 | - 인위적으로 만들어지는 식별자 - 후보 중에서 주식별자로 선정할 것이 없거나 너무 많은 칼럼으로 이루어져 있는 경우 새로운 식별자를 만들어서 부여하는 것 |
반응형
'프로그래밍 > DataBase' 카테고리의 다른 글
| [SQLD] SQL 기본 및 활용 Section 01. SQL 기본 (1) SQL기초와 DDL까지 (0) | 2023.08.26 |
|---|---|
| [SQLD] 데이터 모델링의 이해 Section 02. Data Model and Performance (0) | 2023.08.23 |
| [MySQL] 03. 데이터 타입 - 숫자 타입 (0) | 2023.02.25 |
| [MySQL] 02. 명령어(1) (기본 명령어) (0) | 2023.02.24 |
| [MySQL] 01. Introduction (0) | 2023.02.24 |