Проектирование баз данных

Август 1, 2022

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

Содержание

2. Тема № 2«Проектирование баз данных» Занятие № 2.1 «Технология создания баз данных»
3. Учебные цели Дидактические - обобщить и систематизировать знания о порядке и содержании процесса проектирования баз данных;
5. Литература Основная: 1. Иванов, Александр Юрьевич. Базы данных: учебное пособие: [гриф МЧС] / А.Ю. Иванов; МЧС
6. Нормативно-правовая: Доклад «О долгосрочных перспективах развития системы МЧС России (МЧС России - 2030) Доклад Министра РФ
7. 1. Общая схема проектирования базы данных В проектировании баз данных выделяются следующие этапы: анализ информационных потребностей;
8. Анализ информационных потребностей. На этом этапе разработчик базы данных анализирует информацию, циркулирующую в органе управления, для
9. Инфологическое моделирование. Основной задачей этого этапа является разработка инфологической модели (ИЛМ) предметной области. Исходными данными для
10. Логическое проектирование. Исходными данными являются результаты, полученные на этапе инфологического моделирования. Основным результатом этого этапа является
11. Физическая реализация. На этом этапе в среде выбранной СУБД формируются структуры таблиц, осуществляется их первоначальное заведение,
12. 2. Цели проектирования и методы нормализации отношений а) Цели проектирования отношений Основными целями проектирования реляционных БД
13. Достижение полноты хранения необходимых данных является вполне очевидной целью. Предполагается, что БД должна содержать все данные,
14. Исключение избыточности данных:
15. А) Б)
16. Лучшим решением данной проблемы является исключение избыточности путем декомпозиции исходного отношения, что лежит в основе рассматриваемого
17. Необходимость минимизации числа хранимых в БД отношений обусловливается тем, что разбиение одного отношения на два или
18. Проблемы использования единственного отношения. Самым простым вариантом организации схемы БД является составление единственного отношения, в которое
20. Для малых БД, включающих небольшое число атрибутов, универсальное отношение используется в качестве отправной точки при проектировании
21. Аномалия вставки проявляется следующим образом. Если появляется новый преподаватель, который еще не проводит занятия, то для
23. Аномалия удаления для отношения РАСПИСАНИЕ проявляется в случае даления из БД единственного кортежа, в котором ПРЕП#=255.
24. Во-вторых, если вдруг изменился номер телефона в какой-то преподавательской (например, в ПАУД=119), то это изменение следует
25. Понятие нормальной формы схемы БД. Выше было отмечено, что одной из задач проектирования реляционной БД является
26. На первый вопрос можно дать такой ответ. Для БД, общее число хранимых атрибутов в которой невелико,
27. Определение. Отношение находится в первой нормальной форме (1НФ), если каждый его элемент имеет, и всегда будет
28. Определение. Атрибут А является возможным ключом отношения, если А выступает в роли первичного ключа, т.е. по
29. Тогда в отношении РАСПИСАНИЕ можно выделить F-зависимости: А → B A → C A → D
30. Одним из самых важных результатов, полученных в теории реляционных БД, является утверждение о том, что большинство
31. Кроме упомянутых 1НФ и НФБК в теории реляционных баз данных существуют и другие нормальные формы, наиболее
33. Метод декомпозиции без потерь Является одним из самых простых методов нормализации отношений. Сущность его заключается в
34. Метод «сущность-связь» В случае если количество атрибутов, хранимых в БД, очень велико (считается, что достаточным пороговым
35. Проектирование схемы реляционной БД в данном методе производится в три этапа: 1) формирование ИЛМ в виде
36. Третий этап чаще всего не выполняется, т.к. преобразование ER-диаграммы на втором этапе осуществляется по правилам, позволяющим
37. Определение. Сущностью называется некоторый объект предметной области, имеющий экземпляры, обладающие одинаковым набором свойств, но отличающиеся друг
38. Определение. Атрибут есть свойство сущности или связи. Атрибут (набор атрибутов), по значению(ям) которого(ых) можно однозначно идентифицировать
39. Определение. Степенью связи называется соотношение 1:1 (один-к-одному), 1:М (один-ко-многим), М:1 (многие-к-одному) или M:N (многие-ко-многим), которое указывает
40. На рис.6 между сущностями ПРЕПОДАВАТЕЛЬ и КУРС ER-диаграммы показана степень связи M:N.Определение. Класс принадлежности сущности к
41. На ER-диаграмме обязательный класс принадлежности сущности обозначается точкой, взятой в рамку, а необязательный – точкой без
42. В зависимости от степени связи, классов принадлежностей сущностей, наличия атрибутов связи и арности связи каждая связь
43. Правила преобразования связей ER-диаграммы приведены в табл.1.Дадим краткий комментарий к правилам.Если связь бинарная, у нее нет
44. 1. Если обе сущности имеют обязательные классы принадлежности, то связь преобразуется в одно отношение – расширенное
45. 3. Обеспечение целостности данных Информация в базе данных не должна быть противоречивой. Это достигается выполнением различных
46. 3)сравнение полей, которое проверяет значение одного атрибута по значению другого (например, дата приема сотрудника на работу
47. 4. Характеристика CASE-технологии и ее применение для разработки логической структуры базы данных CASE-технология представляет собой методологию
48. Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г.
49. Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате чего
50. Ввиду разнообразной природы CASE-средств было бы ошибочно делать безоговорочные утверждения относительно реального удовлетворения тех или иных
51. 5. Существенные свойства и показатели качества баз данных Оценка качества структур баз данных является необходимой составляющей
52. 6. Методы расчета показателей качества а) Оценка объема проектируемых баз данных Оценка объема БД является неотъемлемой
53. В файлах-таблицах содержатся непосредственно данные, т.е. кортежи значений атрибутов соответствующего отношения. Файлы-таблицы содержат служебную часть с
54. Как известно, мощностью отношения, или файла-таблицы, называется максимально возможное число кортежей (записей) в нем. Используя это
55. Мощности отношений БД определяются, исходя из анализа инфологической модели БД (заданной, например, в виде ER-диаграммы) и
56. Очевидно, что для сущностей с обязательным классом принадлежности связываемая мощность равна непосредственно мощности сущности, а для
57. б) Оценка оперативности выполнения запросов к базе данных При оценке оперативности выполнения запросов в качестве основного
58. Для оценки числа операций обмена между ВЗУ и ОП (в дальнейшем по тексту – просто обменов)
60. Скачать презентацию

Слайд 2

Тема № 2«Проектирование баз данных»
Занятие № 2.1 «Технология создания баз данных»

Слайд 3

Учебные цели
Дидактические
- обобщить и систематизировать знания о порядке и содержании процесса

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

Слайд 4

Слайд 5

Литература
Основная:
1. Иванов, Александр Юрьевич. Базы данных: учебное пособие: [гриф МЧС] /

А.Ю. Иванов; МЧС России. – СПб.: СПбУ ГПС МЧС России, 2010. – 204 с.
Дополнительная:
1. Кузин, Александр Владимирович. Базы данных: учебное пособие: [гриф УМО] / А.В. Кузин, С.В. Левонисова. – 4-е изд., стер. – М. : Академия, 2010. – 320 с.
2. Мамаев Е.В. SQL Server 2000. – СПб.: БХВ-Петербург, 2004. – 1280 с.
3. Грэй П. Логика, алгебра и базы данных / Пер. с англ.- М.: Машиностроение, 1989. – 368 с.

Слайд 6

Нормативно-правовая:
Доклад «О долгосрочных перспективах развития системы МЧС России (МЧС России -

2030) Доклад Министра РФ по делам гражданской обороны, чрезвычайным ситуациям и ликвидации последствий стихийных бедствий. М.: МЧС России, 2012».
Государственный доклад «О состоянии защиты населения и территорий Российской Федерации от чрезвычайных ситуаций природного и техногенного характера в 2012 году».
Основы единой государственной политики РФ в области ГО на период 2020 года (утверждена Президентом РФ от 03.09.2011, № ПР-2613).
Стратегия инновационного развития РФ на период до 2020 года (утверждена распоряжением Правительства РФ от 08.12.2011 года, №2227-р).
Федеральный закон от 22.07.2008 г. №123 – ФЗ (ред.от 10.07.2012 ) «Технический регламент о требованиях пожарной безопасности».
Закон РФ от 29 декабря 2012 года №273-ФЗ «Об образовании в Российской Федерации» с изменениями и дополнениями на 2013 год.
Организационно-методические указания по подготовке территориальных органов, спасательных воинских формирований, подразделений федеральной противопожарной службы, военизированных горноспасательных частей, образовательных учреждений и организаций МЧС России в области гражданской обороны, предупреждения и ликвидации чрезвычайных ситуаций, обеспечения пожарной безопасности и безопасности людей на водных объектах на 2014-2016 годы.
Федеральный закон № 149 «Об информации, информационных технологиях и о защите информации» от 27 июля 2006 г.

Слайд 7

1. Общая схема проектирования базы данных
В проектировании баз данных выделяются

следующие этапы:
анализ информационных потребностей;
инфологическое моделирование;
логическое проектирование;
физическая реализация.

Слайд 8

Анализ информационных потребностей. На этом этапе разработчик базы данных анализирует информацию,

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

Слайд 9

Инфологическое моделирование. Основной задачей этого этапа является разработка инфологической модели (ИЛМ)

предметной области. Исходными данными для этого являются результаты, полученные на предыдущем этапе, а также знания о специфике предметной области. ИЛМ должна отображать объекты (сущности) предметной области, их учитываемые характеристики – атрибуты, а также взаимные связи между объектами и атрибутами. ИЛМ представляется чаще всего в виде графической диаграммы.
Кроме формирования ИЛМ, на данном этапе дается характеристика всех атрибутов, учитываемых в базе данных. Она предполагает указание принадлежности атрибута (к объекту или к связи), типа данных, к которому относятся значения атрибутов, их длины, области допустимых значений, ограничений целостности, выводимости из значений других атрибутов и ряд других характеристик. Результаты оформляются в табличном виде.

Слайд 10

Логическое проектирование. Исходными данными являются результаты, полученные на этапе инфологического моделирования.

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

Слайд 11

Физическая реализация. На этом этапе в среде выбранной СУБД формируются структуры

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

Слайд 12

2. Цели проектирования и методы нормализации отношений
а) Цели проектирования отношений
Основными

целями проектирования реляционных БД являются:
достижение полноты хранения необходимых данных;
исключение избыточности данных;
сведение числа хранимых в БД отношений к минимуму;
нормализация отношений для упрощения решения проблем, связанных с обновлением данных.

Слайд 13

Достижение полноты хранения необходимых данных является вполне очевидной целью. Предполагается, что

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

Слайд 14

Исключение избыточности данных:

Слайд 15

А)
Б)

Слайд 16

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

что лежит в основе рассматриваемого ниже метода проектирования.

Слайд 17

Необходимость минимизации числа хранимых в БД отношений обусловливается тем, что разбиение

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

Слайд 18

Проблемы использования единственного отношения. Самым простым вариантом организации схемы БД является

составление единственного отношения, в которое вносятся все учитываемые в БД атрибуты. Такое отношение носит название универсального. Примером универсального отношения является отношение РАСПИСАНИЕ (рис.3), в которое входят следующие атрибуты:
условный номер преподавателя – ПРЕП#;
фамилия преподавателя – ФАМ;
номер преподавательской – ПАУД;
номер телефона в преподавательской – ТЕЛ;
место проведения занятия – МЕСТО;
день недели - ДЕНЬ_НЕД;
время проведения занятия – ЧАСЫ;
учебная группа – ГРУППА;
шифр дисциплины – ШИФР.

Слайд 19

Слайд 20

Для малых БД, включающих небольшое число атрибутов, универсальное отношение используется в

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

Слайд 21

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

не проводит занятия, то для него необходимо включить в БД кортеж с нулевыми (пустыми) значениями для атрибутов МЕСТО, ДЕНЬ_НЕД, ЧАСЫ, ГРУППА и ШИФР. Пример такого включения представлен на рис.4. Пустые значения в полях МЕСТО и ГРУППА интерпретируются СУБД как 0 (ноль).Если теперь требуется получить ответ на запрос: «Выдать список преподавателей, которые проводят занятия в группах, номера которых меньше 130», то в этот список попадет и преподаватель Семенов, хотя он вообще не проводит ни одного занятия.

Слайд 22

Слайд 23

Аномалия удаления для отношения РАСПИСАНИЕ проявляется в случае даления из БД

единственного кортежа, в котором ПРЕП#=255. Он соответствует преподавателю Смирнову. Предположим, что для Смирнова перенесены его занятия на следующую неделю. Поскольку это единственный кортеж с информацией о Смирнове, то его удаление приведет к потере информации о номере преподавательской аудитории и номере телефона. Если затем запросить список всех преподавателей на кафедре, то Смирнов в него не попадет.Аномалия обновления для отношения РАСПИСАНИЕ проявляется в нескольких случаях. Во-первых, если какой-либо преподаватель (например, Иванов) изменил свою преподавательскую, то в БД нужно проследить это изменение во всех кортежах, описывающих Иванова. Вместе с тем за каждой преподавательской закреплен свой номер телефона. Поэтому следует изменить еще и номер телефона у Иванова.

Слайд 24

Во-вторых, если вдруг изменился номер телефона в какой-то преподавательской (например, в

ПАУД=119), то это изменение следует проследить не только для Иванова, находящегося в ней, но и для других преподавателей этой аудитории, например, Смирнова).Если не произвести эти обновления в полном объеме, то в результате получается противоречивая БД.

Слайд 25

Понятие нормальной формы схемы БД. Выше было отмечено, что одной из

задач проектирования реляционной БД является разбиение отношений с нежелательными аномалиями. Вопросы, которые необходимо решить при этом (т.е. в ходе нормализации), сводятся к следующим:
1) как получить исходные отношения (до начала разбиения)?
2) как распознать «плохие» отношения?
3) как выполнить разбиение?
4) что является признаком завершения разбиения?

Слайд 26

На первый вопрос можно дать такой ответ. Для БД, общее число

хранимых атрибутов в которой невелико, исходным отношением служит универсальное. При большем числе атрибутов для получения исходных отношений следует воспользоваться существующими методами (например, рассматриваемым ниже методом «сущность-связь»).Если определено исходное отношение, то оно должно иметь форму, в которой все поля заполнены атомарными значениями.

Слайд 27

Определение. Отношение находится в первой нормальной форме (1НФ), если каждый его

элемент имеет, и всегда будет иметь атомарное значение.
Определение. Если даны два атрибута А и В и каждому значению А в отношении соответствует ровно одно значение В, то говорят, что В функционально зависит от А (В F-зависит от А, или А → B).В определении F-зависимости для атрибутов БД просматривается аналогия с определением понятия функция в математическом анализе (здесь А выступает в роли аргумента, а В – в роли функции).Если между тремя атрибутами А, В и С установлены F-зависимости А → В и В → С, то говорят, что между А и С существует транзитивная F-зависимость.

Слайд 28

Определение. Атрибут А является возможным ключом отношения, если А выступает в

роли первичного ключа, т.е. по значению, которое принимает атрибут А, можно однозначным образом выбрать из отношения единичную запись.Определение. Если в отношении существует А → В, причем А является составным атрибутом, но ни для какого подмножества А'= А не выполняется условие А'→ В, то говорят, что А является детерминантом (или определителем) В.Рассмотрим введенные определения на примере отношения РАСПИСАНИЕ (см. рис.3). Условно обозначим имена атрибутов буквами А, В, C, D, E, F, G, H и I в таком порядке, как они представлены в отношении (т.е. ПРЕП# обозначим А, ФАМ – В и т.д.).

Слайд 29