Разработка базы данных "Микроконтроллеры", страница 2

            «Код заказчика» однозначно определяет экземпляр сущности и, соответственно, является потенциальным ключом.

На диаграмме «Сущность-связь» «Заказчики» имеют  следующее представление:

 

3) Сущность «Заказы» – это сущность слабого типа, так как она зависит от сущностей «Микроконтроллеры» и «Заказчики» (при отсутствии сущности «Микроконтроллеры» исчезает предмет заказа, а при отсутствии сущности «Заказчики» исчезает причина создания заказа). Для существования связи между слабой и сильной сущностями необходимо включить дополнительные общие поля, которыми являются «Код заказчика» и «Название устройства (семейство)». Таким образом, к атрибутам сущности «Заказы» относятся:

Код заказа, код заказчика, дата заказа, дата исполнения, название устройства (семейство), количество заказанных микроконтроллеров.

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

Сущность «Заказы» и ее атрибуты на диаграмме «Сущность - связь» выглядят следующим образом:

 

Между сущностями существуют связи или отношения. Определим все связи между полученными сущностями, выделив показатель кардинальности каждой связи и её степень. Степенью связи, по определению, является количество сущностей участвующих в связи, а показатель кардинальности –  это число связей каждой сущности, участвующей в связи.

1) «Микроконтроллеры» входят в «Заказ»:

 

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

2) «Заказчик» делает «Заказ»:

Степень связи равна двум, кардинальность один ко многим, так заказ может соответствовать только одному заказчику, а заказчик может сделать несколько заказов.

Полная диаграмма «Сущность - связь»:

 

Получение отношений из модели «Сущность - связь»:

Основываясь на  определенной выше модели «Сущность - связь» выделим набор отношений для нашей базы данных.

Для каждой сильной сущности создадим отдельное отношение:

1) Отношение «Микроконтроллеры» (разрядность, название производителя, название устройства (семейство), архитектура, тактовая частота процессора, интерфейс шины, ширина инструкции, номинальные напряжения, номинальная мощность, режимы пониженного энергопотребления, поддержка DSP/multiplicatitoin hardware, FPU, кэш, характеристики памяти, характеристики корпуса, виды таймеров, интерфейсы последовательного /параллельного ввода/вывода, прерывания, характеристики АЦП/ЦАП, интервал рабочих температур, дополнительные возможности, цена).

2) Отношение «Заказчики» (код заказчика, название, контактное лицо, телефон).

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

3) Отношение «Заказы» (код заказа, код заказчика, дата заказа, дата исполнения, название устройства (семейство), количество заказанных микроконтроллеров).

Теперь, принимая во внимание кардинальность связей между сущностями, необходимо следовать следующим правилам:

1.  Если две или более сущности участвуют в связи «один ко многим», то отношение с кардинальностью «многие» должно иметь поле внешнего ключа, представляющего эту связь.

2.  Если две сущности участвуют в отношении «многие ко многим», то создается отношение, состоящее из полей ключей обеих сущностей.

Исходя из этого, в отношении «Заказы» появились атрибуты «Код заказчика» из отношения «Заказчики» и «Название устройства (семейство) из отношения «Микроконтроллеры». Также необходимо создать новое отношение «Заказано», в котором будут содержаться ключевые поля из отношений «Микроконтроллеры» и «Заказы». Из отношения «Заказы» атрибут «Количество заказанных микроконтроллеров» переносится в отношение «Заказано», так как зависит от типа микроконтроллера, определяемого названием семейства.

            3а) Отношение «Заказы» (код заказа, код заказчика, дата заказа, дата исполнения).

4) Отношение «Заказано» (код заказа, название устройства (семейство), количество заказанных микроконтроллеров).

            Таким образом, следуя методу построения модели «Сущность – связь» мы выделили набор отношений для базы данных.

Нормализация отношений:

Поскольку выделенные отношения не могут полностью отразить структурную и функциональную зависимости данных, проведем процедуру анализа и построения отношений на основе изучения функциональных связей между атрибутами отношений, называемую нормализацией. Нормализация направлена на минимизацию дублирования данных, удаление нежелательных  функциональных зависимостей, а также на исключение аномалий обновления/удаления данных. Современными стандартами разработки баз данных предусматривается 5 нормальных форм отношений, причем каждая последующая форма  должна удовлетворять условиям  предыдущей. В ходе выполнения нормализации мы будем переходить от одной нормальной формы к другой, более строгой. Нормализацию можно будет считать завершенной после приведения данных к 3 усиленной нормальной форме (форме Бойса - Кодда).

1 Нормальная форма. Отношение находится в первой нормальной форме, если в нем нет дубликатов записей и все атрибуты простые. Повторение записей в отношении можно избежать, если есть ключ, однозначно определяющий каждую запись и соответственно запрещающий ее повторение.