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

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

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

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

Цель статьи — не создать полноценный промышленный продукт, а показать основные компоненты информационной системы и то, как они взаимодействуют друг с другом.

Постановка задачи

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

Например:

не работает принтер;
отсутствует доступ к корпоративной системе;
необходимо установить программу;
возникла проблема с компьютером;
требуется создать новую учетную запись.

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

Однако со временем возникают проблемы.

Непонятно, какие заявки уже выполнены, какие еще находятся в работе, кто отвечает за конкретное обращение и когда оно было создано.

Поэтому имеет смысл создать отдельную информационную систему.

Пусть она умеет:

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

Получается уже вполне реальная прикладная задача.

Из чего будет состоять система

Упрощенно систему можно разделить на три основных уровня:

Интерфейс пользователя → серверная часть → база данных

Пользователь работает с интерфейсом. Например, заполняет форму создания заявки.

Интерфейс отправляет данные на сервер.

Сервер проверяет их и записывает в базу данных.

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

Такое разделение используется во множестве современных приложений.

Проектирование базы данных

Начать удобно со структуры данных.

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

пользователи;
заявки.

Таблица пользователей может выглядеть следующим образом:

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 (
'Иван Петров',
'[e-mail]',
'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 и архитектура приложений — и каким образом из этих компонентов собирается единый работающий продукт.