데이터베이스 중복
통제된 중복[edit | edit source]
Controlled Redundancy
통제된 중복은 데이터베이스에서 성능 향상, 데이터 검색 속도 개선 또는 데이터 무결성을 보장하기 위해 의도적으로 중복을 도입하는 경우입니다. 이 경우 데이터베이스 관리 시스템(DBMS)이 중복을 관리하여 데이터 일관성을 유지합니다. 중복은 데이터베이스 설계 단계에서 계획된 것이며, 외래 키(foreign key)나 트리거(trigger) 같은 적절한 메커니즘을 사용하여 중복된 데이터 간의 일관성을 유지합니다.
통제된 중복 예시[edit | edit source]
예를 들어, 은행 데이터베이스에서 고객(Customer) 테이블과 계좌(Account) 테이블이 있다고 가정해봅시다. Customer 테이블에는 고객 ID와 같은 고객 정보가 포함되어 있고, Account 테이블에는 계좌 번호, 잔액 및 관련된 고객 ID가 포함되어 있습니다.
데이터 검색을 최적화하기 위해 Account 테이블에 고객 정보(예: customer_name, customer_address)도 저장(중복)할 수 있습니다. 이렇게 하면 계좌와 고객 정보를 조회할 때 테이블 간 조인이 필요 없어 속도가 빨라집니다. 그러나 DBMS는 외래 키나 트리거를 사용해 Customer 테이블에서 고객 정보가 변경될 때 Account 테이블의 정보도 업데이트되도록 합니다. 이 경우는 통제된 중복으로, 중복된 정보가 있더라도 데이터베이스가 데이터 일관성을 보장합니다.
장점[edit | edit source]
- 쿼리 성능 향상(조인 필요 없음)
- 여러 테이블을 결합하지 않고도 더 나은 리포팅 가능
통제되지 않은 중복[edit | edit source]
Uncontrolled Redundancy
통제되지 않은 중복은 동일한 데이터가 여러 곳에 저장되지만, 중복된 데이터 간의 일관성을 보장하는 메커니즘이 없을 때 발생합니다. 이는 주로 잘못된 데이터베이스 설계나 제약 조건의 부족으로 인해 발생하며, 데이터 이상(anomalies), 비일관성, 저장 공간 낭비 등을 초래합니다.
통제되지 않은 중복 예시[edit | edit source]
학교 데이터베이스에서 학생(Student) 테이블이 각 반의 교사 이름을 저장하고, 동시에 교사(Teacher) 테이블도 교사 이름을 저장한다고 가정해봅시다. 두 테이블에서 교사 이름이 수동으로 입력된다면, 교사 이름이 변경되었을 때 두 테이블의 정보가 동기화되지 않을 수 있습니다(예: 교사가 결혼해서 성이 바뀌는 경우).
만약 일관성을 보장할 수 있는 제약 조건이나 트리거가 없다면, Teachers 테이블에서는 교사 이름이 업데이트되었지만 Students 테이블에서는 여전히 이전 이름이 남아 있을 수 있습니다. 이는 통제되지 않은 중복의 예로, 데이터가 일관되지 않게 됩니다.
문제점[edit | edit source]
- 데이터 비일관성(동일한 데이터의 다른 버전)
- 저장 공간 낭비
- 데이터 유지 및 업데이트의 어려움
