Курс знакомит слушателей с основными принципами работы со структурированными данными в реляционной модели, учит проектировать данные, описывать объекты базы данных в терминах реальной СУБД, составлять запросы на языке SQL, использовать представления, процедуры, функции и триггеры, создавать индексы, управлять конкурентным доступом к данным и манипулировать механизмом транзакций. Основу курса составляют изучение и применение языка SQL для создания, модификации объектов баз данных и управления данными в произвольной реляционной базе данных. Выполнение практических задач в рамках курса предполагает использование СУБД My SQL. В курсе рассматриваются этапы проектирования реляционных баз данных, правила составления запросов, основные методы индексирования данных. В курсе будут изучены вопросы использования транзакций и прав доступа к данным. Также курс дает обзор современных тенденций в области науки о данных в связи с появлением BigData. В заключении курса будут показаны сферы применения NoSQL баз данных и указаны современные подходы к обработке big data.
Преобразование отношений.
Loading...
Из курса от партнера Saint Petersburg State University
Базы данных (Databases)
57 оценки
Из урока
Реляционная алгебра. Нормализация реляционных отношений.
В этой лекции мы начнем с описания реляционной модели, на которой основаны наиболее популярные СУБД. Будут даны основные понятия реляционной теории и показано, как представляются объекты и связи в терминах реляционной модели. Будут продемонстрированы проблемы, возникающие при ошибках в проектировании данных, и пути их исправления. Также будут рассмотрены основные операции для манипулирования реляционными данными.
Познакомьтесь с преподавателями
Михайлова Еленадоцент, ИО заведующего кафедрой информационно-аналитических систем СПбГУ
Кафедра информационно-аналитических систем СПбГУ
[МУЗЫКА]
[МУЗЫКА] Здравствуйте!
В прошлый раз мы рассмотрели с вами, как сущности и связи представляются в таблице.
Иногда мы замечаем, что таблицы спроектированы плохо.
Давайте начнём с примеров.
На первом примере мы видим таблицу,
которая будет называться «Группами» и у неё будет всего два атрибута.
Первый атрибут — это будет номер группы, второй — это список студентов,
которые учатся в этой группе.
Мы сразу видим, что искать информацию о каком-то конкретном студенте нам будет
не очень удобно, определять количество студентов в группе тоже неудобно,
строки будут разной длины.
Таким образом, у нас значение атрибута «номер группы» оказывается не атомарным.
Второй пример не очень хорошего отношения — это пример, в котором мы храним товары,
которые нам предоставляют определённые поставщики, и цены.
Какие атрибуты мы видим у этой таблицы?
Мы видим «название фирмы», «адрес», «телефон», «товар» и «цена».
Что плохого в этой таблице?
Мы видим, что если нам фирма поставляет несколько деталей,
то мы несколько раз храним адрес фирмы, телефон, которые, вообще-то говоря,
можно было бы сохранить всего один раз.
Следующий пример плохого отношения, например, студенты и предметы.
В данном отношении у нас есть номер группы, номер зачётки,
фамилия, имя, отчество студента, предмет и преподаватель.
Глядя на эту табличку, мы догадываемся, что у нас определённый предмет
для одной и той же группы вёл один и тот же преподаватель.
А мы в этой таблице несколько раз храним его фамилию.
Что плохого возникает в таких отношениях, которые мы называем плохими?
Во-первых, это трудности с извлечением некоторых данных.
Когда мы храним список всех студентов в одной строке,
нам неудобно извлекать эту информацию.
Второй недостаток — это избыточность.
Мы несколько раз храним адрес фирмы, несколько раз храним её телефон.
Таким образом, количество хранимых данных увеличивается.
При такой организации таблиц нас ждут аномалии изменения.
Что это такое?
Если в одной строке мы заметили, что адрес фирмы или телефон изменился,
то нам придётся изменять не в одной строке, а во всех строчках,
которые соответствуют товарам, поставляемым этой фирмой.
То же самое с удалением.
Если мы удалили товар, поставляемый какой-то компанией,
то случайно можем удалить и всю информацию об этой фирме,
если она не поставляет нам в данный момент больше никаких товаров.
Последняя аномалия, которую мы отметим, это аномалия добавления.
Если мы хотим внести в нашу базу данных информацию о какой-то фирме,
которая ещё пока не поставила нам ещё ни одного товара,
нам придётся ввести фиктивную строчку, в которой будут только название фирмы,
адрес и телефон, с пустым названием товара,
и когда мы потом добавим какой-то реальный товар, который эта компания нам поставит,
нам надо не забыть про эту искусственно добавленную строчку.
Что же делать с такими плохими отношениями?
Вернёмся к нашим примерам.
Первый пример, в котором у нас был номер группы и список студентов этой группы,
мы можем представить в виде другого отношения, в котором будет три столбца,
первый столбец будет соответствовать номеру группы, второй столбец — номеру
зачётки, и третий столбец будет соответствовать номеру студента.
Таким образом, у нас для каждого студента будет своя строка таблицы.
Что касается таблицы с товарами и ценами, мы замечаем, что у нас адрес фирмы и её
телефон зависят только от названия фирмы и никак не связаны с поставляемыми товарами.
В таком случае, мы можем вынести информацию о фирме,
её адресе и телефоне в другую таблицу.
Мы уже с вами увидели зависимости, что называние фирмы определяет адрес и
телефон, а название фирмы вместе с товаром определяет его цену.
Что такое зависимость?
Это когда, зная одни атрибуты, мы можем определить и другие.
Таким образом, мы можем перейти к понятию функциональных зависимостей.
Рассмотрим отношение R с атрибутами A1, A2, и так далее...
An и некое подмножество атрибутов.
И мы говорим, что у нас X функционально определяет Y
или Y функционально зависит от X,
если любому значению X соответствует в точности одно значение Y.
В нашем случае зависимости, зная название фирмы,
мы точно можем определить её адрес и телефон.
И зная название фирмы и товар, мы можем узнать его цену.
Можем ввести уже другое, более формальное определение ключа.
Ключом мы называем минимальный набор атрибутов,
который функционально определяет все остальные.
Формально, если мы снова вспомним схему нашего
отношения R и X является неким подмножеством атрибутов,
не обязательно это один атрибут, это может быть несколько атрибутов.
тогда мы считаем, что X определяет весь набор атрибутов нашего отношения.
И для любого Y, которое является подмножеством X,
такая зависимость не выполняется.
Это требование минимальности ключа.
Таким образом, для нашего отношения товара и фирмы
мы можем вывести ключ «название фирмы» и «товар».
Это единственная комбинация атрибутов,
которая позволяет нам однозначно определить все остальные.
Введём понятие полной функциональной зависимости.
Мы говорим, что Y полностью функционально зависит от X, если Y функционально
зависит от всех атрибутов, входящих в состав X, а не от какой-то его части.
Таким образом, в нашем отношении «Товары и цены» есть
полная функциональная зависимость между названием
фирмы и товаром, они определяют цену.
А вот у названия фирмы,
товара и адреса и телефона есть неполная функциональная зависимость, поскольку
адрес с телефоном зависят только от фирмы, а никоим образом не зависят от товара.
И формальный недостаток нашего отношения «Товары и фирмы» — то, что неключевые
атрибуты, которые не полностью зависят от возможного ключа, это адрес и телефон.
Что мы можем сделать с нашей таблицей, чтобы сделать её лучше?
Вот у нас была таблица «Товары и фирмы», в которой было пять атрибутов.
Мы разобъём наше отношение на два.
Одно отношение будет соответствовать фирме, в которой будет название фирмы,
адрес и телефон, а второе отношение будет соответствовать товарам,
там будет название фирмы, товар и цена.
Введём понятие транзитивной зависимости.
Функциональная зависимость A → C называется транзитивной,
если существует такой атрибут B, что имеются функциональная зависимость
A → B и B → C, и при этом отсутствует функциональная зависимость C → А.
Какую транзитивную функциональную зависимость мы можем рассмотреть в нашем
отношении «Студенты и предметы»?
Рассмотрим, какие есть зависимости в этом отношении.
У нас есть зависимость, что номер зачётки определяет группу, группа с
предметом определяют преподавателей, и получается формальный недостаток
отношения «Студенты и предметы» — это наличие двух транзитивных зависимостей.
Как нам преобразовать отношение «Студенты и предметы»?
Разобъём его на два отношения.
Одно отношение будет служить для представления связей между предметом,
группой и преподавателем, а второе отношение — для хранения информации
о студенте, в котором останется номер зачётки, фамилия,
имя, отчество студента, номер группы и предмет.
Что же мы на самом деле делали?
Мы с вами разбивали одну таблицу на два.
На самом деле, мы производили с вами декомпозицию.
Введём определение.
Декомпозиция — это разбиение на множества, может быть,
пересекающиеся, такие, что их объединение даёт нам исходное отношение.
Как мы можем восстановить исходное отношение?
Мы сделаем это при помощи операции естественного соединения.
Чем мы руководствовались для того, чтобы производить декомпозицию?
Пока нам помогала только наша собственная интуиция.
В дальнейшем мы рассмотрим, какими правилами мы должны руководствоваться,
чтобы производить декомпозицию отношений, и как делать это правильно.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
