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

[모델링]

데이터베이스의 모델링은 현실 세계를 단순화 하여 표현 하는 기법이다. 

 

<모델링이 갖춰야 할 조건>

• 현실세계를 반영해야 한다. 
• 단순화 하여 표현해야 한다. 
• 관리하고자 하는 데이터를 모델로 설계한다. 

 

<모델링의 특징> 

• 추상화 : 현실 세계를 일정한 형식으로 표현하는 것이다. 즉, 아이디어나 개념을 간략하게 표현하는 과정이다. 
• 단순화 : 복잡한 현실 세계를 정해진 표기법으로 단순하고 쉽게 표현한다는 의미이다. 
• 명확화 : 불분명함을 제거하고 명확하게 해석할 수 있도록 기술한다는 의미이다. 

 

<모델링의 세가지 관점> 

• 데이터 관점 : 어떤 데이터들이 업무와 얽혀있는지. 어떤 관계에 있는지 모델링하는 방법
• 프로세스 관점 : 이 업무가 실제로 처리하고 있는 일은 무엇인지 모델링 하는 방법
• 데이터와 프로세스 상관 관점 : 프로세스의 흐름에 따라 데이터가 어떤 영향을 받는지 모델링하는 방법 

 

<모델링의 세가지 단계>  : 개 논 물 

• 개념적 데이터 모델링 : 추상화 레벨이 가장 높은 모델링이다. 이 단계에서는 업무 중심적이고 포괄적인 수준의 모델링이 진행 된다. 
• 논리적 데이터 모델링 : 재사용성이 가장 높은 모델링으로 데이터베이스 모델에 대한 Key, 속성, 관계 등을 모두 표현하는 단계이다. 
• 물리적 데이터 모델링 : 실제 데이터베이스로 구현 할 수 있도록 성능이나 가용성 등의 물리적인 성격을 고려하여 모델을 표현하는 단계이다. 

 

<3단계 스키마 구조>  외 (논독) 개 (물독) 내 

외부 스키마 : (사용자 관점) 사용자가 보는 데이터베이스의 스키마를 정의한다. -> View 단계로 여러개의 사용자 관점으로 구성 되는 것. 뷰 단계 여러 개의 사용자 관점으로 구성 되어 있으며, 각 개인의 입장에서 필요로 하는 데이터베이스의 논리적 구조를 정의한 것

 

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

 

개념 스키마 : (통합된 관점) 데이터베이스에 저장되는 데이터들을 표현하고 데이터들 간의 관계를 나타낸다. -> 모든 사용자 관점을 통합한 조직 전체 관점의 통합적인 표현 

 

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

 

내부 스키마 : (물리적 관점) 실질적인 데이터의 저장 구조나 컬럼 정의, 인덱스 등이 포함 된다.  -> 물리적인 저장 구조를 나타내는 것 

 

- 외부 스키마(External Schema) - 서브 스키마, 사용자 뷰

1. 외부 스키마는 사용자나 응용 프로그래머가 개인의 입장에서 필요한 데이터베이스의 논리적 구조를 정의한다.

2. 외부 스키마는 전체 데이터베이스의 한 논리적인 부분으로 볼 수 있기 때문에 서브 스키마라고도 한다.

3. 하나의 데이터베이스 시스템에는 여러 개의 외부 스키마가 존재할 수 있다.

4. 하나의 외부 스키마를 여러개의 응용 프로그램 혹은 사용자가 공유할 수 있다.

5. 일반 사용자는 SQL과 같은 질의어를 이용하여 DB를 쉽게 사용할 수 있다.

6. 응용 프로그래머는 C나 JAVA 등의 언어를 사용하여 DB에 접근한다.

 

- 개념 스키마(Conceptual Schema) - 전체적인 뷰

1. 개념 스키마는 데이터베이스의 전체적인 논리적 구조로, 모든 응용 프로그램이나 사용자들이 필요로 하는 데이터를 종합한 조직 전체의 데이터베이스로 하나만 존재한다.

2. 개념 스키마는 개체 간의 관계(Relationship)와 제약 조건을 나타내고 데이터베이스의 접근 권한, 보안 및 무결성 규칙에 관한 명세를 정의한다.

3. 데이터베이스 파일에 저장되는 데이터의 형태를 나타내는 것으로, 단순히 스키마라고 하면 개념 스키마를 의미한다.

4. 기관이나 조직체의 관점에서 데이터베이스를 정의한 것이다.

5. DBA에 의해서 구성된다.

 

- 내부 스키마(Internal Schema) - 시스템 설계자 뷰

1. 내부 스키마는 물리적인 저장장치 입장에서 데이터가 저장되는 방법을 기술한 것이다.

2. 내부 스키마는 실제 데이터베이스에 저장될 레코드의 물리적인 구조를 정의한다.

3. 내부 스키마는 저장 데이터 항목의 표현방법, 내부 레코드의 물리적 순서, 인덱스 유/무 등을 나타낸다.

4. 시스템 프로그래머나 시스템 설계자가 관리한다.

 

<데이터 모델링시 지양 해야 할 것> 

• 중복 : 같은 데이터가 여러 엔터티에 중복으로 저장 되는 현상은 피해야 한다. 
• 비유연성 : 사소한 변경에도 데이터 모델이 수시로 변경 되어야 하는 상황이 생길 수 있다. 이런 상황을 피하기 위해 유연성을 높히는 것이 바람직한다. 
• 비일관성 : 다른 데이터와의 연관성을 고려하지 않아 일부 데이터만 변경할 수 있기 때문에 데이터간의 연관 관계에 대해 명확하게 정의 해야한다. 

 

< E-R 다이어그램 >

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

 

[엔터티 (Entity)]

<엔터티란>

사전적인 의미는 '독립체' 로서 데이터베이스에서 엔터티는 식별이 가능한 객체라는 의미를 가지고 있다. 

각각의 엔터티는 자신을 더 상세하게 나타내기 위해 속성 (Attribute) 을 갖게 되고 개수는 엔터티마다 상이해서 용도에 따라 매우 많을 수도 있고 매우 적을 수도 있다. 

 

<엔터티의 특징> 

• 업무에서 쓰이는 정보여야 한다. 
• 유니크함을 보장할 수 있는 식별자가 있어야 한다. 
• 2개 이상의 인스턴스를 가지고 있어야 한다. 
• 반드시 속성을 가지고 있어야 한다. 
• 다른 엔터티와 1개 이상의 관계를 가지고 있어야 한다. 

 

<엔터티의 분류> 

유형 vs 무형 - 유개시

• 유형 엔터티 : 물리적인 형태 존재. 안정적, 지속적 -> 상품, 회원 
• 개념 엔터티 : 물리적인 형태 없음, 개념적 -> 부서, 학과 
• 시간 엔터티 : 행위를 함으로써 발생, 빈번함, 통계 자료로 이용 -> 주문, 이벤트 응모 

 

발생 시점  - 기중행

• 기본 엔터티 : 독립적으로 생성됨, 자신 엔터티를 가질 수 있음 -> 상품, 회원 
• 중심 엔터티 : 기본 엔터티로부터 파생, 행위 엔터티 생성 -> 주문, 매출, 계약  
• 행위 엔터티 : 2개 이상의 엔터티로부터 파생 -> 주문 내역, 이벤트응모 이력 

 

<엔터티 이름 정하기> 

• 업무에서 실제로 쓰이는 용어 사용 
• 한글은 약어를 사용하지 않고 영문만 대문자로 표기 
• 단수 명사로 표현하고 띄어쓰기는 하지 않음 
• 다른 엔터티와 의미상으로 중복 될 수 없음 
• 해당 엔터티가 갖고 있는 데이터가 무엇인지 명확하게 표현

 

[속성 (Attribute)] 

<속성이란> 

의미상 더 이상 쪼개지지 않는 레벨이어야 하고 프로세스에 필요한 항목이어야 한다.  즉 엔터티의 특징을 나타내는 최소의 데이터 단위이다. 하나의 속성은 한개의 속성값만 가질 수 있다. 만약 하나의 속성이 여러 개의 속성값을 갖는 경우 별도의 엔터티로 분리하는 것이 바람직하다. 

 

엔터티 ⊃ 인스턴스 ⊃ 속성의 관계가 성립 되는데,

주요 특징으로는 

• 한 개의 엔터티는 두 개 이상의 인스턴스를 갖는다
• 한 개의 엔터티는 두 개 이상의 속성을 갖는다  
• 한 개의 인스턴스는 두 개 이상의 속성을 갖는다 
• 한 개의 속성은 하나의 속성값을 갖는다. 

 

<속성 분류> 

- 특성에 따라 - 기설파

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

 

- 구성방식에 따라 - PF일

• PK 속성 : 엔터티의 인스턴스들을 식별할 수 있는 속성 
• FK 속성 : 다른 엔터티의 속성에서 가져온 속성
• 일반 속성 : PK, FK를 제외한 나머지 속성 

 

<도메인> 

속성이 가질 수 있는 속성값의 범위를 도메인이라고 한다. 

 

<용어사전>

엔터티의 속성명을 정의할 때 명확한 의미의 이름을 부여하고 다른 엔터티와의 혼란을 예방하기 위해 이용하는 것 

 

 

[관계 (Relationship)] 

<관계란> 

엔터티와 엔터티와의 관계를 의미하며,  어떤 연관성이 있는지 타입을 분류한다. 

관계는 존재 관계와 행위 관계로 나눌 수 있다. 

• 존재 관계 : 존재 자체로 연광성이 있는 관계 -> 학생 - 학과 / 직원 - 부서 
• 행위 관계 : 특정한 행위를 함으로써 연관성이 생기는 관계를 의미한다 -> 회원 - 주문 / 학생 - 출석부 

 

<관계 표기법>

• 관계명 : 관계의 이름
  엔터티와 엔터티가 어떠한 관계를 맺고 있는지를 나타내주는 문장.  각 엔터티의 관점에서 관계명을 하나씩 가지기 때문에 모든 관계는 두 개의 관계명을 가지고 있다.  관계명은 반드시 명확한 문장 + 현재형이어야 한다. 
• 관계차수 : 관계에 참여하는 수
  각 엔터티에서 관계에 참여하는 수를 의미하며 일반적으로 1:1 , 1:M , M:N 으로 구분할 수 있다.  
• 관계선택사양 : 필수 인지 선택인지의 여부
  팔수적 관계 (참여자가 반드시 존재해야 하는 관계) / 선택적 관계 (참여자가 없을 수도 있는 관계) 

 

[식별자]

<식별자란> 

모든 엔터티는 인스턴스를 가지고 있고 인스턴스는 속성으로 자신의 특성을 나타낸다. 식별자는 이런 속성 중에 각각의 인스턴스를 구분 가능하게 만들어주는 대표 격인 속성을 의미한다. 

 

<주식별자> - 유최불존

주식별자는 기본키, PK에 해당하는 속성이다. 하나의 속성이 주식별자가 될 수도 있고 여러개의 속성이 주식별자가 될 수도 있다. 

• 유일성 : 각 인스턴스에 유니크함을 부여하여 식별이 가능하도록 한다. 
• 최소성 : 유일성을 보장하는 최소 개수의 속성이어야 한다. 
• 불변성 : 속성값이 되도록 변하지 않아야 한다. 
• 존재성 : 속성값이 NULL 일 수 없다. 

<주식별자를 도출하는 기준>

• 해당 업무에서 자주 이용되는 속성을 주 식별자로 지정
• 복합으로 주식별자를 구성할 경우 너무 많은 속성을 포함하지 않도록 한다.  
• 명칭, 내역 등과 같이 이름으로 기술 되는 것들은 가능하면 주식별자로 지정하지 않는다. 
• 자주 수정 되지 않는 속성으로 한다. 

<분류> 

• 대표성 여부 
  ① 주식별자 (유일성, 최소성, 불변성, 존재성을 가진 대표 식별자 / 다른 엔터티와 참조 관계로 연결) 
  ② 보조식별자 (인스턴스를 식별할 수는 있지만 대표 식별자가 아님 / 다른 엔터티와 참조 관계로 연결되지 않음) 
• 스스로 생성되었는지 여부 
  ① 내부식별자 (엔터티 내부에서 스스로 생성된 식별자)
  ② 외부식별자 (다른 엔터티에서 온 식별자, 다른 엔터티와의 연결고리 역할) 
• 단일 속성의 여부 
  ① 단일식별자 (하나의 속성으로 구성된 식별자)
  ② 복합식별자 (두 개의 속성으로 구성된 식별자) 
• 대체 여부 
  ① 원조 식별자 / 본식별자  (업무 프로세스에 존재하는 식별자 / 가공되지 않은 원래의 식별자) 
  ② 대리식별자 / 인조식별자 (주식별자의 속성이 두 개 이상인 경우 그 속성들을 하나로 묶어서 사용하는 식별자) 

 

<식별자 관계 vs 비식별자 관계> 

• 식별자 관계 : 부모 엔터티의 식별자가 자식 엔터티의 주식별자가 되는 관계이다.  실선으로 표기
• 비식별자 관계 : 부모 엔터티의 식별자가 자식 엔터티의 일반 속성이 되는 관계이다.  점선으로 표기