1 вопрос - Проектирование информационной системы (ИС).
ИС - коммуникационная система по сбору, передачи и обработки информации об объекте, снабжающая работников различного ранга информацией для реализации функций управления. В общем виде система охватывает комплекс взаимосвязанных элементов, действующих как единое целое в интересах цели.
Система включает компоненты:
· структура системы
· множество элементов системы и взаимосвязи между ними,
· функция каждого элемента системы,
· цели и ограничения системы и ее отдельных элементов (материальные и информационные потоки поступающие в систему или вводимые ею, вход и выход каждого элемента системы).
Каждая система обладает свойствами делимости и целостности. Делимость – систему можно представить состоящих из относительно самостоятельных частей (подсистем) каждая из которых, может рассматриваться как система. Это упрощает анализ разработку внедрение и эксплуатацию. Свойство целостности – указывает на согласование целей функционирования всей системы с целями функций ее подсистем и элементов. ИС создается для конкретного объекта. Эффективная ИС принимает во внимание различие между уровнями управления, сферами действий, а так же внешними обстоятельствами и дает каждому уровню управления только ту информацию которая ему необходима для эффективной реализации функций управления. Внедрение ИС производится с целью повышения эффективности производственно хозяйственной деятельности за счет не только обработки и хранения информации но и за счет применения новых методов управления основанных на моделировании действий специалиста фирмы при принятии решения за счет методов искусственного интеллекта, экспертных систем, средств телекоммуникаций, глобальных и локальных сетей и т.д.
2 вопрос - Понятие и структура проекта ИС.
Под проектом ЭИС понимают – проектно-конструкторскую и технологическую документацию, в которой представлено описание проектных решений по созданию и эксплуатации ЭИС в конкретной программно-технической среде.
С точки зрения проектирования процесс представляется последовательной формализацией проектных решений на различных стадиях жизненного цикла ЭИС (планирование, анализ требований, технический проект, внедрение, эксплуатация).
Объектами проектирования ЭИС являются, отдельные элементы или комплексы функциональных (задачи, комплексы задач и функции управления) и обеспечивающих частей (элементы или комплексы информационного, программного и технического обеспечения системы).
Субъектом проектирования являются коллективы специалистов, как правило, специализированные проектные организации и организации заказчики.
3 вопрос - Требования к эффективности и надежности проектных решений.
К основным требованиям, предъявляемым к выбираемой технологии проектирования, относятся следующие:
· созданный с помощью этой технологии проект должен отвечать требованиям заказчика;
· выбранная технология должна максимально отражать все этапы цикла жизни проекта;
· выбираемая технология должна обеспечивать минимальные трудовые и стоимостные затраты на проектирование и сопровождение проекта;
· технология должна быть основой связи между проектированием и сопровождением проекта;
· технология должна способствовать росту производительности труда проектировщика;
· технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта;
· технология должна способствовать простому ведению проектной документации.
Осуществление проектирования ИС предполагает использование проектировщиками определенной технологии проектирования, соответствующей масштабу и особенностям разрабатываемого проекта.
4 вопрос - Основные компоненты технологии проектирования ИС
Технология проектирования – это совокупность методов, средств проектирования и организации ЭИС, т.е. управление процессом создания и модернизации ЭИС.
Методы проектирования ЭИС можно классифицировать:
Так, по степени автоматизации методы:
· ручного проектирования, при котором проектирование компонентов ИС осуществляется без использования специальных инструментальных программных средств, а программирование - на алгоритмических языках;
· компьютерного проектирования, которое производит генерацию или конфигурацию (настройку) проектных решений на основе использования специальных инструментальных программных средств.
По степени использования типовых проектных решений методы:
· оригинального (индивидуального) проектирования, когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к ИС;
· типового проектирования, предполагающего конфигурацию ИС из готовых типовых проектных решений (программных модулей).
По степени адаптивности проектных решений методы:
· реконструкции, когда адаптация проектных решений выполняется путем переработки соответствующих компонентов (перепрограммирования программных модулей);
· параметризации, когда проектные решения настраиваются (перегенерируются) в соответствии с изменяемыми параметрами;
· реструктуризации модели, когда изменяется модель проблемной области, на основе которой автоматически перегенерируются проектные решения.
Средства делят на 2 класса:
1. Без использования компьютеров – применяются на всех этапах проектирования. К ним относятся: Средства организационно-методического обеспечения (стандарты, регламенты, законодательные документы); Единая система классификации кодирования информации;
Единая система документации; Модели описания; Модели анализа потоков информации;
2. С использованием компьютеров – могут применяться на отдельных этапах проектирования:
2.1. Операционные средства – повышается производительность труда проектировщиков, но не разрабатывается законченного проектного решения, таким образом, средства данного подкласса поддерживают отдельные операции проектирования и могут применяться независимо друг от друга: Алгоритмические языки; Библиотеки стандартных подпрограмм; Генераторы программ типовых операций обработки данных; Различные утилиты; Простейшие инструментальные средства проектирования (тестирование отладка, поддержка документирования);
2.2. Средства, поддерживающие проектирование отдельных компонентов проекта: Средства общесистемного назначения: СУБД; Методоориентированные пакеты прикладных программ (математическая статистика, дискретное программирование и т.п.); Табличные процессоры; Графические и текстовые редакторы; Оболочки экспертных систем; Интегрированные пакеты прикладных программ;
2.3. Средства, поддерживающие проектирование разделов проекта: ср-ва ориентир на тип организационной системы (промышленная, не промышленная сфера); ср-ва ориентир на уровень управления (предприятия, подразделения, участок); ср-ва ориентир на функцию управления (планирование, учёт, анализ и т.д.);
2.4. Средства, поддерживающие разработку проекта на стадиях и этапах процесса проектирования: Автоматизированные системы проектирования; CASE средства.
1. 5 вопрос - Методы проектирования ИС:
– способ создания систем ЭИС. 3 метода: индивидуальный (оригинальный), типовое проектирование, автоматизированное проект.(САПР) Индивидуальное характеризуется – все виды работ для различных объектов выполняются по индивидуальным проектам. В процессе инд проектирования применяются свои оригинальные методики и средства проведения работ. Методики проведения работ на всех этапах обследование, формирование технического задания, разработки технического проекта и раб документации создаются для конкретного объекта по мере необходимости. “-” высокая трудоемкость, большие сроки проектирования, плохая модернизируемость, плохая сопровождаемость. Типовое проектирование – разбиение системы на множество составных компонентов и создание для каждой из них законченного проектного решения, которое про внедрении привязывается к конкретным условиям объекта. В зависимости от декомпозиции различают: элементное проектирование, подсистемное, объектная. При элементном методе проектирования, вся система разбивается на конечное множество элементов, каждый из которых является типовым. В качестве элементов могут выступать проектные решения по информационному, техническому, программному виду обеспечения. Подсистемный метод проектирования характеризуется более высокой степенью интеграции элементов ЭИС. Декомпозиция системы осуществляется на уровне функциональных подсистем, иногда комплекса задач, каждая из выделеных подсистем представляется в законченом виде ППП. При этом обеспечивается функциональная полнота системы, минимум инф-ой связи, параметрическая настраиваемость. Для каждого ППП оформляется пакет документации. Объектное проектирование- декомпозиция ЭИС не производится. Типовой проект создается в целом для некоторого обобщеного объекта, определенной группы. Автоматизированное проектирование – автоматизация основных этапов создания ЭИС, начиная от выбора состава задач и заканчивая автоматическим получением проектной документации
СРЕДСТВА ПРОЕКТИРОВАНИЯ – некоторый совокупный преобразователь реализующий с использованием ЭВМ несколько взаимосвязанных технологических операций проектирования. 1 Объектные средства: типовые проекты, типовые проектные решения, ППП. 2 Инструментальные средства: ОС, САПр, CASE – технологии. Для средств проектирования определяется вход (инф необходимая для настройки соответствующего средства) и выход (результат проектирования на некотором шаге). Требования к средствам проектирования: Должны охватывать процесс проектирования в комплексе и по всем вопросам организации и проыедения проектных работ; обладать совместимостью; быть легкими в освоении; одни и теже средства должны быть применимы для различных объектов; позволять создавать адаптивные системы; экономически эффективны.
6 вопрос - Краткая характеристика применяемых технологий проектирования.
Сочетание различных признаков классификации методов проектирования обусловлива¬ет характер используемой технологии проектирования ЭИС, среди которых выделяются два основных класса:
1. Каноническая технология проектир-я:
2. Индустриальная технология проектир-я:
автоматизированное (использование CASE-технологий)
типовое (параметриче¬ски-ориентированное или модельно-ориентированное)
Использование индустриальных технологий проектирования не исключает использова¬ния в отдельных случаях канонической технологии.
Характеристики классов технологий проектирования
Класс технологии проектирования Степень автоматизации Степень типизации Степень адаптивности
Каноническое проектирование Ручное проектирование Оригинальное
проектирование Реконструкция
Индустриальное автоматизированное проектирование Компьютерное
проектирование Оригинальное
проектирование Реструктуризация модели (генерация ЭИС)
Индустриальное типовое
проектирование Компьютерное
проектирование Типовое сборочное проектирование Параметризация и ре-
структуризация модели
(конфигурация ЭИС)
Средства проектирования должны быть:
· в своем классе инвариантными к объекту проектирования;
· охватывать в совокупности все этапы жизненного цикла ИС;
· технически, программно и информационно совместимыми;
· простыми в освоении и применении;
· экономически целесообразными
Средства проектирования ИС можно разделить на два класса:
без использования ЭВМ
с использованием ЭВМ
Все множество средств проектирова¬ния с использованием ЭВМ делят на четыре подкласса
К первому подклассу относятся операционные средства.
Ко второму подклассу относят средства, поддерживающие проектирование отдельных компонентов проекта ИС
К третьему подклассу относятся средства, поддерживающие проектирование разделов проекта ИС.
К четвертому подклассу средств проектирования ИС относятся средства, поддерживающие разработку проекта на стадиях и этапах процесса проектирования.
Современные CASE-средства, в свою очередь, классифицируются в основном по двум признакам:
1) по охватываемым этапам процесса разработки ИС;
2) по степени интегрированности: отдельные локальные средства (tools), набор не интегрированных средств, охватывающих большинство этапов разработки ИС (toolkit) и полностью интегрированные средства, связанные общей базой проектных данных - репозиторием (workbench).
7 Вопрос - Требования, предъявляемые к технологии проектирования ИС.
Основные требования, предъявляемые к технологии проектирования:
Созданный с помощью выбранной технологии проект должен отвечать требованиям заказчика.
Технология должна максимально отражать все этапы цикла жизни проекта.
Технология должна обеспечивать минимальные трудовые и стоимостные затраты как на проектирование так и на сопровождение проекта.
Технология должна быть основой связи между проектированием и сопровождениям.
Технология должна способствовать росту производительности труда проектировщика.
Технология должна обеспечивать надёжность процесса проектирования и эксплуатации проекта.
Технология должна способствовать простому ведению проектной документации.
Основой технологией проектирования ЭИС составляет методология, методология определяет сущность и основные отличительные технологические особенности.
Методология предполагает наличие концепции принципов проектирования, которые реализуются набором методов, которые должны поддерживаться определёнными средствами проектирования.
8 вопрос - Выбор технологии проектирования:
Сочетание различных признаков классификации методов проектирования обусловлива¬ет характер используемой технологии проектирования ЭИС, среди которых выделяются два основных класса: каноническая и индустриальная технологии.
Индустриальная технология проектирования, в свою очередь, разбивается на два под¬класса: автоматизированное (использование CASE-технологий) и типовое (параметриче¬ски-ориентированное или модельно-ориентированное) проектирование.
Каноническое проектирование ЭИС отражает особенности ручной технологии индивидуального (оригинального) проектирования, осуществляемого на уровне исполнителей без использования каких-либо инструментальных средств, позволяющих интегрировать выполнение элементарных операций.
В настоящее время имеется несколько типов технологий проектирования
оригинальный
типовой
автоматизированный
смешанный
Основными ограничениями при выборе технологии могут служить:
- наличие денежных средств на приобретение поддержку выбранной технологии
- ограничение во времени проектирования
- наличие специалистов соответствующей квалификации.
Результатом выполнения этой операции служит, описание выбранной технологии, методов и средств проектирования.
2. 9 вопрос - Каноническое проектирование ИС:
Каноническое проектирование ЭИС отражает особенности ручной технологии инди-видуального (оригинального) проектирования, осуществляемого на уровне исполнителей без использования каких-либо инструментальных средств, позволяющих интегрировать выполнение элементарных операций. Как правило, каноническое проектирование приме¬няется для небольших локальных ЭИС.
В основе канонического проектирования лежит каскадная модель жизненного цикла ЭИС. Стадии созда¬ния» делится на следующие семь стадий: 1. исследование и обоснование создания системы: 2. разработка технического задания; 3. создание эскизного проекта; 4. техническое проектирование; 5. рабочее проектирование; 6. ввод в действие; 7. функционирование, сопровождение, модернизация.
10 Вопрос - Стадии и этапы процесса проектирования ИС.
Стадии и этапы создания ЭИС:
1. Формирование требований к ЭИС:
1.1 Обследование объекта и обоснование необходимости создания ЭИС
1.2 Формирование требований пользователя к ЭИС
1.3 Оформление отчета о выполненной работе и заявки на разработку ЭИС
2. Разработка концепции ЭИС:
2.1 Изучение объекта
2.2 Проведение необходимых научно-исследовательских работ
2.3 Разработка вариантов концепции ЭИС и выбор варианта концепции ЭИС, удовлетворяющего требованиям пользователя.
2.4 Оформление отчета о выполненной работе.
3. Техническое задание:
3.1 Разработка и утверждение технического задания ЭИС
4. Эскизный проект:
4.1 Разработка предварительных решений по выбранному варианту ЭИС.
4.2 Разработка документации на ЭИС и ее частей
5. Технический проект:
5.1 Разработка проектных решений по системе и ее частям.
5.2 Разработка документации на ЭИС.
5.3 Разработка и оформление документации на поставку изделий для комплектования ЭИС.
6. Рабочая документация:
6.1 Разработка РД на систему или ее частей.
6.2 Разработка или адаптация программ.
7. Ввод в действие:
7.1 Подготовка объекта автоматизации к вводу в действие.
7.2 Подготовка персонала , проводится обучение персонала.
7.3 Строительно-монтажные работы (если строится специализированное здание).
7.4 Проведение предварительных испытаний. Проведение опытной эксплуатации.Проведение опытных испытаний.
7.6 Введение в промышленную эксплуатацию
8. Сопровождение ЭИС:
8.1 Выполнение работ в соответствии с гарантийными обязательствами.
8.2 После гарантийное обслуживание.
11 вопрос - Состав работ на предпроектной стадии, стадии технического и рабочего проектирования, стадии ввода в действие ИС, эксплуатации и сопровождения:
На первой «Предпроектной стадии» принято выделять два основных этапа: сбор ма-териалов обследования; анализ материалов обследования и разработка технико-экономического обоснования (ТЭО) и технического задания (ТЗ).
В результате выполнения первого этапа проектировщики получают материалы обсле-дования, которые должны содержать полную и достоверную информацию, описы¬вающую изучаемую предметную область – предприятие. После выполнения второго этапа проектировщики по¬лучают количественные и качественные характеристики информационных потоков, опи¬сание их структуры и мест обработки, объемов выполняемых операций и трудоемкости их обработки.
Вторая стадия «Технорабочее проектирование» выполняется в два этапа: техническое проектирование и рабочее проектирование. На этапе «Техническое проектирование» вы¬пол-няются работы по логической разра¬ботке и выбору наилучших вариантов проектных решений, в результате чего создается «Технический проект». Этап «Рабочее проектирование» связан с физической реализацией выбранного варианта проекта и получением документации «Рабочего проекта». При нали¬чии опыта проектирования эти этапы иногда объединяются в один, в результате выполне¬ния которого получают «Технорабочий проект».
Третья стадия «Внедрение проекта» включает в себя три этапа: подготовка объекта к внедрению проекта; опытное внедрение проекта и сдача его в промышленную эксплуата¬цию. На этапе «Подготовка объекта к внедрению проекта» осуществляется комплекс работ по подготовке предприятия к внедрению разработанного проекта ЭИС. На этапе «Опыт¬ное внедрение» осуществляют проверку правильности работы некоторых частей проекта и получают исправленную проектную документацию и «Акт о проведении опытного вне¬дрения». На этапе «Сдача проекта в промышленную эксплуатацию» осуществляют ком¬плексную системную проверку всех частей проекта, в результате которой получают дора¬ботанный «Техно-рабочий проект» (Д3.1) и «Акт приемки проекта в промышленную экс¬плуатацию»
Четвертая стадия - «Эксплуатация и сопровождение проекта» включает этапы: экс-плуатация проекта; сопровождение и модернизация проекта. На этапе «Эксплуатация проекта» получают информацию о работе всей системы в целом и отдельных ее компонентов и собирают статистику о сбоях системы в виде рекла¬маций и замечаний, которые накапливаются для выполнения следующего этапа. На этапе «Сопровождение проекта» выполняются два вида работ: ликвидируются последствия сбоев в работе системы и исправляются ошибки, не выявленные при внедрении проекта, а также осуществляется модернизация проекта. В процессе модернизации проект либо до¬рабатывается, т.е. расширяется по составу подсистем и задач, либо производится перенос системы на другую программную или техническую платформу с целью адаптации ее к изменяющимся внешним и внутренним условиям функционирования, в результате чего получают документы модернизированного «Технорабочего проекта».
12 вопрос - Состав проектной документации:
Содержание документов является общим для всех видов ИС и, при необходимости, может дополняться разработчиком документов в зависимости от особенностей создавае¬мой ИС. Допускается включать в документы дополнительные разделы и сведения, объе¬динять и исключать разделы.
В состав рабочей док-тации проекта входят док-ты:
1. Пояснительная записка.
2. Функциональная и организационная структура.
3. Должностные инструкции.
4. Инструкция по заполнению входных оперативных док-тов.
5. Инструкция по использованию выходных док-тов.
6. Инструкция по организации и ведению нормативно-справочной инф-ии.
7. Инструкция по организации хранения инф-ии в архиве.
8. Инструкция по подготовке инф-ии к вводу в ПК.
9. Расчет экономической эффективности системы.
10. Мероприятия по подготовке объекта к внедрению.
11. Ведомость док-тов.
13 вопрос - Состав, содержание и принципы организации информационного обеспечения ИС:
Технический проект системы - это техническая док-тация, утвержденная в установленном порядке, содержащая общесистемные проектные решения, алгоритм решения задач, а также оценку экономической эффективности автоматизированной системы управления и перечень мероприятий по под¬готовке объекта к внедрению.
Технический проект разрабатывается в целях определения основных проектных решений по созданию сис-мы. На этом этапе осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора наилучших вариантов решений, проводятся экспериментальная проверка основных
проектных решений и расчет экономической эффективности системы.
Фактически технический проект содержит комплекс эконо¬мико-математических и алгоритмических моделей.
Полный комплект технического проекта на систему включает в себя 10 док-тов:
1. Пояснительная записка.
2. Функциональная и орг-ная структура системы.( обоснование выделяемых подсистем, их пе-речень и назначение; перечень задач, решаемых в каждой под¬системе, с краткой характеристикой их содержания; схема информационных связей между подсистемами и между задача¬ми в рамках каждой подсистемы)
3. Постановка задач и алгоритм решения.( выполняется для каждой отдельной за¬дачи,)
4. Организация информационной базы.
5. Альбом форм док-тов.
6. Система математического обеспечения.
7. Принцип построения комплекса технических средств.
8. Расчет экономической эффективности системы.
9. Мероприятия по подготовке объекта к внедрению системы.
10. Ведомость док-тов.
док-ты 1, 2, 5, 8, 9 могут разрабатываться для отдельных подсистем.
Все перечисленные док-ты можно сгруппировать и пред¬ставить в виде четырех основных частей технического проек¬та: экономико-организационная, информационная, математи¬ческая, техническая.
Экономико-организационная часть технического проекта со¬держит пояснительную записку относительно оснований для разработки системы, перечень организаций разработчиков, краткую характеристику объекта с указанием основных тех¬нико-экономических показателей его функционирования и свя¬зей с другими объектами, краткие сведения об основных про¬ектных решениях по функциональной и обеспечивающим ча¬стям системы, раздел об организационной и функциональной структу¬ре.
Информационная часть технического проекта объединяет док-ты 4 и 5. В док-те "Организация информацион¬ной базы" отражаются источники поступления инф-ии и способы ее передачи для решения первоочередного комплекса функциональных задач; совокупность показателей, используемых в системе; состав док-тов, сроки и периодичность их поступления; основные проектные решения по организации фонда НСИ; состав НСИ, включая перечень реквизитов, их определение, значность, диапазон изменения и перечень док-тов НСИ; перечень массивов НСИ, их объем, порядок и частота корректировки инф-ии; предложения по унификации док-тации, контрольный пример по вне¬сению изменений в НСИ; структурная форма НСИ с описа¬нием связи между его элементами; требования к технологии создания и ведения фонда; методы хранения, поиска, внесе¬ния изменений и контроля; определение объемов и потоков инф-ии НСИ.
"Альбом форм док-тов" содержит формы НСИ.
Математическая часть технического проекта содержит обоснование структуры математического обеспечения, обосно¬вание выбора системы программирования, в том числе пере¬чень стандартных программ.
Техническая часть технического проекта предполагает опи¬сание и обоснование схемы технического процесса обработки данных; обоснование требований к разработке нестандартно¬го оборудования; обоснование и выбор структуры комплекса технических средств и его функциональных групп; комплекс мероприятий по обеспечению надежности функционирования технических средств.
Анализ предметной области, разработка состава и структуры БД, проектирование логико-семантического комплекса.
Проектирование баз данных — это итерационный, многоэтапный процесс принятия обоснованных решений в процессе анализа информационной модели предметной области, требований к данным со стороны прикладных программистов и пользователей, синтеза логических и физических структур данных, анализа и обоснования выбора программных и аппаратных средств. Этапы проектирования баз данных связаны с многоуровневой организацией данных. Рассматривая вопрос проектирования баз данных, будем придерживаться такого многоуровневого представления данных: внешнего, инфологического, логического (даталогического) и внутреннего.
Внешний уровень в этом случае выступает как отдельный этап проектирования, на котором изучается все внемашинное информационное обеспечение, то есть формы документирования и представления данных, а также внешняя среда, в которой будет функционировать банк данных с точки зрения методов фиксации, сбора и передачи информации в базу данных.
Инфологический уровень представляет собой информационно-логическую модель (ИЛМ) предметной области, из которой исключена избыточность данных и отображены информационные особенности объекта управление без учета особенностей и специфики конкретной СУБД. То есть инфологическое представление данных ориентированно преимущественно на человека, который проектирует или использует базу данных.
Логический (концептуальный) уровень построен с учетом специфики и особенностей конкретной СУБД. Этот уровень представления данных ориентирован больше на компьютерную обработку и на программистов, которые занимаются ее разработкой. На этом уровне формируется концептуальная модель данных, то есть специальным способом структурированная модель предметной области, которая отвечает особенностям и ограничениям выбранной СУБД. Модель логического уровня, поддерживаемую средствами конкретной СУБД, называют еще даталогической.
Инфологическая и даталогическая модели, которые отображают модель одной предметной области, зависимы между собой. Инфологическая модель может легко трансформироваться в даталогическую модель.
Внутренний уровень связан с физическим размещением данных в памяти ЭВМ. На этом уровне формируется физическая модель БД, которая включает структуры сохранения данных в памяти ЭВМ, в т.ч. описание форматов записей, порядок их логического или физического приведения в порядок, размещение по типам устройств, а также характеристики и пути доступа к данным.
Целью проектирования на внешнем уровне является разработка внемашинного информационного обеспечения, которое включает систему входной (первичной) документации, характеризующую определенную предметную область, систему классификации и кодирования технико-экономической информации, а также перечень соответствующих выходных сообщений, которые нужно формировать с помощью БнД.
Цель семантического моделирования — обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому семантическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка).
Однако взятый в отдельности любой из этих методов не может дать достаточно информации для проектирования рациональной структуры БД. Поэтому при проектировании БД целесообразно совместно использовать эти два подхода. Если схематично представить процесс проектирования БД на внешнем уровне, то он состоит из таких работ: 1)Определение функциональных задач предметной области, которые подлежат автоматизированному решению. 2)Изучение и анализ оперативных первичных документов. 3)Изучение нормативно-справочных документов. 4)Изучение процессов преобразования входных сообщений в выходные.
Результатом проектирования на внешнем уровне будет перечень атрибутов (реквизитов) оперативной и условно-постоянной информации, которые необходимо хранить в БД, с указанием источников их получения и формы представления.
14 вопрос - Проектирование фактографических БД: методы проектирования; концептуальное, логическое и физическое проектирование:
Фактографические ИС накапливают и хранят данные в виде множества экземпляров одного или нескольких типов структурных элементов (информационных объектов), отражающих сведения по какому-либо факту, событию и т.д., отделенному от всех прочих сведений и фактов
Уровни представления информации в фактографических ИС
Начальный уровень определяется локальными представлениями о предметной области пользователей-абонентов ИС и их представлениями о своих информационных потребностях. На основе анализа этих представлений определяется информационно-логическая схема предметной области, подлежащей отображению ИС, и концептуальная модель использования ИС.
Вторым уровнем представления информации в ИС является схема базы данных, называемая еще логической структурой данных, представляющая описание средствами конкретной СУБД информационно-логической схемы предметной области.
Совокупность средств и способов реализации схемы базы данных в конкретной СУБД составляет модель организации данных
Третий и самый «низкий» уровень представления информации в фактографических ИС выражается внутренней схемой базы данных, определяющей структуру организации и особенности хранения информационных массивов, в которых и находятся собственно сами данные.
Физическое проектирование.
Наиболее часто формализация представлений о предметной области осуществляется в рамках модели «объекты-связи» (так называемая ER-модель — от англ. Entity Relationship).
Под информационным объектом понимается некоторая сущность фрагмента действительности, например организация, документ, сотрудник, место, событие и т. д.
В предметной области выделяются различные типы объектов, представляемые в информационной системе в каждый момент времени конечным набором экземпляров данного типа. Каждый тип объекта включает (идентифицируется) присущий ему набор атрибутов (свойств, характерных признаков, параметров).
Атрибут представляет логически неделимый элемент структуры информации, характеризующийся множеством атомарных значений (атрибут «Имя» объекта типа «Лицо», атрибут «Текст» объекта типа «Документ»).
Один или некоторая группа атрибутов объекта данного типа могут исполнять роль ключевого атрибута, по которому различаются конкретные экземпляры объектов (объект «Лицо» - ключ совокупность атрибутов «Фамилия», «Имя», «Отчество» или один атрибут «Номер паспорта»).
Различные типы объектов и различные экземпляры одного типа объекта могут быть охвачены определенными отношениями, которые в рамках ER-модели выражаются связями.
Связи по признаку множественности могут быть трех типов: 1)«один-к-одному» (например, «Лицо-Паспорт»); 2)«один-ко-многим» (например, «Подразделение-Сотрудник»); 3)«многие-ко-многим» (например, отношение «Сотрудник -Документ»).
Концептуальные средства описания
Обычно различают концептуальные модели двух видов: 1)объектно-ориентированные модели, в которых сущности реального мира представляются в виде объектов, а не записей реляционных таблиц; 2)семантические модели, отражающие значения реальных сущностей и отношений.
Концептуальное моделирование баз данных на основе семантических моде¬лей поддерживается во всех известных CASE-средствах (например, таких как ERWin и Power
Designer). Кроме того, семантические модели более просты для понимания, особенно при проектировании сравнительно небольших баз данных.
Основной задачей логического проектирования является разработка логической схемы, ориентированной на СУБД. На этом этапе определяются отношения реляционной модели (таблицы СУБД), атрибуты (столбцы таблиц) и типы атрибутов (типы данных столбцов).
Выделяется несколько основных методов логического проектирования:
— отображение ER-диаграммы на логическую схему;
— нормализация таблиц.
Обычно логическое проектирование выполняется в следующей последовательности:
1) составление таблицы истинности синтезируемого узла согласно его определению, назначению и (словесному) описанию принципа работы ;
2) составление математической формулы для логической функции, описывающей работу синтезирующего узла, согласно имеющейся таблице истинности ;
3) анализ полученной функции с целью построения различных вариантов её математического выражения (на основании законов булевой алгебры) и нахождения наилучшего из них в соответствии с тем или иным критерием;
4) составление функциональной (логической) схемы узла из заранее заданного набора логических элементов .
15- Принципы и особенности проектирования интегрированных ИС. 17- Методы и средства организации метаинформации проекта ИС:
Первоначально профессиональные СУБД создавались для мощных высокопроизводительных платформ - IBM, DEC, Hewlett-Packard, Sun Но затем, учитывая все возрастающую популярность и широкое распространение персональных компьютеров, их разработчики приступили к переносу (портированию) СУБД в операционные среды desktop-компьютеров (OS/2, NetWare, UnixWare, SCO UNIX).
В настоящее время большинство компаний - поставщиков СУБД развивает три направления своих систем. Во-первых, совершенствование СУБД для корпоративных информационных систем, которые характеризуются большим числом пользователей (от 100 и выше), базами данных огромного объема (их часто называют сверхбольшими базами данных - Very Large Data Base - VLDB), смешанным характером обработки данных и т.д. Это - традиционная область mainframe-систем и приближающихся к ним по производительности RISC-компьютеров.
Другое направление - СУБД поддерживающие рабочие группы. Это направление характеризуется относительно небольшим количеством пользователей с сохранением, всех "многопользовательских" качеств. Системы этого класса ориентированы преимущественно на "офисные" применения, не требующие специальных возможностей. Так, большинство современных многопользовательских СУБД имеет версии системы, функционирующие в сетевой операционной системе Novell NetWare. Ядро СУБД оформлено здесь как загружаемый модуль NetWare NetWare Loadable Module - NLM), выполняющийся на файловом сервере. База данных также располагается на файловом сервере. SQL-запросы поступают к ядру СУБД от прикладных программ, которые запускаются на станциях сети - персональных компьютерах (отметим, что, несмотря на использование файлового сервера, здесь мы имеем дело с RDA-моделью).
Наконец, новый импульс в развитии получило направление desktop-версий СУБД, ориентированных на персональное использование - преимущественно в операционной среде MS Windows.
Стремление компаний - поставщиков СУБД иметь фактически по три варианта своих систем, покрывающих весь спектр возможных применений выглядит для пользователей чрезвычайно привлекательно. Действительно, для специалиста исключительно удобно иметь на своем легко транспортируемом портативном компьютере локальную базу данных в том же формате и обрабатываемую по тем же правилам, что и стационарную корпоративную базу данных фирмы, куда собранные данные могут быть без труда доставлены.
В 1987-94 в нашей стране было разработано множество программ, ориентированных на использование СУБД типа PARADOX, FoxPRO, dBASE IV, Clipper. При переходе на более мощную многопользовательскую СУБД у пользователей возникает естественное желание интегрировать уже существующие разработки в эту среду. Например, может возникнуть потребность хранить локальные данные на персональном компьютере и осуществлять к ним доступ с помощью системы FoxPRO, и одновременно иметь доступ к глобальной базе данных под управлением СУБД Oracle. Организация такого доступа, когда программа может одновременно работать и с персональной, так и с многопользовательской СУБД представляет собой сложную проблему по следующей причине.
Специалисты фирмы Microsoft разработали стандарт Open Database Connectivity (ODBC). Он представляет собой стандарт интерфейса прикладных программ и позволяет программам, работающим в среде Microsoft Windows, взаимодействовать с различными СУБД, как с персональными, так и с многопользовательскими, функционирующими в различных операционных системах. Фактически, интерфейс ODBC универсальным образом отделит чисто прикладную, содержательную сторону приложений от собственно обработки и обмена данными с СУБД. Основная цель ODBC - сделать взаимодействие приложения и СУБД прозрачным, не зависящим от класса и особенностей используемой СУБД. Отметим, что стандарт ODBC является неотъемлемой частью семейства стандартов, облегчающих написание и обеспечивающих вертикальную открытость приложений. Интерфейс ODBC обеспечивает взаимную совместимость серверных и клиентских компонентов доступа к данным. Для реализации унифицированного доступа к различным СУБД, было введено понятие драйвера ODBC, представляющего собой динамически загружаемую библиотеку.
ODBC-архитектура содержит четыре компонента: 1) приложение; 2)менеджер драйверов; 3)драйверы; 4)источники данных.
Роли среди них распределены следующим образом: Приложение вызывает функции ODBC для выполнения SQL-инструкций, получает и интерпретирует результаты; менеджер драйверов загружает ODBC-драйверы, когда этого требует приложение; ODBC-драйверы обрабатывают вызовы функций ODBC, передают операторы SQL СУБД и возвращают результат в приложение; источник данных - объект, скрывающий СУБД, детали сетевого интерфейса, расположение и полное имя базы данных и т.д.
Действия, выполняемые приложением, использующем интерфейс ODBC, сводятся к следующему: для начала сеанса работы с базой данных приложение должно подключиться к источнику данных, ее скрывающему; затем приложение обращается к базе данных, посылая SQL-инструкции, запрашивает результаты, отслеживает и реагирует на ошибки и т.д., то есть имеет место стандартная схема взаимодействия приложения и сервера БД, характерная для RDA-модели. Важно, что стандарт ODBC включает функции управления транзакциями. Завершив сеанс работы, приложение должно отключиться от источника данных.
16 вопрос - Система управления информационными потоками как средство интеграции приложений ИС:
Первоначально профессиональные СУБД создавались для мощных высокопроизводительных платформ - IBM, DEC, Hewlett-Packard, Sun Но затем, учитывая все возрастающую популярность и широкое распространение персональных компьютеров, их разработчики приступили к переносу (портированию) СУБД в операционные среды desktop-компьютеров (OS/2, NetWare, UnixWare, SCO UNIX).
В настоящее время большинство компаний - поставщиков СУБД развивает три направления своих систем. Во-первых, совершенствование СУБД для корпоративных информационных систем, которые характеризуются большим числом пользователей (от 100 и выше), базами данных огромного объема (их часто называют сверхбольшими базами данных - Very Large Data Base - VLDB), смешанным характером обработки данных и т.д. Это - традиционная область mainframe-систем и приближающихся к ним по производительности RISC-компьютеров.
Другое направление - СУБД поддерживающие рабочие группы. Это направление характеризуется относительно небольшим количеством пользователей с сохранением, всех "многопользовательских" качеств. Системы этого класса ориентированы преимущественно на "офисные" применения, не требующие специальных возможностей. Так, большинство современных многопользовательских СУБД имеет версии системы, функционирующие в сетевой операционной системе Novell NetWare. Ядро СУБД оформлено здесь как загружаемый модуль NetWare NetWare Loadable Module - NLM), выполняющийся на файловом сервере. База данных также располагается на файловом сервере. SQL-запросы поступают к ядру СУБД от прикладных программ, которые запускаются на станциях сети - персональных компьютерах (отметим, что, несмотря на использование файлового сервера, здесь мы имеем дело с RDA-моделью).
Наконец, новый импульс в развитии получило направление desktop-версий СУБД, ориентированных на персональное использование - преимущественно в операционной среде MS Windows.
Стремление компаний - поставщиков СУБД иметь фактически по три варианта своих систем, покрывающих весь спектр возможных применений выглядит для пользователей чрезвычайно привлекательно. Действительно, для специалиста исключительно удобно иметь на своем легко транспортируемом портативном компьютере локальную базу данных в том же формате и обрабатываемую по тем же правилам, что и стационарную корпоративную базу данных фирмы, куда собранные данные могут быть без труда доставлены.
В 1987-94 в нашей стране было разработано множество программ, ориентированных на использование СУБД типа PARADOX, FoxPRO, dBASE IV, Clipper. При переходе на более мощную многопользовательскую СУБД у пользователей возникает естественное желание интегрировать уже существующие разработки в эту среду.
18 вопрос - Типовое проектирование ИС. Понятие типового элемента.
Методы типового проектирования ИС предполагают создание системы из готовых покупных типовых элементов (типовых проектных решений), кот-ые в дальнейшем настраиваются на особенности конкретного предприятия или дорабатываются в соответствии с требованиями проблемной области.
Под типовым проектным решением (ТПР) - проектной док-тация, включая программные модули, проектное решение, пригодное к многократному использованию.
В качестве проектного решения может выступать реализация как отдельных компонентов ИС (программных модулей, функциональных задач, автоматизированных рабочих мест, локальных БД, локальных вычислительных сетей), так и взаимосвязанных комплексов компонентов (функциональных и обеспечивающих подсистем, ИС в целом).
Классификация ТПР: 1.Элементарный метод; 2.Подсистемный метод; 3. Объектный метод.
Задачи ТПР: Информационное обеспечение (БД, файлы); Программное обеспечение (ОС, СУБД); Техническое обеспечение (на какой технике); Математическое обеспечение (математические методы); Организационное обеспечение (методические материалы по работе с персоналом).
Типовой элемент системы - типовое решение по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному).
Сущность применения ТПР при элементном методе заключается в комплектации ИС из множества ТПР по отдельным разрозненным задачам. Если данного множества недостаточно для того, чтобы спроектировать систему, необходимые модули дорабатываются вручную. Достоинство элементного метода типового проектирования ИС связано с применением модульного подхода к проектированию и док-тированию ИС.
19 вопрос - Технологии параметрически-ориентированного и модельно-ориентированного проектирования:
При проектировании ИС на основе параметрической настройки пакета прикладных программ (ППП) последний рассматривается как «черный ящик» (рис.). На вход ППП подаются параметрический (ПП) и информационный (ИП) потоки, а выходом служит результат работы пакета (РП). ППП включает следующие блоки: функционирования, обработки параметров, адап-тации.
Информационный поток представляет собой исходные данные, которые обрабатываются и необходимы для получения результатов работы пакета. Исходные данные для функционирования пакета могут быть представлены в виде различных док-тов, причем как бумажных, так и электронных.
Результаты работы пакета могут быть представлены в виде отчетов, графиков, электронных док-тов, которые могут накапливаться или направляться во внешнюю среду.
Блок функционирования обрабатывает исходные данные и формирует результаты работы пакета. Графически блок функционирования представляется деревом программных модулей, которые автоматизируют функции обработки данных.
Параметрический поток - инф-ия, необходимая для настройки пакета на конкретные условия функционирования. Параметрический поток включает информацию, которая задается один раз при установке (инсталляции) этого пакета. Изменяя параметры, можно включать и выключать какие-либо модули или влиять на режим их работы. Для архитектуры «клиент-сервер» в параметрическом потоке описываются пользователи и их уровни доступа к программным модулям и ко всему пакету в целом.
Параметрическая инф-ия предоставляется:
· в справочниках (классификаторах с задаваемым числом уровней классификации, например, в справочниках номенклатуры изделий и услуг, видов расчетов, валют и т.д.);
· в таблицах описаний конфигурации программных модулей (например, условия включения (выключения) модуля, режимы ручного или автоматического обновления полей данных, методы расчетов показателей и т.д.).
Сущность применения метода типового проектирования ИС на основе параметрической настройки ППП заключается в определении критериев оценки ППП, оценке множества ППП-претендентов по сформулированным критериям, выбору и закупке ППП с наивысшей интегральной оценкой, а далее - собственно настройке параметров и возможной доработке закупленного ППП.
Модельно-ориентированное проектирование ИС
Сущность модельно-ориентированного проектирования ИС сводится к адаптации компонентов типовой ИС в соответствии с моделью проблемной области конкретной организационно-экономической системы. Для этого технология проектирования должна поддерживать как модель типовой ИС, так и модель конкретного предприятия, а также средства поддержания соответствия между ними.
Типовые модели описывают конфигурации информационной системы для определенных отраслей (автомобильной, электронной, нефтегазовой и др.) или типов производства (единичного, серийного, массового, непрерывного и др.).
Модель предприятия (проблемной области) строится либо путем привязки фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия.
20 Вопрос - Автоматизированное проектирование ИС с использованием CASE-технологии. Функционально-ориентированный и объектно-ориентированный подходы. Содержание -технологии протатипного создания приложений.
Термин CASE (Computer Aided System/Software Engineering) используется в довольно широком смысле. Первоначальное зна¬чение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоя¬щее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.д.) за счет ее автоматизации и интеграции поддерживающих средств.
Таким образом, CASE-технологии не могут считаться самостоятельными, они только обеспечивают, как минимум, высокую эффективность их применения, а в некоторых случаях и принципиальную возможность применения соответствующей методологии.
Большинство существующих CASE-систем ориентировано на автоматизацию проектирования программного обеспечения и основано на методологиях структурного (в основном) или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
Наибольшая потребность в использовании CASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ИС. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки.
Преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования сводятся к следующему:
· улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации;
· возможность повторного использования компонентов разработки;
· поддержание адаптивности и сопровождения ИС;
· снижение времени создания системы, что позволяет на ранних стадиях проектирования получить прототип будущей системы и оценить его;
· освобождение разработчиков от рутинной работы по документированию проекта, так как при этом используется встроенный документатор;
· возможность коллективной разработки ЭИС в режиме реального времени.
CASE-технология в рамках методологии включает в себя методы, с помощью которых на основе графической нотации строятся диаграммы, поддерживаемые инструментальной средой.
- Методология определяет шаги и этапность реализации проекта, а также правила использования методов, с помощью которых разрабатывается проект.
- Метод - это процедура или техника генерации описаний компонентов ИС (например, проектирование потоков и структур данных).
- Нотация - отображение структуры системы, элементов данных, этапов обработки с помощью специальных графических символов диаграмм, а также описание проекта системы на формальных и естественных языках.
- Инструментальные средства CASE - специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.
Архитектура CASE-средства
Ядром системы является база данных проекта - репозиторий (словарь данных). Он представляет собой специализированную базу данных, предназначенную для отображения состояния проектируемой ИС в каждый момент времени. Объекты всех диаграмм синхронизированы на основе общей информации словаря данных.
Графический редактор диаграмм предназначен для отображения в графическом виде в заданной нотации проектируемой ИС. Он позволяет выполнять следующие операции:
-создавать элементы диаграмм и взаимосвязи между ними;
-задавать описания элементов диаграмм;
-задавать описания связей между элементами диаграмм;
-редактировать элементы диаграмм, их взаимосвязи и описания.
Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ИС.
Он выполняет следующие функции:
· мониторинг правильности построения диаграмм;
· диагностику и выдачу сообщений об ошибках;
· выделение на диаграмме ошибочных элементов.
Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций:
· инициализации проекта;
· задания начальных параметров проекта;
· назначения и изменения прав доступа к элементам проекта;
· мониторинга выполнения проекта.
Сервис - представляет собой набор системных утилит по обслуживанию репозитория. Данные утилиты выполняют функции полномасштабных средств автоматизации, покрывающих весь жизненный цикл ИС.
Функционально-ориентированный подход.
Основными идеями функционально-ориентированной CASE-технологии являются идеи структурного анализа и проектирования информационных систем. Они заключаются в следующем:
1) декомпозиция всей системы на некоторое множество иерархически подчиненных функций;
2) представление всей инф-ии в виде графической нотации. Систему всегда легче понять, если она изображена графически.
В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы:
- BFD (Bussiness Function Diagram) - диаграмма бизнес-функ¬ций (функциональные спецификации);
- DFD (Data Flow Diagram) - диаграмма потоков данных (жестко ориентированы на какую-либо технологию обработки данных и отражают передачу инф-ии от одной функции к другой в рамках заданной технологии обработки);
- STD (State Transition Diagram) - диаграмма переходов состо¬яний (матрицы перекрестных ссылок);
- ERD (Entity Relationship Diagram) - ER-модель данных пред¬метной области (информационно-логические модели «сущность-связь»);
- SSD (System Structure Diagram) - диаграмма структуры программного приложения.
Объектно-ориентированный подход.
Структурная декомпозиция ИС на основе объектно-ориентированного подхода отличается от функционально-ориентированного подхода лучшей способностью отражать динамическое поведение системы в зависимости от возникающих событий.
В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML
Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы:
1) диаграмму прецедентов использования (Use-case diagram), которая отображает функциональность ИС в виде совокупности выполняющихся последовательностей транзакций;
2) диаграмму классов объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично ER-диаграмме функционально-ориентированного подхода;
3) диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий;
4) диаграммы взаимодействия объектов (Interaction diagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования;
5) диаграммы деятельностей (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более детальные диаграммы);
6) диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (могут декомпозироваться на более детальные диаграммы);
7) диаграмму компонентов (Component diagram), которая отображает физические модули программного кода;
8) диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети.
Понятие прототипного проектирования – RAD-технологии.
Данная технология обеспечивает создание на ранней стадии реализации действующей интерактивной модели системы, так называемой системы-прототипа, позволяющей наглядно продемонстрировать пользователю будущую систему, уточнить его требования, оперативно модифицировать интерфейсные элементы: формы ввода сообщений, меню, выходные док-ты, структуру диалога, состав реализуемых функций.
Согласованная система-прототип служит спецификацией для дальнейшей разработки ИС, что позволяет на ранних этапах проектирования выявить возможные ошибки проектирования и определить параметры будущей системы.
Для реализации технологии прототипного проектирования необходимо применять высокоуровневые инструментальные средства: инструменты быстрой разработки приложения в развитых СУБД - класс DEVELOPER и интегрированные инструменты быстрой разработки приложений - класс BUILDER.
22 вопрос - Стандартные методы совместного доступа к базам и программам в сложных информационных системах (драйверы ODBC, программная система CORBA):
Специалисты фирмы Microsoft разработали стандарт Open Database Connectivity (ODBC). Он представляет собой стандарт интерфейса прикладных программ и позволяет программам, работающим в среде Microsoft Windows, взаимодействовать с различными СУБД, как с персональными, так и с многопользовательскими, функционирующими в различных операционных системах. Фактически, интерфейс ODBC универсальным образом отделит чисто прикладную, содержательную сторону приложений от собственно обработки и обмена данными с СУБД. Основная цель ODBC - сделать взаимодействие приложения и СУБД прозрачным, не зависящим от класса и особенностей используемой СУБД. Отметим, что стандарт ODBC является неотъемлемой частью семейства стандартов, облегчающих написание и обеспечивающих вертикальную открытость приложений. Интерфейс ODBC обеспечивает взаимную совместимость серверных и клиентских компонентов доступа к данным. Для реализации унифицированного доступа к различным СУБД, было введено понятие драйвера ODBC, представляющего собой динамически загружаемую библиотеку.
ODBC-архитектура содержит четыре компонента: 1) приложение; 2)менеджер драйверов; 3)драйверы; 4)источники данных.
Роли среди них распределены следующим образом: Приложение вызывает функции ODBC для выполнения SQL-инструкций, получает и интерпретирует результаты; менеджер драйверов загружает ODBC-драйверы, когда этого требует приложение; ODBC-драйверы обрабатывают вызовы функций ODBC, передают операторы SQL СУБД и возвращают результат в приложение; источник данных - объект, скрывающий СУБД, детали сетевого интерфейса, расположение и полное имя базы данных и т.д.
Действия, выполняемые приложением, использующем интерфейс ODBC, сводятся к следующему: для начала сеанса работы с базой данных приложение должно подключиться к источнику данных, ее скрывающему; затем приложение обращается к базе данных, посылая SQL-инструкции, запрашивает результаты, отслеживает и реагирует на ошибки и т.д., то есть имеет место стандартная схема взаимодействия приложения и сервера БД, характерная для RDA-модели. Важно, что стандарт ODBC включает функции управления транзакциями. Завершив сеанс работы, приложение должно отключиться от источника данных.