Готовая курсовая: ИС учёта аренды автотранспорта

СОДЕРЖАНИЕ
ВВЕДЕНИЕ	3
1	ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ	5
2	ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ	8
2.1	Этап концептуального проектирования	8
2.2	Этап логического проектирования	9
2.3	Этап физического проектирования	10
3	ПРОЕКТИРОВАНИЕ ПОЛЬЗОВАТЕЛЬСКИХ ИНТЕРФЕЙСОВ	13
3.1	Список требуемых транзакций	13
3.2	Анализ транзакций на этапе логического проектирования	13
3.3	Документация на пользовательские интерфейсы	15
3.4	Реализация транзакций средствами выбранной СУБД	19
3.5.	Анализ транзакций на этапе физического проектирования	29
ЗАКЛЮЧЕНИЕ	34
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ	35
ПРИЛОЖЕНИЯ	36
Скрипт генерации базы данных	36

Внедрение баз данных и автоматизированных информационных систем на современных предприятиях имеет огромное значение, поскольку это позволяет:
Улучшить качество обслуживания клиентов, предоставляя быстрый и эффективный сервис.
Повысить производительность труда благодаря автоматизации бизнес-процессов и упрощению работы сотрудников.
Получать актуальную информацию о деятельности компании и принимать обоснованные решения.
Снизить затраты на ведение бизнеса, оптимизируя управление ресурсами и процессами.
Создать инфраструктуру для увеличения рентабельности, снижения издержек и обеспечения стабильно высокого качества продукции и услуг.
Таким образом, разработка и внедрение информационной системы является актуальной задачей, которая способствует росту бизнеса и его устойчивому развитию.
Целью работы является проектирование и разработка базы данных и информационной системы учета аренды автотранспорта.
Для достижения поставленной цели необходимо решить следующие задачи:
провести анализ предметной области;
создать техническое задание на разработку информационной системы;
разработать модели информационной системы;
реализовать	информационную	систему	учета	аренды
автотранспорта;
выполнить контрольный запуск информационной системы;
описать	последовательность	шагов	по	внедрению информационной системы.
Объектом	исследования	является	бизнес-процесс	аренды автотранспорта.
Предметом	исследования	является	база	данных	учета	аренды автотранспорта.
ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
Компания «АвтоАренда» предлагает услуги аренды автомобилей для различных целей: путешествия, деловые поездки, корпоративные мероприятия и прочее. Основные бизнес-процессы компании включают [1]:
Приём заявок от клиентов: клиенты могут связаться с компанией через сайт, мобильное приложение или по телефону, чтобы забронировать автомобиль на определённое время.
Подбор автомобилей: менеджеры компании подбирают автомобили в соответствии с требованиями и предпочтениями клиента, учитывая марку, модель, тип кузова, пробег и стоимость аренды.
Оформление договора аренды: после подтверждения бронирования клиент подписывает договор аренды, в котором указаны условия аренды, ответственность сторон и порядок оплаты.
Предоставление автомобилей: компания предоставляет автомобили в оговоренное время и место, обеспечивая их техническое состояние и соответствие заявленным характеристикам.
Контроль состояния автомобилей: сотрудники компании следят за состоянием автомобилей и своевременно проводят техническое обслуживание и ремонт.
Оплата услуг: клиенты оплачивают услуги аренды безналичным расчётом или наличными средствами.
Возврат автомобилей: после окончания срока аренды клиент возвращает автомобиль в указанное место и время, проверяя его состояние и отсутствие повреждений.
Реклама и маркетинг: компания активно продвигает свои услуги на рынке, используя различные каналы коммуникации, такие как интернет, печатная реклама, радио и телевидение.
Финансовый учёт и анализ: компания ведёт учёт доходов и расходов, анализирует финансовые показатели и планирует развитие бизнеса.
Развитие и инновации: компания постоянно совершенствует свои услуги, внедряет новые технологии и предложения, чтобы оставаться конкурентоспособной на рынке аренды автотранспорта.
Внедрение базы данных по учету аренды автотранспорта позволит получить следующие преимущества:
Повышение эффективности бизнес-операций [2]: автоматизация процессов управления автопарком, отслеживание наличия транспортных средств, планирование графиков технического обслуживания и анализ использования автомобилей.
Рост выручки: увеличение клиентской базы, автоматизация процессов и сокращение операционных издержек.
Получение гибкой системы: возможность масштабирования системы в зависимости от количества запросов и операций [3].
Проектируемая система должна обеспечивать автоматизацию процессов аренда автотранспорта.
Функциональные требования к информационной системе учёта аренды автотранспорта включают:
Создание и редактирование информации о клиентах, автомобилях и договорах аренды.
Ведение истории всех арендных отношений с клиентами и автомобилями.
Возможность просмотра отчётов о состоянии аренды и финансов.
Управление	клиентской	базой,	включая	регистрацию	новых клиентов, изменение их контактных данных и статуса.
Возможность настройки прав доступа пользователей к различным функциям системы.
Требования к интерфейсу.
Интерфейс пользователя должен быть выполнен в виде веб-приложения с набором веб-страниц, обеспечивающим выполнение возложенных задач.
Интерфейс системы должен быть интуитивно понятным и простым в использовании.
Требования к безопасности.
Система должна обеспечивать защиту от несанкционированного доступа к данным.
Требования к интеграции.
ИС должна иметь возможность интеграции с сайтом организации для обеспечения возможности онлайн-записи.
ИС будет разрабатываться как клиент-серверное приложение, в качестве основной парадигмы будет использоваться объектно- ориентированный подход.
ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ
Этап концептуального проектирования
Концептуальное проектирование представляет собой начальный этап разработки базы данных, в ходе которого создается общая информационная модель данных, полностью независимая от конкретных технических реализаций. На этом этапе определяются основные сущности и их взаимосвязи.
Для предметной области проката автомобилей выделим следующие предметные области:
Скидка - описание скидок, которые может получить клиент в компании проката.
Клиент - описывает клиента автопроката.
Штраф - описание штрафов, которые может получить клиент за порчу арендуемого автомобиля.
Автомобиль - описывает арендуемый автомобиль.
СрокНадбавка - описание надбавок к оплате в зависимости от срока аренды.
Графически концептуальная модель представлена на рисунке 1 в виде ER-диаграммы, текущая и последующие диаграммы выполнены в среде ERWin.
Рисунок 1 - Концептуальная ER-модель базы данных
Как видно из диаграммы, многие сущности объединяются связью "многие-ко-многим", что в реляционной модели данных должно преобразовываться в дополнительную таблицу при дальнейшем проектировании.
Этап логического проектирования
Следующий этап — логическое проектирование — преобразует полученную концептуальную модель в структуру, учитывающую особенности выбранной модели данных. В процессе логического проектирования создаются схемы отношений, определяются первичные и внешние ключи, формируется логическая структура базы данных.
Логическая модель базы данных представлена на рисунке 2. Следует отметить, что в целом сущности логической модели соответствуют сущностям ранее сформированной концептуальной модели. Для реализации связей "многие-ко-многим" создана таблица "Сделка", которая описывает совершенные и действующие договоры аренды. Также созданы таблицы-
справочники "ТипАвтомобиля" и "ГодКоэф", которые описывают типы кузовов автомобилей и надбавку в цене в зависимости от года выпуска автомобиля.
Рисунок 2 - Логическая ER-модель базы данных
Этап физического проектирования
Завершающий этап — физическое проектирование — отвечает за создание конкретной реализации базы данных в выбранной СУБД. На этом этапе учитываются технические особенности системы, определяются способы физического хранения данных, создаются индексы и настраиваются методы доступа к информации.
Для реализации базы данных будет использоваться СУБД MySQL как одна из наиболее используемых и функциональных на данный момент.
В физической модели базы данных, представленной на рисунке 3, выбраны типы данных для каждого из атрибутов, соответствующие СУБД MySQL, а также названия таблиц и атрибутов переведены на английский язык для обеспечения лучшей совместимости с языками программирования при последующей разработке интерфейса информационной системы проката автомобилей.
Рисунок 3 - Физическая ER-модель базы данных
Следующим шагом является создание скрипта для генерации таблиц базы данных, в соответствии с разработанной физической моделью. Чтобы обеспечить правильность создания таблиц при многократном перезапуске скрипта, первым действием будет проверка их существования и удаления таблиц, как показано на рисунке 4.
Далее с помощью соответствующих запросов «CREATE» создаются все таблицы базы данных.
Рисунок 4 - Фрагмент скрипта создания базы данных
Полный	листинг	скрипта	создания	базы	данных	приведен	в приложении к пояснительной записке.
ПРОЕКТИРОВАНИЕ ПОЛЬЗОВАТЕЛЬСКИХ ИНТЕРФЕЙСОВ
Список требуемых транзакций
В число основных транзакций, выполняемых менеджером компании по аренде автомобилей входит:
вывод списка автомобилей не старше заданного года;
вывод списка автомобилей заданной марки;
вывод списка автомобилей заданного производителя;
вывод списка клиентов;
вывод списка заказов за определенный период;
вывод списка незавершенных заказов.
Анализ транзакций на этапе логического проектирования
Для вывода списка автомобилей не старше заданного года следует выполнить выборку из таблицы Auto указав в условии, что поле year должно быть меньше заданного параметра. В результате запроса необходимо вывести поля brand, model, body, cost, year, year_fee, car_number. Для отображения названия кузова необходимо выполнить соединение таблицы Auto с таблицей CarBody с помощью внешнего ключа body. Для отображения надбавки за год авто, следует выполнить соединение таблицы Auto с таблицей YearFee с помошью внешнего ключа year_fee.
Для вывода списка автомобилей заданной марки следует выполнить выборку из таблицы Auto указав в условии, что поле model должно быть равно заданному параметру. В результате запроса необходимо вывести поля brand, model, body, cost, year, year_fee, car_number. Для отображения названия кузова необходимо выполнить соединение таблицы Auto с таблицей CarBody с помощью внешнего ключа body. Для отображения надбавки за год авто,
следует выполнить соединение таблицы Auto с таблицей YearFee с помошью внешнего ключа year_fee.
Для вывода списка автомобилей заданного бренда следует выполнить выборку из таблицы Auto указав в условии, что поле brand должно быть равно заданному параметру. В результате запроса необходимо вывести поля brand, model, body, cost, year, year_fee, car_number. Для отображения названия кузова необходимо выполнить соединение таблицы Auto с таблицей CarBody с помощью внешнего ключа body. Для отображения надбавки за год авто, следует выполнить соединение таблицы Auto с таблицей YearFee с помошью внешнего ключа year_fee.
Для отображения списка клиентов следует выбрать поля s_name, f_name, m_name, address, phone из таблицы Client, а также поля name и value из таблицы Discount. Выполнить соединение таблицы Client с таблицей Discount с помощью внешнего ключа discount.
Для отображения списка заказов за определенный период необходимо прочитать записи из таблицы Contract и выполнить ее соединение с таблицами Client и Auto по внешним ключам client и auto соответственно. Полученный список необходимо отфильтровать по условию, в котором поле start_date больше или равно первого параметра и в то же время поле end_date меньше или равно второго параметра. Запрос должен выводить полное имя клиента (созданное объединением полей s_name, f_name и m.name), название автомобиля (объединение полей brand и model), номер автомобиля, дата начала аренды, дата окончания аренды.
Для отображения списка незавершенных заказов необходимо прочитать записи из таблицы Contract и выполнить ее соединение с таблицами Client и Auto по внешним ключам client и auto соответственно. Полученный список необходимо отфильтровать по условию, в котором поле end_date равно NULL.
Документация на пользовательские интерфейсы
Интерфейс пользователя включает в себя набор окон, с помощью которых пользователь может решить задачу просмотра записей таблиц БД, а также их добавления, изменения и удаления. Также интерфейс обеспечивает отображение отчетов базы данных.
Информационная система должна удовлетворять следующим функциональным требованиям:
пользователь должен иметь возможность просмотра списка таблиц базы данных;
пользователь должен иметь возможность просмотра содержимого заданной таблицы БД;
интерфейс должен предоставлять возможность добавления новых записей в таблицу;
интерфейс должен предоставлять возможность удаления заданной записи из таблицы;
информационная система должна предоставлять возможность отображать отчет об активных заказов (заказах, в которых не установлена дата возврата);
информационная система должна предоставлять возможность отображать отчет о клиентах компании.
Далее опишем интерфейс информационной системы в контексте данных требований.
Интерфейс информационной системы разработан с помощью языка программирования Python и фреймворка Django. Для реализации базы данных использовалась СУБД MySQL.
После запуска информационной системы пользователь должен перейти в  веб-браузере  по  адресу  «127.0.0.1:8000»,  чтобы  попасть  на  главную
страницу. Главная страница отображает список таблиц базы данных (рисунок 5).
Рисунок 5 - Отображение списка таблиц базы данных
При нажатии на кнопку с названием определенной таблицы БД, пользователь переходит на страницу отображения записей таблицы. Записи сущности базы данных отображаются в табличном виде, причем последний столбец каждой строки содержит кнопки «Изменить» и «Удалить», которые позволяют изменить значения соответствующей записи или удалить ее.
Последняя строка таблицы повторяет поля сущности, но содержит элементы ввода данных. При заполнении этих полей и нажатии кнопки
«Добавить», создаются новые записи.
В качестве примера добавим три тестовые записи в таблицу carbody (рисунок 6).
Рисунок 6 - Добавление тестовых записей в таблицу carbody
Продемонстрируем удаление записи из таблицы carbody, на примере записи	с	id=14	(test2).	Для	этого	в	соответствующей	строке	нажмем
«Удалить». Страница автоматически обновится и отобразит измененную сущность (рисунок 7).
Рисунок 7 - Удаление тестовой записи из таблицы carbody
Для перехода на страницу отчетов следует ввести в адресной строке браузера «127.0.0.1:8000/report». Страница отчетов содержит выпадающий список, в котором можно выбрать нужный отчет и нажать кнопку «Показать». После этого в таблице ниже отобразится содержимое отчета.
На рисунке 8 показан отчет о незавершенных заказах.
Рисунок 8 - Отчет о незавершенных заказах
Отчет о клиентах показан на рисунке 9.
Рисунок 9 - Отчет о клиентах
Таким	образом,	показано	выполнение	всех	заявленных функциональных тестов.
Реализация транзакций средствами выбранной СУБД
Описание реализованных в СУБД транзакций представлено в таблице
Таблица 1. Описание реализованных в СУБД MySQL транзакций
Далее покажем исходный код скриптов для организации каждой из транзакций и результате их выполнения в СУБД MySQL.
Скрипт	и	результат	выполнения	процедуры	GetCars	показаны	на рисунках 10 и 11.
Рисунок 10 - Скрипт создания процедуры GetCars
Рисунок 11 - Результат выполнения процедуры GetCars
Скрипт и результат выполнения процедуры GetCarsByModels показаны на рисунках 12 и 13.
Рисунок 12 - Скрипт создания процедуры GetCarsByModels
Рисунок 13 - Результат выполнения процедуры GetCarsByModels
Скрипт и результат выполнения процедуры GetCarsByBrand показаны на рисунках 14 и 15.
Рисунок 14 - Скрипт создания процедуры GetCarsByBrand
Рисунок 15 - Результат выполнения процедуры GetCarsByBrand
Скрипт и результат выполнения представления clients_info показаны на рисунках 16 и 17.
Рисунок 16 - Скрипт создания представления clients_info
Рисунок 17 - Результат вызова представления clients_info
Скрипт и результат выполнения процедуры GetOrdersInDate показаны на рисунках 18 и 19.
Рисунок 18 - Скрипт создания процедуры GetOrdersInDate
Рисунок 19 - Результат выполнения процедуры GetOrdersInDate
Скрипт	и	результат	выполнения	процедуры	GetCars	показаны	на рисунках 20 и 21.
Рисунок 20 - Скрипт создания представления active_orders
Рисунок 21 - Результат выполнения представления active_orders
Скрипт	и	результат	выполнения	процедуры	AddClient показаны	на рисунках 22 и 23.
Рисунок 22 - Скрипт создания процедуры AddClient
Рисунок 23 - Результат выполнения процедуры AddClient
Скрипт	и	результат	выполнения	процедуры	UpdateClient показаны на рисунках 24 и 25.
Рисунок 24 - Скрипт создания процедуры UpdateClient
Рисунок 25 - Результат выполнения процедуры UpdateClient
Скрипт	и	результат	выполнения	процедуры	AddCar показаны на рисунках 26 и 27.
Рисунок 26 - Скрипт создания процедуры AddCar
Рисунок 27 - Результат выполнения процедуры AddCar
Скрипт	и	результат	выполнения	процедуры	AddContract показаны на рисунках 28 и 29.
Рисунок 28 - Скрипт создания процедуры AddContract
Рисунок 29 - Результат выполнения процедуры AddContract
Анализ транзакций на этапе физического проектирования
Целью данного анализа является определение функциональных характеристик транзакций, которые будут выполняться в базе данных, и выявление наиболее важных из них. Чтобы гарантировать, что разработанный физический дизайн базы данных соответствует требуемому уровню производительности, нам необходимо собрать как можно больше информации о транзакциях, которые будут выполняться в базе данных. Нам понадобятся как качественные, так и количественные характеристики. Для каждой транзакции необходимо знать:
ожидаемую частоту выполнения транзакции;
отношения и атрибуты, к которым транзакция должна будет получить доступ, а также тип доступа (R – извлечение, I – вставка);
ограничения на допустимое время выполнения транзакции.
Во многих случаях просто нецелесообразно анализировать все транзакции, поэтому мы должны выбрать самые «важные». Возвращаясь к диаграмме, используемой для анализа транзакций на этапе логического проектирования (см. рисунок 3.1), нам необходимо определить, какие отношения используются наиболее интенсивно во время выполнения транзакции. Для этого мы должны подсчитать количество входящих стрелок для каждой сущности. Например, в нашем случае результат будет следующим:
Таблица 2. Таблица количества вхождений для каждой сущности
Поскольку в нашем примере анализировалось лишь небольшое количество транзакций, количество входящих стрелок для всех сущностей примерно одинаково. Однако обычно 2–3 сущности имеют значительно больше входящих стрелок, чем остальные. На этапе физического проектирования имеет смысл анализировать только те транзакции, которые подразумевают доступ к отношениям с большим количеством входящих стрелок. В нашем случае это сущности Client, Auto и особенно Contract, через которые проходят все заявленные транзакции в нашем примере.
Далее необходимо указать ожидаемое количество строк в отношениях, а также среднюю и максимальную кардинальность каждого отношения. Например, мы ожидаем около 500 клиентов, до 200 автомобилей и более 1000 контрактов в год.
При анализе каждой транзакции важно не только знать среднее и максимальное количество вызовов в час, но и иметь информацию о днях недели и часах суток, когда транзакция обычно выполняется, включая данные о времени пиковой нагрузки. Например, частота определенных транзакций может оставаться на постоянном уровне большую часть времени, но все равно показывать четкий пик в конце месяца из-за подготовки отчетов. Другие транзакции могут выполняться только по будням с 9:00 до 18:00.
Когда поток транзакций требует частого доступа к определенным отношениям, выбранные для них стратегии выполнения становятся весьма значимыми. Если эти транзакции независимы друг от друга, риск проблем с производительностью уменьшается. Однако, если их планы выполнения конфликтуют, потенциальные проблемы можно частично решить, внимательно изучив транзакции и найдя способы их изменения для повышения производительности. В нашем случае нам нужно сосредоточиться на транзакциях, проходящих через таблицы Client, Auto и Contract.
Результаты анализа представлены в таблице 3.
Таблица 3. Результаты анализа транзакций

В ходе курсовой работы была спроектирована информационная система аренды автотранспорта. В качестве СУБД использована MySQL, интерфейс спроектирован в виде веб-приложения. Для разработки был использован язык программирования Python и фреймворк Django.
Проектируемая система призвана обеспечивать автоматизацию процессов аренда автотранспорта.
Функциональные требования к информационной системе учёта аренды автотранспорта включают:
Создание и редактирование информации о клиентах, автомобилях и договорах аренды.
Ведение истории всех арендных отношений с клиентами и автомобилями.
Возможность просмотра отчётов о состоянии аренды и финансов.
Управление	клиентской	базой,	включая	регистрацию	новых клиентов, изменение их контактных данных и статуса.
Пояснительная записка состоит из двух глав.
В первой главе представлен анализ предметной области, на основании которого были сформулированы требования к разрабатываемой ИС и проведено моделирование базы данных.
Во второй главе показана частичная разработка информационной системы, включая разработку и тестирование работы основных транзакций базы данных и проектирование интерфейса пользователя.

Раннев, Г.Г. Измерительные информационные системы. Учебник для студентов высших учебных заведений. Гриф УМО МО РФ / Г.Г. Раннев. - М.: Академия (Academia), 2021. - 493 c.
Анашкина, Н.В. Технологии и методы программирования: Учебное пособие для студентов учреждений высшего профессионального образования / Н.В. Анашкина, Н.Н. Петухова, В.Ю. Смольянинов. - М.: ИЦ Академия, 2021. - 384 c.
Балдин, К.В. Информационные системы в экономике: Учебник / К.В. Балдин, В.Б. Уткин. - М.: Дашков и К, 2020. - 395 c.
Бодров, О.А. Предметно-ориентированные экономические информационные системы: Учебник для вузов / О.А. Бодров. - М.: Гор. линия-Телеком, 2019. - 244 c.
Варфоломеева, А.О. Информационные системы предприятия: Учебное пособие / А.О. Варфоломеева, А.В. Коряковский, В.П. Романов. - М.: НИЦ ИНФРА-М, 2020. - 283 c.
ПРИЛОЖЕНИЯ
Скрипт генерации базы данных
DROP TABLE IF EXISTS Discount CASCADE; DROP TABLE IF EXISTS Client CASCADE; DROP TABLE IF EXISTS Penalty CASCADE; DROP TABLE IF EXISTS DelayFee CASCADE; DROP TABLE IF EXISTS CarBody CASCADE; DROP TABLE IF EXISTS YearFee CASCADE; DROP TABLE IF EXISTS Auto CASCADE; DROP TABLE IF EXISTS Contract CASCADE;
CREATE TABLE Discout (
id INT AUTO_INCREMENT,
name VARCHAR(100) NOT NULL, value DECIMAL(10,2) NOT NULL, PRIMARY KEY(id)
);
CREATE TABLE Client (
id INT AUTO_INCREMENT, f_name VARCHAR(50) NOT NULL, s_name VARCHAR(50) NOT NULL,
m_name VARCHAR(50) NOT NULL, address VARCHAR(100) NULL, phone VARCHAR(30) NOT NULL,
discount INT NOT NULL, PRIMARY KEY(id),
FOREIGN KEY(discount) REFERENCES Discount(id)
);
CREATE TABLE Penalty (
id INT AUTO_INCREMENT,
name VARCHAR(100) NOT NULL, cost DECIMAL(10,2) NOT NULL, PRIMARY KEY(id)
);
CREATE TABLE DelayFee (
id INT AUTO_INCREMENT,
delay INT NOT NULL,
cost DECIMAL(10,2) NOT NULL, PRIMARY KEY(id)
);
CREATE TABLE CarBody (
id INT AUTO_INCREMENT, name VARCHAR(50) NOT NULL, PRIMARY KEY(id)
);
CREATE TABLE YearFee (
id INT AUTO_INCREMENT, year INT NOT NULL,
fee INT NOT NULL, PRIMARY KEY(id)
);
CREATE TABLE Auto (
id INT AUTO_INCREMENT, brand VARCHAR(50) NOT NULL, model VARCHAR(50) NOT NULL, body INT NOT NULL,
cost DECIMAL(10,2) NOT NULL, year INT NOT NULL,
year_fee INT NULL,
car_number VARCHAR(10) NOT NULL,
PRIMARY KEY(id),
FOREIGN KEY(body) REFERENCES CarBody(id),
FOREIGN KEY(year_fee) REFERENCES YearFee(id)
);
CREATE TABLE Contract (
id INT AUTO_INCREMENT,
client INT NOT NULL, auto INT NOT NULL,
start_date DATETIME NOT NULL, end_date DATETIME NULL, penalty INT NULL,
delay_fee INT NULL, PRIMARY KEY(id),
FOREIGN KEY(client) REFERENCES Client(id), FOREIGN KEY(auto) REFERENCES Auto(id),
FOREIGN KEY(penalty) REFERENCES Penalty(id), FOREIGN KEY(delay_fee) REFERENCES DelayFee(id)
);
Содержимое файла models.py
# This is an auto-generated Django model module.
# You'll have to do the following manually to clean this up:
#  * Rearrange models' order
#  * Make sure each model has one field with primary_key=True
#	* Make sure each ForeignKey and OneToOneField has `on_delete` set to the desired behavior
# * Remove `managed = False` lines if you wish to allow Django to create, modify, and delete the table
# Feel free to rename the models, but don't rename db_table values or field names. from django.db import models
class Auto(models.Model):
brand = models.CharField(max_length=50) model = models.CharField(max_length=50)
body = models.ForeignKey('Carbody', models.DO_NOTHING, db_column='body') cost = models.DecimalField(max_digits=10, decimal_places=2)
year = models.IntegerField()
year_fee	=	models.ForeignKey('Yearfee',	models.DO_NOTHING, db_column='year_fee', blank=True, null=True)
car_number = models.CharField(max_length=10)
def   str  (self):
return f'{self.car_number} ({self.brand} {self.model})'
class Meta: managed = False db_table = 'Auto'
class Carbody(models.Model):
name = models.CharField(max_length=50)
def  str (self): return self.name
class Meta: managed = False
db_table = 'CarBody'
class Client(models.Model):
f_name = models.CharField(max_length=50) s_name = models.CharField(max_length=50) m_name = models.CharField(max_length=50)
address = models.CharField(max_length=100, blank=True, null=True) phone = models.CharField(max_length=30)
discount	=	models.ForeignKey('Discount',	models.DO_NOTHING, db_column='discount')
def   str  (self):
return f'{self.s_name} {self.f_name[0]}.{self.m_name[0]} ({self.phone})'
class Meta: managed = False db_table = 'Client'
class Contract(models.Model):
client = models.ForeignKey(Client, models.DO_NOTHING, db_column='client') auto = models.ForeignKey(Auto, models.DO_NOTHING, db_column='auto') start_date = models.DateTimeField()
end_date = models.DateTimeField(blank=True, null=True)
penalty = models.ForeignKey('Penalty', models.DO_NOTHING, db_column='penalty', blank=True, null=True)
delay_fee	=	models.ForeignKey('Delayfee',	models.DO_NOTHING, db_column='delay_fee', blank=True, null=True)
def   str  (self):
return f'{self.client} - {self.auto}'
class Meta: managed = False
db_table = 'Contract'
class Delayfee(models.Model): delay = models.IntegerField()
cost = models.DecimalField(max_digits=10, decimal_places=2)
def   str  (self):
return str(self.delay)
class Meta: managed = False
db_table = 'DelayFee'
class Discount(models.Model):
name = models.CharField(max_length=100)
value = models.DecimalField(max_digits=10, decimal_places=2)
def  str (self): return self.name
class Meta: managed = False
db_table = 'Discount'
class Discout(models.Model):
name = models.CharField(max_length=100)
value = models.DecimalField(max_digits=10, decimal_places=2)
def  str (self): return self.name
class Meta: managed = False
db_table = 'Discout'
class Penalty(models.Model):
name = models.CharField(max_length=100)
cost = models.DecimalField(max_digits=10, decimal_places=2)
def  str (self): return self.name
class Meta: managed = False
db_table = 'Penalty'
class Yearfee(models.Model): year = models.IntegerField() fee = models.IntegerField()
def  str (self): return str(self.year)
class Meta: managed = False
db_table = 'YearFee'
Содержимое файла settings.py
"""
Django settings for carrent project.
Generated by 'django-admin startproject' using Django 5.2.
For more information on this file, see https://docs.djangoproject.com/en/5.2/topics/settings/
For the full list of settings and their values, see https://docs.djangoproject.com/en/5.2/ref/settings/ """
from pathlib import Path
# Build paths inside the project like this: BASE_DIR / 'subdir'. BASE_DIR = Path( file ).resolve().parent.parent
# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/5.2/howto/deployment/checklist/
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY	=	'django-insecure-w=)v37470@e^yuoytqmn@amj8+2=frf-+u#jsg
%f*6zkwyscav'
# SECURITY WARNING: don't run with debug turned on in production! DEBUG = True
ALLOWED_HOSTS = ['127.0.0.1', '10.0.2.2']
# Application definition
INSTALLED_APPS = [
'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'core'
]
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
ROOT_URLCONF = 'carrent.urls' TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates', 'DIRS': [],
'APP_DIRS': True, 'OPTIONS': {
'context_processors': [ 'django.template.context_processors.request', 'django.contrib.auth.context_processors.auth', 'django.contrib.messages.context_processors.messages',
],
},
},
]
WSGI_APPLICATION = 'carrent.wsgi.application'
# Database
# https://docs.djangoproject.com/en/5.2/ref/settings/#databases
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql', 'NAME': 'carrent',
'USER': 'root',
'PASSWORD': 'ek5lmdupmysql', 'HOST': 'localhost',
'PORT': '3306'
}
}
# Password validation
# https://docs.djangoproject.com/en/5.2/ref/settings/#auth-password-validators
AUTH_PASSWORD_VALIDATORS = [
]
# Internationalization
# https://docs.djangoproject.com/en/5.2/topics/i18n/ LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'UTC'
USE_I18N = True USE_TZ = True
# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/5.2/howto/static-files/
STATIC_URL = 'static/'
STATICFILES_DIRS = (f'{BASE_DIR}/static',)
# Default primary key field type
# https://docs.djangoproject.com/en/5.2/ref/settings/#default-auto-field
DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'
Содержимое файла views.py
from django.shortcuts import render from django.views import View
import core.logic_for_tables as tlogic import core.logic_for_reports as rlogic
class IndexView(View): def get(self, request):
action = tlogic.create_tables_list(request) return action.render()
def post(self, request): pass
class TableView(View): def get(self, request):
pass
def post(self, request): tlogic.choose_action(request)
action = tlogic.show_table_content(request) return action.render()
class ReportView(View): def get(self, request):
action = rlogic.create_report(request, 'active_orders')
return action.render()
def post(self, request):
report_name = request.POST.get('report') print(report_name)
action = rlogic.create_report(request, report_name) return action.render()