スプレッドシート（Excel、Googleスプレッドシート、またはその他の名前のシート）は、非常に優れた強力なツールです。しかし、データベースもそうです。いつスプレッドシートに固執する必要がありますか？いつデータベースに移動する必要がありますか？
これは私の前の記事「スプレッドシートとデータベース：切り替える時が来たのか？」の続きです。ここでは、スプレッドシートを使用して大量のデータを整理することの最も一般的な欠点について説明しました。この記事では、データベースがこれらの問題をどのように解決するかを説明します。
データベースを使用してデータを整理する
私のモットーは「ニーズに合った適切な技術を使用する」です。あなたがシートを介してあなたのビジネスを運営することができれば、素晴らしいです！単純なデータベースが必要な場合、MSAccessは悪い選択肢ではありません。ただし、これらの製品が機能しない場合は、カスタマイズされたデータベースとWebアプリケーションが必要になる可能性があります。データベースはあなたのデータを保存します。 Webアプリは、データベースと対話し、データレイヤーと通信するためのユーザーフレンドリーな方法になります。
私たちの架空のサービスビジネスはそれほど複雑ではなかったので、かなり単純なデータモデルを使用してそれを強化することができました。下の画像を見ると、必要なものがすべて5つのテーブルに格納されていることがわかります：client_type 、client 、service 、replacement 、およびhas_service 。
データベース設計の重要なルールは、関連する実世界のデータを1か所に保持することです。 。この場合、すべてのclient クライアントテーブルのデータ。このようにして、同じデータを複数の場所に保存することを回避します（前述の冗長性の悪さ）。クライアントに関連するものを変更する場合は、この表で1回だけ変更します。これにより、データ品質が大幅に向上し、パフォーマンスが向上します。
実際のデータを含む次のテーブルは、service テーブル。ここでも、サービスに関連するすべての詳細をここに保存でき、データを非常に効率的に変更できます。
client テーブルとservice テーブルは、他のテーブルなしで存在する可能性のある実際のエンティティです。ただし、無関係なエンティティを使用してデータベースを作成することはあまり意味がありません。これは、製品やサービスを購入者なしで顧客に提供するようなものです。したがって、has_service テーブル。どのクライアントがどのサービスを利用しているかに関する情報を保存するために、そのクライアントとサービスへの参照として機能する外部キーを使用します。これらの外部キーは、サービステーブルとクライアントテーブルのレコードを指し示します。各クライアントとサービスの関係に関連する追加情報をこのテーブルに保持することもできます。
client_type テーブルは、考えられるすべてのタイプのクライアントを格納する辞書のように使用されます。異なるセグメンテーションを別々のディクショナリテーブルに保持するのが最善です（たとえば、顧客タイプと従業員の役割タイプがある場合は、それらを異なるテーブルに保存します）。ただし、これは単純なモデルであるため、必要なテーブルは1つだけです。
モデルの最後のテーブルは、replacement テーブル。これを使用して、交換するサービスと交換サービスの2つのサービスを関連付けます。これにより、既存のサービスの代わりとなるサービスをクライアントに提供できる柔軟性が得られます（あるモバイル通話プランから別のプランに変更するのと同じように）。
データベースの利点
データベースはスプレッドシートよりも設定が複雑ですが、これにより、データの整合性とセキュリティの点で実際にいくつかの重要な利点が得られます。
キーと制約
データベースには、適切に使用された場合にほとんどのデータ品質とパフォーマンスの問題を防ぐ組み込みのルールとコントロールがあります。主キー（テーブル内の各レコードを一意に識別する列）と外部キー（別のテーブル内のレコードを参照する列）はデータの安全性にとって重要ですが、代替キーまたは一意のキー（テーブル内の各レコードに固有のデータを含む）を定義します）も非常に役立ちます。
リレーショナルデータベースでは、キーはさまざまなテーブルのデータを関連付けます。テーブルの主キーは常にUNIQUEですが、外部キーは他のテーブルの主キーを参照します。この参照は、これら2つのテーブルのデータに関連しています（例：has_service 表は、顧客データと顧客のサービスを関連付けています）。また、他のテーブルで参照されている主キーを削除しようとすると警告が表示されます。これにより、別のテーブルで（参照として）まだ必要なレコードを削除できなくなります。
制約は、フィールドに入力できるデータの種類を定義します。データに値（NOT NULL）が必要であること、電話番号の形式を定義すること、文字のみを含めることなどを指定できます。これは、フィールドに間違った種類のデータを入力する人々によるデータの問題を回避できることを意味します。
セキュリティと権限
もう1つの非常に重要なデータベース機能は、データへのアクセスの制御です。 。これにより、データベースにアクセスできるユーザーを設定できるだけでなく、ユーザーが表示または変更できる内容を制御することもできます。これはデータセキュリティの大きな部分です。たとえば、従業員が顧客の詳細を変更できるが、サービスの詳細は変更できないユーザーロールを定義できます。また、従業員がデータを変更または削除できるルールを設定することもできます。人々が仕事をするために必要なデータにのみアクセスできるようにすることは、良い標準的な方法です。
もちろん、これらの機能を（少なくとも何らかの方法で）シートで再現することもできますが、それは間違いなく「車輪の再発明」になります。
スプレッドシートだけを使用することはできませんか？
もちろんできます。データモデルで使用されているのと同じパターンに従うシートを作成できます。それは多くのデータの問題を解決しますが…
データモデルをシートに複製することは、理想的なオプションではありません。データベースシステムが提供するすべての利点、データを「正常」に保つためのすべてのルールと制約、偶発的な削除やその他のエラーを防ぐためのすべてのものが失われます。最適化に失敗し、データセットが十分に大きい場合、パフォーマンスが低下します。
それを解決したとしても、データの共有についてはどうでしょうか。複数のユーザーが同時に同じシートを使用していますか？これにより、どのようなデータの整合性とパフォーマンスの問題が発生しますか？これは、物事をシンプルに保つことの反対です。
したがって、シートでビジネスニーズを処理できないと思われる場合は、おそらくすでにデータベースに向かっています。スプレッドシートに保存されているデータで行き詰まり、データベースに移動したい場合は、次のことを行う必要があります。
- データを最適に保存するデータベースモデルを作成します。
- データベースをバックグラウンドで使用してアプリケーションを構築します。
- データをクリアし、（必要に応じて）変換して、データベースにインポートします。
- データベースのみの操作を続行します。
スプレッドシートとデータベースのどちらを選択する必要がありますか？
今日の記事では、データベースがシートを使用して大量のデータを整理する際の問題をどのように解決するかを学びました。私のアドバイスは、常に問題の最も簡単な解決策を採用することです。 。スプレッドシートが適切に機能する場合は、それらを使用してください。ただし、データ主導の企業の場合は、できるだけ早くデータベースの使用を開始する必要があります。データのクリーンアップと移行を待つ時間が長くなるほど、プロセスはより苦痛になります。