- Главная
- Разное
- Бизнес и предпринимательство
- Образование
- Развлечения
- Государство
- Спорт
- Графика
- Культурология
- Еда и кулинария
- Лингвистика
- Религиоведение
- Черчение
- Физкультура
- ИЗО
- Психология
- Социология
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Геометрия
- Детские презентации
- Информатика
- История
- Литература
- Маркетинг
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Что такое findslide.org?
FindSlide.org - это сайт презентаций, докладов, шаблонов в формате PowerPoint.
Обратная связь
Email: Нажмите что бы посмотреть
Презентация на тему Методика сущность-связь. Построение структур данных. (Лекция 8)
Содержание
- 2. Функциональное моделированиеПример IDEF0 -диаграммы, моделирующей деятельность компании, занимающейся распределением товаров по заказам
- 3. Диаграммы потоков данныхМодель DFD имеет два уровня
- 4. Диаграммы потоков данныхОсновные компоненты диаграмм потоков данных:внешние сущности; системы/подсистемы; процессы; накопители данных; потоки данных.
- 5. Диаграммы потоков данныхВнешняя сущностьВнешняя сущность представляет собой
- 6. Диаграммы потоков данныхВнешняя сущностьОпределение некоторого объекта или
- 7. Диаграммы потоков данныхСистемы и подсистемыНомер подсистемы служит
- 8. Диаграммы потоков данныхПроцессыПроцесс характеризует конкретное преобразование входных
- 9. Диаграммы потоков данныхПроцессы Номер процесса служит для
- 10. Диаграммы потоков данныхНакопители данных Накопитель данных представляет
- 11. Диаграммы потоков данныхНакопители данныхНакопитель данных идентифицируется буквой
- 12. Диаграммы потоков данныхПоток данныхПоток данных определяет информацию,
- 13. Построение иерархии диаграмм потоков данныхПервый уровень представления
- 14. Построение иерархии диаграмм потоков данныхПервый уровень представления
- 15. Построение иерархии диаграмм потоков данныхПервый уровень представления
- 16. Построение иерархии диаграмм потоков данныхПервый уровень представления
- 17. Построение иерархии диаграмм потоков данных Второй уровень
- 18. Построение иерархии диаграмм потоков данных Второй уровень
- 19. Построение иерархии диаграмм потоков данных Второй уровень
- 20. Построение иерархии диаграмм потоков данных Второй уровень
- 21. Построение иерархии диаграмм потоков данных Второй уровень
- 22. Правила построения диаграмм потоков данных 1. Размещать
- 23. Правила построения диаграмм потоков данных Соблюдать следующие
- 24. Правила построения диаграмм потоков данных Соблюдать следующие
- 25. Построение иерархии диаграмм потоков данныхПримеры диаграмм
- 26. Построение иерархии диаграмм потоков данныхПримеры диаграмм
- 27. Построение иерархии диаграмм потоков данныхПримеры диаграмм
- 28. Пример IDEF0 -диаграммы, моделирующей деятельность складаКонтекстная диаграмма
- 29. Пример IDEF0 -диаграммы, моделирующей деятельность складаДетализация
- 30. Далее моделировать систему будем, используя диаграммы потоков
- 31. Далее моделировать систему будем, используя диаграммы потоков
- 32. Далее моделировать систему будем, используя диаграммы потоков данных (DFD). Декомпозируем функциональный блок «Отгрузка» Диаграмма DFD «Отгрузка»
- 33. Методика "сущность-связь" построения структур баз данных Термины,
- 34. Методика "сущность-связь" построения структур баз данных Термины,
- 35. Методика "сущность-связь" построения структур баз данныхПример применения
- 36. Методика "сущность-связь" построения структур баз данныхПример применения
- 37. Методика "сущность-связь" построения структур баз данныхПример применения
- 38. Методика "сущность-связь" построения структур баз данныхПример применения
- 39. Методика "сущность-связь" построения структур баз данныхПример применения
- 40. Методика "сущность-связь" построения структур баз данныхПример применения
- 41. Методика "сущность-связь" построения структур баз данныхПример применения
- 42. Методика "сущность-связь" построения структур баз данныхПример применения
- 43. Методика "сущность-связь" построения структур баз данныхПример применения
- 44. Методика "сущность-связь" построения структур баз данныхПример применения
- 45. Методика "сущность-связь" построения структур баз данныхПример применения
- 46. Методика "сущность-связь" построения структур баз данныхПример применения
- 47. Методика "сущность-связь" построения структур баз данныхПример применения
- 48. Методика "сущность-связь" построения структур баз данныхПример применения
- 49. Методика "сущность-связь" построения структур баз данныхПример применения методики - Система подсчета зарплаты.Итоговая диаграмма
- 50. Методика "сущность-связь" построения структур баз данныхПравила построения
- 51. Методика "сущность-связь" построения структур баз данныхПравила построения
- 52. Методика "сущность-связь" построения структур баз данныхПравила построения
- 53. Методика "сущность-связь" построения структур баз данныхПравила построения
- 54. Методика "сущность-связь" построения структур баз данныхПравила построения
- 55. Методика "сущность-связь" построения структур баз данныхПравила построения
- 56. Методика "сущность-связь" построения структур баз данныхПравила построения
- 57. Скачать презентацию
- 58. Похожие презентации
Функциональное моделированиеПример IDEF0 -диаграммы, моделирующей деятельность компании, занимающейся распределением товаров по заказам
Слайд 2
Функциональное моделирование
Пример IDEF0 -диаграммы, моделирующей деятельность компании, занимающейся
распределением товаров по заказам
Слайд 3
Диаграммы потоков данных
Модель DFD имеет два уровня представления:
Первый
уровень представления составляют диаграммы верхних уровней иерархии (контекстные диаграммы),
которые определяют основные процессы или подсистемы ИС с внешними входами и выходами.Второй уровень представления составляют собственно диаграммы потоков данных и процессов их обработки. Они детализируют контекстные диаграммы. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно. На этом уровне декомпозиции выполняются мини спецификации.
Слайд 4
Диаграммы потоков данных
Основные компоненты диаграмм потоков данных:
внешние сущности;
системы/подсистемы;
процессы;
накопители данных;
потоки данных.
Слайд 5
Диаграммы потоков данных
Внешняя сущность
Внешняя сущность представляет собой материальный
предмет или физическое лицо, представляющее собой источник или приемник
информации, например, оператор, внешняя система и др.
Слайд 6
Диаграммы потоков данных
Внешняя сущность
Определение некоторого объекта или системы
в качестве внешней сущности указывает на то, что она
находится за пределами границ анализируемой ИС.В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Слайд 7
Диаграммы потоков данных
Системы и подсистемы
Номер подсистемы служит для
ее идентификации. В поле имени вводится наименование подсистемы в
виде предложения с подлежащим и соответствующими определениями и дополнениями.
Слайд 8
Диаграммы потоков данных
Процессы
Процесс характеризует конкретное преобразование входных потоков
данных в выходные в соответствии с определенным алгоритмом.
Например,
преобразование входного потока данных о значениях сигналов с датчиков в выходной поток вычисленных физических величин (давление, температура и др.).
Слайд 9
Диаграммы потоков данных
Процессы
Номер процесса служит для его
идентификации.
В поле имени вводится наименование процесса в
виде предложения с активным глаголом в неопределенной форме (вычислить, рассчитать, …), за которым следуют существительные в винительном падеже, например: "Рассчитать давление на объекте";
"Вычислить среднее значение температуры".
Фраза, характеризующая процесс, должна недвусмысленным образом определять конкретную операцию или совокупность операций, которым подвергается входящий поток данных.
Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.
Слайд 10
Диаграммы потоков данных
Накопители данных
Накопитель данных представляет собой
абстрактное устройство для хранения информации, которую можно в любой
момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми
Слайд 11
Диаграммы потоков данных
Накопители данных
Накопитель данных идентифицируется буквой "D"
и произвольным числом.
Имя накопителя выбирается из соображения наибольшей
информативности для проектировщика. Накопитель данных в общем случае является прообразом будущей базы данных и описание хранящихся в нем данных должно быть увязано с информационной моделью.
Слайд 12
Диаграммы потоков данных
Поток данных
Поток данных определяет информацию, передаваемую
через некоторое соединение от источника к приемнику.
Реальный поток
данных может быть информацией, передаваемой по линии связи между датчиком и микроконтроллером, по кабелю между двумя вычислительными устройствами и т.д.На диаграмме поток данных изображается в виде линии со стрелкой, которая показывает направление потока.
Каждый поток данных должен иметь имя, отражающее его содержание.
Слайд 13
Построение иерархии диаграмм потоков данных
Первый уровень представления модели
- уровень контекстных диаграмм.
Модель простой ИС может быть представлена
контекстной диаграммой в виде одной системы как единого целого. Модель в этом случае выглядит как контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы имя, отражающее его содержание.
Слайд 14
Построение иерархии диаграмм потоков данных
Первый уровень представления модели
- уровень контекстных диаграмм.
Для сложных ИС строится иерархия контекстных
диаграмм. Для модели сложной ИС контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных.
Признаками сложности ИС могут быть:
наличие большого количества внешних сущностей (десять и более);
распределенная природа системы;
многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.
Слайд 15
Построение иерархии диаграмм потоков данных
Первый уровень представления модели
- уровень контекстных диаграмм.
Начальная диаграмма последовательно декомпозируется на ряд
подсистем нижнего уровня и в итоге может быть представлена в виде иерархии контекстных диаграмм. При этом контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует ИС.
Слайд 16
Построение иерархии диаграмм потоков данных
Первый уровень представления модели
- уровень контекстных диаграмм.
В заключении полученную иерархию контекстных диаграмм
проверяют на полноту исходных данных об объектах системы и изолированность объектов, т.е. отсутствие информационных связей с другими объектами.
Слайд 17
Построение иерархии диаграмм потоков данных
Второй уровень представления
модели – уровень диаграмм потоков данных и процессов их
обработкиКаждая подсистема, которая присутствует на контекстных диаграммах, детализируется при помощи DFD –диаграмм и, как правило, представляется в виде процессов, связанных между собой потоками данных.
Каждый процесс на диаграмме, в свою очередь, может быть детализирован при помощи DFD –диаграмм или, если дальнейшая детализация на подпроцессы невозможна или нецелесообразна, представлен в виде спецификации.
Слайд 18
Построение иерархии диаграмм потоков данных
Второй уровень представления
модели – уровень диаграмм потоков данных и процессов их
обработкиПри детализации должны выполняться следующие правила:
правило балансировки - означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме;
правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.
Слайд 19
Построение иерархии диаграмм потоков данных
Второй уровень представления
модели – уровень диаграмм потоков данных и процессов их
обработки Спецификация является конечной вершиной иерархии DFD.
Решение о завершении детализации процесса и использовании спецификации принимается исходя из следующих критериев:
наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);
возможности описания преобразования данных процессом в виде последовательного алгоритма;
выполнения процессом единственной логической функции преобразования входной информации в выходную;
возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).
Слайд 20
Построение иерархии диаграмм потоков данных
Второй уровень представления
модели – уровень диаграмм потоков данных и процессов их
обработки Важно отметить, что до построения иерархии DFD-диаграмм для детализации процессов необходимо определить содержание всех потоков и накопителей данных, которое описывается при помощи структур данных.
Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации.
Условное вхождение означает, что данный компонент может отсутствовать в структуре.
Альтернатива означает, что в структуру может входить один из перечисленных элементов.
Итерация означает вхождение любого числа элементов в указанном диапазоне.
Слайд 21
Построение иерархии диаграмм потоков данных
Второй уровень представления
модели – уровень диаграмм потоков данных и процессов их
обработки Верификация законченной модели системы (проверка на полноту и согласованность):
В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы.
Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки.
В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации:
все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.
Слайд 22
Правила построения диаграмм потоков данных
1. Размещать на
каждой диаграмме от 3 до 6-7 процессов.
2. Не
загромождать диаграммы несущественными на данном уровне деталями.3. Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов.
4. Выбирать ясные, отражающие суть дела, имена процессов и потоков для улучшения понимаемости диаграмм, при этом стараться не использовать аббревиатуры.
Слайд 23
Правила построения диаграмм потоков данных
Соблюдать следующие этапы:
1)
Идентификация внешних объектов, с которыми система должна быть связана.
2)
Идентификация основных видов информации, циркулирующей между системой и внешними объектами.3) Предварительная разработка контекстной диаграммы.
4) Изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при этом изучении вопросы по всем ее частям.
5) Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков.
6) Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы.
7) Проверка основных требований по DFD первого уровня.
8) Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.
Слайд 24
Правила построения диаграмм потоков данных
Соблюдать следующие этапы:
9)
Проверка основных требований по DFD соответствующего уровня.
10) Добавление определений
новых потоков в словарь данных при каждом их появлении на диаграммах.11) Параллельное (с процессом декомпозиции) изучение требований (в том числе и вновь поступающих), разбиение их на элементарные и идентификация процессов или спецификаций процессов, соответствующих этим требованиям.
12) После построения двух-трех уровней проведение ревизии с целью проверки корректности и улучшения понимаемости модели.
13) Построение спецификации процесса (а не простейшей диаграммы) в случае, если некоторую функцию сложно или невозможно выразить комбинацией процессов.
Слайд 30 Далее моделировать систему будем, используя диаграммы потоков данных
(DFD).
Декомпозируем функциональный блок «Приемка товара на склад»
Диаграмма
DFD «Приемка товара на склад»Слайд 31 Далее моделировать систему будем, используя диаграммы потоков данных
(DFD).
Декомпозируем функциональный блок «Хранение и переучет продукции»
Диаграмма DFD
«Хранение и переучет продукции»Слайд 32 Далее моделировать систему будем, используя диаграммы потоков данных
(DFD).
Декомпозируем функциональный блок «Отгрузка»
Диаграмма DFD «Отгрузка»
Слайд 33
Методика "сущность-связь" построения структур баз данных
Термины, используемые
при проектировании БД
База данных — некоторый упорядоченный
банк информации, предназначенный для хранения необходимых данных.Система управления базой данных (СУБД) — программный комплекс, отвечающий за работу с базой данных, как-то: ее сортировка, извлечение информации по запросу пользователя и некоторые другие действия.
Поле — самая маленькая единица хранения информации, из которой строятся другие более крупные единицы данных — записи. В поле обычно хранится один атрибут для описания некоего объекта, информация о котором хранится в базе данных.
Запись — набор полей, объединенных в единую структуру, на значение которой — хранить информацию об экземпляре интересующего нас объекта. Иногда в литературе запись называют кортежем.
Слайд 34
Методика "сущность-связь" построения структур баз данных
Термины, используемые
при проектировании БД
Таблица — набор записей, в который
входит информация обо всех экземплярах объекта. Обычно каждая таблица сохраняется в виде отдельного файла.
Слайд 35
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Техническое задание:
Создать систему хранения и
вычисления заработной платы с учетом различных премий, надбавок и налогов.В простейшем случае мы можем создать таблицу, состоящую из четырех полей:
"Фамилия",
"Начислено",
"Удержано",
"Сумма",
и такой "плоской" базы данных нам бы вполне могло хватить.
Но есть много недостатков!!!
Слайд 36
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Необходимо преобразование плоской базы данных в
реляционную.Реляционная база данных представляет собой набор таблиц, которые содержат всю необходимую информацию.
Чтобы преобразовать старую базу данных в реляционную БД, мы должны произвести нормализацию, то есть разбиение универсальной таблицы на несколько простых.
Слайд 37
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Для правильной нормализации мы воспользуемся методикой
"сущность-связь".Сущности — это объекты, которыми мы оперируем при помощи СУБД и которые нас интересуют.
Связи - показывают, как эти сущности взаимодействуют между собой.
Для нашей БД одна из связей сущности звучит примерно так: "Работник получает Деньги".
Здесь "Работник" и "Деньги" — сущности,
а "получает" — связь, описывающая их взаимодействие.
Связи зачастую выглядят как глаголы с предлогами, если предлог есть.
Определяя сущности, необходимо выделить их атрибуты, которые будут использованы в базе данных.
Атрибуты — это свойства, которыми сущности обладают.
Так, для сущности "Работник" нас будут интересовать такие атрибуты, как "Фамилия Имя Отчество" ("ФИО"), "Табельный номер" и "Должность".
Слайд 38
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Определим степени связей:
Степень связи —
абстрактная характеристика, показывающая, сколько элементов одной сущности связано со сколькими элементами другой сущности в рамках решения конкретной задачи.Степень связи может принимать значения:
Один к одному – 1 : 1 – один элемент одной сущности связан только с одним элементом другой сущности;
Один к многим – 1 : М – один элемент одной сущности связан со многими элементами другой сущности;
Многие к одному – М : 1 – многие элементы одной сущности связаны с одним элементом другой сущности;
Многие ко многим – М : М – многие элементы одной сущности связаны с многими элементами другой сущности.
Слайд 39
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Класс принадлежности – характеристика, определяющая, обязательно
или нет все элементы сущности должны быть связаны с элементами другой сущности. Классы принадлежностей:
Обязательный – (О);
Необязательный – (N)
Слайд 40
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Диаграмма для конструкции "Работник получает Деньги"
Слайд 41
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Понятие ключа
Ключ, или первичный ключ, как
его часто называют, помогает однозначно выделить именно ту запись в БД, которая нам нужна. Для этого в таблице выбирается одно или несколько полей, по содержимому которого (которых) можно с полной уверенностью установить, ту ли запись мы нашли.
Ключ из нескольких полей называют композитным, то есть составным.
Нахождение ключа для таблицы — дело довольно трудное.
Слайд 42
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Усложним задачу.
Пусть сумма выплаты работнику
будет вычисляться из нескольких сумм, каждая из которых считается за каждую выполненную работу отдельно. Видов работ также может быть несколько. Таким образом, мы имеем четыре сущности:
"Работник" - информация о сотруднике,
"Виды работ" - типовые работы, выполняемые на предприятии, и расценки,
"Выполненные работы" - список закрытых нарядов,
"Баланс" - заработанная сумма, налоги и итоговая сумма для получения.
Слайд 43
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Атрибуты сущностей:
"Работник": Фамилия, Имя, Отчество, Табельный
номер, Должность."Виды работ" : Наименование, Стоимость.
"Выполненные работы": Наименование вида, номер закрытого наряда, объект.
"Баланс": Сумма выплат.
Слайд 44
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Возможные конструкции:
Работник выполняет разные Виды
работ.Выполненные работы состоят из разных Видов работ.
Работник участвовал в Выполнении работ (Выполненные работы).
Работник имеет Баланс выплаты.
Выполненные работы составляют Баланс.
Слайд 45
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Структура диаграммы будет выглядеть следующим образом
Слайд 46
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Анализ конструкции Работник выполняет разные Виды
работ.1. Определение класса принадлежности:
каждый работник должен выполнять какой-то вид работы, следовательно, здесь сущность "Работник" имеет обязательный класс принадлежности - О.
работники предприятия должны выполнять весь спектр видов работ (имеется в виду нормальное предприятие). Следовательно, сущность «Виды работ» имеет также обязательный класс принадлежности - О.
2. Определение степени связи:
каждый работник может выполнять несколько видов работ;
каждый вид работы может быть выполнен несколькими работниками
Следовательно, конструкция имеет степень связи "многие ко многим" (М:М).
Слайд 47
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Анализ конструкции Выполненные работы состоят из
разных Видов работ.1. Определение класса принадлежности:
каждая выполненная работа должна быть определенного вида, следовательно, здесь сущность Выполненные работы имеет обязательный класс принадлежности - О.
некоторые виды работ могут в текущем месяце не выполняться совсем, что дает сущности "Вид работ" в данной конструкции имеет необязательный класс принадлежности - N.
2. Определение степени связи:
многие выполненные работы могут быть одного вида;
каждая выполненная работа может быть только одного вида. Следовательно, конструкция имеет степень связи "многие к одному" (М:1).
Слайд 48
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Анализ конструкции Работник участвовал в Выполнении
работ1. Определение класса принадлежности:
каждый работник должен участвовать в выполнении работ, следовательно, здесь сущность Работник имеет обязательный класс принадлежности - О.
каждая выполненная работа имеет своего исполнителя, то есть сущность Выполненные работы в данной конструкции имеет обязательный класс принадлежности - О.
2. Определение степени связи:
один работник может участвовать в выполнении множества работ;
одна выполненная работа выполняется одним работником. Следовательно, конструкция имеет степень связи "один ко многим" (1:М).
Слайд 49
Методика "сущность-связь" построения структур баз данных
Пример применения методики
- Система подсчета зарплаты.
Итоговая диаграмма
Слайд 50
Методика "сущность-связь" построения структур баз данных
Правила построения таблиц
БД на основе диаграмм «сущность - связь» :
Правило №1
Если
имеется связь степени 1:1 и класс принадлежности обеих сущностей обязательный, то требуется всего одна таблица. Первичным ключом этой таблицы может быть любой из ключей сущностей.
Слайд 51
Методика "сущность-связь" построения структур баз данных
Правила построения таблиц
БД на основе диаграмм «сущность - связь» :
.
Правило
№2Если имеется связь степени 1:1 и класс принадлежности одной сущности является обязательным, а другой — необязательным, то требуются две таблицы.
Для каждой сущности необходимо создать свою таблицу, первичным ключом которой будет ключ этой сущности.
Кроме того, первичный ключ сущности с необязательным классом принадлежности должен быть добавлен в качестве атрибута в таблицу, созданную для сущности с обязательным классом принадлежности.
Слайд 52
Методика "сущность-связь" построения структур баз данных
Правила построения таблиц
БД на основе диаграмм «сущность - связь» :
Правило №3
Если
имеется связь степени 1:1 и класс принадлежности обеих сущностей является необязательным, то требуются три таблицы. Для каждой сущности необходимо создать свою таблицу, первичным ключом которой будет ключ этой сущности.
Кроме того, связующая таблица должна содержать в себе ключи других таблиц в качестве атрибутов.
Слайд 53
Методика "сущность-связь" построения структур баз данных
Правила построения таблиц
БД на основе диаграмм «сущность - связь» :
Правило №4
Если
имеется связь степени 1 :М и класс принадлежности М-связанной сущности является обязательным, то требуются две таблицы. Для каждой сущности необходимо создать свою таблицу, первичным ключом которой будет ключ этой сущности.
Кроме того, первичный ключ 1-связанной сущности должен быть добавлен в качестве атрибута М-связанной таблицы.
Слайд 54
Методика "сущность-связь" построения структур баз данных
Правила построения таблиц
БД на основе диаграмм «сущность - связь» :
Правило №5
Если
имеется связь степени 1:М и класс принадлежности М-связанной сущности является необязательным, то требуются три таблицы. Для каждой сущности необходимо создать свою таблицу, первичным ключом которой будет ключ этой сущности.
Кроме того, связующая таблица должна содержать в себе ключи других таблиц в качестве ее атрибутов.
Слайд 55
Методика "сущность-связь" построения структур баз данных
Правила построения таблиц
БД на основе диаграмм «сущность - связь» :
Правило №6
Если
имеется связь степени М:М, то требуются три таблицы. Для каждой сущности необходимо создать свою таблицу, первичным ключом которой будет ключ этой сущности.
Кроме того, связующая таблица должна содержать в себе ключи других таблиц в качестве ее атрибутов.
Слайд 56
Методика "сущность-связь" построения структур баз данных
Правила построения таблиц
БД на основе диаграмм «сущность - связь» :
Правило №7
При
наличии многосторонней связи необходимо создать свою таблицу для каждой сущности, первичным ключом которой будет ключ этой сущности. Кроме того, необходимо создать еще одну таблицу связи, которая будет содержать первичные ключи остальных таблиц в качестве своих атрибутов.
То есть для п-сторонней связи необходимо создать п+1 таблиц.
