Проектирование и создание базы данных для строительной фирмы

При проектировании БД строительной фирмы фильмов после описания предметной области необходимо выбрать метод построения инфологической модели (ER-модели) и СУБД, в которой будет реализован проект.

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

Microsoft Office Access -- реляционная система управления базами данных корпорации Microsoft. Входит в состав пакета Microsoft Office. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Система имеет удобный интерфейс управления базой данных путем создания форм и отчетов, путем которых пользователь, не имеющий навыков проектирования БД может просматривать и редактировать записи таблиц, а также получать заранее оформленные отчеты на основании хранимых в БД данных.

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

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

1.3 Построение модели сущность-связь

ER-модель (от англ. entity-relationship model, модель «сущность -- связь») -- модель данных, позволяющая описывать концептуальные схемы предметной области. ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.

На рисунке 1 ниже изображена ER-модель базы данных строительной фирмы.

Рисунок 1 - ER-модель

2. Проектирование даталогической модели базы данных

2.1 Проектирование логической структуры базы данных

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

Таблица 1 - описание таблиц базы данных

Схема базы данных строительной фирмы в среде MS ACCESS будет выглядеть следующим образом (рис. 2):

Рисунок 2 - Схема данных базы данных видеопроката

2.2 Выявление полного перечня ограничений целостности

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

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

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

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

· при добавлении записей в таблицу проверяется уникальность их первичных ключей

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

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

Ограничения, контролируемые в таблицах

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

Ограничения, контролируемые формами

В формах, предусмотренных для поиска или просмотра данных, таких как «Поиск клиента» установлено ограничение «Только чтение».

2.3 Проектирование физической структуры базы

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

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

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

На рисунках ниже (рис. 3 - 10) представлены разработанные таблицы.

Рисунок 3 - Таблица «Бригады»

Рисунок 4 - Таблица «Заказы»

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

Рисунок 6 - Таблица «Материалы в наличии»

Рисунок 7 - Таблица «Поставки»

Рисунок 8 - Таблица «Поставщики»

Рисунок 9 - Таблица «Сотрудники»

Рисунок 10 - Таблица «Услуги»

3. Реализация проекта в среде конкретной СУБД.

3.1 Организация ввода данных в БД

В Access можно вводить данные непосредственно в таблицу в режиме таблица. Но обычно для ввода данных в БД Access используют формы (forms). Form ускоряет работу с базой данных. Form в БД - это структурированное интерактивное окно с элементами управления, в котором отображаются поля одной или нескольких таблиц, или запросов.

Форму можно использовать для ввода, изменения или отображения данных из таблицы или запроса. В Microsoft Office Access предусмотрены средства, помогающие быстро создавать формы. Формы в БД Access можно создавать с помощью различных средств:

· инструмента Form;

· инструмента Разделенная form;

· инструмента Несколько элементов;

· инструмента Пустая form;

· Мастера form;

· Конструктора form.

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

Формы ввода имеют следующий вид (рис. 11 - 14):

Рисунок 11 - Форма «Добавление заказа»

Рисунок 12 - Форма «Добавление клиента»

Рисунок 13 - Форма «Новый материал»

Рисунок 14 - Форма «Обновление материалов»

3.2 Реализация запросов, получение отчетов

Реализация запросов

· быстрый поиск определенных данных путем фильтрации с применением определенных критериев (условий);

· вычисление или сведение данных;

· автоматизированное управление данными, например, регулярный просмотр актуальных данных.

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

Запрос «Запрос по заказам» (рис. 15) объединяет значения нескольких таблиц для последующего использования.

Рисунок 15 - Запрос «Запрос по заказам»

Запрос с параметром «Запрос для отчета по заказам» (рис.16) вызывается при формировании отчёта по заказам с указанием промежутка дат.

Рисунок 16 - Запрос «Запрос для отчета по заказам»

Запрос «Затраты на услугу» (рис.17) подсчитывает итоговую стоимость услуги, складывая цену и затраты.

Рисунок 17 - Запрос «Затраты на услугу»

Запрос «Запрос по поставкам» (рис. 18) нужен для формирования отчёта по поставкам, объединяет данные таблиц и определяет сумму заказа материалов.

Рисунок 18 - Запрос «Запрос по поставкам»

Запрос с конкретным параметром «Запрос Поиск клиента» выполняет поиск клиента по заданным ФИО или номеру телефона.

Рисунок 19 - Запрос в режиме конструктора

Рисунок 20 - Ввод параметра

Рисунок 21 - Экранная форма запроса

Остальные запросы реализуются аналогичным образом.

Получение отчетов

· отображение или распространение сводки данных;

· архивирование моментальных снимков данных;

· предоставление сведений об отдельных записях;

· создание надписей.

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

строительный проектирование база