データ収集に投資するほどメリットは少なくなる CDPが持つさまざまな機能の中で比較的新しく、そして注目されているのが、1人の顧客の行動を追える機能だ。また、一元的な顧客情報の整理も課題の1つとして認識している企業が増えており、そのための「360度の顧客ビュー」を実現するツールとしてCDPが活用されている側面も大きい。 「360度の顧客ビュー」とは、1人の顧客を中心に、企業と顧客（見込み顧客含む）との関係に関連する必要なデータすべてを取り込んだデータセットのことだ。これに対し川辺氏は、「本当に必要なのでしょうか」と問いかける。 顧客を360度から把握するためには、複雑な図式が必要だ。企業内には、上流としてCRMやERPなどの業務系システムのほか、マルチチャネル・マーケティングハブといったマーケティング系のシステム、分析系のデータ基盤・システムがあり、それらからもデータを取り込む必要がある。そ

印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 名寄せとは 「名寄せ」というものを、読者の皆さんも一度はお聞きになったことがあるはずだ。聞いたことがなくても、例えば、町内会なり同窓会なりで名簿を複数持ってきて突き合わせれば、それが名寄せである。クラブ活動で入部届けをもらって、実在の人物かどうか確認するのも名寄せである。 名寄せが国民的に有名になったのは、国民年金における名寄せの一件だ。 「年金の支給が漏れているかもしれません、別人に年金を払っているかもしれません」という人が何百万人も出てきたという事件である。住民基本台帳や名寄せが悪者のようにも見えるが、それは発覚のキッカケに過ぎない。名寄せをしなければ埋もれたままだったはずだ。 「最初から人を確認しておけばよかった」と言いたくなるが

Tweet 【プレスリリース】不動産テック協会、Geolonia と共同で不動産情報の共通 ID 付与の取り組みを開始 一般社団法人不動産テック協会(代表理事:赤木 正幸、巻口 成憲、以下、不動産テック協会) は、株式会社 Geolonia(本社:東京都千代田区 代表取締役社長:宮内 隆行、以下、Geolonia)と 共同で、国内の土地や建物等の不動産情報に対して、共通 ID の付与に向けた取り組みを開始い たします。2021 年内に、不動産テック協会に加盟する企業同士の情報連携が可能となることを目 指してまいります。 背景 現状の不動産情報は、共通して利用できる通し番号などはなく、「住所」や「物件名」などで物件を 特定しています。そのため、「三丁目」と「3 丁目」といった表記ゆれが頻繁に発生しやすく、そのた びに情報修正する状況が続いています。さらに、これらの不動産情報はオープンデータで

前回記事で、「関数従属性にもとづくデータの論理構造」に着目してDB設計すべきだと説明した。しかしそのスタイルはひどくマイナーで、「データの扱われ方」に沿ってテーブルを切り出すやり方が今でも圧倒的多数派である。 多数派のやり方の何が問題なのか。非効率で混乱している現行業務をシステム化する場合、ふつうは抜本的合理化が求められる。ところが「データの扱われ方主導」ではそれが起こりにくい。現行業務のあり方が追認されたうえでの効率化しか起こらない恐れがある。 具体例を「簿記」を使って説明しよう。紙とペンで伝統的な経理事務をやっている組織があるとして、業務を合理化するためのコンピュータシステムがスクラッチ開発されることになったとしよう。 「データの扱われ方主導」で設計する技術者は、開口一番「（現行の）仕事の進め方を教えてください」と尋ねるだろう。ユーザは次のように答えるだろう。「まずは勘定科目の体系を決

「マイクロサービス(microservices)」が注目されている。社内外のさまざまなシステムが提供するREST APIのような操作手段を組み合わせて、新たなしくみをアジャイルに開発・保守してゆく。そんな開発スタイルのことをいう。 もともとはネット系企業で普及した手法であるが、それ以外の企業にとっても参考になる。前回記事で、基幹システムが効果的なAPIを提供することで「周辺システム」の開発が合理化されると説明した。これを社内システム全体に適用した手法が、マイクロサービスである。ネット系企業でなくても「周辺システム」はいろいろあるので、いくらでも応用できる。ただし、当然ながら万能ではなく使いどころがある。 基幹システムから見た「周辺システム」と書いたが、それらは今風に言い換えるとSoE(Systems of Engagement)、ようするに顧客との関係強化をはかるためのシステム群である。い

データベース管理者でもマイナンバーのデータは見えないようにする 今回の記事では、マイナンバーを扱うITシステムの中で重要な要素となる「データベース」に着目し、どのような対応をすればいいかを考えていきたい。別添の安全管理措置のガイドラインには、「物理的安全管理措置」と「技術的安全管理措置」の2つの項目がある。物理的安全管理措置の中でデータベースに関連しそうなのが「電子媒体等を持ち出す場合の漏洩等の防止」と「個人番号の削除、機器及び電子媒体等の破棄」の2つだ。 漏洩防止に対応するために必要となるデータベース機能には、データの暗号化があるだろう。万一マイナンバーの入っているデータベースファイル入りのハードディスクを盗まれたり、あるいはデータベースサーバーなりが丸ごと盗難にあったりした場合にも、中身のデータが適切に暗号化されていれば漏洩を防止できるだろう。もう1つの個人番号の削除や電子媒体の破棄の

福岡県を拠点に鉄道、バスなどの運輸業、不動産、流通など幅広い事業を展開している西日本鉄道。80社1学校法人からなるグループを形成する同社では、グループ経営の高度化や業務改善のため、経理システムにSAP ERPを導入するなど、積極的にIT活用を進めてきた。近年、事業の多角化に伴う経営管理データの活用ニーズが高まっており、SAP ERPからの迅速なデータの抽出とそのデータを分析する環境の実現が急務だった。だが、SAPのデータ抽出時のレスポンスの悪さと、抽出したデータのカスタマイズは外部ベンダーへの依頼が必要なことから運用面でもコスト面でも問題を抱えていた。 課題解決に向け、同社ではフラッシュストレージをプラットフォームに採用したSAP対応BIフレームワークの高速化版アプライアンスを導入する。本資料では、課題解決のための製品選択と導入効果について関係者のインタビューを基に紹介する。SAPデータの

カラム型データベースでトランザクション処理を実現するカラクリとは？ インメモリとカラム型データベースの可能性を調べる（その5） SAPのHANAは、最初からインメモリデータベースとカラム型データベースの技術を用いて高速な集計や分析処理と高速なトランザクション処理とを両立させることを目指して開発されたと、HANAの開発者でありSAPの共同創業者であるハッソ・プラッタナー氏はHANAの設計思想と実装を解説した著書「In-Memory Data Management」で書いています。 ここでは、その書籍および公開されている論文「Efficient Transaction Processing in SAP HANA Database – The End of a Column Store Myth」（SAP HANAデータベースにおける効果的なトランザクション処理 ― カラムストア神話の終焉）から

カラム型データベースはなぜ集計処理が高速で、トランザクションが苦手なのか。インメモリとカラム型データベースの可能性を調べる（その4） 現在主流となっているOracle、SQL Server、DB2などのリレーショナルデータベースは事実上すべて、行（ロー）指向で内部の処理を行っています。一方で、最近急速に注目されているのが、列指向で内部処理を行い、大量データの集計や分析処理に優れた「カラム型データベース」（あるいはカラム指向データベース、カラムナーデータベース）です。 カラム型データベースはSybase IQやNetezza、Verticaなどデータウェアハウス専用のデータベースで主に採用されています。また、SQL Serverには「ColumnStore Index」、Oracle Exadataには「Hybrid Columnar Compression」と呼ばれるカラム型データベースの

インメモリデータベースでサーバが落ちたらデータはどうなる？ インメモリとカラム型データベースの可能性を調べる（その3） サーバのメインメモリ上にあるデータは、サーバの電源が落ちれば消えてしまいます。だからこそ、現在のデータベースではデータを失わないように永続化の手段としてデータベースやログをハードディスクに保存しています。 データベースをメインメモリ上に保持するインメモリデータベースでは、万が一サーバの電源が落ちるなどの物理的障害が発生したらどうなるのでしょう。メモリの内容が消えるのと同時にデータベースを失ってしまったり、整合性が失われるなどの問題が発生してしまう心配はないのでしょうか。 結論としては、インメモリデータベースでもつねにログをハードディスクやフラッシュドライブなどのストレージへ書き込んで、サーバの物理的障害に備えています。インメモリデータベースであっても、メインメモリだけに依

従来のデータベースをメモリに載せるだけではだめなのか？ インメモリとカラム型データベースの可能性を調べる（その2） 現代のサーバは1台で複数のプロセッサを備え、数百ギガバイトから数テラバイトのメインメモリを搭載可能です。これは多くの企業で利用されているデータベースがそのままメモリに載るほどの容量です。 大量のメモリを搭載したサーバを用いれば、Oracle DatabaseやSQL ServerやDB2など従来のディスクベースのデータベースでも、データベースをまるごとメインメモリのバッファキャッシュに載せることができます。そうすればディスクアクセスのボトルネックは事実上ほとんどなくせるため、高速なデータベースアクセスが実現します。 だとしたら、データベースをすべてメモリに載せる機能を備えたインメモリデータベースを、わざわざ使う必要はあるのでしょうか？ この疑問は、以前の記事「キャッシュの大き

インメモリデータベース、カラム型データベースは使い物になるのか？ インメモリとカラム型データベースの可能性を調べる（その1） ERPベンダ最大手のSAPは2010年、新規に開発したデータベース「SAP HANA」（当時の名称は「SAP High-Performance Analytics Appliance」）を発表しました。 HANAの製品化を背景に、SAPは2012年5月にデータベース市場への本格参入を宣言し、オラクルやIBM、マイクロソフトとデータベース市場で競合していくことを表明。そして今年2013年2月にはついにERPと組み合わせた「SAP Business Suite powered by SAP HANA」の出荷を開始し、業務アプリケーションのバックエンドデータベースとしてHANAの本格利用を開始しました。 HANAには、これまで主流だったリレーショナルデータベースとは異なる

EnterpriseZine（エンタープライズジン）編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

「喜連川といえばデータベース。ずーっとデータベースをやってきました」とデータベース一筋の喜連川先生。その出発点を探ろうと、専攻を選んだ当時を尋ねようとすると「いまより悲惨でしたよ」と言う。 当時コンピュータに関係する学科となると「Electrical Engineering」で、主流は通信だった。中学生のころ「“体育館一面に並ぶコンピュータと書いた記事”を新聞で目にした」という世代である。人工知能や仮想現実などまだまだ先のこと。当時はコンピュータを専門にしようとすること自体が亜流だった。「未来がどれだけあるか分からない」―当時はそのくらい注目度や期待が薄いという意味で「悲惨」だそうだ。 そんなに不確実なものを選んだのはなぜかと尋ねた。先生は「人生、思い通りになるものは少ないですから」と話し始めた。 「ぼくは車の運転が下手でね。車は“こうやって動かす”と分かっていても、雨が降ったら滑ったりす