列指向データベースのページのデータ構造 - ablog
行指向データベースは行単位でページ(Oracle Database でいうデータブロック)にデータを格納しているのに対して、列指向データベースは列ごとにページに格納している。クエリ実行時に結果セットを返す際に列別にバラバラのページに格納されているデータをどうやってタプル(レコード)に復元している*1のかと思ったがやはり行IDのようなものを持っているようだ。 行ID は C-Store では pid、MonetDB では BAT(Binary Association Tables) の oid と呼ばれている。 The Design and Implementation of Modern Column-Oriented Database Systems NSM(N-ary Storage Model): 行方向でブロック（ページ）にデータを格納する方式 DSM(Decomposition
Embulkを業務システムで使った話 - 今日もプログラミング
背景 自分はSIerのエンジニアである。 いろいろなお客様の、いろいろな業務システムと格闘するのがお仕事である。 また、今はembulk-input-jdbcとかembulk-output-jdbcのコミッタもやっている。 業務システムとRDBとテキストファイル 業務システムでは、たいていRDBを使っている。 そして、サーバ間でデータを連携するために、RDBからテキストファイルにエクスポートしたり、テキストファイルをRDBにインポートしたりすることが結構ある。 そんなときどうするかと言うと、RDB付属のツールを使うことが多い。 例えば、OracleへのインポートであればSQL*Loader、MySQLへのインポートであればmysqlimport、というように。 RDB付属のツールの問題点 いろいろなお客様がいて、いろいろなシステムがあるので、RDBもいろいろである。 ちなみに、うちの会社で
jOOQ (Java Object Oriented Querying) の使い方の紹介 - 愛と勇気と缶ビール
jOOQ (http://www.jooq.org/) についてのメモ。 jOOQは、type safeかつdatabase orientedなクエリビルダーである。 database orientedなので、「アプリケーションからDBのことなんて全然意識したくないねん」的な思想に基いて作られた類のプロダクトとは異なり、思い通りのSQLを生成できるようになっている。 以下gradle前提で。version等はよしなに。 gradle dependenciesはこんな感じ compile 'org.jooq:jooq:3.7.1' compile 'org.jooq:jooq-meta:3.7.1' テーブル等に相当するクラスをgradle taskから生成するためにbuildscriptのdependenciesにも以下をかいておく classpath 'org.jooq:jooq-cod
使える論理削除への道(1) それは論理削除の問題なのか - 極北データモデリング
削除フラグ(というか「論理削除を削除フラグだけで実装すること」)批判は何度も見てきたが PostgreSQLアンチパターン これ見るともはや論理削除自体が闇扱いになってしまったようだ。 闇だろうと何だろうと論理削除(というドリルが提供する穴)は要件の実装に必要なので、このへんの議論はあまりまじめに追ってこなかった。 いつだったか「削除フラグはバグの温床だからやめろ」という主張を読んでおぉなるほどと思い、ではどうやって論理削除を実装するのかなと思って続きを読むと「『ほんとに削除したデータが必要ですか?』とユーザに確認して、物理削除に変えさせてもらう」と書いてあってズコーとなったことがあるが、要件削っていいなら実装上のどんな問題も消えるわけで、何かもう別世界の議論で自分の仕事には関係ないと思っていた。 が、これだけ繰り返し批判されているからには、論理削除を正しく使う方法なり条件なりを明らかに
MySQL・PostgreSQLユーザーグループ（MyNA・JPUG）合同DB勉強会で発表した資料を公開しました。「データモデルについて知っておくべき7つのこと 〜NoSQLに手を出す前に〜」
表題の通り、MyNAとJPUGの合同DB勉強会で発表をしたので資料を公開した。 内容の詳細はスライドそのものを見ていただくとして、言いたいことの主旨はこうである。世の中に完璧なデータモデルはないので、NoSQLは当然の如く必要になる。だが、何でもかんでもNoSQLを使えば良いというものではない。むしろアプリケーションが必要としているデータモデルが何かということをよく理解し、本当に必要な場合にこそ、NoSQLを使うべきなのである。つまり「ご利用は計画的に！」ということだ。 大切なのは、様々なデータモデルを理解し、アプリケーションにとってベストな製品を選択するということだ。ベストなのがRDBかも知れないし、そうでないかも知れない。最適なデータモデルを選択した場合に、出来上がったものの性能も最高になるし、開発効率も最も良くなる。データベースの主流はRDBだが、それはリレーショナルモデルがカバーで
nullについて最後まで考える(1) --- T字形で消せるnull，消せないnull - 極北データモデリング
正美氏とかDateの本を読むと、Codd論文を理解するとnullの存在が許せなくなるのだなあ、と思う。 私はこのnull徹底排除の感覚が理解できていない。Codd論文読んだことないし。 比較演算や集計演算の対象に null が混入していると、直感に反する結果が出てくることがあるのはわかる。 同僚がnot null制約を付けていないのを見つけると「付けないとだめっすよ」と言ったりもする。 でも、これはわかった振りをしているだけなのだ。 nullがよくないのは当たり前として、あらゆるアプリケーションでnullを発生させないことができるのだろうか？ どうしても発生するケースがあるのだとすれば、どのnullはあってもよくて、どのnullはあってはならないのか？ where句に出現するnullと、サブクエリが返すnullと、アプリケーションに返されるnullと、罪の重さは全部同じなのか（違うんじゃな
リレーショナルモデルについて
Mikiya Okuno @nippondanji 第一正規形の条件は、テーブルがリレーションの性質を満たすこと。何故ならば、正規化はリレーショナルモデル上での設計理論なので、リレーションにしか適用できないから。だからNULLを含んではいけないし、繰り返しグループは許容されず、ドメインの設計がしっかりできていないといけない。 2015-03-31 22:23:44 Mikiya Okuno @nippondanji リレーショナルモデル上の設計理論は、対象がリレーションであるから実行できる。ということは、リレーションになれないデータには正規化も適用できない。なので「テーブルを全部正規化せよ」という方針は破綻してしまう。 2015-03-31 22:26:02 Mikiya Okuno @nippondanji テーブルを正規化すべきかの判断は実は至ってシンプル。それはリレーションか否か。あ
Oracle DBA & Developer Days 2014の資料が公開されたようです。
JPOUG Advent Calendar 2014の13日目のエントリです。 だいぶ遅れたプレゼントになりすみません。 ちょっと欲張ってJPOUG Advent Calendar 2014 二回目の登場になります。 1回目はこちら 今回も1nmくらい役に立つプレゼントになればと思ってエントリします。 さて、本記事のタイトルにあるように、 「Oracle DBA & Developer Days 2014 (DDD 2014)」の資料が公開されたようです。 以下サイトから資料がダウンロード出来るようです。 http://eventreg.oracle.com/profile/web/index.cfm?PKWebId=0x14073486e5 役立つ資料が山ほど入手出来るので、 サイトを紹介してこの記事を終わってもいいかなと思いましたが、 人の褌でうんぬんと言われそうなので、 私が担当した
optimizer_dynamic_sampling=11
久々の投稿となります。 今日は、JPOUG Advent Calendar 2014の6日目のエントリです。 1µmくらい役に立つプレゼントになればと思ってます。 前日の第三の柴田ことgonsuke777さんが「Bind Peek を もっと使おうぜ！」という 煽り記事を書いていましたので、 私も呪文のように唱えられるoptimizer_dynamic_sampling=0で有名な 動的統計(動的サンプリング)の12cの今について書こうと思います。 動的統計は12c(または11.2.0.4.0リリース)以前は動的サンプリングという名前でした。 機能を単純に説明すると、オプティマイザ統計(俗に言う統計情報)が 不十分な場合にそれを補完(補填？)するための機能です。 第三の柴田がBind Peekを使おうと言っていますが、 それだって不十分な統計情報のもと使っても何の意味もありません！ なぜな
11月の活動報告
先日、db tech showcaseと北海道データベースDAYでプレゼンを行ったので、例によってSlideShareで公開してある。既にTwitterで呟いたので既にご覧になった方も多いかも知れないが、改めてブログでも紹介しておこうと思う。 あなたが知らないリレーショナルモデル（@db tech showcase） まずはdb tech show caseで使った資料の紹介だ。今回は50分という時間の短さだったので、伝えたいことをギュッと凝縮した内容になっている。この資料で主に伝えたかった内容は次のようなものだ。 リレーショナルモデルとは何か SQLとリレーショナルモデルの関係 リレーショナルモデルを使わないとどうなるか なぜリレーショナルモデルを適用できないか どんなときリレーショナルモデルを適用してはいけないか 4つ目については、ひとつ良い説明の方法を思いついたので、今回の資料にも盛
メモ: 複合主キーを云々いう前に足りなかったこと - 虎塚
先日、データベース設計で、ナチュラルキーの組合せを使った複合主キーと、その代替となるサロゲートキーのどちらを使うか、という話を書きました。 複合主キーを避けるべき理由 - 虎塚 月末までには、改めて考えを整理するつもりでした。しかし、残念ながら、今の自分の知識ではムリそうです。そこで、考えたことを少しずつ出力することにしました。 この問題について考えるべき（だった）こと 前回の記事に足りなかった観点が3つあります。 データベースの論理設計と物理設計を分ける 複数ある要素の一部にだけ言及していると自覚する すべては程度問題である これらを1つずつ考えてみます。 1. 論理設計と物理設計を分ける まず、データベースの論理設計と物理設計を分けて考える必要がありました。非常に、基本的なことですが・・・ 論理設計で、ユニーク制約が必要なキーと、行を一意に特定するキー（候補キー）を特定します。もちろん
「複合キー」と実装用フレームワーク - 設計者の発言
テーブルの主キーの設定に関して「複合キーと代理キーのどちらが適切か」という議論がある。私の立場は明確で、 分析段階では必要に応じて複合キーを用いながらモデリングし、実装段階で環境の事情に応じて代理キーを導入すればよい。もちろん、モデルのとおりに実装することが許されるならば、それがいちばんよい。 というものだ。根拠を説明しよう。 以下のようなデータ要件があるとする。記号ではイメージしにくいという読者には、テーブルＡが「社員」で、Ｃが「趣味」で、ＡＣが「社員の趣味」と想像してもらえばよい。その場合の属性eは、各社員の各趣味に対する「好みの度合い(-2は大嫌い、2は大好き、とか)」くらいと考えてもらえばよい。要は a,b,c,d,e の５つの管理項目が見出され、項目間に b=F(a)、d=F(c)、e=F(a,c) の関数従属性が認められたという例だ。 [Ａ] {a}, b ＋ 100 aaa
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
コーソルDatabaseエンジニアのBlog
コーソル DatabaseエンジニアのBlog へようこそ コーソル DatabaseエンジニアのBlogでは、 コーソル所属のエンジニアがOracle Databaseを中心としたDatabaseに関わる技術情報を発信しています。 コーソルでは、Oracle Databaseをはじめとするデータベース全般に関わるサービス（コンサルティング、設計、構築など）、オラクル製品のプロダクトサポートサービスを提供しています。 また、不定期で無償の技術セミナーを開催しています。 株式会社コーソル - サービス案内 株式会社コーソル - セミナー情報 コーソルでは、Oracle Databaseスペシャリストになりたいエンジニア、 Oracle Database技術を活かして働きたいエンジニアを絶賛募集中です。 コーソルについて知るためには・・・ 株式会社コーソル - 会社情報 人事ブログ - 『コー
目次
米国時間の2013年7月1日、オラクル製データベース管理システムの最新バージョンとなる「Oracle Database 12c」が米国で正式発表となった。 最大の特徴は、クラウドコンピューティング環境の進展を意識して、データベースの「マルチテナント」を実現するための機能を実装したこと。マルチテナントとは、一つのシステム管理環境下に、複数のシステムを同居させる形態のことを言う。バージョン名の最後に付く「c」はクラウドを表している。 ほかにも、データ配置を最適化する機能、セキュリティリスクを低減させる機能、可用性をさらに向上させる機能など、複数の機能を実装・強化した。いずれも、データベースをマルチテナント化した環境、ひいてはクラウドコンピューティング環境の上でデータを安全に運用管理するために有効なものである。 本特集では、Oracle Database 12cで登場する主要機能の概要と実装方法
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Does Your Database Really Use Your Index? - DZone Database
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
外部キー制約に伴うロックの小話
削除フラグのはなし
データベースのバージョニングとアップグレードスクリプトの利用
