26800

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

Реферат

Информатика, кибернетика и программирование

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

Русский

2013-08-18

420.15 KB

35 чел.

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

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

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

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

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

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

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

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

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

  1.  Файлы и файловые системы.

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

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

  1.  создать файл (требуемого типа и размера);
  2.  открыть ранее созданный файл;
  3.  прочитать из файла некоторую запись (текущую, следующую, предыдущую, первую, последнюю);
  4.  записать в файл на место текущей записи новую, добавить новую запись в конец файла.

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

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

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

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

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

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

  1.  Распределенные БД.

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

Особенности данного этапа:

  1.  Практически все современные СУБД обеспечивают поддержку полной реляционной модели, а именно:
  2.  структурной целостности — допустимыми являются только данные, представленные в виде отношений реляционной модели;
  3.  языковой целостности, то есть языков манипулирования данными высокого уровня (в основном SQL);
  4.  ссылочной целостности, контроля за соблюдением ссылочной целостности в течение всего времени функционирования системы, и гарантий невозможности со стороны СУБД нарушить эти ограничения.
  5.  Большинство современных СУБД рассчитаны на многоплатформенную архитектуру, то есть они могут работать на компьютерах с разной архитектурой и под разными операционными системами, при этом для пользователей доступ к данным, управляемым СУБД на разных платформах, практически неразличим.
  6.  Необходимость поддержки многопользовательской работы с базой данных и возможность децентрализованного хранения данных потребовали развития средств администрирования БД с реализацией общей концепции средств защиты данных.
  7.  Потребность в новых реализациях вызвала создание серьезных теоретических трудов по оптимизации реализаций распределенных БД и работе с распределенными транзакциями и запросами с внедрением полученных результатов в коммерческие СУБД.
  8.  Для того чтобы не потерять клиентов, которые ранее работали на настольных СУБД, практически все современные СУБД имеют средства подключения клиентских приложений, разработанных с использованием настольных СУБД, и средства экспорта данных из форматов настольных СУБД второго этапа развития.
  9.  Именно к этому этапу можно отнести разработку ряда стандартов в рамках языков описания и манипулирования данными начиная с SQL89, SQL92, SQL99 и технологий по обмену данными между различными СУБД, к которым можно отнести и протокол ODBC (Open DataBase Connectivity), предложенный фирмой Microsoft.
  10.  Именно к этому этапу можно отнести начало работ, связанных с концепцией объектно-ориентированных БД — ООБД. Представителями СУБД, относящимся ко второму этапу, можно считать MS Access 97 и все современные серверы баз данных Oracle7.3,Oracle 8.4 MS SQL6.5, MS SQL7.0, MS SQL 2000, System 10, System 11, Informix, DB2, SQL Base и другие современные серверы баз данных, которых в настоящий момент насчитывается несколько десятков.
  11.  Архитектура БД. Физическая и логическая независимость.

Рис. 1.2. Трехуровневая модель системы управления базой данных, предложенная ANSI

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

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

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

1. Пользователь посылает СУБД запрос на получение данных из БД.

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

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

4. СУБД получает информацию о запрошенной части концептуальной модели.

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

6. В СУБД возвращается информация о местоположении данных в терминах операционной системы.

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

8. Операционная система осуществляет перекачку информации из устройств хранения и пересылает ее в системный буфер.

9. Операционная система оповещает СУБД об окончании пересылки.

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

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

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

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

  1.  Проектирование. Реализация. Эксплуатация; Модернизация и развитие. Полная реорганизация.

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

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

  1.  Конечные пользователи. Это основная категория пользователей, в интересах которых и создается банк данных. В зависимости от особенностей создаваемого банка данных круг его конечных пользователей может существенно различаться. Это могут быть случайные пользователи, обращающиеся к БД время от времени за получением некоторой информации, а могут быть регулярные пользователи. В качестве случайных пользователей могут рассматриваться, например, возможные клиенты вашей фирмы, просматривающие каталог вашей продукции или услуг с обобщенным или подробным описанием того и другого. Регулярными пользователями могут быть ваши сотрудники, работающие со специально разработанными для них программами, которые обеспечивают автоматизацию их деятельности при выполнении своих должностных обязанностей. Например, менеджер, планирующий работу сервисного отдела компьютерной фирмы, имеет в своем распоряжении программу, которая помогает ему планировать.и распределять текущие заказы, контролировать ход их выполнения, заказывать на складе необходимые комплектующие для новых заказов. Главный принцип состоит в том, что от конечных пользователей не должно требоваться каких-либо специальных знаний в области вычислительной техники и языковых средств.
  2.  Администраторы банка данных. Это группа пользователей, которая на начальной стадии разработки банка данных отвечает за его оптимальную организацию с точки зрения одновременной работы множества конечных пользователей, на стадии эксплуатации отвечает за корректность работы данного банка информации в многопользовательском режиме. На стадии развития и реорганизации эта группа пользователей отвечает за возможность корректной реорганизации банка без изменения или прекращения его текущей эксплуатации.
  3.  Разработчики и администраторы приложений. Это группа пользователей, которая функционирует во время проектирования, создания и реорганизации банка данных. Администраторы приложений координируют работу разработчиков при разработке конкретного приложения или группы приложений, объединенных в функциональную подсистему. Разработчики конкретных приложений работают с той частью информации из базы данных, которая требуется для конкретного приложения.

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

Рассмотрим их более подробно.

В составе группы администратора БД должны быть:

  1.  системные аналитики;
  2.  проектировщики структур данных и внешнего по отношению к банку данных информационного обеспечения;
  3.  проектировщики технологических процессов обработки данных;
  4.  системные и прикладные программисты;
  5.  операторы и специалисты по техническому обслуживанию.

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

  1.  Основные функции группы администратора БД.
  2.  Анализ предметной области:

- описание предметной области,

- выявление ограничений целостности,

- определение статуса (доступности, секретности) информации,

- определение потребностей пользователей, определение соответствия «данные — пользователь»,

- определение объемно-временных характеристик обработки данных.

2. Проектирование структуры БД:

- определение состава и структуры файлов БД и связей между ними,

- выбор методов упорядочения данных и методов доступа к информации, описание БД на языке описания данных (ЯОД).

3. Задание ограничений целостности при описании структуры БД и процедур обработки БД: 

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

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

- определение ограничений целостности, вызванных структурой БД;

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

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

4. Первоначальная загрузка и ведение БД: 

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

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

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

5. Защита данных: 

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

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

- разработка средств фиксации доступа к данным и попыток нарушения системы защиты;

- тестирование системы защиты;

- исследование случаев нарушения системы защиты и развитие динамических методов защиты информации в БД.

6. Обеспечение восстановления БД: 

- разработка организационных средств архивирования и принципов восстановления БД;

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

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

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

8. Анализ эффективности функционирования БД: 

- анализ показателей функционирования БД;

- планирование реструктуризации (изменение структуры) БД и реорганизации БнД.

9. Работа с конечными пользователями:

- сбор информации об изменении предметной области;

- сбор информации об оценке работы БД;

- обучение пользователей, консультирование пользователей;

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

10. Подготовка и поддержание системных средств:

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

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

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

- курирование подключения новых программных средств к БД.

11. Организационно-методическая работа по проектированию БД:

- выбор или создание методики проектирования БД;

- определение целей и направления развития системы в целом;

- планирование этапов развития БД;

- разработка общих словарей-справочников проекта БД и концептуальной модели;

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

курирование подключения нового приложения к действующей БД;

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

  1.  Классификация моделей данных.

Одними из основополагающих в концепции баз данных являются обобщенные категории «данные» и «модель данных».

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

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

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

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

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

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

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

Модели, основанные на языках разметки документов, связаны прежде всего со стандартным общим языком разметки — SGML (Standart Generalised Markup Language), который был утвержден ISO в качестве стандарта еще в 80-х годах. Этот язык предназначен для создания других языков разметки, он определяет допустимый набор тегов (ссылок), их атрибуты и внутреннюю структуру документа. Контроль за правильностью использования тегов осуществляется при помощи специального набора правил, называемых DTD-описаниями, которые используются программой клиента при разборе документа. Для каждого класса документов определяется свой набор правил, описывающих грамматику соответствующего языка разметки. С помощью SGML можно описывать структурированные данные, организовывать информацию, содержащуюся в документах, представлять эту информацию в некотором стандартизованном формате. Но ввиду некоторой своей сложности SGML использовался в основном для описания синтаксиса других языков (наиболее известным из которых является HTML), и немногие приложения работали с SGML-документами напрямую.

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

Однако HTML сегодня уже не удовлетворяет в полной мере требованиям, предъявляемым современными разработчиками к языкам подобного рода. И ему на смену был предложен новый язык гипертекстовой разметки, мощный, гибкий и, одновременно с этим, удобный язык XML. В чем же заключаются его достоинства?

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

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

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

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

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

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

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

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

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

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

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

Экземпляры-потомки одного типа, связанные с одним экземпляром сегмента-предка, называют «близнецами».

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

Стандарт сетевой модели впервые был определен в 1975 году организацией CODASYL (Conference of Data System Languages), которая определила базовые понятия модели и формальный язык описания.

Сетевая модель позволяет отображать разнообразные взаимосвязи элементов данных в виде произвольного графа:

Базовыми объектами модели являются:

  1.  элемент данных;
  2.  агрегат данных;
  3.  запись;
  4.  набор данных,

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

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

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

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

  1.  Реляционная модель данных основные понятия.

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

Элементы РМД и формы их представления:

Отношения

Таблица

Схема отношения

Строка заголовков столбцов таблицы

Кортеж

Строка таблицы

Сущность

Описание свойств объекта

Атрибут

Заголовок столбца таблицы

Домен

Множество допустимых значений атрибута

Значение атрибута

Значение поля в записи

Первичный ключ

Один или несколько атрибутов

Тип данных

Тип значений элементов в таблице

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

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

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

N-арным отношением R называют подмножество декартова произведения D1xD2x ... xDn множеств D1, D2, ..., Dn (n > 1), необязательно различных. Исходные множества D1, D2, ..., Dn называют в модели доменами.

R D1xD2x...xDm, где D1xD2x ...xDn— полное декартово произведение.

Полное декартово произведение — это набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется из своего домена.

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

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

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

 Схема отношения (заголовок) представляет собой список имён атрибутов.

Множество кортежей отношения часто называют содержимым или телом.

 Степень отношения  - это число его атрибутов. Кардинальное число или мощность – число кортежей.

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

  1.  Реляционная алгебра операции над отношениями.

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

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

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

Теоретико-множественные операции:

1. Объединением двух отношении называется отношение, содержащее множество кортежей, принадлежащих либо первому, либо второму исходным отношениям, либо обоим отношениям одновременно.

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

3. Разностью отношений R1 и R2 называется отношение, содержащее множество кортежей, принадлежащих R1 и не принадлежащих R2

Сцеплением, пли конкатенацией, кортежей с = <c1, с2, ..., сn> и q = <q1, q2, ..., qm> называется кортеж, полученный добавлением значений второго в конец первого.

4. Расширенным декартовым произведением отношения R, степени n со схемой

SR1=(А12...,Аn) и отношения R2 степени m со схемой

SR2=(В12, ... , Вm) называется отношение R3 степени n+m со схемой

SR3 = (А1, А2, ... , Аn, В1, В2, ..., Вm),

содержащее кортежи, полученные сцеплением каждого кортежа г отношения R1 с каждым кортежем q отношения R2.

Специальные операции:

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

Пусть а — булевское выражение, составленное из термов сравнения с помощью связок И, ИЛИ, НЕ и, возможно, скобок. В качестве термов сравнения допускаются:

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

б) терм А ос В, где А, В — имена некоторых Q-сравнимых атрибутов, то есть атрибутов, принимающих значения из одного и то же домена D.

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

2. Проекцией отношения R на набор атрибутов В, обозначаемой R[B], называется отношение со схемой, соответствующей набору атрибутов В SR|B| = В, содержащему кортежи, получаемые из кортежей исходного отношения R путем удаления из них значений, не принадлежащих атрибутам из набора В.

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

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

3. Операция условного соединения.

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

Пусть R = {r}, Q = { q } — исходные отношения,

SR, SQ — схемы отношений R и Q соответственно.

SR = (А1, А2, ... , Ak): SQ = (В1 В2, ... , Bm),

где А, В — имена атрибутов в схемах отношений R и Q соответственно. При этом полагаем, что заданы наборы атрибутов А и В.

А {Аi} ,j=1,k; В {Bj} j=1,m, и эти наборы состоят из Q-сравнимых атрибутов.

Тогда соединением отношений R и Q при условии р будет подмножество декартова произведения отношений R и Q, кортежи которого удовлетворяют условию р, рассматриваемому как одновременное выполнение условий:

  1.  r.Aj Qj Вi, : i=l,k, где k — число атрибутов, входящих в наборы А и В, а Qj— конкретная операция сравнения.
  2.  Aj Qj Вi Di Qi — i-й предикат сравнения, определяемый из множества допустимых на домене Di операций сравнения.

R [ Р ] Q = { r.q) | (г. q) | r.A Qj q.Bj - «Истина», i=l,k}

4. Последней операцией, включаемой в набор операций реляционной алгебры, является операция деления.

Для определения операции деления рассмотрим сначала понятие множества образов.

Пусть R — отношение со схемой SR = (A1, A2 ,..., Ak);

Пусть А — некоторый набор атрибутов А {Аi} i=l,k , А1 — набор атрибутов, не входящих в множество А.

Пересечение множеств А и А1 пусто: А А1 = 0; объединение множеств равно множеству всех атрибутов исходного отношения: A А1 = SR.

Тогда множеством образов элемента у проекции R[А] называется множество таких элементов у проекции R[A1] , для которых сцепление (х, у) является кортежами отношения R, то есть

QA(x) = {у | у R[A1] ^ (х, у) R} - множество образов.

Дадим теперь определение операции деления. Пусть даны два отношения R и Т соответственно со схемами: SR = (А1, А2, ... , Ak); ST =-(В1, В2, ... , Вm);

А и В — наборы атрибутов этих отношений, одинаковой длины (без повторений);

А SR ; В ST. Атрибуты А1 — это атрибуты из R, не вошедшие в множество А.

Пересечение множеств А А1 = — пусто и A А1 = SR. Проекции R[A] и Т[В] совместимы по объединению, то есть имеют эквивалентные схемы: SR|A|~ ST[B|.

Тогда операция деления ставит в соответствие отношениям R и Т отношение Q = R[A:B]T, кортежи которого являются теми элементами проекции R[A1], для которых Т[В] входит в построенные для них множество образов:

R[A:B]T = {r | r R[A1] ^ Т[В] (у | у R [А] ^ (r, у) R } }.

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

  1.  История развития SQL .

SQL ( Structured Query Language ) — Структурированный Язык Запросов — стандартный язык запросов по работе с реляционными БД. Работа была начата сразу после появления статью Э.Кодда в 1970г. в лабораториях компании IBM для проверки возможностей реляционной модели.

СУБД System R - экспериментальная исследовательская система с языком SEQUEL (позже SQL ), созданная IBM:

  1.  Полный реляционный язык БД
  2.  Операторы манипулирования БД
  3.  Средства определения и манипулирования схемой БД
  4.  Определение ограничений целостности
  5.  Определение представлений
  6.  Определение индексов
  7.  Авторизация доступа к отношениям и их полям
  8.  Точки сохранения транзакций и откаты

SQL в коммерческих реализациях:

1979 - Oracle (Relation Software Inc.- Oracle corp.;

1981-1982 - DB2 (IBM), Ingres - CA-OpenIngres (Relation Technology Inc. - Computer Associates)

1984 - Informix (Informix Sofrware);

1986 - Sybase (Sybase Corp.)

 Реализован во всех коммерческих реляционных СУБД

Все фирмы провозглашают соответствие стандарту SQL

Реализованные диалекты очень близки

Путь "сверху вниз" - уточнение и упрощение SQL System R

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

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

Достоинства и недостатки SQL

Достоинства:

  1.  Повсеместная распространенность
  2.  Быстрое обучение в простых случаях
  3.  Связывание с различными языками программирования
  4.  Поддержка ODBC и JDBC
  5.  Фактор времени: научились хорошо реализовывать.

Недостатки:

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

  1.  Структура языка SQL.

В отличие от реляционной алгебры, где были представлены только операции запросов к БД, SQL является полным языком, в нем присутствуют не только операции запросов, но и операторы, соответствующие DDLData Definition Language — языку описания данных. Кроме того, язык содержит операторы, предназначенные для управления (администрирования) БД.

 SQL содержит разделы, представленные в таблице 1:

Таблица 1. Операторы определения данных DDL 

Оператор

Смысл

Действие

CREATE TABLE

Создать таблицу

Создает новую таблицу в БД

DROP TABLE

Удалить таблицу

Удаляет таблицу из БД

ALTER TABLE

Изменить таблицу

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

CREATE VIEW

Создать представление

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

ALTER VIEW

Изменить представление

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

DROP VIEW

Удалить представление

Удаляет ранее созданное представление

CREATE INDEX

Создать индекс

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

DROP INDEX

Удалить индекс

Удаляет ранее созданный индекс

Таблица 2. Операторы манипулирования данными Data Manipulation Language  DMP )

Оператор

Смысл

Действие

DELETE

Удалить строки

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

INSERT

Вставить строку

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

UPDATE

Обновить строку

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

Таблица 3. Язык запросов Data Query Language (DQL)

Оператор

Смысл

Действие

SELECT

Выбрать строки

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

Таблица 4. Средства управления транзакциями

Оператор

Смысл

Действие

COMMIT

Завершить транзакцию

Завершить комплексную взаимосвязанную обработку информации, объединенную в транзакцию

ROLLBACK

Откатить транзакцию

Отменить изменения, проведенные в ходе выполнения транзакции

SAVEPOINT

Сохранить промежуточную точку выполнения транзакции

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

Таблица 5. Средства администрирования данных

Оператор

Смысл

Действие

ALTER DATABASE

Изменить БД

Изменить набор основных объектов в базе данных, ограничений, касающихся все!) базы данных

ALTER DBAREA

Изменить область хранения БД

Изменить ранее созданную область хранения

ALTER PASSWORD

Изменить пароль

Изменить пароль для всей базы данных

CREATE DATABASE

Создать БД

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

CREATE DBAREA

Создать область хранения

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

DROP DATABASE

Удалить БД

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

DROP DBAREA

Удалить область хранения БД

Удалить существующую область хранения (если в ней на настоящий момент не располагаются активные данные)

GRANT

Предоставить права

Предоставить права доступа на ряд действий над некоторым объектом БД

REVOKE

Лишить прав

Лишить прав доступа к некоторому объекту или некоторым действиям над объектом

Таблица 6. Программный SQL 

Оператор

Смысл

Действие

DECLARE

Определяет курсор для запроса

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

OPEN

Открыть курсор

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

FETCH

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

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

CLOSE

Закрыть курсор

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

PREPARE

Подготовить оператор SQL к динамическому выполнению

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

EXECUTE

Выполнить оператор SQL, ранее подготовленный к динамическому выполнению

Выполняет ранее подготовленный план запроса

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

  1.  Типы данных SQL.

В языке SQL /89 поддерживаются следующие типы данных:

  1.  CHARACTER ( n ) или CHAR ( n ) — символьные строки постоянной длины в п символов. При задании данного типа под каждое значение всегда отво дится п символов, и если реальное значение занимает менее, чем п символов, то СУБД автоматически дополняет недостающие символы пробелами.
  2.  NUMERIC [( n , m )] — точные числа, здесь п — общее количество цифр в числе, m — количество цифр слева от десятичной точки.
  3.  DECIMAL [( n , m )] — точные числа, здесь п — общее количество цифр в числе, m — количество цифр слева от десятичной точки.
  4.  DEC [( n , m )] - то же, что и DECIMAL [( n , m )].
  5.  INTEGER или INT — целые числа.
  6.  SMALLINT — целые числа меньшего диапазона.

Несмотря на то, что в стандарте SQL 1 не определяется точно, что подразумевается под типом INT и SMALLINT (это отдано на откуп реализации), указано только соотношение между этими типами данных, в большинстве реализаций тип данных INTEGER соответствует целым числам, хранимым в четырех байтах, a SMALLINT — соответствует целым числам, хранимым в двух байтах. Вы бор одного из этих типов определяется размером числа.

  1.  FLOAT [( n )] — числа большой точности, хранимые в форме с плавающей точкой. Здесь п — число байтов, резервируемое под хранение одного числа. Диа пазон чисел определяется конкретной реализацией.
  2.  REAL — вещественный тип чисел, который соответствует числам с плавающей точкой, меньшей точности, чем FLOAT.
  3.  DOUBLE PRECISION специфицирует тип данных с определенной в реализации точностью большей, чем определенная в реализации точность для REAL.

В стандарте SQL 92 добавлены следующие типы данных:

  1.  VARCHAR ( n ) — строки символов переменной длины.
  2.  NCHAR ( N ) — строки локализованных символов постоянной длины.
  3.  NCHAR VARYING ( n ) — строки локализованных символов переменной длины.
  4.  BIT ( n ) — строка битов постоянной длины.
  5.  BIT VARYING ( n ) — строка битов переменной длины.
  6.  DATE — календарная дата.
  7.  ТIМЕSТАМР(точность) — дата и время.
  8.  INTERVAL — временной интервал.

Большинство коммерческих СУБД поддерживают еще дополнительные типы данных, которые не специфицированы в стандарте. Так, например, практически все СУБД в том или ином виде поддерживают тип данных для представления не структурированного текста большого объёма. Этот тип аналогичен типу MEMO в настольных СУБД. Называются эти типы поразному, например в ORACLE этот тип называется LONG , в DB 2 - LONG VARCHAR , в SYBASE и MS SQL Server - TEXT.

Однако следует отметить, что специфика реализации отдельных типов данных серьезным образом влияет на результаты запросов к БД. Особенно это касается реализации типов данных DATE и ТШЁЗТАМР. Поэтому при переносе прило жений будьте внимательны, на разных платформах они могут работать по разному, и одной из причин может быть различие в интерпретации типов данных.

  1.  Системный анализ предметной области.

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

В общем случае существуют два подхода к выбору состава и структуры предметной области:

  1.  Функциональный подход — он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая БД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.
  2.  Предметный подход — когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и весьма динамичными. Мы не можем точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач.

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

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

  1.  Инфологическая модель данных. "Сущность-связь". Основные понятия.

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

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

Модель «сущность—связь»

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

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

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

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

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

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

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Квартира может пустовать, в ней может жить один или несколько жильцов.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

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

  1.  множество связей между одними и теми же сущностями

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

  1.  тренарные связи

(врач может назначить несколько пациентов на несколько анализов, анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами);

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

  1.  Классификация сущностей.

К.Дейт [3] определяет три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей – обозначения.

 Стержневая сущность (стержень) – это независимая.

 Ассоциативная сущность (ассоциация) – это связь вида "многие-ко-многим" ("-ко-многим" и т.д.) между двумя или более сущностями или экземплярами сущности (как в примере 2.4). Ассоциации рассматриваются как полноправные сущности:

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

  Характеристическая сущность (характеристика) – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что сущности реального мира имеют иногда многозначные свойства. Муж может иметь несколько жен (пример 2.3), книга – несколько характеристик переиздания (исправленное, дополненное, переработанное, ...) и т.д.

 Обозначающая сущность или обозначение – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями и отличается от характеристики тем, что не зависит от обозначаемой сущности.

  1.  Элементы расширенного языка ER-диаграмм.

Наиболее распространенным средством моделирования данных являются диаграммы ERD (диаграммы «сущность-связь»), нотация которых была впервые введена Питером Ченом в 1976 г. Базовыми понятиями ERD являются:

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

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

Атрибут (Attribute) - любая характеристика сущности.

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

Связь (Relationship) - поименованная ассоциация между двумя сущностями, при которой каждый экземпляр одной сущности (сущности-родителя) ассоциирован с произвольным количеством экземпляров второй сущности (сущности-потомка).

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

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

  1.  Даталогическое проектирование.

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

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

  1.  Описание концептуальной схемы БД в терминах выбранной СУБД.
  2.  Описание внешних моделей в терминах выбранной СУБД.
  3.  Описание декларативных правил поддержки целостности базы данных.
  4.  Разработка процедур поддержки семантической целостности базы данных.

Проектирование схемы БД может быть выполнено двумя путями:

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

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

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

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

  1.  Нормализация данных.

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

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

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

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

  1.  Нормальные формы.

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

  1.  первая нормальная форма (1NF);
  2.  вторая нормальная форма (2NF);
  3.  третья нормальная форма (3NF);
  4.  нормальная форма Бойса— Кодда (BCNF);
  5.  четвертая нормальная форма (4NF);
  6.  пятая нормальная форма, или форма проекции-соединения (5NF или PJNF).

Основные свойства нормальных форм:

  1.  каждая следующая нормальная форма в некотором смысле улучшает свойства предыдущей;
  2.  при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

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

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

Отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей.

Отношение находится в нормальной форме Болса—Кодла, если оно находится в третьей нормальной форме и каждый детерминант отношения является возможным ключом отношения.

  1.  Архитектура "клиент-сервер" в технологии баз данных.

Основной принцип технологии «клиент—сервер» применительно к технологии

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

приложения на 5 групп, имеющих различную природу:

  1.  функции ввода и отображения данных .(Presentation Logic);
  2.  прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);
  3.  функции обработки данных внутри приложения (Database Logic);
  4.  функции управления информационными ресурсами (Database Manager System);
  5.  служебные функции, играющие роль связок между функциями первых четырех групп.

 

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

  1.  формирование экранных изображений;
  2.  чтение и запись в экранные формы информации;
  3.  управление экраном;
  4.  обработка движений мыши и нажатие клавиш клавиатуры.

Бизнес-логика, или логика собственно приложений (Business processing Logic), - это часть кода приложения, которая определяет собственно алгоритмы решения конкретных задач приложения. Обычно этот код пишется с использованием различных языков программирования, таких как С, C++, Cobol, SmallTalk, VisualBasic.

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

Процессор управления данными (Database Manager System Processing) — это собственно СУБД, которая обеспечивает хранение и управление базами данных.

  1.  Модели серверов баз данных.

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

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

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

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

Рис. 10.8.  Взаимодействие пользовательских и клиентских процессов в модели "один-к-одному"

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

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

Проблемы, возникающие в модели "один-к-одному", решаются в архитектуре "систем с выделенным сервером", который способен обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами (рис. 10.9). Логически каждый клиент связан с сервером отдельной нитью ("thread"), или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой односерверной ("multi-threaded").

Она позволяет значительно уменьшить нагрузку на операционную систему, возникающую при работе большого числа пользователей ("trashing").

Рис. 10.9.  Многопотоковая односерверная архитектура

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

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

В некоторых системах эта проблема решается вводом промежуточного диспетчера. Подобная архитектура называется архитектурой виртуального сервера ("vir-tual server") (рис. 10.10).

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

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

Рис. 10.10. Архитектура с виртуальным сервером

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

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

Рис.10.11. Многопотоковая мультисерверная архитектура

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

  1.  Модели транзакций. Свойства транзакций.

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

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

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

  1.  структура транзакции
  2.  параллельность внутри транзакции
  3.  продолжительность

Типы транзакций:

  1.  Плоские (классические)
  2.  Цепочечные.
  3.  Вложенные.

Плоские транзакции характеризуются 4 классическими свойствами:

  1.  атомарность;
  2.  согласованность;
  3.  изолированность;
  4.  долговечность (прочность).

Иногда данные транзакции называются ACID-транзакциями. 
ACID - Atomicity, Consistency, Isolation, Durability. 
Упомянутые выше свойства означают следующее: 
Атомарность - выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе. 
Согласованность - гарантирует, что по мере выполнения транзакций, данные переходят из одного согласованного состояния в другое, т.е. транзакция не разрушает взаимной согласованности данных. 
Изолированность - означает, что конкурирующие за доступ к БД транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно. 
Долговечность - если транзакция завершена успешно, то те изменения, в данных, которые были ею произведены, не могут быть потеряны ни при каких обстоятельствах. 

  1.  Журнал транзакций.

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

  1.  Результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии БД.
  2.  Результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии БД.

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

  1.  Индивидуальный откат транзакции. Должен быть применен в следующих случаях:
  2.  оператор ROLLBACK;
  3.  аварийное завершение программы;
  4.  принудительный откат транзакции в случае взаимной блокировки при параллельном выполнении транзакций. Для выхода из тупика данная транзакция может быть выбрана в качестве "жертвы" и принудительно прекращено ее выполнение ядром СУБД.
  5.  восстановление после внезапной потери содержимого ОП (мягкий сбой). Случаи:
  6.  при аварийном выключении электропитания;
  7.  при возникновении неустранимого сбоя процессора. Такая ситуация характеризуется потерей той части БД, которая к моменту сбоя содержалась в буферах ОП.
  8.  восстановление после поломки основного внешнего носителя БД (жесткий сбой).
    Происходит очень редко, но тем не менее СУБД должна быть в состоянии восстановить базу данных даже в этом случае. Основой восстановления является архивная копия и журнал изменений БД.

Возможны два основных варианта ведения журнальной информации:

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

Достоинства:

  1.  Позволяет выполнять индивидуальные откаты транзакций.

Недостатки:

  1.  Приводит к дублированию информации в локальном и общем журналах, => лучше использовать второй вариант.
  2.  Журнализация и буферизация транзакций.

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

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

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

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

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

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

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

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

  1.  Параллельное выполнение транзакций.

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

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

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

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

Пример. Перевод денежных средств между счетами А, В, С. Две транзакции.

T1: read (A); A:=A-10; write(A); read(B); B:=B+10; write (B);

T2: read (B); B:=B-20; write(B); read(C); C:=C+20; write (C);

Корректность работы заключается в сохранении постоянного значения суммой А+В+С.

  1.  Хранимые процедуры.

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

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

CALL процедура(…)   Или  EXECUTE процедура(…)

Сохраняемые процедуры могут возвращать множества результатов, то есть результаты запроса SELECT. Такие множества результатов могут обрабатываться, используя курсоры, другими сохраненными процедурами, возвращая указатель результирующего множества, либо же приложениями. Сохраняемые процедуры могут также содержать объявленные переменные для обработки данных и курсоров, которые позволяют организовать цикл по нескольким строкам в таблице. Стандарт SQL предоставляет для работы выражения IF, LOOP, REPEAT, CASE и многие другие. Сохраняемые процедуры могут принимать переменные, возвращать результаты или изменять переменные и возвращать их, в зависимости от того, где переменная объявлена.

Реализация сохраняемых процедур варьируется от одной СУБД к другой. Большинство крупных поставщиков баз данных поддерживают их в той или иной форме. В зависимости от СУБД, сохраняемые процедуры могут быть реализованы на различных языках программирования, таких, как SQL, Java, C или C++. Сохраняемые процедуры написанные не на SQL могут самостоятельно выполнять SQL-запросы, а могут и не выполнять. Все более широкое использование сохраняемых процедур привело к появлению процедурных элементов в языке SQL стандарта SQL:1999 и SQL: 2003 в части SQL/PSM. Это сделало SQL императивным языком программирования. Большинство СУБД предлагают собственные проприетарные и расширения производителя, сверх SQL/PSM.

  1.  Встроенный SQL.

Язык SQL используется для доступа к базам данных не только в интерактивном режиме, но и в прикладных программах. В следующих трех главах описываются особенности программного SQL. В главе 17 рассматривается встроенный SQL — разновидность программного SQL, наиболее широко применяемая в реляционных СУБД. В главе 18 описывается динамический SQL — Усовершенствованная форма встроенного SQL; с его помощью создаются утилиты общего назначения для работы с базами Данных. И наконец, в главе 19 рассматривается альтернативная Разновидность программного SQL— интерфейс вызовов функций, применяемый в нескольких популярных СУБД. 
Язык SQL можно использовать для доступа к базам данных в двух режимах, прц интерактивной работе и в прикладных программах. По большей части сам язык одинаков в обоих вариантах. Эта двойственность SQL имеет несколько преимуществ. 
программисты могут относительно легко научиться писать программы, которые в ходе своей работы обращаются к базам данных; 
все возможности, доступные в интерактивном языке запросов, автоматически доступны и в прикладных программах; 
инструкции SQL, предназначенные для использования в программах, вначале могут быть проверены в интерактивном режиме, а затем вставлены в исходный 
I     текст программы; 
?    программы могут работать с базами данных на уровне таблиц и результатов запросов. 


 

А также другие работы, которые могут Вас заинтересовать

75057. Особенности почв участка Кожуховского затона 334 KB
  Существенным и неотъемлемым качеством почвы является её плодородие. Плодородие почвы называют её способность обеспечивать растения необходимым количеством питательных элементов воды и воздуха.
75058. Абак. Реконструкция римского абака 348 KB
  Первыми приспособлениями для вычислений были вероятно всем известные счётные палочки которые и сегодня используются в начальных классах многих школ для обучения счёту. Абак - счётная доска применявшаяся для арифметических вычислений приблизительно с IV века до н.
75059. Инновации и информационные технологии в образовании 873.89 KB
  Одаренность –- системное развивающееся в течение жизни качество психики которое определяет возможность достижения человеком более высоких результатов в одном или нескольких видах деятельности по сравнению с другими людьми.
75060. Виды транспорта 169 KB
  Основная часть История транспорта; Виды транспорта; Что называют транспортом Для чего нужен транспорт. Потом появились первые сельскохозяйственные орудия первое колесо различные транспортные средства.
75062. ЛИПЕЦКАЯ ЗЕМЛЯ НА СЛУЖБЕ ОТЕЧЕСТВУ 78 KB
  Два века отделяют нашу современность от великой победы русского народа в Отечественной войне 1812 года, но это нисколько не умаляет ее огромного значения для истории России. Борьба с иноземными захватчиками пробудила тогда в народе высокие чувства любви к Родине, истинного патриотизма, гордости и чести, народного единения.
75063. Роль казачества в истории становления и развитие Амурских земель 191.5 KB
  Прошло уже триста с лишним лет, как здесь впервые ступила нога русского человека. Первый отважный землепроходец, завидев здешние места, никем не занятые и никем ещё не освоенные, сразу же сердцем прикипел к ним. А кто этот отважный землепроходец? – задаюсь я вопросом каждый раз.
75064. ПЕРЕПЕЛИННОЕ ЧУДО 201.5 KB
  Известно, что перепелиные яйца –- экологически чистый продукт. В древние времена яйца и мясо перепелов использовались в восточной народной медицине. Яйца перепелов очищают кровь нормализуют давление повышают гемоглобин.