dp-900 데이터 유형 및 데이터 저장소 식별

정규화는 데이터를 각각 열이 적고 한 테이블에서 다른 테이블로의 참조가 있는 잘 정의된 여러 테이블로 분할하는 프로세스입니다

정규화에서는 최종적으로 데이터가 잘 정의된 좁은 테이블(좁은 테이블은 열이 적은 테이블)로 분할되고, 한 테이블에서 다른 테이블로 참조가 이루어집니다

 

데이터의 구조뿐만 아니라 데이터 사용 방식에 따라 다양한 방식으로 데이터를 분류할 수 있습니다. 

이제 다양한 데이터 유형의 특성에 대해 알아보겠습니다. 

관계형 데이터베이스는 아마도 가장 잘 알려진 

데이터 보유 모델일 것입니다. 

테이블과 열의 구조가 단순하기 때문에 처음에는 쉽게 사용할 수 있습니다. 

그러나 견고한 구조로 인해 몇 가지 문제가 발생할 수 있습니다. 

예를 들어 고객 정보가 들어 있는 데이터베이스에서 

주소가 두 개 이상인 고객을 어떻게 처리할까요? 

각 주소의 세부 정보를 보관할 열을 추가합니까? 

그렇다면 이 중 몇 개의 열을 추가해야 할까요? 

주소를 3개까지 허용할 경우 고객의 주소가 하나뿐이면 어떻게 되나요?

예비 컬럼에 무엇을 저장합니까? 

그런데 갑자기 주소가 4개인 고객이 생긴다면 어떻게 될까요? 

마찬가지로 주소, 거리 이름, 

집 번호, 도시, 우편 번호에는 어떤 정보를 저장합니까? 

집에 번호가 아닌 이름이 있거나 

우편번호를 사용하지 않는 곳에 있으면 어떻게 되나요? 

정규화라는 프로세스를 사용하여 이러한 문제를 해결할 수 있습니다. 

일반적으로 정규화 프로세스의 최종 결과는 데이터가 

다수의 좁고 잘 정의된 테이블로 분할되는 것입니다. 

좁은 테이블은 한 테이블에서 

다른 테이블로의 참조가 포함된 열 수가 적은 테이블입니다. 

예를 들어, 

CustomerID 키를 해당 주소 키와 함께 테이블에 복사할 수 있습니다. 

하지만 몇 가지 단점이 있습니다.데이터를 

쿼리하려면 

런타임에 데이터를 다시 조인하고 다양한 좁은 테이블에 

액세스하여 여러 테이블의 정보를 재조합해야 하는 경우가 많습니다. 

이러한 유형의 쿼리는 처리하는 데 비용이 많이 들 수 있습니다. 

예를 들어 고객이 Jay와 

Francis Adams가 같은 주소를 공유하더라도 주소가 한 번만 저장된다고 가정해 보겠습니다. 

다음에 설명하겠지만 문서 데이터베이스에서는 그렇지 않습니다. 

비관계형 데이터베이스를 사용하면 

원래 구조와 더 유사한 형식으로 데이터를 저장할 수 있습니다. 

예를 들어 문서 데이터베이스에서는 

이전 단원의 예와 같이 각 고객의 세부 정보를 단일 문서에 저장할 수 있습니다. 

주소를 포함한 고객의 세부 정보를 검색하려면 

문서 한 개만 읽으면 됩니다. 

하지만 문서 데이터베이스를 사용하면 몇 가지 단점이 있습니다. 

두 고객이 같은 주소를 가지고 

동거하는 경우 관계형 데이터베이스에서는 주소 정보를 한 번만 저장하면 됩니다. 

이 예시에서는 Jay와 Francis Adams가 모두 같은 주소를 공유했습니다. 

따라서 주소 정보는 한 번만 저장됩니다. 

문서 데이터베이스의 경우 

Jay Adams와 Francis Adams의 문서에는 주소가 중복됩니다. 

이렇게 중복되면 필요한 스토리지가 늘어날 뿐만 아니라 유지 관리가 더 복잡해질 

수 있습니다. 

주소가 변경되면 두 문서에서 수정해야 합니다. 

관계형 데이터베이스와 비관계형 데이터베이스는 서로 다른 워크로드에 적합합니다. 

관계형 데이터베이스의 주요 용도는 트랜잭션 처리를 처리하는 것입니다. 

트랜잭션은 원자적인 일련의 작업입니다. 

즉, 시퀀스의 모든 작업이 

성공적으로 완료되거나, 문제가 발생하면 

시퀀스에서 지금까지 실행된 모든 작업을 실행 취소하거나 롤백해야 합니다.

 

은행 송금이 좋은 예입니다. 

한 계좌에서 자금을 차감하고 

동일한 금액을 다른 계좌에 입금합니다. 

시스템에 장애가 발생하여 거래를 완료할 수 없는 경우, 거래를 

롤백하여 원래 계좌로 자금을 복원해야 합니다.자금을 

분실해서는 안 됩니다.

 

그런 다음 전송을 다시 시도할 수 있습니다. 

마찬가지로 동일한 자금으로 두 번 입금하고 계좌에 입금할 수 없어야 합니다. 

각 데이터베이스 거래에는 정의된 시작점이 있으며, 

데이터베이스 내에서 데이터를 수정하는 단계가 뒤따릅니다.

마지막으로 데이터베이스는 변경 내용을 커밋하여 영구적으로 만들거나

 

트랜잭션을 다시 시도할 수 있는 시작 지점으로 변경 내용을 롤백합니다. 

트랜잭션 데이터베이스는 트랜잭션을 처리하는 동안 데이터베이스가 일관성을 유지할 수

 

있도록 ACID, 원자성, 일관성, 격리성, 내구성, 속성을 준수해야 합니다.

 

Atomicity는 각 트랜잭션이 완전히 성공하거나 완전히 실패하는 단일 단위로 취급되도록 보장합니다.트랜잭션을 

구성하는 명령문 중 하나라도 완료되지 않으면 

전체 트랜잭션이 실패하고 데이터베이스는 변경되지 않습니다. 

원자계는 정전, 

오류, 충돌 등 모든 상황에서 원자성을 보장해야 합니다. 

일관성을 유지하면 트랜잭션이 

데이터베이스의 데이터를 하나의 유효한 상태에서 다른 유효한 상태로만 가져올 수 있습니다. 

일관된 데이터베이스에서는 

설명할 수 없는 방식으로 데이터가 손실되거나 생성되어서는 안 됩니다. 

앞서 설명한 은행 송금 예시에서는 계좌에 자금을 추가할 경우 

해당 금액의 차감액이 어딘가에 있어야 하며, 외부에서 자금을 

받았을 경우 해당 자금의 출처를 설명하는 기록이 있어야 합니다. 

갑자기 돈을 벌거나 잃을 수는 없습니다. 

격리를 통해 트랜잭션을 동시에 실행하면 

데이터베이스가 트랜잭션이 

순차적으로 실행되었을 때와 동일한 상태가 됩니다. 

동시 프로세스에서는 일관성 없는 상태의 데이터를 볼 수 없습니다. 

예를 들어, 한 계정에서 자금이 차감되었지만 아직 다른 계정에는 

입금되지 않았습니다. 

내구성을 보장하므로 일단 거래가 

커밋되면 

정전이나 충돌과 같은 시스템 장애가 발생하더라도 해당 거래가 계속 약정된 상태로 유지됩니다. 

트랜잭션 

워크로드를 처리하는 데이터베이스 시스템은 본질적으로 복잡합니다.

 

데이터베이스의 일관성과 복구 가능성을 유지하면서 

동시에 동일한 데이터에 액세스하고 수정하려고 시도할 수 있는 동시 사용자를 관리하고, 트랜잭션을 격리된 상태로 처리해야 합니다. 

많은 시스템은 업데이트 또는 수정 

시 데이터에 잠금을 적용하여 관계형 일관성과 격리를 구현합니다. 

잠금은 잠금이 해제될 때까지 다른 프로세스가 데이터를 읽을 

수 없도록 합니다. 

잠금은 트랜잭션이 커밋되거나 롤백될 때만 해제됩니다. 

잠금이 너무 심하면 응용 프로그램이 

잠금이 해제될 때까지 기다리는 동안 성능이 저하될 수 있습니다. 

분산 데이터베이스는 많은 조직에서 널리 사용됩니다. 

분산 데이터베이스는 데이터가 여러 

물리적 위치에 저장되는 데이터베이스입니다.

 

데이터 센터와 같이 동일한 물리적 위치에 있는 여러 컴퓨터에 보관되거나 

상호 연결된 컴퓨터 네트워크를 통해 분산되어 있을 수 있습니다. 

비분산 데이터베이스 시스템과 비교할 때 

분산 데이터베이스에 대한 데이터 업데이트는 여러 위치에 적용하는 데 시간이 걸립니다. 

이 시나리오에서 트랜잭션 일관성이 필요한 경우 

잠금이 매우 오랫동안 유지될 수 있습니다. 특히 

중요한 시점에 데이터베이스 간에 네트워크 장애가 발생하는 경우에는 더욱 그렇습니다. 

이 문제를 해결하기 위해 많은 분산 데이터베이스 관리 시스템에서는 

트랜잭션의 엄격한 격리 요구 사항을 완화하고 최종 일관성을 

구현합니다. 

이러한 형태의 일관성에서는 응용 프로그램이 데이터를 쓸 때 

한 서버에서 각 변경 내용을 기록한 다음 

분산 데이터베이스 시스템의 다른 서버에 비동기적으로 전파합니다. 

이 전략은 대기 시간을 최소화하는 데 도움이 되지만 데이터에 

일시적인 불일치가 발생할 수 있습니다. 

최종 일관성은 애플리케이션에 주문 보장이 

필요하지 않은 경우에 이상적입니다.소셜 미디어 

시스템의 공유 수, 좋아요 수, 

스레드가 없는 댓글 수 등을 예로 들 수 있습니다. 

분석 워크로드는 일반적으로

 

 

판매 실적 및 재고 수준과 같은 방대한 양의 과거 데이터 또는 비즈니스 지표를 저장하는 읽기 전용 시스템입니다. 

분석 워크로드는 데이터 분석 및 의사 결정에 사용됩니다. 

분석은 원시 데이터에서 제시한 사실을 

요약, 추세 및 기타 종류의 비즈니스 정보로 집계하여 생성됩니다. 

분석은 특정 시점의 데이터 스냅샷 또는 

일련의 스냅샷을 기반으로 할 수 있습니다. 

의사 결정권자는 일반적으로 모든 거래의 모든 세부 정보를 요구하지 않고 

더 큰 그림을 원합니다. 

분석 정보의 예로는 월별 매출 보고서를 들 수 있습니다. 

영업 부서장으로서 

발생한 모든 일일 

거래와 거래 정보를 볼 필요는 없지만 추세를 파악하고 

결정을 내리고 분석 정보를 내리기 위해서는 월별 판매 보고서가 반드시 필요합니다. 

하지만 거래 정보는 분석 정보의 필수적인 부분입니다. 

일일 매출 기록이 좋지 않으면 추세를 

파악하는 데 유용한 보고서를 작성할 수 없습니다.

 따라서 거래 정보를 효율적으로 처리하는 것이 매우 중요합니다.