관계 모델링
이 아티클에서는 Azure Table Storage 솔루션을 디자인할 수 있도록 모델링 프로세스를 설명합니다.
도메인 모델 빌드는 복잡한 시스템의 디자인에서 중요한 단계입니다. 일반적으로 엔터티와 해당 엔터티 간의 관계를 식별하는 모델링 프로세스를 사용하여 비즈니스 도메인을 이해하고 시스템 디자인에 대한 정보를 제공합니다. 이 섹션에서는 도메인 모델에서 일반적으로 발견되는 일부 관계 유형을 Table service의 디자인으로 변환하는 방법을 중점적으로 알아봅니다. 논리적 데이터 모델과 실제 NoSQL 기반 데이터 모델을 매핑하는 프로세스는 관계형 데이터베이스를 디자인할 때 사용되는 프로세스와 다릅니다. 관계형 데이터베이스 디자인에서는 일반적으로 중복을 최소화하는 데 최적화된 데이터 정규화 프로세스 및 데이터베이스 작동 방식의 구현을 추상화하는 선언적 쿼리 기능을 가정합니다.
일대다 관계
비즈니스 도메인 개체 간의 일대다 관계는 빈번하게 발생합니다. 예를 들어 하나의 부서에 여러 직원이 있는 경우가 여기에 해당합니다. Table service에서 일대다 관계를 구현하는 방법에는 여러 가지가 있으며, 각 방법마다 특정 시나리오와 관련될 수 있는 장단점이 있습니다.
수만 개의 부서 및 직원 엔터티가 있고, 모든 부서에 여러 직원이 있으며, 각 직원이 하나의 특정 부서에 연결된 대규모 다국적/지역 기업을 예로 들어 보겠습니다. 별도의 부서 및 직원 엔터티를 저장하는 한 가지 접근 방식은 다음과 같습니다.
이 예는 PartitionKey 값을 기반으로 형식 간의 암시적 일대다의 관계를 보여 줍니다. 각 부서에는 여러 직원이 있을 수 있습니다.
또한 이 예에서는 부서 엔터티와 해당 관련 직원 엔터티가 동일한 파티션에 있습니다. 여러 엔터티 유형에 대해 서로 다른 파티션, 테이블 또는 스토리지 계정을 사용하도록 선택할 수 있습니다.
다른 접근 방식은 다음 예와 같이 데이터를 비정규화하고 비정규화된 부서가 있는 직원 엔터티만 저장하는 것입니다. 이 특정 시나리오에서는 부서 관리자 정보를 변경할 수 있어야 하는 요구 사항이 있는 경우 이 비정규화된 접근 방식이 적합하지 않을 수 있습니다. 부서 관리자 정보를 변경하려면 부서의 모든 직원을 업데이트해야 하기 때문입니다.
자세한 내용은 이 가이드의 뒷부분에 있는 비정규화 패턴 을 참조하세요.
다음 표에는 일대다 관계가 있는 직원 및 부서 엔터티를 저장하는 측면에서 위에 설명된 각 접근 방식의 장단점이 요약되어 있습니다. 여러 작업을 수행할 빈도도 고려해야 합니다. 비용이 많이 드는 작업이 자주 발생하지 않는 경우에만 해당 작업을 디자인에 포함할 수도 있습니다.
| 접근 방식 | 장점 | 단점 |
|---|---|---|
| 별도의 엔터티 유형, 동일한 파티션, 동일한 테이블 |
|
|
| 별도의 엔터티 유형, 서로 다른 파티션, 테이블 또는 스토리지 계정 |
|
|
| 단일 엔터티 유형으로 비정규화 |
|
|
*자세한 내용은 엔터티 그룹 트랜잭션을 참조하세요.
이러한 옵션 간에 선택하는 방법 및 가장 중요한 장단점은 특정 애플리케이션 시나리오에 따라 다릅니다. 예를 들어 부서 엔터티를 수정하는 빈도, 모든 직원 쿼리를 수행하는 데 추가 부서 정보가 필요한지 여부, 파티션 또는 스토리지 계정의 확장성 제한에 얼마나 근접했는지 여부 등에 따라 달라집니다.
일대일 관계
도메인 모델은 엔터티 간의 일대일 관계를 포함할 수 있습니다. Table service에서 일대일 관계를 구현해야 하는 경우 두 관련 엔터티를 모두 검색해야 할 때 해당 엔터티를 연결하는 방법도 선택해야 합니다. 이 링크는 키 값의 명명 규칙에 따라 암시적일 수 있으며, 각 엔터티의 PartitionKey 및 RowKey 값 형식으로 링크를 해당 관련 엔터티에 저장할 경우 명시적일 수 있습니다. 관련 엔터티를 동일한 파티션에 저장해야 하는지 여부에 대한 자세한 내용은 일대다 관계섹션을 참조하세요.
Table service에서 일대일 관계를 구현하기 위한 구현 고려 사항도 있습니다.
- 큰 엔터티 처리(자세한 내용은 큰 엔터티 패턴참조)
- 액세스 제어 구현(자세한 내용은 공유 액세스 서명을 사용하여 액세스 제어 참조).
클라이언트에 조인
Table service에서 관계를 모델링하는 방법에는 여러 가지가 있지만 Table service를 사용하는 두 가지 주요 이유는 확장성과 성능이라는 점을 잊어서는 안 됩니다. 솔루션의 성능 및 확장성을 저하시키는 많은 관계를 모델링할 경우 모든 데이터 관계를 테이블 디자인에 빌드할 필요가 있는지 자문해 보아야 합니다. 클라이언트 애플리케이션에서 필요한 조인을 수행할 수 있도록 하면 디자인을 간소화하고 솔루션의 확장성 및 성능을 향상시킬 수 있습니다.
예를 들어 자주 변경되지 않는 데이터가 포함된 작은 테이블이 있는 경우 이 데이터를 한 번 검색하여 클라이언트에 캐시할 수 있습니다. 그러면 동일한 데이터를 검색하기 위한 반복 작업을 방지할 수 있습니다. 이 가이드에서 살펴본 예제에서는 소규모 조직의 부서 집합이 작고 자주 변경되지 않을 수 있으므로 클라이언트 애플리케이션에서 한 번 다운로드하여 조회 데이터로 캐시할 수 있는 데이터로 적절합니다.
상속 관계
클라이언트 애플리케이션에서 상속 관계의 일부를 구성하는 클래스 집합을 사용하여 비즈니스 엔터티를 나타내는 경우 Table 서비스에서 이러한 엔터티를 쉽게 유지할 수 있습니다. 예를 들어 사람 이 추상 클래스인 클라이언트 애플리케이션에 다음과 같은 클래스 집합이 정의되어 있을 수 있습니다.
다음과 같이 엔터티를 사용하는 단일 Person 테이블을 사용하여 Table service에서 구체적 클래스 두 개의 인스턴스를 유지할 수 있습니다.
클라이언트 코드에서 동일한 테이블에 있는 여러 엔터티 형식으로 작업하는 방법에 대한 자세한 내용은 이 가이드의 뒷부분에 있는 형식이 다른 엔터티 형식 작업 섹션을 참조하세요. 이 섹션에서는 클라이언트 코드에서 엔터티 유형을 인식하는 방법에 대한 예제를 제공합니다.