Распределенная база данных предполагает хранение данных на нескольких узлах сети обработку данных и их п

Работа добавлена на сайт samzan.net:

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

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

Терминология

Пользователь БД — программа или человек, обращающийся к БД на ЯМД.

Запрос — процесс обращения пользователя к БД с целью ввода, получения или изменения информации в БД.

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

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

Топология БД = Структура распределенной БД — схема распределения физической БД по сети.

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

Удаленный запрос — запрос, который выполняется с использованием модемной связи.

Возможность реализации удаленной транзакции — обработка одной транзакции, состоящей из множества SQL-запросов на одном удаленном узле.

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

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

2 МОДЕЛЬ 'ФАЙЛ-СЕРВЕР'

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

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

Преимущества

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

Недостатки

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

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

4, 5 Функции ввода и отображения данных (Presentation Logic – презентационная логика). К этой функции относятся все интерфейсные экранные формы, с которыми работает пользователь, а также отображаемая на экране результативная и справочная информация. 2.Прикладные функции, определяющие основные алгоритмы решения задач (Business Logic – бизнес-логика). 3.Функции обработки данных внутри приложения (Database Logic – логика обработки данных). 4.Функции управления информационными ресурсами (Database Manager Logic). Это собственно СУБД, обеспечивающая хранение и управление базами данных. 5.Служебные функции, играющие роль связок между функциями первых четырех групп.

Модель удаленного управления данными. Модель файлового сервера

Модель удаленного управления данными также называется моделью файлового сервера (File Server, FS). В этой модели презентационная логика и бизнес-логика располагаются на клиенте. На сервере располагаются файлы с данными и поддерживается доступ к файлам. Функции управления информационными ресурсами в этой модели находятся на клиенте.

Распределение функций в этой модели представлено на рис. 10.4.

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

Рис. 10.4. Модель файлового сервера

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

Каков алгоритм выполнения запроса клиента?

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

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

Недостатки:

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

8 Модель удаленного доступа к данным основана на учете специфики размещения и физического манипулирования данных во внешней памяти для реляционных СУБД. В RDA-модели компонент доступа к данным в СУБД полностью отделен от двух других компонентов (компонента представления и прикладного компонента) и размещается на сервере системы. Компонент доступа к данным реализуется в виде самостоятельной программной части СУБД, называемой SQL-сервером, и инсталлируется на вычислительной установке сервера системы. Функции SQL-сервера ограничиваются низкоуровневыми операциями по организации, размещению, хранению и манипулированию данными в дисковой памяти сервера. Иначе говоря, SQL-сервер играет роль машины данных.

Модели серверов баз данных.

Недостатки:

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

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

Вышеперечисленные недостатки устраняются в модели (архитектуре) "систем с выделенным сервером", который способен обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами. Логически каждый клиент связан с сервером отдельной нитью (tread), или потоком, по которому пересылаются запросы.
Такая архитектура получила название многопотоковой односерверной.
Достоинства:

уменьшается нагрузка на ОС, возникающая при работе большого числа пользователей.

Многопотоковая односерверная архитектура.

Недостатки:
Т.к. сервер может выполняться только на одном процессоре, возникает ограничение на применение СУБД для мультипроцессорных платформ. Например, если компьютер имеет 4 процессора, то СУБД с одним сервером использует только один из них, не загружая оставшиеся 3.
В некоторых системах эта проблема решается вводом промежуточного диспетчера - архитектура виртуального сервера.
Архитектура виртуального сервера.

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

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

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

Сервер приложений (англ. application server) — это программная платформа (software framework), предназначенная для эффективного исполнения процедур (программ, механических операций, скриптов), которые поддерживают построение приложений. Сервер приложений действует как набор компонентов, доступных разработчику программного обеспечения через API (Интерфейс прикладного программирования), который определен самой платформой.

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

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

Преимущества серверов приложений

Целостность данных и кода

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

Централизованная настройка и управление

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

Безопасность

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

Поддержка транзакций

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

Примеры реализации

Под сервером приложений в случае Java EE подразумевается комплекс программ, реализующих концепцию Java EE и позволяющих запускать в себе Java EEприложения. К классу серверов приложений относятся такие продукты как Sun GlassFish, IBM WebSphere, RedHat JBoss Application Server, Apple WebObjects (англ.) и др.
Zope, развитый сервер web-приложений.
Терминальные серверы, например поставляемые компанией Citrix

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

12 Обработку всех клиентских запросов выполняет один серверный процесс (использующий один процессор), взаимодействующий со всеми клиентами и монопольно управляющий ресурсами (Рис. 19-6). При этом для отдельного клиентского процесса создаётся поток, (thread) в рамках которого локализуется обработка запроса.

13 Архитектура виртуального сервера.

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

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

Многопотоковая односерверная архитектура

Обработку всех клиентских запросов выполняет один серверный процесс (использующий один процессор), взаимодействующий со всеми клиентами и монопольно управляющий ресурсами (Рис. 19-6). При этом для отдельного клиентского процесса создаётся поток, (thread) в рамках которого локализуется обработка запроса.

15 16 17

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

Рис. 10.12. Многонитевая мультисерверная архитектура

Типы параллелизма

Рассматривают несколько путей распараллеливания запросов.

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

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

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

И третий вид параллелизма является гибридом двух ранее рассмотренных (см. рис. 10.14).

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

Рис. 10.13. Выполнение запроса при вертикальном параллелизме

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

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

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

Хранимые процедуры похожи на определяемые пользователем функции (UDF). Основное различие заключается в том, что пользовательские функции можно использовать как и любое другое выражение в SQL запросе, в то время как хранимые процедуры должны быть вызваны с помощью функции CALL:

CALL процедура(…)

или

EXECUTE процедура(…)

Хранимые процедуры могут возвращать множества результатов, то есть результаты запроса SELECT. Такие множества результатов могут обрабатываться, используя курсоры, другими сохраненными процедурами, возвращая указатель результирующего множества, либо же приложениями. Хранимые процедуры могут также содержать объявленные переменные для обработки данных и курсоров, которые позволяют организовать цикл по нескольким строкам в таблице. Стандарт SQL предоставляет для работы выражения IF, LOOP, REPEAT, CASE и многие другие. Хранимые процедуры могут принимать переменные, возвращать результаты или изменять переменные и возвращать их, в зависимости от того, где переменная объявлена.

Реализация хранимых процедур варьируется от одной СУБД к другой. Большинство крупных поставщиков баз данных поддерживают их в той или иной форме. В зависимости от СУБД, хранимые процедуры могут быть реализованы на различных языках программирования, таких, как SQL, Java, C или C++. Хранимые процедуры написанные не на SQL могут самостоятельно выполнять SQL-запросы, а могут и не выполнять. Все более широкое использование хранимых процедур привело к появлению процедурных элементов в языке SQL стандарта SQL:1999 и SQL: 2003 в части SQL/PSM. Это сделало SQL императивным языком программирования. Большинство СУБД предлагают собственные проприетарные и расширения производителя, сверх SQL/PSM.

Генераторы предназначены для получения последовательностей уникальных чисел. Например - 1, 2, 3..., 10, 20, 30, и т.п. Такие числа обычно используются как идентификаторы записи в таблицах, имеющих суррогатный (абстрактный) первичный ключ. Например, в таблице клиентов для их нумерации введен столбец CLIENT_ID INTEGER, по которому построен первичный ключ. Столбец можно заполнять значениями генератора.

Нужно сразу заметить, что сами по себе генераторы не обеспечивают сохранение последовательности номеров в случае удаления записей - генератор всего лишь выдает числа по очереди увеличивая их на некоторую величину и обеспечивая уникальность выданных значений. То есть, генератор выглядит как переменная типа integer (в первом диалекте, или int64 в третьем диалекте), которая находится в памяти, и над которой можно выполнять операции Inc и Dec. Если вам требуется обеспечить непрерывные последовательности идентификаторов записей даже в случае их удаления или модификации, то вам нужно обратиться к статье Auditable series of numbers (непрерывные последовательности чисел). В любом случае это задача приложения и сервера, и выходит за рамки данного описания.

Использование триггеров

Триггер представляет собой процедуру, которая находится на сервере БД и вызывается автоматически при модификации записей БД, т. е. при изменении столбцов или при их удалении и добавлении. В отличие от хранимых процедур, триггеры нельзя вызывать из приложения клиента, а также передавать им параметры и получать от них результаты.
Триггер цо своей сути похож на обработчики событий BeforeEdit, AfterEdit, Beforelnsert, Afterlnsert, BeforeDelete и AfterDelete, связанных с модификацией таблиц. Триггер может вызываться при редактировании, добавлении или удалении записей до и/или после этих событий.

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

«Ссылочная целостность в реляционной базе данных – это согласованность между связанными таблицами. Ссылочная целостность обычно поддерживается путем комбинирования первичного ключа и внешнего ключа. Для соблюдения ссылочной целостности требуется, чтобы любое поле в таблице, объявленное внешним ключом, могло содержать только значения из поля первичного ключа родительской таблицы …» [5]
«[Ссылочная целостность – это] свойство, обеспечиваемое реляционными системами управления базами данных (РСУБД), которое предотвращает ввод несогласованных данных пользователями или приложениями. В большинстве РСУБД имеются различные правила ссылочной целостности, которые можно применить при создании связи между двумя таблицами.» [6]
«[Ссылочная целостность – это] предохранительное устройство системы управления базами данных, гарантирующее, что каждый внешний ключ соответствует первичному ключу. Например, номера заказчиков являются первичными ключами в файле заказчиков и внешними ключами в файле заказов. При удалении записи заказчика должны быть удалены соответствующие записи заказов; в противном случае они останутся без исходной связи. Если СУБД не проверяет этого, соответствующий механизм должен программироваться в приложении.» [7]

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

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

Методические основы проектирования серверной части приложения

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

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

Концептуальное проектирование базы данных включает в себя следующие этапы:
1)Создание локальной концептуальной модели данных.
2)Определение типов сущностей.
3)Определение атрибутов.
4)Определение типов связей.
5)Проверка модели на избыточность.
6)Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.
7)Обсуждение локальных концептуальных моделей данных с конечными пользователями.
8)Создание локальной концептуальной модели данных. Целью данного этапа является определение предметной области и состава пользователей разрабатываемой базы данных.

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

Логическое проектирование базы данных (для реляционной модели) включает в себя следующие этапы.
1)Создание и проверка локальной логической модели данных на основе представления предметной области каждого из типов пользователей
2)Устранение особенностей локальной логической модели, несовместимых с реляционной моделью (необязательный этап).
3)Определение набора отношений исходя из структуры локаль ной логической модели данных.
4)Проверка отношений с помощью правил нормализации таб лиц.
5)Проверка соответствия отношений требованиям пользова тельских транзакций.
6)Определение требований поддержки целостности данных.
7)Обсуждение разработанных локальных логических моделей данных с конечными пользователями.
8)Создание и проверка глобальной логической модели данных.
9)Слияние локальных логических моделей данных в единую глобальную модель данных.
10)Проверка глобальной логической модели данных.
11)Проверка возможностей расширения модели в будущем
12)Обсуждение глобальной логической модели данных с пользователями.

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

Физическое проектирование базы данных (для реляционной модели) включает в себя следующие этапы.
1)Перенос глобальной логической модели данных в среду целевой СУБД.
2)Проектирование базовых отношений в среде целевой СУБД.
3)Проектирование отношений, содержащих производные данные.
4)Реализация ограничений предметной области.
5)Проектирование физического представления базы данных.
6)Анализ транзакций.
7)Выбор файловой структуры.
8)Определение индексов.
9)Определение требований к дисковой памяти.
10)Разработка пользовательских представлений.
11)Разработка механизмов защиты.
12)Анализ необходимости введения контролируемой избыточности.
13)Организация мониторинга и настройка функционирования операционной системы.

Введение

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

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

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

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

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

Задачи курсовой работы состоят в следующем:

- реализовать базу данных;

- реализовать пользовательский интерфейс;

- составить отчеты;

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

1.Постановка задачи

Разработанная база дынных состоит из нескольких “уровней”. Самый абстрактный “уровень” это схема данных. На этом уровне непосредственно отображены связи между таблицами.

В данной курсовой работе поставлены задачи:

- Построение физической модели на компьютере (при помощи Erwin);

- Определение связей, типов данных;

- Разработка удобного пользовательского интерфейса;

- Создание запросов, форм;

- Создание отчетов (по заданию);

- Построение главной кнопочной формы;

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

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

- учет товаров;

- учет товара по группам;

- учет товаров по чекам;

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

2. Проектирование, создание и управление Базой Данных

В базе данных реализовано 4 таблицы.

1)Таблица Группа товара, содержит 2 столбца Номер группы товара и Название группы товара.

2) Таблица Товар, содержит 4 столбца Номер_товара, Название товара, Цена, Номер группы товара.

3) Таблица чек, содержит 2 столбца: Номер_чека, Дата.

4) Таблица Товар по чеку, содержит 3 столбца: Номер товара, Номер чека. Количество.

Для удобства работы с базой данных было создано несколько форм.

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

Формы для запросов.

1)Форма для запроса1(см. Рис. 1)

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

Рис. 1 Форма для запроса1

Например. Вводим в textBox номер чека – 7, и нажимаем на кнопку – Просмотр отчета.(см. Рис. 2)

Рис. 2 Работа отчета1

2)Форма для запроса2

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

Рис. 3 Форма для запроса2

Например. Вводим в textBox дату – 12.11.08 и нажимаем на кнопку – Просмотр отчета. (см. Рис4)

Рис. 4 Работа запроса2

Организация введения данных в таблицы происходит через соответствующие формы. Для удобства была создана главная кнопочная форма. (см. Рис. 5)

Эта форма выглядит так:

Рис. 5 Кнопочная форма

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

В подменю Таблицы в удобной форме представлены таблицы для ввода информации.

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

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

Схема данных была создана при помощи программы Erwin.

3. Технологическая инструкция пользователя

Например:

- Вводим новый товар.

Для того чтобы ввести новый товар необходимо выполнить следующие действия(см. Рис. 7):

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

Рис. 7 Ввод нового сотрудника

Если в списке групп товаров нужной группы не то вводим её в ручную

Нажимаем кнопку Группа товара -> и вводим новую группу товара. (см. Рис 8)

Рис 8. Создание новой группы товара.

Далее нажимаем кнопку Чек -> и вводим дату внесения нового товара, в свою очередь номер чека вводится автоматически. (см. Рис 9)

Рис 9. Ввод даты.

Далее нажимаем кнопку Товар по чеку -> выбираем из списка наш товар

-> выбирает также номер чека по которому проходит данный товар -> вводим количество этого товара. (см. Рис 10)

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

В обязанности администратора могут входить:

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

Кроме того, администратор должен контролировать рост базы данных. От него требуется держать руководство в курсе относительно предполагаемого роста БД, с тем, чтобы иметь возможность своевременно заказать любое необходимое оборудование. [3,12]

1.2 Классификация администраторов баз данных

Существует несколько видов администраторов БД, а их обязанности вполне могут отличаться от компании к компании.[4] Вот типовые характеристики различных типов администраторов баз данных (АБД) и занимаемых ими положений:

Оперативные (operational) АБД:

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

Тактические (tactical) АБД:

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

Стратегические (strategic) АБД:

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

Старшие (senior) АБД:

досконально знают свой персонал;
подготавливают младших АБД;

Младшие (junior) АБД:

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

Прикладные (application) АБД:

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

Системные (system) АБД:

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

Наемные (contract) АБД :

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

Администраторы-руководители :

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

Потребности администратора зависят от его обязанностей и квалификации.

26 хз

1. Страхование на 201314 гг
2. Физические и динамические свойства астероидных семейств
3. Романтизм в детской литературе
4. ДРЕВНЕЙШИЕ СОБИРАТЕЛИ И ОХОТНИКИ 1
5. Третья культура в Древней Руси
6. зависимые компоненты ОС Переносимость операционной системы Микроядерная архитектура Концепция Пр
7. Принципы структуризации и проектирования сетей Ethernet
8. реферат дисертації на здобуття наукового ступеня доктора технічних наук
9. Лабораторная работа- Дифференцирующие и интегрирующие цепи
10. х гг. XIII в. и впоследствии неоднократно перерабатывалась
11. Оцінка стану менеджменту в організації
12. Тема- Маркетингова політика комунікацій МЕТА- Набуття навичок творчого пошуку удосконалення маркетинго
13. ТЕМА 13. РЫНОК ПРИРОДНЫХ РЕСУРСОВ 13
14. Цель работы выявить пути методы и средства совершенствования аналитической работы в КБ Тагилбанк
15. Розрахунок двигуна механізму вильоту стріли
16. Экспериментальное получение электромагнитных волн Существование электромагнитных волн переменного
17. Доклад- Кишечная непроходимость
18. Разработка бизнес-плана по созданию салона красоты для мужчин
19. Информационный критерий оценки фонетической неопределенности
20. Психологические знания в работе учител

Материалы собраны группой SamZan и находятся в свободном доступе