2.3.5. Различия в классификации объектов и отношений между ними

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

И тот, и другой подход имеет, право на существование. Принци­пиальной разницы, влекущей за собой какие-то серьезные послед­ствия, в сравниваемых подходах нет.

2.3.6. Терминологические различия

Кроме различия в изображении тех или иных сущностей, в тео­рии инфологического моделирования наблюдается расхождение в используемой терминологии. Например, в CASE Oracle родовой объект называется супертип (syper-type), а видовой - подтип (sub-type). Таких различий в терминологии можно привести много, но их фикса­ция не является сейчас нашей целью. Хотя обратить внимание на та­кие различия нужно, чтобы при использовании конкретной системы не возникло ошибочное понимание происходящего. Так, в некоторых CASE-системах (например, Design/IDEF, PowerDesigner и др.) исполь­зуется непривычная для теории проектирования БД трактовка поня­тия физического проектирования: под физическим проектированием в них понимается проектирование (описание) структуры БД для конк­ретной целевой СУБД.

2.3.7. Соглашения по именованию элементов er-модели

При описании базовой модели мы использовали только имена классов объектов, идентификаторов и свойств объектов.

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

Многие методики требуют обязательного именования связей. Поскольку связи являются двусторонними, то наименование связи будет меняться в зависимости от того, с какой стороны ее рассматри­вать. Поэтому часто в модели предлагается указывать оба эти назва­ния (например, в системах CASE Oracle, ProKit*WORKBENCH). В Design/IDEF1X обязательно надо указывать имя связи от «родителя» к «ребенку», имя связи в обратном направлении также можно ука­зать, но это не является обязательным.

Для того чтобы было понятно, к какому из направлений связи ка­кое название относится, принимают определенные соглашения о том, как располагать эти названия на схемах. Например, сверху линии по­мещать название, относящееся к левой стороне связи, а под линией - к правой; или разделять эти имена наклонной чертой (первым поме­щается имя от «родителя» к «ребенку»).

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

Для CASE-средств важной является также связь вопросов имено­вания элементов ER-модели и соответствующих им элементов даталогической модели. Так как ER-модель описывает предметную об­ласть и используется всеми категориями пользователей для обеспе­чения ее однозначного понимания, то желательно, чтобы имена давались на естественном национальном языке. Но в дальнейшем ER-модель используется для генерации описания структуры БД, а конк­ретные СУБД имеют разные ограничения на задание имен элементов БД. Хорошим решением этой проблемы является наличие в CASE-средстве возможности автоматически преобразовывать имена, исполь­зованные в ER-модели, в соответствии с ограничениями целевой СУБД. К сожалению, далеко не все CASE-средства обладают такими возможностями. Некоторые CASE-средства позволяют при создании ER-модели каждому ее элементу давать несколько имен (одно - для использования в концептуальной модели, другое - в даталогической (или, как она называется во многих современных CASE-средствах, -физической) модели и др.). Это, конечно, лучше, чем полное отсут­ствие возможности использовать разные имена, но не вполне соот­ветствует сути подхода, заключающейся в том, что по исходному опи­санию могут генерироваться проекты для разных целевых систем, так как ограничения на допустимые имена в каждой из этих систем мо­гут быть разными.

К сожалению, многие CASE-средства не только не обеспечивают, но даже и не контролируют правильность задания имен в полученной схеме БД. Это надо иметь в виду при построении ER-модели. При использовании некоторых CASE-средств возникают проблемы с ис­пользованием русского языка.