Концептуальные и физические er-модели

Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы. Это означает, что диаграмма не учитывает особенности конкретной СУБД. По данной концептуальной диаграмме можно построить физическую диаграмму, которая уже будут учитываться такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п. Физический вариант диаграммы, приведенной на Рис. 9 может выглядеть, например, следующим образом:

Рис. 10

На данной диаграмме каждая сущность представляет собой таблицу базы данных, каждый атрибут становится колонкой соответствующей таблицы. Обращаем внимание на то, что во многих таблицах, например, "CUST_DETAIL" и "PROD_IN_SKLAD", соответствующих сущностям "Запись списка накладной" и "Товар на складе", появились новые атрибуты, которых не было в концептуальной модели - это ключевые атрибуты родительских таблиц, мигрировавших в дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей.

Лекция №4 Реляционная модель данных

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

Не все таблицы являются отношениями. Чтобы таблица стала отношением она должна соответствовать следующим условиям:

• Каждый столбец имеет уникальное имя. Порядок столбцов в таблице не существенен.

• В таблице не может быть одинаковой записи. Порядок записей в таблице не существенен.

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

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

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

Типы данных бывают простые, составные и ссылочные.

Простые, или атомарные, типы данных не обладают внутренней структурой. К простым типам данных относятся следующие типы:

• Логический.

• Строковый.

• Численный.

Различные языки программирования могут расширять и уточнять этот список, добавляя такие типы как:

• Целый.

• Вещественный.

• Дата.

• Время.

• Денежный.

• Перечислимый.

• Интервальный.

• И т.д.…

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

• Массивы

• Записи (Структуры)

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

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

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

• Домен имеет уникальное имя (в пределах базы данных).

• Домен определен на некотором простом типе данных или на другом домене.

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

• Домен несет определенную смысловую нагрузку.

Например, домен  , имеющий смысл "возраст сотрудника" можно описать как следующее подмножество множества натуральных чисел:

Если тип данных можно считать множеством всех возможных значений данного типа, то домен напоминает подмножество в этом множестве.

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

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

Таблица – отношение Таблица не является отношением:

Функциональная зависимость – это связь между атрибутами. Если мы знаем значение одного атрибута, то мы можем найти и значений второго атрибута, тогда говорят, что второй атрибут функционально зависит от первого атрибута. Например, если мы знаем номер счета клиента, то мы можем определить и состояние этого счета. В таком случае мы скажем, что атрибут СостояниеСчетаКлиента функционально зависит от атрибута НомерСчетаКлиента.

Еще пример, каждому студенту присвоен уникальный номер, у каждого студента имеется одна и только одна специальность. Имея номер студента мы можем узнать его специальность. Поэтому мы говорим, что атрибут Специальность функционально зависит от атрибута НомерСтудента. Или же атрибут НомерСтудента функционально определяет атрибут Специальность. Атрибут, который функционально определяет другие атрибуты называется детерминантом. В нашем примере это НомерСтудента.

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

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

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

Каждое отношение имеет минимум один ключ.

Атрибут Секция в этом примере функционально определяет атрибут Плата, но не является ключом.