Реляционная модель — студенческий портал

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

Таблица как важная часть реляционной БД

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

Таблицы в таких БД обладают следующими свойствами:
— столбцы размещаются в определённом порядке, формируемом при создании таблицы. Таблица может не иметь ни одной строки, однако хотя бы один столбец должен быть обязательно;
— в таблице не может быть 2-х одинаковых строк. Если вспомнить математику, то такие таблицы называют отношениями (relation).

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

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

Приведём пример

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

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

Ключи в БД

Первичный ключ (РК, primary key) — столбец, значения которого различны во всех строках. РК бывают логические (естественные) и суррогатные (искусственные).

Например, для таблицы «Пользователи» первичным ключом может быть столбец e-mail, т. к. не бывает 2-х пользователей с одним и тем же e-mail.

На практике для хранения и обработки данных рекомендуют применять суррогатные ключи (их использование позволит абстрагировать РК от реальных данных). Это важно, если пользователь, вдруг, сменит e-mail, а ведь первичные ключи нельзя менять.

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

Вносим первичные ключи в наши таблицы:

Теперь становится ясно, что сообщение id=2 относится к теме «О рыбалке» (id=4), которая создана Васей, а остальные принадлежат теме «О рыбалке», созданной Кириллом (id=1).

Такое поле будет называться внешний ключ (FK, foreign key). При этом каждое значение данного поля сопоставляется с каким-либо первичным ключом из таблицы «Темы».

В результате устанавливается однозначное соответствие между темами и сообщениями.

Итак, наша база данных фактически готова. Схематично она выглядит так:

В этой небольшой базе данных лишь 3 таблицы. А что делать, если их 10 либо 200? Ясно, что всё не так просто. Именно поэтому любое проектирование реляционных баз данных начинается с разработки концептуальной модели данных.

Концептуальная модель базы данных

Под концептуальной моделью понимают отражение предметной области для разрабатываемой базы данных. Если не вдаваться в теорию, то речь идёт о некой диаграмме с общепринятыми обозначениями:
— вещи обозначаются прямоугольниками;
— атрибуты объекта овалами;
— связи в таблицах ромбами;
— мощность и направление связей стрелками (одинарными, двойными).

Простой пример — интернет-магазин. В нём есть товары, поставляемые поставщиками и заказываемые покупателями. Это три объекта и две связи:

Делая поставку, поставщик подтверждает её документами. Аналогично и с покупателем. Таким образом, и поставку, и покупку можно рассматривать в качестве самостоятельных объектов.

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

Видим, что в структуре появились ещё 2 объекта — «Журнал поставок» и «Журнал покупок» со связями типа «один ко многим» (каждый журнал может включать несколько поставок/покупок, но каждая поставка/покупка включает лишь один журнал).

Атрибуты таблицы

Каждый объект интернет-магазина имеет свои атрибуты:

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

Собственно, при обширной предметной области данные лучше разбить на несколько локальных областей. Как правило, объём должен быть в пределах 5-7 объектов. И лишь после создания локальных моделей выполняется их объединение в общую сложную схему.

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

Проектирование реляционной базы данных. Преобразование модели в реляционную

Преобразование концептуальной модели данных в реляционную — важная часть проектирования БД. Процесс включает в себя:
— построение набора предварительных таблиц;
— указание РК;
— выполнение нормализации.

Из набора таблиц состоят наши объекты, а из полей таблиц — атрибуты объектов:

Итак, мы определились с таблицами, полями, РК и FK. Следует отметить, что в таблицах «Журнал покупок» и «Журнал поставок» РК составные, т. к. состоят из 2-х полей.

Что касается нормализации, то под ней понимают обратимый и пошаговый процесс, при котором исходная схема меняется другой схемой, в которой таблицы характеризуются более простой и логичной структурой. Это нужно по следующим причинам:
1. Устранение избыточности данных. Вспомним нашу таблицу:

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

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

Пример аномалии модификации — чтобы поменять название темы, нам придётся смотреть все строки и менять название в каждой из них.

Нормализация бывает:
— 1-й нормальной формы (1НФ);
— 2НФ;
— 3НФ;
— НФБК (нормальной формы Бойса-Кодда);
— 4НФ;
— 5НФ.

Если говорить о реляционных базах данных, то минимум — это 1НФ.

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

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

Итак, в процессе проектирования мы преобразовали концептуальную модель в реляционную. Следующий этап — реализация её в конкретной СУБД. Для этого потребуется как сама СУБД, так и знание языка SQL. Например, прекрасно подойдёт СУБД MySQL или какая-нибудь другая СУБД.

Подводим итоги проектирования

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

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

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

В заключение, добавим, что умение проектировать базы вам никогда не помешает. А научиться всему этому вы сможете на нашем курсе «Реляционные СУБД». Ждём вас!

Источник: https://otus.ru/nest/post/589/

IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов

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

Продолжаем рубрику Заметки о MySQL, в которой я уже успел рассмотреть установку и настройку MySQL сервера баз данных, а также рассмотрел способы изменения кодировок сервера MySQL при помощи команды SET NAMES и файла конфигураций my.ini.

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

В этой статье я постараюсь изложить кратко какие виды и типы баз данных бывают и остановлюсь на некоторых из них более подробно.

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

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

База данных. Математические модели, структура, определение

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

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

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

Более подробно обо всем этом читайте в рубрике Заметки о XML и XLST.

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

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

Иерархическая база данных, структура иерархических баз данных

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

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

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

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

Сетевая база данных, структура сетевых баз данных

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

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

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

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

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

А в рубрике посвященной MySQL нас интересуют реляционные базы данных, на которых мы и остановимся более подробно.

Реляционные базы данных, структура реляционных баз данных

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

Был когда-то такой математик – Эдгар Франк Кодд, умерший в 2003 году, который в восьмидесятых годах очень подробно описал структуру реляционных баз данных математическим языком.

А если есть хорошо написанная математика, то соответственно есть и программная реализация. Останавливаться на биографии Э.Ф. Кодда я не буду, для этого есть различные энциклопедии. Именно благодаря Кодду реляционные базы данных стали активно развиваться.

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

Особенности реляционных баз данных

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

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

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

Или иначе MySQL – это программное воплощение математических идей.

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

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

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

Хотя MySQL сервер всегда можно настроить.

Проектирование базы данных

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

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

1. База данных должна быть как можно более компактна, то есть, неизыбыточна.
2. База данных должна быть простой с точки зрения обработки.

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

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

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

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

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

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

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

На этом всё, спасибо за внимание, надеюсь, что был хоть чем-то полезен и до скорых встреч на страницах блога для начинающих вебразработчиков и вебмастеров ZametkiNaPolyah.ru 

Источник: https://zametkinapolyah.ru/zametki-o-mysql/bazy-dannyx-vidy-i-tipy-baz-dannyx-struktura-relyacionnyx-baz-dannyx-proektirovanie-baz-dannyx-setevye-i-ierarxicheskie-bazy-dannyx.html

GOUSPO студенческий портал! » Взаимосвязи в моделях и реляционный подход к построению модели

admin

1. Основные операции реляционной алгебры.

Методы и алгоритмы обработки информации в реляционных базах данных основываются на теории реляционной алгебры, кото­рую ранее называли алгеброй логики, или булевой алгеброй.

Алгебра логики представляет собой прежде всего алгебру выс­казываний.

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

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

Запись А = 1 и С = 0 означает, что А истинно и что С ложно. Каждое конкретное высказывание имеет вполне определенное значение истинности — это постоянная, рав­ная 0 или 1. От конкретных (постоянных) высказываний следует отличать так называемые переменные высказывания.

Переменное высказывание — это не высказывание в подлинном смысле, а переменная для высказываний (пропозициональная пе­ременная), т.е.

символ, вместо которого можно подставить посто­янные высказывания (или их наименования) и который может принимать лишь два значения: «истинно» или «ложно», или соот­ветственно 1 и 0 (двоичная переменная). Переменные высказыва­ния (т.е.

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

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

Объединение про­стых высказываний в сложные в алгебре логики производится без учета внутреннего содержания (смысла) этих высказываний.

Ис­пользуются определенные логические операции (или логические связи), позволяющие объединять некоторые данные высказыва­ния (постоянные или переменные) в более сложные (постоянные или переменные).

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

Отрицание высказывания. Отрицание высказывания А — это высказывание, которое истинно, когда А ложно, и ложно, когда А истинно; обозначается: А; читается: «не А».

Конъюнкция двух высказываний.

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

Конъюнкция двух высказываний обозначается: А В; чи­тается «А и В». Знак конъюнкции «» имеет смысл союза «и». Опе­рация конъюнкции имеет также смысл логического умножения и может обозначается знаком «&».

Значения истинности операции конъюнкции А В АВ 1 1 1 1 1

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

Операция дизъюнкции обозначается: AB; читается: «А или В» (другое обозначение: А + В; другое название — «логическое сложение»).

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

Знак «» может иметь смысл «или», употребленный, например, в фразе: «При звоне будиль­ника Петя или Ваня проснется» (здесь «или» не исключает воз­можности того, что проснутся оба). В данном случае дизъюнкция имеет смысл неразделительного «или».

Значения истинности операции дизъюнкции А В AB 1 1 1 1 1 1 1

Эквивалентность двух высказываний.

Эквивалентность двух выс­казываний — это сложное высказывание, истинное тогда, когда значения истинности составляющих высказываний одинаковы, и ложное — в противном случае; обозначается: А  В; читается: «А эк­вивалентно В». Для эквивалентности справедливы высказывания, которые можно записать следующим образом: A 1 = А, что озна­чает: А эквивалентно единице, когда А истинно.

Запись А  0 = А означает, что А эквивалентно нулю, когда А ложно.

Отрицание эквивалентности.

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

Отрицание эквивалентно­сти означает, что А не эквивалентно В. Эта операция имеет важное значение в теории проектирова­ния ЭВМ, так как она представляет собой так называемое сложе­ние двоичных чисел по модулю два.

Импликация двух высказываний. Импликация двух высказыва­ний обозначается: A В; читается: «если А, то В». Это такое слож­ное высказывание, которое ложно только в том случае, когда А истинно, а В ложно.

Импликация не предполагает обязательную связь по смыслу между условием А и следствием В, хотя и не исключает такую связь. Смысл импликации можно выра­зить следующим образом: «А ложно или В истинно».

В этом выражении союз «или» имеет не исключающее значение.

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

2. Реляционный подход к построению модели данных.

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

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

Основоположником теории реляционных баз данных считается сотрудник фирмы IBM доктор Э. Ф. Кодд, опубликовавший 6 июня 1970 г. статью «Реляционная модель данных для больших коллек­тивных банков данных. В этой статье впервые и был использован термин «ре­ляционная модель данных», что и положило начало реляцион­ным базам данных.

Теория реляционных баз данных, разработанная в 1970-х гг. в США доктором Э. Ф. Коддом, опиралась на математический аппарат те­ории множеств.

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

Таким образом, реляционная БД представляет собой инфор­мацию (данные) об объектах, представленную в виде двумерных массивов — таблиц, объединенных определенными связями. База данных может состоять и из одной таблицы.

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

Таблица состоит из следующих элементов: поле, ячейка, запись.

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

Поля (столбцы)

Ячейка содержит конкретное значение соответствующего поля (признака одного объекта).

Запись — строка таблицы. Она содержит значения всех призна­ков, характеризующих один объект. Число записей (строк) соот­ветствует числу объектов, данные о которых содержатся в таб­лице.

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

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

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

Термины реляционных баз данных

Теория БД	Реляционные СУБД(FoxPro, Microsoft Access)	SQL Server 7.0
Отношение (Relation)	Таблица (Table)	Таблица (Table)
Атрибут (Attribute)	Поле (Field)	Колонка (Column)
Кортеж (Tuple)	Запись (Record)	Строка (Row)

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

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

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

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

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

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

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

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

Например, если в качестве первичного ключа выбрать идентификационный номер нало­гоплательщика, то номер паспорта будет альтернативным клю­чом.

3. Типы взаимосвязей в модели: «один-к-одному», «один-ко-многим» и «многие-ко-многим».

• Между таблицами устанавливаются следующие типы связей: «один к одному»; «один ко многим»; «многие ко многим»:
• •  связь «один к одному» устанавливается в случаях, когда конкретная строка главной таблицы в любой момент времени связана только с одной строкой подчиненной таблицы;
• •  связь «один ко многим» устанавливается в случаях, когда конкретная строка главной таблицы в любой момент времени связана с несколькими строками подчиненной таблицы; при этом любая строка подчиненной таблицы связана только с од­ной строкой главной таблицы;
• • связь «многие ко многим» устанавливается в случаях, ког­да конкретная строка главной таблицы в любой момент време­ни связана с несколькими строками подчиненной таблицы и в то же время одна строка подчиненной таблицы связана с не­сколькими строками

Источник: http://gouspo.ru/?p=207

SQL и NoSQL: разбираемся в основных моделях баз данных

Перевод статьи «Understanding SQL And NoSQL Databases And Different Database Models»

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

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

) и их новые реализации (MySQL, PostgreSQL, MongoDB, Redis и т.д.). В этой статье мы разберемся в основах баз данных и СУБД. 

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

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

СУБД основаны на моделях баз данных — определённых структурах для обработки данных. Каждая СУБД создана для работы с одной из них с учётом особенностей операций над информацией.

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

Модели баз данных

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

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

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

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

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

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

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

Безмодельный (NoSQL) подход

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

Популярные СУБД

В этой статье мы опишем вам парадигмы основных решений для работы с базами данных. Хотя точные числа привести очень сложно, в большинстве случаев выбор делается в пользу реляционной модели или NoSQL. Прежде чем мы сравним их, давайте узнаем, что находится “под капотом” у каждой из них.

РСУБД

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

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

Самыми популярными РСУБД сейчас являются:

• SQLite: очень мощная встраиваемая РСУБД.

• MySQL: самая популярная и часто используемая РСУБД.

• PostgreSQL: самая продвинутая и гибкая РСУБД.

NoSQL-СУБД

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

В отличие от традиционных РСУБД, некоторые базы данных NoSQL, например, MongoDB, позволяют группировать коллекции данных с другими базами данных. Такие СУБД хранят данные как одно целое. Эти данные могут представлять собой одиночный объект наподобие JSON и вместе с тем корректно отвечать на запросы к полям.

NoSQL базы данных не используют общий формат запроса (как SQL в реляционных базах данных). Каждое решение использует собственную систему запросов.

Сравнение SQL и NoSQL

Для того, чтобы прийти к простому и понятному выводу, давайте проанализируем разницу между SQL- и NoSQL-подходами:

• Структура и тип хранящихся данных: SQL/реляционные базы данных требуют наличия однозначно определённой структуры хранения данных, а NoSQL базы данных таких ограничений не ставят.

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

• Масштабируемость: оба решения легко растягиваются вертикально (например, путём увеличения системных ресурсов). Тем не менее, из-за своей современности, решения NoSQL обычно предоставляют более простые способы горизонтального масштабирования (например, создания кластера из нескольких машин).

• Надёжность: когда речь заходит о надёжности, SQL базы данных однозначно впереди.

• Поддержка: РСУБД имеют очень долгую историю. Они очень популярны, и поэтому получить поддержку, платную или нет, очень легко. Поэтому, при необходимости, решить проблемы с ними гораздо проще, чем с NoSQL, особенно если проблема сложна по своей природе (например, при работе с MongoDB).

• Хранение и доступ к сложным структурам данных: по своей природе реляционные базы данных предполагают работу с сложными ситуациями, поэтому и здесь они превосходят NoSQL-решения.

Источник: https://tproger.ru/translations/sql-nosql-database-models/

iMath Wiki — Основные понятия реляционной теории баз данных. Формализация отношений

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

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

СУБД общего назначения должна позволять определение, создание, изменение, администрирование и произведение запросов к БД.

В качестве примеров СУБД можно назвать такие широко известные пакеты, как

• MySQL
• PostgreSQL
• Microsoft SQL Server
• Oracle
• IBM DB2
• Microsoft Access
• SQLite

Базы данных обычно не являются переносимыми между различными СУБД, однако возможно взаимодействие между СУБД (и с пользовательским ПО) с использованием различных стандартов, таких, как SQL, ODBC или JDBC.

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

Итак, основные задачи, выполняемые СУБД включают

Определение схемы данных
Создание, изменение и удаление структур, которые определяют организацию всех остальных данных в БД

Изменение данных
Добавление, изменение и удаление самих данных

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

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

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

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

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

Хотя, безусловно, приемы проектирования БД общие для всех применений.

Модели БД

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

• Иерархическая, или навигационная модель
• Сетевая модель

Иерархическая модель широко использовалась в СУБД, поставляемых компанией IBM в 1960х. Основная идея заключается в том, что запись в такой БД может иметь несколько “дочерних” и одну “родительскую”. В целом, это подозрительно похоже на иерархическую файловую систему. Чтобы получить запись в такой БД, часто необходим проход по всему дереву.

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

В 1970х Эдгаром Коддом (сотрудник IBM) была предложена реляционная модель, которая значительно облегчила задачу поиска информации в БД. О реляционной модели можно думать как о “таблицах”, в которых “строки” – это записи в БД.

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

На основе предложений Кодда к середине 1970х была разработана СУБД System R, а к концу в ней появилась поддержка стандартизованного языка запросов SQL.

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

Примерами реализации NoSQL подхода могут быть т.н. документо-ориентированные БД, построенные на основе XML. Основное преимущество NoSQL – высокая горизонтальная масштабируемость, т.е. возможность увеличивать производительность за счет добавления серверов.

С появлением облачных технологий, NoSQL стал особенно востребован.

Тем не менее, реляционная модель пока остается самой распространенной, поэтому более подробно остановимся именно на ней.

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

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

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

Введем некоторые определения.

Домен
Множество, содержащее полный набор всех возможных значений некоторой переменной. Домены часто так же называют типом данных.

Атрибут
Упорядоченная пара названия атрибута и домена (D_j).

Кортеж
Конечное упорядоченное множество ((d_1, d_2, ldots, d_n))

Заголовок (схема) отношения
Кортеж ((A_1, A_2, ldots, A_n)), где (A_j) – атрибуты.

Значение атрибута
Конкретное значение, принадлежащее домену атрибута.

Тело отношения
Множество кортежей ((d^i_1, d^i_2, ldots, d^i_n)), где (d^i_j in D_j), (D_j) – домены.

Запись
Кортеж ((d^i_1, d^i_2, ldots, d^i_n)) при фиксированном (i).

Отношение
Совокупность заголовка отношения и тела отношения.

Схема базы данных
Множество схем всех отношений, входящих в БД.

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

(d^1_1)	(d^1_2)	(ldots)	(d^1_n)	← Запись
(d^2_1)	(d^2_2)	(ldots)	(d^2_n)	← Запись
(ldots)	(ldots)	(ldots)	(ldots)	← Запись
(d^m_1)	(d^m_2)	(ldots)	(d^m_n)	← Запись

Реляционная модель налагает следующие дополнительные требования на отношения:

• Атрибуты имеют фиксированный тип данных (домен)
• Значения атрибутов атомарны1
• Записи уникальны
• Порядок записей не имеет значения (нет скрытых атрибутов)
• Порядок атрибутов не имеет значения (нет скрытых зависимостей атрибутов)

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

Функциональная зависимость
множество атрибутов (B) функционально зависит от множества атрибутов (A) (записывается (A
ightarrow B)), если для любых двух записей, имеющих одинаковые значения (A), их значения (B) совпадают. Иначе, каждому значению (A) соответствует единственное значение (B) (не обязательно уникальное, именно единственное).

Иными словами, если некоторый набор атрибутов (A) однозначно определяет (в рамках данного отношения) значения атрибутов (B), то (B) функционально зависит от (A).

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

Для них, значение функции функционально зависит от всех аргументов одновременно. Скажем, для функции (z = f(x,y)) выполняется ФЗ ((x,y) o z), или сокращенно, (xy o z).

Отношения в данном контексте можно рассматривать как некие табличные или дискретные функции.

Работа с ФЗ

Существуют определенные формальные правила работы с ФЗ отношения.

Формальные правила тесно связаны с понятиями замыкания и неприводимой ФЗ.

Аксиомы Армстронга

Существуют правила вывода новых ФЗ из существующих, называемые аксиомами Армстронга.

Аксиомы Армстронга

1. Правило рефлексивности: если (B subset A), то (A
   ightarrow B)
2. Правило дополнения: если (A
   ightarrow B), то (AC
   ightarrow BC)
3. Правило транзитивности: если (A
   ightarrow B) и (B
   ightarrow C), то (A
   ightarrow C)

Из этих аксиом так же могут быть выведены следующие дополнительные правила:

1. Правило самоопределения: (A
   ightarrow A)
2. Правило декомпозиции: Если (A
   ightarrow BC), то (A
   ightarrow B) и (A
   ightarrow C)
3. Правило объединения: Если (A
   ightarrow B) и (A
   ightarrow C), то (A
   ightarrow BC)
4. Правило композиции: Если (A
   ightarrow B) и (C
   ightarrow D), то (AC
   ightarrow BD)

Можно заметить, что, вследствие правила рефлексивности, любое множество атрибутов (A) подразумевает ФЗ вида (A o A). Такие ФЗ, а так же следующие из них, не представляют интереса, и называются тривиальными.

Тривиальная функиональная зависимость
ФЗ (A o B), такая, что (B subset A).

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

Замыкание множества ФЗ
Замыканием множества ФЗ называется такое множество ФЗ, которое включает все ФЗ исходного множества, а так же все подразумеваемые ими. Другими словами, для отношения (R), обладающего функциональными зависимостями (S), замыканием (S^+) называется множество всех ФЗ, возможных для (R), исходя из (S).

Как правило, требуется установить, будет ли некая ФЗ (X
ightarrow Y) следовать из данного множества ФЗ (S). Оказывается, это возможно тогда и только тогда, когда множество атрибутов (Y) является подмножеством замыкания атрибутов (X^+) в (S).

Замыкание атрибутов
Замыканием (X^+) атрибутов (X) по множеству ФЗ (S) называется множество всех атрибутов, которые функционально зависят от какого-либо подмножества (X).

Для вычисления замыкания множества атрибутов (X^+) по множеству ФЗ (S) существует следующее правило: для каждой ФЗ (A
ightarrow B) в (S), если (A subset X^+), то и (B subset X^+), причем достаточно начать с предположения, что (X^+ = X).

Следует заметить, что для любого замыкания (X^+), существуют ФЗ вида (X o B), где (B subset X^+), таким образом, замыкания всех атрибутов отношения по его ФЗ описывают замыкание ФЗ этого отношения.

Это правило используется для вычисления неприводимого множества ФЗ, эквивалентного данному (в смысле эквивалентности их замыканий). Уменьшение количества ФЗ при сохранении замыкания (и, следовательно, внутренней логики, описываемой ФЗ) является важным шагом в проектировании БД.

Множество ФЗ называется неприводимым, если:

1. Правая часть каждой ФЗ содержит только один элемент
2. Ни один атрибут ни одной левой части ФЗ множества не может быть удален без изменения замыкания
3. Ни одна ФЗ множества не может быть удалена без изменения замыкания.

Для любого множества ФЗ существует хотя бы одно эквивалентное неприводимое множество. Такое множество называется минимальным покрытием.

Источник: https://wiki.livid.pp.ru/students/dbms/lectures/1.html