Наиболее распространенной степенью связи является двухсторонняя. Двухсторонние связи обычно обозначаются как связи "один к одному" (1:1), "один ко многим" (1:М) или "многие ко многим" (М:N). Также используется понятие «класс принадлежности» экземпляров сущности, он может быть необязательным (на ER-диаграммах обозначается цифрой 0) – если какой-либо экземпляр одной сущности не связан ни с одним экземпляром другой сущности, или обязательным (1) – если все экземпляры одной сущности связаны хотя бы с одним экземпляром другой сущности. Определим связи между заданными сущностями и классы принадлежности:

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

                     Клиент                     «заключает»                   Контракт

 
 

Рис.1.1. Связь между двумя сущностями 
 

    

2. сущности  «Услуга» и «Контракт» имеют вид связи «один ко многим» т.е.  на одну и ту же услугу может быть заключено несколько разных контрактов. Сущность «Контракт» имеет обязательный класс принадлежности, так как не может быть контрактов без предмета его заключения. «Услуга» имеет необязательный класс принадлежности, т.к. могут быть услуги, по которым не заключено ещё ни одного контракта.

 

                      Контракт                «заключается на»                   Услуга

     

    Рис 1.2. Связь между двумя сущностями 

    3)  сущности «Контракт» и «Менеджер» также имеют вид связи «один ко многим», т.к. один менеджер может вести несколько контактов, а для каждого контракта назначается только один менеджер. Сущность «Контракт» имеет обязательный класс принадлежности, так как не может быть контрактов, по которым не назначены менеджеры. «Менеджер» имеет класс принадлежности 0, т.е. могут быть менеджеры ещё не ведущие контрактов.

    

                      Контракт                        «ведет»                    Менеджер

 
 

     Рис. 1.3. Связь между двумя сущностями 

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

 
 
 
 
 
 
 
 

Рис. 1.4. Концептуальная модель базы данных. Связи между сущностями. 

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

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

     Сущности  Договор и Платеж связаны с  другими сущностями по типу «один ко многим». В реляционных базах данных связи между таблицами осуществляются посредством первичных ключей. Поле подчиненной таблицы, по которому осуществляется связь, называется внешним ключом главной таблицы. Таким образом, таблица Договор имеет внешние ключи: Код клиента, Код вида рекламной продукции, Код сотрудника. Таблица Платеж имеет в качестве внешнего ключа поле Номер договора из таблицы Договор. 
 

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

Рисунок 2 Схема связей между  отношениями

     2.2 Физическая  модель базы данных

     Эта модель описывает данные средствами конкретной СУБД. На этом этапе отношение, разработанное с помощью преобразованных ER-диаграмм, превращается в таблицы. Главными вопросами физического проектирования модели являются:

     1) Оптимизация времени основных  запросов;

     2) Обеспечение безопасности выполнения  запросов базы данных.

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

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

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

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

     3 Реализация базы данных в СУБД Microsoft Access

     3.1 Структура таблиц, ключи и индексы

     Создадим  все таблицы («Книги», «Заказы», «Клиенты») в режиме конструктора: нажимаем на кнопке Создание таблицы в режиме конструктор. В появившемся окне конструктора таблиц определим для каждой таблицы имя поля, тип данных, свойства поля. Конструкторы всех таблиц представлены на рисунках 3 – 5.

Рисунок 3 Конструктор таблицы  «Книги»

Рисунок 4 Конструктор таблицы «Заказы»

Рисунок 5 Конструктор таблицы «Клиенты»

     Одно  из полей таблицы назначим ключевым. Значение в этом поле однозначно определяет запись. Это поле должно быть назначено Обязательным и Индексированным (без повторений). Чтобы назначить это поле ключевым, отметим поле и щелкнем на инструменте Ключ. Закроем окно Конструктора таблиц для сохранения структуры таблицы и зададим имя таблице в окне запроса. Ключевым в таблице «Книги» назначим поле Код книги, в таблице «Заказы» - Дата заказа, в таблице «Клиенты» - Наименование клиента.

Введем  данные в таблицы. Для этого выбираем таблицу и нажимаем на кнопку Открыть.

     Таблицы с данными представлены на рисунках 6-8.

     Рисунок 6  Данные таблицы «Книги»

     Рисунок 7  Данные таблицы  «Заказы»

     

     Рисунок 8  Данные таблицы «Клиенты»

     3.2 Связи  между таблицами

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

     Постоянные связи между таблицами были установлены ранее. Для реализации связей таблиц базы данных в СУБД MS Access необходимо нажать в Строке меню кнопку Схема данных. После этого добавляем все ране созданные нами таблицы. Связи между таблицами установим с помощью мыши по методу «зацепить и перетянуть». Зацепим поле Код книги в таблице «Книги» и протащим к такому же полю в таблице «Заказы». Чтобы  обеспечить целостности данных в окне диалога ставим флажок напротив Обеспечение целостности данных. После этого на схеме появляется линия, соединяющая соответствующие поля таблиц. Аналогично установим связь  таблиц «Заказы» и «Клиенты» по полю Наименование клиента.

Рисунок 9 Окно схемы данных

     3.3 Основные  запросы

     Запрос  – процесс обращения пользователя к базе данных с целью ввода, получения  или изменения информации в базе данных. Запрос позволяет создать  набор записей из данных, находящихся  в одной или нескольких таблицах, и использовать его как источник данных для формы или отчета. Запрос может быть выполнен двумя способами: по образцу QBE и при использовании алгоритмического языка SQL. Запросы можно использовать для выполнения следующих операций: вставка новых записей, удаление записей, изменение значений, создание новых полей. Также с помощью запросов можно решать некоторые задачи, связанные с проведением вычислений над данными, хранящимися в Access-таблицах.

     Выполним  следующие запросы:

• Список всех книг с фамилиями авторов, сгруппированный по областям знаний;
• Проданные книги, сгруппированные по покупателям;
• Книги, проданные конкретному покупателю;
• Список покупателей, сгруппированный по городам;
• Средний ежемесячный объем заказов;
• Средний ежемесячный объем заказов по каждому покупателю;
• Ежемесячный объем продаж книг каждого наименования;
• Бестселлер прошлого года.

     3.3.1 Список всех книг с фамилиями авторов, сгруппированный по областям знаний

     Создадим  запрос «Список всех книг с фамилиями авторов, сгруппированный по областям знаний». Для этого нужно перейти на вкладку Запросы, и выбрать Создание запроса в режиме конструктора. В окне Добавление таблицы на вкладке Таблицы выбираем таблицу «Книги», нажимаем кнопку Добавить. Закроем окно Добавление таблицы. Теперь выберем те поля таблицы, которые необходимо включить в запрос. Выберем поля: Название книги, Автор книги, Область знаний. Для того чтобы поместить эти поля в бланк запроса, нужно дважды нажать кнопкой мыши на имени поля в таблице либо перетянуть название поля из таблицы в бланк запроса, либо выбрать необходимые поля в списке названий полей в бланке запроса.

     Для группировки списка по области знаний необходимо в бланке запроса в  поле сортировка для поля Область знаний выбрать сортировку по возрастанию. Для запуска запроса нажимаем пиктограмму  Запуск на панели Конструктор запросов.

     Конструктор запроса «Список всех книг с фамилиями авторов, сгруппированный по областям знаний» представлен на рисунке 10.

Рисунок 10 Конструктор запроса  «Список всех книг с фамилиями авторов, сгруппированный по областям знаний»

       Результат выполнения запроса «Список всех книг с фамилиями авторов, сгруппированный по областям знаний» представлен на рисунке 11. 
 
 

Рисунок 11 Результат выполнения запроса «Список всех книг с фамилиями авторов, сгруппированный по областям знаний»