【Rails関西】Rails屋からデータモデリングに対する回答 - プログラマの思索
1/20に開かれた第6回RubyOnRails関西へ行ってきた。 場所は神戸電子専門学校。目の前にオランダ館、風見鶏館などの異人館があり、華やかな場所でした。 このたびの発表の中で最も興味を引いた講演が「やさしいRailsの育て方」(by 西和則さん)。 講演内容は、Railsでもテーブル設計をきちんと考えましょう、ということなのだが、それは昨年8月の渡辺さんの指摘に対する回答になっているように思う。 【1】RDBのテーブル設計におけるアンチパターン Railsをやっていると、例えば、下記のアンチパターンに囚われてしまう。 １・無限ＦＫ地獄や列破綻 テーブルに他テーブルの外部キーをどんどん持たせると列が増えていく。 西さんの例では、社員テーブルに派閥1、派閥2のカラムを増やしていた。 ２・フラグステータスとバタフライ効果 「北京で蝶が羽ばたくとニューヨークで嵐が起きる」がその意味だが、「小
Tags: Database schemas
An online tech community is the most exciting place for a software developer to spend their time. It not only offers the chance to work and interact remotely, but also helps in honing one’s own skills and becoming a well-rounded programmer. Whether you are a budding software developer or simply passionate about technology, here are the best online software development communities you can join. The
フラグを属性にするか、リレーションシップにするか - 極北データモデリング
オブジェクトモデリングで何だかよく分からないことに、あるデータ項目を属性にするか関連にするかの基準があいまい、というのがある。 怪しい世界だなあと思って見ていたが、考えてみるとデータモデリングの世界もおんなじです。 あるデータ項目を「属性にするのか、新しいエンティティを生成してそこに入れるか」が、流派によって違う。 どの流派も正規形であることは変わらないのだが... 例えばRDBでは、区分コード＝いわゆるフラグを、別のテーブルとのリレーションシップで表すことができる。 で、あんまりやったことないけど、これからは区分コードを極力排除して、区分をリレーションシップで表現することにしようと思ったのです。 例 商品マスタの中に、現役商品と廃盤商品の両方が入っているとする。 商品マスタ = { 商品ID(PK), JANコード, 商品名, 廃盤区分(Yes/No) ... } また、商品を集めてカタ
Using DBDesigner to generate Rails files | Bill Katz
An occasionally updated repository of thoughts, past work, and links. Topics include programming, web ventures, and writing. dbmodel is a tool to generate Rails files (models, scaffolds) from a free graphic database design tool, DBDesigner 4. You can create tables in DBDesigner, specify table relations, synchronize the model with a MySQL database, and then use dbmodel to automatically generate cod
エンティティの見出し方・属性の割り振り方 - 伝統的設計・T字形ER手法・ABD - 極北データモデリング
非正規形の表が与えられたときに、その表を出力できるDBをどうやって設計するか。 伝統的DB設計法・T字形ER手法・ABDのやり方を並べて書いてみる。 伝統的DB設計法 伝統的なDB設計では、非正規形の表を正規化する過程で、エンティティを切り出していく。 また正規化しながら、関数従属性に従って属性を割り振っていく。 データ項目の意味は考えず、データ項目の重複が最小になるように分解するので、m:nの関係の時以外は交差エンティティは発生せず、「社員マスタに所属部門コードがある」といった結果になる。 T字形ER手法 上記を問題視したのがT字形ER手法。 T字形ER データベース設計技法 P-26 ER手法が大きく勘違いされた点は、データを正規化してから、ER手法を使ってデータ構造を表現する、という点にある。 つまり、ER手法が表現手段に成り下がってしまったのである。ER手法は、思考手段(解析手法)
代理キーは「スタイル」ではなく「テクニック」 - 設計者の発言
データモデリングでは、複合キーに代わって単一項目の代理キー（サロゲートキー）を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル（基本方針）」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）ことになっているとする（在庫管理では典型的な業務要件だ）。この関係をデータモデルで表すとモデル１のようになる。横浜第１倉庫でA01の棚に保管されることになっている商品１００の現在庫が２５０個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル２のようになる。 ２つのモデルの形式上の違いはどこにあるのだろう。モデル１では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ
capsctrldays - フリーのERDモデリングツール：Toad(TM) Data Modeler , メモリとモニタが欲しい！
1 [DB] フリーのERDモデリングツール：Toad(TM) Data Modeler via The Joel on Software Discussion Group - Free Database Modeling Tool? 無料のERDツールってDBDesigner4くらいしか使えるものがなかったんだけど、これはいいなあ。論理モデルと物理モデルを描けるのがいいなあ。論理モデルは日本語で、物理モデルは英語表記で、ってなことができる。それに、いろんなRDBMSをサポートしてる。これぞ求めているものだなあ（烏足記法なのがイヤだけど）。 画面はダサいけど、レポート出力したやつはなかなかカッコヨイ。 有償版になると、リバースエンジニアリングができて、DFDが描けるようになるそうな（要らないよね）。 追記 いつからかフリー版は無くなってる？ 以前のバージョンをダウンロードできるサイトがあ
関数従属性は多重度に先行して認識される - 設計者の発言
「ライド・オン・Rails」を読んで、著者のひとりの馬場さんにメールしたのが縁で「RubyOnRails勉強会@関西」で話をしてきた。業務システムに関わるためには簿記の知識が必須だとか、デーモデリングの基礎知識なんかを漫談風に解説してタダ酒をご馳走になった。 大胆にもRailsの問題もいくつか指摘した。そのひとつが、Railsで利用されるＯＲマッパActiveRecordでは「複合キー」に関数従属する項目の存在を認めていない点だ。そのような業務要件を含むデータベースをRailsでは扱いにくい。 たとえば、「契約単価」は「顧客コード」と「商品コード」との組み合わせに、「月次ＴＴＭレート」は「通貨コード」と「年月」との組み合わせに関数従属する。こういう関係は業務システムではふつうに存在する。Railsは本格的な業務システムを扱うためのフレームワークではないのだからいいじゃないかと考える向きもあ
【感想】RubyOnRails 勉強会@関西とデータモデリング - プログラマの思索
デスマーチ・プロジェクトに束の間の休日ができたので、RubyOnRails 勉強会@関西に初参加してきた。 Ruby勉強会＠関西と同じく、女子学生や女性エンジニアも多くて、華やかな雰囲気で、講演も甘辛だった。 僕はRubyOnRails初心者なので、聞きやすかった。 聴講の目的は、もちろん渡辺さんの「アジャイルにデータモデリング」。 「何故、RubyにDOAの第一人者の渡辺さんがいるの？」みたいな。 【1】RubyOnRailsに、複合キー(複数の識別子)を持つテーブルはない！？ 渡辺さんのお話は、業務システムとデータモデリングの関係から始まり、テーブルの項目の関数従属性の説明と演習まで、というとても初心者向けの講義。 懇親会で業務に携わっていると言うエンジニアの女性が、 「私はRailsのインストール方法も知らない初心者だが、渡辺さんが話した関数従属性や正規化の話はとても基本的な話です」
L'eclat des jours(2006-06-26)
_ まとめ 良くわからなくなったのでまとめてみた。わかる粒度が名前を知ってるだけ、概念を理解している、実際に利用したまでばらけているので、嘘八百のような気もする（というか、嘘は確実にある）。 こういうときにマインドマップってのを使うんだろうか？ EA（全体統合） BA …… プロセス DA …… データ AA …… 制約 TA …… 実装 DOA（AS IS重視）—フラット—物理モデル—ボトムアップ まずモノ（エンティティとリレーション） 検証手段：エンティティの整合性 思考法：join 抽象的 T字型派……純粋抽象派（ここに含めるべきではないのでは） ↑ 伝統派……業務分析 ↓ TH派……帳票上のエンティティ 具象的 はぶ派……UI（Webのページ、帳票など）上のエンティティ＋業務フロー （頂いたコメントを元に修正：7/1） 伝統派……業務分析 TH派……帳票上のエンティティ
考えさせられる - yojikのlog
RubyKaigi2006 RESTのPOST,GET,PUT,DELETEとDB(というかリソース)のCRUDの類似。Webアプリケーションにおける殆どの操作は、リソースのCRUDに対応させることができる。*1 実際のアプリのレベルに落として考えると、例えばユーザをグループに追加する際に、ユーザコントローラに対して「グループに加入させよ」メッセージを送る*2のではなく、メンバシップコントローラに、ユーザ-グループ間のメンバシップをCREATE(REST的にはPOSTで依頼)してもらう事になる。*3。 上記を徹底すればWeb(アプリ|サービス)が、外部からDBのように扱えるようになる。多分、この話がActiveResourceに繋がる。(のだと思う) なんか学ぶべき点が多そうです。 あと個人的には、DBのように扱うためには、ユーザ(や他のアプリ)との対話の中で、適切な単位でCRUDを纏め上
複雑さに金が落ちる時代は本当に終わるのか？ - アンカテ
RailsやChuraのいけてないところ これは、Ruby on Railsに対する実に的確な批判だと思う。だが、これによって逆にRailsの意味が見えてきたような気がする。 (このエントリ、入口はソフトのやや専門的な話ですが、例によって大風呂敷で、そこから"The World is Flat"の話につながっていくので、できればプログラマ以外の方もおつきあい下さい) Railsというソフト開発ツールの良さは、単に便利とかフルスタック(必要な全ての機能盛合せ)ということではなく、実践的な仕事の流れが背後に想定されていることだ。頭をひねってツールを使いこなすというより、ツール(が想定しているソフト開発手順)に「乗る」という感覚で開発を進めることができる(まさに On Rails)。 だから、Railsの個々の機能の過不足を問題にするのはあまり意味が無い。仮に不足があったとしても、オープンソース
RailsとABDとCRUDとワークフロー - moroの日記
羽生さんのABD(Activity Based Datamodel)ですが、それを知った感想を自分なりにすごく乱暴にまとめると、DBをイベント系とリソース系にわけた上で、仕事っていうのはリソース間やイベントとリソースの間になんらかの関係を発生させる捉える、という考え方かなぁ、と。 イベントとリソース 売上げが立つ、というイベントはつまりお客さん(リソース)と商品(リソース)との間に購入/入金という関連が発生するというふうに捉えられます、と。 あんまり例えが良くありませんが、ビジネス上のできごと＝イベントに着目し、イベントも関連テーブルのエンティティを素直にcreateすることで表現するという方法論だと読んでいます。 さらにDBを設計するということは、そういったイベント、すなわちビジネス上のアクティビティをどう記録するか、という観点でデータの持ちかたを設計していくということなんじゃないでしょ
【レポート】Developer Summit 2006 - DBは超グローバル変数、どう設計するか | エンタープライズ | マイコミジャーナル
本稿では、2月9日に目黒雅叙園で開催された翔泳社主催のカンファレンス「Developers Summit 2006」から、スターロジック代表取締役兼CEO 羽生章洋氏のセッション「楽々ERDレッスン〜これが楽々DB設計の勘所！〜」の模様をレポートしたい。なお、羽生氏は、Seasarファウンデーションの理事を務めるなど、オープンソースソフトウェア開発コミュニティでも活躍中である。 さて、システム開発の現場において、データベースの設計は特に重要視されることが多い。では何故DB設計が重要なのか、という問いに対し、羽生氏は「DBはアプリケーションをまたがる『超グローバル変数』だから」だと語る。個別のプログラムにおいてさえグローバル変数の使用には注意が必要なのだから、時として複数のシステムに影響を及ぼすデータベースの設計に最大限の注意が必要なのは当然、というわけだ。データベースの設計がいい加減だと、
『社員マスタという不思議なエンティティ（第２回）』
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
O/Rマッパーの新しい形? - Hydrate 2.0 | エンタープライズ | マイコミジャーナル
Hydrate 2.0 リリース The Hydrate Projectは4日(米国時間)、Hydrateの最新版であるHydrate 2.0を公開した。HydrateはJavaで作成されたデータ変換用ツール。RDBMS、XML、オブジェクト指向言語という3つの異なるデータを相互にシームレスに変換する操作を実現する。 RDBMS、XML、オブジェクト指向言語という3つの異なるデータは、UMLというデータ形式でニュートラルに表現することができる。HydrateはそれぞれのデータをUMLでモデリングするためのツールのようにもみえる。 図1 オブジェクトモデルおよびXML Schema定義の可視化ビュー 図2 可視化ビューで使われているクエリの編集画面 Hydrate 2.0はGNU LESSER GENERAL PUBLIC LICENSE Version 2.1のもとで公開されているオープン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://d.hatena.ne.jp/habuakihiro/20060827
http://d.hatena.ne.jp/habuakihiro/20060203
http://capsctrl.que.jp/kdmsnr/diary/20060620.html
6月のはぶにっき