Проектирование и разработка информационной системы «Учет персонала в театре» на базе Microsoft Access: Комплексное руководство для курсовой работы

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

Именно поэтому автоматизация кадрового учета через создание специализированной информационной системы (ИС) является не просто желательной, а жизненно важной для повышения эффективности и упрощения деятельности отдела кадров театра. Такой подход позволяет не только минимизировать рутинные операции, но и трансформировать управление персоналом в стратегический ресурс, способствуя более гибкому и оперативному реагированию на вызовы театрального бизнеса. Какой важный нюанс здесь упускается? Качественная ИС также способствует повышению прозрачности и справедливости в управлении персоналом, что укрепляет моральный дух коллектива.

Целью данной курсовой работы является разработка проекта информационной системы «Учет персонала в театре» на базе Microsoft Access. В рамках этой цели будут решены следующие основные задачи:

1. Теоретическое обоснование: Изучение фундаментальных понятий, принципов и методологий проектирования ИС и баз данных.
2. Анализ предметной области: Детальное исследование специфики учета персонала в театральном учреждении и формирование исчерпывающего перечня функциональных и нефункциональных требований к системе.
3. Концептуальное и логическое проектирование БД: Разработка ER-модели и реляционной структуры базы данных с применением принципов нормализации.
4. Физическая реализация ИС: Создание таблиц, форм, запросов и отчетов в среде Microsoft Access, а также описание алгоритмов обработки данных.
5. Обеспечение информационной безопасности: Разработка мер по защите данных с учетом специфики СУБД Access и угроз ИБ.
6. Документирование: Оформление курсовой работы в соответствии с академическими и техническими стандартами, включая руководство пользователя.

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

Теоретические основы проектирования информационных систем и баз данных

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

Основные понятия и определения

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

Информационная система (ИС) – это не просто набор компьютеров, а сложная, взаимосвязанная совокупность средств, методов и персонала, которые работают вместе для сбора, хранения, обработки и выдачи информации. Её главная цель – помочь достичь поставленных целей организации, обеспечивая своевременное и точное принятие решений. ИС объединяет в себе информационные технологии, направленные на поддержку всего жизненного цикла данных, от их создания до архивирования, включая управление данными и знаниями. По своей сути, это организационно упорядоченная совокупность документов (или массивов документов) и информационных технологий, использующих средства вычислительной техники и связи для реализации информационных процессов.

База данных (БД) – это сердце любой информационной системы. Она представляет собой структурированную совокупность сведений об объектах определённой предметной области. Представьте её как упорядоченную библиотеку, где каждая книга – это запись, а полки – таблицы. Главные характеристики БД: она является взаимосвязанной, хранится вместе (во внешней памяти), организована специальным образом и отражает состояние объектов и их отношений в рассматриваемой предметной области. Ключевая особенность – минимальная избыточность данных при их оптимальном использовании.

Система управления базами данных (СУБД) – это программное обеспечение, которое выступает в роли библиотекаря для нашей БД. Это совокупность языковых и программных средств, позволяющих создавать, поддерживать и совместно использовать БД многими пользователями. СУБД управляет структурой БД, контролирует доступ к данным и предоставляет пользователю удобный интерфейс для работы с информацией, абстрагируя его от низкоуровневых деталей аппаратного обеспечения. Microsoft Access, MySQL, PostgreSQL, Oracle Database – всё это примеры СУБД.

ER-модель (модель «сущность-связь») – это мощный инструмент для концептуального проектирования БД. Она представляет собой графическую схему, которая визуализирует данные системы и показывает, как они логически связаны друг с другом. Это своего рода «чертеж» будущей базы данных, понятный как техническим специалистам, так и бизнес-пользователям. Основные компоненты ER-модели:

• Сущности: Объекты или события, о которых необходимо хранить информацию (например, «Сотрудник», «Спектакль»).
• Атрибуты: Характеристики или свойства сущностей (например, «Имя сотрудника», «Название спектакля»).
• Связи: Взаимодействия или отношения между сущностями (например, «Сотрудник работает в Отделе»).

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

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

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

Жизненный цикл информационной системы: Модели и этапы

Информационная система, подобно живому организму, проходит через определённые стадии развития: от зарождения идеи до вывода из эксплуатации. Этот путь, известный как жизненный цикл информационной системы (ЖЦ ИС), является краеугольным камнем методологии проектирования и управления проектами в сфере IT. Он представляет собой структурированную последовательность этапов, каждый из которых имеет свои цели, задачи и результаты. Понимание ЖЦ ИС позволяет систематизировать процесс разработки, управлять рисками и обеспечивать качество конечного продукта.

Традиционно ЖЦ ИС начинается с момента осознания необходимости её создания и завершается полным изъятием системы из эксплуатации. Этот период разбивается на основные стадии:

1. Планирование и анализ требований (системный анализ). На этой начальной, но критически важной стадии, происходит глубокое погружение в предметную область. Выявляются существующие проблемы и недостатки в текущих процессах (например, в ручном учете персонала), формулируется потребность в новой или улучшенной ИС. Определяется экономическая целесообразность и обоснованность автоматизации. Здесь важно понять, что система должна делать.
2. Проектирование (техническое и логическое). Этот этап переводит «что» в «как». Разрабатывается общая архитектура системы, определяющая состав автоматизируемых функций (функциональная архитектура) и обеспечивающих подсистем (системная архитектура). Создаётся концептуальная (ER-модель) и логическая структура базы данных, проектируется пользовательский интерфейс, формируются алгоритмы обработки данных. Результатом является технический проект ИС.
3. Реализация (конструирование). На этой стадии происходит непосредственное создание системы: написание программного кода, создание таблиц, форм, запросов и отчетов в выбранной СУБД (в нашем случае – Microsoft Access).
4. Внедрение. После завершения разработки система устанавливается, настраивается и интегрируется в рабочую среду. Проводится обучение пользователей, миграция данных.
5. Эксплуатация и сопровождение (модернизация). Это самая длительная стадия, в течение которой система используется по назначению. Осуществляется техническая поддержка, исправление ошибок, а также внесение изменений и дополнений в соответствии с новыми требованиями или изменением внешних условий.

Важно отметить, что ЖЦ ИС не всегда является линейным процессом. Современные подходы часто предполагают итеративный характер, при котором реализованные этапы могут циклически повторяться. Это отражено в различных моделях жизненного цикла:

• Каскадная (водопадная) модель: Классический, последовательный подход, где каждый этап полностью завершается до начала следующего. Прост в управлении для стабильных и хорошо определённых требований, но негибок к изменениям.
• Спиральная модель: Итерационная модель, включающая прототипирование и анализ рисков на каждой итерации. Подходит для проектов с неопределёнными требованиями, позволяя постепенно уточнять функциональность.
• Инкрементная модель: Разработка делится на ряд инкрементов (шагов), каждый из которых добавляет новую функциональность. Позволяет быстро получить работающую часть системы и постепенно её достраивать.
• V-образная модель (модель разработки через тестирование): Развитие каскадной модели, где каждый этап анализа и проектирования имеет соответствующий этап тестирования. Подчеркивает важность тестирования на всех стадиях.
• Модель быстрой разработки приложений (RAD): Ориентирована на быструю разработку с активным участием заказчика, часто с жестким ограничением по времени (например, 60 дней). Идеальна для проектов, где скорость выхода на рынок критична.

Для курсовой работы по проектированию ИС «Учет персонала в театре» наиболее подходящей является инкрементная модель или модифицированная каскадная модель с элементами прототипирования. Каскадный подход обеспечивает структурированность и последовательность, что важно для академического проекта, где требуется поэтапное описание. Элементы прототипирования позволяют наглядно демонстрировать функциональность и вносить корректировки на ранних стадиях, что полезно для студента, который осваивает новые концепции. Однако, учитывая ограниченные сроки и объем курсовой работы, основное внимание будет уделено последовательному прохождению этапов анализа, проектирования и реализации.

Принципы проектирования информационных систем

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

1. Принцип системности: Этот принцип призывает рассматривать ИС как единое целое, состоящее из взаимосвязанных компонентов. Он предполагает использование процессов анализа (разложение целого на составные части) и синтеза (воссоединение целого из частей). Применительно к нашей системе учета персонала, это означает, что мы не просто создаем отдельные таблицы для сотрудников и спектаклей, но и продумываем, как они будут взаимодействовать, как данные из одного модуля будут влиять на другой, обеспечивая целостную картину управления кадрами.
2. Принцип стандартизации (унификации): Основа этого принципа – использование типовых, унифицированных и стандартизованных элементов, проектных решений и пакетов прикладных программ. Применение стандартов снижает затраты на разработку, упрощает сопровождение и повышает совместимость. В контексте Access это может быть использование стандартных шаблонов форм, следование конвенциям именования объектов или применение общепринятых структур запросов.
3. Принцип развития: ИС должна быть спроектирована с учетом её будущего. Мир меняется, законодательство обновляется, число пользователей растет, появляются новые функции. Система учета персонала в театре должна быть достаточно гибкой, чтобы адаптироваться к этим изменениям без радикальной перестройки. Например, возможность добавления новых типов контрактов, актерских званий или отчетных форм должна быть заложена в архитектуру изначально.
4. Принцип модульности: Этот принцип предполагает разбиение всей системы на независимые, легко управляемые модули. Каждый модуль выполняет свою специфическую функцию. В нашей ИС это могут быть отдельные модули для управления сотрудниками, спектаклями, контрактами, отчетностью. Модульность создает понятную архитектуру, упрощает отладку, тестирование и повышает общую поддерживаемость системы. Например, изменение логики расчета премии в модуле «Контракты» не должно затрагивать функциональность модуля «Сотрудники».
5. Принцип функциональной избирательности: Хотя этот принцип чаще применяется в контексте операционных систем, его можно адаптировать к проектированию ИС. Он заключается в выделении наиболее важных, часто используемых модулей, которые должны быть всегда доступны и работать максимально эффективно. В ИС учета персонала это могут быть функции быстрого поиска сотрудника по ФИО или формирования актуального штатного расписания, которые должны быть оптимизированы для мгновенного доступа, тогда как, например, архивные данные уволенных сотрудников могут храниться с менее строгими требованиями к скорости доступа.
6. Принцип надежности: Система должна выполнять свои функции последовательно и предсказуемо, без сбоев, в течение определённого периода времени. Достижение надежности требует тщательного анализа требований, выявления потенциальных режимов отказа и применения практик надёжного проектирования. Для нашей ИС это означает устойчивость к ошибкам ввода данных, корректное сохранение информации даже при сбоях, а также обеспечение целостности связей между таблицами. Часто уровень надежности нормируется экономически обоснованными вероятностными показателями.

Таким образом, проектирование ИС охватывает три основные области:

• Проектирование объектов данных для базы данных (таблицы, связи, ограничения).
• Проектирование программ, экранных форм и отчетов (пользовательский интерфейс и функциональность).
• Учет конкретной среды или технологии (например, возможности и ограничения Microsoft Access).

Соблюдение этих принципов при проектировании ИС «Учет персонала в театре» позволит создать не только функциональную, но и устойчивую, масштабируемую и легко поддерживаемую систему, что является ключевым требованием для успешной курсовой работы.

Анализ предметной области и формирование требований к ИС «Учет персонала в театре»

Каждая информационная система создается для решения конкретных задач в определённой предметной области. ИС «Учет персонала в театре» не исключение. Театр — это уникальный организм, где сливаются творчество и строгий административный порядок. Понимание этой специфики, а также формирование четких и измеримых требований к системе, является первым и наи��олее важным шагом в её успешном проектировании. Этот раздел посвящен глубокому анализу того, что именно потребуется от нашей системы.

Особенности учета персонала в театральном учреждении

Театр — это не просто организация, это сложный творческий и производственный механизм, где каждый сотрудник, от актера до осветителя, играет свою уникальную роль. Именно поэтому учет персонала в театральном учреждении имеет ряд специфических особенностей, которые необходимо учитывать при проектировании информационной системы:

1. Актерские звания и категории: В отличие от стандартных предприятий, где сотрудники имеют должности, актеры обладают ещё и званиями (например, «Заслуженный артист», «Народный артист») и могут относиться к различным категориям, что влияет на их статус, оплату и участие в постановках. ИС должна предусматривать учет этих званий и их актуальность.
2. Занятость актеров в различных спектаклях и ролях: Ключевая особенность театра – постоянная смена репертуара и занятость актеров одновременно в нескольких постановках. Система должна отслеживать, в каких спектаклях задействован каждый актер, какие роли он исполняет, и в какие периоды времени. Это позволит эффективно планировать репетиции и гастроли, избегая конфликтов в расписании.
3. Несколько актеров на одну роль: В театре часто практикуется введение нескольких актеров на одну и ту же роль (взаимозаменяемость, второй состав, стажерские составы). ИС должна корректно отображать эту связь, позволяя при необходимости быстро найти всех исполнителей конкретной роли в определённом спектакле.
4. Специфика контрактов и оплаты труда: Контракты актеров могут быть значительно сложнее стандартных трудовых договоров. Помимо базовой зарплаты, они могут включать дополнительные суммы по итогам работы, премии за количество сыгранных спектаклей, за исполнение ведущих ролей, за гастроли и т.д. Система должна быть способна учитывать эти переменные составляющие оплаты, что требует гибкой структуры для расчета вознаграждений.
5. Уникальность спектаклей и ролей: Каждый спектакль имеет уникальный номер и название, а внутри него – свой набор ролей, каждая из которых также уникальна в рамках данного спектакля. ИС должна четко разграничивать спектакли, их версии и роли, ассоциированные с ними.
6. Учет технических и административных ролей: Помимо творческого состава, театр насчитывает множество технических (осветители, звукорежиссеры, гримеры, костюмеры) и административных (директоры, менеджеры, администраторы) сотрудников. Их учет также должен быть интегрирован в систему, возможно, с меньшей детализацией по ролям в спектаклях, но с акцентом на их должности, отделы и графики работы.
7. График отпусков и творческие отпуска: Планирование отпусков в театре имеет свои особенности, поскольку оно должно быть синхронизировано с репертуарным планом. Актеры могут иметь творческие отпуска, которые также требуют отдельного учета.

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

Функциональные требования к ИС учета персонала

Функциональные требования определяют, что именно должна делать информационная система, то есть какие конкретные задачи она способна выполнять для пользователя. В контексте ИС «Учет персонала в театре», эти требования формируют ядро её предназначения, обеспечивая автоматизацию всех ключевых кадровых операций и предоставление необходимой информации. Автоматизация кадрового делопроизводства — это не просто ускорение, но и значительное повышение точности и надёжности работы с данными.

Ключевые функциональные требования к нашей системе включают:

1. Учет должностей и отделов:
   • Возможность добавления, редактирования и удаления информации о должностях (например, «Актер драмы», «Главный режиссер», «Осветитель», «Бухгалтер») и отделах (например, «Актерская труппа», «Режиссерский отдел», «Бухгалтерия», «Цех декораций»).
   • Привязка должностей к отделам.
2. Учет сотрудников:
   • Полный набор личных данных: ФИО, дата рождения, место рождения, пол, гражданство, семейное положение, адрес проживания и регистрации, контактные данные (телефон, email).
   • Данные об образовании: Учебное заведение, специальность, год окончания, квалификация, документы об образовании.
   • Состав семьи: Информация о супругах, детях (ФИО, дата рождения).
   • Стаж работы: Общий стаж, стаж работы в театре.
   • Отпуска: Планирование, учет использованных и неиспользованных отпусков (ежегодные, учебные, творческие).
   • Назначения и переводы: История должностных перемещений внутри театра.
   • Воинский учет: Сведения о воинском звании, военно-учетной специальности, категории годности к военной службе.
3. Учет вакансий:
   • Ведение списка открытых вакансий с указанием должности, отдела, требований к кандидатам, даты открытия и закрытия вакансии.
   • Возможность связывать вакансии с соответствующими должностями.
4. Учет уволенных сотрудников:
   • Хранение полной информации об уволенных сотрудниках, дате и причине увольнения.
   • Отдельный статус для уволенных, исключающий их из активного штата, но сохраняющий данные для истории и отчетности.
5. Учет переподготовок и повышения квалификации:
   • Фиксация информации о прохождении сотрудниками курсов повышения квалификации, тренингов, переподготовки с указанием названий курсов, дат, выданных документов.
6. Формирование штатного расписания:
   • Автоматическое формирование и вывод актуального штатного расписания театра с указанием должностей, отделов, количества штатных единиц и занятых ставок.
7. Выполнение кадровых операций:
   • Оформление приема на работу: Ввод всех необходимых данных нового сотрудника, присвоение должности.
   • Составление личных карточек: Формирование и печать унифицированной формы личной карточки Т-2.
   • График отпусков: Создание, редактирование и просмотр графика отпусков на год.
   • Приказы: Формирование приказов на отпуск, увольнение, перевод, прием на работу.
8. Составление отчетной документации:
   • Отчет «Сведения о состоянии кадров в отрасли» (для вышестоящих организаций).
   • Отчет по вакансиям.
   • Список сотрудников по отделам.
   • Список военнообязанных сотрудников.
   • График отпусков.
   • Список дней рождения сотрудников (на месяц, год).
   • Отчеты по занятости актеров в спектаклях и ролях.
9. Управление финансовыми данными, связанными с персоналом:
   • Учет окладов, тарифных ставок.
   • Учет различных доплат (за звание, выслугу лет).
   • Учет премий за участие в спектаклях или другие достижения.
10. Поиск и извлечение данных:
    • Развитые функции поиска и фильтрации данных по различным критериям (ФИО, должность, отдел, статус, звание актера, участие в спектакле).
    • Возможность выполнения сложных поисковых запросов.

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

Нефункциональные требования к ИС: Производительность, надежность, безопасность, удобство и масштабируемость

Если функциональные требования описывают, что система делает, то нефункциональные требования определяют, как она это делает. Они касаются качества, эффективности и устойчивости системы, являясь критически важными для её успешной эксплуатации. Для ИС «Учет персонала в театре» эти аспекты особенно важны, поскольку они напрямую влияют на удовлетворенность пользователей, безопасность конфиденциальных данных и долгосрочную жизнеспособность системы.

1. Безопасность: Защита от несанкционированного доступа, изменения, утечки и уничтожения данных является наивысшим приоритетом для ИС, работающей с персональными данными. Это включает:
   • Аутентификация и авторизация пользователей.
   • Разграничение прав доступа на уровне объектов (таблиц, форм, отчетов).
   • Защита от вредоносного ПО.
   • Контроль целостности данных.
   • Механизмы резервного копирования и восстановления.
2. Производительность: Система должна оперативно реагировать на запросы пользователя и эффективно обрабатывать данные. Для ИС учета персонала это означает:
   • Время ответа (латентность): Скорость, с которой система реагирует на действия пользователя. Например, открытие формы сотрудника не должно превышать 1-2 секунды. Для веб-приложений эти метрики могут измеряться в миллисекундах.
   • Пропускная способность: Количество операций (например, запросов на выборку данных), которые система может обработать в единицу времени. Хотя Access имеет ограничения, система должна обеспечивать приемлемую скорость при работе с типовыми объемами данных театра.
   • Утилизация ресурсов: Эффективное использование ресурсов ЦПУ, памяти и дискового ввода-вывода.
3. Надежность/Доступность: Система должна работать безотказно и быть доступной для использования в требуемом режиме.
   • Надежность: Способность системы выполнять свои функции без сбоев. Измеряется показателями, такими как среднее время наработки на отказ (MTBF — Mean Time Between Failures), которое рассчитывается как отношение общего времени работы системы к количеству сбоев. Например, MTBF = (Общее время работы) / (Количество сбоев). Чем выше MTBF, тем надёжнее система.
   • Доступность: Процент времени, в течение которого система доступна для пользователей. Часто выражается в «девятках», например, 99,99% («четыре девятки») означает, что система недоступна не более 52,56 минут в год.
   • Ремонтопригодность: Легкость и скорость восстановления системы после сбоя. Измеряется средним временем на восстановление (MTTR — Mean Time To Repair). Чем ниже MTTR, тем быстрее система восстанавливается.
4. Удобство использования (Usability): Система должна быть интуитивно понятной и простой в эксплуатации, что снижает количество ошибок и утомляемость персонала.
   • Продуманный пользовательский интерфейс форм для ввода и редактирования данных.
   • Логичная навигация.
   • Четкие сообщения об ошибках.
   • Схожесть экранных форм с бумажными аналогами.
5. Масштабируемость: Способность системы эффективно справляться с увеличением объема данных или числа пользователей без существенного снижения производительности. Хотя Microsoft Access имеет свои ограничения по масштабируемости (общий размер БД до 2 ГБ, практическое число одновременных пользователей 10-20), ИС должна быть спроектирована с учетом потенциального роста в рамках этих ограничений.
6. Совместимость: Система должна корректно функционировать с определенной операционной системой и другим ПО. Для Microsoft Access это означает совместимость преимущественно с операционными системами семейства Windows.
7. Адаптация: Способность системы адаптироваться к изменяющимся условиям функционирования, например, к новым законодательным требованиям или изменению внутренней структуры театра.

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

Проектирование базы данных для ИС «Учет персонала в театре»

Проектирование базы данных — это, пожалуй, наиболее ответственный и творческий этап в создании информационной системы. Именно здесь закладывается фундамент, на котором будет стоять вся логика работы с данными. Как архитектор тщательно прорабатывает каждый элемент несущей конструкции, так и разработчик БД должен скрупулезно продумать структуру хранения информации, чтобы обеспечить её целостность, непротиворечивость и эффективность доступа. Мы начнем с высокоуровневого концептуального представления с помощью ER-модели и затем перейдем к детализированной реляционной структуре, применяя принципы нормализации.

Концептуальное проектирование: ER-модель

Концептуальное проектирование — это первый шаг в создании БД, где мы абстрагируемся от технических деталей и фокусируемся на семантике, то есть на смысле данных и отношениях между ними. Главным инструментом здесь выступает ER-модель (Entity-Relationship, или модель «сущность-связь»), которая позволяет графически представить структуру предметной области. ER-диаграмма — это визуальный язык, понятный как аналитикам, так и заказчикам, позволяющий «увидеть» будущую базу данных.

Основные компоненты ER-диаграммы:

• Сущности (Entity): Объекты или события, информацию о которых необходимо хранить. На диаграммах они обычно обозначаются прямоугольниками.
• Атрибуты (Attribute): Характеристики сущностей, описывающие их свойства. На диаграммах атрибуты обычно обозначаются овалами и связаны с сущностями.
• Связи (Relationship): Взаимосвязи между сущностями, показывающие, как они взаимодействуют. На диаграммах связи обозначаются ромбами.

Типы связей между сущностями:

• Один к одному (1:1): Один экземпляр сущности A связан только с одним экземпляром сущности B.
• Один ко многим (1:М): Один экземпляр сущности A связан со множеством экземпляров сущности B.
• Многие ко многим (М:М): Множество экземпляров одной сущности связаны со множеством экземпляров другой сущности. Такие связи на этапе логического проектирования всегда декомпозируются через промежуточную сущность.

Давайте построим ER-диаграмму для ИС «Учет персонала в театре», выделив ключевые сущности, их атрибуты и связи:

Ключевые сущности для ИС «Учет персонала в театре»:

1. Сотрудники (Employees): Основная сущность, представляющая всех сотрудников театра.
   • Атрибуты: КодСотрудника (первичный ключ, счетчик), Фамилия, Имя, Отчество, ДатаРождения, МестоРождения, Пол, Гражданство, СемейноеПоложение, АдресПроживания, АдресРегистрации, Телефон, Email, ДатаПриемаНаРаботу, ОбщийСтаж, СтажВТеатре, Фото.
2. Должности (Positions): Список всех возможных должностей в театре.
   • Атрибуты: КодДолжности (первичный ключ, счетчик), НазваниеДолжности, Оклад.
3. Отделы (Departments): Структурные подразделения театра.
   • Атрибуты: КодОтдела (первичный ключ, счетчик), НазваниеОтдела, ТелефонОтдела.
4. Спектакли (Performances): Информация о всех постановках.
   • Атрибуты: КодСпектакля (первичный ключ, счетчик), НазваниеСпектакля, Режиссер, ДатаПремьеры, Продолжительность.
5. Роли (Roles): Роли в каждом спектакле.
   • Атрибуты: КодРоли (первичный ключ, счетчик), НазваниеРоли, ОписаниеРоли, КодСпектакля (внешний ключ к Спектаклям).
6. УчастиеВ_Спектаклях (PerformanceParticipation): Сущность для связи актеров с ролями в спектаклях (разрешение М:М связи между Сотрудниками и Ролями).
   • Атрибуты: КодУчастия (первичный ключ, счетчик), КодСотрудника (внешний ключ к Сотрудникам), КодРоли (внешний ключ к Ролям), ДатаНачалаУчастия, ДатаОкончанияУчастия, СтатусУчастия (например, «Основной», «Дублер», «Стажер»).
7. Контракты (Contracts): Информация о трудовых договорах и оплате.
   • Атрибуты: КодКонтракта (первичный ключ, счетчик), КодСотрудника (внешний ключ), НомерКонтракта, ДатаНачала, ДатаОкончания, БазоваяЗарплата, ДопУсловия (текст), СтатусКонтракта.
8. Премии (Bonuses): Дополнительные выплаты за спектакли или другие достижения.
   • Атрибуты: КодПремии (первичный ключ, счетчик), КодКонтракта (внешний ключ), ТипПремии, СуммаПремии, ДатаНачисления, Описание.
9. Образование (Education): Сведения об образовании сотрудников.
   • Атрибуты: КодОбразования (первичный ключ, счетчик), КодСотрудника (внешний ключ), УчебноеЗаведение, Специальность, ГодОкончания, Квалификация, НомерДиплома.
10. Семья (FamilyMembers): Сведения о членах семьи сотрудников.
    • Атрибуты: КодЧленаСемьи (первичный ключ, счетчик), КодСотрудника (внешний ключ), ФИО, ДатаРождения, СтепеньРодства.
11. ВоинскийУчет (MilitaryRecords): Данные для воинского учета.
    • Атрибуты: КодВоинскогоУчета (первичный ключ, счетчик), КодСотрудника (внешний ключ), КатегорияУчета, ВоинскоеЗвание, ВУС, ГодностьКВС.
12. Отпуска (Vacations): Информация о всех видах отпусков.
    • Атрибуты: КодОтпуска (первичный ключ, счетчик), КодСотрудника (внешний ключ), ТипОтпуска, ДатаНачала, ДатаОкончания, КоличествоДней, Основание.
13. Звания (Titles): Актерские и почетные звания.
    • Атрибуты: КодЗвания (первичный ключ, счетчик), ��азваниеЗвания (например, «Заслуженный артист»), ДатаПрисвоения, КодСотрудника (внешний ключ).

Связи между сущностями:

• Сотрудники – Отделы: 1:М (Один Отдел может иметь много Сотрудников, но один Сотрудник относится к одному Отделу).
• Сотрудники – Должности: 1:М (Одна Должность может быть занята многими Сотрудниками, но один Сотрудник занимает одну Должность в конкретный момент. Для истории должностей можно создать отдельную таблицу «ИсторияДолжностей»).
• Сотрудники – Контракты: 1:М (Один Сотрудник может иметь много Контрактов в разное время).
• Контракты – Премии: 1:М (Один Контракт может иметь много Премий).
• Сотрудники – Образование: 1:М (Один Сотрудник может иметь несколько записей об Образовании).
• Сотрудники – Семья: 1:М (Один Сотрудник может иметь несколько ЧленовСемьи).
• Сотрудники – ВоинскийУчет: 1:1 (Один Сотрудник имеет одну запись ВоинскогоУчета).
• Сотрудники – Отпуска: 1:М (Один Сотрудник может иметь много Отпусков).
• Сотрудники – Звания: 1:М (Один Сотрудник может иметь несколько Званий, присвоенных в разное время).
• Спектакли – Роли: 1:М (Один Спектакль может иметь много Ролей).
• Сотрудники – Роли: М:М (Множество Сотрудников могут исполнять множество Ролей в разных Спектаклях). Эта связь декомпозируется через промежуточную сущность УчастиеВ_Спектаклях.

На основе этой информации можно построить детальную ER-диаграмму, используя стандартные обозначения (прямоугольники для сущностей, овалы для атрибутов, ромбы для связей, а также индикаторы кардинальности связей).

Логическое проектирование: Реляционная модель и нормализация

После того как концептуальная схема БД в виде ER-модели создана, следующим шагом является её преобразование в логическую структуру, которая будет понятна для выбранной системы управления базами данных (СУБД) — в нашем случае, реляционной СУБД Microsoft Access. Этот процесс называется логическим проектированием, и его центральным элементом является нормализация.

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

Нормализация базы данных — это систематический процесс, направленный на:

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

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

Понятие функциональной зависимости: В основе нормализации лежит понятие функциональной зависимости. Атрибут B функционально зависит от атрибута A (A → B), если каждое значение A однозначно определяет значение B. Например, КодСотрудника → Фамилия, потому что по КодуСотрудника всегда можно однозначно определить Фамилию.

Рассмотрим основные нормальные формы и применим их к нашим сущностям:

1. Первая нормальная форма (1НФ)

Таблица находится в 1НФ, если:

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

Пример: Если бы в таблице Сотрудники было поле Телефоны, содержащее список номеров через запятую, это нарушало бы 1НФ. Для соблюдения 1НФ мы создадим отдельную таблицу КонтактныеДанные или ТелефоныСотрудников со связью «один ко многим» с таблицей Сотрудники. В нашем ER-моделировании мы уже учли это, создав отдельные таблицы для Образования, Семьи, Отпусков, Званий, что по умолчанию соответствует 1НФ.

2. Вторая нормальная форма (2НФ)

Таблица находится во 2НФ, если:

• Она находится в 1НФ.
• Каждый неключевой атрибут полностью функционально зависит от всего первичного ключа. Это означает, что неключевой атрибут не должен зависеть от части составного первичного ключа.

Пример: Рассмотрим гипотетическую таблицу ЗанятостьВ_Спектаклях с составным первичным ключом (КодСотрудника, КодСпектакля) и атрибутами КодРоли, НазваниеРоли, ДатаЗанятости. НазваниеРоли зависит только от КодаРоли, а не от всего составного ключа.
Чтобы привести к 2НФ, мы должны выделить КодРоли и НазваниеРоли в отдельную таблицу Роли, а в таблице ЗанятостьВ_Спектаклях оставить только КодСотрудника, КодСпектакля и КодРоли (как внешний ключ), а также другие атрибуты, зависящие от всего составного ключа (ДатаЗанятости).
В нашей ER-модели мы уже создали отдельные сущности Спектакли и Роли, а связь Сотрудники — Роли — Спектакли разрешена через промежуточную сущность УчастиеВ_Спектаклях, которая имеет составной ключ или свой искусственный ключ, и все её атрибуты (кроме ключей) будут полностью зависеть от этого ключа.

3. Третья нормальная форма (3НФ)

Таблица находится в 3НФ, если:

• Она находится во 2НФ.
• Она не содержит транзитивных функциональных зависимостей. Это означает, что неключевые атрибуты не должны зависеть от других неключевых атрибутов (то есть, неключевой атрибут не должен быть функционально зависим от первичного ключа через другой неключевой атрибут).

Пример: Предположим, в таблице Сотрудники кроме КодСотрудника (первичный ключ) есть КодОтдела, НазваниеОтдела, ТелефонОтдела. Здесь НазваниеОтдела и ТелефонОтдела зависят от КодаОтдела, а КодОтдела зависит от КодаСотрудника. Это транзитивная зависимость: КодСотрудника → КодОтдела → НазваниеОтдела/ТелефонОтдела.
Для приведения к 3НФ необходимо вынести КодОтдела, НазваниеОтдела и ТелефонОтдела в отдельную таблицу Отделы, а в таблице Сотрудники оставить только КодОтдела как внешний ключ.
Аналогично, если бы в таблице Должности был НазваниеОтдела, то это также являлось бы нарушением 3НФ, если Оклад зависел бы от НазванияДолжности, а НазваниеДолжности от КодаДолжности.

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

Таблица	Первичный ключ (PK)	Внешние ключи (FK)	Атрибуты (поля)
Сотрудники	КодСотрудника	КодДолжности (к Должности), КодОтдела (к Отделы)	Фамилия, Имя, Отчество, ДатаРождения, МестоРождения, Пол, Гражданство, СемейноеПоложение, АдресПроживания, АдресРегистрации, Телефон, Email, ДатаПриемаНаРаботу, ОбщийСтаж, СтажВТеатре, Фото
Должности	КодДолжности		НазваниеДолжности, Оклад
Отделы	КодОтдела		НазваниеОтдела, ТелефонОтдела
Спектакли	КодСпектакля		НазваниеСпектакля, Режиссер, ДатаПремьеры, Продолжительность
Роли	КодРоли	КодСпектакля (к Спектакли)	НазваниеРоли, ОписаниеРоли
УчастиеВ_Спектаклях	КодУчастия	КодСотрудника (к Сотрудники), КодРоли (к Роли)	ДатаНачалаУчастия, ДатаОкончанияУчастия, СтатусУчастия
Контракты	КодКонтракта	КодСотрудника (к Сотрудники)	НомерКонтракта, ДатаНачала, ДатаОкончания, БазоваяЗарплата, ДопУсловия, СтатусКонтракта
Премии	КодПремии	КодКонтракта (к Контракты)	ТипПремии, СуммаПремии, ДатаНачисления, Описание
Образование	КодОбразования	КодСотрудника (к Сотрудники)	УчебноеЗаведение, Специальность, ГодОкончания, Квалификация, НомерДиплома
Семья	КодЧленаСемьи	КодСотрудника (к Сотрудники)	ФИО, ДатаРождения, СтепеньРодства
ВоинскийУчет	КодВоинскогоУчета	КодСотрудника (к Сотрудники)	КатегорияУчета, ВоинскоеЗвание, ВУС, ГодностьКВС
Отпуска	КодОтпуска	КодСотрудника (к Сотрудники)	ТипОтпуска, ДатаНачала, ДатаОкончания, КоличествоДней, Основание
Звания	КодЗвания	КодСотрудника (к Сотрудники)	НазваниеЗвания, ДатаПрисвоения
ИсторияДолжностей	КодИсторииДолжности	КодСотрудника (к Сотрудники), КодДолжности (к Должности)	ДатаНазначения, ДатаОсвобождения

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

Реализация информационной системы в Microsoft Access

После тщательного концептуального и логического проектирования базы данных настаёт время для её физического воплощения. Для нашей курсовой работы в качестве инструмента выбрана Microsoft Access – СУБД, входящая в состав пакета Microsoft Office. Access, несмотря на некоторые ограничения по масштабируемости, является отличным выбором для небольших и средних приложений, особенно для академических проектов, благодаря своей относительной простоте освоения и наличию встроенных средств для создания пользовательского интерфейса. Этот раздел детально описывает процесс реализации ИС «Учет персонала в театре» в среде Access.

Физическое проектирование: Создание таблиц и связей

Физическое проектирование — это этап, на котором логическая модель базы данных адаптируется под специфику конкретной СУБД, в нашем случае, Microsoft Access. Здесь определяются точные типы данных для каждого атрибута, устанавливаются первичные и внешние ключи, создаются индексы для оптимизации производительности и, наконец, реализуются связи между таблицами.

1. Создание таблиц в Microsoft Access:

Для каждой сущности, определённой на этапе логического проектирования, будет создана отдельная таблица в Access. Процесс создания включает:

• Выбор режима: Таблицы можно создавать в режиме конструктора (рекомендуется для детальной настройки) или с помощью мастера.
• Определение полей: Для каждого атрибута указывается имя поля и тип данных, максимально соответствующий хранимой информации.
  • КодСотрудника, КодДолжности, КодОтдела и другие первичные ключи: Тип данных «Счетчик» (AutoNumber). Это автоматически генерирует уникальные порядковые номера для каждой новой записи, что идеально подходит для первичных ключей.
  • Фамилия, Имя, НазваниеДолжности, НазваниеСпектакля: Тип данных «Короткий текст» (Short Text) или «Длинный текст» (Long Text) при необходимости.
  • ДатаРождения, ДатаПриемаНаРаботу, ДатаПремьеры: Тип данных «Дата/время» (Date/Time).
  • Оклад, БазоваяЗарплата, СуммаПремии: Тип данных «Денежный» (Currency) для финансовых данных.
  • ОбщийСтаж, СтажВТеатре, КоличествоДней: Тип данных «Числовой» (Number), с выбором соответствующего размера поля (например, Целое, Длинное целое).
  • Фото: Тип данных «Вложение» (Attachment) для хранения изображений, или «Объект OLE» (OLE Object) для более сложных медиа, хотя чаще используют хранение пути к файлу в текстовом поле.
  • Пол, СемейноеПоложение, СтатусУчастия: Тип данных «Короткий текст» с использованием списков подстановок (lookup lists) для стандартизации ввода.
• Установка первичных ключей: Для каждой таблицы поле, обозначенное как PK, устанавливается в качестве первичного ключа. Это гарантирует уникальность каждой записи.
• Свойства полей: Настройка дополнительных свойств, таких как «Обязательное поле» (Required), «Индексированное поле» (Indexed – для ускорения поиска и сортировки), «Значение по умолчанию» (Default Value), «Условие на значение» (Validation Rule) для контроля корректности ввода данных.

Пример структуры таблицы «Сотрудники»:

Имя поля	Тип данных	Описание	Свойства поля (пример)
КодСотрудника	Счетчик	Уникальный идентификатор сотрудника (PK)	Первичный ключ
Фамилия	Короткий текст	Фамилия сотрудника	Размер поля: 50, Обязательное поле: Да
Имя	Короткий текст	Имя сотрудника	Размер поля: 50, Обязательное поле: Да
Отчество	Короткий текст	Отчество сотрудника	Размер поля: 50
ДатаРождения	Дата/время	Дата рождения	Формат: Краткая дата, Обязательное поле: Да
КодДолжности	Числовой	Внешний ключ к таблице «Должности» (FK)	Размер поля: Длинное целое, Обязательное поле: Да, Индексированное: Да
КодОтдела	Числовой	Внешний ключ к таблице «Отделы» (FK)	Размер поля: Длинное целое, Обязательное поле: Да, Индексированное: Да
… (другие поля)

2. Установление связей между таблицами:

После создания всех таблиц необходимо установить между ними связи, отражающие реляционную структуру БД. Это делается в окне «Схема данных» (Relationships) Access:

• Добавление всех необходимых таблиц на схему.
• Перетаскивание первичных ключей (PK) одной таблицы на соответствующие внешние ключи (FK) другой таблицы.
• Настройка связей: При создании связи открывается окно «Изменение связи», где крайне важно установить флажок «Обеспечение целостности данных». Это гарантирует, что:
  • Нельзя ввести значение во внешний ключ, если оно отсутствует в первичном ключе связанной таблицы (например, нельзя назначить сотрудника на несуществующую должность).
  • Нельзя удалить запись из главной таблицы, если есть связанные записи в подчинённой таблице (например, нельзя удалить отдел, если в нём есть сотрудники).
  • Можно также установить каскадное обновление связанных полей (при изменении PK в главной таблице, FK обновляется в подчинённой) и каскадное удаление связанных записей (при удалении PK в главной таблице, связанные записи удаляются в подчинённой). Для ИС учета персонала каскадное удаление следует использовать с осторожностью, чтобы избежать случайной потери данных.

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

Разработка пользовательского интерфейса: Формы для ввода и редактирования данных

Пользовательский интерфейс (UI) – это лицо информационной системы. От его удобства и интуитивности напрямую зависит продуктивность работы персонала и минимизация ошибок. В Microsoft Access Forms (формы) являются основным инструментом для создания UI, позволяя эффективно просматривать, вводить и редактировать данные из таблиц и запросов.

При проектировании форм для ИС «Учет персонала в театре» мы будем ориентироваться на следующие принципы:

1. Интуитивность и простота: Формы должны быть максимально понятными для пользователя, не требуя дополнительных инструкций.
2. Эргономичность: Расположение элементов управления должно быть логичным и минимизировать утомляемость при длительной работе.
3. Соответствие бумажным бланкам: Где это возможно, дизайн экранных форм будет имитировать привычные бумажные документы (например, личную карточку сотрудника), что снижает порог вхождения и количество ошибок при переносе данных.
4. Разграничение доступа: Через формы можно ограничить прямой доступ пользователей к таблицам, предоставляя им только те данные и функции, которые соответствуют их роли.

Процесс создания форм в Access:

Access предлагает несколько способов создания форм:

1. Мастер форм (Form Wizard): Самый быстрый способ создать базовую форму. Он задает вопросы о том, какие поля и таблицы нужно использовать, и предлагает различные макеты. Отлично подходит для быстрого создания черновиков.
2. Средство «Форма» (Form Tool): Позволяет создать простую форму на основе выбранной таблицы или запроса одним щелчком мыши.
3. Конструктор форм (Form Design): Наиболее мощный и гибкий инструмент, дающий полный контроль над дизайном формы, расположением элементов, добавлением кнопок, вкладок, списков и программированием событий с помощью VBA.

Примеры форм для ИС «Учет персонала в театре»:

• Форма «Сотрудники»:
  • Предназначена для ввода и редактирования основных данных о сотруднике.
  • Может быть реализована как разделенная форма (Split Form), отображающая данные одновременно в режиме таблицы (для быстрого обзора) и в представлении формы (для детального редактирования).
  • Использование вкладок (Tab Control) для организации информации: «Личные данные», «Образование», «Семья», «Контракты», «Отпуска», «Участие в спектаклях», «Воинский учет». Каждая вкладка может содержать подформы (Subforms), отображающие связанные данные из других таблиц (например, список всех отпусков сотрудника, его образования или ролей в спектаклях).
  • Поля со списком (Combo Box) или поля со списком подстановки (Lookup Fields) для выбора значений из связанных таблиц (например, выбор должности из таблицы Должности, отдела из таблицы Отделы), что стандартизирует ввод и предотвращает опечатки.
  • Кнопки для навигации (Далее, Назад), сохранения (Сохранить), удаления (Удалить), добавления новой записи (Добавить).
  • Поле для загрузки фотографии сотрудника.
• Форма «Спектакли»:
  • Для ввода и редактирования информации о спектаклях.
  • Может включать подформу для управления ролями в данном спектакле.
• Форма «Контракты»:
  • Для детализированного ввода условий контракта сотрудника, включая базовую зарплату и возможность добавления премий через подформу.
• Форма «Должности» / «Отделы»:
  • Простые формы для управления справочными данными.

Пример элемента управления «Поле со списком» (Combo Box) для выбора должности:
В режиме конструктора формы на поле КодДолжности можно установить элемент управления «Поле со списком», указав в его свойствах:

• Источник строк: SQL-запрос SELECT КодДолжности, НазваниеДолжности FROM Должности ORDER BY НазваниеДолжности;
• Число столбцов: 2
• Ширина столбцов: 0см;3см (чтобы КодДолжности был скрыт, но НазваниеДолжности отображалось).
• Присоединенный столбец: 1 (чтобы в поле КодДолжности формы сохранялся именно код, а не название).

Такой подход к разработке форм обеспечивает удобный и эффективный пользовательский интерфейс, который минимизирует ошибки ввода данных и значительно упрощает работу с информационной системой учета персонала в театре.

Разработка функциональных модулей: Запросы и отчеты

Запросы и отчеты — это мощные инструменты Microsoft Access, которые превращают сырые данные, хранящиеся в таблицах, в осмысленную информацию и наглядные документы. Запросы позволяют извлекать, фильтровать, сортировать и анализировать данные, а отчеты — представлять эту информацию в удобочитаемом, печатном виде. В ИС «Учет персонала в театре» они являются ключевыми для поддержки принятия решений и выполнения повседневных задач кадрового учета.

Запросы: Окно в мир данных

Запросы в Access позволяют задавать вопросы к базе данных и получать на них ответы. Они могут быть простыми (выборка данных по одному критерию) или сложными (объединение данных из нескольких таблиц, агрегирование, вычисления).

Способы создания запросов:

• Мастер запросов (Query Wizard): Простой способ для создания типовых запросов (выборка, перекрестные, поиск повторяющихся/несвязанных записей).
• Конструктор запросов (Query Design View): Дает полный контроль над запросом, позволяя добавлять таблицы, выбирать поля, устанавливать критерии выборки, сортировку, создавать вычисляемые поля.
• Режим SQL (SQL View): Позволяет писать запросы на языке SQL, что даёт максимальную гибкость и является стандартом в работе с базами данных.

Примеры запросов для ИС «Учет персонала в театре»:

1. Запрос выбора: «Сотрудники по должности»
   • Задача: Вывести список всех сотрудников, занимающих определённую должность.
   • Таблицы: Сотрудники, Должности.
   • Поля: Фамилия, Имя, Отчество из Сотрудники, НазваниеДолжности из Должности.
   • Критерий: НазваниеДолжности = [Введите название должности] (пользовательский параметр).
   • SQL-пример:

     SELECT Сотрудники.Фамилия, Сотрудники.Имя, Сотрудники.Отчество, Должности.НазваниеДолжности
     FROM Должности INNER JOIN Сотрудники ON Должности.КодДолжности = Сотрудники.КодДолжности
     WHERE (((Должности.НазваниеДолжности)=[Введите название должности]));

2. Запрос перекрестный: «Занятость актеров по спектаклям»
   • Задача: Отобразить, сколько актеров задействовано в каждом спектакле или какие роли в каком спектакле занимают актеры.
   • Таблицы: Сотрудники, УчастиеВ_Спектаклях, Роли, Спектакли.
   • Поля: НазваниеСпектакля (заголовок строки), НазваниеРоли (заголовок столбца), Фамилия (значение, с функцией Count или First).
3. Запрос действия (обновление): «Повышение окладов»
   • Задача: Увеличить оклад для всех сотрудников определённой должности на заданный процент.
   • Таблицы: Должности.
   • Действие: Обновление поля Оклад на [Оклад] * (1 + [Процент повышения]/100).
   • Критерий: НазваниеДолжности = [Введите название должности].
4. Запрос на поиск: «График отпусков на год»
   • Задача: Вывести информацию о запланированных отпусках всех сотрудников на текущий год.
   • Таблицы: Сотрудники, Отпуска.
   • Поля: Фамилия, Имя, ТипОтпуска, ДатаНачала, ДатаОкончания.
   • Критерий: Year([ДатаНачала]) = Year(Date()).

Отчеты: Информационные выводы на печать

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

Способы создания отчетов:

• Мастер отчетов (Report Wizard): Удобен для создания простых, но хорошо структурированных отчетов на основе таблиц или запросов.
• Конструктор отчетов (Report Design View): Дает полный контроль над внешним видом отчета, позволяет создавать сложные группировки, вычисляемые поля, внедрять подмножества данных (подобно подформам).

Примеры отчетов для ИС «Учет персонала в театре»:

1. Отчет «Штатное расписание»:
   • Источник данных: Запрос, объединяющий Отделы, Должности и Сотрудники.
   • Группировка: По НазваниюОтдела, затем по НазваниюДолжности.
   • Содержимое: Название отдела, название должности, количество штатных единиц, ФИО сотрудников, оклад.
   • Итоговые значения: Общее количество сотрудников в каждом отделе и по театру в целом.
2. Отчет «Сведения о состоянии кадров»:
   • Источник данных: Запрос, агрегирующий информацию по полу, возрасту, стажу, образованию сотрудников.
   • Содержимое: Статистические данные, необходимые для внешней отчетности.
3. Отчет «График отпусков»:
   • Источник данных: Запрос, отбирающий отпуска на определенный период.
   • Группировка: По Отделу или Должности.
   • Содержимое: ФИО сотрудника, даты начала и окончания отпуска, тип отпуска.
   • Визуализация: Возможно использование графических элементов для отображения периодов отпусков.
4. Отчет «Дни рождения сотрудников»:
   • Источник данных: Запрос, отбирающий дни рождения на текущий месяц/год.
   • Содержимое: ФИО сотрудника, дата рождения, возраст.

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

Алгоритмы обработки данных и автоматизация

Сердцем любой информационной системы являются алгоритмы, которые определяют логику обработки данных. В Microsoft Access эти алгоритмы реализуются как через встроенные функции запросов и форм, так и посредством языка программирования Visual Basic for Applications (VBA). Понимание и описание этих алгоритмов критически важно для курсовой работы, поскольку оно демонстрирует глубокое понимание внутренней работы системы.

Основные операции с данными, для которых необходимо разработать алгоритмы, включают:

1. Добавление данных (Insert):
   • Алгоритм:
     1. Пользователь открывает соответствующую форму (например, «Сотрудники»).
     2. Нажимает кнопку «Добавить нового сотрудника» или переходит к пустой записи.
     3. Вводит данные в поля формы.
     4. Система автоматически генерирует первичный ключ (для полей типа «Счетчик»).
     5. При вводе внешних ключей (например, КодДолжности, КодОтдела) используются поля со списком, которые отображают названия из связанных таблиц, но сохраняют коды.
     6. При попытке сохранения система проверяет данные на соответствие условиям валидации (например, обязательные поля, корректность формата даты), а также на соблюдение целостности данных, установленной в связях между таблицами.
     7. Если все проверки пройдены, данные записываются в соответствующую таблицу.
   • Реализация в Access: Ввод данных через привязанные формы. Проверки могут быть реализованы через свойства полей (обязательность, условие на значение) и события формы (например, BeforeUpdate с использованием VBA для более сложных проверок).
2. Редактирование данных (Update):
   • Алгоритм:
     1. Пользователь открывает форму и находит запись, которую необходимо отредактировать (через поиск, фильтрацию или навигацию).
     2. Изменяет значения в полях формы.
     3. При сохранении система выполняет те же проверки целостности и валидации, что и при добавлении.
     4. Если данные корректны, изменения применяются к соответствующей записи в таблице.
   • Реализация в Access: Редактирование через привязанные формы. Возможность использования VBA для логики, например, для автоматического обновления поля СтажВТеатре при изменении ДатыПриемаНаРаботу.
3. Удаление данных (Delete):
   • Алгоритм:
     1. Пользователь находит запись, предназначенную для удаления.
     2. Нажимает кнопку «Удалить» или использует стандартную функцию удаления записи в форме.
     3. Система проверяет наличие связанных записей в других таблицах (благодаря установленному флажку «Обеспечение целостности данных» без каскадного удаления). Если связанные записи существуют, система выдает сообщение об ошибке и предотвращает удаление.
     4. Если связанных записей нет или установлено каскадное удаление (и это разрешено политикой безопасности), система удаляет запись.
     5. Для повышения безопасности рекомендуется использовать подтверждение удаления («Вы уверены?»).
   • Реализация в Access: Удаление через стандартные функции форм или с помощью VBA-кода, вызывающего метод DoCmd.RunCommand acCmdDeleteRecord после подтверждения от пользователя. Для массового удаления могут использоваться запросы действия на удаление.
4. Поиск и фильтрация данных (Select with Criteria):
   • Алгоритм:
     1. Пользователь задает критерии поиска/фильтрации (например, фамилия, должность, отдел, статус участия в спектакле).
     2. Система формирует SQL-запрос на основе этих критериев.
     3. Запрос выполняется, и результат (отфильтрованные или найденные записи) отображается пользователю в форме или отчете.
   • Реализация в Access:
     • Фильтрация в формах: Использование встроенных средств фильтрации Access.
     • Поиск через поля формы: Создание текстового поля для ввода критерия поиска и кнопки, которая запускает фильтрацию формы по этому критерию с помощью VBA-кода (например, Me.Filter = "Фамилия LIKE '*" & Me.txtSearch & "*'", Me.FilterOn = True).
     • Специализированные запросы: Создание параметрических запросов, которые запрашивают критерии у пользователя.

Автоматизация с помощью VBA (Visual Basic for Applications):

VBA, встроенный язык программирования в Access, позволяет значительно расширить функциональность ИС и автоматизировать рутинные операции:

• Расширенная валидация данных: Создание сложных правил проверки, которые невозможно реализовать через свойства полей.
• Динамическое изменение интерфейса: Например, скрытие или отображение полей в зависимости от выбора пользователя.
• Сложные расчеты: Автоматический расчет стажа, премий на основе нескольких параметров.
• Создание пользовательских макросов и кнопок: Назначение VBA-кода кнопкам для выполнения специфических действий (например, печать отчета по текущему сотруднику, экспорт данных в Excel).
• Управление потоком данных: Автоматическое перемещение данных между таблицами или выполнение пакетных операций.

Пример VBA для кнопки «Рассчитать возраст» в форме «Сотрудники»:

Private Sub btnCalculateAge_Click()
    If Not IsNull(Me.ДатаРождения) Then
        Dim dtmBirthDate As Date
        Dim intAge As Integer

        dtmBirthDate = Me.ДатаРождения
        intAge = DateDiff("yyyy", dtmBirthDate, Date)
        If Date < DateSerial(Year(Date), Month(dtmBirthDate), Day(dtmBirthDate)) Then
            intAge = intAge - 1
        End If
        MsgBox "Возраст сотрудника: " & intAge & " лет", vbInformation, "Расчет возраста"
    Else
        MsgBox "Пожалуйста, введите дату рождения.", vbExclamation, "Ошибка"
    End If
End Sub

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

Информационная безопасность и защита данных в ИС учета персонала

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

Принципы и угрозы информационной безопасности

Основополагающие принципы информационной безопасности, закрепленные в таких стандартах, как ГОСТ Р 53114-2008, формируют каркас для построения надежной защиты данных. Эти принципы являются фундаментом для любой стратегии ИБ:

1. Конфиденциальность: Информация не должна быть раскрыта или сделана доступной для неуполномоченных лиц, организаций или процессов. Для ИС учета персонала это означает, что личные данные сотрудников (адреса, телефоны, сведения о семье, оклады, медицинские данные) должны быть доступны строго ограниченному кругу лиц, имеющих на это соответствующие полномочия.
2. Целостность: Информация не должна подвергаться несанкционированному изменению или уничтожению. Любые изменения должны быть авторизованы и отслеживаемы. Это гарантирует, что данные о зарплатах, должностях или стаже не будут искажены или подделаны.
3. Доступность: Авторизованные пользователи должны иметь доступ к информации и связанным ресурсам без излишних задержек, когда это необходимо. Система должна работать стабильно, а данные быть доступны для тех, кто имеет право на их использование, в любое время, когда это требуется для выполнения служебных обязанностей.

Нарушение любого из этих принципов приводит к угрозам информационной безопасности, которые могут быть классифицированы по источнику и характеру:

• Антропогенные преднамеренные угрозы: Это угрозы, исходящие от злоумышленников, целью которых является причинение ущерба, хищение или несанкционированное использование информации. Примеры:
  • Хакерские атаки: Попытки проникновения в систему извне.
  • Кража базы данных обиженным сотрудником: Инсайдерские угрозы, когда текущий или бывший сотрудник с доступом к системе использует его во вред организации.
  • Происки конкурентов: Целенаправленные действия других организаций по получению конфиденциальной информации.
  • Фишинг и социальная инженерия: Методы обмана пользователей для получения учетных данных.
• Антропогенные непреднамеренные угрозы: Возникают из-за человеческого фактора, но без злого умысла.
  • Халатность: Небрежное обращение с данными или средствами доступа (например, оставленный без присмотра компьютер с открытой БД).
  • Некомпетентность: Недостаточные знания или навыки пользователя, приводящие к ошибочным действиям (например, случайное удаление важной записи).
  • Случайность: Непредвиденные события, связанные с действиями человека (например, пролитый кофе на сервер).
• Техногенные угрозы: Сбои оборудования, программного обеспечения, ошибки в работе сети.
• Стихийные бедствия: Пожары, наводнения и другие природные явления, приводящие к потере данных.

Особое внимание следует уделить инсайдерским угрозам. Согласно исследованиям и стандартам Центробанка РФ, инсайдеры являются одним из основных источников рисков для информационной безопасности организаций. Это связано с тем, что они уже имеют определенный уровень доверия и доступа к внутренним системам, что значительно упрощает их злонамеренные действия.
Понимание этих принципов и классификация угроз позволяют разработать комплексный подход к защите данных в ИС учета персонала, сочетающий организационные и технические меры.

Методы и средства обеспечения информационной безопасности в MS Access

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

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

• Правила использования паролей (сложность, периодичность смены).
• Порядок обработки конфиденциальной информации.
• Процедуры реагирования на инциденты безопасности.
• Правила установки и обновления ПО.

2. Разграничение прав доступа:
Это одна из наиболее важных мер, особенно в Access. По умолчанию, при создании БД в Access, пользователь получает полные права доступа ко всем объектам (является членом группы Admins с именем Admin). Это необходимо изменить.

• Идентификация и аутентификация: Использование системы логинов и паролей. Пароль, установленный по умолчанию (если таковой есть), должен быть немедленно изменен до начала эксплуатации системы. Рекомендуется использовать сложные пароли, сочетающие буквы разного регистра, цифры и спецсимволы.
• Делегирование прав доступа: Создание разных групп пользователей с ограниченными правами. Например:
  • Администратор ИС: Полный доступ к структуре БД, данным, формам, отчетам, возможность создания и изменения пользователей.
  • Сотрудник отдела кадров: Полный доступ к просмотру, добавлению, редактированию, удалению данных о сотрудниках, контрактах, отпусках. Доступ к формированию всех отчетов.
  • Руководитель театра: Просмотр данных и отчетов (например, штатное расписание, сводки по персоналу), но без возможности изменения или удаления.
  • Бухгалтер: Доступ к финансовым данным персонала (оклады, премии) для расчета зарплаты, но без доступа к личным данным, не относящимся к финансовому учету.
• Создание специализированных форм: Для каждой категории пользователей могут быть разработаны отдельные формы, через которые они взаимодействуют с данными. Это позволяет скрыть ненужные поля, кнопки или даже целые таблицы. Например, бухгалтер может видеть форму с окладами, но не иметь доступа к вкладке с данными о составе семьи сотрудника.
• Защита базы данных паролем: Файл .accdb (или .mdb) можно защитить паролем. Это предотвратит несанкционированный доступ к самой базе данных.

3. Технические меры защиты:

• Средства криптографической защиты: Хотя Access не имеет встроенных мощных средств шифрования данных на уровне полей, можно использовать шифрование всего файла базы данных (если поддерживается версией Access) или сторонние утилиты для шифрования данных на диске.
• Антивирусная защита: Обязательна установка и регулярное обновление антивирусного ПО на всех рабочих станциях и сервере, где хранится база данных.
• Резервное копирование: Регулярное создание резервных копий базы данных и хранение их на защищенных носителях в разных местах. Это критически важно для восстановления данных после сбоев или атак.
• Использование надежного хостинга/сетевого расположения: Если Access-файл расположен в сети, убедиться, что сетевые ресурсы защищены.
• Настройка брандмауэра: Ограничение сетевого доступа к компьютеру, на котором хранится база данных.

4. Физические меры защиты:

• Системы контроля доступа: Ограничение физического доступа в помещения, где находятся компьютеры с ИС или её резервными копиями.
• Сигнализация, камеры наблюдения: Для предотвращения несанкционированного проникновения.
• Замки для носителей информации: Защита внешних жестких дисков или флеш-накопителей с резервными копиями.

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

При проектировании ИС «Учет персонала в театре» меры по обеспечению ИБ должны быть разумно обоснованы. Затраты на защиту ресурсов не должны превышать их стоимости, а меры безопасности не должны создавать излишнюю нагрузку на бизнес-процессы или персонал. Главное – достичь адекватного уровня защиты, соответствующего потенциальным рискам.

Документирование курсовой работы и руководство пользователя

Завершающий, но не менее важный этап в разработке информационной системы — это её документирование. Для курсовой работы по проектированию ИС, документирование не просто формальность, а ключевой элемент, демонстрирующий полноту понимания задачи, системный подход к её решению и способность к структурированному изложению материала. Как подробный чертеж объясняет инженеру каждую деталь конструкции, так и качественная документация позволяет понять логику, структуру и функционирование разработанной системы.

Структура курсовой работы по проектированию ИС

Курсовая работа представляет собой полноценный проект, описывающий все этапы создания информационной системы. Её структура должна быть логичной, последовательной и соответствовать академическим требованиям. Основные разделы курсовой работы по проектированию ИС «Учет персонала в театре» включают:

1. Введение:
   • Актуальность темы (например, проблемы ручного учета в театре).
   • Цель работы (например, разработка ИС учета персонала в Access).
   • Задачи работы (перечень конкретных шагов, которые будут выполнены).
   • Объект и предмет исследования.
   • Структура курсовой работы.
2. Анализ предметной области:
   • Общее описание деятельности театра, его структуры.
   • Детальный анализ текущих процессов учета персонала, выявление их недостатков.
   • Описание специфических бизнес-правил и особенностей учета персонала в театральном учреждении (актерские звания, спектакли, роли, контракты).
3. Формирование требований к ИС:
   • Классификация и детальное описание функциональных требований к системе (учет сотрудников, должностей, спектаклей, отчетность, операции).
   • Классификация и детализация нефункциональных требований (производительность, надежность, безопасность, удобство использования, масштабируемость) с указанием метрик.
4. Концептуальное проектирование ИС:
   • Описание методологии ER-моделирования.
   • Построение и подробное описание ER-диаграммы, включая все сущности, их атрибуты и типы связей.
5. Логическое проектирование ИС:
   • Преобразование ER-модели в реляционную структуру.
   • Описание процесса нормализации базы данных, объяснение 1НФ, 2НФ, 3НФ.
   • Представление и обоснование окончательной структуры реляционных таблиц с указанием первичных и внешних ключей.
6. Физическое проектирование и реализация ИС:
   • Выбор СУБД (Microsoft Access) и обоснование выбора.
   • Описание процесса создания таблиц в Access с указанием типов данных, свойств полей, первичных и внешних ключей.
   • Подробное описание установления связей между таблицами в Схеме данных Access.
   • Разработка и описание пользовательского интерфейса:
     • Описание основных форм (например, «Сотрудники», «Спектакли», «Контракты») с их структурой, использованием подформ, полей со списком.
     • Принципы удобства использования.
   • Разработка функциональных модулей:
     • Примеры и описание запросов (выборка, перекрестные, действия) для решения типовых задач.
     • Примеры и описание отчетов (штатное расписание, график отпусков, списки) для вывода информации.
   • Описание алгоритмов обработки данных (добавление, редактирование, удаление, поиск, фильтрация) и, при необходимости, фрагментов VBA-кода для автоматизации.
7. Информационная безопасность и защита данных:
   • Раскрытие принципов ИБ (конфиденциальность, целостность, доступность) согласно ГОСТ Р 53114-2008.
   • Анализ основных угроз ИБ для ИС учета персонала.
   • Описание организационных и технических мер обеспечения безопасности (разграничение прав доступа, парольная защита, резервное копирование, инструктаж) применительно к MS Access.
8. Заключение:
   • Подведение итогов проделанной работы.
   • Обобщение полученных результатов и подтверждение достижения поставленных целей и задач.
   • Отметить перспективы дальнейшего развития системы.
9. Список используемых источников:
   • Перечень литературы, стандартов и электронных ресурсов, использованных при написании работы.
10. Приложения:
    • Снимки экрана форм, запросов, отчетов.
    • Коды SQL-запросов, VBA-модулей.
    • ER-диаграмма, схемы таблиц.

Стандарты документирования и руководство пользователя

Качественная документация – это залог долговечности и поддерживаемости любой ИС. Она служит мостом между разработчиками, пользователями и будущими специалистами, которым предстоит работать с системой. В России стандарты документирования информационных систем регламентируются серией ГОСТ 34 «Информационные технологии. Комплекс стандартов на автоматизированные системы» и ГОСТ 19 «Единая система программной документации (ЕСПД)».

Принципы оформления документации:

• ГОСТ 34.201-2020 «Виды, комплектность и обозначения документов при создании автоматизированных систем»: Определяет, какие документы должны быть разработаны на различных стадиях ЖЦ ИС (техническое задание, эскизный проект, технический проект, рабочая документация). В контексте курсовой работы это означает, что каждый раздел должен соответствовать определенному типу документации.
• ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы»: Устанавливает требования к содержанию и оформлению Технического задания, что может быть использовано для структурирования раздела требований к ИС в курсовой работе.
• РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов»: Дополняет предыдущие стандарты, детализируя требования к содержанию различных видов проектных документов.

При написании курсовой работы важно придерживаться этих стандартов, описывая:

1. Назначение таблиц: Для каждой таблицы (например, Сотрудники, Спектакли) должно быть четко указано, какая информация в ней хранится и для каких целей она используется.
2. Назначение запросов: Описание каждого запроса, его функции (например, «Запрос для вывода списка сотрудников отдела кадров»).
3. Назначение форм: Детальное описание каждой формы, её элементов управления, их назначения и логики работы.
4. Назначение отчетов: Описание каждого отчета, его структуры, источника данных и информации, которую он предоставляет.

Руководство пользователя:

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

Содержание руководства пользователя для ИС «Учет персонала в театре» должно включать:

• Введение: Общее описание системы, её назначение и возможности.
• Начало работы:
  • Требования к системе (операционная система, Access).
  • Установка и запуск ИС.
  • Авторизация и вход в систему (логин/пароль).
• Интерфейс системы:
  • Обзор главного окна, навигационных панелей.
  • Описание основных элементов управления (кнопки, меню, вкладки).
• Работа с основными модулями:
  • Управление сотрудниками:
    • Добавление нового сотрудника (пошаговая инструкция).
    • Редактирование данных сотрудника.
    • Поиск и фильтрация сотрудников.
    • Удаление сотрудника (с предупреждениями).
  • Управление спектаклями и ролями:
    • Добавление нового спектакля.
    • Назначение актеров на роли.
  • Управление контрактами и оплатой:
    • Ввод и редактирование контрактов.
    • Начисление премий.
  • Работа с отпусками, образованием, воинским учетом и т.д.: Пошаговые инструкции для каждой функции.
• Формирование отчетов:
  • Как выбрать и запустить нужный отчет.
  • Как задать параметры отчета (период, отдел, должность).
  • Печать и экспорт отчетов.
• Вопросы и ответы: Ответы на часто задаваемые вопросы.
• Глоссарий: Объяснение используемых терминов.

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

Заключение

В рамках данной курсовой работы была успешно решена комплексная задача по проектированию и разработке информационной системы «Учет персонала в театре» на базе Microsoft Access. В ходе исследования были всесторонне проанализированы теоретические основы информационных систем, баз данных и их жизненного цикла, что заложило прочный методологический фундамент проекта.

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

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

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

Особое внимание было уделено вопросам информационной безопасности. Были рассмотрены основные принципы ИБ согласно ГОСТ Р 53114-2008, проанализированы потенциальные угрозы, включая инсайдерские, и предложены конкретные методы и средства защиты данных в условиях Access, в том числе детальное разграничение прав доступа для различных категорий пользователей.

Наконец, была представлена полная структура курсовой работы и подробные требования к документированию в соответствии с российскими ГОСТами, а также разработан план руководства пользователя, обеспечивающий простоту освоения системы конечными пользователями.
Таким образом, все поставленные цели и задачи курсовой работы были успешно достигнуты. Разработанная информационная система «Учет персонала в театре» на базе Microsoft Access представляет собой функциональное, логически обоснованное и документированное решение, которое способно значительно повысить эффективность работы кадровой службы театра.

Перспективы дальнейшего развития системы:

1. Интеграция с другими системами: Возможность обмена данными с бухгалтерской системой для автоматизации расчета заработной платы.
2. Web-интерфе��с: Переход на клиент-серверную архитектуру (например, с использованием SQL Server или других СУБД) и разработка веб-интерфейса для обеспечения удаленного доступа и повышения масштабируемости.
3. Мобильное приложение: Разработка мобильного приложения для руководителей или актеров для быстрого доступа к расписаниям или личной информации.
4. Расширенная аналитика: Внедрение средств бизнес-аналитики для глубокого анализа кадровых данных, прогнозирования текучести кадров и оптимизации штатного расписания.
5. Система оповещений: Реализация автоматических уведомлений о днях рождения, окончании контрактов или отпусков.

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

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

1. Глушаков С. В., Сурядный А. С., Шумилов М. И. Microsoft Access 2007. М.: АСТ, 2008. 448 с.
2. Карпова Т. Базы данных: модели, разработка, реализация. СПб.: Питер, 2001. 304 с.
3. Кошелев В. Е. Access 2007. Эффективное использование. СПб.: Бином-Пресс, 2009. 590 с.
4. Кронан Джон, Сандберг Бобби Microsoft Access 2007. М.: НТ Пресс, 2009. 384 с.
5. Лори Ульрих Фуллер, Кук К. Access 2010 для чайников. СПб.: Вильямс, 2011. 384 с.
6. Мак-Дональд Мэтью Access 2007. СПб.: БХВ-Петербург, 2007. 784 с.
7. Сергеев А. Access 2007. СПб.: Питер, 2008. 176 с.
8. Смирнова О. В. Access 2007 на практике. М.: Феникс, 2009. 160 с.
9. Шумаков П.В., Фаронов В.В. Руководство разработчика баз данных. М.: Нолидж, 2000. 635 с.
10. Базы данных. Кафедра вычислительных систем и программирования СПбГЭУ. URL: https://se.unecon.ru/wp-content/uploads/2019/07/%D0%91%D0%B0%D0%B7%D1%8B-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85.pdf (дата обращения: 27.10.2025).
11. Базы данных и СУБД: Основные понятия, модели и объекты БД. URL: https://baza.spbgasu.ru/files/attachments/b282fe6b-4f9e-4c74-8b63-d1df52345e6c/%D0%91%D0%B0%D0%B7%D1%8B%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85%20%D0%B8%20%D0%A1%D0%A3%D0%91%D0%94.pdf (дата обращения: 27.10.2025).
12. Лекция 1 Информационные системы и их классификации. URL: http://www.kgau.ru/distance/mf_01/is_01/01/01.pdf (дата обращения: 27.10.2025).
13. Лекция 1 Тема: Жизненный цикл ИС Цель. URL: https://op.ncfu.ru/pluginfile.php/334255/mod_resource/content/1/%D0%9B%D0%B5%D0%BA%D1%86%D0%B8%D1%8F%202.%20%D0%96%D0%B8%D0%B7%D0%BD%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9%20%D1%86%D0%B8%D0%BA%D0%BB%20%D0%98%D0%A1.pdf (дата обращения: 27.10.2025).
14. Лекция № 7. Базы данных и СУБД. URL: https://www.mgri.ru/upload/iblock/9f7/9f7278d6b997233c042211f440d165f1.pdf (дата обращения: 27.10.2025).
15. Системы управления базами данных. НВГУ. URL: https://www.nvsu.ru/files/izdatelstvo/mamedli.pdf (дата обращения: 27.10.2025).
16. Выпускная квалификационная работа (бакалаврская работа). Тольяттинский государственный университет. URL: https://www.tltsu.ru/upload/iblock/a3b/a3bbd908e2b85149959e4b7875952f40.pdf (дата обращения: 27.10.2025).
17. СУБД: что это, виды, структура, функции — где и как используются системы управления базами данных, примеры. Яндекс Практикум. URL: https://practicum.yandex.ru/blog/chto-takoe-subd/ (дата обращения: 27.10.2025).
18. Абдуллина В. З. Базы данных в информационных системах. КазаНТУ, 2015. URL: https://elib.kstu.kz/files/books/bazy_dannykh_v_informatsionnykh_sistemakh_abdullina_v.z._kazntu_2015.pdf (дата обращения: 27.10.2025).
19. Бурцева И. В. Информационные системы. Тамбов: ТГТУ, 2009. URL: https://www.tstu.ru/book/elib/pdf/2009/burtseva.pdf (дата обращения: 27.10.2025).
20. Информационные системы. Издательский центр «Академия». URL: https://www.academbook.ru/upload/iblock/d76/d768131557d19c1186e8851dd43c7b2e.pdf (дата обращения: 27.10.2025).
21. Разработка системы кадрового учета. КиберЛенинка. URL: https://cyberleninka.ru/article/n/razrabotka-sistemy-kadrovogo-ucheta (дата обращения: 27.10.2025).
22. Введение в базы данных. URL: https://e.lanbook.com/img/content/pdf/2012/10/3740.pdf (дата обращения: 27.10.2025).
23. Информационные системы. Учебник. СФУ, 2011. URL: http://edu.sfu-kras.ru/sites/edu.sfu-kras.ru/files/manual/uchebnik-informatsionnye-sistemy.pdf (дата обращения: 27.10.2025).
24. Принципы создания информационных систем. СтудИзба. URL: https://studizba.com/lectures/informatika/kompyuternye-tehnologii/207-principy-sozdaniya-informacionnyh-sistem.html (дата обращения: 27.10.2025).
25. Паклина К. А. Проектирование автоматизированной информационной системы «Отдела кадров». Челябинск, 2021. URL: https://elib.cspu.ru/xmlui/bitstream/handle/123456789/2712/%D0%9A%D1%83%D1%80%D1%81%D0%BE%D0%B2%D0%B0%D1%8F%20%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0_%D0%9F%D0%B0%D0%BA%D0%BB%D0%B8%D0%BD%D0%B0%20%D0%9A%D1%81%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B5%D0%B5%D0%B2%D0%BD%D0%B0.pdf?sequence=1&isAllowed=y (дата обращения: 27.10.2025).
26. Базы данных: учебник для студ. учреждений высшего проф. образования. М.: Академия, 2014. URL: https://elibrary.ru/item.asp?id=23348006 (дата обращения: 27.10.2025).
27. Пояснительная записка. URL: https://se.sfedu.ru/wp-content/uploads/2021/05/poyasnitelnaya_zapiska.doc (дата обращения: 27.10.2025).
28. Принципы проектирования программ и их отражение в спецификации на доработку ERP-системы. Habr, 2023. URL: https://habr.com/ru/companies/sberinftech/articles/750436/ (дата обращения: 27.10.2025).
29. Методические рекомендации по выполнению курсовых работ по МДК 01.02. URL: https://spo.ranepa.ru/images/spo/sveden/education/metod/Metodicheskie_rekomendacii_po_vipolneniyu_kursovyh_rabot_po_MDK_01.02.pdf (дата обращения: 27.10.2025).
30. Разграничение прав доступа и многопользовательская работа в Access 2010, 2013. URL: https://access.usue.ru/multiuser/ (дата обращения: 27.10.2025).
31. Разделение прав доступа. MS Access. Киберфорум. URL: https://www.cyberforum.ru/access/thread1387600.html (дата обращения: 27.10.2025).
32. Access для HR-а: создаем базу данных персонала. Директор по персоналу. URL: https://www.hr-director.ru/article/65328-microsoft-access-dlya-hr-a-sozdaem-bazu-dannyh-personala (дата обращения: 27.10.2025).
33. Создание запроса, формы или отчета в Access. Служба поддержки Майкрософт. URL: https://support.microsoft.com/ru-ru/office/%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%B0-%D1%84%D0%BE%D1%80%D0%BC%D1%8B-%D0%B8%D0%BB%D0%B8-%D0%BE%D1%82%D1%87%D0%B5%D1%82%D0%B0-%D0%B2-access-53896dfa-251f-4952-b132-4740e53a253a (дата обращения: 27.10.2025).
34. Нормализация данных. URL: http://e-lib.gasu.ru/pc/metod/DB_metod/2_2_6.htm (дата обращения: 27.10.2025).
35. ОП.08. Основы проектирования баз данных. Методические указания по выполнению. Индустриальный институт. URL: https://kgeu.ru/files/faculties/iei/kaf_is/doc/op_08_osnovi_proektirovaniya_baz_dannih_metodicheskie_ukazaniya_po_v.pdf (дата обращения: 27.10.2025).
36. Microsoft 365 Access. Progresia. URL: https://progresia.ru/microsoft-365/access/ (дата обращения: 27.10.2025).
37. Нормализация баз данных. Фестиваль педагогических идей «Открытый урок». Первое сентября. URL: https://urok.1sept.ru/articles/588856 (дата обращения: 27.10.2025).
38. Описание мер по обеспечению информационной безопасности на предприятии. SearchInform. URL: https://www.searchinform.ru/infosecurity/bases/measures/ (дата обращения: 27.10.2025).
39. Нормализация СУБД: пример базы данных 1NF, 2NF, 3NF. Guru99. URL: https://www.guru99.com/database-normalization-1nf-2nf-3nf.html (дата обращения: 27.10.2025).
40. Разработка базы данных и серверной части информационной системы для предметной области ‘Театр’. Библиофонд. URL: https://www.bibliofond.ru/view.aspx?id=808381 (дата обращения: 27.10.2025).
41. Кадровый учет в MS Access 2016. YouTube. URL: https://www.youtube.com/watch?v=k_jH5U5_u1s (дата обращения: 27.10.2025).
42. Лабораторная работа № 1. Создание таблиц, запросов, форм, отчетов. Цель. URL: https://vuzlit.ru/872428/sozdanie_tablic_zaprosov_form_otchetov (дата обращения: 27.10.2025).
43. ER-диаграмма: визуализация связей и сущностей. KursHub. URL: https://kurshub.ru/er-diagramma/ (дата обращения: 27.10.2025).
44. MS Access – один из лучших инструментов для обработки данных. URL: https://cpas.ru/articles/ms-access—odin-iz-luchshih-instrumentov-dlya-obrabotki-dannyh/ (дата обращения: 27.10.2025).
45. Обеспечение информационной безопасности организации. Falcongaze. URL: https://falcongaze.com/ru/about-company/blog/obespechenie-informacionnoy-bezopasnosti-organizacii-osnovy-celi-zadachi-principy-etapy-i-mery/ (дата обращения: 27.10.2025).
46. Практическое занятие № 23 и № 24. Создание форм и отчётов. Фильтрация. URL: https://www.hse.ru/data/2012/10/01/1258679901/%D0%9F%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F%20%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%20%E2%84%9623,%2024.pdf (дата обращения: 27.10.2025).
47. Требования к информационной безопасности. SearchInform. URL: https://www.searchinform.ru/infosecurity/bases/requirements/ (дата обращения: 27.10.2025).
48. Нефункциональные требования к системе: что такое, примеры, что входит. Kaiten. URL: https://kaiten.ru/blog/nefunkcionalnye-trebovaniya/ (дата обращения: 27.10.2025).
49. Обеспечение информационной безопасности в компании: основы и методы поддержания кибербезопасности на предприятии. Kickidler. URL: https://www.kickidler.com/ru/blog/informatsionnaya-bezopasnost-predpriyatiya/ (дата обращения: 27.10.2025).
50. Методические рекомендации по практическим работам на тему «Работа с базами данных MS Access». УчМет. URL: https://uchmet.ru/library/material/183181/ (дата обращения: 27.10.2025).
51. Нормальные формы БД — что важно знать системным аналитикам. YouTube. URL: https://www.youtube.com/watch?v=F3_a2g060jU (дата обращения: 27.10.2025).
52. Создание формы в Access. Служба поддержки Майкрософт. URL: https://support.microsoft.com/ru-ru/office/%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D1%84%D0%BE%D1%80%D0%BC%D1%8B-%D0%B2-access-b68e55ac-5d15-4375-961f-f42f840f9316 (дата обращения: 27.10.2025).
53. Проектирование реляционной базы данных. Высшая школа экономики. URL: https://www.hse.ru/data/2013/05/23/1297594539/%D0%94%D0%97-2_%D0%91%D0%94.pdf (дата обращения: 27.10.2025).
54. Нормализация данных: что это и зачем их нормировать — правила нормирования данных в БД. Яндекс Практикум. URL: https://practicum.yandex.ru/blog/chto-takoe-normalizatsiya-dannyh/ (дата обращения: 27.10.2025).
55. Информационная безопасность предприятия: что это такое и зачем она нужна, какие способы защиты данных существуют и как их внедрить в компании. Дом.ру Бизнес. URL: https://business.dom.ru/journal/it/informacionnaya-bezopasnost-predpriyatiya (дата обращения: 27.10.2025).
56. Реляционная база данных. Проектирование реляционных баз данных. Otus. URL: https://otus.ru/journal/relyacionnaya-baza-dannyh-proektirovanie-relyacionnyh-baz-dannyh/ (дата обращения: 27.10.2025).
57. Что такое нефункциональные требования: типы, примеры и подходы. Visure Solutions. URL: https://visuresolutions.com/ru/blog/non-functional-requirements/ (дата обращения: 27.10.2025).
58. ER диаграмма системы бухгалтерского учета. Creately. URL: https://creately.com/ru/templates/er-diagrams/er-diagram-of-accounting-system/ (дата обращения: 27.10.2025).
59. Что такое ER-диаграмма и как ее создать? Lucidchart. URL: https://www.lucidchart.com/pages/ru/chto-takoe-er-diagramma-i-kak-ee-sozdat (дата обращения: 27.10.2025).
60. Лабораторная работа 1. Проектирование базы данных. Цель: спроектировать. СФУ. URL: http://edu.sfu-kras.ru/sites/edu.sfu-kras.ru/files/manual/lab-rab-bd.pdf (дата обращения: 27.10.2025).
61. Создание запросов и отчетов в MS’Access. YouTube. URL: https://www.youtube.com/watch?v=1FvS8K72b4w (дата обращения: 27.10.2025).
62. ER-диаграммы: как создать, примеры построения модели. Бизнес-секреты. Tinkoff, 2024. URL: https://secrets.tinkoff.ru/biznes-s-nulya/er-diagrammy/ (дата обращения: 27.10.2025).
63. Функциональные и нефункциональные требования (с примерами). Visure Solutions. URL: https://visuresolutions.com/ru/blog/functional-and-non-functional-requirements/ (дата обращения: 27.10.2025).
64. Написание курсовой работы по Проектированию информационных систем. ВсеСдал. URL: https://vsesdal.com/kursovaya/napisanie_kursovoj_raboty_po_proektirovaniyu_informacionnyh_sistem (дата обращения: 27.10.2025).
65. Проектирование и дизайн информационных систем (СПО, курс 1). Roweb.online. URL: https://roweb.online/courses/proektirovanie-i-dizajn-informacionnyh-sistem-spo-kurs-1 (дата обращения: 27.10.2025).
66. База данных Access Отдел кадров предприятия. Accesshelp.ru. URL: https://accesshelp.ru/baza-dannyh-access-otdel-kadrov-predpriyatiya/ (дата обращения: 27.10.2025).
67. ER-диаграммы: что это, применение, нотации — как создать ER-диаграмму сущность-связь, примеры. Яндекс Практикум, 2023. URL: https://practicum.yandex.ru/blog/er-diagrammy/ (дата обращения: 27.10.2025).
68. Методические материалы по работе в программе Microsoft Access. Общее понятие. Vuzlit.ru. URL: https://vuzlit.ru/1329606/metodicheskie_materialy_rabote_programme_microsoft_access_obschee (дата обращения: 27.10.2025).
69. Обучение проектированию Информационных Систем. Часть 1. «Введение в предмет…». YouTube. URL: https://www.youtube.com/watch?v=6P64f_lEa-g (дата обращения: 27.10.2025).