Третья нормальная форма

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

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

• Код продукта (первичный ключ)

• Имя

• Рекомендуемая розничная цена

• Скидка

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

Даталогическая модель базы данных

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

Одноимённые (общие) поля в связанных таблицах

Пусть имеется таблица хоздоговоров «Договор» с полями: Номер_догов (ключ), Код_заказчика, Цена_догов, и т.д.:

Договор

Номер_догов (кл.)

Код_заказчика

Цена_догов

Договор может быть заключен на несколько лет. С целью месячного учета фактических затрат по каждому договору создана таблицы «Факт» с полями: Ном_дог, Год, Месяц, Цена_дог, Затраты_на_оборуд, и т.д. Ключ этой таблицы: Номер_дог + Год + Месяц:

Факт

Номер_догов (кл.)

Год (кл.)

Месяц (кл.)

Цена_догов

Затраты_на_оборуд

Получилась связанная пара таблиц в которой ключ таблицы «Договор» является старшей частью ключа таблицы «Факт». Обратим внимание на поле «Цена» в обоих таблицах - одинаковые поля и казалось бы нужно принимать меры по устранению избыточности. Но в данном случае это поле заполняется по смыслу независимо и должен быть механизм контроля за одинаковостью.

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

Поиск информации. Индексные файлы

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

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

Теперь усложним задачу и зададим следующий вопрос: «Перечислить сотрудников отдела В с зарплатой менее 80000 рублей». В этом случае придется сначала упорядочить таблицу по коду отдела, но тогда нарушится упорядочение по табельному номеру и по нему - опять придем к медленному варианту поиска - перебору.

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

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

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

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

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

Существует ещё один способ сократить поиск – хэширование. Общая идея: завести массив фиксированной длины и придумать функцию, осуществляющую отображение значение ключа записи на множество индексов массива 0...n, где n - размер массива. Обычно размер массива много меньше количества записей, так что отображение получается неоднозначное. Если различные ключи приводят в один и тот же индекс массива, то возникает конфликт. Обычно этот конфликт разрешается таким образом: каждый элемент массива содержит не одну запись, а список записей. То есть для поиска записи по ключу: а) находим индекс i по хэш-функции; б) перебираем весь список элементов этого индекса для поиска элемента с требуемым ключём.