知らない方でも、概念的に読んでみてください。お話の題材としては、10,000件のサンプルデータはやや不満ではあります。できればもう1〜2桁多いデータ量の方が面白いのですが、それでも市販の教科書・入門書等のサンプルよりは、かなりマシです。データベースシステムは大量のデータを扱えることに意味があります。少量のサンプルデータで論じても、なかなか見えてこない部分が多いのです。ERD非常に単純な且つ純粋な階層的データなので、設計は簡単です。TABLE4個のテーブルを作りました。論理的にはちょっと変なのですが、各テーブルの行にはシーケンス番号の項目を持たせています。分類を表すためだけなら不要ですが、じつは分類の並びには意味があって、進化の過程での分岐が古いものが先に、そして新しいものが後に来るような、緩い表示の慣習があります。早く分岐したダチョウ目を先頭に、進化の最終形である鳴禽類(スズメ目)が最後に来るようなことです。元のリストの順番を保持して表示したいことが多くあるので、連番を振っています。する場合、シーケンスの採番の手段はいくつかあります。関数を使うことですが。MAX()で現在の最大値を取得し、インクリメントして新規行の番号にします。関数でも問題ないのですが、もっとデータ件数が増えた場合には、かなりのオーバーヘッドになります。MAX()関数を使うと遅くて実用になりませんでした。アーキテクチャ的な弱点です。速さとのトレードオフになっています。信じられないほど速いです。手抜きせずに、番号を保持するテーブルを作りました。トリガーでテーブル更新してみたいという意図もあったりします。したときに自動的にユニークな連番を付加しています。今回は、これをトリガーでやってみました。プログラム側では意識することがなくなって、トランザクション処理も確実なので楽になります。トリガーの定義記述はこんな感じです。して読むことがよく行われます。定義の詳細ごく普通です。普通ではあるんですが、さて?どうなんでしょう。屋さんのそれとは少しずれているのかもしれません。文ですが、さらっと出来たわけではありません。悩んで、紆余曲折がありました。制約を書いていませんでした。いうのも、稀な例として同じ学名に複数の和名を割り当てたい状況があるかも、と頭を過りました。皆さんよくご存じの公園にいる、豆を撒くとやってくる鳩ぽっぽです。正式な和名は「カワラバト」ですが、俗称の「ドバト」もよく使います。専門家の文章でも、図鑑の表記でも、混在したり併記したりすることがよくあります。手抜きと妥協はどこにでもあるけど厳格には別名格納用の表を作って正規化するべきでしょう。そこまでしなくてもなー......と。制約を外していたのです。いやぁ、何の問題もありませんよ。制約て、アフォなプログラムが事前のデータ重複検査を手抜きしたときに、エラーで叩き落とすぐらいのもんでしょう。いうのが、あまり項目属性の制約を使わない私の感覚ですが実際にはデータ更新の時に重複チェックはやっていますし。更新で落ちるアプリケーションなんて、あってはならない。)プログラムは全て予定通り動きます。後述の処理時間測定をやっていて、「???」と思いました。使用時だけときどき妙に時間が掛かることがあります。通常の数倍〜10倍程度。結果の検証コンピュータの気持ちになって考えるあ、気がつきましたね。パーサの気持ちになって考えてみよう!』ってわけです。組み立てていくわけですから。10倍遅いとはいっても、ミリ秒単位の計測をしてはじめて分かります。普通にパソコンの画面で応答を見ていたって、全く分かりません。いう『バグ?』って、じつは大規模システム開発でも結構あります。論理的に考えうる全ての要素を網羅しようとするDB設計者と、あくまで現実に即して考えるアプリケーション設計者の意志疎通が充分でないと、設計の意図とは異なる使われ方をします。その多くは、アプリケーションから使用するというより、保守・管理のツールとして効率度外視で用意したものだったりします。それを見つけたプログラマは喜んで使っちゃいます。