Что такое элемент модели
элемент модели
3.4 элемент модели: Важная составляющая физической системы, описываемой моделью.
Смотри также родственные термины:
3.1.8 элемент модели данных (Data Model Element; DME): Составной элемент или элемент данных.
Полезное
Смотреть что такое «элемент модели» в других словарях:
элемент модели данных — 3.1.8 элемент модели данных (Data Model Element; DME): Составной элемент или элемент данных. Источник … Словарь-справочник терминов нормативно-технической документации
элемент — 02.01.14 элемент (знак символа или символ) [element ]: Отдельный штрих или пробел в символе штрихового кода либо одиночная многоугольная или круглая ячейка в матричном символе, формирующие знак символа в… … Словарь-справочник терминов нормативно-технической документации
элемент данных — 3.4 элемент данных: Смысловой элемент информации, прослеживаемый на стыке между картой и устройством сопряжения, для которого определены наименование, описание логического содержания, формат и кодирование. Источник … Словарь-справочник терминов нормативно-технической документации
Модели нейронных сетей (neural network models) — Модели, включающие сети нейроноподобных элементов, приобрели известность в психологии и родственных дисциплинах, когнитивной науке и нейробихевиоральной науке. Такие модели появились тж под предметными заголовками коннекционистских моделей и… … Психологическая энциклопедия
элемент — Обобщенный термин, под которым в зависимости от соответствующих условий может пониматься поверхность, линия, точка. Примечания 1. Элемент может быть поверхностью (частью поверхности, плоскостью симметрии нескольких поверхностей), линией (профилем … Справочник технического переводчика
элемент внешнего ориентирования (фотограмметрической) модели — Один из геометрических параметров, определяющих положение, ориентацию фотограмметрической модели объекта в системе координат объекта фотограмметрической съемки и ее масштаб. [ГОСТ Р 51833 2001] Тематики фотограмметрия … Справочник технического переводчика
Элемент — [element] первичная (для данного исследования, модели) составная часть сложного целого. См. Элемент множества, Элемент системы … Экономико-математический словарь
элемент системы — Активный компонент компьютерной системы/сети. Например, автоматизированный процесс или множество процессов, подсистема, человек или группа людей, которые обладают отличительным набором функций (МСЭ Т Х.1141). [http://www.iks… … Справочник технического переводчика
элемент — ЭЛЕМЕНТ (лат. elementum) член ряда, часть целого, термин античной философии. Первоначально буквы. Разные тексты порождаются одним и тем же набором букв (Лукреций). Графическое (буквенное) изображение Э. сродни использованию в тех же целях … Энциклопедия эпистемологии и философии науки
Элемент системы — [element of a system] часть системы, которая рассматривается без дальнейшего членения как единой целое, его внутренняя структура не является предметом исследования. Выбор элемента как первичной единицы определяется характером и задачами модели… … Экономико-математический словарь
Что такое элемент модели
Модель UML (UML model) ‒ это совокупность конечного множества конструкций языка, главные из которых ‒ это сущности и отношения между ними.
Сами сущности и отношения модели являются экземплярами метаклассов метамодели.
Рассматривая модель UML с наиболее общих позиций, можно сказать, что это граф (точнее, нагруженный мульти-псевдо-гипер-орграф), в котором вершины и ребра нагружены дополнительной информацией и могут иметь сложную внутреннюю структуру. Вершины этого графа называются сущностями, а ребра ‒ отношениями. Остальная часть раздела содержит беглый (предварительный), но полный обзор имеющихся типов сущностей и отношений. К счастью, их не слишком много. В последующих главах книги все сущности и отношения рассматриваются еще раз, более детально и с примерами.
1.4.1. Сущности
Для удобства обзора сущности в UML можно подразделить на четыре группы:
Структурные сущности, как нетрудно догадаться, предназначены для описания структуры. Обычно к структурным сущностям относят следующие.
Объект (object) 1 ‒ сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение.
Класс (class) 2 ‒ описание множества объектов с общими атрибутами, определяющими состояние, и операциями, определяющими поведение.
Интерфейс (interface) 3 ‒ именованное множество операций, определяющее набор услуг, которые могут быть запрошены потребителем и предоставлены поставщиком услуг.
Кооперация (collaboration) 4 ‒ совокупность объектов, которые взаимодействуют для достижения некоторой цели.
Действующее лицо (actor) 5 ‒ сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.
Компонент ∇ (component) 6 ‒ модульная часть системы с четко определенным набором требуемых и предоставляемых интерфейсов.
Артефакт (artifact) 7 ‒ элемент информации, который используется или порождается в процессе разработки программного обеспечения. Другими словами, артефакт ‒ это физическая единица реализации, получаемая из элемента модели (например, класса или компонента).
Узел (node) 8 ‒ вычислительный ресурс, на котором размещаются и при необходимости выполняются артефакты.
∇ В русском языке допустимо использование слова «компонент» мужского рода и слова «компонента» женского рода. Современная языковая практика склоняется к использованию мужского рода, поэтому мы употребляем, например, термин «диаграмма компонентов». Но в некоторых случаях традиция требует использования женского рода, например, «компонента связности графа».
На следующем рисунке приведена стандартная нотация в минимальном варианте для структурных сущностей.
Рис. Нотация структурных сущностей
Поведенческие сущности предназначены для описания поведения. Основных поведенческих сущностей всего две: состояние и действие (точнее, две с половиной, потому что иногда употребляется еще и деятельность, которую можно рассматривать как особый случай состояния).
Состояние (state) 1 ‒ период в жизненном цикле объекта, находясь в котором объект удовлетворяет некоторому условию и осуществляет собственную деятельность или ожидает наступления некоторого события.
Деятельность (activity) 2 можно считать частным случаем состояния, который характеризуется продолжительными (по времени) не атомарными вычислениями.
Действие (action) 3 ‒ примитивное атомарное вычисление.
Это только надводная часть айсберга поведенческих сущностей: состояния бывают самые разные (см. раздел 4.2). Кроме того, при моделировании поведения используется еще ряд вспомогательных сущностей, которые здесь не перечислены, потому что сосуществуют только вместе с указанными основными.
Несколько особняком стоит сущность ‒ вариант использования.
Вариант использования (use case) 4 ‒ множество сценариев, объединенных по некоторому критерию и описывающих последовательности производимых системой действий, доставляющих значимый для некоторого действующего лица результат.
Ниже приведена стандартная нотация в минимальном варианте для поведенческих сущностей.
Рис. Нотация поведенческих сущностей
Группирующая сущность в UML одна ‒ пакет ‒ зато универсальная.
Пакет (package) 1 ‒ группа элементов модели (в том числе пакетов).
Аннотационная сущность тоже одна ‒ комментарий.
Комментарий (comment) 2 ‒ произвольное по формату и содержанию описание одного или нескольких элементов модели.
Рис. Нотация группирующей и аннотационной сущностей
Приведенная классификация не является исчерпывающей. У каждой из этих сущностей есть различные частные случаи и вариации, рассматриваемые в последующих главах.
1.4.2. Отношения
В UML используются четыре основных типа отношений:
Зависимость ‒ это наиболее общий тип отношения между двумя сущностями.
Отношение зависимости указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность.
Рис. Отношение зависимости
Ассоциация ‒ это наиболее часто используемый тип отношения между сущностями.
Отношение ассоциации имеет место, если одна сущность непосредственно связана с другой (или с другими ‒ ассоциация может быть не только бинарной).
Графически ассоциация изображается в виде сплошной линии 1 с различными дополнениями, соединяющей связанные сущности, как показано на следующем рисунке. На программном уровне непосредственная связь может быть реализована различным образом, главное, что ассоциированные сущности знают друг о друге. Например, отношение часть-целое является частным случаем ассоциации и называется отношением агрегации.
Рис. Отношение ассоциации
Обобщение ‒ это отношение между двумя сущностями, одна их которых является частным (специализированным) случаем другой.
Рис. Отношение обобщения
Отношение реализациии используется несколько реже, чем предыдущие три типа отношений, поскольку часто подразумеваются по умолчанию.
Отношение реализации указывает, что одна сущность является реализацией другой.
Рис. Отношение реализации
Перечисленные типы отношений являются основными, различные их вариации и дополнительные отношения детально рассматриваются в последующих главах.
1.4.3. Диаграммы
Предыдущий параграф преследует примерно те же цели, какие имеет описание лексики в обычном языке программирования. А именно, мы обрисовали (еще не полностью, но уже достаточно) множество слов UML (лексем, графических примитивов, элементов моделирования ‒ называйте, как хотите ‒ фиксированного термина нет). Пора переходить к синтаксису, а именно к описанию того, как из слов конструируются предложения.
На первый взгляд, все очень просто: берутся сущности и, если нужно, указываются отношения между ними. В результате получается модель, то есть граф (с разнородными вершинами и ребрами), нагруженный дополнительной информацией. Но при более внимательном рассмотрении обнаруживаются проблемы. Мы хотим затратить некоторые усилия на обсуждение этих проблем, иначе целый ряд особенностей UML может показаться висящим в воздухе, хотя на самом деле, эти особенности и есть продуманное решение замалчиваемых обычно проблем.
∇ Скажем, эту книгу ‒ не в качестве образца, а в качестве примера.
∇∇ Смеем вас уверить, что писать структурированный текст также намного легче.
Диаграммы UML и есть та основная накладываемая на модель структура, которая облегчает создание и использование модели.
Диаграмма (diagram) ‒ это графическое представление некоторой части графа модели.
Вообще говоря, в диаграмму можно было бы включить любые (допустимые) комбинации сущностей и отношений, но произвол в этом вопросе затруднил бы понимание моделей. Поэтому авторы UML определили набор рекомендуемых к использованию типов диаграмм, которые получили название канонических типов диаграмм.
Инструменты моделирования, как правило, обеспечивают работу со всеми каноническими диаграммами, но делают это довольно догматически, не позволяя отойти от канона ни на шаг, даже если это нужно по существу задачи. С другой стороны, некоторые инструменты, наряду с каноническими, поддерживают и апокрифические типы диаграмм. Было бы удобно, если бы набор канонических диаграмм предлагался по умолчанию, но пользователь мог бы настроить, изменить и переопределить этот набор в случае необходимости, примерно так, как это делается с шаблонами Microsoft Word. Некоторые инструменты, но далеко не все, поддерживают такие возможности.
Заметим, что помимо сущностей и отношений на диаграмме присутствует другие элементы модели, которые мы также будем называть конструкциями языка. Это тексты, которые могут быть написаны внутри фигур сущностей или рядом с линиями отношений, рамки диаграмм и их фрагментов, значки, присоединяемые к линиям или помещаемые внутрь фигур. Эти элементы не только помогают представить модель в более наглядной форме, но подчас несут значительную смысловую нагрузку.
1.4.4. Классификация диаграмм
В UML 1 ∇ всего определено 9 канонических типов диаграмм. Ниже перечислены их названия, принятые в этой книге (в других источниках есть отличия).
∇ Здесь и далее под UML 1 понимаются версии UML, предшествующие UML 2.0.
∇ В некоторых источниках название этого типа диаграмм переводится как «диаграмма прецедентов», что является грубейшей терминологической ошибкой. Не советуем пользоваться такими источниками ‒ скорее всего, их авторы не понимают того, о чем пишут.
∇∇ В некоторых источниках название данной диаграммы переводится как «диаграмма развертывания».
Этот список является итогом многочисленных дискуссий и компромиссов, поэтому не следует воспринимать его как догму. В частности, расхожее утверждение «в UML определены девять типов диаграмм» является не совсем верным: в метамодели UML определены элементы модели (сущности и отношения) и способы их комбинирования, а девять типов диаграмм ‒ это уже надстройка над языком, отражающая сложившуюся практику его использования.
Канонические диаграммы отнюдь не образуют полного ортогонального набора: они пересекаются как по включенным в них средствам, так и по области применения. Более того, некоторые из них являются частными случаями других, есть просто семантически эквивалентные пары, можно привести примеры допустимых диаграмм, для которых затруднительно указать однозначно, к какому именно из канонических типов диаграмма относится.
Сказанное можно проиллюстрировать условной классификацией диаграмм, приведенной ниже.
Рис. Иерархия типов диаграмм для UML 1
∇ Здесь и далее под UML 2 понимаются версии UML, начиная с UML 2.0.
∇∇ В UML 1 возникала невольная ассоциация между диаграммой кооперации и одноименной сущностью, что было не совсем верно и порой вводило в заблуждение.
∇∇∇ В UML 2 синтаксическая и смысловая нагрузка диаграммы состояний настолько изменилась, что название уже не отражало содержания.
Список новых диаграмм и их названий, принятых в этой книге, приведен ниже.
На рис. Иерархия типов диаграмм для UML 2 (часть 1 и 2) приведена диаграмма классов, отражающая взаимосвязь диаграмм в UML 2.
Рис. Иерархия типов диаграмм для UML 2 (часть 1)
Рис. Иерархия типов диаграмм для UML 2 (часть 2)
Далее в этой главе мы очень бегло опишем все тринадцать канонических диаграмм, с тем, чтобы иметь определенный контекст и словарный запас для последующего изложения. Детали изложены в остальных главах книги.
Но прежде чем перейти к следующему разделу, сделаем одно небольшое отступление относительно того, как стандарт требует оформлять диаграммы. Общий шаблон представления диаграммы приведен ниже.
Рис. Нотация для диаграмм
Основных элементов оформления два: наружная рамка и ярлычок с названием диаграммы. Если с рамкой все просто ‒ это прямоугольник, ограничивающий область в котором должны находиться элементы диаграммы, то название диаграммы записывается в специальном формате, приведенном на рис. Нотация для диаграмм.
Указанная сложная форма ярлычка поддерживается не всеми инструментами. Впрочем, это не обязательно, поскольку семантика первична, а нотация вторична. Далее мы везде используем в качестве ярлычка диаграммы прямоугольник, и это не должно вызывать недоразумений.
Возможные теги (типы) для диаграмм приведены в следующей таблице. Теги, предлагаемые стандартом, записаны во второй столбец. Однако, как показала практика, предлагаемые стандартом правила не всегда удобны и логически обоснованы, поэтому третий столбец таблицы содержит разумную на наш взгляд альтернативу.
Моделирование данных: зачем нужно и как реализовать
Моделирование данных ощутимо упрощает взаимодействие между разработчиками, аналитиками и маркетологами, как и сам процесс создания отчетов. Поэтому я перевела статью IBM Cloud Education о ценности моделирования и от себя добавила инфо о способах трансформации данных для моделирования.
Моделирование данных
Узнайте, как моделирование данных использует абстракцию для представления и лучшего понимания природы данных в информационной системе предприятия.
Что такое моделирование данных
Моделирование данных — это создание визуального представления о всей информационной системе либо ее части. Цель в том, чтобы проиллюстрировать типы данных, которые используются и хранятся в системе, отношения между этими типами данных, способы группировки и организации данных, их форматы и атрибуты.
Модели данных строятся на основе бизнес-потребностей. Правила и требования к модели данных определяются заранее на основе обратной связи с бизнесом, поэтому их можно включить в разработку новой системы или адаптировать к существующей.
Данные можно моделировать на различных уровнях абстракции. Процесс начинается со сбора бизнес-требований от заинтересованных сторон и конечных пользователей. Эти бизнес-правила затем преобразуются в структуры данных. Модель данных можно сравнить с дорожной картой, планом архитектора или любой формальной схемой, которая способствует более глубокому пониманию того, что разрабатывается.
Моделирование данных использует стандартизированные схемы и формальные методы. Это обеспечивает последовательный и предсказуемый способ управления данными в организации или за ее пределами.
В идеале модели данных — это живые документы, которые развиваются вместе с потребностями бизнеса. Они играют важную роль в поддержке бизнес-процессов и планировании ИТ-архитектуры и стратегии. Моделями данных можно делиться с поставщиками, партнерами и коллегами.
Преимущества моделирования данных
Моделирование упрощает просмотр и понимание взаимосвязей между данными для разработчиков, архитекторов данных, бизнес-аналитиков и других заинтересованных лиц. Кроме того, моделирование данных помогает:
Уменьшить количество ошибок при разработке программного обеспечения и баз данных.
Унифицировать документацию на предприятии.
Повысить производительность приложений и баз данных.
Упростить отображение данных по всей организации.
Улучшить взаимодействие между разработчиками и командами бизнес-аналитики.
Упростить и ускорить процесс проектирования базы данных на концептуальном, логическом и физическом уровнях.
Типы моделей данных
Разработка баз данных и информационных систем начинается с высокого уровня абстракции и с каждым шагом становится все точнее и конкретнее. В зависимости от степени абстракции модели данных можно разделить на три категории. Процесс начинается с концептуальной модели, переходит к логической модели и завершается физической моделью.
Концептуальные модели данных. Также они называются моделями предметной области и описывают общую картину: что будет содержать система, как она будет организована и какие бизнес-правила будут задействованы. Концептуальные модели обычно создаются в процессе сбора исходных требований к проекту. Как правило, они включают классы сущностей (вещи, которые бизнесу важно представить в модели данных), их характеристики и ограничения, отношения между сущностями, требования к безопасности и целостности данных. Любые обозначения обычно просты.
Логические модели данных уже не так абстрактны и предоставляют более подробную информацию о концепциях и взаимосвязях в рассматриваемой области. Они содержат атрибуты данных и показывают отношения между сущностями. Логические модели данных не определяют никаких технических требований к системе. Этот этап часто пропускается в agile или DevOps-практиках. Логические модели данных могут быть полезны для проектов, ориентированных на данные по своей природе. Например, для проектирования хранилища данных или разработки системы отчетности.
Физические модели данных представляют схему того, как данные будут храниться в базе. По сути, это наименее абстрактные из всех моделей. Они предлагают окончательный дизайн, который может быть реализован как реляционная база данных, включающая ассоциативные таблицы, которые иллюстрируют отношения между сущностями, а также первичные и внешние ключи для связи данных.
Процесс моделирования данных
Моделирование данных начинается с договоренности о том, какие символы используются для представления данных, как размещаются модели и как передаются бизнес-требования. Это формализованный рабочий процесс, включающий ряд задач, которые должны выполняться итеративно. Сам процесс обычно выглядят так:
Определите сущности. На этом этапе идентифицируем объекты, события или концепции, представленные в наборе данных, который необходимо смоделировать. Каждая сущность должна быть целостной и логически отделенной от всех остальных.
Определите ключевые свойства каждой сущности. Каждый тип сущности можно отличить от всех остальных, поскольку он имеет одно или несколько уникальных свойств, называемых атрибутами. Например, сущность «клиент» может обладать такими атрибутами, как имя, фамилия, номер телефона и т.д. Сущность «адрес» может включать название и номер улицы, город, страну и почтовый индекс.
Определите связи между сущностями. Самый ранний черновик модели данных будет определять характер отношений, которые каждая сущность имеет с другими. В приведенном выше примере каждый клиент «живет по» адресу. Если бы эта модель была расширена за счет включения сущности «заказы», каждый заказ также был бы отправлен на адрес. Эти отношения обычно документируются с помощью унифицированного языка моделирования (UML).
Полностью сопоставьте атрибуты с сущностями. Это гарантирует, что модель отражает то, как бизнес будет использовать данные. Широко используются несколько формальных шаблонов (паттернов) моделирования данных. Объектно-ориентированные разработчики часто применяют шаблоны для анализа или шаблоны проектирования, в то время как заинтересованные стороны из других областей бизнеса могут обратиться к другим паттернам.
Назначьте ключи по мере необходимости и определите степень нормализации. Нормализация — это метод организации моделей данных, в которых числовые идентификаторы (ключи) назначаются группам данных для установления связей между ними без повторения данных. Например, если каждому клиенту назначен ключ, этот ключ можно связать как с его адресом, так и с историей заказов, без необходимости повторять эту информацию в таблице с именами клиентов. Нормализация помогает уменьшить объем дискового пространства, необходимого для базы данных, но может сказываться на производительности запросов.
Завершите и проверьте модель данных. Моделирование данных — это итеративный процесс, который следует повторять и совершенствовать под потребности бизнеса.
Типы моделирования данных
Моделирование данных развивалось вместе с системами управления базами данных (СУБД), при этом типы моделей усложнялись по мере роста потребностей предприятий в хранении данных.
Иерархические модели данных представляют отношения «один ко многим» в древовидном формате. В модели этого типа каждая запись имеет единственный корень или родительский элемент, который сопоставляется с одной или несколькими дочерними таблицами. Эта модель была реализована в IBM Information Management System (IMS) в 1966 году и быстро нашла широкое применение, особенно в банковской сфере. Хотя этот подход менее эффективен, чем недавно разработанные модели баз данных, он все еще используется в системах расширяемого языка разметки (XML) и географических информационных системах (ГИС).
Реляционные модели данных были предложены исследователем IBM Э. Ф. Коддом в 1970 году. Они до сих пор встречаются во многих реляционных базах данных, обычно используемых в корпоративных вычислениях. Реляционное моделирование не требует детального понимания физических свойств используемого хранилища данных. В нем сегменты данных объединяются с помощью таблиц, что упрощает базу данных.
Реляционные базы данных часто используют язык структурированных запросов (SQL) для управления данными. Эти базы подходят для поддержания целостности данных и минимизации избыточности. Они часто используются в кассовых системах, а также для других типов обработки транзакций.
В ER-моделях данных используют диаграммы для представления взаимосвязей между сущностями в базе данных. ER-модель представляет собой формальную конструкцию, которая не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма «сущность-связь» (Entity-Relationship diagram). Однако для визуализации ER-моделей могут использоваться и другие графические нотации, либо визуализация может вообще не применяться (например, только текстовое описание).
Объектно-ориентированные модели данных получили распространение как объектно-ориентированное программирование и стали популярными в середине 1990-х годов. Вовлеченные «объекты» — это абстракции сущностей реального мира. Объекты сгруппированы в иерархии классов и имеют связанные черты. Объектно-ориентированные базы данных могут включать таблицы, но могут также поддерживать более сложные связи. Этот подход часто используется в мультимедийных и гипертекстовых базах данных.
Размерные модели данных разработал Ральф Кимбалл для быстрого поиска данных в хранилище. Реляционные и ER-модели делают упор на эффективное хранение и уменьшают избыточность данных, а размерные модели упорядочивает данные таким образом, чтобы легче было извлекать информацию и создавать отчеты. Это моделирование обычно используется в системах OLAP.
Две популярные размерные модели данных — это схемы «звезда» и «снежинка». В схеме «звезда» данные организованы в факты (измеримые элементы) и измерения (справочная информация), где каждый факт окружен связанными с ним измерениями в виде звездочки. Схема «снежинка» напоминает схему «звезда», но включает дополнительные слои связанных измерений, что усложняет схему ветвления.
Инструменты для моделирования данных
Сегодня широко используются многочисленные коммерческие и CASE-решения с открытым исходным кодом, в том числе различные инструменты моделирования данных, построения диаграмм и визуализации. Вот несколько примеров:
erwin Data Modeler — это инструмент моделирования данных, основанный на языке IDEF1X, который теперь поддерживает и другие нотации, включая нотацию для размерного моделирования.
Enterprise Architect — это инструмент визуального моделирования и проектирования, который поддерживает моделирование корпоративных информационных систем и архитектур, программных приложений и баз данных. Он основан на объектно-ориентированных языках и стандартах.
ER/Studio — это программа для проектирования баз данных, совместимая с некоторыми из самых популярных СУБД. Она поддерживает как реляционное, так и размерное моделирование данных.
Бесплатные инструменты моделирования данных включают решения с открытым исходным кодом, такие как Open ModelSphere.
Для того, чтобы преобразовать данные в структуру, которая соответствует требованиям модели, можно использовать встроенный механизм регулярных запросов, которые выполняются в Google BigQuery, Scheduled Queries и AppScript. Их легко можно освоить, потому что это привычный SQL, но проводить отладку в Scheduled Queries практически нереально. Особенно, если это какой-то сложный запрос или каскад запросов.
Есть специализированные инструменты для управления SQL-запросами, например, dbt и Dataform.
dbt (data build tool) — это фреймворк с открытым исходным кодом для выполнения, тестирования и документирования SQL-запросов, который позволяет привнести элемент программной инженерии в процесс анализа данных. Он помогает оптимизировать работу с SQL-запросами: использовать макросы и шаблоны JINJA, чтобы не повторять в сотый раз одни и те же фрагменты кода.
Главная проблема, которую решают специализированные инструменты — это уменьшение времени, необходимого на поддержку и обновление. Это достигается за счет удобства отладки.