Процесс проектирования БД представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов ПО в терминах некоторой модели. В общем случае можно выделить следующие этапы проектирования:
I. Системный анализ и словесное описание информационных объектов ПО . Существуют два подхода к выбору состава и структуры предметной области:
· Функциональный подход. Он реализует принцип движения «от задач» и применяется тогда, когда известны функции некоторой группы лиц и комплексов задач, для облуживания информационных потребностей которых создается БД. В этом случае можно четко выделить необходимый минимальный набор объектов, которые должны быть описаны.
· Предметный подход. Информационные потребности будущих пользователей жестко не зафиксированы. Невозможно выделить необходимый минимальный набор объектов, которые необходимо описывать. В описание ПО в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и существенны для нее. Проектируемая БД называется предметной и может быть использована для множества разнообразных, заранее неопределенных задач. Такой подход кажется наиболее перспективным, однако может привести к избыточности задачи или потребности пользователей, а с другой стороны, учитывает возможность наращивания новых приложений.
II. Проектирование инфологической модели ПО. Задача инфологического этапа проектирования: получение семантических (смысловых) моделей данных (например, в терминах ER-моделей)., отображающих информационное содержание конкретной ПО. Вначале выполняется выделение из воспринимаемой реальности требуемой части ПО, определяются ее границы, происходит абстрагирование от несущественных частей для конкретного применения БД. В результате определяются объекты, их свойства и связи, которые будут существенны для будущих пользователей системы.
III. Даталогическое или логическое проектирование БД , т.е. описание БД в терминах принятой даталогической модели данных (например, реляционной). Задачей логического этапа проектирования является организация данных., выделенных на предыдущем этапе, в такую форму, которая принята в выбранной конкретной СУБД, используя ее типы и модели данных. Даются рекомендации по выбору методов доступа к данным.
IV. Физическое проектирование БД , т.е. выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения. Задачей физического этапа проектирования является выбор рациональной структуры хранения данных. и методов доступа к ним, исходя из того арсенала средств и методов, который предоставляет разработчику конкретная СУБД.
При проектировании базы данных решаются две основных проблемы:
Каким образом отобразить объекты предметной области в абстрактные объекты модели данных? Эту проблему называют проблемой логического проектирования баз данных.
Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создание каких дополнительных структур (например, индексов) потребовать и т.д.? Эту проблему называют проблемой физического проектирования баз данных.
В случае реляционных баз данных трудно представить какие-либо общие рецепты по части физического проектирования. Здесь слишком много зависит от используемой СУБД. Поэтому мы ограничимся вопросами логического проектирования реляционных баз данных, которые существенны при использовании любой реляционной СУБД.
Более того, мы не будем касаться очень важного аспекта проектирования - определения ограничений целостности (за исключением ограничения первичного ключа). Дело в том, что при использовании СУБД с развитыми механизмами ограничений целостности (например, SQL-ориентированных систем) трудно предложить какой-либо общий подход к определению ограничений целостности. Эти ограничения могут иметь очень общий вид, и их формулировка пока относится скорее к области искусства, чем инженерного мастерства. Самое большее, что предлагается по этому поводу в литературе, это автоматическая проверка непротиворечивости набора ограничений целостности.
из каких отношений должна состоять БД и
какие атрибуты должны быть у этих отношений
Можно выделить три основных подхода к проектированию БД:
1. сбор информации об объектах решаемой задачи в рамках одной таблицы и последующая ее декомпозиция на несколько взаимосвязанных таблиц на основе процедур нормализации (классический метод );
2. переход от семантической (инфологической) модели второго этапа с помощью CASE-средств к готовой схеме БД или даже готовой прикладной информационной системе (ИС);
3. структурирование информации для использования в ИС в процессе проведения системного анализа на основе совокупности практических правил и рекомендаций.
Сначала будет рассмотрен классический подход, при котором весь процесс проектирования производится в терминах реляционной модели данных методом последовательных приближений к удовлетворительному набору схем отношений. Исходной точкой является представление ПО в виде одного или нескольких отношений, и на каждом шаге проектирования производится некоторый набор схем отношений, обладающих лучшими свойствами. Процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает свойствами лучшими, чем предыдущая.
В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:
первая нормальная форма (1NF);
вторая нормальная форма (2NF);
третья нормальная форма (3NF);
нормальная форма Бойса-Кодда (BCNF);
четвертая нормальная форма (4NF);
пятая нормальная форма (5NF или PJ/NF).
Основные свойства нормальных форм :
каждая следующая нормальная форма в некотором смысле лучше предыдущей;
при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.
В основе процесса проектирования лежит метод нормализации, декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы.
Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости . Для дальнейшего изложения нам потребуются несколько определений.
Определение 1. Функциональная зависимость
В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть составными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y: R.X ->R.Y.
Определение 2 . Полная функциональная зависимость
Функциональная зависимость R.X ->R.Y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X.
Определение 3. Транзитивная функциональная зависимость
Функциональная зависимость R.X -> R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X -> R.Z и R.Z -> R.Y и отсутствует функциональная зависимость R.Z -/-> R.X.
Определение 4. Неключевой атрибут
Неключевым атрибутом называется любой атрибут отношения, не входящий в состав первичного ключа (в частности, первичного).
Определение 5 . Взаимно независимые атрибуты
Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других.
Поскольку требование первой нормальной формы является базовым требованием классической реляционной модели данных, мы будем считать, что исходный набор отношений уже соответствует этому требованию, т.е. все атрибуты атомарны. Если таблица содержит составные атрибуты, то привести ее к 1NF можно, используя алгоритм нормализации, предложенный Э. Коддом:
начиная с исходной таблицы, берется ее первичный ключ и добавляется в каждую подчиненную таблицу (составной атрибут);
первичный ключ каждого расширенной таблицы состоит из первичного ключа подчиненной таблицы и добавленного родительского первичного ключа;
после этого из родительской таблицы вычеркиваются все непростые атрибуты, и эта процедура повторяется для каждой из подчиненных таблиц;
условие окончания алгоритма - атомарность всех атрибутов.
Пример 5.1 Рассмотрим в качестве предметной области некоторую организацию, выполняющую некоторые проекты. Модель предметной области опишем следующим неформальным текстом:
Сотрудники организации выполняют проекты.
Проекты состоят из нескольких заданий.
Каждый сотрудник может участвовать в одном или нескольких проектах, или временно не участвовать ни в каких проектах.
Над каждым проектом может работать несколько сотрудников, или временно проект может быть приостановлен, тогда над ним не работает ни один сотрудник.
Над каждым заданием в проекте работает ровно один сотрудник.
Каждый сотрудник числится в одном отделе.
Каждый сотрудник имеет телефон, находящийся в отделе сотрудника.
В ходе дополнительного уточнения того, какие данные необходимо учитывать, выяснилось следующее:
О каждом сотруднике необходимо хранить табельный номер. Табельный номер является уникальным для каждого сотрудника.
Каждый отдел имеет уникальный номер.
Каждый проект имеет номер. Номер проекта является уникальным.
Каждое задание из проекта имеет номер, уникальный в пределах проекта.
Представим схему отношения (вся информация в одной таблице):
СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ
(СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Первичный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> СОТР_ЗАРП
СОТР_НОМЕР -> ОТД_НОМЕР
ОТД_НОМЕР -> СОТР_ЗАРП
СОТР_НОМЕР, ПРО_НОМЕР -> СОТР_ЗАДАН
Как видно, хотя первичным ключом является составной атрибут СОТР_НОМЕР, ПРО_НОМЕР, атрибуты СОТР_ЗАРП и ОТД_НОМЕР функционально зависят от части первичного ключа, атрибута СОТР_НОМЕР. В результате мы не сможем вставить в отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ кортеж, описывающий сотрудника, который еще не выполняет никакого проекта (первичный ключ не может содержать неопределенное значение). При удалении кортежа мы не только разрушаем связь данного сотрудника с данным проектом, но утрачиваем информацию о том, что он работает в некотором отделе. При переводе сотрудника в другой отдел мы будем вынуждены модифицировать все кортежи, описывающие этого сотрудника, или получим несогласованный результат. Такие неприятные явления называются аномалиями схемы отношения. Они устраняются путем нормализации.
Определение 6 . Вторая нормальная форма (в этом определении предполагается, что единственным ключом отношения является первичный ключ)
Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый не ключевой атрибут полностью зависит от первичного ключа.
Можно произвести следующую декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в два отношения СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР)
Первичный ключ:
СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> СОТР_ЗАРП
СОТР_НОМЕР -> ОТД_НОМЕР
ОТД_НОМЕР -> СОТР_ЗАРП
Первичный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН
Каждое из этих двух отношений находится в 2NF, и в них устранены отмеченные выше аномалии (легко проверить, что все указанные операции выполняются без проблем).
Рассмотрим еще раз отношение СОТРУДНИКИ-ОТДЕЛЫ, находящееся в 2NF. Заметим, что функциональная зависимость СОТР_НОМЕР -> СОТР_ЗАРП является транзитивной; она является следствием функциональных зависимостей СОТР_НОМЕР -> ОТД_НОМЕР и ОТД_НОМЕР -> СОТР_ЗАРП. Другими словами, заработная плата сотрудника на самом деле является характеристикой не сотрудника, а отдела, в котором он работает (это не очень естественное предположение, но достаточное для примера).
В результате мы не сможем занести в базу данных информацию, характеризующую заработную плату отдела, до тех пор, пока в этом отделе не появится хотя бы один сотрудник (первичный ключ не может содержать неопределенное значение). При удалении кортежа, описывающего последнего сотрудника данного отдела, мы лишимся информации о заработной плате отдела. Чтобы согласованным образом изменить заработную плату отдела, мы будем вынуждены предварительно найти все кортежи, описывающие сотрудников этого отдела. Т.е. в отношении СОТРУДИКИ-ОТДЕЛЫ по-прежнему существуют аномалии. Их можно устранить путем дальнейшей нормализации.
Определение 7. Третья нормальная форма (определение дается в предположении существования единственного ключа.)
Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.
Можно произвести декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ в два отношения СОТРУДНИКИ и ОТДЕЛЫ:
СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР)
Первичный ключ:
СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> ОТД_НОМЕР
ОТДЕЛЫ (ОТД_НОМЕР, СОТР_ЗАРП)
Первичный ключ:
ОТД_НОМЕР
Функциональные зависимости:
ОТД_НОМЕР -> СОТР_ЗАРП
Каждое из этих двух отношений находится в 3NF и свободно от отмеченных аномалий.
Если отказаться от того ограничения, что отношение обладает единственным ключом, то определение 3NF примет следующую форму:
Определение 7*
Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF, и каждый не ключевой атрибут не является транзитивно зависимым от какого-либо ключа R.
На практике третья нормальная форма схем отношений достаточна в большинстве случаев, и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается .
Однако иногда полезно продолжить процесс нормализации.
Пример 5.2 Рассмотрим следующий пример схемы отношения:
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ИМЯ, ПРО_НОМЕР, СОТР_ЗАДАН)
Возможные ключи:
СОТР_НОМЕР, ПРО_НОМЕР
СОТР_ИМЯ, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> CОТР_ИМЯ
СОТР_НОМЕР -> ПРО_НОМЕР
СОТР_ИМЯ -> CОТР_НОМЕР
СОТР_ИМЯ -> ПРО_НОМЕР
СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН
СОТР_ИМЯ, ПРО_НОМЕР -> CОТР_ЗАДАН
В этом примере мы предполагаем, что личность сотрудника полностью определяется как его номером, так и именем (это снова не очень жизненное предположение, но достаточное для примера).
В соответствии с определением 7* отношение СОТРУДНИКИ-ПРОЕКТЫ находится в 3NF. Однако тот факт, что имеются функциональные зависимости атрибутов отношения от атрибута, являющегося частью первичного ключа, приводит к аномалиям. Например, для того, чтобы изменить имя сотрудника с данным номером согласованным образом, нам потребуется модифицировать все кортежи, включающие его номер.
Определение 8. Детерминант
Детерминант - любой атрибут, от которого полностью функционально зависит некоторый другой атрибут.
Определение 9 . Нормальная форма Бойса-Кодда
Отношение R находится в нормальной форме Бойса-Кодда (BCNF) в том и только в том случае, если каждый детерминант является возможным ключом.
Очевидно, что это требование не выполнено для отношения СОТРУДНИКИ-ПРОЕКТЫ. Можно произвести его декомпозицию к отношениям СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ:
СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ)
Возможные ключи:
СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> CОТР_ИМЯ
СОТР_ИМЯ -> СОТР_НОМЕР
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Возможный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН
Возможна альтернативная декомпозиция, если выбрать за основу СОТР_ИМЯ. В обоих случаях получаемые отношения СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ находятся в BCNF, и им не свойственны отмеченные аномалии.
Пример 5.3 Рассмотрим пример следующей схемы отношения:
ПРОЕКТЫ (ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН)
Отношение ПРОЕКТЫ содержит номера проектов, для каждого проекта список сотрудников, которые могут выполнять проект, и список заданий, предусматриваемых проектом. Сотрудники могут участвовать в нескольких проектах, и разные проекты могут включать одинаковые задания.
Каждый кортеж отношения связывает некоторый проект с сотрудником, участвующим в этом проекте, и заданием, который сотрудник выполняет в рамках данного проекта (мы предполагаем, что любой сотрудник, участвующий в проекте, выполняет все задания, предусмотренные этим проектом). По причине сформулированных выше условий единственным возможным ключом отношения является составной атрибут ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН, и нет никаких других детерминантов. Следовательно, отношение ПРОЕКТЫ находится в BCNF. Но при этом оно обладает недостатками: если, например, некоторый сотрудник присоединяется к данному проекту, необходимо вставить в отношение ПРОЕКТЫ столько кортежей, сколько заданий в нем предусмотрено.
Определение 10 . Многозначные зависимости
В отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.
В отношении ПРОЕКТЫ существуют следующие две многозначные зависимости:
ПРО_НОМЕР -> -> ПРО_СОТР
ПРО_НОМЕР -> -> ПРО_ЗАДАН
Легко показать, что в общем случае в отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, когда существует многозначная зависимость R.A -> -> R.C.
Дальнейшая нормализация отношений, подобных отношению ПРОЕКТЫ, основывается на следующей теореме:
Теорема Фейджина
Отношение R (A, B, C) можно спроецировать без потерь в отношения R1 (A, B) и R2 (A, C) в том и только в том случае, когда существует MVD A -> -> B | C.
Под проецированием без потерь понимается такой способ декомпозиции отношения, при котором исходное отношение полностью и без избыточности восстанавливается путем естественного соединения полученных отношений.
Определение 11 . Четвертая нормальная форма
Отношение R находится в четвертой нормальной форме (4NF) в том и только в том случае, если в случае существования многозначной зависимости A -> -> B все остальные атрибуты R функционально зависят от A.
В нашем примере можно произвести декомпозицию отношения ПРОЕКТЫ в два отношения ПРОЕКТЫ-СОТРУДНИКИ и ПРОЕКТЫ-ЗАДАНИЯ:
ПРОЕКТЫ-СОТРУДНИКИ (ПРО_НОМЕР, ПРО_СОТР)
ПРОЕКТЫ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН)
Оба эти отношения находятся в 4NF и свободны от отмеченных аномалий.
Во всех рассмотренных до этого момента нормализациях производилась декомпозиция одного отношения в два. Иногда это сделать не удается, но возможна декомпозиция в большее число отношений, каждое из которых обладает лучшими свойствами.
Пример 5.4 Рассмотрим, например, отношение
СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР, ОТД_НОМЕР, ПРО_НОМЕР)
Предположим, что один и тот же сотрудник может работать в нескольких отделах и работать в каждом отделе над несколькими проектами. Первичным ключом этого отношения является полная совокупность его атрибутов, отсутствуют функциональные и многозначные зависимости.
Поэтому отношение находится в 4NF. Однако в нем могут существовать аномалии, которые можно устранить путем декомпозиции в три отношения.
Определение 12. Зависимость соединения
Отношение R (X, Y, ..., Z) удовлетворяет зависимости соединения * (X, Y, ..., Z) в том и только в том случае, когда R восстанавливается без потерь путем соединения своих проекций на X, Y, ..., Z.
Определение 13 . Пятая нормальная форма
Отношение R находится в пятой нормальной форме (нормальной форме проекции-соединения - PJ/NF) в том и только в том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R.
Введем следующие имена составных атрибутов:
СО = {СОТР_НОМЕР, ОТД_НОМЕР}
СП = {СОТР_НОМЕР, ПРО_НОМЕР}
ОП = {ОТД_НОМЕР, ПРО_НОМЕР}
Предположим, что в отношении СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ существует зависимость соединения:
* (СО, СП, ОП)
На примерах легко показать, что при вставках и удалениях кортежей могут возникнуть проблемы. Их можно устранить путем декомпозиции исходного отношения в три новых отношения:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, ОТД_НОМЕР)
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР)
ОТДЕЛЫ-ПРОЕКТЫ (ОТД_НОМЕР, ПРО_НОМЕР)
Пятая нормальная форма - это последняя нормальная форма, которую можно получить путем декомпозиции. Ее условия достаточно нетривиальны, и на практике 5NF не используется. Заметим, что зависимость соединения является обобщением как многозначной зависимости, так и функциональной зависимости.
Замечание . Если отношения не нормализованы, то возникает проблемы избыточности, потенциальной противоречивости (аномалии обновления), аномалии включения, аномалии удаления .
Основные понятия о базах данных и СУБД
Информационная система (ИС) – это система, построенная на базе компьютерной техники, предназначенная для хранения, поиска, обработки и передачи значительных объемов информации, имеющая определенную практическую сферу применения.
База данных – это ИС, которая хранится в электронном виде.
База данных (БД) – организованная совокупность данных, предназначенная для длительного хранения во внешней памяти ЭВМ, постоянного обновления и использования.
БД служат для хранения и поиска большого объёма информации. Примеры баз данных: записная книжка, словари, справочники, энциклопедии и т.д.
Классификация баз данных:
1. По характеру хранимой информации:
- Фактографические – содержат краткие сведения об описываемых объектах, представленных в строго определённом формате (картотеки, н-р: БД книжного фонда библиотеки, БД кадрового состава учреждения),
- Документальные – содержат документы (информацию) самого разног типа: текстового, графического, звукового, мультимедийного (архивы, н-р: справочники, словари, БД законодательных актов в области уголовного права и др.)
2. По способу хранения данных:
- Централизованные (хранятся на одном компьютере),
- Распределенные (используются в локальных и глобальных компьютерных сетях).
3. По структуре организации данных:
- Реляционные (табличные),
- Нереляционные.
Термин «реляционный» (от лат. relatio – отношение) указывает на то, что такая модель хранения данных построена на взаимоотношении составляющих её частей. Реляционная база данных, по сути, представляет собой двумерную таблицу . Каждая строка такой таблицы называется записью. Столбцы таблицы называются полями: каждое поле характеризуется своим именем и топом данных. Поле БД – это столбец таблицы, содержащий значения определенного свойства.
Свойства реляционной модели данных:
Каждый элемент таблицы – один элемент данных;
Все поля таблицы являются однородными, т.е. имеют один тип;
Одинаковые записи в таблице отсутствуют;
Порядок записей в таблице может быть произвольным и может характеризоваться количеством полей, типом данных.
Иерархической называется БД, в которой информация упорядоченная следующим образом: один элемент считается главным, остальные – подчинёнными. В иерархической базе данных записи упорядочиваются в определенную последовательность, как ступеньки лестницы, и поиск данных может осуществляться последовательным «спуском» со ступени на ступень. Данная модель характеризуется такими параметрами, как уровни, узлы, связи. Принцип работы модели таков, что несколько узлов более низкого уровня соединяются при помощи связи с одним узлом более высокого уровня.
Узел – информационная модель элемента, находящегося на данном уровне иерархии.
Свойства иерархической модели данных:
Несколько узлов низшего уровня связано только с одним узлом высшего уровня;
Иерархическое дерево имеет только одну вершину (корень), не подчинено никакой другой вершине;
Каждый узел имеет своё имя (идентификатор);
Существует только один путь от корневой записи к более частной записи данных.
Иерархической базой данных является Каталог папок Windows, с которым можно работать, запустив Проводник. Верхний уровень занимает папка Рабочий стол. На втором уровне находятся папки Мой компьютер, Мои документы, Сетевое окружение и Корзина, которые представляют собой потомков папки Рабочий стол, будучи между собой близнецами. В свою очередь, папка Мой компьютер – предок по отношению к папкам третьего уровня, папкам дисков (Диск 3,5(А:), С:, D:, E:, F:) и системным папкам (Принтеры, Панель управления и др.).
Сетевой называется БД, в которой к вертикальным иерархическим связям добавляются горизонтальные связи. Любой объект может быть главным и подчинённым.
Сетевой базой данных фактически является Всемирная паутина глобальной компьютерной сети Интернет. Гиперссылки связывают между собой сотни миллионов документов в единую распределенную сетевую базу данных.
Программное обеспечение, предназначенное для работы с базами данных, называется система управления базами данных (СУБД). СУБД используются для упорядоченного хранения и обработки больших объемов информации.
Система управления базами данных (СУБД) – это система, обеспечивающая поиск, хранение, корректировку данных, формирование ответов на запросы. Система обеспечивает сохранность данных, их конфиденциальность, перемещение и связь с другими программными средствами.
Основные действия, которые пользователь может выполнять с помощью СУБД:
Создание структуры БД;
Заполнение БД информацией;
Изменение (редактирование) структуры и содержания БД;
Поиск информации в БД;
Сортировка данных;
Защита БД;
Проверка целостности БД.
Современные СУБД дают возможность включать в них не только текстовую и графическую информацию, но и звуковые фрагменты и даже видеоклипы.
Простота использования СУБД позволяет создавать новые базы данных, не прибегая к программированию, а пользуясь только встроенными функциями. СУБД обеспечивают правильность, полноту и непротиворечивость данных, а также удобный доступ к ним.
Популярные СУБД - FoxPro, Access for Windows, Paradox.
Таким образом, необходимо различать собственно базы данных (БД) – упорядоченные наборы данных, и системы управления базами данных (СУБД) – программы, управляющие хранением и обработкой данных. Например, приложение Access, входящее в офисный пакет программ Microsoft Office, является СУБД, позволяющей пользователю создавать и обрабатывать табличные базы данных.
Принципы построения систем управления баз данных следуют из требований, которым должна удовлетворять организация баз данных:
- Производительность и готовность. Запросы от пользователя базой данных удовлетворяются с такой скоростью, которая требуется для использования данных. Пользователь быстро получает данные всякий раз, когда они ему необходимы.
- Минимальные затраты. Низкая стоимость хранения и использования данных, минимизация затрат на внесение изменений.
- Простота и легкость использования. Пользователи могут легко узнать и понять, какие данные имеются в их распоряжении. Доступ к данным должен быть простым, исключающим возможные ошибки со стороны пользователя.
- Простота внесения изменений. База данных может увеличиваться и изменяться без нарушения имеющихся способов использования данных.
- Возможностьпоиска. Пользователь базы данных может обращаться с самыми различными запросами по поводу хранимых в ней данных. Для реализации этого служит так называемый язык запросов.
- Целостность . Современные базы данных могут содержать данные, используемые многими пользователями. Очень важно, чтобы в процессе работы элементы данных и связи между ними не нарушались. Кроме того, аппаратные ошибки и различного рода случайные сбои не должны приводить к необратимым потерям данных. Значит, система управления данными должна содержать механизм восстановления данных.
- Безопасность и секретность. Под безопасностью данных понимают защиту данных от случайного или преднамеренного доступа к ним лиц, не имеющих на это права, от неавторизированной модификации (изменения) данных или их разрушения. Секретность определяется как право отдельных лиц или организаций решать, когда, как какое количество информации может быть передано другим лицам или организациям.
Далее на примере одной из самых распространенных систем управления базами данных – Microsoft Access входит в состав популярного пакета Microsoft Office – мы познакомимся с основными типами данных, способами создания баз данных и с приемами работы с базами данных.
Проектирование баз данных
Как и любой программный продукт, база данных обладает собственным жизненным циклом (ЖЦБД). Главной составляющей в жизненном цикле БД является создание единой базы данных и программ, необходимых для ее работы.
ЖЦБД включает в себя следующие основные этапы:
1. Планирование разработки базы данных;
2. Определение требований к системе;
3. Сбор и анализ требований пользователей:
4. Проектирование базы данных:
Концептуальное проектирование базы данных – создание концептуальной модели данных, то есть информационной модели. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Чаще всего концептуальная модель базы данных включает в себя: описание информационных объектов, или понятий предметной области и связей между ними; описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними;
Логическое проектирование базы данных – создание логической модели данных; создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных логическая модель - набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.
На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
Физическое проектирование базы данных – создание схемы базы данных для конкретной СУБД, создание описания СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным, разработка средств защиты данных), создание индексов и т.д.;
5. Разработка приложений:
Проектирование транзакций (группа инструкций SQL (набор команд), исполняемых как единое целое);
Проектирование пользовательского интерфейса;
6. Реализация;
8. Тестирование;
9. Эксплуатация и сопровождение:
Анализ функционирования и поддержка исходного варианта БД;
Адаптация, модернизация и поддержка переработанных вариантов.
Проектирование баз данных – процесс создания схемы базы данных и определения необходимых ограничений целостности (соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам).
Основные задачи проектирования баз данных:
Обеспечение хранения в БД всей необходимой информации.
Обеспечение возможности получения данных по всем необходимым запросам.
Сокращение избыточности и дублирования данных.
Обеспечение целостности базы данных.
Суть проектирования баз данных (БД), как и любого другого процесса проектирования, в создании описания новой, прежде не существовавшей в таком виде системы, которая при её реализации способна предполагаемо функционировать в соответствующих условиях. Из этого следует, что этапы проектирования базы данных должны последовательно и логически связано отражать суть этого процесса.
Замысел проектирования основывается на какой-либо сформулированной общественной потребности. У этой потребности есть среда её возникновения и целевая аудитория потребителей, которые будут пользоваться результатом проектирования. Следовательно, процесс проектирования баз данных начинается с изучения данной потребности с точки зрения потребителей и функциональной среды её предполагаемого размещения. То есть, первым этапом становится сбор информации и определение модели предметной области системы, а также – взгляда на неё с точки зрения целевой аудитории. В целом, для определения требований к системе производится определение диапазона действий, а также границ приложений БД.
Далее проектировщик, уже имеющий определённые представления о том, что ему нужно создать, уточняет предположительно решаемые приложением задачи, формирует их список (особенно, если в проектной разработке большая и сложная БД), уточняет последовательность решения задач и производит анализ данных. Такой процесс – тоже этапная проектная работа, но обычно в структуре проектирования эти шаги поглощаются этапом концептуального проектирования – этапом выделения объектов, атрибутов, связей.
Создание концептуальной (информационной модели) предполагает предварительное формирование концептуальных требований пользователей, включая требования в отношении приложений, которые могут и не быть сразу реализованным, но учёт которых позволит в будущем повысить функциональность системы. Имея дело с представлениями объектов-абстракций множества (без указания способов физического хранения) и их взаимосвязями, концептуальная модель содержательно соответствует модели предметной области. Поэтому в литературе первый этап проектирования БД называется инфологическим проектированием.
Далее отдельным этапом (либо дополнением к предыдущему) следует этап формирования требований к операционной обстановке, где оцениваются требования к вычислительным ресурсам, способным обеспечить функционирование системы. Соответственно, чем больше объем проектируемой БД, чем выше пользовательская активность и интенсивность обращений, тем выше требования предъявляются к ресурсам: к конфигурации компьютера к типу и версии операционной системы. Например, многопользовательский режим работы будущей базы данных требует сетевого подключения с использованием операционной системы, соответствующей многозадачности.
Следующим этапом проектировщик должен выбрать систему управления базой данных (СУБД), а также инструментальные средства программного характера. После этого концептуальную модель необходимо перенести в совместимую с выбранной системой управления модель данных. Но нередко это сопряжено с внесением поправок и изменений в концептуальную модель, поскольку не всегда взаимосвязи объектов между собой, отражённые концептуальной моделью, могут быть реализованы средствами данной СУБД.
Это обстоятельство определяет возникновение следующего этапа – появления обеспеченной средствами конкретной СУБД концептуальной модели. Данный шаг соответствует этапу логического проектирования (создания логической модели).
Наконец, финальным этапом проектирования БД становится физическое проектирование – этап увязки логической структуры и физической среды хранения.
Таким образом, основные этапы проектирования в детализированном виде представлены этапами:
Ключевые из них ниже будут рассмотрены подробнее.
Идентификация сущностей составляет смысловую основу инфологического проектирования. Сущность здесь – это такой объект (абстрактный или конкретный), информация о котором будет накапливаться в системе. В инфологической модели предметной области в понятных пользователю терминах, которые не зависят от конкретной реализации БД, описывается структура и динамические свойства предметной области. Но термины, при этом берутся в типовых масштабах. То есть, описание выражается не через отдельные объекты предметной области и их взаимосвязи, а через:
Инфологическую модель можно создавать с помощью нескольких методов и подходов:
Поскольку использование метода «сущность-связь» является комбинированным способом проектирования на данном этапе, он чаще других становится приоритетным.
Локальные представления при методическом разделении должны, по возможности, включать в себя информацию, которой бы хватило для решения обособленной задачи или для обеспечения запросов какой-то группы потенциальных пользователей. Каждая из этих областей содержит порядка 6-7 сущностей и соответствует какому-либо отдельному внешнему приложению.
Зависимость сущностей отражается в разделении их на сильные (базовые, родительские) и слабые (дочерние). Сильная сущность (например, читатель в библиотеке) может существовать в БД сама по себе, а слабая сущность (например, абонемент этого читателя) «привязывается» к сильной и отдельно не существует.
Следует разделять понятия «экземпляр сущности» (объект, характеризующийся конкретными значениями свойств) и понятие «тип сущности» – объект, для которого характерно общее имя и список свойств.
Для каждой отдельной сущности выбираются атрибуты (набор свойств), которые в зависимости от критерия могут быть:
После этого производится спецификация атрибута, спецификация связей в локальном представлении (с разделением на факультативные и обязательные) и объединение локальных представлений.При числе локальных областей до 4-5 их можно объединить за один шаг. В случае увеличения числа, бинарное объединение областей происходит в несколько этапов.
В ходе этого и других промежуточных этапов находит своё отражение итерационная природа проектирования, выражающаяся здесь в том, что для устранения противоречий необходимо возвращаться на этап моделирования локальных представлений для уточнения и изменения (например, для изменения одинаковых названий семантически разных объектов или для согласования атрибутов целостности на одинаковые атрибуты в разных приложениях).
От выбора системы управления БД зависит практическая реализация информационной системы. Наиболее значимыми критериями в процессе выбора становятся параметры:
Ошибки в выборе СУБД практически наверняка впоследствии спровоцируют необходимость корректировать концептуальную и логическую модели.
Логическая структура БД должна соответствовать логической модели предметной области и учитывать связь модели данных с поддерживаемой СУБД. Поэтому этап начинается с выбора модели данных, где важно учесть её простоту и наглядность.
Предпочтительнее, когда естественная структура данных совпадает с представляющей её моделью. Так, например, если в данные представлены в виде иерархической структуры, то и модель лучше выбирать иерархическую. Однако на практике такой выбор чаще определяется системой управления БД, а не моделью данных. Поэтому концептуальная модель фактически транслируется в такую модель данных, которая совместима с выбранной системой управления БД.
Здесь тоже находит отражение природа проектирования, которая допускает возможность (или необходимость) вернуться к концептуальной модели для её изменения в случае, если отражённые там взаимосвязи между объектами (или атрибуты объектов) не удастся реализовать средствами выбранной СУБД.
По завершению этапа должны быть сформированы схемы баз данных обоих уровней архитектуры (концептуального и внешнего), созданные на языке определения данных, поддерживаемых выбранной СУБД.
Схемы базы данных формируются с помощью одного из двух разнонаправленных подходов:
Второй подход предполагает определение ряда высокоуровневых сущностей и их взаимосвязей с последующей детализацией до нужного уровня, что и отражает, например, модель, созданная на основе метода «сущность-связь». Но на практике оба подхода, как правило, комбинируются.
На следующем этапе физического проектирования БД логическая структура отображается в виде структуры хранения БД, то есть увязывается с такой физической средой хранения, где данные будут размещены максимально эффективно. Здесь детально расписывается схема данных с указанием всех типов, полей, размеров и ограничений. Помимо разработки индексов и таблиц, производится определение основных запросов.
Построение физической модели сопряжено с решением во многом противоречивых задач:
Вторая задача вступает в конфликт с первой, поскольку, например:
Всё это увеличивает размер базы данных, поэтому проектировщик ищет разумный баланс, при котором задачи решаются оптимально путём грамотного размещения данных в пространстве памяти, но не за счёт средств защиты базы дынных, куда входит как защита от несанкционированного доступа, так и защита от сбоев.
Для завершения создания физической модели проводят оценку её эксплуатационных характеристик (скорость поиска, эффективность выполнения запросов и расхода ресурсов, правильность операций). Иногда этот этап, как и этапы реализации базы данных, тестирования и оптимизации, а также сопровождения и эксплуатации, выносят за пределы непосредственного проектирования БД.
С точки зрения конечного пользователя процесс создания базы данных можно представить в виде четырех этапов:
На первом этапе необходимо провести подробное словестное описание предметной области и реальных связей, которые присутствуют между описываемыми объектами.
Предметная область отображается моделями данных нескольких уровней. Предметная область может относиться к любому типу организации.
Необходимо различать полную предметную область(крупное предприятие) и организационную единицу этой предметной области. Организационная единица, в свою очередь, может представлять собою предметную область (например, цех по производству или отдел предприятия).
Информация для описания предметной области зависит от реальной модели и может включать в себя сведения о людях, местах, предметах, событиях и понятиях.
Существует два подхода к выбору состава и структуры предметной области:
Функциональный подход - применяется, когда известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая БД.
Предметный подход - когда информационные потребности будущих пользователей БД жестко не фиксируются.
Концептуальное проектирование . Разработка концептуальной модели предметной области основана на анализе информационных потребностей конечных пользователей и тех требований, которые они предъявляют к создаваемой базе данных.
На этом этапе прежде всего решается вопрос о том, какие данные должны храниться в базе и какого типа информационные выборки и отчеты могут потребоваться пользователю БД.
Главными элементами концептуальной модели данных являются объекты и отношения. Объекты представляют аспекты, которые пользователи считают важными в моделируемой части реальности. Отношения связывают два объектных множества. Отношение само по себе является объектным множеством, состоящим из пар объектов-элементов, взятых из двух множеств, которое соединяет отношение.
Концептуальная модель предметной области обычно представляется в виде графической схемы, на которой показан состав и взаимосвязи хранимых данных. В процессе работы инфологическая модель может дополняться новыми данными в связи с изменяющимися потребностями пользователя.
Существует три основных типа отношений:
1) «один-к-одному». Такая связь означает, что каждому значению реквизита А соответствует одно и только одно значение связанного с ним реквизита В, и наоборот. Например, каждому значению реквизита Номер паспорта соответствует единственное значение реквизита ФИО гражданина страны, и наоборот. Такую связь обозначают 1:1, графически в инфологических моделях эта связь изображается одинарными стрелками.
2)«один-ко-многим». Эта связь означает, что каждому значению реквизита А соответствует одно или несколько значений связанного с ним реквизита В, а каждому значению реквизита В соответствует одно и только одно значение реквизита А. Например, для аэропорта , из которого осуществляется множество рейсов, характерна следующая связь между описывающими этот объект реквизитами: одному значению реквизита Название аэропорта вылета соответствует несколько значений реквизита Номер рейса, а каждому значению Номер рейса соответствует только одно Название аэропорта вылета.
3)«многие-ко-многим». Такая связь означает, что каждому значению реквизита А соответствует несколько значений связанного с ним реквизита В, и наоборот. Например, турагентство может работать с несколькими туроператорами, а туроператор обычно имеет разветвленную сеть турагентов. Такую связь обозначают М: М, а графически изображают двойными стрелками.
Аналогичные связи могут быть установлены в БД между реляционными таблицами и практически реализованы за счет наличия в них общих полей (реквизитов). Если общих полей в связываемых таблицах нет, то нужно сделать следующее:
Логическое проектирование заключается в определении числа и структуры таблиц, формировании запросов к БД, определении типов отчетных документов, разработке алгоритмов обработки информации, создании форм для ввода и редактирования данных.
На этом этапе осуществляется выбор подходящей системы управления базами данных и представление инфологической модели предметной области в форме структуры базы данных конкретной СУБД.
Для размещения одной и той же информации могут быть использованы различные модели данных. Их выбор зависит от многих факторов, в том числе от имеющегося технического и программного обеспечения, объемов информации, сложности автоматизируемых задач.
Файловая модель. Представляет собой совокупность не связанных между собой файлов из однотипных записей с линейной (одноуровневой) структурой.
Более сложными моделями внутримашинной организации данных являются сетевые и иерархические модели.
В иерархической модели любой объект (запись, сегмент) может подчиняться только одному объекту вышестоящего уровня. В сетевых – любой объект (запись, файл) может подчиняться нескольким объектам.
Сетевые модели данных по сравнению с иерархическими являются более универсальным средством отображения данных для разных предметных областей. Достоинством сетевых моделей является отсутствие дублирования данных в различных элементах модели.
Реляционные модели данных отличаются от сетевых и иерархических простой структурой данных, удобным для пользователя табличным представлением и доступом к данным. Реляционная модель данных является совокупностью простейших двумерных таблиц – отношений. Связи между двумя логически связанными таблицами в реляционной модели устанавливаются по равенству значений одинаковых атрибутов таблиц - отношений.
Физическое проектирование предполагает определение способов и мест размещения базы данных, оценку ее объема и других параметров.
В каждой СУБД по -разному организованы хранение и доступ к данным. В системах баз данных файлы можно классифицировать следующим образом:
Файлы прямого доступа;
Файлы последовательного доступа;
Индексные файлы.
Похожая информация.
Следуя принципам, описанным в этой статье, можно создать базу данных, которая работает надлежащим образом и в будущем может быть адаптирована под новые требования. Мы рассмотрим основные принципы проектирования базы данных , а также способы ее оптимизации.
Надлежащим образом структурированная база данных:
Разработка БД включает в себя следующие этапы:
Рассмотрим каждый этап проектирования баз данных подробнее. Обратите внимание, что в этом руководстве рассматривается реляционная модель базы данных Эдгара Кодда , написанная на языке SQL (а не иерархическая, сетевая или объектная модели ).
Например, если вы создаете базу данных для публичной библиотеки, нужно продумать, каким образом и читатели, и библиотекари должны получать доступ к БД .
Вот несколько способов сбора информации перед созданием базы данных:
Начните со сбора существующих данных, которые будут включены в базу. Затем определите типы данных, которые нужно сохранить. А также объекты, которые описывают эти данные. Например:
Клиенты
Товары
Заказы
При проектировании реляционной базы данных эта информация позже станет частью словаря данных, в котором описаны таблицы и поля БД . Разбейте информацию на минимально возможные части. Например, подумайте о том, чтобы разделить поле почтового адреса и штата, чтобы можно было фильтровать людей по штату, в котором они проживают.
После того, как вы определились с тем, какие данные будут включены в базу, откуда эти данные будут поступать, и как они будут использоваться, можно приступить к планированию фактической БД .
Следующим шагом будет визуальное представление базы данных. Для этого нужно точно знать, как структурируются реляционные БД . Внутри базы связанные данные группируются в таблицы, каждая из которых состоит из строк и столбцов.
Чтобы преобразовать списки данных в таблицы, начните с создания таблицы для каждого типа объектов, таких как товары, продажи, клиенты и заказы. Вот пример:
Каждая строка таблицы называется записью. Записи включают в себя информацию о чем-то или о ком-то, например, о конкретном клиенте. Столбцы (также называемые полями или атрибутами) содержат информацию одного типа, которая отображается для каждой записи, например, адреса всех клиентов, перечисленных в таблице.
Чтобы при проектировании модели базы данных обеспечить согласованность разных записей, назначьте соответствующий тип данных для каждого столбца. К общим типам данных относятся:
Некоторые СУБД также предлагают тип данных Autonumber , который автоматически генерирует уникальный номер в каждой строке.
В визуальном представлении БД каждая таблица будет представлена блоком на диаграмме. В заголовке каждого блока должно быть указано, что описывают данные в этой таблице, а ниже должны быть перечислены атрибуты:
При проектировании информационной базы данных необходимо решить, какие атрибуты будут служить в качестве первичного ключа для каждой таблицы, если таковые будут. Первичный ключ (PK ) — это уникальный идентификатор для данного объекта. С его помощью вы можете выбрать данные конкретного клиента, даже если знаете только это значение.
Атрибуты, выбранные в качестве первичных ключей, должны быть уникальными, неизменяемыми и для них не может быть задано значение NULL (они не могут быть пустыми ). По этой причине номера заказов и имена пользователей являются подходящими первичными ключами, а номера телефонов или адреса — нет. Также можно использовать в качестве первичного ключа несколько полей одновременно (это называется составным ключом ).
Когда придет время создавать фактическую БД , вы реализуете как логическую, так и физическую структуру через язык определения данных, поддерживаемый вашей СУБД .
Также необходимо оценить размер БД , чтобы убедиться, что можно получить требуемый уровень производительности и у вас достаточно места для хранения данных.
Теперь, когда данные преобразованы в таблицы, нужно проанализировать связи между ними. Сложность базы данных определяется количеством элементов, взаимодействующих между двумя связанными таблицами. Определение сложности помогает убедиться, что вы разделили данные на таблицы наиболее эффективно.
Каждый объект может быть взаимосвязан с другим с помощью одного из трех типов связи:
Когда существует только один экземпляр объекта A для каждого экземпляра объекта B, говорят, что между ними существует связь «один-к одному » (часто обозначается 1:1 ). Можно указать этот тип связи в ER-диаграмме линией с тире на каждом конце:
Если при проектировании и разработке баз данных у вас нет оснований разделять эти данные, связь 1:1 обычно указывает на то, что в лучше объединить эти таблицы в одну.
Но при определенных обстоятельствах целесообразнее создавать таблицы со связями 1:1 . Если есть поле с необязательными данными, например «описание», которое не заполнено для многих записей, можно переместить все описания в отдельную таблицу, исключая пустые поля и улучшая производительность базы данных.
Чтобы гарантировать, что данные соотносятся правильно, в нужно будет включить, по крайней мере, один идентичный столбец в каждой таблице. Скорее всего, это будет первичный ключ.
Эта связи возникают, когда запись в одной таблице связана с несколькими записями в другой. Например, один клиент мог разместить много заказов, или у читателя может быть сразу несколько книг, взятых в библиотеке. Связи «один- ко-многим » (1:M ) обозначаются так называемой «меткой ноги вороны», как в этом примере:
Чтобы реализовать связь 1:M , добавьте первичный ключ из «одной » таблицы в качестве атрибута в другую таблицу. Если первичный ключ таким образом указан в другой таблице, он называется внешним ключом. Таблица со стороны связи «1 » представляет собой родительскую таблицу для дочерней таблицы на другой стороне.
Когда несколько объектов таблицы могут быть связаны с несколькими объектами другой. Говорят, что они имеют связь «многие-ко-многим » (M:N ). Например, в случае студентов и курсов, поскольку студент может посещать много курсов, и каждый курс могут посещать много студентов.
На ER-диаграмме эти связи отображаются с помощью следующих строк:
При проектировании структуры базы данных реализовать такого рода связи невозможно. Вместо этого нужно разбить их на две связи «один-ко-многим ».
Для этого нужно создать между этими двумя таблицами новую сущность. Если между продажами и продуктами существует связь M:N , можно назвать этот новый объект «sold_products », так как он будет содержать данные для каждой продажи. И таблица продаж, и таблица товаров будут иметь связь 1:M с sold_products . Этот вид промежуточного объекта в различных моделях называется таблицей ссылок, ассоциативным объектом или таблицей связей.
Каждая запись в таблице связей будет соответствовать двум сущностям из соседних таблиц. Например, таблица связей между студентами и курсами может выглядеть следующим образом:
Другим способом анализа связей является рассмотрение того, какая сторона связи должна существовать, чтобы существовала другая. Необязательная сторона может быть отмечена кружком на линии. Например, страна должна существовать для того, чтобы иметь представителя в Организации Объединенных Наций, а не наоборот:
Два объекта могут быть взаимозависимыми (один не может существовать без другого ).
Иногда при проектировании базы данных таблица указывает на себя саму. Например, таблица сотрудников может иметь атрибут «руководитель», который ссылается на другое лицо в этой же таблице. Это называется рекурсивными связями.
Лишние связи — это те, которые выражены более одного раза. Как правило, можно удалить одну из таких связей без потери какой-либо важной информации. Например, если объект «ученики » имеет прямую связь с другим объектом, называемым «учителя », но также имеет косвенные отношения с учителями через «предметы », нужно удалить связь между «учениками » и «учителями ». Так как единственный способ, которым ученикам назначают учителей — это предметы.
После предварительного проектирования базы данных можно применить правила нормализации, чтобы убедиться, что таблицы структурированы правильно.
В то же время не все базы данных необходимо нормализовать. В целом, базы с обработкой транзакций в реальном времени (OLTP ), должны быть нормализованы.
Базы данных с интерактивной аналитической обработкой (OLAP ), позволяющие проще и быстрее выполнять анализ данных, могут быть более эффективными с определенной степенью денормализации. Основным критерием здесь является скорость вычислений. Каждая форма или уровень нормализации включает правила, связанные с нижними формами.
Первая форма нормализации (сокращенно 1NF ) гласит, что во время логического проектирования базы данных каждая ячейка в таблице может иметь только одно значение, а не список значений. Поэтому таблица, подобная той, которая приведена ниже, не соответствует 1NF :
Возможно, у вас возникнет желание обойти это ограничение, разделив данные на дополнительные столбцы. Но это также противоречит правилам: таблица с группами повторяющихся или тесно связанных атрибутов не соответствует первой форме нормализации. Например, приведенная ниже таблица не соответствует 1NF :
Вместо этого во время физического проектирования базы данных разделите данные на несколько таблиц или записей, пока каждая ячейка не будет содержать только одно значение, и дополнительных столбцов не будет. Такие данные считаются разбитыми до наименьшего полезного размера. В приведенной выше таблице можно создать дополнительную таблицу «Реквизиты продаж », которая будет соответствовать конкретным продуктам с продажами. «Продажи » будут иметь связь 1:M с «Реквизитами продаж ».
Вторая форма нормализации (2NF ) предусматривает, что каждый из атрибутов должен полностью зависеть от первичного ключа. Каждый атрибут должен напрямую зависеть от всего первичного ключа, а не косвенно через другой атрибут.
Например, атрибут «возраст » зависит от «дня рождения », который, в свою очередь, зависит от «ID студента », имеет частичную функциональную зависимость. Таблица, содержащая эти атрибуты, не будет соответствовать второй форме нормализации.
Кроме этого таблица с первичным ключом, состоящим из нескольких полей, нарушает вторую форму нормализации, если одно или несколько полей не зависят от каждой части ключа.
Таким образом, таблица с этими полями не будет соответствовать второй форме нормализации, поскольку атрибут «название товара » зависит от идентификатора продукта, но не от номера заказа:
Третья форма нормализации (3NF ) : каждый не ключевой столбец должен быть независим от любого другого столбца. Если при проектировании реляционной базы данных изменение значения в одном не ключевом столбце вызывает изменение другого значения, эта таблица не соответствует третьей форме нормализации.
В соответствии с 3NF , нельзя хранить в таблице любые производные данные, такие как столбец «Налог », который в приведенном ниже примере, напрямую зависит от общей стоимости заказа:
В свое время были предложены дополнительные формы нормализации. В том числе форма нормализации Бойса-Кодда , четвертая-шестая формы и нормализации доменного ключа, но первые три являются наиболее распространенными.
Некоторым пользователям может потребоваться доступ к нескольким разрезам одного типа данных, особенно в базах данных OLAP. Например, им может потребоваться узнать продажи по клиенту, стране и месяцу. В этой ситуации лучше создать центральную таблицу, на которую могут ссылаться таблицы клиентов, стран и месяцев. Например:
Также с помощью средств проектирования баз данных необходимо настроить БД с учетом возможности проверки данных на соответствие определенным правилам. Многие СУБД , такие как Microsoft Access , автоматически применяют некоторые из этих правил.
Правило целостности гласит, что первичный ключ никогда не может быть равен NULL . Если ключ состоит из нескольких столбцов, ни один из них не может быть равен NULL . В противном случае он может неоднозначно идентифицировать запись.
Правило целостности ссылок требует, чтобы каждый внешний ключ, указанный в одной таблице, сопоставлялся с одним первичным ключом в таблице, на которую он ссылается. Если первичный ключ изменяется или удаляется, эти изменения необходимо реализовать во всех объектах, на которые ссылается этот ключ в базе данных.
Правила целостности бизнес-логики обеспечивают соответствие данных определенным логическим параметрам. Например, время встречи должно быть в пределах стандартных рабочих часов.
Индекс — это отсортированная копия одного или нескольких столбцов со значениями в возрастающем или убывающем порядке. Добавление индекса позволяет быстрее находить записи. Вместо повторной сортировки для каждого запроса система может обращаться к записям в порядке, указанном индексом.
Хотя индексы ускоряют извлечение данных, они могут замедлять добавление, обновление и удаление данных, поскольку индекс нужно перестраивать всякий раз, когда изменяется запись.
Представление — это сохраненный запрос данных. Представления могут включать в себя данные из нескольких таблиц или отображать часть таблицы.
После проектирования модели базы данных можно уточнить БД с помощью расширенных свойств, таких как справочный текст, маски ввода и правила форматирования, которые применяются к конкретной схеме, представлению или столбцу. Преимущество этого метода заключается в том, что, поскольку эти правила хранятся в самой базе, представление данных будет согласовано между несколькими программами, которые обращаются к данным.
Унифицированный язык моделирования (UML ) — это еще один визуальный способ выражения сложных систем, созданных на объектно-ориентированном языке. Некоторые из концепций, упомянутых в этом руководстве, известны в UML под разными названиями. Например, объект в UML известен, как класс.
Сейчас UML используется не так часто. В наши дни он применяется академически и в общении между разработчиками программного обеспечения и их клиентами.
Структура проектируемой базы данных зависит от того, какую СУБД вы используете. Некоторые из наиболее распространенных:
Подходящую систему управления базами данных можно выбирать исходя из стоимости, установленной операционной системы, наличия различных функций и т. д.
Перевод статьи «Database Structure and Design Tutorial » дружной командой проекта
В первой статье из цикла «Данные в WordPress» я привела обзорные сведения об использовании реляционных баз данных в WordPress: какие таблицы используются, и какие данные…
Для защиты конфиденциальных данных в MySQL 5.7 появилась возможность шифрования данных с помощью движка InnoDB. В этой статье я объясню принципы шифрования баз данных,…
