Информационное обеспечение, базы данных. Конспект лекций (стр. 3 )

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

Правило 3 требует, чтобы отсутствующие данные можно было представить с помощью недействительных значений (NULL).

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

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

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

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

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

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

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

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

3.5. Постреляционная модель данных

а)

Подразделения Работники

б) Подразделения

Рис. 9. Структуры данных реляционной и постреляционной моделей

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

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

На рис. 9 на примере информации о подразделениях и работниках для сравнения приве­дено представление одних и тех же данных с помощью реляционной (а) и постреля­ционной (б) моделей. Таблица ПОДРАЗДЕЛЕНИЯ содержит данные о руководителе (Руководитель) и аббревиатуре (Аббревиатура). В таблице РАБОТНИКИ содержатся данные о работниках подразделений организации: табельный номер (Таб №), фамилия, инициалы (ФИО) и подразделение, где работает сотрудник (Подразделение). Таблица ПОДРАЗДЕЛЕНИЯ связана с таблицей РАБОТНИКИ полями Аббревиатура–Подразделение.

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

Помимо обеспечения вложенности полей постреляционная модель поддерживает ассоциированные многозначные поля (множественные группы). Совокупность ассо­циированных полей называется ассоциацией. При этом в строке первое значение од­ного столбца ассоциации соответствует первым значениям всех других столбцов ас­социации. Аналогичным образом связаны все вторые значения столбцов и т. д.

а)

SELECT

Аббревиатура, Руководитель, Таб №, ФИО

FROM

Подразделения, Работники

WHERE

Подразделения. Аббревиатура=Работники. Подразделение;

б)

SELECT

Руководитель, Подразделение, Таб №, ФИО

FROM

Подразделения

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

Поскольку постреляционная модель допускает хранение в таблицах ненормали­зованных данных, возникает проблема обеспечения целостности и непротиворечиво­сти данных. Эта проблема решается включением в СУБД механизмов, подобных хра­нимым процедурам в клиент-серверных системах.

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

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

Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных.

Рассмотренная нами постреляционная модель данных поддерживается СУБД uniVers. К числу других СУБД, основанных на постреляционной модели данных, от­носятся также системы Bubba и Dasdb.

3.6. Многомерная модель

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

Толчком послужила в 1993 году программная статья одного из основоположников реляционного подхода Э. Кодда. В ней сформулированы 12 основных требований к системам класса OLAP (OnLine Analytical Processing — оперативная аналитическая обработка), важнейшие из которых связаны с возможностями концептуального пред­ставления и обработки многомерных данных. Многомерные системы позволяют опе­ративно обрабатывать информацию для проведения анализа и принятия решения.

В развитии концепций ИС можно выделить следующие два направления:

·  системы оперативной (транзакционной) обработки;

·  системы аналитической обработки (системы поддержки принятия решений).

Реляционные СУБД предназначались для информационных систем оперативной обработки информации и в этой области были весьма эффективны. В системах ана­литической обработки они показали себя несколько неповоротливыми и недостаточ­но гибкими. Более эффективными здесь оказываются многомерные СУБД (МСУБД).

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

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

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

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

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

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

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

По сравнению с реляционной моделью многомерная организация данных облада­ет более высокой наглядностью и информативностью. Для иллюстрации на рис. 10 приведены реляционное (а) и многомерное (6) представления одних и тех же данных об объемах продаж автомобилей.

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

а)

6)

Рис. 10. Реляционное и многомерное представление данных

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

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

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

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

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

Модели	Месяцы

Рис. 11. Пример трехмерной структуры данных

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

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

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4 5 6 7 8