|
|
|
содержание .. 32 33 34 35 ..
:
&:#*%)K* :(*AK & +($5(!%%)$
-
%*#$A&
F
*:,&* ,$%+@*,:K
:!+(
5
@!"!
5
вания
к
быстродействию
средств
обмена
(
полагают
,
что
СУБД
должна
работать
со
скоростью
обра
-
ботки
тысяч
сущностей
в
секунду
).
3.
В
САПР
проблема
целостности
данных
оказывается
более
трудной
для
решения
,
чем
в
боль
-
шинстве
других
систем
,
поскольку
проектирование
является
процессом
взаимодействия
многих
про
-
ектировщиков
,
которые
не
только
считывают
данные
,
но
и
изменяют
их
,
причем
в
значительной
мере
работают
параллельно
.
Из
этого
факта
вытекают
следствия
:
во
-
первых
,
итерационный
характер
про
-
ектирования
обычно
приводит
к
наличию
по
каждой
части
проекта
нескольких
версий
,
любая
из
них
может
быть
принята
в
дальнейшем
в
качестве
основной
,
поэтому
нужно
хранить
все
версии
с
возмож
-
ностью
возврата
к
любой
из
них
;
во
-
вторых
,
нельзя
допускать
использования
неутвержденных
дан
-
ных
,
поэтому
проектировщики
должны
иметь
свое
рабочее
пространство
в
памяти
и
работать
в
нем
автономно
,
а
моменты
внесения
изменений
в
общую
БД
должны
быть
согласованными
и
не
порож
-
дать
для
других
пользователей
неопределенности
данных
.
4.
Транзакции
могут
быть
длительными
и
трудоемкими
.
?")*6)%=’$;
называют
последователь
-
ность
операций
по
удовлетворению
запроса
.
В
САПР
внесение
изменений
в
некоторую
часть
проек
-
та
может
вызвать
довольно
длинную
и
разветвленную
сеть
изменений
в
других
его
частях
из
-
за
суще
-
ственной
взаимозависимости
компонентов
проекта
(
многошаговость
реализации
запросов
).
В
частно
-
сти
,
транзакции
могут
включать
в
себя
такие
трудоемкие
операции
,
как
верификация
проектного
ре
-
шения
с
помощью
математического
моделирования
.
В
результате
транзакции
могут
длиться
даже
не
-
сколько
часов
и
более
.
Одна
из
трудностей
заключается
в
отображении
взаимозависимости
(
ассоциа
-
тивности
)
данных
.
При
хранении
компонентов
проекта
во
внешней
памяти
затраты
времени
на
обра
-
ботку
запросов
оказываются
значительно
выше
,
чем
в
большинстве
других
автоматизированных
сис
-
тем
,
с
менее
выраженными
взаимозависимостями
данных
.
5.
Иерархическая
структура
проектных
данных
и
,
следовательно
,
отражение
наследования
в
це
-
лях
сокращения
объема
базы
данных
.
В
определенной
мере
названные
особенности
учитываются
в
СУБД
третьего
поколения
,
в
кото
-
рых
стали
применяться
черты
объектно
-
ориентированных
(
объектных
)
СУБД
.
В
них
наборы
данных
,
характеризующих
состояние
предметной
области
(
состояние
проекта
в
случае
САПР
),
помещаются
в
отдельные
файлы
.
Интерпретация
семантики
данных
осуществляется
с
помощью
специальных
про
-
цедур
(
методов
),
сопровождающих
наборы
.
Наследование
свойств
объектов
предметной
области
вы
-
ражается
с
помощью
введения
категорий
класса
,
надкласса
,
подкласса
.
Информационные
модели
при
-
ложений
для
таких
СУБД
разрабатываются
на
основе
методик
типа
IDEF
1
X.
Объектные
БД
выгодны
,
во
-
первых
,
тем
,
что
данные
по
конкретным
объектам
проектирования
не
разбросаны
по
множеству
таблиц
,
как
это
имеет
место
в
реляционных
БД
,
а
сосредоточены
в
оп
-
ределенных
местах
.
Во
-
вторых
,
для
каждого
объекта
могут
быть
назначены
свои
типы
данных
.
В
ре
-
зультате
проще
решаются
задачи
управления
и
удовлетворения
запросов
.
Наряду
с
чисто
объектными
СУБД
(pure ODBMS),
применяют
СУБД
объектно
-
реляционные
.
В
последних
происходит
объединение
свойств
реляционных
и
объектно
-
ориентированных
СУБД
:
объ
-
ектно
-
ориентированная
СУБД
снабжается
непроцедурным
языком
запросов
или
в
реляционную
СУБД
вводятся
наследование
свойств
и
классы
.
Непроцедурность
входного
языка
обеспечивается
ис
-
пользованием
языка
SQL.
Его
операторы
непосредственно
включаются
в
программы
на
языке
С
.
Воз
-
можно
написание
дополнительных
программ
,
интерпретирующих
SQL-
запросы
.
Отличительные
особенности
СУБД
третьего
поколения
:
расширенный
набор
возможных
типов
данных
(
это
абстрактные
типы
,
массивы
,
множества
,
записи
,
композиции
разных
типов
,
отображение
величин
с
значениями
разных
типов
),
открытость
(
доступность
из
разных
языков
программирования
,
возможность
обращения
к
прикладным
системам
из
СУБД
),
непроцедурность
языка
(
общепринятым
становится
язык
запросов
SQL),
управление
асинхронными
параллельными
процессами
,
состояние
которых
отражает
БД
.
Последнее
свойство
позволяет
говорить
о
тесной
взаимосвязи
СУБД
и
подсис
-
темы
управления
проектами
DesPM.
Названные
особенности
управления
данными
в
САПР
нашли
свое
выражение
в
современных
подсистемах
управления
проектными
данными
PDM.
В
PDM
разнообразие
типов
проектных
данных
поддерживается
их
классификацией
и
соответст
-
&
.
+
.
)
"#$%!#&’&($"!))$* +($*,#&($"!)&*
135
:
&:#*%)K* :(*AK & +($5(!%%)$
-
%*#$A&
F
*:,&* ,$%+@*,:K
:!+(
5
@!"!
5
вующим
выделением
групп
с
характерными
множествами
атрибутов
.
Такими
группами
данных
явля
-
ются
описания
изделий
с
различных
точек
зрения
(
аспекты
).
Для
большинства
САПР
машинострое
-
ния
характерными
аспектами
являются
свойства
компонентов
и
сборок
(
эти
сведения
называют
Bill
of materials — BOM),
модели
и
их
документальное
выражение
(
основными
примерами
могут
служить
чертежи
, 3
D
модели
визуализации
,
сеточные
представления
для
конечно
-
элементого
анализа
,
тексто
-
вые
описания
),
структура
изделий
,
отражающая
взаимосвязи
между
компонентами
и
сборками
и
их
описаниями
в
разных
группах
.
Вследствие
большого
объема
проектных
данных
и
наличия
ряда
версий
проектов
PDM
должна
обладать
развитой
системой
поиска
нужных
данных
по
различным
критериям
.
Рассмотренные
особенности
банков
данных
в
САПР
позволяют
квалифицировать
их
как
систе
-
мы
Data Warehouse (DW),
т
.
е
.
хранилища
данных
.
Для
хранилищ
данных
характерен
ряд
особеннос
-
тей
,
совпадающих
с
названными
выше
особенностями
банков
данных
САПР
:
1
)
длительное
хранение
информации
,
отражающей
историю
разработок
; 2)
частота
операций
чтения
данных
выше
частоты
операций
обновления
данных
; 3)
использование
единых
форматов
для
однотипных
данных
,
получен
-
ных
из
различных
источников
(
например
,
от
разных
программно
-
методических
комплексов
).
Эти
осо
-
бенности
позволяют
управлять
конфигурацией
проектов
,
что
,
в
частности
,
означает
хранение
в
САПР
всех
версий
проекта
и
,
возможно
,
данных
по
проектам
предыдущих
разработок
,
удовлетворение
сложных
запросов
,
для
ответа
на
которые
требуется
извлечение
и
обработка
данных
из
различных
ча
-
стей
хранилища
(
так
называемая
многомерная
обработка
).
Модели
данных
в
DW
отличаются
от
реля
-
ционных
моделей
(RM):
в
RM
использованием
нормальных
форм
стремятся
максимально
уменьшить
избыточность
данных
,
что
приводит
к
увеличению
числа
таблиц
,
но
уменьшенных
размеров
,
однако
многомерный
поиск
,
требующийся
в
DW,
в
множестве
таблиц
затруднен
.
Поэтому
в
DW
чаще
исполь
-
зуется
модель
данных
“
звезда
”,
в
которой
имеется
общая
таблица
фактов
(Fact Table)
и
каждому
фак
-
ту
ставится
в
соответствие
несколько
таблиц
с
необходимыми
атрибутами
.
Целостность
данных
в
DW
обеспечивается
проверкой
и
трансформацией
данных
(data cleaning),
вводимых
из
внешних
источни
-
ков
,
наличием
дисциплины
обновления
данных
,
централизованным
хранением
основной
базы
,
при
этом
достаточное
быстродействие
поддерживается
передачей
копий
определенных
частей
базы
в
ло
-
кальные
базы
,
называемые
киосками
данных
(Data Mart)
и
ориентированные
на
отдельные
группы
пользователей
.
Примером
СУБД
,
учитывающей
требования
,
предъявляемые
со
стороны
САПР
,
является
система
IMAN
фирмы
EDS Unigraphics.
Это
система
управления
объектно
-
ориентированными
базами
данных
,
ее
можно
также
назвать
системой
интеграции
данных
.
Она
выполняет
функции
подсистемы
PDM,
которые
являются
функциями
хранения
данных
,
управле
-
ния
доступом
к
ним
,
контроля
вносимых
изменений
,
создания
спецификаций
изделий
,
интегрирования
прикладных
под
-
систем
.
Внутри
IMAN
используется
реляционная
модель
данных
,
а
на
интерфейсном
уровне
—
объектно
-
ориентирован
-
ная
информационная
модель
.
Для
синхронизации
изменений
предусматривается
блокировка
доступа
пользователей
,
если
с
БД
уже
начал
работу
некоторый
пользователь
.
Другими
известными
примерами
подсистем
управления
проектными
данными
могут
служить
системы
Optegra
(
фирма
Computervision), Euclid Design Manager (Matra Datavision), ProPDM
в
составе
САПР
Pro/Engineer (PTC),
TechnoDOCS (
Российская
фирма
“
Весть
”).
Ряд
фирм
разрабатывает
системы
PDM,
которые
можно
использовать
как
самостоятельные
про
-
дукты
и
как
подсистемы
в
автоматизированных
системах
проектирования
и
управления
.
Примером
может
служить
система
PartY (
фирма
Лоция
Софт
),
в
которой
предусмотрены
функции
управления
кон
-
фигурацией
изделий
,
управления
проектными
данными
и
документооборотом
,
графический
пользовательский
интерфейс
,
реализация
архитектуры
клиент
-
сервер
.
(:8+:0-1
<38:9
D.0+>
5:001/+
9
,
.-
>6
C
*
.
При
сетевой
организации
АС
информационное
обеспечение
может
быть
реализовано
по
одному
из
следующих
вариантов
:
1
) FS —
файловый
сервер
;
2) RDA —
доступ
к
удаленным
данным
; 3) DBS —
сервер
баз
данных
; 4) AS —
сервер
приложений
.
Варианты
различаются
распределени
-
ем
между
разными
узлами
сети
функ
-
ций
хранения
данных
,
управления
дан
-
ными
,
обработки
данных
в
приложени
-
ях
и
интерфейса
с
пользователем
.
На
рис
. 5.3
место
среды
передачи
данных
&
.
+
.
)
"#$%!#&’&($"!))$* +($*,#&($"!)&*
136
%+,
5.3.
Варианты
двухзвенных
схем
распределенных
вычислений
:
&:#*%)K* :(*AK & +($5(!%%)$
-
%*#$A&
F
*:,&* ,$%+@*,:K
:!+(
5
@!"!
5
показано
вертикальной
чертой
для
первых
трех
вариантов
.
Каждый
вариант
имеет
свою
область
применения
|