翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ドキュメントについて理解する

ドキュメントデータベースは、セミ構造化データをドキュメントとして格納するために使用されます。リレーショナルデータベースのように、それぞれが固有の固定構造を持つ複数のテーブルにわたってデータを正規化するのではなく、ドキュメントとして格納します。ドキュメントデータベースに保存されているドキュメントは、ネストされたキーと値のペアを使用して、ドキュメントの構造またはスキーマを提供します。ただし、さまざまな種類のドキュメントを同じドキュメントデータベースに保存できるため、形式が異なる類似したデータの処理要件を満たします。たとえば、各ドキュメントは自己記述型であるため、トピック「ドキュメントデータベースのドキュメントの例」で説明しているオンラインストアの JSON でエンコードされたドキュメントは、同じドキュメントデータベースに保存することができます。

SQL 用語と非リレーショナル用語の比較

次の表は、SQL データベースによって使用される用語とドキュメントデータベース (MongoDB) で使用される用語を比較したものです。

シンプルなドキュメント

ドキュメントデータベースのすべてのドキュメントは自己記述型です。このドキュメントでは、JSON に似た形式のドキュメントを使用しますが、エンコードの他の方法も使用できます。

単純ドキュメントには、ドキュメント内ですべてが同じレベルの 1 つ以上のフィールドがあります。次の例では、フィールド 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":}) としてアクセスできるようになりました。

ドキュメントデータベースのドキュメントの例

前に説明したように、ドキュメントデータベース内の各ドキュメントは自己記述型であるため、ドキュメントデータベース内のドキュメントの構造は、相互に異なる可能性があります。次の 2 つのドキュメント (1 つは書籍用、もう 1 つは定期刊行物用) は、構造的に異なります。ただし、両方とも同じドキュメントデータベースに存在できます。

書籍ドキュメントの例を次に示します。

{
    "_id" : "9876543210123",
    "Type": "book",
    "ISBN": "987-6-543-21012-3",
    "Author": 
    {
        "LName":"Roe",
        "MI": "T",
        "FName": "Richard" 
    },
    "Title": "Understanding Document Databases"
}

2 つの記事を含む定期刊行物の例を以下に示します。

{
    "_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"
}

これら 2 つのドキュメントの構造を比較します。リレーショナルデータベースでは、別々の「定期刊行物」と「書籍」テーブル、または null の値として「刊行物」、「問題」、「記事」、「MI」など未使用のフィールドを持つ 1 つのテーブルが必要です。ドキュメントデータベースが半構造化され、各ドキュメントが独自の構造を定義しているため、それらの 2 つのドキュメントは null フィールドなしで同じドキュメントデータベースに共存できます。ドキュメントデータベースは、スパースデータの処理に適しています。

ドキュメントデータベースに対する開発により、迅速で反復的な開発が可能になります。これは、動的にドキュメントのデータ構造を変更でき、コレクション全体のスキーマを変更する必要がないためです。ドキュメントデータベースが適しているのは、アジャイル開発と動的に変化する環境です。

ドキュメントデータベースの正規化について

ドキュメントデータベースは正規化されていません。そのため、1 つのドキュメントで見つかったデータを別のドキュメントで繰り返すことができます。さらに、ドキュメント間で一部のデータに相違が発生する場合があります。たとえば、オンラインストアで購入を行い、購入のすべての詳細が 1 つのドキュメントに保存されるシナリオを考えてみます。このドキュメントは、たとえば次の 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" 
}

この情報は、トランザクションコレクションでドキュメントとして保存されます。後で、1 つのアイテムの購入を忘れていることに気付きます。そのため、再度同じストアにログオンし、別の購入を行います。これもトランザクションコレクションの別のドキュメントとして保存されます。

{
    "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" 
}

この 2 つのドキュメント、つまり名前と買い物客 ID (同じクレジットカードを使用した場合はクレジットカード情報) の冗長性に注目してください。しかし、ストレージは安価であり、各ドキュメントは結合が必要ない単純なキーと値のクエリで迅速に取得できる単一のトランザクションを完全に記録するため、問題はありません。

また、2 つの文書の間には、クレジットカード情報という明らかな相違があります。これは明らかな相違であるのは、各購入で別のクレジットカードを使用した可能性が高いためです。各ドキュメントは、記録されるトランザクションについては正確です。