귤귤의 대모험

이전 포스팅에서 정규화 이론이 왜 중요한가?

데이터 이상 현상을 제거하기 위해 정규화 이론은 중요하다고 하였습니다

데이터 구조적인 측면에서 중복되는 데이터에 대해서 독립 개체로

관리하기 위해서도 정규화 이론은 필요하다고 했습니다

그 밖에 또 무엇이 있을까요?

더 자세히 알고 싶다면 아래의 링크를 클릭해서 확인하시길 바랍니다

2022.08.22 - [Data_Modeling/Methodology] - 데이터 모델링 정규화 이론이 너무나도 중요한 이유는?

정규화의 의의

데이터 모델링의 핵심이론인 정규화 이론은 몇 가지 특징을 가지고 있습니다

첫째, 속성 간의 종속성을 기준으로 성격이 유사한 속성들은 모이고 관계없는 속성들은 분리합니다

행위와 관계를 구분하고 본질을 파악하여 범주화하는 것이 핵심입니다

둘 때, 정규화는 함수 종속을 없애고 밀접한 속성을 하나의 표에 집약시키는 체계적인 방법입니다

따라서 데이터는 응집도는 높고 결합도는 낮게 분리합니다

결국, 데이터 본질에 충실한 제대로 된 엔터티가 도출될 수밖에 없습니다

셋째, 데이터 중복이 최소화된 효율적이고 구조화된 모델입니다

데이터 이상 현상이 사라지게 됩니다

넷째, 주식별자는 인스턴스를 구분하는 기준이므로 집합의 개체 발생 규칙도 검증되어 더 장확 해집니다

즉, 주 식별자만으로 엔터티가 어떻게 관계되었는지만 본다면

어떻게 데이터가 관리되고 저장되는지

규칙을 확인할 수 있습니다

다섯째, 업무 변경에 따른 확장성이 좋습니다

속성과 그에 따른 데이터가 엔터티 별로 독립 개체로 구성되어

범용성이 높게 구성됩니다

그래서 사용자가 새로운 업무를 추가할 때

확장성이 좋습니다 

여섯째, 데이터 중복을 최소화함으로써 데이터 무결성을 극대화합니다

정규화 과정을 거치면 데이터의 중복성을 제거합니다

그리고 독립 개체를 만들어 데이터 무결성을 보장할 것입니다

일곱째, 정규화된 모델은 그렇지 않은 모델에 비해 대부분 성능이 좋다.

이 부분은 동의를 못하는 사람이 있을 수 있다

정규화가 된 데이터 모델링은 테이블이 늘어나서

조인이 증가하여 성능이 저하된다고 생각할 수 있습니다

아래에서 더 자세히 설명하겠습니다

정규화가 정말 성능 저하의 원인일까?

정규화를 하게 되면 한 개의 테이블이 두 개의 테이블로 분리해야 합니다

그렇게 되면 조인이 증가하기 때문에 성능이 저하될 거라고 합니다

정규화되지 않은 테이블에서는 중복된 데이터를 더 읽어야 하고

정규화가 된 테이블에서는 조건에 맞는 데이터만 읽어 빠르게 처리할 수 있습니다

하지만

조인이 필요하다는 것은 변화가 없지요

인덱스만 정확히 정의되어 있다면 성능상의 차이는 미미할 것입니다

그리고 테이블의 한 행이 2K고 한 블록의 크기가 8K라면 한 블록에서 4개의 개체가 담길 수 있습니다

DBMS는 한 블록, 즉 IO의 최소 단위가 블록이기 때문에 8K를 메모리로 올립니다

그래서 SQL 최적화할 경우 조회할 레코드 수가 아닌 블록의 수가에 집착하는 이유도 바로 이것 때문입니다

그렇기 때문에

정규화가 IO의 대상이 되는 블록수를 줄여줄 수 있는 이야기가 됩니다

모든 속성이 한 개의 테이블에 담겨 있다면 조회하는 속성의 수가

많고 적음에 상관없이 항상 전체 블록을 읽어야 합니다

그러나 정규화가 잘되어 있다면 훨씬 적은 블록을 읽고도 원하는 결과를 얻을 수 있습니다

물론 조인이 많이 걸려 여러 테이블을 조회하는 것이 시간 소요가 발생할 수 있지만

만약 정규화가 된 여러 테이블이 정규화하지 않은 한 개의 테이블로 관리한다면

그것 또한 관리하는 입장에서는 아찔할 수밖에 없습니다

OLTP에서 조인에 의한 성능 저하가 극심한 경우라면 조인의 방법이 잘못되었을 경우가 큽니다

인덱스가 없거나 조인 연결이 이상하게 되어 옵티마이저가 인덱스를 사용하지 못하는 등의 문제지

조인 자체가 문제의 본질인 경우는 드물기 때문입니다

그리고 최근에는 컴퓨터 성능이 좋아져 이전만큼 성능 저하를 많이 느끼지 못합니다

그래서 정규화 때문에 성능 저하라고 하는 것은 조금 아이러니하지요

관리하는 측면에서 정규화는 매우 중요하다는 것이며,

정규화 때문에 성능 저하가 아닌 다른 문제 해결이 정답일 것입니다

데이터 구조적 측면에서 이득이라고 생각합니다

전체적인 것을 본다면 정규화는 대부분의 경우에서 더 뛰어난 성능을 보입니다

프로젝트 성패를 결정짓는 데이터 모델링 이야기 中 김상래 지음

이제 정규화라는 것에 대해 조금은 알 수 있었으면 합니다

몇 개의 포스팅에서 지긋지긋하게 다뤘기 때문에

이제는 조금 익숙해지지 않았을까 합니다

저도 이번 기회에 조금 더 공부하는 계기가 되었습니다

IT공부는 즐거울 때도 정말 지루할 때도 있지만

공부하고 그 결과가 바로바로 올 수 있는 몇 안 되는 직업이라고 생각합니다

능력만 있으면 인정받을 수 있으니 더 힘을 내 봅시다

그럼 우리의 IT 대모험은 끝나지 않았으니

파이팅 하시길 바랍니다

이전 포스팅 모델러의 마음가짐이란?

이전 포스팅에서는 데이터 모델러에 있어 

마음가짐을 어떻게 해야 하는지에 대하여 알아보았습니다

스키마 구조와 모델을 보는 3가지 관점이 왜 중요한지

사용자 관점에서만 모델링을 하다보면

불필요한 공수가 발생하여 장기간 운영해야 하는 서비스에서는

너무나도 불합리한 것이었지요?

더 궁금한 것이 있다면

아래의 링크를 클릭해서 확인하시면 되겠습니다

2022.08.16 - [Data_Modeling/Methodology] - 데이터 모델링의 중요한 마음가짐이란 무엇일까?

데이터 모델링 정규화 이론의 중요성

데이터 모델링에 있어 정규화 과정은 어느 책에든 강좌를 봐도

빠지지 않고 이야기하는 이론입니다

그 이유는 2차 원표(DBMS)에 어떤 데이터를 어떻게 담는 것이 최적인지 고민하는 과정입니다

그 고민에 어떻게 담는 것이 가장 적합한지 알아보기 위해서는 

정규화 이론이 가장 이상적이기 때문입니다

구조적으로 데이터 이상 현상이 존재하지 않는 데이터 구조가 이상적입니다

하지만 위와 같이 데이터가 구조가 구축되어있다면,

아래와 같이 문제점이 발생합니다

- 평가 코드 결과가 홍길동이라는 학생에 대한 정보는 입력이 불가능합니다

- 과목 코드가 CR11인 과목의 이름이 '심리학 입문'으로 변경되면

박영진과 김영희의 CR11 관련 열을 모두 찾아서 수정해야 합니다

- 김영희 F학점 평가 결과를 삭제하면 논리학 개론 과목도 함께 삭제됩니다.

데이터 이상 현상은 속성의 값을 수정할 때나 새로운 개체를 삽입하거나 삭제할 경우 의도하지 않은

다른 데이터에 문제가 발생하는 현상입니다

그런 데이터 이상 현상이 발생하는 데이터 구조를 가지고 있다면,
이상 현상의 원인은 데이터가 독립적이지 않고 중복으로 관리되어

데이터 간의 종속성에 계속 영향을 받기 때문입니다

하나의 종속성이 하나의 표로 관리되도록 분해해가는 과정이 바로 정규화입니다

즉, 종속성을 기준으로 데이터를 어떻게 담는 것이 최적인가에 대한 방법론이 바로 정규화 이론입니다 

1 정규화 적용 사례

* 1 정규화에서는 모든 속성이 값을 반드시 하나만 가져야 합니다

자격증 정보를 사원에 종속된 정보가 아니라 독립된 개체 정보로 유일하게 관리하고자 합니다

아래와 같이 사원이 자격증을 여러 개 가지고 있다면 문제점이 발생한다

그래서 사원 보유 자격증을 만들어서 관리합니다

하지만 이것 또한 문제점이 발생합니다

자격증별로 어떠한 이슈가 있을지 모르기 때문입니다.

그래서 아래와 같이 자격증을 독립적인 개체로 만들어주는 것이 좋습니다

그러면 범용적으로 자격증에 수장 지원 여부나 진급 시 필요한 필수 자격증 여부 등 여러 값들을 관리할 수 있습니다

그래서 1: N로 개체가 연결될 가능성이 있다면 독립 개체로 관리해야 합니다

2 정규화 적용 사례

* 모든 속성이 반드시 주 식별자 전부에 종속되어야 합니다

* 1 정규화로 생성된 집합은 자식이며, 2 정규화로 분리된 집합은 부모가 됩니다.

아래와 같이 데이터가 구성되어있다면

2 정규화를 거쳐서 2개로 분리가 됩니다

그 이유는 단체명이 변경된다면 데이터 이상현상이 발생하기 때문입니다

이때 단체 번호에 종속된 속성을 전부 별도 엔터티로 분리를 합니다

즉, 계약 번호는 같지만, 계약 주체인 단체가 다를 경우에는 계약 내용 등이 다를 수 있음을 주식 별자가 설명하고 있습니다

이렇게 설명은 안되어있지만 엔터티만 보고도 계약과 단체의 데이터 관계를 이해할 수 있어야 합니다

3 정규화 적용 사례

* 주 식별자가 아닌 모든 속성이 상호 종속 관계여서는 안됩니다.

아래와 같이 <고객명>과 <고객등급> 속성은 <고객번호>에 함수적으로 종속되어 있습니다

오른쪽과 같이 고객 집합을 별도로 분리하여 <고객> 엔터티로 만드는 과정이 필요합니다

실제 현장 모델링에서 가장 근원적이고 기반이 되는 핵심사상이 바로 정규화 이론입니다

그리고 통상 4 정규화 이상의 모델은 폭넓게 사용되지 않고 있습니다

이렇게 데이터 이상 현상을 줄이기 위해서는 정규화 이론은 필수 이론이라고 할 수 있습니다

숙지가 잘 안 되더라도 반복적으로 보며 생각하면서

정규화에 대한 개념을 확실히 잡는 것이 중요합니다

그래서 엔터티를 보기만 해도 데이터의 관계성을 파악해서

모델러의 의도를 파악하는 것이 개발자로도 필요한 덕목이라고 생각합니다.

그럼 앞으로 언젠가는 모델러가 될 여러분의 미래를 생각하며

오늘도 한걸음 나아갑시다!

파이팅!!

프로젝트 성패를 결정짓는 데이터 모델링 이야기 中 김상래 지음

이전 포스팅에서 데이터 모델링의 범주화와 추상화에 대해서 알아보았습니다

너무나도 범주화가 중요했지요

범주화는 본질을 정확하게 파악해서 성격이 유사한 개체로 묶는 과정이었습니다

추상화는 가장 핵심적인 특성만 추리하는 과정입니다

이렇게 과정을 거치면서 본질과 현상을 구분하여 본질적인 개체를 무시하게 되면

큰 문제점이 드러나는 것도 알아보았습니다

더 자세한 사항을 알고 싶다면 아래의 포스팅을 확인해보세요

2022.08.12 - [Data_Modeling/Methodology] - 데이터 모델링 개제의 본질적인 정보와 역할 정보를 구분해야 하는 이유는? 범주화와 추상화의 중요성은?

3단계 스키마 구조가 중요한 이유

데이터 모델링을 공부한다고 하면

정말 자주 나오는 것이 3단계 스키마 구조입니다

외부 스키마, 개념 스키마, 내부 스키마

이 3개의 스키마 구조인 이 단어들을 많이 들어보셨을 것입니다

하지만

이 스키마 구조가 왜 중요한지에 대해서는

생각해보지 못했을 수도 있다고 생각합니다

이론적으로 접근해서 

외부 스키마는 사용자 관점의 정보 단위 뷰

개념 스키마는 사용자 관점을 데이터 관점으로 통합한 뷰

내부 스키마 데이터가 DBMS에 저장되는 논리적 구조

위의 사항으로만 인지하고 실제 모델링할 경우

생가지 못한 상황이 발생할 수 있습니다

이제 이야기를 한번 해봅시다

개념 스키마는 외부 스키마와 독립된 계층이라는 것입니다.

하지만 프로젝트를 하다 보면 이상한 구조의 스키마를 보게 됩니다

외부 스키마를 다루듯 테이블을 화면별, 업무 프로세스별로 만드는 경우가 그런 상황입니다

이렇게 되면 스키마가 독립성이 줄어들고 결합도만 커지는 상황이 생깁니다

이런 상황이 발생하면 좋은 스키마 구조라고는 할 수 없습니다

외부 스키마에서 정의된 것들이 개념과 내부 스키마를 무시한 채 구조가 정립된 거라고 할 수 있습니다

화면이 변경되면 테이블을 수정하거나 새로운 테이블을 만드는 상황이 올 수도 있다는 것입니다.

그럼 새 프로그램을 개발하는 상황이 되고 그것을 운영하려면 테스트도 새롭게 해야 합니다.

결론적으로 새로운 공수가 발생하게 됩니다.

그래서 데이터의 독립성을 정확하게 분석하고 이해해서

데이터 독립성을 해치지 않도록 개념 스키마에 근거해서 모델링해야 합니다.

개념 스키마는 외부 스키마보다 데이터의 본질에 가깝습니다.

그 본질을 무시한 체 외부 스키마의 사용자 관점으로 모든 것을 개발하게 되면

개발자들의 공수들이 늘어나게 되며 이것은 운영에서 지속적인 스트레스가 발생할 수 있습니다 

그 데이터들의 형태들을 생각해서 유사한 것을

묶을 수 있는 범주화가 필요할 것입니다

범주화는 이전 포스팅에서 알아보았습니다

우리가 결국 만드는 것은 저장 구조입니다

그 구조의 형태는 스프레드 시트와 같은 2차원 표며,

그 표에 어떤 데이터를 어떻게 관리할 것인지를 고민하는 것이 데이터 모델링입니다

이렇게 우리는 이론적으로 간단하게 생각할 수도 있는 스키마 구조를

본능적으로 이러한 것들을 생각하면서 모델링할 수도 있습니다

하지만 이러한 것들을 생각을 하고 관점을 높일 수 있는 것은 좋은 것 같습니다

개념 모델, 논리 모델, 물리 모델, 그리고 현실적인 논리 모델

데이터 모델을 보는 3가지 관점으로

개념 모델, 논리 모델, 물리 모델이 있습니다.

논리 모델은 물리적인 요소를 고려하지 않고 업무 관점의 모델이며

물리 모델은 물리적인 요소를 고려한 현실적인 모델입니다.

이렇게 관점에 대해 듣다 보면 의문점이 생기기 마련입니다.

논리 모델에서 현실적인 항목을 반영하면 잘못된 것인가?

논리 모델과 물리 모델 간의 차이가 심하면 모델링은 잘못된 것인가?

그리고 개념 모델은 어느 정도의 수준의 모델인가?

이런 의문점을 해결하기 위해서는 

우선 개념 모델링에 대해 정확하게 이해하는 것이 좋습니다.

개념 모델은 주식 별자는 물론이며

엔터티 간의 관계와 주요 속성이 모두 그려진 구체적인 모델입니다.

개념 모델은 가장 특징적인 주요 속성 및 식별까지만 도출해서 전체적인 그림을 그리는 것입니다

품질 좋은 논리 모델을 만들기 위해 반드시 거쳐야 합니다.

논리 모델은 주요 엔터티뿐 아니라

모든 엔터티와 개별 엔터티의 속성이 모두 도출된 구체적이고 정규화된 모델입니다.

논리 모델은 업무 데이터를 테이블 수준이 아닌,

정보 요구사항을 인간이 이해하기 가장 적합한 수준으로

통합하거나 분리한 형태의 모델입니다.

이렇게 개념 모델은 논리 모델을 정확하게 그리기 위해 구체적인 뼈대를 형성하여 만들고

논리 모델은 그 뼈대를 바탕으로 살을 붙이는 과정입니다.

그렇다면 개념 모델은 어느 정도 수준으로 모델링해야 할지 알 수 있을 것입니다. 

이제 남은 것은 물리 모델과 논리 모델의 차이점과 역할을 분명히 할 필요가 있겠습니다.

논리 모델에서 성능 이슈는 아니지만

전체 구조에 영향을 미치는 요소들은 좀 더 일찍 결정하는 것이 중요합니다.

그래서 물리 모델에서는 무결성이 조금 손상되더라도

성능과 같은 현실적인 이슈를 최대한 해결하기 위한 작업이라고 할 수 있습니다

그러니 논리에서는 최대한 사람이 이해하기 가장 쉬우면서

가능한 한 테이블에 유사한 형태의 모델이어야 합니다.

그렇게 작업이 된 상태에서 물리 모델을 적용해서 성능 이슈를 해결해야 할 것입니다

프로젝트 성패를 결정짓는 데이터 모델링 이야기 中 by김상래

오늘의 포스팅은 

이전에 많이 배웠던 기본적인 것들이었습니다

3가지 관점과 3단계 스키마를 단 3줄로 정리된 이론적이 것이었지요

하지만 이렇게 관점을 어떻게 보고 어떻게 생각하는지에 대한

사고력을 높이는 것은 상당히 좋은 경험이었던 것 같습니다

오늘도 이렇게 좋은 한 걸음을 나아간 것 같습니다

그럼 다음 포스팅도 기대해주세요