Методические указания для студентов специальности 2205, 0755 «Проектирование и технология эвс», «Комплексная информационная безопасность автоматизированных систем» (стр. 20 из 21)
ПРИМЕР ОСНОВНОЙ ЧАСТИ
ВВЕДЕНИЕ
Во ведении пишется общая часть по проекту.
2. ПРОЕКТИРОВАНИЕ ИНФОЛОГИЧЕСКОЙ МОДЕЛИ ДАННЫХ
Структуризация предметной области
Пункт проката дисков имеет фонд лазерных дисков и получает прибыль от проката и продажи отдельных экземпляров
Клиентами фирмы могут быть как физические, так и юридические лица. Клиент может приобрести диск, но при том его стоимость превышает рыночную цену. Прокат диска осуществляется следующим образом: клиент оставляет залог, размер которого равен целому числу m, умноженному на стоимость суточного проката. Все клиенты, желающие взять диск напрокат, проходят процедуру регистрации, указывая в качестве обязательных данных фамилию и имя; остальные поля служат для анализа интересов клиентуры фирмы.
Необходима также регистрация факта выдачи каждого диска, т.е. создание учетной записи с указанием фамилии клиента, названия диска и даты выдачи. По истечении m дней диск считается проданным и учетная запись удаляется.
При возврате диск проверяется на дефектность, соответствующий факт фиксируется.
По желанию оператора составляется отчет с указанием размера выручки, количества списанных дисков, названий дисков, пользующихся наибольшим спросом, а также дисков, отсутствующих в каталоге, но заказанных клиентами, и другой информацией.
В случае, если клиент заказывает диск, количество экземпляров которого указано равным нулю, клиент может оформить требование и тогда по возвращении взятого на руки экземпляра он должен быть выдан клиенту, оформившему требование в порядке очереди.
В настоящей работе реальная предметная область ограничена автоматизацией обслуживания клиентов и не рассматривает вопросы обновления фонда.
Основные компоненты бизнеса:
* клиенты;
* каталог дисков;
* оператор;
* учетные записи;
* требования.
Основные бизнес-процессы:
* выдача экземпляров дисков;
* возвращение дисков в каталог;
* проверка диска на дефектность;
* оформление требований;
* уведомление о необходимости выдачи возвращенного диска оформителю требования;
* преобразование требование -® учетная запись.
База данных должна поддерживать накопление и хранение информации об основных компонентах бизнеса и автоматизированное выполнение бизнес-процессов.
Формализованное описание задачи
Бизнес-правила:
* устаревшие учетные записи удаляются
* максимальный срок проката – размер залога, деленный на стоимость суточного проката;
* оформить заказ на прокат может только зарегистрированный клиент;
* заказать диск, отсутствующий в каталоге, может любой клиент;
* при удалении учетной записи происходит проверка на наличие требований на этот диск;
* при обновлении каталога данные о списанных дисках уничтожаются.
Перечень вводимой информации:
* фамилия, имя и отчество клиента;
* электронный адрес клиента;
* род занятий;
* возраст;
* категория диска;
* жанр;
* название диска;
* количество экземпляров диска;
* дата выдачи копии в прокат;
* обусловленная дата возврата копии;
* признак дефектности диска;
* названия новых дисков;
* данные для вывода в отчет;
* цена дня проката копии;
* размер залога.
Сведения об имеющихся в фонде дисках могут быть доступны клиентам фирмы.
ПРОЕКТИРОВАНИЕ ЛОГИЧЕСКОЙ МОДЕЛИ ДАННЫХ
Концептуальная модель данных построена с использованием методологии информационного моделирования IDEF1X (Integrated DEFinitions 1 eXpanded), имеющей в настоящее время статус федерального стандарта США. В IDEF1X различают три уровня графического представления информации.
Уровень «сущность - связь» (Entity-Relationship, ER level). Это уровень наименее детального представления информации. Сущности и связи представлены только именами.
Уровень ключей (Key-Based, KB level). На этом уровне в диаграммах отражаются имена первичных и внешних ключей сущностей и связей. Диаграмма KB–уровня объявляет уникальные идентификаторы экземпляров сущностей и ограничения ссылочной целостности.
Уровень атрибутов (Fully attributed, FA level). Диаграмма FA–уровня показывает имена всех атрибутов сущностей и связей и полностью определяет структуру и взаимосвязи данных. Включает в себя КВ-уровень.
3.1. Сущности и связи (ER - уровень)
3.2. Проектирование реляционной модели данных на основе принципов нормализации
Цель нормализации – преобразовать универсальное отношение, представленное выше диаграммой «сущность-связь», в систему отношений, удовлетворяющих определенным формальным отношениям. При обновлении данных, хранящихся в такой системе отношений, не возникают аномальные ситуации, и РСУБД в состоянии поддерживать целостность данных.
Первая нормальная форма (1НФ). Говорят, что отношение находится в первой нормальной форме, если и только если все домены его атрибутов содержат скалярные значения.
Любое отношение реляционной модели данных (РМД) находится в 1НФ по определению.
Вторая нормальная форма (1НФ). Говорят, что отношение находится во второй нормальной форме, если и только если каждый его неключевой атрибут неприводимо зависит от первичного ключа.
Для приведения отношения ко второй нормальной форме необходимо выделить в отдельные отношения группы атрибутов, зависящих от части возможного ключа отношения 1НФ.
При несоблюдении этого условия отношения ТРЕБОВАНИЯ и УЧЕТНАЯ ЗАПИСЬ были бы объединены.
Третья нормальная форма (3НФ). Говорят, что отношение находится в третьей нормальной форме, если и только если оно находится в 2НФ и нет транзитивных зависимостей, то есть все неключевые атрибуты взаимно независимы.
В данном случае этому условию не удовлетворяет отношение КАТАЛОГ, так как записи содержат названия дисков, зависящие от атрибутов категория и жанр.
Но при разбиении отношения на два отношения категория - жанр и жанр – название усложнилась бы работа с БД в прикладной программе.
3.3. Состав атрибутов сущностей (FA-уровень)
3.4. Глоссарий
Таблица 1. Сопоставление физических и логических имен модели
| Физическое имя | Логическое имя | Тип поля | Описание |
| Client_id | Номер клиента | autoincrement | Уникальный идентификатор клиента |
| Surname | Фамилия | Char(15) | Фамилия клиента |
| Name | Имя | Char(10) | Имя клиента |
| Patronymic | Отчество | Char(15) | Отчество. Необязательное поле |
| Age | Возраст | Numeric | Возраст. Необязательное поле |
| Job | Род занятий | Char(25) | Род занятий. Необязательное поле |
| | Электронный адрес | Char(20) | Электронный адрес клиента. Необязательное поле. |
| Disk_id | Номер диска | autoincrement | Уникальный идентификатор диска. Владелец – КАТАЛОГ |
| Description | Описание | Char(15) | Ссылка на htm-файл с описанием диска. Владелец – КАТАЛОГ |
| Category | Категория | Char(30) | Категория. Используется для поиска нужного диска |
| Genre | Жанр | Char(30) | Жанр. Используется для поиска нужного диска |
| Caption | Название | Char(50) | Название диска. Владелец – КАТАЛОГ |
| Quantity | Количество | numeric | Количество экземпляров диска в КАТАЛОГе |
| Write off | Списано | numeric | Количество списанных дисков |
| Date | Дата | Date | Дата создания учетной записи, либо фактическая дата возврата диска, используемая для вычисления сдачи |
| ReturnDate | Дата возврата | Date | Формально указываемая дата возврата диска |
| Record_id | Номер уч. Записи | autoincrement | Уникальный идентификатор учетной записи |
| Req_id | Номер требуемого диска | autoincrement | Уникальный идентификатор записи об интересующем клиента диске |
| ReqDisk | Название требуемого диска | Char(30) | Название требуемого диска |
| Summa | сумма | Long Integer | Сумма, полученная после каждой операции продажи или проката диска |
4. ОБОСНОВАНИЕ ВЫБОРА ПРОГРАММНЫХ СРЕДСТВ