Файл: Тема Введение в теорию баз данных Вопрос Основные понятия.pdf

Физическая модель - отражает все свойства (атрибуты) информационных объектов базы и связи между ними с учетом способа их хранения - используемой СУБД.
Внутренняя модель - база данных, соответствующая определенной физической модели.
Внешняя модель - комплекс программных и аппаратных средств для работы с базой данных, обеспечивающий процессы создания, хранения,
редактирования, удаления и поиска информации, а также решающий задачи выполнения необходимых расчетов и создания выходных печатных форм.
Создание информационной системы ведется в несколько этапов, на каждом из которых конкретизируются и уточняются элементы разрабатываемой системы.
Вопрос 4. Жизненный цикл базы данных. Модели жизненного цикла.
[4]
Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует.
Известны следующие базовые модели жизненного цикла: каскадная, поэтапная (каскадная с обратной связью), спиральная.
Каскадная модель.
Каскадная модель, в которой переход на следующий этап означает полное завершение работ на предыдущем этапе.
В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ (или «водопад»).
Его основной характеристикой является разбиение всей разработки на этапы, при этом переход на следующий этап происходит только после полного завершения работ на текущем (рис. 5).
Рис. 5. Каскадная схема разработки ПО
Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. При этом этапы работ выполняются в логичной последовательности, что позволяет планировать сроки завершения всех работ и соответствующие затраты. Этот подход хорошо зарекомендовал себя при построении ИС, для которых в начале разработки можно достаточно точно и полно сформулировать все требования и предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения.
Его недостатки связаны с тем, что реальный процесс создания ПО ИС обычно не укладывается в такую жёсткую схему. Практически постоянно возникает потребность возвращаться к предыдущим этапам, уточнять или пересматривать принятые решения. В результате затягиваются сроки выполнения работы, пользователи могут вносить замечания лишь по завершению всех работ с системой. При этом модели автоматизируемого объекта могут устареть к моменту их утверждения.

---

Поэтапная модель.
Поэтапная модель с промежуточным контролем. (См. рис. 6) Разработка ПО ведётся итерациями с циклами обратной связи между этапами.
Межэтапные корректировки позволяют уменьшить трудоёмкость процесса разработки по сравнению с каскадной моделью. Время жизни каждого из этапов растягивается на весь период разработки.
Рис. 6. Поэтапная модель с промежуточным контролем
Спиральная модель.
В этой модели (рис. 7) особое внимание уделяется начальным этапам разработки – выработке стратегии, анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).
Рис. 7. Спиральная модель
Каждый виток спирали предполагает создание фрагмента (компонента) или версии программного продукта. На них уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом, углубляются, последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Полный жизненный цикл ИС должен поддерживаться комплексом инструментальных средств с учётом необходимости: адаптации типового проекта к различным системно-техническим платформам (техническим средствам, операционным системам и СУБД) и организационно-экономическим особенностям объектов внедрения; интеграции с существующими разработками (включая реинжиниринг приложений и конвертирование БД); обеспечения целостности проекта и контроля за его состоянием (наличие единой технологической среды создания, сопровождения и развития ИС, а также целостность репозитария). При этом желательно обеспечить независимость от программно-аппаратной платформы и СУБД, поддержку одновременной работы групп разработчиков, открытую архитектуру и возможности экспорта/импорта.
Вопрос 5. Методологии и стандарты.
Для решения задач проектирования сложных систем существуют специальные методологии и стандарты. К таким стандартам относятся методологии семейства
IDEF (Icam DEFinition, ICAM - Integrated Computer-Aided Manufacturing - первоначально разработанная в конце 70-х гг. программа ВВС США
интегрированной компьютерной поддержки производства). С их помощью можно эффективно проектировать, отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах.
Другие методологии, используемые при моделировании сложных систем:

---

·
DFD-технология анализа «потока данных» (Data Flow Diagrams);
·
Workflow-технология анализа «потока работ».
Важное место в моделировании информационных систем занимает методология и системы, использующие UML - унифицированный язык моделирования (Unified Modeling Language). UML - язык для спецификации, визуализации, конструирования и документирования сложных информационно-насыщенных объектных систем. В настоящее время зарегистрирован как международный стандарт ISO/IEC 19501:2005 «Information technology - Open Distributed Processing - Unified Modeling Language (UML)».
Одной из последних разработок в области моделирования предприятия является создание специального унифицированного языка моделирования
UEML (Unified Enterprise Modeling Language).
Разработка UEML - сетевой проект (IST-2001-34229), финансируемый Евросоюзом (см. http://athena.troux.com/akmii/Default.aspx?WebID=249).
Проект UEML включает создание:
·
общего, визуального, базированного на шаблонах языка для коммерческих инструментальных средств моделирования предприятий и программных систем класса workflow;
·
стандартизованных, независимых от инструментов механизмов передачи моделей между проектами;
·
репозитория моделей предприятий.
Данный проект осуществляется в соответствии с международными стандартами:
Таблица 1.
ISO 14258
Rules and Guidelines for Enterprise Models (Правила и руководящие принципы для моделей предприятия);
ISO 15704
Requirements for enterprise-reference architectures and methodologies (Требования и методологии по описанию архитектуры предприятия).
Инструментальные средства моделирования предприятий, поддерживающие язык UEML, Metis (Computas), e-MAGIM (GraiSoft), MOzGO (IPK) и др.
В нашей стране в списке действующих ГОСТов по разработке автоматизированных систем (по данным Стандартинформ http://www.vniiki.ru/catalog_v.asp?page=1) следующие:
Таблица 2.
ГОСТ 34.003-90
«Информационная технология. Комплекс стандартов на автоматизированные системы. Термины и определения»;
ГОСТ 34.201-89
«Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»;
ГОСТ 34.601-90
«Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»;
ГОСТ 34.602-89
«Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».
ГОСТ 19.101-77
«Единая система программной документации. Общие положения» и т.д.( На разработку программной документации действуют стандарты класса ЕСПД)
Стадии и этапы создания автоматизированных систем (АС) в соответствии с ГОСТ 34.601-90 приведены в табл 3:

---

Таблица 3.
Стадии
Этапы работ
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. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий)
на их разработку.
5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
6. Рабочая документация
6.1. Разработка рабочей документации на систему и ее части. 6.2. Разработка или адаптация программ
7. Ввод в действие
7.1. Подготовка объекта автоматизации к вводу АС в действие. 7.2.
Подготовка персонала.
7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами,
информационными изделиями).
7.4. Строительно-монтажные работы.
7.5. Пусконаладочные работы.
7.6. Проведение предварительных испытаний.
7.7. Проведение опытной эксплуатации.
7.8. Проведение приемочных испытаний
8. Сопровождение
8.1. Выполнение работ в соответствии с гарантийными обязательствами.
8.2. Послегарантийное обслуживание
Для проектирования концептуальной модели и формирования физической модели базы данных информационной системы можно использовать инструментальные CASE-средства (Computer-Aided Software System Engineering). Например, Case Studio, SyBase Power Disigner, ERWin Data Modeler и др.
Данные системы применяются при описании модели данных стандарт IDEF1X и позволяют генерировать программный код на языках SQL, VBScript,
JScript, либо работать с другими технологиями для переноса физической модели в реальные СУБД, которыми могут быть Oracle, Microsoft SQL Server, IBM
DB2, Informix, Microsoft Access и др.
На рис. 8. приведена схема, показывающая взаимосвязь основных терминов в области проектирования баз данных и работы с ними.

---

Рис. 8. Взаимосвязь основных терминов в области проектирования баз данных и работы с ними
Выбор системы для разработки приложений, работающих с базой данных, сложное и ответственное решение. Такую возможность имеют универсальные системы программирования: Visual C++ и C#, Delphi, Visual Basic и др. Однако специализированные языки программирования в составе
СУБД располагают огромным количеством процедур и функций для работы с базами данных, специальными библиотеками, механизмами для ускорения работы с большими базами данных.
В связи с повсеместным распространением Интранета, Экстранета и Интернета, многие системы имеют возможность создания трехуровневой сервис-ориентированной архитектуры Web-приложений для работы с базами данных.
По принятым сегодня нормам, над любым проектом ИС работают:
·
бизнес-аналитики, изучающие и моделирующие бизнес-процессы предметной области;
·
системные аналитики и архитекторы, проектирующие архитектуру решения, приложений и данных;
·
авторы кода приложений;
·
специалисты по тестированию и оценке качества;
·
авторы документации;
·
авторы дистрибутивов;
·
специалисты по внедрению.
Причем обычно эти функции распределяются между различными специалистами, хотя совмещение ролей все еще практикуется. На этапах проектирования и программирования могут использоваться методы объектно-ориентированного подхода к разработке объектов информационной системы
(наследование, инкапсуляция, полиморфизм).
Вопрос 6. Пользователи баз данных.
В информационных системах, создаваемых на основе СУБД, способы организации данных и методы доступа к ним перестали играть решающую роль, поскольку оказались скрытыми внутри СУБД. Массовый, так называемый конечный пользователь, как правило, имеет дело только с внешним интерфейсом, поддерживаемым СУБД. Эти преимущества, как уже понятно, не могут быть реализованы путем механического объединения данных в БД.
Предполагается, что в системе существует (как неотъемлемая составная часть) специальное должностное лицо (группа лиц) - администратор базы
данных (АБД), который несет ответственность за проектирование и общее управление базой данных.
АБД определяет информационное содержание БД. С этой целью он идентифицирует объекты БД и моделирует базу, используя язык описания данных.

---