РЕФЕРАТ

Объём данной пояснительной записки к курсовому проекту по дисциплине "Организация баз данных и знаний" составляет 50 страниц.

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

Для успешной работы с представленной программой необходим IBM совместимый компьютер с операционной системой не ниже Microsoft® Windows 98SE и пакетом офисных программ Microsoft® Office, в частности Microsoft® Access 2000 или более поздней версии.

Для реализации данного алгоритма была выбрана система управления базами данных - Microsoft® Access™.

СОДЕРЖАНИЕ

• ВВЕДЕНИЕ 4
• 1. ОПИСАНИЕ ПРИМЕНЕНИЯ 6
• 2. ПОСТАНОВКА ЗАДАЧИ 7
• 3. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ 8
• 3.1 Задачи проектирования баз данных 8
• 3.2 Формирование концептуальной модели 9
• 4. ВЫБОР И ПОСТРОЕНИЕ МОДЕЛИ 19
• 4.1 Выбор модели 19
• 4.2 Нормализация с помощью метода ER-диаграмм 23
• 5. ОПИСАНИЕ ПРОГРАММЫ 30
• 5.1Описание логической структуры 30
• 5.2 Входные и выходные данные 31
• 5.3 Инструкция пользователю 34
• СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 37
• ПРИЛОЖЕНИЕ А Текст программы 38
• ПРИЛОЖЕНИЕ Б Результаты работы программы 43
• ВВЕДЕНИЕ

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

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

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

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

Хорошо спроектированная база данных:

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

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

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

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

Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.

СУБД Access корпорации Microsoft® обладает исключительно высокими скоростными характеристиками и в этом отношении заметно выделяется среди других интерпретирующих систем. Набор команд и функций, предлагаемых разработчикам программных продуктов в среде Microsoft® Access 2000, по мощи и гибкости отвечает любым современным требованиям к представлению и обработке данных. Здесь может быть реализован максимально удобный, гибкий и эффективный пользовательский интерфейс. Система также обладает средствами быстрой генерации форм, отчетов и меню, поддерживает язык SQL.

1. ОПИСАНИЕ ПРИМЕНЕНИЯ

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

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

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

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

· сокращение времени обработки информации;

· простоте реализации различных запросов и скорости обработки данных;

· автоматизации труда.

Благодаря тому, что программа реализована при помощи Microsoft® Access 2000, она имеет внешний вид (интерфейс) характерный для всех приложений разработанных под операционную систему Microsoft® Windows, который очень прост и дружелюбен по отношению к пользователю.

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

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

2. ПОСТАНОВКА ЗАДАЧИ

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

Реализовать расчёт прибыли фирмы от отдельно взятой проведённой операции и суммарной прибыли за указанный временной промежуток.

3. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

3.1 Задачи проектирования базы данных

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

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

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

При проектировании структуры новой БД определяют сущности предметной области, которые должны найти свое отражение в базе данных. Анализ предметной области обычно осуществляется:

· на основании существующих сведений о предметной области в широком или узком смысле, то есть в масштабах, в которых она должна быть представлена в создаваемой БД и работающих с ней приложениях;

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

· на основании представления о том, какое место БД и работающие с ней приложения займут в структуре эксплуатирующей ее организации;

· на основании представлений о том, какие изменения потоков организации последуют после внедрения программной системы в эксплуатацию.

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

3.2. Формирование концептуальной модели

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

Анализ предметной области обычно осуществляется:

· на основании существующих сведений о предметной области, в масштабах в которых она должна быть представлена в создаваемой базе данных и работающих с ней приложениях;

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

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

В конечном итоге анализ предметной области должен привести к созданию проекта базы данных.

Вначале необходимо изобразить сущности и связи между ними. Как правило, каждой сущности (объекту) в базе данных соответствует таблица. Затем для каждой таблицы базы данных приводится список полей записи.

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

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

· идентификацию функциональной деятельности предметной области;

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

· идентификацию характеристик этих сущностей;

· идентификацию взаимосвязей между сущностями;

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

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

Исходя из того, что агентство по покупки - продаже недвижимости является фирмой посредником, т. е. в проводимых операциях с недвижимостью она не выступает ни в роли покупателя, ни в роле продавца. Следовательно, можно сделать вывод, что основным видом деятельности фирмы является работа с клиентами, которые хотят продать либо купить недвижимость. Иными словами, основной задачей фирмы является поиск оптимальных вариантов покупки либо продажи собственности отдельно взятого клиента, на основании имеющихся данных о заказах (заявках) других клиентов. Таким образом, агентство помогает продавцу найти своего покупателя и наоборот. За услуги подобного рода, фирма получает 5 % от суммы продаваемого объекта.

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

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

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

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

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

Второй составной частью заявки является учётная карточка объекта недвижимости.

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

После того как оператор зарегистрировал клиента в базе данных агентства, он (оператор) производит поиск наиболее подходящего варианта для этого клиента.

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

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

В созданной базе данных существуют 5 объектов:

1. Клиент физическое лицо

2. Клиент юридическое лицо

3. Недвижимость (объект продажи-покупки)

4. Проданные объекты

5. Сотрудники

Анализ запросов на данные отдельных клиентов показывает, что для поиска подходящих объектов (например, по фамилии, типу клиента) и отбора необходимого (например, по номеру паспорта или свидетельства о регистрации), следует выделить следующие атрибуты для объектов:

Клиент (Физическое Лицо)

Тип клиента - Покупатель или продавец;

Код клиента - Учётный номер клиента;

ФИО - Фамилия и инициалы;

Адрес - Адрес клиента;

Телефон - Телефон клиента;

№ паспорта, серия - Личные данные клиента;

№ идентиф. кода - Идентификационный код физического лица.

Клиент (Юридическое Лицо)

Тип клиента - Покупатель или продавец;

Код клиента - Учётный номер клиента;

Наименование организации - Название фирмы, предприятия и др.;

Адрес - Адрес клиента;

Телефон - Телефон клиента;

№ регистр. свидетельства - Номер свидетельства о регистрации;

№ банковского счёта - Номер банковского счёта организации.

Недвижимость (Объект Продажи-Покупки)

Код заявки - Номер заказа определённого клиента;

Дата - Дата составления заказа;

Наименование объекта - Дом, дача, гараж, квартира, и т. д.;

Площадь - Общая площадь объекта;

Этаж - Этаж, на котором находится объект;

Кол-во комнат - Количество жилых комнат в объекте;

Страна - Страна, в которой находится объект;

Область - Область, в которой находится объект;

Населенный пункт - Название города, села, ПГТ, и т. д. в котором находится объект;

Район - Район, в котором находится объект;

Улица - Улица, по которой находится объект;

Цена - Цена объекта.

Проданные Объекты

Код заявки - Номер заказа определённого клиента;

Дата - Дата составления заказа;

Наименование объекта - Дом, дача, гараж, квартира, и т. д.;

Площадь - Общая площадь объекта;

Этаж - Этаж, на котором находится объект;

Кол-во комнат - Количество жилых комнат в объекте;

Страна - Страна, в которой находится объект;

Область - Область, в которой находится объект;

Населенный пункт - Название города, села, ПГТ, и т. д. в котором находится объект;

Район - Район, в котором находится объект;

Улица - Улица, по которой находится объект;

Цена - Цена объекта.

Дата операции - Дата продажи объекта;

Прибыль - Доход фирмы от проведения операции.

Сотрудники

Код Сотрудника - Код, который присваивается новому сотруднику;

Фамилия - Фамилия сотрудника;

Имя - Имя сотрудника;

Должность - Занимаемая должность;

Дата Рождения - День рождения сотрудника;

Дата Найма - Дата приёма на работу;

Адрес - Место жительства сотрудника;

Город - Место жительства сотрудника;

Область - Место жительства сотрудника;

Индекс - Почтовый индекс;

Страна - Место жительства сотрудника;

Домашний Телефон - Телефон сотрудника.

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

Клиент (Физическое Лицо)

Клиент (Юридическое Лицо)

Недвижимость (Объект продажи-покупки)

Проданные Объекты

Сотрудники

Между атрибутами вышеперечисленных объектов существуют 2 типа отношений:

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

К данному типу относятся отношения между атрибутами:

1. Код клиента и ФИО;

2. № паспорта и ФИО;

3. № идентификационного кода и ФИО;

4. № банковского счёта и Наименование организации;

5. № регистрационного свидетельства и Наименование организации;

6. Код заявки и Наименование объекта;

7. Код сотрудника и ФИО.

Связи между остальными атрибутами объектов определены как "многие-ко-многим".

"Многие-ко-многим" - отношение имеет место, когда:

а) записи в родительской таблице может соответствовать больше одной записи в дочерней таблице;

б) записи в дочерней таблице может соответствовать больше одной записи в родительской таблице.

Многие СУБД не поддерживают связи "многие-ко-многим" на уровне индексов и ссылочной целостности, хотя и позволяют реализовывать ее в таблицах неявным образом. Аналогично, многие CASE - средства (программы для разработки структуры базы данных в виде диаграмм и генерации на их основе физической базы данных) также не позволяют определять эту связь между таблицами проектируемой базы данных. Считается, что всякая связь "многие-ко-многим" может быть заменена на одну или более связь "один-ко-многим".

4. ВЫБОР И ПОСТРОЕНИЕ МОДЕЛИ

4.1. Выбор модели

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

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

- Найти указанное дерево БД;

- Перейти от одного дерева к другому;

- Перейти от одной записи к другой внутри;

- Перейти от одной записи к другой в порядке обхода иерархии;

- Вставить новую запись в указанную позицию;

- Удалить текущую запись.

Одним из основных преимуществ иерархической модели данных является скорость поиска по базе.

Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г. До сих пор поддерживается много баз данных, что создает существенные проблемы с переходом, как на новую технологию БД, так и на новую технику.

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

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

Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться два условия:

- Каждое экземпляр типа P является предком только в одном экземпляре L;

- Каждый экземпляр C является потомком не более чем в одном экземпляре L.

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

а) Тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 (как в иерархии).

б) Данный тип записи P может быть типом записи предка в любом числе типов связи.

в) Данный тип записи P может быть типом записи потомка в любом числе типов связи.

г) Может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 - два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться.

д) Типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком - в другой.

е) Предок и потомок могут быть одного типа записи.

Примерный набор операций может быть таковым:

Найти конкретную запись в наборе однотипных записей (инженера Сидорова);

Перейти от предка к первому потомку по некоторой связи (к первому сотруднику отдела 310);

Перейти к следующему потомку в некоторой связи (от Сидорова к Иванову);

Перейти от потомка к предку по некоторой связи (найти отдел Сидорова);

Создать новую запись;

Уничтожить запись;

Модифицировать запись;

Включить в связь;

Исключить из связи;

Переставить в другую связь и т.д.

К достоинствам сетевой СУБД можно отнести возможность экономии памяти за счет разделения подобъектов.

Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL), организации, ответственной за определение языка программирования Кобол.

Описанные выше модели данных относятся к так называемым "ранним" СУБД. У этих моделей есть существенные недостатки так то:

Слишком сложно пользоваться;

Фактически необходимы знания о физической организации;

Прикладные системы зависят от этой организации;

Их логика перегружена деталями организации доступа к БД.

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

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

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

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

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

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

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

В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение.

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

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

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

4.2. Нормализация с помощью метода ER-диаграмм

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

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

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных. Среди множества разновидностей ER-моделей, одна из наиболее развитых применяется в системе CASE фирмы ORACLE.

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

Ключевыми для данного метода являются понятия сущность и связь.

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

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

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

Используя вышеописанные правила, применим метод ER-диаграмм для нормализации исходного универсального отношения.

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

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

Для объекта Клиент (физическое лицо):

Код клиента -> ФИО, Адрес, Телефон, № паспорта, № идентиф. кода, Тип клиента.

№ паспорта -> ФИО, Адрес, Телефон, Код клиента, № идентиф. кода, Тип клиента.

№ идентиф. кода -> ФИО, Адрес, Телефон, Код клиента, № паспорта, Тип клиента.

Для объекта Клиент (юридическое лицо):

Код клиента -> Наименование организации, Адрес, Телефон, № регистр. свидетельства, № банковского счёта, Тип клиента.

№ регистр. свидетельства -> ФИО, Адрес, Телефон, Код клиента, № банковского счёта, Тип клиента.

№ банковского счёта -> ФИО, Адрес, Телефон, Код клиента, № регистр. свидетельства, Тип клиента.

Для объекта Недвижимость (Объект продажи-покупки):

Код заявки -> Дата, Наименование объекта, Площадь, Этаж, Кол-во комнат, Страна, Область, Населенный пункт, Район, Улица, Цена.

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

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

Для объекта Клиент (физическое лицо) ключевым является поле Код клиента.

Для объекта Клиент (юридическое лицо) ключевым является поле Код клиента.

Для объекта Недвижимость (Объект продажи-покупки) ключевым является поле Код заявки.

Так как, объекты Клиент (физическое лицо) и Клиент (юридическое лицо) однотипны, следовательно, проведя нормализацию только для объектов Клиент (физическое лицо) и Недвижимость (Объект продажи-покупки) мы нормализируем и объект Клиент (юридическое лицо).

Построим схему сущностей объекта Клиент (физическое лицо) и Недвижимость (Объект продажи-покупки).

Клиент1 Недвижимость1

Клиент2 Недвижимость2

Клиент3 Недвижимость3

Клиент4 Недвижимость4

Клиент5 Недвижимость5

Клиент6 Недвижимость6

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

Строим ER-диаграмму:

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

Если степень бинарной связи 1 : n, и класс принадлежности является обязательным, то необходимо построить 2 отношения. В отношении n-связной сущности добавить ключ односвязной сущности как атрибут.

Ключевым атрибутом для объекта Клиент (физическое лицо) как и для объекта, Клиент (юридическое лицо) является Код клиента. Этот ключ добавляем, в качестве атрибута, в объект Недвижимость (Объект продажи-покупки).

В результате нормализации получили отношения, приведённые в таблицах 4.1 - 4.3.

Таблица 4.1 - Отношение "Клиент (Физическое лицо)"

Таблица 4.2 - Отношение "Клиент (Юридическое лицо)"

Таблица 4.3 - Отношение "Недвижимость (Объект покупки-продажи)"

Продолжение Таблицы 4.3 - Отношение "Недвижимость (Объект покупки-продажи)"

Эти отношения будут использованы при создании базы данных.

Проверим полученные отношения на соответствие нормальной форме Бойса-Кодда.

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

Все полученные отношения находятся в нормальной форме Бойса-Кодда, так как, все первичные ключи совпадают с детерминантами.

5. ОПИСАНИЕ ПРОГРАММЫ

5.1. Описание логической структуры

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

При написании командного файла использовался метод структурного программирования. Вся программа разделена на несколько подпрограмм.

Алгоритм программы достаточно прост. Ниже представлен концептуальный алгоритм данной программы.

Шаг 0: Инициализация программы.

Шаг 1: Ждать выбора пользователя. При выборе перейти к шагу 2.

Шаг 2: Если пользователь выбрал пункт меню ВЫХОД, то перейти к шагу 10, в противном случае к шагу 3.

Шаг 3: Инициализация вспомогательного меню в соответствии с выбором пользователя.

Шаг 4: Ждать выбора пользователя. При выборе перейти к шагу 5.

Шаг 5: Если пользователь отказался от выбора, то перейти к шагу 1, в противном случае к шагу 6.

Шаг 6: Инициализация меню выбора в соответствии с выбором пользователя.

Шаг 7: Ждать выбора пользователя. При выборе перейти к шагу 8.

Шаг 8: Если пользователь отказался от выбора, то перейти к шагу 4, в противном случае к шагу 9.

Шаг 9: Исполнение подпрограммы в соответствии с выбором пользователя. Переход к шагу 7.

Шаг 10: Завершение работы программы.

5.2. Входные и выходные данные

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

Таблицы имеют следующие типы полей:

Таблица 5.1 - типы полей таблицы "Клиенты(Физические лица)"

Таблица 5.2 - типы полей таблицы "Клиенты(Юридические лица)"