Лекция: 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. Основные показатели оценки качества программы
Качество программ — это определенная совокупность свойств программного продукта, обеспечивающих решение возложенных на него задач в заданной среде функционирования и с допустимым множеством исходных данных.
Показателями качества являются надежность (безошибочность, включая и экстремальные, нестандартные условия выполнения), модифицируемость (легкость доработки и разбиения на модули), мобильность (настройка на новые условия, перенос на другую ЭВМ с минимальными затратами), дружественность интерфейса между ЭВМ и пользователем, занимаемый объем памяти, качество документации, подробность документирования самой программы.
Надежность программы является наиболее важным критерием качества программы в целом.
Модифицируемость программы — функциональное разбиение программы на автономные модули (модульное программирование), возможность доработки (изменения) содержания модулей.
Переносимость — легкость адаптации к изменению среды, т.е. компонентов программирования, возможность переноса программы из одной операционной системы в другую.
Занимаемая память — объем ОЗУ (кбайт, Мбайт) и объем ВЗУ, необходимых для функционирования программы.
Надежность программы определяется надежностью ее составляющих:
— алгоритмическая (вычислительная) надежность:
— информационная надежность:
— надежность программного обеспечения;
— надежность аппаратная.
Рассмотрим кратко отдельные составляющие надежности программ.
Алгоритмическая (вычислительная) надежность — способность программы выполнять свои функции при изменении условий функционирования.
Информационная надежность предусматривает:
— способность алгоритма или программы правильно выполнять свои функции при различных ошибках в исходных данных;
— способность информационной системы обеспечивать целостность хранящихся в ней данных;
— способность алгоритма и программы нормально функционировать в случае неправильных действий пользователя при вводе информации.
Надежность программного обеспечения — это характеристика способности программного обеспечения выполнять возложенные на него функции при поступлении требований на их выполнение, показатель качества, характеризующий свойства программного изделия выдавать одни и те же результаты при различных условиях функционирования.
При рассмотрении вопроса надежности программ следует учитывать тот факт, что надежность и правильность программ — не одно и то же. Правильность программы — это отсутствие в программе, разработанной по заданному алгоритму, программных ошибок. Надежность программы — более широкое понятие.
Надежность — это способность программ давать разумные результаты при всех возможных данных и действиях, в частности, в аномальных условиях. Если в программу вводят необычные данные, они должны быть выявлены и отброшены. Должны выявляться ошибки программы, ошибки данных, к которым следует добавить проблему предельных случаев и возможные ошибки аппаратуры.
Рассмотрение всех составляющих качества программ является очень сложной и объемной задачей. Поэтому мы ограничимся только теми показателями качества программ, которые зависят от разработчика (программиста).