metoda_2013

ПРАКТИЧЕСКАЯ ЧАСТЬ

Обоснование необходимость разработки базы данных в заданной проблемной области.

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

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

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

Выделяемые группы пользователей:

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

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

«Операторы» – группа имеет ограниченные права: допускается вставка, корректировка и удаление (либо маркировка на

470

ПРАКТИЧЕСКАЯ ЧАСТЬ

удаление) данных о продажах топлива (с изменением текущего количества топлива на станции), также просмотр информации о ценах.

ER-диаграмма.

В базе данных «Заправочная станция» выделим следующие сущности:

[Вид топлива], [Поставщик], [Поставка], [Продажа], [Операторы]

На базе этих сущностей составим ER-диаграмму базы данных:

Описание состава и содержания таблиц базы.

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

Fuel (Fuel_id, Fuel, Quantity_available, Current_price) Suppliers(Supplier_id, Supplier, Country, City, Address, Phone,Bank_properties)

Delivery (Delivery_id, Supplier_id, Fuel_id, Quantity_delivered, Supplier_price)

Employees (Employee_id, LastName, FirstName, MiddleName, BirthDate, INN)

471

ПРАКТИЧЕСКАЯ ЧАСТЬ

Sale (Sale_id, Fuel_id, Employee_id, Quantity_sold, Sale_price, Sale_date)

В каждой таблице присутствуют первичные ключи в виде автоинкрементных полей, позволяющих избежать дублирования текстовой информации и упростить процедуры транзакции. Таблицы 1, 2 и 4 предоставляют общую информацию о видах топлива, поставщиках и работниках «Заправочной станции». Таблицы 3 и 5 предоставляют сводную информацию о поставках (связывая данные о видах топлива и поставщиках) и продажах (связывая данные о проданных литрах топлива и продавцах, обслуживавших клиентов).

Таблицы 1 и 2 имеют связь один-ко-многим с таблицей 3. Таблицы 1 и 4 имеют связь один-ко-многим с таблицей 5.

Нормализация.

Данная организация БД отвечает требованиям третей нормальной формы, так как:

поля таблицы содержат неделимую информацию (требование I

НФ)

отсутствуют повторяющиеся группы полей (требование I НФ) любое неключевое поле однозначно определяется первичным ключом таблицы (требование II НФ)

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

(требование III НФ)

Пример заполнения таблиц.

Реализуем структуру БД в среде Delphi через DatabaseDesktop fuel.db

suppliers.db

472

ПРАКТИЧЕСКАЯ ЧАСТЬ

delivery.db

employees.db

sale.db

и приведем пример заполнения таблиц

(данные о поставщиках с сайта http://www.riccom.ru/sale_market_r_np_11.htm,

данные о ценах с сайта http://www.au92.ru/msg/20040617_uypl90x.html):

473

ПРАКТИЧЕСКАЯ ЧАСТЬ

Права и полномочия пользователей.

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

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

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

474

ПРАКТИЧЕСКАЯ ЧАСТЬ

«Операторы» – группа имеет ограниченные права: допускается вставка, корректировка и удаление (либо маркировка на удаление) данных о продажах топлива (с изменением текущего количества топлива на станции), также просмотр информации о ценах. Просмотр и редактирование данных о поставщиках и поставках запрещено.

Поддержка целостности данных.

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

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

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

Пример № 2.

Задание

Имеется следующая проблемная область: столовая.

Требуется:

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

2.Разработать ER-диаграмму.

3.Описать состав и содержание таблиц базы (не менее 5 таблиц).

475

ПРАКТИЧЕСКАЯ ЧАСТЬ

4.Указать первичные ключи и связи таблиц.

5.Обосновать, что таблицы находятся в третьей нормальной форме. При необходимости провести нормализацию.

6.Дать пример заполнения таблиц (не менее 5 записей в таблице).

7.Описать, какие пользователи и к каким таблицам должны

8. Как предполагается поддерживать целостность данных? Дать полные рекомендации с указанием Ваших таблиц.

9. Составить и проверить в FoxPro или SQL Explorer по 3 примера на каждый из следующих видов запросов SQL:

1)к одной таблице;

2)к нескольким с внутренними соединениями;

3)к нескольким с внешними соединениями;

4)сгруппированные запросы;

5)запросы с подзапросами;

6)запросы на включение, удаление, обновление групп записей по заданным условиям;

7)группы связанных между собой запросов, объединенных в транзакции.

10. Разработать подробное задание на программное обеспечение для работы с Вашей базой данных.

Цель создания и требования к БД. Категории пользователей

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

Категории пользователей:

Guest – гость, случайный посетитель; User – пользователь, постоянный клиент;

Worker – работник столовой (повар, буфетчица и т.п.); Manager – руководитель (зав. производством, технолог); Director – директор столовой;

Admin – администратор базы данных.

476

ПРАКТИЧЕСКАЯ ЧАСТЬ

ER-диаграмма

Все отношения находятся в III нормальной форме, так как они находятся во II нормальной форме и в них нет транзитивных зависимостей.

477

Продукты

Рецепты

478

ПРАКТИЧЕСКАЯ ЧАСТЬ

Поставки

479