문서 이해

문서 데이터베이스는 관계형 데이터베이스에서처럼 각각 고유하고 고정된 구조를 가진 여러 테이블의 데이터를 정규화하는 대신 반정형 데이터를 문서로 저장하는 데 사용됩니다. 문서 데이터베이스에 저장된 문서는 중첩된 키-값 페어를 사용하여 문서의 구조 또는 스키마를 제공합니다. 그러나, 동일한 문서 데이터베이스에 다른 유형의 문서를 저장할 수 있으므로 다른 형식의 유사한 데이터를 처리하기 위한 요구 사항을 충족할 수 있습니다. 예를 들어, 각 문서는 자체 설명적이므로 해당 항목에 설명된 온라인 스토어용 JSON -encoded 문서는 동일한 문서 데이터베이스에 저장될 문서 데이터베이스의 예제 문서 수 있습니다.

SQL비관계형 용어와 비교.

다음 표는 문서 데이터베이스 (MongoDB) 에서 사용하는 용어와 데이터베이스에서 사용되는 용어를 비교합니다. SQL

SQL	MongoDB
표	수집
열	문서
열	필드
프라이머리 키	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(같은 신용카드를 사용한 경우에는 신용카드 정보)가 중복된다는 점에 주목하세요. 그러나 스토리지가 저렴하고, 각 문서가 조인할 필요가 없는 단순 키-값 쿼리를 사용하여 빠르게 검색할 수 있는 단일 거래를 완전히 기록하기 때문에 괜찮습니다.

또한 신용 카드 정보라는 두 문서 간에도 명백한 차이가 있습니다. 각각의 구매에 대해 다른 신용카드를 사용한 것 같으므로 이러한 분명한 차이는 유일합니다. 각 문서는 문서화된 거래에 대해 정확합니다.