708 Тульский механический завод.

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

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

3. Понятия первичного и внешнего ключа.

Для выполнения операций над данными необходимо иметь для каждой записи (строки) таблицы уникальный идентификатор, значение которого однозначно определяет только эту запись. Этот идентификатор называют Первичный (главный) ключ (primary key). Он может состоять из одного или нескольких полей. Например, в TELEF (телефонный справочник, см. пример)- роль ключа выполняет одно поле- Номер телефона, а в SEBEST- 3 поля: Фирма, Прод., Сх.

Главный ключ должен обладать двумя свойствами:

1. Однозначной идентификацией записи.

2. Отсутствием избыточности - никакое поле нельзя удалить из ключа, не нарушая при этом однозначности (первого свойства).

В примере ZAKAZ - главным ключом является номер завода (поскольку бессмысленно иметь иначе).

Главным ключом в таблице KADR «просится» быть Ф.И.О…. (посмотрим далее).

Таким образом, указание главного ключа - это и есть единственный способ отличить один экземпляр объекта от другого.

Вернемся к Ф.И.О.- это не надежный ключ. Более надежным является в пределах предприятия - табельный номер; в пределах страны - номер и серия паспорта или просто один номер (как в США- social secuirity number).

Слово «главный» предполагает и наличие неглавного или простого ключа. Этот термин возникает в операции, подразумевающей просмотр по какому-либо полю. Например, по полю «Катег» в примере с телефонным справочником. Т.е. при этом «Катег» - это простой ключ и его значение может быть неуникальным.

Существует, также, понятие Внешний ключ (foreign key), - это поле таблицы, значения которого выбираются из связанного с ним справочника (словаря).

Один из выводов по ключам: главный ключ - только один, а простых ключей может быть множество.

Простые ключи используются при так называемом индексировании (об этом далее).

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

Общие правила проектирования БД

Пользуясь рассмотренными понятиями можно спроектировать совокупность таблиц, которая и образует БД. Например, в БД для задачи Заказ может содержаться три таблицы.

- Заказ;

- Словарь заказчиков;

- Словарь продукции.

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

- количество таблиц должно быть по возможности минимальным;

- таблицы должны быть нормализованы с учетом некоторых правил (рассмотрим далее).

Существует строгая теория проектирования реляционных БД, однако практическое ее применение, как показал опыт, вызывает большие проблемы.

Почему проект БД может быть плохим

В выбранной модели все хранимые данные должны быть размещены в одной или нескольких таблицах. Можно ли для этой цели использовать единственную таблицу, так называемое, универсальное отношение?

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

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

Аномалии обновления

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

Аномалии включения

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

Аномалии удаления

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

Вычисляемые значения

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

Нормализация

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

Задача нормализации

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

Но такая нормализация не дает оптимальной двумерной структуры. Могут возникнуть неприятности, приводящие к потерям данных.

В качестве неудачно спроектированной рассмотрим таблицу ZAKAZ. Что неправильно? В нее включено поле «Реквизиты» заказчика, значение которого зависит от значения кода заказчика, но не зависит от ключа таблицы - номера заказа. Появляется возможность потери информации- при удалении заказа (обычная операция) будут утрачены и сведения о реквизитах заказчика (если это единственный заказ этого заказчика). Если у одного заказчика заказов много, то нужно как-то избежать повторного их ввода.

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

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

Если применить этот принцип снова к тому же примеру - обнаружим еще поле «Цена» - его значение является функцией поля «Код_прод», поэтому следует поступить аналогично «Реквизитам» - сделать словарем.

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

Таким образом, после вынесения третьего и седьмого полей в словари мы получим оптимально-компромиссное решение. Компромисс заключается, с одной стороны, в полноте нормализации, с другой - в минимизации числа таблиц.

Выводы:

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

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

2. Если главный ключ не просматривается - подумать, правильно ли подобран состав полей.

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

Повторяющиеся группы

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

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

Если все это попросту включить в файл KADR, то число полей для каждой записи придется брать по максимуму. Например, ученый может иметь до 10 премий, тогда придется включать в общую таблицу 20 полей: ДАТА1, КОД1; ДАТА2, КОД2;… Большая часть значений этих полей будет пустой.

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

PREM

Таб_ном

Дата_присужд

Код_прем

Главным ключом в этой таблице является Таб_ном + Дата_присуж. Если допустить, что в один день сотрудник может получить две премии (в юбилей), то в

главный ключ придется включить все поля. Одновременно придется ввести и словарь:

SL_PREM

Код_прем

Назв_прем

Рассмотрим еще один пример.

Необходимо вести список сплавов с указанием значений всех возможных параметров для каждого из них. Допустим число параметров равно 100 (плотность, теплоемкость, температура плавления, и т.д.). тогда таблица становится громоздкой:

Сплав

Код_спл

Пар1

Пар2

…

Пар100

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

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

Сплав-Параметр

Код_спл

Код_парам

Знач_парам

к которой, как и в предыдущем примере нужен словарь (справочник) параметров, содержащий код, наименование и описание параметра.

Единственный недостаток этой таблицы - многократное повторение кода одного и того же сплава.

Нормальные формы

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

Первая нормальная форма

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

Вторая нормальная форма

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

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

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

Имя продукта

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

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

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

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

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

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

Имя

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

Скидка

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

Теория нормализации основывается на зависимостях между полями (функциональные зависимости).

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

Определённое значение ключегого атрибута соответствует только 1 значению описательного атрибута.

Полн. функц. Зависимость: поле, наход. в полн. функц. завис-ти, если оно зависит от составного ключа и не зависит от его части.

Табл. в 1 н.ф. – ни одна строка не содержит в своём поле более 1 значения и ни одно из ключ.полей не пусто.

Табл. в 2 н.ф. – удовл.определению 1 н.ф.+все её поля, не вход. В первич. ключ, связ. полн. фунц. зависимостью с первич. ключом.

Табл. в 3 н.ф. – удовл.определению 2 н.ф.+ни одно из её неключ.полей не зависит от др.неключ. полей функц-но+кажд. из неключ. Атрибутов нетранзитивно завис. от первичного ключа.

Транзитивная зависимость – один из 2описат. атрибутов зависит от ключа, а другой зависит от первого.

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

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

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

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

Договор

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

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

Цена_догов

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

Факт

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

Год (кл.)

Месяц (кл.)

Цена_догов

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

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

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