3 Типа атрибутов:

1. Ключевой (*) – это основной индетефикатор объекта (индетефикатор или индетефикация – это однозначное определение каждого экземпляра объекта). Индетефикатор может включать в себя несколько атрибутов. В этом случае он называется составным индетефикатором или составным ключом.  

2. Описательный (●) – это обычные описательные характеристики объекта

3. Производный (○) – это атрибут, который определяется на основе других атрибутов. Такие атрибуты часто представляют собой сводную информацию. Например ср. возраст студента, общ. Сумма стипендии с учетом льгот. Множество допустимых значений, которые может принимать атрибут называется доменом атрибута или областью определения атрибута.

Целостность данных (Data integrity) - свойство, при выполнении которого данные сохраняют заранее определенный вид и качество. Целостность данных - устойчивость хранимых данных к разрушению и уничтожению, связанным с неисправностями технических средств, системными ошибками и ошибочными действиями пользователей.

Целостность данных - точность и валидность данных. Целостность данных предполагает: отсутствие неточно введенных данных, защиту от ошибок при обновлении баз данных; невозможность удаления (или каскадное удаление) связанных данных разных таблиц; сохранность данных при сбоях техники (возможность восстановление данных) и др.

4 Фактографические ИС. Концептуальное моделирование, концептуальные средства описания, модель сущность-связь. Виды связей

Фактографическая информационно-поисковая система - информационно-поисковая система, обеспечивающая выдачу непосредственно фактических сведений, затребованных потребителем в информационном запросе. Поисковый массив фактографической ИПС состоит из описаний фактов, извлеченных из документов и представленных на некотором формальном языке.

В фотографических информационных системах регистрируются факты – конкретные значения данных об объектах реального мира, объектом может быть человек, предмет, событие о котором записаны данные. Объект – (единичная реализация сущности) – часть мира, выделяемое как единое целое в течение некоторого отрезка времени.

Концептуальное моделирование. Модель сущность-связь (концептуальная модель).

При проектирование ИС необходимо создать модель предметной области, которая должна основываться, исходя из анализа информационных потребностей будующих пользователей, эту стадию проектирования ИС принято называть концептуальным проектированием, а ее результат – концептуальной моделью предметной области. Наряду с понятием «концептуальная модель» используется термины: инфологическое проектирование и инфологическая модель. Инструментальные средства для определения концептуальной модели принято так же называть моделями данных, но при том подразумевается семантическое моделирование, которое представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструментов семантического моделирования используются:ER диаграммы или диаграммы сущность-связь..Сущность – это класс однотипных объектов, информация о которых должна быть учтена в модели. На диаграмме сущность изображается в виде прямоугольника, в верху – имя сущности, внизу – атрибуты. Сущность может иметь несколько ключевых атрибутов. Синоним сущности – ИО. Совокупность отношений между сущностями, имеющими место в некоторой предметной области называется - связь. При анализе связи могут встречаться, бинарные связи,унарная(вязь сущности сама с собой), тернарная и в общем случае n-арная.

В модели ERD связь представляется графической линией между соотносимыми объектами. Связь должна иметь имя, которое обычно выражается в неопределенной, глагольной форме(иметь, принадлежать, значиться).

Рассмотрим бинарные связи(1:1, 1:М, М:М). связь 1:1 – это такой тип связи между сущностями а и в, когда каждому экземпляру сущности а соответствует один и только один экземпляр сущности в, и наоборот. Идентификация экземпляров уникальна в обоих направлениях(номер зачетн книжки и номер паспорта) отношение 1:1 часто используется для разделения таблицы с большим количеством полей как правило, доя управления доступом к отдельным атрибутов таблицы различных пользователей. Для сокращения времени отклика при работе в сети, в которой одновременно работают несколько пользователей. Связь 1:М – с помощью связи 1:М определяется такой тип связи между сущностями а и в, когда одному экземпляру сущности а может соответствовать 0,1 или несколько экземпляров сущности в. Но каждому экземпляру сущности в может соответствовать один и только один экземпляр сущности а. Идентификация экземпляров при отношении 1:М уникальна только в направлении от в к а. Например: сотрудники 1:М дети. У каждого сотрудника может быть несколько детей, но у каждого ребенка родителем может быть только данный сотрудник. Левая сущность со стороны 1 наз-ся родительской, правая М –дочерней. Связь М:М - определяет такой тип связи между сущностями а и в, при котором каждому экземпляру сущности а может соответствовать 0, 1 или несколько экземпляров сущности в, и наоборот. Каждому экземпляру в может соответствовать 0,1 или несколько экземпляров а. например: Студент М:М дисциплина. Студент может изучать несколько дисциплин, но в тоже время одна и таже дисциплина может изучаться несколькими студентами. Идентификация экземпляров сущности не уникальна в обоих направлениях. Такой тип связи является допустимым на ранних разработках информационной модели. В дальнейшем этот тип связи должен быть заменен связями 1:М через промежуточную сущность. При разработки модели сущность-связь, так называемых ER моделей разработчик должен получить след информацию о предметной области: - список сущностей предметной области, - список атрибутов сущности, - описание взаимосвязей между сущностями. Рассмотренное ER моделирование, относиться к типу концептуальных ER диаграмм, это означает что ER диаграмма не учитывает особенность конкретных СУБД. По данной концептуальной диаграмме можно построить физическую диаграмму в которой будут учитываться особенности СУБД(допустимые типы, наименование полей, обеспечение цельности). Совокупность сущностей, свойств сущностей и отношений между ними называется концептуальной или информационно-логической моделью(инфологическая модель).Эта модель(концептуальная) представляет данные подлежащие хранению в базе данных в случае использования реляционных СУБД, каждая сущность из концептуальной модели адекватно отобразиться реляционной таблицей, атрибуты сущности – полями, таблицы и отношения между сущностями, существование в реальном мире логическими связями между ними. При построении базы данных, как основного хранилища данных информационной системы, концептуальная модель, созданная на этапе предпроектного обследования предметной области(как правило с использованием case system) является основой для построения основы базы данных

5. Программные средства реализации фактографических ИС. Понятие модели данных, основные компоненты модели. Виды моделей данных.

Модели данных. Основные компоненты модели.

Существует большое разнообразие сложных типов данных, но среди них можно определить несколько общих. Обобщенные структуры данных называют моделями данных. Модель данных – совокупность структур данных и операций их обработки, любая модель данных обязательно должна содержать 3 компонента: - структура данных – представление хранимых данных, используемых базой данных, - набор допустимых операций, выполняемых на структуре данных.Модель данных предполагает наличие языка определения данных(ЯОД), описывающего структуру и хранение, и языка манипулирования данными(ЯМД) служащего для операции извлечения и модифицирования данных, - ограничение целостности, это механизм поддержания соответствия данных предметной области на основе формально описанных правил.

Модель данных описывается следующим образом:􀂃 определяются типы и характеристики логических структур данных(полей, записей, файлов);􀂃 описываются правила составления структур более общего типа из

структур более простых типов;􀂃 описываются возможные действия над структурами и правила их

выполнения, включающие:− основные элементарные операции над данными;

− обобщенные операции (процедуры);− средства контроля относительно простых условий корректности ввода данных (ограничения);− средства контроля сколь угодно сложных условий корректности выполнения определенных действий (правила).В качестве основных элементарных операций обычно рассматриваются следующие: поиск записи с заданным значением ключа, чтение нужной записи, добавление записи, корректировка, удаление.

Виды моделей данных.

Excel позволяет создать только плоскую БД, т к отсутствует ограничение целостности. Ссылочная целостность – адекватность внешних ключевых значений ключа главной таблицы(главная табл – связываемая таблица). К числу важнейших из них относятся след модели данных: - иерархическая(примерно 1972), - сетевая(1973), - реляционная(1981), - объектно-ориентированная(90 е). В иерархической модели данные представляются в виде древовидной иерархической структуры. Эта структура удобна для работы с иерархически упорядоченной информацией и громоздко для информации со сложными логическими связями. Здесь существует ряд принципиальных особенностей.

1. Групповые отношения являются отношениями соподчиненности.

Группа (запись) – владелец отношения имеет подчиненные группы – члены отношений. Исходная группа называется предком, подчиненная – потомком.2. Групповые отношения образуют иерархическую структуру, которую можно описать как ориентированный граф следующего вида:− имеется единственная особая вершина (соответствующая

группе), называемая корнем, в которую не заходит ни одно ребро (группа не имеет предков);

− во все остальные вершины входит только одно ребро (все остальные группы имеют одного предка), а исходит произвольное количество ребер (группы имеют произвольное количество потомков);

− отсутствуют циклы. 3. Иерархическая модель данных может представлять совокупность нескольких деревьев. В терминологии иерархической модели деревья, описывающие структуру данных, называются деревьями описания данных, а сами структурированные данные (база данных) – деревьями данных. Особенностью реализации операций поиска в иерархической модели является то, что операция всегда начинает поиск с корневой вершины и специфицирует иерархический путь (последовательность связанных вершин) от корня до вершины, экземпляры которой удовлетворяют условиям поиска. Сетевая модель изначально представлена данными в виде произвольных графов. Более симметричным, чем иерархическая. Реализация групповых отношений в сетевой модели осуществляется с использованием указателей (адресов связи или ссылок), которые

устанавливают связь между владельцем и членом группового отношения. Однако, процедура управления данными значительно сложнее .Недостаток: высокая сложность и жесткость схемы БД построенной на ее основе. Иерархическая и сетевая БД называются БД с навигацией. Реляционная модель: при соблюдении определенных условий отношения представлены в виде двумерной таблицы. запись и файл. Структура записи определяет структуру таблицы, содержащей экземпляры соответствующей записи. Столбцы таблицы

представляют собой имена полей записи, строки таблицы – экземпляры записи. Таким образом, понятие «таблица» здесь соответствует понятию «файл» модели данных. Для формального описания таблицы используется теоретикомножественное понятие отношения. Список названий столбцов таблицы (имен полей записи, соответствующих атрибутам) именуют схемой отношения и обозначают R (A1, A2, …, An). Совокупность схем отношений, используемых для представления концептуальной модели, называется схемой реляционной базы данных, а текущие значения соответствующих отношений – реляционной базой данных. В качестве основного недостатка реляционной модели можно указать дублирование информации при представлении связей. Необходимо отметить, что большинство СУБД для персональных ЭВМ поддерживают именно реляционную модель данных. В качестве примеров таких наиболее распространенных СУБД можно указать Paradox, Access, Достоинства – простота, удобство организации на ПК и ЭВМ, наличие теоретического обоснования(математическое аппаратное множество, исчисление предикатов(логич выражений)) 1 и 2 –го порядка), возможность формирования гибкой схемы БД. Объектно-ориентированная БД. Объединяет в себе две БД- сетевую и реляционную. база данных, в которой данные оформлены в виде моделей объектов, включающих прикладные программы, которые управляются внешними событиями. Результатом совмещения возможностей (особенностей) баз данных и возможностей объектно-ориентированных языков программирования являются Объектно-ориентированные системы управления базами данных (ООСУБД). ООСУБД позволяет работать с объектами баз данных также, как с объектами в программировании на ООЯП. ООСУБД расширяет языки программирования, прозрачно вводя долговременные данные, управление параллелизмом, восстановление данных, ассоциированные запросы и другие возможности.Некоторые объектно-ориентированные базы данных разработаны для плотного взаимодействия с такими объектно-ориентированными языками программирования как Java, Visual Basic, C++. Объектно-ориентированные базы данных обычно рекомендованы для тех случаев, когда требуется высокопроизводительная обработка данных, имеющих сложную структуру.

5. Програмные средства реализации фактографических ИС. Общие понятия СУБД. Классификация СУБД. Функции СУБД.

Система управления БД представляет собой совокупность языковых и программных средств, предназначенных для создания, ведения использования БД.

Программные средства – комплексы программ, на определенном языке программирования, языковые – то, что содержит модель данных.

Общие понятия СУБД. Классификация СУБД

Система управления БД представляет собой совокупность языковых и программных средств, предназначенных для создания, ведения использования БД.

Программные средства – комплексы программ, на определенном языке программирования, языковые – то, что содержит модель данных.

Классификация СУБД:

1. По используемой модели данных

1.2 По характеру использования делятся на: Персональные – обеспечивают возможность создания персональных БД и недорогих приложений по необходимости работающих с сервером БД (в режиме файл-сервер) Помнить: файл-сервер - при посылке запроса от клиента к серверу, запрос тянется через сеть и на клиентской базе выполняется операция. Клиент-сервер – при посылке запроса на сервер там же идет его обработка. Примеры персональной СУБД: Visual FoxPro; Paradox; MS Accesses.

Многопользовательские – включают сервер БД и клиентскую часть. Могут работать в неоднородной вычислительной среде (допускаются различные типы ЭВМ и ПК и различные ОС), поэтому с помощью таких СУБД можно создать ИС, работающие по технологии клиент-сервер. Примеры: Oracle; Informix.

2. По архитектуре организации хранения данных

2.1 Локальные СУБД (все части локальной СУБД размещаются на одном компе)

2.2 Распределенные СУБД (части СУБД могут размещаться на двух и более компах)

3. По способу доступа к БД

3.1 Файл-сервер. В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. Ядро СУБД располагается на каждом клиентском компьютере. Доступ к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на ЦП сервера, а недостатком — высокая загрузка локальной сети. На данный момент файл-серверные СУБД считаются устаревшими.

Примеры: Microsoft Access, Borland Paradox.

3.2 Клиент-сервер. Такие СУБД состоят из клиентской части (которая входит в состав прикладной программы) и сервера (см. Клиент-сервер). Клиент-серверные СУБД, в отличие от файл-серверных, обеспечивают разграничение доступа между пользователями и мало загружают сеть и клиентские машины. Сервер является внешней по отношению к клиенту программой, и по надобности его можно заменить другим. Недостаток клиент-серверных СУБД в самом факте существования сервера (что плохо для локальных программ — в них удобнее встраиваемые СУБД) и больших вычислительных ресурсах, потребляемых сервером.

Примеры: Firebird, Interbase, IBM DB2, MS SQL Server, Sybase, Oracle, PostgreSQL, MySQL, ЛИНТЕР.

3.3 Встраиваемые. страиваемая СУБД — библиотека, которая позволяет унифицированным образом хранить большие объёмы данных на локальной машине. Доступ к данным может происходить через SQL либо через особые функции СУБД. Встраиваемые СУБД быстрее обычных клиент-серверных и не требуют установки сервера, поэтому востребованы в локальном ПО, которое имеет дело с большими объёмами данных (например, геоинформационные системы).

Примеры: OpenEdge, SQLite, BerkeleyDB, один из вариантов Firebird, один из вариантов MySQL, Sav Zigzag, Microsoft SQL Server Compact, ЛИНТЕР.

Общие понятия СУБД. Основные функции

Функции СУБД

1 Непосредственное управление данными во внешней памяти

2 Управление буферами оперативной памяти. Буфера оперативной памяти – это рабочие области памяти, в котором осуществляется подкачка данных СУБД для повышения скорости работы. Если при обращении к любому элементу данных будет производится обмен с внешней памятью, то вся система будет работать со скоростью этой памяти.

3 Управление Транзакцией. Транзакция – это последовательность операций над СУБД, рассматривая СУБД как единое целое. При выполнении транзакции она может быть либо успешно завершена (СУБД), либо ни одно из изменений не отразится в БД. Существуют две основные транзакции:

3.1 Фиксация транзакции – действие, обеспечивающее фиксацию на диск тех изменений в БД, которые были сделаны в процессе транзакции. До тех пор, пока транзакция не зафиксирована, возможно обнуление этих изменений.

3.2 Откат транзакции – действие, которое аннулирует все изменения при выполнении транзакции. Понятие транзакции необходимо для поддержания логической целостности БД.

4 Одно из основных требований СУБД – надежное хранение данных во внешней памяти. Под надежностью хранения понимают возможность СУБД к восстановлению последнего согласованного состояния БД после аппаратного или программного сбоя. Поддержание надежного хранения при избыточности хранения данных. Причем та часть данных, которая требуется для восстановления должна хранится особо надежно. Наиболее распространенный метод содержания такой информации – ведение журнала изменений БД. Журнал – это особая часть СУБД, не доступная пользователям, в которую поступают записи о всех изменениях основной части БД.

5. Программные средства реализации фактографических ИС. Архитектура СУБД, независимость данных, объекты моделирования, схемы СУБД.

Система управления БД представляет собой совокупность языковых и программных средств, предназначенных для создания, ведения использования БД.

Программные средства – комплексы программ, на определенном языке программирования, языковые – то, что содержит модель данных.

Архитектура СУБД. Независимость данных

В системе должны поддерживаться раздельные представления данных – для пользователя логическое представление и для системы механизмов среды хранения физическое.

Физическая независимость данных – с точки зрения пользователя, представление данных в БД абсолютно не зависит от их физического хранения, т.е. физическое перемещение данных никак не может повлиять на логическую структуру.

Логическая независимость данных – означает независимость прикладных программ от данных, определенных на логическом уровне. Любые изменения логической схемы не требуют коррекции этих программ.

В соответствии с этим подходом различают логический (внешний) и физический (внутренний) уровни. В 1975г. Был опубликован стандарт ANSI/X3/SPARC, по которому создан третий концептуальный уровень, независимый от первых двух. Трехуровневая архитектура позволяет обеспечить независимость хранимых данных от использующих их программ.

Внешний (логический уровень) должен обеспечивать поддержку представления хранения БД с точки зрения прикладных программ и пользователей

Концептуальный уровень представляет информационно логическую модель в терминах (технология описания) конкретных СУБД. На концептуальном уровне на основе предметной области создается концептуальная модель, которая представляет объекты и взаимосвязи предметной области без указания способа их физического хранения.

Внутренний (физический уровень) должен обеспечивать поддержку хранимой БД

На каждом уровне используется своя модель и схема данных. На внешнем уровне таких моделей может быть несколько. Физическая модель описывает способы физической реализации логической модели данных. На этом уровне хранится след. информация: сведения о распределении дискового пространства для хранения данных и индексов; описание и подробности сохранения записей; сведения о размещении записей; сведения о сжатии данных и методов, выбранных для их шифрования.

. Обобщенная архитектура СУБД.

СУБД управляет оперативной памятью, в которой располагаются буфера с данными, буфера журналов, данные системного каталога, которые необходимы для поддержки целостности и проверки привилегий пользователей. Кроме того, в оперативной памяти во время работы СУБД располагается информация, которая соответствует текущему состоянию обработки запросов, там хранятся планы выполнения скомпилированных запросов и т. д.

По версии ANSI/X3/SPARC

Концептуальная модель описывает все элементы данных и связи между ними с указанием поддержки между ними и необходимости ограничений. Для каждой БД существует только 1 концептуальная схема. Внутренняя схема явл. полным описанием внутренней модели данных (описание индексов, полей данных). Внешняя схема отображает пользовательское представление на соответствующую часть концептуальной модели.

8 типы моделей данных. Сетевая и иерархическая модели данных. Представление данных, операции над данными, ограничения целостности

Виды моделей данных.

Excel позволяет создать только плоскую БД, т к отсутствует ограничение целостности. Ссылочная целостность – адекватность внешних ключевых значений ключа главной таблицы(главная табл – связываемая таблица). К числу важнейших из них относятся след модели данных: - иерархическая(примерно 1972), - сетевая(1973), - реляционная(1981), - объектно-ориентированная(90 е). В иерархической модели данные представляются в виде древовидной иерархической структуры. Эта структура удобна для работы с иерархически упорядоченной информацией и громоздко для информации со сложными логическими связями. Здесь существует ряд принципиальных особенностей.

1. Групповые отношения являются отношениями соподчиненности.

Группа (запись) – владелец отношения имеет подчиненные группы – члены отношений. Исходная группа называется предком, подчиненная – потомком.2. Групповые отношения образуют иерархическую структуру, которую можно описать как ориентированный граф следующего вида:− имеется единственная особая вершина (соответствующая

группе), называемая корнем, в которую не заходит ни одно ребро (группа не имеет предков);

− во все остальные вершины входит только одно ребро (все остальные группы имеют одного предка), а исходит произвольное количество ребер (группы имеют произвольное количество потомков);

− отсутствуют циклы. 3. Иерархическая модель данных может представлять совокупность нескольких деревьев. В терминологии иерархической модели деревья, описывающие структуру данных, называются деревьями описания данных, а сами структурированные данные (база данных) – деревьями данных. Особенностью реализации операций поиска в иерархической модели является то, что операция всегда начинает поиск с корневой вершины и специфицирует иерархический путь (последовательность связанных вершин) от корня до вершины, экземпляры которой удовлетворяют условиям поиска. Сетевая модель изначально представлена данными в виде произвольных графов. Более симметричным, чем иерархическая. Реализация групповых отношений в сетевой модели осуществляется с использованием указателей (адресов связи или ссылок), которые

устанавливают связь между владельцем и членом группового отношения. Однако, процедура управления данными значительно сложнее .Недостаток: высокая сложность и жесткость схемы БД построенной на ее основе. Иерархическая и сетевая БД называются БД с навигацией. Объектно-ориентированная БД. Объединяет в себе две БД- сетевую и реляционную. база данных, в которой данные оформлены в виде моделей объектов, включающих прикладные программы, которые управляются внешними событиями. Результатом совмещения возможностей (особенностей) баз данных и возможностей объектно-ориентированных языков программирования являются Объектно-ориентированные системы управления базами данных (ООСУБД). ООСУБД позволяет работать с объектами баз данных также, как с объектами в программировании на ООЯП. ООСУБД расширяет языки программирования, прозрачно вводя долговременные данные, управление параллелизмом, восстановление данных, ассоциированные запросы и другие возможности.Некоторые объектно-ориентированные базы данных разработаны для плотного взаимодействия с такими объектно-ориентированными языками программирования как Java, Visual Basic, C++. Объектно-ориентированные базы данных обычно рекомендованы для тех случаев, когда требуется высокопроизводительная обработка данных, имеющих сложную структуру.

9. Реляционная модель данных. Понятие отношения. Мощность и кардинальное число отношения. Домен отношения. Схемы отношения. Общие свойства отношенйи. Объектнл-связанная модель.

Реляционная модель: при соблюдении определенных условий отношения представлены в виде двумерной таблицы. запись и файл. Структура записи определяет структуру таблицы, содержащей экземпляры соответствующей записи. Столбцы таблицы

представляют собой имена полей записи, строки таблицы – экземпляры записи. Таким образом, понятие «таблица» здесь соответствует понятию «файл» модели данных. Для формального описания таблицы используется теоретикомножественное понятие отношения. Список названий столбцов таблицы (имен полей записи, соответствующих атрибутам) именуют схемой отношения и обозначают R (A1, A2, …, An). Совокупность схем отношений, используемых для представления концептуальной модели, называется схемой реляционной базы данных, а текущие значения соответствующих отношений – реляционной базой данных. В качестве основного недостатка реляционной модели можно указать дублирование информации при представлении связей. Необходимо отметить, что большинство СУБД для персональных ЭВМ поддерживают именно реляционную модель данных. В качестве примеров таких наиболее распространенных СУБД можно указать Paradox, Access, Достоинства – простота, удобство организации на ПК и ЭВМ, наличие теоретического обоснования(математическое аппаратное множество, исчисление предикатов(логич выражений)) 1 и 2 –го порядка), возможность формирования гибкой схемы БД.

организация процессов обработки данных в БД. Понятие реляционной модели.

Организация процессов обработки данных целиком определяется правилами и ограничениями, накладываемые той СУБД, в которой создается база данных.

Модель данных – совокупность структур данных и операций их обработки, любая модель данных обязательно должна содержать 3 компонента: - структура данных – представление хранимых данных, используемых базой данных, - набор допустимых операций, выполняемых на структуре данных.

Реляционная модель – способ рассмотрения данных, который связан с 3-мя аспектами данных: структурная часть (объекты данных), структурная часть описывает, какие объекты рассматриваются реляционной моделью. Утверждается, что единственной структурой данных используемых в реляционной модели являются нормолизированные n-парные отношения. Манипуляционная часть - в ней утверждаются два фундаментальных механизма манипулирования реляционными БД: реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств. Второй на классическом, логическом аппарате исчисления предикатов (высказываний,выражений) первого порядка .Целостная часть – в целостной части реляционной модели данных фиксируется два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД: - целостность сущности (Сущность – любой конкретный или абстрактный объект в рассматриваемой предметной области)( целостности сущностей – каждое отношение должно описывать экземпляры только одной сущности и обладать первичным ключом. Другими словами, отношения должны быть нормализованы и в их физических реализациях (таблицах) не должно быть одинаковых записей)

– целостность внешних ключей(Внешние ключи не должны быть несогласованными, т.е. для каждого значения внешнего ключа должно существовать соответствующее значение первичного ключа в родительском отношении.)

организация процессов обработки данных в БД. Понятие отношения. Мощность и кардинальное число отношения.

Понятие отношения – основывается на понятии декартового произведения. Пусть D1,D2 и Dn – произвольные конечные множества и необязательно различные. Декартовым произведение этих множеств D1*D2…*Dn называется множество произведений(кортежей) вида <d1d2…dn> где d1 – элемент множества D1, d2 – элемент множества D2 и т.д.

Отношением R определенное нам множества D1,D2…Dn называется подмножество декартового произведения D1,D2…Dn, при этом множество D1,D2…Dn называется доменами отношения, а элементы декартового произведения <d1,d2…dn> - кортежами.

Данное отношение(см. рисунок) является отражением некоторой сущности реального мира(сущность-детали), а с точки зрения обработки данных представляет собой таблицу.

Количество всех кортежей в отно­шении определяет его мощность, или кардинальное число. Мощность множества кортежей отношения называют мощностью отношения. Мощность множества или кардинальное число множества — это обобщение понятия количества (числа) элементов множества, которое имеет смысл для всех множеств, включая бесконечные.

организация процессов обработки данных в БД. Схемы отношений.

Отношение обычно записывается в виде R (<A1:D1>,<A2:D2>) или R(A1,A2,…An) без указания доменов. Список имен атрибутов называется схемой отношений. Совокупность схемы отношении используемых для представления информации называется схемой реляционной БД, а текущее значение соответствующих отношений –реляционной БД (Реляционная база данных - база данных, построенная на основе реляционной модели. В реляционной базе каждый объект задается записью (строкой) в таблице. ). Схему реляционной БД можно представить в виде совокупности схем отношений :

R1(A11…A1n)

R2(A21…A2n)

Rm(Am1…Amn)

Два отношения называются односхемными если они построены по одной схеме.

организация процессов обработки данных в БД. Заголовок и тело отношения. Домен отношения.

Отношение R определенное на множестве D1,D2…Dn содержит две части: заголовок и тело(если представить отношение как таблицу, заголовок – строка заголовков столбцов, а тело- множество строк данных).

Заголовок состоит из такого фиксированного множества атрибутов A1,A2…An, что существует взаимнооднозначное соответствие между этими атрибутами и определяющими их доменами, причем каждый атрибут соответствует одному и только одному из лежащих в основе доменов {<A1:D1>,<A2:D2>…<An:Dn>} все имена атрибутов A1,A2…An, разные .

Тело отношения состоит из изменяющегося во времени множества кортежей, где каждый кортеж состоит в свою очередь из множества пар {имя атрибута:значение атрибута}.

Количество атрибутов в данном отношении называется степенью(иногда арностью) отношения. Отношение первой степени – унанрное, второй-бинарное, третьей – тернарное… n – n арное.

Исходя из математического описания отношения можно сделать след выводы: 1 Заголовок отношения описывает декартовое произведение доменов на котором задано отношение. Заголовок статичен, он не меняется во время работы с Бд: если в отношении изменены, добавлены или удалены атрибуты, то в результате получим другое отношение пусть даже с преждним именем.

2 тело отношения представляет собой набор кортежей, т.е подмножество декартовых произведений домена. Таким образом тело отношения и является отношением в математическом смысле слова. Тело отношения может изменяться во время работы с БД. Картежи могут изменяться, добавляться и удаляться. Массив, представляющий n-арное отношение обладает след свойствами: - каждая строка представляет собой кортеж степени n, - порядок строк не является существенным, - все строки различны, - порядок столбцов является существенным, он соответствует порядку D1,D2…Dn доменов на котором определяется отношение R.

Домен - семантическое понятие. По-скольку каждый атрибут определен на домен, то домен можно рассматривать как множество допустимых значений атрибута. Домен характеризуется следующими свойствами: - имеет уникальное имя(в пределах конкретной БД) – домен определен на некотором простом типе данных или на другом домене.

Простые или атомарные типы данных не обладают внутренней структурой. Данные такого типа называются скалярными, к ним относятся логические (true, false), строковые(«А», «АВ»…), числовые( byte, Long, integer)

Неатомарные значения это значения, которые имеют в своем составе некоторым образом структурные значения(связанные списки, вложенные отношения).

организация процессов обработки данных в БД. Общие свойства отношений.

1 отношение рассматриваемое как файл. Отношение можно рассматривать, как абстрактное представление файла, который состоит из последовательных записей, по одной на каждый кортеж, причем одинаковые записи запрещаются, все записи должны быть одного и того же типа у них должно быть одно и тоже количество полей, причем в соответствующих полях различных записях должна храниться информация одного и того же типа.

Таким образом получаем ледующие соответствие: отношение-файл

Свойства отношения : 1 Кортеж – запись в файле. Имя атрибута – имя поля, - имя домена – тип поля 2 в отношении нет одинаковых кортежей Поскольку тело отношения есть множество кортежей, то как всякое множество не может содержать неразличимых элементов. 3 ключи отношения и целостность данных. Ключевым полем называется поле, содержащие уникальное значение по которому соответствует запись может быть идентифицирована. Понятие ключевых полей обеспечивает запрет на совпадение.

Первичный ключ – атрибут или группа атрибутов(составной ключ, однозначно идентифицирующих каждый кортеж отношений). Вместе с понятием первичного ключа реляционная модель включает в себя правило целостности объекта, состоящее из следующих ограничений: - ни один элемент первичного ключа базового отношения не может быть null значения – кортежи базовых отношений соответствуют реальным объектам реального мира.По скольку эти объекты различимы, т.е распознаваемы, поэтому соответствующие представление объектов так же должны быть распознаваемы.

Внешним ключом отношения R2 называется атрибут или группа атрибутов, значения которых является значением первичного ключа некоторого отношения R1. Св-ва внешнего ключа: - внешний ключ будет составным тогда и только тогда, когда составным будет первичный ключ базового отношения – Каждый атрибут входящий в внешний ключ должен быть определен на том же домене что и соответствующий атрибут первичного ключа.

Ограничение, согласно которому значение данного внешнего ключа должны быть адекватны значениям соответствующих первичных ключей называют ссылочным ограничением или ссылочной целостностью. Целостность данных – свойство по которому каждая запись идентифицируется. (Складывается из целостность первичных ключей и ссылочной целостности). Первичный ключ - это столбец или группа столбцов, однозначно определяющие запись.

4 Атомарность значений атрибутов. Значения всех атрибутов должны быть атомарны(т.е не содержать других отношений). Принято говорить, что в реляционной Бд допускаются только нормализованные отношения или отношения, представленные в первой нормальной форме. Отношением, находящимся в первой нормальной форме называется отношение, каждый домен которого содержит только атомарные значения и поэтому каждое значение в этих отношениях так же является атомарным.

5 нормализованные отношения представляются в виде табличной структуры

9. Организация процессов обработки данных. Операции обработки кортежей. Операции обработки отношений.

организация процессов обработки данных в БД. Операции над данными. Операции обработки кортежей.

Операции обработки кортежей, все эти операции связаны с изменением состава кортежа в каком-либо отношении. 1 –добавить(add new) необходимо задание имени отношения и предварительного формирования значения атрибутов нового кортежа. Обязательно должен быть добавлен ключ кортежа. Операция не будет выполнена, если ключ имеет не уникальное значение. 2 – удалить – необходимо удалить имя отношения, а так же кортеж или группу кортежей подлежащих удалению. 3 – изменить (update) – выполняется для именованного отношения и может корректировать как один так и несколько кортежей.

Операции обработки отношений – отличительной особенностью этих операций является то, что единицей обработки в них является не кортежи, а отношения на входе такой операции используется одно или несколько отношений фиксированной арности. Результатом выполнения операции всегда является новое отношение

Операции объединения и пересечения отношений.

Традиционно определяют 8 реляционных операторов, определяемых в 2 группы : 1 – теоретико-множественные операторы –1.1 ОБЪЕДИНЕНИЯ - возвращает отношения, содержащие все кортежи, которые принадлежат или одному из 2-х определяющих отношений или обоим. С1=AUB эта операция предполагает что на входе задано два односхемных отношения, есть построенное по той же схеме отношение С1 содержащее все кортежи отношения А и все кортежи отношения В. В СУБД для объединения таблиц существует запрос на объединение Sql оператор - Union. 1.2 Операция пересечения С2=А пересекает В С2-результат пересечения Аи В. Эта операция предполагает что на входе заданы два односхемных отношения А и В. На выходе построено отношение С2, содержащее только те кортежи отношения А, которые есть в отношении В.

1.3 Операция вычитания. С3=А-В. Результирующее отношение С3, включает в себя только те кортежи отношения А, которых нет в отношение В.

1.4 Декатово произведение C4=АхВ Важным отличием этой операции является то что отношения А и В могут быть построены по разным схемам, а схема отношения С4 включает в себя все атрибуты А и В. Пусть имеются отношения А и В арность К1 и к2 соответственно, тогда дакартовым произведением отношений А и В, называется множество кортежей длинны К1+К2, где первые К1 компоненты образуют кортежи отношения А, а последние К2 компоненты образуют кортежи отношения В.

2 Специальные реляционные операторы. 2.1 Выборка – возвращает отношения, содержащие все кортежи определенного отношения, которые удовлетворяют определенным условиям. Операция выборка(горизонтальное подмножество) первоначально называлось операция ограничения. На входе используется одно отношение. Результат- новое отношение, построенное по той же схеме, содержащее подмножество кортежей исходного отношения, удовлетворяющих условию выборки.

2.2 Оператор проекции – возвращает отношение, содержащее все кортежи(называемое как подкортежи), определенного отношения после исключения из него некоторых атрибутов. Операция проекция(вертикальное подмножество) на входе операции устанавливается одно отношение, результирующее отношение включает подмножество атрибутов исходного отношения. Каждому кортежу исходного отношения соответствует такой кортеж в результирующем отношении, что значения одинаковых атрибутов этих совпадают, но при этом кортежи – дубликаты устраняются. В связи с чем мощность результирующего отношения может быть меньше мощности исходного.

11 Организация процессов обработки данных. Функциональная зависимость в отношениях. Нормализация отношений.

Функциональная зависимость в отношениях.

Функциональная зависимость - форма устойчивой взаимосвязи между объективными явлениями или отражающими их величинами, при к-рой изменение одних явлений вызывает определенное количественное изменение др. Объективно Ф. з. проявляется в виде законов и отношений, обладающих точной количественной определенностью.

Функциональная зависимость в отношении, реляционная Бд содержит как структурированную так и семантическую информацию. Структурированная информация определяется числом и видом включенных в нее отношений, семантическая описывает множество функциональных зависимостей, существующих между атрибутами отношений объявленных в схеме Бд. Пример: рассмотрим зависимость в отношении студент между атрибутом N зачетной книжки и ФИО студента. Предполагается что одно значение атрибута N зачетной книжки определяет одно значение ФИО студента. Данное свойство справедливо для всех значений отношения и выражается след образом N зачет – ФИО. И означает функциональную зависимость ФИО студента от номера зачетной книжки.

Если задано некоторое отношение R, то говориться что атрибут Y отношения R, функционально зависит от атрибута Х отношения R, тогда и только тогда, когда каждое значение Х в отношение R в каждый момент времени связано только с одним значением Y.

Замечание: одно и тоже значение Х может появиться в нескольких кортежах отношения R, поскольку Y зависимо от Х, то по определению каждый из кортежей содержит одно и тоже значение Y. Атрибут Х стоящий слева от стрелки обозначает функциональную зависимость, называется - детерминантом, а атрибут Y - зависимой частью. Обoзначение X≠Y показывает, что между Х и Y нет функциональной зависимости. Если Х определяет Y(Х→Y), а Y определяет Х(Y→X), то между Х и Y существует взаимно-однозначные отношения.

Функциональная зависимость атрибута отношения напоминает понятие функциональной зависимости в математике. У=f(x), где f – правило, по которому каждому элементу Х ставиться в соответствие элемент Y. В отношении, в качестве области определения выступает домен на котором определен атрибут Х. В качестве В выступает множество значений Y. Правило f реализуется след алгоритмом. По данному значению атрибута Х, найти любой кортеж отношения содержащий это значение. Значение атрибута Y в этом кортеже и будет кортежем функциональной зависимости. Отличие состоит в том что для фиксированного значения Х в математ значении, Y всегда одно и тоже. У=f(х)=х^2=4

В случае отношения значения зависимого атрибута может принимать различные значения в различных состояниях(1-смирнова-иванова – при смене фамилии).

Таким образом понятие функциональная зависимость атрибута нельзя считать полностью эквивалентным математическим понятием функциональной зависимости. Функциональная зависимость атрибута утверждает лишь то, что для каждого конкретного состояния БД по значении. Одного атрибута(детерминанта) можно однозначно определить значение другого атрибута(зависимой части). Но конкретные значения зависимой части могут быть различны в различных состояниях БД.

Нормализация отношений. 1НФ.

Поскольку функциональная зависимость определяет семантическую информацию отношений, иногда могут возникнуть ситуации, когда они не желательны из-за побочных эффектов или аномалий, которые они вызывают при модификации БД. В связи с этим возникает вопрос о корректности представленной схемы. Конкретной считается схема в которой отсутствуют нежелательные функциональные зависимости, в противном случае приходиться прибегать к декомпозиции с разложением отношений, при которой данное множество отношений заменяется другим множеством(число их возрастает) является проекциями первых. Цель этой процедуры – устранить нежелательные функциональные зависимости, а следовательно аномалии, что составляет суть процесса нормализации). Нормализация – пошаговый обратимый процесс замены данной схемы другой схемой, в которых отношения имеют простую и регулярную структуру.

Под нормализацией отношения подразумевается процесс приведения отношения к одной из так называемых нормальных форм. Итак, что же представляет собой процесс нормализации? Фактически это не что иное, как последовательное преобразование исходной БД к НФ, при этом каждая следующая НФ обязательно включает в себя предыдущую (что, собственно, и позволяет разбить процесс на этапы и производить его однократно, не возвращаясь к предыдущим этапам).

Приведение структуры БД в соответствие этим ограничениям - это и есть нормализация. В целом суть этих ограничений весьма проста: каждый факт, хранимый в БД, должен храниться один-единственный раз, поскольку дублирование может привести (и на практике непременно приводит, как только проект приобретает реальную сложность) к несогласованности между копиями одной и той же информации. Следует избегать любых неоднозначностей, а также избыточности хранимой информации.

Говорят, что модель данных находится в первой нормальной форме (1NF) тогда и только тогда, когда каждый атрибут каждого экземпляра сущности (т.е. каждая клетка таблицы) всегда содержит только элементарные значения. Если атрибут можно логично разделить на несколько – следует это сделать; после этого БД будет находиться в первой нормальной форме.

Нормализация отношений. 2НФ.

Таблица находится во второй нормальной форме, если она находится в первой нормальной форме, и при этом любой её атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего первичного составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов(частей). Или другими словами: в 2NF нет неключевых атрибутов, зависящих от части составного ключа (+ выполняются условия 1NF).

Нормализация отношений. 3НФ.

Согласно определению Кодда, таблица находится в 3НФ тогда и только тогда, когда выполняются следующие условия:

• Отношение R (таблица) находится во второй нормальной форме;

• Каждый непервичный атрибут R находится в нетранзитивной (то есть прямой) зависимости от каждого ключа R.

Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых. Транзитивной зависимостью неключевых атрибутов от ключевых называется следующая: A → B и B → C, где A - набор ключевых атрибутов (ключ), B и С - различные множества неключевых атрибутов.

При решении практических задач в большинстве случаев третья нормальная форма является достаточной. Процесс проектирования реляционной базы данных, как правило, заканчивается приведением к 3NF.

Отношение находится в третьей нормальной форме (3НФ), если оно находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Допустимо использовать альтернативное определение. Отношение находится в 3НФ тогда и только тогда, когда все неключевые атрибуты отношения взаимно независимы и функционально полно зависят от первичного ключа.

12. Проектирование ИС. Понятие и структура проекта ИС. Требования к эффективности и надежности проектных решений.

ИНФ.СИСТ. – представляет собой систему, реализующую автоматизированный сбор, обработку и манипулирование данными и включающие технические средства обработки данных, программное обеспечение и обслуживающий персонал. Информационные системы предназначена для хранения, обработки, поиска, распространения, передачи и предоставления информации.

Проектирование ИС охватывает три основные области:

• проектирование объектов данных, которые будут реализованы в базе данных;

• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

• учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

Проектирование информационных систем всегда начинается с определения цели проекта. В общем виде цель проекта можно определить как решение ряда взаимосвязанных задач, включающих в себя обеспечение на момент запуска системы и в течение всего времени ее эксплуатации:

• требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;

• требуемой пропускной способности системы;

• требуемого времени реакции системы на запрос;

• безотказной работы системы;

• необходимого уровня безопасности;

• простоты эксплуатации и поддержки системы.

Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются специфичные для него модели - организации, требований к ИС, проекта ИС, требований к приложениям и т.д. Модели формируются рабочими группами команды проекта, сохраняются и накапливаются в репозитории проекта. Создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - CASE-средств.

Процесс создания ИС делится на ряд этапов (стадий [1]), ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).

Обычно выделяют следующие этапы создания ИС: формирование требований к системе, проектирование, реализация, тестирование, ввод в действие, эксплуатация и сопровождение.

Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.

Целью начальных этапов создания ИС, выполняемых на стадии анализа деятельности организации, является формирование требований к ИС, корректно и точно отражающих цели и задачи организации-заказчика. Чтобы специфицировать процесс создания ИС, отвечающей потребностям организации, нужно выяснить и четко сформулировать, в чем заключаются эти потребности. Для этого необходимо определить требования заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации.

Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Современные инструментальные средства и программные продукты позволяют достаточно быстро создавать ИС по готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков, требуют многочисленных доработок, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС на этапе анализа.

На этапе проектирования прежде всего формируются модели данных. Проектировщики в качестве исходной информации получают результаты анализа. Построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных.

Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Главная цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. При проектировании модулей определяют интерфейсы программ: разметку меню, вид окон, горячие клавиши и связанные с ними вызовы.

Конечными продуктами этапа проектирования являются:

• схема базы данных (на основании ER-модели, разработанной на этапе анализа);

• набор спецификаций модулей системы (они строятся на базе моделей функций).

Кроме того, на этапе проектирования осуществляется также разработка архитектуры ИС, включающая в себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем. Кроме выбора платформы, на этапе проектирования определяются следующие характеристики архитектуры:

• будет ли это архитектура "файл-сервер" или "клиент-сервер";

• будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;

• будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;

• будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);

• будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

Этап проектирования завершается разработкой технического проекта ИС.

На этапе реализации осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации.

Этап тестирования обычно оказывается распределенным во времени.

После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели:

• обнаружение отказов модуля (жестких сбоев);

• соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).

После того как автономный тест успешно пройден, модуль включается в состав разработанной части системы и группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние.

Далее группа модулей тестируется на надежность работы, то есть проходят, во-первых, тесты имитации отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую нагрузку на систему.

Затем весь комплект модулей проходит системный тест - тест внутренней приемки продукта, показывающий уровень его качества. Сюда входят тесты функциональности и тесты надежности системы.

Последний тест информационной системы - приемо-сдаточные испытания. Такой тест предусматривает показ информационной системы заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика.

Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентированного моделирования, CASE-систем.

13 Основные компоненты технологии проектирования ИС. Методы и средства проектирования ИС. Краткая характеристика применяемых технологий проектирования. Требования, предъявляемые к технологии проектирования ИС. Выбор технологии проетирования ИС.

ИНФ.СИСТ. – представляет собой систему, реализующую автоматизированный сбор, обработку и манипулирование данными и включающие технические средства обработки данных, программное обеспечение и обслуживающий персонал. Информационные системы предназначена для хранения, обработки, поиска, распространения, передачи и предоставления информации.

Проектирование ИС охватывает три основные области:

• проектирование объектов данных, которые будут реализованы в базе данных;

• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

• учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

Проектирование информационных систем всегда начинается с определения цели проекта. В общем виде цель проекта можно определить как решение ряда взаимосвязанных задач, включающих в себя обеспечение на момент запуска системы и в течение всего времени ее эксплуатации:

• требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;

• требуемой пропускной способности системы;

• требуемого времени реакции системы на запрос;

• безотказной работы системы;

• необходимого уровня безопасности;

• простоты эксплуатации и поддержки системы.

Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются специфичные для него модели - организации, требований к ИС, проекта ИС, требований к приложениям и т.д. Модели формируются рабочими группами команды проекта, сохраняются и накапливаются в репозитории проекта. Создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - CASE-средств.

Процесс создания ИС делится на ряд этапов (стадий [1]), ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).

Обычно выделяют следующие этапы создания ИС: формирование требований к системе, проектирование, реализация, тестирование, ввод в действие, эксплуатация и сопровождение. Каждый этап характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. В общем случае стратегия выбора Средств Проектирования для конкретного применения зависит от следующих факторов:

• характеристик моделируемой предметной области;

• целей, потребностей и ограничений будущего проекта ИС, включая квалификацию участвующих в процессе проектирования специалистов;

• используемой методологии проектирования.

Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности ИС, создаваемых в различных областях экономики. Современные сложные ИС и проекты, обеспечивающие их создание, характеризуются, как правило, следующими особенностями:

• сложность предметной области (достаточно большое количество функций, объектов, атрибутов и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов;

• наличие совокупности тесно взаимодействующих компонентов - подсистем, имеющих свои локальные задачи и цели функционирования;

• иерархическую структуру взаимосвязей компонентов, обеспечивающую устойчивость функционирования системы;

• иерархическую совокупность критериев качества функционирования компонентов и ИС в целом, обеспечивающих достижение главной цели - создания и последующего применения системы;

• отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем;

• необходимость достаточно длительного сосуществования старых приложений и вновь разрабатываемых БД и приложений;

• наличие потребности как в традиционных приложениях, связанных с обработкой транзакций и решением регламентных задач, так и в приложениях аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема;

• поддержка одновременной работы достаточно большого количества локальных сетей, связываемых в глобальную сеть масштаба предприятия, и территориально удаленных пользователей;

• функционирование в неоднородной операционной среде на нескольких вычислительных платформах;

• разобщенность и разнородность отдельных микроколлективов разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;

• существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.

Методология проектирования определяется как совокупность трех составляющих:

• пошаговой процедуры, определяющей последовательность технологических операций проектирования;

• критериев и правил, используемых для оценки результатов выполнения технологических операций;

• нотаций (графических и текстовых средств), используемых для описания проектируемой системы.

На выбор СП могут существенно повлиять следующие особенности методологии проектирования:

• ориентация на создание уникального или типового проекта;

• итерационный характер процесса проектирования;

• возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей;

• жесткая дисциплина проектирования и разработки при их коллективном характере;

• необходимость отчуждения проекта от разработчиков и его последующего централизованного сопровождения.

Критерии выбора

Традиционно при обсуждении проблемы выбора СП (в особенности CASE-средств) большое внимание уделялось особенностям реализации той или иной методологии анализа предметной области (E-R, IDEF0, IDEF1Х, Gane/Sarson, Yordon, Barker и др.). Безусловно, богатство изобразительных и описательных средств дает возможность на этапах стратегического планирования и анализа построить наиболее полную и адекватную модель предметной области. С другой стороны, если говорить о конечных результатах - базах данных и приложениях, то обнаруживается, что часть описаний в них практически не отражается, оставаясь чисто декларативной (на выходе мы в любом случае получим описание БД в табличном представлении с минимальным набором ограничений целостности и исполнимый код приложений, большую часть которых составляют экранные формы, не выводимые непосредственно из моделей предметной области). Опытные аналитики и проектировщики всегда с большими или меньшими трудозатратами придут к нужному конечному результату независимо от того, какая конкретно методология или ее разновидность реализована в данном инструменте. Это, конечно, не означает, что методология не важна, напротив, отсутствие или неполнота описательных средств могут с самого начала значительно затруднить работу над проектом. Однако, зачастую на первом плане оказываются другие критерии, невыполнение которых может породить гораздо большие трудности. Может создаться впечатление, что если можно сформировать необходимую аппаратную платформу из компонентов различных фирм-производителей, то так же просто можно выбрать и скомплексировать разные инструментальные средства, каждое из которых является одним из мировых лидеров в своем классе. Однако в случае инструментальных средств в настоящее время, в отличие от оборудования, отсутствуют международные стандарты на основные свойства конечных продуктов (программ, баз данных и их сопряжение). Однако, поскольку составные части проекта должны быть интегрированы в единый продукт, следовательно, имеет смысл рассматривать не любые, а только сопряженные инструментальные средства, которые в принципе могут быть ориентированы - даже внутри одного класса - на разные методологии; при этом необходимо отбирать в состав комплекса СП средства, поддерживающие по крайней мере близкие методологии, если не одну и ту же. Исходя из перечисленных выше соображений, примем в качестве основных критериев выбора СП следующие критерии:

Поддержка полного жизненного цикла ИС с обеспечением эволюционности ее развития. Полный жизненный цикл ИС должен поддерживаться "сквозной" технологической цепочкой средств разработчика, обеспечивающей решение следующих задач:

• обследование и получения формализованных знаний о предметной области (последовательный и логически связный переход от формализованного описания предметной области к ее моделям);

• декомпозиция проекта на составные части и интеграция составных частей;

• проектирование моделей приложений (логики приложений и пользовательских интерфейсов);

• прототипирование приложений;

• проектирование баз данных;

• коллективная, территориально распределенная разработка приложений с использованием различных инструментальных средств (включая их интеграцию, тестирование и отладку);

• разработка распределенных баз данных (с выбором оптимальных вариантов распределения);

• разработка проектной документации с учетом требований проектных стандартов;

• адаптация к различным системно-техническим платформам и СУБД;

• тестирование и испытания;

• сопровождение, внесение изменений и управление версиями и конфигурацией ИС;

• интеграция с существующими разработками (включая реинжиниринг приложений, конвертирование БД);

• администрирование ИС (оптимизация эксплуатационных характеристик);

• управление разработкой и сопровождением ИС (планирование, координация и контроль за ресурсами и ходом выполнения работ);

• прогнозирование и оценка трудоемкости, сроков и стоимости разработки.

Для существующих ИС должен обеспечиваться плавный переход из старой среды эксплуатации в новую с минимальными переделками и поддержкой эксплуатируемых баз данных и приложений, внедренных до начала работ по созданию новой системы.

Обеспечение целостности проекта и контроля за его состоянием. Данное требование означает наличие единой технологической среды создания, сопровождения и развития ИС, а также целостность базы проектных данных (репозитория). Единая технологическая среда должна обеспечиваться за счет использования единственной CASE-системы для поддержки моделей ИС, а также за счет наличия программно-технологических интерфейсов между отдельными инструментальными средствами, сертифицированных и поддерживаемых фирмами- разработчиками соответствующих средств. В частности, интерфейс между CASE-системой и средствами разработки приложений должен выполнять две основные функции: а) непосредственный переход в рамках единой среды от описания логики приложения, реализованного CASE-системой, к разработке пользовательского интерфейса (экранных форм); б) перенос описания БД из репозитория CASE-системы в репозиторий средства разработки приложений и обратно. Вся информация о проекте должна автоматически помещаться в базу проектных данных, при этом должны поддерживаться согласованность, непротиворечивость, полнота и минимальная избыточность проекта, а также корректность операций его редактирования. Это может быть достигнуто при условии исключения или существенного ограничения возможности актуализации репозитория различными средствами. Должны также обеспечиваться возможности для централизованного сбора, хранения и распределения информации между различными этапами проекта, группами разработчиков и выполняемыми операциями. Поддержка базы проектных данных может быть реализована собственными средствами СП или средствами целевой СУБД (второй вариант предпочтительнее, поскольку упрощается технология ведения репозитория). Невыполнение требования целостности в условиях разобщенности разработчиков и временной протяженности крупного проекта может означать утрату контроля за его состоянием.

Независимость от программно-аппаратной платформы и СУБД. Требование определяется неоднородностью среды функционирования ИС. Такая независимость может иметь две составляющих: независимость среды разработки и независимость среды эксплуатации приложений. Она обеспечивается за счет наличия совместимых версий СП для различных платформ и драйверов соответствующих сетевых протоколов, менеджеров транзакций и СУБД. Один из дополнительных факторов, который при этом следует учитывать - это способ взаимодействия с СУБД (прямой или через ODBC), поскольку использование ODBC может заметно ухудшить производительность и надежность интерфейса.

Поддержка одновременной работы групп разработчиков. Развитые СП должны обладать возможностями разделения полномочий персонала разработчиков и объединения отдельных работ в общий проект. Должна обеспечиваться одновременная работа проектировщиков БД и разработчиков приложений (разработчики приложений в такой ситуации могут начинать работу с базой данных, не дожидаясь полного завершения ее проектирования CASE-средствами). При этом все группы специалистов должны быть обеспечены адекватным инструментарием, а внесение изменений в проект различными разработчиками должно быть согласованным и корректным. Каждый разработчик должен иметь возможность работы со своим личным репозиторием, являющимся фрагментом или копией общего репозитория. Должны обеспечиваться содержательная интеграция всех изменений, вносимых разработчиками, в общем репозитории, одновременная доступность для разработчика общего и личного репозиториев и простота переноса объектов между ними. Помимо перечисленных основных критериев, предварительный анализ при выборе СП должен учитывать следующие аспекты:

Возможность разработки приложений "клиент-сервер" требуемой конфигурации. Подразумевается сочетание наличия развитой графической среды разработки приложений (многооконность, разнообразие стандартных графических объектов, разнообразие используемых шрифтов и т.д.) с возможностью декомпозиции (partitioning) приложения на "клиентскую" часть, реализующую пользовательский экранный интерфейс и "серверную" часть. При этом должна обеспечиваться возможность перемещения отдельных компонентов приложения между "клиентом" и "сервером" на наиболее подходящую платформу, обеспечивающую максимальную эффективность функционирования приложения в целом, а также возможность использования сервера приложений (менеджера транзакций).

Открытая архитектура и возможности экспорта/импорта. Открытая и общедоступная информация об используемых форматах данных и прикладных программных интерфейсах должна позволять интегрировать инструментальные средства третьих фирм и относительно безболезненно переходить от одной системы к другой. Возможности экспорта/импорта означают, что спецификации, полученные на этапах анализа, проектирования и реализации для одной ИС, могут быть использованы для проектирования другой ИС. Повторное проектирование и реализация могут быть обеспечены при помощи средств экспорта/импорта спецификаций в различные СП.

Качество технической поддержки в России, стоимость приобретения и поддержки, опыт успешного использования. Имеется в виду наличие квалифицированных дистрибьюторов и консультантов, быстрота обслуживания пользователей, высокое качество технической поддержки и обучения продукту и методологии его применения для больших коллективов разработчиков (наличие сведений о практике использования системы, качество документации, укомплектованность примерами и обучающими курсами, наличие прототипных проектов). Затраты на обучение новым технологиям значительны, однако потери от использования современных сложных технологий необученными специалистами могут оказаться значительно выше. Кроме того, фирмы-поставщики инструментальных средств должны быть устойчивыми, так как технология выбирается не на один год, а также должны обеспечивать хорошую поддержку на территории России (горячая линия, консультации, обучение, консалтинг), возможно, через дистрибьюторов. Что касается стоимости, следует учитывать возможность получения бесплатной пробной лицензии (trial license), стоимость лицензии на одно рабочее место СП, скидки, предоставляемые фирмой в случае приобретения большого количества лицензий, необходимость приобретения run-time версий для эксплуатации приложений и т.д. В то же время стоимость продукта должна рассматриваться не сама по себе, а с учетом ее соответствия возможностям продукта.

Простота использования. Учитываются следующие характеристики:

• доступность пользовательского интерфейса;

• время, необходимое для обучения;

• простота инсталляции;

• качество документации.

Обеспечение качества проектной документации. Это требование относится к возможностям СП анализировать и проверять описания и документацию на полноту и непротиворечивость, а также на соответствие принятым в данной методологии стандартам и правилам (включая ГОСТ, ЕСПД). В результате анализа должна формироваться информация, указывающая на имеющиеся противоречия или неполноту в проектной документации. Должна быть также обеспечена возможность создавать новые формы документов, определяемые пользователями.

Использование общепринятых, стандартных нотаций и соглашений. Для того, чтобы проект мог выполняться разными коллективами разработчиков, необходимо использование стандартных методов моделирования и стандартных нотаций, которые должны быть оформлены в виде нормативов до начала процесса проектирования. Несоблюдение данного требования ставит разработчиков в зависимость от фирмы-производителя данного средства, делает затруднительным формальный контроль корректности используемых нотаций и снижает возможности привлечения дополнительных коллективов разработчиков, поскольку число специалистов, знакомых с данным методом (нотацией) может быть ограниченным. В идеальном случае (что, конечно же, далеко не всегда возможно) окончательный выбор может быть произведен по результатам тестирования в соответствии с заданным планом, которое должно включать имитацию проектирования реальной БД и разработки приложений и состоять из следующих шагов:

• установка и конфигурирование (ясность и точность инструкций по установке, наличие подсказок в процессе установки, возможность установки по выбору и задания многопользовательской конфигурации);

• разработка концептуальной схемы БД (понятность и простота построения, модификации и документирования различных элементов диаграмм "сущность-связь", отображение ограничений ссылочной целостности и бизнес- правил, управление режимом отображения);

• формирование отчета о концептуальной схеме (список сущностей с определениями и атрибутами, включая указание ключей, список атрибутов, сгруппированных по сущностям, список связей между сущностями, возможность форматирования отчета, составления отчета по выделенной части схемы, передачи отчета, например, в другие приложения (текстовые процессоры));

• разработка графической схемы БД для конкретной СУБД с учетом специфичных для нее структур данных и ограничений (выбор целевой СУБД и реализация элементов схемы - ввод и модификация имен таблиц и столбцов, определение типов данных, доменов, индексов, значений по умолчанию и неопределенных значений, порядка индексирования, а также задание ограничений ссылочной целостности и дополнительных бизнес-правил, характеризующих предметную область, управление триггерами и хранимыми процедурами);

• формирование отчета о схеме БД (печать диаграммы схемы, списка таблиц с соответствующими столбцами, первичными ключами, индексами и т.д., возможность форматирования отчета, составления отчета по выделенной части схемы, передачи отчета в другие приложения);

• генерация схемы БД (трансформация схемы БД в файл DDL в текстовом формате или непосредственный интерфейс с целевой СУБД);

• разработка простейшего приложения (описание экранных форм, программирование или описание логики приложения и интерфейса с БД, загрузка БД тестовыми данными и тестирование приложения);

• сопровождение схем БД (внесение изменений - создание новых сущностей и атрибутов, изменение схемы БД, повторная генерация схемы, управление версиями, обеспечение сохранности данных, синхронизация концептуальной схемы и самой БД);

• обратное проектирование - реинжиниринг (полное и точное восстановление исходной концептуальной схемы по файлам DDL или непосредственно из словаря целевой СУБД).

В результате выполненного анализа может оказаться, что ни одно доступное средство не удовлетворяет в нужной мере всем основным критериям и не покрывает все потребности проекта. В этом случае может применяться набор средств, позволяющий построить на их базе единую технологическую среду.

Анализ средств проектирования информационных систем

Современные СП могут быть разделены на две большие категории. Первую составляют CASE- системы (как независимые (upper CASE), так и интегрированные с СУБД), обеспечивающие проектирование БД и приложений в комплексе с интегрированными средствами разработки приложений "клиент-сервер" (например, Westmount I-CASE+Uniface, Designer/2000+Developer/2000). Их основное достоинство заключается в том, что они позволяют разрабатывать всю ИС целиком (функциональные спецификации, логику процессов, интерфейс с пользователем и базу данных), оставаясь в одной технологической среде. Инструменты этой категории, как правило, обладают существенной сложностью, широкой сферой применения и высокой гибкостью. Вторую категорию составляют собственно средства проектирования БД, реализующие ту или иную методологию, как правило, "сущность-связь" ("entity-relationship") и рассматриваемые в комплексе со средствами разработки приложений. К средствам этой категории можно отнести такие, как SILVERRUN+JAM, ERwin/ERX+PowerBuilder и др. Помимо указанных категорий, СП можно классифицировать по следующим признакам:

• степени интегрированности: (отдельные локальные средства, набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС и полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);

• применяемым методологиям и моделям систем и БД;

• степени интегрированности с СУБД;

• степени открытости;

• доступным платформам.

В разряд СП попадают как относительно дешевые системы для персональных компьютеров (ПК) с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-систем, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами. Применение СП требует от потенциальных пользователей специальной подготовки и обучения. Опыт показывает, что внедрение СП осуществляется медленно, однако по мере приобретения практических навыков и общей культуры проектирования эффективность применения этих средств резко возрастает, причем наибольшая потребность в использовании СП испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки. На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми СП:

• Westmount I-CASE;

• Uniface;

• Designer/2000+Developer/2000 (ORACLE);

• SILVERRUN+JAM;

• ERwin/ERX+PowerBuilder.

Приведенный список не претендует на полноту. Кроме того, на рынке постоянно появляются как новые (для отечественных пользователей) системы, так и новые версии и модификации перечисленных систем (например, CASE/4/0, System Architect и т.д.). Некоторое представление о возможностях наиболее развитых СП может дать краткая характеристика следующих программных продуктов:

Westmount I-CASE 3.2 (CADRE Technologies Inc.)

Westmount I-CASE представляет собой интегрированный программный продукт, обеспечивающий выполнение следующих функций:

• графическое проектирование архитектуры системы (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа "клиент- сервер", анализ использования мониторов транзакций и особенностей функционирования систем в реальном времени);

• проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм;

• генерация кода программ на 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;

• программирование на языке C со встроенным SQL;

• управление версиями и конфигурацией проекта;

• генерация проектной документации по стандартным и индивидуальным шаблонам;

• экспорт и импорт данных проекта в формате CDIF.

Westmount I-CASE можно использовать в конфигурации "клиент-сервер", при этом база проектных данных может располагаться на сервере, а рабочие места разработчиков могут быть клиентами. Westmount I-CASE функционирует на всех основных UNIX-платформах и VMS. В качестве целевой СУБД могут использоваться ORACLE, Informix, Sybase и Ingres. В качестве отдельного продукта поставляется интерфейс Westmount-Uniface Bridge, обеспечивающий совместное использование двух систем в рамках единой технологической среды проектирования (при этом схемы БД, структурные схемы программ и последовательности экранных форм непосредственно в режиме on-line, без создания каких-либо файлов экспорта- импорта, переносятся в репозиторий Uniface, и, наоборот, прикладные модели, сформированные средствами Uniface, могут быть перенесены в репозиторий Westmount I-CASE. Возможные рассогласования между репозиториями двух систем устраняются с помощью специальной утилиты). В рамках версии Westmount I-CASE 4.0 предполагается обеспечить возможность функционирования клиентской части в среде Windows 95, а серверной - в среде Windows NT.

Uniface (Compuware)

Uniface 6.1 представляет собой среду разработки крупномасштабных приложений "клиент-сервер" и имеет следующую компонентную архитектуру:

• Application Objects Repository (репозиторий объектов приложений) содержит метаданные, автоматически используемые всеми остальными компонентами на протяжении жизненного цикла ИС.

• Application Model Manager поддерживает прикладные модели, каждая из которых представляет собой подмножество общей схемы БД с точки зрения данного приложения.

• Rapid Application Builder - средство быстрого создания экранных форм и отчетов на базе объектов прикладной модели. Оно включает графический редактор форм, средства прототипирования, отладки, тестирования и документирования. Реализован интерфейс с разнообразными типами оконных элементов управления (Open Widget Interface) для существующих графических систем - MS Windows (включая VBX), Motif, OS/2.

• Developer Services (службы разработчика) - используются для поддержки крупных проектов и реализуют контроль версий, права доступа, глобальные модификации и т.д. Это обеспечивает разработчиков средствами параллельного проекти-рования, входного и выходного контроля, поиска, просмотра, поддержки и выдачи отчетов по данным системы контроля версий.

• Deployment Manager (управление распространением приложений) - средства, позволяющие подготовить созданное приложение для распространения, установить и сопровождать его (при этом платформа пользователя может отличаться от платформы разработчика). В их состав входят сетевые драйверы и драйверы СУБД, сервер приложений (полисервер), средства распространения приложений и управления базами данных. Uniface поддерживает интерфейс практически со всеми известными программно- аппаратными платформами, СУБД, CASE-средствами, сетевыми протоколами и менеджерами транзакций.

• Personal Series (персональные средства) - используются для создания сложных запросов и отчетов в графической форме, а также для переноса данных в такие системы, как WinWord и Excel.

В качестве примера можно привести результаты предварительного анализа перечисленных выше СП, которые сведены в краткую таблицу характеристик, приведенную ниже. Таблица характеристик СП

СП	West-mount I-CASE + Uniface	Designer/2000+Developer/2000	SILVER-RUN + JAM	ERwin/ERX + PowerBuilder
Поддержка полного жизненного цикла ИС	+	+	+	+
Обеспечение целостности проекта	+	+	-	-
Независимость от платформы	+ (ORACLE, Informix, Sybase, Ingres и др., dbf-файлы)	- (целевая СУБД - только ORACLE)	+ (ORACLE, Informix, Sybase, Ingres и др.)	+ (ORACLE, Informix, Sybase, поддержка ODBC)
Одновременная групповая разработка БД и приложений	+	- *)	- *)	- *)

*) разработчики приложений могут начинать работу с базой данных только после завершения ее проектирования. Анализ данных, приведенных в таблице, показывает, что из перечисленных СП только комплекс Westmount I-CASE+Uniface наиболее полно удовлетворяет всем критериям, принятым в качестве основных. Так, например, в комплексе Westmount I-CASE+Uniface целостность базы проектных данных и единая технология сквозного проектирования ИС обеспечивается за счет использования интерфейса Westmount-Uniface Bridge. Следует отметить, что каждый из двух продуктов сам по себе является одним из наиболее мощных в своем классе. Таким образом, наиболее развитыми средствами разработки крупномасштабных ИС на сегодняшний день является, по мнению автора, комплекс Westmount I-CASE+Uniface. С другой стороны, его применение не исключает использования в том же самом проекте таких средств, как PowerBuilder, для разработки сравнительно небольших прикладных систем в среде MS Windows.

14 Современная методология проектирования иС, понятие бизнес процесса, бизнес-функции и бизнес-модели. Основные модели жизненного цикла ИС(каскадная, спиральная модели, поэтапная модель с промежуточным контролем) регламентация процессов проектирования в отечественных и международных стандартах.

Бизнес-процесс — это последовательность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей. Для наглядности бизнес-процессы визуализируют при помощи блок-схемы бизнес-процессов. Существуют три вида бизнес-процессов:

1. Управляющие — бизнес-процессы, которые управляют функционированием системы. Примером управляющего процесса может служить Корпоративное управление иСтратегический менеджмент.

2. Операционные — бизнес-процессы, которые составляют основной бизнес компании и создают основной поток доходов. Примерами операционных бизнес-процессов являются Снабжение, Производство, Маркетинг и Продажи.

3. Поддерживающие — бизнес-процессы, которые обслуживают основной бизнес. Например, Бухгалтерский учет, Подбор персонала, Техническая поддержка

Бизнес-процесс начинается со спроса потребителя и заканчивается его удовлетворением. Бизнес-процесс может быть декомпозирован на несколько подпроцессов, которые имеют собственные атрибуты, однако также направлены на достижение цели основного бизнес-процесса. Бизнес-процессы должны быть построены таким образом, чтобы создавать стоимость и ценность для потребителей и исключать любые необязательные или вовсе лишние активности. На выходе правильно построенных бизнес-процессов увеличиваются ценность для потребителя и рентабельность (меньшая себестоимость производства товара или услуги).

Бизнес-процессы могут подвергаться моделированию с помощью различных методов. Одним из способов является составление модели бизнес-процесса «как есть» (англ. as is). После этого модель бизнес-процесса подвергается критическому анализу или обрабатывается специальным программным обеспечением. В результате строится модель бизнес-процесса «как должно быть» (англ. to be). Некоторые консультанты опускают фазу «как есть» и сразу предлагают модель «как должно быть».

Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления. Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.

В настоящее время известны и используются следующие модели жизненного цикла:

•  Каскадная модель (рис. 2.1) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.

•  Поэтапная модель с промежуточным контролем (рис. 2.2). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

•  Спиральная модель (рис. 2.3). На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).

Рис. 2.1.  Каскадная модель ЖЦ ИС

Рис. 2.2.  Поэтапная модель с промежуточным контролем

Рис. 2.3.  Спиральная модель ЖЦ ИС

На практике наибольшее распространение получили две основные модели жизненного цикла:

• каскадная модель (характерна для периода 1970-1985 гг.);

• спиральная модель (характерна для периода после 1986.г.).

В ранних проектах достаточно простых ИС каждое приложение представляло собой единый, функционально и информационно независимый блок. Для разработки такого типа приложений эффективным оказался каскадный способ. Каждый этап завершался после полного выполнения и документального оформления всех предусмотренных работ.

Можно выделить следующие положительные стороны применения каскадного подхода:

• на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;

• выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.

Каскадный подход хорошо зарекомендовал себя при построении относительно простых ИС, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе. Основным недостатком этого подхода является то, что реальный процесс создания системы никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС оказывается соответствующим поэтапной модели с промежуточным контролем.

Однако и эта схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к системе. Согласование результатов разработки с пользователями производится только в точках, планируемых после завершения каждого этапа работ, а общие требования к ИС зафиксированы в виде технического задания на все время ее создания. Таким образом, пользователи зачастую получают систему, не удовлетворяющую их реальным потребностям.

Спиральная модель ЖЦ была предложена для преодоления перечисленных проблем. На этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путем создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы. Это позволяет уточнить требования, цели и характеристики проекта, определить качество разработки, спланировать работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который удовлетворяет действительным требованиям заказчика и доводится до реализации.

Итеративная разработка отражает объективно существующий спиральный цикл создания сложных систем. Она позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем и решить главную задачу - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.

Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения вводятся временные ограничения на каждый из этапов жизненного цикла, и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. Планирование производится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

15 Каноническое проектирование ИС.стадии и этапы процесса проектирования ИС. Формирование требований к ИС, обследование предметной области.раработка концепции ИС. Модели деятельности предприятий: модель «как есть» и модель «как должно быть». Реализация моделей с помощью Case-средства.