Er diagram: entity relationship diagram model

Типы связей

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

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

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

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

Один к одному

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Types of Attributes	Description
Simple attribute	Simple attributes can’t be divided any further. For example, a student’s contact number. It is also called an atomic value.
Composite attribute	It is possible to break down composite attribute. For example, a student’s full name may be further divided into first name, second name, and last name.
Derived attribute	This type of attribute does not include in the physical database. However, their values are derived from other attributes present in the database. For example, age should not be stored directly. Instead, it should be derived from the DOB of that employee.
Multivalued attribute	Multivalued attributes can have more than one values. For example, a student can have more than one mobile number, email address, etc.

What is an Entity Relationship Diagram (ERD)?

An entity relationship diagram (ERD) shows the relationships of entity sets stored in a database. An entity in this context is an object, a component of data.
An entity set is a collection of similar entities. These entities can have attributes that define its properties.

By defining the entities, their attributes, and showing the relationships between them, an ER diagram illustrates the logical structure of databases.

ER diagrams are used to sketch out the design of a database.

Two ways to get started

Use the online edition of SmartDraw on any computer or tablet
Start Now

Download the Windows desktop edition of SmartDraw
Download

Сценарий 2. Разобраться с устройством механизма или подсистемы

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

В этом случае, как и в первом сценарии, вы можете открыть редактор этой подсистемы и перейти на закладку Схема данных. Здесь вы увидите более интересную картину, потому что кроме объектов на этой схеме будут показаны и подчинённые подсистемы.

Подсистемы являются группами объектов. Содержащиеся в них объекты имеют связи с объектами, которые находятся «снаружи». Чтобы посмотреть, как устроена любая из этих подсистем, например подсистема Характеристики, вы можете кликнуть на ней прямо в схеме, и увидите её устройство.

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

Классические методологии

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

К классическим стандартам описания бизнес процесса относятся следующие:

DFD (Data Flow Diagram) — стандарт описания процессов верхнего уровня и потоков данных, которые преобразуются функциями данного процесса.

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

WFD (Workflow Diagram) — стандарт описания потоков работ. Используется для детализации функций бизнес процесса.

Нотация WFD  имеет дополнительные элементы для описания бизнес процесса:

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

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

ERD (Entity Relaishionship Diagram) — стандарт описания информационной модели.

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

Основные нотации: ERD (Нотация Чена), UML (Class Diargamm), IDEF1x.

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.

Сценарий 1. Какие объекты конфигурации использует данный объект

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

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

Теперь эта задача решается значительно проще. Вы открываете редактор объекта конфигурации и переходите на закладку Схема данных. Такая закладка есть у всех прикладных объектов конфигурации.

EDT сразу же показывает вам ER-диаграмму. В неё включаются все объекты первого уровня, которые использует регистр Продажи.

На этой схеме данных видно, что регистр Продажи использует документ РасходТовара и справочники Товары и Контрагенты. Эти связи исходят из регистра. Кроме этого на схеме показаны и взаимные связи между самими используемыми объектами (между документом и справочниками).

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

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

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

Закрытой стрелкой обозначается связь с владельцем, а ромбом – с регистратором. Это помогает визуально отличать «техногенные» связи от прикладных.

Такую схему данных, которая открывается на закладке редактора объекта конфигурации, вы можете изменять и модифицировать: раскрывать группы реквизитов, перетаскивать объекты, располагая их более удобным образом, и т.д.

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

Поэтому здесь, в этом месте, не нужно увлекаться наведением «красоты», для этого есть другой сценарий, который мы тоже рассмотрим далее.

Documenting an Existing Database Using Data

There are two reasons to create a database diagram. You’re either designing a new schema or you need to document your existing structure.

If you have an existing database you need to to document, you create a database diagram using data directly from your database. You can export your database structure as a CSV file (there are some scripts on how to this here), then have a program generate the ERD automatically.

This will be the most accurate potrait of your database and will require no drawing on your part.

Here’s an example of a very basic database structure generated from data.

If you want to create a new plan, you can also edit the generated diagram and collaborate with your team on what changes to make.

10.3.2. Вторая нормальная форма er-диаграммы

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

На рис.
10.10(a) показана диаграмма, на
которой тип сущностиЭЛЕМЕНТ
РАСПИСАНИЯне удовлетворяет
требованиям второй нормальной формы.
На этой диаграмме у сущностиЭЛЕМЕНТ
РАСПИСАНИЯимеются следующие
свойства. Элементы расписания предназначены
для сохранения данных о рейсах самолетов,
вылетающих в течение дня. Некоторыми
важными характеристиками рейса являются
номер рейса, аэропорт вылета, аэропорт
назначения, дата и время вылета, бортовой
номер самолета, тип самолета. Если
говорить про российские авиационные
компании, то (1) у каждого рейса имеется
заранее приписанный ему номер (уникальный
среди всех других имеющихся номеров
рейсов), (2) не все рейсы совершаются
каждый день, поэтому характеристикой
конкретного рейса является дата и время
его совершения, (3) бортовой номер самолета
определяется парой<номер
рейса, дата-время вылета>.
Имеется связь «многие к одному» между
сущностямиЭЛЕМЕНТ
РАСПИСАНИЯиГОРОД.
Экземпляры типа сущностиГОРОДхарактеризуют город, в который прибывает
данный рейс.

Рис.
10.10.Пример приведения ER-диаграммы ко
второй нормальной форме

Уникальным идентификатором типа сущности
ЭЛЕМЕНТ
РАСПИСАНИЯявляется пара
атрибутов<номер
рейса, дата-время вылета>. Если
вернуться к терминам функциональных
зависимостей, то между атрибутами этой
сущности имеются следующие FD:

• {номер
  рейса, дата-время вылета}бортовой
  номер самолета;

• номер
  рейса
  аэропорт
  вылета;

• номер
  рейса
  аэропорт
  назначения;

• бортовой
  номер самолета
  тип
  самолета.

Кроме того, очевидно, что каждый экземпляр
связи с сущностью ГОРОДтакже определяется значением атрибутаномер
рейса. Налицо нарушение требования
второй нормальной формы. Мы получаем
не только избыточное хранение значений
атрибутоваэропорт
вылетаиаэропорт
назначенияв каждом экземпляре
типа сущностиЭЛЕМЕНТ
РАСПИСАНИЯс одним и тем же
значением номера рейса. Искажается и
затемняется смысл связи с сущностьюГОРОД.
Можно подумать, что в разные дни один и
тот же рейс прибывает в разные города.

На рис.
10.10(b) показан нормализованный
вариант диаграммы, в котором все сущности
находятся во второй нормальной форме.
Теперь имеются три типа сущности:РЕЙСс атрибутаминомер
рейса,аэропорт
вылета,аэропорт
назначения,ЭЛЕМЕНТ
РАСПИСАНИЯс атрибутамидата-время
вылета,бортовой
номер самолета,тип
самолетаиГОРОД.
Уникальным идентификатором сущностиРЕЙСявляется атрибутномер
рейса, уникальный идентификаторЭЛЕМЕНТ
РАСПИСАНИЯсостоит из атрибутадата
вылетаи конца связиКОГДА,НА
ЧЕМ. Мы видим, что ни в одном типе
сущности больше нет атрибутов, определяемых
частью уникального идентификатора.
Свойства второй нормальной формы
удовлетворяются, и мы имеем более
качественную диаграмму.

What is an ER diagram (ERD)?

First of all, what is an Entity Relationship Diagram?

Entity Relationship Diagram, also known as ERD, ER Diagram or ER model, is a type of structural diagram for use in database design. An ERD contains different symbols and connectors that visualize two important information: The major entities within the system scope, and the inter-relationships among these entities.

And that’s why it’s called «Entity» «Relationship» diagram (ERD)!

When we talk about entities in ERD, very often we are referring to business objects such as people/roles (e.g. Student), tangible business objects (e.g. Product), intangible business objects (e.g. Log), etc. «Relationship» is about how these entities relate to each other within the system.

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.

Summary

• ER Model in DBMS stands for an Entity-Relationship model
• The ER model is a high-level data model diagram
• ER diagrams are a visual tool which is helpful to represent the ER model
• ER diagrams in DBMS are blueprint of a database
• Entity relationship diagram DBMS displays the relationships of entity set stored in a database
• ER diagrams help you to define terms related to entity relationship modeling
• ER Model in DBMS is based on three basic concepts: Entities, Attributes & Relationships
• An entity can be place, person, object, event or a concept, which stores data in the database (DBMS)
• Relationship is nothing but an association among two or more entities
• A weak entity is a type of entity which doesn’t have its key attribute
• It is a single-valued property of either an entity-type or a relationship-type
• It helps you to defines the numerical attributes of the relationship between two entities or entity sets
• ER- Diagram DBMS is a visual representation of data that describe how data is related to each other
• While Drawing ER diagrams in DBMS, you need to make sure all your entities and relationships are properly labeled.

Entity Relationship Diagram Tutorial

Here are some best practice tips for constructing an ERD:

• Identify the entities. The first step in making an ERD is to identify all of the entities you will use. An entity is nothing more than a rectangle with a description of something that your system stores information about. This could be a customer, a manager, an invoice, a schedule, etc. Draw a rectangle for each entity you can think of on your page. Keep them spaced out a bit.
• Identify relationships. Look at two entities, are they related? If so draw a solid line connecting the two entities.
• Describe the relationship. How are the entities related? Draw an action diamond between the two entities on the line you just added. In the diamond write a brief description of how they are related.
• Add attributes. Any key attributes of entities should be added using oval-shaped symbols.
• Complete the diagram. Continue to connect the entities with lines, and adding diamonds to describe each relationship until all relationships have been described. Each of your entities may not have any relationships, some may have multiple relationships. That is okay.

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:

ERD features	Conceptual	Logical	Physical
Entity (Name)	Yes	Yes	Yes
Relationship	Yes	Yes	Yes
Columns		Yes	Yes
Column’s Types		Optional	Yes
Primary Key			Yes
Foreign Key			Yes

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.

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

Путеводитель по нотациям и методологиям

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

Методологии \Типы	Модель управления / модель потоков данных	Модель потоков работ (детализация бизнес процесса)	Информационная модель
Классические методологии	DFD	WFD	ERD
Семейство IDEF	IDEF0	IDEF3	IDEF1x
ARIS	VADC (Value Added Chain), FAD (Function Allocation Diagramm)	eEPC, BPMN, UML Activity Diagramm	ERD (Entity Relationship Diagramm), UML Class Diagramm
UML	Use Case Diagramm	UML Activity Diagramm	UML Class Diagramm

Common Entity Relationship Diagram Symbols

An ER diagram is a means of visualizing how the information a system produces is related. There are five main components of an ERD:

• Entities, which are represented by rectangles. An entity is an object or concept about which you want to store information.

  A weak entity is an entity that must defined by a foreign key relationship with another entity as it cannot be uniquely identified by its own attributes alone.

• Actions, which are represented by diamond shapes, show how two entities share information in the database.

  In some cases, entities can be self-linked. For example, employees can supervise other employees.

• Attributes, which are represented by ovals. A key attribute is the unique, distinguishing characteristic of the entity. For example, an employee’s social security number might be the employee’s key attribute.
  A multivalued attribute can have more than one value. For example, an employee entity can have multiple skill values.

  A derived attribute is based on another attribute. For example, an employee’s monthly salary is based on the employee’s annual salary.

• Connecting lines, solid lines that connect attributes to show the relationships of entities in the diagram.
• Cardinality specifies how many instances of an entity relate to one instance of another entity. Ordinality is also closely linked to cardinality. While cardinality specifies the occurrences of a relationship, ordinality describes the relationship as either mandatory or optional. In other words, cardinality specifies the maximum number of relationships and ordinality specifies the absolute minimum number of relationships.
  There are many notation styles that express cardinality.Information Engineering StyleChen StyleBachman StyleMartin Style

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

Strong Entity Set	Weak Entity Set
Strong entity set always has a primary key.	It does not have enough attributes to build a primary key.
It is represented by a rectangle symbol.	It is represented by a double rectangle symbol.
It contains a Primary key represented by the underline symbol.	It contains a Partial Key which is represented by a dashed underline symbol.
The member of a strong entity set is called as dominant entity set.	The member of a weak entity set called as a subordinate entity set.
Primary Key is one of its attributes which helps to identify its member.	In a weak entity set, it is a combination of primary key and partial key of the strong entity set.
In the ER diagram the relationship between two strong entity set shown by using a diamond symbol.	The relationship between one strong and a weak entity set shown by using the double diamond symbol.
The connecting line of the strong entity set with the relationship is single.	The line connecting the weak entity set for identifying relationship is double.

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-диаграмму-советы

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

• Определите все объекты в данной системе и определите отношения между этими объектами;
• Объект должен появиться только один раз в определенном месте схемы;
• Определите точное и подходящее имя для каждого объекта, атрибута и отношений в диаграмме. Выберите  простые и понятные слова. Условия, которые просты и знакомы всегда побеждает смутные, технические звучащие слова. Для объектов имена существительные, для связей глаголы (можно с пояснениями). Не забываем про уникальность имен объектов;
• Удалите неявные, избыточные или ненужные отношения между объектами;
• Никогда не подключайте отношения к другим отношениям;
• Используйте цвета, чтобы классифицировать однотипные объекты или выделить ключевые области в диаграмме.

WebOnTo.ru