- •Оглавление
- •1. Введение. Представление данных в памяти компьютера 3
- •2. Модели представления данных 43
- •3. Проектирование реляционных бд 83
- •4 Реляционная алгебра 114
- •5. Case – технологии 127
- •6. Организация доступа прикладной программы 178
- •1. Введение. Представление данных в памяти компьютера
- •1.1 Предмет дисциплины и ее задачи
- •1.2 Основные понятия
- •1.3 Файловые системы, как первый шаг к субд
- •1.4 Структурная схема субд и основные функции
- •1.5 Преимущества и недостатки субд по сравнению с файловыми системами
- •1.6 Организация внешней памяти реляционной субд
- •1.7 Типы и структуры данных
- •1.8 Типы и структуры данных, применяемые в реляционных бд
- •1.9 Типы и структуры данных, применяемые в объектно-реляционных бд
- •1.10 Понятие модели данных
- •2. Модели представления данных
- •2.1 Иерархическая модель данных
- •2.2 Сетевая модель данных
- •2.3 Реляционная модель данных
- •2.4 Свойства отношений. Отличие отношений от таблиц.
- •2.5 Понятие целостности данных
- •2.6 Ограничения реляционных баз данных
- •2.7 Суть постреляционного объектно-ориентированного подхода
- •2.8 Объектно-ориентированные субд и стандарт odmg
- •2.9 Объектно-реляционные субд
- •2.10 No sql бд и субд
- •1. NoSql базы в-основном оупенсорсные и созданы в 21 столетии.
- •6. Распределенные системы
- •3. Проектирование реляционных бд
- •3.1 Этапы разработки базы данных
- •3.2 Критерии оценки качества логической модели данных
- •3.3 Проектирование баз данных на основе нормализации отношений
- •3.4 Первая нормальная форма
- •3.5 Аномалии обновления
- •3.6 Функциональные зависимости
- •3.7 Вторая нормальная форма
- •3.8 Третья нормальная форма
- •3.9 Алгоритм нормализации (приведение к 3nf)
- •3.10 Oltp и olap-системы
- •3.11 Корректность процедуры нормализации. Теорема Хеза
- •3.12 Нормальная Форма Бойса-Кодда (nfbk)
- •3.13 Четвертая Нормальная Форма
- •3.14 Пятая Нормальная Форма
- •3.15 Продолжение алгоритма нормализации (приведение к 5 nf)
- •4 Реляционная алгебра
- •4.1 Операции над отношениями: общие сведения
- •4.2 Синтаксис операторов реляционной алгебры
- •4.3 Оптимизация алгоритмов реализации запросов
- •5. Case – технологии
- •5.1 Общие вопросы проектирования ис, понятие case-технологии
- •5.2 Жизненный цикл по ис
- •5.3 Модели жизненного цикла по
- •5.4 Методология rad
- •5.5 Структурный подход к проектированию ис
- •5.6 Методология функционального моделирования sadt (idef0)
- •5.7 Моделирование потоков данных (методология Гейна-Сарсона)
- •5.8 Методы построения диаграмм «сущность-связь» (erd)
- •5.9 Моделирование данных case-методом Баркера
- •5.10 Методология idef1
- •6. Организация доступа прикладной программы к серверу базы данных
- •6.1 Общие сведения
- •6.2 Использование специализированных библиотек и встраиваемого sql
- •6.4 Odbc – открытый интерфейс к бд на платформе ms Windows
- •6.5 Jdbc - интерфейс к базам данных на платформе Java
- •6.6 Прикладные интерфейсы ole db и ado
- •Литература
5.2 Жизненный цикл по ис
Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО).
ЖЦ ПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Модель жизненного цикла ПО – это структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 (российский аналог — ГОСТ Р ИСО/МЭК 12207-99). ISO (International Organization of Standardization) – это Международная организация по стандартизации, а IEC (International Electrotechnical Commission) – Международная комиссия по электротехнике.
По стандарту модель ЖЦ ПО включает в себя:
стадии;
результаты выполнения работ на каждой стадии;
ключевые события – точки завершения работ и принятия решений.
Стадия – это часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.
На каждой стадии могут выполняться несколько процессов, определенных в стандарте, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.
Каждый процесс разделен на набор действий, каждое действие – на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения. Связи по входным данным при этом сохраняются.
Структура ЖЦ ПО базируется на трех группах процессов:
основные (приобретение, поставка, разработка, эксплуатация, сопровождение);
вспомогательные (документирование, управление конфигурацией, обеспечение качества, верификация, совместная оценка, разрешение проблем);
организационные (управление, создание инфраструктуры, усовершенствование, обучение).
Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия: инициирование приобретения, подготовка заявочных предложений, подготовка и корректировка договора, надзор за деятельностью поставщика, приемка и завершение работ.
Каждое действие включает ряд задач. Например, подготовка заявочных предложений должна предусматривать: формирование требований к системе, формирование списка программных продуктов, установление условий и соглашений, описание технических ограничений (среда функционирования системы и т. д.).
Рассмотрим некоторые процессы подробнее.
Разработка включает в себя все работы по созданию ПО и его компонент в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала (руководства пользователя) и т.д. Разработка ПО включает в себя, как правило, анализ, проектирование и реализацию (программирование).
Эксплуатация включает в себя работы по внедрению компонентов ПО в эксплуатацию, в том числе конфигурирование БД и рабочих мест пользователей, обеспечение эксплуатационной документацией, проведение обучения персонала и т.д., и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию ПО в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы.
Сопровождение включает действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения. Под сопровождением понимают внесение изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования ПО. Верификация – это процесс определения того, отвечает ли текущее состояние разработки, достигнутое на данном этапе, требованиям этого этапа. Проверка позволяет оценить соответствие параметров разработки с исходными требованиями. Проверка частично совпадает с тестированием, которое связано с идентификацией различий между действительными и ожидаемыми результатами и оценкой соответствия характеристик ПО исходным требованиям. В процессе реализации проекта важное место занимают вопросы идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом.
Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.
Аттестация – это определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению.
Аудит позволяет определить соответствие проекта требованиям, планам и условиям договора.
Разрешение проблем – это анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов.
Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО имеет итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах [10].
В РБ до настоящего времени при разработке ИС принято использовать советский стандарт ГОСТ 34.601-90, который предусматривает следующие стадии создания автоматизированной системы (АС): формирование требований, разработка концепции АС, разработка и утверждение технического задания на создание АС, эскизный проект, технический проект, рабочая документация, ввод в действие и сопровождение АС. Все стадии разбиты на этапы, которые подробно описываются в тексте стандарта. Однако данный стандарт не вполне подходит для проведения разработок в настоящее время: многие процессы отражены недостаточно, а некоторые положения устарели.