データベース('23)
https://gyazo.com/00c307c7079a3e39384bb42c4918efaf
1. イントロダクション
実世界のデータのかたまりを扱っている
データは何らかの目的に沿って集められ、規則(制約)に沿って設計されている 定義
ある目的のための共有性や再利用性を意図して、一定の規則に基づいてコンピュータ上に格納されたデータの集まり
データを管理し、適切に利用するためのソフトウェア・システム
様々な機能を提供する
データモデルを提供する
RDMSのデータの記述や操作を規定した体系
データの整合性の維持
整合性等の制約を記述
スキーマを記述するための言語
インスタンスを操作するための言語
機密保護に関するアクセス制限やトランザクション処理を行うための制御を実施する
効率的なデータアクセスの実現
queryに対して処理コストが最小となるような処理手続きを立案し、問い合わせ処理(query processing)を行う
機密保護
ある1つのアプリケーションから見たデータベースの読み書き等の処理単位
DBMSは複数のトランザクションを整理し、並列処理できるように制御する
同じデータに対する複数のトランザクションはロックなどを用いて整合性を保つ
例えばトランザクションが途中で中断された場合に、データ操作をログとして記録するとともに2時記憶装置への書き込みを制御することで中断したトランザクションの中で行われた書き込みをキャンセルし、整合性のある状態に戻す
DB + DBMS
DBSをさしてデータベースと呼ぶこともある
想定ユーザ
データベース管理者
アプリケーション管理者
一般ユーザ
論理的な意味におけるデータベース内のデータの構造や形式、制約を定義する枠組み
メタデータの管理はデータベース管理システムが行う
スキーマに基づいて格納される実際のデータ
データベース管理システムの標準アーキテクチャ
ANSI/X3/SPARC
物理的なデータの格納や構成を規定したスキーマ
データベースを論理的に規定したスキーマ
データベースに対する個々のユーザやアプリケーションの要求に対応
データベースの利点
管理上の無駄が省け、データの整合性が保てる
開発効率の向上
機密が保持しやすい
同時アクセスへの耐久性
障害から回復できる
実際によく使われるDBMS
RDMSでは対応しづらいケース
ビッグデータなど膨大な量で勝つ複雑な構造を持つデータを高速で処理しなければならない 両方のデータモデルを採用している所も多い
2. 私たちの周りのデータベース
図書検索サイト
検索エンジン
SNS
オンラインショッピング
オンラインバンキング
過去の気象データ
1960年代に国際標準化機構(ISO)によって定義
書誌情報を整理するための構造的なデータフォーマット
異なる図書館などで書誌情報を交換し合うための通信プロトコル
Web検索機能やリンク集
Webページのドキュメントをデータベースのインデックスに格納
ディレクトリ型
センター型
モール型
信頼性やリアルタイム性が求められる
従来の更新処理を中心に考えたデータベースの構成ではなく、履歴型データの検索を主体に考えたデータベースの構成法
勘定系システム
マスタ、トランザクションデータが一元管理で構成
AI機能を取り入れたデータベース
3. データベースの仕組み
客観的な事実を数値、文字、画像、音声などで表したもの
ある特定の目的について、適切な判断を下したり、行動の意思決定をしたりするのに役立つ資料や知識
情報として価値のあるデータ
正確性
整合性
スピード
一元化
共有性
再利用性
利便性
セキュリティ
データの管理法の変遷
手書き→コンピュータ
紙と筆記用具で作成可能
データの並び替えの場合は1から書き直し
コンピュータを利用してデータを作成し、紙のデータとして活用するということが行われるようになった
データは専用のプログラムによってのみ処理することができた
ファイルシステムではデータは単なるファイル
プログラムごとにファイルが存在
重複などで不整合
ファイルシステムの問題点
1. ファイルの所在情報に関すること
ファイル部の物理構造を意識する必要がある
データへのアクセスにファイル場所、何バイト目かをプログラムに記述
データとプログラムの関係は密接
データベースではデータの格納場所はデータベース管理システム側で管理する
2. ファイルの共有に関すること
複数のユーザーが同時実行する場合に不都合が生じる可能性
データベース管理システムを利用してデータの管理をする場合、データベースに格納されたどのデータをどのシステムが利用するかのマッピングを行う
表計算ソフトを使ったデータ管理
表計算ソフトで作成した一覧表は、紙と鉛筆で作る一覧表をコンピュータに置き換えただけに過ぎない
社内の要望が多岐にわたってきたときに、表計算ソフトで対応することは困難になってくる
ファイルの共有に関する問題
データベースの定義
「ある目的のために」
無目的に集めたデータではデータベースとは呼べない
「一定の規則に基づいて」
バラバラな形で蓄積したのでは意味がない
現実社会のデータをコンピュータ上で扱えるように置き換えたもの
概念データモデル: 現実社会の構造をデータ化して記述したもの
実態は物
関連は1対1、1対多、多対多
実体を長方形
関連をひし形
属性を角丸四角形
論理データモデル: 概念モデルをコンピュータに近い形で表現したもの
木構造
網の目のように表す
テーブルとして表現
オブジェクト間の関係
物理データモデル: ハードウェアやDB製品を含む、実装方法を定義したもの
3層スキーマ構造
4. データベースの歴史
1950年代の米軍のデータ専用の情報基地が由来
1957年
分散型ネットワークのきっかけ
分散された膨大なデータを収集・処理する必要性
宇宙開発技術を短期間に向上させる必要性
学術的なデータベースはW.C.Mcgeeの論文(1950s)
階層的に管理し、データの重複を回避、拡張も効率的に行う
保守技術や機密保護の必要性も説いた
階層的にデータの関連を表す方法は階層モデルのデータベースとして発展普及
1950年代はバッチ処理によるコンピュータ利用が主流
マギー氏の論文で提唱された内容は現在のデータベース構造や機能にもそのまま当てはまる
1960s
商用データベースとして利用できるのは国家機関や一部の大手企業
アメリカ国防省が計算機メーカや政府関係者、ユーザの3団体を招集して設立
事務所利用の共通プログラミング言語開発を目的
IDSのアルゴリズムや仕様を組み込み正式な文法とするための作業を1965に開始
現実世界の多くの事象は階層構造を形成しているとの前提を元に階層データモデルのデータベースとして発展
レコードタイプの実現値のこと
レコードタイプ
同一形式のレコードの総称
レコードタイプ間の関係を示したものがスキーマ
現実世界の多くのものは1:nの制約を満たされない
子は親を複数持てない
プログラムがデータに強く依存する
データ構造の変更がプログラムを作り直す必要
データに達するためのパスが複数存在する
階層データモデルとの大きな違い
子レコードは任意数の親レコードを持つことができる
データベースは通常のレコード集合とレコード間のリンクにより明示的に扱ったリンク集合とからなる
モデルの欠点
関係の定義や変更を行うための処理が複雑で、プログラムによってはデータ構造を変更するなどの手間がかかる
CODASYL型
CODASYLがDBTGの発足、COBOL-70の公開
商用ネットワークデータベース管理システムはほとんどこの仕様に準拠
IDSの登場以降、多くのコンピュータメーカやソフトハウスなどによって、独自のデータベース管理システムの開発が進んだ
階層データモデルやネットワークデータモデル
理論的な枠組みに基づくものではなく、現場の要請に応じて様々なデータ構造化の手法が組み込まれてきたもの
設計時に想定した処理は高速
予期しない結合が必要な処理は再設定や処理が複雑
1970年、IBMサンノゼ研究所のコッドがアメリカ計算機学会誌に「データベースにおけるリレーショナルデータモデル」を発表
1971-74に多くの論文
SQLにより簡単に操作が行える
キーを使って表同士に関係をもたせつなげる
https://gyazo.com/6aee00c2455cdf0fa4c2ecea894a02d5
リレーションRが属性A...をもつとき、$ R(A_1,A_2, \cdots, A_n)
リレーショナルデータベースモデルではデータベーススキーマはリレーションスキーマの集まりとして表現される
インスタンスはタプルの集まりにより表現される
論理的な意味でつながっているのであって、それぞれのデータは独立して存在している
リレーショナルデータモデルのデータベース設計はデータ間の構造に規定されない
大きな期待が寄せられたがこのモデルはすぐには実用化されなかった
すでに階層データモデルやネットワークデータモデルが実用化され、構築中だった
数学的に高度に抽象化されたものなので、実装するにはソフトウェア技術上の困難があり、当時のハードウェアはパワー不足だった
1970年代はリレーショナルデータベース管理システムの商品化を目指した施策の時代
IBMはSystem Rが開発されたが製品レベルには至らなかった
Oracle社がIBMに先駆けてリレーショナルデータベース管理システムっ製品を世の中に出した 汎用コンピュータ用のリレーショナルデータベース管理システムが販売された
80年代後半になるとネットワークが構築、クライアント/サーバ型
1990年代
PC向けの商品やオープンソース
Illustra
リレーショナルデータベース管理システムの具体的な製品
より複雑な情報を管理することに適したデータベース
文書データ、イメージ、3次元データ、地図データなど
誰でも簡単にプログラムを作成できる環境を提供する
オブジェクトは現実世界の事象を表現したもの
元になるデータ(プロパティ)を管理するとともに、それをもとにそれを表現するための手続きも包含しなければならない
ファイルやテーブルがデータだけの集まりであるのに対して、オブジェクトにはそのデータを変更したり取り出したりする手続き(メソッド)も含んでいる オブジェクト指向プログラミングにおいては、オブジェクト中心に考え、データはあくまでもオブジェクトを形成する一つの要素
その他の特徴
タプル、集合、マルチ集合、リスト、配列
これらの構成値を自由に入れ子状に用いた複合値として与えることができる 分割耐性を持つスケールアウト可能なデータベースがNoSQL
大まかな分類
列指向データ型
Bigtabl
5. データベースの動作環境
1960後半-1970初頭 PDPという’低価格コンピュータが登場 1973年にカーネル部分がC言語で書き直されたことから高い移植性を持つOSとなった
徐々にPCが増え始め、パーソナルなデータベースソフトが登場
1981 IBM PC
複数の端末から同じデータベースにアクセスして処理
Web-データベース連携システム
1ユーザー1プロセスで負荷が高い
Webサーバ、アプリケーションサーバ、データベースサーバの3層にタスクを分散
Webサーバはクライアントとの通信を専門
それ以外の処理をWebアプリケーションサーバが担当
データベースとアプリケーションソフトをネットワーク上に独立させることで分散化
クラウドコンピューティング
XMLスキーマ自体をデータベース定義とし、XMLデータそのものをデータベースとする 情報公開には優れていたものの、データの交換目的には向いていなかった
非常に柔軟に文書を表現できたが、文法が複雑すぎて一般には普及しなかった
SGMLをもとに作られたのがXML
タグにより階層構造が示されていることから、外部に対応するスキーマを保つ必要がない
XMLデータベースとリレーショナルデータベースは互いに完全に共存することは困難
XSLを用いてスタイルの制御やXML以外の形式に変換することも、パーサやDOMにより構造を解析してオブジェクト化することも可能
リレーショナルデータベース向けのテーブルとして情報提供
オブジェクト指向データーベースと関連づけたりもできる
オープンソースデータベース
LAMP(Linux Apache MySQL PHP/Perl/Python) LAPP(Linux Apache PostgreSQL PHP/Perl/Python) ネットワーク型データベースに対応するNDLが1987にISOとJISを取得 SQL→リレーショナル・データベース管理システム→リレーショナルデータベース
6. データベースにおける概念設計
データモデル
実世界の情報構造を抽象化・記号化して表現
データベース管理システムで利用できるように、設計した概念データモデルを再構成したもの
各種データベース管理システム特有のデータ構造や格納方式を前提として論理データモデルをより詳細に定義したデータモデル
テーブル定義表やテーブル容量、ページサイズ、インデックスなどを定義
データベース設計
対象となる実世界の情報を記号化して概念データモデルを作成
1976 チェン
学生が番号、氏名、住所、所属などをもつ
ある関連型における実体と実体の間のインスタンスの数の対応関係
1対1、1対多、多対多
ある関連型とそれに関わる実体型があった際に、その関連に関係しない実体が存在して良いか否かに関する制約
1, Nの代わりに(最小値、最大値)と記述する
別の実体型が存在していないと存在できない実体型
単独で存在できる実体型
弱実体型に一意の識別能力をを与える実体型
所有実体型の主キーと対になって初めてその弱実体型を位置位に識別できる属性
所有実体型と弱実態型の間の関連型
3項以上の実体間の関係性
再履修を認める場合「履修」は「年度学期」を加えた3項関連型を用いる
概念データモデルをそのままデータベース管理システムに適用できるとは限らない
概念データベースを基に、データベース管理システムで利用可能な論理データモデルへと変換を行う
データベース構築はデータベース管理システムによって半ば自動的になされるのて通常ユーザは考慮しない
社員と営業部員・製造部員
実体-関連図を記述するための表記法
実体型を四角形、関連を矢印、多重度は◯と●
オブジェクト指向によって分析・設計されたモデルを表現するために用いられる
実体型を四角形、関連およびた重度を実線と数値で表現
3項関連は白抜きのひし形
7. リレーショナルデータモデル
実世界の種々の情報をテーブル(表)とみなして取り扱う 表における列を特性するためのラベル
リレーションのそれぞれの属性の取りうる範囲
プログラミングにおける型のようなもの
属性Aのドメインをdom(A)
リレーションの定義
属性$ A_1, A_2, \cdots, A_nに対してドメインを$ D_1, D_2, \cdots, D_nとしたとき、その直積$ D \times D_2 \times \cdots \times D_nの有限部分集合 直積とは、各集合から1つずつ取り出した要素すべてを組みにした集合
集合に属するそれぞれの要素
集合の要素なので、全く同じタプルが複数行存在することはない
空の値
タプルを位置位に識別できる属性
複数の属性の組み合わせでも良い
候補キーの中で属性が空値を取らず、かつデータ管理上最も適切である1つ
リレーション名と属性の集合、各種制約を合わせたもの
e.g. 科目(科目番号, 科目名, 単位数)
属性のドメインもリレーションスキーマの一部
e.g. 科目(科目番号: $ D_1, 科目名:$ D_2, 単位数: $ D_3)
その他の書き方: $ R(A,B,C)を属性型だけに着目して$ \{A,B,C\}と記すこともある
リレーションが含むタプルの集合
リレーションはデータの追加や更新、そして削除によってインスタンスが変化していく
実体-関連モデルをリレーショナルデータモデルへ変換
実体型からの変換
弱実体型ではない通常実体型
実体型はそれと同じリレーション名と属性の集合を持つリレーションに変換できる
通常実体型の主キーは変換後のリレーションの主キーとなる
弱実体型
実体型をオーナーとする弱実体型Eに対しては、Eのすべての属性を変換するリレーションの属性とする
さらにその弱実体型に対応するリレーションの主キーをリレーションの属性に加え、これと実体型の部分キーの組み合わせをリレーションのキーとする
関連型からの変換
1対1対応の場合
独立したリレーションを作らずに、実体型から作成したリレーションのいずれかに要素を組み入れて変換するのが一般的
e.g.
教員(教員番号,教員名,顧問担当)として顧問担当を部活の外部キーとする
部活(部活名,顧問教員番号)
1対N対応の場合
N側の実体型の主キーに対して1側の実体型の主キーを組み合わせてリレーションとして設計する
その関連型に属性が存在する場合はその属性もリレーションに加える
e.g.
科目(科目番号,科目名,単位数,担当教員番号)
教員(教員番号,教員名)
N対M対応の場合
関連型をリレーションに変換する
N側の実体型の主キーとM側の実体型の主キーを組み合わせてそのリレーションの主キーとするのが一般的
その関連型に属性がある場合はリレーションにその属性を追加する
e.g. 履修(科目番号、学生番号、年度学期、成績)
ISA関連からの変換
実体ベースアプローチ
E-Rモデルの中で階層化されている各実体型に対してリレーションへの変換を試みる方法
下の階層の実体型には主キーが存在しないことになるが、親階層の実体型の主キーを割り当てる
e.g.
社員(社員番号, 氏名, 住所)
営業部員(社員番号, 売上)
製造部員(社員番号, 専門分野)
階層全体に対する検索をしたいときに探しやすい
特定の市に住んでいる社員を探すなど
下位階層の事項に対する問い合わせは複数のリレーションに問い合わせしなければならない
オブジェクト指向アプローチ
クラスをリレーション、オブジェクトをそのクラスに所属するタプルと捉える
e.g.
社員(社員番号, 氏名, 住所)
営業部員(社員番号,氏名,住所,売り上げ)
製造部員(社員番号,氏名,住所,専門分野)
最下層クラスに関する問い合わせする際には1つのリレーションを調べることで対応できる
最上位クラスに関する問い合わせを行う場合は複数のリレーションを調べなければならない
単一リレーションアプローチ
ISA関連の上位・下位階層のすべての実体を単一のリレーションに含めて表現する方法
意味をなさない属性が含まれることも生じる
NULL, ⊥
本来リレーションは属性がナルであることを許さない
e.g.
社員(社員番号,氏名,住所,売り上げ、専門分野)
https://gyazo.com/593e6c3f920b04565b9288fb636578f0
8. データ操作
データベースに求めるユーザ側の要求
リレーショナルデータベースに質問(問い合わせ、クエリ)し、求める結果を得る リレーショナルデータベースのデータを更新(update)する
集合論を基に具体的な計算手順を用いて問い合わせを表現する演算体系
問い合わせの結果に含まれるデータがどのような条件を満たすべきかを論理式を用いて記述する宣言的なデータ操作体系
閉じている
リレーションを対象としたデータ操作結果が再びリレーションになる
表現力に差はなく、等価である
リレーショナル代数で表現できるデータ操作は必ずリレーショナル論理でも表現でき、逆もまた成り立つ
あるリレー書アンルデータベース操作体系やデータベース言語の表現力が、リレーショナル代数やリレーショナル論理以上であるとき
リレーショナル代数の主な演算
一般的な集合演算: 和集合演算、差集合演算、共通集合演算、直積集合演算
それ以外: 選択演算、射影演算、結合演算、商演算
和集合演算、差集合演算、直積集合演算、選択演算、射影演算を基本的な代数演算とみなす考え方も根強い
共通集合演算は差集合演算を使って表現できる
結合演算は直積演算と選択演算の組み合わせ
商演算は直積演算と射影演算と差演算の組み合わせで表現できる
和集合演算
2つのリレーション$ Rと$ Sの和集合を求める二項演算
結果のリレーションは和(union)と呼ばれ、$ R \cup Sで表現する
定義: $ R \cup S = \{ t| t \in R \lor t \in S\}
タプルtがリレーションRの要素であるかまたはリレーションSの要素であるようなタプルtの集合
差集合演算
定義: $ R-s=\{t|t \in R \land \neg (t\in S)\}
タプルtがリレーションRの要素であり、かつリレーションSの要素でないようなタプルtの集合
共通集合演算
定義: $ R \cap S = \{ t|t\in R \land t \in S \}
タプルtがリレーションRの要素でありかつリレーションSの要素でもあるタプルtの集合
共通は以下のように差の演算により表現できる
$ R \cap S = R - (R -S)
https://gyazo.com/0c5063098971b97d0170deec72bd71d8
集合演算においてリレーションRとリレーションSが同じ属性名及びドメインを持たねばならない
仮に異なる属性を持つとすると、
和集合は異なるドメインを持つタプルが混在してしまうのでリレーションではなくなってしまう
差と共通の集合演算においても$ R-Sは常にR、$ R \cap Sは常に空集合となる
リレーションRとリレーションSが与えられたとき、Rの要素である任意のタプルtとSの要素である任意のタプルuを連結したタプルt*uを要素とするリレーションを、RとSの直積と呼び、$ R \times Sと表記する
すなわち$ R \times S = \{ t*u | t \in R \land u \in S \}
であり、$ t = (a_1, a_2, \cdots, a_n)かつ、$ u = (b_1, b_2, \cdots, b_m)のとき
$ t*u = (a_1, a_2, \cdots, a_n, b_1, b_2, \cdots, b_m)
重複する属性名はR.CやT.Cのいように属性名の前にリレーション名をつける
リレーションRに含まれるタプル1つ1つに対して、指定した条件Cが真となるタプルだけを残し、ほかを削除する単項演算
$ \sigma_C(R)
選択条件Cに入るものとして
属性$ A_iと定数$ cの比較演算子$ \theta(=,<, >,≤,≥, ≠のいずれかに該当)による比較条件$ A_i\theta_c
属性$ A_iと属性$ A_jの比較演算子$ \thetaによる比較条件$ A_i\theta A_j
論理和、論理積、否定等を用いたこれらの組み合わせなど
選択演算子$ \sigmaはselectionの頭文字sに相当
リレーションRが持つ属性の中で指定した属性だけを残してほかを削除する単項演算
Rの属性集合$ \{ A_1, A_2, \cdots, A_n \}の部分集合を$ Lとすると
$ \pi_L (R)
$ \piはprojectionの頭文字pに相当する
射影の演算結果もリレーションであり全く同じタプルを複数持つことはできあにので、その場合は削除される
https://gyazo.com/e5ea562633a179aa8ce61a7546d66358
「商品a, b, cをすべて扱っているお店の一覧を求める」という問い合わせは商演算$ R \div S
https://gyazo.com/20c409dd97567a1a35ae4f08267f571f
一般的には2つのリレーションR,Sに対し以下のように定義
$ R \div S = \pi_{A_1,A_2, \cdots,A_{m-1}}(R)-\pi_{A_1,A_2,\cdots,A_{m-1}}((\pi_{A_1,A_2,\cdots,A_{m-1}}(R)\times S)-R)
商と名付けている理由は、2つのリレーションRとSに対して$ (R \times S) \div S = Rが成り立つから
https://gyazo.com/884ddfc7f56f87597ac52b955e76b788
リレーションRとリレーションSの共通部分に着目し、その各属性値が等しいタプルを連結する演算
2つのリレーションに対して自然結合$ R \Join Sは直積、選択、射影を組み合わせて表現
https://gyazo.com/f1fad09957a293489eaa0a03c55c48c4
https://gyazo.com/baaf871f9a6cc6d40ca6723831948724
共通属性の値が同じであるタプルが見つからない場合もあり、その場合は演算結果には含まれない
連結するタプルを選ぶ条件を一般の条件に拡張させた結合
$ \thetaはタプルを選ぶ条件を定義する際に用いる比較演算子を表す
統合条件$ =を条件として用いたθ結合
θ結合は等号以外の条件を用いるものとして区別することもある
https://gyazo.com/06aa4a6297fa40f30fe24f2b8b812431
$ t*uはタプルtとuを連結したタプル、$ P_F(t,u)はtとuが結合条件Fを満たすときに真となる術後
θ結合演算は直積と選択の組み合わせとして表現できる
https://gyazo.com/da1e52f7d9fe01d6a9833e29740be429
https://gyazo.com/b7320e43aa02d18be011a42a334401dd
自然結合ではダングリングタプルが生じる場合がある
外部結合ではダングリングタプルも結果に加えられる
https://gyazo.com/912d14f965592a5968058d9adc7aaf89
ダングリングタプルが生じた場合にはnull記号(⊥)を用いたタプルがリレーションに加えられる
リレーショナル代数における本来の定義に反すること
SQLではnull値を取る形で実装されている
https://gyazo.com/ad9e4fbc769139a79f21f6e5e6dfa0f7
外部結合においてもθ結合のようにタプルを選ぶ条件を付与する事が可能
https://gyazo.com/d03e897f524dc295aeae36f7ec43ded5
左側の被演算子のリレーションRにおけるダングリングタプルのみ演算結果に残し、Sにおけるダングリングタプルは残さない
左の逆
左外部結合と右外部結合に対してという意味で上記の自然外部結合を全外部結合と呼ぶこともある https://gyazo.com/0dc5fab74fd9b4883e77231717649870