이 모바일 앱에서 필요한 데이터 범위는 꽤 제한적이므로 설계자들은 이름공간 하나만 있어도 충분하다고 판단해서 TrackerNS라는 이름공간을 사용하기로 했다.

고객별로 계좌 번호가 하나씩 있고 이 계좌 번호가 고객을 식별하는 고유 식별자가 된다.

설계자들은 이제 값의 구조를 결정하려고 한다. 사용자 인터페이스의 예비 설계본을 검토한 후 고객 이름과 계좌 번호가 함께 조회되는 경우가 많으므로 이 둘을 리스트 하나로 관리하기로 결정했다. 기본 통화도 자주 사용되므로 고객 이름과 계좌 번호가 있는 리스트에 포함시키기로 했다. 이 앱은 배송 상태를 추적하도록 설계되어 있기 때문에 신용카드 청구지 주소 같은 관리용 정보가 필요 없으므로 이런 데이터는 키-값 데이터베이스에 저장하지 않기로 했다.

앱 설계자들은 키에 ‘엔터티 타입:계좌 번호’ 형태의 명명규칙을 사용하기로 결정했다. 이 앱이 관리하는 데이터의 유형에 대한 정보가 제공되었으므로 설계자들은 데이터베이스에서 다음과 같은 엔터티 타입을 지원하기로 결정했다.

• 고객 정보, 줄여서 cust

• 대시보드 구성 옵션, 줄여서 dshb

• 경보와 알림 명세, 줄여서 alrt

• 사용자 인터페이스 구성, 줄여서 ui

설계의 다음 단계는 엔터티별 속성을 결정하는 것이다. 고객 엔터티는 고객 이름과 선호하는 통화를 관리한다. 계좌 번호는 키의 일부분이므로 값 리스트에 다시 저장할 필요는 없다. 고객에 대한 키-값 쌍의 예는 다음과 같다.

TrackerNS['cust:4719364'] = {'name':'Prime Machine, Inc.', 'currency':'USD'}