Слайд 2
![Управление данными в САПР](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-1.jpg)
Управление данными в САПР
Слайд 3
![В большинстве автоматизированных информационных систем применяют системы управления базами данных (СУБД), поддерживающие реляционные модели данных.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-2.jpg)
В большинстве автоматизированных информационных систем применяют системы управления базами данных (СУБД),
поддерживающие реляционные модели данных.
Слайд 4
![Общие требования к СУБД: обеспечение целостности данных (их полноты и](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-3.jpg)
Общие требования к СУБД:
обеспечение целостности данных (их полноты и достоверности);
защита данных от несанкционированного доступа и от искажений из-за сбоев аппаратуры;
удобство пользовательского интерфейса;
в большинстве случаев важна возможность распределенной обработки в сетях ЭВМ.
Слайд 5
![Первые два требования обеспечиваются ограничением прав доступа, запрещением одновременного использования](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-4.jpg)
Первые два требования обеспечиваются
ограничением прав доступа,
запрещением одновременного использования одних
и тех же обрабатываемых данных (при возможности их модификации),
введением контрольных точек (checkpoints) для защиты от сбоев
и т.п.
Слайд 6
![Банк данных (БнД) в САПР является важной обслуживающей подсистемой, он](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-5.jpg)
Банк данных (БнД) в САПР является важной обслуживающей подсистемой, он выполняет
функции информационного обеспечения и имеет ряд особенностей. В нем хранятся как редко изменяемые данные (архивы, справочные данные, типовые проектные решения), так и сведения о текущем состоянии различных версий выполняемых проектов.
Слайд 7
![БнД работает в многопользовательском режиме, с его помощью осуществляется информационный](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-6.jpg)
БнД работает в многопользовательском режиме, с его помощью осуществляется информационный интерфейс
(взаимодействие) различных подсистем САПР.
Построение БнД САПР — сложная задача, что обусловлено следующими особенностями САПР:
Слайд 8
![Разнообразие проектных данных, фигурирующих в процессах обмена как по своей](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-7.jpg)
Разнообразие проектных данных, фигурирующих в процессах обмена как по своей семантике
(многоаспектность), так и по формам представления.
В частности, значительна доля графических данных.
Слайд 9
![Нередко обмены должны производиться с высокой частотой, что предъявляет жесткие](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-8.jpg)
Нередко обмены должны производиться с высокой частотой, что предъявляет жесткие требования
к быстродействию средств обмена (полагают, что СУБД должна работать со скоростью обработки тысяч сущностей в секунду).
Слайд 10
![В САПР проблема целостности данных оказывается более трудной для решения,](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-9.jpg)
В САПР проблема целостности данных оказывается более трудной для решения, чем
в большинстве других систем, поскольку проектирование является процессом взаимодействия многих проектировщиков, которые не только считывают данные, но и изменяют их, причем в значительной мере работают параллельно.
Слайд 11
![Вследствие этого: во-первых, итерационный характер проектирования определяет наличие нескольких равноценных](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-10.jpg)
Вследствие этого:
во-первых, итерационный характер проектирования определяет наличие нескольких равноценных версий
всех частей проекта, поэтому возникает необходимость сохранения всех версий с возможностью возврата к любой из них;
во-вторых, нельзя допускать использования неутвержденных данных, поэтому проектировщики должны иметь свое рабочее пространство в памяти и работать в нем автономно, а моменты внесения изменений в общую БД должны быть согласованными и не порождать для других пользователей неопределенности данных.
Слайд 12
![Транзакции могут быть длительными и трудоемкими.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-11.jpg)
Транзакции могут быть длительными и трудоемкими.
Слайд 13
![Транзакцией называют последовательность операций по удовлетворению запроса. В САПР внесение](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-12.jpg)
Транзакцией называют последовательность операций по удовлетворению запроса.
В САПР внесение изменений
в некоторую часть проекта может вызвать довольно длинную и разветвленную сеть изменений в других его частях из-за существенной взаимозависимости компонентов проекта (многошаговость реализации запросов). В частности, транзакции могут включать в себя такие трудоемкие операции, как верификация проектного решения с помощью математического моделирования.
Слайд 14
![В результате транзакции могут длиться даже несколько часов и более.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-13.jpg)
В результате транзакции могут длиться даже несколько часов и более. Одна
из трудностей заключается в отображении взаимозависимости (ассоциативности) данных. При хранении компонентов проекта во внешней памяти затраты времени на обработку запросов оказываются значительно выше, чем в большинстве других автоматизированных систем, с менее выраженными взаимозависимостями данных.
Слайд 15
![Иерархическая структура проектных данных и, следовательно, отражение наследования в целях сокращения объема базы данных.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-14.jpg)
Иерархическая структура проектных данных и, следовательно, отражение наследования в целях сокращения
объема базы данных.
Слайд 16
![В определенной мере названные особенности учитываются в СУБД третьего поколения,](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-15.jpg)
В определенной мере названные особенности учитываются в СУБД третьего поколения, в
которых стали применяться черты объектно-ориентированных (объектных) СУБД. В них наборы данных, характеризующих состояние предметной области (состояние проекта в случае САПР), помещаются в отдельные файлы.
Слайд 17
![Интерпретация семантики данных осуществляется с помощью специальных процедур (методов), сопровождающих](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-16.jpg)
Интерпретация семантики данных осуществляется с помощью специальных процедур (методов), сопровождающих наборы.
Наследование свойств объектов предметной области выражается с помощью введения категорий класса, надкласса, подкласса. Информационные модели приложений для таких СУБД разрабатываются на основе методик типа IDEF1X.
Слайд 18
![Объектные БД выгодны, во-первых, тем, что данные по конкретным объектам](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-17.jpg)
Объектные БД выгодны,
во-первых, тем, что данные по конкретным объектам проектирования
не разбросаны по множеству таблиц, как это имеет место в реляционных БД, а сосредоточены в определенных местах.
Во-вторых, для каждого объекта могут быть назначены свои типы данных.
В результате проще решаются задачи управления и удовлетворения запросов.
Слайд 19
![Наряду с чисто объектными СУБД (pure ODBMS), применяют СУБД объектно-реляционные.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-18.jpg)
Наряду с чисто объектными
СУБД (pure ODBMS), применяют СУБД объектно-реляционные.
В
последних происходит объединение свойств реляционных и объектно-ориентированных СУБД: объектно-ориентированная СУБД снабжается непроцедурным языком запросов или в реляционную СУБД вводятся наследование свойств и классы.
Слайд 20
![Непроцедурность входного языка обеспечивается использованием языка SQL. Его операторы непосредственно](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-19.jpg)
Непроцедурность входного языка обеспечивается использованием
языка SQL.
Его операторы непосредственно включаются
в программы на языке С. Возможно написание дополнительных программ, интерпретирующих SQL-запросы.
Слайд 21
![Отличительные особенности СУБД третьего поколения: расширенный набор возможных типов данных](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-20.jpg)
Отличительные особенности
СУБД третьего поколения:
расширенный набор возможных типов данных (это
абстрактные типы, массивы, множества, записи, композиции разных типов, отображение величин с значениями разных типов),
открытость (доступность из разных языков программирования, возможность обращения к прикладным системам из СУБД),
непроцедурность языка (общепринятым становится язык запросов SQL),
управление асинхронными параллельными процессами, состояние которых отражает БД.
Слайд 22
![Управление асинхронными параллельными процессами, состояние которых отражает БД, позволяет говорить](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-21.jpg)
Управление асинхронными параллельными процессами, состояние которых отражает БД, позволяет говорить о
тесной взаимосвязи СУБД и подсистемы управления проектами DesPM.
Слайд 23
![Названные особенности управления данными в САПР нашли свое выражение в современных подсистемах управления проектными данными PDM.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-22.jpg)
Названные особенности управления данными в САПР нашли свое выражение в современных
подсистемах управления проектными данными PDM.
Слайд 24
![В PDM разнообразие типов проектных данных поддерживается их классификацией и](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-23.jpg)
В PDM разнообразие типов проектных данных поддерживается их классификацией и соответствующим
выделением групп с характерными множествами атрибутов.
Такими группами данных являются описания изделий с различных точек зрения (аспекты).
Слайд 25
![Для большинства САПР машиностроения характерными аспектами являются: свойства компонентов и](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-24.jpg)
Для большинства САПР машиностроения характерными аспектами являются:
свойства компонентов и сборок
(эти сведения называют Bill of materials — BOM),
модели и их документальное выражение (основными примерами могут служить чертежи, 3D модели визуализации, сеточные представления для конечно-элементого анализа, текстовые описания),
структура изделий, отражающая взаимосвязи между компонентами и сборками и их описаниями в разных группах.
Слайд 26
![Вследствие большого объема проектных данных и наличия ряда версий проектов](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-25.jpg)
Вследствие большого объема проектных данных и наличия ряда версий проектов PDM
должна обладать развитой системой поиска нужных данных по различным критериям.
Рассмотренные особенности банков данных в САПР позволяют квалифицировать их как системы Data Warehouse (DW),
т.е. хранилища данных.
Слайд 27
![Для хранилищ данных характерен ряд особенностей: длительное хранение информации, отражающей](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-26.jpg)
Для хранилищ данных характерен ряд особенностей:
длительное хранение информации, отражающей историю
разработок;
частота операций чтения данных выше частоты операций обновления данных;
использование единых форматов для однотипных данных, полученных из различных источников (например, от разных программно-методических комплексов).
Слайд 28
![Эти особенности позволяют управлять конфигурацией проектов, что означает хранение в](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-27.jpg)
Эти особенности позволяют управлять конфигурацией проектов, что означает хранение в САПР
всех версий проекта и данных по проектам предыдущих разработок, удовлетворение сложных запросов, для ответа на которые требуется извлечение и обработка данных из различных частей хранилища (многомерная обработка).
Слайд 29
![Модели данных в DW отличаются от реляционных моделей (RM). В](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-28.jpg)
Модели данных в DW отличаются от реляционных моделей (RM).
В RM
стремятся максимально уменьшить избыточность данных использованием нормальных форм, что приводит к увеличению числа таблиц, но уменьшенных размеров.
Однако многомерный поиск, требующийся в DW, в множестве таблиц затруднен.
Поэтому в DW чаще используется модель данных “звезда”, в которой имеется общая таблица фактов (Fact Table) и каждому факту ставится в соответствие несколько таблиц с необходимыми атрибутами.
Слайд 30
![Целостность данных в DW обеспечивается: проверкой и трансформацией данных (data](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-29.jpg)
Целостность данных в DW обеспечивается:
проверкой и трансформацией данных (data cleaning),
вводимых из внешних источников,
наличием дисциплины обновления данных,
централизованным хранением основной базы;
при этом достаточное быстродействие поддерживается
передачей копий определенных частей базы в локальные базы, называемые киосками данных (Data Mart) и ориентированные на отдельные группы пользователей.
Слайд 31
![Примером СУБД, учитывающей требования, предъявляемые со стороны САПР, является система](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-30.jpg)
Примером СУБД, учитывающей требования, предъявляемые со стороны САПР, является система IMAN
фирмы EDS Unigraphics.
Это система управления объектно-ориентированными базами данных, ее можно также назвать системой интеграции данных.
Она выполняет функции подсистемы PDM, которые являются функциями хранения данных, управления доступом к ним, контроля вносимых изменений, создания спецификаций изделий, интегрирования прикладных подсистем.
Внутри IMAN используется реляционная модель данных, а на интерфейсном уровне — объектно-ориентированная информационная модель. Для синхронизации изменений предусматривается блокировка доступа пользователей, если с БД уже начал работу некоторый пользователь.
Слайд 32
![Другими примерами подсистем управления проектными данными могут служить системы Optegra](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-31.jpg)
Другими примерами подсистем управления проектными данными могут служить системы
Optegra (фирма
Computervision),
Euclid Design Manager (Matra Datavision),
ProPDM в составе САПР Pro/Engineer (PTC),
TechnoDOCS (Российская фирма “Весть”).
Слайд 33
![Ряд фирм разрабатывает системы PDM, которые можно использовать как самостоятельные](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-32.jpg)
Ряд фирм разрабатывает системы PDM, которые можно использовать как самостоятельные продукты
и как подсистемы в автоматизированных системах проектирования и управления.
Примером может служить система PartY (фирма Лоция Софт), в которой предусмотрены функции управления конфигурацией изделий, управления проектными данными и документооборотом, графический пользовательский интерфейс, реализация архитектуры клиент-сервер.
Слайд 34
![Интеллектуальные серверы БД](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-33.jpg)
Интеллектуальные серверы БД
Слайд 35
![Особенности СУБД в САПР определяют их квалификацию как интеллектуальных (СУБД третьего поколения).](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-34.jpg)
Особенности СУБД в САПР определяют их квалификацию
как интеллектуальных
(СУБД третьего
поколения).
Слайд 36
![Признаки интеллектуальной СУБД (дополнительно к вышеуказанным): реализация в СУБД части](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-35.jpg)
Признаки интеллектуальной СУБД (дополнительно к вышеуказанным):
реализация в СУБД части прикладных процедур,
что характерно для структуры DBS,
оповещение пользователей (прикладных программ) об интересующих их изменениях состояния БД,
синхронизация событий в БД,
способность обслуживать прикладные программы, первоначально ориентированные на разные типы СУБД (многопротокольность).
Слайд 37
![Оповещение заключается в информировании программы А о совершении события, вызванного](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-36.jpg)
Оповещение заключается в информировании программы А о совершении события, вызванного программой
В и влияющего на работу программы А.
Слайд 38
![Примером события может быть выход значения некоторого параметра в БД](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-37.jpg)
Примером события может быть выход значения некоторого параметра в БД за
допустимые пределы.
Наиболее просто информирование можно организовать периодическим опросом состояния БД со стороны K.
Однако это усложняет ПО и неэффективно по затратам времени и загрузке сети. Лучше возложить функцию оповещения на СУБД,
что и присуще интеллектуальным СУБД.
Слайд 39
![Но для этого нужно иметь обратные ссылки на программы, обращающиеся](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-38.jpg)
Но для этого нужно иметь обратные ссылки на программы, обращающиеся к
БД, правила (триггеры), фиксирующие наступления событий, и процедуры обработки событий.
Удобный вариант оповещения — информирование программы А о происшедших событиях во время ее активизации.
Слайд 40
![Распределенные базы данных](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-39.jpg)
Распределенные базы данных
Слайд 41
![В крупных АС, построенных на основе корпоративных сетей, не всегда](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-40.jpg)
В крупных АС,
построенных на основе корпоративных сетей, не всегда удается
организовать централизованное размещение всех баз данных и СУБД на одном узле сети.
Поэтому появляются
распределенные базы данных.
Слайд 42
![При построении РБД приходится решать ряд сложных проблем, связанных с](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-41.jpg)
При построении РБД приходится решать ряд сложных проблем, связанных с минимизацией
трафика, обеспечением интероперабельности обработки данных и целостности данных.
Слайд 43
![Минимизация трафика нужна в связи с необходимостью при обслуживании запроса](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-42.jpg)
Минимизация трафика нужна в связи с необходимостью при обслуживании запроса данных
из многих узлов, пересылаемые по сети.
Целесообразна однократная пересылка таблиц (причем таблиц именно меньшего размера) на один узел, на котором и будет обрабатываться запрос.
Слайд 44
![Интероперабельность выражает способность взаимодействия программ, работающих в гетерогенных сетях (в](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-43.jpg)
Интероперабельность выражает способность взаимодействия программ, работающих в гетерогенных сетях (в разных
операционных средах или с разными СУБД).
Интероперабельность обеспечивается или с помощью программ-шлюзов (конверторов) для каждой пары взаимодействующих сред, или с помощью единого унифицированного языка взаимодействия.
Слайд 45
![Таким языком для доступа к БД является язык SQL, интероперабельность](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-44.jpg)
Таким языком для доступа к БД является язык SQL, интероперабельность на
его основе имеет место в системе ODBC (Open Data Base Connectivity), пример реализации которой показан на рисунке.
Слайд 46
![В примере СУБД FoxPro находится в локальном узле, а СУБД](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-45.jpg)
В примере СУБД FoxPro находится в локальном узле, а СУБД Ingres
и Informix – в удаленных узлах. Прикладная программа имеет ОDBC-интерфейс, не зависимый от особенностей различных СУБД. Менеджер драйверов реализует на базе унифицированного языка SQL все нюансы доступа к БД, общие для разных СУБД. Драйвер конкретной СУБД преобразует инвариантные к СУБД запросы в форму, принятую в данной СУБД. В трехзвенной структуре менеджер драйверов может быть размещен на промежуточном сервере.
Слайд 47
![Обеспечение целостности в РБД намного сложнее, чем в одноузловых БД.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-46.jpg)
Обеспечение целостности в РБД намного сложнее, чем в одноузловых БД.
Различают два
подхода
к построению РБД:
тиражирование (репликация), при котором на нескольких серверах (узлах) сети расположены копии БД;
полномасштабная распределенность, при которой разные части БД находятся на разных серверах сети (классическая распределенность).
Слайд 48
![Применяют два способа тиражирования.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-47.jpg)
Применяют два способа тиражирования.
Слайд 49
![Способ, называемый репликацией первой копии, основан на выделении среди серверов](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-48.jpg)
Способ, называемый репликацией первой копии, основан на выделении среди серверов с
копиями БД одного первичного сервера (репликатора). Внесение изменений пользователями возможно только в БД первичного сервера, который в дальнейшем осуществляет тиражирование.
Слайд 50
![Тиражирование — это перенос изменений БД из первичного сервера во](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-49.jpg)
Тиражирование — это перенос изменений БД из первичного сервера во все
вторичные (локальные) серверы, которые используются клиентами только для чтения данных.
Репликатор реагирует на события, фиксируемые триггерами, периодически пересылает обновленные данные в копии БД.
Недостаток способа — невысокая надежность, присущая любым централизованным структурам.
Слайд 51
![Надежность повышается при использовании способа голосования. Здесь изменения посылаются не](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-50.jpg)
Надежность повышается при использовании способа голосования.
Здесь изменения посылаются не в
один первичный, а в некоторые N серверов.
При этом любой запрос на чтение направляется к некоторым M серверам, причем N+M > K, где K — общее число серверов. Принимается последняя по времени обновления версия ответа.
Слайд 52
![Тиражирование вносит избыточность в хранимые данные, появляются трудности с разрешением](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-51.jpg)
Тиражирование вносит
избыточность в хранимые данные, появляются трудности с разрешением конфликтов
из-за возможных несогласованных изменений в локальных БД.
Однако по сравнению с классическими РБД, в которых данные не дублируются, заметно уменьшается трафик, надежнее и проще работа с локальными БД.
Слайд 53
![Обеспечение надежности и удобства работы особенно актуально в случае ненадежных](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/179745/slide-52.jpg)
Обеспечение надежности и удобства работы особенно актуально в случае ненадежных и
медленных каналов связи, что имеет место во многих сетях в России.