Слайд 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) Физическое проектирование – реализация даталогической модели средствами конкретной СУБД, а также выбор решений, связанных с физической средой хранения данных: выбор методов управления дисковой памятью, методов доступа к данным, методов сжатия данных и т.д. – эти задачи решаются в основном средствами СУБД и скрыты от разработчика БД.
• На этапе инфологического проектирования в ходе сбора информации о предметной области требуется выяснить:
• основные объекты предметной области (объекты, о которых должна храниться информация в БД);
• атрибуты объектов;
• связи между объектами;
• основные запросы к БД.

ЭТАПЫ И ОСНОВНЫЕ ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

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

ER-МОДЕЛЬ ДАННЫХ

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

ER-МОДЕЛЬ ДАННЫХ

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

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

ПРЕОБРАЗОВАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ В РЕЛЯЦИОННУЮ

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

Подобные документы

реферат, добавлен 08.03.2010


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

курсовая работа, добавлен 10.03.2015


Разработка концептуальной модели базы данных "Чемпионат авто": описание предметной области, каталог задач, описание таблиц, схема данных, ER-диаграмма. Проектирование реляционной модели "Спортивный комплекс". Реализация и результат работы базы данных.

курсовая работа, добавлен 14.06.2011


Понятие базы данных, ее архитектура. Классификация баз данных. Основные модели данных. Примеры структурированных и неструктурированных данных. Достоинства и недостатки архитектуры файл-сервер. Иерархическая модель данных. Виды индексов, нормализация.

презентация, добавлен 06.08.2014


Функции автоматизированной системы "Отдел аспирантуры". Проектирование реляционной модели и разработка SQL-кода базы данных. Анализ информационного обеспечения функций. Проектирования глобальной ER-модели. Спецификации локальных ограничений и правил.

курсовая работа, добавлен 01.04.2011


Построение инфологической модели данных каталога магазина цифровых дисков. Окно создания новых файлов. Типы данных в Visual FoxPro. Список типов индекса. Структура таблиц, связи между ними. Настройка внешнего вида формы. Выбор поля для сортировки данных.

курсовая работа, добавлен 24.09.2013


Информационная система на базе компьютера. Основное отличие системы с базой данных от традиционной файловой системы. Построение концептуальной модели, реляционной модели. Нормализация. Проектирование базы данных в ACCESS. Создание SQL запросов.

курсовая работа, добавлен 06.11.2008


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

курсовая работа, добавлен 01.02.2015


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

реферат, добавлен 28.11.2011


Определение базы данных и банков данных. Компоненты банка данных. Основные требования к технологии интегрированного хранения и обработки данных. Система управления и модели организации доступа к базам данных. Разработка приложений и администрирование.

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

Урок 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. Приведите примеры преобразования сетевой модели в реляционную.

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

наиболее распространенной. Основные достоинства реляционного подхода:

небольшой набор простых и точных понятий, которые позволяют моделировать разнообразные предметные области;теоретическая поддержка в виде

мощного математического аппарата

теории множеств и реляционной алгебры;

При формальном рассмотрении этой модели, которая относится к низкоуровневым моделям данных, выделяют следующие основные

аспекты: структурная организация данных

– от этого зависит эффективность хранения данных и скорость их обработки;

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

манипулирование данными, т.е.

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

Основа реляционной модели –

математическое понятие отношения (англ. – relation).

Физическим представлением отношения является обычная двумерная таблица .

В отдельной таблице обычно хранятся данные для некоторого

информационного объекта (ИО).

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

Примеры информационных объектов

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

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

должны повторяться .

Строки таблицы для хранения данных называют записями (или кортежами ).

В полях отдельной записи хранятся значения реквизитов для конкретного экземпляра рассматриваемого ИО.

Пример таблицы для хранения данных

При формировании заголовка таблицы порядок расположения столбцов значения не имеет.

Количество столбцов определяет

степень отношения (таблицы).

Унарное отношение имеет степень 1, а бинарное отношение – степень 2.

Кардинальность отношения

измеряется количеством записей

Фундаментальные (базовые) свойства отношения (таблицы)

1.Каждая ячейка отношения содержит только одно элементарное (атомарное, неделимое) значение.

2.Каждая запись является уникальной, т.е. дублирование записей не допускается.

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

3.Порядок размещения записей не имеет никакого значения, что также вытекает из понятия «множество».

При необходимости записи можно

упорядочить с помощью операции

Целостность данных в реляционной модели

Эти требования, гарантирующие корректность данных, включают в себя два условия:

целостность таблиц (отношений);

Требование целостности таблицы

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

Минимальный набор атрибутов, позволяющий однозначно

идентифицировать каждую запись рассматриваемого отношения,

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

Например, по номеру налогоплательщика (ИНН) можно однозначно определить его адрес, фамилию и другие персональные данные.

Ключ называется составным , если он

образован из нескольких атрибутов.

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

множество атрибутов.

Тот потенциальный ключ, который выбран для однозначной идентификации

записей таблицы, называют первичным ключом (Primary Key - PK).

В составе первичного ключа ни один атрибут не может содержать пустых значений (NULL).

Остальные потенциальные ключи

становятся альтернативными ключами (Alternate Key - AK).

Для первичного ключа лучше всего

Требование ссылочной
целостности обусловлено тем, что
очень часто данные для
взаимосвязанных информационных
объектов (ИО) хранятся в разных
	Преподава
таблицах.
(РК Кодтели преп
		Код_кафед
	Отчество
	Должность	Название
(FК Кафедра