マイクロソフトナレッジナゲッツへようこそ もうピータースです今日のトピックはよく混乱を招くものですデータバースとは一体何でしょうか データベースなのかアプリなのかそれとも it 担当者だけが理解すればいいダイナミクス365の隠れたサービスなのか最もシンプルな定義はこうです データバースは多くのダイナミクス365エクスペリエンスを支える共通のデータ基盤ですダイナミクス365オフィスビルだと考えてみてください 営業カスタマーサービスその他のアプリは人々が働く部屋でありデータバースはその裏側にあるファイリングシステムとルールです このエピソードの終わりにはダイナミクスのデータがどこに存在し一つの顧客情報更新がどのように営業活動自動化レポートに反映されるかがわかります しかし製品名の話に入る前にまずはビジネス上の混乱から始めましょうこれは一つの共有場所によって解決されます 別々のコピーを持つ代わりに営業チームサポートチーム経理チームがある会社を創造してみてください 営業部門は顧客の詳細をスプレッドシートで管理していますサポート部門は別の案件管理ツールで作業しています 経理部門は独自のシステムに顧客名を保持していますまたある人はメールスレッドを共有メールボックスに保存し別の人は誰も見つけられないフォルダーにメモを保管しています 同じ顧客が今や5つの場所に存在していることになります各チームが目の前の仕事しか見えていないため最初はこのような設定が普通に感じられます しかし問題はここです顧客が電話番号住所会社名または主要な連絡先を変更した途端問題が発生します営業がスプレッドシートを更新しますサポートにはそれが反映されません 経理は依然として古い住所に書類を送ってしまいますすると誰かがリストをエクスポートし手作業で整理してメールで回覧するため突然3人がそれぞれ自分のコピーこそが正しいと 信じるようになりますどのリストを信頼すべきでしょうかその疑問は皆さんが思う以上に時間を無駄にしますスタッフは記録を照合するために手を止めます 管理者はなぜレポートが営業システムと一致しないのかを問い詰めますサポート担当者は別の場所には少し異なる詳細情報が存在している顧客のために 案件を開いてしまいます誰も混乱を生み出そうとしているわけではありません混乱はコピーから生じるのです20年前はシステムが別々であればサーバーもデータベースも別々であり 各チームが独自の情報を保持していましたそれらを接続するにはカスタム作業スケジュールされたインポートそして多くの手作業による確認が必要でした ある場所での変更が別のシステムに反映されるのは明日か来週かあるいは永遠に反映されないこともありましたデータバースはビジネスアプリにこの種の情報のための共有の場所を提供します 簡単に言えばデータバースはビジネス情報のためのマイクロソフトのクラウドデータプラットフォームです情報を構造化されたテーブルに保存するためデータはバラバラのメモや未整理のファイル 断絶されたスプレッドシートのタブとしてではなく明確な形で存在しますこれは会社のファイリングキャビネットのようなものですが承認された複数のツールが同時に利用できる点が特徴です顧客はデータバースに一度だけ登録されます その顧客は営業担当者が商談を進める際にダイナミクス365セールスに表示されます同じ顧客の詳細はサポート担当者が依頼を処理する際にダイナミクス365カスタマーサービスにも表示されますパワーアップスを使えばデータを新しいアプリにコピーしなくても現場作業員やアカウントマネージャーが同じ顧客情報を利用できます一つの顧客行き一つの共有参照ポイントです これはあらゆるチームがすべての情報をすぐに見られるようになるという意味ではありません はなく同じビジネス情報を機に連携できるということです これがダイナミクス365とデータバースが非常に自然に適合する理由ですダイナミクス365セールスやカスタマーサービスなどのアプリはデータバースを使用してデータを保存保護していますしかしここが重要な点です ダイナミクス365とデータバースの統合について語る際多くの人はコネクタが必要な2つの別々の製品を想像しがちです しかし多くのダイナミクス365アプリにおいてその認識は誤りですデータはすでにデータバースの中に存在しているからです ダイナミクス365から顧客リストを抜き出して別のデータベースにコピーし両方の同期を祈る必要はありませんダイナミクス365がすでに使用している同じビジネス情報に基づき同じ基盤の上に構築できるのです これによって議論の焦点が変わりますどうすれば2つの顧客リストを同期できるかと問う代わりにどの担当者やアプリがこの顧客レコードを扱う必要があり それぞれに何を許可すべきかを問いかけることができますさてデータバースは企業が所有するすべてのシステムを置き換えるわけではありません 企業は依然として会計ソフト業界特化ツール倉庫システムウェブサイトあるいは独自のデータを持つ古いアプリケーションを使用する場合がありますデータバースは外部システムを一晩ですべて排除する魔法の接着剤ではないのです 提供されるのは接続されたアプリ間で共有する必要があるビジネスデータの共通の場所です顧客の詳細営業活動サポート業務タスクフォローアップなどが含まれます これらのレコードは一つのソースとして共存し承認されたツールが読み取りや更新を行えるようになりますでは私と一緒にそのファイリングキャビネットを開けてみましょう データバースがどのように情報を整理しているかがわかればダイナミクス365の接続全体におけるテーブル業列そしてリレーションシップというファイリングキャビネットの概念が理解しやすくなります そのファイリングキャビネットを開いてみましょうデータバースでは情報はテーブルの中に格納されています 実際のキャビネットの引き出しを想像してみてください一つの引き出しには企業情報別の引き出しには個人情報3つ目の引き出しにはサポート依頼が入っています すべての書類を一つの巨大な引き出しに放り込んで後で誰かが整理してくれることを願うようなことはしませんそれぞれの引き出しには役割があります データバースにおいてテーブルは一種類のビジネス情報を保持するものです取引先テーブルには通常関わりのある企業の情報が入ります 連絡先テーブルには個人の情報が入りますリードテーブルには顧客になる前の見込み客の情報が入りますサポート依頼はケーステーブルで管理し通話やメール予定タスクといった作業はアクティビティテーブルで追跡できます これらが標準テーブルですほとんどの企業で顧客や担当者業務やり取りの管理が必要となるためマイクロソフトがこれらを用意しています 標準テーブルで対応できる一般的な業務に対してわざわざ新しいテーブルを作成する必要はありませんしかしどの企業にも独自の業務というものがあります 研修会社であればコースや修了証の管理が必要かもしれません不動産業であれば建物やユニット点検記録が必要になるでしょう 製造業であれば機器の点検や訪問修理の記録が必要かもしれませんそのような場合には自社の実際の業務に合わせたカスタムテーブルを作成できます カスタムテーブルはキャビネットに新しい引き出しを追加してわかりやすいラベルを貼るようなものだと考えてくださいテーブルに派行が含まれます 業とはその引き出しの中にある一つのアイテムのことです例えば連絡先テーブルの一行は顧客企業の担当者であるマリアゴメスさんを表すことができます その業にはシステム内の他のすべての連絡先とは区別された彼女の個別の詳細情報が保持されます列は各業に対して保持したい詳細情報を定義します マリアさんの連絡先行には名、姓、メールアドレス、電話番号、役職、会社、レコード所有者、ステータスなどの列が含まれます列はその場所にどのような種類の情報を入力するかを決定します つまりメール列にはメールアドレスが入りステータス列には承認済みのステータス選択肢が入るといった具合ですこのようにしてビジネス情報は確実な形式へと整えられます 列がなければ電話番号をメモ欄に入力する人もいれば名前のフィールドに追加する人も現れ入力すらしない人も出てくるでしょう明確な連絡先テーブルがあれば全員が同じ場所にある同じ詳細情報を使って作業できます その構造はアプリがデータを理解する助けにもなりますフォームは適切な入力欄を表示できレポートはステータス別に連絡先を集計でき所有者が変われば自動化機能が反応します 情報はただ蓄積されるだけではありません各項目が何を意味するのかを接続されたツールに伝えるラベルがついているのです まずは業務ニーズに合う標準テーブルから使い始めてください企業相手のビジネスなら取引先や連絡先といった誰もが理解できるパターンがすでに用意されています顧客サポートを行っているならケーステーブルが出発点となります そして組み込みのパターンでは収まらない情報がある場合にのみカスタムテーブルを追加しましょうこれにより顧客を意味するテーブルを5つも作成してしまうというよくある問題を回避できます あるチームはクライアント別のチームは顧客マスター3つ目のチームはパートナー連絡先と呼ぶかもしれませんすぐにどのテーブルを使うべきか誰も判断できなくなります 標準テーブルを明確にしカスタムテーブルに慎重に名前をつけることで多くの人が利用しても整理された状態を保てます次にそれらの引き出しを連携させる仕組みについて説明します 連絡先はアカウントに属していますマリアはコントソ社で働いています マリアの業にコントソ社の住所や電話番号会社詳細を何度も入力する代わりにデータバースでは連絡先テーブルとアカウントテーブルの間にリレーションシップを作成できますマリアはコントソとリンクされており会社情報は会社側に保持されるためこのリンクが重要になります コントソのオフィス住所が変わった場合誰かがアカウント業を一度更新するだけで済みます関連するすべての連絡先は古い情報を個別に保持することなく常に同じ会社を参照できます リレーションシップはサポートケースをそれを提起した顧客と結びつけることもできますまた販売案件をその取引に関連する通話メール会議パスクと結びつけることも可能です 営業担当者が案件を開くと無関係なメモやカレンダーを探し回ることなく関連する活動をすべて確認できます情報にコンテキスト文脈が生まれるのです 単にケース番号を見るだけではありませんどの顧客に属しているのかを確認できます連絡先を表示するだけでもありませんその人物に関連付けられた会社を確認できます これらのリンクのおかげで同じ事実をあちこちに入力し直すことなくデータを有効活用できます古いガイドや動画を見る前に用語に関する小さな注意点があります エンティティフィールドレコードという言葉を耳にするかもしれませんこれらはデータバースの古い用語です マイクロソフトは現在エンティティをテーブルフィールドを列レコードを行と呼んでいます意味は変わっていません つまりエンティティを作成するように指示する古いガイドはテーブルの作成を意味していますフィールドは列でありレコード派行です 両方の用語を知っておけば別の製品だと勘違いせずに済みますこのようにテーブルは情報とそれらのリレーションシップを整理します しかし整理されたキャビネットには管理が必要です誰が何を入力し変更し安全にアクセスできるかを誰かが決定しなければなりません データにはルールと受付窓口が必要です共有データは適切な人が安全に作業できる場合にのみ機能します 営業担当者には顧客詳細が必要ですサポート担当者にはケース履歴が必要です マネージャーにはより広い視野が必要です そして外部パートナーにはプロセスの一部へのアクセス権のみが必要かもしれません全員が同じ情報を見るべきではありません 非公開の連絡メモ交渉価格進行中のサポートケースを含む顧客レコードを想像してみてくださいすべてのユーザーにフルアクセス権を与えるとすぐにリスクが生じます 全員を厳しく制限しすぎると仕事ができなくなり別の問題が発生しますデータバースならこれらを制御できます 最初の制御はIDから始まります 会社のアカウントでサインインするとマイクロソフトエントラーIDがユーザーを識別しますエントラーIDはオフィスの入り口にある受付だと考えてください 到着してバッジを見せると受付係が本人確認を行ってから入室を許可しますデータバースはそのIDを使用してどのユーザーがデータにアクセスしているかを把握します 単に入室を許可するだけではありません入室後にその人物に何を許可するかも決定します そこで役立つのがセキュリティロールですセキュリティロールとは業務や責任に紐づいた一連の権限のことです 営業担当者カスタマーサービス担当者マネージャーごとにロールを作成できます各ロールはテーブルへのアクセスを制御できます 例えば営業担当者は取引先企業取引先担当者見込み顧客案件の読み取り作成更新が許可されます しかし重要な顧客情報の削除は許可されない場合がありますサポート担当者はケースの作成と更新はできますが営業案件を変更することはできません 権限には業の読み取り作成変更削除が含まれますつまりアプリごとにどのボタンを非表示にするかを覚えている必要はありません 権限はデータ自体に付随しますそのためデータバースのデータがどこに表示されても同じガードレールが適用されます さらにアクセス権を細かく絞り込むことも可能です業レベルのセキュリティはどの業を操作できるかを決定します 営業担当者は自分が担当する顧客のみを見ることができますが を使用しますただしアクセスできるデータ範囲が異なります この設定によりスタッフは自分の作業に集中できマネージャーは必要な情報を把握できますまたアクセス権のない顧客情報を誰かが開いてしまうリスクも軽減されます さらに厳重な保護が必要な情報もあります列レベルのセキュリティではテーブル内の個々の列を保護できます 例えば顧客業は開けても個人識別し給与銀行口座情報個人的な財務メモは見られないようにできます 顧客業自体は業務に必要な範囲で利用可能です保護された列だけが制限されます 大規模な企業ではビジネスユニットを使用して組織間に境界を作成できます企業は異なる顧客グループを担当する地域部門子会社を分離できます ビジネスユニットはそれらの境界を超えたアクセス権の仕組みを形作るのに役立ちますこれはすべてのビジネスに複雑なセキュリティマップが必要だという意味ではありません 小さなチームであれば明確なロールがいくつかあれば十分です規模の大きな企業ではチーム地域責任範囲が異なるためより多くの階層が必要になる場合があります 要点はデータバースならビジネスの実際の仕組みに合わせてアクセス権を設定できるということですアクセス制御は誰がデータにアクセスできるかを保護しますがルールはデータそのものの品質を保護します ビジネスルールを使用すれば新しい連絡先を保存する前に電話番号の入力を必須にすることができますまたケースをクローズする際に理由の入力を求めるなど条件のチェックも可能です 入力された情報に基づいてユーザーに表示される内容を変更することもできます同じルールがそのテーブルを使用するすべてのアプリに適用されます これはあるアプリでは不完全なデータが受け入れられ別のアプリでは拒否されるといった事態を避けるために重要ですルールは特定の画面ではなくビジネス情報そのものに紐付けられるべきだからです データバースはバックグラウンドでロジックを実行しビジネスプロセスの一貫性を保つのにも役立ちます覚えておくべき詳細はシンプルです データは単なるストレージではなくルールを伴うということです つまり基盤には情報それを扱う権限を持つ人々そしてデータを活用可能にするルールが含まれていますダイナミクス365がその同じ基盤上で動作すれば自社のビジネスデータにアクセスするために従来のようなブリッジは不要になりますダイナミクス365の統合が実際に意味することですが多くの人はダイナミクス365とデータバースの統合と聞くとコネクタで結ばれた2つの別々のシステムを思い浮かべます一方のシステムが顧客データを保持しもう一方のシステムがそのコピーを必要とするため 同期を設定し実行を待ち途中で失敗しないことを祈るという流れです多くのビジネスツールにとってそのイメージは理にかなっています しかしダイナミクス365セールスとダイナミクス365カスタマーサービスの場合接続はそれよりもはるかに緊密です これらのアプリはデータバースを共有データ基盤として使用しています互いを理解するために顧客情報の業をやり取りする別々のデータベースではありません 最初から同じビジネス情報に基づいて動作しますこれは営業担当者がダイナミクス365セールスで新しい会社を作成する場合の例です 主な連絡先を追加し商談への取り組みを開始しますそれらの詳細は即座にアプリが使用する共有データの一部となります その後その顧客がサポートに連絡したとしますサポート担当者は全く同じ会社情報と連絡先詳細を扱うことができます 営業からリストをエクスポートしたり別のサポートツールで顧客情報を再作成したりする必要はありません担当者はサポートケースをその顧客に紐付けるだけで状況を理解するための履歴を確認できます 営業チームは商談を確認しますサポートチームはケースを確認し両チームが同じ顧客を中心に取り組むのです もちろんこれはすべての画面が同一になることやすべてのチームが同じプロセスに従うことを意味するわけではありません営業にはリード案件通話会議が必要です カスタマーサービスにはケース9サービス履歴が必要ですダイナミクス365の各アプリは業務に最適なツールを提供します 基盤となるビジネス情報は必要な場所であればどこにでも接続できますこの共通の基盤こそがダイナミクス365とデータバースの統合が意味するところです 単にデータをA地点からB地点へ移動させるだけではありませんアプリが同じ業関係性ルールアクセス制御を共有することなのです まずオフィスでのシンプルな販売プロセスをたどってみましょう ウェブサイトやイベントからリード見込み客が発生します営業担当者がそのリードに対応し人物について理解を深めリードを顧客関係や商談へと転換します 電話メール予定タスクのすべてをその一連の業務に紐付けることができますそのためチームが個別のツールを探し回って状況をつなぎ合わせる必要はありません その後顧客がサポートを必要とした場合サポートケースを同じ顧客に紐付けることができますサポート担当者は名前とメールアドレスだけを確認するようなことはしません すでに特定された顧客関係に基づき状況を把握しながら対応できます一方営業チームは顧客に未解決のサービス課題があることを把握できるため 問題を把握せずに更新の商談へ進む事態を防げます一つの顧客関係が様々な種類の業務を支えることができます これは単に2つのシステムで顧客名を一致させることよりもはるかに有用ですコモンデータモデル略して cdm という言葉を耳にすることもあるでしょう その名前から必要以上に複雑なものだと考える必要はありません単に多くの企業が追跡する取引先担当者 活動ケースなどの共通のビジネス用テーブルパターンをマイクロソフトが提供しているということですこれらのパターンによりダイナミクス365とデータバースベースのアプリは共通の言語で始動できます 取引先とは企業を意味します担当者とは個人を意味します活動とはビジネス関係における業務を記録するものです 自社に合わせて設定を調整し必要なテーブルを追加できます毎回白紙の状態から始める必要はありませんあるアプリが取引先テーブルを理解し別のアプリも同じテーブルを使用すれば 両方のアプリが同じ種類のビジネス情報を参照できますこれにより構築できる内容も変わってきます 例えばフィールドチームが顧客を検索し訪問を確認し面談後にメモを残すためのシンプルなアプリが必要だとしますダイナミクス365ですでに使用されているデータバーステーブルを利用してパワーアップスを構築できます そのアプリのためだけに顧客データを新しいリストへエクスポートする必要はありませんフィールド作業員はアプリを開き顧客を見つけて訪問情報を更新するだけです データは以前説明したセキュリティルールの対象となり営業やカスタマーサービスがすでに使用している顧客関係と接続されたままになりますより構造化された業務にはモデル駆動型アプリを構築できます モデル駆動型アプリはデータモデルから始まります パワーアップスはその構造を使用して実用的なビジネスアプリのエクスペリエンスを作成します チームが実際に使用するツールや素材に合わせて作業台を整理するようなものだと考えてくださいテーブルが作業内容を記述しますリレーションシップが各要素を結びつけます ホームは詳細を入力及び確認するための場所をユーザーに提供しますリューは注意が必要な業を見つけるのに役立ちます セキュリティは各ユーザーが何を開いたり変更したりできるかを決定しますモデル駆動型アプリはどちらもデータバースを基盤としているため ダイナミクス365と並行して機能させることができます例えばダイナミクス365セールスが販売プロセス全体を処理し 小規模なモデル駆動型アプリが契約マネージャーに顧客との合意事項を追跡するための専用の場所を提供するといった使い方が可能です どちらも2つ目の顧客データベースを作成することなく関連する顧客データを使用できますもちろんそのアクセスには依然として注意が必要です アプリがデータバーステーブルを使用できるからといって全てのユーザーが全ての行を編集したり全ての列を表示したりできるべきではありません ロールベースの行アクセス制御とビジネスルールが引き続き操作を制限します現場向けアプリであれば会社の他のデータやtmsデータを公開することなく その担当者に必要な顧客詳細とアクションだけを提供できますつまりダイナミクス365とデータバースの統合はもはや遠く離れた2つの部屋をつなぐ単なるケーブルではありません ダイナミクス365アプリカスタムアプリおよびビジネスプロセスはすべて同じ共有基盤の上で機能しますそれがわかると次の疑問が明確になります マイクロソフトの接続プラットフォーム全体でその同じ顧客更新情報を他に何が利用できるでしょうかこの接続プラットフォームは実際の業務でどのように機能するのでしょうか 共有された顧客更新情報は周囲のツールがそれに対応できる場合に役立ちますパワーオートメートはデータバースの業の変更を監視し変更が発生した時にアクションを開始することで 後続の作業を処理します例えば新しいリードがダイナミクス365セールスに入力されたとします フローによって担当営業への通知チームへのメッセージ投稿またはフォローアップタスクの作成が可能になります誰も共有受信トレイを1日中監視する必要はありません リードが変更されると次のステップが自動的に開始されますパワーオートメートはその作業を行うためだけにリードの個別のコピーを必要としません 営業アプリが使用しているのと同じ顧客情報や所有者詳細を使ってデータバースの業に反応できるためファイルをエクスポートして手動でメールをやり取りすることに頼らず ビジネスプロセスに密接した自動化が可能になります次はパワーBIです セールスマネージャーは現在のパイプラインを確認したいと思うかもしれませんカスタマーサービスマネージャーは今週何件の問い合わせがあったか どの案件が未解決かあるいはどの顧客からのサポート依頼が多いかを把握する必要がありますパワーBIはデータバースのビジネスデータをレポートできるため 各チームは毎週金曜日の午後にスプレッドシートをエクスポートする手間をかけずに進行中の業務を可視化できますこのレポートは日常的に使用されているビジネスデータから作成されます つまり案件が進行するにつれてパイプラインのグラフも動的に変化します担当者がケースを更新すればケースダッシュボードで現在の作業負荷を確認できます ここで重要なのはダッシュボードが個別に詳細を確認する作業を置き換えるということですダッシュボードによって何に注目すべきかを判断する前に業務の全体像をより明確に把握できる ようになりますパワーアップスは同じプロセスへの別の入り口を提供します 現場の作業員が顧客の現場に到着した場面を想像してみてください彼らにダイナミクス365セールスの全機能は必要ありません 必要なのは顧客を見つけ訪問の詳細を確認し状況を報告しメモや写真を残すことだけかもしれません目的を絞ったパワーアップならこうした簡潔な操作感を提供できます アカウントチームには顧客との契約内容を確認するためのアプリが必要かもしれませんマネージャーには申請を承認するためのシンプルなアプリが必要かもしれません 各アプリは特定の業務に集中しながらバックエンドでは一元管理された同一のデータバース情報を使用しますユーザーは自分の業務に最適なツールを使用できます 企業は一貫した情報を保持し続けることができます時には情報がデータバースの外部で発生することもあります企業がオンラインソースから得たリストをビジネスデータの一部として組み込む必要がある場合などがそうです パワークエリを使えばサポートされているオンラインソースからデータを取り込みインポート中にクレンジングを行い適切なデータバーステーブルに読み込むことができます これは外部ソースにダイナミクスやパワープラットフォームのツールで必要な情報が含まれている場合に役立ちますそれでも何がデータバースに属するのか既存のテーブルとどう連携させるべきかを検討する必要があります 検討せずにデータをインポートしても混乱の場所が変わるだけですではこれらの要素を日常的なフローに当てはめてみましょう 新しいリードがダイナミクス365に入力されます割り当てルールによって地域や製品に基づいて誰がそのリードを担当すべきかが判断されます担当者はパワーオートメートフローを通じてチームメッセージを受け取り作業が待機していることを知ります 営業担当者がリードを更新して販売プロセスを進めるとパワーBIダッシュボードが更新されチームの現在のパイプラインが反映されますたった一つの更新が様々な場所で有用なアクションを引き起こします パワーオートメートはタスクを次のステップへと進めますパワーBIは業務の状況を可視化しますパワーアップスは特定のチームが業務に関与するための専用のインターフェースを提供します データバースはこれらのツールが動作する間ビジネス情報を整理し安全に保ちますその違いが重要なのです 自動化ツールはファイリングシステムではなくダッシュボードは顧客データベースそのものではありませんそれぞれのツールには役割がありますがすべて同じソースから連携できます それを理解すればスプレッドシートや単純なリストで業務プロセス全体を回そうとするのではなく適切なツールを選べるようになります データバースが適している場面と何にとって変わるわけではないのかを解説しますここからが本題です 複数のユーザーやアプリが相互に関連するビジネスデータを扱う必要があるならデータバースを選びましょう明確なアクセスルールや反復可能なプロセスが必要な場合です データバースはそれを実現しますが他のすべてを置き換えるわけではありません個人的な分析や素早いリスト作成には依然としてエクセルが最適です チーム内での簡単な追跡にはシェアポイントリストが適していますまた詳細な制御を必要とする開発者にとってはSQLが依然として強力な選択肢です ではデータバースはいつ進化を発揮するのでしょうかデータのコピーを作成することなくダイナミクス365アプリ自動化レポートの間でデータを接続する必要がある場合です ダイナミクス365とデータバースはすべてのデータルールセキュリティアプリ自動化 レポートが共通の基盤を共有するときに最も力を発揮しますm365fmでマイクロソフトのウルジナゲッツを公読し ダイナミクス365パワープラットフォームマイクロソフト365のわかりやすいガイドをご覧ください次はモデル駆動型アプリの回を見てデータバースのテーブルがどのように実用的なビジネスアプリに変わるのかを確認してください