Для специальности 5В073200 «Стандартизация, сертификация и метрология»



страница2/10
Дата06.06.2016
Размер1.01 Mb.
ТипЛекция
1   2   3   4   5   6   7   8   9   10

Реляционное исчисление


Реляционное исчисление основано на логике первого порядка. Если два варианта реляционного исчисления:

  • The Исчисление доменов (DRC), где переменными являются элементы (атрибуты) кортежа.

  • The исчисление кортежей (TRC), где переменными являются кортежи.

Мы хотим обсудить исчисление кортежей потомучто оно лежит в основе большинства реляционных языков. Подробное обсуждение DRC (и также TRC) смотри у [Дейта, 1994 год] или [Ullman, 1988 год].

Исчисление кортежей


Запросы, использующие TRC, представлены в следующем виде: x(A) ∣ F(x) где x - это переменная кортежа, A - это множество атрибутов и F - формула. Результирующие отношение состоит из всех кортежей t(A), которые удовлетворяют F(t).

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

{x(SNAME) ∣ x ∈ SUPPLIER ∧ nonumber

∃ y ∈ SELLS ∃ z ∈ PART (y(SNO)=x(SNO) ∧ nonumber

z(PNO)=y(PNO) ∧ nonumber

z(PNAME)='Screw')} nonumber

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

Реляционная алгебра и реляционное исчисление


Реляционная алгебра и реляционное исчисление имеют одинаковую выражающую мощность; т.е. все запросы, которые можно сформулировать с помощью реляционной алгебры, могут быть также сформулированы с помощью реляционного исчисления и наоборот. Первым это доказал E. F. Codd в 1972 году. Это доказательство основано на алгоритме (“алгоритм редукции Кодда”) по которому произвольное выражение реляционного исчисления может быть сокращено до семантически эквивалентного выражения реляционной алгебры.

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

Лекция 3. Дефекты соединения: «дефект типа разветвление» и «дефект типа разрыв».

Дефекты

Проблемы/дефекты ER моделирования

Дефектами соединения (connection trap), обычно возникают вследствие неправильной интерпретации смысла некоторых связей. Мы рассмотрим два основных типа дефектов соединения: дефект типа "разветвление" (fan trap) и дефект типа "разрыв" (chasm trap), а также укажем способы выявления и устранения этих проблем в создаваемых ER-моделях.

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

Дефекты типа "разветвление"

Дефект типа разветвление

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

Дефект типа "разветвление" возникает в том случае, когда две или несколько связей типа 1:М исходят из одной сущности. Потенциальный дефект типа "разветвление" показан на рисунке, на котором две связи типа 1:М (Has и Operates) исходят из одной и той же сущности Division.

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


Дефекты типа "разрыв"

Дефект типа разрыв

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

Дефект типа "разрыв" может возникать, если существует одна или несколько связей с минимальной кратностью, равной нулю (которая обозначает необязательное участие), и эти связи составляют часть пути между взаимосвязанными сущностями. На рисунке потенциальный дефект типа "разрыв" показан на примере связей между сущностями Branch, Staff и PropertyForRent.

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


Аномалии


Избыточность данных и аномалии обновления

Основная цель проектирования реляционной базы данных заключается в группировании атрибутов в отношения таким образом, чтобы минимизировать избыточность данных и тем самым сократить объем памяти, необходимый для физического хранения отношений, представленных в виде таблиц. Проблемы, связанные с избыточностью данных, можно проиллюстрировать, сравнив отношения Staff и Branch таблицах 1 и 2 с отношением StaffBranch таблице 3. Отношение StaffBranch является альтернативной формой представления отношений Staff и Branch. Упомянутые отношения описываются следующим образом:


  • Staff (staffNo, sName, position, salary, branchNo)


  • Branch (branchNo, bAddress)


  • StaffBranch (staffNo, sName, position, salary, branchNo, bAddress)



Лекция 4. Инфологическое проектирование. Основные функции поддержки баз данных

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

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

Чаще всего концептуальная модель базы данных включает в себя:


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

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

Логическое (даталогическое) проектирование


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

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

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

Физическое проектирование


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




Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   10


База данных защищена авторским правом ©uverenniy.ru 2019
обратиться к администрации

    Главная страница