「関連クラス」をデータモデルで解き明かす（前編） - 設計者の発言
ＵＭＬのクラス図に登場する「関連クラス」はわかりにくい。オブジェクト図を描いてもなかなか直感的にイメージできない難物だが、同じ内容のデータモデルと突き合わせることで意味が明確になる。その過程で、データモデリングにおいて識別子を重要視することの意義もわかってくる。 ◆参照関係 まずは「関連クラス」が関係しないノーマルなパターンで見よう。データモデルでの「参照関係」の例と、それに対応するクラス図だ。 データモデルのほうがデータ項目が多いが、それはデータモデリングにおいては「識別子（データモデルで水色に示されている項目）」をエンティティの認識単位とするためだ。だから、データモデリングにおいてエンティティを一覧する作業は、有効な識別子を一覧する作業そのものと言っていい。 いっぽう、クラス図において識別子にもとづくユニーク性は問題にされないため、データモデルで認識されるような識別子が載っていないこと
DB設計の難しさ
今日は徒然なるままにDB設計について思っていることを並べてみようと思う。 ようやくWEB+DB Pressの次号の原稿を書き終えた。2年間の連載であるが、来年はプライベートが忙しくなる予定なので、連載はこれにて終了とさせてもらうつもりである。 「なぜ人はリレーショナルデータベースを使いこなせないのか」 このところ執筆や講演を通じてリレーショナルモデルについて説明する機会を色々頂いているが、それらの活動の根源となっているのが、この素朴な疑問である。その疑問をパワーにしてこれまで活動を行なってきた。 現時点での自分の回答は「データベース設計が難しいから」である。もちろんリレーショナルモデルそのものの難しさというのもあるが、それよりは「適切な使い分けができていない」ということが大きいように思う。言葉を変えると、リレーショナルモデルを適用すべきデータとそうでないデータの判断ができていないからDB設
InfoQ: データの削除は非推奨
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
SQLアンチパターンを読みました
by @dekokun on 2013/02/26 8:15 Tagged as: SQL, 書籍. デプサミ2013で和田さんのSQLアンチパターンの講演を聞けなかった腹いせにSQLアンチパターンを購入して読んでおりましたが読み終わりましたので投稿。 だいたいの内容 世のシステムのかなりの割合で使用されているとおもわれるRDBMSを使用したシステムを作る際に開発者(DBAなど含む)が陥りがちなアンチパターンがまとまっている本です。 「インデックスショットガン(無闇やたらとインデックスを貼りまくる)」などの「そりゃ当然やっちゃいけないよね」と誰しもが納得するものから、「IDリクワイアド(すべてのテーブルにID列をつける)」など、一部の人には「あれ、それって何がダメなんだっけー」というもの、「リーダブルパスワード(パスワードの値を読める状態でDBに保存)」などの、いわゆる「DB設計についての
「データモデリングライブ＠名古屋」報告 - 設計者の発言
名古屋での初のモデリングライブでは、連休中にもかかわらず２５名の方々が集まってくださった。取り上げた題材は不動産屋さんの物件管理代行事業のためのシステムである。テーブル数もプロセス数もちょうどよい数だったと思う。 ＤＦＤとＥＲ図を比べると、ＥＲ図のタッチのほうがキレイだ。これはそのときのマーカーの書き味が良かったためである。新鮮で書き味の良いマーカーを選ぶことは、ホワイトボードを使ってモデリングするときの最強のコツである。そうすることで、モデルは「見つめていたい絵」になる。結果的に、ユーザにじっくり見つめてもらえるのでモデルとしての適切さも向上する。弘法ではないモデラーはマーカーを選ぼう。 実際のモデリングの手順は次のとおりだ。「要件定義」のための洗練された手法や「超上流」の分析作業などは要らない。だから、モデリングライブではいきなり１と２を見てもらえる。それは、３と５は「持ち帰り」でなさ
渡辺幸三が語る「データ中心設計の基本とクラウド開発」＜第17回関西IT勉強宴会＞
今回も前回に引き続きシナジーマーケティングさんの会議室をお借りしました。ありがとうございました。前回は18時にしましたが今回は定刻の19時です。参加者は19名。しかも初参加の方が８名もいらっしゃいました。予定通り21時すぎに終わり11名で2次会開始。仕事の都合で勉強会はドタキャ...
概念モデルと論理モデルの違い（後編） - 設計者の発言
前編では、通常のデータ項目（値項目）に加えて「実体そのもの（実体項目）」を利用する点が、概念データモデルの特徴であると説明した。これによって「作為的なデータ項目」を持ち込まずに、管理対象をデータモデリングの俎上に置けるようになる。前編で説明した参照関係（モデル１）に続いて、もう少し例を見ていこう。 ＜モデル１＞（前編より再掲） 【社員管理表】[社員],社員名,生年月日,性別,... ＋ ￣￣￣ ｜ ① 山田 ... ｜ ② 鈴木 ... ｜ ③ 佐藤 ... ｜ └─…【活動履歴管理表】[活動履歴],[社員],[趣味],実施日,... ┌─… ￣￣￣￣￣ ｜ ⑥ ① ④ 9/11 ｜ ⑦ ③ ⑤ 9/12 ｜ ⑧ ① ④ 9/18
代理キー - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "代理キー" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2022年12月) 代理キー（だいりキー、英: alternate key）は、コンピュータの関係データベースの関係モデルにおいて、関係の候補キーのうち主キーとして選ばれなかったキーをいう。 例えば、関係データベースで社員関係変数 (社員テーブル) があり、社員関係変数は「社員番号」「社会保障番号」などの属性をもつとする。 この場合、「社員番号」と「社会保障番号」はともにある社員の一意識別子となる。 このため「社員番号」もしくは「社会保障番号」はいずれも主キーとして使うことがで
新刊「チケット駆動開発」の紹介／サロゲートキーとデータモデル<第19回関西IT勉強宴会>
今回も、シナジーマーケティングさんの会議室をお借りしました。毎回ありがとうございます。 参加者は13名 。ちょっと事情があり参加者を絞ったのですがそのおかげで一つの大きなテーブルを囲む形式で全員で議論が出来て大変楽しかったです。 今回は皆さん翌日に用事があったようで２次会に...
「達人が語る こんなデータベース設計はヤダ！」へ参加してきました - 虎塚
あの『達人に学ぶDB設計 徹底指南書』を書かれたミックさんが講演されると聞いて、Club DB2さんの勉強会に初めてお邪魔してきました。 「第146回 達人が語る こんなデータベース設計はヤダ！」 https://www.ibm.com/developerworks/wikis/display/clubdb2/146 非常に面白く、勉強になりました。せっかくなので、備忘メモをupしておきます。 （内容に誤りがあったり、もし掲載自体に問題があったりしましたら、修正・削除しますのでお知らせください。＞関係各位） 本編 （追記）発表資料にリンクしました。 http://d.hatena.ne.jp/mickmack/20120714/1342246442 ミックさんが「これだけは覚えて帰ってください」とおっしゃった3つのポイントを引用します。 トレードオフ うまい話には裏がある。 物理 vs 論
第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モデルにおける実体を四角形として記
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[SQL][Ruby]SQLアンチパターン@Sendagaya.rb #141 | アペフチ