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

Обновлено: 30.06.2024

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

По модели данных классифицировать СУБД можно следующим образом:

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

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

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

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

Следуя спецификации CODASYL, сетевая модель поддерживает DDL (Data Definition Language - язык определения данных) и DML (Data Manipulation Language - язык обработки данных). Это специальные языки, предназначенные для определения структуры базы данных и составления запросов. Несмотря на их наличие программист по-прежнему должен знать структуру базы данных.

В сетевой модели допускаются отношения "многие ко многим", а записи не зависят друг от друга. При удалении записи удаляются и все ее связи, но не сами связанные записи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По способу доступа к БД:

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

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

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

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

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

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

Базовыми внутренними языками программирования являются языки четвертого поколения. В качестве базовых языков могут использоваться C, C++, Pascal, Object Pascal. Язык C++ позволяет строить программы на языке Visual Basic с широким спектром возможностей, более близком и понятном даже пользователю-непрофессионалу, и на непроцедурном (декларативном) языке структурированных запросов SQL. Следует отметить, что исторически для системы управления базой данных сложились три языка:

язык описания данных (ЯОД), называемый также языком описания схем, - для построения структуры ("шапки") таблиц БД;

язык манипулирования данными (ЯМД) - для заполнения БД данными и операций обновления (запись, удаление, модификация);

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

В настоящее время функции всех трех языков выполняет язык SQL, относящийся к классу языков, базирующихся на исчислении кортежей(кортеж чаще всего является единицей информации), языки СУБД FoxPro, Visual Basic for Application (СУБД Access) и так далее.

Вместе с тем сохранились и языки запросов, например язык запросов по примеру Query By Example (QBE) класса исчисления доменов. Отметим, что эти языки в качестве "информационной единицы" БД используют отдельную запись. С помощью языков БД создаются приложения, базы данных и интерфейс пользователя, включающий экранные формы, меню, отчеты. При создании БД на базе СУБД FoxPro эти элементы (объекты) фиксируются в отдельных файлах, которые, в свою очередь, сосредоточиваются в одном файле, называемом проектом. После отработки БД проект преобразуется в приложение. В СУБД Access все созданные объекты размещаются в одном файле [4].

СУБД можно классифицировать по:

по модели данных;

по степени распределённости;

по способу доступа к БД;

по степени универсальности.

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

1)дать общую характеристику СУБД;

2)рассмотреть классификацию СУБД.

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

1.КЛАССИФИКАЦИЯ СУБД ПО МОДЕЛИ ДАННЫХ

СУБД по модели данных классифицируется на:

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

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

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

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

Иерархической базой данных является файловая система, состоящая из корневого каталога, в котором имеется иерархия подкаталогов и файлов.[3]

Сетевая СУБД - СУБД, построенная на основе сетевой модели данных.

К основным понятиям сетевой модели базы данных относятся: уровень, элемент (узел), связь.

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

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

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

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

Реляционная СУБД (или РСУБД) - система управления реляционными БД.

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

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

Каждый элемент таблицы является одним элементом данных;

Каждый столбец обладает своим уникальным именем;

Одинаковые строки в таблице отсутствуют;

Все столбцы в таблице однородные, то есть все элементы в столбце имеют одинаковый тип;

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

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

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

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

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

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

ObjectStore поддерживает транзакции (в данный момент времени может существовать только одна транзакция), допускает методы доступа: хеш-таблица для несортированных данных и B-дерево для сортированных, также возможно использование SQL [2].

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

Объектно-реляционными СУБД являются, например, широко известные Oracle Database, Informix, DB2, PostgreSQL [3].

2.КЛАССИФИКАЦИЯ СУБД ПО СТЕПЕНИ РАСПРЕДЕЛЁННОСТИ

СУБД классифицируются по степени распределённости на:

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

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

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

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

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

3.КЛАССИФИКАЦИЯ СУБД ПО СПОСОБУ ДОСТУПА К БД

СУБД классифицируются по способу доступа к БД на:

Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера.

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

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

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro [3].

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

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

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

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

Исторически локальные и файл-серверные СУБД предоставляли скриптовый язык, на котором пользователь мог писать прикладную программу. Так устроены Microsoft Access, FoxPro, Clipper, 1С: Бухгалтерия. Недостатком этого подхода была крайняя бедность результирующих программ, ограниченные средства отладки. И зачастую не существовало компактной среды исполнения, которую можно распространять вместе с программой; нужна программа - устанавливай весь пакет. С распространением динамической линковки и opensource-сообщества маятник качнулся в другую сторону: пусть программист пишет свою программу на том языке высокого уровня, на котором удобно. СУБД же будет подсоединена к программе и станет единым целым с ней [3].

4.КЛАССИФИКАЦИЯ СУБД ПО СТЕПЕНИ УНИВЕРСАЛЬНОСТИ

По степени универсальности СУБД делят на общего и специального назначения.

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

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

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

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

В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера. Недостатки: потенциально высокая загрузка локальной сети; затруднённость или невозможность централизованного управления; затруднённость или невозможность обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Применяются чаще всего в локальных приложениях, которые используют функции управления БД; в системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками на БД.
На данный момент файл-серверная технология считается устаревшей.
Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу. Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность.
Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.

Встраиваемая СУБД — СУБД, которая может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Физически встраиваемая СУБД чаще всего реализована в виде подключаемой библиотеки. Доступ к данным со стороны приложения может происходить через SQL либо через специальные программные интерфейсы.
Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.

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

· Иерархические
· Сетевые
· Реляционные
· Объектно-ориентированные
· Объектно-реляционные

Стоит запомнить два общих принципа построения "правильной базы данных". Во-первых, нужно постараться обеспечить целостность (правильность) и непротиворечивость данных в БД: физическую сохранность данных, предотвращение неверного использования данных (например, ввода недопустимых значений), контроль операций вставки, обновления и удаления данных, защиту от несанкционированного доступа и т.д. Во-вторых, надо поддерживать минимальную избыточность данных. Любой элемент данных должен храниться в базе в единственном экземпляре, чтобы не дублировались операции, производимые над ним.
За хранение данных в базе, их обработку и взаимодействие с прикладными программами отвечает отдельный класс программ - системы управления базами данных (например Op Base , MS Access, FoxPro, MS SQL Server, Oracle и другие). Они отличаются друг от друга функциональностью, производительностью, стоимостью и т.п., но, в принципе, все предназначены для решения вышеуказанных задач. Чтобы заставить СУБД правильно выполнять свои функции и сопровождать базу данных, необходимо организовать работу так, чтобы соблюдались оба принципа. Иначе придется в основном бороться с самой СУБД.
При построении "правильной базы данных" многое зависит от ее структуры, то есть схемы. Из каких таблиц и атрибутов должна состоять схема базы данных? Какие атрибуты выбрать в качестве ключевых? Надо ли связывать эти таблицы между собой? Подобные вопросы могут возникнуть у кого угодно, и чтобы ответить на них, требуется научиться моделировать схему базы данных. Для этого были придуманы специальные диаграммы "сущность-связь" (ER-диаграммы), которые позволяют легко и наглядно проектировать структуру баз данных без привязки к конкретным СУБД. Методика, согласно которой используются ER-диаграммы, оказалась настолько успешной и полезной на практике, что легла в основу целого класса программных продуктов, так называемых CASE-средств проектирования информационных систем. Наиболее распространенная программа этого класса – Erwin
Главная проблема, которую требуется решить при создании базы данных - создать для нее такую структуру, которая бы обеспечивала минимальное дублирование информации и упрощала процедуры обработки и обновления данных, представленных набором таблиц. Для решения этой проблемы был предложен универсальный способ. Этот способ сформулирован в виде специальных требований к организации данных в ходе проектирования, которые получили названия нормальных форм (НФ). Первые три нормальные формы оказались самыми живучими и распространились больше других.
Согласно требованиям первой нормальной формы, все атрибуты таблицы должны быть простыми, то есть состоять из одного неделимого элемента данных. Например, если сделать в базе данных атрибут "Адрес", то в него можно будет заносить значения данных типа "г. Москва, 3-я улица Строителей, д. 25, кв. 12". Но определить, из какого города человек с таким адресом и существует ли такой же адрес в другом городе будет очень сложно, потому что придется писать целую процедуру обработки текстовой записи, чтобы вычленить город.
Вторая нормальная форма требует соблюдения условий первой НФ, а также дополнительно каждый не ключевой атрибут должен однозначно зависеть только от первичного ключа. Имеются в виду функциональные зависимости из реальной предметной области. Здесь возникают проблемы с выявлением зависимостей, если первичный ключ является составным, то есть состоит из нескольких атрибутов.

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

$lec.docx.
Показать все связанные файлы Подборка по базе: ПР Архивация данных.docx, 03.11.2021 Деловые игры в экономике, Лекция.docx, Материаловедение. Лекция 2.doc, Практика1 Основы управления проектами (1) (1).pdf, Связнодисперсные системы. Образование кристаллизационно-конденса, Государственная и муниципальная собственность в РФ, ее значение , 10 лекция жауап Аманжолов Н..docx, Лекарство лекция 4.docx, Презентация Основные компоненты системы управления..pptx, №10 лекция_fa877a9d0cd3a23572333890cf2d140d.pdf

Лекция 2. Системы управления базами данных. Классификация СУБД

Классификация СУБД.

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

Классификация по виду программ. К СУБД относятся следующие основные виды программ: полнофункциональные СУБД; серверы БД; клиенты БД.

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

К ПФСУБД относятся: Clarion Database Developer, Data Ease, Dataplex, dBase IV, Microsoft Access, Microsoft FoxPro, Paradox R:BASE.

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

Примерами серверов БД являются следующие программы: NetWare SQL (Novell), MS SQL Server (Microsoft), InterBase (Borland), SQLBase Server (Gupta), Intelligent Database (Ingress).

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

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

Персональные СУБД обеспечивают возможность создания персональных БД и приложений, работающих с ними. Персональные СУБД или разработанные с их помощью приложения могут выступать в роли клиентской части многопользовательской СУБД. К персональным СУБД относятся Visual FoxPro, Paradox, dBase, Access и др.

Многопользовательские СУБД включают в себя сервер БД и клиентскую часть, могут работать в однородной и в неоднородной вычислительной среде (с разными типами ЭВМ и ОС). К многопользовательским СУБД относятся, например, СУБД Oracle и Informix.

Классификация по способу доступа к БД СУБД бывают: файл-серверные, клиент-серверные, встраиваемые.

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

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

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

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

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

Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.

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

Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.

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

Функции СУБД

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

управление данными во внешней памяти;
управление буферами оперативной памяти;
управление транзакциями;
журнализация и восстановление БД после сбоев;
поддержка языков БД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СУБД придерживаются стратегии «упреждающей» записи в журнал протокола WAL (Write Ahead Logging – «пиши сначала в журнал»). Она заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

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

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

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

Поддержка языков БД. Для работы с БД используются специальные языки, называемые языками БД. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Выделялись два языка – язык определения схемы БД (SDL – Schema Definition Language) и язык манипулирования данными (DML – Data Manipulation Language). SDL служил для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными (операторы ввода, удаления, модификации и выборки данных).

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

Язык SQL сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД – именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов.

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

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

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

Читайте также: