Экономический факультет
Введение.
Модульные платформы — это унифицированный набор компонентов и архитектурных решений, который используется для создания различных моделей автомобилей. Из этого «конструктора» автопроизводители собирают машины, где сохраняется общая основа, но варьируются кузова, некоторые специфические узлы [5].
Автомобильная промышленность трансформируется благодаря модульным платформам, которые повышают экономическую эффективность, уровень гибкости и инновационные возможности [5]. Поэтому во время быстроразвивающихся технологий, спроса на персонализацию модульный автопром — ключ к успешному развитию автомобильной промышленности. Стандартизация ключевых компонентов и узлов позволяет создавать широкий ассортимент моделей на единой базе, что ускоряет производство и уменьшает издержки на разработку.
Рисунок 1. Компоненты автомобиля
Мотивация проекта.
Современный автомобиль представляет собой сложную систему, состоящую из большого количества взаимосвязанных компонентов (рис. 1). В модульном автопроме одна и та же платформа может использоваться для разных моделей автомобилей, а комплектующие могут применяться в нескольких производственных решениях одновременно. Из-за этого возникает необходимость централизованного хранения и управления данными. Если информация хранится разрозненно, становится сложно контролировать совместимость платформ и деталей, отслеживать производство автомобилей и получать аналитическую информацию. Поэтому задача проекта — построить информационную систему, которая объединяет данные о производителях, моделях, автомобилях, платформах и комплектующих в единую структуру.
Основная цель проекта — разработка модели информационной системы для модульного автопрома. Для достижения этой цели были поставлены несколько задач. Во-первых, необходимо было выделить основные сущности предметной области и определить связи между ними. Во-вторых, подготовить структуру базы данных и организовать данные для последующего хранения. Также требовалось разработать ролевую модель, описать бизнес-процессы в нотации IDEF0, реализовать SQL-базу данных и написать программный код для обработки информации.
После подготовки данных была разработана структура базы данных. В проекте были созданы основные таблицы-сущности: производители автомобилей, модели, автомобили, платформы и комплектующие. Кроме этого, были созданы таблицы-связки. Они необходимы для реализации отношений между сущностями. Например, одна платформа может использоваться несколькими автомобилями, а одна деталь может быть связана с определенной платформой. Такое разделение позволяет избежать дублирования информации и обеспечивает целостность данных.
Ключевым компонентом модульных платформ является стандартизация частей автомобиля, которые являются элементами брендовой дифференциации и не видны клиентам [5]. Обычно это строение электроники и проводки, тормозов, компоненты шасси, части подвески, рулевого управления, а также интерфейсы межмодульного взаимодействия, крепления агрегатов. С помощью этой технологии инженеры фокусируются на уникальных характеристиках моделей (специальное оборудование, управляемость, дизайн автомобиля).
Рисунок 2. Гибкость при использовании модульных платформ
Разнообразие моделей.
С помощью модульных платформ дизайнеров повышается гибкость при создании автомобилей. На стандартизированной архитектуре возможно производить различные классы и типы автомобилей (например, от седана до кроссовера) (рис. 2). Это реализуется за счет установки различных кузовов и изменения свесов, колеи, колесной базы [5]. Благодаря гибкости автопроизводители могут учитывать требования региональных рынков, а также быстрее внедрять инновационные технологии, ведь для этого не нужно полное изменение конструкции.
Также модульный автопром отвечает тренду на кастомизацию продукции под запросы клиентов (рис. 3). Без усложнения производственного процесса предприниматели получают возможность предлагать различный дизайн, оборудование [3].
Рисунок 3. Кастомизация продукции под запросы клиента
Первыми стали использовать подобие платформы General Motors в 1908. В это время все марки создавали разные модели на единой основе, а кузов потребители приобретали самостоятельно в других компаниях [4].
GM пытается рационализировать использование созданных инженерных решений для упрощения разработки и внедрения инноваций. К унификации GM подвигло то, что он был объедением нескольких марок, из-за чего потребовались единые технологии. Стандартизация прошла успешно, и они стали производить несколько моделей (Oldsmobile, Chevrolet, Pontiac) на единой платформе А-body.
После войны в Европе имел успех Citroen 2CV, что использовали французы, дав новое имя (Citroën Ami) и изменив кузов, они создали новый автомобиль, который стал самым продаваемым в их стране. Так, создание моделей на единых платформах приближается к современным формам.
В 70-е в Америке появляется бейдж-инжиниринг. Он подразумевает производство такой же машины, как уже есть на рынке, то есть без технических различий, но с небольшими внешними имениями, а главное новой эмблемой [4].
В начале XXI в автопроизводители приступили к созданию разных моделей автомобилей на единой платформе. Каждая модель обладала своими преимуществами, поэтому перестали говорить, что платформенный инжиниринг не совместим с разнообразием. Примером такого подхода могут служить Volkswagen Touareg и Porsche Cayenne (рис. 4).
Рисунок 4. Volkswagen Touareg и Porsche Cayenne на единой платформе
При использовании модульных платформ модели отличаются друг от друга дизайном, и некоторыми характеристиками, но имеют общую конструкцию. С использованием этой технологии возникает проблема: невозможно комбинировать части моделей, которые созданы на разных платформах из-за их несовместимости.
Сейчас набирают популярность модульные «тележки», так как заменяют несколько платформ сразу. Детали стыкуются между собой, ведь автомобиль заранее делится на области, которые возможно менять в определенных пределах [4].
Большое количество издержек образуется при создании неизменной, негибкой части автомобиля – места, где находится мотор или трансмиссия. Но все остальные элементы возможно изменять. В этом заключается свобода модульных платформ, они позволяют создавать автомобиля на одной основе, но отличные по характеристикам, например, на платформе Volkswagen проектируются Audi A4 и Bentley Bentayga, Lamborghini Urus. Volkswagen начал использовать модульные платформы MLB уже в 2007 для моделей с продольным расположением двигателя. Позднее, когда появляется MQB (рис. 5), модульные платформы стали применять для моделей с поперечным расположением мотора [4]. Для дальнейшего развития машин этой фирмы стали использовать модульные платформы. Им последовали ключевые игроки глобального авторынка: Toyota, Daimler, Nissan, PSA и др.
Рисунок 5. Модульная система MQB
В Японии вместо создания единой универсальной платформы разработали взаимосвязанные «тележки» для разных типов автомобилей. Например, TNGA включает платформы для кроссоверов, седанов. При их проектировании использовались стандартизованные узлы подвесок и точки крепления. В 2023 году более половины моделей Toyota построено с помощью TNGA (рис. 6): Camry, Corolla, C-HR, RAV4, Highlander, а также премиальные Lexus (NX, ES, RX).
В 2025 году Mercedes-Benz выпустил модульную платформу MMA (Mercedes-Benz Modular Architecture). Она создана для гибридных силовых установок и для чисто электрических [1].
Можно отметить, что количество созданных на основе определённой платформы моделей определяет ее успех. На сегодняшний день модульные платформы только развиваются, поэтому пока используют имеющиеся платформы.
Трендом в автопроме является возможность одной платформы принимать совершенно разные типы силовых установок. Рынок будет нуждаться одновременно в традиционных бензиновых двигателях и гибридах еще долго из-за постепенного перехода к электромобилям, что помогают учесть модульные платформы.
Рисунок 6. Модульная платформа TNGA
В будущем увеличится гибкость платформ, что позволит создавать автомобили совершенно разных классов на одной базе [1]. По мере развития технологии диапазон размеров и назначений будет расширяться.
Возможно, в будущем для автомобилей разного класса будет в качестве основной использоваться одна платформа. Главное внимание будет сосредоточено на программном обеспечении при стандартизации железной основы [5]. Предприниматели будут получать прибыль на платных обновлениях, дополнительных функциях и возможностях. Платформа будет еще более унифицирована, а электроника продолжит дифференциацию.
Экологические требования сильно влияют на рынок, а значит на развитие платформ. Направлением их эволюции выступает использование переработанных материалов, оптимизация производства. По европейские нормам к 2030 году автомобиль должен состоять на 85% из перерабатываемых материалов. Производители начали адаптироваться: полимеров заменяются на биопластики, сталь на алюминий. Таким образом, экологичность является важным конкурентным преимуществом.
На втором этапе работы использовался Excel. Он применялся как инструмент предварительного проектирования базы данных. В Excel были подготовлены данные о производителях, моделях, автомобилях, платформах и комплектующих. Отдельные листы соответствовали будущим таблицам базы данных.
Следующий этап — разработка ролевой модели системы. Все участники были разделены на внутренние и внешние (рис. 7). К внутренним участникам относятся генеральный директор, руководитель производства, производственный менеджер, инженер-конструктор и специалист по комплектующим. Также отдельно выделяется управленческий персонал. Эти роли выполняют аналитические запросы и контроль производства. Сотрудники оперативной деятельности создают и изменяют данные в системе. К внешним участникам относятся клиент и поставщик комплектующих. Они имеют ограниченный доступ и могут в основном просматривать информацию или передавать данные.
Рисунок 7. Ролевая модель системы
После ролевой модели были описаны бизнес-процессы в нотации IDEF0. Главный процесс называется «Управление производством автомобилей на модульной платформе» (рис. 8). Этот процесс был декомпозирован на несколько этапов (рис. 9). Сначала выполняется ведение данных о производителях и моделях. Затем формируется автомобильная платформа. После этого подбираются комплектующие, регистрируется конкретный автомобиль и в конце выполняется анализ и контроль производства. Такая последовательность отражает логику модульного автопрома, где автомобиль создается как результат объединения платформы, модели и набора комплектующих.
Рисунок 8. Бизнес-процессы в нотации IDEF0
Рисунок 9. Этапы управления производством автомобилей на модульной платформе
Практическая реализация проекта выполнялась в SQL Server, а для работы с базой данных использовалась среда DBeaver. В базе данных были созданы таблицы, первичные ключи и внешние ключи. Особое внимание уделялось foreign keys, так как они обеспечивают целостность данных и не позволяют создавать некорректные связи между сущностями. Например, нельзя зарегистрировать автомобиль с производителем, которого нет в таблице производителей. Также были реализованы SQL-запросы для разных ролей: аналитические запросы для управленческого персонала и запросы на создание или изменение данных для сотрудников оперативной деятельности.
Для каждой роли были разработаны SQL-запросы, соответствующие их функциям. Например, руководитель производства может выполнять аналитические запросы по автомобилям и платформам, а производственный менеджер — регистрировать новые автомобили и изменять характеристики. Также реализованы запросы для анализа производителей, платформ, моделей и комплектующих. Это позволяет использовать базу данных не только как хранилище информации, но и как инструмент аналитики и управления производством.
Пример SQL-запроса:
Для обработки данных был написан программный код на Python с использованием библиотеки Pymssql. Программа подключается к SQL Server и выполняет операции с таблицей производителей автомобилей. В коде были реализованы функции просмотра производителей и добавления новых записей. Таким образом, Python использовался как пример прикладного взаимодействия с базой данных через программный интерфейс.
Результаты проекта.
В результате проекта была разработана целостная модель информационной системы для модульного автопрома. Были выделены сущности предметной области, подготовлена структура базы данных, разработана ролевая модель и описаны бизнес-процессы. Также была реализована база данных в SQL Server, настроены связи между таблицами и написан программный код на Python для обработки данных. Главный результат проекта состоит в том, что удалось связать концептуальное описание предметной области с технической реализацией информационной системы.
Список литературы.
Введение.
Организация розничной торговли книгами в современных реалиях претерпевает значительные изменения под влиянием цифровых технологий. Традиционная модель, при которой покупатель приходил в книжный магазин и выбирал книгу,сегодня дополнена множеством новых способов: онлайн-заказы с доставкой, покупка на маркетплейсах, электронные книги и сервисы с подпиской. Помимо этого, перед книготорговыми предприятиями остро стоит вопрос привлечения покупателей, поскольку конкуренция со стороны крупных сетей, таких как «Читай-город» и «Буквоед», а также маркетплейсов Ozon и Wildberries, постоянно усиливается.
Цель эссе - рассмотреть применение инновационных информационных технологий, в первую очередь технологий искусственного интеллекта, для совершенствования способов приобретения книжной продукции и повышения эффективности привлечения покупателей в розничной книжной торговле.
Описание предметной области книжной розничной торговли.
На основе анализа схемы данных №38 «Книготорговцы» можно выделить ключевые сущности, которые отражают специфику розничной книжной торговли. Центральным объектом являются книги, каждая из которых имеет уникальный идентификатор, автора, категорию, ISBN, дату публикации, рекомендованную розничную цену и комментарии. Авторы содержат персональные данные: имя, инициалы, фамилию, дату рождения, пол и контактные детали. Категории книг представляют собой классификатор, позволяющий группировать книги по жанрам или тематикам (например, историческая литература, религиозная, западная проза).
Спрос и продажи отражаются через сущности клиентов, заказов и позиций заказа. Клиент имеет уникальный код, имя, адрес, телефон и электронную почту. Заказ фиксирует дату покупки и общую стоимость и привязан к конкретному клиенту. Позиция заказа детализирует каждую купленную книгу с указанием согласованной цены и комментария. Кроме того, в базе данных присутствуют контакты -дополнительные лица, напрямую не связанные с клиентом, но косвенно относящиеся к ним.
Предметная область охватывает следующие ключевые процессы: формирование ассортимента книг, привлечение и регистрацию покупателей, оформление заказов, фиксацию фактической цены продажи и послепродажное взаимодействие с клиентами.
Цель автоматизации в данном контексте - расширение способов приобретения книг (онлайн, офлайн, через маркетплейсы), а также повышение эффективности привлечения и удержания покупателей за счёт персонализированных коммуникаций и анализа покупательского поведения.
Рисунок 1 – База данных с описанием
Рисунок 2 – Ролевая модель книжного магазина
Рисунок 3 – Контекстная диаграмма IDEFO A-0
Рисунок 4 – Декомпозиция бизнес-процесса A0
Параметры доступа к базе данных.
Сервер: 93.180.33.27
Порт: 1433
База данных: ANBO
SQL-запросы по ролям.
1) Роль: Клиент (просмотр)
1. Просмотр каталога книг (только книги с ценой > 0)
SELECT book_ID, book_Title, author_Last_Name, book_Category_Code, book_Recommended_Price
FROM Books
JOIN Authors ON Books.author_ID = Authors.author_ID
WHERE book_Recommended_Price > 0;
2. Просмотр своих завершённых заказов (только с суммой > 0, для customer_ID = 1)
SELECT order_ID, order_Date, order_Value
FROM Orders
WHERE customer_ID = 1 AND order_Value > 0;
2) Роль: Менеджер по продажам (просмотр)
1. Поиск заказа по номеру
SELECT o.order_ID, c.customer_Name, o.order_Date, o.order_Value
FROM Orders o
JOIN Customers c ON o.customer_ID = c.customer_ID
WHERE o.order_ID = 10;
2. Просмотр истории заказов конкретного клиента
SELECT o.order_ID, o.order_Date, o.order_Value
FROM Orders o
WHERE o.customer_ID = 5 AND o.order_Value > 0;
3) Роль: Специалист по работе с клиентами (просмотр)
1. Поиск клиента по фамилии
SELECT customer_ID, customer_Name, customer_Phone, customer_Email
FROM Customers
WHERE customer_Name LIKE N'%Иванов%';
2. Просмотр всех контактов клиентов
SELECT c.contact_ID, c.contact_FirstName, c.contact_LastName,
c.contact_CellPhonenumber, ct.contact_Type_Description
FROM Contacts c
JOIN Ref_Contact_Types ct ON c.contact_Type_Code = ct.contact_Type_Code;
4) Роль: Кладовщик (просмотр)
1. Просмотр книг, поступивших в указанном месяце (январь 2024)
SELECT book_ID, book_Title, date_Acquired, book_Recommended_Price
FROM Books
WHERE date_Acquired IS NOT NULL
AND FORMAT(CAST(date_Acquired AS DATE), 'yyyy-MM') = '2024-01'
ORDER BY CAST(date_Acquired AS DATE);
2. Количество книг на складе по категориям
SELECT bc.book_Category_Description, COUNT(b.book_ID) AS BooksCount
FROM Books b
JOIN Book_Categories bc ON b.book_Category_Code = bc.book_Category_Code
WHERE b.date_Acquired IS NOT NULL
GROUP BY bc.book_Category_Description
ORDER BY BooksCount DESC;
5) Роль: Маркетолог (просмотр)
1. Продажи по месяцам
SELECT YEAR(o.order_Date) AS Year, MONTH(o.order_Date) AS Month,
COUNT(o.order_ID) AS OrdersCount, SUM(o.order_Value) AS MonthlyRevenue
FROM Orders o
WHERE o.order_Value > 0
GROUP BY YEAR(o.order_Date), MONTH(o.order_Date)
ORDER BY Year DESC, Month DESC;
2. Количество заказов по дням недели
SELECT DATEPART(weekday, order_Date) AS WeekDay, COUNT(order_ID) AS OrdersCount
FROM Orders
WHERE order_Value > 0
GROUP BY DATEPART(weekday, order_Date)
ORDER BY WeekDay;
6) Роль: Директор (просмотр)
1. Общая выручка магазина
SELECT SUM(order_Value) AS TotalRevenue
FROM Orders
WHERE order_Value > 0;
2. Средний чек по магазину
SELECT AVG(order_Value) AS AverageCheck
FROM Orders
WHERE order_Value > 0;
7) Роль: Администратор БД (просмотр)
1. Просмотр всех таблиц в базе данных
SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
ORDER BY TABLE_NAME;
2. Просмотр всех уникальных типов данных в базе
SELECT DISTINCT DATA_TYPE
FROM INFORMATION_SCHEMA.COLUMNS
ORDER BY DATA_TYPE;
Обработка данных в Python.
Часть 2: Загрузка данных из Excel
# Загружаем только основные таблицы
customers = pd.read_excel(file_name, sheet_name='Customers')
books = pd.read_excel(file_name, sheet_name='Books')
orders = pd.read_excel(file_name, sheet_name='Orders')
order_items = pd.read_excel(file_name, sheet_name='Order_Items')
book_categories = pd.read_excel(file_name, sheet_name='Book_Categories')
print(f"Клиентов: {len(customers)}")
print(f"Книг: {len(books)}")
print(f"Заказов: {len(orders)}")
Клиентов: 50
Книг: 50
Заказов: 50
Часть 3: Отчёт для клиента
print("\n--- КЛИЕНТ ---")
print("\nКаталог книг (первые 5):")
print(books[['book_Title', 'book_Recommended_Price']].head(5))
print("\nКатегории книг:")
print(book_categories)
print("\nМои заказы (customer_ID=1):")
my_orders = orders[orders['customer_ID'] == 1]
print(my_orders[['order_ID', 'order_Date', 'order_Value']])
--- КЛИЕНТ ---
Каталог книг (первые 5):
book_Title book_Recommended_Price
0 Твоё сердце будет разбито 550
1 Преступление и наказание 500
2 Мастер и Маргарита 520
3 Евгений Онегин 480
4 Три товарища 590
Категории книг:
book_Category_Code book_Category_Description
0 CLASSIC Русская и зарубежная классика
1 DETECTIVE Детективы и триллеры
2 FANTASTIC Фантастика и фэнтези
3 ROMANCE Любовные романы и современная проза
4 POETRY Поэзия
5 CHILDREN Детская литература
6 SCIENCE Научно-популярная литература
Мои заказы (customer_ID=1):
order_ID order_Date order_Value
0 1 2024-01-15 550
Заключительная часть.
В ходе работы над проектом я спроектировала и заполнила базу данных «Книготорговцы», разработала ролевую модель с 7 ролями и описала бизнес-процесс в IDEF0 (4 этапа). Для каждой роли были подготовлены SQL-запросы на просмотр данных.
Ключевым результатом является модуль на Python для персонализированных рекомендаций (этап А4). Он анализирует историю покупок клиента и предлагает книги из его любимой категории. Программа протестирована на клиенте с ID=1: система определила категорию ROMANCE и порекомендовала «Новую жизнь в Париже» и «Любовь в эпоху перемен».
В рамках проекта подготовлена аналитика для руководства: общая выручка магазина составила 25 913 рублей при 50 заказах, средний чек - 518,26 рублей. Эти данные позволяют оценить текущие показатели деятельности и принимать обоснованные управленческие решения.
Считаю, что я смогла достичь цель проекта в полной мере. Разработанные решения обладают потенциалом для масштабирования и могут быть адаптированы для использования в реальной практике книжной розницы для оптимизации процессов и повышения прибыли компании.
Список литературы.
Введение.
В современном мире ресторанный бизнес, особенно в сегменте высокого класса, перестал быть исключительно сферой кулинарного мастерства и гостеприимства. Сегодня, это сложно выстроенная система, где успех зависит от передовых информационных технологий, которые внедряют в бизнес. Раньше факторами успеха считались исключительно изысканные блюда, мастерство шефа и безупречная работа официантов. Но теперь к ним добавились очень важные компоненты — цифровая инфраструктура управления.
Данная работа посвящена анализу цифровых технологий, которые уже внедрили в ресторанный бизнес и которые можно внедрить для улучшения качества. Целью является выявление и систематизация технологических факторов успеха.
Описание предметной области.
В ресторане главными объектами являются Блюдо (из меню), Заказ, Продукт (на складе) и Сотрудник. У блюда есть название, цена и список продуктов, из которых оно состоит. У заказа есть номер, статус выполнения и общая сумма. Склад хранит продукты, и каждый раз, когда повар готовит блюдо, нужное количество продуктов со склада списывается.
Процесс работы строится просто: гость делает заказ, официант передает его на кухню, повар готовит блюда, тратя на это продукты. Когда гость поел, заказ оплачивается и закрывается. Все это время система следит за тем, чтобы на складе не закончились нужные продукты, иначе блюдо становится недоступным.
Автоматизация здесь нужна, чтобы не считать остатки продуктов вручную и не путаться в заказах. Она помогает быстро передавать заказы на кухню, точно знать, сколько продуктов осталось, и видеть выручку в конце дня.
Ключевые этапы реализации проекта.
В рамках выполнения работы по проектированию и разработке информационной системы для ресторанного бизнеса было реализовано несколько последовательных этапов: от построения концептуальных моделей до практической реализации SQL-скриптов и программной логики обработки данных на языке Python.
Этап 1. Проектирование ролевой модели, схемы данных и бизнес-процессов
Первым этапом работы стало определение ролевой структуры и описание бизнес-процессов. В ходе анализа были выделены три крупных блока пользователей: внешние участники (гости, поставщики, платежная система), обслуживающий персонал зала (официант, хостес, бармен, сомелье), а также производственный и управленческий состав (повара горячего и холодного цехов, закупщик, управляющий, бухгалтер, шеф-повар и администратор). Схема распределения прав и функциональных обязанностей между перечисленными ролями представлена на рисунке 1.
Рисунок 1 – Ролевая модель
Далее была спроектирована модель бизнес-процесса «Приготовление блюда» в нотации IDEF0, включающая последовательность от запуска заказа до выдачи готового блюда. Визуализация данного бизнес-процесса приведена на рисунке 2.
Рисунок 2 – Модель бизнес-процесса приготовления блюда IDEF0
Заключительным этапом моделирования стала разработка логической схемы базы данных. Структура БД показана на рисунке 3.
Рисунок 3 – Схема БД
Этап 2. Реализация SQL-запросов по ролям
После утверждения структуры БД был разработан набор SQL-скриптов, обеспечивающих взаимодействие пользователей с системой согласно их ролям.
Так, для роли «Хостес» разработаны запросы на проверку занятых мест и бронирование столиков:
SELECT COUNT(*) AS занятые_места
FROM student_meals_taken smt
JOIN meals m ON smt.meal_id = m.meal_id
WHERE m.date_of_meal = CURRENT_DATE;
Для роли «Официант» реализованы операции создания и объединения заказов:
INSERT INTO orders (order_id, date_order_placed, other_details)
VALUES (2000, CURRENT_DATE, 'Заказ от столика 1');
Запросы для «Закупщика» направлены на контроль складских остатков:
SELECT product_name, reorder_level
FROM products
WHERE reorder_level < 10;
Роль «Менеджера смены» позволяет рассчитывать дневную выручку ресторана:
SELECT SUM(amount_of_payment) AS дневная_выручка
FROM payments
WHERE date_of_payment = CURRENT_DATE;
Также были реализованы скрипты для поваров, экспедитора и бармена, которые контролируют уровень запасов, статус заказов и специфические позиции меню, а администратор системы обладает полным доступом к управлению ролями и данными персонала.
Этап 3. Обработка данных и визуализация в Python
Финальным этапом стала реализация вспомогательного скрипта на языке Python с использованием библиотек pandas. Скрипт выполняет загрузку данных из Excel-файлов, их обработку и аналитику.
Первой задачей стала функция выгрузки данных о продуктах. Для удобства была написана пользовательская функция поиска цены продукта по его уникальному коду:
def get_price(product_code, df):
row = df[df['product_code'] == product_code]
if not row.empty:
return row['unit_price'].iloc[0]
return "Продукт не найден"
Также скрипт осуществляет проверку статусов поставок. На основе датафреймов загружаются данные о доставках (df_deliveries), после чего строится столбчатая диаграмма, показывающая соотношение статусов «Без нареканий» и «Недостача».
В заключительной части скрипта реализован анализ финансовых операций. Данные о платежах (df_payments) преобразуются в даты, группируются по дням, после чего с помощью библиотеки matplotlib строится линейный график «Сумма платежей по датам». Это позволяет менеджменту ресторана отслеживать динамику выручки в режиме реального времени. Используемый для этого код имеет следующий вид:
df_payments['date_of_payment'] = pd.to_datetime(df_payments['date_of_payment'])
payments_by_date = df_payments.groupby(df_payments['date_of_payment'].dt.date)['amount_of_payment'].sum()
payments_by_date.plot(kind='line', figsize=(10,5), marker='o', title='Сумма платежей по датам')
Результат выполнения данного программного кода, наглядно демонстрирующий динамику поступления средств, представлен на рисунке 4.
Рисунок 4 – Визуализация динамики платежей по датам
Заключение.
Проведённый анализ показывает, что ресторанный бизнес высокого класса сегодня невозможен без внедрения цифровых технологий. Системы автоматизации (R-Keeper, SteadyControl), мобильные приложения и QR-меню стали не просто дополнительными инструментами, а обязательной основой для снижения издержек, ускорения обслуживания и минимизации человеческих ошибок.
Перспективные технологии — интерактивные столы, роботизация кухни, упрощённые программы лояльности — открывают новые возможности для роста среднего чека и оптимизации персонала. Предложенные авторские решения (ИИ-аналитик отзывов, умное прогнозирование закупок, автоматический планировщик смен) способны решить конкретные проблемы рестораторов, от пищевых потерь до эффективного управления штатом.
Цифровизация даёт владельцам контроль из любой точки мира и точную аналитику, но технологии остаются лишь помощниками. Искусственный интеллект не заменит человеческую эмпатию и атмосферу заведения. Будущее ресторанного бизнеса — за разумным сочетанием передовых IT-решений и живого гостеприимства.
В ходе работы были последовательно реализованы основные этапы жизненного цикла информационной системы: от моделирования бизнес-процессов и проектирования базы данных до разработки прикладных SQL-скриптов и программной логики на Python для оперативного контроля данных.
Используемые источники.
Введение.
Актуальность исследования: Современный спорт высших достижений переживает этап цифровой трансформации. Рост конкуренции на международных турнирах требует отказа от субъективных методов оценки и перехода к технологически обоснованным решениям. Ошибка судьи или неточность хронометража могут стоить спортсмену медали или тренерскому штабу очень много. Одновременно с этим назрела потребность в персонализированных методиках подготовки, учитывающих индивидуальные биомеханические, физиологические и психологические особенности атлета. В этих условиях применение современных информационных систем становится не дополнительным преимуществом, а необходимым условием конкурентоспособности.
Объект исследования: спортивные соревнования и тренировочный процесс как совокупность организационных, технических и методических компонентов.
Предмет исследования: современные цифровые технологии, используемые для объективной оценки спортивных результатов и совершенствования методик подготовки победителей крупных международных турниров.
Цель: Выявить эффективность внедрения информационных систем в практику судейства и тренировок, а также определить перспективные направления цифровизации спортивной подготовки.
Задачи:
1. Описать ключевые сущности предметной области (спортсмены, тренеры, судьи, соревнования, результаты, методики) и их взаимосвязи.
2. Проанализировать уже внедрённые системы оценки - видеоповторы, электронные хронометры, датчики движения - и оценить их влияние на точность судейства.
3. Изучить перспективные технологии: цифровые двойники спортсменов, искусственный интеллект для прогнозирования результатов, VR-тренажёры для моделирования соревновательных ситуаций.
4. Рассмотреть риски информационной безопасности и этические аспекты, связанные со сбором и обработкой биометрических данных атлетов.
5. Сформулировать рекомендации по интеграции рассмотренных технологий в единую систему подготовки и оценки.
Гипотеза: Комплексное внедрение цифровых технологий в спортивную практику создаёт условия для построения индивидуализированных траекторий подготовки, что ведёт к снижению травматизма и увеличению вероятности установления рекордов.
Методологическая основа работы включает анализ научной и технической литературы, изучение отраслевых кейсов внедрения информационных систем, сравнительный анализ традиционных и цифровых подходов к оценке и подготовке.
Практическая значимость работы заключается в систематизации современных цифровых решений в области спорта и обосновании их применения для повышения конкурентоспособности российских спортсменов на международной арене.
Описание предметной области.
Предметная область «Результаты спортивных соревнований. Оценка спортивных достижений и методики подготовки победителей крупных турниров» охватывает деятельность, связанную с проведением спортивных турниров, фиксацией достижений спортсменов и разработкой эффективных тренировочных программ. Основными сущностями являются:
- Игроки - центральный объект, обладающий атрибутами: уникальный идентификатор, код рейтинга, ФИО, пол, контактные данные и дополнительные сведения.
- Клубы - содержит информацию о футбольных клубах, к которым могут принадлежать игроки. Атрибуты: идентификатор клуба, название, адрес, дополнительные сведения и ссылка на организатора в виде идентификатора.
- Организаторы соревнований - обеспечивают организацию спортивных соревнований. Атрибуты: идентификатор, название, описание.
- Справочник видов спорта - содержит в себе такие атрибуты, как код вида спорта и описание (вид спорта).
- Справочник рейтингов - атрибуты: код рейтинга и описание (спортивное звание).
- Соперники (участники) - связывает игрока или команду с конкретным видом спорта и клубом. Атрибуты: идентификатор, вид спорта, клуб, игрок, рейтинг, тип (команда или одиночный игрок).
- Соревнования - описывает конкретное событие или матч, связывает соперников и организатора. Прочие атрибуты: уникальный идентификатор, название, даты начала и конца, описание результата, числовые показатели для каждого участника.
Ключевые этапы проекта.
Ролевая модель:
Модель бизнес-процесса:
Параметры доступа к базе данных.
Адрес сервера: 93.180.33.27:1433
Название БД: YUEN
Название сервера: dbo
SQL-запросы.
1. Игрок (Player)
Просмотр собственного профиля
SELECT p.player_id, p.player_first_name, p.player_last_name,
p.gender, p.date_of_birth, p.address,
p.phone_number, p.email_address,
p.other_details,
r.ranking_description
FROM Players p
LEFT JOIN Ref_Ranking_Codes r ON p.ranking_code = r.ranking_code
WHERE p.player_id = :current_player_id;
2. Организатор (Organizer)
Просмотр своих соревнований
SELECT c.competition_id, c.competition_name,
c.venue, c.start_date, c.end_date,
c.result_description,
c.competitor_1_score, c.competitor_2_score,
rs.sport_description
FROM Competitions c
JOIN Ref_Sport_Codes rs ON c.sport_code = rs.sport_code
WHERE c.organizer_id = :current_organizer_id
ORDER BY c.start_date DESC;
3. Представитель клуба (ClubRep)
Просмотр данных своего клуба
SELECT cl.club_id, cl.club_name, cl.club_address,
cl.club_city, cl.founding_year,
rs.sport_description, o.organizer_name,
cl.other_club_details
FROM Clubs cl
LEFT JOIN Ref_Sport_Codes rs ON cl.sport_code = rs.sport_code
LEFT JOIN Competition_Organizers o ON cl.organizer_id = o.organizer_id
WHERE cl.club_id = :current_club_id;
4. Регистратор (Registrar)
Поиск игрока по имени
SELECT p.player_id, p.player_first_name, p.player_last_name,
p.date_of_birth, p.gender,
r.ranking_description, p.phone_number, p.email_address
FROM Players p
LEFT JOIN Ref_Ranking_Codes r ON p.ranking_code = r.ranking_code
WHERE p.player_last_name LIKE '%' + :search_name + '%'
OR p.player_first_name LIKE '%' + :search_name + '%'
ORDER BY p.player_last_name, p.player_first_name;
5. Оператор соревнований (CompetitionOperator)
Список участников по виду спорта для выбора пары
SELECT comp.competitor_id,
p.player_first_name + ' ' + p.player_last_name AS player_name,
cl.club_name, rs.sport_description,
r.ranking_description
FROM Competitors comp
JOIN Players p ON comp.player_id = p.player_id
JOIN Clubs cl ON comp.club_id = cl.club_id
JOIN Ref_Sport_Codes rs ON comp.sport_code = rs.sport_code
JOIN Ref_Ranking_Codes r ON comp.ranking_code = r.ranking_code
WHERE comp.sport_code = :sport_code
ORDER BY r.ranking_code, cl.club_name;
6. Администратор клуба (ClubAdmin)
Создание нового клуба
INSERT INTO Clubs (
club_name, club_address, club_city,
founding_year, sport_code, organizer_id,
other_club_details)
VALUES (
:club_name, :club_address, :club_city,
:founding_year, :sport_code, :organizer_id,
:other_club_details);
7. Аналитик (Analyst)
Рейтинговая таблица игроков в разрезе вида спорта
SELECT rs.sport_description, r.ranking_description,
p.player_first_name + ' ' + p.player_last_name AS player_name,
cl.club_name,
COUNT(c.competition_id) AS total_played,
SUM(CASE
WHEN (comp.competitor_id = c.competitor_1_id AND c.competitor_1_score > c.competitor_2_score)
OR (comp.competitor_id = c.competitor_2_id AND c.competitor_2_score > c.competitor_1_score)
THEN 1 ELSE 0 END) AS wins,
CAST(100.0 * SUM(CASE
WHEN (comp.competitor_id = c.competitor_1_id AND c.competitor_1_score > c.competitor_2_score)
OR (comp.competitor_id = c.competitor_2_id AND c.competitor_2_score > c.competitor_1_score)
THEN 1 ELSE 0 END)
/ NULLIF(COUNT(c.competition_id), 0) AS DECIMAL(5,1)) AS win_pct
FROM Competitors comp
JOIN Players p ON comp.player_id = p.player_id
JOIN Clubs cl ON comp.club_id = cl.club_id
JOIN Ref_Sport_Codes rs ON comp.sport_code = rs.sport_code
JOIN Ref_Ranking_Codes r ON comp.ranking_code = r.ranking_code
LEFT JOIN Competitions c
ON c.competitor_1_id = comp.competitor_id
OR c.competitor_2_id = comp.competitor_id
WHERE comp.sport_code = :sport_code
GROUP BY rs.sport_description, r.ranking_description,
p.player_first_name, p.player_last_name,
cl.club_name, r.ranking_code
ORDER BY win_pct DESC;
8. Руководитель (Manager)
Сводная операционная панель
SELECT
(SELECT COUNT(*) FROM Players) AS total_players,
(SELECT COUNT(*) FROM Clubs) AS total_clubs,
(SELECT COUNT(*) FROM Competitors) AS total_competitors,
(SELECT COUNT(*) FROM Competitions) AS total_competitions,
(SELECT COUNT(*) FROM Competitions WHERE result_description IS NOT NULL) AS completed,
(SELECT COUNT(*) FROM Competitions WHERE result_description IS NULL AND end_date < GETDATE()) AS overdue_results;
9. Системный администратор (SysAdmin)
Добавление новой рейтинговой категории в справочник
INSERT INTO Ref_Ranking_Codes (ranking_code, ranking_description)
VALUES (:ranking_code, :ranking_description);
Обработка данных на Python.
# -*- coding: utf-8 -*-
"""Untitled2.ipynb
Automatically generated by Colab.
Original file is located at
https://colab.research.google.com/drive/1b6VgPDqv9xfnXM1MXSfDGyFtf3sg8GfR
"""
from google.colab import files
uploaded = files.upload()
import pandas as pd
import matplotlib.pyplot as plt
import numpy as np
import os
plt.rcParams['font.sans-serif'] = ['DejaVu Sans', 'Arial', 'Liberation Sans']
plt.rcParams['axes.unicode_minus'] = False
FILE_PATH = "Юмашева Ева, м101, 2 этап.xlsx"
if not os.path.exists(FILE_PATH):
print(f"Файл {FILE_PATH} не найден. Доступные .xlsx файлы:")
for f in os.listdir():
if f.endswith('.xlsx'):
print(f" {f}")
raise FileNotFoundError(f"Файл {FILE_PATH} отсутствует")
print(f"Загрузка данных из {FILE_PATH}...")
xls = pd.ExcelFile(FILE_PATH)
sheet_names = xls.sheet_names
data = {}
for sheet in sheet_names:
data[sheet] = pd.read_excel(xls, sheet_name=sheet)
players = data['Players']
ref_rank = data['Ref_Ranking_Codes']
ref_sport = data['Ref_Sport_Codes']
organizers = data['Competition_Organizers']
clubs = data['Clubs']
competitors = data['Competitors']
competitions = data['Competitions']
print("\n--- Предварительная обработка ---")
players['date_of_birth'] = pd.to_datetime(players['date_of_birth'], errors='coerce')
competitions['start_date'] = pd.to_datetime(competitions['start_date'], errors='coerce')
competitions['end_date'] = pd.to_datetime(competitions['end_date'], errors='coerce')
players_with_rank = players.merge(ref_rank, on='ranking_code', how='left')
print("\nПример данных игроков с описанием рейтинга:")
print(players_with_rank[['player_first_name', 'player_last_name', 'ranking_code', 'ranking_description']].head(5))
print("\n--- Статистика по игрокам ---")
gender_counts = players['gender'].value_counts()
print("Распределение по полу:")
print(gender_counts)
rank_counts = players['ranking_code'].value_counts().sort_index()
print("\nРаспределение по рейтинговым кодам:")
print(rank_counts)
plt.figure(figsize=(8, 5))
rank_counts.plot(kind='bar', color='skyblue', edgecolor='black')
plt.title('Распределение игроков по рейтинговым уровням')
plt.xlabel('Рейтинговый код')
plt.ylabel('Количество игроков')
plt.xticks(rotation=0)
plt.tight_layout()
plt.savefig('распределение игроков по рейтинговым уровням.jpg', dpi=150)
plt.show()
print("График сохранён как 'распределение игроков по рейтинговым уровням.jpg'")
print("\n--- Статистика по участникам соревнований ---")
competitors_sport = competitors.merge(ref_sport, on='sport_code', how='left')
sport_counts = competitors_sport['sport_description'].value_counts()
print("Участники по видам спорта:")
print(sport_counts)
type_counts = competitors['team_or_player_TP'].value_counts()
print("\nУчастники по типу заявки:")
print(type_counts)
plt.figure(figsize=(10, 5))
sport_counts.plot(kind='bar', color='lightgreen', edgecolor='black')
plt.title('Количество участников по видам спорта')
plt.xlabel('Вид спорта')
plt.ylabel('Количество участников')
plt.xticks(rotation=45, ha='right')
plt.tight_layout()
plt.savefig('количество участников по видам спорта.jpg', dpi=150)
plt.show()
print("График сохранён как 'количество участников по видам спорта.jpg'")
print("\n--- Анализ соревнований ---")
def determine_winner(row):
if pd.isna(row['competitor_1_score']) or pd.isna(row['competitor_2_score']):
return None
if row['competitor_1_score'] > row['competitor_2_score']:
return row['competitor_1_id']
elif row['competitor_1_score'] < row['competitor_2_score']:
return row['competitor_2_id']
else:
return 'Draw'
competitions['winner_competitor_id'] = competitions.apply(determine_winner, axis=1)
comp_organizer = competitions.merge(organizers, on='organizer_id', how='left')
organizer_counts = comp_organizer['organizer_name'].value_counts()
print("\nСоревнования по организаторам:")
print(organizer_counts)
comp_sport_counts = competitions['sport_code'].value_counts().rename(index=ref_sport.set_index('sport_code')['sport_description'])
print("\nСоревнования по видам спорта:")
print(comp_sport_counts)
plt.figure(figsize=(8, 8))
organizer_counts.plot(kind='pie', autopct='%1.1f%%', startangle=90, colormap='Set3')
plt.title('Распределение соревнований по организаторам')
plt.ylabel('')
plt.tight_layout()
plt.savefig('распределение соревнований по организаторам.jpg', dpi=150)
plt.show()
print("График сохранён как 'распределение соревнований по организаторам.jpg'")
wins = competitions[competitions['winner_competitor_id'].notna() & (competitions['winner_competitor_id'] != 'Draw')]
winner_counts = wins['winner_competitor_id'].value_counts().reset_index()
winner_counts.columns = ['competitor_id', 'wins']
winner_info = winner_counts.merge(competitors, on='competitor_id', how='left')
winner_info = winner_info.merge(players, on='player_id', how='left')
winner_info['full_name'] = winner_info['player_first_name'] + ' ' + winner_info['player_last_name']
winner_info = winner_info[['competitor_id', 'full_name', 'wins', 'sport_code']].sort_values('wins', ascending=False)
print("\nТоп-5 участников по количеству побед в матчах:")
print(winner_info.head(5))
print("\n--- Участие клубов ---")
club_participation = competitors['club_id'].value_counts().reset_index()
club_participation.columns = ['club_id', 'num_competitors']
club_participation = club_participation.merge(clubs[['club_id', 'club_name']], on='club_id', how='left')
print("Количество участников от каждого клуба:")
print(club_participation[['club_name', 'num_competitors']].head(10))
with pd.ExcelWriter('analysis_report.xlsx') as writer:
players_with_rank.to_excel(writer, sheet_name='Players_With_Rank', index=False)
sport_counts.to_excel(writer, sheet_name='Competitors_by_Sport')
organizer_counts.to_excel(writer, sheet_name='Competitions_by_Organizer')
winner_info.to_excel(writer, sheet_name='Top_Winners', index=False)
club_participation.to_excel(writer, sheet_name='Clubs_Participation', index=False)
Заключение.
В ходе выполнения проекта спроектирована и реализована реляционная база данных «Результаты спортивных соревнований», охватывающая полный жизненный цикл соревновательной деятельности - от регистрации игроков и клубов до ввода результатов и формирования аналитических отчётов. Разработанная структура данных нормализована, содержит 7 таблиц, связанных внешними ключами, что обеспечивает целостность и непротиворечивость информации.
На основе анализа бизнес-процессов (IDEF0 A1–A5) выделены девять ролей пользователей, для каждой из которых определены разрешённые операции и ограничения доступа. Это позволяет гибко разграничивать права и гарантировать, что каждый участник системы работает только с необходимыми данными.
Разработан набор из девяти характерных SQL-запросов, покрывающих ключевые функции всех ролей - от просмотра профиля до построения рейтинговых таблиц и сводных панелей. Все запросы параметризованы, что исключает SQL-инъекции и упрощает интеграцию с внешними приложениями.
Предусмотрена возможность обработки данных в Python с использованием различных библиотек, что позволяет автоматизировать формирование отчётов, визуализировать динамику показателей и строить прогнозные модели.
Таким образом, разработанное решение создаёт основу для цифровой трансформации спортивного управления: повышает объективность судейства, сокращает трудозатраты на учёт, даёт тренерам и аналитикам инструменты для персонализированной подготовки атлетов. Внедрение подобной системы в практику спортивных федераций и лиг будет способствовать повышению конкурентоспособности российских спортсменов на международной арене.
Источники:
Российская Федерация, 119991, г.Москва, ГСП-1, Ленинские горы,
Московский государственный университет имени М.В. Ломоносова,
дом 1, строение 46 (3-й новый учебный корпус), Экономический факультет, к.546,548,550
Кафедра экономической информатики
Наш сайт на econ.msu.ru
+7 (495) 939-30-67 — секретарь
+7 (495) 939-57-25 — преподавательская
Электронная почта: ecinf.econ@org.msu.ru