Банк данных (стр. 6 )

ИЛМ даже для небольшой и несложной предметной области включает в себя описание значительного числа компонентов и связей между ними. При этом встает проблема наглядности общей схемы. Эта проблема по-разному решается при ручном и автоматизированном построении инфологической модели. В автоматизированных системах чаще всего строится единое изображение ЕR - модели и используется прием масштабирования, когда, уменьшая или увеличивая масштаб изображения, на экране. можно посмотреть как всю схему, так и отдельный ее фрагмент.

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

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

5. Некоторые возможности, имеющиеся в одних системах или методиках, отсутствуют в других. В этих случаях возможны различные варианты: а) для изображения ситуации используются возможности, предоставляемые моделью, но это требует применения определенных приемов, часто несколько искусственных, для их представления; б) ситуация просто не отображается в модели.

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

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

Некоторые методики не вводят агрегированный объект как самостоятельную категорию. В этом случае агрегированный объект изображается как простой, при этом пользователь должен предварительно определить его идентификатор и свойства. Если модель допускает изображение только двоичных связей, то проектировщик должен преобразовать n - арную связь в совокупность бинарных.

Кроме указанных сложностей при определении идентификатора агрегированной сущности, могут возникнуть и проблемы при переходе от ИЛМ к даталогической модели.

Вариант, когда ситуация не может быть отражена в ИЛМ, может быть проиллюстрирован на следующем: если методика построения модели не предполагает фиксацию класса членства в связи, то эта информация будет, просто потеряна.

В некоторых САSЕ-системах имеет место ситуация, когда какая-то конструкция допускается в системе как промежуточная.

Например, в IDEF и САSЕ ОRАСLЕ отношение М: М допускается как неспецифическое отношение. Его наличие разрешается на ранних стадиях разработки проекта, а в дальнейшем оно должно быть заменено на специфическое отношение посредством введения третьей сущности. Это является недостатком системы, так как, во-первых, не все СУБД требуют такого преобразования (некоторые системы поддерживают отношение М:М в явном виде), и, во-вторых, если такое преобразование потребуется, его вполне система автоматизации проектирования могла бы выполнить автоматически на этапе даталогического проектирования. Даже если выполняется «ручное» проектирование, то указанное преобразование должно выполняться проектировщиком на стадии даталогического проектирования, а не при описании предметной области.

Кроме того, при рассматриваемом преобразовании на стадии инфологического проектирования в ЮЕР вводится новая категория сущностей — сущности пересечения или ассоциативные сущности. Введение новых сущностей влечет за собой введение в ИЛМ и дополнительных связей. Все это, вместе взятое, усложняет и без того нелегкую задачу инфологического проектирования.

В предметной области могут быть сущности, идентификаторы которых являются зависимыми от идентификатора какого-то другого объекта. Например, если участки на предприятии нумеруются в пределах цеха, то идентификатор участка будет составным, включающим в себя код цеха и код участка. В инфологической модели можно ограничиться указанием этого составного идентификатора. Некоторые методики построения ЕR - моделей (например, методология IDEF1X, Рrokit) предусматривают введение особых видов сущностей и особых видов отношений для отображения подобных ситуаций. Так, в IDEF сущность, для идентификации которой надо рассматривать ее отношение с другими сущностями, называется зависимой от идентификатора сущностью, и для ее изображения используется блок с закругленными углами. Для изображения же не зависимой от идентификации сущности используется прямоугольник. Для связи объектов, один из которых нужен для полной идентификации другого, вводится понятие идентифицирующего отношения. Для него также вводится свое условное обозначение. В ЮЕР для идентифицирующего отношения используется сплошная линия, а для неидентифицирующего — пунктирная.

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

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

Тема : Схемы и подсхемы.

Если бы назначением базы данных (БД) было только хранение данных, то ее структура была бы простой. Причина ее сложности в том, что она должна обеспечивать связи. 

Прежде всего следует обсудить способ, с помощью которого пользователи БД представляют эти связи.

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

На рис. 10 приведен пример схемы:

Рис.10

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

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

Термин схема используется для определения полной таблицы всех типов элементов данных и типов записей, хранимых в БД. Термином подсхема определяют описание данных, которое использует ПП – лист. На основе одной схемы можно составить много различных подсхем. Например, на рис. 11 приведены подсхемы двух ПП – листов. Программисты имеют различные представления о данных, но обе подсхемы получены из схемы, приведенной на рис. 11.

Подсхема программиста А

Подсхема программиста В

Ни схемы, ни подсхемы не отражают способов физического запоминания данных. Существует 4 различных вида описания данных:

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

Связи этих четырех видов описания данных представлены на рисунке 12.

Следующий момент, который следует обсудить – это связи между элементами данных.

Взаимосвязь между двумя типами данных может быть простая и сложная. Под простой связью понимается такая связь, в которой элементы соединяются один с одним. Например, №_служащего и Имя, так как каждое имя имеет соответствующий №_служащего и наоборот.

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

Четыре типа связи возможны между двумя наборами элементов А и В. связь А с В может быть простой, а обратная связь – сложной и наоборот, а также обе связи могут быть простыми или сложными. На рис. 13 изображены все эти варианты.

А ↔В – один к одному;  А  В – один ко многим;

А  В – многие к одному; А  В – многие ко многим

Рис. 13.

На рис. 14 показаны два способа представления связей между двумя наборами элементов.

№_служащего

53730

28719

53550

79623

15971

51883

№_отдела

044

172

090

№_служащего

№_отдела

53730	044
28719	172
53550	044
79623	090
15971	172
51883	044

Рис.14