Учет междугородних телефонных разговоров (стр. 2 из 3)

1. один-к-одному (1:1),

2. один-ко-многим (1:М),

3. многие-ко-многим (М:М).

Связь "один-к-одному" означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности. Связь "один-ко-многим"(1: М) означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи, а связь "многие-к-одному" (M:1) означает, что один экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и наоборот, один экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности.

Определим типы связей наших сущностей. Данные представлены в таблице, па рисунке №2.

Тип сущности	Связь	Тип сущности	Кардинальность связи
Заказчик	Заказывает	Телефонный звонок	1:М
Получатель	Получает	Телефонный звонок	М:1

Рис.№2. Сведения о типах связей

1.3 0пределение атрибутов и связывание их с типами сущностей и связей

Цель: связывание атрибутов с типами сущности и связи.

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

Кроме того, в ER-модели допускается принцип категоризации сущностей. Это значит, что, как и в объектно-ориентированных языках программирования, вводится понятие подтипа сущности, то есть сущность может быть представлена в виде двух или более своих подтипов — сущностей, каждая из которых может иметь общие атрибуты и отношения и/или атрибуты и отношения, которые определяются однажды на верхнем уровне и наследуются на нижнем уровне.

Атрибуты бывают:

- простые;

- составные - состоят из простых атрибутов;

- однозначные - атрибуты, которые могут принимать единственное значение;

- многозначные - атрибуты, которые могут принимать много значений;

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

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

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

1. имя атрибута и его описание;

2. любые алиасы или синонимы, имеющиеся для данного атрибута;

3. тип данных и размерность значений;

4. значение, принимаемое для атрибута по умолчанию, если таковое имеется;

5. является ли атрибут обязательным;

6. является ли атрибут составным;

7. является ли атрибут производным;

8. является ли атрибут многозначным.

Сведения об атрибутах представлены в таблице на рис.№3.

Атрибуты	Тип данных	Простой	Синонимы	Описание
Заказчик разговора
Код абонента	счётчик	Код абонента, заказчика разговора
ФИО	текстовый	Личные данные абонента	Личные данные абонента
Адрес	Текстовый	-	Адрес абонента	Адрес абонента
№_телефона_заказчика	Числовой	№_телефона_заказчика	№_телефона_заказчика
Дата	Дата/время	Дата	Дата звонка
Время	Дата/время	Время	Время звонка

Рис.№3.

1.4 0пределение доменов атрибутов

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

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

1. набор допустимых значений для атрибутов;

2. сведения о размере и формате каждого из полей атрибутов.

После выделения всех имеющихся доменов их документируют, присваивают осмысленные имена.

Сведения о доменах атрибутов представлены в таблице на рисунке №4.

Рис.№4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.№5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.№6.

2.2 Проверка моделей с помощью правил нормализации

Цель: проверка локальной логической модели данных с использованием технологии нормализации. Технология проектирования реляционных баз данных связано с теорией нормализации, основанной на анализе функциональных зависимостей между атрибутами отношений. Понятие функциональной зависимости является фундаментальным в теории нормализации реляционных баз данных. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области. Именно поэтому процесс поддержки функциональных зависимостей, характерных для данной предметной области, является базовым для процесса проектирования. Нормализация - это метод создания набора отношений с заданными свойствами на основе требуемых данных, установленных некоторой организацией. Это формальный метод анализа отношений на основе первичного ключа и существующих функциональных зависимостей. Он включает ряд правил, которые могут использоваться для проверки отдельных отношений таким образом, чтобы вся БД была нормализована до желаемой степени нормализации. В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм: