お知らせ

データベースはパソコンからクラウドへ

古くからあるデータベースソフトの一つFileMakerがFileMaker Cloudを発表しました。 AWSにホストを持つクラウド型のFileMaker Serverで、PaaSのように使えるものかと感じます。 オンプレミスのサーバーよりもAWSの高可用性を重要視することと外出先や拠点間でのモバイル利用をつよく意識したもののようです。 PaaS型のクラウドは多くはデータベースのアプリです。 まずプラットフォームとして独自のRDBMSがあり独自のAPIが提供され、その上に様々な業務用アプリケーションを構築して提供しているのが実際の姿です。 SalesforceのSalesCloudもForce.comのプラットフォーム上に構築されたSFAで、ServiceCloudやMarketingCloudなども同じようにプラットフォーム上にアプリケーションとして展開されており、サービスを購入することで連携することができます。またForce.com上で独自のアプリケーションを利用者が構築することもできます。 ZOHOも同様にZOHO CreatorがRDBMSとAPIをユーザーが利用できるようにしたものでZOHO CRMやSales IQなどもそのプラットフォーム上に構築されたものでしょう。 国産のクラウドプラットフォームKintoneはデータベースであることをそのまま使っているように感じます。JavascriptとCSSを利用したカスタマイズやAPIに力を入れているところが上記の2点とは異なっているなと感じるとことです。 データをどう活用するか、これが現在非常に重要となっています。 モバイルプラットフォームからオンプレミスのデータを閲覧するのはいくつかのステップを踏まなければならなく、これがクラウドであれば多くの問題が簡単に解決してしまいます。 現在特に営業支援などはお客様先や外出先での活用が利点になるので多く普及しているものと考えます。 FileMakerがクラウド化したことにより、その他業務、在庫管理や販売管理の分野などでもクラウド化、モバイルプラットフォームの活用などが普及していくように考えています。

データベースの成り立ち

データベースという言葉は、非常に頻繁に聞く言葉です。 OracleやMySQLなど現在主流のデータベースはリレーショナルデータベースと呼ばれる種類のデータベースです。 コンピュータはプログラムがデータを扱う、という仕組みによって動作します。 データは業務のものや、機器を制御するためのデータ、様々なデータを対応するプログラムが扱います。 データはプログラムの内部にあっても良いのですが、プログラム外部にデータを保管することで、追加や変更、他のプログラムからの利用が簡単になります。 そのデータの置き場所がデータベースで、そもそもはデータの先頭から読み出していく順次的なものでした。これをシーケンシャルアクセスと呼びます。 データベースの成り立ちはコンピュータの記録装置の歴史を辿ることになり、ハードディスク、フロッピーディスク以前にオープンリールなどのテープ装置が使われていました。 テープ装置はテープ先頭からの順次の読み出しが基本で、他にプログラムからの制御によって早送り、巻き戻しを行います。 データの保存はデータの最後尾に追加するか、既存のデータの上書きになります。 テープから読み出されたデータはメモリに格納され、プログラムによる処理が行われます。 この方式では処理に時間がかかることと、メモリの制約を受ける範囲内でしかデータは扱えません。 ハードディスクがコンピュータに備えられるようになって、データは自由にどこからでもアクセスできるようになりました。ランダムアクセスと呼びます。 ランダムアクセスによってデータの読み書きの効率は非常に高くなり、ハードディスクによって大量のデータが保管できるようになりました。 そこでデータとデータの間を連結リストなどのアルゴリズムを利用してデータの並び順を作ることで、データベース内のデータを素早く探索できるような仕組みが出来上がりました。これはインデックス(索引)と呼ばれます。 必要なデータを読み出す際、一定の項目によって順番に並んでいる時、バラバラに配置されたデータをすべて読み出して見つけるのとは比較できないぐらいの高速になりえます。 データの探索が高速で効率良くできることによって、二つのデータベースを関連付けるなどの効率が実用的となり、現在一般的に利用されているリレーショナルデータベースが主流となっていきました。 SQLというデータ呼び出し言語が多くのリレーショナルデータベースに付属しています。 それまでは各プログラムがデータを読み出して抽出、加工していたものを、簡易な言語によってデータベース側で実行できるようになりました。 もともとはプログラム側でプログラミング言語によって書かれていたアルゴリズムが、SQLによって簡易に記述できるようになり、データベースを扱う複雑なプログラムが隠蔽されるようになりました。 これにデータの読み出し、書き出しの要求を逐次処理するためのトランザクションも組み込まれて、複数の呼び出しなどにも正確に対応します。 これら機能が集約することにより、リレーショナルデータベース管理システム(RDBMS)は汎用性を持ち、各業務プログラムから独立してデータの読み込み、書き込みを担当するミドルウェアとして活用されています。

ADPからの切り替えを

ソーシャルゲームのこと

今日本では、Wiiやプレイステーションなど据え置き型のゲーム市場よりも、スマートフォンで遊べるパズル＆ドラゴンズのようなソーシャルゲームが大きく売り上げを伸ばしています。 このことについて、積極的に遊んでいる方も、関心がない方も、どちらかといえばよくないと考えておられる方もいるはずです。 よくないと考える方の、よくないと思う理由として、課金を前提とした射幸心を煽るシステムであること、また据え置き型ゲームの衰退を憂う、などの理由があると思います。 たしかに、ヒットすれば開発費用をはるかに上回る売り上げを出せるソーシャルゲームは、日本中の若手エンジニアにとって就きたい業界になっています。 このような状況について筆者の思うところを書いてみたいと思います ソーシャルゲームまでのゲーム 日本のゲーム業界で据え置き型ゲーム機は、古くはカセット、DVD−ROMなど、一本の完結したメディアでのリリースをされていました。 これは開発環境一式をゲーム機メーカーから貸与、あるいは購入し、開発を終えた後にメーカーの審査をうけライセンスを与えられて発売されるというサイクルがありました。 ソーシャルゲームは、スマートフォンの開発ツールとアプリストアの審査基準さえ通過すれば、個人でも始めることのできるものです。 参入障壁の低さもあり、新興の中小企業でもあらたな参入の余地があります。 据え置き型のゲームは一本のメディアの中で完結しているので、ゲーム機の性能に依存し、追加的な要素は与えられないものでした。 現在コンピュータはほとんどがインターネットに接続されていて、インターネット上のサーバーと、ゲームソフトというクライアントに分かれ、オンラインで楽しむ作りが取り入れられています。 ただ、日本は世界的な流行の中で、オンラインゲームについては幾分かの遅れがありました。 世界中のユーザーをターゲットにした大規模なオンラインゲームはとても負荷が高く、障害などを起こさず運用するためには、十分な技術をもった、たくさんのデータベースエンジニアやサーバーエンジニアのチームが必要となります。 運用費で莫大な費用が必要であれば、パッケージとして完結する据え置き型のゲームの方が売り切り型で楽な部分もあります。 しかしオンラインのゲームのユーザーが増加するにつれ、日本のゲーム業界は世界の流れに乗れなくなってきていました。 ソーシャルゲームとエンジニア ソーシャルゲームはソーシャル、人とのつながりが大きな要点になっています。 ネットワークを介し、複数人数で遊ぶためには、ゲームというクライアントとサーバーの形をとらざるを得ません。 サーバーに必要とされるのは、ユーザーの情報、ユーザーの利用するキャラクターやアイテムの情報、ユーザー間のメッセージのやり取りを蓄えることで、大きな役目を持つのはやはりデータベースとなります。 ユーザーがゲームを起動するたびに、このスマートフォンとデータベースサーバーとのやり取りが始まりますので、同時にどれぐらいの人数がアクセスするかで、サーバーの能力を決定しなければいけません。 その見積もりを間違えれば、サーバーとの通信障害でユーザーが離れてしまいます。 サーバーとゲームがずっとデータのやり取りをしていると、その間の通信も発生しますし、サーバーにも大きな負荷を与えてしまいますので、一度クライアントにデータを渡して、接続を切らなければいけません。 そこからゲームを始める際に、ユーザー側のキャラクターの組み合わせや、挑戦するゲームのコースなどから、ゲーム内で現れる敵などとゲームの結果をクライアントに送り、再度クライアントの接続を切ります。 あとはユーザーがゲームに成功するかどうかで、ユーザーのデータにアイテムなどを追加するか、追加しないかを受け取って、再度サーバーとゲームの接続を切ります。 現在はクラウドのような、スケールアップできるサーバーの基盤があり、少ないスペックのサーバーからでもゲームをリリースでき、ユーザーが増加するにつれ、サーバースペックを強化していく方法をとれます。 またイベントなどアクセス集中の際に、適宜サーバー能力を強化し、あまりアクセスのない時間帯はサーバー費用を節約するために能力を低下させるような動的な管理も必要となります。 そのうえでサーバーとクライアントの通信の最適化も必要となり、データベースや、ネットワークエンジニアにはたくさんの課題があります。 こういった一般消費者向けの、動的なサーバ管理を必要とするオンラインサービスはあまり沢山ない状態で、このソーシャルゲームの隆盛は多くの経験あるエンジニアを育てているのではないかと考えます。 ゲームの価値 コンピュータゲームは生まれた時から、コンピュータの実用とは正反対の形で存在し、娯楽のために提供されるものです。 かつてファミコンが世界中でブームになった際も、賛否の意見はあったはずです。 特に電子媒体にお金を支払う、ということ自体に抵抗があった時代です。物としての玩具ではなく、プログラムとデータに支払われるお金です。 現在はこのような抵抗はほぼなくなってきてはいますが、ゲームのユーザーも拡散してしまい、1パッケージとしてのゲームの売り上げが低下しています。 そんなかで、ゲームメーカーとして利益率の高い製品を販売する必要の中で生まれてきたもの、それがソーシャルゲームでしょう。 それを選択するかどうかは、ユーザー次第で、それはいつの時代も変わらないことです。

Windows8とPostgresqlODBCドライバ

PostgresqlのODBCドライバをWindows8 64bit版へ導入する際に直面した問題について投稿します。 とはいえ、完全な解決に至っていないので、PostgresqlをODBCで使う場合は、Windows8へのアップグレードは待った方がよさそうです。 PsqlODBCドライバでODBC Administratorがクラッシュ PostgresSQLのODBCドライバ64bit版をWindows8に導入しようと考える場合、公式サイトの最新版をダウンロードするのが当たり前の手順となると思います。 http://www.postgresql.org/ftp/odbc/versions/ ここで最新バージョンであるmsiパッケージ psqlodbc_09_01_0200-x64.zip をダウンロードし、展開し、インストールを行います。 ここでインストールしたODBCドライバをWindows8のODBCデータソースアドミニストレーター(64bit)で登録してみます。 ここで完了をクリックすると、 ODBCデータソースアドミニストレーターがクラッシュします。 32bit版ODBCドライバの導入 32bit版のODBCドライバであれば、もう一つ新しいバージョンがあります。 psqlodbc_09_01_0200-1.zip これを展開し、再びインストールします。 コントロールパネルー管理ツールからODBCデータソース(32ビット)を実行します。 ここでは64bitとついていないバージョンを追加することができます。 データベースの接続を入力すると、無事postgresqlに接続することができました。 問題点 Windows8の検索からODBCで検索すると、64bit版のODBCデータソースアドミニストレータにしかたどり着けません。 32bitのODBCアドミニストレータはc:\windows\SysWOW64\odbcad32.exeにあります。 64bitのODBCアドミニストレータはc:\windows\system32\odbcad32.exeがそれになります。 管理ツールから選べますので、これを利用してください。 もう一点問題点というべきなのかはわかりませんが、64bitアプリケーションから32bitODBCドライバは呼び出すことができません。 64bitアプリケーションから32bitドライバを呼び出せないのは、当然なことなのですが、OfficeからODBCでデータソースにつなぐ場合など、Office自体が32bit版か、64bit版かで、この辺が決定的に変わってしまいます。 ACCESS2013(64bit)からこの32bitのPostgresqlのODBCデータソースを呼び出そうとすると、 「 ODBC--呼び出しが失敗しました。 指定されたDSNには、ドライバーとアプリケーションとのアーキテクチャの不一致が含まれています(#0) 」 このようなエラーメッセージが表示され、それ以上どうすることもできなくなってしまいます。 Windows 8(64bit)+ACCESS2013(64bit)+PostgresqlODBCという組み合わせで、この記事が書かれている現時点で、動作させるための正解はない、といえそうです。 ODBCドライバを介さずに接続できれば、起こらない問題ですが、ODBCで他のデータベースに接続する形のACCESSデータベースや、EXCELシート、その他ツールなどは、導入前に注意が必要です。 これはODBCドライバとアプリケーションのアーキテクチャの不整合の話ですので、postgresqlに限った話ではありませんが、新しいOSの導入の際には、アプリケーションも含め、慎重に選択することが大事です。 すべて32bitを選んでおいた方が、無難に進む事例もあると実感しました。

Btrieveのファイルを開きたい

Btrieve（ビートリーブ）とは1990年代に、パソコンを使ったクライアント/サーバシステムのデーターベースとしてよく使われていました。 このBtrieve自体は、現在OracleやMS-SQLServerなどRDBMS（リレーショナル型データベース）全盛の時代では、あまりメジャーな存在ではなくなりつつありますが、現在でもPervasive PSQLとして製品ラインは続いています。 このBtreiveをPervasive PSQLにリプレースする場合、同じデータベースファイルをそのままに使えるので、移行には手間はかからないようです。 Pervasive PSQL製品版を持っていない場合は、このファイルを開くことができません。 ファイルの中を見ると、おそらく固定長のファイルであることは、わかるのですが、データベースがどういう定義で保存されているのかわからない場合、データを紐解くことは難しいです。 Accessもバージョン2.0の時代はBtrieveのデータベースを開く機能もあったようですが、2013年の現在Access2.0のソフト本体も、動く環境もそろえることは難しくなっています。 これを読み取るものがないものか、ネットを探してみたところ、オープンソースのソフトウェアでBtrieveFileSaverというものを見つけることができました。 これはBtrieveやPervasiveのランタイムやライブラリは必要とせずに動作するもののようです。 BtrieveFileSaver http://sourceforge.net/projects/btrievefilesave/ リポジトリを見ますと、VisualC++.netで開発されたソフトウェアです。 最新版をダウンロードすると、windows形式のexeがいくつか展開されます。 readme.txtとliesmich.txt(ドイツ語でライセンス)をよく読んで利用してください。 Visual_btrieve_file_saver_trial_en(de).exeは、トライアルバージョンのようで、GUIで操作できますが5件までの出力に、限られているようです。 コマンドライン版のBTrieveFileSaver.exeをコマンドプロンプトを利用して、実行します。 利用方法は、 [text] BtrieveFileSaver –brtin data.dat –brtout data.dat.dmp –format 1 [/text] のようにして利用します。 -brtinには読み込み元のBtrieveのファイル、-brtoutには出力先ファイル名を指定します。 -formatオプションは 1 BUTIL（Btrieveのコマンドラインユーティリティー）形式での出力です。先頭にレコード長、レコード区切りはCR+LFで出力されるようです。 2 BUTIL形式から、レコード長を取り除いた形式のようです。 3 HEX DUMP(16進ダンプ）をテキスト形式で出力します。CRCということはチェックサムが付加されているものかもしれません。ファイルサイズとしては、一番大きくなります。 4.HEX DUMP(16進ダンプ）をテキスト形式で出力します。 上記の4つのオプションを使用することができます。 実行すると1レコードごとに処理ログが出力されます。 改行区切りはCR+LFなので、メモ帳などで読むと、テキストフィールドはかなりきれいに並んだ状態で読めます。 またレコード長などもはっきりしますので、実際のデータのプリンタ出力やバイナリエディタと合わせて使えば、レコード定義を理解することもできそうです。 Btrieve形式のデータベースを、サードパーティーのアプリで開くものもなかなか見つかりませんので、このようなソフトウェアを利用するのも、方法の一つかもしれません。

Accessのリプレース開発

Accessのリプレースシステム開発が急増しています。 その理由は大きく分けて３つあります。 １．Windows7ではAccess2000をサポート対象外！ 新規でPCを購入されたお客様からよくお問い合わせがあるのが、このパターン。 Windows7では Access2000をサポートしていません（8は言わずもがな・・・）。 このような理由から、PCを一新するのを機に、Accessのリプレースを希望されるお客様が多くなっています。 ２．Access2007以降では2003以前とファイル形式が違う！ Access2007から、多くの機能面が見直され、ファイル形式が新しくなりました。 が、厄介なことに、この新形式のファイルはAccess2002-2003形式のファイルとは互換性がありません。 そのため「せっかくAccess2003で作成したファイルが正常に動作しない！」といったご相談を受けることがあります。 このような場合も、リプレースが必要となってきます。 ３．Access2007以前のバージョンはMicrosoftのサポート対象外 Access2007以前のバージョンのAccessはMicrosoftのサポート対象外になっています。 更にAccess2010も延長サポートは2020/10/13をもって終了するため、リプレースを検討される企業様が増えています。 せっかく作り込んだ資産ですので有効に利用したいものです。   バージョンアップすれば、当然、過去のバージョンと互換性があると思いがちですが、 Accessに関して言えば、一概にそうとは言えません。現在、古いバージョンのAccessを 使用している方はリプレース作業が必要になることを踏まえたうえで、新規バージョンの 導入を検討してみてはいかがでしょうか。