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

курсовая работа

книги, отредактированные определенным редактором;

авторы и их гонорары, в порядке убывания размеров гонораров;

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

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

прогноз затрат издательства;

построение линейного тренда затрат.

1. Проектирование базы данных

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

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

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

Выделим основные этапы, на основании которых перейдем от предметной области к реализации БД средствами СУБД Access:

1. анализ предметной области;

2. информационно- логическое проектирование на основе сущность - связь;

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

4. БД и приложения, реализованные на конкретной программно-аппаратной основе.

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

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

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

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

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

Экземпляр сущности - однозначно идентифицируемый объект, который относится к сущности определенного типа. Каждый однозначно идентифицируемый объект типа сущности, который относится к сущности определенного типа, называется просто экземпляром сущности (entity occurrence).

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

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

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

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

Автор

Имя

Фамилия

Контракт

Книга

Дата подписания

Дата окончания

Дата оплаты

Сумма

Авторы

Книга

Название

Рубрика

Автор

Редактор

Опубликована

Редактор

Имя

Фамилия

Рисунок 1 - Сущности и атрибуты сущностей.

Определим связи между заданными сущностями и классы принадлежности:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создадим все таблицы в режиме конструктора: нажимаем на кнопке Создание таблицы в режиме конструктор. В появившемся окне конструктора таблиц определим для каждой таблицы имя поля, тип данных, свойства поля. Конструкторы всех таблиц представлены на рисунках 2 - 5.

Рисунок 2 - Конструктор таблицы «Автор»

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

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

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

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

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

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

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

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

база данные таблица индекс

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

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

Рисунок 7 - Данные таблицы «Автор»

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

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

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

3. Создание запросов

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

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

список всех напечатанных книг с фамилиями и именами авторов, сгруппированный по области знаний и отсортированный по дате завершения контракта;

список книг с фамилиями авторов, работа над которыми идет в настоящее время;

Делись добром ;)