Введение.

Программное обеспечение за полвека своего существования претерпело огромные изменения: от программ, способных выполнять только простейшие логические и арифметические операции до сложных систем управления предприятиями. В развитии программного обеспечения всегда можно было выделить два основных направления:
>> выполнение вычислений;
>> накопление и обработка информации.
Хотя первоначально компьютеры предназначались главным образом для выполнения сложных математических расчетов (в первую очередь для расчетов, связанных с созданием ядерного оружия и ракетной техники), в настоящее время доминирующим является второе направление. Такое перераспределение основных функции, выполняемых вычислительной техникой, вполне понятно - гражданский бизнес гораздо более распространен, чем военные и научные вычисления, а снижение стоимости компьютеров сделало их доступными для совсем небольших предприятий и даже частных лиц.
Сегодня управление предприятием без компьютера просто немыслимо. Компьютеры давно и прочно вошли в такие области управления, как бухгалтерский учёт, управление складом, ассортиментом и закупками. Однако современный бизнес требует гораздо более широкого применения информационных технологий в управлении предприятием. Жизнеспособность и развитие информационных технологий объясняется тем, что современным бизнес крайне чувствителен к ошибкам в управлении. Интуиции, личного опыта руководителя и размеров капитала уже мало для того, чтобы быть первым. Для принятия любого грамотнoгo управленческого решения в условиях неопределенности и риска необходимо постоянно держать под контролем различные аспекты финасово-хозяйственной деятельности, будь то: торговля, производство или предоставление каких-либо услуг. Поэтому современный подход к управлению предполагает вложение средств в информационные технологии. И чем крупнее предприятие, тем серьезнее должны быть подобные вложения. Они являются жизненной необходимостью - в жесткой конкурентной борьбе одержать победу сможет лишь тот, кто лучше оснащен и наиболее эффективно организован.

Информационные системы.

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

База данных.

Как уже отмечалось ранее, система управления БД (СУБД) является неотъемлемой частью любой информационной системы. Тип используемой СУБД обычно определяется масштабом информационной системы – малые информационные системы могут использовать локальные СУБД, в корпоративных же информационных системах потребуется мощная клиент-серверная СУБД, поддерживающая многопользовательскую работу.
В настоящее время наиболее широко распространены реляционные СУБД. Несмотря на очевидную привлекательность и растущую популярность объектно-ориентированных СУБД (ObjectStore, Objectivity, O2, Jasmin), пока всё же преобладают реляционные БД, являющиеся хорошо отлаженными, развитыми, сопровождаемыми системами, поддерживающими стандарт SQL-92 (к таким системам относятся, например, Oracle, Informix, Sybase, DB2, MS SQL Server).
Традиционным методом организации информационных систем является двухзвенная архитектура клиент-сервер. В этом случае вся прикладная часть информационной системы размещается на рабочих станциях, а на стороне сервера осуществляется только доступ к базе данных. Чтобы разгрузить клиентскую рабочую станцию и уменьшить загрузку сети, применяются трехзвенные архитектуры клиент-сервер. В этой архитектуре кроме клиентской части системы и сервера базы данных вводится промежуточный сервер приложений. На стороне клиента выполняются только интерфейсные действия, а вей логика обработки информации поддерживается в сервере приложений.
При разработке базы данных необходимо учитывать специфику той СУБД, для котором .на разработка проводится. Несмотря на существование стандарта ANSI SQL 92, практически все SQL-серверы используют своп реализации SQL, содержащие расширения стандарта. Тем не менее на начальном этапе, при разработке общей структуры базы данных (на уровне концептуальной модели), особенности используемой СУБД можно не учитывать.

CASE-средства.

Первым шагом в проектировании информационной системы является получение формального описания предметной области, построение полных и непротиворечивых функциональных и информационных моделей информационной системы. Это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Следует также учитывать, что в процессе создания и функционирования информационной системы потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.
Указанные сложности способствовали появлению программно-технологических класса, так называемых CASE-средств, призванных повысить эффективность разработки ПО. Термин CASH (Computer Aided Software/System Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных информационных систем в целом. В настоящее время под CASE-средствами понимаются программные средства, поддерживающие процессы создания и сопровождения информационных систем, включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы.

Средства разработки.

Еще один класс задач, решаемых при проектировании информационных систем, относится к созданию удобного и соответствующего целям информационной системы пользовательского интерфейса. Следует понимать, что задача эргономичности интерфейса не формализуется, но в то же время она является очень существенной. Пользователи часто судят о качестве системы в целом, исходя из качества ее интерфейса. Более того, от качества интерфейса зависит эффективность использования системы.
Разработка интерфейса всегда являлась трудоемкой задачей, отнимающей много времени у разработчиков. Однако в последние годы появились так называемые средства визуальной разработки приложений, в значительной мере упростившие задачу разработки графического интерфейса пользователя. Сейчас па рынке программных продуктов предлагается довольно много разнообразных средств визуальной разработки приложений, ориентированных на разработку информационных систем. Все их можно условно разделить на два класса:
>> специализированные средства ориентированные исключительно на работу с вполне определенной СУБД и не предназначенные для разработки обычных приложений, не использующих базы данных. Примером средств такого рода может служить система Power Builder фирмы Sybase;
>> универсальные средства, которые могут использоваться как для разработки информационных приложений, взаимодействующих с базами данных, так и для разработки любых других приложений, не использующих базы данных. Из таких средств наибольшей известностью пользуются системы Borland Delphi фирмы Borland и Visual Basic фирмы Microsoft.
Каждый из указанных классов имеет свои достоинства и недостатки, поэтому в общем случае трудно отдать предпочтение одному из них.
В предлагаемой книге в качестве средства разработки выбран продукт Borland Delphi, пользующийся большой популярность в нашей стране. Delphi базируется на объектно-ориентированном языке Object Pascal, который наилучшим образом подходит для учебных целей вследствие своей строгости и простоты. Кроме того, в Object Pascal в полной мере реализованы все основные концепции объектно-ориентированного программирования. Объектно-ориентированное программирование позволяет сделать любую систему более гибкой и динамичной, исключив необходимость в постоянном переписывании структуры базы данных и приложений.
Главное достоинство объектно-ориентированного проектирования заключается в возможности повторно использовать ранее написанный код. Кроме того, объектные системы несут в себе возможность модификации и развития. Применительно к базам данных это положение позволяет начать проектирование будущей системы, не имея исчерпывающего представления о предметной области. Поскольку получение детальной информации о предметной области - процесс весьма трудоёмкий, то применение объектно-ориентированного подхода позволит сократить сроки и уменьшить стоимость разработки системы.
Для кого предназначена эта книга?
Данная книга в первую очередь предназначена для начинающих программистов, не имеющих большого опыта разработки информационных систем. Основное внимание в книге уделяется вопросам разработки клиентской части информационных систем с использованием системы визуальной разработки приложений Borland Delphi.
В то же время в книге содержится большое количество материала, посвящённого вопросам разработки баз данных, в частности, рассматриваются основные методологии проектирования информационных систем, приводится подробное описание стандарта ANSI SQL-92, излагаются теоретические сведения о реляционной модели данных. Таким образом, данную книгу можно рассматривать в качестве учебного пособия но информационным системам начального уровня.

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

>> все части книги (главы 1-6) излагаются базовые сведения об информационных системах предприятий и их проектировании. В первых трех главах приводится основная терминология и рассматриваются базовые понятия, знание которых необходимо для эффективного восприятия материала из последующих глав и других литературных источников. Далее рассматриваются вопросы проектирования и разработки одной из важнейших частей информационной системы - реляционной базы данных. В реляционных базах данных информация хранится в виде взаимосвязанных двумерных таблиц. Разработка структуры базы данных, обеспечивающей эффективный доступ к информации и ее обработку, в значительной степени определяет качество информационной системы в целом. Для упрощения процесса проектирования структуры базы данных и уменьшения времени разработки используются специальные программные средства проектирования баз данных, называемые CASE-средствами.
Каждая из представленных в этой части книги глав касается важных концептуальных понятий.
>>Глава 1. "Информационные системы". В данной главе рассматриваются общие понятия и типы информационных систем, определяются их базовые свойства, а также формулируются задачи, решаемые при разработке таких систем, и проблемы, возникающие при их решении. Также рассматриваются наиболее типичные области применения информационных систем.
>> Глава 2. "Жизненный цикл информационных систем". Здесь рассматриваются понятие жизненного цикла информационной системы и основные процессы, его сопровождающие. Также рассматриваются основные модели жизненного цикла информационных систем.
>> Глава 3. "Методология и технология разработки информационных систем". В этой главе приводятся сведения о методологии быстрой разработки приложении — RAD (Rapid Application Development), рассматриваются фазы жизненного цикла информационной системы в рамках методологии RAD. Приводятся сведения об основных международных и российских стандартах и методиках разработки информационных систем.
>> Глава 4. "Реляционные базы данных". В этой главе приводятся основные сведения о реляционных базах данных. Рассматриваются важнейшие функции, выполняемые системами управления базами данных, дается краткая история их развития. Обсуждаются основы реляционной модели данных, нормальные формы данных и вопросы нормализации данных.
>> Глава 5. "Управление реляционными базами данных". Здесь приводятся сведения о методах и средствах управления как информацией, хранящейся и базе данных, так и структурой самой базы данных. Рассматриваются средства языка управления базами данных SQL, предусмотренные стандартом ANSI 92.
>> Глава 6. "Проектирование структуры базы данных". В данной главе рассматриваются понятия концептуальной и физической моделей данных, а также средства анализа и проектирования баз данных (CASE-средства). Приводится пример разработки базы данных с использованием одного из наиболее популярных CASE-средств Power Designer.

От издательства
Наши замечания, предложения, вопросы отправляйте по адресу электронной почты
comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
Подробную информацию о наших книгах вы найдете на web-сайте издательства
http://www.piter.com

Глава 1. Информационные системы.
>> развитие сети Интернет принесло большие возможности работы с удаленными подразделениями, открыло широкие перспективы электронной коммерции, обслуживания покупателей через Интернет и многое другое. Более того, определенные преимущества дает использование Интернет технологий в интрасетях предприятия (так называемые интранет технологии).
ПРИМЕЧАНИЕ
Следует иметь в виду, что использование определенных технологий при построении информационных систем не является самоцелью разработчика. Выбор технологий должен производиться в зависимости от реальных потребностей.
Основные составляющие корпоративных информационных систем
В составе корпоративных информационных систем можно выделить две относительно независимых составляющих:
>> компьютерную инфраструктуру организации, представляющую собой совокупность сетевой, телекоммуникационной, программной, информационной и организационной инфраструктур. Данная составляющая обычно называется корпоративной сетью.
>> взаимосвязанные функциональные подсистемы, обеспечивающие решение задач
организации и достижение ее целей.
Первая составляющая отражает системно-техническую, структурную сторону любой информационной системы. По сути, это основа для интеграции функциональных подсистем, полностью определяющая свойства информационной системы, определяющие ее успешную эксплуатацию. Требования к компьютерной инфраструктуре едины и стандартизованы, а методы ее построения хорошо известны и многократно проверены на практике. Вторая составляющая корпоративной информационной системы полностью относится
к прикладной области и сильно зависит от специфики задач и целей предприятия.
Данная составляющая полностью базируется на компьютерной инфраструктуре предприятия и определяет прикладную функциональность информационной системы, Требования к функциональным подсистемам сложны и зачастую противоречивы, так как выдвигаются специалистами из различных прикладных областей. Однако в конечном счёте именно эта составляющая более важна для функционирования организации, так как для неё, собственно, и строится компьютерная инфраструктура.
Соотношение между составляющими информационной системы.
Взаимосвязи между двумя указанными составляющими информационной системы достаточно сложны. С одной стороны, эти две составляющие в определенном смысле независимы. Например, организация сети и протоколы, используемые для обмена данными между компьютерами, абсолютно не зависят от того, какие методы и программы планируется использовать на предприятии для организации бухгалтерского учета.
С другой стороны, указанные составляющие в определенном смысле все же зависят друг от друга. Функциональные подсистемы в принципе не могут существовать без компьютерной инфраструктуры. В то же время компьютерная и инфраструктура сама по себе достаточно ограничена, поскольку не обладает необходимой функциональностью. Невозможно эксплуатировать распределенную информационную систему при отсутствии сетевой инфраструктуры. Хотя, имея развитую инфраструктуру, можно предоставить сотрудникам организации ряд полезных общесистемных служб (например, электронную почту доступ в Интернет), упрощающих работу и делающих ее более эффективной (в частности, за счет использования более развитых средств связи).
Таким образом, разработку информационной системы целесообразно начинать с построения компьютерной инфраструктуры (корпоративной сети) как наиболее важной составляющей, опирающейся на апробированные промышленные технологии и гарантированно реализуемой в разумные сроки и силу высокой степени определенности как в постановке задачи, так и и предлагаемых решениях.
ПРИМЕЧАНИЕ
Бессмысленно строить корпоративную сеть как некую самодостаточную систему, не принимая во внимание прикладную функциональность. Если в процессе создания системно-технической инфраструктуры не проводить анализ и автоматизацию управленческих задач, то средства, инвестированные в разработку корпоративной сети, не дадут впоследствии реальной отдачи.
Корпоративная сеть создается на многие годы вперед, капитальные затраты на ее разработку и внедрение настолько велики, что практически исключают возможность полной или частичной переделки существующей сети. Функциональные подсистемы, в отличие от корпоративной сети, изменчивы по своей природе, так как в предметной области деятельности организации постоянно происходят более или менее существенные изменения. Функциональность информационных систем сильно зависит от организационно-управленческой структуры организации, ее функциональности, распределения функции, принятых в организации финансовых технологий и схем, существующей технологии документооборота и множества других факторов.
Разработку н внедрение функциональных подсистем можно выполнять постепенно. Например, сначала на наиболее важных и ответственных участках выполнять разработки, обеспечивающие прикладную функциональность системы (внедрять системы финансового учета, управления кадрами и т.п.), а затем распространять прикладные программные системы и па другие, первоначально менее значимые области управления предприятием.
Классификация информационных систем
Информационные системы классифицируются по разным признакам. Рассмотрим наиболее часто используемые способы классификации.

Классификация по масштабу
По масштабу информационные системы подразделяются на следующие группы:

>> одиночные;
>> групповые;
>> корпоративные.

Одиночные информационные системы.

Одиночные информационные системы реализуются, как правило, на автономном ПК (сеть не используется). Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых настольных или локальных систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro, Paradox, dBase и Qicrosoft Access.
Групповые информационные системы.
Групповые информационные системы ориентированы на коллективное использование информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используются серверы баз данных (называемые также SQL-серверами) для рабочих групп. Существует довольно большое количество различных SQL-серверов, как коммерческих, так и свободно распространяемых. Среди них наиболее известны такие серверы баз данных, как Oracle, DB2. Qicrosoft SQL Server, InlerBase, Sybase, Inforqix.
Корпоративные информационные системы.
Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией сервером или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Qocrosoft SQLServer.
Для групповых и корпоративных систем существенно повышаются требования к надежности функционирования и сохранности данных. Эти свойства обеспечиваются поддержкой целостности данных, ссылок и транзакции в серверах баз данных.

Классификация по сфере применения.

По сфере применения информационные системы обычно подразделяются па четыре группы:

>> системы обработки транзакций;
>> системы принятия решений;
>> информационно-справочные системы;
>> офисные информационные системы.

Системы обработки транзакций, в свою очередь, по оперативности обработки данных, разделяются на пакетные информационные системы и оперативные информационные системы. В информационных системах организационного управления преобладает режим оперативной обработки транзакций - OLTP (OnLinc Tran¬saction Processing), для отражения актуального состояния предметной области в
любой момент времени, а пакетная обработка занимает весьма ограниченную часть. Для систем OLTP характерен регулярный поток довольно простых транзакций, играющих роль заказов, платежей, запросов и т. п. Важными требованиями для них являются: >> высокая производительность обработки транзакций;
>> гарантированная доставка информации при удаленном доступе к БД по телекоммуникациям.
Системы поддержки принятия решений - DSS (Decision Support Systeq) - представляют собой другой тип информационных систем, в которых с помощью довольно сложных запросов производится отбор и анализ данных в различных разрезах: временных, географических и по другим показателям.
Обширный класс информационно-справочных основан на гипертекстовых документах и мультимедиа. Наибольшее развитие такие информационные системы получили в сети Интернет.
Класс офисных информационных систем нацелен на перевод бумажных документов в электронный вид, автоматизацию делопроизводства и управление документооборотом.
ПРИМЕЧАНИЕ
Следует отметить, что приводимая классификация по сфере применения в достаточной степени условна. Крупные информационные системы очень часто обладают признаками всех перечисленных выше классов. Кроме того, корпоративные информационные системы масштаба предприятия обычно состоят из ряда подсистем, относящихся к различным сферам применения.

Классификация по способу организации.

По способу организации групповые и корпоративные информационные системы
подразделяются на следующие классы.

>> системы на основе архитектуры файл-сервер;
>> системы на основе архитектуры клиент-сервер;
>> системы на основе многоуровневой архитектуры;
>> системы на основе Интернет/интранеттехнологий.

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

Архитектура файл-сервер.

Архитектура файл-сервер не имеет сетевого разделения компонентов диалога PS и PL и использует компьютер для функций отображения, что облегчает построение графического интерфейса. Файл-сервер только извлекает данные из файлов, так что дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на центральный процессор. Каждый новый клиент добавляет вычислительную мощность к сети.
Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логику обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интерпретации.
Однако такая архитектура имеет существенный недостаток: при выполнении некоторых запросов к базе данных клиенту могут передаваться большие объемы данных, загружая сеть и приводя к непредсказуемости времени реакции. Значительный сетевой трафик особенно сильно сказывается при организации удаленного доступа к базам данных на файл-сервере через низкоскоростные каналы связи. Одним из вариантов устранения данного недостатка является удаленное
управление файл-серверным приложением в сети. При этом в локальной сети
размещается сервер приложений, совмещенный с телекоммуникационным сервером (обычно называемым сервером доступа), в среде которого выполняются обычные файл-серверные приложения. Особенность состоит в том, что диалоговый ввод-вывод поступает от удаленных клиентов через телекоммуникации. Приложения не должны быть слишком сложными, иначе велика вероятность перегрузки сервера, или же нужна очень мощная платформа для сервера приложений.
ПРИМЕЧАНИЕ
Одним из традиционных средств, на основе которых создаются файл-серверные системы, являются локальные СУБД. Однако такие системы, как правило, не отвечают требованиям обеспечения целостности данных (в частности, они не поддерживают транзакции). Поэтому при их использовании задача обеспечения целостности данных возлагается на программы клиентов, что приводит к усложнению клиентских приложений. Однако эти инструменты привлекают своей простотой, удобством исполь¬зования и доступностью. Поэтому файл-серверные информационные системы до сих пор представляют интерес для малых рабочих групп и, более того, нередко используются в качестве информационных систем масштаба предприятия.

Архитектура клиент-сервер.

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверных приложений путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, пони¬мающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации. Отличительная черта серверов БД - наличие справочника данных, в котором записана структура БД, ограничения целостности данных, форматы и даже серверные процедуры обработки данных по вызову или по событиям в программе. Объектами разработки в таких приложениях помимо диалога и логики обработки являются, прежде всего, реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов к базе данных.
Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые ком¬поненты PS и PL размешаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размешаются на сервере, а диалог (PS, PL), логика BL и DL - на клиенте. Двухуровневое опреде¬ление архитектуры клиент-сервер использует именно этот вариант: приложение работает у клиента. СУБД - на сервере.
Поскольку эта схема предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью. Однако сложные приложения, вызывающие большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому, что там находится логика принятия решения. Такая схема приводит к дополнительному усложнению администрирования приложений, разбросанных по раз личным клиентским узлам.
Для сокращения нагрузки на сеть и упрощения администрирования приложений компонент BL можно разместить на сервере. При этом вся логика принятия решении оформляется в виде хранимых процедур и выполняется на сервере БД. Хранимая процедура - процедура с операторами SQL для доступа к БД, вызываемая по имени с передачей требуемых параметров и выполняемая на сервере БД, Хранимые процедуры могут компилироваться, что повышает скорость их выполнения и сокращает нагрузку на сервер.
Хранимые процедуры улучшают целостность приложений и БД, гарантируют актуальность коллективно используемых операций и вычислений. Улучшается сопро¬вождение таких процедур, а также безопасность (нет прямого доступа к данным).
ПРИМЕЧАНИЕ
Следует помнить, что перегрузка хранимых процедур прикладной логикой может перегрузить сервер, что приведет к потере производительности. Эта проблема особенно актуальна при разработке крупных информационных систем, в которых к серверу может одновременно обращаться большое количество клиентов. Поэтому в большинстве случаев следует принимать компромиссные решения: часть логики приложения размещать на стороне сервера, часть — на стороне клиента. Такие клиент-серверные системы называются системами с разделенной логикой. Данная схема при удачном разделении логики позволяет получить более сбалансированную загрузку клиентов и сервера, но при этом затрудняется сопровождение приложений.
Создание архитектуры клиент-сервер возможно и на основе многотерминальной системы. В этом случае в многозадачной среде сервера приложений выполняются программы пользователей, а клиентские узлы вырождены и представлены терминалами. Подобная схема информационной системы характерна для UNIX. В настоящее время архитектура клиент-сервер получила признание и широкое .распространение как способ организации приложений для рабочих групп и информационных систем корпоративного уровня. Подобная организация работы повышает эффективность выполнения приложений за счет использования возможностей сервера БД, разгрузки сети и обеспечения контроля целостности данных.
Двухуровневые схемы архитектуры клиент-сервер могут привести к некоторым проблемам в сложных информационных приложениях с множеством пользователей и запутанной логикой. Решением этих проблем может стать использование многоуровневой архитектуры.

Многоуровневая архитектура.

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своей классической форме состоит из трех уровней:
>> нижний уровень представляет собой приложения клиентов, выделенные для выполнения функций и логики представлений PS и PL и имеющие программный интерфейс для вызова приложения на среднем уровне;
>> средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL и с которого логика обработки данных DL вызывает операции с базой данных DS;
>> верхний уровень представляет собой удаленный специализированный сервер базы данных, выделенный для услуг обработки данных DS и файловых операций FS (без риска использования хранимых процедур).
Подобную концепцию обработки данных пропагандируют, в частности фирмы
Oracle. Sun, Borland и др.
Трехуровневая архитектура позволяет еще больше сбалансировать нагрузку на разные узлы и сеть, а также способствует специализации инструментов для разработки приложений и устраняет недостатки двухуровневой модели клиент-сервер.
Централизация логики приложения упрощает администрирование и сопровожде¬ние. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистам узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейса, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов. С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной. Продукты для трехзвенной архитектуры, так называемые мониторы транзакций, являются относительно новыми. Эти инструменты в основном ориентирован на среду UNIX, однако прикладные серверы можно cтроить на базе Qicrosoft\Windows NT с использованием вызова удалённых процедур для организации связи клиентов с сервером. На практике в локальной сети могут использоваться
смешанные архитектуры (двухуровневые и трёхуровневые)
с одним и тем же сервером БД. С учетом глобальных связей архитектура может иметь больше трех звеньев. В настоящее время появились новые инструментальные средства для гибкой сегментации приложений клиент-сервер по различным узлам сети.
Таким образом, многоуровневая архитектура распределенных приложений позволяет повысить эффективность работы корпоративной информационной системы и оптимизировать распределение ее программно-аппаратных ресурсов. Но пока на российском рынке по-прежнему доминирует архитектура клиент-сервер.

Интернет/интранет-технологии.

В развитии технологии Интернет/интранет основной акцент пока что делается на разработке инструментальных программных средств. В то же время наблюдается отсутствие развитых средств разработки приложений, работающих с базами данных. Компромиссным решением для создания удобных н простых в использовании и сопровождении информационных систем, эффективно работающих с базами данных, стало объединение Интернет/интранет-технологии с многоуровневой архитектурой. При этом структура информационного приложения приобретает следующий вид: браузер - сервер приложений - сервер баз данных - сервер динамических страниц - web-сервер.
Благодаря интеграции Интернет/интранет технологий и архитектуры клиент-сервер процесс внедрения и сопровождения корпоративной информационной системы существенно упрощается при сохранении достаточно высокой эффективности и простоты совместного использования информации.
Области применения и примеры реализации информационных систем.
В последние несколько лет компьютер стал неотъемлемой частью управленческой системы предприятий. Однако современный подход к управлению предполагает еще и вложение денег в информационные технологии. Причем чем крупнее предприятие, тем больше должны быть подобные вложения.
Благодаря стремительному развитию информационных технологий наблюдается расширение области их применения. Если раньше чуть ли не единственной областью, в которой применялись информационные системы, была автоматизация бухгалтерского учета, то сейчас наблюдается внедрение информационных технологий во множество других областей. Эффективное использование корпоративных информационных систем позволяет делать более точные прогнозы н избегать возможных ошибок в управлении.
Из любых данных и отчетов о работе предприятия можно извлечь массу полезных сведений. И информационные системы как раз и позволяют извлекать максимум пользы из всей имеющейся в компании информационных технологий - современный бизнес крайне чувствителен к ошибкам в управлении, и для принятия грамотного управленческого решения в условиях неопределенности и риска необходимо постоянно держать под контролем различные аспекты финансово-хозяйственной деятельности предприятия (независимо
от профиля его деятельности). Поэтому можно вполне обоснованно утверждать, что в жесткой конкурентной борьбе большие шансы на победу имеет предприятие, использующее в управлении современные информационные технологии.
Рассмотрим наиболее важные задачи, решаемые с помощью специальных программных средств.
Бухгалтерский учет.
Это классическая область применения информационных технологий и наиболее часто реализуемая на сегодняшний день задача. Такое положение вполне объяснимо. Во-первых, ошибка бухгалтера может стоить очень дорого, поэтому очевидна выгода использования возможностей автоматизации бухгалтерии. Во-вторых, задача бухгалтерского учета довольно легко формализуется, так что разработка систем автоматизации бухгалтерского учета не представляет технически сложной проблемы.
ПРИМЕЧАНИЕ
Тем не менее разработка систем автоматизации бухгалтерского учета является весь¬ма трудоемкой. Это связано с тем, что к системам бухгалтерского учета предъявляются повышенные требования в отношении надежности и максимальной простоты и удобства в эксплуатации.
Управление финансовыми потоками.
Внедрение информационных технологий в управление финансовыми потоками также обусловлено критичностью этой области управления предприятия к ошибкам. Неправильно построив систему расчетов с поставщиками и потребителями, можно спровоцировать кризис наличности даже при налаженной сети закупки, сбыта и хоро¬шем маркетинге. И наоборот, точно просчитанные и жестко контролируемые условия финансовых расчетов могут существенно увеличить оборотные средства фирмы.
Управление складом, ассортиментом, закупками.
Далее, можно автоматизировать процесс анализа движения товара, тем самым отследив и зафиксировав те двадцать процентов ассортимента, которые приносят восемьдесят процентов прибыли. Это же позволит ответить на главный вопрос - как получать максимальную прибыль при постоянной нехватке средств? «Заморозить» оборотные средства в чрезмерном складском запасе - самый простой способ сделать любое предприятие, производственное или торговое, потенциальным инвалидом. Можно просмотреть перспективный товар, вовремя не вло¬жив в него деньги.
Управление производственным процессом.
Управление производственным процессом представляет собой очень трудоёмкую задачу. Основными механизмами здесь являются планирование и оптимальное управление производственным процессом. Автоматизированное решение подобной задачи дает возможность грамотно планировать, учитывать затраты, проводить техническую подготовку производства, оперативно управлять процессом выпуска продукции в соответствии с производственной программой и технологией. Очевидно, что чем крупнее производство, тем большее число бизнес-процессов участвует в создании прибыли, а значит, использование информационных систем жизненно необходимо.
Управление маркетингом.
Управление маркетингом подразумевает сбор и анализ данных о фирмах-конкурентах, их продукции и ценовой политике, а также моделирование параметров внешнего окружения для определения оптимального уровня цен, прогнозирования прибыли и планирования рекламных кампаний. Решение большинства этих задач могут быть формализованы и представлены в виде информационной системы, позволяющей существенно повысить эффективность управления маркетингом.
Документооборот.
Документооборот является очень важным процессом деятельности любого предприятия. Хорошо отлаженная система учетного документооборота отражает реально происходящую на предприятии текущую производственную деятельность и дает управленцам возможность воздействовать на нее. Поэтому автоматизация документооборота позволяет повысить эффективность управления.
Оперативное управление предприятием.
Информационная система, решающая задачи оперативного управления предприятием, строится на основе базы данных, в которой фиксируется вся возможная информация о предприятии. Такая информационная система является инструментом для управления бизнесом и обычно называется корпоративной информационной системой.
Информационная система оперативного управления включает в себя массу программных решений автоматизации бизнес-процессов, имеющих место на конкретном предприятии. Одно из наиболее важных требований, предъявляемых к таким информационным системам - гибкость, способность к адаптации и дальнейшему развитию.
Предоставление информации о фирме.
Активное развитие сети Интернет привело к необходимости создания корпоративных серверов для предоставления различного рода информации о предприятии. Практически каждое уважающее себя предприятие сейчас имеет свой web-сервер. Web-сервер предприятия решает ряд задач, из которых можно выделить две основные:
>> создание имиджа предприятия;
>> максимальная разгрузка справочной службы компании путем предоставления потенциальным и уже существующим абонентам возможности получения необходимой информации о фирме, предлагаемых товарах, услугах и ценах. Кроме того, использование web-технологий открывает широкие перспективы для электронной коммерции и обслуживания покупателей через Интернет.

ГЛАВА 2. Жизненный цикл информационных систем.

Разработка корпоративной информационной системы, как правило, выполняется для вполне определенного предприятия. Особенности предметной деятельности предприятия, безусловно, будут оказывать влияние на структуру информационной системы. Но в то же время структуры разных предприятий в целом похожи между собой. Каждая организация, независимо от рода ее деятельности, состоит из ряда подразделений, непосредственно осуществляющих тот или иной вид деятельности компании. И эта ситуация справедлива практически для всех организаций, каким бы видом деятельности они ни занимались.
Таким образом, любую организацию можно рассматривать как совокупность взаимодействующих элементов (подразделений), каждый из которых может иметь свою, достаточно сложную, структуру. Взаимосвязи между подразделениями тоже достаточно сложны. В общем случае можно выделить три вида связей между подразделениями предприятия:
>> функциональные связи - каждое подразделение выполняет определенные виды работ в рамках единого бизнес-процесса;
>> информационные- связи - подразделения обмениваются информацией
>> внешние связи некоторые подразделения взаимодействуют с внешними системами, причем их взаимодействие также может быть, как информационным,
так и функциональным. Общность структуры разных предприятий позволяет сформулировать некоторые единые принципы построения корпоративных информационных систем. В общем случае процесс разработки информационной системы может быть рассмотрен с двух точек зрения:
>> по содержанию действий разработчиков (групп разработчиков). В данном случае рассматривается статический аспект процесса разработки, описываемый в терминах основных потоков работ: исполнители, действия, последовательность действий и т. п.;
>> по времени, или по стадиям жизненного цикла разрабатываемой системы. В данном случае рассматривается динамическая организация процесса разработки, описываемая в терминах циклов, стадий, итераций и этапов.
Общие сведения об управлении проектами.
Информационная система предприятия разрабатывается как некоторый проект. Многие особенности управления проектами и фазы разработки проекта (фазы жизненного цикла) являются общими, не зависящими не только от предметной области, но и от характера проекта (неважно, инженерный это или экономический). Поэтому имеет смысл вначале рассмотреть ряд общих вопросов управ¬ления проектами.
Понятие проекта.
Проект - это ограниченное по времени целенаправленное изменение отдельной системы с изначально четко определенным и целями, достижение которых определяет завершение проекта, а также с установленными требованиями к срокам, результатам, риску, рамкам расходования средств и ресурсов и к организационной структуре.
ПРИМЕЧАНИЕ
Обычно для сложного понятия {каким, в частности, является понятие проекта) трудно дать однозначную формулировку, которая полностью охватывает все признаки вводимого понятия. Поэтому приведенное определение не претендует на единственность и полноту.
Можно выделить следующие основные отличительные признаки проекта как объекта
управления:
>> изменчивость - целенаправленный перевод системы из существующего в некоторое желаемое состояние, описываемое в терминах целей проекта;
>> ограниченность конечной цели;
>> ограниченность продолжительности;
>> ограниченность бюджета;
>> ограниченность требуемых ресурсов;
>> новизна для предприятия, для которого реализуется проект;
>> комплексность - наличие большого числа факторов, прямо пли косвенно влияющих на прогресс и результаты проекта;
>> правовое и организационное обеспечение - создание специфической организационной структуры па время реализации проекта.
Рассматривая планирование проектов и управление ими, необходимо четко осознавать, что речь идет об управлении неким динамическим объектом. поэтому си
стема управления проектом должна быть достаточно гибкой, чтобы допускать возможность модификации без глобальных изменений в рабочей программе. В системном плане проект может быть представлен «черным ящиком», входом которого являются технические требования и условия финансирования, а итогом работы - достижение требуемого результата. Выполнение работ обеспечивается наличием необходимых ресурсов:
>> материалов;
>> оборудования;
>> человеческих ресурсов.
Эффективность работ достигается за счет управления процессом реализации проекта, которое обеспечивает распределение ресурсов, координацию выполняемой последовательности работ и компенсацию внутренних и внешних возмущающих воздействий.
С точки зрения теории систем управления проект как объект управления должен быть наблюдаемым и управляемым, то есть выделяются некоторые характеристики, по которым можно постоянно контролировать ход выполнения проекта (свойство наблюдаемости). Кроме того, необходимы механизмы своевременного воздействия на ход реализации проекта (свойство управляемости). Свойство управляемости особенно актуально в условиях неопределенности и изменчивости предметной области, которые нередко сопутствуют проектам по разработке информационных систем (более подробно проблемы получения полного формального описания предметной области будут обсуждаться в конце данной главы). Для обоснования целесообразности и осуществимости проекта, анализа хода его реализации, а также для заключительной оценки степени достижения поставлен¬ных целей проектa и сравнения фактических результатов с запланированными существует ряд характеристик проекта. К важнейшим из них относятся технико-экономические показатели:
>> объем работ;
>> сроки выполнения;
>> себестоимость;
>> экономическая эффективность, обеспечиваемая реализацией проекта;
>> социальная и общественная значимость проекта.
Классификация проектов.
Проекты могут сильно отличаться по сфере приложения, составу, предметной области, масштабам, длительности, составу участников, степени сложности, значимости результатов и т. п. Проекты могут быть классифицированы по самым различным признакам. Отметим основные из них. Класс проекта определяется по составу и структуре проекта. Обычно различают:
>> монопроект (отдельный проект, который может быть любого типа, вида и масштаба);
>> мультипроект (комплексный проект, состоящий из ряда монопроектов и требующий применения многопроектного управления),
Тип проекта определяется по основным сферам деятельности, в которых осуществляется проект. Можно выделить пять основных типов проекта:
>> технический;
>> организационный;
>> экономический;
>> социальный;
>> смешанный.
ПРИМЕЧАНИЕ
Разработка информационных систем относится, скорее всего, к техническим проектам, которые имеют следующие особенности:
>> главная цель проекта четко определена, но отдельные цели должны уточняться по
мере достижения частных результатов;
>> срок завершения и продолжительность проекта определены заранее, желательно их точное соблюдение, однако они также могут корректироваться в зависимости от полученных промежуточных результатов и общего прогресса проекта.
Масштаб проекта определяется по размерам бюджета и количеству участников:
>> мелкие проекты;
>> малые проекты;
>> средние проекты;
>> крупные проекты.
Можно также рассматривать, масштабы проектов в более конкретной форме - отраслевые, корпоративные, ведомственные проекты, проекты одного предпри¬ятия.
Основные фазы проектирования информационной системы
Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда "проекта уже нет". Совокупность
ступеней развития от возникновения идеи до полного завершения проекта принято разделять на фазы (стадии, этапы).
В определении количества фаз и их содержания имеются некоторые отличия, поскольку эти характеристики во многом зависят от условий осуществления конкретного проекта и опыта основных участников. Тем не менее логика и основное содержание процесса разработки информационной системы почти во всех случаях являются общими.
Можно выделить следующие фазы развития информационной системы:
>> формирование концепции;
>> разработка технического задания;
>> проектирование;
>> изготовление;
>> ввод системы в эксплуатацию.
Рассмотрим каждую из них более подробно.
ПРИМЕЧАНИЕ
Вторую и частично третью фазы принято называть фазами системного проектирования, а последние две (иногда сюда включают и фазу проектирования) - фазами реализации.
Концептуальная фаза.
Главным содержанием работ на этой фазе является определение проекта, разработка его концепции, включающая:
>> формирование идеи, постановку целей;
>> формирование ключевой команды проекта;
>> изучение мотивации и требований заказчика и других участников;
>> сбор исходных данных и анализ существующего состояния;
>> определение основных требовании и ограничений, требуемых материальных,
финансовых и трудовых ресурсов;
>> сравнительную оценку альтернатив;
>> представление предложении, их экспертизу и утверждение,
Разработка технического предложения.
Главным содержанием этой фалы является разработка технического предложения
и переговоры с заказчиком о заключении контракта. Общее содержание работ этой
фазы:
>> разработка основного содержания проекта, базовой структуры проема;
>> разработка и утверждение технического задания;
>> планирование, декомпозиция базовой структурной модели проекта;
>> составление сметы и бюджета проекта, определение потребности в ресурсах;
>> разработка календарных планов и укрупненных графиков работ;
>> подписание контракта с заказчиком;
>> ввод в действие средств коммуникации участников проекта и контроля за ходом работ.
Проектирование.
На этой фазе определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов. Характер¬ные работы этой фазы:
>> выполнение базовых проектах работ;
>> разработка частных технических заданий;
>> выполнение концептуального проектирования;
>> составление технических спецификаций и инструкций;
>> представление проектной разработки, экспертиза и утверждение.
Разработка.
На этой фазе производятся координация и оперативный контроль работ по проекту, осуществляется изготовление подсистем, их объединение и тестирование. Основное содержание;
>> выполнение работ по разработке программного обеспечения;
>> выполнение подготовки к внедрению системы;
>> контроль и регулирование основных показателей проекта.
Ввод системы в эксплуатацию.
На этой фазе проводятся испытания, опытная эксплуатация системы в реальных
условиях, ведутся переговоры о результатах выполнения проекта и о возможных
новых контрактах. Основные виды работ:
>> комплексные испытания;
>> подготовка кадров для эксплуатации создаваемой системы;
>> подготовка рабочей документации, сдача системы заказчику и ввод её в эксплуатацию:
>> сопровождение, поддержка, сервисное обслуживание;
>> оценка результатов проекта и подготовка итоговых документов;
>> разрешение конфликтных ситуаций и закрытие работ по проекту;
>> накопление опытных данных последующих проектов, анализ опыта, состояния, определение направлений развития.
ПРИМЕЧАНИЕ
Начальные фазы проекта имеют решающее влияние на достигаемый результат, так как в них принимаются основные решения, определяющие качество информационной системы. При этом обычно 30% вклада в конечный результат проекта вносят фазы концепции и предложения, 20 % - фаза проектирования, 20 % — фаза изготовлений, 30 % — фаза сдачи объекта и завершения проекта.
Кроме того, на обнаружение ошибок, допущенных на стадии системного проектирования, расходуется примерно в два раза больше времени, чем на последующих фазах, а их исправление обходится в пять раз дороже. Поэтому па начальных стадиях проекта разработку следует выполнять особенно тщательно. Наиболее часто на начальных фазах допускаются следующие ошибки:
>> ошибки в определении интересов заказчика;
>> концентрация на маловажных, сторонних интересах;
>> неправильная интерпретация исходной постановки задачи;
>> неправильное или недостаточное понимание деталей;
>> неполнота функциональных спецификаций (системных требований);
>> ошибки в определении требуемых ресурсов и сроков;
>> редкая проверка на согласованность этапов и отсутствие контроля со стороны заказчика (нет привлечения заказчика).
Процессы, протекающие на протяжении жизненного цикла информационной системы
Понятие жизненного цикла является одним из базовых понятий методологии проектирования информационных систем. Жизненный цикл информационной системы представляет собой непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивается в момент полного изъятия ее из эксплуатации.
Существует международный стандарт, регламентирующий жизненный цикл информационных систем - ISO/IEC 12207.
ПРИМЕЧАНИЕ
ISO - International Organization of Standardization (международная организация по стан¬дартизации). IEC - International Bectrotechnical Commission (международная комис¬сия по электротехнике).
Стандарт ISO, IEC 12207 определяет структуру жизненного цикла, содержащую
процессы, действия и задачи, которые должны быть выполнены во время создания
информационной системы. Согласно данному стандарту структура жизненного
цикла основывается на трек группах процессов:
>> основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение);
>> вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, разрешение проблем);
>> организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение).
Рассмотрим каждую из указанных групп более подробно.
Основные процессы жизненного цикла.
Среди основных процессов жизненного цикла наибольшую важность имеют три: разработка, эксплуатация и сопровождение. Каждый процесс характеризуется разделёнными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами.
Разработка.
Разработка информационной системы включает в себя все работы по созданию информационного программного обеспечения и его компонентов в соответствие с заданными требованиями. Разработка информационного программного обеспечения также включает:
>> оформление проектной и эксплуатационной документации;
>> подготовку материалов, необходимых для проведения тестирования разработанных программных продуктов;
>> разработку материалов, необходимых для организации обучения персонала. Разработка является одним из важнейших процессов жизненного цикла информационной системы и, как правило, включает в себя стратегическое планирование, анализ, проектирование и реализацию (программирование).
Эксплуатация.
Эксплуатационные работы можно подразделить на подготовительные и основные.
К подготовительным относятся:
>> конфигурирование базы данных и рабочих мест пользователей;
>> обеспечение пользователей эксплуатационной документацией;
>> обучение персонала.
Основные эксплуатационные работы включают:
>> непосредственно эксплуатацию;
>> локализацию проблем и устранение причин их возникновения;
>> модификацию программного обеспечения;
>> подготовку предложений по совершенствованию системы;
>> развитие и модернизацию системы.
Сопровождение.
Службы технической поддержки играют весьма заметную роль в жизни любой корпоративной информационной системы. Наличие квалифицированного технического обслуживания на этапе эксплуатации информационной системы является необходимым условием для решения поставленных перед ней задач, причем ошибки обслуживающего персонала могут приводить к явным или скрытым финансовым потерям, сопоставимым со стоимостью самой информационной системы.
Основными предварительными действиями при подготовке к организации технического обслуживания информационной системы являются следующие:
>> выделение наиболее ответственных узлов системы и определение для них критичности простоя. Это позволит выделить наиболее критичные составляющие информационной системы и оптимизировать распределение ресурсов для технического обслуживания;
>> определение задач технического обслуживания и их разделение на внутренние (решаемые силами обслуживающего подразделения) и внешние (решаемые специализированными сервисными организациями). Таким образом производится четкое определение круга исполняемых функции и разделение ответственности ;
>> проведение анализа имеющихся внутренних и внешних ресурсов, необходимых для организации технического обслуживания в рамках описанных задач и разделения компетенции. Основные критерии для анализа: наличие гарантии на оборудование, состояние ремонтного фонда, квалификация персонала;
>> подготовка плана организации технического обслуживания, в котором необходимо определить этапы исполняемых действий, сроки их исполнения, затраты на этапах, ответственность исполнителей.
Обеспечение качественного технического обслуживания информационной системы требует привлечения специалистов высокой квалификации, которые в состоянии решать не только каждодневные задачи администрирования, но и быстро восстанавливать работоспособность системы при сбоях.

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

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

Структура жизненного цикла информационной системы.

Полный жизненный цикл информационной системы включает в себя, как правило, стратегическое планирование, анализ, проектирование, реализацию, внедрение и эксплуатацию. В общем случае жизненный цикл можно, в свою очередь, разбить на ряд стадий. В принципе это деление на стадии достаточно произвольно. Мы рассмотрим один из вариантов такого деления, предлагаемый корпорацией Rational Software. Это одна из ведущих фирм на рынке программного обеспечения средств разработки информационных систем (среди которых большой популярностью за-.служенно пользуется универсальное CASE-средство Rational Rose). Согласно методологии, предлагаемой Rational Software, жизненный цикл информационной системы подразделяется на четыре стадии:
>> начало;
>> уточнение;
>> конструирование;
>> переход (передача в эксплуатацию).
Границы каждой стадии определены некоторыми моментами времени, и которые необходимо принимать, определенные критические решения и в которые, следовательно, должны быть достигнуты определенные ключевые цели.
Начальная стадия.
На начальной стадии устанавливается область применения системы и определяются граничные условия. Для этого необходимо идентифицировать все внешние объекты, с которыми должна взаимодействовать разрабатываемая система, и определить характер этого взаимодействия на высоком уровне. На начальной стадии идентифицируются все функциональные возможности системы н производится описание наиболее существенных из них.
Деловое применение включает:
>> критерии успеха разработки;
>> оценку риска;
>> оценку ресурсов, необходимых для выполнения разработки;
>> календарный план с указанием сроков завершения основных этапов.
Стадия уточнения.
На этой стадии проводится анализ прикладной области, разрабатывается архитектурная основа информационной системы. При принятии любых решений, касающихся архитектуры системы, необходимо принимать во внимание всю разрабатываемую систему в целом. Это означает, что необходимо описать большинство функциональных возможностей системы и учесть взаимосвязи между отдельными ее составляющими. В конце стадии уточнения проводится анализ архитектурных решений и способов устранения главных элементов риска, содержащихся в проекте.
Стадия конструирования.
На стадии конструирования разрабатывается законченное изделие, готовое к передаче пользователю. По окончании этой стадии определяется работоспособность разработанного программного обеспечения.
Стадия перехода.
На стадии перехода производится передача разработанного программного обеспечения пользователям. При эксплуатации разработанной системы в реальных условиях часто возникают различного рода проблемы, которые требуют дополнительных работ но внесению корректив в разработанный продукт, Это, как правило, связано с обнаружением ошибок и недоработок. В конце стадии перехода необходимо определить, достигнуты цели разработки
или нет.

Модели жизненного цикла информационной системы.
Моделью жизненного цикла информационной системы будем называть некоторую структуру, определяющую последовательность осуществления процессов, действий и задач, выполняемых на протяжении жизненного цикла информационной системы, а также взаимосвязи между этими процессами, действиями и задачами. В стандарте ISO/TEC 12207 не конкретизируются в деталях методы реализации и выполнения действий и задач, входящих в процессы жизненного цикла информационной системы, а лишь описываются структуры этих процессов. Это вполне понятно, так как регламенты стандарта являются общими для любых моделей жизненного цикла, методологий и технологий разработки. Модель же жизненного цикла зависит от специфики информационной системы и условий, в которых она создается и функционирует. Поэтому не имеет смысл а предлагать какие-либо конкретные модели жизненного цикла и методы разработки информационных систем для общего случая, без привязки к определенной предметной области. К настоящему времени наибольшее распространение получили следующие две основные модели жизненного цикла:
>> каскадная модель, иногда также называемая моделью «водопад» (waterfall);
>> спиральная модель.
Каскадная модель жизненного цикла информационной системы.
Каскадная модель демонстрирует классический подход к разработке различных систем в любых прикладных областях. Для разработки информационных систем данная модель широко использовалась в 70-х и первой половине 80-х годов. Каскадные методы проектирования хорошо описаны в зарубежной и отечественной литературе разных направлений: методических монографиях, стандартах, учебниках. Организация работ по каскадной схеме официально рекомендовалась и широко применялась в различных отраслях. Таким образом, наличие не только теоретических оснований, но и промышленных методик и стандартов, а также использование этих методов в течение десятилетий позволяет называть каскадные методы классическими.
Каскадная модель предусматривает последовательную организацию работ. При этом основной особенностью является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будут полностью завершены все работы на предыдущем этапе. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы раз¬работка могла быть продолжена другой командой разработчиков.
Основные этапы разработки по каскадной модели.
За десятилетия существования модели «водопад» разбиение работ на стадии и
названия этих стадий менялись. Кроме того, наиболее разумные методики и стандарты избегали жесткого и однозначного приписывания определенных работ к конкретным этапам. Тем не менее вес же можно выделить ряд устойчивых этапов.
разработки, практически не зависящих от предметной области:
>> анализ требований заказчика;
>> проектирование;
>> разработка;
>> тестирование и опытная эксплуатация;
>> сдача готового продукта.

На первом этапе проводится исследование проблемы, которая должна быть решена, четко формулируются все требования заказчика. Результатом, получаемым на данном этапе, является техническое задание (задание на разработку), согласованное со всеми заинтересованными сторонами.
На втором этапе разрабатываются проектные решения, удовлетворяющие всем требованиями, сформулированным в техническом задании. Результатом данного этапа является комплект проектной документации, содержащей все необходимые данные для реализации проекта.
Третий этап — реализация проекта. Здесь осуществляется разработка программного обеспечения (кодирование) в соответствии с проектными решениями, полученными на предыдущем этапе. Методы, используемые для реализации, не имеют принципиального значения. Результатом выполнения данного этапа является готовый программный продукт.
На четвертом этапе проводится проверка полученного программного обеспечения на предмет соответствия требованиям, заявленным в техническом задании. Опытная эксплуатация позволяет выявить различного рода скрытые недостатки, проявляющиеся в реальных условиях работы информационной системы. Последний этап - сдача го нового проекта. Главная задача этого этапа — убедить заказчика, что все его требования реализованы в полной мере. Этапы работ в рамках каскадной модели часто также называют частями «проектного цикла» системы. Такое название возникло потому, что этапы состоят из многих итерационных процедур уточнения требований к системе и вариантов проектных решении. Жизненный цикл самой системы существенно сложнее ее и больше. Он может включать в себя произвольное число циклов уточнения, изменения и дополнения уже принятых и реализованных проектных решений. В этих циклах происходит развитие информационной системы и модернизация отдельных ее компонентов.
Основные достоинства каскадной модели.
Каскадная модель имеет ряд положительных сторон, благодаря которым она хо¬рошо зарекомендовала себя при выполнении различного рода инженерных разработок и получила широкое распространение. Рассмотрим основные достоинства модели «водопад»:
>> на каждом этане формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. На заключительных этапах также разрабатывается пользовательская документация, охватывающая нее предусмотренные стандартами виды обеспечения информационной системы: организационное, методическое, информационное, программное, аппаратное;
>> выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения и соответствующие затраты.
Каскадная модель изначально разрабатывалась для решения различного рода инженерных задач и не потеряла своего значения для прикладной области до настоящего времени. Кроме того, каскадный подход хорошо зарекомендовал себя и при построении определенных информационных систем. Имеются в виду системы для которых в самом начале разработки можно достаточно точно и полно сформулировал все требования, с тем чтобы предоставить разработчикам свободу выбора реализации, наилучшей с технической точки зрения. К таким информационным системам, в частности, относятся сложные расчетные системы, системы реального времени. Тем не менее, несмотря на все свои достоинства, каскадная модель имеет ряд недостатков, ограничивающих ее применение при разработке информационных систем. Причем эти недостатки делают ее либо полностью неприменимой, либо приводят к увеличению сроков разработки и стоимости проекта. В настоящее время многие неудачи программных проектов объясняются именно применением последовательного процесса разработки.
Недостатки каскадной модели.
Перечень недостатков каскадной модели при ее использовании для разработки информационных систем достаточно обширен. Вначале просто перечислим их, а затем рассмотрим основные из них более подробно:
>> существенная задержка получения результатов;
>> ошибки и недоработки на любом из этапов выясняются, как правило, на последующих этапах работ, что приводит к необходимости возврата на предыдущие стадии;
>> сложность распараллеливания работ по проекту;
>> чрезмерная информационная перенасыщенность каждого из этапов;
>> сложность управления проектом;
>> высокий уровень риска и ненадежность инвестиций.
Задержка получения результатов обычно считается главным недостатком каскадной схемы. Данный недостаток проявляется в основном в том, что вследствие последовательного подхода к разработке согласование результатов с заинтересованными сторонами производится только после завершения очередного этапа работ. Поэтому может оказаться, что разрабатываемая информационная система не соответствует требованиям пользователей. Причем такие несоответствия могут возникать на любом этапе разработки — искажения могут непреднамеренно вноситься и проектировщиками-аналитиками, и программистами, так как они не обязательно хорошо разбираются в тех предметных областях, для которых производится разработка информационной системы.
Кроме того, используемые при разработке информационной системы модели автоматизируемого объекта, отвечающие критериям внутренней согласованности и полноты, могут в силу различных причин устареть за время разработки (например, из-за внесения изменений в законодательство, колебания курса ва¬лют и т. п.). Это относится и к функциональной модели, и к информационной модели, и к проектам интерфейса пользователя, и к пользовательской документации.
Возврат на более ранние стадии. Данный недостаток каскадной модели в общем-то является одним из проявлений предыдущего. Поэтапная и последовательная работа над проектом может быть следствием то го, что ошибки, допущенные на более ранних этапах, как правило, обнаруживаются только на последующих стадиях работы над проектом. Поэтому, после того как ошибки проявятся, проект возвращается на предыдущий этап, перерабатывается и снова передается на последующую стадию. Это может служить причиной срыва графика работ и усложнения взаимоотношений между группами разработчиков, выполняющих отдельные этапы работы. Самым же неприятным является то, что недоработки предыдущего уровня могут обнаруживаться не сразу на последующем уровне, а позднее (например, на стадии опытной эксплуатации могут проявиться ошибки в описании предметной облас¬ти). Это означает, что часть проекта должна быть возвращена на начальный уровень работы. Вообще, работа может быть возвращена с любого этапа на любой предыдущий этап.
Одной из причин данной ситуации является то, что в качестве экспертов, участвующих в описании предметной области, часто выступают будущие пользователи системы, которые нередко не могут четко сформулировать то, что они хотели бы получить. Кроме того, заказчики и исполнители часто неправильно понимают друг друга вследствие того, что исполнители обычно не являются специалистами в предметной области решаемой задачи, а заказчики далеки от программирования. Сложность параллельного ведения работ. Отмеченные выше проблемы возникают вследствие того, что работа над проектом строится в виде цепочки последовательных шагов. Причем даже в том случае, когда разработку некоторых частей проекта (подсистем) можно вести параллельно, при использовании каскадной схемы распараллеливание работ весьма затруднительно. Сложности параллельного ведения работ связаны с необходимостью постоянного согласования различных частей проекта. Чем сильнее взаимозависимость отдельных частей проекта, тем чаще и тщательнее должна выполняться синхронизация, тем сильнее зависимы друг от друга группы разработчиков. Поэтому преимущества параллельного ведения работ просто теряются. Отсутствие параллелизма негативно сказывается и на организации работы всего коллектива разработчиков. Работа одних групп сдерживается другими. Пока производится анализ предметной области, проектировщики, разработчики и те, кто занимается тестированием и администрированием, почти не имеют работы. Кроме того, при последовательной разработке крайне сложно внести изме¬нения в проект после завершения этапа и передаче проекта на следующую стадию. Так, например, если после передачи проекта на следующий этап группа разработчиков нашла более эффективное решение, оно не может быть использовано. Это связано с тем, что более раннее решение уже, возможно, реализовано и связано с другими частями проекта. Поэтому исключается (или, по крайней мере, существенно затрудняется) доработка проекта после его передачи на следующий этап.
Информационная перенасыщенность.
Проблема информационной перенасыщенности возникает вследствие сильной зависимости между различными группами разработчиков. Данная проблема заключается в том, что при внесении изменений в одну из частей проекта необходимо оповещать всех разработчиков, которые использовали или могли использовать эту часть в своей работе. Когда система состоит из большого количества взаимосвязанных подсистем, то синхронизация внутренней документации становится важной самостоятельной задачей. Причем синхронизация документации на каждую часть системы — это не более чем процесс оповещения групп разработчиков. Самим же разработчикам необ¬ходимо ознакомиться с изменениями и оценить, не сказались ли эти изменения на уже полученных результатах. Все это может потребовать проведения повторного тестирования и даже внесения изменений в уже готовые части проекта. Причем эти изменения, в свою очередь, должны быть отражены во внутренней документации и быть разосланы другим группам разработчиков. Как следствие, объем документации по мере разработки проекта растет очень быстро, так что требуется все больше времени для составления документации и ознакомления с ней. Следует также отметить, что, кроме изучения нового материала, не отпадает и необходимость в изучении старой информации. Это связано с тем, что вполне вероятна ситуация, когда в процессе выполнения разработки изменяется состав группы разработчиков (этот процесс носит название ротации кадров). Новым разработчикам необходима информация о том, что было сделано до них. Причем чем сложнее проект, тем больше времени требуется, чтобы ввести нового разработчика в курс дела.
Сложность управления проектом при использовании каскадной схемы в основном обусловлена строгой последовательностью стадий разработки и наличием сложных взаимосвязей между различными частями проекта. Последовательность разработки проекта приводит к тому, что одни группы разработчиков должны ожидать результатов работы других команд. Поэтому требуется административное вмешательство для того, чтобы согласовать сроки работы и состав передаваемой документации. В случае же обнаружения ошибок в выполненной работе необходим возврат к предыдущим этапам выполнения проекта. Это приводит к дополнительным сложностям в управлении проектом. Разработчики, допустившие просчет или ошибку, вынуждены прервать текущую работу (над новым проектом) и заняться исправлением ошибок. Следствием этого обычно является срыв сроков выполнения как исправляемого, так и нового проектов. Требовать же от команды разработчиков ожидания окончания следующей стадии разработки нерационально, так как приводит к существенным потерям рабочего времени. Упростить взаимодействие между группами разработчиков и уменьшить информационную перенасыщенность документации можно, уменьшая количество связей между отдельными частями проекта. Однако это обычно весьма непросто. Далеко не каждую информационную систему можно разделить на несколько слабо связанных подсистем.
Высокий уровень риска.
Чем сложнее проект, тем больше продолжительность каждого из этапов разработки и тем сложнее взаимосвязи между отдельными частями проекта, количество которых также увеличивается. Причем результаты разработки можно реально увидеть и оценить лишь на этапе тестирования, то есть после завершения анализа, проектирования и разработки — этапов, выполнение которых требует значительного времени и средств. Как уже было отмечено выше, запоздалая оценка создает значительные проблемы при выявлении ошибок анализа и проектирования — требуется возврат проекта на предыдущие стадии и повторение процесса разработки.
Однако возврат на предыдущие стадии может быть связан не только с ошибками, но и с изменениями, произошедшими за время выполнения разработки в предметной области или в требованиях заказчика. Причем возврат проекта вследствие этих причин на доработку не гарантирует, что предметная область снова не изменится к тому моменту, когда будет готова следующая версия проекта. Фактически это означает, что существует вероятность того, что процесс разработки «зациклится» и никогда не дойдет до сдачи в эксплуатацию. Расходы на проект будут постоянно расти, а сроки сдачи готового продукта — постоянно откладываться. Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскадной схеме, имеют повышенный уровень риска. Этот вывод подтверждается практикой: по сведениям консалтинговой компании The Standish Group, в США более 31 % проектов корпоративных информационных систем (IT-проектов) заканчивается неуспехом; почти 53 % IT-проектов завершается с перерасходом бюджета (в среднем на 189 %, то есть почти в два раза); и только 16,2 % проектов укладывается и в срок, и в бюджет.
ПРИМЕЧАНИЕ
Существует еще один серьезный недостаток, присущий каскадной модели разработки, на который также следует обратить внимание. Этот недостаток связан с конфликтом (не всегда явным) между разработчиками, участвующими в выполнении проекта. Этот конфликт обусловлен тем, что возврат части проекта на предыдущую стадию обычно сопровождается поиском причин и виновных. А так как однозначно персонифицировать ответственного за ошибки далеко не всегда возможно, то попытки поиска виноватых могут сильно усложнить отношения в коллективе. Как следствие, в рабочей группе часто ценится не тот руководитель, который имеет высокую квалификацию и больший опыт, а тот, кто умеет «отстоять» своих подчиненных, обеспечить им более удобные условия работы и т, п. В результате появляется опасность снижения и квалификации, и творческого потенциала всей команды. Соответственно, техническое руководство проектом начинает в большей степени подменяться организационным руководством, все более детальной проработкой должностных инструкций и все более формальным исполнением этих инструкций. Тот, кто не умеет организовать работу, обречен бороться за дисциплину. И здесь возникает проблема несовместимости дисциплины и творчества. Чем строже дисциплина, тем менее творческой становится атмосфера в коллективе. И такое положение вещей может привести к тому, что наиболее одаренные кадры со временем покинут коллектив.
Спиральная модель жизненного цикла.
Спиральная модель, в отличие от каскадной, предполагает итерационный процесс разработки информационной системы. При этом возрастает значение начальных этапов жизненного цикла, таких как анализ и проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов.
Итерации.
Каждая итерация представляет собой законченный цикл разработки, приводящий к выпуску внутренней или внешней версии изделия (или подмножества конечного продукта), которое совершенствуется от итерации к итерации, чтобы стать законченной системой. Таким образом, каждым виток спирали соответствует созданию фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали, На каждой итерации углубляются и последовательно конкретизируются детали проекта, в результате чего выбирается обоснованный вариант, который доводится до окончательной реализации.
Использование спиральной модели позволяет осуществлять переход на следующий этап выполнения проекта, не дожидаясь полного завершения работы на текущем - недоделанную работу можно будет выполнить на следующей итерации.
Главная задача каждой итерации — как можно быстрее создать работоспособный
продукт, который можно показать пользователям системы. Таким образом, существенно упрощается процесс внесения уточнений и дополнений в проект.
Преимущества спиральной модели.
Спиральный подход к разработке программного обеспечения позволяет преодолеть большинство недостатков каскадной модели и, кроме того, обеспечивает ряд
дополнительных возможностей, делая процесс разработки более гибким.
Рассмотрим преимущества итерационного подхода более подробно:
>> итерационная разработка существенно упрощает внесение изменений в проект
при изменении требований заказчика;
>> при использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое постепенно. При итерационном подходе интеграция производится фактически непрерывно. Поскольку интеграция
начинается с меньшего количества элементов, то возникает гораздо меньше
проблем при ее проведении (по некоторым оценкам, при использовании каскадной модели разработки интеграция занимает до 40 % всех затрат в конце проекта);
>> уменьшение уровня рисков. Данное преимущество является следствием предыдущего, так как риски обнаруживаются именно во время интеграции. Поэтому уровень рисков максимален в начале разработки проекта. По мере продвижения разработки ожидаемый риск уменьшается. Данное утверждение справедливо при любой модели разработки, однако при использовании спиральной модели уменьшение уровня рисков происходит с наибольшей скоростью. Это связано с тем, что при итерационном подходе интеграция выполняется уже на первой итерации и при выполнении начальных итераций выявляются многие аспекты проекта, такие как пригодность используемых инструментальных средств и ПО, квалификация разработчиков и т. п. Ниже приведены зависимости уровня рисков от времени разработки при использовании каскадного и итерационного подходов;
>> итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие. Например, можно сократить сроки разработки за счет уменьшения функциональности системы пли использовать в качестве составных частей системы продукцию сторонних фирм вместо собственных разработок.
>> итерационный подход упрощает повторное использование компонентов позволяет использовать компонентный подход к программированию — более подробно об этом мы будем говорить в следующей главе). Это обусловлено тем. что гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после проведения нескольких начальных итерации позволяет выявить общие, многократно используемые компоненты, которые на последующих итерациях будут совершенствоваться;
>> спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно могут корректироваться критические параметры эффективности, что при использовании каскадной модели выполняется только перед внедрением системы;
>> итерационный подход позволяет совершенствовать процесс разработки — анализ, проводимый в конце каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации.
Проблемы, возникающие при использовании спиральной модели.
Основная проблема спирального цикла — определение момента перехода на следующий этап. Для её решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Иначе процесс разработки может прекратится в бесконечное совершенствование уже сделанного. При итерационном подходе полезно следовать принципу "лучшее — враг хорошего". Поэтому завершение итерации должно производиться строго в соответствии с планом, даже если не вся запланированная работа закончена.
Планирование работ обычно проводится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

ГЛАВА 3. Методология и технология разработки информационных систем.
Методология создания информационных систем заключается в организации процесса построения информационной системы и обеспечении управления этим процессом для того, чтобы гарантировать выполнение требований как к самой системе, так и к характеристикам процесса разработки.
Основными задачами, решение которых должна обеспечивать методология создания корпоративных информационных систем (с помощью соответствующего набора инструментальных средств), являются следующие:
>> обеспечение создания информационных систем, отвечающих целям и задачам предприятия и соответствующих предъявляемым к ним требованиям по автоматизации деловых процессов;
>> гарантия создания системы с заданными параметрами в течение заданного времени в рамках оговоренного заранее бюджета;
>> простота сопровождения, модификации и расширения системы с целью обеспечения ее соответствия изменяющимся условиям работы предприятия;
>> обеспечение создания корпоративных информационных систем, отвечающих требованиям открытости, переносимости и масштабируемости;
>> возможность использования в создаваемой системе разработанных ранее и применяемых на предприятии средств информационных технологий (программного обеспечения, баз данных, средств вычислительной техники, телекоммуникаций).
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой информационной системы. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла информационных систем.
Основное содержание технологии проектирования составляют технологические инструкции, состоящие из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.
Технология проектирования может быть представлена как совокупность трех составляющих:
>> заданной последовательности выполнения технологических операций проектирования;
>> критериев и правил, используемых для оценки результатов выполнения технологических операций;
>> графических и текстовых средств (нотаций), используемых для описания практикуемой системы.
Каждая технологическая операция должна обеспечиваться следующими материальными и информационными ресурсами:
>> данными, полученными на предыдущей операции (или исходными данными),
представленными в стандартном виде;
>> методическими материалами, инструкциями, нормативами и стандартами;
>> программными и техническими средствами;
>> исполнителями.
Результаты выполнения операции должны представляться в некотором стандартном виде, обеспечивающем их адекватное восприятие при выполнении следующей технологической операции (на которой они будут использоваться в качестве исходных данных).
Можно сформулировать следующий ряд общих требований, которым должна удовлетворять технология проектирования, разработки и сопровождения информационных систем:
>> поддерживать полный жизненный цикл информационной системы;
>> обеспечивать гарантированное достижение целей разработки системы с заданным качеством и в установленное время;
>> обеспечивать возможность разделения крупных проектов на ряд подсистем — декомпозицию проекта на составные части, разрабатываемые группами исполнителей ограниченной численности, с последующей интеграцией составных частей;
ПРИМЕЧАНИЕ
Декомпозиция проекта позволяет повысить эффективность работ. Подсистемы, на которые разбивается проект, должны быть слабо связанны по данным и функциям. Каждая подсистема разрабатывается отдельной группой разработчиков. При этом необходимо обеспечить координацию работ и исключить дублирование результатов, получаемых каждой проектной группой.
>> технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обуслов¬лено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;
>> обеспечивать минимальное время получения работоспособной системы;
ПРИМЕЧАНИЕ
Здесь имеется в виду не реализация информационной системы в целом, а разработка ее отдельных подсистем. Как правило, даже при наличии полностью завершенного проекта внедрение разработанной системы проводится последовательно, по отдельным подсистемам. Реализация же всей системы в сжатые сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации отдельных подсистем в более короткие сроки меньшим числом разработчиков.
>> предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
>> обеспечивать независимость выполняемых проектных решений от средств реализации системы - системы управления базами данных, операционной системы, языка и системы программирования.

Методология RAD - Rapid Application Development.

На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования. Однако по мере возрастания сложности разрабатываемых систем и увеличения запросов пользователей (чему в значительной степени способствовал прогресс в области вычислительной техники, а также появление удобного графического интерфейса пользователя в системном программном обеспечении) потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию целого направления в области программного обеспечения - инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке программного обеспечения средств автоматизации практически всех этапов жизненного цикла информационных систем.
Основные особенности методологии RAD.
Методология разработки информационных систем, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки приложений - RAD (Rapid Application Development). Данная методология охватывает все этапы жизненного цикла современных информационных систем. RAD - это комплекс специальных инструментальных средств быстрой разработки прикладных информационных систем, позволяющих оперировать с определенным набором графических объектов, функционально отображающих отдельные информационные компоненты приложений.
Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах:
>> небольшой команде программистов (обычно от 2 до 10 человек);
>> тщательно проработанный производственный график работ, рассчитанный на
сравнительно короткий срок разработки (от 2 до б мес.);
>> итерационная модель разработки, основанная на тесном взаимодействии с заказчиком - по мере выполнения проекта разработчики уточняют и реализуют в продукте требования, выдвигаемые заказчиком.
При использовании методологии RAD большое значение имеют опыт и профессионализм разработчиков. Группа разработчиков должна состоять из профессионалов, имеющих опыт в анализе, проектировании, программировании и тестировании программного обеспечения.
Основные принципы методологии RAD можно свести к следующему:
>> используется итерационная (спиральная) модель разработки;
>> полное завершение работ на каждом из этапов жизненного цикла не обязательно;
>> в процессе разработки информационной системы необходимо тесное взаимодействие с заказчиком и будущими пользователями;
>> необходимо применение CASE-средств и средств быстрой разработки приложений;
>> необходимо применение средств управления конфигурацией, облегчающих
внесение изменений в проект и сопровождение готовой системы;
>> необходимо использование прототипов, позволяющее полнее выяснить и реализовать потребности конечного пользователя;
>> тестирование и развитие проекта осуществляются одновременно с разработкой;
>> разработка ведется немногочисленной и хорошо управляемой командой профессионалов;
>> необходимы грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
Объектно-ориентированный подход.
Средства RAD дали возможность реализовывать совершенно иную по сравнению с традиционной технологию создания приложений: информационные объекты формируются как некие действующие модели (прототипы), чье функционирование согласовывается с пользователем, а затем разработчик может переходить непосредственно к формированию законченных приложений, не теряя из виду общей картины проектируемой системы. Возможность использования подобного подхода в значительной степени является результатом применения принципов объектно-ориентированного проектирования. Применение объектно-ориентированных методов позволяет преодолеть одну из главных трудностей, возникающих при разработке сложных систем — колоссаль¬ный разрыв между реальным миром (предметной областью описываемой пробле¬мы) и имитирующей средой.
Использование объектно-ориентированных методов позволяет создать описание (модель) предметной области в виде совокупности объектов — сущностей, объ¬единяющих данные и методы обработки этих данных (процедуры). Каждый объект обладает своим собственным поведением и моделирует некоторый объект реального мира. С этой точки зрения объект является вполне осязаемой вещью, которая демонстрирует определенное поведение.
В объектном подходе акцент переносится на конкретные характеристики физической или абстрактной системы, являющейся предметом программного модели¬рования. Объекты обладают целостностью, которая не может быть нарушена. Таким образом, свойства, характеризующие объект и его поведение, остаются неиз¬менными. Объект может только менять состояние, управляться или становиться в определенное отношение к другим объектам.
Широкую известность объектно-ориентированное программирование получило с появлением визуальных средств проектирования, когда было обеспечено слия¬ние (инкапсуляция) данных с процедурами, описывающими поведение реальных объектов, в объекты программ, которые могут быть отображены определенным образом в графической пользовательской среде. Это позволило приступить к созданию программных систем, максимально похожих на реальные, и добиваться наивысшего уровня абстракции. В свою очередь, объектно-ориентированное про¬граммирование позволяет создавать более надежные коды, так как у объектов программ существует точно определенный и жестко контролируемый интерфейс. При разработке приложений с помощью инструментов RAD используется множество готовых объектов, сохраняемых в общедоступном хранилище. Однако обеспечивается и возможность разработки новых объектов. При этом новые объекты могут разрабатываться как на основе существующих, так и «с нуля». Инструментальные средства RAD обладают удобным графическим интерфейсом пользователя и позволяют на основе стандартных объектов формулировать простые приложения без написания кода программы. Это является большим преимуществом RAD, так как в значительной степени сокращает рутинную работу по разработке интерфейсов пользователя (при использовании обычных средств разработка интерфейсов представляет собой достаточно трудоемкую задачу, отнимающую много времени). Высокая скорость разработки интерфейсной части приложений позволяет быстро создавать прототипы и упрощает взаимодействие с конечными пользователями.
Таким образом, инструменты RAD позволяют разработчикам сконцентрировать усилия на сущности реальных деловых процессов предприятия, для которого создается информационная система. В итоге это приводит к повышению качества разрабатываемой системы.
ПРИМЕЧАНИЕ
В данном разделе мы лишь поверхностно рассмотрели особенности и преимущества объектно-ориентированных методов проектирования. Более подробно этот вопрос будет обсуждаться далее.
Визуальное программирование.

Применение принципов объектно-ориентированного программирования позволи¬ло создать принципиально новые средства проектирования приложений, называемые средствами визуального программирования. Визуальные инструменты RAD позволяют создавать сложные графические интерфейсы пользователя вообще без написания кода программы. При этом разработчик может на любом этапе наблюдать то, что закладывается в основу принимаемых решений. Визуальные средства разработки оперируют в первую очередь со стандартными интерфейсными объектами — окнами, списками, текстами, которые легко можно связать с данными из базы данных и отобразить на экране монитора. Другая группа объектов представляет собой стандартные элементы управления — кнопки, переключатели, флажки, меню и т. п., с помощью которых осуществляется управление отображаемыми данными. Все эти объекты могут быть стандартным образом описаны средствами языка, а сами описания сохранены для дальнейшего повторного использования.
В настоящее время существует довольно много различных визуальных средств разработки приложений. Но все они могут быть разделены на две группы — универсальные и специализированные.
Среди универсальных систем визуального программирования сейчас наиболее распространены такие, как Borland Delphi и Visual Basic. Универсальными мы их называем потому, что они не ориентированы на разработку только приложений баз данных — с их помощью могут быть разработаны приложения почти любого типа, в том числе и информационные приложения. Причем программы, разрабатываемые с помощью универсальных систем, могут взаимодействовать практически с любыми системами управления базами данных. Это обеспечивается как использонанием драйверов ODBC или OLE DB, так и применением специализированных средств (компонентов).
Специализированные средства разработки ориентированы только на создание приложений баз данных. Причем, как правило, они привязаны к вполне определенным системам управления балами данных. В качестве примера таких систем можно привести Power Builder фирмы Sybase (естественно, предназначенный для работы с СУБД Sybase Anywhere Server) и Visual FoxPro фирмы Microsoft. Поскольку задачи создания прототипов и разработки пользовательского интерфейса, по существу, слились, программист получил непрерывную обратную связь с конечными пользователями, которые могут не только наблюдать за созданием приложения, но и активно участвовать в нем, корректировать результаты и свои требования. Это также способствует сокращению сроков разработки и является важным психологическим аспектом, который привлекает к RAD все большее число пользователей. Визуальные инструменты RAD позволяют максимально сблизить этапы создания информационных систем: анализ исходных условий, проектирование системы, разработка прототипов и окончательное формирование приложений становятся сходными, так как на каждом этапе разработчики оперируют визуальными объектами.
Событийное программирование.
Лотка приложения, построенного с помощью RAD, является событийно-ориентированной. Это означает следующее: каждый объект, входящий в состав приложения, может генерировать события и реагировать на события, генерируемые другими объектами. Примерами событий могут быть: открытие и закрытие окон, нажатие кнопки, нажатие клавиши клавиатуры, движение мыши, изменение данных в базе данных и т. п.
Разработчик реализует логику приложения путем определения обработчика каждого события — процедуры, выполняемой объектом при наступлении соответствующий события. Например, обработчик события «нажатие кнопки» может открыть диалоговое окно. Таким образом, управление объектами осуществляется с помо¬щью событий.
Обработчики событий, связанных с управлением базой данных (DELETE, INSERT, UPD ATE), могут реализовываться в виде триггеров на клиентском или серверном узле. Такие обработчики позволяют обеспечить ссылочную целостность базы дан¬ных при операциях удаления, вставки и обновления, а также автоматическую генерацию первичных ключей.
Фазы жизненного цикла в рамках методологии RAD.
При использовании методологии быстрой разработки приложений жизненный
инк ч информационной системы состоит из четырех фаз:
>> фаза анализа и планирования требований;
>> фаза проектирования;
>> фаза построения;
>> фаза внедрения.
Рассмотрим каждую из них более подробно.
Фаза анализа и планирования требований.
На данной фазе выполняются следующие работы:
>> определяются функции, которые должна выполнять разрабатываемая информационная система;
>> определяются наиболее приоритетные функции, требующие разработки в первую очередь;
>> проводится описание информационных потребностей;
ПРИМЕЧАНИЕ
Определение указанных выше требований выполняется совместно будущими пользователями системы и разработчиками.
>> ограничивается масштаб проекта;
>> определяются временные рамки для каждой из последующих фаз;
>> в заключение, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на имеющихся аппаратных и программных средствах.
Если реализация проекта принципиально возможна, то результатом фазы анализа и планирования требований будет список функций разрабатываемой информационной системы с указанием их приоритетов и предварительные функциональные и информационные модели системы.
Фаза проектирования.
На фазе проектирования необходимым инструментом являются CASE-средства, используемые для быстрого получения работающих прототипов приложений.
ПРИМЕЧАНИЕ
Термин CASE (Computer Aided Software/System Engineering) используется в настоя¬щее время в весьма широком смысле. Первоначальное значение термина CASE ограничивалось лишь вопросами автоматизации разработки программного обеспечения. Однако в дальнейшем значение этого термина расширилось и приобрело новый смысл, охватывающий процесс разработки сложных информационных систем в целом. Теперь под термином "CASE-средства" понимаются программные средства, поддерживающие процессы создания и сопровождения информационных систем, включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. Подробному рассмотрению CASE-технологий в данной книге посвящена глава 6 «Проектирование структуры базы данных».
Прототипы, созданные с помощью CASE-средств, анализируются пользователями, которые уточняют и дополняют те требования к системе, которые не были выявлены на предыдущей фазе. Таким образом, на данной фазе также необходимо участие будущих пользователей в техническом проектировании системы.
ПРИМЕЧАНИЕ
Для построения всех моделей и прототипов должны быть использованы именно те CASE-средства, которые будут затем применяться при построении системы. Данное требование связано с тем, что при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.
Далее на этой фазе проводится анализ и при необходимости корректировка функциональной модели системы. Детально рассматривается каждый процесс системы.
При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог или отчет (это позволяет устранить неясности или неоднозначности). Затем определяются требования разграничения доступа к данным. После детального рассмотрения процессов определяется количество функциональных элементов разрабатываемой системы. Это позволяет разделить информационную систему на ряд подсистем, каждая из которых реализуется одной командой разработчиков за приемлемое для RAD-проектов время (порядка полутора месяцев). С использованием CASE-средств проект распределяется между различными командами — делится.
Функциональная модель.
На этой же фазе происходит определение набора необходимой документации. Результатами данной фазы являются;
>> общая информационная модель системы;
>> функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
>> точно определенные с помощью CASE-средства интерфейсы между автономно
разрабатываемыми подсистемами;
>> построенные прототипы экранов, диалогов и отчетов.
ПРИМЕЧАНИЕ
Одной из особенностей применения методологии RAD на данной фазе является то, что каждый созданный прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация. (При традиционном подходе использовались средства прототипирования, не предназначенные для построения реальных приложений, поэтому разработанные прототипы не могли быть использованы на последующих фазах и просто «выбрасывались» после того, как выполняли задачу устранения неясностей в проекте.)
Фаза построения.
На фазе построения выполняется собственно быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных ранее моделей, а также требований нефункционального характера. Разработка приложения ведется с использованием визуальных средств программирования. Формирование программного кода частично выполняется с помощью автоматических генераторов кода, входящих в состав CASE-средств. Код генерируется на основе разработанных моделей.
На фазе построения также требуется участие пользователей системы, которые оце¬нивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки. После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы, а именно:
>> определяется необходимость распределения данных;
>> производится анализ использования данных;
>> производится физическое проектирование базы данных;
>> определяются требования к аппаратным ресурсам;
>> определяются способы увеличения производительности;
>> завершается разработка документации проекта.
Результатом данной фазы является готовая информационная система, удовлетворяющая всем требованиям пользователей.
Фаза внедрения.
Фаза внедрения в основном сводится к обучению пользователей разработанной информационной системы. Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, еще на этапе проектирования системы.
ПРИМЕЧАНИЕ
Приведенная схема разработки информационной системы не является универсальной. Вполне возможны различные отклонения от нее. Это связано с зависимостью схемы выполнения проекта от начальных условий, при которых начинается разработка (например, разрабатывается совершенно новая система или на предприятии уже существует некоторая информационная система). Во втором случае существующая система может либо использоваться в качестве прототипа новой системы, либо интегрироваться в новую разработку в качестве одной из подсистем.
Ограничения методологии RAD.
Несмотря на все свои достоинства, методология RAD тем не менее (как, впрочем, и любая другая методология) не может претендовать на универсальность. Ее применение наиболее эффективно при выполнении сравнительно небольших систем, разрабатываемых для вполне определенного предприятия.
При разработке же типовых систем, не являющихся законченным продуктом, а представляющих собой совокупность типовых элементов информационной системы, большое значение имеют такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Это связано с тем, что типовые системы обычно централизованно сопровождаются и могут быть адаптированы к различным программно-аппаратным платформам, системам управления базами данных, коммуникационным средствам, а также интегрировать¬ся с существующими разработками. Поэтому для такого рода проектов необходим высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
Методология RAD неприменима не только для создания типовых информацион¬ных систем, но и для построения сложных расчетных программ, операционных систем или программ управления сложными инженерно-техническими объектами программ, требующих написания большого объема уникального кода. Методология RAD не может быть использована для разработки приложений, в которых интерфейс пользователя является вторичным, то есть отсутствует наглядное определение логики работы системы. Примерами таких приложений могут служить приложения реального времени, драйверы или службы. Совершенно неприемлема методология RAD для разработки систем, от которых зависит безопасность людей, — например, систем управления транспортом или атомных электростанций. Это обусловлено тем, что итеративный подход, являющейся одной из основ RAD, предполагает, что первые версии системы не будут полностью работоспособны, что в данном случае может привести к серьезнейшим катастрофам.

Стандарты и методики.
Одним из важных условий эффективного использования информационных технологий является внедрение корпоративных стандартов. Корпоративные стандарты представляет собой соглашение о единых правилах организации технологии или управления. При этом за основу корпоративных могут приниматься отраслевое, национальные и даже международные стандарты.
Однако высокая динамика развития информационных технологий приводит к быстрому устареванию существующих стандартов и методик разработки информационных систем. Так, например, в связи со значительным прогрессом в области программного обеспечения и средств вычислительной техники наблюдается рост размеров и сложности информационных систем. При этом существенно меняются требования как к основным функциям и сервисным возможностям систем, так и к динамике изменения этих функций. В этих условиях применение классических способов разработки и обеспечения качества информационных систем становиться малоэффективным и не приводит к уровню качества, адекватному реальным требованиям.
Полезны в этом отношении стандарты открытых систем (в первую очередь стандарты на интерфейсы различных видов, включая лингвистические, и на протоколы взаимодействия). Однако разработка систем в новых условиях требует также новых методов проектирования и новой организации проектных работ. Проектирование и методическая поддержка организации разработки информационных систем (включая программное обеспечение (ПО), и базы данных (БД)) традиционно поддерживаются многими стандартами и фирменными методиками. Вместе с тем известно, что требуется адаптивное планирование разработки, в том числе в динамике процесса ее выполнения. Одним из способов адаптивного проектирования является разработка и применение профилей жизненного цикла информационных систем и программного обеспечения. Корпоративные стандарты образуют целостную систему, которая включает три вида стандартов:
>> стандарты на продукты и услуги;
>> стандарты на процессы и технологии;
>> стандарты на формы коллективной деятельности, или управленческие стандарты.
Виды стандартов.
Существующие на сегодняшний день стандарты можно несколько условно разделить на несколько групп по следующим признакам:
>> по предмету стандартизации. К этой группе можно отнести функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию жизненного цикла создания и использования информационных систем и программного обеспечения;
>> по утверждающей организации. Здесь можно выделить официальные международные, официальные национальные или национальные ведомственные стандарты (например, ГОСТы, ANSI, IDEFO/i), стандарты международных консорциумов и комитетов по стандартизации (например, консорциума OMG), стандарты «де-факто» — официально никем не утвержденные, но фактически действующие (например, стандартом «де-факто» долгое время были язык взаимодействия с реляционными базами данных SQL и язык программирования С), фирменные стандарты (например, Microsoft ODBC);
>> по методическому источнику. К этой группе относятся различного рода методические материалы ведущих фирм-разработчиков программного обеспечения, фирм-консультантов, научных центров, консорциумов по стандартизации.
ПРИМЕЧАНИЕ
Необходимо иметь в виду, что, хотя это и не очевидно, в каждую из указанных выше групп и подгрупп входят стандарты, существенно различающиеся по степени обязательности для различных организаций; конкретности и детализации содержащихся требований; открытости и гибкости, а также адаптируемости к конкретным условиям.
Ниже мы рассмотрим следующие стандарты и методики, касающиеся организации жизненного цикла информационных систем и программного обеспечения:
>> методика Oracle CDM (Custom Development Method) no разработке прикладных информационных систем под заказ;
>> международный стандарт ISO/IEC 12207:1995-08-01 на организацию жизненного цикла продуктов программного обеспечения;
>> отечественный комплекс стандартов ГОСТ 34.
Поскольку рассматриваемые стандарты представляют собой весьма объемные документы, изложенные на десятках и даже сотнях страниц, то мы рассмотрим их лишь на уровне общей структуры и основных особенностей.
Методика Oracle CDM.
Одним из уже сложившихся направлений деятельности фирмы ORACLE стала разработка методологических основ и производство инструментальных средств для
автоматизации процессов разработки сложных прикладных систем, ориентированных на интенсивное использование баз данных. Методика Oracle CDM является развитием давно разработанной версии Oracle CASE-Method, применяемой в CASE-средстве Oracle CASE (в новых версиях - Designer/2000).
Основу CASE-технологии и инструментальной среды фирмы ORACLE составляют:
>> методология структурного нисходящего проектирования, при которой разработка прикладной системы представляется в виде последовательности четко определенных этапов;
>> поддержка всех этапов жизненного цикла прикладной системы, начиная с самых общих описаний предметной области до получения и сопровождения готового программного продукта;
>> ориентация на реализацию приложений в архитектуре клиент-сервер с использованием всех особенностей современных серверов баз данных, включая декларативные ограничения целостности, хранимые процедуры, триггеры баз данных, и с поддержкой в клиентской части всех современных стандартов и требований к графическому интерфейсу конечного пользователя;
>> наличие централизованной базы данных, репозитария, для хранения спецификаций проекта прикладной системы на всех этапах ее разработки. Такой репозитарий представляет собой базу данных специальной структуры, работающую под управлением СУБД ORACLE;
>> возможность одновременной работы с репозитарием многих пользователей. Такой многопользовательский режим почти автоматически обеспечивается стандартными средствами СУБД ORACLE. Централизованное хранение проекта системы и управление одновременным доступом к нему всех участников разработки поддерживают согласованность действий разработчиков и не допускают ситуацию, когда каждый проектировщик или программист работает со своей версией проекта и модифицирует ее независимо от других;
>> автоматизация последовательного перехода от одного этапа разработки к следующему. Для этого предусмотрены специальные утилиты, с помощью которых можно по спецификациям концептуального уровня (модели предметной области) автоматически получать первоначальный вариант спецификации уровня проектирования (описание структуры базы данных и состава программных модулей, чтобы на его основе после всех необходимых уточнений и дополнений автоматически генерировать готовые к выполнению программы;
>> автоматизация различных стандартных действий по проектированию и реализации приложения: предусматривается генерация многочисленных отчетов по содержимому репозитария, обеспечивающих полное документирование текущей версии системы на всех этапах ее разработки; с помощью специальных процедур предоставляется возможность проверки спецификаций на полноту и непротиворечивость.
Общая структура.
Жизненный цикл формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов, Методика Oracle CDM определяет следующие фазы жизненного цикла информационной системы:
>> стратегия;
>> анализ (формулирование детальных требований к прикладной системе);
>> проектирование (преобразование требований в детальные спецификации системы);
>> реализация (написание и тестирование приложений);
>> внедрение (установка новой прикладной системы, подготовка к началу эксплуатации);
>> эксплуатация (поддержка приложения и слежение за ним, планирование будущих функциональных расширений).
Первый этап связан с моделированием и анализом процессов, описывающих деятельность организации, технологические особенности работы. Целью является построение моделей существующих процессов, выявление их недостатков и возможных источников усовершенствования. Этот этап не является обязательным в случае, когда существующая технология и организационные структуры четко определены, хорошо понятны и не требуют дополнительного изучения и реорганизации.
ПРИМЕЧАНИЕ
Более точным названием первого этапа, вероятно, было бы "Определение требований".
На втором этапе разрабатываются детальные концептуальные модели предметной области, описывающие информационные потребности организации, особенности функционирования и т. п. Результатом являются модели двух типов:
>> информационные, отражающие структуру и общие закономерности предметной области;
>> функциональные, описывающие особенности решаемых задач. На третьей стадии (этапе проектирования) на основании концептуальных моделей вырабатываются технические спецификации будущей прикладной системы - определяются структура и состав базы данных, специфицируется набор программных модулей. Первоначальный вариант проектных спецификаций может быть получен автоматически с помощью специальных утилит па основании данных концептуальных моделей. На этапе реализации создаются программы, отвечающие всем требованиям проектных спецификаций.
ПРИМЕЧАНИЕ
Использование генераторов приложений, входящих в состав DESIGNER/2000, позволяет полностью автоматизировать этот этап, существенно сократить сроки разработки системы и повысить ее качество и надежность.
Методика Oracle CDM выделяет следующие процессы, протекающие на протяжении жизненного цикла информационной системы;
>> определение производственных требований;
>> исследование существующих систем;
>> определение технической архитектуры;
>> проектирование и построение базы данных;
>> проектирование и реализация модулей;
>> конвертирование данных;
>> документирование;
>> тестирование;
>> обучение;
>> переход к новой системе;
>> поддержка и сопровождение.
Процессы состоят из последовательностей задач, задачи разных процессов взаимосвязаны с помощью явных ссылок.
Особенности методики Oracle CDM.
Отметим основные особенности методики Oracle CDM, определяющие область ее
применения и присущие ей ограничения.
>> Степень адаптивности CDM ограничивается тремя моделями жизненного цикла:
> классическая — предусматривает все этапы;
> быстрая разработка — ориентированна на использование инструментов
моделирования и программирования Oracle;
> облегчённый подход — рекомендуется в случае малых проектов и возможности быстро прототипировать приложения.
>> Методика не предусматривает включение дополнительных задач, которые не оговорены в CDM, и их привязку к остальным. Также исключено удаление задачи (и порождаемых ею документов), не предусмотренное пи одной из трех моделей жизненного цикла, и изменение последовательности выполнения задач по сравнению с предложенной.
>> Все модели жизненного цикла являются по сути каскадными. Даже «облегченный подход», несмотря на итерационность выполнения действий по прототипированию, сохраняет общий последовательный и детерминированный порядок выполнения задач.
>> Методика не является обязательной, но может считаться фирменным стандартом. При формальном применений степень обязательности полностью соответствует ограничениям возможностей адаптации.
>> Прикладная система рассматривается в основном как программно-техническая система — например, возможность выполнения организационно-структурных преобразований, практически всегда происходящих при переходе к новой информационной системе, в этой методике отсутствуют.
>> CDM теснейшим образом опирается на использование инструментария Oracle, несмотря на утверждения о простом приспособлении CDM к проектам, в которых используется другой комплект инструментальных средств.
>> Методика Oracle CDM представляет собой вполне конкретный материал, дета¬лизированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах информационных систем с опорой на инструментальные средства и СУБД фирмы Oracle.
Международный стандарт ISO/IEC 12207: 1995-08-01.
Первая редакция ISO 12207 была подготовлена в 1995 г. объединенным техническим комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7, проектирование программного обеспечения».
По определению, ISO 12207 — базовый стандарт процессов жизненного цикла ПО, ориентированный на различные виды ПО и типы проектов автоматизированных систем, в которых ПО является одной из составных частей. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает жизненный цикл от концептуализации идей до завершения проекта. Целесообразность совместного использования стандартов на информационные системы и на ПО обусловливается одним из положений ISO 12207, согласно которому процессы, используемые во время жизненного цикла ПО, должны быть совместимы с процессами, используемыми во время жизненного цикла автоматизированной системы.
Согласно ISO 12207, система — это объединение одного или нескольких процессов, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей или целей.
ПРИМЕЧАНИЕ
В отличие от Oracle COM стандарт ISO 12207 в равной степени ориентирован на организацию действий каждой из двух сторон: поставщика (разработчика) и покупателя (пользователя); он может быть применен и в том случае, когда обе стороны — из одной организации.
Общая структура.
В стандарте ISO 12207 не предусмотрено каких-либо этапов (фаз или стадий) жизненного цикла информационной системы. Данный стандарт определяет лишь ряд процессов, причем по сравнению с Oracle CDM стандарт ISO 12207 состоит из гораздо более крупных обобщенных процессов: приобретение, поставка, разработка и т. п. Несколько утрируя, можно сказать, что один процесс ISO 12207 сопоста¬вим со всеми процессами Oracle CDM вместе взятыми.
Согласно ISO 12207, каждый процесс подразделяется на ряд действий, а каждое действие — на ряд задач.
Очень важной особенностью ISO 12207 по сравнению с CDM является то, что каждый процесс, действие или задача инициируются и выполняются другим про
цессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).
Основные и вспомогательные процессы жизненного цикла.
В стандарте ISO 12207 описаны пять основных процессов жизненного цикла про¬граммного обеспечения:
>> процесс приобретения определяет действия предприятия-покупателя, которое приобретает информационную систему, программный продукт или службу программного обеспечения;
>> процесс поставки определяет действия предприятия-поставщика, которое снаб¬жает покупателя системой, программным продуктом или службой программ¬ного обеспечения;
>> процесс разработки определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт;
>> процесс функционирования определяет действия предприятия-оператора, которое обеспечивает обслуживание системы в целом (а не только программного обеспечения) в процессе ее функционирования в интересах пользователей. В отличие от действий, которые определяются разработчиком в инструкциях по эксплуатации (эта деятельность разработчика предусмотрена во всех трех рассматриваемых стандартах), определяются действия оператора по консультированию пользователей, получению обратной связи и др., которые он планирует сам и берет на себя соответствующие обязанности;
>> процесс сопровождения определяет действия персонала, обеспечивающего со¬провождение программного продукта, то есть управление модификациями программного продукта, поддержку его текущего состояния и функциональной пригодности; сюда же относятся установка программного изделия на вычислительной системе и его удаление.
Кроме основных, стандарт ISO 12207 оговаривает 8 вспомогательных процессов,
которые являются неотъемлемой частью всего жизненного цикла программного
изделия и обеспечивают должное качество проекта программного обеспечения.
К вспомогательным процессам относятся:
>> процесс решения проблем;
>> процесс документирования;
>> процесс управления конфигурацией;
>> процесс обеспечения качества;
>> процесс верификации;
>> процесс аттестации;
>> процесс совместной оценки;
>> процесс аудита.
В стандарте ISO 12207 также определяются четыре организационных процесса:
>> процесс управления;
>> процесс создания инфраструктуры;
>> процесс усовершенствования;
>> процесс обучения.
ПРИМЕЧАНИЕ
Под процессом усовершенствования в стандарте ISO 12207 понимается не усовер¬шенствование информационной системы или программного обеспечения, а улучшение самих процессов приобретения, разработки, обеспечения качества и т. д., реально осуществляемых в организации.
И наконец, в стандарте ISO 12207 определен один особый процесс, называемый процессом адаптации, который определяет основные действия, необходимые для адаптации этого стандарта к условиям конкретного проекта.
Особенности стандарта ISO 12207
Все сказанное выше позволяет сформулировать следующие особенности стандарта ISO 12207.
>> Стандарт ISO 12207 имеет динамический характер, обусловленный способом определения последовательности выполнения процессов и задач, при котором один процесс при необходимости вызывает другой или его часть. Такой характер позволяет реализовать любую модель жизненного цикла.
ПРИМЕЧАНИЕ
Согласно стандарту ISO 12207, модель жизненного цикла — это структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.
>> Стандарт ISO 12207 обеспечивает максимальную степень адаптивности. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с конкретными проектами информационных систем. Эта адаптация сводится к исключению процессов, видов деятельности и задач, неприменимых в конкретном проекте.
ПРИМЕЧАНИЕ
Согласно ISO 12207, добавление уникальных или специфических процессов, действий и задач должно быть оговорено в контракте между сторонами. Причем «контракт» понимается в самом широком смысле — от юридически оформленного документа до неформального соглашения. Это соглашение может быть определено даже единственной стороной — как задача, поставленная самому себе.
>> Стандарт принципиально не содержит описания конкретных методов действий, а тем более — заготовок решений или документации. Он лишь описывает архи
тектуру процессов жизненного цикла программного обеспечения, но не конкретизирует в деталях, как реализовывать или выполнять услуги и задачи, включённые в процессы. Данный стандарт не предписывает имена, форматы или точное содержание получаемой документации. Решения такого типа принимаются сторонами, использующими стандарт.
>> Обеспечение качества разными процессами выполняется с разной предусмотренной степенью организационной независимости контролирующей деятельности вплоть до обязательных требований к полной независимости проверяющею персонала от какой-либо прямой ответственности за проверяемые объекты. В отличие от CDM контроль этого вида предусмотрен на самых ранних шагах разработки, начиная с анализа системных требований посредством их проверок на соответствие потребностям приобретения.
>> Степень обязательности рассматриваемого стандарта следующая: после решения организации о применении ISO 12207 в качестве условия торговых отношений является ее ответственность за указание минимального набора требуемых процессов и задач, которые обеспечивают согласованность с этим стандартом.
>> Стандарт содержит предельно мало описаний, направленных на проектирование базы данных. Это можно считать оправданным, так как разные системы и разные прикладные комплексы программного обеспечения могут не только использовать весьма специфические типы баз данных, но и вообще не использовать базу данных.
Ценность стандарта ISO 12207 в том, что он содержит наборы задач, характеристик качества, критериев оценки и т. п., дающие всесторонний охват проектных ситуаций. Например, при выполнении анализа требований к системе предусматривается, что:
>> рассматривается область применения системы для определения требований, предъявляемых к системе;
>> спецификация требований системы должна описывать функции и возможности системы, области применения системы, организационные требования и требования пользователя, безопасность, защищенность, человеческие факторы, эргономику, связи, операции и требования сопровождения; проектные ограничения и квалификационные требования,
Далее, при выполнении анализа требований к программному обеспечению предусмотрено 11 классов характеристик качества, которые используются позже при обеспечении качества.
При этом разработчик должен установить и документировать в виде требований к программному обеспечению следующие спецификации и характеристики:
>> функциональные и возможные спецификации, включая исполнение, физические характеристики и условия среды эксплуатации, при которых единица программного обеспечения должна быть выполнена;
>> внешние связи (интерфейсы) с единицей программного обеспечения;
>> требования квалификации;
>> спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и вероятностью травмы персонала;
>> спецификации защищенности, включая спецификации, связанные с компрометацией точности информации;
>> человеческие факторы спецификаций по инженерной психологии (эргономике), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и областями, нуждающимися в концентрированном человеческом внимании, которые являются чувствительными к ошибкам человека и обучению;
>> определение данных и требований к базе данных;
>> установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);
>> документацию пользователя;
>> работа пользователя и требования выполнения;
>> требования сервиса пользователя.
ПРИМЕЧАНИЕ
Согласно стандарту IS012207, требование квалификации — это набор критериев или условий (квалификационные требования), которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт как подчиняющийся (удовлетворяющий условиям) его спецификациям и готовый для использования в целевой окружающей среде.
Хотя стандарт не предписывает конкретной модели жизненного цикла или метода разработки, он определяет, что стороны-участники при использовании стандарта ответственны за следующее:
>> выбор модели жизненного цикла для разрабатываемого проекта;
>> адаптацию процессов и задач стандарта к этой модели;
>> выбор и применение методов разработки программного обеспечения;
>> выполнение действий и задач, подходящих для проекта программного обеспечения.
Стандарты комплекса ГОСТ 34.
ГОСТ 34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Объектами стандартизации являются автоматизированные системы различных видов и все виды их компонентов, а не только программное обеспечение и базы данных.
Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично ISO 12207, в нем предусмотрено, что заказчик может разрабатывать автоматизированную систему для себя сам (например, создав для этого специализированное подразделение). Однако формулировки ГОСТ 34 не ориентированы на столь яв
ное и в известном смысле симметричное отражение действий обеих сторон, как это сделано в ISO 12207. Поскольку ГОСТ 34 в основном уделяет внимание содержанию проектных документов, распределение действий между сторонами обычно производится исходя из этого содержания.
Общая структура.
Из всех существующих групп документов будем основываться только на группе 0 "Общие положения" и группе 6 «Создание, функционирование и развитие автоматизированной системы». Наиболее популярными можно считать стандарты ГОСТ 34.601-90 (стадии создания автоматизированной системы), ГОСТ 34.602-89 (техническое задание на создание автоматизированной системы) и методические указания РД 50-34.698-90 (требования к содержанию документов). Стандарты предусматривают стадии и этапы выполнения работ по созданию автоматизированной системы, но не предусматривают сквозных процессов в явном виде.
Согласно ГОСТ 34, разработка автоматизированной системы разбивается на следующие этапы и стадии.
>> Этап формирования требований к автоматизированной системе. Состоит из следующих стадий:
> обследование объекта и обоснование необходимости разработки автоматизированной системы;
> формирование требований заказчика к автоматизированной системе;
> разработка отчета о проделанной работе и заявки на разработку технического задания.
>> Разработка концепции:
> изучение объекта;
> проведение необходимых научно-исследовательских работ;
> разработка вариантов концепции автоматизированной системы, удовлетворяющей требованиям заказчика;
> разработка отчета о проделанной работе.
> Разработка и утверждение технического задания на разработку автоматизированной системы.
>> Разработка эскизного проекта автоматизированной системы:
> разработка предварительных проектных решений по всей системе в целом
и по ее отдельным составляющим;
> разработка документации.
>> Разработка технического проекта:
> разработка проектных решений по всей системе и по ее частям;
> разработка документации на автоматизированную систему и на подсистемы, входящие в ее состав;
> разработка и оформление документации на поставку изделий для комплектования автоматизированной системы и/или технических требований на их разработку;
> разработка заданий на проектирование в смежных частях проекта объекта
автоматизации.
>> Разработка технической документации:
> разработка рабочей документации на систему и ее части;
> разработка и/или адаптация программного обеспечения.
>> Ввод разработанной системы в действие:
> подготовка объекта автоматизации;
> подготовка персонала;
> комплектация автоматизированной системы программными и техническими средствами;
> монтажные работы;
> пуско-наладочные работы;
> предварительные испытания;
> опытная эксплуатация;
> приемочные испытания.
>> Сопровождение:
> выполнение работ в соответствии с гарантийными обязательствами;
> послегарантийное обслуживание.
В ГОСТ 34 приводится описание содержания документов, разрабатываемых на каждом из этапов.
Особенности.
Основными особенностями комплекса стандартов ГОСТ 34 являются следующие:
>> Основной целью разработки комплекса нормативных документов ГОСТ 34 было разрешение противоречий, возникающих при интеграции систем вследствие несогласованности нормативно-технической документации. В 80-х годах действовали следующие комплексы и системы стандартов, устанавливающие требования к различным пилам автоматизированных систем: > единая система стандартов автоматизированных систем управления (24-я система) для АСУ, ОАСУ, АСУП, АСУТП и других организационно-экономических систем;
> комплекс стандартов системы 23501, распространявшихся на системы автоматизированного проектирования (САПР);
> четвертая группа 14-й системы стандартов, распространяющаяся на автоматизированные системы технологической подготовки производства (АСТПП). Практика применения стандартов на ОАСУ, АСУП, АСУТП, САПР, АСТПП показала, что, по существу, в них применяется единая система понятий и есть
много общих объектов стандартизации, однако требования стандартов не согласованы между собой, имеются различия по составу и содержанию работ, различия в обозначении, составе, содержании и оформлении документов. В этих условиях было решено выработать одну обобщенную понятийную и терминологическую систему, общую схему разработки, общий набор документов и их содержания и определить их как обязательные для всех автоматизированных систем.
Таким образом, комплекс стандартов ГОСТ 34 более близок к схемам конкретных методик, чем к стандартам типа ISO 12207.
>> Степень адаптивности стандарта ГОСТ 34 определяется следующими возможностями:
> возможностью отказаться от этапа эскизного проектирования и объединять
этапы разработки технического проекта и рабочей документации;
> возможностью отказываться от некоторых стадий разработки, а также объединять большинство документов и их разделов;
> возможностью вводить дополнительные документы, разделы документов и работы;
> возможностью динамически создавать частные технические задания, что позволяет достаточно гибко формировать жизненный цикл автоматизированной системы.
Стадии и этапы, выполняемые организациями — участниками работ по созданию автоматизированной системы, устанавливаются в договорах и техничес¬ком задании, что близко к подходу ISO 12207.
>> Несмотря на достаточно большую гибкость формирования жизненного цикла, предопределенные документами ГОСТ 34 этапы и стадии разработки на практике ориентируют разработчиков на каскадную схему жизненного цикла.
>> Документы ГОСТ 34 определяют единую терминологию и вполне разумно классифицируют работы по созданию автоматизированной системы и документы, разрабатываемые в результате этих работ. Благодаря ГОСТ 34 упрощается интеграция разных систем и повышается качество систем, полученных в результате интеграции.
>> Обеспечение качества согласно ГОСТ 34 определяется в техническом задании на автоматизированную систему и производится на любых последующих этапах и с любой степенью независимости экспертизы. В последовательности этапов разработки эти экспертизы располагаются несколько позже, чем в ISO 12207.
>> Степень обязательности ГОСТ 34: полная обязательность отсутствует, материалы ГОСТ 34, по сути, являются методической поддержкой. Причем эта поддержка в значительной степени ориентирована на заказчика: в стандарте имеется набор требований к содержанию технического задания и проведению испытаний разработанной системы.
>> Ключевым документом взаимодействия сторон является техническое задание (ТЗ) на создание автоматизированной системы. ТЗ является основным исходным документом для создания автоматизированной системы нее приемки, оно определяет важнейшие точки взаимодействия заказчика и разработчика.
ПРИМЕЧАНИЕ
Техническое задание разрабатывается организацией-разработчиком (по ГОСТ 34.602-89); но формально техническое задание выдает разработчику заказчик (по РД 50-680-88).
Согласно ГОСТ 34, автоматизированная система состоит из программно-технических, программно-методических комплексов и отдельных компонентов организационного, технического, программного и информационного обеспечения. Документы комплекса ГОСТ 34 определяют автоматизированную систему следующим образом:
>> «организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т. д.) или их сочетаниях» - РД 50-680-88;
>> «система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций» - ГОСТ 34.003-90.
Таким образом, автоматизированная система рассматривается в первую очередь как персонал, принимающий решения и выполняющий другие управляющие действия, поддержанный организационно-техническими средствами.
Выводы.
>> Ни один из рассмотренных стандартов не является универсальным, описывающим все виды действий и задач; выполняемых в конкретных проектах. Такая ситуация, вероятно, объективно неизбежна для любых достаточно конкретных стандартов и фирменных методик.
>> Наиболее широкий набор процессов, действий и задач, охватывающий большинство возможных ситуаций при максимальной адаптируемости, содержится в стандарте ISO 12207. Он может служить примером хорошо организованного стандарта, содержащего минимум ограничений и конкретных рекомендаций. При использовании ISO 12207 детальные определения процессов, форм документов и т. п. целесообразно выносить в различные функциональные стандарты, ведомственные нормативные документы или фирменные методики, которые могут быть использованы или не использованы в каждом конкретном проекте.
>> ГОСТ 34 достаточно полно и фундаментально определяет.
> систему как объект создания или развития;
> аналитические и при необходимости исследовательские работы, направленные на разработку обоснованной концепции автоматизированной системы;
> виды обеспечения системы, которые, в общем, согласуются с требованиями ISO 12207 к системе и программному обеспечению.
Материалы ГОСТ 34 почти так же, как и ISO 12207, а может быть, еще более четко определяют, что автоматизированная система — это в первую очередь люди, которые выполняют свои функции с помощью информационных технологий.
>> ГОСТ 34 благодаря своей комплексной ориентации на систему и обеспечению единой терминологии позволяет избежать ситуаций, в которых разработчики разных профессий (например, финансовые аналитики и проектировщики баз данных) «говорят на разных языках», от чего в итоге страдают цельность и глубина проработки проекта.
>> ГОСТ-34 и CDM в первую очередь ориентированы на действия по созданию и поддержке систем ISO 12207 — на приобретение и эксплуатацию систем (при этом разработка является процессом, логически вытекающим из приобретения).

Профили открытых информационных систем.
Создание, сопровождение и развитие современных сложных информационных систем базируется на методологии построения таких систем как открытых. Открытые информационные системы создаются в процессе информатизации всех основных сфер современного общества: органов государственного управления, финансово-кредитной сферы, информационного обслуживания предпринимательской деятельности, производственной сферы, науки, образования. Развитие и использование открытых информационных систем неразрывно связаны с применением стандартов на основе методологии функциональной стандартизации информационных технологий.
Понятие профиля информационной системы.
При создании и развитии сложных, распределенных, тиражируемых информационных систем требуется гибкое формирование и применение гармонизированных совокупностей базовых стандартов и нормативных документов разного уровня, выделение в них требований и рекомендаций, необходимых для реализации заданных функций системы. Для унификации и регламентирования такие совокупности базовых стандартов должны адаптироваться и конкретизироваться применительно к определенным классам проектов, функций, процессов и компонентов системы. В связи с этим выделилось и сформировалось понятие профиля информационной системы как основного инструмента функциональной стандартизации.
Профиль - это совокупность нескольких (или подмножество одного) базовых стандартов с четко определенными и гармонизированными подмножествами обязательных и факультативных возможностей, предназначенная для реализации заданной функции или группы функций.
Профиль формируется исходя из функциональных характеристик объекта стандартизации, В профиле выделяются и устанавливаются допустимые возможности и значения параметров каждого базового стандарта и/или нормативного документа, входящего в профиль.
Профиль не должен противоречить использованным в нем базовым стандартам и нормативным документам. Он должен применять выбранные из альтернативных вариантов необязательные возможности и значения параметров в пределах допустимых.
На базе одной совокупности базовых стандартов могут формироваться и утверждаться различные профили для разных проектов информационных систем. Ограничения базовых документов профиля и их согласованность, проведенная разработчиками профиля, должны обеспечивать качество, совместимость и корректное взаимодействие отдельных компонентов системы, соответствующих профилю, в заданной области его применения.
Базовые стандарты и профили в зависимости от проблемно-ориентированной области применения информационных систем могут использоваться как непосредственные директивные, руководящие или рекомендательные документы, а также как нормативная база, необходимая при выборе или разработке средств автоматизации технологических этапов или процессов создания, сопровождения и развития информационных систем. Обычно рассматривают две группы профилей:
>> регламентирующие архитектуру и структуру информационной системы;
>> регламентирующие процессы проектирования, разработки, применения, сопровождения и развития системы.
В зависимости от области применения профили могут иметь разные категории и соответственно разные статусы утверждения:
>> профили конкретной информационной системы, определяющие стандартней
ванные проектные решения в пределах данного проекта;
>> профили информационной системы, предназначенные для решения некоторого класса прикладных задач.
Профили информационных систем унифицируют и регламентируют только часть требований характеристик, показателей качества объектов и процессов, выделенных и формализованных на базе стандартов и нормативных документов. Другая часть функциональных и технических характеристик системы определяется заказчиками и разработчиками творчески, без учета положений нормативных документов.
Принципы формирования профиля информационной системы.
Использование профилей информационных систем призвано решить следующие
задачи:
>> снижение трудоемкости проектов;
>> повышение качества компонентов информационной системы;
>> обеспечение расширяемости и масштабируемости разрабатываемых систем;
>> обеспечение возможности функциональной интеграции в информационную систему задач, которые раньше решались раздельно;
>> обеспечение переносимости прикладного программного обеспечения. В зависимости от того, какие из указанных задач являются наиболее приоритетными, производится выбор стандартов и документов для формирования профиля. Актуальность использования профилей информационных систем обусловлена современным состоянием стандартизации информационных технологий, которое характеризуется следующими особенностями:
>> существует множество международных и национальных стандартов, которые не полностью и неравномерно удовлетворяют потребности в стандартизации объектов и процессов создания и применения сложных информационных систем;
>> длительные сроки разработки, согласования и утверждения международных и национальных стандартов приводят к их консерватизму и хроническому отставанию от современных информационных технологий;
>> функциональными стандартами поддержаны и регламентированы только самые простые объекты и рутинные, массовые процессы: телекоммуникации, программирование, документирование программ и данных. Наиболее сложные и творческие процессы создания и развития крупных распределенных информационных систем — системный анализ и проектирование, интеграция компонентов и систем, испытания и сертификация — почти не поддержаны требованиями и рекомендациями стандартов из-за трудности их формализации и унификации;
>> совершенствование и согласование нормативных и методических документов в ряде случаев позволяют создать на их основе национальные и международные стандарты.
Подходы к формированию профилей информационных систем могут быть различными. В международной функциональной стандартизации информационных технологий принято довольно жесткое понятие профиля. Считается, что его основой могут быть только международные и национальные, утвержденные стандарты. Использование стандартов де-факто и нормативных документов фирм не допускается. При таком подходе затруднены унификация, регламентирование и параметризация множества конкретных функций и характеристик сложных объектов архитектуры и структуры современных информационных систем. Другой подход к разработке и применению профилей информационных систем состоит в использовании совокупности адаптированных и параметризованных базовых международных и национальных стандартов и открытых спецификаций, отвечающих стандартам де-факто и рекомендации международных консорциумов.
Эталонная модель среды открытых систем (OSE/RM) определяет разделение любой информационной системы на две составляющие: приложения (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют. Между приложениями и средой определяются стандартизованные интерфейсы — Application Program Interface (API), которые являются необходимой частью профилей любой открытой системы. Кроме того, в профилях могут быть определены унифицированные интерфейсы взаимодействия функциональных частей друг с другом и интерфейсы взаимодействия между компонентами среды системы. Спецификации выполняемых функций и интерфейсов взаимодействия могут быть оформлены в виде профилей компонентов системы. Таким образом, профили информационной системы с иерархической структурой могут включать в себя:
>> стандартизованные описания функций, выполняемых данной системой;
>> функции взаимодействия системы с внешней для нее средой;
>> стандартизованные интерфейсы между приложениями и средой информационной системы;
>> профили отдельных функциональных компонентов, входящих в систему. Для эффективного использования конкретного профиля необходимо;
>> выделить объединенные логической связью проблемно-ориентированные области функционирования, где могут применяться стандарты, общие для одной организации или группы организаций;
>> идентифицировать стандарты и нормативные документы, варианты их использования и параметры, которые необходимо включить в профиль;
>> документально зафиксировать участки конкретного профиля, где требуется создание новых стандартов или нормативных документов, и идентифицировать характеристики, которые могут оказаться важными для разработки недостающих стандартов и нормативных документов этого профиля;
>> формализовать профиль в соответствии с его категорией, включая стандарты, различные варианты нормативных документов и дополнительные параметры, которые непосредственно связаны с профилем;
>> опубликовать профиль и/или продвигать его по формальным инстанциям для
дальнейшего распространения.
При использовании профилей важное значение имеет обеспечение проверки корректности их применения путем тестирования, испытаний и сертификации. Для этого требуется создание технологии контроля и тестирования в процессе применения профиля. Данная технология должна поддерживаться совокупностью методик, инструментальных средств, составом и содержанием оформляемых документов на каждом этапе выполнения проекта.
Использование профилей способствует унификации при разработке тестов, проверяющих качество и взаимодействие компонентов проектируемой информационной системы. Профили должны определяться таким образом, чтобы тестирование их реализации можно было проводить по возможности наиболее полно по стандартизованной методике. При этом возможно применение ранее разработанных методик, так как международные стандарты и профили являются основой для создания общепризнанных аттестационных тестов.
Структура профилей информационных систем.
Разработка и применение профилей являются органической частью процессов проектирования, разработки и сопровождения информационных систем. Профили характеризуют каждую конкретную информационную систему на всех стадиях ее жизненного цикла, задавая согласованный набор базовых стандартов, которым должна соответствовать система и ее компоненты.
Стандарты, важные с точки зрения заказчика, должны задаваться в ТЗ на проектирование системы и составлять ее первичный профиль. То, что не задано в ТЗ, первоначально остается на усмотрение разработчика системы, который, руководствуясь требованиями ТЗ, может дополнять и развивать профили системы и впоследствии согласовывать их с заказчиком. Таким образом, профиль конкретной системы не является статичным, он развивается и конкретизируется в процессе проектирования информационной системы и оформляется в составе документации проекта системы.
В профиль конкретной системы включаются спецификации компонентов, разработанных в составе данного проекта, и спецификации использованных готовых программных и аппаратных средств, если эти средства не специфицированы соответствующими стандартами. После завершения проектирования и испытаний системы, в ходе которых проверяется ее соответствие профилю, профиль применяется как основной инструмент сопровождения системы при эксплуатации, модернизации и развитии.
Общая структура профиля информационной системы.
Формирование и применение профилей конкретных информационных систем выполняется на основе использования международных и национальных стандартов, ведомственных нормативных документов, а также стандартов де-факто при условии доступности соответствующих им спецификаций. Для обеспечения корректного применения профилей их описания должны содержать:
>> определение целей использования данного профиля;
>> точное перечисление функций объекта или процесса стандартизации, определяемого данным профилем;
>> формализованные сценарии применения базовых стандартов и спецификаций,
включенных в данный профиль;
>> сводку требований к информационной системе или ее компонентам, определяющих их соответствие профилю, и требований к методам тестирования соответствия;
>> нормативные ссылки на конкретный набор стандартов и других нормативных документов, составляющих профиль, с точным указанием применяемых редакций и ограничений, способных повлиять на достижение корректного взаимодействия объектов стандартизации при использовании данного про¬филя;
>> информационные ссылки на все исходные документы. На стадиях жизненного цикла информационной системы выбираются и затем применяются основные функциональные профили:
>> профиль прикладного программного обеспечения;
>> профиль среды информационной системы;
>> профиль защиты информации в информационной системе;
>> профиль инструментальных средств, встроенных в информационную систему.
Профиль прикладного программного обеспечения.
Прикладное программное обеспечение всегда является проблемно-ориентированным и определяет основные функции информационной системы. Функциональные профили системы должны включать в себя согласованные базовые стандарты. При использовании функциональных профилей информационных систем следует еще иметь в виду согласование этих профилей между собой. Необходимость такого согласования возникает, в частности, при использовании стандартизованных API, в том числе интерфейсов приложений со средой их функционирования и со средствами защиты информации. При согласовании функциональных профилей возможны также уточнения профиля среды системы и профиля встраиваемых инструментальных средств создания, сопровождения и развития прикладного программного обеспечения.
Профиль среды информационной системы.
Профиль среды информационной системы должен определять ее архитектуру в соответствии с выбранной моделью обработки данных.
Стандарты интерфейсов приложений со средой (API) должны быть определены по функциональным областям профилей информационной системы. Декомпозиция структуры среды функционирования системы на составные части, выполняемая на стадии эскизного проектирования, позволяет детализировать профиль среды информационной системы по функциональным областям эталонной модели OSE/RM:
>> область графического пользовательского интерфейса;
>> область реляционных или объектно-ориентированных СУБД (например, стандарт языка SQL-92 и спецификации доступа к разным базам данных);
>> область операционных систем с учетом сетевых функций, выполняемых на уровне операционной системы;
>> область телекоммуникационной среды в части услуг и служб прикладного уровня: электронной почты, доступа к удаленным базам данных, передачи файлов, доступа к файлам и управления файлами.
Профиль среды распределенной системы должен включать стандарты протоколов транспортного уровня, стандарты локальных сетей (например, стандарт Ethernet IEEE 802.3 или стандарт Fast Ethernet IEEE 802.3 и), а также стандарты средств сопряжения проектируемой информационной системы с сетями передачи данных общего назначения.
Выбор аппаратных платформ информационной системы связан с определением их параметров: вычислительной мощности серверов и рабочих станций в соответствии с проектными решениями по разделению функций между клиентами и серверами; степени масштабируемости аппаратных платформ; надежности. Профиль среды должен содержать стандарты, определяющие параметры технических средств и способы их измерения (например, стандартные тесты измерения производительности).
Профиль защиты информации.
Профиль защиты информации должен обеспечивать реализацию политики информационной безопасности, разрабатываемой в соответствии с требуемой категорией безопасности и критериями безопасности, заданными в ТЗ на систему. Построение профиля защиты информации в распределенных системах клиент-сервер методически связано с точным определением компонентов системы, ответственных за те или иные функции, службы и услуги, и средств защиты информации, встроенных в эти компоненты. Функциональная область защиты информации включает в себя следующие функции защиты, реализуемые разными компонентами системы:
>> функции, реализуемые операционной системой;
>> функции защиты от несанкционированного доступа, реализуемые на уровне
программного обеспечения промежуточного слоя;
>> функции управления данными, реализуемые СУБД;
>> функции защиты программных средств, включая средства защиты от вирусов;
>> функции защиты информации при обмене данными в распределенных системах, включая криптографические функции;
>> функции администрирования средств безопасности.
Профиль зашиты информации должен включать указания на методы и средства обнаружения в применяемых аппаратных и программных средствах недекларированных возможностей. Профиль должен также включать указания на методы и средства резервного копирования информации и восстановления информации при отказах и сбоях аппаратуры системы.
Профиль инструментальных средств.
Профиль инструментальных средств, встроенных в информационную систему, должен отражать решения по выбору методологии и технологии создания, сопровождения и развития информационной системы. В этом профиле должны содержаться ссылки на описание выбранных методологии и технологии, выполненное на стадии эскизного проектирования системы.
Состав инструментальных средств определяется на основании решений и нормативных документов об организации сопровождения и развития информационной системы. При этом должны быть учтены правила и порядок, регламентирующие внесение изменений в действующие системы. Функциональная область профиля инструментальных средств, встроенных в систему, охватывает функции централизованного управления и администрирования, связанные с:
>> контролем производительности и корректности функционирования системы
в целом;
>> управлением конфигурацией прикладного программного обеспечения, тиражированием версий;
>> управлением доступом пользователей к ресурсам системы и конфигурацией
ресурсов;
>> перенастройкой приложений в связи с изменениями прикладных функций информационной системы;
>> настройкой пользовательских интерфейсов (генерацией экранных форм и отчетов);
>> ведением баз данных системы;
>> восстановлением работоспособности системы после сбоев и аварий. Дополнительные ресурсы, необходимые для функционирования встроенных инструментальных средств, такие как минимальный и рекомендуемый объем оперативной памяти, размеры требуемого дискового пространства и т. п., должны быть учтены в разделе проекта, относящемся к среде информационной системы. Выбор инструментальных средств, встроенных в систему, должен производиться в соответствии с требованиями профиля среды. Ссылки на соответствующие стандарты, входящие в профиль среды, должны содержаться и в профиле инструментальных средств.
В этом профиле должны также содержаться ссылки на требования к средствам тестирования, которые необходимы для процессов сопровождения и развития системы и должны быть в нее встроены. В число встроенных в информационную систему средств тестирования должны входить средства функционального тестирования приложений, тестирования интерфейсов, системного тестирования и тестирования серверов/клиентов при максимальной нагрузке.

ГЛАВА 4. Реляционные базы данных.
По мере развития вычислительной техники изменялись и основные направления ее использования. Первоначально средства вычислительной техники подразумевалось использовать для выполнения различного рода математических вычислений, которые невозможно провести «вручную» за разумное время. Развитие этого направления привело к развитию разделов математики, связанных с численными методами вычислений, и к появлению алгоритмических языков, удобных для реализации алгоритмов численных методов и ориентированных на выполнение математических расчетов (одним из наиболее популярных языков программирования такого типа является Fortran, до сих пор широко применяющийся для научных расчетов).
Затем, по мере увеличения возможностей и уменьшения стоимости вычислительных средств, получило развитие второе направление, связанное с использованием средств вычислительной техники в автоматизированных информационных системах. Здесь вычислительные возможности компьютеров отходят на второй план — основные функции вычислительных средств в информационных системах состоят в поддержке надежного хранения информации, выполнении специфических для данного приложения преобразований информации и/или вычислении, предоставлении пользователям удобного и легко осваиваемого интерфейса.
ПРИМЕЧАНИЕ
Несмотря на то что сложность вычислений, выполняемых в информационных системах, несоизмеримо ниже, чем при проведении научных расчетов, требования к вычислительной мощности компьютеров в таких системах увеличиваются. Это связано с тем, что объемы обрабатываемой информации, как правило, достаточно велики, а сама информация имеет сложную структуру. Этим же объясняется существенное увеличение требований к объему как оперативной памяти, так и устройств постоянного хранения информации.
Со временем именно второе направление, связанное с хранением и обработкой данных, стало доминирующим, особенно после появления персональных компьютеров. Использование персональных компьютеров для выполнения сложных научных расчетов сейчас является скорее исключением. Интересно также отметить, что современные персональные компьютеры, оборудованные процессорами с громадными тактовыми частотами (на сегодняшний день рядовой дешевый процессор работает на частоте 700-800 МГц), при решении сложных научных задач могут даже уступать по вычислительным возможностям «большим» компьютерам 10-15-летней давности.
Базы данных: основные сведения.
Развитие компьютерных технологий, связанных с хранением и обработкой данных, привело к появлению в конце 60-х — начале 70-х годов специализированного программного обеспечения, получившего название систем управления базами данных (СУБД) (DataBase Management Systems — DBMS). СУБД позволяют структурировать, систематизировать и организовывать данные для их компьютерного хранения и обработки. Именно системы управления базами данных являются основой практически любой информационной системы.
СУБД можно определить как некую систему управления данными, обладающую следующими свойствами:
>> поддержание логически согласованного набора файлов;
>> обеспечение языка манипулирования данными;
>> восстановление информации после разного рода сбоев;
>> обеспечение параллельной работы нескольких пользователей.

Основные функции СУБД.
К основным функциям, выполняемым системами управления базами данных, обычно относят следующие;
>> непосредственное управление данными во внешней памяти;
>> управление буферами оперативной памяти;
>> управление транзакциями;
>> протоколирование;
>> поддержка языков баз данных. Рассмотрим каждую из указанных функций более подробно.
Непосредственное управление данными во внешней памяти
Функция непосредственного управления данными во внешней памяти включает обеспечение необходимых структур внешней памяти (постоянных запоминающих устройств — как правило, магнитных дисков) как для хранения данных, непосредственно входящих в базу данных, так и для служебных целей, например для уско¬рения доступа к данным в некоторых случаях (обычно для этого используются индексы). Причем пользователям базы данных в общем случае не нужно знать, использует ли СУБД файловую систему и если использует, то как организованы файлы. Обычно СУБД поддерживает собственную систему именования объектов
БД. В зависимости от способа реализации СУБД может либо использовать возможности существующих файловых систем, либо работать с устройствами внешней памяти на низком уровне.
Управление буферами оперативной памяти.
Объём информации, хранящейся в базе данных, с которой работает СУБД, обычно достаточно велик и практически всегда превышает доступный объем оперативной памяти. При этом время доступа к данным, хранящимся в оперативной памяти, существенно меньше, чем к данным, хранящимся на устройствах внешней памяти. Очевидно, что если при обращении к любому элементу данных будет производится обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти.
Увеличения скорости обмена данными можно достичь, используя буферизацию данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезнос¬ти буферизации той или иной части базы данных. Поэтому в СУБД обычно поддерживается собственный набор буферов оперативной памяти с собственным механизмом замены буферов.
ПРИМЕЧАНИЕ
Следует отметить, что существует направление развития СУБД, ориентированное на постоянное присутствие в оперативной памяти всей информации из базы данных. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что буферизация станет не нужна. Если исходить из темпов снижения цен на оперативную память, то такие СУБД действительно могут стать актуальными в достаточно недалеком будущем.
Управление транзакциями.
Транзакцией называется последовательность операций над базой данных, рассматриваемых СУБД как единое целое. Если все операции успешно выполнены, то транзакция также считается успешно выполненной и СУБД фиксирует (COMMIT) все изменения данных, произведенные этой транзакцией (то есть заносит измене¬ния во внешнюю память). Если же хотя бы одна операция транзакции заканчивается неудачей, то транзакция считается невыполненной и производится откат (ROLLBACK) — отмена всех изменений данных, произведенных в ходе выполне¬ния транзакции, и возврат базы данных к состоянию до начала выполнения транзакции. Управление транзакциями необходимо для поддержания логической целостности базы данных. Поддержка механизма транзакций является обязательным условием даже однопользовательских, а тем более для многопользовательских СУБД. То свойство, что каж¬дая транзакция начинается при целостном состоянии базы данных и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к базе данных. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может, в принципе, ощущать себя единственным пользователем СУБД.
С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Под сериализациями параллельно выполняющихся транзакций понимается такое планирование их работы, при котором суммарный результат смеси транзакций эквивалентен результату их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций. Попятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).
Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов базы данных. При использовании любого алгоритма сериализации возможны конфликты между несколькими транзакциями по доступу к объектам базы данных, В этом случае для поддержания сериализации необходимо выполнить откат одной или нескольких транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей.
Журнализация.
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Аппаратные сбои обычно подразделяются на два вида:
>> мягкие сбои связаны с внезапной остановкой работы компьютера. Обычно являются следствием внезапного выключения питания или "зависания" операционной системы (что особенно характерно для операционных систем Windows);
>> жесткие сбои характеризуются потерей информации на носителях внешней
памяти.
Программные сбои обычно возникают вследствие ошибок в программах. Причем эти ошибки могут быть как в самой СУБД, что может привести к аварийному завершению ее работы, так и в пользовательской программе. Первый случай можно рассматривать как разновидность мягкого аппаратного сбоя. Во втором случае незавершенной остается только одна транзакция.
В любом случае для восстановления информации в базе данных необходимо иметь некоторую дополнительную информацию. Таким образом, для поддержания надежности хранения данных требуется избыточность данных. Причем та часть информации, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений базы данных. Журнал представляет собой особую часть базы данных, недоступную пользователям СУБД и поддерживаемую с особой тщательностью (иногда используются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части базы данных. В разных СУБД изменения базы данных журнализируются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения базы данных, иногда — минимальной внутренней операции модификации страницы внешней памяти. Могут также использоваться одновременно оба подхода. Во всех случаях придерживаются стратегии «упреждающей» записи в журнал (так называемого протокола Write Ahead Log — WAL). Несколько утрированно можно сказать, что эта стратегия заключается в том, что запись об изменении любого объекта базы данных должна быть занесена в журнал до того, как будет выполнено и зафиксировано изменение этого объекта. Если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановле¬ния базы данных после любого сбоя.
Самая простая ситуация восстановления — индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений базы данных. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации базы данных, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи, относящиеся к одной транзакции, связывают обратным списком (от конца к началу). При мягком сбое во внешней памяти основной части базы данных могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является приведение внешней памяти основной части базы данных в такое состояние, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того чтобы этого добиться, сначала производят откат незавершенных транзакций, а потом повторно воспроизводят те операции завершенных транзакций, результаты которых не отображены во внешней памяти.
Для восстановления базы данных после жесткого сбоя используют журнал и архивную копию базы данных. Архивная копия — это полная копия базы данных к моменту начала заполнения журнала (хотя имеется много вариантов трактовки смысла архивной копии). Для нормального восстановления базы данных после жестко¬го сбоя, естественно, необходимо, чтобы журнал не пропал. Тогда восстановление базы данных состоит в том, что, исходя из архивной копии, по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.
Поддержка языков баз данных.
Для работы с информацией, хранящейся в базе данных, используются специальные языки, носящее общее название языков баз данных. Чаще всего выделяются два языка:
>> язык определения схем данных (Schema Definition Language, SDL) служит главным образом для определения логической структуры базы данных;
>> язык манипулирования данными (Data Manipulation Language, DML) содержит набор операторов манипулирования данными, то есть операторов, позволяющих заносить данные в базу, а также удалять, модифицировать или выбирать существующие данные.
Несколько разных специализированных языков баз данных поддерживалось лишь в ранних СУБД. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с базой данных, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). Таким образом, указанные выше языки баз данных на сегодняшний день фактически являются подмножествами единого стандартного языка SQL.
Язык SQL позволяет определять схему реляционной базы данных и манипулировать данными. При этом именование объектов базы данных (для реляционной базы данных — именование таблиц и их полей) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов.
Язык SQL содержит специальные средства определения ограничений целостности базы данных. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности базы данных производится на языковом уровне — при компиляции операторов модификации базы данных компилятор SQL на основании имеющихся в базе данных ограничений целостности генерирует соответствующий программный код.
Специальные операторы языка SQL позволяют определять так называемые представления базы данных, фактически являющиеся хранимыми в базе данных запросами (результатом любого запроса к реляционной базе данных является таблица) с именованными столбцами, называемыми полями. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в базе данных, но с помощью представлений можно ограничить или, наоборот, расширить видимость данных для конкретного пользователя. Поддержка представлений производится также на языковом уровне.
Наконец, авторизация доступа к объектам базы данных производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу базы данных, обладает полным набором полномочий для работы с данной таблицей. В число этих полномочий нходит полномочие на передачу всех или части полномочий другим пользовате¬лям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.
ПРИМЕЧАНИЕ
Здесь дается лишь общее представление о языке SQL Более подробно данный язык и его функции будут рассматриваться ниже.
Эволюция систем управления базами данных.
На эволюцию СУБД существенное влияние оказывает бурное развитие микроэлектронных технологий и связанное с этим развитие персональных компьютеров. Темпы развития персональных компьютеров за последние 10-15 лет существенно пре-вышают темпы развития «больших» ЭВМ. Область применения персональных компьютеров за последние несколько лет существенно расширилась. Можно выделить следующие основные причины этой тенденции:
>> цена персональных компьютеров значительно ниже, чем больших ЭВМ;
>> по функциональным возможностям персональные компьютеры превосходят
большие ЭВМ;
>> существенно уменьшился разрыв между производительностью персональных компьютеров и больших ЭВМ. Кроме то го, для многих задач работы сданными производительность компьютера не является решающим фактором;
>> архитектура систем на основе персональных компьютеров обладает большей гибкостью и мобильностью, а сфера их использования значительно шире области применения больших ЭВМ.
Общая тенденция движения от отдельных mainframe-систем к открытым распределенным системам оказала огромное влияние на развитие архитектур СУБД и поставила перед их разработчиками ряд сложных проблем. Главная проблема состояла в технологической сложности перехода от централизованного управления данными на одном компьютере и СУБД, использовавшей собственные модели, форматы представления данных и языки доступа к данным, к распределенной обработке данных в неоднородной вычислительной среде, состоящей из соединенных в сеть компьютеров различных моделей и производителей.
Постепенный переход от вычислительных систем на основе больших ЭВМ и централизованного управления данными к распределенным системам на основе персональных компьютеров, а также внедрение персональных компьютеров практически во все сферы деятельности привели и к изменению подходов к организации систем управления базами данных. В истории развития и совершенствования систем управления базами данных можно условно выделить три основных этапа. Кратко рассмотрим каждый из них.
СУБД первого поколения.
Первый этап был связан с созданием первого поколения СУБД, опиравшихся на иерархическую и сетевую модели данных (на основе спецификаций CODASYL). В этот период времени на рынке вычислительной техники доминировали большие вычислительные машины (mainframe), такие как система IBM 360/370, которые в совокупности с СУБД первого поколения составили аппаратно-программную платформу больших информационных систем. СУБД первого поколения были в подавляющем большинстве закрытыми системами: отсутствовал стандарт внеш¬них интерфейсов и не обеспечивалась переносимость прикладных программ. Ранние СУБД, с сегодняшней точки зрения, имели массу недостатков, из которых наиболее существенными были следующие:
>> сложность использования;
>> необходимость знать физическую организацию базы данных;
>> сильная зависимость прикладных систем от физической организации базы данных;
>> перегрузка логики прикладных систем деталями организации доступа к базе
данных;
>> отсутствие средств автоматизации проектирования баз данных;
>> очень высокая стоимость.
Среди достоинств СУБД первого поколения можно отметить:
>> наличие развитых средств управления данными во внешней памяти на низком
уровне;
>> возможность построения эффективных прикладных систем вручную;
>> возможность экономии памяти за счет совместного использования объектов
(в сетевых системах).
Несмотря на все свои недостатки, СУБД первого поколения оказались весьма долговечными: разработанное на их основе программное обеспечение используется по сей день, и большие ЭВМ по-прежнему хранят огромные массивы актуальной информации. Главной причиной этого является, вероятно, экономический фактор - в свое время в аппаратное и программное обеспечение больших ЭВМ были вложены огромные средства: в результате многие продолжают их использовать, несмотря на морально устаревшую архитектуру. В то же время перенос данных и программ с больших ЭВМ на компьютеры нового поколения сам по себе представляет сложную техническую проблему и требует значительных затрат.
Реляционные СУБД.
Началом второго этапа в эволюции СУБД можно считать публикации в начале 70-х годов ряда статей Э. Кодда, в которых выдвигались по сути революцион¬ные идеи, существенно изменившие устоявшиеся представления о базах данных.
Будучи математиком по образованию, Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение (по-английски — relation, отсюда и название — реляционные базы данных).
Одна из главных идей Кодда заключалась в том, что связь между данными должна устанавливаться в соответствии с их внутренними логическими взаимоотношениями.
ПРИМЕЧАНИЕ
В СУБД первого поколения для связи записей из разных файлов использовались физические указатели или адреса на диске. Это означало, что в том случае когда в разных файлах хранится логически связанная информация, а физическая связь между этими файлами отсутствует, то для получения выборки (извлечения информации) из такой базы данных необходимо использовать низкоуровневые средства работы с файлами. В случае же реляционной базы данных сама СУБД поддерживает извлечение информации из базы данных на основе логических связей, и при работе с базой данных нет необходимости напрямую программировать работу с файлами. Естественно, это существенно упрощает работу с базами данных.
Второй важный принцип, предложенный Коддом, заключается в том, что в реляционных системах одной командой могут обрабатываться целые файлы данных, в то время как в ранних СУБД одной командой обрабатывалась только одна запись. Реализация этого принципа существенно повысила эффективность програм¬мирования баз данных.
Реализация реляционных принципов в СУБД сделала возможным разработку простых языков запросов, доступных для изучения пользователями, не являющимися специалистами в области программирования. Таким образом, благодаря снижению требований к квалификации существенно расширился круг пользователей баз данных.
ПРИМЕЧАНИЕ
На начальном этапе развития реляционных баз данных было разработано несколько языков запросов, среди которых наиболее известны такие, как QBE - Query by Example (запрос по образцу), Quel - Query Language (язык запросов) и SQL - Structured Query Language (структурированный язык запросов). Среди этих языков на сегодняшний день наибольшее распространение имеет SQL, который в 1986 г. был принят в качестве стандарта ANSI языков реляционных баз данных. Последнее обновление этого стандарта было принято в 1992 г., и язык запросов, соответствующий этому стандарту, обычно обозначается как SQL-92.
Сейчас реляционные базы данных получили очень широкое распространение и фактически их можно рассматривать как стандарт СУБД для современных информационных систем.
Объектно-ориентированные СУБД.
Несмотря на большую популярность реляционных СУБД, развитие технологии управления данными на них не остановилось, Развитие реляционных баз данных и обеспечение возможностей решения более сложных задач привели к появлению объектно-ориентированных баз данных, для которых характерны использование идей объектно-ориентированного подхода, управления распределенными базами данных, активного сервера базы данных, языков программирования четвертого поколения, фрагментации и параллельной обработки запросов, технологии тиражирования данных, многопоточной архитектуры и других революционных достижений в области обработки данных.
Объектно-ориентированный подход имеет ряд преимуществ для разработчика, из которых можно отметить следующие:
а возможность разбить систему на совокупность независимых сущностей (объектов) и провести их строгую независимую спецификацию;
>> простота эволюции системы за счет использования таких элементов объектного подхода как наследование и полиморфизм;
>> возможность объектного моделирования системы, позволяющее проследить поведение реальных сущностей предметной области уже на ранних стадиях разработки.
ПРИМЕЧАНИЕ
Несмотря на все достоинства объектно-ориентированных СУБД, их использование далеко не всегда оправданно. Нередко декомпозиция данных объекта не вызывает никаких проблем и вполне логична. В этом случае использование реляционной моде¬ли может быть более эффективно. Кроме того, ведущие производители реляционных СУБД IBM и Oracle доработали свои продукты (DB2 и Oracle соответственно), добавив объектную надстройку над реляционным ядром системы. Таким образом, работая с этими СУБД, можно использовать ту или иную модель данных в зависимости от конк¬ретной ситуации. Вероятно, что в обозримом будущем рынок корпоративных систем пока останется за гибридными обьектно-реляционными СУБД.
Объектная модель данных более близка сущностям реального мира. Объекты можно сохранить и использовать непосредственно, не раскладывая их по таблицам. Типы данных определяются разработчиком и не ограничены набором предопределенных типов.
При занесении сложного объекта в реляционную базу обязательна процедура декомпозиции его данных для того, чтобы разместить их в таблицах. При чтении объекта из реляционной базы он собирается из отдельных элементов и только затем пригоден для использования. В объектных же СУБД данные объекта, а также методы изменения этих данных помещаются в хранилище как единое целое.
Использование объектной модели представления данных (и, соответственно, объектно-ориентированной СУБД) наиболее привлекательно для информационных систем корпоративного уровня, разработка которых ведется методами объектного проектирования.
Реляционная модель данных.

Реляционная модель данных была предложена Е. Коддом, известным американским специалистом в области баз данных. Основные концепции этой модели были впервые опубликованы в 1970 г. в статье «A Relational Model of Data for Large Shared Data Banks» (CACM, 1970, Vol. 13, № 6). Реляционная модель позволила решить одну из важнейших задач в управлении базами данных — обеспечить независимость представления и описания данных от прикладных программ, следствием чего было бы существенное упрощение проектирования и программирования баз данных. Поэтому после опубликования работ Кодда начались активные исследова¬ния по созданию реляционной системы управления базами данных. В результате этих исследований во второй половине 70-х годов был создан ряд коммерческих и некоммерческих реляционных СУБД.
К основным достоинствам реляционного подхода к управлению базой данных следует отнести:
>> наличие небольшого набора абстракций, которые позволяют сравнительно просто моделировать большую часть распространенных предметных областей и допускают точные формальные определения, оставаясь интуитивно понятными;
>> наличие простого и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных;
>> возможность манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти. Несмотря на все свои достоинства, реляционные системы далеко не сразу получили широкое признание. Хотя уже во второй половине 70-х годов появились первые прототипы реляционных СУБД, долгое время считалось невозможным добиться эффективной реализации таких систем. Однако постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что уже в середине 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД.
В настоящее время реляционные СУБД остаются одними из наиболее распространенных, несмотря на некоторые присущие им недостатки. Сейчас основным предметом критики реляционных СУБД является не их недостаточная эффективность, а некоторая ограниченность таких систем при использовании в так называемых нетрадиционных областях (наиболее распространенными примерами являются системы автоматизации проектирования), в которых требуются предельно сложные структуры данных. Причем эта ограниченность реляционных СУБД является прямым следствием их простоты и проявляется лишь в отдельных предметных областях. Вторым часто отмечаемым недостатком реляционных баз данных является невозможность адекватного отражения семантики предметной области — возможности представления знаний о семантической специфике предметной области в реляционных системах очень ограничены.
На устранение именно этих недостатков в основном и направлены исследования по созданию объектно-ориентированных баз данных.
Базовые понятия реляционной модели данных.
Термин «реляционный» (от английского relation — отношение) указывает прежде всего на то, что такая модель хранения данных построена на взаимоотношении составляющих ее частей, которые удобно представлять в виде двумерной таблицы. Кодд показал, что набор отношений (таблиц) может быть использован для хранения данных об объектах реального мира и моделирования связей между ними. Таким образом, реляционная модель данных представляет информацию в виде совокупности взаимосвязанных таблиц, которые принято называть отношениями или реляциями. Основными понятиями реляционной модели данных являются:
>> тип данных;
>> домен;
>> атрибут;
>> кортеж;
>> ключ.

Тип данных.
Понятие тип данных в реляционной модели данных полностью эквивалентно соответствующему понятию в алгоритмических языках. Набор поддерживаемых типов данных определяется СУБД и может сильно различаться в разных системах. Однако практически все СУБД поддерживают следующие типы данных:
>> целочисленные;
>> вещественные;
>> строковые;
>> специализированные типы данных для денежных величин;
>> специальные типы данных для временных величин (дата и/или время);
>> типы двоичных объектов (данный тип не имеет аналога в языках программиро¬вания; обычно для его обозначения используется аббревиатура BLOB — Binary Large Object).
ПРИМЕЧАНИЕ
достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres).
В рассматриваемом примере используются три типа данных — строковый (столбцы «Имя» и «Специальность»), временной тип (столбец «Дата_рождения») и це¬лочисленный тип («Курс» и <№_студенческого_билета>).
Домен.
Наименьшая единица данных реляционной модели — это отдельное атомарное (неразложимое) для данной модели значение данных. Доменом называется множество атомарных значений одного и того же типа. Иными словами, домен представляет собой допустимое потенциальное множество значений данного типа. В нашем примере можно для каждого столбца таблицы определить домен:
>> домены «Имена» и «Специальности» для столбцов «Имя» и «Специальность» соответственно будут базироваться на строковом типе данных — в число их значении могут входить только те строки, .которые могут изображать имя и название специальности (в частности, такие строки не должны начинаться с мягкого знака);
>> домен «Даты_рождения» для столбца «Дата_рождения» определяется на базо¬вом временном типе данных — данный домен содержит только допустимый диапазон дат рождения студентов;
>> домены «Номера_курсов» и «Номера_студенческих_билетов» базируются на целочисленном типе - в число его значений могут входить только те целые числа, которые могут обозначать номер курса университета (обычно от 1 до 6) и номер студенческого билета (обязательно положительное число).
ПРИМЕЧАНИЕ
Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с диапазонными типами и множествами, имеющимися в ряде языков программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат «истина», то элемент данных является элементом домена. Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла. В нашем примере значения доменов «Номера_курсов» и «Номера_студенческих_билетов» основаны на одном типе данных — целочисленном, но не являются сравнимыми.
ПРИМЕЧАНИЕ
Понятие домена используется далеко не во всех СУБД. В качестве примера реляционных баз данных, использующих домены, можно привести Oracle и InterBase.
Атрибуты, схема отношения, схема базы данных.
Столбцы отношения называют атрибутами, им присваиваются имена, по которым к ним затем производится обращение.
Список имен атрибутов отношения с указанием имен доменов (или типов, если домены не поддерживаются) называется схемой отношения. Схема нашего отношения СТУДЕНТ запишется так:
СТУДЕНТ {№_стуценческого_билета Номера_студевческих_билетов
Имя Имена.
Дата_рождения Даты_рождения.
Курс_Номера_курсов.
Специальность Специальности)
Степень отношения — это число его атрибутов. Отношение степени один называют унарным, степени два — бинарным, степени три — тернарным, а степени n - n-арным.
Степень отношения СТУДЕНТЫ равна пяти, то есть оно является 5-арным.
Схемой базы данных называется множество именованных схем отношений.
Кортеж.
Кортеж, соответствующий данной схеме отношения, представляет собой множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. «Значение» является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым степень кортежа, то есть число элементов в нем, совпадает со степенью соответствующей схемы отношения. Иными словами, кортеж - это набор именованных значений заданного типа.
ПРИМЕЧАНИЕ
Схему отношения иногда называют также заголовком отношения, а отношение как набор кортежей — телом отношения.
Понятие схемы отношения напоминает понятий структурного типа данных в языках программирования (структура в C/C++, запись в Pascal). Однако в реляционных базах данных имя схемы отношения всегда совпадает с именем соответствующего отношения-экземпляра. В классических реляционных базах данных после определения схемы базы данных изменяются только отношения-экземпляры. В них могут появляться новые и удаляться или модифицироваться существующие кортежи. Однако во многих реализациях допускается и изменение схемы базы данных: определение новых и изменение существующих схем отношения. Это принято называть эволюцией схемы базы данных. Таким образом, отношение по сути является множеством кортежей, соответствующим одной схеме отношения.
Кардинальным числом или мощностью отношения называется число его кортежей. Мощность отношения СТУДЕНТЫ равна 6. В отличие от степени отношения кардинальное число отношения изменяется во времени.
Пустые значения.
В некоторых случаях какой-либо атрибут отношения может быть неприменим. Например, и рассматриваемом в качестве примера отношении СТУДЕНТЫ может также храниться информация о потенциальных абитуриентах, посещающих подготовительные курсы вуза. В этом случае неприменимыми оказываются атрибуты «№_студенческого_билета» и «Курс» (так как абитуриенты еще не поступили в вуз и, следовательно, не имеют студенческого билета и не могут быть отнесены к какому-либо курсу). Кроме того, иногда при вводе информации в строку реляционной таблицы некоторые данные могут быть неизвестны и выясняться позже. (Для нашего примера — при поступлении на подготовительные курсы абитуриент еще не определился окончательно, на какую специальность он будет поступать.)
В обоих указанных случаях в поля, соответствующие неприменимым или неизвестным атрибутам, ничего не заносится, и строка записывается в базу данных с пустыми значениями этих атрибутов.
Следует понимать, что пустое значение — это не Ноль и не пустая строка, а неизвестное значение атрибута, которое не определено в данный момент времени и в принципе может быть определено позднее.
ПРИМЕЧАНИЕ
Для обозначения пустых значений полей используется слово NULL.
Ключи отношения.
Поскольку отношение с математической точки зрения является множеством, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно заданный момент времени. Таким образом, в отношении всегда должен присутствовать некоторый атрибут (или набор атрибутов), однозначно определяющий каждый кортеж отношения и обеспечивающий уникальность строк таблицы. Такой атрибут (или набор атрибутов) называется первичным ключом отношения. Более строго определить понятие первичного ключа можно следующим образом; если R — отношение с атрибутами At, А2,..., Аn, то множество атрибутов К - (Ai, Aj,..,Ak) отношения R является первичным ключом этого отношения тогда и только тогда, когда удовлетворяются два независимых от времени условия:
>> уникальность: в произвольный момент времени никакие два различных кортежа отношения R не имеют одного и того же значения для Аi, aj, ..., Ak;
>> минимальность: ни один из атрибутов Аi, aj, ..., Ak не может быть исключен из К без нарушения уникальности.
Для каждого отношения свойством уникальности обладает по крайней мере полный набор его атрибутов. Однако требуется обеспечить и условие минимальности. Поэтому, как правило, в отношении всегда имеется один атрибут, обладающий свойством уникальности и являющийся первичным ключом. В зависимости от количества атрибутов, входящих в ключ, различают простые и сложные (или составные) ключи.
Простой ключ — ключ, содержащий только один атрибут. В общем случае опера¬ции объединения выполняются быстрее в том случае, когда в качестве ключа используется самый короткий и самый простой из возможных типов данных. С этой точки зрения наилучшим образом подходит целочисленный тип, который имеет аппаратную поддержку для выполнения над ним логических операций. Сложный или составной ключ - ключ, состоящий из нескольких атрибутов.
ПРИМЕЧАНИЕ
Набор атрибутов, обладающий свойством уникальности, но не обладающий минимальностью, называется суперключом. Суперключ — сложный (составной) ключ с большим числом столбцов, чем необходимо для того, чтобы быть уникальным идентификатором. Такие ключи нередко используются на практике, так как избыточность может оказаться полезной пользователю.
В зависимости от того, содержит ли атрибут, являющийся первичным ключом, какую-либо информацию, различают искусственные и естественные ключи. Искусственный или суррогатный ключ — ключ, созданный самой СУБД или пользователем с помощью некоторой процедуры, который сам по себе не содержит информации. Искусственный ключ используется для создания уникальных идентификаторов строк, когда сущность должна быть описана полностью, чтобы однозначно идентифицировать конкретный элемент. Искусственный ключ часто используют вместо значимого сложного ключа, который является слишком громоздким, чтобы использоваться в реальной базе данных. Система поддерживает искусственный ключ, но он никогда не показывается пользователю. Естественный ключ-ключ, в который включены значимые атрибуты и который, таким образом, содержит информацию.
ПРИМЕЧАНИЕ
В рассматриваемом нами примере в качестве первичного ключа отношения СТУДЕНТЫ можно рассматривать атрибут №_студенческого_билета. Причем данный ключ будет естественным, так как он несет вполне определенную информацию.
Каждый из типов первичных ключей имеет свои преимущества и недостатки; их обсуждению посвящено большое количество публикаций. Мы не будем проводить подробное их сравнение, а отметим лишь основные плюсы и минусы каждого из видов ключей.
Основными достоинствами естественных ключей является то, что они несут вполне определенную информацию и их использование не приводит к необходимости добавлять в таблицы атрибуты, значения которых не имеют никакого смысла и таким образом, отношение по сути является множеством кортежей, соответствующим одной схеме отношения.
Кардинальным числом или мощностью отношения называется число его кортежей. Мощность отношения СТУДЕНТЫ равна 6. В отличие от степени отношения кардинальное число отношения изменяется во времени.
Пустые значения.
В некоторых случаях какой-либо атрибут отношения может быть неприменим. Например, и рассматриваемом в качестве примера отношении СТУДЕНТЫ может
также храниться информация о потенциальных абитуриентах, посещающих подготовительные курсы вуза. В этом случае неприменимыми оказываются атрибуты
«№_студенческого_билета» и «Курс» (так как абитуриенты еще не поступили в вуз и, следовательно, не имеют студенческого билета и не могут быть отнесены к какому-либо курсу). Кроме того, иногда при вводе информации в строку реляционной таблицы некоторые данные могут быть неизвестны и выясняться позже. (Для нашего примера — при поступлении на подготовительные курсы абитуриент еще не определился окончательно, на какую специальность он будет поступать.)
В обоих указанных случаях в поля, соответствующие неприменимым или неизвестным атрибутам, ничего не заносится, и строка записывается в базу данных с пустыми значениями этих атрибутов.
Следует понимать, что пустое значение — это не Ноль и не пустая строка, а неизвестное значение атрибута, которое не определено в данный момент времени и в принципе может быть определено позднее.
ПРИМЕЧАНИЕ
Для обозначения пустых значений полей используется слово NULL.
ПРИМЕЧАНИЕ
В рассматриваемом нами примере в качестве первичного ключа отношения СТУДЕНТЫ можно рассматривать атрибут №_студенческого_билета. Причем данный ключ будет естественным, так как он несет вполне определенную информацию.
Каждый из типов первичных ключей имеет свои преимущества и недостатки; их обсуждению посвящено большое количество публикаций. Мы не будем проводить подробное их сравнение, а отметим лишь основные плюсы и минусы каждого из видов ключей.
Основными достоинствами естественных ключей является то, что они несут вполне определенную информацию и их использование не приводит к необходимости добавлять в таблицы атрибуты, значения которых не имеют никакого смысла и используются лишь для связи между отношениями. Иными словами, использование естественных ключей позволяет получить более компактную форму таблиц (в которых не будет избыточных, неинформативных данных) и более естественные связи между ними.
Основным же недостатком естественных ключей является то, что их использование весьма затруднительно в случае изменчивости предметной области. Следует понимать, что значения атрибутов первичного ключа не должны изменяться. То есть од¬нажды заданное значение первичного ключа для кортежа не может быть позже изменено. Такое требование ставится в основном для поддержания целостности базы данных. Связь между отношениями обычно устанавливается именно по первичному ключу, и его изменение приведет к нарушению этих связей или к необхо¬димости изменения записей в нескольких таблицах. Даже в сравнительно простых базах данных это может вызвать ряд трудноразрешимых проблем.
ПРИМЕЧАНИЕ
В некоторых реляционных СУБД допускается изменение первичного ключа. Иногда это бывает действительно полезно. Однако прибегать к этому следует лишь в случае крайней необходимости.
Типичным примером изменчивой предметной области, в которой для сущности невозможно определить неизменный естественный ключ, является любая область, где в качестве сущности выступает человек. Действительно, невозможно определить для человека набор атрибутов, которые были бы уникальны и неизменны на протяжении всей его жизни. Второй, довольно существенный недостаток естественных ключей состоит в том, что, как правило, уникальные естественные ключи являются составными и содержат строковые атрибуты. Как уже отмечалось выше, максимальная скорость выполнения операций над данными обеспечивается при использовании простых целочисленных ключей. Таким образом, с точки зрения быстродействия системы естественные ключи часто оказываются неоптимальными. Оба недостатка естественных ключей можно преодолеть, определив в отношениях суррогатные ключи, представляющие собой некоторый универсальный атрибут, как правило целочисленного типа, который не зависит ни от предметной области, ни, тем более, от структуры отношения, которое он идентифицирует. Таким образом можно обеспечить уникальность и неизменность ключа (раз он никаким образом не зависит от предметной области, то никогда не возникнет необходимость изменять его). Однако за это приходится платить избыточностью данных в таблицах.
ПРИМЕЧАНИЕ
Следует заметить, что во многих практических реализациях реляционных СУБД допускается нарушение свойства уникальности кортежей для промежуточных отношений, порождаемых неявно при выполнении запросов. Такие отношения являются не множествами, а мультимножествами, что в ряде случаев позволяет добиться определенных преимуществ, но иногда приводит к серьезным проблемам. В любой из таблиц может оказаться несколько наборов атрибутов, которые можно выбрать в качестве ключа. Такие наборы называются потенциальными или альтернативными ключами.
Нередко в отношениях определяются так называемые вторичные ключи. Вторичный ключ представляет собой комбинацию атрибутов, отличную от комбинации, составляющей первичный ключ. Причем вторичные ключи не обязательно обладают свойством уникальности. При их определении могут задаваться следующие ограничения;
>> UNIQUE — ограничение уникальности, значения вторичных ключей при данном ограничении не могут дублироваться;
>> NOT NULL — при данном ограничении ни один из атрибутов, входящих в состав вторичного ключа, не может принимать значение NULL. Перекрывающиеся ключи — сложные ключи, которые имеют один или несколько общих столбцов.
Связанные отношения.
В реляционной модели данные представляются в виде совокупности взаимосвязанных таблиц. Подобное взаимоотношение между таблицами называется связью (relationship). Таким образом, еще одним важным понятием реляционной модели является связь между отношениями.
Для рассмотрения связанных отношений воспользуемся рассмотренным ранее примером — отношением СТУДЕНТЫ. Данное отношение может быть связано с отношением УСПЕВАЕМОСТЬ, в котором содержатся сведения об успеваемости студентов по разным предметам.
Условия целостности данных.
Чтобы информация, хранящаяся в базе данных, была однозначной и непротиворечивой, в реляционной модели устанавливаются некоторые ограничительные условия. Ограничительные условия — это правила, определяющие возможные значения данных. Они обеспечивают логическую основу для поддержания корректных значений данных в базе. Ограничения целостности позволяют свести к минимуму ошибки, возникающие при обновлении и обработке данных. Важнейшими ограничениями целостности данных являются;
>> категорийная целостность;
>> ссылочная целостность.
Ограничение категорийной целостности заключается в следующем. Кортежи отношения представляют в базе данных элементы определенных объектов реального мира или, в соответствии с терминологией реляционных СУБД, категорий. Первичный ключ таблицы однозначно определяет каждый кортеж и, следовательно, каждый элемент категории. Таким образом, для извлечения данных, содержащихся в строке таблицы, или для манипулирования этими данными необходимо знать значение ключа для этой строки. Поэтому строка не может быть занесена в базу данных до тех пор, пока не будут определены все атрибуты ее первичного ключа. Это правило называется правилом категорийной целостности и кратко формулируется следующим образом: никакой атрибут первичного ключа строки не может быть пустым. Второе условие накладывает на внешние ключи ограничения для обеспечения целостности данных, называемой ссылочной целостностью.
Если две таблицы связаны между собой, то внешний ключ таблицы должен содержать только те значения, которые уже имеются среди значений ключа, по которому осуществляется связь. Если корректность значений внешних ключей не контролируется СУБД, то может нарушиться ссылочная целостность данных. Это можно пояснить на рассматриваемом примере следующим образом. Если удалить из таблицы СТУДЕНТЫ строку (например, при отчислении студента), имеющую хотя бы одну связанную с ней строку в таблице УСПЕВАЕМОСТЬ, то это приведет к тому, что в таблице УСПЕВАЕМОСТЬ останутся записи об успеваемости студента, который уже отчислен. Такая же ситуация будет наблюдаться и в том случае, если внешнему ключу таблицы УСПЕВАЕМОСТЬ ошибочно будет присвоено значение, отсутствующее в значениях ключа связанной таблицы. Ограничения категорийной и ссылочной целостности должны поддерживаться СУБД. Для соблюдения целостности сущности достаточно гарантировать отсутствие в любом отношении кортежей с одним и тем же значением первичного ключа. Что же касается ссылочной целостности, то здесь обеспечение целостности выглядит несколько сложнее. При обновлении ссылающегося отношения (при вставке новых кортежей или модификации значения внешнего ключа в существующих кортежах) достаточно следить за тем, чтобы не появлялись некорректные значения внешнего ключа. А вот при удалении кортежа из отношения, на которое ведет ссылка, возможно использовать один из трех поводов, каждый из которых поддерживает целостность по ссылкам:
>> первый подход заключается в том, что запрещается производить удаление кортежа, на который существуют ссылки (то есть сначала нужно либо удалить ссылающиеся кортежи, либо соответствующим образом изменить значения их внешнего ключа);
>> при втором подходе при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа автоматически становится неопределенным;
>> третий подход (называемый также каскадным удалением) состоит в том, что при удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи. В развитых реляционных СУБД обычно можно выбрать способ поддержания ссылочной целостности для каждой отдельной ситуации определения внешнего ключа. Конечно, для принятия такого решения необходимо анализировать требования конкретной прикладной области.
ПРИМЕЧАНИЕ
Хотя большинство современных СУБД обеспечивает ссылочную целостность данных, все же следует помнить, что существуют реляционные СУБД, в которых не выполняются ограничения ссылочной целостности. Это, как правило, ранние разработки локальных реляционных СУБД — FoxPro версии 2.6 и ниже, версии dBase для DOS.
Типы связей между таблицами.
При установлении связи между двумя таблицами одна из них будет являться глазной (master), а вторая — подчиненной (detail). Различие между ними несколько упрощенно можно пояснить следующим образом. В главной таблице всегда доступны все содержащиеся в ней записи. В подчиненной же таблице доступны только те записи, у которых значение атрибутов внешнего ключа совпадает со значением соответствующих атрибутов текущей записи главной таблицы. Причем изменение текущей записи главной таблицы приведет к изменению множества доступных записей подчиненной таблицы, а изменение текущей записи в подчиненной таблице не вызовет никаких изменений ни в одной из таблиц.
ПРИМЕЧАНИЕ
На практике часто связывают более двух таблиц. Одна и та же таблица может быть главной по отношению к одной таблице и подчинённой по отношению к другой. Или у одной главной таблицы может находиться в подчинении не одна, а несколько таблиц. Однако подчиненная таблица не может управляться двумя таблицами. Таким образом, у главной таблицы может быть несколько подчиненных, но у подчиненной таблицы может быть только одна главная.
Различают четыре типа связей между таблицами реляционной базы данных:
>> один к одному — каждой записи одной таблицы соответствует только одна запись другой таблицы;
>> один комногим одной записи главной таблицы могут соответствовать несколько записей подчиненной таблицы;
>> многие к одному нескольким записям главной таблицы может соответствовать одна и та же запись подчиненной таблицы;
>> многие ко многим — одна запись главной таблицы связана с несколькими записями подчиненной таблицы, а одна запись подчиненной таблицы связана с несколькими записями главной таблицы.
ПРИМЕЧАНИЕ
При проведении выборки данных из базы (с использованием, например, языка SQL) и отображении результатов этой выборки можно потребовать сортировки результирующей таблицы в соответствии со значениями некоторых атрибутов. Однако это не противоречит принципу отсутствия упорядоченности, так как результат выборки не является отношением, а представляет собой некоторый упорядоченный список кортежей.
Отсутствие упорядоченности атрибутов.
Атрибуты отношений также не упорядочены, поскольку по определению схема
отношения есть множество пар (имя атрибута, имя домена}. Для ссылки назначение атрибута в кортеже отношения всегда используется имя атрибута. Это свойство теоретически позволяет, например, модифицировать схемы существующих отношений не только путем добавления новых атрибутов, но и путем удаления существующих атрибутов. Однако в большинстве существующих систем такая возможность не допускается, и хотя упорядоченной набора атрибутов отношения явно не требуется, часто в качестве неявного порядка атрибутов используется их поря¬док в линейной форме определения схемы отношения.
Атомарность значений атрибутов.
Значения всех атрибутов являются атомарными. Это следует из определения домена как потенциального множества значений простого типа данных, то есть среди значений домена не могут содержаться множества значений (отношения).
Реляционная система управления базами данных.
Реляционная база данных — это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных. Однако пользователи могут воспринимать такую базу данных как совокупность таблиц. Таким образом, реляционную базу данных можно рассматривать как хранилище данных, содержащее набор двумерных связанных таблиц. Набор средств для управления подобным хранилищем называется реляционной системой управления базами данных. Реляционная СУБД может содержать утилиты, приложения, службы, библиотеки, средства создания приложений и другие компоненты. Еще раз подчеркнем, что в реляционной базе данных таблицы с вязаны между собой; это позволяет с помощью единственного запроса найти все необходимые данные (которые могут находиться в нескольких таблицах). Будучи связанной посредством общих ключевых полей, информация в реляционной базе данных может объединяться из множества таблиц в единый результирующий набор.
Свойства таблиц реляционной базы данных.
Так как таблицы в реляционной СУБД являются отношениями реляционной модели данных, то и свойства этих таблиц являются свойствами отношений, которые мы уже рассмотрели выше. Кратко сформулируем эти свойства еще раз:
>> каждая таблица состоит из однотипных строк и имеет уникальное имя;
>> строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или NULL;
>> строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку;
>> столбцам таблицы присваиваются уникальные имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы);
>> полное информационное содержание базы данных представляется в виде явных значений данных, и такой метод представления является единственным. В частности, не существует каких-либо специальных «связей» или указателей, соединяющих одну таблицу с другой;
>> при выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию. Этому способствует наличие имен таблиц и их столбцов, а также возможность выделения любой строки или любого набора строк с указанными признаками.
Индексы.
Выше мы рассмотрели понятие ключей таблиц базы данных. В большинстве реляционных СУБД ключи реализуются с помощью объектов, называемых индексами. Индекс представляет собой указатель на данные, размещенные в реляционной таблице. Можно провести аналогию индекса таблицы базы данных с указателем, обычно помещаемым в конце книги. Чтобы найти в книге страницы, относящиеся к некоторой теме, проще всего обратиться к указателю, в котором устанавливается соответствие между перечисленными в алфавитном порядке темами и номерами страниц, и сразу определить страницы, которые следует просмотреть. Чтобы без указателя найти все страницы, относящиеся к нужной теме, пришлось бы просматривать всю книгу. Индекс базы данных предназначен для аналогичных целей — чтобы ускорить поиск информации в таблице базы данных. Индекс предоставляет информацию о точном физическом расположении данных в таблице.
ПРИМЕЧАНИЕ
Мы отмечали, что записи в реляционных таблицах не упорядочены. Тем не менее любая запись в конкретный момент времени имеет вполне определенное физическое местоположение в файле базы данных, хотя оно и может изменяться при изменении информации, хранящейся в базе данных.
При создании индекса в нем сохраняется информация о местонахождении записей, относящихся к индексируемому столбцу таблицы. При добавлении в таблицу новых записей или удалении существующих индекс также модифицируется. При выполнении запроса к базе данных, в условие поиска которого входит индексированный столбец, поиск значений производится в первую очередь в индексе. Если этот поиск оказывается успешным, то в индексе устанавливается точное местоположение искомых данных в таблице базы данных.
Различают несколько типов индексов. Наиболее часто выделяют три типа:
>> простые;
>> составные;
>> уникальные.
ПРИМЕЧАНИЕ
Ускорение поиска информации при использовании индекса может показаться неочевидным — ведь количество записей в индексе совпадает с количеством записей в таблице. Однако следует учитывать два обстоятельства:
>> обращение к индексу выполняется быстрее, чем к таблице;
>> в индексе записи хранятся в упорядоченном виде (в рассматриваемом примере — в алфавитном порядке) и поэтому при поиске информации в индексе нет необхо¬димости просматривать все данные до конца индекса.
Простые индексы представляют собой простейший и вместе с тем наиболее распространенный тип индекса. Простой индекс строится на основе только одного столбца реляционной таблицы.
Составные индексы строятся по двум и более столбцам реляционной таблицы. При создании составного индекса необходимо принимать во внимание, что последовательность столбцов, по которым создается индекс, влияет на скорость поиска данных.
ПРИМЕЧАНИЕ
Последовательность столбцов в составном индексе указывается при его создании и никаким образом не связана с последовательностью столбцов в таблице.
Можно назвать два условия оптимальности следования столбцов в составном индексе:
>> первым следует помещать столбец, содержащий наиболее ограничивающее значение (то есть содержащий меньшее количество повторов);
>> первым следует помещать столбец, содержащий данные, которые наиболее часто задаются в условиях поиска.
Сформулированные условия оптимальности часто являются противоречивыми, так что между ними следует находить разумный компромисс,
ПРИМЕЧАНИЕ
Следует серьезно относиться к планированию индексов. Неправильное применение индексов может привести к снижению производительности системы. Мы уже говорили о том, что физическое местоположение записей может измениться в процессе редактирования данных пользователями, а также в результате манипуляций с файлами базы данных, проводимых самой СУБД (таких как сжатие данных, сборка «мусора» и др.). Обычно при этом происходят соответствующие изменения и в индексе, а это увеличивает время, требующееся СУБД для проведения таких операций. Поэтому обычно не следует индексировать:
>> столбцы, данные в которых подвержены частому изменению;
>> столбцы, содержащие большое количество пустых значений;
>> столбцы, содержащие небольшое количество уникальных значений;
>> небольшие таблицы;
>> поля большого размера. Уникальные индексы не допускают введения в таблицу дублирующих значений. Уникальные индексы используются не только с целью повышения скорости поиска, но и для поддержания целостности данных. Уникальный индекс может быть как простым, так и составным.
Нормализация данных.
Нормализация представляет собой процесс реорганизации данных путем ликвидации повторяющихся групп и иных противоречий с целью приведения таблиц к виду, позволяющему осуществлять непротиворечивое и корректное редактирование данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, то есть исключена избыточность информации. Таким образом, нормализацию можно также определить как процесс, направленный на уменьшение избыточности информации в реляционной базе данных.
Цели нормализации.
Избыточность информации устраняется не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных и упрощения управления ими.
Использование ненормализованных таблиц может привести к нарушению целостности данных (противоречивости информации) в базе данных. Обычно различают следующие проблемы, возникающие при использовании ненормализованных таблиц:
>> избыточность данных;
>> аномалии обновления;
>> аномалии удаления;
>> аномалии ввода.
Избыточность данных.
Избыточность данных проявляется в том, что в нескольких записях таблицы базы данных повторяется одна и та же информация. Например, один человек может работать на двух (или даже более) должностях. Таким образом, если сотрудник работает на нескольких должностях, то его личные данные будут дублироваться несколько раз, что приведет к неоправданному увеличению занимаемого объема внешней памяти.
Аномалии обновления.
Аномалии обновления тесно связаны с избыточностью данных. Предположим, что у сотрудника, работающего на нескольких должностях, изменился адрес. Чтобы информация, содержащаяся в таблице, была корректной, необходимо будет внести изменения в несколько записей. Если же исправление будет внесено не во все записи, то возникнет несоответствие информации, которое и называется аномалией обновления.
Аномалии удаления.
Аномалии удаления возникают при удалении записей из ненормализованной таблицы. Пусть, например, в организации проводится сокращение штатов и некоторые должности аннулируются. При этом следует удалить соответствующие записи в рассматриваемой таблице. Однако удаление приведет к потере информации о сотруднике, занимавшем эту должность. Такая потеря информации и называется аномалией удаления. (Для нашего случая можно привести и другой пример — удаление записи при увольнении сотрудника приведет к потере информации о должности, которую он занимал.)
Аномалии ввода.
Аномалии ввода возникают при добавлении в таблицу новых записей и обычно
возникают, когда для некоторых полей таблицы заданы ограничения NOT NULL. В таблице, рассматриваемой в качестве примера, имеется поле «Рейтинг», в котором содержится информация об уровне квалификации сотрудника, устанавливаемом по результатам его работы. При приеме на работу нового сотрудника установить уровень его квалификации невозможно, так он еще не выполнял никаких работ в организации. Если для этого поля задать ограничение NOT NULL, то в таблицу нельзя будет ввести информацию о новом сотруднике. Это и называется аномалией ввода.
Выводы.
Очевидно, что аномалии обновления, удаления и ввода крайне нежелательны. Чтобы свести к минимуму возможность появления такого рода аномалий, и используется нормализация.
Нормальные формы.
Теория нормализации основана на концепции нормальных форм, Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если оно удовлетворяет свойственному данной форме набору ограничений.
В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:
>> первая нормальная форма (1NF);
>> вторая нормальная форма (2NF);
>> третья нормальная форма (3NF);
>> нормальная форма Бойса-Кодда(BCNF);
>> четвертая нормальная форма (4NF);
>> пятая нормальная форма, или нормальная форма проекции-соединения (5NF
или PJ/NF).
Основные свойства нормальных форм:
>> каждая следующая нормальная форма в некотором смысле лучше предыдущей;
>> при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.
В основе процесса проектирования лежит метод нормализации — декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы. Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости. Функционально зависимым считается такой атрибут, значение которого однозначно определяется значением другого атрибута. Функционально зависимые атрибуты обозначаются следующим образом: X -> Y. Эта запись означает, что если два кортежа в таблице имеют одно и то же значение атрибута X, то они имеют одно и то же значение атрибута Y. Атрибут, указываемый в левой части, называется детерминантом.
ПРИМЕЧАНИЕ
Первичный ключ таблицы является детерминантом, так как его значение однозначно определяет значение любого атрибута таблицы.
Первая нормальная форма.
Ограничение первой нормальной формы — значения всех атрибутов отношения должны быть атомарными. Данное требование является базовым требованием классической реляционной модели данных, поэтому любая реляционная таблица по определению уже находится в первой нормальной форме.
Вторая нормальная форма.
Отношение находится во второй нормальной форме в том и только в том случае, когда это отношение находится в первой нормальной форме и каждый неключевой атрибут полностью зависит от первичного ключа.
ПРИМЕЧАНИЕ
Неключевым называется любой атрибут отношения, не входящий в состав первичного ключа.
Чтобы перейти от первой нормальной формы ко второй, нужно выполнить следующие шаги:
Определить, на какие части можно разбить первичный ключ, так чтобы некоторые из неключевых полей зависели от одной из этих частей (причем эти части
могут содержать несколько атрибутов).
Создать новую таблицу для каждой такой части ключа и группы зависящих от
нее полей и переместить их в эту таблицу. Часть бывшего первичного ключа
станет при этом первичным ключом новой таблицы.
Удалить из исходной таблицы поля, перемешенные в другие таблицы, кроме
тех их них, которые станут внешними ключами.
Третья нормальная форма.
Функциональная зависимость атрибутов X и Y отношения Я называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости X -> Z и Z -> У, но отсутствует функциональная зависимость Z -> X.
Отношение R находится в третьей нормальной форме в том и только в том случае, если оно находится во второй нормальной форме и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.
Чтобы перейти от второй нормальной формы к третьей, нужно выполнить следующие шаги:
Определить все поля (или группы полей), от которых зависят другие поля.
Создать новую таблицу для каждого такого поля (или группы полей) и группы, зависящих от него полей и переместить их в эту таблицу. Поле (или группа полей), от которого зависят все остальные перемещенные поля, станет при этом первичным ключом новой таблицы.
Удалить перемещенные поля из исходной таблицы, оставив лишь те из них, которые станут внешними ключами.
Нa практике третья нормальная форма схем отношений в большинстве случаев достаточна, и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается. Поэтому мы не будем рассматривать другие нормальные формы, тем более что в работе они используются сравнительно редко.

ГЛАВА 5. Управление реляционными базами данных.

Использование реляционных баз данных возможно только при наличии эффективных средств управления ими. Поэтому после публикаций статей Кодда, предлагающих реляционную модель данных, стали активно проводиться исследования по созданию языков управления реляционными данными. В результате этих исследований был предложен ряд языков, среди которых следует отметить три:
>> SQL — Structured Query Language (структурированный язык запросов);
>> QBE — Query By Example (запрос по образцу);
>> QUEL — Query Language (язык запросов).
Сейчас наибольшее распространение получил язык SQL, который является единственным языком реляционных баз данных, принятым в качестве стандарта ANSI.
ПРИМЕЧАНИЕ
Хотя SQL и называется языком запросов, он включает в себя кроме средств запросов и все необходимые средства по управлению базами данных.
В данной главе мы рассмотрим возможности языка SQL по управлению объектами реляционной базы данных и администрированию баз данных.
Краткая история языка SQL.
Язык реляционных баз данных SQL был разработан в середине 70-х годов в рамках исследовательского проекта экспериментальной реляционной СУБД System R компании IBM. Данный проект включал в себя разработку реляционной системы управления базами данных и языка SEQUEL (Structured English Query Language). Исходное название SEQUEL только частично отражало суть этого языка. Несмот¬ря на то что язык был ориентирован главным образом на удобную и понятную пользователям формулировку запросов к реляционной базе данных, он уже яв
лялся полноценным языком реляционной базы данных, содержащим, помимо операторов формулирования запросов и манипулирования базой данных, следующие элементы:
>> средства определения схемы базы данных и манипулирования ей;
>> средства определения ограничений целостности и триггеров;
>> средства создания представлений базы данных;
>> возможности определения структур физического уровня, поддерживающих
эффективное выполнение запросов;
>> средства авторизации доступа к отношениям и их полям;
>> средства поддержки точек сохранения транзакции и откатов. В конце 70-х годов модифицированный вариант языка SEQUEL, получивший название SQL, был выпущен корпорацией Oracle в качестве языка коммерческой системы управления базами данных. В 1983 г. компания IBM выпустила SQL в качестве языка управления СУБД DB2.
Американский национальный институт стандартов (ANSI) принял язык SQL в качестве стандарта в 1986 г. С тех пор этот стандарт пересматривался два раза — в 1989 г. были внесены некоторые незначительные изменения, а в 1992 г. стандарт SQL был довольно существенно расширен и в настоящее время известен под на¬званием ANSI SQL-92 или SQL/92.
ПРИМЕЧАНИЕ
Следует понимать, что ANSI SQL— всего лишь стандарт, не являющийся реальным языком. Каждый производитель систем управления базами данных, как правило, пред¬лагает собственную реализацию языка SQL Причем в таких реализациях могут быть как расширения существующего стандарта, так и отклонения от него, в том числе отсутствие некоторых стандартных элементов языка. Тем не менее, независимо от реализации, основа SQL сохраняется, поэтому при изучении языка SQL главным являет¬ся понимание базовых концепций и команд ANSI SQL-92.
Типы команд SQL.
Команды языка SQL обычно подразделяются на несколько групп. Основные типы команд следующие:
>> DDL (Data Definition Language) — язык определения данных. Команды данной группы используются для создания и изменения структуры объектов базы данных (например, для создания и удаления таблиц);
>> DML (Data Manipulation Language) — язык манипулирования данными. Команды DML используются для манипулирования информацией, содержащейся в объектах базы данных;
>> DCL (Data Control Language) — язык управления данными. Соответствующие команды предназначены для управления доступом к информации, хранящейся в базе данных;
>> DQL (Data Query Language) — язык. Это наиболее часто используемые команды, предназначенные для формирования запросов к базе данных (запрос — это обращение к базе данных для получения соответствующей информации);
>> команды администрирования базы данных предназначены для осуществления контроля за выполняемыми действиями и анализа производимых операций;
>> команды управления транзакциями.
ПРИМЕЧАНИЕ
Язык запросов в данной главе рассматриваться не будет. Команды языка запросов будут подробно обсуждаться далее в главе 11 «Выборка данных».
Типы данных SQL/92.
Типы данных, используемые в стандартном SQL, можно подразделить на следующие группы:
>> строковые типы;
>> числовые типы;
>> типы для представления даты и времени. Рассмотрим эти типы данных более подробно.
Строковые типы.
В SQL/92 определены два строковых типа:
>> символьные строки фиксированной длины;
>> символьные строки переменной длины.
Символьные строки фиксированной длины
Данные, хранящиеся в виде символьных строк фиксированной длины, всегда занимают один и тот же объем памяти, определяемый при объявлении поля, независимо от реального размера строки, занесенной в поле. Объявление строки фиксированной длины согласно ANSI SQL-92 имеет вид:
CHARACTER(n)
где n - длина строки, определяющая размер поля, к которому это объявление относится.
При использовании строк фиксированной длины пустые места обычно заполняются пробелами. Например, если размер поля задан равным 10, а в него введена строка, состоящая из 3 символов, то оставшиеся 7 символов заполняются пробелами.
ПРИМЕЧАНИЕ
Не следует использовать тип CHARACTER для полей, предназначенных для хранения длинных строк, длина которых может сильно варьироваться — это приведет к неоправданному расходу доступной внешней памяти (дискового пространства).
Символьные строки переменной длины.
Длина строк переменной длины не является постоянной для всех данных, а зависит от реального размера строки, хранящейся в поле таблицы базы данных. Объявление строки переменной длины имеет вид:

VARCHAR(n)
где n — число, определяющее максимально возможную длину строки. В отличие от типа CHARACTER использование VARCHAR обеспечивает более экономное расходование дискового пространства. Независимо от того, какой размер строки у казан в объявлении, поле будет занимать столько места, сколько необходимо для хранения занесенной в него информации. Например, если объявлено поле VARCHAR(10) и в него занесена строка длиной 3 символа, то для хранения этой строки будет использовано только три байта, а не 10, как в случае строки фиксированной длины.
Числовые типы.
Числовые типы подразделяются на:
>> целочисленные типы;
>> вещественные типы с фиксированной точкой;
>> вещественные типы с плавающей точкой;
>> двоичные строки фиксированной и переменной длины.
Целочисленные типы.
Стандартом ANSI SQL-92 устанавливаются два целочисленных типа:
>> INTEGER — целое число со знаком, использующее 4 байта. Может представлять числа в диапазоне от -2 147 483 648 до 2 147 483 647;
>> SMALLINT — короткое целое число со знаком, использующее 2 байта. Может представлять целые числа в диапазоне от -32 768 до 32 767.
Вещественные типы с фиксированной точкой.
Вещественные типы с фиксированной точкой предназначены для точного представления дробных чисел. Наиболее часто эти типы используются в том случае, когда недопустимы погрешности, неизбежные при представлении веществен¬ных чисел с плавающей запятой в двоичной форме (например, при хранении значений денежных величин). Вещественные типы с фиксированной запятой, по сути, являются целочисленными типами, в которых отображается десятичная точка.
Синтаксис объявления типа с фиксированной запятой следующий:

DECIMAL(n, m)
где n — точность; m — масштаб. Точность — это общая длина числового значения. Масштаб — количество знаков, расположенных справа от десятичной точки.
Вещественные типы с плавающей точкой.
Типы с плавающей точкой обычно используются в научных и инженерных расчетах. При использовании этих типов следует учитывать, что в процессе занесения в базу данных некоторого числа при его преобразовании в двоичную форму с плавающей точкой всегда вносится некоторая погрешность. И хотя эта погрешность очень мала, в некоторых случаях она является недопустимой и может внести серьезную ошибку, например, при суммировании большого количества значений. Поэтому типы с плавающей точкой неприменимы для хранения значений денежных величин.
Наиболее часто используются для вещественного типа с плавающей точкой:
>> FLOAT — числа с одинарной точностью;
>> DOUBLE — числа с двойной точностью.
Двоичные строки.
Двоичные строки используются сравнительно редко. Обычно поля такого типа применяются в качестве флагов или двоичных масок.
Так же как и символьные строки, двоичные строки бывают фиксированной и переменной длины. Двоичные строки фиксированной длины объявляются следующим образов:
BIT (n)
где n — длина строки в байтах. Объявление строк переменной длины выглядит так:
BIT VARYING(n) где n — максимальная длина строки в байтах.
Типы для представления даты и времени.
Очевидно, что данные типы используются для хранения информации, относящейся к датам и времени.
ПРИМЕЧАНИЕ
Иногда типы данных, предназначенные для хранения времени и даты, называются темпоральными.
В стандарте SQL определены следующие типы данных для хранения информации о дате и времени:
>> DATE - используется для хранения даты;
>> TIME - используется для хранения времени;
>> TIMESTAMP - хранит дату и время;
>> INTERVAL - хранит промежуток времени между двумя датами или между двумя моментами времени.
ПРИМЕЧАНИЕ
Следует заметить, что в большинстве реализаций SQL поддерживаются некоторые дополнительные типы данных. Кроме того, синтаксические и семантические свойства типов, определенных в стандарте ANSI SQL-92, могут различаться в отдельных реализациях SQL.
Необходимо всегда иметь в виду, что, хотя с использованием языка SQL можно определить схему базы данных, содержащую данные любого из рассмотренных типов, возможность использования этих данных в прикладных системах зависит от применяемого языка программирования.
Управление объектами базы данных.
Объект базы данных — это любой объект, определенный в базе данных и используемый для хранения информации или для обращения к информации. Примерами объектов базы данных могут служить таблицы, представления и индексы. Для управления объектами базы данных используется подмножество команд DDL языка SQL.
Создание, модификация и удаление таблиц.
Таблица является основным объектом для хранения информации в реляционной базе данных. При создании таблицы обязательно указываются имена полей, содержащихся в таблице, и типы данных, соответствующие полям. Кроме того, при создании таблицы для полей могут оговариваться ограничительные условия и значения, задаваемые по умолчанию.
Ограничительные условия — это правила, ограничивающие значения величин в поле таблицы базы данных.
Значение по умолчанию — значение, которое автоматически вводится в поле таблицы базы данных при добавлении новой записи, если пользователь не указал значение этого поля.
Оператор CREATE TABLE.
Для создания таблицы используется оператор CREATE TABLE. Синтаксис этого оператора имеет следующий вид:
CREATE TABLE имя_таблииы ( имя__поля_1 тип_данных. икя_поля_2 тип_данных.
имя_поля_N тип__данных)
Для примера рассмотрим оператор, создающий таблицу ФИЗИЧЕСКИЕ ЛИЦА, рассмотренную в предыдущей главе:
CREATE TABLE Физические_лица (
Код_физического_лица INTEGER.
Имя VARCHAR(25).
Фамилия VARCHAR(25).
Отчество VARCHAR(25),
Дата_рождения DATE.
Адрес VARCHAR(50).
Телефон VARCHAR(25))

ПРИМЕЧАНИЕ
В приводимом примере, чтобы избежать путаницы и неоднозначности, мы использовали русские имена таблицы и полей. При создании же реальных таблиц реальной базы данных следует иметь в виду, что далеко не все СУБД допускают использование символов кириллицы в именах полей и таблиц. Более того, даже если СУБД позволяет использовать русские буквы, желательно все же использовать в именах объектов базы данных только латинские символы, особенно если для создания интерфейсной части информационной системы предполагается использовать средства разработки третьих фирм. Это позволит избежать целого ряда трудноразрешимых проблем.
Оператор ALTER TABLE.
Созданная таблица может быть модифицирована с использованием оператора ALTER TABLE. С помошью этого оператора можно добавлять и удалять поля таблицы, изменять тип данных полей, добавлять и удалять ограничения.
ПРИМЕЧАНИЕ
Оператор ALTER TABLE не определен в стандарте ANSI. Однако он поддерживается в большинстве реализаций SQL, обеспечивая существенно большую гибкость управления структурой базы данных. Если же используемая СУБД не поддерживает ALTER TABLE, то можно просто создать новую таблицу с измененной структурой и затем перенести в нее данные из старой таблицы, после чего старую таблицу можно будет удалить.
В общем виде синтаксис оператора ALTER TABLE выглядит следующим образом:
ALTER TABLE имя таблицы [MODIFY] [имя_поля тип_дакных] tADD] [имя_поля тип_данных] [DROP] [имя_поля]
Действие, выполняемое оператором ALTER TABLE, определяется ключевым словом,
указываемым после имени таблицы:
>> MODIFY — изменяет определение поля;
>> ADD — добавляет новое поле в таблицу;
>> DROP — удаляет поле из таблицы.
Для изменения типа данных ноля используется следующий синтаксис оператора
ALTER TABLE;
ALTER TABLE имя_табпицы ADD (имя_поля тип_данных)
Например, для того, чтобы добавить в таблицу ФИЗИЧЕСКИЕ ЛИЦА поле, в котором будет содержаться адрес электронной почты сотрудника, следует использовать следующий оператор:
ALTER TABLE Физические_лица ADO (Email CHARACTERS))
Если же требуется изменить тип данных существующего поля, то следует использовать оператор ALTER TABLE в паре с ключевым словом MODIFY:
ALTER TABLE имя_таблицы MODIFY (имя_поля тип_данных)

Пусть, например, после того как мы добавили в таблицу ФИЗИЧЕСКИЕ ЛИЦА поле Email, выяснилось, что использование типа CHARACTER для этого поля неэф¬фективно — у многих сотрудников нет электронной почты и, следовательно, часть дискового пространства расходуется впустую. Целесообразнее применить для этого поля тип данных VARCHAR. Для изменения типа данных вызовем оператор ALTER TABLE:
ALTER TABLE Физические_лица MODIFY (Email VARCHAR(25))
Удаление существующего поля выполняется вызовом оператора ALTER TABLE с ключевым словом DROP:
ALTER TABLE имя_таблицы DROP (имя_поля)

ПРИМЕЧАНИЕ
Следует быть очень осторожным при использовании оператора ALTER TABLE. Непродуманное внесение изменений в таблицы уже работающей базы данных может привести к нарушению работы всей системы в целом.
Оператор DROP TABLE.
Для удаления таблиц используется оператор DROP TABLE. Синтаксис этого оператора имеет следующий вид:
DROP TABLE имя_таблицы [RESTRICT | CASCADE]
Если при вызове оператора DROP TABLE используется ключевое слово RESTRICT и на удаляемую таблицу ссылается какое-либо представление или ограничение, то при выполнении оператора удаления таблицы будет сгенерировано сообщение об ошибке. Если же использовать ключевое слово CASCADE, то удаление таблицы будет выполнено и вместе с таблицей будут удалены все ссылающиеся на нее представлении и ограничения.
Задание ограничений.
Ограничения используются для того, чтобы обеспечить достоверность и непротиворечивость информации в базе данных. Существует достаточно большое количество различного рода ограничений, из которых мы рассмотрим лишь основные;
>> ограничение NOT NULL;
>> ограничение первичного ключа;
>> ограничение UNIQUE;
>> ограничение внешнего ключа;
>> ограничение CHECK.
Oграничение NOT NULL.
Ограничение NOT NULL может быть установлено для любого поля реляционной таблицы. При наличии этого ограничения запрещается ввод значений NULL в поле, для второго это ограничение установлено.
ПРИМЕЧАНИЕ
Следует понимать, что значение NULL не эквивалентно ни нулевому значению для числовых полей, ни пробелу для полей текстовых — если в поле занесено значение «О» (или « »), то поле не пустое, а содержит число 0 (или строку, состоящую из одного пробела). Если же значение поля равно NULL, то это означает, что поле содержит неопределенное значение (поле пустое), то есть в него не была занесена никакая информация.
Ограничение NOT NULL устанавливается при создании таблицы с помощью оператора CREATE TABLE. Чтобы задать ограничение NOT NULL для некоторого поля, следует просто указать NOT NULL после указания типа поля:

CREATE TABLE иня_таблицы (
имя_поля_1 тип_данных NOT NULL.
имя_поля_2 тип_данных NULL.
...
имя_поля_N тип_данных NOT NULL)


Если же после задания типа данных поля следует слово NULL, то данное поле может содержать пустые значения. Однако атрибут NULL обычно устанавливается по умолчанию, поэтому указывать его явно нет необходимости.
Ограничение NOT NULL устанавливается для тех полей, в которые при занесении данных в таблицу обязательно должна быть введена какая-либо информация. Например, в таблице, содержащей личные данные о сотрудниках организации, можно задать ограничение NOT - NULL для полей, в которых будут содержаться имя и фамилия сотрудника. Поэтому оператор создания таблицы ФИЗИЧЕСКИЕ ЛИЦА следует видоизменить следующим образом:

CREATE TABLE Физические_лица (
Код_физического_лица INTEGER.
Имя VARCHAR(25) NOT NULL.
Фамилия VARCHAR(25) NOT NULL.
Отчество VARCHAR(25).
Дата_рождения DATE.
Адрес VARCHAR(50). Телефон VARCHAR(25))

ПРИМЕЧАНИЕ
При добавлении нового поля в непустую таблицу с использованием оператора ALTER TABLE нельзя устанавливать ограничение NOT NULL для добавляемого поля. Это вполне очевидно — уже существующие записи в таблице не могут иметь в новом столбце непустые значения. Однако это ограничение можно преодолеть следующим образом:
Добавьте в таблицу поле без ограничения NOT NULL.
Заполните значения нового поля для всех существующих записей.
Измените определение нового поля с помощью команды ALTER TABLE, задав ему ограничение NOT NULL.
Ограничение первичного ключа.
Первичные ключи указываются при создании таблицы. Так как поля, входящие в состав первичного ключа, не могут принимать значение NULL, то для них обяза
тельным является ограничение NOT NULL. Ограничение первичного ключа может
быть задано двумя путями.
>> В том случае когда первичный ключ состоит только из одного поля, то он может быть задан с помощью ключевых слов PRIMARY KEY, указываемых при описании поля в операторе CREATE TABLE:
CREATE TABLE имя_таблицы (
имя_поля_1 тип_данных NOT NULL PRIMARY KEY.
имя_поля_2 тип__данных.
имя_лоля_N тип_данных NOT NULL)
Обратите внимание на то, что указание ограничения NOT NULL для поля, являющегося первичным ключом, является обязательным.
>> Первичный ключ может быть также задан в конце описания таблицы, после определений всех полей. Для этого также используется ключевая фраза PRIMARY KEY, после которой в круглых скобках указывается имя поля, составляющего первичный ключ: CREATE TABLE имя таблицы ( имя_поля_1 тип_данных NOT NULL, имя поля 2 тип_данных.
имя_поля_N тип_данных NOT NULL. PRIMARY KEY (имя_поля_1))
Второй способ особенно удобен для задания составных первичных ключей. В этом случае в скобках следует указать через запятую все поля, составляющие первичный ключ:
CREATE TABLE имя_таблицы ( имя_поля_1 тип_данных NOT NULL, имя поля_2 тип_данных. имя поля_3 тип_данных NOT NULL.
имя_поля_N тип_данных NOТ NULL. PRIMARY KEY (имя_поля_1. имя_поля_3))

ПРИМЕЧАНИЕ
При использовании составного первичного ключа ограничение NOT NULL должно быть задано для всех полей, входящих в его состав.
Ограничение UNIQUE.
Ограничение UNIQUE похоже на ограничение первичного ключа, так как при наличии этого ограничения для некоторого поля все значения, содержащиеся в этом поле, должны быть уникальными. Однако, в отличие от первичного ключа, ограничение UNIQUE допускает наличие пустых значений поля (если, конечно, для этого поля не установлено ограничение NOT NULL).
Ограничение UNIQUE задается при создании таблицы с помощью ключевого слова UNIQUE, указываемого при описании поля:
CREATE TABLE имя_таблицы (
имя_поля_1 тип_данных NOT NULL PRIMARY KEY.
имя_поля__2 тип_данных UNIQUE. имя_поля_3 тип_данных NOT MULL,
имя_поля_N тип_данных NOT NULL UNIQUE)
Можно также задать ограничение UNIQUE не для одного поля, а для группы полей. Объявление группы полей уникальной отличается от объявления уникальными индивидуальных полей, так как именно комбинация значений, а не просто индивидуальные значения, обязана быть уникальной. То есть значение каждого поля, входящего в группу, не обязательно должно быть уникальным, а комбинация значений полей всегда должна быть уникальной.
Ограничение UNIQUE для группы полей, так же как и составной первичный ключ, задается после описания всех полип таблицы:
CREATE TABLE имя_таблицы (
имя_поля_1 тип_данных NOT NULL PRIMARY KEY.
имя_поля_2 тип_данных.
имя_поля_3 тип_даиных NOT NULL.
имя лоля_N тип_данных NOT NULL UNIQUE. UNIQUE (имя_поля_2. имя_поля_3))

Ограничение внешнего ключа.
Ограничение внешнего ключа является основным механизмом для поддержания ссылочной целостности базы данных. Поле, определяемое в качестве внешнего ключа, используется для ссылки на поле другой таблицы, обычно называющееся родительским ключом, а таблица, на которую внешний ключ ссылается, называется родительской таблицей (родительский ключ часто является первичным ключом родительской таблицы).
Типы полей внешнего и родительского ключа обязательно должны быть идентичны. А вот имена полей могут быть разными. Однако во избежание путаницы желательно и имена полей для внешнего и родительского ключей задавать одинаковыми.
Внешний ключ не обязательно должен состоять только из одного поля. Подобно первичному ключу, внешний ключ может состоять из любого числа полей, которые обрабатываются как единый объект. Поля родительского ключа, на который ссылается составной внешний ключ, должны следовать в том же порядке, что и во внешнем ключе.
Когда поле таблицы является внешним ключом, оно определенным образом связано с таблицей, на которую этот ключ ссылается. Это фактически означает, что каждое значение внешнего ключа непосредственно привязано к значению в родительском ключе.
Ограничение внешнего ключа (FOREIGN KEY) может быть задано либо в операторе CREATE TABLE, либо с помощью оператора ALTER TABLE. Синтаксис ограничения FOREIGN KEY имеет следующий вид:
FOREIGN KEY имя_внешнего_ключа (список полей внешнего ключа) REFERENCES имя_длительской_таблицы (список полей родительского ключа)
Первый список полей — это список из одного или нескольких полей таблицы, разделенных запятыми. Второй список полей — это список полей, которые будут составлять родительский ключ. Списки полей, указываемые в качестве внешнего и родительского ключей, должны быть совместимы:
>> они должны иметь одинаковое число полей;
>> порядок следования полей в списках должен совпадать. Причем совпадение
определяется не именами полей, которые могут быть различны, а типами данных и размером полей. Рассмотрим пример создания базы данных со связанными таблицами:
CREATE TABLE Физические_лица (
Код_фиэического лица INTEGER NOT NULL PRIMARY KEY.
Имя VARCHAR(25)~NOT NULL.
Фамилия VARCHAR(25) NOT NULL.
Отчество WARCHAR(25).
Дата_рождения DATE.
Адрес VARCHAR(50).
Телефон VARCHAR(25))
CREATE TABLE Должности (
Код_должности INTEGER NOT NULL PRIMARY KEY.
Должность VARCHAR(50) NOT NULL UNIQUE,
Разряд INTEGER NOT NULL.
Зарплата DECIMAL (7.2) NOT NULL)
CREATE TABLE Сотрудники (
Код_сотрудника INTEGER NOT NULL PRIMARY KEY,

Код_должности INTEGER.
Код_физического_лица INTEGER NOT NULL.
Рейтинг DECIMAL(4.2).
Дата_приема DATE NOT NULL.
Дата_увольнения DATE.
FOREIGN KEY Физ_ВК (Код_физического_лица)
REFERENCES Физические_лица (Код физического_лица),
FOREIGN KEY Должн_ВК (Код_должности)
REFERENCES Должности (Код_должности))

Внешний ключ может быть добавлен и после создания таблицы — с помощью оператора ALTER TABLE (естественно, только в том случае, если используемая реализация SQL поддерживает данный оператор). Синтаксис оператора ALTER TABLE, используемый для создания внешнего ключа. Имеет следующий вид: ALTER TABLE имя_таблицы
ADD CONSTRAINT имя_внешнего_ключа FOREIGN KEY (список полей внешнего ключа) REFERENCE имя_родительской_таблицы (список полей родительского клоча).
ПРИМЕЧАНИЕ
Следует иметь в виду, что при использовании оператора ALTER TABLE для создания связи между таблицами необходимо, чтобы связываемые таблицы находились в состоянии ссылочной целостности. Иначе при попытке выполнения оператора будет выдано сообщение об ошибке.
Внешний ключ ограничивает значения, которые можно ввести в таблицу. Чтобы в поля, составляющие внешний ключ, можно было ввести некоторое значение, необходимо, чтобы это значение уже было введено в родительской таблице.
Ограничение внешнего ключа также оказывает влияние на удаление и модификацию записей родительской таблицы. Никакое значение родительского ключа, на которое ссылается какой-либо внешний ключ, не может быть удалено или изменено. Н
ельзя изменять значение родительского ключа, на который ссылается какой-либо внешний ключ — это также приведет к потере информации и нарушению ссылочной целостности базы данных.
ПРИМЕЧАНИЕ
В некоторых реализациях SQL имеется возможность задавать для внешних ключей каскадное удаление и каскадное обновление. Это означает, что при попытке удалить или модифицировать значение родительского ключа, на которое ссылается внешний ключ, соответствующие записи внешнего ключа также будут удалены (каскадное удаление) или изменены (каскадное обновление). Данные возможности отсутствуют в стандарте ANSI SQL-92.
Одним из синтаксических вариантов задания каскадного обновления и удаления является следующий:
UPDATE OF имя_родительской_таблицы CASCADES
DELETE OF имя_родительской_таблицы CASCADES
Ключевые фразы UPDATE OF и DELETE OF указываются в операторе CREATE TABLE. Вместо ключевого слова CASCADES можно указать слово RESTRICTED — в этом случае изменение и удаление значений родительского ключа, на которые ссылается внешний ключ из данной таблицы, будет запрещено.
CREATE TABLE Сотрудники (
Код_сотрудника INTEGER NOT NULL PRIMARY KEY,
Код_должности INTEGER.
Рейтинг DECIMAL (4.2). Дата_приёма DATE NOT NULL. Дата_увольнения DATE,
foreign key Физ_ВК (Код_физического_лица)
REFERENCES Физические лица (Код_физического лица). FOREIGN KEY Должн_ВК (Код_должности) REFERENCES Должности (Код_должности), UPDATE OF Физические_лица CASCADES DELETE OF Фиэические_лица RESTRICTED).

Ограничение CHECK.
Ограничение CHECK используется для проверки допустимости данных, вводимых в поле таблицы. Ограничение CHECK состоит из ключевого слова CHECK, сопровождаемого предложением предиката, который использует указанное поле. Любая попытка модифицировать или вставить значение поля, которое могло бы сделать этот предикат не¬верным, будет отклонена.
ПРИМЕЧАНИЕ
Проверка корректности значений, заносимых в базу данных, может также выполняться в пользовательских приложениях. Однако использование ограничения CHECK обеспечивает дополнительный уровень защиты от ошибок.
Задание ограничения CHECK производится при создании таблицы. Для этого после описания полей таблицы указывается ключевая фраза:
CONSTRAINT имя_ограничения CHECK (ограничение)
В рассматриваемом нами примере базы данных сотрудников организации ограничение может быть задано, например, для поля «Разряд» таблицы ДОЛЖНОСТИ. Допустим, разряд не может превышать 20. Тогда оператор создания таблицы ДОЛ Ж-НОСТИ, в котором задано это ограничение, будет иметь следующий вид:
CREATE TABLE Должности (
Код должности INTEGER NOT NULL PRIMARY KEY.
Должность VARCHAR(50) NOT NULL UNIQUE.
Разряд INTEGER NOT NULL,
Зарплата DECIMAL(4.2) NOT NULL.
CONSTRAINT CHK_RATE CHECK (Разряд<=20))
Можно задавать ограничение и для нескольких полей. Для этого следует просто включить их в ограничительное условие. Для формирования сложного ограничения, включающего несколько условий, используются логические операторы AND и OR. В таблице ДОЛЖНОСТИ можно, например, ввести еще ограничение на мини¬мальную зарплату:
CONSTRAINT CHK_RATE CHECK (Разряд<=20 AND Зарплата>=1000))

Задание значений по умолчанию.
Для полей таблицы можно задавать значения по умолчанию, которые будут заноситься в поля при добавлении новой записи в таблицу, если значения этих полей не определены.
ПРИМЕЧАНИЕ
Значение NULL фактически является значением по умолчанию, принятым для каждого поля таблицы, для которого не задано ограничение NOT NULL и которое не имеет другого значения по умолчанию.
Для задания значения по умолчанию используется директива DEFAULT, которая указывается в команде CREATE TABLE при описании поля, для которого устанавливается значение по умолчанию:
CREATE TABLE {
имя_лоля_N тип данных DEFAULT = значение_по_умолчанию
...
)
В рассматриваемом примере значение по умолчанию может быть, например, установлено для поля "Рейтинг" таблицы СОТРУДНИКИ:
CREATE TABLE Сотрудники (
Код_сотрудника INTEGER NOT NULL PRIMARY KEY.
Код_должности INTEGER,
Код_физического_лица INTEGER NOT NULL.
Рейтинг DECIMAL (4.2) DEFAULT=0.
Дата_приёма DATE NOT NULL.
...)

Создание и удаление индексов.
Стацдарт ANSI в настоящее время не поддерживает индексы. Тем не менее индексы широко применяются практически во всех базах данных, поэтому работу с ними нельзя обойти вниманием.
Синтаксис оператора создания индекса может существенно различаться в зависимости от используемой реализации SQL. Наиболее часто встречается следующая синтаксическая форма команды создания индекса:
CREATE INDEX имя_индекса
ON имя_таблиды (имя_поля_1. [имя_поля_2, ...])

ПРИМЕЧАНИЕ
Приведенная форма оператора CREATE INDEX может быть дополнена рядом многочисленных параметров, которые сильно различаются в разных реализациях SQL. Эти параметры используются, например, для упорядочивания информации по возрастанию или убыванию (параметры ASC и DESC).
Создание простого индекса.
Простой индекс является простейшей и вместе с тем распространенной разновидностью индексов. Простой индекс состоит только из одного поля (столбца) таблицы, поэтому он часто также называется одностолбцовым индексом. Наиболее типичный синтаксис команды создания простого индекса имеет вид:
CREATE INDEX имя_индекса
ОN имя_таблицы (имя_столбца)
Например, для таблицы ФИЗИЧЕСКИЕ ЛИЦА можно было бы создать индекс но полю, содержащему фамилии сотрудников, с помощью следующего оператора:
CREATE INDEX NAME_IDX
ON Физические_лица (Фамилия)

Уникальные индексы.
Уникальный индекс не допускает введения в таблицу дублируюшихся значений.
Таким образом, уникальные индексы используются не только с целью повышения
производительности, но и для поддержания целостности данных.
Типичный синтаксис оператора создания уникального индекса имеет следующий
вид:
CREATE UNIQUE INDEX имя_индекса UN имя_таблицы (имя_попя)
Например, для таблицы ДОЛЖНОСТИ можно создать уникальный индекс по полю "Должность" с помощью следующей команды:
CREATE UNIQUE INDEX POST_IDX
ON Должности (Должность)

ПРИМЕЧАНИЕ
Создать уникальный индекс для существующей таблицы можно только в том случае, если в индексируемом поле не содержится повторяющихся значений.
Составные индексы.
Составными называются индексы, построенные по двум и более полям. При создании составного индекса необходимо учитывать, что порядок следования полей в составном индексе оказывает существенное влияние на скорость поиска данных. В общем случае поля в индексе следует располагать в порядке уменьшения ограничивающих значений. Синтаксис задания составного индекса имеет следующий вид:
CREATE INDEX имя_индекса
ON имя таблиды (имя_поля_1. имя_поля_2. ...)
В нашем примере имеет смысл сослать составной индекс для полей «Фамилия» и «Имя» таблицы ФИЗИЧЕСКИЕ ЛИЦА. Оператор создания такого индекса имеет следующий вид:
CREATE INDEX FULLNAME IDX
ON Физические_лица (Фамилия, Имя)

ПРИМЕЧАНИЕ
Обратите внимание на то, что порядок следования полей в последнем примере должен быть именно таким, так как поле «Фамилия» накладывает более сильное ограничение, чем поле «Имя» — вероятность того, что у нескольких сотрудников будут одинаковые имена, выше, чем вероятность совпадения фамилий.
Удаление индексов.
Удаление индексов не вызывает никаких проблем. Для удаления необходимо знать только имя индекса (и, разумеется, обладать соответствующими правами). Синтаксис оператора удаления индекса имеет следующий вид:
DROP INDEX имя_индекса
Удаление индекса никак не влияет на информацию, содержащуюся в индексированных полях. После удаления индекс может быть создан вновь.
ПРИМЕЧАНИЕ
Типичной причиной удаления индексов является попытка увеличения производительности базы данных. Для достижения оптимальной производительности часто требуется проведение длительных экспериментов с индексами — их создание и удаление с возможным последующим воссозданием в прежнем или измененном виде.
Работа с представлениями.
Представление (View) является объектом базы данных, работа с которым ничем не отличается от работы с обычной таблицей. Отличие представлений от таблиц заключается в следующем. Обычные таблицы баз данных содержат данные. Представления же данных не содержат, а их содержимое выбирается из других таблиц (или других представлений). Таблицы (или представления), на основе которых формируются представления, принято называть базовыми таблицами (или базовыми представлениями). Фактически представление является запросом, который выполняется всякий раз, когда происходит обращение к представлению. Результат выполнения этого запроса в каждый момент времени является содержанием представления. При изменении данных в базовых таблицах представления изменяется и содержание представлений. Изменение данных в представлении также приводит к изменению данных в таблицах, на основе которых это представление создано. Использование представлений незначительно отличается от использования таблиц. Выборка данных из представления выполняется точно так же, как и из обычной таблицы. Допускаются также операции манипулирования данными представления хотя здесь имеются некоторые ограничения.
Представления в отличие от таблиц не занимают дискового пространства (или, точнее дисковое пространство, занимаемое представлениями, очень мало — только то, что требуется для хранения запроса).
Области применения представлений.
Представления в основном применяются в двух случаях:
>> с целью зашиты данных;
>> для формирования итоговых данных.
В первом случае представления применяются для того, чтобы предоставить пользователю информацию не из всей таблицы, а лишь из некоторых ее полей. Рассмотрим следующий пример. Пусть, например, информация о рейтингах сотрудников хранящаяся в поле "Рейтинг" таблицы СОТРУДНИКИ, считается конфиденциальной и право доступа к ней имеют лишь руководители организации. Но часть информации, хранящейся в этой же таблице, необходима работникам отдела кадров - данные об именах сотрудников и датах их приема на работу. В этом случае для разграничения доступа к одной таблице удобно использовать представление, отобрав для него только ту информацию, к которой должны иметь доступ служащие отдела кадров. При этом они смогут выполнять свои служебные обязанности в полном объеме и не будут иметь доступа к конфиденциальной информации.
Представления могут быть использованы для ограничения доступа не только к полям, но и к записям таблицы. Для этого достаточно в запросе на выборку данных, на основе которого создается представление, указать соответствующее ограничительное условие. Например, в рассмотренном выше примере с работниками отдела кадров можно при создании представления задать условие, которое будет исключать из представления сотрудников, занимающих определенные должности.
ПРИМЕЧАНИЕ
Как уже отмечалось, представления строятся на основе запросов к базе данных, которые будут рассмотрены далее в главе 11 «Выборка данных», посвященной подмножеству команд DQL языка SOL. Поэтому в этом разделе мы приведем лишь общие сведения о представлениях, не вдаваясь в подробности формирования запросов.
Представления также используются для формирования итоговых результатов при формировании отчетов. В том случае, когда требуется часто распечатывать отчет, формируемый на основе таблиц с часто изменяемой информацией, удобно использовать представления. Так как представление может быть создано на основе запроса, содержащего предложения группировки, то можно создать представление, получающее информацию из ряда базовых таблиц и группирующих ее необходимым образом, а при выводе отчета обращаться к этому представлению как к обычной таблице. В этом случае не нужно будет каждый раз при выводе отчета формировать сложный SQL-запрос. Кроме того, в этом случае часть логики окажется вынесенной на сторону сервера базы данных, так как формирование отчета не будет зависеть от клиентского приложения.
Создание представлений.
Для создания представлений используется оператор CREATE VIEW. Представление может быть создано на основе одной или нескольких таблиц и/или других представлений. Наиболее типичный синтаксис оператора создания представлений имеет следующий вид:
CREATE VIEW имя_представления AS {оператор выборки данных}
Оператор выборки может быть любой сложности, он может содержать любые условия отбора и предложения группировки.
После создание представления с ним можно работать как с обычной таблицей, имеющей имя, заданное в качестве имени представления. Некоторым исключением являются представления, содержащие предложения группировки. Для таких представлений нет никаких ограничений по выборке данных, но применение к ним операторов манипулирования данными (подмножества команд DDL) недопустимо.
Удаление представлений.
Удаление представлений выполняется с помощью оператора DROP VIEW, при вызове которого могут указываться параметры RESTRICT или CASCADE. Данные параметры определяют действия при удалении представления, на которое ссылаются другие представления и/или ограничения. При использовании варианта RESTRICT в этом случае будет выдано сообщение об ошибке, и удаление не будет выполнено. Если же используется режим CASCADE, то выполнение оператора DROP VIEW приведет к удалению всех базовых представлений и ограничений. Типовой синтаксис оператора DROP VIEW имеет следующий вид: DROP VIEW имя_представления [RESTRICT | CASCADE]
ПРИМЕЧАНИЕ
Удаление представления (в отличие от удаления таблицы) не приводит к удалению данных, на которые это представление ссылается. Удаляется лишь запрос на выборку данных, на основе которого было создано представление.
Хранимые процедуры.
Хранимые процедуры (Stored Procedure) представляют собой группы связанных операторов SQL. Использование хранимых процедур обеспечивает дополнительную гибкость при работе с базой данных, так как выполнить хранимую процедуру обычно гораздо проще, чем последовательность отдельных операторов SQL.
Хранимые процедуры хранятся в базе данных в откомпилированном виде, что обеспечивает более высокую скорость их выполнения.
Хранимые процедуры могут получать входные параметры, возвращать значения приложению и могут быть вызваны явно из приложения или подстановкой вместо имени таблицы в инструкции SELECT.
Основные преимущества, которые дает использование хранимых процедур, заключаются в следующем:
>> хранимые процедуры позволяют вынести часть логики на сервер базы данных. Это ослабляет зависимость базы данных информационной системы от клиентской части;
>> хранимые процедуры обеспечивают модульность проекта: они могут быть общими для клиентских приложений, которые обращаются к одной и той же базе данных, что позволяет избегать повторяющегося кода и уменьшает размер приложений;
>> хранимые процедуры упрощают сопровождение приложений; при обновлении процедур изменения автоматически отражаются во всех приложениях, которые их используют, без необходимости повторной компиляции и сборки;
>> хранимые процедуры повышают эффективность работы информационной системы; они выполняются сервером, а не клиентом, что снижает сетевой трафик;
>> скорость выполнения хранимых процедур выше, чем для последовательности отдельных операторов SQL. Это связано с тем, что хранимые процедуры хра¬нятся на сервере в откомпилированном виде.
Различают два вида хранимых процедур:
>> процедуры выбора, которые приложения могут использовать вместо таблиц или представлений в операторе выборки данных. Процедура выбора должна возвращать одно или несколько значений, иначе результатом выполнения процедуры будет ошибка;
>> выполняемые процедуры, которые вызываются явно с использованием специального оператора. Выполняемая процедура может не возвращать результата вызываемой программе.
Создание хранимых процедур.
Для создания хранимых процедур используется оператор CREATE PROCEDURE. Синтаксис этого оператора сильно зависит от используемой реализации SQL, поэтому
мы не будем его подробно рассматривать.
Оператор CREATE PRXEDURE определяет новую хранимую процедуру в базе данных.
Язык процедур сильно зависит от реализации SQL, но, как правило, включает все
инструкции SQL для манипулирования данными и ряд расширений, включающих:
>> условные операторы;
>> различные виды операторов цикла;
>> возможности обработки исключительных ситуаций.
Хранимые процедуры состоят из заголовка и тела. Заголовок процедуры содержит:
>> имя процедуры, которое должно быть уникальным среди имен процедур и таблиц в базе данных;
>> список входных параметров и их типов данных, которые процедура принимает из вызывающей программы (может отсутствовать);
>> список выходных параметров и их типов данных, если процедура возвращает значения в вызывающую программу.
Тело процедуры содержит:
>> список локальных переменных и их типов данных (если они используются в коде процедуры);
>> блок инструкций на языке процедур и триггеров, заключенный между ключевыми словами BEGIN и END. Блок может включать в себя другие блоки, реализуя несколько уровней вложенности.
Выполнение хранимых процедур.
Оператор, запускающий хранимую процедуру на выполнение, зависит от типа про¬цедуры. Процедуры выбора выполняются при обращении к ним с помощью оператора выборки данных SELECT. Для вызова выполняемой процедуры следует использовать специальный оператор EXECUTE, Синтаксис этого оператора зависит от используемой реализации SQL.
Удаление хранимых процедур.
Для удаления хранимых процедур используется оператор DROP PROCEDURE. Синтаксис этого оператора является достаточно общим для различных реализаций SQL и имеет следующий вид:
DROP PROCEDURE имя_хранимой_процедуры
Триггеры.
Триггеры представляют собой разновидность хранимых процедур. Однако в отличие от хранимых процедур выполнение триггера происходит не в результате явного вызова некоторого оператора SQL, а при выполнении одного из операторов манипулирования данными, вносящими изменения в базу данных. При этом триггеры могут исполняться как до, так и после выполнения оператора манипулирования данными.
ПРИМЕЧАНИЕ
В определенном смысле триггеры являются аналогами обработчиков событий языка Object Pascal (и ряда других языков).
Триггеры используются для обеспечения ссылочной целостности данных в базе.
Они предоставляют следующие возможности:
>> возможность контроля вводимых данных, чтобы гарантировать, что пользователь ввел в поля таблицы только допустимые значения;
>> упрощение сопровождения приложений, так как изменение в триггере автоматически отражается во всех приложениях, которые используют таблицы со связанными с ними триггерами;
>> автоматическое документирование изменений таблицы. Приложение может управлять журналом изменений с помощью триггеров, которые выполняются всякий раз, когда происходит изменение таблицы.
Создание триггера.
Для создания триггера используется оператор CREATE TRIGGER. Синтаксис этого оператора существенно зависит от используемой реализации SQL, поэтому мы не будем рассматривать его подробно и поговорим лишь об общих особенностях создания триггеров.
Так же как и хранимые процедуры, триггеры состоят из заголовка и тела. Заголовок триггера содержит:
>> имя триггера, уникальное внутри базы данных;
>> имя таблицы, с которой связан триггер;
>> инструкции, которые определяют, когда триггер будет выполняться (при выполнении какого оператора манипулирования данными и в какой момент времени — до или после выполнения оператора).
Тело триггера содержит:
>> список локальных переменных и их типов данных (если они используются в коде триггера);
>> блок инструкций на языке процедур и триггеров, заключенный между ключевыми словами BEGIN и END. Блок может содержать в себе другой блок, реализуя несколько уровней вложенности. Таким образом, отличие триггера от хранимой процедуры заключается только в заголовке. Триггер связан с таблицей. Владелец таблицы и любой пользователь, наделенный
привилегиями на таблицу, автоматически имеют права выполнять связанные с ней триггеры.
ПРИМЕЧАНИЕ
После создания триггера в него нельзя внести изменения. Чтобы внести изменения в уже созданный триггер, необходимо удалить его и создать заново. Некоторые реализации SQL также допускают замену триггера (в том случае, если триггер с указанным именем уже существует) при выполнении оператора CREATE TRIGGER (при этом нет необходимости явно удалять ранее созданный триггер).
Удаление триггера.
Для удаления триггера используется оператор DROP TRIGGER. Синтаксис этого оператора является достаточно общим для различных реализаций SQL и имеет следующий вид:
DROP TRIGGER имя_триггера
Манипулирование данными.
Для манипулирования данными, хранящимися в базе данных, используется группа операторов SQL, выделяемая в качестве отдельного типа команд, называемых языком манипулирования данными (DML - Data Manipulation Language). С помощью операторов DML пользователь может загружать в таблицы новые данные, модифицировать и удалять существующие данные. В языке SQL определены только три основных оператора DML:
>> INSERT;
>> UPDATE;
>> DELETE.
Добавление в таблицу новой информации.
Процесс ввода в таблицу базы данных новой информации обычно называется загрузкой данных. Для загрузки данных используется оператор INSERT.
Добавление к таблице новой записи.
Для добавления к таблице новой записи используется следующая синтаксическая форма оператора INSERT:
INSERT INTO имя_таблицы
VALUES (значение_1. значение_2 значение_N)
При использовании данной формы оператора INSERT список VALUES должен содержать количество значений, равное количеству полей таблицы. Причем тип данных каждого из значений, указываемых в списке VALUES, должен совпадать с типом данных поля, соответствующего этому значению.
ПРИМЕЧАНИЕ
Последовательность полей определяется последовательностью их описания в операторе CREATE TABLE, с помощью которого таблица была создана.
Значения, относящиеся к символьным типам и датам, должны быть заключены в апострофы. В списке значений может также использоваться значение NULL. Рассмотрим пример. Таблица ДОЛЖНОСТИ была создана с использованием следующего оператора:
CREATE TABLE Должности С
Код_должности INTEGER NOT NULL PRIMARY KEY.
Должность VARCHAR(50) NOT NULL UNIQUE.
Разряд INTEGER NOT NULL.
Зарплата DECIMAL(7.2) NOT NULL)

Для добавления новой записи в эту таблицу следует использовать следующий оператор INSERT:
INSERT INTO Должности
VALUES (12. 'Ведущий профашист', 12. 2000.00.)

Ввод данных в отдельные поля таблицы.
При добавлении данных в таблицу можно заполнять не все поля, а лишь некоторые из них. В этом случае используется следующая синтаксическая форма оператора INSERT:
INSERT INTO имя_таблицы (имя_поля_1. имя_поля_2. ".... имя_поля_N) VALUES (значение_1. значение_2. .... значение_N)
Например, при добавлении информации о новом сотруднике в таблицу ФИЗИЧЕСКИЕ ЛИЦА необходимо указать только информацию о полном имени сотрудника. В этом случае можно использовать следующий оператор:
INSERT INTO Физические_лица (Код_физического_лица. Имя.
Фамилия. Отчество)
VALUES (234.'Иванов','Федор','Михайлович')

ПРИМЕЧАНИЕ
Список полей в операторе INSERT может иметь произвольный порядок, не зависящий от порядка задания полей при создании таблицы. Однако список значений должен соответствовать порядку, в котором указаны поля, связанные с этими значениями.
При выполнении данного оператора во все остальные поля будет занесено значение NULL. Естественно, что поля, которые не указываются в круглых скобках после имени таблицы, не должны иметь ограничения NOT NULL, иначе попытка выполнения оператора INSERT окажется неудачной.
Занесение в таблицу данных, содержащихся в другой таблице.
Иногда требуется перенести часть информации из одной таблицы в другую. Такого рода операцию можно выполнить с помощью комбинации оператора INSERT с оператором выборки данных SELECT.
ПРИМЕЧАНИЕ
С помощью оператора выборки данных SELECT формируется запрос - обращение к базе данных с целью получения определенной информации. Объединяя операторы INSERT и SELECT, можно добавить в таблицу данные, полученные в результате выполнения запроса из другой таблицы (таблиц). Синтаксис оператора INSERT в этом случае будет иметь следующий вид;
INSERT INTO имя таблицы (имя_поля_1. иия_поля_2 имя_поля_N)
SELECT [* | имя_поля_1. имя_поля_2. ... имя_поля_N]
FROM имя_таблицы
WHERE условие

В данном операторе вместо предложения VALUES используется оператор SELECT. Кратко поясним синтаксис этого оператора. После слова SELECT указывается список полей, значения которых включаются в выборку (если после SELECT указать символ *, то в выборку будут включены все поля). Предложение FROM используется для указания имени таблицы, из которой производится выборка данных. Предложение WHERE является необязательным и используется для наложения ограничений на данные, включаемые в выборку.
Количество полей, указываемых в круглых скобках после имени таблицы в операторе INSERT, должно быть равно количеству полей, включаемых в выборку. Соответствие полей определяется порядком их следования: первому полю в списке оператора INSERT соответствует первое поле в списке оператора SELECT и т. д.
Изменение данных, хранящихся в таблице.
Для изменения данных, уже занесенных в таблицу, используется оператор UPDATE. Данный оператор не добавляет новых записей в таблицу, а заменяет существующие данные на новые. Оператор UPDATE может быть применен как к одному полю таблицы (наиболее часто используемый случай), так и к нескольким полям. Количество изменяемых записей зависит от потребностей пользователя — с помощью UPDATE можно изменить как одну, так и несколько записей (вплоть до изменения значения всех записей, содержащихся в таблице).
Модификация данных в одном поле таблицы.
Для изменения данных только в одном из полей таблицы используется наиболее простая форма оператора UPDATE, имеющая следующий вид:
UPDATE имя_таблицы SET имя_поля - значение [WHERE условие]
Смысл отдельных синтаксических элементов оператора UPDATE достаточно очевиден: после ключевого слова UPDATE указывается имя таблицы, в которой модифицируются данные, после ключевого слова SET выполняется присвоение полю с заданным именем нового значения. Условие, задаваемое с помощью необязательного предложения WHERE, определяет количество записей, которые будут модифициро¬ваны.
ПРИМЕЧАНИЕ
Условие, указываемое в предложении WHERE оператора UPDATE, формируется по тем же правилам, что и условие, задаваемое в предложении WHERE оператора SELECT.
Рассмотрим пример. Допустим, требуется изменить номер телефона сотрудника организации, хранящийся в таблице ФИЗИЧЕСКИЕ ЛИЦА (такая необходимость может возникнуть либо при смене номера телефона, либо в случае корректировки ошибочно занесенных данных). В этом случае оператор UPDATE должен изменить значение только одного поля и только в одной записи. Поэтому в предложении WHERE необходимо указать такое условие, которое бы выбирало необходимую нам запись. Наиболее простым решением будет использовать для отбора нужной записи поле первичного ключа "Код_физического_лица". Значения, хранящиеся в этом поле, уникальны и однозначно определяют сотрудника. Тогда оператор UPDATE, выполняющий изменение номера телефона, будет иметь следующий вид:
UPDATE Физические_лица
SET Телефон - 4095) 2347890
WHERE Код_фиэического_лица - 16
Данный оператор изменит значение номера телефона только для записи, соответствующей сотруднику, зарегистрированному в базе данных под номером 16. Если бы мы не задали ограничительного условия в приведенном выше операторе, то значение номера телефона было бы изменено для всех записей в таблице.
ПРИМЕЧАНИЕ
При использовании оператора UPDATE необходимо быть очень внимательным и правильно формулировать ограничительные условия. В противном случае выполнение оператора UPDATE может привести к потере информации, хранящейся в базе данных.
Изменение значений в нескольких полях таблицы
С помощью оператора UPDATE можно одновременно изменять значения в нескольких полях таблицы. Для этого следует указать после ключевого слова SET не одно, а несколько полей:
UPDATE имя_таблицы
SET имя_поля_1 - значение_1.
имя_поля_2 - эначение_2.
имя_поля_М - значение_N
[WHERE условие]
Использование оператора в данной форме ничем не отличается от рассмотренного ранее. Здесь точно так же нужно быть очень осторожным при формировании условия.
Удаление данных из таблицы.
Удаление данных из таблицы выполняется с помощью оператора DELETE. Данный оператор полностью удаляет всю запись, а не данные из отдельных полей. Синтаксис оператора DELETE имеет следующий вид:
DELETE FROM имя_таблицы
[WHERE условие]
Удаляемые записи определяются в соответствии с условием, заданным с помощью необязательного предложения WHERE. При отсутствии предложения WHERE в операторе DELETE данные будут удалены из всей таблицы,

Управление безопасностью базы данных.
Одной из важнейших задач управления базами данных является обеспечение безопасности данных, то есть защиты данных от их несанкционированного использования.
ПРИМЕЧАНИЕ
Под несанкционированным использованием обычно понимается доступ к данным со стороны пользователей, не имеющих на это права.
Обеспечение безопасности данных является очень серьезным вопросом, детальное рассмотрение которого требует отдельной объемной книги. Поэтому здесь мы
обсудим лишь один из аспектов обеспечения безопасности, а именно — управление доступом к базе данных.
Привилегии пользователей.
Привилегиями называются уровни полномочий пользователей. Разграничение доступа к информации, хранящейся в базе данных, регулируется с помощью привилегий.
Различают привилегии двух типов:
>> системные привилегии;
>> объектные привилегии.
Рассмотрим каждый из типов более подробно.
Системные привилегии.
Системные привилегии дают пользователям базы данных возможность выполнять действия, связанные с ее администрированием: создавать, удалять и изменять структуру как самой базы данных, так и отдельных ее объектов. Кроме того, системные привилегии дают право на изменение состояния базы данных и ее отдельных объектов.
Возможные системные привилегии существенно зависят от используемой СУБД. Но в любом случае они включают такие привилегии, как право на:
>> создание таблицы;
>> создание представления;
>> создание хранимой процедуры;
>> удаление таблицы;
>> удаление представления;
>> удаление хранимой процедуры.
Этот список может быть расширен. Кроме того, каждая из привилегий имеет свои особенности в различных СУБД.
Объектные привилегии.
Объектные привилегии представляют собой уровни полномочий пользователей, распространяемые на объекты базы данных. Это означает, что для того, чтобы выполнять определенные действия над объектами базы данных, пользователь дол¬жен иметь соответствующие права.
Стандартом ANSI предусмотрены следующие объектные привилегии:
>> SELECT — разрешает производить выборку данных из указанной таблицы (представления);
>> INSERT (имя_поля) — разрешает выполнять добавление данных в определенное
поле указанной таблицы (представления);
>> INSERT — разрешает добавление данных во все поля указанной таблицы (представления);
>> UPDATE (имя_поля) — разрешает модифицировать данные в заданном поле указанной таблицы (представления);
>> UPDATE — разрешает модифицировать данные во всех полях указанной таблицы (представления);
>> REFERENCE (имя_поля) — разрешает ссылаться па заданное поле указанной таблицы (эта привилегия требуется при установке любых ограничений целостности);
>> REFERENCE — позволяет ссылаться на все поля указанной таблицы.
ПРИМЕЧАНИЕ
Кроме указанных существует целый ряд объектных привилегий, доступных в различных СУБД.
Управление доступом к базе данных.
Для управления доступом пользователей к базе данных в языке SQL существуют
два оператора:
>> GRANT;
>> REVOKE.
Как правило, эти операторы используются администратором базы данных или его
помощником по безопасности.
Оператор GRANT.
Оператор GRANT используется для предоставления пользователю как системных, так и объектных привилегий. Синтаксис данного оператора имеет следующий вид:
GRANT привилегия_1 [. привилегия_2]
ON имя_объекта
ТО имя_пользователя [WITH GRANT OPTION]
Предоставление пользователю с именем USER права на выбор данных из таблицы СОТРУДНИКИ выполняется с помощью следующего оператора:
GRANT SELECT
ON Сотрудники
ТО USER
С помощью одного оператора GRANT можно задавать сразу несколько привилегий. Например, следующий оператор предоставит пользователю USER право как просматривать, так и добавлять данные в таблицу СОТРУДНИКИ:
GRANT SELECT. INSERT
ON Сотрудники
TO USER
При вызове оператора GRANT может использоваться необязательное предложение WITH GRANT OPTION. Данное предложение означает, что пользователь, для которого предоставляются привилегии, также получает право предоставлять привилегии на данный объект. Например, если вызвать рассмотренный выше оператор с предложением WITH GRANT OPTION, то пользователь с именем USER, кроме права просматривать и добавлять данные в таблицу СОТРУДНИКИ, получит также право предоставлять эти привилегии другим пользователям:
GRANT SELECT. INSERT
ON Сотрудники
TO USER
WITH GRANT OPTION

Оператор REVOKE.
Оператор REVOKE используется для отмены предоставленных пользователю привилегий. Данный оператор может вызываться с одним из двух параметров — RESTRICT или CASCADE. При использовании варианта RESTRICT оператор REVOKE будет успешно выполнен только в том случае, если его выполнение не приведет к появлению так называемых оставленных привилегий.
ПРИМЕЧАНИЕ
Оставленными называются привилегии, оставшиеся у пользователя, которому они были предоставлены с помощью предложения WITH GRANT OPTION оператора GRANT.
При использовании режима CASCADE удаляются все привилегии, которые могли бы остаться у других пользователей. Это означает, что если пользователю USER1 были предоставлены привилегии с помощью параметра WITH GRANT OPTION, а он, в свою очередь, предоставил эти привилегии пользователю USER2, то отмена приви¬легий пользователю USER1 в режиме CASCADE приведет к отмене привилегий и для пользователя USER2. Синтаксис оператора REVOKE имеет следующий вил:
REVOKE привилегия_1 [. привилегия_2]
ON имя объекта
FROM имя_пользователя [RESTRICT | CASCADE]
Например, для отмены права добавления данных в таблицу СОТРУДНИКИ для пользователя USER следует использовать следующий оператор;
REVOKE INSERT ON Сотрудники FROM USER

ГЛАВА 6. Проектирование структуры базы данных.

В предыдущей главе было рассмотрено создание базы данных и входящих в нее таблиц с помощью SQL-конструкций. Этот подход можно применить при конструировании небольших информационных систем, но создание больших баз данных, содержащих сотки и тысячи таблиц и сложные связи между ними, возможно только при использовании CASE-средств. Вручную очень трудно разработать и представить графически структуру системы, проверить ее на полноту и непротиворечивость, отслеживать версии и выполнять модификации.
В данной главе мы рассмотрим создание концептуальной и физической моделей, а затем их использование для создания и модификации структуры базы данных с помощью современных CASE-средств.
Концептуальное моделирование структуры данных.
Широкое распространение реляционных СУБД и их использование в самых разнообразных приложениях показывает, что реляционная модель данных достаточна для моделирования предметных областей. Однако проектирование реляционной базы данных я терминах отношений на основе рассмотренного нами ранее механизма нормализации (см. главу 4 «Реляционные базы данных») часто представляет собой очень сложный и неудобный для проектировщика процесс. Это обусловлено некоторой ограниченностью реляционной модели данных, которая особенно ярко проявляется в следующих аспектах:
> реляционная модель не предоставляет достаточных средств для представления смысла данных. Проектировщик должен независимым от модели способом представлять семантику реальной предметной области. Примером данного ограничения может служить представление ограничений целостности;
> в ряде случаев предметную область трудно моделировать на основе плоских таблиц. Сложности могут возникнуть на начальной стадии проектирования при описании предметной области в виде одной (возможно, даже ненормализованной) таблицы;
> хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не содержит никаких средств для представления этих зависимостей;
> несмотря на го что процесс проектирования начинается с выделения некоторых объектов (сущностей) предметной области, существенных для приложения, и выявления связей между этими сущностями, реляционная модель данных не предлагает какого-либо аппарата для разделения сущностей и связей.
Концептуальные модели данных.
Для преодоления ограничений реляционной модели и обеспечения потребности проектировщиков баз данных в более удобных и мощных средствах моделирования предметной области проектирование баз данных обычно выполняется не в терминах реляционной модели, а с использованием концептуальных моделей предметной области.
Обычно различают концептуальные модели двух видов:
> объектно-ориентированные модели, в которых сущности реального мира представляются в виде объектов, а не записей реляционных таблиц;
> семантические модели, отражающие значения реальных сущностей и отношений. Объектно-ориентированную модель можно рассматривать как результат объединения семантической модели данных и объектно-ориентированного языка программирования.
Несмотря на то что в последнее время все большее распространение получают объектно-ориентированные модели, не снижается и значение семантических моделей. Концептуальное моделирование баз данных на основе семантических моделей поддерживается во всех известных. CASE-средствах (например, таких как ERWin и Power Designer). Кроме того, семантические модели более просты для понимания, особенно при проектировании сравнительно небольших баз данных. Как и реляционная модель, любая развитая семантическая модель данных включает структурную, манипуляционную и целостную части. Главным назначением семантических моделей является обеспечение возможности выражения семантики данных. Цель семантического моделирования — обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому семантическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами семантических моделей являются сущности, связи между ними и их свойства (атрибуты).
Модель «сущность-связь».
Одной из наиболее популярных семантических моделей данных является модель "сущность-связь" (часто называемая также ER-моделью - по первым буквам английских слов Entity (сущность) и Relation (связь)).
На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом в 1976г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в CASE-средствах, предназначенных для автоматизированного проектирования реляционных баз данных.
Для моделирования структуры данных используются ER-диаграммы (диаграммы «сущность-связь»), которые в наглядной форме представляют связи между сущностями. В соответствии с этим ER-диаграммы получили распространение в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз данных. Наиболее распространенными являются диаграммы, выполненные в соответствии со стандартом IDEF1X, который используют наиболее популярные CASE-системы (в частности, ERwin, Design/IDЕЕ, Power Designer). Основными понятиями ER-диаграммы являются сущность, связь и атрибут,
Сущность.
Сущность — это реальный или виртуальный объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению. Если не вдаваться в подробности, то можно считать, что сущности соответствуют таблицам реляционной модели. Каждая сущность должна обладать следующими свойствами:
> иметь уникальный идентификатор;
> содержать один или несколько атрибутов, которые либо принадлежат сущности, либо наследуются через связь с другими сущностями;
> содержать совокупность атрибутов, однозначно идентифицирующих каждый
экземпляр сущности.
Любая сущность может иметь произвольное количество связей с другими сущностями.
Связь.
Связъ -это соединение двух сущностей, при котором, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Связь представляется в виде линии, связывающей две сущности или идущей от сущности к ней же самой. Для каждой связи между сущностями указываются правила, обеспечивающие ее поддержание.
Атрибут.
Атрибут является характеристикой сущности, значимой для рассматриваемой предметной области. В ER-диаграммах список атрибутов сущности отображается в виде строк внутри прямоугольника с изображением сущности. В реляционных базах данных аналогом атрибута является поле таблицы.
Общие сведения о CASE-средствах.
За последнее десятилетие в области технических средств программирования сфор¬мировалось новое направление - CASE-технология (Computer-Aided Software/ System Engineering). CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем и поддерживается комплексом взаимосвязанных средств автоматизации. При использовании методологий структурного анализа появился ряд ограничений (сложность понимания, большая трудоемкость и стоимость использования, неудобство внесения изменений в проектные спецификации и т. д.). СASЕ-технологии с самого начала развивались именно с целью преодоления этих ограничений путем автоматизации процессов анализа и интеграции поддерживающих средств.
Основные возможности CASE-средств.
Современные CASE-средства охватывают обширную область поддержки многочис¬ленных технологий проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл программного обеспечения. Наиболее трудоемкими этапами разработки информационной системы являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В наиболее полном виде CASE-средства обладают следующими характерными особенностями:
> единый графический язык. CASE-технологии обеспечивают всех участников проекта, включая заказчиков, единым строгим, наглядным и интуитивно понятным графическим языком, позволяющим получать обозримые компоненты с простой и ясной структурой. При этом программы представляются двумерными схемами (которые проще в использовании, чем многостраничные описания), позволяющими заказчику участвовать в процессе разработки, а разработчикам — общаться с экспертами предметной области, разделять деятельность системных аналитиков, проектировщиков и программистов, облегчая им защиту проекта перед руководством, а также обеспечивая легкость сопровождения и внесения изменений в систему;
> единая база данных проекта. Основа CASE-технологии — использование базы данных проекта (репозитория) для хранения всей информации о проекте, которая может совместно использоваться разработчиками в соответствии с их правами доступа. Содержимое репозитория включает не только информационные объекты различных типов, но и отношения между их компонентами, а также правила использования или обработки этих компонентов. Репозиторий может хранить объекты различных типов: структурные диаграммы, определения экранов и меню, проекты отчетов, описания данных, логику обработки, модели данных, их организации и обработки, исходные коды, элементы данных и т. п.;
> интеграция средств. На основе репозитория осуществляются интеграция CASE-средств и разделение системной информации между разработчиками. При этом возможности репозитория обеспечивают несколько уровней интеграции: общий пользовательский интерфейс по всем средствам, передачу данных между средствами, интеграцию этапов разработки через единую систему представления фаз жизненного цикла, передачу данных и средств между различными платформами;
> поддержка коллективной разработки и управления проектом, CASE-технология поддерживает групповую работу над проектом, обеспечивая возможность работы в сети, экспорт-импорт любых фрагментов проекта для их развития и/или модификации, а также планирование, контроль, руководство и взаимодействие, то есть функции, необходимые в процессе разработки и сопровождения проектов. Эти функции также реализуются на основе репозитория. В частности, через репозиторий могут осуществляться контроль безопасности (ограничения и привилегии доступа), контроль версий и изменений и т. п.;
> макетирование. CASE-технология дает возможность быстро строить макеты (прототипы) будущей системы, что позволяет заказчику на ранних этапах разработки оценить, насколько она устраивает его и приемлема для будущих пользователей;
> генерация документации. Вся документация по проекту генерируется автоматически на базе репозитория (как правило, в соответствии с требованиями действующих стандартов). Несомненное достоинство CASE-технологии заключается в том, что документация всегда отвечает текущему состоянию дел, поскольку любые изменения в проекте автоматически отражаются в репозиторий (известно, что при традиционных подходах к разработке программного обеспечения доку¬ментация в лучшем случае запаздывает, а ряд модификаций вообще не находит в ней отражения);
> верификация проекта. CASE-технология обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки, что влияет на успех разработки в целом;
> автоматическая генерация программного кода. Генерация программного кода осуществляется на основе репозитория и позволяет автоматически построить до 85-90% текстов на языках высокого уровня.
> сопровождение и реинжиниринг. Сопровождение системы в рамках CASE-технологии характеризуется сопровождением проекта, а не программных кодов. Средства реинжиниринга и обратного инжиниринга позволяют создавать модель системы Из ее кодов и интегрировать полученные модели в проект, автоматически обновлять документацию при изменении кодов, автоматически из¬менять спецификации при редактировании кодов и т. п. далеко не все CASE-срсдства поддерживают все указанные выше возможности. Поэтому обычно к CASE-средгтиам относят любой программный продукт, автоматизирующий ту или иную совокупность процессов жизненного цикла программного обеспечения и обладающий следующими основными характерными особенностями:
> наличие мощных графических средств для описания и документирования информационной системы, обеспечивающих удобный интерфейс с разработчиком и развивающих его творческие возможности;
>интеграция отдельных компонентов CASE-средств, обеспечивающая управляемость процесса разработки информационной системы;
>использование специальным образом организованного хранилища проектных метаданных (репозитория).
Создание концептуальной модели информационной системы.
Рассмотрим создание модели информационной системы. Для этого используем пример базы данных Премьер. В качестве CASE-средства будем использовать одну из наиболее популярных систем моделирования данных — Power Designer фирмы Sybase.
База данных Премьер.
Строительная компания «Премьер» возводит различные здания. Для всех зданий требуются разнообразные материалы в различных количествах. На разных этапах проекта работают разные бригады. Например, есть бригады арматурщиков, каменщиков, штукатуров и т. д. Составляя график работ, фирма «Премьер» варьирует состав бригад. Рабочие назначаются в разные бригады в соответствии с квалификацией. Один и тот же рабочий может выполнять разные работы (например, работать как плотником, так и каменщиком), поэтому его могут включать в разные бригады. Численности бригад меняется в зависимости от размера здания и предъявляемых к нему требований. Следовательно, бригады составляются исходя из требований конкретного здания. Кроме того, для каждой бригады, работающей на строительстве данного здания, назначается бригадир. Рабочий может возглавлять одну бригаду и работать в другой простым рабочим.
В базе данных должна содержаться информация о том, кто из рабочих фирмы в какую бригаду назначен на разных зданиях, какие материалы используются при возведении разных зданий, а также график работ по каждому зданию.

Создание нового проекта в Power Designer.

Для создания концептуальной модели базы данных запустите программу Power Designer и выберите из меню File команду New. Откроется основное окно программы, которое содержит область отображения модели, меню, панель инструментов и панель элементов модели.
Прежде всего определим свойства создаваемой модели, которые используются для ее идентификации, описания и отображения в отчетах по модели. Для этого выполните команду Dictionary > Model Properties. Откроется окно диалога Model Properties. Задайте в нем наименование и идентификатор проекта, в рамках которого создается данная модель, а также наименование и идентификатор самой модели. Кроме этого, вы можете указать автора модели, используемый язык, версию модели, ввести краткое и подробное описание, аннотацию.
Создание сущностей.
Для создания сущности выберите на панели элементов значок с изображением прямоугольника, содержащего в верхней части горизонтальную линию, и перенесите его в область модели. Создастся прямоугольник для новой сущности, которая пока содержит только наименование. Для определения свойств сущности сделайте двойной щелчок на изображении прямоугольника. Откроется окно диалога Entity Properties. Перейдите на вкладку Definition и введите наименование, идентификатор и краткое описание сущности. Подробное описание вво-дится в поле редактирования на вкладке Description. При совместной разработке модели информационной системы вкладка Annotation может использоваться для замечаний и комментариев по поводу сущности. При нажатии на кнопку Attributes, расположенную на вкладке Description, открывается окно диалога ввода атрибутов сущности. Для определения бизнес-правил сущности щелкните на кнопке Rules и в открывшемся окне диалога выберите одно из ранее созданных правил.
Создание доменов.
Прежде чем перейти к непосредственному определению атрибутов сущностей, познакомимся с созданием доменов. Домены являются аналогами пользовательских типов в реляционных базах данных и могут использоваться для указания типов атрибутов сущностей. Для создания домена выполните команду Dictionary > List of Domains. Откроется окно диалога List of Domains, которое содержит таблицу со списком доменов модели.
Тип данных создаваемого домена — четырехзначное число (фактически это подтип стандартного числового типа данных Number) и его значение по умолчанию равно нулю. Для создания нового домена щелкните на кнопке New и введите в столбцы Name и Code таблицы наименование и идентификатор домена. Для определения типа данных перейдите в столбец Data Type и щелкните на кнопке с многоточием, расположенной с правого края ячейки. Откроется окно диалога Standard Data Types, в котором можно выбрать требуемый тип из большого количества базовых типов данных. В данном случае необходимо выбрать тип Number и задать в поле Length длину 4. Для определения значения по умолчанию щелкните на кнопке Check. Откроется окно диалога Check Parameters. На отображаемой по умолчанию вкладке Standard Parameters в полях области Values определите минимальное и максималь¬ное значения, а также значение по умолчанию. Здесь же вы можете задать формат, единицу измерения и список допустимых значений домена, Для определения бизнес-правил домена щелкните на кнопке Rules и выберите в открывшемся окне диалога одно из ранее созданных правил. Для ввода подробного описания и аннотации щелкните в окне диалога List of Domains на кнопках Describe и Annotation соответственно. Для каждой из них будет открыто соответствующее окно диалога, содержащее поля для ввода текста.
Определение атрибутов сущностей.
Для определения атрибутов сущности откройте окно ее свойств и щелкните на кнопке Attributes, расположенной на вкладке Description, Откроется окно диалога ввода атрибутов сущности. В таблице для каждого атрибута задаются имя, идентификатор и тип данных, который может быть одним из базовых типов или доменом, созданным пользователем. В этой же таблице устанавливаются флаг идентифицирующего атрибута и признак запрета пустого значения. Для ввода относящихся к атрибуту ограничений щелкните на кнопке Check и задайте требуемые значения в окне диалога Check Parameters.
Определение связей между сущностями.
Для создания связи между двумя сущностями выполните следующие действия:
1. Выберите на панели элементов кнопку, на которой показаны два прямоугольника, соединенные линией.
2. Соедините линией две сущности.
В модели появляется связь между выбранными сущностями, которой по умолчанию присваивается имя Relation_n, где n - порядковый номер создаваемой связи. Для определения свойств созданной связи сделайте на ней двойной щелчок мышью. Откроется окно свойств связи, в верхней части которого расположены графическое отображение связи и кнопки с наименованиями соединяемых сущностей. Введите в поля Name, Code и Label наименование связи, ее идентификатор и краткое описание. Затем задайте в области Cardinality тип связи между сущностями: один-к-одному, один-ко-многим, многие-к-одному или многие-ко-многим. В расположенных ниже двух областях для каждой сущности связи задаются обязательность, мощность связи и зависимость. Степень связности, то есть количество связываемых экземпляров данной сущности, указывается в полях Min и Мах. Свойство Mandatory определяет, является ли связь обязательной, и в зависимости от типа связи отображается на линии в виде следующих значков. При определении зависимой связи для идентификации сущности используются идентифицирующие атрибуты связанной сущности. Например, для сущности ASSIGNMENT обе связи с сущностями WORKER и BUILDING являются зависимыми. Каждый элемент сущности ASSIGNMENT однозначно определяется совокупностью идентифицирующих атрибутов сущностей WORKER и BUILDING. Для установки признака зависимой связи используется флажок Dependent.
Для типа отношения один-к-одному можно установить флажок Dominant, который указывает родительскую сущность.
Проверка модели.
При использовании CASE-срсдств можно в любой момент проверить созданную модель на наличие ошибок. Для этого выполните команду Dictionary > Check Model и установите в открывшемся окне диалога флажки проверки сущностей, атрибутов и связей. Затем щелкните на кнопке ОК для запуска процесса проверки. Ее результат будет отображаться в окне Check Model Messages. Для исправления ошибки дважды щелкните на соответствующей строке в окне сообще¬ний. Откроется связанное с этой ошибкой окно свойств сущности, атрибута или связи.
Документирование модели базы данных.
СASЕ-средства содержат прекрасные возможности для создания описания модели базы данных. Во-первых, вы можете распечатать модель в графическом виде. Для этого в Power Designer необходимо выполнить команду File > Print Graphics и указать в появляющемся окне диалога печатаемые страницы и тип цветной или черно-белой печати.
С помощью средств создания отчетов можно сформировать полное описание мо¬дели, включив в него всю необходимую информацию, которая была введена при проектировании модели. Для создания отчета выполните команду File > Create Report Откроется окно диалога со списком предопределенных типов отчетов. Вы можете выбрать любой из них и создать отчет, а при необходимости модифицировать выбранный тип отчета и сохранить его спецификацию под новым именем. При выборе режима модификации отчета открывается окно настройки, в левой части которого находится список возможных атрибутов отчета, а в правой - список атрибутов, выбранных для отображения в отчете. Используя механизм перетаскивания, вы можете выбрать любой элемент из левой части и разместить его в нужном месте шаблона отчета. Для элементов отчета можно устанавливать шрифт и параметры абзаца. Для элементов, являющихся заголовками сущностей, атрибутов и связей, можно изменять отображаемый текст. Для этого в контекстном меню элемента выберите команду Edit и измените шаблон элемента в окне редактирования.
При отображении списков сущностей, атрибутов и связей можно указать перечень отображаемых свойств, порядок их расположения в таблице, а также размеры столбцов в абсолютном и процентном выражении. Созданный отчет можно вывести на печать или сохранить в формате RTF, чтобы продолжить редактирование в текстовом процессоре.
Создание физической модели.
Концептуальная модель позволяет понять суть создаваемой информационной системы, но она не подходит для создания непосредственно структуры базы данных. Для генерации структуры базы данных необходимо преобразовать концептуальную базу данных в физическую.
Рассмотрим сначала общие принципы преобразования: о каждая сущность преобразуется в таблицу. Имя сущности становится именем таблицы; о каждый атрибут становится столбцом таблицы с тем же именем, уточняется тип данных, выбирается более точный формат;
> идентифицирующие атрибуты сущности превращаются в первичный ключ таблицы. Если для данной сущности имеются зависимые связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящегося на другом конце связи (этот процесс может продолжаться рекурсивно);
> связи многие-к-одному и один-к-одному становятся внешними ключами. Для них создается копия уникального идентификатора с одиночного конца связи, и соответствующие столбцы составляют внешний ключ;
> для первичного ключа (уникальный индекс) и внешних ключей создаются индексы;
> для связей многие-ко-многим создается таблица, столбцами которой являются уникальные идентификаторы связываемых сущностей (они составляют первичный ключ).
В Power Designer дан преобразования концептуальной модели в физическую выполните команду Dictionary > Generate Physical Model Откроется окно диалога Generating Physical Data Model (рис. 6.21), в котором прежде всего укажите тип СУБД, для которой будет создаваться модель. Затем установите флажки добавления подробных описаний и аннотаций, проверки модели перед преобразованием, определите шаблоны для определения наименований первичных и внешних ключей. Для всех связей, имеющихся в модели, задаются единые правила удаления и изменения. Если в структуре базы данных для разных связей требуются разные правила, вы можете уточнить их в физической модели. Щелкните на кнопке ОК. Запустится процесс преобразования, после завершения которого созданная модель откроется в отдельном окне. Вы можете модифицировать физическую модель, распечатывать ее в графическом виде и создавать.
Создание структуры базы данных.
После создания физической модели и ее уточнения вы можете создать структуру базы данных с помощью команды Database > Generate Database. Откроется окно диалога Parameters, в котором необходимо установить флажки создания таблиц, индексов, комментариев и т. п.
Для создания структуры базы данных непосредственно из данного окна диалога щелкните на кнопке Create database. Откроется окно диалога установления соединения с источником данных ODBC; после соединения созданный сценарий будет выполнен сервером базы данных. Однако наиболее часто используется другой путь: с помощью кнопки Generate script создается сценарии, который затем запускается на выполнение средствами сервера базы данных.
Ниже приведен текст сценария создания таблицы BUILDING и комментариев к ней и ее столбцам:

create table BUILDING (
BLDG IDNUMBER not null
BLDG_ADRESS VARCHAR(100) null
BLDG_TYPE CHAR(20) default 'Офис' not null
constraint CKC_BLDG_TYPE_BUILDING
check (BLDG_TYPE in ('Офис', 'Склад', 'Магазин','Жилой дом')).
QLTY_LEVEL NUMBER(1) null
STATUS NUMBER(1) default 1 not null
constraint CKC_STATUS_BUILD1NG check (STATUS between 1 and 3).
constraint PK_BUILDING primary key (BLDG_ID) } / comment on table BUILDING is 'Список строящихся зданий'
comment on column BUILDING.BLDG_ID is 'Идентификатор' comment on column BUILDING.BLDG_ADDRESS is 'Адрес'
comment on column BUILDING.BLDG_TYPE is 'Тип здания' /
conment on column BUILDING.QLTY_LEVEL is 'Уровень качества' /
comment on column BUILDING.STATUS is 'Статус' /

Модификация структуры базы данных.
Жизненный цикл создания и сопровождения информационной системы имеет вид спирали. Это означает, что модификация структуры базы данных практически неизбежна. Использование CASE-средств позволяет несколько облегчить поддержку нескольких версий структуры и автоматизировать создание сценариев изменения структуры базы данных.
Закончив разработку очередной версии модели базы данных, создайте архив физической модели с помощью команды Database > Archive Model Теперь вы можете модифицировать модель и после завершения создания очередной версии запустить процесс модификации структуры базы данных с помощью команды Database > Modify Database. При этом откроется окно диалога Parameters, которое, в отличие от аналогичного окна создания структуры базы данных, содержит поле для ввода имени архивированной модели. После задания всех необходимых для модификации параметров щелкните на кнопке Generate script. Power Designer сравнит текущую модель базы данных с архивированной моделью и создаст сценарий, содер¬жащий команды модификации структуры базы данных. При этом учитываются особенности выбранной СУБД. Например, в ORACLE 7.3, в отличие от некоторых других систем, отсутствует команда удаления поля таблицы. В этом случае создается временная таблица, в которую переписывается вся информация из модифицируемой таблицы. После этого таблица удаляется и создается вновь - без удаленного столбца. Затем в нее добавляются записи из временной таблицы. Ниже приведен пример удаления столбца QLTY_LEVEL из таблицы BUILDING:
alter table ASSIGNMENT
drop constraint FK_BUILDING_ASSIGNMENT /
create table tmp BUILDING (
BLDG_IDNUMBER not null
BLDG_ADDRESS VARCHAR2 (100) null
BLDG_TYPE CHAR(20) not null
QLTY_LEVEL NUMBER(1) null
STATUS_NUMBER(1) not null
)
/
insert into tmp_BUILDING (BLDG_ID. BLDG_ADDRESS. BLDG ТУРЕ. QLTY_LEVEL. STATUS) select BLDG_ID. BLDG_ADDRESS. BLDG_TYPE. QLTY_LEVEL. STATUS from BUILDING
/
drop table BUILDING cascade constraints
/
create table BUILDING (
BLDG_IDNUMBER not null.
BLDG_ADDRESS VARCHAR2(100) null
BLDG_TYPE CHAR(20) default 'Офис' not null
constraint CKC_BLDG_TYPE_BUILDING
check (BLDG_TYPE in ('Офис'.'Склад'.'Магазин'.'Жилой дом')).
STATUS NUMBER(1) default 1 not null
constraint CKC_STATUS_BUILDING check (STATUS between 1 and 3). constraint PK_BUILDING primary key (BLDG_ID) )
/
comment on table BUILDING is 'Список строящихся зданий'
/
raiment on column BUILDING. BLDG_ID is 'BLDG-ID'
/
comment on column BUILDING.BLDG_ADDRESS is 'BLDG-ADDRESS'
/
comment on column BUILDING. BLDG_TYPE is 'BLDG-TYPE'
/
comment on column BUILDING. STATUS is 'STATUS'
/
insert into BUILDING (BLDG_ID. BLDG_ADDRESS. BLDG_TYPE. STATUS)
select BLDG_ID. BLDG_ADDRESS. BLDG_TYPE. STATUS
from tmp_BUILDING
/
drop table tmp_BUILDING. cascade constraints
/
alter table ASSIGNMENT
add constraint FK_BUILDING_ASSIGNMENT foreign key (BLDG_ID)
references BUILDING (BLDG_ID) on delete cascade

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