Презентация на тему: Реляционная база данных. Презентация на тему «Реляционная модель данных

| Виды моделей данных

Урок 40
Виды моделей данных

Изучив эту тему, вы узнаете и повторите::

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

Связи между таблицами реляционной модели данных

Реляционная модель данных, как правило, состоит из нескольких связанных между собой таблиц. Если вы связываете два объекта нитью, то к одному концу нити привязан один объект, к другому концу привязан второй объект. Также и между таблицами: один конец связи относится к одной таблице, а второй конец связи - к другой. Таким образом, связь всегда соединяет только две таблицы.

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

- «один-к-одному»;
- «один-ко-многим»;
- «многие-ко-многим».

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

Предположим у нас есть две таблицы - ТАБ1 и ТАБ2. 

Связь «один-к-одному» (условное обозначение 1:1) означает, что одной записи в таблице ТАБ1 соответствует только одна запись в таблице ТАБ2, а одной записи в таблице ТАБ2 соответствует только одна запись в таблице ТАБ1. При связи «один-к- одному» обе таблицы, и ТАБ1 и ТАБ2, имеют одинаковое количество записей и между этими записями установлено взаимнооднозначное соответствие.

Например, одна таблица описывает класс Школы. В ней могут быть помещены такие данные, как номер школы, направление (образовательный уклон), адрес, телефон. Другая таблица описывает класс Директора школ по следующим параметрам: фамилия, имя, отчество, личные данные директора. Поскольку у любой школы может быть только один директор, и любой человек может быть директором только в одной школе, то между такими двумя таблицами имеет место связь «один-к-одному». Связь «один-к-одному» является довольно редким типом связей.

Связь «один-ко-многим» (условное обозначение 1:М) означает, что одной записи в таблице ТАБ1 (конец связи «один») соответствует много записей в таблице ТАБ2 (конец связи «многие»), но одной записи в таблице ТАБ2 соответствует только одна запись в таблице ТАБ1. Таблица со стороны связи «один» называется главной, а таблица со стороны связи «многие» называется подчиненной. Эта связь характерна также тем, что записи в главной таблице могут и не иметь подчиненных записей, но для каждой записи в подчиненной таблице обязательно должна быть запись в главной таблице. Связь «один-ко-многим» является наиболее распространенным типом связей.

Например, пусть таблица Дома содержит сведения об улицах и номерах домов, таблица Квартиры содержит сведения о номере квартиры в доме, количестве комнат, общей жилой площади. Между таблицами Дома и Квартиры имеет место связь «один- ко-многим» - «один» со стороны таблицы Дома, «многие» со стороны таблицы Квартиры. Это так, потому что один дом мо жет содержать много квартир, но любая конкретная квартира находится только в одном доме. Когда описывают связь типа «один-ко-многим», то сначала указывают главную таблицу, а затем подчиненную.

Связь «многие-ко-многим» (условное обозначение М:М) означает, что одной записи в ТАБ1 соответствует много записей в ТАБ2, а одной записи в ТАБ2 соответствует много записей в ТАБ1.

Например, в таблице Остановки содержатся адреса остановок для маршрутов городского транспорта, а в таблице Маршруты - перечень маршрутов. Между этими таблицами установлена связь «многие-ко-многим», так как на одну остановку могут прибывать многие маршруты, и наоборот, каждому маршруту соответствует много остановок.

Графическое обозначение реляционной модели

Графически реляционную модель можно представить, как показано на рис. 4.9. Каждая таблица изображается в виде прямоугольника, в верхней части которого записано название таблицы (класса объектов). Ниже можно указать названия полей. Поля, являющиеся ключом, выделены. Соединительные линии между таблицами обозначают связи. Над связью в конкретной базе данных можно написать ее смысл, а также тип отношения: «один- ко-многим », «многие-ко-многим».

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

Составим реляционную модель для базы данных Песни. Представим сведения о песнях в виде двух взаимосвязанных классов - Исполнители и Песни. Тогда вместо одной таблицы получится две (табл. 4.3, 4.4).

Будем рассматривать такую модель, где каждую песню исполняет только один исполнитель. Тогда можно сказать, что классы Исполнители и Песни связаны отношением «один-ко-многим». Естественно, что в таблице Исполнители будет меньше записей, чем в таблице Песни.

Таблица 4.3. Исполнители

Таблица 4.4. Песни

Если бы мы приняли условие, что каждая песня может быть исполнена несколькими исполнителями, то отношение между таблицами стало бы «многие-ко-многим», и это была бы уже другая модель.

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

Как правило, это поле имеет имя Код <имя объекта>. Это поле вводится в расчете на дальнейшую компьютерную обработку данных. Дело в том, что программной среде «легче» работать с числами, чем с текстом. Порядковые номера не повторяются, поэтому такое поле можно выбрать в качестве ключевого.

Так в таблицу Исполнители можно ввести поле Код исполнителя числового типа, а в таблицу Песни - поле Код песни.

В таблицах, связанных отношением «один-ко-многим», связь между таблицами осуществляется по ключевому полю следующим образом. В таблицу Песни добавляется поле с названием Код исполнителя и для каждой песни в нем указываются соответствующие номера исполнителей. Такой номер, по сути, несет в себе всю информацию об исполнителе, представленную в соответствующей таблице. Это и означает, что связь между таблицами осуществлена по ключу Код исполнителя. Реляционная модель этой базы данных представлена на рис. 4.10.

Рис. 4.10. Реляционная модель базы данных Любимые песни

Возникает закономерный вопрос: зачем нужно было разделять одну таблицу на две? На первый взгляд может показаться, что одна таблица (см. табл. 4.1) удобнее для восприятия информации. Но в такой таблице нам надо было каждый раз полностью указывать название исполнителя и все его характеристики. Поскольку по свойству реляционных таблиц каждая запись (строка) считается независимой от других записей, то такая таблица не отражает в полной мере связь между песнями и исполнителями. Более того, если в какой-то строке вы записали исполнителя с ошибкой, то это будет восприниматься как новое значение. Если же исполнители выделены в отдельную таблицу, то такие операции как удаление или изменение данных можно производить намного легче и быстрее.

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

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

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

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

Рассмотрим пример иерархической модели населенных пунктов планеты Земля (рис. 4.11). В ней выделен корневой уровень - планета Земля, второй уровень обозначает континенты, третий - страны, четвертый - населенные пункты.

Рис. 4.11. Иерархическая модель Планета Земля

Корневой уровень будет служить названием базы данных. Каждый следующий уровень описываем в виде отдельной таблицы. Получаем следующую реляционную модель (рис. 4.12).

Рис. 4.12. Реляционная модель Планета Земля

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

Для сетевой модели Увлечения подростков (рис. 4.13) каждый уровень также оформляем в виде отдельной таблицы. Между таблицами установлена связь «многие-ко-многим».

Рис. 4.13. Реляционная модель Увлечения подростков

Контрольные вопросы и задания

1. Что такое модель данных и для чего она нужна?

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

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

4. Приведите примеры моделей данных для разных предметных областей.

5. Что представляет собой иерархическая модель данных в общем виде?

6. Что такое узел иерархической модели данных?

7. В чем состоят свойства иерархической модели данных?

8. Приведите примеры иерархических моделей данных.

9. Что представляет собой сетевая модель данных в общем виде?

10. В чем состоят свойства сетевой модели данных?

11. Приведите примеры сетевых моделей данных.

12. Что представляет собой реляционная модель данных в общем виде?

13. Как вы понимаете связь между информационными объектами 1:1? Приведите примеры такого типа связей.

14. Как вы понимаете связь между информационными объектами 1:М? Приведите примеры этого типа связей.

15. Как вы понимаете связь между информационными объектами М:М? Приведите примеры данного типа связей.

16. В чем состоят свойства реляционной модели данных?

17. Приведите примеры реляционных моделей данных.

18. Как графически отображается реляционная модель данных?

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

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

Слайд 1

Описание слайда:

Слайд 2

Описание слайда:

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

Слайд 3

Описание слайда:

Слайд 4

Описание слайда:

Слайд 5

Описание слайда:

Основные понятия базы данных Так, таблица Деталь содержит сведения о всех деталях, хранящихся на складе, а ее строки являются наборами значений атрибутов конкретных деталей. Каждый столбец таблицы - это совокупность значений конкретного атрибута объекта. Так, столбец Материал представляет собой множество значений "Сталь", "Олово", "Цинк", "Никель". В столбце Количество содержатся целые неотрицательные числа. Значения в столбце Вес - вещественные числа, равные весу детали в килограммах. Эти значения не появляются из воздуха. Они выбираются из множества всех возможных значений атрибута объекта, которое называется доменом. Так, значения в столбце материал выбираются из множества имен всех возможных материалов - пластмасс, древесины, металлов и т.д. Следовательно, в столбце Материал принципиально невозможно появление значения, которого нет в соответствующем домене, например, "вода" или "песок". Каждый столбец имеет имя, которое обычно записывается в верхней части таблицы. Оно должно быть уникальным в таблице, однако различные таблицы могут иметь столбцы с одинаковыми именами. Любая таблица должна иметь по крайней мере один столбец; столбцы расположены в таблице в соответствии с порядком следования их имен при ее создании. В отличие от столбцов, строки не имеют имен; порядок их следования в таблице не определен, а количество логически не ограничено.

Слайд 6

Описание слайда:

Слайд 7

Описание слайда:

Слайд 8

Описание слайда:

Слайд 9

Описание слайда:

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

Слайд 10

Описание слайда:

Слайд 11

Описание слайда:

Слайд 12

Описание слайда:

Слайд 13

Описание слайда:

Слайд 14

Описание слайда:

Слайд 15

Описание слайда:

Слайд 16

Описание слайда:

Слайд 17

Описание слайда:

Слайд 18

Описание слайда:

Слайд 19

Описание слайда:

Другие нормальные формы Первая нормальная форма запрещает таблицам иметь неатомарные, или многозначные атрибуты. Однако существует множество ситуаций моделирования, требующих многозначных атрибутов. Например, преподаватель в вузе отвечает за несколько дисциплин. Существует несколько решений, каждое из которых имеет определенные недостатки. Все они требуют лишней памяти из-за наличия пустых значений, либо из-за необходимости вводить избыточные данные. Те из них, в которых есть пустые значения, нарушают категорийную целостность, поскольку все атрибуты вместе составляют ключ таблицы. Эти кажущиеся связи между независимыми атрибутами можно исключить, потребовав, чтобы каждое значение атрибута сочеталось с каждым значением другого атрибута как минимум в одной строке. Условие, обеспечивающее независимость атрибутов путем обязательного повторения значений, называется многозначной зависимостью. Многозначная зависимость является таким же ограничительным условием, как функциональная зависимость. Очевидно, что поскольку они требуют огромного числа повторений значений данных, важный этап процесса нормализации состоит в избавлении от многозначных зависимостей. Таблица имеет четвертую нормальную форму (4НФ), если она имеет 3НФ и не содержит многозначных зависимостей. Для избавления от некоторых других аномалий были предложены еще несколько нормальных форм: пятая нормальная форма (5НФ), нормальная форма область/ключ (НФОК) и т.д. Однако они имеют очень ограниченное практическое использование.

Слайд 21

ОСНОВНЫЕ ПОНЯТИЯ РЕЛЯЦИОННОЙ МОДЕЛИ ДАННЫХ

• В основе реляционных систем лежит реляционная модель данных .
• Принципы реляционной модели были заложены в 1969–1970 гг. американским ученым Е. Ф. Коддом (E. F. Codd), в то время работавшим в корпорации IBM. Будучи математиком по образованию, он привнес в область управления базами данных строгие математические принципы и точность, которых не хватало ранним системам. Хотя реляционный подход утвердился не сразу, можно отметить, что почти все созданные с конца 70-х гг. продукты баз данных основаны именно на реляционном подходе.
• Подавляющее большинство научных исследований в области баз данных в течение последних 35 лет также проводилось именно в этом направлении.
• Рассматривая и постепенно уточняя основные понятия реляционной модели, будем иметь в виду три компоненты модели данных:
• структуры данных,
• операции, которые можно выполнять над данными, и
• ограничения, связанные с обеспечением целостности данных.

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

• Отношение это таблица , подобная приведенной на рисунке, состоящая из строк и столбцов и имеющая вверху строку, называемую заголовок отношения .
• Строки таблицы-отношения называются кортежами (tuple), а столбцы атрибутами (attribute).
• Количество кортежей в отношении называется кардинальным числом отношения, а количество атрибутов называется степенью отношения.
• Каждый атрибут в отношении имеет наименование , которое указывается в заголовочной части отношения.
• Ключ отношения – это атрибут или набор атрибутов отношения такие, что в любой момент времени в отношении не существует строк, для которых значение или комбинация значений ключевых атрибутов являются одинаковыми. Ключ , таким образом, является уникальным идентификатором кортежей отношения (на рисунке ключевой атрибут выделен жирным шрифтом).
• Домен отношения – это множество значений, из которого могут браться значения конкретного атрибута. То есть конкретный набор значений атрибута в любой момент времени должен быть подмножеством множества значений домена, на котором определен этот атрибут. Значения атрибута, которые отсутствуют в множестве, задаваемом доменом, являются недопустимыми.

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

• Основные задачи проектирования баз данных:
• Обеспечение хранения в БД всей необходимой информации.
• Обеспечение возможности получения данных по всем необходимым запросам.
• Сокращение избыточности и дублирования данных.
• Обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.
• Основные этапы проектирования баз данных:
• 1) Концептуальное (инфологическое) проектирование – построение формализованной модели предметной области. Такая модель строится с использованием стандартных языковых средств, обычно графических, например ER-диаграмм (диаграмм «Сущность-связь»). Такая модель строится без ориентации на какую-либо конкретную СУБД.
• Основные элементы данной модели:
• Описание объектов предметной области и связей между ними.
• Описание информационных потребностей пользователей (описание основных запросов к БД).
• Описание алгоритмических зависимостей между данными.
• Описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.

• 2) Логическое (даталогическое) проектирование – отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель – набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определённым формализованным правилам, а также нормализацию этих таблиц. Этот этап может быть в значительной степени автоматизирован.
• 3) Физическое проектирование – реализация даталогической модели средствами конкретной СУБД, а также выбор решений, связанных с физической средой хранения данных: выбор методов управления дисковой памятью, методов доступа к данным, методов сжатия данных и т.д. – эти задачи решаются в основном средствами СУБД и скрыты от разработчика БД.
• На этапе инфологического проектирования в ходе сбора информации о предметной области требуется выяснить:
• основные объекты предметной области (объекты, о которых должна храниться информация в БД);
• атрибуты объектов;
• связи между объектами;
• основные запросы к БД.

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

• Модель сущность-связь (ERM) - модель данных, позволяющая описывать концептуальные схемы предметной области.
• ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи , которые могут устанавливаться между этими сущностями.
• Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).
• ER-модель представляет собой формальную конструкцию , которая сама по себе не предписывает никаких графических средств её визуализации.
• Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen Chen), американским профессором компьютерных наук в университете штата Луизиана.

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

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

• Таким образом, у нас определены таблицы , поля , первичные ключи (РК) и связи (FK).
• В таблицах Журнал поставок и Журнал покупок первичные ключи - составные , т.е. состоят из двух полей .
• Теоретически бывают таблицы, в которых все поля являются одним составным ключом .
• Нормализация - это пошаговый, обратимый процесс замены исходной схемы другой схемой, в которой таблицы имеют более простую и логичную структуру. Это нужно для устранения избыточности данных.

1 из 21

Презентация на тему:

№ слайда 1

Описание слайда:

№ слайда 2

Описание слайда:

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

№ слайда 3

Описание слайда:

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

№ слайда 4

Описание слайда:

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

№ слайда 5

Описание слайда:

Основные понятия базы данных Так, таблица Деталь содержит сведения о всех деталях, хранящихся на складе, а ее строки являются наборами значений атрибутов конкретных деталей. Каждый столбец таблицы - это совокупность значений конкретного атрибута объекта. Так, столбец Материал представляет собой множество значений "Сталь", "Олово", "Цинк", "Никель". В столбце Количество содержатся целые неотрицательные числа. Значения в столбце Вес - вещественные числа, равные весу детали в килограммах.Эти значения не появляются из воздуха. Они выбираются из множества всех возможных значений атрибута объекта, которое называется доменом. Так, значения в столбце материал выбираются из множества имен всех возможных материалов - пластмасс, древесины, металлов и т.д. Следовательно, в столбце Материал принципиально невозможно появление значения, которого нет в соответствующем домене, например, "вода" или "песок".Каждый столбец имеет имя, которое обычно записывается в верхней части таблицы. Оно должно быть уникальным в таблице, однако различные таблицы могут иметь столбцы с одинаковыми именами. Любая таблица должна иметь по крайней мере один столбец; столбцы расположены в таблице в соответствии с порядком следования их имен при ее создании. В отличие от столбцов, строки не имеют имен; порядок их следования в таблице не определен, а количество логически не ограничено.

№ слайда 6

Описание слайда:

№ слайда 7

Описание слайда:

Взаимосвязь таблиц базы данных Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами. Рассмотрим пример, в котором база данных хранит информацию о рядовых служащих (таблица Служащий) и руководителях (таблица Руководитель) в некоторой организации. Первичный ключ таблицы Руководитель - столбец Номер. Столбец Фамилия не может выполнять роль первичного ключа, так как в одной организации могут работать два руководителя с одинаковыми фамилиями. Любой служащий подчинен единственному руководителю, что должно быть отражено в базе данных. Таблица Служащий содержит столбец Номер руководителя, и значения в этом столбце выбираются из столбца Номер таблицы Руководитель. Столбец Номер Руководителя является внешним ключом в таблице Служащий.

№ слайда 8

Описание слайда:

№ слайда 9

Описание слайда:

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

№ слайда 10

Описание слайда:

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

№ слайда 11

Описание слайда:

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

№ слайда 12

Описание слайда:

№ слайда 13

Описание слайда:

Традиционные операции Объединение двух отношений (С1 = А U В) предполагает, что на входе задано два односхемных отношения А и В. Результат объединения есть построенное по той же схеме отношение С, содержащее все кортежи А и все кортежи отношения В.Пересечение двух отношений (С2=А U В) предполагает на входе два односхемных отношения А и В. На выходе создается отношение по той же схеме, содержащее только те кортежи отношения А, которые есть в отношении В.Вычитание двух отношений (С3=А-В). Все три отношения строятся по одной схеме. В результирующее отношение С3 включаются только те кортежи из А, которых нет в отношении В.Декартово произведение (С4=А X В). Ее важное отличие от предшествующих состоит в том, что отношения А и В могут быть построены по разным схемам, а схема отношения С4 включает все атрибуты отношении А и В.

№ слайда 14

Описание слайда:

Специальные операции Операция селекция выполняется по строкам. На входе операции используется одно отношение. Результат выборки есть новое отношение, построенное по той же схеме, содержащее подмножество кортежей исходного отношения, удовлетворяющих условию выборки.Операция проекция. На входе операции используется одно отношение. Результирующее отношение включает подмножество атрибутов исходного. Каждому кортежу исходного отношения соответствует такой кортеж в результирующем отношении, что значения одинаковых атрибутов этих двух кортежей совпадают. Но при этом в результирующем отношении кортежи-дубликаты устраняются, в связи с чем мощность результирующего отношения может быть меньше мощности исходного.Операция соединение естественное. На входе операции используется два отношения. В каждом из отношений выделен атрибут, по которому будет осуществляться соединение. Оба атрибута должны быть определены на одном и том же домене. Схема результирующего отношения включает все атрибуты двух отношений. Допускается, чтобы в схеме результирующего отношения вместо двух атрибутов, по которым выполняется соединение, был представлен только один. Операция соединение похожа на декартово произведение. Операция деление. На входе операции используется два отношения А и В. Пусть отношение А, называемое делимым, содержит атрибуты (А1,А2, ...,Аn). Отношение В – делитель -содержит подмножество атрибутов А; положим, (А1,А2, ...,Аk), где (k

№ слайда 15

Описание слайда:

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

№ слайда 16

Описание слайда:

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

№ слайда 17

Описание слайда:

Первая нормальная форма Отношение называется нормализованным или приведенным к первой нормальной форме (1НФ), если все его атрибуты простые.Ненормализованное отношение легко сделать нормализованным. Такое преобразование может привести к увеличению мощности отношения и изменению ключа.Функциональная зависимость. Пусть Х и Y - два атрибута некоторого отношения, Говорят, что Y функционально зависит от X, если в любой момент времени каждому значению Х соответствует не более чем одно значение атрибута Y. Функциональную зависимость можно обозначить так: Х>Y.Полная функциональная зависимость. Говорят, что не ключевой атрибут функционально полно зависит от составного ключа, если он функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.

№ слайда 18

Описание слайда:

Вторая нормальная форма Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме и каждый не ключевой атрибут функционально полно зависит от составного ключа.Чтобы отношение привести ко второй нормальной форме, необходимо:построить его проекцию, исключив атрибуты, которые не находятся в полной функциональной зависимости от составного ключа;построить дополнительно одну или несколько проекций на часть составного ключа и атрибуты, функционально зависящие от этой части ключа.Транзитивная зависимость. Пусть X, Y, Z - три атрибута некоторого отношения. При этом Х>Y и Y>Z, но обратное соответствие отсутствует, т. е. Z не> или Y не>Х. Тогда говорят, что Z транзитивно зависит от X.

Другие нормальные формы Первая нормальная форма запрещает таблицам иметь неатомарные, или многозначные атрибуты. Однако существует множество ситуаций моделирования, требующих многозначных атрибутов. Например, преподаватель в вузе отвечает за несколько дисциплин. Существует несколько решений, каждое из которых имеет определенные недостатки. Все они требуют лишней памяти из-за наличия пустых значений, либо из-за необходимости вводить избыточные данные. Те из них, в которых есть пустые значения, нарушают категорийную целостность, поскольку все атрибуты вместе составляют ключ таблицы. Эти кажущиеся связи между независимыми атрибутами можно исключить, потребовав, чтобы каждое значение атрибута сочеталось с каждым значением другого атрибута как минимум в одной строке. Условие, обеспечивающее независимость атрибутов путем обязательного повторения значений, называется многозначной зависимостью. Многозначная зависимость является таким же ограничительным условием, как функциональная зависимость. Очевидно, что поскольку они требуют огромного числа повторений значений данных, важный этап процесса нормализации состоит в избавлении от многозначных зависимостей.Таблица имеет четвертую нормальную форму (4НФ), если она имеет 3НФ и не содержит многозначных зависимостей.Для избавления от некоторых других аномалий были предложены еще несколько нормальных форм: пятая нормальная форма (5НФ), нормальная форма область/ключ (НФОК) и т.д. Однако они имеют очень ограниченное практическое использование.

№ слайда 21

Описание слайда:

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