Содержание к диссертации
Введение
1. Организация информационного обеспечения систем автоматизированного проектирования радиоэлектронной аппаратуры 11
1.1. Системы автоматизированного проектирования и моделирования РЭУ 14
1.2. Информационный фонд САПР 21
1.2.1. Состав информационного фонда схемотехнических САПР 22
1.2.2. Способы ведения информационного фонда САПР 23
1.3. Организации информационного фонда схемотехнических САПР на основе библиотек 26
1.4. Организация информационного фонда схемотехнических САПР на основе СУБД 30
1.5. Выводы 33
2. Модели данных для интегрированной бд схемных компонентов 35
2.1. Модель данных «Сущность-Связь» 36
2.2. Расширенная модель «Сущность-Связь» для технических систем 42
2.3. Наследование типов сущности и типов связи 44
2.4. Построение реляционной схемы из ER-диаграммы 45
2.5. Представление в реляционной схеме супертипов и подтипов Сущности 50
2.6. Схема данных интегрированной БД схемных компонентов 52
2.7. Выводы 53
3. Содержательный аспект информации о радиоэлектронных компонентах 54
3.1. Набор атрибутов для супертипа сущности «Модель схемного компонента» 54
3.1.1. Модель биполярного транзистора (Bipolar Transistor) 55
3.1.2. Модель полевого транзистора (Junction Field Effect Transistor) 63
3.1.3. Модель операционного усилителя (Linear Operational Amplifier) 67
3.2. Набор атрибутов для супертипа сущности «Электрический многополюсник» 75
3.3. Набор атрибутов для супертипа сущности «Типовой корпус» 85
3.4. Выводы 87
4. Реализация «ИБДСК» в среде Oracle и С# 88
4.1. Реализация базы данных в среде Oracle 89
4.1.1. Создание базы данных с помощью команды Transcat-SQL 89
4.1.2. Структура таблиц базы данных "ИБДСК " 89
4.1.3. Связь между таблицами 101
4.1.4. Система управления БД " ИБДСК " В СРЕДЕ Oracle 102
4.2. Подключение к базе данных Oracle из С# 104
4.3. Создание приложения в среде С# для работы с базой данных Oracle 113
4.3.1. Структура приложения в среде 113
4.3.2. Архитектура создания приложения 114
4.4. Выводы 121
Заключение 122
Список литературы 124
- Организации информационного фонда схемотехнических САПР на основе библиотек
- Расширенная модель «Сущность-Связь» для технических систем
- Набор атрибутов для супертипа сущности «Электрический многополюсник»
- Создание приложения в среде С# для работы с базой данных Oracle
Введение к работе
Актуальность исследования
В настоящее время наметилась тенденция коллективного использования САПР электронных схем в локальных вычислительных сетях и в сети Интернет. В качестве информационного обеспечения подобных систем используется сервер баз данных, содержащий всю необходимую справочную и проектную информацию, доступную с рабочих станций. Поэтому актуальной является задача разработки интегрированных баз данных электронных компонентов, как для аналоговых, так и для цифровых схем.
Современные САПР радиоэлектронной аппаратуры поддерживают, так называемый, библиотечный метод проектирования. Суть его заключается в том, что в процессе разработки объект детализируется до некоторых элементарных фрагментов, называемых структурными примитивами. Каждый примитив имеет свою поведенческую модель и представляет конструктивно законченный радиоэлектронный компонент, например транзистор, интегральную схему любой сложности или функциональную ячейку топологии кристалла кремния. Примитивы и их модели объединяются в библиотеки, которые доступны любому проектировщику.
Разрабатываемая электронная схема представляет собой некоторую комбинацию стандартных примитивов. Генерация конкретного варианта структуры выполняется на заданном наборе библиотечных примитивов методом проб и ошибок. Полученное решение требует проверки на работоспособность и соответствие требованиям технического задания. С этой целью строится структурная модель объекта как комбинация поведенческих моделей библиотечных примитивов, составляющих объект.
Привлекательная сторона библиотечного метода организации состоит в том, что структурные примитивы, используемые при проектировании, могут принадлежать различным иерархическим уровням. Благодаря этому значительно повышается эффективность моделирования.
Поведенческие модели библиотечных примитивов должны весьма точно отображать не только функцию, но также статические и динамические характеристики примитивов. Современные САПР (PCAD, PSPICE, OrCAD, ACTIVE VHDL и другие), а также языки моделирования HSL, DSL, PML,VHDL позволяют строить такие модели.
Информационное обеспечение наиболее распространенных на рынке САПР электронных схем представлено в виде совокупности библиотек. Так, наиболее известная САПР "сквозного" проектирования электронных схем OrCAD включает 5 типов библиотек, содержащих сведения о схемных компонентах.
Библиотечная организация информационного обеспечения САПР, несмотря на кажущуюся простоту, порождает ряд проблем при функционировании САПР:
• несогласованность различных типов библиотек по составу электронных компонентов (нарушение целостности данных);
• отсутствие процедур подбора и поиска компонентов по совокупности критериев;
• незащищенность информации от несанкционированного доступа;
• отсутствие разграничения прав пользователей на модификацию и удаление информации;
• отсутствие средств централизованного копирования и восстановления данных.
Кроме того, библиотеки схемных компонентов содержат минимальный объем информации, необходимый только для функционирования САПР, и не содержат нормативно-справочную информацию, на основании которой проектировщик отбирает схемные компоненты на этапе синтеза начального варианта схемы. Отсутствует в библиотеках так же информация о 3-мерном конструктивном исполнении корпусов компонентов.
Для решения перечисленных проблем предлагается использовать интегрированную базу данных схемных компонентов (ИБДСК), содержащую полный объем информации для всех этапов проектирования и ориентированную на пользователя САПР. При этом пользователь САПР может эффективно решать задачу подбора схемных компонентов и получать нормативно-справочную информацию в процессе автоматизированного формирования документации на проект. В рамках ИБДСК возможно также организовать автоматизированное определение значений параметров моделей компонентов на основе справочных данных. Для обеспечения функционирования САПР в базу данных должна быть встроена возможность формирования соответствующих библиотек для всех компонентов, применяемых в проекте. Таким образом, система управления ИБДСК должна обеспечивать выполнение следующих функций:
• занесение всех видов информации о схемных компонентах;
• проверку полноты информации по каждому компоненту для всех этапов проектирования;
• редактирование и удаление информации о схемных компонентах;
• поиск и отбор компонентов по различным критериям для рабочего проекта;
• формирование текстовых библиотек для рабочего проекта.
Цели и задачи исследования
Цель работы - исследование и разработка интегрированной базы данных схемных компонентов (ИБДСК), содержащей полный объем информации для всех этапов проектирования и позволяющей эффективно решать задачу подбора схемных компонентов и получать нормативно-справочную информацию в процессе автоматизированного формирования документации на проект.
Для достижения поставленной цели исследования необходимо решить следующие задачи:
1. Провести сравнительный анализ методов организации информационного обеспечения современных САПР;
2. Выполнить анализ и систематизацию полной информации о схемных компонентах, включающей данные о параметрах моделей, нормативно- справочные данные и данные о конструктивном исполнении компонента;
3. Разработать инфологические и даталогические модели данных (схемы базы данных) для рассматриваемой предметной области;
4. Разработать и реализовать подсистему ведения интегрированной базы данных схемных компонентов на основе клиент-серверной технологии.
Основные методы исследования
Для решения поставленных задач в диссертационной работе используются методы математического моделирования схемных компонентов, положения теории баз данных и теории построения САПР, методы объектно- ориентированного проектирования и программирования.
Достоверность научных результатов
Подтверждается корректностью использования математического аппарата, теорией моделирования электронных схем, теорией реляционных баз данных, теорией объектно-ориентированного программирования, а так же результатами тестирования разработанного информационного и программного обеспечения.
Новые научные результаты
Научная новизна полученных в диссертационной работе результатов заключается в следующем:
1. Разработана концепция организации информационного обеспечения САПР, основанная на замене традиционного используемых библиотечных файлов интегрированной базой данных схемных компонентов (ИБДСК), реализованной в рамках технологии клиент-сервер. Использование технологии баз данных позволяет получить оперативный доступ инженера-схемотехника к полной информации о параметрах любого схемного компонента, выполнить подбор схемных компонентов по совокупности параметров и организовать процедуры по защите и копированию данных в схемотехнических САПР;
2. Предложена расширенная модель «Сущность-Связь», отражающая объекты и связи между ними для организации информационного обеспечения схемотехнических САПР;
3. Разработана методика перехода от расширенной модели «Сущность- связь» к реляционной модели данных. В качестве основного способа реализации реляционной модели предложен метод преобразования каждого подтипа сущности в отдельное отношение, отличающийся
наибольшей компактностью и простотой реализации;
4. Разработана архитектура программного обеспечения ИБДСК, ориентированная на применение в САПР OrCAD PSpice A/D, DesignLab и Micro-Cap и отличающаяся от известных наличием инвариантных средств добавления новых видов схемных компонентов. Научные положения, выносимые на защиту
1. Концепция интегрированной базы данных схемных компонентов, содержащая полный объем информации для всех этапов проектирования и ориентированная на пользователя САПР, что позволяет эффективно решать задачу подбора схемных компонентов и оперативно получать нормативно-справочную информацию в процессе автоматизированного формирования документации на проект.
2. Расширенная модель «Сущность-Связь», отражающая объекты и связи между ними для организации информационного обеспечения схемотехнических САПР. В состав модели входят сущности «Схемный компонент», «Модель компонента», «Электрический многополюсник», «Типовой корпус».
3. Реляционная модель (схема данных) интегрированной БД схемных компонентов, учитывающая наличие высокой вложенности подтипов сущностей; большое разнообразие связей между сущностями; возможность добавления новых видов схемных компонентов в процессе эксплуатации базы данных.
4. Распределенная архитектура программного обеспечения интегрированной БД схемных компонентов, обеспечивающая эффективное распределение функций обработки данных между сервером БД и клиентским приложением.
Практическая ценность
Значение результатов диссертационной работы для практического применения заключается в следующем:
1. Разработанная концепция организации информационного обеспечения схемотехнических САПР, основанная на замене традиционного используемых библиотечных файлов интегрированной базой данных схемных компонентов, обеспечивает более эффективное проектирование аналоговых электронных устройств;
2. Предложенная в диссертации усложненная ER-модель предметной области позволяет учесть все аспекты применения схемных компонентов при проектировании электронных устройств;
3. Реализованное приложение базы данных в рамках технологии клиент- сервер включает инвариантное ядро, обеспечивающее удобное для добавления новых видов схемных компонентов.
4. Обеспечена возможность использования разработанной ИБДСК совместно со схемотехническими САПР OrCAD PSpice A/D, DesignLab и Micro-Cap, что позволяет снабдить инженера-схемотехника полной информацией о схемных компонентах и значительно повысить эффективность применения этих САПР.
5. Разработанная концепция организации информационного обеспечения схемотехнических САПР, предложенная усложненная ER-модель предметной области и реализованное приложение базы данных в рамках технологии клиент-сервер могут быть распространены и на системы синтеза цифровых схем, системы конструкторского проектирования и САПР сложных технических объектов различного назначения, не зависимо от их физической природы.
Практическая реализация и внедрение результатов работы
Разработанные в ходе исследования реляционные модели данных предметной области реализованы в среде универсальной промышленной СУБД Oracle 9i. Практическим результатом работы является ИБДСК, ориентированная на применение в САПР OrCAD PSpice A/D, DesignLab и Micro-Cap. Применение технологий баз данных в системах автоматизированного схемотехнического проектирования позволяет сосредоточить в электронном виде всю необходимую информацию о схемных компонентах и решить задачу подбора компонентов для проектируемой схемы.
Разработанные при выполнении работы модели данных и приложение баз данных были использованы в учебном процессе кафедры САПР СПбГЭТУ (ЛЭТИ) им. В.И. Ульянова (Ленина) и при создании информационного обеспечения для современных схемотехнических САПР.
Апробация работы
Основные теоретические результаты диссертационной работы докладывались на конференциях:
1. 5-ая международная конференция "Приборостроение в экологии и безопасности человека".- СПб., ГУАП, 31.01 - 02.02 2007.
2. Международная конференция " Современное образование: содержание, технологии, качество ". - СПб., СПбГЭТУ, 23.04.2008.
3. Конференции профессорско-преподавательского состава СПбГЭТУ, Санкт-Петербургский государственный электротехнический университет 2008, 2009 г.
Публикации
Основные теоретические и практические результаты диссертации опубликованы в 4 статьях и докладах, среди которых 2 публикации в ведущих рецензируемых изданиях, рекомендованных в действующем перечне ВАК. Доклады доложены и получили одобрение на 2 международных, всероссийских и межвузовских научно-практических конференциях перечисленных в конце автореферата.
Структура и объем диссертации
Диссертационная работа состоит из введения, четырех глав, заключения и списка литературы, включающего 68 наименований. Работа изложена на 128 страницах, содержит 30 рисунков и 18 таблиц.
Организации информационного фонда схемотехнических САПР на основе библиотек
Проектирование — связанная совокупность процессов преобразования одних данных в другие. При этом данные, являющиеся результатом одного процесса преобразования, могут быть исходными для другого процесса (промежуточные данные).
Система автоматизированного проектирования — сложная и многокомпонентная система, процессы преобразования данных в которой разнообразны. Это приводит к различным трактовкам термина "данные" в САПР. Так, для управляющей подсистемы в состав данных входит совокупность программных модулей, которые реализуют функции проектирования; для подсистемы диалогового обеспечения САПР данными является множество взаимосвязанных информационных и управляющих кадров экрана дисплея; для проектирующих подсистем к данным относится совокупность исходных и результирующих чисел, необходимых для выполнения конкретной проектной процедуры; пользователю САПР в качестве данных требуется иметь в своем распоряжении исходную проектную документацию, справочные данные, типовые проектные решения и т. д.
Совокупность данных, используемых всеми компонентами САПР, составляет информационный фонд САПР.
Основная функция информационного обеспечения (ИО) — ведение информационного фонда, т. е. обеспечение создания, поддержки и организации доступа к данным. Таким образом, информационное обеспечение САПР есть совокупность информационного фонда и средств его ведения. зависимости от функционального назначения информации можно выделить следующие виды составляющих информационного фонда САПР: A. - Информация о структуре объекта проектирования и значениях параметров модели объекта; B. - Информация о структуре моделей компонентов, входящих в состав объекта, и значениях параметров их моделей; C. - Исходные и результирующие (расчетные) данные, необходимые при выполнении программных модулей при реализации проектных операций и процедур. Эти данные часто меняются в процессе проектирования, однако их тип постоянен и полностью определяется соответствующим программным модулем; Б. - Текущая проектная документация отражает состояние и ход выполнения проекта. Как правило, эти данные слабо-структурированы, часто изменяются в процессе проектирования и представляются в форме текстовых документов и чертежей; Е. - Нормативно-справочная проектная документация (НСПД) включает в себя справочные данные о материалах, элементах схем, унифицированных узлах и конструкциях. Эти данные, как правило, хорошо структурированы и упорядочены; Е. - Государственные и отраслевые стандарты, руководящие материалы и указания, регламентирующие документы (слабоструктурированные документальные данные); С. -Типовые проектные решения и готовые проекты, выполненные в САПР.
На рис. 1 приведена обобщенная структура информационного обеспечения схемотехнических САПР. Рис. 1. Состав информационного фонда САПР
Способы ведения информационного фонда САПР. Проблему организации и ведения информационного фонда можно рассматривать в содержательном и организационном аспектах.
Содержательный аспект информации, используемой при проектировании, полностью определяется принятой методикой проектирования, структурой программного обеспечения, разработанными алгоритмами решения проектных задач.
С организационной точки зрения важно сформулировать принципы и определить средства ведения информационного фонда, структурирования данных, выбрать способы управления массивами данных.
Различают следующие способы ведения информационного фонда САПР: 1. Использование файловой системы ОС; 2. Использование файлов внешних приложений; 3. Построение библиотек; 4. Создание информационных программ конверторов; 5. Использование специализированных и универсальных СУБД. Использование файловой системы ОС.
Этот способ базируется на использовании различных типов файлов операционной системы, в среде которой функционирует САПР. Программные модули САПР совместно используют файлы для хранения и передачи информации. При этом формат файлов и способ их открытия полностью определяется в программных модулях САПР.
Такой подход широко применяется для хранения временных и промежуточных данных в САПР, предназначенных для дальнейшей обработки (вид информации - С).
Использование файлов внешних приложений. В рамках этого способа используются форматы файлов, используемых внешними приложениями, такими как Microsoft Word, Excel, Internet Explorer и др. Для доступа к таким файлам необходимо использовать динамический вызов соответствующего приложения, либо включать в состав САПР специализированные модули для их открытия. Этот способ используется для хранения различных видов текущей проектной и нормативно справочной документации (виды информации — E,F,G).
Расширенная модель «Сущность-Связь» для технических систем
До сих пор рассматривались только самые основные и наиболее очевидные понятия ЕЯ-модели данных, используемые в традиционных областях применения баз данных, а именно: банковские, кадровые, бизнес системы и т.д.
В сложных технических системах объекты предметной области могут иметь несколько уровней представления [33]. При использовании блочно- иерархического подхода к проектированию представления о проектируемой системе расчленяют на иерархические уровни. На верхнем уровне используют наименее детализированное представление, отражающее только самые общие черты и особенности проектируемой системы. На следующих уровнях степень подробности описания возрастает, при этом рассматривают уже отдельные блоки системы, но с учетом воздействий на каждый из них его соседей. Такой подход позволяет на каждом иерархическом уровне формулировать задачи приемлемой сложности, поддающиеся решению с помощью имеющихся средств проектирования. На каждом из уровней представления схемный компонент может иметь различное семантическое описание, что приведет к расщеплению сущностей ЕЯ-модели на несколько иерархических уровней.
Другим аспектом, способствующим появлению иерархии в ЕЯ-моделях технических систем является наличие семантически однородных объектов, т.е. объектов выполняющих одинаковые функции, но в тоже время имеющих существенно различные внутренние структуры, а, следовательно, и различные наборы атрибутов. Примером таких объектов может быть усилитель сигналов, построенный на дискретных схемных компонентах и его аналог, выполненный на интегральных схемах.
Рассмотрим иерархию сущностей ЕЯ-модели для схемных компонентов.
Подтипы и супертипы сущностей. Подобно тому, как это делается в языках программирования с развитыми типовыми системами (например, в языках объектно-ориентированного программирования), в ЕЯ- модели поддерживается возможность наследования типа сущности, исходя из одного или нескольких супертипов. Механизм наследования в ЕЯ-модели обладает несколькими особенностями: в частности, интересные нюансы связаны с необходимостью графического изображения этого механизма;
Уточняемые степени связи. Иногда бывает полезно определить возможное количество экземпляров сущности, участвующих в данной связи (например, ограничение, связанное с тем, что в схеме может быть использовано не боле трех типов схемных компонентов). Для выражения этого семантического ограничения разрешается указывать на конце связи ее максимальную или обязательную степень;
Взаимно исключающие связи. Для заданного типа сущности можно определить такой набор типов связи с другими типами сущности, что для каждого экземпляра заданного типа сущности может (если набор связей является необязательным) или должен (если набор связей обязателен) существовать экземпляр только одной связи из этого набора;
Каскадные удаления экземпляров сущностей. Некоторые связи бывают настолько сильными (конечно, в случае связи «один ко многим»), что при удалении опорного экземпляра сущности (соответствующего концу связи «один») нужно удалить и все экземпляры сущности, соответствующие конг\у связи «многие». Соответствующее требование каскадного удаления можно специфицировать при определении связи ,
Домены. Как и в случае реляционной модели данных, в некоторых случаях полезна возможность определения потенциально допустимого множества значений атрибута сущности (домена).
Эти и другие усложненные элементы модели данных «Сущность-Связь» делают ее более мощной, но одновременно несколько затрудняют ее использование [60,61]. Подробно рассмотрим иерархию сущностей, включающую супертипы и подтипы сущности.
Сущность может быть расщеплена на два или более взаимно исключающих подтипов, каждый из которых включает общие атрибуты и/или связи. Эти общие атрибуты и/или связи явно определяются один раз на более высоком уровне. В подтипах могут определяться собственные атрибуты и/или связи. В принципе, подтипизация может продолжаться на более низких уровнях, но опыт использования ЕЯ-модели при проектировании баз данных показывает, что в большинстве случаев оказывается достаточно двух-трех уровней.
Если у типа сущности А имеются подтипы Вх, В2, ... , Вп, то: (а) любой экземпляр типа сущности В1, В2,..., Вп является экземпляром типа сущности А (включение); (Ь) если а является экземпляром типа сущности А, то а является экземпляром некоторого подтипа сущности В± (1 = 1, 2, ..., п) (отсутствие собственных экземпляров у супертипа сущности) , (с) ни для каких подтипов В . и Bj j = 1, 2 . . . , п) не существует экземпляра, типом которого одновременно являются типы сущности Вд. и В., (разъединенность подтипов).
Тип сущности, на основе которого определяются подтипы, называется супертипом. Как мы видели выше, подтипы должны образовывать полное множество, т. е. любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для обеспечения такой полноты приходится определять дополнительный подтип ПРОЧИЕ.
Набор атрибутов для супертипа сущности «Электрический многополюсник»
Конструктивно схемные компоненты помещаются в корпус, который с точки зрения конструктора радиоэлектронной аппаратуры представляет собой объемное тело [9]. Таким образом, супертип сущности «Схемный компонент» связан еще с одним супертипом сущности «Типовой корпус». В зависимости от условий применения схемных компонентов используется несколько конструктивных исполнений корпусов, что приводит к расщеплению супертипа сущности «Типовой корпус» на подтипы «Корпус металлостеклянный», «Корпус металлопластмассовый», «Корпус пластмассовый», «Бескорпусное исполнение» и т.д. (см. рис. 2.6). С другой стороны, иерархия схемных компонентов не учитывается при помещении компонента в корпус (биполярный и полевой транзисторы различного назначения могут быть помещены в одинаковые типовые корпуса). Эти два фактора позволяют при переходе от ЕЫ-диаграммы к реляционной модели использовать единую таблицу и общий набор атрибутов для всех подтипов сущности «Типовой корпус». Атрибуты типовых компонентов, выпускаемых российской промышленностью
Ниже в таблице 3.5 приводятся атрибуты типовых компонентов, выпускаемых российской промышленностью и соответствующие ГОСТ 18472-88.
Габаритные чертежи типовых корпусов схемных компонентов, приведены в таблице 3.6. Габаритные чертежи типовых корпусов схемных компонентов 1. Для перехода от мифологических моделей схемных компонентов к да- талогическим моделям необходимо определить наборы атрибутов для каждого типа сущности. Особенностью данного этапа является повышенная сложность инфологических моделей компонентов, имеющих иерархическую структуру и наличие нескольких супертипов и подтипов сущностей; 2. Каждый из подтипов сущности «Модель схемного компонента» характеризуется эквивалентной схемой модели, уравнениями модели .и таблицей параметров (атрибутов) модели. При этом в базе данных целесообразно хранить изображение эквивалентной схемы и таблицу параметров модели; 3. Супертип сущности «Схемный компонент» связан с супертипом сущности «Электрический многополюсник». С учетом иерархии такая связь распадается на связи между соответствующими подтипами сущностей (биполярный транзистор — электрический многополюсник для биполярного транзистора, полевой транзистор — электрический многополюсник для полевого транзистора, операционный усилитель — электрический многополюсник для операционного усилителя и т.д.). Степень связи между подтипами сущностей равна 1:1, так как для каждого вида компонента существует единственный вид многополюсника со своим набором атрибутов (параметров); 4. Супертип сущности «Схемный компонент» связан еще с одним супертипом сущности «Типовой корпус». В зависимости от условий применения схемных компонентов используется несколько конструктивных исполнений корпусов, что приводит к расщеплению супертипа сущности «Типовой корпус» на подтипы. С другой стороны, иерархия схемных компонентов не учитывается при помещении компонента в корпус (биполярный и полевой транзисторы различного назначения могут быть помещены в одинаковые типовые корпуса). Эти два фактора позволяют при переходе от ЕЯ-диаграммы к реляционной модели использовать единую таблицу и общий набор атрибутов для всех подтипов сущности «Типовой корпус».
Создание приложения в среде С# для работы с базой данных Oracle
Использование (ADO.NET) для подключения к базе данных Oracle . В ADO.NET (ActiveX Data Objects) [18,41,45] используется OLEDB - новый механизм подключения к базам данных обеспечивающий ускоренный и более гибкий доступ к различным источникам, для которых ADO.NET обеспечивать единый, удобный интерфейс. Это означает, что приложение может легко переходит от однопользовательских база данных к комплексным системам, в которых используется Oracle. ADO .NET. Доступ к данным: Объектная модель ADO.NET [11,57] реализует отсоединенный доступ к данным. При этом в Visual Studio.NET существует множество ВСТРОЕННЫХ мастеров и дизайнеров, которые позволяют реализовать механизмы доступа к БД еще на этапе разработки программного кода. С другой стороны, задача получения доступа к данным может быть решена непосредственно во время выполнения приложения. Концепция доступа к данным в ADO .NET основана на использовании двух компонентов (Рис. 4.2): 1. НАБОРА ДАННЫХ (представляется объектом класса DataSet) со стороны клиента. Это локальное временное хранилище данных; 2. ПРОВАЙДЕРА ДАННЫХ (представляется объектом класса DataProvider). Это посредник, обеспечивающий взаимодействие приложения и базы данных со стороны базы данных (в распределенных приложениях — со стороны сервера). ADO .NET. Объектная модель: Объектная модель ADO .NET предполагает существование (при написании приложения для работы с базой данных — использование) двух множеств классов, выполняющих четко определенные задачи при работе с базой данных (Рис. 4.3): Классы подсоединенных объектов обеспечивают установление соединения с базой данных и управление базой со стороны приложения, классы отсоединенных объектов обеспечивают сохранение, использование и преобразование полученной от базы данных информации на стороне приложения. DataTable: Каждый объект DataTable представляет одну таблицу базы данных. Таблица в каждый конкретный момент своего существования характеризуется: 1. СХЕМОЙ таблицы; 2. СОДЕРЖИМЫМ таблицы (информацией). При этом СХЕМА таблицы (структура объекта DataTable) определяется двумя наборами: 1. множеством столбцов таблицы (набор DataColumns, состоящий из множества объектов DataColumn), 2. множеством ограничений таблицы (набор Constraints, состоящий из множества объектов Constraint). DataColiimns: DataColumnCollection задает схему таблицы, определяя тип данных каждой колонки. Объект DataColumn содержит информацию о структуре столбца (метаданные). Например, у этого объекта имеется свойство Туре, описывающее тип данных столбца/"67,68]. Также имеются свойства Readonly; Unique; Default; Autolncrement; которые, в частности, позволяют ограничить диапазон допустимых значений поля и определить порядок генерации значений для новых данных. Объект DataColumn представляет тип колонки в DataTable. Это стандартный блок, предназначенный для построения схемы DataTable. Каждый объект DataColumn как элемент схемы характеризуется собственным типом, определяющим тип значений, которые DataColumn содержит. DataRows: СОДЕРЖИМОЕ таблицы (непосредственно данные) задается набором DataRows - это конкретное множество строчек таблицы, каждая из которых является объектом - представителем класса DataRow. Элементы этого набора являются объектами класса DataRow. В этом классе обеспечивается несколько вариантов реализации свойства Item, которые обеспечивают навигацию по множеству записей объекта DataTable и сохранение текущих изменений данных, сделанных за текущий сеанс редактирования базы. Изменение данных в DataTable и состояние строки таблицы: Основной контроль за изменениями данных в таблице возлагается на строки — объекты класса DataRow. Для строки определены несколько состояний, которые объявлены в перечислении RowStte. Контроль за сохраняемой в строках таблицы информацией обеспечивается посредством определения состояния строки, которое обеспечивается одноименным (RowState) свойством - членом класса DataRow. Relations: В классе DataSet определяется свойство Relations - набор объектов - представителей класса Data Relations. Каждый такой объект определяет связи между составляющими объект DataSet объектами Dat&Table (таблицами). Если в DataSet более одного набора DataTable, набор DataRelations будет содержать несколько объектов типа DataRelation (Рис. 4.4). Каждый объект определяет связи между таблицами - DataTable. Таким образом, в объекте DataSet реализуется полный набор элементов для управления данными, включая сами таблицы, ограничения и отношения между таблицами. Constraints: Объекты - представители класса Constraint в наборе Constraints объекта DataTable позволяет задать на множестве объектов DataTable различные ограничения. DataView: Объекты - представители класса DataView НЕ ПРЕДНАЗНАЧЕНЫ для организации визуализации объектов DataTable. Их назначение - простой последовательный доступ к строкам таблицы. Объекты DataView являются средством перебора записей таблицы. При обращении ЧЕРЕЗ объект DataView к таблице получают данные, которые хранятся в этой таблице.
