Андреева Е.Г. Базы данных - файл n1.doc

приобрести
Андреева Е.Г. Базы данных
скачать (129.8 kb.)
Доступные файлы (1):
n1.doc397kb.07.06.2005 20:21скачать

n1.doc

1   2   3

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

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

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

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

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

Типичные операции в сетевой модели:

– найти следующую запись данного типа и сделать ее текущей;

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

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

– заполнить запись из буфера в БД.

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

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

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

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

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

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

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

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

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

Первоначально понятие модели данных употреблялось как синоним структуры данных конкретной БД. Однако в конце 60-х, в начале 70-х годов появились системы многоуровневой архитектуры, основанные на концепции многоуровневого представления данных.

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

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


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

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

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

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

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

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

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

Для управляемого архитектурного уровня степень его управляемости может быть различной. В некоторых СУБД внешние интерфейсы предоставляют только возможность определения данных, не обеспечивая доступ к средствам манипулирования данными, например, в СУБД типа CODASYL. В других случаях, напротив, имеются возможности манипулирования данными, но не предоставляются средства определения данных, например, интерфейс языка ADASCRIPT в СУБД ADABAS. Но существуют и случаи полной управляемости. Такими возможностями обладают интерфейсы языка SQL в СУБД DBR, в ряде СУБД для ПК.

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

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

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

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

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

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

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

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

Упрощенная схема системы базы данных представлена на рис. 2.

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

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

Прикладные

программы


Рис. 2
Однопользовательская система (single-user system) – это система, в которой в одно и то же время к базе может получить доступ не более одного пользователя.

Многопользовательская система (multi-user system) – это система, в которой к базе данных могут получить доступ сразу несколько пользователей.

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

Данные в БД могут быть интегрированными и общими (разрешенными к общему доступу).

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

Например, БД содержит два файла:


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

К аппаратному обеспечению системы БД относятся:

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

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

Между физической базой данных (данными, которые сохранены на диске) и пользователями системы располагается уровень программного обеспечения – диспетчер базы данных или система управления базами данных, СУБД (database management system, DBMS). Все запросы пользователей на доступ к базе данных обрабатываются СУБД, добавление файлов или таблиц, выборку и обновление данных в них также обеспечивает СУБД. Основная функция СУБД – это предоставление пользователю базы данных возможности работать в ней, не вникая в детали на уровне аппаратного обеспечения. СУБД позволяет пользователю рассматривать БД как объект более высокого уровня по сравнению с аппаратным обеспечением, а также поддерживает выражаемые в терминах высокого уровня пользовательские операции (например, на языке SQL).

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

Пользователи

Пользователей можно разделить на три большие группы.

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

2. Конечные пользователи работают с системами баз данных через рабочую станцию или терминал. Конечный пользователь может получить доступ к базе данных, используя одно из оперативных приложений или воспользоваться интегрированным интерфейсом программного обеспечения самой системы баз данных. Такой интерфейс также поддерживается оперативным приложением, но это приложение не создается пользователем, оно является встроенным в систему БД. В большинстве систем есть хотя бы одно такое встроенное приложение, а именно: процессор языка запросов, с помощью которого пользователь указывает команды или выражения высокого уровня для данной СУБД. Язык SQL – типичный пример языка запросов баз данных. (В данном случае «запрос» – это не только выборка данных, но и операции обновления, вставки и удаления).

Кроме языка запросов, в большинстве систем также предоставляются дополнительные встроенные интерфейсы, в которых пользователь в явном виде не использует команды. Эти встроенные интерфейсы представляют собой команды меню и поля в формах. Язык запросов – это командный интерфейс.

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

1) принимать решение, какие данные необходимо вносить в БД в первую очередь;

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

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

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

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

  1. в создании самих баз данных;

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

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

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

База данных оперирует так называемыми «постоянными» и «транзитными» данными. Транзитные данные – это промежуточные результаты, входные и выходные данные, рабочие очереди. Постоянные данные – это не транзитные данные, т. е. они не так сильно меняются как транзитные. Различие между постоянными и транзитными данными не является четким. Например, для предприятия постоянные данные – это данные о продукции, о счетах, о клиентах, данные планирования.

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

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

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

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

Компактность. Нет необходимости в многотомных бумажных карто- теках.

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

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

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

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

Почти все продукты баз данных, созданные с конца 70-х годов, основаны на подходе, который называют реляционным (relational). Большинство научных исследований в области баз данных в течение последних 25 лет проводилось в этом направлении. На самом деле, реляционный подход представляет собой основную тенденцию сегодняшнего рынка, и реляционная модель – единственная существенная разработка в истории развития баз данных.

Реляционная система – это система, основанная на следующих принципах:

1) данные для пользователя передаются в виде таблиц ;

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

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

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

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

Примеры коммерческих продуктов, которые можно отнести к перечисленным категориям.

Системы инвертированных списков: CA-DATACOM/DB компании Computer Associates International Inc. (ранее был известен как DATACOM/DB компании Applied Data Research).

Иерархические системы: IMS корпорации IBM.

Сетевые: CA-IDMS/DB компании Computer Associates International Inc. (ранее был известен как IDMS компании Cullinet Software Inc.).

Первые реляционные продукты начали появляться в конце 1970-х— начале 1980-х годов. Существует, возможно, более 200 коммерческих реляционных продуктов, предназначенных для работы с любым программным и аппаратным обеспечением. Среди них DB2 корпорации IBM; Rdb/VMS корпорации Digital Equipment; ORACLE корпорации Oracle; INGRES компании Ingres Division of The ASK Group Inc.; SYBASE компании Sybase Inc. и многие другие.

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

– Дедуктивные СУБД.

– Экспертные СУБД.

– Расширяемые СУБД.

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

– Семантические СУБД.

– Универсальные реляционные СУБД.
Архитектура системы баз данных

Архитектура ANSI/SPARC включает три уровня: внутренний, концептуальный и внешний.

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

Внешний уровень наиболее близок к пользователям, т.е. он связан со

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

Концептуальный уровень – это «промежуточный» уровень между двумя первыми.

Если внешний уровень связан с индивидуальными представлениями пользователей, то концептуальный уровень связан с обобщенным представлением пользователей.
Архитектура клиент/сервер

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

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

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

Исключениями являются специальные «служебные» приложения (утилиты). Такие приложения иногда могут работать только непосредствен­но на внутреннем уровне системы. Утилиты скорее относятся к непосредствен­ным компонентам СУБД, чем к приложениям в обычном смысле.



Рис. 3
Приложения делятся на несколько определенных категорий.

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

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

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

– процессоры языков запросов;

– генераторы отчетов;

– графические бизнес-подсистемы;

– электронные таблицы;

– процессоры обычных языков;

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

– генераторы приложений;

– другие средства разработки приложений, включая CASE-продукты (CASE или Computer-Aided Software Engineering – автоматизация разработки программного обеспечения), и т. д.

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

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

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

Примеры типов утилит, которые часто приме­няются на практике, приводятся ниже.

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

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

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

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

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

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

Распределенная обработка

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

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


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

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

– Машина сервера может быть изготовлена по специальному заказу, приспособлена для работы с СУБД («машина базы данных») и может обеспечить лучшую производи­тельность СУБД.

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

– Несколько разных машин клиентов могут иметь доступ к одной и той же машине сер­вера. Поэтому одна база данных может совместно использоваться несколькими от­дельными клиентскими системами (рис. 5).


Рис. 5
Можно добавить еще одно преимущество выполнения сервера и клиента на отдельных машинах – соответствие практической работе многих предприятий. Это довольно распространенный способ для отдельного предприятия. Например, банк ра­ботает со многими компьютерами, сохраняющими данные для одной части предприятия на одном компьютере, а данные для другой части – на другом. Это также очень распростра­нено среди пользователей, которым необходим доступ с одного компьютера к данным, хранимым на другом компьютере. Следовательно, машины клиентов могут иметь свои собственные сохраняемые данные, а машина сервера может иметь свои собственные приложения. Поэтому каждая машина может выступать в роли сервера для одних пользователей и в роли клиента для других (рис. 6); иными словами, каждая машина будет поддерживать полную систему баз данных.

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

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



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

Другой пример системы БД обычно называют распределенной системой баз данных. Для рас­пределенных баз данных отдельное приложение может «прозрачно» обра­батывать данные, распределенные на множестве различных баз данных, управление ко­торыми осуществляют разные СУБД, работающие на многочисленных машинах с различными операционными системами, соединенных вместе коммуникационными сетями. Понятие «прозрачный» означает, что приложение выполняет обработку данных с логической точки зрения, как будто управление данными полностью осуществляется одной СУБД, работающей на отдельной машине.
1   2   3


Модели данных
Учебный материал
© nashaucheba.ru
При копировании укажите ссылку.
обратиться к администрации