В условиях цифровизации и активного развития информационных технологий автоматизация процессов управления становится неотъемлемой частью деятельности организаций различных сфер. Особенно актуальной данная тенденция является для предприятий жилищно-коммунального хозяйства, в которых ежедневно обрабатываются значительные объемы информации, связанной с управлением жилым фондом, учетом объектов недвижимости, обращениями жильцов, предоставлением услуг и контролем выполнения работ. Эффективность функционирования таких организаций во многом определяется качеством хранения, обработки и анализа данных, что делает использование современных систем управления базами данных необходимым условием устойчивого развития.
Управляющие компании, осуществляющие деятельность в сфере обслуживания многоквартирных домов, сталкиваются с проблемами разрозненного хранения информации, высокой долей ручной обработки данных и отсутствием единого информационного пространства. Это приводит к увеличению времени обработки заявок, риску возникновения ошибок, дублированию данных и снижению прозрачности управленческих процессов. Внедрение автоматизированной системы управления на основе грамотно спроектированной базы данных позволяет структурировать информацию, повысить надежность хранения данных и обеспечить оперативный доступ к актуальной информации для всех заинтересованных пользователей.
Актуальность выбранной темы обусловлена необходимостью разработки и внедрения эффективных инструментов управления данными в деятельности управляющих компаний. Современные системы управления базами данных позволяют не только хранить информацию, но и автоматизировать ключевые бизнес-процессы, обеспечивать контроль целостности данных, реализовывать механизмы разграничения доступа и повышать уровень информационной безопасности. В условиях роста объемов данных и усложнения структуры управляемых объектов роль базы данных как центрального элемента информационной системы существенно возрастает.
Практическая значимость данной работы заключается в возможности использования разработанной базы данных в качестве основы для автоматизированной системы управления деятельностью управляющей компании ООО «КомфортДом». Результаты проектирования могут быть использованы для учета жилых домов, помещений, жильцов, обращений и заявок, а также для организации хранения и обработки информации о предоставляемых услугах. Разработанная структура базы данных может быть адаптирована и расширена с учетом специфики деятельности аналогичных организаций, что повышает универсальность и прикладную ценность выполненной работы.
Целью курсовой работы является разработка базы данных для автоматизированной системы управления деятельностью управляющей компании ООО «КомфортДом», обеспечивающей эффективное хранение, обработку и управление информацией, необходимой для принятия управленческих решений.
Для достижения поставленной цели в работе предполагается решение следующих задач:
– провести анализ предметной области и определить основные информационные объекты и процессы, характерные для деятельности управляющей компании;
– разработать инфологическую модель базы данных с определением сущностей и связей между ними;
– выполнить построение логической модели базы данных с учетом требований нормализации;
– разработать физическую модель базы данных с учетом выбранной системы управления базами данных;
– спроектировать основные SQL-запросы для работы с данными;
– реализовать элементы серверной логики базы данных с использованием хранимых процедур, функций и триггеров;
– рассмотреть основные аспекты администрирования базы данных, включая вопросы безопасности и управления доступом.
Объектом исследования в данной курсовой работе является деятельность управляющей компании ООО «КомфортДом» в части управления жилым фондом и обработки информационных потоков.
Предметом исследования являются методы и средства проектирования, управления и автоматизации баз данных, применяемые при создании автоматизированной системы управления для управляющей компании.
В процессе выполнения курсовой работы используются методы анализа предметной области, структурного и логического проектирования баз данных, методы нормализации данных, а также практические методы разработки SQL-запросов и серверных механизмов обработки данных. В качестве инструментальных средств применяются современные системы управления базами данных и стандартные средства языка SQL.
Таким образом, выбранная тема курсовой работы соответствует современным требованиям к управлению и автоматизации баз данных, имеет практическую направленность и позволяет сформировать навыки проектирования информационных систем, ориентированных на решение реальных задач управления в сфере жилищно-коммунального хозяйства.
1 Проектирование базы данных
Проектирование базы данных является ключевым этапом создания автоматизированной системы управления, так как именно на данном этапе формируется структура хранения данных, определяются связи между объектами предметной области и закладываются основы дальнейшей автоматизации процессов. Корректно спроектированная база данных обеспечивает целостность, непротиворечивость и актуальность информации, а также позволяет эффективно реализовать функциональные возможности информационной системы.
В рамках данной курсовой работы проектирование базы данных выполняется для автоматизированной системы управления деятельностью управляющей компании ООО «КомфортДом», осуществляющей управление и эксплуатацию жилого фонда.
1.1 Анализ предметной области и деятельности ООО «КомфортДом»
ООО «КомфортДом» является управляющей компанией, основной деятельностью которой является управление многоквартирными жилыми домами, организация технического обслуживания общего имущества, прием и обработка обращений жильцов, а также контроль выполнения работ подрядными организациями. В процессе своей деятельности компания взаимодействует с большим количеством объектов и участников, что формирует значительные информационные потоки.
К основным объектам предметной области относятся жилые дома, входящие в управление компании, помещения в составе домов, жильцы, заявки и обращения, услуги, выполняемые работы, сотрудники управляющей компании и подрядные организации. Между указанными объектами существуют устойчивые информационные связи, отражающие реальные процессы управления жилым фондом.
Жилые дома характеризуются адресом, количеством этажей, годом постройки и состоянием инженерных систем. Каждый дом включает в себя множество помещений, которые могут быть жилыми или нежилыми. С помещениями связаны жильцы, являющиеся собственниками или нанимателями, которые могут формировать обращения и заявки в управляющую компанию.
Заявки жильцов представляют собой обращения, связанные с техническими неисправностями, вопросами обслуживания или предоставления коммунальных услуг. Каждая заявка имеет дату создания, описание проблемы, текущий статус и ответственное лицо. В процессе обработки заявок формируются данные о выполненных работах и затраченном времени, что также подлежит учету.
Информационные потоки в деятельности ООО «КомфортДом» включают поступление заявок от жильцов, распределение работ между сотрудниками и подрядчиками, фиксацию результатов выполненных работ и формирование отчетной информации. Все перечисленные данные должны храниться централизованно и быть доступны для анализа и управления, что обуславливает необходимость создания автоматизированной базы данных.
Таким образом, предметная область характеризуется большим количеством взаимосвязанных сущностей и регулярным обновлением данных, что требует использования структурированной и надежной модели хранения информации.
1.2 Инфологическое проектирование базы данных
Инфологическое проектирование базы данных направлено на формирование концептуальной модели предметной области, независимой от конкретной системы управления базами данных. На данном этапе выполняется выделение сущностей, определение их атрибутов и установление связей между ними.
В результате анализа предметной области был сформирован следующий перечень основных сущностей:
– Дом
– Помещение
– Жилец
– Заявка
– Услуга
– Сотрудник
– Подрядная организация
Каждая из выделенных сущностей отражает реальный объект или участника процессов управления жилым фондом и содержит информацию, необходимую для работы автоматизированной системы.
Характеристика основных сущностей приведена в таблице 1.
Таблица 1
Основные сущности предметной области
Для каждой сущности был сформирован набор атрибутов. В таблице 2 представлена спецификация атрибутов сущности «Заявка».
Таблица 2
Спецификация атрибутов сущности «Заявка»
Для каждой сущности был выбран первичный ключ, обеспечивающий однозначную идентификацию экземпляров. В качестве первичных ключей используются уникальные идентификаторы числового типа.
Между сущностями установлены следующие типы связей:
– между сущностями «Дом» и «Помещение» реализована связь «один-ко-многим», так как одному дому соответствует несколько помещений;
– между сущностями «Помещение» и «Жилец» реализована связь «один-ко-многим»;
– между сущностями «Жилец» и «Заявка» реализована связь «один-ко-многим»;
– между сущностями «Заявка» и «Сотрудник» реализована связь «один-ко-многим».
Интегрированное представление предметной области отражено в инфологической модели базы данных, представленной на рисунке 1.
Рисунок 1 – Инфологическая модель базы данных управляющей компании ООО «КомфортДом»
1.3 Построение логической модели базы данных
Логическое проектирование базы данных направлено на преобразование инфологической модели в реляционную модель, пригодную для реализации в среде выбранной системы управления базами данных. На данном этапе каждая сущность представляется в виде таблицы, а связи между сущностями реализуются с использованием первичных и внешних ключей.
В результате отображения инфологической модели были сформированы отношения, соответствующие сущностям предметной области. Для каждого отношения определен набор атрибутов и ключевых полей. Связи типа «один-ко-многим» реализованы путем включения внешних ключей в подчиненные таблицы.
Полученные отношения были проанализированы на соответствие требованиям нормализации. В процессе анализа установлено, что все таблицы приведены к третьей нормальной форме, что исключает избыточность данных и обеспечивает логическую целостность базы данных.
Структура логической модели базы данных представлена на рисунке 2.
Рисунок 2 – Логическая модель базы данных ООО «КомфортДом»
1.4 Построение физической модели базы данных
Физическое проектирование базы данных выполняется на основе логической модели и учитывает особенности конкретной системы управления базами данных. В рамках данной работы физическая модель разрабатывается с использованием реляционной СУБД и языка SQL.
Проектирование физической структуры данных включает определение типов данных для каждого поля таблиц, настройку ограничений целостности, создание первичных и внешних ключей, а также установку индексов для повышения производительности запросов.
Пример структуры таблицы «Дом» приведен в таблице 3.
Таблица 3
Структура таблицы «Дом»
Физическая модель обеспечивает корректное хранение данных, поддержку ссылочной целостности и возможность расширения базы данных при увеличении объема информации или изменении требований к системе.
Выводы по разделу
В результате выполнения первого раздела курсовой работы было осуществлено проектирование базы данных автоматизированной системы управления деятельностью управляющей компании ООО «КомфортДом». На данном этапе была сформирована теоретическая и структурная основа всей разрабатываемой информационной системы.
В ходе анализа предметной области была изучена специфика деятельности управляющей компании, определены основные объекты управления и характерные для них информационные потоки. Выявленные сущности и связи между ними позволили получить целостное представление о процессах управления жилым фондом, обработки обращений жильцов и взаимодействия сотрудников с информационными ресурсами. Проведенный анализ подтвердил необходимость использования централизованной базы данных для повышения эффективности управления и сокращения доли ручной обработки информации.
Инфологическое проектирование позволило формализовать предметную область в виде системы взаимосвязанных сущностей с определенными атрибутами и типами связей. Разработанная инфологическая модель обеспечила наглядное и логически согласованное представление данных, что снизило риск появления противоречий и избыточности информации на последующих этапах проектирования.
На этапе логического проектирования была выполнена трансформация инфологической модели в реляционную структуру. Сформированные таблицы и связи между ними были приведены к третьей нормальной форме, что обеспечило логическую целостность базы данных и оптимальные условия для хранения и обработки информации. Выбранная структура базы данных позволяет эффективно реализовать основные операции работы с данными и обеспечивает возможность дальнейшего расширения системы.
Физическое проектирование базы данных было выполнено с учетом особенностей используемой системы управления базами данных Microsoft SQL Server. Определение типов данных, ограничений целостности и индексов создало условия для надежного хранения информации и повышения производительности при выполнении запросов. Разработанная физическая модель соответствует требованиям масштабируемости и может быть адаптирована при увеличении объема данных.
Таким образом, в рамках первого раздела были последовательно выполнены все этапы проектирования базы данных — от анализа предметной области до построения физической модели. Полученные результаты послужили основой для дальнейшей разработки SQL-запросов, серверной логики и механизмов администрирования базы данных, рассмотренных в последующих разделах курсовой работы.
2 Проектирование SQL-запросов
Проектирование SQL-запросов является важным этапом разработки базы данных автоматизированной системы управления, так как именно запросы обеспечивают извлечение, обработку и представление данных в форме, удобной для пользователей и прикладных компонентов системы. В рамках данной курсовой работы база данных реализуется с использованием Microsoft SQL Server, что позволяет применять стандартные средства языка SQL, а также механизмы оптимизации и индексирования данных.
Анализ предметной области деятельности ООО «КомфортДом» позволил выделить основные операции, выполняемые над данными в процессе управления жилым фондом. К таким операциям относятся получение информации о домах и помещениях, учет жильцов, обработка заявок, контроль статусов обращений, формирование отчетных данных и обновление информации о выполненных работах. Реализация указанных операций осуществляется с помощью SQL-запросов различных типов.
В процессе проектирования были разработаны запросы на выборку данных, запросы с использованием агрегатных функций и группировки, запросы с вычисляемыми полями, запросы с объединением данных из нескольких таблиц, а также запросы на добавление, обновление и удаление данных. Общее количество реализованных запросов превышает минимально требуемое и охватывает основные сценарии работы с базой данных.
Пример простого запроса на выборку данных приведен для получения списка всех домов, находящихся в управлении компании. Данный запрос используется для формирования справочной информации и выбора объекта управления:
SELECT id_дома, адрес, этажность, год_постройки
FROM Дом;
Для получения информации о заявках конкретного жильца используется запрос с условием фильтрации данных:
SELECT id_заявки, дата_создания, описание, статус
FROM Заявка
WHERE id_жильца = 5;
Важную роль в работе управляющей компании играет анализ обращений жильцов, поэтому были реализованы запросы с агрегатными функциями и группировкой данных. Например, запрос для определения количества заявок по каждому дому позволяет оценить проблемные объекты жилого фонда:
SELECT d.адрес, COUNT(z.id_заявки) AS количество_заявок
FROM Дом d
JOIN Помещение p ON d.id_дома = p.id_дома
JOIN Жилец j ON p.id_помещения = j.id_помещения
JOIN Заявка z ON j.id_жильца = z.id_жильца
GROUP BY d.адрес;
Для формирования аналитической информации используются запросы с вычисляемыми полями. Например, расчет срока обработки заявки на основе даты создания и даты закрытия:
SELECT id_заявки,
DATEDIFF(day, дата_создания, дата_закрытия) AS срок_обработки
FROM Заявка
WHERE статус = 'Закрыта';
Запросы с объединением данных из нескольких таблиц позволяют получать комплексную информацию, необходимую для управленческих решений. Примером является запрос, отображающий сведения о заявках, жильцах и ответственных сотрудниках:
SELECT z.id_заявки, z.дата_создания, j.ФИО, s.ФИО AS сотрудник, z.статус
FROM Заявка z
JOIN Жилец j ON z.id_жильца = j.id_жильца
JOIN Сотрудник s ON z.id_сотрудника = s.id_сотрудника;
Помимо запросов на выборку данных, в системе реализованы запросы на добавление, обновление и удаление данных, обеспечивающие корректную работу автоматизированной системы управления. Пример запроса на добавление новой заявки приведен ниже:
INSERT INTO Заявка (дата_создания, описание, статус, id_жильца)
VALUES (GETDATE(), 'Неисправность освещения в подъезде', 'Новая', 7);
Для изменения статуса заявки используется запрос на обновление данных:
UPDATE Заявка
SET статус = 'В работе'
WHERE id_заявки = 12;
Удаление устаревших или ошибочно введенных данных осуществляется с помощью запроса на удаление:
DELETE FROM Заявка
WHERE id_заявки = 25;
С целью повышения производительности выполнения запросов в базе данных были созданы индексы по наиболее часто используемым полям. В таблице 4 приведен перечень созданных индексов.
Таблица 4 – Индексы базы данных
Создание индексов позволило сократить время выполнения запросов на выборку и агрегацию данных, что особенно важно при увеличении объема информации и росте числа пользователей системы.
Таким образом, в рамках данного раздела были спроектированы и реализованы SQL-запросы различных типов, обеспечивающие полный цикл работы с данными автоматизированной системы управления ООО «КомфортДом». Разработанные запросы охватывают основные операции обработки информации и создают основу для реализации серверной логики базы данных, рассматриваемой в следующем разделе.
Выводы по разделу
В рамках второго раздела курсовой работы было выполнено проектирование и реализация SQL-запросов для базы данных автоматизированной системы управления ООО «КомфортДом». Разработанные запросы обеспечивают выполнение основных операций обработки данных, необходимых для функционирования системы управления жилым фондом.
В процессе работы были реализованы запросы различных типов, включая запросы на выборку данных, запросы с условиями фильтрации и сортировки, агрегатные запросы с использованием функций группировки, а также запросы с вычисляемыми полями. Реализация запросов с объединением данных из нескольких таблиц позволила получать комплексную информацию, отражающую взаимосвязь объектов предметной области, и обеспечила формирование аналитических сведений, необходимых для принятия управленческих решений.
Особое внимание было уделено запросам на добавление, обновление и удаление данных, которые обеспечивают актуальность информации в базе данных и поддерживают корректную работу автоматизированной системы управления. Разработка данных запросов позволила реализовать полный цикл работы с данными и обеспечить поддержку основных бизнес-процессов управляющей компании.
Для повышения производительности выполнения запросов были созданы индексы по наиболее часто используемым полям. Анализ работы запросов показал, что использование индексов существенно снижает время выполнения операций выборки и агрегирования данных, особенно при увеличении количества записей в таблицах. При этом было установлено, что сложные запросы с множественными соединениями таблиц требуют дополнительной оптимизации при дальнейшем росте объема данных.
Таким образом, результаты второго раздела подтвердили эффективность разработанных SQL-запросов и выбранных методов оптимизации. Созданные запросы обеспечивают надежную и производительную работу базы данных и формируют основу для реализации серверной логики и механизмов автоматизации, рассмотренных в следующем разделе курсовой работы.
3 Проектирование серверного приложения: хранимые процедуры, функции и триггеры
Серверное приложение базы данных является важнейшим компонентом автоматизированной системы управления, так как именно на серверном уровне реализуется основная бизнес-логика обработки данных. Использование хранимых процедур, функций и триггеров позволяет повысить производительность системы, обеспечить целостность данных и сократить объем логики, реализуемой на стороне клиентских приложений.
В рамках данной курсовой работы серверное приложение базы данных ООО «КомфортДом» реализуется средствами Microsoft SQL Server с использованием языка Transact-SQL. Разработанные серверные объекты обеспечивают автоматизацию ключевых операций, связанных с обработкой заявок, управлением данными о жильцах и контролем изменений в базе данных.
Общая схема взаимодействия объектов серверного приложения представлена на рисунке 3.
Рисунок 3 – Схема взаимодействия хранимых процедур, функций и триггеров
Хранимые процедуры используются для выполнения повторяющихся операций обработки данных и позволяют инкапсулировать сложную логику в серверной части базы данных.
Хранимая процедура 1 – добавление новой заявки
Данная процедура предназначена для добавления новой заявки от жильца и выполняется в рамках транзакции, что обеспечивает целостность данных.
CREATE PROCEDURE sp_AddRequest
@id_жильца INT,
@описание NVARCHAR(500)
AS
BEGIN
BEGIN TRANSACTION;
INSERT INTO Заявка (дата_создания, описание, статус, id_жильца)
VALUES (GETDATE(), @описание, 'Новая', @id_жильца);
COMMIT TRANSACTION;
END;
Пример запуска процедуры:
EXEC sp_AddRequest 5, 'Неисправность отопления';
Результатом выполнения процедуры является добавление новой записи в таблицу «Заявка».
Хранимая процедура 2 – изменение статуса заявки
Процедура используется для обновления текущего статуса заявки и также реализует механизм транзакций.
CREATE PROCEDURE sp_UpdateRequestStatus
@id_заявки INT,
@статус NVARCHAR(50)
AS
BEGIN
BEGIN TRANSACTION;
UPDATE Заявка
SET статус = @статус
WHERE id_заявки = @id_заявки;
COMMIT TRANSACTION;
END;
Пример запуска:
EXEC sp_UpdateRequestStatus 12, 'В работе';
Хранимая процедура 3 – закрепление заявки за сотрудником
Процедура предназначена для назначения ответственного сотрудника за обработку заявки.
CREATE PROCEDURE sp_AssignEmployee
@id_заявки INT,
@id_сотрудника INT
AS
BEGIN
BEGIN TRANSACTION;
UPDATE Заявка
SET id_сотрудника = @id_сотрудника
WHERE id_заявки = @id_заявки;
COMMIT TRANSACTION;
END;
Хранимая процедура 4 – получение списка заявок по статусу
Процедура используется для формирования выборки заявок с заданным статусом.
CREATE PROCEDURE sp_GetRequestsByStatus
@статус NVARCHAR(50)
AS
BEGIN
SELECT id_заявки, дата_создания, описание
FROM Заявка
WHERE статус = @статус;
END;
Хранимая процедура 5 – удаление закрытых заявок
Процедура предназначена для очистки базы данных от устаревших данных.
CREATE PROCEDURE sp_DeleteClosedRequests
AS
BEGIN
DELETE FROM Заявка
WHERE статус = 'Закрыта';
END;
Функции используются для выполнения вычислений и возврата значения, которое может применяться в SQL-запросах.
Функция расчета количества заявок жильца
CREATE FUNCTION fn_RequestCountByResident (@id_жильца INT)
RETURNS INT
AS
BEGIN
DECLARE @count INT;
SELECT @count = COUNT(*)
FROM Заявка
WHERE id_жильца = @id_жильца;
RETURN @count;
END;
Пример использования функции:
SELECT dbo.fn_RequestCountByResident(5) AS количество_заявок;
Триггеры используются для автоматического выполнения действий при возникновении определенных событий в базе данных. В отличие от хранимых процедур, триггеры запускаются исключительно системой управления базами данных.
Триггер 1 – автоматическая установка даты закрытия заявки
CREATE TRIGGER trg_SetCloseDate
ON Заявка
AFTER UPDATE
AS
BEGIN
IF UPDATE(статус)
BEGIN
UPDATE Заявка
SET дата_закрытия = GETDATE()
WHERE id_заявки IN (
SELECT id_заявки
FROM inserted
WHERE статус = 'Закрыта'
);
END
END;
Триггер 2 – контроль удаления заявок
Данный триггер запрещает удаление заявок, находящихся в работе.
CREATE TRIGGER trg_PreventDeleteActiveRequests
ON Заявка
INSTEAD OF DELETE
AS
BEGIN
IF EXISTS (SELECT 1 FROM deleted WHERE статус = 'В работе')
BEGIN
RAISERROR ('Удаление заявок в работе запрещено', 16, 1);
ROLLBACK TRANSACTION;
END
ELSE
BEGIN
DELETE FROM Заявка WHERE id_заявки IN (SELECT id_заявки FROM deleted);
END
END;
Триггер 3 – логирование добавления заявок
Триггер автоматически фиксирует факт добавления новой заявки.
CREATE TRIGGER trg_LogRequestInsert
ON Заявка
AFTER INSERT
AS
BEGIN
INSERT INTO Журнал_действий (дата_операции, описание)
SELECT GETDATE(), 'Добавлена новая заявка'
FROM inserted;
END;
Таким образом, в данном разделе были разработаны хранимые процедуры, функции и триггеры, обеспечивающие реализацию серверной логики автоматизированной системы управления ООО «КомфортДом». Использование серверных механизмов позволило повысить надежность обработки данных, автоматизировать ключевые операции и обеспечить контроль целостности информации.
Выводы по разделу
В рамках третьего раздела курсовой работы была разработана серверная логика базы данных автоматизированной системы управления ООО «КомфортДом». Использование хранимых процедур, функций и триггеров позволило реализовать основные элементы бизнес-логики непосредственно на уровне сервера базы данных, что повысило надежность и целостность обработки информации.
Разработанные хранимые процедуры обеспечили автоматизацию ключевых операций, связанных с добавлением, обновлением и обработкой заявок, а также распределением ответственности между сотрудниками. Применение механизма транзакций в хранимых процедурах позволило гарантировать согласованность данных при выполнении операций, затрагивающих несколько таблиц, и предотвратить возникновение некорректных состояний базы данных в случае ошибок выполнения.
Созданная пользовательская функция позволила реализовать вычисление аналитических показателей непосредственно на сервере базы данных, что упростило формирование отчетной информации и снизило нагрузку на клиентские приложения. Использование функции в составе SQL-запросов повысило гибкость и расширяемость системы.
Реализованные триггеры обеспечили автоматический контроль изменений данных и выполнение дополнительных действий при возникновении событий вставки, обновления и удаления записей. Использование триггеров позволило автоматизировать установку служебных значений, ограничить некорректные операции и обеспечить фиксацию изменений в базе данных. Вместе с тем, было отмечено, что при значительном увеличении объема данных и интенсивности операций использование триггеров требует осторожного подхода, так как они могут оказывать влияние на производительность системы.
Таким образом, разработка серверного приложения позволила повысить уровень автоматизации и безопасности базы данных, обеспечить централизованное управление бизнес-логикой и создать устойчивую основу для дальнейшего развития автоматизированной системы управления. Полученные результаты логически дополняют проектирование SQL-запросов и создают предпосылки для эффективного администрирования базы данных, рассмотренного в следующем разделе курсовой работы.
4 Администрирование базы данных
Администрирование базы данных является завершающим этапом проектирования автоматизированной системы управления и направлено на обеспечение надежной, безопасной и стабильной работы базы данных в процессе эксплуатации. Корректно организованное администрирование позволяет управлять доступом пользователей к данным, предотвращать несанкционированные действия, обеспечивать сохранность информации и восстанавливать данные в случае сбоев или отказов оборудования.
В рамках данной курсовой работы администрирование базы данных автоматизированной системы управления ООО «КомфортДом» реализуется с использованием стандартных средств Microsoft SQL Server и включает создание пользовательских ролей, настройку авторизации, выбор модели восстановления и стратегии резервного копирования, а также настройку параметров безопасности SQL Server Agent.
Для разграничения доступа к данным в базе данных были созданы пользовательские роли, соответствующие основным категориям пользователей автоматизированной системы. Использование ролей позволяет централизованно управлять правами доступа и упростить администрирование при изменении состава пользователей.
В базе данных ООО «КомфортДом» были определены следующие роли:
– администратор базы данных;
– сотрудник управляющей компании;
– пользователь с правами просмотра данных.
Назначение пользовательских ролей и их основные права представлены в таблице 5.
Таблица 5 – Пользовательские роли базы данных
Роль | Назначение | Основные права
db_admin | Администрирование БД | Полный доступ ко всем объектам
employee | Работа с заявками | Чтение, добавление и обновление данных
viewer | Просмотр информации | Только чтение данных
Создание ролей и назначение прав доступа осуществляется с использованием команд SQL Server. Пример создания роли сотрудника приведен ниже:
CREATE ROLE employee;
GRANT SELECT, INSERT, UPDATE ON Заявка TO employee;
Авторизация пользователей базы данных осуществляется на основе учетных записей SQL Server с последующим назначением соответствующих ролей. Такой подход позволяет гибко управлять доступом к данным и обеспечивает соответствие требованиям информационной безопасности.
Каждому пользователю назначается минимально необходимый набор прав в зависимости от выполняемых функций. Например, сотрудники управляющей компании имеют доступ к таблицам заявок и жильцов, но не имеют прав на удаление данных или изменение структуры базы данных.
Пример создания пользователя и назначения ему роли приведен ниже:
CREATE LOGIN employee_user WITH PASSWORD = 'StrongPassword123';
CREATE USER employee_user FOR LOGIN employee_user;
ALTER ROLE employee ADD MEMBER employee_user;
Использование ролевой модели доступа позволяет снизить риск ошибок и несанкционированных действий при работе с базой данных.
Для обеспечения сохранности данных в базе данных была выбрана полная модель восстановления. Данная модель позволяет восстановить базу данных до любого момента времени при наличии резервных копий и журналов транзакций, что особенно важно для информационных систем, работающих в режиме постоянного обновления данных.
В рамках выбранной модели восстановления разработана стратегия резервного копирования, включающая:
– полное резервное копирование базы данных с периодичностью один раз в сутки;
– дифференциальное резервное копирование один раз в 6 часов;
– резервное копирование журнала транзакций каждые 30 минут.
Пример команды полного резервного копирования базы данных приведен ниже:
BACKUP DATABASE ComfortDomDB
TO DISK = 'C:\Backup\ComfortDomDB_full.bak';
Проверка работоспособности стратегии резервного копирования осуществляется путем восстановления базы данных на тестовом сервере, что подтверждает корректность создаваемых резервных копий и возможность восстановления данных в случае сбоя.
SQL Server Agent используется для автоматизации административных задач, включая выполнение заданий резервного копирования и обслуживания базы данных. Для повышения уровня безопасности были выполнены настройки, ограничивающие доступ к SQL Server Agent только для пользователей с административными правами.
В рамках настройки безопасности:
– доступ к управлению заданиями SQL Server Agent предоставлен только администраторам;
– учетная запись агента ограничена минимально необходимыми правами;
– задания резервного копирования выполняются по расписанию с журналированием результатов выполнения.
Пример задания резервного копирования базы данных, созданного с использованием SQL Server Agent, может быть представлен в виде скриншота интерфейса среды SQL Server Management Studio (рисунок 4).
Рисунок 4 – Настройка задания резервного копирования в SQL Server Agent
Выводы по разделу
В данном разделе были рассмотрены основные аспекты администрирования базы данных автоматизированной системы управления ООО «КомфортДом». Создание пользовательских ролей и настройка авторизации обеспечили разграничение доступа к данным и повышение уровня информационной безопасности. Выбор полной модели восстановления и разработка стратегии резервного копирования позволили обеспечить сохранность и восстановление данных в случае сбоев. Настройка параметров безопасности SQL Server Agent обеспечила автоматизацию и контроль выполнения административных задач.
Рассмотренные меры администрирования дополняют ранее разработанные механизмы проектирования и серверной логики базы данных, формируя целостную и надежную автоматизированную систему управления.
