архитектура приложений баз данных

Скромное руководство по схемам баз данных

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

Но как оценить, какая схема лучше? И что вообще значит «лучше», когда мы говорим об архитектуре БД? Команда Mail.ru Cloud Solutions предлагает познакомиться с рекомендациями Майка Алча, консультанта по разработке программного обеспечения. Нам кажется, что он довольно лаконично резюмировал некоторые принципы грамотной архитектуры.

Директор: «Думаю, мы должны построить базу данных SQL».

Разработчик (он вообще понимает, о чем говорит, или просто увидел какую-то рекламу в бизнес-журнале. ): «Какого цвета хотите базу данных?».

Директор: «Пожалуй, у сиреневого больше всего памяти».

Несколько базовых советов

Итак, важно стремиться к двум основным вещам:

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

— Оптимизирую этот SQL-запрос. Он тормозит, и пользователи начинают жаловаться.

— А нецензурная лексика в комментариях обязательна для оптимизации?

— Если бы ты видел оригинальный код, то не спрашивал бы.

Рассмотрим эти рекомендации подробнее.

1. Используйте как минимум третью нормальную форму

Архитектуру баз данных можно разделить на следующие категории:

Первая нормальная форма

Для первой нормальной формы каждое значение каждого столбца каждой таблицы в БД должно быть атомарным. Что значит атомарным? Если вкратце, атомарное значение представляет собой «единичную вещь».

Например, у нас есть такая таблица:

Здесь столбец areas («Области») содержит значения, которые не являются атомарными. Например, в строке Джона Доу поле хранит две сущности: «Дизайн веб-сайтов» и «Исследование клиентуры».

Таким образом, эта таблица не находится в первой нормальной форме.

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

Вторая нормальная форма

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

Допустим, у вас такая архитектура базы (я подчеркнул поля, соответствующие первичному ключу в этой таблице):

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

Аналогично, имя проекта однозначно определяется идентификатором project_id.

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

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

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

Третья нормальная форма

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

Допустим, у вас следующая архитектура (которая далека от идеала):

В этой таблице department_number можно вывести из employee_id, а department_name можно вывести из department_number. Таким образом, department_name транзитивно зависит от employee_id!

Если существует такая транзитивная зависимость: employee_id → department_number → department_name, то данная таблица не находится в третьей нормальной форме.

Какие проблемы возникают из-за этого?

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

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

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

Всех этих проблем можно полностью избежать в третьей нормальной форме.

Мамины эксплойты. Ее дочь зовут Помогите! Меня заставляют подделывать паспорта

2. Создайте последнюю линию обороны в виде ограничений

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

Ограничения устанавливают правила, какие значения можно вносить в поля БД.

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

Обязательно укажите, что должно произойти при удалении и обновлении строки, связанной с другими строками в других таблицах (правила ON DELETE и ON UPDATE).

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

Установите проверочные ограничения CHECK, чтобы убедиться — значения таблицы находятся в допустимом диапазоне, например, цена на товар всегда имеет положительное значение.

Интересный факт: в апреле 2020 года именно такое ограничение в программном обеспечении помешало торгам на московской бирже ММВБ, потому что цена на нефтяные фьючерсы WTI опустилась ниже нуля. В отличие от московской биржи, Нью-Йоркская товарная биржа NYMEX обновила софт за неделю до инцидента, поэтому сумела успешно провести сделки по отрицательной цене, то есть с доплатой покупателю от продавца — прим. пер.

Обо всех ограничениях PostgreSQL можно почитать здесь.

3. Никогда не храните в одном поле целые адреса

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

Но что делать, если нужно объединить покупки клиентов по городам, чтобы посмотреть, в каком городе какой продукт более популярен? Вы сможете это сделать?

Это будет очень тяжело!

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

Поэтому обязательно разбивайте универсальное поле «Адрес» на конкретные поля: улица, номер дома, город, область, почтовый индекс и так далее.

Еще одна проблема адресов — «анонимные» поля

Вот иллюстрация из книги Майклза Блаха «Медная пуля для улучшения качества программного обеспечения»:

Какие тут видны возможные проблемы? Сможете ли вы легко отличить город Чикаго от улицы Чикаго? Наверное, нет.

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

Как составлять резюме

— У тебя есть опыт в SQL?

— Так и пиши: эксперт по NoSQL.

4. Никогда не храните в одном поле имя и фамилию

Аналогично ситуации с адресами: количество вариаций имени и фамилии слишком велико, чтобы их четко различать.

Конечно, можно отделить имя от фамилии, если между ними пробел.

Например, «Майк Альче» → имя «Майк» и фамилия «Альче».

Но что делать, если пользователь ввел второе имя? Или у него двойная фамилия? А что, если есть и второе имя, и двойная фамилия?

Как определить, где имя, а где фамилия, чтобы разделить строку? Ошибки неизбежны.

Способ избежать многих проблем — создать отдельные поля (в формах) для имен пользователей first_name и last_name. Таким образом, вы позволите пользователям разделить свои собственные имена и сможете хранить данные согласованным образом.

Примечание: я не говорю, что в полях БД запрещены пробелы. Например, для таких имен, как «Хуан Мартин Дель Потро», первая часть «Хуан Мартин» входит в поле first_name, а «Дель Потро» — в поле last_name. Конечно, это не идеально. Можно дополнительно завести столбцы middle_name и second_last_name. Посмотрите подробнее о возможных вариациях имен и фамилий в списке «Заблуждения программистов об именах» и статье «Заблуждения программистов об именах — с примерами». Придется согласиться на какой-то компромисс между точностью и практичностью.

5. Установите соглашения для имен таблиц и полей и придерживайтесь их

Довольно неприятно работать с данными, которые выглядят как user.firstName, user.lst_name, user.birthDate и так далее.

Я бы посоветовал установить правила именования с подчеркиванием, потому что не все SQL-движки одинаково обрабатывают заглавные буквы, а заключать всё в кавычки весьма утомительно.

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

Источник

Основные понятия и определения

Современные авторы часто употребляют термины » банк данных » и » база данных » как синонимы, однако в общеотраслевых руководящих материалах по созданию банков данных Государственного комитета по науке и технике (ГКНТ), изданных в 1982 г., эти понятия различаются. Там приводятся следующие определения банка данных, базы данных и СУБД :

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

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

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

Архитектура базы данных. Физическая и логическая независимость

Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Это именно то, чего не хватало при использовании файловых систем.

Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.

Процесс прохождения пользовательского запроса

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

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

Пользователи банков данных

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

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

Определим основные категории пользователей и их роль в функционировании банка данных:

Рассмотрим их более подробно.

В составе группы администратора БД должны быть:

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

Источник

2) Архитектура СУБД

Что такое архитектура базы данных?

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

1 уровень Архитектура

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

2-х уровневая архитектура

Двухуровневая архитектура — это архитектура базы данных, в которой

Интерфейс приложения, который называется ODBC (Open Database Connectivity) — API, который позволяет клиентской программе вызывать СУБД. Сегодня большинство СУБД предлагает драйверы ODBC для своих СУБД. Двухуровневая архитектура обеспечивает дополнительную безопасность СУБД, поскольку она не предоставляется конечному пользователю напрямую.

Примером двухуровневой архитектуры является система управления контактами, созданная с использованием MS-Access.

Двухуровневая архитектурная схема

В приведенной выше двухуровневой архитектуре мы видим, что один сервер связан с клиентами 1, 2m и 3. Эта архитектура обеспечивает прямую и более быструю связь.

3-х уровневая архитектура

Трехуровневая схема является расширением двухуровневой архитектуры. 3-уровневая архитектура имеет следующие уровни

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

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

Трехуровневая архитектура — самая популярная архитектура СУБД.

Целью трехуровневой архитектуры является:

Пример трехуровневой архитектуры

Источник

Архитектура приложений баз данных

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

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

Общая структура приложения баз данных

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

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

Визуальные компоненты отображения данных расположены на вкладке Data Controls. Они по большей части являются стандартными компонентами ото­бражения данных с небольшими изменениями и дополнениями. В основе любого приложения баз данных лежат наборы данных, представля­ющие собой массивы записей, полученные из баз данных. Наборы данных хранятся в специальных компонентах, построенных на базе класса TDataSet. Для обеспечения связи набора данных о визуальными компонентами отобра­жения данных предназначен специальный компонент — источник данных, реализуемый классом TDataSource, Компонент TDataSource обеспечивает пере­дачу данных в визуальные компоненты, отслеживает синхронное изменение их состояния, если изменяется состояние связанного сними набора данных, передачу измененных данных обратно в набор. Этот компонент располагает­ся на вкладке Data Access.

Базовый механизм доступа к данным основывается на трех «китах»:

компонентах-потомках класса TDataSet (наборах данных);

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

Эта схема показана на рис. 2.2.

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

Модуль данных (Data Module) представляет собой невизуальный контейнер, и котором размещаются компоненты доступа к данным. В модуле данных можно размещать только невизуальные компоненты. Модуль данных досту­пен программисту на этапе разработки в виде формы, в которую он может положить компоненты и настроить их свойства. Модуль данных отличается от обычной формы, так как берет свое начало от класса TComponent.

Для создания модуля данных можно воспользоваться репозиторием объек­тов, который активируется при выполнении команды меню New ► Data Module.

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

На рис. 2.4 показано «дерево объектов». Оно позволяет отображать в списке объекты, размещенные в модуле данных. Перетаскивая объекты из «дерева объектов» в рабочую область Diagram, можно легко настраивать их свойства, буквально соединяя объекты линиями связи. На рис. 2.5 показана модель некой базы данных. Для того чтобы создать подобную модель, потребуется совсем немного времени. При помощи кнопки Property connector легко связать табли­цы с компонентом-провайдером. А кнопка Master\Detail connector позволяет установить связь «один-ко-многим» в диалоговом окне FieLd Link Designer.

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

Процессор баз данных Borland Database Engine

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

поиск местоположения базы данных;

поиск таблицы, ее открытие и чтение служебной информации;

чтение данных в соответствии с форматом хранения данных

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

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

Для работы с источниками данных при посредстве BDE в Delphi имеется специальный набор компонентов, расположенных на странице BDE Палит­ры компонентов. Эти компоненты для работы с базами данных используют возможности BDE, обращаясь к его функциям и процедурам. Механизм доступа к BDE инкапсулирован в базовом классе TBDEDataSet. Поэтому в процессе программирования не нужно будет необходимости использовать функции BDE напрямую. Почти все, что можно сделать путем прямого обращения, можно сделать и через компоненты — это проще и надежнее.

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

BDE взаимодействует с базами данных при посредстве драйверов. Для осо­бенно распространенных локальных СУБД разработан набор стандартных драйверов. Работа с наиболее распространенными серверами БД осуществ­ляется при помощи драйверов системы SQL Links. Кроме этого, если для базы данных существует драйвер ODBC, то можно использовать и его. Дос­таточно зарегистрировать этот драйвер в BDE.

Однако BDE не претендует на всеобъемлющую универсальность и имеет некоторые недостатки. Это, например, снижение скорости работы прило­жения, недостатки реализации некоторых драйверов и т. д. В документации «Delphi 7 содержится предупреждение, что после 2002 года фирма Borland перестанет поддерживать BDE и рекомендует использовать технологию dbExpress.

Архитектура и функции BDE

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

В составе BDE поставляются стандартные драйверы, обеспечивающие дос­туп к СУБД Paradox, dBASE, FoxPro и текстовым файлам. Локальные драй­веры (рис. 1) устанавливаются автоматически совместно с ядром процес­сора. Один из них можно выбрать в качестве стандартного драйвера, который имеет дополнительные настройки, влияющие на функционирование процессора БД.

Рис. 1. Структура процессора баз данных BDE

Доступ к данным серверов SQL обеспечивает отдельная система драйве­ров — SQL Links. С их помощью в Delphi можно без особых проблем разра­батывать приложения для серверов Oracle 8, Informix, Sybase, DB2 и, естест­венно, InterBase. Эти драйверы необходимо устанавливать дополнительно.

Помимо этого, в BDE имеется очень простой механизм подключения лю­бых драйверов ODBC (к примеру, Microsoft Access) и создания на их основе сокетов ODBC.

С точки зрения пользователя процесс подключения локального драйвера и драйвера SQL Links практически не отличается, за исключением деталей на­стройки. Настройка драйверов и собственных параметров BDE осуществляется при помощи специальной утилиты — BDE Administrator

В состав BDE входят следующие функциональные подсистемы.

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

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

Система сортировки является запатентованной технологией и обеспечи­вает очень быстрый поиск по запросам SQL и через стандартные драйве­ры для Paradox и dBASE.

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

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

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

Транслятор данных обеспечивает преобразование форматов данных для различных типов БД.

Кэш BLOB используется для ускорения работы с данными в формате BLOB.

SQL-генератор транслирует запросы в формате QBE в запросы SQL.

О Система реструктуризации обеспечивает преобразование наборов данных в таблицы Paradox или dBASE.

Система поддержки драйверов SQL повышает эффективность механизма поиска при выполнении запросов SQL. /

Таблицы в памяти. Этот механизм позволяет создавать таблицы непо­средственно в оперативной памяти. Используется для ускорения обра­ботки больших массивов данных, сортировки, преобразования форматов данных.

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

Менеджер конфигурации обеспечивает разработчику доступ к информации о конфигурации драйверов.

Источник