データベースのテスト問題の答え合わせと解説の後、データベースの設計についての説明を行う。

SQLの動作確認や、SQLの記述問題について解説し、 後半の説明問題について説明を行う。

授業後半は通常の授業に戻り、データベースの設計について説明を行う。

トップダウン設計では、要求仕様書などに記載された、名詞をベースに実体とその属性を抽出する。 動詞に注目すれば、関連を取り出すことができる。 これを元に、ER図を描いていく。

ボトムアップ設計では、既存のデータベースの元となる帳票をベースに属性を 作っていく。 最初に、レベル毎に分類し、その属性の中で、従属する属性を見つけテーブルを 分割してく流れを説明する。 ただし、処理の効率や更新の頻度を考慮して、表を併合する場合もあることを紹介。

中間テストの採点結果の返却と問題の解説を行う。

間違った回答の傾向をみていると、成績の悪い人は 2重forループの繰り返しから怪しそうな雰囲気が見えてくる。 4年の情報構造論になれば、構造体のポインタが絡むからこそ、 データの型に注目してプログラムが書けるようになってほしい。

最後の問題で、5年のデータベースの問題を流用し、 2つの表を串刺しのプログラムを書いてもらった。 しかし、この3年間、データベースに関連した出題をしていたことから、 傾向を予想されているのか、正解率は高かったかな。

解説終了後は、後半のグラフィックスの授業内容の導入として、 最近の映画をネタにグラフィックス処理の大変さを解説する。

• 12/07 ３軸の加速度・角加速度・方位センサー全部入り…I2Cバス 3.3[V] いいなぁ…ArduinoでMotion系これで全部いけるじゃん。 http://tinyurl.com/7cddm2b #fnct

この記事は、 の @TohruSaitohに掲載した #fnct タグ付き記事を、まとめたものです。

仕事をしていたら、 急にパソコン回りで「ぎーご・ぎーご」という音がする。 明らかにHDDの異常。 といっても、NASやらサーバやら並んでいるので、 まずは触診。それなりの音がするHDDは、それなりに触れば解る。 でも、まだ音も小さいし判別できなかったので、次は ひとつひとつ停止させたりしながら、音が止まるのを確認。

すると、一番最年長のサーバが原因。 といっても、Webを使った実験でちょいとファイル共有のために、 使っている程度で、後継サーバも動かしているし、 あっさり諦め。ひとまず、ファイルは読めるし、 後継サーバに移していないファイルを早々にコピーして、 shutdown。 後は、後継サーバがうまく使われるようにネットワークの設定を変更して終了。

最年長サーバだけあって、どれだけ持ったか…と備品シールをみると、 「平成14年」９年間か….よく壊れずにここまで動いていたな….

• 11/25 おもしろそう… "f-paletteはfuRoが開発した、電子工作マイコンキット。センサやモータ、スピーカなどを接続することができ…" http://bit.ly/rE2a0N #fnct

この記事は、 の @TohruSaitohに掲載した #fnct タグ付き記事を、まとめたものです。

テスト問題作り中なんだが、列挙型のネタを授業でやってるし、 出題しようかと画策するけど、"g++ -Wall" で警告吐かれるコードは、 基本掲載したくない。んで、C++での列挙型の型チェックの厳しさを 試してみた。

列挙型は、一連の識別可能なタグを自動生成するわけだし、 連番の数字を生成する。しかし、C++ではint型への昇格は認めているけど、 あくまで識別可能なタグ。だから、よく列挙型の紹介で使うコードは、 CではOKだけど、C++ではNG。

enum WEEK { SUN,MON,TUE,WED,THR,FRI,SAT } ;
for( enum WEEK w = SUN ; w <= SAT ; w++ ) {
printf( "%d¥n" , w ) ;
}

"WEEK::operator++() が見つからない"らしい。ま、予想の範囲。

整数値との変換は、昇格を認めているから、以下はC++でもOKなのか。

char week_name[][ 4 ] = {
"Sun","Mon","Tue","Wed","The","Fri","Sat"
} ;
printf( "%s" , week_name[ WED ] ) ; // OK。

うーむ、最初の for() みたいなの書きたい場合は、キャスト無しだと、 どう書くのがC++らしいのかな…

// 美しくない...
w = (enum WEEK)( (int)w + 1 ) ;

switch-breakの書き方

上記のネタの答えを探していたんだけど、その中で安全なコードの書き方なんだろうけど、 以下のようなコードの書き方を見つけた。 switch-case での break 書き忘れによる、処理の通りぬけを防ぐ目的なんだけど、 やっぱり気味悪いなぁ…

switch( x ) {
break ; case 1 : // 処理1
break ; case 2 : // 処理2
break ; default : // 処理default
}

有名な安全なコードの書き方の例として、if文の条件式中の"="と"=="の書き間違い を防ぐために、以下のように書くのも、個人的には気味悪くて嫌い。

// "=="を"="と書き間違えても、コンパイラは警告しない
if ( x == 0 ) 処理... ;
// もし"="に書き間違えたら、定数に代入はできないから警告!!
if ( 0 == x ) 処理... ;

チェイン法の説明を行う。

前回説明のハッシュ法は、ハッシュ衝突が発生した場合、べつのハッシュ値を そこに格納する。しかし、配列で実装した場合であれば、ハッシュ表以上の データ件数を保存することはできない。

チェイン法

チェイン法は、同じハッシュ値の物をまとめて保存する方法。 このため、同じハッシュ値のデータは、リスト構造とするのが一般的。

#define SIZE 100
int hash_func( int ph ) { return ph % SIZE ; }
struct List {
int phone ;
struct List* next ;
} ;
struct List* table[ SIZE ] ; // NULLで初期化
void entry( int ph ) {
int idx = hash_func( ph ) ;
hash[ idx ] = cons( ph , hash[ idx ] ) ;
}
int search( 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 ;
}

文字列をハッシュ値に

ここまでで説明した事例は、電話番号をキーとするものであり、 余りを求めるだけといったような簡単な計算で、ハッシュ値が求められた。 しかし、一般的には文字列といったような名前から、ハッシュ値が欲しいことが普通。

ハッシュ値は、簡単な計算で、見た目デタラメな値が求まればいい。 (ただしく言えば、ハッシュ値の出現確率が一様)。 一見規則性が解らない値として、文字であれば文字コードが考えられる。 複数の文字で、これらの文字コードを加えるなどの計算をすれば、 偏りの少ない値を取り出すことができる。

int hash_func( char s[] ) {
int sum = 0 ;
for( int i = 0 ; s[i] != '¥0' ; i++ ) {
sum = sum + s[i] ;
}
return sum % SIZE ;
}

実際には、幅広い値が求まり、文字列順序で違う値が求まるように、工夫をすることが多い。

  sum = sum + s[i] ; // 基本
sum = (sum*2 + s[i]) ; // 幅広い値で文字順序に依存
sum = ( sum*A + s[i] ) % B ; // A:小さい素数、B:巨大な素数

データベースの設計としての正規形の説明。 最初に、ER図の補足として、UMLのクラス図に近い書き方をする方式があることを 説明しておく。

正規形

データベースにおいて、様々な不整合を防ぐために正しい設計が必要であることを 改めて説明し、それには正規形としての条件を満たしている必要があることを説明する。

第一正規形は、すべての要素が原子値である条件を満たせばいい。 要素の中が複数の項目であったり表形式のデータがあると、 表構造のリレーショナルデータベースにはできない。

キーの説明：超キー(スーパーキー)とは、データベースで１つのデータを 選び出すために必要なデータ項目であり、複数の項目で１データを指定 できる場合もある。

候補キーとは、必要最小限の項目となっているものを指す。 １項目が抜けても選別できなくなるようであれば、候補キーとは言わない。 主キーとは、候補キーのなかで管理の都合上便利なもの。

データ項目の値が決まると、他のデータ項目が自動的に決まるものは、 従属関係があるという。

第二正規形は、部分従属がなく、すべての非キーデータ項目が、候補キーに 完全従属する場合をいう。

完全従属とは、候補キーを構成する全てのデータ項目に、非キーデータ項目が従属していること。 部分従属とは、候補キーを構成するデータ項目の一部のデータ項目に、非キー項目が従属していること。

この例において、単価は商品名が決まれば自動的に求まる情報。 (単価が日々変化することはないという条件で…) これは、部分従属となる。

推移従属性とは、データ項目でA→B→Cと、次々と値が求められる関係を指す。 このなかで、第三正規形とは、 候補キー以外の非キーデータ項目は、候補キーに完全従属し、 かつどの候補キーにも推移従属しない関係をいう。