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

 

데이터 모델링 

 

현실시계의 데이터를 단순화(추상화)시켜 데이터베이스로 표현하기 위한 작업이다. 

 

단지 데이터베이스만을 구축 하기 위한 용도로 쓰이는 것이 아니라

 

데이터모델링 자체로서 업무를 설명하고 분석하는 부분에서도 매우 중요한 의미를 자지고 있다.

 

약속된 표기법으로 표현한다. 

 

 

모델링 시 유의사항 

 

중복성

 

• 여러 장소의 데이터베이스에 같은 정보를 저장하지 않도록 한다. 

 

비유연성 

 

• 데이터의 정의를 데이터의 사용 프로세스와 분리한다. 
• 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.

 

비일관성 

• 데이터의 중복이 없더라도 비일관성은 발생할 수 있다.
• 데이터와 데이터간의 상호 연관 관계에 대해 명확하게 정의하여야 한다.
• 사용자가 처리하는 프로세스 혹은 이와 관련된 프로그램과 테이블의 연계성을 높이는 것은 데이터 모델이 업무 변경에 대해 취약하게 만드는 단점.

 

 

개념적 데이터 모델링

 

추상화의 수준이 높음 

 

업무중심적이고 포괄적인 수준의 모델링 진행

 

전사적 데이터 모델링을 수행할 때 많이 한다. 

 

논리적 데이터 모델링

 

시스템으로 구축하고자 하는 업무에 대해 

 

key, 속성, 관계 등을 정확하게 표현 

 

재사용성이 높음

 

물리적 데이터 모델링

 

실제로 데이터베이스에 이식할 수 있도록 

 

성능, 저장 등 물리적인 성격을 고려하여 설계

 

 

스키마(Schema)란?

 

스키마는 데이터베이스의 구조와 제약조건에 관한 전반적인 명세를 기술한 것이다.

 

스키마는 데이터베이스를 구성하는 데이터 개체(Entity), 개체의 특성을 나타내는 속성(Attribute),

 

개체 사이에 존재하는 관계(Relationship) 및 데이터 조작 시 데이터 값들이 갖는 제약 조건 등에 관하여 기술한다.  

 

쉽게 말해 DB 내에 데이터가 어떤 구조로 저장되는가를 나타내는 데이터베이스 구조를 스키마라고 한다.

 

데이터베이스 스키마 구조 3단계

 

 

개념 스키마

• 모든 사용자 관점을 통합한 조직 전체 관점의 통합적 표현
• 데이터 모델링은 통합 관점을 가지고 있는 개념 스키마(Conceptual Schema)를 만들어 가는 과정

 

외부 스키마

• 사용자 뷰(View)
• 사용자나 응용 프로그래머가 각 개인의 입장에서 필요로 하는 데이터베이스의 논리적 구조를 정의
• 전체 데이터베이스의 한 논리적인 부분 (서브 스키마)
• 같은 데이터베이스에 대해서도 서로 다른 관점을 정의 할 수 있도록 허용
• 일반 사용자는 SQL을 사용하여 DB를 사용한다.

 

내부 스키마

• 물리적 저장장치 입장에서 본 데이터베이스 구조, 물리적인 저장 장치와 밀접한 계층
• 실제 데이터베이스에 저장될 레코드의 물리적인 구조를 정의
• 데이터 항목의 표현방법, 내부 레코드의 물리적 순서 등을 나타냄
• 시스템 프로그래머, 설계자가 보는 관점의 스키마

 

 

https://code-lab1.tistory.com/114

[DB] 스키마(Schema)란? 외부스키마, 개념스키마, 내부스키마

 

 

 

ERD(Entity Relationship Diagram)

 

데이터베이스 구조를 한눈에 알아보기 위해서 쓰인다.

 

1976년 Peter Chen 에 의해 만들어진 표기법

 

 

 

작성 흐름 : 엔티티 도출 -> 엔티티 배치 -> 관계 설정 -> 관계명 기술 

 

엔티티의 특징

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

 

 

발생 시점에 따른 분류 

엔터티의 발생 시점에 따라 기본/키 엔터티(Fundamental Entity, Key Entity), 중심 엔터티(Main Entity), 행위 엔터티(Active Entity)로 구분할 수 있다.

기본 엔터티 

기본 엔터티란 그 업무에 원래 존재하는 정보로서 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 생성할 수 있고 자신은 타 엔터티의 부모의 역할을 하게 된다. 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가지게 된다.

관계로 생성되지 않고 독립적으로 생성할 수 있고 자신은 타 엔터티의 부모의 역할을 하게 된다. 다른 엔터티로부터 주식별 자를 상속받지 않고 자신의 고유한 주식별 자를 가지게 된다.

중심 엔터티 

중심 엔터티란 기본 엔터티로부터 발생하고 그 업무에 있어서 중심적인 역할을 한다. 데이터의 양이 많고 발생하고 다른 엔터티와의 관계를 통해 많은 행위엔터티를 생성한다.

행위 엔터티 

행위 엔터티는 두 개 이상의 부모엔터티로부터 발생하고 자주 내용이 바뀌거나 데이터양이 증가한다. 분석 초기 단계에서는 잘 나타나지 않으며 상세 설계단계나 프로세스와 상관모델링을 진행하면서 도출될 수 있다.

 

 

 

속성

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

 

한 개의 엔티티는 두 개 이상의 속성을 갖는다.

 

한 개의 속성은 한 개의 속성값을 가져야 한다. 

 

 

1) 기본속성
기본 속성은 업무로부터 추출한 모든 속성이 여기에 해당하며 엔터티에 가장 일반적이고 많은 속성을 차지한다. 코드성 데이터, 엔터티를 식별하기 위해 부여된 일련번호, 그리고 다른 속성을 계산하거나 영향을 받아 생성된 속성을 제외한 모든 속성은 기본속성이다. 주의해야 할 것은 업무로부터 분석한 속성이라도 이미 업무상 코드로 정의한 속성이 많다는 것이다. 이러한 경우도 속성의 값이 원래 속성을 나타내지 못하므로 기본속성이 되지 않는다.

 

2) 설계속성
설계속성은 업무상 필요한 데이터 이외에 데이터 모델링을 위해, 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성이다. 대개 코드성 속성은 원래 속성을 업무상 필요에 의해 변형하여 만든 설계속성이고 일련번호와 같은 속성은 단일(Unique)한 식별자를 부여하기 위해 모델 상에서 새로 정의하는 설계속성이다.

 

3) 파생속성
파생속성은 다른 속성에 영향을 받아 발생하는 속성으로서 보통 계산된 값들이 이에 해당된다. 

 

 

도메인(Domain)

각 엔티티(테이블)의 속성에 대해서 어떤 유형의 값이 들어가는지를 정의하는 개념

 

각 속성의 가질 수 있는 값의 범위 

 

속성에 대한 데이터타입, 크기 지정 / 제약사항 지정 

 

 

관계

 

ERD에서는 관계를 연결할 때 , 존재와 행위를 구분하지 않고 단일화된 표기법을 사용한다.

 

UML의 클래스 다이어그램에서는 연관관계와 의존관계에 대해 다른 표기법을 가지고 표현한다. 

 

 

 

관계의 표기법

 

관계명 : 관계의 이름

관계차수 : 1:1 , 1:M , M:N

관계선택사양 : 필수관계 , 선택관계 

 

 

관계를 정의할 때 체크사항

 

1. 연관규칙이 존재하는가?
2. 정보조합이 발생하는가?
3. 관계연결에 대한 규칙이 서술되어 있는가?
4. 관계연결을 가능하게 하는 동사가 있는가?

 

주식별자

 

주식별자의 특징

 

1. 유일성 : 유일하게 구분

2. 최소성 : 속성의 수 유일성을 만족하며 최소의 수 

3. 불변성 : 식별자의 값은 변하지 않아야 함

4. 존재성 : not Null

 

 주식별자를 지정할 때 고려해야 할 사항은?

 

1) 주식별자에 의해 엔터티 내의 모든 인스턴스들이 유일하게 구분되어야 한다.

2) 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.

3) 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다.

4) 주식별자가 지정되면 반드시 값이 들어와야 한다.

 

 

• 식별자
  : 데이터를 식별할 수 있는 속성

 

• 대체여부에 따라 분류가능
  • 본질식별자 : 업무에 의해 만들어진 식별자
  • 인조식별자 : 업무적으로 만들어지지는 않았지만  인위적으로 만든 식별자 (시스템적으로 부여된 식별자)

 

 

 

식별자와 비식별자관계

 

- 식별자관계(identifying relationship)만을 이용해 데이터모델링을 전개할 경우,

 

pk 속성의 숫자가 관계에 따라 계속 증가하면서 개발된 sql구문이 복잡해지고 이러한 구문의 복잡성으로 개발오류가 유발할 수 있다.

 

- 비식별자 관계(non-identifying relationship)만을 이용해 데이터모델링을 전개할 경우,

 

테이블간의 과다한 조인을 유발해 조인에 의한 성능저하를 유발할 수 있게 된다.

“데이터모델관계 도출 시 식별자관계와 비식별자관계의 의미를 정확하게 이해하고,

 

업무적 특징과 조인관계 그리고 pk 구성을 고려해 식별자관계/비식별자관계를 결정한다.”