Создание er-диаграмм

Содержание:

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

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

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

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

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

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

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

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

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

What Features Should an Online ERD Tool Have?

First, we will consider the features that you should expect from an online ER diagram app. (During these days of remote teams and social distancing, we’re going to focus on online ERD solutions). When evaluating a new ERD tool, ask yourself:

• How will this work through the entire database design process?
• Does it support different DBMSs and ?
• How does it manage changes?
• How does it enable collaborative development work with my team?
• Does it allow me to export my work to different formats?
• Can I import existing work from different formats?

Let’s compare the features of a few top-rated ER diagram online tools and see how they support database design.

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.

Dia

Dia is a free and open source ER diagram creator for Windows. To start with, first, you need to select ER from the drop-down menu at left. You will then see symbols to draw ER diagram including entity, attribute, relationship, and connector. You can insert these elements into the main editor window and create a desired ER diagram. By double-clicking a symbol, you can edit related properties, which are:

• For an entity, you can specify whether it is a weak entity or associative entity.
• For an attribute, you get to define it as key, weak, derived, or multivalued attribute.
• As for a relationship, you get to add left and right cardinality, specify whether its identifying relationship, etc.

You can further customize font, fill color, line color, etc. You can add layers, sent/bring an object to back/front, copy the diagram, change input method, etc.

The created ER diagram can be exported in a variety of formats, such as EMF, PNG, PDF, SVG, TIFF, JPEG, ICO, CUR, etc.

Dia can be used to draw a good number of diagrams including Flowchart, databases, GRAFCET, Network diagram, UML, Circuit diagram, etc.

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.

Как нарисовать ER-диаграмму-советы

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

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

WebOnTo.ru

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.

Результат эксперимента

Первый тест – как меняется время, затрачиваемое на заполнение списка друзей. Результат – на графике ниже.
Варианты 3-5 ожидаемо показывают практически константное время «бизнес-операции», которое не зависит от роста размера сети и неотличимую разницу в производительности.
Вариант 2 показывает тоже константную, но чуть худшую производительность, причем практически ровно в 2 раза относительно вариантов 3-5. И это не может не радовать, так как соотноситься с теорией – в этом варианте количество операций ввода-вывода в/из HBase как раз в 2 раза больше. Это может служить косвенным свидетельством, что наш тестовый стенд в принципе дает неплохую точность.
Вариант 1 так же ожидаемо оказывается самым медленным и демонстрирует линейный от размера сети рост времени, затрачиваемого на добавление одно друга.
Посмотрим теперь результаты второго теста.
Варианты 3-5 опять же ведет себя ожидаемо – константное время, не зависящее от размера сети. Варианты 1 и 2 демонстрируют линейный рост времени при росте размера сети и схожую производительность. Причем вариант 2 оказывается чуть медленнее – по всей видимости из-за необходимости вычитки и обработки дополнительной колонки «count», что при росте n становится более заметным. Но я все же воздержусь от каких-либо выводов, так как точность данного сравнения относительно невысока. Кроме того, данные соотношения (какой вариант, 1 или 2, быстрее) менялись от запуска к запуску (при этом сохраняя характер зависимости и «идя ноздря в ноздрю»).

Ну и последний график – результат тестирования удаления.

Здесь опять же без сюрпризов. Варианты 3-5 осуществляют удаление за константное время.
Причем, что интересно, варианты 4 и 5, в отличии от предыдущих сценариев, показывают заметную чуть худшую производительность, чем вариант 3. По всей видимости, операция удаления строки – более затратная, нежели операция удаления колонки, что в целом логично.

Варианты 1 и 2, ожидаемо, демонстрируют линейный рост времени. При этом вариант 2 стабильно медленнее варианта 1 – из-за дополнительной операции ввода-вывода по «обслуживанию» колонки count.

Общие выводы эксперимента:

• Варианты 3-5 демонстрируют бОльшую эффективность, так как они использует преимущества HBase; при этом их производительность отличается друг относительно друга на константу и не зависит от размера сети.
• Разница между вариантами 4 и 5 не была зафиксирована. Но это не значит, что вариант 5 не следует использовать. Вполне вероятно, что используемый сценарий эксперимента с учетом ТТХ тестового стенда не позволил ее выявить.
• Характер роста времени, необходимого на выполнение «бизнес-операций» с данными, в целом подтвердил полученные ранее теоретические выкладки для всех вариантов.

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.

Типы связей

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

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

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

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

Один к одному

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модели данных на основе записей

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

Реляционная модель данных

Реляционная модель данных основана на понятии математических отноше­ний. В реляционной модели данные и связи представлены в виде таблиц, каждая из которых имеет несколько столбцов с уникальными именами. В табл. 1 и 2 показан пример реляционной схемы некоторой части проекта , содер­жащей сведения об отделениях компании и персонале организации. Например, из табл. 2 видно, что сотрудник John Whi te работает менеджером с годовой зар­платой 30000 фунтов стерлингов в отделении компании с номером () ВО05, который, согласно данным из табл. 1, расположен по адресу 22 Deer Rd, London

Здесь важно отметить, что между отношениями и сущест­вует следующая связь: сотрудник работает в отделении компании. Однако между этими двумя отношениями нет явно заданной связи; ее существование можно за­метить, только зная, что атрибут в отношении эквивалентен ат­рибуту в отношении

Таблица 1. Пример описания сущности в реляционной схеме

branchNo	street	city	postcode
8005	22 Deer Rd	London	SW14EH
8007	16 Argyll St	Aberdeen	А82 3SU
8003	163 Main St	Glasgow	G119QX
8004	32 Manse Rd	8ristol	8S99 1NZ
8002	56 Clover Dr	London	NW10 6EU

Таблица 2. Пример описания сущности в реляционной схеме

staffNo	fName	IName	position	sex	DOB	salary	branchNo
SL21	John	White	Manager	м	1-0ct-45	30000	8005
SG37	Ann	8eech	Assistant	F	10-Nov-60	12000	8003
SG14	David	Ford	Supervisor	м	24-Mar-58	18000	8003
SA9	Магу	Howe	Assistant	F	19-Feb-70	9000	8007
SG5	Susan	8rand	Manager	F	3-Jun-40	24000	8003
SL41	Julie	Lee	Assistant	F	13-Jun-65	9000	8005

How to Create an Entity Relationship Diagram (ERD)

Now in this ERD Diagram Tutorial, we will learn how to create an ER Diagram. Following are the steps to create an ER Diagram:

Steps to Create an ER Diagram

Let’s study them with an Entity Relationship Diagram Example:

In a university, a Student enrolls in Courses. A student must be assigned to at least one or more Courses. Each course is taught by a single Professor. To maintain instruction quality, a Professor can deliver only one course

Step 1) Entity Identification

We have three entities

• Student
• Course
• Professor

Step 2) Relationship Identification

We have the following two relationships

• The student is assigned a course
• Professor delivers a course

Step 3) Cardinality Identification

For them problem statement we know that,

• A student can be assigned multiple courses
• A Professor can deliver only one course

Step 4) Identify Attributes

You need to study the files, forms, reports, data currently maintained by the organization to identify attributes. You can also conduct interviews with various stakeholders to identify entities. Initially, it’s important to identify the attributes without mapping them to a particular entity.

Once, you have a list of Attributes, you need to map them to the identified entities. Ensure an attribute is to be paired with exactly one entity. If you think an attribute should belong to more than one entity, use a modifier to make it unique.

Once the mapping is done, identify the primary Keys. If a unique key is not readily available, create one.

Entity	Primary Key	Attribute
Student	Student_ID	StudentName
Professor	Employee_ID	ProfessorName
Course	Course_ID	CourseName

For Course Entity, attributes could be Duration, Credits, Assignments, etc. For the sake of ease we have considered just one attribute.

Step 5) Create the ERD Diagram

ER-моделирование

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

Основные преимущества ER-моделей:

• Точный и понятный формат документирования структуры информации.
• Позволяет указать требования к данным и связям между ними.
• Позволяет наглядно показать структуру хранилища для облегчения проектирования базы данных.
• Существуют методы отображения ER-моделей в таблицы БД и обратно.
• Закладывают основу для интеграции с другими приложениями.

Основные типы объектов на ER-диаграмме:

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.

Пример

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

Таблица 6.1. Атрибуты сущности «Студент»

Атрибут	Описание
Номер	Уникальный номер для идентификации пользователя
Ф.И.О.	Фамилия, имя и отчество пользователя
Пароль	Пароль для доступа в систему
Возраст	Возраст студента
Пол	Пол студента
Характеристика	Memo-поле с общей характеристикой пользователя
E-mail	Адреса электронной почты
Телефон	Номера телефонов студента (домашний, рабочий)
Опыт работы	Специальности и опыт работы студента по каждой из них
Специальность	Специальность, получаемая студентом при окончании учебного заведения
Специализация	Направление специальности, по которому обучается студент
Иностранный язык	Список иностранных языков и уровень владения ими
Тестирование	Список тестов и отметки о их прохождении
Экспертная оценка	Список предметов с экспертными оценками по каждому из них
Оценки по экзаменам	Список сданных предметов с оценками

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

Таблица 6.2. Атрибуты сущности «Опыт работы»

Атрибут	Описание
Специальность	Название специальности, по которой у студента есть опыт работы

Опыт	Опыт работы по данной специальности в годах
Место работы	Наименование предприятия, где приобретался опыт

Таблица 6.3. Атрибуты сущности «Иностранный язык»

Атрибут	Описание
Язык	Название иностранного языка, которым владеет студент
Уровень владения	Численная оценка уровня владения иностранным языком

Таблица 6.4. Атрибуты сущности «Тестирование»

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

Таблица 6.5. Атрибуты сущности «Экспертная оценка»

Атрибут	Описание
Дисциплина	Наименование дисциплины, по которой оценивался студент
Ф.И.О. преподавателя	Ф.И.О. преподавателя, который оценивал студента
Оценка	Экспертная оценку преподавателя
Атрибут	Описание
Предмет	Название предмета, экзамен по которому сдавался
Оценка	Полученная оценка

Составим ERD-диаграмму, определяя типы атрибутов и проставляя связи между сущностями (рис. 6.4). Все сущности будут зависимыми от сущности «Студент». Связи будут типа «один-ко-многим».

Рис. 6.4. ERD-диаграмма БД студентов

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

Следующим этапом при построении логической модели является определение ключевых атрибутов и типов атрибутов.

Таблица 6.7. Типы атрибутов

Атрибут	Тип
Номер	Number
Ф.И.О.	String
Пароль	String
Возраст	Number
Атрибут	Тип
Пол	String
Характеристика	String
	String
Специальность	String
Специализация	String
Опыт	Number
Место работы	String
Язык	String
Уровень владения	Number
Название	String
Описание	String
Оценка	Number
Дисциплина	String
Ф.И.О. преподавателя	String
Предмет	String

Выберем для каждой сущности ключевые атрибуты, однозначно определяющие сущность. Для сущности «Студент» это будет уникальный номер, для сущности «Опыт работы» все поля являются ключевыми, так как по разным специальностям студент может иметь разный опыт работы в разных фирмах. Сущность «Тест» определяется названием, так как студент по одному тесту может иметь только одну оценку. Оценка по экзамену определяется только названием предмета, экспертная оценка зависит от преподавателя, который ее составил, поэтому в качестве ключевых атрибутов выберем «Дисциплину» и «Ф.И.О. преподавателя». У сущности «Иностранный язык» уровень владения зависит только от наименования языка, следовательно, это и будет являться ключевым атрибутом.

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

Рис. 6.5. ERD-диаграмма БД студентов с ключевыми атрибутами

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