Пример физической модели в бизнесе

Нормализация — процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели данных. Нормализация позволяет быть уверенным, что каждый атрибут определен для своей сущности, значительно сократить объем памяти для хранения данных.

Для рассмотрения видов нормальных форм введем понятия функциональной и полной функциональной зависимости.

Функциональная зависимость. Атрибут В сущности Е функционально зависит от атрибута А сущности Е, если и только если каждое значение А в Е связало с ним точно одно значение В в Е. Другими словами, А однозначно определяет В.

Полная функциональная зависимость. Атрибут Е сущности В полностью функционально зависит от ряда атрибутов А сущности Е, если и только если В функционально зависит от Л и не зависит ни от какого подряда А.

Существуют следующие виды нормальных форм:

• Первая нормальная форма

(1NF). Сущность Е находится в первой нормальной форме, если и только если все атрибуты содержат только атомарные значения. Среди атрибутов не должно встречаться повторяющихся групп, т. е. нескольких значений для каждого экземпляра.

Моделирование данных за 9 минут

• Вторая нормальная форма. Сущность Е находится во второй нормальной форме, если она находится в первой нормальной форме и каждый неключевой атрибут полностью зависит от первичного ключа, т. е. не существует зависимостей от части ключа.
• Третья нормальная форма (3 NF). Сущность Е находится в третьей нормальной форме, если она находится во второй нормальной форме и неключевые атрибуты сущности Е зависят от других атрибутов Е.

После третьей нормальной формы существуют нормальная форма Бойсса — Кодда, четвертая и пятая нормальные формы. На практике ограничиваются приведением к третьей нормальной форме. Часто после проведения нормализации все взаимосвязи данных становятся правильно определены, модель данных становится легче поддерживать. Однако нормализация не ведет к повышению производительности системы в целом, поэтому при создании физической модели в целях повышения производительности приходится сознательно отходить от нормальных форм, чтобы использовать возможности конкретного сервера. Такой процесс называется денормализацией.

1.1. Поддержка нормализации в ERWin

ERWin обеспечивает только поддержку нормализации, но не содержит в себе алгоритмов, автоматически преобразующих модель данных из одной формы в другую.

Поддержка первой нормальной формы В модели каждая сущность или атрибут идентифицируется с помощью имени. В ERWin поддерживает корректность имен следующим образом:

• отмечает повторное использование имени сущности и атрибута;
• не позволяет внести в сущность более одного внешнего ключа;
• запрещает присвоение неуникальных имен атрибутов внутри одной модели, соблюдая правило «в одном месте — один факт».

Создание физической модели

Целью создания физической модели является обеспечение администратора соответствующей информацией для переноса логической модели данных в СУБД.

примеры бизнес моделей

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

Таблица 7.1. Сопоставление компонентов логической и физической модели

Денормализация

После нормализации все взаимосвязи данных становятся определены, исключая ошибки-при оперировании данными. Но нормализация данных снижает быстродействие БД. Для более эффективной работы с данными, используя возможности конкретного сервера БД, приходится производить процесс, обратный нормализации, — денормализацию.

Для процесса денормализации не существует стандартного алгоритма, поэтому в каждом конкретном случае приходится искать свое решение. Денормализация обычно проводится на физическом уровне модели. ERWin имеет следующие возможности по поддержке процесса денормализации:

• Сущности, атрибуты, группы ключей и домены можно создавать только на логическом уровне модели. В

ERWin существует возможность выделения элементов логической модели таким образом, чтобы они не появлялись на физическом уровне.

• Таблицы, столбцы, индексы и домены можно создавать только на физическом уровне. В

ERWin существует возможность выделения элементов модели таким образом, чтобы они не появлялись на логическом уровне. Эта возможность напрямую поддерживает денормализацию физической модели, так как позволяет проектировщику включать таблицы, столбцы и индексы в физическую модель, ориентированную на конкретную СУБД.

• Разрешение связей «многие-ко-многим». При разрешении этих связей в логической модели ERWin добавляет ассоциированные сущности и позволяет добавить в них атрибуты. При разрешении связей в логической модели автоматически разрешаются связи и в физической модели.

Пример

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

Студент может иметь несколько адресов электронной почты и несколько телефонных номеров, что является нарушением первой нормальной формы. Необходимо создать отдельные сущности «E-mail» и «Телефон» и связать их с сущностью «Студент» (рис. 7.1).

Рис. 7.1. ERD-диаграмма БД студентов в первой нормальной форме

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

Для приведения БД к третьей нормальной форме необходимо обеспечить отсутствие транзитивных зависимостей неключевых атрибутов. Такая зависимость наблюдается у атрибутов «Специальность» и «Специализация» у сущности «Студент»: специализация зависит от специальности и от группы, в которой обучается студент.

Создадим новую независимую сущность «Специальность», перенеся в нее атрибут «Специализация» и создав новый атрибут «Группа», являющийся ключевым и определяющий атрибуты «Специальность» и «Специализация». Проведем неидентифици-рующую связь от сущности «Специальность» к сущности «Студент», при этом ключевой атрибут «Группа» мигрирует в сущность «Студент». Получим БД в третьей нормальной форме, так как других транзитивных зависимостей неключевых атрибутов нет (рис. 7.2).

Рис. 7.2. ERD-диаграмма БД студентов в третьей нормальной форме

Перейдем к построению физической модели. Перед построением физической модели необходимо выбрать тип базы данных в меню при создании физической модели. Выберем в качестве DataBase Microsoft Access 97 или 2000, получив физическую модель, сгенерированную ERWin по умолчанию (рис. 4.4).

В полученной модели необходимо скорректировать типы и размеры полей. Кроме того, на этапе создания физической модели данных вводятся правила валидации колонок, определяющие списки допустимых значений и значения по умолчанию (закладка Access у атрибута).

Таблица 7.2. Свойства колонок таблиц физической модели БД студентов

Источник: itteach.ru

Создание физической модели данных

Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. ERwin поддерживает ведение отдельных проектов, позволяя проектировщику выделять подмножество модели в виде предметных областей (Subject Area). Трансформационная модель позволяет проектировщикам и администраторам БД лучше представлять, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель данных удовлетворяет требованиям к ИС.

Модель СУБД автоматически генерируется из трансформационной модели и является точным отображением системного каталога СУБД. ERwin непосредственно поддерживает эту модель путем генерации системного каталога.

Физический уровень представления модели зависит от выбранного сервера. Для смены базы данных, в которой будет реализована физическая модель, следует в меню Database выбрать режим Choose Database. В открывшемся окне Computer Associates ERwin – Target Server (см. рис. 39) в блоке Target SQL DBMS следует установить переключатель на имени требуемой БД. В нижней части данного окна сразу будет отражен стандарт данной БД по длине и формату полей.

Рис. 39. Окно для выбора базы данных.

Пример физической модели данных представлен на рис. 40.

Рис. 40. Пример физической модели данных

По завершении работы над информационной моделью, как правило, распечатываются логический и физический уровни диаграммы, а также отчет по соответствиям сущность-таблица, атрибут-имя колонки, сущность-атрибуты. Для этого в меню Tools следует выбрать пункт Report Builder, в котором – подпункт Report Builder. Откроется диалоговое окно Report Templates (см. рис.

41), в котором следует выбрать тип отчета (например, Standard.erp) и тип представления выходных данных (HTML, RTF, TEXT) и нажать кнопку Run. Откроется диалоговое окно Import From ERP (см. рис. 42), в котором следует нажать кнопку Select All, а затем – кнопку ОК.

Диаграмма физической модели является необходимым, почти достаточным и очень удобным материалом для разработчиков программ.

Рис. 41. Окно для выбора типа отчета

Рис. 42. Окно для выбора компонентов отчета

Сгенерированный отчет может быть сохранен на диск (колонки разделяются запятыми, выравниваются или разделяются табуляцией) или передан в текстовый процессор (или электронную таблицу) через интерфейс DDE.

Экспорт данных в СУБД

Завершением построения логической, а также физической модели данных является экспорт созданных таблиц и их полей в системы управления базами данных (СУБД).

Рассмотрим экспорт данных на примере СУБД Access.

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

В Панели управления необходимо открыть элемент Источники данных ODBC (32 разряда) и перейти на вкладку Пользовательский DSN (см. рис. 43). Для создания нового источника данных пользователя следует нажать кнопку Добавить. В открывшемся диалоговом окне Создание нового источника данных (см. рис. 44) следует выбрать Microsoft Access Driver (*.mdb) и нажать кнопку Готово.

Рис. 43. Окно для выбора/настройки источника данных через ODBC.

Рис. 44. Окно для выбора драйвера нового источника данных.

Откроется диалоговое окно Установка драйвера ODBC для Microsoft Access (см. рис. 45), в котором следует: ввести имя источника данных (например, Экспорт в СУБД Access); ввести описание (например, Экспорт данных приложений в СУБД Access); выбрать (или создать) базу данных, в т.ч. допускается и пустую (см. кнопки Выбрать или Создать) и нажать кнопку ОК.

Рис. 45. Окно для настройки драйвера ODBC для Microsoft Access.

После этого следует перейти к настройке на экспорт данных созданной модели в ERwin.

Следует установить режим просмотра физической модели данных (меню Model режим Physikal model). После этого в меню Database необходимо выбрать режим Choose Database. В открывшемся окне Computer Associates ERwin – Target Server установить переключатель на ODBC/Generic, выбрать версию 3.0 из списка ODBC/Generic Version (см. рис. 46) и нажать кнопку ОК.

В открывшемся окне Computer Associates ERwin (см. рис. 47) следует отказаться от конвертации данных в ODBC, нажав кнопку No. В следующем открывшемся окне ODBC/Generic Connection (см. рис. 48) следует ввести: имя пользователя (User Name), пароль (Password), имя базы данных (Database) и нажать кнопку Connect.

Рис. 46. Окно для настройки на экспорт данных через ODBC.

Рис. 47. Окно для подтверждения конвертации данных в ODBC.

Рис. 48. Окно для настройки на соединение данных через ODBC.

После этого в меню Tools необходимо выбрать режим Forward Engineer/Schema Generation. В открывшемся окне DB2 Schema Generation (см. рис. 49) установить на вкладке Options требуемые флажки (в блоках Schema, View, Table следует установить флажки Drop… для удаления созданных ранее схем, процедур, таблиц) и нажать кнопку Generate.

Откроется диалоговое окно Computer Associates ERwin (см. рис. 50) следует подтвердить удаление старых таблиц из базы данных, нажав кнопку Yes. В следующем информационном окне Generate Database Schema (см. рис. 51) для просмотра информации по процессу генерации следует нажимать кнопку Continue, а по завершении процесса генерации – кнопку ОК.

Рис. 49. Окно для настройки экспортируемых данных.

Рис. 50. Окно для подтверждения удаления созданных ранее таблиц.

Рис. 51. Окно для просмотра хода генерации данных в СУБД.

Для прекращения установленного соединения с СУБД следует в меню Database выбрать режим Database Connection. В открывшемся окне ODBC/Generic Connection (см. рис. 52) следует нажать кнопку Disconnect.

Рис. 52. Окно для настройки на разрыв соединения через ODBC.

Задания на проектирование системы

Для проектирования экономической ИС по анализу работы условной фирмы требуется описать бизнес-процессы деятельности этой фирмы при помощи пакета BPwin и построить логическую и физическую модели данных при помощи пакета ERwin.

Список тем для проектирования:

1. Учет прибыли и ее использование

2. Организация учета материальных ценностей и их оценка

3. Учет нематериальных активов

4. Учет арендованных основных средств

5. Учет реализации продукции

6. Учет финансовых вложений

7. Учет расчетов с бюджетом и внебюджетными фондами

8. Учет готовой продукции и ее отгрузки потребителям

9. Расчеты с учредителями

10. Учет затрат на производство

11. Учет валютных операций

12. Учет расчетов с органами социального страхования и обеспечения

13. Учет расчетов по векселям

14. Выпуск продукции и калькулирование себестоимости

15. Расчеты по НДС

16. Учет МБП

17. Учет кассовых операций

18. Учет расчетов с поставщиками и подрядчиками

19. Учет движения материальных ценностей

20. Расчеты с бюджетом по налогам

21. Расчеты по заработной плате

22. Инвентаризация материальных ценностей

23. Учет расчетов с подотчетными лицами

24. Учет кредитов банка

25. Учет основных средств

26. Методы оценки материалов, отпускаемых на производство

27. Учет расчетов с разными дебиторами и кредиторами

28. Учет долгосрочной аренды основных средств

Требования к построению модели.

— в контекстной диаграмме входных (и выходных) документов должно быть не менее четырех;

— диаграмм декомпозиции должно быть не менее четырех, с учетом вложенности;

— каждая диаграмма декомпозиции должна состоять не менее чем из трех элементов «работа»;

— диаграмм потоков данных должно быть не менее двух;

— каждая диаграмма потоков данных должна состоять не менее чем из трех элементов «работа».

— полей в таблицах должно быть не менее семи;

— таблицы должны включать первичные ключи (связанные – еще и внешние ключи);

— связи таблиц должны быть как идентифицирующие так и не идентифицирующие;

Структура отчета следующая:

— экономическая постановка задачи (назначение разработки, основные документы по задаче),

— исходные данные (структура исходных таблиц),

— описание создания функциональной модели (BPwin) и модели данных (ERwin),

— распечатка (функциональная модель, бизнес-процессы, диаграмма потоков данных, отчеты по BPwin, логическая и физическая модели данных),

Список литературы

1. Маклаков С.В. Моделирование бизнес-процессов с Bpwin 4.0. – М.: ДИАЛОГ-МИФИ, 2002

2. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2002

3. Черемных С.В., Семенов И.О., Ручкин В.С. Структурный анализ систем: IDEF-технологии. — М.: Финансы и статистика, 2001

4. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник. – М.: Финансы и статистика, 2001

5. Маклаков С.В. BPwin, ERwin CASE-средства разработки информационных технологий. – М.: ДИАЛОГ-МИФИ, 2000

Учебно-методическое издание

МОРОЗОВА ВЕРА ИВАНОВНА,

Источник: infopedia.su

Концептуальное логическое и физическое моделирование данных

Модель данных — это совокупность метаданных (концептов) и их связей (более точно — мета-связей). Дадим простейший пример. Перед нами текст, описывающий бизнес-ситуацию: клиент по имени Петров оплатил счет и получил чек за три ручки и два карандаша в торговой точке (канцелярский бутик) внутри магазина «ГУМ»; основанием для покупки явилось воздействие рекламной компании, проводимой по радио. Что мы можем выделить из этого текста в качестве концептуальной модели данных?

• Объекты (концепты): Клиент. Счет. Оплата. Покупка. Чек. Товар. Кампания. Точка продаж. Рекламный канал.
• Отношения объектов (мета-связи): Клиент совершает Покупку. Клиент совершает Оплату. Клиент получает Товар. Чек отражает Оплату. Оплата соответствует Счету. Покупка совершена в Точке продаж. На Покупку повлияла Кампания. Кампания проводилась в рекламном Канале. Кампания таргетировала определенный Тип Клиентов.

Так рождается концептуальная модель, задающая тон всему последующему процессу проектирования информационной системы.

Существует три уровня (уровня абстрактности-детальности) в моделировании данных (их можно считать минимально рекомендованными стадиями проектирования операций над данными):

• Концептуальный -► концептуальная модель
• Логический -► логическая модель
• Физический -► физическая модель

Концептуальный уровень моделирования

Базовый элемент концептуальной модели: бизнес-сущность или бизнес-объект. Более точно — класс, то есть совокупность объектов (объектов реальности), отнесенных пользователями или экспертами к определенному классу. Примечение: это называют сущностью, если хотят подчеркнуть тот общий признак, ту суть, по которой объекты реальности отбираются в класс.

Это называют классом, если хотят подчеркнуть, что речь идет не об единичном объекте, а о множестве объектов с одинаковой сутью. Например, «пишущий прибор» — это и шариковая ручка, и карандаш, и ручка перьевая и сотни моделей различных ручек разной конструкции и эстетики. «Пишущий прибор» — сущность, суть которой — нЕчто, позволяющее писать. Но также «пишущий прибор» — указание на класс предметов реальности (=объектов реальности), с помощью которых можно писать.

Примеры бизнес-сущностей:

• клиент (как вариант, клиент-ФЛ, клиент-ЮЛ),
• продукт (как вариант, товар, услуга),
• сделка (как вариант, заказ),
• контракт.

Концептуальная модель бизнеса (модель размышления или онтологическая картинка бизнеса), как правило, представлена в документах класса ГЛОССАРИЙ. Это может быть как местная wiki, так и разрозненные главы типа «Глоссарий» в различных документах компании.

Качество таких глоссариев не высокое, для автоматизации и тем более цифровизации они не годятся, но безусловно словарь или тезаурус — это первый артефакт, с изучения которого должен начать аналитик. Цель аналитика — построить настоящую концепт-модель из концептуальных объектов данных, где объект данных — это контейнер с атрибутами, имеющий как четкие семантически границы, так и выделенные свойства объекта — атрибуты. Собственно атрибуты-свойства и есть лучший способ определения концептуального объекта. Если вы не можете выделить атрибуты (ну естественно речь идет о мета-атрибутах), то такой концепт не важен для автоматизации или цифровизации, хотя может быть важен для понимания полной онтологической картины предметной области. Схематически (графически) наиболее удобным способом представления концептуальной модели является схема типа «диаграмма классов». Изображение каждого класса на схеме содержит:

• имя класса (знак у Ф.Готлоба)
• описание класса (определение сущности или семантики классов в виде 1-2-3-10 предложений).
• мета-атрибуты класса (или свойства-характеристики класса). С точки зрения ИТ, атрибуты являются табличным способом определения функции соотнесения объектов реальности со знаком класса (см. концентроид Рудда).
• связи класса — ассоциации, композиции, специализации — отношения класса к другим классам (то есть мета-связи).

Например, концепт АВТОМОБИЛЬ может быть задан так: любой предмет реальности, у которого можно указать наличие и свойства таких его компонентов, как объем двигателя, габариты, числов возможных пассажиров в кабине. Под такое определение может попасть и кран, и грузовик, и трактор. И это вам решать, имеет ли место быть концептуальная ошибка или нет.

Концептуализация вещей и предметов является относительно простой задачей. Концептуализация явлений сложнее. Концептуализация ментально-когнитивных явлений наиболее сложна. Дайте концептуальное определение и мета-атрибуты для таких явлений, как ПРОБЛЕМА, ПРЕТЕНЗИЯ, ИНИЦИАТИВА, ИДЕЯ. Легко?

Потренируйтесь также в определении того, что есть ТРЕБОВАНИЕ, ОГРАНИЧЕНИЕ, ПРИНЦИП, ИНТЕРЕС, ФУНКЦИЯ, ПРОЦЕССНЫЙ ШАГ.

Бизнес-сущности имеют связи друг с другом. Связи при именовании полезно «окрашивать» именами действий или отношений из предметной области, например, клиент заключает сделку , заказ состоит из товаров . Наилучшая нотация для концептуального уровня — подборка элементов из слоя Business и Motivation методологии Archimate. В данной нотации рекомендуется использоваться объект Meaning, а также бизнес-сущности могут быть привязаны к ряду других элементов (например, value или capability), что улучшает их окрашивание или лучше структурирует (делает более наглядной) моделируемую предметную область.

Фокус моделирования:

• понятийная/смысловая модель, выработка глоссария
• разработка онтологии домена (онтики)
• создание/проработка представления о понятии/явлении, как об информационном объекте (см. концентроид Рудда)
• выделение ключевых атрибутов, характеризующих ту или иную бизнес-сущность

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

• при создании BI-систем
• при создании модели данных интеграционной платформы.

В отдельных случаях приходится поддерживать концептуальную модель двух видов:

• текущую концепт.модель, являющуюся мостиком между логическими моделями данных конкретных приложений.
• текущую концепт.модель, отражающую текущее понимание нами онтологии предметной области. Эта модель может меняться почти каждый день.

Для дизайна и управления концептуальной моделью данных может быть использована российская СиММА — система многослойного моделирования архитектуры.

Логический уровень моделирования

Логическая модель является уточнением и детализацией концептуальной модели. Но это лишь с одной стороны (со стороны концептуального моделирования). С противоположной стороны (со стороны реализации) на построение логической модели влияет:

• тип планируемой СУБД, которая будет воплощать модель или выбранный framework (как правило, объектно-ориентированный)
• класс проектируемой системы: операционная (транзакционная) или аналитическая (BI)
• исторически сложившияся трактовка предметной области вендором системы

Назначение моделей логического уровня или зачем это нужно? Логический уровень моделирования — это уровень логики организации данных, то есть какие данные и как сгруппированы и связаны друг с другом.

Концептуальный уровень больше заботится о смысловой нагрузке, выраженной в связях, логический — заботится о скрупулезном учете фактических (реальных) связей, предусмотренных программистом между объектами системы (ссылки объектов друг на друга, отношения объектов). Концептуальный уровень оперирует бизнес-сущностями, логический — сущностями будущей или фактически имеющейся информационной системы (например, базы данных). В компаниях с большой историей логический уровень задан фактически развернутыми системами конкретных вендоров. На вопрос «зачем нужен логический уровень?» можно было бы ответить так: «это тот набор мыслей, с которым вы садитесь что-то программировать, его не может не быть».

Примечание: логический — не означает выделенный с точки зрения здравого смысла и причинно-следственных рассуждений. Логический — значит формализованный по законам формальной (!) логики выбранного способа представления данных: таблично-реляционного или объектно-ориентированного, или сетевого, векторного, графового и т.д. Причины неудач в процессной автоматизации связаны с тем, что 9 из 10 аналитиков и программистов не в состоянии формализовать на логическом уровне такое сложное явление как «процесс», потому что никогда не слышали об алгебре процессов (и даже более того — безнадежно застряли в модели акторов). А, как известно, без формализации нет и автоматизации. Точнее сказать, наблюдается автоматизация процесса в акторной модели — путь в тупик далеких 90-х.

Важное замечание №1. В простейших случаях концептуальные объекты (бизнес-сущности) совпадают с объектами логического уровня. В таких случаях фаза концептуального моделирования может совсем не требоваться или совпадать с фазой построения логической модели.

Важное замечание №2. Очень часто молодые системные аналитики пытаются построить сложную логическую модель и проваливают работу, не подозревая о необходимости фазы концептуального моделирования, которая должна выполняться с участием бизнес-аналитиков и самого бизнеса. В настоящее время — время диджитал — концептуализация и цифровизация должны рассматриваться как синонимы. Ну и конечно же не стоит забывать про DDD: чем строже соответствие логической и концептуальной моделей (вплоть до совпадения), тем лучше для качества проекта.

Тип объектов логического уровня соответствует типам объектов избранной СУБД или фреймворка. Для реляционных баз данных — это кортеш из атрибутов одной таблицы. Для объектно-ориентированных баз данных и фреймворков — это собственно «объекты».

Объекты логического уровня (их часто называют ENTITY, сущности) — это то, чем оперирует информационная система (база данных или сервер приложений) или программист [в ходе написания кода]. К сущностям логического уровня подвязываются методы работы с этими сущностями. То есть в зависимости от того, какая именно физическая реализация концепт-модели будет выбрана, сущности логического уровня получат опеределенные степени сводобы-несвободы.

Базовый элемент логической модели: сущность или объект (в ООП — класс, где объект — экземпляр класса).

Для проектирования реляционных баз данных используется нотация ERD. Рамками этой нотации фактически и задаётся логический уровень моделирования. Однако для систем, имеющих на верхнем уровне объектную модель, логический уровень описывается диаграммной классов (из нотации UML). Детализирующие (вспомогательные) и часто используемые диаграммы логического уровня моделирования — это диаграммы состояний.

Примеры сущностей (классов):

• клиент -► party + customer + customer_profile + person
• продукт -► продукт + предложение продукта + price plan
• заказ -► order, order_item, delivery_spec

Фокус моделирования:

• выделение элементарных сущностей, элементарных логических единиц (классов), имеющих самостоятельный смысл в моделируемой предметной области.
• детальное (точное) уточнение (установка) взаимосвязей между сущностями
• перечисление всех (!) значимых для бизнеса атрибутов сущности
• разделение атрибутов на простые атрибуты и перечисления (будущие справочники)
• выделение сущностей не столько как контейнеров для атрибутов, сколько как объектов поведения.

Немаловажное влияние на сущности логического уровня и их взаимосвязи оказывает тип проектируемой системы. Если проектируемая система относится к BI-классу, то следует понимать назначение BI-системы, ожидаемые от нее витрины, срезы, аналитики, метод моделирования времени (динамики изменения данных) и т.п.

Если в ходе проектирования разрабатывается логическая модель не одной, а нескольких систем, что часто имеет место быть в крупных компаниях, внедряющих пятую, десятую или сто двадцатую систему, то при разработке логической модели указывают к какой системе принадлежит (или будет принадлежать) та или иная сущность. Распределение сущностей по различным информационным системам даёт возможность грубо наметить (спрогнозировать) будущие информационные потоки (и точки интеграции) между системами.

Важное замечание. При разработке новой информационной системы, являющейся частью комплекса унаследованных систем, часто приходится использовать как проектирование сверху вниз (от концептуального уровня к физическому), так и обратное — снизу вверх: от уже существующих физических моделей к логической и далее мапирование в концептуальную. Это на порядок или даже на 2 порядка усложняет проектирование даже если нужно создать/автоматизировать один сквозной процесс, протекающий через ряд информационных систем.

Иногда при проработке логического уровня возникают сущности, которые трудно подвязать к бизнес-сущностям концептуального уровня и тогда возникает вопрос: нужно ли на концептуальном уровне завести новую бизнес-сущность? Ответ таков:

• с одной стороны, не стоит перегружать концептуальный уровень.
• с другой стороны, если на концептуальном уровне появляется новая сущность, она должна быть отражена в глоссарии, как принципиально новое понятие, существенно отличное от других понятий данной предметной области.
• не ленитесь использоваться для организации сущностей отношения наследования-специализации.

Каждый вендор информационной системы имеет логическую модель своей системы даже если он и не раскрывает ее своим клиентам. При интеграции нескольких систем приходится сначала увязывать их логические модели на концептуальном уровне моделирования, а лишь потом строить связи между логическими моделями разных систем. Например, в системе автоматизации продаж клиент может быть представлен как PARTY, в ERP-системе той же компании как КОНТРАГЕНТ, а системе биллинга той же компании, как АБОНЕНТ.

Физический уровень моделирования

Физический уровень — это уровень таблиц для реляционных моделей данных.

Базовый элемент физической модели: таблица.

Примеры таблиц:

• клиент -► table_1
• продукт -► table_2
• сделка -► table_3

Не исключается, что одна таблица физического уровня может участвовать в моделировании сразу нескольких логических сущностей.

Фокус моделирования:

• Выделение отдельных таблиц, в том числе как результат нормализации данных.
• Выделение таблиц-справочников.
• Определение ключей.
• Разделение атрибутов на простые атрибуты и перечисления (будущие справочники)

В простейших случаях логические объекты (сущности) совпадают с объектами физического уровня. Это характерно для самых простых баз данных реляционного типа.

Источник: marcus-aurelius.ru