※<（日本酒大好き）>からの転載です。元の日付は2014-05-23です。 ------------------------------------------------------------------------------------------------------------ 私はブログのタイトル通り、システム管理者をやっています。社内のパソコンはテスト用など一部を除いてActiveDirectory（ドメイン）に参加させて管理しています。 ActiveDirectoryというかドメインの機能として、配下のクライアントはドメインコントローラの時刻に自動的に同期する機能があるため、一つのドメイン環境下では、基本的に全コンピュータの時計は同じ時刻を指すはずなんです。 と ころがある日、女子社員の一人が「私のパソコンの時計5分ぐらい遅れてる～！」というと、他の女子社員も「私も～」

データベースまわりでカーディナリティとか濃度という言葉がバラバラの意味で使われているので整理する。 以下の３種類の使われ方がある。 1. relationのカーディナリティリレーション中のタプルの数（不正確に言えばテーブル中のレコード数）をカーディナリティという場合。 これが原義。 Date「データベースシステム概論」P-90 一つの組(tuple)は表の一つの行に対応し、一つの属性(attribute)は一つの列に対応している。 組の数は濃度(cardinality)とよばれ、属性の数は次数(degree)とよばれる。 2. relationshipのカーディナリティエンティティ間の関係が1対1・1対多・多対多のどれか、ということをカーディナリティという場合。 3. キーのカーディナリティキーの値の数と、全レコード件数との比を、カーディナリティという場合。 日本語の「濃度」のイメージに近

クライアントとDBサーバ間のネットワークがボトルネックになる2つのケース これまで、大規模データ処理RDBMSの2大ボトルネックであるI/OとCPUについて、発生の原因と改善策を紹介してきました。その2大巨頭に隠れて目立たないのですが、大規模データ処理を行う際には、I/OやCPUと同じくらいネットワークもボトルネックになりやすいものです。 ネットワークがボトルネックになるケースとしては、以下の2つがあります。 DBサーバとストレージ間のネットワークI/O クライアントとDBサーバ間の結果セット転送 前者は第2回、第3回で紹介しているので、今回はクライアントとDBサーバ間のネットワークに焦点を当てて解説していきます。 大規模データ処理を行うRDBMSにおいて、クライアントとDBサーバ間のネットワークがボトルネックになる代表的なケースは下記の2つです。 ケース① ⇒ DBサーバがクライアントに

MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select

MySQL 5.7には150を超える新機能がある。 MySQLのマニュアルはとてもいいものだが、少し長すぎる。これは、新機能の箇条書きリストだ。それぞれの機能について1つずつまとめるように頑張ってある。なので、 InnoDBのネイティブパーティショニング については、InnoDBの項かパーティショニングの項のどちらかにだけ載っている。 MySQL 5.7.8 RC2はここからダウンロードできる それか、yumかaptのリポジトリーからもインストール可能だ。 レプリケーション関連 マルチソースレプリケーション(訳注: 1スレーブに複数マスターを設定可能になった) [ 1 ] オンラインでのGTIDの有効化 [ 1 2 3 ] 準同期レプリケーションの性能向上 [ 1 2 ] ロスレス準同期レプリケーション [ 1 2 ] 準同期レプリケーションでいくつのスレーブからACKが返ってくるまで待つ

WPFに触れたことのある人ならバインディングの便利さを知らぬ人は居ないでしょう。これはその骨にあたる部分の話です。 DependencyObjectを継承したクラスにはDependencyPropertyを使用することができます。これは通常の依存関係プロパティとしてでなく、添付プロパティ、継承プロパティなどにも使用することができます。 そのほか値の有効性の判定や、変更時のコールバックやイベントなどの機能。デフォルト値から変更しなければメモリが節約されること、メタデータの設定に応じて様々な付加機能が使えるところなど、究極的に便利なプロパティです。本当に手厚いものです。 便利である反面、以下のような分かり易いボトルネックを持っています。 DependencyPropertyは内部の情報保持はObjectであるため、値型を格納する際はボックス化、アンボックス化のコストを必ず持ちます。つまり、GC

大きなサイズのインデックスを生成しようとするとERROR 1071が発生することがあり、そんな時にはinnodb_large_prefixパラメータを利用すると良いことがある。 MySQLのInnoDBストレージエンジンのテーブルの長いvarcharカラムを含むカラムにインデックスを生成しようとしたことがあれば、このエラーを見たことがあるだろう。 ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes 文字数制限は、使っている文字コードに依存する。例えば latin1 であればインデックスを生成できる最大カラムは varchar(767)であるが、 utf8 の場合は varchar(255) までである。 インデックスあたり、3072バイトという別の制限もある。767バイトはカラムごとの制限な

今日は最近出たリレーショナルデータベースの入門書を2冊紹介しよう。献本御礼！！ おうちで学べるデータベースのきほん まずはミックさんと木村さんによる「おうちで学べるデータベースのきほん」だ。「おうちで学べる」シリーズのものだが、とても充実した内容のリレーショナルデータベースの入門書となっている。これからデータベースを本気で始めようと考えている超初心者の人には最適な一冊ではないかと思う。例えば次のような内容は、データベース運用の雰囲気をつかむのに持ってこいである。 クライアントサーバーについて 3層アーキテクチャ データベースにまつわるお金の話 トランザクション 正規化 パフォーマンスの話 無論、これは入門書なので、この本だけを読めば実践でデータベースを使えるようになるというものではない。本書を読破したあと、更に多くの学習や経験が必要になるだろう。データベースの門戸を叩く取っ掛かりとしては、

XamDataGridは、非常に多機能なコンポーネントです。XamDataGridは、http://infragistics.com/DataPresenter名前空間を定義することで使用することが出来ます。通常のXAMLのコレクションを表示する系のコントロールはItemsSourceプロパティにコレクションを設定して使用しますが、XamDataGridはDataSourceプロパティにコレクションを設定することで、データの表示をすることが出来ます。 例として以下のようなPersonクラスのコレクションを持ったMainWindowViewModelクラスをDataContextに持ったWindowにXamDataGridを配置してデータを表示させたコードを示します。 using System; using System.Collections.Generic; using System.L

データ・モデリングの普及団体，DOA+コンソーシアムはこのほど，リレーショナル・データベース管理システム（RDBMS）の処理性能に関する実証試験を行い，調査結果を公開した。「データを正規化してデータベースに実装すると，処理性能が低下する」という“誤解”を正すため，実証実験を行ったという。 データを正規化して実装したときと，非正規化して実装したときの処理性能の違いを調べた結果，「正規化して実装したデータベースの方が処理性能が高い」，「非正規化して実装したデータベースを操作する際，テーブル結合（JOIN）が発生する処理を行うと，処理性能が低くなる」と結論付けた。 実証実験では，自動車の受注業務を想定したWebシステムを構築して，処理性能を測定した。このWebシステムは，データベース上に格納された受注データを基に，製品データや部品データ，部品メーカのデータなどを検索する。 データベース実装の違い

リレーショナルモデルを実践するには、ドメイン（≒データ型）を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性（≒カラム）に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その

WPFで少しスクロールの制御をする必要がありました。ItemsControl系のコントロールでですね。ということで調べてみた感じこんな方法がありそうっていうのでメモ。 足場作り まず、サンプルの説明用の足場を作ります。画面上部にStackPanelを置いて画面の下部にListBoxを置いただけのシンプル画面です。データを読み込むボタンと、各スクロール方法の処理を書いてるボタンが置いてあります。 <Window x:Class="ScrollSample.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="MainWindow" Height="350" Width=

Mikiya Okuno @nippondanji 第一正規形の条件は、テーブルがリレーションの性質を満たすこと。何故ならば、正規化はリレーショナルモデル上での設計理論なので、リレーションにしか適用できないから。だからNULLを含んではいけないし、繰り返しグループは許容されず、ドメインの設計がしっかりできていないといけない。 2015-03-31 22:23:44 Mikiya Okuno @nippondanji リレーショナルモデル上の設計理論は、対象がリレーションであるから実行できる。ということは、リレーションになれないデータには正規化も適用できない。なので「テーブルを全部正規化せよ」という方針は破綻してしまう。 2015-03-31 22:26:02 Mikiya Okuno @nippondanji テーブルを正規化すべきかの判断は実は至ってシンプル。それはリレーションか否か。あ

4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にした本で、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。

とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー（代理キー）」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、本質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル（≒行）の値を一意に決定することができる属性（≒カラム）の集合」の

今日は徒然なるままにDB設計について思っていることを並べてみようと思う。 ようやくWEB+DB Pressの次号の原稿を書き終えた。2年間の連載であるが、来年はプライベートが忙しくなる予定なので、連載はこれにて終了とさせてもらうつもりである。 「なぜ人はリレーショナルデータベースを使いこなせないのか」 このところ執筆や講演を通じてリレーショナルモデルについて説明する機会を色々頂いているが、それらの活動の根源となっているのが、この素朴な疑問である。その疑問をパワーにしてこれまで活動を行なってきた。 現時点での自分の回答は「データベース設計が難しいから」である。もちろんリレーショナルモデルそのものの難しさというのもあるが、それよりは「適切な使い分けができていない」ということが大きいように思う。言葉を変えると、リレーショナルモデルを適用すべきデータとそうでないデータの判断ができていないからDB設

熱力学の第一法則にある通り、エネルギーというものは破壊することができない。ただ、ある形態から別の形態に変化するだけである。この自然法則はビジネスの話にも当てはまる。ある会社に対して良からぬことを行えば、いつの日かその会社にしっぺ返しをされかねないのだ。 検索エンジンのグーグルが、現在使用しているオラクルMySQLリレーショナル・データベースのシステムの全てを、MySQLから派生したMariaDBに移行することを決めた。これに関し、公式な理由などはおそらく何もないだろう。意図的ではないのかもしれないが、そこには明らかにオラクルに対する因縁めいた物が感じられる。 オラクルはここ数年間、グーグルがAndroidオペレーティングシステムにJavaコードの一部をコピーしていることと、37のアプリケーション·プログラミング·インターフェースにJavaプログラミング言語を利用していることで、著作権侵害を