Базы данных в строительстве реферат

Обновлено: 05.07.2024

База данных Access Строительные фирмы

База данных Access Строительные фирмы предназначена для автоматизации работы компании, основным направлением деятельности которой является строительство, ремонт и продажа недвижимости. В базе таблицы заполнены данными, выполнены простые и перекрестные запросы, а также запросы на добавление, обновление и удаление. Также сделаны формы для работы с данными и отчеты, которые можно выводить на печать.
База данных Access Строительные фирмы содержит 6 таблиц, 13 запросов, 7 форм + главная кнопочная форма, 9 отчетов.

ВНИМАНИЕ! Пояснительной записки нет!

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

Цель практических заданий – приобретение навыков анализа предметной области, проектирования базы данных, ее физической реализации в СУБД Access.
Результат выполнения работы представляется в виде базы Access, который должен содержать:
• структуру спроектированных таблиц,
• схему данных со связями между таблицами,
• примеры форм, обеспечивающих интерфейс пользователя,
• запросы (в режиме Конструктора и на языке SQL),
• отчеты (в режиме отчета и в режиме Конструктора),
• главную кнопочную форму.

Главная кнопочная форма — БД Access Строительные фирмы

Готовая база данных Access Строительные фирмы доступна для скачивания по ссылке ниже.

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

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

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

Из данной цели вытекают следующие задачи:

1. Рассмотрение истории возникновения базы данных (БД) и системы управления базами данных (СУБД) и их основные определения.

2. Выбор основного набора данных, необходимых для составления базы данных и составление инфологической модели;

3. Практическая реализация базы данных в оболочке Microsoft Access.

4. Создание вспомогательных элементов, для упрощения работы с базой данных (создание форм, запросов и отчетов).

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

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

Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных " (БД).

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

Поле – это столбец таблицы.

Запись – аналог строки в таблице.

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

Форма – является основным средством создания диалогового интерфейса приложения пользователя.

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

Макрос – это программа, которая содержит описание последовательности действий, выполняемых, как правило, при наступлении некоторого события в объектах.

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

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

Счетчик – поле, содержащее номера записей в таблице.

Индекс – средство автоматической сортировки записей в таблице по значению индексируемого поля.

Модуль – содержит процедуры на языке VisualBasic.

Проект – служит для объединения элементов приложения и группировки их по типам.

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

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

2. Техническое задание

Основание для разработки.

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

1. Общее проектирование системы;

2. Проектирование структуры данных: выбор полей для включения в таблицы;

3. Проектирование и связывание таблиц;

4. Проектирование полей: правила ввода данных и проверки допустимости их значения;

5. Проектирование запросов;

6. Проектирование форм и отчетов;

7. Проектирование средств автоматизации: создание меню.

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

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

- Информация в таблицах не должна дублироваться;

- Желательно, чтобы каждая таблица содержала информацию только на одну тему;

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

- Информацию об объекте желательно разбивать на минимальные единицы.

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

Краткий формат времени

Краткий формат даты

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

- процессором Pentium II 1500 ГГц;

- 32 Мб оперативной памяти;

- не менее 12 Мб на жестком диске;

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

Этап 1. Общее проектирование системы

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

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

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

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

Этап 2. Проектирования структуры данных: выбор полей для включения в таблицы.

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

Этап 3. Проектирование и связывание таблиц.

Этап 4. Проектирование полей: правила ввода данных и проверки допустимости их значения.

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

Проектирование имен, типов и размеров полей.

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

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

Таблица 7 - Типы данных Access

Алфавитно-цифровые символы; до 255 знаков

Алфавитно-цифровые символы; строки длиной до 64 тыс. знаков

Числовые значения многих типов и форматов

Значение дат и времени

Данные, представляющие собой денежные суммы

Автоматически наращивает числовой счетчик

Логическое значение Да/Нет, Истина/Ложь

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

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

Таблица 8 - Клиенты

Этап 5. Проектирование форм.

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

При проектировании форм необходимо предусмотреть размещение на экране трех типов объектов:

- Надписей и текстовых полей для полей ввода данных;

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

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

Этап 6. Проектирование средств автоматизации: создание меню.

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

Создание базы данных состояло из следующих шагов:

1.Одним из известных способов запустим MS Access;

6.Введём имена полей и типы в соответствии с инфологической и даталогической моделями;

8.Подобным образом создадим остальные таблицы;

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

23. Заполним таблицы некоторыми данными, вводя их в созданную форму;

24. Создадим ещё одну форму, которая будет отображаться при открытии базы данных;

3.2 Инструкция пользователя

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

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

Назначение кнопок на главной кнопочной форме.

В ыводы

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

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

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

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

Литература

1. Д. Дейт. Введение в систему баз данных. - М., СПб.: BHV - Санкт - Петербург 1977.- 312с.

3. Ф. Баркет. Использование MS Access 97 – М., СПб.: BHV - Санкт - Петербург 1977.- 390с.

4. С. Глушаков. Базы данных. – Х., Фолио, 2001. – 504 с.

6. В. Пасько. Access 2000. – К., Издательская группа BHV, 1999. – 384 с.

7. Ю. Бекаревич. MS Access 2000 за 30 занятий. – СПб.: БХВ – Санкт-Петербург, 2000. – 512 с.

Из данной цели вытекают следующие задачи:

3. Практическая реализация базы данных в оболочке Microsoft Access.

Поле – это столбец таблицы.

Запись – аналог строки в таблице.

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

Форма – является основным средством создания диалогового интерфейса приложения пользователя.

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

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

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

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

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

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

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

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

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

Концептуальное (инфологическое) проектирование.

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

Чаще всего концептуальная модель базы данных включает в себя:

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

Инфологическую модель можно создавать с помощью нескольких методов и подходов:

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

Для каждой отдельной сущности выбираются атрибуты (набор свойств), которые в зависимости от критерия могут быть:

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

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

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

Логическое (даталогическое) проектирование.

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

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

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

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

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

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

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

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

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

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

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

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

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

Вторая задача вступает в конфликт с первой, поскольку, например:

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

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

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

Выбор системы управления и программных средств БД.

От выбора системы управления БД зависит практическая реализация информационной системы. Наиболее значимыми критериями в процессе выбора становятся параметры:

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

Ошибки в выборе СУБД практически наверняка впоследствии спровоцируют необходимость корректировать концептуальную и логическую модели.

Читайте также: