Вторая стадия сводится к разработке графического представления полученной информации в виде схемы, которая включает, в частности, исходные данные с формирующими их процессами и результирующие со ссылкой на использующие процессы. На этом же этапе уточняется степень важности данных, выявляются и фиксируются связи между ними. К данной работе, наряду с проектировщиком, полезно привлекать администратора баз данных и представителей пользователя.
Роль логическое проектирования – отображение КМ в выбранную модель данных. На этом этапе необходимо определить отношения и атрибуты, выделить ключи. На ряд атрибутов могут быть наложены ограничения, которые выражаются в функциональных зависимостях между ними. Если выбрана реляционная модель данных, в процессе проектирования следует так определять отношения, чтобы атрибуты в каждом из них функционально полно зависели от ключей и не было транзитивной зависимости атрибутов в отношении. В результате должна сформироваться логическая схема БД, находящаяся в 3 нормальной форме. Эта схема, разумеется, не окончательная, в процессе проектирования она может неоднократно корректироваться, в результате чего нормализованность может нарушиться. В этом случае добавляется специальный этап нормализации схемы. Основное назначение этапа нормализации – получение схемы, эквивалентной данной, но не обладающей некоторыми отрицательными свойствами, связанными с функциональными зависимостями.
Семантическая мощность БД возрастает с увеличением числа дополнительных характеристик, таких, как контроль полномочий, контроль достоверности исходных данных, контроль ограничения целостности. При обсуждении реляционной модели говорилось, что в полной мере такими свойствами обладают лишь полностью реляционные СУБД.
Контроль полномочий (разграничение прав доступа) служит защитой от несанкционированного доступа к данным. Для него обычно используется система паролей.
Процедуры контроля исходных данных по заданным ограничениям могут быть как внешними по отношению к базам данных, так и встроенными, если СУБД допускает возможность хранимых процедур.
Ограничения целостности служат для защиты данных от некорректных изменений. Различают статические ограничения, отражающие множество корректных состояний БД, и динамические, определяющие правильные переходы из состояния в состояние. Соответственно, ограничения целостности обеспечиваются вызовом при модификации данных программ статического или динамического арбитража.
Создание 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. Списки воспитанников.
3. Списки сотрудников.
4. Перечень существующих кружков и проводимых мероприятий.
Выходными данными являются:
1. Отчеты, сформированные по запросам;
2. Простые запросы: по кружкам, воспитанникам, сотрудникам, мероприятиям.
3. Перекрестные запросы.
Для сотрудников по должностям, для воспитанников по гражданству, для мероприятий по дате.
Требования пользователя заключаются в легкости исправления и внесения изменений в настоящую базу данных.
Концептуальная модель представлена в Приложении Б.
Логическое проектирование.
Сущность – это объект, о котором в системе будет накапливаться информация. Сущности бывают как физически существующие так и абстрактные. Для сущностей различают тип сущности и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр – конкретными значениями свойств.
Выделим базовые сущности этой предметной области:
· Сотрудники. Атрибуты сотрудников – Фамилия, Имя, Отчество, Должность, Название отдела, Табельный номер, Номер паспорта, Адрес, Город, Дата рождения. Для сотрудников необходимо хранить сведения о заказах, которые они ведут.
· Кружки. Атрибуты кружков – наименование кружка, наименования отдела, Имя и Фамилия педагога. Для Кружков необходимо ранить сведения об отделах, за которыми закреплены кружки.
· Воспитанники. Атрибуты воспитанников – Фамилия, Имя, Дата рождения, кола, Класс, родной язык, Гражданство, Домашний адрес и наименование кружка.
· Мероприятия. Атрибуты мероприятия – Наименование мероприятия, дата проведения, наименование кружка.
Требования к сущностям:
Сущность Сотрудники – должна содержать полную информацию о каждом работающем сотруднике в организации.
Сущность Кружки - должна содержать информацию о том, как называется кружок, кто ведет кружок (ФИ педагога) и отдел, к которому относится кружок.
Сущность Воспитанники – должна содержать полную информацию об учащихся, записанных в кружках, и указывается наименование кружка, в котором занимается ребенок.
Связь один-ко-многим. Такая связь подразумевает, что каждому объекту одного набора соответствуют ноль или более объектов второго набора, и каждому объекту второго типа соответствует не более одного объекта первого типа.
Необходимо так же определить первичный ключ. Если таблица никогда не будет использоваться в качестве главной, то ключ для нее определять не нужно. В главных таблицах обычно содержится информация о реальных объектах, причем с каждым объектом ассоциируется только одна запись. Определение ключа таблицы является простейшим способом предотвращения появления в таблице одинаковых записей. В главной таблице связи должен быть определен первичный ключ. Access считает таблицы, у которых такой ключ не определен, подозрительными. При открытии таких таблиц в режиме конструктора появляется диалоговое окно, сообщающее о том, что ключ таблицы не определен. Ключ можно определить и в связанных таблицах, что поможет избежать появления повторяющихся данных. Ключ таблицы можно задать по значению нескольких полей. Access автоматически индексирует таблицу по значению ключа.