Связи

    Связь является логическим соотношением между  сущностями. Каждая связь должна именоваться глаголом или глагольной фразой. Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение построенной модели данных.

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

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

    Имя связи – фраза, характеризующая  отношение между родительской и  дочерней сущностями. Для связи один-ко-многим идентифицирующей или не идентифицирующей достаточно указать имя, характеризующее отношение от родительской к дочерней сущности.

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

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

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

    Основные  этапы проектирования концептуальной модели:

1. Первичный анализ информационных потребностей пользователей, выделение объектов предметной области и формирование исходных отношений:
2. Проектирование исходных отношений:

• определение атрибутов отношений и их типов данных;

• нормализация отношений до 3 НФ.

3. Связывание отношений в концептуальную информационную модель:

• определение первичных ключей отношений;
• определение связей между отношениями.

    3. Создание физической модели данных

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

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

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

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

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

• ввод информации в БД;
• удаление информации из БД;
• редактирование внесенной информации;
• выборка данных по различным критериям;
• формирование отчетов и вывод информации из базы данных на экран и на принтер.

    Ввод, замена и удаление информации должны производится в экранных формах приложения.

 

     2. ОСНОВНЫЕ ЭТАПЫ  ВЫПОЛНЕНИЯ КУРСОВОГО  ПРОЕКТА 

    2.1. Предметная область и постановка задачи 

    1.1 Описание предметной  области

 Учет  телекомпанией стоимости прошедшей  в эфире рекламы 

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

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

         1.2 Постановка задачи

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

    1.3 Описание входных документов

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

    Передачи:

    код передачи;

    Название,

      Рейтинг, 

    Стоимость минуты.

    Реклама:

      Код  рекламы,

      Код  передачи, 

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

    Дата,

    Длительность  в минутах.

    Заказчики:

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

      Название,

      Банковские  реквизиты, 

    Телефон,

    Контактное  лицо. 

    1.4 Описание выходных документов

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

    Отчет обо всех зарегистрированных заказчиков:

    фамилия, имя, отчество ((или фамилия и инициалы) заказчика;

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

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

    - информацию о требуемом заказчике.

2.2 Концептуальное проектирование 
 

    Определение сущностей

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

    Передачи (Код передачи, Название, Рейтинг, Стоимость  минуты).

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

    Заказчики (Код  заказчика, Название, Банковские  реквизиты, Телефон, Контактное лицо).

    Тогда в базе данных предполагается следующая семантика:

    Сущность  Передачи. Каждая передача имеет уникальный номер. Название передачи является также уникальным значением.

    Сущность  Реклама. Каждая реклама  имеет уникальный номер, дату, длительность минуты.

    Сущность  Заказчики. Каждый заказчик имеет свой уникальный код, название фирмы, банковские реквизиты, телефон.  

    Определение типов связей

    Итак, база данных будет иметь следующие  связи:

    Передачи - Реклама

  связь характеризуются типом связи: «один-ко-многим».

         Реклама – Заказчики

связь характеризуются типом связи: «многие-к одному». 

    Инфологическая  модель

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

    Инфологическое  проектирование, прежде всего, связано  с попыткой представления семантики предметной области в модели БД.

    Существует  несколько моделей данных. Для  проектируемой базы данных применена  модель "сущность-связь", которая стала фактическим стандартом при инфологическом моделировании баз данных. Инфологическая модель в области «Телевидение» представлена на рисунке 2.1.

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

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

    Согласно  правилам преобразования ER-модели в  реляционную, определяем отношения (базовые  таблицы), их атрибуты, первичные и внешние ключи.

    Сущности  Передачи будет соответствовать отношение ПЕРЕДАЧИ – 4-арное отношение с первичным ключом Код передачи, свойства атрибутов указаны в таблице 2.1.

    Сущности  Реклама будет соответствовать отношение РЕКЛАМА – 5 – арное отношение с первичным ключом Код рекламы;

    Сущности  Заказчики будет соответствовать отношение ЗАКАЗЧИКИ – 5 – арное отношение с первичным ключом Код заказчика; 

      

    Рис. 2.1 – Инфологическая модель «Телевидение»

 

    Аналогично определяются отношения сущностей Реклама, Заказчики.

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

• «ограничить» операцию удаления, т.е. удаление «запрещается» пока есть хоть одна ссылка на этот объект;
• «ограничить» операцию вставки, т.е. вставка новой строки «запрещается», если значению внешнего ключа не соответствует ни одно значение из родительской таблицы;
• «каскадировать» операцию обновления, обновляя также внешний ключ в дочерней таблице.