Какие бывают базы данных

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

Иерар­хия — это когда есть выше­сто­я­щий, а есть его под­чи­нён­ные, кто ниже. У них могут быть свои под­чи­нён­ные и так далее. Мы уже каса­лись такой моде­ли, когда гово­ри­ли про дере­вья и бустинг.

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

Вид­но, что на дис­ке C: есть мно­го папок: Dropbox, eSupport, GDrive и все те, кото­рые не поме­сти­лись на экране.

Внут­ри пап­ки GDrive есть ###_Inbox и #_Альбатрос, а внут­ри #_Альбатроса — десят­ки дру­гих папок. Если мы посмот­рим на скрин­шот, то уви­дим, то долж­ност­ная инструк­ция бух­гал­те­ра лежит с осталь­ны­ми фай­ла­ми внут­ри пап­ки Долж­ност­ные и охра­на тру­да, кото­рая лежит внут­ри пап­ки Инструкции.

Иерар­хи­че­ская база дан­ных зна­ет, кто кому под­чи­ня­ет­ся, и поэто­му может быст­ро нахо­дить нуж­ную инфор­ма­цию. Но такие базы мож­но орга­ни­зо­вать толь­ко в том слу­чае, когда у вас есть чёт­кое раз­де­ле­ние в дан­ных, что глав­нее, а что ему подчиняется.

Примеры

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

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

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

Программы доступа к Webmoney

Основные понятия иерархической модели

Иерархическая модель является самой ранней моделью баз данных. Для понимания иерархической модели необходимо запомнить следующие термины:

• Атрибут (или поле)– минимальный элемент данных. Атрибут имеет уникальное имя, по которому к нему можно обратиться из программного кода.
• Запись – логически связанная совокупность атрибутов. Запись имеет уникальное имя, которое позволяет обращаться к ней из программного кода. Записи можно добавлять, изменять, удалять.
• Экземпляр записи – конкретная запись с конкретными значениями атрибутов.
• Групповое отношение — иерархическое отношение между записями двух разных типов. Запись, которая, находится выше по иерархии, называется родительской. Записи, которые, расположены ниже по иерархии называются дочерними.

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

Пример 1

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

• Спортсмен (код спортсмена, разряд, ФИО);
• Тренер (код тренера, разряд, ФИО);
• Соревнование (код соревнования, дата, название).

Отношения между записями соответствуют связям между объектами реального мира. Например, отношение между объектом «тренер» и объектом «спортсмен» моделируется связью типа «один-ко-многим». Поэтому в записи «спортсмен» являются дочерними по отношению к записи «тренер». А вот между объектами «спортсмен» и «соревнование» в реальной жизни присутствует связь «много-ко-многим», потому что спортсмен может участвовать во многих соревнованиях, а в одном соревновании участвует много спортсменов. Отношения типа «много-ко-многим» в иерархической модели данных не существует. Единственный способ смоделировать его — это дублирование информации путем создания дополнительного дерева 2.

ПримерыExamples

Простой примерSimple Example

Следующий пример намеренно упрощен, чтобы легче было приступить к работе.The following example is intentionally simplistic to help you get started. Сначала создайте таблицу для хранения определенных географических данных.First create a table to hold some geography data.

Теперь введите данные для некоторых континентов, стран, штатов и городов.Now insert data for some continents, countries, states, and cities.

Выберите данные, добавляя столбец, который преобразовывает данные уровня в текстовое значение, удобное для восприятия.Select the data, adding a column that converts the Level data into a text value that is easy to understand. Этот запрос также отсортирует результат по типу данных hierarchyid .This query also orders the result by the hierarchyid data type.

Результирующий набор:Here is the result set.

Обратите внимание, что иерархия имеет допустимую структуру, несмотря на отсутствие внутреннего согласования.Notice that the hierarchy has a valid structure, even though it is not internally consistent. Байя — единственный штат.Bahia is the only state

Он отображается в иерархии как одноранговый по отношению к городу Бразилиа.It appears in the hierarchy as a peer of the city Brasilia. Аналогично полярная станция Макмердо не имеет родительской страны.Similarly, McMurdo Station does not have a parent country. Необходимо решить, подходит ли этот тип иерархии для использования.Users must decide if this type of hierarchy is appropriate for their use.

Добавьте еще одну строку и выберите результаты.Add another row and select the results.

Это демонстрирует наличие других возможных проблем.This demonstrates more possible problems. Киото можно ввести в качестве уровня даже при отсутствии родительского уровня .Kyoto can be inserted as level even though there is no parent level . И Лондон и Киото имеют одинаковое значение свойства hierarchyid.And both London and Kyoto have the same value for the hierarchyid. Опять-таки пользователи должны решить, подходит ли этот тип иерархии для использования, и заблокировать значения, недопустимые для использования.Again, users must decide if this type of hierarchy is appropriate for their use, and block values that are invalid for their usage.

Кроме того, в этой таблице не используется верхняя часть иерархии .Also, this table did not use the top of the hierarchy . Она была опущена, потому что общий родительский объект для всех континентов отсутствует.It was omitted because there is no common parent of all the continents. Его можно добавить путем добавления всей планеты.You can add one by adding the whole planet.

Сетевые базы данных

Существуют:

• реляционные;
• иерархические;
• сетевые базы данных.

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

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

Структурная часть иерархической модели

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

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

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

Табличные базы данных

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

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

Определение 2

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

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

Замечание 2

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

Ключевое поле, как правило, имеет тип данных счетчик. Однако в некоторых случаях удобнее, чтобы ключевое поле таблицы имело другой тип (например, числовой — инвентарный номер или код объекта).

Как работают базы данных.

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

Язык структурированных запросов SQL позволяет производить следующие операции:

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

Достоинства системы управления базами данных MySQL:

• Скорость выполнения запросов.
•  СУБД MySQL разработана с использованием языков C/C++ и оттестирована более чем на 23 платформах.
• Открытый код доступен для просмотра и модернизации всем желающим.
• Высокое качество и устойчивость работы.
• Поддержка API для различных языков программирования
• Наличие встроенного сервера. СУБД MySQL может быть использован как с внешним сервером, поддерживающим соединение с локальной машиной и с удаленным хостом, так и в качестве встроенного сервера.
• Широкий выбор типов таблиц позволяет реализовать оптимальную для решаемой задачи производительность и функциональность.
• Локализация выполнена корректна. 
• Совместимость с другими базами данных и полностью удовлетворяет стандарту SQL.

Как отследить iPhone друга через Find My Friends?

Приложение Find My Friends предоставляет пользователю возможность узнать, где находятся его друзья и близкие. Если на телефоне установлена операционная система iOS 9 или более поздняя версия, то программа должна быть установлена по умолчанию. На iOS 8 понадобится ручная установка приложения. Если войти в сервис iCloud на своем устройстве, то автоматически будет выполнен вход в приложение Find My Friends с таким же Apple ID.

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

• запустить приложение Find Friends;
• нажать кнопку «Добавить»;
• выбрать необходимое имя из списка или ввести адрес электронной почты;
• нажать «Готово», после чего запрос будет отправлен.

Если друг согласен делиться своим местоположением на карте, он одобрит запрос. В дальнейшем его можно будет отслеживать онлайн через Find My Friends или веб-страницу iCloud.

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

Пример табличной базы данных

Рассмотрим базу данных «Компьютер» (рис.3), которая представляет собой перечень объектов (компьютеры), каждый из которых имеет свое имя (название). В качестве характеристик (свойств) будут выступать тип процессора и объем оперативной памяти.

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

Определение 3

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

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

Замечание 3

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

Отношения и функции

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

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

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

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

Как известно, различают четыре вида посторения БД:

• Реляционные — табличные СУБД, где информация представлена в виде строк-столбцов. По этому принципу строятся базы данных в «Аксесе», к примеру.
• Объектно-ориентированные — тесно связаны с ООП (программированием, в котором идет работа с объектами), и это их главный плюс, но, учитывая их небольшую производительность, они пока значительно уступают в распространенности реляционным.
• Гибридные — СУБД, вмещающие в себе сразу два указанных выше вида.
• Иерархические — объект внимания данной статьи. Это БД, характеризирующиеся древообразной структурой.

Наиболее известным примером иерархической базы данных является продукт, созданный компанией IBM («АйБиЭм»), под названием Information Management System (переводится как «Информационная система управления»), сокращенно IMS. Первая версия IMS вышла еще в прошлом, двадцатом веке, в шестьдесят восьмом году. Она используется для хранения и контроля данных и поныне.

Управляющая часть иерархической модели

В рамках иерархической модели выделяют языковые средства описания данных (ЯОД) и средства манипулирования данными (ЯМД). Каждая физическая база описывается набором операторов, обусловливающих как её логическую структуру, так и структуру хранения БД. При этом способ доступа устанавливает способ организации взаимосвязи физических записей.

Определены следующие способы доступа:

• иерархически последовательный;
• иерархически индексно-последовательный;
• иерархически прямой;
• иерархически индексно-прямой;
• индексный.

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

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

InnoDB

Данный тип таблиц обеспечивает высокую производительность и устойчивое хранение данных в таблицах объемом вплоть до 1 Тбайт и нагрузкой на 
сервер до 800 вставок/обновлений в секунду.Особенности таблиц типа InnoDB:

• Таблицы не создаются в базах данных, и для каждой из таблиц не выделяется отдельный файл данных. Исключение – файл определения с расширением frm, который создается по умолчанию. Все таблицы хранятся в едином табличном пространстве, поэтому имена таблиц должны быть уникальными.
• Хранение данных в едином табличном пространстве позволяет снять ограничение на объем таблиц, так как файл с таблицами может быть разбит не несколько частей и распределен по нескольким дискам или даже хостам.
• Данный тип таблиц поддерживает автоматическое восстановление после сбоев.
• Обеспечивается поддержка транзакций.
• Единственный тип таблиц, поддерживающий внешние ключи и каскадное удаление.
• Выполняется блокировка на уровне отдельных записей.
• Расширенная поддержка кодировок.
• Рушатся при достижении объема в несколько гигабайт, однако заметно уступают в скорости и не поддерживают полнотекстовый поиск.

Уровни моделирования реляционной базы данных

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

Вводятся следующие понятия:

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

Бинарные связи

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

Типы бинарных связей:

• Связь типа «один-к-одному» означает, что один экземпляр первой сущности связан не более чем с одним экземпляром второй сущности и, наоборот, один экземпляр второй сущности связан не более чем с одним экземпляром первой сущности.
• Связь типа «один-ко-многим» означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности, но при этом один экземпляр второй сущности связан не более чем с один экземпляром первой сущности.
• Связь типа «много-ко-многим» означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Эта связь должна быть заменена двумя связями типа один-ко-многим путем создания промежуточной сущности.

Отзывы и комментарии о сайте: cashbox.ru

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

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

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

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

Рис.
6. Иерархическая
база данных

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

Из
этого примера видны недостатки
иерархических БД:

Частично
дублируется информация между
записями СОТРУДНИК и ИСПОЛНИТЕЛЬ (такие
записи называют парными), причем
виерархической
модели данных не
предусмотрена поддержка соответствия
между парными записями.

Иерархическая
модель реализует отношение между
исходной и дочерней записью по схеме
1:N, то есть одной родительской записи
может соответствовать любое число
дочерних.

Допустим
теперь, что исполнитель может
принимать участие более чем в одном
контракте (т.е. возникает связь типа
M:N). В этом случае в базу данных необходимо
ввести еще одно групповое отношение,
в котором ИСПОЛНИТЕЛЬ будет
являться исходной записью, а КОНТРАКТ
— дочерней ( рис.
7 c). Таким образом, мы опять вынуждены
дублировать информацию.

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