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

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

· общая информационная модель системы;

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

· точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

· построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

· определяется необходимость распределения данных;

· производится анализ использования данных;

· производится физическое проектирование базы данных;

· определяются требования к аппаратным ресурсам;

· определяются способы увеличения производительности;

· завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

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

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

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

В качестве итога перечислим основные принципы методологии RAD:

· разработка приложений итерациями;

необязательность полного завершения работ на каждом из этапов жизненного цикла;

обязательное вовлечение пользователей в процесс разработки ИС;

необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

необходимое использование генераторов кода;

использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;

тестирование и развитие проекта, осуществляемые одновременно с разработкой;

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

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

Структурный подход

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

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

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

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

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

принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;

принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

· принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

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

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

DFD (Data Flow Diagrams) диаграммы потоков данных;

ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

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

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

Методология функционального моделирования SADT

Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

· графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;

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

· ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

· связность диаграмм (номера блоков);

· уникальность меток и наименований (отсутствие повторяющихся имен);

· синтаксические правила для графики (блоков и дуг);

· разделение входов и управлений (правило определения роли данных).

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

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

Общие положения по созданию автоматизированных информационных систем

Создание автоматизированных информационных систем регламентируется комплексом стандартов и руководящих документов. Можно выделить следующие стадии и этапы создания АИС (табл. 4.1).

Одним из центральных элементов всего процесса создания АИС является разработка технического задания, структура которого, согласно ГОСТ 34.602-89, содержит следующие разделы:

общие сведения;

назначение и цели создания (развития) системы;

характеристика объектов автоматизации;

требования к системе;

состав и содержание работ по созданию системы;

порядок контроля и приемки системы;

требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

требования к документированию;

источники разработки.

Стадии

1. Формирование требований к ИС

1.1. Обследование объекта и обоснование необходимости создания ИС.

1.2. Формирование требований пользователя к ИС.

1.3. Оформление отчета о выполненной работе и заявки на разработку ИС (тактико-технического задания)

2. Разработка концепции ИС

2.1. Изучение объекта.

2.2. Проведение необходимых научно-исследовательских работ.

2.3. Разработка вариантов концепции ИС и выбор варианта концепции ИС, удовлетворяющего требованиям пользователя.

2.4. Оформление отчета о выполненной работе

3. Техническое задание

3.1. Разработка и утверждение технического задания на создание ИС

4. Эскизный проект

4.1. Разработка предварительных проектных решений по системе и ее частям.

4.2. Разработка документации на ИС и ее части

5. Технический проект

5.1. Разработка проектных решений по системе и ее частям.

5.2. Разработка документации на ИС и ее части.

5.3. Разработка и оформление документации на поставку изделий для комплектования ИС и (или) технических требований (технических заданий) на их разработку.

5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации

6. Рабочая документация

6.1. Разработка рабочей документации на систему и ее части.

6.2. Разработка или адаптация программ

7. Ввод в действие

7.1. Подготовка объекта автоматизации к вводу ИС в действие.

7.2. Подготовка персонала.

7.3. Комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями).

7.4. Строительно-монтажные работы.

7.5. Пусконаладочные работы.

7.6. Проведение предварительных испытаний.

7.7. Проведение опытной эксплуатации.

7.8. Проведение приемочных испытаний

8. Сопровождение ИС

8.1. Выполнение работ в соответствии с гарантийными обязательствами.

8.2. Послегарантийное обслуживание

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

требования к системе в целом;

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

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

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

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

Для большинства разновидностей ИС особое значение имеют требования к информационному обеспечению. В данном подразделе, в частности, определяются требования:

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

к информационному обмену между компонентами системы;

к информационной совместимости со смежными системами;

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

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

к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;

к защите данных от разрушений при авариях и сбоях в электропитании системы;

к контролю, хранению, обновлению и восстановлению данных;

к процедуре придания юридической силы документам, продуцируемым техническими средствами ИС.

На основе установленных в техническом задании основных требований и технических решений на последующих этапах конкретизируются и непосредственно разрабатываются компоненты и элементы системы. В частности, на этапе 4.1 «Разработка предварительных проектных решений по системе и ее частям» определяются:

функции ИС;

функции подсистем;

концепция информационной базы и ее укрупненная структура;

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

состав вычислительной системы;

функции и параметры основных программных средств.

На этапе 5.1 «Разработка проектных решений но системе и ее частям» осуществляется разработка общих решений по системе и ее частям:

по функционально-алгоритмической структуре системы;

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

по структуре технических средств;

по алгоритмам решения задач и применяемым языкам;

по организации и ведению информационной базы (структура базы данных);

по системе классификации и кодирования информации (словарно-классификационная база);

по программному обеспечению.

Разработка и документация программного обеспечения в процессе создания или комплектования автоматизированных систем (п. 6.2) регламентируются комплексом стандартов, объединенных в группу «Единая система программной документации (ЕСПД)».

7. Основные сведения о системах управления базами данных (СУБД). Применение СУБД для создания информационной модели экономической системы, хранения, поиска и анализа необходимых данных, расчета и выдачи отчетных материалов и т.п. СУБД MS Access. Структура базы данных MS Access и основные типы ее объектов: Таблицы, Запросы, Формы, Отчеты, Макросы

Для построения информационных систем используют систему управления базами данных (СУБД).

Перечислим основные функции СУБД.

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

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

Управление буферами оперативной памяти.

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

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

Управление транзакциями.

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

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

Журнализация.

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

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

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

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно мы рассмотрим это в соответствующей лекции.

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

Поддержка языков БД

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные.

В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). Перечислим основные функции реляционной СУБД, поддерживаемые на "языковом" уровне (т.е. функции, поддерживаемые при реализации интерфейса SQL).

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

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

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

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

Типовая организация современной СУБД.

Естественно, организация типичной СУБД и состав ее компонентов соответствует рассмотренному нами набору функций. Напомним, что мы выделили следующие основные функции СУБД:

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

управление буферами оперативной памяти;

управление транзакциями;

журнализация и восстановление БД после сбоев;

поддержание языков БД.

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

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

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

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

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

Модель данных -- совокупность структур данных и операций по их обработке. С помощью модели данных можно наглядно представить структуру объектов и установленные между ними связи. Для терминологии моделей данных характерны понятия «элемент данных» и «правила связывания». Элемент данных описывает любой набор данных, а правила связывания определяют алгоритмы взаимосвязи элементов данных. К настоящему времени разработано множество различных моделей данных, но на практике используется три основных. Выделяют иерархическую, сетевую и реляционную модели данных. Соответственно говорят об иерархических, сетевых и реляционных СУБД.

Иерархическая модель данных.

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

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

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

Сетевая модель данных.

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

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

Реляционная модель данных.

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

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

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

Атрибут (или данное) -- это некоторый показатель, который характеризует некий объект и принимает для конкретного экземпляра объекта некоторое числовое, текстовое или иное значение. Информационная система оперирует наборами объектов, спроектированными применительно к данной предметной области, используя при этом конкретные значения атрибутов (данных) тех или иных объектах. Например, возьмем в качестве набора объектов классы в школе. Число учеников в классе -- это данное, которое принимает числовое значение (у одного класса 28, у другого-- 32). Название класса -- это данное, принимающее текстовое значение (у одного -- 10А, у другого -- 9Б и т. д.).

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

Основоположником теории реляционных баз данных считается сотрудник фирмы IBM доктор Э. Кодд, опубликовавший 6 ₍июня 1970 г. статью A Relational Model of Data for Large-Shared Data Banks (Реляционная модель данных для больших коллективных банков данных). В этой статье впервые был использован термин «реляционная модель данных. Теория реляционных баз данных, разработанная в 70-х годах в США доктором Э. Коддом, имеет под собой мощную математическую основу, описывающую правила эффективной организации данных. Разработанная Э. Коддом теоретическая база стала основой для разработки теории проектирования баз данных.

Э. Кодд, будучи математиком по образованию, предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он доказал, что любой набор данных можно представить в виде двумерных таблиц особого вида, известных в математике как «отношения».

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

Таблица состоит из столбцов (полей) и строк (записей); имеет имя, уникальное внутри базы данных. Таблица отражает тип объекта реального мира (сущность), а каждая ее строка-- конкретный объект. Каждый столбец таблицы -- это совокупность значений конкретного атрибута объекта. Значения выбираются из множества всех возможных значений атрибута объекта, которое называется доменом (domain).

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

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

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

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

Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции -- среди них не существует «первой», «второй», «последней». Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом (primary key). Часто вводят искусственное поле, предназначенное для нумерации записей в таблице. Таким полем, например, может быть его порядковый, который сможет обеспечить уникальность каждой записи в таблице. Ключ должен обладать следующими свойствами.

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

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

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

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

Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key).

При описании модели реляционной базы данных для одного и того же понятия часто употребляют различные термины, что зависит от уровня описания (теория или практика) и системы (Access, SQL Server, dBase). В табл.7.1. приведена сводная информация об используемых терминах.

Реляционные базы данных

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

Каждая таблица имеет уникальное в базе данных имя и состоит из однотипных строк.

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

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

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

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

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

Нормализация и ее необходимость.

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

- возможность хранить все необходимые данные в БД;

- исключение избыточности данных;

- необходимость свести количество хранимых таблиц к .минимуму.

При простом переносе полей бумажных форм в таблицы базы данных неизбежно возникнет ряд проблем -- даже для простых двумерных структур приходится изменять состав полей

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

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

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

Таблица считается нормализованной на определенном уровне, когда она удовлетворяет условиям, накладываемым соответствующей формой нормализации. Процесс нормализации представляет собой последовательное изменение структуры таблиц до тех пор, пока она не будет удовлетворять требованиям последней формы нормализации. Существуют следующие шесть форм нормализации: О первая нормальная форма (First Normal Form, INF);

О вторая нормальная форма (Second Normal Form, 2NF);

О третья нормальная форма (Third Normal Form, 3NF);

О нормальная форма Бойса - Кодда (Brice - Codd Normal Form, BCNF);

О четвертая нормальная форма (fourth Normal Form, 4NF);

О пятая нормальная форма, или нормальная форма проекции-соединения (Fifth Normal Form, 5NF или PJ/NF).

При описании нормальных форм используется несколько понятий.

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

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

Многозначная функциональная зависимость. Поле А однозначно определяет поле В, если для каждого значения поля А существует хорошо определенное множество соответствующих значений поля В. Например, если рассматривать таблицу предметов и оценок учеников в школе, то поле с оценкой имеет хорошо определенное множество допустимых значений (1, 2, 3, 4, 5). Кроме того, количество предметов в школе также ограничено.

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

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

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

Первая нормальная форма

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

Вторая нормальная форма

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

Итак, таблица, находящаяся во второй нормальной форме, должна удовлетворять следующим правилам:

- таблица должна содержать данные об одном типе объектов;

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

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

Если таблица имеет простой первичный ключ, состоящий только из одного

Третья нормальная форма

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