Достоинства и недостатки теоретико-графовых моделей

Достоинства:

1. Развитое средство управления во внешней памяти на низком уровне.

2. Возможность построить вручную эффективные прикладные программы.

3. Возможность экономии памяти распределённой информации на объектах системы.

Недостатки:

1. Слишком сложно пользоваться.

2. Фактически необходимо знание о физической организации информации.

3. Логика СУБД перегружена деталями организации доступа к данным.

4. Модель «сущность-связь». (E/R) Основные понятия. Область применения.

Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области.

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

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (англ. entity-relationship diagram, ERD).

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

Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen Chen)[1], американским профессором компьютерных наук в университете штата Луизиана[2].

Нотации (графические диаграммы)[править | править вики-текст]

Нотация Питера Чена[править | править вики-текст]

Простая ER-модель MMORPG с использованием нотации Питера Чена

Множества сущностей изображаются в виде прямоугольников, множества отношений изображаются в виде ромбов. Если сущность участвует в отношении, они связаны линией. Если отношение не является обязательным, то линия пунктирная. Атрибуты изображаются в виде овалов и связываются линией с одним отношением или с одной сущностью.[3]

Crow's Foot[править | править вики-текст]

Пример отношения между сущностями согласно нотации Crow's Foot

Данная нотация была предложена Гордоном Эверестом (англ. Gordon Everest) под названием Inverted Arrow («перевёрнутая стрелка»), однако сейчас чаще называемая Crow's Foot («воронья лапка») или Fork («вилка»).[4]

Согласно данной нотации, сущность изображается в виде прямоугольника, содержащего её имя, выражаемое существительным.[5] Имя сущности должно быть уникальным в рамках одной модели. При этом, имя сущности — это имя типа, а не конкретного экземпляра данного типа. Экземпляром сущности называется конкретный представитель данной сущности.

Связь изображается линией, которая связывает две сущности, участвующие в отношении. Степень конца связи указывается графически, множественность связи изображается в виде «вилки» на конце связи. Модальность связи так же изображается графически — необязательность связи помечается кружком на конце связи. Именование обычно выражается одним глаголом[5] в изъявительном наклонении настоящего времени: «Имеет», «Принадлежит» и т. д.; или глаголом с поясняющими словами: «Включает в себя», и т.п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае, название левого конца связи указывается над линией связи, а правого – под линией. Каждое из названий располагаются рядом с сущностью, к которой оно относится.

Атрибуты сущности записываются внутри прямоугольника, изображающего сущность и выражаются существительным в единственном числе (возможно, с уточняющими словами). Среди атрибутов выделяется ключ сущности — неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности.[5]

5. Реляционная модель данных. Основные понятия. Область применения.

(Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка.

На реляционной модели данных строятся реляционные базы данных.

Реляционная модель данных включает следующие компоненты:

Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.

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

Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).

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

Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни «плоскими», ни «неплоскими».

Для лучшего понимания РМД следует отметить три важных обстоятельства:

модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;

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

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

Принципы реляционной модели были сформулированы в 1969—1970 годах Э. Ф. Коддом (E. F. Codd). Идеи Кодда были впервые публично изложены в статье «A Relational Model of Data for Large Shared Data Banks»[1][2], ставшей классической.

Строгое изложение теории реляционных баз данных (реляционной модели данных) в современном понимании можно найти в книге К. Дж. Дейта. «C. J. Date. An Introduction to Database Systems» («Дейт, К. Дж. Введение в системы баз данных»).

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

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

(Отношения и таблицы

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

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

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

Пример реляционной таблицы приведен на рисунке 4.17.

Рис. 4.17. Реляционная таблица

Мы уже установили, что состояние отношения определяется набором входящих в него кортежей. Ещё раз отметим, что состояние отношения в реляционной теории не рассматривается. Пример состояния отношения "Сотрудники":

Ниже приведен пример нереляционной таблицы с двумя шапками, верхней и боковой:

Самостоятельно преобразуйте её в реляционную таблицу.

Основные отличия таблиц от отношений:

· В отношении нет одинаковых кортежей. Таблицы без первичного ключа могут содержать одинаковые строки. Если, например, в таблице "сотрудник" выбирается единственный столбец "но-мер_отдела", то в таблице-результате часть строк будет повторена. Устранение повторов может изменить смысл полученного результата.

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

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

· Отношения не имеют метрических свойств. Для таблиц они важны. Размеры столбцов и число строк определяют быстродействие запросов и инструкций манипуляции данными.

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

Таблица 4.2. Соответствие терминов реляционной и табличных моделей
Термин реляционной модели	Термин табличной модели
Схема базы	Схема базы
	Создание схемы базы
	Ввод строки
	Обновление строки
	Удаление строки
Отношение	Таблица (реляционного типа)
Заголовок отношения	Заголовок таблицы
Тело отношения	Тело таблицы
Атрибут отношения	Столбец таблицы
Кортеж отношения	Строка таблицы
Арность отношения	Количество столбцов
Типы данных и домены	Типы данных и домены
	Ширина столбца
	Количество строк
	Размер таблицы
	Время исполнения

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

7. Понятие БД, СУБД, реляционные БД и их объектов.

Дата добавления: 2015-05-09