Проектирование и управление разработкой сайта на платформе «1С-Битрикс: Управление сайтом»

Кратность связи «один-к-одному». Дискриминация

	О связи говорят, что она имеет кратность «один-к-одному», если каждый элемент сущности А может ссылаться на один и только один элемент сущности Б.

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

Для Битрикс-проектирования появление связей кратности «один-к-одному» характерно, в основном, при использовании приёма дискриминации.

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

В контексте ООП дискриминацию называют обобщением или генерализацией.

Смысл приёма в следующем. Пусть Интернет-магазин торгует только двумя видами товаров: книгами и музыкальными CD.

Мы видим, что у них есть общие атрибуты: ID, Наименование, Издатель, Цена. Однако только у книг есть атрибут ТипПереплёта и КоличествоСтраниц. И только у дисков есть Длительность. То есть, обе сущности:

• с одной стороны, проявляют общее поведение в качестве товара: у них есть цена, их можно купить, в списке их можно отбирать по производителю (издателю), можно сортировать по цене, искать по наименованию и т.д. – и хотелось бы иметь возможность всё это делать в общем списке и добавлять в один и тот же заказ;
• с другой стороны, кроме отображения в общем списке, эти товары могут быть разнесены по разным разделам сайта, где, например, книги могут быть отобраны по типу переплёта (в качестве подарка, как правило, лучше брать книги в твёрдом переплёте) – и детальные страницы тоже будут немного отличаться (только у дисков будет выводиться длительность).

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

Однако обратите внимание на поле ТипПереплёта. У книг на предыдущем рисунке оно было обязательным. Но поскольку к дискам эта характеристика неприменима, пришлось сделать это поле опциональным. Это означает, что теперь придётся при вводе и обработке также контролировать это поле программно.

	Ещё один минус: будет много пустых ячеек. Так, у всех без исключения книг будет пустым атрибут Длительность, а у дисков – ТипПереплёта и КоличествоСтраниц. А в том случае, если типов товаров будет больше, пустот станет больше, чем заполненных ячеек – и в случае классических таблиц это может стать большой проблемой. Эта проблема неактуальна для Битрикса, поскольку при добавлении новых свойств таблица не растёт вширь: вместо этого заполненные свойства сохраняются в отдельной таблице вида «ID элемента – ID свойства – значение свойства». Об этом можно подробнее прочитать в соответствующей главе. Но даже если предполагается использовать только одну сущность, отрисовать дискриминацию необходимо. Это позволяет чётко понимать, какие можно использовать отборы и другие действия с книгами и дисками в качестве просто товаров, а также какие узкоспециальные действия можно производить с частными вариантами.

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

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

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

	Сущность, не имеющая самостоятельной ценности, называется зависимой сущностью.

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

Если в Visio вы правильно соедините родителя с дискриминатором специальной связью Parent to category, а дискриминатор с каждой из сущностей-потомков специальной связью Category to child, то все обозначения будут расставлены автоматически. Вам останется только, щёлкнув по дискриминатору, в панели свойств выбрать дискриминирующий атрибут и отметить флаг Category is complete (он означает, что мы перечислили все возможные подвиды родительской сущности – а так всегда и надо делать).

А теперь самое сложное. Требуется отобразить структуру с дискриминацией на таблицы (инфоблоки). Чрезвычайно важно сразу продумать все возможные варианты использования сущностей – и выбрать наиболее подходящий способ отображения.

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

Итак, пусть изначально было N сущностей, обладающих общими свойствами.

Страница 9 - 9 из 12
Начало | Пред. | 7 8 9 10 11 | След. | Конец