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

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

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

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

· Позволяет создать базу данных, что обычно осуществляется с помощью языка определения  данных (DDL — Data Definition Language). Язык DDL предоставляет пользователям средства указания типа данных и их структуры, а также средства задания ограничений для информации, хранимой в базе данных.

Типы данных в СУБД

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- date

- check number

- paid to

- amount

Каждый раз при появлении  в БД записи check, в базе запоминаются значения для каждого из полей. Определение записи (как заключающей в себе ее поля) называется типом записи (record type). Значение для соответствующего типа записи будем называть вхождением записи или просто записью. В языке C записям соответствуют структуры.

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

Ключом (key) называется поле, позволяющее осуществить наиболее быстрый доступ к записи или навигацию по отсортированным записям. В рассмотренной выше записи check можно определить как ключ поле check number, позволяющий быстро получить (найти и считать) вхождение записи check зная check number. Индексом (index) называется файл содержащий только ключи. Его так же называют ключевым файлом (key file).

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

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

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

Отношения между таблицами

Отношения между записями в таблицах делятся на три типа:

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

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

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