Слайд 2
Система управления базами данных (СУБД) — это комплекс
языковых и программных средств, предназначенный для создания, ведения и
совместного использования БД многими пользователями.
Слайд 3
Требования к базе данных
хранение данных
обеспечение доступа к данным
наличие
системы пользовательских привилегий
возможность резервного копирования и восстановления данных
распределенное хранение
данных
обеспечение поддержки транзакций
управление параллельной работой пользователей
поддержка целостности данных
предоставление некоторого набора различных вспомогательных функций
наличие интерфейса для администратора
наличие универсального языка
эффективный доступ к данным
Слайд 4
Размещение и архитектура СУБД
Слайд 5
Размещение и архитектура СУБД
Слайд 6
Размещение и архитектура СУБД
Слайд 7
Модели БД
Модель данных – это совокупность структур данных
и операций их обработки.
По способу установления связей между данными
различают модели данных:
иерархическую (начало 60-х годов XX в.)
сетевую (начало 60-х годов XX в.)
реляционную (начало 70-х годов XX в.)
Различаются способами представления взаимосвязей между объектами.
Слайд 8
Модели БД
Иерархическая модель
Слайд 10
Модели БД
Реляционная модель (предложена Эдгаром Коддом)
В
теории множеств таблица – отношение (relation). Отношение – множество
элементов, называемых кортежами.
Слайд 11
Исходные данные задачи
«Преподаватель читает курс»
K1, K2, K3
– множество учебных курсов
П1, П2, П3 – множество преподавателей
Слайд 12
Иерархическая модель задачи
«Преподаватель читает курс»
Только односторонние связи от
старших вершин к младшим
Какие курсы читает преподаватель П2?
Какие преподаватели
читают курс К1?
Слайд 13
Сетевая модель задачи
«Преподаватель читает курс»
Возможны связи «всех со
всеми»
Сложность реализации СУБД
Слайд 14
Реляционная модель задачи
«Преподаватель читает курс»
Достоинство – сравнительная простота
инструментальных средств поддержки.
Недостаток – зависимость скорости выполнения операций от
размера таблиц.
Слайд 15
Структура реляционной базы данных
Реляционная база данных - база
данных, в которой все данные представлены в виде двумерных
таблиц или отношений.
Таблица (совокупность столбцов и строк) применяется для описания некоей сущности (персона, место, событие и т.д.).
Столбец (поле) – данные одного типа.
Строка (запись) – данные всех столбцов о предмете (сущности).
Все строки должны иметь уникальный ключ
Все данные одного вида должны находиться в одном столбце
Слайд 17
Основными конструктивными элементами инфологических моделей являются сущности, связи
между ними и их свойства (атрибуты)
Сущность – любой различимый
объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д.
Атрибут — это свойство, описывающее определенный аспект объекта, значение которого следует зафиксировать в описании предметной области.
Связь – ассоциирование двух или более сущностей.
Слайд 19
Определение цели создания базы данных
Целесообразно записать цель создания
базы данных на бумаге: задачи, способы использования и список пользователей.
Наличие
описания позволяет следовать поставленным целям в процессе принятия решений.
Слайд 20
Поиск и организация необходимых данных
Процесс поиска и организации
необходимых данных следует начать с записи имеющихся сведений.
При подготовке
списка необязательно стремиться придать ему законченный вид с первого раза.
Определение структуры отчетов позволяет выявить элементы, которые требуется включить в базу данных.
Составьте список вопросов, ответы на которые требуется получать с помощью базы данных.
Слайд 21
Распределение данных по таблицам
Пример проектирования базы данных
«Продажи продуктов»
Чтобы
распределить данные по таблицам, выделите основные группы или темы.
Слайд 22
Распределение данных по таблицам
Пример проектирования базы данных
«Продажи продуктов»
Целесообразно
ли помещать все элементы в единую таблицу?
Слайд 23
Преобразование элементов данных в столбцы
Несколько советов по созданию
столбцов
не включайте в таблицу вычисляемые данные
разбивайте информацию на минимальные
логические компоненты
Слайд 24
Задание первичных ключей
Столбец или набор столбцов для однозначного
определения каждой строки таблицы носят название первичного ключа таблицы.
первичные
ключи служат для быстрого связывания данных из нескольких таблиц
первичный ключ не должен содержать повторяющихся значений
первичный ключ должен всегда иметь значение
часто в качестве первичного ключа используется произвольное уникальное числовое значение, этот номер не подлежит изменению
Слайд 25
Задание первичных ключей
Можно использовать столбец с типом
данных «Счетчик».
Бессодержательные коды идеально подходят для использования в качестве
первичного ключа, т. к. они не изменяются.
Первичный ключ, содержащий фактические данные о строке, более подвержен изменениям, т. к. фактические сведения могут измениться.
Столбец с типом данных "Счетчик" — удобный первичный ключ. Коды продуктов никогда не совпадают.
Слайд 26
Задание первичных ключей
В базе данных продаж можно создать
столбец счетчика для первичного ключа всех таблиц: "Код Товара"
для таблицы товаров, "Код Заказа" для таблицы заказов, "Код Клиента" для таблицы клиентов и "Код Поставщика" для таблицы поставщиков.
Слайд 27
Создание связей между таблицами
Отношение «один-ко-многим»
Связь между таблицами
«Поставщики» и «Продукты».
Столбец кода поставщика в таблице продуктов
- внешний ключ.
Внешний ключ — это первичный ключ другой таблицы.
Столбец кода поставщика - первичный ключ таблицы поставщиков.
Слайд 28
Создание связей между таблицами
Отношение «многие-ко-многим»
Связь между таблицами
«Продукты» и «Заказы».
Один заказ может включать несколько продуктов.
С другой стороны, отдельный продукт может содержаться в нескольких заказах.
Слайд 29
Создание связей между таблицами
Преобразование отношения «многие-ко-многим»
в два отношения
«один-ко-многим»
Слайд 30
Создание связей между таблицами
После создания таблицы сведений о
заказах список таблиц и полей может выглядеть следующим образом.
Слайд 31
Создание связей между таблицами
Слайд 32
Создание связей между таблицами
Отношение «один-к-одному»
Дополнительные сведения о
продукте, которые редко используются или применимы к небольшому числу
продуктов.
Вместо создания дополнительного пустого поля для всех продуктов лучше создать таблицу «Дополнительные сведения о продукте».
Слайд 33
Усовершенствование структуры
Отсутствие необходимых столбцов. Может потребоваться дополнительная таблица.
Наличие столбцов с данными, которые можно получать из существующих
полей путем вычислений.
Наличие многократно повторяющихся данных в таблицах. Разделить таблицу на две таблицы и связать их отношением "один-ко-многим".
Наличие таблиц с большим количеством полей и пустыми полями в отдельных записях. Изменить структуру таблицы, чтобы сократить число полей и увеличить число записей.
Разбиение каждого элемента данных на минимальные компоненты (для отчетов, сортировки, поиска или вычислений).
Наличие в столбце данных, не относящихся к теме таблицы. Поместить в другую таблицу.
Для создания отношений "один-к-одному" и "один-ко-многим" требуются общие столбцы. Для создания отношения "многие-ко-многим" требуется третья таблица.
Слайд 34
Усовершенствование структуры
таблицы «Продукты»
Таблица "Продукты" может содержать поле, в
котором указана категория продукта.
Рациональный подход — выделить категории в
качестве отдельной таблицы с собственным первичным ключом.
Выявление повторяющихся групп. Плохая структура:
Код поставщика
Код продукта
Имя
Код продукта1
Имя1
Код продукта2
Имя2
Код продукта3
Имя3
Недостатки:
верхний предел для числа продуктов
пустые столбцы
усложнение многих задач (сортировка или создание индекса таблицы по коду или наименованию продукта)
Слайд 35
Применение правил нормализации
Первая нормальная форма (1НФ)
На пересечении строки
и столбца в таблице должно содержаться одно значение.
запрещает множественные
столбцы (значения типа списка, например поле «Адрес» или «ФИО»)
запрещает повторяющиеся столбцы
требует определить первичный ключ для таблицы
Неприведенная
Приведенная
Слайд 36
Применение правил нормализации
Вторая нормальная форма (2НФ)
Каждый столбец, не
входящий в ключ, должен находиться в зависимости от всего
ключевого столбца, а не от его части (первичный ключ - несколько столбцов).
Три типа ключевых полей:
ключевые поля счетчика
простой ключ
составной ключ
Пример «Отпуск товара по накладным»
до нормализации после нормализации
накладные клиенты
Слайд 37
Применение правил нормализации
Третья нормальная форма (3НФ)
Столбцы, не являющиеся
ключевыми, должны быть независимыми друг от друга. Каждый столбец,
не являющийся ключевым, должен зависеть только от первичного ключа.
Пример ненормализованной таблицы, где скидка зависит от цены.
Код продукта (первичный ключ)
Имя
Рекомендуемая розничная цена
Скидка
Изменение любого неключевого столбца не должно влиять на другие столбцы.
:
Слайд 38
Задание для самостоятельной работы
(БД Договоры)
:
Слайд 39
Задание для самостоятельной работы
(БД Договоры)
:
Слайд 40
Задание для самостоятельной работы
(БД Договоры)
:
Слайд 41
Структура БД
(оболочка, которая хранит и организует информацию внутри
БД)
Включает в себя следующие элементы:
количество таблиц и их имена
количество
полей в таблицах и их имена
типы полей
длины полей
ключевые поля
наличие полей для связи между таблицами
Ограничения на имена таблиц в Access:
не более 64 символов
нельзя - (.), (!), (‘), ([])
не должно начинаться с пробела
Слайд 42
Пример проектирования БД «Успеваемость»
Исходные данные
списки групп студентов
списки преподавателей
кафедр
перечень дисциплин
учебные программы
распределение нагрузки между преподавателями
экзаменационные ведомости
Сущность – объект,
информацию о котором необходимо хранить в базе данных.
Атрибут — это свойство, описывающее определенный аспект объекта, значение которого следует зафиксировать в описании предметной области.
Экземпляр сущности – запись таблицы.
Значение атрибута – поле.
Одна клеточка в таблице – значение атрибута для конкретного экземпляра сущности.
Что же будет сущность для БД «Успеваемость?»
Слайд 43
Пример проектирования БД «Успеваемость»
Таблица «Оценки»
Слайд 44
Пример проектирования БД «Успеваемость»
Таблица «Оценки»
Слайд 45
Пример проектирования БД «Успеваемость»
Определение первичного ключа отношения «Оценки»
Первичный
ключ – поле (набор полей), представляет уникальный идентификатор для
каждой записи.
ключ должен однозначно определять каждую строку;
в нем не должно быть пустых или отсутствующих значений — он всегда содержит значение;
ключ крайне редко изменяется (в идеале — никогда).
Для таблицы ОЦЕНКИ, в первичном ключе можно использовать несколько столбцов: студент, дисциплина, форма контроля, семестр, дата.
Первичный ключ из нескольких столбцов называется составным.
Слайд 46
Пример проектирования БД «Успеваемость»
Минимизации избыточности
Исключим из таблицы «Оценки»
лишние атрибуты.
Данные о студенте нужно вынести в отдельную таблицу
СТУДЕНТЫ. То же и с дисциплинами, формами контроля, преподавателями, группами и специальностями.
Слайд 47
Пример проектирования БД «Успеваемость»
Определение первичного ключа
Слайд 48
Пример проектирования БД «Успеваемость»
Минимизация избыточности
Атрибут СПЕЦИАЛЬНОСТЬ исключим с
целью минимизации избыточности.
Данные о факультете и специальности можно
получить по связи с номером группы.
В нашем случае атрибут ГРУППЫ отношения СТУДЕНТЫ – внешний ключ.
Слайд 49
Пример проектирования БД «Успеваемость»
Ссылочная целостность данных
Каждому внешнему ключу
должна соответствовать строка какого-либо объектного отношения.
Отношение СТУДЕНТ не может
принять вид:
Внешний ключ ссылается на экземпляр объекта, о котором ничего не известно.
Каждому внешнему ключу должна соответствовать строка какого — либо объектного отношения. Следует добавить строку в отношение ГРУППЫ с кодом группы 2237.
Слайд 50
Пример проектирования БД «Успеваемость»
Минимизация избыточности
Из таблицы ОЦЕНКИ исключим
наименования дисциплин, форм контроля, фамилии преподавателей. Оставим коды и
создадим справочники.
В итоге таблица ОЦЕНКИ примет следующий вид:
Слайд 51
Пример проектирования БД «Успеваемость»
Типы данных
Свойства поля определяются типом
данных, которые будут в нем храниться.
В каждой системе БД
имеется свой набор типов.
К простым типам данных относятся следующие типы:
логический
строковый
численный
Различные языки программирования могут расширять и уточнять этот список, добавляя такие типы как:
целый
вещественный
дата
время
денежный
перечислимый
интервальный и т.д.
Слайд 52
Пример проектирования БД «Успеваемость»
Типы данных
При выборе типа данных,
используемых в поле, необходимо учитывать следующее:
Какие значения должны отображаться
в поле?
Сколько места необходимо для хранения значений в поле.
Какие операции должны производиться со значениями в поле. Суммировать значения можно в числовых полях и в полях, а значения в текстовых полях нельзя.
Нужна ли сортировка или индексирование поля. Сортировать и индексировать поля MЕМО и гиперссылки невозможно.
Необходимо ли использование полей в группировке записей в запросах или отчетах? Поля MЕМО и гиперссылки использовать для группировки записей нельзя.
Каким образом должны быть отсортированы значения в поле?
Для сортировки чисел как числовых значений используются числовые поля. Многие форматы дат невозможно отсортировать надлежащим образом, если они были введены в текстовое поле.
В Microsoft Access определены девять типов полей: «Текстовый», «Числовой», «Денежный», «Дата/время», «Логический», «Счетчик», «Поле MEMO», «Гиперссылка», «Поле объекта OLE».
Слайд 55
Таблица «Группы»
Таблица «Специальности»
Слайд 56
Таблица «Дисциплины»
Таблица «Формы контроля»
Слайд 57
Таблица «Виды оценок»
Таблица «Преподаватели»
Слайд 58
Определение связей между информационными объектами
Слайд 61
Таблица «Группы»
Таблица «Специальности»
Слайд 62
Таблица «Уровень»
Таблица «Формы обучения»
Таблица «Образовательная программа»
Слайд 63
Таблица «Города»
Таблица «Регионы»
Слайд 64
Таблица «Дисциплины»
Таблица «Формы контроля»
Слайд 65
Таблица «Виды оценок»
Таблица «Преподаватели»