BPWin и ERWin компании LogicWorks.

LogickWorks выпускает два взаимнодополняющих инструмента проектирования информационных систем:

• BPWin - функциональное моделирование на основе методологии IDEF0. Допускается также использовние нотации IDEF3 и DFD в нотации Йордона - ДеМарко. Имеется возможность экспорта построенных моделей в системы функционально-стоимостного анализа (ABC - Activity Based Costing) и информационного моделирования ERWin.
• ERWin - средство информационного моделирования, используется нотация IDEF1X. Поддерживаются свыше 20 целевых СУБД, имеется возможность генерации прототипов прикладных программ для Visual Basic, Delphi и т.д.

Designer/2000 компании Oracle.

Данный продукт компании Oracle, возможно, наиболее полно поддерживает все этапы создания приложений обработки данных. Однако, следует оговориться, что, в отличие от других средств, он поддерживает практически одну целевую СУБД - Oracle Server (имеется еще возможность генерации скриптов на ANSI SQL). То же самое касается и средств создания пользовательсокго интерфейса. Хотя возможна генерация прототипов программ для языков Visual Basic, C, Java, полностью все возможности Designer/2000 реализуются только при использовании его вместе со средством разработки Oracle Developer/2000.

В состав Oracle Designer/2000 включены следующие модули:

• инструментарий анализа предметной области:
• Process Modeler - средство анализа деловой активности организации. Позволяет создать модель структуры органнизации и привязать к этой модели функции, выполняемые в различных подразделениях, и информационные потоки между функциями. Содержит элементы бизнес-анализа.
• Dataflow Diagrammer - в этом инструменте на базе DFD - диаграм детализуются функции, описаные в Process Modeler. Используется нотация Йордона - Де Марко.
• Function Hierarchy Diagrammer - этот модуль автоматически выстраивает иерархии функций, определенных в двух предыдущих инструментах, имеется также возможность создавать прототипы функций.
• Entity Relationships Diagrammer - инструмент моделирования данных (диаграмы " сущность-связь" ), которыми оперируют функции, определенные в Dataflow Diagrammer. Используется нотация Баркера.
• Matrix Diagrammer - инструмент для исследования связей между функциями и данными.
• генераторы структур:
• Database Wizard - генерирует реляционные структуры из ER-диаграм.
• Application Wizard - генерирует иерархию программных модулей конечного приложения обработки данных на основе иерархии функций. При этом может одновременно генерироваться несколько взаимосвязанных подсистем для различных подразделений одной организации. Во время генерации автоматически обнаруживаются одинаковые с точки зрения использования информационных объектов функции, которые согут быть объединены в одном модуле.
• инструментарий проектирования приложения:
• Data Diagrammer - инструмент для доработки реляционных структур данных на основе нотации Баркера
• Module Structure Diagrammer - инструмент для управления структурой программных модулей готового приложения. Здесь определяются типы модулей (меню, экранная форма, отчет) и их иерархии вызовов.
• Module Data Diagrammer - средство для проектирования экранного интерфейса программного модуля на основе используемых им данных. Позволяет без программирования весьма гибко управлять внешним видом и поведением генерируемого модуля.
• генераторы данных и кода:
• Server Generator - генерирует базу данных на основе реляционных моделей.
• генераторы кода - на основе моделей, построенных в Module Data Diagrammer, позволяет создать исходный код для Visual Basic, C, Java а также инструментов среды Oracle Developer/2000 (Oracle Forms, Oracle Reports). В последнем случае возможна циклическая доработка приложения: в сгенерированный прототип приложения в Developer/2000 вносятся изменения, которые видны для Designer/2000 и не теряются при повторной перегенерации.
• Preferences Navigator - средство управления предпочтениями при генерации программных модулей. Плзволяет устанавливать многочисленные опции (например, внешний вид элементов экранного интерфейса) как для проекта в целом, так и для каждого модуля в отдельности.

Также в Oracle Designer/2000 имеется ряд других инструментов: утилита для интерактивного выполнения SQL-запросов, средства управления проектом и т.д.

Направления развития БД.

Ограничения реляционных баз данных.

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

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

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

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

Постреляционные СУБД.

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

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: