第4章中間SQL
4.1接続式
SQLは、他の形式の結合操作を提供します。これにより、結果には、自然結合によって除外されたタプルを含めることができます。
4.1.1接続条件
SQLはon、接続に参加する関係に共通の述語を設定するために使用され、where類似していますが、外部結合操作では結果がwhere異なります。
on使い方は以下の通りです。
select * from student join takes on student.ID = takes.ID;
上記onの条件があればあることを示す属性タプルから学生が同じ属性タプルIDから取りID、その後、それらが得られた組として接続されています。
上記の結果は論理的に次のステートメントと同じですが
select * from student natural join takes;
しかし、on文は2つのがあることを意味し、重複したタプルを取り出していないID中での属性結果の関係、student.IDおよびtakes.ID
実際、同等のステートメントは
select * from student, takes where student.ID = takes.ID;
4.1.2外部接続
外部結合の導入
次のクエリステートメントを使用する場合は、「すべての学生の選択情報を調べる」というクエリを検討してください。
select * from student natural join takes;
現時点では、コースを選択していない、つまりテイクに対応するIDがない学生については、この学生のコース選択の結果は表示されないため、コース選択情報を次のように設定したいと考えています。学生はコースを選択しませんnull。今回、外部結合を導入しました。
一般に、外部結合と内部結合nullの結果は、内部結合の結果と一致しなかったタプルを保持するために、いくつかの属性に設定されます。
外部接続には、左外部接続、右外部接続、完全外部接続の3種類があります。
- 左外部接続。最初に内部結合を作成し、次に左側の関係に含まれていないタプルを含め、次にこれらのタプルの右側の関係の項目を設定します
null。 - 右外側の接続。最初に内部結合を作成し、次に右側の関係に含まれていないタプルを含め、これらのタプルの左側の関係に項目を設定します
null。 - 完全な外部接続。左外部結合と右外部結合の結合。
外部結合を使用した後、「すべての学生のコース選択情報を調べる」というクエリは次のように表すことができます。
select *
from student left outer join takes;
左外部結合を使用した後、コースを選択しない学生がいる場合でも、それらも結果に含まれますが、コース選択情報の値はに設定されnullます。
同様に、右外部結合と完全外部結合はright outer join合計として表されますfull outer join
onとwhereは、外部結合で異なる動作をすることに注意してください。外部結合では、内部結合の結果に作用します。つまり、nullで埋められてから挿入されるタプルには影響しません。しかし、どこが内部接続とnull挿入の後に得られた結果に作用します。たとえば、上記のクエリは
select *
from student left outer join takes on student.ID = takes.ID;
しかし、次のクエリ
select *
from student natural left outer join takes
where student.ID = takes.ID;
null属性を含むタプルはありません。
4.2表示
4.2.1ビューの定義
多くの場合、すべてのユーザーに関係全体の論理モデルを表示させたくはありません。セキュリティ上の理由から、特定のデータをユーザーから隠す必要があります。したがって、ビューはSQLで導入されます。ビューはクエリステートメントによって定義されますが、事前にデータが含まれていませんが、使用中にビューを定義するクエリステートメントによって計算されます。
SQLはcreate viewビューを定義するために使用します
create view view_name as <query expression>
view_nameビューの名前であり、<query expression>有効なクエリステートメントです。
たとえば、「2009年秋学期に物理学部が提供するすべてのコースを一覧表示する」というビューを定義できます。
create view physics_fall_2009 as
select course, course_id, sec_id, building, room_number
from section, course
where course.course_id = section.course_id and
course.dept_name = 'Physics' and
section.semester = 'Fall' and
section.year = '2009';
4.2.2SQLクエリでのビューの使用
このビューは、たとえば、「2009年の秋学期にWastonビルで提供されているすべての物理コースを検索する」などの関係として使用できます。
select course_id
from physics_fall_2009
where building = 'Watson';
4.2.3マテリアライズドビュー
特定のデータベースでは、ビューの関係を保存できますが、ビューの定義に使用される実際の関係が変更されると、ビューも変更されることが保証されます。このようなビューは、マテリアライズド・ビューと呼ばれます。
4.2.4更新を表示
ビューはクエリに便利なツールですが、ビューを使用して更新、挿入、または削除を表現すると、深刻な問題が発生する可能性があります。難しいのは、ビューによって表現されたデータベースの変更を、データベース論理モデルの実際の関係の変更に変換する必要があることです。したがって、ビューが更新可能と呼ばれる場合は、次の制限を満たす必要があります
- from句にはデータベース関係が1つだけあります。
- select句には、リレーションシップの属性名のみが含まれ、式、集計関数、および個別の宣言は含まれません。
- select句に表示されない属性は、null値を取ることができます。
- クエリ部分には、groupby句とhave句は含まれていません。
4.3事務
トランザクションは、一連のクエリおよび/または更新ステートメントで構成されます。SQL標準では、SQLステートメントが実行されると、トランザクションが暗黙的に開かれることが規定されています。次の2つのSQLステートメントのいずれかがトランザクションを終了します。
- 仕事をコミットします。現在のトランザクションをコミットします。これは、トランザクションによって行われた更新がデータベースに保持されることを意味します。トランザクションがコミットされると、新しいトランザクションが自動的に開始されます。
- ロールバック作業。現在のトランザクションをロールバックします。つまり、トランザクション内のすべてのSQLステートメントを元に戻してデータベースを更新します。このようにして、データベースはトランザクションの最初のステートメントが実行される前の状態に復元されます。
トランザクションがコミット作業を完了していない場合、その影響はロールバックされます。トランザクションの実行中にブレークポイントまたはシステムクラッシュが発生した場合、データベースの再起動時にロールバックが自動的に実行されます。トランザクションがコミット作業を完了した場合、ロールバックによってその影響を元に戻すことはできません。
トランザクションの完了はアトミックです。つまり、トランザクションは、すべてのステップを完了した後にアクションをコミットするか、すべてのアクションを完了できない場合はすべてのアクションをロールバックします。
多くのSQLステートメントでは、各SQLステートメントはデフォルトでトランザクションを構成し、実行後に自動的に送信されます。トランザクションが複数のSQLステートメントを完了する場合は、自動コミットをオフにする必要があります。
4.4整合性制約
整合性制約により、許可されたユーザーによるデータの変更によってデータの整合性が損なわれることはありません。
4.4.1単一の関係に対する制約
単一の関係に対する制約には、
- nullではありません。例えば、
name varchar(20) not null - ユニーク。例えば
unique(Aj1, Aj2, ..., Ajn)、unique属性グループ定義要素は、候補コードを構成します。 - check（<述語>）。たとえば
check(semester in ('Fall', 'Winter', 'Spring', 'Summer'))、。check属性値が条件を満たしていることを確認するための句。
上記の3つの文が上記にcreate table追加されます。
4.4.2 断言
アサーションは述語であり、データベースが常に満たすことができることを望む条件を表します。ドメイン制約と参照整合性制約は、特殊な形式のアサーションです。アサーションの定義は、一般的に次の形式です。
create assertion <assertion-name> check <predicate>;
アサーション構造をサポートする広く使用されているデータベースシステムはまだないことに注意してください。
4.5SQLデータ型とモード
4.5.1SQLの日付と時刻のタイプ
以下に示すように、SQLは日付型データをサポートします
date # 日历日期，包括年、月和日，如'2001-04-25'
time # 一天中的时间，包括时、分和秒，如'09:30:00'，可以用time(p)来指定秒的小数点后的数字数，用time with time zone来将时区和时间一起存储
timestamp # date和time的组合，如'2001-04-25 10:29:01.45'。可以用变量timestamp(p)来指定秒的小数点后的数字数，用timestamp with time zone来将时区和时间一起存储
case e as t正式な式を使用して、文字列eを型tに変換できます。ここで、tはdata, time, timestamp型の1つであり、文字列も正しい形式に準拠している必要があります。
またはの値dextract (field from d)から単一のドメインを抽出するために使用できます。ドメインはそれらのいずれでもかまいません。タイムゾーン情報を抽出することが可能と。datetimeyear, month, day, hour, minute, secondtimezone_hourtimezone_minute
現在の日付と時刻を取得する他の関数があります。current_date現在の日付をcurrent_time返し、現在の時刻（タイムゾーンあり）をlocal_time返し、現在の現地時間（タイムゾーンなし）を返します。タイムスタンプがされて返されたことにより、current_timestampおよびlocal_timestamp。
4.5.2デフォルト値
SQLではdefault、以下に示すように、テーブルの作成に使用されるデフォルト値を指定できます。
create table student(
...
tot_cred numeric(3, 0) default 0,
...
);
4.5.3インデックスの作成
インデックス（インデックス）は、データベースが、指定されたインデックス属性をとる関係にあるタプルを効率的に見つけるのに役立ちます。たとえば、学生関係の属性IDにインデックスを作成する場合、データベースシステムは関係内の他のタプルをスキャンする必要がなく、22201や44553などの指定されたID値を持つレコードを直接見つけることができます。
一般的に使用されるデータベースは、通常、次のステートメントを使用してインデックスを定義します
create index studentID_index on student(ID);
上記のステートメントは、学生関係の属性IDにstudentID_indexという名前のインデックスを作成します。
4.5.4ラージオブジェクトタイプ
SQLは、以下に示すように、文字データ用のclobラージオブジェクトタイプとバイナリデータ用のラージオブジェクトデータタイプを提供しblobます。
book_revoew clob (10kb)
image blob (10MB)
4.5.5ユーザー定義タイプ
SQL標準では、使用可能create typeおよびcreate domainタイプとフィールドをそれぞれ定義するように定義されていますが、これらの構造形式は、ほとんどのデータベース実装で完全にはサポートされていません。
4.5.6createテーブルの拡張
SQLはcreate table like、以下に示すように、テーブルの構造に基づいて新しいテーブルを作成するためのサポートを提供します。
create table temp like student;
ただし、上記のステートメントは、学生とまったく同じ構造の新しいテーブルtempを作成するだけであり、その内容は空です。
以下に示すように、クエリ結果に基づいて新しいテーブルを作成することもできます。
create table tl as (
select * from instructor where dept_name = 'music'
)
with data;
データが追加されない場合、データは挿入されません。新しいテーブルの属性は、クエリ結果の属性から取得されます。もちろん、新しいテーブルの名前の後に属性名を指定することもできます。
4.6承認
データベースに対するユーザーのアクセス許可を制限し、承認を通じてアクセス許可を提供できます。権限許可には、データ許可（選択、更新、挿入、削除）とデータベース許可（ユーザーが関係を作成、変更、および削除できるようにする）の2つのタイプがあります。ユーザーが不正なアクセス許可を実行すると、システムはその実行を拒否します。
4.6.1権限の付与と撤回
grant以下に示すように、権限の許可された使用
grant <权限列表>
on <关系名或视图>
to <用户或角色>
例えば
grant select on department to Amit, Satashi;
このステートメントは、ユーザーにAmitとSatashiに部門関係の選択権限を付与します。
以下に示すように、権限が一部の属性に固有であることが望まれる場合があります。
grant update(budget)
on department
to Amit, Satashi;
このステートメントは、ユーザーAmitとSatashiに部門関係の更新権限を付与しますが、予算のみが更新されます。挿入権限を付与する際に属性を指定することもできます。残りの未指定の属性は、nullとして指定されるか、デフォルト値として指定されます。
権限の付与pulicは、現在のすべてのユーザーと将来のユーザーの承認と同等です。
以下に示すように、revoke失効権限を使用できます。使用ステートメントとgrant時間はまったく同じです。
revoke update(budget)
on department
to Amit, Satashi;
ユーザーに付与された権限は、ユーザーが他のユーザーに付与することもできます。現時点では、権限の回復はより複雑になります。
4.6.2役割
SQLでは、ロールに権限を付与できます。この時点で、新しいユーザーが作成されると、そのユーザーにロールが直接付与されるため、新しいユーザーはロールが持つ権限を直接取得できるため、新しいユーザーを個別に承認する手間が省けます。
したがって、ユーザーまたはロールの権限には2つの部分が含まれます
- 直接付与された許可。
- 付与されたロールによってもたらされる権限。
create role以下に示すように、使用する役割を作成します
create role instructor;
次に、ロールに権限を付与できます
grant select
on department
to instructor;
次に、以下に示すように、ユーザーまたはロールにロールを付与できます。
grant dean to Amit;
create role dean;
grant instructor to dean;
4.6.5権限の移転
以下に示すように、grantコマンドの実行時に追加してwith grant option、許可されたユーザーが他のユーザーに許可を再度付与できるようにすることができます。
grant select on department to Amit with grant option;
あるユーザーから別のユーザーへの権限の転送は、承認グラフとして表すことができますが、相互承認の動作により、承認グラフでループが発生する可能性があります。
ユーザーが権限を持つための必要十分条件は、認証グラフのルートノードからユーザーを表す頂点へのパスがあることです。
4.6.6権限の撤回
ユーザーの権限が取り消されると、他のユーザーに付与された権限もデフォルトのカスケードによって取り消されますが、カスケードが取り消されないようにrevoke後で追加することができますrestrict。