«Отличие государственного деятеля от политика в том, что политик ориентируется на следующие выборы, а государственный деятель — на следующее поколение». У. Черчилль
Терминология уровней
В блогах моих коллег была упомянута трехуровневая архитектура СУБД ANSI/X3/SPARC. Долгое время она являлась своего рода образцом для проектирования информационной системы в целом, состоящей из СУБД и приложений. Если для 1975 года была характерна ситуация, когда большинство разработчиков занималось вопросами реализации физического уровня хранения, то уже к середине-концу 1980-х появилось достаточное число программных продуктов класса универсальных СУБД, реализующих ту или иную модель данных логического уровня. Соответственно, границы физического уровня заметно сдвинулись, оставляя лишь место для тонкой настройки и потянув за собой и логические рамки. Особенности организации внешнего уровня также стало возможным описывать на логическом, прежде всего с помощью схем (пространств имён), видов (view) и хранимых процедур самой СУБД, а также различными инструментами слоя сервера приложений.
Похожая история случилась и с другим термином. В 1970-х годах для обозначения роли проектирующего и обслуживающего структуры баз данных сотрудника было введено специальное понятие — администратор баз данных. Но в настоящее время уже возникло достаточно чуткое разделение на администраторов-проектировщиков и администраторов по эксплуатации. Например, учебные курсы и сертификации Microsoft по СУБД имеют два основных сюжета: реализация и эксплуатация. Компетенции этих специалистов пересекаются, но сложность моделируемых предметных областей, с одной стороны, и обросших тысячами параметров тонкой настройки и мониторинга на конкретных аппаратных платформах с другой, вынуждают к такому разделению труда. Впрочем, руководство некоторых предприятий зачастую уверено, что администратор БД — это тот работник, что делает резервные копии, раздаёт права доступа, а остальное время генерирует трафик в социальных сетях[1]. Но даже подобный взгляд является прогрессом, ведь в РФ образца 1990х такого сотрудника называли программистом...
Возвращаясь к терминологии проектирования, очень часто в обсуждениях встречается путаница между понятиями моделей данных и моделей баз данных, являющихся на самом деле схемами баз данных. Избежать неоднозначности помогут два простых определения.
Модель данных — это инструмент описания
Схема базы данных — это результат использования инструмента
Взяв в качестве инструмента уже рассмотренные выше реляционную, сетевую или иерархическую модели данных вы получите на выходе соответствующую (или пока ещё не вполне соответствующую) функциональным требованиям схему базы данных.
Определившись с разницей между моделями и схемами данных, можно перейти к разделению на следующие уровни абстракции баз данных: концептуальный, логический и физический. Они соответствуют взглядам на одну и ту же базу данных со стороны разных участников проекта: функционального специалиста, проектировщика БД, администратора БД, программиста, пользователя.
- Концептуальный уровень соответствует описаниям сущностей (объектов) предметной области, связям между ними. Используются модели понятийного уровня, семантические модели. Характерная особенность полученных описаний — независимость от используемых моделей данных.
- Логический уровень описывает схему базы данных в терминах выбранной модели данных. Скорее всего это будет реляционная модель, но если вы столкнётесь с иным походом, то моделирование на логическом уровне также будет специфичным.
- Физический уровень соответствует описанию схемы данных в конкретной СУБД. Одной логической схеме БД может соответствовать несколько физических схем для разных СУБД, реализующих, тем не менее, одну и ту же модель
Рис. 1. Три уровня абстракции базы банных
Концептуальный уровень представляет собой наибольший интерес для функционального специалиста-проектировщика. Для разработчика информационной системы важнее результат моделирования на концептуальном уровне, который будет использован в логическом проектировании. Если концептуальные модели отсутствуют, проектировщику придётся работать «стандартным» методом прочтения линейных текстов многостраничных функциональных спецификаций, выстраивая по ним логическую схему БД.
Специфика выбранной модели данных, проявляющаяся уже на логическом уровне, вполне объясняет не слишком нравящееся части программистского сообщества «засилье» реляционных баз данных. Однако, описывая структуры в терминах отношений, ключей, связей, проектировщик может быть уверен, что его результат будет однозначно понят не только непосредственными коллегами, но и другими специалистами. Перейдя же, например, на сетевую терминологию наборов, записей и агрегатов данных, можно встретить не только непонимание изложенной сути, но и неумение программистов приложений оптимальным образом работать с данными в выбранной парадигме, сводящее к нулю предполагаемые выгоды от выбора.
Спускаясь на физический уровень, специфика СУБД становится основным фактором эффективности реализации схемы базы данных вышестоящих уровней. Так реляционная модель на своём логическом уровне оперирует понятиями отношений, атрибутов, ключей. На физическом же уровне РСУБД предлагает программисту пользоваться соответствующими терминами.
Табл. 1. Соответствие некоторых терминов реляционной модели (логический уровень) их реализаций в СУБД (физический уровень)
Термин реляционной модели | Соответствующие термины РСУБД |
Отношение | Таблица-кластер Таблица-куча Секционированная таблица Табличная функция Вид (view, виртуальная таблица) |
Проекция | Вид (view) Материализованный вид Табличная функция |
Кортеж | Строка (запись) Строка (с построчным сжатием) |
Атрибут | Колонка (столбец) Вычислимая колонка Вычислимая хранимая колонка |
Ключ | Первичный ключ Ограничение уникальности (unique) Уникальный индекс |
Домен | Встроенный тип Пользовательский тип |
Как видно на примере соответствий всего для нескольких терминов, логический уровень значительно отличается от физической реализации в том числе неоднозначностью соответствия. Так в реляционной модели ключом называется минимальный набор атрибутов отношения, позволяющий однозначно идентифицировать кортеж. Ключей, возможно составных, то есть содержащих более одного атрибута, может быть несколько. В РСУБД для каждой таблицы можно определить лишь один ключ, который называется первичным (primary key). Остальные ключи придётся определять соответствующим ограничением целостности или уникальными индексами.
Например, в отношении «Пользователи» веб-сайта кроме первичного ключа в виде внутреннего уникального номера-идентификатора, можно определить такие ключи как «имя регистрации» и «адрес электронной почты». В соответствующей таблице первичным ключом будет идентификатор, а соответствующим колонкам назначены ограничения уникальности.
Некоторые средства СУБД могут быть использованы для реализации разных элементов реляционной модели. Например, вид, как правило, представляет собой проекцию.
CREATE VIEW power users AS
SELECT u.id, u.name FROM users u
INNER JOIN users groups ug ON u.id = ug.id user
INNER JOIN groups g ON g.id = ug.id group
WHERE g.sysname = ’POWER_USERS’Однако, с помощью видов можно создавать и полноценные отношения, находящиеся в режиме «только чтение»
CREATE VIEW colors
AS
SELECT 1 AS id, 'Красный' AS name
UNION
SELECT 2 AS id, 'Зеленый' AS name
UNION
SELECT 3 AS id, 'Синий' AS name
Тот же принцип может быть использован и для табличных функций, которые в первом варианте просто являются параметрическими видами.
CREATE FUNCTION users_by_group(@sysname nvarchar(16))
RETURNS TABLE
AS
RETURN
(
SELECT u.id, u.name
FROM users u
INNER JOIN users_groups ug ON u.id = ug.id_user
INNER JOIN groups g ON g.id = ug.id_group
WHERE g.sysname = @sysname
)Кроме описанной классификации, также существует разделение на инфологическое и даталогическое моделирование с выработкой соответствующих схем, в целом соответствующих концептуальным и логическим.
[1] На заре развития Интернет во времена распространения сетей FIDO, узлы которых часто содержали администраторы сетей и БД, ходила такая шутка: «Настоящий фидошник умеет делать 2 вещи: читать почту и пить пиво»
