データベース入門

情報

あなたは熟練した開発者で、すでにデータベースについてすべて知っていますか？ 🤓

それなら、すぐにチュートリアル - ユーザーガイド：最初のステップに進むことができます。

データベースについてすべてを知らない場合は、簡単な概要を以下に示します。

後で自分でさらに勉強することもできます。

しかし、これはあなたがデータベースを使い始め、SQLModelで生産的になるのに役立つはずです。 🚀

データベースとは

では、データベースとは何でしょうか？

データベースは、構造化され、非常に効率的な方法でデータを保存および管理するシステムです。

ヒント

「データベース」という単語を「DB」と略するのが非常に一般的です。

データベースに関する情報はたくさんあり、非常に技術的で学術的なものになる可能性があるため、ここでは主要な概念の概要を簡単に説明します。

SQLModelでカバーされていないもの（「NoSQL」データベース）を含む、さまざまな種類のデータベースについても少し説明します。

データベースを使う理由

プログラミングを始めるとき、プログラムのコードとは別にデータベースを持つことが良いアイデアである理由が明確でないかもしれません。 まず、そこから始めましょう。

ヒント

それがあなたにとって明確な場合は、次のセクションに進んでください。👇

あなたのコードには、すでに変数、辞書、リストなどがあります。 それらはすべて、すでに何らかの方法でデータを保存しています。 なぜ別のデータベースが必要なのでしょうか？

よく見ると、あなたのコードは静的で、一度実行すると時間とともにあまり変化しません。 もちろん、機能を追加するなど、コードを頻繁に変更しますが、Pythonがコードを実行し始めると、プログラムは開始時のままになります。 また、コードを変更しても、プログラムは再び実行したときにのみ変更されます。

また、変数で変更を加えた場合でも、プログラムが終了すると、メモリにあったすべてのデータは消えてしまいます。 🔥

ほとんどの場合、プログラムの目的は、プログラム外部のデータを使って何かをすることです。

• ファイルをある場所から別の場所に移動するだけの場合もあります。
• または、ターミナルでユーザーからデータを取り込み、異なる方法で表示することもできます。
• または、いくつかのデータを取り込み、何らかの方法で処理するWeb APIなど。

ほとんどの場合、データはプログラムの外部から来るか、プログラムの外部で終了します（たとえば、画面、ファイルなどに表示される）。

多くの場合、プログラムがデータを作成して保存し、読み取り、更新、削除などをできるようにする必要があります。

コードからファイルを読み書きすることで、これらすべてを行うことができます。 そして、それは単純なケースでは機能します。 しかし、少し複雑なデータを使用するほとんどの複雑なシステムでは、その戦略はあまり効率的ではありません。 また、データの同期を維持し、安全に保存されていることを確認するなど、多くの注意点に対処する必要があります。

データベースは、これらの問題を解決し、データの処理プロセスをより効率的で、コードに依存しないように設計されています。 ✨

データベースとのやり取り方法

さまざまな種類のデータベースが多数あります。

単一ファイルデータベース

データベースは、heroes.dbという名前の単一のファイルであり、非常に効率的な方法でコードで管理できます。 例としてはSQLiteがあり、それについてはもう少し詳しく説明します。

サーバーデータベース

データベースは、サーバー上のアプリケーションとして実行され、最適化された形式で内部的に複数のファイルを処理するシステムにすることもできます。

Webサーバーのように、カスタムで非常に効率的な方法で通信します。 これが、最も一般的なデータベースのやり取りのタイプです。

この場合、コードはファイルを直接読み書きまたは変更するのではなく、このサーバーアプリケーションと通信します。

データベースは別のサーバー/マシンに配置できます

または、データベースは同じサーバー/マシンに配置できます

これらのタイプのデータベースの最も重要な側面は、コードがデータを格納するファイルを直接読み取りまたは変更しないことです。

代わりに、コードはデータベースアプリケーションと通信し、そのデータベースアプリケーションが実際にデータファイルを読み書きおよび変更します。 これは、このデータベースアプリケーションが通常、コードよりもはるかに効率的であるためです。

このように機能するデータベースの例としては、PostgreSQL、MySQL、またはMongoDBなどがあります。

分散サーバー

場合によっては、データベースは、異なるマシンで実行され、互いに連携して通信することで、より効率的になり、より多くのデータを処理するサーバーアプリケーションのグループになることもあります。

この場合、コードは異なるマシンで実行されているこれらのサーバーアプリケーションの1つ以上と通信します。

サーバーアプリケーションとして機能するほとんどのデータベースは、何らかの形で複数のサーバーもサポートしています。

分散システムを持つことも追加の課題を生み出すため、最初は単一のサーバーアプリケーションまたは単一のファイルに基づいたアプリケーションを操作する可能性が高くなります。

SQLデータベース

データベースとのやり取りのさまざまな方法と、それらがファイルをどのように処理するかなどについてすでに説明しました。 これは、ほとんどまたはすべてのデータベースに当てはまります。

しかし、データベースを分類する別の方法があり、それは非常に重要です。 ご想像のとおり、多くのタイプのデータベースがあり、各グループに多くのデータベースがあります。 しかし一般的に、それらは「SQLデータベース」と「NoSQLデータベース」の2つの大きなグループに分けることができます。

「SQL」という名前の理由については少し後で説明しますが、まず、それが何であるかを見てみましょう。

SQLデータベースのためのSQLModel

SQLModelは、SQLデータベースを支援するためのツールです。

NoSQLデータベースではあまり役に立ちません。 それにもかかわらず、ここでそれらについて少し説明します。

SQLデータベースの発明

昔、一部の賢い人々は、データを保存する優れた方法は、それを異なるテーブルに入れることであることに気づきました。

そして、「テーブル」とは、単一のスプレッドシートのように、異なる列と行を持つグリッドのデータのことです。

各行は特定のアイテムまたはレコードを表します。 また、各列は、そのレコードの特定の属性またはフィールドを表します。

巨大なテーブルの例

ヒーローに関するデータをいくつか保存する必要があるとしましょう。

単一のテーブルでヒーローを保存する場合、次のようになる可能性があります

id	名前	秘密の名前	年齢	チーム	本部
1	デッドポンド	ダイブ・ウィルソン	null	Z-ファクター	シスターマーガレットのバー
2	スパイダーボーイ	ペドロ・パルケードール	null	プリベンターズ	シャープタワー
3	ラスティマン	トミー・シャープ	48	プリベンターズ	シャープタワー

これは、たとえば、単一のスプレッドシートを使用して、単一のテーブルで行わなければならない可能性が高いでしょう。

しかし、これにはいくつかの問題があります。 いくつか確認してみましょう。

単一テーブルの問題

「シャープタワー」の名前を「プリベンターズタワー」に変更することにしたと想像してください。

これで、それを2か所で更新する必要があります。

コードがその名前を1か所で更新し始めたときに、突然停電が発生してコンピューターの電源が切れたらどうなるでしょうか？

「プリベンターズタワー」と言っている場所と、「シャープタワー」と言っている場所があるという、一貫性のない情報になってしまう可能性があります

id	名前	秘密の名前	年齢	チーム	本部
1	デッドポンド	ダイブ・ウィルソン	null	Z-フォース	シスターマーガレットのバー
2	スパイダーボーイ	ペドロ・パルケードール	null	プリベンターズ	プリベンターズタワー ✅
3	ラスティマン	トミー・シャープ	48	プリベンターズ	シャープタワー 🚨

そして、チーム「Z-フォース」の一員である「麻雀」という新しいヒーローを追加する必要があると想像してください。

チームの名前を忘れて、「Y-フォース」などの無効なチーム名で「麻雀」を追加してしまう可能性があります。

id	名前	秘密の名前	年齢	チーム	本部
1	デッドポンド	ダイブ・ウィルソン	null	Z-フォース	シスターマーガレットのバー
2	スパイダーボーイ	ペドロ・パルケードール	null	プリベンターズ	プリベンターズタワー
3	ラスティマン	トミー・シャープ	48	プリベンターズ	シャープタワー
4	麻雀	ニーナ・サーガール	31	Y-フォース 🚨	シスターマーガレットのバー

もし1人のヒーローが2つのチームに所属していたらどうでしょう？単一の大きなテーブルにこれを簡単に入れる方法はありません。

複数のテーブル

しかし、これらの問題や他の問題は、データを複数のテーブルに持つことでより良く解決できます。

そのため、すべてのデータを含む単一のテーブルを持つ代わりに、ヒーロー用のテーブルとチーム用のテーブルを個別に持ち、それらを相互に接続する方法を持つことができます。

チームのテーブルは次のようになります。

id	名前	本部
1	プリベンターズ	シャープタワー
2	Z-フォース	シスターマーガレットのバー

次に、ヒーローのテーブルはほぼ同じようになります。しかし、2つのテーブルを接続する方法が必要だと述べたことを覚えていますか？

ヒーローのテーブルには、team_idという別の列が追加されます。この列は、各行（各ヒーロー）から、そのヒーローが所属するチームへの関係を示します。

id	名前	秘密の名前	年齢	team_id ✨
1	デッドポンド	ダイブ・ウィルソン	null	2 ✨
2	スパイダーボーイ	ペドロ・パルケードール	null	1 ✨
3	ラスティマン	トミー・シャープ	48	1 ✨

識別 - プライマリキー

上記の例では、各行にidがあります。各IDはテーブルごとに一意であり、その特定の行を識別します。

これらのSQLデータベースでは、テーブル内の各行を識別する一意の方法が必要です。一意である列の組み合わせである可能性もありますが、通常は単一の列です。これはテーブルの「プライマリキー」と呼ばれます。

プライマリキーは、多くの場合、単一の列であり、通常はデータベースによって自動的に生成される整数であり、多くの場合、列は単純にidと呼ばれます。

このプライマリキー、この場合は列idは、テーブルごとに一意である必要があります。ただし、2つの異なるテーブルが同じIDを持つ可能性があります。たとえば、上記では、両方のテーブルが2つの異なる行にID 2を持っています。1つは1つのテーブルの「Z-Force」、もう1つは別のテーブルの「スパイダーボーイ」ですが、テーブルごとに1つだけ存在する限り、それでも問題ありません。

リレーションシップ - 外部キー

テーブル内の各行には、単一のプライマリキー（この例では単一の列id）があります。

たとえば、チームのテーブルには、チームPreventersにID 1、チームZ-ForceにID 2があります。

これらのプライマリキーのIDは、チームのテーブルの各行を一意に識別できるため、ヒーローのテーブルに移動して、チームのテーブル内のこれらのIDを参照することができます。

そのため、ヒーローのテーブルでは、team_id列を使用して、チームの*外部*テーブルへの関係を定義します。ヒーローのテーブルのteam_id列の各値は、チームのテーブルの1行のid列と同じ値になります。

ヒーローのテーブルには、idであるプライマリキーがあります。しかし、外部テーブルのキーを参照する別の列team_idもあります。これにも専門用語があり、team_idは「外部キー」です。

関係とリレーショナルデータベース

これらのテーブルのそれぞれに対する技術的および学術的な用語は「リレーション」です。

これらのデータベースについて話すとき、その用語をよく耳にするかもしれません。

これらのテーブルのそれぞれが実際には相互に「関連」しているにもかかわらず、英語で何かと関係があるという意味で使用する意味とは異なります。

専門用語のリレーションは、これらの各テーブルを指すだけです。

そして、この専門用語のため、これらのSQLデータベースはリレーショナルデータベースとも呼ばれます（実際、それが技術的に正しい用語です）。しかし、これは依然として複数のテーブルで作成されたこれらのデータベースを指すだけです。

SQL - 言語

複数のテーブルにデータを保存する方法というこれらのアイデアを開発した後、それらと対話するために使用できる言語も作成しました。

その言語はSQLと呼ばれ、その名前は構造化クエリ言語に由来します。

それにもかかわらず、この言語はデータを*クエリ*するためだけに使用されるのではありません。レコード/行を作成し、それらを更新し、削除するためにも使用されます。また、データベースを操作し、テーブルを作成するなどにも使用されます。

この言語は、複数のテーブルを処理するこれらのデータベースすべてでサポートされているため、SQLデータベースと呼ばれます。ただし、各データベースには、サポートするSQL言語に小さなバリエーション（方言）があります。

ヒーローを保持するテーブルがheroテーブルと呼ばれていると想像してみましょう。そこからすべてのデータを取得するSQLクエリの例は、次のようになります。

SELECT *
FROM hero;

そして、そのSQLクエリはテーブルを返します。

id	名前	秘密の名前	年齢	team_id
1	デッドポンド	ダイブ・ウィルソン	null	2
2	スパイダーボーイ	ペドロ・パルケードール	null	1
3	ラスティマン	トミー・シャープ	48	1

SQL用のSQLModel

SQLModelは、通常のPythonオブジェクトを使用してPythonコードを作成し、それをSQLデータベースに送信するSQLステートメントに変換するのに役立つライブラリです。

次に、データを受信し、コードで引き続き使用できるPythonオブジェクトに入れます。

SQL、SQLModel、それらの使用方法、およびそれらが次のセクションでどのように関連しているかについて詳しく説明します。

技術的な詳細

SQLModelはSQLAlchemyの上に構築されています。実際には、SQLAlchemyとPydanticを組み合わせて、上にいくつかのシュガーを追加したものです。

NoSQLデータベース

SQLデータベースは最も古く、最も一般的に使用されているタイプのデータベースですが、別の（非常に興味深い）カテゴリであるNoSQLデータベースのカテゴリがあります。

NoSQLデータベースは、キーバリューストア、ドキュメントストア、グラフデータベースなど、さまざまなサブタイプを幅広くカバーしています。

SQLModelはSQLデータベースでのみ役立ちます。そのため、ドキュメントの残りの部分ではそれについて説明します。