Текст книги "Базы данных: конспект лекций"
Автор книги: авторов Коллектив
Жанр:
Базы данных
сообщить о нарушении
Текущая страница: 11 (всего у книги 12 страниц)
4. Обобщения
Очередным видом связи классов сущностей между собой, который мы рассмотрим, является связь вида обобщение. Это также нерекурсивный вид связи.
Итак, связь типа обобщение реализуется как взаимосвязь одного родительского класса сущностей с несколькими дочерними классами сущностей (в отличие от предыдущей рассмотренной связи Ассоциации, в которой речь шла о нескольких родительских классах сущностей и одним дочернем классе сущностей).
При формулировании правил представления данных при помощи связи Обобщения необходимо сразу сказать, что эта взаимосвязь одного родительского класса сущностей и нескольких дочерних классов сущностей, описывается полностью идентифицирующими связями, т. е. категориальными связями. Вспоминая определение полностью идентифицирующих связей, мы приходим к выводу, что при использовании Обобщения каждый атрибут первичного ключа родительского класса сущностей переносится в состав первичного ключа классов сущностей дочерних, т. е. атрибуты первичного мигрирующего ключа родительского класса сущностей полностью формируют первичные ключи всех дочерних классов сущностей, они их идентифицируют.
Любопытно отметить, что при Обобщении реализуется так называемая иерархия категорий или иерархия наследования.
При этом родительский класс сущностей определяет класс обобщенных сущностей, характеризующийся атрибутами, общими для сущностей всех дочерних классов или так называемых категориальных сущностей т. е. родительский класс сущностей представляет собой буквальное обобщение всех своих дочерних классов сущностей.
В качестве примера реализации обобщения в реляционной модели данных построим следующую модель. Эта модель будет основана на обобщенном понятии «Учащиеся» и будет описывать следующие категориальные понятия (т. е. будет обобщать следующие дочерние классы сущностей): «Школьники», «Студенты» и «Аспиранты».
Итак, построим ключевую диаграмму, отражающую суть взаимоотношений между родительским классом сущности и дочерними классами сущностей, описываемых связью типа Обобщение.
Итак, что же мы видим?
Во-первых, каждому из базовых отношений (или из классов сущностей, что одно и то же) «Школьники», «Студенты» и «Аспиранты» соответствуют свои собственные атрибуты, как то «Класс», «Курс» и «Год обучения». Каждый из этих атрибутов характеризует участников своего собственного класса сущностей. Еще мы видим, что первичный ключ родительского класса сущностей «Учащиеся» мигрирует в каждый дочерний класс сущностей и формирует там первичный внешний ключ. При помощи этих связей мы можем по коду любого учащегося определить его имя, фамилию и отчество, информацию о которых мы не найдем в самих соответствующих дочерних классах сущностей.
Во-вторых, так как мы говорим о полностью идентифицирующей (или категориальной) связи классов сущностей, то обратим внимание на кратности связей между родительским классом сущностей и его дочерними классами. На родительском конце каждой из этих связей стоит кратность «один», а на каждом дочернем конце связей стоит кратность «не более одного». Если вспомнить определение полностью идентифицирующей связи классов сущностей, то становится понятно, что действительно единственный в своем роде код учащегося, являющийся первичным ключом класса сущностей «Учащиеся», задает не более одного атрибута с таким кодом в каждом дочернем классе сущностей «Школьники», «Студенты» и «Аспиранты». Поэтому все связи имеют именно такие кратности.
Запишем фрагмент операторов создания базовых отношений «Школьники» и «Студенты» с определением правил поддержания ссылочной целостности типа cascade. Итак, имеем:
Create table Школьники
…
primary key (Код ученика)
foreign key (Код ученика) references Учащиеся (Код ученика)
on update cascade
on delete cascade
Create table Студенты
…
primary key (Код студента)
foreign key (Код студента) references Учащиеся (Код студента)
on update cascade
on delete cascade;
Таким образом, мы видим, что в дочернем классе сущностей (или отношений) «Школьники» задается первичный внешний ключ, ссылающийся на родительский класс сущностей (или отношение) «Учащиеся». Правило cascade поддержания ссылочной целостности определяет, что при удалении или при обновлении атрибутов родительского класса сущностей «Учащиеся» соответствующие им атрибуты дочернего отношения «Школьники» будут автоматически (каскадом) обновляться или удаляться. Аналогично при удалении или при обновлении атрибутов родительского класса сущностей «Учащиеся» соответствующие им атрибуты дочернего отношения «Студенты» также будут автоматически обновляться или удаляться.
Необходимо заметить, что здесь используется именно это правило поддержания ссылочной целостности, потому что в данном контексте (перечень учащихся) не рационально запрещать удаление и обновление информации, а также присваивать неопределенное значение вместо реальных сведений.
А теперь приведем пример классов сущностей, описанных в предыдущей диаграмме, только представленных в табличной форме. Итак, имеем следующие таблицы-отношения:
Учащиеся – родительское отношение, объединяющее в себе информацию об атрибутах всех остальных отношений:
Школьники – дочернее отношение:
Студенты – второе дочернее отношение:
Аспиранты – третье дочернее отношение:
Итак, действительно, мы видим, что в дочерних классах сущностей не прописана информация о фамилии, имени и отчестве учащихся, т. е. школьников, студентов и аспирантов. Эту информацию можно получить только посредством ссылок на родительский класс сущностей.
Также мы видим, что различные коды учащихся в классе сущностей «Учащиеся» могут соответствовать различным дочерним классам сущностей. Так, про учащегося с кодом «1» Заботина Николая в родительском отношении неизвестно ничего, кроме его имени, а всю остальную информацию (кто он, школьник, студент или аспирант) можно узнать только обратившись к соответствующему дочернему классу сущностей (определяется по коду).
Аналогичным образом необходимо работать с остальными учащимися, чьи коды указаны в родительском классе сущностей «Учащиеся».
5. Композиция
Связь классов сущностей типа композиция, так же как и две предыдущие, не принадлежит к виду рекурсивной связи.
Композиция (или, как ее еще иногда называют, композитная агрегация) – это взаимосвязь одного родительского класса сущностей с несколькими дочерними классами сущностей, так же как и предыдущая рассмотренная нами связь. Обобщение.
Но если обобщение определялось как взаимосвязь классов сущности, описывающаяся полностью идентифицирующимися связями, то композиция, в свою очередь, описывается не полностью идентифицирующими связями, т. е. при композиции каждый атрибут первичного ключа родительского класса сущностей мигрирует в ключевой атрибут дочернего класса сущностей. И при этом атрибуты мигрирующего ключа лишь частично формируют первичный ключ дочернего класса сущностей.
Итак, при композитной агрегации (при композиции) родительский класс сущностей (или агрегат) связывается с несколькими дочерними классами сущностей (или компонентами). При этом компоненты агрегата (т. е. компоненты родительского класса сущностей) ссылаются на агрегат посредством внешнего ключа, входящего в состав первичного ключа и, следовательно, не могут существовать вне агрегата.
Вообще композитная агрегация представляет собой усиленную форму простой агрегации (о которой мы поговорим чуть дальше). Композиция (или композитная агрегация) характеризуется тем, что:
1) ссылка на агрегат участвует в идентификации компонентов;
2) эти компоненты не могут существовать вне агрегата.
Агрегация (связь, которую мы будем рассматривать дальше) с обязательно не идентифицирующими связями также не позволяет компонентам существовать вне агрегата и поэтому близка по смыслу к описанной выше реализации композитной агрегации.
Построим ключевую диаграмму, описывающую взаимосвязь между одним родительским классом сущностей и несколькими дочерними классами сущностей, т. е. описывающую связь классов сущностей типа композитной агрегации.
Пусть это будет ключевая диаграмма, изображающая состав корпусов некого учебного городка, включающего в себя корпуса, их аудитории и лифты. Итак, эта диаграмма будет иметь следующий вид:
Итак, рассмотрим только что построенную диаграмму.
Что мы в ней видим?
Во-первых, мы видим, что связь, использованная в этой композитной агрегации, действительно идентифицирующая и действительно не полностью идентифицирующая. Ведь первичный ключ родительского класса сущностей «Корпуса» участвует в формировании первичного ключа дочерних классов сущностей «Аудитории» и «Лифты», но не определяет его полностью. Первичный ключ «№ корпуса» родительского класса сущностей мигрирует во внешние первичные ключи «№ корпуса» обоих дочерних классов, но, кроме этого мигрировавшего, ключа у обоих дочерних классов сущностей существует и свой собственный первичный ключ, соответственно «№ аудитории» и «№ лифта», т. е. составные первичные ключи дочерних классов сущностей лишь частично оказываются сформированными атрибутами первичного ключа родительского класса сущностей.
Теперь разберемся с кратностями связей, соединяющих родительский и оба дочерних класса. Так как мы имеем дело с не полностью идентифицирующими связями, то кратности присутствуют такие: «один» и «много». Кратность «один» присутствует на родительском конце обеих связей и символизирует то, что в списке всех имеющихся корпусов (а класс сущностей «Корпуса» является именно таким списком) каждый номер может встретиться только один, (и не более того) раз. А, в свою очередь, среди атрибутов классов «Аудитории» и «Лифты» каждый номер корпуса может встретиться много раз, так как аудиторий (или лифтов) больше, чем корпусов, и в каждом корпусе – несколько и аудиторий, и лифтов. Таким образом, при перечислении всех аудиторий и лифтов мы неминуемо будем повторять номера корпусов.
И, наконец, как и при рассмотрении предыдущего вида связи, запишем фрагменты операторов создания базовых отношений (или, что одно и то же, классов сущностей) «Аудитории» и «Лифты», причем сделаем это с определением правил поддержания ссылочной целостности типа cascade.
Итак, этот оператор будет выглядеть следующим образом:
Create table Аудитории
…
primary key (№ корпуса, № аудитории)
foreign key (№ корпуса) references Корпуса (№ корпуса)
on update cascade
on delete cascade
Create table Лифты
…
primary key (№ корпуса, № лифта)
foreign key (№ корпуса) references Корпуса (№ корпуса)
on update cascade
on delete cascade;
Таким образом, мы и задали все необходимые первичные и внешние ключи дочерних классов сущностей. Правило поддержания ссылочной целостности мы снова взяли cascade, так как уже описали его как наиболее рациональный.
Теперь приведем пример в табличной форме всех только что рассмотренных нами классов сущностей. Опишем те базовые отношения, которые отразили при помощи диаграммы, в виде таблиц, и для наглядности введем туда некоторое количество показательных данных.
Корпуса – родительское отношение имеет следующий вид:
Аудитории – дочерний класс сущностей:
Лифты – второй дочерний класс сущностей родительского класса «Корпуса»:
Итак, мы можем видеть, каким образом организована информация по всем корпусам, их аудиториям и лифтам в этой базе данных, которую вполне может использовать любое реально существующее учебное заведение.
6. Агрегация
Агрегация – это последний вид связи между классами сущностей, который подлежит рассмотрению в рамках нашего курса. Она также не является рекурсивной, и один из двух ее видов довольно близок по смыслу к уже рассмотренной ранее композитной агрегации.
Итак, агрегация – это взаимосвязь одного родительского класса сущностей с несколькими дочерними классами сущностей. При этом взаимосвязи могут быть описаны связями двух видов:
1) обязательно не идентифицирующими связями;
2) необязательно не идентифицирующими связями.
Напомним, что при обязательно не идентифицирующих связях некоторые атрибуты первичного ключа родительского класса сущностей переносятся в неключевой атрибут дочернего класса, и при этом Null-значения для всех атрибутов мигрирующего ключа запрещены. А при не обязательно не идентифицирующих связях миграция первичных ключей происходит по точно такому же принципу, но при этом Null-значения для некоторых атрибутов мигрирующего ключа разрешены.
При агрегации, родительский класс сущностей (или агрегат) связывается с несколькими дочерними классами сущностей (или компонентами). Компоненты агрегата (т. е. родительского класса сущностей) ссылаются на агрегат посредством внешнего ключа, не входящего в состав первичного ключа, и, следовательно, в случае не обязательно не идентифицирующих связей, компоненты агрегата могут существовать вне агрегата.
В случае использования агрегации с обязательно не идентифицирующими связями компонентам агрегата не позволяется существовать вне агрегата, и в этом смысле агрегация с обязательно не идентифицирующими связями близка к композитной агрегации.
Теперь, когда стало понятно, что собой представляет связь типа агрегации, построим ключевую диаграмму, описывающую работу этой связи.
Пусть наша будущая диаграмма описывает маркированные компоненты автомобилей (а именно двигатель и шасси). При этом, будем считать, что списывание автомобиля предполагает и списывание шасси вместе с ним, но не предполагает одновременное списывание двигателя.
Итак, наша ключевая диаграмма имеет следующий вид:
Итак, что же мы видим на этой ключевой диаграмме?
Во-первых, связь родительского класса сущностей «Автомобили» с дочерним классом сущностей «Двигатели» является не обязательно не идентифицирующей, потому что атрибут «№ автомобиля» допускает среди своих значений Null-значения. В свою очередь, Null-значе-ния этот атрибут допускает по той причине, что списывание двигателя, по условию не зависит от списывания всего автомобиля и, следовательно, при списывании автомобиля происходит не обязательно. Также мы видим, что первичный ключ «№ двигателя» класса сущностей «Автомобили» мигрирует в неключевой атрибут «№ двигателя» класса сущностей «Двигатели». И при этом данный атрибут приобретает статус внешнего ключа. А первичным ключом в этом классе сущностей «Двигатели» является атрибут «Маркер двигателя», который не ссылается ни на какой атрибут родительского отношения.
Во-вторых, связь родительского класса сущностей «Двигатели» и дочернего класса сущностей «Шасси» – это обязательно не идентифицирующая связь, потому что атрибут внешнего ключа «№ автомобиля» не допускает среди своих значений Null-значения. Это, в свою очередь, происходит потому, что по условию известно, что списывание автомобиля предполагает обязательное одновременное списывание и шасси. Здесь, так же, как и в случае предыдущей связи, первичный ключ родительского класса сущностей «Двигатели» мигрирует в неключевой атрибут «№ автомобиля» дочернего класса сущностей «Шасси». При этом первичным ключом этого класса сущностей является атрибут «Маркер шасси», который не ссылается ни на какой атрибут родительского отношения «Двигатели».
Идем дальше. Для наилучшего усвоения пройденной темы, запишем снова фрагменты операторов создания базовых отношений «Двигатели» и «Шасси» с определением правил поддержания ссылочной целостности.
Create table Двигатели
…
primary key (Маркер двигателя)
foreign key (№ автомобиля) references Автомобили (№ автомобиля)
on update cascade
on delete set Null
Create table Шасси
…
primary key (Маркер шасси)
foreign key (№ автомобиля) references Автомобили (№ автомобиля)
on update cascade
on delete cascade;
Мы видим, что правило поддержания ссылочной целостности мы использовали везде одно – cascade, так как еще раньше признали его наиболее рациональным из всех. Однако на этот раз мы использовали (помимо правила cascade) еще и правило поддержания ссылочной целостности set Null. Причем использовали мы его при следующем условии: если какое-то значение первичного ключа «№ автомобиля» из родительского класса сущностей «Автомобили» будет удалено, то значению ссылающегося на него внешнего ключа «№ автомобиля» дочернего отношения «Двигатели» будет присвоено Null-значение.
7. Унификация атрибутов
Если при миграции первичных ключей некоего родительского класса сущностей в один и тот же дочерний класс попадают совпадающие по смыслу атрибуты из разных родительских классов, то эти атрибуты необходимо «слить», т. е. необходимо провести так называемую унификацию атрибутов.
Например, в случае, когда сотрудник может работать в организации, числясь не более чем в одном отделе, после унификации атрибута «Код организации» получим следующую ключевую диаграмму:
При миграции первичный ключ из родительских классов сущностей «Организация» и «Отделы» в дочерний класс «Сотрудники», атрибут «Код организации» попадает в класс сущностей «Сотрудники». Причем дважды:
1) первый раз с маркером PFK из класса сущностей «Организация» при установлении не полностью идентифицирующей связи;
2) и второй раз, с маркером FK с условием допустимости Null-значений из класса сущностей «Отделы» при установлении не обязательно не идентифицирующей связи.
При унификации атрибут «Код организации» получает статус атрибута первичного / внешнего ключа, поглощающего статус атрибута внешнего ключа.
Построим новую ключевую диаграмму, демонстрирующую сам процесс унификации:
Таким образом и произошла унификация атрибутов.
Лекция № 13. Экспертные системы и продукционная модель знаний
1. Назначение экспертных систем
Для ознакомления с таким новым для нас понятием, как экспертные системы мы, для начала, пройдемся по истории создания и разработки направления «экспертные системы», а потом определим и само понятие экспертных систем.
В начале 80-х гг. XX в. в исследованиях по созданию искусственного интеллекта сформировалось новое самостоятельное направление, получившее название экспертных систем. Цель этих новых исследований по экспертным системам состоит в разработке специальных программ, предназначенных для решения особых видов задач. Что это за особый вид задач, потребовавший создания целой новой инженерии знаний? К этому особому виду задач могут быть отнесены задачи из абсолютно любой предметной области. Главное, что отличает их от задач обычных, – это то, что человеку-эксперту решить их представляется очень сложным заданием. Тогда и была разработана первая так называемая экспертная система (где в роли эксперта выступал уже не человек, а машина), причем экспертная система получает результаты, не уступающие по качеству и эффективности решениям, получаемым обычным человеком – экспертом. Результаты работы экспертных систем могут быть объяснены пользователю на очень высоком уровне. Данное качество экспертных систем обеспечивается их способностью рассуждать о собственных знаниях и выводах. Экспертные системы вполне могут пополнять собственные знания в процессе взаимодействия с экспертом. Таким образом, их можно с полной уверенностью ставить в один ряд с вполне оформившимся искусственным интеллектом.
Исследователи в области экспертных систем для названия своей дисциплины часто используют также уже упоминавшийся ранее термин «инженерия знаний», введенный немецким ученым Е. Фейгенбаумом как «привнесение принципов и инструментария исследований из области искусственного интеллекта в решение трудных прикладных проблем, требующих знаний экспертов».
Однако коммерческие успехи к фирмам-разработчикам пришла не сразу. На протяжении четверти века в период с 1960 по 1985 гг. успехи искусственного интеллекта касались в основном исследовательских разработок. Тем не менее, начиная примерно с 1985 г., а в массовом масштабе с 1987 по 1990 гг. экспертные системы стали активно использоваться в коммерческих приложениях.
Заслуги экспертных систем довольно велики и состоят в следующем:
1) технология экспертных систем существенно расширяет круг практически значимых задач, решаемых на персональных компьютерах, решение которых приносит значительный экономический эффект и существенно упрощает все связанные с ними процессы;
2) технология экспертных систем является одним из самых важных средств в решении глобальных проблем традиционного программирования, таких как продолжительность, качество и, следовательно, высокая стоимость разработки сложных приложений, вследствие которой значительно снижался экономический эффект;
3) имеется высокая стоимость эксплуатации и обслуживания сложных систем, которая зачастую в несколько раз превосходит стоимость самой разработки, а также низкий уровень повторной используемости программ и т. п.;
4) объединение технологии экспертных систем с технологией традиционного программирования добавляет новые качества к программным продуктам за счет, во-первых, обеспечения динамичной модификации приложений рядовым пользователем, а не программистом; во-вторых, большей «прозрачности» приложения, лучшей графики, интерфейса и взаимодействия экспертных систем.
По мнению рядовых пользователей и ведущих специалистов, в недалекой перспективе экспертные системы найдут следующее применение:
1) экспертные системы будут играть ведущую роль на всех стадиях проектирования, разработки, производства, распределения, отладки, контроля и оказания услуг;
2) технология экспертных систем, получившая широкое коммерческое распространение, обеспечит революционный прорыв в интеграции приложений из готовых интеллектуально-взаимодействующих модулей.
В общем случае экспертные системы предназначены для так называемых неформализованных задач, т. е. экспертные системы не отвергают и не заменяют традиционного подхода к разработке программ, ориентированного на решение формализованных задач, но дополняют их, тем самым значительно расширяя возможности. Именно этого и не может сделать простой человек-эксперт.
Такие сложные неформализованные задачи характеризуются:
1) ошибочностью, неточностью, неоднозначностью, а также неполнотой и противоречивостью исходных данных;
2) ошибочностью, неоднозначностью, неточностью, неполнотой и противоречивостью знаний о проблемной области и решаемой задаче;
3) большой размерностью пространства решений конкретной задачи;
4) динамической изменчивостью данных и знаний непосредственно в процессе решения такой неформализованной задачи.
Экспертные системы главным образом основаны на эвристическом поиске решения, а не на исполнении известного алгоритма. В этом одно из главных преимуществ технологии экспертных систем перед традиционным подходом к разработке программ. Именно это и позволяет им так хорошо справляться с поставленными перед ними задачами.
Технология экспертных систем используется для решения самых различных задач. Перечислим основные из подобных задач.
1. Интерпретация.
Экспертные системы, выполняющие интерпретацию, чаще всего применяют показания различных приборов с целью описания положения дел.
Интерпретирующие экспертные системы способны обрабатывать самые различные виды информации. Примером может послужить использование данных спектрального анализа и изменения характеристик веществ для определения их состава и свойств. Также примером может служить интерпретация показаний измерительных приборов в котельной для описания состояния котлов и воды в них.
Интерпретирующие системы чаще всего имеют дело непосредственно с показаниями. В связи с этим возникают затруднения, которых нет у других видов систем. Что это за затруднения? Эти затруднения возникают из-за того, что экспертным системам приходится интерпретировать засоренную лишним, неполную, ненадежную или неверную информацию. Отсюда неизбежны либо ошибки, либо значительное увеличение обработки данных.
2. Прогнозирование.
Экспертные системы, осуществляющие прогноз чего-либо, определяют вероятностные условия заданных ситуаций. Примерами служат прогноз ущерба, причиненного урожаю хлебов неблагоприятными погодными условиями, оценивание спроса на газ на мировом рынке, прогнозирование погоды по данным метеорологических станций. Системы прогнозирования иногда применяют моделирование, т. е. такие программы, которые отображают некоторые взаимосвязи в реальном мире, чтобы воссоздать их в среде программирования, и потом спроектировать ситуации, которые могут возникнуть при тех или иных исходных данных.
3. Диагностика различных приборов.
Экспертные системы производят такую диагностику, применяя описания какой-либо ситуации, поведения или данных о строении различных компонентов, чтобы определить возможные причины неисправно работающей диагностируемой системы. Примерами служат установление обстоятельств заболевания по симптомам, которые наблюдаются у больных (в медицине); определение неисправностей в электронных схемах и определение неисправных компонентов в механизмах различных приборов. Системы диагностики довольно часто являются помощниками, которые не только ставят диагноз, но и помогают в устранении неполадок. В таких случаях данные системы вполне могут взаимодействовать с пользователем, чтобы оказать помощь при поиске неполадок, а потом привести список действий, необходимых для их устранения. В настоящее время многие диагностические системы разрабатываются в качестве приложений к инженерному делу и компьютерным системам.
4. Планирование различных событий.
Экспертные системы, предназначенные для планирования, проектируют различные операции. Системы предопределяют практически полную последовательность действий, прежде чем начнется их реализация.
Примерами такого планирования событий могут служить создания планов военных действий как оборонительного, так и наступательного характера, предопределенного на определенный срок с целью получения преимущества перед вражескими силами.
5. Проектирование.
Экспертные системы, выполняющие проектирование, разрабатывают различные формы объектов, учитывая сложившиеся обстоятельства и все сопутствующие факторы.
В качестве примера можно рассмотреть генную инженерию.
6. Контроль.
Экспертные системы, осуществляющие контроль, сравнивают настоящее поведение системы с ее ожидаемым поведением. Наблюдающие экспертные системы обнаруживают контролируемое поведение, которое подтверждает их ожидания по сравнению с нормальным поведением или их предположением о потенциальных отклонениях. Контролирующие экспертные системы по своей сути должны работать в режиме реального времени и реализовывать зависящую как от времени, так и от контекста интерпретацию поведения контролируемого объекта.
В качестве примера можно привести слежение за показаниями измерительных приборов в атомных реакторах с целью обнаружения аварийных ситуаций или оценку данных диагностики пациентов, находящихся в блоке интенсивного лечения.
7. Управление.
Ведь широко известно, что экспертные системы, осуществляющие управление, весьма результативно руководят поведением системы в целом. Примером служит управление различными производствами, а также распределением компьютерных систем. Управляющие экспертные системы должны включать в себя наблюдающие компоненты, для того, чтобы контролировать поведение объекта на протяжении длительного времени, но они могут нуждаться и в других компонентах из уже проанализированных типов задач.
Экспертные системы применяются в самых различных областях: финансовых операциях, нефтяной и газовой промышленности. Технология экспертных систем может быть применена также в энергетике, транспортном хозяйстве, фармацевтическом производстве, космических разработках, металлургической и горной промышленностях, химии и многих других областях.
