NoSQL 데이터베이스, 일반적으로 키-값 데이터베이스에서는 규칙이 좀 다르다. 키-값 데이터베이스에는 미리 정의된 테이블 구조가 없다. 테이블이 없으니 컬럼도 없다. 컬럼이 없는데 키까지 없으면 어떤 값이 있는지 알 도리가 없다. 장바구니 애플리케이션이 의미 없는 키가 있는 키-값 데이터베이스를 사용하고 있다고 가정해보자.

Cart[12387] = 'SKU AK8912j4'

이 키는 관계형 데이터베이스에서 볼 수 있을법한 형식의 식별자다. 이 키-값 쌍은 12387이란 숫자로 식별되는 장바구니에 SKU AK8912j4라는 상품이 담겨 있음을 알려준다. SKU가 Stock Keeping Unit(재고 관리 단위)의 약자이므로 이 값은 유통분야에서 특정 유형의 제품을 나타내는 표준 형식일 거로 추측할 수는 있다. 하지만 이 장바구니가 어느 고객 것인지, 배송 주소는 어디인지는 알 수가 없다.

이 문제를 해결하는 한 가지 방법은 custName 같은 또 다른 이름공간을 생성하는 것이다. 예를 들면 다음과 같이 값을 저장할 수 있다.

CustName[12387] = 'Katherine Smith'

장바구니가 누구 소유인지 식별하는 문제는 해결할 수 있지만, 이런 접근법으로는 모든 문제를 해결하지 못한다. 이런 방식은 애플리케이션이 추적하는 모든 속성에 대해 독립된 이름공간이 필요하다. 따라서 속성 정보를 가진 의미 있는 키를 사용하는 것도 고려해 볼 수 있다.

이전에 설명했듯이 엔터티 형식, 엔터티 식별자, 엔터티 속성에 관한 정보를 포함하는 의미 있는 이름을 만들 수 있다. 예를 들어보자.

Cust : 12387 : firstName

이 키에는 customerID 값이 12387인 고객의 이름이 포함되어 있다. 이렇게 하는 것이 의미 있는 이름을 만드는 유일한 방법은 아니지만, 이 책에서는 이 방식을 사용할 것이다. 키를 만드는 방법을 정리하면 다음과 같다.

Entity Name … 엔터티 이름 + ' : ' + 엔터티 식별자 + ' : ' + 엔터티 속성

꼭 콜론(:)만 사용하라는 법은 없지만 널리 사용되는 구분자다.