データベースの設計の続きとして、 最初に先週説明が不完全であったボトムアップ設計の説明を追加する。 特にボトムアップ設計で、項目をレベルに分類し、データグループを作成・分離・統合 といった作業を説明する。

データベースの論理設計では、実際に出来上がったER図などから関係モデルに変換される。 しかし、実際には業務に応じて、処理のタイミング・処理の量・トラヒック、処理の要求条件 などを勘案しながら問題点を整理することを説明する。 テーブルの統合の検討として、複数のリレーションの直積(結合)をとりながらの 処理は、時間のかかる処理であったりするため、業務によっては統合が必要となったりする。 また、テーブルの分解の検討として、 同じリレーションへの処理の集中、特に更新作業が頻発する場合は、排他処理などが 発生し、データロックなどで処理が停滞する場合もあるため、必要に応じてテーブルの分解が 必要になるかもしれない。 インデックス情報の検討として、 参照の高速化ではインデックスファイルを用いたりする。しかしながら更新作業によっては、 インデックスファイルの更新の負荷が高まる場合もある。

データベースの物理設計では、実際にハードディスクの容量見積もり、メモリの容量見積もり、 ログファイルの見積もりなどが必要となる。 特にハードディスクの容量見積もりでは、PCTFREE(可変長データの増加による実体の移動を減らすためのデータ間のギャップ)や、PCTUSED(ページ内に空きが発生した時に他のレコードを収容するか？)に伴う、空き領域も勘案すべきである。

緊急連絡システムの配信されるメールの内容の相関を分析したくって、準備。文章比較を自分で書くと大変そうだし、便利なツールを Perl でできないかと探す。

文章をMecabで単語分割して、diff で差分を確認して、差分の行の量に応じてスコアをつければ簡単と思われる。かといって、テキストを子プロセスで MeCab や diff に渡すのは、中間ファイルが大量そうだし避けたい。 Perlモジュールを探すけど、やっぱり節操のない Perl だと、すべてが揃う…(^_^;

• Text::Diff – テキストの差分 / Perlモジュール徹底解説
• Perlメモ / MeCab モジュール

# aptitude search text-diff | grep perl
p   libtext-diff-perl  - Perl module to find differences in files a
# aptitude install libtext-diff-perl
# aptitude search mecab | gerp perl
p   libmecab-perl      - Perl 用 mecab バインディング
# aptitude install mecab libmecab-perl

簡単な実験プログラム。

#!/usr/bin/perl
use MeCab ;
use Algorithm::Diff 'sdiff' ;
my $a = "This is a pen.晴れた！"
."今日の天気は晴れています。"
."明日は雪がふるかな？"
."でもたぶん雨でしょう。" ;
my $b = "That is a pencil."
."今日の天気はどんよりと晴れてるよー。"
."明日はアラレがふるかな？"
."でもたぶん雪でしょう。" ;
sub mecab_split { # MeCabで単語分割
my $str = shift ;
my $mecab = new MeCab::Tagger( "" ) ; # コマンドライン引数
return map  { my @z = split( /\s+/ ) ; $z[0] }
split( /\n+/ , $mecab->parse( $str ) ) ;
}
my @a = mecab_split( $a ) ;
my @b = mecab_split( $b ) ;
my @diff = sdiff( \@a , \@b ) ;
foreach ( @diff ) {
my ($sign , $a , $b) = @$_ ;
print "$sign/$a/$b/\n" ;
}

(( 動作例 u:同じ,c:変更,+:追加,-:削除 ))
$ perl text-diff.pl
c/This/That/
u/is/is/
u/a/a/
c/pen/pencil/
:
u/たぶん/たぶん/
c/雨/雪/
u/でしょう/でしょう/
u/。/。/
u/EOS/EOS/

プログラム応用のテストの返却を行う。

構造体やポインタ・配列が絡む出題だったので、式の意味を正確に把握できていない人も多い。 解説の際には、式の部分がどういった型なのかを説明しながら、 優先順位を交えて説明を行う。

今回は、出題で解りにくい出題や出題ミスもちょっとあったので、配点には苦慮。

グラフィックス追加説明

テスト解説では、時間が微妙に余るので、補足説明を行った。 CMYKの解説問題で関連する式色系として、 色相Hue・彩度Satulation・明度ValueによるHSV系などを追加説明する。

また、グラフィックスの課題において、様々な開発環境があることを紹介。

• C,C++
  • Microsoft Visual C++(Visual Studio)
  • Borland C++
  • GrWinグラフィックスライブラリ
• Java
  • Java SDK(Sun:Oracle)
  • Processing

情報構造論のテストを返却。 25点満点5問出題で4問選択だから、普通に勉強していれば80点 (平均79点)といった状態。 テストとレポートを返却して、解説を行う。 時間が少し余ったので、テスト前の続きということでハッシュ法(チェイン法)を説明する。

チェイン法

チェイン法の最初に説明した方法は、オープンアドレス法で、 ハッシュ衝突が発生したデータは、本来の場所をはずれて次の場所に保管… といった方法をとっていた。しかしながら、単純なオープンアドレス法では、 ハッシュ表サイズ以上のデータを覚えられない。

チェイン法では、同じハッシュ値になったデータをリストに連結して保存する方式。

// 電話番号をハッシュ法で保存する。
struct List {
int  phone ;
struct List* next ;
} ;
struct List* hash[ SIZE ] ; // NULLで初期化
void entry( int ph ) {
int idx = hash_func( ph ) ;
// 授業ではリストの説明の際の補助関数で説明
// hash[ idx ] = cons( ph , hash[ idx ] ) ;
struct List* p ;
p = (struct List*)malloc( sizeof( struct List ) ) ;
if ( p != NULL ) {
p->phone = ph ;
p->next = hash[ idx ] ;
hash[ idx ] = p ;
}
}
// hash表に登録されているか？
int find( int ph ) {
int idx = hash_func( ph ) ;
struct List* p ;
for( p = hash[ idx ] ; p != NULL ; p = p->next ) {
if ( p->phone == ph )
return 1 ;
}
return 0 ;
}

チェイン法の処理速度を考えると、データ件数がハッシュ表より小さい間は、 ほぼリストの先には1件のデータしか入っていない。 このため検索時間は、ほぼハッシュ値計算の一定時間であり、 となる。

しかし、データ件数Nが、ハッシュ表のサイズを超えると、 リストの先に平均「データ件数/ハッシュ表サイズ」件の要素が連なる。 よって、検索時間はデータ件数に比例し、 となる。

うーむ、説明用にいい図はないかと、「チェイン法、オーダー」で画像検索したら、 オーダーメードの装飾品ばっかり…

今日は、テストの返却と説明の後、第3正規形を説明し、他の正規形について紹介を行う。

第3正規形

データベースでは、すべての要素が原子値となるような、第1正規化。 非キーが、キーに従属するような第2正規化を行うが、 データベースとして扱いやすくするには、第3正規化が重要。

• 素早く正規形を見抜く実践テクニック(@IT)

第1正規化	第2正規化

第3正規化では、第2正規形から、推移関数従属性を取り除いたもの。 推移関数従属とは、A→Bのような関数従属性があって、 さらにB→Cがあるような、A→B→Cのような関係。 これが推移従属があると、不整合がおこりやすい。

第3正規化

おまけ：BC正規形,第4,5正規形

この他にも、 さらに非キーからキーに関数従属性がある場合にそれを取り除く、 ボイスコッド正規形(BC正規化)。 「対称性のある多値従属性(キーを決めると複数データが該当)」を分解して得られる第4正規形や、 「元になるテーブルの結合従属性を維持して分解することにより得られる第5正規形などがある。

トップダウン設計・ボトムアップ設計

データベースの設計にあたって、実際の設計手順の説明を行う。

トップダウン設計では、対象業務を記述し、その中から名詞となっている実体を抽出する。 さらに動詞や形容詞のように記載されている関連を抽出する。 抽出した実体・関連では、あいまいであったり冗長であったりするので、整理したうえで、 その実体・関連をER図に表す。

ボトムアップ設計では、対象業務で実際に使われている入力帳票や結果の出力などを 見ながら、第1正規形を満たすように表を作っていく作業からおこなう。

トップダウン設計やボトムアップ設計で、 ER図や第一正規形を満たすような表が出来上がったら、 その属性の中で従属性を確認しながら、第2正規形・第3正規形へと整理していく。

就職氷河期で担任クラスも、不安感を持っている人も多く、 就職希望者が例年より多い状態。 その中で、企業に勤めているOBが、自分の企業のアピールのため 派遣されて、就職ガイダンスを行いました。

入社2年目になるパナソニックエレクトロニクスデバイスの酒井さんが来て、 企業説明。当初の予定では11人参加の予定だったけど、 ぎりぎりの参加希望者も入れて17人参加という状態。 就職希望者にしても、電子部品系以外の希望者もいるはずなんだけど、 県内大手の製造業とあってか、単一学科・単一企業でのガイダンスで、 これだけ参加するなんて、学生さんも就職に対する危機感たっぷりということだろう。

追記：といっても、暗いネタの記事へのリンク。

• 「就職氷河期」再来！ 質の高い学生を狙え

ガイダンスの裏で、専攻科授業の予定で中間テストの代わりの小テストの 採点結果を配布しようと準備していて、あたふたしていたが、 専攻科の教室に入ると誰もいない。 後半交代のA先生と「あれぇ？」と思っていたけど、 年間行事予定をみると、しっかり「専攻科休講」との記載であった….はぁ…

東工シャッターの方をお招きして、就職開拓セミナーとなった。

面白かったキーワードを以下に示します。 人材には、自燃性・可燃性・不燃性の人がいる。 会社のほしい人材は、

1. 元気に挨拶のできる人。
   (事実、挨拶のできる/できないは、人格と見られる)
2. プラス思考のできる人。
   迷ったらやる(仕事でも恋愛でも)
3. 好奇心旺盛なひと、負けず嫌いなひと。

いい会社のびる会社の見分け方、 挨拶のある、活気のある、きれいな会社。 仕事で成功するには、 (a)熱意があって、(b)仕事を好きに、(c)人間性を高める努力をする。 理性・知性・感性のある人。

講演って、たいくつな話もあるけど、シンプルに内容を絞ってわかりやすく、 聞いていてためになる話であった。 電子情報の学生さんは、きわめて真面目に聞いていたが、ざわついている学生さんもチラホラ。 最低限、私がこの講演に一言追加するなら、 「人の話をきける人」ということを言いたい。 この講演をサボって来ていない人、聞いていても寝ている人、無駄口ばかりの人、 こういう人は仕事をしてもダメなヤツが多いと思うぞ…