Презентация на тему по информатике и ИКТ на тему Реляционная база данных

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

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

это некоторый набор данных, необходимых для работы.
Однако данные

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

Возврат в
содержание

как последовательность разных, иногда и взаимосвязанных, явлений. Еще в

древности люди различными способами описывали эти явления, часто даже не понимая их сущности. Сегодня это описание называется данными. К данным относятся: факты, явления, события, идеи или предметы.
Фиксация данных традиционно происходит через конкретные средства общения - естественного языка или изображений, на конкретном носителе: камне или бумаге. Учитывая тот факт, что естественный язык обладает достаточной гибкостью, данные и их интерпретация (семантика) фиксируются совместно. Например, рассмотрим утверждение "Стоимость билета на электричку 147". Здесь "147" - данное, а "Стоимость билета на электричку" - его семантика.
Очень часто данные и интерпретация разделяются. Например, "Расписание движения поездов" представляется в виде таблицы, в которой в верхней части отдельно от данных будет приведена их интерпретация, а это затрудняет работу с данными и приводит к сложности получения сведения из нижней части таблицы.
Разделение данных и интерпретации становиться еще более ощутимым, когда ЭВМ применяется для ввода и обработки данных. Это происходит потому, ЭВМ может иметь дело только с данными. Большая часть интерпретирующей информации не фиксируются в явной форме (ЭВМ не "понимает", является ли "22.50" стоимостью авиабилета или временем вылета). Почему так происходит?
Существуют как минимум две исторические причины, способствующие тому, что активное использование ЭВМ способствовало тому, что произошло разделение данных и интерпретации:
- ЭВМ не имело достаточных возможностей, чтобы обрабатывать тексты на естественном языке - основном языке интерпретации данных;
высокая стоимость памяти ЭВМ.
Память использовали для того, чтобы хранить сами данные, а интерпретацией занимались непосредственно пользователи. Процесс выглядел следующим образом, интерпретацию данных закладывали в программу, которая "понимала", например, что пятое вводимое значение связано с временем прибытия поезда, а пятое - с временем его убытия. Такая последовательность действий делала программу незаменимой, потому что без интерпретации данные всего лишь совокупность битов на запоминающем устройстве.
Все серьезные проблемы, которые возникают при введении данных, связаны с тем, что между данными и использующими их программами существует очень жесткая связь.
Как показывает практика, совместное использование одних и тех же данных, приносит массу проблем. Например, очень часто бывает так, что при использовании одной и той же ЭВМ пользователями создаются и используются в программах разные наборы данных, содержащие сходную информацию. Это можно объяснить тем, что пользователь просто не имеет информации о том, что сотрудник, который работает рядом, давно ввел в ЭВМ нужные данные.
Очень удобно при использовании, когда разработчики прикладных программ, размещают нужные им данные в файлах. Надо учитывать, что одинаковые данные в разных приложениях отличаются организацией, то есть обладают разной последовательностью размещения в записи, разные форматы одних и тех же полей и т.п. Поэтому обобщить все данные очень сложно. Это связано с тем, что если один разработчик производит изменение структуры записи файла, то и другой разработчик должен произвести изменения в программах, использующих записи этого файла.

Возврат в
содержание

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

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

в зависимости от модели данных, которая лежит в их

основе. Принято выделять:

Можно добавлять данные на основе инвертированных списков.

Возврат в
содержание

которой все данные представлены для пользователя в виде прямоугольных

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

Возврат в
содержание

о всех деталях, хранящихся на складе, а ее строки

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

Возврат в
содержание

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

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

Возврат в
содержание

данных отсутствуют "данные о данных", например, описатели таблиц, столбцов

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

Возврат в
содержание

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

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

Возврат в
содержание

данных фиксируются два базовых требования целостности, которые должны поддерживаться

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

Возврат в
содержание

образуют реляционную алгебру. Каждая операция использует одну или две

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

Возврат в
содержание

В) предполагает, что на входе задано два односхемных отношения

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

Возврат в
содержание

операции используется одно отношение. Результат выборки есть новое отношение,

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

Возврат в
содержание

отношениями, позволяя обновлять БД, а также выбирать подмножества хранимых

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

Возврат в
содержание

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

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

Возврат в
содержание

первой нормальной форме (1НФ), если все его атрибуты простые.
Ненормализованное

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

Возврат в
содержание

если оно находится в первой нормальной форме и каждый

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

Возврат в
содержание

если оно находится во второй нормальной форме и каждый

не ключевой атрибут не транзитивно зависит от первичного ключа. Рассматриваемая версия третьей нормальной формы часто называется нормальной формой Бойса-Кодда (НФБК).

Возврат в
содержание

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

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

Возврат в
содержание