Фактографические информационные системы

Размещено на http://www.allbest.ru/

1. Фактографические информационные системы

файловый информационный запрос иерархический

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

2. Файловые ИС

Исторически первым шагом создания фактографических АИС были файловые системы. С точки зрения прикладной программы файл - это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные. По своему содержанию файл ИС является набором записей (records), которые содержат логически связанные данные. Каждая запись содержит логически связанный набор из одного или нескольких полей (field). Значение поля дает некоторую характеристику моделируемого в ИС объекта.

Для манипулирования файловыми данными используется система управления файлами. Ее основные задачи:

распределение внешней памяти;

определение структуры файла;

способы именования файлов и отображение их имен на пространство адресов внешней памяти;

обеспечение доступа к данным;

обеспечение защиты данных в файлах;

способы многопользовательского доступа к файлам.

Ограничения файловых информационных систем

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

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

Пример. Рассмотрим два отдела в некоторой организации - планово-договорный отдел и склад.

Файловая ИС ПДО:

Договоры (Номер, Код контрагента, Код товара, Количество, Цена договора, Дата заключения, Дата поставки).

Товары (Код товара, Наименование)

Контрагенты (Код контрагента, Наименование, Адрес, Телефон).

…

Файловая ИС склада:

Товары Код товара, Наименование)

Получатели (Код получателя, Наименование, Адрес, Телефон).

Отгрузка (Код получателя, Код товара, Количество)

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

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

Несовместимость форматов файлов, используемых в различных приложениях.

Ограниченный круг запросов к ИС.

Отсутствие средств восстановления в случае аппаратного или программного сбоя.

Неэффективные способы многопользовательского доступа к данным.

3. Базы данных

Перечисленные недостатки являются следствием двух факторов:

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

Помимо самих приложений не предусмотрено других инструментов доступа к данным и их обработки.

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

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

Основные черты баз данных:

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

Все данные собраны вместе и хранятся с минимальной долей избыточности.

База данных хранит не только рабочие данные, но и метаданные («данные о данных»).

Определение. Метаданные (meta-data) - это информация, которая описывает информационное наполнение базы данных (сведения о структуре данных, допустимых значениях, взаимосвязи с другими данными, физическом размещении и т.п.).

Независимость между программами и данными (program-data independence). Аналогия с принципом абстрагирования данных (известным из ООП): внутренняя реализация объектов остается закрытой для пользователя и может изменяться без видимых последствий до тех пор, пока не изменится внешнее описание этого объекта.

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

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

4. Системы управления базами данных

Определение. Система управления базами данных (Database management system, DBMS) - это комплекс программного обеспечения, с помощью которого пользователи могут определять, создавать и поддерживать базу данных, а также осуществлять к ней контролируемый доступ.

Основные возможности СУБД:

Позволяет определять базу данных (вносить метаданные) с использованием специального языка определения данных (ЯОД, DDL - Data Definition Language).

Позволяет вставлять, обновлять, удалять и извлекать информацию из базы данных путем взаимодействия с БД и прикладными программами пользователя. Для этих целей в СУБД обычно разрабатывается язык манипулирования (управления) данными (ЯМД, ЯУД, DML - Data Manipulation Language), который также называют языком запросов (Query Language).

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

Системы обеспечения безопасности данных и предотвращения несанкционированного доступа;

Системы поддержки целостности и непротиворечивости хранимых данных;

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

Системы восстановления БД после аппаратного или программного сбоя.

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

Более подробно все указанные возможности СУБД будут изучаться в курсе «Базы Данных».

5. Модели данных

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

Определение. Предметная область - это часть реального мира, которая представляется и отображается в ИС.

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

Мы рассмотрим трехуровневую систему описания БД.

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

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

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

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

Размещено на http://www.allbest.ru/

На каждом из указанных уровней строится описание БД в виде модели данных.

Модель данных внешнего уровня - это описание предметной области (или представлений о предметной области) задачи.

К моделям данных концептуального уровня относятся объектные (object-based) модели и модели на основе записей (record-based).

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

6. Объектные модели

В процессе создания объектной модели разработчик заменяет понятия о предметах, фактах и событиях реального мира на их информационные представления. На сегодняшний день существует свыше 30 разновидностей объектных моделей. Однако наиболее распространенным методом концептуального проектирования считается модель типа «сущность-связь» (ER-модель, Entity-Relationship model).

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

Дадим следующие определения:

Сущность (entity) - это отдельный элемент предметной области (человек, место, вещь или событие), который должен быть представлен в базе данных.

Набор сущностей (entity set) - это множество сущностей одного типа. Пример: люди, предприятия, праздники и т.д.

Атрибут - это свойство, которое описывает некоторый аспект объекта и значение которого следует зафиксировать. Фактически сущность представляет собой множество атрибутов.

Ключ сущности - это один или несколько атрибутов, однозначно идентифицирующие сущность в наборе сущностей.

Связь (relationship) - некоторое это ассоциативное отношение между сущностями.

Пример: Отдел - Начальник отдела, Родитель-Потомок.

Связь, объединяющая два набора сущностей, называется бинарной связью.

Роль сущности в связи - это функция, которую выполняет сущность в данной связи. Например, в связи Родитель - Потомок сущности Человек могут иметь роли "родитель" и "потомок". Указание ролей в модели "сущность-связь" не является обязательным и служит для уточнения семантики связи.

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

Связь один к одному (1 : 1). Сущности с одной ролью всегда соответствует не более одной сущности с другой ролью.

Размещено на http://www.allbest.ru/

Пример: Отдел - Начальник отдела

Связь один ко многим (1 : n). Сущности с одной ролью может соответствовать любое число сущностей с другой ролью.

Размещено на http://www.allbest.ru/

Пример: Отдел-Сотрудник. В каждом отделе может работать произвольное число сотрудников, но сотрудник может работать только в одном отделе.

Связь многие ко многим (m : n). Каждая из ассоциированных сущностей может быть представлена любым количеством экземпляров. Пример. Для выполнения каждого проекта по контракту в организации создается рабочая группа исполнителей, в которую входят сотрудники разных отделов. Поскольку каждый сотрудник может входить в несколько рабочих групп, а каждая группа должна включать не менее одного сотрудника, то связь между сущностями «Сотрудник» и «Рабочая Группа» имеет степень m : n.

1

Размещено на http://www.allbest.ru/

Если существование сущности x зависит от существования сущности y, то x называется зависимой сущностью (иногда сущность x называют "слабой", а "сущность" y - сильной).

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

Графическое представление модели «сущность-связь» называется ER-диаграммой. В таблице ниже указаны обозначения основных элементов ER-модели.

Обозначение	Значение
	Набор независимых сущностей
	Набор зависимых сущностей
	Атрибут
	Ключевой атрибут
	Набор связей

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

Семантическая модель данных Хаммера - МакЛеода (1981);

Функциональная модель данных Шипмана (1981);

Семантическая ассоциативная модель Су (1983)

Объектно-ориентированные модели.

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

7. Модели на основе записей

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

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

Иерархическая (hierarchical);

Сетевая (network);

Реляционная (relational).

8. Иерархическая и сетевая модели данных

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

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

Агрегат данных - поименованная совокупность элементов данных внутри записи, которую можно рассматривать как единое целое. Имя агрегата используется для его идентификации в схеме структуры данного более высокого уровня. Агрегат данных может быть простым если состоит только из элементов данных (пример: дата[день, месяц, год]), и составным если включает в свой состав другие агрегаты.

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

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

Размещено на http://www.allbest.ru/

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

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

Иерархическая модель хорошо реализует отношения между исходной и дочерней записью по схеме 1:1 или 1:n. Если между записями возникает связь типа m:n, то возникнет необходимость в дублировании информации.

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

Наиболее развитый стандарт описания сетевой модели данных был предложен Ассоциацией по языкам систем обработки данных КОДАСИЛ (CODASYL COnference on DAta SYstems Language).

9. Реляционная модель данных

Реляционная модель данных основана на математической теории отношений (само название "реляционная" происходит от английского relation - "отношение").

Дадим несколько определений.

Декартово произведение: Для заданных конечных множеств (не обязательно различных) декартовым произведением называется множество произведений вида:

,

где .

Пример: если даны два множества A (a1,a2,a3) и B (b1,b2), их декартово произведение будет иметь вид С=AЧB (a1Чb1, a2Чb1, a3Чb1, a1Чb2, a2Чb2, a3Чb2).

Отношение: Отношением R, определенным на множествахназывается подмножество декартова произведения.

При этом:

Множества называются доменами отношения;

Элементы декартова произведения называются кортежами;

Число n определяет степень отношения (n=1 - унарное, n=2 - бинарное, ..., n-арное);

Количество кортежей называется мощностью отношения;

Пример: на множестве С из предыдущего примера могут быть определены отношения R1 (a1*b1, a3*b2) или R2 (a1*b1, a2*b1, a1*b2)

Отношения удобно представлять в виде таблиц.

Основные компоненты реляционного отношения

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

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

Именованное множество пар «имя атрибута - имя домена» называется схемой отношения. Мощность этого множества - называют степенью или арностью отношения. Набор именованных схем отношений представляет собой схему базы данных.

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

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

В отличие от иерархической и сетевой моделей данных в реляционной отсутствует понятие группового отношения. Для отражения ассоциаций между кортежами разных отношений используется дублирование их ключей. Рассмотрим пример реляционной базы данных, в которой заданы отношения, представляющие уже знакомые нам наборы сущностей Отдел, Сотрудник, Заказчик, Контракт и Исполнители:



Пример реляционной БД

Как видно из рисунка связь между отношениями Отдел и Сотрудник создается путем копирования первичного ключа "Номер_отдела" из первого отношения во второе. Таким образом, для того, чтобы получить список работников для отдела с заданным наименованием, необходимо: 1) из таблицы Отдел установить значение атрибута "Номер_отдела", соответствующее заданному наименованию отдела; 2) выбрать из таблицы Сотрудник все записи, значение атрибута "Номер_отдела" которых равно значению, полученному на предыдущем шаге. Для того, чтобы узнать в каком отделе работает сотрудник, нужно выполнить обратную операцию: 1) определяем "Номер_отдела" из таблицы Сотрудник; 2) по полученному значению находим запись в таблице Отдел.

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

10. Фундаментальные свойства отношений

Фундаментальные свойства отношений:

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

Отсутствие упорядоченности кортежей.

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

Атомарность значений атрибутов, т.е. среди значений домена не могут содержаться составные значения или отношения.

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

Свойства реляционных СУБД:

Данные в них хранятся в таблицах;

Связи между таблицами скрыты от пользователя;

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

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

11. Физические модели данных

Описывают то, как данные хранятся в ЭВИ, представляя информацию о структуре записей, их упорядоченности и существующих путях доступа. Примеры физических моделей:

Обобщающая модель (unifying model);

Модель кадрирования памяти (frame memory).

12. Этапы проектирования фактографических ИС

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

Определение набора представляющих интерес сущностей.

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

Определение атрибутов и наборов их допустимых значений (доменов).

Определение ключей для каждого набора сущностей.

Построение ER-диаграммы, то есть графического представления модели «сущность-связь».

Построение локальных логической модели данных

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

Уточнение и нормализация логической модели;

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

Перенос логической модели данных в среду целевой СУБД

Разработка механизмов защиты данных.

13. Перспективные направления развития фактографических ИС

Выделим три больших направления относительно развития современных фактографических ИС:

Web-технологии

Технологии World Wide Web как платформа для работы с БД;

Технологии БД для работы с World Wide Web;

Хранилища данных

Базы знаний

14. Web-технологии

Основные понятия:

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

Сервисы Интернет - электронная почта, средства проведения конференций, средства удаленного доступа, средства посылки и получения файлов, WWW.

World Wide Web - это гипермедиа система, предоставляющая простые средства типа «укажи и щелкни», используемые для просмотра информации в сети Интернет с помощью механизма гиперссылок.

Intranet [extranet] - это Web-сайт или группа Web-сайтов, принадлежащих одной организации и доступных только ее членам [и санкционированным внешним пользователям].

15. Принципы интеграции технологий БД в среду Web

Технология подключения не должна зависеть от данных и разработчика ПО СУБД

Возможность взаимодействия с БД не зависимо от типа используемого Web-браузера и Web-сервера.

Возможность взаимодействия с БД с использованием «тонкого» клиента.

Возможность защищенного доступа к ценным корпоративным данным.

Высокий уровень производительности программного и аппаратного обеспечения

Минимальный уровень администрирования.

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

Недостатки применения Web-технологий: высокая стоимость, недостаточная надежность, слабая защищенность данных.

Новейшие области применения технологий БД для управления информацией в среде WWW:

Моделирование и запросы в WWW. Задача формулировки запросов для поиска определенных страниц Web с анализом не только содержания страниц, но и структуры связей между ними. Web-сайты в таком случае рассматриваются в виде ориентированного графа, в котором узлами являются страницы, а ребрами - гиперссылки между ними. Для обработки информации по такой модели данных в настоящее время разрабатываются специальные ЯМД (языки запросов). Указанная технология может быть полезна также при анализе целостности сайта (проблемы моделирования).

Выборка и интеграция информации. Некоторые Web-сайты могут рассматриваться как контейнеры структурированных данных (множеств кортежей, множеств объектов и т.д.). Например, сайт Internet Movie Database (http://www.imdb.com/) может рассматриваться как внешний интерфейс базы данных о кинофильмах. В связи с ростом числа таких сайтов становятся актуальными две следующие задачи. Первая задача состоит в том, чтобы фактически осуществлять выборку данных, представленных в структурированном виде (например, множество кортежей) из HTML-страниц, их содержащих. Если мы рассматриваем сайты такого рода как автономные неоднородные базы данных, то возникает вторая задача - формулировка запросов, которые требуют интеграции данных, полученных из разнородных источников.

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

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

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

Проектирование графического представления страниц.

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

16. Хранилища данных

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

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

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

Проблемы ХД: высокие требования к ресурсам, сложности сопровождения и интеграции, проблемы качества данных, владение данными (опасность подкупа сотрудников).

Размещено на Allbest.ru