Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Курсовая работа РГГУ

Дисциплина: Математические основы баз данных

Исполнитель: Нестеров В.П.



Содержание

Введение

1.Общая часть

1.1 Функциональные зависимости атрибутов и ключи отношений

2.Практическая часть

2.1 Разработка информационной модели базы данных

2.1.1 Описание предметной области

2.1.2 Описание входных документов

2.1.3 Описание содержания отчетных документов

2.1.4 Описание функциональной схемы программного приложения

2.2.Разработка инфологической модели базы данных

2.2.1 Описание информационных объектов

2.2.2 Нормализация информационных объектов

2.2.3 Построение инфологической модели в виде диаграммы “Таблица -Связь”

2.3.Разработка даталогической модели

2.3.1 Описание выбранной СУБД

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

2.3.3 Описание запросов к базе данных

2.3.4 Описание содержания и вида выходных документов

2.4.Создание физической модели данных

2.4.1 Описание технологии ведения базы данных

2.4.2 Создание структуры БД

2.4.2.1 Создание таблиц проектируемой БД

2.4.2.2 Формирование схемы данных

4.2.3 Создание форм для ведения проектируемой БД

2.4.2.4 Создание запросов проектируемой БД

2.5. Разработка информационной системы на основе созданной БД

2.5.1 Схема функциональной структуры приложения

2.5.2 Разработка формы заставки, главной и вторичных кнопочных форм

2.5.3 Инструкция для пользователя для работы с ИС

Заключение

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



Введение

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

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

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

В таблице «Анкета» необходимо предусмотреть Фамилия Имя Отчество сотрудника, Дату рождения, Место рождения, Национальность, Адрес и т.д. База данных должна, учитывать Пол, семейное положение сотрудника, состав семьи, отдел, оклад. Также должно учитываться номер удостоверение личности.

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



1.Общая часть

1.1 Функциональные зависимости атрибутов и ключи отношений

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

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

Функциональная зависимость обозначается X -> Y. Отметим, что X и Y могут представлять собой не только единичные атрибуты, но и группы, составленные из нескольких атрибутов одного отношения.

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

Некоторые функциональные зависимости могут быть нежелательны.

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

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

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

v не должны появляться ранее отсутствовавшие кортежи;

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

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

Простой атрибут - атрибут, значения которого атомарны (неделимы).

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

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

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

СЛУЖАЩИЙ(НОМЕР_СЛУЖАЩЕГО, ИМЯ, ДАТА_РОЖДЕНИЯ, ИСТОРИЯ_РАБОТЫ, ДЕТИ).

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

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

ИСТОРИЯ_РАБОТЫ (ДАТА_ПРИЕМА, НАЗВАНИЕ, ИСТОРИЯ_ЗАРПЛАТЫ),

ИСТОРИЯ_ЗАРПЛАТЫ (ДАТА_НАЗНАЧЕНИЯ, ЗАРПЛАТА),

ДЕТИ (ИМЯ_РЕБЕНКА, ГОД_РОЖДЕНИЯ).

Их связь представлена на рис. 1.1.

Рис. 1.1. Исходное отношение

Для приведения исходного отношения СЛУЖАЩИЙ к первой нормальной форме необходимо декомпозировать его на четыре отношения, так как это показано на следующем рисунке:

Рис.1.2. Нормализованное множество отношений.

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

Алгоритм нормализации описан Е.Ф.Коддом следующим образом:

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

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

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

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

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

Пусть имеется отношение ПОСТАВКИ (N_ПОСТАВЩИКА, ТОВАР, ЦЕНА).

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

· N_поставщика, товар -> цена

· товар -> цена

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

· ПОСТАВКИ (N_ПОСТАВЩИКА, ТОВАР)

· ЦЕНА_ТОВАРА (ТОВАР, ЦЕНА)

Таким образом, можно дать определение второй нормальной формы:

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

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

Пусть X, Y, Z - три атрибута некоторого отношения. При этом X --> Y и Y --> Z, но обратное соответствие отсутствует, т.е. Z -/-> Y и Y -/-> X. Тогда Z транзитивно зависит от X.

Пусть имеется отношение ХРАНЕНИЕ (ФИРМА, СКЛАД, ОБЪЕМ), которое содержит информацию о фирмах, получающих товары со складов, и объемах этих складов. Ключевой атрибут - "фирма". Если каждая фирма может получать товар только с одного склада, то в данном отношении имеются следующие функциональные зависимости:

· фирма -> склад

· склад -> объем

При этом возникают аномалии:

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

· если объем склада изменяется, необходим просмотр всего отношения и изменение кортежей для всех фирм, связанных с данным складом.

Для устранения этих аномалий необходимо декомпозировать исходное отношение на два:

· ХРАНЕНИЕ (ФИРМА, СКЛАД)

· ОБЪЕМ_СКЛАДА (СКЛАД, ОБЪЕМ)

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

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

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

В качестве примера рассмотрим отношение ПРЕПОДАВАТЕЛЬ (ИМЯ, КУРС, УЧЕБНОЕ_ПОСОБИЕ), хранящее сведения о курсах, читаемых преодавателем, и написанных им учебниках. Пусть профессор N читает курсы "Теория упругости" и "Теория колебаний" и имеет соответствующие учебные пособия, а профессор K читает курс "Теория удара" и является автором учебников "Теория удара" и "Теоретическая механика". Тогда наше отношение будет иметь вид:

----------------------------------------------------

| ИМЯ | КУРС | УЧЕБНОЕ_ПОСОБИЕ |

----------------------------------------------------

| N | Теория упругости | Теория упругости |

| N | Теория колебаний | Теория упругости |

| N | Теория упругости | Теория колебаний |

| N | Теория колебаний | Теория колебаний |

| K | Теория удара | Теория удара |

| K | Теория удара | Теоретическая механика |

----------------------------------------------------

добавляем:

----------------------------------------------------

| K | Теория упругости | Теория удара |

| K | Теория упругости | Теоретическая механика |

----------------------------------------------------

Это отношение имеет значительную избыточность и его использование приводит к возникновению аномалии обновления. Например, добавление информации о том, что профессор K будет также читать лекции по курсу "Теория упругости" приводит к необходимости добавить два кортежа (по одному для каждого написанного им учебника) вместо одного. Тем не менее, отношение ПРЕПОДАВАТЕЛЬ находится в NFBC (ключевой атрибут - ИМЯ).

Заметим, что указанные аномалии исчезают при замене отношения ПРЕПОДАВАТЕЛЬ его проекциями:

--------------------------- -------------------------------

| ИМЯ | КУРС | | ИМЯ | УЧЕБНОЕ_ПОСОБИЕ |

--------------------------- -------------------------------

| N | Теория упругости | | N |Теория упругости |

| N | Теория колебаний | | N |Теория колебаний |

| K | Теория удара | | K |Теоретическая механика |

| K | Теория упругости | | K |Теория удара |

--------------------------- -------------------------------

Аномалия обновления возникает в данном случае потому, что в отношении ПРЕПОДАВАТЕЛЬ имеются:

1. зависимость множества значений атрибута КУРС от множества значений атрибута ИМЯ

2. зависимость множества значений атрибута УЧЕБНОЕ_ПОСОБИЕ от множества значений атрибута ИМЯ.

Такие зависимости и называются многозначными и обозначаются как

ИМЯ ->> КУРС ИМЯ ->> УЧЕБНОЕ_ПОСОБИЕ

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

ИМЯ ->> КУРС | УЧЕБНОЕ_ПОСОБИЕ

Очевидно, что каждая функциональная зависимость является многозначной, но не каждая многозначная зависимость является функциональной.

Отношение находится в 4NF если оно находится в BCNF и в нем отстутсвуют многозначные зависимости, не являющиеся функциональными зависимостями.

До сих пор мы предполагали, что единственной операцией, необходимой для устранения избыточности в отношении, была декомпозиция его на две проекции. Однако, существуют отношения, для которых нельзя выполнить декомпозицию без потерь на две проекции, но которые можно подвергнуть декомпозиции без потерь на три (или более) проекций. Этот факт получил название зависимости по соединению, а такие отношения называют 3-декомпозируемые отношения (ясно, что любое отношение можно назвать "n-декомпозируемым", где n >= 2).

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

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

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

информационный модель база данные



2.Практическая часть

2.1 Разработка информационной модели базы данных

2.1.1 Описание предметной области

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

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

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

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

Таким образом, входящими документами для учета объектов недвижимости и сделок по ним являются:

- договор купли-продажи;

- договор аренды.

Исходящими документами являют следующие отчеты:

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

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

- Отчет по прибыли от сделок;

- Отчет по прибыли от сделок за период;

- Отчет о проданных объектах;

- Отчет об объектах, сданных в аренду.

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

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

- Наименование организации: РА «Твой Дом»;

- Адрес организации: 400006, г. Волгоград, пр. им. Ленина, дом 206;

- Телефон организации: (88442) 798-97-55;

- Руководитель организации (ФИО): Алтухов Илья Георгиевич;

- Главный бухгалтер (ФИО): Кранникова Маргарита Юрьевна;

- Идентификационный номер налогоплательщика (ИНН): 3444234652;

- Код причины постановки на учёт (КПП): 545423468;

- Расчетный счет: 54354621324894231357;

- Наименование Банка: Волгоградское ОСБ №8621;

- Банковский Идентификационный Код (БИК): 545613245;

- Корреспондентский счет: 54138534544545787545;

2.1.2 Описание входных документов

Входными документами являются:

1. Договор купли-продажи объекта недвижимости или договор аренды. Один договор может содержать в себе несколько операций. Договор содержит следующие данные:

- Номер документа;

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

- Наименование и реквизиты организации-исполнителя;

- ФИО продавца/арендодателя, адрес проживания;

- ФИО покупателя/арендатора, адрес проживания;

- Характеристика объекта продажи/аренды;

- Стоимость объекта купли-продажи/сдачи в аренду.

2.1.3 Описание содержания отчетных документов

Отчеты, которые будут реализованы в базе данных:

1. Отчет «Отчет по заработной плате сотрудникам», содержит следующие атрибуты:

- ФИО сотрудника;

- Заработная плата за операцию;

- Дата операции;

- Тип операции;

- Стоимость сделки;

- Итог по заработной плате за все проведенные операции;

- Реквизиты организации.

2. Отчет «Отчет по заработной плате сотруднику» (содержит сведения о заработной плате конкретному сотруднику, ФИО которого вводится пользователем при формировании отчета):

- ФИО сотрудника;

- Заработная плата за операцию;

- Дата операции;

- Тип операции;

- Стоимость сделки;

- Итог по заработной плате за все проведенные операции;

- Реквизиты организации.

3. Отчет «Прибыль от сделок», данные которого сгруппированы по месяцам:

- Дата операции;

- Тип операции;

- Объект;

- Адрес объекта;

- Сотрудник;

- Стоимость объекта;

- Прибыль от сделки;

- Итоговая прибыль по всем сделкам;

- Реквизиты организации.

4. Отчет «Прибыль от сделок за период» (содержит сведения о прибыли организации за конкретный период времени, вводимый пользователем при формировании отчета):

- Дата операции;

- Тип операции;

- Объект;

- Адрес объекта;

- Сотрудник;

- Стоимость объекта;

- Прибыль от сделки;

- Итоговая прибыль по сделкам за период;

- Реквизиты организации.

5. Отчет «Объекты продажи»:

- Наименование объекта;

- Адрес объекта;

- Количество комнат;

- Общая площадь;

- Жилая площадь;

- Этаж;

- Этажность;

- Стоимость объекта;

- Реквизиты организации.

6. Отчет «Объекты аренды»:

- Наименование объекта;

- Адрес объекта;

- Количество комнат;

- Общая площадь;

- Жилая площадь;

- Этаж;

- Этажность;

- Стоимость объекта;

Реквизиты организации.

2.1.4 Описание функциональной схемы программного приложения

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

- добавление новых данных в каждую таблицу;

- редактирование уже введенных данных;

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



Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 2.1. Функциональная схема разрабатываемого программного приложения

Список ограничений.

1. Номера документов уникальны;

2. Для одного объекта продажи/аренды имеется только один клиент-собственник;

3. Типы операций и типы объектов заранее определены;

4. Используемая валюта: рубль;

5. Стоимость сделки является конечной и не изменяемой.

2.2.Разработка инфологической модели базы данных

2.2.1 Описание информационных объектов

Все информационные объекты рассматриваемой предметной области поделены на следующие структурные элементы:

1. Информационные объекты, относящиеся к организации: Реквизиты организации, Сотрудники организации;

2. Информационные объекты, относящиеся к клиентам: Сведения о клиентах.

3. Информационные объекты, относящиеся к объектам недвижимости: Сведения об объектах; Типы объектов;

4. Информационные объекты, относящиеся к договорам: Сведения об операциях; Типы операций.

Рассмотрим каждый из этих структурных элементов и выделим сущности.

1) Сущность ОРГАНИЗАЦИЯ.

- Код организации (КодОрганизации);

- Наименование организации (НаименованиеОрганизации);

- Адрес организации (Адрес);

- Телефон (Телефон);

- ФИО руководителя (Руководитель);

- Главный бухгалтер (Главный бухгалтер);

- Идентификационный номер налогоплательщика (ИНН);

- Код причины постановки на учёт (КПП);

- Расчетный счет (Р/С);

- Банковский Идентификационный Код (БИК);

- Наименование Банка (Наименование банка);

- Корреспондентский счет (К/С).

2) Сущность СОТРУДНИКИ.

- Код Сотрудника (КодСотрудника);

- ФИО сотрудника (ФИО сотрудника);

- Дата рождения (Дата рождения);

- Адрес проживания сотрудника (Адрес проживания);

- Контактный телефон (Контактный телефон).

3) Сущность КЛИЕНТЫ.

- Код клиента (Код Клиента);

- ФИО клиента (ФИО Клиента);

- Адрес (Адрес);

- Контактный теелфон (Телефон);

- Код объекта (КодОбъекта).

4) Сущность ОБЪЕКТЫ.

- Код объекта (КодОбъекта);

- Тип объекта (ТипОбъекта);

- Тип операции (ТипОперации);

- Адрес объекта (АдресОбъекта);

- Количество комнат (КоличествоКомнат);

- Общая площадь (ОбщаяПлощадь);

- Жилая площадь (ЖилаяПлощадь);

- Этаж (Этаж);

- Этажность (Этажность);

- Стоимость (Стоимость).

5) Сущность ТИПЫ ОБЪЕКТОВ.

- Код типа объекта (КодТипаОбъекта);

- Наименование типа объекта (НаименованиеТипаОбъекта).

6) Сущность ОПЕРАЦИИ.

- Код операции (КодОперации);

- Код типа операции (КодТипаОперации);

- Дата операции (ДатаОперации);

- Код организации (КодОрганизации);

- Код клиента (КодКлиента);

- Код объекта (КодОбъекта);

- Код сотрудника (КодСотрудника);

- Стоимость (Стоимость).

7) Сущность ТИПЫ ОПЕРАЦИЙ:

- Код типа операции (КодТипаОперации);

- Наименование типа операции (НаименованиеТипаОперации).

2.2.2 Нормализация информационных объектов

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

Результатами анализа проведенного в предыдущем разделе стали 7 сущностей: ОРГАНИЗАЦИЯ, СОТРУДНИКИ, КЛИЕНТЫ, ОБЪЕКТЫ, ТИПЫ ОБЪЕКТОВ, ОПЕРАЦИИ, ТИПЫ ОПЕРАЦИЙ . Каждая сущность характеризуется группой атрибутов, часть из которых может дублироваться в других сущностях. Для оптимизации данных необходимо провести процедуру нормализации, которая выполняется поэтапно.

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

Для приведения сущностей к таблицам первой нормальной форме, необходимо исключить дублирование множества характеристик между двумя сущностями, путем присвоения ключевых атрибутов тем сущностям, которые их не имеют. Так, например, для определения объекта недвижимости, принадлежащего клиенту в сущности КЛИЕНТЫ нет необходимости дублировать характеристики сущности ОБЪЕКТЫ, достаточно внести в атрибуты сущности КЛИЕНТЫ ключевое поле: Код Объекта (КодОбъекта). А в сущности ОБЪЕКТЫ заменить атрибут «Номер объекта» на «Код Объекта», и в дальнейшем связать две этих сущности через созданное поле. Аналогичным образом по необходимости добавляются ключевые атрибуты к другим сущностям.

Для второй нормальной формы (2НФ) требуется, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен. Значение первичного ключа в таблице БД должно быть уникальным, т.е. в таблице не должно существовать двух и более записей с одинаковым значением первичного ключа. Те поля, которые зависят только от части первичного ключа, должны быть выделены в составе отдельных таблиц. Примером приведение таблиц ко второй нормальной форме, является разделение сведений о счетах на две сущности ТИПЫ ОПЕРАЦИЙ и ТИПЫ ОБЪЕКТОВ.

Для третьей нормальной формы (ЗНФ) требуется, чтобы все не ключевые столбцы таблицы зависели от первичного ключа таблицы, но были независимы друг от друга. Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ.

В результате проведения нормализации были выявлены сущности ТИПЫ ОПЕРАЦИЙ и ТИПЫ ОБЪЕКТОВ.



2.2.3 Построение инфологической модели в виде диаграммы “Таблица -Связь”

Рисунок 2.2. Инфологическая модель в виде диаграммы «Таблица-связь»

2.3 Разработка даталогической модели

2.3.1 Описание выбранной СУБД

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

Наиболее удобной и популярной системой управления базой данных (СУБД), которая позволит реализовать все необходимые задачи по разработке базы данных и программного приложения является продукт компании Microsoft - Access.

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

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

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

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

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

Access может поддерживать одновременную работу с базой данных 50 пользователей, при этом все пользователи гарантировано будут работать с актуальными данными.



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

Ниже представлены сущности и их атрибуты виде таблиц реляционной базы данных (РБД) с описанием ограничений и примером заполнения.

Таблица 2.1. Таблица «Организация»

Поле	Данные контрольного примера
(*)КодОрганизации
Наименование	Риэлтерское агентство «Твой Дом»
ИНН	3444234652
КПП	545423468
Адрес	400006, г. Волгоград, пр. им. Ленина, дом 206
Телефон	(88442) 798-97-55
Руководитель	Алтухов Илья Георгиевич
Главный бухгалтер	Кранникова Маргарита Юрьевна
Расчетный счет	54354621324894231357
БИК	545613245
Банк	Волгоградское ОСБ №8621
К/С	54138534544545787545

Таблица 2.2. Описание логической структуры таблицы «Организация»

Поле	Тип данных	Ограничения
(*)КодОрганизации	Счетчик	Последовательное Уникальное
Наименование	Текстовый (255)	Не более 255 символов
ИНН	Текстовый (10)	10 цифр
КПП	Текстовый (9)	9 цифр
Адрес	Текстовый (255)	Не более 255 символов
Телефон	Текстовый (20)	Не более 20 символов
Руководитель	Текстовый (50)	Не более 50 символов
Главный бухгалтер	Текстовый (50)	Не более 50 символов
ОКПО	Текстовый (8)	8 цифр
Расчетный счет	Текстовый (20)	20 цифр
БИК	Текстовый (9)	9 цифр
Банк	Текстовый (50)	Не более 100 символов
К/С	Текстовый (20)	20 цифр

Таблица 2.3. Таблица «Клиенты»

Поле	Контрольный пример 1	Контрольный пример 2
(*)КодКлиента	1	2
ФИОКлиента	Иванов Петр Михайлович	Федоров Иван Михайлович
Адрес Проживания	ул. Борьбы, дом 2, кв. 11	ул. Козловская, дом 55
Контактный телефон	(76423) 167-56-43	(86725) 453-73-45

Таблица 2.4. Описание логической структуры таблицы «Клиенты»

Поле	Тип данных	Ограничения
(*)КодКлиента	Счетчик	Последовательное, Уникальное
ФИОКлиента	Текстовый (50)	Не более 50 символов
Адрес Проживания	Текстовый (50)	Не более 50 символов
Контактный телефон	Текстовый (20)	Не более 20 символов

Таблица 2.5. Таблица «Сотрудники»

Поле	Контрольный пример 1	Контрольный пример 2
(*)КодСотрудника	1	2
ФИО Сотрудника	Петелина Виктория Александровна	Романенко Марина Александровна
Дата рождения	07.09.1986	10.04.1981
Паспортные данные	18 05 802978	18 05 809858
Адрес проживания	ул. Борьбы, дом 2, кв. 11	ул .Кропоткина, дом 11, кв. 34
Контактный телефон	(75435) 753-45-34	(45757) 742-58-54

Таблица 2.6. Описание логической структуры таблицы «Сотрудники»

Поле	Тип данных	Ограничения
(*)КодСотрудника	Счетчик	Последовательное, Уникальное
ФИО Сотрудника	Текстовый (50)	Не более 50 символов
Дата рождения	Дата/время	Краткий формат
Паспортные данные	Текстовый (20)	Не более 20 символов
Адрес проживания	Текстовый (50)	Не более 50 символов
Контактный телефон	Текстовый (20)	Не более 20 символов



Таблица 2.7. Таблица «Объекты»

Поле	Контрольный пример 1	Контрольный пример 2
(*)КодОбъекта	1	2
(*)КодТипаОперации	1	1
(*)КодТипаОбъекта	1	2
АдресОбъекта	ул. КИМ, дом 5	ул. Рабоче-Крестьянская, дом 2, кв. 4
КоличествоКомнат	4	3
ОбщаяПлощадь	59,5	79,5
ЖилаяПлощадь	33,4	53,5
Этаж		3
Этажность	2	5
Стоимость	2500000руб.	3200000руб.

Таблица 2.8. Описание логической структуры таблицы «Клиенты»

Поле	Тип данных	Ограничения
(*)КодОбъекта	Счетчик	Последовательное, Уникальное
(*)КодТипаОперации	Числовой	Длинное целое
(*)КодТипаОбъекта	Числовой	Длинное целое
АдресОбъекта	Текстовый (50)	Не более 50 символов
КоличествоКомнат	Числовой	Длинное целое
ОбщаяПлощадь	Числовой	Длинное целое, 1 знак после запятой
ЖилаяПлощадь	Числовой	Длинное целое, 1 знак после запятой
Этаж	Числовой	Длинное целое
Этажность	Числовой	Длинное целое
Стоимость	Денежный	2 знака после запятой

Таблица 2.9. Таблица «Операции»

Поле	Контрольный пример 1	Контрольный пример 2
(*) КодОперации	1	2
ДатаОперации	19.06.2009	22.06.2009
(*) КодТипаОперации	1	2
(*) КодОрганизации	1	1
(*) КодКлиента	3	4
(*) КодОбъекта	2	5
(*) КодСотрудника	3	3
Стоимость	2400000руб.	7000руб.

Таблица 2.10. Описание логической структуры таблицы «Операции»

Поле	Тип данных	Ограничения
(*) КодОперации	Счетчик	Последовательное, уникальное
ДатаОперации	Дата/время	Краткий формат
(*) КодТипаОперации	Числовой	Длинное целое
(*) КодОрганизации	Числовой	Длинное целое
(*) КодКлиента	Числовой	Длинное целое
(*) КодОбъекта	Числовой	Длинное целое
(*) КодСотрудника	Числовой	Длинное целое
Стоимость	Денежный	2 знака после запятой

Таблица 2.11. Таблица «Типы объектов»

Поле	Контрольный пример 1	Контрольный пример 2
(*) КодТипаОбъекта	1	2
НаименованиеТипаОбъекта	Дом	Квартира

Таблица 2.12. Описание логической структуры таблицы «Валютные счета организации»

Поле	Тип данных	Ограничения
(*) КодТипаОбъекта	Счетчик	Последовательное, уникальное
НаименованиеТипаОбъекта	Текстовый (20)	Не более 20 символов

Таблица 13. Таблица «Типы операций»

Поле	Контрольный пример 1	Контрольный пример 2
(*) КодТипаОперации	1	2
НаименованиеТипаОперации	Дом	Квартира

Таблица 14. Описание логической структуры таблицы «Типы операций

Поле	Тип данных	Ограничения
(*) КодТипаОперации	Счетчик	Последовательное, уникальное
НаименованиеТипаОперации	Текстовый (20)	Не более 20 символов



2.3.3 Описание запросов к базе данных

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

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

из таблицы СОТРУДНИКИ:

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

из таблицы ОПЕРАЦИИ:

- Дата операции;

- Стоимость.

из таблицы ТИПЫ ОПЕРАЦИИ:

- Тип операции.

из таблицы ОРГАНИЗАЦИЯ:

- Наименование организации;

- ИНН;

- КПП

- Адрес организации;

- Телефон организации;

- Руководитель организации;

- Главный бухгалтер организации.

- Расчетный счет;

- БИК;

- Наименование банка;

- К/С.

Вычисляемые поля: Заработная плата: Операции![Стоимость (руб)]*0,05*0,15

Условия выборки нет.

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

из таблицы СОТРУДНИКИ:

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

из таблицы ОПЕРАЦИИ:

- Дата операции;

- Стоимость.

из таблицы ТИПЫ ОПЕРАЦИИ:

- Тип операции.

из таблицы ОРГАНИЗАЦИЯ:

- Наименование организации;

- ИНН;

- КПП

- Адрес организации;

- Телефон организации;

- Руководитель организации;

- Главный бухгалтер организации.

- Расчетный счет;

- БИК;

- Наименование банка;

- К/С.

Условие отбора:

[СОТРУДНИКИ].[ФИО Сотрудника]=[Введите ФИО сотрудника]

Вычисляемые поля:

Заработная плата: Операции![Стоимость (руб)]*0,05*0,15

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

из таблицы ОПЕРАЦИИ:

- Дата операции;

- Стоимость.

из таблицы ТИПЫ ОПЕРАЦИИ:

- Тип операции.

из таблицы ОБЪЕКТЫ:

- Адрес объекта.

из таблицы СОТРУДНИКИ:

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

из таблицы ОРГАНИЗАЦИЯ:

- Наименование организации;

- ИНН;

- КПП

- Адрес организации;

- Телефон организации;

- Руководитель организации;

- Главный бухгалтер организации.

- Расчетный счет;

- БИК;

- Наименование банка;

- К/С.

Условий для выборки нет.

Вычисляемые поля:

Прибыль от сделки: Операции![Стоимость (руб)]*0,05

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

из таблицы ДОГОВОРЫ:

- Номер договора.

из таблицы ОПЕРАЦИИ:

- Код операции;

- Вид операции;

- Дата проведения операции;

- Сумма в валюте.

из таблицы ОРГАНИЗАЦИЯ:

- Наименование организации;

- ИНН;

- Адрес организации;

- Телефон организации;

- Расчетный счет;

- БИК;

- Руководитель организации;

- Главный бухгалтер организации.

Условие для выборки:

[ОПЕРАЦИИ].[Дата операции]=”Between [Введите начальную дату] And [Введите конечную дату]”

Вычисляемые поля:

Прибыль от сделки: Операции![Стоимость (руб)]*0,05

Запрос «Объекты продажи». Данный запрос формирует список проданных объектов недвижимости. Запрос содержит следующие данные:

из таблицы ТИПЫ ОБЪЕКТОВ:

- Наименование типа объекта.

из таблицы ТИПЫ ОПЕРАЦИИ:

- Тип операции.

из таблицы ОБЪЕКТЫ:

- Адрес объекта;

- Количество комнат;

- Общая площадь;

- Жилая площадь;

- Этаж;

- Этажность;

- Стоимость.

из таблицы ОРГАНИЗАЦИЯ:

- Наименование организации;

- ИНН;

- КПП

- Адрес организации;

- Телефон организации;

- Руководитель организации;

- Главный бухгалтер организации.

- Расчетный счет;

- БИК;

- Наименование банка;

- К/С.

Условие выборки:

[ТИПЫ ОПЕРАЦИЙ].[Наименование типа операции]=«Продажа»

2.3.4 Описание содержания и вида выходных документов

В базе данных будет разработано шесть отчетов: отчет «Вычисление заработной платы», отчет «Заработная плата сотрудника», отчет «Прибыль от сделок», отчет «Прибыль от сделок за период», отчет «Объекты продажи», отчет «Объекты аренды».

Каждый из выходных документов основан на одноименном запросе к базе данных. Соответственно и содержание выходных документов будет результат выполнения запроса. Выходные данные и их источники подробно описаны в разделе 2.3.3

Ниже представлены виды выходных документов.

Рисунок 2.3. Вид отчета «Вычисление заработной платы»

Рисунок 2.4. Окно ввода Фамилии сотрудника для отбора.



Рисунок 2.5. Ввод конечного отрезка времени

2.4 Создание физической модели данных

2.4.1 Описание технологии ведения базы данных

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

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

- через раздел СУБД «Таблицы», производя действия по изменению, добавлению или удалению непосредственно в таблице;

- через раздел СУБД «Формы», выполняя необходимые действия в таблице через интерфейс формы;

- через раздел СУБД «Запросы», выполняя запросы на обновление, добавление или удаление данных.

Наиболее приемлемым и удобным является способ ведения базы данных через интерфейс формы.

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

2.4.2 Создание структуры БД

2.4.2.1 Создание таблиц проектируемой БД

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

Рисунок 2.6. Таблица «Организация».

Рисунок 2.7. Таблица «Объекты».

Рисунок 2.8. Таблица «Сотрудники».



2.4.2.2 Формирование схемы данных

Рисунок 2.9. Схема связей между таблицами БД



4.2.3 Создание форм для ведения проектируемой БД

Рисунок 2.10. Форма «Организация»

Рисунок 2.11. Форма «Клиенты»



2.4.2.4 Создание запросов проектируемой БД

Рисунок 2.12. Запрос «Вычисление заработной платы»



2.5 Разработка информационной системы на основе созданной БД

2.5.1 Схема функциональной структуры приложения

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 2.13. Схема функциональной структуры приложения.

2.5.2 Разработка формы заставки, главной и вторичных кнопочных форм

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

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

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

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

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

2.5.3 Инструкция для пользователя для работы с ИС

Для открытия базы данных запустите файл «Риэлтерское агентство_Твой дом.mdb».

После открытия приложения MS ACCESS на экране появится главная форма приложения.

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

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

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

Для проведения операции купли-продажи (аренды) следует открыть форму «Оформление сделки» и ввести необходимые данные. Пополнить базу сведениями об участниках и объекте сделки можно непосредственно при оформлении сделки.

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

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

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

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

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

Выхода из приложения осуществляется нажатием кнопки «Выход» на главной форме приложения «РА «Твой Дом».



Заключение

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

На основе данных документов и деятельности, связанной с ними, были выявлены 7 сущностей, связанных между собой.

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

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

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

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

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



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

1. Скала В.И. “Охрана труда и техника безопасности”, - СПб: «LEM», 2010. - 276с.: ил.

2. Филиппов В.А. Охрана труда. Правила устройства и безопасной эксплуатации электрооборудования. Москва: Инфра - М, 2009, 144 с.: ил.

3. Под редакцией проф. Горфинкель В.Я. Швандера В.А. Экономика предприятия. Москва: Юнити - Дана, 2010, 718 с.: ил.

4. Романенко И.В. Экономика предприятия. Москва: Эксмо, 2011, 183с.: ил.

5. Епанешников А.М., Епанешников В.А. «Delphi Среда разработки». Учебное пособие М: Диалог - Мифи, 2011г.- 304с.: ил.

6. Фаронов В.В., Шумаков П.В. «DELPHI Руководство разработчика баз данных”, М: Нолидж, 2010, 640с.: ил.

7. Кузан Д.Я., Шапоров В.Н. Программирование Win32 API в Delphi - СПб.: БХВ-Петербург, 2010. 368 с.: ил.

Размещено на Allbest.ru