ИННОВАЦИИ БИЗНЕСУ

Одним из методов проектирования баз данных реляционного типа является метод СУЩНОСТЬ - СВЯЗЬ. Привлекательность этого метода состоит в том, что он не теряет присущей ему наглядности и простоты при проектировании сложных баз данных. Однако, в некоторых случаях применение метода СУЩНОСТЬ - СВЯЗЬ встречает определенные трудности. Ниже, на конкретных примерах, показаны ситуации, когда возникают эти трудности, указаны причины и предлагается способ их устранения.

Сначала рассмотрим метод СУЩНОСТЬ - СВЯЗЬ в том виде, как он изложен в соответствующей литературе. Рассмотрим пример проектирования базы данных, предназначенной для хранения информации о преподавателях и читаемых ими курсах. Для определенности примем степень связи m: n и класс принадлежности обеих сущностей необязательными. На рис. 1 представлена соответствующая совокупность из трех отношений.

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

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

Для устранения указанных трудностей проектирования баз данных предлагается дополнить метод СУЩНОСТЬ - СВЯЗЬ новым понятием о том, что связь, также как и сущность может иметь множество связей. Тип связи состоит из совокупности атрибутов связи. Сам факт наличия связи и все другие характеристики типа связи образуют единое множество атрибутов типа, поэтому хранение характеристик связи предлагается осуществлять в тех же отношениях, где и факт наличия связи. В частности, в приведенном примере информация о факте наличия связи хранится в отношении ЧИТАЕТ. Тогда в соответствии с выше изложенным и характеристику связи (домен ЧАСЫ) нужно также поместить в отношение ЧИТАЕТ. Тогда совокупность отношений рассмотренной выше базы данных примет вид, показанный на рис. 2. Можно также показать, что при использовании предложенных выше соглашений, создание отношения, предназначенного специально для хранения информации о характеристиках связи, не требуется при всех возможных сочетаниях степени связи с классами принадлежности. Во всех этих сочетаниях домен с характеристиками связи должен находиться в составе того отношения, в котором располагаются два ключевых домена связываемых отношений, определяющих факт наличия связи. Независимость данных сохраняется всегда.

Рис. 1

Рис. 2