Проектирование и реализация базы данных для учета договоров аренды в курсовой работе

Введение, в котором мы определим цели и задачи нашей работы

В современной экономике использование баз данных и информационных систем становится неотъемлемой частью успешной деловой деятельности. Эффективное управление информацией — ключ к оптимизации бизнес-процессов, и компании любого масштаба сталкиваются с необходимостью автоматизации своих операций. Одной из таких областей является учет договоров аренды, где ручная обработка данных ведет к ошибкам, задержкам и неэффективному использованию ресурсов. Отсутствие единой системы затрудняет отслеживание сроков, платежей и состояния объектов, что создает прямые финансовые и юридические риски.

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

Для достижения поставленной цели необходимо решить несколько ключевых задач:

  • Детально изучить предметную область «Учет договоров аренды» и описать ее бизнес-процессы.
  • Спроектировать концептуальную и логическую модели будущей базы данных на основе проведенного анализа.
  • Реализовать спроектированную реляционную базу данных в среде системы управления базами данных (СУБД) MS Access.
  • Разработать пользовательский интерфейс (формы, запросы, отчеты) для комфортного взаимодействия с данными.

Определив цели и задачи, первым логичным шагом становится глубокое погружение в специфику бизнес-процессов, которые мы собираемся автоматизировать.

Глава 1. Системный анализ предметной области «Учет договоров аренды»

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

В ходе анализа мы можем выделить следующие основные сущности:

  1. Клиенты (Арендаторы): Субъекты, заключающие договор аренды. Важно учитывать, что клиентами могут быть как физические, так и юридические лица, что требует разных наборов данных.
    • Для физических лиц: ФИО, паспортные данные, контактный телефон, адрес регистрации.
    • Для юридических лиц: Полное наименование организации, юридический адрес, ИНН, банковские реквизиты.
  2. Объекты недвижимости: Имущество, сдаваемое в аренду. Необходимо хранить как общие данные о здании, так и характеристики конкретных помещений.
    • Атрибуты: Адрес, тип объекта (офис, склад, квартира), общая площадь, этаж, номер помещения, стоимость аренды за квадратный метр.
  3. Договоры: Юридический документ, фиксирующий условия сделки. Это центральная сущность, связывающая клиента и объект.
    • Атрибуты: Номер договора, дата заключения, сроки действия (начало и окончание), общая стоимость, периодичность оплаты, размер штрафов за просрочку.
  4. Платежи: Финансовые транзакции, связанные с исполнением договоров.
    • Атрибуты: Дата платежа, уплаченная сумма, назначение платежа (аренда, пени), ссылка на конкретный договор.

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

На основе этого анализа можно сформулировать функциональные требования к будущей базе данных. Система должна обеспечивать:

  • Централизованное хранение информации о клиентах, объектах и договорах.
  • Автоматический расчет арендной платы с учетом площади и ставки.
  • Формирование счетов на оплату и актов.
  • Учет поступающих платежей и отслеживание задолженностей.
  • Напоминания об окончании сроков действия договоров и необходимости внесения платежей.

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

Глава 2. Концептуальное проектирование будущей базы данных

Концептуальное проектирование — это этап, на котором мы переводим наши знания о предметной области в формализованную, но еще не зависящую от конкретной СУБД модель. Главным инструментом на этом этапе является модель «сущность-связь» (ER-модель, от англ. Entity-Relationship model), а ее графическое представление — ER-диаграмма. Эта диаграмма служит универсальным «чертежом» будущей базы данных, понятным как для разработчика, так и для заказчика.

Основываясь на анализе, проведенном в предыдущей главе, мы выделяем следующие ключевые сущности:

  • Клиенты
  • Договоры
  • Объекты
  • Платежи

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

В нашей предметной области прослеживаются следующие ключевые взаимосвязи:

  1. Связь «Клиенты» ↔ «Договоры». Один клиент может заключить несколько договоров аренды (например, на разные объекты или в разное время). Однако каждый конкретный договор заключается только с одним клиентом. Таким образом, между ними устанавливается связь типа «один-ко-многим» (1:M).
  2. Связь «Договоры» ↔ «Объекты». В рамках одного договора может быть арендовано несколько объектов (например, несколько офисов в одном здании). В то же время один и тот же объект в один период времени может быть связан только с одним активным договором. Если рассматривать возможность сдачи одного объекта разным арендаторам в разное время, то связь становится сложнее, но для курсового проекта мы можем упростить ее до «один-ко-многим» (1:M), где один договор может включать много объектов. Для более сложных сценариев могла бы понадобиться промежуточная таблица, создающая связь «многие-ко-многим».
  3. Связь «Договоры» ↔ «Платежи». По одному договору производится множество платежей в течение срока его действия. Каждый платеж относится строго к одному договору. Это классический пример связи типа «один-ко-многим» (1:M).

Графически на ER-диаграмме эти сущности изображаются в виде прямоугольников, а их атрибуты — в виде овалов. Связи изображаются линиями, соединяющими сущности, с указанием типа мощности связи (1, M). Такая диаграмма наглядно демонстрирует всю структуру данных, показывая, какая информация хранится в системе и как она между собой логически связана. Это наш фундамент для следующего, более технического этапа — логического проектирования.

Имея на руках концептуальную модель, мы должны преобразовать ее в реляционную структуру, пригодную для реализации в СУБД, и убедиться, что эта структура эффективна и не содержит избыточности.

Глава 3. Логическое проектирование и нормализация реляционной модели

Логическое проектирование — это процесс преобразования концептуальной ER-модели в реляционную модель, то есть в набор взаимосвязанных таблиц. Основная цель этого этапа — создать структуру, которая будет не только точно отражать предметную область, но и обеспечивать целостность, непротиворечивость и отсутствие избыточности данных. Ключевым инструментом для достижения этой цели является процесс нормализации.

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

  • Аномалия обновления: при изменении повторяющихся данных (например, ФИО клиента) приходится обновлять множество строк, что чревато ошибками.
  • Аномалия удаления: при удалении единственной записи о какой-либо операции (например, последнего договора клиента) можно случайно потерять всю информацию о самом клиенте.
  • Аномалия добавления: невозможно добавить информацию о новой сущности (например, о новом клиенте), пока она не будет связана с другой (пока он не заключит договор).

Процесс нормализации обычно выполняется до третьей нормальной формы (3NF), что является стандартом для большинства реляционных баз данных. Рассмотрим этот процесс на нашем примере.

Первая нормальная форма (1NF):
Таблица находится в 1NF, если все ее атрибуты являются атомарными (неделимыми), и она не содержит повторяющихся групп столбцов. Например, если бы мы в таблице «Договоры» создали поля «Объект1», «Объект2», мы бы нарушили 1NF. Правильное решение — вынести объекты в отдельную связанную таблицу.

Вторая нормальная форма (2NF):
Таблица находится в 2NF, если она находится в 1NF и каждый неключевой атрибут полностью зависит от всего составного первичного ключа. Это правило актуально для таблиц со составными ключами. Например, в связующей таблице «СоставДоговора» (ДоговорID, ОбъектID) поле «СтоимостьАренды» будет зависеть от обоих частей ключа, а вот «АдресОбъекта» — только от «ОбъектID», что является нарушением 2NF. Адрес должен храниться в таблице «Объекты».

Третья нормальная форма (3NF):
Таблица находится в 3NF, если она находится в 2NF и в ней отсутствуют транзитивные зависимости (когда неключевые поля зависят от других неключевых полей). Например, если бы в таблице «Клиенты» мы хранили «ИНН», «НаименованиеОрганизации» и «АдресОрганизации», то адрес и наименование зависели бы не от первичного ключа клиента, а от ИНН. Правильное решение — вынести реквизиты юридических лиц в отдельную таблицу, связанную с основной таблицей клиентов.

В результате процесса нормализации наша ER-модель преобразуется в следующий набор таблиц, приведенных к 3NF:

  1. tblClients: ClientID (PK), ClientType, FullName, PassportData, PhoneNumber, …
  2. tblLegalEntities: LegalEntityID (PK), ClientID (FK), CompanyName, INN, Address, …
  3. tblObjects: ObjectID (PK), Address, ObjectType, Area, PricePerMeter, …
  4. tblContracts: ContractID (PK), ClientID (FK), ContractNumber, StartDate, EndDate, …
  5. tblContractComposition: ContractCompositionID (PK), ContractID (FK), ObjectID (FK) — связующая таблица для реализации связи M:M, если один объект может входить в разные договоры.
  6. tblPayments: PaymentID (PK), ContractID (FK), PaymentDate, Amount, …

Каждая таблица имеет первичный ключ (PK) для уникальной идентификации записей и внешние ключи (FK) для связи с другими таблицами. Такая структура является оптимальной, масштабируемой и защищенной от аномалий. Когда теоретический фундамент заложен и структура таблиц определена, наступает этап практической реализации — создания нашей базы данных в конкретной инструментальной среде.

Глава 4. Физическая реализация базы данных в среде MS Access

После завершения логического проектирования наступает этап физической реализации — непосредственного создания структуры базы данных в выбранной СУБД. Для учебных проектов MS Access является одним из самых популярных и удобных инструментов, поскольку он сочетает в себе ядро реляционной базы данных и средства для быстрой разработки пользовательского интерфейса (форм, отчетов).

Процесс создания таблиц в MS Access на основе нашей нормализованной модели выглядит следующим образом. Для каждой таблицы, определенной в Главе 3, мы выполняем следующие шаги в режиме конструктора:

1. Создание таблицы `tblClients`

Эта таблица будет хранить общую информацию о всех клиентах.

  • ClientID: Тип данных «Счетчик». Это поле будет первичным ключом (PK) с автоматическим приращением.
  • ClientType: Тип данных «Короткий текст». Можно задать маску ввода или список допустимых значений («Физ. лицо», «Юр. лицо»).
  • FullName: Тип данных «Длинный текст» для ФИО или названия организации. Поле является обязательным.
  • PhoneNumber: Тип данных «Короткий текст». Рекомендуется использовать маску ввода для стандартизации формата.

2. Создание таблицы `tblObjects`

Справочник наших объектов недвижимости.

  • ObjectID: Тип данных «Счетчик» (PK).
  • Address: Тип данных «Длинный текст». Обязательное поле.
  • Area: Тип данных «Числовой» (с плавающей точкой).
  • PricePerMeter: Тип данных «Денежный».

Аналогичным образом создаются все остальные таблицы (`tblContracts`, `tblPayments` и т.д.). Для каждого поля важно не только выбрать правильное имя и тип данных, но и настроить его свойства: размер поля, формат, маска ввода, значение по умолчанию и, что очень важно, установить свойство «Обязательное поле» для ключевой информации.

После создания всех таблиц ключевым шагом является установление связей между ними. В MS Access это делается в специальном окне «Схема данных».

Здесь мы наглядно «перетаскиваем» поле первичного ключа из одной таблицы (например, `ClientID` из `tblClients`) на соответствующее поле внешнего ключа в другой таблице (`ClientID` в `tblContracts`). При создании связи необходимо установить флажок «Обеспечение целостности данных». Это заставит Access автоматически проверять, чтобы:

  • Нельзя было создать договор для несуществующего клиента.
  • Нельзя было удалить клиента, у которого есть активные договоры.

Таким образом, мы не просто создаем набор таблиц, а строим полноценную реляционную модель, где целостность и непротиворечивость данных поддерживается на уровне самой СУБД. База данных создана и наполнена структурой, но для удобной работы с ней необходим дружелюбный пользовательский интерфейс.

Глава 5. Разработка интерфейса для взаимодействия с данными

Даже идеально спроектированная база данных бесполезна, если конечный пользователь не может удобно и безопасно с ней работать. Работа напрямую с таблицами неудобна и рискованна — можно случайно удалить или изменить важные данные. Для решения этой проблемы в MS Access и других СУБД используются формы. Форма — это основной элемент пользовательского интерфейса, который представляет данные в привычном и логичном виде и позволяет выполнять операции ввода, редактирования и просмотра.

В рамках нашего проекта необходимо создать несколько ключевых форм, каждая из которых решает свою задачу:

  1. Форма «Карточка клиента». Эта форма предназначена для добавления новых и редактирования существующих клиентов. Она должна содержать все поля из таблицы `tblClients`. Для удобства можно использовать вкладки, чтобы разделить основную информацию и, например, банковские реквизиты (для юридических лиц). На форме обязательно должны быть кнопки управления: «Добавить нового клиента», «Сохранить изменения», «Удалить».
  2. Форма «Договор аренды». Это более сложная, составная форма. Основная часть формы будет связана с таблицей `tblContracts` и отображать общие данные договора (номер, даты, клиент). В качестве поля для выбора клиента лучше использовать не просто текстовое поле, а раскрывающийся список, который подгружает ФИО из таблицы `tblClients`.

    Ключевой особенностью этой формы является наличие подчиненной формы, связанной с таблицей `tblContractComposition`. Эта подчиненная форма будет выглядеть как таблица и позволит добавлять в договор один или несколько объектов недвижимости из справочника.

  3. Форма «Учет платежей». Простая форма для регистрации факта оплаты по договору. Она может содержать поле для выбора договора (также в виде списка), поле для ввода даты и суммы платежа. Кнопка «Сохранить платеж» будет добавлять новую запись в таблицу `tblPayments`.

При создании форм важно активно использовать различные элементы управления, которые предоставляет Access: текстовые поля, списки, поля со списком, переключатели и кнопки. Каждый элемент управления связывается с соответствующим полем в источнике данных (таблице или запросе). Грамотно спроектированные формы скрывают от пользователя сложную табличную структуру, направляют его действия и минимизируют вероятность ошибок при вводе данных.

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

Глава 6. Создание запросов для анализа и выборки данных

Данные, хранящиеся в таблицах, приобретают настоящую ценность только тогда, когда мы можем их извлекать, анализировать и преобразовывать в полезную информацию. Инструментом для решения этих задач в реляционных базах данных являются запросы. Запрос — это формальная инструкция к СУБД, позволяющая фильтровать, сортировать, объединять данные из нескольких таблиц и выполнять над ними вычисления.

В MS Access запросы можно создавать в удобном графическом конструкторе, который позволяет даже без знания языка SQL строить сложные выборки. Рассмотрим несколько практических примеров запросов, необходимых для нашей системы:

  1. Простой запрос на выборку: «Найти всех арендаторов из определенного города».
    • Задача: Получить список клиентов, зарегистрированных в заданном городе.
    • Реализация: В конструктор добавляется таблица `tblClients`. В итоговую выборку перетаскиваются поля «FullName» и «PhoneNumber». В поле «Address» в строку «Условие отбора» вписывается название нужного города, например, `Like «*Москва*»`.
  2. Запрос с параметром: «Показать все договоры, заключенные за период».
    • Задача: Дать пользователю возможность указать начальную и конечную даты и получить список договоров, заключенных в этом интервале.
    • Реализация: В конструктор добавляются таблицы `tblContracts` и `tblClients`. В строку «Условие отбора» для поля `StartDate` пишется `>[Введите начальную дату]` и `<[Введите конечную дату]`. При каждом запуске запроса Access будет показывать диалоговое окно для ввода дат.
  3. Вычисляемый запрос: «Расчет задолженности по договорам».
    • Задача: Для каждого активного договора рассчитать общую сумму начисленной аренды и сравнить ее с общей суммой платежей.
    • Реализация: Это более сложный запрос, требующий группировки и вычислений. Сначала создается итоговый запрос, который суммирует все платежи (`Amount`) по каждому `ContractID` из таблицы `tblPayments`. Затем создается основной запрос, который связывает `tblContracts` с первым запросом и вычисляет разницу между полем `TotalCost` и суммой платежей.
  4. Итоговый запрос: «Отчет по поступлениям за месяц».
    • Задача: Сгруппировать все платежи по месяцам и посчитать общую сумму поступлений за каждый месяц.
    • Реализация: В конструктор добавляется таблица `tblPayments`. Включается режим «Групповые операции». В качестве поля для группировки используется выражение `Format([PaymentDate], «yyyy-mm»)`, а для поля `Amount` выбирается агрегатная функция `Sum`.

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

Мы научились извлекать и анализировать данные. Финальный штрих — представить эти данные в удобном для печати и восприятия виде.

Глава 7. Формирование отчетности для принятия решений

Финальным этапом работы с данными является их представление в виде документов, пригодных для печати, сохранения в PDF или отправки по электронной почте. Для этих целей в базах данных используются отчеты. Отчет — это средство для визуализации и документирования информации, которое позволяет сгруппировать, отсортировать и красиво оформить данные, полученные из таблиц или, что более предпочтительно, из запросов.

В рамках нашей системы учета аренды можно создать несколько ключевых отчетов:

  1. Отчет «Список действующих договоров».
    • Назначение: Предоставить менеджеру сводную информацию по всем активным договорам.
    • Источник данных: Запрос, который выбирает договоры, у которых дата окончания больше текущей.
    • Структура: В конструкторе отчетов данные можно сгруппировать по полю «Клиент». В заголовке группы будет выводиться ФИО клиента, а в области данных — список его договоров с указанием номеров, сроков и стоимости. В конце отчета можно вывести итоговое поле, подсчитывающее общее количество активных договоров.
  2. Отчет «Счет на оплату аренды».
    • Назначение: Сформировать печатный документ для конкретного арендатора на оплату за определенный месяц.
    • Источник данных: Параметрический запрос, который по ID договора и нужной дате выбирает все необходимые реквизиты клиента, договора и рассчитывает сумму к оплате.
    • Структура: Отчет будет оформлен по стандартам бухгалтерского документа. Он будет содержать реквизиты арендодателя и арендатора, таблицу с наименованием услуги («Аренда за октябрь 2025 г.»), количество, цену и сумму. Все эти данные будут динамически подставляться из запроса при формировании отчета.

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

Разработав все компоненты системы — от таблиц до отчетов, — мы завершили практическую часть работы и можем подвести итоги.

Заключение, где мы подведем итоги проделанной работы

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

Были последовательно пройдены все ключевые этапы проектирования и реализации:

  • Проведен системный анализ предметной области, в результате которого были определены основные сущности, их атрибуты и бизнес-процессы.
  • На основе анализа была построена концептуальная модель «сущность-связь» и выполнено логическое проектирование с нормализацией таблиц до третьей нормальной формы (3NF), что обеспечило целостность и отсутствие избыточности данных.
  • Создана физическая база данных в среде СУБД MS Access, включая таблицы с заданными типами данных и схему данных с обеспечением целостности.
  • Разработан дружелюбный пользовательский интерфейс, состоящий из форм для ввода и редактирования данных, запросов для их анализа и отчетов для формирования итоговых документов.

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

  • Интеграцию с бухгалтерскими системами, например, с , для автоматической передачи финансовых данных.
  • Реализацию веб-интерфейса или использование облачных хранилищ для обеспечения удаленного доступа к базе данных для сотрудников.
  • Добавление модуля автоматических email-оповещений о предстоящих платежах и окончании сроков договоров.

Список использованной литературы

  1. Ананьев П.И., Беспалова Е.Э., Кайгородова М.А. Базы данных: Методические указания к выполнению курсовой работы. – Барнаул: изд-во ААЭП, 2005г.
  2. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений. – 4-е издание, С.-П.: Корона принт, 2004г.
  3. Дженнингс, Роджер. Использование Microsoft Access 2002. Специальное издание, Вильямс, 2002.
  4. Адрианов В. Россия в мировом процессе развития средств связи, компьютеризации и информатизации//Экономист, 2006, №8
  5. Гражданское право. Практикум Под.ред. Н.Д.Егорова, А.П.Сергеева, ч.2, М., 1997г.
  6. Гражданское право. Учебник Под. Ред. Е.А.Суханова, т.2, М., 1993г.
  7. Общие положения об аренде, Сафулин Д., М., 1990г.
  8. Гражданский Кодекс РФ

Похожие записи