18. Классификация баз данных. Модель представления данных.

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

Виды баз данных

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

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

Примеры:

Иерархическая

Объектная и объектно-ориентированная

Объектно-реляционная

Реляционная

Сетевая

Функциональная.

Классификация по среде постоянного хранения

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

В оперативной памяти: все данные на стадии исполнения находятся в оперативной памяти.

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

Классификация по содержимому

Примеры:

Географическая

Историческая

Научная

Мультимедийная

Клиентская.

Классификация по степени распределённости

Централизованная, или сосредоточенная (англ. centralized database): БД, полностью поддерживаемая на одном компьютере.

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

Неоднородная (англ. heterogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами более одной СУБД

Однородная (англ. homogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами одной и той же СУБД.

Фрагментированная, или секционированная (англ. partitioned database): методом распределения данных является фрагментирование (партиционирование, секционирование), вертикальное или горизонтальное.

Тиражированная (англ. replicated database): методом распределения данных является тиражирование (репликация).

Другие виды БД

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

Временная, или темпоральная (англ. temporal database): БД, в которой поддерживается какой-либо аспект времени, не считая времени, определяемого пользователем.

Пространственно-временная (англ. spatial-temporal database) БД: БД, в которой одновременно поддерживается одно или более измерений в аспектах как пространства, так и времени.

Циклическая (англ. round-robin database): БД, объём хранимых данных которой не меняется со временем, поскольку в процессе сохранения данных одни и те же записи используются циклически.

Сверхбольшие базы данных

Сверхбольшая база данных (англ. Very Large Database, VLDB) — это база данных, которая занимает чрезвычайно большой объём на устройстве физического хранения. Термин подразумевает максимально возможные объёмы БД, которые определяются последними достижениями в технологиях физического хранения данных и в технологиях программного оперирования данными.

Модель- совокупность структур данных и операций их обработки. Выбор той или другой модели происходит после получения всей информации о предметной области, ее описаний и детализации. Перед началом моделирования в собранной информации выделяются объекты, их характеристики и связи между ними. Для выбора конкретной модели первоначально предметную область желательно оценить с т.з. прямого моделирования понятий, т.е. оценивается возможность определения выделенных объектов в терминах и структурах выбранной модели данных.Кроме возможности прямого моделирования оцениваются следующие свойства модели данных:1. сложность модели для изучения пользователем; 2. наглядность; 3. сложность и трудоемкость написания программ для манипулирования структурами данных; 4. соблюдение правил композиции; 5. оптимальное число базисных структур и т.д.

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

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

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

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

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

Реляционная модель данных

История реляционных СУБД ведет свое начало с конца 60-х, когда одновременно несколькими авторами были выдвинуты предложения об использовании теоретико-множественных операторов для организации доступа к данным. Наиболее известными являются работы Е. Кодда. Затем была экспериментальная система управления базми данных System R и использованный в ней язык SEQUEL, который можно считать непосредственным предшественником языка SQL. В настоящее время именно язык SQL является и де-юро, и де-факто стандартом для работы с реляционными СУБД. Например, семейство серверов реляционных баз данных Informix Dynamic Server поддерживают все эти стандарты и, кроме того, обеспечивают дополнительные возможности.

Интересно отметить, что еще в 1980 году Джефри Ульман (J.D. Ullman) писал в своей монографии "Основы систем баз данных" ("Principles of Databse Systems"), что почти все существующие коммерческие системы баз данных базируются либо на сетевой, либо на иерархической модели данных, но не реляционной модели и "эта ситуация будет меняться медленно". Тем не менее, уже в 1985 году ситуация резко поменялась - реляционные СУБД и язык SQL стали очень популярными. А в начале 90-х годов реляционные СУБД и язык SQL практически вытеснили все остальное с рынка СУБД. Причиной для такого кардинального изменения ситуации стала разработка эффективных, быстрых и надежных методов хранения и доступа к реляционным данным.

Понятие отношения и таблицы

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

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

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

Представление базы данных

Реляционная база данных - это набор информации, сгруппированной в одну или несколько таблиц. Таблицу можно представить как двумерный массив, или как набор записей одинаковой (для данной таблицы) структуры. Записи еще называют рядами. Другими словами, таблица состоит из рядов и столбцов. Число столбцов и записей для каждой таблицы теоретически неограничено, хотя на практике ограничения, естественно, существуют. Превысить ограничения хорошего сервера базы данных практически невозможно - например, сервер баз данных Infomix DS позволяет иметь до 32 767 столбцов и до 8 миллиардов записей в каждой таблице.

+-----+----+-----+-------+ ¦     ¦    ¦     ¦       ¦ <-------- запись (ряд) ¦-----+----+-----+-------¦ ¦     ¦XXXX¦     ¦       ¦ <-------- запись (ряд) ¦-----+-+--+-----+-------¦ ¦       ¦                ¦ ¦       L----------------+----> значение данного атрибута ¦  ...................   ¦      для данной записи ¦-----+----+-----+-------¦ ¦     ¦    ¦     ¦       ¦ +-----+----+-----+-------+    ^   ^    ¦   ¦    ¦   L---------- столбец (атрибут, поле)    L-------------- столбец (атрибут, поле)

Рис. 2.6. Структура таблицы (отношения).

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

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

Связь между таблицами

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

Таблица "Издательства":          +--------------------------+-----------------+         ¦  Название                ¦ Адрес           ¦        +--------------------------+-----------------+         ¦ Бухгалтерия и спорт      ¦ Одесса, п/я 13  ¦        ¦ Драконоведение           ¦ Энск, 5-е авеню ¦        ¦ ....................     ¦ ............... ¦        +--------------------------+-----------------+  

Таблица "Сборники":          --------------------------T------------------------+        ¦ Сборник                 ¦  Издательство          ¦        +-------------------------+------------------------+        ¦ Финансы в спорте’97     ¦ Бухгалтерия и спорт    ¦        ¦ Как уйти от налогов     ¦ Бухгалтерия и спорт    ¦        ¦ Техника бега            ¦ Бухгалтерия и спорт    ¦        ¦ Китайские бумажные змеи ¦ Драконоведение         ¦        ¦ ......                  ¦ ....................   ¦        L-------------------------+------------------------+

Рис. 2.7. Структура некоторых таблиц из базы данных для издательств (отношения).

Теперь по названию сборника всегда можно определить название и адрес издательства (или нескольких издательств), его выпустившего. Для этого надо в таблице "Сборники" найти запись, у которой поле "Сборник" есть требуемое название, из найденной запись взять название издательства (атрибут “Издательство”), а потом в таблице "Издательства" найти нужный адрес.

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

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

SQL - классическая язык доступа к реляционным СУБД

Практически все современные реляционные СУБД поддерживают Structured Query Language (SQL) - язык структурированных запросов. Синтаксис и семантика данного языка определены стандартами ISO, базирующимися на соответствующих стандартах ANSI SQL 87, SQL-89 и SQL-92.

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

Code:

CREATE TABLE Издательства (        Название CHAR(20),        Адрес CHAR(40) ) CREATE TABLE Сборники (        Сборник CHAR(20),        Издательство CHAR(20) )

 

 

Запрос, который определит адрес издательства (или издательств), выпустивший сборник “Китайские воздушные змеи” будет выглядеть следующим образом:

Code:

SELECT Адрес FROM Издательства WHERE Название =        (SELECT Издательство FROM Сборники WHERE                Сборник = “Китайские воздушные змеи”)

 

 

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

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

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

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

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