본문 바로가기

컴퓨팅

관계형 데이터 모델링_모든 내용

MODEL

- 어떤 목적을 가지고 진짜를 모방한 것

- 목적 : 관계형데이터베이스의 '표(Table)'에 정보를  담는 것

- 효과 : 일단 모델(표)이 완성되고 나면 그 다음 데이터는 엄청난 양의 데이터를 빠른 속도로 다룰 수 있다. 

 

*그러나 거대하고 복잡한 현실세계를 정보로 만들어서 표에 담는 것이 매우 힘든 작업이라는 점.

이러한 힘든 작업은 일반인이 하기 힘들었지만 점점 내용이 체계화 되면서

DATA MOELING이라는 이름으로 현실세계를 컴퓨터로 옮기는 학문이 탄생했다. 

 

DATA MODELING의 전체 흐름

1. 업무 파악

2. 개념적 데이터 모델링

3. 논리적 데이터 모델링

4. 물리적 데이터 모델링

 


1. 업무 파악

현실세계에서 분석하려는  실무에 대해 개념적으로 이해해야 컴퓨터로 정확히 프로그래밍 할 수 있다.

그 일에 익숙해져서 아는 것으로는 컴퓨터를 이해시킬 수 없기 때문에 개념적으로 분석할 필요가 있는 것.

 


2. 개념적 모델링

업부라는 현실과 데이터 베이스라는 또 다른 현실이 있을 때 그것을 동기화시키는 작업.

따라서 두번 째 순서이지만, 이미 업무와 관계형데이터베이스 설계에 정통해야 그 개념을 명확하게 뽑아낼 수 있다.  

 

개념적 모델링이 우리에게 주는 효용

1) 필터 : 현실에서 개념을 추출하는 일종의 필터를 제공

2) 언어 : 개념에 대해서 다른 사람들과 소통하게 해주는 언어로서 작용

 

이러한 목적을 이루게 해주는 도구 : ERD

Entity Relationship Diagram

1. 전체 개념도    *수정사항 : kim ~ developer,2019.01.01, 내용입력해주세요2->저자이름

하나의 세포에서도 무수한 일이 일어나듯 우리의 현실세계는 무한히 복잡하다.

이렇게 복잡한 현실에서 개념을 뽑아내는 것은 무척이나 힘든 일이다. 

 

ERD는 현실을 3계의 관점으로 필터링하여 개념화를 도와준다.

- 정보 : 현실세계 속 정보를 발견하고, 또 다른 사람에게 표현할 수 있도록 한다. ~ Attribute

- 그룹 : 서로 연관된 정보를 그룹핑하여 인식시키고 다른 사람에게 표현할 수 있도록 한다. ~ Entity

- 관계 : 정보 그룹 간의 관계를 인식하고 다른 사람에게 표현할 수 있도록 한다. ~Relation

 ERD를 만드는 방법

1) ERD는 Python_캡슐화/객체화 처럼 기능단위로 만든다.

2. Entity설계

기능 단위로 쪼개면서 생기는 장점

- 필요한 기능으로 그룹핑할 수 있다.

- 기능끼리의 결합을 통해 중복을 최소화 시킴으로서 메모리 자원을 효율적으로 사용시킬 수 있다. 

 

예시에서 현실세계에서 뽑아낸 '댓글','글','저자' 와 같은 개념을

ERD(개념적 모델링)에서는 Entity 라고 부른다.

그리고 이 Entity는 표(Table)로서 정리된다.

 

그리고 Entity는 정보의 집합으로서 표현했다.

그림1 을 보면,  '글'이라는 Entity에서 우리는 (제목_업무파악), (생성일_2019.06.05), (본문) 이라는 정보를 묶어냈다.

우리는 Enitity에 속한 각각의 정보를 Attribue 라고 하고 이 Attribute는 표의 칼럼(Column)으로 정리된다.

 

*의문 해결

kim,lee와 같은 저자는 왜 '글'Entity의 Attribute가 아닌가?

:단순히 kim,lee와 같은 저자로서의 정보만 있으면 속성이 된다. 그러나 그 저자가 개발자이고 가입일이 언제고 와 같은 정보도 같이 있기 때문에 다른 엔티티로 분할시킨 것이다.

즉 Entitiy를 디렉토리, Attribute를 파일이라고 비유를 해보면

Entity란 파일만 담을 수 있고 자식 디렉토리는 품을 수 없는 제한적인 디렉토리다.

 

2) Entity(엔티티) 간의 관계를 표현해준다. 

3. Entity 간 관계 설정

 Entity를 뽑아냈으면 우리는 이 Entity 간의 관계를 설정해야 한다.

ERD에서는 이를 Relation이라고 부른다.

논리적모델링에서는 PK(기본키), FK(왜래키)로 이 Relation(관계)이 맺어지며 물리적모델링에서는 JOIN을 통해 구현된다.

3) Identifier(식별자)를 지정해준다.

대한민국 국민에게는 주민번호가 있고, 자동차에는 자동차 번호가 있듯,

Entity에서 그 Entitiy를 대표할 수 있는 속성을 찾아야한다.  > 나중 논리적 모델의 PK,FK로서 JOIN기능을 수행

따라서 대표하는 속성이란 원하는 속성에 있는 대상(정보)를 중복없이 정확하게 타겟팅한다.

 

예를 들어서 식별자에 대해 더 자세히 알아보자.

4. 식별자 설정 예시

다음과 같은 표가 있을 때

다른 정보와 중복되지 않는 속성은 ueser_id, email, nation_id 이다. 이것을 식별자로 지정할 수 있는 후보라고 해서 후보키(candidate key)라고 지칭한다.

이 중에서 user_id처럼 자연스럽게 행이 추가될 때 마다 각 숫자를 붙이는 것을 자연스러운 키는 아니다 라고 해서 '인조키' 라고 부르는데 이걸 떠나서 요 속성/컬럼을 기본키(Primary key)라고 지정했다고 해보자.

그러면 나머지 후보키인 email, nation_id는 따로 대체키(Alternate key)라고 지칭한다.

다른 방법으로 email과 nation_id를 복합시켜서 키를 만들 수도 있겠다. 이것을 중복키(Composite key)라고 한다.

 

자 다시 실습으로 돌아오면

5. Entity, Attribute 개념화

밑줄 : 각 Entity에서 모두 식별자(identifier)로 둘 만한 것이 없어서 인조키를 식별자로 두었다.

마름모 : Relation(PK와FK의 연결관계)이다. 

4) Cardinality, Opionality 따져보기

Cardinality : 엔티티간 상위(그룹)관계 따지기 (일대일, 일대다, 다대다)

Optionality : 엔티티간 종속관계 따지기 (필수관계, 옵션관계)

6. ERD 완성

 

*추가) 실습

관계 밝히기 꿀팁ex.

[서비스 발생]이면 Id_origin, Id_task의 값을 [서비스 발생]에서 선택한 값을 가질 수 있고  

[서비스 관계]이면 eventtype, timesmap [서비스 관계]에서 선택된 값이 (서비스발생)에 할당/수렴된다.

*까치발을 여러 선택지 1,2,3으로 연상 


3. 논리적 데이터 모델링

  • Mapping Rule
  • Normalization

가장 중요하고 어려운 개념적 모델링이 완료되었다면, 논리적 데이터 모델링은 꾀나 기계적인 작업이다. 

개념적 모델링이 현실세계의 개념을 뽑아내는 것이라고 한다면,  그 개념을 관계형 데이터베이스(RDBMS)에 맞게 잘 정리정돈 하는 것이 논리적 모델링이다. 

1. Mapping Rule을 통한 변환

ERD에서 표현한 내용을 관계형 데이터(RDMS)에 맞는 형식으로 변환할 때 사용하는 방법론

7. Mapping Rule 변환요소 3가지

Entitiy는 빈 테이블로 만들고, Atrribute는 칼럼으로 만드는 너무 쉬운. 생각해야할 것은 Realtion이다. 

*Entity간 Relation을 맺기 위해서 기본키 식별자를 이용한다고 했다.

이 기본키 식별자 에서 어떤 엔티티 속성을 PK로 할지 FK로 할지는 FK만 결정하면 된다.

가장 먼저 엔티티를 대표하는 속성인 기본키 식별자가 그대로 PK로 유지된다. 이름이 같은 이유이기도 하다.

그 다음 FK를 설정하기 위해서는 어떤 엔티티가 더 상위 엔티티인지 따지면된다. 부모테이블과 자식테이블로 나누어 본뒤,  자식테이블 속성에 부모PK를 FK로 부여하여 서로를 관계시킨다. 

 

*Mapping Table을 만든다.      

N:M (다대다)관계에서는 FK가 중복 값을 갖게되는 현상이 필요함으로 중간 다리 역활인 Mapping Table이 필요하다. 

왜 Mapping Table이 필요한지에 대해 먼저 알아보자 .

1) 1:1 에서는 값이 중복되지 않으므로 부모자식 관계만 생각하여 FK를 정하면 된다. 

8. [1:1 관계]  *부모테이블:저자 ,자식테이블 :휴먼저자

 

2) 1:N에서는 데이터 값은 중복해서 나올 수 있어도, FK자체가 중복값을 갖지는 않는다_맵핑테이블 필요없다.

9. [1:N 관계] _author와 comment / topic과 comment

3) author와 topic을 관계맺는데 있어서 서로의 주요키를 참고했더니 값 자체가 중복일 경우가 생긴다.

즉,   맵핑테이블을 통해 중복을 없애는 것이  필요!

10. [N:M 관계]에서 FK값 자체의 중복문제
11. [N:M관계] Write 맵핑테이블을 참고하는 것으로 중복 해결 *created란 정보도 추가함

논리적 모델링 산출물 : Mapping Rule 결과

12. 논리적모델링 완성

2. Normaliztion(정규화)

정규화 : 정제되지 않은 테이블을 관계형 데이터베이스 테이블에 맞게끔 변환하는 방법

총 6가지 정규화 방법이 있지만 1~3 정규화가 산업에서 많이 사용되고 그 이상은 학술적으로 논의되는 경우가 많으므로 1~3 정규화까지 알아보고자 한다.

 

13. 정규화 방법 6가지

1) 제1 정규화

모든 칼럼에서 값은 하나씩 원자 단위로 형성되어야 한다. 

-  조회에서의 문제점 : SELECT * FROM topic WHERE tag='free'

- 정렬에서의 문제점 : SELECT * FROM topic ORDER BY tag

- 조인에서의 문제점 

 

예를 들어보자. 

14. 잘못된 제1 정규화

오류1 ~ tag를 제외한 나머지 칼럼의 데이터가 중복된다.

오류2 ~ 불필요하게 칼럼이 더 늘어났고, 단일 값의 경우 tag2는 NULL값이 된다. 

 

해결  **전제 : tag가 topic의 title에 의해 결정된다고 했을 때

15. 제1 정규화

topic과 tag의 관계는 M:N의 관계다. 이러한 경우 Mapping Table을 통해 문제를 해결했던 것을 기억해보자.

새로운 맵핑테이블에서 topic과 tag가 서로 참조되며 정보의 누락과 중복이 모두 제거했다. 

 

2) 제 2정규화 

테이블 간 부분 종속성이 없어야 된다.

이 말은 테이블에서 PK가 중복키로 설정되어 있다면 분리시켜야 한다는 말이다.   

PK가 중복이 되는 것은 다른 속성(칼럼)의 값을 구별하 기준을 만들기 위해서이다. 그러한 부분적으로 종속되는 속성들을 따로 모아 파편화_Mapping Table 한다.

 

예시.  *전제 : title에는 [descrpitiopn, created, author_id, author_name]이 종속되고,  title&type에 price가 종속된다.

 

16. 제 2정규화

topic 자체에 종속되는 속성들만 따로 모으고

topic과 type에 의해 부분적으로 종속되었던 price를 따로 테이블을 만들어서 관계시키는 방법으로 해결했다. 

 

3) 제 3정규화 

테이블에서 이행 종속성을 없앤다. 

 

마찬가지 예를 들어보자.

17. 제 3정규화

제 2정규화까지 시행되었던 예시를 또 다시 살펴보고 문제점을 살펴보자.

(문제 살펴보기)

-Topic 엔터티의 title 기본키 속성에 [description, created, author_id, author_name, author_profile] 들이 종속되어있다. 

- 그런데 살펴보면 auhor_id에 [author_name, author_profile] 이 또 종속/의존되어 있음을 확인할 수 있다. ->이행 종속성

- 이러한 이행 종속성 때문에 테이블에서 중복이 발생했다.

 

(문제 해결)

- 이행 종속성이 발견되는 속성들만 따로 빼서 파편화_Mapping Table 한 뒤 이름은 author라고 지정하고 author_id는 나중 topic이 참조하는 속성임을 구별하기 위해 id로 지정한다.

-  말했듯이, 메인 테이블인 topic에서도 author테이블을 참조해야 하기 때문에 author테이블의 id를 참조할 수 있는 author_id 칼럼을 생성한다. 

- 따라서 topic테이블이 author테이블을 참조하기 위해 topic의 author_id 속성이 FK가 된다. (FK는 중복여부 상관없음.) 

 

*심화

18.이행 종속성 _심화

만약 원래 테이블에서 author_id가 없다 하더라도

이렇게 데이터가 중복되는 경우에는 어떤 특정 속성에 암시적으로 종속되는 것임을 인식한 뒤

author_id 등의 Mapping Table에서 기본키가될 속성을 따로 생성시키는 것이 중요하다.


3. 물리적 데이터 모델링

논리적 데이터 모델링이 관계형데이터베이스(RDMS)에 알맞은 표를 만드는 것었다면

물리적 데이터 모델링은 이렇게 만들어진 표를 프로그램에 최적화되게 구현하는 것을 의미한다. 

쉽게 코딩한다 라고 생각하면 되겠다. 

좋은 성능으로 구현시키기 위한 여러가지 방법이 존재한다.

 

우선 성능이 떨어진다면 어디서 느려지는지를 찾고 방법을 찾아봐야한다.

 

방법1. Index

인덱스는 행에 대한 '읽기 성능'을 비약적으로 향상시킨다.

그러나 '쓰기 성능'을 비관적으로 희생시킨다.

쓰기가 이뤄질 때마다 저장공간은 물론 인덱싱되어 있는 행을 잘 정돈시키기 위한 추가적인 연산 또한 발생하기 때문이다.

 

방법2. application

index로 해결되지 않는다면, RDBMS Application(ex.eclipse)에서 캐시(cache)와 같은 것을 만질 수 있다.

캐시는 저장한다는 뜻으로 입력에 따른 실행결과를 저장해두었다가, 동일한 입력이 발생할 때 저장해둔 결과를 출력함으로서 연산의 부하를 줄여주는 방법이다.

 

방법3. denormalization (역정규화)

여러가지 방법으로도 성능향상에 문제가 있다면, 표의 구조를 바꾸는 역정규화를 시행할 수 있다.

 

 

 

 

 

 

출처 : https://opentutorials.org/module/4134

 

관계형 데이터 모델링

수업소개 관계형 데이터베이스의 테이블을 설계하는 방법을 알려드리는 수업입니다. 이 수업은 아래와 같은 내용을 담고 있습니다.  데이터 모델링의 효용 업무파악 개념적 데이터 모델링 논

opentutorials.org

 

'컴퓨팅' 카테고리의 다른 글

Python_generator  (0) 2021.02.16
Pandas_DataFrame _processing_Tech  (0) 2021.01.18
카디널리티란  (0) 2021.01.16
Anaconda_prompt  (0) 2021.01.16
python_English to Korean  (0) 2021.01.15