기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 문서 이해
문서 데이터베이스는 관계형 데이터베이스에서처럼 각각 고유하고 고정된 구조를 가진 여러 테이블의 데이터를 정규화하는 대신 반정형 데이터를 문서로 저장하는 데 사용됩니다. 문서 데이터베이스에 저장된 문서는 중첩된 키-값 페어를 사용하여 문서의 구조 또는 스키마를 제공합니다. 그러나, 동일한 문서 데이터베이스에 다른 유형의 문서를 저장할 수 있으므로 다른 형식의 유사한 데이터를 처리하기 위한 요구 사항을 충족할 수 있습니다. 예를 들어, 각 문서는 자체적으로 설명되므로 [문서 데이터베이스의 예제 문서](#document-database-documents) 주제에 설명된 온라인 상점을 위한 JSON 인코딩 문서를 동일한 문서 데이터베이스에 저장할 수 있습니다.
**Topics**
+ [SQL 대 비관계형 용어](#document-database-sql-vs-nosql-terms)
+ [단순 문서](#document-database-documents-simple)
+ [내장 문서](#document-database-documents-embeded)
+ [문서 데이터베이스의 예제 문서](#document-database-documents)
+ [문서 데이터베이스에서 정규화 이해](#document-database-normalization)
## SQL 대 비관계형 용어
다음 표에서는 문서 데이터베이스(MongoDB)에서 사용하는 용어를 SQL 데이터베이스에서 사용하는 용어와 비교합니다.
| SQL | MongoDB |
| --- | --- |
| 표 | 수집 |
| 열 | 문서 |
| 열 | Field |
| 프라이머리 키 | ObjectId |
| 인덱스 | 인덱스 |
| 보기 | 보기 |
| 중첩된 테이블 또는 객체 | 포함 문서 |
| 배열 | 배열 |
## 단순 문서
문서 데이터베이스의 모든 문서는 자체적으로 설명되어 있습니다. 이 설명서에서는 다른 인코딩 수단을 사용할 수 있는 경우에도 JSON과 유사한 형식의 문서를 사용합니다.
단순 문서에는 문서 내에서 모두 동일한 수준인 하나 이상의 필드가 있습니다. 다음 예에서 `SSN`, `LName`, `FName`, `DOB`, `Street`, `City`, `State-Province`, `PostalCode` 및 `Country` 필드는 문서 내에서 모두 형제 요소입니다.
```
{
"SSN": "123-45-6789",
"LName": "Rivera",
"FName": "Martha",
"DOB": "1992-11-16",
"Street": "125 Main St.",
"City": "Anytown",
"State-Province": "WA",
"PostalCode": "98117",
"Country": "USA"
}
```
단순 문서에서 정보를 구성할 때 각 필드는 개별적으로 관리됩니다. 개인의 주소를 가져오려면 `Street`, `City`, `State-Province`, `PostalCode` 및 `Country`를 개별 데이터 항목으로 가져와야 합니다.
## 내장 문서
복잡한 문서는 문서 내에 내장 문서를 생성하여 데이터를 구성합니다. 내장 문서는 데이터 그룹화 및 개별 데이터 항목 중 제공된 사례에서 더 효율적인 방식으로 관리하는 데 도움이 됩니다. 이전 예제를 사용하면 기본 문서에 `Address` 문서를 포함할 수 있습니다. 이렇게 하면 다음과 같은 문서 구조가 발생합니다.
```
{
"SSN": "123-45-6789",
"LName": "Rivera",
"FName": "Martha",
"DOB": "1992-11-16",
"Address":
{
"Street": "125 Main St.",
"City": "Anytown",
"State-Province": "WA",
"PostalCode": "98117",
"Country": "USA"
}
}
```
이제 개별 필드(`"SSN":`), 내장 문서(`"Address":`) 또는 내장 문서의 멤버(`"Address":{"Street":}`)로 문서의 데이터에 액세스할 수 있습니다.
## 문서 데이터베이스의 예제 문서
이전에 설명한 대로 문서 데이터베이스의 각 문서는 자체적으로 설명되므로 문서 데이터베이스 내의 문서 구조는 서로 다를 수 있습니다. 다음의 두 문서(책 및 정기 간행물용)는 구조적으로 서로 다릅니다. 하지만 두 문서 모두 동일한 문서 데이터베이스에 있을 수 있습니다.
다음은 샘플 책 문서입니다.
```
{
"_id" : "9876543210123",
"Type": "book",
"ISBN": "987-6-543-21012-3",
"Author":
{
"LName":"Roe",
"MI": "T",
"FName": "Richard"
},
"Title": "Understanding Document Databases"
}
```
다음은 두 개의 기사가 있는 샘플 정기 간행물 문서입니다.
```
{
"_id" : "0123456789012",
"Publication": "Programming Today",
"Issue":
{
"Volume": "14",
"Number": "09"
},
"Articles" : [
{
"Title": "Is a Document Database Your Best Solution?",
"Author":
{
"LName": "Major",
"FName": "Mary"
}
},
{
"Title": "Databases for Online Solutions",
"Author":
{
"LName": "Stiles",
"FName": "John"
}
}
],
"Type": "periodical"
}
```
이 두 문서의 구조를 비교합니다. 관계형 데이터베이스에서는 별도의 "정기 간행물" 및 "책" 테이블이나 "출판", "발행", "기사", "MI" 등 사용하지 않은 필드가 `null` 값인 단일 테이블이 필요합니다. 문서 데이터베이스는 각 문서가 자체 구조를 정의하는 반구조화이므로 이러한 두 문서는 `null` 필드가 없는 동일한 문서 데이터베이스에서 동시에 존재할 수 있습니다. 문서 데이터베이스는 희소 데이터를 처리하는 데 적합합니다.
문서 데이터베이스를 대상으로 개발하면 빠르고 반복적으로 개발할 수 있습니다. 이는 전체 모음에 대한 스키마를 변경하지 않고 문서의 데이터 구조를 동적으로 변경할 수 있기 때문입니다. 문서 데이터베이스는 신속한 개발 및 동적으로 변화하는 환경에 매우 적합합니다.
## 문서 데이터베이스에서 정규화 이해
문서 데이터베이스는 정규화되지 않습니다. 한 문서에서 발견된 데이터가 다른 문서에서 반복될 수 있습니다. 게다가 문서 간에 일부 데이터 차이가 있을 수 있습니다. 예를 들어, 온라인 상점에서 구매하고 구매에 대한 모든 세부 정보가 단일 문서에 저장되는 시나리오를 고려하십시오. 문서는 다음 JSON 문서와 같을 수 있습니다.
```
{
"DateTime": "2018-08-15T12:13:10Z",
"LName" : "Santos",
"FName" : "Paul",
"Cart" : [
{
"ItemId" : "9876543210123",
"Description" : "Understanding Document Databases",
"Price" : "29.95"
},
{
"ItemId" : "0123456789012",
"Description" : "Programming Today",
"Issue": {
"Volume": "14",
"Number": "09"
},
"Price" : "8.95"
},
{
"ItemId": "234567890-K",
"Description": "Gel Pen (black)",
"Price": "2.49"
}
],
"PaymentMethod" :
{
"Issuer" : "MasterCard",
"Number" : "1234-5678-9012-3456"
},
"ShopperId" : "1234567890"
}
```
이러한 모든 정보는 거래 모음에서 문서로 저장됩니다. 나중에 품목 하나를 구매하지 않은 것을 알게 되었습니다. 따라서 다시 동일한 상점에 로그인하여 다시 구매했습니다. 이러한 구매도 거래 모음에서 다른 문서로 저장됩니다.
```
{
"DateTime": "2018-08-15T14:49:00Z",
"LName" : "Santos",
"FName" : "Paul",
"Cart" : [
{
"ItemId" : "2109876543210",
"Description" : "Document Databases for Fun and Profit",
"Price" : "45.95"
}
],
"PaymentMethod" :
{
"Issuer" : "Visa",
"Number" : "0987-6543-2109-8765"
},
"ShopperId" : "1234567890"
}
```
이 두 문서, 즉 이름과 구매자 ID(같은 신용카드를 사용한 경우에는 신용카드 정보)가 중복된다는 점에 주목하세요. 그러나 스토리지가 저렴하고, 각 문서가 조인할 필요가 없는 단순 키-값 쿼리를 사용하여 빠르게 검색할 수 있는 단일 거래를 완전히 기록하기 때문에 괜찮습니다.
또한 신용 카드 정보라는 두 문서 간에도 명백한 차이가 있습니다. 각각의 구매에 대해 다른 신용카드를 사용한 것 같으므로 이러한 분명한 차이는 유일합니다. 각 문서는 문서화된 거래에 대해 정확합니다.