Нисходящее проектирование БД

1.

Федеральное государственное бюджетное
образовательное учреждение
высшего образования
«Оренбургский государственный университет»
Кафедра прикладной информатики в экономике и
управлении
БАЗЫ ДАННЫХ
1

2.

Тема : Нисходящее
проектирование БД
2 часа
Разработчик Панова Н.Ф.
2

3.

1.
2.
3.
4.
5.
6.
Этапы нисходящего подхода к
проектированию БД
Анализ предметной области
Инфологическое моделирование
Выбор СУБД
Проектирование внутреннего уровня БД
Разработка инфологической модели
предметной области
3

4.

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

5.

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

6.

Этапы проектирования БД
анализ ПО
инфологическое
моделирование
выбор СУБД
даталогическое
проектирование
(логическое
проектирование)
Проектирование
внутреннего уровня БД

7.

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

8.

1. Функциональный подход – применяется,
когда заранее известны комплексы задач, для
обслуживания которых создается БД, т.е. четко
выделяется минимальный необходимый набор
классов объектов предметной области.
2. Предметный
подход
–
когда
информационные потребности заказчиков БД
четко не фиксируются и могут быть
динамичными. В данном случае минимальный
набор классов объектов предметной области
выделить сложно.

9.

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

10.

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

11.

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

12.

изучение документов;
анкетирование;
наблюдение;
интервьюирование;

13.

Анкетирование – письменный опрос сотрудников
предприятия с использованием опросных листов
(анкет), которые им предлагается заполнить.

14.

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

15.

Интервью
это метод сбора первичной
информации путем выяснения субъективных
мнений, предпочтений, установок людей в
отношении
какого-либо
объекта
при
непосредственном общении с ними.
-

16.

На этом этапе создается инфологическая модель
предметной области. Эта модель отражает
семантику предметной области и формулируется в
терминах, понятных каждому пользователю, а не
только специалисту в области БД.
Широкое распространение получила модель
Питера
Чена
«Сущность-связь»
(Entity
Relationship), она стала фактическим стандартом в
инфологическом моделировании, и получило
название ER – модель.

17.

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

18.

Окончательный
выбор осуществляется путем
сравнительного анализа различных характеристик
3-4 СУБД.
Множество характеристик принято группировать.
Так технические характеристики включают
потребность
в
оперативной
памяти,
максимальный объем БД, число одновременно
подключенных пользователей, перечень объектов
БД, поддерживаемых СУБД и т.д.

19.

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

20.

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

21.

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

22.

23.

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

24.

Отображается
в
виде
закругленными краями.
прямоугольника
с
Имя
сущности
–
существительное
в
единственном числе, именительном падеже
указывается внутри прямоугольника заглавными
буквами.
Обязательный атрибут обозначается символом
‘*’,
необязательный
символом
‘ ’

25.

Экземпляр сущности – это
представитель данной сущности.
конкретный
Так экземпляром сущности Студент является
определенный студент, например,
Иванов.

26.

СОТРУДНИК
* Фамилия
* Имя
* Отчество
* Пол
Телефон

27.

Каждая связь является двусторонней и обладает
следующими свойствами:
Опциональность. Свойство показывает, должна ли
связь существовать для каждого экземпляра сущности
(обязательная связь)или нет (необязательная связь).
Как правило, связи обязательны со стороны одной
сущности и необязательны со стороны другой
сущности
Имя - описывает правило, связывающее сущности.
Например, “обучается в” или “обучает”.

28.

Мощность - правило указывающее, сколько таких
связей может иметь место. Существуют следующие
типы связей:
cвязь “один - к – одному” (1 : 1);
связь “один – ко – многим” (1 : М);
связь “многие – к –одному” (М : 1);
связь “многие – ко – многим” (М : N).

29.

Тип связи
опциональность
обозначение
1:1
обязательная
──────────
1:1
необязательная
1:М
обязательная
1:М
необязательная
М:N
обязательная
М:N
необязательная
--------------------

30.

Между сущностями А и В существует связь
1 : 1, если в каждый момент времени
каждому экземпляру сущности А
соответствует 0 или 1 экземпляр сущности
В и каждому экземпляру сущности В
соответствует 0 или 1 экземпляр сущности
А.

31.

Между сущностями А и В существует связь
1 : М, если в каждый момент времени
каждому экземпляру сущности А
соответствует
0, 1 или несколько
экземпляров сущности В, но при этом
каждому
экземпляру
сущности
В
соответствует 0 или 1 экземпляр сущности
А.

32.

Между сущностями А и В существует связь
M : N, если сняты все ограничения на
количество
экземпляров
сущностей,
участвующих в связи.

33.

Каждый
Имя
сущности
-субъекта
Опциональ
ность связи
(может,
должен)
Имя связи
Мощность
связи
(один,
несколько)
Имя
сущностиобъекта
Каждая связь читается в двух направлениях

34.

СОТРУДНИК
* Фамилия
* Имя
* Отчество
* Пол
Телефон
имеет
относится
ЗАПИСЬ В
ТРУДОВОЙ
КНИЖКЕ
* Дата
* Отдел
* Должность
Каждый сотрудник может иметь несколько записей в
трудовой книжке.
Каждая запись в трудовой книжке должна относиться
к одному сотруднику

35.

Уникальный идентификатор (UID) сущности –
это атрибут, совокупность атрибутов или
комбинация атрибутов и связей, используемая для
идентификации экземпляра сущности.
Атрибуты, входящие в состав уникального
идентификатора, должны быть обязательными.
UID обозначается символом #.
Если в UID входит связь, на линии связи
ставится символ ‘|’.

36.

СОТРУДНИК
# * Табельный номер
* Фамилия
* Имя
* Отчество
* Пол
Телефон

37.

БАНК
открыт
СЧЕТ
#* номер счета
#* Номер банка
обслуживает
Поскольку номер счета уникален в пределах того
банка, в котором он открыт, то для идентификации
счета необходимо знать и номер банка.
В общем случае в уникальный идентификатор может
входить несколько связей.

38.

39.

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

40.

41.

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

42.

Связь M : N удаляется путем добавления в модель
новой сущности – сущности пересечения. При этом
связь M : N заменяется двумя связями 1 : M
Сущность пересечения может быть пустой.
В предметной области, как правило, имеется
соответствующий
документ
или
сущность
пересечения
моделирует позицию некоторого
документа.

43.

ПОЗИЦИЯ
ПРАЙС-ЛИСТА
представляет
представлен
* цена
ТОВАР
ТОВАР
#* код
* наименование
указывает
ПОСТАВЩИК
указан
#* код
* наименование

44.

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

45.

Например, сущность «ВРАЧ» и сущность
«ПАЦИЕНТ» созданы для отображения разных
ролей человека – один лечит, другой лечится.
В случае если врач становится пациентом, то
информация о нем должна быть также отображена
и в сущности «ПАЦИЕНТ».
Таким образом данные дублируются.

46.

ПОЗИЦИЯ
ДОГОВОРА
#* номер
* количество
* цена
ДОГОВОР
#* номер
* дата
ТОВАР
#* код
* наименование
ПОТРЕБИТЕЛЬ
#* код
* наименование
ПОСТАВЩИК
#* код
* наименование

47.

ДОГОВОР
ПОЗИЦИЯ
ДОГОВОРА
#* номер
* дата
#* номер
* количество
* цена
соответствует
ТОВАР
указывает
Выступ. в роли
поставщика
Выступает в роли
потребителя
ЮРИДИЧЕСКОЕ ЛИЦО
#* код
* наименование
#* код
* наименование

48.

Взаимоисключающая связь – это такая
ситуация, когда сущность имеет связь либо с
сущностью А, либо с сущностью В.
Обе связи могут существовать только в разные
моменты времени.

49.

Взаимоисключаемость связей моделируется с
помощью арка.
Арк изображается в виде дуги, пересекающей
входящие в арк взимоисключающие связи.
Связи,
входящие
в
арк,
помечаются
кружочком.

50.

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

51.

АДРЕС
#* номер
* Дом
квартира
ЮРИДИЧЕСКОЕ
ЛИЦО
#* код
* наименование
ФИЗИЧЕСКОЕ
ЛИЦО
#* код
* имя
НАСЕЛЕННЫЙ ПУНКТ
#* код
* наименование
УЛИЦА
#* код
* наименование

52.

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

53.

ВУЗ
#* номер
* название
ФАКУЛЬТЕТ
#* номер
* название
КАФЕДРА
#* номер
* название

54.

Такая модель имеет некоторый недостаток – при
добавлении ещё одного уровня иерархии,
например, при добавления структурной единицы
«Лаборатория» в подчинение какой—либо кафедре
потребуется добавить ещё одну сущность в модель.
Таким
образом
любое
изменение
в
организационной структуре предприятия потребует
корректировки модели.

55.

ТИП СТРУКТУРНОЙ
ЕДИНИЦЫ
#* Код
* наименование
СТРУКТУРНАЯ
ЕДИНИЦА
#* Код
* наименование
подчиняется
Имеет в
подчинении

56.

Сущности, находящиеся на всех уровнях
иерархии должны иметь одинаковые атрибуты;
Иерархия, смоделированная как рекурсивная
связь, должна быть необязательной в обоих
направлениях;
Обязательная ветвь, направленная вверх или
вниз, создает бесконечную иерархию, не имеющую
применения в реальном мире;