Этапы проектирования базы данных

1.

ЭТАПЫ
ПРОЕКТИРОВАНИЯ
БАЗЫ ДАННЫХ
Учебная дисциплина «Технологии баз
данных в управленческой деятельности».
Тема 3.2., 6ч.
Попова Е.Э.

2.

Уровни представления информации
1. Инфологический.
2. Датологический.
3. Физический.

3.

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

4.

Уровни представления информации
ИНФОЛОГИЧЕСКИЙ УРОВЕНЬ
•сущности
•атрибуты
•связи
Представление аналитика
ДАТАЛОГИЧЕСКИЙ УРОВЕНЬ
•записи
•элементы данных
•связи между записями
Представление программиста
ФИЗИЧЕСКИЙ УРОВЕНЬ
•группирование данных
•индексы
•методы доступа
Представление администратора

5.

Проектирование БД на инфологическом
уровне
Обследование
предметной
области
Построение
инфологической
модели
Информационная модель предметной области – описание предметной области,
выполненной без ориентации на программное и аппаратное обеспечение.
Инфологическое проектирование – процесс создания инфологической модели.
Цель инфологического проектирования (моделирования): создание точного и полного
отображения реального мира, используемого в будущем в качестве источника
информации для построения базы данных.

6.

Структурные и объектно-ориентированные
методы проектирования
Разработчик
Заказчик
Единый язык общения
Модель
данных
Структурные методы. EntityRelationship model.
Объектно-ориентированные
методы. Unified Modeling
Language.

7.

Структурные и объектно-ориентированные
методы проектирования
ER-модель (модель Сущность-связь) концептуально проще UML.
ER-модель – это семантическая модель данных, которая предназначена для
упрощения процесса проектирования БД.
Язык UML принадлежит объектному миру.

8.

Модель «сущность-связь» (EntityRelationship model, ER-модель)
Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен
Ченом.
Информация для построения ER-модели:
1. Сущности, о которых хранятся данные в организации, например, люди,
места, идеи, события и т.д., (будут представлены в виде блоков);
2. Связи между этими сущностями (будут представлены в виде линий,
соединяющих эти блоки);
3. Свойства этих сущностей (будут представлены в виде имен атрибутов в этих
блоках).

9.

Модель «сущность-связь» (EntityRelationship model, ER-модель)
Нотации:
• Нотация Питера Чена.
• Crow's Foot.
• Нотация Мартина.
• Нотация Баркера.
• IDEF1x.
• Bachman notation.

10.

Нотация Питера Чена
сущность
отношения
связи
атрибут
сильный тип
слабый тип

11.

Нотация Питера Чена
Виды атрибутов:
простые;
составные;
однозначные;
многозначные;
производные.

12.

Нотация Питера Чена
Виды атрибутов:
Простые: Состоят из одного компонента. Например, код книги в библиотеке.
Составные. Адрес проживания может содержать название страны, населенного
пункта, улицы, номера дома.
Однозначные. Атрибут «Номер зачетной книги» для типа сущности «Студент»
является однозначным, так как студент может иметь только один номер зачетной
книги (одно значение).
Многозначные. Атрибут «Номер телефона» для сущности «Студент», так как
студент может иметь несколько номеров телефона (домашний, мобильный и т.д.).
Производные. Текущий курс обучения студента можно вычислить на основе
разности текущего года обучения и года поступления студента в учебное
заведение (без учета отчисления и т.п.).

13.

Нотация Питера Чена

14.

Нотация Питера Чена
Связи:
Отношения между сущностями характеризуются глаголом, который пишется внутри
ромба. Глагол определяет характер взаимодействия между типами сущностей.
Студент изучает дисциплину – выделяется глагол «изучает».
Студент учится в группе – выделяется глагол «учится».

15.

Нотация Питера Чена
Мощность связи:
Значение максимального количества конкретных экземпляров сущностей, которые
могут использоваться для данной связи.

16.

Нотация Питера Чена
Пример связи типа «много ко многим».

17.

Нотация Баркера
Сущность
Атрибуты сущности
Ключ сущности

18.

Нотация Баркера
Связи между сущностями могут выражаться
следующими фразами - "СОТРУДНИК может иметь
несколько ДЕТЕЙ",
Каждая связь имеет два конца и одно или два
наименования. Наименование обычно выражается в
неопределенной глагольной форме: "иметь",
"принадлежать" и т.п. Каждое из наименований
относится к своему концу связи.
Каждая связь может иметь одну из двух модальностей
связи:
Модальность «может».
Модальность «должен».
Связь может иметь разную модальность с разных концов.

19.

Пример
Разработать БД по заказам некоторой оптовой торговой фирмы.
Менеджер должен:
1. Хранить информацию о покупателях.
2. Печатать накладные на отпущенные товары.
3. Следить за наличием товаров на складе.
Покупатель.
Накладная.
Товар.
? Склад .
? Наличие товара.
Связи:
"покупатели могут покупать много товаров«;
"товары могут продаваться многим покупателям".

20.

Пример
Разработать БД по заказам некоторой оптовой торговой фирмы.
Уточнения:
Фирма имеет несколько складов.
Каждый товар может храниться на нескольких складах и быть проданным с любого
склада.
Покупатели покупают товары, получая при этом накладные, в которые внесены
данные о количестве и цене купленного товара.
Каждый покупатель может получить несколько накладных.
Каждая накладная обязана выписываться на одного покупателя.
Каждая накладная обязана содержать несколько товаров (не бывает пустых
накладных).
Каждый товар, в свою очередь, может быть продан нескольким покупателям через
несколько накладных.
Кроме того, каждая накладная должна быть выписана с определенного склада, и с
любого склада может быть выписано много накладных.

21.

Пример
Разработать БД по заказам некоторой оптовой торговой фирмы.
Уточнения:
Фирма имеет несколько складов.
Каждый товар может храниться на нескольких складах и быть проданным с любого
склада.
Покупатели покупают товары, получая при этом накладные, в которые внесены
данные о количестве и цене купленного товара.
Каждый покупатель может получить несколько накладных.
Каждая накладная обязана выписываться на одного покупателя.
Каждая накладная обязана содержать несколько товаров (не бывает пустых
накладных).
Каждый товар, в свою очередь, может быть продан нескольким покупателям через
несколько накладных.
Кроме того, каждая накладная должна быть выписана с определенного склада, и с
любого склада может быть выписано много накладных.

22.

Пример
Разработать БД по заказам некоторой оптовой торговой фирмы.

23.

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

24.

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

25.

Пример
Разработать БД по заказам некоторой оптовой торговой фирмы.
Уточнения:
Каждый товар имеет некоторую текущую цену.
Эта цена, по которой товар продается в данный момент.
Эта цена может меняться со временем.
Цена одного и того же товара в разных накладных, выписанных в разное время,
может быть различной.
Имеется две цены - цена товара в накладной и текущая цена товара.

26.

Пример
Разработать БД по заказам некоторой оптовой торговой фирмы.
Уточнения:
Сущности "Накладная" и "Товар" связаны отношением типа много-ко-многим.
Требуется дополнительная сущность "Список товаров в накладной".
Связь ее с сущностями "Накладная" и "Товар" характеризуется следующими фразами:
"каждая накладная обязана иметь несколько записей из списка товаров в накладной",
"каждая запись из списка товаров в накладной обязана включаться ровно в одну
накладную", "каждый товар может включаться в несколько записей из списка товаров в
накладной", " каждая запись из списка товаров в накладной обязана быть связана ровно с
одним товаром".
Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются
атрибутами сущности "Список товаров в накладной".
Аналогично исправляется связь между сущностями "Склад" и "Товар".
Вводится дополнительная сущность "Товар на складе".
Атрибутом этой сущности будет "Количество товара на складе".
Товар будет числиться на любом складе и количество его на каждом складе будет свое.

27.

Пример
Разработать БД по заказам некоторой оптовой торговой фирмы.

28.

Нотация Crow's Foot
Cущность изображается в виде прямоугольника.
Атрибуты
сущности
записываются
внутри
прямоугольника, изображающего сущность и
выражаются существительным в единственном
числе (возможно, с уточняющими словами).
Связь изображается линией. Множественность связи изображается в виде «вилки» на конце
связи.
Модальность связи изображается графически — необязательность связи помечается
кружком на конце связи.
Именование выражается одним глаголом в изъявительном наклонении настоящего времени:
«Имеет», «Принадлежит»; или глаголом с поясняющими словами: «Включает в себя».
Наименование может быть одно для всей связи или два для каждого из концов связи
(название левого конца связи указывается над линией связи, а правого – под линией).
Каждое из названий располагаются рядом с сущностью, к которой оно относится.

29.

Язык моделирования UML
UML (Unified Modeling Language) – унифицированный язык для моделирования
информационных систем любой сложности.
1994 г. – начало работ по созданию языка.
1997 г – версия 1.0.
2017 г. – версия 2.5.1.
UML разработан и развивается консорциумом OMG (Object Management Group).
Проектирование реляционных БД – только одна и не слишком большая область
применения языка.
Преимущество использования UML: можно выполнить весь проект создания
информационной системы на основе одного общего инструмента.

30.

Язык моделирования UML
Принципы UML:
1. Абстрагирования. Предписывает включать в модель только те аспекты
проектируемой БД, которые имеют непосредственное отношение к выполнению
системой своих функций или своего целевого предназначения. При этом все
второстепенные детали опускаются, чтобы чрезмерно не усложнять процесс
анализа и исследования полученной модели.
2. Многомодельности. Означает, что никакое единственное представление
сложной системы не является достаточным для адекватного выражения всех ее
особенностей.
3. Иерархического построения моделей сложных систем. Необходимо
рассматривать процесс построения модели на разных уровнях абстрагирования
или детализации в рамках фиксированных представлений.

31.

Язык моделирования UML

32.

Язык моделирования UML

33.

Язык моделирования UML
В языке UML имеется четыре вида сущностей:
• структурные,
• поведенческие,
• группирующие,
• аннотационные.

34.

Язык моделирования UML
Структурные – статические части модели, соответствующие концептуальным или
физическим элементам модели. Это имена существительные в моделях.
Класс (Class) – описание совокупности объектов с общими атрибутами, операциями,
отношениями и семантикой. Реализует несколько интерфейсов.
Интерфейс (Interface) – совокупность операций, которые определяют набор услуг,
предоставляемых классом или компонентом. Описывает видимое извне поведение
элементов.
Кооперация (Collaboration) – совокупность операций, которые производят некоторый
общий эффект, не сводящийся к простой сумме слагаемых.
Цепочка
ответственности

35.

Язык моделирования UML
Вариант использования или Прецедент (Use сase) – описание последовательности
выполняемых системой действий, которая производит наблюдаемый результат, значимый
для какого-либо определенного действующего лица (Actor).
Разместить
заказ
Активный класс (Active class) – класс, объекты которого вовлечены в один или несколько
процессов и могут инициировать управляющее воздействие.
Компонент (Component) – физическая заменяемая часть системы, которая соответствует
некоторому набору интерфейсов и обеспечивает его реализацию.
Узел (Node) – элемент реальной (физической) системы, который существует во время
функционирования программного комплекса и представляет собой вычислительный
ресурс.
Сервер

36.

Язык моделирования UML
Поведенческие – динамические составляющие, описывающие поведение модели во
времени и в пространстве. Это глаголы языка.
Взаимодействие (Interaction) – поведение, суть которого заключается в обмене
сообщениями между объектами в рамках конкретного контекста для достижения
определенных целей.
Отобразить
Автомат (State machine) – поведение, определяющее последовательность состояний,
через которые объект или взаимодействие проходят на протяжении своего жизненного
цикла в ответ на различные события, а также реакция на эти события.
Ожидание

37.

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

38.

Язык моделирования UML

39.

Язык моделирования UML
В языке UML определены четыре типа отношений:
Зависимость (Dependency) – это семантическое отношение между двумя сущностями, при
котором изменение одной из них, независимой, может повлиять на семантику другой,
зависимой.
Ассоциация (Association) – отношение, описывающее совокупность связей между
объектами. Разновидностью ассоциации является агрегирование (Aggregation) –
структурное отношение между целым и его частями. Графическое изображение
ассоциации может включать кратность и имена ролей.

40.

Язык моделирования UML
Композиция (composition) – это такая агрегация, где объекты-части не могут
существовать сами по себе и уничтожаются при уничтожении объекта агрегирующего
класса.
Дом
Комната

41.

Язык моделирования UML
Обобщение (Generalization) – это отношение
“специализация/обобщение”, при котором объект
специализированного элемента (потомок) может быть
подставлен вместо объекта обобщенного элемента
(родителя или предка). Таким образом, потомок (Child)
наследует структуру и поведение своего родителя
(Parent). Второе название – наследование.
Реализация (Realization) – это отношение между
классификаторами, при котором один классификатор
определяет “контракт”, а другой гарантирует его
выполнение. Отношения реализации встречаются в
двух случаях: во-первых, между интерфейсами и
реализующими их классами или компонентами, а вовторых, между прецедентами и реализующими их
кооперациями.

42.

Язык моделирования UML
Графическое отображение
связей.

43.

Язык моделирования UML
Структура
языка:

44.

Язык моделирования UML
На диаграмме классов (Class diagram) изображаются классы, интерфейсы, объекты и
кооперации, а также их отношения. На диаграммах классов обычно показываются
зависимости, ассоциации и обобщения.

45.

Язык моделирования UML
Диаграмма классов

46.

Язык моделирования UML
На диаграмме вариантов использования (Use case diagram) представлены прецеденты и
акторы (частный случай классов), а также отношения между ними. Они используются при
моделировании поведения системы.

47.

Язык моделирования UML
Диаграмма вариантов
использования

48.

Язык моделирования UML
Диаграмма деятельности
(Activity diagram) представляют
переходы потока управления
между объектами от одной
деятельности к другой внутри
системы.
Диаграмма может стать опорной
для построения диаграммы
классов.

49.

Язык моделирования UML
Диаграмма
деятельности

50.

Проектирование БД на даталогическом
уровне
Даталогическое проектирование (логическое) – преобразование требований к
данным в структуры данных.
Результат: СУБД-ориентированная структура базы данных и спецификации
прикладных программ.
На этом этапе часто моделируют базы данных применительно к различным СУБД
и проводят сравнительный анализ моделей.

51.

Проектирование БД на даталогическом
уровне

52.

Проектирование БД на даталогическом
уровне
Инфологическая
модель
Ограничения
Даталогическая
модель
То, что хочет получить заказчик!
Технические.
Программные.
Организационные.
Как это будет реализовано!

53.

Проектирование БД на даталогическом
уровне

54.

Проектирование БД на даталогическом
уровне

55.

Пример
Разработать БД «Детский магазин».
При разработке стандартной схемы организации был определен следующий персонал:
директор, администраторы, продавцы-консультанты по продажам, уборщицы,
водители.
Работа продавца-консультанта — это процесс, который разделен на следующие этапы:
• поиск нужного товара;
• формирование списка товаров;
• добавление информации о покупателях.

56.

Пример
Таблица 1. Информационные процессы этапов
Этап
Информационные процессы
1. поиск нужного
товара
поиск товара на складе посредством побуквенного ввода названия
товара, фирмы изготовителя или цене в поле поиска
2. формирование
списка товаров
вывод выбранных товаров в отдельную таблицу
3. оформление
документов клиента
сохранение информации в базу данных
4. оформление
продажи
выбор количества продаваемого товара

57.

Пример
Таблица 2. Перечень сущностей предметной области
Название
Ключ сущности
Атрибуты сущности
Детский магазин
Код_магазина
Название
Адрес
Телефон
Почта
ФамилияИО_владельца
Адреса_магазинов
Город
Страна
Сотрудники
Код_сотрудника
Должность
ФамилияИО_сотрудника
Паспортные данные
Дата_рождения
Пол
Образование
Телефон
Дата_устройства
Город
Почта
Код_магазина
Поставщики
Код_поставщика
Адрес
Телефон
Страна
Почта
Категория_товара
Фирма_товара
Дата_поставки
Количество

58.

Пример
Покупатели
Код_покупателя
ФамилияИО_покупателя
Паспортные_данные
Город
Телефон
Адрес
Почта
Постоянный_клиент
Заказы
Код_заказа
ФамилияИО_заказчика
Название_товара
Количество
Дата заказа
Стоимость_заказа
Код_доставки
Товары
Код_товара
Артикул
Категория
Название
Размер
Материал
В_наличии(шт)
Заказано/ожидается
Изображение
Цена(шт)
Количество
Код_поставщика
Код_типа
Код_магазина

59.

Пример
Таблица 3. Перечень связей между сущностями
№
Связь
1
Поставщики ПОСТАВЛЮТ Товары
2
Товары СОСТОЯТ Типы
3
Товары НАХОДЯТСЯ Магазин
4
Магазин РАБОТАЮТ Сотрудники
5
Сотрудники ОФОРМЛЯЮТ Заказы
6
Заказы ДЕЛАЮТ Клиенты

60.

Пример

61.

Пример
Таблица 4. Структура таблицы «Товары»
Таблица 5. Структура таблицы «Сотрудники»
Ключевое поле
Название поля
Тип поля
Ключевое поле
Название поля
Тип поля
Ключ
Код_товара
Счетчик
Ключ
Код_сотрудника
Счетчик
Артикул
Текстовый
Должность
Текстовый
Категория
Текстовый
ФИО сотрудника
Текстовый
Название
Текстовый
Паспортные данные
Числовой
Размер
Числовой
Материал
Текстовый
Дата рождения
Дата/время
В наличии(шт)
Текстовый
Пол
Текстовый
Заказано/Ожидается
Текстовый
Образование
Текстовый
Изображение
Поле объекта OLE
Телефон
Числовой
Цена(шт)
Денежный
Фотография
Поле объекта OLE
Количество
Числовой
Дата устройства
Дата/время
Код поставщика
Числовой
Город
Текстовый
Код типа
Числовой
Почта
Текстовый
Код магазина
Числовой
Код магазина
Числовой

62.

Пример
Физическая модель.
СУБД MS Access.

63.

Проектирование БД на физическом
уровне
Физическое проектирование –
определение особенностей хранения
данных, методов доступа и т.д.
Физическая модель базы данных
содержит все детали, необходимые
конкретной СУБД для создания базы.