기본 용어
엔터티(Entity)
데이터의 집합, 인스턴스들의 집합
업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것
개체들의 특성을 설명할 수 있는 속성을 가짐.
눈에 보이지 않는 개념적인 형태로 존재
현업 업무에서 사용하는 용어를 사용해야 하며 약어 지양
이름의 의미는 엔터티 생성의 의미를 드러내야함
특징
업무에 필요하고 관리하고자하는 정보이어야 하며, 유일한 식별자로 식별이 가능해야함.
영속적으로 존재하는 인스턴스의 집합이어야 하며, 업무 프로세스에 의해 이용되어야 함.
반드시 속성이 존재해야하고 다른 엔터티와 최소 한 개 이상의 관계가 있어야함.
통계용 엔터티 도출, 코드성 엔터티 도출, 내부 필요에 의한 엔터티(예 : 트랜잭션 로그)도출 시에는 관계를 생략할 수 있음.
한 개의 엔터티는 2개 이상의 인스턴스 집합이면서 2개 이상의 속성을 가져야함
형태에 따른 분류
- 유형 엔터티(Tangible Entity)
- 물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔터티
- ex) 사원, 강사, 물품
- 개념 엔터티(Conceptual Entity)
- 관리해야할 개념적인 정보로 구분이 되는 엔터티
- ex) 조직, 보험상품
- 사건 엔터티(Event Entity)
- 업무를 수행함에 따라 발생되는 엔터티로 발생량이 많고 통계자료에 이용됨
- ex) 주문, 청구, 미납
발생시점에 따른 분류
- 기본/키 엔터티(Fundamental/Key Entity)
- 독립적으로 생성이 가능하고, 타 엔터티의 부모역할을 하며 고유한 주식별자를 가지는 엔터티
- ex) 사원, 부서, 고객, 상품, 자재)
- 중심 엔터티(Main Entity)
- 기본엔터티로부터 발생되고 업무에 있어서 중심적인 역할을 하는 엔터티
- ex) 계약, 사고, 예금원장, 청구, 주문, 매출
- 행위 엔터티(Active Entity)
- 2개 이상의 부모 엔터티로부터 발생되고 내용이 자주 바뀌거나 데이터량이 증가함.
- 분석 초기단계에서는 잘 나타나지 않으며 상세 설계 단계나 프로세스와의 상관모델링 과정에서 도출될 수 있음
- ex) 주문목록, 사원변경이력
속성(attribute) = 컬럼
저장하고 싶은 개채의 항목
하나의 열은 하나의 속성 정보 표시
업무에서 필요로하는 인스턴스
의미상 더이상 분리되지 않는 최소의 데이터 단위
특징
업무에서 필요하고 관리하고자하는 정보
정규화 이론에 근간하여 주식별자에 함수적 종속성을 가져야 함.
하나의 속성에는 한 개의 값만을 가지며 하나의 속성에 여러개의 값이 있는 다중값일 경우 별도의 엔터티로 분리
특성에 따른 분류
- 기본속성(Basic Attribute)
- 업무 분석을 통해 추출한 모든 속성
- 대부분의 속성
- ex) 코드성 데이터, 엔터티 식별을 위한 일련번호 등
- 설계속성(Designed Attribute)
- 데이터 모델링 및 업무의 규칙화를 위해 새로 만들거나 변형하여 정의하는 속성
- 유일한 식별자를 부여하기 위해 모델 상에서 새롭게 정의하는 속성
- ex) 코드성 속성, 일련번호 등
- 파생속성(Derived Attribute)
- 다른 속성에 영향을 받아 발생하는 속성
- 프로세스 설계시 정합성 유지를 위해 유의해야할 점이 많고 가능한 적게 만드는 것이 좋음.
엔터티 구성방식에 따른 분류
- 기본 키(Primary Key) : 엔터티를 식별할 수 있는 속성
- 외래 키(Foregin Key) : 다른 엔터티와의 관계에서 포함된 속성
- 일반속성 : PK, FK에 해당되지 않는 속성
의미 분할가능여부에 따른 분류
- 복합속성(Composite Attribute) : 시, 구, 동, 번지 등으로 이루어져 여러 세부속성으로 분류할 수 있는 주소와 같은 속성
- 단순속성(Simple Attribute) : 나이, 성별 등 더 이상 다른 속성들로 분할할 수 없는 속성들
가질 수 있는 값의 개수차이에 따른 분류
- 다중값 속성(Multi Value Attribute) : 전화번호와 같이 집, 휴대전화, 회사 전화같은 여러 개의 값을 가질 수 있는 속성
- 단일값 속성(Single Value Attribute) : 주민등록번호와 같이 하나의 값만 존재하는 속성
식별자
하나의 엔터티 내에 구성되어 있는 여러 속성들 중 엔터티를 대표할 수 있는 속성
하나의 엔터티는 반드시 하나의 유일 식별자가 존재
논리 데이터 모델링에서 업무적으로 구분되는 정보
대표성 여부에 따른 분류
- 주 식별자
- 보조 식별자
독립적으로 생성이 가능한지 여부에 따른 분류
- 내부 식별자 : 엔터티 내부에서 스스로 생성되는 식별자
- 외부 식별자 : 타 엔터티와의 관계를 통해 타 엔터티로부터 받아오는 식별자
속성의 수에 따른 분류
- 단일 식별자 : 하나의 속성으로 구성
- 복합 식별자 : 둘 이상의 속성으로 구성
기존의 식별자 속성을 대체해서 만든지에 따른 분류
- 본질 식별자 : 업무에 의해 자연적으로 생성되는 식별자
- 인조 식별자 : 원조식별자가 복잡한 구성을 가지고 있어 편의성을 위해 인위적으로 만든 식별자
식별자 관계에 따른 분류
- 식별자 관계 : 상속받은 부모 엔터티의 식별자를 자식 엔터티의 주식별자로 이용
- 비식별자 관계 : 상속받은 부모 엔터티의 식별자를 자식 엔터티의 일반 식별자로 사용
인스턴스(Instance) = 행
데이터 베이스에 저장된 데이터 내용의 전체 집합
정의된 스키마에 따라 데이터베이스에 실제로 저장된 값
한 개의 인스턴스는 한 개의 속성값을 가져야함
스키마
데이터 베이스에 저장되는 데이터 구조와 제약 조건의 정의
DB를 구성하는 데이터 개체(Entity), 속성(Attribute), 관계(Relationship) 및 데이터 조작시 데이터 값들이 갖는 제약 조건 등에 관해 전반적으로 정의
- 외부 스키마 (서브스키마, 사용자 뷰)
- 사용자가 자신이 필요로 하는 데이터베이스의 논리적 구조
- 하나의 데이터베이스에는 여러 개의 외부 스키마가 존재할 수 있으며 하나의 외부스키마를 여러 사용자가 공용 가능
- 질의어를 이용하여 쉽게 사용 가능
- 개념스키마 (전체적인 뷰)
- 데이터베이스의 전체적인 논리적 구조
- 사용자가 필요로하는 데이터의 종합적인 조직
- 데이터 베이스에 단 하나만 존재
- 개체간의 제약 조건을 나타내고 데이터베이스의 접근 권한, 보안, 데이터 의무 결성을 정의
- 데이터 베이스 관리자에 의해 구성
- 내부 스키마
- 물리적 저장장치와 밀접
- 실제로 저장될 레코드의 구조를 정의하고 데이터 표현, 데이터 순서등을 나타냄
원자값
속성 값이 더이상 논리적으로 분해할 수 없는 값
도메인(domain)
하나의 속성이 취할 수 있는 동일한 유형의 원자값들의 집합
엔티티의 속성들이 가질 수 있는 값들의 집합
릴레이션이 포함된 속성들이 각각 가질 수 있는 값들의 집합
릴레이션
관계형 데이터베이스에서 정보를 구분하여 저장하는 기본 단위
즉 DB 테이블
특징
- 한 릴레이션에 동일한 튜블 불가능
- 한 릴레이션에 포함된 튜플은 순서가 없음
- 한 릴레이션에 동일한 속성값 가능
- 한 릴레이션에 포함된 속성의 명칭은 중복 불가능
- 튜플들의 삽입, 삭제 등의 작업으로 릴레이션은 시간에 따라 변화
- 릴레이션 스키마를 구성하는 속성들간 순서는 중요하지 않음
- 릴레이션을 구성하는 튜플을 유일하게 식별하기 위해 속성들의 부분집합 키로 설정
- 속성의 값은 논리적으로 더 이상 쪼갤 수 없는 원자 값만을 저장
차수(degree)
한 릴레이션 안에 있는 속성 수
유효한 릴레이션의 최소 차수 : 1
모든 릴레이션은 적어도 하나 이상의 속성을 가지고 있음
튜플(tuple, 레코드)
릴레이션의 각 행
카디날리티(cardinality)
릴레이션 튜플의 개수
아직 데이터가 삽입되지 않은 테이블의 경우 0의 값 가능
시간의 흐름에 따라 값이 변화
카우치 베이스(couchbase)
쉽게 수평 확장이 가능하고 고성능의 매우 유연한 문서 기반의 NoSQL 솔류션
응답시간이 매우 빠름
대량의 동시 사용자 처리 가능
다운타임이 거의 없어 365일 가동할 수 있는 솔루션
Json 문서 객체를 지원하기 정보 저장과 변경이 매우 유연하고 쉬움
성능 확장시 서버 시스템을 실시간으로 추가하면서 서비스 용량 확장이 가능하기에 유지 보수 측면에서 매우 편리
일반적으로 카우치베이스 서버는 여러 서버로 구성된 클러스터로 구성
join 연산
두 테이블을 결합하는 연산
(추가로 조사해볼 것)
정규화 =
이상 현상을 제거하기 위해서 데이터베이스를 올바르게 설계해 나가는 과정
함수 종속성을 이용하여 이상 현상이 일어나지 않는 릴레이션으로 설계하는 과정
이상현상(Anomaly)
잘못된 테이블 설계로 나타남
불필요한 데이터 중복으로 인해 릴레이션에 대한 데이터 삽입, 수정, 삭제 연산을 할 때 발생할 수 있는 부작용
- 삽입 이상(Insertion Anomaly)
- 불필요한 정보를 함께 저장하지 않고서는 어떤 정보를 저장하는 것이 불가능
- 튜플 삽입 시 특정 속성에 해당하는 값이 없어 NULL을 입력해야 하는 현상
- 데이터를 삽입하기 위해 불필요한 데이터도 함께 삽입해야 하는 문제
- 삭제 이상(Deletion Anomaly)
- 필요한 정보를 함께 삭제하지 않고서는 어떤 정보를 삭제하는 것이 불가능
- 튜플 삭제 시 같이 저장된 다른 정보까지 연쇄적으로 삭제되는 현상
- 중복 튜플 중 일부만 변경하여 데이터가 불일치하게 되는 문제
- 갱신 이상(Update Anomaly)
- 반복된 데이터 중에 일부를 갱신할 때 데이터 불일치 발생
- 튜플을 삭제하면 꼭 필요한 데이터까지 같이 삭제되는 데이터 손실 문제
- 튜플 갱신 시 중복된 데이터의 일부만 갱신되어 일어나는 데이터 불일치 현상
이상현상의 예시
employee 테이블
근무자 번호(Empolyee_ID), 근무자 명(Name), 근무자가 속한 부서(Department), 참여하고 있는 학생 그룹(Student_Group)
삽입 이상
새로운 부서가 신설되고 아직 근무자가 없을 때, 이 부서와 관련된 정보는 불필요한 정보를 함께 입력하지 않는 한 위 테이블에 입력 불가능
삭제 이상
만약 Accounting 부서에 속한 사람이 J.Longfellow 한 명일 경우 이 부서에 관련된 정보는 불필요한 정보를 함께 입력하지 않는 한 위 테이블에 입력 불가능
갱신 이상
만약 A.Bruchs 부서가 CIS 에서 Marketing으로 바뀐 경우 테이블의 4, 5 번째 행의 CIS를 모두 바꾸지 않고 하나만 바꾼다면 A.Bruchs의 부서는 어디에 속해있는지 알 수 없음
함수 종속성(FD : Functional Dependency)
속성 데이터들의 의미와 속성 간의 상호 관계로부터 유도되는 제약 조건의 일종
실세계에서 존재하는 속성들 사이의 제약 조건으로부터 유도
각종 추론 규칙에 따라 속성들 간의 함수적 종속성 판단 가능
X -> Y
"X는 Y를 함수적으로 결정한다" = "Y는 X에 함수적으로 종속되어 있다"
-X의 값이 Y의 값을 유일하게 결정되는 관계
-X는 Y의 결정자
- Y는 X에 종속됨
함수 종속성의 종류
함수 종속 관계를 판단할 때 현재의 속성 값을 기준으로 판단하면 안 되고 속성에 들어올 수 있는 값들을 고려하여 판단
일반적으로 기본키와 후보 키는 릴레이션의 다른 모든 속성들을 함수적으로 결정
완전 함수 종속 (Full Functional Dependency)
X -> Y 일 때 속성 집합 X의 일부분에는 Y가 종속되어 있지 않음
부분 함수 종속 (Partial Functional Dependency)
X -> Y 일 때 속성 집합 X의 부분집합에도 Y가 함수적으로 종속
이행 함수 종속 (Transitive Functional Dependency)
함수 종속 관계 X -> Y, Y -> Z 가 있으면 논리적으로 X -> Z 가 성립
함수 종속성의 예시
완전 함수 종속
manufacturer 속성, model 속성을 알면 moder full name 속성을 참조 하지 않아도 값을 알 수 있음
=> moder full name 속성은 manufacturer 속성, model 속성에 대해 완전 함수적 종속
부분 함수 종속
manufaturer country 속성은 maunfacture와 종속관계이지만 model 속성과 아무 관계 없음
=> manufaturer country 속성은 maunfacture와 종속관계이지만 model 속성에 대해 부분 함수 충족
함수 종속성 다이어그램(FD Diagram)
- 릴레이션의 속성 : 직사각형
- 속성 간의 함수 종속성 : 화살표
- 복합 속성 : 직사각형으로 묶음
함수 종속성 규칙
정규화
DB 설계 이론, 관계형 모델을 전제로 구축
데이터의 중복을 줄이고 무결성을 향상시키는 등 여러 목적을 달성하기 위해서 재디자인하는 것
즉 이상 현상을 제거하기 위해서 릴레이션을 의미 있는 속성들로만 구성하기 위해 릴레이션을 분해하는 과정
데이터의 중복 속성을 제거하고 결정자에 의해 동일한 의미의 일반 속성이 하나의 테이블로 집약하는 과정
정규화된 테이블은 데이터를 처리할 때 속도가 빨라질 수도 있고 느려질 수도 있음
일반적으로 테이블을 여러개로 분해하면 속도는 상대적으로 느려지지만 이상 문제 감소
속성들끼리의 종속 관계를 분석하여 여러개의 릴레이션으로 분해하는 과정 -> 데이터베이스의 설계 재구성
목적
데이터의 중복 최소화 (저장 공간 최소화, 불필요한 데이터 제거 )
각종 이상 현상 방지
자료 구조의 안정성 최대화
효과적인 검색 알고리즘 (다양한 관점의 query 지원)
데이터 무결성 유지 (무결성 제약조건의 시행 단순화)
정규화의 장점
응용프로그램 단에서 불필요한 로직 제거 가능
불필요한 쿼리 제거로 성능 향상
새로운 데이터 형의 추가로 인한 확장 시, 그 구조를 변경하지 않아도 되거나 일부만 변경 가능
데이터베이스와 연동된 응용 프로그램에 최소한의 영향만을 미치게 되어 응용프로그램의 생명을 연장
정규화의 단점
릴레이션의 분해로 인해 릴레이션 간의 JOIN연산이 많아짐 (응답 시간 증가)
정규화 대상
- OLTP 데이터 베이스 - 정규화
- 온라인 데이터 수정 시스템
- 여러 사람이 다수의 트랜잭션을 실시간으로 실행
- CRUD가 많이 발생하기에 정규화 하는 것이 유리
- ex) 온라인 거래 시스템
- OLAP 데이터 베이스 - 반정규화
- 분석을 목적으로 대량의 데이터를 검색하는 데 사용되는 다차원 온라인 기록 데이터 저장소 시스템
- 일반적으로 분석을 목적으로 데이터베이스 내의 트랜잭션(레코드라고도 불림)을 질의하는 작업을 포함
- 일반적으로 하나 이상의 OLTP 시스템에서 수집한 데이터에 대한 분석을 제공
- 기업이 트랜잭션 데이터로부터 더 많은 인사이트를 추출하여 양질의 정보를 기반으로 한 의사결정에 활용
- ex) 분석 리포트
OLTP 시스템 |
OLAP 시스템 |
| 다수의 사용자에 의한 대량의 데이터베이스 트랜잭션을 실시간으로 실행할 수 있도록 지원 |
일반적으로 분석을 목적으로 데이터베이스 내 다수의 레코드(또는 모든 레코드)에 대한 질의 작업 포함 |
| 빛의 속도에 가까운 빠른 응답시간 필요 | OLTP에 대비 엄청나게 느린 응답시간 필요 |
| 적은 양의 데이터를 자주 수정하고, 일반적으로 읽기 및 쓰기 작업 간 균형이 유지됨 |
데이터를 전혀 수정하지 않음. 일반적으로 읽기 집약적인 작업 |
| 인덱스화된 데이터를 사용해 응답 시간 개선 | 대량의 레코드에 손쉽게 액세스할 수 있도록 컬럼 형식으로 데이터 저장 |
| 데이터베이스에 대한 빈번한 또는 동시 백업 필요 | 훨씬 적은 빈도의 데이터베이스 백업 필요 |
| 상대적으로 적은 스토리지 공간 필요 | 대량의 기록 데이터를 저장하기 때문에 일반적으로 상당한 양의 스토리지 공간 필요 |
| 일반적으로 하나 또는 몇 개의 레코드를 포함하는 단순한 쿼리 실행 |
다수의 레코드를 포함하는 복잡한 쿼리 실행 |
CRUD : (Create, Read, Update, Delete)
반정규화 : 정규화된 시스템을 성능 향상 및 개발과 운영의 단순화를 위해 역으로 정규화 실행
ex) join을 많이 사용하는 경우, 대량의 범위를 자주 처리하는 경우 등 조회에 대한 처리가 중요한 판단에 부분적으로 사용
제1 정규형 (1NF)
속성의 도메인이 오직 원자값만을 포함하고 튜플의 모든 속성이 도메인에 속하는 하나의 값을 가져야 함
복합 속성, 다중값 속성, 중첩 릴레이션 등 비 원자적인 속성을 허용하지 않는 릴레이션 형태
1. 각 속성이 하나의 속성만을 가져야 한다. = 어떤 릴레이션에 속한 모든 도메인이 원자값만으로 되어 있다.
2. 하나의 속성은 같은 종류나 타입의 값을 가져야 한다.
3. 각 속성이 유일한 이름을 가져야 한다.
4. 속성의 순서가 상관없어야 한다
5. 모든 속성에 반복되는 그룹이 나타나지 않아야 한다.
6. 기본 키를 사용하여 관련 데이터의 각 집합을 고유하게 식별할 수 있어야 한다.
예시 1
- 1정규화가 필요한 테이블각 컬럼이 하나의 값(속성)만을 가져야 한다. ->불만족
- 1NF위와 같이 각 칼럼이 원자 값을 갖도록 테이블을 분해
- 하나의 컬럼은 같은 종류나 타입(type)의 값을 가져야 한다. ->만족
- 각 컬럼이 유일한(unique) 이름을 가져야 한다. ->만족
- 칼럼의 순서가 상관없어야 한다. ->만족
예시 2
제2 정규형 (2NF)
모든 비주요 속성들이 주요 속성에 대해 완전 함수적 종속
테이블의 모든 속성이 완전 함수적 종속을 만족
완전 함수적 종속 : 키가 아닌 열들이 각각 후보키에 대해 결정되는 릴레이션 형태
부분 함수적 종속 : 기본키 중에 특정 컬럼에만 종속
제2 정규형에서도 이상현상이 발생 -> 이행적 함수 종속 존재 (제3 정규화가 해결)
1. 1정규형을 만족해야 한다.
2. 모든 컬럼이 부분적 종속(Partial Dependency)이 없어야 한다.== 모든 칼럼이 완전 함수 종속을 만족해야 한다.
예시 1
- 성적의 특정 값을 알기 위해서는 학생 번호+과목이 있어야 함
- 하지만 특정 과목의 지도교수는 과목명만 알면 지도교수가 누군지 알 수 있음
- 위 테이블에서 기본키는 (학생 번호, 과목)으로 복합키
- 그런데 이때 지도교수 칼럼은 (학생 번호, 과목)에 종속되지 않고 (과목) 에만 종속되는 부분적 종속
- 따라서 제2 정규화를 만족하지 않으므로 아래와 같이 분해
예시 2
제3 정규형 (3NF)
어떠한 비주요 속성도 기본키에 대해서 이행적으로 종속되지 않음
기본키 이외의 다른 속성이 그외 다른 속성을 결정할 수 없는 것
비주요 속성이 비주요 속성에 의해 종속되는 경우가 없는 릴레이션 형태
후보키가 여러개인 릴레이션에서는 제3 정규형에서도 이상현상 발생 -> 보이스-코드 정규형으로 해결
이행 종속성 : A->B, B->C 일 때 A->C 가 성립
1. 2 정규형을 만족해야 한다.
2. 기본키를 제외한 속성들 간의 이행 종속성이 없어야 한다.= 기본키가 아닌 속성들은 기본 키에만 의존
예시 1
- ID를 알면 등급을 알 수 있다. 등급을 알면 할인율을 알 수 있다.
- 따라서 ID를 알면 할인율을 알 수 있다.
- 따라서 이행 종속성이 존재하므로 제 3 정규형을 만족하지 않는다.
예시 2
BCNF (Boyce-Codd Normal Form) / Strong 3NF
BCNF는 제 3정규형보다 더 엄격한 제약 조건
보통 정규화는 여기까지 진행되며 그 이상 진행시 단점이 나타날 수 있음
다치 종속성이 발생할 수 있음 (이상현상 )
1. 3정규형을 만족해야 한다.
2. 모든 결정자가 후보키 집합에 속해야 한다. = 후보키 집합에 없는 칼럼이 결정자가 될 수 없음
BCNF 위반 예시
- 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속이므로 2NF를 만족
- 기본키가 아닌 모든 속성이 기본키에 이행적 함수 종속이 되지 않으므로 3NF를 만족
- 결정자인 C가 슈퍼키가 아니기에 BCNF는 위반
예시 1
제3 정규형까지는 만족하는 테이블
- (학생 번호, 과목)이 기본키로 지도교수를 알 수 있다.
- 하지만 같은 과목을 다른 교수가 가르칠 수도 있어서 과목-> 지도교수 종속은 성립하지 않는다.
- 하지만 지도교수가 어떤 과목을 가르치는지는 알 수 있으므로 지도교수-> 과목 종속이 성립한다.
- 이처럼 후보키 집합이 아닌 칼럼이 결정자가 되어버린 상황을 BCNF를 만족하지 않는다고 한다
예시 2
제4 정규형 (4NF)
다치 종속 제거
다치 종속
1. A->B 일 때 하나의 A값에 여러 개의 B값이 존재하면 다치 종속성을 가진다고 하고 A↠B라고 표시
2. 최소 3개의 칼럼이 존재
3. R(A, B, C)가 있을 때 A와 B 사이에 다치 종속성이 있을 때 B와 C가 독립적
1. BCNF를 만족해야 한다.
2.다치 종속(Multi-valued Dependency)이 없어야 한다.
예시 1
- 101번 학생은 자바와 C++ 과목을 수강하고, 노래와 게임을 취미로 가진다.
- 이렇게 되면 학생 번호 하나에 과목 여러 개와 취미 여러 개가 종속된다.
- 이런 경우 학생 번호를 토대로 값을 조회하면 아래와 같이 중복이 발생하게 된다.
- 과목과 취미는 관계가 없는 독립적인 관계
- 하지만 같은 테이블의 학생 번호라는 칼럼에 다치 종속되어버려 중복이 발생하는 문제
- 4NF위 2개의 테이블은 여전히 다치 종속성을 가지지만, 2개 이상의 칼럼이 하나의 칼럼에 다치 종속되지는 않기 때문에 제4 정규형을 만족
제5 정규형 (5NF)
중복을 제거하기 위해 분해할 수 있을 만큼 전부 분해하는 것
조인 종속성 제거
일반적으로 현실의 데이터베이스에서는 5 정규형을 사용하지 않음
1. 4NF를 만족해야 한다.
2. 조인 종속(Join dependency)이 없어야 한다.
3. 조인 연산을 했을 때 손실이 없어야 한다.
조인 종속
다치 종속의 좀 더 일반화된 형태
하나의 릴레이션을 여러 개의 릴레이션으로 무손실 분해했다가 다시 결합할 수 있음
ex) 예를 들어 A라는 릴레이션을 B와 C로 분해했다가 다시 조인했을 때 그대로 A가 된다면, A는 조인 종속성이 있음
다치 종속
1. A->B 일 때 하나의 A값에 여러 개의 B값이 존재하면 다치 종속성을 가진다
2. A↠B라고 표시
2. 최소 3개의 칼럼이 존재
3. R(A, B, C)가 있을 때 A와 B 사이에 다치 종속성이 있을 때 B와 C가 독립적
1. BCNF를 만족해야 한다.
2. 다치 종속(Multi-valued Dependency)이 없어야 한다.
예시 1
- 예를 들어 A라는 릴레이션을 B와 C로 분해했다가 다시 조인했을 때 그대로 A가 된다면, A는 조인 종속성이 있다
기초 용어
https://hoyeonkim795.github.io/posts/db-%EC%9A%A9%EC%96%B4/
https://hoyeonkim795.github.io/posts/couchbase/
https://data-is-power.tistory.com/197
이상 현상 / 함수형
https://code-lab1.tistory.com/47
https://hoyeonkim795.github.io/posts/%EC%9D%B4%EC%83%81/
https://www.oracle.com/kr/database/what-is-oltp/
정규화
https://code-lab1.tistory.com/270
https://code-lab1.tistory.com/48#google_vignette
https://hoyeonkim795.github.io/posts/normalization/
https://hoyeonkim795.github.io/posts/normalization-course/
