http://www.relcom.ru/Internet/Literature/index.html 3 страница

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

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

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

Примерами зарубежных реляционных СУБД для ПЭВМ являются следующие: DBaseIII Plus и dBase IY (фирма Ashton-Tate), DB2 (IBM), R:BASE (Microrim), FoxFro ранних версий и EoxBase (Fox Software), Раrаdох и dBASE for Windows (Borland), FoxFro более поздних версий, Visual FoxFro и Access (Microsoft), Clarion (Clarion Software), Ingres (ASK Computer Systems) и Oracle (Oracle).

К отечественным СУБД реляционного типа относятся системы: ПАЛЬМА (ИК АН УССР), а также система HyTech (МИФИ).

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

119 Назначение и компоненты хранилища данных

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

– поддержка высокой скорости данных из хранилища;

– поддержка внутренней непротиворечивости данных;

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

– наличие удобных утилит просмотра данных хранилища;

– полнота и достоверность хранимых данных;

– поддержка качественного процесса пополнения данных.

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

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

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

– средств переноса и трансформации данных;

– метаданных – включают каталог хранилища и правила преобразования данных при загрузке их из оперативных баз данных;

– реляционного хранилища;

– OLAP хранилища;

– средств доступа и анализа данных.

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

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

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

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

132 Характеристика CASE-средств и CASE-технологий. Примеры

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

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

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

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

методология (MethodDiagrams), которая задает единый графический язык и правила работы с ним.

графические редакторы (GraphicEditors), которые помогают рисовать диаграммы; возникли с распространением PC и GUI, так называемых «uppercase технологий

генератор: по графическому представлению модели можно сгенерировать исходный код для различных платформ (так называемая lowcase часть CASE-технологии).

репозиторий, своеобразная база данных для хранения результатов работы программистов. [11]

^ 3. Внедрение CASE-технологий.

Приведенная в данном разделе технология базируется в основном на стандартах IEEE [16,17] (IEEE - Institute of Electrical and Electronics Engineers - Институт инженеров по электротехнике и электронике). Термин «внедрение» используется в широком смысле и включает все действия от оценки первоначальных потребностей до полномасштабного использования CASE-средств в различных подразделениях организации-пользователя. Процесс внедрения CASE-средств состоит из следующих этапов:

определение потребностей в CASE-средствах;

оценка и выбор CASE-средств;

выполнение пилотного проекта;

практическое внедрение CASE-средств. [6]

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

На способ внедрения CASE-средств может повлиять специфика конкретной ситуации. Например, если заказчик предпочитает конкретное средство, или оно оговаривается требованиями контракта, этапы внедрения должны соответствовать такому предопределенному выбору. В иных ситуациях относительная простота или сложность средства, степень согласованности или конфликтности с существующими в организации процессами, требуемая степень интеграции с другими средствами, опыт и квалификация пользователей могут привести к внесению соответствующих корректив в процесс внедрения. [3]

95. Основные показатели оценки качества программы

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

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

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

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

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

Занимаемая память - объем ОЗУ (кбайт, Мбайт) и объем ВЗУ, необходимых для функционирования программы.

Надежность программы определяется надежностью ее составляющих:

- алгоритмическая (вычислительная) надежность:

- информационная надежность:

- надежность программного обеспечения;

- надежность аппаратная.

Рассмотрим кратко отдельные составляющие надежности программ.

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

Информационная надежность предусматривает:

- способность алгоритма или программы правильно выполнять свои функции при различных ошибках в исходных данных;

- способность информационной системы обеспечивать целостность хранящихся в ней данных;

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

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

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

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

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

118 Основные средства разработки БД

ER-модели широко используются в практике создания БД. Они применяются при ручном и автоматизированном проектировании с использованием CASE-средств, поддерживающих весь цикл разработки СБД или отдельные его стадии. Ктаким средствам относятся: ProKit*WORKBENCH, Design / IDEF, CASE Oracle (Designer / 2000), Power Designer (S-Designor), ERWin, SILVERRUN, ERStudio и другие. CASE-средства являются сравнительно новым направлением в информационных технологиях. Первая версия инструментария Oracle появилась в 1989 г.

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

При сравнении CASE-систем кроме используемой методологии ER-моделирования, необходимо учитывать специфические критерии, связанные с реализацией функций автоматизированного проектирования:

· число и перечень поддерживаемых целевых СУБД;

· поддержку распределенных БД;

· поддержку коллективной работы при проектировании (управление правами пользователей, ведение репозитория и т. д.);

· построение концептуальной ER-модели по описанию структуры существующей БД – реверс-инжиниринг;

· автоматизируемые функции проектирования и степень их автоматизации;

· качество и жесткость проектных решений (возможность выбора из нескольких альтернативных решений, возможность ручного вмешательства в процесс);

· надежность работы;

· документирование проекта;

· открытость системы (возможность стыковки с другими средствами);

· удобство графического редактора;

· количественные ограничения (общее число сущностей, число уровней вложенности для обобщенной сущности и др.);

· возможность автоматической оценки объема памяти для проектируемой БД;

· возможность автоматической генерации процедур;

· наличие средств моделирования хранилищ данных;

· требования к ресурсам компьютера;

· операционную среду;

· стоимость системы.

CASE-средства показывают модель с разной степенью детализации:

· только обозначения сущностей и связей между ними;

· сущности + ключи;

· сущности + ключи + внешние ключи;

· сущности + все атрибуты.

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

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

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

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

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

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

122 Характеристика сетевой модели данных. Примеры

Сетевая модель данных позволяет отображать разнообразные взаимосвязи элементов данных в виде произвольного графа, обобщая тем самым иерархическую модель данных (рис. 4.). Наиболее полно концепция сетевых БД впервые была изложена в Предложениях группы КОДАСИЛ (KODASYL). (см. Приложение рис.4.) Для описания схемы сетевой БД используется две группы типов: «запись» и «связь». Тип «связь» определяется для двух типов «запись»: предка и потомка. Переменная типа «связь» являются экземплярами связей. Сетевая БД состоит из набора записей и набора соответствующих связей. На формирование связи особых ограничений не накладывается. Если в иерархических структурах запись-потомок могла иметь только одну запись-предка, то в сетевой модели данных запись-потомок может иметь произвольное число записей-предков (сводных родителей). Пример схемы простейшей сетевой БД показан на рис.5. Типы связей здесь обозначены надписями на соединяющих типы записей линиях. (см. Приложение рис.5.) B различных СУБД сетевого типа для обозначения одинаковых по сути понятий зачастую используются различные термины. Например, такие как элементы и агрегаты данных, записи, наборы, области и т. д.

Физическое размещение данных в базах сетевого типа может быть организовано практически теми же методами, что и в иерархических базах данных.

K числу важнейших операций манипулирования данными баз сетевого типа можно отнести следующие:

поиск записи в БД;

переход от предка к первому потомку;

переход от потомка к предку;

создание новой записи;

удаление текущей записи;

обновление текущей записи;

включение записи в связь;

исключение записи из связи;

изменение связей и т. д.

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

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

Системы на основе сетевой модели не получили широкого распространения на практике. Наиболее известными сетевыми СУБД являются следующие: IDMS, db_VistaIII, СЕТЬ, СЕТОР и КОМПАС.

Пример сетевой модели данных

121 Достоинства и недостатки объектно-ориентированной модели представления данных. Примеры

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

Стандартизированная объектно-ориентированная модель описана в рекомендациях стандарта ODMG -93 (Object Database Management Group – группа управления объектно-ориентированными базами данных).

Рассмотрим упрощенную модель объектно-ориентированной БД. Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом или типом, конструируемым пользователем (определяется как class). Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связн ую ие рархию объектов. Пример логической структуры объектно-ориентированной БД библиотечного дела приведен на рис. 2.9. Здесь объект типа Библиотека является родительским для объектов-экземпляров классов Абонент, Каталог и Выдача. Различные объекты типа Книг а могут иметь одного или разных родителей. Объекты типа Книга, имеющие одного и того же родителя, должны различаться, по крайней мере, инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isb n, удк, названи е и автор.

Логическая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД. Основное различие между ними состоит в методах манипулирования данными.

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

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

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа Книга, являющимся потомками объекта типа Каталог, можно приписать свойства объекта-родителя: isbn, удк, название и автор. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств билет и номер в объекте Библиотека приводит к наследованию этих свой ств вс еми дочерними объектами Абонент, Книга и Выдач а. Не случайно, поэтому значения свойства билет классов Абонент и Выдача, показанных на рис. 2.9, являются одинаковыми – 00015.

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

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

97 Ресурсы вычислительной системы. Управление ресурсами

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

ВИДЫ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ

В зависимости от ряда признаков различают следующие вычислительные системы (ВС):

однопрограммные и многопрограммные (в зависимости от количества программ, одновременно находящихся в оперативной памяти);

индивидуального и коллективного пользования (в зависимости от числа пользователей, которые одновременно могут использовать ресурсы ВС);

с пакетной обработкой и разделением времени (в зависимости от организации и обработки заданий);

однопроцессорные, многопроцессорные и многомашинные (в зависимости от числа процессоров);

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

работающие или не работающие в режиме реального времени (в зависимости от соотношения скоростей поступления задач в ВС и их решения);

универсальные, специализированные и проблемно-ориентированные (в зависимости от назначения).

РЕЖИМЫ РАБОТЫ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ

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

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

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

Однопрограммный режим работы вычислительной системы (ВС)
Аппаратные средства ЭВМ совместно с программным обеспечением образуют ВС. В зависимости от класса ЭВМ и вида операционной системы ВС могут работать в режимах однопрограммном и мультипрограммном.

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

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

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

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

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

Режим пакетной обработки

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

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

Режим коллективного доступа

125 Общая характеристика языков запросов БД. Примеры

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