Студентам > Рефераты > Курс лекций по Проектированию баз и хранилищ данных
Курс лекций по Проектированию баз и хранилищ данныхСтраница: 3/5
§ Администраторы банка данных. Это группа пользователей, которая
на начальной стадии разработки банка данных отвечает за его оптимальную
организацию с точки зрения одновременной работы множества конечных
пользователей, на стадии эксплуатации отвечает за корректность работы данного
банка информации и многопользовательском режиме. На стадии развития и реорганизации
эта группа пользователей отвечает за возможность корректной реорганизации банка
без изменения или прекращения его текущей эксплуатации.
§ Разработчики и администраторы приложений. Это группа пользователей,
которая функционирует во время проектирования, создания и реорганизации банка
данных. Администраторы приложений координируют работу разработчиков при
разработке конкретного приложения или группы приложений, объединенных в
функциональную подсистему. Разработчики конкретных приложений работают с той частью
информации из базы данных, которая требуется для конкретного приложения.
Не в каждом банке данных могут быть выделены все тины пользователей.
Мы уже знаем, что при разработке информационных систем с использованием
настольных СУБД администратор банка данных, администратор приложении и
разработчик часто существовали в одном лице. Однако при построении современных
сложных корпоративных баз данных, которые используются для автоматизации всех
или большей части бизнес-процессов в крупной фирме или корпорации, могут
существовать и группы администраторов приложений, и отделы разработчиков. Наиболее
сложные обязанности возложены на группу администратора БД.
Рассмотрим их более подробно. В составе группы администратора
БД должны быть:
· системные аналитики;
· проектировщики структур данных и внешнего по отношению к банку
данных информационного обеспечения;
· проектировщики технологических процессов обработки данных;
· системные и прикладные программисты:
· операторы и специалисты по техническому обслуживанию.
Если речь идет о коммерческом банке данных, то важную роль
здесь играют специалисты по маркетингу.
Основные функции группы администратора БД
1. Анализ
предметной области: описание предметной области, выявление ограничений
целостности, определение статуса (доступности, секретности) информации,
определение потребностей пользователей, определение соответствия «данные -
пользователь», определение объемно-временных характеристик обработки данных.
2. Проектирование
структуры БД: определение состава и структуры файлов БД и связей между
ними, выбор методов упорядочения данных и методов доступа к информации, описание
БД на языке описания данных (ЯОД).
3. Задание ограничений целостности при описании структуры БД и
процедур обработки БД:
§ задание декларативных ограничений целостности, присущих
предметной области;
§ определение динамических ограничений целостности, присущих
предметной области в процессе изменения информации, хранящейся в БД;
§ определение ограничений целостности, вызванных структурой БД;
§ разработка процедур обеспечения целостности БД при вводе и
корректировке данных;
§ определение ограничений целостности при параллельной работе
пользователей в многопользовательском режиме.
4. Первоначальная загрузка и ведение БД:
§ разработка технологии первоначальной загрузки БД, которая будет
отличаться от процедуры модификации и дополнения данными при штатном
использовании базы данных;
§ разработка технологии проверки соответствия введенных данных
реальному состоянию предметной области. База данных моделирует реальные объекты
некоторой предметной области и взаимосвязи между ними, и на момент начала
штатной эксплуатации эта модель должна полностью соответствовать состоянию
объектов предметной области на данный момент времени;
§ в соответствии с разработанной технологией первоначальной
загрузки может понадобиться проектирование системы первоначального ввода
данных.
5. Защита данных:
§ определение системы паролей, принципов регистрации пользователей,
создание групп пользователей, обладающих одинаковыми правами доступа к данным;
§ разработка принципов защиты конкретных данных и объектов
проектирования;
§ разработка специализированных методов кодирования информации при
ее циркуляции в локальной и глобальной информационных сетях;
§ разработка средств фиксации доступа к данным и попыток нарушения
системы зашиты;
§ тестирование системы защиты;
§ исследование случаев нарушения системы защиты и развитие
динамических методов защиты информации в БД.
6. Обеспечение восстановления БД:
§ разработка организационных средств архивирования и принципов
восстановления БД;
§ разработка дополнительных программных средств и технологических
процессов восстановления БД после сбоев.
7. Анализ
обращений пользователей БД: сбор статистики по характеру запросов, по
времени их выполнения, по требуемым выходным документам
8. Анализ эффективности функционирования БД:
§ анализ показателей функционирования БД;
§ планирование реструктуризации (изменение структуры) БД и
реорганизации БнД.
9. Работа с конечными пользователями:
§ сбор информации об изменении предметной области;
§ сбор информации об оценке работы БД;
§ обучение пользователей, консультирование пользователей;
§ разработка необходимой методической и учебной документации по
работе конечных пользователей.
10. Подготовка
и поддержание системных средств:
§ анализ существующих на рынке программных средств и анализ
возможности и необходимости их использования в рамках БД;
§ разработка требуемых организационных и программно-технических
мероприятий по развитию БД;
§ проверка работоспособности закупаемых программных средств перед
подключением их к БД;
§ курирование подключения новых программных средств к БД.
11. Организационно-методическая
работа по проектированию БД:
§ выбор или создание методики проектирования БД;
§ определение целей и направления развития системы в целом;
§ планирование этапов развития БД;
§ разработка общих словарей-справочников проекта БД и концептуальной
модели;
§ стыковка внешних моделей разрабатываемых приложений;
§ курирование подключения нового приложения к действующей БД;
§ обеспечение возможности комплексной отладки множества приложений,
взаимодействующих с одной БД.
Архитектура базы данных. Физическая и логическая независимость
Терминология в СУБД, да и сами термины «база данных» и «банк
данных» частично заимствованы из финансовой деятельности. Это заимствование —
не случайно и объясняется тем, что работа с информацией и pa6oтa с денежными
массами во многом схожи, поскольку и там и там отсутствует персонификация
объекта обработки: две банкноты достоинством в сто рублей столь же неотличимы и
взаимозаменяемы, как два одинаковых байта (естественно, за исключением серийных
номеров). Вы можете положить деньги на некоторый счет и предоставить возможность
вашим родственникам или коллегам использовать их для иных целей. Вы можете
поручить банку оплачивать ваши расходы с вашего счета или получить их наличными
о другом банке, и это будут уже другие денежные купюры, но их ценность будет
эквивалентна той, которую вы имели, когда клали их на ваш счет.
В процессе научных исследований, посвященных тому, как именно
должна быть устроена СУБД, предлагались различные способы реализации. Самым
жизнеспособным из них оказалась предложенная американским комитетом по
стандартизации ANSI (American National Standards Institute) трехуровневая система
организации БД, изображенная на рис. 2.1:
Рис.
2.1. Трехуровневая модель системы управления базой данных, предложенная ANSI
1. Уровень
внешних моделей — самый верхний уровень, где каждая модель имеет свое
«видение» данных. Этот уровень определяет точку зрения на БД отдельных
приложений. Каждое приложение видит и обрабатывает только те данные, которые
необходимы именно этому приложению. Например, система распределения работ
использует сведения о квалификации сотрудника, но ее не интересуют сведения об
окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения
используются в подсистеме отдела кадров.
2. Концептуальный
уровень — центральное управляющее звено, здесь база данных представлена в
наиболее общем виде, который объединяет данные, используемые всеми приложениями,
работающими с данной базой данных. Фактически концептуальный уровень отражает
обобщенную модель предметной области (объектов реального мира), для которой
создавалась база данных. Как любая модель, концептуальная модель отражает
только существенные, с точки зрения обработки, особенности объектов реального
мира.
3. Физический
уровень — собственно данные, расположенные в файлах или в страничных
структурах, расположенных на внешних носителях информации.
Эта архитектура позволяет обеспечить логическую (между
уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при
работе с данными. Логическая независимость предполагает возможность
изменения одного приложения без корректировки других приложений, работающих с
этой же базой данных. Физическая независимость предполагает возможность
переноса хранимой информации с одних носителей на другие при сохранении
работоспособности всех приложений, работающих с данной базой данных. Это именно
то, чего не хватало при использовании файловых систем. Выделение концептуального
уровня позволило разработать аппарат централизованного управления базой данных.
Классификация банков данных
Банки данных — это очень сложная система, которую можно классифицировать
по целому спектру признаков, касающихся как банка в целом, так и отдельных его
компонентов.
По назначению БнД бывают:
- информационно-поисковые;
- специализированные по отдельным
областям науки и техники;
- банки данных АСУ для
организационно-экономической информации;
- банки данных для систем
автоматизации научных исследований и производственных испытаний;
- банки данных для систем
автоматизированного проектирования.
По архитектуре поддерживаемой вычислительной среды БнД бывают
централизованными (интегрированными) и распределенными.
По виду информации, которая сохраняется, банки делятся
на банки данных, банки документов и банки знаний.
По языку общения пользователя с БД различают системы с
базовым языком (открытые системы) и с собственным языком (закрытые системы).
В открытых системах языковым средством общения с БД один из
языков программирования, например C, Pascal. В таких системах для общения с БД
нужен посредник, то есть программист, который владеет избранным языком программирования.
Закрытые системы имеют собственный язык общения. Он, как правило,
намного проще, чем язык программирования. Поэтому в таких системах не нужен
посредник-программист для общения с БД. Сами пользователи, которые имеют
соответствующую подготовку, смогут работать с БД.
Одними из основополагающих в концепции баз данных являются
обобщенные категории «данные» и «модель данных».
Понятие «данные» в концепции баз данных — это набор конкретных
значений, параметров, характеризующих объект, условие, ситуацию или любые
другие факторы. Примеры данных: Петров Николай Степанович, $30 и т. д. Данные
не обладают определенной структурой, данные становятся информацией тогда, когда
пользователь задает им определенную структуру, то есть, осознает их смысловое
содержание. Поэтому центральным понятием в области баз данных является понятие модели.
Не существует однозначного определения этого термина, у разных авторов эта
абстракция определяется с некоторыми различиями, но, тем не менее, можно
выделить нечто общее в этих определениях-
Модель данных — это некоторая абстракция, которая,
будучи приложима к конкретным данным, позволяет пользователям и разработчикам
трактовать их уже как информацию, то есть сведения, содержащие не только
данные, но и взаимосвязь между ними.
Рис.
2.4. Классификация моделей данных
На рис. 2.4 представлена классификация моделей данных.
В соответствии с рассмотренной ранее трехуровневой архитектурой
мы сталкиваемся с понятием модели данных по отношению к каждому уровню. И
действительно, физическая модель данных оперирует категориями, касающимися
организации внешней памяти и структур хранения, используемых в данной
операционной среде. В настоящий момент в качестве физических моделей используются
различные методы размещения данных, основанные на файловых структурах: это
организация файлов прямого и последовательного доступа, индексных файлов и
инвертированных файлов, файлов, использующих различные методы хеширования,
взаимосвязанных файлов. Кроме того, современные СУБД широко используют
страничную организацию данных. Физические модели данных, основанные на
страничной организации, являются наиболее перспективными.
Наибольший интерес вызывают модели данных, используемые на
концептуальном уровне. По отношению к ним внешние модели называются подсхемами
и используют те же абстрактные категории, что и концептуальные модели данных.
Кроме трех рассмотренных уровней абстракции при проектировании
БД существует еще один уровень, предшествующий им. Модель этого уровня должна
выражать информацию о предметной области в виде, независимом от используемой
СУБД. Эти модели называются инфологическими, или семантическими,
и отражают в естественной и удобной для разработчиков и других пользователей
форме информационно-логический уровень абстрагирования, связанный с фиксацией и
описанием объектов предметной области, их свойств и их взаимосвязей.
Инфологические модели данных используются на ранних стадиях
проектирования для описания структур данных в процессе разработки приложения, а
даталогические модели уже поддерживаются конкретной СУБД.
Документальные модели данных соответствуют
представлению о слабоструктурированной информации, ориентированной в основном
на свободные форматы документов, текстов на естественном языке.
Модели, основанные на языках разметки документов, связаны,
прежде всего, со стандартным общим языком разметки — SGML (Standard Generalized Markup Language),
который был утвержден ISO в качестве стандарта еще в 80-х годах. Этот язык
предназначен для создания других языков разметки, он определяет допустимый
набор тегов (ссылок), их атрибуты и внутреннюю структуру документа. Контроль за
правильностью использования тегов осуществляется при помощи специального набора
правил, называемых DTD-описаниями. которые используются программой клиента при
разборе документа. Для каждого класса документов определяется свой набор
правил, описывающих грамматику соответствующего языка разметки. С помощью SGML
можно описывать структурированные данные, организовывать информацию, содержащуюся
в документах, представлять эту информацию в некотором стандартизованном
формате. Но ввиду некоторой своей сложности SGML использовался в основном для
описания синтаксиса других языков (наиболее известным из которых является
HTML), и немногие приложения работали с SGML-документами напрямую.
Гораздо более простой и удобный, чем SGML, язык HTML позволяет
определять оформление элементов документа и имеет некий ограниченный набор
инструкций — тегов, при помощи которых осуществляется процесс разметки.
Инструкции HTML в первую очередь предназначены для управления процессом вывода
содержимого документа на экране программы-клиента и определяют этим самым
способ представления документа, но не его структуру. В качестве элемента
гипертекстовой базы данных, описываемой HTML. используется текстовый файл, который
может легко передаваться по сети с использованием протокола HTTP. Эта
особенность, а также то, что HTML является открытым стандартом, и огромное
количество пользователей имеет возможность применять возможности этого языка
для оформления своих документов, безусловно, повлияли на рост популярности HTML
и сделали его сегодня главным механизмом представления информации в Internet.
Однако HTML сегодня уже не удовлетворяет в полной мере требованиям,
предъявляемым современными разработчиками к языкам подобного рода. И ему на
смену был предложен новый язык гипертекстовой разметки, мощный, гибкий и,
одновременно с этим, удобный язык XML. В чем же заключаются его достоинства?
XML (Extensible Markup Language)
— это язык разметки, описывающий целый класс объектов данных, называемых
XML-докумснтами. Он используется в качестве средства для описания грамматики
других языков и контроля за правильностью составления документов. То есть сам
по себе XML не содержит никаких тегов, предназначенных для разметки, он просто
определяет порядок их создания.
|
Главная
Документация
Файлы
Информация
