発注者必見!データベースシステムとファイルシステムの違いとは?

更新日:2017年07月29日 | 公開日:2017年07月29日

発注者必見!データベースシステムとファイルシステムの違いとは?

データベースは、企業の社内システム構築やwebサービスの展開にあたって必須の技術となってきました。
顧客管理を行う顧客データベース、商品在庫を管理する商品データベース、会社の金銭的なマネジメントを行う会計データベースなど社内の業務の遂行にあたって多くの場面でデータベースが使われています。
また、ECサイトなどを展開している場合には、webからのアクセスに対応する顧客データベースや商品データベースが動いています。

一昔前のホームページは文字、図形、画像を組み合わせてページ(画面)ごとにファイルを作っていました。しかし現在、コーポレートサイトの構築手段として広く採用されているWordPressなどのCMS(コンテンツ・マネジメント・システム)は文字、図形、画像をデータベースで管理してページを作っています。

一方で、手軽な社内向けストレージサービスとして人気のあるグーグルのGoogle DriveやマイクロソフトのOneDrive、個人のデータ管理としても幅広く使われているDropboxやiCloudなどのファイルシステムもなくてはならないツールになっています。

データベースとファイルシステムはどちらもデータを効率的に扱うためのツールですが、いったいこの両者にはどんな違いがあるのでしょうか。

例えば「社内のドキュメントを管理するシステムがほしい!」と考えた場合、データベース構築を検討するべきでしょうか?それともファイルシステム構築が必要なのでしょうか?
データベースとファイルシステムは似ているように見えて、実は技術的にはまったく違うものです。
そしてこの違いはシステムを構築してくれるシステム構築会社が知っていればよい、というものではなく発注者がどんなシステムを望んでいるかを明確に伝えるために押さえておかなければならない必須知識なのです。

この記事を一読してその違いを把握し、自社にとって必要なデータ管理の方法と最適なツールを見つけてください。

発注者が知っておくべきデータベースの基礎知識

それでは、まず「データベース」とは何かについて整理するところから始めます。

「データベース」と「ファイルシステム」は多くの場面で明確に区別されることなくなんとなく使われたり、一緒の意味で使われたりしています。

例えば、「大辞林」でデータベースを引いてみると以下のように書かれています。

これですと「データベース」イコール「ファイル」(システム)になってしまい、商用データベースのOracleやオープンソースデータベースのMySQLと、Google DriveやDropboxとの違いがなくなってしまいます。

日常生活ではこのレベルの理解でも大丈夫かもしれませんが、社内にデータベースやファイルシステムを構築しようと外部の業者に発注を考えるような場合には両者をもっと明確に区別しておく必要があります。

データベースとは何か

それでは、次に広辞苑ではなくもう少し専門的な辞書で「データベース」という言葉を確認してみましょう。

今度は、「データベース」イコール「ファイル」という定義はなくなりました。
細かい言葉の意味については以下で説明していきますので、データを扱うシステム構築上は「データベース」と「ファイル」はしっかり区別する必要があるということを意識しておいてください。

データベースは「データ」を蓄積して「情報」を提供する

先程「データベース」と「ファイル」を区別することの大切さを指摘しましたが、データベースを理解するにあたってはさらに「データ」と「情報」を区別しておくことが必要です。
私たちは会社で仕事をする上で、「データ共有」「情報共有」などの言葉を普通に使っています。
しかし、データベースでは両者を明確に区別します。

まず「データ」とは、客観的な事実を数値、文字、図形、画像、音声などで表したものを指します。
営業第一課の今月の総売上という数値は「データ」ですし、ECサイトで提供されている商品の文字、図形なども「データ」です。
そして商品をより分かりやすく説明するための画像、音声などもすべて「データ」になります。

こうしたデータは、社内の営業成績管理データベースや、ECサイトを展開するためのwebサーバーに蓄積されています。
しかし、そのデータの実態は、例えばリレーショナルデータベースの場合には、エクセルの表のように縦横のマトリックスにデータが格納されているだけで、営業成績がグラフで分かりやすく出てきたり、ECサイトの商品ページのように画像の下にキャッチコピーがあってクリックすると詳細スペックが出てきたりする、といった有益な「情報」ではありません。

データは、ネットワークにつながれて「データ共有」されているだけでなく、何かに役立つ形で「情報共有」されて初めて価値が出てきます。
データベースとは、「データ」を整理されたあるルールに基づいた形で格納し、いつでも有益な価値ある「情報」に変換して取り出せるようにしたものだと言えます。

データに価値を持たせるためにはデータベースが必要

「データ」と「情報」の違いが分かると、データに求められる特徴がはっきりします。
データが整理されていない状態で何のルールもなく蓄積されていたり、正確性に不備があったりすれば、そのデータを利用する「情報」にも価値がなくなってしまいます。

つまり「データ」とは数値、文字、図形、画像、音声がただ保存されていればいい、というわけではなく「情報」として提供できる準備ができている必要があるのです。
いつでも有益な情報に変換できる状態を保ってスタンバイしているためには、データが下記の要素を備えていることが大切になります。データに求められる要素を分類すると次のようになります。

正確性

正しいデータを格納する必要があり、またいったん格納された後はきちんと維持されなければなりません。
入力時に小数点2桁まで格納したデータがデータベースの不具合で小数点が落ちて整数だけになっていたり、文字化けして格納されてしまったりしては価値ある情報に変換することはできません。

整合性

有益な情報に変換するためには数値や文字などデータそのものの正確性だけでなく、いつの時点のものなのかが大切になります。
気象情報を格納するデータベースでは、同じ「晴れ」という天気データがいくつも存在しますから、日付データと紐付けられていないと意味がありません。
営業マンの成績でも何月集計なのかなど、データが複数の属性と正確に整合性を持っていて初めて価値を持ちます。

管理一元化

データベースは、バラバラに存在していると更新時に不整合がおきたり、データの一元性に問題が生じたりします。
本社で見ている営業データと支店で見ている営業データが違っているという場合には、正確な情報判断は不可能になります。
データは1ヵ所にまとめて管理されている必要があります。

共有

もともとデータとは複数のユーザーがアクセスして、何度でも有益な情報を提供できるようにした仕組みです。
極端な話、一人の生き字引的存在の頭のなか(あるいはその人のパソコンのなか)にだけデータがあって「困ったときは○○さんに聞け」という状態ではデータの共有ということはおきません。
もちろん生き字引的存在に頼るような属人的な情報管理は望ましくありません。
したがって、データベースは共有ができて初めて存在価値があると言えます。

容易性

正確なデータが一元的に共有可能な状態で保存されているとしても、肝心のデータを情報として活用することに専門のコンピューターシステムの知識が必須だ、という場合一部の限られた人(研究者など)以外そのデータを有効活用できなくなってしまいます。
企業においてはこうしたデータベースでは意味がないので、誰でもGUI(グラフィカルユーザーインタフェース)で操作できる容易性が必須となります。

可用性

可用性とは、ほしいと思ったときにそれがすぐに利用できる状態で提供されることを意味します。
データには基本的に永続的な価値がありますが、情報は鮮度が命です。
例えば今日の天気予報は朝出かけるときに知りたいのに、昼過ぎにならないとデータがアウトプットされないということでは意味がありません。
営業活動などでも、必要なときにすぐに商品データや顧客データを取り出せないと、データ活用の意味が半減してしまいます。

発注者が知っておくべきファイルシステムの基礎知識

ここまでデータベースについて基礎的な仕組みや求められる要件などを整理してきました。
今度は同じように「ファイルシステム」について整理してみましょう。

ファイルシステムとは何か

まずは、「ファイルシステム」の辞書的な定義を見てみましょう。

ここに説明されているようにファイルシステムは、もともと単体のコンピューターの内部にあるディスク(ハードディスクやリムーバブルディスク)に格納されたファイルに対してアクセスしたり編集したりする機能を指しました。

インターネットが普及してからは、NFSやCIFS、SMB(Server Message Block)などネットワーク経由でファイルシステムを共有するプロトコルが登場し、ネットワーク上からアクセスすることが一般的になりました。
Google Drive、OneDrive、Dropbox、iCloudなどのストレージサービスもこの流れのなかから誕生したサービスです。

データベースと最も違う点は、データベースが、「数値、文字、図形、画像、音声」などの個々の要素に解体されたデータを蓄積するのに対して、ファイルシステムでは、1つのまとまりのある「ファイル」を単位とする点です。

例えば営業に関するデータで言えば、営業マン個々人の成績を時系列的に蓄積していくのがデータベースであるのに対して、ファイルシステムでは「○○氏の営業成績表」のようなファイルとして加工された単位でデータを格納します。

ファイルシステムは「ファイル」を整理して「付加価値」を提供する

データベースが数値、文字、図形、画像、音声などの「データ」を蓄積して「情報」を提供する仕組みであったのに対し、「ファイルシステム」は、「ファイル」を整理して「付加価値」を提供します。

例えば、自分が個人的に管理している音楽CDを考えてみましょう。
音楽CDは、アーチスト名や楽曲、アルバム名などの情報がセットになった「ファイル」です。
「物理的なメディアのCDがどうしてファイルなの?」と思うかもしれませんが、CDの情報をiTunesなどでパソコンに取り込んだ場合、アーチスト名や楽曲、アルバム名などの情報はパソコンのなかに「ファイル」として格納されます。
音楽配信サービスなどはすべてこのファイルを単位として提供されていますので、今後は今の通念とは逆に、「音楽CDは、ファイルをCDに焼いたもの」という捉え方が一般的になるかもしれません。

今iTunesの例を出しましたが、iTunesの役割は、音楽CDやビデオなどのファイル情報を、ユーザーに分かりやすく提供するという「付加価値」提供サービスになっています。
売れ筋であったり、新曲であったり、自分のお気に入りであったり、さまざまな切り口でこれらのファイルにインデックス(索引)を付けて、ユーザーに分かりやすくファイルを検索してもらい、楽しんでもらうのがiTunesの役割です。

同様の見方は検索エンジンについても言えます。
検索エンジンは世界中のwebサイトというファイルにインデックスを付けて上位表示させることをサービスとしています。
個別のECサイトなどが、「数値、文字、図形、画像、音声」などのデータを使って商品ページを表示したある一定のまとまりのある情報(webサイトのページ)を、ファイルとしてインデックス化しているのがGoogleやYahoo!、Bingなどの検索サービスです。

そして、Google Drive、OneDrive、Dropbox、iCloudなどのストレージサービスもまさに、ワードやエクセル、PDFなどのファイルを検索しやすくし、編集も可能な状態で付加価値を付けて提供しています。

ファイルに価値を持たせるためにはインデックスが必要

今見てきたように、ファイルシステムにおいては「インデックス」が非常に大きな役割を果たします。
分かりやすく、使いやすく、そして魅力的な形でファイルを分類して提供するので、ファイルシステムのインデックスは書籍などの「目次」に相当するものと言えます。

インデックスはあまり大きすぎても視認性が悪くなりますので、ある程度の単位まで大きくなってきたらフォルダを分けたり、フォルダ名を付け直して分類体系を改善したりします。
パソコンのデスクトップやマイドキュメントのフォルダを整理したり、Dropboxのファイル構成を整理したり、またブラウザのお気に入りを定期的にいじったりするのは、自分にとっての付加価値が高くなるようにインデックスを付け直している行為だと言えるでしょう。

もちろん、データベースとファイルシステムは完全に相反するものではありません。
データベースで検索したデータをファイル化してインデックスを付けて保存するということは普通に行われています。
そして、今月の営業部の個人個人のデータを1ファイルずつにまとめ、それを1つのフォルダに格納するというデータベースの使い方も一般的です。
このとき、データベースから引き出したデータはファイル化され、インデックスが付けて分類されるのでファイルシステムになったと言えるでしょう。

また、ファイルシステムの検索のインデックスにもデータベース技術が使われることによって、高速で正確な検索結果が提供されます。
グーグルの検索システムなどは、扱っている情報はwebサイトというファイルですが、それをインデックス化してデータベースに格納して提供しています。

このように、技術的なレベルではデータベースとファイルシステムは補完し合いながらサービスを提供しています。

「データベース」と「ファイルシステム」との違いで発注先も変わってくる

ここまで「データベース」と「ファイルシステム」との違いを見てきました。
データベースもファイルシステム同じ情報を取り扱っているのに、その中身は随分と差があることにお気づきだと思います。
この違いをさらにはっきりさせることで、自社にとって必要なのが「データベース」なのか「ファイルシステム」なのかが見えてきます。

「データベース」の種類を知ってより適切な提案してもらうおう

データベースは、主に「階層型データベース」「ネットワーク型データベース」「リレーショナルデータベース」「NoSQLデータベース」の4つに分類できます

階層型データベース

階層型データベースとは会社の組織図のように、社長から始まって各部門の取締役、部長、課長、係長、リーダーなどのように階層的に情報を整理したものです。

このタイプのデータベースでは、昔の組織のように固定的な役割が決まっている場合にはデータが整理しやすく検索も高速に行えます。
しかし、「プロジェクトチーム」などの組織横断的なノードを加えて、各部署から人員を選抜するなどの形でデータを扱いたい、という場合には不向きになってきます。

実際に階層ツリーを書いてみるとすぐに分かるのですが、営業第一課に所属している「鈴木一郎さん」の名前が、年末キャンペーンプロジェクトにも「鈴木一郎さん」として表示されるという非常に視認性の悪い状態になります。

データベース技術的にもこうした重複データが多くなればなるほど、データの検索スピードなどに影響が出てきます。

ネットワーク型データベース

ネットワーク型データベースでは、ツリー組織のように上から一本道で線が延ばされて分類されるだけでなく、自由に自分から線を引けるところに特色があります。
先程の「鈴木一郎さん」の例で言えば、「鈴木一郎さん」を起点として、営業一課と年末キャンペーンプロジェクトに線を延ばすことができますので、データの重複がなくなります。

ネットワーク型では、階層型データベースにあったデータの重複は解消されますが、頻繁にこうしたプロジェクトチームの追加などの仕様変更がある場合には、プログラムの変更などメンテナンスに大きな工数と負荷をかけることがあります。
階層型データベースのデメリットは克服しているものの、データベースを単純に一元化して管理するという部分には課題があります。

リレーショナルデータベース

リレーショナルデータベースでは、エクセルのようにデータを行と列から構成される2次元の表形式で表します。
SQL(構造化問い合わせ言語)という英語の自然言語に近い直感的なプログラミングが可能な方法によって、ユーザーの目的に応じて自由な形式で簡単に操作できます。
リレーショナルデータベースは、重複排除や一元管理のためのルールを内部に持っているので、階層型、ネットワーク型データベースにあった課題も克服しています。

SQLを採用した検索プログラム部分と格納されたデータの独立性が高いため、データ構造に修正(営業一課鈴木一郎さんのプロジェクトへの抜擢など)が入ったとしてもプログラムへの影響は極めて小さくて済みます。

NoSQLデータベース

リレーショナルデータベースは、データと検索部分の独立性が高く使い勝手もよいのですが、ビッグデータ解析などで大量なデータからある規則性を割り出すなどの処理には向きません。
ビッグデータなどでこうした複雑なデータを扱い、詳しい分析に適した検索プログラム言語としては、「NoSQL」(=Not only SQL )があります。

幅広い種類の膨大な量のデータを高速かつ動的に整理し分析することに適したNoSQLデータベースは、スケーラビリティ、可用性、耐障害性においてもリレーショナルデータベースよりも優れていると言われていますので、大規模のデータ解析などを行いたい場合には第一候補となるでしょう。

「ファイルシステム」の種類を知ってより適切な提案してもらおう

ファイルシステムにおいても、データベースと同じように時代の変遷に合わせていくつかの有益なモデルが生み出され、受け継がれてきています。
ここでは、OSがファイルを管理する仕組みとしての狭義のファイルシステムは除外して、ネットワーク型でファイルをインデックス管理できる仕組みを持っているものについて整理します。

NFS サーバー

NFSとはNetwork File Systemの略で、TCP/IPネットワーク上でコンピューター同士がファイルシステムを共有できるようにしたものです。
LinuxなどのUNIX系のOSで標準のファイルシステムとして採用されています。
メールサーバーやwebサーバーのストレージ管理で重宝されています。

「NFS サーバー」はUNIX系のOS同士であれば、まるで自分の端末を触っているような感覚で別の端末にログインしてファイルを操作できるので、使い勝手もよくファイル管理も容易です。
しかしWindows系のパソコンとのファイル共有などは提供されていませんので、情報システム部門内部でファイル共有が完結している場合などは問題ありませんが、営業マンが普段使っているパソコンから会社のホストに保存されている製品情報ファイルを見たい、という場合などには別のファイル共有ネットワークが必要になります。

Sambaサーバー

前記のNFS-Windows相互ファイル共有の課題解決のために広く使われているのが、UNIX系OSで動作するコンピューターをWindowsネットワーク上のサーバーやクライアントとして利用することを可能にする「Sambaサーバー」です。
Sambaを使えば、会社のホスト系サーバーとして数多く採用されているUNIX系のコンピューターを、Windowsネットワーク上のファイルサーバー、プリントサーバー、Windowsドメインコントローラとして利用することができます。

すべてをWindowsサーバーで構成すると非常に高額になるため、コスト重視でUNIX系サーバーを混在させてファイルサーバーを構成したい、という場合に重宝します。

FTP(File Transfer Protocol)サーバー

FTPは、File Transfer Protocolの略で、WWW(ワールドワイドウェブ)などと同じ、TCP/IP上の通信規格を意味します。
主にグラフィカルなデータをwebブラウザ経由で提供するのがWWW方式であるとすれば、FTPはネットワーク上でファイルの転送を効率的に行うための通信プロトコルだと言えます。

ファイル転送プロトコルとしては世界標準ですが、ファイルを共有してインデックス化して付加価値を高めて再利用するというよりは、HTMLソースや画像などのwebページ用各種ファイルをクライアントパソコンからwebサーバーへのアップロードするためなどによく使われています。

WebDAV

WebDAV(Web-based Distributed Authoring and Versioning)は転送に特化したプロトコルであるFTPを閲覧にも便利なように拡張した仕組みだと言えるでしょう。

WebDAVを使えば、FTPソフトなしでWindowsのエクスプローラーやMac OSのFinderでwebサーバー上のファイルを表示させることができます。
表示させるだけなく、ファイルを削除したり、ドラッグ操作でファイルを移動したり、修正して再保存したりなどもできます。

FTPと違ってファイルをダウンロード・アップロードするという手間をかけずに、直接ファイルを加工できるので次に挙げるクラウドファイルシステムと同様の使い勝手が実現できています。

クラウドファイルシステム

クラウドファイルシステムは、Google Drive、OneDrive、Dropbox、iCloudなどのPaaS型で提供されたり、IaaS上に独自にプライベートクラウドを構築したりして利用できるサービスです。

自社でファイルシステムを最初から構築するのではなく、インフラやファイルシステムのアプリケーションをクラウド上で月額課金にて利用するタイプなので、自社にサーバーを持つ必要がありません。このため、初期費用を抑えられることやシステム管理を担当する専任の技術者が不要といったコスト的なメリットが大きくファイルシステムの利用形態として急速に普及しています。

また、柔軟にシステムをスケールできること、故障によるサービス停止の心配がない、最新のセキュリティアップデートなどを無料で迅速に行ってくれるなど運用面でのメリットもクラウドファイルシステムの普及を大きく後押ししています。

データベースとファイルシステム、どちらが自社の要望にあっているか見極めよう

いかがでしたでしょうか。
ここまでデータベースとファイルシステムの違いを見てきましたが、両者にはかなりの違いがあることが明らかになりました。
技術的な仕組みではデータベース技術とファイルシステムの技術は相互に補完し合いながらサービスを構成しています。
むしろ、データベースとファイルシステムの違いを意識するべき場面は、「数値、文字、図形、画像、音声」などの個々の要素に解体されたデータを一定のルールに基づいて蓄積して情報として活用したいのか、ファイル単位で構成されたデータを効率よくインデックス化して付加価値を付けて管理したいのか、という活用段階です。
もっとも、本文中でも指摘しましたがデータベースとファイルシステムは完全に相反するものではなく、両方をうまく組み合わせて日常業務を効率的に遂行できるようになります。
先に挙げた例で言えば、「データベースで検索した営業マンの成績データをファイル化してインデックスを付けて保存して活用する」という一連の行動には、データベースとファイルシステムの両方が必要となってきます。

つまり、自社にとって最適なシステムは何かを明らかにするためには、ここで解説した基礎知識を活用して自社でデータを活用するイメージを明確化してから、それに対してどのようなアプローチでデータベースやファイルシステムを利用するのが最適なのか検討する、という順番で考えることが大切です。

「アイミツ」にご相談いただければ、御社のシステムの現状を把握した上で、最適なシステムを案件ごとにきめ細かく提案できるシステム構築会社をご紹介いたします。
データベースやファイルを活用した情報システムの構築をお考えの際にはぜひお声をかけていただければと思います。

見積もり、取ってますか?

発注をする際に最も大切なことは適正価格を知ることです。
3~4社から見積もりを取ることで、
発注への納得度を高めることができます。

コンシェルジュ

発注は時間も手間もかかりますよね?

コンシェルジュが解決します!

コンシェルジュに相談、あなたにあった業者を提案、発注の手間を削減!

完全無料

まずはお気軽にご相談ください