2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。Read less
イミュータブルデータモデルの極意
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。Read less
ビジネスプロセスモデリング表記法 - Wikipedia
ビジネスプロセスモデリング表記法（英語: Business Process Model and Notation, BPMN）とは、ビジネスプロセスをワークフローとして描画するための表記法である。BPMN は Business Process Management Initiative (BPMI) が開発し、Object Management Group (OMG) と BPMI が 2005年に合併した後は OMG が保守している。 BPMNによるBPD（BP図）の例。BPMNとは、ユーザがシステムに要求する業務の流れを記述した図 BPMN の目的は、すべてのビジネス関係者が容易に理解できる標準記法を提供することである。ビジネス関係者には、プロセスの作成・更新を行うビジネスアナリスト、プロセスの実装を行う技術者、プロセスを管理するマネージャなどが含まれる。さらに BPMN はビジネスプ
開発現場ですぐに通用する"今どきの"モデリングテクニック | ウルシステムズ株式会社
パート2では「開発プロジェクトの工程全体の中におけるモデリング」という視点から、実際のモデリングに必要な要素や具体的な作業の進め方を解説していきます。なぜそのような視点にしたのかは本編で述べていますが、基本的には筆者のこれまでの経験上、実際の開発現場で通用するモデリングのスキルを取得するにあたっての最短の近道だと考えるからです。これまでのモデリングに関する書籍や記事とは一味違った切り口での説明になると思いますが、どうぞ最後までお付き合いください。 "教科書に載っていない"モデリング作法とはこれまでに筆者は、データモデリングに関する数多くの書籍や雑誌／Webの記事を読んできました。それらから得た知識は、確かに実践の中で活かされてきましたが、実際のプロジェクトでDB設計を担当するとなると「記事には載っていない何か」が現場では必要になったのです。世の中にある、多くのモデリングに関する書籍や記事に
分類集計コード
前回書いた「コード設計の話」でちょっとふれた「ロールアップコード」と「階層化コード」について補足しておきたい。両方とも細かい点を除けば同じ性格のものなので、ここでは「分類集計コード」と呼んでおく。 「コード設計の話」では、分類集計コードは「無意コード化の原則」に違反していないかという問題を採り上げ、だいじょうぶという判断をした。しかし、だからといって他の通常の無意コードとまったく同様とみなしてよいわけではない。分類集計コードを使用するさいには注意が必要だ。 具体的にいえば、分類集計コードは、分類される側のエンティティの識別子として用いるべきではない。たとえば、「製品分類コード」を設けて製品（脚注①）を分類するとしよう。このとき、分類される側である「製品」の識別子として製品分類コードを用いるべきではないということだ。 製品としての実質には変化がなく、分類だけ変わってしまうことがある。むしろ分
コード設計の話
今日は地味な話をしたい。といってもいつも地味な話だが。コードや区分の設計は良いシステムを設計するうえでとても大切である。設計にあたっては業務要件をみたすためにどんなコードや区分が必要かという視点が最初にくるのはもちろんだが、それ以外にも考慮すべきことがある。変なコード設計のもとでプログラムを書くと条件判定が複雑化し、読みにくく変更しにくいシステムができあがる。 ここで書くことは、経験のある設計者はたぶん（私のように）先輩から教わるとか自分で体得しているのもので目新しくはないが、まとめて整理してある本も意外にないようである（私が知らないだけかもしれない）。 無意コード化 無意コード化とはコードの各桁に意味を持たせないことである。これは、わりに良く知られている原則だ。「コードの各桁に意味を持たせる」とは、たとえば品番の頭1桁が"9"ならサービスパーツと判断するといった処理をプログラムのなかに記
主キーの設計⑥－数学をちょっとだけ（その３）
シリーズになってしまった「主キーの設計」も今回でようやく終わりだ。前々回ではリレーションに対する代替案として「リレーション関数」なる概念をひねり出した。前回はリレーション関数モデルの上で正規形と正規化を再定義した。今回はリレーション関数モデルに関係代数を移築する。 関係代数とは 関係代数は、リレーションの集合と、その上に定義されたいくつかの演算からなる体系だ。演算の数え方は人によって違うようだが、制限(restriction)・射影(projection)・直積(production)・和(union)・差(difference)・共通部分(intersection)・結合(join)・商(division)の８つを想定すれば十分だろう。ここでのポイントは、この体系がこれらの演算に関して「閉じている」という点だ。すなわち、リレーションに上記いずれかの演算をほどこして得られる結果は、やはりリ
主キーの設計⑤－数学をちょっとだけ（その２）
前回に引き続いて数学である。前回は「リレーション」の代わりに「リレーション関数」を土台としてリレーショナルモデルを再構築できないか、という提案をした。そして「リレーション関数」の数学的定義を作ってみた。今回は、この新たな基礎の上に、正規化理論を移築できないかを検討する。 ちょっと補足すると、正規化理論は関係代数に依拠しているので、先に関係代数を移築し、その後に正規化理論に取り組むのがスジかもしれない。しかしデータモデルを作る上で、まず必要なのは正規化理論であって関係代数ではない。なので、あまり堅いことを言わずに、正規化理論から始めることにするわけだ。 正規形の定義 出発点として、リレーショナルモデルでの「正規形」の定義を確認しておこう： リレーションを構成する属性値集合がいずれも、構造をもたない単純な値（＝スカラ値）の集合であるとき、かつそのときに限り、そのリレーションは第1正規形 (1N
主キーの設計④－数学をちょっとだけ（その１）
主キー論争の分析その④である。 といっても、前のエントリーですでに、主キーの存在を抹殺したので、論争の焦点そのものが雲散霧消してしまった。今回は付け足しとして、数学の話をする。 この「主キーの設計」シリーズ、僕は近年稀に見る気合をいれて書いているのに、悲しいことに回を追うごとに読者は減っているようだ（：_；）。今回でさらに減ること請け合いだ。 読みたくない人は読まなくてよろしい（でもヒマだったら読んでね）。 さて取り掛かる前に、やるべき作業の全体像を鳥瞰しておこう。 僕らの目標は、リレーショナルモデルに「エンティティ参照」の概念を組み込むことだ。 リレーショナルモデルは、大雑把に言えば、リレーションの数学的定義を土台として、その上に関係代数と正規化理論が乗っかる構造になっている。 ここで明らかなのは、僕らの目標を達成するには、「リレーション」をそのまま使うわけにはいかない、ということだ。前
主キーの設計③－いいとこ取りは可能か？
主キー論争の分析その③である。 前のエントリーでは、コード派とID派の意見の相違の源泉には、コッド博士が作り出した正規化の理論の取り扱いをどうするか、という問題が横たわっているという仮説を提示した。そして、正規化の理論には「エンティティ」の居場所がなく、したがって（実質はエンティティ参照である）IDにも居場所がない、という僕の理解を説明した。 このことの結果として、正規化の理論を重視すると、設計段階でのIDの導入には慎重にならざるを得ず、IDの使用は認めたとしても「実装テクニック」と位置づけることになる。一方、関連の実装に外部識別子（ユーザが認識しているコードのたぐい）を用いることによってもたらされる弊害（前々回説明した）を気にする人々は、IDの導入に積極的であり、数学的な意味での正規化の実効性に対しては批判的となる。 このような説明が「コード派」と「ID派」の議論の構図を模式的に表したも
主キーの設計②－正規化って何ですか？
主キー論争の分析その②である。 前のエントリーでは、最終的にできあがるデータベースの形について検討した。僕の結論は、内部識別子（アソシエーションの実装用の識別子）としてIDを用いることについては、コード派もID派も同意できるのではないかというものだった。 僕としては、コード派とID派の違いは、むしろ、今回検討するデータ設計の方法論に関するものだ、と思っている。 もっと具体的に言おう。誰でも、コッド博士が作り出した正規化の理論に忠実に従おうとすれば、ほぼ間違いなく「コード派」になってしまうのだ。なぜなら、正規化の数学理論には、IDとか（IDのウラにある）エンティティという概念が登場する余地がないからである。 正規化の理論の正確な意味（数学的な意味）は、設計の現場では明確には意識されていないし、意識しなくともデータベース設計はできてしまう。しかし、コード派とID派の論争のみなもとはここにある（
主キーの設計①
主キー論争（データベース設計で、どういうものをテーブルの主キーとすべきかという議論）が再燃しているようだ（こことかこことかこことかここ）。 これはかなり以前からある論争で、大雑把にいうとコード派とID派という二つの立場の間で戦われている。 コード派 … ユーザの目に触れるデータ項目（典型的にはコード）を主キーとする。複合主キーを許す。 ID派 … ユーザの目に触れないデータ項目（自動生成したID）を主キーとする。複合主キーを許さない。 僕としてはいずれも一長一短あると思うのだが、両派なんとなく主張がすれ違っているようにも見える。やはりまず、主キーとは何かというところに立ち戻って考えないと、論点が見えにくくなるんじゃないだろうか。 主キーには以下の二つの機能がある。 ユーザーからコンピュータシステムに対する要求において、対象データを一意に指定する手段を提供する（外部識別子機能） エンティティ
データモデル洗練テクニック－「スコープ概念の抽出」と「参照関係の逆転」
データモデルを設計するときに役立つかもしれないテクニックをひとつ。 X社では得意先ごとに異なる条件で売掛金を回収している。だから、売掛金管理システムでは、回収条件を得意先別に登録できるようにしたい。また、1ヵ月後に20%、2ヵ月後に残り全額といった分割回収もある。回収条件を表にするとこんな感じだろうか。 A社は2ヵ月後100%回収、B社は上述した通りの分割回収の例だ。これをデータモデルに落とすと、こうなる。 このモデルは直観的にわかりやすく、このままでも、まあまずくはない。しかし、あえてもう少し考えてみよう。僕が気になるのは回収条件の一意キーに含まれている[得意先]だ。これは何のためにあるのだろうか。よく考えると、[得意先]は２つの機能を担っていることがわかる。 回収条件は、複数（1つ以上)の行が集まって、意味あるひとつの単位となる。[得意先]はそのまとまりを識別する機能を担っている。 －
逆方向バリデーションを自動化する - 設計者の発言
バリデーション（入力値の妥当性検査）の仕様を「テーブルの拡張定義」とみなして、アプリではなくＤＢ側に置く。これによってさまざまな効果がもたらされるが、その中で今回取り上げたいのは「逆方向バリデーションが自動化される」という利点だ。逆方向バリデーションはこれまで、個々の案件において場当たり的に対処されてきたグレーゾーンであった。これが自動化されることで、問題を構造的に扱えるようになる。 まず、「逆方向バリデーション問題」の様相を確認しておこう。たとえば、(1)の商品テーブル上には「販売まるめ数」があって、受注テーブルの「受注数」はその倍数値でなければいけないとする。この場合、受注データの保守アプリにおいて、販売まるめ数が'10'である商品Ａの受注数として'55'を指定するとエラーである。55は10の倍数ではないからだ。 (1)受注数は販売まるめ数の倍数であること [商品] 商品id、商品名、
マスターテーブルと「有効期間」 - 設計者の発言
マスターテーブルには「比較的変化しないデータ」が登録されるが、Ｍ＆Ａが常態化した結果、取引先マスターあたりは頻繁に変わるようになった。社名や取引条件が変わるだけでなく、複数の取引先が１社に統合されることもある。 ここらへんは、マスターデータに「有効期間」を設けるべきかどうかの問題としてしばしば話題になる。「有効期間を含むテーブルとの参照関係」の記事でも触れたが、もう少し補足しておきたい。結論を先に言えば「ケースバイケースではあるが、それほど神経質になる必要はない」ということだ。 まず、有効期間を伴わない通常例を見よう。(1)では、すべての属性項目が主キーであるidに関数従属している。 (1)期間管理しないパターン [得意先GRP] GRP_id、グループ名、... ＋ 012 Ｍグループ ｜ └―…[得意先] 得意先id、社名、GRP_id、... 00001 Ｍ社
「有効期間」を含むテーブルとの参照関係 - 設計者の発言
一次識別子に「有効期間」が含まれることがある。そんなテーブルに対して関連を張ってゆくと正規化違反を生じてしまうケースがある。これを避けるためには「動的参照関係」の知識と、これに対応した開発基盤が必要だ。よほど単純なＤＢでない限り「動的参照関係」のデータ要件は出現するものなので、実務者としてはしっかり理解しておきたい。 まず、有効期間とキーとの関わりを整理しておこう。「商品値引テーブル」を例にした場合のモデリングパターンをいくつか挙げよう。{...}内はキー（一次識別子）を表している。 (1)開始日・終了日ともに属性 [商品] {商品ID},商品名,... ＋ 12345 全自動漬物石ＴＳ１００ ｜ └―…[商品値引] {商品値引ID},商品ID,開始日,終了日,値引率,... 000001 12345 07/01 08/31 15 000002 12345 08/01 09/30
サロゲートキーの日常性と心得之条 - 設計者の発言
「モノクロとカラーのどちらの表現を選ぶか」と訊かれて、映画監督はなんと答えるだろう。おそらく「どちらかを選べだって？愚問だね。必要に応じて使い分けるだけさ」と答えるだろう。同様に「サロゲートキーと複合主キーのどちらの技法を選ぶか」なんて訊かれても困る。どちらも必要に応じて使うだけの話で、どちらかが強制されるようなものではない。 実際のところ、複合主キーと同様、サロゲートキーも必要不可欠な技法だ。それは設計者本人さえ意識しないまま、日常的に利用されている。たとえば多くの場合、受注テーブルの主キー（一次識別子）である「受注№」は、サロゲートキーの一種だ。次のモデルで説明しよう。 (1)受注情報のモデル１ [顧客] 顧客id,顧客名 ＋ ｜ └―…[受注見出し] 受注№,顧客id,受注日,... ＋ ｜ └―∈[受注明細] 受注№,明細行番,商品id, 受注数,納期,... 受注情報は、出荷情報
渡辺式データモデリングの復習 - プログラマの思索
渡辺幸三さんのデータモデリングの手法について、復習と理解のために残す。 以下メモ書き。 間違っていたらあとで直す 【1】サロゲートキーの注意点 サロゲートキーは、トランザクションテーブルに多い。 受注番号、注文番号のように、シーケンスとして単に採番される。 しかし、実際のテーブル設計では、サロゲートキーを持つテーブルは、主キーとは異なる一意なキー項目が存在する場合がある。 たとえば、商品マスタのJANコード、従業員マスタの社会保障番号などだ。 あるいは、発注テーブルの受払Noなどもそうだ。 サロゲートキーはWebシステムではとても相性が良い。 しかし、何でもかんでもテーブルをサロゲートキーによる主キーで設計すると、業務要件をカラム間の関数従属性で表現しきれなくなる。 すると、そのような従属性はアプリ層で実装するようになり、システムが肥大化していく弱点がある。 だから、一意制約を持つキー項目
Mac：graphvizやsemPathでパス図を描く - Qiita
共分散構造分析などでパス図を描くツールを探してみると以下２種類の方法が定番のようなので試してみました。お手軽なのはsemPlotですがgraphvizは自由度が高いです。 semPlot library(semPlot) X <- rnorm(100) Y <- rnorm(100) Z <- rnorm(1) * X + rnorm(1) * Y + rnorm(1) * X * Y DF <- data.frame(X, Y, Z) # 回帰分析 res <- lm(Z ~ X * Y, data = DF) # パスの描画 semPaths(res, whatLabels = "stand", style = "lisrel")
統語論 - Wikipedia
統語論（とうごろん、英: syntax）とは、ヒト・人間の言語（いわゆる自然言語）において文が構成（combine）される仕組み[1]、または、それ以外の形式言語なども含む言語学の対象である言語一般において文が構成される仕組み、及びそれを扱う言語学の一分野[1]である。統辞論（とうじろん）、構文論（こうぶんろん）ともいう。 統語論は文法［音韻論（音の仕組み）、形態論（語が構成される仕組み）などを含む、言語の構造を成り立たせている諸原理］ の一部である[1]。ただし、特に統語論のことを指して「文法」ということもある[1]。 生成文法[編集] "Colorless green ideas sleep furiously." の構文木。詳細にはXバー理論によるそれ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
聡 鳥谷部