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

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

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

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

системные аналитики;

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

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

операторы и специалисты по техническому обслуживанию.

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

• — описание предметной области,
• — выявление ограничений целостности,

— определение статуса (доступности, секретности) информации,.

— определение потребностей пользователей, определение соответствия «данные — пользователь»,.

— определение объемно.

• -временных характеристик обработки данных.
• 2. Проектирование структуры БД:
  • — определение состава и структуры файлов БД и связей между ними,
  • — выбор методов упорядочения данных и методов доступа к информации, описание БД на языке описания данных (ЯОД).
• 3. Задание ограничений целостности при описании структуры БД и процедур обработки БД:
  • — задание декларативных ограничений целостности, присущих предметной области;
  • — определение динамических ограничений целостности, присущих предметной области в процессе изменения информации, хранящейся в БД;

— определение ограничений целостности, вызванных структурой БД;

• — разработка процедур обеспечения целостности БД при вводе и корректировке данных; - определение ограничений целостности при параллельной работе пользователей в многопользовательском режиме.
• 4. Первоначальная загрузка и ведение БД:

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

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

• — в соответствии с разработанной технологией первоначальной загрузки может понадобиться проектирование системы первоначального ввода данных.
• 5. Защита данных:

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

• — разработка принципов защиты конкретных данных и объектов проектирования; разработка специализированных методов кодирования информации при ее циркуляции в локальной и глобальной информационных сетях;
• — разработка средств фиксации доступа к данным и попыток нарушения системы защиты;
• — тестирование системы защиты; - исследование случаев нарушения системы защиты и развитие динамических методов защиты информации в БД.
• 6. Обеспечение восстановления БД:

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

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

• 7. Анализ обращений пользователей БД:
  • — сбор статистики по характеру запросов, по времени их выполнения, по требуемым выходным документам
• 8. Анализ эффективности функционирования БД:

— анализ показателей функционирования БД;

• — планирование реструктуризации (изменение структуры) БД и реорганизации БнД.
• 9. Работа с конечными пользователями:

— сбор информации об изменении предметной области; - сбор информации об оценке работы БД;

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

— курирование подключения новых программных средств к БД.

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

— выбор или создание методики проектирования БД;

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

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

Одними из основополагающих в концепции баз данных являются обобщенные категории «данные» и «модель данных», параметров, характеризующих объект, условие, ситуацию или любые другие факторы. Примеры данных: Петров Николай Степанович, $ 30 и т. д. Данные не обладают определенной структурой, данные становятся информацией тогда, когда пользователь задает им определенную структуру, то есть осознает их смысловое содержание. Поэтому центральным понятием в области баз данных является понятие модели. Не существует однозначного определения этого термина, у разных авторов эта абстракция определяется с некоторыми различиями, но тем не менее можно выделить нечто общее в этих определениях. Модель данных — это некоторая абстракция, которая, будучи приложима к конкретным данным, позволяет пользователям и разработчикам трактовать их уже как информацию, то есть сведения, содержащие не только данные, но и взаимосвязь между ними. Понятие «данные» в концепции баз данных — это набор конкретных значений.

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

Модели, основанные на языках разметки документов, связаны прежде всего со стандартным общим языком разметки — SGML (Standart Generalised Markup Language), который был утвержден ISO в качестве стандарта еще в 80-х годах. Этот язык предназначен для создания других языков разметки, он определяет допустимый набор тегов (ссылок), их атрибуты и внутреннюю структуру документа. Контроль за правильностью использования тегов осуществляется при помощи специального набора правил, называемых DTD-описаниями, которые используются программой клиента при разборе документа. Для каждого класса документов определяется свой набор правил, описывающих грамматику соответствующего языка разметки. С помощью SGML можно описывать структурированные данные, организовывать информацию, содержащуюся в документах, представлять эту информацию в некотором стандартизованном формате. Но ввиду некоторой своей сложности SGML использовался в основном для описания синтаксиса других языков (наиболее известным из которых является HTML), и немногие приложения работали с SGML-документами напрямую. Гораздо более простой и удобный, чем SGML, язык HTML позволяет определять оформление элементов документа и имеет некий ограниченный набор инструкций — тегов, при помощи которых осуществляется процесс разметки. Инструкции HTML в первую очередь предназначены для управления процессом вывода содержимого документа на экране программы-клиента и определяют этим самым способ представления документа, но не его структуру. В качестве элемента гипертекстовой базы данных, описываемой HTML, используется текстовый файл, который может легко передаваться по сети с использованием протокола HTTP. Эта особенность, а также то, что HTML является открытым стандартом и огромное количество пользователей имеет возможность применять возможности этого языка для оформления своих документов, безусловно, повлияли на рост популярности HTML и сделали его сегодня главным механизмом представления информации в Интернете.

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

2. Иерархическая модель данных.

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

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

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

Стандарт сетевой модели впервые был определен в 1975 году организацией CODASYL (Conference of Data System Languages), которая определила базовые понятия модели и формальный язык описания. Сетевая модель позволяет отображать разнообразные взаимосвязи элементов данных в виде произвольного графа: Базовыми объектами модели являются:

элемент данных;

агрегат данных;

запись;

набор данных;

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

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

4. Реляционная модель данных основные понятия.

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

Элементы РМД и формы их представления:

ОтношенияТаблица.

Схема отношенияСтрока заголовков столбцов таблицы.

КортежСтрока таблицы.

СущностьОписание свойств объекта.

АтрибутЗаголовок столбца таблицы.

ДоменМножество допустимых значений атрибута.

Значение атрибутаЗначение поля в записи.

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

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

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

Домен — множество всех возможных значений определенного атрибута отношения. Каждый домен образует значение одного типа данных, н-р, численных или символьных. Если значения атрибутов берутся из одного и того же домена, то имеет смысл сравнения. Схема отношения (заголовок) представляет собой список имён атрибутов. Множество кортежей отношения часто называют содержимым или телом. Степень отношения — это число его атрибутов. Кардинальное число или мощность — число кортежей. Схемы двух отношений называются эквивалентными, если они имеют одинаковую степень и возможно такое упорядочение имен атрибутов в схемах, что на одинаковых местах будут находиться сравнимые атрибуты, то есть атрибуты, принимающие значения из одного домена.