[ SQLD ] 데이터 모델링의 이해 240728

데이터 모델의 구성요소에서 Entity의 표준 표기법은 '엔터티'  다.

모델링은 모델을 만드는 것이다.

모델링 → 복잡한 현실세계를 추상화, 단순화하여 일정한 표기법에 의해 명확하게 표현하는 것이다.

모델링은 일반적으로 그림으로 표현하고, 모델링의 핵심은 추상화, 단순화, 명확화다.

( 모델링은 구체화, 복잡화, 일반화 등이 아니다 )

모델링에서 추상화는 중요도에 따라 중요한 부분은 강조하고,

덜 중요한 부분은 표현하지 않는 것이다.

 

모델링의 결과로 모델 ( Model ) 이 나옴

→ 모델은 현실 세계를 추상화 ( 모형화 ) 하여 반영한 것이다.

 

모델링의 관점

 

현실 세계를 추상화, 단순화하여 일정한 표기법에 의해 명확하게 표현할 건데

1) 데이터간의 관계를 나타내는 데이터 ( 관점의 ) 모델링 ( WHAT )

→ 데이터와 데이터간의 관계, 업무와 데이터간 관계를 모델링 ( → 프로세스에서 사용하는 데이터를 모델링 )

→ 데이터 모델링은 데이터에 접근하는 방법 ( HOW ), 사람 ( WHO ) 과는 무관하다.

2) 데이터에 접근하는 방법 ( 업무가 실제로 하고 있는 일 또는 해야할 일을 나타내는 프로세스 관점 ( HOW )

3) 업무 처리 방법에 따라 데이터가 받는 영향을 나타내는 데이터와 프로세스의 상관 관점 ( Interaction ) 이 있다.

 

데이터 ( 관점의 ) 모델링의 3단계

모델링 3단계에 관한 학계와 산업계의 비교

 

차이는

학계에서는 개념적, 논리적 모델링을 정확히 구분

→ 개념적 모델링은 엔터티와 관계 ( Relationship ) 를 명확하게 나타내어 ER 다이어그램 ( ERD ) 으로 표현

→ ER 다이어그램을 기반으로 논리적 모델링을 하여 릴레이션간 관계 ( Relation Model ) 를 나타낸다. 

논리적 모델링 단계에서 릴레이션 ( 테이블 ) 을 도출한다.

 

산업계에서는 개념적, 논리적 모델링을 구분하지 않고 수행하는데 ( 똑같이 ER 다이어그램으로 표현 ),

추상화 정도에 따라서 구분되는데 개념적 모델링보다 논리적 모델링이 좀 더 구체화된 것이다.

물리적 모델링에서 릴레이션 ( 테이블 ) 을 도출한다.

 

구분	학계	산업계
개념적 모델링	ERD ( Entity RelationShip Diagram ) 도출 주로 Chen 타입의 ERD 사용 관계 ( Relationship ) 가 자체 속성을 가질 수 있다.	핵심 엔터티 / 관계 / 속성 중심의 ERD 를 도출한다. 추상화 수준이 높다. 주로 IE / Crow's Foot 타입의 ERD 를 사용한다. 관계 ( Relation ) 가 자체 속성을 가질 수 없다. → IE / Crow's Foot 타입의 ERD 경우, 관계를 선으로 나타내기 때문에 관계 자체가 속성을 가질 수 없다.
논리적 모델링	( ERD 로부터 ) 릴레이션 ( 테이블 ) 도출 PK ( Primary Key, 기본 키, 주 키 )와 FK ( Foreign Key, 외래키, 외부키 ) 지정  ( 릴레이션을 깔끔하게 하기 위해서 ) 정규화 및 반정규화를 수행한다.	( 개념적 모델링에서의 ERD 보다 ) 훨씬 구체적인 수준의 ERD 를 도출한다. 시스템으로 구축하고자하는 업무에 대해 식별자, 속성, 관계등을 명시한다. M : N 관계를 여러 개의 1 : N 으로 분해
물리적 모델링	실제 DBMS 맞는 릴레이션을 구축 데이터 타입 정의, 인덱스 설계, 뷰 설계 → 실제로 작동하는 DB System 을 만드는 과정	릴레이션 도출 ( 기본키, 외래키, 칼럼 정의 ) 정규화 및 반정규화 수행 데이터 타입 정의, 인덱스 설계, 뷰 설계

 

학계의 개념적 모델링에서 Chen 타입의 ERD

 

데이터 독립성

 

데이터베이스 시스템의 핵심은 동일한 데이터들은 중복 관리하지 않고, 한 곳에서 관리해서 나눠 쓴다 ( 데이터 중복 제거 )

→ 프로그램마다 데이터를 갖고 있는게 아니라 프로그램이 데이터를 필요로할 땐 데이터베이스 시스템에 접근해서 원하는 데이터를 가져가도록 설계 → 프로그램과 데이터 간의 독립을 보장하는 설계

 

데이터 구조가 변경되어도 응용 프로그램이 변경될 필요가 없다

외부스키마와 개념스키마간의 독립성을 보장해주고 ( 논리적 데이터 독립성 )과

개념스키마와 내부스키마간 의 독립성을 보장해주면 ( 물리적  데이터  독립성 )

데이터의 독립성이 실현된다.

 

데이터의 독립성을 유지되지 않으면 ( 데이터의 종속성이 증가하면 )

데이터의 중복성과  복잡도가 증가한다 → 파일 시스템의 단점

요구사항에 대응하는 난이도가 증가한다. 예를 들어 필드하나를 바꾸려면

해당 필드의 요청사항에 관련된 코드를 모두 수정해야 한다 → 데이터 유지보수의 비용이 증가한다.

 

데이터베이스 3단계 구조

1) 외부 스키마는 각 사용자나 응용 프로그램 관점에서의 요구사항을 가리킨다.

ex. 내 급여가 얼마인가?

 

2) 외부스키마가 필요한 개념들을 모두 모아놓은 것이 개념스키마다.

필요한 개념들을 어떻게 모아놓아야 응용 프로그램이 요구하는 데이터를

( 응용 프로그램에게 ) 효율적으로 가져갈 수 있을지를 고민하고 설계하는 과정이

데이터 모델링이다. 데이터 모델링은 통합 관점의 개념 스키마를 만들어가는 과정이다.

 

3) 개념스키마를 실제 물리적으로 저장을 해놓는 구조가 내부스키마에 해당한다.

DB가 물리적으로 저장된 형식

 

데이터 모델링의 3가지 구성요소

Entity ( 개체 ) : 업무와 관련된 어떤 것 ( thing )

→ 업무에 필요한 정보를 저장하고, 관리하기 위한 집합적인 것

 

엔터티는 인스턴스의 집합이다.

과목이라는 엔터티가 있을 때,

과목 엔터티에는 여러 개의 인스턴스가 담길 수 있고,

( 하나의 ) 인스턴스 ( 레코드 ) 의 예로

'데이터베이스 입문, 3학점, 전공필수' 이런 값이 올 수 있다.

 

엔터티의 특징은

1) 해당 업무에서 필요하고 관리하고자 하는 정보를 포함해야 한다.

병원 시스템에서는 환자라는 엔터티가 필요하지만

회사-인사 시스템에서는 환자라는 엔터티 정보가 필요없으므로 환자가 엔터티가 될 수 없다.

 

2) 유일한 식별자 ( Identifier ) 에 의해 식별이 가능해야 한다.

( 하나의 ) 인스턴스 ( 레코드 ) 를 바로 지목할 수 있어야 한다.

※ 학계와 실무에서의 Entity 에 대한 해석이 다름

학계에서 엔터티는 식별자가 하나일 수 있고,

없을 수도  있고 ( Weak Entity ), 두 개 일수도 있다.

실무에서의 엔터티는 어느정도 테이블화된 상태이고,

그 때 유일한 식별자라 함은 Key 에 해당하는 것을 가리킨다.

 

3) 영속적으로 존재하는 ( 둘 이상의 ) 인스턴스의 집합이어야 한다.

4) 업무 프로세스에 의해 이용되어야 한다.

CRUD ( Create, Read, Update, Delete ) 에 해당하는 엔터티가 아니라면 불필요한 엔터티이므로 빼야 한다.

 

5) 반드시 속성을 가져야 한다.

일반 엔터티의 경우, 두 개 이상의 속성을 ( 주식별자[ PK ] 와 N개의 다른 속성들 )  가져야 엔터티로써의 가치가 있다.

단, 연관 엔터티의는 주식별자 ( PK ) 속성만 갖고 있어도 인정한다.

 

엔터티의 명명 ( 이름 짓기 )

권고사항

- 엔터티 생성 의미대로, 실제 업무에서 사용하는 용어를 사용한다.

- 약어를 사용하지 않는다.

- 단수 명사를 사용한다.

필수사항: 이름이 동일한 엔터티가 중복으로 존재할 수 없다.

 

6) 다른 엔터티와 최소 한 개 이상의 관계를 가져야 한다.

고립 엔터티는 부적절한 엔터티이거나 또는 관계가 누락된 경우에 해당할 수 있다.

 

단, 통계성 엔터티, 코드성 엔터티, 시스템 처리용 내부 엔터티 ( 트랜잭션 로그 테이블 등 ) 의 경우

고립 엔터티 ( 다른 엔터티와 관계가 없는 엔터티 ) 를 인정한다.

어떤 엔터티가 단순 참조용의 엔터티일 때 해당 엔터티는 고립 엔터티를 인정한다.

 

Attribute : 어떤 것 ( Entity ) 이 갖는 성격

- 학계에서의 개념적 모델링에서의 관계 ( Relationship ) 는 속성을 갖을 수 있다.

속성은 사물의 특징 또는 본질적인 성질을 의미한다.

속성이 없다면 실체를 생각할 수 없다.

엔터티 안에 있는 인스턴스들을 구분하기 위한 값들이 속성이 된다.

엔터티, 인스턴스, 속성, 속성값의 대응

- 각 엔터티는 둘 이상의 인스턴스를 가진다.

- 각 엔터티는 둘 이상의 속성을 가진다.

- 각 속성은 하나의 속성값을 가진다. 예를 들어 나이는 47 이지 47, 48 이 될 수 없다.

 

속성의 특징

- 모든 속성은 주식별자 ( PK ) 에 함수적으로 종속되어야 한다.

- 하나의 속성은 한 개의 값만을 가져야 한다.

→ 속성이 여러 개의 값을 가질 경우 해당 속성을 별도의 엔터티로 분리한다.

 

속성의 명명

- ( 하나의 ) 엔터티 안에서 속성명은 중복될 수 없다.

( 하나의 ) 엔터티 안의 어떤 속성명과

다른 엔터티 안의 속성명이 같은 건 괜찮으나

가급적 유일하게 정의하는 것이 좋다.

→ 속성의 이름은 가급적 전체 모델에서 유일하게 정의한다.

- 현업에서 사용하는 이름을 부여하고, 약어 사용은 가급적 금지한다.

- 서술식 속성명을 피하고 명사형 속성명을 사용한다.

- 수식어와 소유격을 피한다.

 

( 속성의 ) 도메인 ( Domain )

- 각 속성이 가질 수 있는 값의 범위 속성에서 허용하는 값을 정하는 것

예를 들어 나이라는 속성이 가질 수 있는 값의 범위는 1 ~ 100

- 속성에 대한 데이터 타입 ( 값이 문자열인지 숫자인지 등을 정하는 것 ) 과

크기 ( 몇 글자 등 ) 그리고 제약사항을 지정하는 개념이다.

 

Relationship : Entity ( 엔터티 ) 간의 [ 어떤 것 간의 ] 관계

관계와 페어링 ( Pairing )

엔터티간의 논리적 연관성을 관계라 하고,

엔터티 내 인스턴스 간의 개별적 연관성을 페어링이라 한다.

인스턴스간의 집합을 논리적으로 표현하면 엔터티가 되고,페어링간의 집합을 논리적으로 표현하면 관계가 된다.

 

데이터베이스 스키마란 데이터 모델링의 대상이 되는 것,

모델링을 한다는 것은 스키마를 모델링하는 것을 의미한다.

→ 데이터베이스 구조, 데이터 타입 그리고 제약조건에 대한 명세

→ 데이터베이스 설계 단계에서 명시되며, 자주 변경되지 않는다.

그 후에 사용을 할 때는 인스턴스를 주로 사용한다.

 

데이터베이스 인스턴스란 특정 시점에 데이터베이스에 실제로 저장되어 있는 데이터의 값을 의미한다.

SQL문 ( 시퀄문, 에스큐엘문 ) 으로 데이터베이스 인스턴스에 대해 질의가 이루어진다.

데이터베이스 인스턴스의 조회, 삽입, 변경, 삭제를 통해 데이터베이스 인스턴스가

시점에 따라 달라진다.

 

데이터베이스 스키마에는 여러 개의 데이터베이스 인스턴스 ( 여러 개의 레코드 ) 가

들어있다. 예를 들어 Student 라는 릴레이션 ( 테이블 ) 이 있고,

Student 릴레이션의 스키마는 이름, 나이, 학년으로 구성되어 있을 때 ( 데이터베이스 스키마 )

데이터베이스 스키마에는 여러 명의 학생 데이터가 담겨질 수 있다.

홍길동, 13, 6학년 이렇게 값이 담길 때,

이 하나의 행 ( 레코드 ) 을 하나의 데이터베이스 인스턴스라고 하고,

여러 개의 데이터베이스 인스턴스가 데이터베이스 스키마에 담길 수 있다.

→ Student Entity 안에 홍길동이라는 인스턴스가 들어있는 것

 

데이터 모델 표기법

( 한 명의 ) 직원은 ( 하나의 ) 부서에 소속된다.

( 하나의 ) 부서는 ( 여러 명의 ) 직원을 포함한다.

 

Chen 타입의 데이터 모델 표기법은 관계 ( Relationship ) 를 마름모로 표현,

관계 ( Relationship ) 가 속성을 갖을 수 있다.

 

IE / Crow's Foot ( 까마귀 발 모양의 표기법 ) 타입의 데이터 모델 표기법은

관계를 선으로 표현, 관계가 속성을 갖을 수 없다.

IE / Crow's Foot 표기법의 경우 ( 하나의 ) 부서에 직원이 여러 명 있을 수 도 있고,

아예 없을 수도 있다는 표시도 가능하다. 관계에 참여하지 않는 인스턴스가 없을 수도 있다 ( Optionality )

 

학계와 실무에서의 차수의 의미는 다르다.

학계에서 차수는 unary, binary, ternery, N-ary를 의미하는데,

실무에서 차수는 학계에서의 대응수 ( 1 : N, 1 : 1, M : N ) 를 의미한다.

 

1) ( 한 명의 ) 한국남자는 ( 한 번의 ) 병역을 등록해야 한다.

    ( 한 번의 ) 병역에 ( 한 명의 ) 한국남자가 등록된다.

 

2) ( 하나의 ) 부서가 여러 명의 사원을 포함한다.

여러 명의 사원이 ( 하나의 ) 부서에 소속된다.

 

3) ( 하나의 ) 주문에 여러 개의 제품이 포함된다.

( 하나의 ) 제품이 여러 주문에 포함된다.

 

관계 선택성 ( Optionality )

필수 참여와 선택 참여

필수 참여의 경우 사원은 ( 하나의 ) 부서에 반드시 소속되어야 한다.

부서에는 반드시 한 명 이상의 사원이 포함되어야 한다.

 

 

선택 참여의 경우 부서에는 사원이 0일 수 있고, N명일수도 있다.

( 한 명의 ) 사원은 반드시 ( 하나의 ) 부서에 포함된다.

 

보충설명

 

좋은 데이터 모델의 특징

- 업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의 되어야 한다 ( 완전성 ) 

- 동일한 사실 ( 속성 ) 은 반드시 한 번만 기록해야 한다.

동일한 데이터가 중복으로 기록되어선 안된다 ( 중복 배제 )

동일한 데이터의 중복기록 방지를 위해서 동일한 속성은 한 곳에서만 관리해야 한다.

단 필수불가결하게 중복이 되어 기록될 수 밖에 없는 속성이 있는데 바로 FK 다.

- 업무 규칙이 데이터 모델에 표현되어야 한다 ( 업무 규칙 )

→ 엄밀히 말하면 업무 규칙은 How 가 아닌 규칙을 프로세스에서 관리하기 위해서

필요한 데이터가 모델에 포함되어 있어야 한다는 의미다.

- 부서별로 응용 프로그램별로 따로 데이터를 만드는 것이 아니라 공용 데이터를 만들어 놓고

각 사용자나 응용 프로그램이 필요할 때마다 데이터를 사용할 수 있게 하는 것이 좋다.

→ 각 사용자나 응용 프로그램 관점에서 필요로 하는 공통 데이터들을 모두 모아

모든 데이터를 전 영역에서 사용할 수 있도록 설계해야 한다 ( 데이터 재사용 )

- 동일한 데이터는 조직의 전체에서 한 번만 정의되고, 이를 여러 다른 영역에서 참조, 활용해야 한다 ( 통합성 )

 

데이터는 빠짐없이 저장되어야 하고, 데이터가 중복으로 저장되는 일이 발생해서는 안된다.

 

참고 강의

1. 데이터베이스실무(SQLD대비) | 김남규 교수