【より良い】データモデリング【モデルを】
- : 名無しさん@お腹いっぱい。 [] 03/07/07 01:41:mnMZZn0T
- データベース構築の上流工程であるモデリングについて語らうスレッドです。
モデル作成に関する質問、質問に対する回答、
作ったモデルの自慢、自慢されたモデルの批評など、
モデリングに関すること全般を扱います。
ソフトの使い方に関する話題、物理的なモデルの話題はご遠慮ください。
EX.
このソフトで○○の機能は〜 → ソフトウェア板へ
○○の組み立てが完成して、これから塗装〜 → 模型・プラモ板へ
モデリングツール
○SVG Cats
製品情報 ttp://http://www.sage-p.com/svgcats.files/svgcats.htm
DL ttp://http://www.vector.co.jp/soft/dl/win95/art/se251284.html
SVG(ベクター画像をテキストで記述するデータフォーマット。要はXMLの一種)でモデル図を描画するツール
●ER/Studio
製品情報 ttp://http://www.jsys-products.com/product/erstudio/
トライアル版DL ttp://http://www.jsys-products.com/download/trial/erstudio/
●AllFusion ERwin Data Modeler
製品情報 ttp://http://www.caj.co.jp/allfusion/erwin/data_modeler.htm
トライアル版DL ttp://http://www.caj.co.jp/registration/allfusion/erwin_pm.htm
●Rational Rose
製品情報 ttp://http://www.rational.co.jp/products/rose/
評価版請求 ttp://http://ops.rational.co.jp/CatalogHassou/f_req.html
●Microsoft Visio Professional
製品情報 ttp://http://www.microsoft.com/japan/Office/visio/evaluation/
評価版配布請求 ttp://http://www.microsoft.com/japan/office/visio/evaluation/trial/
SVGビューア
○SVG Viewerプラグイン
ttp://http://www.adobe.co.jp/svg/ ダウンロードページ
SVG画像を閲覧するためのプラグイン
- : NAME IS NULL [sage] 2006/07/06(木) 18:28:47ID:???
-
親=PK:|AAA|
子=PK:|AAA|1-n|BB|
孫=PK:|AAA|1-n|BB|1-n|CC|
かな?
んで。気になるのは。各コードは固定長でなく可変長なんですか?? - : NAME IS NULL [sage] 2006/07/06(木) 22:26:39ID:???
-
あ、固定長です。
>親=PK:|AAA|
>子=PK:|AAA|1-n|BB|
>孫=PK:|AAA|1-n|BB|1-n|CC|
これは、まさしくこんな関係です。 - : NAME IS NULL [] 2006/07/10(月) 23:41:46:2umW5dHJ
- あるリソースエンティティ同士の関係を表すのに
交差エンティティを作成するという例はよく見かけるのですが、
イベントエンティティ同士の関係についても交差エンティティを作成するという
事はあるのでしょうか?
たとえばある複数の勘定科目から出金して、出金した額を別の種類の複数の
科目へ入金するといった作業があるとして、出金エンティティと入金エンティティ
との関係はどう表したらよいのでしょうか。 - : NAME IS NULL [] 2006/07/10(月) 23:45:40:EbhJ+Fw+
- yhSEfIF00
- : NAME IS NULL [sage] 2006/07/11(火) 02:01:08ID:???
-
交差エンティティって呼ぶのかどうかは知らないけど、
そんなようなものは必要に応じて当然作るよ。
○親テーブル
PK1 PK2
入金No.010 出金No.101
入金No.011 出金No.102
○子テーブル-入金
PK1 PK2
入金No.010 勘定科目A 1,000
入金No.010 勘定科目B 2,000
入金No.011 勘定科目C 200
○子テーブル-出金
PK1 PK2
出金No.101 勘定科目Y 2,500
出金No.101 勘定科目Z 500
出金No.102 勘定科目A 200
- : NAME IS NULL [sage] 2006/07/11(火) 14:42:29ID:???
- DB作る前に簿記の勉強したほうがいいね。
帳票をそのままDBにすればおk。 - : NAME IS NULL [sage] 2006/07/15(土) 15:39:26ID:???
- 簿記検定受験後の今その言葉の重みが良くわかる
- : NAME IS NULL [] 2006/08/27(日) 18:38:29:7FPwEeLv
- つまらない質問で申し訳ないのですが、
顧客IDなどのコードの作成方法は
決まっているのでしょうか。
社員番号なら入社年月日+連番
などでいいと思うのですが、
何か指針はあるのでしょうか。 - : NAME IS NULL [sage] 2006/08/28(月) 01:10:22ID:???
- 連番も何桁取るとか有るよ。2桁じゃ100人入ったら終わり。
総務や人事と打ち合わせて決めたほうがいいよ。
全社的に統一しないと意味がない。
顧客コードなら営業とかと打ち合わせて決めるべき。
営業上、顧客の元に自社の顧客番号が付いたものが送られるし、「ああ、うちって100社目なんだな」って推測されちゃうような顧客IDは恥ずかしい。 - : NAME IS NULL [sage] 2006/09/01(金) 01:41:11ID:???
- 設計するのに使ってるツールとか教えて!
XEADとかJude、ObjectBrowserERあたりがよさげなんですが!!
今試そうと思ってるのがOracle JDeveloper10g!!! - : NAME IS NULL [sage] 2006/09/01(金) 17:52:21ID:???
- DBDesigner4最強。
XEADだけは勘弁 - : NAME IS NULL [sage] 2006/09/02(土) 23:04:56ID:???
- さんへ
XEADは、どこら辺が駄目だと思いますか? - : NAME IS NULL [sage] 2006/09/16(土) 01:13:27ID:???
- ナチュラルキーとサロゲートキーって使い分けどうしてますか?
顧客マスタとか商品マスタみたいなのはナチュラルキー、
受注TRとか売上TRはサロゲートキー、
仕様変更が多そうならサロゲートキー多め、
ERモデリングツール使うならナチュラルキー、
ORマッピング使うならサロゲートキー、
こなかじ? - : NAME IS NULL [sage] 2006/09/16(土) 01:23:02ID:???
- 知るか。何でもいいよ。
あれもアホな議論だったな - : NAME IS NULL [sage] 2006/09/17(日) 01:56:26ID:???
- 佐藤 正美氏が提唱する「T字形ER」ってどうなんでしょ。会社の上司が
信者(?)で何が何でも導入したいみたいで。。。本を読んでみたけど
文章表現は下手(だと思った)だし理論にしても判り辛いような。。。
数千人規模の会社の基幹業務構築のモデリングには大丈夫なのかな〜?
と思ってます(例えば数年後には理論自体廃れてるとか・・・)。 - : NAME IS NULL [sage] 2006/09/17(日) 02:41:45ID:???
-
いいところはresource概念とevent概念云々のところぐらいか
あとはちょっと・・・。identifierの扱いがアレなんで、あの理論をそのまま適用するのは
実際的ではないと思う - : NAME IS NULL [sage] 2006/09/17(日) 04:11:40ID:???
- データモデリングなんて勘でやるのが一番いい。
主キーと関連だけしっかり抑えとけば大概上手くいく。
大事なのは、間違ったモデリングなんてないと知っておくこと - : NAME IS NULL [sage] 2006/09/17(日) 16:38:22ID:???
- 勘でやる時点でだめだめな悪寒。
いろんなモデリングのシミュレーションソフトとかあれば設計時に検証しやすくて便利なのにな。 - : NAME IS NULL [sage] 2006/09/18(月) 11:28:44ID:???
-
基幹ではないが、大手での採用例はあり。
和光市の某自動車メーカとか、麹町の某信販会社とか。
ただ、T字型を使ったプロジェクトで試行錯誤した経験者がいない状態で
本読んだだけでいきなり実地の大規模システムに適用しようとすると
多大な困難が待ち受けていそうな悪寒が… - : TM使ってるよ [] 2006/09/20(水) 14:17:52:6C6LnzZC
- TM(T字形ER手法)は、CoddのRDBMに始まって、正規化だけでは解決しない問題を検討している間に、
業務系のシステムでは「コード体系」を使って分析するのが便利って便法を思いついたりしながら発展して
きましたが、根っこの部分ではオブジェクト指向におけるドメインモデリングと繋がっています。
なので、#453 の方が言われる様に、本を読んだだけで見よう見真似で始めるのは、少し辛いでしょう。
できれば、本人から習うことが可能なので、それが一番だと思います。
ttp://http://www.sdi-net.co.jp/ に行ってみましょう。 - : NAME IS NULL [sage] 2006/09/23(土) 17:10:07ID:???
- ↑
HP見てみたけど、本当大丈夫なの?かなり素人っぽいHPで
すが。コンサルとかやってるんんだったらもうちょっとマシな
HPにした方がいいような。。。
それに実績も書いてないし。 の和光や麹町の会社ではどれだけ
TMにより実績がでたのかな?
コンサルやるなら会社(?)の規模も知りたいなー - : NAME IS NULL [sage] 2006/09/24(日) 12:10:14ID:???
- 麹町では使ってはいるが「お絵かきソフト」程度の使われ方。
「Visioの方が書きやすいじゃん」ってノリだから「TMを
導入してビジネスの強み・弱み・・・」なんて程遠い状態。 - : NAME IS NULL [sage] 2006/09/24(日) 20:16:59ID:???
-
WebPages見てそういう感想抱いたのなら、TMとは出会わなかったことにした方が多分幸せになれる。
いや、煽りや皮肉ではなく、本音ベースの話。
感覚的な「合う」「合わない」っていうのは結構重要な要素かと。 - : NAME IS NULL [sage] 2006/09/25(月) 00:31:01ID:???
- HP見たけど「1,000,000 ステッフ゜ 規模の システム であれば、10数名で、6 ヶ月以内に導入する。」
ってのは凄いなー。
事例とかあるといいけどね。 - : NAME IS NULL [sage] 2006/09/25(月) 01:10:08ID:???
- 優秀なエンジニアが集まればとか、そのための費用を出せるならとか前提条件いっぱいだろ?
まあ優秀なエンジニア集めれば、別に何でも短納期でできそうな悪寒。
そういう論点のすり替えをして一儲けするのがコンサルと言えばそうだけど。 - : NAME IS NULL [sage] 2006/09/25(月) 10:26:51ID:???
-
ステップってコード量だよねぇ?
でコンサルが開発するわけじゃないだろうし、有効なメトリクスなのかね?
コンサルとしてはそういうところ大事だと思うんだが。 - : NAME IS NULL [sage] 2006/09/26(火) 00:04:22ID:???
- 画面数とかテーブル数とかユースケース数とかでないとピンと来ない
- : yossy [] 2006/09/26(火) 00:38:05:3/C3qjqe
- 皆様始めまして。
DBDesigner4の使い勝手が良かったので日本語化してみました(需要アルカナ・・・)
ttp://http://dbdesigner.iimp.jp/
使ってみてご意見いただければと存じ上げます。
Delphiはあまり使ったことがないので安定度が下がっているかもしれません。。
あと、、まだWindows版しかコンパイルしていないです・・・。
Linuxはあまり慣れていないもので。。すみません。。。 - : NAME IS NULL [sage] 2006/10/02(月) 23:45:41ID:???
- >447
主キーベースのERDを作成する段階では、ナチュラルキーでモデリングし始め、
全属性ERDを作成する段階で、最終的にサロゲートキーに再設計してる。
(最初はナチュラルキーの方がわかりやすいので・・・)
全部サロゲートキーにしてる理由は、
(1)安定性の確保
:将来のシステム改善などでの主キー属性の設計変更を、極力抑える。
(候補キー自体が安定していることが前提なのに、変わることあるから・・・)
(2)データへのアクセスコストを抑えたい
:ナチュラルキーだと3つ以上のコンポジットとなってしまう場合がある(特に連関エンティティ)
(3)ポリシーの統一
:全エンティティを同じポリシーで設計するため全部サロゲートキー
なんて言い訳でサロゲートキーにしてる。 - : NAME IS NULL [sage] 2006/10/02(月) 23:56:56ID:???
-
>候補キー自体が安定していることが前提なのに、変わることあるから・・・
間違えた。
候補キー -> 主キー - : NAME IS NULL [age] 2007/05/12(土) 18:00:45ID:???
- 保守age
- : NAME IS NULL [] 2007/05/15(火) 19:54:55:/Spdz0dJ
- FFの武器を管理したいと思っています。
次回のバージョンアップで他のシリーズも同一のテーブルで管理できるようにしたいです。
現在
武器 (武器ID, 攻撃力, 入手場所)
案1
武器テーブルにシリーズNoを追加して、シリーズNo+武器IDを主キーにする。
シリーズNo | 武器ID
FF1 | 001
FF1 | 002
FF2 | 001
FF3 | 001
...
案2
武器テーブルにシリーズNoを追加して、武器IDは主キーのまま通し番号とする
武器ID | シリーズNo
001 | FF1
002 | FF1
003 | FF2
004 | FF3
案1だと枝番の作成がめんどうなのですが、きれいにナンバリングされる。
案2だとキーの作成は簡単だが、データの入力順を間違えると気持ち悪いナンバリングになってしまう。
どのような場合にどちらがいいか教えてください。 - : NAME IS NULL [sage] 2007/05/15(火) 23:21:27ID:???
- >466
複合キー列への外部キー設定は列が増えてしまって、
子表が増えるほど面倒になるから案2がいいなぁ。どうせ
武器IDなんてもとより意味のあるものじゃないんだし。
もういっそ武器IDは乱数を採番するようにしちゃえば気にならないよ。 - : NAME IS NULL [sage] 2007/05/16(水) 03:44:39ID:???
- 1の方がデータ移行は楽そうだな。
最近の流行は2か。アプリケーションフレームワーク的に2のようになってないとあかんものがあるな。
武器リストだと表示順ってのも気にしたいだろうから、
1のテーブルにさらにid列を一つ追加して、
武器IDは表示順的な意味を持たせるのもありかも - : NAME IS NULL [sage] 2007/07/08(日) 18:42:56ID:???
- MySQLのDBDesignerに相当するpostgresqlのツールってありますか?
それとも、postgresqlをodbcで接続して、DBDesignerを使っても、幸せになれますか? - : NAME IS NULL [] 2007/08/07(火) 20:28:30:bIEMzxGi
- このスレでも何回か見かけるが、簿記の知識がSEにも要求される場合がある。
独学で簿記を勉強しようとすると、書籍を購入して勉強となりがちだが、
項目が羅列してあり説明は最小限のような簿記の書籍ではなかなか理解は進まない(俺だけか)。
簿記の書籍は不親切であり、そのために資格学校が存続できてる気がする。
資格学校に通わなくても資格学校の通信教育等もあるし、それもそんなに高くはない。
さらに講義形式の勉強で一番手軽なのは、資格学校が出版しているDVDビデオの教材がある。
例えば、以下のような教材がある。
合格テキスト講義DVD日商簿記3級 商業簿記 Ver.4.0(10,500円)
DVD6枚組 TAC出版
俺は本屋で買ったが、amazonにもある。講師は違うが2級もある。
これと対になってる書籍(テキスト)も別に売ってるが、なくても特に困らない。
DVDの講義なので、好きなときに何回でも見れる。
これを見てしまうと、いかに市販の書籍で学ぶことが能率が悪いかということがよく分かる。
おそらく簿記の勉強は書籍ではなくて人の話を聞いて学ぶのが一番よいのでは
ないかと思う。「要はこういうこと」みたいな言葉やくどいぐらいの説明は
なかなか書籍には載りにくい。このDVDのテキストも同じ欠点がある。
例えば減価償却累計額について簿記上の具体例を含めて詳しい説明を書籍で
探そうとすると結構大変だと思う。また、講師がしゃべってくれるわけで漢字の
読み方も問題なくなる。この3級の講師は大変よいと思う。きっちりとよく話してくれている。
スレ違いすまん。
- : NAME IS NULL [sage] 2007/08/08(水) 00:35:59ID:???
- まぁ、SEが片手間に勉強するのにむいた教材は確かに少ないかもしれんけど、
たかが3級レベルで分かりやすいも分かりにくいも無いと思うんだが・・・ - : NAME IS NULL [sage] 2007/08/08(水) 21:18:53ID:???
- まったくその通り。10日でわかるとかそういうので十分、
実際は1週間足らず勉強してケアレスミスで落として
90点代後半取れた。 - : NAME IS NULL [] 2007/08/09(木) 22:20:09:MI2mCbx1
- 初心者です。
物理データモデルの「内部スキーマ」とは、具体的にRDBMSで
いうところの、どのようなオブジェクトなのでしょうか?
どなたか御教授ねがいます。 - : NAME IS NULL [sage] 2007/08/10(金) 02:23:03ID:???
- テーブルとかカラムとか
- : NAME IS NULL [sage] 2007/08/10(金) 22:15:11ID:???
-
ANSI/SPARC 3層スキーマのことなら、
概念スキーマ:テーブル
外部スキーマ:VIEW
内部スキーマ:物理ファイル定義(oracleだとセグメントかな) - : 473 [] 2007/08/11(土) 00:56:13:Fq8lPKBO
- さん
ありがとうございます。
ANSI/SPARC 3層スキーマに関してですが、SQL Server 2000
について「内部スキーマ」なるものが、どのようなオブジェクトを
指すのかご存知なら教えていただけますか?
宜しくお願いします。 - : NAME IS NULL [sage] 2007/08/11(土) 09:26:15ID:???
-
内部スキーマについて、oracleだとセグメントって書いたけど、
データベース上の特定のオブジェクトや構造を指している
というよりも、索引からセグメントからデータファイルまでの
物理構造のことを指してる。
SQL Serverは詳しくないのだけど、同じようにセグメント
(oracleでは表領域に相当)からデータベースデバイス?までの
物理構造のことを指しているのではないかな。 - : NAME IS NULL [] 2007/11/19(月) 21:31:13:YgXjo0NC
- 次のケースの一般的なデータモデルをご教授ください。
長文で申し訳ありませんが宜しくお願いします。
<前提条件>
製造業向けの部品加工を想定(在庫関連の処理は無し)
製品・部品・工程・実績の4つのエンティティがあるとして、、、
製品 … 製品というよりは製造指示Noのようなもの
部品 … 製品を構成する部品です。(※一般的なBOMのような親品目,子品目を再帰で保持するような複雑な構造ではない)
工程 … 部品を加工するための加工工程手順です。(手順1:旋盤, 手順2:マシニング...)
実績 … 加工工程に対する実績(労務費、労務時間)
4つのエンティティの関連は次のような階層構造を考えています。
(※この考え方がおかしい場合はご指摘ください)
製品 → 部品 → 工程 → 実績
(1:n) (1:n) (1:n)
部品には材料や購入品といった部品区分があり、データ属性が異なるため、
部品をスーパータイプ、材料・購入品をサブタイプで持たせようと思っています。
製品 → +部品(部品id(PK), 部品区分...) → 工程 → 実績
|
+材料(部品id(PK), 仕入先cd(FK), 寸法...)
+購入品(部品id(PK), 仕入先cd(FK), 購入品品番(FK)...)
*** 質問1***
各エンティティの主キー(PK)をどのように設けるのが一般的なのでしょうか?
上記のようなデータ構造の場合の一般的な主キーの設け方をご教授ください。
今考えているのが@とAの方法です。
@各エンティティに単独の主キー(PK)を設けて、親への参照キー(FK)をそれぞれ持たせる。
製品: 製品id(PK), 製造指示No, 型番...
部品: 部品id(PK), 製品id(FK), 部品区分, 部品cd, 部品数...
材料: 部品id(PK), 製品id(FK), 仕入先cd(FK), 寸法...
購入品: 部品id(PK), 製品id(FK), 仕入先cd(FK), 購入品品番(FK)...
工程: 工程id(PK), 製品id(FK), 部品id(FK), 工程cd, 工程手順No, 標準時間, 数量...
実績: 実績id(PK), 製品id(FK), 部品id(FK), 工程id(FK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...
A各エンティティの主キー(PK)を複合キーで持たせる。
製品: {製品id}(PK), 製造指示No, 型番...
部品: {製品id, 部品id}(PK), 部品区分, 部品cd, 部品数...
材料: {製品id, 部品id}(PK), 仕入先cd(FK), 寸法...
購入品: {製品id, 部品id}(PK), 仕入先cd(FK), 購入品品番(FK)...
工程: {製品id, 部品id, 工程id}(PK), 工程cd, 工程手順No, 標準時間, 数量...
実績: {製品id, 部品id, 工程id, 実績id}(PK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...
そもそも考え方がおかしい場合はご指摘ください。
- : NAME IS NULL [] 2007/11/19(月) 21:32:24:YgXjo0NC
- 続きです。
*** 質問2***
次の原価をリアルタイムで把握したい場合には原価データをどのように保持するのが一般的なのでしょうか?
(※ここでは外注費は無いもとする)
1.製品別原価(製品別の材料費計+購入品費計+労務費計)
2.部品別原価(部品別の材料費計+購入品費計+労務費計)
3.工程別原価(工程別の労務費計)
考えているのは次のとおりです。
@製品エンティティに"材料費計", "購入品費計", "労務費計"のデータ項目を持たせる。
A部品のスーパータイプエンティティに"材料費計", "購入品費計", "労務費計" のデータ項目を持たせる。
B工程エンティティに"労務費計"のデータ項目を持たせる。
各計データの更新はトリガーやストアドにて行う
そもそも考え方がおかしい場合はご指摘ください。
以上、宜しくお願いします。
- : NAME IS NULL [sage] 2007/11/20(火) 02:27:57ID:???
- 質問1
正規化をきちんとするなら、@の材料と購入品には製品idは入らないはず。
俺なら他のテーブルとの一貫性を保つために
材料: 材料id(PK), 部品id(FK), 仕入先cd(FK), 寸法...
購入品: 購入品id(PK), 部品id(FK), 仕入先cd(FK), 購入品品番(FK)...
とする。でも、部品idにユニーク制約をつけなきゃいけないのでそこを手間と感じるかどうか。
@かAかはどっちでもいいけど、最近は@が主流。
処理側のフレームワークと言うかプログラムロジックに便利な方を選択。
質問2
集計用のテーブルを別に作るべき。
完全なリアルタイムにせずに、例えば10分ごとに集計バッチをまわすとか、
Oracleならマテビューを使うとかする - : NAME IS NULL [] 2007/11/20(火) 14:49:55:/GHn6NrO
-
遅くなりまして申し訳ございません。
レスありがとうございました。
質問1について
なるほど、確かにデータ編集時に、複合主キーより単独主キーでアクセスした方が
SQL文も簡単に記述でき、何かと便利が良さそうですね。
教えて頂いた方法で実装しようと思うのですが、
@の方法(各エンティティに単独の主キー(PK)を設けて、親への参照キー(FK)をそれぞれ持たせる)で
きちんとした正規化を行う場合、工程の製品id(FK) と 実績の製品id(FK), 部品id(FK)も要らなくなり、
次のようになるはず?(1階層上の親id のみ 持たせる)
この理解で問題ないでしょうか?
製品: 製品id(PK), 製造指示No, 型番...
部品: 部品id(PK), 製品id(FK), 部品区分, 部品cd, 部品数...
材料: 材料id(PK), 部品id(FK), 仕入先cd(FK), 寸法...
購入品: 購入品id(PK), 部品id(FK), 仕入先cd(FK), 購入品品番(FK)...
工程: 工程id(PK), 部品id(FK), 工程cd, 工程手順No, 標準時間, 数量...
実績: 実績id(PK), 工程id(FK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...
もしくは、材料id, 購入品id は持たず、次のようにする。
製品: 製品id(PK), 製造指示No, 型番...
部品: 部品id(PK), 製品id(FK), 部品区分, 部品cd, 部品数...
材料: 部品id(PK), 仕入先cd(FK), 寸法...
購入品: 部品id(PK), 仕入先cd(FK), 購入品品番(FK)...
工程: 工程id(PK), 部品id(FK), 工程cd, 工程手順No, 標準時間, 数量...
実績: 実績id(PK), 工程id(FK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...
- : NAME IS NULL [] 2007/11/20(火) 14:51:01:/GHn6NrO
- 続きです。
遅くなりまして申し訳ございません。
レスありがとうございました。
質問2について
やはり集計用の別テーブルを設けた方がいいのですね。
今回のケースで集計テーブルを用いるとすれば、次のような感じでよろしいですか?
集計元テーブルと集計先テーブルは(1:1の関係)になる。
また本来は集計テーブルに主キーの項目として集計日を含むと思うのですが、
今回は集計日が要らないので外します。
製品: 製品id(PK)... → 製品別原価: 製品id(PK), 材料費計, 購入品費計, 労務費計...
部品: 部品id(PK)... → 部品別原価: 部品id(PK), 材料費計, 購入品費計, 労務費計...
工程: 工程id(PK)... → 工程別原価: 工程id(PK), 労務費計...
もしくは、集計テーブルにも単独主キーを設けて、次のようにする。
製品: 製品id(PK)... → 製品別原価: 製品別原価id(PK), 製品id(FK), 材料費計, 購入品費計, 労務費計...
部品: 部品id(PK)... → 部品別原価: 部品別原価id(PK), 部品id(FK), 材料費計, 購入品費計, 労務費計...
工程: 工程id(PK)... → 工程別原価: 工程別原価id(PK), 工程id(FK), 労務費計...
以上、質問ばかりで申し訳ございませんが
宜しくお願いします。 - : NAME IS NULL [] 2007/11/20(火) 20:40:10:wWhiZNbu
- パソコンショップならここ!!
ttp://http://want-pc.com - : kmyPJqxBGr [ycubhf@lsfqqh.com] 2007/11/20(火) 21:35:11ID:???
- 6ehkeP <a href="ttp://http://dphojlgmqyum.com/">dphojlgmqyum</a>, [url=ttp://http://dciuxyoglilw.com/]dciuxyoglilw[/url], [link=ttp://http://jupungwigput.com/]jupungwigput[/link], ttp://http://tltjzxqojqqo.com/
- : YDdMTWcmpUvtToARj [bvwblh@pkweaw.com] 2007/11/20(火) 21:57:55ID:???
- aVR2l3 <a href="ttp://http://mxmpbpvmprfm.com/">mxmpbpvmprfm</a>, [url=ttp://http://yrgjgiqgeori.com/]yrgjgiqgeori[/url], [link=ttp://http://xppokryehkqp.com/]xppokryehkqp[/link], ttp://http://pnlqzfhrtylu.com/
- : NAME IS NULL [sage] 2007/11/21(水) 00:24:58ID:???
-
OKと思われ。
OKと思われ。まぁ、こっちは単独主キー無くてもいいかも知れんが - : NAME IS NULL [sage] 2007/11/21(水) 10:43:07ID:???
-
レスありがとうございました。
これでスッキリしましたので先に進めそうです!!
- : kkEaqflyQ [buyzovirax@buyzovirax.com] 2007/11/23(金) 04:52:59ID:???
- ttp://http://ublog.union.edu/elpinner/88 buy zovirax
- : kAXUAXtktXfWiAc [toucheme@toucheme.com] 2007/11/23(金) 10:57:18ID:???
- ttp://http://iqlveq.cn cheap mp3 downloads
- : XRXQZTpLvYJra [dialog@golaid.info] 2007/11/23(金) 12:14:42ID:???
- ttp://http://itdvmb.cn mp3 player downloads
- : qgNOgKJitye [ImADisco@ImADisco.org] 2007/11/23(金) 21:16:42ID:???
- ttp://http://kgnsye.cn/imax-california.html Imax california
ttp://http://kgnsye.cn/california-dept-of-corporation-htm.html California dept of corporation htm
ttp://http://kgnsye.cn/single-family-homes-carlsbad-california.html Single family homes carlsbad california
ttp://http://kgnsye.cn/archangel-tattoo-design.html Archangel tattoo design
ttp://http://kgnsye.cn/blue-book-pricings-for-atv.html Blue book pricings for atv - : vnlCkSByPPMG [nightmp3@bdzwbn.cn] 2007/11/25(日) 00:46:56ID:???
- ttp://http://bfsnbw.cn/mp34 free memory
- : NAME IS NULL [sage] 2008/02/10(日) 12:22:27ID:???
- MySQL4.1、5.0でも DBDesignerは使えますか?
に同じ現象が書かれているのですが・・・
バージョンアップされてないからなぁ^^;
- : NAME IS NULL [] 2008/05/23(金) 04:29:26:P38jVWZR
- A C
- : VQiYlHzPZa [ehohon@shhnjv.com] 2008/06/01(日) 13:42:47ID:???
- n1ywUN <a href="ttp://http://vdgsdgcxvewl.com/">vdgsdgcxvewl</a>, [url=ttp://http://ltldczvyogvo.com/]ltldczvyogvo[/url], [link=ttp://http://dznjgohehaza.com/]dznjgohehaza[/link], ttp://http://whxrulsmcetw.com/
- : NAME IS NULL [sage] 2008/07/07(月) 17:23:41ID:???
- 住所録のデータベースのモデルです。
取引先の会社とその担当者、お客様とその家族、
と、全部で4つのテーブルを作成しました。
それぞれのテーブルには、名前や電話や住所などの
列を並べました。
そこで疑問になったのが。
取引先の住所と担当者の住所は、共通する事もある(し違う事もある)。
家族の住所と個人の住所は、共通する事もある(し違う事もある)。
と、考えると。
住所部分のみでテーブルを作成して、4つのテーブルから
参照した方がいいのかな?とも思ったのですが、いかがでしょう?
- : NAME IS NULL [sage] 2008/07/07(月) 22:08:49ID:???
- そうね。それなら取引先が複数住所もってるケースにも対応できるね
- : NAME IS NULL [sage] 2008/07/07(月) 22:38:19ID:???
- 取引先が複数住所を持ってるケースは考えていませんでしたが。
確かにおっしゃる通りで、良さそうですね。
また、営業所が移転した場合や家族が引っ越しした時に、
同じ住所テーブルを示していれば、個人の住所も一括で
修正されますね。ありがとうございました。 - : NAME IS NULL [sage] 2008/09/06(土) 12:04:21ID:???
- 1レコードに開始/終了時刻を持って「状態」を記録するメリットって何?
開始/終了イベントテーブルにそれぞれ発生時刻を記録するほうがいいと思うんだけど - : NAME IS NULL [sage] 2008/09/08(月) 00:51:51ID:???
-
イベントテーブルにそれぞれ記録するほうがいいのは
たとえばどんな時でしょうか?
- : NAME IS NULL [sage] 2008/09/08(月) 23:23:38ID:???
-
抽出したエンティティの意味的な違いに優劣はないから実用上のメリットで言うと、
所要時間を求めるようなクエリでjoinを節約できるとか。
逆に挿入/更新でコストはかかっているわけで、メリット/デメリットともに
事前集計表と似たようなもの。 - : NAME IS NULL [] 2008/12/23(火) 20:52:33:GasTPqXo
- 保守
- : NAME IS NULL [sage] 2008/12/28(日) 05:07:16ID:???
- 状態が欲しい場合も無く無いと思うけどなあ。
導入事例ってあんまり当てにならないのか。まあそもそも営業資料だしね。
導入されても、実際十分に活用されてるかどうかや、現在も使われてるかどうかはわからないしなあ。 - : NAME IS NULL [] 2009/01/17(土) 01:16:45:jMspYNZv
- 町場の工務店用データベース作成のためこんな感じのER図を作成してみたのですが
もし問題があれば指摘していただけるとありがたいです。
ttp://niyaniya.info/pic/img/2186.jpg
業務の基本的な流れは 見積作成⇒請負契約⇒ 工事 です。オリジナルはもうすこしマスタテーブルが
増えて複雑なのですが、基本はこんな感じです。 よろしくお願いします。 - : NAME IS NULL [sage] 2009/01/17(土) 23:29:03ID:???
-
普段、IDEF1Xでしか読み書きしてないから、リレーションシップの
意味が正しく理解できてるかわかんないのと、業務要件が不明だから、
自分の所見でコメント。
(1)「見積明細」の主キーは”見積ID”では?。
「見積明細」は「見積」のサブタイプということだと思うけど、
意味があって分けてるのかな?
(2)「請負契約明細」についても(1)と同様。
(3)「請負金額入金」「請負金額請求」は、「入金」「請求」として
独立エンティティにするか悩むところ。
入金単位や請求単位が請負契約単位なのかな?
(1契約で入金は複数回とかないのかな)
(4)何故「仕入契約」「下請契約」は"業者ID"が主キーに
なってるのに、「請求契約」の方には”顧客ID”が主キーに
なってないの? この違いの意味は?
両方とも<契約>という同じような意味のエンティティと
考えれば、その属性も同じような主キー構成で
いいと思うけど。
※属性なしで、エンティティ名だけでリレーションシップを
考えた方がわかりやすいですよ。 - : NAME IS NULL [] 2009/01/18(日) 03:01:18:rdZV1j35
-
レスありがとうです!
ありがたい指摘なのですが理解する語彙が足りずアドバイスを生かしきれないのが
残念ですが・・・
(1)で言われた「見積明細」テーブルは、本来「見積」テーブルと一体の繰り返し要素を別テーブルに分離した
もので主キーは設定していません。 1つの見積に対して複数の見積項目があるので2つのテーブルに分離しました。
販売業者における販売テーブルと販売明細テーブルのような関係です。
(2)の「請負契約」と「請負契約明細」も同様の関係です。
(3)の「請負金額入金」「請負金額請求」は確かに一つのテーブルに統合できそうです。
盲点でした・・ありがとうございます。
問題は(4)でして、、、『なぜ「請負契約」の方には顧客IDが主キーになっていないのか』
との指摘ですが、 請負契約の場合、1つの契約に相手となる顧客は1つだけなのですが、下請契約や仕入契約は
1つの工事に相手となる業者は複数に及ぶことがあります。 その質の違いから差が生じたと思います。
これがはじめてのデータモデリングで試行錯誤の結果ですのでもしかしたら基本的なところで誤理解をしてる可能性
ありですので・・・その程度のもんだとオモっていただけるとありがたいです。
- : NAME IS NULL [sage] 2009/01/18(日) 04:03:52ID:???
- 明細テーブルにも主キーはつけるべきだよ。
この場合は表示順を主キーにすりゃいいんじゃないかな。
> (3)の「請負金額入金」「請負金額請求」は確かに一つのテーブルに統合できそうです。
統合すると請求1回に対して入金複数回のケースとか対応できなくなるよ。
あなたんとこの業務的には問題ないのかも知れんけど、
柔軟性保つために分けておいたほうがベター
主キー入ってないテーブルがあること以外は、大体OKそうに見えるね。
は見当はずれだから気にしないほうがいい - : NAME IS NULL [sage] 2009/01/18(日) 04:09:07ID:???
- > この場合は表示順を主キーにすりゃいいんじゃないかな。
ごめん、親テーブルの主キー+表示順というつもりだった。
たとえば見積明細では(見積ID、表示順)を主キーにする - : NAME IS NULL [sage] 2009/01/18(日) 04:25:30ID:???
-
505です。今日は何故か眠れないのでレス
ちょっと説明がまずかったみたいなので、まず用語から。
※文中の用語はググってね。
エンティティ=テーブル
属性=列項目
主キー=(簡単に言うと)一意に行を特定できる列項目
(1)の、「1つの見積に対して複数の見積項目がある」という
のは、「見積」1行に対して「見積明細」複数行という意味であれば、
「見積明細」テーブルの主キーは、”見積ID”と、明細を識別する”明細ID"
みたいなのが必要。(用語的には第2正規形)
(2)も同様。
(3)はそういう意味ではなくて、「契約」「請求」「入金」と、
それぞれ独立した(主キーを持つ)テーブルにしても良いのではという意味。
データモデルを考えるときに、業務の実態を、リソース(資源:名詞)と
イベント(出来事:動詞)に分けて、テーブルとして考えるのだけど、
例えば、
リソースは、「社員」「顧客」「業者」で、
イベントは、「見積」「契約」「請求」「入金」「工事」「支払」
なわけだ。
以上 - : NAME IS NULL [sage] 2009/01/18(日) 04:28:57ID:???
-
どこが見当違いか、指摘してもらえるとうれしいね - : NAME IS NULL [sage] 2009/01/18(日) 04:43:29ID:???
-
もしかして、(1)でサブタイプって書いたことを見当違いって
言ってるのかな?
エンティティ名だけ見ると、第2正規形を意識したと思えたけど、
もしかして主キーが同じで、あえて分けたのかと深読みしただけ
なんだけどね。
(3)は509で書いた通り。
(4)は、業務要件わからないから、所見てことで、
主眼を「請負契約」と同様に<<契約>>に置いてもいいかなと思ったのさ。
よろしく。 - : NAME IS NULL [sage] 2009/01/18(日) 12:41:42ID:???
- あのさ、「明細」ってかいてあんのにピンと来ないようじゃお話にならないと思うよ。
- : 506 [sage] 2009/01/18(日) 20:01:21ID:???
-
>明細テーブルにも主キーはつけるべきだよ。
この場合は表示順を主キーにすりゃいいんじゃないかな
なるほど! これは勉強になりました。 キーはテーブルの結合しか用途がないもの
だと思っていたのでそういう使い方が出来るのは初めて知りました。
>主キー入ってないテーブルがあること以外は、大体OKそうに見えるね。
は見当はずれだから気にしないほうがいい
いえいえ皆さんのアドバイスは大変勉強になります。
- : 506 [sage] 2009/01/18(日) 20:11:51ID:???
-
>「見積明細」テーブルの主キーは、”見積ID”と、明細を識別する”明細ID"
みたいなのが必要。(用語的には第2正規形)
たしかにおっしゃるとおりです。 明細テーブルの各行を識別するキーも必要ですね・・・。
ここらへんはまったくノーマークでしたのでありがたい指摘です。 その意味で
見積明細にも見積IDを主キーに設定すべきと仰っていたのですね。 私の間違いでした・・・
>データモデルを考えるときに、業務の実態を、リソース(資源:名詞)と
イベント(出来事:動詞)に分けて、テーブルとして考えるのだけど、
この辺はいまの自分にはちょっと高度です もうちとレベルアップしてからアドバイスを
生かさせていただきます^^;
- : NAME IS NULL [sage] 2009/01/18(日) 23:18:35ID:???
- 高度ってあんた・・・
- : NAME IS NULL [sage] 2009/01/19(月) 01:35:56ID:???
-
まぁ、そう言いなさんな。所見で深読みしたけどさ。
最初の図(モデル)から想像したのは、子エンティティの
外部キーについて、親エンティティからのキー移行だけを間違えて
記述したものと深読みしたということ。
(よって、排他的サブタイプと見たわけ)
業界/業務要件が不明なので、モデルから判断するだけ、つまり、
名称(用語)でエンティティを安易に想像してはダメってことも
あるからね。(話をよく聞かないうちに決めつけちゃダメさ)
ちなみにウチの所でも、第2正規化の結果を「XX」「XX明細」と
してるよ。
スレ汚しスマソ。 - : 506 [sage] 2009/01/19(月) 20:38:23ID:???
- みなさんのご指摘を参考に最終的に↓のように仕上げてみました。これでなんとか
やってみようと思います。 どうもありがとうございましたです!
ttp://niyaniya.info/pic/img/2219.jpg - : NAME IS NULL [sage] 2009/02/01(日) 03:55:40ID:???
- 業務知識が無いと、まともな設計が出来ない見本だな。
運用で不具合出まくるだろうなあwww - : NAME IS NULL [] 2009/06/04(木) 09:25:50:w6Hljn46
- 五階層まで登録できる工事の見積システムのデータモデリングをしてるのですが
↓こんなかんじでどうでしょう^^;
ttp://http://imepita.jp/20090604/333030
項目A→項目B→項目C→項目D→項目E と具体的になっていく感じです
例) 電気→3LDK標準電気工事→玄関→外部玄関等→照明器具 DWP-3524DS
項目Aによって必要な階層がことなるので動的に階層を変更できればいいのですが、、 - : NAME IS NULL [sage] 2009/06/07(日) 19:19:03ID:???
- >519
階層構造を柔軟にとか考えると、
所要量展開、再帰、LLC、
部品展開、原価計算、
といったところをある程度考慮して取り入れながら
設計するのかなと思う。
これらでぐぐってみてもよいかと。
- : NAME IS NULL [] 2009/06/09(火) 23:40:48:jbiexGaF
-
その前に親子関係は1対多なんだよね?
何もテーブルを幾つも作らなくても、
子情報が主キーでそこに親情報が従属するような
再帰的な1テーブルで済まないの?
これだと、多重構造が可変でも耐えられるでしょ?
- : NAME IS NULL [sage] 2011/02/08(火) 23:20:58ID:???
- 目指してる 未来が違う byシャープ
ttp://http://twitter.com/saramura6/statuses/6688087715352576 - : 忍法帖【Lv=40,xxxPT】(1+0:8) 【24.9m】 電脳プリオン ◆3YKmpu7JR7Ic [sage] 2013/01/25(金) 23:43:05.28ID:???
- もう語らないのか
- : NAME IS NULL [sage] 2013/03/02(土) 18:51:51.23ID:???
- また必要とあれば語るだろう。
あなたはどうなのか。 - : NAME IS NULL [] 2013/03/15(金) 16:29:53.95:2duRrtZr
- _
|O\
| \ キリキリ
∧|∧ \ キリキリ
ググゥ>(;⌒ヽ \
∪ | (~)
∪∪ γ´⌒`ヽ
) ) {i:i:i:i:i:i:i:i:}
( ( ( ´・ω・)、
(O ⌒ )O
⊂_)∪ - : NAME IS NULL [] 2013/03/20(水) 07:38:57.93:vIKc7Kkm
- ※本投稿の拡散歓迎です。
違法派遣(偽装請負・多重派遣・偽装出向・事前面接等)についての刑事罰
【告訴権者=業務委託、準委任、共同受注、業務請負契約および特定派遣(契約・正規)、一般派遣、正規社員】
@職業安定法第44条の労働者供給事業の禁止規定に違反(1年以下の懲役または20万円以下の罰金)
■偽装請負・多重派遣・偽装出向・多重出向
■事前面接(顔合わせ・面談・職場見学等)と履歴書・職務経歴書・スキルシート等提出による労働者の特定(※)
(音声録音で立証可能)
A労働基準法第6条(中間搾取の禁止) (1年以下の懲役又は50万円以下の罰金)
■多重派遣・多重出向
※違法派遣(派遣労働者の特定)→派遣法で認められた派遣労働者ではない→労働者供給事業→職業安定法44条違反というの
が前提となる法解釈となります。派遣法における罰則が軽微なのは法律の不備や労働者軽視などが原因ではありません。
違法派遣は全て職業安定法44条で裁くことが可能なため、刑罰の重複を避けるために派遣法には軽微な罰則(主に裁量行政による)しかないのです。
使用者に有利な民事訴訟や労働関係諸局への通報等の対極にあるのが書面(告訴状)による刑事告訴(※告訴先は検察の直告班)です。
労働関係諸局への通報・斡旋による軽微な「適正化」や監督・指導に対して、法律に定められた刑事罰を問うことになり、
違法派遣業者にとって有罪は考えられる限り最大の処罰となります。同時に刑事罰を受けた
担当者が取引先に与える悪印象を考慮すれば、通常会社側は告訴が受理された時点で告訴取り下げに
動くのが妥当でしょう。懲役、前科がつく刑罰が下される可能性から、告訴取り下げの和解金は高額となることが多いのです。
告訴の流れとしては、
刑事告訴⇒告訴受理⇒告訴取下げ要請⇒取下げ和解金入金⇒告訴取下げ
となります。告訴の懲役刑適応は犯罪者個人に対してのみですので、告訴する対象は
派遣先・派遣元 社長
派遣先・派遣元 担当者・責任者・管理役員・取締役
派遣先・派遣元 人事管理担当者・人事管理役員・取締役
が妥当です。刑事告訴取り下げの和解金額は犯罪者個人と交渉するとよいでしょう。(告訴状は人数分提出する必要あり) - : NAME IS NULL [] 2013/03/20(水) 12:33:55.35:YfGwk/bV
- お知らせ
市原警察署の生活安全課の帰化人創価警官の指導の元、
入学式から2週間ほど、在日の創価学会員を主体とした自称防犯パトロールが、
2週間ほど行われることになりました
生活安全課の指導であることと、パトロールであることは、
絶対に公言してはいけないとの指導も、帰化人創価警官より出ています
期間中は2人組の在日の創価学会員が、頻繁に創価批判者の自宅周辺を、
うろつき回ると思われます
日本人の方は、充分に注意してください - : NAME IS NULL [] 2013/11/18(月) 19:50:39.02:zznn8NO/
- データモデリングと設計って違うの?
- : NAME IS NULL [sage] 2013/11/18(月) 22:12:02.83ID:???
- 設計のほうが(データモデリングよりも)広い用語だろな
つまり、すべてのデータモデリングは設計の一種だけど、
逆は必ずしも真にはならない
データモデリングはDB設計の中でも上流工程の作業を指し「概念設計」とも呼ばれる
具体的には、現実世界の事物をコンピュータの内部表現に近い
エンティティとリレーションの集合で定義する作業になる
そして、これによって完成したモデルを利用するミドルウェアやフレームワークに
合わせて具体化する作業が「実装設計」になる
実装設計が終えれば(詳細設計もしくは)コード設計が待っている - : NAME IS NULL [sage] 2014/10/20(月) 21:31:26.45ID:???
- 業務系ってクラスモデリングよりもデータモデリングが主流なんでしょうか?
単に興味本位で聞いただけです。 - : NAME IS NULL [] 2015/10/17(土) 02:21:58.10:BkamhfiH
-
業務システムはデータ中心主義だからね。 - : NAME IS NULL [] 2015/11/16(月) 09:18:55.30:xLOuBCtw
- パリテロはやっぱりヤラセ!
クライシス・アクターさんがスターダムに! 早くも偽旗作戦の証拠映像が挙がりました!
ボストンテロとパリ襲撃事件テロ両方に居合わせた世界一不運な女性ですw
◆BOOM! Exposed Crisis Actor from Sandy Hook and Boston Bombing found at Paris False Terrorist Attack
ttp://https://twitter.com/hotaru123a/status/665888328193937408
ISISに襲撃されたパリのバタクラン劇場のオーナーは2015年9月11日に劇場を売却済み。
ttp://https://twitter.com/tokai amada/status/665992523878301696 - : NAME IS NULL [sage] 2015/12/01(火) 01:31:27.19ID:???
- w
- : NAME IS NULL [] 2017/12/29(金) 11:44:21.05:dtNZwIie
- 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
A8RNOMREE3
凡例:
レス番
100 (赤) → 2つ以上レスが付いている
100 (紫) → 1つ以上レスが付いている
名前
名無しさん (青) → sage のレス
名無しさん (緑) → age のレス
ID
ID:xxxxxxx (赤) → 発言が3つ以上のID
ID:xxxxxxx (青) → 発言が2つ以上のID
このページは2ch勢いランキングが作成したキャッシュです。元のページはこちら。削除についてはこちら。