Как написать курсовую работу по базе данных «Прокат яхт» – пошаговое руководство от А до Я

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

Целью настоящей курсовой работы является разработка реляционной базы данных для информационной системы «Прокат яхт». Эта система призвана автоматизировать ключевые операции: от приема заявки от клиента до возвращения яхты и проведения финальных расчетов. Для достижения этой цели были поставлены следующие задачи:

• Проанализировать предметную область — бизнес-процессы компании по прокату яхт.
• Спроектировать концептуальную, логическую и физическую модели данных.
• Реализовать структуру базы данных с помощью языка определения данных SQL (DDL).
• Разработать набор демонстрационных SQL-запросов для решения типичных бизнес-задач.

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

Глава 1. Теоретический фундамент для разработки базы данных

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

Ключевым процессом при проектировании реляционных БД является нормализация. Ее цель — устранить избыточность и возможные аномалии (ошибки) при добавлении, обновлении или удалении данных. Процесс нормализации состоит из нескольких этапов, называемых нормальными формами (НФ):

1. Первая нормальная форма (1НФ): Все атрибуты (столбцы) таблицы должны быть атомарными, то есть содержать только одно значение. В таблице не должно быть повторяющихся строк.
2. Вторая нормальная форма (2НФ): Таблица должна быть в 1НФ, и все неключевые атрибуты должны полностью зависеть от всего первичного ключа (а не от его части).
3. Третья нормальная форма (3НФ): Таблица должна быть во 2НФ, и все неключевые атрибуты должны зависеть только от первичного ключа, а не от других неключевых атрибутов.

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

Теперь, вооружившись необходимой теорией, мы можем приступить к самому интересному — практической реализации нашей системы «Прокат яхт».

Глава 2. Практическая реализация системы «Прокат яхт»

2.1. Как устроен бизнес по прокату яхт. Анализируем предметную область

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

• Клиенты: Люди или организации, которые берут яхты в аренду.
• Яхты: Флот судов, доступных для проката, каждая со своими характеристиками.
• Сотрудники: Персонал, который оформляет аренду и обслуживает яхты.

Основной бизнес-процесс — это Аренда. Он включает в себя прием заявки, бронирование конкретной яхты на определенные даты, передачу ее клиенту и приемку по возвращении. Параллельно с арендой существуют и другие процессы, такие как Оплата аренды и заказ Дополнительных услуг (например, услуги капитана или кейтеринг).

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

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

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

2.2. Создаем визуальный чертеж. Проектирование концептуальной модели ERD

Чтобы превратить наше словесное описание в формализованную структуру, используется концептуальная модель. Наиболее популярным инструментом для ее визуализации является ER-диаграмма (Entity-Relationship Diagram), или диаграмма «сущность-связь». Она наглядно показывает основные объекты системы и то, как они взаимодействуют.

На основе анализа из предыдущего пункта мы выделяем следующие основные сущности:

• Клиенты
• Яхты
• Аренда
• Сотрудники
• Дополнительные услуги
• Оплаты

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

В курсовой работе здесь необходимо привести саму диаграмму в виде рисунка. Ниже представлено ее текстовое описание.

Ключевые связи в нашей системе:

• «Один-ко-многим» (1:N):
  • Один Клиент может совершить много Аренд (связь `Клиенты`-`Аренда`).
  • Одна Яхта может быть сдана во много Аренд (в разное время, разумеется) (связь `Яхты`-`Аренда`).
  • Один Сотрудник может оформить много Аренд (связь `Сотрудники`-`Аренда`).
  • К одной Аренде может относиться несколько Оплат (например, аванс и финальный расчет).
• «Многие-ко-многим» (M:N):
  • Одна Аренда может включать несколько Дополнительных услуг, и одна и та же Услуга может быть заказана в разных Арендах.

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

2.3. От чертежа к плану. Разработка логической и физической моделей

Теперь мы переходим от абстрактной ER-диаграммы к более конкретным моделям. Этот этап делится на две части.

1. Логическая модель. На этом шаге мы преобразуем каждую сущность в реляционную таблицу. Для каждой таблицы мы определяем атрибуты (поля), а также назначаем первичный ключ (Primary Key, PK) — уникальный идентификатор для каждой записи. Для реализации связей мы используем внешние ключи (Foreign Key, FK) — поля, которые ссылаются на первичные ключи в других таблицах. Связь «многие-ко-многим» (`Аренда` — `Допуслуги`) разрешается через создание промежуточной, ассоциативной таблицы, например, `Аренда_Услуги`.

2. Физическая модель. Здесь мы финализируем наш план, уточняя технические детали для конкретной СУБД. Для каждого поля (атрибута) мы выбираем конкретный тип данных (например, `INT` для целых чисел, `VARCHAR(100)` для строк до 100 символов, `DATE` для дат, `DECIMAL(10, 2)` для денежных сумм) и задаем ограничения (например, `NOT NULL`, если поле не может быть пустым).

Ниже представлено описание структуры основных таблиц:

Таблица `Яхты` (Yachts)

• YachtID (PK): INT, NOT NULL, Уникальный идентификатор яхты
• Model: VARCHAR(100), NOT NULL, Модель яхты
• Capacity: INT, Вместимость (человек)
• PricePerDay: DECIMAL(10, 2), NOT NULL, Цена аренды в день
• Status: VARCHAR(50), Статус («Свободна», «В аренде» и т.д.)

Таблица `Клиенты` (Clients)

• ClientID (PK): INT, NOT NULL, Уникальный идентификатор клиента
• FirstName: VARCHAR(100), NOT NULL, Имя
• LastName: VARCHAR(100), NOT NULL, Фамилия
• Phone: VARCHAR(20), Телефон

Таблица `Аренда` (Rents)

• RentID (PK): INT, NOT NULL, Уникальный идентификатор аренды
• ClientID (FK): INT, NOT NULL, Ссылка на клиента
• YachtID (FK): INT, NOT NULL, Ссылка на яхту
• StartDate: DATE, NOT NULL, Дата начала аренды
• EndDate: DATE, NOT NULL, Дата окончания аренды
• TotalPrice: DECIMAL(10, 2), Общая стоимость

У нас есть детальный технический план. Пришло время «построить дом» — написать SQL-код, который создаст структуру нашей базы данных на сервере.

2.4. Воплощаем план в коде. Разработка объектов базы данных через DDL

Для создания структуры базы данных используется язык DDL (Data Definition Language). Его основной и самый важный оператор — `CREATE TABLE`, который, как следует из названия, создает новую таблицу в базе данных.

При создании таблиц крайне важен правильный порядок: сначала нужно создавать родительские таблицы (на которые ссылаются), и только потом — дочерние (которые содержат внешние ключи). В нашем случае сначала создаются `Clients` и `Yachts`, а уже потом `Rents`, которая на них ссылается.

Ниже приведен полный SQL-скрипт для создания основных таблиц нашей БД. Комментарии (`—`) поясняют назначение ограничений.

-- Создание таблицы для клиентов
CREATE TABLE Clients (
    ClientID INT PRIMARY KEY,
    FirstName VARCHAR(100) NOT NULL,
    LastName VARCHAR(100) NOT NULL,
    Phone VARCHAR(20)
);

-- Создание таблицы для яхт
CREATE TABLE Yachts (
    YachtID INT PRIMARY KEY,
    Model VARCHAR(100) NOT NULL,
    Capacity INT,
    PricePerDay DECIMAL(10, 2) NOT NULL,
    Status VARCHAR(50)
);

-- Создание таблицы для аренд
CREATE TABLE Rents (
    RentID INT PRIMARY KEY,
    ClientID INT NOT NULL,
    YachtID INT NOT NULL,
    StartDate DATE NOT NULL,
    EndDate DATE NOT NULL,
    TotalPrice DECIMAL(12, 2),
    -- Установка внешнего ключа для связи с таблицей клиентов
    CONSTRAINT FK_Rents_Clients FOREIGN KEY (ClientID) REFERENCES Clients(ClientID),
    -- Установка внешнего ключа для связи с таблицей яхт
    CONSTRAINT FK_Rents_Yachts FOREIGN KEY (YachtID) REFERENCES Yachts(YachtID)
);

Для ускорения поиска по часто используемым полям, таким как `ClientID` и `YachtID` в таблице `Rents`, рекомендуется создавать индексы. В большинстве СУБД они создаются автоматически для первичных и внешних ключей.

Каркас базы данных создан. Теперь его нужно наполнить «жизнью» — тестовыми данными, чтобы проверить работоспособность и выполнять запросы.

2.5. Наполняем базу данными. Работа с DML-операторами

Чтобы наполнить наши таблицы данными, мы используем язык DML (Data Manipulation Language), а именно оператор `INSERT INTO`. Этот оператор позволяет добавлять новые строки в указанную таблицу. Как и при создании таблиц, здесь важна последовательность: нельзя создать запись об аренде для клиента, которого еще нет в базе.

Приведем примеры заполнения для наших таблиц.

-- Добавляем двух клиентов
INSERT INTO Clients (ClientID, FirstName, LastName, Phone) VALUES
(1, 'Иван', 'Петров', '+79111234567'),
(2, 'Анна', 'Сидорова', '+79217654321');

-- Добавляем две яхты
INSERT INTO Yachts (YachtID, Model, Capacity, PricePerDay, Status) VALUES
(101, 'Bavaria Cruiser 46', 8, 35000.00, 'Свободна'),
(102, 'Hanse 315', 4, 20000.00, 'Свободна');

-- Создаем аренду для клиента Ивана Петрова (ID=1) на яхту Bavaria (ID=101)
INSERT INTO Rents (RentID, ClientID, YachtID, StartDate, EndDate, TotalPrice) VALUES
(1001, 1, 101, '2025-08-10', '2025-08-15', 175000.00);

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

База данных создана и наполнена. Настало время проверить, может ли она выполнять свою главную функцию — предоставлять нужную информацию по запросу.

2.6. Извлекаем пользу. Примеры практических SQL-запросов к базе

Главная цель создания БД — быстро получать ответы на бизнес-вопросы. Это делается с помощью оператора `SELECT` языка SQL. Продемонстрируем это на нескольких примерах, от простого к сложному, чтобы доказать работоспособность нашего проекта.

1. Бизнес-вопрос: Показать все яхты, цена аренды которых меньше 25000 рублей в день.
Задача: Простой запрос с фильтрацией по условию `WHERE`.

SELECT Model, PricePerDay
FROM Yachts
WHERE PricePerDay < 25000;

2. Бизнес-вопрос: Показать все оформленные аренды, с указанием имен клиентов и моделей яхт.
Задача: Запрос, требующий соединения (`JOIN`) трех таблиц: `Rents`, `Clients` и `Yachts`.

SELECT r.RentID, r.StartDate, c.FirstName, c.LastName, y.Model
FROM Rents AS r
JOIN Clients AS c ON r.ClientID = c.ClientID
JOIN Yachts AS y ON r.YachtID = y.YachtID;

3. Бизнес-вопрос: Посчитать общую сумму выручки от всех аренд.
Задача: Запрос с использованием агрегатной функции `SUM()`.

SELECT SUM(TotalPrice) AS TotalRevenue
FROM Rents;

4. Бизнес-вопрос: Найти клиентов, которые арендовали яхты более одного раза.
Задача: Запрос с группировкой (`GROUP BY`) и фильтрацией по результату агрегации (`HAVING`).

SELECT c.ClientID, c.FirstName, c.LastName, COUNT(r.RentID) AS NumberOfRents
FROM Clients AS c
JOIN Rents AS r ON c.ClientID = r.ClientID
GROUP BY c.ClientID, c.FirstName, c.LastName
HAVING COUNT(r.RentID) > 1;

5. Бизнес-вопрос: Показать все яхты, которые свободны в данный момент.
Задача: Запрос с условием по полю `Status`.

SELECT YachtID, Model, Capacity
FROM Yachts
WHERE Status = 'Свободна';

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

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

Заключение и финальные штрихи

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

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

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

При оформлении работы обратите внимание на следующие разделы:

• Список литературы: Включите в него учебники по базам данных и SQL, ГОСТы по оформлению документации и статьи, которые вы использовали.
• Приложения: Чтобы не загромождать основной текст, рекомендуется вынести в приложения весь листинг SQL-кода, полноразмерные ER-диаграммы и другие крупные графические материалы.

Работа написана. Финальный рывок — убедиться, что все сделано идеально.

Чек-лист для самопроверки перед сдачей

Перед тем как сдать работу, пройдитесь по этому короткому списку. Это поможет избежать досадных ошибок и повысить итоговую оценку.

• Структура: Соответствует ли структура работы заданию (введение, главы, заключение, список литературы, приложения)?
• Оформление: Все ли рисунки (диаграммы) и таблицы пронумерованы и имеют подписи? Есть ли на них ссылки в тексте?
• Код: Проверен ли ваш SQL-код на работоспособность? Выполняются ли скрипты без ошибок?
• Требования вуза: Соответствует ли оформление (шрифты, отступы, титульный лист) методическим указаниям вашего учебного заведения?
• Грамотность: Проверена ли работа на орфографические и пунктуационные ошибки?
• Логика: Содержат ли выводы в заключении четкие ответы на задачи, которые были поставлены во введении?

Список источников информации

1. 1. Агальцов, В.П. Базы данных. В 2-х т. Т.1. Локальные базы данных: Учебник [Текст]/ В.П. Агальцов. — М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013. -352 c.
2. 2. Агальцов, В.П. Базы данных. В 2-х т. Т.2. Распределенные и удаленные базы данных: Учебник [Текст]/ В.П. Агальцов. — М.: ИД ФОРУМ, НИЦ ИНФРА -М, 2013. -272 c.
3. 3. Алешин, Л. И. Автоматизированные информационные системы/ Л.И. Алешин. – 3-е изд. — СПб.: Питер 2012. – 290 с.
4. 4. Быкова, В.В. Искусство создания базы данных в MS Access: учебное пособие [Текст]/ В.В. Быкова. – М.: Проспект, 2015. – 121с.
5. 5. Вичугова, А.А. Методы и средства концептуального проектирования информационных систем: сравнительный анализ структурного и объектно-ориентированного подходов. // Прикладная информатика. — 2014. — №1(49). — С.56-58
6. 6. Галямина, И.Г. Управление процессами: Учебник для вузов. Стандарт третьего поколения / И.Г. Галямина. — СПб.:Питер, 2013. – 304с.
7. 7. Голицына, О.Л. Базы данных: Учебное пособие [Текст] / О.Л. Голицына, Н.В. Максимов, И.И. Попов. — М.: Форум, 2012. — 400 c.
8. 8. Кириллов В.В. Введение в реляционные базы данных. Введение в реляционные базы данных [Текст]/ В.В. Кириллов, Г.Ю. Громов. — СПб.: БХВ-Петербург, 2012. — 464 c.
9. 9. Кузин А.В. Базы данных: Учебное пособие для студ. высш. учеб. Заведений [Текст]/ А.В. Кузин, С.В. Левонисова. — М.: ИЦ Академия, 2012. — 320 c.
10. 10. Латыпова, Р.Р. Базы данных. Курс лекций: учебное пособие [Текст]/ Р.Р. Латыпова. – М.: Проспект, 2015. – 94с.
11. 11. Мирошниченко, Г.А. реляционные базы данных: практические приемы оптимальных решений/ Г.А. Мирошниченко. — СПб: БХВ-Петербург, 2010. – 400с.
12. 12. Михеева, Е.В. Информационные технологии в профессиональной деятельности/ Е.В. Михеева. — М.: Проспект, 2010. – 419 с.
13. 13. Нурмухамедов, Г.М. Информатика. Теоретические основы. Учебное пособие для подготовки к ЕГЭ/ Г.М. Нурмухамедов. — СПб.: БХВ-Петербург, 2012. – 208с.
14. 14. Орлов, С.А., Цилькер, Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. 4-е издание. Стандарт третьего поколения/ С.А. Орлов, Б.Я. Цилькер. — СПб.: Питер, 2012. – 608с.
15. 15. Пирогов, В.Ю. Информационные системы и базы данных: организация и проектирование: учебное пособие/ В.Ю. Пирогов. СПб: БХВ-Петербург, 2012. – 528с.
16. 16. Microsoft Office. Состав, назначение, основные программы-приложения [Электронный ресурс] Режим доступа: http://www.yaklass.ru/materiali?mode=cht&chtid=483