Вы находитесь на странице: 1из 71

Основы работы с Tableau –

визуализация и анализ данных


Тема 1:
Введение в проектирование
баз данных
План занятия:
 Что такое база данных  Нормализация/Денормализация
 Структура базы данных  Ограничения
 Типы данных  Хранимые процедуры (stored procedures)
 Отношения между таблицами  Целостность данных
 Отношение один-к-одному  Триггер
 Отношение один-ко-многим (много-к-одному)  Деловые правила
 Отношение много-ко-многим  Преобразование к физической модели
 Нормализация баз данных  Корпоративное хранилище данных (Data Ware House)
 Ключи и индексы  Принципы организации хранилища
 Сбор информации  Дизайн хранилищ данных
 Определение сущностей  OLAP-анализ
 Определение атрибутов для каждой сущности  Slowly Changing Dimensions
 Определение связей между сущностями  Процессы работы с данными
 Business intelligence
Что такое база данных

 База данных - это набор информации, организованной тем, или иным способом.
 Самый простой пример баз – телефонная записная книжка. Этот список фамилий
владельцев телефонов и их телефонных номеров, представленный в записной книжке в
алфавитном порядке, представляет собой проиндексированную базу данных.
Использование индекса, в данном случае фамилии или имени, позволяет достаточно
быстро отыскать требуемый номер телефона.
 База данных хранится и обрабатывается в вычислительной системе. Таким образом,
любые внекомпьютерные хранилища информации (архивы, библиотеки, картотеки)
базами данных не являются.
 Цель базы данных — помочь людям и организациям вести учет определенных вещей.
 СУБД (Система управления базами данных) — комплекс программ, позволяющих
создать базу данных и манипулировать данными (вставлять, обновлять, удалять и
выбирать). Система обеспечивает безопасность, надёжность хранения и целостность
данных, а также предоставляет средства для администрирования баз данных (Microsoft
Access, Microsoft SQL Server, MySQL, Oracle SQL, IBM DB2 SQL, PostgreSQL и другие).
SQL  
 SQL (structured query language) — язык программирования, применяемый для создания,
модификации и управления данными в реляционной базе данных, управляемой
соответствующей СУБД.
 Изначально SQL был основным способом работы пользователя с базой данных и позволял
выполнять следующий набор операций:
 создание в базе данных новой таблицы;
 добавление в таблицу новых записей;
 изменение записей;
 удаление записей;
 выборка записей из одной или нескольких таблиц (в соответствии с заданным условием);
 изменение структур таблиц.
Задача 1
Опишите SQL-команды:
Ответы
 SHOW DATABASES - SQL-команда, которая отвечает за просмотр доступных баз данных.
 CREATE DATABASE - Команда для создания новой базы данных.
 USE - USE <database_name> выбирает базу данных, необходимую для дальнейшей работы.
 SOURCE - Позволит выполнить сразу несколько SQL-команд, содержащихся в файле с расширением .sql.
 DROP DATABASE - Стандартная SQL-команда для удаления целой базы данных.
 SHOW TABLES - С помощью этой команды можно увидеть все таблицы, которые доступны в базе данных.
 CREATE TABLE - SQL-команда для создания новой таблицы.
 DESCRIBE - С помощью DESCRIBE <table_name> можно просмотреть различные сведения (тип значений,
является ключом или нет) о столбцах таблицы.
 INSERT - Команда INSERT INTO <table_name> в SQL отвечает за добавление данных в таблицу.
 UPDATE - SQL-команда для обновления данных таблицы.
 DELETE - SQL-команда DELETE FROM <table_name> используется для удаления данных из таблицы.
 DROP TABLE - Удаляет всю таблицу целиком.
 SELECT – Получает данные из выбранной таблицы.
 SELECT DISTINCT - В столбцах таблицы могут содержаться повторяющиеся данные. Используйте SELECT
DISTINCT для получения только неповторяющихся данных.
Ответы
 WHERE - Можно использовать ключевое слово WHERE в SELECT для указания условий в запросе.
 GROUP BY - Используется с агрегатными функциями для группировки выходных значений.
 HAVING - Ключевое слово HAVING было добавлено в SQL по той причине, что WHERE не может использоваться для
работы с агрегатными функциями.
 ORDER BY - Используется для сортировки результатов запроса по убыванию или возрастанию (ASC или DESC).
 BETWEEN - Используется для выбора значений данных из определённого промежутка. Могут быть использованы
числовые и текстовые значения, а также даты.
 LIKE - Оператор LIKE используется в WHERE, чтобы задать шаблон поиска похожего значения. Есть два свободных
оператора, которые используются в LIKE: % (ни одного, один или несколько символов); _ (один символ).
 IN - С помощью IN можно указать несколько значений для оператора WHERE
 JOIN - используется для связи двух или более таблиц с помощью общих атрибутов внутри них.
 VIEW - это виртуальная таблица SQL, созданная в результате выполнения выражения. Она содержит строки и
столбцы и очень похожа на обычную SQL-таблицу. VIEW всегда показывает самую свежую информацию из БД.
 Агрегатные функции - Используются для получения совокупного результата, относящегося к рассматриваемым
данным: COUNT(col_name) — возвращает количество строк; SUM(col_name) — возвращает сумму значений в данном
столбце; AVG(col_name) — возвращает среднее значение данного столбца; MIN(col_name) — возвращает наименьшее
значение данного столбца; MAX(col_name) — возвращает наибольшее значение данного столбца.
 Вложенные подзапросы - это SQL-запросы, вложенные в другой запрос.
Типы данных
 Данные разного типа обрабатываются с разной скоростью. Целочисленные данные
обрабатываются быстрее всего. Для обработки данных двойной точности используется
специальный сопроцессор. Из-за сложности внутреннего представления данных с плавающей
точкой, они обрабатывается дольше, чем целочисленные.
 Дольше всего обрабатываются строковые данные. Это связано с динамическим распределением-
перераспределением оперативной памяти компьютера.
 Основные типы данных:
• INTEGER- данные из целых чисел;
• FLOAT — данные из дробных чисел (данные с плавающей точкой);
• CHAR, VARCHAR — текстовые типы данных (символьные);
• LOGICAL — логический тип данных (да/нет);
• DATE/TIME — временные данные.
Плоская БД
 Телефонный справочник представляет собой так называемую “плоскую” базу данных, в
которой вся информация располагается в единственной таблице.
 Каждая запись в этой таблице содержит идентификатор конкретного человека – ФИО и его
номер телефона. Таким образом таблица состоит из записей, информация в которых
разделена на несколько частей – полей (“ФИО” и “Номер телефона”).
Реляционная БД
 В отличие от плоских, реляционные базы данных состоят из нескольких таблиц, связь
между которыми устанавливается с помощью совпадающих значений одноименных
полей.
 В качестве примера реляционной базы данных можно привести поставляемую вместе с
Visual Basic базу данных BIBLIO.MDB, содержащую библиографическую информацию о
книгах по программированию, их авторах и издательствах, эти книги опубликовавших.

 База данных состоит из 4 таблиц, содержащих


информацию об объектах одного типа. Из названий
таблиц становиться понятно, что данные в каждой
таблице принадлежат одной и той же группе
объектов. Каждая строка в этих таблицах однозначно
определяет один объект из соответствующей группы.
 Вообще, база данных может состоять из одной или
нескольких таблиц. Запись, в свою очередь, состоит
из нескольких полей, каждое из которых содержит
элемент данных об объекте.
Отношения между таблицами
 Отношения между таблицами устанавливают связь между данными находящимися в
разных таблицах базы данных.
 Отношения между таблицами определяются отношением между группами объектов
соответствующего типа. Например, один автор может написать несколько книг и
издать их в разных издательствах. Или издательство может опубликовать несколько
книг разных авторов. Таким образом, между авторами и названиями книг существует
отношение один-ко-многим, а между издательствами и авторами существует
отношение много-ко-многим.
Отношение один-к-одному
One-to-one
 Если между двумя таблицами существует отношение один-к-одному, это означает, что
каждая запись в одной таблице соответствует только одной записи в другой таблице.
 Примером такого отношения может служить отношение между таблицами AUTHORS и
PERSON с персональной информацей об авторах (домашний адрес, телефон, образование)
 Между таблицами AUTHORS и PERSON существует отношение один-к-одному, так как одна
запись, идентифицирующая автора, однозначно соответствует только одной записи в
таблице PERSON, содержащей персональные данные об авторе.
 Связь между таблицами определяется с помощью совпадающих полей: Au_ID в таблице
AUTHORS и в таблице PERSON.
Отношение один-ко-многим
One-to-many

 Хорошим примером отношения между таблицами один-ко-многим является отношение


между издательствами и названиями изданных книг (таблицы PUBLISHERS и TITLES), так
как одно издательство может иметь отношение к созданию нескольких книг.
 Связь между таблицами AUTHORS и TITLES осуществляется с помощью совпадающих
полей PubID в обеих таблицах.
Отношение много-ко-многим
Many-to-many
 При отношении между двумя таблицами много-ко-многим каждая запись в одной
таблице связана с несколькими записями в другой таблице и наоборот. Иллюстрацией
такого отношения может служить отношение между таблицами PUBLISHERS и AUTHORS.
С одной стороны, каждое издательство может публиковать книги разных авторов и с
другой стороны - каждый автор может публиковаться в разных издательствах.
 Для удобства работы с таблицами, имеющими отношение много-ко-многим, обычно в
базу данных добавляют еще одну таблицу (мостик), которая находится в отношении
один-ко-многим и много-к-одному к соответствующим таблицам. В случае базы данных
BIBLIO.MDB такой таблицей является TITLE AUTHOR
Задача 2
 Определите тип отношения между таблицами:
Ответ:
Задача 3
 Определите тип отношения между таблицами:
Ответ:
Нормализация баз данных
 Рассмотрим процесс нормализации базы данных на примере базы данных BIBLIO.MDB.
 Вообще говоря, все данные о книгах, авторах и издательствах можно разместить в одной
таблице, названной, например, BIBLIOS. Можно работать и с такой таблицей, однако
такая структура данных является неэффективной. В таблице BIBLIOS будет достаточно
много повторяющихся данных, например сведения об издательстве или авторе будут
повторяться для каждой опубликованной книги.
Нормализация баз данных
Такая организация данных приведет к следующим проблемам, с которыми столкнется конечный
пользователь вашей программы:
1.Наличиеповторяющихся данных приведет к неоправданному увеличению размера файла базы данных.
Кроме нерационального использования дискового пространства, это также вызовет заметное замедление
работы приложения.
2.Вводпользователем большого количества повторяющейся информации неизбежно приведет к
возникновению ошибок.
3.Изменение,например, номера телефона издательства потребует значительных усилий по
корректировке каждой записи, содержащей данные об издателе.

Чтобы избежать всех этих проблем, надо стремиться максимально уменьшить количество повторяющейся
информации. Процесс уменьшения избыточности информации в базе данных посредством разделения ее
на несколько связанных друг с другом таблиц и называется нормализацией данных.
Целью нормализации реляционной базы данных является устранение недостатков структуры базы
данных, приводящих к избыточности, которая, в свою очередь, потенциально приводит к различным
аномалиям и нарушениям целостности данных.
Нормализация баз данных
Для того, чтобы построить достаточно эффективную структуру данных, достаточно
придерживаться нескольких простых правил:
1.Определите таблицы таким образом, чтобы записи в каждой таблице описывали объекты одного
и того же типа. В нашем случае библиографические данные можно разместить в трех таблицах:
PUBLISHERS - содержит информацию об издательствах;
AUTHORS - содержит информацию об авторах книг;
TITLES - содержит информацию об изданных книгах.
1.Если в вашей таблице появляются поля, содержащие аналогичные данные, разделите таблицу.
2.Незапоминайте в таблице данных, которые могут быть вычислены при помощи данных из других
таблиц.
3.Используйтевспомогательные таблицы. Например, если в вашей таблице есть поле Страна, то
может быть стоит ввести вспомогательную таблицу Country, которая будет содержать
соответствующие записи (Россия, Украина, США и т.п.). Этот прием также поможет уменьшить
количество ошибок при вводе данных, допускаемых пользователями.
Первичные и внешние ключи
 Как было отмечено выше при описании отношений между таблицами, в реляционных базах данных таблицы
связываются друг с другом посредством совпадающих значений ключевых полей. Ключевым полем может быть
практически любое поле в таблице. Ключ может быть первичным (primary key) или внешним (foreign key).
 Под первичным ключом понимают поле или набор полей, однозначно (уникально) идентифицирующих запись. В
качестве первичного ключа в таблице «Преподаватель» может выступать только «Таб. №»,  значения других полей
могут повторяться внутри данной таблицы. Желательно всегда определять первичный ключ для таблицы БД.

 Внешний ключ – это одно или несколько полей (атрибутов), которые являются первичными в другой таблице и
значение которых заменяется значениями первичного ключа другой таблицы.
Первичные и внешние ключи
Задача 4
Определите первичные и внешние ключи:

1)

2)
Ответы:
1)

2)
Первичные и внешние ключи
 Первичный ключ очень важен для каждой таблицы:
• Primary key не позволяет создавать одинаковых записей (строк) в таблице;
• Primary key обеспечивают логическую связь между таблицами одной базы данных
(для реляционных БД).

 Часто ключевое поле не несет никакой смысловой нагрузки и является просто


идентификатором объекта в таблице.

 Во многих случаях удобно использовать в качестве ключа поле счетчика (Counter


field). При этом вся ответственность по поддержанию уникальности ключевого поля
снимается с пользователя и перекладывается на процессор баз данных. Поле
счетчика представляет собой четырехбайтовое целое число (Long) и автоматически
увеличивается на единицу при добавлении пользователем новой записи в таблицу.
Простые/составные ключи

 Ключи делятся на два класса: простые и составные.


 Простой ключ состоит только из одного атрибута. Например, в базе «Паспорта граждан
страны» номер паспорта будет простым ключом: ведь не бывает двух паспортов с
одинаковым номером.
 Составной ключ состоит из нескольких атрибутов. В той же базе «Паспорта граждан
страны» может быть составной ключ со следующими атрибутами: фамилия, имя,
отчество, дата рождения. Это — как пример, т. к. этот составной ключ, теоретически, не
обеспечивает гарантированной уникальности записи.
Индексирование
 Данные запоминаются в таблице в том порядке, в котором они вводятся пользователем.
Это, так называемый, физический порядок следования записей.

 Часто требуется представить данные в другом, отличном от физического, порядке.


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

 Одними из основных требований, предъявляемым к системам управления базами


данных, являются возможность представления данных в определенном, отличном от
физического, порядке и возможность быстрого поиска определенной записи.
Эффективным средством решения этих задач является использование индексов.
Индексирование
 Индекс представляет собой таблицу, которая содержит ключевые значения для каждой
записи в таблице данных и записанные в порядке, требуемом для пользователя.
 Ключевые значения определяются на основе одного или нескольких полей таблицы.
Кроме того, индекс содержит уникальные ссылки на соответствующие записи в таблице.
 Таблица CUSTOMERS содержит информацию о покупателях. Таблица Индексов IDX_NAME
построена на основе поля Name таблицы CUSTOMERS. Индекс IDX_NAME содержит
значения ключевого поля Name, упорядоченные в алфавитном порядке, и ссылки на
соответствующие записи в таблице CUSTOMERS.
Индексирование
 Каждая таблица может иметь несколько различных индексов, каждый из которых определяет
свой собственный порядок следования записей. Например, таблица AUTHORS может иметь
индексы для представления данных об авторах, упорядоченные по дате рождения или по
алфавиту. Таким образом, каждый индекс используется для представления одних и тех же
данных, но упорядоченных различным образом.
 Таблицы в БД могут и не иметь индексов. В этом случае для большой таблицы время поиска
определенной записи может быть весьма значительным и использование индекса становиться
необходимым. С другой стороны, не следует увлекаться созданием слишком большого количества
индексов, так как это может заметно увеличить время необходимое для обновления БД и
значительно увеличить размер файла базы данных.
 При разработке приложений, работающих с БД, наиболее широко используются простые индексы.
Простые индексы используют значения одного поля таблицы. Примером простого индекса в БД
BIBLIO.MDB может служить код ISBN, идентификатор автора Au_ID или издательства PubID.
Индексирование (вывод)
 Одна из основных задач, возникающих при работе с БД, – это задача поиска. При этом,
поскольку информации в БД, как правило, содержится много, перед программистами
встает задача не просто поиска, а эффективного поиска, т.е. поиска за сравнительно
небольшое время и с достаточной точностью. Для оптимизации производительности
запросов производят индексирование некоторых полей таблицы.
 Использовать индексы полезно для быстрого поиска строк с указанным значением одного
столбца. Без индекса чтение таблицы осуществляется по всей таблице, начиная с первой
записи, пока не будут найдены соответствующие строки. Если же таблица содержит
индекс по рассматриваемым столбцам, то БД может быстро определить позицию для
поиска в середине файла данных без просмотра всех данных.
 Это происходит потому, что БД помещает проиндексированные поля ближе в памяти,
так, чтобы можно было быстрее найти их значения. Для таблицы, содержащей
1000 строк, это будет как минимум в 100 раз быстрее по сравнению с последовательным
перебором всех записей.
Проектирование базы данных

 Термин «реляционный» означает «основанный на отношениях». Реляционная база данных


состоит из сущностей (таблиц), находящихся в некотором отношении друг с другом.
Название произошло от английского слова relation—отношение.
 Проектирование базы данных состоит из двух основных фаз: логического и физического
моделирования.
 Во время логического моделирования вы собираете требования и разрабатываете модель
базы данных, не зависящую от конкретной СУБД. Это похоже на то, как если бы вы
создавали чертежи вашего дома. Вы могли бы продумать и начертить все: где будет
кухня, спальни, гостиная. Но это все на бумаге и в макетах.
 Во время физического моделирования вы создаете модель, оптимизированную для
конкретного приложения и СУБД. Именно эта модель реализуется на практике. Если
вернуться к дому из предыдущего абзаца, на этом этапе вам придется строить где-
нибудь дом — таскать бревна, кирпичи
Проектирование базы данных

Процесс проектирования базы данных состоит из следующих этапов:

сбор требований (информации);


определение сущностей;
определение атрибутов для каждой сущности;
определение связей между сущностями;
нормализация;

преобразование к физической модели;


создание базы данных.

Первые 5 этапов образуют фазу логического проектирования, а остальные два — фазу


физического моделирования.
Сбор требований
 На этом этапе вам необходимо точно определить, как будет использоваться БД и какая
информация будет в ней храниться. Соберите как можно больше сведений о том, что
система должна делать и чего не должна.
 Сбор и анализ требований пользователей (по предметной области):
Определение сущностей

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

Любая таблица имеет следующие характеристики:


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

На этом этапе вам необходимо выявить все категории информации (сущности), которые
будут храниться в базе данных.
Определение атрибутов
 Атрибут представляет свойство, описывающее сущность.
 Атрибуты часто бывают числом, датой или текстом. Все данные, хранящиеся в атрибуте,
должны иметь одинаковый тип и обладать одинаковыми свойствами.
 После определения сущностей необходимо определить все атрибуты этих сущностей.
На диаграммах атрибуты обычно перечисляются внутри прямоугольника сущности. На
рисунке вы найдете пример базы данных «Дома», только теперь для сущностей из этой
базы определены некоторые атрибуты.
Определение атрибутов
Для каждого атрибута определяется тип данных, их размер, допустимые значения и
любые другие правила. К их числу относятся правила обязательности заполнения,
изменяемости и уникальности.

Правило обязательности заполнения определяет, является ли атрибут обязательной


частью сущности. Если атрибут является необязательной частью сущности, то он может
принимать NULL-значение, иначе — нет.
Определите, является ли атрибут изменяемым. Значения некоторых атрибутов не могут
измениться после создания записи.
Нужно определить, является ли атрибут уникальным. Если это так, то значения атрибута
не могут повторяться.
Типы ключей
 Возможный ключ представляет собой любой набор атрибутов, однозначно идентифицирующих
запись в таблице. Возможный ключ может быть простым или составным. Каждая сущность
должна иметь, по крайней мере, один возможный ключ, хотя таких ключей может быть и
несколько. Ни один из атрибутов первичного ключа не может принимать неопределенное
(NULL) значение. Возможный ключ называется также суррогатным.
 Первичным ключом называется совокупность атрибутов, однозначно идентифицирующих
запись в таблице (сущности). Один из возможных ключей становится первичным ключом.
 Любой возможный ключ, не являющийся первичным, называется альтернативным ключом.
Сущность может иметь несколько альтернативных ключей.
 Внешним ключом называется совокупность атрибутов, ссылающихся на первичный или
альтернативный ключ другой сущности. Если внешний ключ не связан с первичной сущностью,
то он может содержать только неопределенные значения. Если при этом ключ является
составным, то все атрибуты внешнего ключа должны быть неопределенными.
Определение связей между сущностями
 Реляционные БД позволяют объединять информацию, принадлежащую разным сущностям.
 Отношение — это ситуация, при которой одна сущность ссылается на первичный ключ второй
сущности. Как, например, сущности Дом и Хозяин на предыдущем рисунке. Отношения
определяются в процессе проектирования базы. Для этого следует проанализировать сущности и
выявить логические связи, существующие между ними:
1. Один-к-одному
2. Один-ко-многим
3. Многие-ко-многим

 По критерию обязательности отношения делятся на обязательные и необязательные.


1. Обязательное отношение означает, что для каждой записи из первой сущности непременно
должны присутствовать связанные записи во второй сущности.
2. Необязательное отношение означает, что для записи из первой сущности может и не
существовать записи во второй сущности.
Нормализация

 Нормализацией называется процесс удаления избыточных данных из БД. Каждый


элемент данных должен храниться в базе в одном и только в одном экземпляре.
 Существует пять распространенных форм нормализации. Как правило, база данных
приводится к третьей нормальной форме.
 В процессе нормализации выполняются определенные действия по удалению
избыточных данных. Нормализация повышает быстродействие, ускоряет сортировку
и построение индекса, уменьшает количество индексов на сущность, ускоряет
операции вставки и обновления.
 Нормализованная база данных обычно отличается большей гибкостью. При
модификации запросов или сохраняемых данных в нормализованную базу обычно
приходится вносить меньше изменений, а внесение изменений имеет меньше
последствий.
 Плюсы – быстрая запись, минусы – чтение данных занимает больше времени.
Первая нормальная форма (1NF)

 Чтобы преобразовать сущность в первую нормальную


форму, следует исключить повторяющиеся группы
значений и добиться того, чтобы каждый атрибут
содержал только одно значение, списки значений не
допускаются.
 Другими словами, каждый атрибут в сущности должен
храниться только в одном экземпляре. Например,
сущность Дом не нормализована и содержит несколько
атрибутов для хранения данных о владельцах дома.
 Для приведения сущности Дом в первую нормальную
форму необходимо удалить повторяющиеся группы
значений, т. е. удалить атрибуты Владелец 1—3,
поместив их в отдельную сущность
Вторая нормальная форма (2NF)
 Таблица во второй нормальной форме содержит только те данные, которые к ней
относятся. Значения не ключевых атрибутов сущности зависят от первичного ключа.
 Для соответствия второй нормальной форме сущности должны быть в первой
нормальной форме.
 Например, у сущности Дом есть атрибут Цена литра бензина, который не имеет ничего
общего с домами. Этот атрибут удаляется (или вы можете перенести его в другую
сущность). А также мы переносим атрибут Мэр в отдельную сущность — этот атрибут
зависит от города, где находится дом, а не от дома.
Третья нормальная форма (3NF)
 В третьей нормальной форме исключаются атрибуты, не зависящие от всего ключа.
 Любая сущность, находящаяся в третьей нормальной форме, находится также и во
второй. Это самая распространенная форма базы данных.
 В третьей нормальной форме каждый атрибут зависит от ключа, от всего ключа и ни
от чего, кроме ключа. Например, у сущности Владелец дома есть атрибут Знак
зодиака, который зависит от даты рождения владельца дома, а не от его имени
(которое является ключом). Для приведения сущности Владелец дома необходимо
создать сущность Знаки зодиака и перенести туда атрибут Знак зодиака.
Денормализация
 Денормализация — это умышленное изменение структуры базы, нарушающее правила
нормальных форм. Обычно это делается с целью улучшения производительности БД.
 Теоретически, надо всегда стремиться к полностью нормализованной базе, однако на
практике полная нормализация базы почти всегда означает падение производительности.
 Чрезмерная нормализация БД может привести к тому, что при каждом извлечении данных
придется обращаться к нескольким таблицам. Обычно в запросе должны участвовать
четыре таблицы или менее.
 Стандартными приемами денормализации являются: объединение нескольких таблиц в
одну, сохранение одинаковых атрибутов в нескольких таблицах, а также хранение в
таблице сводных или вычисляемых данных.
Задача 5
Определите, является ли БД нормализованной:
Задача 6
Определите, является ли БД нормализованной:
Задача 7
Определите, является ли БД нормализованной:
Ответ
Ограничения
Constraints
 Ограничения (constrains) — это правила, за соблюдением которых следит система управления
БД. Ограничения определяют множество значений, которые можно вводить в столбец или
столбцы.
 Например, вы не хотите, чтобы сумма заказа в вашем очень крутом магазине была бы меньше
500 рублей. Вы просто устанавливаете ограничение на колонку Сумма заказа.
 Наиболее часто используемых ограничений в SQL:
• NOT NULL Constraint — столбец не может иметь значение NULL.
• DEFAULT Constraint — задает значение по умолчанию для столбца, если оно не указано.
• UNIQUE Constraint — все значения в столбце должны быть разными.
• PRIMARY Key — уникальная идентификация каждой строки/записи в таблице базы данных.
• FOREIGN Key — уникально идентифицирует строку/запись в любой другой таблице базы
данных.
• CHECK Constraint — ограничение CHECK обеспечивает, чтобы все значения в столбце
удовлетворяли определенным условиям.
• INDEX — используется для быстрого создания данных базы данных.
Хранимые процедуры
Stored procedures
 Хранимые процедуры (stored procedures) — это предварительно откомпилированные
процедуры, хранящиеся в БД.
 Хранимые процедуры можно использовать для определения деловых правил, с их
помощью можно осуществлять более сложные вычисления, чем с помощью одних лишь
ограничений.
 Хранимые процедуры могут содержать логику хода выполнения программы, а также
запросы к базе данных. Они могут принимать параметры и возвращать результаты в
виде таблиц или одиночных значений.
 Хранимые процедуры похожи на обычные процедуры или функции в любой программ
 Хранимые процедуры находятся в БД и выполняются на сервере базы данных. Как
правило, они быстрее операторов SQL, поскольку хранятся в компилированном виде.
Целостность данных
 Организовав данные в таблицы и определив связи между ними, можно считать, что была
создана модель, правильным образом отражающая бизнес-среду. Теперь нужно
обеспечить, чтобы данные, вводимые в базу, давали правильное представление о
состоянии дела. Иными словами, нужно обеспечить выполнение деловых правил и
поддержку целостности (integrity) базы данных.
 Например, ваша компания занимается доставкой книг. Вы вряд ли примете заказ от
неизвестного клиента, ведь тогда вы даже не сможете доставить заказ. Отсюда бизнес-
правило: заказы принимаются только от клиентов, информация о которых есть в БД.
Корректность данных в реляционных базах обеспечивается набором правил.
Целостность данных
 Правила целостности данных делятся на четыре категории:
 Целостность сущностей — каждая запись сущности должна обладать уникальным
идентификатором и содержать данные. Ведь надо же вам как-то различать все эти записи в
базе данных.
 Целостность атрибутов — каждый атрибут принимает лишь допустимые значения.
Например, сумма покупки, определенно, не может быть меньше нуля.
 Ссылочная целостность — набор правил, обеспечивающих логическую согласованность
первичных и внешних ключей при вставке, обновлении и удалении записей. Ссылочная
целостность обеспечивает, чтобы для каждого внешнего ключа существовал
соответствующий первичный ключ. (Возьмем предыдущий пример с сущностями Владелец
дома и Дом. Допустим, вы Вася Иванов и владеете домом. Вы сменили фамилию на
Сидоров и внесли соответствующие изменения в сущность Владелец дома. Определенно
вы бы хотели, чтобы ваш дом продолжал числиться за вами под вашим новым именем, а
не принадлежал некоему Васе Иванову, которого уже не существует).
 Пользовательские правила целостности — любые правила целостности, не относящиеся ни
к одной из перечисленных категорий
Триггеры

 Триггер — это аналог хранимой процедуры, который вызывается автоматически при


изменении данных в таблице.
 Триггеры являются мощным механизмом для поддержания целостности базы данных.
 Триггеры вызываются до или после изменения данных в таблице. С их помощью можно
не только отменить эти изменения, но и изменить данные в любой другой таблице.
 Например, вы создаете интернет-форум, и вам необходимо сделать так, чтобы в списке
форумов показывалось последнее сообщение форума. Конечно, вы можете брать
сообщение из сущности Сообщения форума, но это увеличит сложность вашего запроса
и время его выполнения. Проще добавить триггер к сущности Сообщения форума,
который бы записывал последнее добавленное сообщение в сущность Форумы, в
атрибут Последнее сообщение. Это сильно упростит запрос.
Деловые правила
 Деловые правила определяют ограничения, накладываемые на данные в соответствии с
требованиями бизнеса (тех, для кого вы создаете базу). Деловые правила могут
состоять из набора шагов, необходимых для выполнения определенной задачи, или же
они могут быть просто проверками, которые контролируют правильность введенных
данных.
 Деловые правила могут включать правила целостности данных. Их главная цель —
обеспечить правильное ведение деловых операций. Например, в компании «СтройКом»
может быть так принято, что закупаются для служебных нужд только белые, синие и
черные автомобили. Тогда деловое правило для атрибута Цвет автомобиля сущности
Служебные автомобили будет гласить, что автомобиль может быть только белым,
синим или черным.
Физическая модель

 Следующим шагом, после создания логической модели, является построение


физической модели.
 Физическая модель — это практическая реализация БД. Физическая модель определяет
все объекты, которые вам предстоит реализовать.
 При переходе от логической модели к физической сущности преобразуются в таблицы,
а атрибуты в столбцы. Отношения между сущностями можно преобразовать в таблицы
или оставить как внешние ключи.
 Первичные ключи преобразуются в ограничения первичных ключей. Возможные ключи
— в ограничения уникальности.
Lakeview Equipment Rentals занимается прокатом оборудования (краны, экскаваторы)

Задача 8
Job (проект), Contractor (подрядчик), Phone (телефон), Equipment type (тип оборудования), Equipment number (номер оборудования), Daily rate
(плата за день), Start date (дата начала), End date (дата окончания), Days (количество дней), Charge (стоимость)
Что случится, если у подрядчика KH Services изменится номер телефона?
Фирма RB Partnership решила не брать в прокат экскаватор (backhoe).
Фирма Swaging имеет телефон 206-555-8989 и работает над реконструкцией моста на Центральной улице. Мы хотим
записать эти данные, но эта компания еще ничего не брала у нас в прокат.
Описка - KJ Services вместо KH Services.
Прокат экскаватора с номером 10020 - ежедневная плата 650 долларов или 750 долларов?
В записи о прокате строительных лесов (Scaffolding) нет конечной даты.
Корпоративное хранилище данных
Data Warehouse
 Хранилище данных (Data Warehouse) — предметно-ориентированная информационная
база данных, специально разработанная и предназначенная для подготовки отчётов и
бизнес-анализа с целью поддержки принятия решений в организации. Это хранилище
очищенной интегрированной информации, полученной от многих систем, из которого
информация поступает к конечным пользователям или в витрины данных.
 Строится на базе СУБД и систем поддержки принятия решений.
 Данные из системы копируются в хранилище данных таким образом, чтобы при
построении отчётов и OLAP-анализе не использовались ресурсы транзакционной системы и
не нарушалась её стабильность.
 Есть два варианта обновления данных в хранилище:
1. полное обновление данных в хранилище. Сначала старые данные удаляются, потом
происходит загрузка новых данных. Процесс происходит с определённой периодичностью,
при этом актуальность данных может несколько отставать от OLTP-системы (Online
Transaction Processing);
2. инкрементальное обновление — обновляются только те данные, которые изменились в
OLTP-системе.
Принципы организации хранилища

 Проблемно-предметная ориентация. Данные объединяются в категории и хранятся


в соответствии с областями, которые они описывают, а не с приложениями, которые
они используют.

 Интегрированность. Данные объединены так, чтобы они удовлетворяли всем


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

 Некорректируемость. Данные в хранилище данных не создаются: то есть поступают


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

 Зависимость от времени. Данные в хранилище точны и корректны только в том


случае, когда они привязаны к некоторому промежутку или моменту времени.
Дизайн хранилищ данных
 Существуют два основных архитектурных направления — нормализованные хранилища данных и
хранилища с измерениями.
1. В нормализованных хранилищах, данные находятся в предметно ориентированных таблицах третьей
нормальной формы. Нормализованные хранилища характеризуются как простые в создании и
управлении, недостатки нормализованных хранилищ — большое количество таблиц как следствие
нормализации, из-за чего для получения какой-либо информации нужно делать выборку из многих
таблиц одновременно, что приводит к ухудшению производительности системы. Для решения этой
проблемы используются денормализованные таблицы — витрины данных, на основе которых уже
выводятся отчетные формы (срез хранилища данных, представляющий собой массив тематической,
узконаправленной информации, ориентированный, например, на пользователей одной рабочей
группы или департамента).
2. Хранилища с измерениями используют схему «звезда» или схему «снежинка». Основным
достоинством хранилищ с измерениями является простота и понятность для разработчиков и
пользователей, также, благодаря более эффективному хранению данных и формализованным
измерениям, облегчается и ускоряется доступ к данным, особенно при сложных анализах. Основным
недостатком является более сложные процедуры подготовки и загрузки данных, а также управление
и изменение измерений данных. При достаточно большом объеме данных схемы «звезда» и
«снежинка» также дают снижение производительности при соединениях с измерениями.
OLAP-анализ
 OLAP (online analytical processing, интерактивная аналитическая обработка) — технология
обработки данных, заключающаяся в подготовке суммарной (агрегированной) информации на
основе больших массивов данных, структурированных по многомерному принципу. Реализации
технологии OLAP являются компонентами программных решений класса Business Intelligence.
 Причина использования OLAP для обработки запросов — скорость. Реляционные базы данных
хранят сущности в отдельных таблицах, которые обычно хорошо нормализованы. Эта структура
удобна для операционных баз данных (системы OLTP), но сложные многотабличные запросы в
ней выполняются относительно медленно.
OLAP-анализ

 OLAP-структура, созданная из рабочих данных, называется OLAP-куб. Это многомерный


массив данных, как правило, разреженный и долговременно хранимый
 Куб создаётся из соединения таблиц с применением схемы звезды или схемы снежинки.
В центре схемы звезды находится таблица фактов, которая содержит ключевые факты, по
которым делаются запросы. Множественные таблицы с измерениями присоединены к
таблице фактов. Эти таблицы показывают, как могут анализироваться агрегированные
реляционные данные.
Slowly Changing Dimensions

 Медленно меняющиеся измерения (Slowly Changing Dimensions, SCD) — механизм


отслеживания изменений в данных измерения в терминах хранилища данных.
Применяется в случае, если данные меняются не очень часто и не по расписанию.
 Примером могут служить географические данные (местонахождение склада,
юридический адрес организации), статус заказчика по программе лояльности или отдел
компании, в котором работает её сотрудник.
 Выделяют несколько типов SCD:
 Тип 0 - Нулевой тип (SCD0) является пассивным методом, т. к. предполагается, что
значения атрибутов такого типа не будут меняться. Примерами могут служить дата
создания записи, дата и место рождения, серийный номер устройства
Slowly Changing Dimensions

 Тип 1 - Первый тип (SCD1) использует простое затирание: данные в таблице полностью
заменяются на новые (самые актуальные). Историчность при этом полностью теряется, т.
е. после обновления невозможно отследить цепочку изменений.

 Суррогатный ключ (ID записи) остаётся прежним. Значения полей «Должность» и


«Отдел» заменяются на новые. Бизнес-ключ (Табельный номер) в данном примере не
меняется, но может быть изменен при необходимости по аналогии с другими полями.
Slowly Changing Dimensions
 Тип 2 - Второй тип (SCD2) использует добавление новой строки и дополнительных столбцов. Такой
подход позволяет сохранить историчность.
 Дополнительно можно добавить служебные столбцы, которые могут отвечать за версионирование,
статус, временной интервал, в течение которого данные строки можно считать актуальными.

 Суррогатный ключ (ID записи) создаётся новый. Бизнес-ключ (Табельный номер) не меняется, что
позволяет связать добавленную строку с оригинальной
Slowly Changing Dimensions

 Тип 3 - Третий тип (SCD3) использует добавление новых столбцов-атрибутов, хранящих


предыдущее значение для поддержания историчности. Такой тип в чистом виде
возникает редко, и нужен бизнесу для ситуаций, когда необходимо отслеживать
изменения только по конкретным параметрам.
 Третий тип сохраняет лишь ограниченную историчность (с точностью только до
предыдущего значения), что делает его менее содержательным по сравнению с типом 2
Процессы работы с данными

 Источниками данных могут быть:


1. Традиционные системы регистрации операций
2. Отдельные документы
3. Наборы данных
 Операции с данными:
1. Извлечение — перемещение информации от источников данных в отдельную БД,
приведение их к единому формату.
2. Преобразование — подготовка информации к хранению в оптимальной форме для
реализации запроса, необходимого для принятия решений.
3. Загрузка — помещение данных в хранилище, производится атомарно, путём добавления
новых фактов или корректировкой существующих.
4. Анализ — OLAP, Data Mining (глубинный анализ данных), сводные отчёты.
5. Представление результатов анализа.
Business intelligence

 Business intelligence (BI) — обозначение компьютерных методов и инструментов для


организаций, обеспечивающих перевод транзакционной деловой информации в
понятную форму, пригодную для бизнес-анализа, а также средства для массовой
работы с такой обработанной информацией.
 Цель BI — интерпретировать большое количество данных, заостряя внимание лишь на
ключевых факторах эффективности, моделируя исход различных вариантов
действий, отслеживая результаты принятия решений.
 BI платформы: Tableau, QlikView, Power BI, IBM Cognos Analytics и другие
Вопросы?
Спасибо за внимание!