데이터 모델의 이해

 

https://velog.io/@ajm0718/Entity

Entity

https://someone-life.tistory.com/9

[SQL] 엔터티(Entity)의 이해

엔터티(Entity)

• 정의: 엔터티는 업무상 관리가 필요한 대상들의 집합으로, 사람, 장소, 물건, 사건, 개념 등과 같은 명사에 해당합니다. 실체 또는 객체로도 불리며 데이터를 저장하고 관리하기 위한 단위입니다
• 특징:
  • 업무에 필요하고 관리해야 할 정보여야 합니다.
  • 유일한 식별자를 통해 식별 가능해야 합니다.
  • 영속적으로 존재하는 인스턴스의 집합이어야 하며, 최소 두 개 이상의 인스턴스를 포함합니다.
  • 속성을 가져야 하며, 다른 엔터티와 관계를 가질 수 있어야 합니다
• 예시: '학생' 엔터티는 학번, 이름, 주소 등의 속성을 가지며, 각 학생은 엔터티의 인스턴스로 볼 수 있습니다.

속성(Attribute)

• 정의: 속성은 엔터티를 설명하는 최소 데이터 단위로, 더 이상 쪼개지지 않는 정보입니다. 엔터티 내에서 관리되는 구체적인 정보 항목이라 할 수 있습니다
• 특징:
  • 업무상 필요하며 의미상 더 이상 분리되지 않아야 합니다.
  • 각 속성은 하나의 값만을 가지며, 유일한 식별자에 종속될 수 있습니다.
  • 속성은 기본 속성(예: 이름), 설계 속성(업무 규칙화 목적), 파생 속성(계산된 값) 등으로 구분됩니다
• 예시: '학생' 엔터티의 속성으로 학번, 이름, 전공 등이 있으며, '학점' 속성은 0.0~4.5 사이의 값을 가질 수 있습니다.

인스턴스(Instance)

• 정의: 인스턴스는 엔터티나 클래스의 구체적인 실체로, 엔터티의 개별적인 데이터 항목이나 클래스에서 생성된 객체를 의미합니다. 예를 들어, '학생' 엔터티에서 특정 학생 한 명이 인스턴스입니다
• 특징:
  • 동일한 클래스나 엔터티에서 여러 개의 인스턴스를 생성할 수 있습니다.
  • 각 인스턴스는 독립적으로 고유한 속성을 가지며 다른 인스턴스와 구별됩니다
• 예시: 'Car' 클래스에서 특정 자동차 객체(예: 빨간색 Toyota Corolla)는 해당 클래스의 인스턴스입니다.

개념	정의	특징	예시
엔터티	관리가 필요한 데이터 집합	유일 식별 가능, 영속적 존재, 최소 두 개 이상의 인스턴스를 포함	학생, 과목, 주문
속성	엔터티를 설명하는 최소 데이터 단위	더 이상 분리 불가, 하나의 값만 가짐	학번, 이름, 주소
인스턴스	엔터티나 클래스의 구체적 실체	고유한 속성을 가짐, 동일 엔터티/클래스에서 여러 개 생성 가능	특정 학생(홍길동), 특정 자동차

모델링의 개념

• 현실 세계의 비즈니스 프로세스와 데이터 요구 사항을 "추상적이고 구조화된 형태"로 표현하는 과정
• 데이터베이스의 구조와 관계를 정의하며, 이를 통해 데이터의 저장, 조작, 관리 방법을 명확하게 정의 

모델링의 특징

1. 추상화 (Abstraction)

• 현실 세계의 복잡한 데이터를 일정한 형식에 맞추어 표현하는 과정입니다.
• 다양한 현상을 표준화된 표기법으로 표현하여 공통적인 특징을 도출합니다.
• 이는 현실 세계를 단순화하면서도 본질적인 요소를 유지하여 모형화하거나 가설적 의미를 부여하는 작업입니다.

2. 단순화 (Simplification)

• 복잡한 현실 세계를 정해진 규약이나 표기법으로 표현하여 쉽게 이해할 수 있도록 만드는 과정입니다.
• 제한된 언어나 시각적 도구(예: ERD, UML)를 사용하여 데이터를 표현함으로써 일관성을 유지하고 오류를 줄이는 데 기여합니다.
• 단순화는 데이터 구조와 관계를 명확히 하여 이해관계자들이 데이터를 쉽게 활용할 수 있도록 돕습니다.

3. 명확화 (Clarification)

• 대상에 대한 애매모호함을 제거하고, 누구나 이해할 수 있도록 정확하게 현상을 기술하는 것을 의미합니다.
• 이를 통해 데이터의 해석 및 활용 과정에서 발생할 수 있는 혼란을 방지합니다.
• 명확화를 통해 데이터 모델이 모든 이해관계자에게 동일한 의미로 전달될 수 있습니다

https://sosoeasy.tistory.com/505

데이터 모델링의 의미 및 주요특징

데이터 모델링 3 가지 관점

1. 데이터 관점 (Data Perspective)

• 정의: 업무가 어떤 데이터와 관련이 있는지, 데이터 간의 관계는 무엇인지 모델링하는 방법.
• 목적: 데이터를 중심으로 업무를 분석하고, 데이터 간의 구조적 관계를 명확히 정의.
• 핵심 질문: "업무와 관련된 데이터는 무엇이며, 이들 간의 관계는 무엇인가?"
• 예시: 데이터베이스 설계 시 엔터티와 속성, 관계를 정의하는 과정.

2. 프로세스 관점 (Process Perspective)

• 정의: 업무가 실제로 수행하는 일이나 해야 할 일을 모델링하는 방법.
• 목적: 업무 흐름과 절차를 중심으로 분석하여 프로세스를 명확히 이해하고 설계.
• 핵심 질문: "업무에서 수행되는 활동은 무엇이며, 어떻게 이루어지는가?"
• 예시: 비즈니스 프로세스 모델링(BPM)이나 UML 액티비티 다이어그램을 통해 업무 절차를 시각화.

3. 데이터와 프로세스의 상관 관점 (Interaction Perspective)

• 정의: 업무 처리 방식에 따라 데이터가 어떻게 영향을 받는지를 모델링하는 방법.
• 목적: 데이터와 프로세스 간의 상호작용을 분석하여 시스템의 동작을 이해하고 최적화.
• 핵심 질문: "프로세스가 데이터를 어떻게 사용하고 변화시키는가?"
• 예시: 데이터 흐름 다이어그램(DFD)을 통해 데이터와 프로세스 간의 상호작용을 표현.

https://woondl.tistory.com/m/106

[강의] SQLD_ 데이터 모델링의 이해

데이터 모델링 유의점

1. 중복(Duplication)

• 데이터 중복은 데이터베이스의 비효율성을 초래하고, 저장 공간 낭비와 데이터 불일치 문제를 유발할 수 있습니다.
• 데이터 모델링 과정에서 동일한 데이터를 여러 장소에 저장하지 않도록 설계하여 중복을 최소화해야 합니다

2. 비유연성(Inflexibility)

• 데이터 모델이 지나치게 고정적이면, 사소한 업무 변화에도 데이터 구조를 수정해야 하는 상황이 발생할 수 있습니다.
• 데이터 정의와 사용 프로세스를 분리하여 설계하면, 작은 변화가 시스템 전체에 미치는 영향을 줄이고 유연성을 확보할 수 있습니다

3. 비일관성(Inconsistency)

• 데이터 간 상호 연관 관계가 명확히 정의되지 않으면 비일관성이 발생할 수 있습니다. 예를 들어, 한 데이터는 갱신되었지만 관련 데이터는 갱신되지 않는 경우가 이에 해당합니다.
• 이를 방지하려면 데이터 간의 관계를 명확히 정의하고 일관성을 유지해야 합니다.

4. 정확성과 완전성(Correctness and Completeness)

• 데이터 모델은 업무 요구사항을 정확히 반영해야 하며, 필요한 모든 데이터를 포함해야 합니다. 잘못된 키 정의나 관계 설정은 모델의 신뢰성을 떨어뜨릴 수 있습니다.

5. 확장성과 유지보수성(Scalability and Maintainability)

• 데이터 모델은 향후 요구사항 변화와 데이터 증가에 대비할 수 있도록 확장 가능하게 설계되어야 합니다.
• 모듈화된 설계와 명확한 명명 규칙을 통해 유지보수를 용이하게 해야 합니다.

6. 표준 준수(Standards Compliance)

• 일관된 표준과 규칙을 준수하여 엔터프라이즈 수준에서 통합적으로 관리할 수 있는 모델을 설계해야 합니다.
• 명확한 명명 규칙과 관계 정의는 협업과 이해를 돕습니다.

7. 데이터 품질(Data Quality)

• 데이터 품질은 비즈니스 성공에 중요한 요소로, 잘못된 모델링은 데이터 활용 가치를 떨어뜨릴 수 있습니다.
• 초기 단계에서부터 품질 문제를 예방하는 것이 중요합니다.

데이터 모델링 3가지 요소

1. 개체(Entity)

• 정의: 데이터베이스에서 관리하고자 하는 대상 또는 객체를 의미합니다.
• 특징:
  • 실세계의 특정 항목이나 개념을 데이터로 표현한 것.
  • 데이터베이스 테이블로 구현되며, 각 테이블은 특정 유형의 정보를 저장.
• 예시: 학생, 고객, 제품 등.

2. 속성(Attribute)

• 정의: 개체가 가지는 특성이나 정보를 나타냅니다.
• 특징:
  • 개체를 구체화하거나 설명하는 데이터 요소.
  • 데이터베이스 테이블의 열(Column)로 표현.
• 예시: 학생 개체의 속성으로 이름, 학번, 생년월일 등이 포함될 수 있음.

3. 관계(Relationship)

• 정의: 개체 간의 연관성을 나타냅니다.
• 특징:
  • 두 개 이상의 개체 간 상호작용을 정의.
  • 관계는 1:1, 1:N, N:M 형태로 표현될 수 있음.
• 예시: 학생과 강사 간의 수업 관계, 고객과 주문 간의 관계.

https://wikidocs.net/1208

04. 데이터 모델링의 3단계 진행

데이터 모델링의 3단계

1. 개념적 데이터 모델링 (Conceptual Data Modeling)

• 목적: 조직과 사용자의 요구사항을 분석하여 데이터의 전반적인 구조를 정의.
• 특징:
  • 추상화 수준이 높고, 기술적인 요소는 배제된 상태에서 비즈니스 중심으로 진행.
  • 핵심 엔터티(Entity)와 이들 간의 관계를 정의하며, 엔터티-관계 다이어그램(ERD)을 생성.
  • 사용자와 시스템 개발자 간의 의사소통을 위한 기반 제공.
• 활용 예시: 회사 내 직원, 부서, 프로젝트 등의 관계를 정의.

2. 논리적 데이터 모델링 (Logical Data Modeling)

• 목적: 개념적 모델을 기반으로 데이터의 논리적인 구조와 규칙을 명확히 정의.
• 특징:
  • 엔터티의 속성(Attribute)과 키(Key)를 정의하며, 데이터 정규화를 통해 중복을 제거하고 일관성을 확보.
  • 비즈니스 요구사항을 데이터베이스 설계에 반영할 수 있도록 구체화.
  • 물리적 구현과 독립적으로 데이터 구조를 설명.
• 활용 예시: 직원 테이블에 이름, 나이, 직책 등의 속성을 추가하고, 부서와의 관계를 명확히 설정.

3. 물리적 데이터 모델링 (Physical Data Modeling)

• 목적: 논리적 모델을 실제 데이터베이스 시스템(DBMS)에 구현 가능한 형태로 변환.
• 특징:
  • 테이블, 컬럼, 인덱스 등 물리적인 저장 구조를 설계.
  • 성능 최적화(예: 인덱스 설정, 파티셔닝)와 저장소 활용 방안을 고려.
  • DBMS의 특성에 맞춰 데이터 저장 및 접근 방식을 설정.
• 활용 예시: MySQL 또는 Oracle DBMS에서 실제로 직원 테이블과 부서 테이블을 생성하고 관계를 구현.

스키마의 3단계 구조

 

1. 외부 단계 (External Level)

• 정의: 사용자나 응용 프로그램 관점에서 데이터베이스를 표현하는 단계.
• 특징:
  • 외부 스키마(View Schema)가 존재하며, 사용자가 필요로 하는 데이터만 정의.
  • 각 사용자 그룹은 자신에게 필요한 데이터만 접근 가능하며, 나머지 세부사항은 숨겨짐.
  • 여러 개의 외부 스키마가 존재 가능.
• 예시: 학생은 자신의 학적 정보만 볼 수 있고, 교수는 강의 정보만 접근할 수 있는 경우.
• 장점: 사용자 편의성과 보안성 향상.

2. 개념 단계 (Conceptual Level)

• 정의: 조직 전체 관점에서 데이터베이스의 논리적 구조를 정의하는 단계.
• 특징:
  • 개념 스키마(Conceptual Schema)가 존재하며, 데이터의 논리적 구조와 제약 조건을 정의.
  • 모든 외부 스키마는 이 개념 스키마를 기반으로 생성됨.
  • 데이터의 무결성과 일관성을 유지하며, 조직 전체에서 필요한 데이터를 통합적으로 관리.
• 예시: 학생, 과목, 교수 등의 개체와 이들 간의 관계 정의.
• 장점: 논리적 데이터 독립성 보장(개념 스키마 변경 시 외부 스키마에 영향 없음).

3. 내부 단계 (Internal Level)

• 정의: 물리적 저장 장치 관점에서 데이터베이스를 표현하는 단계.
• 특징:
  • 내부 스키마(Internal Schema)가 존재하며, 데이터 저장 구조와 접근 경로를 정의.
  • 테이블 저장 방식, 인덱스 설정, 물리적 레코드 순서 등을 포함.
• 예시: 테이블이 디스크에 어떻게 저장되고, 인덱스가 어떤 방식으로 설정되는지 정의.
• 장점: 물리적 데이터 독립성 보장(내부 스키마 변경 시 개념 스키마에 영향 없음).

https://prinha.tistory.com/

[DB] 3단계 데이터베이스-외부/개념/내부스키마

https://computer-science-student.tistory.com/501

3단계 데이터베이스 구조

1. 모델링 3요소

• 개체(Entity): 관리하고자 하는 데이터의 대상(테이블).
• 속성(Attribute): 개체가 가지는 특성(컬럼).
• 관계(Relationship): 개체 간의 연관성(외래키 등).

2. 스키마 3요소

• 외부 스키마 (External Schema): 사용자 관점에서 필요한 데이터만 보여주는 논리적 뷰.
• 개념 스키마 (Conceptual Schema): 데이터베이스 전체의 논리적 구조를 정의.
• 내부 스키마 (Internal Schema): 데이터 저장 방식과 물리적 구조를 정의.

모델링 요소	스키마 요소	설명
개체(Entity)	개념 스키마	개체(Entity)는 개념 스키마에서 테이블로 정의되며, 데이터베이스 전체 구조에 포함됨.
속성(Attribute)	외부 및 개념 스키마	속성은 외부 스키마에서 사용자에게 필요한 데이터로 선택적으로 노출되며, 개념 스키마에서 모든 속성이 정의됨.
관계(Relationship)	개념 및 내부 스키마	관계는 개념 스키마에서 엔터티 간의 연관성을 정의하며, 내부 스키마에서는 이를 물리적으로 구현(예: 외래 키).

3단계 스키마의 독립성

 

1. 논리적 데이터 독립성

• 정의: 개념 스키마가 변경되어도 외부 스키마(사용자 관점)나 응용 프로그램에 영향을 주지 않는 특성.
• 적용 사례:
  • 테이블의 속성(컬럼)을 추가하거나 삭제하는 경우.
  • 엔터티 간의 관계를 재설계하는 경우.
• 보장 방법:
  • 외부 스키마와 개념 스키마 간의 매핑을 통해, 외부 스키마는 개념 스키마 변경에 의존하지 않도록 설계.
• 예시: 전화번호 속성이 "연락처"로 이름이 바뀌더라도, 외부 스키마에서 이를 매핑 정보로 처리하여 사용자에게는 동일한 이름으로 제공 가능.

2. 물리적 데이터 독립성

• 정의: 내부 스키마(물리적 저장 방식)가 변경되어도 개념 스키마(논리적 구조)나 외부 스키마에 영향을 주지 않는 특성.
• 적용 사례:
  • 데이터 저장 방식 변경(예: 파일 포맷, 인덱스 추가/삭제).
  • 데이터베이스 파일 위치 변경 또는 파티셔닝 적용.
• 보장 방법:
  • 개념 스키마와 내부 스키마 간의 매핑을 통해, 내부 저장소 변경이 논리적 구조에 영향을 미치지 않도록 설계.
• 예시: 테이블의 물리적 저장 순서를 변경하거나 인덱스를 추가해도 논리적 데이터 모델과 사용자 쿼리는 그대로 유지.

https://prinha.tistory.com/

[DB] 3단계 데이터베이스-외부/개념/내부스키마

데이터 모델링 표기법

• 엔터티(Entity)와 엔터티 간의 관계(Relationship)를 시각적으로 표현한 다이어그램
• 1976 년 피터 첸(Peter Chen)이 만든 표기법, 데이터 모델링 표준으로 사용