Множественные базы данных

Август 8, 2022

Главная
Информатика
Множественные базы данных

Содержание

2. Контрольные вопросы Что такое выборка? Как реализуется сортировка выборки? Как реализуется построчный фильтр? Шаблоны LIKE Синтаксис
3. Рост сложности реализации Основной проблемой при разработке БД является проблема роста сложности реализации проекта с течением
4. Структура таблицы Products
5. Избыточность Обратите внимание на поля category, producer, country, supplier. В данной таблице значения в этих полях
6. Потенциально неверный ввод К тому же, неопытные пользователи при вводе информации для поля, допустим, category, могут
7. Решение этих двух проблем Разумнее было бы создать для категорий отдельную таблицу, где каждое название категории
8. Аномалия добавления Также при работе с однотабличными БД часто возникают проблемы добавления информации, описывающей какие-то отдельные
9. Аномалия удаления Также существует аномалия, связанная с удалением данных. Допустим, будет необходимо удалить всю информацию о
10. Подробнее про аномалии http://citforum.ck.ua/database/dblearn/dblearn06.shtml В книге Кристофера Дейта
11. Отдельная таблица Итак, мы остановились на необходимости вынести названия категорий в отдельную таблицу:
12. Внешний ключ В таблице Products вместо текстового названия категории можно использовать числовой идентификатор этой категории из
13. Что получится
14. Вопрос Ну и как же пользователь будет работать с какими-то цифрами вместо понятных названий? В действительности,
15. Виды связей между таблицами Из рассмотренного примера очевидно, что у нас не просто появилась ещё одна
16. Один к одному Обозначение связи: 1:1. Таблицы связаны по схеме «один-к-одному», если каждой записи из первой
17. Один ко многим Обозначение связи: 1:M. Между таблицами имеет место связь «один-ко-многим», если каждой записи из
18. Многие ко многим Обозначение связи: N:M. Между таблицами имеет место связь «многие-ко-многим», если каждой записи из
19. Таблица-тэг Физически не существует способа реализовать связь «многие-ко-многим» непосредственно между двумя таблицами. Вместо этого такая связь
20. Связь «Родитель-Потомок» Вообще, существует ещё одно обозначение связи между двумя таблицами: «родитель-потомок». Если первая таблица содержит
22. Ограничения внешнего ключа Допустим, из таблицы «Категории» потребовалось удалить некоторую категорию. Однако в дочерней таблице «Продукты»
23. 1. Restrict (No action) Запрещено удалять записи из родительской таблицы, если в дочерней таблицы есть ссылки
24. 2. Cascade Из дочерней таблицы автоматически удаляются все записи, ссылающиеся на удаляемую запись из родительской таблицы.
25. 3. Set Null Предполагает, что будет происходить автоматическая замена значений (на NULL) внешнего ключа дочерней таблицы,
26. 4. Set Default Автоматически заменяет во внешнем ключе записей дочерней таблицы, ссылающихся на удаляемую запись из
27. Изменение первичного ключа Аналогичное поведение можно получить при изменении первичного ключа записи из родительской таблицы, на
28. Целостность данных Таким образом реализуется сохранение целостности данных в БД. Все современные СУБД содержат достаточно развитые
29. Определение понятия Целостность базы данных (database integrity) — соответствие имеющейся в базе данных информации её внутренней
30. Целостность и достоверность Задача аналитика и проектировщика базы данных — возможно более полно выявить все имеющиеся
31. Практика Создание схемы данных для базы, которая позволяет не установить связи, а активизировать средства сохранения целостности
32. Домашнее задание
34. Скачать презентацию

Слайд 2

Контрольные вопросы
Что такое выборка?
Как реализуется сортировка выборки?
Как реализуется построчный фильтр?
Шаблоны LIKE
Синтаксис

INSERT
Синтаксис UPDATE
Синтаксис DELETE

Слайд 3

Рост сложности реализации
Основной проблемой при разработке БД является проблема роста сложности

реализации проекта с течением времени. Представить предметную область в том виде, в котором она существует на самом деле в реальном мире, с помощью одной таблицы практически невозможно. http://www.mstu.edu.ru/study/materials/zelenkov/ch_5_1.html

Слайд 4

Структура таблицы Products

Слайд 5

Избыточность
Обратите внимание на поля category, producer, country, supplier. В данной таблице

значения в этих полях часто повторяются (например, для 26 записей только 3 разных названия стран), при этом поля текстовые, что влечёт значительные расходы дискового пространства («Украина» занимает либо 7, либо 14 Байт).

Слайд 6

Потенциально неверный ввод
К тому же, неопытные пользователи при вводе информации для

поля, допустим, category, могут запросто ввести название категории «Малочные», а не «Молочные», и в дальнейшем это может создать проблемы как с сортировкой получаемых из таблицы выборок, так и с поиском информации в этой таблице.

Слайд 7

Решение этих двух проблем
Разумнее было бы создать для категорий отдельную

таблицу, где каждое название категории хранилось бы только один раз. То же самое для поставщиков, стран и производителей. Создание многотабличных БД потребует некоторых дополнительных усилий, и работа с полученной многотабличной БД будет немного отличаться от работы с однотабличной БД.

Слайд 8

Аномалия добавления
Также при работе с однотабличными БД часто возникают проблемы добавления

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

Слайд 9

Аномалия удаления
Также существует аномалия, связанная с удалением данных. Допустим, будет необходимо

удалить всю информацию о некотором производителе, и все товары, которые этот производитель выпустил. Технически это вполне осуществимо, но логически это идет в разрез с идеологией однотабличных БД.

Слайд 10

Подробнее про аномалии
http://citforum.ck.ua/database/dblearn/dblearn06.shtml
В книге Кристофера Дейта

Слайд 11

Отдельная таблица
Итак, мы остановились на необходимости вынести названия категорий в отдельную

таблицу:

Слайд 12

Внешний ключ
В таблице Products вместо текстового названия категории можно использовать числовой

идентификатор этой категории из новой таблицы Categories. Если так сделать, то в таблице Products будет поле, ссылающееся на первичный ключ таблицы Categories. Такое поле называется внешним ключом. Таким полям принято давать «говорящие» названия. Например, добавлять перед именем поля префикс id_. Итак, внешний ключ – это одно или несколько полей подчинённой таблицы, предназначенных для связи с главной таблицей. Там хранятся значения первичного ключа главной таблицы, за счёт этого и обеспечивается связь.

Слайд 13

Что получится

Слайд 14

Вопрос
Ну и как же пользователь будет работать с какими-то цифрами вместо

понятных названий? В действительности, конечный пользователь сайта или приложения никогда не увидит внутреннюю структуру БД. Замена цифр на текстовые значения при их отображении для пользователя – это задача программиста, и её решение будет рассмотрено чуть позже.

Слайд 15

Виды связей между таблицами
Из рассмотренного примера очевидно, что у нас не

просто появилась ещё одна таблица, но и, благодаря внешнему ключу, эти две таблицы связаны друг с другом (как минимум, в нашем воображении ☺). Существует три вида связей между таблицами:
один к одному
один ко многим
многие ко многим

Слайд 16

Один к одному
Обозначение связи: 1:1.
Таблицы связаны по схеме «один-к-одному», если каждой

записи из первой таблицы соответствует 1 или 0 записей во второй таблице.
Например: таблица «Люди» и таблица «Внутренние паспорта». Действительно, по законодательству Украины, у каждого гражданина может быть только один внутренний паспорт (который можно нечаянно потерять ☺). Ещё пример: «Люди» и «Идентификационные коды», «Медведи» и «Ложки».
Эта связь используется реже, чем две остальные.

Слайд 17

Один ко многим
Обозначение связи: 1:M.
Между таблицами имеет место связь «один-ко-многим», если

каждой записи из первой таблицы соответствует любое количество (0, 1 или более) записей во второй таблице.
Это самая часто используемая связь с современных реляционных БД. Например, так можно соединить таблицы «Матери» и «Дети», «Специализации» и «Группы».

Слайд 18

Многие ко многим
Обозначение связи: N:M.
Между таблицами имеет место связь «многие-ко-многим», если

каждой записи из первой таблицы соответствует 0, 1 или более записей во второй таблице и наоборот.
Пример: таблица «Дисциплины» и таблица «Преподаватели». Каждая дисциплина может читаться несколькими преподавателями, но и каждый преподаватель может читать несколько разных дисциплин. Другой пример: «Люди» и «Увлечения».

Слайд 19

Таблица-тэг
Физически не существует способа реализовать связь «многие-ко-многим» непосредственно между двумя таблицами.

Вместо этого такая связь реализуется при помощи дополнительной таблицы, называемой тэгом, и двух связей «один-ко-многим».

Слайд 20

Связь «Родитель-Потомок»
Вообще, существует ещё одно обозначение связи между двумя таблицами: «родитель-потомок».

Если первая таблица содержит внешний ключ, ссылающийся на вторую таблицу, то говорят, что первая таблица является потомком, а вторая – родителем. В примере с таблицами «Продукты» и «Категории», таблица «Категории» – родительская, а таблица «Продукты» – дочерняя.

Слайд 21

Слайд 22

Ограничения внешнего ключа
Допустим, из таблицы «Категории» потребовалось удалить некоторую категорию. Однако

в дочерней таблице «Продукты» есть продукты, относящиеся к этой категории. Если удалить категорию, то внешний ключ этих продуктов будет ссылаться в никуда… Что можно сделать в такой ситуации? Существует четыре варианта развития событий.

Слайд 23

1. Restrict (No action)
Запрещено удалять записи из родительской таблицы, если в

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

Слайд 24

2. Cascade
Из дочерней таблицы автоматически удаляются все записи, ссылающиеся на удаляемую

запись из родительской таблицы.

Слайд 25

3. Set Null
Предполагает, что будет происходить автоматическая замена значений (на NULL)

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

Слайд 26

4. Set Default
Автоматически заменяет во внешнем ключе записей дочерней таблицы, ссылающихся

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

Слайд 27

Изменение первичного ключа
Аналогичное поведение можно получить при изменении первичного ключа записи

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

Слайд 28

Целостность данных
Таким образом реализуется сохранение целостности данных в БД. Все современные

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

Слайд 29

Определение понятия
Целостность базы данных (database integrity) — соответствие имеющейся в базе данных информации её внутренней

логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint). Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 25; возраст родителей не может быть меньше возраста их биологического ребёнка и тд.

https://ru.wikipedia.org/wiki/%D0%A6%D0%B5%D0%BB%D0%BE%D1%81%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

Слайд 30

Целостность и достоверность
Задача аналитика и проектировщика базы данных — возможно более

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

Слайд 31

Практика
Создание схемы данных для базы, которая позволяет не установить связи, а

активизировать средства сохранения целостности данных.
На примере таблиц «Студенты» и «Группы», либо «Продукты» и «Категории».

Слайд 32

Множественные базы данных

Содержание

Контрольные вопросыЧто такое выборка?Как реализуется сортировка выборки?Как реализуется построчный фильтр?Шаблоны LIKEСинтаксис

Рост сложности реализацииОсновной проблемой при разработке БД является проблема роста сложности

Структура таблицы Products

ИзбыточностьОбратите внимание на поля category, producer, country, supplier. В данной таблице

Потенциально неверный вводК тому же, неопытные пользователи при вводе информации для

Решение этих двух проблем Разумнее было бы создать для категорий отдельную

Аномалия добавленияТакже при работе с однотабличными БД часто возникают проблемы добавления

Аномалия удаленияТакже существует аномалия, связанная с удалением данных. Допустим, будет необходимо

Подробнее про аномалииhttp://citforum.ck.ua/database/dblearn/dblearn06.shtmlВ книге Кристофера Дейта

Отдельная таблицаИтак, мы остановились на необходимости вынести названия категорий в отдельную

Внешний ключВ таблице Products вместо текстового названия категории можно использовать числовой

Что получится

ВопросНу и как же пользователь будет работать с какими-то цифрами вместо

Виды связей между таблицамиИз рассмотренного примера очевидно, что у нас не

Один к одномуОбозначение связи: 1:1.Таблицы связаны по схеме «один-к-одному», если каждой

Один ко многимОбозначение связи: 1:M.Между таблицами имеет место связь «один-ко-многим», если

Многие ко многимОбозначение связи: N:M.Между таблицами имеет место связь «многие-ко-многим», если

Таблица-тэгФизически не существует способа реализовать связь «многие-ко-многим» непосредственно между двумя таблицами.

Связь «Родитель-Потомок»Вообще, существует ещё одно обозначение связи между двумя таблицами: «родитель-потомок».

Ограничения внешнего ключаДопустим, из таблицы «Категории» потребовалось удалить некоторую категорию. Однако

1. Restrict (No action)Запрещено удалять записи из родительской таблицы, если в

2. CascadeИз дочерней таблицы автоматически удаляются все записи, ссылающиеся на удаляемую

3. Set NullПредполагает, что будет происходить автоматическая замена значений (на NULL)

4. Set DefaultАвтоматически заменяет во внешнем ключе записей дочерней таблицы, ссылающихся

Изменение первичного ключаАналогичное поведение можно получить при изменении первичного ключа записи

Целостность данныхТаким образом реализуется сохранение целостности данных в БД. Все современные

Определение понятияЦелостность базы данных (database integrity) — соответствие имеющейся в базе данных информации её внутренней

Целостность и достоверностьЗадача аналитика и проектировщика базы данных — возможно более

ПрактикаСоздание схемы данных для базы, которая позволяет не установить связи, а

Домашнее задание

Похожие презентации