관계
관계의 정의
- 관계란 엔터티들이 서로 상호 연관성을 가지고 있는 상태를 말합니다.
- 강사와 수강생은 서로 논리적으로 연관성이 부여된 상태이며 해당 관계는 ‘강의한다’라는 관계로 명명할 수 있습니다.
- 또한 강사 인스턴스 하나가 여러 수강생 인스턴스들과 관계를 가지고 있기 때문에 이러한 관계를 일대다 관계라고 부릅니다.
관계의 분류
존재에 의한 관계
- ‘소속된다’라는 의미는 어떠한 행위에 의해 발생되는 의미가 아닌 단지 사원이 부서에 소속되어 있기 때문에 나타나는 관계입니다.
행위에 의한 관계
고객과 주문의 관계는 고객이 주문이라는 행위에 의해 발생되는 관계이기 때문에 행위에 의한 관계라고 볼 수 있습니다.
관계의 표기법
- 관계명(Membership) : 관계의 이름
- 관계차수(Cardinality) : 일대일(1:1) , 일대다(1:M), 다대다(M:N)
- 관계선택사양(Optionality) : 필수관계, 선택관계
관계명
- 엔터티가 관계에 참여하는 형태를 지칭
- 각각의 관계는 두 개의 관계명을 가짐
관계차수
관계선택사양
- 고객은 여러번 주문할 수도 있고 한번도 주문하지 않을 수도 있음 (선택관계)
- 그러나 주문은 반드시 고객이 있어야 가능함 (필수관계)
식별자
식별자란??
- 식별자는 엔터티 내에서 각각의 인스턴스들을 구분할 수 있는 속성을 말합니다.
- 쉽게 생각해서 웹사이트에서 특정 회원을 구분하기 위해 계정명이나 이메일을 사용하는 것으로 이해할 수 있습니다.
식별자의 특징
식별자 분류
대표성 여부
- 주식별자: 엔터티 내에서 각 인스턴스들을 구분할 수 있는 구분자이며, 타 엔터티와 관계를 연결할 수 있는 식별자 (ex: 주문번호, 사원번호)
- 보조식별자: 엔터티 내에서 각 인스턴스들을 구분할 수 있는 구분자이나 대표성을 가지지 못해 관계연결을 못하는 식별자 (ex: 전화번호 : 전화번호는 각 개인마다 유일하긴 하나 자주 바뀔 수 있어서 불변성을 만족하지 못함)
스스로 생성 여부
- 내부식별자: 엔터티 내부에서 스스로 생성되는 식별자 (ex: 게시판글번호)
- 외부식별자: 타 엔터티와의 관계를 통해 들어오는 식별자 (ex: 댓글 엔터티의 원본게시물번호)
속성의 수
- 단일식별자: 하나의 속성만으로 구성된 식별자 (ex: 사원엔터티의 사원번호)
- 복합식별자: 둘 이상의 속성의 조합으로 구성된 식별자 (ex: 주문엔터티의 고객번호와 주문번호)
대체가능 여부
- 본질식별자: 업무에 의해 만들어지는 가공되지 않는 원래의 식별자
- (ex: 사원엔터티의 사원번호)
- 인조식별자: 주 식별자의 속성이 두 개 이상인 경우 속성들을 하나의 속성으로 묶어 사용하는 식별자
- (ex: 제품엔터티의 씨리얼번호 - SM230301 <제품식별코드+제조일자>)
식별자관계와 비식별자관계
데이터 모델과 성능
성능 데이터 모델링
- 성능 데이터 모델링은 데이터베이스 시스템의 성능을 향상시키기 위해 데이터 모델을 설계하는 과정입니다.
- 이 과정에서는 시스템의 응답 시간, 처리량, 자원 사용 등과 관련된 성능 목표를 달성하기 위해 데이터베이스 구조를 조정하고 최적화합니다. 이를 통해 데이터베이스의 성능을 최대화할 수 있습니다.
성능 데이터 모델링 수행시점
- 성능 데이터 모델링은 일반적으로 시스템 개발 라이프사이클의 초기 단계에서 수행됩니다. 주로 다음과 같은 단계를 거치게 됩니다:
- 요구사항 수집 및 분석: 시스템의 성능 요구사항을 수집하고 분석합니다. 이는 예상되는 동시 사용자 수, 응답 시간 요구사항, 데이터 양 및 빈도 등을 포함합니다.
- 데이터 모델 설계: 수집한 요구사항을 기반으로 데이터 모델을 설계합니다. 이 단계에서는 테이블, 관계, 속성 및 인덱스 등을 정의합니다. 데이터 모델의 구조와 관계는 성능에 직접적인 영향을 미치게 됩니다.
- 성능 분석: 설계된 데이터 모델을 분석하여 성능 이슈를 식별합니다. 이 단계에서는 데이터베이스 쿼리의 실행 계획을 평가하고, 인덱스 및 쿼리 최적화를 고려합니다.
- 최적화: 성능 이슈를 해결하기 위해 데이터 모델을 최적화합니다. 이는 인덱스의 추가 또는 변경, 테이블 파티셔닝, 쿼리 재작성 등을 포함할 수 있습니다.
중요!! - 성능 데이터 모델링은 분석/설계 단계에서 주도면밀하게 고려되어야 한다.
성능 데이터 모델링시 고려사항
1) 데이터 모델링을 할 때 정규화를 정확하게 수행
2) 데이터베이스 용량 산정을 수행 - 어떤 엔티티(테이블)에 데이터가 집중되는지
3) 데이터베이스에 발생되는 트랜잭션의 유형을 파악
4) 용량과 트랜잭션의 유형에 따라 반정규화를 수행
5) 이력모델의 조정, PK/FK 조정, 슈퍼타입/서브타입 조정등을 수행
6) 성능관점에서 데이터 모델을 검증 - 충분하게 성능이 고려되었는지
정규화와 성능
정규화란??
정규화는 데이터베이스 설계 과정에서 중복을 최소화하고 효율적인 구조를 갖도록 데이터를 구조화하는 과정입니다. 이 과정은 데이터 중복, 업데이트 이상(Anomalies), 삽입 이상, 삭제 이상을 최소화하는데 도움이 됩니다. 정규화의 궁극적인 목표는 데이터의 무결성과 일관성을 보장하는 것입니다.
- 정규화를 수행하면 입력/수정/삭제의 성능은 무조건 향상됨!!!
- 다만 조회 성능은 향상될수도 있고 저하될수도 있음!!!
정규화가 성능에 영향을 미치는 이유
데이터베이스에서 정규화를 사용하면 다음과 같은 이유로 입력(삽입), 수정(업데이트), 삭제 성능이 향상될 수 있습니다.
- 중복 최소화: 정규화를 통해 데이터 중복을 제거합니다. 이로 인해 불필요한 데이터를 삽입, 수정, 삭제하는 데 드는 비용이 줄어들며, 따라서 성능이 향상됩니다.
- 데이터 무결성 보장: 정규화는 데이터 무결성을 보장하는 데 도움이 됩니다. 중복이 제거되면서 일관성이 유지되므로, 업데이트나 삭제 시 이상(anomalies)이 발생할 가능성이 줄어듭니다.
- 디스크 공간 효율성: 중복된 데이터가 제거되면서 디스크 공간의 사용이 효율적으로 이루어집니다. 이로 인해 데이터의 저장, 검색, 업데이트 성능이 향상될 수 있습니다.
- 트랜잭션 성능 향상: 정규화는 데이터의 수정을 최소화하여 트랜잭션 충돌의 가능성을 줄이는데 도움이 됩니다. 이는 여러 사용자가 동시에 데이터베이스에 액세스할 때 특히 중요합니다.
그러나, 반드시 주의해야할 점은 정규화의 장점이 반드시 모든 상황에서 통할 것이라는 보장이 없다는 것입니다. 예를 들어, 조회(Query) 성능은 정규화로 인해 저하될 수도 있습니다. 왜냐하면 데이터가 여러 테이블에 분산되어 있기 때문에 조인 연산이 필요하게 될 수 있기 때문입니다. 따라서 필요에 따라 반정규화를 고려하는 것도 중요합니다.
정규화 관련 용어
- 주민번호를 알면 그사람의 이름, 출생지, 주소를 알 수 있다!!
- 정규형(Normal Forms): 정규형은 데이터베이스의 특정 조건을 충족하는지 판단하는 규칙 또는 표준입니다. 데이터베이스는 1NF, 2NF, 3NF, BCNF, 4NF, 5NF(또는 PJ/NF), 6NF와 같은 여러 정규형을 가질 수 있습니다.
- 함수적 종속성(Functional Dependency): 함수적 종속성은 속성 간의 관계를 설명하는 개념으로, 속성 A가 속성 B에 함수적으로 종속되면, A의 값이 B의 값을 결정한다는 뜻입니다.
- 결정자(Determinant): 함수적 종속성에서, 한 속성 또는 속성 그룹이 다른 속성 또는 속성 그룹을 결정할 때, 그 속성 또는 속성 그룹을 결정자라고 합니다.
- 다치종속(Multivalued Dependency): 속성 A가 속성 B에 대해 다치종속을 가지면, A의 한 값이 B의 집합을 결정한다는 뜻입니다. 이는 4NF를 충족하는 데 필요한 조건입니다.
정규화 유형
- 1NF: 각 열이 원자적인 값을 가져야하고, 각 행은 고유한 키로 식별되어야 합니다.
- 2NF: 1NF를 만족하면서, 모든 비키(non-key) 열이 기본 키에 완전하게 함수적 종속되어야 합니다.
- 3NF: 2NF를 만족하면서, 비키(non-key) 열 간에 함수적 종속성이 없어야 합니다.
- BCNF (Boyce-Codd Normal Form): 3NF를 만족하면서, 모든 결정자가 후보 키(candidate key)가 되는 정규형입니다.
- 4NF: BCNF를 만족하면서, 다치종속(Multivalued Dependency)이 없는 정규형입니다.
- 5NF (or PJ/NF): 투영-조인 정규형(Projection-Join Normal Form)으로, 분해와 조인에 의해 손실되는 정보가 없는 정규형입니다.
제 1정규형을 위반한 사례 - 제 1정규화 대상
1NF(제1정규형)은 데이터베이스 정규화의 가장 기본적인 단계입니다. 이는 모든 테이블의 모든 열이 원자적인 값을 가져야하고, 각 행이 고유한 키로 식별되어야 한다는 것을 의미합니다.
그럼 실제 데이터를 가지고 이를 설명해보겠습니다.
예를 들어, 학생들의 과목별 성적을 기록하는 테이블이 있다고 가정해봅시다. 이 테이블은 다음과 같이 구성될 수 있습니다.
이 테이블은 1NF를 만족하지 않습니다. 왜냐하면 "과목" 열이 원자적이지 않기 때문입니다. 여러 과목이 하나의 열에 포함되어 있습니다.
1NF를 만족시키기 위해 테이블을 다음과 같이 변환할 수 있습니다.
이제 모든 열이 원자적인 값을 가지며, 각 행은 "학생ID"와 "과목"의 조합으로 고유하게 식별됩니다. 따라서 이 테이블은 1NF를 만족합니다.
이렇게 1NF를 적용하면 데이터의 중복성이 감소하고, 데이터 무결성을 보장할 수 있게 됩니다. 또한 데이터 관리 및 검색이 훨씬 더 효율적이게 됩니다.
제 2정규형을 위반한 사례 - 제 2정규화 대상
제2정규형(2NF)은 모든 비키(non-key) 속성이 기본 키에 완전히 함수적 종속되어야 하는 것을 요구합니다. 이는 키가 복합 키(composite key, 두 개 이상의 속성으로 구성된 키)인 경우에 주로 적용됩니다.
예를 들어, 학생들이 수강하는 과목에 대한 세부 정보를 추적하는 테이블이 있다고 가정해봅시다. 이 테이블은 다음과 같이 구성될 수 있습니다.
이 테이블에서 복합 키는 '학생ID'와 '과목'이며, '교수'는 비키(non-key) 속성입니다.
하지만 이 테이블은 2NF를 위반합니다. 왜냐하면 '교수' 속성이 복합 키의 일부인 '과목'에 부분적으로 함수적 종속되기 때문입니다. 즉, '과목'을 알면 '교수'를 알 수 있지만, 이는 '학생ID'와는 무관합니다.
따라서 이 테이블을 2NF를 만족하도록 수정하려면 테이블을 분해하여 '과목'과 '교수' 사이의 함수적 종속성을 별도의 테이블로 만들면 됩니다.
다음은 2NF를 만족하는 테이블입니다:
학생과 과목 테이블:
과목과 교수 테이블:
이렇게 2NF를 적용하면 데이터 중복성을 더욱 줄일 수 있고, 갱신 이상(Anomalies)을 방지할 수 있습니다.
제 3정규형을 위반한 사례 - 제 3정규화 대상
제3정규형(3NF)은 모든 비키(non-key) 속성이 기본 키에 대해 이행적 함수적 종속이 없어야 한다는 것을 요구합니다. 즉, 비키 속성 간에는 함수적 종속이 있으면 안 됩니다.
예를 들어, 고객이 주문한 제품에 대한 정보를 저장하는 테이블이 있다고 가정해봅시다. 이 테이블은 다음과 같이 구성될 수 있습니다.
이 테이블에서 기본 키는 '주문ID'이며, 비키(non-key) 속성은 '고객ID', '제품ID', '제품명', '제품가격'입니다.
그러나 이 테이블은 3NF를 위반합니다. 왜냐하면 '제품명'과 '제품가격'이 '제품ID'에 이행적으로 함수적 종속되어 있기 때문입니다. 즉, '제품ID'를 알면 '제품명'과 '제품가격'을 알 수 있습니다.
따라서 이 테이블을 3NF를 만족하도록 수정하려면 테이블을 분해하여 '제품ID', '제품명', '제품가격' 사이의 함수적 종속성을 별도의 테이블로 만들면 됩니다.
다음은 3NF를 만족하는 테이블입니다:
주문 테이블:
제품 테이블:
이렇게 3NF를 적용하면 데이터 중복성을 더욱 줄일 수 있고, 갱신 이상(Anomalies)을 방지할 수 있습니다.
보이스-코드 정규화가 필요한 사례
보이스-코드 정규형 (BCNF, Boyce-Codd Normal Form)은 강력한 3NF로 볼 수 있으며, 모든 결정자가 후보 키의 부분집합이어야 한다는 것을 요구합니다. 이는 비키(non-key) 속성이나 후보키가 아닌 속성에 대해 함수적 종속이 있으면 안된다는 것을 의미합니다.
예를 들어, 학생들이 과목을 수강하고 그 과목을 가르치는 교수에 대한 정보를 저장하는 테이블이 있다고 가정해봅시다. 이 테이블은 다음과 같이 구성될 수 있습니다.
이 테이블에서 기본 키는 '학생ID'와 '과목ID'의 조합입니다.
그러나 이 테이블은 BCNF를 위반합니다. 왜냐하면 '과목ID'가 '교수ID'를 결정하는데, '과목ID'는 기본 키의 일부이지만 기본 키 전체는 아니기 때문입니다.
따라서 이 테이블을 BCNF를 만족하도록 수정하려면 테이블을 분해하여 '과목ID'와 '교수ID' 사이의 함수적 종속성을 별도의 테이블로 만들면 됩니다.
다음은 BCNF를 만족하는 테이블입니다:
학생과 과목 테이블:
과목과 교수 테이블:
이렇게 BCNF를 적용하면 데이터 중복성을 더욱 줄일 수 있고, 갱신 이상(Anomalies)을 방지할 수 있습니다.
제 4정규화가 필요한 사례
제4정규형(4NF)은 다치종속(Multivalued Dependency, MVD)를 제거하기 위한 정규형입니다. 다치종속은 속성 A의 값이 변함없이, 속성 B와 C가 독립적으로 여러 값을 가질 때 발생합니다.
예를 들어, 특정 학생이 참여하는 여러 클럽과, 그 학생이 선호하는 여러 가지 색상을 기록하는 테이블이 있다고 가정해봅시다. 이 테이블은 다음과 같이 구성될 수 있습니다.
이 테이블에서 기본 키는 '학생ID', '클럽', '선호 색상'의 조합입니다. 하지만, 이 테이블은 4NF를 위반합니다. 왜냐하면 '클럽'과 '선호 색상'이 '학생ID'에 대해 다치종속(MVD)를 가지기 때문입니다. 즉, 학생ID가 동일하면, 클럽과 선호 색상은 각각 독립적으로 여러 값을 가질 수 있습니다.
따라서 이 테이블을 4NF를 만족하도록 수정하려면 테이블을 분해하여 '학생ID'와 '클럽', 그리고 '학생ID'와 '선호 색상' 각각의 관계를 별도의 테이블로 만들면 됩니다.
다음은 4NF를 만족하는 테이블입니다:
학생과 클럽 테이블:
학생과 색상 테이블:
이렇게 4NF를 적용하면 데이터 중복성을 더
욱 줄일 수 있고, 업데이트 이상(Anomalies)을 방지할 수 있습니다.
제 5정규화가 필요한 사례
제5정규형(5NF), 또는 조인 종속성 정규형(Project-Join Normal Form, PJNF)은 복잡한 링크를 가진 엔티티 사이의 관계에서 보다 복잡한 종속성을 처리하기 위한 정규형입니다. 이는 테이블이 모든 조인 종속성을 충족하면서, 각각의 조인 연산 후에도 원본 테이블과 동일하게 유지되어야 함을 요구합니다.
예를 들어, 공급업체가 생산하는 제품을 취급하는 고객에 대한 정보를 저장하는 테이블이 있다고 가정해봅시다. 이 테이블은 다음과 같이 구성될 수 있습니다.
이 테이블에서 기본 키는 '공급업체ID', '제품ID', '고객ID'의 조합입니다.
그러나 이 테이블은 5NF를 위반합니다. 왜냐하면 공급업체-제품 관계와 제품-고객 관계는 별도로 존재하며, 이들 사이에는 직접적인 종속성이 없기 때문입니다. 즉, 공급업체가 제품을 만들고, 그 제품을 고객이 취급하지만, 특정 공급업체와 고객 사이에는 직접적인 관계가 없습니다.
따라서 이 테이블을 5NF를 만족하도록 수정하려면 테이블을 분해하여 '공급업체ID'와 '제품ID', 그리고 '제품ID'와 '고객ID' 각각의 관계를 별도의 테이블로 만들면 됩니다.
다음은 5NF를 만족하는 테이블입니다:
공급업체와 제품 테이블:
제품과 고객 테이블:
이렇게 5NF를 적용하면 데이터 중복성을 더욱 줄일 수 있고, 업데이트 이상(Anomalies)을 방지할 수 있습니다.
이미지 출처 : https://hoon93.tistory.com
