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

ВВЕДЕНИЕ

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

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

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

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

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

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



1. ПОНЯТИЕ БАНКА ДАННЫХ

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

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

1.1 Требования к БнД:

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

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

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

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

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

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

1.2 Компоненты банка данных

БнД является сложной человеко-машинной системой, включающей в свой состав различные взаимосвязанные и взаимозависимые компоненты, а именно:

· информационная компонента;

· программные средства;

· языковые средства;

· технические средства;

· организационно-методические средства;

· администраторы БнД.

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

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

В качестве технических средств для БнД используется ЭВМ.

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

Функционирование БнД невозможно без администраторов БнД - специалистов, обеспечивающих создание, функционирование и развитие БнД.

1.3 Классификация банков данных

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

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

· иерархическую;

· сетевую;

· реляционную.

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

· постреляционная;

· многомерная;

· объектно-ориентированная.

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

Классификация по типу модели распространяется не только на БД, но и на СУБД и БнД в целом.

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

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

Рис. 1.1 Классификация СУБД по числу уровней в архитектуре (пример трехуровневой архитектуры)

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



2. МОДЕЛИ ДАННЫХ

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

Иерархическая структура представляет совокупность элементов, связанных между собой по определенным правилам. Графическим способом представления иерархической структуры является дерево (рис. 2.1).

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

Рис. 2.1 Графическое изображение иерархической структуры

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



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

Рис. 2.2 Пример иерархической структуры

К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения операций над данными.

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

На иерархической модели данных основано сравнительно ограниченное количество СУБД, в числе которых можно назвать зарубежные системы IMS, PC/Focus, Team-Up и Data Edge, а также отечественные системы Ока, ИНЭС и МИРИС.

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

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

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

Недостатком сетевой модели данных являются высокая сложность и жесткость схемы БД, построенной на ее основе.

Рис. 2.3 Графическое изображение сетевой структуры

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

Наиболее известными сетевыми СУБД являются IDMS, db_VistaIII, СЕТЬ, СЕТОР и КОМПАС.

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

Реляционная модель данных была предложена Е.Ф. Коддом, известным исследователем в области баз данных, в 1969 году, когда он был сотрудником фирмы IBM. Впервые основные концепции этой модели были опубликованы в 1970.

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

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

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

1) Каждое значение, содержащееся на пересечении строки и столбца, должно быть атомарным.

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

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

4) Каждое поле имеет уникальное имя.

5) Последовательность полей в таблице несущественна.

6) Последовательность записей в таблице несущественна.

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

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

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

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

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

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

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

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

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

Рис. 2.5 Схема реляционной модели данных

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

Примерами зарубежных реляционных СУБД для ПЭВМ являются: DB2, Paradox, FoxPro, Access, Clarion, Ingres, Oracle.

К отечественным СУБД реляционного типа относятся системы ПАЛЬМА и HyTech.



2.4 Постреляционная модель

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

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

а) Накладные Накладные-товары

N накладной	Покупатель		N накладной	Товар	Количество
0373	8723		0373	Сыр	3
8374	8232		0373	Рыба	2
7364	8723		8374	Лимонад	1
			8374	Сок	6
			8374	Печенье	2
			7364	Йогурт	1

б) Накладные

N накладной	Покупатель	Товар	Количество
0373	8723	Сыр	3
		Рыба	2
8374	8232	Лимонад	1
		Сок	6
		Печенье	2
7364	8723	Йогурт	1

Рис. 2.6 Структуры данных реляционной (а) и постреляционной (б) моделей

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

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

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

Рассмотренная постреляционная модель данных поддерживается СУБД uniVers. К числу других СУБД, основанных на постреляционной модели данных, относятся также системы Bubba и Dasdb.

2.5 Многомерная модель

Многомерный подход к представлению данных появился практически одновременно с реляционным, но интерес к многомерным СУБД стал приобретать массовый характер с середины 90-х годов. Толчком послужила в 1993 году статья Э. Кодда. В ней были сформулированы 12 основных требований к системам класса OLAP (OnLine Analytical Processing - оперативная аналитическая обработка), важнейшие из которых связаны с возможностями концептуального представления и обработки многомерных данных.

В развитии концепций информационных систем можно выделить следующие два направления:

1) системы оперативной (транзакционной) обработки;

2) системы аналитической обработки (системы поддержки принятия решений).

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

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

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

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

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

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

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

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

а) б)

Модель	Месяц	Объем		Модель	Июнь	Июль	Август
Жигули	июнь	12		Жигули	12	24	5
Жигули	июль	24		Москвич	2	18	No
Жигули	август	5		Волга	No	19	No
Москвич	июнь	2
Москвич	июль	18
Волга	июль	19

Рис. 2.7 Реляционное (а) и многомерное (б) представление данных

Основные понятия многомерных моделей данных: измерение и ячейка.

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

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

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

информационный автоматизированный база банк данный



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

Рис. 2.8 Пример трехмерной модели

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

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

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

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

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

Примерами систем, поддерживающими многомерные модели данных, является Essbase, Media Multi-matrix, Oracle Express Server, Cache. Существуют программные продукты, например Media/MR, позволяющие одновременно работать с многомерными и с реляционными БД.

2.6 Объектно-ориентированная модель

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

Стандартизированная объектно-ориентированная модель описана в рекомендациях стандарта ODMG-93 (Object Database Management Group - группа управления объектно-ориентированными базами данных).

Рассмотрим упрощенную модель объектно-ориентированной БД. Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом или типом, конструируемым пользователем (определяется как class). Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов. Пример логической структуры объектно-ориентированной БД библиотечного дела приведен на рис. 2.9. Здесь объект типа Библиотека является родительским для объектов-экземпляров классов Абонент, Каталог и Выдача. Различные объекты типа Книга могут иметь одного или разных родителей. Объекты типа Книга, имеющие одного и того же родителя, должны различаться, по крайней мере, инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn, удк, название и автор.

Логическая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД. Основное различие между ними состоит в методах манипулирования данными.

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

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

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа Книга, являющимся потомками объекта типа Каталог, можно приписать свойства объекта-родителя: isbn, удк, название и автор. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств билет и номер в объекте Библиотека приводит к наследованию этих свойств всеми дочерними объектами Абонент, Книга и Выдача. Не случайно поэтому значения свойства билет классов Абонент и Выдача, показанных на рис. 2.9, являются одинаковыми - 00015.

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

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

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

Рис. 2.9 Логическая структура БД библиотечного дела

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

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

К объектно-ориентированным СУБД относятся POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.

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

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

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

Другие виды классификации связаны с отдельными компонентами БнД.

1. Разработка банков данных состоит из 4-х этапов:

1этап. Формирование и анализ требований к системе:

- составляется спецификация системы, включающая список задач, которые должен решать БнД;

- перечень конечных пользователей и их функций;

- перечень требований к БД;

- составляется схема документооборота в организации.

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

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

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

2. Основные задачи, решаемые персоналом банка данных

В состав персонала БнД входят разные специалисты: администраторы БнД, системные аналитики, системные и прикладные программисты, операторы, специалисты по техническим средствам, по маркетингу и др.

Перечислим основные функции и задачи, решаемые персоналом при разработке и эксплуатации базы данных:

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

2) проектирование структуры базы данных (определение состава и структуры файлов БД, описание ее схемы на языке описания данных);

3) задание ограничений целостности БД;

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

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

6) обеспечение восстановления БД;

7) анализ эффективности БнД и развитие системы;

8) работа с пользователями (сбор откликов, обучение);

9) сопровождение системного программного обеспечения (приобретение, установка и развитие);

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

3. Пользователи банков данных

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

- Проектирование,

- Реализация,

- Поддержка,

- Обновление и разработка,

- Полная реорганизация.

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

Определим основные категории потребителей и их роли в функционировании банка данных:

Конечные пользователи

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

Администраторы банка данных

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

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

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

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

Рассмотрим их более детально.

Часть группы администратора БнД должна быть:

- Системные комментаторы;

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

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

- Системные и прикладные программисты;

- Действующие компании и эксперты в ремонтной службе.

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

Основные функции группы администраторов БД

1. Исследование области данных: описание области данных, укладка текста ограничений целостности, определение состояния (доступность, конфиденциальность) информация, определение потребностей потребителей, определение соответствия "потребители данных", определение височных объемом характеристик обработки данных.

2. Разработка строения БД: определение сочинения и строение файлов БД и связи промежуточный, выбор методов оптимизации данных и методов доступа для информации, описания БД на языке описания данных (ЯОД).

3. Задание ограничений целостности в описании структуры БД и процедурах обработки БД:

- Задание декларативных ограничений целостности, свойственной от области данных;

- Определение динамичных ограничений целостности, свойственной от области данных в ходе изменения информации, хранившей в БД;

- Определение ограничений целостности вызывается строением БД;

- Разработка процедур поддержки целостности БД при вводе и корректировке данных;

- Определение ограничений целостности параллельной работой потребителей в многопользовательском режиме.



4. Инициирование загрузки и руководство БД

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

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

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

5. Предохранение данных

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

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

- Разработка средств фиксации доступа к данным и попыткам нарушения системы защиты;

- Тестирование системы защиты;

- Исследование случаев нарушения системы защиты и разработки динамичных методов предохранения информации в БД.

6. Поддержка восстановления БД

- Разработка организационных означает архивирования и принципы восстановления БД;

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

7. Исследование вызовов потребителей БД: набор статистики на символе запросов, времени включения их производительности, в соответствии с требуемыми выходными документами

8. Исследование эффективности функционирования БнД:

- Исследование индексов функционирования БнД

- Планирующая перестройка структуры (структурное изменение) БД и реорганизация БнД.

9. Работа с конечными пользователями:

- Сбор информации об изменении области данных;

- Сбор информации об оценке работ БнД;

- Тренировка потребителей, консультация потребителей;

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

10. Приготовление и поддержка системных средств:

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

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

- Проверка работоспособности искупленного матобеспечения перед их соединением с БнД;

- Контроль соединения нового матобеспечения к БнД.

11. Организационно-систематическая работа при разработке БнД:

- Выбор или создание метода разработки БД;

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

- Планирование стадий развития БнД;

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

- Монтаж внешних моделей разработанных приложений;

- Контроль соединения нового приложения к работе БнД;

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



ЗАКЛЮЧЕНИЕ

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

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

Итак, основа банка - база данных

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

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

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

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

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

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

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



СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Дейт К.Дж. Введение в системы баз данных.8-е изд. [Текст] / - М., Вильямс, 2007-1328 с. - ISBN 978-5-699-38683-3

2. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. [Текст] / - М., Вильямс, 2008 - 1440 с. - ISBN 5-8459-0881-7

3. Марков А.С., Лисовский К.Ю. Базы данных. Введение в теорию и методологию. [Текст] / - М., Финансы и статистика, 2009- 512 с. - ISBN 5-94157-374

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