データベースの基本
informationdatabaseundergraduatelecture
data/lecture/information/database/database-portal.lecture.n.md
1導入
この講義では、データベース管理システムによってデータを永続的かつ一貫して管理するための基本概念を説明する。特に、関係モデルの構成要素、キーと整合性制約、正規化の目的、トランザクションの ACID 特性を導入する。
HTTP サーバは要求を処理し、必要に応じて表現を生成するが、利用者、商品、注文などのデータは個々の通信が終了した後にも保持される。このようなデータを複数のプログラムや利用者から安全に共有するには、保存形式だけでなく、制約、同時実行、障害からの回復を管理する仕組みが必要である。
2データベースと DBMS
データベースとは、特定の目的に従って組織化され、永続的に管理されるデータの集合である。
データベース管理システムとは、データベースの定義、保存、検索、更新、アクセス制御、同時実行制御、障害回復などを提供するソフトウェアである。データベースが管理対象となるデータであるのに対し、DBMS はそのデータを管理する機構である。
3関係モデルの構成要素
関係モデルでは、データを関係として表現する。実装上は表として表示されることが多いが、関係は単なる行列形式のファイルではなく、属性とタプルからなる数学的な構造である。
- 属性は、データを特徴づける名前の付いた項目である。
- ドメインは、ある属性が取り得る値の集合である。
- タプルは、各属性に対応する値をまとめた一件のデータである。
- 関係スキーマは、関係名と属性の構成を定める。
- 関係インスタンスは、ある時点でスキーマに適合するタプルの集合である。
たとえば、学生を表現する関係スキーマを次のように記述できる。
\operatorname{Student}(\mathit{student\_id},\ \mathit{name},\ \mathit{department\_id})
この場合、student_id、name、department_id が属性であり、個々の学生に対応する値の組がタプルである。
4キー
スーパーキーとは、関係スキーマで許容されるすべてのインスタンスにおいて、各タプルを一意に識別することが制約された属性集合である。候補キーとは、いずれの真部分集合もスーパーキーではない極小なスーパーキーである。
主キーとは、候補キーのうち、タプルの主要な識別子として選択したものである。候補キーは複数存在し得るが、主キーとして選択するものは一つである。
外部キーとは、ある関係の属性集合であり、その値が同一または別の関係の候補キーを参照する。たとえば、Student.department_id が学部の関係にある Department.department_id を参照すれば、学生と所属学部を関連づけられる。
5整合性制約
整合性制約とは、データベースの状態が満たすべき条件である。代表的な制約には、次のものがある。
- ドメイン制約は、属性値を所定のドメインへ制限する。
- キー制約は、候補キーの値がタプルを一意に識別することを要求する。
- 実体整合性は、主キーの構成属性が欠損せず、各タプルを識別できることを要求する。
- 参照整合性は、外部キーの非空の値が参照先に存在することを要求する。
DBMS はこれらの制約に違反する更新を拒否し、または宣言された参照動作に従って関連するデータを更新する。ただし、データが現実世界を正確に反映しているかどうかは、スキーマに表現された制約だけでは完全に保証できない。
6正規化の目的
同一の事実を複数箇所へ記録すると、一部だけを更新することによる不整合、データを追加できない状況、削除に伴う別の事実の消失が生じ得る。これらをそれぞれ更新、挿入、削除の異常という。
正規化とは、属性間の依存関係に基づいて関係スキーマを分解し、望ましくない冗長性と更新異常を抑制するための設計過程である。正規化はあらゆる重複を消去することではなく、依存関係を適切に表現することを目的とする。性能や利用形態に応じて、意図的に冗長性を導入する非正規化もある。
7トランザクションと ACID
トランザクションとは、DBMS が一つの論理的な作業単位として扱う操作列である。たとえば送金では、一方の口座からの減額と他方の口座への増額を一体として処理する必要がある。
トランザクションの代表的な特性を ACID と総称する。
- 原子性: トランザクションの全操作を反映するか、いずれも反映しない。
- 一貫性: トランザクションが正しく実行されると、制約を満たす状態から別のそのような状態へ移行する。
- 独立性: 並行するトランザクションの干渉を制御し、所定の分離レベルに対応する観測結果を提供する。
- 永続性: 確定したトランザクションの結果は、以後の障害に対して保持される。
ACID は実装方式そのものではなく、トランザクション処理が目標とする性質である。また、一貫性は DBMS だけで自動的に得られるものではなく、適切な制約と正しいトランザクション処理を必要とする。
8要点
- データベースは組織化されたデータであり、DBMS はその定義、操作、保護を担う。
- 関係スキーマは属性の構成を定め、関係インスタンスはある時点のタプルの集合である。
- 候補キー、主キー、外部キー、および整合性制約は、データの識別と関連を表現する。
- 正規化は望ましくない冗長性と更新異常を抑制し、トランザクションは複数の操作を論理的な単位として管理する。
9次に進む講義
data/lecture/information/database/sql-basics.lecture.n.md
Database Fundamentals
data/lecture/information/database/database-portal.lecture.n.md
1Introduction
This lecture explains the fundamental concepts through which a database management system manages data persistently and consistently. In particular, it introduces the components of the relational model, keys and integrity constraints, the purpose of normalization, and the ACID properties of transactions.
An HTTP server processes requests and generates representations when needed, but data concerning users, products, and orders must remain available after individual communications end. Sharing such data safely among multiple programs and users requires mechanisms that manage not only storage formats but also constraints, concurrency, and recovery from failures.
2Databases and DBMSs
A database is a collection of data that is organized for a particular purpose and managed persistently.
A database management system is software that provides database definition, storage, querying, updating, access control, concurrency control, failure recovery, and related functions. A database is the data being managed, whereas a DBMS is the mechanism that manages it.
3Components of the Relational Model
The relational model represents data as relations. Relations are often displayed as tables in implementations, but a relation is not merely a file arranged in rows and columns; it is a mathematical structure consisting of attributes and tuples.
- An attribute is a named component that characterizes the data.
- A domain is the set of values that an attribute may take.
- A tuple is one data item containing a value corresponding to each attribute.
- A relation schema specifies a relation name and its attribute structure.
- A relation instance is the set of tuples that conforms to a schema at a particular time.
For example, a relation schema representing students can be written as follows.
\operatorname{Student}(\mathit{student\_id},\ \mathit{name},\ \mathit{department\_id})
Here, student_id, name, and department_id are attributes, and each collection of values corresponding to one student is a tuple.
4Keys
A superkey is a set of attributes constrained to identify every tuple uniquely in every instance permitted by a relation schema. A candidate key is a minimal superkey: no proper subset of it is itself a superkey.
A primary key is the candidate key selected as the principal identifier of tuples. A relation may have multiple candidate keys, but only one is selected as its primary key.
A foreign key is a set of attributes in one relation whose values reference a candidate key in the same or another relation. For example, if Student.department_id references Department.department_id in a department relation, it associates each student with a department.
5Integrity Constraints
An integrity constraint is a condition that database states must satisfy. Representative constraints include the following.
- A domain constraint restricts an attribute value to its specified domain.
- A key constraint requires candidate-key values to identify tuples uniquely.
- Entity integrity requires the primary-key attributes to be present so that each tuple can be identified.
- Referential integrity requires every non-null foreign-key value to exist in the referenced relation.
A DBMS rejects updates that violate these constraints or updates related data according to declared referential actions. Constraints expressed in a schema cannot, however, fully guarantee that data accurately reflects the real world.
6Purpose of Normalization
Recording the same fact in several locations can cause inconsistency when only one occurrence is updated, inability to insert data, or loss of a separate fact during deletion. These problems are called update, insertion, and deletion anomalies, respectively.
Normalization is the design process of decomposing relation schemas according to dependencies among attributes in order to reduce undesirable redundancy and update anomalies. Normalization does not mean eliminating every duplication; its purpose is to represent dependencies appropriately. Denormalization may deliberately introduce redundancy in response to performance requirements or access patterns.
7Transactions and ACID
A transaction is a sequence of operations that a DBMS treats as one logical unit of work. A funds transfer, for example, must treat the debit from one account and the credit to another as one unit.
Four representative transaction properties are collectively called ACID.
- Atomicity: either all operations of a transaction take effect, or none do.
- Consistency: when a transaction executes correctly, it moves the database from one constraint-satisfying state to another.
- Isolation: interference among concurrent transactions is controlled to provide observations corresponding to a specified isolation level.
- Durability: the effects of a committed transaction remain preserved despite subsequent failures.
ACID describes desired properties of transaction processing rather than a particular implementation. Consistency is not obtained automatically from the DBMS alone; it also requires appropriate constraints and correct transaction logic.
8Key Points
- A database is organized data, whereas a DBMS defines, operates on, and protects that data.
- A relation schema specifies an attribute structure, while a relation instance is the set of tuples present at a particular time.
- Candidate keys, primary keys, foreign keys, and integrity constraints express identification and relationships among data.
- Normalization reduces undesirable redundancy and update anomalies, while transactions manage several operations as a logical unit.
9Next Lecture
data/lecture/information/database/sql-basics.lecture.n.md