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