TDDでデータベースと付き合う方法
はじめに データベースを読み書きする部分のユニットテストがやりにくいのには、いくつか理由があります。 複数人でテストを同時に実行すると、競合する データベースを使ったテストは、時間が掛かる データベース内のデータが変わると、テストが失敗する 1番目は、各自の開発環境にテスト用のデータベースを用意することで、解決できます。2番目の問題は、データベースにアクセスするコードをロジックから分離して、データベースに実際にアクセスするテストケースを減らすことで、改善できます（ロジックのテストにはモックやダミーを使います）。3番目は、テストのたびにデータベースの内容を初期化することが基本になりますが、そうするとテストに長い時間が掛かるようになってしまいます。 今回は、ビジネスロジックの開発時にモックやダミーを使いやすくするにはどうするか、また、テスト時にデータベースの内容を安定させるにはどうしたらよいか
DB管理者がいますぐ確認すべき3つの設定
DB管理者がいますぐ確認すべき3つの設定：真・Dr. K's SQL Serverチューニング研修（4）（1/3 ページ） 管理者の力量があらわれる3つの設定 前回、設定された値を見るだけでDB管理者の力量が見える、ということに触れました。今回も必ず押さえておきたいパラメータを、なぜそのように設定すべきかという理由と併せて解説していきます。 設定すべきポイントは大変シンプルです。 tempdbの数をCPUコア数にあわせよ x64環境なら「メモリ内のページロック指定」を変えよ OLTP環境では、並列処理の最大限度（Max DOP）はCPUコア数の「4分の1」に設定せよ もちろん、これだけ変更すれば、その部分における最低限のチューニングは完了します。しかし1つ上のエンジニアを目指すなら、その理由まできっちり知っておくべきでしょう。その理由を知ることで、監視ツールや動的管理オブジェクトが発する「
NoSQLデータモデリング技法
NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文：NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
基礎から理解するデータベースのしくみ（2）
図1●リレーショナル・データベース管理システム（RDBMS）が，受け取ったSQL文を実行するまでの処理の流れ SQL文を記述してデータベースを操作することはそれほど難しいことではありません。しかし，リレーショナル・データベース管理システム（RDBMS）が問い合わせを実行する速度は，SQL文の書き方によって大きく異なります。ちょっとした記述の違いによって，応答時間が何倍も違うことはめずらしくありません。 では，速いSQL文を書けるようになるためには，どうすればいいのでしょうか。その答えは，「RDBMSがSQL文を内部でどのように処理しているのか」を理解することです。RDBMSは，プログラマが記述したSQL文を基にさまざまな処理を行ってから実際にデータベースにアクセスします。その過程を知ることで，アクセスのしかたをコントロールできるようになるのです。 例えば，CUSTOMERS（顧客）テーブル
基礎から理解するデータベースのしくみ（1）
「データベースはブラックボックス。どんなSQL文を投げたらどんな結果が返ってくるかさえ知っていればよい」---そう思っている人も多いかもしれません。確かに，最近の市販のリレーショナル・データベース管理システム（RDBMS）にはGUIベースの管理ツールなどが付属し，データベースそのものについての深い知識が求められることは昔に比べれば少なくなりました。メモリーやディスクなどのハードウエア・リソースが増えて，開発者のスキル不足が表面化しにくくなったこともあるでしょう。 しかし，本物のソフトウエア・エンジニアを目指すのであれば，データベースが動く仕組みを学ぶことは避けて通れません。「SQL文を受け取ってから結果を返すまでにRDBMSがどんな処理をしているのか」「データ・ファイルの物理構造はどうなっているのか」「インデックスはどのように格納されているのか」——。こうした知識がないと，パフォーマンスな
【DB概論】データベースシステムに求められる要件
【DB概論】データベースシステムに求められる要件：できるエンジニアになる！ ちょい上DB術・基礎編（1） デキるエンジニアになるためには、DB技術の基礎は必須です。本連載では、豊富な実例と演習問題で、プロとして恥ずかしくない設計手順を解説します。DB設計のポイントとなる汎用的なケースを紹介しているので、通常の業務とは異なる場合でも応用できる「共通の考え方」を身に付けられます。 デキるエンジニアになるためには、DB技術の基礎は必須です。 「使える」システムを構築するには、データベース設計がと非常に重要です。先人が遭遇したトラブルを避けられるかどうか、システム構築やアプリケーション開発が成功するか否かは、データベース設計にかかっているところが大きいです。 本連載では、豊富な実例と演習問題で、プロとして恥ずかしくない設計手順を解説します。システム構築において「どの工程で、どのような観点からデータ
素早く正規形を見抜く実践テクニック（1/4） － ＠IT
今回のテーマはデータベースエンジニアの必須知識の1つである「正規化」です。正規化は、リレーショナル・データベースのテーブル設計を行ううえで非常に重要なテクニックであり、データベースを設計、実装したことのある方なら一度は正規化に触れているのではないでしょうか。 それほど基本的な知識であるにもかかわらず、正規化を説明できる人はなかなかいません。多く聞かれるのが「何となくテーブルを作ると自然に第3正規形になる」とか「実務上は第3正規化まで行えば問題ない」というものです。 ではなぜ「第3正規化まで行えば問題ない」のでしょうか。本稿ではひととおり正規化について確認しながら、あまり触れられることのない第3正規化より先の正規化を紹介して、この疑問に答えていきたいと思います。 正規化の位置付け 正規化は、データベース設計全般にかかわる基礎知識ですが、特に論理データモデリングの作業の中で必要になります。本稿
連載記事 「データベースエンジニアへの道」 － ＠IT
Oracleライセンス「SE2」検証 CPUスレッド数制限はどんな仕組みで制御されるのか （2017/7/26） データベース管理システムの運用でトラブルが発生したらどうするか。DBサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle SE2の「CPUスレッド数制限」がどんな仕組みで行われるのかを検証します ドメイン参加後、SQL Serverが起動しなくなった （2017/7/24） 本連載では、「SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ドメイン参加後にSQL Serverが起動しなくなった場合の対処方法」を解説します さらに高度なSQL実行計画の取得」のために理解しておくべきこと （2017/7/21） 日本オラクルのデータベーススペシャリストが「DBAがすぐ
「トランザクション」に関する問題 （1/3） － ＠IT
「トランザクションの原子性」とは、トランザクションのACID特性の1つで、トランザクション処理はすべて実行されるか、1つも実行されないか、いずれかの状態で終了するという特性です。従って、「イ」が正解です。 ほかの選択肢は次の点が間違っています。 ア 分散データベースの「位置の透過性」の説明 ウ ACID特性の「一貫性」の説明 エ ACID特性の「独立性」の説明 データベーススペシャリストに限らず、午前問題は、知っていれば解ける「知識問題」と、計算などが必要な「作業問題」に分けることができます。 トランザクションに関する問題は、デッドロックの発生タイミングなどを見極めさせる作業問題の方が多く出題されています。時間や労力がかかり、問40の前後という試験終盤に位置することから、ミスをしやすい分野といえます。 その中にあって「トランザクションのACID特性」は、トランザクションに関する問題では数少
「分散データベース」に関する問題 （1/3） － ＠IT
問4-1 分割に対する透過性 分散データベースシステムにおける“分割に対する透過性”を説明したものはどれか。 ア データの格納サイトが変更されても、ユーザーのアプリケーションや操作法に影響がないこと イ 同一のデータが複数のサイトに格納されていても、ユーザーはそれを意職せずに利用できること ウ 1つの表が複数のサイトに分割されて格納されていても、ユーザーはそれを意識せずに利用できること エ ユーザーがデータベースの位置を意識せずに利用できること
「SQL」に関する問題（1/3） － ＠IT
1つの表「会員」を自己結合したSQL文の実行結果を問う問題です。各会員の「リーダ会員番号」から、各会員のリーダの生年月日を割り出し、会員自身の生年月日と比較します。結合結果の属性を簡単にまとめると次のようになります。 ◆会員とリーダの属性（会員番号/会員名/生年月日） 会員 ------------------ リーダ 001/田中/1960-03-25 --- 002/鈴木/1970-02-15 ---条件を満たす 002/鈴木/1970-02-15 --- 002/鈴木/1970-02-15 003/佐藤/1975-05-27 --- 002/鈴木/1970-02-15 004/福田/1960-10-25 --- 004/福田/1960-10-25 005/渡辺/1945-09-01 --- 004/福田/1960-10-25 ---条件を満たす この結果から、「X.生年月日 ＜ Y.
「データモデル」に関する問題(1/3) － ＠IT
問2-1 素早く正規形を見抜く 第1、第2、第3正規形とそれらの特徴a～cの組み合わせとして、適切なものはどれか ※（ア～エから選択） a どの非キー属性も、主キーの真部分集合に対して関数従属しない。 b どの非キー属性も、推移的に関数従属しない。 c 繰返し属性が存在しない。 （19年-午前問題-問24） a～cは、次の正規形の説明になっています。 a：第2正規形 b：第3正規形 c：第1正規形 これを第1、第2、第3正規形の順に並べるとc、a、bとなります。従って、「ウ」が正解です。 第1、第2、第3正規形の特徴を問う問題は、午前問題、午後問題ともによく出題されています。違いを説明できるようにしておきましょう。 午前問題はこの問題のように選択式ですが、午後問題では「表aは第何正規形まで正規化されているか。その根拠を具体的に3つ挙げ、それぞれ40字以内で答えよ」と、理由を含めて答えさせる
「データモデル」に関する問題（1/3) － ＠IT
概念データモデルは、実社会のデータを抽象化して表現したものです。データベースを集中型にするか分散型にするかなど、格納方法についての物理的な要件は含まれません。従って、「エ」が正解です。 ほかの選択肢は次の点が間違っています。 アは、論理データモデルの説明です。 イは、抽象化するのは業務プロセスではなくデータです。 ウは、物理データモデルの説明です。 概念データモデルでは、どのようなデータが、どのような関係にあるかを構造図で表現します。 例えば、「商品」と「売り上げ」というデータ（エンティティ）と、その関係（リレーションシップ）をER図で表現したERモデルがその典型的な例です。情報処理技術者試験ではER図やUMLを見て概念データモデルを解釈したり作成する問題（午後）が出題されています。 午前問題で出題されるデータモデルの問題はこの問題のように、特別に難しいわけではありません。問い方も似ており
春期試験の押さえどころを総ざらい！ （1/5） － ＠IT
本連載では、テクニカルエンジニア（データベース）試験に対応できる知識を確認していきます。多岐にわたる知識が問われる試験ですので、受験する方はもちろん、日常業務ではあまり使うことのない技術知識の確認にも役立ててください。 はじめに 本連載では、テクニカルエンジニア（データベース）試験に対応できる知識を確認していきます。初回の今回は、春期試験の直前対策になるよう、押さえておきたい頻出キーワードや問題パターン、記述問題の問われ方などを紹介します。以降の本連載を読み進めるうえでも参考になりますから、ぜひご一読ください。心配なポイントや苦手な分野は実際の過去問などを参考に学習しておきましょう 。 試験の概要 テクニカルエンジニア（データベース）試験（注1）は、次のように午前問題、午後1問題、午後2問題という3部構成で実施されます。
削除フラグのはなし
6. id name pass is_deleted 1 ryu xxx FALSE 2 ken xxx FALSE 3 honda xxx TRUE 8. id name pass is_deleted 1 ryu xxx FALSE 2 ken xxx FALSE 3 honda xxx TRUE 3 honda xxx FALSE
SQL緊急救命室 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
データベースの内部動作を知る
SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基本的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの？ Part 1：SQL文はどのように実行されるのか SQL実行までの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
連載記事 「真・Dr. K's SQL Serverチューニング研修」 － ＠IT
できるエンジニアになるための ちょい上DB術・基礎編 インデックス － ＠IT自分戦略研究所