Введение в базы данных презентация

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

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

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

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

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

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

Основным здесь является четкое понимание различия между дублированием данных и избыточным дублированием данных. Рассмотрим эту разницу на примере. В качестве примера возьмем таблицу Книга – Автор имеющую вид
Таблица 1

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

Программирование трехмерной графики и Visual C++ и MFC, т. 2 .
Рассмотрим появление избыточного дублирования данных на примере Таблицы 3 Книга – Автор - Телефон
Таблица 3

Таблица 2

появились пустые ячейки, наличие которых в таблицах недопустимо, так как при удалении первой строки произойдет потеря информации о телефона Тихомирова для третьей строки. Есть выход разбить Таблицу 3 на две, имеющих вид
Таблица 5

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

Таблица 6

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

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

продолжение Таблицы 7

универсальной таблицей проектируемой базы данных. В нее включают все представляющие интерес атрибуты, и она может содержать все данные, которые предполагается размещать в этой БД. Если число атрибутов не превышает 15, то универсальная таблица может использоваться в качестве отправной точки при проектировании БД.
Вторая нормальная форма (2NF). Вторая нормальная форма требует, чтобы данные во всех не ключевых столбах полностью зависели от первичного ключа или каждого поля первичного ключа, если он является составным. Под полной зависимостью понимается то, что значение в каждом столбце однозначно определяется значением первичного ключа. Если же в таблице имеется хотя бы одно поле, которое не зависит от величины первичного ключа, то в этот ключ необходимо включить дополнительные столбцы. Перед проверкой на соответствие 2NF таблица должна быть приведена к 1NF. Процесс приведения ко второй нормальной форме позволяет избавится от большей части повторяющихся данных, оставшихся от первого этапа нормализации.

продолжение Таблица 8

вынеся в одну информацию о книгах, а во вторую – об авторах. Видно, что в таблице Книга (Таблица 9) поле номер книги однозначно идентифицирует все остальные столбцы таблицы и поэтому может использоваться в качестве первичного ключа. Аналогично в таблице Автор (Таблица 10) поле автор однозначно позволяет определить номер телефона автора. Однако при этом мы потеряли информацию о том, какой автор написал какую книгу. Для решения этой проблемы нужна таблица соответствия (Таблица 11). Представим набор таблиц, удовлетворяющий 2NF.
Таблица 9

Таблица 11

Таблица 10

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