れぶろぐ - [ISO] 性別コードの規格 (ISO 5218, JIS X 0303)
■ 性別コードの規格 (ISO 5218, JIS X 0303) 性別のデータを保存しておく時に、0 と 1 で表せばいいかと考えていたが、 「不明」を示す値もあった方が良いことに気が付いたので調べてみた。 こういうのも規格があるんだね。 ISO 5218 - Wikipedia, the free encyclopedia 0 = Not known 1 = Male 2 = Female 9 = Not applicable JIS X 0303 1 = 男 2 = 女 ただし、JIS X 0303 は廃止された らしく、 また ISO 5218 に同じ内容が含まれているので、ISO 5218 に合わせておけばいいか。
第13回 ［データモデル編］発注者が確認しやすいようにCRUD図をアレンジする
CRUD図を利用して発注者とレビューをされたご経験はありますか？ CRUD図というと一般的には以下のような図をイメージされるのではないでしょうか。 このCRUD図を使って，機能とデータの抜け・漏れや処理の集中，不完全な分割などがないかどうかを検証する「CRUD分析」で発注者に確認したいことが発生したときに，CRUD図をそのまま見せても，発注者はなかなか理解しずらいものです。 確認したい内容に絞り込んだ表を作成する そこでCRUD図をそのまま発注者に見せるのではなく，以下のようにアレンジしたCRUD図を作成してみましょう。 この図のポイントは以下の通りです。 ・申請書作成や承認といった処理のタイミングごとに，各エンティティの作成，参照，更新，削除があるかどうかを表した表形式にする。 ・確認したいエンティティとタイミングのみ記載する。 ・エンティティの数が多い場合は分類する。 ・作成，参照，更
ERの基礎知識とツールの活用法
前回からデータモデリング全体の利用法が理解できたかと思います。今回はデータモデリングの中身の話に入り、ERの基礎知識とツールの活用方法について解説します。データ中心設計（DOA）の基礎となるERについて、ぜひマスターしてください。 ERの醍醐味はリレーションです。リレーションの線がなければERはただの箱（エンティティ）の羅列で、無味乾燥したものになります。エンティティとエンティティの関係が一目であらわされることがER図の意義なのです。 ERのリレーションには依存型と非依存型があります。親エンティティがなければ子エンティティが存在できないものが依存型リレーション、親がなくとも子が独立して存在できるものが非依存型リレーションです。 図1はSQL ServerのサンプルデータベースNorthwindをリバースしたER図の一部です。 「受注」と「受注明細」の関係は、依存／非依存のどちらでしょうか。
第2回 IDEF1XによるER図の記述 | gihyo.jp
前回は、論理設計のデータモデリングにはERモデルを使用すると説明しましたが、ERモデルはER図を使用して表現することができます。ER図の記述方法にはいろいろなものがありますが、今回は、一般的に普及しているIDEF1XによってER図を記述する方法について説明します。 IDEF1Xとは IDEF1Xは、IDEF（Integration Definition）と呼ばれる、システムをさまざまな側面から分析してモデリングを行うための方法の1つで、おもにデータベースの概念設計においてER図を記述する方法としてよく使用されます。 また、IDEF1Xは、米国のNIST（国立標準技術研究所）によってFIPS（連邦情報処理標準）として標準化されており、IE（Information Engineering）と並んでER図の記述方法として一般的なものです。 IDEF1Xでは、ERモデルにおける実体を四角形として記
第4回：仮説立案から対策まで5段階でデータ分析
ビジネスデータ分析を効果的に行うには、「仮説立案」や「検証」といった分析手法の理解が不可欠である。今回は、分析手法の基本を解説する。業務部門がデータ分析を手掛ける際に、情報システム部門が実施すべき支援策も紹介する。 営業部門や販売部門の担当者一人ひとりがビジネスデータ分析を実行するには、基本となる“コツ”を共有する必要がある。今回は、「データ分析の三原則」「データ分析と統計学の違い」「動向分析・要因分析・検証分析」といった分析手法の基本を説明しよう。 データ分析の三原則を理解する データ分析は、3つの基本原則から成る。(1)データを比較する、（2）時系列に並べる、（3）詳細データで要因をつかむ、である。 データは比較して初めて、個々の数字の良しあしが分かる。例えば、「予算と実績」「自社の売り上げと他社（もしくは業界）の売り上げ」の比較などだ。データを比較しなければ、個々の数字が持つ意味を評
第5回 良いモデルを作成するコツ
第4回まで，正しく概念データモデリングをするためにはどのようにすればよいのか，その方法を解説してきました。しかし，正しい手順で概念データモデルを行えば，必ず正しい概念データモデルができるとは限りません。概念データモデリングをするのは人間である以上，人間の判断や想像力が大きく品質に影響します。最終回となる今回は，より良いモデルを作成するために有効なノウハウをご紹介したいと思います。 ケース5 E社は，プリンタや複合機と消耗品の販売や保守を扱う事務機器販売会社です。顧客の増加に伴い取扱量が急速に拡大しているため，販売や保守業務などを管理する情報システムの導入を進めています。業務システム開発の要件定義における概念データモデリングの必要性を重要と考えています。そこで，社内各部門から専任のメンバーを選出し，情報システム部との合同で概念データモデリングを進めています。 営業部からの選任メンバーが作成し
木村さんが指南するDFDの上手な書き方
要求定義でDFDを利用する人は多いだろう。しかし，見よう見まねで書かれたDFDに出会うことも多く，業務の真の姿をとらえて構造化できていないケースも少なくない。 使えるDFDを書くにはどうしたらよいか。DFDの特徴に着目すると，上手な書き方が見えてくる。 「誰が」を記載しないこと DFDは，UMLのユースケース図と同様，対象となる業務の範囲を把握するのを主な目的として使われる図である。要求定義の初期段階で，システム化して解決したい問題領域を可視化することができる。要求定義でDFDをうまく書くには，DFDでは何が記述でき，何は記述されないのかをよく知っておくことが大切である。 ユースケース図と比較すると，DFDの特徴が浮かび上がってくる。（図1）の×印（図に記述しない対象）に注目してみよう。共通で×印が付いているのは「処理の順序やタイミング」だ。DFDとユースケース図は，これらが分からなくても
第3回 その手順ではモデリングできません
第1回，第2回で，概念データモデリングを行なう本当の目的は業務ルールの整理と分析にあることについて解説しました。ところが，概念データモデリングの重要性を理解して実際にモデリングを開始しても，実際には思うようにモデリングできない場合があります。そこで今回は，正しい概念データモデリングの方法を解説します。 ケース4 D社は，四輪エンジンのシャフト部品などを製造する金属部品メーカーです。今年度から取り扱い製品の大幅な増加が予想され，製造工程を統合的に管理する生産管理システムの導入を決定しました。システム化の対象範囲は，年間予算を作成する「営業部」，生産計画，製造指図，設計/材料情報を管理する「生産管理課」，工程進捗を見る「製造部」，品質情報を管理する「品質管理課」の4部門です。 情報システム部では，まずは業務を分析し新システムの概念データモデルを作成することになりました。ところが，初めて本格的に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
