SQLD

(1과목) 데이터 모델링의 이해

Zoo_10th 2024. 4. 16.

1. 데이터 모델의 이해

1-1. 모델링의 특징

컴퓨터에 데이터를 넣는다고 생각을 하면

1) 추상화(Abstraction)

현실 세계를 일정한 형식으로 표현하는 것이다. 즉 아이디어나 개념을 간략하게 표현하는 과정이다.

2) 단순화(Simplification)

복잡한 현실 세계를 정해진 표기법으로 단순하고 쉽게 표현한다는 의미이다.

3) 명확화(clarity)

불분명함을 제거하고 명확하게 해석할 수 있도록 기술한다는 의미이다.

1-2. 모델링의 세 가지 관점

1) 데이터 관점(What, Data)

데이터 위주의 모델링이라고 할 수 있다. 어떤 데이터들이 업무와 얽혀있는지, 그리고 그 데이터간에는 어떤 관계가 있는지에 대해서 모델링하는 방법이다.

2) 프로세스 관점 (How, Process)

프로세스 위주의 모델링이라고 할 수 있다. 업무가 실제로 처리하고 있는 일은 무엇인지 또는 앞으로 철리해야하는 일은 무엇인지 모델링하는 방법이다.

3) 데이터와 프로세스의 상관 관점(Data cv. Process, Interaction)

데이터와 프로세스의 관계를 위주로 한 모델링이라고 할 수 있다. 프로세스의 흐름에 따라 데이터가 어떤 영향을 받는지를 모델링하는 방법이다.

1-3. 모델링 유의사항

데이터의 품질(데이터의 신뢰도, 정확성 등을 나타내는 척도)을 보장하기 위해 데이터 모델링시 다음 사항에 유의해야 한다.

1) 중복(Duplication)

같은 데이터가 여러 엔터티에 중복으로 저장되는 현상을 지장해야 한다.

2) 비유연성(Inflexibility)

데이터 모델의 설계에 따라 애플리케이션의 사소한 변경에도 데이터 모델이 수시로 변경되어야 하는 상황이 생길 수 있다. 이런 상황은 시스템을 유지보수하는 데에 어려움을 가중시키므로 데이터 모델과 프로세스를 분리하여 유연성을 높이는 것이 바람직하다.

3) 비일관성(Inconsistency)

데이터의 중복이 없는 경우에도 비일관성이 발생할 수 있다. 개발자가 다른 데이터와의 연관성을 고려하지 않고 일부 데이터만 변경할 수 있기 때문이다. 이런 위험을 예방하기 위해 데이터 모델링을 할 때 데이터 간의 연관 관계에 대해 명확하게 정의해야 한다.

1-4. 모델링의 세가지 단계

1) 개념적 데이터 모델링(Conceptual Data Modeling)

전사(회사 전체 차원의)적 모델링 수행 시 행해지며 추상화 레벨이 가장 높은 모델링이다. 이 단계에서는 업무 중심적이고 포괄적인 수준의 모델링이 진행된다.

ex) 개념적으로만 추상화(생각, 계획)

2) 논리적 데이터 모델링(Logical Data Modeling)

재사용성이 가장높은 모델링으로 데이터베이스 모델에 대한 Key, 속성, 관계 등을 모두 표현하는 단계이다.

ex) 연결을 담당

3) 물리적 데이터 모델링(Physical Data Modeling)

실제 데이터베이스로 구현할 수 있도록 성능이나 가용성 등의 물리적인 성격을 고려하여 모델을 표현하는 단계이다.

ex) 실제로 구현

1-5. 데이터의 독립성

1) 3단계 스키마 구조

① 외부 스키마(External Schema)

사용자의 관점 : Multiple User`s View 단계로 각 사용자가 보는 데이터 베이스의 스키마를 정의한다.

② 개념 스키마(Conceptual Schema)

통합된 관점 : Community View of DB 단계로 모든 사용자가 보는 데이터베이스의 스키마를 통합하여 전체 데이터베이스를 나타내는 것이다. 데이터 베이스에 저장되는 데이터들을 표현하고 데이터들 간의 관계를 나타낸다.

③ 내부 스키마(Internal Schema)

물리적인 관점 : Physical Representation 단계로 물리적인 저장 구조를 나타낸다. 실질적인 데이터의 저장구조나 컬럼 정의, 인덱스 등이 포함된다.

2) 3단계 스키마 구조가 보장하는 독립성

ANSI-SPARC 아키텍처에서 이렇게 스키마를 3단계 구조로 나누는 이유는 데이터베이스에대한 사용자들의 관점과 데이터 터베이스가 실제로 표현되는 물리적인 방식을 분리하여 독립성을 보장하기 위한 것이다.

논리적 독립성 : 개념 스키마가 변경되어도 외부 스키마는 영향을 받지 않는다.

물리적 독립성 : 내부 스키마가 변경되어도 외부/개념 스키마는 영향받지 않는다.

1-6. ERD(Entity Relationship Diagram)

시스템에 어떤 엔터티들이 존재하며 그들 간의 어떤 관계가 있는지를 나타내는 다이어그램이다.

1) ERD 표기 방식

① Peter Chen : 주로 대학교재에서 사용하는 표기법으로 실무에서 사용하는 경우는 드물다.

② IDEF1X(Integration Definition for Information Modeling) : 실무에서 사용하는 경우도 있으며 ERWin에서 사용되는 모델이기도 하다.(ERWin은 ERD를 그리는 모델링 툴)

색으로 구분한다.

③ IE/Crow`s Foot : 까마귀 발 표기법이라고도 부르며 가장 많이 사용한다. ERWin, ERStudio에서 사용되는 모델이다.

(ERWin, ERStudio는 ERD를 그리는 모델링 툴)

④ Min-Max/ISO : 각 엔터티의 참여도를 좀 더 상세하게 나타내는 표기법이다.

⑤ UML : 소프트웨어 공학에서 주로 사용되는 모델이다.

⑥ case*Method/barker : Oracle에서 사용되는 모델로 Crow`s Foot과 비슷하다.

2) IE/Crow`s Foot 표기법

기호 의미
엔터티
0개
1개
2개 이상
부모 엔터티의 식별자가 자식 엔터티의 주식별자(주식별자 관계)
부모 엔터티의 식별자가 자식 엔터티의 일반 속성(비식별자 관계)

2. 엔터티(Entity)

2-1. 엔터티란

식별이 가능한 객체라는 의미를 가지고 있다.(테이블)

2-2. 엔터티의 특징

1) 업무에서 쓰이는 정보여야 한다.

실질적으로 업무에서 쓰이는 정보여야 엔터티로 도출하는 의미가 있다. 

2) 유니크함을 보장할 수 있는 식별자가 있어야 한다.

엔터티에 속한 각각의 인스턴스가 중복되거나 식별이 모호하면 이 엔터티는 설계가 잘못된 것이다.(PK)

3) 2개 이상의 인스턴스를 가지고 있어야 한다.

인스턴스가 1개만 존재하고 앞으로도 쭉 1개만 존재할 예정이라면 이것은 엔터티로 볼 수 없다.

4) 반드시 속성을 가지고 있어야한다.

속성 없는 엔터티는 빈박스와 같다. 엔터티는 반드시 자신을 상세하게 나타낼 수 있는 속성을 가지고 있어야 한다.

5) 다른 엔터티와 1개 이상의 관계를 가지고 있어야 한다.

각각의 엔터티는 다른 엔터티와의 연관성을 가지고 있어야 한다.

2-3. 엔터티의 분류

1) 발생시점

기본 엔터티  - 업무에 원래 존재하는 정보
 - 독립적으로 생성되며, 자식 엔터티를 가질 수 있다.
ex) 상품, 회원, 사원, 부서 등
중심 엔터티  - 기본 엔터티로부터 파생되고, 행위 엔터티 생성
 - 업무에 있어서 중심적인 역할을 하며 데이터의 양이 많이 발생한다.
ex) 주문, 매출, 계약 등
행위 엔터티  - 2개 이상의 엔터티로부터 파생한다.
 - 데이터가 자주 변경되거나 증가할 수 있음
ex) 주문 내역, 이벤트 응모 이력

2) 엔터티의 이름을 정할 때 주의할 점

 - 업무에서 실제로 쓰이는 용어 사용

 - 한글은 약어를 사용하지 않고 영문은 대문자로 쓰기

 - 단수 명사로 표현하고 띄어쓰기는 하지 않는다.

 - 다른 엔터티와 의미상으로 중복될 수 없다(주문, 결제 엔터티는 중복될 수 있다.)

 - 해당 엔터티가 갖고 있는 데이터가 무엇인지 명확하게 표현한다.

3. 속성(Attribute)

3-1. 속성이란

엔터티의 특징을 나타내는 최소의 데이터 단위이다. 속성 안에 속성은 존재하지 않는다.

3-2. 엔터티, 인스턴스, 속성, 속성값의 관계

한개의 엔터티는 두개 이상의 인스턴스를 갖고 한개의 인스턴스는 두개 이상의 속성을 가지며, 한개의 속성은 하나의 속성값을 가진다.

엔터티 ⊃ 인스턴스 ⊃ 속성의 관계가 성립하는데 각각의 표기법으로 나타내면 다음과 같다.

3-3. 분류

1) 특성에 따른 분류

기본속성(Basic Attribute) 업무 프로세스 분석을 통해 바로 정의가 가능한 속성
설계속성(Designed Attribute) 업무에 존재하지는 않지만 설계하다보니 필요하다고 판단되어 도출해낸 속성
파생속성(Derived Attribute) 다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성

① 기본 속성 : 엔터티의 가장 일반적인 속성으로 업무 프로세스 분석을 통해 바로 정의가 가능한 속성들이다. 엔터티의 가장 많은 퍼센티지를 차지하는 속성이며 일부 설계속성과 파생속성을 제외한 모든 속성이 기본 속성에 해당한다.

② 설계속성 : 업무에 존재하지는 않지만 설계과정에서 합리적인 모델링을 위해 만들어진 속성이다.

ex) 학번, 주민번호 등 개개인의 고유한 값을 할당함에 인스턴스에 유니크함을 부여한다.

③ 파생속성 : 다른 속성으로부터 파생된 속성을 의미하는 것으로 계산된 값이나 가공된 값이 이에속한다. 파생속성을 설계할 경우 반드시 데이터의 정합성이 고려되어야 하고 계산과정에서 누락되는 데이터가 생기는 경우 결과 값이 엉터리가 될 수 있는 위험 요소가 존재하기 때문에 불가피하게 필요한 경우에만 정의한다.

3-4. 도메인(Domain)

속성이 가질 수 있는 속성값의 범위이다. 엔터티를 정의할 때 데이터 타입과 크기로 나타낼 수 있다.

4. 관계

4-1. 관계란

엔터티와의 관계를 의미한다. 연관성이 있는지 타입을 분류하여 존재 관계와 행위 관계로 나눌 수 있다.

4-2. 존재 관계

존재 자체로 연관성이 있는 관계를 의미하다. 예를 들면 직원과 부서, 학생과 학과, 자식과 부모, 회원과 동호회

4-3. 행위 관계

특정 행위로 인해 연관성이 생기는 관계이다. 예를 들면 고객과 주문, 학생과 출석부

4-4. 표기법

1) 관계명(Membership)

엔터티와 엔터티가 어떠한 관계를 맺고 있는지를 나타내주는 문장이다. 모든 관계는 두 개의 관계명을 가지고 있는데 이유는 각 엔터티의 관점에서 관계명을 하나씩 가지고 있기 때문이다.

관계명은 반드시 명확한 문장으로 표현해야 하며 현재형이여야 한다.

옳지 않은 관계명 옳은 관계명
연관성이 있다.
관계가 있다.
출석을 했다.
주문한다.
소속된다.
출석을 한다.

2) 관계차수(Cardinality)

각 엔터티에서 관계에 참여하는 수를 의미하며 일반적으로 1:1, 1:M(1대다), N:M(다대다) 형식으로 구분할 수 있다.

1:1 관계
1:M 관계
N:M 관계

3) 관계선택사양(Optionality)

관계선택사양은 필수요소인지 선택사항인지를 나타내는 말이다. 

 

728x90

'SQLD' 카테고리의 다른 글

(1과목) 데이터 모델과 SQL  (0) 2024.04.18

댓글