Номер поставщика	Наименование поставщика	Город поставщика
1	Иванов	Уфа
2	Петров	Москва
3	Сидоров	Москва
4	Сидоров	Челябинск

Таблица 11 Отношение A (Поставщики)

Проекция будет иметь вид:

Город поставщика
Уфа
Москва
Челябинск

Таблица 12 Отношение A [Город поставщика]

Соединение

Общая операция соединения

Соединением отношений A и B по условию называется отношение (A TIMES B) WYERE c. c представляет собой логическое выражение, в которое могут входить атрибуты отношений A и B и (или) скалярные выражения. Таким образом, операция соединения есть результат последовательного применения операций декартового произведения и выборки. Если в отношениях A и B имеются атрибуты с одинаковыми наименованиями, то перед выполнением соединения такие атрибуты необходимо переименовать.

Тэта-соединение

Пусть отношение A содержит атрибут X, отношение B содержит атрибут Y, а и - один из операторов сравнения (<, >, >=, <= и т.д.). Тогда и-соединением отношения A по атрибуту X с отношением B по атрибуту Y называют отношение (A TIMES B) WHERE XиY или A[XиY]B. Это частный случай операции общего соединения.

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



Номер поставщика	Наименование поставщика	X (Статус поставщика)
1	Иванов	4
2	Петров	1
3	Сидоров	2

Таблица 13 Отношение A (Поставщики)

Номер детали	Наименование детали	Y(Статус детали)
1	Болт	3
2	Гайка	2
3	Винт	1

Таблица 14 Отношение B (Детали)

Ответ на вопрос "какие поставщики имеют право поставлять какие детали?" дает -соединение :

Номер поставщика	Наименованиепоставщика	X (Статус поставщика)	Номер детали	Наименование детали	Y (Статус детали)
1	Иванов	4	1	Болт	3
1	Иванов	4	2	Гайка	2
1	Иванов	4	3	Винт	1
2	Петров	1	3	Винт	1
3	Сидоров	2	2	Гайка	2
3	Сидоров	2	3	Винт	1

Таблица 15 Отношение "Какие поставщики поставляют какие детали"

Естественное соединение

Пусть даны отношения A(A₁, A₂,…,A_n , X₁, X₂,…,X_n) и B(X₁, X₂,…,X_n , B₁, B₂,…,B_m), имеющие одинаковые атрибуты X₁, X₂,…,X_n (т.е. атрибуты с одинаковыми именами и определенные на одинаковых доменах). Тогда естественным соединением отношений A и B называется отношение с заголовком (A₁, A₂,…,A_n , X₁, X₂,…,X_n , B₁, B₂,…,B_m) и телом, содержащим множество кортежей (a₁, a₂,…, a_n, x₁, x₂,…, x_n, b₁, b₂…, b_n) таких, что (a₁, a₂,…, a_n, x₁, x₂,…, x_n,)ОA и (x₁, x₂,…, x_n, b₁,b₂…, b_n)ОB. Естественное соединение настолько важно, что для него используют специальный синтаксис: A JOIN B. Естественное соединение производится по всем одинаковым атрибутам.

Естественное соединение эквивалентно следующей последовательности реляционных операций:

1. Переименовать одинаковые атрибуты в отношениях

2. Выполнить декартово произведение отношений

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

4. Выполнить проекцию, удалив повторяющиеся атрибуты

5. Переименовать атрибуты, вернув им первоначальные имена

Пример. В предыдущем примере ответ на вопрос "какие детали поставляются поставщиками", более просто записывается в виде естественного соединения трех отношений P JOIN PD JOIN D (для удобства просмотра порядок атрибутов изменен, это является допустимым по свойствам отношений):

Номер поставщика PNUM	Наименование поставщика PNAME	Номердетали DNUM	Наименование детали DNAME	Поставляемое количество VOLUME
1	Иванов	1	Болт	100
1	Иванов	2	Гайка	200
1	Иванов	3	Винт	300
2	Петров	1	Болт	150
2	Петров	2	Гайка	250
3	Сидоров	1	Болт	1000

Таблица 20 Отношение P JOIN PD JOIN D

Деление

Пусть даны отношения A(X₁, X₂,…, X_n , Y₁, Y₂,…,Y_m) и B (Y₁, Y₂,…,Y_m), причем атрибуты Y₁,Y₂,…,Y_m - общие для двух отношений. Делением отношений A на B называется отношение с заголовком (X₁, X₂,…, X_n) и телом, содержащим множество кортежей (x₁, x₂,…, x_n) таких, что для всех кортежей (y₁, y₂,…, y_m)ОB в отношении найдется кортеж (x₁, x₂,…, x_n , y₁, y₂,…, y_m). Отношение A выступает в роли делимого, отношение B выступает в роли делителя. Синтаксис операции деления: A DEVIDBY B.

Пример. В примере с поставщиками, деталями и поставками ответим на вопрос, "какие поставщики поставляют все детали?". В качестве делимого возьмем проекцию X=PD[PNUM, DNUM], содержащую номера поставщиков и номера поставляемых ими деталей:

Номер поставщика PNUM	Номер детали DNUM
1	1
1	2
1	3
2	1
2	2
3	1

Таблица 21 Проекция X=PD[PNUM,DNUM]

В качестве делителя возьмем проекцию Y=D[DNUM], содержащую список номеров всех деталей (не обязательно поставляемых кем-либо):

Номер детали DNUM
1
2
3

Таблица 22 Проекция Y=D[DNUM]

Деление дает список номеров поставщиков, поставляющих все детали:

Номер поставщика PNUM
1

Таблица 23 Отношение X DEVIDEBY Y

13. Оптимизация запросов к базе данных

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

14. Основные функции и компоненты СУБД

Функции СУБД:

1. ведение БД: ввод, корректир, сортировка, обработка, поиск данных, обработка по запросу.

2. обеспечение безопасности и целостности данных

3. управление приоритетами

4. формирование отчетов

5. операции над служебными данными (метаданными)

6. связь с пользователем

7. средства буферизации данных

8. обеспечение теледоступа

9. контроль достоверности данных

В различных СУБД все эти функции реализованы по-разному.

Компоненты СУБД:

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

11. средства для разработки БД (типа конструктора БД), позволяет создавать таблицы

12. средства для модификации структуры БД

13. средства для оптимизации программирования (конструктор запросов, мастер запросов, форм, отчетов)

14. отладчик

15. генератор (API) приложений

16. обучающая программа +примеры

17. библиотека функций

18. язык запросов

19. компилятор

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

Выделяется на этом фоне Access, удобная, т.к. понятная и рассчитана не на программистов.

15. Клиентские СУБД, примеры, назначение и возможности

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

· обеспечивать получение общих и/или детализированных отчетов по итогам работы;

· позволять легко определять тенденции изменения важнейших показателей;

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

· выполнять точный и полный анализ данных.

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

Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще - диалекты SQL и/или VBA)и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

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

(Обзор современных реляционных СУБД)

Многие направления обработки данных нуждаются в средствах управления базами данных. Независимо от способа выбора, 9 из 10 выбранных реляционных СУБД является продуктом одной из шести фирм (дабы не обижать кого-то в алфавитном порядке) IBM, INFORMIX, INPRISE, MICROSOFT, ORACLE, SYBASE. Мы не собираемся здесь анализировать причины выбора кем-то продукта той, а не иной фирмы. Мы не проводили сравнений этих продуктов (дело это очень дорогое, так как требует одинаково хорошее и глубокое знание продуктов), не ориентировались мы и на данные независимых исследователей. Не желая кого-либо обидеть, тем не менее, каждая новая версия сопровождается статьей, где она сравнивается с продуктом конкурирующей фирмы, и где выпячивается лучшие ее стороны. Маркетинг есть маркетинг. Ничего с этим не поделаешь.

По результатам за 1998 год распространенность СУБД на мировом рынке выстраивает рейтинг в следующем порядке: DB2, Oracle, MS SQL, Sybase SQL, Informix. Однако такой порядок больше говорит об эффективности маркетинговой политике, нежели о качественных характеристиках тех или иных продуктов. Выбор по рейтингу не оптимален, но еще хуже, когда он осуществляется по совету знакомых («нет … в своем отечестве») или вообще директивно (по «политическим» мотивам). Мы рекомендуем учитывать, в первую очередь, стоимость владения и сопровождения СУБД в российских условия, которая однозначно связана на количеством и качеством специалистов на рынке труда. Этот критерий, ничем не хуже рейтинга продаж или рекламных сравнительных статей.

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

16. Серверные СУБД, примеры, назначение и возможности

Oracle, Informix, Sy Base, Microsoft SQL Server…

Отличительные особенности серверных СУБД:

1. поддержка архитектуры клиент-сервер

2. работа с распределенными СУБД

3. большое число пользователей

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

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

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

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

1. снижается объем передаваемых данных по сети

2. выборка этих данных осуществляется быстрее (быстродействие), т.к эта хорошо разработанная серверная СУБД.

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

Все современные серверные СУБД обеспечивают архитектуру клиент-сервер.

Функции, кот выполняет сервер БД:

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

2. хранение и резервное копирование данных

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

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

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

Особенности серверных СУБД:

6. Практически все серв СУБД обладают более высокой производительностью

7. меньше загружают комп. сеть

8. имеют более совершенные средства безопасности

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

10. могут работать с несколькими сетевыми операционными системами

11. имеют утилиты администрирования (удобные)

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

13. поддерживают создание OLAP и хранилищ данных

14. поддержание распределенных запросов и транзакций

15. обеспечивают электронную коммерцию и публикацию данных в Internet.

Механизм доступа к данным:

Первые механизмы разработала фирма Borland.

16. BDE

17. Специальные драйвера

17. Основные операторы SQL. Синтаксис и примеры использования оператора SELECT

Основу языка SQL составляют операторы, условно разбитые не несколько групп по выполняемым функциям.

Можно выделить следующие группы операторов (перечислены не все операторы SQL):

Операторы DDL (Data Definition Language) - операторы определения объектов базы данных

· CREATE SCHEMA - создать схему базы данных

· DROP SHEMA - удалить схему базы данных

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

· ALTER TABLE - изменить таблицу

· DROP TABLE - удалить таблицу

· CREATE DOMAIN - создать домен

· ALTER DOMAIN - изменить домен

· DROP DOMAIN - удалить домен

· CREATE COLLATION - создать последовательность

· DROP COLLATION - удалить последовательность

· CREATE VIEW - создать представление

· DROP VIEW - удалить представление

Операторы DML (Data Manipulation Language) - операторы манипулирования данными

· SELECT - отобрать строки из таблиц

· INSERT - добавить строки в таблицу

· UPDATE - изменить строки в таблице

· DELETE - удалить строки в таблице

· COMMIT - зафиксировать внесенные изменения

· ROLLBACK - откатить внесенные изменения

Операторы защиты и управления данными

· CREATE ASSERTION - создать ограничение

· DROP ASSERTION - удалить ограничение

· GRANT - предоставить привилегии пользователю или приложению на манипулирование объектами

· REVOKE - отменить привилегии пользователя или приложения

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

Наиболее важными для пользователя являются операторы манипулирования данными (DML).

Примеры использования операторов манипулирования данными

INSERT - вставка строк в таблицу

Пример 1. Вставка одной строки в таблицу:

INSERT INTO

P (PNUM, PNAME)

VALUES (4, "Иванов");

UPDATE - обновление строк в таблице

Пример 3. Обновление нескольких строк в таблице:

UPDATE P

SET PNAME = "Пушников"

WHERE P.PNUM = 1;

DELETE - удаление строк в таблице

Пример 4. Удаление нескольких строк в таблице:

DELETE FROM P

WHERE P.PNUM = 1;

Примеры использования оператора SELECT

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

Оператор SELECT всегда выполняется над некоторыми таблицами, входящими в базу данных.

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

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

Порядок выполнения оператора SELECT

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

Стадия 1. Выполнение одиночного оператора SELECT

Если в операторе присутствуют ключевые слова UNION, EXCEPT и INTERSECT, то запрос разбивается на несколько независимых запросов, каждый из которых выполняется отдельно:

Шаг 1 (FROM). Вычисляется прямое декартовое произведение всех таблиц, указанных в обязательном разделе FROM. В результате шага 1 получаем таблицу A.

Шаг 2 (WHERE). Если в операторе SELECT присутствует раздел WHERE, то сканируется таблица A, полученная при выполнении шага 1. При этом для каждой строки из таблицы A вычисляется условное выражение, приведенное в разделе WHERE. Только те строки, для которых условное выражение возвращает значение TRUE, включаются в результат. Если раздел WHERE опущен, то сразу переходим к шагу 3. Если в условном выражении участвуют вложенные подзапросы, то они вычисляются в соответствии с данной концептуальной схемой. В результате шага 2 получаем таблицу B.

Шаг 3 (GROUP BY). Если в операторе SELECT присутствует раздел GROUP BY, то строки таблицы B, полученной на втором шаге, группируются в соответствии со списком группировки, приведенным в разделе GROUP BY. Если раздел GROUP BY опущен, то сразу переходим к шагу 4. В результате шага 3 получаем таблицу С.

Шаг 4 (HAVING). Если в операторе SELECT присутствует раздел HAVING, то группы, не удовлетворяющие условному выражению, приведенному в разделе HAVING, исключаются. Если раздел HAVING опущен, то сразу переходим к шагу 5. В результате шага 4 получаем таблицу D.

Шаг 5 (SELECT). Каждая группа, полученная на шаге 4, генерирует одну строку результата следующим образом. Вычисляются все скалярные выражения, указанные в разделе SELECT. По правилам использования раздела GROUP BY, такие скалярные выражения должны быть одинаковыми для всех строк внутри каждой группы. Для каждой группы вычисляются значения агрегатных функций, приведенных в разделе SELECT. Если раздел GROUP BY отсутствовал, но в разделе SELECT есть агрегатные функции, то считается, что имеется всего одна группа. Если нет ни раздела GROUP BY, ни агрегатных функций, то считается, что имеется столько групп, сколько строк отобрано к данному моменту. В результате шага 5 получаем таблицу E, содержащую столько колонок, сколько элементов приведено в разделе SELECT и столько строк, сколько отобрано групп.

Стадия 2. Выполнение операций UNION, EXCEPT, INTERSECT

Если в операторе SELECT присутствовали ключевые слова UNION, EXCEPT и INTERSECT, то таблицы, полученные в результате выполнения 1-й стадии, объединяются, вычитаются или пересекаются.

Стадия 3. Упорядочение результата

Если в операторе SELECT присутствует раздел ORDER BY, то строки полученной на предыдущих шагах таблицы упорядочиваются в соответствии со списком упорядочения, приведенном в разделе ORDER BY.

18. Реляционная полнота SQL

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

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

Оператор декартового произведения

Реляционная алгебра:

Оператор SQL:

SELECT A.Поле1, A.Поле2, …, B.Поле1, B.Поле2, …

FROM A, B;

или

SELECT A.Поле1, A.Поле2, …, B.Поле1, B.Поле2, …

FROM A CROSS JOIN B;

Оператор проекции

Реляционная алгебра:

Оператор SQL:

SELECT DISTINCT X, Y, …, Z

FROM A;

Оператор выборки

Реляционная алгебра: ,

Оператор SQL:

SELECT *

FROM A

WHERE c;

Оператор объединения

Реляционная алгебра:

Оператор SQL:

SELECT *

FROM A

UNION

SELECT *

FROM B;

Оператор вычитания

Реляционная алгебра:

Оператор SQL:

SELECT *

FROM A

EXCEPT

SELECT *

FROM B

Реляционный оператор переименования RENAME выражается при помощи ключевого слова AS в списке отбираемых полей оператора SELECT. Таким образом, язык SQL является реляционно-полным.

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

Оператор соединения Реляционная алгебра: Оператор SQL: SELECT A.Поле1, A.Поле2, …, B.Поле1, B.Поле2, … FROM A, B WHERE c; или SELECT A.Поле1, A.Поле2, …, B.Поле1, B.Поле2, … FROM A CROSS JOIN B WHERE c;	Оператор пересечения Реляционная алгебра: Оператор SQL: SELECT * FROM A INTERSECT SELECT * FROM B;

Оператор деления

Реляционная алгебра:

Оператор SQL:

SELECT DISTINCT A.X

FROM A

WHERE NOT EXIST

(SELECT *

FROM B

WHERE NOT EXIST

(SELECT *

FROM A A1

WHERE

A1.X = A.X AND

A1.Y = B.Y));

19. Методология RAD

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

· небольшую команду программистов (от 2 до 10 человек);

· короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

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

· фаза анализа и планирования требований;

· фаза проектирования;

· фаза построения;

· фаза внедрения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20. Инструментальные средства CASE технологии

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

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

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:

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

графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

средства разработки приложений, включая языки 4GL и генераторы кодов;

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

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

средства тестирования;

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

средства анализа , предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

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

средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin, S-Designor

средства разработки приложений. К ним относятся средства 4GL, JAM, SQL Windows (Gupta).

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

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

21. Методы контроля достоверности экономической информации

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

22. Объектно-ориентированные СУБД. Параллельная обработка данных

Объектно-ориентированные СУБД

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

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

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

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

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

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

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

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

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

СУБД с параллельной обработкой данных

Информационные хранилища на базе СУБД с параллельной обработкой данных рассчитаны на многопроцессорные системы. Такие СУБД разделяются по типу архитектуры - без разделения ресурсов и с совместным использованием дискового пространства. В первом случае за каждым из процессоров закреплены выделенные области памяти и диски, что дает хорошую скорость обработки. Во втором случае все процессоры делят между собой как оперативную память, так и все место на диске. Примерами СУБД без разделения ресурсов являются : DB2 (IBM), Informix Online Dynamic (Informix), Navigation Server (Sybase). СУБД с совместным использованием памяти является AdabasD версия 6,1. В СУБД Oracle 7.2 обеспечивается лучшая переносимость на различные платформы.

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

Параллельная обработка запросов

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

23. Распределенные и полнотекстовые базы данных. Хранилища данных

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

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

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

Размещено на Allbest.ru