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