Агенство недвижимости

ВВЕДЕНИЕ

Моя встреча будет посвящена созданию и развитию базы данных по купле-продаже недвижимости.

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

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

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

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

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

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

База данных – поименованная совокупность структурированных данных, относящихся к некоторой предметной области. В реальной деятельности в основном используют системы БД.

Также можно охарактеризовать как набор сведений, хранящихся некоторым упорядоченным способом. Можно сравнить базу данных со шкафом, в котором хранятся документы. Иными словами, база данных — это хранилище данных. Сами по себе базы данных не представляли бы интереса, если бы не было систем управления базами данных (СУБД).

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

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

1.2. Последовательность проектирования базы данных

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

Инфологическое проектирование;

Определение требований к операционной среде, в которой эксплуатируется информационная система;

Подбор системы управления базами данных (СУБД) и других программных средств;

Логическое проектирование БД;

Физическая структура базы данных.

1.2.1. Инфологическое проектирование

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

Инфологическая модель. ПрО – это описание структуры и динамики. ПрО, характер информационных потребностей пользователя, выраженный в терминах, понятных пользователю, и не зависящий от реализации базы данных. Это описание не относится к отдельным объектам. ПрО и отношения между ними, но и их типы, связанные с ними ограничения целостности и процессы, ведущие к их переходу. ПрО из одного состояния в другое [1].

Существуют следующие основные подходы к созданию инфологической модели субъекта:

Функциональный подход к проектированию БД ("от задач");

Объектный подход к проектированию БД ("от предметной области");

Метод "сущность-связь" (entity–relation, ER–method).

Наиболее широко будет использоваться метод "сущность-связь". Далее мы будем использовать основные понятия:

Сущность — это объект, о котором в системе собираются данные. Для сущности дается имя и тип (сильный или слабый). Сильные существа существуют сами по себе, а существование слабых зависит от существования сильных существ. [2]. Атрибут принадлежит сущности. Следует различать:

Идентификационные и описательные атрибуты. Идентифицирующие атрибуты помогают отличить один экземпляр объекта от другого. Описательные атрибуты включают свойства объекта;

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

Однозначные и многозначные атрибуты (могут иметь одно или несколько значений для каждого экземпляра сущности). Например, дата рождения — это однозначный атрибут, а номер телефона — многозначный атрибут;

Основные и производные атрибуты. Значение первичного атрибута не зависит от других атрибутов; значение производного атрибута вычисляется из значений других атрибутов. Например, возраст рассчитывается на основе даты рождения и текущей даты;

Обязательные и необязательные (первые нужно указывать при вставке данных в БД, вторые можно не указывать).

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

Связь – это осмысленная ассоциация между сущностями. Связь имеет имя, тип (необязательный или обязательный), степень (1:1, 1:n или m:n) и кардинальность (унарная, бинарная, троичная или n-арная)[3]. На рис. 1 приведены обозначения, которые мы будем использовать в ER-диаграммах.

<Object: word/embeddings/oleObject1.bin>

Рис.1 – Обозначения, используемые в ER-диаграммах

1.2.3. Требования к операционной обстановке

На этом этапе оцениваются требования к вычислительным ресурсам, необходимым для работы системы, определяются тип и конфигурация компьютера, выбираются тип и версия операционной системы. Количество вычислительных ресурсов будет зависеть от ожидаемого размера планируемой базы данных и интенсивности ее использования. Если база данных будет работать в многопользовательском режиме, вам потребуется сетевое подключение и подходящая многозадачная операционная система, такая как Windows, OC UNIX, семейство MAC OS. В моем случае БД будет использовать только локальные ресурсы, что сразу снижает требования к уровню конфигурации компьютера, достаточно использовать архитектуру системы из семейства win32 и порт USB 2.0 или новее [4].

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

Учитывая ограниченный набор функций, я решил сосредоточиться на Microsoft Access 2013, мощной и высокопроизводительной 32-разрядной системе управления реляционными базами данных.

Будучи реляционной СУБД, Access обеспечивает доступ ко всем типам данных и позволяет одновременно использовать несколько таблиц базы данных. Также допускается использование электронные таблицы, созданных в средах Paradox или dBase. В среде Microsoft Office пользователю доступны текстовые документы (Word), электронные таблицы (Excel) и презентации (PowerPoint), полностью совместимые с Access. Присутствует возможность напрямую взаимодействовать с данными из WWW (World Wide Web) и просматривать данные в формате HTML (HyperText Markup Language) с помощью новых веб-расширений, позволяющих работать с такими приложениями, как Internet Explorer и Netscape Navigator и тому подобными ПО.

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

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

Фаза физического проектирования состоит в определении схемы хранения, т.е. физической структуры базы данных. Схема хранения данных зависит от физической структуры, поддерживаемой выбранной СУБД. Физическая структура базы данных должна адекватно отражать логическую структуру базы данных и обеспечивать эффективное размещение и быстрый доступ к данным. Результаты этого этапа документируются в виде схемы хранения данных на языке DDL (Data Definition Language) выбранной СУБД. Решения, принятые на этом этапе, оказывают большое влияние на производительность системы [5].

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

Этапы методологии проектирования физической базы данных:

Перенос глобальной логической модели данных в целевую среду базы данных;

Проектирование фундаментальных отношений;

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

Реализация доменных ограничений;

Проектирование физического представления базы данных;

Анализ транзакций;

Выбор файловой структуры;

Определение индексов;

Определение требований к дисковому пространству;

Разработка пользовательских представлений;

Проектирование защитных механизмов;

Обоснование необходимости контролируемого резервирования;

Постоянный мониторинг и настройка операционной системы;[6]

Особенности проектирования реляционной базы данных

При проектировании реляционной базы данных используется та же процедура, что и при проектировании других баз данных с моделью данных, но она имеет свои особенности. При проектировании схемы базы данных необходимо учитывать необходимость минимизировать дублирование данных и упростить процедуры обработки и обновления данных. Если схема базы данных неверна, могут возникнуть аномалии модификации данных. Они вызваны отсутствием инструментов для явного представления нескольких типов отношений между программными объектами и отсутствием инструментов для описания ограничений целостности на уровне модели данных. Для решения таких задач проводится нормализация отношений. Механизм нормализации отношений был разработан Э. Ф. Коддом [7]. Этот механизм позволяет преобразовать любое отношение с формальными свойствами в третью нормальную форму. Нормализация реляционной схемы достигается путем ее декомпозиции. Декомпозиция реляционной схемы R — это замена реляционной схемы R набором реляционных схем Ai таких, что Y i R = Ai, причем не обязательно, чтобы реляционные схемы Ai не были нейтральными по пересечению. Первая нормальная форма относится к понятиям простого и сложного (составного или многозначного) атрибута (см. параграф 1.2.1). Отношение сводится к 1НФ, если все его атрибуты просты. Для того чтобы свести отношение со сложными атрибутами к 1НФ, необходимо сделать следующее:

1) свести сложные атрибуты к простым атрибутам;

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

Для идентификации кортежа в этом случае потребуется составной ключ, включающий первичный ключ исходного отношения и все многозначные атрибуты. Вторая нормальная форма основана на понятии функциональной зависимости. Пусть X и Y — атрибуты некоторого отношения. Если в любой момент времени каждому значению X соответствует значение Y, то говорят, что Y функционально зависит от X (XY). Атрибут X в функциональной зависимости XY называется определителем отношения. В нормализованном отношении каждый не ключевой атрибут функционально зависит от ключа отношения. Атрибут, не являющийся ключом, функционально полностью зависит от составного ключа, если он функционально зависит от ключа, но функционально не зависит ни от какой части составного ключа.

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

построить его проекцию, исключив атрибуты, функционально независимые от первичного ключа;

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

- построить его проекцию, исключив атрибуты, функционально независимые от первичного ключа;

- кроме того, построение одной или нескольких проекций для части составного ключа и для атрибутов, функционально зависимых от этой части ключа. Третья нормальная форма основана на концепции транзитивной зависимости. Пусть X, Y, Z — атрибуты некоторого отношения. XY и YZ, но обратной зависимости нет, т.е. Z не зависит от Y или Y не зависит от X. Тогда говорят, что Z транзитивно зависит от X (XZ).

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

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

построить одну или несколько дополнительных проекций на детерминанты исходной связи и функционально зависимые признаки;

Исключение составляет случай, когда для транзитивной зависимости XZ (XY и YZ) либо Z зависит от Y, либо Y зависит от X, т. е. между признаками X и Y, например, имеется отношение 1:1. В такой ситуации отношения не разрываются.

Четвертая нормальная форма основана на понятии многозначной зависимости. Многозначная зависимость существует, если заданные значения атрибута X совпадают с набором нулевых (или более) значений атрибута Y (XY). Различают тривиальные и нетривиальные многозначные отношения. Тривиальное многозначное отношение — это отношение X — Y, для которого Y X или XUY = R, где R — рассматриваемое отношение. Тривиальное многозначное отношение не нарушает 4НФ. Если хотя бы одно из этих двух условий не выполняется удовлетворено, то называется такое отношение нетривиальным Четвертая нормальная форма (4НФ) Отношение находится в 4НФ, если оно находится в 3НФ и не имеет нетривиальных многозначных зависимостей. Чтобы привести отношение к 4НФ, необходимо создать два или больше проекций исходного отношения, каждая из которых содержит ключ и многозначную зависимость. [8]

Проведу краткий пересказ всего вышеперечисленного:

Первая нормальная форма (1НФ). Отношение сводится к 1НФ, если все его атрибуты простые (табл. 1). Чтобы свести отношение со сложными атрибутами к 1НФ, нам нужно сделать следующее:

1)свести сложные атрибуты к простым атрибутам,

2)построить декартово произведение всех многозначных атрибутов и соответствующих им кортежей.

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

Таблица 1 – Пример 1НФ

Вторая нормальная форма основана на понятии функциональной зависимости. Пусть X и Y — атрибуты некоторого отношения. Если в любой момент времени каждому значению X соответствует значение Y, то говорят, что Y функционально зависит от X (XY). Атрибут X в функциональной зависимости XY называется определителем отношения. В нормализованном отношении каждый не ключевой атрибут функционально зависит от ключа отношения. Не ключевой атрибут функционально полностью зависит от составного ключа, если он функционально зависит от ключа, но функционально не зависит ни от какой части составного ключа.

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

• построить проекцию, исключая атрибуты, которые функционально не полностью зависят от сложного первичного ключа;

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

Приведём пример такой таблицы. Изначальная таблица:

Таблица 2 – изначальная таблица

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

Таблица 3 – 2НФ таблицы

Третья нормальная форма (3НФ). Отношение является 3НФ (табл. 4, 5, 6), если оно является 2НФ, и все не ключевые атрибуты не являются транзитивными к первичному ключу. Для того чтобы привести отношение к 3НФ, нужно:

• построить проекцию, исключив транзитивно зависящие от ключа атрибуты;

• построить одну или несколько проекций на детерминанты исходных отношений и функционально зависимые от них атрибуты;

Для наглядности приведу пример таблицы в 3НФ:

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

Таблица 4 – Изначальная таблица

Таблица является 2НФ, но не 3НФ. Атрибут Модель является первичным ключом отношения. У автомобилей нет личного номера телефона, номер телефона зависит только от компании. Итак, в отношениях Модель → Магазин, Магазин → Телефон, Модель → Телефон существуют следующие функциональные зависимости.

Зависимость Модель → Телефон является транзитивной, поэтому эта связь не включена в 3НФ.

Таблица 5 – Первая таблица в 3НФ

Таблица 6 – Вторая таблица в 3НФ

Разделение исходного отношения дает два отношения, находящиеся в 3НФ:

Четвертая нормальная форма основана на понятии многозначной зависимости. Многозначная зависимость существует, если заданные значения атрибута X совпадают с набором нулевых (или более) значений атрибута Y (XY).

Мы различаем тривиальные и нетривиальные многозначные зависимости. Тривиальной многозначной зависимостью XY является такая зависимость, где Y U X или XUY = R, где R - рассматриваемое отношение. Тривиальное многозначное отношение не нарушает 4НФ. Если хотя бы одно из этих двух условий выполняется не выполняется, то такая зависимость называется нетривиальной [9].

Четвертая нормальная форма (4НФ). Отношение находится в 4НФ, если оно находится в 3НФ и нет нетривиальных многозначных зависимостей.

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

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

2.1. Инфологическое проектирование

2.1.1. Анализ предметной области

База данных «купли-продажи недвижимости» создается для выполнения услуг, реализации их типа риелторской фирмы. Большое количество подобных компаний осуществляют деятельность на территории нашей страны, сегодня многие имеют свои официальные представительства и информационные порталы в сети Интернет. На своих сайтах данные фирмы выкладывают доступные к реализации помещения, их типы, типы домов, в которых находятся те или иные пространства. Также, многие риелторские компании хранят в своих базах данных клиентов, которые ранее совершали сделки, а также хранят авторов подобных объявлений.

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

2.1.2. Целевая деятельность риелторов

Если осуществляется покупка недвижимости:

Если осуществляется продажа недвижимости:

Для создания ER-диаграммы необходимо выделить сущности предметной области:

Исходя из выявленных сущностей, построим ER-диаграмму (рис. 2). Пометки у линии означают степень связи: 1:1, 1:N и N:M.

Рис. 2 – ER-диаграмма (без выделения атрибутов)

2.1.3. Анализ информационных задач и круга пользователей системы

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

База данных купли-продажи недвижимости решает такие задачи, как:

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

2.2. Определение требований к операционной обстановке

На этом этапе производится оценка требований к вычислительным ресурсам, необходимым для функционирования системы, определение типа и конфигурации конкретной ЭВМ, выбор типа и версии операционной системы. Объём вычислительных ресурсов зависит от предполагаемого объёма проектируемой базы данных и от интенсивности их использования. Если БД будет работать в многопользовательском режиме, то требуется подключение её к сети и наличие соответствующей многозадачной операционной системы.

Для выполнения этого этапа необходимо знать (хотя бы ориентировочно) объём работы фирмы по прокату автомобилей (т.е. количество автомобилей и клиентов), а также иметь представление о характере и интенсивности запросов.

Объём внешней памяти, необходимый для функционирования системы, складывается из двух составляющих: память, занимаемая модулями СУБД (ядро, утилиты, вспомогательные программы), и память, отводимая под данные (МД). Наиболее существенным обычно является МД. Объём памяти МД, требуемый для хранения данных, можно приблизительно оценить по формуле где li – длина записи в i-й таблице (в байтах), Ni – примерное (максимально возможное) количество записей в i-й таблице, Na – количество записей в архиве i-й таблицы.

Минимальные требования к ПК:

ПК, с процессором на архитектуре win32, начиная от Pentium III поколения для более стабильной работы.

Жёсткий диск, на котором есть свободная память в объёме от 2 гигабайт.

Наличие не менее 800 мегабайт свободной оперативной памяти на постоянной основе.

Семейство операционных систем, построенных под архитектуру Win32, начиная от Windows XP для поддержки современных инструментариев.

Наличие приложения Microsoft Office 2010 Access или более поздних версий.

Обязательно наличие принтера.

Проектирование проводилось в СУБД Microsoft Access 2013, на ПК с характеристиками Intel Core i5 6400, 8 гигабайт оперативной памяти, SSD на 128 гигабайт, а также жёсткий диск размером 1024 гигабайта или же 1 терабайт.[11]

Анализ информационных задач показывает, что для реализации требуемых функций подходят почти все СУБД для ПЭВМ (MS Access, PostgreSQL, MySQL, SQlite, MariaDB, MS SQL Server и пр.). Все они поддерживают реляционную модель данных и предоставляют разнообразные возможности для работы с данными. Объём внешней и оперативной памяти, требующийся для функционирования СУБД, обычно указывается в сопроводительной документации.

База данных создаётся на основании схемы базы данных. Для преобразования ER–диаграммы в схему БД приведём уточнённую ER–диаграмму, содержащую атрибуты сущностей (рис. 3).

Рис. 3 – расширенная ER-диаграмма

Преобразование ER–диаграммы в схему БД выполняется путем сопоставления каждой сущности и каждой связи, имеющей атрибуты, отношения (таблицы) БД. Связь типа 1: n (один-ко-многим) между отношениями реализуется через внешний ключ. Ключ вводится для того отношения, к которому осуществляется множественная связь. Внешнему ключу должен соответствовать первичный или уникальный ключ основного (родительского) отношения [6, с. 102].

Более подробно о принципах преобразования ER-диаграммы в схему БД рассказано в [1].

Для схемы БД будем использовать обозначения, представленные на рис. 4.

<Object: word/embeddings/oleObject2.bin>

Рис. 4 – Обозначения, используемые на схеме базы данных

Полученная схема реляционной базы данных (РБД) приведена на рис. 5.

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

Каждое реляционное отношение соответствует одной сущности (объекту ПрО) и в него вносятся все атрибуты этой сущности. Для каждого отношения определяются первичный ключ и внешние ключи (в соответствии со схемой БД). В том случае, если базовое отношение не имеет потенциальных ключей, вводится суррогатный первичный ключ, который не несёт смысловой нагрузки и служит только для идентификации записей.[13]

Отношения приведены на рисунках далее. Для каждого отношения указаны атрибуты с их внутренним названием, типом и длиной. Типы данных обозначаются так: N – числовой, C – символьный тип фиксированной длины, V – символьный тип переменной длины, D – дата (этот тип имеет стандартную длину, зависящую от СУБД, поэтому она не указывается). О правилах выбора типов данных подробно рассказано в [2, с. 89].

Типы данных в таблице «Типы»:

Рис. 5 – типы данных в «Типы»

Типы данных в таблице «Недвижимость»:

Рис. 6 – типы данных в «Недвижимость»

Типы данных в таблице «Владельцы»:

Рис. 7 – типы данных в «Владельцы»

Типы данных в таблице «Клиенты»:

Рис. 8 – типы данных в «Клиенты»

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

1НФ. Для приведения таблиц к 1НФ требуется составить прямоугольные таблицы (одно значение атрибута – одна ячейка таблицы) и разбить сложные атрибуты на простые.

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

2НФ. В нашем случае все отношения находятся во второй нормальной форме. Так как ни в одном отношении нет составных ключей.

3НФ. Все отношения удовлетворяют условиям третьей нормальный формы.

4НФ. Также все отношения находятся в третьей нормальной форме.

Таблица изначально была спроектирована так, чтобы находится в правильных нормальных формах.[14]

Опишем для каждой группы пользователей права доступа к каждой таблице. Права доступа должны быть распределены так, чтобы для каждого объекта БД был хотя бы один пользователь, который имеет право добавлять и удалять данные из объекта. Права приведены в табл. 1. Используются следующие сокращения:

s – чтение данных (select);

i – добавление данных (insert);

u – модификация данных (update);

d – удаление данных(delete).

Таблица 1. Права доступа к таблицам для групп пользователей

Мной была использована СУБД MS Access 2019, поэтому описание логический схемы БД будет происходить на языке ANSI SQL с кодировкой Win-1251.

Отношение ТИПЫ (Types):

CREATE TABLE Types(

type_id integer primary key not null auto_increment,

description text not null,

plan text not null,

room_type text not null,

room_count integer not null

);

Отношение НЕДВИЖИМОСТЬ (Building):

CREATE TABLE Building(

b_id integer primary key not null auto_incerement,

address text not null,

rooms char,

kitchen Boolean,

toilet Boolean,

enterence Boolean,

other text,

price integer not null

);

Отношение ВЛАДЕЛЬЦЫ (Owners):

CREATE TABLE Owners(

o_id integer primary key not null auto_incerement,

address text not null,

photo OEL,

other_data text

);

Отношение КЛИЕНТЫ (Clients):

CREATE TABLE Clients(

c_id integer primary key not null auto_incerement,

c_data text,

c_address text not null,

c_docs text

);

Приведу примеры нескольких готовых запросов (представлений):

Месяц: Month(Сделка!Дата_сделки)

Год: Year([Дата_сделки])

СтоимостьУслуг: Sum-СтоимостьУслуги

Общая стоимость: [Стоимость проживания].Стоимость.Недвижимость+[Общая стоимость услуг по отдыхающим].[Sum-СтоимостьУслуги]

СтоимостьУслуги: Услуги.[Стоимость 1 услуги]*[Оказание услуг]

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

Таблица 2. Права доступа к представлениям

Права доступа пользователей предоставляются с помощью команды GRANT. Рассмотрим для примера права сотрудника компании ok_user, который является сотрудником отдела кадров. Права доступа к отношениям Departs и Rooms могут быть описаны следующим образом:

grant select, insert, update, delete on departs to ok_user;

grant select, insert, update, delete on rooms to ok_user;

Права доступа руководителей проектов (сотрудников, staff) к представлению my_projects могут быть описаны следующим образом:

grant select, insert, update, delete on my_projects to staff;

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

Права доступа участников проекта (сотрудников, staff) к представлению my_emps могут быть описаны следующим образом:

grant select on my_emps to staff;

Если сотрудник не является участником проекта, он не получит данных через этот запрос и не сможет воспользоваться правами доступа к нему [8, с. 163].

Для удобного пользования базой данных также были созданы формы.

Основной формой можно считать «Недвижимость» (рис. 9). Она объединяет в себе все характеристики, необходимые для подбора помещения, содержит большое количество данных.

Рис. 9 – форма «Недвижимость»

Также имеется форма «Владельцы» (рис. 10). Данные здесь созданы с помощью генератора слов на портале в сети Интернет.

Рис. 10 – форма «Владельцы»

Чтобы узнать информацию о клиентах создана форма «Клиенты» (рис. 11). Она объединяет в себе случайные данные, созданные в Интернете.

Рис. 11 – форма «Клиенты»

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ