Docs Menu
Docs Home
/ /
Atlas App Services
/ /

스키마 정의 및 적용

이 페이지의 내용

  • 스키마 정의하기
  • Null 유형 유효성 검사

컬렉션에 있는 문서의 모양과 내용은 스키마를 정의하여 제어할 수 있습니다. 스키마를 사용하면 특정 필드를 요구하고, 필드 값의 유형을 제어하고, 쓰기 작업을 커밋하기 전에 변경 사항의 유효성을 검사할 수 있습니다.

이 가이드에서는 연결된 MongoDB Atlas 컬렉션에 대한 스키마를 정의, 구성 및 배포하는 방법을 보여줍니다.

참고

연합 데이터 소스는 규칙이나 스키마를 지원하지 않습니다. 연합 데이터 소스에는 시스템 기능에서만 액세스할 수 있습니다.

Atlas App Services UI 또는 App Services CLI 를 사용하여 컬렉션에 대한 스키마를 정의할 수 있습니다.

Atlas App Services UI를 사용할 때 다음을 선택할 수 있습니다.

  • 컬렉션의 기존 데이터에서 스키마를 생성하고 필요에 따라 수정합니다.

  • 필드 수준 스키마 정의를 추가하여 스키마를 수동으로 정의합니다.

1

왼쪽 탐색 메뉴에서 Schema Data Access 아래의 을 클릭하여 스키마 편집기를 엽니다. 컬렉션 구성 화면이 Collections 탭 에 표시됩니다. Atlas App Services 는 연결된 클러스터 에서 기존 컬렉션을 검색하고 이를 스키마 편집기 왼쪽에 나열합니다.

메뉴에서 컬렉션 을 찾아 선택하면 스키마 편집기 오른쪽에 컬렉션 구성이 표시됩니다.

App Services UI 의 스키마 화면
클릭하여 확대
2

컬렉션 에 이미 데이터가 있는 경우 App Services 는 컬렉션 에 있는 문서의 하위 집합을 샘플 하고 샘플 을 기반으로 스키마 를 생성할 수 있습니다. 이미 스키마가 있거나 스키마 를 수동으로 정의하려는 경우 다음 단계로 건너뛰세요.

샘플링할 문서 수를 구성하고 MongoDB 쿼리 언어를 사용하여 샘플을 특정 문서로 제한할 수 있습니다. 기본적으로 App Services는 전체 collection에서 최대 500개의 문서를 무작위로 샘플링합니다.

기존 데이터로 스키마를 생성하려면

  1. 스키마 편집기 오른쪽에 있는 컬렉션 구성에서 Generate Schema 을 클릭하여 샘플 구성 화면을 엽니다.

  2. 최대 50,000개 문서까지 샘플 크기를 지정합니다.

  3. 선택 사항으로 Advanced을 클릭하고 쿼리, 프로젝션 및/또는 정렬을 지정해 샘플 쿼리를 세분화할 수 있습니다. 쿼리 및 정렬 필터를 사용하여 문서의 특정 하위 집합을 샘플링하고 프로젝션 필터를 사용해 각 문서에서 특정 필드의 하위 집합을 샘플링할 수 있습니다.

  4. 샘플 쿼리를 실행하고 스키마를 생성하려면 Generate을 클릭합니다. 샘플링된 문서의 수와 내용에 따라 프로세스는 최대 1분 정도 소요됩니다.

App Services UI 에서 스키마 샘플 크기 입력 생성
클릭하여 확대
3

스키마를 수동으로 정의하거나 필드 수준 스키마 정의를 추가하여 기존 스키마를 수정할 수 있습니다.

각 컬렉션 에 대해 단일 BSON 스키마 를 정의할 수 있습니다. 각 컬렉션 스키마 의 루트 수준 유형은 컬렉션 의 문서 를 나타내는 object 스키마 입니다. 루트 스키마의 properties 필드 내에서 문서 필드에 대한 추가 스키마를 정의할 수 있습니다.

JSON schema 객체에서 사용할 수 있는 필드는 스키마가 정의하는 값 유형에 따라 다릅니다. 지원되는 유형 목록과 구성 방법에 대한 자세한 내용은 스키마 유형을 참조하세요.

예시

App Services를 사용해 13세 이상인 사용자가 자신이 좋아하는 색상의 순위 목록을 제출할 수 있는 투표 앱을 운영하는 그룹이 있습니다. 각 문서는 한 사람의 투표를 나타내는 votes이라는 이름의 MongoDB collection에 투표를 저장합니다. 각 투표에는 해당 인물의 이름, 나이, 선호하는 색상 배열이 포함되어야 합니다. 각 색상에는 rank, namehexCode이 있습니다. 다음은 votes collection의 일반적인 문서입니다.

{
"name": "Jane Doe",
"age": 42,
"favoriteColors": [
{ "rank": 1, "name": "RebeccaPurple", "hexCode": "#663399" },
{ "rank": 2, "name": "DodgerBlue", "hexCode": "#1E90FF" },
{ "rank": 3, "name": "SeaGreen", "hexCode": "#2E8B57" },
]
}

그룹은 다음 스키마를 사용하여 votes 컬렉션의 각 문서에 대해 나열된 제약 조건이 충족되도록 할 수 있습니다.

{
"bsonType": "object",
"required": ["name", "age", "favoriteColors"],
"properties": {
"name": {
"bsonType": "string"
},
"age": {
"bsonType": "int",
"minimum": 13,
"exclusiveMinimum": false
},
"favoriteColors": {
"bsonType": "array",
"uniqueItems": true,
"items": {
"bsonType": "object",
"properties": {
"rank": { "bsonType": "int" },
"name": { "bsonType": "string" },
"hexCode": {
"bsonType": "string",
"pattern": "^#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})$"
}
}
}
}
}
}
4

각 필드의 콘텐츠를 구성하는 것 외에도 스키마의 validate 필드에 유효성 검사 표현식을 정의해 문서에 대한 변경 사항의 유효성을 검사할 수 있습니다. 유효성 검사 표현식은 %%prev%%prevRoot 확장을 사용하여 삽입 또는 업데이트 작업이 수행되기 에 필드 또는 문서의 값에 액세스할 수 있습니다.

예시

문서의 owner_id 필드가 각 문서의 소유자를 나타내는 collection을 생각해 보세요. 이 collection의 비즈니스 규칙은 문서에 소유자가 있으면 owner_id의 값이 절대 변경되지 않도록 지정하고 있습니다. 다음 유효성 검사 표현식을 사용하여 이 제약 조건을 적용하면 업데이트 작업이 이전에 소유자가 없던 곳에 소유자를 할당하는 것이 아니라면 owner_id 값을 변경하지 않도록 할 수 있습니다.

"owner_id": {
"validate": {
"%or": [
{ "%%prev": { "%exists": false } },
{ "%%prev": "%%this" }
]
}
}

%%prevRoot 확장을 사용하여 다음과 같은 동등한 유효성 검사 표현식을 만들 수도 있습니다:

"owner_id": {
"validate": {
"%or": [
{ "%%prevRoot.owner_id": { "%exists": false } },
{ "%%prevRoot.owner_id": "%%root.owner_id" }
]
}
}
5

스키마를 구성한 후 Save을 클릭합니다. 저장 후 App Services는 이후의 모든 쿼리에 대해 즉시 스키마 적용을 시작합니다.

참고

스키마와 일치하지 않는 기존 문서는 자동으로 업데이트되거나 유효성이 검사되지 않으므로 향후 이러한 문서를 변경하면 스키마 유효성 검사에 실패할 수 있습니다.

6

컬렉션 스키마를 저장한 후에는 컬렉션의 기존 문서가 스키마를 준수하는지 검증할 수 있습니다.

App Services는 자동 스키마 생성과 마찬가지로 유효성 검사를 위해 문서를 샘플링합니다.

collection에서 데이터의 유효성을 검사하는 방법:

  1. Run Validation버튼을 클릭하여 유효성 검사 구성 창을 엽니다.

  2. 최대 50,000개 문서까지 샘플 크기를 지정합니다.

  3. 선택 사항으로 Advanced을 클릭하고 쿼리 및/또는 정렬을 지정하여 문서의 특정 하위 집합으로 유효성 검사를 세분화할 수 있습니다.

  4. collection에서 문서를 샘플링하고 스키마를 기준으로 각 문서의 유효성을 검사하려면 Run Validation을 클릭합니다.

유효성 검사가 완료되면 App Services는 샘플의 유효성 검사 오류를 JSON Validation Errors 테이블에 나열합니다. 테이블의 각 행은 특정 필드에 대한 특정 유형의 유효성 검사 오류를 나타내며 이러한 방식으로 유효성 검사에 실패한 문서의 수를 나타냅니다.

각 유효성 검사 오류에 대해 Actions 메뉴를 사용하여 실패한 원시 문서를 다운로드하거나 실패한 문서를 찾는 MongoDB 쿼리를 복사할 수 있습니다.

App Services UI 의 스키마 유효성 검사 오류를 표시하는 표
클릭하여 확대
1

appservices로 앱을 구성하려면 앱 이 포함된 조직 또는 프로젝트 로 범위가 지정된 API 키 를 사용하여 MongoDB Cloud 로그인 해야 앱.

appservices login --api-key="<MongoDB Cloud Public API Key>" --private-api-key="<MongoDB Cloud Private API Key>"
2

appservices 을 사용하여 문서 스키마 를 정의하려면 애플리케이션 구성 파일의 로컬 복사본이 필요합니다.

최신 버전의 앱의 로컬 사본을 가져오려면 다음을 실행하세요.

appservices pull --remote="<Your App ID>"

Realm UI의 Deploy > Import/Export App 화면에서 애플리케이션의 구성 파일 사본을 다운로드할 수도 있습니다.

3

컬렉션 의 스키마 를 정의하거나 수정하려면 컬렉션의 구성 디렉토리 에서 schema.json 구성 파일 을 엽니다.

컬렉션 스캐폴드

컬렉션 에 대한 규칙이나 스키마 를 아직 정의하지 않은 경우 구성 디렉토리 와 schema.json 를 수동으로 만들어야 합니다.

# Create the collection's configuration directory
mkdir -p data_sources/<service>/<db>/<collection>
# Create the collection's schema file
echo '{}' >> data_sources/<service>/<db>/<collection>/schema.json

모든 문서 의 루트 수준 스키마 는 object 유형이어야 합니다. 추가 스키마 를 사용하여 properties 배열 내의 특정 필드를 구성할 수 있습니다. 스키마 는 최소한 다음과 유사해야 합니다.

/data_sources/<service>/<db>/<collection>/schema.json
{
"bsonType": "object",
"properties": {
"<Field Name>": <Schema Document>,
...
}
}
4

스키마 의 validate 필드 에 유효성 검사 표현식 을 정의하여 문서 변경 사항의 유효성을 검사할 수 있습니다. 유효성 검사 표현식은 %%prev%%prevRoot 확장을 사용하여 삽입 또는 업데이트 작업이 발생 하기 전에 필드 또는 문서의 값에 액세스 .

예시

문서의 owner_id 필드가 각 문서의 소유자를 나타내는 collection을 생각해 보세요. 이 collection의 비즈니스 규칙은 문서에 소유자가 있으면 owner_id의 값이 절대 변경되지 않도록 지정하고 있습니다. 다음 유효성 검사 표현식을 사용하여 이 제약 조건을 적용하면 업데이트 작업이 이전에 소유자가 없던 곳에 소유자를 할당하는 것이 아니라면 owner_id 값을 변경하지 않도록 할 수 있습니다.

"owner_id": {
"validate": {
"%or": [
{ "%%prev": { "%exists": false } },
{ "%%prev": "%%this" }
]
}
}

%%prevRoot 확장을 사용하여 다음과 같은 동등한 유효성 검사 표현식을 만들 수도 있습니다:

"owner_id": {
"validate": {
"%or": [
{ "%%prevRoot.owner_id": { "%exists": false } },
{ "%%prevRoot.owner_id": "%%root.owner_id" }
]
}
}
5

schema.json 를 정의하고 저장한 후에는 업데이트된 구성을 원격 앱 에 푸시할 수 있습니다. App Services CLI 는 푸시 시 새 스키마 를 즉시 배포합니다.

appservices push --remote="<Your App ID>"

App Services의 기본 동작은 각 필드에 대해 단일 유형만 허용하는 것입니다. null은 고유한 BSON 유형이므로 스키마 필드는 기본적으로 null을 허용하지 않습니다.

선택적 필드와 함께 null 값을 사용할 때 스키마 유효성 검사 를 통과하도록 App Services 를 구성할 수 있습니다. null 형식 유효성 검사 를 활성화하면 필드 값을 스키마 의 형식 또는 BSON null 형식으로 유지할 수 있습니다. null 형식 스키마 유효성 검사 를 활성화 하지 않으면 App Services 는 선택적 필드에 전달된 null 값을 거부합니다. null 형식 유효성 검사 를 활성화 하더라도 필수 필드는 null을 허용하지 않습니다.

App Services UI에서 널 형식 스키마 유효성 검사를 활성화하려면 다음을 수행합니다.

  1. Manage 헤더 아래의 왼쪽 탐색 메뉴에서 App Settings을 선택합니다.

  2. General 탭에서 Null Type Schema Validation 섹션으로 이동합니다. 스위치를 ON으로 전환합니다.

  3. Save 버튼을 클릭합니다.

돌아가기

Schemas