組織情報論
第2回 データベース 1
データベースの方式とDBMS
1
講師 佐枝三郎
https://sites.google.com/site/jiusaedasoshikiron2017/
データベースとは
社会的なシステムで取り扱うデータ
• 社会で使用されている多様な情報システムは、様々な大
規模データが基礎になっている
– 公共的なシステム
• 電気・ガス・水道などのインフラストラクチャ管理、交通機関や交通信
号の制御、飛行場の航空機発着制御．．．
– 企業や経済活動のシステム
• 銀行の預金管理・決済システム、航空機の発券・予約管理、企業の
各種業務システム．．．
– 個人の消費活動などのためのシステム
• Amazonの在庫・注文管理、Suicaの残高管理、YouTubeのコメント・タ
グの管理、その他いろいろ
• このようなシステムで扱うデータは大規模であり、また、こ
のようなデータは効率的・効果的に処理する必要がある
3
大規模データを実際に扱うためには
• プログラム（システム）が、大規模データの必要な部分を、高速に
取り出したい
• 重要で他人に見せたくないデータを、取得・追加・修正ができる人
間（システム）を制限したい
• 同時に複数の人間（システム）が、ひとつのデータを書き換えるこ
とを防ぎたい
• 万一、データを保存したメディア（ディスクなど）が壊れたり、停電等
でシステムが止まっても、重要なデータが消えるのを防ぎたい
• 動いているシステムを止めずに、大規模データのバックアップ(コ
ピーあるいは写し）を取りたい
• これらの要求を満足させるために生
まれたのがデータベース
4
データベースとは － 厳密な概念
• データベース（database）は、「複数の利用目
的のための共有を考慮し、組織的かつ永続的
に格納されたデータの体系」である
• 複数の利用目的のための共有
– AmazonのWebサイトで、書籍を購入した購入データと購入者の
データは、売上や配送などの直接の販売活動に利用するだけ
でなく、消費者の購買行動の分析や、おすすめ商品の提示など、
マーケティングにも利用する
• 組織的
– データベースに格納されたデータは一定のルールによって作成
される
• 永続的
– データベースに格納されたデータは、明示的に消さない限りは
存在し続ける
5
データベースとは － 図書館との比較
• データベースとは、そこに行けばすべての情報が得られるよう
な基地のイメージ。具体的には図書館をイメージするとよい。
– 図書館は多くの分野の膨大な資料と書籍を蓄積し、たくさんの利用者
が異なった調査目的で来館する。
– 図書館にある膨大な量の資料や書籍は、整理・分類されていなければ、
利用者はすべての資料を調べる必要があり、収集された資料や書籍
は無意味なものとなる。
– 実際の図書館は、職員（司書）が資料や書籍の分類整理を行い、新刊
の購入、書籍の補修を行うため、利用者が調査をできる。
• データベースとは、図書館と同様に「様々な目的を考慮して整
理整頓されたデータの集まり」である。
– 図書館司書にあたるのが、データベース管理システム（DBMS）というソ
フトウェアであり、一般利用者や企業のシステムが必要なデータを参照
や蓄積ができる。
データベースシステム
• 大規模データを取り扱う要求を満足させるために、生まれた
のがデータベースシステム（database system, DBS）である
• 各種の固有の目的を持ったシステムが利用したいデータ群を、
有機的に統合して蓄積管理し、複数システムで効率的共有と、
高度な利用を行うために存在する
• 現在、企業や公共機関、各種Webサイトなどで使用されてい
るシステムの、主要な構成要素あるいは部品として利用され
ている
• データベースは整理されたデータ群（倉庫のようなも
の）であり、データを格納、整理、検索するために必要
なソフトウェアは、
• 「データベース管理システム」 という
7
データベース管理システムとは
8
データベース管理システム
• データベース管理システム（database management
system, DBMS）
– データを管理し利用に供するためのソフトウェアシステム
• データベースシステム（database system）
– データベース＋データベース管理システム
データベース管理システム
（DBMS)
データベース（DB)
デ ータ ベ ース シ ス テ ム （ D B S)
9
データベース管理システムの特徴１
• プログラムとの相互独立性
– データベース管理システムの仕様変更があっても、利用す
るプログラムの修正はほとんど必要なく、プログラムの修正
はデータベースに影響を与えない。
• 効率のよいデータアクセス機構
– 最新のソフトウェア技術を応用して、高速に大量のデータを
検索・更新できる
• データの一元管理と整合性維持
– データベース管理システムが情報を一元管理するため、
データには重複がない。同時にデータ間の整合性が確保さ
れている
データベース管理システムの特徴2
• 複数利用者の同時処理
– データベースには同時に複数のユーザがアクセスできる。
同時の書き込みや削除なども データベース管理システム
が管理し整合を取るため、データの矛盾が発生しない。
• データの機密性
– データベースへのアクセス権限がないユーザは、データ
ベース管理システム によってアクセスが拒否される。
• データの障害回復
– データベースに何らかの障害が発生した場合、データベー
ス管理システムには複数の回復するための手段が用意さ
れ迅速な回復ができる。
11
ファイルシステムとの比較
• 従来型のファイルシステムとの比較で、データ
ベース管理システムの特徴を説明する
• ファイルシステムは、ディスク上にある複数の
データが集まったデータの単位
– WORD 、EXCEL、メモ帳のファイル
– 文字や数字、プログラムテキストなどのデータが集
まっている
– 従来の大型コンピュータでは、磁気テープにファイル
を格納することも多かった
・ディスク装置
・磁気テープ
12
プログラムとの相互独立性
• ファイルにデータを格納する場合は、プログラムを書く人は、
以下のことが分かっていなければならない
– 「使うデータは、どのファイルに置かれているか、ファイルの名前
は何というか」
– 「このデータは、ファイルの中でどの位置にあるか、何文字目か
ら何文字をデータとして取り扱う必要があるか、データの形式は
どうなっているか」
• ファイルの場合は、データとプログラムの依存関係が非常
に強くなる
– データについての詳細情報や意味をプログラムに記述しなけれ
ばならなくなる
– 依存関係が強いとプログラムにとっても、データベースにとって
も大きな制約が生まれる
– 別の理由で、データを格納したファイルの置き場（PCではフォル
ダー）を変えたり、ファイル形式が変えるとプログラムの中に記
述されたデータの詳細情報も大幅に変更しなければならない
13
ファイルとデータベースの違い
0 1 0 1 荒 井 次 郎
0 1 0 2 伊 豆 三 太 郎
0 1 0 3 和 泉 俊 樹
0 1 0 5 加 藤 一 郎
0 2 0 1 木 下 俊 彦
0 2 0 5 古 河 数 之 進
0 2 3 1 酒 井 正 春
0 3 0 1 田 中 三 造
0 3 2 2 田 所 義 之
0 3 4 5 土 田 幸 宗
1 2 0 1 和 田 勝 男
ファイル上のデータを解釈して、意味のあるデータを作りだす
・1番目の記号から4個の記号は、数字で学生の番号を表す
・5番目の記号から6個の記号は、文字で学生の姓名を表す
データベースでは、「番号」、「姓名」と
いうデータの名前のみで参照でき、
細かい位置などは知る必要がない
データベース
データアクセスの効率性
• データベース管理システムは、高速に検索できるようデー
タのインデックスを作るなどの技術を用いて、大規模デー
タの中から必要な部分を高速に取り出すことができる
– 一般のファイルにデータを格納する場合、データ量が1000倍に
なれば、読み込む時間も1000倍かかる
– 高速に読み込むためには、二分探索のようなアルゴリズムを
使ってデータの整理をし、また読み込むためにも工夫をしなけ
ればならない
– これらのアルゴリズムを、たくさんの使うプログラムで、それぞ
れ作るのは非常に負荷がかかる
• データベース管理システムは、こうようなアルゴリズムを実
装しているので、使用プログラムは、高速化の処理をデー
タベース管理システムに委任できる
• データの検索を、データ操作言語（後述）で行う場合、冗長
な処理を記述しても、 「問い合わせの最適化」を行う機能
をデータベース管理システムが持っている
15
データの一元管理と整合性維持
• データベースに格納されたデータは、企業の場合、仕事に
必要な大事な資源である。意図的な不正データの入力、
誤ったデータ入力を排除し、データベースの内容は、常に
整合性のあるものである必要がある
– 顧客データに存在しない顧客番号の売上データがあってはい
けない（参照性制約）
– 銀行口座の預金残高がマイナスになってはいけない
• ファイルはプログラムが直接取り扱うので、このような整合
性をチェックすることは、すべてプログラムが行う必要があ
る。
– システム規模が大きくなると、この整合性チェックをそれぞれの
プログラムで行うことは非常に困難になる
– データベース管理システムは、管理システム側で、入力された
データの整合性をチェックし、問題があれば入力を受け付けな
い機能がある。
– 当然、何が整合性のあるデータで、何が整合性が
ないかは、人間が定義をする必要がある
16
複数利用者の同時処理
• ひとつのファイルにあるデータを複数ユーザが、同時に利
用する場合、データの書き込みと読み出しのタイミングが
問題となる
– 交通機関（飛行機、新幹線など）の座席予約システムで、ある
座席の空き情報を、二つのプログラムが同時に読み込んだ場
合
– 銀行の預金口座の残高情報を二つのプログラムが読みこみ、
それぞれが別の金額を引き落とした場合
• こうした場合に備え、ファイルのデータを読み込み際に、プ
ログラムがファイルを他人が使用できないようにする必要
がある。（これをロック処理あるいは排他処理という）
– ファイルの場合は、データを使用するすべてのプログラムが、
この「読みこむ前に、あらかじめファイルにロックする」ことが必
要となる
– この処理をすべてのプログラムに確実に入れることは膨大な
作業であり、データベース側でロック処理を行った方が制御が
簡単である
17
データの機密性
• 特定データが複数のユーザによって使用される場合（共
有）、会社の業務によっては個々のユーザがどのデータを
見られるか、あるいは直せるかなどの権限を決めなけれ
ばならない場合が多い
• 「従業員の人事情報」がファイルに格納されている。通常
次のような権限規定が想定される。
– 人事部の部員は、全社従業員の人事データを読むことができ、
業務で許された範囲で書き込みができる
– 部長以上は、自分の部員に関するすべての人事データを見る
ことができるが、書き込みは人事評価データ以外は許されない
– 従業員は人事評価データ以外の自分の人事データを読むこと
ができるが、書き込みは許されない
• こうした機能はファイルでは実現が難しく、データベース管
理システムにおいては、データの構成とユーザの構成の
組み合せで、様々な操作の権限を定義することができる
データの障害回復
• コンピュータシステムは、サーバー、パソコンに限らず、データを読
み書きしている最中に様々事故や障害が起こる可能性を持っている
– 大災害や停電による電気の供給停止
– コンピュータのCPUなどの中核部品の故障によるシステムダウン
– ディスク装置の故障
– 実行プログラムのエラーによるプログラム中断
• プログラムが上記の事故・障害で稼働不可になった場合でも、業務
のデータは消失させることはできない
– 企業のシステムが停電によるシステムダウンで、顧客に対する売上と
請求データがなくなり、誰に何をどれだけ売ったか、いくらの金額を回
収するべきかが分からなくなれば、その企業はつぶれてしまう
– 交通機関、電気・ガスなどのインフラストラクチャのシステムは、金銭問
題もあるが、障害によるデータの消失が人命にかかわることもあるかも
しれない
• データベース管理システムは、障害発生に備え、データの二重化、
バックアップの取得、障害回復後のデータ再現などの機能を持って
いる
19
データベースシステムの特徴のまとめ
• データベースシステムは、データを体系的に組織化し、
データベースとして、各種のシステム（プログラム）に提
供する
• その特徴的なメリットは
– データをシステム（プログラム）から独立させることによって、
ひとつのデータを様々な目的で利用することができる
– データを統合し一元管理することで、個々のシステムが同じ
データを持ち、無用な重複や不整合が生じることがなくなる
• ファイルにあるコピーして、複数のシステムが利用していると、デー
タの整合性や一貫性がなくなり、データ（例えば顧客など）の追加や
削除をそれぞれのファイルに行って、最新の状態に維持するのが
難しい
• データの意味（項目名やデータの範囲と説明）、データ相互の関連
を把握することができる
– データの操作に関連する高度な処理技術を専門的に持ち、
個々のシステムはその処理を行わないでよいようになる
– データの表現法やその管理方法を標準化しやすくなる
• データの形式、データ長、コード体系など
20
データモデルとその種類
21
データベースシステムとデータモデル
• データベースは、管理するデータベース管理システム
の設計コンセプト（考え方）によって、データの格納構
造や、データの検索と更新の手法が異なる。
• この設計コンセプトを、「データモデル（data model）」と
いう
– データモデルを用いることで、データがディスク上に具体
的にどう格納されているか、どう取り出せばよいかを考え
ることなく、データを読み込むことができる
• 主要なデータモデル
– 階層型データモデル
– ネットワーク型(網型）データモデル
– リレーショナルデータモデル（関係データモデル）
階層型データモデル
• 階層型データモデルは、データを階
層型に格納・整理する仕組みである
• このモデルでは、データはツリー構
造で表現し、ひとつのデータは他の
複数のデータに対して、親子の関係
を持ち、データを読み込むルートは
一通りしかない
• データは常に親子（1対多）の関係と
は限らず、「多対1」の場合や「多対
多」の場合もあり、このデータモデル
で表現すると、データの冗長が発生
しやすくなる
• 階層型データモデルでは、プログラ
ムを作成する時、あらかじめ階層構
造を理解しておく必要がある
• 階層構造に変更があった場合には、
それに合わせたプログラムの改変も
必要になる
• 階層型データベースは、この方式で
ある
データの構造
23
ネットワーク型データモデル
• ネットワーク型データモデルは、
データを網上に格納・整理する仕
組みである
• それぞれのデータ単位が繋がっ
ているため、ネットワーク型と呼
ばれる
• ネットワーク型データモデルでは、
複数の親データへのアクセスが
可能になり、階層型で問題となっ
ていた冗長性を排除する仕組み
になっている
• ネットワーク型モデルでも、階層
型データモデルと同様に、データ
構造を理解してプログラム開発
をする必要がある
• ネットワーク型データベースは、
この方式である データの構造
24
リレーショナルデータモデル
• データベースを「表（リレー
ション、relation）」の集まりと
して表現する
• データベースに対する操作
は、この「表」に対する操作と
して実現する
– 表にデータを追加する
– 表からデータを削除する
– 表からデータを検索するなど
• 「データの永続性」を実現す
るため、「表」は何らかの形で
ファイルに保存されるが、そ
れはデータベース管理システ
ムが行うので、システム（プロ
グラム）は気にする必要がな
い
データの構造
学生テーブル
学籍番号 氏名 所属学部 所属サークル
BG2014-001 相沢一郎 001 110 BG2014-002 今田良子 001 100 BG2014-003 上村真一 003 100 BG2014-004 榎本茂 001 120 BG2014-005 太田かおる 002 130
学部テーブル
学部コード 学部名 定員
001 経営情報学部 200
002 薬学部 100
003 福祉学部 200
サークルテーブル
サークルコード サークル名 部員数
100 なし －
110 野球部 60
120 サッカー部 50
130 書道部 40
25
リレーショナルデータベース
• リレーショナルモデルの概念は、1970年、E.F.Coddが提唱し、現在
利用されている多くのデータベースシステムは、このリレーショナ
ルモデルを基にしている。
• リレーショナルデータベースの特徴は以下の通り。
– データ構造は 2次元の表(テーブル)によって表現、EXCELの表のイ
メージでデータを蓄積。
– 複数の表データを関連付けることで、巨大なデータベースの中に取り
込める
– 現在利用されているコンピュータサーバ、PCで動作するデータベース
の大部分はリレーショナル型である。
– パソコンで利用できるデータベース管理システムは、Microsoft
Access、オープンソフトウェアでは、MySQLなどが多く利用されている
– リレーショナル型データベースに対応する処理言語SQLが早くから成
立し標準化され、ISOの国際規格もされている。
ISO/IEC 9075:2008、『Database Language SQL』
データモデルの基本概念
27
スキーマとインスタンス
• スキーマ（schema）
– 同じ種類のデータをまとめて抽象的に表現したもの
– データの構造、形式、データ間の関連、データ相互の関係から生じる
整合性制約なども表現する
– 「データの構造を記述したデータ」の意味で、「メタデータ（metadata）」
ということもある
– EXCELの表の場合は、表にどのような列があるか、それぞれの列はど
のような種類のデータであるかを記述したもの
– EXCELの表の一行目に、各列の項目名と単位などが書かれているイ
メージ
• インスタンス（instance）
– 定義されたスキーマに従って、データベースに格納された実際の
データ
– EXCELの表の場合は、2行目以降の複数行の実際のデータ
– データベースのデータを利用することは、データベースのインスタンス
に対して、データの挿入・更新・削除などを行うことになる
– データベースのスキーマは、データベースの設計や理解に用いる
28
スキーマとインスタンス
学生テーブル
学籍番号 氏名 所属学部 所属サークル
BG2016-001 相沢一郎 001 110
BG2016-002 今田良子 001 100
BG2016-003 上村真一 003 100
BG2016-004 榎本茂 001 120
BG2016-005 太田かおる 002 130
学部テーブル
学部コード 学部名 定員
001 経営情報学部 200
002 薬学部 100
003 福祉学部 200
サークルテーブル
サークルコード サークル名 部員数
100 なし －
110 野球部 60
120 サッカー部 50
130 書道部 40
スキーマ
29
インスタンス
スキーマ
インスタンス
スキーマ
インスタンス
３層スキーマの概念
• データベースシステムはデータを抽象化し、論理的レベル
でデータ記述とデータ操作を行うための枠組みを提供する
– データとは、取り扱う対象、すなわち登場人物、品物、仕事の
内容などを表現している
• 抽象化の三つのレベル
– 内部スキーマ（内部レベル）
• 物理的なデータの格納のレベル
– 概念スキーマ（概念レベル）
• データベース全体を論理的に記述したレベル
– 外部スキーマ（外部レベル）
• データベースを利用する、様々なアプリケーションシステム毎の、
データベースに対する見方レベル（「サブスキーマ（subschema）」
• 3層に分けたデータモデルは、1978年に、ANSI-SPARC（米
国規格協会標準化計画委員会）が提唱したことで、
「ANSI/SPARCモデル」と呼ばれることが多い
ANSI/SPARCの3層モデル
内部スキーマ
概念スキーマ
外部スキーマ(b)
外部スキーマ(a) ・・・ 外部スキーマ(n)
AP(1) AP(1) AP(1) AP(1) AP(1) AP(1)
アプリケーションプログラムのレベル
外部レベル
概念レベル
内部レベル
31
データ独立性
• データベースシステムのデータが、利用するアプリ
ケーションプログラムに依存しないで構成されている
こと
• 「データ独立性（data independence）」
• それによって、以下のメリットが生まれる
– データとアプリケーションプログラムの依存度が少なくな
ると、それぞれの作り方や運用の仕方が柔軟になる
– データベースのデータ形式や格納方式を変更した場合で
も、データを利用している多数のアプリケーションプログラ
ムを、変更に対応して修正する必要がなくなる
– データを格納する機器や、ネットワーク、利用ソフトウェア
を常に最新で高性能なものを利用して効率化できる
32
3層モデルとデータ独立性
内部スキーマ
概念スキーマ
外部スキーマ(b)
外部スキーマ(a)
AP(1) AP(2) AP(3) AP(4)
アプリケーションプログラムのレベル
外部レベル
概念レベル
内部レベル
論理的
データ独立性
物理的
データ独立性
33
論理的データ独立性
• 外部レベルと概念レベルの間の独立性
– 概念レベルでのスキーマに変更しても、外部レベルに
変更がなければ、アプリケーションプログラムへは影響
がなく、プログラムの修正は必要ない
• 例えば、既存の概念に新しい概念を追加しても、既存の概念
を利用しているプログラムはそのまま利用できる
– 概念スキーマの一部を取り出し、別の外部スキーマを
作成できる
• 企業に関係する人間を、給料の支払い対象と考えて整理す
るスキーマ
• 同じ人間を、企業の社内システムの利用者として整理したス
キーマ
物理的データ独立性
• 概念レベルと内部レベルの間の独立性
• 「データが実際にどのファイルに、いかなる形式
で格納されているか」は、データベースの抽象的
な構造を定義した概念スキーマと関係がなく、依
存性がない
• 物理レベルでのデータの格納形式、ファイル編成
やインデックス（索引）の作り方を変更し、高速化
を行っても、アプリケーションプログラムは変更す
る必要がない
– アプリケーションプログラムにおけるデータの操作方
法（検索、更新など）は、概念スキーマに基づいている
35
データベース管理システムの機能
36
データベース管理システムの構造
データ操作言語処理機能
システムカタログ
制御用情報
・同時実行処理
・障害回復処理
データ管理機能
ファイル管理機能
データ定義言語処理機能
データベース
データベース
アプリケーション スキーマ
プログラム
一般利用者
プログラマ データベース
管理者
37
データベース管理システムの機能
• データ定義言語処理機能
– データ定義言語（DDL）で記述された処理を行う
• データ操作言語処理機能
– データ操作言語（DML）で記述された処理を行う
• システムカタログ（system catalog）
– スキーマ情報（メタデータ）を格納する
– 「データ辞書（data dictionary）」ともいう
• データ管理機能
– 実際のデータベースアクセス処理を司る
• ファイル管理機能
– データベースを格納するファイルにアクセスする
データベースシステムの利用者
• データベース管理者（database administrator, DBA）
– スキーマの定義や変更、チューニング、アクセス権の設
定、バックアップ、障害対応等を行う
• プログラマ
– データベースのデータを検索・更新するプログラムを作成
する
• 一般利用者
– データベースのデータを利用するユーザ
• データベース用の操作言語で、端末（PC）から利用するユーザ
• あるアプリケーションプログラムを通じてデータベースを利用する
ユーザ
• Amazonや楽天などのインターネットのサイトを利用する人は、
データベースの利用者ということになる
39
データベース言語
• データモデルに基づくデータ記述およびデータ操作の
ための言語を「データベース言語（database
language）」という
• データ定義言語（data definition language, DDL）
– データ記述を行うための言語
• データ操作言語（data manipulation language, DML）
– データ操作を行うための言語
• DDLとDMLは、それぞれ別個の言語として用意される
場合もあるが、全体を一つの言語として用意される場
合もある
• リレーショナルデータベースシステムで使われる代表
的なデータベース言語にSQLがある
40
問い合わせ言語（SQL）の利用例
• データベースから特定のデータを取り出す処
理のことを「問い合わせ（query）」という
• SQLは、表（テーブル）にあるデータの一部を、
指定した条件で抜き出す文法である。
– 抜き出す対象のテーブルと欲しいデータの項目
（列）、検索条件を指定する
– 結果はテーブルの各行で、検索条件に合致した
行だけが抜き出される
– 具体的なイメージは次のページ
41
SQLの利用イメージ
• 最初にあるものは、検索の意図、すなわち何のために
どのような情報がほしいか！
• 「相撲部のキャプテンが、新入生のなかに部員候補と
なる学生がどれだけいるか、そのリストがほしいと考
えた」
• 必要なもの
– 部員候補となる基準： とりあえず身長と体重、そしてそ
れぞれのデータに対する基準値
– 新入生の一覧表（名前と学籍番号、それから身長と体重
のデータも）
具体的な要求事項は
「新入生の一覧表の中から、
身長180cm以上、体重80ｋｇ以上の者を抜き出す」
番号番号
番号番号 氏名氏名氏名氏名 性別性別性別性別 学部学部学部学部 身長身長身長身長 体重体重体重体重 サークルサークルサークルサークル BG001
BG001 BG001
BG001 古溝古溝古溝古溝 亮太亮太亮太亮太 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 175175175175 62626262 なしなしなしなし BG002
BG002 BG002
BG002 菅沼菅沼菅沼菅沼 純平純平純平純平 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 169169169169 56565656 野球部野球部野球部野球部 BG003
BG003 BG003
BG003 青山青山青山青山 雄介雄介雄介雄介 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 186186186186 83838383 サッカー部サッカー部サッカー部サッカー部 BG004
BG004 BG004
BG004 安楽安楽安楽安楽 善美善美善美善美 女女女女 薬学部薬学部薬学部薬学部 158158158158 49494949 なしなしなしなし BG005
BG005 BG005
BG005 井前井前井前井前 大輝大輝大輝大輝 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 174174174174 68686868 なしなしなしなし BG006
BG006 BG006
BG006 佐々木佐々木佐々木佐々木 裕太郎裕太郎裕太郎裕太郎 男男男男 薬学部薬学部薬学部薬学部 182182182182 92929292 なしなしなしなし BG007
BG007 BG007
BG007 中尾中尾中尾中尾 圭佑圭佑圭佑圭佑 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 171171171171 72727272 サッカー部サッカー部サッカー部サッカー部 BG008
BG008 BG008
BG008 平山平山平山平山 大貴大貴大貴大貴 男男男男 薬学部薬学部薬学部薬学部 175175175175 76767676 なしなしなしなし BG009
BG009 BG009
BG009 飯島飯島飯島飯島 健健健健 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 168168168168 56565656 なしなしなしなし BG010
BG010 BG010
BG010 角倉角倉角倉角倉 スミレスミレスミレスミレ 女女女女 薬学部薬学部薬学部薬学部 162162162162 53535353 華道部華道部華道部華道部 BG011
BG011 BG011
BG011 西村西村西村西村 航航航航 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 185185185185 78787878 なしなしなしなし BG012
BG012 BG012
BG012 伏谷伏谷伏谷伏谷 健太健太健太健太 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 174174174174 66666666 野球部野球部野球部野球部 BG013
BG013 BG013
BG013 北村北村北村北村 卓也卓也卓也卓也 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 181181181181 82828282 サッカー部サッカー部サッカー部サッカー部
新入生テーブル
・
・
43要求事項を、普通の言葉からSQLに翻訳する
番号 番号 番号
番号 氏名氏名氏名氏名 性別性別性別性別 学部学部学部学部 身長身長身長身長 体重体重体重体重 サークルサークルサークルサークル BG001
BG001 BG001
BG001 古溝古溝古溝古溝 亮太亮太亮太亮太 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 175175175175 62626262 なしなしなしなし BG002
BG002 BG002
BG002 菅沼菅沼菅沼菅沼 純平純平純平純平 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 169169169169 56565656 野球部野球部野球部野球部 BG003
BG003 BG003
BG003 青山青山青山青山 雄介雄介雄介雄介 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 186186186186 83838383 サッカー部サッカー部サッカー部サッカー部 BG004
BG004 BG004
BG004 安楽安楽安楽安楽 善美善美善美善美 女女女女 薬学部薬学部薬学部薬学部 158158158158 49494949 なしなしなしなし BG005
BG005 BG005
BG005 井前井前井前井前 大輝大輝大輝大輝 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 174174174174 68686868 なしなしなしなし BG006
BG006 BG006
BG006 佐々木佐々木佐々木佐々木 裕太郎裕太郎裕太郎裕太郎 男男男男 薬学部薬学部薬学部薬学部 182182182182 92929292 なしなしなしなし BG007
BG007 BG007
BG007 中尾中尾中尾中尾 圭佑圭佑圭佑圭佑 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 171171171171 72727272 サッカー部サッカー部サッカー部サッカー部 BG008
BG008 BG008
BG008 平山平山平山平山 大貴大貴大貴大貴 男男男男 薬学部薬学部薬学部薬学部 175175175175 76767676 なしなしなしなし BG009
BG009 BG009
BG009 飯島飯島飯島飯島 健健健健 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 168168168168 56565656 なしなしなしなし BG010
BG010 BG010
BG010 角倉角倉角倉角倉 スミレスミレスミレスミレ 女女女女 薬学部薬学部薬学部薬学部 162162162162 53535353 華道部華道部華道部華道部 BG011
BG011 BG011
BG011 西村西村西村西村 航航航航 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 185185185185 78787878 なしなしなしなし BG012
BG012 BG012
BG012 伏谷伏谷伏谷伏谷 健太健太健太健太 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 174174174174 66666666 野球部野球部野球部野球部 BG013
BG013 BG013
BG013 北村北村北村北村 卓也卓也卓也卓也 男男男男 経営情報学部経営情報学部経営情報学部経営情報学部 181181181181 82828282 サッカー部サッカー部サッカー部サッカー部
・
・ 抜き出す （検索する）
新入生テーブル
検索結果
氏名
氏名 氏名
氏名 身長 身長 身長 身長 体重 体重 体重 体重 サークル サークル サークル サークル
青山
青山 青山
青山 雄介 雄介 雄介 雄介 186 186 186 186 83 83 サッカー部 83 83 サッカー部 サッカー部 サッカー部
佐々木 佐々木 佐々木
佐々木 裕太郎 裕太郎 裕太郎 裕太郎 182 182 182 182 92 92 なし 92 92 なし なし なし
北村
北村 北村
北村 卓也 卓也 卓也 卓也 181 181 181 181 82 82 サッカー部 82 82 サッカー部 サッカー部 サッカー部
SELECT 氏名,身長,体重,サークル FROM 学生テーブル
WHERE 身長 >= 180 AND 体重 >= 80
SQL言語
44
45
47
48
