PAGE TOP

あれこれ

印刷する

データベースを考えてみる

主としてAccessの場合

さぼ郎
データベース」というワードをよく使います。

データベースとは、「データを溜めるもの」あるいは「溜めたデータの集まり」のことですが、データの蓄積、検索、更新などの一連の仕組み(システム)を総称するときにも使われます。

データベース

マイクロソフトによると、Accessでは拡張子「accdb」を一つの「データベース」としています。そして、一つのデータベースの最大容量(ファイルサイズ)に2GBytesの制限をつけています。

厳密には、「RDBMS」という用語があって、それは「リレーショナル・データベース・マネジメント・システム」の略なのですが、ようはデータベースに対して管理システムがあって、初めて役に立つという仕組みです。

リレーショナル」とはどういうことかというと、簡単に言うと複数の表をクエリで結合して目的のレコードとして活用するというような考え方です。

最近では「NoSQL」などというデータベース形式が活躍しています。これは「SQL」を使わない、すなわちリレーショナルデータベースではないということを明示しています。

ちなみに「SQL」は略語ではなく「SQL」として誕生しています。

「NoSQL」が活躍する背景には「ビッグデータ」があります。データの件数が億とか10億とか100億になると、データを保持するサーバーを分散する必要が出てきます。

そうなると、リレーショナルデータベースとして運用することは事実上困難になってきます。

そこで、「SQL」を使わない、つまりリレーションのないデータ形式にし、ハッシュを使ったデータの分散をし、巨大データに対するレスポンスを上げているのだと解釈しています(「知の呪縛」にかかったうるさ型に言わせると「ああでもない」「こうでもない」と言われそうですが、イメージ、そんな感じです)。

「ハッシュ」とは何かというと、例えば日本語の単語を分散させて管理するならば、「あ」~「わ」までを語彙のトップに分散させる。これを繰り返していけば、頭の何文字化を読むことで、目的の単語にたどり着けます。

現実の「ハッシュ・テーブル」は、均等にぶら下がるような統計的な均等化を十分に検討して作るか、システムが自動的に割り振ります。

通常巨大なデータから目的のデータに到達するためには、最適化されたハッシュは最速に近いと思われますが、同じハッシュキーの発生は回避できず、それを衝突と言いますが、衝突した場合の最適な処理が必要になります。

アマゾンやグーグルでは盛んに「NoSQL」を使って、レコメンドなどに活用しているようです。最近、amazonのレコメンドは、結構、役に立っていますよね。

もし、一つのデータベースが2GBytesを超えるような場合は、2GBytesを超えない算段をして、接続していく工夫が必要になります。

実際にワードクラフトでは、1年の件数が1,300万件、売上が1,377億円になるデータをAccessで扱っていますが、各種集計をしてExcelに出力するという処理なので、検索や抽出というような使い方ではありません。

ただ、2GBytesを超えてしまっていて、その対処として正確な情報がなかなか手に入らなくて困りましたが、データベース(「accdb」ファイル))を上期と下期に分断して、ユニオンクエリでデータベースを接続することで容量制限を回避しています。

とはいえ、クエリでテーブルを繋ぐわけですから速度は犠牲になっています。

64ビットAccessでも、その制約は同じですが、(同じ性能のCPUで比較したわけではないので正確な情報ではありませんが)処理速度はかなり早い気がします。

1,300万件のクロス集計は、表頭項目9種で2時間もかかります(表側項目にもよりますが)が、アウトプットが手に入ればいいのであるなら、このような方法もあります。

逆を言えば、Accessでは、データベースのサイズが2GBytesを超えないような仕組みを想定しており、それを超えるような場合は、とりあえずはユニオンクエリを提供することで、処理することは可能にしているというレベルだと考えるべきでしょう。

それと、「Accessは壊れる」ということを云う人が意外と多いのですが、ワードクラフト的な経験で言うと、壊れたという経験がほとんどありません。

壊れるのはフォームである場合が多いというような情報もありますが、真偽は不明です。

破壊

テーブルのフィールド数も相変わらず255列までで、一昔前のExcelレベルですので、あまり壮大な仕組みを作るならば、テーブルを複数に分離してクエリで繋ぐこととなり、速度が犠牲になります。

では、使いものにならないのかというと、ワタシは全くそのように考えていません。webなどでAccessの2GBytesの制約を検索すると、「本格的なデータベースを組みならAccessはやめるべきだ」という記述を多く目にしますが、その根拠を明確に示している記述は少ないです。

データベースというと、一般的には社内であれ、社外であれサーバーが必要であったり、そのためのリソース(お金とか人材)が必要であったりします。さらに、有償のRDBMSだと、イニシャルだけでなくランニングも結構な費用がかかります。

それに比べて、Accessだと、
ランタイムが無料
ポーティング(持ち運び)が自在 - サーバー等が不要
レポート作成が容易 - Excelとの連繋も自在
というようなメリットがあります。

デメリット
排他制御がレコードロックではない
堅牢性または冗長性
セキュリティ
MACやスマホで使えない
などで、使用される状況によっては、脆弱です。

ポーティング(可搬性)が緩いということは、パソコンにAccessのランタイムをインストールすればどこでも手軽に使えると同時に、「accdb」ファイル一つで、そっくり持ち去られる懸念もあるということにもなり、諸刃の剣です。

しかし、Excelで顧客管理や営業管理をしているなら、同じ話です。

持ち運び

ようは、原発と一緒で、絶対的安全を求めるのか、利便を求めるのかによるわけですが、メリットとデメリットを検討すれば自ずから答えが出てくるものと思います。

原発とは根本的に違うのは、一般的尺度や価値においては、メリットとデメリットは、中間で妥結するということではないでしょうか。これは「妥協」ではなく、「バランス」なのだと思うのです。

データベース」というだけで、「本確定なシステムはAccessでは組めない」のような「ゼロ」か「百」かの話ではなく、Excelでやりきれなくなっているような処理をAccessに移行するという視点だってあるわけで、専門家を自認する人たちの論調は経済的なバランスや利便を見失っている、よくあるパターンですね。

アイデアのちから」という本では、こういうのを「知の呪縛」としており、視野が狭窄しているように感じます。

一般的な使用場面においては、コスト・パフォーマンスを抜きにして考えることには無理があるわけです。

データベースで起こりうる障害に、デッドロックがあります。日本語に訳すと「膠着」とか「行き詰まり」です。Accessによるデッドロック回避はどうなっているのかわかりません。

一般的にはデッドロックを検知した場合、ロールバックさせて、ロックの解放を待てばいいのですが、それをシステムが自動的に行うのか、コード書くのかは現時点では知りません。

カジコさんによればやはり、コードを書くようです

また、巨大なトランザクション処理には弱いのは事実です。トランザクション処理は「完全成功」か「完全失敗」しか無いので、件数が多い場合は、それなりの手を打たなければなりません。

まして、1レコードが255フィールドを超えるような場合だと、そのテーブル数に応じたトランザクション処理をしなければならず、とても時間がかかります。
成功
はたまた
失敗
このトランザクションの件数は、レジストリで変更するとか、一時的に変えることができます。

とはいえ、巨大なトランザクション処理をするのは、その間、データベースそのものをロックするようなことになるわけですし、1件でも失敗すると、元に戻さなければならないわけですから、できるだけトランザクションファイルは細かくすることが、望ましいですよね。

このことはAccessに限ることではありません。

それと、よくあるのが、開発中、開発終了後にデータのレイアウトを増やしたり減らしたりすることです。そのために画面のレイアウトが変わったり、レポートのフォーマットが変わったり、当然ですが、SQLが変更になったりするので、うっかりすると思いもしないところでバグの原因になったりもします。

設計変更
インターフェースが変わるような変更が発生しないように、十分な事前調査とプラン(話し合いを含む)が不可欠です。建物を建てることと全く同じと言えます。

使えればいい」のではなく「使いやすくなければだめ」であって、ユーザーインターフェースは徹底的に考え尽くさなければ、いずれ使われなくなるシステムになってしまうことが多いです。

最近では、クラウドが浸透してきています。クラウドにすることでスマホでアクセスできるということが、凄いベネフィットであるように喧伝されています。

クラウド
便利だとは思いますが、セキュリティホールを抜けられると、悪意ある第三者にデータをアクセスされてしまうという致命的な欠点もありますし、スマホを使った即時性が、どこまで経営的メリットになっているのかは、よく考えるべき事項であると思います。

ベネッセの事故のように内部に悪意を持つ人がいる前提なら、完全なセキュリティにはとてもコストが掛かりますが、企業の社会的責任と経営的ダメージを勘案して、やるならやる以上の覚悟と対応が求められます。

まして、来年から始まるマイナンバー制度においては、漏れることは、即座に訴訟の対象になるという自覚と十分な対策が不可欠になります。これは、システム以前の問題であり、的確な個人情報管理や文書管理が前提になります。

蓄積するべきデータはAccessで行い、データの分析や評価をExcelで行うというような連繋は、おおかたのビジネスシーンにおいては、かなり現実的であり実用的だと思います。

キーワード