В реляционной СУБД нельзя хранить кортежи отношений на физическом уровне в нужном разработчикам порядке. Отсутствие требования к поддержанию порядка на множестве кортежей отношения придает СУБД дополнительную гибкость при хранении баз данных во внешней памяти и при выполнении запросов к базе данных. Это не противоречит тому, что при формулировании запроса к БД, например, на языке SQL можно потребовать сортировки результирующей таблицы в соответствии со значениями некоторых столбцов. Такой результат, вообще говоря, является не отношением, а некоторым упорядоченным списком кортежей, и он может быть только окончательным результатом, к которому уже нельзя адресовать запросы.
Согласно трактовке Дейта, реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части (К. Дейт, 2000).
В структурной части модели фиксируется, что единственной родовой структуройданных, используемой в реляционных БД, является нормализованное парное отношение. Определяются понятия доменов, атрибутов, кортежей, заголовка, тела и переменной отношения. По сути дела, выше рассматривалось именно понятия и свойства структурной составляющей реляционной модели.
В манипуляционной части модели определяются два фундаментальных механизма манипулирования реляционными БД – реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями и добавлениями), а второй – на классическом логическом аппарате исчисления предикатов первого порядка. Основной функцией манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка реляционных БД: язык называется реляционным, если он обладает не меньшей выразительностью и мощностью, чем реляционная алгебра или реляционное исчисление.
Из всего вышесказанного следует, что классический подход к проектированию структур реляционных БД имеет следующие проблемы:
1. идентификация функциональных зависимостей;
2. трудоемкость идентификации всех функциональных зависимостей;
3. зависимость конечного результата проектирования от опыта и субъективного взгляда проектировщика, а не от формальной методики проектирования;
4. проблема идентификации сущностей и атрибутов сущностей.
1.3 Методы проектирования БД ИС
Методология создания информационных систем заключается в организации процесса построения информационной системы и в управлении этим процессом для того, чтобы гарантировать выполнение требований, как к самой системе, так и к характеристикам процесса разработки. [18, С.130]
Основными задачами, решение которых должна обеспечивать методология создания информационных систем (ИС) (с помощью соответствующего набора инструментальных средств), являются [18, С. 131]:
- соответствие создаваемой информационной системы целям и задачам предприятия, а также предъявляемым к ней требованиям по автоматизации желаемых процессов и гарантирование создания системы с заданными параметрами в течение заданного времени в рамках оговоренного заранее бюджета;
- простота сопровождения, модификации и расширения системы с целью обеспечения ее соответствия изменяющимся условиям работы предприятия и соответствие создаваемой информационной системы требованиям открытости, переносимости и масштабируемости;
- возможность использования в создаваемой системе разработанных ранее и применяемых на предприятии средств информационных технологий (программного обеспечения, баз данных, средств вычислительной техники, телекоммуникаций).
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой информационной системы. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла информационных систем.
Основное содержание технологии проектирования составляют технологические инструкции, состоящие из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций. Данная технология может быть представлена как совокупность трех составляющих [9, С. 52]:
1. Заданной последовательности выполнения технологических операций проектирования;
2. Критериев и правил, используемых для оценки результатов выполнения технологических операций;
3. Графических и текстовых средств (нотаций), используемых для описания проектируемой системы.
Причем каждая технологическая операция должна обеспечиваться соответствующими материальными, информационными и людскими ресурсами. (Данными, полученными на предыдущей операции (или исходными данными), представленными в стандартном виде, методическими материалами, инструкциями, нормативами и стандартами, программными и техническими средствами и исполнителями).
Результаты выполнения операции должны представляться в некотором стандартном виде, обеспечивающем их адекватное восприятие при выполнении следующей технологической операции (на которой они будут использоваться в качестве исходных данных). Технология проектирования, разработки и сопровождения информационных систем, должна отвечать ряду общих правил [17, С. 156]:
- Поддерживать полный жизненный цикл информационной системы;
- Предусмотреть возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
- Обеспечивать гарантированное достижение целей разработки системы с заданным качеством в установленное время и возможность разделения (декомпозиции) крупных проектов на ряд подсистем, как составных частей, разрабатываемых группами исполнителей ограниченной численности, с последующей интеграцией этих частей;
- Обеспечить возможность ведения работ по проектированию отдельных подсистем небольшими группами, что обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей.
- Обеспечить минимальное время получения работоспособной системы. (реализация информационной системы не в целом, а разработка и реализация ее отдельных подсистем);
- Обеспечить независимость выполняемых проектных решений от средств реализации системы — системы управления базами данных, операционной системы, языка и системы программирования.
На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования. Однако по мере возрастания сложности разрабатываемых систем и запросов пользователей, благодаря технологическому прогрессу и появлению удобного графического интерфейса пользователя в системном программном обеспечении. Появилась методология создания информационных систем, основанная на использовании средств быстрой разработки приложений, которая в последнее время получила широкое распространение и приобрела название Методологии быстрой разработки приложений (Rapid Application Development, RAD). Данная методология охватывает все этапы жизненного цикла современных информационных систем и представляет собой комплекс специальных инструментальных средств, позволяющих оперировать с определенным набором графических объектов, функционально отображающих отдельные информационные компоненты приложений.
Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах:
- На небольшой команде программистов (обычно от 2 до 10 человек);
- На тщательно проработанном производственном графике работ, рассчитанном на сравнительно короткий срок разработки;
- На итерационной модели разработки, основанной на тесном взаимодействии с заказчиком, когда по мере выполнения проекта разработчики уточняют и реализуют в продукте требования, выдвигаемые заказчиком.
Основные принципы методологии RAD заключаются в том, что используется итерационная (спиральная) модель разработки. Полное завершение работ на каждом из этапов жизненного цикла не обязательно. В процессе разработки информационной системы, осуществляемой немногочисленной и хорошо управляемой командой профессионалов, обеспечивается тесное взаимодействие с заказчиком и будущими пользователями. Применяются CASE-средства и средства быстрой разработки приложений, а так же средства управления конфигурацией, облегчающие внесение изменений в проект и сопровождение готовой системы. Используются прототипы, позволяющие полнее выяснить и реализовать потребности конечного пользователя. Тестирование и развитие проекта осуществляются одновременно с разработкой. Обеспечиваются грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
CASE-средства (от Computer Aided Software/System Engineering) - позволяют проектировать любые системы на компьютере. Необходимый элемент системного и структурно-функционального анализа, CASE средства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций [24, С. 55]
Применимы практически во всех сферах деятельности. Результат использования CASE-средств - оптимизация систем, снижение расходов, повышение эффективности, снижение вероятности ошибок.