Содержание
- 2. Общие положения Методология проектирования - структурированный подход, предусматривающий использование специализированных процедур, технических приемов, инструментов, документации и
- 3. Концептуальное проектирование Этап 1 Концептуальное проектирование базы данных (инфологическое) - процедура конструирования информационной модели предприятия, не
- 4. Логическое проектирование Этап 2 Логическое проектирование базы данных - процесс конструирования информационной модели предприятия на основе
- 5. Этап 3 - Физическое проектирование базы данных - процесс создания описания конкретной реализации базы данных, размещаемой
- 6. Физическое проектирование БД (общие положения) Образно говоря, при логическом проектировании разработчик сосредоточивается на том, что надо
- 7. Однако, этап физического проектирования базы данных не является совершенно изолированным от других - как правило, между
- 8. Этапы физического проектирования Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД. Этап 4.1.
- 9. Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД. Теперь необходимо принять решение о
- 10. Создание доменов: CREATE DOМAIN рrорertу_type AS CHAR(1) CHECK(VALUE IN('B', 'С', 'О', 'Е', 'F', 'М', 'S')); CREATE
- 11. Физическое проектирование Механизм создания доменов CREATE TABLE property for rent( рnо PROPERTY_NUMBER NOT NULL, street STREET
- 12. Физическое проектирование Механизм создания триггеров CREATE TRIGGER property before update BEFORE UPDATE ON property_for_rent FOR ЕАСН
- 13. Физическое проектирование Механизм создания индексов Индекс представляет собой механизм доступа, усоряющий выборку данных из таблицы -
- 14. Было (Концептуальная модель): Удаление сложных связей Арендатор Id_Arend Участок Id_Uch Работник Id_Rabot Выдает право на аренду
- 15. Рекурсивными называются такие связи, в которых сущность некоторого типа взаимодействует сама с собой. Если концептуальная модель
- 16. Концептуальное проектирование. Этап 1. Для упрощения данной рекурсивной связи типа 1:М мы заменим ее вновь созданной
- 17. Удаление связей с атрибутами Если в концептуальной модели присутствуют связи, имеющие собственные атрибуты, они должны быть
- 18. Множественными называют атрибуты, которые могут иметь одновременно несколько значений для одного и того же экземпляра сущности.
- 19. Проверка связей типа 1:1 В процесс определения сущностей могли быть созданы две различные сущности, которые на
- 20. Удаление избыточных связей Связь является избыточной, если одна и та же информация может быть получена не
- 21. Например, рассмотрим ситуацию, когда необходимо смоделировать связи между сущностями Маn (Мужчина), Woman (Женщина) и Child (Ребенок),
- 22. Поэтому все существующие взаимоотношения примера не могут быть смоделированы без использования связи типа FatherOf. Суть состоит
- 23. Цель Проверка локальной логической модели данных с использованием технологии нормализации. Процедуры нормализации достаточно подробно были рассмотрены
- 24. Этап «Проверка модели с помощью правил нормализации». Нормализация представляет собой процедуру принятия решений о том, какие
- 25. - Нормализация проекта позволяет организовать размещение данных в соответствии с их функциональными зависимостями. Поэтому данная процедура
- 26. Этап: Нормализация -Нормализация проекта позволяет повысить его устойчивость и избавиться от аномалий обновления (изменения, добавления, корректировки
- 27. Этап Нормализация Другими словами, наша задача состоит в проверке корректности состава каждого из созданных отношений посредством
- 28. Цель - Убедиться в том, что локальная логическая модель данных позволяет выполнить все транзакции, предусмотренные данным
- 29. Используя ЕR-диаграммы, словарь данных и установленные связи между первичными и внешними ключами, указанные в описании отношений,
- 30. Этап Проверка модели в отношении транзакций пользователей Рассмотрим возможный подхода, благодаря которому мы сможем убедиться, что
- 31. Этап Проверка модели в отношении транзакций пользователей а) ввод сведений о новом филиале. Первичным ключом отношения
- 32. Этап Проверка модели в отношении транзакций пользователей Подход к проверке модели данных на соответствие требуемым транзакциям
- 33. Этап Проверка модели в отношении транзакций пользователей. Этот подход позволяет визуально выделить те области модели, которые
- 34. Цель Создание окончательного варианта диаграмм "сущность-связь" (ER-диаграмм), являющихся локальным логическим представлением данных, используемых отдельными пользователями приложения.
- 35. Этап Определение требований поддержки целостности данных Цель Определение ограничений, налагаемых в представлениях пользователей требованием сохранения целостности
- 36. Этап Определение требований поддержки целостности данных Полное и точное отражение представления пользователя мы сможем получить ТОЛЬКО
- 37. Этап Определение требований поддержки целостности данных Обязательные дaнные: Некоторые атрибуты всегда должны содержать одно из допустимых
- 38. Этап Определение требований поддержки целостности данных Ограничения для доменов атрибутов. Каждый атрибут имеет домен, представляющий собой
- 39. Этап Определение требований поддержки целостности данных Целостность сущностей: Первичный ключ любой сущности не может содержать пустого
- 40. Этап Определение требований поддержки целостности данных Ссылочная целостность Внешний ключ связывает каждую строку дочернего отношения с
- 41. Этап Определение требований поддержки целостности данных Например, атрибут Branch_No отношения Staff связывает данные о каждом из
- 42. Этап Определение требований поддержки целостности данных Существует несколько важных моментов, связанных с использованием внешних ключей. Во-первых,
- 43. Этап Определение требований поддержки целостности данных Следующая проблема связана с организацией поддержки ссылочной целостности. Реализация этой
- 44. Этап Определение требований поддержки целостности данных Рассмотрим следующие ситуации: Случай 1. Вставка новой строки в дочернее
- 45. Этап Определение требований поддержки целостности данных Случай 3. Обновление внешнего ключа в строке дочернего отношения (Property).
- 46. Этап Определение требований поддержки целостности данных Случай 5. Удаление строки из родительского отношения (Staff). При удалении
- 47. Этап Определение требований поддержки целостности данных NO ACTION. Удаление строки из родительского отношения запрещается, если в
- 48. Этап Определение требований поддержки целостности данных SET NULL. При удалении строки из родительского отношения во всех
- 49. Этап Определение требований поддержки целостности данных SET DEFAULT. При удалении строки из родительского отношения в атрибут
- 50. Этап Определение требований поддержки целостности данных В нашем случае это будет звучать так: "При удалении работника
- 51. Этап Определение требований поддержки целостности данных Случай 6. Обновление первичного ключа в строке родительского отношения(Statt). Если
- 52. Этап Учет требования данного предприятия В заключение требуется проанализировать ограничения, называемые ограничениями предприятия (или бизнес-правилами). Например,
- 53. Взаимосвязь между логическими моделями данных и диаграммами потоков данных Логическая модель данных отображает структуру сохраняемых данных
- 54. Этап. Создание и проверка глобальной логической модели данных Цель Объединение отдельных локальных логических моделей данных в
- 55. Этап. Создание и проверка глобальной логической модели данных Проверка выполняется с использованием тех же методов, которые
- 56. Этап. Создание и проверка глобальной логической модели данных Хотя каждая отдельная логическая модель данных предполагается корректной,
- 57. Этап. Создание и проверка глобальной логической модели данных Процедуру слияния можно считать самой важной в ходе
- 58. Этап 3.1. Слияние локальных логических моделей данных Цель Объединить отдельные локальные логические модели данных в единую
- 59. Этап 3.1. Слияние локальных логических моделей данных Предлагаемый подход предусматривает выполнение следующих действий: 1. Анализ имен
- 60. Этап 3.1. Слияние локальных логических моделей данных Вероятно, самый простой метод слияния нескольких локальных моделей данных
- 61. Этап 3.1. Слияние локальных логических моделей данных 1. Анализ имен сущностей и их первичных ключей. Может
- 62. Этап 3.1. Слияние локальных логических моделей данных Слияние общих сущностей из отдельных локальных моделей: Следует проанализировать
- 63. Этап 3.1. Слияние локальных логических моделей данных Слияние сущностей с одинаковыми именами и первичными ключами. Как
- 64. Слияние сущностей с одинаковыми именами и первичными ключами. Представление View1 Staff (Staff No, Name, Position, Sex,
- 65. Слияние сущностей с одинаковыми именами, но с различными первичными ключами. В некоторых ситуациях могут быть обнаружены
- 66. Представление View1 Staff (Staff_No, Name, Position, Sex, Salary, Branch_No) Primary Кеу Name Alternate Кеу Staff No
- 67. Слияние сущностей с различными именами, имеющих одинаковые или различные первичные ключи. В некоторых случаях можно обнаружить
- 68. Слияние локальных логических моделей данных 4 Включение (без слияния) сущностей, уникальных для каждого локального представления На
- 69. Включение (без слияния) связей, уникальных для каждого локального представления 6. Включение (без слияния) связей, уникальных для
- 70. Проверка на наличие пропущенных сущностей и связей 7. Проверка на наличие пропущенных сущностей и связей Вероятно,
- 71. Проверка на наличие пропущенных сущностей и связей В то же время, при проведении опросов пользователей конкретного
- 72. Слияние локальных логических моделей данных 8. Проверка корректности внешних ключей На этом этапе может осуществляться слияние
- 74. Скачать презентацию