Как устроена информационная система: проектируем простую систему учета заявок

Когда слышишь термин «информационная система», первое время он кажется слишком общим. Под него можно подвести почти что угодно: интернет-магазин, банковское приложение, электронный дневник, систему учета сотрудников или даже небольшой сервис для регистрации обращений пользователей. Но почти у всех таких систем есть общая задача: получить данные, сохранить их, обработать и предоставить пользователю в удобном виде. В этой статье я разберу устройство информационной системы на простом примере — системе учета заявок. Такая система может использоваться внутри компании: сотрудник сообщает о проблеме, заявка сохраняется, специалист берет ее в работу, а затем меняет статус после решения. Цель статьи — не создать полноценный промышленный продукт, а показать основные компоненты информационной системы и то, как они взаимодействуют друг с другом. Постановка задачи Представим небольшую организацию, в которой сотрудники периодически обращаются в техническую поддержку. Например: не работает принтер; отсутствует доступ к корпоративной системе; необходимо установить программу; возникла проблема с компьютером; требуется создать новую учетную запись. Если подобных обращений немного, их можно принимать через мессенджер или записывать в обычную таблицу. Однако со временем возникают проблемы. Непонятно, какие заявки уже выполнены, какие еще находятся в работе, кто отвечает за конкретное обращение и когда оно было создано. Поэтому имеет смысл создать отдельную информационную систему. Пусть она умеет: создавать заявку; хранить информацию о пользователе; показывать список заявок; изменять статус заявки; назначать ответственного сотрудника; хранить дату создания заявки. Получается уже вполне реальная прикладная задача. Из чего будет состоять система Упрощенно систему можно разделить на три основных уровня: Интерфейс пользователя → серверная часть → база данных Пользователь работает с интерфейсом. Например, заполняет форму создания заявки. Интерфейс отправляет данные на сервер. Сервер проверяет их и записывает в базу данных. Когда необходимо показать список заявок, происходит обратный процесс: сервер получает информацию из базы данных и передает ее интерфейсу. Такое разделение используется во множестве современных приложений. Проектирование базы данных Начать удобно со структуры данных. Для небольшой системы нам понадобятся как минимум две сущности: пользователи; заявки. Таблица пользователей может выглядеть следующим образом: users id name email role Здесь id — уникальный идентификатор пользователя. Поле role определяет роль. Например: user support admin Теперь создадим таблицу заявок: tickets id title description status created_at author_id executor_id Поле author_id будет содержать идентификатор пользователя, создавшего заявку. executor_id — идентификатор сотрудника, который занимается ее выполнением. Таким образом, между таблицами возникает связь. Один пользователь может создать несколько заявок. В терминах баз данных это называется отношением один ко многим. Условно схема выглядит так: users +----------+ | id | | name | | email | | role | +----------+ | | v tickets +-------------+ | id | | title | | description | | status | | created_at | | author_id | | executor_id | +-------------+ Даже на этом этапе становится видно, зачем информационной системе нужна структурированная база данных. Если хранить всю информацию в одной большой таблице, данные пользователей придется постоянно дублировать. Например, имя и электронная почта автора будут повторяться в каждой его заявке. Это усложняет изменение данных и увеличивает вероятность ошибок. SQL и создание таблиц Для хранения информации можно использовать PostgreSQL. Таблица пользователей может быть создана следующим SQL-запросом: CREATE TABLE users ( id SERIAL PRIMARY KEY, name VARCHAR(100) NOT NULL, email VARCHAR(150) UNIQUE NOT NULL, role VARCHAR(30) NOT NULL ); Таблица заявок: CREATE TABLE tickets ( id SERIAL PRIMARY KEY, title VARCHAR(200) NOT NULL, description TEXT, status VARCHAR(30) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, author_id INTEGER NOT NULL, executor_id INTEGER, FOREIGN KEY (author_id) REFERENCES users(id), FOREIGN KEY (executor_id) REFERENCES users(id) ); После этого база данных уже может хранить основные сущности системы. Добавим пользователя: INSERT INTO users (name, email, role) VALUES ( 'Иван Петров', 'ivan@example.com', 'user' ); Теперь можно создать заявку: INSERT INTO tickets ( title, description, status, author_id ) VALUES ( 'Не работает принтер', 'Принтер в кабинете 203 не печатает документы', 'new', 1 ); Получить все заявки можно обычным запросом: SELECT * FROM tickets; Но пользователю системы работать напрямую с SQL, конечно, не нужно. Для этого существует серверная часть приложения. Зачем нужен backend Backend — это часть системы, которая находится между пользовательским интерфейсом и базой данных. Именно сервер решает, что разрешено делать пользователю. Например, если приложение получает команду: Создать заявку сервер должен: проверить, авторизован ли пользователь; проверить корректность данных; сохранить заявку; вернуть результат. Если пользователь пытается изменить чужую заявку или назначить себя администратором, backend должен отклонить запрос. Поэтому нельзя строить приложение так, чтобы пользовательский интерфейс напрямую работал с базой данных. Сервер выступает контролируемой точкой доступа к информации. API Связь между интерфейсом и сервером часто строится через API. Например, для нашей системы можно определить следующие HTTP-запросы: GET /tickets Получить список заявок. GET /tickets/15 Получить заявку с идентификатором 15. POST /tickets Создать новую заявку. PATCH /tickets/15 Изменить заявку. Например, при создании обращения интерфейс может отправить серверу JSON: { "title": "Не работает принтер", "description": "Принтер не печатает документы" } Сервер обработает запрос и может вернуть: { "id": 42, "title": "Не работает принтер", "status": "new", "created_at": "2026-08-13T10:30:00" } Интерфейсу при этом совершенно не обязательно знать, какой SQL-запрос выполнялся внутри системы. Это одно из преимуществ разделения приложения на уровни. Статусы заявок Практически в любой системе учета появляется понятие состояния объекта. Для заявки можно использовать статусы: new in_progress resolved closed Но просто разрешить менять статус на любой другой — не всегда хорошая идея. Например, логично определить последовательность: new | v in_progress | v resolved | v closed Это уже пример бизнес-логики. Бизнес-логика — правила, определяющие поведение информационной системы. Например: новую заявку может создать любой сотрудник; назначить исполнителя может только сотрудник поддержки; закрыть заявку можно только после выполнения; обычный пользователь не может удалить чужое обращение. Именно такие правила превращают обычную базу данных в полноценную информационную систему. Авторизация пользователей Следующая проблема — как сервер понимает, какой пользователь выполняет запрос. Обычно используется механизм авторизации. Пользователь вводит логин и пароль. После успешной проверки сервер выдает ему токен или создает сессию. При дальнейших запросах приложение сообщает серверу, от имени какого пользователя выполняется операция. Например: POST /tickets Authorization: Bearer Сервер получает идентификатор пользователя из токена и автоматически указывает его как автора новой заявки. В реальном приложении пароль нельзя хранить в базе данных в открытом виде. Вместо этого хранится его криптографический хеш. Это важный пример того, как требования к информационной системе выходят далеко за пределы обычного хранения данных. Необходимо учитывать безопасность. Интерфейс системы Для простого варианта достаточно нескольких страниц. Страница входа Поля: Email Пароль Список заявок Можно представить его в виде таблицы: ID Название Статус Автор Исполнитель 1 Не работает принтер new Иван — 2 Установить программу in_progress Анна Сергей 3 Нет доступа к системе resolved Максим Сергей Создание заявки Пользователь вводит: название; описание проблемы. Остальные данные система формирует автоматически. Например, дату создания не нужно вводить вручную. Страница заявки На ней можно показать полную информацию: Заявка №15 Название: Нет доступа к корпоративной системе Описание: После смены пароля система сообщает об ошибке. Автор: Иван Петров Исполнитель: Сергей Иванов Статус: В работе Создана: 13.08.2026 Такой интерфейс уже позволяет использовать систему в реальной работе. Что происходит при создании заявки Теперь рассмотрим полный процесс. Пользователь нажимает кнопку «Создать заявку». Шаг 1. Интерфейс Пользователь вводит: Название: Нет доступа к системе Описание: После ввода пароля появляется ошибка Шаг 2. Запрос к серверу Frontend отправляет: POST /tickets с данными: { "title": "Нет доступа к системе", "description": "После ввода пароля появляется ошибка" } Шаг 3. Проверка Backend проверяет: существует ли пользователь; заполнено ли название; не превышена ли допустимая длина данных. Шаг 4. Запись в базу Сервер выполняет примерно такой SQL-запрос: INSERT INTO tickets ( title, description, status, author_id ) VALUES ( 'Нет доступа к системе', 'После ввода пароля появляется ошибка', 'new', 7 ); Шаг 5. Ответ Сервер сообщает интерфейсу, что заявка создана. Пользователь видит: Заявка №43 успешно создана. На первый взгляд действие выглядит очень простым. Но внутри него взаимодействует сразу несколько частей информационной системы. Что произойдет при росте нагрузки Для учебного проекта можно запустить backend и базу данных даже на одном компьютере. Но представим, что системой пользуются уже не 20 сотрудников, а 100 000 человек. Тогда начинают появляться новые задачи. Например: сервер получает слишком много запросов; база данных начинает отвечать медленнее; необходимо хранить резервные копии; требуется журналирование действий; появляются требования к отказоустойчивости. Архитектура становится сложнее. Может появиться несколько серверов: Пользователи | v Балансировщик / \ v v Backend 1 Backend 2 \ / \ / v v Database Балансировщик распределяет запросы между серверами. Могут также появляться кеширование, очереди сообщений, репликация базы данных и другие механизмы. Но принцип остается тем же: система получает, хранит, обрабатывает и передает информацию. Почему нельзя сделать все в одной таблице Excel На небольшом количестве данных Excel действительно может решить задачу. Допустим, есть таблица: Автор Email Проблема Статус Исполнитель Однако при увеличении числа пользователей появляются ограничения. Во-первых, информация начинает дублироваться. Имя и email пользователя придется записывать снова для каждой заявки. Во-вторых, сложно контролировать права доступа. В полноценной системе можно разрешить пользователю видеть только свои заявки, а администратору — все. В-третьих, становится сложнее работать одновременно большому количеству пользователей. Кроме того, информационная система может автоматически проверять данные, отправлять уведомления и выполнять другие действия. То есть отличие заключается не только в способе хранения данных, но и в автоматизации процессов вокруг них. Что можно добавить в систему дальше Даже из такой простой идеи можно постепенно получить достаточно серьезный проект. Например, добавить приоритет заявки: low medium high critical После этого можно реализовать фильтрацию: Показать все критические заявки, которые еще не выполнены. SQL-запрос будет выглядеть примерно так: SELECT * FROM tickets WHERE priority = 'critical' AND status != 'closed'; Можно добавить комментарии к заявкам. Для этого появляется новая таблица: comments id ticket_id author_id text created_at После этого одна заявка может иметь множество комментариев. Можно добавить историю изменения статусов: ticket_history id ticket_id old_status new_status changed_by changed_at Это позволит определить, кто и когда изменил заявку. Также можно реализовать: прикрепление файлов; email-уведомления; поиск; фильтрацию; статистику; личный кабинет; раздел администратора; категории заявок; автоматическое назначение исполнителя. Из небольшого учебного приложения постепенно получается достаточно полноценная информационная система. Какие технологии можно использовать Один из возможных наборов технологий: Frontend: HTML CSS JavaScript Backend: Python FastAPI Database: PostgreSQL API: REST Для небольшого проекта этого более чем достаточно. При этом конкретные технологии здесь вторичны. Backend можно написать на Java, C#, Go, JavaScript или другом языке. PostgreSQL можно заменить другой СУБД. Главное — понимать назначение каждого компонента и взаимодействие между ними. Что я понял при разборе такой системы До изучения устройства подобных приложений информационная система может восприниматься просто как программа с базой данных. Но в реальности это набор связанных компонентов. База данных отвечает за хранение информации. Backend реализует правила работы и управляет доступом к данным. API определяет способ взаимодействия компонентов. Frontend предоставляет пользователю интерфейс. Авторизация отвечает за идентификацию пользователей и разграничение прав. А архитектура определяет, как все эти части связаны между собой. Даже простая система учета заявок затрагивает сразу несколько областей: базы данных, программирование, проектирование архитектуры, безопасность и пользовательские интерфейсы. Именно этим информационные системы мне и кажутся интересными: разработчик работает не только над отдельным алгоритмом или интерфейсом, а проектирует целый процесс работы с информацией. Заключение Информационная система необязательно должна начинаться с огромной архитектуры, десятков сервисов и миллионов пользователей. Начать можно с простой задачи. Например: Пользователь создает заявку, система сохраняет ее, сотрудник принимает ее в работу и после выполнения меняет статус. Но даже в таком небольшом сценарии появляются ключевые элементы современной информационной системы: пользователи; база данных; связи между сущностями; backend; API; интерфейс; бизнес-логика; авторизация; безопасность. Именно поэтому небольшой проект зачастую полезнее для понимания информационных технологий, чем попытка сразу изучить устройство огромных систем. Разбирая систему по частям, становится понятнее, зачем нужны базы данных, серверная разработка, API и архитектура приложений — и каким образом из этих компонентов собирается единый работающий продукт.