Mysql 上級 - データベース設計仕様書 (2)

8.ERモデル

ER モデルには、エンティティ、属性、関係という 3 つの要素があります。

エンティティはデータ オブジェクトとみなすことができ、多くの場合、実生活における実際の個人に対応します。ER モデルでは、長方形で表されます。エンティティは、強いエンティティと弱いエンティティの 2 つのカテゴリに分類されます。強いエンティティは他のエンティティに依存しないエンティティを指し、弱いエンティティは別のエンティティに強い依存性を持つエンティティを指します。

属性はエンティティの特性を指します。たとえば、スーパーマーケットの住所、連絡先、従業員数などです。ER モデルでは楕円で表されます。

関係とは、エンティティ間のつながりを指します。たとえば、スーパーマーケットが顧客に商品を販売するとき、それはスーパーマーケットと顧客の間のつながりです。ER モデルではダイヤモンドで表されます。

注: エンティティとプロパティは簡単に区別できません。システム全体の観点から物事を考えるべきであり、エンティティは独立して存在でき、属性は分割できないという原則があります。つまり、プロパティには他のプロパティを含めることはできません。

8.1 関係の種類

ER モデルの 3 つの要素のうち、関係は 1 対 1、1 対多、多対多の 3 つのタイプに分類できます。
1 対 1: エンティティ間の 1 対 1 の関係を指し、たとえば、個人と ID カード情報の関係は 1 対 1 の関係になります。ID カード情報は 1 人につき 1 つだけ持つことができ、1 つの ID カード情報は 1 人にのみ属します。

1 対多: 一方のエンティティがリレーションシップを通じてもう一方の複数のエンティティに対応できることを意味します。逆に、この関係を通じて、相手側の実体は唯一側の実体にのみ対応することができます。たとえば、新しいクラス テーブルを作成すると、各クラスには複数の生徒がいて、各生徒はクラスに対応し、クラスと生徒の間には 1 対多の関係が存在します。

多対多: 関係の両側のエンティティが、その関係を通じて相手方の複数のエンティティに対応できることを意味します。たとえば、購入モジュールでは、サプライヤーとスーパーマーケットの関係は多対多の関係になり、1 つのサプライヤーが複数のスーパーマーケットに商品を供給したり、1 つのスーパーマーケットが複数のサプライヤーから商品を購入したりすることができます。もう 1 つの例は、コース選択スケジュールです。多くの科目があり、各科目には多くの学生が選択し、各学生は複数の科目を選択できます。これは多対多の関係です。

8.2 モデリング分析

ER モデルは面倒に思えますが、プロジェクト全体をコントロールすることは非常に重要です。小規模なアプリケーションを開発しているだけであれば、おそらくいくつかのテーブルを設計するだけで十分ですが、ある程度の規模のアプリケーションを設計する場合は、プロジェクトの初期段階で完全な ER モデルを確立することが非常に重要です。アプリケーション プロジェクト開発の本質は、実際にはモデリングです。

私たちが設計したケースは電子商取引ビジネスですが、電子商取引ビジネスは大規模かつ複雑すぎるため、SKU (StockKeeping Unit) と SPU (Standard Product Unit) の意味に焦点を当てるなど、ビジネスを簡素化しました。 SKU を直接使用し、SPU の概念には言及しませんでした。この e コマース ビジネス デザインには、以下に示すように、合計 8 つのエンティティがあります。

• 住所エンティティ
• ユーザーエンティティ
• ショッピングカートエンティティ
• コメントエンティティ
• 商品エンティティ
• 製品分類エンティティ
• 注文エンティティ
• 注文詳細エンティティ

このうち、ユーザーと製品の分類は、他のエンティティに依存する必要がないため、強力なエンティティです。その他は弱いエンティティです。独立して存在できますが、すべてユーザー エンティティに依存するため、すべて弱いエンティティです。これらの要素を理解すると、
図に示すように、電子商取引ビジネスの ER モデルを作成できます。

この図では、追加されたアドレスとユーザーの関係は 1 対多の関係ですが、製品と製品の詳細は 1 対 1 の関係を示し、製品と注文は多対多の関係を示します。この ER モデルには、8 つのエンティティ間の 8 つの関係が含まれています。

(1) ユーザーは電子商取引プラットフォームに複数のアドレスを追加できます;
(2) ユーザーはショッピング カートを 1 つだけ持つことができます;
(3) ユーザーは複数の注文を作成できます;
(4) ユーザーは複数のコメントを投稿できます;
(5) 1 つのアイテム A製品には複数のコメントを含めることができます;
(6) 各製品カテゴリには複数の製品が含まれます;
(7) 注文には複数の製品を含めることができ、製品は複数の注文に含めることができます。
(8) 注文には異なる種類の商品が含まれる場合があるため、注文には複数の注文詳細が含まれます。

8.3 ERモデルの改良

この ER モデルを使用すると、電子商取引ビジネス全体を理解できます。先ほどの ER モデルは電子商取引ビジネスの枠組みを示していますが、そこに含まれるエンティティは、注文、住所、ユーザー、ショッピング カート、コメント、商品、商品カテゴリ、注文内容の 8 つのエンティティとそれらの間の関係のみであり、これらを表現することはできません。特定のテーブルとテーブル間の関係。取得する ER モデルをより完全なものにするために、属性を追加し、それらを楕円で表す必要があります。

したがって、この ER モデルの各部分をさらに設計する必要があります。つまり、電子商取引の特定のビジネス プロセスを洗練し、それらを統合して完全な ER モデルを形成する必要があります。これは、データベースの設計アイデアを明確にするのに役立ちます。

(1) 住所エンティティには、ユーザー番号、都道府県、市、地域、受信者、連絡先番号、およびデフォルトの住所かどうかが含まれます。
(2) ユーザーエンティティには、ユーザー番号、ユーザー名、ニックネーム、ユーザーパスワード、携帯電話番号、電子メール、アバター、ユーザーレベルが含まれます。
（３）ショッピングカートの実体には、ショッピングカート番号、ユーザー番号、商品番号、商品数量、画像ファイルＵＲＬが含まれる。
(4) 注文内容には、注文番号、荷受人、受取人の電話番号、合計金額、ユーザー番号、支払方法、配送先住所、注文時刻が含まれます。
（５）注文内容実体には、注文明細番号、注文番号、商品名、商品番号、商品数量が含まれる。
(6) 製品の実体には、製品番号、価格、製品名、分類番号、販売の有無、仕様、色が含まれます。
(7) コメント実体には、コメント ID、コメント内容、コメント時刻、ユーザー番号、製品番号が含まれます
(8) 製品分類実体には、カテゴリ番号、カテゴリ名、親カテゴリ番号が含まれます

8.4 ERモデル図をデータテーブルに変換

ER モデルを描画することで、ビジネス ロジックが明確になりました。次に、描画された ER モデルを特定のデータ テーブルに変換するという、非常に重要なステップに進みます。変換の原則は次のとおりです。

(1) エンティティは通常、データ テーブルに変換されます。
(2) 多対多のリレーションシップは、通常、データ テーブルに変換されます。
(3) 1 対 1 または 1 対多のリレーションシップは、通常、データ テーブルに変換されます。新しいデータ テーブルを設計するのではなく、テーブルの外側のキーを介して表現する変換
(4) 属性をテーブル フィールドに変換します。

実際、データベース ベースのアプリケーション プロジェクトは、最初に ER モデルを確立し、次にそれをデータ テーブルに変換することでデータベース設計作業を完了できます。ERモデルを作ることが目的ではなく、ビジネスロジックを整理して優れたデータベースを設計することが目的です。モデリングのためのモデリングではなく、ER モデルの作成プロセスを利用して考えを整理し、ER モデルの作成が意味のあるものになるようにすることをお勧めします。

9. データテーブルの設計原則

上記の内容に基づいて、データ テーブル設計の一般原則を「3 つ減らして 1 つ増やす」と要約します。

1. データテーブルの数は少ないほど良い
2. データテーブル内のフィールドが少ないほど良い
3. データ テーブル内の結合主キー フィールドの数は少ないほど良いです。
4. 使用する主キーと外部キーの数が多いほど、より良い結果が得られます。

注: この原則は絶対的なものではなく、場合によっては、データ処理の効率と引き換えにデータの冗長性を犠牲にする必要があります。

10. データベース オブジェクトの作成に関する提案

10.1 ライブラリについて

1. [必須] ライブラリ名は 32 文字以内で指定してください。使用できるのは英文字、数字、アンダースコアのみです。英文字で始めることをお勧めします。
2. [必須] 中国語と英語のライブラリ名はすべて小文字にする必要があり、異なる単語はアンダースコアで区切る必要があります。名前を見て意味を知る必要があります。
3. [必須] ライブラリ名の形式は、業務システム名_サブシステム名です。
4. 【必須】ライブラリ名にキーワード（種類、順序など）を使用することは禁止されています。
5. [必須] データベース作成時に文字セットを明示的に指定する必要があり、文字セットは utf8 または utf8mb4 のみです。データベースを作成する SQL の例: CREATE DATABASE crm_fund DEFAULT CHARACTER SET 'utf8';
6. [推奨事項] プログラムがデータベース アカウントに接続する場合は、最小アクセス許可の原則に従い、データベース アカウントは 1 つの DB でのみ使用し、データベースをまたがる接続は許可されません。原則として、プログラムで使用されるアカウントにはドロップ権限を付与することはできません。
7. [推奨] 一時ライブラリには接頭辞 tmp_ と接尾辞の日付が付けられ、バックアップ ライブラリの接頭辞は bak_ で接尾辞は日付になります。

10.2 テーブルと列について

1. [必須] テーブル名と列名は 32 文字以内で制御する必要があります。テーブル名には英文字、数字、アンダースコアのみを使用できます。英文字で始めることをお勧めします。

2. [必須] テーブル名と列名は小文字にする必要があり、異なる単語はアンダースコアで区切る必要があります。名前を見て意味を知る必要があります。

3. 【必須】テーブル名はモジュール名との関連性が高く、同一モジュール内のテーブル名は可能な限り統一したプレフィックスを使用する必要があります。例: crm_fund_item

4. [必須] テーブル作成時に文字セットを utf8 または utf8mb4 として明示的に指定する必要があります。

5. [必須] テーブル名、列名にキーワード（型、順序など）を使用することは禁止されています。

6. [必須] テーブルの作成時にテーブル ストレージ エンジンの種類を明示的に指定する必要があります。特別な要件がない場合、常に InnoDB になります。

7. 【必須】テーブル作成時にコメントは必須です。

8. [必須] フィールド名には、可能な限り実際の意味を表す英単語または略語を使用してください。例: 会社 ID。corporation_id は使用せず、corp_id のみを使用します。

9. [必須] ブール値型のフィールドの名前は is_description です。たとえば、メンバーが有効かどうかを示すメンバー テーブルのフィールドの名前は is_enabled です。

10. 【必須】画像やファイルなどの大きなバイナリデータをデータベースに保存することは禁止されています。通常、ファイルは非常に大きいため、短期間でデータ量が急激に増大します。データベースがデータベースを読み込むと、大きなデータが読み取られます。
    通常、多数のランダム IO 操作が実行され、ファイルは非常に大きくなり、 IO 操作には時間がかかります。通常、データベースにはファイル サーバーに保存され、ファイル アドレス情報のみが保存されます。

11. 【提案】テーブル作成時の主キーについて テーブルには主キーが必要です (1) 主キーはid、型はintまたはbigint、auto_incrementであることは必須であり、unsignedの使用を推奨します符号なしタイプ。(2) テーブルの各行の主題を識別するフィールドは主キーに設定せず、user_id、order_id などの他のフィールドに設定し、一意のキーインデックスを確立することをお勧めします。これを主キーとして設定し、主キーの値がランダムに挿入されると、innodb の内部ページ分割と大量のランダム I/O が発生し、パフォーマンスが低下するためです。

12. [推奨事項] トラブルシューティングを容易にするために、コア テーブル (ユーザー テーブルなど) には行データの作成時刻フィールド (create_time) と最終更新時刻フィールド (update_time) が必要です。

13. [推奨事項] テーブル内のすべてのフィールドは可能な限り NOT NULL 属性を持つべきであり、企業は必要に応じて DEFAULT 値を定義できます。NULL 値を使用すると、各行が追加の記憶領域を占有するなどの問題が発生するため、データ移行でエラーが発生しやすくなり、集計関数の計算結果に偏りが生じます。

14. [推奨事項] 同じデータを格納するすべての列名と列型は一貫している必要があります (通常は関連列として使用されます。クエリ中に関連列型が一致しない場合、データ型は暗黙的に自動的に変換され、インデックスが列が無効になり、クエリ効率が低下します)。

15. [推奨] 中間テーブル (または一時テーブル) は、中間結果セットを保持するために使用され、名前は tmp_ で始まります。バックアップ テーブルは、ソース テーブルのバックアップまたはスナップショットのキャプチャに使用され、その名前は bak_ で始まります。中間テーブルとバックアップテーブルは定期的にクリーンアップされます。

16. [デモ] より標準化されたテーブル作成ステートメント:

CREATE TABLE user_info (
	`id` INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主键',
	`user_id` BIGINT ( 11 ) NOT NULL COMMENT '用户id',
	`username` VARCHAR ( 45 ) NOT NULL COMMENT '真实姓名',
	`email` VARCHAR ( 30 ) NOT NULL COMMENT '用户邮箱',
	`nickname` VARCHAR ( 45 ) NOT NULL COMMENT '昵称',
	`birthday` date NOT NULL COMMENT '生日',
	`sex` TINYINT ( 4 ) DEFAULT '0' COMMENT '性别',
	`short_introduce` VARCHAR ( 150 ) DEFAULT NULL COMMENT '一句话介绍自己，最多50个汉字',
	`user_resume` VARCHAR ( 300 ) NOT NULL COMMENT '用户提交的简历存放地址',
	`user_register_ip` INT NOT NULL COMMENT '用户注册时的源ip',
	`create_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
	`update_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
	`user_review_status` TINYINT NOT NULL COMMENT '用户资料审核状态，1为通过，2为审核中，3为未
	通过，4为还未提交审核',
	PRIMARY KEY ( `id` ),
	UNIQUE KEY `uniq_user_id` ( `user_id` ),
	KEY `idx_username` ( `username` ),
KEY `idx_create_time_status` ( `create_time`, `user_review_status` ) 
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '网站用户基本信息'

17. [推奨] テーブルを作成するときは、視覚化ツールを使用できます。これにより、テーブルとフィールドに関連するすべての規則を確実に設定できるようになります。

10.3 インデックスについて

1. [必須] InnoDB テーブルの主キーは id int/bigint auto_increment である必要があり、主キー値の更新は禁止されています。
2. [必須] InnoDB および MyISAM ストレージ エンジン テーブルの場合、インデックス タイプは BTREE である必要があります。
3. [推奨事項] 主キーの名前は pk_ で始まり、一意のキーは uni_ または uk_ で始まり、通常のインデックスは idx_ で始まり、常に小文字形式を使用し、接尾辞としてフィールドの名前または略語を付けます。
4. [提案] 複数の単語で構成される列名については、最初の数単語の最初の文字を取り、最後の単語を追加して列名を形成します。例:
   サンプル テーブルのインデックス member_id: idx_sample_mid。
5. [推奨] 1 つのテーブルのインデックスの数は 6 を超えることはできません。
6. [提案] インデックスを作成するときは、結合インデックスを作成することを検討し、最も区別性の高いフィールドを最初に配置します。
7. 【推奨事項】 複数テーブルJOINのSQLでは、JOINの実行効率が最も高くなるように、駆動テーブルの接続列に必ずインデックスを持たせてください。
8. [推奨事項] テーブルを作成またはインデックスを追加するときは、テーブル内に重複したインデックスが存在しないことを確認してください。たとえば、key(a,b) がテーブルにすでに存在する場合、key(a) は冗長インデックスであるため、削除する必要があります。

10.4 SQLの記述

1. [必須] 終端の SELECT 文には特定のフィールド名を指定する必要があり、* の記述は禁止されています。
2. 【提案】 ターミナル上の挿入文では、INSERT INTO t1 VALUES(…)と書かず、特定のフィールド名を指定してください。
3. [推奨事項] 静的テーブルまたは小さなテーブル (100 行以内) を除き、DML ステートメントには WHERE 条件があり、インデックス検索を使用する必要があります。
4. [推奨] INSERT INTO...VALUES(XX),(XX),(XX)... ここでの XX の値は 5000 を超えてはいけません。値が高すぎるとすぐにオンラインになりますが、マスターとスレーブの同期に遅延が発生します。
5. [推奨事項] SELECT 文では UNION を使用せず、UNION ALL を使用することを推奨し、UNION 句の数は 5 に制限してください。
6. [推奨事項] オンライン環境では、複数テーブルの JOIN は 5 テーブルを超えないようにしてください。
7. [推奨] ORDER BYの使用を減らし、ソートなしで業務と通信するか、ソートをプログラムに組み込む。ORDER BY、GROUP BY、および DISTINCT ステートメントは比較的 CPU を集中的に使用するため、データベースの CPU リソースは非常に貴重です。
8. [推奨事項] ORDER BY、GROUP BY、DISTINCT を含むクエリの場合、WHERE 条件でフィルタリングされた結果セットを 1,000 行以内に収めてください。そうしないと、SQL が非常に遅くなります。
9. [推奨事項] 1 つのテーブルに対する複数の変更操作は 1 つにマージする必要があります。100 万行を超える大きなテーブルの変更テーブルは、DBA によってレビューされ、ビジネスのオフピーク時に実行される必要があります。複数の変更操作は、一緒に統合される。alter table はテーブル ロックを生成するため、この期間中はテーブルへのすべての書き込みがブロックされ、ビジネスに大きな影響を与える可能性があります。
10. 【推奨事項】 データをバッチ操作する場合は、トランザクションの処理間隔を制御し、必要なスリープを行う必要があります。
11. [推奨事項] トランザクションに含まれる SQL ステートメントは 5 つまでです。トランザクションが長すぎると、長時間のデータのロック、MySQL の内部キャッシュ、過度の接続消費などの問題が発生するためです。
12. [推奨事項] トランザクション内の更新ステートメントは、UPDATE... WHERE id=XX のように、可能な限り主キーまたは UNIQUE KEY に基づく必要があります。そうしないと、ギャップ ロックが生成され、ロック範囲が内部的に拡張されます。その結果、システムのパフォーマンスが低下し、デッドロックが発生します。