Московский государственный университет печати

Чертовской В.Д.


         

Базы и банки данных

Учебное пособие


Чертовской В.Д.
Базы и банки данных
Начало
Печатный оригинал
Об электронном издании
Оглавление

Введение

Часть 1. ОСНОВНЫЕ ПОЛОЖЕНИЯ

Раздел 1. Основные понятия

1.

Глава 1. Общие сведения

1.1.

Данные, информация, знания

1.2.

Основные понятия и определения

1.3.

Классификация БД и СУБД

1.4.

Состав СУБД и работа БД

2.

Глава 2. Концепция баз данных

2.1.

Требования, предъявляемые к базам данных

2.2.

Концепция построения БД

2.3.

Методология проектирования баз данных

2.4.

Методология использования баз данных

Раздел 2. Теория баз данных

3.

Глава 3. Общая теория

3.1.

Модели представления данных

3.2.

CASE-технология

3.3.

CASE-средства

4.

Глава 4. Теория реляционных баз данных

4.1.

Математические основы теории

4.2.

Построение БД

4.3.

Использование БД

4.3.1.

Запросы к данным

4.3.2.

Синхронизация процессов доступа

Часть 2. Централизованные базы данных

Раздел 3. Реализация бд (модели БД)

5.

Глава 5. Реляционные БД SQL

5.1.

Логическая структура

5.2.

Создание БД

5.3.

Использование БД

5.3.1.

Язык SQL

5.3.2.

Язык QBE

6.

Глава 6. Сетевые БД

6.1.

Логическая структура

6.2.

Программная реализация

6.2.1.

Создание БД (ЯОД)

6.2.2.

Использование БД (ЯМД)

7.

Глава 7. Иерархические БД

7.1.

Логическая структура

7.2.

Программная реализация

7.2.1.

Создание БД (ЯОД)

7.2.2.

Использование БД (ЯМД)

8.

Глава 8. Взаимосвязь МД

8.1.

Сравнительная характеристика моделей данных

8.2.

Преобразование моделей данных

8.3.

Выбор моделей данных

9.

Глава 9. Физическая БД

9.1.

Вопросы программной реализации БД

9.2.

Организация хранения и доступ

9.3.

Доступ к данным и их обновление

Раздел 4. Современные направления развития БД

10.

Глава 10. Автоматизация проектирования

10.1.

Классический подход к проектированию

10.1.1.

Однопользовательский режим

10.1.2.

Многопользовательский режим

10.2.

Современный подход к проектированию

10.3.

Автоматизация проектирования

11.

Глава 11. Объектно-ориентированные базы данных

11.1.

Недостатки реляционных баз данных

11.2.

Состояние развития ООБД

11.3.

Сущность ООБД

11.4.

Недостатки и перспективы развития ООБД

Часть 3. Распределенные базы данных (РБД)

Раздел 5. Основы теории РБД

12.

Глава 12. Общая характеристика РБД

12.1.

Новые требования, предъявляемые к БД

12.2.

Состав и работа РБД

12.3.

Система клиент/сервер

Раздел 6. Основы теории РБД

13.

Глава 13. Создание РБД

13.1.

Обеспечение целостности

13.2.

Фрагментация и локализация

13.3.

Процесс интеграции

13.4.

Преобразование структуры и данных

13.5.

Однородные и неоднородные РБД

14.

Глава 14. Использование РБД

14.1.

Одновременный доступ

14.2.

Защита

14.3.

Восстановление РБД

14.4.

Запросы

Заключение

Контрольные вопросы

Литература

Указатели
11  именной указатель
360  предметный указатель
163  указатель иллюстраций
25  указатель компаний

Раздел 2. Теория баз данных

3.
Глава 3. Общая теория

3.1.
Модели представления данных

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

Их можно разделить на две группы:

    1) формальные (математические, скорее теоретические), предполагающие разработку БД только человеком;

    2) математические представления, рассчитанные на автоматизацию процесса проектирования БД («компьютерное представление»).

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

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

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

Описание часто проводят последовательно: структура, ограничения, операции. Начнем поэтому с описания структур данных.

Проще всего структуру (отношение) можно задать таблицей с «плоской» (табл. 1.1)

Таблица 1.1.

Таблица данных о вузе

№_студента №_преподавателя Кафедра Факультет Часовая нагрузка
1 2 3 4 5
Козлов
...
Строков
...
ИиУС
...
ПМТ
...
65
...
или сложной (табл. 1.2)

Таблица 1.2.

Таблица поставок комплектующих

Шифр Название Кол-во в год В том числе по кварталам
54
...
Принтер
...
98
...
40
...
17
...
20
...
21
...
структурой. Однако при таком задании хорошо видны элементы (столбцы, поля), но плохо просматриваются отношения, которые могут быть четырех типов: 1:1, 1:M, M:1, M:N.

Более наглядным (особенно для представления типа 1:1) является представление в виде ориентированного графа (рис. 3.1),Рис. 03.01. Ориентированный граф восходящее к математике, теории автоматического управления и теории информации. Элементами n (n принадлежит N) графа Г(N, U) являются столбцы (поля), а связи между ними определяются дугами u (u принадлежит U). Такому графу соответствует матрица смежности (табл. 3.1)

Таблица 3.1.

Матрица смежности

1 2 3 4 5
1 0 0 1 1 1
2 0 0 0 0 1
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
или двудольный граф. Разновидностью графов являются предложенные Д. Мартином овал-диаграммы (рис. 3.2)Рис. 03.02. Овал-диаграмма.

Теория графов достаточно хорошо развита, однако прямое ее применение для представления данных встречает затруднения, вызванные следующими обстоятельствами;

    1) связи в моделях представления данных относительно просты (рис. 3.1),Рис. 03.01. Ориентированный граф матрицы смежности получаются разреженными, что снижает ценность их использования;

    2) в графах отражается чаще всего один тип связи (например, 1:1): выходом здесь может быть использование овал-диаграмм;

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

Для преодоления третьего затруднения сформировались модели представления данных «сущность - связь» (Entity - Relationship), называемые также «ER-моделями (диаграммами)» или «моделями Чена». Базовыми структурами в ER-модели являются «типы сущностей» и «типы связей».

Отличие типа связи от типа сущности - в установлении зависимости существования реализации одного типа от существования реализации другого. (Например, ЛИЧНОСТЬ - тип сущности, тип СОСТОИТ В БРАКЕ - нет, поскольку реализация последнего типа не существует, если не существует двух личностей. Тип связи может рассматриваться поэтому как агрегат двух или более типов сущностей.)

ER-модель может быть представлена ER-диаграммой (ERD), состоящей из следующих элементов:

Выделяют три типа связи: связь «один к одному» (1:1), связь «один ко многим» (1:M), связь «многие ко многим» (M:N).

Примерами этих связей могут быть:

1:1 М:1 M:N

больной <–-> койка, больной <<–-> палата, больной <<–->> врач.

Следует отметить особенности отображения ER-модели:

    а) рекурсивное множество связей

    б) два множества связей между одними и теми же множествами сущностей

    в) множество n-арных связей, например тернарных

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

Фрагмент концептуальной модели предметной области «Больница» представлен на рис. 3.3,Рис. 03.03. ER-диаграмма предметной области 'Больница' а пример представления атрибутов для конкретного объекта показан на рис. 3.4.Рис. 03.04. Модель БД 'Учебный процесс' Выделяют многозначный атрибут, атрибут множества связей.

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

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

а) ограничение целостности применительно к атрибутам (например, N койки - целое, положительное, число коек - диапазон от 1 до 100);

б) ограничение Е по существованию сущностей (рис. 3.3);Рис. 03.03. ER-диаграмма предметной области 'Больница'

в) ID-зависимость (рис. 3.3): сущность не может быть идентифицирована в ряде случаев по значениям собственных атрибутов.

Покажем свойства этих моделей на примере БД «Учебный процесс» в институте (рис. 3.4).Рис. 03.04. Модель БД 'Учебный процесс' Укрупненно (и в несколько другом начертании, чем на рис. 3.3)Рис. 03.03. ER-диаграмма предметной области 'Больница' он может быть представлен в виде отношений трех групп атрибутов (рис. 3.4, а)Рис. 03.04. Модель БД 'Учебный процесс' со связями M:N и 1:M. Поскольку группы 1 и 3 - множества, схему можно представить в виде рис. 3.4, б.Рис. 03.04. Модель БД 'Учебный процесс' Известно, что ни одна модель данных не может реализовать отношения M:N. В связи с этим схема связей - после преобразования - окончательно выглядит так, как показано на рис. 3.4, в.Рис. 03.04. Модель БД 'Учебный процесс'

Заметим, что перечисленные методы:

    1) слабо ориентированы на использование компьютеров в проектировании БД;

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

    3) отражают потоки данных не системно.

Перечисленным требованиям отвечает CASE-технологияссылка на источники литературы, система методов которой приведена на рис. 3.5.Рис. 03.05. Классификация CASE-методов: А - элементов много; Б - описание элементов; DFD - Data Flow Diagramm; ERD - Entry Relationship Diagramm; STD - State Transaction Diagramm

3.2.
CASE-технология

С переходом в автоматизированных системах к задаче автоматизации управления возникла необходимость в системном описании процесса управления, включая и принятие решений. Одними из первых моделей в этом направленииссылка на источники литературы были форрестеровские модели . Позднее появилась методология автоматизации (Structures Analysis Design Technique) SADT .

Модельными компонентами CASE-технологияCASE-технологии (рис. 3.5)Рис. 03.05. Классификация CASE-методов: А - элементов много; Б - описание элементов; DFD - Data Flow Diagramm; ERD - Entry Relationship Diagramm; STD - State Transaction Diagramm являются составляющие ERD, DFD, STD. Их место в системном описании процесса управления показано на рис. 3.6.Рис. 03.06. Описание процессов в системе

CASE-технология представляет собой систему методов описания (рис. 3.5),Рис. 03.05. Классификация CASE-методов: А - элементов много; Б - описание элементов; DFD - Data Flow Diagramm; ERD - Entry Relationship Diagramm; STD - State Transaction Diagramm рассчитанную на использование компьютеров при создании БД. Computer-Aided Software/System (CASE-технология) - совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддержанная комплексом взаимосвязанных средств автоматизации. CASE - инструмент для системных аналитиков, разработчиков и программистов.

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

Они дополняются следующими принципами.

  1. Принцип абстрагирования от несущественных деталей (с их «упрятыванием») с контролем на присутствие лишних элементов.

  2. Принцип формализации.

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

  4. Принцип непротиворечивости - обоснование и согласованность элементов.

  5. Принцип логической и физической независимости данных.

  6. Принцип непосредственного доступа (без программирования) конечного пользователя.

Эта технология положена в основу реализации программных CASE-средстваCASE-средств.

Формальным инструментом описания является система диаграмм рис. 3.5:Рис. 03.05. Классификация CASE-методов: А - элементов много; Б - описание элементов; DFD - Data Flow Diagramm; ERD - Entry Relationship Diagramm; STD - State Transaction Diagramm ER-диаграмм (ERD), диаграмм потоков данных (DFD), диаграмм переходов состояний (STD), спецификаций процесса, - которые обсудим отдельно.

В описании процессов возможны два случая.

  1. Сложные процессы.

  2. Процессы простые.

А. Сложные процессы.

ER-диаграммаER-диаграммы. Из рис. 3.5Рис. 03.05. Классификация CASE-методов: А - элементов много; Б - описание элементов; DFD - Data Flow Diagramm; ERD - Entry Relationship Diagramm; STD - State Transaction Diagramm видно, что фактически первой разновидностью методов системы CASE-моделей явились ER-модели Чен К.Чена, подробно рассмотренные в предыдущем параграфе. Здесь укажем лишь на ее разновидность - модель Баркер М.Баркера (рис. 3.7).Рис. 03.07. Нотация Баркера В ней указываются имя сущности, степень множественности (например, 1:М), обязательность (–––-) или необязательность (...........) связи.

DF-диаграммаDF-диаграммы. Диаграммы применяются для отображения процессов вход-выход. Первоначально использовалась методология SADT, о которой говорилось ранее, затем перешли на схемы DFD. Используются две основные разновидности нотаций: Иордана-Демарко и Гейна-Сарсона. Различия между ними невелики и потому используем нотацию Гейна-Сарсона. В нотации используются символы, снабженные именами.

Хранилище базы данныхХранилище (та или иная часть БД) - данные, хранимые в памяти. Внешняя сущность базы данныхВнешняя сущность - это источник или приемник данных.

DFD строится на основе декомпозиции, и модель верхнего уровня называют контекстной диаграммой. В любом конкретном проекте она одна. Такие модели описывают объект управления, а для отражения управляющей части (УЧ) системы применяютссылка на источники литературы расширение реального времени: перечисленные обозначения рисуются пунктирными линиями или точками. Основными типами управляющих потоков являются Т-поток (триггер), А-поток (процесс непрерывен, пока поток не выключится), E/D-поток (аналог выключателя с двумя кнопками «включено» и «выключено»).

Для иллюстрации использования диаграмм приведем сначала словесное описание процесса.

Пример 3.1. Словесная модель процесса распределения товаров по заказам.

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

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

Если заказ принят, то определяется наличие товаров на складе.

Если товар есть, то выписывается предъявляемый заказчику счет к оплате, после которой товар отправляется заказчику.

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

Контекстная диаграмма Гейна-Сарсона представлена на рис. 3.8:Рис. 03.08. Контекстная диаграмма процесса распределения товаров по заказам она позволяет видеть входные и выходные потоки. Детализированная диаграмма рассматриваемого процесса может быть представлена в виде, показанном на рис. 3.9,Рис. 03.09. Детализированная диаграмма распределения товара по заказам при этом в общем случае каждый из процессов 1 - 3, в свою очередь, может быть детализирован. Расширенная диаграмма отображена на рис. 3.10.Рис. 03.10. Расширенная диаграмма распределения товаров по заказам Алгоритм выработки решений показан в более знакомом виде на рис. 3.11,Рис. 03.11. Алгоритм процесса распределения товаров по заказам: А - заказ не отвечает номенклатуре; Б - заказ оформлен неверно; В - товар на складе есть а соответствующая форрестеровская модельссылка на источники литературы процесса - на рис. 3.12.Рис. 03.12. Форрестеровская модель процесса распределения товаров по заказам: ОУ - объект управления; УЧ - управляющая часть системы; А - деньги есть; Б - товар на складе есть; В - заказ оформлен правильно; Г - заказ отвечает номенклатуре; Д - счет оплачен

Рис. 3.8 - 3.11Рис. 03.08. Контекстная диаграмма процесса распределения товаров по заказамРис. 03.09. Детализированная диаграмма распределения товара по заказамРис. 03.10. Расширенная диаграмма распределения товаров по заказамРис. 03.11. Алгоритм процесса распределения товаров по заказам: А - заказ не отвечает номенклатуре; Б - заказ оформлен неверно; В - товар на складе есть позволяют заметить, что потоки имеют пояснения. Текстовые средства моделирования получили название словаря данных. В форме Бэкуса-Наура (БНФ) его фрагмент представлен на рис. 3.13.Рис. 03.13. Фрагмент словаря данных

ST-диаграмма. Она используется для отображения процесса выработки и результатов реализации решений. Вводится понятие «состояние». Схематика (схема переходов) может быть такой, как показано на рис. 3.14.Рис. 03.14. STD для процесса распределения товаров по заказам Процесс изменения состояния может быть отражен с помощью таблицы

Текущее состояние    Условие    Действие    Следующее состояние
Начальное состояние Активизируется каждый раз    
ОЖИДАНИЕ Заказ Получить заказ ОБРАБОТKА
ОБРАБОТKА Заказ не отвечает номенклатуре Аннулировать заказ ОЖИДАНИЕ
ОБРАБОТKА Заказ обеспечен складскими запасами Реализация заказа ОЖИДАНИЕ
ОБРАБОТKА Заказ не обеспечен складскими запасами Заявка на товар ОЖИДАНИЕ
Условие Состояние   Заказ        Заказ не отвечает номенклатуре Заказ обеспечен складскими запасами    Заказ не обеспечен складскими запасами
Начальное состояние Активизируется каждый раз        
ОЖИДАНИЕ  
Получить заказ
ОБРАБОТKА
     
ОБРАБОТKА    
Аннулировать заказ
ОЖИДАНИЕ
   
ОБРАБОТKА      
Реализация заказа
ОЖИДАНИЕ
 
ОБРАБОТKА        
Заявка на товар
ОЖИДАНИЕ

Рассмотренный аппарат используется для масштабных процессов. Для простых процессов он существенно упрощен (рис. 3.5).Рис. 03.05. Классификация CASE-методов: А - элементов много; Б - описание элементов; DFD - Data Flow Diagramm; ERD - Entry Relationship Diagramm; STD - State Transaction Diagramm

Б. Процессы простые

В этом случае системной основой является спецификация процесса, содержащая номер, имя процесса, список входных и выходных данных и тело (описание, алгоритм) процесса. Тело можно описать (рис. 3.5)Рис. 03.05. Классификация CASE-методов: А - элементов много; Б - описание элементов; DFD - Data Flow Diagramm; ERD - Entry Relationship Diagramm; STD - State Transaction Diagramm структурированным языком, визуальным языком, формальными компьютерными языками. Спецификация процесса (рис. 3.9)Рис. 03.09. Детализированная диаграмма распределения товара по заказам может иметь такой вид:

ВХОД=ЗАКАЗ

ВЫХОД=ЗАКАЗ АННУЛИРОВАН

ВЫХОД=ЗАКАЗ ПРИНЯТ

СПЕЦ. ПРОЦЕСС 1

ВЫПОЛНИТЬ ПОЛУЧИТЬ ЗАКАЗ

ДО_ТЕХ_ПОР_ПОКА ЗАКАЗ_ОТСОРТИРОВАН

КОНЕЦ_ВЫПОЛНИТЬ

ВЫПОЛНИТЬ установить флаг ЗАКАЗ АННУЛИРОВАН, если он не соответствует номенклатуре

ВЫПОЛНИТЬ установить флаг ЗАКАЗ АННУЛИРОВАН, если он неверно оформлен

ВЫПОЛНИТЬ установить флаг ЗАКАЗ ПРИНЯТ, если он соответствует номенклатуре

КОНЕЦ_ВЫПОЛНИТЬ

КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.

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

Таблицы решений чаще всего задаются по схеме ЕСЛИ ..., ТО... и могут быть отражены в виде деревьев решений (Сi - условие).

Продвинутой разновидностью Flow-форм является диаграмма Несси-Шнейдера.

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

Далее речь пойдет о сложных процессах.

После освещения деталей CASE-технологии вернемся к системному аспекту.

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

  1. По шкалам Software Engineerig (SE) и Information Engineerig (IE). Первая шкала предназначена для проектирования программного обеспечения и хорошо известна - фактически описана в данной работе, вторая - новая, с более широкой областью применения (для проектирования не только программного обеспечения).

  2. По порядку построения модели:

    а) процедурно-ориентированный (современный подход);

    б) ориентированный на данные (традиционный подход).

  3. По типу целевых систем - для систем реального времени (управление сложными структурами большого объема данных с интенсивным вводом-выводом) и информационных систем (управление событиями с малым количеством простых по структуре данных с интенсивными вычислениями).

3.3.
CASE-средства

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

Интегрированный пакет CASE-средств содержит 4 основных компонента.

  1. Средства централизованного хранения информации о всем проекте (своеобразная база данных проекта).

  2. Средства ввода данных для хранения.

  3. Средства анализа, проектирования и разработки.

  4. Средства вывода.

Для CASE-технологии (сокращенно - CASE) характерны четыре основных типа графических диаграмм:

    1) функциональное проектирование (DFD);

    2) моделирование данных (ERD);

    3) моделирование поведения (STD);

    4) структурные диаграммы (карты) - отношения между модулями и внутри- модульная структура.

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

  1. По категориям. Выделяют уровень интеграции: вспомогательные программы (tools); пакеты(toolkit); инструментальные средства (workbench, АРМ).

  2. По функциональному признаку.

Для анализа и проектирования возможно использовать CASE-аналитик (единственное отечественное средство первой генерации), Application Development Workbench, Easy CASE System Designer.

Проектирование БД существенно упрощается при применении ERWin (фирма Logic WorksLogic Works), Designer/2000 (OracleOracle), позволяющих проводить логическое моделирование данных, автоматическое преобразование данных в ЗНФ.

Программирование (кодогенерирование) - DECACE (DECDEC), Delphi (BorlandBorland).

Сопровождение (поддержка системной документации) и реинжиниринг (анализ, корректировка, реинжиниринг существующей системы) - SuperStructure (Computer Data SystemComputer Data System).

Управление проектом (планирование, контроль, взаимодействие) - Project Workbench (Applied Bisiness TechnologyApplied Business Technology).

Рассмотрим одну из реальных систем автоматизации проектирования БД в рамках Oracle (Cooperative Development Environment - CDE), в которую входят CASE*Dictionary, CASE*Designer, CASE*Generator.

CASE*Dictionary - хранилище информации (БД проекта). CASE*Designer - средство моделирования процессов и данных в системе через внешний интерфейс с помощью средств графического моделирования. CASE*Designer полностью интегрирован с CASE*Dictionary. CASE*Generator - на основе информации CASE*Designer автоматически генерирует модули программного кода (меню, формы, отчеты). CASE*Generator может генерировать и DLL-сценарии (таблицы, представления, индексы, последовательности) в схеме приложения.

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

Application Development Workbench (разработка систем на многих платформах) - компания Knowledge WarKnowledgeWare;

Easy CASE System Designer (графическое инструментальное средство проектирования, позволяющее генерировать схемы приложения для одной или нескольких СУБД, включая Oracle) - компания Evergreen CASE ToolsEvergreen CASE Tools;

ERWin/ERX (средство проектирования БД для MS Windows) - компания Logic WorksLogic Works;

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

© Центр дистанционного образования МГУП