[SQLD] 1과목: 데이터 모델링의 이해 - 데이터 모델링의 이해

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

I. 데이터 모델링의 이해

| 데이터 모델링

정보 시스템을 개발하는 과정에서 필요한 데이터의 구조와 관계를 표현하는 과정이다. 다시 말해, 데이터 모델링은 현실세계의 정보, 이벤트, 엔터티, 관계 등을 추상화, 단순화 하여 데이터베이스나 애플리케이션에서 사용될 수 있는 상태로 변화되는 과정이다.

 

- 데이터 모델링의 특징

• 추상화 : 데이터 모델링은 실세계의 복잡한 데이터를 일정 형식에 맞게  표현한다. 
• 단순화: 모델링 과정에서 필요하지 않은 세부 정보는 생략되며 중요한 정보만이 포함된다.
• 명확성 : 모델이 명료하고 모호함이 없어 정확하게 표현되어야 한다. 

- 데이터 모델링의 관점

• 데이터 관점 : 업무와 데이터 및 데이터 사이의 관계를 의미한다. ERD와 같은 도구를 사용하여 표현된다. 학교 시스템에서 학생, 강의, 교수 등의 엔터티와 그들 사이의 관계를 모델링하는 것 
• 프로세스 관점 : 업무가 실제 하고 있는 일은 무엇인지 또는 무엇을 해야하는지 모델링한다. 데이터흐름도(DFD)와 같은 도구를 사용하여 표현한다. 학교 시스템에서 학생 정보를 입력, 수정, 삭제하는 포르세스를 모델링하는 경우이다.
• 상관 관점 : 데이터와 프로세스 간의 상호 작용을 의미한다. 업무를 처리하는 일의 방법에 따라 데이터가 어떤 영향을 받고 있는지 모델링한다. 시퀀스 다이어그램, 상태 다이어그램등 UML 도구가 사용된다. 학교 시스템에서 학생이 강의를 등로갛거 취소할 때의 상호 작용 모델링

- 데이터 모델링의 유의점(빈출!)

• 중복 : 데이터베이스가 여러 장소에 같은 정보를 저장하지 않도록 한다.
• 비유연성 : 데이터 정의를 프로세스와 분리해 데이터 혹은 프로세스의 변화가 db에 큰 변화를 일으킬 가능성을 줄여야한다. 
• 비일관성 :  데이터와 데어타간 연관 관계에 대해 명확화게 정의해야한다.

**비유연성 데이터 모델링에서 "비유연성"은 모델의 변경에 대한 저항성을 의미한다. 좋은 데이터 모델은 변경 사항에 대응하기 위해 유연해야 한다. 그러나 모델이 너무 복잡하거나 제대로 설계되지 않았을 경우, 작은 변경 사항에도 큰 수정이 필요할 수 있다. 이러한 비유연성은 시스템의 유지 보수와 확장성에 큰 장애가 될 수 있다.

 

- 데이터 모델링의 3단계(추상 -> 구체)

• 개념적 모델링 : 비즈니스의 주요 개념과 그들 사이의 관계를 표현한다. ERD와 같은 도구를 사용하며 엔터티들 사이의 관계를 식별한다. 구체적인 속성, 데이터 형식, 세부 사항은 포함하지 않는다. 추상화 수준이 높고 업무중짐적이고 포괄적인 수준의 모델링 진행. 전사적 데이터 보델링, EA 수립시 많이 사용한다.
• 논리적 모델링 : 데이터 구조를 더욱 상세하게 정의하며 실제 데이터베이스 설계에 앞서 데이터의 관계, 속성, 무결성 규칙등을 결정한다. 특정 데이터 시스템에 종속적이지 않다. 재사용성이 높다.
• 물리적 모델링 : 논리적 모델을 특정 데이터베이스 관리 시스템에 구현 가능한 상태로 변환하는 것이다. 데이터베이스의 실제 테이블, 인덱스, 뷰, 트리거 등의 객체를 정의하고 데이터의 저장 구조, 액세스 경로, 성능 최적화를 고려한다.

 

- 스키마모델링의 3단계(추상화 -> 구체화)

• 외부 스키마 : 사용자나 응용 프로그램의 관점에서 본 데이터베이스의 뷰(view)를 정의한다. 하나의 데이터베이스 시스템은 여러 외부 스키마를 가질 수 있다.
• 개념 스키마 : 전체 데이터베이스의 논리적 구조와 모든 사용자와 응용 프로그램의 요구사항을 통합하여 표현한다. 모든 엔터티, 관계, 제약 조건 등을 포함하여 전체 데이터베이스의 논리적 뷰를 제공한다. 설계자 관점에서 데이터 모델링의 지향점이다.
• 내부 스키마 : 데이터가 실제로 저장되는 물리적인 데이터베이스의 구조를 정의한다. 물리적 저장방법, 액세스 경로, 파일 구조 등. 개발자 관점
• 개념적 모델링과 개념 스키마를 헷갈리면 안된다. 데이터 모델링에서 개념적 모델링은 1단계 스키마 모델링에서 개념 스키마는 2단계다!!!

 

 

 

-  데이터 독립성

• 논리적 독립성 : 외부 스키마가 개념 스키마의 변화에 무관함. 논리적 사상(mapping) 없음
• 물리적 독립성 : 개념 스키마가 내부 스키마의 변화에 무관한. 물리적 사상 없음
• 유지보수 비용 증가, 데이터 중복성 증가, 데이터 복잡도 증가, 요구사항 대응 저하를 방지한다.

ANSI/SPARC의 3단계 구조

- 데이터 모델링의 3요소 : 엔터티, 관계, 속성

 

- ERD(Entitiy Relationship Diagram) : 엔티티-관계 다이어그램

• 데이터의 논리적 구조와 그 사이의 관계를 시작적으로 나타내는 도구
• 작업 순서 : 엔티티 그리기 -> 엔터티 적절히 배치하기 -> 엔터티간 관계 설정 -> 관계명 기술 -> 관계의 관계차수 기술 -> 관계의 필수여부 기술

 

 

---

 

| 엔터티(Entity)

데이터베이스에서 표현하려는 실세계의 객체나 개념으로 업무에서 관리해야하는 데이터의 집합이다. 명사형으로 표현되며 인스턴스의 집합이다. 인스턴스는 실제 객체(홍길동)이고 엔티티는 범주(사람)이다.

 

- 엔터티의 특징(빈출)

1) 반드시 해당 어붐에서 필요하고 관리하고자 하는 정보여야 한다.

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

3) 2개 이상의 인스턴스를 포함한다. = 두 개 이상의 속성을 갖는다.

4) 엔터티는 실제 업무 프로세스에 이용되어야 한다.

5) 반드시 속성을 가진다.

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

 

- 엔터티의 종류

1) 유무형에 따른 분류

• 유형 엔터티 : 물리적 형태가 있고 지속적으로 활용되는 엔터티
• 개념 엔터티 : 물리적 형태가 없는 엔터티

2) 데이터 모델 내에서 수행하는 역할과 의미 기준으로 분류

• 기본 엔터티 : 독립적으로 생성되는 엔터티이다. 업무에 필요하고 관리하려는 정보로서 가장 중심적인 역할을 한다. 대부분의 엔터티가 이 카테고리에 속하고 주로 CRUD연산의 대상이다.  학생, 주문 , 제품 등
• 관계 엔터티 : 두 개 이상의 엔터티 간의 관계를 표현하기 위한 엔터티이다. 흔히 다대대 관계를 해소하기 위해 사용한다. 
• 속성 : 다른 엔터티의 속성으로 존재하지 않고 독립적으로 존재하는 속성을 엔터티로 만든 경우이다. 특정 엔터티의 속성이 여러 개의 값이나 복잡한 속성을 갖는 경우, 이를 별도의 엔터티로 분리하여 관리하는 것이다.

2) 발생 시점에 따른 분류

• 기본 엔터티(Basic Entity or Key Entity) : 업무에 원래 존재하는 정보로서 독립적으로 생성된다. 업무의 주체가 되며 다른 엔터티와의 관계를 통해 주로 활용된다. EX) 사원, 제품, 고객 등
• 중심 엔터티(Main Entity) : 기본 엔터티를 중심으로 업무가 진행되면서 발생하는 정보를 담는 엔터티. 중심 엔터니는 기본 엔터티와 밀접한 관련이 있으며 주로 특정 해위나 이벤트와 관련된 정보를 포함한다. EX) 주문, 계약, 예약 등
• 행위 엔터티(Transaction Entity) : 두 개 이상의 엔터티 간의 관계나 그 관계에서 발생하는 특정한 행위나 이벤트를 표현하기 위한 엔터티이다. 행위 엔터티는 주로 다대다 관계를 해소하기 위해 사용한다 .EX) '고객_주문', '사원_프로젝트' 등

 

- 엔터티의 명명규칙

1) 실제 업무에서 사용하는 용어를 사용한다.

2) 약어를 지양한다.

3) 단수 명사를 지향한다.

4) 유일성을 보장해야한다.

5) 명확성

 

- ERD 작성순서

1) 엔티티를 그린다.

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

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

4) 관계명을 기술한다.

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

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

 

---

| 속성(Attribute)

엔터티가 가지는 최소의 단위로서 인스턴스의 구성요소이다.  쉽게 말하면 엔터티는 데이터의 주체나 객체를 나타내며 그 엔터티의 구체적인 특성이나 세부 정보를 나타내는 것이 속성이다. 예를 들어 '사원'이라는 엔터티가 있다면, 그 사원의 '이름', '주소', '부서' 등은 모두 사원 엔티티의 속성이다. 

 

- 속성의 특징

• 정해진 주식별자에 함수적 종속성을 가져야 한다.
• 한 속상의 한개의 값만 가진다.
• 업무에서 필요하고 관리하고자 하는 정보여야한다.

 

- 속성 표기법 : IE 표기법, Baker 표기법

 

- 속성의 종류

1) 특성에 따른 분류

• 기본 속성 : 비즈니스 프로세스에서 도출되는 본래의 속성 EX) 이름, 계좌번호, 티자율
• 설계 속성 : 데이터 모델링 과정에서 업무 규칙화를 위해 발생하는 속성. EX) 상품코드, 지점코드
• 파생 속성 : 다른 속성에 의해 만들어지는 속성. 데이터를 조회할 때 빠른 성능을 낼 수 있도록 하기 위해 원래 속성의 값을 계산하여 저장할 수 있도록 만든 속성 EX) 합계, 평균, 이자
• ** 이자율은 기본속성, 이자율과 원금을 계산하여 구한 이자금액은 파생 속성이다!

2) 엔티티 구성방식에 따른 분류

• PK 속성 : 엔터티를 식별할 수 있는 속성
• FK 속성 : 다른 엔터티와의 관계에서 포함된 속성
• 일반속성 : PK, FK가 아닌 속성

3) 세부의미에 따른 분류

• 단순 속성 : 세부 의미로 쪼갤 수 없는 속성 EX) 시, 구, 동, 번지
• 복합 속성 : 세부 단위로 쪼갤 수 있는 송성  EX) 주소

4) 개수에 따른 분류

• 단일값 속성 : 속성 하나에 한개의 값을 가지는 속성성
• 다중값 속성 : 속성 하나에 다중 값을 가지는 속성 -> 바람직하지 않다. 1차 정규화를 하거나 별도의 엔터티를 만들어 관계로 연결하자 EX) 휴대전화번호가 2개인 사람

**도메인(Domain) 속성이 가질 수 있는 값의 범위

 

---

| 관계(Relationship)

두 개 이상의 엔터티 간의 연관성을 표현하는 구조이다. 관계는 엔터티간의 상호 작용, 의존성 및 연결 방식을 명확하게 나타낸다. 엔터티는 명사형이로 관계는 동사형이다. 엔터티가 인스턴스의 집합을 논리적으로 표현한 것과 동일하게 관계는 관계 페어링의 집합을 논리적으로 표현한 것이다. 

**관계 페어링 : 엔터티 안의 인스턴스가 개별적으로 관계를 가지는 것

 

- 관계의 분류 : ERD는 구분 안함, UML은 구분함!!!

1) 존재에 따른 분류 : 엔티티 간의 상태(소속)

• ERD에서는 존재/행위에 따른 표기 구분이 없다.
• UML에서는 연관관계에 해당되며 실선으로 표현한다.

2) 행위에 따른 분류 : 엔티티 간의 행위(주문)

• ERD에서는 존재/행위에 따른 표기 구분이 없다.
• UML에서는 의존관계에 해당되며 점선으로 표현한다.

erd

 

- 관계의 주요 특징 및 구성요소

• 참여 엔터티 : 관계는 두 개 이상의 엔터티를 연결한다. 이 연걸되는 엔터티들을 참여 엔터티라고 한다.
• 차수(Degree) : 관계의 차수는 관계에 참여하는 엔터티의 수를 나타냅니다. 예를 들면, 이진 관계는 두 개의 엔터티를 연결하며, 삼진 관계는 세 개의 엔터티를 연결한다.
• 카디널리티(Cardinality) : 관계의 카디널리티는 엔터티 간의 관계에서 각 엔터티는 인스턴스 수를 나타낸다. 예를 들면"하나의 회사는 여러 직원을 가질 수 있고, 하나의 직원은 하나의 회사에만 속할 수 있다"는 관계에서 1:N 카디널리티를 가진다.

- 관계의 표기법

• 관계명(Membership) : 관계의 이름
• 관계차수(Cardinality) : 1:1, 1:M, N:M
• 관계선택사양(Optionality) : 필수관계, 선택관계

- 관계의 유형

• 1:1 관계 (One-to-One): 하나의 엔터티 인스턴스가 다른 엔터티의 하나의 인스턴스와만 관계를 맺을 수 있다.
• 1:N 관계 (One-to-Many): 하나의 엔터티 인스턴스가 다른 엔터티의 여러 인스턴스와 관계를 맺을 수 있으며, 반대로는 하나의 인스턴스와만 관계를 맺을 수 있다.
• M:N 관계 (Many-to-Many): 하나의 엔터티의 여러 인스턴스가 다른 엔터티의 여러 인스턴스와 관계를 맺을 수 있다.

 

- 관계 정의 시 고려사항

• 두 엔터티 사이에 관심있는 연관 규칙이 존재하는가?
• 두 엔터티 사이에 정보의 조합이 발생되는가?
• 업무기술서, 장표에 관계 연결에 대한 규칙이 서술되어 있는가?
• 업무기술서, 장표에 관계 연결을 가능하게 하는 동사(Verb)가 있는가? -> 명사 아니다!!

---

 

| 식별자(Identifiers)

식별자는 특정 엔터티의 인스턴스를 구별하고 식별하기 위해 사용 되는 속성(또는 속성의 집합)을 의미한다. 즉, 엔터티 내에서 각 인스턴스는 그들의 식별자를 통해 유일하게 구분될 수 있어야한다.

 

- 주식별자의 주요 특징

• 유일성 : 식별자는 엔터티 내에서 각 인스턴스를 고유하게 식별할 수 있어야한다. 동일한 식별자 값이 두 개 이상 존재해서는 안된다. EX) 사원번호는 유일해야한다.
• 불변성 : 일단 식별자 값이 할당되면, 그 값을 변경해서는 안된다. EX)한번 정해진 사원번호는 바꿀 수 없다.
• 최소성 : 식별자는 가능한 한 최소한의 속성으로 구성되어야한다. 즉, 식별을 위해 불필요한 속성을 포함시키지 않아야 한다. EX) 사원번호 한가지로 구분되어야 한다. 이름 + 전화번호 두가지로 구분해서는 안된다.
• 존재성 : 주식별자가 지정되면 반드시 값이 있어야한다. EX) 사원번호가 없는 직원을 있을 수 없다.

 

- 식별자의 종류

 

1) 대표성 여부

• 주식별자 :유일성, 최소성, 대표성을 모두 만족하는 식별자  EX) 사원번호
• 보조식별자 : 보조식별자는 엔터티 내에서 주식별자 외에도 인스턴스를 구별하는 데 도움을 주는 다른 속성이다. 보조식별자는 주식별자와는 달리 해당 엔터티의 모든 인스턴스에 대해 유일하거나 변하지 않을 필요는 없다. 하나의 엔터티는 여러개의 보조식별자를 가질 수 있다. EX) 이메일 주소, 전화번호

 

2) 스스로 생성여부

• 내부식별자 : 엔터티 내부에서 스스로 만들어지는 식별자로 해당 엔터티만의 고유한 식별자로 사용된다. 
• 외부식별자 : 타 엔터티에서 가져온 값으로 주로 관계에서 FK 역할을 하는 ㅅ혹성을 의미한다. 외부식별자는 해당 엔터티와 연관된 다른 엔터티의 인스턴스를 참조하거나 식별하기 위해 사용하낟. 예를 들어 '주문' 엔터티에서 '고객번호'는 '고객'엔터티의 '고객 번호'를 참조하는 외부식별자가 될 수 있다.

3) 속성의 수

• 단일 식별자 : 하나의 속성의로 구성된 식별자 EX) 사원번호
• 복합 식별자 : 둘 이상의 속성으로 구성된 식별자 EX) 이름 + 주민번호

4) 출처와 의미에 의한 구분

• 본질식별자 : 엔터티의 실제 세계에서 고유한 특성을 반영하여 식별되는 속성을 의미한다. EX) 주민등록번호
• 인조식별자 : 시스템 내에서 임의로 생성된 식별자이다. EX) 데이터베이스의 일련번호나 시퀀스

**주식별자의 도출기준 - 해당 업무에서 자주 이용되는 속성으로 지정한다. - 명칭, 내역과 같이 이름으로 기술되는 것은 가능하면 지정하지 않는다.(처리가 길어진다) - 복합 속성의 경우, 너무 많은 속성이 포함되지 않도록 한다.

 

 

- 식별자/비식별자 (빈출!)

	식별자	비식별자
정의	부모 엔터티의 주식별자가 자식 엔터티의 주식별자로 사용되는 관계	부모 엔터티의 주식별자가 자식 엔터티의 속성(주로 외래키)으로만 사용되며 주식별자로는 사용되지 않는 관계
특징	- 자식 엔터티는 부모 엔터티 없이는 존재할 수 없다. - 부모와 자식 엔터티가 강하게 연결된다.	- 자식 엔터티가 부모 엔터티와 독립적으로 존재할 수 있다. - 부모와 자식 엔터티 사이의 연결이 상대적으로 약하다.
예시	'주문-주문 상세 정보 관계'에서 주문 번호는 주문 상세 정보의 주식별자의 일부	'사원-부서 관계'에서 부서 코드는 사원 엔터티의 속성(외래키)이지만 사원의 주식별자는 아니다
연결 고려사항	- 반드시 부모 엔티티에 종속 - 자식 주식별자 구성에 부모 주식별자 포함 필요 - 상속받은 주식별자속성을 타 엔터티에 이전 필요	- 자식 주식별자구성을 독립적으로 구성 - 자식 주식별자구성에 부모 주식별자 부분 필요 - 상속 받은 주식별자속성을 타 텐터티에 차단 필요 - 부모쪽은 관계참여가 선택관계
UML 표기법	실선	점선