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

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

Выделяют следующие виды ключей:

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

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

3. внешний ключ - это атрибут или группа атрибутов дочерней сущности, которые соответствуют первичному ключу родительской сущности.

4. составной ключ - первичный ключ, состоящий из нескольких атрибутов.

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

1. использовать потенциальный ключ с минимальным набором атрибутов;

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

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

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

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

1.6Создание диаграммы "сущность — связь"

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

Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь " или называемая ещё ER-моделью.

Моделирование предметной области при помощи модели "сущность-связь" базируется на использовании графических диаграмм.

Рис.№5

П. Логическое проектирование

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

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

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

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

Проверка связей

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

Первым пунктом является удаление связи " многие ко многим". Удалить эту связь можно путем ввода промежуточной сущности. Такая связь ^х в моей курсовой работе отсутствует, так как была сразу выделена в качестве отдельной сущность "марка".

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

Вторым пунктом является удаление сложных связей - связей существующих между тремя и более типами сущности. Такие связи в моей модели отсутствуют.

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

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

Далее необходимо удалить множественные атрибуты, если они имеются. В данном случае их нет.

Также следует проверить связи типа один-к-одному. В разрабатываемой мною модели такие связи вообще отсутствуют.

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

Пример выборки по связям на рисунке 6:

Рис.№6.