Главная страница
Навигация по странице:

  • Систе́ма управле́ния ба́зами да́нных (СУБД

  • Основные термины и определения

  • Лекция 1. Введение в клиент-серверные СУБД.

  • Архитектура клиент—сервер

  • Interbase SQL Server. Общие сведения .

  • Лекция 3. Триггеры и хранимые процедуры Хранимые процедуры

  • Лекции. Базы данных. База данных


    Скачать 356.07 Kb.
    НазваниеБазы данных. База данных
    АнкорЛекции.docx
    Дата12.03.2018
    Размер356.07 Kb.
    Формат файлаdocx
    Имя файлаЛекции.docx
    ТипДокументы
    #13996
    страница1 из 10
      1   2   3   4   5   6   7   8   9   10

    Введение.

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

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

    • данные, которые они используют, имеют сложную структуру

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

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

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

    Для дальнейшего обсуждения нам необходимо ввести понятие предметной области:

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

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

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

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

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

    Основные функции СУБД:

    • управление данными во внешней памяти (на дисках);

    • управление данными в оперативной памяти;

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

    • поддержание языков БД (язык определения данных, язык манипулирования данными).

    Обычно современная СУБД содержит следующие компоненты (см. рис.):

    • ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию,

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

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

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


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

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

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

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

    Второе направление – это хранение и обработка данных. Целью любой информационной системы является хранение и обработка данных о каких-либо объектах реального мира.

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

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

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

    В широком смысле слова термин «база данных» (БД) – это совокупность сведений о конкретных объектах.

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

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

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

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

    Интересно:

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

    Объём запущенной Yahoo в 2008 году базы данных достиг 2 петабайт. Система создана для аналитических целей, в ней хранится история поведения Web-пользователей (утверждается, что в месяц сохраняются данные о полумиллиарде пользователей). Помимо прочего, интернет-гигант заявляет, что это не только самая большая БД в мире, но ещё и самая нагруженная — в сутки в ней регистрируются данные о 24 млрд событиях.

    Управлением базами данных занимается модифицированная версия СУБД PostgreSQL. Это стало возможным благодаря покупке Yahoo компании-стартапа Mahat Technologies, изначально работающей с PostgreSQL. Код свободной СУБД был модифицирован для работы с такими огромными объемами информации (одно из самых крупных изменений: ориентация на поколоночное хранение вместо традиционного построчного, что замедляет запись на диск, но обеспечивает лучшую скорость доступа к данным для аналитических целей). Положительный результат налицо: некоторые таблицы в базе содержат триллионы строк, которые не просто лежат мертвым грузом на дисках, но могут быть запрошены и обработаны стандартным SQL, в стандартной ACID-совместимой среде.

    2) Каждый гражданин Исландии имеет доступ к сайту Íslendingabók — генеалогической базе данных, содержащей информацию о родственных связях всех исландцев начиная с 18 века. Задача составления такой базы смогла быть решена благодаря не очень большому населению государства (чуть более 300 тысяч) и тому, что Исландия на протяжении своей истории была слабо подвержена влиянию как эмиграции, так и иммиграции. Многие молодые люди используют этот сайт для проверки, не является ли им новый возлюбленный кузеном или кузиной, чтобы исключить вероятность инцеста. Другое популярное применение сайта — проверка степени своего родства с известными личностями.

    Лекция 1. Введение в клиент-серверные СУБД.

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

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

    Результаты прогресса привела к тому, что на рынке уверенно возобладали реляционные СУБД, и произошло сближение функциональности ряда лидирующих клиент-серверных систем (Oracle, MS SQL, Sybase, DB2, Interbase, Progress). Цены на эти системы заметно снизились (в разы).

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

    Рис 1. Архитектура клиент—сервер

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

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

    • увеличение производительности за счет того, что сам сервер может эффективно кэшировать данные;

    • перенос части функциональности на сервер с уменьшением трафика и увеличением производительности (хранимые процедуры, триггера);

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

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

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

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

    В 1992 г. был принят новый стандарт SQL-92. Этот язык существенно более сложен, чем SQL-89, а конструкции SQL-92 специфицированы в стандарте существенно более полно. Первой компанией, которая объявила о соответствии своего продукта новому стандарту, была компания Oracle со своей седьмой версией (это произошло прямо в 1992 г.).

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

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

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

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

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

    • местами не совпадает даже синтаксис SQL - в части, например, внешних соединений таблиц (outer join);

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

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

    Interbase SQL Server. Общие сведения.

    Одним из реляционных клиент-серверных СУБД является InterBase SQL Server фирмы Borland. Схематично архитектура клиент-сервер InterBase в ее типичной конфигурации изображена на рисунке 2.

    Компания Borland выпустила версию 6.0 OpenSource в июле 2000 года. В этот момент код Interbase был скопирован, и помещен там же, на sourceforge.net, но под названием Firebird.

    Собственно, Borland как владелец исходных текстов, не публикует собственных изменений, тем более для платных версий. Выпуск платных (сертифицированных) версий Interbase был возобновлен в марте 2001 года, и схема оплаты лицензий, а также контроль лицензий на сервере, остались теми же, что и в Interbase 5.x.

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


    Рис 2. Архитектура клиент—сервер InterBase

    Примерно в октябре 2001 года группа разработчиков из Санкт-Петербурга выпустила собственную версию под кодовым названием Yaffil, базирующуюся на исходном коде Firebird. Эта версия первоначально задумывалась как "исследовательская", с большим количеством параметров настройки и частями кода, оптимизированными и переведенными на ассемблер. В настоящее время Yaffil является полигоном для тестирования сервера, оптимизированного для работы на многопроцессорных компьютерах под Windows.

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

    В настоящее время последние версии InterBase 7 и FireBird 2 уже имеют существенные отличия, которые не позволяют производить миграцию базы. Декларируется, что семерка совместима только с InterBase 6.5, и рекомендуется проводить миграцию только через backup/restore.

    Interbase полностью совместим со стандартом ANSI SQL-92, а так же имеет собственное расширение SQL для хранимых процедур и триггеров. В сравнении со многими другими СУБД, InterBase предоставляет очень эффективный механизм триггеров: каждая таблица может иметь большое количество триггеров, которые выполняются автоматически при вставке, изменении или удалении каждой отдельной записи, до или после этих событий. Многие функции существующих СУБД были впервые реализованы в Interbase – это, в частности, обновляемые представления, события, многомерные массивы и BLOB-поля. Более того, некоторые механизмы, такие, например, как двухфазное подтверждение транзакций, до сих пор остаются уникальными, представленными только в Interbase.

    Подключение к базе может осуществляться как по сетевым протоколам (TCP/IP, NetBEUI, IPX/SPX), так и локально.

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

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

    Немаловажной особенностью сервера InterBase является возможность расширения стандартного набора SQL-функций при помощи пользовательских библиотек – User Defined Functions, а также механизмы обработки BLOB-полей на сервере с помощью BLOB-фильтров.

    Платформы


    Начиная с момента своего выхода, т.е. 1985 года, Interbase был Unix-ориентированным сервером баз данных. К моменту выхода 5.0 (1997 год) множество ранее поддерживаемых операционных систем (около 15) или прекратили свое существование, или стали экзотическими, поэтому основных портов осталось 6. К 2000 году их число уменьшилось до 3 - Windows, Solaris (SPARC), и Linux. Порты под NetWare, SCO и HP-UX были прекращены как неперспективные.

    Кроме уменьшения количества поддерживаемых вариантов ОС при выпуске Interbase 6.5 было решено отказаться от старой архитектуры Classic (пользователь-процесс) в пользу более современной - SuperServer (пользователь-thread).

    Firebird, как OpenSource СУБД, преследовала иные цели, а именно обеспечить работу на максимально различных платформах. Поэтому архитектура Classic была сохранена (как единственная, способная обеспечить масштабирование на многопроцессорных компьютерах под Unix), и в дополнение к основным платформам были выпущены дистрибутивы (готовые комплекты для установки) для FreeBSD, HP-UX, AIX, Solaris (Intel), и даже для Darwin (MacOS X). В настоящее время ведутся работы по портированию Firebird на WinCE (пока существует только клиентская часть Firebird для WinCE).

    Yaffil, как уже упоминалось выше, выпускается только для Windows, и сейчас находится в завершающей стадии тестирование Yaffil for Windows с архитектурой Classic (для работы на SMP-машинах).

    Типы приложений


    Конечно, самые разнообразные. Interbase давно уже распространен в нашей стране, и завоевал популярность в первую очередь у разработчиков, использующих инструментальные среды разработки Borland - Delphi, C++Builder, Jbuilder. В последнее время все больше разработчиков, использующих Visual C, MS Access и другие средства, также приходят к использованию Interbase. Это в первую очередь обусловлено появлением ряда качественных ODBC-драйверов, а также OLE-DB-провайдеров (в настоящее время их общее число около 12-ти), позволяющих тесно интегрировать работу Interbase и офисных систем.

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

    Такие системы как правило по объему хранимых данных не превышают 300-500 мегабайт, а также работают либо в однопользовательском, либо в многопользовательском режиме с количеством пользователей от 2 до 15-ти, и легко переносятся с компьютера на компьютер. Операционная система в данном случае чаще всего Windows 95 или 98. К сожалению, о надежности в этом случае серьезно говорить нельзя, однако такие требования обычно обусловлены финансовыми причинами, по которым пользователи приложений не могут установить Windows XP/2K из-за старых процессоров или небольшого количества оперативной памяти - 32 мегабайт RAM для подобных систем вполне достаточно даже при работе с невыделенным сервером до 15-20-ти пользователей.

    Более серьезные приложения, как то внутрикорпоративные системы, системы управления предприятием, биллинговые и т.п., разумеется работают с большими объемами данных (от 500 мегабайт до 8 гигабайт) и как правило используют Unix в качестве серверной ОС, и никогда не работают в однопользовательском режиме. При количестве пользователей до 50 на сервер обычно используют Windows, а в случаях до 300-400 пользователей - обязательно Unix (RedHat Linux или FreeBSD) и как правило на двух-, реже четырех-процессорных системах. В процентном отношении для данных систем в качестве операционной системы сервера Windows используется в 30% случаев, Unix - 70%.

    Classic и SuperServer


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

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

    Архитектуру SuperServer можно по аналогии охарактеризовать как "на всех клиентов - один сервер". Это означает, что все клиентские соединения обслуживаются одним серверным процессом, где каждым конкретным клиентом занимаются отдельные потоки (threads).

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

    Classic или SuperServer


    Следует заметить, картина складывается довольно интересная на каждый недостаток Classic у SuperServer находится достоинство. Classic расточителен - SuperServer экономен, Classic без Services API - у SuperServer он есть.

    Однако, как и везде, здесь мы имеем "палку о двух концах", т. е., определенные недостатки Classic переходят в определенных ситуациях в его достоинства, а преимущества SuperServer превращаются в недостатки. Например, рассмотрим случай. когда N нас имеется, скажем, мощный двухпроцессорный компьютер- сервер с большим количеством ОЗУ, например 2 Гбайт. Если мы установим на такую систему InterBase в варианте SuperServer, то будем наблюдать не ускорение, а замедление по сравнению с однопроцессорным вариантом того же сервера! Более того, с памятью будут твориться сплошные "недоразумения"- экономный SuperServer будет "отказываться" от огромного ОЗУ. пытаясь всячески сэкономить оперативную память. Как же так, мощные процессоры, много памяти, a InterBase SuperServer не очень-то быстро работает?

    Вот здесь и проявляются недостатки SuperServer. Проблему с масштабируемостью InterBase архитектуры SuperServer на многопроцессорных компьютерах давно признали в компании Borland. Дело в том, что ядро SuperServer не расчитано на использование нескольких процессоров. Сервер InterBase SuperServer не может управлять распределением потоков по процессорам. В результате ОС при нарастании нагрузки начинает перебрасывать главный серверный процесс (ibserver.exe) с одного процессора на другой. На это тратятся системные ресурсы и время, что замедляет работу InterBase. С такой ситуацией на многопроцессорных системах борются путем "привязки" (affinity) InterBase варианта SuperServer к одному определенному процессору и игнорирования остальных.

    Надо также отметить, что с распределением памяти у SuperServer тоже имеются некоторые проблемы. Если мы рассмотрим, как SuperServer обслуживает множество небольших клиентских запросов, то увидим довольно привлекательную картину: высокую производительность при относительно небольшом использовании оперативной и виртуальной памяти. Многочисленные клиентские запросы совместно (без дублирования) используют кешированную информацию SuperServer. Эта особенность делает вариант InterBase с архитектурой SuperServer особенно привлекательным для Web-приложений, ориентированных именно на такой стиль работы с базами данных. Так как запросы небольшие, то они быстро отрабатывают и освобождают память для следующих за ними запросов.

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

    Эти "тяжелые" запросы "проходятся" по большому количеству записей и требуют значительных ресурсов памяти и процессора для их выполнения. Мы пытаемся предусмотреть подобную ситуацию и используем мощное аппаратное обеспечение: высокопроизводительный компьютер-сервер с большим количеством ОЗУ. Однако, SuperServer "не понимает" нашей предусмотрительности и при выполнении "тяжелого" запроса пытается обращаться с ним как с небольшим, т. е. отдает ему доступную кеш-память и ресурсы, вытесняя при этом остальные запросы. Результат печален - пока выполняется запрос-тяжеловес, остальные запросы "топчутся в очереди". В связи с фактически последовательным обслуживанием потоков критическими участками кода ядра InterBase сервер просто не имеет другого выбора.

    Остается сказать о достоинствах Classic, проявляющихся в этой ситуации.

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

    Во-вторых, использование памяти и процессора при выполнении "тяжелых" запросов. Если мы запускаем какой-то очень интенсивно работающий с базой запрос, то он выполняется в рамках одного серверного процесса, обслуживающего данного клиента, не останавливая при этом остальные. Приоритет "тяжелого" запроса (фактически процесса) падает по мере увеличения времени использования им ресурсов процессора и он начинает "уступать дорогу" более приоритетным процессам других соединений, выполняющим короткие запросы, т. е. процессор занят на 90%, но на долю "долгожителя" приходится 80-70-60- 50-40 %... Он замедляет остальные, это заметно, но терпимо, и главное - у пользователя не возникает ощущения "подвешенности".

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

    Файлы базы данных InterBase


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

    База данных InterBase представляет собой один или несколько файлов, в которых находится информация обо всем, что связано с этой базой. Исключение составляет информация о пользователях, поскольку пользователи определяются на уровне всего сервера и хранятся отдельно, в системной базе данных ISC4.GDB(Security.fdb). Внутри файлов базы данных содержится вся информация о базе: сами данные, индексы, триггеры, хранимые процедуры и т. д.

    База данных InterBase для среднего проекта представляет собой один файл, так как ограничение в 32 Гбайта на размер одного файла базы данных позволяет держать все данные в одном файле (версии ниже InterBase 6.5, Firebird 1.0 и Yaffil 1.0 имеют ограничение в 2-4 Гбайт, в зависимости от ОС). 32 гигабайт вполне хватает для хранения информации приложения баз данных среднего размера. Но при необходимости можно разбить базу данных на несколько файлов. Известны базы данных InterBase размером в сотни гигабайт.

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

    Таблица 1. Размер страницы, поддерживаемый различными версиями

    Версия InterBase



    Размер страницы, байт

    1024

    2048

    4096

    8192

    16384

    InterBase 4

    *

    *

    *

    *



    InterBase 5.x

    *

    *

    *

    *



    InterBase 6.0x

    *

    *

    *

    *



    Firebird Ix/Yaffl 1.x /InterBase 6.5 и выше

    *

    *

    *

    *

    *


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

    Лекция 3. Триггеры и хранимые процедуры
    Хранимые процедуры и триггеры, о которых уже неоднократно упоминалось в предыдущих лекциях, являются одними из самых мощных средств InterBase для реализации бизнес-логики на стороне сервера. Использование этих инструментов приводит к:

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

    • повышению безопасности БД, снижению риска ошибок;

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

    • уменьшению и упрощению кода клиентских приложений, работающих с сервером InterBase.

    Хранимые процедуры, как и триггеры, типичны только для клиент-серверных баз данных. И те, и другие используют специальный алгоритмический язык. О триггерах мы поговорим на следующей лекции, а сейчас изучим хранимые процедуры и алгоритмический язык, общий и для триггеров, и для хранимых процедур.
      1   2   3   4   5   6   7   8   9   10
    написать администратору сайта