Ais Lecture 3
1 like448 views
Документ представляет собой лекцию о проектировании автоматизированных информационных систем (АИС), охватывающую стадии создания, проектную документацию и особенности разработки. Основное внимание уделяется процессу проектирования баз данных, включая концептуальное проектирование, создание таблиц и проектирование реляционных баз данных. Лекция также описывает важность формулировки технических заданий и требования к информационному обеспечению систем.
![Проектирование АИС: обзор курса Бабич А.В. [email_address] http:/barhan.poltava.ua/lug/ Полтавский государственный педагогический университет Полтавский политехнический колледж](https://image.slidesharecdn.com/aislecture3-1232611577928799-2/85/Ais-Lecture-3-1-320.jpg)
Ais Lecture 3
- 1. Проектирование АИС: обзор курса Бабич А.В. [email_address] http:/barhan.poltava.ua/lug/ Полтавский государственный педагогический университет Полтавский политехнический колледж
- 2. Лекция 3 Общие положения по созданию АИС
- 3. О чем мы узнаем Проектная документация Концептуальное проектирование и проектирование схемы БД Проектирование и создание таблиц
- 4. Цель лекции Дать представление о стадиях проектирования АИС, нормативной документации, создаваемой на каждом этапе. Раскрыть некоторые характерные особенности процесса проектирования АИС.
- 5. Урок 1 Проектная документация
- 6. Проектная документация стандарты по созданию АС Создание АИС регламентируется «Комплексов стандартов и руководящих документов на АС» ГОСТ 34.601-90 определяет несколько стадий и этапов создания АС Один из центральных элементов процесса создания АС – разработка технического задания
- 7. Проектная документация стадии и этапы создания АС 1. Формирование требований к АС Обследование объекта и обоснование необходимости создания АС Формирование требований пользователя к АС Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)
- 8. Проектная документация стадии и этапы создания АС 2. Разработка концепции АС Изучение объекта Проведение необходимых научно-исследовательских работ Разработка вариантов концепции АС и выбор варианта, удовлетворяющего требованиям пользователя Оформление отчета о проделанной работе
- 9. Проектная документация стадии и этапы создания АС 3. Техническое задание Разработка и утверждение технического задания на создание АС
- 10. Проектная документация стадии и этапы создания АС 4. Эскизный проект Разработка предварительных проектных решений по системе и ее частям Разработка документации на АС и ее части
- 11. Проектная документация стадии и этапы создания АС 5. Технический проект Разработка проектных решений по системе и ее частям Разработка документации на АС и ее части Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (тех. заданий) на их разработку Разработка заданий на проектирование в смежных областях проекта объекта автоматизации
- 12. Проектная документация стадии и этапы создания АС 6. Рабочая документация Разработка рабочей документации на систему и ее части Разработка или адаптация программы
- 13. Проектная документация стадии и этапы создания АС 7. Ввод в действие Подготовка объекта автоматизации к вводу АС в действие Подготовка персонала Комплектация АС поставляемыми изделиями (программными и техническими средствами, etc.) Строительно-монтажные работы Пусконаладочные работы Проведение предварительных испытаний Проведение опытно й эксплуатации Проведение приемочных испытаний
- 14. Проектная документация стадии и этапы создания АС 8. Сопровождение АС Выполнение работ в соответствии с гарантийными обязательствами Послегарантийное обслуживание
- 15. Проектная документация техническое задание Согласно ГОСТ 34.602-89 техническое задание содержит такие разделы : общие сведения назначение и цели создания (развития) системы характеристика объектов автоматизации требования к системе состав и содержание работ по созданию системы порядок контроля и приемки системы требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие требования к документированию источники разработки
- 16. Проектная документация техническое задание Суть технического задания заключается в проработке, выборе и утверждении основных технических, организационных, программных, информационно-логических и лингвистических решений, которые устанавливаются в разделе «Требования к системе»: требования к системе в целом требования к функциям (задачам), выполняемым системой требования к видам обеспечения
- 17. Проектная документация техническое задание Требования к системе в целом отражают концептуальные параметры и характеристики создаваемой системы, среди которых указываются требования у структуре и функционированию системы, к надежности и безопасности, к численности и квалификации персонала и т.д.
- 18. Проектная документация техническое задание Требования к функциям (задачам) содержат перечень функций, задач или их комплексов; временной регламент каждой из них; требования к качеству их реализации; к форме представления выходной информации; характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций; достоверности выдачи результатов
- 19. Проектная документация техническое задание Требования по видам обеспечения в зависимости от вида системы содержат требования по математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методологическому и др. видам обеспечения системы
- 20. Проектная документация техническое задание Для большинства разновидностей АС (АИС) особое значение имеют требования по информационному обеспечению : требования к составу, структуре и способам организации данных в системе ( инфологическая схема ) к информационному обмену между компонентами системы к информационной совместимости со смежными системами по использованию российских и др. классификаторов, унифицированных документов
- 21. Проектная документация техническое задание … по применению СУБД к структуре процесса сбора, обработки, передачи данных в системе и представлению данных к защите данных к журналированию изменений, хранению, обновлению и восстановлению данных к процедуре придания юридической силы документам, продуцируем техническими средствами АС и др.
- 22. Проектная документация техническое задание На основе установленных в тех. задании основных требований и технических решений на последующих этапах конкретизируются и непосредственно разрабатываются компоненты и элементы системы.
- 23. Проектная документация техническое задание Например, на этапе «Разработка предварительных проектных решений по системе и ее частям» определяются: функции АС функции подсистем концепция информационной базы и ее укрупненная структура функции СУБД состав вычислительной системы функции и параметры основных программных средств
- 24. Проектная документация техническое задание На этапе «Разработка проектных решений по системе и ее частям» осуществляется разработка: по функционально-алгоритмической структуре системы по функциям персонала и организационной структуре по структуре технических средств по алгоритмам решения задач и применяемым языкам по организации и ведению информационной базы ( структура БД ) по системе классификации и кодирования информации ( словарно-классификационная база ) по программному обеспечению
- 25. Проектная документация техническое задание Разработка и документирование программного обеспечения в процессе создания и комплектования АС регламентируются комплексом стандартов – «Единая система программной документации (ЕСПД)» Создание АИС – сложный многоэтапный процесс, требующий привлечения различных категорий специалистов – программистов, инженеров, управленческих и др. работников
- 26. Урок 2 Концептуальное проектирование и проектирование схемы БД
- 27. Проектирование БнД Одна из наиболее трудоемких и сложных задач при создании АИС – проектирование банка данных , как основы подсистемы представления и обработки информации. Проектирование: концептуальное схемно-структурное В группу разработчиков входят специалисты: по формализации предметной области (постановщики задач, формализаторы) по программному обеспечению СУБД технические дизайнеры и специалисты по эргономике
- 28. Проектирование БнД концептуальное проектирование Концептуальное проектирование банков данных АИС – процесс во многом эвристический , а адекватность построенной инфологической схемы предметной области проверяется эмпирически по анализу и проверке удовлетворения информационных потребностей пользователей.
- 29. Проектирование БнД концептуальное проектирование Этапы концептуального проектирования: обзор и изучение области использования АИС для формирования общего представления о предметной области формирование и анализ круга функций и задач АИС определение основных объектов-сущностей предметной области и отношений между ними формализованное описание предметной области
- 30. Проектирование БнД обзор и изучение области использования АИС Обзор и изучение области использования АИС для формирования общего представления о предметной области выполняется разработчиком в тесном взаимодействии с заказчиком Разработчик изучает организационно-распорядительную документацию определяет: процессы участники информационные потоки Принципиальный момент – фрагментирование предметной области – разделение на организационные, технологические, функциональные и др. блоки предметная область
- 31. Проектирование БнД обзор и изучение области использования АИС При фрагментировании предметной области формализатор должен ответить на такие вопросы : выделить перечень фрагментов , подлежащих отражению в АИС лица, принимающие решения функционально-технологические структуры (подразделения) определить информационные потребности и информационные результаты деятельности фрагментов какая информация в каком виде в какие сроки определить общие характеристики и содержание процессов потребления и обработки информации фрагментами содержание информации технологии обработки, передачи, использования
- 32. Проектирование БнД обзор и изучение области использования АИС Ответы на эти вопросы помогают сформировать представление о существующей ( «как есть» ) технологии формирования, накопления, обработки и использования информации в рамках АИС и проанализировать (вместе с заказчиком) «узкие места» и недостатки в существующей технологии
- 33. Проектирование БнД определение круга функций и задач АИС После формирования общего представления о предметной области производится определение функций и задач АИС . Это делается на основе декомпозиции «лозунга» - основной цели создания АИС В ходе декомпозиции лозунга: определяется предварительный перечень пользователей системы уточняются информационные потребности пользователей
- 34. Проектирование БнД определение основных объектов предметной области Главный итоговый результат концептуального проектирования – определение основных объектов-сущностей предметной области и отношений между ними . Отношения : организационные технологические Отношения предметной области выражаются в документах : организационно-распорядительных информационно-справочных других нормативно-служебных документах
- 35. Проектирование БнД определение основных объектов предметной области Анализ «бумажной» документации перечень атрибутов , характеризующих объекты и отношения предметной области В одном документе могут быть отражены атрибуты разных объектов и отношений. Два подхода формирования перечня объектов предметной области и их атрибутов: дедуктивный индуктивный
- 36. Проектирование БнД определение основных объектов предметной области Дедуктивный подход: выделяются основные понятия и категории , которыми выражаются фрагменты предметной области эти понятия и категории принимаются за основу списка объектов-сущностей предметной области на основе анализа документации и взаимодействия с заказчиком формируются атрибуты выделенных объектов При определении списка атрибутов каждого объекта руководствуются соображениями минимальной достаточности – принцип «бритвы Оккама»: перечень объектов и их атрибутов должен быть достаточным перечень объектов и их атрибутов не должен быть избыточным
- 37. Проектирование БнД определение основных объектов предметной области Индуктивный подход: формируется общий перечень атрибутов предметной области на основе эвристического анализа проводится агрегация атрибутов в группы, образующие объекты предметной области Часть атрибутов и понятий предметной области выражают процессы-отношения между объектами. Такие атрибуты выделяются и анализируются параметры и характер связей , которые они выражают: структурность направленность множественность обязательность
- 38. Проектирование БнД определение основных объектов предметной области Чаще всего выделение объектов-сущностей, их атрибутов и отношений-связей осуществляется комбинированным способом на итерационной основе Распространенный прием – «обобщение» некоторых понятий и атрибутов – объединение в одну сущность близких или однотипных понятий, категорий, атрибутов на основе анализа их частных проявлений и вариантов.
- 39. Проектирование БнД формализованное описание предметной области Формализованное описание концептуальной схемы банка данных осуществляется средствами одной их семантических моделей данных В большинстве случаев семантические модели применяются на стадии концептуального проектирования с последующим преобразованием концептуальной схемы в структуру соответствующей реляционной БД . Наиболее известные семантические модели: ER- модели – диаграммы Бахмана (Пин-Шен-Чен, 1976) UML - диаграммы классов
- 40. Проектирование БнД формализованное описание предметной области Формализованное описание концептуальной схемы банка данных – основа эскизного проекта создания БнД ИС Следующий шаг – построение средствами СУБД схемы БнД, соответствующей концептуальной схеме Адекватность реализации концептуальной схемы БнД определяется эвристически и эмпирически в ходе отладки и пилотной эксплуатации БнД
- 41. Урок 3 Проектирование и создание таблиц
- 42. Проектирование таблиц проектирование схем реляционных БД При проектировании схемы реляционной БД можно выделить такую последовательность процедур: определение перечня таблиц и их связей определение перечня полей, типов полей, ключевых полей таблиц, установление связей между таблицами через внешние ключи определение и установление индексов для полей таблиц разработка списков (словарей) для полей с перечислимым характером значений данных установление ограничений целостности по полям таблиц и связям нормализация таблиц, доработка перечня таблиц и их связей Первые пять процедур называют процессом предварительного проектирования таблиц и связей между ними
- 43. Проектирование таблиц проектирование и создание таблиц Для каждого объекта-сущности в реляционных СУБД проектируют соответствующую таблицу . Поля таблиц соответствуют атрибутам информационных объектов концептуальной схемы БнД Основные базисные характеристики: домен поле-атрибут кортеж отношение ключ внешний ключ
- 44. Проектирование таблиц проектирование и создание таблиц Кроме этого указывается тип поля . Понятие типа поля в СУБД = тип в ЯП . Традиционно поддерживаемые СУБД простые типы: числовой символьный темпоральный (дата / время) булевский (логический) Современные СУБД: специализированные типы полей денежный OLE MEMO и др. Сложные типы, позаимствованные из ЯП высокого уровня
- 45. Проектирование таблиц проектирование и создание таблиц Домен ≠ тип! Домен – подмножество базисного типа данных с определенной смысловой нагрузкой. Пример – множество всех имен из множества всевозможных значений символьного типа.
- 46. Проектирование таблиц проектирование и создание таблиц Требование уникальности кортежей определение и установление ключевых полей таблиц реляционных СУБД Определение ключевого поля выполняется на основе смыслового эвристического анализа тематики таблицы + принцип минимальной достаточности количество полей, образующих ключ таблицы, должно быть минимальным Часто как ключевые поля используются поля типа « AUTOINCREMENT » ( AUTOINC, Счетчик)
- 47. Проектирование таблиц проектирование и создание таблиц Реляционная модель обеспечивает лишь два типа связей-отношений: Один-ко-многим создание внешнего ключа Установление связи Один-к-одному связывание таблиц по одноименным и однотипным полям Пример: М-21 Сидоров И.П. 569 77 М-23 Петров С.И. 568 М-21 Иванов П.С. 567 Комната в общежитии Группа ФИО № зачетки М-21 Сидоров И.П. 569 М-23 Петров С.И. 568 М-21 Иванов П.С. 567 Группа ФИО № зачетки 77 Петров С.И. 568 Комната в общежитии ФИО № зачетки
- 48. Проектирование таблиц проектирование и создание таблиц Связи типа «Многие-ко-многим» в реляционных СУБД реализуются через создание двух связей «Один-ко-многим» - введение связной таблицы Пример: Документы Рег. № Название Сотрудники № ФИО ∞ Согласование ∞ Документы Рег. № Название Сотрудники № ФИО Согласование Рег. № № Название 1 1 ∞ ∞ 1
- 49. Проектирование таблиц проектирование и создание таблиц Пример – реализация: Один документ согласован двумя сотрудниками Один сотрудник согласовал два документа О кредите 4774 О сбыте 1234нс О поставках 1497с Название Рег. № Документы Сидоров И.П. 134 Петров С.И. 133 Иванов П.С. 132 ФИО № Сотрудники 16.02.04 132 4774 17.02.04 134 1497с 15.02.04 132 1497с Дата № Рег. № Согласование
- 50. Проектирование таблиц проектирование и создание таблиц Важный момент проектирования таблиц – определение необходимости индексирования тех или иных полей таблиц Если в одной таблице установлено более 10 индексов, то: недостаточно продумана структура БД (таблицы) или неправильно выбраны поля, по которым чаще всего производится поиск ключевые поля индексируются автоматически внутреннее устройство индексных массивов обычно остается скрытым и для пользователей и для разработчиков
- 51. Проектирование таблиц проектирование и создание таблиц Также важное значение имеет выделение полей с перечислимым (перечислительным, словарным, списковым) характером значений . Значения таких полей определяются из некоторого унифицированного списка-словаря Словари (списки): фиксированные «привязываются» к соответствующим полям БД и размещаются в каталоге БД динамические реализуются через создание дополнительных одностолбцовых таблиц
- 52. Проектирование таблиц проектирование и создание таблиц В практическом плане важным является установление ограничений целостности по полям и связям Ограничения по значениям полей уникальность кортежей уникальность значений ключевых полей UNIQUE NOT NULL допустимые диапазоны значений полей относительные соотношения значений по полям таблицы Ограничения целостности данных отражают ту часть правил и особенностей предметной области , которая не формализуется в реляционной модели ( бизнес-правила )
- 53. Проектирование таблиц проектирование и создание таблиц Три подхода реализации требования целостности по ссылкам : запрет удаления записи , если на нее существуют ссылки из других таблиц при удалении записи значения внешних ключей всех связанных записей становятся неопределенными каскадное удаление всех записей, связанных с удаляемой Разделение процесса проектирования таблиц на этапы является условным, а сам процесс предварительного проектирования (создания) таблиц реализуется инструкциями SQL
- 54. Проектирование таблиц нормализация таблиц Нормализация реляционных таблиц-отношений – следствие: требования атомарности значений полей требования рациональности группировки полей-атрибутов по различным таблицам Нормализация таблиц – доработка концептуальной схемы данных Нормализация таблиц – последовательный процесс разбиения и преобразования некоторого небольшого исходного набора таблиц для построения набора взаимосвязанных таблиц в нормальных формах
- 55. Проектирование таблиц нормализация таблиц Наиболее простая – первая нормальная форма = требование атомарности полей и единственности значений по полям в реляционной модели
- 56. Проектирование таблиц нормализация таблиц Пример приведения к первой нормальной форме: BMW операция «Багамы» 2234 111 Ягуар «Золотой глаз» капитан Бонд 007 2233 110 - операция «Берн» полковник Исаев 002 отпуск «Бриллиантовая рука» 2233 110 премия операция «Ы» майор Пронин 001 Награда Кодовое название Телефон Кабинет Мероприятия в кот. принимал участие Звание Фамилия Личный № 2234 111 капитан Бонд BMW операция «Багамы» 007 2234 111 капитан Бонд Ягуар «Золотой глаз» 007 2233 110 полковник Исаев - операция «Берн» 002 2233 110 майор Пронин отпуск «Бриллиантовая рука» 001 2233 110 майор Пронин премия операция «Ы» 001 Телефон Кабинет Звание Фамилия Награда Кодовое название мероприятия Личный №
- 57. Проектирование таблиц нормализация таблиц Таблицы в первой нормальной форме могут содержать: ситуации дублирования данных аномалии схемы таблиц-отношений Е. Кодд разработал механизм разбиения таблиц для приведения к более совершенным нормальным формам – функциональная зависимость полей-атрибутов
- 58. Проектирование таблиц нормализация таблиц Поле-атрибут Y функционально зависит от поля атрибута X , если любому значению X всегда соответствует одно и только одно значение Y В первой нормальной форме все неключевые атрибуты функционально зависят от ключа таблицы.
- 59. Проектирование таблиц нормализация таблиц Вторая нормальная форма основана на понятии полной функциональной зависимости Функциональная зависимость неключевого атрибута от составного ключа таблицы называется полной , если он зависит от составного ключа в целом, но не зависит от любой его части Таблица находится во второй нормальной форме , если она находится в первой нормальной форме и все ее неключевые атрибуты функционально полно зависят от составного ключа
- 60. Проектирование таблиц нормализация таблиц Пример приведения во вторую нормальную форму: 2234 111 капитан Бонд BMW операция «Багамы» 007 2234 111 капитан Бонд Ягуар «Золотой глаз» 007 2233 110 полковник Исаев - операция «Берн» 002 2233 110 майор Пронин отпуск «Бриллиантовая рука» 001 2233 110 майор Пронин премия операция «Ы» 001 Телефон Кабинет Звание Фамилия Награда Кодовое название мероприятия Личный № BMW операция «Багамы» 007 Ягуар «Золотой глаз» 007 - операция «Берн» 002 отпуск «Бриллиантовая рука» 001 премия операция «Ы» 001 Награда Кодовое название мероприятия Личный № 2234 111 капитан Бонд 007 2233 110 полковник Исаев 002 2233 110 майор Пронин 001 Телефон Кабинет Звание Фамилия Личный №
- 61. Проектирование таблиц нормализация таблиц В таблицах, находящихся во второй нормальной форме большинство аномалий , присущих первой нормальной форме, устранено . Вместе с тем, могут сохраниться ситуации дублирования данных транзитивная зависимость атрибутов
- 62. Проектирование таблиц нормализация таблиц Таблица-отношение находится в третьей нормальной форме , если она находится во второй нормальной форме и каждое ее неключевое поле-атрибут нетранзитивно зависит от первичного ключа Третья нормальная форма = взаимная независимость неключевых атрибутов и их полная функциональная зависимость от первичного ключа
- 63. Проектирование таблиц нормализация таблиц Пример приведения во вторую нормальную форму: 2234 111 капитан Бонд 007 2233 110 полковник Исаев 002 2233 110 майор Пронин 001 Телефон Кабинет Звание Фамилия Личный № 111 капитан Бонд 007 110 полковник Исаев 002 110 майор Пронин 001 Кабинет Звание Фамилия Личный № 2234 111 2233 110 Телефон Кабинет
- 64. Проектирование таблиц нормализация таблиц Третья нормальная форма устраняет : большинство аномалий схем таблиц-отношений ситуации дублирования данных В некоторых случаях третью нормальную форму можно «улучшить» приведением в нормальную форму Бойса-Кодда детерминанты – совокупность атрибутов, от которых функционально полно зависят другие атрибуты «Улучшения» нормальной формы Бойса-Кодда связаны с многозначной зависимостью атрибутов Существуют также четвертая и пятая нормальные формы
- 65. Проектирование таблиц нормализация таблиц Нормализация исходных таблиц при проектировании БнД проводится для рационализации группировки полей-атрибутов в схемах таблиц с целью устранения аномалий и дублирования данных Нормализация = декомпозиция исходных таблиц на множество связанных и не связанных более простых таблиц при обработке данных выполняется множество операций соединения таблиц обычно ограничиваются третьей нормальной формой
- 66. Проектирование таблиц нормализация таблиц Результат проектирования и нормализации таблиц – законченная схема (логическая структура) БД Технологически описание схемы БД помещается в каталог БД (системную таблицу) Обычно каталог БД хранится в файле БД вместе с данными
- 67. Проектирование таблиц нормализация таблиц Для повышения эффективности схемно-структурного проектирования БнД применяются CASE- системы: Designer (Oracle) ERWin/PBWin PowerBuilder UML tools Визуализированная концептуальная схема БнД транслируется CASE- системой в схему соответствующего реляционного БнД Подобные тенденции наблюдаются во многих современных СУБД, в т.ч. персональных Появляются также специальные анализаторы структуры таблиц БД
- 68. Итоги ГОСТ 34.601-90 определяет несколько стадий и этапов создания АС Один из центральных элементов процесса создания АС – разработка технического задания Создание АИС – сложный многоэтапный процесс, требующий привлечения различных категорий специалистов – программистов, инженеров, управленческих и др. работников Проектирование БнД: концептуальное схемно-структурное Существует пять нормальных форм, но чаще всего останавливаются на третьей CASE -системы позволяют визуально построить концептуальную схему БнД и оттранслировать ее в схему реляционного БнД
- 69. Вопросы ? ?
- 70. Вопросы Какой документ является центральным в процессе создания АС ? Врачи поликлиники ведут прием и обследование пациентов. Выделите основные объекты-сущности предметной области и отношения между ними для концептуального проектирования БнД АИС, автоматизирующей учет обследований пациентов. Изобразите концептуальную схему Что такое CASE- средства и для чего они предназначены ?
- 71. Вопросы продолжение При концептуальном проектировании БнД АИС, автоматизирующей ведение табеля рабочего времени сотрудников организации, выделены следующие объекты-сущности: Сотрудник Табель Сотрудник Нетрудоспособность Отпуск ∞ ∞ ∞ ∞ 1 1 С учетом того, что Табель является основой для начисления зарплаты, определите необходимые атрибуты каждого объекта концептуальной схемы
- 72. Вопросы продолжение Приведите к первой нормальной форме следующую ненормализованную таблицу (в рамке – ключ таблицы): Урюпинск ЗАО «Степь» 11.12.99 15.12.99 7347 6-й отдел Петров С.И. 233 Гряжск НПО «Заря» 21.11.99 15.11.99 7245 Черноморск ПО «Кристалл» 20.10.99 01.10.99 7234 1-й отдел Иванов П.С. 231 Город Организация Дата окончания Дата начала № Командировка Подразделение ФИО Таб. №
- 73. Использованные материалы Гайдамакин Н.А. Автоматизированные информационные системы, базы и банки данных. Вводный курс: Учебное пособие. – М.: Гелиос АРВ, 2002. С. Д. Кузнецов. Проектирование и разработка корпоративных информационных систем. © Центр Информационных Технологий, 1998 С. Д. Кузнецов. Концептуальное проектирование схемы реляционных БД с использованием UML . © Центр Информационных Технологий, 2000
Editor's Notes
- #2: Предлагаемый материал содержит доступную автору (возможно, не исчерпывающую) информацию по поводу проектирования, разработки, сопровождения и реинжиниринга информационных систем. Информация - это самое ценное достижение человечества. Она ценнее, чем алмазы и золото. Информация помогает нам жить. Информационные системы дают нам шанс на то, чтобы выжить. Грубо говоря, "data and knowlegment mining", т.е. добыча данных и знаний является нашей основной задачей. Задачей не русских, не японцев, не американцев, не какой-то конкретной страны, но всего человечества. Мы все непрерывно накапливаем данные и знания, но проблема состоит в том, чтобы все это переварить и полезно использовать. Для этого и предназначены компьютеризованные информационные системы. Они служат нам, чтобы более быстро, более надежно обработать информацию, чтобы люди не тратили рутинное время, чтобы избежать свойственных человеку случайных ошибок, чтобы сэкономить расходы, чтобы сделать жизнь людей более комфортной. Мы просто не можем справиться с поступающей информацией без компьютерной поддержки. Но для этого нужно уметь использовать существующие, а также проектировать, разрабатывать и сопровождать новые информационные системы. Собственно, этому и посвящен настоящий курс.