Лекция 1 (db l01. ppt) Введение в Автоматизированные информационные системы (аис) и Базы данных (БД). Определение бд и банков данных (БнД). Компоненты банка данных. Цели, задачи и структура курса



страница1/26
Дата27.04.2016
Размер5.04 Mb.
ТипЛекция
  1   2   3   4   5   6   7   8   9   ...   26



Лекция 1 (DB_l01.ppt)


Введение в Автоматизированные информационные системы (АИС)

и Базы данных (БД). Определение БД и банков данных (БнД).

Компоненты банка данных. Цели, задачи и структура курса
1.1. Введение в АИС и базы данных

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

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

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



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

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

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

Иногда в составе банка данных выделяют архивы. Основа­нием для этого является особый режим использования данных, когда только часть данных находится под оперативным управлением СУБД. Все остальные данные (собственно архивы) обычно располагаются на носителях, оперативно не управляемых СУБД. Одни и те же данные в разные моменты времени могут входить как в базы данных, так и в архивы. Банки данных могут не иметь архивов, но если они есть, то в состав банка данных может входить и система управления архивами.

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

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

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

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

В структуре банка данных выделяют следующие компоненты (подсистемы):


  • информационная база;

  • лингвистические средства;

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

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

  • организационно-административные подсистемы и нормативно-методическое обеспечение.

(Слайд 4)
Информационная база

Данные, отражающие состояние определенной предметной области и используемые информационной системой, принято называть информационной базой. Информационная база состоит из двух компонент: 1) коллекции записей собственно данных и 2) описания этих данных — метаданных.

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

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

В литературе по базам данных упоминаются три уровня представления данных — концептуальный, внутренний и внешний (Слайд 5).

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

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

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

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


Лингвистические средства

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

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

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



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

ЯМД обычно включает в себя средства запросов к базе данных и поддержания базы данных (добавление, удаление, обнов­ление данных, создание и уничтожение БД, изменение опреде­лений БД, обеспечение запросов к справочнику БД).

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

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

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

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



Селективная мощность языков запросов характеризует возможность выбора данных по разным критериям. Данное понятие плохо поддается формализации: можно сказать, что язык с большей селективной мощ­ностью позволяет сформулировать большинство запросов так, что ответ на них содержит меньше ненужных данных. Языки, обладающие малой селективной мощностью, в общем случае уже требуют привлечения дополнительных средств для анализа от­ветов на запросы (например, оценки пользователя).

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

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



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

Наиболее распространенным языком для работы с базами данных является SQL (Structured Query Language), в своих последних реализациях предоставляющий не только средства для спецификации и обработки запросов на выборку данных, но так же и функции по созданию, обновлению, управлению доступом и т.д.

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

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


Программные средства

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



  • ядро, обеспечивающее управление данными во внешней и оперативной памяти, а также протоколирование изменений;

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

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

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

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

Именно централизованное управление данными обеспечивает:



  • сокращение избыточности хранимых данных;

  • совместное использование хранимых данных;

  • стандартизацию представления данных, упрощающую экс­плуатацию БД;

  • разграничение доступа к данным;

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


Технические средства (Слайд 9)

Большинство банков данных создается и функционирует на основе универсальных вычислительных машин. Следует упомянуть и достаточно интенсивно развивавшееся в 80-90гг. направление создания машин баз данных – аппаратной реализации «нечисловой» обработки, в том числе параллельной и конвейерной обработки, ассоциативных процессоров и памяти.

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

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

Для повышения надежности хранения часто используют специализированные дисковые подсистемы – RAID (Redundant Array of Inexpensive Disk). Один логический RAID-диск - это несколько физических дисков, объединенных в одно устройство, управляемое специализированным контроллером, что позволяет распределять основные и системные данные между несколькими носителями (дисками), в том числе дублировать данные.

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

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

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


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

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

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

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

Прикладные программисты имеют, как правило, в своем распоряжении один или несколько языков программирования, с помощью которых генерируются прикладные программы.
1.3. Цель, задачи и структура курса (Слайд 11)

Цель курса – понимание общесистемных и прикладных основ баз данных, практическое изучение средств моделирования, разработки и администрирования БД, а также разработки приложений управления доступом к информационным массивам.

Образовательными задачами общесистемного уровня являются:


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

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

Задачами методологического и прикладного уровня являются изучение:

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

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

  • основ и средств управления и администрирования СУБД.


Место курса в системе образования (Слайд 12)

Курс базируется на материале курсов «Основы программирования», «Информатика», «Дискретная математика» и служит методологической основой для курсов «Информационные системы», «Проектирование информационных систем», «Интеллектуальные информационные системы», «Информационная безопасность».



Требования к уровню освоения содержания курса

В результате изучения курса студенты должны:



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

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

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

  • иметь практические навыки разработки баз данных;

  • иметь представление о целях и средствах разработки и администрирования баз данных.


В составе курса 4 раздела (Слайд 13):

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

  • моделирование и проектирование БД (инфологическое моделирование ПО; даталогическое моделирование; управление реляционными базами данных);

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

  • эксплуатация и разработка приложений БД (управление доступом и целостность БД; администрирование СУБД; разработка приложений в среде Delphi).




  • Лекция 2 (DB_l02.ppt)

Классификация БД. Фактографические и документальные БД.

БД оперативной и ретроспективной информации. Хранилища данных.

Локальные и распределенные БД.

Соотношение основных требований и свойств СУБД: система компромиссов.
2.1. Классификация баз данных

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

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

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

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

По топологии хранения данных различают локальные и распределенные БД.

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

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

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

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

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

БД могут соотноситься с различными уровнями информационных процессов: уровень информационных технологий (ИТ), уровень системы (ИС), уровень информационных ресурсов (ИР). (слайд 3)

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

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

При рассмотрении БД на уровне информационных ресурсов БД трактуется как элемент мировых ИР. Основной характеристикой здесь является содержание БД, хотя и структуры данных также немаловажны.
2.2. Фактографические и документальные БД

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

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

С точки зрения структуры единицы хранения принято различать хорошо структурированные данные и слабо структурированные данные.



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

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

Фактографические БД – БД, ориентированные на хранение хорошо структурированных данных. Единицей хранения в таких БД служит описание «факта» конечным четко определенным множеством характеристических свойств.

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



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

При построении документальных БД обычно ПрО представляется как совокупность в общем случае не взаимодействующих объектов. Набор характеристических свойств объекта конечен, но не фиксирован. Значение характеристического свойства может быть множественным и может зависеть от контекста использования (слайд 4).

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

Отличия этих двух видов поиска представлены на слайде (слайд 5).

При поиске данных обычно ищут полное совпадение запроса с элементом данных. При поиске данных результаты выводятся простой индукцией, например, если A и B, то C. Поиск информации намного ближе к методам дедукции: отношения описываются только степенью уверенности или неуверенности. В информационном поиске, как правило, стратегия поиска построена по принципу усечения первоначальных результатов поиска, что и приводит к логике «от общего к частному». Из этого следует детерминистское описание модели поиска данных и вероятностная модель информационного поиска.

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

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

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


2.3. БД оперативной и ретроспективной информации. Хранилища данных

С точки зрения основных особенностей ПрО и решаемых задач можно выделить два основных класса БД – оперативной и ретроспективной информации.

БД оперативной информации являются основой так называемых OLTP-приложений (Оп-Line Transactions Processing). Типичными примерами OLTP-приложений являются системы складского учета, системы заказов билетов, банковские системы, выполняющие операции по переводу денег, и т. п. Основная функция подобных систем заключается в одновременном выполнении большого количеств коротких транзакций – завершенных блоков операций манипулирования данными, например: "снять некоторую сумму денег со счета А и добавить эту сумму на счет В", "продать пассажиру билет на заданный поезд на заданное место на определенную дату". Завершенность транзакции означает, что при возникновении ошибки транзакция должна целиком откатиться и вернуть БД к состоянию, которое было до начала транзакции (не должно быть ситуации, когда деньги сняты со счета А, но не поступили на счет В).

Основные особенности OLTP-приложений:



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

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

  2. Запросы на выборку в основном предназначены для предоставления пользователям возможности выбора из различных справочников, и большая часть этих запросов известна заранее еще на этапе проектирования.

Таким образом, критическими для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных.

БД ретроспективной информации входят в состав документальных ИС, ориентированных на задачи информационного поиска, а также в OLAP-приложения (Оп-Line Analitical Processing, оперативная аналитическая обработка данных). Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений (DSS, Decision Support System), а также хранилищ данных (data warehouse) и систем интеллектуального анализа данных (data mining). Такие системы предназначены для установления зависимостей между данными (например, можно попытаться определить, как связан объем продаж товаров с характеристиками потенциальных покупателей) или для проведения анализа, отвечающего на вопросы "что если...".

БД ретроспективной информации характеризуются следующими особенностями:


  1. Добавление в БД новых данных происходит относительно редко крупными блоками.

  2. Данные из БД обычно никогда не удаляются.

  3. Запросы к данным являются нерегламентированными и, как правило, достаточно сложными. Очень часто новый запрос формулируется аналитиком для уточнения результата, полученного при выполнении предыдущего запроса.

  4. Скорость выполнения запросов важна, но не критична.

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

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

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

Хранилище данных - предметно-ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для под­держки принятия решений.

В приведенном определении указанные характеристики данных рассматриваются следующим образом. (слайд 6)



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

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

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

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

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



Сравнение систем OLTP и хранилищ данных

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


Проблемы разработки и сопровождения хранилищ данных

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



  • Недооценка ресурсов, необходимых для загрузки данных: многие разработчики склонны недооценивать время, необходимое для извлечения, очистки и загрузки данных в хранилище.

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

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

  • Повышение требований конечных пользователей

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

  • Высокие требования к ресурсам: может потребоваться огромный объем дискового про­странства.

  • Владение данными: создание хранилища данных может потребовать изменения статуса конечных пользователей в отношении прав владения данными

  • Сложное сопровождение: любая реорганизация деловых процессов или источников данных может отразиться на работе хранилища данных

  • Долговременный характер проектов

  • Сложности интеграции


Локальные и распределенные БД

В общем случае режимы работы с БД можно классифицировать по следующим признакам:



  • многозадачность - однопользовательский или многопользовательский;

  • правило обслуживания запросов – последовательное или параллельное;

  • схема размещение данных – централизованная или распределенная БД.


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

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

Развитие сетевых технологий в сочетании с широким распространением персональных ЭВМ и внедрением стандартов открытых систем привело к появлению систем баз данных размещенных в сети разнотипных компьютеров. Такие системы распределенных баз данных обеспечивают обработку распределенных запросов, когда при обработке одного запроса используются ресурсы базы, размещенные на различных ЭВМ сети. Система распределенных баз данных состоит из узлов, каждый из которых является СУБД, а узлы взаимодействуют между собой так, что база данных любого узла будет доступна пользователю, так как если бы она была локальной. Архитектура распределенной БД приведена на слайде (слайд 9).


Соотношение основных требований и свойств СУБД: система компромиссов (слайд 10)

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

1). Каким образом сложные нелинейные структуры данных представить в виде линейных – наиболее соответствующих принципу последовательного представления (хранения) в машинной памяти.

2). Каким образом организовать данные, чтобы была возможность эффективного внесения, удаления и редактирования данных.

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

4). Каким образом организовать данные, чтобы поиск был эффективным и позволял отыскивать записи по нескольким ключам.


Создание базы данных - это по существу попытка найти компромисс сразу по нескольким направлениям и сочетаниям нескольких взаимообратных факторов (с точки зрения их влияния на показатель общей эффективности системы), в том числе, следующих (слайд 11):

  1. Эффективность – простота;

  2. Скорость выборки – стоимость (сложность) аппаратных средств;

  3. Скорость выборки – сложность процедур доступа;

  4. Плотность данных – время доступа и сложность процедур;

  5. Независимость данных – производительность;

  6. Гибкость средств поиска – избыточность данных или

  7. Гибкость поиска – скорость поиска;

  8. Сложность процедур доступа – простота обслуживания.


Лекция 3 (DB_l03.ppt)

Методологические основы БД. Типология свойств и связей объекта.

Многоуровневые модели предметной области.

Идентификация объектов и записей.

3.1. Методологические основы БД

Иерархическое описание и абстрагирование

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

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

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

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

Природа характеристического свойства может быть различной. Рассмотрим основные типы свойств (слайд 3).

Свойство может быть множественным или единичным – т.е. атрибут, задающий свойство, может одновременно иметь несколько значений или, соответственно, только одно. Например, студент может владеть несколькими иностранными языками, но свойство «№ студенческого билета» будет иметь единственное значение.

Свойство может быть простым (не подлежащих дальнейшему делению с точки зрения прикладных задач) или составным – если его значение составляется из значений простых свойств. Например, свойство «Год рождения» является простым, а свойство «Адрес» - составным, т.к. включает значения простых свойств «Город», «Улица», «Дом».

В некоторых случаях полезно различать базовые и производные свойства. Например, объект «Студент» может иметь свойство «Общее количество сданных экзаменов», которое вычисляется суммированием сданных экзаменов.

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

Значения свойств могут быть постоянными - статическими, или динамическими, т.е. меняться со временем. Например, свойство «№ студенческого билета» является статическим, а «Адрес» - динамическим. Свойство может быть неопределенным, если оно является динамическим, но его текущее значение еще не задано.

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


Инструмент связей - это средство представления сложных объектов, каждый из которых может рассматриваться как множество некоторым образом взаимосвязанных простых объектов. Деление на простые и сложные объекты, также как и характер взаимосвязи, является условным и определяется особенностям анализа предметной области, т.е. в конце концов – характером использования данных о предметах в решаемых прикладных задачах. При этом с точки зрения, например, конструктора, ДЕТАЛЬ является сложным объектом, а с точки зрения поставщика – простым.

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

Отношение «часть-целое» используются для представления составных объектов. Например, МАШИНЫ состоят из УЗЛОВ, УЗЛЫ состоят из ДЕТАЛЕЙ. Здесь возможны как отношения «один ко многим», так и «многие ко многим».

Отношение «род-вид» - для представления обобщенных объектов. Например, СОТРУДНИКИ подразделяются по профессии на КОНСТРУКТОРОВ, ПРОГРАММИСТОВ, РАБОЧИХ; ПРОГРАММИСТЫ – на ПРИКЛАДНЫХ ПРОГРАММИСТОВ и СИСТЕМНЫХ ПРОГРАММИСТОВ. Иерархические отношения, и, в частности – «родо-видовые», обычно используются как основа классификации объектов по наборам характеристических признаков. Причем «видовые» объекты наследуют свойства «родовых».

Другой широко используемой разновидностью взаимосвязи является агрегирование – объединение простых объектов в сложный по принципу их принадлежности агрегату или их совместного участия в некотором процессе. Агрегирование, рассматриваемое здесь как более общий случай иерархических отношений, объединяет объекты разной природы с единственным общим свойством «совместное участие». Агрегированные объекты именуются обычно отглагольными существительными, например, «Состав»: ПОДРАЗДЕЛЕНИЕ состоит из СОТРУДНИКОВ; «Поставка»: ПОСТАВЩИК поставляет ДЕТАЛИ.
Связи. Кроме связей между объектом и его свойствами, инфологическая модель отражает связи между объектами разных классов. Связь определяется как «ассоциация, объединяющая несколько сущностей». Эта ассоциация всегда может существовать между разными сущностями или между сущностью и ей же самой (рекурсивная связь).

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

Если каждый экземпляр сущности участвует, по крайней мере, в одном экземпляре связи, то такое участие этой сущности называется полным (или обязательным); в противном случае – неполным (или необязательным).

Количественный характер участия экземпляров сущностей (один или многие) задается типом связи (или мощностью связи). Возможны следующие типы: «один к одному», «один ко многим», «многие к одному», «многие ко многим».


3.3. Многоуровневые модели предметной области

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

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

Модель предметной области соотносится с реальными объектами и связями так же, как схема маршрутов городского пассажирского транспорта с фактической траекторией движения автобуса. Схема адекватно отражает действительность на уровне основных понятий – маршрутов и остановок: выбрав по схеме маршрут, пассажир достигнет цели (прибудет на нужную остановку) независимо от того, в каком транспортном ряду будет двигаться автобус.


Наиболее простой способ представления предметных областей в БД реализуется поэтапно:

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

2) определением физического представления данных с учетом выбранных структур хранения данных и архитектуры ЭВМ.

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

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

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

Соотношение этих понятий приведено на слайде (слайд 7).

Теоретически вопрос о многообразии уровней абстракции был решен еще в 60 – 70-х годах. Основой для его решения является концепция многоуровневой архитектуры системы базы данных. Например, в отчете CODASYL предусматривался архитектурный уровень подсхемы, который позволял для каждого конкретного приложения строить свое собственное «видение» используемого подмножества базы данных путем определения его «персональной» подсхемы базы данных.

В более общем виде этот вопрос решен в архитектурной модели ANSI/X3/SPARC. Здесь на внешнем уровне может поддерживаться совсем иная модель данных (или даже несколько моделей), чем на концептуальном уровне. Поддержка разнообразных возможностей абстрагирования в такой системе достигается благодаря средствам определения и поддержки межуровневого отображения моделей данных.

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

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


  • адекватность отображения предметной области;

  • возможность взаимодействия с БД разных пользователей при решении разных прикладных задач;

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

  • надежность функционирования БД и защиту от несанкционированного доступа.

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

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

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

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

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

Это отражает распространенную практику специализации и разделения ответственности, иллюстрируемую слайдом (слайд 10). Главное же заключается в том, что работу по проектированию и эксплуатации баз данных можно разделить на три достаточно самостоятельных этапа. Хотя надо отметить, что на практике создание концептуальной схемы не всегда предшествует построению внешней. Иногда трудно с самого начала полностью определить предметную область, но, с другой стороны, уже известны требования пользователей (именно поэтому создание базы уже имеет смысл). И, кроме того, адекватность модели предметной области, в конце концов, должна подтверждаться практикой пользовательских представлений.
3.4. Идентификация объектов и записей

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

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

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

Также как и в реальном мире, отдельный объект всегда уникален (уже хотя бы потому, что мы именно его выделяем среди других). Соответственно, запись, содержащая данные о нем, также должна быть узнаваема однозначно (по крайней мере, в рамках предметной области), т.е. – иметь уникальный идентификатор, причем никакой другой объект не должен иметь такой же идентификатор. Поскольку идентификатор – суть значение элемента данных, в некоторых случаях для обеспечения уникальности требуется использовать более одного элемента. Например, для однозначной идентификации записей о дисциплинах учебного плана необходимо использовать элементы СЕМЕСТР и НАИМЕНОВАНИЕ ДИСЦИПЛИНЫ, так как одна дисциплина может быть прочитана в разных семестрах.

Предложенная выше схема представляет атрибутивный способ идентификации содержания объекта (слайд 11). Она является достаточно естественной для данных, имеющих фактографическую природу, и описывающих обычно материальные объекты. Информацию, представляемую такого рода данными, называют хорошо структурированной. Здесь важно отметить, что структурированность относится не только к форме представления данных (формат, способ хранения), но и к способу извлечения значения (интерпретации данных) пользователем: значение параметра не только представлено в предопределенной форме, но и обычно сопровождается указанием размерности величины, что позволяет пользователю понимать ее смысл без дополнительных комментариев. Таким образом, фактографические данные предполагают возможность их непосредственной интерпретации.

Исходя из соотношения понятий «объект», «атрибут», «значение атрибута» может быть определена следующая типология простых (атомарных) запросов (слайд 12):

1). А(Е) = ? Каково значение атрибута А для объекта Е?

2). А(?) = V Какие объекты имеют значение атрибута равное V?

3). ?(Е) = V Какие атрибуты объекта Е имеют значение равное V?

4). ?(Е) = ? Какие значения атрибутов имеет объект Е?

5). А(?) = ? Какие значения имеет атрибут А в наборе?

6). ?(?) = V Какие атрибуты объектов набора имеют значение равное V?

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

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

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

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

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

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


  1. способ, с помощью которого внешние пользователи представляют (описывают) объекты и связи;

  2. форму и методы внутримашинного представления элементов данных и взаимосвязей;

  3. средства, обеспечивающие взаимно однозначные преобразования внешнего и внутримашинного представлений.

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

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


Соотношение понятий модель данных и модель базы данных приведено на слайде (слайд 12).

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



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

  • как средство спецификации типов данных и их организации, разрешенных в конкретной БД;

  • как основа разработки общей методологии построения баз данных;

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

  • как основа разработки семейства языков запросов и языков манипулирования данных;

  • как основа архитектуры СУБД;

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

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

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

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

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


Лекция 4 (DB_l04.ppt)

Теоретические основы фактографических БД. Реляционная алгебра и реляционное исчисление. Основные операции реляционной алгебры

и реляционного исчисления при обработке данных



  1   2   3   4   5   6   7   8   9   ...   26


База данных защищена авторским правом ©ekollog.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал