База данных может содержать до 32768 объектов.
В состав Accessвходит множество мастеров, построителей и надстроек, которые позволяют упростить процесс создания объектов базы данных.
2.6 Разработка структуры базы данных и отношений атрибутов
Осуществляется детализация хранилищ данных, а также документально обосновываются сущности системы и способы их взаимодействия, включая идентификацию объектов предметной области (сущностей), свойств этих объектов (атрибутов) и их связей (отношений).
Сущность представляет собой множество экземпляров реальных или абстрактных объектов, обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. Отношение в самом общем виде представляет собой связь между двумя и более сущностями. Отношение должно быть однозначно поименовано.
Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются связи. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности. Значение связи характеризует её тип и выбирается из множества: "0 или 1", "0 или более", "1", "1 или более", "диапазон p:q". Пара значений связей, принадлежащая одному и тому же отношению, определит тип этого отношения.
Для большинства приложений достаточно использовать следующие типы отношений:
один к одному (используется на верхних уровнях иерархии модели данных, на нижних встречается редко);
один ко многим (отношения такого типа являются наиболее часто используемыми);
многие ко многим (используется на ранних этапах проектирования с целью прояснения ситуации).
В дальнейшем каждое из отношений типа "многие ко многим" должно быть преобразовано в комбинацию типов отношений "один к одному" или "один ко многим" (возможно с введением вспомогательных ассоциативных сущностей и с введением новых отношений).
Каждая сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности. При этом любой атрибут может быть определен как ключевой.
Все связи являются бинарными и представляют собой линии с двумя концами, соединяющими сущности, для которых должно быть определено имя, степень множественности и степень обязательности. Степень множественности определяет, один или много объектов участвуют в связи. Степень обязательности определяет, обязательна ли или не обязательна данная связь между сущностями.
Разработка структуры базы данных включает такие основные этапы, как:
идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей;
идентификация отношений между сущностями и указание типов отношений;
разрешение неспецифических видов отношений (многие к многим).
Этап 1 является определяющим при построении модели. Исходной информацией для этого этапа служит содержание хранилищ данных, определяемое входящими и выходящими из него потоками. Первоначально осуществляется анализ хранилища, включающий сравнение содержимого входных и выходных потоков и создания на основе этого сравнения варианта схемы хранилища. На следующем шаге осуществляется упрощение схемы путем устранения избыточности. Следующий шаг – упрощение схемы при помощи нормализации (удаление повторяющихся групп). Единственным способом нормализации является расщепление данной схемы на две более простые. Далее производится определение ключевых атрибутов для идентификации сущности.
Для шага нормализации существуют концепции и методы, разработанные Коддом (Codd). Он установил три типа нормализованных схем, называемых первой, второй и третьей нормальной формой.
Согласно Кодду любая нормализованная схема (схема без повторяющихся групп) автоматически находится в первой нормальной форме (1НФ), независимо от того, насколько сложен ее ключ и какая взаимосвязь может существовать между ее элементами. По определению схема находится во второй нормальной форме (2НФ), если все её ключевые атрибуты полностью зависят от ключа. Схема находится в третьей нормальной форме (3НФ), если она находится во 2НФ, и ни какой неключевой атрибут не зависит от другого неключевого атрибута.
Этап 2 служит для выявления и определения отношений между сущностями, а также для идентификации типов отношений. На этом этапе допускаются неспецифические отношения "многие ко многим".
Определение отношений включает выявление связей, для этого отношение должно быть проверено в обоих направлениях следующим образом: выбирается экземпляр одной из сущностей и определяется, сколько различных экземпляров второй сущности может быть с ним связано.
Этап 3 предназначен для разрешения отношений "многие ко многим". Для этого каждое такое неспецифическое отношение преобразуется в два специфических с введением новых.
2.6.1 Нормализация базы данных
Нормализация таблиц базы данных - первый шаг на пути проектирования структуры реляционной базы данных. Строго говоря, конечно, не самый первый - сначала надо решить, что же мы вообще будем хранить в базе, то есть определиться со структурой полей, их типами и размерностью, смыслом хранимой в них информации.
Теория нормализации реляционных баз данных была разработана в конце 70-х годов 20 века. Согласно ей, выделяются шесть нормальных форм, пять из которых так и называются: первая, вторая, третья, четвертая, пятая нормальная форма, а также нормальная форма Бойса-Кодда, лежащая между третьей и четвертой.
База данных считается нормализованной, если ее таблицы (по крайней мере, большинство таблиц) представлены как минимум в третьей нормальной форме. Часто многие таблицы нормализуются до четвертой нормальной формы, иногда, наоборот, производится денормализация.
Главная цель нормализации базы данных - устранение избыточности и дублирования информации. В идеале при нормализации надо добиться, чтобы любое значение хранилось в базе в одном экземпляре, причем значение это не должно быть получено расчетным путем из других данных, хранящихся в базе.
Первая нормальная форма
Первая нормальная форма:
запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию)
запрещает множественные столбцы (содержащие значения типа списка и т.п.)
требует определить первичный ключ для таблицы, то есть тот столбец или комбинацию столбцов, которые однозначно определяют каждую строку
Вторая нормальная форма
Вторая нормальная форма требует, чтобы неключевые столбцы таблиц зависели от первичного ключа в целом, но не от его части: если таблица находится в первой нормальной форме и первичный ключ у нее состоит из одного столбца, то она автоматически находится и во второй нормальной форме.
Третья нормальная форма
Чтобы таблица находилась в третьей нормальной форме, необходимо, чтобы неключевые столбцы в ней не зависели от других неключевых столбцов, а зависели только от первичного ключа. Самая распространенная ситуация в данном контексте - это расчетные столбцы, значения которых можно получить путем каких-либо манипуляций с другими столбцами таблицы. Для приведения таблицы в третью нормальную форму такие столбцы из таблиц надо удалить.
Нормальная форма Бойса-Кодда
Нормальная форма Бойса-Кодда требует, чтобы в таблице был только один потенциальный первичный ключ. Чаще всего у таблиц, находящихся в третьей нормальной форме, так и бывает, но не всегда. Если обнаружился второй столбец (комбинация столбцов), позволяющий однозначно идентифицировать строку, то для приведения к нормальной форме Бойса-Кодда такие данные надо вынести в отдельную таблицу.
Четвертая нормальная форма
Для приведения таблицы, находящейся в нормальной форме Бойса-Кодда, к четвертой нормальной форме необходимо устранить имеющиеся в ней многозначные зависимости. То есть обеспечить, чтобы вставка / удаление любой строки таблицы не требовала бы вставки / удаления / модификации других строк этой же таблицы.
Пятая нормальная форма
Таблицу, находящуюся в четвертой нормальной форме и, казалось бы, уже нормализованную до предела, в некоторых случаях еще можно бывает разбить на три или более таблиц, соединив которые, мы получим исходную таблицу. Получившиеся в результате такой, как правило, весьма искусственной, декомпозиции таблицы и называют находящимися в пятой нормальная форме. Формальное определение пятой нормальной формы таково: это форма, в которой устранены зависимости соединения. В большинстве случаев практической пользы от нормализации таблиц до пятой нормальной формы не наблюдается.
Разработаны специальные формальные математические методы нормализации таблиц реляционных баз данных. На практике проектировщик баз данных, детально познакомившись с предметной областью, как правило, достаточно быстро создаст структуру, в которой большинство таблиц находятся в четвертой нормальной форме:.
Главное, чего мы добьемся, проведя нормализацию базы данных - это устранение (или, по крайней мере, серьезное сокращение) избыточности, дублирования данных. Как следствие, значительно сокращается вероятность появления противоречивых данных, облегчается администрирование базы и обновление информации в ней, сокращается объем дискового пространства.