5. Типы баз данных. Преимущество реляционных бд.
Иерархическая:
Иерархические базы данных могут быть представлены как дерево, состоящее из объектов различных уровней. Верхний уровень занимает один объект, второй — объекты второго уровня и т. д.
Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект более близкий к корню) к потомку (объект более низкого уровня), при этом возможна ситуация, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один предок.
Сетевые:
Сетевые базы данных подобны иерархическим, за исключением того, что в них имеются указатели в обоих направлениях, которые соединяют родственную информацию.
Реляционная:
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц.
Реляционная база – совокупность двумерных таблиц, где столбцами – являются характеристики объекта, строками – экземпляры объекта.
Достоинства:
1. Простота – использование двумерных матриц. Самый простой способ работы с базой для неподготовленного пользователя.
2. Гибкость – с таблицей можно производить любые операции склеивания и разрезания, т.о. можно получать информацию в любом виде. Один объект связывается с другим по столбцам и строкам, мы получаем 1 большую таблицу, из которой мы берем строки по нужным нам характеристикам. Эту таблицу мы можем склеивать и разделять.
3. Точность – описание связей между таблицами и характеристиками. Можно описывать с помощью, так называемой алгебры отношений.
4. Секретность – контроль за доступом к информации упрощается.
5. Простота ведения. Двумерную таблицу легко представить в виде физических записей.
6. Независимость данных – проще всего обеспечить независимость данных от ПО в реляционных структурах.
7. Достаточно простой язык манипулирования данными. SQL – структурный язык запросов.
8. Ясность – достаточно просто представить логическую схему базы.
Недостатки:
1. Не всегда удобно представлять информацию в двумерных таблицах, иногда удобнее представить информацию в многомерных таблицах или в виде дерева.
6. Понятие реляционной таблицы. Свойства реляционной таблицы.
Реляционная таблица — основной контейнер хранения данных в БД. Реляционную таблицу можно представить в виде плоскости, разделенной на строки и столбцы. В таблице размещаются строки определенного вида, точно так же, как в папке могут храниться документы одного типа (например, счета за телефон).
Свойства реляционных таблиц:
1. Все столбцы в таблице имеют уникальные имена.
2. Каждый элемент в таблице представляет собой элемент данных. Повторяющиеся группы отсутствуют.
3. В реляционных таблицах нет 2-х одинаковых строк
4. В операциях с такой таблицей ее строки и столбцы могут просматриваться в любом порядке без относительно к информационному содержанию и смыслу.
7. Понятие отношения, поля, записи, внешнего ключа, первичного ключа. Типы связей. Мощность связи. Обязательность связи.
Отношение — множество однотипных записей объединенных одной темой.
Элемент данных (поле) – наименьшая поименованная единица данных.
Поле – это столбец. Каждый столбец имеет имя.
Запись – отдельная уникальная совокупность полей.
Первичный ключ – это одно или несколько полей (столбцов), комбинация значений которых однозначно определяет каждую запись в таблице.
Внешний (вторичный) ключ — это одно или несколько полей (столбцов) в таблице, содержащих ссылку на поле или поля первичного ключа в другой таблице.
Связь «один-ко-многим» означает, что одной записи в родительской таблице может соответствовать ноль, одна или более записей в дочерней таблице.
Связь «один-ко-многим» является самой распространенной для реляционных баз данных.
Связь «один-к-одному» имеет место, когда одной записи в родительской таблице соответствует ноль или одна запись в дочерней таблице.
Связь «многие-ко-многим» — данный вид связи означает, что несколько записей одной таблицы связаны с несколькими записями другой таблицы и наоборот
Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству дочерней сущности. По мощности связи выделяют отношения «один к одному», «один ко многим», «многие ко многим».
Требование целостности ссылок заключается в том, что внешний ключ не может быть указателем на несуществующую строку в таблице, т.е. для любой записи с конкретным значением внешнего ключа должна обязательно существовать связанная запись в родительской таблице с соответствующим значением первичного ключа.
studfiles.net
Реляционные таблицы (отношения)
Под реляционной таблицей понимается 2-х мерная таблица, обладающая следующими свойствами:
1) у всех столбцов уникальные имена
2) столбцы в таблице однородны (любое имя определяет тип данных)
3) любой элемент таблицы неделим
4) нет одинаковых строк
5) в операциях с такой таблицей строки и столбцы могут просматриваться в любом порядке.
Соответствия между традиционными понятиями и понятиями реляционной алгебры:
| традиционное понятие | реляционная алгебра | термин Б.Д. |
| таблица | реляционная таблица отношение | таблица Б.Д. (*.mbd) |
| строка | кортеж | запись |
| столбец | атрибут | поле |
| множество допустимых значений элементов столбцов | домен | тип и размер данного |
Записи в Б.Д. образуются при вводе данных в таблицу. Каждой записи присваивается уникальный номер (служебное поле). Число записей может превышать 1 млрд. Текущая запись – та, на которой в данный момент стоит указатель. При открытии Б.Д. это, как правило, первая запись (может быть и последняя). Число полей ≥255.
Любая таблица (отношение) состоит из атрибутов (столбцов), а любая запись содержит сведения о конкретном экземпляре рассматриваемой сущности. Для однозначного определения каждой записи вводится уникальное ключевое поле (или совокупность полей), называемое первичным ключом. Первичный ключ помимо уникальности должен быть непустым. Одно поле – простой ключ, несколько – составной.
Пример: в таблице «заказ» могут быть поля: №, дата, код клиента и т.д. Если все номера заказов уникальны, то первичный ключ – поле «№». Если нумерация заказов ежемесячна, то первичный ключ — совокупность полей «№»&«дата».
По значению ключа определяется единственная запись в таблице.
2. Связи между таблицами
Связи между таблицами дают возможность использовать данные разных таблиц. В реляционной модели используются 3 основные вида связи:
1. один-к-одному (1:1) –одному элементу одной таблицы соответствует один элемент другой таблицы и наоборот.
2. один-ко-многим (1:∞) –одному элементу главной (родительской) таблицы соответствует множество элементов другой таблицы, называемой подчиненной (дочерней). В этом случае одному значению первичного ключа главной таблицы несколько записей с таким же ключом соответствующего поля называется вторичным ключом, подчиненным другой таблицы.
| клиент | код |
| 543 |
| код ¿ | код заказа |
Пример:
3. Операции над реляционными таблицами:
1. Традиционные для множеств:
1.1. Объединение –операция над двумя совместимыми отношениями R1 и R2, имеющими одинаковую структуру (состав полей). В результате получается новое отношение: R= R1∪R2, имеющее тот же состав атрибутов (полей) и совокупность строк исходных таблиц, исключая дублирующие.
1.2. Пересечение –
1.3. Вычитание – R=R1-R2
1.4. Декартово произведение – R=R1*R2. R включает в себя все атрибуты исходных отношений. При этом R состоит из всевозможных сочетаний строк исходных отношений (число строк равно числу строк R1 умноженному на число строк R2).
| № | ФИО | код | наим |
| Ш | П1 | БД | |
| Ш | П2 | ОС | |
| В | П1 | БД | |
| В | П2 | ОС | |
| К | П1 | БД | |
| К | П2 | ОС |
Пример:
| код пр. | наим. |
| П1 | БД |
| П2 | ОС |
2. Операции реляционной алгебры:
2.1. Выбор(ка) –операция выполняется над одним отношением R1. Результат: R содержит только те строки, которые имеют заданные значения в выбранных полях, структура таблицы сохраняется.
2.2. Проекция –выполняетсянад одним отношением R1. Результат: R, в которое включены только заданные поля.
2.3. Соединение – над двумя связанными таблицами R1 и R2. R представляет комбинацию R1 и R2. Структура – совокупность всех атрибутов исходных таблиц, строки формируются таким образом, что каждая строка главной таблицы объединяется со строками из подчиненной, для которой выполняется условие равенства значений ключа связи.
Пример: в результате соединения таблиц «клиент» и «заказ» получаем таблицу, содержащую список клиентов и сделанных ими заказов.
Все операции над реляционными таблицами поддерживаются инструкциями языка структурированных запросов SQL (Structured Query Language).
infopedia.su
Свойства реляционной таблицы
ОСНОВНЫЕ ПОНЯТИЯ БАЗ ДАННЫХ
База данных (БД) – именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области данных.
Примеры предметных областей данных: склад, магазин, вуз, больница, учебный процесс и т. д. Именно предметная область определяет совокупность данных, которые должны храниться в базе данных.
Система управления базами данных (СУБД) – совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования базы данных многими пользователями.
Другие определения, имеющие отношение к БД и СУБД.
Банк данных (БнД) – это система специальным образом организованных данных – баз данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и многоцелевого использования данных.
Информационная система (ИС) – взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной задачи.
Основой практически любой информационной системы является база данных.
Сервер – компьютер или программа, владеющая определенным информационным ресурсом и предназначенная для обработки запросов от программ-клиентов.
Основными моделями данных, определяющие структуру базы данных, являются:
иерархическая модель;
сетевая модель;
реляционная модель.
РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ
Теоретической основой этой модели является теория отношений и основной структурой данных – отношение. Именно поэтому модель получила название реляционной (от английского слова relation — отношение).
Отношениепредставляет собой множество элементов, называемых кортежами. Наглядной формой представления отношения является двумерная таблица. Смысловые значения некоторых элементов реляционной модели приведены в следующей таблице.
| Обычное представление | База данных | Реляционная модель |
| Таблица | Таблица | Отношение |
| Строка | Запись | Кортеж |
| Название столбца | Поле | Атрибут |
| Множество значений столбца | Множество значений поля | Домен (множество значений атрибута) |
Подавляющее число создаваемых и используемых баз данных являются реляционными. Их создание и развитие связано с научными работами известного американского математика, специалиста в области систем баз данных Э. Кодда.
Свойства реляционной таблицы
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
· каждый элемент таблицы — один элемент данных;
· все столбцы (поля, атрибуты) в таблице однородные, т.е. все элементы в одном столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;
· каждый столбец имеет уникальное имя;
· одинаковые строки (записи, кортежи) в таблице отсутствуют;
· порядок следования строк и столбцов может быть произвольным.
Каждое поле содержит одну характеристику объекта предметной области. В записи собраны сведения об одном экземпляре этого объекта.
Ключи
Поле, каждое значение которого однозначно определяет соответствующую запись, называется простым ключом (ключевым полем). Ключ, состоящий из нескольких полей называется составным ключом. В СУБД Access в качестве ключа может быть использован Счетчик, который автоматически возрастает на единицу при вводе в таблицу новой записи. Такой ключ называют искусственным. Он семантически не связан ни с одним полем таблицы. Из-за этого он допускает повторный ввод одних и тех же записей. Но с помощью него просто устанавливать связь между таблицами. Основное свойство ключа – уникальность, неповторимость.
Типы связей между таблицами
Структура базы данных определяется структурой таблиц и связями между ними.
Связи между таблицами бывают трех типов:
«один-к-одному» (1:1) – одной записи в главной таблице соответствует одна запись в подчиненной таблице,
«один-ко-многим» (1:М) – одной записи в главной таблице соответствует несколько записей в подчиненной таблице,
«многие-ко-многим» (М:М) – нескольким записям в главной таблице соответствуют несколько записей в подчиненной таблице. Или одной записи в первой таблице может соответствовать несколько записей во второй таблице. И одной записи во второй таблице могут соответствовать несколько записей в первой таблице.
Создание связей между таблицами
Связь между таблицами устанавливается с помощью ключей. Главной называют таблицу, первичный ключ которой используется для установления связи с другой таблицей, которая в этом случае называется подчиненной.
Чтобы связать две реляционные таблицы, необходимо ключ главной таблицы ввести в состав подчиненной таблицы. Название ключа может быть другим, но обязательно одинаковыми с первичным ключом должны быть тип и размер вторичного ключа в подчиненной таблице. Для удобства лучше обозначение вторичного ключа оставлять таким же, как и первичного. Однако если ключом выбран Счетчик, то вторичный ключ должен иметь тип Числовой — длинное целое (но не Счетчик!). Вторичный ключ – это или обычное поле, или часть первичного ключа в подчиненной таблице.
СУБД Access для реализации связи «многие-ко-многим» требует создать таблицу связи и ввести в нее в качестве вторичных ключей первичные ключи двух таблиц, которые должны иметь такую связь (М:М). После этого устанавливается связь 1:М каждой из двух таблиц с таблицей связи. Между двумя таблицами таким образом реализуется связь М:М. Если в БД «Моя библиотека» создать таблицы Книги и Авторы, то связь между ними будет вида М:М, так как одной записи в таблице Книги (реквизиты одной книги) может соответствовать несколько записей в таблице Авторы. Потому что у одной книги может быть несколько авторов. В свою очередь, одной записи в таблице Авторы могут соответствовать несколько записей в таблице Книги, так как один автор может написать несколько книг. Таблицу связи можно назвать КнигиАвторы, в которую будут включены ключи обеих таблиц – Книги и Авторы. Если требуется, в таблицу связи можно включить и другие поля.
Среди реляционных баз данных следует различать корпоративные и настольные базы данных.
Из корпоративных реляционных СУБД наиболее распространенными являются: Oracl, IBM DB2, Sybase, Microsoft SQL Server, Informix. Из постреляционных СУБД известна СУБД Cache компании InterSystems.
Наиболее известны в настоящее время следующие настольные БД: Microsoft Access, Paradox (фирмы Borland), FoxPro (Microsoft), dBase IV (IBM), Clarion.
Эти СУБД занимают более 90% всего рынка СУБД.
В следующем разделе дана краткая характеристика СУБД Microsoft Access.
Похожие статьи:
poznayka.org
Реляционные базы данных обречены? / Habr
Примечание переводчика: хоть статья довольно старая (опубликована 2 года назад) и носит громкое название, в ней все же дается хорошее представление о различиях реляционных БД и NoSQL БД, их преимуществах и недостатках, а также приводится краткий обзор нереляционных хранилищ.
В последнее время появилось много нереляционных баз данных. Это говорит о том, что если вам нужна практически неограниченная масштабируемость по требованию, вам нужна нереляционная БД.
Если это правда, значит ли это, что могучие реляционные БД стали уязвимы? Значит ли это, что дни реляционных БД проходят и скоро совсем пройдут? В этой статье мы рассмотрим популярное течение нереляционных баз данных применительно к различным ситуациям и посмотрим, повлияет ли это на будущее реляционных БД.
Реляционные базы данных существуют уже около 30 лет. За это время вспыхивало несколько революций, которые должны были положить конец реляционным хранилищам. Конечно, ни одна из этих революций не состоялась, и одна из них ни на йоту не поколебала позиции реляционных БД.
Начнем с основ
Реляционная база данных представляет собой набор таблиц (сущностей). Таблицы состоят из колонок и строк (кортежей). Внутри таблиц могут быть определены ограничения, между таблицами существуют отношения. При помощи SQL можно выполнять запросы, которые возвращают наборы данных, получаемых из одной или нескольких таблиц. В рамках одного запроса данные получаются из нескольких таблиц путем их соединения (JOIN), чаще всего для соединения используются те же колонки, которые определяют отношения между таблицами. Нормализация — это процесс структурирования модели данных, обеспечивающий связность и отсутствие избыточности в данных.
Доступ к реляционным базам данных осуществляется через реляционные системы управления базами данных (РСУБД). Почти все системы баз данных, которые мы используем, являются реляционными, такие как Oracle, SQL Server, MySQL, Sybase, DB2, TeraData и так далее.
Причины такого доминирования неочевидны. На протяжении всего существования реляционных БД они постоянно предлагали наилучшую смесь простоты, устойчивости, гибкости, производительности, масштабируемости и совместимости в сфере управлении данными.
Однако чтобы обеспечить все эти особенности, реляционные хранилища невероятно сложны внутри. Например, простой SELECT запрос может иметь сотни потенциальных путей выполнения, которые оптимизатор оценит непосредственно во время выполнения запроса. Все это скрыто от пользователей, однако внутри РСУБД создает план выполнения, основывающийся на вещах вроде алгоритмов оценки стоимости и наилучшим образом отвечающий запросу.
Проблемы реляционных БД
Хотя реляционные хранилища и обеспечивают наилучшую смесь простоты, устойчивости, гибкости, производительности, масштабируемости и совместимости, их показатели по каждому из этих пунктов не обязательно выше, чем у аналогичных систем, ориентированных на какую-то одну особенность. Это не являлось большой проблемой, поскольку всеобщее доминирование реляционных СУБД перевешивало какие-либо недочеты. Тем не менее, если обычные РБД не отвечали потребностям, всегда существовали альтернативы.
Сегодня ситуация немного другая. Разнообразие приложений растет, а с ним растет и важность перечисленных особенностей. И с ростом количества баз данных, одна особенность начинает затмевать все другие. Это масштабируемость. Поскольку все больше приложений работают в условиях высокой нагрузки, например, таких как веб-сервисы, их требования к масштабируемости могут очень быстро меняться и сильно расти. Первую проблему может быть очень сложно разрешить, если у вас есть реляционная БД, расположенная на собственном сервере. Предположим, нагрузка на сервер за ночь увеличилась втрое. Как быстро вы сможете проапгрейдить железо? Решение второй проблемы также вызывает трудности в случае использования реляционных БД.
Реляционные БД хорошо масштабируются только в том случае, если располагаются на единственном сервере. Когда ресурсы этого сервера закончатся, вам необходимо будет добавить больше машин и распределить нагрузку между ними. И вот тут сложность реляционных БД начинает играть против масштабируемости. Если вы попробуете увеличить количество серверов не до нескольких штук, а до сотни или тысячи, сложность возрастет на порядок, и характеристики, которые делают реляционные БД такими привлекательными, стремительно снижают к нулю шансы использовать их в качестве платформы для больших распределенных систем.
Чтобы оставаться конкурентоспособными, вендорам облачных сервисов приходится как-то бороться с этим ограничением, потому что какая ж это облачная платформа без масштабируемого хранилища данных. Поэтому у вендоров остается только один вариант, если они хотят предоставлять пользователям масштабируемое место для хранения данных. Нужно применять другие типы баз данных, которые обладают более высокой способностью к масштабированию, пусть и ценой других возможностей, доступных в реляционных БД.
Эти преимущества, а также существующий спрос на них, привел к волне новых систем управления базами данных.
Новая волна
Такой тип баз данных принято называть хранилище типа ключ-значение (key-value store). Фактически, никакого официального названия не существует, поэтому вы можете встретить его в контексте документо-ориентированных, атрибутно-ориентированных, распределенных баз данных (хотя они также могут быть реляционными), шардированных упорядоченных массивов (sharded sorted arrays), распределенных хэш-таблиц и хранилищ типа ключ-значения. И хотя каждое из этих названий указывает на конкретные особенности системы, все они являются вариациями на тему, которую мы будем назвать хранилище типа ключ-значение.
Впрочем, как бы вы его не называли, этот «новый» тип баз данных не такой уж новый и всегда применялся в основном для приложений, для которых использование реляционных БД было бы непригодно. Однако без потребности веба и «облака» в масштабируемости, эти системы оставались не сильно востребованными. Теперь же задача состоит в том, чтобы определить, какой тип хранилища больше подходит для конкретной системы.
Реляционные БД и хранилища типа ключ-значение отличаются коренным образом и предназначены для решения разных задач. Сравнение характеристик позволит всего лишь понять разницу между ними, однако начнем с этого:
Характеристики хранилищ
| Реляционная БД | Хранилище типа ключ-значение |
|---|---|
| База данных состоит из таблиц, таблицы содержат колонки и строки, а строки состоят из значений колонок. Все строки одной таблицы имеют единую структуру. |
Для доменов можно провести аналогию с таблицами, однако в отличие от таблиц для доменов не определяется структура данных. Домен – это такая коробка, в которую вы можете складывать все что угодно. Записи внутри одного домена могут иметь разную структуру. |
| Модель данных1 определена заранее. Является строго типизированной, содержит ограничения и отношения для обеспечения целостности данных. |
Записи идентифицируются по ключу, при этом каждая запись имеет динамический набор атрибутов, связанных с ней. |
| Модель данных основана на естественном представлении содержащихся данных, а не на функциональности приложения. |
В некоторых реализация атрибуты могут быть только строковыми. В других реализациях атрибуты имеют простые типы данных, которые отражают типы, использующиеся в программировании: целые числа, массива строк и списки. |
| Модель данных подвергается нормализации, чтобы избежать дублирования данных. Нормализация порождает отношения между таблицами. Отношения связывают данные разных таблиц. |
Между доменами, также как и внутри одного домена, отношения явно не определены. |
Никаких join’ов
Хранилища типа ключ-значение ориентированы на работу с записями. Это значит, что вся информация, относящаяся к данной записи, хранится вместе с ней. Домен (о котором вы можете думать как о таблице) может содержать бессчетное количество различных записей. Например, домен может содержать информацию о клиентах и о заказах. Это означает, что данные, как правило, дублируются между разными доменами. Это приемлемый подход, поскольку дисковое пространство дешево. Главное, что он позволяет все связанные данные хранить в одном месте, что улучшает масштабируемость, поскольку исчезает необходимость соединять данные из различных таблиц. При использовании реляционной БД, потребовалось бы использовать соединения, чтобы сгруппировать в одном месте нужную информацию.
Хотя для хранения пар ключ-значение потребность в отношения резко падает, отношения все же нужны. Такие отношения обычно существуют между основными сущностями. Например, система заказов имела бы записи, которые содержат данные о покупателях, товарах и заказах. При этом неважно, находятся ли эти данные в одном домене или в нескольких. Суть в том, что когда покупатель размещает заказ, вам скорее всего не захочется хранить информацию о покупателе и о заказе в одной записи.
Вместо этого, запись о заказе должна содержать ключи, которые указывают на соответствующие записи о покупателе и товаре. Поскольку в записях можно хранить любую информацию, а отношения не определены в самой модели данных, система управления базой данных не сможет проконтролировать целостность отношений. Это значит, что вы можете удалять покупателей и товары, которые они заказывали. Обеспечение целостности данных целиком ложится на приложение.
Доступ к данным
| Реляционная БД | Хранилище типа ключ-значение |
|---|---|
| Данные создаются, обновляются, удаляются и запрашиваются с использованием языка структурированных запросов (SQL). |
Данные создаются, обновляются, удаляются и запрашиваются с использованием вызова API методов. |
| SQL-запросы могут извлекать данные как из одиночной таблица, так и из нескольких таблиц, используя при этом соединения (join’ы). |
Некоторые реализации предоставляют SQL-подобный синтаксис для задания условий фильтрации. |
| SQL-запросы могут включать агрегации и сложные фильтры. |
Зачастую можно использовать только базовые операторы сравнений (=, !=, <, >, <= и =>). |
| Реляционная БД обычно содержит встроенную логику, такую как триггеры, хранимые процедуры и функции. |
Вся бизнес-логика и логика для поддержки целостности данных содержится в коде приложений. |
Взаимодействие с приложениями
| Реляционная БД | Хранилище типа ключ-значение |
|---|---|
| Чаще всего используются собственные API, или обобщенные, такие как OLE DB или ODBC. |
Чаще всего используются SOAP и/или REST API, с помощью которых осуществляется доступ к данным. |
| Данные хранятся в формате, который отображает их натуральную структуру, поэтому необходим маппинг структур приложения и реляционных структур базы. |
Данные могут более эффективно отображаться в структуры приложения, нужен только код для записи данных в объекты. |
Хранилища типа ключ-значение: преимущества
Есть два четких преимущества таких систем перед реляционными хранилищами.
Подходят для облачных сервисов
Первое преимущество хранилищ типа ключ-значение состоит в том, что они проще, а значит обладают большей масштабируемостью, чем реляционные БД. Если вы размещаете вместе собственную систему, и планируете разместить дюжину или сотню серверов, которым потребуется справляться с возрастающей нагрузкой, за вашим хранилищем данных, тогда ваш выбор – хранилища типа ключ-значение.
Благодаря тому, что такие хранилища легко и динамически расширяются, они также пригодятся вендорам, которые предоставляют многопользовательскую веб-платформу хранения данных. Такая база представляет относительно дешевое средство хранения данных с большим потенциалом к масштабируемости. Пользователи обычно платят только за то, что они используют, однако их потребности могут вырасти. Вендор сможет динамически и практически без ограничений увеличить размер платформы, исходя из нагрузки.
Более естественная интеграция с кодом
Реляционная модель данных и объектная модель кода обычно строятся по-разному, что ведет к некоторой несовместимости. Разработчики решают эту проблему при помощи написания кода, который отображает реляционную модель в объектную модель. Этот процесс не имеет четкой и быстро достижимой ценности и может занять довольно значительное время, которое могло быть потрачено на разработку самого приложения. Тем временем многие хранилища типа ключ-значение хранят данные в такой структуре, которая отображается в объекты более естественно. Это может существенно уменьшить время разработки.
Другие аргументы в пользу использования хранилищ типа ключ-значение, наподобие «Реляционные базы могут стать неуклюжими» (кстати, я без понятия, что это значит), являются менее убедительными. Но прежде чем стать сторонником таких хранилищ, ознакомьтесь со следующим разделом.
Хранилища типа ключ-значение: недостатки
Ограничения в реляционных БД гарантируют целостность данных на самом низком уровне. Данные, которые не удовлетворяют ограничениям, физически не могут попасть в базу. В хранилищах типа ключ-значение таких ограничений нет, поэтому контроль целостности данных полностью лежит на приложениях. Однако в любом коде есть ошибки. Если ошибки в правильно спроектированной реляционной БД обычно не ведут к проблемам целостности данных, то ошибки в хранилищах типа ключ-значение обычно приводят к таким проблемам.
Другое преимущество реляционных БД заключается в том, что они вынуждают вас пройти через процесс разработки модели данных. Если вы хорошо спроектировали модель, то база данных будет содержать логическую структуру, которая полностью отражает структуру хранимых данных, однако расходится со структурой приложения. Таким образом, данные становятся независимы от приложения. Это значит, что другое приложение сможет использовать те же самые данные и логика приложения может быть изменена без каких-либо изменений в модели базы. Чтобы проделать то же самое с хранилищем типа ключ-значение, попробуйте заменить процесс проектирования реляционной модели проектированием классов, при котором создаются общие классы, основанные на естественной структуре данных.
И не забудьте о совместимости. В отличие от реляционных БД, хранилища, ориентированные на использование в «облаке», имеют гораздо меньше общих стандартов. Хоть концептуально они и не отличаются, они все имеют разные API, интерфейсы запросов и свою специфику. Поэтому вам лучше доверять вашему вендору, потому что в случае чего, вы не сможете легко переключиться на другого поставщика услуг. А учитывая тот факт, что почти все современные хранилища типа ключ-значение находятся в стадии бета-версий2, доверять становится еще рискованнее, чем в случае использования реляционных БД.
Ограниченная аналитика данных
Обычно все облачные хранилища строятся по типу множественной аренды, что означает, что одну и ту же систему использует большое количество пользователей и приложений. Чтобы предотвратить «захват» общей системы, вендоры обычно каким-то образом ограничивают выполнение запросов. Например, в SimpleDB запрос не может выполняться дольше 5 секунд. В Google AppEngine Datastore за один запрос нельзя получить больше, чем 1000 записей3.
Эти ограничения не страшны для простой логики (создание, обновление, удаление и извлечение небольшого количества записей). Но что если ваше приложение становится популярным? Вы получили много новых пользователей и много новых данных, и теперь хотите сделать новые возможности для пользователей или каким-то образом извлечь выгоду из данных. Тут вы можете жестко обломаться с выполнением даже простых запросов для анализа данных. Фичи наподобие отслеживания шаблонов использования приложения или системы рекомендаций, основанной на истории пользователя, в лучшем случае могут оказаться сложны в реализации. А в худшем — просто невозможны.
В таком случае для аналитики лучше сделать отдельную базу данных, которая будет заполняться данными из вашего хранилища типа ключ-значение. Продумайте заранее, каким образом это можно будет сделать. Будете ли вы размещать сервер в облаке или у себя? Не будет ли проблем из-за задержек сигнала между вами и вашим провайдером? Поддерживает ли ваше хранилище такой перенос данных? Если у вас 100 миллионов записей, а за один раз вы можете взять 1000 записей, сколько потребуется на перенос всех данных?
Однако не ставьте масштабируемость превыше всего. Она будет бесполезна, если ваши пользователи решат пользоваться услугами другого сервиса, потому что тот предоставляет больше возможностей и настроек.
Облачные хранилища
Множество поставщиков веб-сервисов предлагают многопользовательские хранилища типа ключ-значение. Большинство из них удовлетворяют критериям, перечисленным выше, однако каждое обладает своими отличительными фичами и отличается от стандартов, описанных выше. Давайте взглянем на конкретные пример хранилищ, такие как SimpleDB, Google AppEngine Datastore и SQL Data Services.
Amazon: SimpleDB
SimpleDB — это атрибутно-ориентированное хранилище типа ключ-значение, входящее в состав Amazon WebServices. SimpleDB находится в стадии бета-версии; пользователи могут пользовать ей бесплатно — до тех пор пока их потребности не превысят определенный предел.
У SimpleDB есть несколько ограничений. Первое — время выполнения запроса ограничено 5-ю секундами. Второе — нет никаких типов данных, кроме строк. Все хранится, извлекается и сравнивается как строка, поэтому для того, чтобы сравнить даты, вам нужно будет преобразовать их в формат ISO8601. Третье — максимальные размер любой строки составляет 1024 байта, что ограничивает размер текста (например, описание товара), который вы можете хранить в качестве атрибута. Однако поскольку структура данных гибкая, вы можете обойти это ограничения, добавляя атрибуты «ОписаниеТовара1», «Описание товара2» и т.д. Но количество атрибутов также ограничено — максимум 256 атрибутов. Пока SimpleDB находится в стадии бета-версии, размер домена ограничен 10-ю гигабайтами, а вся база не может занимать больше 1-го терабайта.
Одной из ключевых особенностей SimpleDB является использование модели конечной констистенции (eventual consistency model). Эта модель подходит для многопоточной работы, однако следует иметь в виду, что после того, как вы изменили значение атрибута в какой-то записи, при последующих операциях чтения эти изменения могут быть не видны. Вероятность такого развития событий достаточно низкая, тем не менее, о ней нужно помнить. Вы же не хотите продать последний билет пяти покупателям только потому, что ваши данные были неконсистентны в момент продажи.
Google AppEngine Data Store
Google’s AppEngine Datastore построен на основе BigTable, внутренней системе хранения структурированных данных от Google. AppEngine Datastore не предоставляет прямой доступ к BigTable, но может восприниматься как упрощенный интерфейс взаимодействия с BigTable.
AppEngine Datastore поддерживает большее число типов данных внутри одной записи, нежели SimpleDB. Например, списки, которые могут содержать коллекции внутри записи.
Скорее всего вы будете использовать именно это хранилище данных при разработке с помощью Google AppEngine. Однако в отличии от SimpleDB, вы не сможете использовать AppEngine Datastore (или BigTable) вне веб-сервисов Google.
Microsoft: SQL Data Services
SQL Data Services является частью платформы Microsoft Azure. SQL Data Services является бесплатной, находится в стадии бета-версии и имеет ограничения на размер базы. SQL Data Services представляет собой отдельное приложение — надстройку над множеством SQL серверов, которые и хранят данные. Эти хранилища могут быть реляционными, однако для вас SDS является хранилищем типа ключ-значение, как и описанные выше продукты.
Необлачные хранилища
Существует также ряд хранилищ, которыми вы можете воспользоваться вне облака, установив их у себя. Почти все эти проекты являются молодыми, находятся в стадии альфа- или бета-версии, и имеют открытый код. С открытыми исходниками вы, возможно, будете больше осведомлены о возможных проблемах и ограничениях, нежели в случае использования закрытых продуктов.
CouchDB
CouchDB — это свободно распространяемая документо-ориентированная БД с открытым исходным кодом. В качестве формата хранения данных используется JSON. CouchDB призвана заполнить пробел между документо-ориентированными и реляционными базами данных с помощью «представлений». Такие представления содержат данные из документов в виде, схожим с табличным, и позволяют строить индексы и выполнять запросы.
В настоящее время CouchDB не является по-настоящему распределенной БД. В ней есть функции репликации, позволяющие синхронизировать данные между серверами, однако это не та распределенность, которая нужна для построения высокомасштабируемого окружения. Однако разработчики CouchDB работают над этим.
Проект Voldemort
Проект Voldemort — это распределенная база данных типа ключ-значение, предназначенная для горизонтального масштабирования на большом количестве серверов. Он родилась в процессе разработки LinkedIn и использовалась для нескольких систем, имеющих высокие требования к масштабируемости. В проекте Voldemort также используется модель конечной консистенции.
Mongo
Mongo — это база данных, разрабатываемая в 10gen Гейром Магнуссоном и Дуайтом Меррименом (которого вы можете знать по DoubleClick). Как и CouchDB, Mongo — это документо-ориентированная база данных, хранящая данные в JSON формате. Однако Mongo скорее является объектной базой, нежели чистым хранилищем типа ключ-значение.
Drizzle
Drizzle представляет совсем другой подход к решению проблем, с которыми призваны бороться хранилища типа ключ-значение. Drizzle начинался как одна из веток MySQL 6.0. Позже разработчики удалили ряд функций (включая представления, триггеры, скомпилированные выражения, хранимые процедуры, кэш запросов, ACL, и часть типов данных), с целью создания более простой и быстрой СУБД. Тем не менее, Drizzle все еще можно использовать для хранения реляционных данных. Цель разработчиков — построить полуреляционную платформу, предназначенную для веб-приложений и облачных приложений, работающих на системах с 16-ю и более ядрами.
Решение
В конечном счете, есть четыре причины, по которым вы можете выбрать нереляционное хранилище типа ключ-значение для своего приложения:
- Ваши данные сильно документо-ориентированны, и больше подходят для модели данных ключ-значение, чем для реляционной модели.
- Ваша доменная модель сильно объектно-ориентированна, поэтому использования хранилища типа ключ-значение уменьшит размер дополнительного кода для преобразования данных.
- Хранилище данных дешево и легко интегрируется с веб-сервисами вашего вендора.
- Ваша главная проблема — высокая масштабируемость по запросу.
Однако принимая решение, помните об ограничениях конкретных БД и о рисках, которые вы встретите, пойдя по пути использования нереляционных БД.
Для всех остальных требований лучше выбрать старые добрые реляционные СУБД. Так обречены ли они? Конечно, нет. По крайней мере, пока.
1 — по моему мнению, здесь больше подходит термин «структура данных», однако оставил оригинальное data model.
2 — скорее всего, автор имел в виду, что по своим возможностям нереляционные БД уступают реляционным.
3 — возможно, данные уже устарели, статья датируется февралем 2009 года.
habr.com
Реляционная база данных
Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных.
Каждая таблица в реляционной БД удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть множества таких значений. Любая таблица, удовлетворяющая этому условию, называется нормализованной. Фактически, ненормализованные таблицы, т.е. таблицы, содержащие повторяющиеся группы, даже не допускаются в реляционной БД.
Всякая нормализованная таблица автоматически считается таблицей в первой нормальной форме, сокращенно 1НФ. Таким образом, строго говоря, «нормализованная» и «находящаяся в 1НФ» означают одно и то же. Однако на практике термин «нормализованная» часто используется в более узком смысле
– «полностью нормализованная», который означает, что в проекте не нарушаются никакие принципы нормализации.
Теперь в дополнение к 1НФ можно определить дальнейшие уровни нор-
мализации – вторую нормальную форму (2НФ), третью нормальную форму
(3НФ)и т.д. По существу, таблица находится в 2НФ, если она находится в 1НФ
иудовлетворяет, кроме того, некоторому дополнительному условию, суть которого будет рассмотрена ниже. Таблица находится в 3НФ, если она находится в 2НФ и, помимо этого, удовлетворяет еще другому дополнительному условию
ит.д.
Таким образом, каждая нормальная форма является в некотором смысле более ограниченной, но и более желательной, чем предшествующая. Это связано с тем, что «(N+1)-я нормальная форма» не обладает некоторыми непривлекательными особенностями, свойственными «N-й нормальной форме». Общий смысл дополнительного условия, налагаемого на (N+1)-ю нормальную форму по отношению к N-й нормальной форме, состоит в исключении этих непривлекательных особенностей.
Теория нормализации основывается на наличии той или иной зависимости между полями таблицы. Определены два вида таких зависимостей: функ-
циональные и многозначные.
Функциональная зависимость. Поле В таблицы функционально зависит от поля А той же таблицы в том и только в том случае, когда в любой заданный момент для каждого из различных значений поля А обязательно существует только одно из различных значений поля В. Отметим, что здесь допускается, что поля А и В могут быть составными.
Полная функциональная зависимость. Поле В находится в полной функ-
циональной зависимости от составного поля А, если оно функционально зависит от А и не зависит функционально от любого подмножества поля А.
Многозначная зависимость. Поле А многозначно определяет поле В той
studfiles.net
Реляционные таблицы
Реляционная таблица (relational table) определяется фиксированным множеством своих столбцов. Типы данных, которые хранятся в столбцах, относятся к встроенным или определяемым пользователем типам (т.е. доменам). Таблица может содержать произвольное количество строк (или записей). Поскольку таблица есть не что иное, как математическое множество, повторяющиеся строки в таблице отсутствуют.
Для некоторых столбцов допускается, что значение столбца в определенной строке может принимать значение NULL. Значение NULL означает одну из двух возможностей: «не определенное в данный момент значение» или «неприменимое значение».
Одним из следствий требования к модели РБД, которое состоит в недопустимости дублирования строк, является наличие у каждой таблицы первичного ключа (primary key). Ключ — это минимальное множество столбцов (возможно один) таких, что значения в этих столбцах единственным способом идентифицируют одну строку в таблице. Таблица может содержать много подобных ключей. Один из этих ключей произвольным образом выбирается как наиболее важный- это первичный ключ, (primary key). Другие ключи называются потенциальными (candidate) или альтернативным (alternative) ключами.
На практике таблица СУРБД не обязана иметь ключ. Это значит, что таблица (без уникального ключа) может содержать идентичные строки — чудное бесполезное свойство реляционной базы данных, когда две строки, содержащие одинаковые значения во всех своих столбцах, никак нельзя отличить. В системах ОБД и ОРБД подобное различение обеспечивается за счет наличия OID (два объекта могут быть равными, но не идентичными, например, как две копии одной книги).
Хотя существует возможность ввести в UML стереотипы для моделирования реляционных баз данных, более удобно использовать специально предназначенные для этого диаграммные методы, позволяющие осуществить логическое моделирование реляционных баз данных.
На рис. 9 показана одна из подобных систем нотации. В качестве целевой базы данных здесь использовалась база данных DB2 копании IBM.
Рис. 9 Определение таблиц реляционной базы данных
Таблица Employee состоит из восьми столбцов. Последние три столбца допускают в качестве значений использование значения NULL. Столбец emp_id представляет собой первичный ключ. Столбцы {family_name, date_of_birth} определяют потенциальные (альтернативные) ключи. Столбец gender определен на домене Gender.
Поскольку на РБД накладывается ограничение, которое заключается в том, что столбцы могут принимать только атомические однократные значения, моделирование имени и телефонного номера работника вызывает у нас определенные затруднения. В предыдущем случае мы использовали два столбца : family_name и firstname. Столбцы не сгруппированы и никак не связаны в модели. В последнем случае мы предпочли решение с двумя столбцами (phone_numl, phone_num2), допускающими наличие максимум двух телефонных номеров у каждого работника.
После того, как таблица определена с помощью CASE-средств, можно автоматически сгенерировать программный код для создания таблицы, как показано ниже. Сгенерированный текст программы включает определение домена Gender и определение бизнес-правила, определенного на этом домене.
Задание: Выполнить системное проектирование программной системы. Обосновать выбор базы данных и выполнить ее проектирования.
Предоставить отчет, содержащий результаты системного проектирования и проектирования базы данных
Контрольные вопросы:
1. Объясните, в чем состоит различие между распределенной системой обработки и распределенной системой баз данных.
2. Что такое трехзвенная архитектура? В чем ее преимущества и недостатки?
3. Что такое доминантный класс?
4. Что такое отношение соединения?
5. Каковы различия между объектной и реляционной моделью БД?
studfiles.net
85.Реляционная схема таблиц. Логический и физический ключ реляционных отношений. Определение, назначение, пример.
Реляционная модель строится на основе отношений. Отношение- некоторое подмножество одного или более доменов. Домен- это некоторое множество, набор однородных значений. Если в структуру отношения добавить ограничения на возможные значения данных, то получается реляционная схема. Схема данных- имя отношения с перечнем столбцов и строк. Термин «ключ отношения» имеет различные значения на стадиях проектирования и реализации. Если в процессе проектирования под ключом понимается один или несколько столбцов, однозначным образом идентифицирующий картежи отношения, то на стадии реализации под ключом понимается столбец, на базе которого строится индекс с целью повышения эффективности обработки данных. Чтобы различить 2 значения ключа, употребляют термины «логический ключ» и «физический ключ». Логический ключ— это уникальный идентификатор. Физический ключ- столбец, на основе которого создается индекс или другая структура хранения с целью увеличения скорости обработки.
88. Язык описания данных реляционных таблиц (ddl). Структура этого языка.
Язык, который используется для описания структуры реляционных БД называется DDL (Data Definition Language).
В текстовом DDL-файле перечисляются название таблиц, имена столбцов этих таблиц, описано их содержание и указаны индексы. Структура БД может быть определена не только с помощью DDL в текстовом формате, но и представлена в графическом виде.
В состав языка DDL входят несколько базовых инструкций, обеспечивающих основной набор функций при создании реляционных таблиц и связей между ними.
CREATETABLE… — создать таблицу;
CREATEINDEX… — создать индекс;
ALTERTABLE… — изменить структуру ранее созданной таблицы;
DROP… — удалить существующую таблицу и базы данных.
В структуре инструкций CREATETABLEи ALTERTABLEважную роль играет предложение CONSTRAINT (создать ограничения на значения данных) со следующими установками — NOT NULL (не допускаются нулевые, точнее «пустые» значения по соответствующему полю, иначе говоря, определяется поле с обязательным заполнением), AUTOINC (поле с инкрементальным, т. е. последовательно возрастающим с каждой новой записью, характером значений) и PRIMARY KEY (определение для поля уникального, т. е. без повторов, индекса, что в результате задает режим заполнения данного поля с уникальными неповторяющимися по различным строкам значениями).
76.Идентификационно-зависимые сущности в модели «Сущность-связь». Определение, пример, графическая интерпретация.
В модели «Сущность-связь» имеется особый тип слабых сущностей, называемый идентификационно-зависимыми сущностями. Это такие сущности, идентификаторы которых содержат идентификатор другой сущности. Рассмотрим сущности ДОМ и КВАРТИРА. Пусть идентификатором сущности Дом является атрибут Название дома, а идентификатором сущности Квартира является композитный идентификатор {Название дома, Номер квартиры}. Поскольку идентификатор сущности Квартира содержит в себе идентификатор сущности Дом (Название дома), то сущность Квартира является идентификационно- зависимой от сущности Дом.
studfiles.net