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

метки: Данные, Проектирование, Сущность, Фактографический, Запись, Модель, Информация, Связь

Фактографические ИС и файловые ИС

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

Основными компонентами фактографических систем являются Базы Данных и системы управления Базами Данных (СУБД).

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

Файловые информационные системы

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

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

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

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

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

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

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

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

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

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

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

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

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

…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... комнатах. Управление серверами осуществляют системные администраторы. 2. Базы данных 2.1 Понятие базы данных (БД) Основы современной информационной технологии составляют базы данных (БД) и системы управления базами данных (СУБД), роль которых ... O bject M odel — модель составных объектов) и др. — Позволяет одним программам выполнять операции над объектами данных используя процедуры других программ. ...

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

Введение

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

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

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

Среди основных возможностей СУБД можно выделить:

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

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

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

Трехуровневая система описания БД включает:

• Внешний уровень;
• Концептуальный уровень;
• Внутренний уровень.

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

Внешний уровень

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

Концептуальный уровень

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

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

Внутренний уровень

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

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

Объектные модели и их применение

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

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

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

Набор сущностей (entity set) — это группа или множество сущностей одного типа. Например, это может быть набор людей, предприятий или праздников. Каждая сущность в наборе имеет свои уникальные атрибуты, которые описывают ее свойства и характеристики.

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

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

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

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

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

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

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

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

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

Как уже говорилось ранее, модель «сущность-связь» стала фактическим стандартом при проведении концептуального моделирования огромного количества фактографических ИС (Баз данных).

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

• Семантическая модель данных Хаммера — МакЛеода (1981);
• Функциональная модель данных Шипмана (1981);

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

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

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

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

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

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

• Иерархическая (hierarchical);
• Сетевая (network);
• Реляционная (relational).

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

Организация данных в иерархической СУБД

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

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

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

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

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

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

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

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

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

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

Реляционная модель данных основана на математической теории отношений. Само название «реляционная» происходит от английского слова «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. По полученному значению найти запись в таблице Отдел.

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

Теперь рассмотрим фундаментальные свойства отношений:

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

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

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

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

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

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

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

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

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

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

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

• Обобщающая модель (unifying model);
• Модель кадрирования памяти (frame memory).

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

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

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

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

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

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

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

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

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

Уточнение и нормализация логической модели являются важными шагами в разработке фактографических информационных систем (ИС).

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

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

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

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

Перспективные направления развития фактографических ИС включают в себя три основных области: Web-технологии, хранилища данных и базы знаний.

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

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

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

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

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

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

Моделирование и запросы в WWW

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

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

Выборка и интеграция информации

Некоторые Web-сайты могут рассматриваться как контейнеры структурированных данных (множеств кортежей, множеств объектов и т.д.).

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

Разработка и реструктуризация Web-сайтов

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

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

Введение

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

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

В данной работе рассматривается концепция хранилищ данных (ХД) как развитие традиционных баз данных (БД).

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

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

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

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

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

Заключение

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

Введение

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

Оперативная база данных

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

Квазипостоянная база данных

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

Подсистемы ХД

Подсистема оперативного анализа данных

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

Подсистема принятия решений

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

Достоинства и проблемы ХД

Достоинства ХД

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

Проблемы ХД

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