Текст книги "Основы использования и проектирования баз данных"

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

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

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

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

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

Однако использование СУБД дает не только преимущества, но сопряжено и с такими негативными последствиями, как:

– сложность СУБД;

– большой размер СУБД;

– значительная стоимость некоторых СУБД;

– дополнительные затраты на аппаратное обеспечение;

– затраты на преобразование имеющейся инфраструктуры предприятия;

– снижение производительности;

– более серьезные последствия при выходе системы из строя.

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

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

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

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

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

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

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

1.3. Архитектура баз данных

Построению систем, основанных на использовании СУБД, предшествовали интенсивные научные исследования, направленные на решение проблемы устройства самой СУБД. Наиболее фундаментальным результатом этих исследований стало определение трех уровней абстракции, т. е. трех различных уровней описания элементов данных, зафиксированных в модели ANSI-SPARC [13]. Эти уровни формируют трехуровневую архитектуру базы данных, которая охватывает внешний, концептуальный и внутренний уровни (рис. 1.2). Уровень, на котором данные воспринимаются пользователями, называется внешним уровнем (external level), тогда как СУБД и операционная система воспринимают данные на внутреннем уровне (internal level). Именно на внутреннем уровне данные реально сохраняются с использованием структур данных и файловой организации. Концептуальный уровень (conceptual level) представления данных предназначен для отображения внешнего уровня на внутренний и обеспечения необходимой независимости друг от друга.

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

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

– каждый пользователь должен иметь возможность изменять свое представление о данных, причем это изменение не должно оказывать влияния на других пользователей;

– пользователи не должны непосредственно иметь дело с какими-либо подробностями физического хранения данных в базе, т. е. взаимодействие пользователя с базой не должно зависеть от особенностей хранения в ней данных;

– администратор базы данных должен иметь возможность изменять структуру хранения данных в базе, не оказывая влияния на пользовательские представления;

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

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

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

Рис. 1.2. Трехуровневая архитектура ANSI-SPARC.

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

Концептуальный уровень соответствует обобщающему представлению базы данных. Этот уровень описывает то, какие данные хранятся в базе данных, а также связи, существующие между ними. Являясь промежуточным уровнем в трехуровневой архитектуре, он содержит логическую структуру всей базы данных (с точки зрения администратора базы данных). Фактически это полное представление требований к данным со стороны предприятия, которое не зависит от любых соображений относительно способа их хранения. На концептуальном уровне представлены следующие компоненты:

– все сущности, их атрибуты и связи;

– накладываемые на данные ограничения;

– информация о смысловом содержании данных;

– информация о мерах обеспечения безопасности и поддержки целостности данных.

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

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

– распределение дискового пространства для хранения данных и индексов;

– описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных);

– сведения о размещении записей;

– сведения о сжатии данных и выбранных методах их шифрования.

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

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

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

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

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

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

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

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

Если СУБД поддерживает уровень подсхем, то перед проектировщиком встает задача определения подсхем. Это также можно рассматривать как этап проектирования БД.

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

Рис. 1.3. Модели и описания структуры БД, поддерживаемые СУБД.

Взаимосвязь этапов проектирования базы данных показана на рис. 1.4.

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

Рис. 1.4. Взаимосвязь этапов проектирования.

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

1.4. Классификация баз данных

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

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

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

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

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

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

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

По форме собственности БД делятся на государственные и негосударственные.

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

1.5. Классификация моделей данных

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

Рис. 1.5. Классификация БД по характеру хранения данных и обращения к ним.

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

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

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

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

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

Модели, ориентированные на формат документа, связаны прежде всего со стандартным общим языком разметки – SGML, который был утвержден ISO в качестве стандарта еще в 1980-х гг. Этот язык предназначен для создания других языков разметки, он определяет допустимый набор дескрипторов, их атрибуты и внутреннюю структуру документа. С помощью SGML можно описывать структурированные данные, организовывать информацию, содержащуюся в документах, представлять эту информацию в некотором стандартизованном формате.

Гораздо более простой и удобный, чем SGML, язык HTML позволяет определять оформление элементов документа и вносить специальные дескрипторы в документы, при помощи которых осуществляется процесс разметки. Дескрипторы на языке HTML в первую очередь предназначены для управления процессом вывода содержимого документа на экране с помощью программы-клиента (например, браузера) и определяют этим самым способ представления документа, но не его структуру. На языке HTML документ представляется набором элементов, причем начало каждого элемента, а в большинстве случаев и его конец, отмечается дескриптором, который называется тегом. В начале элемента указывается открывающий тег, а в конце – закрывающий. Например, элемент, соответствующий размечаемому документу, открывается тегом <html>, закрывается тегом </html> и содержит внутри себя элементы заголовка и тела документа, ограниченные специальными тегами <head> </head> и <body> </body>:

<html>

<head>

заголовок документа

</head>

<body>

тело документа

</body>

</html>

Рис. 1.6. Классификация моделей данных.

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

Однако HTML сегодня уже не удовлетворяет в полной мере требованиям, предъявляемым современными разработчиками к языкам подобного рода. На смену ему пришел новый язык гипертекстовой разметки, мощный, гибкий и удобный язык XML.

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

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

Дескрипторные модели – самые простые из документальных моделей, они широко использовались на ранних стадиях использования документальных баз данных. В этих моделях каждому документу соответствовал дескриптор – описатель. Этот дескриптор имел жесткую структуру и описывал документ в соответствии с характеристиками, требуемыми для работы с документами в документальной базе данных.

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

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

Рис. 1.7. Распределение курсов между преподавателями.

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

Указанный недостаток снят в СМ, где, по крайней мере теоретически, возможны связи «всех со всеми» (рис. 1.9). Использование ИМ и СМ ускоряет доступ к информации в БД. Но поскольку каждый элемент данных должен содержать ссылки на некоторые другие элементы, требуются значительные ресурсы как дисковой, так и основной памяти компьютера. Кроме того, для этих моделей характерна сложность реализации СУБД.

Рис. 1.9. Сетевая модель данных.

Реляционная модель является простейшей и наиболее привычной формой представления данных в виде таблицы (рис. 1.10). В теории множеств таблице соответствует термин «отношение» (relation), который и дал название реляционной модели. Достоинством РМ является сравнительная простота инструментальных средств ее поддержки, а недостатком – жесткость структуры данных и зависимость скорости выполнения операций от размера таблиц.

Рис. 1.10. Реляционная модель данных: НП – номер преподавателя; НК – номер курса.

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

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