d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

d

엔터티만 명확하게 정의하면 모델링의 많은 문제는 해결

여러 데이터가 혼합된 형태의 엔터티는 엔터티가 아니라 뷰로 사용

주 식별자가 존재하도록 엔터티 설계

같은 성격의 데이터는 전사적으로 유일하게

하나의 엔터티에 서로 다른 성격의 데이터를 혼용해서는 안됨

엔터티는 보통 다른 엔터티와 관계가 존재하는 것이 일반적이므로 관계가 존재하지 않으면 그 엔터티의 성격을 다시 확인

프로세스에 따라 변하는 상태를 엔터티로 설계하거나, 특정 프로세스를 처리하기 위한 화면에 따라 엔터티를 설계하면 안됨

엔터티와 프로세스는 별개

하나의 화면에 하나의 엔터티를 매핑해서 설계하는 것은 지양할 것

데이터베이스에서 관리하려는 데이터를 엔터티로 설계하며, 설계 했더라도 사용하지 않는다면 삭제

일정한 약속을 정해 준수할 것

구체적(Specific)

일반적(General)

생략해도 의미가 통하는 단어는 생략

중복 의미를 나타내는 단어가 사용되지 않도록 주의

엔터티 명에 '~등록', '~처리' 등과 같이 프로세스(업무)를 표현하는 것은 바람직하지 않음

엔터티 명은 명사형으로 사용하는 것이 일반적

형용사형을 사용하여 설명하는 식의 엔터티명은 함축적이지 않으며 직관적이지 않음

엔터티 명은 가독성에 문제가 되지 않고 성격을 파악할 수 있는 정도 내에서 띄어쓰기를 하지 않고 명명

속성 명을 컬럼 명으로 자동 전환하는 것과 달리 엔터티 명은 테이블 명으로 자동 전환하지 않아야 함

엔터티 정의가 바뀌는 것은 바람직 하지 않지만, 엔터티 명은 생각보다 자주 바뀜

엔터티 명은 빈번하게 변경되지만, 테이블 명은 변경할 이유가 없다는 점을 염두에 두고 원칙을 정의

테이블 명과 마찬가지로 엔터티 명은 전 영역에서 중복돼서는 안됨

엔터티 명에 특수 문자는 사용하지 않는 것이 원칙이지만 '_', '/', '( )', '[ ]' 등은 사용가능

실체 엔터티에 대한 명명법의 핵심은 엔터티 명이 명사로 끝나는 것

명사로 끝나도록 정하는 것은 적합하지 않음

엔터티 명에 '~했음’이나 '~한 데이터’를 붙여보았을 때 자연스러운 문장이 되면 행위 엔터티에 대한 명명으로 적합

교차 엔터티의 명명법은 관계의 명명법과 연관됨

다대다(M:M) 관계의 관계 명은 교차 엔터티 명과 유사

집계 기준은 앞쪽에, 대상(무엇을 집계했는지)은 뒤쪽에 위치하는 것이 좋음

구체화 할것인지 일반화 할것인지 판단

서브타입 엔터티 명은 슈퍼타입 엔터티에 수식어를 붙이는 형식으로 사용

유사한 속성을 분리할 때

덜 사용되는 속성을 분리할 때

프로세스를 표현한 결과를 나타낼 때

논리 모델이 완료된 시점에 검증하는 것이 좋으며, 리더가 일관되게 검증

모델에 표현된 불필요한 엔터티가 있는지?

모델에 표현되지 않은 엔터티가 있는지?

엔터티를 설계할 때 간혹 속성으로 설계해야 하는데, 엔터티로 설계하는 경우가 있으니 주의

한 엔터티에 여러 성격의 데이터가 혼재돼서는 안되며, 엔터티는 동일한 성격의 집합으로 구성되어야 함

유사한 데이터가 여러 엔터티에 존재하는 것은 특별한 이득이 없으므로 엔터티 통합을 기본 원칙으로 검증

유사한 구조가 반복된다면 좀 더 일반화하여 통합

필요한 단어만을 사용해서 구체적으로 붙여야함

엔터티 명을 보고 어떤 데이터를 관리하는 엔터티인지를 알 수 있도록 가능한 구체적이어야 함

반대로 확장할 수 있는 집합인데도 불구하고 구체적으로 붙이는 것은 바람직하지 않음

엔터티 명에 필요 없는 단어는 생략

서브타입 엔터티 명은 슈퍼타입 엔터티 명을 차용해야 함

엔터티 명은 주 식별자와 한 쌍처럼 잘 어울려야 함

어울리지 않을 경우 단순히 가독성 측면에서만 문제가 되는 것이 아니라 간혹 둘 중의 하나를 잘못 설계했을 수도 있음

엔터티 설명은 반드시 기술하는 것이 원칙

설명이 누락된 엔터티를 뽑아서 설명을 채워야함

모델러는 엔터티 명과 설명만을 보고도 해당 엔터티를 충분히 설명할 수 있어야함

모든 엔터티에 업무 식별자가 존재하는지를 검토

업무 식별자는 CASE 툴에서 관리하지 않기 때문에 표준 형식을 정해서 관리

엔터티 명이 '~이력’으로 끝나는지 검토

하위(자식) 엔터티가 많다면 종료일자 속성을 주 식별자에 포함하지 말 것

일대일(1:1) 관계만을 뽑아서 두 엔터티의 성격이 같은지 확인

성능, 관리 상의 문제가 없다면 합체할 것을 고려

종속 관계인 엔터티는 동일한 주제 영역에 존재해야함

종속 엔터티는 일반적으로 주 식별자를 식별자로서 상속

인스턴스가 하나뿐인 엔터티는 흔치 않으므로, 반드시 잘못된 것은 아니지만 재차 확인해볼 필요가 있음

주 식별자가 없다고 반드시 잘못된 엔터티는 아니지만, 주 식별자가 없는 엔터티를 뽑아서 다시 검토해야함

일대일(1:1) 관계나 슈퍼타입, 서브타입 관계 등을 제외하고, 엔터티의 주 식별자가 같은 엔터티는 주 식별자를 검토해 볼 필요가 있음

모델러는 스스로 설계한 엔터티와 속성을 쉽게 설명할 수 있어야함

외부 엔터티나 복제 엔터티는 원천 엔터티와 엔터티 명과 주 식별자가 동일해야함

데이터 성격에 맞는 정체성이 뚜렷한 엔터티를 설계하는 것은 데이터 모델 설계의 중요한 원칙

유사한 성격의 데이터는 통합하는 것이 데이터 모델링의 주요 원칙

확장하기 수월한 모델으로 데이터를 통합할수록 모델은 유연해짐

데이터에 결점이 없는 상태

가독성이 좋도록 모델을 설계

업무 요건에 맞는 모델을 설계하는 것

업무 식별자를 제대로 도출하여 엔터티를 분명히 설계

업무 프로세스에 맞게 관계선을 표현

성능이 좋도록 모델을 설계하는 것

ERD가 제대로 관리될 수 있도록 설계하는 것

표준화 원칙을 따라 동일한 용어를 사용하도록 설계하는 것

향후에 사용되지 않을 수도 있다는 것을 고려해서 설계하며, 주믄등록번호 같은 암호화 대상 속성을 주 식별자로 사용하면 안됨

엔터티에 존재하는 모든 인스턴스는 고유해야 하며, 널 값을 가지면 안 된다는 것이 엔터티 무결성

한 엔터티에는 동일한 주 식별자 값이 존재할 수 없으며, 주 식별자 속성은 모르는 값인 널 값을 허용할 수 없음

엔터티 무결성을 만족하기 위해선 주 식별자에 PK(Primary Key)를 생성하고, 업무 식별자에 유니크 인덱스(Unique Index)를 생성

연관된 인스턴스 간의 일관성을 유지하기 위한 제약

엔터티의 외래 식별자 속성 값은 참조되는 엔터티의 주 식별자 값과 일치하거나 널 값이어야 한다는 것

참조 무결성은 FK(Foreign Key) 제약으로 지켜짐

도메인 무결성은 속성과 관련된 제약

도메인 무결성은 데이터 타입(Data Type)과 기본 값(Default) 제약, 널(Null) 제약, 체크(Check) 제약 등을 지킬 수 있음

업무 무결성은 기업에서 업무를 수행하는 방법이나 데이터를 처리하는 규칙을 의미

업무 무결성을 지키기 위해 지침을 제시하여 논리적으로 지키게 하는 방법이 있고, 데이터베이스 제약을 사용하여 강제적으로 지키게 하는 방법이 있음

속성의 종속성을 파악하여 엔터티를 설계하는 것

핵심은 식별자(Identifier)와 종속성(Dependency)

엔터티를 대표하는 속성(업무 식별자)을 찾은 후에, 그 속성을 기준으로 대상 속성이 종속됐는지 여부를 판단

업무 요건에 필요한 속성을 묶어서 엔터티 설계

정규화는 일반적으로 순서대로 수행되지 않으나, 크게 상향식(속성을 제거하면서 정규화), 하향식(생각하는 과정을 통해 정규화)으로 구분할 수 있음

순서대로 수행하는 것이 현실적이진 않을 수 있지만, 더 체계적일 수 있음

식별자에 종속된 유사한 속성들은 모으고, 종속되지 않은 독립적인 속성들은 분리하여 속성을 명확히 구별하는 것

특정 속성이 어떤 엔터티에 위치해야 옳은지를 따져서 제자리인 한 곳에만 있도록 하는 과정

더는 분해될 수 없는 엔터티

속성 간의 부정확한 종속성을 없애는 것

중복 속성을 제거하기 위함이지 액세스 성능을 최적화하기 위함은 아님

다만 정규화를 수행할 때는 성능을 고려해야 하며, 서능 문제가 분명할 때는 비정규화를 고려해야함

모든 종속의 기초가 되는 종속

릴레이션에서 A 속성의 값이 B 속성의 값을 유일하게 식별할 수 있다면, B 속성은 A 속성에 함수적으로 종속됐다고 함

속성 간의 종속성을 분석해 집합을 분리하기 위한 것이므로 속성과 엔터티를 정의하고 관계를 파악하는 데 절대적인 역할을 함

한 속성이 다른 속성을 유일하게 식별할 수 있는지는 업무 요건에 따라 달라짐

밀접한 속성을 모아 하나의 릴레이션으로 만드는 체계적인 방법

속성 Y가 속성 X에 의해 함수적으로 종속되다는 말은 속성 X의 값을 이용해 속성 Y의 값을 유일하게 식별할 수 있다는 의미

이 때 X를 결정자, Y를 종속자라고 하고 X는 Y를 함수적으로 결정한다고하며, 기호로 X → Y, y=f(x) 로 표현

X→Y→Z와 같은 종속을 이행 종속(Transitive Dependency)라 하며, 3정규형과 관련된 종속

함수 종속은 직접 종속을 의미

결정자(Determinant)는 속성 간의 종속성을 분석할 때의 기준이 되는 값(식별자(Key))

릴레이션에 모든 속성을 함수적으로 결정하는 최소한의 속성(후보 키(Candidate Key))

종속자(Dependent)는 결정자의 값에 의해 정해질 수 있는 값(비식별자(Non-Key))

릴레이션 R의 속성 X가 키인지 알려면 X의 폐포를 알아야함

X의 폐포는 X에 종속됐다고 추론(Reasoning)할 수 있는 모든 속성의 집합을 의미

X→(Y,Z)라면 X의 폐포는 X 자신과 Y와 Z다 (X^+ = X, Y, Z)

Y ⊆ X 이면 X → Y 성립

X → Y 이면 XZ → XY 성립

X → Y 이고 Y → Z 이면 X → Z 성립

x → YZ 이면 X → Y 이고 X → Z 성립

X → Y 이고 X → Z 이면 X → YZ 성립

X → Y 이고 YZ → W 이면 XZ → W 성립

먼저 릴레이션의 키를 도출한 뒤 정규화 수행

어떤 방법을 사용하든 정규화는 키를 구하는 것으로 시작하며, 키를 구하려면 모든 함수 종속을 찾아야함

상향식 모델링 시 기존 엔터티의 주 식별자를 검증하면서 정규화 수행

하향식 모델링 시 엔터티와 주 식별자를 새롭게 분석하며, 분석 시 후보 식별자를 정한 수 맞는지 검증

그냥 그대로의 릴레이션

사용하던 릴레이션에 속성을 잘못 추가해서 사용할 때 생길 수 있음

새로 설계할 때 정규화와 무관하게 화면이나 업무 요건 문장을 그대로 릴레이션으로 설계할 때 생길 수 있음

정규형이 아닌 릴레이션

완전성이란 데이터 중복 등의 이상이 없는 성질

정규화의 가장 커다란 목적 중 하나는 중복 데이터를 제거하는 것으로, 데이터베이스는 데이터를 관리하는 저장소이기 떄문에 데이터 이상이 없어야 완전해질 수 있음

중복 데이터를 사용할수록 데이터 정합성은 저하됨

어떤 경우라도 데이터를 중복시켜 정합성이 깨질 수 있도록 설계하는 것은 좋지 않음

안정성과 신뢰도를 높이는 견고한 정규형 모델을 사용해야 데이터는 완전해짐

확장성이란 업무 변화에 유연하게 대처할 수 있는 성질

정규화를 하면 모델의 확장성(Flexibility)이 좋아짐

또한 함수종속을 기반으로 모델 구조를 정의하기 때문에 데이터의 성격에 맞는 엔터티가 설계됨

엔터티가 명확하게 정의돼 있다면 추가 업무가 발생했을 때 이미 존재하는 엔터티에 통합할지, 별도의 엔터티를 추가할지, 속성으로 추가할지가 명확해지고 그에 따른 엔터티간의 관계도 명확해짐

즉 데이터 성격에 맞는, 함수 종속에 의해 결정된 데이터 구조는 견고하며 확장성도 뛰어남

아노말리는 데이터의 이상 현상 뜻하며, 데이터 품질을 저하시키는 주범

데이터가 서로 맞지 않는 아노말리는 중복 데이터로 인해 발생

중복 데이터 존재시 의도하지 않은 이상 현상이 발생 할 수 있음

아노말리는 방지하는 근본적인 방법은 정규화

아노말리는 애플리케이션에서 방지할 수 있으나 이는 임시방편적인 편법

중복 데이터가 사용되면 언젠가는 데이터 이상 현상이 발생

업데이트 아노말리

삭제 아노말리

삽입 아노말리

속성의 원자성 개념 기반

함수 종속(Functional Dependency) 개념 기반

다가 종속(Multivalued Dependency) 개념 기반

조인 종속(Join Dependency) 개념 기반

정규형 특징

정규형은 일종의 체계가 존재하므로 일반적으로 3정규형을 만족한다는 것은 1정규형, 2정규형도 만족하는 것을 의미

함수 종속을 사용하지 않고 직관적으로 3정규형이나 BC정규형을 도출할 수도 있음

하나의 값을 가져야 한다는 것으로 더 이상 조갤 수 없는(UNCUT) 하나의 값만을 가져야 한다는 것을 의미

다가 속성(Multivalued Attributes)

복합 속성(Composite Attributes)

다가 속성이 사용된 릴레이션

복합 속성이 사용된 릴레이션

유사한 속성이 반복된 릴레이션

한 릴레이션에서 반복 형태의 속성을 해소한 것

중첩 릴레이션

중복 속성이 여러 개 존재하는 릴레이션

중첩 릴레이션이 존재하는 릴레이션

동일 속성이 여러 릴레이션에 사용된 경우

정규형

비정규형

정규형 사용시 성능 문제 발생하고, 현재의 업무 요건이 불변할 때 비정규형을 사용

위 두 조건을 동시에 만족하지 않으면 정규형 사용을 권장

비정규형의 조회 성능이 항상 효율적이진 않음

자주 발생하면서 가장 심각한 유형은 여러 속성이 묶여서 반복되는 형태(상품번호, 주문수량)

여러 속성이 묶여서 반복됐다는 것은 이미 일대다(1:M)의 독립적인 데이터를 의미함

쌍을 맞춰서 관리해야되는데 이를 어길 경우 데이터 무결성이 깨져 사용할 수 없는 모델이 됨

인덱스 사용하기에도 매우 복잡

속성을 특정 기준으로 분리한 경우

하나의 전화번호를 세 자리로 분리한 경우 각각의 의미에 맞도록 속성명을 표준화 해야함

속성이 업무적으로 반복이 고정적이지 않은 경우

1정규화를 통해 1:M 관계로 관리

릴레이션의 모든 속성이 후보 식별자 전체에 종속적일 때

주 식별자가 두 개 이상인 릴레이션에서 발생

부분 함수 종속으로 발생한 중복 데이터를 제거하는 것이 2정규화

2정규화는 후보 식별자를 구성하는 속성이 두개 이상일 때만 대상이 되고, 단일 속성일 때는 대상이 안됨

즉 전체에 종속되지 않고 일부에 종속(Partial Functional Dependency)된 속성을 2정규형이 아님

간혹 2정규화를 해야하는지 판단이 힘들 때가 있는데, 이는 속성 명을 명확히 붙이지 않아서 발생하기 때문에 발견하기 쉽지 않음

따라서 데이터를 보고 분석해야 정확히 2정규화 대상인지를 판단할 수 있음

모델에서 속성 명이나 엔터티 명을 잘못 사용해 의도한 것과 다르게 모델을 설계하는 경우가 있는데, 이 때문에 2정규화를 하게 될 수도 있어 주의해야함

엔터티를 정확하게 분석해서 엔터티 명과 속성 명을 명확하게 사용하면 이런 문제는 발생하지 않을것

3정규형은 비식별자 속성 간에 발생하는 이행적 종속성(Transitive Dependency)과 관련됨

이행적 종속성은 Y가 X에 종속되고 Z가 Y에 종속되면 Z는 X에도 종속된다고 추론하는 것을 말함

즉 X → Y 이고 Y → Z 이면 X → Z가 성립하며, 이때 Y느 릴레이션의 후보 식별자나 후보 식별자의 일부가 아닌 일반 속성(비식별자 속성)

{(#A#B → C , #A#B → D , C → D)} 일 때, C는 일반 속성이면서 속성 D의 결정자기도 함

즉 속성 D는 주 식별자인 A와 B에 간접 종속돼 있으므로 직접적인 함수 종속에 의해서 분해돼야 함

이행 종속된 속성 D와 그 속성의 결정자 역할을 하는 속성 C를 분해해서 새로운 릴레이션으로 생성

{(#A#B → C), (#C → D)}

3정규형을 보강한 정규형으로 모든 결정자는 주 식별자여야 한다는 정규형

릴레이션에 존재하는 종속자는 후보 식별자가 아니어야함

모든 BC정규형 릴레이션은 3정규형 릴레이션이지만, 3정규형 릴레이션이 모두 BC정규형 릴레이션을 만족하는 것은 아님

속성 Y에 종속된 Z가 후보 식별자에 포함되면 BC정규형이 아님

Z가 후보 식별자에 포함되는지에 따라 3정규형과 BC정규형이 구분됨

Z가 후보 식별자에 포함되더라도 일반 속성간에는 종속성이 없으므로 3정규형은 만족함

{(#A#B → C, #A#B → D, C → #B)} 일 때, 일반 속성 C에 종속된 종속자 #B가 주식별자에 포함돼 있으므로 BC 정규형에 어긋나지만 일반 속성(C, D) 사이에는 종속 관계가 없으므로 3정규형은 만족함

BC 정규형을 만족하기 위해서 주식별자 #B 를 일반속성으로 변경하고 일반 속성 C를 주식별자로 변경하며, 속성 C와 B를 분해해서 새로운 릴레이션으로 생성

{(#A#C → D), (#C → B)}

다가 종속 개념이 기반이 되는 정규형으로 이를 이해하려면 다가 종속(MVD; Multivalued Dependency)을 이해해야 함

다가 종속은 한 릴레이션에 다가 속성이 두 개 이상 존재할 때 발생할 수 있으며, 다가 속성 값 사이에 다대다(M:M) 관계가 발생 하는 것

데이터를 정확하고 효율적으로 관리할 수 있도록 해주며 데이터 사용 공간도 절약

서로 관계가 없는 다가 속성 간에 종속성이 생긴 릴레이션은 많은 중복 데이터가 생기기 때문에 4정규화를 하여 중복 데이터를 제거해야 함

1정규화와 유사하나 1정규화는 다가 속성을 엔터티로 분해하는 것이고 4정규화는 서로 관련이 없는 다가 속성을 개별 엔터티로 분해하는 것으로 다가 속성을 1정규형으로 만들면 다가 종속은(MVD)은 자연히 제거됨

하나의 A 값에 대응하는 여러 개의 B 값이 있고 A 값에 대응하는 여러 개의 C 값이 있으며, B 값과 C 값 사이에는 아무런 상관관계가 없는데 A, B, C 값을 하나의 릴레이션에서 관리할 때 다가 종속이 발생

즉 두 개의 독립적인 일대다(1:M) 관계의 속성이 하나의 릴레이션에 존재하면 다가 종속이 발생

아래 표는 사원은 두 명 이지만 이름이 열번 존재하고 '홍길동’의 기술과 언어는 두 개인데 네 건의 데이터가 존재

사원과 기술, 사원과 언어라는 두개의 다가 속성을 하나의 릴레이션에서 관리하기 때문

기술과 언어 사이에 직접적인 연광이 없고, 단지 한 사원에 속해 있어 간접적인 연관 관계만 존재

즉 어떤 기술이 어떤 언어와 쌍이 되는지 중요하지 않으므로 두개의 릴레이션으로 분해

조인 종속(Join Dependency) 개념 기반으로 조인 종속이 없는 릴레이션

어떤 릴레이션을 분해(정규화)한 다음에 조인해서 다시 원래의 릴레이션으로 복원할 수 있다면, 그 릴레이션은 조인 종속이 존재하는 릴레이션

무손실 분해와 비부가적 분해가 되도록 분해한 릴레이션이 5정규형

5정규형은 릴레이션을 분해하고(Project) 합치는(Join) 개념 때문에 PJ정규형(Project-Join Normal Form)이라고도 함

5정규형은 3개체 관계(Ternary Relationships)와 연관됨

3개체 관계가 발생한 릴레이션은 일반적으로 세 개의 릴레이션으로 분해할 수 있으며, 세 개의 릴레이션으로 분해하면 5정규형을 만족함

하나의 릴레이션을 여러 개의 릴레이션으로 분해한 후 공통(식별자) 속성으로 조인하여 데이터 손실 없이 원래의 릴레이션으로 복원할 수 있으면, 이를 '무손실 조인’이라함

조인한 결과에 원래 릴레이션에 없던 데이터(가짜 튜플)가 존재하지 않으면 이를 '비부가적 조인’이라함

'무손실 분해’란 필요한 데이터가 사라지지 않도록 분해하는 것을 뜻하고, '비부가적 분해’란 필요 없는 데이터가 생기지 않는 것을 뜻함

정규화 수행 조건

정규화 순서

정규화 수행 조건

정규화 순서

정규화 수행 조건

정규화 순서

(상속한 관계가 일반속성이 되며, 관계는 비식별 관계(Non-Identifying Relationship))

정규화 수행 조건

정규화 순서

정규화 수행 조건

정규화 순서

정규화 수행 조건

정규화 순서

3정규화까지가 정규화의 대다수를 차지하기 때문에 3정규화까지 하면 대부분의 중복은 해결할 수 있음

3정규화에 비해 어려운 BC정규화, 4정규화, 5정규화 난이도

BC 정규화 이상으로 수행할 시 쿼리(조회)가 어렵다고 생각하기 때문

정규화를 하는 이유는 중복 데이터를 제거하여 데이터 이상현상을 최소화하려는 것

업무 요건에 따라 정규화를 수행하고 나서, 성능 관점에서 필요에 따라 비정규형을 선택할 수 있을 뿐 정규화를 제한하는것은 올바른 접근 방법이 아님

다만 이론에 의해 최대한 분해한 5정규형은 실익이 없고, 5정규화를 하지 않는다고 해서 업무 요건을 저해하는것도 아니며, 중복 데이터가 생기는 것도 아님

정규화하여 엔터티를 분해하였을 때 조인하는 과정에서 사용하는 블록이 능어남으로써 성능에 나쁜 영향을 미침

따라서 일반적인 조회 요건이라면 미세하게라도 정규형이 비정규형보다 조회 성능이 떨어질 가능성이 높음

다만 정규화를 하면 중복 데이터가 최소화되고 인스턴스의 크기가 작아지므로, 한 블록(8Kbytes)에 저장하는 인스턴스는 많아지게됨

이 점이 여러 건의 조회뿐만 아니라 한 건의 조회에도 특정 속성을 조회할 때는 정규형의 성능이 좋아질수 있는 원인

정규화의 기본 개념이 함수 종속이므로 종속성, 의존성이 같은 데이터(성격이 같은 데이터)는 업무에서 같이 조회될 가능성도 커져 최소의 블록을 사용하는 효과를 얻게됨

그로인해 블록이 다시 사용될 가능성(확률)이 커짐으로써 메모리에 존재하는 블록을 조회할 메모리 적중률(Hit Ratio)이 높짐으로써 성능이 좋아짐

조회 성능과는 다르게 쓰기 성능(Insert, Update, Delete)이 좋다는 것은 중복 속성이 없기 때문

비정규형은 어떤식으로든 중복 데이터를 사용하며, 한 속성을 다루는게 아니라 여러 속성을 다루기 때문에 쓰기 시간이 오래 걸림