Author: admin

データベースの話を進める上で、基本的な概念として何をベースに話をスタートさせるかをきちんと決めておきましょう。用語の整理というよりも、基本概念の整理がまず必要です。以下の図は、どこかで見たことがあるようなと思われる方もいらっしゃいますが、大して難しい概念はないと思います。まず、これを見て、直感的に、住所録、つまり複数の人の名前、住所、電話番号を「表にしている」と見てもらえると思います。

この表がデータベースのごく基本的なモデルとなります。表にまとめることで、人間がデータを参照したときに理解、あるいは活用がしやすくなるということがあります。データがを混沌と記録していたとして、記録はできているとしても、そこから特定のデータを探したり、データの傾向を求めるということは大変なことだったり失敗したりということになります。一方、データをきれいに整理しておけば、容易に検索したり、確実に集計したりということが期待できます。その整理された形式が表です。

ここで、Excelなどの表計算ソフトを引き合いに出して、「表は良い」ということを議論することもできるでしょう。表にしておくことで、オーバーな言い方ではありますが、多くの人が成功体験を積んでいるはずです。色々な利点が見出されている表というのものをモデルとして考えるということが出発点になります。もっとも、それは鶏と卵の議論ではないかということも言えるかもしれません。リレーショナルデータベースの理論が最初に発表されたような時期だと、表というモデルを考えること自体は単に１つのアイデアであり有用性までは実証されていないとの見方もあったようです。後々、ソフトウエアとして実装された上で、リレーショナルデータベースの有用性が証明され、理論と実際が相互に発達してきたという経緯もあります。

結果的に「まず表で始めます」となると、表が便利なのは常識だろうということで理由が吹っ飛んでしまいますが、表が便利なことを突き詰めて考えるのはやはりかなり難しいとも言えます。感覚的に、理解しやすく、しかも、大量のデータを扱えそうだというあたりの考えが出発点にあるということは、それほど不自然ではないと考えます。

さて、表とは言ってももう少しその構造を細かく見ましょう。非常に重要なことは「１人の人が１行」ということです。つまり、この行のことを「レコード」と呼ぶとして、１レコードが何を表しているのかということが非常に重要です。実は、これが決まればデータベースは実装可能ですが、1レコードを示すものが揺らいだり、間違っていると、データの記録がうまくできません。このことは改めて説明しますが、ここでは住所録は１レコードが１人であるということに注目します。そして、１人のレコードには、複数の「フィールド」があります。フィールドには「フィールド名」がつけられています。

１人の人の住所録を管理する上で、ひたすら名前や住所を書き並べても良いのですが、よく整理された状態というのは、一定の基準で情報が分離され、整頓されているということであると言えます。基本的に１人の人は、１つの名前があって、１つの住所があるということにここではしてください。だとしたら、名前と住所をごちゃ混ぜに記録するよりも、名前の枠、住所の枠で分離しておく方が、整理されたように見えます。つまり、ある特定の「属性」の情報「だけ」が取り出したりあるいは入力しやすくなっている方が都合が良いということが言えるはずです。もし、ごちゃ混ぜだったら、その混沌としたデータから一部分のデータ（例えば、名前だけ）を取り出すことが大変だったり、あるいは不可能だったりします。よって、フィールドに分離分割され、フィールドに実際のデータを入れておくという仕組みが作られたわけです。そして、フィールドという単位で処理をすることにより、うまくいけばデータの種類に関わらず、必要なデータだけがポンと出てくるということができるはずです。

ちなみに、レコードについては、行、ロー、タプルなどの言い方があり、フィールドについては、列、カラム、属性、アトリビュート、プロパティなどの言い方もありますます。一部のコミュニティではその言い方を間違えると白い目で見られるということも以前はあったようですが、表形式でデータ全体を考えるという概念上は概ね同じものを指しています。一連の記事では、レコード／フィールドという呼び方で進めます。

表計算ソフトだと、縦横にセルが並んでいるのですが、見かけは同じ表でも、データベースでの表は、まず、表をレコードごとに分割されていて、そのレコードにフィールドが存在するという見方をするのが良いでしょう。表の一部分を自由に扱うということもある意味はできますが、階層的に記述したら、以下の図のように、レコードの方が上位概念になります。この図の線は、正確には「導出可能」という意味です。ある表である「住所録」があるとき、その住所録からレコードに辿り着き、特定のレコードからフィールドのデータに辿り着けるというのが導出の具体例です。実際にそういうプログラムを記述できると言っても良いでしょう。視覚的にいえば、表をまず横方向にスライスして、そのスライス１つ１つについて、縦方向にスライスすることで実データに辿り着くという感じです。

階層の図（「ツリー」と呼びましょう）ではフィールド名は省略していますが、最初の表と、この階層図は、概念的には同じものを示しています。同じとは何か？ ここでは「同一データ」と言っても良いでしょう。「表とツリーは同一である」ということは理解しづらいことかもしれませんが、一方で当たり前すぎて意識していない人も多いかもしれません。住所録は表で記述できますが、ツリーでも記述できるので、同一なのです。もちろん、表のほうがコンパクトで扱いやすそうです。ツリーが優れている理由はここでは明確にはありませんが、ツリーは関連性を明示可能です。つまり、表／レコード／フィールドという階層を明確に示すことができています。

ツリーを見ていると、フィールドの集合がレコードであり、レコードの集合が表であるということが明確にわかります。ここで、フィールドだけが具体的なデータを記録できていて、レコード自体はそのフィールドの集合という位置づけになります。なので、もちろん最初のレコードを「鈴木一郎」という名前で呼んでもいいのですが、レコードを特定する情報はここでは明確ではないので、便宜的に「レコード１」と記述しています。なお、レコードの特定の問題については、今後、色々な視点で説明をすることになります。

集合（set）といえば数学、数学といえば「嫌い」という人も多いかもしれませんが、集合論の真面目な議論に入らなくても、日常的な感覚の範囲では頑張って理解しましょう。ただ、集合と言うと深い議論があって、その１つは「集合には要素に重複はない」と言う定義です。集合の基本的な定義は「お互いに区別できるものの集まり」となっています。住所録の場合、重複したデータ、つまり全く同一の２つの行があった場合、用途上それは２つ存在している必要は全くなく一方は消したりないものとして扱うことは問題ありません。なので、レコードの「集合」が表なのです。また、フィールドについても、１つしかない名前を２つ以上のフィールドに入れたところでそのうちの１つしか必要ないので、フィールドの「集合」がレコードになるのです。この辺り、現実と数学の定義がよく合います。集合の考え方がリレーショナルデータベースの理論の基礎になっているという点は決して無視できない時事です。ここでは細かく議論しませんが、集合の要素は順序は問わないという定義もやっぱりデータベースの表といろんな意味でよくマッチングします。ちなみに、今回は数式は出しませんでしたが、先々では数式も出ると思います。その方がわかりやすいこともありますので、その時はなるべくわかりやすく説明するように心がけますが、数式があっても驚かないでください。

数学としての集合は有名ですが、その仲間のようなものも数学で定義されています。要素の重複を許すものをバグ（bag）あるいは多重集合（multiset）と呼ばれています。また、重複を許しつつ順序も情報として持つものを列（sequence、list）と呼ばれています。さらに重複は許さないが順序も情報として持つ順序集合（ordered set）もあります。これらも集合を基にした数学の理論は展開されています。ですが、プログラムができる方は、むしろ配列などとして理解されており、物理的な意味でデータを実際にこの形式で扱っているとも言えるので、抽象数学よりも具体的な世界での理解はされているのではないかと思います。数学に興味のある方はその辺りも書籍などを当たってみると良いでしょう・・・と言いつつ、この種の数学の書籍はかなり気合いと時間をかけないと理解に至らないのは確かですね。

次回は、表をツリーにしたことで、ER図の一部の定義に到達できることを説明しましょう。

データベースデザインを、ここでは、「リレーショナルデータベースでシステム開発等を行う場合に、データベースのスキーマ、つまりどんなテーブルやフィールドを用意すれば良いのか」と言う問題であると定義します。データベースそのものの設計ではなく、データベースを利用する場合の問題です。RDBで開発をしている人は、どのように設計をすればいいのかと言うことが大変難しい問題であることはよくご存知でしょう。FileMakerを使って「簡単にテーブル定義ができます」となっていても、操作が簡単なことで設計が適切にできるかどうかは定かではありません。単純なシステムならともかく、今時は手元でやっている複雑怪奇でどうしようもない作業があるからコンピュータにさせようと言うのが動機としては一般的です。したがって、目的とするシステムを実現可能なデータ構造も複雑化しがちです。そう言うことで開発をしようというと、ベテラン、エースあるいはアーキテクトなどと呼ばれる専門家などがスキーマ設計を行うことになります。彼らは、多くの事例にこれまで取り扱ったという経験があり、複雑でどうしようもなさそうな要求をうまくシステムが飲み込んでしまうようなスキーマを作ってしまいます。

そうしたスキルを得るにはどうすればいいか？ 経験を積むと言うこともあります。しかし、経験を積んでもそれができない人もいます。理解をするには理由を知ることが重要です。簡単な問題には「なぜ？」に対する答えは言えるのですが、非常に複雑な問題や、要件が怪奇すぎて微妙な問題に対するうまい解決策などをスキーマ設計者が出してきたとき、なぜそうなのかと言うことは設計者もうまく説明できないかもしれません。もちろん、理由があるのですが、知識を知らない人に説明できるかというとなかなか難しいと言うのが実情でしょう。もちろん、そう言う場合に頼りになるという意味では悪くはないとも言えますが、「自分もそうしたスキルをつけたい」と思ったらどうすればいいのでしょうか？

そう言うわけで、いろんな書籍があり、セミナーなどもやっていて、それらで勉強すればなんとかなっているという人もいるでしょうし、やっぱりわからなかったという人もいるでしょう。私も、ある有名なデータベース設計者のセミナーを参加して気づきました。そのかたの示す設計はもちろん、なるほどと思うところもあるのですが、理由を仔細におっしゃらない場面も多々あり、要するに「常識的にはこうなりますね」的な説明で終わってしまう場面もあったからです。その理由を知りたい、理由を知って応用したいと思うのが通常かと思いますが、やはりデータベース設計の世界は、どうもまずは経験を積んだ人の知見が主なナレッジということになってしまうのでしょう。

私自身はその答えはもう持っていて、クローズドなセミナー等で少しはお話ししています。また、そういうコンテンツを持っているのなら、それをビジネス展開してはどうかと思われるところかもしれません。少しはそう思っていたのですが、いろんな状況が重なり、「そうだ、淡々とブログに書こう！」と思った次第です。不定期にこの話題を積み重ねて行こうと思っています。まず、近々は、以前に所属した会社の社内セミナーで話そうとしていた内容を文章にまとめようと思っています。大まかに説明すると、「同じ名前のものが部署によって異なる対象になる」という事例から、それらはテーブルを分離しないと管理できないという話です。ドメイン駆動開発の世界でのユビキタス言語の考え方を、データベース設計のある側面に適用したお話しです。

そういうわけで、データベースデザインについて書くことにしました。

バンクーバー経由でアメリカに入った帰りは、やはりエアカナダだったのですが、サンフランシスコからカルガリーまでUnited Expressで行き、そこで乗り換えるというスケジュールでした。これも、2014年6月の状況ですが、メモとして残しておきます。

往路は先にエアカナダだったのでいろいろな意味でスムーズだったのでしょうけど、復路は先にエアカナダのコードシェア便でスタートです。そうすると、エアカナダの事前のチェックインは、カルガリーと成田間のフライトしかできず、最初にサンフランシスコで乗るフライトは、空港に行かないとチェックインができません。ちなみに、エアカナダはiOSのPassbookですので、紙はまったく使いませんが、その前には昔ながらのチケットを持ってカルガリーまで移動することになります。

まず、出発のサンフランシスコからの便は、ユナイテッドとエアカナダのコードシェア便で、運用はユナイテッドです。エアカナダのカウンターは国際線側にしかないため、この場合は運用しているユナイテッドの、しかも国内線のターミナル3に行って手続きをすることになります。カルガリーはもちろんカナダなのですが、国内線扱いですね。自動チェックイン機で、パスポートをかざせば、問題なく、チェックインがそこでできました。荷物もそこであずけて、成田行きというタグを貼ってもらいます。そして、セキュリティチェックを受けて普通に乗り込みます。23Aという席だったのですが、いちばん後ろの席でした。小さなジェットで約2時間半でカルガリーです。なお、最初に登場するときにバッグを預ければ、そのバッグの扱いがどうなるかを紙でもらえます。飛行機では税関深刻の用紙を記入しておきます。

カルガリーではまず入国審査をします。そこでけっこう並んだので焦ったのですが、幸か不幸かカルガリー発の飛行機も遅れたので、ダッシュしなくて済みました。アメリカからの便だと全員入国審査があり、たままた飛行機が重なったのか、かなりの列ができました。入国にはビザは不要で（乗り換えだけだから）、単にどこから来て、どこに行くのかを言って、滞在時間くらいを言っただけです。アメリカの入国のように、指紋や写真は撮らないのですぐに終わります。その後、ターンテーブルに行って、まず自分の荷物を持ち、関税申告の用紙の回収場所を通り抜けます。そこを出たすぐのところに、エアカナダのカウンタがあって、そこで荷物を再度預けます。単にチケットのチェックをして、ベルトコンベアに載せるだけです。この荷物の移動を自分でやらないといけないということです。

そして、後は飛行機に乗り込みますが、工事中なのか、迷路のように入り組んだところを通貨して乗り場に行きました。そして、カルガリー発の便に乗る時に、入り口の係の人がパスポートチェックをします。Passbookのチケットとパスポートを渡し、検索をして確認すればOKです。iPhoneとパスポートを返されるときも、紙のチケットと同じように、パスポートにiPhoneをはさんで返してくれます。まあいいのですが、習慣って変わらないのですね。カルガリーからの便は半分ほどしか席が埋まってない感じでした。

ちなみに、サンフランシスコ空港まではいつもBARTを使っているのですが、到着時に何も考えずに往復分のチャージをしました。しかし、今回、朝早い便だったのでBARTで行く事ができず、シャトルで移動しました。チャージされたBARTチケットが余ってしまって困っています（苦笑）。

追記：6とbも間違うぞという指摘があったので、修正します。

ユーザ名やパスワードは、時として「手で入力する」ことを必要とします。もちろん、コピペもあるんですが、手入力を必要にすることで、意図的にセキュリティレベルを高めることもあるかもしれません。そのとき、印刷状況によって、数字の「１」と「小文字のL」の見分けがつかなかったりということが発生します。もちろん、フォントの工夫と、アルファベットおよび数字などの使用している文字をサンプルとして印刷するということで対処する場合もあるかもしれません。

ここで、いっそのこと、間違えやすい文字列はもともと含めないでアカウントやパスワードを作るのがいいのではないかとも言えます。とはいえ、「間違いやすい」というのもちょっと曖昧な定義です。ご意見をいただければと思います。なお、ここでは記号類、全角文字は排除されているものとします。

数字＋アルファベット大文字

• 0 O（見栄えが似ている）
• 1 I（見栄えが似ている）
• Q 9（発音が似ている）

数字＋アルファベット大文字小文字

• 1 l i j（見栄えが似ている）
• 6 b（見栄えが似ている）
• 0 O o（見栄えが似ている）
• Q 9 q（発音が似ている）
• C c（見栄えが似ている）
• K k（見栄えが似ている）
• S s（見栄えが似ている）
• V v（見栄えが似ている）
• W w（見栄えが似ている）
• X x（見栄えが似ている）
• Z z（見栄えが似ている）

Zとzを間違えるかというと、微妙かもしれませんが、ありそうなことを排除することを考えています。フォントに寄っては、Zとzは区別しずらい、あるいは間違えやすいことはあるだろうということです。それでも、Tとtは区別はつくだろうとうことでリストには入れていません。

Qと9の区別は、日本語だけだろうということもあります。また、大文字と小文字の違いがある場合には発音だけでは判定できません。音声でコードを伝える必要がある場合は、アルファベットは大文字か小文字かのいずれかだけにしないといけないでしょう。どちらを使うかは、使用するシステムに依存すると思います。

上記のルールを適用して間違えやすい文字列を排除すると、使える文字列はこうなります。

数字＋アルファベット大文字（30文字）

•  2345678ABCDEFGHJKLMNPRSTUVWXYZ

数字＋アルファベット大文字小文字（3735文字）

•  234578ABDEFGHJLMNPRTUYadefghmnprtuy

以前、クーポンコードのようなものを考えたとき、その手入力が必要としたらどうなるかを考えました。その仕様がどうだったかはどうでもいいので、現状での記述に揃えます。ただ、ランダムに作るというよりも、生成した乱数をビットに分離すれば、変換はやりやすいと考えました。つまり、base64の原理です。4ビット16文字なら16進表現の方がいいでしょう。6ビット64文字にするには、上記のいずれのパターンも足りません。そこで、5ビット32文字で考えます。「数字＋アルファベット大文字小文字」をもとに、さらに微妙に間違いが発生しないかと考えられる以下の53文字を排除するとします。

• m n r（お互いにデザインが類似している）
• u y （大文字のデザインにそこそこ近い）

こうして残ったのが以下の32文字、つまり5ビットです。5ビット分ずつ、以下の文字列に置き換えれば、乱数からそのエンコード表現ができあがり、手入力時に間違いやすい文字列が排除されているということになります。

数字＋アルファベット大文字小文字（32文字）

• 234578ABDEFGHJLMNPRTUYadefghprty

こんなことまで考えて、クーポンシステムを作ったのに、全然使われなかった…。まあ、それは仕方ないとして、別件でランダムパスワードの生成が必要になったので、思い出してブログにまとめました。

日本でもiBooksが開始されました。けっこう時間がかかったという気がしますが、iPadが出た頃の盛り上がりの期待ほどでもないという点からは、時間がかかってサービスが立ち上がったところで誰も損はしていないのかもしれません。

さて、電子出版と言ったときにいろいろなコンテンツが考えられますが、やはり、既存の書籍や雑誌等の紙媒体と同等なコンテンツというのが1つの大きなジャンルになるのは疑いもない事実です。今回は、従来型書籍の電子化において、どうしてタイトルが増えないのかという点についての1つの見方を書きます。とはいえ、今現在はかなり増えていると思いますが、「元年」と言われて２年くらいはほんとにコンテンツが増えませんでした。もちろん、リーダや販売方法などといった、技術的な問題やインフラの問題もあり、そこは多くの人の興味がそそられるところでしょう。しかしながら、契約の問題はあまり深入りされることもなく過ごされています。

紙の書籍を出版すると、筆者と出版社はいわゆる「出版契約」という契約を結びます。正しくは、執筆前に契約するのですが、まあ、そういう事例はほとんどなく、通常は筆者が書き終わって出版するまでの間に取り交わします。文面に、「原稿をいついつまでに作成し…」などと寒い条項があるのは気にせずに進めます（大笑）。また、契約を結ばなくても、一般的な出版契約が結ばれたとみなされる点についても、かなり以前に裁判があって確定しているというのを聞いた事があります。借地権みたいなルールがあるのです。その契約書は、多くの出版社は、日本書籍出版協会のヒナ型を使っています。出版に興味のある方は、ぜひともこの契約を読んでください。最近では、電子出版に対応したバージョンもあります。

この出版契約で微調整するとしたら、印税などのお金の部分と、日時といった時間的要素だけでしょう。他の部分を調整したことを聞いた事はありません。その結果、出版権という権利が出版社に設定され、出版に関する権利を独占的に有することになります。筆者、つまり著作権者は著作物なのに自分で任意の方法で公開する事は契約上できなくなります。契約上の文言は時代とともに変化していますが、独占的な権利を持つという点はずっと同じです。

以前だと、出版物の流通経路は、出版社から書店に至るものしかなかったので、独占契約をしても、他のルートがあったわけではありません。もっとも、A社よりB社の方がたくさん売ってくれそうだとか、A社の担当者と喧嘩しておざなりにされたので別の出版社に変わりたいと言っても、そう簡単には出版した本の出版社は変更できるものではありません。私の経験でも、版元の会社が解散するので別の会社から改訂版を出すようなこと少しありましたが、これはレアケースでしょう。

結果的に、紙の出版物は、出版社が電子出版化することを決定しない限りは、電子出版として出回らないのです。筆者がどんなに希望しても、出版社の決定がなされないといけません。もっとも、出版社に多大な利益をもたらす筆者の場合はそれなりに意見は通るかもしれませんが、それはごく一部の話です。大多数は関係ないという感じです。出版社も電子出版に乗り気ですが、口を揃えて言うのが「電子出版は売れない」という話です。この話は回を改めますが、安定したビジネスの枠組みから出られない出版社ほど、電子化しないということになるわけです。たぶん、この３年ほどで、出版社を中心とした出版界の枠を出てしまった人は決して少なくはありません。その理由は、電子出版に対して消極的な態度を見せた出版社に対する不満が大きいと思います。契約で権利を保持するのはもちろん必要なことですが、独占権を持ちつつ権利を行使しないというのが、現在限られたコンテンツしか電子書籍になっていない状況を生み出しているのです。

ちなみに、出版権は、一般には書籍を廃版にすると消滅されることになりますが、契約の解除をしないと、いつまでも出版社に権利は残ります。私は何度か解除の依頼を出した事がありますが、交渉とか何もなく、即座に対応してくれました。出版社に取っては廃版となると一切お金にならないものは持っていても仕方ないですもんね。でも、在庫が山積みになっていると、なかなか廃版にはなりません。資産の破棄となり、そこで損失が発生するので、実は、廃版というのは会計的な意味でも大変なことなのです。

契約と言えば、私はいくつかの書籍で、珍しく出版前に契約をしたことがあります。がんばって、決められた日付までに原稿を提出して、そこから出版されたのは半年以上経過していました。契約書では、提出後3ヶ月くらいの期間で出版社は発刊するという文言があったのです。ちょっと釈然としないのですが、紳士的に「どうなってんの？」と問い合わせて返ってきた答えがこれまた絶妙でした。原稿の受け取り日は、出版社が自由に決められると言ってきました。つまり、私が書き終わって提出した日ではなく、出版社がさて編集始めるかと決めた日が「受取日」になるというものです。契約と言ってもいい加減なものです。まあ、この出版社はあまりいい末路でもなかったのですが、こういう経緯があっただけに、申し訳ないですが、同情する気にはなれませんでした。

要注意キーワード：　みたいな感じ

想定される問題：

• 類似させたい個所と、異なる結果にしたい個所が、正しく伝わらない可能性がある。
• 良かった点、悪かった点が何なのか明確にならない可能性がある。

用例：

1. トップページはアマゾンみたいな感じでお願いします。
2. この前やったプレゼン、プロみたいな感じだったね。
3. 素人みたいな感じのデザインで、どうかな？

キーワードが発生する要因：

• 例を示しつつも、その通りではないということをほのめかしている。
• 的確な表現が見つからない。対象となるものを全体的に評価しているが、詳細な点についての意図や評価基準を持っていない。
• ネガティブな用例においては、湾曲表現、あるいは、意味をやや薄めた言い方であり、受け取り様によってはなんとでも解釈できる言い方をすることで、あつれきや問題視を避けようとしている。

会話でよく使われる「みたいな感じ」は、話のきっかけとして、大枠と方向性を示すには非常に有効である。しかしながら、「○○みたいな感じ」というのが最終的な目標や要望であるとすると、○○の何を継承し、なにを変更するのかという点は不明確なままになる。そのため、この表現が出た場合、具体的なポイントとして、何を意図しているのかを詳細に問いただす必要がある。

＝＝＝＝＝＝＝＝＝＝＝

…とまあ、パターンを考えながら、パターンのパターンを探っている、みたいな感じでw