Базы данных — зачем они нужны и какие бывают виды?

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

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

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

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

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

Сначала были разработаны сетевые и иерархические модели баз данных. Однако вскоре они оказались слишком простыми и технически ограниченными. В 1970-х годах компания IBM совершила серьезный прорыв, разработав гораздо более мощную реляционную модель баз данных, которая быстро вошла в рабочую жизнь. Наиболее успешными продуктами этого времени стали язык баз данных SQL от Oracle и последующие продукты от IBM, SQL/DS и DB2.

До 2000-х годов известные производители доминировали на рынке программного обеспечения для баз данных, пока несколько проектов с открытым исходным кодом не внесли глоток свежего воздуха. К наиболее популярным системам со свободным доступом относятся MySQL и PostgreSQL. Тенденция перехода к системам NoSQL, начавшаяся в 2001 году, продолжила традицию реляционных систем баз данных, начатую производителями.

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

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

Широко используемым термином для описания функций и требований к транзакциям в системе управления базами данных является ACID, сокращение от atomicity, consistency, isolation, and durability. Частичные термины ACID охватывают наиболее важные требования к СУБД:

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

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

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

Самой старой моделью баз данных является иерархическая. С тех пор она была заменена реляционной базой данных и другими моделями. Однако в последнее время иерархическая модель используется все чаще и чаще: XML, например, использует простую систему для хранения данных. То тут, то там страховые компании и банки все еще используют иерархические базы данных, особенно для старых приложений баз данных. Наиболее известной системой иерархических баз данных является IMS/DB от IBM.

Иерархические базы данных имеют очень четкие зависимости. Это означает, что каждая запись данных имеет ровно одного предшественника (отношения «родитель-ребенок», PCR), кроме корня базы данных. Это приводит к древовидной структуре, показанной выше. Хотя каждый «ребенок» может иметь только одного «родителя», каждый «родитель» может иметь любое количество «детей». Из-за строгого иерархического порядка слои, которые не являются непосредственно смежными, не могут взаимодействовать друг с другом. Кроме того, связь между двумя различными деревьями не может быть легко установлена. Поэтому иерархические структуры баз данных чрезвычайно негибкие, хотя и очень понятные.

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

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

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

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

Сегодня сетевая модель базы данных используется в основном на мэйнфреймах. В других областях продолжают доверять либо иерархической модели (особенно для клиентов IBM), либо переходят на более гибкую и простую в использовании реляционную модель. Известными моделями сетевых баз данных являются UDS от Siemens и DMS от Sperry Univac. За прошедшие годы обе компании также разработали интересные гибриды между сетевой и реляционной моделями, не добившись настоящего прорыва. Однако результаты этого испытания можно проследить в Siemens SQL и сегодня. Современным дальнейшим развитием сетевой модели является графовая база данных, структура которой напоминает сеть.

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

Реляционная модель базы данных работает с отдельными таблицами, которые определяют локализацию и связи между информацией. Эта информация образует набор данных (в диаграмме строки или «кортеж»). Индивидуальная информация собирается в виде атрибутов (в диаграмме A1 — An) в столбцах. Общее отношение («отношение» часто используется как синоним термина «таблица») формируется из связанных атрибутов. Первичный ключ, который обычно определяется как первый атрибут (A1) и никогда не должен меняться, является элементарным для уникальной идентификации записи данных. Другими словами, этот так называемый первичный ключ (также «ID») определяет точную позицию следующего набора данных со всеми атрибутами.

Объектные базы данных были разработаны только в конце 1980-х годов и до сих пор находят мало областей применения. Объектно-ориентированные базы данных, некоторые из которых доступны с открытым исходным кодом, чаще всего используются на платформах Java и .NET. Самой известной объектной базой данных является db40, которая выигрывает, прежде всего, благодаря небольшому объему памяти. Объектные базы данных обычно работают с языком запросов OQL, который очень похож на SQL.

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

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

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

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

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

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

Системы баз данных на основе документов особенно интересны для веб-приложений, поскольку в них можно вводить полные HTML-формы. Особенно в ходе развития web 2.0 документальные базы данных становились все более популярными. Однако между различными документо-ориентированными системами баз данных существуют значительные различия, начиная от синтаксиса и заканчивая внутренней структурой. Таким образом, не каждая база данных документов подходит для каждой области применения. Именно благодаря этим различным итерациям сегодня существует несколько известных систем документно-ориентированных баз данных: Lotus Notes, Amazon SimpleDB, Mongo DB, CouchDB, ThruDB, Orient DB и многие другие.