2020-11-15 用課題¶
- 先に進む前に録画してあるか確認しよう
進捗¶
- 前回の進捗
- 基礎知識編:「COLUMN インメモリデータベース」まで
- 本編:03-06「定積分の例 $f(x)=x^2$」まで
- 今回の進捗
- 基礎知識編:次数と基数まで
- 本編:04-01 の冒頭
課題¶
- オリジナルコンテンツへのリンク
- 勉強会のコンテンツまとめ:GitHub へのリンク
- matplotlib を忘れないように、簡単なグラフをいくつか描いてみてください。
- TeX でいろいろな式を書いてみましょう。
- 勉強の日常組み込み系
- Julia:The Little Book of Julia Algorithmsを読んでみることにしました。適当に話します。
- そのうち取り組む事案:黒木さんの Julia での統計ネタ
- 応用情報の本を一日2ページくらい眺めてみてください。毎日やれば大体 1 年で読み終わります。
TODO¶
- AWS のハンズオン
- 東大の AWS クラウド講義資料を眺めてみてください。せっかくなので状況を見て(私の勉強も兼ねて)「勉強会前半パート」で取り上げようと思います。(とりあえず当面はやらない感じにする?)
- 面白そう:Julia での機械学習アルゴリズム本
- Algorithms for Optimization by Mykel J. Kochenderfer and Tim A. Wheeler @mitpress
自分用メモ¶
- 遅延型方程式に対するコメント追加
- matplotlib のチュートリアルを読もうの会
- 公式情報に触れる重要性
- 古い情報が古いと書いてあったりする:たとえば
pylab
- Gallery
- 見ていて面白い
- 「どこをいじるとどう変わるか」が視覚的にわかる
- 公式情報なのできちんとアップデートしてくれている(はず)
- 公式情報にソースがあるので自分でいろいろ書き換えていて破滅したとき、必ずオリジナルを復元できる
- 実際に競プロの問題をいくつか解いてみましょう。
Matplotlib¶
- 本当に簡単な図を描く
- これを参考に scipy お絵描き
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
TeX の記録¶
- ミンコフスキーの不等式
\begin{align} \Vert f+g \Vert_p \leq \Vert f \Vert_p + \Vert g \Vert_p, \quad p \geq 1. \end{align}
日々の勉強¶
Julia¶
- The Little Book of Julia Algorithms
- リポジトリの対象ディレクトリ:ここ
- その他参考
IT 基礎知識¶
- 応用情報の本を一日2ページくらい眺めてみてください。毎日やれば大体 1 年で読み終わります。
- ネットワークの話もいい加減飽きたので、DB の話を先行してやるか?
復習¶
- 3 つのスキーマ
- ユーザーが見るレベル
- 正規化などをかけておいたデータベースにもっていけるレベル
- 個々のデータベースに合わせた具体的なレベル
- インメモリの DB:コンピューターの基本的なハードウェア構成と意味を復習しよう
本の記述を追いかける¶
P.408 7.8 交換方式¶
P.408 パケット交換方式¶
- 回線交換方式と対になる概念
- 回線交換方式:通信を行うノード間で物理的な通信路を確保してから通信する
- 例:電話
- パケット交換方式について
- データ送信するノードはデータをパケットに区切る。
- ひとつひとつのパケットにヘッダを付けて送信。
- ネットワーク内ではパケット交換機にパケットがたまる
- ネットワークの状況に応じて順次送られる
パケット通信のメリット・デメリット¶
メリット¶
耐障害性 - 通信路を固定しないため,迂回経路が取れる。 - パケット交換機にデータが蓄積されているため,復旧まで待てる。 - パケット多重 - 1 対 1 の通信で回線を占有する必要がないため,1つの回線を多くのノードで共有でき,回線を効率的につかえる - 異機種間接続性 - パケット交換機で中継するときにプロトコル変換・速度変換でエンドノードどうしが同じプロトコルをサポートしていなくても通信できる
デメリット¶
- ネットワーク内の蓄積交換処理による遅延
- 蓄積交換処理による遅延解消のために主に回線の帯域を広げることで対応してきた
- 構造上,完全には遅延をなくせない
- パケット到着順序の不整合
P.408 ATM 交換方式¶
- ATM(Asynchronous Transfer Mode:非同期転送モード)
- 遅延のない回線交換方式とパケット交換方式の利点を得たい
- パケット交換方式の発展
- 遅延の原因をつぶす:特にパケットの多様性
- 多種多様なパケットに対応するために,パケット交換機はソフトウェア処理が必要 ^ ATM での工夫の一例:最も特徴的なのは,パケット(ATMではセルという)の長さをヘッダ部 5 バイト,ペイロード 48 バイトの53バイトに統一
- パケット解析がハードウェアだけでできる。
- ソフトウェアは不要になった。
- Wikipedia から
- 当初の意図に反して非常に複雑な技術になってしまった
- ATM は次世代の主流にならず限定的な使用にとどまった
- ATM の設計思想は MPLS へと引き継がれた
- 汎用のレイヤ 2 のパケットスイッチングのプロトコルとして、ルーターを介したIPの通信網で利用されている。
P.408 ペイロード(payload)¶
- データ通信で本来転送したいデータ本体の部分、ボディを指す。
- ATM ではペイロードのサイズを固定して処理を簡素化
- 難点:パケット全体に占めるペイロードのサイズが相対的に小さくオーバヘッドが大きい
P.410 輻輳¶
- フレームリレー:パケット交換方式の一種
- 1 つの回線を多数のユーザで共有。
- 回線がもつ潜在的な伝送能力(ワイヤスピード)を十分に引き出すうえで効果がある
- 輻輳:ユーザの利用が一時期に集中すると,ワイヤスピードを超えるパケットがネットワーク上に流れる
- ネットワークが輻輳状態になるとスループットが落ちる
- フレームリレーサービスを提供する事業者は,ネットワークが輻輳状態に陥ってスループットが低下しても最低限保証する通信速度を決めている
- CIR(Committed Information Rate:認定情 報速度)
P.370 7 ネットワーク¶
- 確か 7.4 から始めた気がするので 7 章はじめから
P.370 7.1.1 OSI基本参照モデル¶
- 改めて復習
- OSI(Open System Interconnection)基本参照モデル- 異なる設計思想・世代のシステムと円滑に通信するのが目的に標準化
- プロトコルの単機能化,交換の容易さが目的
- 階層化のおかげで一部の階層の技術体系が変わっても、その階層だけ取り替えればいい
- コスト・リスクを小さくする
P.370 プロトコルとサービス¶
- N 層:それぞれの階層のこと
- エンティティ:N 層に存在する通信機器などの実体
- この言葉はいろいろなところで出てきていろいろな意味で使われる
- もちろん気分的には適当な実体を指すことが多い
- プロトコル:N 層に属するエンティティが通信するための取り決め
- 上位の層が下位の層を利用しながら通信する
- 別の階層間のエンティティどうしが通信する窓口が必要
- これを提供するのが下位層:この機能をサービスと呼ぶ
- プロトコルに沿った仕様で製品を開発すれば別のベンダの機器でも通信できる
- 参考:ベンダーロックイン
特定ベンダー(メーカー)の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象のこと。
出来上がった情報システムの正確な仕様が、システムを開発・構築したベンダーにしか解らなくなる場合がある。結果、システムの保守・拡張・改修等の際、現存システムを開発・構築したベンダーに引き続き発注せざるを得なくなる。
- 「Excel で行政に提出する書類を作れ」事案もそれ。
- Apple 製品で身の回りを固めるのも同じ。
- 「多様性が大事」事案でもある。
7.1.2 TCP/IPプロトコルスイート¶
- プロトコル同士には相性がある
- 「ネットワーク層がこのプロトコルならトランスポート層はこのプロトコルにしておくとトラブルが少ない」
- 一般に同じ団体が作ったプロトコルはセットで使われることが多い
- このセットがプロトコルスイート ^ 最も代表的なのは IP を中心に組まれた TCP/IP プロトコルスイート
- 独自の階層モデルをもつ
P.372 TCP/IPの通信¶
- データをパケットに区切る
- 各パケットにヘッダを付けて送信
- ヘッダは各階層ごとに付加されて次の階層へと渡される
- 各ヘッダにはその階層で必要となる送信元や送信先,大きさ,順番などパケット自体に関する情報を含む
- TCPヘッダを付加したパケット:TCP セグメント
- IP ヘッダを付加したパケット:IP パケット
- MACヘッダを付加したパケット:MAC フレームあるいはイーサネットフレーム
P.372 MAC(Media Access Control)アドレス¶
- イーサネットや FDDI で使用される物理アドレス
- イーサネット (Ethernet):コンピューターネットワークの規格の1つ。オフィスや家庭で一般的に使用されている有線LAN (Local Area Network) の技術規格
- FDDI:LAN でデータ転送を行うための標準の一つ
- Fiber distributed data interface
- データリンク層
- 同じネットワークに接続された隣接ノード間の通信で相手を識別するために使う
- MACアドレスの長さ:6バイト
- 先頭24ビットの OUI(ベンダID)
- 後続24ビットの固有製造番号(製品に割り当てた番号)
- MAC アドレスは機器が固有にもつ番号
- 必ず一意に定まるように IEEE が管理
P372 ポート番号¶
- トランスポート層にでノード内のアプリケーションの識別に使う識別子番号
- 0-65535の範囲
- TCP/IPではパケット交換方式でデータをやり取りする
- よく使われるアプリケーションについてのポート番号は Well-Known ポートとして標準化
- TCP・UDPそれぞれで 0-1023 番までの番号を割り当てている
- SSH:TCP22番
- Telnet:TCP23番
- SMTP:TCP25番
- HTTP:TCP80番
- POP3:TCP110番
- IMAP4:TCP143番
- HTTPS :TCP443番
- NTP:UDP123番
- SNMP:UDP161番
- SNMP Trap :UDP162番
- セキュリティ対策のために標準とはポート番号を変えることもある
- Web 開発の本を読んでいると、いろいろな都合から http のポートを 80 以外にしていることもよくある。
- 80 の場合はポートを指定しなくてもいい
- 例:http://localhost/hoge/fuga
- 例:http://localhost:5000/hoge/fuga
- 80 の場合はポートを指定しなくてもいい
P.373 ネットワーク間の通信¶
- 同じネットワークに接続されたノード間はデータリンク層(第 2 層)の通信
- ネットワークを超えたノード間はネットワーク層(第 3 層)の通信 -実際に図 7.1.4 を見よう
- どこが IP アドレスでのやりとりか?
- どこが MAC アドレスでのやり取りか?
P.374 7.2 ネットワーク接続装置と関連技術¶
P.374 7.2.1 物理層の接続¶
P.374 リピータ¶
- ネットワーク上を流れる電流の増幅装置・整流装置
- 物理層:第 1 層
- データ通信はネットワーク上を流れる電流
- ケーブルが長いと電流が減衰・波形が乱れが起きる
- データが読み取れなくなる
- これを増幅するのがリピータ
- 大昔の電話は距離が遠いと音が小さく聞こえにくかった
- まさにこの減衰が問題
- リピータは 1:1 で繋ぐ
- 現在では複数のノードを接続できるマルチポートリピータ(ハブ)が使われるのが一般的
P.374 7.2.2 データリンク層の接続¶
- 第2層
P374 ブリッジ¶
- データリンク層に位置
- ネットワーク上を流れているフレーム(情報の単位)の MAC アドレスを認識して通信を中継する
- 接続されているノードをコリジョンドメイン(セグメント)という単位に分割
- MAC アドレスで判定したフレームのあて先のあるセグメントだけにフレームを送信
- 無駄なトラフィックの回避
- ポートの記憶
- 通信のたびにある MAC アドレスをもつノードがどのポート に接続されているか学習
- 次回の通信時には余分なポートには通信を中継しない。
- ブリッジの動作
- あて先MACアドレスをもとにMACアドレステーブルを参照する
- あて先MACアドレスの接続ポートがフレームを受信したポー トと別ポートであれば,そのポートにフレームを送信し
- 同一ポートであればフレームを破棄する
- あて先MACアドレスが記憶されていない場合やブロードキャス トアドレス(FF-FF-FF-FF-FF-FF)の場合は,受信ポート以外のすべてのポートにフレームを送信する
P.375 スイッチングハブ¶
- レイヤ2スイッチ(L2スイッチ)とも呼ばれる
- データリンク層に位置
- ブリッジと同じ働きをする
- MAC アドレスを認識してフレームのあて先を決めて通信を行います。
- 試験での問われ方
- スイッチングハブはフレームの蓄積機能、速度変換機能や交換機 能をもっている。
- このようなスイッチングハブと同等の機能をもち,同じプロトコル階層で動作する装置はどれか
- 答えは「ブリッジ」
P.375 ブロードキャストストリーム¶
- データリンク層で動作するブリッジやスイッチングハブなどの LANスイッチはブロードキャストフレームを受信ポート以外 のすべてのポートに転送
- これらの機器をループ状に接続し冗長化させると信頼性はあがる
- ブロードキャストフレームは永遠に回り続けながら増える
- 最終的にはネットワークダウンを招く
- この現象をブロードキャストストームという
- ブロードキャストストームを防ぐプロトコル:スパニングツリープロトコル(Spanning Tree Protocol:STP)
- ループを構成している一部のポートを通常運用時にはブロック(論理的に切断)する
- ネットワーク全体をループをもたない論理的なツリー構造にする
P.376 ネットワーク層の接続¶
- 第 3 層(レイヤ 3)
P.376 ルータ¶
- ルータはネットワーク層(第 3 層)に位置する
- あて先IPアドレスを見てパケットの送り先を決め通信を制御する
- IP のローカルネットワークの境界線に設置して利用され,ネットワークの基本単位として機能
- 世界中に散在しているローカルネットワークどうしをルータが結ぶ
- 全体としてインターネットというインフラが機能
- ルータで分けられたネットワークの単位をブロードキャストドメインという
- ルータがパケットを受け取ったあと
- あて先IPアドレスを見る
- 自分のネットワークあてであれば,破棄
- 他のネットワークあてであれば転送
- どのルータへ送ればあて先のネットワークへの通信が速く行えるかを判断することを経路制御(ルーティング)
- ルータはそのための経路表(ルーティングテーブル)を備えている
P.376 デフォルトゲートウェイ¶
- 会社Aのネットワークに属するPCは会社BのPCと直接通信できない
- 会社AのPCは他ネットワークへの接点であるルータAに転送を依頼
- デフォルトゲートウェイ:会社AのPCから見て直近のルータA
- 自分と直接接続していない相手と通信するときはすべてデフォルト ゲートウェイを中継する
P.376 ルーティング¶
- 経路表(ルーティングテーブル)の作成方法
- 手作業で作る:スタティックルーティング
- ルーティングプロトコル利用:ルータ同士が経路情報を交換し、自立的に経路表を作るダイナミックルーティング
- ダイナミックルーティングのための代表的なルーティングプロトコル:RIP、OSPF
- RIP:ディスタンスベクタ型(距離ベクトル型)
- ルーティングテーブルの情報(経路情報)を一定時間間隔で交換しあう
- あて先ネットワークにいたるまでに経由するルータの数(ホップ数)最小経路を選ぶ
- あて先に到達可能な最大ホップ数は 15
- これを超えた経路は採用されない
- OSPF:リンクステート型
- コストを経路選択の要素に取り入れ、コスト最小経路を選ぶ
- コスト値は,回線速度を基に自動的に算出されるが手動設定もできる
- コスト算出式「コスト=100Mbps/経路の通信帯域(bps)」
- コスト計算例は P.377 の図を見ること
P.377 ルータの冗長構成¶
- ルータを冗長構成のために使うプロトコル:VRRP(Virtual Router Redundancy Protocol )
- 同じ LAN に接続された複数のルータを仮想的に 1 台のルータ として見えるようにして冗長構成を実現する
- 複数のルータでグループ(VRRP グループ)を作る
- VRRP グループごとに仮想 IP アドレスと仮想 MAC アドレスを割り当て
- PC などのノードは仮想ルータの IP アドレスに対して通信
- 通常時はグループのマスタルータが仮想ルータの IP アドレス(仮想 IP アドレス)を保持
- マスタルータに障害が発生すると他のバックアップルータがこれを継承
P.377 レイヤ3スイッチ(L3スイッチ)¶
- ルータと同じネットワーク層(第 3 層)の通信機器
- 特徴
- ルータ:ソフトウェアで転送処理
- レイヤ 3 スイッチ:専用ハードウェアで転送処理
- 高速処理できる:大容量のファイルを扱うファイルサーバへのアクセスなど
P.378 トランスポート層以上の層の接続¶
P.378 ゲートウェイ¶
- トランスポート層(第 4 層)-アプリケーション層(第7層)でネットワーク接続するための装置
- 第 3 層のネットワーク層まででエンドツーエンド(E2E)の通信は完成する
- E2E = 通信を行う二者、あるいは、二者間を結ぶ経路全体
- エンドツーエンド原理:高度な通信制御や複雑な機能は末端のシステムが担い、経路上のシステムは単純に信号やデータの中継・転送だけすべし
- TCP/IP ネットワークの原理
- 誤り訂正・フロー制御・再送:TCP 層(第4層、トランスポート層)など上位側の機器やソフトウェア・プロトコル
- 単純な送受信・転送処理:IP 層(第3層、ネットワーク層)
- ゲートウェイ:第 4 層のトランスポート層以上が違う LAN システム相互間のプロトコル・データ形式の変換を担う
- ゲートウェイはアプリケーションプロトコルの内容を 解釈できる
- アプリケーションヘッダの不正な情報混入を検出可能
- ファイアウォール・プロキシサーバもゲートウェイの一種
P.378 L4スイッチ・L7スイッチ¶
- L4スイッチ(レイヤ4スイッチ)はトランスポート層(第4層)の装置
- 定義としてはゲートウェイ
- 機能的にはレイヤ2スイッチ・レイヤ3スイッチの延長上
- ルータやレイヤ3スイッチはIPアドレスを参照して経路制御する
- L4スイッチではTCPポート番号やUDPポート番号も経路制御判断に使える:第4層の機器だから
- L7スイッチ:アプリケーション層(第7層)までの情報を使って通信制御する
P.379 7.2.5 VLAN¶
- VLAN(Virtual LAN:仮想LAN)
- スイッチ(レイヤ2スイッチ,レイヤ3スイッチ)で物理的な接続形態とは独立に仮想的なLANグループを構成する仕組み,あるいはそう構成されたLAN
- 複雑な形態のネットワークを楽に構築できる
- サブネット構成も柔軟に変えられる
P.380 データリンク層の制御とプロトコル¶
- データリンク層:第2層
P.380 7.3.1 メディアアクセス制御¶
- 複数のデータを1つのケーブルを通して送受する場合,データの衝突(コリジョン)を回避するための制御が必要
- これがメディアアクセス制御(Media Access Control:MAC)
コリジョン(衝突)¶
イーサネットや無線LANで複数の端末が送信し、データが衝突する現象を指す。旧式のイーサネット規格では、端末同士を接続するときに1組の通信路で双方向の通信を行う半二重通信のため、送信と受信を同時に行うことができない。送信と受信をその都度切り替えて行うので、端末がお互いデータを送信してしまうと衝突する可能性が高くなる。
P.380 CSMA/CD¶
- CSMA/CD:Carrier Sense Multiple Access with Collision Detection:搬送波感知多重アクセ ス/衝突検出)の略。
- イーサネットで採用されている方式
- 衝突検知方式を採用
- イーサネット:IEEE 802.3として標準化されている LAN規格
- CSMA/CD
- 各ノードは伝送媒体が使用中かどうかを調べて,使用中でなければデータを送りはじめる
- 複数のノードが同時に通信しはじめるとデータの衝突が起こる
- 衝突を検知し,一定時間(ランダム)待った後で,再送
- 一定の距離以上のケーブルでは衝突が検知できない
- CSMA/CD方式の限界
- トラフィックが増加するにつれて衝突が多くなる
- 再送が増え,さらにトラフィックが増加する悪循環に陥る可能性がある
- 特に伝送路の使用率が30%を超えると実用的でなくなる
P.381トークンパッシング方式¶
- トークンによる送信制御を行う方式で
- トークンバス方式
- トークンリング方式
P.381 トークンパッシング方式¶
- ネットワーク上をフリートークンと呼ばれる送信権のためのパケットが巡回する
- フリートークンを獲得したノードだけが送信できるので衝突を避けられる
- ふつうはコンセントレータ(集線器)でネットワ ークとノードを結ぶ
- トークンパッシング方式を採用したLAN規格
- 例:FDDI:Fiber Distributed Data Interface
- FDDIは物理媒体に光ファイバを利用し,最大100Mビ ッ ト/秒の通信
- 特徴
- 伝送媒体上では衝突しない
- トラフィックが増えるにつれてトークンを獲得しにくくなり,少しずつ遅延時間が増える
- 衝突による再送制御の必要がないため伝送路の使用率に対する遅延時間の増加率はCSMA/CD方式より緩やか
P.382 TDMA 方式¶
- TDM(時分割多重)
- ネットワーク上にデータを送信する時間を割 り当てる(タイムスロット)
- タイムスロットごとに別のデータを送って多重化する
- TDM によるアクセス制御が TDMA
- TDMA(Time Division Multiple Access:時分割多重アクセス)
- CSMA/CD・トークンパッシング方式と並ぶ主要なデー タリンク技術
- TDMA ではネットワーク(伝送路)を使える時間を細かく区切る
- 割り当てられた時間は各ノードが独占する方式
- TDMAはコネクション型の通信
P.382 7.3.2 無線LANのアクセス制御方式¶
P.382 CSMA/CA方式¶
- CSMA/CA:Carrier Sense Multiple Access with Collision Avoidance、搬送波感知多重アクセス/衝突回避
- 無線 LAN の制御方式
- CSMA/CD との違い:「衝突検出」が「衝突回避」になった
- 無線 LAN:物理層媒体は電波で衝突の検出は不可能だから回避する
- 特徴
- 送信ノードは使いたい周波数帯の使えるか確認後、必ずランダムな時間だけ待ってから送信をはじめる
- 待ち時間をバックオフ制御時間とよぶ
- 衝突してフレームが壊れても検出できない
- データを受け取ったノードは ACK を返す
- 送信ノードは使いたい周波数帯の使えるか確認後、必ずランダムな時間だけ待ってから送信をはじめる
P.328 RTS/CTS¶
- 無線 LAN の話
- 隠れ端末問題
- 他のノードのデータ送信を感知できないことがある
- 通信ノード間の距離が遠い
- ノード間に障害物がある
- 回避のための RTS/CTS 方式
- 無線 LAN ノード
- データ送信前にRTS(Request ToSend:送信リクエスト)をアクセスポイントに送信
- これを受理したアクセスポイントがCTS(Clear to Send:送信OK)を返信
- 他のノードは CTS を傍受して自分以外の別のノードに送信権があると解釈
- データ送信を延期
- 無線LANノードはアクセスポイントからCTSを受信したらデータ送信開始します
- 衝突抑制:CTSに書かれた他のノードに対する送信抑制時間を使う
- データ送信開始前にデータ送信のネゴシエーシ ョンとして RTS/CTS 方式を使った CSMA/CA を CSMA/CA with RTS/CTS とよぶ
P.383 無線LANの動作モード¶
- 無線 LAN の動作モード:図7.3.4参照
- 2 つのモードがある
- インフラストラクチャモード:無線LANノードがアク セスポイントを通じて相互に通信
- アドホックモード:アクセスポイントなしに無線LANノードどうしが直接通信
P.383 COLUMN FDMA,CDMA¶
- 表7.3.1:多元接続する技術グループ
- TDMA とセット
- FDMA
- ある周波数帯をさらに細かい周波数帯に分割
- 接続できる端末数を増やす技術
- CDMA
- 周波数も時間も分割しない
- 符号で各端末の通信を識別・分離
- 接続できる端末数を増やす
P.383 7.3.3 データリンク層の主なプロトコル¶
- 第 2 層
P.384 ARP¶
- ARP(Address Resolution Protocol):通信相手のIPアドレスからMACアドレスを取るためのプロトコル
- ARPの動作
- ブロードキャストで目的IPアドレスを指定したARP要求パケットをLAN全体に流す
- ブロードキャスト:ネットワークに参加するすべての機器に同時に信号やデータを送ること
- 各ノードは自分のIPアドレスと比較
- 一致したノードだけARP応答パケットに自分のMACアドレスを入れて返す(ユニキャスト)
- ブロードキャストで目的IPアドレスを指定したARP要求パケットをLAN全体に流す
- 参考:GARP(Gratuitous ARP)
- 主な目的:自身に設定するIPアドレスの重複確認・ARPテ ーブルの更新
- 目的IPアドレスに自身が使うIPアドレスを指定し,MACアドレスを問い合わせる
P.384 RARP¶
- Reverse-ARP:逆アドレス解決プロトコル
- MACアドレスからIPアドレスを取る
- 電源オフ時にIPアドレスを保持できない(IPアドレスを保持するハードディスクをもたない)機器が電源オン時に自分のMACアドレスから自身に割り当てられているIPアドレスを知るために使う
- RARP サーバー
- MACアドレスとIPアドレスの対応表を持ったサーバー(RARPサーバー)が必要
P.384 PPP¶
- PPP:Point to Point Protocol
- 2 点間をポイントツーポイントでつなぐためのデータリンクプロトコル
- WANを介して2つのノードをダイヤルアップ接続するときに使う
- ネットワーク層(第3層)とネゴシエーションする NCP(ネットワーク制御プロトコル)とリンクネゴシエーションするLCP(リンク制御プロトコル)からなる
- NCP:Network Control Protocol
- LCP:Link Control Protocol
- リンク制御やエラー処理機能を持つ
P.384 PPPoE¶
- PPPoE:PPP over Ethernet
- PPPと同等な機能をイーサネット(LAN)上で実現するプロトコル
- PPPフレームをイーサネットフレームでカプセル化して実現
P.384 7.3.4 IEEE 802.3規格¶
- メディアアクセス制御に CSMA/CD 方式を使う LAN についての標準
- OSI基本参照モデルにおけるデータリンク層(第 2 層)と物理層(第 1 層)のプロトコルおよびサービスを規定
- OSI 基本参照モデルでのデータリンク層を LLC 副層と MAC 副層の2つに分割
- 物理層での LAN で使う伝送媒体や MAC 副層でのフレーム構成や衝突検出の仕組みを規定
- ツイストケーブルの企画が表 7.3.2 にまとまっている
P.386 7.4 ネットワーク層のプロトコルと技術¶
- もうやった
P.290 6.1.3 データベースの3層スキーマ¶
P.290 スキーマ¶
- schema
- データの性質・形式・ほかのデータとの関連などデータ定義の集合
P.290 ANSI/SPARC3層スキーマ¶
- データベースの3層スキーマ
- データを扱う立場を3つのグループに分け,それぞれに対応したデータ定義するためのモデル
- 目的:次の2点の確立
- 論理データ独立性:論理的なデータと利用者やアプリケーションプログラムから見たデータとの独立
- 物理データ独立性:記憶装置との独立
- cf. P.291 の図。
- 外部スキーマ
- 利用者やアプリケーションプログラムから見たデータを定義
- 実世界が変化するとそれに合わせて概念スキーマは変わる
- アプリケーションプログラムが影響を受けないようにするためにするためのスキーマ
- 例:関係データベースのビュー
- 概念スキーマ
- 実際のデータの物理的な表現方法とは別
- データベースの論理的構造とその内容を定義
- 例:論理設計段階の論理データモデル
- 内部スキーマ
- データを記憶装置上にどのような形式や編成で記録するか、物理的内容の定義
- 障害回復処理(リカバリ),セキュリティなども考えた実際にコンピュータに実装させる格納表現
P.292 6.1.4 E-R図¶
- 実世界にあるデータ構造をなるべくそのまま表現したい
- データベース管理システムに依存しないデータモデルを作りたい
- ER 図:E-Rモデルを図で表現
- Entity-Relationship Diagram
P.292 E-R図の構成要素¶
- エンティティ:データベース化の対象となる実世界を構成する実体
- 大きく分けて 2 種類
- 物理的実体がある:顧客、商品など
- 物理的実体がない:顧客と購入商品の「関係」そのもの:後の例参照
- RDB の例をいろいろ見るとわかる
- アトリビュート:エンティティがもつその性質や特徴を表すいくつかの属性
- 例:顧客エンティティ
- 顧客番号,顧客名
- 識別子:エンティティを一意に識別するための属性
- いわゆる ID:関係データベースの表の主キー
- 例:顧客番号
- 内部 ID と外部(?)ID がある。
- 内部 ID:システム内で固定の ID。よく数値を使う
- 外部(?)ID:ログイン ID などユーザーが決める ID。
- メールアドレスなどある時点では一意。
- ユーザーが変更できるのでシステム内でその値を永続的に使えない
- 関連(リレーションシップ):業務上の規則やルールなどによって発生するエンティティ間の関係
- 顧客はいくつもの商品を注文する
- カーディナリティ:エンティティ間の「1対1」、「1対 多 」、「 多 対 多 」といった対応関係の表現
- 数学で基数・濃度を cardinal number というその cardinal
P.292 「多対多」の関係¶
- 「多対多」の関係は,関係データベースとして実装できない
- 「1対多」と「多対1」の関係に分解する
- リレーションシップそれ自体を1つのエンティティとする
- 図 6.1.8 参照
- 識別子に顧客エンティティの識別子(顧客番号)と商品エンティティの識別子(商品番号)をもたせる
- 顧客と注文の関係は「1対多」、注文と商品の関係は「多対1」の関係
- このときの「注文」を連関エンティティと呼ぶ
- 注意:リレーションシップも属性をもつ
- 例:注文日、注文数量
- 顧客と商品の両方が特定されてはじめて確定する概念
- 例:注文日、注文数量
P.292 独立エンティティと依存エンティティ¶
- エンティティ間に「1対多」の関係があるとき
- 「多」側のエンティティは「1」側のエンティティの識別子を外部キーとしてもつ
- 外部キーがまさに RDB の R
- 外部キーが識別子の一部となる場合、そのエンティティは「1」側のエンティティに依存する
- cf. P.292 図6.1.8 の注文エンティティ
- 注文はある顧客がある商品を注文するという概念
- 顧客番号と商品番号がないと存在できない
- これを依存エンティティ(弱実体)と呼ぶ
- これを独立化したければしてもいい
- 注文番号を導入
- 注文エンティティを図 6.1.9 のように捉える
- 親エンティティに依存しない独立エンティティ (強実体)とみなせる
- 「発注書に ID を振りたい」といった要望も多いはずで、よくある対応
- 独立化させる必要がないケースの例も見てみよう
- e-ラーニングでの受講履歴
- 「誰がどのコースのどの単元を受講したか」
- 特に ID を振って独立に管理したいわけではない
- いつ何を受講してどういう結果だったか(テスト系ならどの問題にどう回答して正否はどうか)といったことは知りたい
P.294 6.2 関係データベース¶
P.294 6.2.1 関係データベースの特徴¶
- 関係データベース:RDB(Relational DataBase)
- 1970年 E.F.コッド博士によって提案された関係モデルをもとにしたデータベース
- 現在,最も多く使われているデータベース
- 一応集合論をもとにしているらしいが、集合論を知らなくても全く問題ない
- 計算機科学の専門家は集合を勉強しないと駄目らしいという事案ではある模様
P.294 関係データベースの構造¶
- 意味的にひとまとまりのデータを 2 次元の平坦な表で表す
- 列が「あるユーザの情報」
- 行が「ある属性の情報」:名前やメールアドレス
- 表に格納されるデータ:単位は次の通り
- 行(組、タプル)
- 列(属性、アトリビュート)
- 2 次元の平坦な表
- 行と列が交差する 1 つのマスには 1 つの値しか入らない
- 「1 つの値」とはいうが、JSON を叩き込むこともある
- 参考
- インデックスが張れず検索のパフォーマンスは厳しいので、検索したいなら JSON を張るのはやめた方がいい
- NoSQL だと列そのものが JSON だったりもする
- 第 1 正規形:cf. P.300 6.3.2
- 行と列が交差する 1 つのマスには 1 つの値しか入らない
次数と基数¶
- (この言葉を使った記憶がない)
- 次数:1 組のデータを表す行を構成する列の数
- 基数:1 つの表を構成する行の数
- テーブルを集合とみなしたときの要素数
- 本曰く「次数は変わることはありません」
- テーブル定義を変えると変わる
- 実際にテーブル定義を変えることはよくある:特に開発中は。
- 機能追加・改修案件で追加されることもよくある
- 1 行は 1 組のデータを表す:表に対するデータの追加・削除で基数はよく変わる
P.295 定義域(ドメイン)¶
- テーブル全体を $\mathcal{T} = A \times B \times \cdots \times Z$ と書いたときの各 $A,B,\dots,Z$ をドメイン(定義域、domain)と呼ぶ
- 数学の集合と違って $\mathcal{T}$ の中に同じ集合を含まない:つまり $\mathcal{T} = \mathbb{R}^n$ といったテーブルは考えない
- ドメインは「属性が取り得る値の集合」
- RDB では適当なデータ型を対応させる:日付,金額,数量,量
- ドメインを新たなデータ型として定義すると違うデー タ項目でも同じ入力チェックや同じ出力編集ができる
P.296 6.2.2 関係データベースのキー¶
- 表中の行を一意に識別するためのキー(スーパキー,候補キー,主キー)
- 別の表を参照し関連づけるための外部キー
P.296 スーパキー¶
- 表中の行を一意に特定できる属性,あるいは属性の組
- 組について:購入履歴を知るためにはユーザーID・商品ID・購入日がわからないといけない、という程度の意味
- かなり広い意味のようなのでたぶんそんなに使わない
- 補足:なぜスーパ「ー」キーではないのか
- 参考
- JIS の規格がある
- その言葉が 3 音以上の場合には,語尾に長音符号を付けない:ブラウザ、プリンタ、スキャナ、ドライバ、フォルダ、モニタなど
- その言葉が 2 音以下の場合には,語尾に長音符号を付ける: キー、バー、エラーなど
- 参考 2:「サーバー」と「サーバ」、どっちが正解? - 【ビジネス用語】
- 参考
P.296 候補キー¶
- 行を一意に決めるための必要最小限の属性で構成されるスーパーキー
- 一意性制約が必要
- 何かの履歴のように複数のIDの組になることもある
- 外部キーが入るテーブルでよくある
P.296 主キー¶
- 複数存在する候補キーの中から任意に選んだ1つの候補キーを主キー(primary key)
- 主キーに選ばれなかった残りの候補キーを代理キー(alternate key)
- 主キー制約
- 一意性制約
- 実体を保証するため空値(NULL)は許さないという NOT NULL制約
P.296 外部キー¶
- 関連する他の表を参照する属性あるいは属性の組
- 2 つの表の間に「1対多」の関係がある場合
- 「多」側の表に「1」側の表の主キーあるいは主キー以外の候補キーを参照する属性をもたせて外部キーにする
- 参照制約:外部キーの値が外部キーで参照される表に存在することを保証
- 参照制約があると「親テーブル」のカラムを勝手に消せなくなる
- 複数の表を参照するなら表内に複数の外部キーを持つ
- 外部キーの値に NOT NULL 制約がなければ NULL が許される
- 一般に外部キーは被参照表の主キーを参照
- UNIQUE 指 定 さ れ た候補キーを参照する場合もある
- cf. 参照制約:P.320
P.297 COLUMN 代用のキー設定¶
- 主キーが複数の属性から構成される複合キー(連結キー)でその構成属性数が多すぎると運用が面倒
- 連番のような必ずしも積極的な意味がない属性を追加してそれを代用のキー(surrogate key)にする
- 複合キーを構成している属性はすべて非キー属性にして代理キーにする
P.298 6.3 正規化¶
P.298 6.3.1 関数従属¶
- 関数従属:ある属性xの値が決まると他の属性yの値が一意的に決まる関係で、$x \mapsto y$ と書く
- 属性 $x$:独立属性(決定項)
- 属性 $y$:従属属性(従属項)
- 正規化:1 つの表の中の属性間にある関数従属性に着目して整理する
- 整合性を維持しやすいデータベースが設計できる
P.298 部分関数従属¶
- 関係 $x \mapsto y$ で $y$ が $x$ の真部分集合に関数従属するとき、$y$ は $x$ に部分関数従属するという
- どこの業界の用語なのかよくわからない。情報系?
- 部分関数従属は独立属性 $x$ が複数の属性からなるときに起こりうる関数従属
- あまりピンとこない:P.299 に商品マスタ的な例が載っていた
- 本の例:独立属性 $x$ が $x_1$ と $x_2$ の 2 つの属性からなるとき
- ${x_1, x_2} \mapsto y$ が成り立ち、かつ $x_1 \mapsto y$ または $x_2 \mapsto y$ のどちらかが成り立つ
- このとき ${x_1, x_2 }$ と $y$ の間に部分関数従属がある
- 例:社員所属部門テーブル
- 社員番号・部門コード・部門名があるテーブル
- 主キー:社員番号と部門コード
- 部門コードに対して部門名は一意に紐づく
- このとき部門名は主キーに部分関数従属する
P.298 完全関数従属¶
- 完全関数従属:関係 $x \mapsto y$ で $y$ が $x$ のどの真部分集合にも関数従属しない
- 独立属性 $x$ が 1 つの属性かなるときは常に完全関数従属
P.299 推移的関数従属¶
- 直接ではなく間接的に関数従属している関係
- 例:社員マスタ
- 社員番号・社員名・住所・郵便番号からなるテーブル
- 社員番号から住所が一意に紐づく
- 住所から郵便番号が一意に紐づく
- 郵便番号は社員番号に推移的関数従属している
- 念のため:住所は住所マスタなどに外出し(正規化)するべきで、こういうテーブルを作ってはいけない
- 詳しくは次の 6.3.2 で議論される
P.300 6.3.2 正規化の手順¶
P.300 第 1 正規化¶
- 非正規:くり返し部分をもつテーブルのこと
- まずもってくり返しという言葉の理解自体がたぶん面倒
- いろいろな例に触れてみよう
- RDB は平坦な 2 次元の表(テーブル)
- くり返し部分をもつ表から繰り返しを排除してスリム化したい
- 第 1 正規化:くり返しを排除する操作
- 第 1 正規形:第 1 正規化して得られた表のこと
- cf. P.300 図6.3.4 の売上表
- P.300 図 6.3.5
- 売り上げ明細表:主キーの売上番号とくり返し部分を一意に決める商品番号が複合キー
- 別の表に分解する
- 外部キー:他のテーブルの主キーである売上番号を参照している
- 分解・独立させた表に元の表の主キーをもたせる理由:結合で元の表を再現するため
P.301 第1正規形におけるデータ操作での不具合¶
- 第1正規形になった表は RDB 上で定義できる
- データの冗長性のためにデータ操作時に不整合を起こさないように注意が必要:更新時異常の概念
- 種類は以下の通り
- 例は本 P.300 の売り上げ表・売上明細表から
- 第 1 正規形では以下のような更新時異常が起きる可能性がある
- 防止策が第 2 正規化・第 3 正規化
- どこまでどうやるかは状況次第
P.301 修正時異常¶
- 商品名「オレンジ」を「清見オレンジ」に変更したい
- 該当する行をすべて同時に変更しなければならない
- 1行でも変更し忘れるとデータ不整合が起きる
- 先に対策を書いておく
- 売上明細には商品番号だけ持たせて、商品名を削る
- 削った代わりに商品テーブルを作る
- (ふつう商品テーブルには単価も切り出す)
- (単価に消費税を載せるかどうかといった問題もある)
P.301 挿入時異常¶
- 売上明細表の主キーは売上番号と商品番号の複合キ ー
- 売上のない("売上番号"が空値)商品は登録できない
- どうやらこの本の「売上表」は商品テーブルも兼ねているらしい
- 先に対策
- 商品テーブルを別に作って、そこからの参照という形にする
P.301 削除時異常¶
- (先程と同じくこの本の売り上げ表は商品テーブルも兼ねている模様)
- 売上実績が 1 つしかない商品のの売上データを削除す ると商品データも削除される
- 逆に商品データを残そうとすれば売上データは削除できない
- 先に対策:商品テーブルを切り出す
P.301 第2正規化¶
- 第2正規化:すべての非キー属性が各候補キーに完全関数従属である状態にする操作
- 第1正規形の表に対して行われる操作
- 候補キーの一部に部分関数従属する非キー属性を別の表に分解する
- 第2正規化して得られた表を第2正規形という
- 例:図6.3.7の売上明細表
- 候補キーは主キーの{売上番号,商品番号}の1
- 非キー属性である商品名と単価は主キーの一部である商品番号に部分関数従属している
- 商品表として独立させる
- 分解の仕方
- 商品表の主キーを商品番号
- 図6.3.7の上の表を再現できるようにする
- 売上明細表(図6.3.7の下の表)には商品表の主キーを参照する外部キーとして"商品番号"を残す
P.302 メモ¶
- 第2正規化するのは候補キーが複数の属性で構成されている場合。
- 1つの属性で構成されているのであれば部分関数従属は存在しない
- 既に第2正規形
- 非キー属性:どの候補キーにも属さない属性
- 第2正規形:どの非キー属性も候補キーの真部分集合に対して関数従属しない
- どの非キー属性も候補キーに完全関数従属
P.302 第3正規化¶
- 第3正規化:非キー属性間の関数従属をなくしてどの非キー属性も候補キーに直接に関数従属している状態にする
- 第2正規形の表に対して行われる操作
- 候補キーに推移的関数従属している非キー属性を別の表に分解
- 第3正規化して得られた表を第3正規形
- 例:図6.3.8の売上表
- これは第2正規形
- 顧客番号→顧客名いう非キー属性間の関数従属がある
- 顧客番号を主キーとした顧客表として独立させる
- 売上表には顧客表の主キーを参照する外部キーとして顧客番号を残す
P.303 メモ¶
- 第3正規形:どの非キー属性も候補キーに推移的関数従属しない
- どの非キー属性も候補キーに直接に関数従属している
- ボイス・コッド正規形
- 第3正規形では次の関数従属が存在する可能性がある
- 候補キーの真部分集合から他の候補キーの真部分集合への関数従属
- 候補キー以外の属性から候補キーの真部分集合への関数従属
- この関係を分解したのがボイス・コッド正規形
- 第3正規形では次の関数従属が存在する可能性がある
P.303 正規化と非正規化¶
- 正規形には第1正規形から第5正規形まである
- たいていの用途ではデータベースの場合、第3正規形まで正規化されていれば十分といわれている
- 正規化の目的はデータ操作にともなう更新時異常の発生を防ぐこと
- 属性間の関数従属を少なくする
- データの重複を排除する
- 正規化のデメリット
- 表がいくつにも分割される
- 必要なデータを取り出すために表を結合しないといけない
- 処理時間がかかる
- 処理速度が必要な時や更新時異常の発生が低い場合はあえて正規化しない・正規化を解く
- たとえば更新が少ない表は正規化しない
- ここでの「非正規化」:アクセスパターンを考えたうえでどの表を統合するか、どの属性を表間に重複させるか考える
P.304 6.4 関係データベースの演算¶
P.304 6.4.1 集合演算¶
- 関係データベースでの集合演算
- 同じ型の表間での和、共通部分(積)、差
- 直積:同じ型の表でなくてもいい
P.304 和、共通(積)、差¶
- 図6.4.1の表AとBに対するそれぞれの演算結果を見る
- 本参照
P.305 直積演算(Cartesian Product:×)¶
- 社員表と部門表の直積は社員表の各行に対して部門表の行を1つずつつなぎ合わせた表
- 直積の結果として得られる新しい表を直積表と呼ぶ
- 次数(属性の数)は両方の表の次数を足した数
- 位数(タプルの数)は両方の位数を掛けた数
- 直積が役に立つイメージがない:実際には結合 (JOIN) を本当によく使う
P.305 6.4.2 関係演算¶
- 関係演算:関係データベース特有の演算
- 射影,選択,結合,商
- 関係代数:関係演算と集合演算を合わせた代数
- 導出表:これらの演算によって得られた表
P.306 SQL の例¶
- 先に持ってきてみた
SELECT 社員コード, 社員名, 部門表.部門コード, 部門名
FROM 社員表, 部門表
WHERE 社員表.部門コード = 部門表.部門コード
P.305 選択と射影¶
- 選択演算:表から指定した行を取り出す関係演算
- SQL でいう WHERE
- 射影演算:表から指定した列を取り出す関係演算
- SQL でいう SELECT column_name
P.306 結合¶
- 参考:P.306 の下の表
- 結合演算:2つの表が共通にもつ項目(結合列)で結合して新しい表をつくり出す関係演算
- まさに正規化でわけたテーブルを結合させる演算
- SQL:SELECT文のFROM句で複数の表名をカンマで区切って指定
- WHERE句で結合条件を指定
- 結合条件
- 結合列の値を>,≧,=,≠,≦,<のいずれかの比較演算子で比較して結びつける
- 等結合:比較演算子が「=(等号)」である結合
- 2つの表から作成される直積表から結合列の値が等 しいものだけを取り出す
- 得られた新たな表には結合列が重複して含まれる
- SELECT句でどちらか一方の結合列を指定して見かけ上の重複を除く
- 自然結合(natural join):重複する結合列を取り除く(一方のみ残す)ようにした結合
- 結合列の列名が2つの表で同じ場合に使える
- 参考
- (意識的に使ったことがない)
P.307 内結合と外結合¶
- 参考:P.307 の図 6.4.8
- 内結合(INNER JOIN)
- 結合列の値が等しい行だけを取り出す結合演算
- 片方の表にしか存在しない行は取り出せない
- データベース言語仕様(JIS X 3005)
- 外結合(OUTER JOIN)
- 片方の表にしか存在しない行も取り出せる結合
- 結合相手の表に該当するデータが存在しない場合はNULL(空)値で結合
- 左外結合・右外結合・完全外結合
- 等結合
- 結合する表をFROM句で指定、結合条件はWHERE句 で指定
- 内結合・外結合
- 結合する表をFROM句の中でJOINを使って指定
- 結合条件は JOIN に続くON句で指定する
- 参考:p309のコラム「内結合と外結合のSQL文」
P.307 左外結合(LEFT OUTER JOIN)¶
- 参考:P307 図 6.4.9、P309 の SQL 文
- 結合する左の表(社員表)が基準
- 右の表(部門表)に存在しない行を空値(NULL)として結合
P.308 右外結合(RIGHT OUTER JOIN)¶
- 参考:P.308 図 6.4.10
- 結合する右の表(部門表)が基準
- 左の表(社員表)に存在しない行をNULLとして結合
P.308 完全外結合(FULL OUTER JOIN)¶
- 参考:P.308 図 6.4.11
- 片方だけに存在する場合もう片方をNULLとして結合
P.308 商¶
- (これ何だろうか?where の
in
?)- 普通に
in
または =`= でよさそう? select
も含んでいる?
- 普通に
- 参考:P.308 図 6.4.12
- 関係R(X,Y1,Y2)とS(Y3,Y4)がある
- S(Y3,Y4)のすべての行がR(Y1,Y2)に含まれる場合に対応するR(X)を求める演算
- 商(R÷S)は関係Rの中から関係Sのすべての行を含む行を取り出し、そこから関係Sの項目を除く
- 重複行も除く
- 参考:P.309、図6.4.13
- 社員表から東京に住み営業2課(E02)に勤務する社員を探す場合に商演算を使う
P.309 COLUMN ない結合と外結合の SQL¶
- 本を読もう
P.310 6.5 SQL¶
P. 310 6.5.1 データベース言語SQLとは¶
- SQL(Structured Query Language)
- RDB の標準的な操作言語
- ほとんどの RDBMS が SQL を使っている
- Relational DataBase Management System
P.310 SQLの分類¶
- RDB のデータを検索(参照)、操作
- データ定義
- トランザクション制御
- 参照:表 6.5.1 に SQL 文が書いてある
P.310 表 6.5.1 重要な SQL¶
- DDL (Data Definition Language)
- CREATE, DROP, GRANT, REVOKE
- DML (Data Manipulate Language)
- SELECT, INSERT, UPDATE, DELETE, COMMIT, ROLLBACK, DECLARE CURSOR, OPEN, FETCH, CLOSE
- DECLARE CURSOR以降は親言語方式などで使用されるSQL
- 親言語方式
- CやCOBOLなどのプログラム中にSQL文を組み込んでデータベースにアクセスする方式。
- 埋込みSQL:p328参照
P.311 6.5.2 SELECT文¶
- データ操作言語(DML)
- 問合せ(SELECT)文
- 挿入(INSERT)文
- 更新(UPDATE)文
- 削除(DELETE)文
- などなど
- SELECT文以外のDMLは「6.5.3 その他のDML文」(p319)参照
P.311 SELECT文の構文¶
- SELECT文の基本構文
- [ ]内は省略可能
SELECT
[DISTINCT]
列名のリスト
FROM 表名のリスト
[WHERE 選択条件や結合条件]
[GROUP BY 列名のリスト]
[HAVING グループ選択条件]
[ORDER BY 列名のリスト]
- リスト:列名および表名をカンマ(,)で区切って列挙したもの。
P.311 行、列の取り出し¶
- 選択:WHERE句に選択条件を指定すると特定の行を取り出せる
in
とリストを使うと複数行に対する- 具体例を考えないと使い分けや気分はわからなそう
- 射影:SELECT句に列名を指定すると特定の列を取り出せる
- SELECT句への
*
:全部の列を取りだす - 選択条件と論理演算子(AND・OR・NOT):複数の条件を組み合わせる
- 表 6.5.2:選択条件に使う比較演算子の表
- 参考:列の値が「空値(NULL)であるか」という検索条件
WHERE 列 IS NULL
WHERE 列 = NULL
ではない- NULL は他にもいろいろ邪悪な面がある
- 空文字列などとは違う概念でよくはまる
SQL 例¶
- P.312、図 6.5.1
- 社員表から年齢が24以上28以下の社員コード・社員名を表示するサンプル
SELECT 社員コード, 社員名 FROM 社員表 WHERE 年齢 >= 24 AND 年齢 <= 28
P.312 BETWEEN述語¶
- 先のSELECT文はBETWEEN述語やIN述語を使って同じ内容を表せる
- BETWEEN述語は「値1~値2」の範囲(値1,値2を含む)に列の値が含まれるかを選択条件にする
SELECT 社員コード, 社員名 FROM 社員表 WHERE 年齢 BETWEEN 24 AND 28
P.312 IN述語¶
- IN述語は列の値が指定された値のいずれかと等しいかを選ぶ条件にする場合に使う
- INの前にNOTをつけると指定された値のいずれでもないという選択条件になる
- IN述語の使用例については副問合せ(p317)も参照
P.313 重複行の排除¶
- 取り出された行の中から重複するものを除きたい場合
- SELECT句の列名指定にDISTINCT述語を使う
P.314 出力順の指定¶
- ORDER BY 句:特定の列の値で昇順・降順に並べ替えて表示する
- ORDER BY のあとに続けて並べ替えのキー(列名)を指定
- 降順の場合はDESC、昇順の場合はASC
- ふつう ASC がデフォルトで省略できる
SELECT 社員名, 年齢 FROM 社員表 ORDER BY 年齢 DESC
P.314 グループ化¶
- GROUP BY 句:取り出した行を指定した列の値でグループ化
- グループごとの合計や最大値などを求める
- HAVING 句:条件に合ったグループだけを取り出す
SELECT 所属, COUNT(), AVG(年齢) FROM 社員表 GROUP BY 所属 HAVING COUNT() >= 2
- SQL の簡単な解説
- 社員表のデータをGROUP BY句を使って所属でグループ化
- HAVING 句で「グループに所属する人数が2人以上」のグループだけを取り出す
- 取り出したグループごとにその所属・人数・平均年齢を求める
P.315 表の結合¶
- 2 つの結合
SELECT A FROM B WHERE
による等結合FROM
句の中でのJOIN ... ON
による内結合や外結合
- どちらであっても結合表には結合条件で指定した結合列が重複して含まれる
- 列名を指定するときは「表名.列名」という形式で表す
P.316 表に別名をつける¶
- FROM句で「表名 AS 別名」あるいは「表名 別名」と指定すると表名に対して別名(相関名)を設定できる
- 自己結合:表に別名を与えると同じ表どうしを結合できる
- 自己結合については P.317 の例を参照
- 上司コードを使ってある社員とその上司の氏名や関連情報を見たい場合に使う
P.317 副問い合わせ¶
- サブクエリともいう
- SELECT文のFROM句やWHERE句・HAVING句などに指定されている入れ子になったSELECT文
SELECT 社員コード, 社員名, 年齢 FROM 社員表 WHERE 年齢 IN (SELECT 指定年齢 FROM 調査対象)
- サブクエリにはいろいろ面倒な話がある
- 参考:MySQL のサブクエリって、ほんとに遅いの?
- これは 2017 年の記事:この辺はお金になるので割と日進月歩で、3 年程度の昔の情報でも既に参考にならないことも多い。
- 簡単なまとめ
- 遅いのは2番目、DEPENDENT SUBQUERYである
- MySQL 5.5 までサブクエリはやっぱり遅い
- MySQL 5.6 からはそんなに遅くなくなった
- MySQL とはいってもバージョンによって全然違う:オプティマイザは進化している
- 現状についてはきちんと最新の話を追う、または自分が必要なケースについて実測する
P.318 EXISTS述語¶
- サブクエリはEXISTS述語でも表せる
- 参照:P.318 の例
- EXISTS は相関副問合せが何らかの結果を返した場合にTRUE(真),何も返さなかった場合にFALSE(偽)を返す
- 主問合せの結果1行に対して相関副問合せから何らかの結果が戻されれば、主問合せの選択条件は成り立ち、何も返されなければ選択条件は成り立たない
- EXISTS 述語でほかの表にも存在するものを調べられる
- ANY でも同じ操作を表せる
- 参考:P.318 の例
- 副問合せの結果のいずれか(ANY)と等しい
- どれがいいかは最終的にはテーブルの実装や使っている RDBMS とバージョンに依存する
- 実測してチューニングしよう
P.319 6.5.3 その他の DML 文¶
P.319 INSERT文¶
- 表に行を挿入する:2つ方法がある
- 参考:本の P.319
- 挿入する値をVALUES句で指定する
- 問合せの結果をすべて挿入する
- (DBMS によるかもしれないが)個別INSERTと一括INSERTもある:パフォーマンスでよく問題になる
- 一部の列に対して INSERT
- どの列に対して挿入するのか列名リストで指定
- 省略された列の値はDEFAULT制約があればその既定値、そうでなければNULL値
- NULL はなるべく使うのをやめよう
- DEFAULT は P.322 表 6.6.1
P.319 UPDATE文¶
- 表中のデータを変更
- 列の変更値を直接指定する
- 変更値をCASE式で決める
- 副問合せの結果を変更値にする
- SET句には変更したい列の値を「列名 = 変更値」の形で指定
- 1 つのUPDATE文で複数の列の値を変えるときはカンマ(,)で区切って指定
- WHERE句を省略すると表中のすべての行が変わる
- ふつうはやらない
- WHERE句を指定すれば条件に合った行だけ変わる
P.320 DELETE文¶
- 表中の行を削除する
- 表中の全行を削除しても表自体は残る
- 表を削除するのはDROP文
- WHERE句を省略すると表中のすべての行が削除される
- WHERE句を指定するとその条件に一致した行だけを削除できる
P.320 参照関係をもつ表の更新¶
- 関連する2つの表の間に参照制約が設定できる
- 被参照表の主キー(候補キー)にない値を参照表の外部キーに追加できない
- 被参照表の行の削除・変更時に制約が出る:図6.5.10参照
- 参照動作指定:削除・変更時の制約は明示的に指定できる
- 次節のCREATE TABLE文を参照
- REFERENCES句(参照指定)の後に次の構文で指定
参照動作指定 REFERENCES 被参照表(参照する列リスト) ON DELETE 参照動作] [ON UPDATE 参照動作] (*[ ]内は省略可能)
- 指摘できる参照動作:表 6.5.5 の 5つ
- デフォルトは NO ACTION
P.320 補足¶
- 参照制約
- 外部キーの値が被参照表の主キーあるいは主キー以外の候補キーに存在することを保証する制約。
- 関連する2つの表の間に参照制約を設定する目的:データ矛盾を起こすような行の追加や削除・変更を排除するため
- REFERENCES指定:p322-324を参照
- データの整合性を保つための制約
- 一意性制約
- 参照制約
- データ項目のデータ型や桁数に関する形式制約
- データ項目が取り得る値の範囲に関するドメイン制約がある。
P.322 6.6 データ定義言語(DDL)¶
P.322 6.6.1 実表の定義¶
P.322 CREATE TABLE文¶
- 表の定義はには CREATE TABLE 文
- 基本構文は P.322 参照
P.322 列制約¶
- 表を構成する列に対する制約
- 参考:表6.6.1
- 一意性制約:同一表内に同じ値が複数存在しないことを保証する制約
- 主キーとなる列には一意性制約にとNOT NULL制約を加えたPRIMARY KEY指定
- 主キー以外の候補キーにも一意性制約がある
- 一般にNULL(ナル)値は重複値とは扱われない
- 候補キーにはNULL値を許すUNIQUE指定
- 参照制約:外部キーの値が被参照表に存在することを保証する制約
- 外部キー:REFERENCES指定(参照指定)す。
P.323 表制約¶
- 一意性制約・参照制約・検査制約は表制約(表定義の要素として定義される制約)にもできる
- 列制約:1つの列に対する制約
- 主キーや外部キーが複数列から構成される場合、これを列制約として定義できない
- このときは表制約を使う
P.323 主なデータ型¶
- 一般的な文字型,数値型は覚えておくといい
P.324 実表の定義例¶
- P.324 の社員表と部門表を定義を見てみよう
P.325 6.6.2 ビューの定義¶
P.325 ビューとは¶
- 実表:ディスク装置上にあり実際にデータが格納される表
- ビュー:実表の一部または複数の表から必要な行や属性(列)を取り出してあたかも1つの表 であるかのように見せかけた仮想表
- 利用者から見れば実表と同じ
- データを検索するだけなら制約はあっても同じように操作できる
- ビューのメリット
- あくまでも仮想の表:対象となった元の表(基底表)の列名と別の名前で定義できる
- ビューに定義することで情報を公開
- ビューに定義しないことで情報を非公開にできる
- 元の表に新たな列が追加されても既存のビューには影響がなく再定義する必要がない
- ビューは仮想的な表
- 一般には実体化されずデータ格納領域をとら ない。
- 実表のように実体化されるビューもある:体現ビュー(materialized view)
P.325 CREATE VIEW文¶
- ビューの定義:CREATE VIEW文による:詳細は本の P.325
- ビュー:対象となる実表(あるいは他のビュー)からSELECT文で必要データを導出する方法で定義される定義するビューの列名に命名規則はない
- 列数はAS句に続くSELECTで問い合わせた結果の列数と同じでなければならない
- 列名は省略可能:省略した場合はSELECTで問い合わせた結果の列名がそのまま定義される
- ビューに対する参照や更新処理
- ビューの対象となった表(基底表)に対す る参照あるいは更新処理に変換されて実行される
P.326 ビューの定義例¶
- 本の P.326 参照
- 社員表と部門表から社員コードと社員名、その社員が所属する部門名からなる表をビュー「社員表2」
- JOIN して必要なカラムだけ取り出す
P.326 ビューの更新¶
- ビューへの更新処理 ビュー定義を基にビューが参照している表(基底表)への対応する処理に変換されて実行
- 更新のための条件
- 更新にかかる実際の表が更新可能
- 更新される表の列や行が一意に決まる
- 更新できないビューの例
- SELECT句で式、集合関数、DISTINCT を使ったSELECT文で定義されている
- ・GROUP BY句やHAVING句を使ったSELECT文で定義されている
P.327 6.6.3 オブジェクト(表)の処理権限¶
- スキーマに定義された実表やビューはそのスキーマ所有者(作成者)にしか処理権限が与えられない
- 複数の利用者がデータベースを利用できるようにしたければ、スキーマ所有者以外にも処理権限を付与する必要がある
- データベース管理ユーザーは全権を持っていて危険な処理もできてしまう
- できることを制限したユーザーで操作したい
- オブジェクト(表)の処理権限
- 読取(SELECT)権限
- 削除(DELETE)権限
- 挿入(INSERT)権限
- 更新(UPDATE)権限
- cf. スキーマ
- 1つのデータベースの枠組み
- スキーマ内に複数の表やビューを定義できる
P.327 処理権限の付与¶
- 権限の付与:GRANT文による
- GRANTの基本構文は次の通り
1 |
|
- 権限指定
- 4 つの処理権限(SELECT,INSERT,UPDATE,DELETE)
- ALL PRIVILEGES(すべて)を指定できる
- 権限を複数付与する場合はカンマ(,)で区切って指定
P.327 処理権限の取消し(変更)¶
- 一度付与された権限を取消し(変更)できる
- 権限の取消しはREVOKE文
- REVOKEの基本構文
1 |
|
P.328 6.7 埋込み方式¶
P.328 6.7.1 埋込みSQLの基本事項¶
P.328 静的SQLと動的SQL¶
- 静的 SQL:あらかじめ決められたSQL文をプログラム中に埋込んで実行する方式
- 実際のアプリケーションではあまり見かけない
- 非カーソル処理:データベースの表から1行を取り出すこと
- 次のような SELECT 文
- この
INTO
を見たことがない
SELECT 社員名, 年齢 INTO :name, :age FROM 社員表 WHERE 社員コード = '100';
- 動的 SQL:実行する SQL 文がプログラム実行中でな ければ決まらない場合に SQL 文を動的に作成し実行する方式
- 上の社員コードがふつう変わる:それが「動的」。
- この動的な部分に変なコードを埋め込むとまずいというのがセキュリティ問題で、例えば SQL インジェクションの問題。
P.328 ホスト変数¶
- ホスト変数:データベースとプログラムのインタフェースとなる変数
- 埋め込み SQL では SQL を実行すると取り出されたデータをINTO句で指定したホスト変数に格納する
- ホスト変数は通常の変数としてもアクセスできる
- 出力関数で表示
- 入力関数で値を入力してそれをSELECT文の条件としても使える
P.329 6.7.2 カーソル処理とFETCH¶
P.329 カーソル処理¶
- 「SELECT・・・・INTO・・・」形式では,1行のデータしか取り出せない
- (見たことがないのでイメージがつかない)
- 検索結果が複数行の場合は1行ずつ取り出せるカーソル処理を使う
- カーソル処理は SQL 文で問い合わせた結果をあたかも1つのファイルであるかのようにとらえる
- FETCH文でそこから1行ずつ取り出す方式
- 1つのSELECT文に対してカーソルを宣言(定義)
- カーソルのオープンでSELECT文が実行
- カーソルで1行ずつ取り出せる
- FETCH文で繰返し行を取り出して処理
- 終了したらカーソルを閉じる
P.330 FETCHで取り出した行の更新¶
- 参考:図 6.7.2:FETCHで取り出した行の更新処理
- FETCH文で取り出した行を更新あるいは削除する場合,FETCH文のあとに続くUPDATE文やDELETE文のWHERE句 に「WHERE CURRENT OF カーソル名」と指定する。
- (FETCH 文を見たことがないのでイメージつかない)