Информационное моделирование предметных областей (Nuskjbgenkuuky bk;ylnjkfguny hjy;bymud] kQlgvmyw)

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

Информационное моделирование предметных областей

В программном обеспечении объекты находятся в определенных взаимосвязях друг с другом. Существует 3 вида взаимосвязей : ассоциация, обобщение и агрегация.

Типы взаимосвязей между объектами

Ассоциация — обозначает наличие логической связи между объектами. С каждой ассоциацией связано понятие мощности, которое может принимать одно из следующих значений: 1:1, 1:М и M:N. Мощность обозначает количество объектов определенного типа, которые будут участвовать в связи.
Обобщение (от общего к частному) — данный тип взаимосвязи реализуется как взаимосвязь одного родительского класса сущностей с несколькими дочерними классами сущностей.
Агрегация (целое-часть) — это взаимосвязь одного родительского класса сущностей с несколькими дочерними классами сущностей. При этом взаимосвязи могут быть описаны связями двух видов:

обязательно не идентифицирующими связями;
необязательно не идентифицирующими связями.

Детальное описание

1:1

В связи один-к-одному каждый блок сущности A может быть ассоциирован с одним блоком сущности B.

Рассмотрим такие сущности — Студент и Зачетная книга.

В каждый момент времени один студент имеет одну зачетную книгу, в то же время одна и та же зачетная книга принадлежит одному студенту.
Для представления связи 1:1 в схеме реляционной БД создаются две таблицы для каждого из объектов предметной области и первичный ключ одного из них (по выбору) добавляется к списку атрибутов другого объекта.

1:M

Если у вас есть две сущности спросите себя:

1) Сколько объектов из B могут относится к объекту A?

2) Сколько объектов из A могут относиться к объекту из B?

Если на первый вопрос ответ — множество, а на второй — один (или возможно, что ни одного), то вы имеете дело со связью один-ко-многим.

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

M:N

Связь многие-ко-многим — это связь, при которой множественным записям из одной таблицы (A) могут соответствовать множественные записи из другой (B).

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

Обобщение (is-a)

Связь типа обобщение реализуется как взаимосвязь одного родительского класса сущностей с несколькими дочерними классами сущностей. Используется, если составляющая объекта относится к основному объекту как класс к подклассу.
При использовании Обобщения первичный ключ родительского объекта переносится в состав первичного ключа дочерних объектов. Любопытно отметить, что при Обобщении реализуется так называемая иерархия наследования. При этом родительский объект содержит атрибуты, которые являются общими для всех дочерних объектов.

Агрегация (part of)

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

Нормализация баз данных

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

Первая нормальная форма

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

Первичный ключ.

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

Атомарность

Правило: поля не имеют дубликатов в каждой записи и каждое поле содержит только одно значение.

Порядок записей не должен иметь значение.

Вторая нормальная форма

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

Избыточность данных

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

См. также

Источники

Types of Table Relationships (англ.). Дата обращения: 22 мая 2017.