データベースの概要_07

SELECTの実行処理

#方式1:
SELECT ...,....,...
FROM ...,...,....
WHERE 多表的连接条件 AND 不包含组函数的过滤条件
GROUP BY ...,...
HAVING 包含组函数的过滤条件
ORDER BY ... ASC/DESC
LIMIT ...,...

#方式2:
SELECT ...,....,...
FROM ...
JOIN ... ON 多表的连接条件
JOIN ... ON ...
WHERE 不包含组函数的过滤条件 AND/OR 不包含组函数的过滤条件
GROUP BY ...,...
HAVING 包含组函数的过滤条件
ORDER BY ... ASC/DESC LIMIT ...,...

#其中:
1from:从哪些表中筛选
2on:关联多表查询时,去除笛卡尔积
3where:从表中筛选的条件
4group by:分组依据
5having:在统计结果中再次筛选
6order by:排序
7limit:分页

テーブルとテーブル間の関係

データベース設計手法:試行錯誤方式、正規化方式、CAD方式
データベース設計ツール:powerdesigner

実際の開発では、多くの場合、プロジェクトにはデータのさまざまな側面が関係します。商品やカテゴリーなど

製品番号 商品名 価格 分類名 学年
1 うわー、ははは 2.34 飲み物 3
2 茅台島 456.78 飲み物 3
3 Java の参入から放棄まで 12.45 2

データの冗長性と外部キー

データの冗長性: カテゴリ情報の重複

データの冗長性によって引き起こされる問題: スペースの無駄、例外の追加、例外の削除、例外の変更

解決策: 外部キー制約を導入する

製品表

製品番号 商品名 商品の価格 カテゴリ番号
1 うわー、ははは 2.34 1
2 茅台島 456.78 1
3 Java の参入から放棄まで 12.45 2

カテゴリ一覧

カテゴリ番号 分類名 学年
1 飲み物 3
2 2

新しいテーブルを導入し、外部キー制約を使用して値の合理性を確保することで、データの冗長性を削減します。

create table tb_catalog(
id bigint primary key auto_increment, -- 实体完整性
title varchar(32) not null
) comment '类别表';
create table tb_product(
id bigint primary key auto_increment comment '商品标号',
name varchar(32) not null,
price numeric(8,2) default 0,
-- 引入额外的列用于表示商品所属于的类别
catalog_id bigint, -- 外键列,允许为null
-- 外键表示该列的允许取的值必须在tb_catalog的id列中出现
foreign key(catalog_id) references tb_catalog(id)
) comment '商品表';
  • カテゴリ テーブルの ID は主キーであり、製品テーブルの列はカテゴリ テーブルの主キーを参照するため、一般的なカテゴリ テーブルはメイン テーブル、製品テーブルはスレーブ テーブル、製品テーブルのcatalog_idは外部テーブルと呼ばれます。
  • メインテーブルの主キーと副テーブルの外部キーによって記述される主キーと外部キーの関係は、1 対多の関係を表します。
    • カテゴリには複数の商品が含まれています
    • 製品は 1 つのカテゴリにのみ属することができます
  • Innodb は MySQL の外部キーとトランザクションをサポートしますが、MyISAM は外部キーとトランザクションをサポートしません
  • 具体的な開発では、パフォーマンスを向上させるために外部キー制約を意図的に削除し、データの合理性をコードで制御します。

外部キーの特徴

  • スレーブ テーブルの外部キーの値は、マスター テーブルの対応する主キー値への参照です。
  • 副テーブルの外部キーのデータ型は、主テーブルの主キーのデータ型と一致している必要があります。

基本的な文法

外部キーを導入する目的は、データの参照整合性を確保することです。
外部キーの作成構文 1:

create table tb_product(
id bigint primary key auto_increment comment '商品标号',
-- 引入额外的列用于表示商品所属于的类别
catalog_id bigint, -- 外键列,允许为null
-- 外键表示该列的允许取的值必须在tb_catalog的id列中出现
foreign key(catalog_id) references tb_catalog(id)
) comment '商品表';

外部キーを作成する 構文 2:

create table tb_product(
id bigint primary key auto_increment comment '商品标号',
catalog_id bigint -- 外键列,允许为null。是否允许为空取决于业务规则
)
-- alter table 从表名称 add [constraint fk_catalog外键约束名称] foreign key(从表中的外
键列名) references 主表名称(主表中的主键列名称)
alter table tb_product add constraint fk_catalog foreign key(catalog_id)
references tb_catalog(id);

外部キー制約を削除する構文:

-- alter table 从表名称 drop foreign key 外键约束名称;
alter table tb_product drop foreign key fk_catalog;

SELECT クエリの 2 つの順序を覚えておく必要があります。

1. キーワードの順序を逆にすることはできません。SELECT ... FROM ... WHERE ... GROUP BY ... HAVING ...ORDER BY ... LIMIT...
2. SELECT ステートメントの実行順序:

SELECT DISTINCT player_id, player_name, count(*) as num # 顺序 5
FROM player JOIN team ON player.team_id = team.team_id # 顺序 1
WHERE height > 1.80 # 顺序 2
GROUP BY player.team_id # 顺序 3
HAVING num > 2 # 顺序 4
ORDER BY num DESC # 顺序 6
LIMIT 2 # 顺序 7

SQLの実行原理

SELECT は最初に FROM ステップを実行します。この段階で、複数のテーブルの結合クエリの場合は、次の手順を実行します。

  1. まず、CROSS JOINによりデカルト積を取得する。これは、仮想テーブルvt(仮想テーブル)1-1を取得することと同等である。
  2. ON でフィルターし、仮想テーブル vt1-1 に基づいてフィルターして、仮想テーブル vt1-2 を取得します。
  3. 外側の行を追加します。左結合、右結合、または完全結合を使用する場合、外部行が含まれます。つまり、仮想テーブル vt1-2 に基づいて外部行を追加して、仮想テーブル vt1-3 を取得します。

もちろん、3 つ以上のテーブルを操作している場合は、すべてのテーブルが処理されるまで上記の手順が繰り返されます。このプロセスにより生データが得られます。

次に、3 番目と 4 番目のステップ、つまり GROUP ステージと HAVING ステージに入ります。この段階では、実際に仮想テーブルvt2に基づいてグループ化およびグループ化フィルタリングが行われ、中間仮想テーブルvt3、vt4が得られる。

条件付きフィルタリング部分が完了したら、テーブルから抽出したフィールドをフィルタリングできます。つまり、SELECT ステージと DISTINCT ステージに入ることができます。

  • まず、SELECT ステージで必要なフィールドが抽出され、次に DISTINCT ステージで重複行がフィルタリングされて除外され、中間仮想テーブル vt5-1 と vt5-2 がそれぞれ取得されます。

目的のフィールド データを抽出した後、指定されたフィールドに従って並べ替えることができます (ORDER BY ステージ)。仮想テーブル vt6 を取得します。

最後に、vt6 に基づいて、指定された行のレコードが取り出され、つまり LIMIT ステージが実行され、仮想テーブル vt7 に対応する最終結果が得られます。

もちろん、SELECT ステートメントを作成するときに、すべてのキーワードが存在するわけではないため、対応するステージは省略されます。

同時に、SQL は英語に似た構造化クエリ言語であるため、SELECT ステートメントを記述する際には、対応するキーワードの順序にも注意する必要があり、いわゆる基本的な動作原理は実行順序です。

標準形NF

リレーショナル データベースを設計するときは、さまざまな仕様要件に従って、合理的なリレーショナル データベースを設計します。これらのさまざまな仕様要件は異なるパラダイムと呼ばれ、さまざまなパラダイムには準標準が存在します。パラダイムが高くなるほど、データベースの冗長性は小さくなります。

現在、リレーショナル データベースには 5+1 正規形があります。第 1 正規形 (1NF)、第 2 正規形 (2NF)、第 3 正規形 (3NF)、バス-コッド正規形 (BCNF)、第 4 正規形 (4NF)、および第 5 正規形です。正規形パラダイム (5NF、完全パラダイムとも呼ばれます)。最小要件を満たす正規形は、第 1 正規形 (1NF) です。第 1 正規形に基づいて、さらに規範的な要件を満たすものを第 2 正規形 (2NF) と呼び、残りの正規形は類推によって推定できます。必要な正規形を満たしていない場合は、正規形の要件を満たしていない部分を表に分割します。一般に、データベースは第 3 正規形 (3NF) を満たすだけで済みます。

データベース設計の概念

  • 実体:現実世界において客観的に存在し、区別できるもの。たとえば、「学生」、「本」、「コース」などです。ここで強調しておきたいのは、ここでいう「もの」とは、具体的な「もの」だけではなく、仮想的な「もの」であることもあり、「教師と学校の関係」と言ったほうがよいでしょう。
  • 属性:教科書では「物体のある特徴」と説明されているので、例えば「性別」は「人」の属性であるなど、そもそも属性が論理的な概念であることがわかります。リレーショナル データベースでは、属性も物理的な概念であり、属性は「テーブルの列」とみなすことができます。
  • タプル: テーブル内の行はタプルです。
  • コンポーネント: タプルの属性値。リレーショナル データベースでは、これは操作アトムです。つまり、リレーショナル データベースが何らかの操作を実行するとき、属性は「分離不可能」です。それ以外の場合、それはリレーショナル データベースではありません。
  • コード: タプルの特定の属性 (または属性グループ) をテーブル内で一意に決定できます。そのようなコードが複数ある場合は、
  • コード選択は、候補コードの中からボスとなるコードを1つ選択し、それをメインコードと呼びます。
  • 完全なコード: コードにすべての属性が含まれている場合、このコードは完全なコードです。
  • メイン属性: 属性が候補コードに出現する限り、この属性がメイン属性になります。
  • 非メイン属性: 上記とは逆に、どの候補コードにも出現していない場合、この属性は非メイン属性です。
  • 外部キー: 属性 (または属性グループ)。キーではありませんが、別のテーブルのキーであり、外部キーです。
  • 候補キー: 関係内の属性または属性グループの値によってタプルを一意に識別でき、その適切なサブセットが識別できなくなった場合、その属性グループは (スーパー コード) 候補キーと呼ばれます。

主キーの定義

主キーは、自然主キーと代理主キーの 2 つのカテゴリに分類できます。通常は、サロゲート主キーを使用することをお勧めします。

  • テーブル内のすべての列の組み合わせを主キー (候補キー) として使用します。
  • 一部の列を削除して、データ行を一意に識別できるかどうかを確認します。
  • 最後に見つかったすべての候補キーの適切なサブセットが主キーです

ベスト プラクティス: ビジネスに関係のないフィールドをテーブルの主キーとして追加できます。id bigint primary keyauto_increment

NF1

所有列不可分,字段满足原子性

学生、学生 (番号、クラス番号、名前、親戚) を定義します。この相対列は割り切れるため、残りの列が NF1 を満たすように相対列が別のテーブルに分割され、最終的な構造が学生 (番号、クラス番号、親戚) として選択されます。クラス番号、名前)、生徒の親族(名前、続柄、アウターコード)

NF2

消除对主键的部分依赖

学生、学生 (番号、クラス番号、名前、寮の建物番号) を定義します。主キーは複合主キー (番号、クラス番号) です。ここでは、クラス番号が決定されると、それが属する学部がわかることがわかります。が決まり、所属を確認 寮の建物番号 そうですね。寮の建物番号は、主キー全体ではなく、主キーの一部に依存します。問題の解き方は、表の生徒数(番号、クラス番号、名前)、学生宿舎(クラス番号、寮棟番号)を分けることです。

NF3

消除对主键的传递依赖

学生、学生(学生番号pk、学科、寮棟番号)を定義、主キーは学生番号なので当然NF2を満たすが、学科が決まれば寮棟番号も決まるので寮棟番号は依存する学生証ではなく学部で。これは推移的な依存関係です: 寮の建物番号 –> 学部 –> 学生番号 pk。サブテーブル

パラダイムとアンチパラダイム

パラダイムを適用するとデータの冗長性を減らすことができますが、パラダイム レベルが高くなるほど、より多くのテーブルが作成され、クエリ効率が低下します。したがって、特定の開発では、パラダイムの要件を軽減し、合理的な冗長データを使用してクエリ効率を向上させるためによく使用されます。

クエリ効率を考慮するため、通常は NF3 にのみ到達し、クエリ効率を向上させるために意図的にパラダイム要件をさらに低くすることもあります [アンチパラダイム]

典型的なケース: JD.com や Taobao などの電子商取引 Web サイト

製品(製品番号(pk)、製品カテゴリ) –> 製品(製品番号(pk)、カテゴリ番号)、カテゴリ(カテゴリ対象番号、カテゴリ名)

商品数が非常に多く、カテゴリーは10 10 10の3段階に分かれています。

応用:商品(番号、第1レベル分類名、第2レベル分類名、第3レベル分類名)

テーブルとテーブル間の関係

テーブルとテーブル [エンティティ] の間には 3 種類の関係があります。

  • 1 対 1 1:1、たとえば、1 人は 1 つの ID カードのみを持つことができ、1 つの ID カードは 1 人の個人にのみ属することができます。
  • 1 対多または多対 1 1:m または m:1。たとえば、カテゴリには複数の商品を含めることができ、商品は 1 つのカテゴリにのみ属することができます。
  • 多対多の n:m など、1 人の学生が複数のコースを受講でき、1 つのコースを複数の学生が受講することができます。

テーブル[エンティティ]間の関係を調べる方法: 中立

一対一

1 対 1 を実装するには、共有主キーまたは一意の外部キーの 2 つの方法があります。例: 個人とID

共有主キー

  • tb_person スレーブ テーブルでは、id 列が現在のテーブルの主キーと外部キーの両方になります。
create table tb_card(
id bigint primary key auto_increment comment '不是身份证号码,仅仅是一个非业务含义
的编号',
name varchar(32) not null,
birth date
);
create table tb_person(
id bigint primary key, -- 这里的主键值来源于tb_card的主键值,主键约束非空唯一
-- 人的编号来源于card表种的编号值,而且on delete cascade级联删除,表示删除对应的身份证
信息时会自动删除对应的用户信息
foreign key(id) references tb_card(id) on delete cascade,
salary decimal(8,2)
);

一意の外部キー

create table tb_card(
id bigint primary key auto_increment,
name varchar(32) not null
);
create table tb_person(
id bigint primary key auto_increment,
salary decimal(8,2),
card_id bigint not null unique,-- not null非空约束; unique唯一性约束,表示该列值不
允许重复
foreign key(card_id) references tb_card(id) on delete cascade
);

特別な実装

たとえば、一夫一婦制、全員の情報を 1 つのテーブルに保存する方法

番号 (PK) 名前 性別 妻番号 夫番号
1 チャオ・シャオパン 真実 2 ヌル
2 王暁華 間違い ヌル 1
3 チャン・イー 真実 ヌル ヌル

別の実装

シリアルナンバー 名前 性別 配偶者番号
1 チャオ・シャオパン 真実 2
2 王暁華 間違い 1
3 チャン・イー 真実 ヌル

データテーブル定義

create table tb_person(
id bigint primary key auto_increment,
name varchar(10) not null,
sex boolean default 1,
pei_id bigint unique,
foreign key(pei_id) references tb_person(id)
);

1対多

実際、デフォルトでは、fk 外部キーは主キー pk を参照しており、これは 1 対多の関連付けです。たとえば、人は複数の車を所有しており、車は 1 人の人にのみ属することができます。

create table tb_person(
id bigint primary key,
name varchar(20)
);
create table tb_car(
id bigint primary key,
title varchar(32) not null,
person_id bigint not null,
foreign key(person_id) references tb_person(id)
);

多対多

実際、多対多の関係はリレーショナル データベースで直接表現できないため、中間テーブルを導入する必要があります。例: 学生の選択科目

create table tb_student(
id bigint primary key auto_increment comment '学生编号',
name varchar(10) not null comment '学生姓名'
) comment '学生表';
create table tb_course(
id bigint primary key auto_increment comment '课程编号',
title varchar(32) not null comment '课程名称'
) comment '课程表';
create table tb_choice(
sid bigint comment '学生编号',
cid bigint comment '课程编号',
-- 不允许重复选修
primary key(sid,cid),
-- 不允许出现的学生信息错误
foreign key(sid) references tb_student(id) on delete cascade,
-- 不允许选修不存在的课程
foreign key(cid) references tb_course(id) on delete cascade
) comment '选课表,用于表示多对多关系';

パワーデザイナー

Power Designer は、経営情報システムの分析と設計に便利に使用できる Sybase Corporation の CASE ツール セットであり、データベース モデル設計のほぼすべてのプロセスが含まれています。

CASE (コンピュータ支援 (または支援) ソフトウェア エンジニアリング)。もともとは、経営情報システムの開発を支援するために使用される、コンピュータ支援のさまざまなソフトウェアやツールで構成される大規模な総合的なソフトウェア開発環境を指しますが、さまざまなツールやソフトウェア技術の出現、開発、改善、継続的な統合により、徐々に単純な開発ツール環境から、比較的独立した方法論に変換されます。

アドバンテージ

  • テーブル構造を作成するために create table やその他のステートメントを使用する必要はなく、データベース ステートメントを自動的に生成できます。
  • データベース設計者は、データをモデル化する方法のみに焦点を当てます。

基本的な設計プロセス

1. 概念的なデータモデルを作成する

  • ステレオタイプ アプリケーション テンプレート
  • 必須の力を空にすることはできません
  • ドメイン ドメインは、最大値、最小値、および制約を定義する値の範囲として理解できます。ユーザー定義後のフィールドは、新しいエンティティの作成時にフィールド属性をすばやく定義するために使用できます。モデルドメインは最初に作成してから使用する必要があります

2. エンティティ間の接続を確立する

3. CDM のチェック: メニュー バーの [ツール] オプションを選択し、[モデルのチェック] を選択して、モデルをチェックするためのインターフェイスを開きます。

4. CDM を PDM に変換: メニュー バーの [ツール] オプションで、[物理データ モデルの生成] を選択します。

5. PDM による SQL ファイルの生成: PDM ページのメニュー バーにある [データベース] で [データベースの生成] をクリックします。

おすすめ

転載: blog.csdn.net/qq_39756007/article/details/127214949