@
この号では主に、MySQL データベース設計における 3 つの主要なパラダイムと ER 図を紹介し、その後の独自のライブラリとそのライブラリ内のテーブル間の関係の設計への道を開きます。
データベースのパラダイムは一連のルールです。リレーショナル データベースを設計するときは、さまざまな規範要件に従って、合理的なリレーショナル データベースを設計します。これらの異なる規範要件は、異なるパラダイムと呼ばれます。
リレーショナル データベースには、第 1 正規形 (1NF)、第 2 正規形 (2NF)、第 3 正規形 (3NF)、バスコード正規形 (BCNF)、第 4 正規形 (4NF)、および第 5 正規形 (5NF、完全正規形とも呼ばれます) の 6 つのパラダイムがあります。パラダイムが高くなるほど、データベースの冗長性は小さくなります。ただし、一般に、より高いパラダイムではデータの関係に対する制約がより良くなりますが、データベース IO がより忙しくなる可能性があると考えられています。したがって、実際のアプリケーションでは、データベース設計は通常、次の条件を満たすだけで済みます。第 3 正規形それでおしまい。したがって、ここでも主に最初の 3 つのパラダイムを紹介します。
(1) 第一正規形
データベーステーブル各列は分割不可能なアトミック データ項目ですリレーショナル データベースの設計では、第一正規形を満たすことがリレーショナル モデルの基本要件です。したがって、第 1 正規形を満たさないデータベースはリレーショナル データベースとは言えません。
図に示す例では、学生情報と学校情報を記録する必要がある学生テーブルを定義しています。学校は依然として分割され続ける可能性があるため、最初のパラダイムを満たしていません。次の例は、第 1 正規形に準拠する例ですが、このように設計されたテーブルはあまり合理的ではありません。
しかし、上記の例からわかるのは、リレーショナル データベースでは、各列は基本的なデータ型で表すことができ、当然のことながら第 1 正規形を満たします。。
(2) 第二のパラダイム
第一正規形を満たすことに基づいて、非キーフィールドどれにも候補キーの部分的な関数依存性テーブルに存在し、定義されている複合主キーこの場合、それは第 2 正規形と一致します。
候補キーは、データ行を一意に識別できる列または列の組み合わせです。 1 つ以上の候補キーをテーブルの主キーとして選択できます。
以下の例は、学生とコースの成績の表です。
このテーブルでは、学生番号 + コース名を使用して複合主キーを定義し、特定のコースでの学生の成績を一意に識別します。学生は学生番号によって識別され、学生に関するその他の情報はコース名には依存しません。同様に、学業単位はコース名のみに依存し、学生には依存しません。複合主キーを使用するテーブルの場合、データ行の一部の列が複合主キーの 1 つまたは複数の列にのみ関連している場合、
したがって、部分関数依存性があり、第 2 正規形を満たさないと言われます。。上の表は第 2 正規形に準拠していません。
上記の表を第 2 正規形に準拠させるには、次の 3 つの表に分割する必要があります。
上記の例を通じて、第 2 正規形が部分的な関数依存性を強調していることがわかりました。テーブル内の主キーに列が 1 つしかない場合、第 2 正規形は当然満たされます。
ここで追加します上の表が第 2 正規形に準拠していない場合に発生する可能性のある問題。
- データの冗長性。学生の名前、年齢、性別、コース単位がレコードの各行で繰り返されるため、大量のデータが冗長になります。
- 更新例外。 MySQL クレジットを調整する場合は、テーブル内のすべての MySQL レコードを更新する必要があります。実行が中断されると、一部のレコードは正常に更新され、一部のデータは更新に失敗し、データの不整合が発生します。
- 例外の挿入。オリジナルのテーブルの設計では、成績は各コースと生徒に対応関係があります。つまり、選択科目試験を受験し、成績を取得した場合にのみ記録が作成されます。新しいコースがあり、誰も試験を受けて結果を得ていない場合、そのデータはデータベースに存在しません。
- 例外の削除。卒業生の試験データをすべて削除すると、その際に履修科目および単位情報も削除されるため、特定の履修科目および単位情報が一定期間データベースに登録されなくなる場合があります。
(3) 第三のパラダイム
第 2 正規形を満たすことに基づいて、どの候補キーにも非キー フィールドは存在しません。推移的な依存関係どちらも 3 番目のパラダイムに準拠しています。
以下は、第 3 正規形に準拠していない学生とその大学に関する表の例です。
このテーブル構造では、学生の学籍番号、名前、年齢、性別、および主キー ID が強く関連していることがわかります。大学の電話番号、大学の住所、および大学には強い関連性があります。テーブルの中で、強く関連する 2 つの関係、さらに、これら 2 つの強い相関関係の間には伝達現象が存在します。つまり、学生の記録は学生 d を通じて見つけることができます。学生の記録には大学の名前が含まれており、各大学には独自の電話番号と住所があります。この種の推移的依存したがって、現在のテーブルは第 3 正規形を満たしていません。
上の表を第 3 正規形に準拠させるには、推移的な依存関係を持つ 2 つの強く関連する関係を分離する必要があります。これを分離して college テーブルを定義し、student テーブルを college テーブルに関連付けます。
ER 図とも呼ばれるエンティティ関係図は、エンティティ関係モデルおよびエンティティ関係モデルとも呼ばれ、データ モデルを記述するために使用される概念図であり、主にデータベース設計段階で使用されます。
(1) データベースの設計プロセス
ER 図を説明する前に、まずデータベースの基本設計プロセスを理解する必要があります。データベースの基本設計プロセスは、次の 3 つのプロセスに分けられます。
- 実際のビジネスからの抽象概念クラス
概念クラスは現実世界から抽象化されており、要件分析段階で決定する必要があります。
クラスはデータベース設計のエンティティに対応し、エンティティはデータベースのテーブルに対応します。
クラスの属性はエンティティの属性に対応し、エンティティの属性はテーブルの列に対応します。 - エンティティ間の関係を決定し、ER 図面を作成して、プロジェクト参加者間の理解とコミュニケーションを促進します。
- SQL ステートメントのコーディングを完了し、ER 図に従ってデータベースを作成します
(2) ER図の基本構成要素
ER 図には、次の 3 つの基本コンポーネントが含まれています。
- エンティティ: ユーザー、学生、クラスなどの長方形のボックスで表されるデータ オブジェクト。
- 属性: 生徒の名前、年齢など、楕円形または角丸長方形で表されるエンティティの特性。
- 関係: エンティティ間の接続。ひし形のボックスで表され、関係のタイプを示し、直線を使用して関連するエンティティと関係を接続します。
(3) 関係の種類
次に、例を使用して ER 図の関係タイプを紹介し、具体的な ER 図を示します。
1. 1対1の関係(1:1)
ユーザーとアカウント
2. 1 対多の関係 (1 : N)
生徒とクラス
3. 多対多の関係 (M : N)
学生とコース
多対多のリレーションシップの場合、中間テーブルを使用して記録できます。たとえば、学生が特定のコースの試験を受けて、対応するスコアを獲得した場合、それは次のように ER 図で表されます。
(4) 設計テーブル
ER図を使用すると、これらに基づいてテーブルを設計できるようになります。
1. ユーザーとアカウント間の 1 対 1 の関係
# 在⽤⼾实体中添加对账⼾实体的关联
drop table if exists users;
create table users (
id bigint primary key auto_increment,
name varchar(20) not null,
nickname varchar(20),
phone_num varchar(11),
email varchar(50),
gender tinyint(1),
account_id bigint
);
drop table if exists account;
create table account (
id bigint primary key auto_increment,
username varchar(20) not null,
password varchar(32) not null
);
# 在账⼾实体中添加对⽤⼾实体的关联
drop table if exists users;
create table users (
id bigint primary key auto_increment,
name varchar(20) not null,
nickname varchar(20),
phone_num varchar(11),
email varchar(50),
gender tinyint(1)
);
drop table if exists account;
create table account (
id bigint primary key auto_increment,
username varchar(20) not null,
password varchar(32) not null,
users_id bigint
);
2. 学生とクラスの間の 1 対多の関係
# 班级表
drop table if exists class;
create table class (
id bigint primary key auto_increment,
name varchar(20)
);
# 学⽣表
drop table if exists student;
create table student (
id bigint primary key auto_increment,
name varchar(20) not null,
sno varchar(10) not null,
age int default 18,
gender tinyint(1),
enroll_date date,
class_id bigint
)
3. 学生、コース、成績間の多対多の関係
# 学⽣表
drop table if exists student;
create table student (
id bigint primary key auto_increment,
name varchar(20) not null,
sno varchar(10) not null,
age int default 18,
gender tinyint(1),
enroll_date date,
class_id bigint,
foreign key (class_id) references class(id)
);
# 课程表
drop table if exists course;
create table course (
id bigint primary key auto_increment,
name varchar(20)
);
# 分数表
drop table if exists score;
create table score (
id bigint primary key auto_increment,
score float,
student_id bigint,
course_id bigint,
foreign key (student_id) references student(id),
foreign key (course_id) references course(id)
);
テーブルが作成され、正しい主キーと外部キーの関係が設定されたら、ビジュアル クライアント ツールのリバース エンジニアリングを通じてデータベース モデル (EE-R 図) を生成できます。ここでは詳しく紹介しません。
以上が、MySQL 設計の 3 つの主要なパラダイムと ER 図に関する本号の全内容です。私のコンテンツが気に入ったら、いいね、収集、フォローして私をサポートしてください。コメントエリアで議論したりコミュニケーションをとったり、私の欠点を指摘したりすることは歓迎です。皆さん、ありがとうございました。
