DBエンジニアのための技術勉強会(第3回)で使用した資料です。主にリレーショナルモデルと正規化について解説しています。リレーショナルモデルの限界について正しく認識してこそ、リレーショナルモデルを理解したと言えると思います。
![データベース設計徹底指南](https://cdn-ak-scissors.b.st-hatena.com/image/square/73257ada9a51bd234690f0dcadd58068d7fd671c/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fdb-engineer-study-anim-131128093024-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか? A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOIN → JOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。
チラシの裏的な雑記です。 サービスに新しいデータストアを選ぶ際にこの辺を情熱を持って説明してくれる人が好き、という話です。 そのデータストアを使う理由はなんですか?みんなが使い慣れている物から変える理由は「有名な会社が使っていて^^」「他のチームが使っていて^^」とかではなくて、既存の物では解決出来ない問題を解決するアプローチになっていますか? もし単純にキャッチアップしておきたいというレベルなら、あなたの趣味で作るシステムで運用する、では欲求を満たせませんか? 同じようなプロダクトは他にもあると思いますが、そのプロダクトで無ければいけない理由はなんですか? まだ新しいプロダクトだった場合、あなたはそのコードを読んで、バグを報告して、必要であればパッチを書く覚悟を持っていますか? あなたはチーム内でそのプロダクトの第一人者になる、という覚悟がありますか?他のメンバーへの啓蒙や情報共有を率先
訳者、角 征典氏より献本御礼。「7つのデータベース 7つの世界」はそのタイトルの通り、7種類のデータベースソフトウェアについて解説したNoSQLの道標とも言うべき書籍である。7種類のデータベースとして紹介されているのは、PostgreSQL、Riak、HBase、MongoDB、CouchDB、Neo4j、Redisである。本書は非常にそそるタイトルであり、わくわくしながらページをめくった。だが、第2章「PostgreSQL」で期待感は打ち砕かれることになる。 正直なところ、この書籍について書評を書くのはどうしようか迷ってしまった。なぜならば、第2章の説明がかなり間違っているからである。そのため、書評を書こうとするとどうしても辛口にならざるを得なかった。献本して頂いた角氏にその旨を伝えたところ、それでも良いと快く了承して頂いた。本当に辛口になるのでその点は容赦して頂きたい。 何が問題なのか
スマホアプリ、Webアプリ、デスクトップアプリといったアプリケーションの種類を問わず、なにかしらの情報(データ)を蓄積して活用するアプリを作成するときに欠かせないのが、データベース管理システム(DataBase Management System=DBMS)です。企業などの組織および個人にとって大切なデータ資産を確実に、かつ高速に管理して処理するためには、データ処理に特化した言語であるSQLをはじめとするデータベースに関する知識が必要になります。 本記事では、これからリレーショナルデータベース管理システム(RDBMS)を扱おうと考えている入門者を対象に、データベースの「いろはのい」について、書籍『書き込み式SQLのドリル 改訂新版』から抜粋して掲載します。 本記事をお読みいただき、さらに詳しくデータベースやSQLについて知りたい場合は、ITproのこのページや書籍『書き込み式SQLのドリル
新入社員必読、データベースの基本を理解しよう - データベースはなぜ必要なの?:ITproという記事に対するブクマで次のようなIDコールが来た。(現在はコメント返しへのお礼が入っているので、文字数制限のためオリジナルのコメントは少し切り詰められている。) "リレーショナルデータベースはすべてのデータを2次元の表形式で表現"こういうのもリレーションが2次元構造という誤解の一種なんだろうか。id:nippondanjiさんが書いてたような。 さて、この疑問に対する正解は如何なるものだろうか? つい先日「7つのデータベース 7つの世界」の書評で書いたばかりだが・・・ 言うまでもなくその通りである。 リレーションが2次元的な構造を持っているというのは典型的な誤解だ。(ちなみにリレーションの次元は属性の数に等しい。n個の属性があるリレーションはn次元。)リレーショナルモデルについてちゃんと学習してい
Generate test data for your database Quick recipes to test real applications with random data Table Structure: Export Format: Generated rows: Use an existing data model and customize it to mimick your table structure or create one from scratch. # Column title Data type Delete Add Another Column Clear table Why do I need to fill a database with random data? When developing an application, you would
リレーショナルOLAP データベース解析法「OLAP」のデータベース。検索・集計はサーバー側で行い、クライアントに結果を返す。
「データベース」という言葉は、1950年頃アメリカ国防省において、複数に点在する資料保管場所を一箇所に集約し効率化を図る目的で誕生したと言われています。つまり、一箇所に集約された場所を、情報(Data)の基地(Base)と呼び、これが今日のデータベースの語源とされています。 一昔前は、特殊な場面でしか使用されていませんでしたが、近年では私たちの生活のありとあらゆる場面でデータベースが使用されるようになってきました。「データベース用語集」では、近年私たちの身近な存在となってきたデータベースに関連する用語を紹介しております。その他に国家試験であるデータベーススペシャリストの体験談や過去問題も紹介しております。 更新履歴 ・2013/09/26 『PFILE(パラメータファイル)』を追加 ・2013/09/09 『Oracle Scheduler』を追加 ・2013/08/21 『HWM(Hig
操作マニュアル 「楽楽販売」のシステム管理者向けリファレンスマニュアルです。 機能や設定方法等についてお困りの際にご活用ください。
データベースに接続する PEAR::DBでデータベースに接続するには、DB::connect メソッドを使用します。接続に成功するとオブジェクトが返されます。 オブジェクト = DB::connect( 'データベースの種類://ユーザー名:パスワード@接続先アドレス/データベース名' ); MySQLに接続する場合、データベースの種類は mysql を指定します。もしPostgreSQLに接続したければ pgsql、SQLiteに接続したければ sqlite を指定します。他にも、色々な種類のデータベースに接続することができます。 DB::connect を実行後、実際に接続ができたかどうかチェックします。チェックは「返されたオブジェクトがエラーオブジェクトかどうか?」で判断しています。これは DB::isError を使用すれば調べることができます。 また、エラーの内容は $dbh->
「喜連川といえばデータベース。ずーっとデータベースをやってきました」とデータベース一筋の喜連川先生。その出発点を探ろうと、専攻を選んだ当時を尋ねようとすると「いまより悲惨でしたよ」と言う。 当時コンピュータに関係する学科となると「Electrical Engineering」で、主流は通信だった。中学生のころ「“体育館一面に並ぶコンピュータと書いた記事”を新聞で目にした」という世代である。人工知能や仮想現実などまだまだ先のこと。当時はコンピュータを専門にしようとすること自体が亜流だった。「未来がどれだけあるか分からない」―当時はそのくらい注目度や期待が薄いという意味で「悲惨」だそうだ。 そんなに不確実なものを選んだのはなぜかと尋ねた。先生は「人生、思い通りになるものは少ないですから」と話し始めた。 「ぼくは車の運転が下手でね。車は“こうやって動かす”と分かっていても、雨が降ったら滑ったりす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く