レッスン

2.1. コンセプチュアルデザイン データベースの設計は、次の 3 つの段階で実行されます。 コンセプチュアルデザイン; 論理的なデザイン。 物理的なデザイン。 概念設計フェーズの目的は、対象領域に関するユーザーのアイデアに基づいて概念データ モデルを作成することです。これを達成するために、一連の一連の手順が実行されます。エンティティ (概念的) スキーマの例: 1. エンティティとそのドキュメントの定義。エンティティを識別するために、他から独立して存在するオブジェクトが定義

3.1 データベースの正規化 正規形は、冗長性の観点から特徴づけるリレーショナル データ モデル内のリレーションのプロパティであり、データのサンプリングまたは変更の論理的に誤った結果を引き起こす可能性があります。正規形は、リレーション (データベース内のテーブル) が満たさなければならない一連の要件として定義されます。 データベースの関係を通常の形式に準拠した形式に変換するプロセスは、正規化と呼ばれます。正規化は、データベースの構造を最小限の論理的冗長性を提供する形式にするこ

4.1 はじめに データベース テーブルを通常のテーブルに変換することで、データベース テーブル間の関係を分析できるようになります。関連する 2 つのテーブル間で相互作用する要素の数は、カーディナリティと呼ばれます。カーディナリティは、データをテーブルにどのように効率的に分割するかを制御するのに役立ちます。 理論的には、すべてのエンティティは相互の関係を維持できますが、実際には、エンティティ間には 3 種類の関係があります。 1対1 1 対多 多対多 4.2 1対1のコミュニ

5.1 はじめに インターネットには、リレーショナル データベースでキーをどのように選択して使用するかについての独断的な教訓が溢れています。場合によっては、論争がホリバーに発展することさえあります。自然キーを使用すべきか、それとも人工キーを使用すべきか? 整数または UUID を自動インクリメントしますか? 64 の記事を読み、5 冊の本のセクションをめくり、IRC と StackOverflow について大量の質問をした後、私 (元の記事の著者である Joe "begrif

6.1 はじめに それでは、理論から実践に移りましょう。 「理論的には、理論と実践の間に違いはありません。実際にはそうなのです。」 私たちは現実世界に住んでおり、すべてのソフトウェア製品は最終的には生きている人々のために作られています。そして、これらの生きている人々は、読み込みが遅いサイトや速度が遅いプログラムに非常に悩まされています。 また、データベース クエリに 1 秒以上かかる場合、これは容認できません。ユーザーは、ページや機能が非常に遅い製品を使用することはありません

7.1 DB側のキャッシュ MySQL はテーブルを操作するときに拡張性の高いアルゴリズムを使用するため、少量のメモリでも MySQL を実行できます。当然のことながら、パフォーマンスを向上させるには、より多くの RAM が必要になります。 現在の設定を表示するには、データベースに接続します

8.1 なぜ非正規化が必要なのでしょうか? 大きなテーブル間で最も計算量の多い操作は結合です。したがって、1 つのクエリで数百万の行で構成される複数のテーブルを「換気」する必要がある場合、DBMS はそのような処理に多くの時間を費やすことになります。 このとき、ユーザーはコーヒーを飲みに離れることができます。処理の対話性は実質的になくなり、バッチ処理の対話性に近づきます。さらに悪いことに、バッチ モードでは、ユーザーは前日の午前中にリクエストされたすべてのデータを受け取り、落

1.1 はじめに そして、トランザクションがどのように機能するかの理論という楽しい作業が始まります。異なるスレッドで同じデータを変更する場合に、システムの動作を維持するにはどうすればよいでしょうか? それとも、あるトランザクションを別のトランザクションで実行したいですか? 私たちはトランザクションの分離を研究することで、これらの質問に対する答えを探し始めます... トランザクション分離レベルは、 DBMS 内で論理的に並列トランザクションを実行した結果、不整合なデータがどの程

2.1 コミットされていない読み取り 「トランザクション分離レベル」とは、トランザクションの並列実行中に発生する上記の種類のデータの不整合のすべてまたは一部から DBMS の内部メカニズムによって提供される (つまり、特別なプログラミングを必要としない) 保護の程度を指します。SQL-92 標準では、次の 4 つの分離レベルのスケールが定義されています。 コミットされていない読み取り 読み取りがコミットされました 反復可能な読み取り シリアル化可能 最初のものが最も弱く、最後

3.1 ACIDの出現 ACID という略語は、 1983 年に Theo Haerder と Andreas Reuter による記事で初めて登場しました。文章を簡略化し、より説得力を持たせるために、この記事の一部を翻訳します（若干の縮小を加えて）。このスニペットでは、ある口座から別の口座に送金される銀行取引の例を使用しています。 $BEGIN_TRANSACTIONトランザクションの概念 (この例では、と の間のデータベースとのすべての対話が含まれます) では、すべての$

4.1 Brewera に関する一貫性 まず、Eric Brewer はデータベースの専門家ではなく、データベースの専門家であると主張したこともありません。彼は分散システムのコミュニティに属しており、CAP の「定理」が登場する彼の有名な講演は、カンファレンス「分散コンピューティングの原理」で行われました。(ちなみに、10 年後の 2010 年に、彼は再び同じ会議で招待講演を行いました。この講演では、特に、「 ) この領域には、データベースの分野で使用される用語の独自の解釈が

5.1 同時性の問題 少し遠い理論から始めましょう。 プログラマーが作成する情報システム (または単にアプリケーション) は、いくつかの典型的なブロックで構成されており、それぞれが必要な機能の一部を提供します。たとえば、キャッシュはリソースを大量に消費する操作の結果を記憶し、クライアントによるデータの読み取りを高速化するために使用されます。ストリーム処理ツールを使用すると、非同期処理のために他のコンポーネントにメッセージを送信できます。また、バッチ処理ツールは次の目的で使用さ