Курсовая ПрБД, 2 курс 3 семестр (для ИВТ и т.п.) / Курсовая ПБД готовая

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

4)Вывод всех квартир, включая свободные и без договоров аренды (с использованием внешнего соединения таблиц)

5)Разбор адреса филиала на уровни с использованием псевдорекурсивного соединения (с использованием рекурсивного соединения)

6)Вывод всех арендаторов, у которых есть договоры аренды (с использованием соединения по отношению)

7)Средняя, минимальная и максимальная сумма аренды по всем договорам (с использованием функций агрегирования)

8)Общая сумма платежей по каждому типу платежа (перекрестный

запрос)

9)Изменение статуса технической заявки (запрос на изменение)

10)Расчёт итоговой суммы аренды с учётом залога и штрафов (с вычисляемым полем)

11

3 Проектирование реляционной базы данных

3.1Концептуальноепроектирование

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

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

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

Ниже приведены сущности концептуальной модели и описание их атрибутов (таблицы 1-4).

Таблица 1

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

12

Таблица 2

Сущность «Арендаторы»

заключённых между владельцем (через агентство) и арендатором, штрафах, осмотрах и платежах, связанные с данным договором.

Таблица 4

Сущность «Филиалы агентства»

13

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

ER-диаграмма для концептуальной модели изображена на рисунке 1.

Рис. 1 – Концептуальная модель

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

3.2 Логическое проектирование

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

14

целостности данных и приведение отношений к нормальным формам. На базе концептуальной модели выполняется последовательная нормализация отношений: приведение к 1НФ, затем 2НФ и 3НФ.

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

Приведение к 1 нормальной форме (1НФ)

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

Висходной концептуальной модели такие атрибуты, как ФИО/название организации, Адрес регистрации, Контактный телефон, оставлены атомарными, что соответствует правилам 1НФ. Однако в сущностях присутствуют многозначные атрибуты, например: Список квартир, Список договоров управления, Платежи, Штрафы, Список менеджеров и Список заявок.

В1НФ многозначные значения допускаются только как псевдоатомарные поля, но их внутренняя структура не раскрывается. Поэтому модель в 1НФ практически совпадает с концептуальной. На этом этапе структура таблиц остаётся прежней, но считается приведённой к 1НФ. Модель 1НФ представлена на рисунке 2.

15

Рис. 2 – Модель в 1НФ

Приведение ко 2 нормальной форме (2NF)

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

Внашей модели все первичные ключи являются простыми, следовательно нарушения 2НФ связаны не с частичной зависимостью, а с наличием повторяющихся групп и многозначных атрибутов, которые необходимо вынести в отдельные сущности. Поэтому на этапе 2НФ выполняются два преобразования: удаление всех списочных (многозначных) атрибутов и создание новых сущностей и добавление внешних ключей.

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

– Квартиры — из Списка квартир владельца.

– Договоры управления — из Списка договоров управления.

– Менеджеры — из Списка менеджеров филиала.

– Платежи — из Информации о платежах арендатора и Платежей в

договорах.

– Штрафы — из одноимённого списка в договорах.

16

–Технические заявки — из Списка заявок филиала и Технических проблем договора.

–Осмотры — из Осмотров в договорах.

Кроме того, псевдоатомарный атрибут Срок действия в договоре заменён двумя атомарными полями: Дата начала, Дата окончания.

Модель 2НФ представлена на рисунке 3.

Рис. 3 – Модель в 2НФ

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

Модель 2НФ имеет две транзитивных зависимостей:

– Менеджер → Филиал → Договор.

В договоре имеется атрибут idФилиала, поэтому возникает зависимость idДоговора → idМенеджера → idФилиала. Поэтому idФилиала в договорах не должно быть, т.к. он однозначно определяется через idМенеджера.

– Квартира → Владлец → Договор.

17

Добавление idВладельца в договор создает транзитивную зависимость. Поэтому в договор должно включаться только idКвартиры.

После устранения зависимостей представляется модель 3НФ на рисунке

4.

Рис. 4 – Модель в 3НФ

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

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

целостность данных при выполнении операций добавления, обновления и

18

удаления. Представленная на рисунке 5 логическая модель является результатом нормализации.

Рис. 5 – Логическая ER-модель

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

3.3 Физическое проектирование

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

19

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

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

–выбор типов данных, поддерживаемых MySQL (INT, VARCHAR, DATE, DECIMAL, ENUM);

–формирование ограничений целостности (PRIMARY KEY, FOREIGN KEY, NOT NULL);

–определение индексов по ключевым атрибутам для ускорения выполнения запросов;

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

На рисунке 6 приведена структура физической модели, используемой при реализации базы данных на сервере Denwer.

Рис. 6 – Физическая модель

20