Рассмотрим пример, связанный с зачислением сотрудников в различные отделы организации.
При отсутствии жестких правил (сотрудник может одновременно зачисляться в несколько отделов или не зачисляться ни в один отдел) необходимо создать описание с ассоциацией Зачисление:
Отделы (Номер отдела, Название отдела, ...)Служащие (Табельный номер, Фамилия, ...)Зачисление [Отделы M, Служащие N](Номер отдела, Табельный номер, Дата зачисления).Однако, при условии, что каждый из сотрудников должен быть обязательно зачислен в один из отделов, можно создать описание с обозначением Служащие:
Отделы (Номер отдела, Название отдела, ...)Служащие (Табельный номер, Фамилия, ... , Номер отдела,Дата зачисления)[Отделы]В данном примере служащие имеют независимое существование (если удаляется отдел, то из этого не следует, что также должны быть удалены служащие такого отдела). Поэтому они не могут быть характеристиками отделов и названы обозначениями.
Обозначения используют для хранения повторяющихся значений больших текстовых атрибутов: "кодификаторы" изучаемых студентами дисциплин, наименований организаций и их отделов, перечней товаров и т.п.
Описание обозначения внешне отличается от описания характеристики только тем, что обозначаемые сущности заключается не в фигурные скобки, а в квадратные:
ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2, ...)[СПИСОК ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ].Как правило, обозначения не рассматриваются как полноправные сущности, хотя это не привело бы к какой-либо ошибке.
Обозначения и характеристики не являются полностью независимыми сущностями, поскольку они предполагают наличие некоторой другой сущности, которая будет "обозначаться" или "характеризоваться". Однако они все же представляют собой частные случаи сущности и могут, конечно, иметь свойства, могут участвовать в ассоциациях, обозначениях и иметь свои собственные (более низкого уровня) характеристики. Подчеркнем также, что все экземпляры характеристики должны быть обязательно связаны с каким-либо экземпляром характеризуемой сущности. Однако допускается, чтобы некоторые экземпляры характеризуемой сущности не имели связей.
1.3 Реляционная модель данных
Основу реляционной модели составляет совокупность данных, объединенных в виде отношений (таблиц). Из теории множеств известно, что формальным аналогом любой таблицы является отношение.
Пусть имеется некоторая совокупность множеств D1, D2, … DN. Отношением R на этих множествах называется подмножество их декартового произведения, где N - это степень отношения. Картеж - это совокупность элементов множеств, причем порядок имеет существенное значение, т.к. каждый элемент множества должен принадлежать только своему домену. Запись вида R(A,B,C) называется схемой отношения и наряду с названием отношения содержит имена атрибутов. Совокупность схем отношений составляет схему реляционной БД.
Количество картежей называется мощностью отношения.
1.4 Нормальные формы отношений
Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных.
Таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто.
Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.
Таблица находится в третьей нормальной форме (3НФ), если она удовлетворяет определению 2НФ и не одно из ее неключевых полей не зависит функционально от любого другого неключевого поля.
Таблица находится в нормальной форме Бойса-Кодда (НФБК), если и только если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа.
2 Этапы проектирования БД
Жизненный цикл БД представляет собой концепцию, в рамках которой рассматривается развитие БД во времени. Жизненный цикл БД делится на две фазы:
- фаза анализа и проектирования,
- фаза эксплуатации.
В течение 1-ой фазы происходит сбор требований пользователей и проектирование БД. В течение 2-ой фазы происходит машинная реализация (создание и отладка программ, проектирование входных и выходных форм и т.д.). Последовательность выполнения этапов и решения задач представлена на рис. 2:
Формулировка и анализ требований относится к первой фазе и является наиболее трудным и длительным во времени этапом процесса проектирования.
Однако он является наиболее важным, т.к. на его базе строится большинство проектных решений. Основной задачей является сбор требований, предъявляемых к содержанию и процессу обработки данных пользователями всех уровней. Анализ требований обеспечивает согласованность целей пользователей, а также согласованность их представлений об информационных потоках. На основе анализа требований устанавливаются цели организации, определяются требования к БД, вытекающие из основных задач. Эти требования документируются в форме доступной пользователям и проектировщикам БД. Для более тщательного анализа требований используется методика тестирования или анкетирования пользователя различного уровня. Результатом этого этапа является определение формата и семантики данных.
Концептуальное проектирование имеет своей целью построение независимой от СУБД информационной структуры путем объединения информационных требований пользователя. Результатом этого этапа является представление информационных требований в виде диаграмм «сущность-связь». Основу этой диаграммы представляет набор сущностей, который моделирует определенную совокупность сведений, сведенных к требованиям.
Сущность представляет собой основное содержание того явления или процесса, о котором необходимо собрать информацию (она является узловой точкой сбора данных). Необходимо различать тип сущности и экземпляр сущности. Тип сущности - это набор однородных вещей, предметов, явлений, выступающих как единое целое. Экземпляр сущности относится к конкретной вещи, т.е. когда вместо общих характеристик появляются конкретные данные.
Сущность является наиболее общим понятием по сравнению с объектом предметной области. При построении диаграмм «сущность-связь» возникают некоторые сложности, связанные с тем, что одни и те же пользователи БД имеют различные представления одних и тех же фактов.
Проектирование реализации также относится к 1-ой фазе жизненного цикла и состоит из двух компонент:
- проектирование БД на уровне логической структуры,
- проектирование программ.
Структурой БД является СУБД, ориентированное описание данных или схема, обычно выраженная в терминах языка описания данных.
Проектирование программного обеспечения имеет целью создание структурированных программ, использующих язык программирования и язык манипулирования данными.
Язык манипулирования данными - это ничто иное как набор команд, осуществляющих различные процедуры манипулирования данными.
Физическое проектирование относится к 1-ой фазе и делится на три категории:
Проектирование формата хранимых записей (сюда включаются виды представления и сжатия данных в записи), распределение элементов данных записей по различным участкам физической памяти в зависимости от их размеров и характеристик использования.
Анализ и проектирование кластеров. Кластеризацией записей называется такое объединение записей различного типа в физические группы, которое позволяет эффективно использовать преимущество последовательного размещения данных.
Проектирование путей доступа к данным (сюда включаются такие параметры и методы, тот которых в значительной степени зависит время доступа и время обработки запросов. Иногда эти параметры называют производительностью системы или производительностью СУБД).
Результатом физического проектирования является физическая структура БД, форматы и размещение в памяти записей и методы доступа к данным.
Векторы. Представляйте векторы данных по столбцам, а не по строкам. Например, диаграмму продаж товаров x, y, ... за последние годы лучше представить в виде:
| ТОВАР | МЕСЯЦ | КОЛ-ВО |
| x | ЯНВАРЬ | 100 |
| x | ФЕВРАЛЬ | 50 |
| … | ... | … |
| x | ДЕКАБРЬ | 360 |
| y | ЯНВАРЬ | 75 |
| … | … | … |
| x | ДЕКАБРЬ | 35 |
| … | … | … |
а не так, как показано ниже:
| ТОВАР | ЯНВАРЬ КОЛ-ВО | ФЕВРАЛЬ КОЛ-ВО | … | ДЕКАБРЬ КОЛ-ВО |
| x | 100 | 50 | … | 360 |
| y | 75 | 144 | … | 35 |
Одна из причин такой рекомендации заключается в том, что при этом значительно проще записываются обобщенные (параметризованные) запросы.
Неопределенные значения. Будьте очень внимательны с неопределенными (NULL) значениями. В поведении неопределенных значений проявляется много произвола и противоречивости. В разных СУБД при выполнении различных операций (сравнение, объединение, сортировка, группирование и другие) два неопределенных значения могут быть или не быть равными друг другу. Они могут по разному влиять на результат выполнения операций по определению средних значений и нахождения количества значений. Для исключения ошибок в ряде СУБД существует возможность замены NULL-значения нулем при выполнении расчетов, объявление всех NULL-значений равными друг другу и т.п.