Реляционные базы данных примеры программ

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

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

Что такое реляционная база данных?

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

В большинстве реляционных БД используется структурированный язык запросов -— SQL (Structured Query Language) для создания и поддержки данных.

Структурирование данных в реляционной базы данных

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

ЧТО ТАКОЕ РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ

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

Строка таблицы является основной логической единицей обработки в реляционной БД.

Реляционная таблица имеет основные свойства:

• в таблице не должно присутствовать две одинаковые строки;
• каждая строка должна содержать только одно значение каждого атрибута.

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

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

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

Примеры реляционных СУБД

MySQL

Самая популярная реляционная база данных. MySQL обладает открытым исходным кодом и принадлежит корпорации Oracle.

MySQL обладает простой структурой и стилем. Гибкость базы данных дает возможность выполнять большинство задач прямо в командной строке. MySQL может работать в облачных решениях а так же на Amazon, Microsoft и других.

Что такое SQL и реляционные базы данных

Из минусов можно отметить, что MySQl имеет проблемы с масштабируемостью, имеет не полностью открытый код и ограниченное соответствие стандартам SQL.

PostgreSQL

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

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

К минусам можно отнести: противоречивую документацию, снижение производительности со временем, слабые инструменты отчетности и аудита.

СУБД ЛИНТЕР

Семейство СУБД ЛИНТЕР имеет три продукта:

СУБД ЛИНТЕР СТАНДАРТ — российская реляционная СУБД, которая включена в Единый реестр российских программ для электронных вычислительных машин и баз данных Минцифры РФ.

Плюс данной СУБД заключается в предъявлении минимальных требований к памяти, что позволяет использовать ее во встраиваемых решениях, либо на M2M/IoT устройствах. В нашей статье вы можете подробно познакомиться с данной СУБД.

ЛИНТЕР БАСТИОН — российская реляционная СУБД, которая гарантирует высочайший уровень безопасности данных пользователя.

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

Реляционные СУБД: обзор базы данных, примеры

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

История разработки

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

К 1960-м годам собралось огромное количество данных, хранящихся на новых мэйнфрейм-компьютерах мира, многие из которых были компьютерами IBM System 360. Это стало проблемой для дальнейшего развития цифровых технологий. Расчеты на мэйнфреймах были дорогими, часто стоили сотни долларов в минуту. Существенной частью этих затрат была сложность, связанная с управлением базой данных (БД).

В 1973 году лаборатория Сан-Хосе, ныне Almaden, начала разрабатывать программу под названием System R (реляционый) с целью применить теорию отношений с помощью так называемой промышленной реализации. Это качество стало определяющим, чтобы определить, какие СУБД называются реляционными. В результате реализации этого проекта было изобретена новая революционная система хранения, ставшая основой успеха IBM.

Дон Чемберлин и Рэй Бойс изобрели SQL для структурированных данных, который сегодня наиболее широко применяются. Патриция Селингер разработала оптимизатор на основе затрат, делающий работу с реляционными БД более рентабельной и эффективной. А Раймон Лори изобрел компилятор, сохраняющий процедуры запросов к БД для будущего использования.

В 1983 году IBM представила второе семейство реляционных СУБД DB2 с целью управления данными. Сегодня DB2 по-прежнему производят миллиарды транзакций каждый день, являясь самым успешным программным продуктом IBM. По словам Арвинда Кришны, генерального менеджера IBM Information Management, DB2 продолжает оставаться лидером в области инновационного ПО для реляционных баз данных (РБД).

Доктор Кодд, известный своим коллегам как Тед, был удостоен звания стипендиата IBM в 1976 году, а в 1981 году Ассоциация вычислительной техники вручила ему премию Тьюринга за вклад, внесенный в разработку РБД.

Принципы создания

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

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

Термины и типы

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

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

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

Альтернативные структуры

База данных NoSQL — это альтернатива РБД, которая особенно полезна для работы с большими наборами распределенных данных.

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

Примеры реляционных СУБД

SQLite — это популярная БД SQL с открытым исходным кодом. ПО может хранить всю БД в одном файле. Самым значительным преимуществом, которое она обеспечивает, является то, что все данные могут храниться локально без подключения к серверу. SQLite стала популярной для БД в мобильных телефонах, КПК, MP3-плеерах, телевизионных приставках и других электронных гаджетах.

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

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

Главный ее недостаток — она работает медленнее, чем иные БД, такие как MySQL. Она также менее популярна, чем MySQL, что затрудняет доступ хостов или поставщиков услуг, которые предлагают управляемые экземпляры PostgreSQL.

Система управления RDBMS

RDBMS — система управления реляционными базами данных, разработанная EF Codd от IBM и способная создавать, изменять и администрировать РБД. Многие существующих на сегодня БД являются продолжением этой вековой модели. Сохраненные данные обрабатываются с применением реляционных операторов в СУРБД.

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

Отличия RDBMS от обычной СУБД

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

СУБД ориентирована на широкий спектр применений, ее особенности позволяют использовать ее во всем мире.

1. Общая реализация столбца, а также многопользовательский доступ включены в функции RDBMS.
2. Потенциал этой модели реляционных СУБД был более чем оправдан современными возможностями применения.
3. Лучшая безопасность обеспечивается созданием таблиц.
4. Некоторые таблицы могут быть защищены системой.
5. Пользователи могут устанавливать барьеры доступа к контенту. Это очень полезно в компаниях, где менеджер может решить, какие данные предоставляются сотрудникам и клиентам. Таким образом, можно настроить индивидуальный уровень защиты данных.
6. Обеспечение будущих требований, поскольку новые данные могут быть легко добавлены к существующим таблицам и согласованы с ранее доступным содержимым. Это функция, которой нет ни в одной БД плоских файлов.

Структурная таблица

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

Существует нескольких типов таблиц:

1. Базовая, которая создается и содержит постоянные данные.
2. Временная, в которой хранятся промежуточные результаты запроса.

1. Столбцы имеют упорядоченный набор: DEPTNO, DEPTNAME, MGR и ADMK DEPT. Все они должны быть однотипными данными.
2. Строки — каждая содержит данные для одного отдела.
3. Значения на пересечении столбца и строки. Например, PLANNING — это значение столбца DEPT NAME в строке для отдела B01.

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

Индекс используется для двух целей:

1. Для повышения быстродействия получения значений данных.
2. Для уникальности.

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

Основные ключи

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

1. Он должен иметь значение, то есть не быть нулевым.
2. Он должен иметь уникальный индекс.
3. Можно иметь более одного уникального ключа в таблице.
4. Иностранный ключ — внешний ключ, указанный в ограничении ссылочной целостности, чтобы его существование зависело от первичного или родительского ключа.

Модель сетевой базы данных

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

Преимущества сетевой БД:

1. Концептуально проста и легка в разработке.
2. Доступ к данным проще и гибче по отношению к иерархической модели и не позволяет члену существовать без родителя.
3. Может обрабатывать сложные данные из-за своего отношения «многие ко многим». Это позволяет более естественное моделирование отношений между записями или объектами реляционной СУБД в отличие от иерархической.
4. Благодаря своей гибкости легче перемещается и находит информацию в сетевой БД.
5. Такая структура изолирует управляющие программы от сложных физических данных.

Объектно-ориентированная система

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

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

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

Процесс проектирования

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

1. Определяют цель БД для анализа требований.
2. Собирают требования. Выполняют сбор данных, организацию таблиц и указывают первичные ключи.
3. Выбирают один или несколько столбцов в качестве так называемого первичного ключа с целью идентификации строк.
4. Создают отношения между таблицами. Сила реляционной БД заключается в отношениях между таблицами. Наиболее важным аспектом при разработке РБД является выявление взаимосвязей между ними.
5. Необходимо выбрать необходимый тип данных для конкретного столбца. Обычно типы данных содержат: целые числа, строку (или текст), дату, время, двоичный код, коллекцию, например перечисление и набор.
6. Уточняют дизайн, добавив больше столбцов.
7. Создают новую таблицу для необязательных данных, используя отношение один к одному.
8. Разбивают большой стол на два меньших стола.
9. Применяют правила нормализации, чтобы проверить, является ли база данных структурно правильной и оптимальной.
10. Индекс может быть определен для одного столбца, набора столбцов, называемого составным индексом, или части столбца, называемой частичным индексом. Можно создать более одного индекса в таблице. Например, если часто ищут клиента, используя либо customer Name либо phone Number, можно ускорить поиск, построив индекс по столбцу customer Name, а также phone Number.
11. Большинство СУБД автоматически строит индекс по первичному ключу.

Создание БД Access

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

Алгоритм создания БД:

1. Предварительно определяют данные и составляют список требуемых полей (фрагментов информации) с использованием разных типов данных.
2. Устраняют лишние поля. Не допускается хранить одинаковую информацию более чем в одном месте. В случае когда можно вычислить одно поле, используя другое, сохраняют одно.
3. Организовывают поля. Формируют их соответственно описанию, в связи с чем каждая группа преобразовывается в таблицу.
4. Добавляют таблицы кодов с сокращениями.
5. Включают в БД таблицу названий и коды из двух букв.
6. Выбирают первичный ключ.
7. Связывают таблицы.

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

Источник: fb.ru

Что такое реляционная база данных (РСУБД)?

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

Пример реляционной базы данных

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

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

Структура реляционных баз данных

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

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

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

Реляционная модель

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

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

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

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

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

Реляционные базы данных появились в 1970-х годах. На сегодняшний день преимущества реляционного подхода сделали его самой распространенной моделью для баз данных в мире.

Реляционная модель и согласованность данных

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

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

Фиксация изменений и атомарность

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

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

Свойства ACID и РСУБД

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

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

Хранимые процедуры и реляционные базы данных

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

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

Блокировки базы данных и параллельный доступ

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

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

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

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

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

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

• Каковы наши требования к точности данных? Будем ли мы использовать бизнес-логику для хранения и обеспечения точности данных? Предъявляются ли к нашим данным более строгие требования в отношении точности (например, если Вы работаете с финансовыми данными и отчетностью)?
• Нужна ли нам масштабируемость? Какими объемами данных требуется управлять и каков прогнозируемый рост этих объемов? Должна ли модель базы данных поддерживать зеркальные копии (как отдельные экземпляры) в целях масштабирования? Если да, сможем ли мы обеспечивать целостность данных в этих экземплярах?
• Насколько важно наличие параллельного доступа? Потребуется ли пользователям и приложениям одновременный доступ к данным? Поддерживает ли ПО базы данных параллельный доступ без ущерба для безопасности?
• Каковы наши потребности в эффективности и надежности баз данных? Требуется ли нам высокоэффективная и надежная система? Каковы требования к скорости выполнения запросов? Какие гарантии дает поставщик услуг в соответствии с соглашением об уровне обслуживания (SLA) или на случай незапланированного простоя?

Реляционная база данных будущего: автономная база данных

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

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

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

Источник: www.oracle.com