2. Узагальнена архітектура системи підтримки прийняття рішень.

Обобщенная архитектура СППР может быть представлена следующим образом:

Подсистема ввода данных. В таких подсистемах, называемых OLTP (On­line transaction processing), выполняется операционная (транзакционная) обработка данных. Для реализации этих подсистем используют обычные системы управления базами данных (СУБД).

• Подсистема хранения. Дня реализации данной подсистемы используют современны^ СУБД и концепцию хранилищ данных.

П Подсистема анализа. Данная подсистема может быть построена на основе:

• подсистемы информационно-поискового анализа на базе реляцион­ных СУБД и статических запросов с использованием языка структур­ных запросов SQL (Structured Query Language);

• подсистемы оперативного анализа. Для реализации таких подсистем применяется технология оперативной аналитической обработки дан­ных OLAP (On-line analytical processing), использующая концепцию многомерного представления данных:

• подсистемы интеллектуального анализа. Данная подсистема реализует методы и алгоритмы Data Mining ("добыча данных").

3. Дванадцять правил е.Кодда для реляційних бд.

В них Кодд сформулировал следующие 12 правил для реляционной БД:

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

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

3. NULL трактуется как неизвестное значение. Если в ячейку таблицы значение не введено, то записывается значение NULL. Его нельзя путать с пустой строкой или со значением 0.

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

5. Должен использоваться единый язык для взаимодействия с СУБД.

Для управления реляционной БД должен использоваться единый язык. В настоящее время таким инструментом стал язык SQL.

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

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

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

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

10. За целостность данных отвечает СУБД. Под целостностью данных в общем случае понимается готовность БД к работе. Различают следующие типы целостности:

• физическая целостность — сохранность информации на носителях я корректность форматов хранения данных;

• логическая целостность — непротиворечивость и актуальность дан­ных, хранящихся в БД.

Потеря целостности базы данных может произойти из-за сбоев аппарату­ры ЭВМ, ошибок в программном обеспечении, неверной технологии вво­да и корректировки данных, низкой достоверности самих данных и т. д.

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

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

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