Управление данными. Основы проектирования БД

31,922 views
31,798 views

Published on

Лекции по курсу "Управление данными". Автор Владислав Лавров (vlavrov.com)

Published in: Education
3 Comments
5 Likes
Statistics
Notes
  • ПРограма для проектирования базы данных MySql http://web-benefit.net/item/kak_byistro_sproektirovat_bazu_dannyih_mysql
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • На 63 слайде 'имеющий существеннОЙ значение' должно быть 'существеннОЕ значение'
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • good material. thanks
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
31,922
On SlideShare
0
From Embeds
0
Number of Embeds
1,883
Actions
Shares
0
Downloads
369
Comments
3
Likes
5
Embeds 0
No embeds

No notes for slide

Управление данными. Основы проектирования БД

  1. 1. 1 Управление данными Часть 5. Основы проектирования баз данных (©) Владислав Лавров, vlavrov.com
  2. 2. 2 это процесс разработки структуры (схемы) базы данных (БД) в соответствии с требованиями пользователей Что такое проектирование базы данных ? (©) Владислав Лавров, vlavrov.com
  3. 3. 3 5.1. Основные требования при проектировании базы данных (©) Владислав Лавров, vlavrov.com
  4. 4. 4 Общие требования к базе данных Удовлетворение информационных потребностей различных категорий пользователей за ограниченный промежуток времени, в определенном месте и в определенном виде. (©) Владислав Лавров, vlavrov.com
  5. 5. 5 Обеспечение достоверности данных в базе, исключение дублирования информации. Общие требования к базе данных (©) Владислав Лавров, vlavrov.com
  6. 6. 6 Обеспечение надежности функционирования системы баз данных, а также восстановление данных за приемлемое время в случае ее отказа. Общие требования к базе данных (©) Владислав Лавров, vlavrov.com
  7. 7. 7 Установка защиты базы данных от несанкционированного доступа Общие требования к базе данных (©) Владислав Лавров, vlavrov.com
  8. 8. 8 Возможность проведения гибкой и нетрудоемкой модификации при изменении требований предметной области, программных и технических средств. Общие требования к базе данных (©) Владислав Лавров, vlavrov.com
  9. 9. 9 5.2. Основы классической методологии проектирования базы данных (©) Владислав Лавров, vlavrov.com
  10. 10. 10 Пользователь 1 Концептуальные требования Пользователь 2 Концептуальные требования Пользователь N Концептуальные требования Внутренняя модель Прикладная программа 1Прикладная программа 1 Сервер БД Прикладная программа 2Прикладная программа 2 Прикладная программа NПрикладная программа N Таблица 1 Таблица 2 Таблица 3 Логическая модель Таблица 1 Таблица 2 Таблица 3 Концептуальная модель Внешняя модель Внешняя модель Внешняя модель. . . . . . (©) Владислав Лавров, vlavrov.com
  11. 11. 11 Результаты проектирования базы данных 1. Полная структура базы данных (концептуальная, логическая и внутренняя модели). 2. Руководства для администраторов базы данных и прикладных программистов. (©) Владислав Лавров, vlavrov.com
  12. 12. 12 5.3. Жизненный цикл системы баз данных (©) Владислав Лавров, vlavrov.com
  13. 13. 13 Фаза анализа и проектирования 1. Формулирование и анализ требований 2. Концептуальное проектирование 3. Проектирование реализации 4. Физическое проектирование Фаза реализации и функционирования базы данных 1. Реализация базы данных 2. Анализ функционирования и поддержка 3. Модификация (©) Владислав Лавров, vlavrov.com
  14. 14. 14 5.4. Основные этапы проектирования баз данных (©) Владислав Лавров, vlavrov.com
  15. 15. 15 Общие информационные требования Требования к обработке Характеристики СУБД Спецификации требований Информационная структура Логическая структура базы данных (СУБД-ориентированная) и спецификации прикладных программ Физическая структура базы данных Характеристики операционной системы и аппаратно-технических средств Этап 2. Концептуальное проектирование Этап 3. Проектирование реализации Этап 4. Физическое проектирование Этап 1. Формулировка и анализ требований (©) Владислав Лавров, vlavrov.com
  16. 16. 16 Этап 1. Формулирование и анализ требований Этап 2. Концептуальное проектирование Этап 3. Проектирование реализации Этап 4. Физическое проектирование Фаза анализа и проектирования (©) Владислав Лавров, vlavrov.com
  17. 17. 17 Цель Сбор, анализ и формализация требований, предъявляемых к содержанию и процессу обработки данных всеми известными и потенциальными пользователями базы данных. (©) Владислав Лавров, vlavrov.com
  18. 18. 18 Результат Техническое задание (ТЗ), которое содержит: – назначение, – требования, – ограничения, – возможности, – бизнес-процессы (функции), – объем, – смету затрат, – сроки, – показатели экономической эффективности, – исполнители. (©) Владислав Лавров, vlavrov.com
  19. 19. 19 • Функциональный: реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая БД. Подходы к проектированию: • Предметный: информационные потребности будущих пользователей БД жестко не фиксируются, они могут быть многоаспектными и весьма динамичными. (©) Владислав Лавров, vlavrov.com
  20. 20. 20 Общие требования при проектировании базы данных: • многократное использование данных; • простота, легкость использования; • гибкость при модификации структуры; • обработка незапланированных запросов; • простота корректировки данных; • небольшие затраты на эксплуатацию; • минимальная избыточность; • производительность; • секретность; • достоверность; • защита от искажений и сбоев; • физическая и логическая независимость; • требуемая скорость доступа и поиска; • стандартизация данных; • наличие словаря базы; • контроль за целостностью данных в базе; • восстановление и реорганизация данных в базе. (©) Владислав Лавров, vlavrov.com
  21. 21. 21 • изучение существующих форм документов, отчетов, файлов, баз данных, программного обеспечения; • интервьюирование персонала различных уровней, специалистов организации. Методы сбора требований пользователей: (©) Владислав Лавров, vlavrov.com
  22. 22. 22 • имя и описание объекта данных; • элементы данных; • продолжительность хранения • условия перевода в архив. Содержание исходной информации: (©) Владислав Лавров, vlavrov.com
  23. 23. 23 Пример содержания исходной информации (©) Владислав Лавров, vlavrov.com
  24. 24. 24 Пример функционального моделирования (SADT-модель, начальный уровень модели) (©) Владислав Лавров, vlavrov.com
  25. 25. 25 Пример функционального моделирования (SADT-модели, первый уровень декомпозиции модели) (©) Владислав Лавров, vlavrov.com
  26. 26. 26 Этап 1. Формулирование и анализ требований Этап 2. Концептуальное проектирование Этап 3. Проектирование реализации Этап 4. Физическое проектирование Фаза анализа и проектирования (©) Владислав Лавров, vlavrov.com
  27. 27. 27 Цель Построение независимой от СУБД информационной структуры путем объединения информационных требований пользователей. Результат Концептуальная модель. (©) Владислав Лавров, vlavrov.com
  28. 28. 28 Пример концептуального моделирования (ER-диаграммы) (©) Владислав Лавров, vlavrov.com
  29. 29. 29 1. Моделирование частных представлений пользователей с использованием диаграмм «сущность - связь» (Entity-Relationship Diagrams, ER-диаграмм): •определение сущностей; •определение атрибутов сущностей; •идентификация ключевых атрибутов сущностей; •определение связей между сущностями. 2. Интеграция частных представлений: Концептуальные требования отдельных пользователей, определенные в стандартной форме (диаграммы «сущность-связь»), сливаются в единое глобальное представление. При этом должны быть выявлены и ликвидированы противоречивые и избыточные данные. Метод выполнения : (©) Владислав Лавров, vlavrov.com
  30. 30. 30 Этап 1. Формулирование и анализ требований Этап 2. Концептуальное проектирование Этап 3. Проектирование реализации Этап 4. Физическое проектирование Фаза анализа и проектирования (©) Владислав Лавров, vlavrov.com
  31. 31. 31 Компоненты • проектирование базы данных; • проектирование программ (©) Владислав Лавров, vlavrov.com
  32. 32. 32 Цель создание СУБД-ориентированной схемы (логической модели) с использованием в качестве исходных данных результатов концептуального проектирования и требований обработки конкретной СУБД. (©) Владислав Лавров, vlavrov.com
  33. 33. 33 Результат • даталогическая модель базы данных в терминах конкретной СУБД; • функциональные спецификации программных модулей; • набор возможных запросов к базе данных. (©) Владислав Лавров, vlavrov.com
  34. 34. 34 Пример реализации даталогической модели Фрагмент даталогической модели БД Фрагмент спецификации таблиц БД (©) Владислав Лавров, vlavrov.com
  35. 35. 35 Показатели эффективности функционирования физической БД: • Время ввода-вывода – время, затрачиваемое на выборку данных с внешней памяти в оперативную, включая время передачи данных. • Время доступа – промежуток времени между выдачей команды, содержащей обращение к некоторым данным, и фактическим получением данных для обработки. • Время отклика – промежуток времени между вводом запроса к базе данных в компьютере и завершением обработки запроса с представлением результатов. (©) Владислав Лавров, vlavrov.com
  36. 36. 36 Этап 1. Формулирование и анализ требований Этап 2. Концептуальное проектирование Этап 3. Проектирование реализации Этап 4. Физическое проектирование Фаза анализа и проектирования (©) Владислав Лавров, vlavrov.com
  37. 37. 37 Компоненты • выбор физической структуры базы данных; • уточнение спецификации программных модулей (©) Владислав Лавров, vlavrov.com
  38. 38. 38 Цель создание физической структуры базы данных и набор реализуемых алгоритмов по ее использованию в терминах конкретной СУБД (©) Владислав Лавров, vlavrov.com
  39. 39. 39 Результат полностью готовая к внедрению структура базы данных и набор реализуемых алгоритмов по ее использованию (©) Владислав Лавров, vlavrov.com
  40. 40. 40 Этап 4. Физическое проектирование Категории проектных решений • Проектирование формата хранимых записей. • Анализ и проектирование кластеров. • Проектирование путей доступа. (©) Владислав Лавров, vlavrov.com
  41. 41. 41 5.5. Обеспечение свойств базы данных в процессе проектирования Фундаментальные свойства базы данных 1) целостность, согласованность, восстанавливаемость; 2) безопасность; 3) эффективность, рост, размер, эксплуатационные ограничения. (©) Владислав Лавров, vlavrov.com
  42. 42. 42 Фундаментальные свойства базы данных Целостность База данных обладает свойством целостности, если она удовлетворяет некоторым определённым ограничениям значений данных и сохраняет это свойство при всех модификациях (замена, добавление или удаление) базы данных. Согласованность База данных обладает свойством согласованности по отношению к некоторой совокупности пользователей, если в любой момент времени база данных реагирует на их запросы одинаковым образом (т. е. все пользователи на заданный ими конкретный запрос получают одинаковый ответ). Восстанавливаемость Запроектированная возможность восстановления с помощью СУБД целостности базы данных после любого сбоя системы. (©) Владислав Лавров, vlavrov.com
  43. 43. 43 Фундаментальные свойства базы данных Безопасность Защита данных от преднамеренного или непреднамеренного доступа, модификации или разрушения. Эффективность Степень соизмерения результатов функционирования базы данных с затратами на обеспечение целостности базы данных. Показатель – скорость обработки единицы информации (©) Владислав Лавров, vlavrov.com
  44. 44. 44 5.6. Даталогическое проектирования базы данных Цель разработка схемы базы данных, т.е. совокупности схем отношений (таблиц), которые адекватно моделируют объекты (предметы, явления и др.) предметной области и семантические связи между этими объектами. Результаты • описание концептуальной схемы БД в терминах выбранной СУБД; • описание внешних моделей в терминах выбранной СУБД; • описание правил поддержки целостности базы данных; • разработка процедур поддержки семантической целостности базы данных (©) Владислав Лавров, vlavrov.com
  45. 45. 45 5.6.1. Проектирование реляционных баз данных с использованием принципов нормализации Проблемы : 1. Проблема логического проектирования. Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области и было по возможности лучшим (эффективным, удобным и т.д.)? 2. Проблема физического проектирования. Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создания каких дополнительных структур (например, индексов) потребовать и т.д.? (©) Владислав Лавров, vlavrov.com
  46. 46. 46 Проектирование реляционных баз данных Принимаемые решения: • Из каких отношений должна состоять база данных? • Каким образом должны быть связаны эти отношения? • Какие атрибуты должны быть у этих отношений? (©) Владислав Лавров, vlavrov.com
  47. 47. 47 Проектирование реляционных баз данных Методы проектирования схемы БД: 1. Декомпозиция (разбиение) Исходное множество отношений, входящих в схему БД, заменяется другим множеством отношений, являющихся проекциями исходных отношений. Общее количество отношений возрастает. Таблица 1 Таблица 2 Таблица 3 (©) Владислав Лавров, vlavrov.com
  48. 48. 48 Проектирование реляционных баз данных Методы проектирования схемы БД: 2. Синтез (сборка) Схема базы данных компонуется из заданных исходных элементарных зависимостей между объектами предметной области. Общее количество отношений уменьшается. Таблица 3 Таблица 1 Таблица 2 (©) Владислав Лавров, vlavrov.com
  49. 49. 49 Теория нормализации Цель Сократить избыточность хранимых данных Преимущества • экономия объема используемой памяти; • уменьшение затрат на многократные операции обновления избыточных копий; • устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Нормализация схем отношений Формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на сопровождение (ввод, корректировку) базы данных. (©) Владислав Лавров, vlavrov.com
  50. 50. 50 Теория нормализации Нормальные формы • первая нормальная форма (1NF); • вторая нормальная форма (2NF); • третья нормальная форма (3NF); • усиленная третья нормальная форма, или нормальная форма Бойса- Кодда (BCNF); • четвертая нормальная форма (4NF); • пятая нормальная форма (5NF). Свойства нормальных форм • каждая следующая нормальная форма в некотором смысле лучше предыдущей нормальной формы; • при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются. (©) Владислав Лавров, vlavrov.com
  51. 51. 51 Теория нормализации (основные определения) Функциональная зависимость Функциональной зависимостью набора атрибутов В отношения R от набора атрибутов А того же отношения, обозначаемой как R.A  R.B или А  В, называется такое соотношение проекций R[A] и R[B], при котором в каждый момент времени любому элементу проекции R[A] соответствует только один элемент проекции R[B], входящий вместе с ним в какой-либо кортеж отношения R. (©) Владислав Лавров, vlavrov.com
  52. 52. 52 Теория нормализации (основные определения) Функциональная зависимость СОТРУДНИКИ (Табельный_номер, ФИО, Номер_паспорта, Номер_отдела, Наименование_отдела, Должность) Пример функциональной зависимости: Табельный_номер  ФИО, Номер_отдела, Наименование_отдела, Должность Функциональная взаимозависимость Если одновременно существуют функциональные зависимости вида А  В и B  А, тогда имеет место функциональная взаимозависимость, которая изображается А  В. Пример функциональной взаимозависимости Табельный_номер  Номер_паспорта (©) Владислав Лавров, vlavrov.com
  53. 53. 53 Теория нормализации (основные определения) Полная и неполная (частичная) функциональная зависимость Функциональная зависимость R.A  R.B называется полной, если набор атрибутов В функционально зависит от А и не зависит функционально от любого подмножества А, то есть если: A1  A  R.A1 -/-> R.B. Читается следующим образом: для любого A1, являющегося подмножеством A, R.B функционально не зависит от R.A1, в противном случае зависимость R.A R.B называется неполной (частичной). Примеры: ЗАКАЗЫ (Номер_заказа, Код_товара, КоличествоТовараВЗаказе, Наименование_товара) Полная функциональная зависимость: Номер_заказа, Код_товара  КоличествоТовараВЗаказе Неполная функциональная зависимость: Номер_заказа, Код_товара  Наименование_товара (©) Владислав Лавров, vlavrov.com
  54. 54. 54 Теория нормализации (основные определения) Транзитивная функциональная зависимость Функциональная зависимость R.A  R.B называется транзитивной, если существует набор атрибутов С такой, что: – С не является подмножеством А; – С не включает в себя В; – существует функциональная зависимость R.A  R.C ; – не существует функциональной зависимости вида R.C  R.A, т.е. R.C -/-> R.A ; – существует функциональная зависимость R.C  R.B. Примеры: СОТРУДНИКИ (Номер_сотрудника, Код_отдела, Наименование_отдела, …) Транзитивная функциональная зависимость: Номер_сотрудника  Наименование_отдела Атрибут Наименование_отдела транзитивно, через атритут Код_отдела зависит от атрибута Номер_сотрудника, т.к. существуют зависимости Код_отдела  Наименование_отдела, Номер_сотрудника  Код_отдела (©) Владислав Лавров, vlavrov.com
  55. 55. 55 Теория нормализации (основные определения) Ключевые атрибуты Возможный ключ Набор атрибутов отношения, который полностью и однозначно (функционально полно) определяет значения всех остальных атрибутов отношения. Другими словами, возможный ключ — это набор атрибутов, однозначно определяющий кортеж отношения, в этом случае при удалении любого атрибута из этого набора его свойство однозначной идентификации кортежа теряется. Первичный ключ Один из возможных ключей, выбранный для преимущественного использования в целях однозначной идентификации значений всех остальных атрибутов отношения. Неключевой атрибут Любой атрибут отношения, не входящий в состав ни одного возможного ключа отношения. Взаимно-независимые атрибуты Атрибуты, которые не зависят функционально один от другого. (©) Владислав Лавров, vlavrov.com
  56. 56. 56 Пример: Система обеспечения продажи товаров (требования) Номер заказа (1234, 5678, 9112, ….) Наименование товара (AMD Athlon 64 X2 6000+ BOX < SocketAM2 >, DDRII 2048 Mb (pc2-5300) 667MHz ECC Fully Buffered Qimonda, D-Link DWA-140 Беспроводной адаптер USB, 802,11n, … ) Цена товара в заказе (…) Количество товара в заказе (…) Единицы измерения товара в заказе (шт., м, …) Наименование типа товара (процессоры, модули памяти, сетевое оборудование, … (©) Владислав Лавров, vlavrov.com
  57. 57. 57 Пример: Фрагмент системы обеспечения продажи товаров (исходный вариант) Объект ЗАКАЗЫ (©) Владислав Лавров, vlavrov.com
  58. 58. 58 Первая нормальная форма (1НФ) Определение Отношение находится в 1НФ (First Normal Form, 1NF) тогда и только тогда, когда на пересечении каждого столбца и каждой строки находятся только элементарные значения атрибутов. Другими словами, в отношении не должно быть ячейки, в которой находится несколько значений. В терминах теории баз данных каждое значение в столбце таблицы является элементарным (атомарным), т.е. состоящим из одного экземпляра. Пример Фрагмент организации данных, удовлетворяющий условиям 1НФ (©) Владислав Лавров, vlavrov.com
  59. 59. 59 Аномалии первой нормальной формы Аномалия включения Пока не будет заказа на товар информация о товаре будет отсутствовать в базе данных (наименование товара, код типа товара, наименование типа товара); Аномалия обновления При изменении наименования товара необходим полный просмотр отношения с целью найти все заказы, чтобы изменение наименования товара было отражено во всех заказах. Аномалия удаления Если какой-либо товар удалить из базы данных (снят с продажи), то при этом будет потеряна не только информация о тех заказах, в которых присутствовал этот товар, но и товаре в целом (код товара, его наименование и тип) Аномалия дублирования Некоторые значения атрибутов приходится многократно повторять (наименование товара и наименование типа товара). (©) Владислав Лавров, vlavrov.com
  60. 60. 60 Вторая нормальная форма (2НФ) Определение Отношение находится во 2НФ (Second Normal Form, 2NF) тогда и только тогда, когда оно находится в первой нормальной форме и не содержит неполных функциональных зависимостей непервичных атрибутов от атрибутов первичного ключа. Другими словами, дополнительное ограничение состоит в том, что все неключевые атрибуты целиком зависят от всего ключа, а не от отдельной его части (т.е. отсутствует частичная зависимость). Пример Фрагмент организации данных, удовлетворяющий условиям 2НФ (©) Владислав Лавров, vlavrov.com
  61. 61. 61 Третья нормальная форма (3НФ) Определение Отношение находится в 3НФ (3НФ, Third Normal Form, 3NF) тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей. Другими словами, дополнительное ограничение заключается в том, что все неключевые атрибуты должны быть взаимно функционально независимы, т.е. ни одно из неключевых полей таблицы не должно зависеть функционально от любого другого неключевого поля. Пример Фрагмент организации данных, удовлетворяющий условиям 3НФ (©) Владислав Лавров, vlavrov.com
  62. 62. 62 5.7. Семантическое моделирование данных. Диаграммы «сущность-связь» Цель Обеспечение разработчика информационной системы концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей (внешних моделей), которые относительно легко могут быть отображены в любую систему баз данных. Польза для проектировщиков – обсуждение с заказчиками, специалистами в предметной области; – формализованное описание предметной области, которое легко «читается» неспециалистами по базам данных; – позволяет неспециалистам оценить глубину и корректность проработки проекта БД; – не привязано к конкретной СУБД. Одной из наиболее распространенных семантических моделей данных является модель «сущность–связь» (Entity–Relationship) или ER-модель (впервые была предложена П.Ченом в 1976 г.) Моделирование предметной области базируется на использовании графических диаграмм, или ER-диаграмм (Entity–Relationship Diagrams). (©) Владислав Лавров, vlavrov.com
  63. 63. 63 5.7.1. Основные понятия семантического моделирования данных Сущность (Entity) Реальный или представляемый объект (предмет или явление), имеющий существенное значение для рассматриваемой предметной области и о котором необходимо хранить информацию. Пример Графическое изображение сущностей на ER-диаграмме (©) Владислав Лавров, vlavrov.com
  64. 64. 64 Основные понятия семантического моделирования данных (продолжение) Связь (Relationship) Именованная бинарная ассоциация, функциональная зависимость между двумя сущностями, значимая для рассматриваемой предметной области. В этом случае каждый экземпляр одной сущности ассоциирован с произвольным (в том числе и нулевым) количеством экземпляров второй сущности и наоборот. Пример Изображение степени и обязательности связи Связь между сущностями «Технологические процессы» и «Технологические агрегаты» (©) Владислав Лавров, vlavrov.com
  65. 65. 65 Атрибут (Attribute) Любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная, в общем случае, для классификации, идентификации, количественной характеристики и выражения состояния сущности. Атрибут выражает некоторое отдельное, интересующее пользователя свойство сущности, которое характеризует ее экземпляр. Отдельный атрибут определяется типом (числовой, текстовый, логический, временной и др.), а также значением, которое он принимает. (©) Владислав Лавров, vlavrov.com Основные понятия семантического моделирования данных (продолжение)
  66. 66. 66 Сущность (Entity): • независимая от идентификаторов каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. • зависимая от идентификаторов однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности. 5.7.2. Методология IDEF 1X (Icam DEFinition) Пример независимой от идентификатора сущностей Коксовые батареи Доменные печи Пример зависимой от идентификатора сущностей Выпуски чугуна Химические анализы кокса (©) Владислав Лавров, vlavrov.com
  67. 67. 67 Методология IDEF 1X (Icam DEFinition) (продолжение) Связь (Relationship) Ассоциация между сущностями, при которой каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе и нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, или дочерней сущностью, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Экземпляр сущности-потомка может существовать только при существовании сущности-родителя. Графическое изображение мощности связи в методологии IDEF 1X: а – нуль, один или более; б – один или много (P); в – нуль или один (Z); г – мощность в точности равна некоторому положительному числу (N) (©) Владислав Лавров, vlavrov.com
  68. 68. 68 Виды связи в методологии IDEF1X Идентифицирующая связь Экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем Пример идентифицирующей связи (©) Владислав Лавров, vlavrov.com
  69. 69. 69 Виды связи в методологии IDEF1X Неидентифицирующая связь Экземпляр сущности-потомка не определяется однозначно своей связью с сущностью-родителем Пример неидентифицирующей связи Номер КБ (FK) (©) Владислав Лавров, vlavrov.com
  70. 70. 70 5.8. Информационное моделирование с помощью CASE-средств CASE-технология (Computer Aided System Engineering) Представляет собой методологию проектирования информационных систем, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения информационной системы и разрабатывать приложения в соответствии с информационными потребностями пользователей. Инструментальные CASE-средства Программные средства, поддерживающие процессы создания и сопровождения информационных систем, которые в общем случае включают следующие этапы: – анализ и формулировку требований предметной области; – проектирование баз данных и прикладного программного обеспечения; – генерацию кода для выбранной СУБД и языка приложений; – тестирование; – документирование; – обеспечение требуемого качества работы информационной системы и др. (©) Владислав Лавров, vlavrov.com
  71. 71. 71 5.8.1. Общая характеристика программы AllFusion ERwin Data Modeler (ранее ERwin) Назначение Средство концептуального моделирования базы данных Возможности – Создание визуального представления (концептуальной модели данных) для решаемой задачи в виде ER-диаграмм; – Генерация концептуальной модели в различные сетевые реляционные СУБД и настольные базы данных; – Обратное проектирование (реинжиниринг) баз данных, т.е. преобразование физической модели базы данных в концептуальную модель, не привязанную к конкретной СУБД. Уровни представления моделей – Логический уровень (прямое отображение фактов сущностей из реальной жизни); – Физический уровень (использование конкретной целевой СУБД, определены типы данных, индексы для таблиц и др. (©) Владислав Лавров, vlavrov.com
  72. 72. 72 5.8.2. Этапы построения информационной модели в ERwin 1. Определение сущностей; 2. Определение связей (зависимостей) между сущностями; 3. Задание первичных и составных (альтернативных) ключей; 4. Определение атрибутов сущностей; 5. Приведение модели к требуемому уровню нормальной формы; 6. Переход к физическому описанию модели: назначение соответствий имя сущности – имя таблицы, атрибут сущности – атрибут таблицы; задание ограничений предметной области; 7. Генерация базы данных, т.е. формирование физической схемы для конкретной выбранной (целевой) СУБД. (©) Владислав Лавров, vlavrov.com
  73. 73. 73 Логическое отображение модели в ERwin (©) Владислав Лавров, vlavrov.com
  74. 74. 74 Физическое отображение модели в ERwin (©) Владислав Лавров, vlavrov.com
  75. 75. 75 Настройка свойств связи между сущностями в ERwin (©) Владислав Лавров, vlavrov.com
  76. 76. 76 Построение информационной модели в ERwin Этап 4. Определение атрибутов сущностей Этап 2. Определение связей между сущностями Этап 1. Определение сущностей Этап 3. Задание первичных ключей (©) Владислав Лавров, vlavrov.com
  77. 77. 77 Построение информационной модели в ERwin Этап 5. Приведение модели к требуемому уровню нормальной формы 1. Проанализировать схему на присутствие сущностей, которые скрыто моделируют несколько разных взаимосвязанных классов объектов реального мира (именно это соответствует ненормализованным отношениям). Если такое выявлено, то разделить каждую из этих сущностей на несколько новых сущностей и установить между ними соответствующие связи. Полученная схема будет находиться в первой нормальной форме. 2. Проанализировать все сущности, имеющие составные первичные ключи, на наличие неполных функциональных зависимостей непервичных атрибутов от атрибутов возможного ключа. Если такие зависимости обнаружены, то разделить данные сущности на две, определить для каждой сущности первичные ключи и установить между ними соответствующие связи. Полученная схема будет находиться во второй нормальной форме. 3. Проанализировать неключевые атрибуты всех сущностей на наличие транзитивных функциональных зависимостей. При обнаружении таковых расщепить каждую сущность на несколько таким образом, чтобы ликвидировать транзитивные зависимости. Схема находится в третьей нормальной форме. (©) Владислав Лавров, vlavrov.com
  78. 78. 78 Построение информационной модели в ERwin Этап 5. Приведение модели к требуемому уровню нормальной формы Инструмент разрешения связей «многие-ко- многим» Окно корректировки связей между сущностями Область настройки установок мощности связи Редактируемая связь (©) Владислав Лавров, vlavrov.com
  79. 79. 79 Построение информационной модели в ERwin Этап 6. Переход к физическому описанию модели Выбор физического уровня представления модели Меню выбора целевой СУБД Окно выбора целевой СУБД (©) Владислав Лавров, vlavrov.com
  80. 80. 80 Построение информационной модели в ERwin Этап 7. Генерация базы данных Меню генерации базы данных Кнопка генерации Окно подключения к базе данных на сервере MS SQL Server 2000 (©) Владислав Лавров, vlavrov.com

×