Лучшие программные решения для создания er-диаграмм [руководство по 2020]

Введение

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

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

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

ER-диграмма строится из элементов представленных в ER-модели, а именно: сущности, атрибуты, связи.

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

Атрибуты — соответственно представляют собой некоторые отличительные черты или характеристики какой либо сущности.

Связи — это ассоциация, между двумя сущностями.

Из выше сказанного понятно что — ER-модель лишь концептуальная модель, которая может иметь или не иметь графического представления, соответственно ER-диаграмма является этим самым графическим представлением(нотацией), коих существует некоторое множество, а именно это нотации: Чена, Мартина, IDEF1X, которые мы рассмотрим далее.

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

Нотация Мартина(Crow`s Foot)

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

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

Основу всей модели базы данных в нотации Мартина составляют элементы «Сущность». Название сущности представляет собой существительное или словосочетания, обозначающие особенности данных, которые представляются описываемой сущностью. Сущность состоит из атрибутов, ключевые из которых подчёркиваются.

Связи изображаются линиями, соединяющими сущности, вид линии в месте соединения с сущностью определяет множественность связи. Имеется 4 вида множественности и смысла связи: 1:1, 1:ЛГ, ЛГ:Л/, связь с указанной мощностью.

Устанавливая связи между сущностями, в нотации Мартина её смысловое наполнение можно обозначать единственной глагольной формой, имеющей смысл связи от «левой» сущности к «правой» сущности, представляя в качестве «левой» сущности ту, у которой множественность связи в верхней её границе равна «1». В случае установления связи многие — ко — многим (№М) «левой» сущностью является та, которая по логике модели является более значимой. Тем не менее, поскольку не всегда можно однозначно разделить сущности на «левую» и «правую», разработчиками указывается смысловое наполнение связи двумя глагольными формами, аналогично тому, как это делалось при рассмотрении модели в нотации Чена. При описании связей, в отличие от нотации Чена, множественность устанавливается не в виде текстовых обозначений, а соответствующими графическими представлениями на связи(пример дан в приложении 2).

Weak Entities

A weak entity is a type of entity which doesn’t have its key attribute. It can be identified uniquely by considering the primary key of another entity. For that, weak entity sets need to have participation.

In above ER Diagram examples, “Trans No” is a discriminator within a group of transactions in an ATM.

Let’s learn more about a weak entity by comparing it with a Strong Entity

IDEF1X

IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы.  Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу «AS IS», тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято.

Сущности в IDEF1X и их атрибуты.

Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друх от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира. Примером сущности IDEF1X может быть сущность «СОТРУДНИК», которая представляет собой всех сотрудников предприятия, а один из них, скажем, Иванов Петр Сергеевич, является конкретной реализацией этой сущности.

Связи между сущностями

Связи в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Связи это суть глаголы, которые показывают, как соотносятся сущности между собой. Ниже приведен ряд примеров связи между сущностями:

Отдел <состоит из> нескольких Сотрудников

Самолет <перевозит> нескольких Пассажиров.

Сотрудник <пишет> разные Отчеты.

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

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

При создании сущности в IDEF1X модели, одним из главных вопросов, на который нужно ответить, является: «Как можно идентифицировать уникальную запись?». Для этого требуется уникальная идентификация каждой записи в сущности для того, чтобы правильно создать логическую модель данных. Напомним, что сущности в IDEF1X всегда имеют ключевую область и, поэтому в каждой сущности должны быть определены ключевые атрибуты.

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

Рисунок

What is ER Diagram?

ER Diagram stands for Entity Relationship Diagram, also known as ERD is a diagram that displays the relationship of entity sets stored in a database. In other words, ER diagrams help to explain the logical structure of databases. ER diagrams are created based on three basic concepts: entities, attributes and relationships.

ER Diagrams contain different symbols that use rectangles to represent entities, ovals to define attributes and diamond shapes to represent relationships.

At first look, an ER diagram looks very similar to the flowchart. However, ER Diagram includes many specialized symbols, and its meanings make this model unique. The purpose of ER Diagram is to represent the entity framework infrastructure.

WHAT IS ENTITY?

A real-world thing either living or non-living that is easily recognizable and nonrecognizable. It is anything in the enterprise that is to be represented in our database. It may be a physical thing or simply a fact about the enterprise or an event that happens in the real world.

An entity can be place, person, object, event or a concept, which stores data in the database. The characteristics of entities are must have an attribute, and a unique key. Every entity is made up of some ‘attributes’ which represent that entity.

Examples of entities:

• Person: Employee, Student, Patient
• Place: Store, Building
• Object: Machine, product, and Car
• Event: Sale, Registration, Renewal
• Concept: Account, Course

Notation of an Entity

Entity set:

Student

An entity set is a group of similar kind of entities. It may contain entities with attribute sharing similar values. Entities are represented by their properties, which also called attributes. All attributes have their separate values. For example, a student entity may have a name, age, class, as attributes.

Example of Entities:

A university may have some departments. All these departments employ various lecturers and offer several programs.

Some courses make up each program. Students register in a particular program and enroll in various courses. A lecturer from the specific department takes each course, and each lecturer teaches a various group of students.

Категоризация сущностей

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

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

Рисунок

Рисунок

ERD notations guide

An ER Diagram contains entities, attributes, and relationships. In this section, we will go through the ERD symbols in detail.

Entity

An ERD entity is a definable thing or concept within a system, such as a person/role (e.g. Student), object (e.g. Invoice), concept (e.g. Profile) or event (e.g. Transaction) (note: In ERD, the term «entity» is often used instead of «table», but they are the same). When determining entities, think of them as nouns. In ER models, an entity is shown as a rounded rectangle, with its name on top and its attributes listed in the body of the entity shape. The ERD example below shows an example of an ER entity.

Entity Attributes

Also known as a column, an attribute is a property or characteristic of the entity that holds it.

An attribute has a name that describes the property and a type that describes the kind of attribute it is, such as varchar for a string, and int for integer. When an ERD is drawn for physical database development, it is important to ensure the use of types that are supported by the target RDBMS.

The ER diagram example below shows an entity with some attributes in it.

Primary Key

Also known as PK, a primary key is a special kind of entity attribute that uniquely defines a record in a database table. In other words, there must not be two (or more) records that share the same value for the primary key attribute. The ERD example below shows an entity ‘Product’ with a primary key attribute ‘ID’, and a preview of table records in the database. The third record is invalid because the value of ID ‘PDT-0002’ is already used by another record.

Foreign Key

Also known as FK, a foreign key is a reference to a primary key in a table. It is used to identify the relationships between entities. Note that foreign keys need not be unique. Multiple records can share the same values. The ER Diagram example below shows an entity with some columns, among which a foreign key is used in referencing another entity.

Relationship

A relationship between two entities signifies that the two entities are associated with each other somehow. For example, a student might enroll in a course. The entity Student is therefore related to Course, and a relationship is presented as a connector connecting between them.

Cardinality

Cardinality defines the possible number of occurrences in one entity which is associated with the number of occurrences in another. For example, ONE team has MANY players. When present in an ERD, the entity Team and Player are inter-connected with a one-to-many relationship.

In an ER diagram, cardinality is represented as a crow’s foot at the connector’s ends. The three common cardinal relationships are one-to-one, one-to-many, and many-to-many.

One-to-One cardinality example

A one-to-one relationship is mostly used to split an entity in two to provide information concisely and make it more understandable. The figure below shows an example of a one-to-one relationship.

One-to-Many cardinality example

A one-to-many relationship refers to the relationship between two entities X and Y in which an instance of X may be linked to many instances of Y, but an instance of Y is linked to only one instance of X. The figure below shows an example of a one-to-many relationship.

Many-to-Many cardinality example

A many-to-many relationship refers to the relationship between two entities X and Y in which X may be linked to many instances of Y and vice versa. The figure below shows an example of a many-to-many relationship. Note that a many-to-many relationship is split into a pair of one-to-many relationships in a physical ERD. You will know what a physical ERD is in the next section.

Сценарий 4. Разработка

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

Прямо сейчас мы реализовали только одну функцию – это переход из схемы данных в редактор объекта конфигурации.

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

Как мы говорили в начале, схема данных это не только новый, но и в некоторой степени экспериментальный инструмент. Мы, конечно, имеем собственные планы по его дальнейшему развитию, но вместе с этим нас интересуют и ваши мысли по этому поводу. Также нам было бы интересно узнать ваше мнение в том случае, если раньше вам уже приходилось (применительно к 1С:Предприятию) решать подобные задачи сторонними средствами.

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

Нотация Чена

СУЩНОСТЬ представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ДОМОДЕДОВО).

ОТНОШЕНИЕ в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (ИМЕЕТ, ОПРЕДЕЛЯЕТ, МОЖЕТ ВЛАДЕТЬ и т.п.).

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

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

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

Ассоциированная сущность представляет данные, которые ассоциируются с отношениями между двумя и более сущностями.

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

Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются СВЯЗИ. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности.

Conceptual, Logical and Physical data models

An ER model is typically drawn at up to three levels of abstraction:

While all the three levels of an ER model contain entities with attributes and relationships, they differ in the purposes they are created for and the audiences they are meant to target.

A general understanding to the three data models is that business analyst uses a conceptual and logical model to model the business objects exist in the system, while database designer or database engineer elaborates the conceptual and logical ER model to produce the physical model that presents the physical database structure ready for database creation. The table below shows the difference between the three data models.

Conceptual model vs Logical model vs Data model:

Conceptual data model

Conceptual ERD models the business objects that should exist in a system and the relationships between them. A conceptual model is developed to present an overall picture of the system by recognizing the business objects involved. It defines what entities exist, NOT which tables. For example, ‘many to many’ tables may exist in a logical or physical data model but they are just shown as a relationship with no cardinality under the conceptual data model.

Conceptual data model example

NOTE: Conceptual ERD supports the use of generalization in modeling the ‘a kind of’ relationship between two entities, for instance, Triangle, is a kind of Shape. The usage is like generalization in UML. Notice that only conceptual ERD supports generalization.

Logical data model

Logical ERD is a detailed version of a Conceptual ERD. A logical ER model is developed to enrich a conceptual model by defining explicitly the columns in each entity and introducing operational and transactional entities. Although a logical data model is still independent of the actual database system in which the database will be created, you can still take that into consideration if it affects the design.

Logical data model example

Physical data model

Physical ERD represents the actual design blueprint of a relational database. A physical data model elaborates on the logical data model by assigning each column with type, length, nullable, etc. Since a physical ERD represents how data should be structured and related in a specific DBMS it is important to consider the convention and restriction of the actual database system in which the database will be created. Make sure the column types are supported by the DBMS and reserved words are not used in naming entities and columns.

Основные понятия ER-моделирования.

ER-моделирование– графический подход к проектированию баз данных. 

Нотации ER-моделирования – языки представления диаграмм.

Основными понятиями ER-модели являются сущность, связь и атрибут.

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

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

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

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

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

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

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

• Один к одному
• Один ко многим
• Много ко многим