Моделирование данных: зачем нужно и как реализовать

Содержание:

Диаграмма ER против диаграммы классов

Диаграммы ER (сущность-взаимосвязь) и диаграммы классов — это две схемы проектирования, которые разработчики программного обеспечения создают обычно на этапах проектирования жизненного цикла разработки программного обеспечения. Диаграммы ER являются продуктом техники моделирования отношений сущностей (ERM) для моделирования баз данных. Диаграмма классов, написанная на унифицированном языке моделирования, представляет собой диаграмму, описывающую структуру предлагаемой системы. Хотя нет необходимости иметь точное соответствие между классами в диаграммах классов и сущностями в диаграммах сущностей, обычно между ними существует некоторая значимая связь. Однако существует множество случаев, когда объект диаграммы ER отображается в несколько классов соответствующей диаграммы классов или один класс диаграммы классов отображается в несколько объектов соответствующей диаграммы ER. Но это полностью зависит от дизайнерских решений разработчиков программного обеспечения.

Что такое диаграмма ER?

Диаграммы ER являются продуктом моделирования отношений сущностей. Моделирование отношений сущностей — это процесс создания абстрактного и концептуального представления данных. Диаграммы ER в конечном итоге моделируют базы данных. В частности, он создает концептуальную схему модели данных. Основными строительными блоками диаграмм ER являются сущности, отношения и атрибуты. Сущность представляет собой вещь, которая может существовать независимо и может быть определена однозначно. Чаще всего сущность представляет собой объект реального мира, такой как автомобиль или служащий. Сущности можно рассматривать как существительные, возникающие при описании решаемой проблемы. Взаимосвязь показывает, как сущности связаны. Они похожи на глаголы в описании решаемой проблемы. Свойства сущностей и атрибутов называются атрибутами.

Что такое диаграмма классов?

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

В чем разница между диаграммой ER и диаграммой классов?

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

Диаграмма вариантов использования

Диаграмма вариантов использования (англ. use-case diagram) – диаграмма, описывающая, какой функционал разрабатываемой программной системы доступен каждой группе пользователей.

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

В этой системе можно выделить следующие группы пользователей:

• Обучающиеся

• Преподаватели

• Классные руководители

• Заместители директора

Каждая из групп пользователей может пользоваться нашей системой по-своему.

Обучающиеся могут:

• Смотреть расписание

• Просматривать свои оценки

Преподаватели могут:

• Размещать материалы для уроков

• Выставлять оценки в электронный журнал

Классные руководители могут делать все то же самое, что и преподаватели плюс:

Составлять расписание родительских собраний

Заместители директора могут:

Составлять расписание
Публиковать посты с важной информацией

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

Отправлять сообщения

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

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

И снова про бизнес-процессы: живой опыт без теории

«Вы не любите кошек? Вы просто не умеете их готовить» (к/ф «Альф»)
Есть разные подходы к тому, как выделять и классифицировать бизнес-процессы, есть с десяток разных нотаций, в которых их можно описывать, есть целый ряд правил, по которым следует выявлять зоны неоптимальности и предлагать улучшения. По сути, мы с вами получаем в руки ящик с инструментами. А профессионализм аналитика заключается в выборе того, инструмента, который лучше всего подойдет для конкретной бизнес-задачи конкретного предприятия. В статье я хочу поделиться результатами осмысления собственных проектов и теми правилами, которые считаю важным и нужным учитывать при анализе и оптимизации бизнес-процессов.

Types of Data Models

There are three types of data models in ER modeling.

Conceptual and Logical Data Models 

The conceptual and logical data models describe how information is organized in a system regardless of the database used. The logical model specifies entities, attributes, and relationships between entities. It abstracts away from actual DBMS used in the implementation of the system.

Physical Data Model

The physical data model represents how the model will be built in the database. It shows the full table definition, including column names, column data types, table constraints, the primary key, the foreign keys, and the relationships between tables. The physical data model will be different for different RDBMS. For example, the data type for a given column may be different between MySQL and SQL Server.

This section appears incomplete. There is no explanation of what a conceptual model is (as opposed to logical). Also, the last sentence is incomplete.

Using ERD with Data Flow Diagram (DFD)

In system analysis and design, Data Flow Diagram (DFD) can be drawn to visualize the flow of information within system processes. In a Data Flow Diagram, there is a symbol called Data Store, which represents a database table that provides the information needed by the system.

Since a physical ER Diagram provides a blueprint of an actual database, the entities in such an ERD are aligned with datastores in a DFD. You can draw ERD as a complement to DFD by representing the structure of information that flows within a system, or, on the contrary, to draw DFD in complementing an ERD by showing how the data will be utilized by the system in runtime.

ER Diagrams Symbols & Notations

Entity Relationship Diagram Symbols & Notations mainly contains three basic symbols which are rectangle, oval and diamond to represent relationships between elements, entities and attributes. There are some sub-elements which are based on main elements in ERD Diagram. ER Diagram is a visual representation of data that describes how data is related to each other using different ERD Symbols and Notations.

Following are the main components and its symbols in ER Diagrams:

• Rectangles: This Entity Relationship Diagram symbol represents entity types
• Ellipses : Symbol represent attributes
• Diamonds: This symbol represents relationship types
• Lines: It links attributes to entity types and entity types with other relationship types
• Primary key: attributes are underlined
• Double Ellipses: Represent multi-valued attributes

Типы связей

Существует
три типа связей:

§ 
Один к одному

§ 
Многие к одному

§ 
Многие ко многим

Один к одному

Мощность “один и только один” в обоих направлениях.
Отображает такой характер отношений между объектами, когда каждому экземпляру
одной сущности соответствует только один экземпляр другой сущности и наоборот.
Это довольно редкий вид связи. Если при проектировании базы данных появляется
такой вид связи, рекомендуется рассмотреть вопрос, нельзя ли объединить эти две
сущности. Например, если в нашем примере добавить еще одну сущность “Паспортные
данные”, то связь между этой сущностью и сущностью “Сотрудник” будет “один к
одному”. В этом случае будет лучше добавить атрибут “паспортные данные” к
сущности “Сотрудник”.

Многие к одному

Мощность “один или более” в одном направлении и “один и
только один” в другом. Такая связь в реляционной модели встречается наиболее
часто. В нашем примере такая связь реализована между сущностями “Подпроект” и
“Проект”.

Многие ко многим

Мощность “один или более” в обоих направлениях. В нашем
примере такая связь реализована между сущностями “Сотрудник” и ”Проект”.
Реляционная модель не позволяет напрямую реализовать связь “многие ко многим”,
т.к. в этом случае не избежать ситуации, когда множественные значения вынуждены
храниться в одном столбце, а это противоречит принципу неделимости, согласно
которому каждая ячейка должна содержать одну порцию данных. Таким образом,
связь “многие ко многим” заменяется несколькими связями “многие к одному” и
представляется с помощью сущности пересечения (Рисунок 5).

Рисунок 5 Практическая
реализация связи «многие ко многим» в ER-диаграмме

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

Правила целостности и ключи

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

Сервер базы данных контролирует
целостность данных посредством ключей:

§ Первичные ключи

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

§ Уникальные ключи

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

§ Внешние ключи

Внешний ключ (FK)
– столбец или сочетание столбцов в одной таблице, которые содержат ссылку на
первичный или уникальный ключ в той же или другой таблице. Внешний ключ основан
на значениях данных и является логическим указателем. Значения внешнего ключа
должны совпадать со значениями соответствующих первичных или уникальных ключей
или быть NULL. Если внешний ключ является частью первичного
ключа, он должен быть определен.

После того, как построена ER-модель
базы данных, необходимо преобразовать ее в табличную модель и предусмотреть
дополнительные объекты, предназначенные для ускорения поиска информации (индексы)
и удобства вывода данных (представления). Кроме того, необходимо продумать, как
лучше хранить объекты базы данных: на каких носителях, какой объем памяти
выделить. Именно физическое проектирование обеспечивает производительность
системы.

Using ERD with BPMN Business Process Diagram (BPD)

In business process mapping, BPMN Business Process Diagram (BPD) can be drawn to visualize business workflows. In a Business Process Diagram, there is a symbol called Data Object, which represents the data input into / output from process activities.

Since a conceptual and logical data model provides a high-level view of business objects within a system, the entities in such ERDs are aligned with data objects in BPD. You can draw ERD as a complement to BPD by representing the structure of data objects needed by a business workflow, or, on the contrary, to draw BPD in complementing an ERD by showing how the data will be utilized throughout a business process.

Руководство по символам ERD

Диаграмма ER содержит сущности, атрибуты и отношения. В этом разделе мы подробно представим каждый символ ERD.

юридическое лицо

ERD-объект находится в системеОпределимая вещь или понятие, Такие как люди / роли (например, студенты), объекты (например, счета-фактуры), концепции (например, представления) или события (например, транзакции) (Примечание: в ERD термин «объект» обычно используется вместо «таблица», но они одинаковы из). При рассмотрении сущностей старайтесь думать о них как о существительных. В модели ER сущность отображается в виде прямоугольника с закругленными углами с названием вверху, а ее атрибуты перечислены в теле формы сущности. В приведенном ниже примере ERD показан вариант использования объекта ER.

Атрибуты сущности

Также известен как Row, что означаетАтрибуты или характеристики объекта, который его держит。

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

В следующем примере ER-диаграммы показан объект, содержащий атрибуты.

Основной ключ

Первичный ключ, также известный как PK, представляет собой специальный атрибут сущности, используемый дляОпределить уникальность записей в таблице базы данных. В таблице не может быть двух (или более) записей с одинаковым значением атрибута первичного ключа. Например, типичным примером является идентификатор в сертификате идентификации. Даже если у двух людей одинаковое имя пола, идентификатор не будет одинаковым. Если сертификат идентификации является Таблица, ID — это первичный ключ. В следующем примере ERD показана сущность «Продукт» с атрибутом первичного ключа «ID» и предварительный просмотр записей таблицы в базе данных. Третья запись недействительна, поскольку значение ID’PDT-0002 ‘уже используется другой записью.

Внешний ключ

Внешние ключи, также известные как внешние ключи и внешние ключи, являютсяСсылка на первичный ключ, Используется для определения взаимосвязи между сущностями

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

отношения

Представление отношений между двумя сущностямиЭти две сущности каким-то образом связаны друг с другом.. Например, студент может пройти курс. Таким образом, сущность «студент» связана с «курсом», и эта взаимосвязь выражается соединительными линиями на диаграмме ER.

Мощность

База определяетВо взаимоотношениях между юридическим лицом и другим юридическим лицом количество раз, когда сторона может появляться. Например, если в команде много игроков, если эта взаимосвязь представлена ​​в ERD, между командой и игроками существует взаимосвязь «один ко многим».

На диаграмме ER мощность представлена ​​гусиными лапками на конце соединительной линии. Три общих основных отношения — «один к одному», «один ко многим» и «многие ко многим».

Примеры однозначной мощности

Отношение «один-к-одному» в основном используется для разделения объекта на две части и краткого представления информации, чтобы читателям было легче ее понять. На следующем рисунке показан пример отношения «один к одному».

Пример мощности «один ко многим»

Отношение «один ко многим» относится к отношениям между двумя объектами X и Y, где один экземпляр X может быть связан со многими экземплярами Y, а один экземпляр Y связан только с одним экземпляром X. На следующем рисунке показан пример отношения «один ко многим».

Примеры мощности многие ко многим

Отношение «многие ко многим» относится к отношениям между двумя объектами X и Y, где X может быть связан со многими экземплярами Y, и наоборот. На рисунке ниже показан пример отношения «многие ко многим»

Обратите внимание, что в физическом ERD отношения «многие ко многим» делятся на отношения «один ко многим». В следующем разделе вы узнаете, что такое физическое ERD

Ограничения

• ER-модель в первую очередь концептуальна, это онтология, которая выражает предикаты в области знаний.
• ER-модели легко используются для представления структур реляционных баз данных (после Кодда и Даты), но не так часто для представления других типов структур данных (хранилища данных, хранилища документов и т. Д.)
• Некоторые обозначения моделей ER включают символы, показывающие суперподтипные отношения и взаимоисключение между отношениями; некоторые нет.
• Модель ER не показывает историю жизни объекта (как его атрибуты и / или отношения меняются с течением времени в ответ на события). Для многих систем такие изменения состояния нетривиальны и достаточно важны, чтобы требовать явной спецификации.
• Некоторые имеют расширенное моделирование ER с конструкциями для представления изменений состояния, подход, поддерживаемый первоначальным автором; примером является якорное моделирование .
• Другие модели изменяют состояние по отдельности, используя диаграммы переходов состояний или какой-либо другой метод моделирования процессов .
• Многие другие виды диаграмм используются для моделирования других аспектов систем, включая 14 типов диаграмм, предлагаемых UML .
• Сегодня даже там, где ER-моделирование может быть полезным, это редко, потому что многие используют инструменты, которые поддерживают похожие типы моделей, особенно диаграммы классов для объектно-ориентированного программирования и модели данных для систем управления реляционными базами данных . Некоторые из этих инструментов могут генерировать код из диаграмм и реконструировать диаграммы из кода.
• В ходе опроса Броди и Лю не смогли найти ни одного примера моделирования отношений сущность в выборке из десяти компаний из списка Fortune 100. Бадиа и Лемир винят в этом недостаток использования отсутствие руководства, а также отсутствие преимуществ, таких как отсутствие поддержки интеграции данных.
• Усиливается модель сущность-связь (РЧЭС моделирование) представляет несколько концепций не в моделировании ER, но тесно связаны с объектно-ориентированного дизайна, как это-а отношения.
• Для моделирования темпоральных баз данных были рассмотрены многочисленные расширения ER. Точно так же модель ER оказалась непригодной для многомерных баз данных (используемых в приложениях OLAP ); в этой области еще не появилось доминирующей концептуальной модели, хотя в основном они вращаются вокруг концепции куба OLAP (также известного как куб данных в этой области).

Why use ER Diagrams?

Here, are prime reasons for using the ER Diagram

• Helps you to define terms related to entity relationship modeling
• Provide a preview of how all your tables should connect, what fields are going to be on each table
• Helps to describe entities, attributes, relationships
• ER diagrams are translatable into relational tables which allows you to build databases quickly
• ER diagrams can be used by database designers as a blueprint for implementing data in specific software applications
• The database designer gains a better understanding of the information to be contained in the database with the help of ERP diagram
• ERD Diagram allows you to communicate with the logical structure of the database to users

Using ERD with Data Flow Diagram (DFD)

In system analysis and design, Data Flow Diagram (DFD) can be drawn to visualize the flow of information within system processes. In a Data Flow Diagram, there is a symbol called Data Store, which represents a database table that provides the information needed by the system.

Since a physical ER Diagram provides a blueprint of an actual database, the entities in such an ERD are aligned with datastores in a DFD. You can draw ERD as a complement to DFD by representing the structure of information that flows within a system, or, on the contrary, to draw DFD in complementing an ERD by showing how the data will be utilized by the system in runtime.

ClickCharts

ClickCharts is another ER diagram creator which is free for non-commercial purpose only. As you open a new project in it, you will see different diagram templates including Flowcharts, UML diagrams, Venn diagrams, Brainstorming diagrams, ER diagrams, etc. There are a few ER diagram templates which you can choose to create entity relationship diagram.

From the left side of the interface, you get key elements of an ER diagram which are Entity, Attribute, and Relationship. The other elements that you can add include weak entity, weak relationship, multivalued attributes, straight connector, orthogonal connector, and curve connector. You can add text in desired font, size, alignment, etc. Further, you edit properties of an element by customizing fill and line color/pattern. If you don’t want to make any further changes to a particular element of the ER diagram, simply right-click on it and click on Lock option. It provides page, grid, grid snap, and object snap views to draw ER diagram.

The good part of this software is that the created ER diagram can be exported in a wide range of formats such as PDF, GIF, JPEG, BMP, PCX, PNG, SVG, RAS, TIFF, WMF, etc.

ClickCharts is a nice free software to draw ER diagram. It has a user-friendly GUI.

Объектные модели данных

При создании объектных моделей данных используются такие понятия, как сущности, атрибуты и связи. Сущность — это отдельный элемент деятельности организации (сотрудник или клиент, место или вещь, понятие или событие), ко­торый должен быть представлен в базе данных. Атрибут — это свойство, которое описывает некоторый аспект объекта и значение которого следует зафикси­ровать, а связь является ассоциативным отношением между сущностями. Ниже перечислены некоторые наиболее общие типы объектных моделей данных.

• Модель типа «сущность-связь”, или -модель (Entity-Relationship model).
• Семантическая модель.
• Функциональная модель.
• Объектно-ориентированная модель.

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

Why use ER Diagrams?

Here, are prime reasons for using the ER Diagram

• Helps you to define terms related to entity relationship modeling
• Provide a preview of how all your tables should connect, what fields are going to be on each table
• Helps to describe entities, attributes, relationships
• ER diagrams are translatable into relational tables which allows you to build databases quickly
• ER diagrams can be used by database designers as a blueprint for implementing data in specific software applications
• The database designer gains a better understanding of the information to be contained in the database with the help of ERP diagram
• ERD Diagram allows you to communicate with the logical structure of the database to users

Attributes

It is a single-valued property of either an entity-type or a relationship-type.

For example, a lecture might have attributes: time, date, duration, place, etc.

An attribute in ER Diagram examples, is represented by an Ellipse

Когда рисовать диаграмму ER?

Итак, когда мы должны рисовать диаграмму ER? Хотя ER-модели в основном используются для демонстрации концепций и проектирования физических баз данных, они могут использоваться и для других целей. Ниже приведены некоторые типичные варианты использования.

• Дизайн базы данных -Изменение структуры базы данных непосредственно в базе данных рискованно.Чтобы не повредить данные в базе данных, мы должны тщательно планировать все изменения. Рисуя ER-диаграммы для демонстрации идей дизайна базы данных, вы можете легко находить ошибки и выявлять недостатки дизайна, а также вносить исправления перед внесением изменений в базу данных.
• Отладка базы данных -Отладка проблем с базой данных часто является сложной задачей, особенно когда база данных содержит много таблиц, мы с вами пишем сложный SQL для получения необходимой информации. С помощью ERD для отображения структуры базы данных вы можете полностью понять структуру всей базы данных. Вы можете легко найти объекты, просмотреть их свойства и определить отношения с другими объектами, что поможет вам легче находить проблемы с базой данных.
• Создание и исправление базы данных Программное обеспечение -ERD, такое как Visual Paradigm, поддерживает инструменты создания баз данных, которые могут автоматически создавать и восстанавливать базы данных с помощью диаграмм ER. Используя этот инструмент для создания диаграмм ER, ваш дизайн ER больше не является статической диаграммой, а является зеркальным отображением, которое действительно отражает физическую структуру базы данных.
• Помогите собрать требования -Вы можете выразить бизнес-объекты высокого уровня в системе, нарисовав ERD для определения требований системы. Эта первоначальная модель также может развиться в физическую модель базы данных, используемую для создания реляционной базы данных или для предоставления мощного справочного материала для создания блок-схем и моделей потоков данных.