stanford-oval/wikipedia huggingface dataset:
宮崎県立宮崎商業高等学校
沿革

1919年（大正8年）4月25日 - 「宮崎町立商業学校」（修業年限3年）として設立。98名が入学。
1920年（大正9年）7月21日 - 「宮崎町立宮崎商業学校」（修業年限5年、現在の中1～高2に相当）に改称。
1924年（大正13年）- 宮崎市の発足により「宮崎市立宮崎商業学校」に改称。
1943年（昭和18年）4月1日 - 中等学校令の施行により、この時の入学生から修業年限が4年（現在の中1～高1に相当）となる。
1944年（昭和19年）4月1日 - 県立に移管され「宮崎県立宮崎商業学校 」に改称。
教育ニ関スル戦時非常措置方策により生徒募集が停止される。1年修了者を宮崎県立宮崎工業学校2年次に編入。
2・3・4年修了者はそのまま商業学校3・4・5年生として在籍。
中等学校令の施行される前に入学した生徒（1941年（昭和16年）4月（4年生）および1942年（昭和17年）4月入学生（3年生））にも修業年限4年が適用されるようになる。
1946年（昭和21年）4月1日 - 修業年限が5年に戻る（ただし4年修了時点で卒業することもできた）。
生徒募集を再開。1944年（昭和19年）4月に工業学校に編入した生徒も希望者は商業学校に復学することができた。
1947年（昭和22年）4月1日 - 学制改革が行われる。
旧制商業学校の募集を停止。
新制中学校を併設し（以下・併設中学校）、商業学校1・2年修了者を新制中学校2・3年生として収容。
併設中学校は経過措置としてあくまで暫定的に設置されたため、新たに生徒募集は行われず、在校生が2・3年生のみの中学校であった。
商業学校3・4年生はそのまま商業学校4・5年生として在籍（ただし4年修了時点で卒業することもできた）。
1948年（昭和23年）3月31日 - 学制改革のため閉校。
1941年（昭和16年）4月1日 - 「宮崎市立宮崎第二商業学校」（夜間部）が設置される。
1944年（昭和19年）4月1日 - 県立移管の上、「宮崎県立宮崎第二商業学校 」に改称。
教育ニ関スル戦時非常措置方策により、募集は停止され、在校生は原則として宮崎県立宮崎工業学校の夜間部に切り替えとなった。
1948年（昭和23年）3月31日 - 学制改革のため閉校。
1914年（大正3年）- 宮崎女教舎が設立、後に私立宮崎女学校と改称。
1920年（大正9年）- 私立宮崎家政実科高等女学校となる。
1926年（大正15年）- 江陽高等女学校となる。
1944年（昭和19年）4月1日 - 江陽高等女学校が県立移管の上、「宮崎県立宮崎女子商業学校」に改称。
1948年（昭和23年）3月31日 - 学制改革のため閉校。
1948年（昭和23年）4月1日 - 宮崎市内の県立旧制中等教育学校4校が統合され、新制高等学校「宮崎県立宮崎大宮高等学校 」が発足。
県立旧制中等学校4校 - 宮崎中学校、宮崎第一高等女学校、宮崎商業学校、宮崎女子商業学校
通常制普通課程・商業課程・家庭課程、定時制（夜間部）普通課程、通信教育部が設置される。
4校の併設中学校も統合され、「宮崎県立宮崎大宮高等学校 併設中学校」と称する。
併設中学校の在校生が1946年（昭和21年）に旧制中等学校へ最後に卒業した3年生のみとなる。
1949年（昭和24年）3月31日 - 併設中学校を廃止。
1957年（昭和32年）4月1日 - 宮崎県立宮崎大宮高等学校から商業課程が分離し「宮崎県立宮崎商業高等学校 」（現校名）として独立。
現在地に校舎が完成し移転を完了。1学年あたりの定員を6学級300名とする。
1961年（昭和36年）2月 - 体育館が完成。
1962年（昭和37年）1月 - 図書館が完成。
1965年（昭和40年）4月 - 生徒在籍数が最大の1,485名（各学年9学級、計27学級）を記録。
1968年（昭和43年）4月 - 創立50周年を記念してプールが完成。
1974年（昭和49年）4月1日 - 学科改編を行い、従来の商業科（9学級）を「商業科（5）・情報処理科（2）・経理科（2）」とする。
1975年（昭和50年）3月 - 情報処理科教室・経理科教室が完成。
1979年（昭和54年）3月 - 創立60周年を記入して新体育館が完成。
1989年（平成元年）4月1日 - 学科改編を行い、商業科（3）・国際経済科（2）・情報処理科（2）・経理科（2）とする。
1991年（平成3年）11月27日 - 校訓を制定。
1994年（平成6年）4月1日 - 経理科を会計科に改称。
2005年（平成17年）3月 - 同窓会館「宮商会館」が完成。
2006年（平成18年）4月1日 - 情報処理科を経営情報科に改編。
2007年（平成19年）4月1日 - 会計科を経営科学科に改編。
学校行事

3学期制
8月 - 1日体験入学、宮商クリーン大作戦
9月 - 体育大会
10月 - 久遠祭（文化祭）
12月 - 修学旅行
3月 - 宮商マーケット（販売実習）
部活動

野球部
春の甲子園大会に3回出場 - 1966年（1回戦敗退）・1969年（1回戦敗退） ・2021年（1回戦敗退）
夏の甲子園大会に6回出場 - 1963年（2回戦敗退）・1964年（準決勝進出）・1969年（1回戦敗退）・2008年（2回戦敗退）・2021年（2回戦からの出場が決定したものの、大会開始後新型コロナウイルス感染症のクラスターが判明したことにより試合を辞退し不戦敗）・2024年
陸上競技部
サッカー部
バレーボール部
バスケットボール部
ソフトボール部
テニス部
ソフトテニス部
卓球部
バドミントン部
弓道部
2024年8月に起きた台風10号に伴う竜巻で弓道場の屋根が吹き飛ばされ、更に置いていた弓が割れる等して12張使用不可となる被害に遭う。
空手道部 (廃部)
水泳部
ハンドボール部
漕艇部 (廃部)
カヌー部
ITソリューション部
ワープロ部
簿記部
珠算・電卓部
吹奏楽部
音楽部
箏曲部
演劇部
放送部
写真部
漫画研究部
美術部
書道部
茶道部
華道部
ESS
マーチング部
ビジネス・アクティベート・クラブ
文芸部
ダンス部
著名な出身者

寺岡孝（元プロ野球選手）
高橋博士（元プロ野球選手）
小川亨（元近鉄バファローズのプロ野球選手、現解説者）
水谷実雄（元プロ野球選手）
山本真一（元プロ野球選手）
西井哲夫（元プロ野球選手）
鳥原公二（元プロ野球選手）
赤川克紀（元プロ野球選手）
濱田登（高校野球指導者、2008年には本校野球部監督として夏の甲子園出場に導く）
菊川優希（柔道家）
黒木美晴（柔道家）
大迫明伸（柔道家、全日本柔道連盟強化コーチ）
GO☆マキ（レゲエシンガー、ダンサー、音楽プロデューサー、起業家）
交通

JR九州 日豊本線 「宮崎駅」
宮崎交通 「宮商前」バス停
国道10号
宮崎県道26号宮崎須木線「商業学校前」交差点
周辺

宮崎公立大学
宮崎大学教育文化学部附属小学校・中学校
宮崎市祇園運動広場・祇園スポーツパーク・北部記念体育館
宮崎西地区交流センター
宮崎県中央福祉こどもセンター
宮崎県中央保健所
宮崎和知川原郵便局
大淀川
小戸神社
村上一郎

| --- | --- |
: その他の同名の人物については「村上一郎 (曖昧さ回避)」をご覧ください。
村上 一郎（むらかみ いちろう、1920年（大正9年）9月24日 - 1975年（昭和50年）3月29日）は、日本の文芸評論家、歌人、小説家。日本浪曼派に共感した。
略歴

東京で生まれ、父はホーリネス教会派のクリスチャンだった。栃木県宇都宮市で育つ。旧制宇都宮中学校（現栃木県立宇都宮高等学校）を経て、東京商科大学（現・一橋大学）予科に進学。高島善哉ゼミ出身。
1943年に大学を卒業後、短期現役士官として海軍に入隊。小島直記らは同期生にあたる。主計大尉として終戦を迎える。
戦後は三菱化成（現三菱ケミカルホールディングス）に入社したがやがて退社。また久保栄に師事する。
その後、高島善哉の紹介で日本評論社編集部に入るが、『日本評論』の連載が連合国軍最高司令官総司令部のプレスコードに反し退社した。以後文筆に専念する。
中野重治の一文に感激し日本共産党に入党したがのち脱党した。
1956年、桶谷秀昭らと『典型』を刊行する。のち、1964年から個人雑誌『無名鬼』を刊行する。『無名鬼』には山中智恵子が多く寄稿した。また1961年から、吉本隆明、谷川雁らとともに雑誌『試行』の編集などをしている。のちに『試行』は吉本の単独編集となる。
『北一輝論』は三島由紀夫に高く評価された。二・二六事件を肯定する面では三島と同様か、またそれ以上であるが、三島の二・二六事件観はあくまで忠誠心の発露、至純の精神への感銘にすぎないが、村上はその理念にまで心を及ばせていた。二・二六事件の失敗、滅びを前提にする三島と異なり、二・二六事件がもし成功したら歴史は変わっていたと肯定論を更に進めて考える。三島が生前最後に出した手紙2通のうちの1通が村上一郎宛てであった。
1975年に武蔵野市の自宅で日本刀により頸動脈を切り自殺を遂げた。享年54。墓所は小平市の小平霊園にある。村上の死に際しては思想的立場が大きく異なる丸山眞男からも悔やみの手紙が寄せられた（『磁場』の臨時増刊村上一郎追悼特集号に掲載）。
村上の死後、妻は再婚して、長谷えみ子の名前で人形作家、歌人として活動した。
内田信也（内田汽船設立者）は母方の叔父、窪田四郎（日魯漁業（現マルハニチロ）社長や富士製紙第5代社長等を歴任）は母方の伯父。石野信一（大蔵省事務次官や神戸銀行頭取を歴任）は村上の従兄にあたる。
著作

『私たちの将来・私たちの職業 27　水産と漁業』三十書房、1958
『私たちの将来・私たちの職業 24　鉱山ではたらく人びと』三十書房、1958
『私たちの将来・私たちの職業 22　機械工場』三十書房、1958
『久保栄論』弘文堂、1959　のち三一選書
『東国の人びと 第1部 (阿武隈郷士)』理論社、1959
『東国の人びと 第2部 (天地幽明)』理論社、1959
『私たちの将来・私たちの職業 13　電気・ガス・水道のしごと』三十書房、1959
『私たちの将来・私たちの職業 5.学校研究所ではたらく人びと』三十書房、1959
『人生とはなにか』社会思想社・現代教養文庫、1963
『日本のロゴス』南北社、1963、国文社（増補版）、1970
『世界の思想家たち 人と名言』社会思想社・現代教養文庫、1966、新版1981
『明日を生きよ 若き日の愛と真実』大和書房・銀河選書、1968
『非命の維新者』角川書店・角川新書、1968、のち角川文庫
『幕末 非命の維新者』中公文庫、2017.9。解説渡辺京二
『明治維新の精神過程』春秋社、1968
『浪曼者の魂魄 村上一郎評論集』冬樹社、1969
『北一輝論』三一書房、1970、のち角川文庫
『武蔵野断唱』構造社、1970
『撃攘 村上一郎歌集』思潮社、1971
『志気と感傷』国文社、1971
『草莽論 その精神史的自己検証』大和書房、1972。ちくま学芸文庫、2018.2
『日本軍隊論序説』新人物往来社、1973
『イアリンの歌 評論集』国文社、1974
『萩原朔太郎ノート 抒情と憤怒』国文社、1975
『振りさけ見れば』而立書房、1975
『歌のこころ』冬樹社　1976
『村上一郎著作集』全12巻、国文社、1977-82。吉本隆明・金子兜太・桶谷秀昭監修
『岩波茂雄』砂子屋書房、1982
『岩波茂雄と出版文化　近代日本の教養主義』講談社学術文庫、2013.12、解説竹内洋
共編

『記録文学への招待』杉浦明平共編　南北社　1963
対談

『尚武の心と憤怒の抒情―文化・ネーション・革命』（対：三島由紀夫）
翻訳

カール・ビヤンホフ『星はうすれゆく 失明してゆく少年期の追憶』光文社　1960
須田泰生

須田 泰生（すだ たいき、1994年7月7日 - ）は、元山陰中央テレビジョン放送のアナウンサー（2017年 - 2020年）。
現在はeスポーツキャスターとしてオデッセイに所属している。またゲーム実況アナウンサーとしてYouTubeでも活動している。
来歴・人物

島根県大田市出身。島根県立大田高等学校、同志社大学経済学部経済学科卒業。
2016年12月からCHK京都アナウンススクールに通い、2017年から山陰中央テレビでアナウンサーとして就職し主にニュースを担当した。
2020年9月に山陰中央テレビを退社し、株式会社ODYSSEY に入社。　eスポーツ実況とYouTubeで「アナウンサーYouTuberたいきち」の名前で動画投稿開始する。
妹と弟がいる。AB型。ももいろクローバーZのファンであった。
2022年10月、ドズル社への入社を発表した。
データベース

| --- | --- |
: この項目では、コンピューティング的な概念について説明しています。データベースの実例については「データベースの一覧（英語版）」を、データベースの概要およびトピックガイドについては「データベースの概要（英語版）」をご覧ください。
| --- | --- |
: ウィキペディアにおけるデータベースの利用については、「Wikipedia:データベースダウンロード」をご覧ください。
SQL言語のSELECT文とその実行結果を示す。
コンピューティングにおいて、データベース（英: database）は、電子的に保存され、アクセスできる組織化されたデータの集合である。実メモリに保存されるもの、CSVなどのファイルに保管される物、OSのファイルシステムなどから、後述のデータベース管理システムを使った大規模なものまである。
小規模なデータベースはOSのファイルシステム上にファイルとして保存されるが、大規模なデータベースはOSに依存しない低レベルなフォーマットで外部記憶装置に保存される。またコンピュータ・クラスターまたはクラウドストレージで保存される。データベース設計に関わる分野は多岐にわたり、データモデリング、効率的なデータ表現と保存、クエリ言語、機密データのセキュリティ（英語版）やプライバシー、同時アクセスとフォールトトレランスのサポートを含む分散コンピューティングの課題など、形式技術と実用的な考慮事項に及ぶ。
データベース管理システム（DBMS）は、エンドユーザー、アプリケーション、およびデータベース自体と対話し、データを取得し分析するためのソフトウェアである。さらに、DBMSソフトウェアには、データベースを管理するために提供される関連機能も含まれている。データベース、DBMS、関連アプリケーションの全体を含めてデータベースシステムと呼ぶ。しばしば「データベース」という用語が、DBMS、データベースシステム、またはデータベースに関連するアプリケーションのいずれかを指す場合に漠然と使われている。
コンピュータ科学者は、データベース管理システムを、サポートするデータベースモデルに基づいて分類している。リレーショナルデータベースは、1980年代の主流であった。これらは、データを一連の表の行と列としてモデル化し、大多数はデータの書き込みとクエリ（問い合わせ）にSQLを使用する。2000年代には、異なるクエリ言語を使用する NoSQL と総称される非リレーショナルデータベースが普及した。
用語と概要

形式的な「データベース」は、関連するデータの集合とその編成方法を指す。通常、このデータへのアクセスは、「データベース管理システム」（DBMS）によって提供される。DBMSは、ユーザーが1つまたは複数のデータベースと対話し、データベースに含まれるすべてのデータへのアクセスを提供するコンピュータソフトウェアの統合セットで構成されている（ただし、特定のデータへのアクセスを制限する制約が存在することもある）。DBMSは、大量の情報の入力、保存、および検索を可能にするさまざまな機能を提供し、その情報がどのように編成されているかを管理する方法を提供する。
このように、両者は密接な関係にあるため、「データベース」という用語は、データの集まりとしてのデータベースと、それを操作するために用いるDBMSの両方を指す言葉として気軽に使われることが多い。
情報技術の専門家以外の世界では、「データベース」という用語は、関連するデータの集合体（例: スプレッドシートやカードインデックスなど）を指すことが多く、サイズや使用要件の点からデータベース管理システムを用いることが一般的である。
既存のDBMSは、データベースとそのデータを管理するためのさまざまな機能を提供しており、それらは次の4つの主要な機能群に分類される。
データ定義（Data definition）- データの編成を規定する定義を作成、変更、および削除する。
更新（Update）- 実データを挿入、変更、および削除する。
検索（Retrieval）- 情報を直接利用できる形式で、または他のアプリケーションでさらに処理できる形式で提供する。検索したデータは、基本的にデータベースに保存されているのと同じ形式で利用できる他、データベースの既存のデータを変更または組み合わせて得た新たな形式でも利用することができる。
管理（Administration）- ユーザーの登録と監視、データセキュリティの実施、性能の監視、データ完全性の維持、並行性制御の対応、予期しないシステム障害などの事象によって破損した情報の回復など。
データベースとそのDBMSは共に、特定のデータベースモデルの原則に準拠している。 「データベースシステム」とは、データベースモデル、データベース管理システム、データベースを総称したものである。
物理的には、データベース・サーバーは、実際のデータベースを格納し、DBMSと関連ソフトウェアのみを実行する専用コンピュータである。データベース・サーバーは通常、大容量のメモリと、安定したストレージ（例: RAIDディスクアレイ）を備えたマルチプロセッサ・コンピュータである。大容量のトランザクション処理環境では、複数台のサーバーと高速チャネルを介して接続されたハードウェア・データベース・アクセラレータも使用される。ほとんどのデータベース・アプリケーション（英語版）の中心にDBMSがある。DBMSは、ネットワークのサポートを組み込んだカスタムのマルチタスク・カーネルを中心に構築されることもあるが、最近のDBMSは通常、これらの機能を提供するために、標準的なオペレーティングシステムに依存している[要出典]。
DBMSは重要な市場（英語版）を形成しているため、コンピューターやストレージのベンダーは、自社の開発計画にDBMSの要件を考慮に入れていることが多い。
データベースとDBMSは、サポートするデータベースモデル（リレーショナルやXMLなど）、実行するコンピュータの種類（サーバークラスタから携帯電話まで）、データベースへのアクセスに使用するクエリ言語（SQLやXQueryなど）、内部エンジニアリング（性能、スケーラビリティ、障害許容力、およびセキュリティに影響する）によって分類することができる。
歴史

データベースとそれぞれのDBMSの規模、機能、性能は桁違いに大きくなっている。これらの性能向上は、プロセッサ、コンピュータメモリ、コンピュータストレージ、およびコンピュータネットワークの技術進歩により可能となった。データベースの概念は、1960年代半ばに広く普及した磁気ディスクなどの直接アクセス記憶媒体の出現によって可能となった。それ以前のシステムは、磁気テープへのデータの順次保存に依っていた。その後のデータベース技術の発展は、データモデルまたはデータ構造に基づいて、ナビゲーショナル、SQL/リレーショナル、ポストリレーショナルの3つの時代に分けることができる。
初期のナビゲーショナル・データモデルは、階層型モデルとネットワーク型モデル（CODASYLモデル）の2つが主であった。これらは、あるレコードから別のレコードへの関係を追跡するために、ポインタ（多くの場合、物理的なディスクアドレス）を使用することが特徴であった。
1970年にエドガー・F・コッドが提唱したリレーショナルモデルは、この伝統から脱却するもので、アプリケーションがリンクをたどるのではなく、内容からデータを検索すべきであると主張するものであった。リレーショナルモデルは、元帳型の表の集まりを組み合わせたもので、それぞれの表は異なる種類のエンティティ（実体）を格納する。1980年代半ばになって、コンピューティング・ハードウェアは、リレーショナルシステム（DBMSとアプリケーション）を幅広く普及するのに十分な性能を持つようになった。けれども、1990年代初頭には、すべての大規模なデータ処理アプリケーションにおいてリレーショナルシステムが主流となり、2018年現在も主流であり続けている。IBM Db2、Oracle、MySQL、Microsoft SQL Server、PostgreSQLは、最も検索されているDBMSである。リレーショナルモデル用の主要なデータベース言語である標準SQLは、他のデータモデル用のデータベース言語にも影響を与えた[要出典]。
オブジェクトデータベースは、オブジェクト指向とリレーショナル型とのインピーダンスミスマッチ（相性の欠如）による不便さを解消するために1980年代に開発され、これにより「ポストリレーショナル（post-relational）」という言葉が生まれ、また、ハイブリッド型のオブジェクト・リレーショナルデータベースも開発された。
2000年代後半に登場した、次世代のポスト・リレーショナルデータベースは、高速なキーバリュー型ストアやドキュメント指向データベースを導入し、NoSQLデータベースと呼ばれるようになった。これと競合するNewSQLと呼ばれる次世代データベースは、リレーショナル/SQLモデルを維持しつつ、市販のリレーショナルDBMSと比較してNoSQLの高い性能に見合うような新しい実装を試みている。
歴史 > 1960年代、ナビゲーショナルDBMS

詳細は「ナビゲーショナル・データベース」を参照
データベースという言葉が登場したのは、1960年代半ば以降に、直接アクセスストレージ（ディスクやドラム）が利用できるようになった時期と重なる。この用語は、過去のテープベースのシステムとは対照的に、日常のバッチ処理ではなく、対話的な共有での利用を可能にすることを意味した。オックスフォード英語辞典では、カリフォルニアのSystem Development Corporation（英語版）が1962年に発表した報告書を、特定の技術的な意味で「データベース」という用語を初めて使用したものとして引用している。
コンピュータの速度と機能が向上するに伴い、多くの汎用データベースシステムが登場し、1960年代半ばには多くのこうしたシステムが商用化されるようになった。標準化への関心が高まり、そうした製品の一つであるIntegrated Data Store（IDS）の制作者であるチャールズ・バックマンが、COBOLの作成と標準化を担当したグループCODASYL内にデータベース・タスクグループを設立した。1971年、データベース・タスクグループは、一般に「CODASYLアプローチ」として知られるようになった彼らの標準を提供し、まもなくこのアプローチに基づいた多くの商用製品が市場に参入した。
CODASYLアプローチ方式は、アプリケーションに対し、大規模ネットワーク内に形成された連結データセットを移動する機能を提供した。アプリケーションは、3つの方法のうちのいずれかによってレコードを見つけることができる。
主キーの使用（CALCキーとして知られ、典型的にはハッシュによって実装される）。
あるレコードから別のレコードへの関係（セットと呼ばれる）の移動。
すべてのレコードを順番にスキャンする。
その後のシステムで、B木（B-tree）が追加され、代替アクセス経路を提供するようになった。また、多くのCODASYLデータベースでは、エンドユーザー向けに（ナビゲーション型APIとは異なる）宣言型クエリ言語も追加された。しかし、CODASYLデータベースは複雑で、有用なアプリケーションを作るには多大な訓練と労力を要した。
また、IBMは、1966年に、Information Management System（IMS）として知られる独自のDBMSを持っていた。IMSは、アポロ計画のために作成されたソフトウェアのSystem/360への発展型であった。IMSは一般にCODASYLと概念が似ているが、そのデータナビゲーションのモデルは厳密な階層を使用し、CODASYLのネットワーク型モデルではなかった。どちらの概念も、データへのアクセス方法の観点から、後にナビゲーショナル・データベースと呼ばれるようになった。この用語は、1973年のバックマンのチューリング賞の講演「The Programmer as Navigator」によって広まった。IBMによって、IMSは階層型データベースとして分類されている。IDMSやCincom Systems（英語版）のTOTALデータベースは、ネットワーク型データベースに分類される。2014年現在、IMSは使用されている。
歴史 > 1970年代、リレーショナルDBMS

エドガー・F・コッドは、カリフォルニア州サンノゼにあるIBMの研究室の1つで、主にハードディスクシステムの開発に携わっていた。彼は、CODASYLアプローチのナビゲーションモデルにおいて、特に「検索（search）」機能の欠如に不満を抱いていた。1970年、彼はデータベース構築の新しいアプローチを概説する多くの論文を書き、最終的に画期的な論文「大規模共有データバンクのためのデータのリレーショナルモデル（A Relational Model of Data for Large Shared Data Banks）」に結実させた。
この論文で、彼は大規模なデータベースを保存し、操作するための新しいシステムについて説明した。コッドの考えは、CODASYLのように自由形式のレコードをある種の連結リストに格納するのではなく、データをいくつかの「テーブル」（table、表）として編成し、それぞれのテーブルを異なる種類のエンティティ（entity、実体）に使用することであった。各テーブルは、エンティティの属性を含む固定数の列を含むことになる。各テーブルの1つ以上の列は、テーブルの行を一意に識別するための主キーとして指定され、テーブル間の相互参照には、ディスクアドレスではなく、常にこの主キーが使用された。クエリにおいては、関係論理の数学的体系に基づく一連の操作を用いて、これらのキー関係に基づいてテーブルを結合する（モデルの名前の由来）。データを正規化された一連のテーブル（または関係（relation）、リレーション）に分割することで、各々の「ファクト（fact、事実）」を一度だけ保存するようにし、更新操作を簡略化する。ビュー（view）と呼ばれる仮想的なテーブルは、ユーザーごとに異なる方法でデータを表示することができるが、ビューを直接更新することはできなかった。
コッドは、テーブル、行、列ではなく、関係（relation）、組（tuple）、定義域（domain）という数学用語を使ってモデルを定義した。現在よく知られているこれらの用語は、初期の実装に由来するものである。コッドは後に、実際の実装が、モデルの基礎となった数学的な基礎から逸脱する傾向にあることを批判した。
テーブル間の関係を表すために、ディスクアドレスではなく主キー（ユーザー指向の識別子）を使用したのは、主に2つの動機があった。エンジニアリングの観点からは、費用がかかるデータベースの再編成をすることなく、テーブルの再配置やサイズ変更を可能とした。しかし、コッドは、セマンティクス（意味）の違いにより強い興味を持っていた。明示的な識別子を使用することで、純粋な数学的定義で更新操作を定義することが容易になり、一階述語論理という確立した学問分野の観点でクエリ操作を定義できるようになった。これらの操作は純粋な数学的性質があるため、クエリ最適化の基礎をなす証明可能な正しい方法でクエリを書き換えることが可能となる。テーブル間の接続は明示的ではなくなったが、階層型モデルやネットワーク型モデルと比較して表現力が損なわれることはない。
階層型モデルやネットワーク型モデルでは、レコードが複雑な内部構造を持つことが許容された。たとえば、ある従業員の給与履歴は、従業員レコードの中の「繰り返しグループ」として表わされることがある。リレーショナルモデルでは、正規化の過程によって、そのような内部構造は、論理キーのみで結合された複数のテーブルに保持されたデータで置き換えられた。
たとえば、データベースシステムの一般的な使い方として、ユーザーに関する情報、名前、ログイン情報、さまざまな住所や電話番号を突き止めることがあげられる。ナビゲーショナル方式では、これらのデータはすべて1つの可変長レコード内に格納される。リレーショナル方式では、そのデータは（たとえば）ユーザーテーブル、アドレステーブル、電話番号テーブルに「正規化（normalize）」される。これらの任意のテーブル内には、実際に住所や電話番号が提供された場合のみ、レコードが作成される。
コッドは、（ディスクアドレスではなく）論理的な識別子を使用して行／レコードを識別するだけでなく、アプリケーションが複数のレコードからデータを組み立てる方法も変更した。アプリケーションがリンクを移動して1レコードずつデータを収集することを要求するのではなく、アプリケーションは、宣言型のクエリ言語を使用して（どのようにデータを見つけるかというアクセス経路ではなく）どのようなデータが必要なのかを表現する。データへの効率的なアクセス経路を見つけるのは、アプリケーションのプログラマーではなく、データベース管理システムの責任となった。クエリ最適化（query optimization）と呼ばれるこの過程は、クエリが数学的論理の観点で表現されているという事実に基づいている。
コッドの論文は、バークレー校のユージン・ウォン（英語版）とマイケル・ストーンブレーカーの二人によって着目された。彼らは、地理データベースプロジェクトにすでに割り当てられていた資金と、コードを作成する学生プログラマーを使って、INGRESと呼ばれるプロジェクトを開始した。INGRESは、1973年の初頭に最初のテスト製品を提供し、1979年には一般に広く使用されるようになった。INGRESは、データアクセス（英語版）のためのQUELと呼ばれる「言語（language）」の使用を含め、多くの点でIBM System Rと類似していた。時の経過とともに、INGRESは新しい標準SQLに移行していった。
IBM自身は、リレーショナルモデルのテスト実装であるPRTV（英語版）と、製品版であるBusiness System 12（英語版）の開発を一度行ったが、いずれも現在は廃止されている。Honeywellは、Multics用のMRDS（英語版）を開発したが、現在ではAlphora Dataphor（英語版）とRel（英語版）の2つの新しい実装が存在する。「リレーショナル」と呼ばれる他のDBMSの実装のほとんどは、実際にはSQL DBMSである。
1970年、ミシガン大学は、デイヴィッド・L・チャイルズ（英語版）の集合論的データモデルに基づくMICRO情報管理システム（英語版）の開発を開始した。MICROは、非常に大きなデータセットを管理するために、米国労働省、米国環境保護庁、アルバータ大学、ミシガン大学、ウェイン州立大学の研究者によって使用された。これは、ミシガン・ターミナル・システム（英語版）を使用するIBMメインフレームコンピューター上で稼働した。このシステムは1998年まで稼動し続けた。
歴史 > 統合型アプローチ

詳細は「」を参照
1970年代から1980年代にかけ、ハードウェアとソフトウェアを統合したデータベースシステムの構築が試みられた。その根底にある理念は、このような統合が、より高い性能をより低い費用で提供できるというものである。その例として、IBM System/38、Teradataの初期の製品、およびBritton Lee, Inc.（英語版）のデータベースマシンがあげられる。
また、データベース管理をハードウェアでサポートするアプローチには、ICL（英語版）のCAFS（英語版）アクセラレータという、プログラム可能な検索機能を持つハードウェアディスクコントローラーがあった。しかし、汎用コンピュータの急速な発展と進歩に、データベース専用機が追いつくことができなかったため、長期的にはこれらの取り組みは概して失敗に終わった。こうしたことから、現今のほとんどのデータベースシステムは、汎用ハードウェア上で動作するソフトウェアシステムであり、汎用のコンピュータとデータストレージを使用している。しかし、この着想は今もなお、Netezza（英語版）やOracle （Exadata（英語版））など一部の企業によって特定の用途で追求されている。
歴史 > 1970年代後半、SQL DBMS

1970年代前半、IBMは、System Rとして、コッドの概念に大まかに基づいたプロトタイプシステムの開発を始めた。最初のバージョンは1974年5月に完成し、その後、レコードを構成するすべての要素（一部はオプション）を単一の大きな「チャンク（chunk、塊）」に格納する必要がないように、データを分割できるマルチテーブルシステムに対応する作業が開始された。その後、1978年と1979年にマルチユーザーバージョンが顧客によってテストされ、その時点では標準化されていたクエリ言語SQLが追加されていた[要出典]。コッドのアイデアは、実行可能でCODASYLよりも優れたものとして確立され、IBMがSQL/DSとして知られるSystem Rの真の製品版、そして後にDatabase 2（IBM Db2）を開発することを後押しした。
ラリー・エリソンのOracle Database（以下、Oracle）は、IBMのSystem Rに関する論文を基に、別の系統から出発した。Oracle V1の実装は1978年に完了したが、エリソンが1979年にIBMを打ち負かしたのはOracle Version 2を市場に投入してからであった。
ストーンブレーカーはその後、INGRESからの教訓を応用して、現在はPostgreSQLとして知られている新しいデータベースPostgresを開発した。PostgreSQLは、大域的で基幹的な業務アプリケーションによく使用されている。（.orgや.infoのドメイン名レジストリでは、多くの大企業や金融機関と同様に、これを主要データストアとして使用している）。
スウェーデンでもコッドの論文は読まれ、1970年代半ばにウプサラ大学でMimer SQL（英語版）が開発された。1984年、このプロジェクトは独立した企業に統合された。
1976年に登場した実体関係モデルは、それまでのリレーショナルモデルよりも馴染みのある記述法を重視したもう一つのデータモデルであり、データベース設計で人気を博した。その後、実体-関係構造は、リレーショナルモデルのデータモデリング構造として追加され、両者の違いは無意味なものとなった[要出典]。
歴史 > 1980年代、デスクトップ

1980年代は、デスクトップコンピューティングの時代の到来を告げた。新しいコンピュータは、Lotus 1-2-3のような表計算ソフトやdBASEのようなデータベースソフトで、ユーザーに力をもたらした。dBASE製品は軽量で、コンピューターユーザーは誰でも容易に理解できた。dBASEの作者、ウェイン・ラトリフ（英語版）は次のように述べている。「dBASEは、BASIC、C、FORTRAN、COBOLのようなプログラムとは異なり、多くの汚い仕事はすでに行われている。データ操作はユーザーではなくdBASEが行うので、ユーザーはファイルを開き、読み込み、閉じ、スペース割り当ての管理などの汚い詳細に煩わされることなく、自分のしていることに集中することができる」。dBASEは、1980年代から1990年代初頭にかけて、最も売れたソフトウェアの一つであった。
歴史 > 1990年代、オブジェクト指向

1990年代は、オブジェクト指向プログラミングの台頭とともに、さまざまなデータベース内のデータの扱い方で発展が見られた。プログラマーと設計者は、データベース内のデータをオブジェクトとして扱うようになった。つまり、ある個人のデータがデータベース内にある場合、その人の住所、電話番号、年齢などの特性は外来のデータではなく、その人に属するものと考えられるようになった。これにより、データ間の関係は、個々のフィールドではなく、オブジェクトとその属性に関連付けられる。プログラムされたオブジェクトとデータベースのテーブルとの間の変換の不都合は、「オブジェクト-リレーショナル・インピーダンスミスマッチ」という言葉で表わされる。オブジェクト・データベースやオブジェクト・リレーショナルデータベースは、この問題を解決するために、プログラマーが純粋なリレーショナルSQLの代わりに使用できるオブジェクト指向言語（SQLの拡張機能という場合もある）を提供しようとするものである。プログラミング側の立場では、オブジェクト・リレーショナル・マッピング（ORM）と呼ばれるライブラリで、同じ問題を解決しようとしている
歴史 > 2000年代、NoSQLとNewSQL

詳細は「NoSQL」および「NewSQL」を参照
XMLデータベースは、構造化されたドキュメント指向データベースの一種で、XML文書の属性に基づいたクエリが可能である。XMLデータベースは、たとえば科学論文、特許、税務申告、人事記録など、非常に柔軟なものから非常に厳格なものまで、データをさまざまな構造を持つ文書の集合として見るのに便利なアプリケーションで主に使用される。
NoSQLデータベースは、多くの場合、非常に高速で、固定化したテーブルスキーマを必要とせず、非正規化（英語版）したデータを格納することで結合操作を回避し、水平スケーリングするように設計されている。
近年、高い分断耐性を備えた大規模分散データベースが強く求められているが、CAP定理によれば、分散システムで一貫性、可用性、分断耐性を同時に備えることは不可能とされている。分散システムは、これら3つの保証のうち、いずれか2つを同時に満たすことはできても、3つすべてを満たすことはできない。そのため、多くのNoSQLデータベースでは、データ整合性のレベルを下げて可用性と分断耐性の両方を保証する、結果整合性という考え方を採用している。
最新のリレーショナルデータベースの一種であるNewSQLは、SQLを使用し、また従来のデータベースシステムのACID保証を維持しながらも、オンライントランザクション処理のワークロード（読み込みと書き込みの両方を伴う）に対して、NoSQLシステムと同じスケーラブルな性能を提供することを目的としている。
使用例

データベースは、組織の内部業務を支援し、顧客や発注先とのオンラインでのやり取りを支えるために使用される（エンタープライズ・ソフトウェアを参照）。
データベースは、業務における管理情報、エンジニアリングデータや経済モデルなどのより専門的なデータを保持するためにも使用される。たとえば、コンピュータによる図書館システム、航空座席予約システム、コンピュータ化された部品在庫管理システム、およびウェブサイトをウェブページの集合としてデータベースに保存する多くのコンテンツ管理システムなどがあげられる。
データベース管理システム

ConnollyとBeggは、データベース管理システム（DBMS）を「ユーザーがデータベースを定義、作成、保守、およびアクセスを制御できるようにするソフトウェアシステム」と定義している。DBMSの例として、MySQL、PostgreSQL、Microsoft SQL Server、Oracle Database、Microsoft Accessがあげられる。
DBMSの頭文字は、基盤となるデータベースモデルを示して拡張されることがあり、リレーショナル型はRDBMS、オブジェクト(指向)型（英語版）はOODBMS、オブジェクトリレーショナル型はORDBMSと呼ばれる。また、分散型データベース管理システムを表すDDBMSなど、他の特性を表すように拡張することができる。
DBMSが提供する機能は非常に多様である。中心的な機能は、データの保存、検索、更新である。コッドは、本格的な汎用DBMSが提供すべき機能およびサービスとして、次のようなものを提案した。
データの保存、検索、更新
メタデータを記述した、ユーザーがアクセス可能なカタログまたはデータディクショナリ
トランザクションと並行処理のサポート
データベースが破損した場合に復旧するための機能
データへのアクセス時および更新時の承認のサポート
遠隔地からのアクセスサポート
データベース内のデータが特定の規則に従うことを保証するための制約の適用
また、DBMS は、インポート、エクスポート、監視、デフラグメント、分析ユーティリティなど、データベースを効果的に管理するために必要な一連のユーティリティを提供することも、一般に期待されている。データベースとアプリケーション・インターフェースの間で相互作用するDBMSの中心部分は、データベース・エンジンと呼ばれることもある。
多くのDBMSは、データベースが使用できるサーバ上のメインメモリの最大量など、静的または動的に調整可能な構成パラメータを持っている。手動構成する量を最小限に抑える傾向があり、組み込みデータベース（英語版）のような場合は、ゼロ管理を目標とする要求が最も重要である。
大規模なエンタープライズDBMSでは、サイズや機能が増大する傾向があり、その生涯を通じて数千人年の開発努力が費やされることがある。
初期のマルチユーザーDBMSでは、一般的に、アプリケーションを同じコンピュータ上で動作させ、コンピュータ端末または端末エミュレーションソフトウェアを通じてアクセスすることしかできなかった。クライアント・サーバー・アーキテクチャは、アプリケーションはクライアントのデスクトップ上にあり、サーバー上に存在するデータベースが処理を分散できるように開発された。これが進化して、アプリケーションサーバやWebサーバを組み込んだ多層アーキテクチャとなり、エンドユーザーインターフェイスはウェブブラウザを介してアクセスし、データベースは隣接する層に直接接続されるのみとなった。
汎用DBMSは、公開のアプリケーションプログラミングインタフェース（API）と、オプションでSQLなどのデータベース言語用のプロセッサを提供して、データベースと対話し操作するアプリケーションを作成できるようにする。特殊用途のDBMSは、プライベートなAPIを使用し、特別にカスタマイズして単一のアプリケーションにリンクされることがある。たとえば、電子メールシステムは、メッセージの挿入、削除、添付ファイルの処理、ブロックリストの検索、メッセージと電子メールアドレスの関連付けなど、汎用DBMSの機能の多くを実行するが、これらの機能は電子メールの処理に必要なものに限定されている。
アプリケーション

詳細は「」を参照
データベースとの外部相互作用は、DBMSと接続するアプリケーション・プログラムを介して行われる。アプリケーションは、ユーザーが文字的または視覚的にSQLクエリを実行できるデータベースツールから、情報を格納し検索するためにデータベースを使用するWebサイトまで、多岐にわたる。
アプリケーション > アプリケーションプログラムインタフェース（API）

プログラマーは、アプリケーションプログラミングインタフェース（API）またはデータベース言語を介して、データベース（データソース（英語版）と呼ばれることもある）との相互対話をコーディングする。選択された特定のAPIや言語は、DBMSによって直接的にサポートされるか、またはプリプロセッサまたはブリッジングAPIを介して間接的にサポートされる必要がある。APIの中にはデータベースに依存しないことを目的とするものもあり、ODBCはそのよく知られた例である。その他の一般的なAPIには、JDBCやADO.NETがある。
データベース言語

データベース言語は、次のような作業を可能とする特殊用途の言語であり、部分言語（英語版）として区別されることもある。
データ制御言語（DCL）- データへのアクセスを制御する。
データ定義言語（DDL）- テーブルの作成、変更、削除などのデータ型の定義や、テーブル間の関係を定義する。
データ操作言語（DML）- 発生データの挿入、更新、削除などの作業を実行する。
データ問い合わせ言語（英語版）（DQL）- 情報を検索し、派生情報を導出できる。
データベース言語は、特定のデータモデルに特化した言語である。著名な例として次のものがある。
SQLは、データ定義、データ操作、およびクエリ（問い合わせ）の役割を1つの言語で兼ね備えたものである。SQLは、コッドによって説明されたリレーショナルモデルとはからいくつかの点で異なっているが（たとえば、テーブルの行と列を並び替えることができる）、リレーショナルモデルの最初の商用言語の1つである。SQLは1986年に米国規格協会（ANSI）標準となり、1987年に国際標準化機構（ISO）標準となった。この標準はそれ以降も定期的に強化されており、すべての主流の商用リレーショナルDBMSによってサポートされている（適合性の程度はさまざまである）。
OQLは、オブジェクトモデル言語標準である（Object Data Management Groupによる）。これは、JDOQLやEJB QL（英語版）などの新しいクエリ言語の設計に影響を与えている。
XQueryは、MarkLogic（英語版）やeXist（英語版）などのXMLデータベースシステム、OracleやDb2などのXML機能を備えたリレーショナルデータベース、およびSaxonなどのインメモリXMLプロセッサで実装された標準のXMLクエリ言語である。
SQL/XML（英語版）は、XQueryとSQLを組み合わせたものである。
データベース言語には、次のような機能を組み込んでいるものもある。
DBMS固有の構成やストレージエンジンの管理。
クエリ結果を変更するための計算。たとえば、カウント、合計、平均、並び替え、グループ化、クロスリファレンス。
制約の適用（例: 自動車データベースでは、1台の車ごとに1種類のエンジンのみ許可される）。
プログラマーの便宜のために、クエリ言語のアプリケーションプログラミングインタフェース版。
ストレージ

詳細は「記憶装置」および「データベースエンジン」を参照
データベースストレージは、データベースの物理的な実体の格納庫である。これは、データベースアーキテクチャの「内部（物理）レベル」を構成する。また、必要に応じて「内部レベル」から「概念レベル」や「外部レベル」を再構築するために必要なすべての情報（たとえばメタデータ、「データに関するデータ」、内部データ構造など）も含んでいる。デジタル・オブジェクトとしてのデータベースには、データ、構造、セマンティクス（意味）の3つの層からなる情報が含まれ、保存する必要がある。長期間に渡ってデータベースを保存し、長持ちさせるために、3つの層すべてを適切に保存する必要がある。データを永続的ストレージに保存するのは、一般に、データベースエンジン（別名「ストレージエンジン」）の責任である。DBMSは通常、基盤となるオペレーティングシステムを通じてアクセスするが（多くの場合、オペレーティングシステムのファイルシステムを、ストレージ配置の仲介役として使用する）、ストレージの特性と構成設定はDBMSの効率的な運用に極めて重要であるため、データベース管理者によって密接に管理される。DBMSは、その運用中に、常に数種類のストレージ（メモリや外部ストレージ）にデータベースを常駐させている。データベースのデータと、追加の必要な情報（おそらく非常に大量にある）は、ビット列に符号化される。データは通常、概念レベルや外部レベルでの見え方とは全く異なる構造でストレージ内に存在するが、ユーザーやプログラムが必要とするとき、または必要な情報の追加形式をデータから計算するとき（例: データベースに問い合わせる時）、これらのレベルの再構築を（可能な限り）最適化するような方法で格納される。
DBMSの中には、データの格納に用いる文字エンコーディングを指定できるものがあり、同じデータベースで複数のエンコーディングを使用することができる。
データモデルをシリアル化し、選ばれた媒体に書き込めるようにするために、ストレージエンジンは、さまざまな低レベルのデータベースストレージ構造（英語版）を使用する。性能を向上させるために、インデックス作成などの手法を使用することもある。従来のストレージは行指向であるが、列指向データベースや相関データベース (en:英語版) もある。
ストレージ > マテリアライズド・ビュー

詳細は「マテリアライズド・ビュー」を参照
性能を向上させるためにストレージを冗長化することがよくある。一般的な例は、頻繁に必要とされる外部ビュー（external view）や、クエリ結果から構成されるマテリアライズド・ビュー（materialized view）の保存である。このようなビューを保存することで、必要になるたびに計算する費用を節約することができる。マテリアライズド・ビューの欠点は、元の更新されたデータベースデータと同期を維持するためにビューを更新する際に発生するオーバーヘッドと、ストレージの冗長化にかかる費用である。
ストレージ > レプリケーション

詳細は「データベースレプリケーション」を参照
データベースは、データの可用性を向上させるために、データベース・オブジェクトの複製（1つ以上のレプリケーション）によるストレージ冗長性を採用することがある。これによって、同じデータベース・オブジェクトに複数のエンドユーザーが同時アクセスした場合の性能を向上させ、また、分散データベースに部分的な障害が発生した場合の回復力を提供する。複製されたオブジェクトの更新には、オブジェクトのコピー間で同期される必要がある。多くの場合、データベース全体が複製される。
セキュリティ

詳細は「」を参照
データベース・セキュリティ（英語版）は、データベースの内容、その所有者、およびそのユーザーを保護するためのあらゆる側面を扱う。その範囲は、意図的な不正なデータベースの使用から、権限のないエンティティ（たとえば、人やコンピュータプログラムなど）による意図しないデータベースへのアクセスまで、さまざまな保護に及ぶ。
データベースアクセス制御は、データベース内のどの情報に誰が（人間または特定のコンピュータプログラム）アクセスを許可されるかを制御することを扱う。その情報には、特定のデータベースオブジェクト（例: レコード種類、特定レコード、データ構造）、特定のオブジェクトに対する特定の計算（例: クエリ種類、特定のクエリ）、または前者に対する特定のアクセス経路の使用（例: 情報にアクセスするために特定のインデックスまたは他のデータ構造の使用）が含まれる。データベースのアクセス制御は、データベース所有者から特別に許可された人員によって、保護された専用のセキュリティDBMSインターフェースを用いて設定される。
アクセス制御の管理は、個人別に直接行うことも、個人と特権（英語版）をグループに割り当てることも、（最も精巧なモデルでは）個人やグループにロール（役割）を割り当ててからロールに権限を付与することもできる。データセキュリティは、権限のないユーザーによるデータベースの閲覧や更新を阻止する。パスワードを使用すると、ユーザーはデータベース全体、または「サブスキーマ」と呼ばれる一部分へのアクセスを許可される。たとえば、従業員データベースには個々の従業員に関するすべてのデータを含めていても、あるグループのユーザーには給与データのみの閲覧を許可し、別のグループには職歴と医療データのみアクセスを許可することが可能である。DBMSがデータベースの入力、更新、問い合わせを対話的に行う方法を提供している場合、この機能によって個人データベースを管理することができる。
一般にデータセキュリティ（英語版）は、特定のデータチャンク（data chunk、塊）を物理的に保護すること（すなわち破損、破壊、削除から。物理的セキュリティ（英語版）を参照）、または、データチャンクやその一部を意味のある情報に変換すること（例: それらが構成するビット列を見て、特定の有効なクレジットカード番号を決定する。データ暗号化を参照）の両方を扱う。
変更およびアクセスのロギングは、誰がどの属性にアクセスしたか、何が変更されたか、そしていつ変更されたかを記録する。ロギングサービスは、アクセスの発生や変更の記録を保持することで、後でフォレンジックデータベース監査（英語版）を行うことを可能にする。場合によっては、データベースレベルで記録するのではなく、アプリケーションレベルのコードで変更を記録することもある。セキュリティ違反の検出を試みるために監視を設定することもできる。データベース・セキュリティには多くの利点があるため、組織はこれに真剣に取り組む必要がある。組織は、ファイアウォール内への侵入、ウィルスの蔓延、ランサムウェアなどのセキュリティ違反やハッキング行為から守られる。これは、企業において、いかなる理由があっても部外者と共有することが許されない、重要な情報を保護するために役に立つ。
トランザクションと同時平行

詳細は「並行性制御」を参照
データベース・トランザクションは、クラッシュ（障害）からの復旧後に、ある程度の耐障害性とデータ完全性を導入するために使用することができる。データベーストランザクションは通常、データベースに対する一連の操作（データベースオブジェクトの読み込み、書き込み、ロック（英語版）の取得や解放など）をカプセル化した作業の単位であり、データベースやその他のシステムでサポートされている抽象概念である。各トランザクションには、どのプログラム／コードの実行がそのトランザクションに含まれるかという点で、明確に定義された境界がある（トランザクションの設計者が、特別なトランザクションコマンドで決定する）。
ACIDという頭字語は、データベーストランザクションの理想的な特性である、原子性（atomicity）、一貫性（consistency）、分離性（isolation）、永続性（英語版）（durability）を表している。
移行

「データ移行#データベース移行」も参照
あるDBMSで構築されたデータベースは、別のDBMSに移植できない（つまり、別のDBMSでは実行できない）。しかし、状況によっては、あるDBMSから別のDBMSにデータベースを移行（database migration）するのが望ましい場合がある。その理由は、主に経済的（DBMS によって総所有コスト（TCO）が異なる）、機能的、および運用的（DBMSによって機能が異なることがある）である。移行には、あるDBMSの種類から別の種類へデータベースを変換することも含まれる。この変換では、（可能であれば）データベース関連のアプリケーション（つまり、関連するすべてのアプリケーションプログラム）をそのまま維持する必要がある。したがって、データベースの概念レベルおよび外部レベルのアーキテクチャ（英語版）は、変換時に維持する必要がある。また、アーキテクチャの内部レベルのいくつかの側面も維持されることが望まれる場合もある。複雑または大規模なデータベースの移行は、それ自体が複雑で費用のかかる（1度きりの）プロジェクトになる可能性があるので、移行を決定するときはその点を考慮する必要がある。これは、特定のDBMS間の移行を支援するツールが存在する可能性があるのにも関わらない。一般に、DBMSベンダーは、他の普及しているDBMSからデータベースをインポートするツールを提供している。