Курсовая работа: АИС для ГОУДОД Центра развития творчества детства и юношества
Инфологическая модель ПО представляет собой описание структуры и динамики ПО, характера информационных потребностей пользователей в терминах, понятных пользователю и не зависимых от реализации БД. Это описание выражается в терминах не отдельных объектов ПО и связей между ними, а их типов, связанных с ними ограничений целостности и тех процессов, которые приводят к переходу предметной области из одного состояния в другое.
1.3 Концептуальное проектирование
На этапе концептуального проектирования определяются информационные потребности и локальные представления предметной области. Выявляется роль, назначение, взаимосвязь данных, проводится их глобальная спецификация. Результат этапа – описание объектов данных и их взаимосвязи без указания способа их физической организации. Структура данных представляется концептуальной схемой, содержащей набор сущностей, связей и атрибутов. Различаются две важных стадии концептуального проектирования: анализ данных и организация их хранения.
Содержание первой стадии – сбор полной и точной информации о данных предметной области. Заметим, что речь идет о первоначальном сборе информации, в процессе проектирования, как правило, выясняются дополнительные обстоятельства. Нередко для проведения данной работы прибегают к одному из двух методов (или к обоим): анкетированию и работе с экспертами. В первом случае пользователю предлагается анкета, в которой он должен дать свое представление о данных. Во втором случае среди пользователей выбирается группа экспертов, которые все и излагают. Оба этих метода страдают большими недостатками. Анкетирование никогда не гарантирует полноту информации: к этому процессу пользователи относятся как к досадной помехе в основной деятельности, поэтому стараются не дать точные сведения, а поскорее «отбиться». Работа с экспертами несколько лучше, но требует затрат квалифицированного труда. Кроме того, эксперты, будучи специалистами в своей области, не всегда способны достаточно внятно и полно изложить суть проблемы целиком. Тем не менее, не стоит пренебрегать этими методами, но за основу следует взять личное участие разработчиков в исследовании. В частности, следует потребовать набор выходных и входных документов и проследить их движение и модификацию на каждом этапе технологического процесса. Во время такого исследования выявляются недостатки принятого документооборота и делаются попытки, как это предлагает BPR, его оптимизировать с точки зрения машинной обработки.
Вторая стадия сводится к разработке графического представления полученной информации в виде схемы, которая включает, в частности, исходные данные с формирующими их процессами и результирующие со ссылкой на использующие процессы. На этом же этапе уточняется степень важности данных, выявляются и фиксируются связи между ними. К данной работе, наряду с проектировщиком, полезно привлекать администратора баз данных и представителей пользователя.
1.4 Логическое проектирование
Роль логическое проектирования – отображение КМ в выбранную модель данных. На этом этапе необходимо определить отношения и атрибуты, выделить ключи. На ряд атрибутов могут быть наложены ограничения, которые выражаются в функциональных зависимостях между ними. Если выбрана реляционная модель данных, в процессе проектирования следует так определять отношения, чтобы атрибуты в каждом из них функционально полно зависели от ключей и не было транзитивной зависимости атрибутов в отношении. В результате должна сформироваться логическая схема БД, находящаяся в 3 нормальной форме. Эта схема, разумеется, не окончательная, в процессе проектирования она может неоднократно корректироваться, в результате чего нормализованность может нарушиться. В этом случае добавляется специальный этап нормализации схемы. Основное назначение этапа нормализации – получение схемы, эквивалентной данной, но не обладающей некоторыми отрицательными свойствами, связанными с функциональными зависимостями.
Семантическая мощность БД возрастает с увеличением числа дополнительных характеристик, таких, как контроль полномочий, контроль достоверности исходных данных, контроль ограничения целостности. При обсуждении реляционной модели говорилось, что в полной мере такими свойствами обладают лишь полностью реляционные СУБД.
Контроль полномочий (разграничение прав доступа) служит защитой от несанкционированного доступа к данным. Для него обычно используется система паролей.
Процедуры контроля исходных данных по заданным ограничениям могут быть как внешними по отношению к базам данных, так и встроенными, если СУБД допускает возможность хранимых процедур.
Ограничения целостности служат для защиты данных от некорректных изменений. Различают статические ограничения, отражающие множество корректных состояний БД, и динамические, определяющие правильные переходы из состояния в состояние. Соответственно, ограничения целостности обеспечиваются вызовом при модификации данных программ статического или динамического арбитража.
1.5 Средства создания модели
Создание ER-модели обычно сопровождается ее графическим представлением. Различные нотации ER-диаграмм поддерживается специальными средствами проектирования программных систем (CASE-средствами). В некоторых случаях подобные средства включаются в инструментальную среду создания баз данных (FoxPro, Access, Oracle и т.п.), иногда они существуют как отдельный продукт. Последний вариант интересен тем, что нет привязки к конкретной СУБД, то есть можно определять концептуальную модель, которая может быть отображена в логическую после того, как будет выбрана СУБД. Рассмотрим один из наиболее популярных средств такого рода – ERWin.
CASE-средство ERWin уже достаточно долго присутствует на рынке инструментальных средств, ориентированных на базы данных. Существует несколько версий этого продукта. ERWin позволяет создавать модели двух уровней: концептуального и логического. Правда называются они довольно своеобразно: концептуальный называется логическим, а логический – физическим. Представление диаграмм соответствует стандарту IDEF1X. Основные элементы модели следующие: сущности, атрибуты сущностей, домены, связи (четыре вида), индексы. Современные версии ERWin не допускают атрибуты связей. Среди атрибутов выделяются первичные ключи. Кроме первичных, можно отметить возможные (альтернативные) ключи, а также ключи поиска. Внешние ключи формируются автоматически при определении связей, причем, в качестве родительского ключа выбирается первичный.
Сильная сторона ERWin заключается в относительной простоте и удобстве работы с продуктом, что немаловажно в случае сжатых сроков разработки (а это случается постоянно). Разумеется, поддерживаются различные уровни документирования модели: описания сущностей, атрибутов, связей, диаграммы, модели в целом и т.п. Есть возможность получить пакет документации о модели с использованием внутреннего генератора отчетов.
После выбора СУБД появляется возможность привязки к типам данных, принятых в этой СУБД. В терминах ERWin, эта работа производится в физической модели. Можно уточнить типы данных, индексы, а также задать хранимые процедуры, обеспечивающие корректность базы данных. Заметим, что в этой модели несколько меняется терминология: сущности называются таблицами, а атрибуты – столбцами. И, наконец, завершающая работа – автоматическая генерация пустой базы данных по разработанной модели. Базу данных следует проверить, особенно индексы, заполнить тестовыми данными и протестировать. Обычно для создания работоспособной базы данных требуется несколько итераций, в ходе которых изменять следует исключительно модель, а не созданную базу данных.
2. Практическая часть
2. 1 Специальная часть
база данные проектирование инфологический
2.1.1 Этапы выполнения курсовой работы
Концептуальное проектирование.
Программами, реализуемыми в ГОУ ДОД «ЦРТДиЮ им. В.М. Комарова», обеспечивающими целостность образовательно-воспитательного процесса, являются программы дополнительного образования детей, утвержденные Министерством просвещения.
В условиях современного развития системы дополнительного образования детей ГОУ ДОД «ЦРТДиЮ им. В.М. Комарова» стремиться реализовать идею общего интеллектуального развития личности ребенка путем введения развивающих и интегрированных курсов, профильного обучения, повышения мастерства воспитанников.
Одним из основных показателей качества образовательного процесса в ГОУ ДОД «ЦРТДиЮ им. В.М. Комарова» является характеристика его содержания, которая зависит от гармоничного единства теории и практики, классического и современного знания, воспитания и развития. В соответствии с требованиями нормативных документов, ГОУ ДОД «ЦРТДиЮ им. В.М. Комарова» имеет свою образовательную программу, которая является ориентирующей моделью совместной деятельности педагога и ребенка.
Задачи, подлежащие автоматизации:
1. Учет кружков;
2. Учет сотрудников;
3. Учет воспитанников;
4. Учет мероприятий.
Для настоящего курсового проекта входными данными послужили:
1. Структурная схема ГОУДОД ЦРТДиЮ.
2. Списки воспитанников.