Схема работы с разделом 2
Раздел 2. Архитектура банка данных
Второй раздел курса включает три темы: “Уровни представления баз данных”, “Категории пользователей банков данных” и “Этапы проектирования моделей баз данных”. После изучения каждой темы Вам следует ответить на вопросы для самопроверки.
Работа с разделом 2 завершается сдачей контрольного теста.
Для того, чтобы Вы смогли успешно ответить на вопросы контрольного теста, Вам предоставляется возможность поработать с репетиционным тестом. Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главе 5 учебника [1] или к учебному пособию [7].
2.1. Уровни представления баз данных
При изучении данной темы Вы должны уяснить роль и место банков данных в информационных системах. Уровни представления (отображения) информации в моделях базах данных на основе стандарта ANSI/SPARC. Понятия схемы и подсхемы и особенности архитектуры современных СУБД.
Для проверки изучения материала темы Вам предстоит ответить на вопросы для самопроверки.
Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главе 2 учебника [1] или к учебному пособия [8].
2.1.1. Основная терминология
Современные авторы часто употребляют термины "банк данных" и "база данных" как синонимы, однако в общеотраслевых руководящих материалах по созданию банков данных Государственного комитета по науке и технике (ГКНТ), изданных в 1982 г., эти понятия различаются. Там приводятся следующие определения банка данных, базы данных и СУБД:
Банк данных (БнД) — это система специальным образом организованных данных — баз данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных.
База данных (БД) — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области.
Система управления базами данных (СУБД) — совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.
Модель данных - это средство абстракции, которое интерпретирует информационное содержание данных предметной области, частично представляя семантику данных предметной области, т.е. средство, передающее некоторые знания о реальном мире (предметной области)
Модель данных характеризуется тремя компонентами:
-
Структура данных, предназначенная для представления точки зрения пользователя на БД.
-
Множество допустимых операций, выполняемых в структуре данных, составляющее основу языка данных модели.
-
Ограничения для контроля целостности.
Программы, с помощью которых пользователи работают с БД, называются приложениями. В общем случае с одной БД могут работать множество различных приложений. Например, если БД моделирует некоторое предприятие, то для работы с ней может быть создано приложение, которое обслуживает подсистему учета кадров, другое приложение может быть посвящено работе подсистемы расчета заработной платы сотрудников, третье приложение работает как подсистемы складского учета и т.д. При рассмотрении приложений, работающих с одной БД, предполагается, что они могут работать параллельно и независимо друг от друга, и именно СУБД призвана обеспечить работу множества приложений с единой базой данных таким образом, чтобы каждое из них выполнялось корректно, но учитывало все изменения в БД, вносимые другими приложениями.
В следующей теме на структурном и функциональном уровне раскрывается поняние архитектуры базы данных, как комплекса взаимосвязанных моделей различных уровней представления информации в банках данных.
2.1.2. Архитектура базы данных.
В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БнД, изображенная на рис. 2.1.
Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое "видение" данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Например, подсистема составления расписания занятий использует сведения о квалификации сотрудника и видов работ по конкретной дисциплине, но ее не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используются в подсистеме отдела кадров.
Концептуальный уровень — центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира. В источниках по базам данных понятия схемы и подсхемы связываются с концептуальным и внешним уровнем соответственно.
Рис. 2.1. Трехуровневая модель СУБД, предложенная ANSI\SPARC
Физический уровень — собственно данные, расположенные в файлах или в страничных структурах, расположенных на внешних носителях информации.
Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Реализация принципа независимости данных является центральным в теории и практике баз данных. Это именно то, чего не хватало при использовании файловых систем.
Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.
На каждом уровне присутствует модель данных, которая специфицируется с помощью языка описания соответствующего уровня. Модель каждого уровня, представленную на языке описания, принято называть схемой. Внешнею модель иногда называют подсхемой.
Каждому уровню представления данных соответствует своя одноименная модель данных.
2.1.3. Процесс прохождения пользовательского запроса в СУБД
Рис. 2.2 иллюстрирует взаимодействие пользователя, СУБД и ОС при обработке запроса на получение данных. Под рабочей областью здесь понимается область оперативной памяти ЭВМ, доступная для пользовательского приложения.
Цифрами помечена последовательность взаимодействий.
Пользователь посылает СУБД запрос на получение данных из БД (стрелка 1).
Анализ прав пользователя и внешней модели данных, соответствующей данному пользователю, подтверждает или запрещает доступ данного пользователя к запрошенным данным.
В случае запрета на доступ к данным СУБД сообщает пользователю об этом (стрелка 12) и прекращает дальнейший процесс обработки данных, в противном случае СУБД определяет часть концептуальной модели, которая затрагивается запросом пользователя.
Рис. 2.2. Схема прохождения запроса к БД
СУБД запрашивают информацию о части концептуальной модели.
СУБД получает информацию о запрошенной части концептуальной модели.
СУБД запрашивает информацию о местоположении данных на физическом уровне (с учетом физической организации файлов базы данных).
В СУБД возвращается информация о местоположении данных в терминах операционной системы.
СУБД просит операционную систему предоставить необходимые данные, используя средства операционной системы.
ОС осуществляет перекачку информации из устройств хранения и пересылает ее в системный буфер.
ОС оповещает СУБД об окончании пересылки.
СУБД выбирает из доставленной информации, находящейся в системном буфере, только то, что нужно пользователю, и пересылает эти данные в рабочую область пользователя.
Любая ИС включает базу Метаданных (словарь данных – системные файлы СУБД), именно здесь и хранится вся информация об используемых структурах данных, логической организации данных, правах доступа пользователей и, наконец, физическом расположении данных. Для управления базой Метаданных каждый производитель СУБД предоставляет специальное программное обеспечение администрирования баз данных, которое предназначено для корректного использования единого информационного пространства многими пользователями.
Всегда ли запрос проходит полный цикл? Конечно, нет. СУБД обладает достаточно развитым интеллектом, который позволяет ей не повторять бессмысленных действий. И поэтому, например, если этот же пользователь повторно обратится к СУБД с новым запросом, то для него уже не будут проверяться внешняя модель и права доступа, а если дальнейший анализ запроса покажет, что данные могут находиться в системном буфере, то СУБД осуществит только 11 и 12 шаги в обработке запроса.
Механизм прохождения запроса в реальных СУБД гораздо сложнее, но и эта упрощенная схема показывает, насколько серьезными и сложными должны быть механизмы обработки запросов, поддерживаемые реальными СУБД.
Вопросы для самопроверки по теме 2.1
1. Из каких составляющих складывается понятие банка данных?
2. В качестве чего используются запоминающие устройства с произвольным доступом в БД?
3. Что дает многоуровневая архитектура БнД?
4. Чем определяется скорость исполнения запроса?
5. Что такое внешняя, концептуальная и внутренняя модель данных?
6. Что такое база метаданных? Для каких целей ее применяют и где она хранится?
7. Что такое логическая и физическая независимость данных?
2.2. Категории пользователей банков данных
При изучении данной темы Вы должны уяснить роль администратора БД в автоматизированных информационных системах (АИС). Эффективность АИС определяется не только использованным оборудованием и программным обеспечением, она напрямую зависит от уровней представления информации в моделях базах данных, т.е. от квалификации администратора БД.
Для проверки изучения материала темы Вам предстоит ответить на вопросы для самопроверки.
Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главе 2 учебника [1] или к учебному пособию [8].
2.2.1. Классификация пользователей БнД
Как любой программно-организационно-техничеcкий комплекс, банк данных существует во времени и в пространстве. Он имеет определенные стадии своего развития:
-
Проектирование.
-
Реализация.
-
Эксплуатация.
-
Модернизация и развитие.
-
Полная реорганизация.
На каждом этапе своего существования с банком данных связаны разные категории пользователей.
Определим основные категории пользователей и их роль в функционировании банка данных:
Конечные пользователи. Это основная категория пользователей, в интересах которых и создается банк данных. В зависимости от особенностей создаваемого БнД круг его конечных пользователей может существенно различаться. Это могут быть случайные пользователи, обращающиеся к БД время от времени за получением некоторой информации, а могут быть регулярные пользователи. В качестве случайных пользователей могут рассматриваться, например, возможные клиенты вашей фирмы, просматривающие каталог вашей продукции или услуг с обобщенным или подробным описанием того и другого. Регулярными пользователями могут быть ваши сотрудники, работающие со специально разработанными для них программами, которые обеспечивают автоматизацию их деятельности при выполнении своих должностных обязанностей. Например, менеджер, планирующий работу сервисного отдела компьютерной фирмы, имеет в своем распоряжении программу, которая помогает ему планировать и распределять текущие заказы, контролировать ход их выполнения, заказывать на складе необходимые комплектующие для новых заказов. Главный принцип состоит в том, что от конечных пользователей не должно требоваться каких-либо специальных знаний в области вычислительной техники и языковых средств.
Администраторы банка данных. Это группа пользователей, которая на начальной стадии разработки банка данных отвечает за его оптимальную организацию с точки зрения одновременной работы множества конечных пользователей, на стадии эксплуатации отвечает за корректность работы данного банка информации в многопользовательском режиме. На стадии развития и реорганизации эта группа пользователей отвечает за возможность корректной реорганизации банка без изменения или прекращения его текущей эксплуатации.
Разработчики и администраторы приложений. Это группа пользователей, которая функционирует во время проектирования, создания и реорганизации БнД. Администраторы приложений координируют работу разработчиков при разработке конкретного приложения или группы приложений, объединенных в функциональную подсистему. Разработчики конкретных приложений работают с той частью информации из БД, которая требуется для конкретного приложения.
Не в каждом банке данных могут быть выделены все типы пользователей. Мы уже знаем, что при разработке ИС с использованием настольных СУБД администратор банка данных, администратор приложений и разработчик часто существовали в одном лице. Однако при построении современных сложных корпоративных баз данных, которые используются для автоматизации всех или большей части бизнес-процессов в крупной фирме или корпорации, могут существовать и группы администраторов приложений, и отделы разработчиков. Наиболее сложные обязанности возложены на группу администратора БД.
Рассмотрим их более подробно.
В составе группы администратора БД должны быть:
-
системные аналитики;
-
проектировщики структур данных и внешнего по отношению к банку данных информационного обеспечения;
-
проектировщики технологических процессов обработки данных;
-
системные и прикладные программисты;
-
операторы и специалисты по техническому обслуживанию.
Если речь идет о коммерческом банке данных, то важную роль здесь играют специалисты по маркетингу.
2.2.2. Основные функции группы администратора БД
1. Анализ предметной области: описание предметной области, выявление ограничений целостности, определение статуса (доступности, секретности) информации, определение потребностей пользователей, определение соответствия "данные—пользователь", определение объемно-временных характеристик обработки данных.
2. Проектирование структуры БД: определение состава и структуры файлов БД и связей между ними, выбор методов упорядочения данных и методов доступа к информации, описание БД на языке описания данных (ЯОД).
3. Задание ограничений целостности при описании структуры БД и процедур обработки БД:
- задание декларативных ограничений целостности, присущих предметной области;
- определение динамических ограничений целостности, присущих предметной области в процессе изменения информации, хранящейся в БД;
- определение ограничений целостности, вызванных структурой БД;
- разработка процедур обеспечения целостности БД при вводе и корректировке данных;
- определение ограничений целостности при параллельной работе пользователей в многопользовательском режиме.
4. Первоначальная загрузка и ведение БД:
- разработка технологии первоначальной загрузки БД, которая будет отличаться от процедуры модификации и дополнения данными при штатном использовании базы данных;
- разработка технологии проверки соответствия введенных данных реальному состоянию предметной области. База данных моделирует реальные объекты некоторой предметной области и взаимосвязи между ними, и на момент начала штатной эксплуатации эта модель должна полностью соответствовать состоянию объектов предметной области на данный момент времени;
- в соответствии с разработанной технологией первоначальной загрузки может понадобиться проектирование системы первоначального ввода данных.
5. Защита данных:
- определение системы паролей, принципов регистрации пользователей, создание групп пользователей, обладающих одинаковыми правами доступа к данным;
- разработка принципов защиты конкретных данных и объектов проектирования; разработка специализированных методов кодирования информации при ее циркуляции в локальной и глобальной информационных сетях;
- разработка средств фиксации доступа к данным и попыток нарушения системы защиты;
- тестирование системы защиты;
- исследование случаев нарушения системы защиты и развитие динамических методов защиты информации в БД.
6. Обеспечение восстановления БД:
- разработка организационных средств архивирования и принципов восстановления БД;
- разработка дополнительных программных средств и технологических процессов восстановления БД после сбоев.
7. Анализ эффективности функционирования БД:
- анализ показателей функционирования БД;
- анализ обращений пользователей БД: сбор статистики по характеру запросов, по времени их выполнения, по требуемым выходным документам;
- планирование реструктуризации (изменение структуры физической организации базы данных) БД и реорганизации БнД.
8. Работа с конечными пользователями:
- сбор информации об изменении предметной области;
- сбор информации об оценке работы БД;
- обучение пользователей, консультирование пользователей;
- разработка необходимой документации по работе конечных пользователей.
9. Подготовка и поддержание системных средств:
- анализ существующих на рынке программных средств и анализ возможности и необходимости их использования в рамках БД;
- разработка требуемых организационных и программно-технических мероприятий по развитию БД;
- проверка работоспособности закупаемых программных средств перед подключением их к БД;
- курирование подключения новых программных средств к БД.
10. Организационно-методическая работа по проектированию БД:
- выбор или создание методики проектирования БД;
- определение целей и направления развития системы в целом;
- планирование этапов развития БД;
- разработка общих словарей-справочников проекта БД и концептуальной модели;
- стыковка внешних моделей разрабатываемых приложений;
- курирование подключения нового приложения к действующей БД;
- обеспечение возможности комплексной отладки множества приложений, взаимодействующих с одной БД.
Вопросы для самопроверки по теме 2.2
1. Приведите классификацию пользователей БД?
2. Кто такой администратор приложений?
3. Кто и как определяет права доступа к БД?
4. Каким образом администратор БД определяет информационные потребности предприятия?
5. Что такое структурные ограничения целостности и ограничения бизнес логики?
6. В какой из моделей (внешней, концептуальной или внутренней) фиксируютя структурные ограничения?
7. Что такое логическая и физическая независимость данных?
8. Перечислите основные функции администратора БнД.
9. Из каких компонент состоит модель данных?
2.3. Концепции и этапы проектирования баз данных
При изучении данной темы Вы должны рассмотреть концепцию жизненного цикла БД и методы, используемые при проектировании моделей баз данных различных уровней поддерживаемых СУБД.
Для проверки изучения материала темы Вам предстоит ответить на вопросы для самопроверки.
При затруднениях в ответе на какой-либо вопрос следует обратиться к главе 14 учебника [1] или к материалам учебного пособия [9].
2.3.1. Жизненный цикл БД
Основные функции администратора базы данных, рассмотренные выше, тесно связаны с понятием жизненного цикла системы (процессов проектирования, сопровождения и расширения ИС). Главной составляющей в жизненном цикле БД является создание единой (интегрированной) базы данных и программ, необходимых для ее функционирования.
Основной целью создания и использования моделей данных в различных ИС (предназначенных для удовлетворения информационных потребностей предприятия), является снижение затрат на разработку и эксплуатацию ИС, что достигается частичной автоматизацией процессов связанных с различными стадиями жизненного цикла системы (рис.2.5.).
База данных, как информационная модель предметной области, представляет собой описание состояния предметной области на формальном языке. Соотнесение представления объектов в базе данных их реальным прообразам достигается только посредством описания состояния предметной области на естественном языке. Введение формального языка приводит к необходимости однозначного перевода описания на одном языке (естественном или формальном) в описание на другом языке и к необходимости их эквивалентной интерпретации.
Рис. 2.3. Интерпретация предметной области
При этом принято считать, что:
-
в каждом конкретном случае возможно неформально указать цели к достижению которых стремиться разработчик и пользователь. В соответствии с этими целями указать в предметной области множество объектов и связей между ними с полнотой (адекватностью), являющейся исчерпывающей для данных целей;
-
невозможно в каждом случае описать все многообразие реальности, хотя не существуют такие аспекты реальности, которые нельзя было бы описать.
Эквивалентная интерпретация достигается введением абстрактных состояний предметной области, определяемых формально и служащих однозначной интерпретацией описания состояния, как на естественном, так и на формальном языке (соответствующие функции интерпретации на рис. 2.3 обозначены IЕА и IФА). Описания состояний на естественном и формальном языке эквивалентны, если одно из них является результатом перевода другого, и если их интерпретацией является одно и то же абстрактное состояние.
Очевидно, что формальное установление факта эквивалентности описаний состояния предметной области на различных языках, требует их абстрактной интерпретации в терминах некоторой эталонной модели. Это приводит к необходимости введения понятия различных уровней абстракции для моделируемой ПО. На каждом из этих уровней абстракции локализуются свои собственные параметры (критерии) с минимальной зависимостью от параметров смежных уровней.
Как отмечается многими авторами, помимо указанных уровней моделирования данных, при проектировании любых систем, используется дополнительный уровень представления (отображения, абстракции, восприятия) информации, который носит название информационно-логического (инфологического), а его модель называют информационно-логической (Infological Model, ILM).
Рис. 2.4. Уровни отображения информации
Задача проектирования модели ПО сводится к последовательному эквивалентному отображению одного уровня абстракции в другой с учетом критериев к моделям каждого уровня. Практически во всех литературных источниках, связанных с базами данных, приводится подробный и обширный список критериев предъявляемых к различным моделям, но в качестве общепринятых выделяют:
-
достоверность – соответствие способу определения и организации информации в данной ПО;
-
отсутствие избыточности – исключение излишней информации;
-
расширяемость – логическая независимость от данных. Способность развиваться и включать новые требования с минимальным воздействием на работу уже существующих моделей. Такие изменения концептуальной схемы, как добавление или удаление новых сущностей, атрибутов или связей, должны осуществляться без необходимости внесения изменений в уже существующие внешние схемы для других групп пользователей.
Отметим, что не в одной из существующих СУБД принцип логической и физической независимости данных не реализован полностью.
Следует также отметить, что важный критерий производительности СУБД (точнее, тех средств, что использует АИС для доступа к данным) - скорость исполнения транзакции (выполнение запросов по модели), зависит непосредственно от организации структуры физической модели и архитектуры рассмотренной в разделе 1 информационной системы.
Ниже на рис.2.5. показан жизненный цикл базы данных.
2.3.2. Общая структура процесса проектирования БД
Проектирование (моделирование) базы данных представляет собой многоэтапный процесс. Основные этапы этого процесса приведены на рис. 2.6).
Рис. 2.5. Жизненный цикл БД
Подробно действия, отраженные на приведенном рисунке, рассмотрены в учебном пособии [7]. На рис. 2.6 представлены три этапа проектирования: проектирование информационной схемы информационной базы, выбор средств реализации и этап эксплуатации и сопровождения БД.
Модель предметной области на инфологическом этапе проектирования указывает, что должна содержать и обрабатывать проектируемая система, отражая общие закономерности присущие информации, циркулирующей в предметной области и задач решаемых в ней, не затрагивая вопросов как это будет реализовано в конкретной СУБД. Эти сведения используются при выборе СУБД. После выбора целевой СУБД становится возможным конструирование концептуальной, внутренней и внешних моделей информационной базы.
Описание внешней модели часто называют подсхемой. Кроме того, термин подсхема ассоциируется с понятием формы (документа), посредством которой пользователь наполняет базу хранимыми данными. Для задания подсхемы применяется схема БД и алгоритмы соответствующих прикладных программ (приложений) реализуемых на внутреннем языке целевой СУБД. Например, для СУБД Qracle таким языком является PL\SQL, а для Acsess – язык VBA (Visual Basic).
Каждый из этапов разбивается на несколько шагов проектирования (рис. 2.6). Очень важным является выбор СУБД, от которого в значительной степени зависит работоспособность построенной базы данных.
Рис. 2.6. Этапы проектирования БД
Вопросы для самопроверки по теме 2.3
1. Что такое жизненный цикл БД?
2. Назовите и раскройте суть основных этапов проектирования БД.
3. Что такое ILM и чем она отличается от концептуальной модели?
4. Назовите критерии выбора СУБД?
5. В какой из моделей фиксируются ограничения бизнес логики?
6. Поясните, что Вы понимаете под избыточностью данных?
7. Какая из моделей определяет производительность БД?
Резюме
Описаны основные этапы проектирования базы данных как процесса построения вышеуказанных моделей и жизненный цикл проектирования базы данных (создание, апробация, исправление ошибок и улучшение характеристик, опытная эксплуатация).
|
