前のパーツ： 1-3、4-6、7-9、10-13
継続する。 カスケードデータの削除。
14.別の例：オンラインストアデータベース。
データベース作成の基本概念を理解し、簡単なリレーショナルデータベースを設計できるようになりました。 以下の例では、データベースを設計するときに発生するタスクをまとめています。
PS以下の非常に簡略化された形式の情報は、データベースを作成するときの思考プロセスをモデル化しています。
オンラインストアシステム。
使用されるデータのアイデアを得るために、オンラインストアが実行する必要のあるタスクの概要を見てみましょう。
- 製品展示
- 製品分類
- 顧客登録
- ショッピングカートにアイテムを追加する
- ショッピングカートの内容を表示する
- 訪問者による注文
- 等
本質と関係を定義します。
タスクのリストから、システムで重要な役割を持つエンティティを導出できます。 製品 、 カテゴリ 、 顧客 、 注文は、ほぼすべてのオンラインストアデータベースにあるエンティティです。 この例では、次のエンティティーのみを含むモデルを示します： customer 、 orderおよびproduct 。 エンティティを決定したら、それらの間の関係について考えることができます。
- 注文と製品の間には多対多の関係があります 。 各注文には1つ以上の製品が含まれており、各製品は0、1つ以上の注文に関連付けることができます。 3つのテーブルを使用して、多対多の関係が作成されます。 2つのテーブル-データソース（注文-注文と製品-商品）と1つ-接続（OrderProducts）。次の図を参照してください。 注文と製品の両方が、接続テーブルと1対多の関係にあることに注意してください。 一緒になって、注文と商品の間に多対多の関係を形成します。
- 顧客と注文には1対多の関係があります。 各顧客レコードは、注文（注文）の複数のレコードに関連付けることができ、逆も同様です。各注文レコード（特定の注文）は、1つの顧客レコードにのみ関連付けることができます。
この表は簡単な例です。 もちろん、「実際の」顧客テーブルには、より多くの情報（住所、都市など）が含まれています。
このモデルに関する注意事項。
注文表
注文テーブルの各レコード、各注文は一意の顧客レコードに関連付けられ、一意の顧客は外部キー -customer_idフィールドを使用します。
注文数。
たとえば、注文数のフィールド（order_quantity）を追加できるかどうか疑問に思っている場合、答えは「いいえ」です。 このデータは、既存のデータから取得できます 。 注文に含まれる製品の総数（order_quantity）は、OrderProductテーブルから取得できます。 注文内の商品の数量を検索するクエリは、SQLを使用して簡単に生成できます。
支払いの種類。
注文テーブルに追加できるフィールドは、payment_type（支払いタイプ）です。 この情報は特定の注文に固有のものであり、他のデータから取得することはできません（payment_typeフィールドは注文テーブルの外部キーになる-注文-支払いタイプを含む別のテーブルへのリンクがあることに注意してください）。
注文の合計金額。
注文テーブルに追加できる（また必要な場合がある）別のフィールドは、合計注文額のフィールドです。 しかし、既存のデータからこのデータを取得できると思うかもしれません。 注文のすべての商品のコストを合計できますか？ はい そしていや。 商品の価格は可変値です。 そのため、各商品のコストを合計して注文の合計コストを計算し、店舗所有者が注文内の商品の1つのコストを2倍にすると、すでに完了したすべての注文の合計コストも変更されます。 言い換えると、表示するときに注文の合計費用を計算し、商品の価格が変化する可能性がある場合、このまさに履歴の表示では、注文全体に対して支払った金額が変わるときに状況が発生する可能性があります。 そのため、注文時に合計費用を計算し、注文テーブルに保存する方がよいのはこのためです。
製品価格の履歴を保持します。
履歴といえば、各製品の価格履歴を保持する必要があるかもしれません。 この場合、注文日を確認し、表price_history（価格履歴）にリクエストを行い、注文日における商品のコストを取得できます。 この場合、注文の合計費用を注文テーブルに保存する必要はありません。 ほとんどのオンラインストアは注文商品の合計金額を保持しており、これらの商品の価格履歴は保持していないと思います。 しかし、あなたについて言えば、開発者はあなたにこれを行うかどうかを決定する責任があります。
商品のテーブル。
商品の表では、商品の価格はVATを除いて保存されます。 VATの価格は、プログラムコードまたはSQLクエリを使用して計算できます。 そのため、VATを含めて価格を保存しません。 この方法で商品の価値を保存することは、将来的に意味があるかもしれないことに注意する必要があります。 このモデルでは、商品の価格は単一のテーブルフィールドに保存されます。 製品の価格を変更すると、以前の値は失われます。 ただし、データベースから過去の販売レポートを受信できるようにするには、各製品の価格履歴を保持する必要があります。 製品が特定の年に値を2回変更した場合、特定の年にこの製品で獲得した金額を知るために価格履歴が必要です。 また、販売時に商品の価格を上げるVATが届かないため、商品の利益レポートでそれを考慮するのは無意味です。
15.結論とさらに読む。
リレーショナルデータベースは、大量の情報を効率的に保存するための優れたツールです。 このガイドでは、主にデータベースモデルの構築に焦点を当てました。 このモデルは任意のRDBMSを使用して実装でき、SQLへのクエリはSQLを使用して実行できます。
次はどこへ行きますか？
データベースを開発する場合は、 Mysqlワークベンチを必ずチェックしてください 。 これは、エンティティ関係図などを作成するための優れたユーティリティです。 私の仕事でMysql RDBMSを使用していない場合でも、ソフトウェア開発者としての仕事で広く使用しています。
このガイドを読んだ後のもう1つの論理的なステップは、構造化照会言語（SQL）に精通することです。 Mysqlワークベンチでデータベースをモデリングしたり、Sqlyogでデータベースを管理したりすることはすべて素晴らしいことですが、データベースの使用方法を本当に理解したい場合、SQLは成功しないスキルです。 W3Schoolsには、始めるための非常に優れたSQLチュートリアルがあります。