IPA/SEC 統合モデリング技術WG 内田氏インタビューRustが再評価される：エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...
トランザクションデータ（とマスターデータ）について思うところ - 急がば回れ、選ぶなら近道
業務系のデータ処理では、大きくはトランザクションとマスターに分かれる。 マスターデータは特に、モデルや制御の方法が何かと面倒くさいので、よく議論になる。「マスターデータの管理の手法」というセミナーまで定期的に普通に開かれることも多い。他方、トランザクションデータ（以下TXデータ）は、普通に受け渡しのデータなので、フラットにダラダラ書いておけばよい、という扱いが大抵になる。そもそもER志向でモデルを設計すると、ほとんどは図面はマスターで占められ、TXデータはやたらなんか大量のフィールドを持つ大きなクラスがあるわいね、という扱いも多い。 あと、設計の観点からいうと、ERベースだとマスター設計が花形になる。まぁわかりやすいし、設計作業がしやすい。マスターは「構造」になり、TXデータは「構造」になりにくい。設計者は「構造」が好きだ。良くできた設計は確かに堅牢で、一定の変化にも追随できる。ある種の「
データモデリングのパターン
ほとんどの場合、私たちは、モデル化されるビジネスエンティティが何か直観的に分かります。つまり、顧客は顧客エンティティとしてモデル化し、請求書は請求書エンティティとしてモデル化します。その後、これらの抽象的な「エンティティ」を主キー制約や外部キー制約を備えたリレーショナルテーブルに変換します。 このような直観には、もちろんきちんとした方法論が存在します。その方法論とは、リレーションの正規化という理論であり、特に、関数従属性、多値従属性、および包含従属性について論じています。正規化の理論は難しすぎて十分理解できないという読者のために、Michael Blahaが最近出した書籍『Patterns of Data Modeling』では、スキーマデザインを考える新しい切り口として、オブジェクト指向アプリケーションプログラミングのデザインパターンに似た考え方を採用しています。本書は2009年の夏に刊
基本設計で作るべき「論理データモデル」の考え方
データモデリング作業の大きな流れ システム企画段階で作成した「概念データモデル」は、ビジネス活動を販売、製造などの機能分野単位で大きくとらえ、ER図で表現したものでした。データの視点で俯瞰（ふかん）的にビジネス活動をとらえることにより、企業が管理すべきデータが明確になります。販売機能分野における、販売計画から販売管理までなど、ビジネス活動のつながりも、データの視点で可視化することでシステム化対象範囲を確定することができました。次はこの「概念データモデル」をベースにデータモデリングを行っていきます。 一般的にデータモデリングは、論理データベース設計、物理データベース設計、データベース適用設計という流れで進めます。それぞれの設計段階で行うことを簡単に述べると、「データ整理」「データ調節」「データ実装準備」になります。 論理データベース設計（データ整理）： 管理対象となるデータを洗い出し、整理し
システム企画に役立つ概念データモデル作成の基本
概念データモデルの構成要素 概念データモデルは、システム化対象範囲にある業務プロセスをモデル化したもので、これを見ただけで企業のビジネス活動が分かるという大きなメリットがあります。図1の販売活動に焦点をあてた概念データモデルを例に、この企業の販売活動を読み解いてみましょう。 概念データモデルは「ハイレベルエンティティ」（図1緑色枠）、「識別子」（図1青色枠）、「リレーションシップ」（図1赤色枠）の3つから構成されます。 エンティティとそれを捕捉する識別子 まず、概念データモデルは企画段階で作成するものであるため、システム化対象範囲にあるデータ群を簡易的なレベルで表します。このデータ群が「ハイレベルエンティティ」（本稿ではエンティティと略記します）です。 これらエンティティを顧客コードや商品番号のような「ｘｘコード」、「ｘｘ番号」という「識別子」から捕捉します。 イベント系エンティティ、リソ
株式会社マジカジャパンの羽生章洋が書いてるブログ:基本に立ち返る - livedoor Blog（ブログ）
紆余曲折色々とありながらも何とか生き延びているスタロジですが、この厳しい世情を乗り越えていくためにはもっとフォーカスを鮮明にする必要があります。では自分たちの優位性・強みとは何か。その基盤とは何か。 ではその「開発生産性が高い理由」は何か。もちろんコードジェネレータがあるとかブリスタのような設計ツールがあるとか、数年かけて作り上げてきた諸々の設備（と敢えて言っておきます）があるというのは目につきやすいものです。ですが、それらはどういうフィロソフィの元に築き上げられてきたか。逆に言うと、スタロジはこれまでに色々と手痛い失敗もあったのですが、どういうときに失敗したのか。 失敗の理由はセールスだとかマネジメントだとか何だとか色々とあるのですが、それでも純粋に開発生産性と直結しているところで考えたときに、重要な一点があることに気付きます。それは「RDBMSありき。SQLありき」という原則があり、そ
マスタの履歴管理パターン（その１） - Xupper技術サポート部のページ
久しぶりにデータモデルの話題です。 ここでは、マスタの履歴管理について、いくつかのパターンを挙げて説明したいと思います。 ■履歴保存用のエンティティを追加し管理（パターン１） 商品エンティティのキーに適用開始年月日を保持し、変更があったタイミングでレコードを追加することにより商品の変更履歴を管理します。 【図１】 ①ある１レコードについて、ある時点の全ての属性の値を、履歴として管理することになります。 ②参照するトランザクション（受注明細）に履歴（商品履歴）の識別子を持たないため、履歴情報が存在する状態で、過去のマスタ情報を参照するためには、受注.受注日と商品履歴.変更日付で検索する等が必要となります。 ■履歴保存用のエンティティを追加し管理（パターン２） パターン１のバリエーションですが、履歴管理用のエンティティのキーを「履歴管理用SEQ」とします。 【図２】 この場合は、参照するトラン
モデリングの本質（石川初さんがオモシロすぎる件） (arclamp.jp アークランプ)
今年のデブサミ2008で、ジョエルを抑えて満足度1位を獲得したランドスケープデザイナーの石川初さん。最近のエントリが面白すぎる。 バックヤードとしての港湾 最近、Googleマップの空撮が普及して、上空からの高解像度の写真を眺める機会が増えるにつれて、建物の屋上が街のバックヤードと化していることがよくわかる。特に都心部にはほとんど「屋根の景」がない。空調の屋外機が延々と並んでいる光景は、自動販売機を後ろ側から眺めているみたいなおもむきだ。 これが、都市のスケールでは、「海岸」がでかいバックヤードになっている。高度に近代化した都市の港湾の「海側からの眺め」というのはほんとに、都市の「裏側」である。きっと、沿岸の「栄養源」から「物資の流通媒体」へと、海岸がその価値を転換させたときから、海側は巨大な荷捌き場になっちゃったのだ。 街へ出よ、驚愕せよ。 （建築学科の学生に地図を見せて『なにか変なこと
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
BPMNについて
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
BPMNを活用したビジネスプロセス・モデリング（1）：ビジネスを可視化するモデル記述言語「BPMN」 - ＠IT 情報マネジメント
ビジネスプロセスをモデル化するのに、UMLは難しすぎると考える人がいる。そもそも、顧客にUMLで記述したビジネスプロセス（のモデル）をみせてもなかなかわかってはもらえない。UMLはもう少し実装寄りのモデルを記述するのに使えばいい。ビジネス寄りのモデルを記述するために、もっと簡単で、しかも表現豊かな言語はないものか。簡単にいえば、そんなニーズのもとにBPMNは誕生したのである。（＠IT編集部） 連載を開始するにあたって 経営戦略とITが密接に結び付き、ビジネス環境の変化に合わせてビジネスプロセス（業務手順）を変更すれば、直ちにシステムが動き出す――。そんな夢のようなパラダイム・シフトが近づいています。その中心にあるのが最近注目されている2つのキーワード、BPM（ビジネスプロセス管理）とSOA（サービス指向アーキテクチャ）です。いま、その大きな流れの中に、BPMNというモデル記述言語が合流しよ
木村さんが指南するDFDの上手な書き方
要求定義でDFDを利用する人は多いだろう。しかし，見よう見まねで書かれたDFDに出会うことも多く，業務の真の姿をとらえて構造化できていないケースも少なくない。 使えるDFDを書くにはどうしたらよいか。DFDの特徴に着目すると，上手な書き方が見えてくる。 「誰が」を記載しないこと DFDは，UMLのユースケース図と同様，対象となる業務の範囲を把握するのを主な目的として使われる図である。要求定義の初期段階で，システム化して解決したい問題領域を可視化することができる。要求定義でDFDをうまく書くには，DFDでは何が記述でき，何は記述されないのかをよく知っておくことが大切である。 ユースケース図と比較すると，DFDの特徴が浮かび上がってくる。（図1）の×印（図に記述しない対象）に注目してみよう。共通で×印が付いているのは「処理の順序やタイミング」だ。DFDとユースケース図は，これらが分からなくても
第4回 良いモデルの作り方
第3回では正しい概念データモデリングの方法について解説しました。第4回では，第3回で登場したD社の事例をもとに，概念データモデリングの作業内容を具体的に解説したいと思います。これまでより長い説明になりますが，ぜひ最後までついてきてください。 まず業務を理解する 概念データモデルの作成の最初のステップは，業務を理解することです。しかし，業務の理解を目的とするとき，概念データモデルでは表現する内容が細かすぎます。分析対象である帳票やエンティティを，業務理解の最初の段階で特定することは困難です。 そこで，まずはプロジェクト（構築するシステム）が対象とする業務について，「業務説明書」を作成します。 営業部 ●3月に2年分の販売計画を立案する。 生産管理課 ●月に2回，3カ月先までの月間生産計画を作成する。 ●月間生産計画の翌月，2カ月先，3カ月先分は，それぞれ顧客からの確定注文，顧客からの発注予定
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.ss.com.au/articles/Agile%20Modeling.pdf
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist
Amazon.co.jp: 実践的データモデリング入門: 真野正: 本
OOJIBOO Blog: [実践的データモデリング入門] 真野正 アーカイブ
DetonationFlash: ドメインモデリング・パターンに対する覚書き
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist