SQLD

1) 데이터 모델링

person456 2023. 12. 24. 17:44

** 데이터 모델링

- 모델 : 현실 세계에서 일어날 수 있는 다양한 현상에 대해 일정한 표기법으로 표현해 놓은 모형

- 모델링 : 모델을 만들어가는 일

- 모델링에 갖춰야할 조건

1) 현실 세계를 반영해야 한다.

2) 단순화하여 표현해야 한다.

3) 관리하고자 하는 데이터를 모델로 설계해야 한다.

 

- 모델링의 특징

1) 추상화 (Abstraction)

- 현실세계를 일정한 형식으로 표현하는 것으로, 아이디어나 개념을 간략하게 표현하는 것

2) 단순화 (Simplification)

- 복잡한 현실 세계를 정해진 표기법으로 단순히 표현한다

3) 명확화(Clarity)

- 불분명함을 제거하고 명확하게 해석한다.

--> 데이터베이스의 모델링은 "현실세계를 추상화, 단순화, 명확하 하기 위해 일정한 표기법을 토대로 표현하는 기법"

 

- 모델링의 3가지 관점

1) 데이터 관점(What, Data)

- 데이터 위주의 모델링. 데이터와 업무의 관계, 데이터와 데이터의 관계를 모델링

2) 프로세스 관점(How, Process)

- 프로세스 위주의 모델링. 프로세스의 하는 일, 처리해야할 일은 무엇인지를 모델링하는 것

3) 데이터와 프로세스의 상관 관점(Data vs Process, Interaction)

- 데이터와 프로세스의 관계를 위주로 한 모델링. 프로세스의 흐름에 따라 데이터가 어떤 영향을 받는지를 표현

--> 모델링시 중복, 비유연성, 비일관성을 조심해야함

 

- 모델링의 3가지 단계

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

- 전사(회사 전체 차원)적 데이터 모델링 수행 시 행해지며 추상화의 레벨이 제일 높다

- 업무 중심적이고 포괄적인 수준의 모델링이 이루어진다.

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

- 재사용성이 가장 높은 모델링으로 데이터베이스 모델에 대한 Key, 속성, 관계 등을 표현하는 단계

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

- 실제 데이터베이스로 구현할 수 있도록 성능이나 가용성 등의 물리적 성격을 고려하여 모델을 표현

 

- 3단계 스키마 구조

1) 외부 스키마(External Schema)

- 사용자의 관점(Multiple User's View) 단계로 각 사용자가 보는 DB 스키마를 정의

2) 개념 스키마 (Conceptual Schema)

- 통합된 관점(Community View of DB) 단계로 모든 사용자가 보는 DB의 스키마를 통합하여 전체 DB를 나타냄

- 데이터베이스에 저장되는 데이터들을 표현하고 데이터의 관계를 나타냄

3) 내부 스키마(Internal Schema)

- 물리적 관점(Physical Representation)단계로 물리적인 저장 구조를 나타냄

- 실질적인 데이터의 저장 구조나 컬럼 정의, 인덱스가 포함됨

--> 3단계로 나누는 이유

1. 어플리케이션에 영향을 주지 않고 DB구조를 변경할 수 있어 독립성이 보장됨

2. 사용자는 DB 구조를 알 필요 없이 데이터를 볼 수 있음

--> 3단계 스키마 구조가 보장하는 독립성

--1) 논리적 독립성

- 개념 스키마가 변경되어도 외부 스키마는 영향받지 않는다.

--2) 물리적 독립성

- 내부 스키마가 변경되어도 외부/개념 스키마는 영향받지 않는다.

 

-E-R다이어그램 (Entity-Relation Diagram) 작성 순서

1) 엔터티를 도출하고 그린다

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

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

4) 관계 명을 기입한다

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

6) 관계의 필수/ 선택 여부를 기입한다.

 

 

** 엔터티(Entity)

- 사전적 의미로는 "독립체"

- 데이터베이스의 입장에서 엔터티는 "테이블"이며, 식별이 가능한 객체이자 업무에서 쓰이는 데이터를 용도별로 분류한 그룹

- 엔터티는 자신을 더 상세히 나타내기위해 속성(Attribute)를 갖는다.

 

- 엔터티의 특징

1) 업무에서 쓰이는 정보여야 함

- 엔터티로 존재하더라도 거의 쓰이지 않는다면 쓸모가 없음

2) 유니크함을 보장할 수 있는 식별자(PK)가 있어야 함

- 엔티터에 속한 인스턴스를 각각 구별할 수 있도록 식별자를 설정해야함

3) 2개 이상의 인스턴스(튜플)을 갖고 있어야 함

4) 반드시 속성을 갖고 있어야 함

5) 다른 엔터티와 1개 이상의 관계를 맺고 있어야 함

 

- 엔터티의 분류

1. 유형 vs 무형

1) 유형 엔터티

- 물리적인 형태가 존재하는 엔터티(상품, 회원)

2) 개념 엔터티

- 물리적인 형태가 없이 개념적인 엔터티(학과, 부서)

3) 사건 엔터티

- 행위를 함으로써 발생하며 통계자료로 이용 가능(주문, 이벤트 응모)

 

2. 발생 시점 기준

1) 기본 엔터티

- 업무에 원래 존재하는 정보

- 독립적으로 생성되며, 자식 엔터티를 가질 수 있음 (상품, 회원, 사원, 부서)

2) 중심 엔터티

- 기본 엔터티로부터 파생되고, 행위 엔터티를 생성하는 엔터티

- 업무에서 중심적인 역할을 하며 데이터의 양이 많음(주문, 매출, 계약)

3) 행위 엔터티

- 2개 이상의 엔터티로부터 파생

- 데이터가 자주 변경되거나 증가할 수 있음(주문 내역, 이벤트 응모 내역)

 

** 속성(Attribute)

- 사물이나 개념의 특징을 잘 설명할 수 있는 항목들

- 의미상 더이상 쪼개지지 않는 레벨이어야 하고, 프로세스에 필요한 항목이어야함

- 속성은 속성값을 가지며, 속성값은 한 개의 속성만을 가져야 한다.

-- 엔터티 > 인스턴스 > 속성

-- 한개의 엔터티는 2개 이상의 인스턴스, 한개의 인스턴스는 2개이상의 속성, 하나의 속성에는 하나의 값만.

 

- 속성의 분류

1. 특성에 따른 분류

1) 기본 속성(Basic Attribute)

- 업무 프로세스 분석을 통해 바로 정의가 가능한 속성

- 엔터티의 가장 많은 퍼센티지를 차지하고, 일부 설계 및 파생 속성을 제외한 모든 속성이 이에 해당됨

2) 설계 속성(Designed Attribute)

- 업무에 존재하지는 않지만 설계하다보니 필요하다고 판단되어 도출해낸 속성

3) 파생 속성(Derived Attribute)

- 다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형한 속성

- 계산된 값이나 가공된 값으로, 사전에 정의된 계산을 통해 조회를 빠르게 하려는 목적으로 주로 생김

- 데이터의 정합성이 고려되어야하고 불가피한 경우에만 정의하는 것이 나음

 

2. 구성 방식에 따른 분류

1) PK(Primary Key) 속성

- 엔터티의 인스턴스들을 식별할 수 있는 속성

2) FK(Foreign Key)속성

- 다른 엔터티의 속성에서 가져온 속성

3) 일반속성

- PK, FK를 제외한 나머지 속성

 

** 도메인(Domain)

- 속성이 가질 수 있는 속성값의 범위

- 데이터 타입과 크기로 나타낼 수 있음

※용어 사전 : 속성의 이름을 정확하고 직관적으로 표현하여 혼란을 없애기 위해 이용하는 것

※시스템 카탈로그 : 시스템 자체에 관련된 데이터를 담고 있는 DB. Select는 가능하지만 나머지는 안됨

 

** 관계(Relationship)

- 엔터티와 엔터티와의 관계를 의미함

1) 존재 관계

- "엄마"와 "아기"처럼 존재 자체로 연관성이 있는 관계를 의미

2) 행위 관계

- 행위를 함으로써 연관성이 생기는 관계를 의미

 

- 관계의 표기법

1) 관계명 (Membership): 관계의 이름

- 2개의 엔터티가 각각의 관계명을 가지므로, 1개의 관계에는 최소 2개의 관계명이 있음

2) 관계차수(Cardinality) : 관계에 참여하는 수

- 1:1, 1:N, N:M 관계로 나누어짐

3) 관계선택사양(Optionality) : 관계가 필수적인지, 선택인지의 여부

 

** 식별자(Identifiers)

- 각각의 인스턴스를 구별할 수 있게 해주는 대표격인 속성

1) 주 식별자

- 기본키, PK(Primary Key)에 해당하는 속성

- 유일성, 최소성, 불변성, 존재성이 보장되어야함.

- 식별자의 분류

 

1. 대표성 여부

1) 주식별자(Primary Identifier)

- 유일성, 최소성, 불변성, 존재성을 가진 대표 식별자

- 다른 엔터티와 참조 관계로 연결

2) 보조식별자(Alternate Identifier)

- 대표식별자가 아닌 것

 

2. 스스로 생성되었는지 여부

1) 내부식별자(Internal Identifier)

- 엔터티 내부에서 스스로 생성된 식별자

2) 외부식별자(Foreign Identifer)

- 엔터티 외부에서 온 식별자, 연결고리 역할

 

3. 단일 속성의 여부

1) 단일식별자(Single Identifier)

 - 하나의 속성으로 구성된 식별자

2) 복합식별자(Composite Indentifer)

- 두개 이상의 속성으로 구성된 식별자

 

4. 대체 여부

1)원조식별자(Original Identifier)

- 업무 프로세스에 존재하는 식별자, 가공되지 않은 원래의 본질 식별자

2) 대리식별자 (Surrogate Identifer)

- 주식별자의 속성이 2개 이상인 경우, 그 속성들을 하나로 묶어 사용하는 인조 식별자

 

 

**식별자 관계

1) 식별자 관계 (Identifier Relationship)

- 부모 엔터티의 식별자가 자식 엔터티의 주식별자가 되는 관계

- 주식별자는 반드시 존재해야하므로 부모가 있어야 생성 가능하며 단일인지 복합인지에 따라 1:1, 1:N이 결정

2) 비식별자 관계(Non-Identifier Relationship)

- 부모의 식별자가 자식의 주식별자가 아닌 일반속성이 되는 관