Реляционные субд: обзор базы данных, примеры

Фундаментальные модели

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

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

Кластеры атакуют!

В начале нового тысячелетия в технологическом мире лопнул пузырь доткомов (), надувавшийся в 1990-х годах. Это вызвало у многих людей вопросы об экономических перспективах Интернета, но в 2000-х годах некоторые из главных свойств сети веб приобрели очень большой масштаб.

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

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

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

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

Когда произошел сдвиг в сторону кластеров, возникла новая проблема – реляционные базы данных не предназначены для работы на кластерах. Кластерные реляционные базы данных, такие как Oracle RAC или Microsoft SQL Server, основаны на концепции общей дисковой подсистемы. Они используют кластерную файловую систему, выполняющую запись данных в легко доступную дисковую подсистему, но это значит, что дисковая подсистема по-прежнему является единственным источником уязвимости кластера. Реляционные базы данных также могут работать на разных серверах с разными наборами данных, эффективно выполняя фрагментацию базы данных (sharding). Хотя это позволяет разделить рабочую нагрузку, вся процедура фрагментации должна контролироваться приложением, которое должно следить за тем, какой сервер базы данных и за какой порцией данных обращается.

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

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

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

В частности, большое влияние оказали две компании — Google и Amazon. Они вышли на передний фронт работы с горизонтально масштабированными кластерами; более того, они хранили огромные объемы данных. Это стимулировало остальные компании.

Обе компании были успешными и быстро растущими высокотехнологичными предприятиями, обладающими средствами и возможностями. Им не приходило в голову, что они уничтожают свои реляционные базы данных. Когда прошло первое десятилетие нового века, обе компании опубликовали короткие, но очень важные документы о своих усилиях: BigTable от компании Google и Dynarno от компании Amazon.

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

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

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

Основные характеристики полей реляционных БД

Названия полей должны быть уникальными в рамках одной сущности. Типы атрибутов или полей реляционных баз данных описывают, данные какой категории хранятся в полях сущностей. Поле реляционной базы данных должно иметь фиксированный размер, исчисляемый в символах. Параметры и формат значений атрибутов определяют манеру исправления в них данных. Еще есть такое понятие, как «маска», или «шаблон ввода». Оно предназначено для определения конфигурации ввода данных в значение атрибута. Непременно при записи неправильного типа данных в поле должно выдаваться извещение об ошибке. Также на элементы полей накладываются некоторые ограничения – условия проверки точности и безошибочности ввода данных. Существует некоторое обязательное значение атрибута, которое однозначно должно быть заполнено данными. Некоторые строки атрибутов могут быть заполнены NULL-значениями. Разрешается ввод пустых данных в атрибуты полей. Как и извещение об ошибке, есть значения, которые заполняются системой автоматически – это данные по умолчанию. Для ускорения поиска любых данных предназначено индексированное поле.

О выборе NoSQL-баз данных

  1. Хранение больших объёмов неструктурированной информации. База данных NoSQL не накладывает ограничений на типы хранимых данных. Более того, при необходимости в процессе работы можно добавлять новые типы данных.
  2. Использование облачных вычислений и хранилищ. Облачные хранилища — отличное решение, но они требуют, чтобы данные можно было легко распределить между несколькими серверами для обеспечения масштабирования. Использование, для тестирования и разработки, локального оборудования, а затем перенос системы в облако, где она и работает — это именно то, для чего созданы NoSQL базы данных.
  3. Быстрая разработка. Если вы разрабатываете систему, используя agile-методы, применение реляционной БД способно замедлить работу. NoSQL базы данных не нуждаются в том же объёме подготовительных действий, которые обычно нужны для реляционных баз.

Основные операторы

— само отношение А (отношение здесь синонимично с таблицей и предикатом) является выражением реляционной алгебры, более того, так как это алгебра, любое выражение реляционной алгебры возвращает отношение (свойство замыкания операторов)

Selection (выборка; ограничение)

— selection (выборка; ограничение), A — отношение (предикат, таблица), – булева формула, по которой происходит отбор строк (кортежей, записей, etc)

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

Projection (проекция)

— projection (проекция) на атрибуты A, B, …. Возвращает таблицу, в которой остаются только колонки (атрибуты) A, B, …. Простой пример ниже. По сути является фильтром по атрибутам т.е. это в некотором смысле вертикальный фильтр.

Переименование

— переименовывает колонку a в b в отношении A (атрибут, аргумент предиката, etc); два чая тому господину, который покажет, что алгебра строго более выразима с оператором переименования (нужно привести пример запроса, который не выразим без этого оператора, но выразим с )

Как хранится информация в БД¶

В основе всей структуры хранения лежат три понятия:

  • База данных;
  • Таблица;
  • Запись.

База данных

База данных — это высокоуровневное понятие, которое означает объединение совокупности данных, хранимых для выполнения одной цели.

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

Таблица

По отношению к базе данных таблица является вложенным объеком. То есть одна БД может содержать в себе множество таблиц.

Аналогией из реального мира может быть шкаф (база данных) внутри которого лежит множество коробок (таблиц).

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

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

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

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

Запись

Запись — это строка электронной таблицы.

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

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

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

1. Создадим для сайта новую БД и дадим ей название .

2. Создадим в БД новую таблицу с именем и определим там следующие столбцы:

  • Город (тип: текст);
  • День (тип: дата);
  • Температура (тип: число);
  • Облачность (тип: число; от 0 (нет облачности) до 4 (полная облачность));
  • Были ли осадки (тип: истина или ложь);
  • Комментарий (тип: текст).

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

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

Реляционная база данных

Английское слово „relation“ можно перевести как связь, отношение.

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

Что это за связи?

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

В сценарии с дневником погоды пользователь вводит название своего города. Это название сохраняется вместе с погодными данными.

Но можно поступить иначе:

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

Так мы решим сразу две задачи:

  • Сократим объём хранимой информации, так как погодные записи больше не будут содержать название города;
  • Избежим дублирования: все пользователи будут выбирать один из заранее определённых городов, что исключит опечатки.

Связи между таблицами в БД бывают разных видов.

В примере выше использовалась связь типа «один-ко-многим», так как одному городу может соответствовать множество погодных записей, но не наоборот!

Бывают связи и других типов: «один-к-одному» и «многие-ко-многим», но они используются значительно реже.

5 последних уроков рубрики «Разное»

  • Выбрать хороший хостинг для своего сайта достаточно сложная задача. Особенно сейчас, когда на рынке услуг хостинга действует несколько сотен игроков с очень привлекательными предложениями. Хорошим вариантом является лидер рейтинга Хостинг Ниндзя — Макхост.

  • Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

    Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.

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

  • Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Разница между реляционной и нереляционной базой данных

Определение

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

Synonms

Реляционные базы данных также называются базами данных SQL, в то время как нереляционные базы данных также называются базами данных NoSQL.

присоединяется

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

Типы

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

использование

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

Примеры

MySQL, SQLite3 и PostgreSQL — это некоторые СУБД, использующие реляционные базы данных. Cassendra, Hbase, MongoDB и Neo4 — некоторые нереляционные базы данных.

Заключение

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

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

Схема реляционной БД
Название атрибута 1 Название атрибута 2 Название атрибута 3 Название атрибута 4 Название атрибута 5
Элемент_1_1 Элемент_1_2 Элемент_1_3 Элемент_1_4 Элемент_1_5
Элемент_2_1 Элемент_2_2 Элемент_2_3 Элемент_2_4 Элемент_2_5
Элемент_3_1 Элемент_3_2 Элемент_3_3 Элемент_3_4 Элемент_3_5

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

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

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

Ограничения традиционной реляционной модели при моделировании нескольких сущностей реального мира привели к изучению семантических моделей данных и так называемых расширенных реляционных моделей данных. За право считаться следующим поколением реляционной модели сейчас соревнуются две модели: объектно-ориентированная и объектно-реляционная. Базы данных, разрабатываемые на основе первой, называются объектно-ориентированными системами управления базами данных (ООСУБД; Object-Oriented Database Management Systems — OODBMS), а базы данных,разрабатываемые на основе второй, соответственно — объектно-реляционными системами управления базами данных.

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

В объектно-ориентированных БД все данные являются объектами. Они могут быть связаны друг с другом отношением «является частью» для представления более крупных составных элементов.

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

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

Операции над множествами

Реляционная алгебра является расширением классического набора операторов над множествами (отношение — это множество упорядоченных кортежей; заметьте, что это совсем не равно упорядоченному множеству кортежей). Пусть у нас есть таблица StudentMark(Name, Mark, Subject, Date) – тогда кортеж (Вася, 5, Информатика, 05.10.2010) является упорядоченным – сначала строка Name на первой (ок, или нулевой) позиции, целое число на второй, строка на третьей и дата на четвертой. При этом сами упорядоченные кортежи (Name, Mark, Subject, Date) не упорядочены «внутри» отношения.

— объединение всех строк в A и B, ограничение — одинаковые аттрибуты

— пересечение строк, такое же ограничение

— B минус A, все строки, что присутствуют в B, но не присутствуют в A, такое же ограничение

(B\A; A — слева, B — справа)

Вспомогательные операторы

— join (соединение); join соединяет две записи таблиц A и B, при условии, что для этих двух записей выполнено условие φ.

admin
Оцените автора
( Пока оценок нет )
Добавить комментарий