Проектирование баз данных: основные принципы

Главные принципы проектирования баз данных«Отличие государственного деятеля от политика в том, что политик ориентируется на следующие выборы, а государственный деятель — на следующее поколение». У. Черчилль

Терминология уровней

В блогах моих коллег была упомянута трехуровневая архитектура СУБД 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 вещи: читать почту и пить пиво»

Вас заинтересует / Intresting for you:

Инструментальная диалоговая си...
Инструментальная диалоговая си... 610 просмотров Ирина Светлова Sun, 24 Mar 2019, 06:01:30
База данных как объект правово...
База данных как объект правово... 448 просмотров Денис Wed, 27 Mar 2019, 03:16:24
Жизненный цикл реляционных баз...
Жизненный цикл реляционных баз... 1064 просмотров Ирина Светлова Tue, 21 Nov 2017, 13:26:01
Перенос корпоративных баз данн...
Перенос корпоративных баз данн... 703 просмотров Дэн Fri, 27 Sep 2019, 07:52:18

Войдите чтобы комментировать

Vovan_ST аватар
Vovan_ST ответил в теме #9183 09 сен 2018 10:52
Терминология объяснена в статье крайне вдумчиво и ясно! Спасибо за это автору!
Fasenger аватар
Fasenger ответил в теме #8986 15 март 2018 07:20
Хотел бы поучаствовать в серьезном проекте по проектированию базы данных с нуля. Мне в свое время казалась серьезной и сложной задача по проектированию БД "Деканат" в универе. Когда деревья были большими, как говорится...