dbdiagram.io - Database Relationship Diagrams Design ToolQuick and simple free tool to help you draw your database relationship diagrams and flow quickly using simple DSL language.
データベース論理設計のアンチパターン - 夜は寝る
おはこんばんちは。 がんばってブログを書きたいので、ちょうどいま読んでいるSQLアンチパターンという本を、噛み砕いて離乳食くらいの柔らかさにして晒してみます。すでに読んだ人はいますぐそっ閉じ、まだ読んでない人は、こちらも同様にそっ閉じしてお風呂に入ってすぐ寝ましょう。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (45件) を見る かなり圧倒的に当たり前のことしか書いてないんですけど、そういう本こそが良書だっておじいちゃんの息子の息子が言ってた気がします。 アンチパターンが全部で25個、ｶｯﾁｮｲｲタイトルとともに紹介されています。「目的」「アンチパターン」「解決策」をそれぞれ示します。本書だと、「アンとパターンを
できるエンジニアになるためのちょい上DB術｜エディラボ｜エディフィストラーニング｜実務に活かせるIT研修
弊社トレーナー中村才千代が、デキるエンジニアのための“ちょい上”DB術を解説します。 DB設計のキモとなるケースを紹介しているので、通常業務と異なる場合でも応用できる「共通の考え方」を身につけられます。 > プロ講師がわかりやすく教えるから、効率よく学べる！ エディフィストのデータベーストレーニングはこちら Oracle / 上流工程 担当 中村 才千代 データベース設計、システム構築の上流～下流工程全般のインストラクターです。SE時代の経験を生かし「業務を知るエンジニアこそDB設計に関わるべき」「DB設計に携わるエンジニアは業務を知る人に知恵を貸してもらう」ことを伝えたいと思っています。 ■認定・受賞 2000年 Oracle University「Best Instructor of the Year」受賞 2002年 Oracle University「Best Instructor
データモデリング・テクニック
4. いろいろなデータモデリング手法 標準的なモデリング手法が存在するわけではない Peter Chen記法：ER図の元祖（だが使われない） THモデル：椿正明／穂高良介 IE (Information Engineering) 記法 IDEF1X (Integration Definition) 記法 T字型ER：佐藤正美 三要素分析法：渡辺幸三 UMLクラス図：オブジェクト指向設計 4 記法や詳細は異なるが、基本は通底している それぞれの方法論は必ずしも排他的ではなく、学べることも多い 5. IE記法 どの記法を使うべきか IDEF1X か IE記法（鳥足）が一般的 今となっては「UMLクラス図」が一番いいかも 誰でも知ってるし、わかりやすい 機能が多いことより、みんながわかる／知ってることが重要 この資料ではUMLクラス図を使うことにする B CA D
リレーショナルデータベースの仕組み (1/3) | POSTD
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
高度な副問合せの構文
連載第11回では、SQL文を入れ子にして条件指定をする構文である「副問い合せ」を紹介しました。今回は、副問合せを応用したさまざまな構文例をご紹介します。 まずは、前回の復習として、「全社員の平均給与よりも、給与が高い社員は誰か」を調べてみましょう。副問合せで全社員の平均給与値を求め、それよりも給与額が高い社員を調べるには、以下のように指定すればよかったですね。 では、次にもう少し複雑な例を考えてみましょう。 「自分が所属する部門の平均給与よりも、給与が高い社員は誰か」を考えてみます。ポイントは、「自分が所属する部門」と比較しなければならない点です。 今までの例（図1）では、「全社員の平均給与」という単一の値と比較すればよかったのに対して、この問合せでは、人によって比較する条件値が異なります。つまり、部門10に所属する人であれば部門10の平均給与と、部門20に所属する人であれば、部門20の平
Gist - Fertile Forest Model - The Cusp of Helix
Fertile Forest Model [Gist] C.1: Hierarchical Data in a RDB We know that it is difficult to store hierarchical data in a RDB. The basic knowledge in order to know the difficulties, are summarized in the following link. Please read at first, because it contains important information in order to understand the fifth model. C.2: Conventional Models DB engineers around the world had been studying the
階層構造をＳＱＬで簡単に操作する
となります。「パス」列にノードまでのフルパスを保持している訳ですね。 この方式のメリットはなんといっても検索が楽なことです。 まぁ、逆に間に追加するような更新は大変なんですけどね どんなことができるか、とにかく次で例をあげていきます。 経路列挙型を使ったデータ取得 サンプルデータ 以下のＳＱＬで作ったテーブルを利用するものとします。 postgreSQLで試しています。 -- create CREATE TABLE department ( departmentcode character varying NOT NULL, departmentname character varying, path character varying, CONSTRAINT department_pkey PRIMARY KEY (departmentcode ), CONSTRAINT departm
データベースの正規化(正規形)とはなんぞや – gomokulog
データベースを扱うには正規化というものを行う必要がある。 その正規化とはなんぞや。 正規化とは、「効率よくデータを扱うために、整理すること」かな。 なぜ、そんなことをしなければならないか。 データを管理する方法はいくつかあるが、主に世の中で使用されているものは、行( タプル, レコード )、 列( カラム、 属性 )で関係 を表現する、関係データベース( リレーショナルデータベース ) と言われるものである。 この関係データベースは、行、列の2次元構造である。 実際の仕事で使用されているような情報は、2次元で表現するには複雑すぎる。 それを無理に関係データベースにすると、色々と残念なことが起きる。 それを上手く管理するためのデータへと分解するのが正規化という手法なんだと思う。 ここからは、具体的例を用いて説明する。 非正規形 例えば、武器や防具等を売る商いをしているGomoCool商会とい
DB設計の基礎【正規化】をマスターしたい - Qiita
はじめに AtraeのAdventCalendar11日目を担当します！２年目の馬場と申します。 やたらと登場回数が多いです。。 前回は、jsのHTTPClientライブラリであるaxiosについて書きました！ ↑↑↑(前回の記事はこちら簡単に実装できるPromiseライクなライブラリaxios使ってみた) 今回は系統を変えて、DB設計について 中でも、DB設計をする上では外せない概念である正規化について 勉強をしたので、アウトプットしていきたいと思っております。 正規化とは何か？ データを正規形にしていくことを正規化と言う。 正規形とは?? ↓↓↓ DBで保持するデータの冗長性を排除し、一貫性と効率性を保持するデータ形式 by達人に学ぶDB設計 徹底指南書 正規化することで、 データの冗長性が排除され、異常(矛盾) を防ぐことができる。 正規形について 上述の通り、DBで保持するデータの
データベース設計についての、僕の知っていることをちょこっと(5) - mike-neckのブログ
こんにちわ、みけです。 しょぼちむにデータモデル設計について教えてくださいの会 #syoboben - connpass 上記の勉強会にでられないので適当に言いたいことを書くシリーズの第……何段だ？これ？ 本日のテーマはT字型ER図とは離れて、よく話題になる(ならない)N次正規化の話 と言いつつ、T字型ER図の話も後半に出てくる… N次正規形 「このテーブルがN次正規形である」という分類は第三次正規化されたテーブルが正義であって、そうでないテーブルが悪であるとかそういう話ではない。 そのように指標となる数字を出しておくことによって、設計の健康状態を把握しやすくすることが目的です。 例えば高速に追加するだけが目的のテーブルにおいては、単純な文字列だけを格納できるテーブルにjsonの状態でレコードが追加されていくだけの正規化されていないテーブルであっても問題無いです。 以下ではデータベースの正
PL/SQLの実行部「IF」文、「CASE」文、「GOTO」文、「NULL」文の書き方
連載バックナンバー 本連載は、Oracle Database向けにデータベース言語 SQL（Structured Query Language）を拡張したプログラミング言語である「PL/SQL（Procedure Language/Structured Query Language）」を理解し、活用していくための実践講座です。SQLは知っているけれど、OracleでのPL/SQLは初めてという人向けに、機能の概要と具体的な書き方を解説していきます。 PL/SQLは「宣言部」「実行部」「例外処理部」で構成されるプログラムであることは前回までに解説しました。今回からは、PL/SQLで実行したい具体的な処理を記述する「実行部」を解説していきます。 実行部にはさまざま手続き処理を記述できます。その中でも次の3つの制御機能を理解すると、プログラミングの幅が大きく広がります。 条件制御：IF文、CAS
4ステップで作成する、DB論理設計の手順とチェックポイントまとめ - Qiita
はじめに 「達人に学ぶDB設計」、「SQLアンチパターン」を読んだのでDB設計をする流れとその過程でのチェックポイントをまとめてみました。 今回は本に載っているものの中でも特に重要そうな部分に絞ってみました。 さらに詳しいことを知りたい方は本を購入してみてください。個人的には達人に学ぶDB設計徹底指南書のほうがおすすめです。こちらだけあれば十分だと思います。 DB設計には大きく分けて論理設計と物理設計の二つがありますが、今回はアプリケーション開発でメインとなる論理設計の部分に焦点をあてて説明をします。 一番最後にチェックポイントだけをまとめた章を用意したので、チェックポイントだけ知りたい方は最後だけ見ていただければと思います。 DB論理設計の流れ DB論理設計は以下のようなステップで進めていきます。 エンティティの抽出 エンティティの定義 正規化 ER図の作成 以下では各ステップごとに章を
データベーステーブル設計の基礎の基礎〜エンティティの抽出・定義から正規化まで - エンジニアHub｜若手Webエンジニアのキャリアを考える！
データベーステーブル設計の基礎の基礎～エンティティの抽出・定義から正規化まで 適切な形でデータベースのテーブルを設計し、運用するには？テーブル設計に必要な初歩を日本MySQLユーザ会副代表の坂井恵さんが丁寧に解説します。 金融系アプリ、ゲーム、人工知能などなど……。どんな種類のシステムを開発する上でも、避けて通れない領域があります。データベースです。データを適切な形式で格納し、取り出す。単純明快ながらも奥深いこの仕組みは、多くのシステムの根幹を支えています。 しかし、適切な形でデータベースのテーブルを設計し、運用するのは簡単なことではありません。「良いテーブル設計」のためには知識と経験が不可欠です。今回は日本MySQLユーザ会の副代表である坂井恵さんに、これからテーブル設計に着手する方に向け、設計に必要な技術と、良い設計を作るための考え方を教えていただきました。 坂井恵（さかい・けい） @
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLで木と階層構造のデータを扱う――入れ子集合モデル