База данных - Database

Оператор выбора SQL и его результат.

А база данных это организованная коллекция данные, обычно хранятся и доступны в электронном виде из компьютерной системы. Там, где базы данных более сложные, они часто разрабатываются с использованием формальных дизайн и моделирование техники.

В система управления базами данных (СУБД) - это программного обеспечения который взаимодействует с конечные пользователи, приложения и сама база данных для сбора и анализа данных. Программное обеспечение СУБД дополнительно включает в себя основные средства, предоставляемые для администрирования базы данных. Совокупность базы данных, СУБД и связанных приложений может быть названа «системой баз данных». Часто термин «база данных» также используется для общего обозначения любой СУБД, системы базы данных или приложения, связанного с базой данных.

Ученые-информатики могут классифицировать системы управления базами данных в соответствии с модели базы данных что они поддерживают. Реляционные базы данных стал доминирующим в 1980-х. Эти данные модели как ряды и столбцы в серии столы, и подавляющее большинство используют SQL для записи и запроса данных. В 2000-х годах стали популярными нереляционные базы данных, известные как NoSQL потому что они используют разные языки запросов.

Терминология и обзор

Формально «база данных» относится к набору связанных данных и способу их организации. Доступ к этим данным обычно обеспечивается «системой управления базами данных» (СУБД), состоящей из интегрированного набора компьютерного программного обеспечения, которое позволяет пользователи для взаимодействия с одной или несколькими базами данных и обеспечения доступа ко всем данным, содержащимся в базе данных (хотя могут существовать ограничения, ограничивающие доступ к определенным данным). СУБД предоставляет различные функции, позволяющие ввод, хранение и поиск больших объемов информации, а также способы управления организацией этой информации.

Из-за тесной взаимосвязи между ними термин «база данных» часто используется случайно для обозначения как базы данных, так и СУБД, используемой для управления ею.

За пределами профессионального мира информационные технологии, период, термин база данных часто используется для обозначения любого набора связанных данных (например, электронная таблица или картотека), поскольку требования к размеру и использованию обычно требуют использования системы управления базами данных.[1]

Существующие СУБД предоставляют различные функции, позволяющие управлять базой данных и ее данными, которые можно разделить на четыре основные функциональные группы:

  • Определение данных - Создание, изменение и удаление определений, определяющих организацию данных.
  • Обновлять - Вставка, изменение и удаление фактических данных.[2]
  • поиск - Предоставление информации в форме, пригодной для непосредственного использования или для дальнейшей обработки другими приложениями. Извлеченные данные могут быть доступны в форме, в основном такой же, как они хранятся в базе данных, или в новой форме, полученной путем изменения или объединения существующих данных из базы данных.[3]
  • Администрация - Регистрация и мониторинг пользователей, обеспечение безопасности данных, мониторинг производительности, поддержание целостности данных, работа с контролем параллелизма и восстановление информации, которая была повреждена в результате какого-либо события, например, неожиданного сбоя системы.[4]

И база данных, и ее СУБД соответствуют принципам конкретной модель базы данных.[5] «Система базы данных» означает модель базы данных, систему управления базой данных и базу данных.[6]

Физически база данных серверы представляют собой выделенные компьютеры, на которых хранятся фактические базы данных и работают только СУБД и соответствующее программное обеспечение. Серверы баз данных обычно мультипроцессор компьютеры с большой памятью и RAID дисковые массивы, используемые для стабильного хранения. Аппаратные ускорители баз данных, подключенные к одному или нескольким серверам через высокоскоростной канал, также используются в средах обработки больших объемов транзакций. СУБД лежат в основе большинства приложения базы данных. СУБД могут быть построены на основе пользовательских многозадачность ядро со встроенным сеть поддержки, но современные СУБД обычно полагаются на стандартные Операционная система для обеспечения этих функций.[нужна цитата ]

Поскольку СУБД составляют значительную рынок, поставщики компьютеров и хранилищ часто учитывают требования СУБД в своих планах развития.[7]

Базы данных и СУБД можно разделить на категории в соответствии с поддерживаемыми ими моделями баз данных (например, реляционными или XML), типами компьютеров, на которых они работают (от кластера серверов до мобильного телефона), язык запросов (s) используется для доступа к базе данных (например, SQL или XQuery ) и их внутренняя инженерия, влияющая на производительность, масштабируемость, устойчивость и безопасность.

История

Размеры, возможности и производительность баз данных и соответствующих СУБД выросли на порядки. Такое повышение производительности стало возможным благодаря технологическому прогрессу в областях процессоры, память компьютера, компьютерное хранилище, и компьютерная сеть. Концепция базы данных стала возможной благодаря появлению носителей с прямым доступом, таких как магнитные диски, которые стали широко доступны в середине 1960-х годов; более ранние системы полагались на последовательное хранение данных на магнитной ленте. Дальнейшее развитие технологии баз данных можно разделить на три эпохи в зависимости от модели или структуры данных: навигационный,[8] SQL /реляционный, и пост-реляционный.

Две основные ранние модели навигационных данных были иерархическая модель и КОДАСИЛ модель (сетевая модель ). Для них характерно использование указателей (часто адресов физических дисков) для отслеживания отношений от одной записи к другой.

В реляционная модель, впервые предложенный в 1970 г. Эдгар Ф. Кодд, отошел от этой традиции, настаивая на том, что приложения должны искать данные по содержанию, а не по ссылкам. В реляционной модели используются наборы таблиц в стиле бухгалтерской книги, каждая из которых используется для разных типов объектов. Только в середине 1980-х годов вычислительное оборудование стало достаточно мощным, чтобы позволить широкое развертывание реляционных систем (СУБД плюс приложения). Однако к началу 1990-х реляционные системы доминировали во всех крупных обработка данных приложений, а по состоянию на 2018 год они остаются доминирующими: IBM DB2, Oracle, MySQL, и Microsoft SQL Server самые популярные СУБД.[9] Доминирующий язык баз данных, стандартизованный SQL для реляционной модели, повлиял на языки баз данных для других моделей данных.[нужна цитата ]

Объектные базы данных были разработаны в 1980-х годах, чтобы преодолеть неудобства объектно-относительное рассогласование импеданса, что привело к появлению термина "пост-реляционный", а также к развитию гибридных объектно-реляционные базы данных.

Следующее поколение постреляционных баз данных в конце 2000-х годов стало известно как NoSQL базы данных, быстрое внедрение хранилища ключей и значений и документно-ориентированные базы данных. Конкурирующее «следующее поколение», известное как NewSQL Базы данных пытались реализовать новые реализации, которые сохранили реляционную модель / модель SQL, стремясь при этом обеспечить высокую производительность NoSQL по сравнению с коммерчески доступными реляционными СУБД.

1960-е, навигационная СУБД

Дальнейшая информация: Навигационная база данных
Базовая структура навигационного КОДАСИЛ модель базы данных

Введение термина база данных совпало с появлением устройств хранения с прямым доступом (диски и барабаны) с середины 1960-х годов. Термин представляет собой контраст с ленточными системами прошлого, позволяя совместное интерактивное использование, а не ежедневное. пакетная обработка. В Оксфордский словарь английского языка цитирует отчет 1962 года Калифорнийской корпорации развития систем как первый, кто использовал термин «база данных» в конкретном техническом смысле.[10]

По мере того как скорость и возможности компьютеров росли, появилось несколько систем баз данных общего назначения; к середине 1960-х годов ряд таких систем вошел в коммерческое использование. Интерес к стандарту начал расти, и Чарльз Бахман, автор одного из таких продуктов, Интегрированное хранилище данных (IDS), основал рабочую группу по базам данных в КОДАСИЛ, группа, ответственная за создание и стандартизацию КОБОЛ. В 1971 году рабочая группа по базам данных представила свой стандарт, который стал известен как CODASYL подход, и вскоре на рынок вышел ряд коммерческих продуктов, основанных на этом подходе.

Подход CODASYL предлагал приложениям возможность перемещаться по связанному набору данных, который был сформирован в большую сеть. Приложения могут находить записи одним из трех способов:

  1. Использование первичного ключа (известного как ключ CALC, обычно реализуемого хеширование )
  2. Навигация по отношениям (называется наборы) от одной записи к другой
  3. Сканирование всех записей в последовательном порядке

Добавлены более поздние системы B-деревья чтобы предоставить альтернативные пути доступа. Многие базы данных CODASYL также добавили декларативный язык запросов для конечных пользователей (в отличие от навигационного API). Однако базы данных CODASYL были сложными и требовали значительного обучения и усилий для создания полезных приложений.

IBM также была собственная СУБД в 1966 году, известная как Система управления информацией (IMS). IMS была разработкой программного обеспечения, написанного для Программа Аполлон на Система / 360. IMS в целом была похожа по концепции на CODASYL, но использовала строгую иерархию для своей модели навигации по данным вместо сетевой модели CODASYL. Обе концепции позже стали известны как навигационные базы данных из-за способа доступа к данным: термин был популяризирован Бахманом в 1973 г. Премия Тьюринга презентация Программист как навигатор. IMS классифицируется IBM как иерархическая база данных. IDMS и Cincom Systems ' ОБЩИЙ базы данных относятся к сетевым базам данных. IMS продолжает использоваться с 2014 г..[11]

1970-е годы, реляционная СУБД

Эдгар Ф. Кодд работал в IBM в Сан-Хосе, Калифорния, в одном из дочерних офисов, который в первую очередь участвовал в разработке жесткий диск системы. Он был недоволен навигационной моделью подхода CODASYL, особенно отсутствием «поискового» средства. В 1970 году он написал ряд статей, в которых изложил новый подход к построению базы данных, который в конечном итоге привел к новаторскому Реляционная модель данных для больших общих банков данных.[12]

В этой статье он описал новую систему для хранения больших баз данных и работы с ними. Вместо того, чтобы хранить записи в каком-то связанный список записей в свободной форме, как в CODASYL, идея Кодда заключалась в том, чтобы организовать данные в виде числа "столы ", каждая таблица используется для отдельного типа объекта. Каждая таблица будет содержать фиксированное количество столбцов, содержащих атрибуты объекта. Один или несколько столбцов каждой таблицы были обозначены как первичный ключ по которому можно было однозначно идентифицировать строки таблицы; при перекрестных ссылках между таблицами всегда использовались эти первичные ключи, а не адреса дисков, и запросы могли объединять таблицы на основе этих ключевых отношений, используя набор операций, основанный на математической системе реляционное исчисление (отсюда и название модели). Разделение данных на набор нормализованных таблиц (или связи), чтобы гарантировать, что каждый «факт» сохраняется только один раз, что упрощает операции обновления. Виртуальные столы называются взгляды может представлять данные по-разному для разных пользователей, но представления нельзя обновлять напрямую.

Кодд использовал математические термины для определения модели: отношения, кортежи и домены, а не таблицы, строки и столбцы. Привычная терминология пришла из ранних реализаций. Позже Кодд критиковал тенденцию практических реализаций отходить от математических основ, на которых была основана модель.

в реляционная модель, записи «связаны» с использованием виртуальных ключей, которые не хранятся в базе данных, но при необходимости определены между данными, содержащимися в записях.

Использование первичных ключей (ориентированных на пользователя идентификаторов) для представления взаимосвязей между таблицами, а не дисковых адресов, имело две основные причины. С инженерной точки зрения это позволило перемещать таблицы и изменять их размер без дорогостоящей реорганизации базы данных. Но Кодда больше интересовала разница в семантике: использование явных идентификаторов упростило определение операций обновления с чистыми математическими определениями, а также позволило определить операции запроса в терминах установленной дисциплины исчисления предикатов первого порядка; Поскольку эти операции имеют чистые математические свойства, становится возможным переписывать запросы доказуемо правильными способами, что является основой оптимизации запросов. Нет потери выразительности по сравнению с иерархической или сетевой моделями, хотя связи между таблицами уже не столь явны.

В иерархической и сетевой моделях записи могли иметь сложную внутреннюю структуру. Например, история заработной платы сотрудника может быть представлена ​​как «повторяющаяся группа» в записи сотрудника. В реляционной модели процесс нормализации привел к замене таких внутренних структур данными, хранящимися в нескольких таблицах, связанных только логическими ключами.

Например, обычным использованием системы баз данных является отслеживание информации о пользователях, их имени, информации для входа в систему, различных адресах и телефонных номерах. При навигационном подходе все эти данные будут помещены в одну запись переменной длины. При реляционном подходе данные будут нормализованный в таблицу пользователей, таблицу адресов и таблицу номеров телефонов (например). Записи в этих дополнительных таблицах будут создаваться только в том случае, если адрес или номера телефонов действительно были предоставлены.

Помимо идентификации строк / записей с помощью логических идентификаторов, а не адресов дисков, Кодд изменил способ, которым приложения собирают данные из нескольких записей. Вместо того, чтобы требовать от приложений сбора данных по одной записи, переходя по ссылкам, они будут использовать декларативный язык запросов, который выражает, какие данные требуются, а не путь доступа, по которому они должны быть найдены. Поиск эффективного пути доступа к данным стал обязанностью системы управления базами данных, а не разработчика приложений. Этот процесс, называемый оптимизацией запросов, зависел от того, что запросы были выражены в терминах математической логики.

Газету Кодда подобрали два человека в Беркли: Юджин Вонг и Майкл Стоунбрейкер. Они начали проект, известный как ИНГРЕС используя финансирование, которое уже было выделено для проекта географической базы данных, и студентов-программистов для создания кода. Начиная с 1973 года, INGRES представила свои первые тестовые продукты, которые в целом были готовы к широкому использованию в 1979 году. INGRES был похож на Система R различными способами, включая использование «языка» для доступ к данным, известный как QUEL. Со временем INGRES перешла на новый стандарт SQL.

Сама IBM провела одну тестовую реализацию реляционной модели, PRTV, и производственный, Бизнес-система 12, оба сейчас сняты с производства. Honeywell написал MRDS за Мультики, и теперь есть две новые реализации: Альфора Датафор и Rel. Большинство других реализаций СУБД, обычно называемых реляционный фактически являются СУБД SQL.

В 1970 году Мичиганский университет начал разработку Система управления информацией MICRO[13] на основе D.L. Дети 'Теоретико-множественная модель данных.[14][15][16] MICRO использовался для управления очень большими наборами данных Министерство труда США, то Агентство по охране окружающей среды США, и исследователи из Университет Альберты, то университет Мичигана, и Государственный университет Уэйна. Он работал на мэйнфреймах IBM с использованием Терминальная система Мичигана.[17] Система оставалась в производстве до 1998 года.

Комплексный подход

Основная статья: Машина базы данных

В 1970-х и 1980-х годах были предприняты попытки построить системы баз данных с интегрированным аппаратным и программным обеспечением. Основная философия заключалась в том, что такая интеграция обеспечит более высокую производительность при более низких затратах. Примерами были IBM Система / 38, раннее предложение Терадата, а Бриттон Ли, Inc. машина базы данных.

Другой подход к аппаратной поддержке управления базами данных был ICL с CAFS акселератор, аппаратный контроллер диска с возможностью программирования. В долгосрочной перспективе эти усилия, как правило, не увенчались успехом, поскольку специализированные машины баз данных не могли идти в ногу с быстрым развитием и прогрессом компьютеров общего назначения. Таким образом, большинство систем баз данных в настоящее время представляют собой программные системы, работающие на аппаратном обеспечении общего назначения, использующие компьютерные хранилища данных общего назначения. Тем не менее, эта идея по-прежнему используется для некоторых приложений некоторыми компаниями, такими как Netezza и Oracle (Exadata ).

Конец 1970-х, СУБД SQL

IBM начала работу над прототипом системы, основанной на концепциях Кодда как Система R в начале 1970-х гг. Первая версия была готова в 1974/5, и затем началась работа над многотабличными системами, в которых данные можно было разделить так, чтобы все данные для записи (некоторые из которых не являются обязательными) не нужно было хранить в одиночный большой «кусок». Последующие многопользовательские версии были протестированы заказчиками в 1978 и 1979 годах, к тому времени стандартизованный язык запросов - SQL[нужна цитата ] - добавлено. Идеи Кодда зарекомендовали себя как работоспособные и превзошли CODASYL, что подтолкнуло IBM к разработке настоящей производственной версии System R, известной как SQL / DS, и позже, База данных 2 (DB2 ).

Ларри Эллисон Oracle Database (или, проще говоря, Oracle ) началось с другой цепочки, основанной на документах IBM о System R. Хотя реализация Oracle V1 была завершена в 1978 году, только в Oracle Version 2 Эллисон победил IBM на рынке в 1979 году.[18]

Stonebraker продолжил применять уроки INGRES для разработки новой базы данных Postgres, которая теперь известна как PostgreSQL. PostgreSQL часто используется для глобальных критически важных приложений (реестры доменных имен .org и .info используют его в качестве основного хранилище данных, как и многие крупные компании и финансовые учреждения).

В Швеции также прочитали статью Кодда и Mimer SQL был разработан с середины 1970-х годов на Уппсальский университет. В 1984 году этот проект был объединен в самостоятельное предприятие.

Другая модель данных, модель сущность – связь, возникла в 1976 г. и завоевала популярность благодаря дизайн базы данных поскольку в нем подчеркивается более знакомое описание, чем в более ранней реляционной модели. Позже конструкции сущность – связь были модернизированы как моделирование данных построить для реляционной модели, и разница между ними стала несущественной.[нужна цитата ]

1980-е, на рабочем столе

1980-е годы стали началом эпохи настольные компьютеры. Новые компьютеры предоставили своим пользователям такие электронные таблицы, как Лотос 1-2-3 и программное обеспечение для баз данных, такое как dBASE. Продукт dBASE был легким и понятным любому пользователю компьютера. К. Уэйн Рэтлифф, создатель dBASE, заявил: «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 теорема это невозможно для распределенная система одновременно предоставлять последовательность, гарантии доступности и допустимости разделов. Распределенная система может удовлетворить любые две из этих гарантий одновременно, но не все три. По этой причине многие базы данных NoSQL используют то, что называется возможная последовательность чтобы гарантировать как доступность, так и устойчивость к разделам с пониженным уровнем согласованности данных.

NewSQL - это класс современных реляционных баз данных, цель которых - обеспечить такую ​​же масштабируемую производительность систем NoSQL для рабочих нагрузок онлайн-обработки транзакций (чтения-записи) при одновременном использовании SQL и поддержании КИСЛОТА гарантии традиционной системы баз данных.

Сценарии использования

Базы данных используются для поддержки внутренних операций организаций и для поддержки онлайн-взаимодействий с клиентами и поставщиками (см. Корпоративное программное обеспечение ).

Базы данных используются для хранения административной информации и более специализированных данных, таких как инженерные данные или экономические модели. Примеры включают компьютеризированные библиотека системы, системы бронирования рейсов компьютеризированный системы инвентаризации запчастей, и много системы управления контентом этот магазин веб-сайты как коллекции веб-страниц в базе данных.

Классификация

Один из способов классификации баз данных включает тип их содержимого, например: библиографический, документ-текст, статистические или мультимедийные объекты. Другой способ - по области их применения, например: бухгалтерский учет, музыкальные композиции, фильмы, банковское дело, производство или страхование. Третий способ связан с некоторыми техническими аспектами, такими как структура базы данных или тип интерфейса. В этом разделе перечислено несколько прилагательных, используемых для характеристики различных типов баз данных.

  • An база данных в памяти это база данных, которая в основном находится в основная память, но обычно поддерживается энергонезависимым хранилищем компьютерных данных. Базы данных в основной памяти работают быстрее, чем базы данных на дисках, и поэтому часто используются там, где критично время отклика, например, в телекоммуникационном сетевом оборудовании.
  • An активная база данных включает в себя управляемую событиями архитектуру, которая может реагировать на условия как внутри, так и за пределами базы данных. Возможные варианты использования включают мониторинг безопасности, оповещение, сбор статистики и авторизацию. Многие базы данных предоставляют активные функции базы данных в виде триггеры базы данных.
  • А облачная база данных полагается на облачные технологии. И база данных, и большая часть ее СУБД находятся удаленно, «в облаке», в то время как ее приложения разрабатываются программистами, а затем обслуживаются и используются конечными пользователями через веб-браузер и Открытые API.
  • Хранилища данных архивировать данные из операционных баз данных и часто из внешних источников, таких как фирмы по исследованию рынка. Хранилище становится центральным источником данных для менеджеров и других конечных пользователей, которые могут не иметь доступа к оперативным данным. Например, данные о продажах могут быть агрегированы в итоги за неделю и преобразованы из внутренних кодов продуктов для использования UPC так что их можно сравнить с ACNielsen данные. Некоторые основные и важные компоненты хранилища данных включают извлечение, анализ и добыча полезных ископаемых data, преобразование, загрузка и управление данными, чтобы сделать их доступными для дальнейшего использования.
  • А дедуктивная база данных сочетает логическое программирование с реляционной базой данных.
  • А распределенная база данных - это тот, в котором данные и СУБД охватывают несколько компьютеров.
  • А документно-ориентированная база данных предназначен для хранения, извлечения и управления документированной или частично структурированной информацией. Документно-ориентированные базы данных - одна из основных категорий баз данных NoSQL.
  • An встроенная база данных system - это СУБД, которая тесно интегрирована с прикладным программным обеспечением, которому требуется доступ к сохраненным данным таким образом, что СУБД скрыта от конечных пользователей приложения и не требует постоянного обслуживания или почти не требует его.[21]
  • Базы данных конечных пользователей состоят из данных, разработанных отдельными конечными пользователями. Примерами являются коллекции документов, электронных таблиц, презентаций, мультимедиа и других файлов. Существует несколько продуктов для поддержки таких баз данных. Некоторые из них намного проще полноценных СУБД, с более элементарной функциональностью СУБД.
  • А система федеративных баз данных состоит из нескольких отдельных баз данных, каждая со своей собственной СУБД. Он обрабатывается как единая база данных федеративной системой управления базами данных (FDBMS), которая прозрачно интегрирует несколько автономных СУБД, возможно, разных типов (в этом случае это также будет гетерогенная система баз данных ), и предоставляет им интегрированное концептуальное представление.
  • Иногда термин мультибаза данных используется как синоним объединенной базы данных, хотя может относиться к менее интегрированной (например, без FDBMS и управляемой интегрированной схемы) группе баз данных, которые взаимодействуют в одном приложении. В этом случае обычно промежуточное ПО используется для распространения, которое обычно включает протокол атомарной фиксации (ACP), например, протокол двухфазной фиксации, позволять распределенные (глобальные) транзакции по участвующим базам данных.
  • А база данных графов это своего рода база данных NoSQL, которая использует структуры графа с узлами, ребрами и свойствами для представления и хранения информации. Общие базы данных графов, которые могут хранить любой граф, отличаются от специализированных баз данных графов, таких как тройные магазины и сетевые базы данных.
  • An массив СУБД это разновидность СУБД NoSQL, которая позволяет моделировать, хранить и извлекать (обычно большие) многомерные массивы такие как спутниковые изображения и результаты моделирования климата.
  • В гипертекст или же гипермедиа база данных, любое слово или фрагмент текста, представляющий объект, например, другой фрагмент текста, статью, изображение или фильм, может быть гиперссылка к этому объекту. Гипертекстовые базы данных особенно полезны для организации больших объемов разрозненной информации. Например, они полезны для организации онлайн-энциклопедии, где пользователи могут удобно перемещаться по тексту. В Всемирная паутина таким образом, большая распределенная база данных гипертекста.
  • А база знаний (сокращенно КБ, kb или Δ[22][23]) - это особый вид базы данных для управление знаниями, предоставляя средства для компьютеризированного сбора, организации и поиск из знание. Также набор данных, представляющих проблемы с их решениями и связанный с ними опыт.
  • А мобильная база данных могут переноситься или синхронизироваться с мобильного вычислительного устройства.
  • Операционные базы данных хранить подробные данные о деятельности организации. Обычно они обрабатывают относительно большие объемы обновлений, используя сделки. Примеры включают базы данных клиентов которые записывают контактную, кредитную и демографическую информацию о клиентах компании, базы данных персонала, содержащие информацию, такую ​​как зарплата, льготы, данные о навыках сотрудников, Планирование ресурсов предприятия системы, которые записывают подробную информацию о компонентах продукта, запасах запчастей и финансовых базах данных, отслеживающих денежные, бухгалтерские и финансовые операции организации.
  • А параллельная база данных стремится повысить производительность за счет распараллеливание для таких задач, как загрузка данных, построение индексов и оценка запросов.
Основные параллельные архитектуры СУБД, вызванные лежащими в основе аппаратное обеспечение архитектура бывают:
  • Общая архитектура памяти, где несколько процессоров совместно используют основное пространство памяти, а также другие хранилища данных.
  • Общая дисковая архитектура, где каждый процессор (обычно состоящий из нескольких процессоров) имеет свою собственную основную память, но все блоки совместно используют другое хранилище.
  • Общая архитектура, где каждый процессор имеет свою собственную основную память и другое хранилище.
  • Вероятностные базы данных нанять нечеткая логика делать выводы из неточных данных.
  • Базы данных в реальном времени обрабатывать транзакции достаточно быстро, чтобы результат вернулся и немедленно отреагировал.
  • А пространственная база данных может хранить данные с многомерными функциями. Запросы к таким данным включают запросы на основе местоположения, например «Где ближайший отель в моем районе?».
  • А временная база данных имеет встроенные временные аспекты, например временную модель данных и временную версию SQL. Более конкретно, временные аспекты обычно включают время действительности и время транзакции.
  • А терминологически ориентированная база данных строится на объектно-ориентированная база данных, часто настраиваемый для конкретного поля.
  • An неструктурированные данные База данных предназначена для хранения в управляемом и защищенном виде различных объектов, которые естественно и удобно не вписываются в общие базы данных. Оно может включать сообщения электронной почты, документы, журналы, мультимедийные объекты и т. Д. Название может вводить в заблуждение, поскольку некоторые объекты могут быть сильно структурированными. Однако вся возможная коллекция объектов не вписывается в заранее определенную структурированную структуру. Большинство известных СУБД в настоящее время различными способами поддерживают неструктурированные данные, и появляются новые специализированные СУБД.

Взаимодействие с базой данных

Система управления базой данных

Коннолли и Бегг определяют систему управления базами данных (СУБД) как «систему программного обеспечения, которая позволяет пользователям определять, создавать, поддерживать и контролировать доступ к базе данных».[24] Примеры СУБД включают MySQL, PostgreSQL, MSSQL, База данных Oracle, и Microsoft Access.

Аббревиатуру СУБД иногда расширяют, чтобы указать на лежащую в основе модель базы данных, с СУБД для реляционный, OODBMS для объектно-ориентированный) и ORDBMS для объектно-реляционная модель. Другие расширения могут указывать на некоторые другие характеристики, такие как DDBMS для распределенных систем управления базами данных.

Функциональные возможности СУБД могут сильно различаться. Основная функция - хранение, поиск и обновление данных. Кодд предложили следующие функции и услуги, которые должна обеспечивать полноценная СУБД общего назначения:[25]

  • Хранение, поиск и обновление данных
  • Доступный пользователю каталог или словарь данных с описанием метаданных
  • Поддержка транзакций и параллелизма
  • Средства для восстановления базы данных в случае ее повреждения
  • Поддержка авторизации доступа и обновления данных
  • Доступ к поддержке из удаленных мест
  • Применение ограничений для обеспечения соответствия данных в базе данных определенным правилам

Также обычно ожидается, что СУБД предоставит набор утилит для таких целей, которые могут потребоваться для эффективного администрирования базы данных, включая утилиты импорта, экспорта, мониторинга, дефрагментации и анализа.[26] Основная часть СУБД, взаимодействующая между базой данных и интерфейсом приложения, иногда называемая ядро базы данных.

Часто СУБД имеют параметры конфигурации, которые можно настраивать статически и динамически, например максимальный объем основной памяти на сервере, который может использовать база данных. Тенденция состоит в том, чтобы свести к минимуму количество ручной настройки, и для таких случаев, как встроенные базы данных первостепенная важность имеет нацеленность на нулевое администрирование.

Крупные крупные корпоративные СУБД имеют тенденцию к увеличению размеров и функциональности, и на их разработку могут потребоваться тысячи человеческих лет усилий на разработку.[а]

Ранние многопользовательские СУБД обычно позволяли приложению размещаться на одном компьютере только с доступом через терминалы или программное обеспечение эмуляции терминала. В клиент-серверная архитектура была разработкой, в которой приложение размещалось на клиентском рабочем столе, а база данных - на сервере, что позволяло распределять обработку. Это превратилось в многоуровневая архитектура включение серверы приложений и веб-серверы с интерфейсом конечного пользователя через веб-браузер с базой данных только напрямую подключенной к соседнему уровню.[27]

СУБД общего назначения предоставит публичные интерфейсы прикладного программирования (API) и, возможно, процессор для языки базы данных Такие как SQL чтобы можно было писать приложения для взаимодействия с базой данных. СУБД специального назначения может использовать частный API и быть специально настроена и связана с одним приложением. Например, электронное письмо система, выполняющая многие функции СУБД общего назначения, такие как вставка сообщений, удаление сообщений, обработка вложений, поиск в черном списке, связывание сообщений с адресом электронной почты и т. д., однако эти функции ограничены тем, что требуется для обработки электронной почты.

Заявление

Внешнее взаимодействие с базой данных будет осуществляться через прикладную программу, которая взаимодействует с СУБД.[28] Это может варьироваться от инструмент базы данных это позволяет пользователям выполнять запросы SQL в текстовом или графическом виде на веб-сайте, который использует базу данных для хранения и поиска информации.

Интерфейс прикладной программы

А программист буду код взаимодействия с базой данных (иногда называемые источник данных ) через интерфейс прикладной программы (API) или через язык базы данных. Выбранный API или язык должны поддерживаться СУБД, возможно косвенно через препроцессор или мостовой API. Некоторые API стремятся быть независимыми от базы данных, ODBC являясь общеизвестным примером. Другие распространенные API включают JDBC и ADO.NET.

Языки баз данных

Языки баз данных - это языки специального назначения, которые позволяют выполнять одну или несколько из следующих задач, иногда называемых подъязыки:

Языки баз данных специфичны для конкретной модели данных. Известные примеры включают:

Язык базы данных может также включать такие функции, как:

  • Конфигурация СУБД и управление механизмом хранения
  • Вычисления для изменения результатов запроса, такие как подсчет, суммирование, усреднение, сортировка, группировка и перекрестные ссылки
  • Обеспечение соблюдения ограничений (например, в автомобильной базе данных разрешено использование только одного типа двигателя на автомобиль)
  • Версия интерфейса прикладного программирования языка запросов для удобства программиста

Место хранения

Основные статьи: Хранение компьютерных данных и Ядро базы данных

Хранилище базы данных - это контейнер физической материализации базы данных. Он включает внутренний (физический) уровень в архитектуре базы данных. Он также содержит всю необходимую информацию (например, метаданные, «данные о данных» и внутренние структуры данных ) для реконструкции концептуальный уровень и внешний уровень с внутреннего уровня при необходимости. Как правило, за хранение данных в постоянном хранилище отвечает ядро базы данных он же «двигатель хранения». Хотя обычно СУБД получает доступ через базовую операционную систему (и часто с помощью операционных систем) файловые системы в качестве промежуточных звеньев для компоновки хранилища), свойства хранилища и настройки конфигурации чрезвычайно важны для эффективной работы СУБД и, таким образом, тщательно поддерживаются администраторами баз данных. СУБД во время работы всегда имеет свою базу данных, расположенную в нескольких типах хранилищ (например, в памяти и на внешнем хранилище). Данные базы данных и дополнительная необходимая информация, возможно, в очень большом количестве, кодируются в битах. Данные обычно хранятся в хранилище в структурах, которые полностью отличаются от того, как данные выглядят на концептуальном и внешнем уровнях, но таким образом, который пытается оптимизировать (как можно лучше) реконструкцию этих уровней, когда это необходимо пользователям и программам. что касается вычисления дополнительных типов необходимой информации из данных (например, при запросе к базе данных).

Некоторые СУБД поддерживают указание кодировка символов использовался для хранения данных, поэтому в одной базе данных можно использовать несколько кодировок.

Различные низкоуровневые структуры хранения базы данных используются механизмом хранения для сериализации модели данных, чтобы ее можно было записать на выбранный носитель. Для повышения производительности могут использоваться такие методы, как индексация. Обычное хранилище ориентировано на строки, но есть также столбчатый и корреляционные базы данных.

Материализованные представления

Основная статья: Материализованное представление

Часто избыточность хранилища используется для повышения производительности. Типичный пример - хранение материализованные представления, которые состоят из часто используемых внешний вид или запросить результаты. Сохранение таких представлений позволяет сэкономить на дорогостоящих вычислениях каждый раз, когда они необходимы. Недостатками материализованных представлений являются накладные расходы, возникающие при их обновлении, чтобы поддерживать их синхронизацию с исходными обновленными данными базы данных, а также стоимость избыточности хранилища.

Репликация

Основная статья: Репликация базы данных

Иногда в базе данных используется избыточность хранилища путем репликации объектов базы данных (с одной или несколькими копиями) для повышения доступности данных (как для повышения производительности одновременного множественного доступа конечных пользователей к одному объекту базы данных, так и для обеспечения отказоустойчивости в случае частичного отказа распределенная база данных). Обновления реплицированного объекта необходимо синхронизировать между копиями объекта. Во многих случаях реплицируется вся база данных.

Безопасность

Основная статья: Безопасность базы данных

Безопасность базы данных занимается всеми различными аспектами защиты содержимого базы данных, ее владельцев и пользователей. Он варьируется от защиты от преднамеренного несанкционированного использования базы данных до непреднамеренного доступа к базе данных неавторизованными объектами (например, человеком или компьютерной программой).

Контроль доступа к базе данных имеет дело с контролем того, кому (человеку или определенной компьютерной программе) разрешен доступ к какой информации в базе данных. Информация может содержать конкретные объекты базы данных (например, типы записей, конкретные записи, структуры данных), определенные вычисления над определенными объектами (например, типы запросов или конкретные запросы) или использование определенных путей доступа к первым (например, с использованием определенных индексов или другие структуры данных для доступа к информации). Контроль доступа к базе данных устанавливается специально уполномоченным (владельцем базы данных) персоналом, который использует выделенные защищенные интерфейсы СУБД.

Этим можно управлять непосредственно на индивидуальной основе или путем назначения отдельных лиц и привилегии группам или (в наиболее сложных моделях) назначением отдельных лиц и групп на роли, которым затем предоставляются права. Безопасность данных предотвращает просмотр или обновление базы данных неавторизованными пользователями. Используя пароли, пользователям разрешается доступ ко всей базе данных или ее подмножествам, называемым «подсхемами». Например, база данных сотрудников может содержать все данные об отдельном сотруднике, но одной группе пользователей может быть разрешено просматривать только данные о заработной плате, а другим разрешен доступ только к истории работы и медицинским данным. Если СУБД предоставляет возможность интерактивного входа и обновления базы данных, а также ее опроса, эта возможность позволяет управлять личными базами данных.

Безопасность данных в целом касается защиты определенных фрагментов данных как физически (т. е. от повреждения, разрушения или удаления; например, см. физическая охрана ), либо их интерпретация, либо их части в значимую информацию (например, путем просмотра строк битов, которые они содержат, заключения конкретных действительных номеров кредитных карт; например, см. шифрование данных ).

Изменять и получать доступ к записям журнала, кто обращался к каким атрибутам, что было изменено и когда это было изменено. Услуги регистрации позволяют проводить судебную экспертизу. аудит базы данных позже, ведя учет происшествий и изменений доступа. Иногда код уровня приложения используется для записи изменений, вместо того, чтобы оставлять это в базе данных. Можно настроить мониторинг для попытки обнаружения нарушений безопасности.

Транзакции и параллелизм

Дальнейшая информация: Контроль параллелизма

Транзакции базы данных может использоваться для введения некоторого уровня Отказоустойчивость и целостность данных после выздоровления от крушение. Транзакция базы данных - это единица работы, обычно заключающая в себе ряд операций с базой данных (например, чтение объекта базы данных, запись, получение замок и т.д.), абстракция, поддерживаемая в базе данных, а также в других системах. Каждая транзакция имеет четко определенные границы, в соответствии с которыми выполнение программы / кода включается в эту транзакцию (определяется программистом транзакции с помощью специальных команд транзакции).

Акроним КИСЛОТА описывает некоторые идеальные свойства транзакции базы данных: атомарность, последовательность, изоляция, и долговечность.

Миграция

Смотрите также: Миграция данных § Миграция базы данных

База данных, созданная с помощью одной СУБД, не переносится на другую СУБД (т.е. другая СУБД не может ее запустить). Однако в некоторых ситуациях желательно перенести базу данных с одной СУБД на другую. Причины в первую очередь экономические (разные СУБД могут иметь разные общая стоимость владения или TCO), функциональные и эксплуатационные (разные СУБД могут иметь разные возможности). Миграция включает в себя преобразование базы данных из одного типа СУБД в другой. Преобразование должно поддерживать (если возможно) связанное с базой данных приложение (то есть все связанные прикладные программы) в неизменном виде. Таким образом, концептуальный и внешний архитектурный уровни базы данных должны сохраняться при преобразовании. Может быть желательно, чтобы также были сохранены некоторые аспекты внутреннего уровня архитектуры. Сложная или большая миграция базы данных может быть сложным и дорогостоящим (разовым) проектом, который следует учитывать при принятии решения о миграции. И это несмотря на то, что могут существовать инструменты для облегчения миграции между конкретными СУБД. Обычно поставщик СУБД предоставляет инструменты, помогающие импортировать базы данных из других популярных СУБД.

Сборка, обслуживание и настройка

Основная статья: Настройка базы данных

После разработки базы данных для приложения следующим этапом является создание базы данных. Как правило, для этой цели может быть выбрана соответствующая СУБД общего назначения. СУБД предоставляет необходимые пользовательские интерфейсы будет использоваться администраторами базы данных для определения необходимых структур данных приложения в соответствующей модели данных СУБД. Другие пользовательские интерфейсы используются для выбора необходимых параметров СУБД (например, связанных с безопасностью, параметров выделения памяти и т. Д.).

Когда база данных готова (определены все ее структуры данных и другие необходимые компоненты), она обычно заполняется исходными данными приложения (инициализация базы данных, которая обычно представляет собой отдельный проект; во многих случаях используются специализированные интерфейсы СУБД, поддерживающие массовую вставку), прежде чем делая его работоспособным. В некоторых случаях база данных становится работоспособной, пока не содержит данных приложения, и данные накапливаются во время ее работы.

После того, как база данных создана, инициализирована и заполнена, ее необходимо обслуживать. Может потребоваться изменение различных параметров базы данных и настройка базы данных (настройка ) для лучшей производительности; структуры данных приложения могут быть изменены или добавлены, могут быть написаны новые связанные прикладные программы для добавления к функциональности приложения и т. д.

Резервное копирование и восстановление

Основная статья: Резервный

Иногда требуется вернуть базу данных в предыдущее состояние (по многим причинам, например, в случаях, когда база данных оказывается поврежденной из-за ошибки программного обеспечения или если она была обновлена ​​ошибочными данными). Чтобы достичь этого, операция резервного копирования выполняется время от времени или непрерывно, где каждое желаемое состояние базы данных (то есть значения ее данных и их встраивание в структуры данных базы данных) хранится в выделенных файлах резервных копий (существует множество методов, позволяющих сделать это эффективно). Когда администратор базы данных решает вернуть базу данных в это состояние (например, указав это состояние на желаемый момент времени, когда база данных находилась в этом состоянии), эти файлы используются для восстановления этого состояния.

Статический анализ

Методы статического анализа для проверки программного обеспечения могут применяться также в сценариях языков запросов. В частности, *Абстрактная интерпретация framework была расширена на область языков запросов для реляционных баз данных как способ поддержки надежных методов аппроксимации.[32] Семантика языков запросов может быть настроена в соответствии с подходящими абстракциями конкретной области данных. Абстракция системы реляционных баз данных имеет много интересных приложений, в частности, для целей безопасности, таких как детальный контроль доступа, водяные знаки и т. Д.

Разные особенности

Другие функции СУБД могут включать:

  • Журналы базы данных - Это помогает вести историю выполненных функций.
  • Графический компонент для создания графиков и диаграмм, особенно в системе хранилища данных.
  • Оптимизатор запросов - Выполняет оптимизацию запросов по каждому запросу, чтобы выбрать эффективный план запроса (частичный порядок (дерево) операций), который необходимо выполнить для вычисления результата запроса. Может быть специфическим для конкретной системы хранения.
  • Инструменты или хуки для проектирования базы данных, программирования приложений, обслуживания прикладных программ, анализа и мониторинга производительности базы данных, мониторинга конфигурации базы данных, конфигурации оборудования СУБД (СУБД и связанная база данных может охватывать компьютеры, сети и блоки хранения) и связанное отображение базы данных (особенно для распределенная СУБД), распределение хранилища и мониторинг структуры базы данных, миграция хранилища и т. д.

Все чаще возникает потребность в единой системе, объединяющей все эти основные функции в одну и ту же платформу сборки, тестирования и развертывания для управления базами данных и контроля версий. Заимствуя из других разработок в индустрии программного обеспечения, некоторые продают такие предложения, как "DevOps для базы данных ».[33]

Дизайн и моделирование

Основная статья: Дизайн базы данных
Процесс проектирования базы данных v2.png

Первая задача разработчика базы данных - создать концептуальная модель данных который отражает структуру информации, которая будет храниться в базе данных. Обычный подход к этому - разработка модель сущность-связь, часто с помощью инструментов для рисования. Другой популярный подход - Единый язык моделирования. Успешная модель данных будет точно отражать возможное состояние моделируемого внешнего мира: например, если у людей может быть более одного телефонного номера, это позволит получить эту информацию. Создание хорошей концептуальной модели данных требует хорошего понимания предметной области; обычно он включает в себя глубокие вопросы о вещах, представляющих интерес для организации, например, «может ли клиент также быть поставщиком?» или «если продукт продается с двумя разными формами упаковки, это один и тот же продукт или разные продукты? ", или" если самолет летит из Нью-Йорка в Дубай через Франкфурт, это один или два (а может, даже три)? ". Ответы на эти вопросы устанавливают определения терминологии, используемой для сущностей (клиентов, продуктов, рейсов, сегментов полета), а также их отношений и атрибутов.

Создание концептуальной модели данных иногда включает ввод деловые процессы, или анализ рабочий процесс в организации. Это может помочь установить, какая информация необходима в базе данных, а какая может быть опущена. Например, это может помочь при принятии решения, нужно ли в базе данных хранить исторические данные, а также текущие данные.

После создания концептуальной модели данных, которая удовлетворяет пользователей, следующим этапом является ее преобразование в схема который реализует соответствующие структуры данных в базе данных. Этот процесс часто называют логическим проектированием базы данных, и на выходе получается логическая модель данных выражается в виде схемы. В то время как концептуальная модель данных (по крайней мере теоретически) не зависит от выбора технологии базы данных, логическая модель данных будет выражена в терминах конкретной модели базы данных, поддерживаемой выбранной СУБД. (Условия модель данных и модель базы данных часто используются как взаимозаменяемые, но в этой статье мы используем модель данных для разработки конкретной базы данных, и модель базы данных для обозначений моделирования, используемых для выражения этого дизайна).

Самая популярная модель базы данных для баз данных общего назначения - это реляционная модель, или, точнее, реляционная модель, представленная языком SQL. В процессе создания логического дизайна базы данных с использованием этой модели используется методический подход, известный как нормализация. Цель нормализации - гарантировать, что каждый элементарный «факт» записывается только в одном месте, чтобы вставки, обновления и удаления автоматически поддерживали согласованность.

Заключительный этап проектирования базы данных - это принятие решений, влияющих на производительность, масштабируемость, восстановление, безопасность и т. Д., Которые зависят от конкретной СУБД. Это часто называют физический дизайн базы данных, а на выходе физическая модель данных. Ключевой целью на этом этапе является независимость данных, что означает, что решения, принимаемые в целях оптимизации производительности, должны быть невидимы для конечных пользователей и приложений. Существует два типа независимости данных: физическая независимость данных и логическая независимость данных. Физический дизайн определяется в основном требованиями к производительности и требует хорошего знания ожидаемой рабочей нагрузки и шаблонов доступа, а также глубокого понимания функций, предлагаемых выбранной СУБД.

Еще один аспект физического проектирования базы данных - безопасность. Это включает как определение контроль доступа для объектов базы данных, а также определение уровней безопасности и методов для самих данных.

Модели

Основная статья: Модель базы данных
Коллаж из пяти типов моделей баз данных

Модель базы данных - это тип модели данных, который определяет логическую структуру базы данных и в основном определяет, каким образом данные можно хранить, организовывать и манипулировать ими. Самый популярный пример модели базы данных - это реляционная модель (или приближение реляционного SQL), в которой используется табличный формат.

Общие логические модели данных для баз данных включают:

Объектно-реляционная база данных объединяет две связанные структуры.

Физические модели данных включают:

Другие модели включают:

Специализированные модели оптимизированы для определенных типов данных:

Внешний, концептуальный и внутренний вид

Традиционный взгляд на данные[34]

Система управления базой данных предоставляет три вида данных базы данных:

  • В внешний уровень определяет, как каждая группа конечных пользователей видит организацию данных в базе данных. Одна база данных может иметь любое количество представлений на внешнем уровне.
  • В концептуальный уровень объединяет различные внешние представления в совместимое глобальное представление.[35] Он обеспечивает синтез всех внешних взглядов. Он выходит за рамки различных конечных пользователей баз данных и скорее представляет интерес для разработчиков приложений баз данных и администраторов баз данных.
  • В внутренний уровень (или же физический уровень) - это внутренняя организация данных внутри СУБД. Это касается стоимости, производительности, масштабируемости и других операционных вопросов. Он касается структуры хранения данных с использованием таких структур хранения, как индексы для повышения производительности. Иногда в нем хранятся данные отдельных представлений (материализованные представления ), рассчитанный на основе общих данных, если для такой избыточности существует обоснование производительности. Он уравновешивает все требования к производительности внешних представлений, возможно, конфликтующие, в попытке оптимизировать общую производительность для всех действий.

Хотя обычно существует только одно концептуальное (или логическое) и физическое (или внутреннее) представление данных, может быть любое количество различных внешних представлений. Это позволяет пользователям просматривать информацию в базе данных с точки зрения бизнеса, а не с технической точки зрения. Например, финансовому отделу компании требуются платежные реквизиты всех сотрудников как часть расходов компании, но не требуются данные о сотрудниках, которые представляют интересы человеческие ресурсы отделение. Таким образом, разным отделам нужны разные взгляды базы данных компании.

Трехуровневая архитектура базы данных относится к концепции независимость данных что было одной из основных движущих сил реляционной модели. Идея состоит в том, что изменения, сделанные на определенном уровне, не влияют на представление на более высоком уровне. Например, изменения на внутреннем уровне не влияют на прикладные программы, написанные с использованием интерфейсов концептуального уровня, что снижает влияние внесения физических изменений для повышения производительности.

Концептуальный взгляд обеспечивает уровень косвенности между внутренним и внешним. С одной стороны, он обеспечивает общий вид базы данных, независимый от различных внешних структур представления, а с другой стороны, он абстрагирует детали того, как данные хранятся или управляются (внутренний уровень). В принципе, каждый уровень и даже каждый внешний вид могут быть представлены с помощью другой модели данных.На практике обычно данная СУБД использует одну и ту же модель данных как для внешнего, так и для концептуального уровней (например, реляционная модель). Внутренний уровень, который скрыт внутри СУБД и зависит от ее реализации, требует другого уровня детализации и использует свои типы структур данных.

Разделение внешний, концептуальный и внутренний Уровни были основной особенностью реализаций моделей реляционных баз данных, которые доминируют в базах данных 21-го века.[35]

Исследование

Технология баз данных была активной темой исследования с 1960-х годов, как в академия и в группах компаний, занимающихся исследованиями и разработками (например, IBM Research ). Исследовательская деятельность включает теория и развитие прототипы. Известные темы исследований включали модели, концепция атомарной транзакции и связанные контроль параллелизма методы, языки запросов и оптимизация запросов методы, RAID, и больше.

В области исследования базы данных есть несколько специализированных академические журналы (Например, Транзакции ACM в системах баз данных -TODS, Инженерия данных и знаний -DKE) и годовой конференции (например., ACM SIGMOD, ACM ПОД, VLDB, IEEE ICDE).

Смотрите также

Актуальное руководство по этой теме см. Схема баз данных.

Примечания

  1. ^ В этой статье приводится 5 лет разработки только для DB2 версии 9 с привлечением 750 человек (Чонг и др. 2007 г. )

Рекомендации

  1. ^ Ульман и Уидом 1997, п. 1.
  2. ^ «Обновление - Определение обновления от Merriam-Webster». merriam-webster.com.
  3. ^ «Извлечение - определение извлечения по Merriam-Webster». merriam-webster.com.
  4. ^ «Администрирование - Определение администрации по Merriam-Webster». merriam-webster.com.
  5. ^ Цитчизрис и Лочовский 1982.
  6. ^ Бейнон-Дэвис 2003.
  7. ^ Нельсон и Нельсон 2001.
  8. ^ Бахман 1973.
  9. ^ "TOPDB Top Database index". pypl.github.io.
  10. ^ "база данных, п". OED Online. Издательство Оксфордского университета. июнь 2013. Получено 12 июля, 2013. (Требуется подписка.)
  11. ^ Корпорация IBM (октябрь 2013 г.). «Серверы транзакций и баз данных IBM Information Management System (IMS) 13 обеспечивают высокую производительность и низкую совокупную стоимость владения». Получено 20 февраля, 2014.
  12. ^ Кодд 1970.
  13. ^ Херши и Истхоуп, 1972 г..
  14. ^ Север 2010.
  15. ^ Чайлдс 1968a.
  16. ^ Чайлдс 1968b.
  17. ^ Справочное руководство по системе управления информацией MICRO (версия 5.0), М.А.Кан, Д.Л. Румельхарт и Б. Бронсон, октябрь 1977 г., Институт труда и производственных отношений (ILIR), Мичиганский университет и Государственный университет Уэйна.
  18. ^ "Хронология 30-летия Oracle" (PDF). Получено 23 августа 2017.
  19. ^ Интервью с Уэйном Рэтлиффом. История FoxPro. Проверено 12 июля 2013.
  20. ^ Разработка объектно-ориентированной СУБД; Портленд, штат Орегон, США; Страницы: 472–482; 1986; ISBN  0-89791-204-7
  21. ^ Грейвз, Стив. «Базы данных COTS для встраиваемых систем» В архиве 2007-11-14 на Wayback Machine, Проектирование встроенных вычислений magazine, January 2007. Проверено 13 августа, 2008.
  22. ^ Аргументация в искусственном интеллекте Ияд Рахван, Гильермо Р. Симари
  23. ^ "Семантика OWL DL". Получено 10 декабря 2010.
  24. ^ Коннолли и Бегг 2014, п. 64.
  25. ^ Коннолли и Бегг 2014 С. 97–102.
  26. ^ Коннолли и Бегг 2014, п. 102.
  27. ^ Коннолли и Бегг 2014 С. 106–113.
  28. ^ Коннолли и Бегг 2014, п. 65.
  29. ^ Чаппл 2005.
  30. ^ «Язык структурированных запросов (SQL)». Международные Бизнес Машины. 27 октября 2006 г.. Получено 2007-06-10.
  31. ^ Вагнер 2010.
  32. ^ Гальдер и Кортеси 2011.
  33. ^ Бен Линдерс (28 января 2016 г.). «Как администрирование баз данных вписывается в DevOps». Получено 15 апреля, 2017.
  34. ^ itl.nist.gov (1993) Определение интеграции для информационного моделирования (IDEFIX) В архиве 2013-12-03 в Wayback Machine. 21 декабря 1993 г.
  35. ^ а б Дата 2003 С. 31–32.

Источники

дальнейшее чтение

внешняя ссылка