정규화는 데이터를 각각 열이 적고 한 테이블에서 다른 테이블로의 참조가 있는 잘 정의된 여러 테이블로 분할하는 프로세스입니다
정규화에서는 최종적으로 데이터가 잘 정의된 좁은 테이블(좁은 테이블은 열이 적은 테이블)로 분할되고, 한 테이블에서 다른 테이블로 참조가 이루어집니다
데이터의 구조뿐만 아니라 데이터 사용 방식에 따라 다양한 방식으로 데이터를 분류할 수 있습니다.
이제 다양한 데이터 유형의 특성에 대해 알아보겠습니다.
관계형 데이터베이스는 아마도 가장 잘 알려진
데이터 보유 모델일 것입니다.
테이블과 열의 구조가 단순하기 때문에 처음에는 쉽게 사용할 수 있습니다.
그러나 견고한 구조로 인해 몇 가지 문제가 발생할 수 있습니다.
예를 들어 고객 정보가 들어 있는 데이터베이스에서
주소가 두 개 이상인 고객을 어떻게 처리할까요?
각 주소의 세부 정보를 보관할 열을 추가합니까?
그렇다면 이 중 몇 개의 열을 추가해야 할까요?
주소를 3개까지 허용할 경우 고객의 주소가 하나뿐이면 어떻게 되나요?
예비 컬럼에 무엇을 저장합니까?
그런데 갑자기 주소가 4개인 고객이 생긴다면 어떻게 될까요?
마찬가지로 주소, 거리 이름,
집 번호, 도시, 우편 번호에는 어떤 정보를 저장합니까?
집에 번호가 아닌 이름이 있거나
우편번호를 사용하지 않는 곳에 있으면 어떻게 되나요?
정규화라는 프로세스를 사용하여 이러한 문제를 해결할 수 있습니다.
일반적으로 정규화 프로세스의 최종 결과는 데이터가
다수의 좁고 잘 정의된 테이블로 분할되는 것입니다.
좁은 테이블은 한 테이블에서
다른 테이블로의 참조가 포함된 열 수가 적은 테이블입니다.
예를 들어,
CustomerID 키를 해당 주소 키와 함께 테이블에 복사할 수 있습니다.
하지만 몇 가지 단점이 있습니다.데이터를
쿼리하려면
런타임에 데이터를 다시 조인하고 다양한 좁은 테이블에
액세스하여 여러 테이블의 정보를 재조합해야 하는 경우가 많습니다.
이러한 유형의 쿼리는 처리하는 데 비용이 많이 들 수 있습니다.
예를 들어 고객이 Jay와
Francis Adams가 같은 주소를 공유하더라도 주소가 한 번만 저장된다고 가정해 보겠습니다.
다음에 설명하겠지만 문서 데이터베이스에서는 그렇지 않습니다.
비관계형 데이터베이스를 사용하면
원래 구조와 더 유사한 형식으로 데이터를 저장할 수 있습니다.
예를 들어 문서 데이터베이스에서는
이전 단원의 예와 같이 각 고객의 세부 정보를 단일 문서에 저장할 수 있습니다.
주소를 포함한 고객의 세부 정보를 검색하려면
문서 한 개만 읽으면 됩니다.
하지만 문서 데이터베이스를 사용하면 몇 가지 단점이 있습니다.
두 고객이 같은 주소를 가지고
동거하는 경우 관계형 데이터베이스에서는 주소 정보를 한 번만 저장하면 됩니다.
이 예시에서는 Jay와 Francis Adams가 모두 같은 주소를 공유했습니다.
따라서 주소 정보는 한 번만 저장됩니다.
문서 데이터베이스의 경우
Jay Adams와 Francis Adams의 문서에는 주소가 중복됩니다.
이렇게 중복되면 필요한 스토리지가 늘어날 뿐만 아니라 유지 관리가 더 복잡해질
수 있습니다.
주소가 변경되면 두 문서에서 수정해야 합니다.
관계형 데이터베이스와 비관계형 데이터베이스는 서로 다른 워크로드에 적합합니다.
관계형 데이터베이스의 주요 용도는 트랜잭션 처리를 처리하는 것입니다.
트랜잭션은 원자적인 일련의 작업입니다.
즉, 시퀀스의 모든 작업이
성공적으로 완료되거나, 문제가 발생하면
시퀀스에서 지금까지 실행된 모든 작업을 실행 취소하거나 롤백해야 합니다.