Сдача в аренду торговых площадей

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

Министерство образования и науки

Российской Федерации

Федеральное агентство по образованию

Тихоокеанский государственный

экономический университет

Кафедра информатики и математики

Курсовая работа

по дисциплине: «Базы данных»

Тема: «Сдача в аренду торговых площадей»

СОДЕРЖАНИЕ

• СОДЕРЖАНИЕ
• ВВЕДЕНИЕ
• 1. ИНФОРМАЦИОННАЯ МОДЕЛЬ И БАЗА ДАННЫХ
• 1.2 Определение базы данных
• 2. МОДЕЛИ ПРЕДСТАВЛЕНИЯ ДАННЫХ
• 2.1 Иерархическая модель данных
• 2.2 Сетевая модель данных
• 2.3 Реляционная модель данных
• 3. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ
• 3.1 Этапы проектирования баз данных
• 3.2 Инфологическая модель данных “сущность - связь”
• 3.3 Даталогическая модель данных
• 3.4 Переход от ER-модели к реляционной
• 3.5 Физическая модель данных
• 4. ПРАКТИЧЕСКАЯ ЧАСТЬ
• 4.1 Предметная область и задачи, возложенные на базу данных
• 4.2 ER-диаграмма базы данных
• 4.3 Программная реализация
• ЗАКЛЮЧЕНИЕ
• СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ
• ПРИЛОЖЕНИЯ
• ВВЕДЕНИЕ
• Стремительное развитие информационных технологий позволяет автоматизировать работу в различных сферах деятельности. Внедрение специализированного программного обеспечения на производстве позволяет сэкономить затраченное время и вложенные средства. Современные программные продукты имеют удобный и простой пользовательский интерфейс, а также минимальные системные требования рабочих станций для их эксплуатации - это способствует использованию ПО при минимальных финансовых вложениях и обучение пользователей в минимальные сроки.
• Актуальным вопросом в настоящее время является создание автоматизированных систем, которые требуют минимальных человеческих затрат и выполняют огромные расчеты за доли секунд, выполняя которые человек затрачивает немало времени и ресурсов. Примером такой автоматизированной системы является и СУБД MS Access.
• Это актуально в данное время, так как рынок программного обеспечения постоянно изменяется, стремительно развивается компьютерная техника, и нужно иметь представление, какие возможности предоставляет то или иное программное обеспечение.

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

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

труд автоматизация арендатор

1. ИНФОРМАЦИОННАЯ МОДЕЛЬ И БАЗА ДАННЫХ

1.1 Понятие информационной системы

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

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

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

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

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

1.2 Определение базы данных

База данных - это поименованная совокупность взаимосвязанных данных, находящихся под управлением СУБД.

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

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

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

2. МОДЕЛИ ПРЕДСТАВЛЕНИЯ ДАННЫХ

2.1 Иерархическая модель данных

В классических иерархических моделях имеется один файл, который является входом в структуру (корень дерева). Остальные файлы связаны друг с другом таким образом, что каждый из них, за исключением корневой вершины, имеет ровно одну исходную вершину («родитель») и любое число подчиненных вершин («детей»). Между записью файла-родителя и записями порожденного файла имеется отношение 1:М (как частный случай может быть и отношение 1:1). Имеются и другие разновидности иерархических моделей, но они менее распространены.

Графическое представление иерархической модели представляет собой граф типа «дерево» (рис. 1). В такой модели имеется одна вершина - корень дерева, являющаяся входом в структуру. Каждая вершина, отличная от корня, может иметь только одну исходную вершину и в общем случае сколько угодно порожденных вершин.

Рис. 1. Схема иерархической модели

2.2 Сетевая модель данных

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

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

Графическое представление сетевой модели представляет собой граф типа «сеть». Входом в такую структуру может являться любая вершина. Каждая вершина может иметь как несколько порожденных, так и несколько исходных вершин. Между парой вершин может быть объявлено несколько связей. Подавляющее большинство СУБД поддерживает простые сетевые структуры, т.е. между каждой парой типов записей поддерживается отношение 1:М (один ко многим). Направление и характер связи в сетевых моделях не являются очевидными, как в случае иерархической модели, поэтому при изображении структуры БД направление связи должно быть указано.

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

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

2.3 Реляционная модель данных

В таких моделях используется своеобразная терминология, но это не меняет сущности модели. Часто даже в рамках одной модели в разных СУБД используется разная терминология. Так, на логическом уровне элемент чаще всего называют атрибутом; кроме того, для него используются термины «колонка», «столбец», «поле». Совокупность атрибутов образует строку (синонимичные термины - «ряд», «запись», «кортеж»). Совокупность строк образует отношение («таблицу», «файл базы данных»). Понятие базы данных как множества отношений поддерживается далеко не всеми реляционными СУБД (т.е. при создании БД описываются отдельные отношения (файлы, таблицы), а для всей базы данных как самостоятельной информационной единицы никакого описания не предусмотрено). Однако следует отметить, что в последнее время новые версии даже тех настольных СУБД, которые раньше не поддерживали понятие БД, сейчас его включают.

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

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

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

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

2.3.1 Таблицы

Таблица - основная структурная единица реляционной базы данных, представляющая собой подмножество декартова произведения доменов. В реляционной теории используется термин «отношение». Часто эти термины используются как синонимы. Иногда они различаются: таблица считается способом хранения (отображения) отношения.

2.3.2 Ключевые поля

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

2.3.3 Индексы

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

2.3.4 Внешние ключи

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

3. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

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

При разработке БД можно выделить следующие этапы работы:

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

2 этап. Анализ объекта. На этом этапе рассматривается, из каких объектов может состоять БД, каковы свойства этих объектов. После разбиения БД на отдельные объекты необходимо рассмотреть свойства каждого из этих объектов, или, другими словами, установить, какими параметрами описывается каждый объект. Все эти сведения можно располагать в виде отдельных записей и таблиц. Далее необходимо рассмотреть тип данных каждой отдельной единицы записи. Сведения о типах данных также следует занести в составляемую таблицу.

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

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

В большинстве СУБД данные можно хранить в двух видах:

· с использованием форм;

· без использования форм.

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

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

Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

Стадия 2. Создание исходной таблицы или таблиц.

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

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

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

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

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

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

Стадия 3. Создание экранных форм.

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

Стадия 4. Заполнение БД.

Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE - в виде формы.

3.2 Инфологическая модель данных “сущность - связь”

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

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

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

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

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

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

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

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

Связи бывают:

1. "один к одному" - одна запись 1 таблицы, соответствует только одной записи второй таблицы и наоборот.

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

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

3.3 Даталогическая модель данных

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

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

- Описание концептуальной схемы БД в терминах выбранной СУБД.

- Описание внешних моделей в терминах выбранной СУБД.

- Описание декларативных правил поддержки целостности базы данных.

- Разработка процедур поддержки семантической целостности базы данных.

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

3.4 Переход от ER-модели к реляционной

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

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

Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

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

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

3.5 Физическая модель данных

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

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

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

Режим 1. Получить все данные (последовательная обработка).

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

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

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

1) высокая скорость доступа к данным;

2) простота обновления данных.

Еще одним относительно новым требованием является объем дополнительно используемой (вторичной) памяти.

В физической БД следует рассматривать методы размещения (запись и хранение) данных и методы доступа (поиск) к ним.

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

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

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

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

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

Прямой метод. Имеется взаимно-однозначное соответствие между ключом записи и ее физическим адресом.

4. ПРАКТИЧЕСКАЯ ЧАСТЬ

4.1 Предметная область и задачи, возложенные на базу данных

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

Положение изменилось с появлением в составе пакета Microsoft Office СУБД Access. С помощью Access обычные пользователи получили удобное средство для создания и эксплуатации достаточно мощных баз данных без необходимости что-либо программировать. При желании систему можно развивать и настраивать собственными силами. Еще одним дополнительным достоинством Access является интегрированность этой программы с Excel и Word.

Именно благодаря этим и другим свойствам курсовой проект реализован в MS Access 2003. Одним из самых важных аспектов выгодности использования Access - минимизация затрат на разработку и дальнейшее сопровождение ПО; обеспечение надежности ЭИС и защиты информации.

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

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

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

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

4.2 ER-диаграмма базы данных

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

Основными понятиями ER-модели являются, как было упомянуто ранее, сущность, связь и атрибут.

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

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

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

Все эти сущности и связи между ними наглядно представлены в ER-диаграмме.

С помощью представленных в ER-диаграмме сущностей и связей между ними можно получить даталогическую модель данных представленную в Microsoft Office Access (приложение 1).

У каждой сущности есть свои атрибуты:

Таблица 1

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

Атрибуты
N/N	Название	Тип	Обяз.	Описание
1	КОД АРЕНДЫ	Счетчик	Д	Код аренды
2	КОД ТОРГОВОЙ ТОЧКИ	Числовой	Д	Код торговой точки
3	КОД КЛИЕНТА	Числовой	Д	Код клиента
4	ДАТА НАЧАЛА	Дата/Время	Д	Дата заключения договора
5	ДАТА ОКОНЧАНИЯ	Дата/Время	Д	Дата окончания договора

Таблица 2

Связи сущности «Аренда»

Связь
Название	Тип	Обязательность	Кардинальность
	ТОРГОВЫЕ ТОЧКИ	один	и более
	КЛИЕНТЫ	нуль	и более
	ЕЖЕМЕСЯЧНЫЕ ПЛАТЕЖИ	один	и более

Таблица 3

Сущность «Торговые точки»

Атрибуты
N/N	Название	Тип	Обяз.	Описание
1	КОД ТОРГОВОЙ ТОЧКИ	Счетчик	Д	Код торговой точки
2	ЭТАЖ	Числовой	Д	Этаж
3	ПЛОЩАДЬ	Числовой	Д	Площадь аренды
4	НАЛИЧИЕ КОНДИЦИОНЕРА	Логический	Д	Кондиционер
5	СТОИМОСТЬ АРЕНДЫ В ДЕНЬ	Денежный	Д	Плата за аренду
6	СВОБОДНАЯ ТОРГОВАЯ ТОЧКА	Логический	Д	Состояние аренды

Таблица 4

Связи сущности «Торговые точки»

Связь
Название	Тип	Обязательность	Кардинальность
	АРЕНДА	нуль	и более

Таблица 5

Сущность «Клиенты»

Атрибуты
N/N	Название	Тип	Обяз	Описание
1	КОД КЛИЕНТА	Счетчик	Д	Код клиента
2	НАЗВАНИЕ	Текстовый	Д	Название организации
3	РЕКВИЗИТЫ	Текстовый	Д	Реквизиты организации
4	АДРЕС	Текстовый	Д	Адрес организации
5	ТЕЛЕФОН	Текстовый	Д	Телефон организации
6	КОНТАКТНОЕ ЛИЦО	Текстовый	Д	Контактное лицо организации

Таблица 6

Связи сущности «Клиенты»

Связь
Название	Тип	Обязательность	Кардинальность
	АРЕНДА	один	и более

Таблица 7

Сущность «Ежемесячные Платежи»

Атрибуты
N/N	Название	Тип	Обяз.	Описание
1	КОД ПЛАТЕЖА	Счетчик	Д	Код платежа
2	КОД АРЕНДЫ	Числовой	Д	Код аренды
3	ДАТА	Дата/Время	Д	Дата выплаты
4	ПЛАТЕЖ	Денежный	Д	Сумма платежа

Таблица 8

Связи сущности «Ежемесячные платежи»

Связь
Название	Тип	Обязательность	Кардинальность
	АРЕНДА	один	и более

4.3 Программная реализация

База данных реализована в системе управления базами данных Microsoft Access 2003 . Microsoft Access - база данных работающая под операционной системой Microsoft Windows .

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

Рис.6. Главная форма

Рис.7. Форма Аренда

В этой форме заключается договора на аренду.

Рис.8. Форма клиенты

В этой форме находятся данные о клиентах

Рис.9. Категории товаров

В форме Торговые точки находятся данные о торговых точках сдаваемых в аренду

Рис. 10. Свободные торговые точки

В этой форме находятся данные о торговых точках не сданных в аренду

Рис.11. Ежемесячные платежи

В этой форме данные о всех платежах клиентов.



Отчет о ежемесячных платежах.

Рис.12. Архив договоров

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

Отчет архив договоров.

Рис.13 Отчет о сдаче торговых площадей.

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

ЗАКЛЮЧЕНИЕ

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

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

Программа «Аренда торговых помещений» создавалась для помощи и облегчения повседневной работы сотрудников работающих в этой области. В отличие от неавтоматизированной работы данная программа отличается высокой точностью и надежностью. Автоматизация позволяет быстро и надежно выполнять требуемые операции, при помощи компьютера и программы Microsoft Access. Она отвечает следующим требованиям:

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

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

- выборка информации по разным запросам пользователя;

- обеспечение целостности и сохранности данных в течение долгого времени;

- вывод информации на печать при помощи отчетов.

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

1. Access 7.0 Торговое издательское бюро BHV, 1996.

2. Симонович. С.В. Специальная информатика. Учебное пособие, АРТ-Пресс, 1998.

3. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. - М.: Финансы и статистика, 1998. - 351 с.

4. Гилуа М.М. Множественная модель данных в информационных системах. - М.: Наука, 1992.

5. Голосов А.О. Аномалии в реляционных базах данных //СУБД. - 1999. - №3. - С.23-28.

6. Дейт К. Введение в системы баз данных //6-издание. - Киев: Диалектика, 1998. - 784 с.

7. Диго С.М. Проектирование и использование баз данных. - М.: Финансы и статистика, 2000. - 208 с.

8. Глушков С.В., Ломотько А.В. «База данных» - Харьков: ФОЛИО; ООО «Издательство ДТС» - 2002. - 504 с. - (Учебный курс).

9. Джулия Келли. Access 97. Самоучитель - СПб: Питер. - 1999. - 336с.

10. Дженнингс Р. Microsoft Access 97. - СПб.: BHV - Санкт-Петербург. - 1999. - 1270с.

11. А.С. Марков К.Ю. Лисовский - Базы данных «Введение в теорию и методологию»

12. М.Р. Когаловский - «Энциклопедия технологий баз данных» 2002г.

13. С.Д. Кузнецов - «Основы современных баз данных»

14. Дж. Мартин - «Организация баз данных в вычислительных системах»

15. Дейт К.Дж. - «Введение в системы баз данных»

ПРИЛОЖЕНИЯ

ПРИЛОЖЕНИЕ 1

Рис.14.Схема данных

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