Ответы к экзамену по дисциплине Базы данных

1. Основные понятия теории баз данных. Файловые системы и системы с базами данных.

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

Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД. 

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

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

• создать файл (требуемого типа и размера);

• открыть ранее созданный файл;

• прочитать из файла некоторую запись (текущую, следующую, предыдущую, первую, последнюю);

• записать в файл на место текущей записи новую, добавить новую запись в конец файла.

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

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

2. Характеристика и основные события этапов развития БД.

История развития баз данных

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

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

1. надежное хранение информации в памяти компьютера;

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

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

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

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

• Все СУБД базируются на мощных мультипрограммных операционных системах (MVS, SVM, RTE, OSRV, RSX, UNIX), поэтому в основном поддерживается работа с централизованной базой данных в режиме распределенного доступа.

• Функции управления распределением ресурсов в основном осуществляются операционной системой (ОС).

• Поддерживаются языки низкого уровня манипулирования данными, ориентированные на навигационные методы доступа к данным.

• Значительная роль отводится администрированию данных.

• Проводятся серьезные работы по обоснованию и формализации реляционной модели данных, и была создана первая система (System R), реализующая идеологию реляционной модели данных.

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

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

3. Банки данных: определение, предпосылки создания, требования, преимущества, недостатки.

Банк данных (БнД) – это система специально организованных данных, программных, языковых, организационных и технических средств, предназначенных для централизованного накопления и коллективного многоцелевого использования данных.

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

Требования БнД :

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

• Обеспечивать заданный уровень достоверности хранимой информации.

• Обеспечивать доступ к данным только пользователям с соответствующими полномочиями.

• Обеспечивать возможность поиска информации по произвольной группе признаков.

• Удовлетворять заданным требованиям по производительности при обработке запросов.

• Иметь возможность реорганизации и расширения при изменении границ ПО.

• Обеспечивать выдачу информации пользователю в различной форме.

• Обеспечивать простоту и удобство обращения внешних пользователей за информацией.

• Обеспечивать возможность одновременного обслуживания большого числа внешних пользователей.

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

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

4. Пользователи банков данных.

В процессе эксплуатации БнД с ним взаимодействуют пользователи разных категорий.

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

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

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

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

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

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

5. Компоненты банка данных. Взаимодействие компонентов БнД.

Компоненты БнД(рис.1)

Рис.1

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

СУБД предназначена для централизованного управления БД в интересах всех работающих в этой системе.

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

• СУБД общего назначения

• специализированные СУБД.

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

Взаимодействие компонентов БнД(рис.2)

Рис.2

6. Информационный компонент, технические и организационно-методические средства БнД.

Информационная компонента

Ядро банка данных — база данных. База данных – поименная совокупность взаимосвязанных данных, находящихся под управлением СУБД. В настоящее время действует закон РФ “О правовой охране программ для электронных вычислительных систем и баз данных”, по нему: База данных – это объективная форма представления и организации совокупности данных, систематизированных таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ.

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

Технические средства банков данных

Состав технических средств стандартный: ЭВМ, периферийные средства для ввода информации в базу данных, средства отображения вводимой информации. Если банк реализуется в сети, то необходимы коммуникационные средства.

Организационно-методические средства

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

7. Программные и языковые средства БнД.

Программные средства банка данных

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

Языковые средства банков данных

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

8. Администратор банка данных(АБНД): определение, функции, взаимодействие с другими категориями пользователей.

АБНД

Функции АБНД:

Анализ предметной области: описание предметной области, выявление ограничений целостности, определение статуса информации, определение потребностей пользователей, определение статуса пользователей, определение соответствия «данные-пользователь», объемно-временных характеристик обработки данных.

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

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

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

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

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

Защита данных от разрушений (резервирование).

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

Анализ обращений пользователей к БД: сбор статистики обращений пользователей к БД, ее хранение и анализ обращений к БД.

Анализ эффективности функционирования БнД и развитие системы: анализ показателей функционирования системы, реорганизация и реконструкция БД, изменение состава БД, развитие программных и технических средств.

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

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

Организационно-методическая работа: выбор или создание методики проектирования БД; определение целей и направлений развития системы; планирование этапов развития БнД; разработка и выпуск организационно-методических материалов.

Взаимодействие АБнД с другими категориями пользователей:

9. Жизненный цикл ИС: этапы, основные и вспомогательные процессы.

ЖЦ – это период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из эксплуатации.

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

Этапы ЖЦ ИС основанной на БД: планирование, сбор и анализ требований к системе, проектирование системы(в том числе проектирование БД), создание прототипа, реализация, тестирование, преобразование, сопровождение.

Структура ЖЦ:

- основные процессы – приобретение, поставка, разработка, эксплуатация, сопровождение.

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

- организационные процессы – управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение.

10. Модели жизненного цикла.

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

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

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

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

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

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

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

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

11. Модели данных: определение, классификация.

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

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

12. Иерархическая модель данных: схема, структура данных, операции над данными, ограничения целостности, недостатки.

Схема иерархической модели данных.

Структура данных: Элемент(атрибут)=>запись(сегмент, группа)=>групповое отношение=>база данных.

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

Запись – именованная совокупность атрибутов. Записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи – конкретная запись с конкретным значением элементов.

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

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

Недостатки иерархических БД:

• Частично дублируется информация между записями СОТРУДНИК и ИСПОЛНИТЕЛЬ (парные записи), причем не предусмотрена поддержка соответствия между парными записями.

• Иерархическая модель реализует отношение между исходной и дочерней записью по схеме 1:N. Допустим теперь, что исполнитель может принимать участие более чем в одном контракте (M:N). В этом случае в БД необходимо ввести еще одно групповое отношение, в котором ИСПОЛНИТЕЛЬ будет являться исходной записью, а КОНТРАКТ – дочерней. Таким образом, мы вынуждены дублировать информацию.

Операции над данными в иерархической модели:

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

Изменить значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.

Удалить некоторую запись и все подчиненные ей записи.

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

Ограничения целостности:

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

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

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

Схема сетевой модели данных:

Структура данных: элемент данных =>агрегат данных => запись => набор данных =>БД.

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

Структуризация данных базируется на концепциях агрегации и обобщения. Агрегация используется для композиции элементов в запись. Обобщение используется для объединения однотипных записей файлов.

Агрегат данных – поименованная совокупность элементов данных внутри записи или другого агрегата. Типы агрегатов вектор и повторяющаяся группа.

Запись – именованная структура, содержащая один и более именованных элементов данных, обладающих своим особым форматом.

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

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

Операции над данными:

Добавить – внести запись в БД и, в зависимости от режима включения, либо включить ее в групповое отношение, где она объявлена подчиненной, либо не включать ни в какое групповое отношение.

Включить в групповое отношение – связать существующую подчиненную запись с записью-владельцем.

Переключить – связать существующую подчиненную запись с другой записью – владельцем в том же групповом отношении.

Обновить – изменить значение элементов предварительно извлеченной записи.

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

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

Исключить из группового отношения – разорвать связь между записью-владельцем и записью-членом.

Ограничения целостности: как и в иерархической модели обеспечивается только поддержание целостности по ссылкам (владелец отношения – член отношения).

14. Пример преобразования иерархической структуры в сетевую.

• Деревья заменяются одной сетевой структурой, в которой запись СОТРУДНИК входит в два групповых отношения;

• Для отображения типа M:N вводиться запись СОТРУДНИК_КОНТАКТ, которая не имеет полей и служит только для связи записей КОНТАКТ и СОТРУДНИК

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

15. Реляционная модель данных. Основные компоненты реляционного отношения.

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

• Представляет данные в виде двухмерной таблицы

• Табличная структура данных отражает отношения между реальными объектами и их характеристиками

• Поиск и обработка записей не зависит от организации и хранения данных в памяти компьютера

• При этом эффективно используются математическая логика и алгебра.

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

Домены

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

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

ДОМЕН - допустимое множество атомарных значений одного т того же типа.

16. Реляционные ключи. Реляционная целостность.

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

Ключ (key)- это группа из одного или более атрибутов, которая уникальным образом идентифицирует строку. (Первичные, внешние, физические, логические, суррогатные, ключь-кандидат)

Также перечисленные ключи могут быть:

• простыми;

• составными -композитными (полностью составными и полусоставными) ключами.

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

• Составной ключ (композитный)- ключ, который содержит два или более элемента данных, каждый из которых необходим для однозначной идентификации объекта.

• Полностью составной ключ - ключ, содержащий несколько атрибутов, между которыми существует отображение М:М.

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

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

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

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

17. Операции с данными в реляционной модели.

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

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

Операции над таблицами (отношениями) – это объединение, пересечение, разность, декартово произведение, проекции, соединения.

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

1. Операция объединения.

Выполняется над двумя совместимыми таблицами (отношениями) R1 и R2 результатом выполнения это операции является новая таблица (отношения) R. В общем виде операция объединения выглядит так : R=R1 U R2

По теории это объединения множества – объединение из двух данных некоторого множества, каждый элемент которого принадлежит либо первому, либо второму множеству

2. Операция пересечения (произведения множества)

Это образование из двух данных множеств R 1 и R2 некоторого нового множества RР, каждый элемент которого принадлежит одновременно множествам R 1 и R2 совместными отношениями. Результативные отношения RР содержат одинаковые кортежи, которые принадлежат как R 1, так и R2. Состав атрибутов в RР такой же, как и в R 1 и R2.

RР=R1 U R2

3. Операция разности (вычитания)

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

RV=R1 - R2

4. Операция декартова произведения

построить декартово произведение двух отношений. Пусть R - таблица, со степенью k1 и пусть S таблица со степенью k2. R × S - это множество всех k1 + k2 - кортежей, где первыми являются k1 элементы кортежа R и где последними являются k2 элементы кортежа S.

5. Операция проекции.

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

6. Операция соединения

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

7. операция выборка

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

18. Двенадцать правил Кодда для РМД.

Этим правилам, сформулированным Коддом, должна соответствовать реляционная СУБД:

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

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

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

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

6.Правило обновления представлений. (все представления, которые теоретически можно обновить, должны быть доступным для обновления)

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

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

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

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

11.Правило независимости распространения. Реляционная база СУБД не должна зависеть от потребностей конкретного клиента

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

19. Трехуровневая архитектура ANSI-SPARC.

ANSI-SPARC - Комитет планирования стандартов и норм SPARC (Standards Planning and Requirements Committee)

Комитете ANSI/SPARC признал необходимость использования трехуровневого подхода общей архитектуры СУБД. Выделены 3 уровня абстракции, т.е. трех различных уровней описания элементов данных. Эти уровни формируют трехуровневую архитектуру, которая охватывает внешний, концептуальный и внутренний уровни.

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

Причины, по которым желательно выполнять такое разделение:

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

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

3. Администратор базы данных (АБД) должен иметь возможность изменять структуру хранения данных в базе, не оказывая влияния на пользовательские представления.

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

5. АБД должен иметь возможность изменять концептуальную или глобальну. Структуру базы данных без какого-либо влияния на всех пользователей.

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

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

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

На внутреннем уровне хранится следующая информация:

· Распределение дискового пространства для хранения данных и индексов;

· Описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных);

· Сведения о размещении записей;

· Сведения о сжатии данных и выбранных методах шифрования.

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

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

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

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

20. Общий обзор процедуры проектирования БД.

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

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

Модели данных

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

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

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

21. Задачи и этапы проектирования баз данных.

Проектирование БД – это взаимосвязанный комплекс работ – от определения общих параметров создаваемой БД, анализа объекта управления и существующей системы управления на объекте, построения информационной модели до создания реальной БД. Основные цели проектирования: Представление данных и связей между ними, необходимых для всех основных областей применения данного приложения и любых существующих групп его пользователей; создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных; разработка дополнительного варианта проекта, структура которого позволяет удовлетворять все основные требования, предъявляемые к производительности системы. Задачи проектирования баз данных: Обеспечение хранения в БД всей необходимой информации; Обеспечение получения всей необходимой информации по всем необходимым запросам; Сокращения избыточности и повтора данных; Обеспечения целостности данных, правильности их содержания; Недопустимость содержания в данных противоречий; Исключение потери данных. Общепринятая методология проектирования БД разделяется на 3 основные фазы: 1.концептуальное проектирование - это процедура конструирования информационной модели, не зависящей от каких-либо физических условий реализации; 2. логическое проектирование - это процесс конструирования информационной модели на основе существующих моделей данных, не зависимо от используемой СУБД и других условий физической реализации;3. физическое проектирование - это процедура создания описания конкретной реализации БД с описанием структуры хранения данных, методов доступа к данным. Процедура проектирования БД будет включать следующие этапы:

1. Создание концептуальной модели данных, исходя из представлений о предметной области, каждого из пользователей. Шаги: определение типов сущности; определение типов связей; определение атрибутов и связывание их с типами сущностей и связей; определение доменов атрибутов; определение атрибутов, являющихся потенциальными и первичными ключами; создание диаграмм "сущность ­– связь”; обсуждение локальной концептуальной модели с конечным пользователем.

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

3. Создание и проверка глобальной логической модели данных. Слияние локальных и логических моделей в единую модель; проверка глобальной логической модели; проверка возможности расширения проблемы в будущем; создание окончательного варианта диаграммы "сущность – связь”; обсуждение глобальной логической модели с конечным пользователем;

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

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

6. Разработка механизмов защиты: разработка пользовательских представлений; определение прав доступа к данным.

22. Методология концептуального проектирования БД.

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

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

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

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

После установления связей следует установить кардинальность каждой из них. Каждая связь имеет кардинальность 1:1, либо 1:N, либо M:N. Кроме того следует проанализировать степень участия каждой из сущностей в конкретном типе связей.  Степень участия может быть полной либо частной. В словарь данных помещаем описание каждой связи. Для представления сущностей и связей используется диаграмма «сущность-связь».

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

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

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

23. Методология логического проектирования БД.

Подразделяется на следующие этапы:

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

2. Создание и проверка глобальной логической модели данных.

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

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

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

3. Проверка модели с помощью правил нормализации.

4. Проверка модели в отношении транзакции пользователя.

5. Создание уточненной диаграммы “сущность – связь”.

6. Определение требований поддержки целостности данных.

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

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

1. Удалить связи M:N (многие ко многим).

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

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

4. Удаление связей с атрибутами.

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

6. Перепроверка связей 1:1. В процессе определения сущностей могут быть созданы две сущности, которые представляют один и тот же объект. Если эти сущности имеют разные первичные ключи, то первый указывается как первичный, а второй ключ – как альтернативный, и эти сущности объединяются в одну сущность.

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

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

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

Проверка модели с помощью правил нормализации

Обязательным является выполнение требований до 3-ей НФ. В отдельных случаях необходимо приводить к НФ, поэтому следующий этап состоит из действий:

- из отношений удаляются повторяющиеся группы атрибутов;

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

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

- все детерминальные отношения были потенциальными ключами.

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

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

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

Различают 5 типов целостности данных:

1.      Обязательные данные;

2.      Ограничение для доменов атрибутов;

3.      Целостность сущностей;

4.      Ссылочная целостность;

5.      Требования данного пользователя.

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

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

Целостность сущностей. Значение первичного ключа не должно иметь NULL-значения.

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

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

24. Методология физического проектирования БД.

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

1.      Перенос глобальной логической модели в среду СУБД

1.1    проектирование таблиц БД в среде СУБД;

1.2    реализация бизнес правил предприятия в среде СУБД;

2.      Проектирование физического представления БД в среде СУБД

2.1    анализ транзакций;

2.2    выбор файловой структуры;

2.3    определение вторичных индексов;

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

3.      Определения требований к дисковой памяти защиты БД

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

3.2    определение прав доступа к функциям;

4.      Организация мониторинга и настройка функционирования системы.

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

Эффективное хранение данных.

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

1.      Пропускная способность транзакции. Этот показатель позволяет определить какое количество транзакций может быть отработано за данный промежуток времени.

2.      Время ответа. Характеризует временной промежуток, необходимый для выполнения одной транзакции.

3.      Дисковая память. Характеризует объем дискового пространства для размещения БД.

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

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

Рекомендуется выбирать основные группы.

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

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

1.      Денормализация усложняет реализацию БД.

2.      Денормализация снижает гибкость системы.

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

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

Иногда денормализация называется оптимизация исполнения.

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

1. Разработка пользовательских представлений;

2. Определение прав доступа к данным.

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

В многопользовательской среде представления используются как средство определения структуры БД и организации защиты информации.

Представления создаются с помощью языка SQL.

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

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

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

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

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

1.      устранить необходимость приобретение дополнительного оборудования;

2.      снизить требование оборудования;

3.      обеспечить лучшее время ответа системы;

4.        повысить уровень производительности системы;

5.      повышение психологического комфорта пользователей.

25. Модель «Сущность-связь».

Элементы модели:

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

Набор сущностей – множество сущностей одного типа (обладающих одинаковыми свойствами).

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

Обозначение сущности и ее атрибутов: СОТРУДНИК(ТАБЕЛЬНЫЙ_НОМЕР, ИМЯ, ВОЗРАСТ).

Ключ сущности – это один или более атрибутов уникально определяющих данную сущность.

Связь – это ассоциация, установленная между несколькими сущностями.

Набор связей – это отношение между n (n>2) сущностями, каждая из которых относится к некоторому набору сущностей.

В случае n=2, т.е. когда связь объединяет две сущности, она называется бинарной.

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

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

Один к одному (1:1). Один ко многим (1:n). Много к одному (n:1).

Если существование сущности x зависит от существования сущности y, то x называется зависимой сущностью( иногда сущность x называют «слабой», а сущность y – «сильной»).

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

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

Этапы построения диаграммы:

1. Идентификация представляющих интерес сущностей и связей.

2. Идентификация семантической информации и набора связей.

3. Определение кардинальностей связей.

4. Определение атрибутов и наборов их значений(доменов).

5. Организация данных в виде отношений «сущность-связь».

26. Нормализация. Избыточность и аномалии. Функциональные зависимости.

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

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

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

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

Аномалии в ненормализованной схеме отношения:

а) обновления – противоречивость данных, вызванная их избыточностью и частичным обновлением.

б) аномалия удаления – непреднамеренная потеря данных, вызванная удалением других данных

в) аномалия ввода – невозможность ввести данные в таблицу, вызванная отсутствием других данных.

Понятие функциональной зависимости.

A,B – атрибут или совокупность атрибутов.

Функциональная зависимость B является функционально зависимым от A, тогда и только тогда, когда каждому значению A соответствует одно и только одно значение B. A->B. F(A)=B. Детерминант – атрибут, который определяет значения других атрибутов. Синоним – определитель.

Транзитивная зависимость существует тогда, когда функциональные зависимости носят следующий характер: A->B b B->C, поэтому A->C.

Многозначная зависимость существует, если каждому значению атрибута A соответствует конечное множество значений атрибута B, связанных с A, и конечное множество значений атрибута C, также связанных с A. Атрибуты B и C друг от друга не зависят. A->B, A->C.

Правила вывода. Аксиомы (правила, теоремы) вывода – правило, устанавливающее, что если некоторое отношение удовлетворяет некоторым F-зависимостям, то оно должно удовлетворять и некоторым другим F-зависимостям.

A,B->A и A,B->B

Если A->B и A->C, то A->BC.

Если A->B и B->C, то A->C.

Если A->B, то AC->B.

Если A->B и BC->D, то AC->D.

27. Нормальные формы 1НФ, 2НФ, 3НФ, НФБК, нормальные формы более высокого порядка.

Последовательность нормальных форм: 1нф, 2нф, 3нф, нфбк, 4нф, 5нф.

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

1нф. Данные хранятся в плоской двухмерной таблице без: неповторяющихся СЕИ; векторов; повторяющихся групп. Приведение к 1нф. Понятие «универсальное отношение» - все атрибуты записываются в одной таблице.

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

3нф. Отношение находится в 3нф, если оно соответствует 2нф, и в нем не существует транзитивных зависимостей.

Нфбк. Отношение соответствует нфбк, если оно соответствует 3нф, и все определители являются кандидатами на использование в качестве ключа.

4нф. Отношение находится в 4нф, если оно соответствует нфбк, и в ней нет многозначных зависимостей.

28. Алгоритм нормализации.

Шаг 1. Получение исходного множества функциональных зависимостей. Рассматриваются все сочетания атрибутов (1, 2, 3, …, n). Не рассматриваются варианты, которые являются следствием теорем о функциональных зависимостях.

Шаг 3. Для каждого fi создать отношение.

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

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

ИЛИ

Шаг 1: приведение к 1НФ

На первом шаге задается одно или несколько отношений, отображающих понятия ПО. По модели ПО (а не по внешнему виду полученных отношений!) выписываются обнаруженные ФЗ. Все отношения автоматически находятся в 1НФ.

Шаг 2: приведение к 2НФ

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

Исходное отношение R (K1, K2, A1, An, B1, Bm)

ФЗ: {К1, К2} — { A1, An, B1, Bm} — зависимость всех атрибутов от ключа отношения.

{К1}-{ A1, An} — зависимость некоторых атрибутов от части составного ключа.

Декомпозированные отношения:

R1 (K1, K2, B1, Bm) — остаток от исходного отношения.

R2 (K1, A1, An) — атрибуты, вынесенные из исходного отношения вместе с часть составного ключа.

Шаг 3: приведение к 3НФ

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

Исходное отношение R (K, A1,... An, B1, Bm)

ФЗ: {К} — { A1, An, B1, Bm}- зависимость всех атрибутов от ключа отношения.

{ A1, An} — {B1, Bm} — зависимость некоторых атрибутов от других неключевых атрибутов.

Декомпозированные отношения:

R1 (K, А1, Аm) — остаток от исходного отношения

R2 (A1, An, B1, Bm) — атрибуты, вынесенные из исходного отношения вместе с детерминантом ФЗ.

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

29. Получение реляционной схемы из ER-диаграммы.

Шаг 1. Каждая сущность превращается в таблицу. Имя сущности становится именем таблицы.

Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.

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

Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Делается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ.

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

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

30. Применение теории нормализации к ER-модели.

31. Средства автоматизации проектирования.

Под всеобъемлющим термином "САПР" (система автоматизированного проектирования) в России понимают ряд англоязычных терминов (CAD/CAM/CAE/PDM/TDM/AEC/GIS и т.д.). В процессе автоматизированного проектирования в качестве входной информации используются технические знания специалистов, которые вводят проектные требования, выполняют различные проверочные расчеты, анализируют и уточняют полученные результаты, выполняют модификацию конструкции.

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

В современных условиях почти на всех перечисленных этапах должны использоваться специализированные системы автоматизированного проектирования электронных устройств (Electronic Design Application - EDA). Поэтому основные направления проектирования, можно разделить на следующие задачи: моделирование смешанных аналого-цифровых устройств; моделирование и синтез логики для ПЛИС; схемотехническое и электромагнитное моделирование СВЧ-устройств; поведенческое моделирование на уровне структурных схем; проектирование печатных плат; анализ электромагнитной совместимости; тепловое моделирование; средства подготовки печатных плат к производству; проектирование топологий БИС; проектирование электротехнических схем и чертежей.

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

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

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

32. Классификация CASE-средств.

CASE-средства классифицируются по различным признакам: по типам, категориям и уровням. Классификация по типам распределяет CASE-средства по их функциональному назначению на следующие группы. Средства анализа и проектирования - предназначены для поддержки определения системных требований, создания спецификаций компонентов системы, проектирование системы. В результате формируются архитектура системы и детальный проект, разработанный до уровня алгоритмов и структур данных. К этой группе принадлежат пакеты CASE. Аналитик (Ейтекс), The Developer (ASYST Technologies), POSE (Computer Systems Advisers), ProKit * Workbench (McDonnell Douglas), Excelerator (Index Technology), Design-Aid (Nastec), Design Machine (Optima), Mic-roStep ( Meta Systems), vsDesigner (Visual Software), Analist / Designer (Yourdon), Design / IDEF (Meta Software), BPWin (Logic Works), SELECT (Select Software Tools), System Architect (Popkin Software & Systems), Westmount I- CASE Yourdon (Westmount Technology BV & CADRE Technologies), CASE/4/0 (micro TOOL GmbH). Средства проектирования баз данных - обеспечивают создание инфологической и даталогичнои моделей БД, нормализацию отношений и автоматическую генерацию схем БД и описаний файлов на уровне программного кода. К этой группе относятся ERWin (Logic Works), Chen Toоlkit (Chen & Associates), S-Designor (SDP), Designer/2000 (Oracle), Silverrun (Computer Systems Advisers). Средства программирования - осуществляют поддержку программирования и тестирования, а также автоматическую кодогенерации из спецификаций с получением полностью документированной выполняемой программы. К этой группе относятся диаграмеры и средства работы с репозиторием, генераторы и анализаторы кодов, генераторы тестов, анализаторы покрытия тестами, отладчик. Основные пакеты: COBOL 2/Workbench (Mikro Focus), DECASE (DEC), NETRON / CAP (Netron), APS (Sage Software).

33. Перспективная CASE-система.

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

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

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

 1.динамического моделирования событий в системе;                       

* динамической и согласованной коррекции всей совокупности диаграмм;

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

* автоматической генерации документации;                               

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

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

Осуществление процесса проектирования предполагает наличие возможностей: 

-определение основной модели прикладной задачи (бизнес-модели) и правил её поведения;

-поддержки процесса проектирование с помощью библиотек, оснащённых средствами хранения, поиска и выбора элементов проектирования (объектов и правил);

-создания пользовательского интерфейса и поддержания распространенных программных интерфейсов (поддержка стандартов OLE, OpenDoc, доступ к библиотекам HTML/Java и т. п.);

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

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

 CASE-системы ближайшего будущего должны позволять создавать скелетные заготовки под классы, атрибуты и методы, готовые приложения на объектно-ориентированных языках программирования типа C++ или Smalltalk, либо программы на языках клиент-серверных продуктов (PowerBuilder, Forte, VisualAge, VisualWorks и т. д.).  К поддерживаемым языкам, по-видимому, скоро добавится язык Java.   Для обеспечения связи с другими этапами жизненного цикла приложения сред­ства CASE-системы должны включать и функции контроля программного кода на синтаксическую корректность и соответствие моделям.  Ядром инфраструктуры будущих CASE-систем должен бытьрепозитарий, отвечающий за генерацию кода, реинжиниринг и обеспечивающий соответствие между моделями и программными кодами. Основу репозитория составят объектно-ориентированные БД, хотя ранее для этого использовались реляционные БД. Другими важнейшими функциями инфраструктуры являются функции контроля версий и управ­ления частями системы при коллективной разработке.

34. Оценка и выбор CASE-средств.

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

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

определение критериев оценки, вытекающее из определения задачи; 

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

подготовка отчета по результатам оценки.

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

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

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

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

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

рекомендаций по выбору конкретного CASE-средства; 

запроса на получение дополнительной информации к процессу оценки.

35. Модели структурного проектирования.

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

1. Функциональную структуру системы;

1. Последовательность выполняемых действий;

2. Передачу информации между функциональными процессами;

3. Отношения между данными.

Наиболее распространенными моделями первых трех групп являются:

• функциональная модель SADT (Structured Analysis and Design Technique);

• модель IDEF3;

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

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

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

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

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

• соответствие подхода к описанию процессов стандартам ISO 9000.

SADT (акроним от англ. Structured Analysis and Design Technique) — методология структурного анализа и проектирования, интегрирующая процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых средств и руководство проектом со своим графическим языком. Процесс моделирования может быть разделен на несколько этапов: опрос экспертов, создание диаграмм и моделей, распространение документации, оценка адекватности моделей и принятие их для дальнейшего использования. Этот процесс хорошо отлажен, потому что при разработке проекта специалисты выполняют конкретные обязанности, а библиотекарь обеспечивает своевременный обмен информацией.

Метод моделирования IDEF3, являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов для закрытого проекта ВВС США. Этот метод предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приобрел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 (модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции). Основой модели IDEF3 служит так называемый сценарий процесса, который выделяет последовательность действий и подпроцессов анализируемой системы.

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

Два типа диаграмм в IDEF3

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

IDEF3 состоит из двух методов:

• Process Flow Description (PFD) — Описание технологических процессов, с указанием того, что происходит на каждом этапе технологического процесса.

• Object State Transition Description (OSTD) — Описание переходов состояний объектов, с указанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.

Основу методологии IDEF3 составляет графический язык описания процессов. Модель в нотации IDEF3 может содержать два типа диаграмм:

1. диаграмму Описания Последовательности Этапов Процесса

2. диаграмму Сети Трансформаций Состояния Объекта

36. Универсальный язык моделирования UML: история развития, структура.

Свою историю унифицированный язык объектно-ориентированного моделирования ведет с конца 80х - начала 90х годов. Собственно создание UML началось в 1994 году. В это время Грэйди Буч (Grady Booch) и Джеймс Рэмбо (James Rambaugh) начали объединять несколько методов объектно-ориентированного моделирования в фирме Rational Software. И уже в 1995 году была представлена спецификация метода, названного Unified Method. Первая версия UML была принята консорциумом OMG (Object Management Group) в январе 1997 года. Утвержденная же в сентябре версия UML 1.1 была принята на вооружение основными компаниями - производителями программного обеспечения, такими, как Microsoft, IBM, Hewlett-Packard и производителями CASE-средств, которые реализовали поддержку UML в своих программных продуктах (Paradigm Plus, Microsoft Visual Modeler for Visual Basic, Delphi и др.)

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

Универсальный язык объектного моделирования UML не зависит от языков программирования и, вследствие этого, может поддерживать любой объектно-ориентированный язык программирования. Он является открытым и позволяет расширять ядро.

37. Универсальный язык моделирования UML: диаграммы прецедентов использования, классов.

Диаграммы классов. Классы в UML изображаются на диаграммах классов, которые позволяют описать систему в статическом состоянии — определить типы объектов системы и различного рода статические связи между ними. Классы отображают типы объектов системы. Между классами возможны различные отношения, представленные на рис. 11.2: зависимости, которые описывают существующие между классами отношения использования; обобщения, связывающие обобщенные классы со специализированными; ассоциации, отражающие структурные отношения между объектами классов.

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

Диаграммы использования. Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» (use case) или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой, которое при этом: описывает видимую пользователем функцию, может представлять различные уровни детализации, обеспечивает достижение конкретной цели, важной для пользователя. Прецедент обозначается на диаграмме овалом, связанным с пользователями, которых принято называть действующими лицами (актерами, actors). Действующие лица используют систему (или используются системой) в данном прецеденте. Действующее лицо выполняет некоторую роль в данном прецеденте. На диаграмме изображается только одно действующее лицо, однако реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы. На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, возможно использование еще двух видов связей между прецедентами: «использование» и «расширение» (рис. 11.4). Связь типа «расширение» применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа «использование» позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания. На рис. 11.4 показано, что при исполнении прецедента «формирование заказа» возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов «оценить риск сделки» и «согласовать цену» необходимо выполнить одно и то же действие — рассчитать стоимость заказа.

Рис. 11.4. Связи на диаграммах прецедентов

Динамические аспекты поведения системы отражаются приведенными ниже диаграммами.

38. Универсальный язык моделирования UML: диаграммы состояний, активности, следования.

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

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

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

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

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

Диаграммы компонентов. Диаграммы компонентов позволяют изобразить модель системы на физическом уровне. Элементами диаграммы являются компоненты — физические замещаемые модули системы. Каждый компонент является полностью независимым элементом системы. Разновидностью компонентов являются узлы. Узел — это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и способностью обработки. Узлы делятся на два типа: устройства — узлы системы, в которых данные не обрабатываются. процессоры — узлы системы, осуществляющие обработку данных. Для различных типов компонентов предусмотрены соответствующие стереотипы в языке UML. Компонентом может быть любой достаточно крупный модульный объект, такой как таблица или экстент базы данных, подсистема, бинарный исполняемый файл, готовая к использованию система или приложение. Таким образом, диаграмму компонентов можно рассматривать как диаграмму классов в более крупном (менее детальном) масштабе. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Основное назначение диаграмм компонентов — разделение системы на элементы, которые имеют стабильный интерфейс и образуют единое целое. Это позволяет создать ядро системы, которое не будет меняться в ответ на изменения, происходящие на уровне подсистем.

На рис. 11.9 показана упрощенная схема элементов фрагмента корпоративной системы. «Коробки» представляют собой компоненты — приложения или внутренние подсистемы. Пунктирные линии отражают зависимости между компонентами.

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

Interaction overview diagram - диаграмма, которая предназначена для представления взаимодействия только в контексте потока управления в некоторой агрегированной форме. Диаграммы обзора взаимодействия, вместо узлов действий и объектов диаграмм деятельности, имеют фреймы, каждый из которых может соответствовать взаимодействию или использованию взаимодействия. Альтернативные комбинированные фрагменты представляются узлом решения и соответствующим узлом слияния. Параллельные комбинированные фрагменты представляются узлом разделения и соответствующим узлом соединения. Комбинированные фрагменты типа Цикл представляются простыми циклами. Ветвление и слияния ветвлений на диаграммах обзора взаимодействия должны быть должным образом вложенными. Диаграммы обзора взаимодействия заключаются во фрейм, аналогично другим видам диаграмм взаимодействия с тегом sd и ref.

Для создания диаграммы взаимодействия были использованы теги (ref и sd), созданные в Sequence diagram. Если при проверке наличия деталей выясняется, что у нас есть детали, то переходим к конечному этапу - «произвести ремонт». А если деталей нет, тогда переходим к этапу заказа и получения деталей.

40. SQL. Операторы определения данных.

SQL (ˈɛsˈkjuˈɛl; англ. Structured Query Language — «язык структурированных запросов») — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных. SQL основывается на исчислении кортежей.

SQL был основным способом работы пользователя с базой данных и позволял выполнять следующий набор операций:

• создание в базе данных новой таблицы;

• добавление в таблицу новых записей;

• изменение записей;

• удаление записей;

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

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

В языке SQL имеется шесть скалярных типов данных, определенных стандартом. Их краткое описание представлено в таблице.

Таблица 2.1.
Тип данных	Объявления
Символьный	CHAR | VARCHAR
Битовый	BIT | BIT VARYING
Точные числа	NUMERIC | DECIMAL | INTEGER | SMALLINT
Округленные числа	FLOAT | REAL | DOUBLE PRECISION
Дата/время	DATE | TIME | TIMESTAMP
Интервал	INTERVAL

41. SQL. Операторы манипулирования данными: выборка, сортировка, группирование, обновление данных.

Язык SQL предназначен для манипулирования данными в реляционных базах данных, определения структуры баз данных и для управления правами доступа к данным в многопользовательской среде. По этой причине язык SQL состоит из 3 составных частей:

• Языка манипулирования данными (Data Manipulation Language, DML);

• Языка определения данных (Data Definition Language, DDL);

• Языка управления данными (Data Control Language, DCL).

Все эти языки являются составной частью языка SQL. Фактически, каждый из них содержит набор команд SQL, предназначенных для своей области. В процессе работы с БД, пожалуй, чаще всего используется язык манипулирования данными, состоящий из 4 основных команд - SELECT, INSERT, UPADTE и DELETE, при помощи которых производится, соответственно, выборка, вставка, обновление и удаление данных.

Язык определения данных служит для создания и изменения структуры БД - таблиц, индексов и т.д. Он состоит из 3 групп команд - CREATE, ALTER и DROP (создание, изменение и удаление, соответственно), каждая из которых может манипулировать с одним из 6 объектов - базой данных, таблицей, виртуальной таблицей, индексом, триггером или хранимой процедурой. Таким образом, например, для команды CREATE мы получаем следующие 6 вариантов:

• CREATE DATABASE - создать базу данных;

• CREATE TABLE - создать таблицу;

• CREATE VIEW - создать виртуальную таблицу;

• CREATE INDEX - создать индекс;

• CREATE TRIGGER - создать триггер;

• CREATE PROCEDURE - создать хранимую процедуру.

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

SELECT ("селект") — оператор DML языка SQL, возвращающий набор данных (выборку) из базы данных, удовлетворяющих заданному условию.

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

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

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

Особую роль играет обработка NULL-значений, когда при слиянии, например, двух таблиц — главной (англ. master) и подчинённой (англ. detail) — имеются или отсутствуют соответствия между записями таблиц, участвующих в слиянии. Для решения этой задачи используются механизмы внутреннего (англ. inner) и внешнего (англ. outer) слияния.

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

План в целом разделяется на две стадии:

• Выборка результатов;

• Сортировка и группировка, выполнение агрегаций.

Сортировка и группировка — это опциональная стадия, которая выполняется, если не найдено путей доступа для получения результата в запрошенном порядке

42. SQL. Создание баз данных. Операторы создания и удаления таблиц.

SQL (ˈɛsˈkjuˈɛl; англ. Structured Query Language — «язык структурированных запросов») — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных. SQL основывается на исчислении кортежей. SQL был основным способом работы пользователя с базой данных и позволял выполнять следующий набор операций:

• создание в базе данных новой таблицы;

• добавление в таблицу новых записей;

• изменение записей;

• удаление записей;

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

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

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

<определение_базы_данных> ::=

CREATE DATABASE имя_базы_данных

[ON [PRIMARY]

[ <определение_файла> [,...n] ]

[,<определение_группы> [,...n] ] ]

[ LOG ON {<определение_файла>[,...n] } ]

[ FOR LOAD | FOR ATTACH ]

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

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

Параметр ON определяет список файлов на диске для размещения информации, хранящейся в базе данных.

Параметр PRIMARY определяет первичный файл. Если он опущен, то первичным является первый файл в списке.

Параметр LOG ON определяет список файлов на диске для размещения журнала транзакций. Имя файла для журнала транзакций генерируется на основе имени базы данных, и в конце к нему добавляются символы _log.

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

<определение_файла>::=

([ NAME=логическое_имя_файла,]

FILENAME='физическое_имя_файла'

[,SIZE=размер_файла ]

[,MAXSIZE={max_размер_файла |UNLIMITED } ]

[, FILEGROWTH=величина_прироста ] )[,...n]

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

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

Параметр SIZE определяет первоначальный размер файла; минимальный размер параметра – 512 Кб, если он не указан, по умолчанию принимается 1 Мб.

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

Создание и удаление таблиц.

Создание таблицы: CREATE TABLE <имя_таблицы>

(<имя_столбца> <тип_столбца>

[NOT NULL]

[UNIQUE | PRIMARY KEY]

[REFERENCES <имя_мастер_таблицы> [<имя_столбца>], ...)

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

• NOT NULL - в этом случае элементы столбца всегда должны иметь определенное значение (не NULL)

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

REFERNECES <имя_мастер_таблицы> [<имя_столбца>] - эта конструкция определяет, что данный столбец является внешним ключом и указывает на ключ какой мастер_таблицы он ссылается.

Удаление таблицы: DROP TABLE <имя_таблицы>

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

CREATE DATABASE Archive

ON PRIMARY ( NAME=Arch1,

FILENAME=’c:\user\data\archdat1.mdf’,

SIZE=100MB, MAXSIZE=200, FILEGROWTH=20),

(NAME=Arch2,

FILENAME=’c:\user\data\archdat2.mdf’,

SIZE=100MB, MAXSIZE=200, FILEGROWTH=20),

(NAME=Arch3,

FILENAME=’c:\user\data\archdat3.mdf’,

SIZE=100MB, MAXSIZE=200, FILEGROWTH=20)

LOG ON

(NAME=Archlog1,

FILENAME=’c:\user\data\archlog1.ldf’,

SIZE=100MB, MAXSIZE=200, FILEGROWTH=20),

(NAME=Archlog2,

FILENAME=’c:\user\data\archlog2.ldf’,

SIZE=100MB, MAXSIZE=200, FILEGROWTH=20)

43. Программный (встроенный) SQL.

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

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

- компилятор должен объединять возможности языка программирования высокого уровня (переменные, ветвления, циклы) и возможности SQL (запросы на языке, близком к естественному).

 Программный SQL позволяет:

- использовать операторы интерактивного SQL в тексте программы на языке программирования высокого уровня;

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

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

Особенности встроенного SQL

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

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

• Встроенные операторы SQL могут ссылаться на переменные базового языка программирования.

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

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

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

44. Статический SQL: основные этапы работы, схема компиляции и сборки программы, основные команды, ограничения.

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

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

Рассмотрим два основных этапа, связанных с работой статического SQL, – компиляция программы и работа (выполнение) программы.

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

• Программа, включающая операторы языка программирования высокого уровня (ЯПВУ) вместе с операторами SQL, подается на вход специального препроцессора, который выделяет из нее части, связанные с SQL.

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

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

• Наряду с этими операциями происходит работа с файлом, содержащим SQL-инструкции. В литературе этот модуль часто носит название "модуль запросов к базе данных" (Database Request Module, DBRM) [1]. Обработку этого модуля осуществляет специальная утилита, которая обычно носит название BIND. Для каждой инструкции SQL утилита выполняет следующие действия:

  • осуществляет синтаксический анализ запроса (проверяет, является ли запрос корректным);

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

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

• Все планы выполнения запросов сохраняются в СУБД для последующего использования.

Рис. Схема компиляции программы с встроенными инструкциями статического SQL

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

Рис. Схема выполнения программы с встроенными инструкциями статического SQL

Таблица 13.1. Основные команды статического SQL
EXEC SQL	Спецификатор, указывающий, что следующая за ним инструкция является инструкцией встроенного SQL
;	В языке C – признак окончания инструкции встроенного SQL
DECLARE TABLE	Объявляет таблицу, которая потом будет использоваться в инструкциях встроенного SQL
SQLCODE	Переменная для обработки ошибок
SQLSTATE	Переменная для обработки ошибок
GET DIAGNOSTICS	Инструкция для обработки ошибок
WHENEVER SQLERROR SQLWARNING NOT FOUND GOTO CONTINUE	Набор совместно используемых инструкций для упрощения обработки ошибок
BEGIN DECLARE SECTION END DECLARE SECTION	Инструкции для определения области, в которой будут объявлены переменные, впоследствии используемые в запросах SQL
INTO	Используется в операторе SELECT для указания переменной, в которую необходимо поместить результат выполнения запроса
DECLARE CURSOR	Курсор – специальный инструмент, предназначенный для обработки результатов запроса, содержащих более одной строки. Работа с курсором похожа на работу с файлами. Данная инструкция служит для создания курсора и связывания его с конкретным запросом
OPEN	Команда, открывающая курсор и побуждающая СУБД начать выполнение запроса. Устанавливает курсор перед первой строкой результата запроса
FETCH	Команда, перемещающая указатель текущей строки (курсор) на следующую строку. В некоторых СУБД и стандарте SQL-92 реализованы разные формы команды FETCH, перемещающие курсор на произвольную строку результатов запроса
CLOSE	Закрывает курсор и прекращает доступ к результатам запроса

Использование описанной выше схемы компиляции/сборки/выполнения программы позволяет:

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

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

Однако статическая разновидность программного SQL имеет некоторые существенные ограничения. Так, переменные в запросах могут использоваться только в тех местах, где в запросах обычно стоят константы. Например, нельзя задавать имя таблицы, из которой производится выборка, а также названия столбцов, как параметр. В связи с этим при использовании статического варианта вложенного (программного) SQL необходимо на этапе написания программы точно знать состав запросов, которые необходимо будет выполнять в прикладной программе. Во многих случаях это ограничение является существенным. Для его устранения была введена новая разновидность программного SQL – динамический SQL. Рассмотрим кратко основные идеи динамического SQL.

45. Динамический SQL: основные команды, схемы функционирования, недостатки и достоинства.

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

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

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

Динамический SQL также должен содержать дополнительные операторы (по сравнению с интерактивным SQL).

Таблица 13.2. Основные команды динамического SQL
EXECUTE IMMEDIATE	Немедленное выполнение инструкции
PREPARE	Подготовка инструкции к выполнению
EXECUTE	Выполнение подготовленной ранее инструкции
DESCRIBE	Специальная команда, участвующая при возврате результата выполнения инструкций динамического SQL
DECLARE CURSOR	Разновидность инструкции DECLARE CURSOR, применявшейся ранее в рамках статического SQL, содержащая вместо запроса его имя (связанное с запросом при помощи инструкции PREPARE )
OPEN FETCH CLOSE	Разновидности инструкций для работы с курсором в динамическом SQL

Рассмотрим схему функционирования динамического SQL (рис. 13.3). Схема предусматривает одноэтапное и двухэтапное выполнение инструкций.

Одноэтапное выполнение инструкций осуществляется командой EXECUTE IMMEDIATE.

Рис. 13.3.  Схема выполнения программы со встроенными инструкциями динамического SQL с применением одноэтапной схемы

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

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

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

Рис. 13.4.  Схема выполнения программы со встроенными инструкциями динамического SQL с применением двухэтапной схемы

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

На этапе выполнения СУБД подставляет значения параметров (полученные из программы) и использует сформированный ранее план выполнения для достижения результата.

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

46. Интерфейсы программирования приложений (API).

Интерфейс прикладного программирования (иногда интерфейс программирования приложений) (англ. Application Programming Interface, API [эй-пи-ай]) — набор готовых классов, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для её использования во внешних программных продуктах.

API как средство интеграции приложений API определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована. Если программу (модуль, библиотеку) рассматривать как чёрный ящик, то API — это множество «ручек», которые доступны пользователю данного ящика, которые он может вертеть и дёргать. Программные компоненты взаимодействуют друг с другом посредством API. При этом обычно компоненты образуют иерархию — высокоуровневые компоненты используют API низкоуровневых компонентов, а те, в свою очередь, используют API ещё более низкоуровневых компонентов. По такому принципу построены протоколы передачи данных по Internet. Стандартный протокол Internet (сетевая модель OSI) содержит 7 уровней (от физического уровня передачи пакетов бит до уровня протоколов приложений, подобных протоколам HTTP и IMAP). Каждый уровень пользуется функциональностью предыдущего уровня передачи данных и, в свою очередь, предоставляет нужную функциональность следующему уровню. Важно заметить, что понятие протокола близко по смыслу к понятию API. И то, и другое является абстракцией функциональности, только в первом случае речь идёт о передаче данных, а во втором — о построении компьютерных приложений. API библиотеки функций и классов включает в себя описание сигнатур и семантики функций.

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

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

Наиболее известные API

API операционных систем(POSIX, Windows API, Cocoa, Linux Kernel API, OS/2 API, Amiga ROM Kernel)

API графических интерфейсов (OpenGL, OpenVG, X11, GTK)

API звуковых интерфейсов (DirectSound, DirectMusic, OpenAL)

API аутентификационных систем (BioAPI, PAM)

47. Протокол ODBC.

ODBC (Open Database Connectivity – открытый доступ к базам данных) – разработанный компанией Microsoft универсальный интерфейс программирования приложений для доступа к базам данных.

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

Рассмотрим кратко структуру программного обеспечения ODBC:

• интерфейс вызовов функций ODBC: это так называемый верхний уровень ODBC, содержащий API, который и используется непосредственно приложениями. Данный API реализован в виде библиотеки динамической компоновки Dll и входит в состав операционной системы Windows;

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

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

Схема выполнения программы с использованием протокола ODBC для доступа к данным приводится на рис. 13.5.

Рис. 13.5.  Схема выполнения программы с использованием протокола ODBC для доступа к данным

48. Протокол JDBC.

JDBC (Java Database Connectivity) представляет собой API для выполнения SQL-запросов к базам данных из программ, написанных на языке Java.

Рассмотрим основные принципы JDBC.

С развитием глобальных сетей, в частности Интернета, и всех сопутствующих технологий стали появляться новые языки, специально предназначенные для работы в новых условиях. Одним из таких языков является язык программирования Java. В настоящее время Интернет-приложения занимают существенное место на рынке, работая в рамках 2-, 3- и многозвенной архитектуры. При этом значение языка Java как средства создания приложений, работающих с базами данных, существенно возрастает. Именно это и явилось одной из основных причин разработки нового программного интерфейса – JDBC. Первоначально интерфейс JDBC был разработан компанией Sun Microsystems, в настоящий момент этот API поддерживается всеми ведущими коммерческими СУБД.

Известно несколько различных версий JDBC. Так, версия 1.0 содержала некоторые средства доступа к данным:

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

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

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

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

Этот перечень определенным образом напоминает аналогичный функциональный аппарат протокола ODBC.

Версия JDBC 2.0 содержит существенные отличия. Так, вследствие увеличения возможностей интерфейса было проведено его идеологическое разделение на две основные части: Core API (основные возможности) и Extensions API (так называемые расширения).

Возможности JDBC:

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

• Курсоры с произвольным доступом. В JDBC 2.0 существует средство, позволяющее перемещаться по результатам запроса произвольным образом.

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

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

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

49. Библиотека DB-Library.

Библиотека DB-Library реализует интерфейс программирования приложений для совместной работы с широко распространенной СУБД Microsoft SQL Server. Данная библиотека является весьма обширной и содержит более 100 функций. Основными из них являются:

• dblogin(); dbopen() – подключение к БД;

• dbopen(); dbexit() – установка/разрыв соединения с БД;

• dbcmd() – передача инструкции (пакета инструкций) SQL в СУБД в текстовом виде;

• dbSQLexec() – требование к СУБД выполнить текущий пакет инструкций;

• dbcancel() – прекращение выполнения пакета инструкций SQL;

• dbresults() – получение результатов выполнения очередной инструкции SQL в текущем пакете;

• dbbind(), dbdata(), dbnextrow(), dbnumcols(), dbdatlen() и др. – обработка результатов запросов на выборку данных.

Логика работы прикладной программы, обрабатывающей данные, хранящиеся в базе данных под управлением Microsoft SQL Server, выглядит следующим образом:

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

• при помощи СУБД программа открывает конкретную базу данных, с которой будет происходить работа ( dbopen() );

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

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

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

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

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

50. СУБД: определение, история развития, основные средства.

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

Основными средствами СУБД являются:

- средства задания (описания) структуры базы данных;

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

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

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

- языковые средства -- макросы, встроенный алгоритмический язык (Dbase, Visual Basic или другой), язык запросов (QBE -- Query By Example, SQL) и т.п., которые используются для реализации нестандартных алгоритмов обработки данных, а также процедур обработки событий в задачах пользователя;

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

История развития

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

В середине 60-х годов корпорация IBM совместно с фирмой NAA (North American Aviation, в настоящее время - Rockwell International) разработали первую СУБД - иерархическую систему IMS (Information Management System). Несмотря на то, что IMS является самой первой из всех коммерческих СУБД, она до сих пор остается основной иерархической СУБД, используемой на большинстве крупных мейнфреймов.

Другим заметным достижением середины 60-х годов было появление системы IDS (Integrated Data Store) фирмы General Electric. Развитие этой системы привело к созданию нового типа систем управления базами данных - сетевых СУБД. Сетевая СУБД создавалась для представления более сложных взаимосвязей между данными и послужили основой для разработки первых стандартов БД. Для создания таких стандартов в 1965 году на конференции CODASYL (Conference on Data Systems Languages) была сформирована рабочая группа List Processing Task Force, переименованная в 1967 году в группу Data Base Task Group (DBTG). Полный вариант отчета этой группы был опубликован в в 1971 году.

Несмотря на то что этот отчет официально не был одобрен Национальным Институтом Стандартизации США (American National Standards Institute - ANSI), большое количество систем было разработано в полном соответствии с этими предложениями группы DBTG. Теперь они называются CODASYL-системами, или DBTG-системами. CODASYL-системы и системы на основе иерархических подходов представляют собой СУБД первого поколения. Однако этим двум моделям присущи приведенные ниже недостатки.

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

• Независимость от данных существует лишь в минимальной степени.

• Отсутствуют теоретические основы.

В настоящее время существует несколько сотен различных реляционных СУБД для мейнфреймов и персональных ЭВМ. Многопользовательские СУБД: система CA-OpenIngres фирмы Computer Associates и система Informix фирмы Informix Software, Inc. Реляционных СУБД для ПК: Access и FoxPro фирмы Microsoft, Paradox и Visual dBase фирмы Borland. Реляционные СУБД относятся к СУБД второго поколения. Однако реляционная модель также обладает некоторыми недостатками - в частности, ограниченными возможностями моделирования.

Для решения этой проблемы был выполнен большой объем исследовательской работы. В 1976 году Чен предложил модель "сущность-связь" (Entity-Relationship model - ER-модель), которая в настоящее время стала основой методологии концептуального проектирования баз данных и методологии логического проектирования реляционных баз данных. В 1979 году Кодд опубликовал расширенную версию реляционной модели - RM/T (1979), затем еще одну версию - RM/V2 (1990). Попытки создания модели данных, позволяющей более точно описывать реальный мир, нестрого называют семантическим моделированием данных (semantic data modeling).

В ответ на все возрастающую сложность приложений баз данных появились две новые системы: объектно-ориентированные СУБД, или ОО СУБД (Object-Oriented DBMS - OODBMS), и объектно-реляционные СУБД, или ОР СУБД (Object-Relational DBMS - ORDBMS). Попытки реализации подобных моделей представляют собой СУБД третьего поколения.

51. Компоненты СУБД. Распределение обязанностей в системах с базами данных.

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

1)Аппаратное обеспечение. Для работы СУБД и приложений необходимо некоторое аппаратное обеспечение. Используемое аппаратное обеспечение зависит от требований данной организации и типа СУБД. Одни СУБД предназначены для работы только с конкретными типами операционных систем или оборудования, другие могут работать с широким кругом аппаратного обеспечения и различными операционными системами.

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

3)Данные. Вероятно, самым важным компонентом среды СУБД (с точки зрения конечных пользователей) являются данные. База данных содержит как рабочие данные, так и метаданные, т.е. "данные о данных". Структура базы данных называется схемой. 

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