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

Предпосылки появления БД и СУБД

Назначение баз данных в юридической деятельности

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

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

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

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

Предпосылки появления БД и СУБД

Понятия база данных БД (database – DB) и СУБД (Database Management System – DBMS) появились в компьютерном мире в середине 60-х годов, когда ЭВМ начали активно использоваться в управлении и программисты стали переходить от решения от дельных задач к комплексной автоматизации управления, увязывая все задачи в единое целое общей целью.

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

Преимуществанового подхода:

· однократный ввод данных, что приводит к резкому сокращению затрат труда;

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

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

Источник

BestProg

Общие сведения о базах данных. История развития систем управления базами данных

Содержание

Поиск на других ресурсах:

1. История появления СУБД. Какие причины возникновения СУБД?

В истории использования вычислительной техники (ВТ) можно выделить несколько направлений ее использования.

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

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

Развитие этого направления привело к тому, что в конце 60-х, в начале 70-х годов появилось специализированное программное обеспечение, которое получило название Система управления базами данных (DataBase Management System – DBMS).

2. Какое назначение систем управления базами данных (СУБД)? Что такое база данных?

Основой любой современной информационной системы есть система управления базами данных.

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

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

3. Какие основные свойства систем управления базами данных?

Для всех существующих систем управления базами данных можно выделить следующие основные свойства:

4. Какие тенденции влияют на эволюцию систем управления базами данных?

На эволюцию систем управления базами данных влияют:

5. Какие были этапы в истории развития и усовершенствование систем управления базами данных?

В истории развития СУБД можно выделить три основных этапа.

Этап 1. Этому этапу соответствуют СУБД первого поколения. Такие системы управления базами данных имели иерархическую и сетевую модели данных. Эти модели базировались на спецификациях CODASYL. В СУБД первого поколения информационные системы базировались на мейнфреймах (mainframe) – больших вычислительных машинах (например, IBM 360).

СУБД первого поколения имели ряд недостатков в сравнении с СУБД следующих поколений.

Этап 2. На этом этапе появляются реляционные СУБД (начало 70-х годов XX века). На сегодняшний день реляционные базы данных есть одними из наиболее популярных. В таких базах данных информация сохраняется в виде таблиц, которые связаны между собой отношениями (relations).

Этап 3. Этот этап характерен появлением объектно-ориентированных СУБД, которые основаны на использовании объектно-ориентированной парадигмы проектирования баз данных.

6. Какие преимущества и недостатки имели СУБД первого поколения?

Недостатки СУБД первого поколения сравнительно с СУБД второго поколения:

Преимущества СУБД первого поколения:

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

В своей теории Э. Кодд предложил такие два основных принципа:

8. Какие преимущества использования реляционных СУБД по сравнению с СУБД первого поколения?

Реляционная СУБД имеют ряд преимуществ в сравнении с СУБД первого поколения:

9. По какому принципу работают объектно-ориентированные СУБД?

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

10. Какие преимущества и недостатки использования объектно-ориентированных СУБД?

Преимущества объектно-ориентированных СУБД:

Недостатки объектно-ориентированных СУБД:

11. Что такое гибридные объектно-реляционные СУБД?

Гибридные СУБД объединяют в себе оба вышеуказанных подхода: реляционный подход и объектно-ориентированный подход. Например, СУБД Oracle имеет объектно-ориентированную надстройку над реляционным ядром системы.

Источник

ИСТОРИЯ РАЗВИТИЯ СУБД

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

Основные функции СУБД:

управление данными во внешней памяти (на дисках);

управление данными в оперативной памяти с использованием дискового кэша;

журнализация изменений, резервное копирование и восстановление базы данных после сбоев;

поддержка языков БД (язык определения данных, язык манипулирования данными) [1].

Обычно современная СУБД содержит следующие компоненты:

ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию,

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

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

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

Классификации СУБД по моделям данных:

По степени распределённости:

Локальные СУБД (все части локальной СУБД размещаются на одном компьютере);

Распределённые СУБД (части СУБД могут размещаться на двух и более компьютерах).

По способу доступа к БД:

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

Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера.

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

На данный момент файл-серверная технология считается устаревшей, а её использование в крупных информационных системах — недостатком [1].

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

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

Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу.

Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик, как высокая надёжность, высокая доступность и высокая безопасность.

Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.

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

2. История возникновения и развития баз данных

В истории вычислительной техники можно проследить развитие двух основных областей ее использования:

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

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

— надежное хранение информации в памяти компьютера;

— выполнение специфических для данного приложения преобразований информации и вычислений;

— предоставление пользователям удобного и легко осваиваемого интерфейса [2].

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

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

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

создать файл (требуемого типа и размера);

открыть ранее созданный файл;

прочитать из файла некоторую запись (текущую, следующую, предыдущую, первую, последнюю);

записать в файл на место текущей записи новую, добавить новую запись в конец файла [1].

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

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

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

Одновременная работа нескольких пользователей во многопользовательских ОС, связанная с модификацией данных в файле, либо вообще не реализовывалась, либо очень замедлена.

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

История развития СУБД насчитывает более 30 лет. В 1968 году была введена в эксплуатацию первая промышленная СУБД система IMS фирмы IBM. В 1975 году появился первый стандарт ассоциации по языкам систем обработки данных — Conference of Data System Languages (CODASYL), который определил ряд фундаментальных понятий в теории систем баз данных, которые и до сих пор являются основополагающими для сетевой модели данных. В дальнейшее развитие теории баз данных большой вклад был сделан американским математиком Э. Ф. Коддом, который является создателем реляционной модели данных. В 1981 году Э. Ф. Кодд получил за создание реляционной модели и реляционной алгебры престижную премию Тьюринга Американской ассоциации по вычислительной технике.

Развитие вычислительной техники повлияло также и на развитие технологии баз данных. Можно выделить четыре этапа в развитии данного направления в обработке данных.

Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment Corporation — DEC), разных моделях HP (фирмы Hewlett Packard) [2].

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

Особенности этого этапа развития выражаются в следующем:

Все СУБД базируются на мощных мультипрограммных операционных системах (MVS, SVM, RTE, OSRV, RSX, UNIX), поэтому в основном поддерживается работа с централизованной базой данных в режиме распределенного доступа.

Функции управления распределением ресурсов в основном осуществляются операционной системой (ОС).

Поддерживаются языки низкого уровня манипулирования данными, ориентированные на навигационные методы доступа к данным.

Значительная роль отводится администрированию данных [2].

Проводятся серьезные работы по обоснованию и формализации реляционной модели данных, и была создана первая система (System R), реализующая идеологию реляционной модели данных [2].

Проводятся теоретические работы по оптимизации запросов и управлению распределенным доступом к централизованной БД, было введено понятие транзакции.

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

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

Второй этап – это этап развития персональных компьютеров.

Особенности этого этапа следующие:

Все СУБД были рассчитаны на создание БД в основном с монопольным доступом.

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

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

При наличии высокоуровневых языков манипулирования данными типа реляционной алгебры и SQL в настольных СУБД поддерживались низкоуровневые языки манипулирования данными на уровне отдельных строк таблиц.

В настольных СУБД отсутствовали средства поддержки ссылочной и структурной целостности базы данных. Эти функции должны были выполнять приложения.

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

Сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД.

Представители этого семейства — очень широко использовавшиеся до недавнего времени СУБД Dbase (DbaseIII+, DbaseIV), FoxPro, Clipper, Paradox.

Особенности этого этапа:

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

О структурной целостности — допустимыми являются только данные, представленные в виде отношений реляционной модели;

О языковой целостности, то есть языков манипулирования данными высокого уровня (в основном SQL);

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

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

Необходимость поддержки многопользовательской работы с базой данных и возможность децентрализованного хранения данных потребовали развития средств администрирования БД с реализацией общей концепции средств защиты данных.

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

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

Разработка стандартов языков описания и манипулирования данными SQL89, SQL92, SQL99 и технологий по обмену данными между различными СУБД.

Разработка концепцией объектно-ориентированных БД — ООБД. Представителями СУБД, относящимся к второму этапу, можно считать MS Access 97 и все современные серверы баз данных Oracle7.3,Oracle 8.4 MS SQL6.5, MS SQL7.0, System 10, System 11, Informix, DB2, SQL Base и другие современные серверы баз данных, которых в настоящий момент насчитывается несколько десятков [2].

Четвертый этап характеризуется появлением новой технологии доступа к данным — интранет.

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

При этом встроенный в загружаемые пользователем HTML-страницы код, написанный обычно на языке Java, Java-script, Perl и других, отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа. Сложные задачи реализованы в архитектуре «клиент-сервер» с разработкой специального клиентского программного обеспечения [2].

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

Кроме классических БД, предназначенных в основном для хранения текстовой и числовой информации, в последнее время получили развитие новые направления применения технологии БД:

— БД мультимедиа (Multimedia Databases);

— системы реального времени и активные БД (Real-time and Active Database Technology), использующиеся для контроля проектирования и производства;

— Интернет БД, включающий серверные БД и поисковые системы.

Источник

Реляционные СУБД: история появления, эволюция и перспективы

Привет, Хабр! Меня зовут Азат Якупов, я работаю Data Architect в компании Quadcode. Сегодня хочу поговорить о реляционных СУБД, которые играют важную роль в современном IT-мире. О том, что они собой представляют и для чего нужны, понимают, вероятно, большинство читателей.

Но вот как и почему появились реляционные СУБД? Об этом многие из нас знают лишь приблизительно. А ведь история создания технологии весьма интересна, она позволяет лучше понять основу цифрового мира. Если вам интересна эта тема — прошу под кат.

Как всё начиналось

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

У банков худо-бедно получалось записывать информацию о транзакциях в виде файлов в заранее подготовленную структуру. У каждой организации было собственное понимание того, как все это должно выглядеть и работать. Не было таких понятий, как консистентность (англ. data consistency), целостности данных (англ. data integrity). В файлах часто встречались дубликаты данных клиентов и их транзакций, которые необходимо было каким-то образом уточнять и приводить в порядок, делалось это в основном вручную. В целом все проблемы того времени в отношении работы с данными можно разделить на несколько основных видов:

Представление структуры в каждом файле было различным.

Необходимо было согласовывать данные в разных файлах, чтобы обеспечить непротиворечивость информации.

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

По сути, здесь мы видим антипаттерн «чистой архитектуры», который был описан Робертом Мартином (Robert C. Martin).

Следует отметить, что были попытки создания моделей, позволяющих навести порядок в данных и их обработке. Одна из таких попыток — иерархическая модель, в которой данные были организованы в виде древовидной структуры. Иерархическая модель была востребованной, но не гибкой. В ней каждая запись могла иметь только одного «предка», даже если отдельные записи могли иметь несколько «потомков». Из-за этого базы данных представляли только отношения «один к одному» или «один ко многим». Невозможность реализации отношения «многие ко многим» могла привести к проблемам при работе с данными и усложняла модель. Более того, вопросы консистентности данных и отсутствия дублирования информации здесь вообще не стояли. Первая иерархическая СУБД называлась IMS от IBM.

На помощь иерархической пришла сетевая модель данных, и уже новая концепция реализовала отношение «многие ко многим». Данный подход был предложен как спецификация модели CODASYL в рамках рабочей группы DBTG (Data Base Task Group).

Но всё это модели, которые сложно было поддерживать. Упростить задачу сбора и обработки данных смог Франк Кодд (Edgar F. Codd). Его фундаментальная работа привела к появлению реляционных баз данных, которые нужны практически всем отраслям. Кодд предложил язык Alpha для управления реляционными данными. Коллеги Кодда из IBM — Дональд Чемберлен (Donald Chamberlin) и Рэймонд Бойс (Raymond Boyce) — создали один из языков под влиянием работы Кодда. Они назвали свой язык SEQUEL (Structured English Query Language), но изменили название на SQL из-за существующего товарного знака.

Появление реляционных БД и их эволюция

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

Отсутствие дублирования данных.

Исключение ряда ошибок и аномалий данных, которые есть в других моделях.

Все данные представлены как факты, хранящиеся в виде отношений (relations) со столбцами (attributes) и строками (tuples).

Одной из первых РСУБД можно назвать dBase-II от компании Ashton-Tate, которая выпустила свой продукт в 1979 году. Она смогла поставить на рынок около 100 000 копий своего продукта. В итоге эта база данных стала самой популярной среди всех существовавших в то время продуктов. К слову, компанию Ashton-Tate позже приобрела фирма Borland. В целом реляционной СУБД этот продукт можно было назвать лишь с очень большой натяжкой.

Но начало было положено — и другие компании стали представлять свои продукты. Так, например, появились Oracle, Ingress и Focus.

К 1980 году сформировалось архитектурное (высокоуровневое) и инженерное (низкоуровневое) понимание того, как должна функционировать РСУБД. И пришло решение о введении стандарта (SQL Standard ISO and ANSI).

Развитие баз данных усилилось после распространения локальных сетей, а затем и сети глобальной. Сеть позволяла совместно использовать оборудование. Также пользователи хотели совместно (параллельно) работать с РСУБД, что ускорило развитие многопользовательских приложений для локальных сетей. Была создана клиент-серверная архитектура обработки данных.

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

В это же время стали появляться первые онлайн-сервисы (например, отправка цветов, подарков, открыток, ведение блогов и т. п.). Большинство этих сервисов стали (и продолжают) работать в связке PHP + MySQL.

Распространение сотовой связи и сотовых телефонов с 1996 года привело к созданию специализированных баз данных для обработки информации в мобильном устройстве. Сейчас они эволюционировали в отдельный стек баз данных (In-Memory) и применяются либо в качестве кэша данных, находясь перед основной базой данных, либо в качестве Warm / Hot логического слоя, используясь в Lambda / Kappa архитектуре.

По моему мнению, в 2000-х произошла своеобразная эволюция, когда нереляционная модель была интегрирована в реляционную базу данных (я говорю про интеграцию XML-формата). Можно было определять модель в модели (по сути, описать любую модель можно в одном столбце таблицы). Примерами технической реализации такого «фрактального моделирования» были Oracle Nested Tables, а также тип XML, а в последствии JSON. Такие модели назвали Post-Relational Models, и можно сказать, что начали появляться зачатки работы с noSQL-моделями формата «ключ-значение / ключ-документ».

Значение и ценность данных стал постепенно осознавать бизнес, в результате чего возросла необходимость в соответствующих специалистах. Технологии БД стали использовать далеко не только для OLTP и OLAP-трафиков, но и для глубоких исследований в данных (поиск аномалий, корреляций, использование статистического аппарата и т. д.).

С 2006 года начал работать облачный сервис Amazon AWS, по словам его представителей, сейчас он насчитывает уже свыше 20 000 частных Data Lakes, построенных внутри облака.

Ну а сейчас роль баз данных возросла еще больше. Ведь данные генерирует любое умное устройство, а их становится всё больше. Это уже не только телевизоры или смартфоны, но и зубные щетки и даже чайники (IOT-трафик, не путать с Index-Organized Tables! 😉

Правда, с увеличением объема данных стало больше и узконаправленных баз данных, которые специализируются на работе с разными типами информации и моделями.

Реляционных СУБД не так много (по сравнению с нереляционными базами данных), но архитектура каждой из них уникальна. У каждой есть свои плюсы и минусы. Также можно отметить, что в мире не существует РСУБД, которая полностью бы описывала математическую реляционную модель Франка Кодда, кроме одной с именем Rel и языком Tutorial-D. Почему это так? Неужели сложность в технической реализации реляционной теории? Нет, конечно. По моему мнению, на самом деле все проще: бизнес неявно диктует свои условия реализации хранения и обработки данных. Давайте вспомним некоторые основные свойства отношений (relations) в рамках реляционной теории и сравним их с реальной жизнью.

“All tuples are unique“. Это значит, что необходимо хранить один факт о свершившимся событии из реального мира. Данное утверждение также поддерживает определение простейшего уникального ключа для отношения, который должен включать весь набор атрибутов отношения.

2. “The order of the lines is irrelevant”. Зачем нам вообще вводить такое понятие, как сортировка строк, а тем более по конкретным атрибутам, да еще в возрастании / убывании или на основании формулы? Хм, вообще, это требование недопустимо!

3.“The order of the columns is irrelevant”. Столбцы (attributes) мы можем переставлять как угодно, так как R(A,B,C) = R(B,C,A).

4.“Each attribute has a unique name within a table”. Каждый атрибут отношения должен иметь уникальное имя.

5.“Each column represents a single data element”. С одной стороны — вопрос нормализации. С другой — вопрос денормализации и ускорения работы модели.

6.“NULL value support”. NULL (𝒘) означает информацию, непригодную для употребления, а в действительности мы можем использовать значение NULL как статус значения в нашей модели.

Более того, каждая РСУБД по-своему интерпретирует NULL значения. Попробуйте выполнить команду ниже для PostgreSQL / MySQL:

и команду для Oracle:

Просто Oracle использует тождество NULL

» (пустая строка), и именно эта фича принесла немало боли во время миграций кодовой базы из Oracle в PostgreSQL (особенно если у вас на проекте витрины данных с материализациями на основании сортировок в оконных функциях и сами оконные функции, основанные на конкатенациях атрибутов).

Что дальше

Каждый виток спирали в IT-индустрии знаменуется очередным открытием модели или подходом в реализации. Так было с реляционными базами данных, затем на сцене появились объектно-ориентированные базы данных, после ворвались noSQL с лозунгом «Долой жесткие структуры отношений!». Я уверен, что эта история будет повторяться снова и снова в зависимости от вызовов, которые стоят уже сейчас и будут появляться перед IT-сообществом.

Но тем не менее сейчас следует обратить внимание на то, что в топ-5 баз данных 4 первых места занимают реляционные базы данных (по данным исследования Solid IT).

Почему это так? Как, учитывая полувековую историю, РСУБД может претендовать на такое высокое место в современном мире? Может быть, причина в legacy кода и созданных структурах моделей, которые нужно поддерживать в рамках реляционных баз данных? Или же причина в том, что переходить на более современные движки слишком дорого?

Можно вспомнить, что у реляционных баз данных есть принцип ACID и фундаментальный математический аппарат. А у нереляционных баз данных есть BASE-семантика с более «мягкими» условиями функционирования и моделирования, а также набор алгоритмов, поддерживающих работу с данными. Семантика против Принципа, иногда хочется жить по Принципам без аномалий в данных и в режиме SERIALIZABLE.

Но все-таки истина лежит где-то посередине, и это видно в разных архитектурах проектов, когда используется «зоопарк» (в хорошем смысле слова) гетерогенных баз данных и их интеграция между собой. А особенно это прослеживается при создании общих хранилищ данных (DWH + Data Lake) в корпорациях.

Как совместить OLAP и OLTP и получить полноценные «диагональные» базы данных? Почему бы не посмотреть в сторону дедуктивных баз данных? Наконец, почему бы полноценно не привлечь весь аппарат Data Science в движки оптимизаторов и обработки информации?

Новое отдельное направление — Data Engineering дает сильный толчок в исследованиях не только данных, но и в поиске архитектуры / интеграции / валидации данных для конкретного бизнес-домена. Появляются стандарты определения данных / информации / знаний / мудрости, что перерастает в обобщенное логическое восприятие информации через разные логические слои данных (тут я могу сослаться на книгу DAMA-DMBOK) при помощи новых инженерных ролей и разграничения ответственности в направлении Data Engineering:

Data Quality Engineer

Data Science Engineer (все-таки они тоже работают с данными).

Если у вас есть интересные идеи по поводу перспектив развития баз данных, моделей, стандартов и Data Engineering в целом — давайте обсудим в комментариях.

Источник