- Классификация субд по типу модели представления данных.

1) по характеру использования :

- однопользовательские, персональные

- многопользовательские

2) по масштабу :

- однопользовательские

- групповые (офисные)

- корпоративные (к примеру, Oracle, Microsoft SQL Server и т.п.)

3) по характеру представления (по содержанию):

- документальные (хранится символьная и текстовая информация)

- фактографические (хранится цифровая информация)

- мультимедийные

4) по виду программного обеспечения :

- полнофункциональные

- сервер

- клиент

5) по модели представления данных :

Исторически сложились3 классические модели:

- иерархическая модель

- сетевая

- реляционная (с 1970 г. Oracle).

Позже появились:

- объектно-ориентированные СУБД

- объектно-реляционные СУБД (постреляционные…)

- многомерные БД

6) по назначению:

- транзакционные базы данных (OLTP) – их большинство…

- хранилища данных (DW (Data Warehouse) – исключены операции удаления и модификации данных. (Для того чтобы заполнять DW, надо делать фильтрацию данных).

- Виды функциональных зависимостей.

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

Утверждение, что В функционально зависит от А, означает то же самое, что А однозначно определяет В, т. е. если в какой-то момент времени известно значение А, то можно получить и значение В.

Функциональная зависимость обозначается стрелкой А  В.

Понятие ФЗ аналогично понятию функции в математике и отражает смысловую (семантическую) взаимосвязь соответствующих атрибутов сущности.

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

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

Если неключевой атрибут зави­сит только от части составного ключа, то говорят о частичной функциональной зависимости атрибута от составного ключа.

Если атрибут В зависит от атрибута А, а С зависит от атрибута В, но обратная зависимость отсутствует, то говорят, что атрибут С зависит от А транзитивно.

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

- Термины реляционной модели.

Реляционная модель данных была предложена в 1969 – 1970 годах Е.Ф.Коддом (E.F.Codd), известным исследователем в об­ласти баз данных, работавшим тогда в корпорации IBM. Согласно Кодду, реляционная база данных представляет собой хранилище данных, содержащее набор двумерных таблиц. Набор средств для управления подоб­ным хранилищем называется реляционной системой управле­ния базами данных (РСУБД).

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

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

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

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

Пусть D1, D2 ,…, Dk – произвольные конечные и не обязательно различные множества (домены). Декартово произведение этих множеств определяется следующим образом:

D₁×D₂×...×D_k = {(d₁, d₂,...,d_k | d_i  D_i, i=1,...,k)}

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

Отношением называется подмножество декартова произведения доменов; его элементами являются упорядоченные n-кортежи вида <d1, d2,…, d_k >.

Отношение (таблица) содержит данные о сущностях (объектах) определённого типа.

Элементы отношения называют кортежами (или записями). Каждый кортеж отношения соответствует одному экземпляру сущности определённого типа. Элементы кортежа принято называть атрибутами (или полями) – их значения образуют столбцы таблицы и определяют характеристику или свойство сущности (объекта).

Действующее количество кортежей (записей) называется мощностью или кардинальным числом отношения.

Количество атрибутов в отношении называется степенью отношения.

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

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

Термины реляционной модели	Термины «табличные» и языка SQL	Термины обработки данных
Отношение	Таблица	Файл
Кортеж	Строка	Запись
Атрибут	Столбец	Поле
Домен	Множество допустимых значений	Базовый или пользовательский тип данных (с условиями)
Мощность (кардинальность) отношения	Количество строк	Количество записей
Степень отношения	Количество столбцов	Количество полей

Е.Ф.Кодд предложил следующие принципы, определяющие структуру базы данных реляционной модели:

1) каждое значение на пересечении строки и столбца должно быть атомарным (скалярным);

2) значения данных в одном и том же столбце должны принадлежать одному и тому же типу;

3) каждый кортеж (запись) в таблице уникален; отношения не содержат идентичных кортежей;

4) каждый атрибут (поле) имеет уникальное имя (обычно в пределах одного отношения);

5) последовательность атрибутов в отношении не определена (на практике в СУБД их порядок фиксируется);

6) последовательность кортежей в отношении не определена.

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

Логические связи в реляционной модели.

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

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

Выделяют три разновидности связи между таблицами базы данных:

• "один–ко–многим";

• "один–к–одному";

• "многие–ко–многим".

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

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

Отношение "многие–ко–многим" применяется в следующих случаях:

• одной записи в родительской таблице соответствует более одной записи в дочерней;

• одной записи в дочерней таблице соответствует более одной записи в родительской.

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

Виды ключей в реляционной модели данных. Первичные и внешние ключи.

Для идентификации кортежей (записей) используются ключи.

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

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

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

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

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

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

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

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

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

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

Логические части реляционной модели; ограничения целостности.

Реляционную модель можно рассматривать как состоящую из трех частей:

• структурной;

• манипуляционной;

• целостной.

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

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

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

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

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