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

В реляционной базе данных, в частности, реализованной в СУБД Microsoft Access, для однозначного распознавания экземпляра объекта подобно приведенному выше понятию «ключ» вводится уникальный идентификатор – первичный ключ. Первичный ключ – это уникальная характеристика для каждой записи в пределах таблицы. Первичный ключ таблицы помимо однозначной идентификации записей позволяет реализовать и связи между таблицами. Благодаря связям информация из одной таблицы становится доступной для другой. Связи устанавливаются за счет того, что в разных таблицах присутствуют поля с одинаковыми значениями.

Покажем на примере преимущества реляционных моделей данных перед моделями данных, построенными на основе сплошных таблиц.

Пример. Разработка фрагмента модели данных «Сотрудники – проекты». Пусть речь идет о технологической службе предприятия, сотрудники которой, занимаясь технологической подготовкой производства, естественным образом участвуют в разработке проектов некоторых изделий. Исходные данные по сотрудникам представлены в так называемой сплошной таблице – см. табл. 13.1.

 

Таблица 13.1

Исходная сплошная таблица «Сотрудники – проекты»
Номер сотрудника	Номер проекта	Номер задания	Фамилия	Должность	Оклад	Отдел	Телефон
1010	AB-115	1.1	Петров	Инженер-технолог	5500	115	6-15
1010	KN-20	1.3	Петров	Инженер-технолог	5500	115	6-15
1015	ZT-14	5.2	Васильев	Инженер-технолог	5500	115	6-15
1036	ZT-14	5.4	Куликов	Техник	3000	110	5-46
2122	AK-177	1.2	Зорин	Начальник отдела	6500	105	6-88
2122	BC-18	3.6	Зорин	Начальник отдела	6500	105	6-88

 

В данной таблице имеются следующие недостатки в представлении данных:

1. Дублируется информация о сотрудниках, т.к. сотрудник может участвовать в нескольких проектах.

2. В таблицу нельзя вписать тех сотрудников, которые не заняты в проектах именно сейчас, а также сотрудников, которые вообще не работают над проектами, иначе таблица не будет сплошной.

3. Если сотрудник увольняется, запись о нем удаляется из таблицы, а вместе с ней – и проект, хотя работа над ним должна продолжаться.

Данный пример является классическим, поскольку отмеченные выше проблемы характерны для всех сплошных файлов.

---

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

Чтобы устранить указанные выше недостатки, разобьем исходную таблицу на две: «Проекты» и «Сотрудники» - табл. 13.2 и 13.3.

Таблица 13.2

Проекты
Номер сотрудника	Номер проекта	Номер задания
1010	AB-115	1.1
1010	KN-20	1.3
1015	ZT-14	5.2
1036	ZT-14	5.4
2122	AK-177	1.2
2122	BC-18	3.6

 

Таблица 13.3

Сотрудники
Номер сотрудника	Фамилия	Должность	Оклад	Отдел	Телефон
1010	Петров	Инженер-технолог	5500	115	6-15
1015	Васильев	Инженер-технолог	5500	115	6-15
1036	Куликов	Техник	3000	110	5-46
2122	Зорин	Начальник отдела	6500	105	6-88

 

Продолжим анализ и посмотрим на таблицу «Сотрудники». Несложно заметить следующие особенности:

1. Дублируется информация о телефонах для сотрудников одного отдела.

2. Если изменяется телефон отдела, необходимо изменять его у всех сотрудников отдела. Аналогичная ситуация будет наблюдаться при изменении размера окладов.

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

4. При увольнении все сотрудников не сохраняются данные о самом отделе.

Поэтому, следуя правилам нормализации, необходимо выполнить декомпозицию таблицы «Сотрудники» и разбить ее на три таблицы: «Сотрудники», «Должности», «Отделы» - табл.13.4, 13.5, 13.6.

Таблица 13.4

Сотрудники (окончательная таблица)
Номер сотрудника	Фамилия	Должность	Отдел
1010	Петров	Инженер-технолог	115
1015	Васильев	Инженер-технолог	115
1036	Куликов	Техник	110
2122	Зорин	Начальник отдела	105

 

Таблица 13.5

Должности
Должность	Оклад
Инженер-технолог	5500
Техник	3000
Начальник отдела	6500

 

Таблица 13.6

Отделы
Отдел	Телефон
115	6-15
110	5-46
105	6-88

 

Т.е окончательно сформированы четыре связанные между собой таблицы: «Проекты», «Сотрудники», «Должности» и «Отделы».

Покажем теперь логику представления фрагмента данных в БД «Режущие инструменты», а более подробно в ее разделе «Сверла». Информация о сверлах берется из справочника – см. табл.13.7.

 

Таблица 13.7

Справочная информация о сверлах
Обозначение	Диаметр, мм	Длина общая, мм	Длина режущей части, мм	Код хвостовика	Материал	ГОСТ
. . .	. . .	. . .	. . .	. . .	. . .	. . .
65	19,00	238	135	Морзе 2	Р6М5	10903
66	19,25	238	140	Морзе 2	Р6М5	10903
. . .	. . .	. . .	. . .	. . .	. . .	. . .

---

 

Общая структура данных показана на рис. 13.1.

Рис.13.1. Общая структура данных БД «Режущие инструменты»

После определения типа данных (здесь применяется два типа данных: «текстовый» - обозначен ниже буквами «С» и «числовой» - буквами «N») и длины полей получается логическая модель данных – рис. 13.2.

Рис.13.2. Логическая модель данных в БД «Режущие инструменты» в разделе «Сверла»

 

Ввиду того, что львиная доля работы по проектированию технологических процессов приходится на работу с данными и при этом перерабатывается очень большое количество информации, ряд САПР ТП построено на основе имеющихся СУБД. Это значительно облегчает создание прикладного программного обеспечения САПР. Так, например, САПР ТП «Техно/Про» построена на базе уже упоминавшейся СУБД Microsoft Access. Информация об этом мощном приложении изложена в специальной литературе и требует отдельного изучения, что не входит в рамки данной дисциплины. Отметим только, что физическое представление данных на диске в данной СУБД организуется в виде одного общего файла, файла базы данных, который имеет расширение .mdb.

Рис.13.1. Общая структура данных БД «Режущие инструменты»

После определения типа данных (здесь применяется два типа данных: «текстовый» - обозначен ниже буквами «С» и «числовой» - буквами «N») и длины полей получается логическая модель данных – рис. 13.2.

Рис.13.2. Логическая модель данных в БД «Режущие инструменты» в разделе «Сверла»

 

Ввиду того, что львиная доля работы по проектированию технологических процессов приходится на работу с данными и при этом перерабатывается очень большое количество информации, ряд САПР ТП построено на основе имеющихся СУБД. Это значительно облегчает создание прикладного программного обеспечения САПР. Так, например, САПР ТП «Техно/Про» построена на базе уже упоминавшейся СУБД Microsoft Access. Информация об этом мощном приложении изложена в специальной литературе и требует отдельного изучения, что не входит в рамки данной дисциплины. Отметим только, что физическое представление данных на диске в данной СУБД организуется в виде одного общего файла, файла базы данных, который имеет расширение .mdb.

м

ЛЕКЦИЯ 14

 

Лингвистическое обеспечение САПР технологических процессов

 

Лингвистическое обеспечение – совокупность языков, используемых в процессе разработки и эксплуатации САПР.

Под «языком» понимается любое средство общения, любая система символов и знаков для представления и обмена информацией.

Лингвистическое обеспечение образуется следующими языками:

• программирования;

• управления;

• проектирования.

Языки программирования необходимы для создания программного обеспечения при разработке САПР. В принципе языки программирования относят и к программному обеспечению САПР. Здесь мы их подробно рассматривать не будем, информация о них приведена в специальной литературе. Напомним лишь, что к наиболее распространенным языкам программирования относятся Pascal, Fortran, Basic, Си (различных версий). В настоящее время на их базе разработаны и повсеместно используются среды программирования такие, как, соответственно, Delphi, Visual Fortran, Visual Basic, Visual Си (также различных версий).

---

Языки управления служат для управления ЭВМ, периферийными устройствами. Это операционная система Windows, драйверы принтеров и т.д. Эти языки также относят и к программному обеспечению САПР. Они в требуемом в данном курсе объеме были описаны ранее.

Языки проектирования ориентированы на пользователей – проектировщиков и предназначены для эксплуатации САПР, в том числе и САПР технологических процессов (САПР ТП). На них мы и остановимся более подробно. Эта группа языков делится на:

• входные;

• внутренние;

• выходные.

Входные языки являются средством взаимодействия конечного пользователя с САПР, например, в ходе подготовки и ввода исходных данных или формирования проблемы.

Внутренние языки обычно скрыты от рядового пользователя и служат для представления информации, передаваемой между различными подсистемами САПР и ЭВМ.

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

Такое деление языков проектирования можно назвать классическим. В различных САПР ТП они могут применяться с различной степенью развернутости и в различном исполнении. В одних САПР ТП, реализующих, например, принцип синтеза технологических процессов, информация о детали для автоматического проектирования варианта ТП вводится единовременно. В других подобных системах применяется диалоговое проектирование (диалоговый синтез) ТП, и в них информация о детали вводится постепенно по ходу проектирования технологического процесса.

Так или иначе место языков проектирования на различных этапах переработки информации в САПР ТП (один из вариантов) показано на рис. 14.1.

Рис. 14.1. Преобразование информации в САПР

 

 

Языки проектирования, построенные на базе классификации

 

Эти языки применяются для укрупненного описания детали с целью поиска в базе данных ее аналога и типового (группового) технологического процесса. Эти языки разного исполнения, но построены, как правило, на базе известных классификаторов:

1. «Общесоюзного классификатора промышленной и сельскохозяйственной продукции (ОКП)»;

2. «Технологического классификатора деталей машиностроения и приборостроения».

Процесс кодирования сведений о детали заключается в присвоении ей цифрового кода по ОКП и дополнения его кодами основных технологических признаков. Схема (структура) конструкторско – технологического кода детали показана в таблице 14.1.

Таблица 14.1

Схема конструкторско - технологического кода детали
No позиции в коде	Классификационный признак
1 2 3 4	Индекс предприятия
5 6	Класс
7	Подкласс
8	Группа
9	Подгруппа
10	Вид
11 12 13 14	Регистрационный номер
15 16 17	Размерная характеристика
18 19	Группа материалов
20	Вид детали по технологическому процессу
21 22	Вид исходной заготовки
23 24	Точность
25	Параметр шероховатости
26	Характеристика элементов зубчатого зацепления
27	Характеристика термической обработки
28	Масса

---

 

Позиции с1 по 14 представляют собой конструкторский код детали, с 15 по 28 – технологический код детали. Позиции с 5 по 14 – код конструктивных признаков детали,

с 15 по 20 – основной технологический код, с 21 по 28 – дополнительный технологический код.

Конструктивное кодирование основано на разбиении всего множества деталей сначала на классы (тела вращения, корпусные детали и т.д.), затем каждого класса - на подклассы (для тел вращения – осей, валов и т.д.) и т.д. и присвоении каждому классу, подклассу и т.д. цифрового кода (номера).

Фрагмент технологического кодификатора показан ниже в табл. 14.2 и 14.3.

Таблица 14.2

Кодификатор размерной характеристики (фрагмент)
Наибольший наружный диаметр или ширина, мм	Код	Длина, мм	Код	Толщина или диаметр трубы, мм	Код
До 5	0	До 20	0	До 0,2	0
5 . . . 10	1	20 . . . 32	1	0,2 . . . 0,5	1
10 . . . 16	2	32 . . . 45	2	0,5 . . . 0,8	2
16 . . . 28	3	45 . . . 75	3	0,8 . . . 1,6	3
. . .	. . .	. . .	. . .	. . .	. . .

 

Таблица 14.2

Кодификатор группы материалов (фрагмент)
Материал	Код
Стали конструкционные Стали конструкционные с содержанием углерода, % до 0,25 0,25 . . . 0,6 более 0,6 . . .	00 01 02 03 . . .

 

Кроме определения конструкторско – технологического кода в некоторых языках дополнительно запрашивается другая информация о детали. Она бывает необходимой для автоматического назначения оборудования, нормирования технологического процесса и т.д.

 

Языки для диалогового проектирования технологических процессов

 

Исполнения таких языков разные. Это зависит от их разработки конкретными авторами или группами разработчиков. Кратко рассмотрим такой язык, применяемый для диалогового проектирования технологических процессов в рамках САПР ТП «ТехноПро»

(автор – Лихачев Андрей Андреевич, распространяется АО «Топ системы»).

Сразу следует отметить, что данная САПР ТП построена на основе СУБД Microsoft Access и поэтому многие сценарии работы естественным образом повторяют действия по работе с данной средой.

При проектировании технологического процесса в системе «ТехноПро» технолог общается с ЭВМ на языке, максимально приближенном к его предметной области. Он оперирует со знакомыми ему понятиями: деталь, операция, переход, карта, эскиз и т.д. Сведения о детали можно вводить с клавиатуры или считывать с введенного заранее в системе T-FLEX электронного чертежа – см. рис. 14.2.

Рис. 14.2. Ввод общих сведений о детали в САПР ТП «ТехноПро»

 

Форма для ввода информации, представленная на рисунке содержит привычные для Access и для Windows кнопки, поля, закладки и др. элементы.

На рис. 14.3 и 14.4 показаны формы для заполнения содержания операций и переходов соответственно. Маршрут операций и переходов представлены в виде «дерева», что упрощает формирование технологического процесса. Порядок следования операций или переходов можно изменять нажатием кнопок со стрелками вверх или вниз, при этом номера операций или переходов пересчитываются автоматически.

---

Смотрите также файлы

• Раб тетр. ХТИ.docx

• Практикум -2012.docx

• Строительство жилого дома в г. Абакане..doc

• Пособие 1С Бухгалтерия 8.1 2010.doc

• Методичка по истории.doc