ようこそ!浜村拓夫の世界へ

    ブログ内検索

    最近の記事

    ブックマーク数の多い記事

    Blog Translation

    Powered By FC2ブログ

    Powered By FC2ブログ
    ブログやるならFC2ブログ


    FC2ブログ LOGIN

    with Ajax Amazon

    データベースの暗号化

    このエントリーを含むはてなブックマーク はてなブックマーク - データベースの暗号化 あとで読む
    昨今、企業の個人情報漏洩が問題になっています。
    サーバーをクラックされて、データベースのデータが漏洩した場合でも、解読不可能となるように、データベースを暗号化しておくことは重要でしょう。

    最新のMySQLには、簡易の暗号化機能が実装されました。
    新機能にはバグが残っているかもしれないので、安定してから導入すれば良いかも?

    ●MySQL InnoDB Tablespace Encryption
    ・透過型のブロック暗号

    MySQL :: MySQL 5.7 Reference Manual :: 15.5.10 InnoDB Tablespace Encryption

    15.5.10 InnoDB Tablespace Encryption

    InnoDB supports data encryption for InnoDB tables stored in file-per-table tablespaces. This feature provides at-rest encryption for physical tablespace data files.



    UCO-Tech(InnoDB Tablespace Encryption) – UCOブログ

    このMySQL 5.7.11で、なんと新機能が搭載されました。
    新機能は、「InnoDB Tablespace Encryption」です。
    MySQLに格納されているデータは、ibdataファイル、もしくは、初期化パラメータ「innodb_file_per_table」がONの場合は、(テーブル名).ibdファイルという形で実ファイルで保持されています。
    しかし、このファイルは暗号化されていないため、OS上から直接中身を見ることができます。
    これを暗号化しよう、というのが、このInnoDB Tablespace Encryptionという機能です。



    MySQL商用版では、MySQL Enterprise Encryption, MySQL Enterprise Audit, MySQL Enterprise Firewallなど、セキュリティ系の製品が次々とリリースされています。
    これらの流れからみても、MySQLもセキュリティに力を入れ始めている(もしくは入れざるを得ない)という事情があるのかな、と言えるのではないでしょうか。



    MySQLの透過暗号化対応版が遂にリリース、ただし注意書き有り。 | Server-GENERAL

    大きく目立つように注意書きが添えられています。
    「これは法規制のコンプライアンスソリューションとして意図されていない。」
    「セキュリティ基準を満たすには鍵管理システムの利用が必須」
    と明記されています。

    読者の方はお分かりと思いますが、これは非常に重要なメッセージです。
    MySQLほど広く普及しているデータベースが透過型暗号に正式に対応したとなれば、セキュリティ技術に詳しく無い人も多く利用することになるでしょう。
    その中で暗号鍵の管理の重要性について理解していない人が安易な暗号化を採用しないように釘を差したとも言えます。


    マニュアルを見ると鍵管理はプラグイン化されているようなので、今後、商用版のリリースの中で本格的なMySQLの暗号化の鍵管理システムが提供されていくのではないかと思います。
    それでも暗号化されるのはInnoDBだけですので、まだまだ機能的には不十分です。



    暗号鍵をクラックされないように、保護しておく必要がありますね?

    ●MariaDB Encryption
    MySQLから派生したMariaDBも、データの暗号化機能を提供しています。

    MariaDB 10.1.7がリリースされました | スマートスタイル

    MariaDB10.1には、以下のような特徴があります。

    ・安全なマルチマスタ構成を実現するクラスタソフト「Galera Cluster」が、手軽に利用可能
    ・テーブル、またはテーブルスペースの暗号化機能
    ・InnoDBのページ圧縮機能
    ・GISデータ(地理データ)に対応
    ・新しいクエリ文法の実装、既存クエリの性能改善
    ・新たなサーバパラメータ変数、ステータス変数の追加



    Data at Rest Encryption - MariaDB Knowledge Base

    Encryption of tables and tablespaces was added in MariaDB 10.1.3. There were substantial changes made in MariaDB 10.1.4, and the description below applies only to MariaDB 10.1.4 and later



    MariaDB encryption is fully supported for the XtraDB and InnoDB storage engines. Additionally, encryption is supported for the Aria storage engine, but only for tables created with ROW_FORMAT=PAGE (the default).

    MariaDB allows the user to configure flexibly what to encrypt. In XtraDB or InnoDB, one can choose to encrypt:
    ・everything — all tablespaces (with all tables)
    ・individual tables
    ・everything, excluding individual tables
    Additionally, one can choose to encrypt XtraDB/InnoDB log files (recommended).



    Table and tablespace encryption on MariaDB 10.1.3 - MariaDB.org

    Performance Impact
    Encrypting the tables or tablespaces naturally have some effect on overall performance of the system. Naturally, the amount of performance effect encryption has is dependent on used hardware, workload and used encryption method.



    MariaDB Encryption Performance Impact

    処理速度は若干落ちますが、上記グラフはプロットがゼロ基準ではないので、それほど遜色はないでしょう。
    速度よりも安全性が重要な場面で利用すべきでしょう。

    ●段階的な暗号化
    暗号化を施す段階には、様々なレベルがあります。

    MySQLの保存データ暗号化(Percona Data Performance Blogより) | Yakst

    保存データ暗号化を行うためには主に3つの方法があります。

    ・フルディスク暗号化
    ・データベース(テーブル)レベル暗号化
    ・アプリケーションレベル暗号化。データがデータベースに挿入される前に暗号化されます。

    フルディスク暗号化は、誰かがディスクをサーバー上から物理的に持ち去るケースしか防ぐことしかできないため、最も強度の弱い方法です。
    一方で、アプリケーションレベルの暗号化は最善の方法です。ほとんどオーバーヘッドを発生させることなく伝送中のデータの暗号化も含め柔軟に行えるためです。
    残念なことに、アプリケーションのソースコードはアプリケーションレベルの暗号化を行うため常に変更できるとは限らないため、データベースレベル暗号化は非常に重要な代替手段となりえます。



    MariaDBのチーフアーキテクトであるSergei Golubchik氏はPercona Live Amsterdamのセッションでデータベース暗号化の長所、短所について次のように述べています。

    長所
     ・DBMSの全機能が利用できる
     ・実装しやすい
     ・データベースからのみデータが閲覧できる
     ・テーブル毎の暗号化、テーブル毎の鍵の設定ができる

    短所
     ・ユーザーごとに実施できない
     ・悪意あるrootユーザーから保護できない



    現在のところ、データベースレベルで保存データ暗号化を行う方法は2つあります。

    MariaDB 10.1.3以降がサポートする暗号化 (Googleのパッチを利用)
    MySQL 5.7.11以降(およびPercona Server 5.7.11)のInnoDBのテーブルスペースレベル暗号化

    MariaDBの実装はMySQL 5.7.11とは異なるものです。



    無償で使える他のRDBは、データの暗号化に対応しているのでしょうか?
    PostgreSQL データ 暗号化 - Google検索
    SQLite データ 暗号化 - Google検索
    どちらも、データを暗号化する方法が用意されているようでした。

    データベースレベルの暗号化には次の2つの弱点があります。

    1. rootおよびMySQLのユーザーはキーリングファイルを読み出し可能でこれは目的からすると大きな問題です。しかしながら、キーをマウントされたドライブ上に置きMySQL起動後にアンマウントする(これはスクリプト化可能)ことは可能です。しかし、MySQLがクラッシュした際に自動で再起動されず、人の介在が必要となってしまう問題があります。

    2. MariaDBのバージョンとMySQLのバージョンはディスクに書いたデータのみを暗号化しRAM上のデータは暗号化しないので、rootユーザーはMySQLにgdb/straceあるいは他のツールをMySQLにアタッチしてサーバー上のメモリを読むことができます。



    メモリ上のデータが暗号化されていないことは、確かに盲点ですね。
    メモリ上のデータまで保護しないといけないなら、データベース以前の話として、そもそもはサーバーをクラックされないようにするしかないのでしょう。

    ●参考

    MySQLおじさんの逆襲 from yoku0825


    SQLite の暗号化 from Akihiro Matsuura


    スマホアプリの制作でも、データストレージにRDBを利用している場合、データ暗号化は必須ですね?

    MariaDB&MySQL全機能バイブル
    鈴木 啓修 / 山田 奈緒子
    技術評論社
    2014-12-18
    ¥ 3,780

    変更不可なAppend-onlyデータベース「Datomic」

    このエントリーを含むはてなブックマーク はてなブックマーク - 変更不可なAppend-onlyデータベース「Datomic」 あとで読む
    RDBの設計について調べている過程で、Datomicなるデータベースを知りました。(メモ)

    Datomic - Google検索

    Datomic Logo

    Datomic 公式サイト
    Datomic - Home

    Clojureの作者が作ったデータベースDatomicが凄い

    変更不可なAppend-onlyデータベース
    従来のデータベースで、あるレコードを変更するというのはそのレコードに対応した場所があり、そこのデータを書き換えるということを意味していました。
    Datomicでは書き換え可能な場所はなく、過去の事実を時刻と共に全て記録します。



    Rich Hickey 氏,Clojure/West で Datomic を語る

    基調講演を担当した QCon London から到着したばかりの Rich Hickey 氏が用意していた話題は,自身の最新の活動である Datomic に関するものだ。
    氏の説明によれば "スケーラブルでフレキシブル,インテリジェントなアプリケーションを実現すべく設計された,クラウドアーキテクチャ上で稼働する分散データベース" である。
    Datomic はフル管理された NoSQL データベースサービスである Amazon DynamoDB 上に構築され,ACID トランザクションやジョイン,不変性と状態を活用するデータモデルなどを機能として備えている。
    さらに Prolog のサブセットである Datalog を装備することで,クエリをアプリケーション側に移行する。
    Prolog に詳しければ,それがルールベースの宣言文を評価する推論エンジンを組み込んだ宣言型言語であると知っているだろう。
    Datalog はルールとデータソースをパラメータとして取得する Prolog のサブセットだ。
    Datomic ではその Datalog をスカラやコレクションを扱うように拡張した上で,コード呼び出しを行う expression 句を追加している。



    Datalog - Wikipedia, the free encyclopedia

    Datalog is a truly declarative logic programming language that syntactically is a subset of Prolog.
    It is often used as a query language for deductive databases.
    In recent years, Datalog has found new application in data integration, information extraction, networking, program analysis, security, and cloud computing.



    Datomicのクエリーは、DatalogというPrologのサブセットを使用しているそうです。

    (参考)
    「10年先行く技術」のデータベースサービス、Datomicを試す | Developers.IO

    Datomicのアーキテクチャ

    Datomic情報モデル

    datomicチュートリアル1日目 - mike-neckのブログ




    音楽からプログラマーに転向…Datomicの作者であるリッチ・ヒッキー氏は、スゴイ人みたいですね!

    プログラミングClojure 第2版
    Stuart Halloway and Aaron Bedra
    オーム社
    2013-04-26
    ¥ 3,672


    【“変更不可なAppend-onlyデータベース「Datomic」”の続きを読む】

    外部キーのデメリットとIDリクワイアド

    このエントリーを含むはてなブックマーク はてなブックマーク - 外部キーのデメリットとIDリクワイアド あとで読む
    RDBの設計で、先駆者のお知恵を拝借したい。

    ・主キーは、自然キーか代理キーか?
    ・外部キーは、不要か?

    調べてみたら、少し混乱してきた。
    いろんな派閥があるみたいだけど、どれも一長一短で、各立場に一理ある?

    派閥とベン図


    2006-08-22 - 極北データモデリング

    ABDでは、外部キーを、resourceだけでなくeventからも追放する。
    楽々ERDレッスンで提唱されていた「コードを外部キーにしない。identifierを外部キーにする」ということを徹底すると、外部キーというものの意味が変わってくる。
    ていうか意味が純化される。外部キーとは、「記録しておきたい事実」そのものではなく、記録したい事実を参照するためのポインタになる。



    ABDの感想 - 世界線航跡蔵

    resource の中に Relationship(外部キー)が混在していることのおかしさ

    IREが沢山発生してしまうことによる結合コストを減らすための最適化テクニックとして混在させるというのはそう変な話じゃないのだと思う。


    ※IRE = Inter Relation Entity (相互関連実体)

    実装のために設計を崩すってこと?

    俺も外部キー使いまくりだけど、その方がJOINが楽だしね?

    【DB】 サロゲートキー(代理キー)の初歩

    ここまでくると、トレードオフの問題ですね。
    サロゲートキーを使うと変更に強くなります。よって保守性があがります。
    が、論理設計上必要ないものを組み込むので設計がわかりづらくなります。サロゲートキーに頼ってモデリングが甘くなる傾向を指摘する記事もあります。設計がわかりづらい、甘いシステムは保守性が落ちます。
    要は正しくサロゲートキーを使用しましょうということ。



    代理キー(サロゲートキー)は、ただのポインターだから、
    導入したからって、設計が分かりづらくなるとは思えんのだが?

    俺は、連番をidにするのが変だと思っていて、seqにしとけや!と思ったよ。
    「id」以外で、主キーのカラム名は何がいいだろ? - 浜村拓夫の世界

    ・seq (sequence) → 連番
    ・id (identifier) → 連番以外のイミュータブル(不変)の値
    が良いと思ったんだけど。。。

    自然キーが、UPDATEで変更されない=イミュータブルなら、自然キーをインデックスとして使いやすい形に加工して、パフォーマンス(実装の改善)のために、代理キーとして使えばいいじゃん!と思った。

    連番とか乱数は、再現性に欠ける要素があるので、キーとしては使いたくないのね。
    ・変化ってのは、時間によって生じる。
    ・不変ってのは、時間軸が除去された状態で生じる。

    RDBのキーは、変化に強い=不変性があって欲しいんだよね?
    「イベント」じゃなくて「リソース」のテーブルなら、「不変」かつ「再現性」のあるキーが付与できると思うんだけど、RDBの教科書の一番最初に書いておいて欲しい事柄なんだよね。

    SQLアンチパターン
    Bill Karwin
    オライリージャパン
    2013-01-26
    ¥ 3,456


    SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版) from Takuto Wada


    「SQL アンチパターン」を読んだ - tsucchi の日記 2nd season

    IDリクワイアド(とりあえずID)

    ・複合主キーを使うべきテーブルに「id」を付けるな、ってのはその通りだと思う
    ・自然キーも上手く使えってあるんだけど、これは反対
    ・テーブル名が Bugs なら主キーは id じゃなくて、bug_id にしとけ、ってあるんだけど、これは微妙

    自然キーですが、僕は基本的にサロゲートキーでやるべきだと思っています。自然キーには必要に応じて一意制約をはるのがいいかな。経験上、自然キーが本当にキーだったことは一度もありませんでした。何か追加の情報(リビジョンとか日付とか)入れれば主キーに大抵なるんですが、そんなんやるくらいなら、サロゲートキー入れたほうがよっぽど楽だと思います。



    複合主キーを避けるべき理由 - 虎塚

    サロゲートキーの必要性
    さて、ここまでは、「複合主キーを避ける」という視点から考えました。ここで、サロゲートキーの必要性を理解する、という視点で考えてみます。
    「ナチュラルキーによる複合主キーでも、行のアイデンティファイアを担保できるのではないか?」という疑問が浮かぶかもしれません。
    これに対しては、「技術上可能だとしても、論理上おかしいから、そういうことはしない」というのが答えだと考えます。
    たとえば、データベースの会員テーブルで同姓同名の人を管理する場合、IDを使って識別します。これは、個々の行が別々のデータを表すからです。たとえ、氏名カラムと登録日時カラムを複合キーとして使うことで行を一意に特定できるとしても、そうしないでしょう。
    というわけで、「実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける」という結論に行き着きました。



    会員テーブルで、同姓同名の人がいた場合、誕生日とか住所とか、他の属性と組み合わせれば、複合主キーとして使える。
    名前だけでは、重複が許されるので、主キーにならない。
    名前という自然キーだけでは、主キーにならないことは多々ある。
    →ある自然キーが世界に1個しかないという前提は、単なる思い込みでしかなく、そもそも間違っている場合が多いと。

    外部キー - Wikipedia

    外部キー(がいぶキー、英語:foreign key、FK)は、コンピュータの関係データベースの関係モデルの文脈において、2つの関係変数(テーブル)の間の参照整合性制約をいう。

    外部キー-主キーの関連を本来は設計の観点から存在していてはならない場合に存在していることや、外部キー-主キーの関連が本来は設計の観点から存在しているべきである場合に存在していないことは、関係データベースおよびデータモデリング、データベース設計についての多くの問題の原因となっていることが多い。



    RDBMSに外部キーは必要か? - plusadd blog

    外部キーについては,MySQLのサイトにメリットとデメリットが記述されている.

    MySQL 4.1 リファレンスマニュアル :: 1.8.4.5 外部キー

    メリット
    1) 関係が適切に設計されている場合、外部キー制約によって、プログラマがデータベースで不整合を引き起こすことが少なくなる。
    2) 連鎖更新および削除を使用すると、クライアントコードを単純化することができる。
    3) 適切に設計された外部キールールは、テーブル間の関係の記述に役立つ。

    デメリット
    1) キー関係を設計する上で犯しやすい間違いによって、循環ルール、連鎖削除の不適切な組み合わせなどの深刻な問題が生じることがある。
    2) データベースレベルでの余分なチェックによって、パフォーマンスに影響が生じる。そのため、一部の主要な商用アプリケーションでは、アプリケーションレベルでこのロジックがコード化されている。
    3) DBA にとって、個々のテーブルのバックアップやリストアが非常に困難になり、場合によっては不可能になるような複雑な関係のトポロジを作成することはめったにない。



    A→B→C→D→E とか、外部キーの連鎖が多段になってる場合、面倒くさそう?

    主キーと外部キーの設定について、ベストプラクティスを紹介している本とかWebサイトがあったら教えて!!!

    13歳からの論理ノート
    小野田 博一
    PHP研究所
    2006-09-21
    ¥ 1,188

    RDBの交差エンティティ

    このエントリーを含むはてなブックマーク はてなブックマーク - RDBの交差エンティティ あとで読む
    DBの設計で、T字形ERとか、ABD(Activity Based Datamodel)を勉強したら、
    「交差エンティティ」という仕組みを使うことが有用だと分かった。

    イミュータブル(不変)なDB設計 - 浜村拓夫の世界

    交差エンティティ - Google検索

    30分でわかるER図の書き方 (10) - とあるソフトウェア開発者のブログ

    交差エンティティ(intersection entity)と呼ばれるエンティティを導入することで、多対多のデータを保持できるようになります。



    RDBのテーブルは、
    ・マスター
    ・トランザクション
    の2区分ではなく、

    ・リソース
    ・イベント
    の2区分で見ると分かりやすい。

    テーブル間の関連性は、関連テーブルでつなぐ。
    1:1、1:多、多:多~どの関係でも、間に関連テーブルがはさまっていると、テーブル同士が疎結合になり、変更に強い設計になる?
    =ビジネスロジックに変更が生じて、ルールが変わったら、関連テーブルを追加・変更すればいいだけ?

    多:多の場合、間にはさまる関連テーブルのことを、
    「Intersect (Link) Entity」
    「交差エンティティ」
    「交差表」
    「連関エンティティ」
    「関係エンティティ」
    等と呼ぶらしい。

    関連テーブルをはさむと、テーブル数が増えるかな?
    SQLでJOINが多発しそうなら、JOIN後のVIEWを作っとけばいいのかな?

    Seasar Conference 2006 Spring (5) - 世界線航跡蔵

    イベント系重要

    まずは、『楽々ERDレッスン』の簡単なまとめをさらっと触った。一言で言えばnatural keyじゃなくidを付番するのが重要ということ。

    そして、その上で「イベント系重要」という話があった。

    マスターテーブルは確かに重要だけれども、それだけあっても仕方がないよね、と。顧客マスター、商品マスターだけあっても仕方がない。顧客だけ、商品だけあっても仕方がない。その間に「売り上げ」がなければビジネスにならない。商品、顧客のようなリソース系も大切だけれども、イベント系こそが真に重要である。

    イベント系って何かと言えば、顧客と商品が交差するのが売り上げであるように、交差エンティティである。そして、交差エンティティがまた他のエンティティと交差するかもしれないから、交差エンティティにも「id重要」。



    イベント系のテーブルは、交差エンティティとして振る舞っている?

    イベントは時系列で発生していく→履歴テーブル、更新ログになるから、
    UPDATEもDELETEも無しで、ひたすらINSERTしていけば良いのかな?

    楽々ERDレッスン (CodeZine BOOKS)
    (株)スターロジック 羽生 章洋
    翔泳社
    2006-04-18
    ¥ 2,376

    イミュータブル(不変)なDB設計

    このエントリーを含むはてなブックマーク はてなブックマーク - イミュータブル(不変)なDB設計 あとで読む
    RDBの設計、モデリング手法について調べていたら、我流の欠点が見えてきた。

    イミュータブルデータモデル(入門編) from Yoshitka Kawashima


    イミュータブルデータモデル(世代編) from Yoshitka Kawashima


    イミュータブル - Wikipedia

    オブジェクト指向プログラミングにおいて、イミュータブル(immutable)なオブジェクトとは、作成後にその状態を変えることのできないオブジェクトのことである。対義語はミュータブル(mutable)なオブジェクトで、作成後も状態を変えることができる。

    イミュータブルなオブジェクトを使うと、複製や比較のための操作を省けるため、コードが単純になり、また性能の改善にもつながる。
    しかしオブジェクトが変更可能なデータを多く持つ場合には、イミュータブル化は不適切となることが多い。
    このため、多くのプログラミング言語ではイミュータブルかミュータブルか選択できるようにしている。



    最近、DBの設計で、論理削除はダメだという話が盛り上がっていた。
    Kazuho's Weblog: さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku」を作ってみた
    Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か
    論理削除が云々について - mike-neckのブログ
    RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita

    上記のスライドを見て、CRUDのUやDの問題点について、少しずつ理解してきた。
    参考文献に挙げられていた「楽々ERDレッスン」も読んでみた。

    楽々ERDレッスン (CodeZine BOOKS)
    (株)スターロジック 羽生 章洋
    翔泳社
    2006-04-18
    ¥ 2,376


    以前、主キーについて悩んだことがあったけど、ミュータブル前提だったから、生じた問題だったと分かった。

    衝突しにくいハッシュ値をMySQLの代理キーにする方法 - 浜村拓夫の世界

    連番の欠点は、何かの事情で、連番カラムのデータが失われたら、再び同じ連番を各レコードに割り当てることがで困難であることです。
    物理的なデータ削除等で、連番に欠番が生じていれば、再度連番を割り当てても、ズレが生じます。
    主キーに、このような不安定要素を残しておくことは、堅牢なシステムとは言えません。



    「id」以外で、主キーのカラム名は何がいいだろ? - 浜村拓夫の世界

    テーブルが破壊されて、データを最初から流し込む必要があるとき、不要になったレコードがあって、レコード数が減ったりしていると、歯欠けになった分だけ、それ以降の連番の割り当てがズレちゃうんだよね。



    テーブルがイミュータブルで、DELETEが一切無ければ、連番が歯欠けになることはなかったんだね!
    主キーは、ただのポインターでOKと。

    なるほどー、と思うこと、しきり。
    もうちょい勉強してみよう!

    MySQLのカバードインデックス

    このエントリーを含むはてなブックマーク はてなブックマーク - MySQLのカバードインデックス あとで読む
    最近、MySQLでテーブルをJOINしまくったビューを作った。
    なんか動作が遅かった。

    チューンナップの余地があったのだろうけど、手が回らなかった。(反省)
    多分、インデックスの使い方が、間違っていたんだろうなー。(遠い目)

    T字形ER(TM)ってどうよ?

    T字型の残したものはインデックスオンリー(カバードインデックス)だけかのう。



    カバードインデックス
    カバリングインデックス
    非クラスタ化インデックス
    付加列インデックス

    呼び方がいろいろあるっぽいけど、このあたりでググると、参考情報が出てくるね?

    SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)
    ミック
    技術評論社
    2015-04-11
    ¥ 2,786


    【“MySQLのカバードインデックス”の続きを読む】

    T字形ER手法 (TM、T-formed ERD method) でプログラム設計

    このエントリーを含むはてなブックマーク はてなブックマーク - T字形ER手法 (TM、T-formed ERD method) でプログラム設計 あとで読む
    コンピューター(電子計算機)のプログラム(命令)を設計するとき、
    データの入れ物(永続化)も設計する必要があります。

    リレーショナルデータベースの構造を設計するとき、
    どんなデータを入れるか?という分析を行います。

    データモデリングには、いろいろな方法が提唱されていますが、
    T字形ER手法」という、効率が良さそうな?方法がありました。(メモ)

    「誰が作っても、同じ形になる」ならば…Pythonみたいだね?
    →正解が一元的に集約される仕組みなら、開発チーム内での齟齬=トラブル防止に役立つかな?

    【“T字形ER手法 (TM、T-formed ERD method) でプログラム設計”の続きを読む】

    RDFクエリ言語「SPARQL」(スパークル)

    このエントリーを含むはてなブックマーク はてなブックマーク - RDFクエリ言語「SPARQL」(スパークル) あとで読む
    SQLを拡張して?、SPARQLという仕組みが作られていた。

    SPARQL

    SPARQL - ウィキペディア

    SPARQL("スパークル"と発音)はRDFクエリ言語の一種である。
    その名称は再帰的頭字語になっており、SPARQL Protocol and RDF Query Languageの略。
    RDFクエリ言語とは、Resource Description Framework で記述されたデータを検索/操作するコンピュータ言語である。
    SPARQL は World Wide Web Consortium (W3C) の RDF Data Access Working Group (DAWG) による標準化作業が行われている。

    SPARQL はクエリのパターンとして、論理積、論理和、その他のパターンを指定可能である。



    RDBは、スキーマレスなデータを取り扱うことが苦手だ。
    Webデータって、構造化されてるのかな?

    SPARQLってのが便利そうなら、使いどころを考えてみよう。(金儲け)

    セマンティックWeb プログラミング
    Toby Segaran / Colin Evans / Jamie Taylor
    オライリージャパン
    2010-06-26
    ¥ 3,456

    ETLツールでデータクレンジング

    このエントリーを含むはてなブックマーク はてなブックマーク - ETLツールでデータクレンジング あとで読む
    ITシステムを改修すると、リレーショナルデータベースの保守が必要になる場合があります。
    データベースの保守で、「ETL」というツールが役立つ場合があります。

    ETLとは 【 Extract/Transform/Load 】 【 ELT 】 - IT用語辞典

    企業の基幹系システムなどに蓄積されたデータを抽出(extract)し、データウェアハウスなどで利用しやすい形に加工(transform)し、対象となるデータベースに書き出す(load)こと。また、これら一連の処理を支援するソフトウェア。

    データウェアハウスを構築し、分析を行うためには、業務システムで発生したデータをデータベースに収納する必要がある。従来、この作業は専用のプログラムを開発しなければならず、ETL作業が全体の工数の半分以上を占めると言われていた。

    最近では、ETLツールの登場により、短期間に容易にETLシステムを構築できるようになった。ETLツールには、GUIを使ってデータの流れをビジュアルに構築するツールや、データ形式の変換機能、不正なデータを排除したり一定の形式にデータを修正するデータクレンジング機能などが搭載されている。



    データクレンジングとは 〔 データクリーニング 〕 〔 クレンジング 〕 - IT用語辞典

    データベースに保存されているデータの中から、重複や誤記、表記の揺れなどを探し出し、削除や修正、正規化などを行い、データの品質を高めること。

    具体的な手法はデータの種類により千差万別だが、一般的な例としては、全角文字と半角文字の違いや、空白文字や区切り記号の有無、人名の異体字の誤りや姓名の分割・併合、法人名の表記(株式会社と(株)の違いなど)、住所や電話番号の表記法などが対象となり、それぞれについて表記ルールを決めて修正・削除などを行なっていく。



    National Clinical Database の医療ビッグデータ - 浜村拓夫の世界

    ●プログラマーの貢献
    NCDのデータを基にして、エキスパートシステムを構築すべきでしょう。
    =医師が適切な治療法を採用することを支援するサービス。
    その前段階として、ETLツール等で迅速にデータマイニングできるサービスを作れば良いでしょう。



    ある程度簡単なデータの保守作業であれば、簡易なETLツールを自作して、データの掃除を行えばOK
    商用ETLツールの機能や特徴について、学んでみたいと思います。

    達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ
    ミック
    翔泳社
    2012-03-16
    ¥ 2,808

    phpMyAdminの代わりに「adminer」を使ってみた

    このエントリーを含むはてなブックマーク はてなブックマーク - phpMyAdminの代わりに「adminer」を使ってみた あとで読む
    最近、phpMyAdminが重たくて、画面表示が遅くて困っていました。
    とりあえず、phpMyAdminの代わりとして、「Adminer」というツールを使ってみたら、こちらは軽くて、動作がサクサクになりました!

    Adminer


    Adminer - Database management in a single PHP file
    http://www.adminer.org/

    シンプルで使いやすくて機能十分!ファイルを1つ置くだけのphpMyAdmin代替ツール「Adminer」 | ITキヲスク

    超絶便利なphpMyAdmin代替ツールを発見しましたので、ご紹介☆
    たった1つのphpファイルで出来た「Adminer」は、めっちゃ使いやすい上に、インストールもサーバにこの1ファイルをアップするだけ!

    ただし1点、このファイルをアップしただけのままだと誰でもアクセスできちゃうので、まぁ気になる場合はベーシック認証などをお忘れなく。



    Adminerは、たった1ファイルで、フットプリントは286KBと小さいので、
    使うときだけWebサーバに置いて、使い終わったらファイルを削除する、
    という使い方もできますね?


    【“phpMyAdminの代わりに「adminer」を使ってみた”の続きを読む】

    FC2Ad