Методология RAD 1 страница

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

• фаза анализа и планирования требований;
• фаза проектирования;
• фаза построения;
• фаза внедрения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

< 1000 функциональных элементов	один человек
1000-4000 функциональных элементов	одна команда разработчиков
> 4000 функциональных элементов	4000 функциональных элементов на одну команду разработчиков

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

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

12. Профили открытых информационных систем.

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

Цели и принципы формирования профилей информационных систем

Основные цели применения профилей:

- снижение трудоемкости, временных затрат, стоимости и улучшение других технико-экономических показателей проектов ИС;

- повышение качества разрабатываемых или применяемых покупных компонентов и ИС в целом;

- обеспечение расширяемости и масштабируемости ИС в зависимости от размера решаемых задач;

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

- обеспечение переносимости прикладных программных средств (ПС) между разными аппаратно-программными платформами.

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

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

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

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

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

В качестве методологической базы для создания профилей сложных распределенных ИС целесообразно использовать технический отчет ИСО/МЭК ТО 10000. Первая и вторая части этого документа применяются в России в качестве ГОСТ Р. Третью часть, определяющую основы и таксономию профилей среды открытых систем, следует использовать при создании профилей ИС как базовый документ. Эталонная модель открытых систем (OSE/RM) разделяет любую информационную систему на приложения (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют [2]. Между приложениями и средой определяются стандартизированные интерфейсы (Application Program Interface, API). Эти интерфейсы являются необходимой частью профиля любой открытой системы. Кроме того, в профилях ИС могут быть определены унифицированные интерфейсы взаимодействия прикладных программ между собой и интерфейсы взаимодействия между компонентами среды ИС. В соответствии с определениями профиля и базовых стандартов, входящих в профиль, по ИСО/МЭК ТО 10000, спецификации выполняемых функций и интерфейсов взаимодействия могут быть оформлены как профиль каждого компонента системы. Таким образом, профили ИС как сложной системы с иерархической структурой могут включать в себя: стандартизированные описания функций, выполняемых данной системой, интерфейсы взаимодействия с внешней для ИС средой и протоколы телекоммуникационной среды, стандартизированные интерфейсы между приложениями и средой ИС, профили отдельных функциональных компонентов, входящих в систему.

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

Структура и содержание профилей информационных систем

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

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

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

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

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

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

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

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

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

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

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

- планируется создание новой ИС при отсутствии задела по системе и компонентам данного проекта;

- имеется типовой проект ИС, и предстоит его адаптация и реализация;

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

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

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

- проектирование ИС. В этот период определяется архитектура и структура ИС уточняются положения, параметры и адаптируются стандарты комплекта профилей; они дополняются ведомственными или корпоративными нормативными документами; оформляются проекты документов и методических руководств по применению рабочей версии каждого профиля;

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

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

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

Следует выделить две крупные группы профилей ИС:

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

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

На стадиях проектирования и разработки ИС выбираются и затем применяются основные функциональные профили:

- профиль прикладного программного обеспечения;

- профиль среды ИС;

- профиль защиты информации в ИС;

- профиль инструментальных средств, встроенных в ИС.

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

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

- выбор готовых программных и аппаратных средств, соответствующих профилям;

- проектирование и разработка прикладного программного обеспечения ИС в соответствии с выбранными профилями, в частности со стандартизированными интерфейсами;

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

- тестирование компонентов ИС на соответствие профилям или проверка сертификатов соответствия для применяемых готовых программных и аппаратных средств;

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

Функциональные профили поддерживаются вспомогательными технологическими профилями. Среди них:

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

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

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

Методические рекомендации по разработке и применению профиля жизненного цикла в проектах конкретных ИС могут быть основанны на стандарте ИСО/МЭК 12207:1995 “Информационные технологии. Процессы жизненного цикла программного обеспечения” [3]. Такой подход правомерен постольку, поскольку программное обеспечение составляет большую часть стоимости современных ИС, а продолжительность жизненного цикла программного обеспечения фактически определяет продолжительность жизненного цикла ИС. Кроме того, современные методы создания программного обеспечения, переносимого между разными аппаратно-программными платформами, позволяют уменьшить зависимость жизненного цикла ИС от жизненного цикла технических средств.

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

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

Описание профилей должно содержать:

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

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

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

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

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

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

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

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

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

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

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

• всякому столбцу таблицы присвоено имя, которое должно быть уникальным для этой таблицы;
• столбцы таблицы упорядочиваются слева направо, т.е. столбец 1, столбец 2,..., столбец n. С математической точки зрения это утверждение некорректно, потому что в реляционной системе столбцы не упорядочены. Однако с точки зрения пользователя, порядок, в котором определены имена столбцов, становится порядком, в котором должны вводиться в них данные, если не предварять при вводе каждое значение именем соответствующего столбца;
• строки таблицы не упорядочены (их последовательность определяется лишь последовательностью ввода в таблицу);
• в поле на пересечении строки и столбца любой таблицы всегда имеется только одно значение данных и никогда не должно быть множества значений (правда, это "атомарное" значение может быть достаточно объемным, например, таким, как рецепт блюда);
• всем строкам таблицы соответствует одно и то же множество столбцов, хотя в определенных столбцах любая строка может содержать пустые значения (NULL-значения), т.е. может не иметь значений для этих столбцов;
• все строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку такой таблицы;
• при выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию.

Почему же база данных, составленная из таких таблиц, называется реляционной? А потому, что отношение - relation - просто математический термин для обозначения неупорядоченной совокупности однотипных записей или таблиц определенного специфического вида.

Дата добавления: 2015-04-23