Введение в базы данных

1.

1
ЛЕКЦИЯ № 5
Введение в базы данных

2. 1. Понятие базы данных

2
1. Понятие базы данных
Под базой данных (БД) понимается хранилище структурированных данных, при этом
данные должны быть непротиворечивы, минимально избыточны и целостны.
Как правило, базы данных создаются для хранения и доступа к данным, содержащим
сведения о некоторой предметной области, то есть некоторой области человеческой
деятельности или области реального мира. Таким образом, всякая база данных должна
представлять собой систему данных о некоторой предметной области. База данных
относящихся к одной предметной области, в различных ситуациях содержат более или менее
детализированную информацию о ней. Степень детализации определяется рядом факторов,
прежде всего целью использования информации из базы данных и сложностью
производственных (деловых) процессов, существующих в пределах предметной области в
конкретных условиях.
Рассмотрим в качестве примера предметной области отпуск товара со склада.
Предположим, что существует две организации, независимые друг от друга, и
испытывающие потребность в автоматизации своих производственных процессов. Для
организации А характерно невысокий ассортимент хранимых и отпускаемых товаров.
Ассортимент отличается стабильностью. Состав реальных покупателей товаров исчисляется
несколькими лицами (только юридическими). Предоплаты за еще не отпущенный товар не
допускается, отпуск товара в кредит не практикуется, система скидок отсутствует. Оплата
производится в рублях. Отпуск товаров осуществляется только с одного склада.

3.

3
Потребности в автоматизации учета отпуска товаров определяется двумя задачами:
1) быстрой выдачей информации о текущих остатках товара на складе;
2) ежемесячной выдачей отчета об общих суммарных отпусках товара.
Организация Б характеризуется множеством территориально распределенных складов, в
том числе в различных государствах ближнего зарубежья. Ассортимент отпускаемых
товаров высок и быстро изменчив в силу изменчивости спроса. Состав покупателей
разнообразен, в число покупателей входят как физические лица, так и юридические лица.
Практикуется система скидок постоянным покупателям, приобретающим товар свыше
определенного количества и (или) суммы. Развита система предоплат, отпуска товаров в
кредит. Оплата производится в местной валюте по текущему курсу доллара, реже – рубля.
Потребности в автоматизации учета отпуска товаров определяется широким диапазоном
целей:
1) быстрым получением информации о текущих остатках товара, в том числе
а) на конкретном складе;
б) по регионам;
в) по всей организации;
2) получением счета об общих суммарных отпусках товара за любой временной интервал в
любой валюте, в том числе
а) по всей организации;
б) по конкретному региону, где расположены склады;
в) по конкретному складу;
г) по конкретному покупателю – отдельно для физических и юридических лиц;
д) по группам покупателей, объединенным по единому признаку, например,
территориальному.

4.

4
3) зачетом предоплат и задолженностей отдельных покупателей;
4) автоматическим переводом покупателей в льготные категории, имеющие право на тот
или иной вид скидки;
5) прогнозированием с определенным уровнем вероятности будущего спроса (по
покупателю, товару, региону и т.д.).
В виду различия целей внедрения БД и содержания деловых процессов в организациях А и
Б, созданные в них БД будут существенно различаться друг от друга – прежде всего
детализацией хранимой информации и, следовательно, структурой данных. Если в
организации А в БД достаточно хранить сведения о приходе и расходе товаров и о ценах на
них, то в БД организации Б необходимо хранить десятки таблиц и в процессе работы тратить
дополнительные усилия для того, чтобы поддерживать их в согласованном состоянии.
В настоящее время широко используются реляционные базы данных, представляющие
связанную совокупность таблиц, хранящие информацию о какой-либо предметной области.

5. 2. Проектирование реляционных баз данных

5
2. Проектирование
реляционных баз данных
Прежде чем приступать к рассмотрению конкретных проблем и алгоритмов проектирования
БД, необходимо иметь четкое представление о процессе и целях проектирования.
Цели и этапы проектирования БД. Прежде чем переходить к целям, перечислим некоторые
из этапов проектирования реляционных БД:
1) Определение объектов (источников данных), которые должны быть включены в БД;
2) Выявление связей между объектами;
3) Определение основных свойств объектов;
4) Определение отношений между таблицами БД, на основе связей между объектами
данных, содержащимся в них;
5) Определение операций, выполняемых при создании и изменении информации в
таблицах, включая обеспечение целостности данных;
6) Выявление индексов, необходимых для ускорения выполнения запросов;
7) Учет вопросов безопасности – какие полномочия и каким пользователям предоставлять;
8) Разработка процедур создания резервных копий и востановления исходных данных.

6.

6
Представленный список конечно же не полон, но позволяет составить представление о тех
действиях, которые необходимо выполнить. Каждый этап проектирования зависит от
результатов предыдущих, и чем тщательнее он будет продуман, тем меньше итераций
(возвратов) понадобится в дальнейшем.
Среди целей наиболее важным представляются следующие:
а) возможность хранения в БД всех необходимых данных;
б) исключение избыточности данных;
в) сведение к минимуму числа хранимых в БД таблиц;
г) нормализация таблиц для упрощения решения проблем, связанных с обновлением и
удалением данных.
Рассмотрим каждую из этих целей подробнее.
Возможность хранения в БД всех необходимых данных. Первым шагом в процессе
проектирования БД является определение всех атрибутов, которые должны быть помещены
в БД, поскольку отсутствие в ней представляющей в интерес информации сводит на нет
ценность всей БД. После определения всех атрибутов нужно решить, сколько требуется
таблиц и какие атрибуты в какие таблицы надо включать. Это определяется целью
использования информации и набором производственных процессов, требующих своей
автоматизации.

7.

7
Исключение избыточности данных. Суть этой цели очевидна проектировщику БД.
Основным здесь является четкое понимание различия между дублированием данных и
избыточным дублированием данных. Рассмотрим эту разницу на примере. В качестве
примера возьмем таблицу Книга – Автор имеющую вид
Таблица 1
Книга
Автор
Разработка клиентских приложений для SQL Server 7
Тихомиров Юрий
Visual C++ и MFC, т. 1
Мешков Андрей
Open GL: Программирование трехмерной графики
Тихомиров Юрий
Visual C++ и MFC, т. 2
Мешков Андрей
Таблица 1 имеет два атрибута Книга (название книги) и Автор (фамилия и имя автора книги) и
содержит данные, указывающие авторов каждой конкретной книги. Фамилии авторов могут
появляться неоднократно, поскольку один автор может написать не одну книгу. При этом
Тихомиров Юрий и Мешков Андрей в таблице появляются дважды, ни одно из них не
является избыточным. Причина в том, что удаление любого из них приводит к потере
информации. Результат такого удаления представлен в Таблице 2.

8.

8
Таблица 2
Книга
Автор
Разработка клиентских приложений для SQL Server 7
Тихомиров Юрий
Visual C++ и MFC, т. 1
Мешков Андрей
Open GL: Программирование трехмерной графики
-
Visual C++ и MFC, т. 2
-
В данном случае нет возможности узнать кто написал книги: Open GL: Программирование
трехмерной графики и Visual C++ и MFC, т. 2 .
Рассмотрим появление избыточного дублирования данных на примере Таблицы 3 Книга –
Автор - Телефон
Таблица 3
Книга
Автор
Телефон
Разработка клиентских приложений для SQL Server 7
Тихомиров Юрий
777-77-77
Visual C++ и MFC, т. 1
Мешков Андрей
444-44-44
Open GL: Программирование трехмерной графики
Тихомиров Юрий
777-77-77
Visual C++ и MFC, т. 2
Мешков Андрей
444-44-44

9.

9
Имеем избыточное дублирование телефонов.
Таблица 4
Книга
Автор
Телефон
Разработка клиентских приложений для SQL Server 7
Тихомиров Юрий 777-77-77
Visual C++ и MFC, т. 1
Мешков Андрей
Open GL: Программирование трехмерной графики
Тихомиров Юрий -
Visual C++ и MFC, т. 2
Мешков Андрей
444-44-44
-
Но у нас появились пустые ячейки, наличие которых в таблицах недопустимо, так как при
удалении первой строки произойдет потеря информации о телефона Тихомирова для третьей
строки. Есть выход разбить Таблицу 3 на две, имеющих вид
Таблица 5
Книга
Автор
Разработка клиентских приложений для SQL Server 7
Тихомиров Юрий
Visual C++ и MFC, т. 1
Мешков Андрей
Open GL: Программирование трехмерной графики
Тихомиров Юрий
Visual C++ и MFC, т. 2
Мешков Андрей

10.

10
Таблица 6
Автор
Телефон
Тихомиров Юрий
777-77-77
Мешков Андрей
444-44-44
Сведение к минимуму числа хранимых в БД таблиц. Эта цель обусловлена тем, что
разбиение одной таблицы на две или более таблиц меньшего размера желательно с точки
зрения исключения определенных проблем, но не совсем удобно для пользователя. Таким
образом, нельзя допускать неограниченного роста числа таблиц.
Нормализация таблиц. Практически для всех таблиц очень важны проблемы удаления и
обновления (как это было продемонстрировано на предыдущем примере). Поэтому
необходимо уметь различать эти потенциально опасные таблицы и «нормализовать» их
посредством разбиения определенным образом. Нормализация представляет собой
формальную процедуру, в ходе которой одна таблица разбивается на две или несколько в
соответствии со специальной процедурой разбиения. Задачами нормализации являются:
а) исключение из таблиц повторяющейся информации;
б) создание структуры, в которой предусмотрена возможность ее будущих изменений;
в) создание структуры, в которой влияние структурных изменений на приложения
использующие информацию этой БД, сведены к минимуму.
Необходимо понимать, что при нормализации таблицы предпринимается попытка
ограничить количество повторяющихся в ней данных. Существует много уровней и типов
нормализации.

11.

11
Наиболее распространенной процедурой является приведение базы данных к третьей
нормальной форме (3NF), так как в большинстве случаев этот уровень нормализации
является компромиссом между полной нормализацией и простотой нормализации.
Существуют уровни и выше, чем 3NF, но на практике они применяются достаточно редко, так
как сильно затрудняют разработку структур данных и снижают их функциональность.
Первая нормальная форма (1NF). Первая нормальная форма – это основа реляционных баз
данных. При ней требуется, чтобы таблица была двумерной и не содержала ячеек,
включающих несколько значений. Приведем пример таблицы, которая не приведена к 1NF
Таблица 7
Название
Автор
Страницы
Цена
Тираж
Телефон
Microsoft Office
Каменский Юрий
Никитин Павел
224
20
10000
111-11-11
222-22-22
Visual C++ и MFC, т.1
Мешков Андрей
Тихомиров Юрий
464
32
10000
333-33-33
777-77-77
Visual C++ и MFC, т.2
Мешков Андрей
Тихомиров Юрий
464
32
7000
333-33-33
777-77-77
Visual C++ и MFC, т.2
Мешков Андрей
Тихомиров Юрий
384
30
5000
333-33-33
777-77-77

12.

12
продолжение Таблицы
7
Название
Автор
Страницы
Цена
Тираж
Телефон
Open GL: Программирование
трехмерной графики
Тихомиров Юрий
256
25
7000
777-77-77
Программирование в Delphi
3
Шведов Дмитрий
192
18
7000
444-44-44
Приведение таблицы к 1NF выполняется достаточно легко – при помощи простого процесса
вставки, в результате чего в таблицу добавляется большой объем избыточных данных.
Таблица приведенная к 1NF примет вид
Таблица 8
Название
Автор
Страницы
Цена
Тираж
Телефон
Microsoft Office
Каменский Юрий
224
20
10000
111-11-11
Microsoft Office
Никитин Павел
224
20
10000
222-22-22
Visual C++ и MFC, т.1
Мешков Андрей
464
32
10000
333-33-33
Visual C++ и MFC, т.1
Тихомиров Юрий
464
32
10000
777-77-77
Visual C++ и MFC, т.2
Мешков Андрей
464
32
7000
333-33-33

13.

продолжение Таблица 8
13
Название
Автор
Страницы
Цена
Тираж
Телефон
Visual C++ и MFC, т.2
Тихомиров Юрий
464
32
7000
777-77-77
Visual C++ и MFC, т.3
Мешков Андрей
384
30
5000
333-33-33
Visual C++ и MFC, т.3
Тихомиров Юрий
384
30
7000
777-77-77
Программирование в Delphi
3
Шведов Дмитрий
192
18
7000
444-44-44
Таблица 8 представляет собой экземпляр корректной таблицы, которую называют
универсальной таблицей проектируемой базы данных. В нее включают все представляющие
интерес атрибуты, и она может содержать все данные, которые предполагается размещать в
этой БД. Если число атрибутов не превышает 15, то универсальная таблица может
использоваться в качестве отправной точки при проектировании БД.
Вторая нормальная форма (2NF). Вторая нормальная форма требует, чтобы данные во всех
не ключевых столбах полностью зависели от первичного ключа или каждого поля
первичного ключа, если он является составным. Под полной зависимостью понимается то,
что значение в каждом столбце однозначно определяется значением первичного ключа. Если
же в таблице имеется хотя бы одно поле, которое не зависит от величины первичного ключа,
то в этот ключ необходимо включить дополнительные столбцы. Перед проверкой на
соответствие 2NF таблица должна быть приведена к 1NF. Процесс приведения ко второй
нормальной форме позволяет избавится от большей части повторяющихся данных,
оставшихся от первого этапа нормализации.

14.

14
В нашем примере Таблицу 8 необходимо разбит на две, вынеся в одну информацию о
книгах, а во вторую – об авторах. Видно, что в таблице Книга (Таблица 9) поле номер книги
однозначно идентифицирует все остальные столбцы таблицы и поэтому может
использоваться в качестве первичного ключа. Аналогично в таблице Автор (Таблица 10) поле
автор однозначно позволяет определить номер телефона автора. Однако при этом мы
потеряли информацию о том, какой автор написал какую книгу. Для решения этой проблемы
нужна таблица соответствия (Таблица 11). Представим набор таблиц, удовлетворяющий 2NF.
Таблица 9
Номер книги
Название
Страницы Цена
Тираж
1
Microsoft Office
224
20
10000
2
Visual C++ и MFC, т. 1
464
32
10000
3
Visual C++ и MFC, т. 2
464
32
7000
4
Visual C++ и MFC, т. 3
384
30
5000
5
Open GL: Программирование трехмерной
графики
256
26
7000
6
Программирование в Delphi 3
192
18
7000

15.

Таблица 10
Телефон
15
Автор
Мешков Андрей
333-33-33
Тихомиров Юрий
777-77-77
Каменский Юрий
111-11-11
Шведов Дмитрий
444-44-44
Никитин Павел
222-22-22
Таблица 11
Автор
Номер книги
Мешков Андрей
2
Тихомиров Юрий
2
Каменский Юрий
1
Шведов Дмитрий
6
Никитин Павел
1
Мешков Андрей
3
Тихомиров Юрий
3
Тихомиров Юрий
4
Тихомиров Юрий
5

16.

16
Легко убедится, что совокупность таблиц Табл. 9 – Табл. 11 удовлетворяет 2NF.
Третья нормальная форма (3NF). Третья нормальная форма требует, чтобы все не
ключевые столбцы таблицы зависели от первичного ключа, но были независимы друг от
друга. Очевидно, что для этого таблицы должны быть приведены к первой и второй
нормальным формам. В нашем примере все рассматриваемые таблицы уже приведены и к
3NF, поскольку они не содержат повторяющихся данных и данные не ключевых полей
зависят от значения первичного ключа.
Нормализация один из методов проектирования БД. Его достаточно легко использовать при
числе атрибутов меньше 15. В противном случае лучше пользоваться er-методом, в котором
используется схема «сущность-связь».

17.

17
СПАСИБО
ЗА
ВНИМАНИЕ !