データベース
Database
データベースとは、電子的に保存され、アクセスされるデータの組織化された集合体で ある。小規模なデータベースはファイルシステム上に保存でき、大規模なデータベースはコンピュータクラスタやクラウドストレージにホストされる。データ ベースの設計は、データモデリング、効率的なデータ表現と保存、クエリー言語、機密データのセキュリティとプライバシー、同時アクセスやフォールトトレラ ンスのサポートなどの分散コンピューティングの問題など、形式手法と実際の考察にまたがるものである。
| In computing, a
database is an organized collection of data stored and accessed
electronically. Small databases can be stored on a file system, while
large databases are hosted on computer clusters or cloud storage. The
design of databases spans formal techniques and practical
considerations, including data modeling, efficient data representation
and storage, query languages, security and privacy of sensitive data,
and distributed computing issues, including supporting concurrent
access and fault tolerance. A database management system (DBMS) is the software that interacts with end users, applications, and the database itself to capture and analyze the data. The DBMS software additionally encompasses the core facilities provided to administer the database. The sum total of the database, the DBMS and the associated applications can be referred to as a database system. Often the term "database" is also used loosely to refer to any of the DBMS, the database system or an application associated with the database. Computer scientists may classify database management systems according to the database models that they support. Relational databases became dominant in the 1980s. These model data as rows and columns in a series of tables, and the vast majority use SQL for writing and querying data. In the 2000s, non-relational databases became popular, collectively referred to as NoSQL, because they use different query languages. |
コンピュータにおいて、データベースとは、電子的に保存され、アクセスされるデータの組織化された集合体で
ある。小規模なデータベースはファイルシステム上に保存でき、大規模なデータベースはコンピュータクラスタやクラウドストレージにホストされる。データ
ベースの設計は、データモデリング、効率的なデータ表現と保存、クエリー言語、機密データのセキュリティとプライバシー、同時アクセスやフォールトトレラ
ンスのサポートなどの分散コンピューティングの問題など、形式手法と実際の考察にまたがるものである。 データベース管理システム（DBMS）は、エンドユーザー、アプリケー ション、データベースそのものと対話し、データを取得・分析するためのソフトウェアで ある。DBMSソフトウェアは、さらに、データベースを管理するために提供される中核的な機能を包含している。データベース、DBMS、関連アプリケー ションの総称をデータベースシステムと呼ぶことができる。多くの場合、「データベース」という用語は、DBMS、データベースシステム、またはデータベー スに関連するアプリケーションのいずれかを指す場合にも緩やかに使用される。 コンピュータ科学者は、データベース管理システムを、それがサポートするデータベースモデルによって分類することができる。リレーショナルデータベースは 1980 年代に主流となった。このデータベースは、データを一連のテーブルの行と列としてモデル化し、大多数はデータの書き込みと問い合わせにSQLを使用してい る。2000年代には、非リレーショナルデータベースが普及し、異なる問い合わせ言語を使用することから、総称してNoSQLと呼ばれるようになった。 |
| Terminology and overview Formally, a "database" refers to a set of related data and the way it is organized. Access to this data is usually provided by a "database management system" (DBMS) consisting of an integrated set of computer software that allows users to interact with one or more databases and provides access to all of the data contained in the database (although restrictions may exist that limit access to particular data). The DBMS provides various functions that allow entry, storage and retrieval of large quantities of information and provides ways to manage how that information is organized. Because of the close relationship between them, the term "database" is often used casually to refer to both a database and the DBMS used to manipulate it. Outside the world of professional information technology, the term database is often used to refer to any collection of related data (such as a spreadsheet or a card index) as size and usage requirements typically necessitate use of a database management system.[1] Existing DBMSs provide various functions that allow management of a database and its data which can be classified into four main functional groups: Data definition – Creation, modification and removal of definitions that define the organization of the data. Update – Insertion, modification, and deletion of the actual data.[2] Retrieval – Providing information in a form directly usable or for further processing by other applications. The retrieved data may be made available in a form basically the same as it is stored in the database or in a new form obtained by altering or combining existing data from the database.[3] Administration – Registering and monitoring users, enforcing data security, monitoring performance, maintaining data integrity, dealing with concurrency control, and recovering information that has been corrupted by some event such as an unexpected system failure.[4] Both a database and its DBMS conform to the principles of a particular database model.[5] "Database system" refers collectively to the database model, database management system, and database.[6] Physically, database servers are dedicated computers that hold the actual databases and run only the DBMS and related software. Database servers are usually multiprocessor computers, with generous memory and RAID disk arrays used for stable storage. Hardware database accelerators, connected to one or more servers via a high-speed channel, are also used in large volume transaction processing environments. DBMSs are found at the heart of most database applications. DBMSs may be built around a custom multitasking kernel with built-in networking support, but modern DBMSs typically rely on a standard operating system to provide these functions.[citation needed] Since DBMSs comprise a significant market, computer and storage vendors often take into account DBMS requirements in their own development plans.[7] Databases and DBMSs can be categorized according to the database model(s) that they support (such as relational or XML), the type(s) of computer they run on (from a server cluster to a mobile phone), the query language(s) used to access the database (such as SQL or XQuery), and their internal engineering, which affects performance, scalability, resilience, and security. |
用語と概要 形式的には、「データベース」とは、関連するデータの集合と、その編成方法を指す。このデータへのアクセスは通常、「データベース管理システム」 （DBMS）によって提供される。このシステムは、ユーザーが1つまたは複数のデータベースと対話し、データベースに含まれるすべてのデータへのアクセス を可能にする統合されたコンピュータソフトウェアのセットで構成されている（ただし、特定のデータへのアクセスを制限する制約が存在する場合もある）。 DBMSは、大量の情報の入力、保存、検索を可能にする様々な機能を提供し、その情報がどのように組織化されているかを管理する方法を提供する。 このように両者は密接な関係にあるため、「データベース」という言葉は、データベースとそれを操作するためのDBMSの両方を指す言葉として気軽に使われ ることが多い。 専門的な情報技術の世界以外では、データベースという用語は、関連するデータの集まり（スプレッドシートやカードインデックスなど）を指すことが多く、サ イズや使用要件からデータベース管理システムを使用することが一般的である[1]。 既存のDBMSは、データベースとそのデータを管理するための様々な機能を提供しており、それらは4つの主要な機能群に分類することができる。 データ定義 - データの構成を定義する定義の作成、変更、削除。 更新 - 実際のデータの挿入、変更、削除[2]。 検索 - 情報を直接利用可能な形で、または他のアプリケーションでさらに処理できるように提供すること。検索されたデータは、基本的にデータベースに格納されてい るのと同じ形態で利用可能になる場合もあれば、データベースから既存のデータを変更したり組み合わせたりして得られた新しい形態で利用可能になる場合もあ る[3]。 管理 - ユーザーの登録と監視、データセキュリティの実施、パフォーマンスの監視、データの整合性の維持、同時実行制御の処理、予期せぬシステム障害など何らかの 事象によって破損した情報の回復など[4]。 データベースとその DBMS はともに、特定のデータベースモデルの原則に準拠している[5]。「データベースシステム」は、データベースモデル、データベース管理システム、および データベースを総称している[6]。 物理的には、データベースサーバーは実際のデータベースを保持し、DBMSと関連ソフトウェアのみを実行する専用コンピュータである。データベースサー バーは通常マルチプロセッサーであり、メモリに余裕があり、安定した保存のためにRAIDディスクアレイが使用される。大容量トランザクション処理環境で は、1台または複数台のサーバーと高速チャネルで接続されたハードウェアデータベースアクセラレータも使用される。DBMSは、ほとんどのデータベースア プリケーションの中核をなしている。DBMSはネットワークサポートを内蔵したカスタムのマルチタスクカーネルを中心に構築されることもあるが、最近の DBMSは通常、これらの機能を提供するために標準的なオペレーティングシステムに依存している[citation needed]。 DBMSは重要な市場を構成しているため、コンピュータとストレージのベンダーはしばしば自らの開発計画にDBMSの要件を取り込んでいる[7]。 データベースと DBMS は、サポートするデータベースモデル（リレーショナルや XML など）、実行するコンピュータの種類（サーバークラスタから携帯電話まで）、データベースへのアクセスに使用するクエリー言語（SQL や XQuery など）、性能、拡張性、回復力、セキュリティに影響する内部エンジニアリングによって分類することができる。 |
| History The sizes, capabilities, and performance of databases and their respective DBMSs have grown in orders of magnitude. These performance increases were enabled by the technology progress in the areas of processors, computer memory, computer storage, and computer networks. The concept of a database was made possible by the emergence of direct access storage media such as magnetic disks, which became widely available in the mid-1960s; earlier systems relied on sequential storage of data on magnetic tape. The subsequent development of database technology can be divided into three eras based on data model or structure: navigational,[8] SQL/relational, and post-relational. The two main early navigational data models were the hierarchical model and the CODASYL model (network model). These were characterized by the use of pointers (often physical disk addresses) to follow relationships from one record to another. The relational model, first proposed in 1970 by Edgar F. Codd, departed from this tradition by insisting that applications should search for data by content, rather than by following links. The relational model employs sets of ledger-style tables, each used for a different type of entity. Only in the mid-1980s did computing hardware become powerful enough to allow the wide deployment of relational systems (DBMSs plus applications). By the early 1990s, however, relational systems dominated in all large-scale data processing applications, and as of 2018 they remain dominant: IBM Db2, Oracle, MySQL, and Microsoft SQL Server are the most searched DBMS.[9] The dominant database language, standardized SQL for the relational model, has influenced database languages for other data models.[citation needed] Object databases were developed in the 1980s to overcome the inconvenience of object–relational impedance mismatch, which led to the coining of the term "post-relational" and also the development of hybrid object–relational databases. The next generation of post-relational databases in the late 2000s became known as NoSQL databases, introducing fast key–value stores and document-oriented databases. A competing "next generation" known as NewSQL databases attempted new implementations that retained the relational/SQL model while aiming to match the high performance of NoSQL compared to commercially available relational DBMSs. |
歴史 データベースとそのDBMSの規模、機能、性能は桁違いに大きくなってきた。これらの性能向上は、プロセッサー、コンピューターメモリー、コンピューター ストレージ、コンピューターネットワークなどの技術進歩によって可能となった。データベースの概念は、1960年代半ばに広く普及した磁気ディスクのよう な直接アクセス可能な記憶媒体の出現によって実現された。データベース技術のその後の発展は、データモデルや構造に基づいて、ナビゲーショナル、SQL/ リレーショナル、ポストリレーショナルという3つの時代に分けることができる[8]。 初期のナビゲーション型データモデルとしては、階層型とCODASYL型（ネットワーク型）の2つが主流であった。これらは、あるレコードから別のレコー ドへの関係をたどるために、ポインタ（多くの場合、物理的なディスクアドレス）を使用することを特徴としていた。 1970年にEdgar F. Coddが提唱したリレーショナルモデルは、この伝統から脱却し、アプリケーションはリンクをたどるのではなく、内容からデータを探すべきであると主張す るもので あった。リレーショナルモデルは、台帳型のテーブルを組み合わせて、それぞれが異なる種類のエンティティに使用される。1980年代半ばにようやく、コン ピュータのハードウェアがリレーショナルシステム（DBMSとアプリケーション）を広く展開できるほど強力になった。しかし、1990年代初頭には、大規 模なデータ処理アプリケーションのすべてにおいてリレーショナルシステムが主流となり、2018年現在も主流であり続けている。IBM Db2、Oracle、MySQL、Microsoft SQL Serverが最も検索されているDBMSである[9]。 支配的なデータベース言語であるリレーショナルモデル用の標準SQLは、他のデータモデル用のデータベース言語にも影響を与えている[引用者注：要注 意]。 オブジェクトデータベースは1980年代にオブジェクトとリレーのインピーダンス不整合の不都合を克服するために開発され、「ポストリレーショナル」とい う言葉が生まれ、またオブジェクトとリレーのハイブリッドデータベースが開発されるに至った。 2000年代後半のポストリレーショナルデータベースの次世代は、高速なキーバリューストアやドキュメント指向のデータベースを導入し、NoSQLデータ ベースと呼ばれるようになった。これと競合する「次世代」のNewSQLデータベースは、リレーショナル/SQLモデルを維持しつつ、市販のリレーショナ ルDBMSと比較してNoSQLの高い性能に見合うような新しい実装を試みている。 |
| 1960s, navigational DBMS The introduction of the term database coincided with the availability of direct-access storage (disks and drums) from the mid-1960s onwards. The term represented a contrast with the tape-based systems of the past, allowing shared interactive use rather than daily batch processing. The Oxford English Dictionary cites a 1962 report by the System Development Corporation of California as the first to use the term "data-base" in a specific technical sense.[10] As computers grew in speed and capability, a number of general-purpose database systems emerged; by the mid-1960s a number of such systems had come into commercial use. Interest in a standard began to grow, and Charles Bachman, author of one such product, the Integrated Data Store (IDS), founded the Database Task Group within CODASYL, the group responsible for the creation and standardization of COBOL. In 1971, the Database Task Group delivered their standard, which generally became known as the CODASYL approach, and soon a number of commercial products based on this approach entered the market. The CODASYL approach offered applications the ability to navigate around a linked data set which was formed into a large network. Applications could find records by one of three methods: 1 Use of a primary key (known as a CALC key, typically implemented by hashing) 2. Navigating relationships (called sets) from one record to another 3. Scanning all the records in a sequential order Later systems added B-trees to provide alternate access paths. Many CODASYL databases also added a declarative query language for end users (as distinct from the navigational API). However, CODASYL databases were complex and required significant training and effort to produce useful applications. IBM also had its own DBMS in 1966, known as Information Management System (IMS). IMS was a development of software written for the Apollo program on the System/360. IMS was generally similar in concept to CODASYL, but used a strict hierarchy for its model of data navigation instead of CODASYL's network model. Both concepts later became known as navigational databases due to the way data was accessed: the term was popularized by Bachman's 1973 Turing Award presentation The Programmer as Navigator. IMS is classified by IBM as a hierarchical database. IDMS and Cincom Systems' TOTAL databases are classified as network databases. IMS remains in use as of 2014.[11] |
1960年代、航法型DBMS データベースという言葉が登場したのは、1960年代半ば以降、直接ア クセス可能なストレージ（ディスクやドラム缶）が利用できるようになった時期と重なる。この言葉は、かつてのテープベースのシステムとは対照的で、日々の バッチ処理ではなく、対話的な共有利用を可能にするものであった。オックスフォード英語辞典では、「データベース」という用語を特定の技術的な意味で初め て使用したものとして、カリフォルニア州のシステム開発社の1962年の報告書を挙げている[10]。 コンピュータの速度と性能が向上するにつれて、多くの汎用データベースシステムが登場し、1960年代半ばには、そのようなシステムの多くが商業的に使用 されるようになった。標準化への関心が高まり、その1つである統合データストア（IDS）の作者であるチャールズ・バックマンは、COBOLの作成と標準 化を担当するCODASYLにデータベースタスクグループを設立した。1971年、データベース・タスク・グループは、一般にCODASYLアプローチと して知られるようになった彼らの標準を提供し、すぐにこのアプローチに基づいた多くの商用製品が市場に出てきた。 CODASYL方式は、アプリケーションに、大きなネットワークに形成されたリンクされたデータセット内を移動する機能を提供するものであった。アプリ ケーションは、3つの方法のうちの1つによってレコードを見つけることができる。 1. 主キーの使用（CALCキーとして知られ、典型的にはハッシュ化によって実装される）。 2. 1つのレコードから別のレコードへの関係（セットと呼ばれる）をナビゲートする。 3. すべてのレコードを順番にスキャンする。 後のシステムでは、B-treeが追加され、別のアクセス経路が提供されるようになった。多くのCODASYLデータベースは、エンドユーザー向けに（ナ ビゲーションAPIとは異なる）宣言型のクエリー言語も追加している。しかし、CODASYLデータベースは複雑で、有用なアプリケーションを作るにはか なりの訓練と労力が必要でした。 IBMも1966年に独自のDBMSを持っており、情報管理システム（IMS）として知られていた。IMSはSystem/360上のApolloプログ ラムのために書かれたソフトウェアを発展させたものであった。IMSは一般にCODASYLとコンセプトが似ているが、データナビゲーションのモデルに CODASYLのネットワークモデルではなく、厳密な階層を使用していた。この言葉は、1973年にバックマンが発表したチューリング賞の「The Programmer as Navigator」によって一般化した。IMSはIBMによって階層型データベースとして分類されている。IDMSやCincom SystemsのTOTALデータベースは、ネットワークデータベースに分類される。IMSは2014年現在も使用されている[11]。 |
| 1970s, relational DBMS Edgar F. Codd worked at IBM in San Jose, California, in one of their offshoot offices that were primarily involved in the development of hard disk systems. He was unhappy with the navigational model of the CODASYL approach, notably the lack of a "search" facility. In 1970, he wrote a number of papers that outlined a new approach to database construction that eventually culminated in the groundbreaking A Relational Model of Data for Large Shared Data Banks.[12] In this paper, he described a new system for storing and working with large databases. Instead of records being stored in some sort of linked list of free-form records as in CODASYL, Codd's idea was to organize the data as a number of "tables", each table being used for a different type of entity. Each table would contain a fixed number of columns containing the attributes of the entity. One or more columns of each table were designated as a primary key by which the rows of the table could be uniquely identified; cross-references between tables always used these primary keys, rather than disk addresses, and queries would join tables based on these key relationships, using a set of operations based on the mathematical system of relational calculus (from which the model takes its name). Splitting the data into a set of normalized tables (or relations) aimed to ensure that each "fact" was only stored once, thus simplifying update operations. Virtual tables called views could present the data in different ways for different users, but views could not be directly updated. Codd used mathematical terms to define the model: relations, tuples, and domains rather than tables, rows, and columns. The terminology that is now familiar came from early implementations. Codd would later criticize the tendency for practical implementations to depart from the mathematical foundations on which the model was based. The use of primary keys (user-oriented identifiers) to represent cross-table relationships, rather than disk addresses, had two primary motivations. From an engineering perspective, it enabled tables to be relocated and resized without expensive database reorganization. But Codd was more interested in the difference in semantics: the use of explicit identifiers made it easier to define update operations with clean mathematical definitions, and it also enabled query operations to be defined in terms of the established discipline of first-order predicate calculus; because these operations have clean mathematical properties, it becomes possible to rewrite queries in provably correct ways, which is the basis of query optimization. There is no loss of expressiveness compared with the hierarchic or network models, though the connections between tables are no longer so explicit. In the hierarchic and network models, records were allowed to have a complex internal structure. For example, the salary history of an employee might be represented as a "repeating group" within the employee record. In the relational model, the process of normalization led to such internal structures being replaced by data held in multiple tables, connected only by logical keys. For instance, a common use of a database system is to track information about users, their name, login information, various addresses and phone numbers. In the navigational approach, all of this data would be placed in a single variable-length record. In the relational approach, the data would be normalized into a user table, an address table and a phone number table (for instance). Records would be created in these optional tables only if the address or phone numbers were actually provided. As well as identifying rows/records using logical identifiers rather than disk addresses, Codd changed the way in which applications assembled data from multiple records. Rather than requiring applications to gather data one record at a time by navigating the links, they would use a declarative query language that expressed what data was required, rather than the access path by which it should be found. Finding an efficient access path to the data became the responsibility of the database management system, rather than the application programmer. This process, called query optimization, depended on the fact that queries were expressed in terms of mathematical logic. Codd's paper was picked up by two people at Berkeley, Eugene Wong and Michael Stonebraker. They started a project known as INGRES using funding that had already been allocated for a geographical database project and student programmers to produce code. Beginning in 1973, INGRES delivered its first test products which were generally ready for widespread use in 1979. INGRES was similar to System R in a number of ways, including the use of a "language" for data access, known as QUEL. Over time, INGRES moved to the emerging SQL standard. IBM itself did one test implementation of the relational model, PRTV, and a production one, Business System 12, both now discontinued. Honeywell wrote MRDS for Multics, and now there are two new implementations: Alphora Dataphor and Rel. Most other DBMS implementations usually called relational are actually SQL DBMSs. In 1970, the University of Michigan began development of the MICRO Information Management System[13] based on D.L. Childs' Set-Theoretic Data model.[14][15][16] MICRO was used to manage very large data sets by the US Department of Labor, the U.S. Environmental Protection Agency, and researchers from the University of Alberta, the University of Michigan, and Wayne State University. It ran on IBM mainframe computers using the Michigan Terminal System.[17] The system remained in production until 1998. |
1970年代、リレーショナルDBMS エドガー・F・コッドは、カリフォルニア州サンノゼのIBMで、主にハードディスクシステムの開発に携わっていた分室の1つに勤めていた。彼は、 CODASYLアプローチのナビゲーションモデル、特に「検索」機能がないことに不満を持っていた。1970年、彼はデータベース構築への新しいアプロー チを概説する多くの論文を書き、最終的に画期的な「大規模共有データバンクのためのデータのリレーショナルモデル」[12]で結実した。 この論文で、彼は大規模なデータベースを保存し、利用するための新しいシステムを説明しました。CODASYLのようにレコードをある種の自由形式のリン クリストに格納するのではなく、コッドのアイデアは、データをいくつかの「テーブル」として整理し、それぞれのテーブルを異なるタイプのエンティティに使 用することであった。各テーブルは、エンティティの属性を含む固定数のカラムを含んでいる。各テーブルの1つ以上のカラムは、テーブルの行を一意に識別で きる主キーとして指定され、テーブル間の相互参照には、ディスクアドレスではなく、常にこの主キーを使用し、クエリーでは、関係論理学という数学体系に基 づく一連の操作を使って、このキー関係に基づいてテーブルを結合する（このモデルが名前の由来になっている）。データを正規化されたテーブル（または関 係）の集合に分割することで、各「ファクト」が一度だけ保存されるようにし、更新操作を簡略化することを目指した。ビューと呼ばれる仮想のテーブルは、 ユーザーごとに異なる方法でデータを表示することができるが、ビューを直接更新することはできない。 コッドは、テーブル、行、列ではなく、関係、タプル、領域という数学用語を使ってモデルを定義した。現在ではおなじみの用語は、初期の実装に由来するもの である。コッドは後に、実用的な実装がモデルの基礎となる数学的な基礎から逸脱する傾向があることを批判することになる。 テーブル間の関係を表すのに、ディスクアドレスではなく、主キー(ユーザー指向の識別子)を使用したのは、主に2つの動機がありました。エンジニアリング の観点からは、高価なデータベースの再編成をすることなくテーブルの再配置やサイズ変更を可能にすることです。明示的な識別子を使用することで、きれいな 数学的定義で更新操作を定義することが容易になり、また、一階述語論理という確立した学問の観点からクエリー操作を定義することが可能になりました。テー ブル間の接続は明示的ではなくなったが、階層モデルやネットワークモデルと比較して表現力は損なわれていない。 階層モデルやネットワークモデルでは、レコードは複雑な内部構造を持つことが許されていた。例えば、ある従業員の給与の履歴は、従業員レコードの中の「繰 り返しグループ」として表されることができる。リレーショナルモデルでは、正規化の過程で、このような内部構造は、論理キーだけで結ばれた複数のテーブル で保持されるデータに取って代わられることになった。 例えば、データベースシステムの一般的な使い方として、ユーザーに関する情報、名前、ログイン情報、様々な住所や電話番号などを追跡することが挙げられ る。ナビゲーショナルアプローチでは、これらのデータはすべて1つの可変長レコードに収められます。リレーショナル方式では、データはユーザーテーブル、 アドレステーブル、電話番号テーブル（例）に正規化されます。これらのオプションのテーブルには、実際に住所や電話番号が提供された場合のみレコードが作 成される。 コッドは、ディスクアドレスではなく論理的な識別子を使って行やレコードを識別するだけでなく、アプリケーションが複数のレコードからデータを収集する方 法を変更しました。アプリケーションがリンクをたどって1レコードずつデータを収集するのではなく、どのようなデータが必要かを表現する宣言型のクエリー 言語を使用し、どのようにデータを見つけるかではなく、どのようにデータを見つけるべきかを表現するようになったのです。データへの効率的なアクセス経路 を見つけるのは、アプリケーションプログラマーではなく、データベース管理システムの責任になった。このプロセスは「クエリーの最適化」と呼ばれ、クエ リーが数学的論理で表現されることに依存していた。 コッドの論文は、バークレー校のユージン・ウォンとマイケル・ストーンブレーカーという2人の人物に取り上げられた。彼らは、すでに地理データベースプロ ジェクトに割り当てられていた資金と、コードを作成する学生プログラマーを使って、INGRESと呼ばれるプロジェクトを開始しました。1973年に始 まったINGRESは、最初のテスト製品を提供し、1979年には一般に広く使用できるようになりました。INGRESは、QUELと呼ばれるデータアク セス用の「言語」を使用するなど、多くの点でSystem Rと類似していました。時間の経過とともに、INGRESは新しい標準SQLに移行しました。 IBMはリレーショナルモデルのテスト実装であるPRTVと、製品版であるBusiness System 12を開発しましたが、いずれも現在は製造中止となっています。HoneywellはMulticsのためにMRDSを書きましたが、現在では2つの新し い実装が存在します。リレーショナルと呼ばれる他のほとんどのDBMSは、実はSQL DBMSである。 1970年、ミシガン大学はD.L. Childsの集合論的データモデルに基づくMICRO情報管理システム[13]の開発を開始した[14][15][16] MICROは米国労働省、米国環境保護局、アルバータ大学、ミシガン大学、ウェイン州立大学の研究者によって非常に大きなデータセットを管理するのに、使 用されていた。MICROはIBMのメインフレームコンピュータ上でMichigan Terminal Systemを使用して稼働していた[17]。 |
| In the 1970s and 1980s, attempts
were made to build database systems with integrated hardware and
software. The underlying philosophy was that such integration would
provide higher performance at a lower cost. Examples were IBM
System/38, the early offering of Teradata, and the Britton Lee, Inc.
database machine. Another approach to hardware support for database management was ICL's CAFS accelerator, a hardware disk controller with programmable search capabilities. In the long term, these efforts were generally unsuccessful because specialized database machines could not keep pace with the rapid development and progress of general-purpose computers. Thus most database systems nowadays are software systems running on general-purpose hardware, using general-purpose computer data storage. However, this idea is still pursued in certain applications by some companies like Netezza and Oracle (Exadata). |
1970年代から1980年代にかけて、ハードウェアとソフトウェアを
統合したデータベースシステムを構築する試みが行われた。その根底にある哲学は、このような統合によって、より高い性能をより低いコストで実現できるとい
うものであった。その例として、IBM System/38、Teradataの初期の製品、Britton Lee,
Inc.のデータベースマシンが挙げられます。 また、データベース管理をハードウェアでサポートするアプローチとして、ICLのCAFSアクセラレータという、プログラム可能な検索機能を持つハード ウェアディスクコントローラーもありました。しかし、汎用コンピュータの急速な発展と進歩にデータベース専用機が追いつけなかったため、長期的にはこれら の努力は概ね失敗に終わった。このため、現在ではほとんどのデータベースシステムが、汎用コンピュータのデータストレージを利用し、汎用ハードウェア上で 動作するソフトウェアシステムとなっている。しかし、Netezza社やOracle社（Exadata）など一部の企業では、今でもこの考え方が特定の 用途で追求されている。 |
| Late 1970s, SQL DBMS IBM started working on a prototype system loosely based on Codd's concepts as System R in the early 1970s. The first version was ready in 1974/5, and work then started on multi-table systems in which the data could be split so that all of the data for a record (some of which is optional) did not have to be stored in a single large "chunk". Subsequent multi-user versions were tested by customers in 1978 and 1979, by which time a standardized query language – SQL[citation needed] – had been added. Codd's ideas were establishing themselves as both workable and superior to CODASYL, pushing IBM to develop a true production version of System R, known as SQL/DS, and, later, Database 2 (IBM Db2). Larry Ellison's Oracle Database (or more simply, Oracle) started from a different chain, based on IBM's papers on System R. Though Oracle V1 implementations were completed in 1978, it wasn't until Oracle Version 2 when Ellison beat IBM to market in 1979.[18] Stonebraker went on to apply the lessons from INGRES to develop a new database, Postgres, which is now known as PostgreSQL. PostgreSQL is often used for global mission-critical applications (the .org and .info domain name registries use it as their primary data store, as do many large companies and financial institutions). In Sweden, Codd's paper was also read and Mimer SQL was developed in the mid-1970s at Uppsala University. In 1984, this project was consolidated into an independent enterprise. Another data model, the entity–relationship model, emerged in 1976 and gained popularity for database design as it emphasized a more familiar description than the earlier relational model. Later on, entity–relationship constructs were retrofitted as a data modeling construct for the relational model, and the difference between the two has become irrelevant.[citation needed] |
1970年代後半、SQL DBMS IBMは1970年代前半にコッドの概念を緩やかに取り入れたシステムのプロトタイプをSystem Rとして作業を開始した。最初のバージョンは1974/5に完成し、その後、レコードのすべてのデータ（一部はオプション）を単一の大きな「チャンク」に 格納する必要がないように、データを分割できるマルチテーブルシステムに関する作業が開始された。その後、1978年と1979年にマルチユーザーバー ジョンが顧客によってテストされ、その頃には標準化されたクエリー言語であるSQL[要出典]が追加されていた。コッドのアイデアはCODASYLよりも 実行可能で優れたものとして確立され、IBMはSQL/DSとして知られるシステムRの真の製品版、そして後にデータベース2（IBM Db2）を開発するよう推し進めた。 ラリー・エリソンのオラクル・データベース（またはより単純にオラクル）は、システムRに関するIBMの論文を基に、異なる連鎖から出発しました。オラク ルV1の実装は1978年に完了しましたが、エリソンが1979年にIBMを抑えて市場に出たのはオラクルV2になってからでした[18]。 Stonebrakerはその後、INGRESからの教訓を応用して新しいデータベース、Postgresを開発しました。PostgreSQLはグロー バルなミッションクリティカルなアプリケーションによく使用されています（.orgと.infoドメイン名レジストリは主要なデータストアとして使用して おり、多くの大企業や金融機関もそうしています）。 スウェーデンでは、コッドの論文も読まれ、1970年代半ばにウプサラ大学でMimer SQLが開発されました。1984年、このプロジェクトは独立した企業として統合された。 もう一つのデータモデルである実体-関係モデルは1976年に登場し、それまでの関係モデルよりも身近な記述を重視したため、データベース設計に人気を博 した。その後、エンティティ-リレーションシップの構成はリレーショナルモデルのデータモデリング構成として後付けされ、両者の違いは意味をなさなくなっ た[要出典]。 |
| 1980s, on the desktop The 1980s ushered in the age of desktop computing. The new computers empowered their users with spreadsheets like Lotus 1-2-3 and database software like dBASE. The dBASE product was lightweight and easy for any computer user to understand out of the box. C. Wayne Ratliff, the creator of dBASE, stated: "dBASE was different from programs like BASIC, C, FORTRAN, and COBOL in that a lot of the dirty work had already been done. The data manipulation is done by dBASE instead of by the user, so the user can concentrate on what he is doing, rather than having to mess with the dirty details of opening, reading, and closing files, and managing space allocation."[19] dBASE was one of the top selling software titles in the 1980s and early 1990s. 1990s, object-oriented The 1990s, along with a rise in object-oriented programming, saw a growth in how data in various databases were handled. Programmers and designers began to treat the data in their databases as objects. That is to say that if a person's data were in a database, that person's attributes, such as their address, phone number, and age, were now considered to belong to that person instead of being extraneous data. This allows for relations between data to be related to objects and their attributes and not to individual fields.[20] The term "object–relational impedance mismatch" described the inconvenience of translating between programmed objects and database tables. Object databases and object–relational databases attempt to solve this problem by providing an object-oriented language (sometimes as extensions to SQL) that programmers can use as alternative to purely relational SQL. On the programming side, libraries known as object–relational mappings (ORMs) attempt to solve the same problem. 2000s, NoSQL and NewSQL Main articles: NoSQL and NewSQL XML databases are a type of structured document-oriented database that allows querying based on XML document attributes. XML databases are mostly used in applications where the data is conveniently viewed as a collection of documents, with a structure that can vary from the very flexible to the highly rigid: examples include scientific articles, patents, tax filings, and personnel records. NoSQL databases are often very fast, do not require fixed table schemas, avoid join operations by storing denormalized data, and are designed to scale horizontally. In recent years, there has been a strong demand for massively distributed databases with high partition tolerance, but according to the CAP theorem, it is impossible for a distributed system to simultaneously provide consistency, availability, and partition tolerance guarantees. A distributed system can satisfy any two of these guarantees at the same time, but not all three. For that reason, many NoSQL databases are using what is called eventual consistency to provide both availability and partition tolerance guarantees with a reduced level of data consistency. NewSQL is a class of modern relational databases that aims to provide the same scalable performance of NoSQL systems for online transaction processing (read-write) workloads while still using SQL and maintaining the ACID guarantees of a traditional database system. |
1980年代、デスクトップで 1980年代は、デスクトップコンピューティングの時代の幕開けであった。新しいコンピュータは、Lotus 1-2-3のような表計算ソフトやdBASEのようなデータベースソフトでユーザーを強化した。dBASEの製品は軽量で、どんなコンピューターユーザー でもすぐに理解できるものでした。dBASEの生みの親であるC. Wayne Ratliffは次のように述べています。「dBASEはBASIC、C、FORTRAN、COBOLのようなプログラムとは異なり、多くの汚い仕事はす でに行われていました。データ操作はユーザが行うのではなく、dBASEが行うので、ユーザはファイルを開いたり、読んだり、閉じたり、スペースの割り当 てを管理したりといった汚いことに煩わされることなく、自分のしていることに集中できる」[19] dBASEは1980年代から1990年代初頭にかけて最も売れたソフトウェアタイトルの一つであった。 1990年代、オブジェクト指向 1990年代には、オブジェクト指向プログラミングの台頭とともに、さまざまなデータベースのデータの扱い方が拡大した。プログラマーやデザイナーは、 データベースのデータをオブジェクトとして扱うようになった。つまり、ある人のデータがデータベースに入っていた場合、その人の住所、電話番号、年齢と いった属性は、余計なデータではなく、その人に属するものと考えられるようになったのだ。これにより、データ間の関係は、個々のフィールドではなく、オブ ジェクトとその属性に関連付けられるようになった[20]。プログラムされたオブジェクトとデータベースのテーブル間の変換の不都合を「オブジェクト-リ レーショナルインピーダンスミスマッチ」という言葉で表現している。オブジェクトデータベースやオブジェクトリレーショナルデータベースは、プログラマー が純粋なリレーショナルSQLの代替として使えるオブジェクト指向言語（SQLの拡張として使われることもある）を提供することでこの問題を解決しようと するものである。プログラミング側では、オブジェクトリレーショナルマッピング（ORM）と呼ばれるライブラリーが同じ問題を解決しようと試みている。 2000年代、NoSQLとNewSQL 主な記事 NoSQLとNewSQL XMLデータベースは、構造化された文書指向データベースの一種で、XML文書の属性に基づいた問い合わせが可能である。XMLデータベースは、科学論 文、特許、税務申告書、人事記録など、非常に柔軟なものから非常に厳格なものまでさまざまな構造を持つ文書の集合体としてデータを見るのに便利なアプリ ケーションで主に使用されている。 NoSQLデータベースは、非常に高速で、固定的なテーブルスキーマを必要とせず、非正規化されたデータを格納することで結合操作を回避し、水平方向に拡 張できるように設計されていることが多い。 近年、パーティション耐性の高い大規模分散データベースが強く求められていますが、CAP定理によると、分散システムで一貫性、可用性、パーティション耐 性を同時に保証することは不可能とされています。分散システムは、このうち2つの保証を同時に満たすことはできても、3つの保証を同時に満たすことはでき ないのです。そのため、多くのNoSQLデータベースでは、データの一貫性を抑えつつ、可用性とパーティション耐性を両立させるために、最終的な一貫性と 呼ばれる方式が採用されています。 NewSQL は、最新のリレーショナルデータベースの一種で、オンライントランザクション処理（読み書き）のワークロードに対して、NoSQL システムと同じスケーラブルな性能を提供することを目的としながら、SQL を使用し、従来のデータベースシステムの ACID 保証を維持することを目的としています。 |
Links
リンク
Bibliography
Other informations