Тема дипломного проекта: «Расчет параметров асинхронного энергосберегающего электродвигателя».

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

Объект исследования - расчет параметров электродвигателя.

Цель работы - создание компьютерной программы для расчета и исследования энергосберегающего асинхронного двигателя с индивидуальными номинальными данными.

В результате в среде разработки Borland C++ Builder была создана компьютерная программа «Электродвигатель». С помощью инструментальных средств, этой программы проведен расчет параметров асинхронного электродвигателя.

Для работы приложения необходимо наличие интерфейса «Microsoft ActiveX Data Objects» (ADO). Минимальные системные требования Pentium II 300 с 64 мегабайтами оперативной памяти, оперативной памяти операционная система Microsoft Windows.

Разработанный программный продукт рекомендуется для специалистов в области электромашиностроения, электропривода и ремонта электрических машин.

Объем отчета 87 страниц. Отчет содержит 30 таблиц, 22 иллюстрации и одно приложение. В работе использовалось 6 литературных источников.

СОДЕРЖАНИЕ

Характеристики степеней защиты электрических машин обозначают двумя латинскими буквами IP (International Protection) и двумя цифрами.

Первая цифра (от 0 до 6) характеризует степень защиты персонала от соприкосновения с движущимися или находящимися под напряжением частями, а также от попадания внутрь машины твердых посторонних предметов; вторая (от 0 до 8) - степень защиты от проникновения внутрь машины влаги. Таким образом, открытые машины в которых не предусмотрено никаких мер защиты, обозначаются IP00.

Наиболее распространенными исполнениями машин по степени защиты являются IP22, IP23, IP44, и IP57.

Исполнения IP22 и IP23 соответствуют защите от возможности соприкосновения с токоведущими и вращающимися частями машины пальцев человека и твердых предметов диаметром более 12,5 мм, а также защите от проникновения внутрь машины капель воды, попадающих под углом не более к вертикали (IP22) или не более (IP23) и продувом воздуха через машину. При этом вентилятор располагается на валу машины, а воздух, проходя внутри корпуса, охлаждает обмотки и сердечники. Двигатели этих исполнений назвали каплезащищенными. Они выполняются с самовентиляцией.

Машины исполнения IP44 защищены от возможности соприкосновения инструментов, проволоки или других предметов, толщина которых не превышает 1мм, с токоведущими частями, а также от попадания внутрь двигателя предметов диаметром более 1 мм.

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

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

1.1.3 Принцип действия трехфазного асинхронного двигателя

При подаче трехфазного напряжения на зажимы статорной обмотки в магнитной системе двигателя возникает вращающееся магнитное поле с полюсами , эквивалентное полю постоянного магнита.

Для рассмотрения принципа действия двигателя условно заменим вращающееся магнитное поле статора полем постоянного магнита, который будем вращать по часовой стрелке, а короткозамкнутую обмотку ротора - одним короткозамкнутым витком, закрепленным на осях с возможностью вращения. Это изображено на рисунке 1.5.

Рисунок 1.5 - Принцип действия асинхронного двигателя

В момент запуска двигателя, когда ротор неподвижен, а внешнее магнитное поле начало вращаться, силовые линии этого поля пересекают обмотки ротора и наводят в ней ЭДС, направление которой можно определить, используя правило правой руки.

Так как ЭДС возникает в замкнутом витке, то под ее действием пойдет электрический ток, практически совпадающий по фазе с ЭДС.

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

Если применить это правило, то окажется, что верхний проводник выталкивается из поля вправо, а нижний - влево, т.е. электромагнитные силы, приложенные к неподвижному ротору, создают пусковой момент, стремящийся повернуть ротор в направлении движения магнитного поля.

Когда электромагнитный момент, действующий на неподвижный ротор, превышает тормозной момент на валу, ротор получает ускоренное движение в направлении вращения магнитного поля двигателя.

По мере возрастания частоты вращения ротора относительная разность частот сокращается, вследствие чего уменьшаются величины ЭДС и тока в проводниках ротора, что влечет за собой соответствующее уменьшение вращающего момента.

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

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

Магнитное поле статора и ротора асинхронного двигателя вращаются в пространстве с разной частотой: частота оси вращения ротора двигателя всегда меньше частоты вращения магнитного поля статора. С этим связано название машины: асинхронный двигатель.

При анализе работы асинхронной машины часто пользуются безразмерным параметром , называемым скольжением и определяемым разностью частот вращения магнитного поля статора и ротора , выраженной в относительных единицах (отнесенной к ):

(1.1)

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

1.2 Расчет параметров асинхронного электродвигателя

Алгоритм расчета традиционного асинхронного двигателя представлен на рисунке 1.6. В блоках 1,2,3 вводятся исходные данные, предварительно определяются размеры магнитопровода, вычисляются параметры обмотки статора, проверяется магнитная индукция в воздушном зазоре . Если больше допустимой , уменьшают предварительную длину сердечника статора . Определяют уровень линейных нагрузок . Если уровень линейных нагрузок превышает допустимый уровень (блок 4), то переходят в блок 3 для перерасчета магнитного потока. В блоке 5 определяются геометрические размеры пазов статора, тепловая нагрузка статора. Если полученное значение тепловой нагрузки превышает допустимое значение более чем на 10%, выбирается проводник большего диаметра с учетом соответствующего уменьшения плотности тока . В Блоках 7,8,9,10 осуществляется расчет параметров короткозамкнутого или фазного ротора, электрических параметров обмоток, намагничивающего тока.

Если магнитная индукция в спинке ротора превышает допустимые значения, то уменьшается высота паза ротора . В блоках 11 и 12 проверяются на допустимые значения коэффициент насыщения магнитной цепи и коэффициент рассеяния статора . Если и при этом , то определяют э. д. с. холостого хода , где - коэффициент сопротивления статора. При отличии от значения э. д. с. более чем на 3% повторяют расчет намагничивающего тока при магнитных индукциях , , , , , измененных пропорционально отношению . В блоке 13 происходит расчет рабочих и пусковых характеристик, тепловой расчет, расчет массы двигателя.

1.3 Реляционные базы данных

Реляционная модель данных была предложена Е.Ф.Коддом (Dr. E.F.Codd), известным исследователем в области баз данных, в 1969 году, когда он был сотрудником фирмы IBM. Впервые основные концепции этой модели были опубликованы в 1970 г.

Реляционная база данных представляет собой хранилище данных, содержащее набор двухмерных таблиц. Набор средств для управления подобным хранилищем называется реляционной системой управления базами данных (РСУБД). РСУБД может содержать утилиты, приложения, сервисы, библиотеки, средства создания приложений и другие компоненты.

Любая таблица реляционной базы данных состоит из строк (называемых также записями) и столбцов (называемых также полями).

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

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

· Каждое значение, содержащееся на пересечении строки и колонки, должно быть атомарным (то есть не расчленяемым на несколько значений).

· Значения данных в одной и той же колонке должны принадлежать к одному и тому же типу, доступному для использования в данной СУБД.

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

· Каждое поле имеет уникальное имя.

· Последовательность полей в таблице несущественна.

· Последовательность записей также несущественна.

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

Поскольку последовательность колонок в таблице несущественна, обращение к ним производится по имени, и эти имена для данной таблицы уникальны (но не обязаны быть уникальными для всей базы данных).

1.3.1 Проектирование реляционных баз данных

При проектировании базы данных решаются две основных проблемы:

· Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области и было по возможности лучшим (эффективным, удобным и т.д.)? Часто эту проблему называют проблемой логического проектирования баз данных.

· Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создание каких дополнительных структур (например, индексов) потребовать и т.д.? Эту проблему называют проблемой физического проектирования баз данных.

В случае реляционных баз данных трудно представить какие-либо общие рецепты по части физического проектирования. Здесь слишком много зависит от используемой СУБД.

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

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

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

· первая нормальная форма (1NF);

· вторая нормальная форма (2NF);

· третья нормальная форма (3NF);

· нормальная форма Бойса-Кодда (BCNF);

· четвертая нормальная форма (4NF);

· пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).

Основные свойства нормальных форм:

· каждая следующая нормальная форма в некотором смысле лучше предыдущей;

· при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.

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

Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости.

В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть составными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y: R.X (r) R.Y.

Функциональная зависимость R.X (r) R.Y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X.

Функциональная зависимость R.X ??? R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X ??? R.Z и R.Z ??? R.Y и отсутствует функциональная зависимость R.Z --> R.X. (При отсутствии последнего требования мы имели бы "неинтересные" транзитивные зависимости в любом отношении, обладающем несколькими ключами.)

Неключевым атрибутом называется любой атрибут отношения, не входящий в состав первичного ключа (в частности, первичного).

Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других.

Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый неключевой атрибут полностью зависит от первичного ключа.

Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

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

1.3.2 Язык реляционных баз данных SQL

Structured Query Language представляет собой непроцедурный язык, используемый для управления данными реляционных СУБД. Термин «непроцедурный» означает, что на данном языке можно сформулировать, что нужно сделать с данными, но нельзя проинструктировать, как именно это следует сделать. Иными словами, в этом языке отсутствуют алгоритмические конструкции, такие как метки, операторы цикла, условные переходы и др.

Язык SQL был создан в начале 70-х годов в результате исследовательского проекта IBM, целью которого было создание языка манипуляции реляционными данными. Первоначально он назывался SEQUEL (Structured English Query Language), затем -- SEQUEL/2, а затем -- просто SQL. Официальный стандарт SQL был опубликован ANSI (American National Standards Institute -- Национальный институт стандартизации, США) в 1986 году (это наиболее часто используемая ныне реализация SQL). Данный стандарт был расширен в 1989 и 1992 годах. В настоящее время ведется работа над стандартом SQL3, содержащим некоторые объектно-ориентированные расширения.

Существует три уровня соответствия стандарту ANSI -- начальный, промежуточный и полный. Многие производители серверных СУБД, такие как IBM, Informix, Microsoft, Oracle и Sybase, применяют собственные реализации SQL, основанные на стандарте ANSI (отвечающие как минимум начальному уровню соответствия стандарту) и содержащие некоторые расширения, специфические для данной СУБД.

Предположим, что имеется база данных, управляемая с помощью какой-либо СУБД. Для извлечения из нее данных используется запрос, сформулированный на языке SQL. СУБД обрабатывает этот запрос, извлекает запрашиваемые данные и возвращает их. Этот процесс схематически изображен на рисунке 1.7.

Рисунок 1.7 - Извлечение данных с использованием SQL запроса.

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

SQL сам по себе не является ни СУБД, ни отдельным продуктом. Это язык, применяемый для взаимодействия с СУБД и являющийся в определенном смысле ее неотъемлемой частью.

SQL содержит примерно 40 операторов для выполнения различных действий внутри СУБД. Ниже приводится краткое описание категорий этих операторов.

Data Definition Language содержит операторы, позволяющие создавать, изменять и уничтожать базы данных и объекты внутри них (таблицы, представления и др.).

Data Manipulation Language содержит операторы, позволяющие выбирать, добавлять, удалять и модифицировать данные. Эти операторы не обязаны завершать транзакцию, внутри которой они вызваны.

Операторы Transaction Control Language применяются для управления изменениями, выполненными группой операторов DML.

Операторы Data Control Language, иногда называемые операторами Access Control Language, применяются для осуществления административных функций, присваивающих или отменяющих право (привилегию) использовать базу данных, таблицы в базе данных, а также выполнять те или иные операторы SQL.

Операторы Cursor Control Language используются для определения курсора, подготовки SQL-предложений для выполнения, а также для некоторых других операторов.

Каждый оператор SQL начинается с глагола, представляющего собой ключевое слово, определяющее, что именно делает этот оператор (SELECT, INSERT, DELETE...). В операторе содержатся также предложения, содержащие сведения о том, над какими данными производятся операции. Каждое предложение начинается с ключевого слова, такого как FROM, WHERE и др. Структура предложения зависит от его типа -- ряд предложений содержит имена таблиц или полей, некоторые могут содержать дополнительные ключевые слова, константы или выражения.

Все операторы SQL имеют вид, показанный на рисунке 1.8.

Рисунок 1.8 - Общий вид операторов SQL

1.3.3 СУБД dBase и Visual dBase

Первая промышленная версия СУБД dBase -- dBase II (принадлежащая тогда компании Ashton-Tate, приобретенной позже компанией Borland) появилась в начале 80-х годов. Благодаря простоте в использовании, нетребовательности к ресурсам компьютера и, что не менее важно, грамотной маркетинговой политике компании-производителя этот продукт приобрел немалую популярность, а с выходом следующих его версий -- dBase III и dBase III Plus (1986 г.), оснащенных весьма комфортной по тем временам средой разработки и средствами манипуляции данными, быстро занял лидирующие позиции среди настольных СУБД и средств создания использующих их приложений.

Хранение данных в dBase основано на принципе «одна таблица -- один файл» (эти файлы обычно имеют расширение *.dbf). MEMO-поля и BLOB-поля (доступные в поздних версиях dBase) хранятся в отдельных файлах (обычно с расширением *.dbt). Индексы для таблиц также хранятся в отдельных файлах. При этом в ранних версиях этой СУБД требовалась специальная операция реиндексирования для приведения индексов в соответствие с текущим состоянием таблицы.

Формат данных dBase является открытым, что позволило ряду других производителей заимствовать его для создания dBase-подобных СУБД, частично совместимых с dBase по форматам данных.

Помимо популярного формата данных dBase является родоначальником и некогда популярного семейства языков программирования, получившего называние xBase. Все языки этого семейства, использующиеся и в FoxBase, и в Clipper, содержат сходный набор команд для манипуляции данными и являются по существу интерпретируемыми языками. В роли интерпретатора команд xBase выступает обычно либо среда разработки приложения на этом языке, либо среда времени выполнения, которую можно поставлять вместе с приложением. Отметим, что для скрытия исходного текста xBase-приложения подобные СУБД обычно содержат утилиты для псевдокомпиляции кода, который затем поставляется вместе со средой времени выполнения. В случае Clipper среда времени выполнения содержится в самом исполняемом файле (и сам Clipper формально считается компилятором), но тем не менее этот язык по существу также является интерпретируемым.

Для работы с данными формата dBase (или иных dBase-подобных СУБД) совершенно необязательно пользоваться диалектами xBase. Доступ к этим данным возможен с помощью ODBC API (и соответствующих драйверов) и некоторых других механизмов доступа к данным (например, Borland Database Engine, некоторых библиотек других производителей типа СodeBase фирмы Sequenter), и это позволяет создавать приложения, использующие формат данных dBase, практически с помощью любого средства разработки, поддерживающего один из этих механизмов доступа к данным.

После покупки dBase компанией Borland этот продукт, получивший впоследствии название Visual dBase, приобрел набор дополнительных возможностей, характерных для средств разработки этой компании и для имевшейся у нее другой настольной СУБД -- Paradox. Среди этих возможностей были специальные типы полей для графических данных, поддерживаемые индексы, хранение правил ссылочной целостности внутри самой базы данных, а также возможность манипулировать данными других форматов, в частности серверных СУБД, за счет использования BDE API и SQL Links.

В настоящее время Visual dBase принадлежит компании dBase, Inc. Его последняя версия -- Visual dBase 7.5 имеет следующие возможности:

· Средства манипуляции данными dBase и FoxPro всех версий.

· Средства создания форм, отчетов и приложений.

· Средства публикации данных в Internet и создания Web-клиентов.

· Ядро доступа к данным Advantage Database Server фирмы Extended Systems и ODBC-драйвер для доступа к данным этой СУБД.

· Средства публикации отчетов в Web.

· Средства визуального построения запросов.

· Средства генерации исполняемых файлов и дистрибутивов.

Компания dBase, Inc объявила также о проекте dBASE Open Source, целью которого является разработка сообществом пользователей dBase новых компонентов и классов с целью включения их в последующую версию dBase (получившую название dBase 2000). Иными словами, имеется тенденция превращения dBase (или его частей) в некоммерческий продукт с доступными исходными текстами.

1.3.4 СУБД Access

Первая версия СУБД Access появилась в начале 90-х годов. Это была первая настольная реляционная СУБД для 16-разрядной версии Windows. Популярность Access значительно возросла после включения этой СУБД в состав Microsoft Office.

В отличие от Visual FoxPro, фактически превратившегося в средство разработки приложений, Access ориентирован в первую очередь на пользователей Microsoft Office, в том числе и не знакомых с программированием. Это, в частности, проявилось в том, что вся информация, относящаяся к конкретной базе данных, а именно таблицы, индексы (естественно, поддерживаемые), правила ссылочной целостности, бизнес-правила, список пользователей, а также формы и отчеты хранятся в одном файле, что в целом удобно для начинающих пользователей.

Последняя версия этой СУБД -- Access 2003, в состав которой входят:

· Средства манипуляции данными Access и данными, доступными через ODBC (последние могут быть «присоединены» к базе данных Access).

· Средства создания форм, отчетов и приложений; при этом отчеты могут быть экспортированы в формат Microsoft Word или Microsoft Excel, а для создания приложений используется Visual Basic for Applications, общий для всех составных частей Microsoft Office.

· Средства публикации отчетов в Internet.

· Средства создания интерактивных Web-приложений для работы с данными (Data Access Pages).

· Средства доступа к данным серверных СУБД через OLE DB.

· Средства создания клиентских приложений для Microsoft SQL Server.

· Средства администрирования Microsoft SQL Server.

Иными словами, Microsoft Access может быть использован, с одной стороны, в качестве настольной СУБД и составной части офисного пакета, а с другой стороны, в качестве клиента Microsoft SQL Server, позволяющего осуществлять его администрирование, манипуляцию его данными и создание приложений для этого сервера.

Помимо манипуляции данными Microsoft SQL Server, Access 2003 позволяет также в качестве хранилища данных использовать Microsoft Data Engine (MSDE), представляющий собой по существу настольный сервер баз данных, совместимый с Microsoft SQL Server.

1.3.5 Технологии ADO и ODBC

Существует множество различных СУБД. Любая СУБД предоставляет некий программный интерфейс (API - Application Programming Interface) с помощью которого можно работать с СУБД. Обычно используется технология клиент-сервер, т.е. прикладная программа с помощью API соединяется с СУБД на сервере, который является другой машиной где-то в сети. Однако при таком подходе возникают проблемы если приложению требуется работать с несколькими СУБД, причин по которым такая необходимость может возникнуть множество. В этом случае разработка такого приложения значительно облегчилась бы при использовании некоторого универсального API для работы с любой СУБД. Поэтому появились универсальные интерфейсы для доступа к любым СУБД ADO, BDE, ODBC. Они очень похожи друг на друга и имеют общие принципы, однако разработаны разными компаниями и поэтому с точки зрения прикладной программы различные. Есть некоторые пересечения у этих технологий, например BDE может использовать драйвера ODBC, а некоторые драйвера ODBC наоборот BDE (например, для доступа к файловым таблицам DBF и т.п.).

Во всех этих интерфейсах можно выделить следующие понятия:

· Data source - клиентская часть СУБД с собственным API (Native API).

· Driver - осуществляет связь с конкретной СУБД через API предоставляемый ей, обеспечивает выполнение запросов на языке SQL и получение результатов. Может немного изменять текст SQL запроса в соответствии с синтаксисом конкретной СУБД.

· Driver Manager - осуществляет управление драйверами необходимыми приложению (загружает, выгружает) а также предоставляет API и обеспечивает передачу вызова собственного API драйверу.

Общая схема изображена на рисунке 1.9.

Рисунок 1.9 - Общая схема доступа к СУБД

OLE DB и ADO - часть универсального механизма доступа к данным Microsoft (Microsoft Universal Data Access), позволяющая осуществить доступ как к реляционным, так и к нереляционным источникам данных, таким как файловая система, данные электронной почты, многомерные хранилища данных и др.

Microsoft ActiveX Data Objects (ADO) -- это набор библиотек, содержащих COM-объекты, реализующие прикладной программный интерфейс для доступа к таким данным и используемые в клиентских приложениях. ADO использует библиотеки OLE DB, предоставляющие низкоуровневый интерфейс для доступа к данным. OLE DB предоставляет доступ к данным с помощью COM-интерфейсов. Можно также использовать OLE DB непосредственно, минуя ADO.

Для доступа к источнику данных с помощью OLE DB требуется, чтобы на компьютере, где используется клиентское приложение, был установлен OLE DB-провайдер для данной СУБД. OLE DB-провайдер представляет собой DLL, загружаемую в адресное пространство клиентского приложения и используемую для доступа к источнику данных. Для каждого типа СУБД нужен собственный OLE DB-провайдер, так как эти поставщики базируются на функциях клиентских API, разных для различных СУБД.

Среди OLE DB-провайдеров для разных источников данных имеется специальный провайдер Microsoft OLE DB Provider for ODBC Drivers. Этот провайдер использует не API клиентской части какой-либо СУБД, а интерфейс ODBC API, поэтому он применяется вместе с ODBC-драйвером для выбранной СУБД.

ADO представляет собой высокоуровневый программный интерфейс для доступа к OLE DB-интерфейсам. Он позволяет манипулировать данными с помощью любых OLE DB-провайдеров, как входящих в состав Microsoft Data Access Components некоторых других продуктов Microsoft, так и произведенных сторонними производителями. ADO содержит набор объектов, используемых для соединения с источником данных, для чтения, добавления, удаления и модификации данных.

Объект ADO Connection применяется для установки связи с источником данных. Он представляет единственную сессию. Этот объект позволяет изменить параметры соединения с базой данных, а также начать или завершить транзакцию. Используя объект Connection, мы можем выполнять команды (например, SQL-запросы) с помощью метода Execute. Если команда возвращает набор данных, автоматически создается объект Recordset, который возвращается в результате выполнения этого метода.

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

Объект Command представляет собой команду, которую можно выполнить в источнике данных. Команда может содержать SQL-предложение или вызов хранимой процедуры. В последнем случае для определения параметров процедуры может быть использована коллекция Parameters объекта Command.

Объект Recordset -- это набор записей, полученных из источника данных, и может быть использован для добавления, удаления, изменения, просмотра записей. Данный объект может быть открыт непосредственно или создан с помощью объектов Connection или Command.

Объект Field -- это колонка в наборе данных, представленных объектом Recordset. Он может быть использован для получения значений конкретного поля, его модификации, извлечения метаданных, таких как имя колонки и тип данных.

На рисунке 1.10 изображена объектная модель ADO.

Рисунок 1.10 - Объектная модель ADO

Библиотека ADO 2.5, являющаяся составной частью операционной системы Windows 2000, содержит два новых объекта -- Record и Stream.

Объект Record представляет одну запись внутри объекта Recordset и может быть использован для работы с гетерогенными и иерархическими данными.

Объект Stream представляет двоичные данные, связанные с объектом Record. Например, если объект Record представляет собой файл, то его объект Stream должен содержать данные внутри этого файла.

ADO входит в состав таких широко используемых продуктов, как Microsoft Office 2000 и Microsoft Internet Explorer 5.0, а также включен в ядро операционных систем семейства Windows 2000.

1.4 Интерполяция функций. Приближение Лагранжа

Интерполирование предполагает вычисление неизвестных значений функции путем получения взвешенного среднего значения функции в известных соседних точках. При линейном интерполировании используется отрезок прямой, которая проходит через две точки. Тангенс угла наклона между точками и равен

.(1.1)

Формула, использующая тангенс угла наклона прямой в точке:

(1.2)

или

.(1.3)

Если разложить формулу (1.3), то в результате получим полином степени . Вычисляя в точках и , получаем соответственно точки и :

(1.4)

Французский математик Жозеф Луи Лагранж (Joseph Louis Lagrange) использовал для нахождения этого полинома несколько иной метод. Он отметил, что полином можно записать в виде

.(1.5)

Каждый член в правой части формулы (1.5) включает линейный множитель, поэтому сумма является полиномом степени . Обозначим отношения

 и .(1.6)

Члены и называются коэффициентами полинома Лагранжа, основанные на узлах и . Используя это замечание, можно записать формулу (1.5) в виде суммы

.(1.7)

Предположим, что ордината вычислена по формуле . Если используется для приближения на интервале , такой процесс называется интерполированием. Если (или ), то использование называют экстраполированием.

Обобщением формулы (1.7) является построение полинома степени, не большей, чем , который проходит через точку , , … , и имеет вид

,(1.8)

где - коэффициенты полинома Лагранжа основанного на узлах:

. (1.9)

Понятно, что члены и не появляются в правой части выражения (8). Это дает возможность ввести обозначения для умножения и записать

.(1.10)

Простые вычисления показывают, что для каждого фиксированного коэффициенты полинома Лагранжа обладают свойствами

, когда и , когда .(1.11)

Предположим, что и - узел. Если , то

,(1.12)

где - полином, которым приближают :

.(1.13)

Остаточный член имеет вид

,(1.14)

для некоторого , лежащего на интервале .

2 СПЕЦИАЛЬНАЯ ЧАСТЬ ОПИСАНИЕ ПРОГРАММЫ

2.1 Структура базы данных

2.1.1 Параметры электродвигателя

Параметры электродвигателя могут принимать целые, действительные, или строковые значения. В последнем случае набор значений фиксирован. Каждый параметр имеет уникальное наименование. Пределы возможных значений параметров, а также количество знаков после запятой зависит от единицы измерения параметра. Для удобства навигации все параметры разбиты на группы. Каждый параметр может принадлежать только к одной группе и иметь только одну единицу измерения. В таблицах 2.1 - 2.4 даны описания структуры таблиц, содержащих информацию о параметрах электродвигателя.

Таблица 2.1 - описание структуры таблицы Mparameters.

Таблица 2.2 - описание структуры таблицы Units

Таблица 2.3 - описание структуры таблицы Enums

Таблица 2.4 - описание структуры таблицы Groups

2.1.2 Зависимости

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

В программе имеются средства для работы с тремя видами зависимостей.

· Формула - пользователь указывает формулу по которой будет определяться параметр.

· Таблица - пользователь выбирает таблицу (либо создает новую) и указывает соответствие между полями таблицы и параметрами двигателя.

· Функция - представляет собой протабулированный график функции. Пользователь указывает параметр-аргумент и параметр- значение функции. Параметр-значение будет определен с помощью интерполяции полиномом Лагранжа заданной степени.

Для каждой зависимости может быть задано условие на использование в зависимости от значений параметров двигателя. Также для всех зависимостей указывается метод расчета к которому они относятся. При подборе зависимостей для расчета какого-либо параметра в первую очередь просматриваются зависимости принадлежащие к заданному методу, а затем - к методу расчета с именем «Основной метод». В таблицах 2.5 - 2.8 даны описания структуры таблиц, содержащих информацию о зависимостях между параметрами.

Таблица 2.5 - описание структуры таблицы Dependences

Таблица 2.6 - описание структуры таблицы Descriptions

Таблица 2.7 - описание структуры таблицы Methods

Запись содержащую метод с именем «Основной метод» - редактировать нельзя.

Таблица 2.8 - описание структуры таблицы Tables .

Вся структура базы данных представлена на рисунке 2.1

Рисунок 2.1 - Структура базы данных

2.2 Редактор таблиц базы данных

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

Рисунок 2.2 - Редактор таблиц

В верхней части редактора расположена панель инструментов. Ниже приведены назначения кнопок на панели инструментов редактора слева-направо:

· Перейти к первой записи

· Перейти к предыдущей записи

· Перейти к следующей записи

· Перейти к последней записи

· Добавить запись

· Удалить запись

· Редактировать запись

· Отменить редактирование

· Обновить таблицу

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

Для поиска записи в редакторе имеются возможности сортировки и фильтрации.

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

Для работы с таблицами параметров и зависимостей можно дополнительно фильтровать записи соответственно по группе параметра и виду зависимости.

2.3 Ввод формул в программе

Формулы в программе представляют собой некоторое арифметическое выражение, в котором могут участвовать параметры электродвигателя. Для использования параметра в формуле, надо указать его обозначение. Обозначение параметра имеет следующий вид: латинская буква «P» и следующий за ней индекс параметра. Например, для параметра с индексом 500 обозначение будет «P500». Для вставки обозначения в выражение пользователь может пользоваться диалогом выбора параметров. В выражениях можно использовать:

· арифметические операции: «+», «-», «*», «/», «^».

· операции сравнения: «=», «<>», «>», «<», «>=», «<=».

· логические операции: «AND», «OR», «NOT».

· математические функции: «abs», «atn», «cos», «exp», «int», «log», «sgn», «sin», «sqr», «tan».

· Операторы приоритета «(», «)».

Строковые значения в выражениях должны заключаться в одинарные кавычки.

Пример выражения: «P100*1000/(P1300*P1400)».

2.4 Поиск пути решения

Для нахождения значения параметра требуется построить последовательность вычислений параметров (если такая существует) по которой можно найти заданный параметр. Эта последовательность (или по-другому путь решения) должна быть такой, чтобы к моменту проведения вычислений по каждой зависимости значения всех необходимых параметров, использующихся в этой зависимости, были уже известны.

Поиск пути решения для параметра, производится в функции FindPath. Аргументом функции является неизвестный параметр электродвигателя. Результат работы функции - значение true, если для параметра путь решения успешно найден и значение false в противном случае.

Рассмотрим работу этой функции. Пусть в качестве аргумента ей передан параметр с индексом I.

Из базы данных выбирается зависимость по которой можно определить данный параметр. При этом учитывается заданный метод решения.

При наличии условия на использование зависимости. Для каждого неизвестного параметра в условии запускается процедура нахождения пути решения и процедура расчета. Если все параметры в выражении условия известны, то производится вычисление этого выражения. В случае когда результатом расчета выражения является 0, либо когда не удается определить хотя бы один из параметров в выражении, рассматриваемая зависимость отвергается и производится поиск новой зависимости для параметра с индексом I.

Для каждого параметра, используемого в зависимости, выполняются следующие проверки:

1. Если значение параметра известно (т.е. параметр входит в состав исходных данных), то переходим к просмотру следующего параметра.

2. Если этот параметр просматривался ранее (т.е. для него уже вызывалась функция FindPath), но путь решения пока не найден, то данная зависимость является обратной к одной из уже рассмотренных и на текущем этапе должна быть отвергнута.

3. Если этот параметр просматривался ранее, и путь решения для него уже найден, то для него и для всех параметров, участвующих в его нахождении помечается порядок расчета после параметра с индексом I.

4. Если параметр неизвестен и не был рассмотрен ранее, то происходит рекурсивный вызов функции FindPath для этого параметра. Если результатом работы функции будет значение true, то переходим к просмотру следующего параметра, если false - берем другую зависимость.

Если эти проверки были выполнены, для каждого параметра, то зависимость включается в путь решения и функция возвращает значение true.

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

2.5 Работа в программе «Электродвигатель»

2.5.1 Соединение с базой данных

При запуске программа производит попытку подключения к базе данных. Подключение происходит посредством интерфейса ADO. Параметры строки связи для подключения хранятся в секции «[DataBase]» файла настроек Options.ini, который находится в рабочем каталоге программы. В этом файле значение ключа «Data» определяет местонахождение базы данных, значение ключа «Provider» определяет поставщика Базы данных и параметры подключения. В случае, когда доступ к базе данных защищен паролем, при запуске программы пользователю предлагается ввести пароль. Если подключение к базе данных не было произведено, то после запуска программы пользователю будет доступен только один пункт главного меню - «Настройка программы». В диалоге Настроек программы пользователь может указать все необходимые параметры строки связи и выполнить соединение с базой данных.

2.5.2 Справочники

Из главного меню «Справочники» можно вызвать редакторы для таблиц Units, Tables, Groups и Methods.

Редактирование таблиц методов вычислений и групп параметров происходит непосредственно в редакторе. Имена методов и групп параметров должны быть уникальными. Метод с именем «Основной метод» удалить или изменить нельзя.