В вычислительной технике база данных представляет собой организованный набор данных или тип хранилища данных , основанный на использовании системы управления базами данных ( СУБД ), программного обеспечения , которое взаимодействует с конечными пользователями , приложениями и самой базой данных для сбора и анализа данных. СУБД дополнительно охватывает основные средства, предоставляемые для администрирования базы данных. Совокупность базы данных, СУБД и связанных с ней приложений может называться системой базы данных . Часто термин «база данных» также используется в широком смысле для обозначения любой СУБД, системы базы данных или приложения, связанного с базой данных.
Небольшие базы данных могут храниться в файловой системе , в то время как большие базы данных размещаются на компьютерных кластерах или в облачном хранилище . Проектирование баз данных охватывает формальные методы и практические соображения, включая моделирование данных , эффективное представление и хранение данных, языки запросов , безопасность и конфиденциальность конфиденциальных данных и проблемы распределенных вычислений , включая поддержку одновременного доступа и отказоустойчивости .
Специалисты по информатике могут классифицировать системы управления базами данных в соответствии с моделями баз данных , которые они поддерживают. Реляционные базы данных стали доминирующими в 1980-х годах. Они моделируют данные как строки и столбцы в серии таблиц , и подавляющее большинство используют SQL для записи и запроса данных. В 2000-х годах стали популярны нереляционные базы данных, которые в совокупности называются NoSQL , поскольку они используют разные языки запросов .
Формально «база данных» относится к набору связанных данных, доступ к которым осуществляется посредством использования «системы управления базами данных» (СУБД), которая представляет собой интегрированный набор компьютерного программного обеспечения , позволяющего пользователям взаимодействовать с одной или несколькими базами данных и предоставляющего доступ ко всем данным, содержащимся в базе данных (хотя могут существовать ограничения, ограничивающие доступ к определенным данным). СУБД предоставляет различные функции, которые позволяют вводить, хранить и извлекать большие объемы информации, а также предоставляет способы управления тем, как организована эта информация.
Из-за тесной взаимосвязи между ними термин «база данных» часто используется в неформальном отношении как для обозначения базы данных, так и для СУБД, используемой для управления ею.
За пределами мира профессиональных информационных технологий термин «база данных» часто используется для обозначения любого набора взаимосвязанных данных (например, электронной таблицы или картотеки), поскольку требования к размеру и использованию обычно требуют использования системы управления базами данных. [1]
Существующие СУБД предоставляют различные функции, позволяющие управлять базой данных и ее данными, которые можно разделить на четыре основные функциональные группы:
Как база данных, так и ее СУБД соответствуют принципам определенной модели базы данных . [5] «Система базы данных» в совокупности относится к модели базы данных, системе управления базами данных и базе данных. [6]
Физически серверы баз данных — это выделенные компьютеры, которые содержат реальные базы данных и запускают только СУБД и соответствующее программное обеспечение. Серверы баз данных обычно представляют собой многопроцессорные компьютеры с большой памятью и массивами RAID- дисков, используемыми для стабильного хранения. Аппаратные ускорители баз данных, подключенные к одному или нескольким серверам через высокоскоростной канал, также используются в средах обработки транзакций большого объема . СУБД находятся в основе большинства приложений баз данных . СУБД могут быть построены вокруг пользовательского многозадачного ядра со встроенной сетевой поддержкой, но современные СУБД обычно полагаются на стандартную операционную систему для предоставления этих функций. [ необходима цитата ]
Поскольку СУБД занимают значительный рынок , поставщики компьютеров и систем хранения данных часто учитывают требования СУБД в своих собственных планах разработки. [7]
Базы данных и СУБД можно классифицировать в соответствии с поддерживаемой ими моделью (моделями) базы данных (например, реляционная или XML ), типом (типами) компьютера, на котором они работают (от серверного кластера до мобильного телефона ), языком (языками) запросов , используемым для доступа к базе данных (например, SQL или XQuery ), и их внутренней разработкой, которая влияет на производительность, масштабируемость , устойчивость и безопасность.
Размеры, возможности и производительность баз данных и соответствующих им СУБД выросли на порядок. Такое увеличение производительности стало возможным благодаря технологическому прогрессу в области процессоров , компьютерной памяти , компьютерных хранилищ и компьютерных сетей . Концепция базы данных стала возможной благодаря появлению носителей прямого доступа, таких как магнитные диски , которые стали широко доступны в середине 1960-х годов; более ранние системы полагались на последовательное хранение данных на магнитной ленте . Последующее развитие технологии баз данных можно разделить на три эпохи, основанные на модели или структуре данных: навигационная , [8] SQL/ реляционная и постреляционная.
Две основные ранние модели навигационных данных — иерархическая модель и модель CODASYL ( сетевая модель ). Они характеризовались использованием указателей (часто адресов физических дисков) для отслеживания связей от одной записи к другой.
Реляционная модель , впервые предложенная в 1970 году Эдгаром Ф. Коддом , отошла от этой традиции, настаивая на том, что приложения должны искать данные по содержанию, а не по ссылкам. Реляционная модель использует наборы таблиц в стиле бухгалтерской книги, каждая из которых используется для другого типа сущности . Только в середине 1980-х годов вычислительное оборудование стало достаточно мощным, чтобы обеспечить широкое развертывание реляционных систем (СУБД плюс приложения). Однако к началу 1990-х годов реляционные системы доминировали во всех крупномасштабных приложениях обработки данных , и по состоянию на 2018 год [обновлять]они остаются доминирующими: IBM Db2 , Oracle , MySQL и Microsoft SQL Server являются наиболее искомыми СУБД . [9] Доминирующий язык баз данных, стандартизированный SQL для реляционной модели, повлиял на языки баз данных для других моделей данных. [ необходима цитата ]
Объектные базы данных были разработаны в 1980-х годах для преодоления неудобств, связанных с несоответствием объектно-реляционного импеданса , что привело к появлению термина «постреляционный», а также к разработке гибридных объектно-реляционных баз данных .
Следующее поколение постреляционных баз данных в конце 2000-х годов стало известно как базы данных NoSQL , представляя быстрые хранилища ключей и ориентированные на документы базы данных . Конкурирующее «следующее поколение», известное как базы данных NewSQL, попыталось создать новые реализации, которые сохранили реляционную/SQL-модель, стремясь при этом соответствовать высокой производительности NoSQL по сравнению с коммерчески доступными реляционными СУБД.
Введение термина « база данных» совпало с появлением хранилищ с прямым доступом (диски и барабаны) с середины 1960-х годов. Термин представлял собой контраст с ленточными системами прошлого, позволяя совместное интерактивное использование, а не ежедневную пакетную обработку . Оксфордский словарь английского языка цитирует отчет 1962 года корпорации System Development Corporation of California как первый, в котором термин «база данных» был использован в определенном техническом смысле. [10]
По мере того, как компьютеры росли в скорости и возможностях, появилось несколько систем баз данных общего назначения; к середине 1960-х годов ряд таких систем вошли в коммерческое использование. Интерес к стандарту начал расти, и Чарльз Бахман , автор одного из таких продуктов, Integrated Data Store (IDS), основал Database Task Group в CODASYL , группе, ответственной за создание и стандартизацию COBOL . В 1971 году Database Task Group представила свой стандарт, который стал известен как подход CODASYL , и вскоре на рынок вышел ряд коммерческих продуктов, основанных на этом подходе.
Подход CODASYL предлагал приложениям возможность навигации по связанному набору данных, который был сформирован в большую сеть. Приложения могли находить записи одним из трех методов:
Более поздние системы добавили B-деревья для предоставления альтернативных путей доступа. Многие базы данных CODASYL также добавили декларативный язык запросов для конечных пользователей (в отличие от навигационного API ). Однако базы данных CODASYL были сложными и требовали значительного обучения и усилий для создания полезных приложений.
IBM также имела свою собственную СУБД в 1966 году, известную как Система управления информацией (IMS). IMS была разработкой программного обеспечения, написанного для программы Apollo на System/360 . IMS была в целом близка по концепции к CODASYL, но использовала строгую иерархию для своей модели навигации по данным вместо сетевой модели CODASYL. Обе концепции позже стали известны как навигационные базы данных из-за способа доступа к данным: этот термин был популяризирован в презентации Бахмана на премии Тьюринга 1973 года «Программист как навигатор» . IMS классифицируется IBM как иерархическая база данных . Базы данных IDMS и Cincom Systems « TOTAL» классифицируются как сетевые базы данных. IMS продолжает использоваться по состоянию на 2014 год [обновлять]. [11]
Эдгар Ф. Кодд работал в IBM в Сан-Хосе, Калифорния , в одном из филиалов, которые в основном занимались разработкой систем жестких дисков . Он был недоволен навигационной моделью подхода CODASYL, в частности, отсутствием «поисковой» возможности. В 1970 году он написал ряд статей, в которых изложил новый подход к построению баз данных, что в конечном итоге привело к появлению новаторской A Relational Model of Data for Large Shared Data Banks . [12]
В этой статье он описал новую систему для хранения и работы с большими базами данных. Вместо того, чтобы хранить записи в каком-то связанном списке записей свободной формы, как в CODASYL, идея Кодда заключалась в организации данных в виде ряда « таблиц », каждая из которых использовалась бы для отдельного типа сущности. Каждая таблица содержала бы фиксированное количество столбцов, содержащих атрибуты сущности. Один или несколько столбцов каждой таблицы были бы обозначены как первичный ключ , по которому строки таблицы могли бы быть уникально идентифицированы; перекрестные ссылки между таблицами всегда использовали бы эти первичные ключи, а не дисковые адреса, и запросы объединяли бы таблицы на основе этих ключевых отношений, используя набор операций, основанных на математической системе реляционного исчисления (откуда и произошло название модели). Разделение данных на набор нормализованных таблиц (или отношений ) было направлено на то, чтобы гарантировать, что каждый «факт» будет сохранен только один раз, что упростило бы операции обновления. Виртуальные таблицы, называемые представлениями, могли бы представлять данные по-разному для разных пользователей, но представления не могли быть обновлены напрямую.
Кодд использовал математические термины для определения модели: отношения, кортежи и домены, а не таблицы, строки и столбцы. Терминология, которая сейчас знакома, пришла из ранних реализаций. Позже Кодд критиковал тенденцию практических реализаций отходить от математических основ, на которых базировалась модель.
Использование первичных ключей (идентификаторов, ориентированных на пользователя) для представления межтабличных связей, а не дисковых адресов, имело две основные мотивации. С инженерной точки зрения это позволяло перемещать и изменять размер таблиц без дорогостоящей реорганизации базы данных. Но Кодда больше интересовала разница в семантике: использование явных идентификаторов упростило определение операций обновления с помощью чистых математических определений, а также позволило определять операции запросов в терминах устоявшейся дисциплины исчисления предикатов первого порядка ; поскольку эти операции имеют чистые математические свойства, становится возможным переписывать запросы доказуемо правильными способами, что является основой оптимизации запросов. По сравнению с иерархическими или сетевыми моделями не происходит потери выразительности, хотя связи между таблицами уже не столь явны.
В иерархических и сетевых моделях записи могли иметь сложную внутреннюю структуру. Например, история зарплаты сотрудника могла быть представлена как «повторяющаяся группа» в записи о сотруднике. В реляционной модели процесс нормализации приводил к замене таких внутренних структур данными, хранящимися в нескольких таблицах, связанных только логическими ключами.
Например, система баз данных обычно используется для отслеживания информации о пользователях, их имени, информации для входа, различных адресов и телефонных номеров. В навигационном подходе все эти данные будут помещены в одну запись переменной длины. В реляционном подходе данные будут нормализованы в таблицу пользователей, таблицу адресов и таблицу телефонных номеров (например). Записи будут создаваться в этих необязательных таблицах только в том случае, если адрес или телефонные номера были фактически предоставлены.
Помимо идентификации строк/записей с использованием логических идентификаторов, а не дисковых адресов, Кодд изменил способ, которым приложения собирали данные из нескольких записей. Вместо того, чтобы требовать от приложений собирать данные по одной записи за раз, перемещаясь по ссылкам, они использовали декларативный язык запросов, который выражал, какие данные требуются, а не путь доступа, по которому их следует найти. Поиск эффективного пути доступа к данным стал обязанностью системы управления базами данных, а не программиста приложения. Этот процесс, называемый оптимизацией запросов, зависел от того факта, что запросы были выражены в терминах математической логики.
Работа Кодда была подхвачена двумя людьми из Беркли, Юджином Вонгом и Майклом Стоунбрейкером . Они начали проект, известный как INGRES, используя финансирование, которое уже было выделено для проекта географической базы данных, и студентов-программистов для создания кода. Начиная с 1973 года, INGRES выпустил свои первые тестовые продукты, которые были в целом готовы к широкому использованию в 1979 году. INGRES был похож на System R во многих отношениях, включая использование «языка» для доступа к данным , известного как QUEL . Со временем INGRES перешел на новый стандарт SQL.
IBM сама сделала одну тестовую реализацию реляционной модели, PRTV , и производственную, Business System 12 , обе сейчас прекращены. Honeywell написала MRDS для Multics , и теперь есть две новые реализации: Alphora Dataphor и Rel. Большинство других реализаций СУБД, обычно называемых реляционными, на самом деле являются СУБД SQL.
В 1970 году Мичиганский университет начал разработку Системы управления информацией MICRO [13] на основе модели теоретико-множественных данных Д. Л. Чайлдса . [14] [15] [16] MICRO использовалась для управления очень большими наборами данных Министерством труда США , Агентством по охране окружающей среды США и исследователями из Университета Альберты , Мичиганского университета и Университета штата Уэйн . Она работала на мэйнфреймах IBM с использованием системы терминалов Мичигана . [17] Система оставалась в производстве до 1998 года.
В 1970-х и 1980-х годах были предприняты попытки построить системы баз данных с интегрированным аппаратным и программным обеспечением. Основная философия заключалась в том, что такая интеграция обеспечит более высокую производительность при меньших затратах. Примерами были IBM System/38 , раннее предложение Teradata и машина базы данных Britton Lee, Inc.
Другим подходом к аппаратной поддержке управления базами данных был ускоритель CAFS компании ICL , аппаратный дисковый контроллер с программируемыми возможностями поиска. В долгосрочной перспективе эти усилия, как правило, были безуспешными, поскольку специализированные машины баз данных не могли идти в ногу с быстрым развитием и прогрессом компьютеров общего назначения. Таким образом, большинство систем баз данных в настоящее время являются программными системами, работающими на оборудовании общего назначения, использующими хранилище данных компьютеров общего назначения. Однако эта идея все еще используется в определенных приложениях некоторыми компаниями, такими как Netezza и Oracle ( Exadata ).
IBM начала работать над прототипом системы, в общих чертах основанной на концепциях Кодда, как System R в начале 1970-х годов. Первая версия была готова в 1974/5, а затем началась работа над многотабличными системами, в которых данные могли быть разделены так, чтобы все данные для записи (некоторые из которых являются необязательными) не должны были храниться в одном большом «куске». Последующие многопользовательские версии были протестированы клиентами в 1978 и 1979 годах, к тому времени был добавлен стандартизированный язык запросов — SQL [ требуется цитата ] —. Идеи Кодда зарекомендовали себя как работоспособные и превосходящие CODASYL, подтолкнув IBM к разработке настоящей производственной версии System R, известной как SQL/DS , а позже и Database 2 ( IBM Db2 ).
Oracle Database Ларри Эллисона (или, проще говоря, Oracle ) начиналась с другой цепочки, основанной на работах IBM по System R. Хотя реализация Oracle V1 была завершена в 1978 году, только с Oracle Version 2 Эллисону удалось обойти IBM на рынке в 1979 году. [18]
Стоунбрейкер продолжил применять уроки INGRES для разработки новой базы данных Postgres, которая теперь известна как PostgreSQL . PostgreSQL часто используется для глобальных критически важных приложений (регистраторы доменных имен .org и .info используют ее в качестве основного хранилища данных , как и многие крупные компании и финансовые учреждения).
В Швеции статья Кодда также была прочитана, и в середине 1970-х годов в Университете Уппсалы был разработан Mimer SQL . В 1984 году этот проект был объединен в независимое предприятие.
Другая модель данных, модель «сущность–связь» , появилась в 1976 году и приобрела популярность для проектирования баз данных , поскольку она подчеркивала более знакомое описание, чем более ранняя реляционная модель. Позднее конструкции «сущность–связь» были модернизированы как конструкция моделирования данных для реляционной модели, и разница между ними стала несущественной. [ необходима цитата ]
1980-е годы ознаменовали начало эпохи настольных компьютеров . Новые компьютеры предоставили своим пользователям электронные таблицы, такие как Lotus 1-2-3 , и программное обеспечение для баз данных, такое как dBASE . Продукт dBASE был легким и простым для понимания любым пользователем компьютера из коробки. К. Уэйн Рэтлифф , создатель dBASE, заявил: «dBASE отличался от таких программ, как BASIC, C, FORTRAN и COBOL, тем, что большая часть грязной работы уже была сделана. Манипулирование данными выполняется dBASE, а не пользователем, поэтому пользователь может сосредоточиться на том, что он делает, а не возиться с грязными деталями открытия, чтения и закрытия файлов, а также управления распределением пространства». [19] dBASE был одним из самых продаваемых названий программного обеспечения в 1980-х и начале 1990-х годов.
В 1990-х годах, наряду с ростом объектно-ориентированного программирования , наблюдался рост способов обработки данных в различных базах данных. Программисты и дизайнеры начали рассматривать данные в своих базах данных как объекты . То есть, если данные человека находились в базе данных, атрибуты этого человека, такие как его адрес, номер телефона и возраст, теперь считались принадлежащими этому человеку, а не посторонними данными. Это позволяет связывать отношения между данными с объектами и их атрибутами , а не с отдельными полями. [20] Термин « несоответствие объектно-реляционного импеданса » описывал неудобства перевода между запрограммированными объектами и таблицами базы данных. Объектные базы данных и объектно-реляционные базы данных пытаются решить эту проблему, предоставляя объектно-ориентированный язык (иногда как расширения SQL), который программисты могут использовать в качестве альтернативы чисто реляционному SQL. Со стороны программирования библиотеки, известные как объектно-реляционные отображения (ORM), пытаются решить ту же проблему.
Базы данных XML — это тип структурированной документоориентированной базы данных, которая позволяет делать запросы на основе атрибутов XML- документа. Базы данных XML в основном используются в приложениях, где данные удобно рассматривать как набор документов, со структурой, которая может варьироваться от очень гибкой до очень жесткой: примеры включают научные статьи, патенты, налоговые декларации и записи о персонале.
Базы данных NoSQL часто очень быстрые, не требуют фиксированных схем таблиц, избегают операций соединения за счет хранения денормализованных данных и предназначены для горизонтального масштабирования .
В последние годы наблюдается сильный спрос на массивно распределенные базы данных с высокой устойчивостью к разделам, но согласно теореме CAP , распределенная система не может одновременно обеспечивать гарантии согласованности , доступности и устойчивости к разделам. Распределенная система может удовлетворять любым двум из этих гарантий одновременно, но не всем трем. По этой причине многие базы данных NoSQL используют то, что называется согласованностью в конечном счете , чтобы обеспечить как гарантии доступности, так и устойчивости к разделам с пониженным уровнем согласованности данных.
NewSQL — это класс современных реляционных баз данных, призванный обеспечить ту же масштабируемую производительность систем NoSQL для рабочих нагрузок обработки онлайн-транзакций (чтение-запись), при этом по-прежнему используя SQL и поддерживая гарантии ACID традиционной системы баз данных.
Базы данных используются для поддержки внутренних операций организаций и для поддержки онлайн-взаимодействия с клиентами и поставщиками (см. Корпоративное программное обеспечение ).
Базы данных используются для хранения административной информации и более специализированных данных, таких как инженерные данные или экономические модели. Примерами являются компьютеризированные библиотечные системы, системы бронирования авиабилетов , компьютеризированные системы инвентаризации деталей и многие системы управления контентом , которые хранят веб-сайты как коллекции веб-страниц в базе данных.
Один из способов классификации баз данных включает тип их содержимого, например: библиографические , текстовые документы, статистические или мультимедийные объекты. Другой способ — по области их применения, например: бухгалтерский учет, музыкальные композиции, фильмы, банковское дело, производство или страхование. Третий способ — по некоторому техническому аспекту, например, по структуре базы данных или типу интерфейса. В этом разделе перечислены некоторые прилагательные, используемые для характеристики различных видов баз данных.
Коннолли и Бегг определяют систему управления базами данных (СУБД) как «программную систему, которая позволяет пользователям определять, создавать, поддерживать и контролировать доступ к базе данных». [24] Примерами СУБД являются MySQL , MariaDB , PostgreSQL , Microsoft SQL Server , Oracle Database и Microsoft Access .
Аббревиатура DBMS иногда расширяется для указания базовой модели базы данных , с RDBMS для реляционной , OODBMS для объектно-ориентированной и ORDBMS для объектно-реляционной модели . Другие расширения могут указывать на некоторые другие характеристики, например, DDBMS для распределенной системы управления базами данных.
Функциональность, предоставляемая СУБД, может значительно различаться. Основная функциональность — хранение, извлечение и обновление данных. Кодд предложил следующие функции и сервисы, которые должна предоставлять полноценная СУБД общего назначения: [25]
Также обычно ожидается, что СУБД предоставит набор утилит для таких целей, которые могут потребоваться для эффективного администрирования базы данных, включая утилиты импорта, экспорта, мониторинга, дефрагментации и анализа. [26] Основная часть СУБД, взаимодействующая между базой данных и интерфейсом приложения, иногда называется ядром базы данных .
Часто СУБД имеют параметры конфигурации, которые можно статически и динамически настраивать, например, максимальный объем основной памяти на сервере, который может использовать база данных. Тенденция заключается в минимизации объема ручной настройки, а для таких случаев, как встроенные базы данных, первостепенной является необходимость стремиться к нулевому администрированию.
Крупные корпоративные СУБД имели тенденцию к увеличению размеров и функциональности и потребовали до тысяч человеко-лет усилий по разработке на протяжении всего своего существования. [a]
Ранние многопользовательские СУБД обычно позволяли приложению находиться только на одном компьютере с доступом через терминалы или программное обеспечение эмуляции терминала. Архитектура клиент-сервер была разработкой, в которой приложение находилось на клиентском рабочем столе, а база данных на сервере, что позволяло распределять обработку. Это превратилось в многоуровневую архитектуру, включающую серверы приложений и веб-серверы с конечным пользовательским интерфейсом через веб-браузер , при этом база данных была напрямую подключена только к соседнему уровню. [28]
СУБД общего назначения будет предоставлять общедоступные интерфейсы прикладного программирования (API) и опционально процессор для языков баз данных , таких как SQL , чтобы позволить приложениям взаимодействовать с базой данных и управлять ею. СУБД специального назначения может использовать частный API и быть специально настроенной и связанной с одним приложением. Например, система электронной почты выполняет многие функции СУБД общего назначения, такие как вставка сообщений, удаление сообщений, обработка вложений, поиск в списке блокировки, связывание сообщений с адресом электронной почты и т. д. Однако эти функции ограничены тем, что требуется для обработки электронной почты.
Внешнее взаимодействие с базой данных будет осуществляться через прикладную программу, которая взаимодействует с СУБД. [29] Это может быть как инструмент базы данных , позволяющий пользователям выполнять SQL-запросы текстовым или графическим способом, так и веб-сайт, который использует базу данных для хранения и поиска информации.
Программист будет кодировать взаимодействия с базой данных ( иногда называемой источником данных ) через интерфейс прикладного программирования (API) или через язык базы данных. Конкретный выбранный API или язык должен поддерживаться СУБД, возможно, косвенно через препроцессор или связующий API. Некоторые API стремятся быть независимыми от базы данных, ODBC является общеизвестным примером. Другие распространенные API включают JDBC и ADO.NET .
Языки баз данных — это языки специального назначения, которые позволяют выполнять одну или несколько из следующих задач, иногда выделяемых в качестве подъязыков :
Языки баз данных специфичны для конкретной модели данных. Известные примеры включают:
Язык базы данных может также включать такие функции, как:
Хранилище базы данных — это контейнер физической материализации базы данных. Оно включает в себя внутренний (физический) уровень в архитектуре базы данных. Оно также содержит всю необходимую информацию (например, метаданные , «данные о данных» и внутренние структуры данных ) для реконструкции концептуального уровня и внешнего уровня из внутреннего уровня при необходимости. Базы данных как цифровые объекты содержат три слоя информации, которые должны храниться: данные, структуру и семантику. Правильное хранение всех трех слоев необходимо для будущего сохранения и долговечности базы данных. [33] Размещение данных в постоянном хранилище, как правило, является обязанностью ядра базы данных , также известного как «ядро хранения». Хотя обычно доступ к ним осуществляется СУБД через базовую операционную систему (и часто с использованием файловых систем операционных систем в качестве промежуточных звеньев для компоновки хранилища), свойства хранения и параметры конфигурации чрезвычайно важны для эффективной работы СУБД и, таким образом, тщательно поддерживаются администраторами баз данных. Во время работы СУБД всегда имеет свою базу данных, находящуюся в нескольких типах хранилищ (например, в памяти и внешнем хранилище). Данные базы данных и дополнительная необходимая информация, возможно, в очень больших объемах, кодируются в биты. Данные обычно находятся в хранилище в структурах, которые выглядят совершенно иначе, чем данные выглядят на концептуальном и внешнем уровнях, но способами, которые пытаются оптимизировать (наиболее возможным образом) реконструкцию этих уровней, когда это необходимо пользователям и программам, а также для вычисления дополнительных типов необходимой информации из данных (например, при запросе базы данных).
Некоторые СУБД поддерживают указание того, какая кодировка символов использовалась для хранения данных, поэтому в одной базе данных можно использовать несколько кодировок.
Различные структуры хранения баз данных низкого уровня используются механизмом хранения для сериализации модели данных, чтобы ее можно было записать на выбранный носитель. Такие методы, как индексирование, могут использоваться для повышения производительности. Обычное хранение ориентировано на строки, но существуют также столбцовые и корреляционные базы данных.
Часто избыточность хранилища используется для повышения производительности. Типичным примером является хранение материализованных представлений , которые состоят из часто используемых внешних представлений или результатов запросов. Хранение таких представлений экономит дорогостоящее вычисление их каждый раз, когда они нужны. Недостатками материализованных представлений являются накладные расходы, возникающие при их обновлении для синхронизации с исходными обновленными данными базы данных, а также стоимость избыточности хранилища.
Иногда база данных использует избыточность хранилища путем репликации объектов базы данных (с одной или несколькими копиями) для повышения доступности данных (как для повышения производительности одновременного доступа нескольких конечных пользователей к одному и тому же объекту базы данных, так и для обеспечения устойчивости в случае частичного отказа распределенной базы данных). Обновления реплицированного объекта должны быть синхронизированы между копиями объектов. Во многих случаях реплицируется вся база данных.
При виртуализации данных используемые данные остаются в своих исходных местах, и устанавливается доступ в режиме реального времени, позволяющий проводить аналитику по нескольким источникам. Это может помочь в решении некоторых технических трудностей, таких как проблемы совместимости при объединении данных с различных платформ, снижение риска ошибок, вызванных неверными данными, и гарантия использования новейших данных. Кроме того, избегание создания новой базы данных, содержащей персональную информацию, может облегчить соблюдение правил конфиденциальности. Однако при виртуализации данных подключение ко всем необходимым источникам данных должно быть работоспособным, поскольку локальной копии данных нет, что является одним из главных недостатков подхода. [34]
Безопасность базы данных касается всех различных аспектов защиты содержимого базы данных, ее владельцев и пользователей. Она варьируется от защиты от преднамеренного несанкционированного использования базы данных до непреднамеренного доступа к базе данных неавторизованными субъектами (например, человеком или компьютерной программой).
Управление доступом к базе данных занимается контролем того, кому (лицу или определенной компьютерной программе) разрешен доступ к какой информации в базе данных. Информация может включать определенные объекты базы данных (например, типы записей, определенные записи, структуры данных), определенные вычисления над определенными объектами (например, типы запросов или определенные запросы) или использование определенных путей доступа к первым (например, использование определенных индексов или других структур данных для доступа к информации). Управление доступом к базе данных устанавливается специальным уполномоченным (владельцем базы данных) персоналом, который использует выделенные защищенные интерфейсы безопасности СУБД.
Это может управляться напрямую на индивидуальной основе или путем назначения лиц и привилегий группам, или (в наиболее сложных моделях) путем назначения лиц и групп ролям, которым затем предоставляются права. Безопасность данных предотвращает просмотр или обновление базы данных неавторизованными пользователями. Используя пароли, пользователям разрешается доступ ко всей базе данных или ее подмножествам, называемым «подсхемами». Например, база данных сотрудников может содержать все данные об отдельном сотруднике, но одна группа пользователей может быть авторизована для просмотра только данных о заработной плате, в то время как другим разрешен доступ только к истории работы и медицинским данным. Если СУБД предоставляет способ интерактивного входа и обновления базы данных, а также для ее опроса, эта возможность позволяет управлять персональными базами данных.
Безопасность данных в целом касается защиты определенных фрагментов данных как физически (т. е. от повреждения, уничтожения или удаления; например, см. физическая безопасность ), так и их интерпретации или частей для получения значимой информации (например, путем просмотра строк битов, которые они содержат, вывода конкретных действительных номеров кредитных карт; например, см. шифрование данных ).
Изменения и доступ регистрируют записи о том, кто получил доступ к каким атрибутам, что было изменено и когда это было изменено. Службы регистрации позволяют проводить судебный аудит базы данных позже, сохраняя запись случаев доступа и изменений. Иногда код уровня приложения используется для записи изменений, а не для того, чтобы оставлять их в базе данных. Мониторинг может быть настроен для попытки обнаружения нарушений безопасности. Поэтому организации должны серьезно относиться к безопасности базы данных из-за множества преимуществ, которые она предоставляет. Организации будут защищены от нарушений безопасности и хакерских действий, таких как вторжение через брандмауэр, распространение вирусов и программы-вымогатели. Это помогает защитить важную информацию компании, которая ни при каких обстоятельствах не может быть передана посторонним лицам. [35]
Транзакции базы данных могут использоваться для введения некоторого уровня отказоустойчивости и целостности данных после восстановления после сбоя . Транзакция базы данных — это единица работы, обычно инкапсулирующая ряд операций над базой данных (например, чтение объекта базы данных, запись, получение или снятие блокировки и т. д.), абстракция, поддерживаемая в базе данных, а также в других системах. Каждая транзакция имеет четко определенные границы с точки зрения того, какие выполнения программы/кода включены в эту транзакцию (определяются программистом транзакции с помощью специальных команд транзакции).
Аббревиатура ACID описывает некоторые идеальные свойства транзакции базы данных: атомарность , согласованность , изолированность и долговечность .
База данных, созданная с помощью одной СУБД, непереносима на другую СУБД (т. е. другая СУБД не может ее запустить). Однако в некоторых ситуациях желательно перенести базу данных из одной СУБД в другую. Причины в первую очередь экономические (разные СУБД могут иметь разную общую стоимость владения или TCO), функциональные и эксплуатационные (разные СУБД могут иметь разные возможности). Миграция включает в себя преобразование базы данных из одного типа СУБД в другой. Преобразование должно сохранить (если возможно) связанное с базой данных приложение (т. е. все связанные прикладные программы) нетронутым. Таким образом, концептуальный и внешний архитектурные уровни базы данных должны быть сохранены при преобразовании. Может быть желательно, чтобы также были сохранены некоторые аспекты внутреннего уровня архитектуры. Сложная или большая миграция базы данных может быть сложным и дорогостоящим (единовременным) проектом сама по себе, что должно быть учтено при принятии решения о миграции. И это несмотря на то, что могут существовать инструменты, помогающие выполнять миграцию между определенными СУБД. Обычно поставщик СУБД предоставляет инструменты, помогающие импортировать базы данных из других популярных СУБД.
После проектирования базы данных для приложения следующим этапом является построение базы данных. Обычно для этой цели может быть выбрана соответствующая универсальная СУБД. СУБД предоставляет необходимые пользовательские интерфейсы , которые администраторы баз данных могут использовать для определения необходимых структур данных приложения в соответствующей модели данных СУБД. Другие пользовательские интерфейсы используются для выбора необходимых параметров СУБД (например, связанных с безопасностью, параметров распределения памяти и т. д.).
Когда база данных готова (все ее структуры данных и другие необходимые компоненты определены), она обычно заполняется начальными данными приложения (инициализация базы данных, которая обычно является отдельным проектом; во многих случаях с использованием специализированных интерфейсов СУБД, которые поддерживают массовую вставку) перед тем, как сделать ее рабочей. В некоторых случаях база данных становится рабочей, будучи пустой от данных приложения, и данные накапливаются во время ее работы.
После создания, инициализации и заполнения базы данных ее необходимо обслуживать. Различные параметры базы данных могут потребовать изменения, а также может потребоваться настройка ( настройка ) базы данных для повышения производительности; структуры данных приложения могут быть изменены или добавлены, могут быть написаны новые связанные прикладные программы для расширения функциональности приложения и т. д.
Иногда желательно вернуть базу данных в предыдущее состояние (по многим причинам, например, в случаях, когда база данных оказывается поврежденной из-за ошибки программного обеспечения или если она была обновлена ошибочными данными). Для достижения этого операция резервного копирования выполняется время от времени или постоянно, при этом каждое желаемое состояние базы данных (т. е. значения ее данных и их внедрение в структуры данных базы данных) сохраняется в выделенных файлах резервных копий (существует много методов, позволяющих сделать это эффективно). Когда администратор базы данных решает вернуть базу данных в это состояние (например, указав это состояние на желаемый момент времени, когда база данных находилась в этом состоянии), эти файлы используются для восстановления этого состояния.
Методы статического анализа для проверки программного обеспечения могут применяться также в сценарии языков запросов. В частности, * Структура абстрактной интерпретации была расширена до области языков запросов для реляционных баз данных как способ поддержки надежных методов аппроксимации. [36] Семантика языков запросов может быть настроена в соответствии с подходящими абстракциями конкретной области данных. Абстракция систем реляционных баз данных имеет много интересных приложений, в частности, для целей безопасности, таких как мелкозернистый контроль доступа, водяные знаки и т. д.
Другие функции СУБД могут включать:
Все чаще звучат призывы к созданию единой системы, которая объединяет все эти основные функции в одну и ту же структуру сборки, тестирования и развертывания для управления базами данных и контроля исходного кода. Заимствуя из других разработок в индустрии программного обеспечения, некоторые предлагают такие предложения как « DevOps для базы данных». [37]
Первая задача проектировщика базы данных — создать концептуальную модель данных , которая отражает структуру информации, которая будет храниться в базе данных. Распространенным подходом к этому является разработка модели сущности-связи , часто с помощью инструментов рисования. Другим популярным подходом является унифицированный язык моделирования . Успешная модель данных будет точно отражать возможное состояние внешнего мира, который моделируется: например, если у людей может быть более одного номера телефона, это позволит зафиксировать эту информацию. Разработка хорошей концептуальной модели данных требует хорошего понимания предметной области; обычно это включает в себя постановку глубоких вопросов о вещах, представляющих интерес для организации, например, «может ли клиент также быть поставщиком?» или «если продукт продается в двух разных формах упаковки, это один и тот же продукт или разные продукты?» или «если самолет летит из Нью-Йорка в Дубай через Франкфурт, это один рейс или два (или даже три)?». Ответы на эти вопросы устанавливают определения терминологии, используемой для сущностей (клиентов, продуктов, рейсов, сегментов полета) и их отношений и атрибутов.
Создание концептуальной модели данных иногда требует ввода бизнес-процессов или анализа рабочего процесса в организации. Это может помочь установить, какая информация необходима в базе данных, а что можно исключить. Например, это может помочь при принятии решения о том, должна ли база данных хранить исторические данные, а также текущие данные.
После создания концептуальной модели данных, которая устраивает пользователей, следующим этапом является ее перевод в схему , которая реализует соответствующие структуры данных в базе данных. Этот процесс часто называют логическим проектированием базы данных, а на выходе получается логическая модель данных, выраженная в виде схемы. В то время как концептуальная модель данных (по крайней мере, теоретически) независима от выбора технологии базы данных, логическая модель данных будет выражена в терминах конкретной модели базы данных, поддерживаемой выбранной СУБД. (Термины модель данных и модель базы данных часто используются взаимозаменяемо, но в этой статье мы используем модель данных для проектирования конкретной базы данных, а модель базы данных — для нотации моделирования, используемой для выражения этого проектирования).
Наиболее популярной моделью базы данных для баз данных общего назначения является реляционная модель, или, точнее, реляционная модель, представленная языком SQL. Процесс создания логического проекта базы данных с использованием этой модели использует методический подход, известный как нормализация . Цель нормализации — гарантировать, что каждый элементарный «факт» записан только в одном месте, так что вставки, обновления и удаления автоматически поддерживают согласованность.
Заключительный этап проектирования базы данных заключается в принятии решений, которые влияют на производительность, масштабируемость, восстановление, безопасность и т. п., которые зависят от конкретной СУБД. Это часто называют физическим проектированием базы данных , а результатом является физическая модель данных . Ключевой целью на этом этапе является независимость данных , то есть решения, принимаемые в целях оптимизации производительности, должны быть невидимы для конечных пользователей и приложений. Существует два типа независимости данных: физическая независимость данных и логическая независимость данных. Физическое проектирование в основном обусловлено требованиями к производительности и требует хорошего знания ожидаемой рабочей нагрузки и шаблонов доступа, а также глубокого понимания функций, предлагаемых выбранной СУБД.
Другим аспектом физического проектирования базы данных является безопасность. Она включает в себя как определение контроля доступа к объектам базы данных, так и определение уровней и методов безопасности для самих данных.
Модель базы данных — это тип модели данных, которая определяет логическую структуру базы данных и принципиально определяет, каким образом данные могут храниться, организовываться и обрабатываться. Наиболее популярным примером модели базы данных является реляционная модель (или приближение SQL к реляционной), которая использует табличный формат.
К общим логическим моделям данных для баз данных относятся:
Объектно-реляционная база данных объединяет две связанные структуры.
Физические модели данных включают в себя:
Другие модели включают в себя:
Специализированные модели оптимизированы для определенных типов данных:
Система управления базами данных обеспечивает три представления данных базы данных:
Хотя обычно существует только одно концептуальное и внутреннее представление данных, может быть любое количество различных внешних представлений. Это позволяет пользователям видеть информацию базы данных в более деловом ключе, а не с технической, обрабатывающей точки зрения. Например, финансовому отделу компании нужны платежные реквизиты всех сотрудников как часть расходов компании, но не нужны сведения о сотрудниках, которые представляют интерес для отдела кадров . Таким образом, разным отделам нужны разные представления базы данных компании.
Трехуровневая архитектура базы данных относится к концепции независимости данных , которая была одной из основных начальных движущих сил реляционной модели. [39] Идея заключается в том, что изменения, внесенные на определенном уровне, не влияют на представление на более высоком уровне. Например, изменения на внутреннем уровне не влияют на прикладные программы, написанные с использованием интерфейсов концептуального уровня, что снижает влияние внесения физических изменений для повышения производительности.
Концептуальное представление обеспечивает уровень косвенности между внутренним и внешним. С одной стороны, оно обеспечивает общее представление базы данных, независимое от различных структур внешнего представления, а с другой стороны, оно абстрагирует детали того, как данные хранятся или управляются (внутренний уровень). В принципе, каждый уровень и даже каждое внешнее представление могут быть представлены другой моделью данных. На практике обычно данная СУБД использует одну и ту же модель данных как для внешнего, так и для концептуального уровней (например, реляционную модель). Внутренний уровень, который скрыт внутри СУБД и зависит от ее реализации, требует другого уровня детализации и использует свои собственные типы структур данных.
Технология баз данных была активной темой исследований с 1960-х годов, как в академических кругах , так и в группах компаний, занимающихся исследованиями и разработками (например, IBM Research ). Исследовательская деятельность включает теорию и разработку прототипов . Известные темы исследований включают модели , концепцию атомарных транзакций, связанные методы управления параллелизмом , языки запросов и методы оптимизации запросов , RAID и многое другое.
Область исследований баз данных имеет несколько специализированных академических журналов (например, ACM Transactions on Database Systems - TODS, Data and Knowledge Engineering - DKE) и ежегодных конференций (например, ACM SIGMOD , ACM PODS , VLDB , IEEE ICDE).
Определения из Викисловаря
Медиа из Commons
Новости из Викиновостей
Цитаты из Викицитатника
Тексты из Викиресурса
Учебники из Wikibooks
Ресурсы из Викиверситета