Руководство по разработке структуры и проектированию базы данных

Содержание проектирования баз данных и этапность

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

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

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

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

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

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

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

Таким образом, основные этапы проектирования в детализированном виде представлены этапами:

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

Ключевые из них ниже будут рассмотрены подробнее.

Логическое проектирование БД

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

Поэтому этап начинается с выбора модели данных, где важно учесть её простоту и наглядность

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

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

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

Схемы базы данных формируются с помощью одного из двух разнонаправленных подходов:

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

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

Инфологическое проектирование

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

• описание типов объектов,
• ограничения целостности, связанные с описанным типом,
• процессы, приводящие к эволюции предметной области – переходу её в другое состояние.

Инфологическую модель можно создавать с помощью нескольких методов и подходов:

1. Функциональный подход отталкивается от поставленных задач. Функциональным он называется, потому что применяется, если известны функции и задачи лиц, которые с помощью проектируемой базы данных будут обслуживать свои информационные потребности.
2. Предметный подход во главу угла ставит сведения об информации, которая будет содержаться в базе данных, при том, что структура запросов может не быть определена. В этом случае в исследованиях предметной области ориентируются на её максимально адекватное отображение в базе данных в контексте полного спектра предполагаемых информационных запросов.
3. Комплексный подход по методу «сущность-связь» объединяет достоинства двух предыдущих. Метод сводится к разделению всей предметной области на локальные части, которые моделируются по отдельности, а затем вновь объединяются в цельную область.

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

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

Зависимость сущностей отражается в разделении их на сильные (базовые, родительские) и слабые (дочерние). Сильная сущность (например, читатель в библиотеке) может существовать в БД сама по себе, а слабая сущность (например, абонемент этого читателя) «привязывается» к сильной и отдельно не существует.

Для каждой отдельной сущности выбираются атрибуты (набор свойств), которые в зависимости от критерия могут быть:

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

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

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

Последовательное развитие и/или прыжки в высоту

Windows — не база данных, но в ней есть реликвия — реестр. Файл hosts — это просто идентификация IP-адресов локального компьютера и символических имен. Но через этот файл образуются информационные потоки с различных доменов или в различные СУБД.

Понять многоликий Windows как рабочий компьютер или сервер можно, но обосновать логику версий этого продукта не получится никак. PHP тоже не база данных, но аргументы разработчиков, почему за версией 5 сразу идет версия 7, не последовательны. PHP — это инструмент доступа к MySQL, его синтаксис определяет, как формировать запросы и получать ответы от базы данных при помощи диалекта SQL.

Примеры несовместимости современных инструментов программирования и обеспечения работы баз данных в последние годы стали нормой вещей, но это не самое оригинальное. Что будет за версией Windows 10? Какие перспективы идут вслед за Oracle Database 12c?

Информация разработчика-автора: «Oracle Database 11g Express Edition (Oracle Database XE) — это СУБД начального уровня, основанная на программном коде СУБД Oracle Database 11g Release 2. Данная СУБД бесплатна для разработки, развертывания и продажи, быстро скачивается и проста в администрировании».

Мнение разработчика-пользователя: «В 2013 г. компания Oracle выпустила версию Oracle Database 12c (версия 12.1.0.1), основными достоинствами которой стали снижение стоимости хранения, высокая доступность данных, простота консолидации баз данных и защита доступа к данным».

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

Анализ предметной области

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

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

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

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

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

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

Литература

• Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: «Вильямс», 2006. — 1328 с. — ISBN 0-321-19784-4.
• Когаловский М.Р. Перспективные технологии информационных систем. — М.: ДМК Пресс; Компания АйТи, 2003. — 288 с. — ISBN 5-279-02276-4.
• Когаловский М.Р. Энциклопедия технологий баз данных. — М.: Финансы и статистика, 2002. — 800 с. — ISBN 5-279-02276-4.
• Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. — ISBN 978-5-94774-736-2.
• Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М.: «Вильямс», 2003. — 1436 с. — ISBN 0-201-70857-4.
• Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. — М.: «Вильямс», 2003. — 1088 с. — ISBN 5-8459-0384-X.

2.2.2. Этапы проектирования баз данных

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

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

Рис 2.2. Этапы проектирования базы данных

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

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

Основные этапы проектирования баз данных

Концептуальное (инфологическое) проектирование

Пример концептуальной схемы

Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.

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

Чаще всего концептуальная модель базы данных включает в себя:

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

Логическое (даталогическое) проектирование

Пример логической схемы для реляционной модели данных.

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

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

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

Физическое проектирование

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

Результатом физического проектирования логической схемы выше на языке SQL может являться следующий скрипт:

CREATE TABLE IF NOT EXISTS Department ( -- Факультет
  id INT NOT NULL,
  name VARCHAR(45),
  PRIMARY KEY (id)
);

CREATE TABLE IF NOT EXISTS Group (
  id INT NOT NULL,
  name VARCHAR(45) ,
  depart_id INT NOT NULL,
  UNIQUE INDEX depart_id_UNIQUE (depart_id ASC),
  PRIMARY KEY (id, depart_id),
  CONSTRAINT depart_fk
    FOREIGN KEY (depart_id)
    REFERENCES Department (id)
);

CREATE TABLE IF NOT EXISTS Student (
  first_name VARCHAR(16) NOT NULL,
  last_name VARCHAR(45) NOT NULL,
  email VARCHAR(255),
  group_id INT NOT NULL,
  PRIMARY KEY (last_name, first_name, group_id),
  INDEX group_fk_idx (group_id ASC),
  CONSTRAINT group_fk
    FOREIGN KEY (group_id) REFERENCES Group (id)
);

Правило 3: Не переусердствуйте с правилом 2

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

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

4.1 Основные цели и этапы проектирования баз данных

Терминология
уровней описания данных и сути
проектирования БД приведена в п. 1.1.3.

Основные цели
проектирования баз данных (ПБД) следующие:

• обеспечение
  хранения в БД всех необходимых данных;

• обеспечение
  получения данных по всем необходимым
  запросам;

• сокращение
  избыточности и дублирования данных;

• обеспечение
  целостности данных: исключение потери
  данных, противоречий в содержании БД,
  нарушений смысла данных;

• сокращение
  времени доступа к данным и получения
  данных по запросам.

В процессе
проектирования баз данных выделяют три
основных этапа.

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

• описание объектов
  предметной области;

• описание атрибутов
  (свойств) объектов;

• описание связей
  между объектами.

Пусть,
например, проектируется база данных о
промышленном предприятии. Объектами
предметной области в данном случае
могут являться работники предприятия,
его подразделения, другие предприятия
– поставщики сырья или потребители
продукции, заключенные договоры, виды
выпускаемой продукции, конкретные
выпущенные изделия и т.д. Эти объекты
имеют свойства (атрибуты) – фамилия,
адрес и профессия работника, стоимость
изделия, объем поставок по договору и
т.д. Наконец, объекты находятся в различных
связях друг с другом: работник работает
в некотором подразделении, подразделения
выпускают продукцию, продукция
поставляется по договорам другим
предприятиям и т.д.

Для
описания объектов предметной области,
их атрибутов и связей между ними обычно
применяются стандартизированные системы
графических обозначений. Чаще всего
применяются ER-модели
(ER-диаграммы),
подробно рассматриваемые в разделе 2,
и семантические объектные модели
(COM-модели),
рассматриваемые в .

Кроме того,
инфологическая модель может включать:

• описание основных
  запросов к проектируемой БД;

• описание
  документооборота, т.е. документов,
  используемых в качестве источников
  данных для БД или составляемых на основе
  БД;

• описание
  алгоритмических связей между данными
  (например, алгоритмы и формулы для
  вычисления каких-либо величин, хранящихся
  в БД или определяемых на основе БД);

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

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

• описание таблиц;

• описание связей
  между таблицами;

• описание атрибутов.

Физическое
проектирование
– описание физической структуры БД,
т.е. ее размещения на запоминающем
устройстве. Такое описание называется
физической моделью. Физическая модель
включает:

• тип носителя;

• способы
  организации данных;

• способы управления
  свободной памятью;

• способы сжатия
  данных и т.д.

Этот
этап, как правило, в основным скрыт от
проектировщика БД, так как реализуется
средствами СУБД. Элементы физического
проектирования рассматривались выше
(п. 2.9) и далее этот этап не рассматривается.

Примечание — При
использовании систем автоматизированного
проектирования БД этап инфологического
проектирования обычно называют логическим
проектированием, а этапы даталогического
и физического проектирования – физическим
проектированием.

Построение концептуальной модели данных

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

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

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

На втором этапе проектирования разработчик должен выделить сущности предметной области. Сущностью предметной области называется абстрактное представление группы объектов с одинаковыми свойствами. Например, молоко, сыр, сметана – это конкретные продукты, но все вместе они относятся к сущности «продукция молокозавода» или «товар». Сущности предметной области описываются атрибутами. Атрибуты сущности – это абстрактные характеристики сущности, конкретные значения которых определяют конкретный экземпляр сущности. Например, сущность «продукция молокозавода» может описываться следующими атрибутами: наименование продукции, тип упаковки, вес, жирность. Если задать этим атрибутам конкретные значения, то мы получим описание конкретного продукта, выпускаемого молокозаводом. Например, молоко в тетрапаке весом 0.5л. и жирностью 3.2%.

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

1. Один поставщик может поставлять много товаров.
2. Один товар может поставляться многими поставщиками.

Приведем еще один пример. Рассмотрим сущности «автомобили» и «владельцы автомобилей». Между ними имеется отношение «владения автомобилем». Его описание будет выглядеть так:

1. Один владелец может владеть многими автомобилями.
2. Один автомобиль может принадлежать только одному владельцу.

Подобные описания отношений между сущностями называются ограничениями предметной области.

Замечание 1

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