Пользователи банков данных. Преимущества централизованного управления данными. Архитектура банка данных.
Пользователей информационной системы условно можно разделить на две группы: внутренние и конечные.
Пользователями БД являются четыре основные категории потребителей ее информации и/или поставщиков информации для нее: (1) конечные пользователи, (2) программисты и системные аналитики, (3) персонал поддержки БД в актуальном состоянии и (4) администратор БД. Хорошо спроектированные системы управления БД (СУБД), используют развитые графические интерфейсы и поддерживают системы отчетов, отвечающие специфике пользователей указанных четырех категорий. В этом случае персонал поддержки БД и конечные пользователи могут легко осваивать и использовать СУБД для обеспечения своих потребностей без какой-либо специальной подготовки, т.е. специфика функционирования данных систем скрыта от пользователя. Более того, хорошо спроектированные СУБД предоставляют опытному пользователю средства для создания собственных БД-приложений, не требуя от него специальной программистской подготовки. Конечным пользователям для обеспечения доступа к информации БД предоставляется графический интерфейс, как правило, в виде системы окон с функциональными меню, позволяющими легко получать необходимую информацию на экран и/или принтер в виде удобно оформленных отчетов.
Программисты и системные аналитики используют СУБД совершенно в ином качестве, обеспечивая разработку новых БД-приложений, поддерживая и модифицируя (при необходимости) уже существующие. Для данной группы пользователей СУБД требуются средства, обеспечивающие указанные функции (создание, отладка, редактирование и т.д.). Пользователи третьей категории нуждаются в интерфейсе, как правило, графическом для обеспечения задач поддержания БД в актуальном состоянии. Эти пользователи состоят в штатах подразделений функциональных и/или обработки информации, обеспечивающих прикладную область, и отвечают за актуальное состояние соответствующей ей БД (контроль текущего состояния, удаление устаревшей информации, добавление новой и т.д.). Программисты выполняют своего рода посреднические функции между БД и конечными пользователями. И если на первых этапах развития БД-технологии они составляли весьма многочисленную группу пользователей, то в процессе развития СУБД и прежде всего массового использования ПК эта категория сходит на нет. Особую и ответственную роль выполняет администратор, отвечающий как за актуальность находящейся в БД информации, так и за корректность функционирования и использования БД и СУБД.
В случае больших БД может быть достаточно много конечных пользователей, ряд программистов и несколько администраторов БД; в случае небольших БД (что особенно характерно для ПК) все эти функции могут обеспечиваться одним человеком. Важные функции выполняет администратор БД, отвечающий за выработку требований к БД, ее проектирование, реализацию, эффективное использование и сопровождение. Необходимость в таком специалисте вытекает из принципа независимости данных, а также диктуется важностью БД в деятельности организаций и более крупных объединений - поставщиков и потребителей информации БД. Администратор БД взаимодействует с пользователями в определении требований к базе в процессе выработки требований к системе в целом, пользуется языком описания данных для определения БД в процессе проектирования системы, взаимодействует с программистами, которые создают П0, использующее доступ к БД, отвечает за загрузку БД информацией в процессе реализации системы, контролирует работоспособность БД, используя соответствующие программные и аппаратные средства, и определяет, когда следует реорганизовывать данные в базе или начать работы по созданию новой, более совершенной БД. В целом, функции администратора БД сводятся к поддержанию целостности БД, необходимого уровня защиты ее данных и эффективности. Среди его наиболее важных обязанностей - согласование конфликтующих требований, которое требуется достаточно часто, ибо БД обслуживает, как правило, целый ряд различных прикладных процессов.
Внутренние пользователи разрабатывают информационную систему и поддерживают ее функционирование.
К группе внутренних пользователей можно отнести: администраторов баз данных, администраторов функциональных систем (подсистем), системных и прикладных программистов.
Конечные пользователи – это пользователи, обращающиеся к информационной системе или посреднику за получением необходимой информации, те пользователи, ради которых, собственно, и создается информационная система.
Конечные пользователи могут быть косвенными и прямыми. Косвенные конечные пользователи не общаются с информационной системой непосредственно. Они формулируют свои запросы службе администратора базы данных, а затем получают ответы на бумаге, которые перед тем, как их передать заказчику, интерпретируются специалистами.
Прямые конечные пользователи общаются с информационной системой в интерактивном режиме . Часть из них умеет обращаться к заранее составленными приложениями и интерпретировать ответы информационной системы. Другие умеют самостоятельно разрабатывать новые приложения.
Современные тенденции развития систем управления базами данных состоят в развитии языковых и программных средств, ориентированных на конечных пользователей, которые готовы разрабатывать самостоятельно новые приложения, не прибегая к услугам профессиональных программистов.
АРХИТЕКТУРА БнД.
СУБД реализует отображение (прямое и обратное):
Модель <- > хранимая БД
В описании отображения, кроме указания соответствий между полями записей модели и полями хранимых записей, указываются все необходимые сведения о хранимых д.: в каком коде они представлены, как они упорядочены, какие существуют индексы, где расположены те или иные д., с какими данными они связаны, какие методы доступа необходимо использовать для манипулирования хранимыми д. и т.п.
Часть задач обработки д. целесообразно возложить на ОС, используя ее программы методов доступа. Т.о. обеспечивается относительная независимость операций хранения д от используемых технических средств. Т.е. вводится понятие внутренней модели БД:
Модель ---- Внутренняя модель ---- физическая БД
При проектировании СУБД разрабатываются собственные методы доступа к хранимым записям (внутренней модели), базирующиеся на методах доступа ОС. Во внутренней модели БД должна быть представлена в виде совокупности хранимых файлов, для которых известна структура хранимых записей, определены служебные поля, реализующие необходимые связи между записями, известны методы доступа СУБД к этим записям и т.д. В состав СУБД включаются средства преобразования хранимых записей к виду физического представления на машинном носителе и обратно.
На рис.1. представлена архитектура БнД.
Рис. 1.
Пользователи составляют свои ПП, используя только термины модели данных (МД). СУБД, получив запрос из ПП, организует запрос (на считывание, напр., из физической БД необходимой порции д. с носителя в буфер) к ОС. Т.о. в буферной памяти СУБД окажутся хранимые записи, имеющие структуру в соответствии со схемой ВнМД.
Затем выполняется требуемое отображение хранимых записей в записи модели, а затем передача их в РО ПП, которая их затребовала.
Эта схема решает вопрос независимости ПП от д., однако требует знания модели д. пользователем, что не всегда оправдано. Следовательно, необходимо внешнее представление д. Логическое представление в МД является “синхронизирующим”, сама модель - концептуальной моделью.
Между внешней и концептуальной моделями также должно быть реальзовано отображение.
При таком подходе на внешнием уровне поддерживаются органиченные модели ПО, видимые отдельными приложениями (пользователями). На концептуальном уровне поддерживается модель ПО для всех приложений. Уровень хранимых данных - внутренний уровень. Такая архитектура БнД придает ему способность к адаптации к возможным изменениям как в ПП, так и в самих д. в силу независимости схем ВнС, КС, ВС. КС - стабильная и нечувствительная к изменениям во ВнС и ВС.
Централизация и децентрализация процессов обработки данных.
Централизация процессов обработки д. позволяет устранить такие надостатки как несвязанность, противоречивость и избыточность д. в ИС, обеспечивает возможность стандартизиции представления д., санкционированного доступа и т.п. Однако по мере роста БД, использование их в территориально разнесенных организациях приводит к тому, что централизованная СУБД плохо справляется с ростом числа обрабатываемых транзакций. Это приводит к снижению общей надежности и производительности системы при обработке запросов пользователей.
Децентрализация процессов обработки д. в ИС позволяет повысить общую производительность системы вследствие распределения нагрузки по нескольким узлам обработки (хотя и за счет снижения требований к целостности и противоречивости д. и их безопасности).
+ Доводы в пользу распределения обработки:
используются в одном периферийном подразделении (в основном);
выгодно хранить д. и обрабатывать на местах возникновения;
большое число операций поиска и манипулирования со вторичными ключами.
+Доводы в пользу централизации д.:
используются централизованными приложениями;
д., возникающие в различных подразделениях, рассматриваются системой как одно целое (логически);
большой объем д. общего назначения;
защита д.;
пользователи могут перемещаться.
В одной и той же системе одни д. могут быть централизованными, другие - децентрализованными. Основная задача при проектировании распределенной БД - распределение д. по сети.