Презентация на тему: ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ
Уровни представления информации
Уровни представления информации
Уровни представления информации
Проектирование БД на инфологическом уровне
Структурные и объектно-ориентированные методы проектирования
Структурные и объектно-ориентированные методы проектирования
Модель « сущность - связь » (Entity-Relationship model, ER- модель )
Модель « сущность - связь » (Entity-Relationship model, ER- модель )
Нотация Питера Чена
Нотация Питера Чена
Нотация Питера Чена
Нотация Питера Чена
Нотация Питера Чена
Нотация Питера Чена
Нотация Питера Чена
Нотация Баркера
Нотация Баркера
Пример
Пример
Пример
Пример
Пример
Пример
Пример
Пример
Пример
Нотация Crow's   Foot
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Я зык моделирования UML
Проектирование БД на даталогическом уровне
Проектирование БД на даталогическом уровне
Проектирование БД на даталогическом уровне
Проектирование БД на даталогическом уровне
Проектирование БД на даталогическом уровне
Пример
Пример
Пример
Пример
Пример
Пример
Пример
Пример
Проектирование БД на физическом уровне
1/63
Средняя оценка: 4.1/5 (всего оценок: 7)
Код скопирован в буфер обмена
Скачать (5284 Кб)
1

Первый слайд презентации: ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

Учебная дисциплина «Технологии баз данных в управленческой деятельности». Тема 3.2., 6ч. Попова Е.Э.

Изображение слайда
2

Слайд 2: Уровни представления информации

Инфологический. Датологический. Физический.

Изображение слайда
3

Слайд 3: Уровни представления информации

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

Изображение слайда
4

Слайд 4: Уровни представления информации

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

Изображение слайда
5

Слайд 5: Проектирование БД на инфологическом уровне

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

Изображение слайда
6

Слайд 6: Структурные и объектно-ориентированные методы проектирования

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

Изображение слайда
7

Слайд 7: Структурные и объектно-ориентированные методы проектирования

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

Изображение слайда
8

Слайд 8: Модель « сущность - связь » (Entity-Relationship model, ER- модель )

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

Изображение слайда
9

Слайд 9: Модель « сущность - связь » (Entity-Relationship model, ER- модель )

Нотации : Нотация Питера Чена. Crow's   Foot. Нотация Мартина. Нотация Баркера. IDEF1x. Bachman notation.

Изображение слайда
10

Слайд 10: Нотация Питера Чена

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

Изображение слайда
11

Слайд 11: Нотация Питера Чена

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

Изображение слайда
12

Слайд 12: Нотация Питера Чена

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

Изображение слайда
13

Слайд 13: Нотация Питера Чена

Изображение слайда
14

Слайд 14: Нотация Питера Чена

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

Изображение слайда
15

Слайд 15: Нотация Питера Чена

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

Изображение слайда
16

Слайд 16: Нотация Питера Чена

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

Изображение слайда
17

Слайд 17: Нотация Баркера

Сущность Атрибуты сущности Ключ сущности

Изображение слайда
18

Слайд 18: Нотация Баркера

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

Изображение слайда
19

Слайд 19: Пример

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

Изображение слайда
20

Слайд 20: Пример

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

Изображение слайда
21

Слайд 21: Пример

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

Изображение слайда
22

Слайд 22: Пример

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

Изображение слайда
23

Слайд 23: Пример

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

Изображение слайда
24

Слайд 24: Пример

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

Изображение слайда
25

Слайд 25: Пример

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

Изображение слайда
26

Слайд 26: Пример

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

Изображение слайда
27

Слайд 27: Пример

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

Изображение слайда
28

Слайд 28: Нотация Crow's   Foot

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

Изображение слайда
29

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

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

Изображение слайда
30

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

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

Изображение слайда
31

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

Изображение слайда
32

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

Изображение слайда
33

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

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

Изображение слайда
34

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

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

Изображение слайда
35

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

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

Изображение слайда
36

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

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

Изображение слайда
37

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

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

Изображение слайда
38

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

Изображение слайда
39

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

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

Изображение слайда
40

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

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

Изображение слайда
41

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

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

Изображение слайда
42

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

Графическое отображение связей.

Изображение слайда
43

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

Структура языка:

Изображение слайда
44

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

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

Изображение слайда
45

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

Диаграмма классов

Изображение слайда
46

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

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

Изображение слайда
47

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

Диаграмма вариантов использования

Изображение слайда
48

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

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

Изображение слайда
49

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

Диаграмма деятельности

Изображение слайда
50

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

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

Изображение слайда
51

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

Изображение слайда
52

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

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

Изображение слайда
53

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

Изображение слайда
54

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

Изображение слайда
55

Слайд 55: Пример

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

Изображение слайда
56

Слайд 56: Пример

Изображение слайда
57

Слайд 57: Пример

Изображение слайда
58

Слайд 58: Пример

Изображение слайда
59

Слайд 59: Пример

Изображение слайда
60

Слайд 60: Пример

Изображение слайда
61

Слайд 61: Пример

Изображение слайда
62

Слайд 62: Пример

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

Изображение слайда
63

Последний слайд презентации: ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ: Проектирование БД на физическом уровне

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

Изображение слайда