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

 

목표

데이터 모델링의 과정을 이해하고 습득하기

 

학습할 것

• 데이터 모델의 이해
• 엔티티
• 속성
• 관계
• 식별자

 

---

데이터 모델링

• 현실 세계를 형식에 맞추어 추상화하여 데이터 모델을 만드는 과정이다.
• 복잡한 현실 개체들을 제한된 표기법으로 이해하기 쉽도록 단순화해준다.
• 데이터를 효율적으로 관리하고 조작하기 위해 사용하며, 데이터베이스 설계나 소프트웨어 개발에서 활용된다.

모델링 특징

• 추상화: 현실세계를 일정한 형식에 맞추어 표현한다.
• 단순화: 복잡한  현실 세계를 간결하고 명확하게 표현한다.
• 명확성(정확성): 애매모호함을 배제하고 누구나 이해 가능하도록 관계가 명확하게 정의된다.
• 일관성: 모델의 구성요소들이 모순없이 일관되어야 한다.
• 유연성: 데이터 변경이나 확장에 대해 유연성이 있어야한다.

데이터 모델의 기능

• 가시화: 시스템을 현재 또는 원하는 모습으로 변경한다.
• 명세화: 시스템의 구조와 행동을 명세화한다.
• 문서화: 시스템 구축 과정에서 결정한 것을 문서화한다.
• 틀 제공: 시스템을 구축하는 구조화된 틀 제공해준다.
• 다양한 영역 집중: 세부사항은 넣어두고 다양한 영역을 알려준다.
• 구체하된 표현방법 제공: 특정 목표에 따라서 표현방법 제공해준다.

데이터 모델링 유의점

• 중복
  
  • 여러 장소에 같은 정보를 저장하는 일은 없어야 한다.
• 비유연성
  
  • 변경이나 확장에 대해 대응할 수 있는 유연성이 있어야 한다.
• 비일관성
  • 데이터 모델의 구성 요소들이 일관성을 유지해야한다.
  • 데이터 타입 일관성, 제약 조건 설정, 엔티티와 그 안에 속성들 간의 관계가 이 안에 포함된다

 

개념적 데이터 모델링

• 현실 세계의 개념적인 구조를 나타내는 데이터 모델이다.
• 업무 요구 사항을 분서거하고 개념적 모델을 만드는 단계이다.
• 개체-관계(ER) 모델이 주로 사용되며, 업무 중심적인 개념이 표현된다.

ERD

논리적 데이터 모델링

• 개념적 데이터 모델을 컴퓨터 시스템에서 사용할 수 있는 형태로 변환하는 과정이다.
• 업무 중심적인 개념을 key, 속성, 관계등을 정확하게 표현하도록 바꾼다.

Customer Table:
+-----------------+--------------+------+-----+---------+
| Column Name | Data Type | Null | Key | Default |
+-----------------+--------------+------+-----+---------+
| CustomerID | INT | NO | PRI | |
| Name | VARCHAR(50) | NO | | |
| Age | INT | YES | | |
| Address | VARCHAR(100) | YES | | |
+-----------------+--------------+------+-----+---------+

Order Table:
+-----------------+--------------+------+-----+---------+
| Column Name | Data Type | Null | Key | Default |
+-----------------+--------------+------+-----+---------+
| OrderID | INT | NO | PRI | |
| CustomerID | INT | NO | | |
| Date | DATE | NO | | |
| Amount | DECIMAL(10,2)| NO | | |
+-----------------+--------------+------+-----+---------+

물리적 데이터 모델링

• 실제 데이터베이스 시스템에서 구현하기 위한 구조로 변환하는 과정이다.
• 시스템의 성능, 보안, 저장 공간 등을 고려하여 논리적 모델을 데이터베이스 스키마로 변환한다.

CREATE TABLE Customer (
  CustomerID INT PRIMARY KEY,
  Name VARCHAR(50) NOT NULL,
  Age INT,
  Address VARCHAR(100)
);

CREATE TABLE Order (
  OrderID INT PRIMARY KEY,
  CustomerID INT NOT NULL,
  Date DATE NOT NULL,
  Amount DECIMAL(10,2) NOT NULL,
  FOREIGN KEY (CustomerID) REFERENCES Customer(CustomerID)
);

 

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

개념 스키마

• 개념 단계에서 데이터베이스 전체의 논리적 구조를 정의한 것이다.
• 조직 전체의 관점에서 생각하는 데이터베이스의 모습이다.

외부 스키마

• 특정 사용자 그룹이나 요구에 맞게 데이터베이스 뷰(View)를 제공한다.
• 외부 스키마는 개념 스키마를 기반으로 작성하며, 필요한 데이터 조작을 위한 인터페이스 역할을 한다.

내부 스키마

• 전체 데이터 베이스가 저장 장치에 실제로 저장되는 방법을 정의한다.
• 레코드 구조, 필드 크기, 레코드 접근 경로 등 물리적인 저장 구조를 정의한다.

 

데이터 모델링의 3요소

• things: 업무가 관여하는 어떤 것
• attributes: 어떤 것이 가지는 성격
• relationships: 어떤 것들 간의 관계

 

---

엔티티(Entity)

엔티티는 데이터 모델에서의 현실세계의 객체 또는 사물을 나타내는 개념이다.

 

엔티티의 특징

• 해당 업무에 필요하고 관리하고자 하는 정보여야한다.
• 엔티티는 반드시 속성이 있어야 한다.
• 영속적으로 존재하는 두개 이상의 인스턴스 집합이 있어야한다.
  영속적 인스턴스 예시: 고객과 같이 데이터베이스에 저장되어 데이터의 지속성을 보장해야한다.
• 최소 한 개 이상의 관계가 있어야 한다.

ERD 작성 순서

1. 엔티티를 그린다.(ex. 고객과 주문)
2. 엔티티를 적절하게 배치한다.
3. 엔티티간 관계를 설정한다.(ex. 고객과 주문간의 관계)
4. 관계명을 기술한다.ex. 고객과 주문이라면 "주문됨" 정도가 관계명)
5. 관계의 참여도를 기술한다.(관계에 참여하는 엔티티의 수를 나타냄)
6. 관계의 필수여부를 기술한다.(필수 또는 옵션으로 표시)

엔티티 분류

기본 엔티티 

• 독립적으로 존재, 다른 엔티티로부터 영향받지 않는다.
• 주로 중요한 개념이나 정보를 나타낸다.

중심 엔티티

• 다른 엔티티들과의 관계를 형성하며, 시스템의 핵심적인 역할을 수행하는 엔티티이다.
• 중재자 역할을 생각하면 편하다.(ex. 고객과 제품이 있다면 "주문" 엔티티가 중심엔티티이다.)

행위 엔티티

• 자주 내용이 바뀌거나 데이터량이 증가한다.
• 특정 행위나 동작을 나타내는 경우가 많다.
• 2개 이상의 부모 엔티티로부터 발생한다.

 

 

---

속성(attribute)

엔티티가 가지는 항목이며 더 이상 분리되지 않는 데이터 단위를 설명한다.

 

구성에 따른 분류

구성 이미지화

PK 속성

• 엔티티를 식별할 수 있는 속성이다. 

FK 속성

• 다른 엔티티와의 관계에서 포함된 속성이다.

일반 속성

• PK 속성, FK 속성에 포함되지 않은 속성이다.(ex. 날짜, 금액)

속성에 따른 분류

기본 속성

• 원래 가지고 있는 속성이자 업무로 부터 추출된 속성이다.
• 일반적인 속성으로 생각하면 편하다.

설계 속성

• 원래는 존재하지 않았지만 설계자가 추가한 속성이다.(ex. 주문번호, 예약번호 등등)

파생 속성

• 다른 속성의 영향을 받아 생기는 속성이며 데이터 조회시 빠른 성능을 내게 해준다.(ex. 평균, 합계)

 

 

 

 

---

관계

엔티티간의 관련성을 의미한다.

관계의 분류

• 연관관계(실선표현): 존재에 의한 관계이다. 
• 의존관계(점선표현): 상대 클래스의 행위에 의한 관계이다.

 

관계의 표기법

• 관계명
  •  애매한 동사 금지, 현재형으로 표현해야한다.
  1. 일대일 관계
     
     • A엔티티와 B엔티티 서로가 속성 하나씩만을 가지는 관계이다.
  2. 일대다 관계
     
     • 하나의 A엔티티는 B엔티티의 여러 속성을 가질 수있다. B엔티티는 A엔티티의 하나의 속성만 가질 수 있다.
  3. 다대일 관계
     
     • A엔티티와 B엔티티 서로가 여러 속성을 가질 수 있는 관계이다.

 

관계선택사양

• 필수관계: 모든 참여자가 반드시 타 엔터티 참여자와 관계를 가지는 관계이다. 
• 선택관계: 관련은 있지만 서로 필수적인 관계는 아닌관계이다.

관계 체크사항

※추후에 관계부분은 더 공부하고 작성예정

 

---

식별자

엔터티는 인스턴스들의 집합이다. 여러 개의 집합체를 담고 있는 하나의 통에서 각각을 구분할 수 있는 논리적인 이름이 있어야한다. 그것을 식별자 라고한다. 
참고로 식별자와 키를 동일하게 생각하는 경우가 있는데 식별자는 업무적으로 구분이 되는 정보, 키는 논리 데이터 모델링 에서 사용하며 데이터베이스 테이블에 접근을 위한 매개체로 이해하는것이 편하다.

 

식별자의 특징

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

식별자 분류

식별자 분류

식별자 관계와 비식별자 관계

• 식별자 관계
  • 부모엔터티로부터 상속받은 식별자를 자식엔터티의 주식별자로 이용하는 경우(실선 표현, 강한 연결관계)이다.
  • 식별자 관계로만 설정시, 주식별자가 많아져 조인에 참여하는 테이블에 따라 복잡성 증가한다.(오류 발생 증가)
• 비 식별자 관계
  • 부모 엔터티로부터 상속받은 식별자를 자식엔터티가 일반 속성으로만 이용하는 경우이다.(점선 표현)
  • 부모 없는 자식 생성될 경우 있다.(식별자가 일반속성 = 필수가 아니다)
  • 자식엔터티에서 별도의 식별자를 가지는게 좋은 이유: 부모엔터티와의 약한 연결관계
  • 안좋은 이유: 비식별자 관계로만 설정시, 부모엔터티와의 불필요한 조인이 많이 생성되어 sql 구문이 길어지고 성능이 저하된다.

 

식별자 관련 추가 내용

• 주식별자 도출기준
  • 해당 업무에서 자주 이용되는 속성 이어야한다.
  • 명칭, 내역 등과 같이 이름으로 기술되는 것은 지정하지 않는다.
  • 복합으로 구성되는 경우가 있는데 속성의 수가 많아지지 않도록 한다.(여러 PK를 가지면 안좋다는걸 의미한다.
• 추가로 제가 식별자관련 내용을 참고하고 공부한 사이트입니다. 도움이 될것같아 주소 남깁니다.

https://dataonair.or.kr/db-tech-reference/d-guide/sql/?mod=document&uid=329