АРМ бухгалтера жилищного кооператива

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

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

Задание

на курсовой проект

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

Студент должен:

1. Выполнить проектирование схемы данных в соответствии с заданным вариантом:

составить список данных, которые необходимо хранить в БД;

определить необходимое количество и структуру таблиц;

назначить ключевые поля для каждой таблицы;

установить связи между таблицами;

составить схему данных.

2. С помощью СУБД создать базу данных:

создать таблицы с помощью СУБД (не менее 3-4 таблиц);

установить связи между таблицами (составить схему данных);

заполнить таблицы данными по своему усмотрению (число записей должно быть не менее 10).

3. Составить программу, в которой предусмотреть:

создать главное меню системы;

создать формы вывода и редактирования данных;

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

создать интерфейс (меню, формы, окна, кнопки);

предусмотреть формирование и вывод данных на принтер в виде отчета.

4. Составить инструкцию пользователя по работе с АРМ.

Вариант 13. «АРМ бухгалтера жилищного кооператива»

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

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

Программное обеспечение АРМ бухгалтера должно позволять -

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

2) выводить в удобной форме данные по следующим запросам пользователя:

поиск данных о тарифе по номеру или названию услуги;

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

расчет квартплаты для каждой квартиры с учетом льгот;

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

расчет суммарной квартплаты по квартирам и видам услуг (перекрестный);

3) автоматизировать обработку информации при следующих бизнес-операциях:

ежемесячный сбор сведений о потребленных коммунальных услугах (ввод и коррекция данных о количестве услуг);

изменение тарифов на коммунальные услуги;

составление списка должников;

4) выводить следующие данные на печать - квитанция об оплате коммунальных услуг; ведомость оплаты коммунальных услуг за месяц; список должников.

Введение

С начала развития вычислительной техники образовались два основных направления ее использования:

· выполнение расчетов, которые невозможно производить вручную;

· создание автоматизированных информационных систем (АИС).

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

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

Система баз данных (СБД) - это система специально организованных данных (баз данных), программных, технических, языковых, организационно-методических средств для централизованного накопления и коллективного многоцелевого использования данных.

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

Основные требования к СБД можно сформулировать следующим образом:

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

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

· дружественность интерфейса;

· обеспечение секретности и конфиденциальности;

· обеспечение взаимной независимости программ и данных;

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

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

1. Основные определения теории БД

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

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

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

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

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

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

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

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

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

Модель данных - совокупность структур данных и операций их обработки.

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

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

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

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

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

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

Иногда ключевое поле называют первичным ключом.

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

Базы данных классифицируются:

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

- По способу доступа к данным: базы данных с локальным доступом и базы данных с удаленным (сетевым) доступом.

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

* файл-сервер;

* клиент-сервер.

2. Организация баз данных - физическая и логическая

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

Рис. 2.1. Трехуровневая модель системы управления базой данных, предложенная ANSI

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

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

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

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

Логическая организация БД - представление пользователя о той предметной области, информация о которой должна храниться в БД, то есть это логическая модель предметной области. Такая модель отражает 3 вида информации:

сведения об объектах предметной области;

их свойства;

отношения между объектами.

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

Логическую модель можно представить несколькими способами. Для ИС характерны 2 способа схемы представления данных - графический и табличный.

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

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

В настоящее время известны 3 графические модели:

иерархическая;

сетевая;

реляционная.

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

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

Основными средствами физического моделирования в БД являются:

структура хранения данных;

поисковая структура;

язык описания данных.

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

1) Организация на основе структуры хранения данных;

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

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

3. Распределенные БД. Определение и основные характеристики распределенных БД. Сравнение централизованной и клиент-серверной архитектур БД

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

РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:

а) каждый узел -- это полноценная СУБД сама по себе;

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

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

Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.

Отсюда возникают дополнительные цели:

1. Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.

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

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

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

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

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

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

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

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

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

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

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

Модель с централизованной архитектурой 

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

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

Рис. 3.1. Централизованная архитектура

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

Модель с архитектурой "клиент-сервер"

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

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

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

В результате работа построена следующим образом:

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

СУБД располагается также на сервере сети.

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

На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к СУБД, расположенной на сервере, на выборку/обновление информации. Для общения используется специальный язык запросов SQL, т.е. по сети от клиента к серверу передается лишь текст запроса.

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

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

Таким образом, СУБД возвращает результат в приложение.

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

Функции приложения-клиента:

? Посылка запросов серверу.

? Интерпретация результатов запросов, полученных от сервера.

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

Функции серверной части:

? Прием запросов от приложений-клиентов.

? Интерпретация запросов.

? Оптимизация и выполнение запросов к БД.

? Отправка результатов приложению-клиенту.

? Обеспечение системы безопасности и разграничение доступа.

? Управление целостностью БД.

Основные достоинства данной архитектуры по сравнению с централизованной:

Существенно уменьшает сетевой трафик.

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

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

Существенно повышает целостность и безопасность БД.

Недостатки данной архитектуры:

Внедрение архитектуры «клиент-сервер» требует существенных финансовых ресурсов.

Своевременное обновление клиентских приложений на всех компьютерах-клиентах.

4. Разновидности и особенности современных СУБД

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

4.1 Характеристика реляционных СУБД

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

Реляционный подход в построении СУБД имеет ряд достоинств:

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

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

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

Реляционная модель имеет строгое теоретическое обоснование. Эта теория способствовала созданию декларативного языка SQL, который в настоящее время стал стандартным в отношении определения и манипулирования реляционными базами данных. Другие сильные стороны реляционной модели - простота, пригодность для систем интерактивной обработки транзакций (OLTP), обеспечение независимости от данных.

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

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

4.2 Характеристика объектных СУБД

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

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

В объектной технологии свойства данных не сводятся к простым "компьютерным" типам данных. Объекты могут содержать внутри себя другие объекты или ссылки на них. Это облегчает построение точных и удобных моделей данных.

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

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

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

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

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

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

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

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

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

4.3 Характеристика распределенных СУБД

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

Достоинства распределенных СУБД:

отражают структуру организации;

обладают разделяемостью и локальной автономностью;

обеспечивают высокую доступность данных;

обладают высокой надежностью и повышенной производительностью.

Недостатки распределенных СУБД:

сложные программные комплексы; увеличение сложности означает и увеличение затрат на приобретение и сопровождение;

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

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

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

5. Основные элементы приложений информационных систем

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

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

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

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

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

Групповые и корпоративные информационные системы и соответствующие приложения могут строиться различными способами:

многотерминальные централизованные вычислительные системы;

системы на основе локальной сети ПК (файл-серверные приложения);

системы с архитектурой клиент-сервер;

системы с распределенными вычислениями;

офисные системы;

системы на основе Internet/Intranet-технологий.

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

PS (Presentation Services) - средства представления. Обеспечиваются устройствами, принимающими ввод от пользователя и отображающим то, что сообщает ему компонент логики представления PL, плюс соответствующая программная поддержка. Может быть текстовым терминалом или Х-терминалом, а также ПК или рабочей станцией в режиме программной эмуляции терминала или Х-терминала.

PL (Presentation Logic) - логика представления. Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя по выбору альтернативы меню, по нажатию кнопки или при выборе элемента из списка.

BL (Business or Application Logic) - прикладная логика. Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение.

DL (Data Logic) - логика управления данными. Операции с базой данных (SQL-операторы SELECT, UPDATE и INSERT), которые нужно выполнить для реализации прикладной логики управления данными.

DS (Data Services) - операции с базой данных. Действия СУБД, вызываемые для выполнения логики управления данными, такие как манипулирование данными, определения данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL-предложения.

FS (File Services) - файловые операции. Дисковые операции чтения и записи данных для СУБД и других компонент. Обычно являются функциями ОС.

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

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

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

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

- квартиры

- жильцы

- льготы

- тарифы

- задолженности

- коммунальные организации.

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

- каждый жилец живет в какой-либо квартире, и в каждой квартире может жить более одного жильца;

- каждая квартира определяется номером и адресом (улица/дом);

- некоторые жильцы имеют льготы по некоторым услугам;

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

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

7. Структура БД (структуры таблиц и схема данных)

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

Определяем структуру таблиц. Создать структуру таблицы означает:

- определить число полей таблицы;

- каждому полю присвоить своё имя;

- определить тип поля;

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

- присвоить таблице уникальное имя.

Разные типы полей имеют разное назначение и разные свойства.

1. Текстовое поле. Основное свойство текстового поля - размер.

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

3. Поля для ввода дат или времени имеют тип Дата/время.

4. Для ввода логических данных служит специальный тип - Логическое поле, имеющие только два значения (Да или Нет; 0 или 1; Истина или Ложь и т. п.).

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

6. В современных базах данных можно хранить не только числа и буквы, но и картинки, музыкальные клипы и видеозаписи. Поле для таких объектов называется полем объекта OLE.

7. У текстового поля есть недостаток, связанный с тем, что оно имеет ограниченный размер (не более 256 символов). Если нужно вставить в поле длинный текст, для этого служит поле типа MEMO. В нем можно хранить до 65 535 символов. Особенность поля MEMO состоит в том, что реально эти данные хранятся не в поле, а в другом месте, а в поле хранится только указатель на то, где расположен текст.

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

На основании вышеизложенного были составлены следующие таблицы:

tblStreet

Имя поля	Тип данных	Описание
IDStreet	Счетчик	Первичный ключ
NameStreet	Текстовый

tblHouse

Имя поля	Тип данных	Описание
IDStreet	Числовой	Внешний ключ
IDHouse	Счетчик	Первичный ключ
NomHouse	Числовой

tblKvartira

Имя поля	Тип данных	Описание
ID	Счетчик	Первичный ключ
IDHouse	Числовой	Внешний ключ
NomKvartira	Числовой

tblPeople

Имя поля	Тип данных	Описание
IDStreet	Числовой	Внешний ключ
IDHouse	Числовой	Внешний ключ
Fam	Текстовый
Name	Текстовый
Ot	Текстовый
NomKV	Числовой	Внешний ключ
ID	Счетчик	Первичный ключ

tblPeopleLgota

Имя поля	Тип данных	Описание
IDStreet	Числовой	Внешний ключ
IDHouse	Числовой	Внешний ключ
Fam	Текстовый
Name	Текстовый
Ot	Текстовый
NomKV	Числовой	Внешний ключ
ID	Счетчик	Первичный ключ
LgotaID	Числовой

Льготы

Имя поля	Тип данных	Описание
Код льготы	Числовой	Первичный ключ
Льгота	Текстовый
Процент льготы	Числовой

tblOplat

Имя поля	Тип данных	Описание
IDMoney	Счетчик	Первичный ключ
IDHouse	Числовой	Внешний ключ
IDStreet	Числовой	Внешний ключ
IDUsluga	Числовой
Summa	Числовой
KolEdUsl	Числовой
DateOpl	Дата/время
DateKvitOpl	Дата/время
NomKVart	Числовой	Внешний ключ

Виды услуг

Имя поля	Тип данных	Описание
Код услуги	Числовой	Первичный ключ
Услуга	Текстовый
Тариф услуги	Денежный

Все таблицы были объединены в обобщенную схему данных.

Рисунок 1 - схема данных

8. Схема интерфейса и образцы элементов интерфейса

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

Рисунок 2 - главная кнопочная форма

Рисунок 3 - кнопочная форма "Льготы"

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

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

Запрос на выборку должников за март месяц.

Рисунок 4 - Структура запроса "Должники"

Рисунок 5 - Результат запроса "Должники"

Запрос квитанции на оплату по определенной квартире

Рисунок 6 - Структура запроса "Квитанция на оплату"

Рисунок 7 - результат запроса "Квитанция на оплату"

3) Создание диаграммы по сумме оплаты и квартире

Рисунок 8 - Диаграмма "Сумма оплаты

4) Формирование квитанции об оплате

база данные паспортный интерфейс

Рисунок 9 - структура запроса на оплату

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

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

В таблице жильцов кооперативного дома имеются все данные: улица, дом, квартира, ФИО, льгота (если есть); также в соответствующие таблицы внесены услуги, тарифы на них и льготы с наименованием и процентом льготы.

1. Пункт меню

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

2. Пункт меню

Здесь по коду льготы можно найти с помощью "бинокля" категорию льготы и льготный процент оплаты коммунальных услуг

3. Пункт меню

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

4. Пункт меню

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

5. Пункт меню

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

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



Заключение

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

Разработанная программа позволяет:

хранить информацию;

выводить в удобной форме;

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

создавать диаграмму;

автоматизировать обработку информации;

выводить выходные документы на печать.

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

Литература

Базы данных: учебно-практическое пособие / С. М. Диго - М. : ЕАОИ, 2011, - Электронное издание (гриф УМО).

Баринов А.Н., Вендров А.М. Системы управления базами данных и знаний - М.: Финансы и статистика, 2011.

Гетц К., Литвин П., Бэрон Э. Microsoft Access 2007. Сборник рецептов для профессионалов - Спб: Питер, 2012.

Гончаров А.Ю. Access 2007 Самоучитель с примерами М.: «Кудиц- ПРЕСС», 2010.

Енин А.Н. Локальная СУБД своими руками. -М.: «Солон- Пресс», 2012.

Кошелев В. Е. Access 2007. Эффективное использование. М.: Бином- Пресс, 2012.

Кузин А.В. Разработка баз данных в системе Microsoft Access. «Инфра- М» , 2014.

Лимеев А.В. Тестирование программ. - Спб.:БХВ - Санкт-Петербург, 2009.

Новиков Б.С. Настройка приложений баз данных - Спб.:БХВ - Санкт-Петербург, 2012.

Тарасов С.В. СУБД для программиста. Базы данных изнутри. - Спб.:БХВ- Санкт-Петербург, 2014.

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