2020-10-24 用課題¶
- 先に進む前に録画してあるか確認しよう
進捗¶
- 前回の進捗
- 基礎知識編:P.408 7.8 交換方式から
- ネットワークの話に飽きてきたのでデータベースの話をする
- 本編:03-05 最急降下法の復習
- メモ:あとで 2 次元の場合のグラフなどを追加する
- 等高線が密なところは勾配が急:ここを通って最小化していく
- 基礎知識編:P.408 7.8 交換方式から
- 今回の進捗
- 基礎知識編:(ネットワークを飛ばして)「P.290 物理設計」まで
- 本編:03-05 「グラフの解説」まで
課題¶
- オリジナルコンテンツへのリンク
- 勉強会のコンテンツまとめ:GitHub へのリンク
- matplotlib を忘れないように、簡単なグラフをいくつか描いてみてください。
- TeX でいろいろな式を書いてみましょう。
- 実際に競プロの問題をいくつか解いてみましょう。例えば次のあたりからアタックします。数学・物理系の話として、まずはマスターオブ整数を眺めてみます。今回は6. 素因数分解を活用した考察の6-4. 約数の構造を知る)を見ましょう。
- 応用情報の本を一日2ページくらい眺めてみてください。毎日やれば大体 1 年で読み終わります。
TODO¶
- 東大の 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} u_{tt} = \triangle u. \end{align}
競プロ、AtCoder¶
6. 素因数分解を活用した考察の6-4. 約数の構造を知る)¶
問題¶
正整数 A,B が与えられます。 A と B の正の公約数の中からいくつかを選びます。 ただし、選んだ整数の中のどの異なる 2 つの整数についても互いに素でなければなりません。 最大でいくつ選べるでしょうか。
(数値例)
・A=60
・B=72
答え:3
60 と 72 の公約数は 1, 2, 3, 4, 6, 12 の 6 個ですが、このうち 1, 3, 4 を選ぶと「どの二つも互いに素」となっています。
ポイント¶
- 2 つの整数に関する問題から 1 つの整数に関する次の問題のように書き換える
正の整数 $G$ が与えられる。$G$ の約数の中から、「どの二つも互いに素となるように」いくつか選びたい。選べる個数の最大値を求めよ。
- $G$ を素因数分解する
- $a_1 a_2 \cdots a_N= p_1^{e_1} p_2^{e_2} \cdots p_K^{e_K}$
- どの 2 つも互いに素になるように約数を取る = 各素因数だけ取ってくる
- 最大公約数が 1 の数のペアが互いに素な数のペアなので、1 をいれてもいい
- 「素因数の個数+1」が求める最大数
- 1 を含めないといけないのが割とはまりポイントになりそう。
コードの参考¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
|
1 2 3 |
|
IT 基礎知識¶
- 応用情報の本を一日2ページくらい眺めてみてください。毎日やれば大体 1 年で読み終わります。
- ネットワークの話もいい加減飽きたので、DB の話を先行してやるか?
復習¶
OSI基本参照モデル¶
- 会社の部署と同じ気分
- 特定層は自分のところにしか責任を持たない
- 「他の層は他の層で専門的に管轄してね」
- お互い全くの無関係ではないが、基本的には自分のことだけ考えていればいい。
いろいろなプロトコル¶
- IP, HTTP, SMTP, POP, ARP...
- 通信の規格
- 状況に応じて適切なプロトコルを選ぶ
- ヘッダ・ボディーの概念
本の記述を追いかける¶
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.286 6.1 データベースの基礎¶
P.286 6.1.1 データベースの種類¶
- 代表的なデータベース
- 階層型データベース
- 網型データベース
- 関係データベース
- 関係データベースが一番よく使われている
- MySQL (MariaDB), PostgreSQL, SQL Server, Oracle
- (疑問)いわゆる NoSQL はどれなのだろうか?
- redis, mongoDB, memcache
P.286 階層型データベース¶
- (具体的なデータベース名(製品名)を知らない)
- 階層構造(木構造)でデータの構造を表現
- レコードどうしが親子関係をもつ
- ある親レコードに対する子レコードは 1 つ以上存在
- 子レコードに対する親レコードはただ1つ
- データの操作
- 親レコードと子レコードを結ぶポインタをたどる
P.286 網型データベース¶
- ネットワーク型データベースとも
- 親レコードと子レコードに「多対多」の関係がある
- 親レコードは複数の子レコードをもてる
- 子レコードは複数の親レコードをもてる
- データの操作
- 親レコードと子レコードを親子組(セット)
- 親子間や兄弟間のリンクをたどって 1 つのデータを取り出す
P.287 関係データベース¶
- データの集合を平坦な2次元の表で表現:リレーショナルデータベースとも
- 親レコード・子レコードという概念をもたない
- レコード間を結ぶポインタやリンクがない
- データ操作の結合でレコードを関連づける
- 1 つの表の 1 つの行と別の表との関連づけ
- 数学の集合概念に基礎をおく
- 値の一致(たとえば,外部キーと主キー)による
P.288 6.1.2 データベースの設計¶
- プロの技
P.288 データベースの設計プロセス¶
- 「概念設計→論理設計→物理設計」の順
- ER 図、関係モデル
P.288 概念設計¶
- 所有データを調査・分析して抽象化した概念データモデルを作る
- まずはデータのもつ意味やデータ間の関係を崩さずあるがままに表現する
- 概念データモデルは単純にデータのもつ意味とその関係を表したモデル
- コンピュータへの実装とは独立の、特定の DBMS に依存しないデータモデル
- DBMS:DataBase Management System、データベース管理システム
- E-Rモデル:EntityRelationship Model、エンティティリレーションシップモデル
- cf.P.292, 6.1.4
- UML のクラス図
- cf. P.496, 9.3.4
P.288 データ分析¶
- 概念設計のデータ分析
- 洗い出しが大事
- どのようなデータがあるのか
- 必要なデータはなにか
- 2 つの大きな目的
- 異音同義語(シノニム)や同名異義語(ホモニム)の排除
- 複数箇所に存在する同一内容データ(データ重複)の排除
- 手法
- データ項目を標準化
- 正規化:データ項目間の関連を明確にする
P.289 POINT データ項目洗出しの留意点¶
- 簡単なアプリ作成をしてみると気分がつかめる
- もしくは具体的なアプリのデータベース設計に関する本を読んでみる
- データ項目名の標準化
- データ項目の意味の定義
- "日付"・"年月日" の 2 つの項目をどう扱うか
- 別物ならデータ項目を定義して本当に別の実体にする
- データ項目のけた数や型の統一
- 型:文字列、日付型、数値、TEXT、バイナリなどなど
- 各データ項目の発生源や発生量の明確化
P.289 トップダウンアプローチとボトムアップアプローチ¶
- データの分析手法
- トップダウンアプローチ:最初に理想型の概念データモデルを作ってからデータ分析する
- ボトムアップアプローチ:画面や帳票などから項目を洗い出してデータ分析した結果として現実的な概念データモデルを作る
- 最終的なデータモデルへの要求事項
- 適切な正規化
- 正規化にもいくつかの段階がある
- いろいろな状況に応じて完全な正規化をしないこともある
- 例えばバッチ集計すると時間がかかりすぎる場合、あえて正規化を崩す
- 業務上のデータ項目をすべて持つ
- 適切な正規化
- どちらかだけで済むことはない
- 主に後者で組んだ上で前者の視点で見直すなど
- 業務・状況に応じて適切な方法を使う・組み合わせる
P.289 論理設計¶
- E-R 図などで表現された概念データモデルはそのままではデータベースに実装できない
- 概念データモデルを論理データモデルに変換する
- 階層モデル,ネットワーク(網)モデル,関係モデルの 3 つ
- それぞれのDBMSの制約に合わせて変換
- 関係データベース
- 概念データモデルを基に主キーや外部キーを含めたテーブル構造を作る
- テーブルの各列(データ項目)に設定される制約を検討
- 処理・利用しやすいようなビュー設計も必要
- ビュー(P.325 参照):データベースの実表のうち,利用者が必要とするものだけを利用に適した形で表として定義したもの
- SELECT 文を呼びやすくするために名前をつけただけ
P.290 物理設計¶
- 実際にデータベース内にデータ実装するときの注意
- 論理データモデルに基づいた特定のデータベース管理システム(DBMS)でデータ量・データの利用頻度・パフォーマンス・運用を考えてデータベースの物理的構造を決める
- データ量:初期データ量,増加度合い
- 利用頻度:トランザクション発生頻度,トランザクション種類(検索,更新)など
- 前に Twitter のシステムの話で紹介した事案
- 論理データモデルに基づいた特定のデータベース管理システム(DBMS)でデータ量・データの利用頻度・パフォーマンス・運用を考えてデータベースの物理的構造を決める
- 論理設計:データベースの見かけ上の設計
- 物理設計:実際に磁気ディスク上に記憶される形式などの具体的な設計
P.290 6.1.3 データベースの3層スキーマ¶
P.290 スキーマ¶
- schema
- データの性質・形式・ほかのデータとの関連などデータ定義の集合
P.290 ANSI/SPARC3層スキーマ¶
- データベースの3層スキーマ
- データを扱う立場を3つのグループに分け,それぞれに対応したデータ定義するためのモデル
- 目的:次の2点の確立
- 論理データ独立性:論理的なデータと利用者やアプリケーションプログラムから見たデータとの独立
- 物理データ独立性:記憶装置との独立
- cf. P.291 の図。
- 外部スキーマ
- 利用者やアプリケーションプログラムから見たデータを定義
- 実世界が変化するとそれに合わせて概念スキーマは変わる
- アプリケーションプログラムが影響を受けないようにするためにするためのスキーマ
- 例:関係データベースのビュー
- 概念スキーマ
- 実際のデータの物理的な表現方法とは別
- データベースの論理的構造とその内容を定義
- 例:論理設計段階の論理データモデル
- 内部スキーマ
- データを記憶装置上にどのような形式や編成で記録するか、物理的内容の定義
- 障害回復処理(リカバリ),セキュリティなども考えた実際にコンピュータに実装させる格納表現
P.291 COLUMN インメモリデータベース¶
- データを直接メモリに配置してパフォーマンスを上げる
- キャッシュとして使われることもよくある
- DB の基本はあくまでディスクにデータを記録してメモリに読み込む
- ディスク入出力がボトルネック
- 前に紹介した速度表を参照すること
- インメモリデータベースではディスク入出力がない
- 基本の処理がメモリ上で閉じるので処理が速い
- 最近のインメモリデータベースの傾向
- データをカラム(列)型フォーマットでメモリに配置する列指向(カラム指向)を採用
- 集計や分析処理などのクエリが高速化します
- 欠点
- 揮発性:メモリ上のデータは電源を切ると失われてしまう
- 何かの事故が起きたらデータが(すべて)飛ぶ
- HDD・SDD よりもメモリは高い
- 対策
- データを定期的にディスクに保存する機能
- 別のスタンバイデータベースにデータの複製を取るレプリケーション機能
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 で議論される