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

데이터 모델링

정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법으로 현실세계의 데이터에 대해 약속된 표기법을 사용해서 표현하는 과정이다.

데이터 베이스를 구축하기위한 분석/설계 과정이지만 그자체로써도 업무를 설명하고 분석하는 의미에서 중요한 의미를 지닌다.

 

 

모델링시 유의사항

1) 중복(Duplication)

데이터베이스가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.

 

2) 비유연성(Inflexibility)

데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무변화에도 데이터 모델이 수시로 변경됨으로써 유지보수의 어려움을 가중시킬 수 있다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.

 

3) 비일관성(Inconsistency)

데이터의 중복이 없더라도 비일관성이 발생할 수 있는데, 예를 들면 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보를 갱신하는 경우이다. 개발자가 서로 연관된 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문에 이와 같은 문제가 발생할 수 있다. 데이터 모델링을 할 때 데이터와 데이터 간의 상호 연관 관계에 대해 명확하게 정의한다면 이러한 위험을 사전에 예방하는데 도움을 줄 수 있다.

사용자가 처리하는 프로세스 혹은 이와 관련된 프로그램과 테이블의 연계성을 높이는 것은 데이터 모델이 업무 변경에 대해 취약하게 만드는 단점에 해당한다.

 

 

 

데이터 모델링 과정

개념적 모델링	->	논리적 모델링	->	물리적 모델링
추상화 수준이 높다 업무중심적 포괄적 전사적 데이터 모델링 EA수립시 사용		key, 속성, 관계 등을 명확하게 표현 재사용성이 높음		성능, 저장 등  물리적인 성격 고려

 

 

Three-level architecture(3단계 데이터베이스 구조)

1) 외부스키마(External Schema)

추상화의 최상위 단계로 외부 단꼐의 각 외부 스키마는 각 사용자를 의미하는 개인적인 데이터베이스 구조

사용자 뷰를 포함해 개인의 논리적 데이터 구조로 이루어져 있으며, 개체나 관계, 응용 프로그램 모두 사용자와 관련된 것만 포함된다. 서브스키마 라고도 부른다.

 

2) 개념스키마(Conceptual Schema)

전체 구조를 추상화하는 단계로써 개념 단계에서 하나의 개념 스키마는 범 기관적 입장에서 데이터베이스를 정의한 것으로 정확히는 전체적이고 종합적인 측면을 나타내는 스키마

모든 사용자의 관점을 통합한 조직 전체 관점의 통합적 표현

객체나 관계, 응용 프로그램에다가 관리적인 측면에서 필요한 데이터와 정책,권한,규칙까지 포함한다.

 

3) 내부스키마(Internal Schema)

가장 낮은 추상화 단계로 물리적 저장 장치의 입장에서 데이터베이스가 저장되는 저장 구조와 세부사항 그리고 접근 경로 등을 기술한다.

아까 개념스키마가 포함하는 내용에다가 내부 레코드 형식/순서/인덱스 유무와 상세한 명세를 포함한다.

 

 

---

ERD(Entity Relationship Diagram)

말로 되어있는 요구사항들을 그림으로 그려 그 관계를 도출하는 것

1976년 피터첸에 의해 E-R Model이라는 표기법이 만들어졌다.

ERD의 예시

작성 순서

1) 엔티티를 그린다

2) 엔티티를 적절하게 배치한다

3) 엔티티간 관계를 설정한다

   존재/행위에 의한 관계를 구분하지 않지만, UML은 구분함에 유의한다.

    ex) 소유한다, 포함한다, 가르친다 등등

4) 관계명을 기술한다

5) 관계의 참여도를 기술한다

    ex) 1:1 , 1:다 , 다:다 (관계차수)

6) 관계의 필수여부를 기술한다.

    ex) 필수관계, 선택관계 (관계선택관계)

 

 

 

 

Entity

실체, 객체라는 의미

정의	그렇게 말한 사람
변별할 수 있는 사물	Peter Chen(1976)
데이터베이스 내에서 변별 가능한 객체	C.J Date(1986)
정보를 저장할 수 있는 어떤 것	James Martin(1989)
정보가 저장될 수 있는 사람, 장소, 물건, 사건 그리고 개념 등	Tomas Bruce(1992)

 

 

특징

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다
• 유일한 식별자에 의해 식별 가능해야 한다
• 영속적으로 존재하는 (두개 이상의) 인스턴스의 집합
• 엔티티는 업무 프로세스에 의해 이용되어야 한다
• 엔티티는 반드시 속성이 있어야한다
• 엔티티는 다른 엔티티와 최소 한 개 이상의 관계가 있어야 한다.

 

엔티티와 인스턴스, 속성과 속성값

 

 

 

 

---

Attribute(속성)

업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위

종류	설명	예시
기본 속성	비즈니스 프로세스에서 도출되는 본래의 속성	ex) 회원ID, 이름, 주문일자 . . .
설계 속성	데이터 모델링 과정에서 발생되는 속성 유일한 값을 부여	ex) 상품코드, 주문코드 . . .
파생 속성	다른 속성에 의해서 만들어지는 속성 데이터를 조회할때 빠른 성능을 내게 해준다.	ex) 합계, 평균 . . .

 

 

 

 

---

Relationship(관계)

엔티티의 인스턴스 간 논리적인 연관성, 존재 형태로서나 행위로서 서로에게 연관성이 부여된 상태

 

구성요소

1) 관계명(Membership)

2) 관계차수(Cardinality)

3) 관계선택사양(Optionality)

 

관계 체크사항

1) 두 개의 엔티티 사이에 관심있는 연관규칙이 존재하는가?

2) 두 개의 엔티티 사이에 정보의 조합이 발생되는가?

3) 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?

4) 업무기술서, 장표에 관계연결을 가능하게 하는 동사가 있는가?

 

 

 

---

Identifiers(식별자)

여러개의 인스턴스를 담고 있는 엔티티에서 인스턴스를 구별하기 위한, 엔티티를 대표하는 속성을 의미

 

식별자가 만족해야할 속성 4가지

유일성	주식별자에 의해 엔티티내에 모든 인스턴스들을 유일하게 구분할 수 있어야한다.
최소성	주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야한다.
불변성	주식별자가 한 번 특정 엔티티에 지정되면 그 식별자의 값은 변하지 않아야한다.
존재성	주식별자가 지정되면 반드시 데이터 값이 존재해야한다(not null)

 

식별자의 종류

기준1) 대표성의 유무

주식별자 : 엔티티 내에서 각 인스턴스를 구분할 수 있으면서 타 엔티티와 참조관계를 연결할 수 있는 식별자

보조식별자 : 엔티티 내에서 각 인스턴스를 구분할 수 있으나, 대표성이 없어 참조관계를 연결할 수 없음

 

기준2) 스스로 생성되었는가?

내부식별자 : 엔티티 내부에서 스스로 만들어진 식별자

외부식별자 : 타엔티티와 관계를 통해 생성된 식별자

 

기준3) 단일 속성인가?

단일식별자 : 하나의 속성으로 되어있다

복합식별자 : 둘 이상의 속성으로 되어있다

 

기준4) 업무적 의미가 있는가

본질식별자 : 업무에 의해 만들어지는 식별자

인조식별자 : 업무적으로 만들어지지는 않지만 원조식별자가 복잡한 구성을 가지고 있어 인위적으로 만든 식별자