Норенков И.П. - Основы автоматизированного проектирования (1060628), страница 67
Текст из файла (страница 67)
Как правило, БнД работает в многопользовательском режиме, с его помощью осуществляется информационный интерфейс(взаимодействие) различных подсистем САПР. Построение БнД САПР - сложная задача, что обусловлено следующими особенностями САПР.1. Разнообразие проектных данных, фигурирующих в процессах обмена какпо своей семантике (многоаспектность), так и по формам представления.
Вчастности, значительна доля графических данных.2725 б Системные среды автоматизированных систем2. Нередко обмены должны производиться с высокой частотой, что предъяв(яет жесткие требования к быстродействию средств обмена (полагают, чтоСУБД должна работать со скоростью обработки нескольких тысяч сущностейв секунду).3. В САПР проблема целостности данных оказывается более трудной длярешения, чем в большинстве других систем, поскольку проектирование является процессом взаимодействия многих проектировщиков, которые не толькосчитывают данные, но и изменяют их, причем в значительной мере работаютпараллельно. Из этого факта вытекают следствия: во-первых, итерационныйхарактер проектирования обычно приводит к наличию по каждой части проекта нескольких версий, любая из них может быть принята в дальнейшем в качестве основной, поэтому нужно хранить все версии с возможностью возврата клюбой из них; во-вторых, нельзя допускать использования неутвержденныхданных, поэтому проектировщики должны иметь свое рабочее пространство впамяти и работать в нем автономно, а моменты внесения изменений в общуюбазу данных должны быть согласованными и не должны порождать для другихпользователей неопределенности данных.4.
Транзакции могут быть длительными и трудоемкими. Транзакцией называют последовательность операций по удовлетворению запроса. В САПРвнесение изменений в некоторую часть проекта может вызвать довольно длинную и разветвленную сеть изменений в других его частях из-за существеннойвзаимозависимости компонентов проекта (многошаговость реализации запросов).
В частности, транзакции могут включать в себя такие трудоемкие операции, как верификация проектного решения с помощью математического моделирования. В результате транзакции могут длиться даже несколько часов иболее. Одна из трудностей заключается в отображении взаимозависимости(ассоциативности) данных. При хранении компонентов проекта во внешней памяти затраты времени на обработку запросов оказываются значительно выше,чем в большинстве других автоматизированных систем с менее выраженными взаимозависимостями данных.5.
Иерархическая структура проектных данных и, следовательно, отражение наследования в целях сокращения объема базы данных.В определенной мере названные особенности учитываются в СУБД третьего поколения, в которых стали применяться черты объектно-ориентированных (объектных) СУБД. В них наборы данных, характеризующих состояниепредметной области (состояние проекта в случае САПР), помещаются в отдельные файлы. Интерпретация семантики данных осуществляется с помощью специальных процедур (методов), сопровождающих наборы.
Наследование свойств объектов предметной области выражается с помощью введениякатегорий класса, надкласса, подкласса. Информационные модели приложений для таких СУБД разрабатываются на основе методик типа IDEF1X.Объектные базы данных выгодны тем, что, во-первых, данные по конкретным объектам проектирования не разбросаны по множеству таблиц, как этоимеет место в реляционных базах данных, а сосредоточены в определенныхместах.
Во-вторых, для каждого объекта могут быть назначены свои типыданных. В результате проще решаются задачи управления и удовлетворениязапросов.10 Основы автоматизированногопроектирования2735. Методическое и программное обеспечение автоматизированных системНаряду с чисто объектными СУБД, применяют СУБД объектно-реляционные. В последних происходит объединение свойств реляционных и объектноориентированных СУБД: объектно-ориентированная СУБД снабжается непроцедурным языком запросов или в реляционную СУБД вводятся наследованиесвойств и классы.
Непроцедурность входного языка обеспечивается использованием языка SQL. Его операторы непосредственно включаются в программына языке С. Возможно написание дополнительных программ, интерпретирующих SQL-запросы.Отличительные особенности СУБД третьего поколения: расширенный набор возможных типов данных (это абстрактные типы, массивы, множества,записи, композиции разных типов, отображение величин со значениями разныхтипов), открытость (доступность из разных языков программирования, возможность обращения к прикладным системам из СУБД), непроцедурность языка(общепринятым становится язык запросов SQL), управление асинхроннымипараллельными процессами, состояние которых отражает база данных.Рассмотренные особенности БнД в САПР позволяют квалифицировать ихкак системы Data Warehouse (DW), т.
е. хранилища данных. Для хранилищданных характерен ряд особенностей, совпадающих с названными выше особенностями БнД САПР: 1) длительное хранение информации, отражающей историю разработок; 2) частота операций чтения данных выше частоты операций обновления данных; 3) использование единых форматов для однотипныхданных, полученных из различных источников (например, от разных программно-методических комплексов).Эти особенности позволяют управлять конфигурацией проектов, что, в частности, означает хранение в САПР всех версий проекта и, возможно, данныхпо проектам предыдущих разработок, удовлетворение сложных запросов, дляответа на которые требуются извлечение и обработка данных из различныхчастей хранилища (так называемая многомерная обработка). Модели данныхв DW отличаются от реляционных моделей (RM): в RM использованием нормальных форм стремятся максимальнр уменьшить избыточность данных, чтоприводит к увеличению числа таблиц, но уменьшенных размеров, при этоммногомерный поиск в множестве таблиц затруднен.
Поэтому в DW чаще используется модель данных «звезда», в которой имеется общая таблица фактов(Fact Table) и каждому факту ставится в соответствие несколько таблиц с необходимыми атрибутами. Целостность данных в DW обеспечивается проверкой и трансформацией данных, вводимых из внешних источников, наличиемдисциплины обновления данных, централизованным хранением основной базы,при этом достаточное быстродействие поддерживается передачей копий определенных частей базы в локальные базы, называемые киосками данных (DataMart) и ориентированные на отдельные группы пользователей.Варианты управления данными в сетях АСПри сетевой организации АС информационное обеспечение может бытьреализовано по одному из следующих вариантов: 1) FS - файловый сервер; 2) RDA - доступ к удаленным данным; 3) DBS - сервер баз данных;2745.6.
Системные среды автоматизированных системИнтерфейс- ПриложениеDBSRDAСУБДБазы данныхFSРис. 5.12. Варианты двухзвенных схем распределенных вычислений4) AS - сервер приложений. Варианты различаются распределением междуразными узлами сети функций хранения данных, управления данными, обработкиданных в приложениях и интерфейса с пользователем. На рис. 5.12 место средыпередачи данных показано вертикальной чертой для первых трех вариантов.Каждый вариант имеет свою область применения.Вариант файл-сервера характерен для локальных сетей на персональныхЭВМ с небольшим числом пользователей. Вследствие интенсивного трафикаи трудностей с защитой информации эта структура для большинства АСмалоэффективна. Поэтому предпочтительнее иметь СУБД в узле сервера.Вариант RDA - это модель удаленного узла, она наиболее распространена внастоящее время среди АС.
В ней уменьшен трафик по сравнению с FS,унифицирован интерфейс с СУБД на основе языка SQL.П р и м е ч а н и е . Клиентов в FS и RDA иногда именуют «толстыми» клиентами, таккак в них сосредоточены средства выполнения приложений.Дальнейший переход к системе распределенных вычислений приводит кперемещению прикладного ПО или его части на специальный сервер или сервербазы данных, т. е. реализуются двух- и трехзвенные схемы. DBS - двухзвеннаяструктура дистанционного управления, основанная на разделении прикладныхпроцедур на две части: индивидуальные для каждого пользователя и общиедля многих задач.
В этой структуре под приложением понимают совокупностьименно общих процедур. Эта совокупность обычно представляется напроцедурных расширениях SQL и сохраняется в специальном словаре базыданных. В альтернативных вариантах (например, в RDA) все прикладныепроцедуры включаются в прикладные программы и, следовательно, принеобходимости их изменения приходится модифицировать практически всеприкладное ПО. Выделение таких процедур в отдельное приложение облегчаетих модификацию. Кроме того, в DBS снижается трафик, так как обмены посети происходят не для каждой операции с базой данных, а для каждойтранзакции, состоящей из нескольких операций.Вариант AS реализуется по трехзвенной схеме, в которой для приложенийиспользуются узлы, отделенные от терминального (локального) узла и отсервера базы данных, т.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
