3507. PS5 ナウ

　本日は午前出張のみでした。なのでいつものように昼食と称して職場近所の量販店へ。
　PS5の抽選販売をやっていました。昨日行ったところではいわゆるゲリラ販売で、やはりというか目の前で売れていたようです。もう少しなんとかして欲しいとは思うものの、順調に推移はしているようです。任天堂スイッチも順調に販売中でした。

　PSNの私のフレの状況では、PS4でオンラインが相変わらず主流です。以前と比べて特に変化はありません。要は今のところのPS5はPS4 pro^2の感じです。
　ゲーム機の推移が地味なためか、ゲームショウ関係の話題がちっとも出てきません。世界情勢がぐぐっと変化中なので、エンタメ系は後回しの感じがします。

　PS5本体はマイナーチェンジがあったそうです。内部が少し簡素化されたとか。次のアップバージョンは外見が変わって中身は簡略化でしょうから、意外と今が購入チャンスだと思います。
　PS storeでなぜかVR特集をやっていて、多分観測気球でしょうけどVR路線を継続する選択肢は生きているようです。今の状況を見ていると、大型スピーカ対ヘッドホンみたいな感じで、本来はホームシアターが欲しいけれど次の選択肢としてVRが来る感じです。
　量販店では8Kテレビは相変わらず売られていて、しかしまだまだ主流は4Kです。8Kは探さないといけないくらいに地味な扱いになってきました。遠くから見るとあまり変わらないからだと思います。私の感覚もそうで、近づいて薄らでかい4Kとの印象は今まで通りです。

　地味と言えばPS nowのPS3ソフトがゆっくりと増えています。こちらは私の環境では相変わらずゲームのゴールデンタイムにはまともに繋がらないので、今後どうするのかな、の感じ。余裕があればPS5だとPS3のエミュレータが動きそうな気がするので(あくまで私の感触)、こちらのダウンロード版が出るかどうかが一つの関心事で、もう一つは繰り返しで申し訳ないですが、PS1とvita(とPSP)のアーカイブがどうなってしまうのか、です。

3506. データベース、続き^15

　以上が私が考えているデータベース、なるものです。
　プログラム初級者にはきついと思いますが、ある程度出来る方には、特にUNIXとかWindowsのOS部をある程度知っている方だと、もしかしたらこつこつと組み立てれば自分にも作れる、の範囲だと思います。

　実際、TRONとか自動車以前の時代に日米貿易摩擦のネタになりそうになったことがあるそうです。DBMS、データベース・マネージメント・システムで。しかし、そのときはあまりにあっさりと早期に日本が完敗したので関係者以外には話題にはなりませんでした。もちろん、今もその状態が続いています。

　この手の小型システムは時に必要なので、私の観察では企業の片隅で、特に製造部門などでひっそりと活躍しているみたいです。いわゆる個人用データベースでは無理で、もう少し本格的なシステムでないといけません。

　実は私、20年ほど前に仕事上の決断が必要になったことがあって、本当に幸いなことに今の仕事(本来の私の専門分野)が見つかったから無難に済んでいますが、そうで無かった場合のことも考え、この手のデータベースシステムで食っていこうかと考えたことがあります。
　大手のシステムサービス企業(皆さんよくご存じの企業群)とかち合うとろくなことは無いので、○○会計システムとか外見は地味な名前にして、中身は前項までの解説で分かるようにBASICを少し拡張した感じで、その部分は社内での扱いにして、応用製品(ソフトとハード、つまりシステム)だけを売る商売です。熱心な顧客にはそのBASIC部分も開示しますが、もちろんソースプログラムは秘密。というかそのソースを見ても上述の説明で分かるように既知の技術しか使ってないから、ばれても平気。

　まあ、今の私のソフトウェアに対する関心とは微妙にずれているので、多分もう機会は無いと思います。今の私に時間と意欲があったら、並列論理型プログラミング言語の方向に行っているはず。…んと、それとデータベースは矛盾しないか。

3505. データベース、続き^14

　本シリーズを見返してみたら、ガイドラインとは何かの説明が必要な気がしてきましたが、本編をさっさと仕上げます。

　値 = テーブル名(キーワード)

　の関数表現でデータベースを説明してきました。しかしこれだとRDBではたった2欄で、左がキーワードの列、右がその値の列、の感じです。いや、このような対応表は珍しくは無く、確実に役立ちます。しかし、何か物足りない。

　例えば部品表だったら、キーワードが部品番号で、値の方は名称、大きさ、重さ、用途などと続くはずです。RDBだと欄を右に増やしてゆきます。
　階層型データベースでは、第二のキーワードを設けて、項目名を入れます。

　値 = テーブル名(部品番号、項目名)

　の感じです。もちろん項目名も管理されているはずで、項目名が筆頭のキーワードの表が他にあるはずです。そう、キーワードが2個となります。改めて書くと、

　値 = テーブル名(キーワード1、キーワード2)

　となります。RDBだとインデックスを2欄に渡って付ける感じです。

　かつての私の上司の観察だと、取引のデータは、

　値 = テーブル名(取引先番号、日付、項目名)

　の3段階で、いろいろ試してみたが、この順が決定版だそうです。ううむ、有料記事みたいな核心情報ですが、これだけだと多分訳分からないので公開しました。なので細かい説明は省略します。

　キーワードにしても値にしても、前項の区切り文字の表記を使えば、最初に上げた単純な対応表で表せると思います。階層にするのはプログラムが書きやすくなる、言い換えると見通しが良くなって他の人にもよく分かる、くらいの意味です。軽くは無いですが。

　意外に大切なことを私は言いました。二分探索表ならキーワードは階層を持っていようとフラットな表になります。ということは、ISAMの多進木の木構造はハード的な構造であって、必ずしもデータベースの論理的階層とは対応しません。この意味で、Btreeは高度に抽象的な構造です。

　排他制御も決定版は無く、しかしこれらの経験的な複雑なデータ構造が現在の我々の生活を支えています。私としてはもう少し計算機科学の理論的背景が欲しいところです。

3504. データベース、続き^13

　データベースの中身のデータは一般の文字列です。文字列と言っても、アルファベットや数字や漢字が並んでいるのも文字列ですが、習慣的にコンピュータでは単なるオクテット列も文字列と言います。

　オクテット、つまり8bitの全パターン(0～255)が特定の個数並んだものなので、画像も音声も、およそコンピュータで扱える対象は何でも入れることが出来ます、原則として。

　初期の8bitコンピュータの時代はASCII 94文字が扱えればそれでよく、8bitだと256文字が使えますから余っている部分にカタカナなどを割り振っていました。
　今でも電子部品店などで売られている簡易な5x7ドット白黒、16文字×2行などの液晶ディスプレイの制御ICはこうなっています。コードの最初の8文字とか16文字は文字が任意にプログラミングできて、ごく簡単なゲーム(たとえば迷路脱出ゲームとか)なら組めます。

　しかし今は漢字仮名交じり文が英文などと混ぜて表示できないと話になりません。なので、こちらの「文字列」も快適に操作できる必要があります。つまり、オクテット列の操作は別途、残しておいて欲しいです。
　私が好みなのはそのごく初期のマイクロソフトBASICマシンの文字列の扱いです。ただし、上述の1バイト＝1文字の場合の話。今も引き継がれているのは多分Visual Basicと、普通の表計算ソフトです。まあぶっちゃけ、私は今の表計算ソフトの数値型とか文字列型の扱いが至高だと思っている訳。

　そのマイクロソフトBASICの文字列演算の筆頭は文字列の結合です。

　C$ = A$ + B$

　ここでA$は文字列型の変数で、$が文字列を表す記号です。中身は「abd」とかで、ブログラム中に書く場合は"abd"とダブルクォートで囲みます。
　演算子(上述の「+」みたいなの)の残りは比較演算子で、

　A$ = B$

　が真偽値(1か0)を取ります。なぜかそのBASICでは真値は1ではなく-1でした。0以外はすべて真の扱いです。アルファベット順というかコード順の大小があって、

　A$ < B$

　も真偽値を返します。

　関数の筆頭はもちろん文字数。

　文字数 = LEN(A$)

　部分文字列、LEFT$、MID$、RIGHT$はほぼ想像通りのはずです。

　文字とコードの変換関数は時に必要です。

　文字 = CHR$(コード)
　コード = ASC(文字)

　似て非なるものが数値と文字列の変換、

　数値 = VAL(文字列)
　文字列 = STR$(数値)

　文字列内の検索は普通は用意されています。

　文字位置 = INSTR(文字列1, 文字列2)
　検索する位置を指定することが出来て、
　文字位置 = INSTR(開始位置、文字列1, 文字列2)

　このINSTRの動作は知っている方には自明ですが、説明は長くなるのでweb検索してみてください。

　BASICではほぼ以上です。C言語でも似たようなものです。
　しかし、データベースがらみでは、以下の2個の要素の追加が必要と思います。

　一つはトークンの扱い。なに、これは簡単です。区切り文字で区切られた文字列、たとえば、

　"abc;def;ghijk;lmn"

　があった場合に、1番目の要素が「abc」、3番目の要素が「ghijk」と取り扱う規約です。このabcとかdefをトークンと言います。元は計算機言語の概念で、+や=もトークンですし、1.23やifやwhileもトークンです。これでなんとなく納得してください、お願いします。

　このトークンの単位を文字列の文字と同様の扱いをして、抽出や挿入の操作の関数を用意します。

　残る一つは、文字列のパターンマッチングです。一般用語は正規表現です。しかし、実用的には文字列「2021/08/28」などが日付として認識できればよく、もう少し簡単にできると思います。

　ふむ、文字列の計算機での扱い、と言っても意外にたくさん説明事項がありました。科学技術計算ではほとんど問題にならないので、コンピュータの説明ではあっさりと紹介されているだけだと思います。
　しかし、データベースでは文字列処理は基本中の基本なので、真剣に取り扱う必要があります。

3503. 真の誕生日

　明日、8月29日はアイドルマスターの仮想アイドルの一人、菊地真の誕生日だそうです。いつものようにPS4のアイマスゲーム、ステラステージに有志Pがお祝いのPVを上げるはずです。

3502. データベース、続き^12

　データ数が少ない場合は二分探索表、多い場合、あるいは挿入・削除が頻繁な場合は赤黒木で、しかしプログラムから見た操作の関数は同じになります。

　まず、検索は、

　値 = テーブル名(キーワード)

　の形で、キーワードと値は文字列型と考えれば良いです。ダイレクトにこう書けるシステムもありますが、とりあえず概念的なものと考えてください。
　そのテーブル(表)にキーワードが無かった場合、つまり空振りの場合はエラーでは無く、特別な値を返すか、別の特殊変数(大域変数)にエラー値を代入した方が便利です。

　データの挿入は、

　insert(テーブル名(キーワード), 値)

　みたいな感じ。すでにデータがあった場合は、前の値が削除、つまり上書きとなる方が便利と思います。

　削除は、

　delete(テーブル名(キーワード))

　となります。SQLというデータベース操作言語を知っている方は、似たような書き方があるのを覚えていると思います。

　キーワードは大小順に並んでいるので、一つ次と一つ前のキーワードを返す関数が欲しくなります。

　キーワード2 = next(テーブル名(キーワード1))
　キーワード2 = previous(テーブル名(キーワード1))

　このとき、テーブル名(キーワード1)がヒットしなくてもその次に大きい(小さい)キーワードが返ってくると便利です。というか、わざわざ順に並べたのはこれをやりたかった、というのもあります。RDBではデータへのポインタみたいなカーソルと言う概念があって、それを使います。

　ここからは単なるデータ型とデータベースのテーブルの違いで、最大のものはロック機構だと思います。

　lock(テーブル名)　または　lock(テーブル名(キーワード))
　unlock(テーブル名)　または　unlock(テーブル名(キーワード))

　ロックについては、微妙にいろいろ種類があるので、調べると面白いです。要するに、あるユーザーが使っている間は別のユーザーは操作できない仕組みが必要です。これをやって初めてデータベースとしての整合性が取れます。

　データベースシステムとしてはテーブルのバックアップと障害復旧の仕組みが必要です。これもシステムによってまちまちだと思います。

　後は通信で、昔はRS-232Cで、今はイーサネットで繋ぐことが多いと思います。リモートで上記の関数が呼べるようにします。この場合、接続先で動作するプログラムが必要で、デーモンと呼ばれます。もちろん、これの管理もデータベースシステムの仕事。ほぼOSと同様の大規模システムになってしまうのは容易に想像できると思います。

　基本的なところはこんなものと思います。後は応用上の取り扱いの話になります。

3501. 一息

　ふう。本日は久しぶりに普通の勤務日の感じでした。このところずっと一日出張が続いていて、それとなぜか新型コロナウイルス感染症対策の職域接種の会場にかり出されて、結構てんてこ舞いでした。
　なので、たまっていた内部的仕事の一部をやっつけ、久しぶりに昼食と称して職場近所の量販店にお出かけしました。必要な買い物があったし。

　その買い物のために安売りショップへ行ったらなぜかものすごく安いマウスが売られていたので購入。というのも、使っていたマウスの動作がやや怪しくなっていたので買い換えのチャンスを狙っていたからです。
　しかし、あまりに安い。無論、やや難ありの感じはしますが、普通に使う分には使える感じです。まさかマルウェア入りとかの落ちは無いと思います。使っているパソコンには普通にアンチウイルスソフトを入れてますし。

　この感じはPC-AT互換機が広まってから、日本ではDOS/Vの時代からと思います。それまではパソコン本体と周辺機器には信頼性と継続性が求められていたと思います。しかし、PC-AT互換機では作り逃げしても許される雰囲気があります。無くなったら別の代替品がいくらでもありますから。
　20年くらい前はそのような新興の聞いたことも無いようなメーカーの部品とか中古品を扱うDOS/Vショップが元気でした。今はすっかり落ち着いてしまって、普通の量販店の感じで、最低限の品質は保証されている感じがします。
　なので少し昔を思い出した訳。

3500. データベース、続き^11

　内容的にはほぼその筋のプロ向きのレベルになってしまいました。ここまで来たのですから、もう少しだけお付き合いください。データ形式としてはあと一歩の位置にいます。

　二分探索表の探索の様子を「数学的」(?)に表すと二分探索木になります。「木」は数学ではトポロジーの話題として有効であり、計算機科学でアルゴリズムを表現する場合にも使います。
　木(tree)は「節(node: ノード)」を「枝(branch: ブランチ)」で結んだもので、ループが無く、全部が繋がっているものを指します。数学の木はこれだけ。
　計算機科学では、「根」と呼ばれる1個の節が最上位に配置され、二分探索木だと下方向に左右に分かれて次の節があり、最後はその下への枝分かれが無い節で「葉」と呼ばれます。
　二分探索表では整列した配列の中間を真っ先に調査します。ですから二分探索木ではこの配列の要素が根の節で、ここから探索が出発です。もしも目標より節の値が大きければ左の枝を選び、小さければ右に進みます。当たれば(等しければ)、そこで終了です。

　ですから、各節には以下の4個のデータが入っています。

　[ キーワード : 値 : 左の節へのポインタ : 右の節へのポインタ ] 

　ポインタは主メモリのアドレスとほぼ同義で、ただし型の情報が付属しています。この場合はポインタの先のデータ型は他の節です。
　葉の場合はポインタの値は「無」つまりヌル値、具体的には0とか-1とかにします。ポインタの片方だけが無の場合は当然あります。

　二分探索表の場合は、データの挿入と削除では位置を探し、操作後は後半のデータを一つずつ後ろに移動させたり前に移動させる必要があり、データが多ければ時間がかかります。
　ポインタを使って木構造にすれば、局所的な構造を変更するだけで済むので、挿入と削除の操作が高速になります。

　しかし、挿入と削除の素朴な操作だけでは木は次第にバランスを崩して、根からの距離が短いデータと長いデータが二分探索木に比べると極端に違ってゆきます。
　ここは言葉ではなかなか説明しづらく、アニメーションを作ると面白いです。

　バランスを取り戻すには木の構造を変更します。回転と呼ばれる操作で、具体的には「赤黒木」と呼ばれるバランス木をweb検索すると出てくると思います。この赤黒木はバランスを保ちながら検索・挿入・削除がどれもほどよく高速な、傑出したアルゴリズムです。
　この赤黒木は、実質的に二分探索木では無く、多進木と解釈できます。赤黒木の場合は2方向だけで無く、3方向と4方向へ枝分かれしていて、2-3-4木と呼ばれます。
　このようなデータの探索と操作、つまり挿入・削除に適した多進木をBtreeと総称します。

　歴史的には多分逆で、ハードディスクでの検索と操作の高速化の方法を探していたら多進木に到達し、その中で赤黒木の性能が突出していた、だと思います。
　この赤黒木のアルゴリズムは結構複雑で、これが操作上は単純な二分探索表と同等なのは意外ですし、理解するにはかなりの時間がかかると思います。こちらもアニメーションにすると面白いと思います。

3499. データベース、続き^10

　データベースのデータは、通常、キーワード順に並んでいます。

　たとえば日誌は日付順に棚に置くのが普通で、そうしないといちいち端から端まで探さないと目的の日誌に到達できません。
　日付は並べ順がはっきりしています。しかし、一般的な分類の順序は一意とは限りません。

　たとえば図書館の図書の順番は図書館共通のカテゴリ順に並んでいます。カテゴリ内では多分、手に入れた順番に下位の一連番号を付けます。関連図書が近くにある、ということ。
　しかし、こちらの場合は、どう分類しても同様の書籍が分散してしまいます。たとえば統計学の本は私の経験では図書館の3カ所くらいを見ないと目的の文献が見つからなかったと思います。とはいえ、分類していないと3カ所どころか全部見ないといけなくなります。

　辞書の見出し語と同じく、キーワードには順番がある、ということ。普通は数値順かアルファベット順(50音順)にします。数学で言えば全順序集合です。2個の要素は等しいか、どちらかが小で他方が大、に必ずなります(不定は無い)。さらに離散集合で、一つ次の要素、一つ前の要素があり、順番に全データをたぐることが出来ます。日付みたいに母集団(?)は無限集合でも、棚にある(標本の)資料の日付は有限集合です。

　これらを満たすデータ型が必要です。

　データ数が少ない場合は、二分探索表が簡単・便利です。文字列型の配列を用意し、キーワードを小さい方から順番に並べておきます。キーワードを検索するときは、配列のちょうど中央のデータと比べて、当たったらおしまい。外れたら大小に応じて上下(左右)の区画を同様に中央のデータと比べます。
　対応する値の配列を別途用意すればデータベースの検索風になりますし、最初から項目が2個の配列で「キーワード : 値」と並べても良いでしょう。文字列なら区切り文字「:」などでその前半をキーワードとする、と決めてもOKです。

　順番に並べておくのがミソで、完全に当たらなくても関連項目が近くにある、ということ。日付などだとある範囲のデータを集めよ、という使い方ができます。

　単に検索だけならハッシュ表、という形式がより(ずっと)高速です。しかし、ハッシュ表には次に大きなキーワード、という概念はありません。
　ハッシュ表にはハッシュ値の衝突の解決手段が必要ですから、データ数が少なければ検索が単純な二分探索表で十分に高速です。
　やってみると分かりますが、文字列処理などで二分探索表のサブルーチン集を用意しておくとあまりに便利なのでやみつきになります。

　これを巨大なファイルに対しても同様に使いたい。これの解決がISAMファイルで、キーワードはBtreeと呼ばれる構造で実現します。わざわざ名前が付いている位で、実現は単純では無く、アルゴリズムとしては複雑な方に入ると思います。

3498. データベース、続き^9

　ふう、やっと本題に入ります。前座が長かったですが、多分、必要だったと思います。
　いきなりデータベースのテーブルの設計の話に入ったところで、いやまて、なぜそんなものが必要なのだ、普通のファイルではいけないのか、そもそも何の役に立つのか、データって何だ、などの質問が殺到して、全く先に進めないと思います。

　ファイル形式というかデータ型としてのデータベースは珍しいものでは無く、たとえばWindows NT (今のWindows 10を含む)の元となったDEC社のVAX/VMSではISAMファイル形式が標準で装備されていました。これにいわゆるロック機構(排他制御)を追加すればデータベースのテーブルになります。
　なぜかWindows NTになったときにファイル形式のISAMは省かれてしまいました。

　少し昔にはオフィススイートに個人用データベース、MS Accessとかが用意されていたので結構遊べましたが、今はなぜか省かれています。特にAccessはデータサーバーのデータベースのテーブルに直接接続できるので重宝していました。その代わりなのか、表の一覧くらいは出来るユーティリティが配布されていましたが、今はあるのかどうか。

　そう、表(テーブル)。今は表計算ソフトを個人用データベースとしても使う感じがします。かつては表計算ソフトの縦は256行とか、その後も8192行程度だったのでデータベースには物足りないです。しかし今は軽く10万行とか扱えるので(ついでに横方向もやけくそなくらい取れる)、おそらくこちらをデータベースの代わりに使っていると思います。
　大企業のデータベースでもテーブル単位だと10万件を超えるのは数えるほどしか無いと思います。
　さっき調べたら表計算ソフトでもQBE(query by example)と呼ばれる問い合わせが関数として用意されているようです。しかし、データベースとして使えるかどうか試したことはありません。

　ということで、本来ならばMS Accessなどを練習台にするつもりでしたが、現状で個人的に遊べるデータベースソフトがすぐには見つからないので、以後、概念的な話になってしまいます。
　私に暇とやる気があれば学習用の簡易データベースシステムを作っているところですが、もちろん暇はありません。読者には申し訳ないです。

3497. 休日

　本日は日曜日。今年は7月中旬から多忙で、やっと一息付けました。この歳になると土日では疲労回復(とルーチンの家事)がやっとで、他のことが出来ません。本日は近くのDIYセンターに行って必要な買い物ができました。

　国際情勢でいろいろあるようです。アフガニスタンから米軍が撤退したとのことで、多分、ここ10年くらいの中東の世界に対する影響の低下の一環だと思います。
　自動車の半導体不足の話題で出てきた国名がベトナムとマレーシアでした。新型コロナウイルス感染症に関係するそうです。40年ほど前はマレーシア、フィリピン、インドネシアなどの刻印のあるICをよく見かけましたから、今も東南アジアが供給源になっているみたいです。

　PS5のシステムソフトウェアを新版のベータ版にしました。先月末にメールで知らせが来ていたのですが、忙しくてなかなか実行できませんでした。特に不具合などは無く、少し画面が綺麗になったかな、の感想です。内蔵SSDの追加が出来るそうですけど、まだ試していません。こちらはきっかけが必要です。
　で、それと関連するのか、久しぶりにフレの一人がPS5でオンラインになっていました。あと2人がPS5を持っているはずですが、一人はあまりオンラインにならず、もう一人はなぜかPS4を使い続けているようです。

　PS3の時を振り返ると、発売が2006年だそうで、私の家ではPS2はありましたがあまり買う気にならず、結局FF13の出た2009年に家族用のを買って、翌年私個人用のを買って、アイドルマスター2はそのまた翌年です。
　発売3年後ですから最初のフルモデルチェンジ後です。PS4の時も最初の1年ほど、つまりブラッドボーンとメタルギアソリッド・ファントムペインが出る以前はどうなることかと思えるくらい地味でしたから、まだぱっとしないのは分かります。
　が、品不足感はどうにかしてほしいです。今も抽選販売していますけど、確率論的には外れを重ねる人が必ず少数出てくるので、長期的には不公平感が出てきます。そろそろ、というか早急になんとかすべきと思います。

3496. データベース、続き^8

　日本では漢字でデータベースが検索できる必要があり、コード化は必須です。ところが、大型機では各社各様にコードを振ってしまいました。

　1978年にJIS漢字コードが制定され、これは非常にタイミングが良くてパソコンではコードの混乱は(ほぼ)起こりませんでした。ただし、DOS/V系のパソコンの内部コードはいわゆるシフトJIS (MS漢字コード)で、これがファイルとして流通してしまって、こちらはJIS規格ではありません。UNIXのEUCはほぼJIS準拠ですが、UNIX以外ではマイナーと思います。

　現在はユニコードの時代で、普通のwebページはおそらくこちらになっていると思います。ワープロもユニコードが扱えて便利になりました。
　ところがユニコードの方は通信規格がいっぱいあって、私はUTF-8で十分と思っていましたから意外でした。
　このブログの文章を打っているエディタはもちろんユニコードが扱えますが、実は私はMS漢字コードを使い続けています。このJIS第一水準・第二水準の範囲では表示が変になる心配はほとんど無いからです。現在でもユニコードの数学記号の扱いはやや雑と思います。

　いずれもASCII 94文字の範囲は共通です。ですから最後の手段としてはここに落とし込めば、まず間違いなく通信が成り立ちます。
　漢字はシフトJISでもEUCでも2バイトとなり、初期のワープロの文字表示は固定幅なので律儀に漢字はアルファベットの2倍の幅があって、半角・全角と呼ばれました。今も日本語キーボードにこの用語が残っています。

　当然ですが、データベースの検索には1文字が1文字として扱われる必要があります。しかし、習慣的にC言語などの計算機言語の文字列はオクテット列を指すので、1文字を1文字として扱うだけでテクニックが必要となります。まあ、普通はコードを決めればビットパターンが決まりますから、キーワード自体は決まります。問題は連結とか削除とかの操作時です。

　漢字の扱いについてはほぼ上記で網羅されていると思います((処理時の)内部コード、ファイル形式、通信規約)。細かいことを言い出せばきりがありません。日本だけで無くヨーロッパなどでも計算機での文字の扱いはデリケートな問題と思います。

3495. データベース、続き^7

　日本語の文章に漢字は必須なので、パソコン初期の頃は大型機も含めて漢字の取り扱いにかなり注力されていたと思います。
　お役所の記録文書では、丁寧な手書きと電子化の間に和文タイプライターの時代があったようです。これはアルファベット圏のタイプライタとは似ても似つかない形をしています。文字盤から縦横に動くハンドルで漢字を選んで押下すると、活字がピックアップされて、こちらは普通のタイプライタみたいな左右に動くロールに挟まれたA4などの用紙にインクをしみこませたリボンを挟んで叩きます。
　西洋の初期の手探り時代のタイプライタにも同じ感じのがあったと思いますが、漢字の字数の都合上、我が国では日本語ワードプロセッサが出現する前はどうにもこうにもの状態だったと思います。

　小学校のテストのプリントなどはどうしていたかというと、ガリ版印刷です。さっき調べたら、なんとアメリカの発明王、エジソン氏の発明らしいです。当然、私もガリった経験があります。
　これの応用が一時期は年賀状の年中行事となったプリントゴッコで、光学反応(熱だったかも)でメッシュ上の樹脂を蒸発させてガリ版同様のスクリーンを作っていました。コピー機のような外見のものもあって、スクリーンを作ると後は印刷なのでコスト削減になるとのことで一時期流行しました。しかし、今はゼロックス方式のコピー機しか見かけません。レーザープリンタも印刷の原理はゼロックス方式と思います。

　まあ、血のにじむような開発競争の結果、家庭用ではインクジェット、小売店などでは感熱紙、預金通帳などはドットインパクト、通常業務用はレーザープリンタ、と棲み分けが完了している感じです。
　印刷技術は現在も普通に行われていて、しかし活版印刷はほぼ無くなったと思います。仕上がりを見るととても凸版とか凹版とかではないので、おそらく主流はオフセット印刷と思います。新聞なんかどうしているのかな。私の少年時代は活版印刷(凸版)でしたから紙面に印字に対応するわずかな凸凹があって、インクの香りとともに新聞らしさ、と言うのがありました。

　ううむ、電子計算機のデータベースの話とは思えない感じになってきましたが、さらに続くかもしれません。

3494. データベース、続き^6

　文字列型に関しては、私は初期のパソコンBASICのやり方が気に入っています。おそらく今のVisual BASICでも同様。表計算ソフトでも文字列は単純型扱いです。
　現在の計算機で文字列という場合は普通は8bitの列を指します。バイトとかオクテットと呼ばれるものが単位で、それを系列として並べたものです。

　C言語などの普通の計算機言語はASCII 94文字(コード33～コード126)で記述できるように設計されます。数字とアルファベットとハイフンやピリオドなどの若干の記号です。現在は大型機のEBCDICはほぼ考えなくて良いので、これでもかなり楽になりました。
　ASCIIではコード0～31とコード127は特別で、改行などの制御文字です。コード127はあまりまともな解説を見たことはないのですが、私の感触では紙テープで打ち間違えたときに位置を一つ戻して穴を全部に空けて無かったことにする、と言う意味の抹消です。
　コード32の空白は印字文字と制御文字の両方の性格を持つ唯一の文字です。
　これでコード0～127の7bitが埋められます。

　紙テープは5単位から8単位の4種が流通していたそうで、しかし私は8単位のものしか知りません。スプロケットだったか紙送り用の小さな穴の片側に3個の穴があって、その反対側を2穴→5穴と増やしてゆくみたいです。5bitは国際テレックス網の単位だったか。これが世界を変えたはずですが、仮名文字は無くて我が国は完全に蚊帳の外。ASCIIは本来は7bitで、これも通信規約のはずです。8bit目はパリティと言って誤り訂正に使われたはずです。はずですって、さすがにこれも私はよく知りません。

　早いとこ漢字をどう扱うかの話に持って行きたいのですが、まだこの感じがちょっと続くと思います。

3493. データベース、続き^5

　なんだか話が間延びしそうなので、途中で書いている私がつまらないと思った時点で終了すると思います。悪しからず。

　多少議論になりそうなのは文字列型で、これを(計算機の)整数や実数のように単純データ型と見なすのか、配列のような複合データ型と見なすのか。

　私が計算機言語の原点と思っている(初期の) FORTRANでは整数(integer: 32bit符号付き2の補数表現が普通)と実数(real (単精度浮動小数点数) / double precision (倍精度浮動小数点数))が区別されていて、たしかこの頃のFORTRANでは混在が不可能で、混ぜるときは変換関数をプログラマがしっかり書かないとコンパイルの段階でエラーを食らったと思います。
　当時は紙カードに穴をパンチするのがプログラム打ち込みで、結果は翌日などに計算センターからラインプリンタで返されるので、あっさりコンパイラからsyntax errorなどと出力された用紙を見て面食らった…、はずです。いや、さすがに今は老人の私でもこの経験はほとんどありません。
　なので、コンパイラはソースプログラムを解析していって、最初の解析不能バグで報告して停止するのでは無く、そのままコンパイルを続けてバグを総出しするのが普通です。
　通常、括弧の閉じ忘れなどが起こると、その後のプログラムはめちゃくちゃに解釈されてしまうので無駄なプリンタ出力になることが多いですが、この、いいから続けろ方式が好まれます。現在のいわゆる統合開発環境でもそうなってます。

　1970年頃のNHKコンピュータ講座でもすでにオンライン端末を使っていましたから、プログラムにバグがあったら直ちに計算機がその旨を返事します。スタジオで実時間で講師が対応していたはずです。普通はリハーサルで潰されていたようですが、重要でありがちな事態は番組で対処法が紹介されていたと思います。

　つまり、数値型と言っても初期のFORTRAN段階で3つの型が存在します。型(type)は同じ数値、たとえば数値1をメモリ上で表すのに3方式が存在する、ということ。
　この区別は初期のパソコンBASICにはありません。現在の表計算ソフトも数値型は数値型の1種だけです。
　現在のパソコンのCPUは驚愕の高性能なので、万能感のある64bit IEEE浮動小数点数で押し通してもそんなに速度は落ちないと思います(トータルで1/10程度には収まると思う)。なにせ、機械語に浮動小数点数と整数の変換命令があるので、それを使えば万事OKです。

　片や現在逐次実行型コンパイル言語代表のC言語では数値型が沢山あります。主なもので、char、int、doubleの3種です。それぞれ1文字ASCIIコード(0～127)、2の補数の(16/32/64bit)整数、64bit IEEE浮動小数点数です。つまり私は特に必要で無い限りこの3型しか使いません。しかし、派生形が山ほどあって、間の悪いことにCPUによって整数精度が異なったりして、多分、C言語の生産性が悪い感じがする原因の一つがここと思います。

　次回は文字列型の話のつもりですが、予想通り、楽屋落ちの感じの話が続くと思います。あるいは、続きません。