実験 4 データベースのセキュリティと整合性
一。実験の目的
1. データベースのセキュリティと整合性の理解を深める;
2. 承認とリサイクルを学ぶ;
4. データベース エンティティの整合性、参照整合性、およびユーザー定義の整合性制約の役割を理解し、体験する。
2.実験内容
構築された各テーブルとユーザーの権限を承認および再利用します. 操作が完了したら、承認されたユーザーが付与されたデータを操作する権利を本当に持っているかどうか、および権限取り消し操作後のユーザーが本当に権限を失うかどうかを確認します.データを操作します。
さまざまな整合性制約を定義し、さまざまなデータを入力して制約の効果を検証します
- SPJテーブルでユーザーaのクエリ権限を設定します。としてログインして、の権限を確認します。
実験手順:
(1) 最初にユーザーを作成します。パスワードは「password」です。
CREATE USER 'a' IDENTIFIED WITH mysql_native_password BY'password';
(2) 承認前に a の権限を確認します。
ログイン：
クエリ ステートメントを実行します。
選択する
spj から
データベースへのアクセスがないことが判明しました:
(3) 再認証:
グラントセレクト
オン spj
に;
(4) ログインして次の権限を確認します。
選択する
spj から
実験結果：
作成：
承認:
結果分析:
ユーザーを作成するときは、'a'@% を作成し、a@host を作成しないでください。そうしないと、承認できません。
- ユーザーbがSリストとPリストの変更権限を持つように設定し、 bがこの権限を他のユーザーcに付与できるようにします。bとcでそれぞれログインし、bとcの権限を確認します。
実験手順:
(1) パスワード「bpassword」でユーザー b を作成します。
'bpassword' によって mysql_native_password で識別されるユーザー 'b' を作成します。
(2) パスワード「cpassword」で c ユーザーを作成します。
'cpassword' によって mysql_native_password で識別されるユーザー 'c' を作成します。
(3) 承認 (クエリと変更のアクセス許可を付与します。変更のアクセス許可のみは許可されません):
グラントセレクト
ON
へ;
付与の更新
ON
へ
GRANT オプション付き。
グラントセレクト
オン p
へ;
付与の更新
オン p
へ
GRANT オプション付き。
(4) ユーザー b にログインし、権限を確認します。
(5) b にログインし、s のテーブル s5 の SNAME を「for the people」に、都市を「Beijing」に変更します。
UPDATE s
SET SNAME='for the people',CITY='北京'
WHERE sno='S1';
(6) p テーブルの p1 をネジに変更し、色を赤に変更します。
UPDATE p
SET PNAME='screw',COLOR='red'
WHERE pno='p1';
(7) b にログインし、認可権限を実行し、c に s テーブルと p テーブルに対するクエリと変更の権限を付与します。
グラントセレクト
ON
に c;
付与の更新
ON
へ
グラントセレクト
オン p
に c;
付与の更新
オン p
へ
(8)cにログインし、sのテーブルs5のSNAMEを「Weimin」、都市を「Shanghai」に変更
UPDATE s
SET SNAME='for the people', CITY='Shanghai'
WHERE sno='S1';
(9) p テーブルの p1 をナットに変更し、色を青に変更します。
UPDATE p
SET PNAME='ナット',COLOR='ブルー'
WHERE pno='p1';
実験結果：
(1) パスワード「bpassword」でユーザー b を作成します。
(2) パスワード「cpassword」で c ユーザーを作成します。
(3) 承認 (クエリと変更のアクセス許可を付与します。変更のアクセス許可のみは許可されません):
(4) ユーザー b にログインし、権限を確認します。
(5) b にログインし、s のテーブル s5 の SNAME を「for the people」に、都市を「Beijing」に変更します。
(6) p テーブルの p1 をネジに変更し、色を赤に変更します。
(7) b にログインし、認可権限を実行し、c に s テーブルと p テーブルに対するクエリと変更の権限を付与します。
(8)cにログインし、sのテーブルs5のSNAMEを「Weimin」、都市を「Shanghai」に変更
(9) p テーブルの p1 をナットに変更し、色を青に変更します。
結果分析:
ユーザーに変更権限を付与するときは、クエリ権限も同時に付与することを忘れないでください。選択しないと更新できません。
- ユーザーaとbの権限を取り戻し、ユーザーcの権限のステータスを確認します。
実験手順:
(1) spj テーブルに対する a のクエリ権限を取り戻します。
取消選択
SPJで
から;
(2) テーブル s および p を変更する b の許可を取り戻します。
更新を取り消す
で
から b;
更新を取り消す
上に
から b;
(3) ユーザー c がまだテーブル s および p を変更する権限を持っているかどうかを確認します。
ログイン c:
s テーブル s5 の SNAME を「Weiguo」に、都市を「Guangzhou」に変更します。
UPDATE s
SET SNAME='国',CITY='広州'
WHERE sno='S1';
p テーブルの p1 をネジに変更し、色を緑に変更します。
UPDATE p
SET PNAME='ネジ',COLOR='緑'
WHERE pno='p1';
実験結果：
(1) spj テーブルに対する a のクエリ権限を取り戻します。
(2) テーブル s および p を変更する b の許可を取り戻します。
(3) ユーザー c がまだテーブル s および p を変更する権限を持っているかどうかを確認します。
結果分析:
b の権限のみが取り消されていますが、b によって c に付与された権限は取り消されていません。これは、mysql がカスケード リカバリを実行していないことを示しています。
4.実験1で作成したテーブルについて、グラフィカル ユーザー インターフェイスを使用して外部キーの関係を確立し、外部キーの役割を確認します。
実験手順:
- 右クリック -- テーブルの設計 -- 外部キー -- 外部キーの作成
(2) 外部キーの役割を確認します: (外部キー制約に違反するデータを spj テーブルに挿入します)
spj テーブルに ('S8', 'P1', 'J9', 200) を挿入します:
INSERT INTO spj VALUES('S8' ,'P1','J9',300);
実験結果:
結果の分析:
S テーブルは S6 まで、p テーブルは P6 まで、j テーブルは J7 まで 挿入されたデータは外部キー制約に違反しているため、エラーが報告されます。
5. 実験 1 で作成したテーブルに対して、パーツの色を赤、オレンジ、黄、緑、青、青、紫の 7 色の範囲内にする必要があり、パーツの重量が 50 を超えないように設定します。これらの 2 つの制約条件付きの名前付けを指定します。名前は、自分の名前の完全なスペルです。
実験手順:
(1) 制約を追加します。
ALTER TABLE p
ADD CONSTRAINT pengzhen CHECK(COLOR in ('red','orange','yellow','green','green','blue','purple') and WEIGHT<=50);
(2) 制約が有効かどうかを検証するには、p テーブルの P1 の「緑」を「赤」に変更します。
UPDATE p
SET color='赤'
WHERE pno='P1';
実験結果：
(1) 制約を追加します。
(2) 制約が有効かどうかを検証するには、p テーブルの P1 の「緑」を「赤」に変更します。
結果分析:
制約が有用かどうかを確認するには、p テーブルの P1 の「緑」を「赤」に変更します。実行時にエラーが報告され、pengzhen 制約が既に存在します。データは変更できません。
6. SPJ テーブルの支給部品数を 1000 以下に設定する
実験手順:
(1) 制約を追加します。
ALTER TABLE spj
CHECK(QTY<=1000) を追加します。
- spj テーブルで最初のデータの QTY を 1200 に変更します。
アップデート spj
セット数量=1200
WHERE sno='S1' AND pno='P1' AND jno='J4';
実験結果：
- 制約を追加します。
(2) spj テーブルの最初のデータの QTY を 1200 に変更します。
結果分析:
制約が存在するため、データを 1000 を超える数に変更することはできません。
7. S テーブルのサプライヤ番号を文字「S」で始まるように設定します
実験プロセス:
ALTER TABLE s
add CHECK(sno like 's%');
実験結果:
結果分析:
制約を作成し、CHECK(sno like 's %')
8. 各テーブルのエンティティの整合性を確認します。
実験的プロセス:
-- テーブル s のエンティティの完全性を検証
-- (1) 通常のデータをテーブル s に挿入
INSERT INTO s VALUES('S7','Red Flag',10,'済南'); --
( 2) 重複データをテーブルに挿入 s
INSERT INTO s VALUES('S7','People',10,'Qingdao'); -- (
3) 空のデータをテーブルに挿入 s
INSERT INTO s VALUES( '','イノベーション',10,'広州');
-- p テーブルのエンティティの整合性を確認
-- (1) 通常のデータを p テーブルに挿入
INSERT INTO p VALUES('P7','tire',null,20);
-- (2) ピースを挿入p テーブル 繰り返しデータ
INSERT INTO p VALUES('P7','tire',null,20);
-- (3) p テーブルに空のデータを挿入
INSERT INTO p VALUES(NULL,'nail',null,5 );
-- テーブル j のエンティティの整合性を検証
-- (1) 通常のデータをテーブル j に挿入
INSERT INTO j VALUES('J8','Car Factory','Shanghai');
-- (2) テーブルに挿入j 繰り返しデータ
INSERT INTO j VALUES('J8','Car Factory','Shanghai');
-- (3) テーブルに空のデータを挿入 j
INSERT INTO j VALUES(NULL,'タイヤ工場' ,'南京');
-- spj テーブルのエンティティの整合性を確認します
-- (1) 通常のデータを spj テーブルに挿入します
INSERT INTO spj VALUES('S7','P6','J7',300);
-- (2) spj テーブルに挿入 重複データを挿入
INSERT INTO spj VALUES('S7','P6','J7',300);
-- (3) spj テーブルに空のデータを挿入
INSERT INTO spj VALUES('S7' ,NULL,' J7',300);
実験結果:
-- テーブル s のエンティティの整合性を検証
-- (1) 通常のデータをテーブル s に挿入 ('S7','Red Flag',10,'済南')
-- (2) s テーブルに重複データを挿入 ('S7','People',10,'Qingdao')
-- (3) テーブル s ('','Innovation',10,'Guangzhou') に空のデータを挿入します。
-- pテーブルのエンティティの整合性を確認します
-- (1) p テーブルに通常のデータを挿入 ('P7','tire',null,20)
-- (2) p テーブルに繰り返しデータを挿入 ('P7','tire',null,20)
-- (3) p テーブルに空のデータを挿入する (NULL,'nail',null,5)
--テーブルjのエンティティの整合性を確認します
-- (1) 通常のデータを j テーブルに挿入 ('J8'、'car factory'、'Shanghai')
-- (2) テーブル j に重複データを挿入 ('J8', 'car factory', 'Shanghai')
-- (3) jテーブルに空のデータを挿入 (NULL,'タイヤ工場','南京')
-- spjテーブルのエンティティの整合性を確認します
-- (1) 通常のデータを spj テーブルに挿入 ('S7','P6','J7',300)
-- (2) spj テーブルに重複データを挿入 ('S7','P6','J7',300)
-- (3) spj テーブルに空のデータを挿入 ('S7', NULL, 'J7', 300)
結果分析:
s、p、および j テーブルの作成時に定義された整合性制約により、重複データを挿入できず、プライマリ コードが null であるデータを挿入できません。上記のステートメントは、整合性制約を検証します。
